16:00:16 <adamw> #startmeeting F38-blocker-review
16:00:16 <zodbot> Meeting started Mon Mar 20 16:00:16 2023 UTC.
16:00:16 <zodbot> This meeting is logged and archived in a public location.
16:00:16 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:16 <zodbot> The meeting name has been set to 'f38-blocker-review'
16:00:20 <adamw> #meetingname F38-blocker-review
16:00:20 <zodbot> The meeting name has been set to 'f38-blocker-review'
16:00:26 <adamw> #topic Roll Call
16:00:31 <LunaJernberg[m]> .hello bittin
16:00:31 <adamw> ahoyhoy folks, who's around for blocker review fun?
16:00:38 <zodbot> LunaJernberg[m]: bittin 'Luna Jernberg' <droidbittin@gmail.com>
16:00:43 * kparal definitely not
16:01:03 <adamw> *note: the FDA has not approved these statements. in rare cases, blocker review may result in a sudden decline in fun. in these cases, stop attending the blocker review meeting and consult your physician immediately
16:01:39 * marcdeop[m] is partly around
16:01:41 <marcdeop[m]> adamw: physician or psicologist? :P
16:01:42 <geraldosimiao> .hello geraldosimiao
16:01:43 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
16:01:58 <LunaJernberg[m]> has not had time to vote, can i vote during the meeting?
16:01:58 <adamw> whichever works best :P
16:02:05 <adamw> Luna Jernberg: yes, that's what it's for!
16:02:11 <LunaJernberg[m]> ah great
16:02:53 <geraldosimiao> great blocker voting fun for everyone ;)
16:03:22 <adamw> #chair kparal marcdeop
16:03:22 <zodbot> Current chairs: adamw kparal marcdeop
16:03:31 <adamw> coremodule: around?
16:03:58 <geraldosimiao> and a healthy debate on the criteria :D
16:04:50 <lruzicka> .hello2
16:04:51 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:06:14 <adamw> alrighty, let's get going
16:06:16 <adamw> boilerplate alert
16:06:24 <zodbot> adamw: Error: Can't start another meeting, one is in progress.
16:06:26 <adamw> #meetingname F38-blocker-review
16:06:26 <zodbot> The meeting name has been set to 'f38-blocker-review'
16:06:28 <adamw> grrr
16:06:30 <adamw> wrong bit
16:06:35 <adamw> #topic Introduction
16:06:37 <adamw> Why are we here?
16:06:45 <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:06:48 <adamw> #info We'll be following the process outlined at:
16:06:51 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:53 <adamw> #info The bugs up for review today are available at:
16:06:55 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:58 <adamw> #info The criteria for release blocking bugs can be found at:
16:07:00 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:07:04 <adamw> #link https://fedoraproject.org/wiki/Fedora_38_Beta_Release_Criteria
16:07:07 <adamw> #link https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria
16:07:11 <adamw> #info for Final, we have:
16:07:12 <adamw> #info 8 Proposed Blockers
16:07:16 <adamw> #info 7 Accepted Blockers
16:07:18 <adamw> #info 3 Proposed Freeze Exceptions
16:07:21 <adamw> #info 8 Accepted Freeze Exceptions
16:07:33 <adamw> #info adamw will secretarialize if coremodule doesn't make it
16:08:47 <adamw> let's start with...
16:08:51 <adamw> #topic Proposed Final blockers
16:09:16 <adamw> #topic (2179535) FFmpeg version 6 seems not to be supported
16:09:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2179535
16:09:28 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1117
16:09:28 <adamw> #info Proposed Blocker, firefox, POST
16:10:21 <adamw> iirc, we have specific functionality requirements for web browsers, and they don't say anything about playing multimedia.
16:10:37 <LunaJernberg[m]> from RPM Fusion is +1 if Fedora 38 is gonna ship with ffmpeg6 if not +-0
16:11:01 <adamw> we do say "The installed system must be able to record audio using the default web browser (if applicable)" but not sure if that affects us.
16:11:10 <Eighth_Doctor> it does
16:11:12 <adamw> i mean, if this affects that
16:11:22 <Eighth_Doctor> it breaks WebRTC and regular playback stuff
16:11:34 <kparal> I'd say the basic functionality criterion can be applied here, even though it's a question if video is basic nowadays
16:11:36 <adamw> sure it does
16:11:44 <kparal> does youtube work or not?
16:11:44 <adamw> is that blocking? that's the question
16:11:56 <LunaJernberg[m]> well i would say WebRTC is important enough so +1
16:12:03 <geraldosimiao> ohh, so it breaks desktop sharing too?
16:13:07 <Eighth_Doctor> well, it breaks anything that goes through ffmpeg
16:13:07 <adamw> i seem to have ffmpeg 6.0 and youtube works
16:13:08 <kparal> youtube works for me
16:13:08 <Eighth_Doctor> so anything but the free codecs
16:13:08 <kparal> and I have ffmpeg 6
16:13:09 <Eighth_Doctor> if a YT video isn't free encoded, then it'll fail
16:13:09 <kparal> ah
16:13:10 <Eighth_Doctor> it's hard to find a reliable test case for that, since YT is progressively re-encoding the whole thing :)
16:13:11 <kparal> I can play h264 video directly in firefox
16:13:15 <kparal> just tested
16:13:20 <kparal> but I have rpmfusion codecs installed
16:13:29 <Eighth_Doctor> that one probably goes through openh264, no?
16:13:36 <Eighth_Doctor> unless you're doing VA-API acceleration
16:13:46 <kparal> ah, right, vaapi
16:13:50 <kparal> I have that enabled
16:13:53 <Eighth_Doctor> VA-API H264 goes through ffmpeg, regular H264 goes through openh264
16:14:36 <Eighth_Doctor> I'm not sure how to check whether a video is going through one path or another, but I don't have VA-API acceleration so it definitely goes through openh264 for that if it's installed
16:14:39 <Eighth_Doctor> if not, then it fails
16:15:06 <adamw> it'd presumably fall back to openh264 if vaapi failed...
16:15:21 <Eighth_Doctor> I actually don't know if it would do that
16:15:25 <LunaJernberg[m]> right click and stats for nerds, but maybe thats just what the video is encoded in?
16:15:42 <geraldosimiao> I see Neal already have a patch for this
16:15:50 <Eighth_Doctor> in any case, there's a PR with a tentative fix, which I rebased against firefox 111
16:17:03 <LunaJernberg[m]> then just hope it works and also Firefox 112 is released some weeks before the F38 release
16:17:16 <kparal> so, if the free media play inside FF, and openh264 works for videoconferences, I'm not sure if we can even block on this
16:17:58 <geraldosimiao> well, I think this is blocker material, if webRTC depends on it
16:18:29 <adamw> yeah, on the whole, video is working for me
16:18:41 <Eighth_Doctor> the main thing this screws up is that if someone wants to install libavcodec-freeworld from rpmfusion to get accelerated video working, that's toast
16:19:13 <Eighth_Doctor> it also makes the ffmpeg demuxers and audio codecs unavailable for firefox too
16:19:18 <marcdeop[m]> -1 blocker from me and i know how many complaines from this will arise from anvry users
16:19:34 <Eighth_Doctor> I'm fine with at least making it an FE
16:20:01 <Eighth_Doctor> but I'd rather not have GA ship with broken VA-API capabilities entirely
16:20:06 <Eighth_Doctor> even for Free codecs
16:20:11 <adamw> -1 blocker, i'm okay with an FE if we wanna do that
16:20:35 <kparal> Finalblocker 0 at this moment, +1 FE
16:21:12 <Eighth_Doctor> +1 FinalBlocker +1 FE
16:21:30 <bcotton> 0 FinalBlocker +1 FE
16:21:34 <Eighth_Doctor> (basically, whichever way we do it, I want to make this fixable for GA)
16:21:39 <geraldosimiao> +1 FB +1FE
16:21:58 <adamw> what is the criterion for blocking
16:21:58 <kparal> hmm, so, vaapi works just fine for me in FF
16:21:59 <adamw> basic functionality?
16:22:22 <adamw> i am having trouble buying "something that's only useful if you enable rpmfusion and install stuff from it" as "basic functionality"
16:22:27 <Eighth_Doctor> I guess do we consider hardware accelerated video (even with free codecs shipped in Fedora) blocking?
16:22:37 <kparal> doh, vaapi+vp9. I have to find h264 for it
16:22:41 <Eighth_Doctor> because this also affects hw acceleration for vp8 and vp9
16:22:46 <Eighth_Doctor> and av1
16:22:56 <Eighth_Doctor> (though av1 doesn't have vaapi support in ffmpeg yet)
16:23:07 <kparal> well, if it's supposed to affect vp9 vaapi, it doesn't for me
16:23:19 <kparal> I justed tested 4k60 video directly in my firefox, it's accelerated
16:23:28 <Eighth_Doctor> huh okay
16:24:29 <Eighth_Doctor> I can't test it as I don't have anything with vp9 accel support :(
16:25:28 <geraldosimiao> one can test here
16:25:33 <geraldosimiao> https://tools.woolyss.com/html5-audio-video-tester/
16:25:33 <kparal> we can ask the proposers to come up with a concrete list of tested use cases which are broken
16:26:14 <Eighth_Doctor> I think it'd be a good idea to get some concrete test cases to add to our test matrix anyway
16:26:34 <Eighth_Doctor> this is a capability people expect for laptops because of energy consumption concerns
16:27:58 <adamw> proposed #agreed 2179535 - punt (delay decision) - we will punt on this to see if affected folks can come up with a more precise explanation of exactly what this breaks so we can evaluate if it really constitutes 'basic functionality'
16:28:30 <geraldosimiao> ack
16:28:31 <lruzicka> ack
16:28:48 <marcdeop[m]> Ack
16:28:58 <Eighth_Doctor> ack
16:29:02 <kparal> ack
16:30:36 <adamw> #agreed 2179535 - punt (delay decision) - we will punt on this to see if affected folks can come up with a more precise explanation of exactly what this breaks so we can evaluate if it really constitutes 'basic functionality'
16:30:43 <adamw> #topic (2177153) crash data are erased occasionally
16:30:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2177153
16:30:48 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1104
16:30:51 <adamw> #info Proposed Blocker, gnome-abrt, NEW
16:30:53 <adamw> #info Ticket vote: FinalBlocker (+0,1,-5) (geraldosimiao, -catanzaro, -lruzicka, -frantisekz, -kparal, -bcotton)
16:31:11 <adamw> so i'm kinda reluctant to take this on current votes as it still doesn't seem really clear in the bug report what is going on here
16:31:22 <adamw> whether we have a more serious problem than intended cleanup
16:32:01 <LunaJernberg[m]> looks on the video, like the GNOME crash bug that was some weeks ago thats now fixed
16:32:18 <LunaJernberg[m]> lemme find the BZ
16:32:24 <kparal> as I see it, there might be some problem when the whole session crashes, but overall it seems to work OK, and I don't think it violates basic functionality at the moment
16:33:05 <adamw> Luna Jernberg: the crash is intentional
16:33:12 <adamw> the bug is about handling of crash *reports*
16:33:29 <LunaJernberg[m]> ah (is too tired to think correctly today)
16:33:52 * lruzicka agrees with kparal
16:33:55 <adamw> we can reject it for now and reconsider later, if we like, i guess
16:34:18 <kparal> I don't have a strong opinion
16:35:20 <geraldosimiao> for now I'm more FB -1
16:35:57 <Eighth_Doctor> -1 FB
16:36:13 <geraldosimiao> it looks more like a commobugs thing
16:36:30 <adamw> proposed #agreed 2177153 - RejectedBlocker (Final) - this is currently rejected as we don't have strong enough evidence there's a reproducible widespread issue here. we can reconsider the vote if more information emerges
16:36:38 <bcotton> i'm not even sure it's "common" at this point. my -1 is without prejudice
16:36:40 <bcotton> ack
16:36:51 <lruzicka> ack
16:36:54 <geraldosimiao> ack
16:37:16 <LunaJernberg[m]> maybe not something to block on but yeah common bugs and try to talk to the abrt people
16:37:45 <adamw> #agreed 2177153 - RejectedBlocker (Final) - this is currently rejected as we don't have strong enough evidence there's a reproducible widespread issue here. we can reconsider the vote if more information emerges
16:37:59 <adamw> #topic (2177993) Crash/Hang when clicking a modified Google event right after editing it (due to the preview popover)
16:38:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2177993
16:38:09 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1097
16:38:12 <adamw> #info Proposed Blocker, gnome-calendar, NEW
16:38:14 <adamw> #info Ticket vote: FinalBlocker (+2,1,-4) (+lruzicka, +geraldosimiao, bcotton, -aday, -frantisekz, -adamwill, -kparal)
16:38:17 <adamw> #info Ticket vote: FinalFreezeException (+1,0,-0) (+bcotton)
16:39:08 <LunaJernberg[m]> -1 but try to talk to the gnome-calendar / GNOME people
16:39:13 <Eighth_Doctor> -1 FB +1 FE
16:40:00 <adamw> anyone wanna make the case for this being a blocker?
16:40:05 <adamw> with those votes we're at -4 combined
16:40:11 <adamw> (+2 / -6)
16:40:27 <lruzicka> I do not insist
16:40:40 <geraldosimiao> well, it seems a corner case indeed, but the crash is nasty
16:40:52 <lruzicka> geraldosimiao, oth, no harm done to the data
16:40:55 <geraldosimiao> but I can go wiht a FE on this
16:41:05 <geraldosimiao> FE +1
16:41:10 <geraldosimiao> FB 0
16:41:58 <adamw> proposed #agreed 2177993 - RejectedBlocker (Final) - this is rejected as not meeting the "basic functionality" test
16:42:02 <geraldosimiao> ack
16:42:02 <adamw> mmmf
16:42:06 <adamw> proposed #agreed 2177993 - RejectedBlocker (Final) - this is rejected as not meeting the "basic functionality" definition
16:42:13 <lruzicka> ack
16:42:22 <LunaJernberg[m]> ack
16:43:35 <adamw> #agreed 2177993 - RejectedBlocker (Final) - this is rejected as not meeting the "basic functionality" definition
16:43:36 <marcdeop[m]> Ack
16:43:37 <geraldosimiao> and as being a FE? we have 3 votes, me, bcotton and Conan Kudo
16:43:57 <adamw> oh, we can do that...i guess...it's a couple of weeks till freeze...
16:44:21 <adamw> what's the case for FE? people who desperately need to modify google calendar events on live images?
16:44:43 <adamw> fe isn't just a consolation prize for things that aren't quite blockers, it has to make sense for there to be a freeze exception
16:44:56 <geraldosimiao> yeah, you know how some people are with their events... ;)
16:45:18 <kparal> I'd only consider FE if there's a patch or devs says they want to work on it. Otherwise it's a wasted time
16:45:41 <kparal> And I don't think we need to care just about the Live image. The default experience, before updates, it also important
16:47:11 <geraldosimiao> yes
16:47:18 <adamw> maybe we table FE until there's some plan of a fix.
16:48:22 <kparal> also, not in a freeze right now
16:48:45 <kparal> let's move on
16:48:58 <geraldosimiao> ok
16:48:59 <geraldosimiao> agreed
16:49:13 <adamw> #topic (2180047) Automatic suspend also suspends virtual machines, can't be resumed
16:49:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2180047
16:49:20 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1120
16:49:22 <adamw> #info Proposed Blocker, gnome-settings-daemon, NEW
16:50:14 <adamw> well, suspending the VMs makes sense, but not resuming them seems bad. :P
16:50:14 <Eighth_Doctor> erk
16:50:15 <kparal> if suspending makes sense, then it's probably a libvirt bug
16:50:15 <kparal> I wasn't so sure about that
16:50:27 <Eighth_Doctor> if you're doing S0 suspend, then yes, it makes sense
16:50:30 <Eighth_Doctor> because otherwise the VM could trigger the machine to wake up
16:51:14 <lruzicka> the VM can be also manually suspended without the chance to recover
16:51:17 <kparal> "the VM could trigger the machine to wake up" - I don't follow, this is about VM suspend, not host suspend
16:51:42 <kparal> lruzicka: yes, that never worked, in my memory
16:52:03 <Eighth_Doctor> oh I misread this as host suspending triggered VM suspend
16:52:38 <lruzicka> kparal, then shouldn't we make it a part of this, too? it seems we are hitting this because of autosuspend
16:52:45 <lruzicka> should be fixed imo
16:52:52 <adamw> oh, wait, iswym
16:53:13 <adamw> i was misreading this as 'when you have VMs running and the host system is auto-suspended, the VMs also suspend'
16:53:15 <adamw> not just 'the auto-suspend setting applies to VMs'
16:53:16 <kparal> nope
16:53:32 <kparal> I should phrase it better, then
16:53:45 <lruzicka> adamw, no ... with host suspended this works fine, the VMs come back in the same state of art
16:54:29 <adamw> yeah, i get it now
16:54:53 <adamw> on the whole...i think i'm probably +1 on this, as a conditional violation of "The release must be able host virtual guest instances of the same release"
16:54:54 <Eighth_Doctor> running a VM in the live environment is probably suicide for a whole host of reasons, and it could be fixed with an update, right?
16:55:31 <Eighth_Doctor> but broken guest operation does suck and we don't respin media for most arches
16:55:33 <adamw> Conan Kudo: what's running on the host is irrelevant here
16:55:44 <adamw> it's what's running on the guest that matters
16:55:47 <adamw> well
16:55:51 <Eighth_Doctor> yeah... so +1 FB
16:55:54 <adamw> i guess the fix might wind up on the host end...
16:55:55 <kparal> I updated the bug titles
16:56:00 <adamw> but it could be on the guest end. can't say rn
16:56:13 <adamw> but yeah, at least for now I'm +1, we can adjust later if appropriate
16:56:25 <bcotton> yeah +1 blocker
16:56:35 <Eighth_Doctor> this also screws with non-x86 desktop VMs too
16:56:41 <geraldosimiao> ok, +1 FB too
16:56:45 <Eighth_Doctor> and those don't get respins
16:56:53 <Eighth_Doctor> so there's not a chance it gets fixed
16:57:08 <Eighth_Doctor> (in a meaningful way for first experience)
16:57:37 <LunaJernberg[m]> +1 FB
16:58:13 <adamw> proposed #agreed 2180047 - AcceptedBlocker (Final) - this is accepted as a conditional violation of the Beta criterion "The release must be able host virtual guest instances of the same release", on the basis that a guest VM that autosuspends after 20 minutes of inactivity and cannot be recovered is sufficiently non-functional to violate that requirement
16:58:24 <lruzicka> ack
16:58:38 <LunaJernberg[m]> ack
16:58:47 <geraldosimiao> ack
16:58:49 <marcdeop[m]> Ack
16:58:50 <kparal> ack
16:59:03 <adamw> #agreed 2180047 - AcceptedBlocker (Final) - this is accepted as a conditional violation of the Beta criterion "The release must be able host virtual guest instances of the same release", on the basis that a guest VM that autosuspends after 20 minutes of inactivity and cannot be recovered is sufficiently non-functional to violate that requirement
16:59:20 <adamw> #topic (2179889) Cascade menus open outside of the visible screen when close to that position.
16:59:22 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2179889
16:59:25 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1118
16:59:28 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:59:31 <adamw> #info Ticket vote: FinalBlocker (+0,0,-2) (-lruzicka, -kparal)
16:59:36 <adamw> #info Ticket vote: FinalFreezeException (+1,0,-0) (+lruzicka)
17:00:03 <adamw> note, this is proposed under the proposed WM criterion that is still under discussion
17:00:28 <adamw> see https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/UDMAC7IGJGHG4TBN32BPBCJCZOLWTDQG/
17:00:39 <lruzicka> and hard to reproduce ... I have tried on multiple devices and it behaves differently on each of them
17:00:56 <Eighth_Doctor> I don't think I've ever seen this before...
17:01:38 <adamw> can't reproduce this here either
17:01:59 <adamw> trying on my rightmost monitor, it's not spilling off the right edge, it's positioning the menu such that there's space, or opening to the left if there isn't
17:02:33 <adamw> it seems to me like there's code there to try and avoid this happening...but lruzicka has somehow triggered a corner case where it doesn't work
17:02:37 <lruzicka> adamw, this behaviour I can see on my desktop with nvidia nouveau, one display
17:02:43 <adamw> but unless we have more success reproducing this i'd be -1...
17:02:56 <Eighth_Doctor> oh maybe we need nvidia cards for it then
17:02:58 <adamw> lruzicka: i'd guess details of the resolution and so on would matter more than the driver
17:03:01 <Eighth_Doctor> because I've got AMD and Intel
17:03:09 <adamw> this kind of thing should be abstracted way above the driver level
17:03:11 <geraldosimiao> yeah, here at the vms too, it opens to the left if I try to positioning to the right, so cna't reporduce
17:03:20 <lruzicka> no, on nvidia it works ok, my laptop is affected P1 Lenovo, Intel graphics
17:03:29 <lruzicka> VMs are fine, too
17:03:32 <LunaJernberg[m]> is the menu clickable?
17:03:34 <LunaJernberg[m]> still
17:03:39 <geraldosimiao> s/cna/can/, s/reporduce/reproduce/
17:03:42 <LunaJernberg[m]> ?
17:03:56 <lruzicka> LunaJernberg[m], let me check
17:04:12 <LunaJernberg[m]> if its just cosmetics i am -1
17:04:43 <adamw> it's not just cosmetic, if it actually affects you, you can't use the submenu
17:04:43 <lruzicka> no, it is not clickable
17:04:43 <adamw> but it doesn't seem to be...common
17:04:57 <LunaJernberg[m]> ah then its more critical
17:05:05 <adamw> Luna Jernberg: the "move to start", "move to new window" options just aren't visible or reachable
17:05:10 <lruzicka> I can workaround this by shuffling the tabs, of course
17:05:26 <LunaJernberg[m]> thats no good
17:05:31 <adamw> i'm -1 so long as nobody else seems to be able to reproduce it, i think
17:05:41 <adamw> i've tried several times now and no dice
17:05:59 <adamw> lruzicka: is it a hidpi screen?
17:06:23 <lruzicka> adamw, I am not sure what counts as hidpi?
17:06:59 <lruzicka> the external monitor is 3840*2160 on 60Hz with 100% scaling
17:07:26 <lruzicka> the laptop is 2560*1600 on 60.03 Hz, 100% scaling
17:07:32 <LunaJernberg[m]> maybe report a bug to upstream Firefox: https://bugzilla.mozilla.org/describecomponents.cgi?product=Firefox if its something that affects other people (never had that happen myself) strange strange
17:07:36 <lruzicka> based on what gnome gives me
17:08:41 <adamw> i was asking whether scaling was being used, i guess.
17:08:57 <lruzicka> adamw, no, I am not using it
17:08:58 <adamw> Luna Jernberg: it's not a firefox bug, probably. it doesn't happen in kde.
17:09:12 <adamw> anyhow...where are we with votes
17:09:13 <LunaJernberg[m]> adamw: hm ok
17:10:00 <lruzicka> I will respect what comes out of you :D
17:10:02 <Eighth_Doctor> -1 FB
17:10:28 <Eighth_Doctor> I can't even justify an FE since I can't repro it at all
17:10:30 <bcotton> -1
17:10:45 <copperi[m]> -1
17:10:50 <geraldosimiao> -1 FB
17:10:57 <LunaJernberg[m]> -1
17:12:32 <adamw> proposed #agreed 2179889 - RejectedBlocker (Final) - this is rejected as it does not seem to be easily reproducible at all, many folks have now tried and not managed. assuming it's an odd corner case of the handling for this scenario not working properly, that's not serious enough to violate any criteria
17:12:47 <LunaJernberg[m]> ack
17:12:53 <kparal> ack
17:12:58 <copperi[m]> ack
17:13:51 <adamw> #agreed 2179889 - RejectedBlocker (Final) - this is rejected as it does not seem to be easily reproducible at all, many folks have now tried and not managed. assuming it's an odd corner case of the handling for this scenario not working properly, that's not serious enough to violate any criteria
17:13:54 <geraldosimiao> ack
17:13:57 <adamw> #topic (2178167) Fullscreen mode is broken for many games
17:14:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2178167
17:14:02 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1102
17:14:06 <adamw> #info Proposed Blocker, mutter, POST
17:14:07 <adamw> #info Ticket vote: FinalBlocker (+4,0,-0) (+lruzicka, +geraldosimiao, +bcotton, +frantisekz)
17:14:17 <adamw> so, this has +4 but i left it on the list because i'm being awkward about criteria
17:14:30 <LunaJernberg[m]> seems Jonas has partly fixed this if you look at the upstream bug
17:14:36 <adamw> but if we are all on board in principle with kparal's proposed criterion, we can probably accept this on that basis
17:15:03 <adamw> that proposal again: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/UDMAC7IGJGHG4TBN32BPBCJCZOLWTDQG/
17:15:13 <lruzicka> let's take Kamil's criterion for this
17:16:17 <adamw> so far nobody has opposed the idea, though we may tweakthe wording and the beta/final split, but we're discussing final now, so
17:16:23 <geraldosimiao> I goo with kparal criterion too
17:16:42 <bcotton> my question is: does it not fit existing criteria on purpose, or was it an oversight? because it seems like the sort of thing we'd intend to catch but missed
17:17:09 <geraldosimiao> with bcottons observation: " as long we dont block on Joe's Fancy Pew Pew Pew Game having a glitchy\ndisplay..."
17:17:14 <bcotton> and if that's the case, i'm comfortable taking it under an in-progress criterion proposal. if we intentionally left it out before, maybe we wait
17:18:02 <LunaJernberg[m]> Minecraft was super laggy and not working for me in GNOME 44 RC1 had to revert to XFCE 4.18 stable to play Minecraft, but it worked again with RC2 of mutter :D
17:18:57 <adamw> Ben Cotton (he/him): more or less an oversight, i'd say.
17:21:50 <Eighth_Doctor> I think we should go with it as an FB under this criterion
17:23:17 <adamw> proposed #agreed 2178167 - AcceptedBlocker (Final) - this is accepted under the proposed criterion from kparal (see above for link). there is still some discussion about tweaking the wording and what is blocked at beta vs. what's blocked at final, but there is strong consensus the criterion should cover this functionality at Final
17:23:33 <kparal> ack
17:23:33 <bcotton> ack
17:23:35 <geraldosimiao> ack
17:23:40 <copperi[m]> ack
17:23:43 <lruzicka> ack
17:24:07 <LunaJernberg[m]> ack
17:24:10 <adamw> #agreed 2178167 - AcceptedBlocker (Final) - this is accepted under the proposed criterion from kparal (see above for link). there is still some discussion about tweaking the wording and what is blocked at beta vs. what's blocked at final, but there is strong consensus the criterion should cover this functionality at Final
17:24:14 <Eighth_Doctor> ack
17:24:17 <marcdeop[m]> ack
17:24:17 <adamw> #topic (2179998) sddm-wayland-plasma freezes for a while at boot time
17:24:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2179998
17:24:25 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1119
17:24:26 <adamw> #info Proposed Blocker, sddm, NEW
17:24:27 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+geraldosimiao)
17:24:46 <kparal> it would be nice if more people reproduced this first
17:25:09 <aleasto> it is 100% reproducible, just with very different "freezing" times apparently
17:25:26 <kparal> I mean the freeze
17:25:26 <marcdeop[m]> I cannot really reproduce, the "freeze" for me is about 1sec
17:25:26 <kparal> the missing buttons are also problematic
17:25:29 <Eighth_Doctor> it's not observable for me (the freezing)
17:25:40 <geraldosimiao> yes, and I suggest using basic VM settings such as 2G ram and only 2cpus
17:26:48 <kparal> 2GB RAM is too low for a desktop, I feel
17:26:48 <adamw> these feel like two different bugs, for a start
17:26:51 <geraldosimiao> the missing buttons is tottaly a break in user experience because with sddm-x11 it doesnt behave like this
17:26:53 <lruzicka> I am seeing it now in a VM with 4GB Ram -> the freeze is like a 5 sec freeue
17:26:55 <lruzicka> freeze
17:26:56 <adamw> didn't we have the problem with the buttons last time we tried sddm on wayland?
17:27:01 <aleasto> adamw: yes, different bugs
17:27:07 <adamw> can we please split them, then?
17:27:14 <adamw> it's very confusing to discuss two different bugs in one report
17:27:17 <marcdeop[m]> yes, please, split :-)
17:27:28 <Eighth_Doctor> yes please
17:27:28 <adamw> the topic of this one is about the freeze, so i'm going with that
17:27:47 <geraldosimiao> ok, I'll split in a second bug about the buttons
17:27:57 <geraldosimiao> so now , only the freeze
17:28:40 <geraldosimiao> at my VMs and hardware, it freezes between 15s to 30s
17:29:02 <geraldosimiao> i7 3th gen hardware
17:29:12 <geraldosimiao> 16GB ram
17:29:51 <adamw> do we have any idea what it's doing while it's 'frozen'?
17:29:54 <adamw> frozen usually means it's waiting for something
17:30:13 <marcdeop[m]> my gut feeling says it's loading custom configs
17:30:44 <marcdeop[m]> like: /usr/lib/sddm/sddm.conf.d/kde_settings.conf
17:31:14 <aleasto> geraldosimiao: even with 2gb of ram and 2cpus i don't get more than 1 second
17:32:00 <Eighth_Doctor> I don't see the freeze at all on three separate laptops and two VMs
17:32:37 <adamw> i kinda feel like this might need a punt to get to the bottom of what's causing it and how widespread that's likely to be
17:32:58 <marcdeop[m]> I had another gut feeling: the virtual keyboard being loaded
17:34:46 <geraldosimiao> yeah, I feel this is related to the virtual keyboard bug
17:34:58 <geraldosimiao> and related to having or not a touch screen
17:35:06 <marcdeop[m]> is it really an issue if things take 1-2 seconds to "load"?  because as this only happens on boot/start of sddm, not sure the "freeze" word is the right one
17:35:07 <geraldosimiao> dont know for sure
17:35:50 <geraldosimiao> already opened the new ticket for the buttons
17:35:58 <adamw> 1-2 seconds i'm fine with
17:35:59 <adamw> 15-30 seconds would be bad
17:36:08 <adamw> feels like the cutoff is somewhere in the middle there :P
17:36:16 <geraldosimiao> if is jus 2 secs its fine, mine is 15-30
17:36:29 <marcdeop[m]> I agree with 15-30 being bad. I just can't reproduce :(
17:36:29 <lruzicka> mine is 5 seconds
17:38:50 <adamw> so...anyone wanna vote either way? or shall we punt?
17:38:55 <marcdeop[m]> -1 blocker
17:39:08 <Eighth_Doctor> -1 blocker
17:39:17 <kparal> I'd say wait until we can test it more
17:39:36 <lruzicka> +1 punt
17:39:48 <geraldosimiao> Punt
17:39:54 <copperi[m]> punt
17:40:02 <marcdeop[m]> we've been fixing quite a few things with upstream related to sddm and kwin_wayland. Perhaps they find what's causing this slowdown somehowquickly
17:40:54 <geraldosimiao> I opened the new one, didn't propose yet
17:41:06 <geraldosimiao> About the button
17:43:22 <marcdeop[m]> should we discuss that one? can you share a link geraldosimiao ?
17:44:17 <adamw> proposed #agreed 2179998 - punt (delay decision) - we agreed to delay the decision on this one to see if we can get a better idea of exactly what causes the delay, and hence how widespread this is likely to be. current testing seems to indicate the pause doesn't affect everyone, and can be quite short
17:45:07 <geraldosimiao> Ack
17:45:09 <geraldosimiao> Yes
17:45:12 <lruzicka> ack
17:45:14 <geraldosimiao> https://bugzilla.redhat.com/show_bug.cgi?id=2180100
17:45:31 <copperi[m]> ack
17:46:57 <marcdeop[m]> ack
17:46:58 <adamw> #agreed 2179998 - punt (delay decision) - we agreed to delay the decision on this one to see if we can get a better idea of exactly what causes the delay, and hence how widespread this is likely to be. current testing seems to indicate the pause doesn't affect everyone, and can be quite short
17:47:22 <geraldosimiao> adamw just proposed now
17:47:54 <adamw> carrying on with the existing list for now.
17:47:54 <adamw> #topic (2178971) xdg-desktop-portal-kde is launching and crashing when SDDM launches the Wayland greeter
17:48:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2178971
17:48:06 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1113
17:48:09 <adamw> #info Proposed Blocker, xdg-desktop-portal-kde, MODIFIED
17:48:12 <adamw> #info Ticket vote: FinalBlocker (+0,0,-1) (-frantisekz)
17:48:28 <marcdeop[m]> that's supposed to be fixed :-)
17:48:54 <geraldosimiao> Yes
17:49:03 <geraldosimiao> No more coredump
17:50:11 <adamw> it's not closed until the fix is stable.
17:50:26 <adamw> it's possible it doesn't make it stable before freeze, in which case we still need blocker status.
17:51:08 <adamw> and as the update is just a new git snapshot, it could theoretically have some *other* bug which could prevent us pushing it stable...you know, all that fun stuff.
17:51:41 <Eighth_Doctor> well, it's a snapshot + patch
17:51:46 <adamw> if the only consequence of this is journal log messages, -1 blocker
17:51:58 <adamw> "system services" means something specific: stuff you can see with `systemctl --failed`.
17:52:29 <Eighth_Doctor> it also apparently supposedly will fix fast user switching again :P
17:52:41 <Eighth_Doctor> but I'm a little scared to re-enable it
17:52:45 <geraldosimiao> 👀
17:52:59 * marcdeop[m] is confident about the user-switching now :-)
17:53:08 <geraldosimiao> That would be great, re-enable
17:53:15 <Eighth_Doctor> not planning to do it this cycle
17:53:27 <Eighth_Doctor> there's enough spinning plates
17:53:37 <adamw> yeah, with you there.
17:53:38 <adamw> do it for 39.
17:53:41 <marcdeop[m]> yeah, right. Let's focus on the other things we found
17:54:03 <geraldosimiao> 👍
17:55:04 <geraldosimiao> So, keep that as blocke?
17:55:43 <geraldosimiao> Or not?
17:55:43 <Eighth_Doctor> it's staying blocked for now
17:55:44 <marcdeop[m]> +1 block ( and I hate saying this)
17:55:49 <Eighth_Doctor> we'll test after f38 is out
17:56:08 <adamw> wait, what?
17:56:12 <adamw> i am confused at the turn this has taken
17:56:22 <adamw> what do you mean "keep this as blocker"?
17:56:30 <marcdeop[m]> agreed. my +1 blocker is for the bug geraldo showed about the buttons
17:56:38 <Eighth_Doctor> I thought we're talking about FUS
17:56:38 <adamw> we're not alking about the buttons
17:56:41 <adamw> or FUS
17:56:46 <Eighth_Doctor> +1 blocker for the buttons
17:56:47 <adamw> there is a topic for a reason
17:56:56 <adamw> we're not talking about the buttons! good lord
17:56:56 <marcdeop[m]> you are right adamw . Apologies
17:56:57 <adamw> we're on https://bugzilla.redhat.com/show_bug.cgi?id=2178971
17:56:59 <adamw> we have been all along
17:57:03 <Eighth_Doctor> oh this
17:57:07 <geraldosimiao> 😬
17:57:12 <Eighth_Doctor> honestly, I don't care that much
17:57:17 <marcdeop[m]> xdg-desktop-portal-kde <--- +1 blocker until it hits stable
17:57:22 <adamw> it wasn't a blocker for f37
17:57:29 <adamw> i don't see any reason for it to be one for f38
17:57:38 <Eighth_Doctor> well, f37 was sddm x11
17:57:41 <Eighth_Doctor> so this didn't happen there
17:57:44 <adamw> -1 blocker. i guess +1 fe in theory ,though i don't want to take a new git snapshot during freeze.
17:58:08 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=2178971#c5
17:58:30 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=2129479
17:58:36 <adamw> you're the one who proposed it as an FE
17:58:37 <Eighth_Doctor> this is being triggered because QtWayland is triggering portal services unconditionally
17:58:39 <Eighth_Doctor> the update tells Qt to not do that for the greeter
17:58:40 <Eighth_Doctor> and the portal services crash because Plasma isn't up yet
17:59:06 <Eighth_Doctor> yes FE, not FB
17:59:12 <adamw> the *very similar bug* for f37 was not a blocker. =)
17:59:20 <Eighth_Doctor> lol
17:59:27 <Eighth_Doctor> oh right, before we reverted in f37
17:59:35 <Eighth_Doctor> both are fixed, do what whatever
17:59:58 <adamw> so i'm the only one who actually voted so far
17:59:58 <adamw> things move faster when people vote
18:00:01 <Eighth_Doctor> +1 FE
18:00:06 <geraldosimiao> ok
18:00:09 <adamw> we're voting on blocker atm
18:00:10 <geraldosimiao> +1 FE
18:00:24 <geraldosimiao> -1 FB
18:00:28 <Eighth_Doctor> -1 FB
18:01:06 <lruzicka> -1 FB
18:02:08 <geraldosimiao> and for the FE status? can we vote too?
18:02:42 <adamw> sure.
18:02:47 <Eighth_Doctor> +1 FE
18:02:50 <lruzicka> +1 FE
18:03:36 <geraldosimiao> +1 FE
18:04:19 <adamw> proposed #agreeed 2178971 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this does not meet any criteria (this is not a failed 'system service' as proposed), so it's rejected as a blocker. However, it's accepted as an FE to clean up these crashes in live environments and first boots after install, although we likely would not take a new git snapshot during freeze
18:04:25 <lruzicka> ack
18:04:30 <marcdeop[m]> ack
18:04:53 <copperi[m]> ack
18:05:04 <Eighth_Doctor> ack
18:05:12 <adamw> #agreeed 2178971 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this does not meet any criteria (this is not a failed 'system service' as proposed), so it's rejected as a blocker. However, it's accepted as an FE to clean up these crashes in live environments and first boots after install, although we likely would not take a new git snapshot during freeze
18:05:28 <geraldosimiao> ack
18:05:37 <adamw> grr
18:05:42 <adamw> too many es
18:05:44 <adamw> #agreed 2178971 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this does not meet any criteria (this is not a failed 'system service' as proposed), so it's rejected as a blocker. However, it's accepted as an FE to clean up these crashes in live environments and first boots after install, although we likely would not take a new git snapshot during freeze
18:06:06 <adamw> #topic (2180100) At sddm-wayland-plasma icons to reboot, shutdown, other dissapear and reapear
18:06:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2180100
18:06:10 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1121
18:06:14 <adamw> #info Proposed Blocker, sddm, NEW
18:06:26 <adamw> okay. NOW we're on buttons.
18:06:38 <geraldosimiao> ok, now we're talking about the buttons...
18:06:43 <geraldosimiao> 🤣
18:06:43 <marcdeop[m]> as much as it pains me.... +1 Blocker
18:07:29 <geraldosimiao> yeah, comparing sddm-x11 experience and sddm-wayland, this bug is really a thing...
18:07:33 <geraldosimiao> +1FB
18:07:36 <adamw> what's the criterion here?
18:07:50 <adamw> (I know the answer but I am testing you. :>)
18:07:54 <geraldosimiao> basic use of the login screen?
18:08:41 <geraldosimiao> if we offer some button for the user to select, it must be easy to click
18:09:06 <geraldosimiao> and not some easter egg thing
18:09:06 <geraldosimiao> I guess
18:09:07 <marcdeop[m]> I must be able to reboot/poweroff the computer from sddm
18:09:18 <geraldosimiao> good one
18:09:28 <Eighth_Doctor> +1 FB
18:13:11 <adamw> that's not a criterion
18:13:28 <adamw> the criterion is "Shutting down, rebooting, logging in and logging out must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. "
18:13:59 <adamw> i just want people to remember the practice of referring to what's actually written there. that's how we're supposed to decide this.
18:14:35 <adamw> i can be +1 to this as a violation of that
18:14:44 <geraldosimiao> ok
18:15:04 <LunaJernberg[m]> i would say its good if you can shut down and reboot from the login screen to when needed, for when Ctrl + Alt + Del or Win + L but if it works from the Plasma menu its all fine i guess
18:15:15 <geraldosimiao> so, 3 votes by now
18:15:20 <lruzicka> yes, it's exactly this, I'd'spose
18:16:05 <LunaJernberg[m]> but as i am not really a KDE person i won't vote
18:16:41 <Eighth_Doctor> if we talk about standard mechanisms, then I find it hard to be blockery about it
18:17:37 <adamw> i mean, I think we consider the items on the login manager to be part of that. that's why the test case covers them. step 8 in https://fedoraproject.org/wiki/QA:Testcase_desktop_login .
18:19:43 <geraldosimiao> yes, and thats wy we have disabled the fas user switching on kde spin, because it wasnt working properly
18:19:45 <geraldosimiao> *fast user switching
18:20:15 <adamw> yeah
18:20:16 <Eighth_Doctor> I don't know if we can just disable it in SDDM
18:20:27 <Eighth_Doctor> most of our controls are SDDM+Plasma KScreenLocker
18:20:41 <geraldosimiao> so, if we offer the button/option it must work and be "clickable"
18:21:20 <adamw> yeah, that's where i am with this one
18:22:35 <geraldosimiao> so, anyone else wanna vote on this?
18:23:06 <adamw> i guess we're at +3
18:23:58 <geraldosimiao> right
18:24:24 <adamw> proposed #agreed 2180100 - AcceptedBlocker (Final) - this is accepted as a violation of Beta criterion "Shutting down, rebooting, logging in and logging out must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops", as such options are intended to be available in SDDM as part of KDE, but they cannot be used properly due to this bug
18:24:28 <bcotton> ack
18:24:36 <geraldosimiao> ack
18:24:39 <Eighth_Doctor> ack
18:25:13 <adamw> #agreed 2180100 - AcceptedBlocker (Final) - this is accepted as a violation of Beta criterion "Shutting down, rebooting, logging in and logging out must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops", as such options are intended to be available in SDDM as part of KDE, but they cannot be used properly due to this bug
18:26:14 <adamw> okay
18:26:15 <adamw> let's move on to
18:26:21 <adamw> #topic Proposed Final freeze exceptions
18:26:28 <adamw> #topic (2178389) Qt application render very thin fonts after switch to VF version of Noto CJK fonts
18:26:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2178389
18:26:37 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1116
18:26:43 <adamw> #info Proposed Freeze Exceptions, qt5-qtbase, ASSIGNED
18:27:26 <LunaJernberg[m]> +1 FE
18:27:54 <Eighth_Doctor> +1 FE
18:28:00 <geraldosimiao> +1 FE
18:28:07 <lruzicka> +1 fe
18:28:21 <marcdeop[m]> +1 FE
18:28:44 <adamw> proposed #agreed 2178389 - AcceptedFreezeException (Final) - this looks bad for CJK users, and could easily be experienced on live images or first boot after install so cannot be fully addressed by an update
18:28:49 <lruzicka> ack
18:28:53 <LunaJernberg[m]> ack
18:28:59 <geraldosimiao> ack
18:29:16 <Eighth_Doctor> ack
18:29:33 <adamw> #agreed 2178389 - AcceptedFreezeException (Final) - this looks bad for CJK users, and could easily be experienced on live images or first boot after install so cannot be fully addressed by an update
18:30:27 <adamw> #info the punt decision for 2179998 is assumed to apply to FE status also, so moving on to
18:30:33 <adamw> #topic (2177722) systemd-oomd extremely aggressive in killing non-DE logins (sshd or console) and any commands running in them
18:30:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2177722
18:30:38 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1090
18:30:41 <adamw> #info Proposed Freeze Exceptions, systemd, NEW
18:30:47 <adamw> to me this kinda reads like a ... missing feature
18:31:03 <adamw> there's a feature to treat desktop sessions with kid gloves. but not console sessions.
18:31:09 <Eighth_Doctor> yeah
18:31:22 <LunaJernberg[m]> +1
18:31:32 <robatino> there still isn't a real response other than "Hmm." and CCing two more people
18:32:20 <lruzicka> +1 fe, let
18:32:29 <Eighth_Doctor> Davide Cavalca: ping ^
18:32:33 <lruzicka> let's make console great again
18:32:40 <geraldosimiao> +1 FE
18:32:51 <adamw> this is one where i'd want to know what we're voting on
18:32:52 <marcdeop[m]> +1 FE
18:32:56 <marcdeop[m]> lruzicka: lol
18:33:08 <adamw> i'm 0 till we have an actual proposed change to look at
18:34:42 <robatino> when the next F37 kernel is submitted for stable i'll try to collect a journalctl on my F37 box with hopefully a bunch of forced logouts (when i do "dnf update" one letter at a time)
18:35:28 <robatino> that's in console mode, of course. inside GNOME it would be fine
18:36:33 <adamw> why on f37?
18:36:38 <adamw> can't you reproduce on f38?
18:37:34 <robatino> i already did, in https://bugzilla.redhat.com/show_bug.cgi?id=2177722#c13 . but it happens more often in F37 and should be the same issue, so would help
18:37:50 <davide> anitazha has been looking into that
18:37:54 <davide> I'll follow up with her
18:37:55 <adamw> ah ok
18:37:58 <adamw> thanks davide
18:38:01 <adamw> and anita
18:38:11 <lruzicka> I need to go, have a nice time ... I have voted in case you do not want to punt.
18:38:15 <lruzicka> See you.
18:38:30 <LunaJernberg[m]> cyas
18:38:43 <geraldosimiao> 👋
18:38:57 <adamw> thanks lruzicka, we're nearly done anyway
18:39:24 <adamw> so, i guess this has enough votes to be accepted, which means i will use my dictatorial powers to decide what kinda fix is acceptable if it comes to that. see what you voted for. ;)
18:39:49 <geraldosimiao> this criterion apllies to that?
18:39:52 <geraldosimiao> https://fedoraproject.org/wiki/Fedora_38_Beta_Release_Criteria#Expected_installed_system_boot_behavior
18:40:01 <adamw> proposed #agreed 2177722 - AcceptedFreezeException (Final) - this is considered a serious enough potential problem for initial update after install that we should try to fix it for release
18:40:06 <adamw> there are no criteria for FE, exactly.
18:40:11 <adamw> there are just...principles.
18:40:42 <robatino> all the criteria appear to only appear to be inside a release-blocking desktop
18:41:20 <geraldosimiao> "A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention, and all virtual consoles intended to provide a working login prompt must do so. "
18:41:50 <geraldosimiao> if systemd-oomd kill it, it isnt working by this criterion
18:41:52 <adamw> robatino: yes, by definition, only release-blocking desktops are release-blocking. =)
18:42:07 <adamw> one of the fe principles is that a bug in a non-release-blocking desktop which would be a blocker for a blocking desktop is usually given an FE
18:42:57 <robatino> geraldosimiao: ok, so i guess it depends on the definition of "working login prompt"
18:43:29 <robatino> it lets you log in, but you can't stay logged in
18:44:06 <adamw> ack/nack/patch?
18:44:30 <geraldosimiao> I'll append the criterion
18:45:11 <geraldosimiao> I think, as described by robatino "It basically makes non-DE logins unusable since one can't risk doing anything significant in them due to the risk of it being aborted." it is this criterion affected
18:45:27 <geraldosimiao> but yes, FE for sure
18:45:58 <LunaJernberg[m]> FE +1
18:46:06 <adamw> i wouldn't consider this related to the login process.
18:46:15 <adamw> if we're talking about blocker. but we're voting on FE, here.
18:46:23 <Eighth_Doctor> +1 FE
18:46:43 <adamw> we already had votes, there's a proposal above, it needs ack/nack/patch
18:46:44 <adamw> then we can all escape this nightmare
18:46:58 <Eighth_Doctor> ack
18:47:03 <bcotton> ack
18:47:10 <LunaJernberg[m]> ack
18:47:18 <Eighth_Doctor> (this meeting has somehow eaten my whole day!)
18:47:18 <geraldosimiao> ack
18:47:37 <LunaJernberg[m]> Eighth_Doctor: yeah almost at  3 hours now
18:48:18 <adamw> #agreed 2177722 - AcceptedFreezeException (Final) - this is considered a serious enough potential problem for initial update after install that we should try to fix it for release
18:48:24 <adamw> alright, we're done
18:48:25 <adamw> whew
18:48:28 <adamw> #topic Open floor
18:48:32 <adamw> any other business, folks?
18:48:51 <LunaJernberg[m]> nope
18:48:58 <geraldosimiao> there's allways one big blocker meeting every release...
18:49:01 <geraldosimiao> we will keep this for f38?
18:49:02 <geraldosimiao> https://bugzilla.redhat.com/show_bug.cgi?id=2016563
18:49:13 <geraldosimiao> as common bug, I mean
18:49:36 <aleasto> oh how i wish that was fixed already
18:49:51 <geraldosimiao> does anyone have any news on this?
18:49:58 <adamw> common bugs entries aren't really release specific any more now they're on ask.fp.o
18:50:05 <adamw> it just can get another release tag added
18:50:16 <geraldosimiao> I think theres no ticket upstream
18:50:21 <adamw> i did ask if anyone's opened an upstream ticket...
18:50:30 <geraldosimiao> yeah, I saw
18:50:55 <geraldosimiao> its  	spice-vdagent right?
18:51:15 <geraldosimiao> if theres none, I'll open a ticket for it upstream
18:52:29 <geraldosimiao> oh there is
18:52:40 <geraldosimiao> https://gitlab.freedesktop.org/spice/linux/vd_agent/-/issues/26
18:53:02 <geraldosimiao> 8 months ago
18:54:33 <adamw> thanks
18:56:21 <adamw> anything else, folks?
18:56:50 <geraldosimiao> no
18:56:51 <LunaJernberg[m]> nope
18:56:51 <Eighth_Doctor> none from me
18:56:52 <marcdeop[m]> all done
18:56:58 <adamw> alrighty, thanks for sticking it out
18:57:23 <adamw> #endmeeting