17:00:34 <bcotton_> #startmeeting F34 Beta Go/No-Go meeting 17:00:34 <zodbot> Meeting started Thu Mar 11 17:00:34 2021 UTC. 17:00:34 <zodbot> This meeting is logged and archived in a public location. 17:00:34 <zodbot> The chair is bcotton_. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:34 <zodbot> The meeting name has been set to 'f34_beta_go/no-go_meeting' 17:00:35 <bcotton_> #meetingname F34-Beta-Go_No_Go-meeting 17:00:35 <zodbot> The meeting name has been set to 'f34-beta-go_no_go-meeting' 17:00:42 <bcotton_> #topic Roll Call 17:00:48 <frantisekz> .hello2 17:00:50 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com> 17:00:55 <nirik> morning 17:00:59 <mhroncok> .hello churchyard 17:01:00 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com> 17:01:09 <mhroncok> nirik: morning 17:01:34 <Southern_Gentlem> .hello2 jbwillia 17:01:35 <zodbot> Southern_Gentlem: Sorry, but you don't exist 17:01:40 <Southern_Gentlem> .hello jbwillia 17:01:41 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@gmail.com> 17:02:14 <copperi[m]> .hello2 17:02:17 <zodbot> copperi[m]: Sorry, but you don't exist 17:02:23 <pwhalen> .hello2 17:02:24 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com> 17:03:18 <copperi> .hello2 17:03:19 <zodbot> copperi: copperi 'Jan Kuparinen' <copper_fin@hotmail.com> 17:04:12 <bcotton_> well i suppose it's time to do this thing 17:04:19 <bcotton_> #topic Purpose of this meeting 17:04:20 <bcotton_> #info Purpose of this meeting is to check whether or not F34 Beta is ready for shipment, according to the release criteria. 17:04:22 <bcotton_> #info This is determined in a few ways: 17:04:28 <bcotton_> #info 1. No remaining blocker bugs 17:04:29 <bcotton_> #info 2. Release candidate compose is available 17:04:31 <bcotton_> #info 3. Test matrices for Beta are fully completed 17:04:37 <bcotton_> #topic Current status - blockers 17:04:38 <bcotton_> #link https://qa.fedoraproject.org/blockerbugs/milestone/34/beta/buglist 17:04:49 <bcotton_> bad news! the number is not 0. so let's take a look at them... 17:05:03 <bcotton_> #info 2 Proposed Blockers 17:05:04 <bcotton_> #info 5 Accepted Blockers 17:05:10 <bcotton_> #topic (1937308) First login attempt fails on laptop with fingerprint reader 17:05:11 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1937308 17:05:13 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/296 17:05:14 <bcotton_> #info Proposed Blocker, gdm, MODIFIED 17:05:39 * nirik voted in ticket already 17:05:40 <bcotton_> #info In the ticket, bcotton & kevin are +1, sgallagh and nb are -1 17:05:47 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/296 17:05:59 * mhroncok just voted there as well 17:06:02 <mhroncok> +1 it was 17:06:17 <frantisekz> +1 17:06:19 <Southern_Gentlem> +BetaFE -1 Blocker 17:06:34 <nirik> as a side note I was wondering if we should make the beta critera to be able to login with any one of the methods, and final require them all (I think we do this for some other things) 17:06:36 <bcotton_> so my take is that this is a blocker, but worth waiving under the late blocker exception becaues it's a Beta 17:06:41 <Southern_Gentlem> +Fblocker 17:07:19 <bcotton_> it's annoying, but not functionally harmful 17:07:48 * nirik wonders where adamw is. He was around eariler. 17:08:40 <adamw> i'm here 17:08:40 <adamw> oh, we started? 17:08:40 <adamw> i'm sure this meeting used to be like two hours later. 17:08:44 <bcotton_> so by my count, we're at +4, 0, -3 17:09:03 <bcotton_> adamw: it's usually an hour later but due to calendar quirks we're running it outside of DST for once :-) 17:09:15 <adamw> nirik: note I don't think this is about the method, actually. 17:09:30 <adamw> it's not "it breaks if you try to log in with a fingerprint" 17:09:43 <nirik> "Shutting down, rebooting, logging in and logging out must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. " 17:09:57 <adamw> the presence of the fingerprint reader is key, but you don't actually have to be trying to use it. 17:10:31 <nirik> well, "the mechanisms offered" sounds to me like it should work with all the things offered, but I guess it's wavy 17:10:34 <adamw> i'm definitely +1 FE on this, really meh about blocker 17:11:00 <adamw> what i meant by 'mechanisms' there was really things like 'menu options' 17:11:09 <adamw> i think when i wrote it, fingerprint readers weren't really a thing :P 17:11:19 <Southern_Gentlem> myself its a blocker if we have something else otherwise it shouldnt stop the beta release 17:11:28 <nirik> BTW, for the record, cloing bugs is bad. don't clone bugs. :) 17:11:29 <bcotton_> is anyone who is -1 on this willing to be +1 with the knowledge can we can choose to waive it 17:11:38 <adamw> it's basically trying to say "if the desktop has a "reboot" button it has to work, but we don't actually require it to have one" 17:11:42 <pwhalen> +1 blocker, also +1 to waiving it under the late blocker exception 17:11:43 <mhroncok> Southern_Gentlem: that's a blocker and we can waive it 17:11:55 <adamw> Southern_Gentlem: if you don't think it should block the release, then your vote is -1 blocker :) 17:12:03 <pwhalen> +1 FE for sure 17:12:08 <Southern_Gentlem> adamw, idid 17:13:06 <bcotton_> okay, i think we're at +5, 0, -3 now. i'd like a little more consensus if possible 17:13:17 <lruzicka[m]> .hello lruzicka 17:13:19 <zodbot> lruzicka[m]: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com> 17:14:19 <bcotton_> Southern_Gentlem: i'm confused by your statements. you say it's a blocker if we have something else, but you also say it's not a blocker. which to me sounds like +1 and you'd be +1 to waive it 17:14:39 <lruzicka[m]> which bug are we talking about, please? 17:14:55 <bcotton_> lruzicka[m]: https://bugzilla.redhat.com/show_bug.cgi?id=1937308 First login attempt fails on laptop with fingerprint reader 17:14:57 <mhroncok> https://bugzilla.redhat.com/show_bug.cgi?id=1937308 17:15:12 <lruzicka[m]> thanks 17:15:33 <Southern_Gentlem> bcotton i do not think its a -1 blocker but i can see why others go the other way 17:16:11 <Southern_Gentlem> for Final yes its a blocker 17:17:08 <bcotton_> lruzicka[m]: thoughts? 17:17:19 <adamw> i guess i'd probably have to say -1 blocker, strictly, as if this were the last blocker we'd probably fudge it for a beta and say 'eh we can just tell people about it' 17:17:24 <lruzicka[m]> How does it look like when I "want to log for the second time" when the first attempt has "frozen" ? 17:17:33 <lruzicka[m]> I do not have fingerprint readers 17:17:39 <adamw> the criterion isn't clearly violated because you can login, as long as you hit esc and try again... 17:18:00 <adamw> from the description it sounds like you get a spinner that spins eternally, and you have to hit esc to get back to the password entry box 17:18:07 <lruzicka[m]> in that case, I am -1 beta blocker, +1 final blocker, +1 common bugs 17:18:08 <nirik> I guess I could change my vote given the explanation of the critera more... but I think perhaps we should revisit it after beta. ;) 17:18:28 <frantisekz> yeah, -1 Beta Blocker, +1 BetaFE then 17:18:30 <Southern_Gentlem> also on first boot how does the fp reader have your creds 17:18:58 <lruzicka[m]> Southern_Gentlem: it does not and that is the problem, I believe 17:19:25 <bcotton_> proposed #agreed BZ 1937308 - RejectedBlocker(Beta) - There is insufficient consensus that this is a blocker (and those who want to say it is also want to waive it), so we will leave it for FinalBlocker consideration 17:19:35 <nirik> ack 17:19:40 <Southern_Gentlem> ack 17:19:44 <pwhalen> ack 17:19:45 <lruzicka[m]> ack 17:19:49 <adamw> i asked benzea to join 17:19:49 <frantisekz> ack 17:19:51 <copperi> ack 17:19:53 <adamw> but it looks like ya'll went on ahead 17:20:12 <adamw> i guess ack 17:20:33 <bcotton_> even if we're no-go today, it doesn't seem like there's an appetite for calling it a blocker for next week. and it already has an FE 17:20:49 <bcotton_> #agreed BZ 1937308 - RejectedBlocker(Beta) - There is insufficient consensus that this is a blocker (and those who want to say it is also want to waive it), so we will leave it for FinalBlocker consideration 17:21:01 <bcotton_> #topic (1924908) Gnome session fails to start with "Oops, something went wrong" on first boot 17:21:02 <Southern_Gentlem> lruzicka[m], i would be more of a blocker if it did 17:21:03 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1924908 17:21:04 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/240 17:21:06 <bcotton_> #info Proposed Blocker, mutter, POST 17:21:45 <bcotton_> no blocker votes on this one yet, so i guess we'll all look at it now 17:22:24 <copperi> I get that message on every boot 17:22:28 <nirik> how long is the 'on no' state? 17:22:34 <lruzicka[m]> Yeah this is something which looks terrible but in the end does not have any impact on the usage 17:22:39 <frantisekz> about 2 minutes nirik 17:22:48 <lruzicka[m]> nirik: from 30 secs to 2 minutes, I guess 17:22:53 <frantisekz> oh, until you go through the initial setup 17:23:05 <nirik> hum, thats longer than many people might wait. 17:23:10 <mhroncok> this indeed look bad but is harmless 17:23:14 <lruzicka[m]> yeah, then you go through the initial setup and problem solved 17:23:15 <bcotton_> yeah 2 minutes might as well be "forever" 17:23:20 <mhroncok> I think we can afford that in beta, but not final 17:23:24 <frantisekz> you see only wallpaper, for like 2 minutes, then gis starts up and there is oh no until you finish the process 17:23:35 <adamw> it's harmless as long as you don't assume it's broken and give up 17:23:42 <frantisekz> there is a fix for it already 17:23:46 <adamw> yeah, for me i just see wallpaper when it's hung 17:23:51 <lruzicka[m]> I have never had to wait 2 minutes, but I saw a bug report today which complained about 2 minutes. Mine took like 30 seconds 17:23:51 <adamw> but it sounds like it might not be the same for everyone? 17:23:52 <nirik> "fedora didn't even boot" power-switch. ;( 17:24:16 <copperi> I don't have delays, only message 17:24:31 <frantisekz> I think it would work just fine on gpus blacklisted for wayland 17:24:37 <bcotton_> i kinda feel like i need to be +1 just for the reputational impact, but i'm willing to be talked out of that 17:25:11 <frantisekz> adamw, bcotton, what are chances for spinning a new compose and repeating go/no-go tomorrow? 17:25:22 <bcotton_> depends on the other blockers 17:25:26 <lruzicka[m]> I am probably sort of fine with both, so I am not going to talk it out of you. 17:25:36 * nirik is still on the fence. 17:25:38 <frantisekz> (also, silverblue x86 is missing, that isn't ideal either) 17:25:52 <bcotton_> if we're good otherwise, i'd be fine with a new RC that only differs with the fix for this 17:26:07 <bcotton_> but we can't really make that call yet 17:26:23 <adamw> i did not check new proposed blockers overnight yet 17:26:24 <frantisekz> mhm, punt this one, look at the others and get back here? 17:26:31 <cmurf> i'm not even sure we have a criterion for this for final let alone beta, but i agree that it looks bad 17:26:39 <bcotton_> adamw: this is 2 of 2 proposed blockers 17:26:48 <adamw> when i went to bed last night this was the thing that made me not request a new candidate 17:26:59 <adamw> whether we accept it as blocker or not i kinda wanted to fix it in the next spin if there was gonna be one 17:27:54 <bcotton_> so it seems like we probably want to call this a blocker and then figure out options after we review the accepted blockers? 17:28:17 <nirik> I guess it technically doesn't break the critera... since you _do_ get a screen after a wait... but bah 17:28:31 <cmurf> exactly 17:28:33 <Southern_Gentlem> yeah lets come back to this one 17:28:44 <cmurf> it has a bad scent to it 17:28:57 <lruzicka[m]> But it really looks awful - however we are still just Beta. 17:29:05 <nirik> I don't see any other proposed blockers... 17:29:18 <adamw> note, we do already have an accepted blocker that isn't fixed in rc12 17:29:19 <adamw> rc1* 17:29:23 <adamw> are people not aware of that? 17:29:32 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1937550 17:29:37 <adamw> it was accepted via ticket vote 17:29:47 <adamw> if we wanted to ship RC1, as well as rejecting everything here, we'd have to waive that 17:29:50 <bcotton_> adamw: i guess i should have started with accepted blockers to save time :-) 17:29:53 <cmurf> haha 17:30:10 <cmurf> so fix mutter and repor-cli and ship it 17:30:14 <cmurf> rc2 17:30:15 <bcotton_> but for now... 17:30:19 <bcotton_> proposed #agreed BZ 1924908 - AcceptedBlocker(Beta) - This bug does not strictly violate any release criteria, but the first-use experience is bad enough that we don't want to ship it. 17:30:24 <adamw> btw, i win the trifecta on that one: I caused, discovered and fixed it. :P 17:30:32 <adamw> nack 17:30:34 <bcotton_> (with the knowledge that we can try again tomorrow possibly) 17:30:35 <adamw> i do not like that 17:30:39 <adamw> makes a mockery of the process 17:31:25 <cmurf> i think we can call it a freeze exception, and agree this one FE should go in along with the fix for report-cli blocker 17:31:28 <mhroncok> ack 17:31:31 <cmurf> FE's don't *have* to go in 17:31:39 <bcotton_> no, i make a mockery of the process. but i think it's within the spirit of the process to say "there are bad things we haven't considered but are worth being blockers" 17:32:07 <adamw> if people really want to take it as a blocker but don't believe it breaks a specific criterion, we either need to propose and accept in principle a change to the criteria, or agree that it violates one of the catchalls 17:32:12 <adamw> bcot: it is not 17:32:15 <mhroncok> fesco has that power, I don't think why bcotton shoudn't have it as well :D 17:32:18 <adamw> the whole point of the blocker process is that we don't do that 17:32:21 <lruzicka[m]> Well, do we need to have blockers to block? Ain't no blockers just one critarion? 17:32:26 <adamw> that's why we spent a lot of time and effort coming up with a concrete set of rules 17:32:41 <cmurf> i agree with adam 17:32:44 <bcotton_> mhroncok: the less power i have, the better ;-) 17:32:46 <nirik> yeah, so lets reject that as a blocker, but +1 FE, and do a rc2 for that and the report thing 17:32:57 <adamw> the established precedent is, if we think something should be a blocker but the criteria don't cover it, we come up with a proposal-in-principle to change the criteria 17:33:14 <nirik> but that means anaconda and gnome change, so a lot of testing to redo... 17:33:26 <cmurf> lorax 17:33:30 <cmurf> and i already tested it :D 17:33:33 <adamw> i would be fine if someone said "let's change the criterion to say whatever's supposed to happen on first boot should happen within a reasonable timeframe and without showing alarming error messages" 17:33:37 <adamw> i would probably +1 a proposal along those lines 17:33:45 <adamw> but i'm not in favour of taking this bug as a blocker without doing that 17:34:18 <cmurf> yeah i'm -1 beta blocker 17:34:27 <mhroncok> let's change the criterion to say whatever's supposed to happen on first boot should happen within a reasonable timeframe and without showing alarming error messages 17:34:53 <Southern_Gentlem> define reasonable timeframe 17:35:03 <Southern_Gentlem> 2minutes? 17:35:04 <nirik> mhroncok: sounds reasonable... :) 17:35:05 <cmurf> there's a devel@ thread for this :P 17:35:09 <lruzicka[m]> Southern_Gentlem: we can have a discussion any time, what that is 17:35:09 <adamw> i knew that was coming :P 17:35:21 <mhroncok> to be fair, it was a bait 17:35:24 <adamw> i'd say that's the kind of thing we could work out in detail on the mailing list though 17:35:42 <bcotton_> i'm not sure i like writing that criterion on the fly, because it seems like there's a lot of nuance we'd want to consider. i'd rather go with the "let's reject this" route and see where we are after reviewing the accepted blockers 17:35:45 <adamw> i'm +1 in principle to mhroncok's proposal, or else i'm also fine with this being -1 blocker +1 fe 17:35:57 <cmurf> exactly it's not ever been something we just wedge into the release criteria following 10 minutes of discussion at blocker review 17:36:00 <lruzicka[m]> it's your proposal, adam, anyway 17:36:19 <bcotton_> i do think there's room for a "this makes us look really bad" fuzzy criterion, but i respect adam's arguments against it 17:36:22 <adamw> yup, but that doesn't mean i'm +1 :D 17:36:35 <lruzicka[m]> Are we generally agreed that the message is too bad for a Beta release? 17:36:50 <Southern_Gentlem> +1 proposal - 1 blocker +fe 17:37:02 <mhroncok> I think this should eb a final blocker and we need that criterion to happen before final 17:37:12 <mhroncok> if not, wa can always ask fesco 17:37:13 <nirik> I think it's a bad look, but we should adjust the critera to avoid it next time. ;) 17:37:13 <cmurf> -1 blocker, +1 FE, bring in this specific FE and the report-cli blocker fix, and make an rc2 17:37:16 <lruzicka[m]> When we are +1 proposal, then we need be +1 blocker :D 17:37:35 <bcotton_> proposed #agreed BZ 1924908 - RejectedBlocker(Beta) - This bug does not violate any release criteria, but we should develop a criterion to address it prior to F34 Final 17:37:35 <cmurf> and it's reasonable to have a final release criteria for excessive delays on first boot 17:37:43 <mhroncok> ack 17:37:44 <nirik> ack 17:37:45 <frantisekz> ack 17:37:46 <Southern_Gentlem> ack 17:37:48 <copperi> ack 17:37:50 <lruzicka[m]> wait 17:38:01 * bcotton_ waits 17:38:10 <lruzicka[m]> so does this mean, we are letting it through into Beta and make sure this will go away on Final? 17:38:22 <nirik> no 17:38:24 <mhroncok> that is my understanding 17:38:29 <mhroncok> but we also have a FE 17:38:37 <bcotton_> potentially. it does have an FE, so if we don't ship RC1, then it can be fixed for Beta 17:38:42 <adamw> what happens depends on other factors 17:38:45 <lruzicka[m]> so we hope to make another RC before we ship to go it away now? 17:38:48 <nirik> it means we aren't considering it a blocker, but it is a FE... which we can pull in. if we want 17:39:42 <lruzicka[m]> but if we dont, this stays in Beta right? Because I really do not know what to think, cause this only looks bad but is not bad. 17:39:51 <lruzicka[m]> I guess I nod to whatever the majority says. 17:40:11 <bcotton_> any nacks to the proposal above? 17:40:18 * bcotton_ looks at adamw in particular 17:40:25 <Southern_Gentlem> looks bad, but no really reason to kill it 17:41:06 <lruzicka[m]> so the global understanding is that if this "stays in" we are still fine about it for Beta? 17:41:25 <bcotton_> i can live with it. i'm not sure i'd call it "fine" :-) 17:41:30 <adamw> ack 17:41:34 <Southern_Gentlem> lruzicka[m], come up with criteria 17:41:36 <lruzicka[m]> ok, then I am ack 17:41:43 <bcotton_> #agreed BZ 1924908 - RejectedBlocker(Beta) - This bug does not violate any release criteria, but we should develop a criterion to address it prior to F34 Final 17:42:01 <bcotton_> adamw: want the #action to propose the criterion in question since you volunteered a first draft? 17:42:12 <lruzicka[m]> Southern_Gentlem: the adam/mrohncok criterion seems fine with me, just expected to place in the Beta frame 17:42:14 <lruzicka[m]> :D 17:42:18 * bcotton_ is not wearing the #action bcotton t-shirt today 17:42:26 <mhroncok> #action bcotton to develop a criterion to address it prior to F34 Final or to delegate it properly 17:42:28 <mhroncok> I am 17:42:38 <cmurf> lol 17:42:38 <mhroncok> :D 17:42:45 <nirik> handy! 17:42:48 <bcotton_> hmm...can non-chairs #action? 17:42:51 <bcotton_> i guess we'll find out :-) 17:42:58 <mhroncok> yes 17:43:09 <bcotton_> .fire mhroncok 17:43:10 <zodbot> adamw fires mhroncok 17:43:11 <lruzicka[m]> zodbot thinks different 17:43:24 <mhroncok> ok, now you got me. not sure 17:43:29 <bcotton_> okay, let's move on to the accepted blockers already in progress 17:43:38 <bcotton_> #topic (1933454) /etc/resolv.conf is not a symlink 17:43:39 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1933454 17:43:41 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/265 17:43:42 <bcotton_> #info Accepted Blocker, anaconda, ON_QA 17:44:15 <bcotton_> is this one in the RC? and if so, has anyone verified it? 17:44:40 <adamw> yeah, this is in the RC 17:44:40 <bcotton_> i'm guessing it isn't since it only hit 17:44:41 <cmurf> itis in the rc i have verified it 17:44:51 <bcotton_> whoops, i meant to correct myself instead of hitting enter 17:44:53 <adamw> cmurf and I verified the fix with the live image openQA built 17:44:57 <bcotton_> oh well. i am wrong for eternity 17:45:03 <adamw> ...and i guess cmurf verified it with the RC :) so nothing much to do here 17:45:20 <bcotton_> #info Fix is verified in RC1 17:45:36 <lruzicka[m]> in my RC installed, this is a symlin 17:45:37 <lruzicka[m]> k 17:45:42 <bcotton_> #topic (1935331) unable to login on laptop with fingerprint reader 17:45:43 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1935331 17:45:45 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/292 17:45:47 <bcotton_> #info Accepted Blocker, authselect, ON_QA 17:45:54 <cmurf> i'm running unmodified RC1 right now on the laptop i'm typing on :P so... cheater! 17:47:01 <cmurf> was this fixed with authselect-1.2.2-5 or -6? doesn't matter, rc1 has -6 on it 17:47:17 <lruzicka[m]> didn't we say this had been fixed? 17:47:38 <bcotton_> we did now 17:47:40 <bcotton_> #info Fix is verified in RC1 17:47:55 <bcotton_> #topic (1937550) Crash reporting does not work in text installer mode due to missing report-cli 17:47:57 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1937550 17:47:58 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/297 17:48:00 <bcotton_> #info Accepted Blocker, lorax, MODIFIED 17:48:33 <nirik> this is the one not in rc1 17:48:41 <cmurf> fix is not in rc1, but i tested it by adding just /usr/bin/report-cli to rc1 and then it works 17:48:54 <adamw> yeah, i found this in RC1 testing 17:49:10 <adamw> openQA will have built an image with the fix included by now, i meant to confirm that it was fixed last night but didn't get the roundtuits 17:49:18 <adamw> cmurf's test strongly indicates it ought to be fixed, though 17:49:25 <bcotton_> adamw: is that something you can check quickly now? 17:49:55 <Southern_Gentlem> bcotton_, is this the last on the list ? 17:50:56 <bcotton_> Southern_Gentlem: there's one more not in VERIFIED 17:51:06 <Southern_Gentlem> ok 17:51:51 <Southern_Gentlem> can we move on to it while waiting for adamw report on this 17:52:06 <adamw> bcotton_: it'll take a bit of time as i need to download the image 17:52:06 <adamw> starting it now 17:52:07 * pwhalen marks it verified 17:52:09 <adamw> so let's move on for now 17:52:10 <bcotton_> that's why i asked adamw if it could be checked quickly 17:52:14 <bcotton_> okay, cool 17:52:21 <adamw> it's not really important to check it right now anyway, is it? since the fix isn't in the rc 17:52:29 <bcotton_> fair enough 17:52:38 <bcotton_> #topic (1930977) [abrt] gnome-shell: nouveau_fence_signalled(): gnome-shell killed by SIGSEGV 17:52:39 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1930977 17:52:41 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/241 17:52:42 <bcotton_> #info Accepted Blocker, mesa, VERIFIED 17:52:50 <bcotton_> this is VERIFIED, nothing more to see 17:52:57 <bcotton_> #topic (1936991) Failed to post KMS update: drmModeAtomicCommit: Invalid argument 17:52:59 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1936991 17:53:00 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/294 17:53:02 <bcotton_> #info Accepted Blocker, mutter, ON_QA 17:53:13 <pwhalen> Now VERIFIED 17:53:27 <bcotton_> magic! 17:53:37 <bcotton_> #info This is now VERIFIED 17:53:59 <bcotton_> oh look, a new proposed blocker 17:54:06 <Southern_Gentlem> no easy fixes for these 2 exist correct ? 17:54:10 <bcotton_> #topic (1937785) Fedora install failed with qemu on a P9 PowerPC "couldn't claim memory" 17:54:11 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1937785 17:54:13 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/301 17:54:15 <bcotton_> #info Proposed Blocker, grub2, NEW 17:54:48 <lruzicka[m]> Hah, a late time blocker :D 17:54:49 <adamw> uh, ppc64le still isn't blocking, is it? 17:54:58 <bcotton_> i just looked, it is not 17:54:58 <Southern_Gentlem> -1 blocker not a release blocking arch 17:55:00 <bcotton_> that makes it easy 17:55:09 <adamw> yup 17:55:10 <adamw> -1 17:55:11 <pwhalen> I don't this can be a blocker, but :( 17:55:11 <frantisekz> -1 17:55:15 <adamw> per https://fedoraproject.org/wiki/Releases/34/ReleaseBlocking we only block on x86_64 and aarch64 17:55:18 <adamw> +1 FE 17:55:21 <lruzicka[m]> -1 17:55:21 <pwhalen> -1 blocker 17:55:31 <nirik> -1 blocker, +1 FE 17:55:33 <mhroncok> +1 FE, -1 blocker 17:55:34 <Southern_Gentlem> +1 fe 17:55:42 <copperi> -1 +1 fe 17:55:58 <pwhalen> +1 fe 17:56:01 <lruzicka[m]> +1 fe because this is what he wanted to request anyway 17:56:09 <bcotton_> proposed #agreed BZ 1937785 - RejectedBlocker(Beta), AcceptedFE(Beta) - ppc64le is not a blocking architecture, but this is worth fixing if we can 17:56:13 <frantisekz> ack 17:56:16 <Southern_Gentlem> ack 17:56:18 <lruzicka[m]> ack 17:56:25 <copperi> ack 17:56:33 <mhroncok> ack 17:56:42 <adamw> ack 17:57:05 <bcotton_> #agreed BZ 1937785 - RejectedBlocker(Beta), AcceptedFE(Beta) - ppc64le is not a blocking architecture, but this is worth fixing if we can 17:57:26 <bcotton_> #topic Current status - blockers 17:57:42 <bcotton_> so... this basically leaves us with just the lorax blocker, right? 17:57:46 <Southern_Gentlem> ok i am lost what about the gnome-shell and mutter before? 17:57:48 <nirik> so we have to decide that one blocker right? 17:58:13 <pwhalen> Southern_Gentlem: those are verified 17:58:39 <Southern_Gentlem> which means fix exist and in rc1? 17:58:55 <nirik> fix exists, in rc1 and verified to actually fix the issue. :) 17:59:01 <Southern_Gentlem> ok 17:59:16 <bcotton_> #info One accepted blocker remains 17:59:34 <bcotton_> #topic Current status - test matrices 17:59:35 <bcotton_> #link https://fedoraproject.org/wiki/Category:Fedora_34_Test_Results 17:59:41 <Southern_Gentlem> and thats the one adamw is checking on? 17:59:46 <bcotton_> yes 17:59:55 <adamw> right 17:59:56 * nirik runs for more coffee 18:00:01 <adamw> so for matrices, uh 18:00:56 <adamw> we're missing a couple of base tests on aarch64 18:01:10 * pwhalen looks 18:01:14 <adamw> (though it's extremely unlikely either is broken) 18:01:34 <adamw> i'm trying to remember why we don't have package install/remove automated...oh well 18:02:16 <lruzicka[m]> I thought we did have it, but if not, I will take it 18:02:32 <pwhalen> *sigh* Sorry, I missed those 18:02:34 <lruzicka[m]> to make it before final 18:03:01 <adamw> we're missing the same couple tests on cloud local, and we don't have any non-local cloud tests for x86_64 18:03:59 <adamw> we're missing a couple of AD tests, though alciregi did one at least and chances of the other two working if that one works and the other two work for freeipa is high 18:04:08 * pwhalen is running the add/remove now 18:04:32 <adamw> so we're not quite at full coverage but fairly close, and we could knock out most of the missing tests quickly. but probably not worth rushing to do them unless someone seriously wants to propose waiving the blocker and releasing rc1 18:05:48 <bcotton_> i mean, it's not the worst blocker in the world. but i'd rather get an rc2, i think 18:05:55 <Southern_Gentlem> i do want to propose we table this meeting til 2pm EST tomorrow and see if we can do a rc2 to solve the issues 18:06:03 <adamw> i personally would quite like to fix a lot of the bugs for an rc2 18:06:09 <adamw> even if that means not rushing to do it tomorrow 18:06:20 <adamw> let's close out this topic first though? 18:06:28 <bcotton_> agreed 18:06:39 <bcotton_> any questions or comments on the test matrices? 18:07:44 <bcotton_> hearing none... 18:07:50 <bcotton_> #topic Current status - RC 18:08:09 <bcotton_> #info RC1 is the current candidate 18:08:28 <bcotton_> are silverblue and python classroom lab missing on all arches or just some? 18:09:28 <Southern_Gentlem> is silverblue a blocker 18:09:38 <adamw> no, it's still not a release-blocking image 18:09:40 <nirik> silverblue is only missing on x86_64 18:09:51 <adamw> did we figure why it's missing yet? 18:10:49 * nirik looks 18:11:22 <adamw> and to be clear: https://bugzilla.redhat.com/show_bug.cgi?id=1937550 is not fixed in RC1 and is an accepted blocker 18:11:26 <adamw> so unless it gets waived we cannot ship RC1 18:11:28 <nirik> installing flatpaks... 18:11:46 <adamw> i found the error there but didn't get past that 18:11:49 <nirik> but I am not sure why. Possibly a transitory thing because aarch64 worked 18:11:50 <adamw> posted it in the failed-composes ticket 18:12:09 <bcotton_> #info Silverblue is missing on x86_64 due to a failure during flatpak installs 18:12:28 <bcotton_> #info Python Classroom Lab is also missing 18:12:45 <bcotton_> #info RC 1 does not contain a fix for accepted blocker BZ1937550 18:12:49 <Southern_Gentlem> i3 still doesnt have wireless support 18:13:18 <mhroncok> > Python Classroom Lab is also missing 18:13:20 <mhroncok> not again 18:14:08 <nirik> the only python classroom thats missing is the arm one 18:14:10 <nirik> armv7 18:14:16 <mhroncok> yes, that is OK 18:14:32 <mhroncok> I was not able to decipher the problem 18:14:35 <nirik> and I think thats also been failing in rawhide/branched... but I am not sure why 18:14:38 <Southern_Gentlem> so are we pushing a week or going to try tomorrow 18:14:39 <mhroncok> there is a screenshot with no error on it 18:14:44 <kalev> do you guys have a link to the failed silverblue? I can't find it in https://pagure.io/releng/failed-composes/issues 18:15:12 * mhroncok is fine to srop the armv7 lab and switch to aarch, just didn't get to it 18:15:15 <mhroncok> *drop 18:15:17 <nirik> kalev: https://koji.fedoraproject.org/koji/taskinfo?taskID=63475299 18:15:23 <kalev> nirik: thanks 18:15:51 <bcotton_> anything else on the RC before we figure out what to do about it? 18:16:34 <kalev> that's a configuration error somewhere in pungi, someone sedded f33/f34/ wrongly so it's trying to install a nonexistant f34 flatpak runtime 18:16:51 <nirik> kalev: ha. whoops 18:16:56 <bcotton_> yay, an easy fix! 18:17:00 <bcotton_> #topic Go/No-Go decision 18:17:14 <bcotton_> okay, so before we get too far down the rabbit hole... 18:17:25 <bcotton_> does anyone want to propse that we waive BZ 1937550 and ship RC1? 18:17:38 <bcotton_> (i do not, but i want to give others the option) 18:18:18 <kalev> next time, I think it would be nice to have an earlier compose attempt even if all blockers aren't lined up, so that there's time to fix issues like this that only show up when a compose is done :) 18:18:21 * Southern_Gentlem shakes head NO 18:18:37 <kalev> (that was re the silverblue failure) 18:18:56 <bcotton_> agreed, kalev 18:18:59 <nirik> bcotton_: I don't. I guess we could under the 'it was too soon' rule, but I don't personally want to. 18:19:25 <bcotton_> okay, no one is jumping up to do this, so the next question becomes what do we do for RC2 18:19:49 <bcotton_> i'd be okay with trying again tomorrow if it only contained a fix for the lorax issue. the more we add, the less okay i am with that 18:19:49 <lruzicka[m]> I'll say, do not rush it. 18:20:01 <Southern_Gentlem> i think we push a week so we there is time for the rc2 and it to be tested 18:20:24 <mhroncok> well, we want to add the intial gnome error message fix if possible, right? 18:20:30 <copperi> I am+1 on adamw's earlien proposal 18:20:31 <bcotton_> yeah, the "early target date" is generally pretty aspirational 18:20:41 <adamw> yeah honestly i would like to fix a lot of the FEs 18:20:43 <bcotton_> mhroncok: i certainly would like to get that in 18:20:45 <adamw> and even consider pulling in the newer plasma 18:20:45 <adamw> and get silverblue in 18:20:47 <nirik> The only reason I would want to do a quick rc2 and try soon is our auth system rollout... but we can see about pushing that a week too I guess. 18:20:52 <pwhalen> I would prefer we not ask for hero testing by tomorrow. If we can roll over the results with a target change, ok. if not we should slip a week and pull in the other FE's 18:21:02 <adamw> honestly i feel like i whiffed a bit on rc1 and should've got some fixes in it that we didn't, i'd like to take a bit of time and get a better build 18:21:36 <Southern_Gentlem> rc1==NO-GO 18:21:50 * pwhalen updated add/remove package test for aarch64 workstation 18:21:59 <lruzicka[m]> +1 to take time, let's say until Tuesday and then make RC2 on Tusday night to have like 2 days of testing 18:21:59 <Southern_Gentlem> adamw, nope you can only do what you can do 18:22:20 <adamw> Southern_Gentlem: i kinda forgot to look through the FEs carefully when requesting rc1 :( there was stuff we could've got in that i missed 18:22:34 <Southern_Gentlem> adamw, you are only human 18:22:39 <adamw> we can probably do an RC sooner than tuesday, i'll try and get it today or tomorrow 18:22:54 <adamw> but i'd want to put in quite a lot of change, more than we could safely hero-test 18:23:01 <bcotton_> is there anyone here *not* in favor of waiting until next week (i.e. really really wants to try again tomorrow) 18:23:05 <nirik> yeah, rc2 as soon as we can reasonably 18:23:10 * pwhalen wipes sweat from his brow 18:23:36 <nirik> pwhalen: does anything on the python classroom leap out: https://koji.fedoraproject.org/koji/taskinfo?taskID=63480680 seems like it booted and then just never started anaconda? 18:23:46 <adamw> we haven't been through the FEs in detail but there's like four or five others which are "well, it's not a BLOCKER, but...it'd really be good to fix it" kinda things 18:25:09 <bcotton_> #agreed Fedora Linux 34 Beta is NO-GO 18:25:10 <bcotton_> #info The next F34 Beta Go/No-Go meeting will be Thursday, 2021-03-18 at 1700 UTC 18:25:12 <bcotton_> #info F34 Beta shifts to target release date #1: Tuesday 2021-03-23 18:25:24 <bcotton_> #action bcotton to announce decision 18:25:36 <bcotton_> #topic Open floor 18:25:38 <bcotton_> Anything else we need to discuss before closing? 18:26:11 <bcotton_> (also: note that since much of the Americas changes to daylight saving time on Sunday, the next meeting will feel an hour later for many of you) 18:26:23 <nirik> I'll see if we can't push the new account system rollotu back. Will see what pushback I get on that. ;) 18:26:53 <mhroncok> nirik: I assumed beta freeze implies for infra as well, no? 18:27:02 <lruzicka[m]> I have found a problem with Abrt today: https://bugzilla.redhat.com/show_bug.cgi?id=1936898 18:27:20 <lruzicka[m]> have you seen it and is it worth an FE for Beta? 18:27:35 <nirik> yeah, but they have a number of scheduling things to balance and they were planning on next week. ;( will see. 18:27:40 <pwhalen> nirik: 00:04:48,552 ERR anaconda:anaconda: ui.tui.hubs.summary: Not enough space in file systems for the current software selection. An additional 2.74 GiB is needed. 18:27:44 <lruzicka[m]> no, not this one: https://bugzilla.redhat.com/show_bug.cgi?id=1937783 18:27:52 <nirik> pwhalen: ah ha. easyfix 18:28:02 <pwhalen> heh :) 18:28:08 <mhroncok> nirik: do I need to do anything? 18:28:08 <lruzicka[m]> this one is more important (1937783) 18:28:10 <bcotton_> nirik: i am happy to flex on anyone who argues against you :-) 18:28:58 <bcotton_> lruzicka[m]: if you nominated it, i'd give it a +1FE 18:29:06 <nirik> mhroncok: yeah, add space in the kickstart... 18:29:37 <lruzicka[m]> bcotton_: II nominated it for final blocker, but could renominate for beta FE, too 18:31:14 <bcotton_> okay, it sounds like we're done here 18:31:19 <bcotton_> thanks everyone for a valiant effort :-) 18:31:42 <adamw> thanks for trying to impose order on chaos, bcotton :P 18:31:42 <lruzicka[m]> no problem 18:31:43 <frantisekz> thanks bcotton for leading the meeting :) 18:31:46 <bcotton_> we'll try this again next week 18:31:54 <adamw> i will try and put together an rc2 request tonight or tomorrow 18:31:57 <lruzicka[m]> ok, see you then 18:31:59 <bcotton_> #endmeeting