16:00:26 #startmeeting F32-blocker-review 16:00:26 Meeting started Mon Mar 30 16:00:26 2020 UTC. 16:00:26 This meeting is logged and archived in a public location. 16:00:26 The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:26 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:26 The meeting name has been set to 'f32-blocker-review' 16:00:26 #meetingname F32-blocker-review 16:00:26 #topic Roll Call 16:00:26 The meeting name has been set to 'f32-blocker-review' 16:00:31 ahoy mateys 16:00:35 who's around for blocker review fun? 16:00:38 .hello2 16:00:39 coremodule: coremodule 'Geoffrey Marr' 16:00:41 ahoy 16:00:42 .hello2 16:00:43 bcotton: bcotton 'Ben Cotton' 16:01:41 * pwhalen is here 16:01:47 .hello2 16:01:48 lruzicka: lruzicka 'Lukáš Růžička' 16:02:07 yoha, coremodule 16:02:26 yo yo yo 16:02:30 * kparal is here 16:03:11 .hello2 16:03:12 frantisekz: frantisekz 'František Zatloukal' 16:03:13 here! 16:04:12 #chair lruzicka bcotton 16:04:12 Current chairs: adamw bcotton lruzicka 16:04:38 impending boilerplate alert 16:04:39 #topic Introduction 16:04:40 Why are we here? 16:04:40 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 16:04:40 #info We'll be following the process outlined at: 16:04:40 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:04:44 #info The bugs up for review today are available at: 16:04:46 #link http://qa.fedoraproject.org/blockerbugs/current 16:04:48 #info The criteria for release blocking bugs can be found at: 16:04:50 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:04:52 #link https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria 16:04:54 #link https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria 16:04:56 #info for Final, we have: 16:05:00 #info 7 Proposed Blockers 16:05:00 #info 2 Accepted Blockers 16:05:05 #info 3 Proposed Freeze Exceptions 16:05:05 #info 1 Accepted Freeze Exceptions 16:05:13 aaaaa the proposed blocker count keeps going up 16:05:16 * adamw hides the button 16:06:15 who wants to secretarialize? 16:07:36 * sumantro is here :D 16:07:40 I'll do it 16:07:53 thanks 16:07:57 #info coremodule will secretarialize 16:08:00 alrighty, let's get going 16:08:09 #topic proposed Beta blockers 16:08:10 er 16:08:11 #undo 16:08:11 Removing item from minutes: 16:08:16 #topic proposed Final blockers 16:08:29 come on adam, keep it together, you can do this, they don't have to know about the whiskey... 16:08:36 #topic (1816098) blivet-gui fail to create a encrypted PV/VG partition 16:08:36 #link https://bugzilla.redhat.com/show_bug.cgi?id=1816098 16:08:36 #info Proposed Blocker, blivet-gui, POST 16:09:11 that's a really nice proxy error 16:09:28 on bugzilla? 16:09:33 it came up for me eventually 16:09:40 reload fixed it 16:09:52 but the speed recently has been... suboptimal! 16:09:57 yeah 16:10:07 yeah 16:10:08 welp, per the terrible criterion i wish we never wrote, definitely +1 :) 16:10:27 +1 16:10:27 +1 Blocker 16:10:34 +1 blocker 16:10:34 +1 blocker 16:10:39 +1 blocker 16:11:03 +1 16:11:31 proposed #agreed 1816098 - AcceptedBlocker (Final) - accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." 16:11:57 ack 16:12:02 ack 16:12:02 ack 16:12:12 ack 16:12:40 ack 16:12:57 ack 16:13:00 #agreed 1816098 - AcceptedBlocker (Final) - accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." 16:13:05 #topic (1812596) repoquery suddenly missing results in --whatrequires on Fedora 32+ (seem to be related to virtual provides) 16:13:05 #link https://bugzilla.redhat.com/show_bug.cgi?id=1812596 16:13:06 #info Proposed Blocker, dnf, POST 16:13:22 hmm, I am not really sure about this one 16:13:30 I'd incline to -1 here, +1 FE 16:13:57 -1 blocker 16:14:07 i'm not really seeing any particularly persuasive reason it even needs to be an FE 16:14:33 hmm, yeah, It seems ok to expect somebody relying on whatrequires to have updated dnf 16:15:29 -1 blocker, -1 FE 16:15:33 I can't really estimate the implications of such a bug 16:15:42 we surely don't have a criterion for it 16:16:44 -1 blocker 16:16:52 hmm, worst case seems to be that some packager rebuilding library with dependencies will miss them and forget to rebuild them 16:17:02 breaking Rawhide in the process :D 16:17:21 so it can be a rawhide blocker then 16:17:26 nope 16:17:41 we're at -3 so far 16:17:44 -1 blocker 16:19:02 I dont have an opinion here 16:19:24 proposed #agreed 1812596 - RejectedBlocker (Final) - there is no indication that this breaks any of the release criteria, or any other justification for blocking release on this 16:19:31 ack 16:19:50 ack 16:20:12 ack 16:20:13 ack 16:20:52 #agreed 1812596 - RejectedBlocker (Final) - there is no indication that this breaks any of the release criteria, or any other justification for blocking release on this 16:20:59 #topic (1816547) Firefox not using langpacks for localization 16:20:59 #link https://bugzilla.redhat.com/show_bug.cgi?id=1816547 16:20:59 #info Proposed Blocker, firefox, NEW 16:23:04 I didn't really know if that was the right criterion 16:23:08 or if we have something better 16:23:25 it feels like we should have a criterion for when the translations are available but don't get used 16:23:53 hmm, I don't think Firefox falls under critpath/networking 16:24:06 I have this weird long standing bug where Firefox just flips from US English to Malawi 16:24:32 cmurf: that happens to me often for grammar checking 16:24:47 is it grammar or spelling? 16:24:54 spelling 16:25:00 i just checked this and it's flipped back to Malawi in the past two days 16:25:20 anyhow, I'd say I am +0, unless we have better criterion and/or I am reading the proposed one wrong 16:25:22 i have no idea what triggers this; right now I can't even get the language selectino menu to draw, it flickers instead 16:26:01 frantisekz: i mean, that was my initial reaction, but then...it is explicitly marked as critical path in comps 16:26:06 yeah, i'm +0 blocker, -1 FE 16:26:17 there is a "critical-path-apps" group in comps with the description "A set of applications that are considered critical path" 16:26:21 and firefox is in it 16:26:28 so on that basis i'm kinda +1 16:26:45 yes, but I my question was about "critical path actions" 16:26:46 https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in#_657 16:26:51 https://fedoraproject.org/wiki/Critical_path_package#Actions 16:27:17 well 16:27:20 I'm not sure why the criterion is written as it is 16:27:33 my logic is, we clearly consider *something* in firefox part of the critical path 16:27:37 and *none* of firefox is translated 16:27:38 soo.... 16:28:02 kparal: it's written that way because there are some things that are part of critpath which do much more than just their critpath stuff 16:28:27 I see 16:28:29 +1, based on that logic 16:28:36 so is networking the right action to pick here? 16:28:42 because it seems nothing else applies 16:28:47 kparal: i think so. it's been a while since this critpath stuff was, you know, 'touched' 16:28:53 it's all a bit bitrotten 16:28:57 I do not think a missing translation should be a blocker when the application works fine otherwise 16:29:01 (note all the xorg-x11-drv packages in the gnome critpath definition) 16:29:13 lruzicka: but you might not understand it 16:29:18 lruzicka: missing translations aren't 16:29:31 which is pretty severe for the only web browser in the system 16:29:38 the criterion specifically is written that way 16:29:40 it says "must correctly display all sufficiently complete translations available for use" 16:29:47 i.e. *if* there is a translation available, it must be displayed 16:30:24 I'm a tentative +1 but I'd like to hear from the maintainer 16:30:25 yes, this is against programming bugs, not missing translations 16:30:29 maybe punt and needinfo? 16:30:44 I'm leaning towards +1 as well 16:30:46 what info? 16:30:46 where is it written, kparal's link does not show anything like that 16:30:55 it seems pretty clearly broken, multiple people have reproduced 16:31:02 lruzicka: https://bugzilla.redhat.com/show_bug.cgi?id=1816547#c8 16:32:52 ok 16:33:01 did this ever work correctly? is it a regression? 16:33:20 sure it did 16:33:23 it says right in the bug 16:33:27 it worked up until a recent build 16:33:33 cmurf: https://bugzilla.redhat.com/show_bug.cgi?id=1816547#c5 16:33:48 In F31, Firefox is translated into Czech, at least. 16:34:17 yeah i jus read that, seems to be a regression 16:34:53 72 is a while ago 16:35:31 +1 blocker 16:35:42 okay, revising to +1 blocker 16:35:50 +1 blocker, too 16:37:12 proposed #agreed 1816547 - AcceptedBlocker (Final) - firefox is unambiguously marked critical path in comps, so this seems like it must violate "All critical path actions on release-blocking desktops must correctly display all sufficiently complete translations available for use." 16:37:54 ack 16:38:18 ack 16:38:33 ack 16:38:42 ack 16:38:58 #agreed 1816547 - AcceptedBlocker (Final) - firefox is unambiguously marked critical path in comps, so this seems like it must violate "All critical path actions on release-blocking desktops must correctly display all sufficiently complete translations available for use." 16:38:59 ack 16:39:02 #topic (1813515) [abrt] gnome-shell: cogl_matrix_stack_pop(): gnome-shell killed by SIGSEGV 16:39:02 #link https://bugzilla.redhat.com/show_bug.cgi?id=1813515 16:39:02 #info Proposed Blocker, gnome-shell, POST 16:39:08 oh goody, gnome-shell crashes, i love these 16:39:17 me 3 16:39:56 i'm tentatively +1 blocker even though i haven't hit it recently 16:40:48 I even was not able to reproduce it on the same machine, so I am not sure. 16:41:10 oh, I was, 16:41:11 crashes of the shell cause data loss, the user has no chance 16:41:36 lruzicka: you just reproduced the issue? 16:42:06 cmurf: yeah, we've historically had a strong tendency to accept known shell crashes because of this 16:42:10 no, that is a different bug 16:42:15 * adamw wonders what became of that whole wrapper thing desktop team keeps promising 16:42:19 sorry, I looked into a wrong window 16:42:30 wrapper? 16:42:47 this bug has a lot of duplicates 16:43:04 cmurf: there's this idea that they'll run the shell in some sort of simple wrapper process that shouldn't crash 16:43:08 FAF says 935 unique crashes 16:43:13 so shell crashes don't nerf the session any more 16:43:21 the other annoying this is that this crash could not be processed by the retrace server, i had to do it locally 16:43:24 but i dunno if it's still a thing 16:43:47 due to the number of people hitting this, I'm leaning towards +1 16:44:19 yeah, me too 16:44:21 +1, agree with kparal 16:44:26 +1 16:44:27 btw, has anyone else seen https://gitlab.gnome.org/GNOME/gjs/issues/294 ? 16:44:36 openqa runs into that one relatively often 16:44:53 though it does tend to be right at the start of a session so not a data loss candidate most likely 16:45:26 I know you won't believe me, but I haven't seen a single shell crash on F32 16:45:34 +1 blocker 16:45:40 I wonder if crashes only happen on wayland 16:46:08 proposed #agreed 1813515 - AcceptedBlocker (Final) - accepted as a conditional violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" with reference also to "All known bugs that can cause corruption of user data must be fixed or documented at Common F32 bugs" (as Shell crashes can often cause data loss) 16:46:19 ack 16:46:22 ack 16:46:24 ack 16:46:25 ack 16:46:28 ack 16:46:37 .fire kparal if things don't crash for you all the time what are you even good for 16:46:37 adamw fires kparal if things don't crash for you all the time what are you even good for 16:46:44 #agreed 1813515 - AcceptedBlocker (Final) - accepted as a conditional violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" with reference also to "All known bugs that can cause corruption of user data must be fixed or documented at Common F32 bugs" (as Shell crashes can often cause data loss) 16:46:57 #topic (1817082) gnome-shell: SIGSEGV when locking screen 16:46:57 #link https://bugzilla.redhat.com/show_bug.cgi?id=1817082 16:46:57 #info Proposed Blocker, gnome-shell, NEW 16:47:05 oh hey look another one 16:47:10 haha 16:47:57 i haven't run into it, but basically the same logic 16:48:25 So, this is the one. I have tried to reproduce it on the same machine, P50, it worked normally. 16:48:27 depends how common it is i guess 16:48:41 yeah 16:48:44 this is hybrid graphics 16:49:03 The laptop has two graphical cards, it worked on Nvidia only, and also on Nvidia+Intel 16:49:14 it'd be nice if someone who knows how to read the stack trace info attached, whether it could be related to hybrid graphics 16:49:15 let's rename this the Stephen Needs A New Laptop bug 16:49:17 could be transient 16:49:26 I was able to lock and unlock for at least 20 times consequently. 16:50:30 hmm, weren't there any AVX2 erratums in Intel CPUs? new microcode/BIOS might fix that? 16:50:53 on the other hand, Fedora should be using latest microcode on Intel, so... I don't know 16:51:19 FAF reports 1 unique report 16:51:47 * kparal votes for adamw's proposal 16:52:08 -1 then 16:52:27 until more people can reproduce it, -1 16:52:27 also can't find any other report like this on upstream gitlab 16:52:30 so yeah, -1 for me too 16:52:30 -1 blocker, unless someone can reproduce it doesnt look to affact man people 16:52:39 *many 16:52:45 -1 blocker 16:52:49 sgallagh: also you can't sit with us at lunch 16:52:56 -1 blocker 16:53:30 but I would like to see Stephen to try without the external monitors and stuff - because I did not have it so I could not test that 16:53:41 proposed #agreed 1817082 - RejectedBlocker (Final) - so far this seems somehow unique to sgallagh, others with same and similar laptops cannot reproduce it and we can find no indication anyone else has hit it in FAF or upstream gitlab 16:53:47 ack 16:53:50 ack 16:53:53 ack 16:53:54 ack 16:53:59 I’ll try to look into that when I’m not recovering from throwing my back out. 16:54:04 ack 16:54:15 sgallagh, ooo get better soon 16:54:24 Thanks 16:55:26 sgallagh: do re-propose if we can nail down the reproduction better and it seems significant enough 16:55:30 #agreed 1817082 - RejectedBlocker (Final) - so far this seems somehow unique to sgallagh, others with same and similar laptops cannot reproduce it and we can find no indication anyone else has hit it in FAF or upstream gitlab 16:55:41 #topic (1816761) in Wayland VM text is selected from line above pointer 16:55:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=1816761 16:55:41 #info Proposed Blocker, mutter, NEW 16:56:55 so how well must mouse cursor work? :) 16:57:13 is this the one that's just like a 1-pixel discrepancy? or the bigger one? 16:57:17 iirc there were two... 16:57:41 he says "one line" 16:57:52 that is pretty much, I believe 16:58:03 this is the bigger one i think 16:58:08 when I try to resize a window, I have the cursor shifted 1-2 cursors width to the right 16:58:31 it's definitely noticeable and inconvenient 16:58:38 wayland VM in what 16:58:58 F32 host and guest here 16:59:15 https://gitlab.gnome.org/GNOME/mutter/-/issues/1094 has more detail on the issue 16:59:42 i think i'm +1 on this one 16:59:55 +1 16:59:58 +1 17:00:06 +1 17:00:06 +1 17:00:25 i *believe* it's a guest-side issue, from reading the upstream bug, also 17:00:32 which means we can't fix it for lives with a post-release update 17:00:41 you can see it here: blob:https://imgur.com/05ce0787-35d1-485a-a347-f89aa5095e05 17:00:53 sigh 17:00:53 yeah, that one's a good illustration 17:01:08 https://i.imgur.com/hUOIFso.png 17:01:27 it's pretty hard to find a spot where you can resize the window 17:01:31 *the spot 17:01:34 proposed #agreed 1816761 - AcceptedBlocker (Final) - accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" and other desktop criteria when running in a VM using 'seamless mouse pointer' mode (which virt-manager and Boxes use by default) 17:01:56 ack 17:01:57 ack 17:02:06 ack 17:02:08 ack 17:02:13 ack 17:02:20 ack 17:03:36 #agreed 1816761 - AcceptedBlocker (Final) - accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" and other desktop criteria when running in a VM using 'seamless mouse pointer' mode (which virt-manager and Boxes use by default) 17:03:45 #topic (1817708) The desktop session will not start. 17:03:45 #link https://bugzilla.redhat.com/show_bug.cgi?id=1817708 17:03:45 #info Proposed Blocker, plasma-desktop, NEW 17:05:38 so...it's working now? 17:06:07 so, it was working today with 20200328 17:06:08 good question 17:06:16 if not +1 blocker 17:07:08 so, I might be -1 today 17:08:17 i guess i'm kinda punt-y? 17:08:24 When I saw this for the first time, it was in a VM, today I wanted to retest on bare metal, so I picked the latest compose on nightlies and realized it worked ok, so retested in VMs, both uefi and bios -> works 17:08:27 might be nice to try with other composes and have other people try 17:08:36 ok, punt is fine with me 17:09:04 +1 punt 17:09:10 +1p 17:09:13 +1 punt 17:09:14 +1 punt 17:11:09 proposed #agreed 1817708 - punt (delay decision) - it would be good to have a few more folks try this out on different systems to confirm whether it's gone away 17:11:14 ack 17:11:16 ack 17:11:20 ack 17:11:26 rdieter: did you have any thoguhts on this one? 17:11:35 sorry, just realized we should ping :) 17:11:40 ack 17:12:53 ack 17:13:26 just giving rdieter a bit of time 17:13:32 * adamw plays hold muzak 17:15:54 okay, let's move on 17:15:57 #agreed 1817708 - punt (delay decision) - it would be good to have a few more folks try this out on different systems to confirm whether it's gone away 17:16:16 #topic Proposed Final freeze exceptions 17:16:21 #info that was all the proposed blockers 17:16:48 #info we already accepted 1816547 and 1816761 as blockers, so we'll skip those 17:16:53 #topic (1814872) Lenovo T450s Touchpad barely works 17:16:53 #link https://bugzilla.redhat.com/show_bug.cgi?id=1814872 17:16:54 #info Proposed Freeze Exceptions, kernel, NEW 17:17:07 +1 fe 17:17:38 seems like a natural fe candidate 17:17:42 +1 FE 17:17:45 +1 fe 17:17:47 +1 fe 17:17:49 can't fix for lives with an update, and even for installs, it makes the initial install difficult 17:17:51 +1 17:18:07 i will take care of that 17:18:18 +1 fe 17:19:20 proposed #agreed 1814872 - AcceptedFreezeException (Final) - this is a significant bug that makes use of a live image difficult on affected systems 17:19:26 patch 17:19:44 proposed #agreed 1814872 - AcceptedFreezeException (Final) - this is a significant bug that makes use of a live image and initial installation difficult on affected systems, and those situations cannot be fixed with an update 17:20:00 ack 17:20:04 ack 17:20:57 well can be fixed by updated isos 17:21:07 ack 17:21:53 ack 17:21:59 ack 17:22:03 #agreed 1814872 - AcceptedFreezeException (Final) - this is a significant bug that makes use of a live image and initial installation difficult on affected systems, and those situations cannot be fixed with an update 17:22:34 #topic Accepted Final blockers 17:22:41 #info that's all the proposals, let's check in briefly on accepted bugs 17:22:48 #topic (1768206) DNF prompts for GPG key import for "repo_gpgcheck=1"-repositories despite "rpm --import"-ing the keys first 17:22:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=1768206 17:22:48 #info Accepted Blocker, dnf, NEW 17:24:04 need to run, thanks for the meeting, see you all next monday 17:25:28 frantisekz, bye 17:26:58 so, there seems to be a bit of confusion on dnf team's part here 17:27:01 i'm adding a comment to try and clarify 17:27:11 https://bugzilla.redhat.com/show_bug.cgi?id=1768206#c18 17:27:14 not sure we can do much more here 17:29:05 comment 14 concerns me 17:29:24 that's the "confusion" i was referring tio 17:30:19 #info there seem to be some perspective differences here, we have added a comment trying to clarify current state and requirements 17:32:25 #topic (1815463) It's impossible to create another user account through KDE System Settings 17:32:26 #link https://bugzilla.redhat.com/show_bug.cgi?id=1815463 17:32:26 #info Accepted Blocker, plasma-user-manager, NEW 17:32:29 this one seems slightly confused also 17:32:43 it magically went away? somewhere else than where rex thought it would? 17:32:50 i guess we should needinfo frantisek to re-test 17:34:52 I have tested it with 20200328 and I am able to create extra users using this any time 17:35:13 if you start Users, it works, if you follow the reproducer in the bug, it works, too 17:35:31 tested in a VM and bare metal 17:35:56 did you test that you could reproduce the *problem* with an older build, though? 17:36:31 give me 2 mins 17:36:42 when i'm trying to reproduce something i like to make sure i can actually reproduce the bug, before i try and reproduce the fix :) 17:37:19 yes, but I did not tried the fix 17:38:18 yes you did you used 20200328 where they used 20200325 17:38:19 I have been trying to create users for Desktop Login OpenQA test for the whole week and it went ok with 20200322, and now I tried 20200 17:38:24 20200328 17:38:52 but the proposed fix is not a part of 28 yet 17:40:31 the plasma systemsettings has the same version 17:40:37 in both of the composees 17:41:22 other things may have changed, though 17:41:29 anyhow 17:41:41 let's ask frantisek to test, as he knows for sure how he triggered the bug, and what with 17:41:59 #info it is not clear if this bug has been resolved for sure, we will ask frantisek to re-test and give his current experience 17:42:35 ls -la 17:44:43 embarrassingporn.mp4 17:44:53 #topic Open floor 17:45:11 that's everything, I believe 17:45:13 any other business, folks? 17:45:35 Well, one more question. 17:46:04 How could have frantisekz used the 20200325 compose when the bug was created on 20200320 ? 17:47:17 and I am sure I did not hit the bug in 20200322 nor 20200328. That is all I wanted to say. 17:50:43 that's why we should ask him :) 17:53:08 i needinfo'ed him 17:53:20 Yeah, I've seen it. 17:53:56 adamw, which him rdieter or frantisekz 17:54:05 frantisekz 17:56:44 okay, sounds like we're done! 17:56:47 thanks for coming out, folks 17:58:20 thanks adamw 17:59:02 didn't I fire you 17:59:50 thanks everybody, take care and stay healthy 18:00:30 #endmeeting