16:00:37 #startmeeting F35-blocker-review 16:00:37 Meeting started Mon Oct 18 16:00:37 2021 UTC. 16:00:37 This meeting is logged and archived in a public location. 16:00:37 The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 16:00:37 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:37 The meeting name has been set to 'f35-blocker-review' 16:00:40 #meetingname F35-blocker-review 16:00:40 The meeting name has been set to 'f35-blocker-review' 16:00:44 #topic Roll Call 16:01:01 .hello2 jbwillia 16:01:02 Southern_Gentlem: Sorry, but user 'Southern_Gentlem' does not exist 16:01:08 .hello jbwillia 16:01:09 Southern_Gentlem: jbwillia 'Ben Williams' 16:01:14 .hello2 16:01:15 coremodule: coremodule 'Geoffrey Marr' 16:01:21 * coremodule willing to act as secretary. 16:01:40 .hello2 16:01:43 frantisekz: frantisekz 'František Zatloukal' 16:02:20 .hello chrismurphy 16:02:21 cmurf[m]: chrismurphy 'Chris Murphy' 16:02:32 morning morning, how's everyone doing? 16:02:42 .hello2 16:02:43 pwhalen: pwhalen 'Paul Whalen' 16:03:10 Great, how about you, adamw? 16:04:16 frazzled... 16:04:42 * pwhalen admits that's more accurate for him too 16:05:14 heh 16:06:25 my god man, it's only Monday 16:07:12 but i guess i can get on the frazzled bandwagon 16:09:14 cmurf: kde 16:09:20 alriiighty 16:09:21 mondays are for trash mostly 16:09:29 #chair cmurf pwhalen 16:09:29 Current chairs: adamw cmurf pwhalen 16:09:34 boilerplate alert 16:09:39 #topic Introduction 16:09:41 Why are we here? 16:09:44 #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:09:47 #info We'll be following the process outlined at: 16:09:51 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:09:54 #info The bugs up for review today are available at: 16:09:58 #link http://qa.fedoraproject.org/blockerbugs/current 16:10:00 #info The criteria for release blocking bugs can be found at: 16:10:03 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:10:06 #link https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria 16:10:11 #link https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria 16:10:37 #info for Final, we have: 16:10:41 #info 3 Proposed Blockers 16:10:44 #info 7 Accepted Blockers 16:10:48 #info 2 Proposed Freeze Exceptions 16:10:52 #info 6 Accepted Freeze Exceptions 16:11:05 #info coremodule will secretarialize 16:11:11 let's get started with: 16:11:11 #topic Proposed Final blockers 16:11:17 #topic (2012758) clevis - thread 'main' panicked at 'called `Option::unwrap() 16:11:19 #link https://bugzilla.redhat.com/show_bug.cgi?id=2012758 16:11:22 #link https://pagure.io/fedora-qa/blocker-review/issue/543 16:11:24 #info Proposed Blocker, clevis-pin-tpm2, ASSIGNED 16:11:31 #info Ticket vote: FinalBlocker (+4,0,-0) (+bcotton, +geraldosimiao, +mattdm, +lruzicka) 16:11:44 so i left this on the meeting list even though it has +4 as discussion in the bug report indicated this may not be a critical problem 16:12:43 note comment #5 and #6 16:14:10 i'm asking pbrobinson about it in the IoT room now 16:14:26 I've not hit this (nor has openqa) but also not using the same commands 16:14:45 okay, would be nice to have his feedback too, maybe we can move this to the end of the meeting? 16:14:52 can we skip for now till we can get more info 16:15:39 roger 16:15:50 #info we'll table this for a bit to see if we can get more info from pbrobinson before voting 16:16:05 #topic (2010058) F34/F35 5.14 kernels will not boot on AWS EC2 t2.small / c4.large / m4.large instances 16:16:09 yeah table is the word 16:16:15 #link https://bugzilla.redhat.com/show_bug.cgi?id=2010058 16:16:19 #link https://pagure.io/fedora-qa/blocker-review/issue/549 16:16:22 #info Proposed Blocker, dracut, NEW 16:16:26 #info Ticket vote: FinalFreezeException (+4,0,-0) (+adamwill, +bcotton, +mattdm, +lruzicka) 16:16:40 so we have the votes for FE here already, blocker is a trickier call 16:16:56 we did quite carefully limit the blocker requirements here, and i think the bug doesn't meet them 16:18:01 the requirement is "Release-blocking cloud disk images must be published to Amazon EC2 as AMIs, and these must boot successfully and meet other relevant release criteria on at least one KVM-based x86 instance type, at least one KVM-based aarch64 instance type, and at least one Xen-based x86 instance type." 16:18:13 it's not actually clear from the bug if there's an arch for which there's no working instance type. 16:18:16 I think FE but respin images with the fix when it lands? 16:19:07 (I think we also may need to expand that requirement in the future.) 16:20:03 Seems like a blocker to me, but based on the existing criteria +1FE 16:20:14 well, i was assuming that as FE we'd pull the fix in anyway 16:20:34 the bug mentions there is a tested fix, it just needs backporting 16:20:42 doesnt appear that anyone has tried the workaround for f35 just f34 so +1FE 16:22:12 I'm hoping that we can do that but if for some reason it doesn't happen by the blessed RC, FE means we ship anyway, right? So in that case we should respin ASAP. 16:22:38 yes. okay. 16:22:49 +1 FE then 16:23:19 **fingers crossed ** 16:23:59 proposed #agreed 2010058 - RejectedBlocker (Final) AcceptedFreezeException (Final) - on current understanding this does not violate the criterion, as we do have at least one working instance type per arch (which is all the criterion requires). But it's clearly a big problem worth fixing for release (and we intend to do so) 16:24:20 ack 16:24:28 ack 16:24:29 ack 16:24:35 mattdm, unless by thursday for the go/nogo there is a consensus otherwise 16:24:37 ack 16:24:57 #agreed 2010058 - RejectedBlocker (Final) AcceptedFreezeException (Final) - on current understanding this does not violate the criterion, as we do have at least one working instance type per arch (which is all the criterion requires). But it's clearly a big problem worth fixing for release (and we intend to do so) 16:25:06 #topic (2011928) Fedora 35 aarch64 cloud image based openstack VM hangs 16:25:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=2011928 16:25:12 #link https://pagure.io/fedora-qa/blocker-review/issue/525 16:25:17 #info Proposed Blocker, kernel, NEW 16:25:19 #info Ticket vote: FinalBlocker (+1,0,-0) (+bcotton) 16:26:15 so the aarch64 img work but just not in an openstack vm? 16:26:36 it seems, uh...murky 16:26:52 https://bugzilla.redhat.com/show_bug.cgi?id=2011928#c36 throws the cat among the pigeons a bit 16:27:16 there definitely seem to be reproducible problems running on a specific openstack provider called vexxhost...but then dusty says coreos folks saw issues on vexxhost a month ago. 16:27:24 i don't know if we've tried running on any other openstack instance. 16:27:56 i'm still working on this, as are others 16:28:09 yeah, it definitely seems to be pretty active 16:28:16 even though we're very late, i kinda still want to punt on this 16:28:28 in the hopes someone does figure out what the heck is going on soon. it does seem pretty active. 16:28:58 I've not reproduced anywhere else, it would be great if someone could test on another openstack instance 16:29:07 i'm not sure we can block on something we don't understand let alone without an upstream fix 16:29:28 coreos folks have said they are hitting something similar on aarch64 where they are using xfs 16:29:35 yeah, as i said above 16:29:57 speculation is that it's either an alignment problem that arm is more sensitive with or possibly toolchain specific... but yeah 16:30:11 once i get a kernel crash dump to developers, it should be less murky 16:30:55 i could use some help with kdump stuff if anyone has experience with it 16:31:13 sysrq+c just hangs the VM, i'm not getting a kernel core dump file in /var/crash 16:31:32 either on #fedora-qa or #kernel:fedoraproject.org 16:35:00 alright 16:35:07 does everyone else feel punt-y here? 16:35:39 yeah for now 16:35:52 +1 punt 16:36:40 +1 punt 16:36:57 oh, should we grant it FE status at least so we can get a fix in without needing votes if one happens to show up quickly? 16:37:00 i'm definitely +1 FE at least 16:37:06 +1FE 16:37:11 +1FE 16:37:32 +1 FE 16:38:03 proposed #agreed 2011928 - punt (delay decision) on blocker, AcceptedFreezeException (Final) - though it's very late, we're still actively researching this and can't be sure yet if it needs to block the release. many folks are working on it actively and we hope for developments soon. We agree it's at least serious enough to grant a freeze exception in any case. 16:38:04 another argument is that it's a conditional blocker, as it seems to only happen in openstack (which is itself curious to everyone) 16:38:18 ack 16:38:45 cmurf: basically i think if this turned out to be something odd about *vexxhost specifically* i'd likely be -1. if it turns out to affect any openstack instance, or at least some likely common openstack version/config, i'd be +1 16:39:21 it is affecting openstack 16:39:44 i'm not sure if it's all openstack providers though, hence your question about vexxhost 16:40:11 ack 16:40:35 +1 fe 16:40:38 ack 16:42:20 #agreed 2011928 - punt (delay decision) on blocker, AcceptedFreezeException (Final) - though it's very late, we're still actively researching this and can't be sure yet if it needs to block the release. many folks are working on it actively and we hope for developments soon. We agree it's at least serious enough to grant a freeze exception in any case. 16:42:59 okay 16:43:08 didn't hear from pbrobinson yet, so let's do: 16:43:15 #topic Proposed Final freeze exceptions 16:43:20 #topic (2014421) Include the latest build that fixes issues on GNOME 41 16:43:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=2014421 16:43:27 #link https://pagure.io/fedora-qa/blocker-review/issue/550 16:43:31 #info Proposed Freeze Exceptions, gnome-shell-extension-dash-to-dock, ON_QA 16:43:34 #info Ticket vote: FinalFreezeException (+1,0,-1) (+lruzicka, -kparal) 16:43:41 so, I've proposed this, and I am -1 FE :D 16:44:10 ok frantisekz why 16:44:15 forgot that we're doing stable push before the release, so having it as a FE woudln't make sense 16:44:31 yeah, if it's not on the media it's probably not necessary 16:44:44 the reason was to make the 0day experience painless on upgrades, that's assured by the stable push right before the release 16:45:03 so, sorry for adding another useless item here 16:45:30 ok (adds to my list for sooner respins) 16:46:35 Southern_Gentlem it shoudln't be necessary if I am not mistaken, if it isn't part of any compose? 16:47:15 if it is a zero day fix therefore its an update will be pulled in 16:48:20 i'm also -1 as there's no advantage here really. 16:48:33 -1 FE 16:50:44 -1 FE 16:51:03 1,0,-6 16:53:32 sorry, juggling KDE bugs, heh 16:54:17 proposed #agreed 2014421 - RejectedFreezeException (Final) - as this extension is not on the media, there's no real need for a freeze exception here, a 0-day update achieves the same goal. 16:54:24 ack 16:54:26 ack 16:54:58 ack 17:00:09 #agreed 2014421 - RejectedFreezeException (Final) - as this extension is not on the media, there's no real need for a freeze exception here, a 0-day update achieves the same goal. 17:00:26 sorry again, i just figured out why we can't delete disabled flatpak remotes...heh 17:00:34 #topic (2012863) Gnome Software does not refresh after installation from RPM. 17:00:40 #link https://bugzilla.redhat.com/show_bug.cgi?id=2012863 17:00:44 #link https://pagure.io/fedora-qa/blocker-review/issue/530 17:00:47 #info Proposed Freeze Exceptions, gnome-software, NEW 17:00:52 #info Ticket vote: FinalFreezeException (+3,1,-0) (+catanzaro, +bcotton, +geraldosimiao, kparal) 17:01:02 +1 FE 17:01:08 +1 FE 17:01:40 .hello geraldosimiao 17:01:41 geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' 17:01:56 sorry I'm late 17:03:34 ok, so i pushed back mildly on this as it's not exactly a one-liner patch 17:03:56 so mcatanzaro's further justification is that there is a non-aesthetic consequence here - after installing an app you can't remove it until you restart gnome-software. 17:04:13 which, yeah, that's a bug it'd be nice to fix. i just worry about the nightmare scenario that we inadvertently break something worse. 17:04:42 we can wait to see / test the proposed patch then, fair point 17:05:26 if there is not fe how would we test 17:05:30 no fe 17:05:49 an update can be submitted 17:05:55 it just doesn't go stable without an FE 17:10:39 so punt so we can see if the medicine is not worse that the issue 17:10:49 than 17:11:14 sorry, i'm splitting attention with a KDE blocker meeting now :D 17:11:16 busy morning 17:11:28 * cmurf[m] distracted as well 17:11:32 we could accept it as an FE but only pull the fix in if someone swears to me that it's safe, i guess 17:12:05 which would make your life easier at this point 17:16:27 ok, let's go with that 17:16:41 haha 17:17:38 proposed #agreed 2012863 - AcceptedFreezeException (Final) - we accept this as there is a practical bug here it'd be nice to fix (can't remove a package after installing it unless you restart Software), but we want to be very sure the fix is safe before we actually pull it in 17:17:59 ack 17:18:50 ack 17:19:32 ack 17:21:38 #agreed 2012863 - AcceptedFreezeException (Final) - we accept this as there is a practical bug here it'd be nice to fix (can't remove a package after installing it unless you restart Software), but we want to be very sure the fix is safe before we actually pull it in 17:21:51 #topic (1990584) F35FailsToInstall: rust-matrixmultiply+thread-tree-devel, rust-matrixmultiply+threading-devel 17:21:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=1990584 17:21:58 #link https://pagure.io/fedora-qa/blocker-review/issue/554 17:22:01 #info Proposed Freeze Exceptions, rust-matrixmultiply, MODIFIED, depends on other bugs 17:22:56 +1 FE, there is no harm in fixing FTI bug 17:23:15 also fti bug would remain forever in the release ('fedora') repository 17:24:24 +1 fe 17:24:29 +1 FE 17:25:27 yeah, sure 17:26:18 proposed #agreed 1990584 - AcceptedFreezeException (Final) - no harm fixing an FTI issue so the frozen tree is good and upgrades work until the release day 17:27:14 ack 17:27:33 ack 17:27:40 ack 17:30:36 #agreed 1990584 - AcceptedFreezeException (Final) - no harm fixing an FTI issue so the frozen tree is good and upgrades work until the release day 17:32:35 ok, let's go to: 17:32:39 #topic Accepted Final blockers 17:35:34 so...the 10,000 foot overview here is: we have fixes in flight for everything except the KDE bugs 17:35:48 let's go into detail on those 17:35:55 #topic (2011291) Discover shows a misleading state of Flatpak repos, can't delete disabled repos 17:35:58 #link https://bugzilla.redhat.com/show_bug.cgi?id=2011291 17:36:02 #link https://pagure.io/fedora-qa/blocker-review/issue/512 17:36:05 #info Accepted Blocker, plasma-discover, NEW 17:36:41 #info we have fixes for these as of this morning. I have confirmed the first "misleading state" fix, the "can't delete disabled" fix showed up during the meeting and I haven't tested it yet, but it should be good 17:36:56 #topic (2011333) Toggling repo in Discover doesn't redraw the checkbox, confusing users 17:37:00 #link https://bugzilla.redhat.com/show_bug.cgi?id=2011333 17:37:03 #link https://pagure.io/fedora-qa/blocker-review/issue/517 17:37:07 #info Accepted Blocker, plasma-discover, NEW 17:37:28 #info we also now have a fix for this, I have confirmed that it works. I'll submit updates later today 17:37:41 #topic (2011322) Discover doesn't seem to find any RPM packages, neither locally installed nor in RPM repos (but just under en_US locale) 17:37:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=2011322 17:37:46 #link https://pagure.io/fedora-qa/blocker-review/issue/515 17:37:50 #info Accepted Blocker, plasma-discover, NEW 17:38:45 #info this one is outstanding, but at least we worked out the trigger (bug only happens in US locale, for some reason). KDE devs are actively helping us look into this one now, we hope to try and get somewhere with it today. 17:40:52 yeah 17:44:35 anyone have other thoughts/notes on these? 17:45:06 nope 17:47:18 okay. i've got a busy day of KDE package builds ahead of me... 17:47:39 good luck :) 17:49:16 #topic Proposed Final blockers 17:49:23 let's circle back to: 17:49:27 #topic (2012758) clevis - thread 'main' panicked at 'called `Option::unwrap() 17:49:30 #link https://bugzilla.redhat.com/show_bug.cgi?id=2012758 17:49:33 #link https://pagure.io/fedora-qa/blocker-review/issue/543 17:49:36 #info Proposed Blocker, clevis-pin-tpm2, ASSIGNED 17:49:40 #info Ticket vote: FinalBlocker (+4,0,-0) (+bcotton, +geraldosimiao, +mattdm, +lruzicka) 17:50:02 i didn't hear back from pbrobinson, i guess he's busy. so possibly the safe thing to do here is accept it, but with a proviso that we can revote if it turns out not to be a big deal? 17:51:00 ack 17:51:06 +1, sounds reasonable 17:51:06 +1 fb with provision 17:51:10 ack 17:51:22 ack, wfm 17:51:28 it seems if one remove the clevis-pin-tpm2 all work fine 17:51:39 so a fix for now 17:52:09 then my question at that point did the hardware have tpm2 17:53:20 proposed #agreed 2012758 - AcceptedBlocker (Final) - we accept this as a blocker on the basis that it violates "When configured on hardware with a Trusted Platform Module (TPM), it must be possible for the Clevis utility to automatically decrypt any encrypted partitions on boot without any user intervention" in enough cases. If further information suggests that's not the case, we may change the decision 17:53:36 ack 17:53:38 ack 17:53:42 ack 17:53:44 ack 17:54:11 #agreed 2012758 - AcceptedBlocker (Final) - we accept this as a blocker on the basis that it violates "When configured on hardware with a Trusted Platform Module (TPM), it must be possible for the Clevis utility to automatically decrypt any encrypted partitions on boot without any user intervention" in enough cases. If further information suggests that's not the case, we may change the decision 17:54:14 #topic Open floor 17:54:17 any other business, folks? 17:55:07 hopes for this week this stuff gets resolved so cmurf[m] can do his USS shipping joke 18:04:59 ok, so now adamw can end the meeting? 18:05:37 i guess we can! 18:05:43 thanks for coming everyone 18:05:55 sorry for splitting attention a bit 18:05:57 #endmeeting