16:01:17 <adamw> #startmeeting F36-blocker-review
16:01:17 <zodbot> Meeting started Mon Mar 14 16:01:17 2022 UTC.
16:01:17 <zodbot> This meeting is logged and archived in a public location.
16:01:17 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:01:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:17 <zodbot> The meeting name has been set to 'f36-blocker-review'
16:01:21 <adamw> #meetingname F36-blocker-review
16:01:21 <zodbot> The meeting name has been set to 'f36-blocker-review'
16:01:26 <adamw> #topic Roll Call
16:01:29 <adamw> morning folks, who's around for blocker fun?
16:03:06 <bcotton> .hello2
16:03:07 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:03:53 <cmurf> .hello
16:03:53 <zodbot> cmurf: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
16:04:03 <cmurf> .hello2
16:04:04 <zodbot> cmurf: cmurf 'Chris Murphy' <chris@cmurf.com>
16:04:26 <nielsenb> I'm here
16:04:37 <lruzicka2> #meetoo
16:06:02 <geraldosimiao> .hello geraldosimiao
16:06:03 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
16:06:15 <lruzicka2> .hello lruzicka
16:06:16 <zodbot> lruzicka2: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:07:38 <adamw> hi hi
16:07:39 <coremodule> .hello2
16:07:40 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:07:43 <adamw> i'm just going through the ticket votes quickly...
16:07:45 * coremodule willing to act as secretary.
16:09:51 <adamw> thanks
16:11:26 <Eighth_Doctor> .hello ngompa
16:11:27 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:11:44 <adamw> hi hi
16:12:20 <adamw> okey dokey
16:12:27 <adamw> #chair coremodule cmurf
16:12:27 <zodbot> Current chairs: adamw cmurf coremodule
16:12:34 <adamw> impending boilerplate alert!
16:12:38 <adamw> #topic Introduction
16:12:41 <adamw> Why are we here?
16:12:44 <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:12:50 <adamw> #info We'll be following the process outlined at:
16:12:51 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:12:54 <adamw> #info The bugs up for review today are available at:
16:12:57 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:12:59 <adamw> #info The criteria for release blocking bugs can be found at:
16:13:02 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:13:05 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria
16:13:08 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria
16:13:20 <adamw> #info for Beta, we have:
16:13:26 <adamw> #info 2 Proposed Blockers
16:13:29 <adamw> #info 4 Accepted Blockers
16:13:33 <adamw> #info 2 Proposed Freeze Exceptions
16:13:33 <adamw> #info 10 Accepted Freeze Exceptions
16:13:40 <adamw> #info for Final, we have:
16:13:50 <adamw> #info 7 Proposed Blockers
16:13:57 <adamw> #info 8 Accepted Blockers
16:13:58 <adamw> #info 3 Proposed Freeze Exceptions
16:14:10 <adamw> those counts are a bit outdated, but i'm not waiting an hour for them to regenerate :D
16:14:26 <adamw> #info coremodule will secretarialize
16:14:29 <adamw> let's start with:
16:14:33 <adamw> #topic Proposed Beta blockers
16:14:43 <adamw> #topic (2063156) Workstation Live is frozen in a VM with QXL video driver (Virtio works OK)
16:14:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2063156
16:14:50 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/656
16:14:53 <adamw> #info Proposed Blocker, mutter, NEW
16:14:56 <adamw> #info Ticket vote: BetaBlocker (+1,0,-4) (+ngompa, -frantisekz, -chrismurphy, -nielsenb, -lruzicka)
16:15:01 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+lruzicka)
16:15:12 <adamw> this has -3, but i figured i'd bring it up for vote as it's kinda a close call
16:15:40 <adamw> i think i'm leaning -1 beta on this, possibly +1 final...
16:15:47 <adamw> it's very on-the-fence-y
16:16:16 <lruzicka2> I would support this view
16:17:01 <cmurf> I think +2 final might be needed. I'm not sure when the default changed
16:17:28 <geraldosimiao> -1 beta blocker
16:17:28 <geraldosimiao> +1 beta FE
16:17:28 <geraldosimiao> +1 final blocker
16:17:56 <cmurf> If VMs using qxl stop working on upgrades... I'd be +1 final blocker
16:18:03 <adamw> cmurf: sorry, what default?
16:18:10 <cmurf> Video
16:18:13 <lruzicka2> +1 final, -1 beta
16:18:14 <nielsenb> I would support that
16:18:19 <bcotton> yeah, it's not clear to me what the actual scope of this is
16:18:23 <cmurf> Used to be qxl
16:18:24 <adamw> oh i see.
16:18:24 <geraldosimiao> Qxl video default
16:18:25 <lruzicka2> Kamil says in 4.0.0
16:18:48 <lruzicka2> which is now in updates-testing F36
16:18:58 <lruzicka2> I am running it on my machines
16:19:17 <cmurf> Ohhh
16:19:17 <adamw> i kinda thought it happened earlier, but...
16:19:52 <lruzicka2> adamw, I did not notice that it changed :D
16:19:52 <cmurf> So the previous version is what's slated for beta? And it uses qxl?
16:20:00 <adamw> hmm, it's right there in the 4.0.0 changelog
16:20:06 <cmurf> So basically this missed freeze?
16:20:18 <cmurf> Sheeeeat
16:20:27 <adamw> cmurf: it's more complicated than that.
16:20:38 <adamw> for virtualization, we really care about what's in current stable releases more than what's in the new release
16:21:04 <adamw> since logically speaking, people are more likely to run f36 VMs on f35 or f34 than on f36, at least at beta time, and maybe at initial final release too.
16:21:17 <adamw> so we can't just say this is fine if we push 4.0.0 stable for f36.
16:21:40 <cmurf> This we have to consider the qxl problem rather than arguing (as I have) that it's mooted by virtio being default
16:21:43 <adamw> (also, as you say, existing VMs don't get their config changed on upgrade)
16:21:46 <lruzicka2> that would need to be 4.0.0 for 35 anyway
16:21:51 <adamw> cmurf: basically, yes.
16:21:58 <cmurf> It actually isn't default yet. That version is in u-t.
16:22:52 <lruzicka2> if there is 4.0.0 in F35 and F34, it would solve the situation for any new VM
16:23:10 <cmurf> Umm, well. Is it reproducible?
16:23:52 <adamw> that's another fun part
16:23:54 <adamw> it seems to be race-y
16:23:56 <lruzicka2> cmurf,  as per the bug description, it is reproducible
16:23:59 <cmurf> If yes then probably +1 beta blocker
16:24:30 <lruzicka2> cmurf, however, it only happens from time to time, more often in user based libvirt VM
16:24:45 <adamw> and, uh, may or may not differ depending on whether you're using system or user libvirt session
16:24:46 <cmurf> I see. So GNOME Boxes?
16:25:03 <cmurf> I thought Boxes switched to virtio video a while ago...hmmm
16:25:04 <lruzicka2> these are affected according to kparal
16:25:12 <adamw> boxes has been using virtio for longer
16:25:23 <adamw> kparal just happened to be using a user session in virt-manager.
16:25:31 <cmurf> Gotcha
16:25:37 <lruzicka2> adamw, he mentioned Boxes as well, let me see
16:25:46 <cmurf> I'm not even sure how to do that
16:26:03 <lruzicka2> cmurf, you need to add it specifically
16:26:18 <cmurf> OTB virt-manager uses a root qemu session
16:26:42 <nielsenb> I use user for everything, with both boxes and virt-manager, not sure how common that is
16:27:05 <nielsenb> If you dismiss the privilege escalation prompt on opening the virt-manager ui, it still works in user mode
16:27:05 <cmurf> Ok if it's only happening with user session and is racy, then -1 beta blocker
16:27:11 <lruzicka2> adamw, yes, the bug mentions gnome-boxes, when it runs a virt-manager created vm
16:27:14 <cmurf> +1 final blocker
16:27:33 <lruzicka2> adamw, so it probably will not be seen there if you create a new vm
16:29:57 <adamw> it would probably help if more people tested to see how common this is on different systems
16:30:02 <adamw> i'll try on my laptop later
16:30:18 <cmurf> Yeah I haven't run into it
16:30:20 <adamw> but on the whole i think it's got enough caveats to be -1 beta, we can common bugs 'use virtio'
16:30:36 <adamw> anyone voting +1 beta?
16:30:46 <lruzicka2> no
16:30:50 <nielsenb> I'm not
16:30:50 <bcotton> -1 beta
16:31:51 <adamw> alrighty
16:33:30 <adamw> proposed #agreed 2063156 - RejectedBlocker (Beta) - this is pretty bad, but since it apparently doesn't happen consistently in the most common config (system virt session) and is easy to workaround (use virtio), we think it's not bad enough to block Beta
16:33:46 <nielsenb> ack
16:34:07 <coremodule> ack
16:34:11 <cmurf> ack
16:34:20 <lruzicka2> ack
16:34:32 <bcotton> ack
16:34:43 <adamw> #agreed 2063156 - RejectedBlocker (Beta) - this is pretty bad, but since it apparently doesn't happen consistently in the most common config (system virt session) and is easy to workaround (use virtio), we think it's not bad enough to block Beta
16:35:03 <adamw> the other proposed beta blocker was rejected by ticket vote, so let's move on to:
16:35:08 <geraldosimiao> ack
16:35:12 <adamw> #topic Proposed Beta freeze exceptions
16:35:15 <adamw> #topic (2063800) ImportError: No library named udev
16:35:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2063800
16:35:21 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/663
16:35:24 <adamw> #info Proposed Freeze Exceptions, anaconda, NEW
16:35:27 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+frantisekz)
16:36:08 <bcotton> +1 BetaFE
16:36:25 <adamw> failure to compose a non-blocking image, seems +1-y to me.
16:36:42 <nielsenb> +1 BetaFE
16:36:43 <coremodule> +1 Beta FE
16:36:45 <geraldosimiao> +1 BetaFE
16:37:29 <lruzicka2> +
16:37:32 <lruzicka2> 1
16:37:39 <adamw> proposed #agreed 2063800 - AcceptedFreezeException (Beta) - failure to compose a non-release-blocking image is typically accepted as an FE issue, as we like to get all the images built for Beta if possible!
16:37:45 <nielsenb> ack
16:37:46 <lruzicka2> ack
16:38:44 <geraldosimiao> ack
16:39:02 <bcotton> ack
16:39:08 <adamw> #agreed 2063800 - AcceptedFreezeException (Beta) - failure to compose a non-release-blocking image is typically accepted as an FE issue, as we like to get all the images built for Beta if possible!
16:39:26 <adamw> the other Beta FE was accepted by ticket vote, so let's move on to:
16:39:27 <adamw> oh, wait
16:39:46 <adamw> i proposed the rejected blocker as an FE, so:
16:39:54 <adamw> #topic (2037047) SELinux preventing systemd-network-generator from creating files in /run/systemd/network/
16:39:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2037047
16:40:00 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/651
16:40:09 <adamw> #info Proposed Freeze exception, selinux-policy, ASSIGNED
16:40:15 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+nielsenb)
16:40:39 <adamw> i guess +1 FE for a safe fix, it seems like there are cases where someone might want to use this feature before an update is possible...
16:41:19 <bcotton> aye. +1 FE
16:41:40 <geraldosimiao> +1 BetaFE
16:42:34 <lruzicka2> +1fe
16:43:04 <adamw> proposed #agreed 2037047 - AcceptedFreezeException (Beta) - this is accepted as a Beta FE as it seems likely someone might want to use this feature before an update is possible, and it'd be nice if we could make it work
16:43:13 <lruzicka2> ack
16:44:07 <bcotton> ack
16:44:28 <nielsenb> ack
16:44:43 <adamw> #agreed 2037047 - AcceptedFreezeException (Beta) - this is accepted as a Beta FE as it seems likely someone might want to use this feature before an update is possible, and it'd be nice if we could make it work
16:44:53 <adamw> okely dokey
16:44:56 <adamw> so let's really move on to:
16:45:00 <adamw> #topic Proposed Final blockers
16:46:45 <adamw> #topic (2059556) crash happens after quit from map
16:46:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2059556
16:46:52 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/661
16:46:55 <adamw> #info Proposed Blocker, gjs, NEW
16:47:53 <cmurf> hmm
16:48:00 <cmurf> so it works OK up until it's quit and then it crashes
16:48:09 <cmurf> any data loss or corruption?
16:48:20 <nielsenb> "that's not how you quit, I'll show you a quit"
16:48:26 <cmurf> that's probably a no...
16:48:30 <cmurf> haha
16:48:56 <cmurf> i'm +1 final blocker today but i really think i'd become -1 final blocker if it's the last bug standing
16:49:00 <lruzicka2> I just closed Maps, no crash is visible
16:49:01 <adamw> yeah
16:49:04 <cmurf> and thus i probably shouldn't be +1
16:49:09 <adamw> lruzicka2: try from a console
16:49:12 <adamw> i see the crash
16:49:14 <lruzicka2> adamw, ok
16:49:20 <nielsenb> You can export an image, does maps have any other data saving functionality?
16:49:21 <adamw> but i kinda agree it's -1; crash on shutdown doesn't really violate criteria for me
16:49:31 <cmurf> yeap
16:49:50 <cmurf> -1 final blocker
16:50:00 <nielsenb> -1 FinalBlocker
16:50:00 <lruzicka2> adamw, ok, there is one on the console
16:50:23 <cmurf> maybe it saves some history state for searches and locations you've clicked on? not sure
16:50:43 <bcotton> -1 final blocker. "exits with more enthusiasm than required" seems acceptable to me
16:50:53 <geraldosimiao> strange, I cannot reproduce that here on the VM
16:51:03 <geraldosimiao> -1 FinalBlocker
16:51:03 <cmurf> oh i just got a crash  quitting it within GNOME shell, not console
16:51:14 <lruzicka2> cmurf, Clutter-CRITICAL **: 17:49:32.451: Unable to create dummy onscreen: No foreign surface
16:51:20 <geraldosimiao> bcotton: 😂😂
16:51:20 <cmurf> clicked Maps on the Dash, let it load up stuff, quit from the menu - got a crash notification
16:51:27 <cmurf> i think we have a crash notification criterion don't we?
16:51:42 <nielsenb> I think that's just for crashes on boot
16:51:47 <lruzicka2> cmurf, on boot only
16:51:53 <adamw> yes, but it wouldn't cover this
16:52:00 <cmurf> ok
16:52:05 <cmurf> well hopefully it gets fixed!
16:52:37 <adamw> proposed #agreed 2059556 - RejectedBlocker (Final) - a crash on shutdown with no other ill effects does not violate the 'basic functionality' or 'no crash notifications on boot' criteria, so this is rejected
16:52:47 <geraldosimiao> well, I don't get that crash notification at all
16:52:48 <nielsenb> ack
16:52:58 <geraldosimiao> ohh wait
16:53:02 <geraldosimiao> now I get
16:53:06 <bcotton> ack
16:53:12 <geraldosimiao> one minute after
16:53:16 <geraldosimiao> ack
16:53:19 <lruzicka2> ack
16:53:27 <adamw> #agreed 2059556 - RejectedBlocker (Final) - a crash on shutdown with no other ill effects does not violate the 'basic functionality' or 'no crash notifications on boot' criteria, so this is rejected
16:54:15 <adamw> #topic (2060320) On Fedora 36 KDE, abrt starts with an empty window without any control widgets.
16:54:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2060320
16:54:23 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/654
16:54:25 <adamw> #info Proposed Blocker, gnome-abrt, ASSIGNED
16:54:29 <adamw> #info Ticket vote: FinalBlocker (+2,0,-0) (+catanzaro, +nielsenb)
16:54:38 <adamw> it's not really an empty window, it's just too big for the screen on KDE at 1024x768
16:54:50 <adamw> i'm probably -1, it's a bit annoying but easy to deal with, and only affects KDE at low resolution
16:55:16 <lruzicka2> adamw, yeah, I can live with it as a proposer
16:55:23 <nielsenb> It doesn't do anything similarly silly at say, ultrawide?
16:55:29 <geraldosimiao> thats an annoying resolution problem
16:55:38 <nielsenb> Or any other common-ish modern resolution?
16:55:44 <geraldosimiao> -1 Final Blocker
16:56:02 <adamw> dunno if we tested ultrawide
16:56:03 <lruzicka2> nielsenb, no, if the resolution is bigger, the app stays small enough
16:56:15 <nielsenb> Fair enough
16:56:16 <lruzicka2> adamw, I tested on 1600x1200
16:56:19 <adamw> but even ultrawide modern monitors are usually taller than 768 aren't they?
16:56:27 <nielsenb> Yeah
16:56:28 <adamw> they're usually like around 1000 pixels high, i thought
16:56:38 <bcotton> i'm kinda waffly. 1024x768 doesn't seem unreasonably small for a VM
16:56:55 <lruzicka2> bcotton, this is a default VM resolution
16:56:59 <adamw> Ben Cotton (he/him/his): i think it should be fixed, it just seems a bit much to block release on it
16:57:13 <cmurf> yeah
16:57:26 <nielsenb> I'm increasingly inclined to agree
16:57:32 <adamw> Ben Cotton (he/him/his): do you think it'd pass the last blocker test
16:57:37 <cmurf> there has been a thought to bump default VM resolution for a while now
16:57:51 <cmurf> i'm not sure what's needed to get there
16:57:56 <nielsenb> It would be nice, Anaconda can be kinda clunky at the default
16:58:13 <lruzicka2> nielsenb, Anaconda is going to be web based
16:58:21 * geraldosimiao uploaded an image: (326KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/SDPtoqKTzNtYXVFsVDmNsxHu/Screenshot_20220314_135748.png >
16:58:27 <lruzicka2> nielsenb, no idea how it will look like
16:58:37 <geraldosimiao> resizing the window all reapears
16:58:49 <nielsenb> This sounds easy enough to live with
16:58:55 <nielsenb> -1 FinalBlocker
16:58:56 <cmurf> i don't love it but i can accept that as a work around
16:59:04 <cmurf> -1 Final Blocker
17:00:13 <adamw> ok, so i think we're at, uh...-4 / +1
17:00:17 <adamw> any more votes?
17:00:24 <lruzicka2> nielsenb, actually I do ... today they showed me ... it will be based on the same backend as cockpit is
17:00:41 <lruzicka2> -1 to throw the number
17:00:50 <nielsenb> Did you test it on a 5 year old phone screen, did it work okay? :)
17:01:07 <Eighth_Doctor> -1 FinalBlocker
17:01:11 <geraldosimiao> -1 Final Blocker
17:01:33 <adamw> geraldosimiao: nice try, you voted already ;)
17:01:35 <OnuralpSezer[m]> -1 FB
17:02:00 <Eighth_Doctor> I think it probably makes sense to look to change our default base resolution, but I don't even know how that would be done
17:02:18 <adamw> proposed #agreed 2060320 - RejectedBlocker (Final) - this is awkward, but it only affects fairly specific cases (KDE at lower resolutions) and is easy enough to workaround by resizing the window; we feel documenting that would be sufficient for release
17:02:24 <Eighth_Doctor> (I see a similar issue on Workstation and I just ignore it there)
17:02:34 <lruzicka2> adamw, how would that cope with OpenQA, is there a way to have the resolution increased?
17:02:49 <lruzicka2> Eighth_Doctor, with abrt?
17:02:57 <Eighth_Doctor> yes
17:03:15 <Eighth_Doctor> it's a general "lower resolution" problem
17:03:19 <lruzicka2> Eighth_Doctor, hmmm, in VM or some normal resolution?
17:03:32 <lruzicka2> ok, I see
17:03:34 <Eighth_Doctor> VM at 800x600 and 1024x768
17:03:39 <Eighth_Doctor> totally fine at normal resolutions
17:04:01 <bcotton> ack the proposal
17:04:05 <nielsenb> ack
17:04:17 <Eighth_Doctor> ack
17:04:17 <lruzicka2> ack
17:04:44 <geraldosimiao> ack
17:05:15 <geraldosimiao> adamw: 🤪 sorry
17:05:17 <adamw> #agreed 2060320 - RejectedBlocker (Final) - this is awkward, but it only affects fairly specific cases (KDE at lower resolutions) and is easy enough to workaround by resizing the window; we feel documenting that would be sufficient for release
17:05:38 <geraldosimiao> ack
17:06:16 <adamw> lruzicka2: openqa runs VMs differently from where the 'defaults' we're talking about would likely be changed. we could easily run openQA's tests at any resolution, really, it's just a couple of arguments to qemu.
17:06:29 <adamw> #topic (2063381) gnome-shell crash, clutter-actor.c:1275:clutter_actor_set_mapped: assertion failed: (!CLUTTER_ACTOR_IS_MAPPED (self))
17:06:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2063381
17:06:36 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/658
17:06:39 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:06:48 <adamw> #info Ticket vote: BetaBlocker (+0,0,-1) (-catanzaro)
17:06:50 <lruzicka2> adamw, ok ... so then we will be fine, if we decide to change the defaults
17:06:51 <adamw> #info Ticket vote: FinalBlocker (+0,0,-2) (-catanzaro, -nielsenb)
17:07:30 <cmurf> i don't know why i hit this 3x in one hour right after upgrading to gnome42.rc
17:07:37 <cmurf> with reboots in between each
17:07:42 <nielsenb> Did you buy a lottery ticket?
17:07:55 <cmurf> but i couldn't deal with it so i downgraded
17:08:26 <cmurf> hence the idea of using the beta catch all, but if no one else is hitting it ...
17:08:40 <nielsenb> I haven't hit it
17:08:42 <lruzicka2> I just tried and did not hit it. :D
17:08:54 <lruzicka2> Have not hit it before either
17:08:56 <nielsenb> But I've only be using 42 seriously-ish for a few days now
17:09:06 <cmurf> i didn't hit it at all with gnome42 beta
17:09:08 <adamw> well, both the 'potential dupes' you linked do look like dupes to me
17:09:12 <nielsenb> I also own a black cat, so maybe I'm immune
17:09:18 <adamw> so that means lnie and pwhalen both hit it
17:09:24 <cmurf> oh right the dupes, so other people are hitting it
17:09:36 <adamw> i dunno if that makes it a blocker, but...does seem a bit worrying
17:09:39 <lruzicka2> nielsenb, I also have one. Geez, we are not fit for the job :D
17:09:59 <cmurf> well, we can punt to thursday go/no-go and see if more show up
17:10:18 <cmurf> and maybe i'll hear from Florian or someone about the stack trace i included
17:10:22 <adamw> this is one of those ones where i wish someone would just merge the fix so we don't have to make a decision. :D
17:10:26 <cmurf> pull in a narrow fix
17:10:34 <cmurf> oh there's a fix for this?
17:11:05 <adamw> a potential one, yeah
17:11:09 <adamw> https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2231
17:11:11 <nielsenb> Unfortunately clutter requires actual programming skill and domain knowledge, so I can't look at it
17:11:53 <cmurf> oh hey i just saw there's a mutter-42.0-1.fc36
17:11:57 <nielsenb> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2299
17:12:01 <nielsenb> isn't that the actual fix?
17:12:16 <cmurf> i had mutter-42~rc-4.fc36.x86_64 for this bug
17:12:39 <cmurf> looks like clutter hasn't changed
17:12:41 <nielsenb> 2231 looks like a related ui bug
17:13:05 <cmurf> ok i'm gonna go back to rc
17:13:14 <nielsenb> Take a chance, make a memory
17:13:16 <cmurf> and update mutter to the newest one in koji
17:14:12 <adamw> cmurf: neither of those PRs is merged
17:14:38 <cmurf> oh
17:14:48 <cmurf> also mutter-42.0-1.fc36 is not in bodhi
17:15:00 <adamw> i could do a build with that second one backported, though. does seem relevant indeed.
17:15:21 <cmurf> i'll run it
17:15:47 <nielsenb> Fixes a crash in the same general area anyway
17:15:52 <adamw> actually, looks like you may as well backport both, by the looks of https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3165#note_1402809
17:15:57 <cmurf> the thing i get worried about is if people hit this on the Live
17:16:02 <cmurf> like if it happens during an install
17:16:32 <adamw> so, uh, anyone have a clear vote on this? i'm a bit 'mmm'
17:16:52 <nielsenb> Reading the bug reports mostly make me realize how rarely I drag something
17:16:57 <nielsenb> Or use the app grid
17:17:05 <cmurf> i wish i knew the scope
17:17:08 <bcotton> +1 punt and hope upstream makes it moot? :-)
17:17:09 <geraldosimiao> +1 'mmm'
17:17:14 <cmurf> and even what triggers it because for me it seemed transient
17:17:25 <nielsenb> It looks to me like it could be racy
17:17:33 <cmurf> yeah i can get on board with +1 punt for now
17:17:33 <nielsenb> To my barely trained eye
17:17:44 <lruzicka2> +punt
17:17:49 <nielsenb> Yeah, I think I'm team punt
17:17:51 <nielsenb> +1 punt
17:18:04 <pwhalen> When testing the keyboard bug on the rpi4, this was a showstopped. Crashed and couldnt log in, reloaded the log in screen
17:18:16 <pwhalen> er, showstopper
17:18:22 <nielsenb> Did it do it every time?
17:18:26 <pwhalen> yes.
17:18:29 <nielsenb> Ugh
17:18:30 <pwhalen> I have not tested since.
17:18:39 <pwhalen> Has anyone else tested on aarch64?
17:18:49 <adamw> i'm either punt or +1
17:18:50 <cmurf> ok that's bad
17:19:03 <geraldosimiao> +1 punt
17:19:03 <nielsenb> I don't have any gnome4 capable aarch64 hardware
17:19:04 <cmurf> workstation aarch64 is release blocking
17:19:12 <pwhalen> The bug happened as soon as I hovered over my name
17:19:53 <cmurf> that's a lot more reproducible than what i'm running into, i wonder if it's the same bug just different manifestation
17:19:57 <cmurf> or yeah, some kind of race
17:20:01 <nielsenb> Which would cause the enter / leave / reentry type events that these MRs are improving the behavior of, so I would say that's almost certainly the same bug
17:20:04 <cmurf> that just doesn't happen on arm
17:20:19 <nielsenb> Or at least a related bug
17:20:38 <cmurf> i'm at least +1 beta FE now
17:20:48 <adamw> oh, yeah, we should give it a beta FE too
17:20:48 <nielsenb> Me too I think
17:20:53 <cmurf> very close to just saying, dang it, +1 beta blocker
17:20:57 <nielsenb> And I think I'm at final blocker too
17:21:20 <nielsenb> If it's still every time on aarch64, I'm +1 beta blocker too
17:21:27 <nielsenb> But unfortunately we don't know that right at this moment
17:21:33 <cmurf> that pwhalen hit it reliably on aarch64 makes me think it should be +1 beta blocker on the basis of this being bad for testing/testers
17:21:33 <nielsenb> Though I'm close to just assuming
17:21:52 <nielsenb> And on the basis you can't log in on a release blocking platform
17:22:01 <cmurf> fair point
17:22:15 <cmurf> showstopper like that is the hallmark of a beta blocker
17:23:00 <adamw> it'd be good to get at least one other person to test on aarch64 if possible
17:23:13 <adamw> i can try and get my jetson nano working for once and do it, but probably not during the meeting...
17:23:24 <adamw> i think i'm gonna say +1 beta fe / +1 final blocker for now
17:23:27 <pwhalen> I think my bug was with rc1, I have not tested rc4 which is on beta
17:23:27 <adamw> we can always revote later
17:23:40 <cmurf> ok so let's punt
17:23:43 <cmurf> do more testing
17:23:46 <nielsenb> +1 BetaFE
17:23:49 <nielsenb> +1 FinalBlocker
17:23:53 <Southern_Gentlem> +1 BFE +1 fb
17:23:57 <cmurf> +1 Beta FE though
17:24:14 <lruzicka2> +1 Beta, +1 fb
17:25:39 <cmurf> i take it this is not showing up in openqa with workstation aarch64 though?
17:25:41 <Southern_Gentlem> lruzicka2, BETA WHAT
17:25:52 <lruzicka2> Southern_Gentlem, FE
17:25:59 <adamw> proposed #agreed 2063381 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - we're not sure quite how common this is, but it's happened enough times to enough people to consider it a conditional violation of several criteria (e.g. the panel criterion) for now. we will backport the proposed fixes and do further testing to clarify the istuation
17:26:05 <nielsenb> ack
17:26:05 <lruzicka2> sck
17:26:09 <cmurf> ack
17:26:09 <lruzicka2> ack
17:26:16 <Southern_Gentlem> ack
17:26:17 <geraldosimiao> ack
17:26:19 <adamw> i'll fix the spelling of situation :D
17:26:30 <adamw> cmurf: no, but the way openqa moves the mouse is sort of different from how a human would.
17:26:38 <cmurf> gotcha
17:26:52 <nielsenb> It uses it's nose
17:27:12 <adamw> right
17:27:32 <adamw> #agreed 2063381 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - we're not sure quite how common this is, but it's happened enough times to enough people to consider it a conditional violation of several criteria (e.g. the panel criterion) for now. we will backport the proposed fixes and do further testing to clarify the situation
17:27:50 <adamw> #topic (2063156) Workstation Live is frozen in a VM with QXL video driver (Virtio works OK)
17:27:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2063156
17:27:57 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/656
17:28:00 <adamw> #info Proposed Blocker, mutter, NEW
17:28:03 <adamw> oh look, this one again
17:28:14 <adamw> so we didn't think it was a beta blocker, do we think it's a final blocker?
17:28:19 <nielsenb> History doesn't repeat, but it sure does rhyme
17:28:59 <cmurf> yeah i was +1 final blocker
17:30:27 <lruzicka2> am I wrong when I think we might fix this with updating F35 and f34 with the latest version?
17:30:34 <lruzicka2> this does not happen on F36
17:30:43 <adamw> well, that would make the default virtio
17:30:50 <adamw> but it wouldn't help VMs that are already created.
17:30:56 <adamw> also, not sure whether that's going to happen.
17:32:22 <nielsenb> I feel like this is a common bugs type situation
17:32:26 <lruzicka2> I am not sure if I want to block on this as there are lots of changes that require user interaction and we do not block on them
17:32:35 <adamw> i'm still kinda fence-y on this. might be nice if we had any idea what's going on.
17:32:36 <nielsenb> It's an unfortunately serious and annoying common bug
17:32:40 <lruzicka2> -1 FB and +1 common bugs
17:33:10 <adamw> i'd kinda like more testing and maybe feedback from developer...
17:33:25 <lruzicka2> and if we really wanted to block than we should have blocked Beta as this violates the Basic criteria
17:33:37 <lruzicka2> IMHO
17:34:14 <adamw> well, when it's a conditional violation, that becomes a judgement call
17:34:40 <adamw> we have quite a lot of precedent for that
17:35:29 <cmurf> +1 for a conditional final blocker
17:35:31 <lruzicka2> ok ... anyway this goes away with one mouse click in the settings :D
17:37:09 <adamw> so far we have -1/+1
17:37:11 <adamw> conclusion:
17:37:16 <lruzicka2> punt
17:37:21 <lruzicka2> :D:D
17:37:59 <adamw> proposed #agreed 2063381 - punt (delay decision) - we were not able to reach a clear decision at this time and with the information currently available. we'll aim to have more folks test and hopefully get feedback from the developers on what may be going on here
17:38:13 <nielsenb> ack
17:38:34 <lruzicka2> ack
17:38:34 <geraldosimiao> ack
17:38:44 <bcotton> ack
17:39:28 <adamw> #agreed 2063381 - punt (delay decision) - we were not able to reach a clear decision at this time and with the information currently available. we'll aim to have more folks test and hopefully get feedback from the developers on what may be going on here
17:39:36 <adamw> #topic (2010595) Cannot install firmware if secureboot is enabled
17:39:39 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2010595
17:39:42 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/635
17:39:45 <adamw> #info Proposed Blocker, shim, NEW
17:39:48 <adamw> #info Ticket vote: FinalBlocker (+0,0,-1) (-nielsenb)
17:40:11 <adamw> ok, so with the info that regular updates do install normally in this scenario, i'm -1 final blocker. this just doesn't violate criteria for me.
17:40:32 <nielsenb> I hate it, but it seems to be Lenovo only, so I'm okay with waving it through
17:41:19 <bcotton> -1 FB. it seems to be vendor-specific and i still have nightmares about shim blockers ;-)
17:41:59 <nielsenb> Also, reading these bug reports, I did not realize how complicated 'shim' actually is
17:42:06 <nielsenb> Feels more like a 'glue' layer
17:42:09 <lruzicka2> -1 FB, but Lenovo guys should be notified to fix it, I guess, to make sure they do not ship problematic versions
17:42:37 <lruzicka2> on the Fedora based machines
17:46:30 <adamw> proposed #agreed 2010595 - RejectedBlocker (Final) - this is a sad bug for affected owners, but firmware update functionality is not covered in the release criteria, and nothing that is covered in the criteria is broken by this bug
17:47:16 <nielsenb> ack
17:48:00 <bcotton> ack
17:48:26 <geraldosimiao> ack
17:48:42 <lruzicka2> ack
17:49:01 <adamw> #agreed 2010595 - RejectedBlocker (Final) - this is a sad bug for affected owners, but firmware update functionality is not covered in the release criteria, and nothing that is covered in the criteria is broken by this bug
17:49:10 <adamw> #topic (2063673) crash happens on the newly installed system
17:49:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2063673
17:49:15 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/662
17:49:19 <adamw> #info Proposed Blocker, xdg-desktop-portal, NEW
17:50:32 <nielsenb> Does the crash appear in the journal, or...?
17:51:59 <adamw> hum, i wonder if this is the same crash lili hit in https://bugzilla.redhat.com/show_bug.cgi?id=2054594
17:52:03 <nielsenb> Not sure if it matters, if it's happening to everyone, every time, I guess it's a blocker.
17:52:23 <geraldosimiao> this seems so familiar. didn't it have another ticket resolved that?
17:53:28 <adamw> geraldosimiao: the one i linked, i think.
17:53:42 <adamw> nielsenb: i don't think openqa is hitting this
17:54:29 <adamw> at least, we're not getting a crash notification on the desktop after install
17:54:32 <geraldosimiao> adamw: yesss sorry, didn't see it was the same
17:54:32 <adamw> which is the criterion
17:55:12 <nielsenb> I haven't tried the named compose yet, so I can't say if I hit it
17:55:13 <adamw> i'm either -1 or punt, i guess
17:55:29 <nielsenb> So far I'm -1 until other reports come pouring in
17:55:58 <lruzicka2> I haven't seen this on today's compose
17:56:09 <lruzicka2> yesterday's to be exact
17:56:10 <nielsenb> -1 FinalBlocker
17:57:01 <adamw> proposed #agreed 2063673 - RejectedBlocker (Final) - as described this doesn't seem to violate the criterion (there has to be a graphical notification of the crash for that), plus others do not seem to be able to reproduce it
17:57:10 <nielsenb> ack
17:57:33 <bcotton> ack
17:57:54 <lruzicka2> ack
17:58:53 <adamw> #agreed 2063673 - RejectedBlocker (Final) - as described this doesn't seem to violate the criterion (there has to be a graphical notification of the crash for that), plus others do not seem to be able to reproduce it
17:59:06 <adamw> alrighty, that's all the proposals
17:59:09 <adamw> unless anyone did a new one
17:59:19 <coremodule> yes
17:59:21 <coremodule> I am
17:59:28 <adamw> .fire coremodule
17:59:30 <zodbot> adamw fires coremodule
17:59:31 <coremodule> It's almost written
17:59:34 <coremodule> hang on
17:59:34 <adamw> okay, so no new proposals!
17:59:37 <adamw> :D
17:59:40 <lruzicka2> which one?
17:59:43 <coremodule> Firefox on aarch64 workstation doesn't launch
17:59:44 <coremodule> hang on
18:00:03 <lruzicka2> coremodule, Beta or Final?
18:00:41 <nielsenb> Oh, just the default browser? No big deal
18:00:55 <nielsenb> Don't think this internet fad is going to catch on anyway
18:01:16 <adamw> telnet ought to be good enough for anybody
18:01:21 <adamw> worked fine on openqa....https://openqa.fedoraproject.org/tests/1173946
18:02:52 <lruzicka2> +1 to make telnet the default
18:05:29 <coremodule> Okay, here you go
18:05:30 <coremodule> https://bugzilla.redhat.com/show_bug.cgi?id=2063961
18:06:12 <nielsenb> Ew
18:06:14 <pwhalen> seeing the same as coremodule on the jetson nano
18:06:16 <nielsenb> That feels like a blocker
18:06:30 <cmurf> oh my
18:07:14 <nielsenb> +1 FinalBlocker
18:07:34 <adamw> just a sec
18:07:35 <geraldosimiao> +1 FinalBlocker
18:07:35 <lruzicka2> +1 Blockero de Finalo
18:07:35 <adamw> stop voting
18:07:37 <adamw> we need a topic
18:07:46 <adamw> right now all of this looks like it's under the last bug
18:07:49 <geraldosimiao> 😁😁
18:08:08 <nielsenb> Make that one a blocker too than, it should have gotten out of the way if it didn't want to be promoted
18:08:25 <adamw> #topic (2063961) Fedora ARM - Firefox fails to open on aarch64 Workstation
18:08:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2063961
18:08:39 <cmurf> we need a working web browser on beta, that's a basic criterion
18:08:41 <adamw> #info Proposed Blocker, firefox, NEW
18:08:47 <adamw> okay, vote away
18:09:01 <nielsenb> +1 FinalBlocker
18:09:02 <geraldosimiao> +1 FinalBlocker
18:09:02 <lruzicka2> +1 bloqueador final
18:09:03 <copperi[m]> +1 Final
18:09:05 <cmurf> It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments.
18:09:15 <cmurf> https://fedoraproject.org/wiki/Basic_Release_Criteria#Required_applications
18:09:22 <cmurf> +1 beta blocker
18:09:30 <adamw> oh yes,
18:09:38 <adamw> this did actually fail on openqa too for the candidate
18:09:41 <adamw> it's passing on the nightlies
18:09:52 <lruzicka2> +1 bloqueador beta
18:09:59 <nielsenb> +1 BetaBlocker
18:10:00 <pwhalen> +1 beta blocker
18:10:08 <coremodule> +1 beta blocker
18:10:09 <lruzicka2> en ese caso
18:10:09 <bcotton> +1 beta blocker. :-(
18:10:10 <adamw> we pulled in firefox 98 for the candidate
18:10:14 <adamw> so this likely broke between 96 and 98
18:11:11 <geraldosimiao> ok, +1 beta blocker
18:11:16 <geraldosimiao> seems fair
18:11:17 <pwhalen> yes, previous nightlies worked OK
18:11:47 <adamw> proposed #agreed 2063961 - AcceptedBlocker (Beta) - accepted as a violation of Basic criterion "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments" on aarch64. Note this bug is introduced by Firefox 98 which is not yet stable, but including 98 is *itself* a blocker
18:12:05 <nielsenb> ack
18:12:06 <cmurf> ack
18:12:07 <coremodule> ack
18:12:20 <pwhalen> ack
18:12:39 <cmurf> how many other firefox 98's are there?
18:12:39 <geraldosimiao> ack
18:12:55 <cmurf> for that matter is there a firefox 97 that works on x86 and aarch64?
18:13:28 <cmurf> looks like 98.0-1 and 98.0-2
18:13:30 <adamw> we need 98 for security fixes anyway
18:13:37 <adamw> #agreed 2063961 - AcceptedBlocker (Beta) - accepted as a violation of Basic criterion "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments" on aarch64. Note this bug is introduced by Firefox 98 which is not yet stable, but including 98 is itself a blocker
18:13:59 <cmurf> oh wait 98.0-1 didn't build nevermind
18:14:20 <cmurf> i think the security fixes are a final criterion though
18:14:53 <cmurf> i'm just grasping for any version of firefox other than 96 that works on both archs
18:17:15 <lruzicka2> I have 98-0-2 already in my system, works ok on x86_64
18:19:19 <adamw> sure, it's aarch64 that's the issue
18:19:30 <adamw> okay, anyhow, moving on...
18:19:33 <adamw> #topic Accepted Beta blockers
18:20:03 <adamw> #info 2016613 - PR is ready upstream, I will backport it after this meeting
18:20:32 <adamw> #info 2057193 - we have a Firefox 98 build and included it in Beta-1.1, but as per above it does not work on aarch64, so we'll need to fix that
18:21:39 <adamw> #info 2017043 - fix was included in GNOME 42-rc megaupdate which is on its way stable, would be good if someone can verify it
18:21:44 <adamw> okay, those are the 'easy' ones
18:21:50 <adamw> #topic (2018271) fedora-release-identity-cloud says "Cloud Edition", Cloud has not been an edition for years
18:21:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2018271
18:21:57 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/578
18:22:01 <adamw> #info Accepted Blocker, fedora-release, ASSIGNED
18:22:08 <adamw> so on this one, we have a bit of a procedural issue
18:22:44 <adamw> the council voted to waive it: https://pagure.io/Fedora-Council/tickets/issue/389#comment-785482
18:23:05 <adamw> however, it appears to me that council doesn't actually have any formal power to do that written down anywhere I can find.
18:23:21 <adamw> I pointed this out, and we decided the best way forward would be to give council that power in this case
18:23:28 <lruzicka2> adamw, why is it a problem to change it?
18:23:46 <lruzicka2> so that it includes the correct name
18:23:48 <lruzicka2> ?
18:23:53 <adamw> so ben proposed a criteria amendment: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/EFTMMXJYAZOW5CHBCON6UHWCUYWF34OY/
18:24:05 <adamw> lruzicka2: see i would've just done that, but people seem to not want to.
18:24:42 <adamw> anyhow, it seems reasonable to me to let council have this power in the specific case of the 'edition' requirement, since that's a branding thing that is council's responsibility
18:24:53 <lruzicka2> sure
18:25:00 <adamw> but we should probably decide on the proposal quite rapidly so we can do something about the bug by thursday. so i'm bringing it up here in case anyone objects to the notion
18:25:17 <lruzicka2> +1 waive it
18:25:33 <copperi[m]> +1 waive
18:25:34 <coremodule> no objection
18:25:40 <adamw> #info a proposal has been made to amend the criteria to allow council to waive the 'edition' requirement (as council is responsible for branding), which will be applied and used by thursday if there are no substantial objections
18:25:45 <adamw> so object now or forever hold your peace ;)
18:26:25 <bcotton> if only all of my proposals flew through with such ease
18:26:42 <nielsenb> More bribes, more ease :D
18:26:56 <copperi[m]> 👍️
18:27:13 <geraldosimiao> ack
18:27:19 <geraldosimiao> :D
18:28:05 <adamw> #info for the record, nobody opposed the proposal at this meeting
18:28:28 <adamw> #info the current plan to handle this bug is for the proposal to be applied and the bug waived as a blocker by council vote
18:28:44 <nielsenb> Sounds good to me
18:29:30 <adamw> alrighty
18:29:33 <adamw> #topic Open floor
18:29:39 <adamw> so, any other f36/blocker-related business?
18:31:04 <geraldosimiao> it seems this here have returned to F36
18:31:06 <geraldosimiao> https://pagure.io/fedora-qa/blocker-review/issue/505
18:31:25 <geraldosimiao> I'll open a ticket for it
18:31:32 <adamw> ah, yeah, we should reopen the existing bug or file a new one
18:31:42 <adamw> and probably propose as a final blocker/beta fe
18:31:52 <geraldosimiao> I think its FB stuff
18:33:38 <adamw> thanks for flagging it up
18:36:48 <adamw> alrighty, looks like we're done
18:37:18 <geraldosimiao> ok, goodbye friends :)
18:37:22 <nielsenb> Bye!
18:39:30 <lruzicka2> seeyou
18:39:57 <adamw> thanks for coming everyone!
18:40:20 <adamw> #endmeeting