16:00:49 <adamw> #startmeeting F33-blocker-review
16:00:49 <adamw> #meetingname F33-blocker-review
16:00:49 <adamw> #topic Roll Call
16:00:49 <zodbot> Meeting started Mon Oct  5 16:00:49 2020 UTC.
16:00:49 <zodbot> This meeting is logged and archived in a public location.
16:00:49 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:49 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:00:49 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:01:03 <coremodule> this is blasphemy this is madness
16:01:10 <coremodule> .hello2
16:01:10 * nb asks zodbot to leave
16:01:10 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:01:15 <nb> .hi
16:01:17 <zodbot> nb: nb 'Nick Bebout' <nick@bebout.net>
16:01:37 <cmurf> .hello chrismurphy
16:01:38 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:02:22 * pwhalen is here
16:02:26 <adamw> .fire zodbot
16:02:26 <zodbot> adamw fires zodbot
16:02:40 <bcotton> .hello2
16:02:41 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:03:04 * cmurf is glad that adamw is back
16:03:29 * kparal is here
16:03:38 <frantisekz> .hello2
16:03:39 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:04:04 * coremodule will secretarialize.
16:04:05 <adamw> how's everyone doing?
16:04:50 <coremodule> gooooood!
16:05:36 <adamw> that's suspiciously positive for someone who has to secretarialize later
16:05:50 <coremodule> but daaaaaad!
16:07:25 <adamw> =)
16:07:33 <adamw> alrighty, let's get rolling - impending boilerplate alert
16:07:44 <adamw> oh, let me throw some chairs first
16:07:49 <adamw> #chair pwhalen coremodule
16:07:49 <zodbot> Current chairs: adamw coremodule pwhalen
16:07:57 <adamw> #topic Introduction
16:07:57 <adamw> Why are we here?
16:07:57 <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:07:57 <adamw> #info We'll be following the process outlined at:
16:07:59 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:01 <adamw> #info The bugs up for review today are available at:
16:08:03 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:05 <adamw> #info The criteria for release blocking bugs can be found at:
16:08:07 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:08:09 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria
16:08:11 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria
16:08:22 <adamw> oh, kparal, have you updated from the async tickets?
16:09:17 * adamw checks quickly...looks like none of the proposals quite has a clear-cut vote
16:09:29 <adamw> #info for Final, we have:
16:09:34 <adamw> #info 6 Proposed Blockers
16:09:34 <adamw> #info 5 Accepted Blockers
16:09:42 <adamw> #info 2 Proposed Freeze Exceptions
16:09:43 <adamw> #info 3 Accepted Freeze Exceptions
16:09:56 <adamw> #info coremodule will secretarialize
16:10:02 <adamw> ok, let's get started with...
16:10:04 <kparal> adamw: I haven't
16:10:06 <adamw> #topic Proposed Final blockers
16:10:20 <adamw> #topic (1885154) retrace jobs seem to always fail
16:10:21 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1885154
16:10:21 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/141
16:10:21 <adamw> #info Proposed Blocker, abrt, NEW
16:10:36 <frantisekz> adamw: I did some updates from async tickets today
16:10:51 <frantisekz> moved one blocker, few FEs to accepted
16:11:17 <coremodule> I seem to remember having a similar issue with auto bug reporting in past and we chose to block on it... I think it was F29 or F30...
16:11:29 <cmurf> i've lost track of all the abrt bugs, dups, and related fixes
16:13:06 <adamw> coremodule: it depends a bit on the details i think
16:13:10 <bcotton> if local processing works (and kparal says it does), then i'm not super keen on calling this a blocker
16:13:15 <cmurf> i filed a bug just like this and it got closed by abrt people as being fixed
16:13:26 <cmurf> that was a week ago
16:14:23 <adamw> there's also the consideration that the bug may well not be in fedora at all but on the retrace server...
16:14:29 <adamw> has anyone tried reporting a crash from f32?
16:14:47 <adamw> (even if that works it still might be a retrace server bug, but it'd be interesting to know)
16:14:55 <adamw> frantisekz: thanks, btw
16:15:23 <kparal> adamw: this bug is most likely on the retrace server
16:15:29 <adamw> yeah
16:15:43 <kparal> so it could be a 0day blocker
16:16:06 <kparal> but we don't really know, and without a fix, we won't know what other issues lie hidden in there :)
16:16:10 <kparal> as abrt proved lately
16:16:11 <cmurf> it's a good question if this is an issue with f32
16:17:14 <adamw> i think i'm kinda leaning -1 blocker +1 fe on this
16:17:22 <adamw> oh, we should vote fe on all proposed blockers as freeze is in 24 hours
16:17:29 <kparal> I remember retrace server was broken completely because it didn't support zstd rpms, in F32. Did that got fixed?
16:17:33 <cmurf> 20 :)
16:17:40 <adamw> ish!
16:17:53 <cmurf> 19h13m44s
16:18:02 <cmurf> oops that's wrong
16:18:05 <cmurf> 43m
16:18:30 <frantisekz> -1 Blocker, +1 FE
16:18:34 <cmurf> it's extra funny when you get it wrong
16:18:46 <cmurf> so the wg has been mixed on abrt bugs
16:18:46 <bcotton> -1 Blocker,  +1 FE
16:19:01 <cmurf> some want to block indefinitely, and fix it, or totally drop it
16:19:17 <cmurf> others aren't sure if that would change anything
16:20:08 <adamw> oh, i should note we have a +1 blocker in the ticket from mcatanzaro
16:20:14 <adamw> he doesn't seem to be around
16:20:23 <adamw> so the count atm is -2 blocker, +3 fe
16:20:44 <adamw> kparal: i thought the zstd thing got fixed but can't swear to it
16:20:54 * kparal is updating his F32 VM
16:20:59 <kparal> 0 blocker
16:21:53 <adamw> any other votes?
16:22:02 <cmurf> i'm on the fence as well without knowing if blocking would help, it really seems to be on its own time frame
16:22:29 <cmurf> +1 FE though
16:23:05 <adamw> at -2 we'd have to leave this outstanding
16:23:19 <coremodule> -1 blocker
16:23:19 <pwhalen> -1 blocker, +1 FE
16:23:25 <coremodule> +1 FE
16:23:48 <adamw> alrighty, that works :)
16:24:39 * kparal causing a crash on F32
16:25:26 <adamw> proposed #agreed 1885154 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected on the grounds that the app is likely working (the bug is likely in the retrace server itself), and local traceback generation does work so we aren't stuck without being able to report crashes. Accepted as a freeze exception issue just in case a fix is needed to the package, obviously we would want that in for release
16:25:47 <adamw> kparal: don't you just need to touch it to make it crash? :)
16:25:52 <kparal> ack
16:25:57 <coremodule> ack
16:26:13 <bcotton> ack
16:26:16 <pwhalen> ack
16:26:28 <kparal> that's exactly what I'm doing, frowning at it
16:26:34 <adamw> hehe
16:26:42 <kparal> Preparing environment for backtrace generation
16:26:49 <adamw> #agreed 1885154 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected on the grounds that the app is likely working (the bug is likely in the retrace server itself), and local traceback generation does work so we aren't stuck without being able to report crashes. Accepted as a freeze exception issue just in case a fix is needed to the package, obviously we would want that in for release
16:27:03 <kparal> Retrace job failed
16:27:03 <kparal> Retrace failed. Try again later and if the problem persists report this issue please.
16:27:06 <adamw> #topic (1882863) gnome-software 3.38.0 does not list all software in Add-ons
16:27:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1882863
16:27:06 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/127
16:27:06 <adamw> #info Proposed Blocker, distribution-gpg-keys, NEW
16:27:10 <kparal> that's exactly the same message
16:27:17 <adamw> kparal: ah, so yeah, that sounds indicative.
16:27:39 <adamw> and also is another reason not to block on this - it's broken in our current release anyway, so what's the point.
16:27:45 <adamw> okay, so on this one...
16:28:20 <adamw> #info we have +1 (zbyszek) -1 (kleinkravis) in the ticket - https://pagure.io/fedora-qa/blocker-review/issue/127
16:28:25 <adamw> so the total stands at 0
16:28:48 <adamw> looks like it was discussed last week and punted
16:29:04 <frantisekz> -1 Final Blocker, +1 Final FE
16:29:06 <kparal> do we have a matching criterion?
16:29:06 <coremodule> it looks like a simple fix, should we block on it, adding the missing gpg keys
16:29:39 <kparal> https://pagure.io/fedora-qa/blocker-review/issue/127#comment-689152
16:30:55 <coremodule> that's a good criterion for this, it just depends on if adding a non-free repo is considered when we're talking about "release blocking"
16:31:01 <adamw> on the one hand i'd really like to see this fixed (especially given the lenovo angle). on the other hand i'm having difficulty justifying it as a blocker
16:31:12 <adamw> it's a stretch for the criterion
16:31:37 <adamw> the software is perfectly capable of installing and removing packages, it's just rejecting a repo whose keys it doesn't have, which seems a reasonable behaviour
16:31:57 <adamw> though tbh i didn't know we ship all these external repo keys at all...
16:31:58 <coremodule> I dunno, i don't see it streching too much, considering the repo's are downloaded and installed like packages
16:31:58 <kparal> and we don't have a criterion for saying "repos provided by default must work"
16:32:18 <adamw> if the repo was *enabled* by default i'd see the case more
16:32:29 <bcotton> yeah, the fact that we ship those keys was new to me, too
16:32:48 <adamw> i think i'm -1 blocker +1 fe on this too
16:33:12 <bcotton> same. -1 blocker +1 fe
16:33:23 <cmurf> the integration aspect of including all of them is pushed back to F34, I think
16:33:23 <kparal> the key is not for rpmfusion, I think, just for the specific subset of packages that is maintained separately
16:33:23 <coremodule> -1 blocker, +1 fe here too, based on the fact that this is not enabled by default
16:33:25 <cmurf> https://pagure.io/fedora-workstation/issue/105
16:33:49 <pwhalen> -1 blocker, +1 fe
16:34:24 <kparal> cmurf: so how unhappy will workstation wg be when we don't fix this?
16:34:40 <cmurf> you know what i don't see keys in that package so i don't think it's related
16:35:26 <adamw> cmurf: er, how do you not?
16:36:52 <adamw> oh, er, btw
16:36:52 <adamw> https://github.com/xsuchy/distribution-gpg-keys/commit/df433ba2d077de89625deb276eeb256200ac080c
16:37:02 <cmurf> kalev: does bug 1882863 look like a blocker to you?
16:37:12 <adamw> https://koji.fedoraproject.org/koji/buildinfo?buildID=1620395
16:37:39 <adamw> https://bodhi.fedoraproject.org/updates/FEDORA-2020-910d76ff81
16:38:26 <adamw> update is marked as fixing https://bugzilla.redhat.com/show_bug.cgi?id=1885076 which looks a lot like a dupe of this
16:38:46 <cmurf> ok one laptop has fedora-workstation-repositories-32-4.fc33.noarch, the other doesn't
16:39:06 <cmurf> and the "other" is a clean installed Workstation live
16:39:58 <adamw> #info this is likely fixed by https://bodhi.fedoraproject.org/updates/FEDORA-2020-910d76ff81
16:41:05 <cmurf> that same laptop has fedora-gpg-keys but not distribution-gpg-keys
16:41:40 <adamw> proposed #agreed 1882863 - RejectedBlocker (Final) AcceptedFreezeException (Final) - we don't think this can really count as a violation of the criterion cited, the app's "basic functionality" is working fine, it is just rejecting a repo whose key it can't find, which is correct behavior. However, we definitely want these additional repos to work at release time as they are widely used, so accepted as a freeze exception issue
16:41:56 <cmurf> ack
16:42:05 <bcotton> ack
16:42:17 <coremodule> ack
16:42:31 <pwhalen> ack
16:42:52 <adamw> #agreed 1882863 - RejectedBlocker (Final) AcceptedFreezeException (Final) - we don't think this can really count as a violation of the criterion cited, the app's "basic functionality" is working fine, it is just rejecting a repo whose key it can't find, which is correct behavior. However, we definitely want these additional repos to work at release time as they are widely used, so accepted as a freeze exception issue
16:43:13 <adamw> #topic (1882718) Can't login if the session is locked
16:43:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1882718
16:43:14 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/131
16:43:14 <adamw> #info Proposed Blocker, gnome-remote-desktop, NEW
16:43:37 <adamw> we have +1 / -3 in the ticket
16:43:52 <bcotton> take my -1, too
16:45:25 <kparal> I voted for the crash to be blocker, not the locked screen
16:45:26 <adamw> well
16:45:40 <kparal> does everyone else disagree with that?
16:45:48 <adamw> yeah, please read https://pagure.io/fedora-qa/blocker-review/issue/131#comment-693434 , i'm a bit partial to that argument
16:45:58 <adamw> though we should really change the bug report or file a different one to make it clear
16:46:30 <adamw> i'm -1 blocker on "this is behaving as upstream intended", but a crash after first connect seems more significant
16:46:32 <cmurf> i think kparal makes a good argument that the crash is final blocker worthy
16:46:56 <kparal> I also updated https://bugzilla.redhat.com/show_bug.cgi?id=1882718#c10
16:46:59 <cmurf> there's two bugs
16:47:34 <bcotton> hm. okay, i can get behind that
16:47:35 <cmurf> one of which may not be a bug (the 'works as intended' one)
16:47:44 <bcotton> +1 blocker on the crash
16:48:34 <cmurf> +1 blocker on the crash
16:48:46 <frantisekz> +1 blocker on the crash
16:48:52 <adamw> yeah, i think i change my vote to +1
16:48:53 <pwhalen> +1 blocker on the crash
16:49:02 <adamw> i guess kalev isn't around..
16:49:25 <kalev> I am now
16:50:14 <adamw> wdyt of kparal's point about the crash?
16:51:44 <kalev> I think I agree with kparal about the crash possibly being blocking (but I don't know much about gnome-remote-desktop)
16:52:41 <adamw> okay
16:52:48 <kalev> sorry, making dinner, have to disappear again
16:52:48 <adamw> we can always revisit later if we change our minds
16:52:53 * kalev nods.
16:53:38 <adamw> but for now, i count +6 / -2, and those -1s were not considering the crash issue, so...
16:55:53 <adamw> proposed #agreed 1882718 - AcceptedBlocker (Final) - accepted as a violation of "All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test", counting screen sharing as part of Settings' basic functionality, as the crash means only one screen sharing session can be attempted, after
16:55:54 <adamw> which the server crashes and all subsequent attempts will fail
16:55:56 <adamw> grrr, too long
16:56:43 <adamw> proposed #agreed 1882718 - AcceptedBlocker (Final) - accepted as a violation of "All applications that can be launched...after a default installation of Fedora Workstation...must start successfully and withstand a basic functionality test", counting screen sharing as part of Settings, as the crash means only one screen sharing session can be attempted, after which the server crashes and all subsequent attempts will fail
16:56:58 <adamw> i think that's a better criterion judo than using the default panel thing
16:57:04 <coremodule> ack
16:57:05 <adamw> but if anyone would prefer the panel thing, speak now
16:57:56 <kparal> I also proposed default functionality criterion
16:57:58 <kparal> ack
16:58:13 <Southern_Gentlem> ACK
16:58:26 <kparal> we now have default functionality covering Settings, we don't need to use the panel criterion anymore
16:58:31 <pwhalen> ack
16:58:48 <adamw> #agreed 1882718 - AcceptedBlocker (Final) - accepted as a violation of "All applications that can be launched...after a default installation of Fedora Workstation...must start successfully and withstand a basic functionality test", counting screen sharing as part of Settings, as the crash means only one screen sharing session can be attempted, after which the server crashes and all subsequent attempts will fail
17:00:30 <adamw> #topic (1880833) Massive memory leak on AMD cards
17:00:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1880833
17:00:32 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/116
17:00:32 <adamw> #info Proposed Blocker, mesa, NEW
17:00:37 <adamw> looks to me like we're still finding the edges of this one
17:01:03 <kparal> no new development
17:01:05 <cmurf> needinfo
17:01:09 <cmurf> still
17:01:27 <coremodule> I got an AMD card over the weekend in a junk box, I can fire it up and report what I see...
17:04:31 <kparal> the reporter's issue dates back to F32, and we're not seeing many complaints even from F32
17:04:48 <kparal> so I think this is likely quite corner case-y
17:05:00 <cmurf> oh
17:05:18 <kparal> and I'm running F32 on RX580 all the time
17:05:21 <cmurf> in that case, -1 blocker, repropose when it's reproducible
17:05:28 <adamw> yeah, i'm either punt again or -1
17:05:31 <bcotton> yeah, i think i'm -1 at this point until someone can make a strong case otherwise
17:05:34 <coremodule> ahhh, good to know kparal
17:05:34 <kparal> cmurf: it is reproducible for him
17:05:35 <adamw> it feels pretty corner case-y
17:05:45 <coremodule> I'm -1 blocker
17:05:52 <cmurf> true but not sure if it's mesa or kernel
17:05:58 <cmurf> and no regression testing so far
17:06:49 <cmurf> sounds like it could be mesa afterall if it's not reproducible on the same GPU under GNOME
17:06:52 <kparal> yeah, either punt or -1 and wait for more people to report tihs
17:07:04 <kparal> cmurf: I have a different GPU
17:07:09 <cmurf> oic
17:07:13 <kparal> sorry if that sounded like I have the same one
17:07:15 <pwhalen> -1 blocker as well
17:07:20 <kparal> he has integrated Vega 3
17:07:30 <kparal> it's not that common as dedicated cards, I guess
17:08:04 <frantisekz> -1 Blocker, limited scope of impacted HW
17:08:08 <cmurf> regression testing the kernel is tedious but way easier than the bisect that's coming next
17:09:19 <cmurf> pre-ack for rejected blocker :P
17:12:09 <adamw> proposed #agreed 1880833 - RejectedBlocker (Final) - with current information this is looking quite a lot like a corner case that does not have broad enough impact to block on. It can be re-proposed if further information suggests that isn't true
17:12:18 <bcotton> ack
17:13:20 <coremodule> ack
17:14:40 <pwhalen> ack
17:15:23 <adamw> #agreed 1880833 - RejectedBlocker (Final) - with current information this is looking quite a lot like a corner case that does not have broad enough impact to block on. It can be re-proposed if further information suggests that isn't true
17:15:32 <adamw> #topic (1885102) snapshot of home can't be used in a new installation
17:15:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1885102
17:15:32 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/140
17:15:32 <adamw> #info Proposed Blocker, python-blivet, NEW
17:16:32 <adamw> there are no votes in the ticket.
17:16:59 <cmurf> oh this one, discovered it last night
17:17:21 <cmurf> i prefer calling it -1, conditional blocker
17:17:38 <adamw> yeah, based on comment 6 i think i'd be -1 too
17:17:55 <adamw> since the sort of intent of the criterion is "you should be able to do a clean reinstall but using an existing /home"
17:17:59 <kparal> doesn't sound too clockery at this point
17:18:05 <kparal> blockery
17:18:09 <adamw> and we sort of expect the existing /home would be a *fedora* one
17:18:19 <bcotton> -1 blocker +1 FE
17:18:23 <cmurf> well it is a fedora one
17:18:23 <adamw> reusing a /home from some other distro that does snapshotting would be a bit hairy
17:18:37 <cmurf> it's a snapshot of a fedora /home
17:18:50 <adamw> right, but taking the point that we don't do any snapshotting as part of packing etc.
17:19:04 <adamw> packaging*
17:19:08 <cmurf> yep
17:19:38 <pwhalen> -1 blocker +1 FE
17:19:51 <Southern_Gentlem> -1 b +1fe
17:19:53 <cmurf> -1 blocker, +1 FE
17:19:54 <nb> -1 blocker +1 FE
17:22:31 <adamw> proposed #agreed 1885102 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as it seems unlikely it will affect many if any people during F33 cycle, given there are likely few existing cases where someone would want to reuse a btrfs /home snapshot. Accepted as a freeze exception issue as there may be *some* cases, and it cannot be fixed with a post-release update
17:23:09 <nb> ack
17:23:48 <pwhalen> ack
17:24:12 <Southern_Gentlem> ack
17:24:23 <bcotton> ack
17:24:39 <cmurf> ack
17:25:01 <adamw> #agreed 1885102 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as it seems unlikely it will affect many if any people during F33 cycle, given there are likely few existing cases where someone would want to reuse a btrfs /home snapshot. Accepted as a freeze exception issue as there may be *some* cases, and it cannot be fixed with a post-release update
17:25:14 <adamw> last proposed blocker
17:25:15 <adamw> #topic (1883609) Secure Boot fails to boot F33 Beta image
17:25:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1883609
17:25:15 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/135
17:25:17 <adamw> #info Proposed Blocker, shim, NEW
17:25:30 <adamw> this seems like a very mysterious bug, but also hard to argue it's not a real one...
17:25:34 <cmurf> yes
17:25:48 <nb> i thought this was already a fesco blocker?
17:25:50 <cmurf> and with only a week of beta so far, hard to say if it's more widespread
17:25:51 <nb> or is that a different bug?
17:26:28 <cmurf> yeah that too, so there's a bit of confusion on that point, but it's tagged for meeting this week
17:26:37 <Southern_Gentlem> i am suspecting the computer needs a firmware update for the secureboot bug about 3 months ago
17:26:40 <cmurf> https://pagure.io/fesco/issue/2479
17:26:55 <cmurf> i'd say the bug got conflated with this fesco issue
17:27:00 <kparal> Southern_Gentlem: which might never arrive depending on the vendor
17:27:37 <kparal> but I think this is not about boothole or whatever the bug name is
17:27:48 <cmurf> i intended the fesco issue to be about the high level issue of Secure Boot signing keys and what it looks like to have to reissue images due to BootHole
17:27:48 <Southern_Gentlem> kparal, then that beyound our contro;
17:27:51 <cmurf> and this bug is something else
17:27:58 <frantisekz> kparal: I thought this could be caused by updating UEFI dbx
17:28:06 <frantisekz> and thus not depending on vendor at all..
17:28:14 <cmurf> the bug we're considering here sounds to me like it's a GRUB bug
17:28:35 <kparal> I don't think this is grub
17:28:37 <cmurf> shim is the same
17:28:40 <kparal> the error doesn't look like grub
17:28:47 <adamw> are we sure 1883609 is actually the same as the fesco ticket?
17:28:57 <cmurf> it's not
17:29:03 <cmurf> it was referenced in the fesco issue
17:29:26 <adamw> okay.
17:29:30 <cmurf> and it was thought during ensuing discussion that they were related, that this bug was an example of revocation happening in the wild
17:29:37 <adamw> so, let's forget about the fesco ticket.
17:29:38 <cmurf> but there's no evidence of that
17:30:13 <kparal> cmurf: well I do have windows on that laptop, so can't say
17:30:25 <kparal> but I can boot F32 Live
17:30:28 <adamw> right
17:30:29 <kparal> just not F33
17:30:35 <adamw> if it was a key revocation issue then f32 should not work either
17:31:03 <cmurf> microsoft has not issued a windows update revoking fedora secure boot keys
17:31:40 <adamw> still, we have no idea what actually *is* going on. afaics.
17:31:54 <cmurf> nope
17:32:08 <cmurf> i don't think it's shim because that binary is identical over the past 2 years
17:32:14 <cmurf> it's not even subject to mass rebuild
17:32:47 <cmurf> it could be xorriso doing something new with isohybrid that tickles some firmware in a weird way
17:32:55 <cmurf> or it could be GRUB
17:33:03 <cmurf> or it could be some other thing
17:33:34 <cmurf> and by GRUB i mean it could be that it tickles the firmware in a way that it spits out this firmware message
17:33:45 <cmurf> i don't see this message in either shim or grub source
17:34:06 <adamw> it's in the lenovo firmware, i believe
17:34:21 <adamw> if you google "Secure Boot Image failed to verify" you get lots of results from people with lenovo machines, but not necessarily using fedora (or linux)
17:34:26 <cmurf> one way to maybe narrow it down is create a USB stick with litd of an f33 ISO that we know should fail
17:35:28 <adamw> there are results from microsoft.com for e.g. - https://answers.microsoft.com/en-us/windows/forum/windows_8-update/image-failed-to-verify-with-access-denied/71ef02ff-abee-4916-ae45-72ef20c178ba
17:35:30 <cmurf> i'm pretty sure there's a firmware bug here too, but it could be one of these nasty nested bugs: one "bug" (or change) triggers the actual bug
17:36:00 <adamw> wonder if we should tag some lenovo folks...
17:36:18 <adamw> i'm kinda punt-y on this one till we have some idea what's going on
17:36:59 <cmurf> kparal reports that upon disabling Secure Boot that sysfs' efivars reports that it's unsupported, not disabled - that itself is a firmware bug
17:37:06 <cmurf> yep
17:37:12 <cmurf> agreed punt, need more info
17:38:50 <Southern_Gentlem> +1 P
17:39:02 <bcotton> +1 punt
17:39:05 <nb> +1 punt
17:40:12 <cmurf> litd created stick would eliminate xorriso as a suspect, if it still fails
17:40:31 <adamw> proposed #agreed 1883609 - punt (delay decision) - this is a worrying bug but it's also very mysterious at present, we don't know what's going on or how many systems it might affect or if it's even a Fedora bug at all (it may be a Lenovo firmware bug). We'll try to gather more information before making a decision
17:40:44 <bcotton> ack
17:41:00 <adamw> kparal: can you try the litd thing?
17:41:38 <cmurf> does anyone remember the proper flags? I think it's --noverify --efi --format
17:41:57 <cmurf> i don't think we need --reset-mbr but it's been years, i think that was for making a dual firmware stick
17:42:14 <adamw> i don't remember either :) might be in a test case
17:42:27 <cmurf> i'll put it in the ticket as a comment
17:43:25 * kparal holding a baby
17:44:09 <adamw> .fire kparal for excessive parenting
17:44:09 <zodbot> adamw fires kparal for excessive parenting
17:44:21 <cmurf> where's the beer?
17:44:24 <adamw> any more acks?
17:44:28 <cmurf> holding a beer *and* a baby?
17:44:34 <cmurf> ack
17:44:40 <bcotton> i can ack again
17:45:38 <cmurf> i'm not sure where the dbx "deny list" lives
17:45:43 <cmurf> if it's in nvram or spi
17:45:46 <coremodule> ack
17:45:47 <pwhalen> ack
17:47:34 <adamw> #agreed 1883609 - punt (delay decision) - this is a worrying bug but it's also very mysterious at present, we don't know what's going on or how many systems it might affect or if it's even a Fedora bug at all (it may be a Lenovo firmware bug). We'll try to gather more information before making a decision
17:47:44 <adamw> alright, moving onto:
17:47:50 <adamw> #topic Proposed Freeze Exceptions
17:48:00 <adamw> #topic (1884617) F32->F33 upgrade: obsolete removed Perl packages requiring perl(:MODULE_COMPAT_5.30.1)
17:48:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1884617
17:48:01 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/138
17:48:01 <adamw> #info Proposed Freeze Exceptions, fedora-obsolete-packages, ASSIGNED
17:48:38 <cmurf> seems reasonable
17:49:02 <bcotton> +1 to obsoleting
17:49:24 <adamw> we have +1 in the ticket from frantisekz
17:49:38 <adamw> oh, and a misspelled +1 from kparal
17:49:55 <pwhalen> +1
17:51:55 <cmurf> +1 fe
17:52:17 <Southern_Gentlem> +1 fe
17:52:50 <adamw> proposed #agreed 1884617 - AcceptedFreezeException (Final) - this seems like a good and useful thing to do, and doing it during freeze means upgrades before or on release day will benefit
17:52:53 <cmurf> ack
17:53:04 <Southern_Gentlem> ack
17:53:15 <pwhalen> ack
17:53:26 <bcotton> ack
17:54:26 <adamw> #agreed 1884617 - AcceptedFreezeException (Final) - this seems like a good and useful thing to do, and doing it during freeze means upgrades before or on release day will benefit
17:54:35 <adamw> last one...
17:54:36 <adamw> #topic (1884467) gnome-tour shortcut keys not working
17:54:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1884467
17:54:36 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/137
17:54:38 <adamw> #info Proposed Freeze Exceptions, gnome-tour, NEW
17:55:03 <adamw> we have +3 in the ticket already
17:55:07 <cmurf> +1 FE
17:55:08 <adamw> so unless anyone's -1...
17:55:12 <bcotton> +1 FE
17:55:27 <adamw> #info there are +3 votes in the ticket (lruzicka, frantisekz, kparal)
17:55:53 <Southern_Gentlem> +1 FE
17:56:06 <adamw> proposed #agreed 1884467 - AcceptedFreezeException (Final) - this may give a poor first impression as it runs on first boot after Workstation install, and for that reason cannot be fixed with a post-release update
17:56:07 <pwhalen> +1 FE
17:56:13 <Southern_Gentlem> ack
17:56:14 <bcotton> ack
17:56:14 <pwhalen> ack
17:58:01 <adamw> #agreed 1884467 - AcceptedFreezeException (Final) - this may give a poor first impression as it runs on first boot after Workstation install, and for that reason cannot be fixed with a post-release update
17:58:09 <adamw> alrighty, that's all the proposals
17:58:12 <adamw> we can do a quick check in on
17:58:18 <adamw> #topic Accepted Blockers
17:59:10 <adamw> #info 1881234 is in the process of being fixed, i'll try to confirm the fix after the meeting
17:59:17 <adamw> #topic (1884260) cheese creates invalid and extremely long video files, each app restart making them longer
17:59:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1884260
17:59:20 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/136
17:59:20 <adamw> #info Accepted Blocker, cheese, ASSIGNED
18:02:06 <adamw> so this is set to ASSIGNED and there's an upstream issue
18:02:09 <adamw> just checking that
18:02:58 <adamw> upstream issue's been open for three months
18:03:48 <adamw> david assigned it to himself, and he is an upstream maintainer...
18:04:13 <adamw> #info the bug here seems clear-cut, and there's an upstream issue too. david king has taken responsibility for it, so ball is in his court
18:04:28 <adamw> #topic (1816547) Firefox not using langpacks for localization
18:04:28 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1816547
18:04:28 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/69
18:04:28 <adamw> #info Accepted Blocker, firefox, ASSIGNED
18:06:02 <cmurf> still?
18:06:37 <adamw> yeah, no movement on this
18:06:51 <adamw> it's assigned to jan horak, but it seems like mstransky is still the one actually maintaining firefox
18:06:54 <adamw> i will poke him by email i think
18:07:02 <adamw> #info this is just sitting around waiting on firefox maintainers
18:07:08 <adamw> #action adamw to poke mstransky about it
18:07:12 <adamw> #undo
18:07:12 <zodbot> Removing item from minutes: ACTION by adamw at 18:07:08 : adamw to poke mstransky about it
18:07:14 <cmurf> there are issues building it still, looks like
18:07:20 <adamw> #action adamw to poke mstransky about #1816547
18:07:33 <cmurf> on 33
18:08:55 <adamw> oh well it's only the web browser, no big deal
18:08:57 <adamw> *sigh*
18:09:09 <adamw> #topic (1868141) Select Printer Driver hangs
18:09:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1868141
18:09:10 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/124
18:09:10 <adamw> #info Accepted Blocker, gnome-control-center, POST
18:09:57 <adamw> looks like we're just waiting for a 3.38.1 release here
18:10:07 <adamw> kalev: i assume one should be coming soon enough?
18:11:05 <adamw> #info this is fixed upstream, waiting for a 3.38.1 release to be made and built downstream
18:11:08 <kalev> adamw: yes, it should be any time now
18:11:13 <adamw> ok, thanks
18:11:32 <adamw> #topic (1861700) login stuck when changing users repeatedly (log out, log in a different one)
18:11:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1861700
18:11:32 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/16
18:11:32 <adamw> #info Accepted Blocker, sddm, ASSIGNED
18:12:19 <adamw> #info there's a proposed solution from Benjamin Berg in https://bugzilla.redhat.com/show_bug.cgi?id=1861700#c75 which looks like it would be worth trying, we are waiting on someone to implement that
18:13:40 <adamw> anything else?
18:14:44 <adamw> #topic Open floor
18:14:48 <adamw> ok, that's everything
18:14:56 <adamw> anyone have any other issues to bring up? late-breaking proposals?
18:15:09 * bcotton proposes it's time for a nap
18:16:34 <adamw> +1
18:17:14 <cmurf> no kidding
18:17:17 <cmurf> it's noon
18:17:22 <cmurf> do i want a nap or lunch
18:18:16 <adamw> ah, the eternal dilemma
18:18:25 <frantisekz> thanks for meeting everybody... I had to handle some other stuff during the last 45 minutes, so sorry for not voting too much
18:18:29 <adamw> proposed #agreed it's nap and/or lunch time
18:18:31 <cmurf> why not both? :D
18:18:37 <cmurf> *and*
18:18:39 <cmurf> haha
18:18:48 <cmurf> ack
18:19:42 <adamw> #agreed it's nap and/or lunch time
18:19:45 <adamw> thanks for coming, everyone
18:20:12 <adamw> #endmeeting