16:00:59 <bcotton> #startmeeting F38-blocker-review
16:00:59 <zodbot> Meeting started Mon Mar 13 16:00:59 2023 UTC.
16:00:59 <zodbot> This meeting is logged and archived in a public location.
16:00:59 <zodbot> The chair is bcotton. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:59 <zodbot> The meeting name has been set to 'f38-blocker-review'
16:01:06 <bcotton> #meetingname F38-blocker-review
16:01:06 <zodbot> The meeting name has been set to 'f38-blocker-review'
16:01:21 <bcotton> #chair adamw
16:01:21 <zodbot> Current chairs: adamw bcotton
16:01:21 <bcotton> #topic Roll Call
16:01:49 <frantisekz> .hello2
16:01:50 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:01:55 <geraldosimiao> .hello geraldosimiao
16:01:56 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
16:02:11 <andi89gi> .hello andi89gi
16:02:12 <zodbot> andi89gi: Sorry, but user 'andi89gi' does not exist
16:02:22 <andi89gi> .hello andilinux
16:02:24 <zodbot> andi89gi: andilinux 'Andi Artz' <Kartz@gmx.net>
16:02:30 * kparal partly present
16:03:16 <frantisekz> .fire kparal partly
16:03:16 <zodbot> adamw fires kparal partly
16:03:37 <bcotton> welcome, everyone. we'll give folks a few more minutes to wander in
16:04:11 * marcdeop is present
16:04:29 <marcdeop> .hello marcdeop
16:04:34 <zodbot> marcdeop: marcdeop 'Marc Deop' <fedora@marcdeop.com>
16:04:43 <adamw> alrighty
16:05:07 * coremodule is here, willing to be the secretary.
16:05:44 <adamw> let's see if this works...
16:05:56 <zodbot> adamw: Error: Can't start another meeting, one is in progress.
16:05:59 <adamw> #meetingname F38-blocker-review
16:05:59 <zodbot> The meeting name has been set to 'f38-blocker-review'
16:06:02 <adamw> #topic Roll Call
16:06:04 <bcotton> i already started it for you adam
16:06:07 <adamw> morning folks, who's here for blocker fun>
16:06:17 <bcotton> and we even already started roll call :-)
16:06:27 <adamw> oh, sorry, missed scrollback
16:06:33 <andi89gi> Morning adamw
16:06:36 <bcotton> but you're #chair'ed and all ready for boilerplate :-)
16:07:05 <adamw> #topic Introduction
16:07:10 <adamw> Why are we here?
16:07:23 <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:28 <adamw> #info We'll be following the process outlined at:
16:07:32 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:36 <adamw> #info The bugs up for review today are available at:
16:07:40 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:43 <adamw> #info The criteria for release blocking bugs can be found at:
16:07:46 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:07:51 <adamw> #link https://fedoraproject.org/wiki/Fedora_38_Beta_Release_Criteria
16:07:53 <adamw> #link https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria
16:08:00 <adamw> #info for Final, we have:
16:08:33 <adamw> #info 5 Proposed Blockers
16:08:35 <adamw> #info 5 Accepted Blockers
16:08:36 <adamw> #info 2 Proposed Freeze Exceptions
16:08:46 <adamw> #info 4 Accepted Freeze Exceptions
16:08:57 <adamw> #info coremodule will secretarialize
16:09:01 <adamw> let's get started with:
16:09:05 <adamw> #topic Proposed Final blockers
16:09:36 <adamw> oh, first one has enough ticket votes, so i'll do that frm the ticket
16:09:39 <adamw> we're down to four
16:09:58 <adamw> #topic (2177725) Combo boxes in GTK4 can't be opened
16:09:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2177725
16:09:59 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1091
16:09:59 <adamw> #info Proposed Blocker, gtk4, VERIFIED
16:10:01 <adamw> #info Ticket vote: FinalBlocker (+2,0,-0) (+bcotton, +geraldosimiao)
16:11:12 <kparal> Seems like an obvious blocker to me. Major apps can't be used properly.
16:11:48 <lruzicka> .hello2
16:11:49 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:11:53 <adamw> yeah, this would affect a lot of things
16:11:54 <adamw> +1
16:11:57 <lruzicka> @kparal, which one?
16:12:19 <frantisekz> FinalBlocker +1
16:12:25 <frantisekz> #link https://bugzilla.redhat.com/show_bug.cgi?id=2177725
16:12:27 <frantisekz> @lruzicka
16:13:20 <lruzicka> +1 FB
16:14:05 <Eighth_Doctor> .hello ngompa
16:14:29 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:14:34 * marcdeop[m] /me is confused. Doesn't [this](https://bugzilla.redhat.com/show_bug.cgi?id=2177725#c2) say it's fixed?
16:14:46 <adamw> it's not fixed until an update goes stable.
16:14:48 <frantisekz> yes, it is fixed in the new gtk build
16:15:21 <adamw> proposed #agreed 2177725 - AcceptedBlocker (Final) - this would affect basic functionality of many GTK4 apps, combo boxes are a standard UI element
16:15:25 <frantisekz> ack
16:15:30 <geraldosimiao> ack
16:15:30 <bcotton> ack
16:15:31 <coremodule> ack
16:15:33 <kparal> ack
16:15:40 <lruzicka> ack
16:15:47 <marcdeop[m]> ack
16:16:20 <andi89gi> ack
16:16:53 <adamw> #agreed 2177725 - AcceptedBlocker (Final) - this would affect basic functionality of many GTK4 apps, combo boxes are a standard UI element
16:17:13 <adamw> #topic (2176766) Dragging files is Nautilus doesn't work as expected, quick movements result in a selection box instead
16:17:16 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2176766
16:17:23 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1085
16:17:24 <adamw> #info Proposed Blocker, nautilus, NEW
16:17:26 <adamw> #info Ticket vote: FinalBlocker (+4,2,-2) (+catanzaro, +nielsenb, +geraldosimiao, +bcotton, kparal, sgallagh, -frantisekz, -lruzicka)
16:17:28 <adamw> #info Ticket vote: FinalFreezeException (+2,0,-0) (+frantisekz, +sgallagh)
16:19:01 <adamw> hmm, this is very subjective
16:19:12 <lruzicka> indeed
16:19:14 <adamw> i kinda have the opposite experience to kparal
16:19:14 <adamw> my 'natural' click-and-drag motion works every time
16:19:20 <kparal> I assume this will be very subjective, yes
16:19:21 <adamw> i have to consciously do it "very fast" to trigger the bug
16:19:57 <adamw> everyone else wanna try and see what they think? it's a simple bug
16:20:02 <lruzicka> adamw, the same hold true for me, moreover I am using the trackball so I click first and then drag, works all the time
16:20:21 <kparal> I have to consciously focus to not trigger it 😄
16:20:25 <kparal> lruzicka: well that explains a lot
16:20:32 * marcdeop[m] doesn't have nautilus installed...
16:21:19 <kparal> I'm leaving this to others, I don't think I can judge this well
16:21:19 <frantisekz> FinalFeature (lets kparal focus :D ) +1, FinalBlocker -1
16:21:22 <adamw> dnf -y install nautilus
16:21:27 <adamw> there, copy and paste that :P
16:21:39 <adamw> based on my personal experience, a highly subjective FinalBlocker -1 , i think
16:22:28 <adamw> seems like a very split vote, though
16:22:34 <frantisekz> most of the time, i use keyboard, and not dragging, but when I drag, I do it slowly enough to to be an issue
16:23:10 <lruzicka> I am FinalBlocker -1, but it seems my workflow is not that standard enough :D
16:23:25 <marcdeop[m]> can somebody give me a link to learn how to vote?
16:23:29 <adamw> note we have +4 in the ticket
16:23:50 <adamw> marcdeop (@marcdeop:matrix.org): how do you mean? you vote in the meeting by saying +1 or -1 :P in a ticket there are instructions right there...
16:23:58 <geraldosimiao> anoying bug, me too usaly click and move roght away, so the bug stop my usual workflow
16:24:01 <geraldosimiao> *right away
16:24:04 <lruzicka> marcdeop[m], you can vote here, or in the ticket before the meeting
16:24:23 <marcdeop[m]> I wanted to abstain
16:24:37 <adamw> in this case we're basically voting whether we think this is bad enough to count as breaking "basic functionality" of the file manager.
16:24:48 <kparal> the reason why I proposed it is not that it's hard to work around once you know it, but for a large portion of our audience (not sure how large) this might appear as if drag&drop was completely broken in nautilus
16:24:53 <adamw> then you just have to say nothing ;) or if you want an explicit abstention, 0, I guess. but the voting system is not formal enough for it to matter
16:24:54 <kparal> that was my impression when I first met this bug
16:24:56 <lruzicka> marcdeop[m], this is the blocker bug application, you can vote here
16:24:58 <lruzicka> marcdeop[m], https://qa.fedoraproject.org/blockerbugs/
16:25:14 <adamw> at present we're about 50/50 split on this one
16:25:25 <lruzicka> kparal, does the mouse speed setting have an influence?
16:25:28 <adamw> so we have the cowardly option: punt and hope upstream fixes it by next week
16:25:38 <kparal> I guess it could
16:25:53 <lruzicka> I shall try, wait a moment
16:26:18 * bcotton waits to see if nautilus will actually launch on KDE Plasma without all of the gnome-y bits installed
16:26:21 <kparal> lruzicka: first you need to grab a mouse 🙂
16:27:47 <kparal> so I guess the thing to decide is not "works for me, because I move the cursor slow enough", but "are we OK if some sizable portion of our audience thinks that drag&drop is broken? Is documenting it enough?"
16:27:52 <lruzicka> kparal, the mouse speed seems not affect this
16:28:26 <kparal> my impression is that you need to be moving at the moment you click the button, and that's when the drag fails
16:28:35 <kparal> if you stop moving and only then click, it works as usual
16:28:52 <kparal> I do a continuous motion when dragging the file, not stopping over it
16:28:54 <lruzicka> kparal, then if the time frame shortens for drag, you will not be able to select any more :D
16:28:55 <adamw> kparal: well, the thing i'm trying to get a feel for is how big the "sizable portion" is likely to be
16:28:56 <adamw> treating people who happen to be here as a highly scientific sample population
16:29:29 <adamw> i guess i always stop on my target to make sure i'm in the right place before i do anything to it, thinking about it
16:29:41 <adamw> anyhoo
16:29:53 <kparal> let's do the cowardly approach then 🙂
16:30:20 <lruzicka> now I think that this bug will be about redefining how to use one's mouse correctly :D
16:30:43 <marcdeop[m]> you are holding it wrong. Jobs dixit
16:31:08 <bcotton> yeah, so i can get this behavior in the "normal" way i'd use it, so I'll stay +1 blocker
16:32:12 <lruzicka> all right then, I believe the second half of users who tend to use the mouse reasonably slow could live with both situations, so we should probably be friendly and vote for +1
16:32:35 <lruzicka> if it is that problematic for those affected then I am changing my mind.
16:32:53 <adamw> well of course it's best to fix it, the question is should we block on it =)
16:33:18 <adamw> if lukas is +1 and kamil's really a +1, i think we actually have enough to accept this, so let's go with that.
16:33:36 <kparal> I'm really 0 😄
16:33:52 <adamw> ok then for interests of time i'm +1
16:34:13 <adamw> proposed #agreed 2176766 - AcceptedBlocker (Final) - this is accepted as a violation of the "basic functionality" criterion for nautilus, in the case of impatient people who like to move the mouse real fast
16:34:23 <lruzicka> ack
16:34:25 <kparal> ack
16:34:46 <geraldosimiao> ack
16:34:55 <andi89gi> ack
16:35:08 <marcdeop[m]> ack
16:35:17 <bcotton> ack
16:35:23 <frantisekz> ack
16:35:43 <adamw> #agreed 2176766 - AcceptedBlocker (Final) - this is accepted as a violation of the "basic functionality" criterion for nautilus, in the case of impatient people who like to move the mouse real fast
16:35:56 <adamw> #topic (2113005) Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards
16:36:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2113005
16:36:03 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1087
16:36:07 <adamw> #info Proposed Blocker, shim, POST
16:36:09 <adamw> #info Ticket vote: FinalBlocker (+3,0,-3) (+geraldosimiao, +kparal, +bcotton, -frantisekz, -nielsenb, -sgallagh)
16:36:13 <adamw> #info Ticket vote: FinalFreezeException (+4,0,-0) (+frantisekz, +nielsenb, +lruzicka, +sgallagh)
16:36:34 <adamw> on the whole i'm still -1 on this. our current release has this bug, and we get a steady trickle of people hitting it, not a flood. there are multiple available workarounds.
16:36:55 <adamw> also, building shim is a giant pita that depends on microsoft, so if we block on this, who knows when we get a build.
16:37:03 <adamw> (i *was* kinda expecting it to have happened by now, though)
16:37:34 <kparal> perhaps it would have happened if we accepted it as f37 blocker and waived as hard to fix, thus becoming f38 beta one
16:38:43 <adamw> i'm not really sure about that honestly
16:38:56 <adamw> my impression is that shim builds happen on a schedule that's more decided in smoky upstream UEFI/SB backrooms than the fedora blocker process
16:39:15 <lruzicka> adamw, I love your metaphors
16:39:18 <geraldosimiao> I agree with Kamil
16:39:58 <geraldosimiao> this must be presented as a blocker, for pressure purposes
16:40:18 <adamw> in case anyone isn't aware, the problem with shim is it has to go through the Secure Boot signing process
16:40:19 <geraldosimiao> even if it is waived afterwards
16:40:31 <adamw> which means we have to send it to microsoft and a whole groaning bureaucratic machinery has to run before it actually gets signed
16:41:05 <adamw> anyhow, i'm still not convinced the bug really qualifies as a blocker. we've never blocked on every non-working piece of hardware
16:41:41 <lruzicka> Should we ask FeSCo? This seems to be like a lot of politics.
16:41:51 <Eighth_Doctor> it doesn't cause data loss, just lack of booting
16:41:55 <geraldosimiao> so, for f39 then? or f40?
16:41:56 <kparal> we have blocked e.g. on all nvidia gpus broken, etc
16:41:58 <Eighth_Doctor> but I don't like this
16:42:20 <Eighth_Doctor> I'm leaving quite heavily to blocker-y state for final, but....
16:42:40 <Eighth_Doctor> the problem is that the shim signing machinery is almost impossible to do in a timely fashion
16:42:47 <marcdeop[m]> on itself is probably not worth a blocker but... will it ever be fixed then?
16:42:56 <lruzicka> geraldosimiao, we are just a little masters, the morning star leads the cock-a-doodle-doing
16:43:16 <geraldosimiao> 🤣🤣
16:43:21 <Eighth_Doctor> can we declare it a blocker and then decide to waive it if it's the last man standing in go/no-go if it looks like we're not getting it soon enough?
16:43:21 <adamw> so far we have 11 affected motherboards/systems, several of which are closely-related Asus ones
16:43:38 <kparal> Eighth_Doctor: yes, hard-to-fix exception
16:43:49 <Eighth_Doctor> then let's go for blocker and see if we can get this fixed
16:43:59 <adamw> we can do that if we like, yes.
16:44:01 <Eighth_Doctor> from my FESCo hat, I'd +1 FinalBlocker
16:44:10 <adamw> what does your fesco hat have to do with it?
16:44:12 <kparal> the blocker will then move to F39 Beta
16:44:13 <marcdeop[m]> +1 FB
16:44:18 <adamw> we're currently voting on it as a regular blocker
16:44:21 <lruzicka> Eighth_Doctor, can Fesco push so that this gets fixed?
16:44:43 <Eighth_Doctor> we'd be asking pjones very nicely, I guess?
16:44:43 <adamw> lruzicka: unless fesco has SB signing keys, it can't do anything practical.
16:44:44 <Eighth_Doctor> like that's the same avenue everyone else has
16:44:47 <adamw> (spoiler: it doesn't.)
16:45:12 * Eighth_Doctor grumbles a bit about that but...
16:45:18 <lruzicka> adamw, so is there anything we could do to speed things up?
16:45:25 <lruzicka> we = Fedora
16:45:40 <Eighth_Doctor> give the SB shim devs coffee and exceptions from their normal work?
16:45:44 <adamw> lruzicka: not really. once we convince robbie or peter to crank up the machinery, we are at its mercy.
16:45:58 <adamw> ain't no wait we are going to get a build anywhere close to the f38 release date at this point.
16:46:01 <adamw> the shim devs have nothing to do with it
16:46:17 <adamw> well, all they have to do is run a build and submit it to microsoft, which is five minutes of work
16:46:22 <adamw> we had the fix for this months ago.
16:46:45 <adamw> i don't know why they didn't submit a build yet, but since they haven't, we're pretty doomed for 38 at this point
16:46:46 <geraldosimiao> can we see that for f39 already?
16:47:03 <adamw> you can see the fix on any release you like if you disable secure boot
16:47:07 <adamw> there's a scratch build linked in the bug report
16:47:52 <geraldosimiao> I mean, grant this process (the shim signin at MS) for f 39
16:48:08 <geraldosimiao> starting right now
16:48:29 <adamw> we can in theory do it any time. i have no idea when the maintainers intend to do it.
16:48:34 <adamw> i already asked in the bug twice,
16:49:42 <geraldosimiao> well, only way we (blocker bug process) can do right now is to grant it a blocker status, even if we waive it afterwads
16:50:45 <geraldosimiao> just to show the others that we are putting a bright flag on this
16:51:21 <adamw> as of right now, not counting me, we have +5 / -3 on this
16:51:33 <adamw> which isn't clear enoufh for a decision
16:51:35 <adamw> unless i missed any votes
16:53:16 <bcotton> so i guess we could punt, but i feel like that's the same as rejecting at this point
16:53:37 <bcotton> i actually think we might possibly get a signed shim turned around before final, but the window is closing rapidly
16:54:10 <bcotton> ("might" is doing a lot of work here, for what it's worth)
16:54:16 <lruzicka> are we ready to waive in case this does not happen?
16:54:27 <kparal> the only difference is whether we have it as F39 Beta blocker or not, I think. It will also clarify the importance to shim owners.
16:54:27 <bcotton> i would be willing to waive it if we had to
16:55:01 <geraldosimiao> yes
16:55:01 <kparal> lruzicka: we will have no other choice anyway
16:55:07 <adamw> you two are already on the record as +1, so
16:55:10 <lruzicka> can we also waive the F39 beta blocker when it does not go as planned?
16:55:15 <lruzicka> am I?
16:55:27 <lruzicka> I am not, only FE
16:55:41 <adamw> as i have it right now, we have: +1 geraldo kparal bcotton conan marcdeop
16:55:58 <adamw> -1 frantisekz nielsenb sgallagh
16:56:11 <lruzicka> so I can still vote either :D
16:56:58 <lruzicka> I am not sure if it makes sense to make a blocker that we will be waiving because there is no way how we could influence stuff.
16:56:58 <adamw> so unless anyone who didn't vote yet wants to vote +1 or anyone who's -1 wants to change, we're stuck punting
16:57:17 <adamw> lruzicka: the argument is that it 'flags it up' and also means it goes on the f39 blocker list, i think.
16:57:25 <adamw> which i don't love, but hey.
16:57:27 <geraldosimiao> the sense is to show the devs the importance of this
16:57:36 <lruzicka> adamw, sure, but what if nothing changes in F39?
16:58:15 <adamw> then we waive it forever, i guess.
16:58:16 <geraldosimiao> at least we try
16:59:20 <lruzicka> so, ok. Let's try then.
16:59:23 <adamw> sending messages isn't what the blocker process is for
16:59:27 <lruzicka> +1 FinalBlocker
16:59:28 <adamw> we do have the prioritized bug process for that
16:59:41 <bcotton> so my argument for making a decision now, for those who remain 0 or unvoted: if we accept it now, we have at least some possibility of a fix for f38. if we wait, we've essentially decided to wait until f39 (at which point we could try to call it a blocker)
17:00:11 <andi89gi> +1 FinalBlocker
17:00:42 <frantisekz> for f38, we'll be risking other regressins from new shim
17:00:46 <frantisekz> I wouldn't do that
17:01:08 <bcotton> for what it's worth, my +1 to blocker status is independent of the timing question
17:01:10 <adamw> proposed #agreed 2113005 - AcceptedBlocker (Final) - this is accepted as a conditional violation of "All release-blocking images must boot in their supported configurations" when booting in native UEFI mode on affected hardware.
17:01:10 <frantisekz> I guess they won't be submitting what we currently have just with that backported
17:01:28 <geraldosimiao> ack
17:01:28 <bcotton> ack
17:01:31 <andi89gi> ack
17:01:38 <kparal> ack
17:01:40 <lruzicka> ack
17:01:44 <adamw> and yes, frantisekz has a point. a consequence of the signing issue with shim is that if we break anything *else* we're boned.
17:02:06 <adamw> (well, not entirely boned, as we can always use any earlier signed shim build.)
17:02:23 <adamw> #agreed 2113005 - AcceptedBlocker (Final) - this is accepted as a conditional violation of "All release-blocking images must boot in their supported configurations" when booting in native UEFI mode on affected hardware.
17:02:39 <adamw> #topic (2177784) Sound volume is sometimes 0% after login (a race condition)
17:02:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2177784
17:02:44 <marcdeop[m]> ack
17:02:44 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1092
17:02:47 <adamw> #info Proposed Blocker, wireplumber, NEW
17:03:18 <aleasto> this is also happeningin f37 since very recently
17:03:30 <frantisekz> punt maybe till we have more data/reproducer?
17:03:56 <adamw> assuming you can turn the volume up, then i'm -1
17:03:58 <kparal> yeah, I guess it would be wise to test it more first
17:04:14 <marcdeop[m]> -1
17:04:39 <marcdeop[m]> (assuming, as adamw , you can turn it   up)
17:04:43 <aleasto> yea you can turn the volume up
17:04:43 <kparal> we do have a criterion that the volume must be reasonable after boot, I believe
17:04:46 <kparal> looking for it
17:05:45 <kparal> ok, I was wrong. It's only the test case, but the criterion doesn't say so
17:05:48 <kparal> or I haven't found it
17:06:13 <kparal> so -1 it seems
17:06:16 <Eighth_Doctor> we probably should have a criterion for it, but for now... -1
17:06:22 <frantisekz> okey dokey, -1 then
17:06:38 <andi89gi> -1
17:06:43 <adamw> i am totally fine with there not being a criterion, honestly
17:06:50 <lruzicka> -1, I would vote +1 only if it happened on each boot.
17:07:05 <bcotton> -1, but i wish i weren't :-)
17:07:12 <aleasto> in my experience it's every boot, on f37
17:07:24 <aleasto> but ticket says otherwise
17:07:28 <kparal> my gnome-shell session just crashed. that's nice
17:07:29 <adamw> i might vote +1 for the volume being 200% on bootup every time (as that can cause problems) but i think not for 0%...
17:07:47 <geraldosimiao> -1
17:08:58 <adamw> proposed #agreed 2177784 - RejectedBlocker (Final) - this isn't serious enough to be considered a criteria violation. The criterion says "The installed system must be able to play back sound with gstreamer-based applications"; if affected by this bug you can play sound, you just have to turn the volume up first.
17:09:01 <frantisekz> I am not seeing this on wireplumber-0.4.13-1.fc37.x86_64 , will try regression test with .4.14 which would probably be an issue since that arrived in f37 too
17:09:08 <frantisekz> ack
17:09:19 <lruzicka> ack
17:09:22 <adamw> do we wanna give it an FE?
17:09:28 <adamw> i'd be +1 FE
17:09:36 <lruzicka> +1 FE
17:09:43 <geraldosimiao> +1FE for me too
17:09:51 <bcotton> +1 FE in case it doesn't get fixed before 4 april
17:09:52 <adamw> freeze is april 4, but hey, just in case
17:09:53 <frantisekz> yep
17:10:11 <adamw> proposed #agreed 2177784 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this isn't serious enough to be considered a criteria violation. The criterion says "The installed system must be able to play back sound with gstreamer-based applications"; if affected by this bug you can play sound, you just have to turn the volume up first. It is bad polish, though, so we grant an FE
17:10:43 <frantisekz> poor poles adamw :(
17:10:44 <frantisekz> ack
17:10:45 <kparal> ack
17:10:46 <bcotton> ack
17:10:47 <geraldosimiao> ack
17:11:01 <kparal> adamw: I just proposed https://bugzilla.redhat.com/show_bug.cgi?id=2177853
17:11:21 <kparal> fyi
17:12:19 <adamw> #agreed 2177784 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this isn't serious enough to be considered a criteria violation. The criterion says "The installed system must be able to play back sound with gstreamer-based applications"; if affected by this bug you can play sound, you just have to turn the volume up first. It is bad polish, though, so we grant an FE
17:12:33 <adamw> kparal: agh i would like to escape from this tennis centre waiting room at some point
17:13:13 <kparal> we can leave it to next week or tickets
17:13:18 <kparal> "late proposal" for a meeting 😄
17:14:14 <adamw> #topic (2177853) Logout/reboot/poweroff timeout leaves the session in a broken state, doesn't perform the action
17:14:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2177853
17:14:50 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:14:50 <adamw> so, what's the criterion here?
17:15:01 <adamw> (i am noting a distressing lack of criterion citations with blocker proposals lately)
17:15:12 <kparal> my gnome-shell got unresponsive again
17:15:22 <kparal> yeah, because I have distressing lack of time 🙂
17:15:43 <kparal> I can either file and propose more, or care about the old ones more
17:15:55 <adamw> do everything
17:16:03 <kparal> I haven't thought about that
17:16:11 <kparal> so the session management criterion, let me find it
17:16:15 <adamw> that's why i'm the boss, see
17:16:30 <lruzicka> I think this would be the login criterion.
17:16:40 <kparal> https://fedoraproject.org/wiki/Fedora_38_Beta_Release_Criteria#Shutdown,_reboot,_login,_logout
17:16:57 <adamw> "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"
17:17:17 <bcotton> +1 on that
17:17:42 <lruzicka> This is severe for Gnome. This should not be happening.
17:17:45 <lruzicka> +1 FB
17:17:58 <kparal> for general users, I think the major problem here is that if you don't react (in 60 seconds), you have a broken desktop of sorts
17:18:08 <adamw> i guess i'm a +1 as a conditional violation
17:18:13 <kparal> I don't know how many users rely on auto-reboot etc
17:18:21 <geraldosimiao> confirmed here too
17:18:29 <geraldosimiao> FinalBlocker +1
17:18:30 <kparal> but users noticed this during the gnome test week, see the duplicate
17:18:38 <kparal> so I guess somebody needs the auto-action
17:19:33 <kparal> I think I'm also more into +1 blocker
17:19:45 <lruzicka> what is auto-reboot?
17:19:56 <geraldosimiao> it jumps 10 seconds too (decrease in 10s steps)
17:20:02 <kparal> after 60 seconds
17:20:08 <geraldosimiao> the timout
17:20:16 <kparal> geraldosimiao: that's expected, I believe
17:20:23 <kparal> the last 10 seconds update by 1 second
17:20:30 <geraldosimiao> ok. confirmed
17:20:40 <kparal> lruzicka: the event after 60 second timeout
17:20:44 <geraldosimiao> bug still on the 20230312 iso
17:20:58 <adamw> proposed #agreed 2177853 - AcceptedBlocker (Final) - this is accepted as a conditional violation of "Shutting down [etc]...must work using...the mechanisms offered (if any) by all release-blocking desktops" in the case where you wait for the automatic action to happen after the timeout
17:21:08 <lruzicka> kparal, ah, ok
17:21:21 <lruzicka> ack
17:21:28 <bcotton> ack
17:22:12 <geraldosimiao> ack
17:22:33 <adamw> #agreed 2177853 - AcceptedBlocker (Final) - this is accepted as a conditional violation of "Shutting down [etc]...must work using...the mechanisms offered (if any) by all release-blocking desktops" in the case where you wait for the automatic action to happen after the timeout
17:22:41 <adamw> okay, moving on to:
17:22:47 <adamw> #topic Proposed Final freeze exception issues
17:23:02 <adamw> #topic (2176732) delete an album and undo the delete operation makes the album is not shown in the "Add to album" list
17:23:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2176732
17:23:03 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1083
17:23:06 <adamw> #info Proposed Freeze Exceptions, gnome-photos, NEW
17:23:08 <adamw> #info Ticket vote: FinalBlocker (+0,0,-5) (-frantisekz, -catanzaro, -nielsenb, -geraldosimiao, -lruzicka)
17:23:11 <adamw> #info Ticket vote: FinalFreezeException (+1,0,-0) (+lruzicka)
17:23:40 <adamw> i dunno if this is really worth a freeze exception since it seems unlikely people will do a lot of photo management from live images, but meh
17:23:46 <adamw> if the fix is specific to the app i guess i'm ok with it
17:24:14 <kparal> +1 FE
17:24:41 <lruzicka> this happens on normal installs, too
17:25:01 <lruzicka> I could reproduce it on my system
17:25:15 <kparal> we can only vote on those that have a patch, if we want to speed up the meeting
17:25:25 <geraldosimiao> I'll add this to my previous vote
17:25:25 <geraldosimiao> +1 FE
17:25:50 <adamw> lruzicka: yes, but the logic is that FEs mainly matter for things you will encounter in live sessions or immediately on first boot
17:26:02 <adamw> because after that we expect you update and therefore you can get the fix as an update and it'll be fine.
17:26:11 <bcotton> 0 FE
17:26:43 <lruzicka> adamw, ok ... in that case this really does not matter that much
17:26:46 <adamw> +1 FE for a fix that doesn't touch anything else, i guess
17:26:57 <lruzicka> +1 FE for such fix
17:27:30 <adamw> proposed #agreed 2176732 - AcceptedFreezeException (Final) - this is accepted to improve final release polish, so long as the proposed fix does not present any risk to anything more important
17:27:37 <lruzicka> ack
17:27:49 <marcdeop[m]> ack
17:27:50 <frantisekz> ack
17:27:53 <geraldosimiao> ack
17:27:59 <bcotton> ack
17:28:44 <andi89gi> ack
17:29:09 <adamw> #agreed 2176732 - AcceptedFreezeException (Final) - this is accepted to improve final release polish, so long as the proposed fix does not present any risk to anything more important
17:29:22 <adamw> #topic (2177722) systemd-oomd extremely aggressive in killing non-DE logins (sshd or console) and any commands running in them
17:29:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2177722
17:29:30 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1090
17:29:35 <adamw> #info Proposed Freeze Exceptions, systemd, NEW
17:30:11 <robatino> this is probably limited to low-RAM systems
17:31:07 <lruzicka> +1 fe
17:31:42 <adamw> well, i mean, of course anything to do with the oomd is more likely to be encountered when you have less memory :D
17:31:45 <adamw> i think this is one where i'd want to know the circumstances of a proposed fix to vote
17:31:54 <robatino> the easiest workaround is just to remove systemd-oomd-defaults and reboot. than systemd-oomd is still running, but it's not monitoring anything, so nothing gets killed
17:31:56 <adamw> i.e. i don't want to vote on it when it's just a bug report, no proposed patch or developer feedback
17:32:06 <bcotton> hm. this one is interesting :-)
17:32:53 <robatino> it seems silly to me that a given command is protected when running in a high-resource DE, but not outside
17:33:23 <bcotton> yeah, i think i'm with you on that, adam. especially since we're ~3 weeks away from freeze anyway
17:36:50 <adamw> anyone else?
17:36:54 <adamw> will propose a punt if not
17:37:24 <geraldosimiao> @robatino if you use the same VM config (ram) with a DE it works fine?
17:38:46 <robatino> yes, i first noticed it in a 2GB F38 vbox VM. first i raised the RAM to 4GB and that seemed to fix it. then when i learned that it might work in GNOME, i lowered the RAM to 2GB and ran the same commands in GNOME and they work reliably there, just not in a console
17:39:21 <adamw> proposed #agreed 2177722 - punt (delay decision) - it's hard to make any decision here without some details of any proposed fix. we will leave this until there's actually a necessary decision to make (i.e. a proposed fix during the freeze period)
17:39:36 <geraldosimiao> ok
17:39:40 <geraldosimiao> ACK
17:39:42 <lruzicka> ack
17:39:49 <robatino> ack
17:40:30 <adamw> #agreed 2177722 - punt (delay decision) - it's hard to make any decision here without some details of any proposed fix. we will leave this until there's actually a necessary decision to make (i.e. a proposed fix during the freeze period)
17:40:47 <adamw> and unless anyone proposed anything else in the last few minutes, that's the lot
17:40:51 <adamw> #topic Open floor
17:40:55 <adamw> any other business, folks?
17:41:12 <geraldosimiao> no
17:41:28 <bcotton> +1 nap time
17:41:35 <marcdeop[m]> just thank you all for your work and dedication
17:41:46 <adamw> thanks for coming out, everybody
17:42:24 <adamw> i've got a bus to catch, sooo
17:42:26 <adamw> #endmeeting