17:00:50 <adamw> #startmeeting F36-blocker-review
17:00:50 <zodbot> Meeting started Mon Feb  7 17:00:50 2022 UTC.
17:00:50 <zodbot> This meeting is logged and archived in a public location.
17:00:50 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:50 <zodbot> The meeting name has been set to 'f36-blocker-review'
17:00:55 <adamw> #meetingname F36-blocker-review
17:00:55 <zodbot> The meeting name has been set to 'f36-blocker-review'
17:00:58 <adamw> #topic Roll Call
17:01:08 <bcotton> .hello2
17:01:09 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:02:44 <coremodule> .hello2
17:02:45 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
17:04:47 <cmurf[m]> ha ok
17:04:59 <adamw> ahoyhoy folks, who's around for blocker review fun
17:05:24 <nielsenb> I'm here too
17:05:42 <adamw> brb, call of nature
17:09:37 <adamw> alrighty
17:09:46 <adamw> welcome to the first blocker review meeting of 2022! exciting times indeed
17:09:57 * pwhalen is here
17:09:59 <lruzicka> .hello lruzicka
17:10:00 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:10:03 <lruzicka> Aloha
17:10:16 * coremodule willing to act as secretary.
17:11:18 * cmurf[m] found the room afterall
17:11:42 <adamw> welcome cmurf
17:12:59 <adamw> #chair coremodule cmurf
17:12:59 <zodbot> Current chairs: adamw cmurf coremodule
17:13:06 <adamw> impending boilerplate alert
17:13:12 <adamw> #topic Introduction
17:13:16 <adamw> Why are we here?
17:13:21 <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.
17:13:25 <adamw> #info We'll be following the process outlined at:
17:13:29 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:13:33 <adamw> #info The bugs up for review today are available at:
17:13:38 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:13:41 <adamw> #info The criteria for release blocking bugs can be found at:
17:13:45 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
17:13:48 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria
17:13:51 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria
17:14:05 <adamw> #info for Beta, we have:
17:14:23 <adamw> #info 3 Proposed Blockers
17:14:27 <adamw> #info 3 Accepted Blockers
17:14:32 <adamw> #info for Final, we have:
17:14:42 <adamw> #info 5 Proposed Blockers
17:15:50 <adamw> #info coremodule will secretarialize
17:16:26 <adamw> let's get going with:
17:16:29 <adamw> #topic Proposed Beta blockers
17:16:56 <adamw> #topic (2032085) Some variants are missing /etc/resolv.conf symlink (use systemd-resolved)
17:16:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2032085
17:17:02 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/581
17:17:06 <adamw> #info Proposed Blocker, distribution, POST
17:17:10 <adamw> #info Ticket vote: BetaBlocker (+1,0,-3) (+sgallagh, -imsedgar, -nielsenb, -bcotton)
17:17:30 <adamw> so this goes to the topic we had in the qa meeting
17:17:51 <adamw> there's no criterion-breaking functionality breakage here, but we're not doing what we said we were gonna do
17:18:14 <adamw> personally i think it would be reasonable for fesco to declare this a blocker, but it's not a blocker by the release criteria
17:18:23 <nielsenb> https://bugzilla.redhat.com/show_bug.cgi?id=2032085#c20
17:18:26 <cmurf[m]> it's reasonable to reject it due to lack of criterion, so my thought is to do that, hope the pending upstream changes fix it, and if not, file a fesco ticket
17:18:35 <nielsenb> if I understand that comment correctly, it might soon become breaking?
17:18:59 <nielsenb> Wait, wrong comment
17:19:05 <nielsenb> comment 21
17:20:05 <adamw> good point
17:20:20 <adamw> but it's not yet, afaik :D
17:20:42 <nielsenb> Yeah, the anticipation is killing me.
17:21:04 <adamw> suggestion: we punt on this and file a ticket for fesco to consider it?
17:21:15 <pwhalen> +1 to the suggestion
17:21:17 <nielsenb> That's what I think would be best.
17:21:19 <nielsenb> +1
17:21:25 <lruzicka> +1
17:21:36 <bcotton> +1 to the punt-to-fesco
17:21:56 <cmurf[m]> +1 to punt to fesco
17:22:07 <adamw> eeeexcellent
17:23:23 <adamw> proposed #agreed 2032085 - punt (delay decision) - we don't think this qualifies as a blocker under the release criteria currently, but there seems to be a strong case for FESCo to declare it a blocker as current state is not at all how we want things to be, and this is an important area. so instead of rejecting, we will file a ticket for FESCo to consider declaring it a blocker (as they are allowed to do)
17:23:38 <lruzicka> ack
17:23:56 <coremodule> ack
17:24:02 <pwhalen> ack
17:24:52 <adamw> #agreed 2032085 - punt (delay decision) - we don't think this qualifies as a blocker under the release criteria currently, but there seems to be a strong case for FESCo to declare it a blocker as current state is not at all how we want things to be, and this is an important area. so instead of rejecting, we will file a ticket for FESCo to consider declaring it a blocker (as they are allowed to do)
17:25:08 <adamw> #topic (2017043) GNOME doesn't accept input from wireless keyboard if there's not another "keyboard" input available
17:25:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2017043
17:25:36 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/590
17:25:41 <adamw> #info Proposed Blocker, libinput, NEW
17:25:45 <adamw> #info Ticket vote: BetaBlocker (+2,0,-1) (+nielsenb, +lruzicka, -sgallagh)
17:25:49 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+sgallagh)
17:25:53 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+sgallagh)
17:27:12 <nielsenb> Per comment 19 in the bugzilla bug, it affects everything not x86
17:27:37 <nielsenb> In case you're wondering why the wireless keyboard you're typing on is working :)
17:28:44 <sgallagh> That reinforces my -1 for Beta :)
17:29:08 <nielsenb> Is aarch64 workstation not beta blocking?
17:29:20 <Southern_Gentlem> sgallagh, i thought arm was a blockng arch
17:30:14 <sgallagh> nielsenb: I think we block on aarch64 XFCE?
17:30:28 <nielsenb> "The current set of release-blocking desktops for x86_64 is GNOME and KDE, and for aarch64 is GNOME."
17:30:38 <bcotton> we don't block on anything for XFCE
17:30:40 <sgallagh> But my point was more around: how likely is it for someone NOT using x86_64 to be using a wireless keyboard?
17:30:41 <nielsenb> From the F36 release criteria
17:30:51 <sgallagh> I misremembered.
17:30:52 <Southern_Gentlem> +1 Blocker
17:30:55 <bcotton> #link https://docs.fedoraproject.org/en-US/releases/f36/blocking/
17:30:55 <nielsenb> I feel like it's more likely for an ARM device to be a couch computer?
17:31:09 <sgallagh> I think it's absolutely a blocker for Final.
17:31:14 <pwhalen> +1 blocker
17:31:16 <coremodule> agreed, I use wireless keyboards to test all my ARM installs...
17:31:19 <sgallagh> But at Beta, it wouldn't pass the "last blocker" test for me.
17:31:26 <cmurf[m]> oh my it's long
17:32:14 <lruzicka> sgallagh, I people had a film player run on Arm, wouldn't they want to use a remote keyboard? I guess so.
17:32:25 <adamw> sorry, i was looking in detail into the bug
17:32:33 <adamw> it looks a lot like this isn't really arm-specific
17:32:43 <sgallagh> I mean, it's an easy workaround to put into Common Bugs: use a wired keyboard.
17:33:08 <adamw> it's more that some code in mutter does not account for the possibility that a single device could have multiple capabilities (pointer, keyboard...)
17:33:18 <sgallagh> adamw: Right, but who on earth would use a wireless keyboard on ppc64le or s390x?
17:33:22 <adamw> so you hit the bug when using a device like that. doesn't matter what system it's connected to or what arch it is.
17:33:32 <nielsenb> Yeah, it's more luck it works with x86
17:33:48 <adamw> does it work with x86?
17:33:57 <sgallagh> It's absolutely worth fixing (and blocking Final for).
17:34:02 <nielsenb> The keyboards work, as far as I understand, yes
17:34:06 <lruzicka> we should also be very aware of the proposed common bugs process - people might feel confused
17:34:08 <adamw> hmm, bug report says it does
17:34:14 <adamw> but...that seems odd.
17:34:18 <nielsenb> Because the multi capability enumeration only fails if it's the first input device enumerated
17:34:23 <sgallagh> But I would absolutely vote against slipping if this was the last bug at Go/No-Go
17:34:31 <nielsenb> And x86 has some "virtual" device always connected for some reason
17:34:43 <nielsenb> At least that's my interpretation
17:34:46 <sgallagh> (Particularly since futzing with low-level mutter stuff during Freeze almost always has side-effects)
17:35:05 <adamw> ah, i wonder if the enumeration of capabilities is changing in different configs
17:35:12 <bcotton> well we're still two weeks away from beta freeze
17:35:17 <adamw> although...hmm...i don't see why that should matter. humf.
17:35:30 <cmurf[m]> what's the criterion?
17:35:53 <cmurf[m]> I'm -1 beta blocker, +1 final blocker, and +1 beta common bugs
17:36:05 <nielsenb> Definitely +1 to beta common bugs
17:36:08 <cmurf[m]> this is before i know what criterion 😛
17:36:10 <adamw> ah, ok, pbrobinson suggested a reason why it works on x86_64, i missed that
17:37:18 <adamw> i kinda don't like the idea that we'd be ok with this because it 'only' affects aarch64. they're supposed to be equally important, really.
17:37:26 <adamw> if it "only" affected x86_64 but aarch64 was fine, would we block on it?
17:37:35 <nielsenb> It feels like a bad "look" to me to push a beta that may not work for a decent subset of people
17:37:38 <lruzicka> adamw, I believe we would
17:38:00 <nielsenb> I would hope people using betas would check the common bugs
17:38:04 <lruzicka> nielsenb, I agree
17:38:09 <sgallagh> adamw: But it's specific to hardware configurations using wireless keyboards
17:38:21 <nielsenb> And specific wireless keyboards at that, apparently
17:38:26 <sgallagh> It's not that it's aarch64, it's an issue around a certain hardware.
17:38:26 <bcotton> i'm definitely not okay with it for final. still trying to figure out how i feel about beta
17:38:42 <sgallagh> And if that's the case, we make a judgement call about how many people will hit it.
17:38:51 <sgallagh> Same as with x86_64
17:38:58 <adamw> well, i think the specific requirement is "only having input devices with multiple capabilities connected"
17:39:19 <adamw> the ones we happen to know about are wireless, but i guess there could be a wired multi-capability input device. i've no idea if there is.
17:39:41 <nielsenb> I used to a Logictech USB one, but unfortunately no longer do
17:39:47 <nielsenb> So I can't really test
17:39:53 <nielsenb> But they do exist
17:39:55 <adamw> nielsenb: it's likely "ones using dongles that also support wireless mice". don't know if you actually have to have a wireless mouse also connected to the same dongle, or the dongle just has to have the capability.
17:40:26 <adamw> nielsenb: it would depend also on how it presents itself to the OS - it could represent itself as two different input devices even though it's physically one thing, i guess
17:40:27 <lruzicka> yeah, I have once had a keyboard with a touchpad ... I no longer do
17:40:29 <adamw> anyway, where are we with votes...
17:40:58 <bcotton> 0 BetaBlocker, +1 BetaFE
17:41:07 <coremodule> I have 4 wireless keyboard/trackpad combos that I use everyday for testing various hardware... mostly ARM stuff, but some x86. For me, this is a blocker, having to test several raspberry pies with a separate wired mouse and wired keyboard attached to each is more hardware to buy and more mess when running multiple at once
17:41:13 <sgallagh> I remain +1 FinalBlocker, -1 BetaBlocker, -1 BetaFE, +1 BetaCommonBugs
17:41:25 <nielsenb> +1 BetaBlocker
17:41:26 <adamw> honestly i think i'm +1 beta. i get sgallagh's argument, but this is just a pretty bad bug for people who hit it.
17:41:36 <nielsenb> Though I understand and appreciate both sides
17:41:40 <adamw> coremodule: is that a +1 vote?
17:41:42 <coremodule> +1 beta blocker, +1 final blocker, +1 common bugs
17:41:45 <lruzicka> I agree, +1 betablocker
17:41:47 <adamw> ok
17:42:04 <adamw> lruzicka and nielsenb were already counted in the ticket, so we're at +4 / -1 i believe
17:42:13 <pwhalen> +1 blocker here to
17:42:15 <pwhalen> too
17:42:24 <adamw> ok, +5/-1, that's clear enough
17:43:04 <sgallagh> I'll just make sure I have my "I Told You So" stamp ready when we get to Go/No-Go ;-)
17:43:28 <adamw> proposed #agreed 2017043 - AcceptedBlocker (Beta) - accepted as a conditional violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" (can't log in or create user if you can't type) on affected systems (aarch64 with multi-capability input device)
17:43:35 <adamw> did that fit on IRC?
17:43:39 <coremodule> yes
17:43:42 <lruzicka> yes, ack
17:43:43 <adamw> yay
17:43:44 <coremodule> ack
17:43:44 <bcotton> ack
17:43:46 <nielsenb> yes
17:43:48 <sgallagh> ack
17:43:49 <nielsenb> ack
17:43:49 <cmurf[m]> ack
17:43:57 <adamw> #agreed 2017043 - AcceptedBlocker (Beta) - accepted as a conditional violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" (can't log in or create user if you can't type) on affected systems (aarch64 with multi-capability input device)
17:44:03 <adamw> Stephen Gallagher: i will go and fix the bug just to spite you
17:44:19 <sgallagh> adamw: I approve of this
17:44:27 <adamw> dangit
17:44:41 <bcotton> spite-driving development is the most effective development methodology
17:44:54 <adamw> quick, write a blog post and get a book deal, we'll be reach
17:44:58 <sgallagh> Honestly, my ideal here is that it gets fixed before Freeze and this is all academic.
17:45:02 <adamw> somebody call O'Reilly
17:45:07 <sgallagh> Bill?
17:45:11 <nielsenb> Do we need a 'spite-master'?
17:45:30 <adamw> no, the ones who print all the books.
17:45:41 <sgallagh> (I know, I was being an ass)
17:45:53 <adamw> oh, apparently they're trying to be a Learning Platform now
17:46:03 <adamw> quick, somebody call O'Reilly and get us a...learning platform...deal
17:46:21 <adamw> #topic (2008179) tpm2_createprimary fails
17:46:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2008179
17:46:30 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/588
17:46:35 <adamw> #info Proposed Blocker, tpm2-tss, ASSIGNED
17:46:39 <adamw> #info Ticket vote: BetaBlocker (+0,0,-3) (-sgallagh, -nielsenb, -bcotton)
17:46:43 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+bcotton)
17:46:47 <adamw> #info Ticket vote: BetaFreezeException (+0,0,-1) (-sgallagh)
17:46:50 <adamw> so as noted, this has =3
17:46:53 <cmurf[m]> there is an iot requirement
17:46:53 <adamw> er, -3
17:46:55 <cmurf[m]> https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Automatic_partition_decryption_.28Clevis.29
17:47:01 <adamw> but i thought i'd bring it to the floor in case someone wants to make the case for it here
17:47:04 <adamw> thanks cmur
17:47:05 <adamw> f
17:47:42 <sgallagh> cmurf: That's for Final, FYI
17:47:58 <nielsenb> Yeah, definitely a final blocker
17:47:58 <cmurf[m]> comment 3, maybe we should find out if IoT is affected?
17:48:13 <cmurf[m]> because that's the only edition the final release criterion applies to at the moment
17:48:37 <nielsenb> Fair point
17:48:39 <sgallagh> I could be +1 FinalBlocker here.
17:49:05 <cmurf[m]> if IoT then +1 final blocker, per criterion
17:49:31 <adamw> well, it would be nice to confirm that workflow is actually affected
17:50:03 <adamw> i'm pinging dusty
17:50:41 <sgallagh> Well, are we agreed that it's NOT a Beta blocker?
17:50:53 <sgallagh> If so, let's put a pin in the Final discussion and move on.
17:51:01 <adamw> i was pinging dusty to see if he has any justification for that
17:52:50 <adamw> but i guess not, so
17:53:11 <adamw> proposed #agreed 2008179 - RejectedBlocker (Beta) - this does not appear to violate any Beta criteria
17:53:12 <cmurf[m]> needinfo and punt to next week
17:53:21 <adamw> oh, now he replied. :D
17:53:23 <adamw> hold on
17:54:01 <adamw> dustymabe: ahoy
17:54:17 <adamw> so, we were about to reject https://bugzilla.redhat.com/show_bug.cgi?id=2008179 , but is there a justification we're missing for it to block beta?
17:54:41 <adamw> we aren't aware of any criteria for it. there's an IoT Final criterion for TPM-based encryption, but that's all we've got
17:55:43 <cmurf[m]> ergo if the problem reproduces on IoT edition then it might be a final blocker 😉
17:55:50 <dustymabe> I don't know of a specific criteria. It basically breaks any users who currently rely on that functionality and upgrade IIUC
17:56:24 <cmurf[m]> at the moment we only have a final release criterion for TPM/Clevis functionality for IoT edition
17:56:30 <dustymabe> the bug has been open for months - we could have reverted tpm2 to the older version when the bug was introduced
17:56:50 <dustymabe> we still have the older version pinned in FCOS which is why our tests are still passing
17:57:24 <dustymabe> I just don't understand why we would choose to leave it broken in rawhide and not revert it
17:58:09 <adamw> dustymabe: the bug doesn't actually seem to mention that an older version of tpm2 works?
17:58:15 <adamw> it's all about how it doesn't work with a newer openssl
17:58:39 <dustymabe> adamw: sorry, I guess that's implied (i.e. was working, now broken)
17:58:41 <adamw> "revert to an even older version" isn't an immediately obvious solution to that problem. so, unless you told him some other way, maybe peter didn't know of the possibility?
17:58:56 <dustymabe> here's our FCOS issue tracker for it: https://github.com/coreos/fedora-coreos-tracker/issues/968
17:59:05 <adamw> "Started happening with tpm2-tss-3.1.0-4.fc36, which was rebuilt for OpenSSL 3.0.0"
17:59:22 <adamw> to me i wouldn't read that as meaning "so just downgrade to an older tpm2 and everything will be fine" heh
17:59:34 <sgallagh> I suspect it's a problem that could be resolved by building against openssl 1.2 compat
17:59:41 <adamw> note, in rawhide we can't literally just revert to an older package, that is not allowed
17:59:53 <adamw> anyhow
18:00:01 <dustymabe> adamw: could you not bump epoch and rebuild ?
18:00:17 <adamw> dusty: we could, but it'd still be built against openssl 3 in that case, wouldn't it?
18:00:19 <adamw> anyhow
18:00:31 <adamw> let's go back to the proposal...
18:00:35 <adamw> but i'm gonna patch it a bit
18:01:02 <dustymabe> adamw: k - just let me know what comment I should add to the bug (sorry there was missing info)
18:01:18 <adamw> proposed #agreed 2008179 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this does not appear to violate any Beta criteria, but it's useful functionality and would be a showstopper for anyone using it on F35 who upgrades to F36, so accepted as an FE issue
18:01:30 <bcotton> ack
18:01:32 <lruzicka> ack
18:01:38 <adamw> dustymabe: i'll try and remember to add a comment later
18:01:40 <nielsenb> ack
18:01:44 <sgallagh> ehhh, I'm not thrilled with having it as an FE, but okay.
18:01:57 <adamw> Stephen Gallagher: sorry, i should've asked for votes on that i guess
18:02:15 <adamw> what do people feel about FE?
18:02:19 <lruzicka> sgallagh, do you think it's dangerous?
18:02:29 <sgallagh> I explained my justification here: https://pagure.io/fedora-qa/blocker-review/issue/588#comment-778016
18:02:32 <dustymabe> I admittedly don't know enough about TPM2 stuff (I'm just the FCOS mule that looks at test failures)
18:02:32 <adamw> since it is something we block on for Final, and dusty makes a point about upgraders, FE seems reasonable to me
18:02:33 <bcotton> +1 FE. if the fix makes it worse, we're not obligated to accept it
18:02:47 <dustymabe> but what happens if someone is depending on this and upgrades to the beta?
18:03:03 <adamw> Stephen Gallagher: if the bug is "TPM doesn't work", I'm having trouble seeing how an update to tpm packages could make things much worse :D
18:03:26 <adamw> dustymabe: it breaks. we *do* tell people not to use beta in production. it's a beta.
18:03:41 <sgallagh> The bug is "TPM doesn't work for auto-decryption" and could end up with "Fixes auto-decryption, breaks all other usages"
18:04:06 <nielsenb> Do we actually know it doesn't work for auto decryption? The bug is SSL
18:04:23 <sgallagh> Anyway, I've said my piece and Ben is correct; we don't have to accept it if it looks too dangerous.
18:05:06 <nielsenb> I do tend to agree it's risky, but we can back out...
18:05:12 <dustymabe> either way I'd like to thank you all for considering this and helping me navigate this process
18:05:21 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=2008179#c6 says it breaks other things
18:05:49 <adamw> so yeah, i think i'm +1 FE
18:05:50 <adamw> any other votes?
18:05:51 <nielsenb> So yeah...
18:05:54 <nielsenb> +1 FE
18:06:40 * dustymabe can't vote
18:07:01 <lruzicka> +1 FE, if there is an option to bail out
18:07:21 <adamw> there always is
18:07:28 <pwhalen> +1 FE
18:07:42 <adamw> and it depends entirely on my cursory, possibly-hungover inspection of the bugs when filing the push request
18:07:45 <adamw> there, don't you feel re-assured
18:07:57 <adamw> OK, so, same proposal:
18:08:23 <adamw> proposed #agreed 2008179 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this does not appear to violate any Beta criteria, but it's useful functionality and would be a showstopper for anyone using it on F35 who upgrades to F36, so accepted as an FE issue
18:08:23 <sgallagh> ack
18:08:27 <bcotton> ack again (just like tag team)
18:08:34 <lruzicka> ack
18:08:40 <nielsenb> ack
18:09:01 <adamw> i feel like proposing it again just to mess with you
18:09:06 <adamw> #agreed 2008179 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this does not appear to violate any Beta criteria, but it's useful functionality and would be a showstopper for anyone using it on F35 who upgrades to F36, so accepted as an FE issue
18:09:31 <adamw> ok, moving on to:
18:09:35 <adamw> #topic Proposed Final blockers
18:09:39 <cmurf[m]> ack
18:09:43 <cmurf[m]> oops
18:09:54 <adamw> oh, coremodule, when secretarializing, can you propose that tpm bug as a final blocker?
18:10:04 <coremodule> sure will
18:10:14 <adamw> we'll need to ask pbrobinson to confirm if it affects IoT, I guess. openQA would, but IoT composes don't seem to be...happening
18:10:22 <adamw> there hasn't been one at all for like a month, and no 36 one yet
18:10:41 <adamw> #topic (2050615) Printing not possible over Cups-PDF in Rawhide
18:10:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2050615
18:10:46 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/600
18:10:50 <adamw> #info Proposed Blocker, cups-pdf, NEW
18:10:54 <adamw> #info Ticket vote: FinalBlocker (+2,0,-0) (+nielsenb, +lruzicka)
18:11:07 <lruzicka> I still think +1
18:11:18 <cmurf[m]> i just added a comment to it
18:11:40 <adamw> so, i'm not sure about this
18:12:00 <adamw> i don't recall why we use cups-pdf in the openqa tests, but i don't think cups-pdf actually *is* "the built-in print-to-PDF driver", is it?
18:12:41 <adamw> i don't have cups-pdf installed, but i can "Print to File" from gedit and there's a "PDF" choice for "Output format:"
18:12:59 <pwhalen> adamw: it does affect iot, the composes have been broken due to https://bugzilla.redhat.com/show_bug.cgi?id=2034360
18:13:01 <adamw> not sure about KDE off the top of my head
18:13:12 <adamw> pwhalen: thanks
18:13:42 <sgallagh> I saw that got fixed this morning, so hopefully tomorrow the composes will resurrect.
18:13:46 <lruzicka> adamw, well, I believe I have used this to go through the process of installing a printer to the system and confirm it worked
18:14:16 <nielsenb> Huh, I don't have it installed either.
18:14:27 <lruzicka> adamw, I know however, that you could go like "Save as PDF" without the need to install the printer.
18:14:32 <nielsenb> And I definitely have a Print to PDF option, but this is Gnome
18:15:20 <lruzicka> nielsenb, it seems that gnome tools convert to pdf automatically, and they either send it to the file or to the real printer
18:15:26 <adamw> yeah, so, hmm, we're kinda in an awkward position here...
18:15:54 <adamw> the test is set up the way it is for a reason (to test that you can "add a printer" and that works), and it finds a real bug, but the real bug isn't exactly covered by the criteria...
18:15:58 <lruzicka> adamw, we are not ... let's punt this and I will look into it more, if you can save into PDF on KDE as well
18:16:20 <lruzicka> adamw, oh .. yeah, you are right
18:16:22 <nielsenb> The more I interact with the printing stack, the more I realize I have no idea how any of it works...
18:16:31 <adamw> haha, i know right
18:16:48 <adamw> i feel like we had this side discussion somewhere about whether cups-pdf was a good idea, but it's not in the PR or anywhere i can find right now
18:17:04 <adamw> there might even have been a mention that it might go away, but i might be misremembering
18:17:48 <cmurf[m]> i don't know what cups-pdf does
18:18:01 <adamw> cmurf: it's basically a fake printer that just prints to a PDF file
18:18:11 <cmurf[m]> but if printing a pdf via ipp doesn't work... that'd be a problem
18:18:12 <cmurf[m]> ahh
18:18:12 <adamw> so you have print-to-PDF functionality in any context you can use CUPS
18:18:15 <nielsenb> It makes PDF files out of cups, tea cups, coffee cups, anything really
18:18:18 <nielsenb> :)
18:18:24 <adamw> also that, yes
18:18:33 <cmurf[m]> so print to pdf file must be implemented in GNOME without cups-pdf, i also don't have it
18:18:44 <lruzicka> cmurf[m], it sure is
18:19:17 <lruzicka> cmurf[m], there is the "Save as PDF" option that can be used even without cups-pdf
18:19:31 <nielsenb> I think CUPS even has a built in PDF filter these days
18:19:41 <cmurf[m]> right, I think that's what's referred to as "The built-in print-to-PDF driver"
18:19:44 <lruzicka> however, I thought that if cups-pdf worked, there I might believe, regular cups printing worked, too
18:20:18 <lruzicka> when I was writing that test case
18:20:31 <adamw> lruzicka: yeah, like i said, i can see value in the test using cups-pdf because it's a bit closer to testing that a 'real' printer would work than the built-in PDF functionality is
18:20:36 <nielsenb> Right, it makes sense as something to use for testing the 'add a printer' user flow
18:20:45 <adamw> but it means the test winds up not exactly hitting either of the scenarios covered by the criteria :/
18:20:50 <nielsenb> Yeah
18:21:14 <cmurf[m]> i see, makes sense
18:21:21 <adamw> so, for the purposes of this meeting...
18:21:33 <nielsenb> I guess you could argue it is still a blocker under the 'makes testing harder' criterion
18:21:37 <adamw> i think i'm either -1 or punt because this bug seems to be in cups-pdf which isn't actually covered
18:21:40 <nielsenb> But I would rather not
18:21:52 <adamw> nielsenb: yeah, for this case i'd say that's more a problem for us on the test writing side
18:21:55 <lruzicka> ok, I am ok with making it -1
18:22:04 <nielsenb> -1 FinalBlocker
18:22:11 <nielsenb> Do I need to change my vote on Pagure?
18:22:12 <adamw> this would be a blocker if 'built-in' PDF printing or printing to a real physical printer failed similarly
18:22:15 <adamw> (I can actually test that later)
18:22:26 <adamw> nielsenb: no, votes in this meeting override votes in the app
18:22:27 <lruzicka> what if we punted and I would check KDE until next time?:
18:22:30 <lruzicka> we still have time
18:22:43 <adamw> lruzicka: we can probably check KDE from screenshots, actually, let me see
18:22:54 <lruzicka> adamw, ok
18:23:17 <adamw> oh, no, the way the UI is i can't see for sure. darn
18:23:22 <adamw> do i have a KDE vm hooked up...
18:26:49 <lruzicka> adamw, I have started one
18:27:00 <lruzicka> adamw, I will check it in 5 minutes
18:27:27 <adamw> i have one running already
18:27:53 <adamw> yeah, looks like KDE has a native "Print to File (PDF)" printer even without cups-pdf installed.
18:28:11 <adamw> so, those are the features the criterion covers. we'll have to figure out what we want to do about this in the openqa tests outside of the meeting
18:28:41 <adamw> so we're at -3 now
18:29:16 <lruzicka> adamw, I can confirm.
18:29:20 <lruzicka> -1 from me
18:29:42 <adamw> proposed #agreed 2050615 - RejectedBlocker (Final) - this bug appears to be specific to the cups-pdf virtual printer, which isn't actually covered by the criteria. We will revisit if it turns out to affect GNOME's or KDE's built-in PDF printing features, or a real physical printer. we'll consider whether and how to adjust the openQA tests as well
18:29:42 <lruzicka> I am going to change the tests tomorrow to use the native print out options.
18:29:46 <lruzicka> ack
18:29:53 <nielsenb> ack
18:30:10 <adamw> in a way it might be nice to do both, but not sure if it's worth the effort, especially since it's a kinda fragile test :|
18:30:53 <lruzicka> adamw, well ... why not, we might do both :)
18:31:19 <lruzicka> the problem seems to be in the invocation command of ghostcript
18:31:28 <lruzicka> I believe it will be fixed soon anyway
18:31:51 <adamw> ok, cool
18:31:55 <adamw> one more ack?
18:32:38 <lruzicka> alter ego ack
18:32:48 <coremodule> ack
18:32:55 <lruzicka> thank you, coremodule
18:32:57 <cmurf[m]> ack
18:33:02 <lruzicka> thank you, cmurf[m]
18:33:06 <cmurf[m]> without the admiral
18:34:13 <adamw> hehe
18:34:17 <adamw> #agreed 2050615 - RejectedBlocker (Final) - this bug appears to be specific to the cups-pdf virtual printer, which isn't actually covered by the criteria. We will revisit if it turns out to affect GNOME's or KDE's built-in PDF printing features, or a real physical printer. we'll consider whether and how to adjust the openQA tests as well
18:34:28 <adamw> #topic (2049849) Windows with bitlocker enabled can't be booted, needs to use bootnext instead of chainloader
18:34:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2049849
18:34:35 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/597
18:34:38 <adamw> #info Proposed Blocker, grub2, NEW
18:35:12 <lruzicka> +1 final blocker
18:35:15 <nielsenb> This one is hard for me
18:35:42 <nielsenb> Without it being fixed, Fedora can't really be a drop in dual boot option on machines shipping Windows 11
18:36:00 <lruzicka> but?
18:36:12 <adamw> cmurf: so this basically affects newer Windows pre-installs?
18:36:14 <nielsenb> We explicitly waive blocking on Secure Boot don't yet?
18:36:19 <nielsenb> *don't we?
18:36:30 <adamw> no, we explicitly include it.
18:36:46 <nielsenb> "The bootloader entry part of this criterion does not apply when Secure Boot is enabled (because it has not yet been made to work, and fixing it is not trivial). cases. "
18:36:59 <adamw> oh, i was thinking of elsewhere
18:37:15 <nielsenb> So I think we already don't work on these machines
18:37:33 <cmurf[m]> oh oops where are we
18:37:41 <nielsenb> https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dual_boot
18:37:45 <cmurf[m]> by we i mean me
18:37:46 <adamw> yes, good point
18:37:56 <adamw> i honestly am not very experienced in this area, cmurf is the expert
18:38:05 <adamw> cmurf, do you remember what the deal with that SB carve-out for dualboot is/was?
18:38:13 <cmurf[m]> this affects any recent system possibly for some time now
18:38:13 <adamw> and how does it relate here?
18:38:49 <cmurf[m]> did we have a carve out for dual boot SB?
18:39:34 <cmurf[m]> the gist is that our Windows boot option in GRUB is increasingly unlikely to work - you just get a blue screen that says enter your bitlocker recovery key instead of Windows booting to a login prompt
18:39:51 <cmurf[m]> new Lenovo laptop out of the box last June is when i first came across it
18:39:54 <lruzicka> cmurf[m], what happens if you have the key?
18:39:57 <adamw> cmurf: nielsenb just pasted it
18:40:00 <cmurf[m]> and it's not even that new, X1 Carbon Gen 7
18:40:07 <adamw> https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dual_boot
18:40:10 <cmurf[m]> if you have the key you can enter it and boot
18:40:15 <adamw> "Secure Boot excepted" footnote
18:40:32 <lruzicka> we have also had an issue with this on Fedora Installfest and we basically destroyed a guy's windows installation
18:40:35 <cmurf[m]> this is not a Secure Boot related issue though
18:40:47 <cmurf[m]> it'd happen even without SB enabled
18:40:49 <nielsenb> But if you disable secure boot to install, you will now also trip the TPM, right?
18:41:01 <adamw> not directly, but will there ever be a system that's affected by this but does not have SB on?
18:41:12 <cmurf[m]> lruzicka: tell me more (just not here, maybe in #fedora-qa:libera.chat
18:41:30 <cmurf[m]> i'm not sure how to answer it
18:41:36 <cmurf[m]> if i turn off SB, the problem still happens
18:41:56 <adamw> would windows even boot in that case though? i just kinda thought microsoft was tying these features together, but imbw
18:41:58 <nielsenb> and Windows with bitlocker enabled will still boot?
18:42:00 <cmurf[m]> in practice, SB will be on any time there's a laptop with TPM 2.0 on it even though the features are orthogonal
18:42:11 <cmurf[m]> you can boot Windows 10 with SB off
18:42:26 <cmurf[m]> i don't know about 11, have been avoiding it so far
18:42:39 <nielsenb> But if you have a system with SB and TPM enabled, Windows installed, bitlocker enabled, then turn SB off, will Windows boot?
18:42:57 <cmurf[m]> sure
18:43:06 <cmurf[m]> measured boot is not related to Secure Boot
18:43:06 <nielsenb> Interesting
18:43:22 <cmurf[m]> Secure Boot just means it's checking for signed bootloaders (EFI binaries)
18:43:30 <nielsenb> Then they are purely orthogonal
18:43:36 <cmurf[m]> measured boot is a separate thing you can do with or without Secure Boot
18:43:36 <nielsenb> And the SB carve out doesn't apply here
18:43:50 <nielsenb> At least as far as I now understand it
18:43:59 <cmurf[m]> yeah pretty sure the SB carve out doesn't apply
18:45:02 <adamw> yeah, i agree it doesn't apply directly, i was just wondering that if we know dualboot like this doesn't work with SB, maybe it makes this bug practically less important
18:45:02 <adamw> anyhow
18:45:16 <adamw> is the SB carve-out still valid? does grub dualboot still not work with SB?
18:45:46 <cmurf[m]> it works
18:46:02 <cmurf[m]> for a long time you can boot Windows via GRUB with Secure Boot enabled
18:46:09 <cmurf[m]> everything is signed so it boots
18:47:01 <nielsenb> Do we have any idea how common Bitlocker is on preloads?
18:47:10 <cmurf[m]> increasingly common
18:47:16 <nielsenb> Figured
18:47:32 <cmurf[m]> mine was out of the box, gen 7 X1 Carbon (what is that about 2 years old?)
18:47:55 <nielsenb> Though more of an enterprise class machine
18:47:58 <cmurf[m]> and when i downloaded a Windows 10 ISO from microsoft.com and obliterated the Lenovo OEM copy of Windows 10 - it too used bitlocker by default
18:48:08 <adamw> okay, so maybe we should ditch that carveout, but by the same token, this bug gets more important...
18:48:12 <nielsenb> Okay, if it's using it by default
18:48:23 <nielsenb> This is really unfortunate
18:48:28 <cmurf[m]> yeah
18:48:51 <cmurf[m]> but being super precise about our existing language, our bootloader does still boot windows, just not to a login prompt
18:48:56 <cmurf[m]> we get a recovery prompt
18:49:13 <adamw> hmm, i think i'd still count that as not working right, heh
18:49:18 <cmurf[m]> does "boot into Windows" mean the login window? or the Windows kernel? 😛
18:49:39 <adamw> i do try to avoid wordsmithing to the extent the criteria read like a terms & conditions document. it's a fine balance. :D
18:49:42 <cmurf[m]> yeah that's probably our intent is to not disturb what the user expects to happen
18:49:45 <lruzicka> cmurf[m], I would like to know what happens if you boot to the recovery prompt and you recover using the Bitlocker key?
18:49:55 <lruzicka> cmurf[m], is it the same on the next boot, too?
18:49:56 <cmurf[m]> works
18:50:01 <nielsenb> I'd rather err on the side of not making people go "what did you do to my machine‽"
18:50:07 <cmurf[m]> nope, one time thing each time
18:50:19 <cmurf[m]> i have to enter the key every time
18:50:28 <cmurf[m]> it's a long ass key too haha
18:50:29 <lruzicka> so this sucks
18:50:33 <nielsenb> Gross
18:50:39 <cmurf[m]> is the machine generated type of recovery key
18:50:58 <adamw> urgh, yeah, that doesn't seem practical
18:51:00 <adamw> one time maybe
18:51:02 <adamw> every time, no
18:51:06 <lruzicka> yeah, it's like a windows installation key
18:51:16 <cmurf[m]> in particular, since it's enabled by default, you don't get an obvious "oh hey by the way here is your recovery key save this in a good spot" warning
18:51:24 <adamw> i guess i'm kinda leaning +1 with all relevant info
18:51:30 <nielsenb> How did you get the key?
18:51:34 <nielsenb> Asking for a friend
18:51:37 <nielsenb> :)
18:51:38 <adamw> it's a conditional blocker, but it's clearly happening already and likely to get worse through 36's life
18:51:45 <cmurf[m]> i forget, there is a way though
18:52:04 <cmurf[m]> i'm on board with it being a conditional blocker
18:52:08 <nielsenb> Yeah, I really don't like that this is basically asking _someone_ to change boot, which is a feature, not a bug
18:52:21 <nielsenb> But on the other hand, ew
18:52:25 <lruzicka> I am so happy not to be using windows
18:52:29 <cmurf[m]> it's a question for javierm and/or rharwood whether this must come from upstream
18:52:39 <cmurf[m]> or if they'd carry a patch and if so how to do it
18:52:45 <adamw> how practical is it for grub to be setting BootNext and rebooting the system? is this something that's been done/considered before or elsewhere?
18:52:57 <cmurf[m]> so it might still get punted for practical reasons to f37 if it's too hard to do in the 36 time frame
18:53:09 <adamw> anyhow, we can take it for now and reconsider later if it turns out to be considered unfixable
18:53:12 <cmurf[m]> yeah i've discussed it a few times with Javier
18:53:48 <adamw> i guess we can ask javier/robbie to chime in soon so we can make a decision before it gets too late
18:53:51 <nielsenb> Unfortunate timing too, I feel like interest in desktop Linux is increasing somewhat with press coverage
18:54:02 <nielsenb> And dual booting easily is a part of that
18:54:16 <adamw> so, other votes?
18:54:20 <nielsenb> +1 FinalBlocker
18:54:34 <lruzicka> +1 for now
18:54:39 <cmurf[m]> For sure we can common bugs this at the least, and improve documentation how users can still boot Windows directly - in which case they don't need to enter the key manually or even have the key
18:54:49 <cmurf[m]> +1 final blocker
18:54:55 <lruzicka> cmurf[m], great idea
18:55:01 <cmurf[m]> i've got to bug out but i'll be lurking by mobile
18:55:32 <cmurf[m]> there is no data loss here but it might appear there's data loss if you don't know you can boot windows without grub still...
18:55:46 <lruzicka> I am sorry but I need to go, children need to go to bed and I am occupying their room, will read the rest from the meeting minutes.
18:55:52 <lruzicka> take care
18:56:36 <adamw> proposed #agreed 2049849 - AcceptedBlocker (Final) - accepted as a conditional violation of Final criterion "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora" in the case of Windows being installed with Bitlocker enabled (as is increasingly common). We recognize this is technically difficult to fix and may change
18:56:36 <adamw> or defer this status based on feedback from the grub maintainers
18:56:50 <adamw> cya lruzicka, we're nearly done
18:56:51 <adamw> thanks for coming
18:57:05 <nielsenb> ack
18:57:11 <Southern_Gentlem> ack
18:58:26 <cmurf[m]> Elevator ack
18:59:54 <adamw> #agreed 2049849 - AcceptedBlocker (Final) - accepted as a conditional violation of Final criterion "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora" in the case of Windows being installed with Bitlocker enabled (as is increasingly common). We recognize this is technically difficult to fix and may change or defer
18:59:54 <adamw> this status based on feedback from the grub maintainers
19:00:05 <adamw> #topic (2020759) [abrt] dma_alloc_noncontiguous: WARNING: CPU: 0 PID: 1429 at kernel/dma/debug.c:1162 debug_dma_map_sg+0x32a/0x380
19:00:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2020759
19:00:12 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/580
19:00:15 <adamw> #info Proposed Blocker, kernel, NEW
19:00:20 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+nielsenb)
19:01:10 <nielsenb> I can reproduce on a fresh install of the latest compose, on first boot
19:03:26 <adamw> seems pretty +1-y if it's appearing as a notification for everyone
19:04:50 <coremodule> yeah, agreed
19:04:56 <coremodule> +1 blocker
19:05:08 <coremodule> *+1 final blokcer
19:05:27 <adamw> so that's +3
19:05:55 <adamw> proposed #agreed 2020759 - AcceptedBlocker (Final) - accepted as a violation of Final criterion "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
19:06:00 <coremodule> ack
19:06:03 <nielsenb> ack
19:06:37 <Southern_Gentlem> ack
19:07:03 <Southern_Gentlem> +1fb
19:07:28 <adamw> #agreed 2020759 - AcceptedBlocker (Final) - accepted as a violation of Final criterion "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."
19:08:31 <adamw> #topic (2042877) crash happens on the newly installed system
19:08:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2042877
19:08:39 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/595
19:08:41 <adamw> #info Proposed Blocker, spice-vdagent, NEW
19:09:00 <nielsenb> I was unable to reproduce.
19:09:24 <coremodule> +1 punt for more testing
19:09:39 <coremodule> I'll mess around with this and try to reproduce
19:09:44 <nielsenb> Yeah, if punt is an option, I vote punt
19:09:53 <nielsenb> Because as soon as I say no, I'll run into it and feel silly
19:10:05 <adamw> hmm, yeah, i haven't seen that on any of my vm attempts either
19:10:10 <adamw> so yeah, punt and ask for more details seems good
19:10:12 <adamw> haha yes
19:10:14 <adamw> that always happens
19:10:27 <adamw> "you're crazy, that's not happening to me!...oh wait"
19:11:44 <Southern_Gentlem> +1 punt
19:11:53 <adamw> proposed #agreed 2042877 - punt (delay decision) - other testers have not immediately been able to reproduce this, we will ask lili for more details on the scenario and try again to reproduce
19:12:04 <coremodule> ack
19:12:08 <nielsenb> ack
19:12:12 <Southern_Gentlem> ack
19:14:40 <adamw> #agreed 2042877 - punt (delay decision) - other testers have not immediately been able to reproduce this, we will ask lili for more details on the scenario and try again to reproduce
19:14:59 <adamw> #topic (2006393) [DNS over TLS] following connection to a wifi AP, internet is not available for ~30s
19:15:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2006393
19:15:09 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/579
19:15:13 <adamw> #info Proposed Blocker, systemd, ASSIGNED
19:16:05 <nielsenb> Again, unsure, looks like it may be fixed soon upstream
19:16:17 <nielsenb> Comment 9 implies it may at least be somewhat hardware dependent
19:16:51 <coremodule> what did we do for this on f35?
19:17:13 <nielsenb> Ignored it and hoped it went away :D
19:17:15 <adamw> we disabled dns-over-tls
19:17:33 <adamw> the PR mentioned in the bug was merged long ago
19:17:38 <adamw> so this ought to be fixed now
19:17:40 <adamw> cmurf, have you re-tested it?
19:18:15 <nielsenb> And does it still happen if you try with a 'cloud' DoH provider instead of your router?
19:18:37 <nielsenb> I guess this is DoT
19:20:15 <adamw> gonna propose we punt to ask cmurf for info on current status
19:20:20 <nielsenb> Yeah
19:20:39 <coremodule> I'm good with that
19:20:44 <adamw> proposed #agreed 2006393 - punt (delay decision) - this is an automatic transfer from F35 and we don't know the exact status of F36 currently wrt this bug. delaying decision to ask cmurf to report back on how F36 is
19:20:44 <coremodule> +1 punt for cmurf
19:21:20 <Southern_Gentlem> cmurf punt +1
19:21:29 <coremodule> ack
19:21:30 <nielsenb> +1
19:21:37 <Southern_Gentlem> +1
19:21:53 <nielsenb> ack
19:22:24 <adamw> #agreed 2006393 - punt (delay decision) - this is an automatic transfer from F35 and we don't know the exact status of F36 currently wrt this bug. delaying decision to ask cmurf to report back on how F36 is
19:22:29 <adamw> alrighty, and with that we're through the list
19:22:33 <adamw> #topic Open floor
19:22:37 <adamw> any other business, folks?
19:23:38 <coremodule> nothing of note here
19:24:20 <nielsenb> nope
19:26:45 <adamw> alrighty, then thanks a lot for coming out! really appreciate it
19:27:56 <adamw> #endmeeting