16:00:23 <adamw> #startmeeting F38-blocker-review
16:00:23 <zodbot> Meeting started Mon Mar 27 16:00:23 2023 UTC.
16:00:23 <zodbot> This meeting is logged and archived in a public location.
16:00:23 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:23 <zodbot> The meeting name has been set to 'f38-blocker-review'
16:00:24 <adamw> #meetingname F38-blocker-review
16:00:24 <zodbot> The meeting name has been set to 'f38-blocker-review'
16:00:28 <adamw> #topic Roll Call
16:00:33 <adamw> ahoyhoy folks, who's here for blocker fun?
16:01:52 * lruzicka is here, sitting in the corner like a duck in its nest.
16:02:23 <geraldosimiao> .hello geraldosimiao
16:02:24 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
16:02:25 * coremodule is here, ready for the meeting and willing to secretarialize.
16:02:50 <adamw> sigh, bugzilla is playing up this morning
16:03:28 <geraldosimiao> Hello, I'm here :)
16:03:43 <geraldosimiao> ohh, zodbot its a bit slow today
16:04:00 <geraldosimiao> coremodule++
16:04:00 <zodbot> geraldosimiao: Karma for coremodule changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:04:01 <marcdeop[m]> .hello marcdeop
16:04:04 <zodbot> marcdeop[m]: marcdeop 'Marc Deop' <fedora@marcdeop.com>
16:04:12 <frantisekz> .hello2
16:04:13 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:06:53 <adamw> #chair marcdeop frantisekz
16:06:53 <zodbot> Current chairs: adamw frantisekz marcdeop
16:06:59 <adamw> impending boilerplate alert!
16:07:04 <adamw> #topic Introduction
16:07:16 <adamw> Why are we here?
16:07:17 <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:17 <adamw> #info We'll be following the process outlined at:
16:07:18 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:21 <adamw> #info The bugs up for review today are available at:
16:07:24 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:29 <adamw> #info The criteria for release blocking bugs can be found at:
16:07:30 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:07:35 <adamw> #link https://fedoraproject.org/wiki/Fedora_38_Beta_Release_Criteria
16:07:37 <adamw> #link https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria
16:07:47 <adamw> #info for Final, we have:
16:07:59 <adamw> #info 2 Proposed Blockers
16:08:11 <adamw> #info 7 Accepted Blockers
16:08:37 <adamw> #info 2 Proposed Freeze Exceptions
16:08:38 <adamw> #info 6 Accepted Freeze Exceptions
16:08:39 <adamw> #info coremodule will secretarialize
16:08:40 <adamw> let's get started with...
16:08:40 <adamw> #topic Proposed Beta blockers
16:08:42 <adamw> grr
16:08:43 <adamw> #undo
16:08:43 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f5be349df60>
16:09:05 <adamw> #topic Proposed Final blockers
16:09:05 <adamw> #topic (2177153) MaxCrashReportsSize claims to be 5000 MB but is 1000 MB
16:09:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2177153
16:09:06 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1104
16:09:07 <adamw> #info Proposed Blocker, abrt, NEW
16:09:09 <adamw> #info Ticket vote: FinalBlocker (+4,1,-2) (+augenauf, +bcotton, +lruzicka, +nielsenb, geraldosimiao, -catanzaro, -frantisekz)
16:10:06 <adamw> so aiui the contention here is that the incorrect max size makes enough crashes non-reportable that it constitutes a violation of the "basic functionality" of the crash reporter app?
16:10:59 <lruzicka> Some people reported one bigger crash and over. That seems to me like a problem.
16:11:14 <adamw> note we rejected this last week, but further research made the situation clearer
16:11:20 <lruzicka> You do not want to report each crash immediately and sometimes you might want to save up several for later.
16:11:34 <frantisekz> from what I understand, you can report most of the crashes just fine, but the older ones would get purged due to C/C++ doing their stuff with numbers...
16:11:41 <frantisekz> doesn't sound like a blocker to me
16:11:42 <adamw> i think i'm still honestly -1 on this, we should fix it, but i'm struggling to block the release on it
16:12:19 <lruzicka> frantisekz, kamil said that if the crash was quite big on data, it would delete it when another crash happens.
16:12:31 <adamw> well, i guess kparal makles a good point
16:12:39 <frantisekz> yeah, i know lruzicka
16:12:44 <adamw> "The 1GB space is enough to report a single crash, if you do it immediately. If there's a second crash, or multiple apps crash at once (like when a session crashes), it's likely that your first/primary crash gets removed immediately. This prevents you from doing the main task of ABRT - reporting a crash."
16:12:53 <adamw> though...is that really the case? are most crashes over 500M?
16:13:02 <lruzicka> I do not like the idea of being able to report just one crash immediately or never
16:13:03 <geraldosimiao> yeah, abrt must not be a "onetime" crash reporter
16:13:27 <geraldosimiao> I think I'm changing my 0 to FB+1
16:14:44 <lruzicka> frantisekz, I know you know.
16:14:54 <frantisekz> I'd say this deletion would happen mostly with webkit crashes, where it can go beyond 500 MB
16:15:23 <frantisekz> I am -1 on blocker if that occurs only on one component crashes
16:15:30 <frantisekz> +1 FE for sure though
16:18:50 <adamw> welp, if we count geraldo as +1 and me as -1 that doesn't change anything much...
16:18:51 <adamw> anyone else have thoughts?
16:19:40 <lruzicka> on the other hand, it is probable that we have had the same situation before
16:19:45 <lruzicka> we just did not know it
16:19:49 * marcdeop[m] is neutral
16:21:50 <adamw> lruzicka: i was kinda wondering about that too
16:21:53 <adamw> when did this change
16:23:06 <frantisekz> it seems we have a fix now: https://github.com/abrt/abrt/commit/b63220f70933dadbd4642b86f5af8269920b8c9a
16:23:49 <adamw> well, since we don't seem to have enough votes to push this off the ledge either way...
16:24:38 <adamw> proposed #agreed 2177153 - punt (delay decision) - we don't have a clear enough vote here. We'll delay the decision in the hopes of getting more votes and/or a fix
16:25:04 <frantisekz> ack
16:25:15 <geraldosimiao> ack
16:25:15 <marcdeop[m]> ack
16:26:14 <adamw> #agreed 2177153 - punt (delay decision) - we don't have a clear enough vote here. We'll delay the decision in the hopes of getting more votes and/or a fix
16:26:53 <adamw> #topic (2180277) gnome-shell crashes and sysops happens  when users logout
16:26:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2180277
16:26:54 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1123
16:26:55 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:26:57 <adamw> #info Ticket vote: FinalBlocker (+1,0,-5) (+geraldosimiao, -adamwill, -frantisekz, -bcotton, -nielsenb, -lruzicka)
16:26:59 <adamw> #info Ticket vote: FinalFreezeException (+7,0,-0) (+adamwill, +frantisekz, +bcotton, +catanzaro, +nielsenb, +lruzicka, +tablepc)
16:27:16 <adamw> oh, looks like this got a few more ticket votes since last i checked
16:27:17 <adamw> so we actually have the votes to reject it, but does anyone have any notes/new votes before we do?
16:28:22 <geraldosimiao> I still wonders if this criterions dosnt apply here
16:28:23 <geraldosimiao> https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria#SELinux_and_crash_notifications
16:28:23 <geraldosimiao> "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."
16:28:24 <geraldosimiao> I know the crash isnt on first login
16:28:43 <geraldosimiao> but after that, if one logout and login again the crash shows up
16:28:50 <adamw> sure. which isn't what the criterion says. :D
16:29:41 <geraldosimiao> ok, it apllies then only at first login
16:29:45 <geraldosimiao> ok then, lets go for FE
16:31:31 <geraldosimiao> because I assume this words "first login" is to ensure the user dont have anithing else installed
16:31:44 <adamw> well, that, and also the theory is that after first login, you can install updates which will prevent this happening later. (ok, it would still probably happen *once*.)
16:32:37 <geraldosimiao> oh, ok, thats right too.
16:32:37 <adamw> proposed #agreed 2180277 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this doesn't violate the release criteria, but it's a polish issue you can run into before updating so we agree it deserves an FE
16:32:39 <geraldosimiao> so its fixable with a after install update
16:32:52 <frantisekz> ack
16:33:18 <geraldosimiao> sure
16:33:19 <geraldosimiao> ack
16:33:55 <marcdeop[m]> ack
16:34:29 <adamw> #agreed 2180277 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this doesn't violate the release criteria, but it's a polish issue you can run into before updating so we agree it deserves an FE
16:34:58 <adamw> ok, that's all the proposed blockers
16:34:59 <adamw> let's move on to
16:35:01 <adamw> #topic Proposed Final freeze exceptions
16:35:38 <adamw> #info 2179591 was accepted as a blocker by ticket vote so we'll skip that one
16:35:44 <adamw> #topic (2179854) Qt 5 render the Bold style CJK character very thick with Noto CJK variable fonts
16:35:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2179854
16:35:50 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1130
16:36:09 <adamw> #info Proposed Freeze Exceptions, qt5-qtbase, MODIFIED
16:36:09 <adamw> +1 for me
16:37:09 <lruzicka> +1
16:37:23 <geraldosimiao> FE +1
16:39:15 <marcdeop[m]> +1
16:41:08 <adamw> proposed #agreed 2179854 - AcceptedFreezeException (Final) - this is accepted as a clear visual quality issue that will be encountered on live boots by CJK users
16:41:15 <lruzicka> ack
16:41:54 <geraldosimiao> ack
16:42:40 <marcdeop[m]> ack
16:43:06 <adamw> #agreed 2179854 - AcceptedFreezeException (Final) - this is accepted as a clear visual quality issue that will be encountered on live boots by CJK users
16:43:32 <adamw> aand that's all the proposals!
16:43:53 <adamw> let's take a quick spin through...
16:43:53 <adamw> #topic Accepted Final blockers
16:43:54 <adamw> #info we are just checking in on these, not voting again (unless we decide it's merited)
16:44:22 <adamw> #topic (2170878) Insecure installed RPMs (like Google Chrome) prevent system updates in F38, can't be removed
16:44:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2170878
16:44:23 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1039
16:44:24 <adamw> #info Accepted Blocker, crypto-policies, ASSIGNED
16:44:31 <adamw> so this got reopened for issues with one specific package/repo
16:45:41 <adamw> it's sounding like there aren't really any release-blocking changes to come out of this, per comment 129
16:46:45 <adamw> #info this is being handled, probably it will be flipped back CLOSED and a common bugs note added. see https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c129
16:47:12 <adamw> #topic (2171350) anaconda failed to detect the fcoe target(only affects ixgbe)
16:47:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2171350
16:47:17 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1041
16:47:23 <adamw> #info Accepted Blocker, kernel, NEW
16:47:37 <adamw> #info this one seems to be getting shopped around maintainers to find one who'll take responsibility for it
16:49:15 <adamw> #info i've pinged jforbes, he'll take a look when he has a minute
16:51:36 <adamw> #topic (2176782) The kernel sometimes does not initialize SimpleDRM when booting in basic graphics mode on BIOS, causing SDDM to fail
16:51:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2176782
16:51:38 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1086
16:51:40 <adamw> #info Accepted Blocker, kernel, POST
16:52:07 <adamw> this one's going to a lot of places, but so far we have my PR to add vga=791 to live image BIOS basic graphics params...
16:52:09 <adamw> and as someone pointed out, that might also need adjustments in anaconda, so i'd better look at that today
16:52:57 <frantisekz> if we were okay with vga= being passed everytime if present, the anacond aplace to change this would be https://github.com/rhinstaller/anaconda/blob/master/data/anaconda.conf#L155
16:53:25 <adamw> ah, yeah.
16:53:28 <geraldosimiao> this vga=791 at linux boot line realy worked at a hardware I have here, as pointed on the ticket
16:54:38 <adamw> #info this bug sort of exposes lots of things to think about, but for the immediate future we have a plan that should...probably work. it'd be good if more folks can test booting an F38 KDE live in basic graphics mode with vga=791 and see if it works for them
16:56:12 <adamw> #topic (2179591) Logging out of Plasma 5.27.3 on Wayland as the second user on the system resulted in a black screen
16:56:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2179591
16:56:13 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1122
16:56:15 <adamw> #info Accepted Blocker, kwin, NEW, depends on other bugs
16:56:37 <adamw> I think we're waiting on an selinux-policy build to see if that helps?
16:57:06 <frantisekz> kamil verified it does get away with avc denials
16:57:21 <frantisekz> not sure if that's enough to fix this entirely
16:57:25 <adamw> oh, it looks like we ahve the selinux-policy build
16:57:30 <adamw> but kparal is having trouble reliably reproducing the issue to be sure the selinux update fixes it
16:57:46 <frantisekz> ref. https://bodhi.fedoraproject.org/updates/FEDORA-2023-624eb88729
16:57:46 <geraldosimiao> Fedora-KDE-Live-x86_64-38-20230326.n.1.iso is working fine
16:58:08 <adamw> #info we have a possible theory of what causes this bug and a fix for it (an SELinux denial and an selinux-policy update), but the problem is not reliably reproducible so confirming the fix is a bit difficult
16:58:22 <aleasto> i'm pretty sure it has nothing to do with sepolicy
16:58:33 <geraldosimiao> he thinks its can be a race condition
16:58:43 <aleasto> not because i have looked into the sepolicy, but because i hit the same denial and don't hit the bug
16:59:00 * marcdeop[m] agrees with @aleasto
16:59:25 <adamw> that doesn't prove it
16:59:26 <adamw> the bug seems to be a race
16:59:34 <aleasto> sure
16:59:47 <adamw> which means you don't always hit the problem even if you hit the trigger
17:00:03 <adamw> so "i hit the potential trigger and didn't hit the bug" doesn't prove the potential trigger isn't the actual trigger
17:00:54 <marcdeop[m]> but that works the other way araound as well: we can't prove the denial is the trigger
17:00:57 <adamw> well, if nobody can reproduce the bug any more after the update goes stable, then either it *was*, or we fixed it some other way
17:00:59 <adamw> either is good
17:02:06 <marcdeop[m]> I personally would be interesting in getting information from loginctl session-status $sessionNumber if anybody ever manages to reproduce the bug again
17:02:07 <marcdeop[m]> I personally would be interested in getting information from loginctl session-status $sessionNumber if anybody ever manages to reproduce the bug again
17:02:16 <adamw> can you mention that on the bug?
17:02:36 <marcdeop[m]> yes, and I also have another suggestion
17:02:47 <adamw> fire away
17:03:40 * marcdeop[m] writes in the bug
17:04:09 <adamw> alrighty
17:04:10 <adamw> #info we'll continue to look into this one as it's a bit slippery
17:04:13 <adamw> #topic (2172956) Update hostkey migration to support OSTree systems and dynamically detect hostkey location
17:04:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2172956
17:04:18 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1050
17:04:21 <adamw> #info Accepted Blocker, openssh, MODIFIED
17:05:56 * kparal forgot about the meeting he added to fedocal himself, shame!
17:06:08 <adamw> #info work is ongoing to clean this up, just need to ensure the right changes are included in the update
17:07:57 <adamw> #topic (2174563) Virtual keyboard (on-screen) not working at sddm-wayland-plasma
17:08:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2174563
17:08:02 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1061
17:08:24 <adamw> #info Accepted Blocker, sddm, NEW
17:08:25 <adamw> there seems to be a bit of debate over whether this should still be a blocker...
17:09:10 <geraldosimiao> yeah
17:09:18 <geraldosimiao> ;)
17:10:13 <adamw> i am a bit confused at this point, honestly
17:10:31 <adamw> how is the button "working" if it doesn't "bring up" the keyboard?
17:10:38 <geraldosimiao> I'm not against removing this icon on sddm when we dont have the touchscreen hardware to use it
17:10:40 <adamw> how *do* you "bring up" the keyboard if you want it?
17:10:52 <aleasto> you "touch" the inputfield
17:11:07 <geraldosimiao> thats a good poitn
17:11:07 <adamw> but you don't need a touchscreen to use a virtual keyboard
17:11:08 <geraldosimiao> point
17:11:08 <adamw> you can use a mouse
17:11:40 <marcdeop[m]> the kde implementation was only intended to show up the vk on touchscreen
17:11:40 <geraldosimiao> well, kde devs seems to disagree with that
17:11:42 <adamw> onscreen keyboards are an accessibility feature, not just a touchscreen input mechanism
17:11:55 <geraldosimiao> thats wat I think too
17:12:02 <marcdeop[m]> that's something being discussed upstream into how to do that properly
17:12:09 <adamw> though i guess we have to argue over whether it's *meant* to be that, in kde...
17:12:14 <marcdeop[m]> I agree as well
17:12:29 <marcdeop[m]> however, I still don't consider this a blocker myself
17:13:02 <aleasto> as far as i understand, it is intended at the moment; but kwin people are ok to change this, although most likely not before Plasma 6
17:13:16 <adamw> what are our practical options at this point? is it not possible to make it work the way it works on X?
17:13:32 <adamw> of course, we can go back to X. again...
17:13:59 <aleasto> "requires big changes" is the last i remember
17:14:02 <aleasto> so Plasma 6 most likely
17:15:05 <geraldosimiao> so: get rid of the icon on non touchscreen hardware x revert to sddm-x11 x keep this icon there and get used to people asking what it does...
17:17:49 <frantisekz> or we can replace sddm with gdm, hehe :D
17:18:10 <adamw> #info this one is tricky, and apparently making it work on wayland the way it works on X.org (you click the virtual keyboard button, and you get a virtual keyboard) is not simple. we will continue to evaluate the options here
17:19:10 <marcdeop[m]> frantisekz: we would if it didn't bring 90% of gnome with it
17:19:36 <frantisekz> yeah, I know that's not feasible, it was just a spicy joke
17:19:39 <marcdeop[m]> I dunno if we (kde-sig) are capable of patching sddm/kwin_wayland to not show that button
17:19:40 <geraldosimiao> frantisekz: thats blasphemy 🤣
17:19:48 <marcdeop[m]> perhaps upstream could show us how to do that
17:22:29 <adamw> #topic (2113005) Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards
17:22:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2113005
17:22:35 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1087
17:22:37 <adamw> #info Accepted Blocker, shim, NEW
17:22:45 <adamw> so, this one is still stuck on the kernel patch, i think
17:23:06 <adamw> looks a lot like we'll have to waive it at this point
17:23:33 <frantisekz> are we (can we) gonna do it right away?
17:24:16 <geraldosimiao> sad
17:24:17 <geraldosimiao> this requirement was announced on 2021, effective 11/30/2022
17:24:17 <geraldosimiao> https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916
17:24:36 <geraldosimiao> devs have had plenty of time to rebuild
17:24:39 <lruzicka> do not pull off trousers when the ford is still a mile ahead
17:24:58 <adamw> geraldosimiao: it's not just a rebuild
17:25:04 <geraldosimiao> yeah, by now this must be skiped to f39
17:25:21 <adamw> NX support *doesn't exist* in the kernel
17:25:22 <adamw> it needs to be added
17:25:54 <geraldosimiao> yeah, I understand
17:25:55 <geraldosimiao> they have announced this on 2021
17:26:01 <geraldosimiao> they => microsoft
17:27:40 <geraldosimiao> ok, rebuild its not the right wordhere, so implement.
17:29:35 <adamw> it appears to be...not simple.
17:29:36 <adamw> the patch series is 26 patches long and it's on version 5.
17:29:37 <adamw> (if i'm on the right one, anyway - i believe it's https://lkml.org/lkml/2023/3/14/390 )
17:30:50 <frantisekz> I'd say if I had to guess that it won't be possible to backport such a large series downstream
17:31:18 <adamw> i think it would, since we're heavily involved in writing it. but i think we don't want to backport it until it's accepted upstream
17:31:25 <adamw> we don't want to be *maintaining* such a patchset long term
17:32:05 <frantisekz> and upstream acceptance can happen next week or next year, we can't do much about that :/
17:32:07 <adamw> anyway, yeah. that's the status.
17:32:07 <geraldosimiao> 👀
17:32:29 <adamw> #info AIUI, this is still blocked on kernel support for NX, for which https://lkml.org/lkml/2023/3/14/390 seems to be the most recent patch series proposal ATM (v5). we may well have to waive it at this point
17:34:11 <adamw> #topic Open floor
17:34:14 <adamw> so, that's the crop
17:34:17 <adamw> anything else, folks?
17:34:34 <frantisekz> what about that f39 proposed blockers? !! :D
17:34:47 <frantisekz> nothing from me, I'll need to run, thanks for the meeting!
17:35:21 <geraldosimiao> nothing from me too
17:36:40 <adamw> .fire frantisekz they're right over....*here*
17:36:40 <zodbot> adamw fires frantisekz they're right over....*here*
17:38:27 <adamw> thanks for coming, folks
17:41:45 <lruzicka> thank you for leading us
17:41:56 <lruzicka> take care and have a nice time all of you
17:42:24 <marcdeop[m]> thank you all for the amazing job you do
17:54:23 <geraldosimiao> 👋
17:54:52 <adamw> aw
17:54:53 <adamw> and on that note!
17:54:53 <adamw> #endmeeting