16:02:59 #startmeeting F34-blocker-review 16:02:59 Meeting started Mon Apr 5 16:02:59 2021 UTC. 16:02:59 This meeting is logged and archived in a public location. 16:02:59 The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:59 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:59 The meeting name has been set to 'f34-blocker-review' 16:03:03 #meetingname F34-blocker-review 16:03:03 The meeting name has been set to 'f34-blocker-review' 16:03:08 #topic Roll Call 16:03:13 .hello2 16:03:14 bcotton: bcotton 'Ben Cotton' 16:03:16 hi folks, who's around for blocker fun? 16:03:53 .hello jbwillia 16:03:54 Southern_Gentlem: jbwillia 'Ben Williams' 16:06:28 i was going to say just 3 of us here everything a blocker and go home 16:07:33 proposed #agreed AdamW needs to change his name to Ben for this meeting 16:08:16 how'd you figure 16:08:29 does seem like attendance is a bit thin, i guess today's a holiday in lots of places 16:08:46 wasn't that yesterday? 16:09:16 yesterday was a sunday, so, no? 16:09:27 er, here, anyway 16:09:29 timezones :P 16:09:31 * pwhalen notes it's a holiday for you too adamw :) 16:09:44 yeah, but i'm an idiot who proposes meetings too late 16:10:02 well, let's start up, anyway, and if we don't seem to have enough voters to achieve anything, i'll shut it back down again 16:10:05 what holiday is it? 16:10:12 #chair bcotton pwhalen 16:10:12 Current chairs: adamw bcotton pwhalen 16:10:14 easter monday 16:10:16 .hello2 16:10:17 coremodule: coremodule 'Geoffrey Marr' 16:10:22 #topic Introduction 16:10:23 * coremodule willing to secretarialize. 16:10:26 Why are we here? 16:10:31 #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:10:36 #info We'll be following the process outlined at: 16:10:40 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:10:45 #info The bugs up for review today are available at: 16:10:50 #link http://qa.fedoraproject.org/blockerbugs/current 16:10:55 #info The criteria for release blocking bugs can be found at: 16:11:00 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:11:05 #link https://fedoraproject.org/wiki/Fedora_34_Beta_Release_Criteria 16:11:09 #link https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria 16:11:23 #info for Final, we have: 16:11:28 #info 2 Proposed Blockers 16:11:28 #info 3 Accepted Blockers 16:12:17 .hello geraldosimiao 16:12:18 geraldosimiao: geraldosimiao 'Geraldo S. SimiĆ£o Kutz' 16:12:29 hi geraldo 16:12:35 #info coremodule will secretarialize 16:12:39 ok, let's get started 16:12:42 #topic Proposed Final blockers 16:12:55 #topic (1946074) boot failure when LV is a cryptoluks device used as sysroot 16:12:59 #link https://bugzilla.redhat.com/show_bug.cgi?id=1946074 16:13:03 #link https://pagure.io/fedora-qa/blocker-review/issue/321 16:13:06 #info Proposed Blocker, dracut, NEW 16:13:11 #info Ticket vote: FinalBlocker (+2,0,-0) (+adamwill, +chrismurphy) 16:13:21 so we have +2 already. this does seem a clear violation of the criteria 16:14:06 +1 16:14:13 +1 16:14:14 +1 16:14:20 +1 16:14:29 +1 16:14:59 alrighty then 16:15:56 proposed #agreed 1946074 - AcceptedBlocker (Final) - this seems like a clear 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" combined with the requirement that installed systems boot successfully 16:16:00 ack 16:16:18 ack 16:16:34 ack 16:16:56 ack 16:17:26 #agreed 1946074 - AcceptedBlocker (Final) - this seems like a clear 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" combined with the requirement that installed systems boot successfully 16:17:34 #topic (1942443) Login using password failed after upgrade to Fedora 34 16:17:39 #link https://bugzilla.redhat.com/show_bug.cgi?id=1942443 16:17:44 #link https://pagure.io/fedora-qa/blocker-review/issue/317 16:17:47 #info Proposed Blocker, gdm, NEW 16:17:53 #info Ticket vote: FinalBlocker (+0,0,-2) (-chrismurphy, -catanzaro) 16:18:02 so we've actually discussed this a bit more in IRC than in the bug 16:18:49 basically, we know of at least two scenarios in which this happens (where the attempted fix for #1933520 doesn't kick in): 16:19:03 1. long-upgraded installs that started as a release before authselect was default 16:19:21 2. systems where the nsswitch config has been changed outside of authselect for any reason 16:19:56 that's how i understand it, anyhow 16:20:15 on the one hand i guess probably most people will be ok, on the other hand it's a pretty bad problem if you do hit it. 16:20:40 so anyone upgrading from what releases 16:21:34 i think 27 and earlier 16:21:42 -1 blocker 16:21:49 acording to this, was on F28... https://fedoraproject.org/wiki/Changes/AuthselectAsDefault 16:21:50 but it's not just like, if you try and upgrade directly, it fails 16:21:59 if you went 27 -> 29 -> 31 -> 33 and you're now going to 34, it fails 16:22:10 (again, aiui) 16:22:24 what criteria would this meet? 16:22:54 ugh, i don't like this :/ 16:23:32 the criterion that you can log into the desktop... 16:23:38 oh fair 16:23:46 but it's conditional on having an affected system. so, awkward case 16:23:58 bcotton: same, I feel like it could affect a fair number of people 16:24:14 well and dont we have one that also we have to be able to upgrade from an ealrier release 16:25:22 sorry, that was a cat induced repeat :D 16:25:35 adamscat++ 16:25:38 is there a workarround for these cases? 16:25:38 Southern_Gentlmen: yeah, https://fedoraproject.org/wiki/Fedora_34_Beta_Release_Criteria#Upgrade_requirements 16:25:43 there is an upgrade criterion yes 16:25:52 +1 blocker 16:26:01 but it's phrased as basically 'upgrading from one or two releases ago must work' 16:26:17 upgrading from 33 is upgrading from one release ago 16:26:25 it doesn't explicitly cover the "long standing install upgraded continuously" scenario (and this is to an extent intentional as we know there are sometimes awkward cases with that) 16:26:40 it doesn't explictly exclude it 16:26:55 we don't actually want to commit ourselves to saying a system upgraded from FC1 will work perfectly every time 16:28:11 i say blocker for now but if it was in a go/nogo meeting i would say wave 16:28:54 i can't decide which side of the fence i fall on. there are good arguments for either decision 16:28:55 this is one of those nice to have 16:28:59 i think without more information (like ~ how many people it would affect and etc) southern is right 16:29:19 s/is right/has a good idea 16:30:05 this can come down to user error as well they didnt clean up after each upgrade 16:30:14 thus my stand 16:30:19 call me a weak -1 to block and +1 FE if we can come up with a fix to mitigate it 16:30:34 i will go with that 16:30:42 -1 blocker +1 FE 16:30:48 +1 FE 16:31:29 weak -1 blocker, definite +1 FE. We should really try to get this fixed 16:31:32 fe? 16:31:38 +1 fe 16:31:45 u9000: Freeze Exception 16:31:49 oh 16:31:56 +1 fe 16:32:07 "everytime we make something idiot prove, then they make better idiots" 16:32:09 i'm more or less in the same place as ben 16:32:19 i'd really want this to be fixed but it's hard to say we'd absolutely hard block the release on it 16:33:26 so my question does it happen on something install after f27 16:34:43 proposed #agreed 1942443 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is a very close call, but the consensus was that it's just too narrow in scope to see as a release blocker (we believe it affects systems that started as Fedora 27 or earlier, and systems where nsswitch configuration was changed outside of authselect). It is accepted as a freeze exception issue for the usual reason upgrade-related issues are. 16:34:44 need a date range of F28 please 16:34:48 ack 16:35:10 Southern_Gentlem: it can happen to more recently-installed systems if nsswitch.conf got modified outside of authselect's system for any reason 16:35:14 (aiui) 16:35:14 ack 16:35:21 ACK 16:35:23 ack 16:35:24 did that fit one line? 16:35:50 if your screen is wide enough 16:36:15 heh 16:36:41 #agreed 1942443 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is a very close call, but the consensus was that it's just too narrow in scope to see as a release blocker (we believe it affects systems that started as Fedora 27 or earlier, and systems where nsswitch configuration was changed outside of authselect). It is accepted as a freeze exception issue for the usual reason. 16:37:32 at a quick look, there is no update on any of the accepted blockers from last week, afaics :| 16:37:37 i provided more info on the kde update one, but that's all 16:37:42 so, let's move onto: 16:37:46 #topic Open floor 16:38:17 are libreboot issues out of scope? 16:38:21 any other blocker/f34-release-related business or concerns? 16:38:22 adamw: I have a late submission 16:38:31 u9000: yeah, i think so, as that's not anything release blocking, is it? 16:38:34 pwhal: submit away! 16:38:43 https://bugzilla.redhat.com/show_bug.cgi?id=1946278 16:39:15 adamw: i haven't got a chance to test it with f34, but f33 doesn't boot at all on libreboot 16:39:23 the live usb does, though 16:39:41 (also i just remembered this, which is why i haven't brought it up earlier) 16:40:00 Just added the blocker flag to it 16:40:41 ok, let me run that 16:40:55 just a sec 16:40:58 plays nuzak 16:41:11 urgh, i can't get into blockerbugs. well we'll do it the manual way! 16:41:56 #topic (1946278) latest uboot fails to load the dtb 16:42:00 #link https://bugzilla.redhat.com/show_bug.cgi?id=1946278 16:42:14 #info Proposed Blocker, uboot-tools, NEW 16:42:44 pwhalen: so, do we know if "some systems" includes any on the Blessed List Of Important Ones? 16:43:02 https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Devices 16:43:43 it does, it will affect quite a few 16:43:56 +1 blocker 16:44:16 +1 here too 16:44:26 +1 blocker 16:44:29 +1 blocker 16:45:08 +1 16:45:20 +1 16:45:33 +1 16:46:00 did i miss anything important 16:46:20 u9000: no 16:46:20 proposed #agreed 1946278 - AcceptedBlocker (Final) - accepted as a violation of "All release-blocking images must boot in their supported configurations" for affected ARM systems (pwhalen avows that systems on the list of officially supported ARM devices will be affected) 16:46:31 ack 16:46:32 copperi: thanks 16:46:33 ack 16:46:33 heh 16:46:34 ack 16:46:34 ack 16:46:39 ack 16:47:29 ack 16:48:06 #agreed 1946278 - AcceptedBlocker (Final) - accepted as a violation of "All release-blocking images must boot in their supported configurations" for affected ARM systems (pwhalen avows that systems on the list of officially supported ARM devices will be affected) 16:48:13 okay, so back to: 16:48:15 #topic Open floor 16:48:41 is this strange bug here fix advanced in anyway? https://bugzilla.redhat.com/show_bug.cgi?id=1929643 16:49:51 that's on the accepted blocker list 16:50:19 adamw: i can secretarialize so you can get back to your holiday 16:50:26 thanks for your testing on it, btw 16:50:44 so it definitely seems like there are broken cases there, but we still have no input from the developers :( 16:50:54 @ben 16:50:55 grrr 16:50:55 Ben Cotton: coremodule already volunteered 16:51:06 oh, i missed that. cool 16:51:43 i've got my libreboot laptop now so i can test if f34 boots 16:51:56 ok, fine. so it's on hold 16:51:59 i probably won't finish in a reasonable time for everyone to wait though 16:54:57 u9000: like i said, it's a bit out of scope for blocker review, i think, unless any significant systems ship with libreboot preinstalled? iirc there aren't any? 16:55:41 there aren't 16:55:58 i just thought it would be good to let y'all know 16:57:04 sure, but just in #fedora-qa or on the test mailing list will be fine :) thanks 16:57:51 oh yeah that's a better place 16:57:52 sorry 16:59:37 ok, thanks for coming, everybody! 17:00:07 thanks adamw :) 17:00:57 #endmeeting