16:02:15 <adamw> #startmeeting F34-blocker-review
16:02:15 <zodbot> Meeting started Mon Apr 12 16:02:15 2021 UTC.
16:02:15 <zodbot> This meeting is logged and archived in a public location.
16:02:15 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:15 <zodbot> The meeting name has been set to 'f34-blocker-review'
16:02:22 <adamw> #meetingname F34-blocker-review
16:02:22 <zodbot> The meeting name has been set to 'f34-blocker-review'
16:02:22 <frantisekz> .hello2
16:02:23 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:02:26 <adamw> #topic Roll Call
16:02:33 <adamw> who's around for blocker review fun?
16:02:34 <frantisekz> .hello2
16:02:34 <pwhalen> .hello2
16:02:35 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:02:36 <adamw> apart from my cat?
16:02:37 <bcotton> .hello2
16:02:38 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
16:02:41 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:02:57 <adamw> who does not know much about bootloaders but has definite opinions about who gets to sit on the space bar
16:03:14 <bcotton> SPONGEBOB SQUARE PANTS!
16:03:25 <adamw> #chair spongebob
16:03:25 <zodbot> Current chairs: adamw spongebob
16:05:26 <adamw> there now follows a short interval in which i update the offline vote counts in a panic
16:05:30 <adamw> please talk among yourselves
16:06:34 * coremodule lurks, but is pulled thin today. Any chance someone else can take the secretarialization this week?
16:07:14 <adamw> i can do it after the meeting if no-one else wants to
16:07:41 <coremodule> adamw, I can do it, it will just happen several hours after the end, which I know isn't ideal if we're trying to get an RC
16:08:06 <coremodule> depending on the outcome of the blockers of course
16:08:38 <coremodule> If you're okay with that, I will act as secretary, but it won't happen any earlier than 3:30pm MST...
16:09:17 <frantisekz> coremodule: I can take care of that right away
16:09:28 <coremodule> Thank you frantisekz :)
16:09:33 <frantisekz> np :)
16:09:38 <bcotton> frantisekz++
16:10:18 <adamw> thanks frantisekz
16:10:20 <adamw> ok, boilerplate alert
16:10:41 <adamw> #chair frantisekz pwhalen
16:10:41 <zodbot> Current chairs: adamw frantisekz pwhalen spongebob
16:10:50 <adamw> #topic Introduction
16:10:56 <adamw> Why are we here?
16:11:02 <adamw> #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:11:06 <adamw> #info We'll be following the process outlined at:
16:11:10 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:11:15 <adamw> #info The bugs up for review today are available at:
16:11:20 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:11:25 <adamw> #info The criteria for release blocking bugs can be found at:
16:11:30 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:11:34 <adamw> #link https://fedoraproject.org/wiki/Fedora_34_Beta_Release_Criteria
16:11:40 <adamw> #link https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria
16:11:45 <adamw> #info we have"
16:11:47 <adamw> #undo
16:11:47 <zodbot> Removing item from minutes: INFO by adamw at 16:11:45 : we have"
16:11:52 <adamw> #info for Final, we have:
16:12:04 <adamw> #info 5 Proposed Blockers
16:12:04 <adamw> #info 6 Accepted Blockers
16:12:08 <adamw> #info 7 Proposed Freeze Exceptions
16:12:08 <adamw> #info 8 Accepted Freeze Exceptions
16:12:16 <adamw> 5, 6, 7, 8!
16:12:23 <frantisekz> :D
16:12:30 <adamw> #info frantisekz will secretarialize
16:12:38 <adamw> #topic Proposed Final blockers
16:12:54 <cmurf> hey maybe end the meeting in the other channel, wooo hooo
16:12:56 <adamw> oh bah just a sec i have to kick blockerbugs
16:12:59 <adamw> thanks cmurf
16:15:22 <adamw> #topic (1947446) F34 plasma theming should use new BreezeTwilight
16:15:28 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1947446
16:15:33 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/341
16:15:38 <adamw> #info Proposed Blocker, kde-settings, ON_QA
16:15:49 <adamw> #info Ticket vote: FinalBlocker (+1,0,-2) (+bcotton, -adamwill, -frantisekz)
16:15:53 <adamw> #info Ticket vote: FinalFreezeException (+3,0,-0) (+bcotton, +adamwill, +frantisekz)
16:16:18 <adamw> as noted in the bug i'm -1 as this doesn't really break any criteria. we did accept it as an FE already though.
16:16:48 <frantisekz> yeah, -1 Blocker, it doesn't break and/or violate any criteria
16:16:53 <bcotton> so i generally defer to the responsible teams on this kind of thing, which is why i was +1, but i am 100% not willing to argue against those who are -1
16:17:41 <adamw> i usually would, but in this case the justification was clearly not in line with the policies :D we do have an artwork criterion, but it fairly clearly doesn't cover theming
16:17:49 <adamw> we could discuss whether it should, but for right now it seems clear we don't cover this
16:18:27 <bcotton> yeah, let's not waste time arguing about this when we can argue about so much else
16:18:37 <bcotton> that sentence almost made sense!
16:18:51 <adamw> ^^^my life
16:18:52 <pwhalen> -1 B, +1 FE
16:19:30 * marcdeop /me doesn't really know the implications of B and/or FE (anybody has a link where it explains it?)
16:20:02 <adamw> blocker means we don't release till it's fixed
16:20:04 <pwhalen> marcdeop: sorry, B=Blocker, FE=Freeze Exception
16:20:27 <adamw> FE means we will pull in a freeze for it as long as we're still working on the final RC, but we won't hold the release for it, or respin for it alone (we only respin if at least one blocker still needs fixing, by policy)
16:20:33 <adamw> pull in a fix* for it
16:21:11 <marcdeop> I also found this: https://pagure.io/fedora-qa/blocker-review :-) thanks for the info guys
16:22:44 <adamw> ok, so i think we are -3, can i amend you to a 0 in the interests of moving on, bcotton? :D
16:22:52 <bcotton> please :-)
16:22:53 <marcdeop> go on with the meeting, if I need help somebody can explain me out of meeting time
16:24:07 <adamw> proposed #agreed 1947446 - RejectedBlocker - this does not violate any of the criteria as currently formulated. Note: already accepted as a freeze exception issue
16:24:28 <bcotton> ack
16:24:43 <frantisekz> ack
16:25:09 <pwhalen> ack
16:25:33 <adamw> #agreed 1947446 - RejectedBlocker - this does not violate any of the criteria as currently formulated. Note: already accepted as a freeze exception issue
16:25:37 <adamw> #topic (1948092) dasbus.error.DBusError: 'NoneType' object has no attribute 'upper'
16:25:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1948092
16:25:47 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/350
16:25:52 <adamw> #info Proposed Blocker, python-blivet, ASSIGNED
16:27:50 <bcotton> so the maintainers think this one is a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1945914
16:28:23 <bcotton> which is an accepted FE already
16:28:55 <cmurf> i'll get around to testing it eventually
16:29:16 <cmurf> either the updates.img or a new anaconda build that incorporates it
16:29:54 <cmurf> we can punt and i'll just mark this bug as a dup once i confirm it
16:30:06 <adamw> that seems reasonable
16:30:17 <cmurf> or even just mark it as a dup now, doesn't matter
16:30:47 <bcotton> cmurf: did you see kparal's question: does this also happen if you create 1M, 10M, 100M disk? Or does it happen just for extremely small (<1kB) disks?
16:31:47 <adamw> the "duplicate" bug says the issue is LVs with a partition table (which is unusual)
16:32:31 <lruzicka[m]> ain't it "on a disk with GPT partition table" ?
16:32:49 <lruzicka[m]> which means that any MBR disks will not cause this?
16:33:07 <cmurf> bcotton: i saw the question but don't know, i only ran into it by accident
16:33:15 <cmurf> i did 'truncate -s 100' instead of 'truncate -s 100g'
16:33:30 <cmurf> so it was a 100 byte backing file, which is, unusual
16:33:35 <adamw> lruzicka: the way it's written it sounds like literally the LV itself has a partition table
16:34:24 <bcotton> yeah. i'm kind of inclined to say "this isn't a thing that real people will actually hit so let's not block on it"
16:34:34 <bcotton> with the implication that cmurf is a robot, not a real person
16:34:47 <cmurf> lol
16:34:50 <adamw> i wouldn't be surprised if cmurf's case turns out not actually to be the same as the "dupe", but both odd corner cases
16:35:29 <cmurf> yea
16:35:43 <lruzicka[m]> adamw: yeah, comment 17 says the GPT thing and 18 this weird stuff, but that can be just a language mistake
16:35:52 <cmurf> but it's an invalid configuration and the isntaller crashes which is what the criterion covers
16:36:33 <adamw> it does, but i think it's reasonable to have some wiggle room for a 100 byte backing file or something equally odd :D
16:36:40 <adamw> anyhow, punt to figure it out seems reasonable
16:36:45 <cmurf> i agreeeee
16:37:14 <cmurf> hilariously it's 100 bytes in the host, and 512 bytes in the guest
16:37:29 <cmurf> there's some minimum size applied to the guest, that might even be where the bug is
16:38:47 <lruzicka[m]> ok, punt
16:38:48 <bcotton> i'm okay with punting, but since go/no-go is in 72 hours, i will be strongly -1 at that point unless something changes significantly
16:39:16 <bcotton> (72 hours and 21 minutes if we're being pedantic, which...)
16:39:18 <adamw> proposed #agreed 1948092 - punt (delay decision) - we agreed to delay this while we get more detail on exactly what the failure case is, and if it's a dupe of 1945914 (or at least fixed by the same change)
16:39:27 <bcotton> ack
16:39:46 <pwhalen> ack
16:39:49 <adamw> cmurf: yeah, as bcotton says it'd be super useful to have the info fast :D
16:39:53 <frantisekz> ack
16:41:55 <lruzicka[m]> ack
16:41:58 <adamw> #agreed 1948092 - punt (delay decision) - we agreed to delay this while we get more detail on exactly what the failure case is, and if it's a dupe of 1945914 (or at least fixed by the same change)
16:42:12 <adamw> ok, moving onto
16:42:19 <adamw> #topic Proposed Final freeze exception issues
16:42:25 <adamw> #topic (1941982) [abrt] gjs: ObjectInstance::~ObjectInstance()(): gjs-console killed by SIGTRAP
16:42:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1941982
16:42:33 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/343
16:42:38 <adamw> #info Proposed Freeze Exceptions, gjs, POST
16:42:43 <adamw> #info Ticket vote: FinalFreezeException (+1,1,-0) (+adamwill, kalev)
16:42:50 <adamw> so this is awkward
16:43:12 <adamw> the bug looks bad - apps crashing on shutdown, which means people see crash notifications and feel bad - but the fix looks insanely large and complicated
16:43:26 <adamw> looks to be one of those things where making sure X gets done before Y turns out to involve rewriting half of the codebase
16:43:40 <adamw> so at this point in the cycle it might be reasonable to be -1 just on that basis
16:43:53 <adamw> when i voted +1 i was sort of expecting a relatively simple fix to show up the next day, but not so much.
16:44:06 <frantisekz> let's punt then?
16:44:32 <frantisekz> we can decide if it gets merged upstream and after some ore testing?
16:44:42 <bcotton> yeah, this one scares me a little bit. i think i'd rather wait and let upstream get the fix sorted out and then let it land as an update
16:45:21 <bcotton> i'm okay with punting and seeing what happens if we're no-go on Thursday
16:45:21 <lruzicka[m]> how long does the fix take to take?
16:45:29 <frantisekz> since the main maintainer of gjs isn't too happy with it right now, I wouldn't pull this in just yet
16:45:32 <lruzicka[m]> take -> make
16:45:54 <adamw> lruzicka: the PR has been being worked on for like a week now
16:45:55 <frantisekz> I guess I don't have any crystal balls around lruzicka :/ :D
16:45:57 <lruzicka[m]> should not we block on this?
16:45:58 <adamw> it seems to keep getting bigger :D
16:46:10 <adamw> lruzicka: on what ground?
16:46:34 <lruzicka[m]> adamw: crash messages appear?
16:46:50 <lruzicka[m]> frantisekz: well, I do not know which balls you have :D
16:47:57 <adamw> lruzicka: the criterion says only on clean boot and log in iirc
16:48:02 <cmurf> i've seen it
16:48:05 <adamw> i.e. it doesn't cover as far as "actually run any applications"
16:48:15 <adamw> what do you think we are, some sort of reliable os? WE ARE FEDORA!!!
16:48:17 <lruzicka[m]> adamw: ah, ok
16:48:22 <cmurf> looks like some apps just crash soon after the desktop session is being torn down or something like that
16:49:11 <cmurf> if there's evidence the crashes result in data loss, it might be covered under that
16:49:25 <cmurf> but i'm not sure what signals the apps get to quit before the logout anyway
16:50:00 <adamw> the crash happens just on app exit
16:50:01 <cmurf> i'm using the signal flatpak which pretty much always crashes on logout, i haven't lost any messages
16:50:05 <adamw> not on logout (well, maybe then too)
16:50:14 <cmurf> huh ok
16:50:16 <cmurf> i haven't seen that
16:50:40 <adamw> seems to affect weather, maps and sound recorder
16:50:49 <adamw> maybe only native-ish GNOME apps?
16:50:54 <cmurf> ok
16:51:02 <cmurf> well -1 blocker and -1 FE
16:51:05 <adamw> (which would make sense since, well, they use gjs...)
16:51:26 <adamw> i think punting to give us the option of accepting if we slip and the fix looks promising makes sense
16:52:10 <frantisekz> +1 punt, we might slip a bit, see the ix is harmless and decide to pull it in
16:52:16 <frantisekz> ix/fix
16:52:22 <pwhalen> +1 punt here as well
16:52:44 <lruzicka[m]> no rant with punt
16:53:45 <adamw> proposed #agreed 1941982 - punt (delay decision) - we are punting with intent: this means we won't pull in a big hairy potential fix this week, but if we wind up slipping this week, it gives us the option to possibly pull it in for the next go-round
16:54:02 <bcotton> ack
16:54:09 <pwhalen> ack
16:54:39 <frantisekz> ack
16:54:48 <lruzicka[m]> ack
16:56:49 <adamw> #agreed 1941982 - punt (delay decision) - we are punting with intent: this means we won't pull in a big hairy potential fix this week, but if we wind up slipping this week, it gives us the option to possibly pull it in for the next go-round
16:56:58 <adamw> #topic (1948576) update to 5.11.12 for 64k page size fixes on ppc64le
16:57:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1948576
16:57:09 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/351
16:57:13 <adamw> #info Proposed Freeze Exceptions, kernel, ON_QA
16:58:06 <cmurf> one upstream report on linux-wireless@ that 5.11.12 breaks iwlwifi on some models (intel wireless)
16:58:26 <cmurf> so we might be wary...
16:59:02 <frantisekz> cmurf, do you have link to that? isn't it fixed in .13?
16:59:10 <cmurf> it's not fixed in 5.11.13
16:59:33 <frantisekz> hmm, okay
16:59:45 <Eighth_Doctor> -1 FE on that reason alone
16:59:59 <cmurf> i had a URL
17:00:31 <cmurf> https://lore.kernel.org/linux-wireless/b606a193-3e4d-cdd7-a2e4-c5b801e2f8fc@gmail.com/T/#t
17:02:00 <cmurf> i have a different model intel wifi so i'm going to try 5.11.12/13 in a bit
17:02:23 <cmurf> 5.12.rc-6 is ok so i suspect the model i've got won't be affected
17:03:20 <cmurf> and that upstream report shows other things were updated so... i can't really assess the risk of wifi breaking but it's making me want more testing of 5.11.12
17:03:30 <frantisekz> I'd definitely rather have borked amdgpu on non-x86 than broken some intel wifi
17:03:53 <frantisekz> we can punt this one too? some more testing and information can arise...
17:04:58 * cmurf is testing this anaconda 100 byte image thing
17:05:05 <adamw> well, if we punt it's effectively a -1 for this week
17:05:06 <pwhalen> +1 punt
17:05:23 <frantisekz> +1 punt
17:06:01 <frantisekz> adamw: that's something I am aiming at with this, not straight reject it, but don't pull it in until we know more
17:06:02 <lruzicka[m]> +1 punt
17:06:36 <adamw> 5.11.12 is going stable for f32 and is stable for f33 already
17:07:15 <adamw> but if punt's the vote, we can go with that...
17:07:48 <frantisekz> (I mean, I don't see it too probable for a go this thursday, we might know more before the next go/no-go)
17:09:43 <pwhalen> hrm, ok. And no issues reported with wireless in either f32 or 33?
17:10:18 <adamw> not in fedora update system, no
17:11:08 <pwhalen> and the reporter mentions - "I immediately tried downgrading again, but to no avail."
17:11:26 <adamw> it sounds like the hardware got in a bad state
17:11:32 <adamw> they needed some kind of reset to get it back
17:11:46 <adamw> i suspect a full shutdown and cold boot would've worked too, but they used some windows thing
17:12:34 <cmurf> sample size of 1
17:12:36 <cmurf> and not fedora
17:12:47 <cmurf> and involves firmware blobs so who knows
17:13:00 <frantisekz> well then, +1 FE
17:13:09 <cmurf> but when there are wifi regression? first i hear of it is reddit a week after it goes stable :P
17:14:08 <adamw> i did google around and didn't see any other reports
17:14:21 <cmurf> yep so it could just be a one off
17:15:15 <pwhalen> +1 FE here too
17:15:33 <bcotton> +1 FE
17:17:02 <adamw> proposed #agreed 1948576 - AcceptedFreezeException (Final) - we are a bit worried about a potential intel wifi issue, but there seems to be only one outlying upstream report and no Fedora reports. 5.11.12 is going stable for F32 and F33. so pulling it into F34 for this and other fixes seems reasonable
17:17:31 <pwhalen> ack
17:18:56 <cmurf> ok the anaconda bug 1948092 is a dup
17:19:01 <cmurf> the updates image does work
17:19:28 * cmurf has updated the bug
17:19:47 <lruzicka[m]> ack
17:21:07 <adamw> great
17:21:13 <adamw> #agreed 1948576 - AcceptedFreezeException (Final) - we are a bit worried about a potential intel wifi issue, but there seems to be only one outlying upstream report and no Fedora reports. 5.11.12 is going stable for F32 and F33. so pulling it into F34 for this and other fixes seems reasonable
17:21:25 <adamw> #topic (1946950) Samba RPC daemons leak memory
17:21:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1946950
17:21:35 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/334
17:21:40 <adamw> #info Proposed Freeze Exceptions, samba, ON_QA
17:21:44 <adamw> #info Ticket vote: FinalFreezeException (+0,2,-1) (bcotton, kparal, -adamwill)
17:21:58 <adamw> i'm -1 on this as i didn't see any justification for it being an fe rather than an update
17:22:46 <frantisekz> -1 FE
17:23:22 <pwhalen> -1 FE
17:23:37 <bcotton> -1 FE
17:23:48 <lruzicka[m]> -1fe
17:24:04 <Southern_Gentlem> -1fe
17:24:50 <adamw> proposed #agreed 1946950 - RejectedFreezeException (Final) - no justification has been provided for why this needs a freeze exception and cannot just be a 0-day update
17:25:13 <Southern_Gentlem> ack
17:25:18 <pwhalen> ack
17:25:28 <bcotton> ack
17:26:26 <frantisekz> ack
17:26:45 <adamw> #agreed 1946950 - RejectedFreezeException (Final) - no justification has been provided for why this needs a freeze exception and cannot just be a 0-day update
17:26:56 <adamw> #topic (1947664) Re-enable systemd-resolved caching
17:27:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1947664
17:27:07 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/344
17:27:18 <adamw> #info Proposed Freeze Exceptions, systemd, MODIFIED
17:27:37 <adamw> haven't heard anything about anyone having issues with the update
17:27:44 <bcotton> so....how confident are we in this? seems like it's bitten us a time or two this release
17:29:23 <adamw> well, the biting usually showed up quite fast before
17:29:40 <frantisekz> karma seems positive overall
17:31:40 <Southern_Gentlem> bcotton,  like everything in fedora it is fluid, once we get a release candidate and test then we will know
17:32:00 <bcotton> :-)
17:32:05 <bcotton> okay, then I'm +1 FE
17:32:18 <adamw> i think i'm just about confident enough to say pull it in
17:32:22 <frantisekz> +1 FE
17:32:24 <Southern_Gentlem> +1 fe
17:32:26 <adamw> i will plan to regret this later
17:32:29 <adamw> tentative +1
17:32:29 <pwhalen> +1 FE
17:32:32 <pwhalen> heh
17:32:33 <lruzicka[m]> +1 fe then
17:32:40 <bcotton> +1 FutureRegret
17:33:03 <Southern_Gentlem> if it works no issue if it doesnt then it doesnt
17:34:02 <Southern_Gentlem> at least we have a couple of days to test before thursday
17:34:09 <cmurf> lol i plan to regret this later hahaha
17:34:38 <Southern_Gentlem> if it works np, if it doesnt we revert and move forward
17:34:47 <Southern_Gentlem> failure is not a bad thing
17:34:50 <adamw> Southern_Gentlem: it's been in u-t for several days so most f34 users should have it already
17:35:40 <Southern_Gentlem> adamw, its not the people already running it i concerned about
17:35:43 <cmurf> same for shim for that matter, so far things are going well
17:36:03 <cmurf> and grub 2.06 for even longer
17:36:09 <adamw> didn't i unpush shim?
17:36:24 <Southern_Gentlem> its the people whom will upgrade or  install after the release
17:36:31 <cmurf> it's still in u-t though
17:36:33 <cmurf> for f33 and f34
17:36:47 <adamw> oh, no, i didn't.
17:37:02 <adamw> Southern_Gentlem: yes, but my point is we're already testing it :D
17:37:21 <cmurf> well instead of breaking a bunch of people's computers we got a lot more testing :P yay!
17:37:30 <Southern_Gentlem> most early adopters i am worried about,and with no one screaming that is good
17:37:45 <Southern_Gentlem> not ^^
17:38:14 <adamw> proposed #agreed 1947664 - AcceptedFreezeException (Final) - so far there's no indication that anyone's had name resolution issues with this, so we're hopeful it finally solves all the major problems. we do want the feature enabled for release as it's a major part of the change.
17:38:15 <frantisekz> adamw, it might make sense to unpush it at least for f33?
17:38:29 <bcotton> ack
17:38:35 <frantisekz> ack
17:38:38 <Southern_Gentlem> ack
17:38:42 <pwhalen> ack
17:38:50 <lruzicka[m]> ack
17:39:35 <cmurf> shim? i think leave it in u-t for f33 for a good while, there is no urgency
17:40:07 <cmurf> for f34 it's a bit different, also no urgency other than the fact we need the new version on all media that boots UEFI
17:40:15 <adamw> frantisekz: autopush is disabled
17:40:24 <adamw> #agreed 1947664 - AcceptedFreezeException (Final) - so far there's no indication that anyone's had name resolution issues with this, so we're hopeful it finally solves all the major problems. we do want the feature enabled for release as it's a major part of the change.
17:40:35 <adamw> #topic (1948003) Backport support for hardware acceleration with proprietary NVIDIA driver
17:40:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1948003
17:40:45 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/347
17:40:50 <adamw> #info Proposed Freeze Exceptions, xorg-x11-server-Xwayland, NEW
17:41:00 <adamw> this seems like a lot of change to pull in late solely for the benefit of a proprietary driver
17:41:30 <bcotton> ...that isn't even released yet
17:41:55 <Southern_Gentlem> 40%+ of your base though
17:42:16 <bcotton> the package maintainer doesn't seem that keen on it either
17:42:34 <Southern_Gentlem> -1 fe
17:42:43 <bcotton> -1 FE
17:43:13 <lruzicka[m]> -1fe
17:43:20 <frantisekz> -1 FE, this can go as an update
17:43:24 <pwhalen> -1 FE
17:44:25 <adamw> proposed #agreed 1948003 - RejectedFreezeException (Final) - this is a lot of change for the benefit solely of a proprietary driver. The cost/benefit doesn't seem worth it at this point
17:44:32 <Southern_Gentlem> sorry no way to test
17:44:33 <Southern_Gentlem> ack
17:44:39 <lruzicka[m]> ack
17:45:25 <frantisekz> ack
17:45:32 <pwhalen> ack
17:45:37 <bcotton> ack
17:46:16 <adamw> #agreed 1948003 - RejectedFreezeException (Final) - this is a lot of change for the benefit solely of a proprietary driver. The cost/benefit doesn't seem worth it at this point
17:46:23 <adamw> ok, that's all the proposed blockers and FEs on the list
17:46:26 <adamw> any late proposals?
17:47:04 <ab> adamw: I missed your request for Samba RPC memory leak, sadly. This is affecting IPA deployments with trust to AD enabled or with Samba domain members. It is definitely an issue I'd like to see fixed in the release and not in a 0-day update because it is an issue hard to spot but it causes OOM in productions.
17:47:50 <ab> I fixed it in F33 already, so F34 would be a regression ;)
17:48:37 <frantisekz> adamw: the secretary thing is done
17:49:41 <adamw> ab: still, it's rather hard to do a freeipa deployment without updates repo active, yes?
17:49:49 <ab> nope
17:49:50 <adamw> you'd have to run the deployment as part of system install
17:49:56 <adamw> ?
17:50:05 <ab> we are pretty much close to having F34 without need for updates testing
17:50:31 <adamw> it still wouldn't need updates-testing
17:50:42 <adamw> if it's queued for stable before release it will be in stable updates repo on release ady
17:50:54 <adamw> FE just gets it on the actual release media and the frozen 'fedora' repo
17:51:32 <ab> which would be great because it means it also would be less of a probelm for people who use iso images in the lab to save on traffic
17:52:13 <adamw> hrm
17:52:15 <adamw> we can revote it, i guess
17:52:18 <adamw> #topic (1946950) Samba RPC daemons leak memory
17:52:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1946950
17:52:21 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/334
17:52:21 <adamw> #info Proposed Freeze Exceptions, samba, ON_QA
17:52:31 <adamw> #info we are re-voting this at ab's request
17:52:35 <Southern_Gentlem> +1 FE
17:52:59 <adamw> he provides the new info that it affects certain freeipa deployments and would like it as an FE for the case of deploying freeipa using only the server dvd iso contents
17:54:16 <cmurf> +1 FE
17:54:20 <frantisekz> +1 FE, ab's reasoning seems solid
17:54:41 <pwhalen> +1 FE
17:54:43 <lruzicka[m]> +1 fe
17:55:26 <bcotton> +1 fe
17:55:27 <adamw> proposed #agreed 1946950 - AcceptedFreezeException (Final) - this is now accepted as an FE due to its impact on FreeIPA deployments, which are part of the Server DVD package set
17:55:32 <frantisekz> ack
17:55:36 <Southern_Gentlem> ack
17:55:51 <pwhalen> ack
17:55:57 <bcotton> ack
17:56:02 <lruzicka[m]> ack
17:56:27 <adamw> #agreed 1946950 - AcceptedFreezeException (Final) - this is now accepted as an FE due to its impact on FreeIPA deployments, which are part of the Server DVD package set
17:56:29 <adamw> ok
17:56:32 <adamw> #topic Open floor
17:56:37 <adamw> any other business, folks?
17:57:32 <Southern_Gentlem> frantisekz> adamw: the secretary thing is done (not anymore :))
17:57:41 <frantisekz> it's done
17:57:42 <frantisekz> :D
17:57:45 <frantisekz> I am quick
17:58:57 <adamw> hehe
17:59:25 <Southern_Gentlem> on the smb thing so the fix already exists?
17:59:44 <cmurf> were we going to review status of blockers?
18:00:19 <adamw> oh yes. that's a thing
18:00:34 <adamw> .fire adamw
18:00:34 <adamw> .hire cmurf
18:00:36 <zodbot> adamw fires adamw
18:00:38 <zodbot> adamw hires cmurf
18:00:38 <adamw> #topic Accepted blocker status
18:00:47 <frantisekz> (I need to run already, will read notes after, thanks everybody and especially adamw for leading this!)
18:01:28 <adamw> skipping ones where the fix is pending
18:01:30 <adamw> thanks frantisekz!
18:01:35 <adamw> #topic (1947704) Do final F34 fedora-release and fedora-repos builds
18:01:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1947704
18:01:47 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/346
18:01:55 <adamw> #info Accepted Blocker, fedora-release, NEW
18:02:12 <adamw> mboddu: ping?
18:02:12 <zodbot> adamw: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
18:02:25 <mboddu> I am here
18:03:18 <adamw> mboddu: is this being worked on?
18:03:42 <Southern_Gentlem> it cant be til it goes final can it
18:04:02 <mboddu> adamw: Yeah, I can work on it today and will submit the updates in few min
18:04:41 <lruzicka[m]> need to go, sorry about that
18:04:43 <adamw> ok, thanks
18:04:48 <adamw> #info mboddu is working on this today
18:04:57 <adamw> #action mboddu to submit final fedora-release and fedora-repos builds
18:06:36 <adamw> #topic (1948034) Server deployment fails on current F34 and Rawhide ("All nameservers failed to answer the query...")
18:06:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1948034
18:06:48 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/349
18:06:53 <adamw> #info Accepted Blocker, freeipa, ASSIGNED
18:07:08 <adamw> so ab tested a fix for this with a scratch build today, it looks good
18:07:26 <adamw> #info a fix for this has been tested as a scratch build, an update will be coming today we hope
18:08:11 <adamw> #topic (1943943) Hitting "Update All" in Plasma Discover sometimes does nothing, just cycles back
18:08:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1943943
18:08:22 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/320
18:08:27 <adamw> #info Accepted Blocker, plasma-discover, NEW
18:08:31 <adamw> this isn't really going anywhere, afaict
18:09:11 <adamw> it does seem the refresh button acts as a workaround
18:09:38 <adamw> and we're still not really sure whether this is something people will likely hit or if something about openqa's test process makes openqa hit it but regular users likely won't
18:09:51 <adamw> so i could see this being waive-able
18:09:52 <adamw> (or just revotable to -1)
18:12:41 <cmurf> -1 blocker
18:13:25 <cmurf> +1 FE, if we slip then consider bringing it in
18:14:02 <cmurf> oh but it's not going anywhere so there's no fix to give an exception to, so scratch the FE
18:14:05 <bcotton> have we done any manual testing on this to see what the experience is for actual people?
18:14:57 <adamw> i haven't. dunno if anyone else has
18:15:37 <Southern_Gentlem> ask the kde sig?
18:16:18 <adamw> i already have been, via irc, but not really getting much news
18:18:29 <adamw> i'm kinda inclined to go to -1 on this, honestly. it's awkward but not really any kind of showstopper, and i suspect people would land on the "just hit the refresh button" workaround by chance easily enough
18:19:18 <bcotton> wfm. we could  commonbugs it too
18:20:01 <Southern_Gentlem> -1 blocker +1 FE
18:22:59 <cmurf> that's -2 blocker so far, how about two more :)
18:23:33 <adamw> i count three
18:23:42 <adamw> you, southern, and me
18:23:50 <adamw> and we can count ben with "wfm" i guess :D
18:24:17 <pwhalen> -1 blocker
18:26:12 <bcotton> -1 blocker just to be clear
18:26:30 <adamw> proposed #agreed 1943943 - RejectedBlocker (Final) - this is revoted to rejected because it doesn't happen all the time, we're not sure if it will actually happen at all often in regular use or if it's just a quirk of openQA's test setup, and the workaround is one folks will probably 'naturally' stumble across
18:26:48 <Southern_Gentlem> ack
18:26:57 <cmurf> ack
18:28:18 <adamw> #agreed 1943943 - RejectedBlocker (Final) - this is revoted to rejected because it doesn't happen all the time, we're not sure if it will actually happen at all often in regular use or if it's just a quirk of openQA's test setup, and the workaround is one folks will probably 'naturally' stumble across
18:28:48 <adamw> #topic (1929643) logout after switch returns the user to console instead of sddm
18:28:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1929643
18:28:56 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/235
18:29:02 <adamw> #info Accepted Blocker, sddm, NEW
18:29:13 <adamw> so i think i saw a note that there may actually be a fix for this
18:29:59 <bcotton> yeah, it sounds like upstream might have something in the works
18:30:25 <bcotton> they know our schedule and expressed hope that they'd get us something in time
18:31:47 <bcotton> i don't actually see any updates in the upstream bug so i'm feeling not-optimistic
18:32:06 <bcotton> conan_kudo[m]: do you know of anything on this?
18:32:07 <adamw> yeah, it hasn't been touched since friday
18:32:47 <Eighth_Doctor> I think you'd have to ask rdieter and ngraham about it, but they're not here
18:33:21 <Eighth_Doctor> Nate in particular is only in the #fedora-kde:matrix.org room
18:35:17 <Eighth_Doctor> I've asked him to join this room
18:35:54 <Eighth_Doctor> hey Nate Graham, so we're talking about the sddm fast user switching thing, do you have any idea if there's any progress on it from Friday?
18:41:01 <NateGraham[m]> not to my knowledge. I can ping about it
18:41:50 <Eighth_Doctor> that'd be great, thanks!
18:43:55 <adamw> #info upstream is working on this bug, but no fix appears to be ready yet
18:44:54 <adamw> #topic (1938630) include new bootloaders on Fedora 34 install media so UEFI Secure Boot enabled systems can boot from them
18:44:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1938630
18:45:03 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/310
18:45:08 <adamw> #info Accepted Blocker, shim, POST
18:45:25 <adamw> so, the status here is, we got a new signed build of shim as an update and it's under testing, but we've found two significant issues in it so far
18:45:42 <adamw> one prevents boot on (we think) all developer edition Dell XPS laptops with default configuration
18:45:57 <adamw> the other prevents boot on older intel macs with the original "EFI" firmware (not UEFI)
18:46:11 <Eighth_Doctor> joy :(
18:46:21 <adamw> #info a resigned shim is built and in updates-testing, but two significant bugs have been discovered in it
18:46:51 <adamw> i guess i'll add a comment to the bug explaining the situation to try and plot a course
18:47:52 <adamw> the best info i have is that pjones was building a new version with the xps bug fixed and sending it for signing on friday, though i don't see a new release tagged upstream so not sure about that
18:48:02 <adamw> i don't believe the intel mac fix was going to be included in that
18:48:41 <adamw> we do have an alternative option for the intel mac bug: we can try and make anaconda set up the bootloader config to use grub directly and just bypass shim on those systems, as they do not support SB in any case
18:48:43 <cmurf> yeah i'm uncertain which unsigned-shim has been submitted for signing
18:48:52 <adamw> but we'd have to implement that, and it would not fix things for upgrades
18:49:12 <Eighth_Doctor> ... which brings us back to how we kind of handwave bootloader management post-install :/
18:49:20 <cmurf> i was under the impression pjones was going to see if there are other issues that came up from today's test day before submitting shim' for signing by MS
18:49:24 <adamw> hmm
18:49:28 <adamw> https://koji.fedoraproject.org/koji/buildinfo?buildID=1734914 does include both fixes
18:49:33 <cmurf> yes
18:49:35 <cmurf> i've tested that
18:49:38 <adamw> javier mentioned he was going on PTO
18:49:49 <cmurf> he is
18:50:08 <adamw> and he definitely seemed to imply in pm with me that he was sending the build right away (this was when we were talking on friday before you found the intel bug)
18:50:13 <adamw> so, uh, i guess we need to get that clarified :D
18:50:20 <cmurf> yeahhhh
18:50:31 <cmurf> i have since found another bug :P but it's non-fatal near as i can tell
18:50:56 <cmurf> i did ping him about it on irc but haven't heard back
18:50:58 <cmurf> https://bugzilla.redhat.com/show_bug.cgi?id=1948432
18:51:07 <cmurf> that's the new bug, which i found on an hp spectre
18:51:53 <adamw> oh, that is the same thing? thought you found it on an apple
18:52:07 <cmurf> i've found two bugs
18:52:12 <adamw> ah okay.
18:52:15 <adamw> that one doesn't break boot though, right
18:52:39 <cmurf> apple EFI 1.10 bug, which is fixed in unsigned-shim-15.4-3 (not to be confused with shim-15.4-3)
18:52:51 <cmurf> the hp bug does not break boot
18:53:18 <cmurf> Failed to lookup EFI memory descriptor is the message and its in red text so it seems like it wants attention
18:53:26 <cmurf> but no call trace and no crashes or anything like that in a week
18:53:57 <cmurf> i only just saw it very early this morning and did regression testing on it to confirm it only correlates to shim 15.4 being installed
18:54:06 <cmurf> but it's been happening for a week, to no ill effect
18:54:19 <adamw> okay.
18:54:36 <adamw> #action adamw to try and get clarity on where we stand with getting a new signed shim build, and what's in it
18:55:01 <adamw> and finally
18:55:02 <adamw> #topic (1946278) latest uboot fails to load the dtb
18:55:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1946278
18:55:11 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/322
18:55:14 <adamw> #info Accepted Blocker, uboot-tools, ASSIGNED
18:55:38 <adamw> pwhalen: still around? any news here?
18:56:17 <pwhalen> yes, pbrobinson is working on it and made some progress
18:57:51 <adamw> #info pbrobinson is working on this and made some progress
18:58:02 <adamw> so, "some progress" sounds like "not done yet" :D
18:58:08 <adamw> so this is on the wait list i guess
18:58:28 <pwhalen> right, not done yet but getting there
18:58:57 <adamw> #action pbrobinson to finish fixing this
18:59:00 <adamw> #topic Open floor
18:59:07 <adamw> aaaand...that's REALLY all i got :) just under the time limit
18:59:14 <adamw> anything else on fire? i hope not, that's enough piles of fire for one year
18:59:36 <cmurf> has it been a year already?
18:59:40 <cmurf> is it december now?
19:00:21 <cmurf> test day is going ok i think
19:01:01 <cmurf> https://testdays.fedoraproject.org/events/111
19:01:04 <cmurf> yeah no fails so far
19:01:12 <adamw> yay
19:01:29 <cmurf> statistically you'd think we'd hit at least another sputnik
19:01:47 <cmurf> and maybe a mac
19:04:24 <adamw> so maybe people are testing wrong? :D
19:04:56 <adamw> alright, thanks for coming, everyone, sorry it dragged on
19:04:58 <adamw> lots of mess :(
19:05:02 <adamw> #endmeeting