<@adamwill:fedora.im>
16:01:01
!startmeeting F44-blocker-review
<@meetbot:fedora.im>
16:01:01
Meeting started at 2026-03-09 16:01:01 UTC
<@meetbot:fedora.im>
16:01:01
The Meeting name is 'F44-blocker-review'
<@adamwill:fedora.im>
16:01:04
!topic Roll Call
<@kparal:matrix.org>
16:01:25
!hi
<@zodbot:fedora.im>
16:01:29
Kamil Páral (kparal) - he / him / his
<@jgroman:fedora.im>
16:01:33
!hi
<@zodbot:fedora.im>
16:01:33
Jaroslav Groman (jgroman)
<@kashyapc:fedora.im>
16:01:37
!hi
<@zodbot:fedora.im>
16:01:38
Kashyap Chamarthy (kashyapc)
<@kparal:matrix.org>
16:01:42
let's see if we still suffer from matrix delays today
<@derekenz:fedora.im>
16:01:49
!hi
<@zodbot:fedora.im>
16:01:51
Derek Enz (derekenz)
<@jlinton:fedora.im>
16:02:13
!hi
<@zodbot:fedora.im>
16:02:14
Jeremy Linton (jlinton)
<@lruzicka:fedora.im>
16:02:21
!hi
<@zodbot:fedora.im>
16:02:22
Lukáš Růžička (lruzicka)
<@lruzicka:fedora.im>
16:02:51
I would like to apologize, I need to leave in 20 minutes. Must be somewhere.
<@decathorpe:fedora.im>
16:02:53
!hi
<@zodbot:fedora.im>
16:02:54
Fabio Valentini (decathorpe) - he / him / his
<@adamwill:fedora.im>
16:03:15
no problem lukas
<@dustymabe:matrix.org>
16:03:32
!hi
<@zodbot:fedora.im>
16:03:38
Dusty Mabe (dustymabe) - he / him / his
<@conan_kudo:matrix.org>
16:03:38
!hi
<@zodbot:fedora.im>
16:03:45
Neal Gompa (ngompa) - he / him / his
<@adamwill:fedora.im>
16:05:16
alrighty, let's get rolling
<@adamwill:fedora.im>
16:05:23
it's everyone's favorite time: boilerplate time!
<@adamwill:fedora.im>
16:05:31
Why are we here?
<@adamwill:fedora.im>
16:05:31
!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.
<@adamwill:fedora.im>
16:05:31
!info We'll be following the process outlined at:
<@adamwill:fedora.im>
16:05:31
!link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
<@adamwill:fedora.im>
16:05:31
!info The criteria for release blocking bugs can be found at:
<@adamwill:fedora.im>
16:05:31
!link http://qa.fedoraproject.org/blockerbugs/current
<@adamwill:fedora.im>
16:05:31
!info The bugs up for review today are available at:
<@adamwill:fedora.im>
16:05:31
!topic Introduction
<@adamwill:fedora.im>
16:05:31
!link https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria
<@adamwill:fedora.im>
16:05:31
!link https://fedoraproject.org/wiki/Fedora_44_Beta_Release_Criteria
<@adamwill:fedora.im>
16:05:31
!link https://fedoraproject.org/wiki/Basic_Release_Criteria
<@adamwill:fedora.im>
16:05:44
!info for Final, we have:
<@adamwill:fedora.im>
16:05:49
!info 7 Proposed Blockers
<@adamwill:fedora.im>
16:05:49
!info 3 Accepted Blockers
<@adamwill:fedora.im>
16:05:52
!info 1 Proposed Freeze Exceptions
<@adamwill:fedora.im>
16:05:55
who wants to secretarialize?
<@kparal:matrix.org>
16:07:13
I can
<@adamwill:fedora.im>
16:07:18
thanks
<@adamwill:fedora.im>
16:07:25
!info Kamil Páral will secretarialize
<@kparal:matrix.org>
16:07:30
it doesn't mean I want to!
<@kparal:matrix.org>
16:07:39
well, too late I guess...
<@adamwill:fedora.im>
16:07:40
too bad, it's written down now
<@adamwill:fedora.im>
16:07:49
let's get started with:
<@adamwill:fedora.im>
16:07:55
!topic Proposed Final blockers
<@adamwill:fedora.im>
16:08:05
!link https://bugzilla.redhat.com/show_bug.cgi?id=2443774
<@adamwill:fedora.im>
16:08:05
!topic (2443774) dnf cli segmentation faults during transaction when locale is set to C or POSIX
<@adamwill:fedora.im>
16:08:05
!info Ticket vote: FinalBlocker (+2,0,-1) (+nielsenb, +derekenz, -kparal)
<@adamwill:fedora.im>
16:08:05
!info Proposed Blocker, dnf5, POST
<@adamwill:fedora.im>
16:08:05
!link https://pagure.io/fedora-qa/blocker-review/issue/2064
<@adamwill:fedora.im>
16:08:39
i'm -1 if it doesn't happen in a default toolbox
<@boniboyblue:fedora.im>
16:09:06
!hi
<@zodbot:fedora.im>
16:09:07
Christopher Boni (boniboyblue)
<@kparal:matrix.org>
16:09:23
it might be related to what env you have when switching to the toolbox, it might inherit the host env vars?
<@kparal:matrix.org>
16:09:34
on my workstation, it doesn't crash in toolbox
<@derekenz:fedora.im>
16:09:40
Seems to work according to Kamil or no?
<@kparal:matrix.org>
16:09:57
since I have en_US.UTF-8 locale
<@adamwill:fedora.im>
16:10:41
well, the bug as reported isn't specific to containers anyway, just 'more likely' to happen in a container as the locale is more likely to be C
<@adamwill:fedora.im>
16:10:53
well, the bug as reported isn't specific to containers anyway, just 'more likely' to happen in a container as the locale is more likely to be POSIX
<@kparal:matrix.org>
16:11:17
so I think it's safe to say this probably won't crash for most toolbox users on default Fedora installs (because even Server installs have some locale defined, I assume)
<@derekenz:fedora.im>
16:11:53
Ok FinalBlocker 0
<@adamwill:fedora.im>
16:13:48
any other votes? we're sorta at an impasse now
<@adamwill:fedora.im>
16:13:58
it's at +1 / -2
<@kparal:matrix.org>
16:14:33
do we have Brandon Nielsen?
<@osama-albahrani:matrix.org>
16:14:34
!hi
<@zodbot:fedora.im>
16:14:35
Osama Albahrani (osalbahr)
<@osama-albahrani:matrix.org>
16:15:03
-1
<@lruzicka:fedora.im>
16:15:17
-1
<@aggraxis:fedora.im>
16:16:22
!hi
<@zodbot:fedora.im>
16:16:24
Paul Maconi (aggraxis) - he / him / his
<@adamwill:fedora.im>
16:16:35
proposed !agreed 2443774 - RejectedBlocker (Final) - this is potentially a blocker per various criteria related to package installation, but we agreed we can't think of or demonstrate any common or criteria-covered situation where the system locale is likely to be C or POSIX
<@derekenz:fedora.im>
16:16:43
ack
<@jgroman:fedora.im>
16:16:54
ack
<@kparal:matrix.org>
16:17:08
ack
<@aggraxis:fedora.im>
16:17:25
ack
<@adamwill:fedora.im>
16:17:37
!agreed 2443774 - RejectedBlocker (Final) - this is potentially a blocker per various criteria related to package installation, but we agreed we can't think of or demonstrate any common or criteria-covered situation where the system locale is likely to be C or POSIX
<@osama-albahrani:matrix.org>
16:17:38
ack
<@adamwill:fedora.im>
16:17:52
!link https://pagure.io/fedora-qa/blocker-review/issue/2071
<@adamwill:fedora.im>
16:17:52
!info Proposed Blocker, gnome-remote-desktop, NEW
<@adamwill:fedora.im>
16:17:52
!info Ticket vote: FinalBlocker (+0,0,-1) (-nielsenb)
<@adamwill:fedora.im>
16:17:52
!topic (2444824) GNOME Remote Desktop (RDP remote login) connects but shows a blank white screen and disconnects shortly afterwards (Fedora 44).
<@adamwill:fedora.im>
16:17:52
!link https://bugzilla.redhat.com/show_bug.cgi?id=2444824
<@adamwill:fedora.im>
16:18:04
Lukáš Růžička did you find time to test this with the other client yet?
<@adamwill:fedora.im>
16:18:06
i didn't :/
<@lruzicka:fedora.im>
16:18:29
Yeah, I tested it.
<@lruzicka:fedora.im>
16:19:05
Although sometimes not on the first try, I could eventually connect to RC 1.2 and fully updated 44 with xfreerdp
<@lruzicka:fedora.im>
16:19:38
And when I connected with xfreerdp, I could also use Connections and connected just fine. So I'd say it kinda works.
<@adamwill:fedora.im>
16:19:42
what happened on the first try?
<@lruzicka:fedora.im>
16:20:08
With xfreerdp? Got a black screen. After a restart of the server, it connected.
<@lruzicka:fedora.im>
16:20:24
I restarted the server after I have set up RDP as advised.
<@lruzicka:fedora.im>
16:20:33
So it needed to be restarted twice.
<@adamwill:fedora.im>
16:21:00
that sounds sort of like a failure, to me...i mean, openqa works *sometimes*, so it's the same, no?
<@adamwill:fedora.im>
16:21:04
sometimes it works, sometimes it doesn't...
<@kparal:matrix.org>
16:21:21
That's quite a poor UX, when you depend on server working but need to restart it in order to make it work...
<@lruzicka:fedora.im>
16:21:28
Yeah, but it is difficult to tell why
<@adamwill:fedora.im>
16:21:36
that doesn't feel like our job :P
<@adamwill:fedora.im>
16:21:44
(yes i know i am the worst at following this rule)
<@kparal:matrix.org>
16:22:23
Anyone, what's the criterion here? This is no longer covered by this: https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#Default_application_functionality
<@kparal:matrix.org>
16:22:27
Anyway, what's the criterion here? This is no longer covered by this: https://fedoraproject.org/wiki/Fedora\_44\_Final\_Release\_Criteria#Default\_application\_functionality
<@kparal:matrix.org>
16:22:39
unless you expect it to be basic functionality of Settings
<@adamwill:fedora.im>
16:22:52
have we seen any failures of the installer RDP test?
<@adamwill:fedora.im>
16:23:08
i think we noted we added this test at the request of desktop team as they want to know whether it works
<@adamwill:fedora.im>
16:23:11
rather than it being for the criteria
<@derekenz:fedora.im>
16:23:24
This was my thought
<@adamwill:fedora.im>
16:23:32
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/333
<@kparal:matrix.org>
16:23:34
It doesn't feel like a basic functionality of Settings to me. If we want remote desktop to work, I would expect us to have a stadalone criterion for it, citing blocking clients etc
<@adamwill:fedora.im>
16:24:20
huh. it happened *today* to install_rdp_client on aarch64 - https://openqa.fedoraproject.org/tests/4403945
<@adamwill:fedora.im>
16:24:30
hadn't happened before that, on 44 compoes
<@adamwill:fedora.im>
16:24:33
hadn't happened before that, on 44 composes
<@adamwill:fedora.im>
16:24:48
and happened on 0307.n.0 on x86_64 - https://openqa.fedoraproject.org/tests/4398111
<@adamwill:fedora.im>
16:24:52
again, hadn't happened before
<@conan_kudo:matrix.org>
16:25:19
yeah, tbh, I'd like to have a criterion for krdp/krfb and grd
<@conan_kudo:matrix.org>
16:25:30
yeah, tbh, I'd like to have a criterion for krdp/krfb and grd to krdc and gnome-connections
<@adamwill:fedora.im>
16:25:31
on rawhide it's happened intermittently since Fedora-Rawhide-20260220.n.0
<@conan_kudo:matrix.org>
16:25:37
but that's not for this cycle
<@adamwill:fedora.im>
16:26:31
so, huh, this seems like a conundrum...
<@kparal:matrix.org>
16:26:40
Conan Kudo: I think it's reasonable. Proposals welcome.
<@adamwill:fedora.im>
16:26:46
why has it been happening to the remote_desktop test for longer, then started happening to anaconda more recently?
<@kparal:matrix.org>
16:27:09
so in anaconda case, we could block on it, right?
<@adamwill:fedora.im>
16:27:13
yes
<@kparal:matrix.org>
16:27:23
https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#Installation_interfaces
<@kparal:matrix.org>
16:27:58
maybe we should create a specific bug for anaconda. Because it might not be the same issue.
<@kparal:matrix.org>
16:28:08
and just block on that one
<@kparal:matrix.org>
16:28:15
also it depends how often it happens
<@lruzicka:fedora.im>
16:28:38
If it does happen on Ana Conda (one of the highest peaks), I support the blocking status. Unfortunately, I need to go now. Sorry. Have a nice time.
<@kparal:matrix.org>
16:28:58
so which link is the anaconda failure? I can't find it
<@adamwill:fedora.im>
16:31:08
i just posted https://bugzilla.redhat.com/show_bug.cgi?id=2444824#c2
<@adamwill:fedora.im>
16:31:27
maybe we should just punt this for a bit more investigation?
<@kparal:matrix.org>
16:33:19
sounds good to me
<@derekenz:fedora.im>
16:33:25
Punt
<@conan_kudo:matrix.org>
16:33:42
yeah
<@adamwill:fedora.im>
16:34:03
proposed !agreed 2444824 - punt (delay decision) - we decided to delay the decision on this for more manual investigation into the various facets (different clients, GNOME case vs. installer case, getting more logs about what's going on when there's a failure)
<@derekenz:fedora.im>
16:34:23
ack
<@jgroman:fedora.im>
16:34:27
ack
<@conan_kudo:matrix.org>
16:34:42
ack
<@boniboyblue:fedora.im>
16:34:51
ack
<@kparal:matrix.org>
16:34:53
ack
<@adamwill:fedora.im>
16:35:33
!agreed 2444824 - punt (delay decision) - we decided to delay the decision on this for more manual investigation into the various facets (different clients, GNOME case vs. installer case, getting more logs about what's going on when there's a failure)
<@adamwill:fedora.im>
16:35:52
!info Ticket vote: FinalBlocker (+0,0,-1) (-nielsenb)
<@adamwill:fedora.im>
16:35:52
!link https://bugzilla.redhat.com/show_bug.cgi?id=2442689
<@adamwill:fedora.im>
16:35:52
!topic (2442689) [abrt] gnome-session: __syscall_cancel_arch(): gnome-session-service killed by SIGABRT
<@adamwill:fedora.im>
16:35:52
!link https://pagure.io/fedora-qa/blocker-review/issue/2056
<@adamwill:fedora.im>
16:35:52
!info Proposed Blocker, gnome-session, NEW
<@jlinton:fedora.im>
16:36:50
This is the same bug I complained about in F43.
<@kparal:matrix.org>
16:37:31
Jeremy Linton: can you find a link?
<@derekenz:fedora.im>
16:37:48
How intermittent is this?
<@kparal:matrix.org>
16:37:53
If this was happening frequently on F44, I think we'd see it easily in openqa. Unless it's hardware specific.
<@kparal:matrix.org>
16:38:17
I haven't seen it personally. Just the dbus delay sometimes.
<@jlinton:fedora.im>
16:38:35
https://bugzilla.redhat.com/show_bug.cgi?id=2402621
<@adamwill:fedora.im>
16:39:30
yeah, i don't think i've seen this in openqa. god knows there have been enough flakes lately, but i haven't seen this
<@kparal:matrix.org>
16:40:33
Jeremy, if I remember the one you linked, it didn't prevent initial setup from working, it was just a harmless coredump in the logs?
<@kparal:matrix.org>
16:41:03
in this case, it blocks g-i-s, Brandon says
<@kparal:matrix.org>
16:41:43
anyway, since it can't be reproduced easily, I'd say -1 for now, and repropose if it happens more often
<@adamwill:fedora.im>
16:42:21
there also isn't a full traceback, which makes debugging kinda impossible
<@jlinton:fedora.im>
16:42:45
Yah IIRC I tiaged it down enough to be convinced it wasn't aarch64 specific, and that yes, its largely just the session not being terminated cleanly. Harmless in that its exposing an underlying issue, but the user functionality isn't directly impacted as such...
<@kparal:matrix.org>
16:43:09
huh, why is the backtrace missing?
<@jlinton:fedora.im>
16:43:31
Probably could show up in other places IIRC but since you do eventually get to the desktop (it just takes longer) not a "end of the world" kind of thing.
<@conan_kudo:matrix.org>
16:44:05
this feels familiar indeed, because it was happening at least since F43
<@kparal:matrix.org>
16:44:18
I think I know why, it's comment 8 breaking abrt attachment uploads
<@kparal:matrix.org>
16:44:23
it already happened to me before
<@conan_kudo:matrix.org>
16:44:34
I wonder if it's related to the dynamic users change in G49
<@kparal:matrix.org>
16:44:42
I was complaining about it, workstation SIG have a ticket about it somewhere
<@conan_kudo:matrix.org>
16:44:43
I wonder if it's related to the dynamic user session change in G49
<@jlinton:fedora.im>
16:44:44
It happens a lot, its just with problem reporter not running correctly it doesn't show up in the users face.
<@kparal:matrix.org>
16:44:55
I complained about it, workstation SIG have a ticket about it somewhere
<@kparal:matrix.org>
16:45:38
well, my current opinion is -1 blocker
<@adamwill:fedora.im>
16:46:37
yeah, if we had a clear indication this was happening regularly in such a way as to actually break first boot experience that'd be something else, but afaics we don't?
<@adamwill:fedora.im>
16:46:39
-1 for now
<@derekenz:fedora.im>
16:46:50
FinalBlocker -1
<@aggraxis:fedora.im>
16:48:00
-1
<@osama-albahrani:matrix.org>
16:48:34
-1
<@adamwill:fedora.im>
16:49:25
proposed !agreed 2442689 - RejectedBlocker (Final) - this is a bit worrying, but for now it does not seem reproducible, openQA tests don't seem to be hitting it. We don't have any clear indication there's a regularly-encountered issue that breaks the first boot flow
<@derekenz:fedora.im>
16:49:33
ack
<@aggraxis:fedora.im>
16:49:45
ack
<@jgroman:fedora.im>
16:49:53
ack
<@conan_kudo:matrix.org>
16:50:03
ack
<@kparal:matrix.org>
16:50:13
ack
<@jlinton:fedora.im>
16:51:14
Yah IIRC, basically the session doesn't quit, it gets stuck in a pthread_cancel, and eventually systemd kills it, and that is the core file and then the machine continues executing. IIRC it was some race with a dbus notification. I did a bit of post debug release while flying back to the us and none of that ended up in the defect.
<@adamwill:fedora.im>
16:51:50
!agreed 2442689 - RejectedBlocker (Final) - this is a bit worrying, but for now it does not seem reproducible, openQA tests don't seem to be hitting it. We don't have any clear indication there's a regularly-encountered issue that breaks the first boot flow
<@adamwill:fedora.im>
16:52:00
if you can reconstruct whatever you figured out that'd be great, jeremy
<@adamwill:fedora.im>
16:52:02
is there an upstream bug?
<@jlinton:fedora.im>
16:52:49
Yah IIRC, basically the session doesn't quit, it gets stuck in a pthread\_cancel, and eventually systemd kills it, and that is the core file and then the machine continues executing. IIRC it was some race with a dbus notification. I did a bit of post release debug while flying back to the us and none of that ended up in the defect.
<@adamwill:fedora.im>
16:53:33
!link https://bugzilla.redhat.com/show_bug.cgi?id=2438442
<@adamwill:fedora.im>
16:53:33
!topic (2438442) Graphics broken unless Panel Self Refresh is disabled (with i915.enable_psr=0)
<@adamwill:fedora.im>
16:53:33
!info Proposed Blocker, kernel, NEW
<@adamwill:fedora.im>
16:53:33
!link https://pagure.io/fedora-qa/blocker-review/issue/2028
<@adamwill:fedora.im>
16:53:42
so, we rejected this as a beta blocker, how do we feel about final?
<@adamwill:fedora.im>
16:53:48
i still feel a bit meh. note there's an upstream patch to try, apparentkly
<@adamwill:fedora.im>
16:54:21
let's face it, there's probably never been a fedora release where *some* laptop or other didn't need a kernel arg to workaround *something*, seems a bit arbitrary to block on this one, but...i dunno.
<@adamwill:fedora.im>
16:54:33
jforbes around?
<@jforbes:fedora.im>
16:54:45
I am
<@kparal:matrix.org>
16:54:51
this is not only specific to a particular laptop, but also just to a particular screen, it seems
<@jforbes:fedora.im>
16:55:20
I expect to get a test build with the patch today or tomorrow
<@aggraxis:fedora.im>
16:55:27
I seem to remember needing to do this to get Fedora to work in the early days of having my Framework laptop.
<@adamwill:fedora.im>
16:55:28
i mean, on its face it's plausible it might affect other laptops of the same generation with 120Hz screens, but that's just speculation I guess (and I dunno if there are any?)
<@kparal:matrix.org>
16:55:37
I'm fine with not blocking on this, unless we get feedback after Beta release that this affects many more laptop models
<@aggraxis:fedora.im>
16:55:52
It's one of those things that keeps coming and going, but it's really an easy fix on the user side.
<@adamwill:fedora.im>
16:55:56
well, 'disable PSR' is one of those all-purpose workarounds which has been useful for various issues
<@jforbes:fedora.im>
16:55:59
Yeah, we unfortunately do not have any metrics on what hardware is actually out there and in use
<@kparal:matrix.org>
16:56:15
also, there is a workaround - switch to 60Hz. Not great, but not terrible either.
<@kparal:matrix.org>
16:59:52
so... any other opinions? I'm more leaning towards -1 blocker at this moment.
<@derekenz:fedora.im>
17:00:28
Yeah it seems to be a P14 thing
<@adamwill:fedora.im>
17:00:30
we can punt and hope it goes away with the patch, but i can't really think of a plausible justification for punting. :D
<@adamwill:fedora.im>
17:00:34
i'm a "-1 for now", i guess
<@adamwill:fedora.im>
17:00:44
open to a revote if evidence indicates more affected hardware
<@derekenz:fedora.im>
17:00:54
-1
<@conan_kudo:matrix.org>
17:01:33
I'm waffly on it
<@conan_kudo:matrix.org>
17:01:38
kind of 0 to +1
<@adamwill:fedora.im>
17:02:03
so we're at...-2.8 / + 0.284 ? :D
<@adamwill:fedora.im>
17:02:19
any other votes?
<@jgroman:fedora.im>
17:02:35
-1
<@adamwill:fedora.im>
17:03:10
alrighty, that tips the Highly Complex, Increasingly Self-Aware Voting Algorithm over the edge
<@adamwill:fedora.im>
17:04:33
proposed !agreed 2438442 - RejectedBlocker (Final) - this is rejected per https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues? , because so far we still have no indication this affects more than a single laptop model, and blocking the release for a workaroundable issue on a single laptop model isn't really in line with past reality. Note "Bugs that affect only a single adapter or small group of closely-related adapters are almost never taken as blockers" in the FAQ.
<@osama-albahrani:matrix.org>
17:04:51
ack
<@derekenz:fedora.im>
17:04:52
ack
<@jgroman:fedora.im>
17:05:06
ack
<@kparal:matrix.org>
17:05:09
ack
<@adamwill:fedora.im>
17:05:28
!agreed 2438442 - RejectedBlocker (Final) - this is rejected per https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues? , because so far we still have no indication this affects more than a single laptop model, and blocking the release for a workaroundable issue on a single laptop model isn't really in line with past reality. Note "Bugs that affect only a single adapter or small group of closely-related adapters are almost never taken as blockers" in the FAQ.
<@adamwill:fedora.im>
17:05:42
!link https://bugzilla.redhat.com/show_bug.cgi?id=2441941
<@adamwill:fedora.im>
17:05:42
!link https://pagure.io/fedora-qa/blocker-review/issue/2047
<@adamwill:fedora.im>
17:05:42
!topic (2441941) Graphics break when trying to type LUKS password
<@adamwill:fedora.im>
17:05:42
!info Proposed Blocker, kernel, NEW
<@jforbes:fedora.im>
17:06:31
I haven't seen much more on that one (it was 4 kernels ago) and I haven't seen a lot of reports from other users either
<@kparal:matrix.org>
17:07:06
this is similar. With even less users complaining about this. But the workaround is less friendly (must have a usb-c display plugged in).
<@conan_kudo:matrix.org>
17:07:29
:(
<@kparal:matrix.org>
17:08:15
Funny is that Jiri (this bug) and Tomas (the previous bug) sit next to each other. There must be haunted burial grounds directly underneath them, or something.
<@conan_kudo:matrix.org>
17:08:47
I wouldn't put it out of the realm of reality :)
<@adamwill:fedora.im>
17:08:48
can we relocate them and hire a priest to sprinkle some holy water?
<@kparal:matrix.org>
17:09:32
on those laptops, preferably
<@adamwill:fedora.im>
17:10:17
in this case I blame jiri for having the poor taste to buy an xps 13 plus
<@kparal:matrix.org>
17:10:24
blocker -1, at this point
<@adamwill:fedora.im>
17:10:41
yeah, i feel bad about it, but -1 unless we find at least somebody else affected
<@adamwill:fedora.im>
17:10:56
it'll be interesting to see forum feedback once beta comes out i guess
<@jforbes:fedora.im>
17:11:39
Well, as I said, it was several kernels ago, might not be happening anymore anyway. There are a solid 2k patches between what this was reported on and what is current
<@adamwill:fedora.im>
17:11:50
we can ask him to check again
<@adamwill:fedora.im>
17:11:54
kparal can do it in person :P
<@adamwill:fedora.im>
17:12:23
and after all, we all know patches always make everything better
<@jlinton:fedora.im>
17:12:43
This kind of stuff hits my P1 with nvidia on/off too, random kernel/monitor setting that keeps the password prompt from working. So I have a handful of blacklist/etc commands I toss in for a kernel release or two.
<@jlinton:fedora.im>
17:13:11
So, I will take some of that holy water.
<@adamwill:fedora.im>
17:13:12
other votes?
<@jforbes:fedora.im>
17:14:11
Beta the 2 kernels since beta were both huge, one was 780 patches, the other was 850, so beta kernel experiences are likely very different from reality at this point
<@jforbes:fedora.im>
17:15:06
adamw: They do make everything different though... Shifting things around so that some users get fixed, new users get broken, and everyone gets a turn :)
<@osama-albahrani:matrix.org>
17:15:16
-1
<@adamwill:fedora.im>
17:16:19
proposed !agreed - 2441941 - RejectedBlocker (Final) - similar to the previous bug, this is rejected per https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues? as we have no indication at this point that it affects more than a single laptop
<@derekenz:fedora.im>
17:16:19
-1
<@derekenz:fedora.im>
17:16:33
ack
<@jgroman:fedora.im>
17:16:38
ack
<@kparal:matrix.org>
17:16:55
ack
<@adamwill:fedora.im>
17:17:03
!agreed - 2441941 - RejectedBlocker (Final) - similar to the previous bug, this is rejected per https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues? as we have no indication at this point that it affects more than a single laptop
<@adamwill:fedora.im>
17:17:11
!info Proposed Blocker, kernel, NEW
<@adamwill:fedora.im>
17:17:11
!link https://pagure.io/fedora-qa/blocker-review/issue/2072
<@adamwill:fedora.im>
17:17:11
!link https://bugzilla.redhat.com/show_bug.cgi?id=2443049
<@adamwill:fedora.im>
17:17:11
!topic (2443049) Kernel 6.19.3 is unbootable - IO_PAGE_FAULT
<@adamwill:fedora.im>
17:17:17
good lord, that priest is gonna be busy
<@xariann:fedora.im>
17:17:32
So I filed that one, and there is more than just me with that bug: https://discuss.cachyos.org/t/boot-freeze-hang-on-linux-cachyos-6-19-0-2/22963/24
<@xariann:fedora.im>
17:18:02
There is also some other thread on that forum with the same issue (they released that as soon as it became stable)
<@adamwill:fedora.im>
17:18:25
seems like https://lore.kernel.org/lkml/20260227080638.208693-1-lkml@antheas.dev/ is the fix for this?
<@jforbes:fedora.im>
17:18:42
Yes, there is a patch for that one, I was trying to follow up with upstream as it seems staged nowhere and not scheduled for inclusion yet
<@xariann:fedora.im>
17:18:54
Yeah, the Cachy kernel 6.19.5 seems to have it, when I looked at the log they did exactly what the patch proposed
<@adamwill:fedora.im>
17:19:09
it got reviewed-by from both nvidia and amd so seems like it ought to move along...
<@xariann:fedora.im>
17:19:10
(and I can boot that kernel)
<@jforbes:fedora.im>
17:19:55
adamw: I expect it will, and I can certainly pull it in for 6.19.7. Just trying to make sure it doesn't become a regression in 7.x
<@adamwill:fedora.im>
17:20:05
rgr
<@kparal:matrix.org>
17:20:07
Xariann: so if you remove "rhgb quiet", you still don't see any boot messages that you can capture on a photo?
<@xariann:fedora.im>
17:20:30
The photo is showing the messages
<@xariann:fedora.im>
17:21:08
Oh wait the photo was on Arch. I can remve rhgb quiet if you like, but when I turn off IOMMU the kernel does boot, I am pretty sure it's the same issue
<@kparal:matrix.org>
17:21:20
ah, I overlooked that one
<@xariann:fedora.im>
17:21:29
(When I turn it off on Fedora that is)
<@adamwill:fedora.im>
17:21:29
that cachyos thread is pretty messy, i suspect several different issues being discussed there
<@kparal:matrix.org>
17:21:59
Xariann: I don't see your motherboard listed in the bug
<@kparal:matrix.org>
17:22:13
I actually have a desktop with a similar motherboard as listed in the cachyos discussion, I might give this a try
<@xariann:fedora.im>
17:22:18
Ahh! Sorry B650M DS3H
<@xariann:fedora.im>
17:22:28
Want me to add it there?
<@osama-albahrani:matrix.org>
17:22:34
where do you see that?
<@adamwill:fedora.im>
17:22:50
replies in the thread, https://lore.kernel.org/lkml/20260227080638.208693-1-lkml@antheas.dev/
<@xariann:fedora.im>
17:23:08
It is messy but there are several mentions of iommu. There is also a Reddit thread. Just saying it's not just me haha
<@adamwill:fedora.im>
17:24:07
yeah, in this case we definitely seem to have indications multiple systems are affected at least
<@adamwill:fedora.im>
17:24:23
i'm a bit unsure about blocker status, it's hard to guess
<@jforbes:fedora.im>
17:24:46
Right, and with the reviews, I don't mind pulling the patch back for 6.19.7 later this week, so blocker status doesn't really matter
<@kparal:matrix.org>
17:24:47
wait for more Beta feedback?
<@adamwill:fedora.im>
17:25:05
sure, i can say that with a straight face!
<@jforbes:fedora.im>
17:25:29
I just have more work to do to follow up with upstream to ensure it gets pulled into 7.0 too
<@adamwill:fedora.im>
17:25:54
proposed !agreed 2443049 - punt (delay decision) - there's some uncertainty around just how many systems are affected by this. we'll delay the decision for a bit to see how feedback looks after the public Beta release, and maybe see if the fix lands in the kernel (making the decision irrelevant)
<@derekenz:fedora.im>
17:26:12
ack
<@jforbes:fedora.im>
17:26:12
Of course, Phoronix seems to be reporting that we will ship F44 on 7.0 which is news to me :)
<@jgroman:fedora.im>
17:26:28
ack
<@xariann:fedora.im>
17:26:30
ack
<@kparal:matrix.org>
17:26:31
Xariann: iommu is configured in bios?
<@osama-albahrani:matrix.org>
17:26:43
ack
<@adamwill:fedora.im>
17:27:05
phoronix is ahead of us all
<@xariann:fedora.im>
17:27:07
IOMMU on in BIOS, if I turn it off with kernel par then it works. Or if I use passthrough mode
<@kparal:matrix.org>
17:28:02
my desktop booted fine with iommu on "auto" in bios. Not sure what that means
<@kparal:matrix.org>
17:28:31
ack
<@adamwill:fedora.im>
17:29:03
!agreed 2443049 - punt (delay decision) - there's some uncertainty around just how many systems are affected by this. we'll delay the decision for a bit to see how feedback looks after the public Beta release, and maybe see if the fix lands in the kernel (making the decision irrelevant)
<@adamwill:fedora.im>
17:29:17
!link https://pagure.io/fedora-qa/blocker-review/issue/2074
<@adamwill:fedora.im>
17:29:17
!topic (2359799) Inital-setup: VK_ERROR_DEVICE_LOST using nvidia hardware
<@adamwill:fedora.im>
17:29:17
!link https://bugzilla.redhat.com/show_bug.cgi?id=2359799
<@adamwill:fedora.im>
17:29:17
!info Proposed Blocker, mesa, NEW
<@adamwill:fedora.im>
17:31:06
so, well, this is a mess. it's filed against mesa on 42, the discussion indicates it's the kernel, or g-i-s, or mesa?
<@adamwill:fedora.im>
17:31:15
Michael Catanzaro are you around? can you explain this one a bit more? whose fault is it?
<@mcatanzaro:gnome.org>
17:31:52
adamw I don't know. mesa seems like as good a guess as any.
<@mcatanzaro:gnome.org>
17:32:14
The bug was definitely introduced in F42. Lots of complaints on reddit starting then.
<@adamwill:fedora.im>
17:32:18
so, well, this looks bad, but otoh, we've shipped at least two releases with it, so what's the rationale for blocking the next release on it?
<@mcatanzaro:gnome.org>
17:32:29
Lots of complaints on reddit. ;)
<@adamwill:fedora.im>
17:33:09
ok, sure, this is, you know, 'system must boot', for affected systems. but there's a solid argument that it's hard to block a release on a bug that we know exists in the current release, because...what does it achieve?
<@kparal:matrix.org>
17:33:35
I just want to say that with nvidia, there are always hundreds of issues that people complain about, but we can hardly do anything with...
<@adamwill:fedora.im>
17:33:35
if we do block on this bug, the current release has the bug. if we don't block on this bug, the current release has the bug.
<@adamwill:fedora.im>
17:33:58
this is at least nouveau-on-nvidia, apparently, not the proprietary driver. so it's theoretically subject to investigation / fix
<@mcatanzaro:gnome.org>
17:35:42
* 5 days ago: https://www.reddit.com/r/Fedora/comments/1rky86u/fedora_timezone_installation_bug/
<@mcatanzaro:gnome.org>
17:35:42
* 21 days ago: https://www.reddit.com/r/Fedora/comments/1rofpls/stuck_at_time_zone_selection/
<@mcatanzaro:gnome.org>
17:35:42
* 2 months ago: https://www.reddit.com/r/linuxquestions/comments/1q60heu/would_it_be_better_for_meothers_to_use_the/
<@mcatanzaro:gnome.org>
17:35:42
* 4 months ago: https://www.reddit.com/r/Fedora/comments/1olm15n/fedora_43_setup_freezescrashes_at_time_zone_select/
<@mcatanzaro:gnome.org>
17:35:42
* 10 months ago: https://www.reddit.com/r/Fedora/comments/1kl3lbh/stuck_on_time_zone_selection/
<@mcatanzaro:gnome.org>
17:35:42
* 1 year ago: https://www.reddit.com/r/Fedora/comments/1k3s9n7/fedora_42_crash_on_time_zone_selection_how_do_i/
<@mcatanzaro:gnome.org>
17:35:42
* 1 year ago: https://www.reddit.com/r/Fedora/comments/1k2ezpq/time_zone_setup_keeps_freezinv/
<@mcatanzaro:gnome.org>
17:35:42
<@mcatanzaro:gnome.org>
17:35:42
* 2 days ago: https://www.reddit.com/r/Fedora/comments/1rnav2v/cant_get_past_time_zone_on_setup/
<@mcatanzaro:gnome.org>
17:35:42
Yes, this is an open source bug. You install proprietary driver _after_ initial setup.
<@adamwill:fedora.im>
17:37:03
thanks for finding it, at least. i agree we ought to prioritize trying to investigate/fix it
<@adamwill:fedora.im>
17:37:36
we can make a case for blocking just on the bug merits alone, I just get stuck a bit on the 'but it's in f42/f43 already' thing. other votes?
<@adamwill:fedora.im>
17:37:55
the criterion is "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
<@conan_kudo:matrix.org>
17:39:44
since mesa gets rebased in stable releases, it's not a good reason to say it affects older releases it can't block new ones
<@derekenz:fedora.im>
17:39:56
So we have another nvidia problem?
<@kparal:matrix.org>
17:40:23
FinalBlocker 0
<@adamwill:fedora.im>
17:40:26
well, in this case, it seems like it was present at release time
<@adamwill:fedora.im>
17:40:35
people are hitting it in g-i-s, remember, before applying any updats
<@adamwill:fedora.im>
17:40:38
people are hitting it in g-i-s, remember, before applying any updates
<@kparal:matrix.org>
17:40:40
(There's always some nvidia problem. Most likely a dozen.)
<@mcatanzaro:gnome.org>
17:40:49
Criterion should be:
<@mcatanzaro:gnome.org>
17:40:49
<@mcatanzaro:gnome.org>
17:40:49
> If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test.
<@mcatanzaro:gnome.org>
17:40:55
It's pretty specific.
<@adamwill:fedora.im>
17:41:20
the one i cited is an earlier criterion (basic) so kinda has more 'force' i would say
<@kparal:matrix.org>
17:42:04
In general this is closer to +1 because many people are affected. But given that it's already in stable releases, blocking on it doesn't achieve much.
<@adamwill:fedora.im>
17:42:24
put it this way: when it's a hardware-specific issue, we're doing a 'how many systems need to be affected for it to block' calculation. i'd set that bar lower for a 'can't get through g-i-s at all' bug than a 'some non-critical function in g-i-s is broken' bug
<@derekenz:fedora.im>
17:43:03
hmmmm good point
<@adamwill:fedora.im>
17:43:52
i suppose you can make a practical argument that if we don't make it a blocker it might not get fixed and we might just roll along with it forever, whereas if we make it a blocker, we can yell at people and get it fixed
<@haasjona:matrix.org>
17:44:00
A previous workaround was installing an old version (41?) and doing system upgrades, but with each new release that becomes less feasible
<@adamwill:fedora.im>
17:44:02
i don't usually like that kinda 'process abuse', but hey, it's an argument
<@adamwill:fedora.im>
17:44:24
that's true too
<@conan_kudo:matrix.org>
17:45:17
I think it is very blockery
<@conan_kudo:matrix.org>
17:45:30
it affects a wide range and basically the majority of laptops
<@conan_kudo:matrix.org>
17:45:39
+1
<@conan_kudo:matrix.org>
17:45:49
+1 FB
<@derekenz:fedora.im>
17:46:16
FinalBlocker +1
<@adamwill:fedora.im>
17:46:16
i'm not sure 'the majority' of laptops have an nvidia GPU? i suspect most laptops are low- or mid-range efforts with intel GPUs
<@adamwill:fedora.im>
17:46:27
but it's likely more than the other two bugs at least
<@kparal:matrix.org>
17:46:55
that is true
<@kparal:matrix.org>
17:47:18
but doesn't this affect desktops as well?
<@jforbes:fedora.im>
17:47:21
Yeah, majority is very misleading there. It is nowhere near a majority, but it isn't an insignificant amount either
<@adamwill:fedora.im>
17:47:33
do we know?
<@adamwill:fedora.im>
17:47:41
at a guess ,though, yeagh
<@adamwill:fedora.im>
17:47:47
nothing about this one seems laptop-specific
<@adamwill:fedora.im>
17:48:04
it seems like some weird bug with calculating the width of a ui element or something
<@adamwill:fedora.im>
17:48:20
i guess i can be a weak +1
<@kparal:matrix.org>
17:48:26
I'm fine with having it as a blocker. But we might find out that we have no one capable of fixing this.
<@jforbes:fedora.im>
17:48:51
adamw: Yes, look at the laptop market over the last 5 years, and count how many of those have nvida chips., then count how many of them use it as a primary display vs i915. Very few laptops would be problematic for install. Desktops on the other hand....
<@kparal:matrix.org>
17:49:05
adamw: "The logical or physical device has been lost. (VK_ERROR_DEVICE_LOST)" doesn't sound like a UI issue
<@kparal:matrix.org>
17:49:34
but the UI issue is quite logical outcome 🙂
<@conan_kudo:matrix.org>
17:49:40
even if it isn't the laptops, it's still >90% of the PC graphics market: https://www.pcworld.com/article/3079686/nvidia-dominates-pc-graphics-cards-eating-94-of-the-market.html
<@adamwill:fedora.im>
17:49:41
i was looking at comment #6
<@jforbes:fedora.im>
17:50:15
Conan Kudo: That ignores completely the number of systems using onboard only with no external GPU
<@adamwill:fedora.im>
17:50:30
Conan Kudo that's discrete GPUs, I think. it'd look a bit different if it accounted for mobos with built-in graphics. but yes, tehre's a lot of nvidia.
<@adamwill:fedora.im>
17:51:07
i think we just about have +3 at this point?
<@haasjona:matrix.org>
17:51:44
I'm +1 FB if I get to vote
<@adamwill:fedora.im>
17:52:13
proposed !agreed 2359799 - AcceptedBlocker (Final) - this is accepted as a violation of the various first boot and initial setup criteria (at Base and Final) when installing on systems with affected NVIDIA GPUs. we do note it was already broken in F42 and F43, which may cause us to consider waiving it if it proves difficult to fix in a realistic timeframe
<@derekenz:fedora.im>
17:52:40
ack
<@adamwill:fedora.im>
17:52:48
everyone gets to vote, the votes run through the highly-advanced, AI-infused weighting algorithm
<@jgroman:fedora.im>
17:52:55
ack
<@adamwill:fedora.im>
17:52:57
(that's Adam Intelligence)
<@aggraxis:fedora.im>
17:53:00
ack
<@adamwill:fedora.im>
17:53:19
!agreed 2359799 - AcceptedBlocker (Final) - this is accepted as a violation of the various first boot and initial setup criteria (at Base and Final) when installing on systems with affected NVIDIA GPUs. we do note it was already broken in F42 and F43, which may cause us to consider waiving it if it proves difficult to fix in a realistic timeframe
<@adamwill:fedora.im>
17:53:51
!info that's all the proposed blockers, let's move on to:
<@adamwill:fedora.im>
17:53:55
!topic Proposed Final freeze exception
<@adamwill:fedora.im>
17:53:59
!link https://bugzilla.redhat.com/show_bug.cgi?id=2445393
<@adamwill:fedora.im>
17:53:59
!topic (2445393) SSSD needs to add Plasma Login Manager to the PAM services whitelist for the AD provider
<@adamwill:fedora.im>
17:53:59
!info Ticket vote: FinalFreezeException (+2,0,-0) (+derekenz, +nielsenb)
<@adamwill:fedora.im>
17:53:59
!info Proposed Freeze Exceptions, sssd, NEW
<@adamwill:fedora.im>
17:53:59
!link https://pagure.io/fedora-qa/blocker-review/issue/2073
<@adamwill:fedora.im>
17:54:11
this has +2, so only needs another +1, unless anyone is -1
<@aggraxis:fedora.im>
17:54:20
+1
<@adamwill:fedora.im>
17:54:40
yeah, +1 for me
<@supakeen:fedora.im>
17:54:46
Which variants use PLM now, is it desktop?
<@kparal:matrix.org>
17:54:48
+1 fe
<@supakeen:fedora.im>
17:54:53
(+1 regardless)
<@adamwill:fedora.im>
17:55:53
KDE
<@adamwill:fedora.im>
17:56:25
proposed !agreed 2445393 - AcceptedFreezeException (Final) - this is accepted as a significant improvement/fix for enterprise login on KDE that can't be fully achieved with a post-release update
<@adamwill:fedora.im>
17:56:38
(there might even be a case for blocker here, but meh, let's just fix it)
<@derekenz:fedora.im>
17:56:46
ack
<@xariann:fedora.im>
17:56:53
ack
<@jgroman:fedora.im>
17:56:55
ack
<@conan_kudo:matrix.org>
17:56:57
ack
<@aggraxis:fedora.im>
17:57:05
ack
<@adamwill:fedora.im>
17:57:34
!agreed 2445393 - AcceptedFreezeException (Final) - this is accepted as a significant improvement/fix for enterprise login on KDE that can't be fully achieved with a post-release update
<@adamwill:fedora.im>
17:57:46
!info that's all the proposals, let's very quickly do:
<@adamwill:fedora.im>
17:57:52
!topic Accepted Final blocker review
<@adamwill:fedora.im>
17:58:13
!info all the accepted blockers are 'image over size' issues, I have not looked into them yet
<@adamwill:fedora.im>
17:58:20
that's about all i got. did anyone else look at them yet?
<@kparal:matrix.org>
17:59:12
I think that's a job for their owners, not us
<@adamwill:fedora.im>
17:59:25
theoretically, yes, but it usually winds up being me :/
<@kparal:matrix.org>
17:59:26
either trim something or increase the max size
<@kparal:matrix.org>
17:59:43
well, you should spend your time elsewhere, is my opinion 🙂
<@matthiasc:gnome.org>
18:00:50
firmware will grow until it consumes all space...
<@adamwill:fedora.im>
18:00:56
yes, netinsts usually wind up being firmware
<@adamwill:fedora.im>
18:01:06
but there can also be other stuff, growing deps etc
<@adamwill:fedora.im>
18:01:24
the 'owner' thing is a bit awkward because the nominal owners don't necessarily have anything to do with why the images got bigger
<@adamwill:fedora.im>
18:01:57
anyhoo, that's the status
<@adamwill:fedora.im>
18:01:59
!topic Open floor
<@adamwill:fedora.im>
18:02:03
anything else we missed?
<@kparal:matrix.org>
18:02:54
it's not really related to blocker meeting, rather general qa, but just a reminder that we're supposed to have common issues documented tomorrow for the official Beta release. If anyone wants to help, it's very appreciated
<@derekenz:fedora.im>
18:03:15
Nothing here for now
<@kparal:matrix.org>
18:03:18
https://discussion.fedoraproject.org/c/ask/common-issues/common-issues-proposed/86
<@kparal:matrix.org>
18:03:18
and
<@kparal:matrix.org>
18:03:18
https://bugzilla.redhat.com/buglist.cgi?classification=Fedora&f0=OP&f1=OP&f2=status_whiteboard&f3=CP&f4=CP&j1=OR&keywords=CommonBugs&keywords_type=allwords&known_name=CommonBugs%3F&list_id=13658829&o2=notregexp&product=Fedora&query_based_on=CommonBugs%3F&query_format=advanced&v2=https%3F%3A%2F%2F%28fedoraproject.org%2Fwiki%2FCommon_F%5B0-9%5D%2B_bugs%7Cask.fedoraproject.org%2Ft%2F%28.%2A%2F%29%3F%5B0-9%5D%2B%7Cdiscussion.fedoraproject.org%2Ft%2F%28.%2A%2F%29%3F%5B0-9%5D%2B%29
<@kparal:matrix.org>
18:03:18
Current proposals to go through:
<@adamwill:fedora.im>
18:04:20
thanks, i was gonna write whatever isn't written yet today
<@kparal:matrix.org>
18:04:47
I'm going through F43 common bugs and tagging those applicable ones with F44.
<@kparal:matrix.org>
18:04:47
Also, Adam, if you still have details about this problem in your head, it would be great to know whether it affects F44 or not:
<@kparal:matrix.org>
18:04:47
https://discussion.fedoraproject.org/t/live-installers-do-not-allow-selection-of-multiple-keyboard-layouts-input-methods/169790
<@kparal:matrix.org>
18:05:56
Sorry, I didn't really manage to write anything new (or review existing ones) today, I'll do whatever I can tomorrow
<@adamwill:fedora.im>
18:06:35
ugh, 'figure out what's going on with webui and input selection' fell entirely off my backlog at some point
<@adamwill:fedora.im>
18:06:42
i'll try and remember to take a fresh look
<@kparal:matrix.org>
18:07:06
that's all from me
<@adamwill:fedora.im>
18:07:57
thanks
<@zodbot:fedora.im>
18:09:39
aggraxis gave a cookie to kparal. They now have 91 cookies, 3 of which were obtained in the Fedora 43 release cycle
<@zodbot:fedora.im>
18:10:05
aggraxis has already given cookies to adamwill during the F43 timeframe
<@adamwill:fedora.im>
18:10:18
!endmeeting