<@adamwill:fedora.im>
16:03:10
!startmeeting F41-blocker-review
<@meetbot:fedora.im>
16:03:11
Meeting started at 2024-10-14 16:03:10 UTC
<@meetbot:fedora.im>
16:03:11
The Meeting name is 'F41-blocker-review'
<@adamwill:fedora.im>
16:03:13
!topic Roll Call
<@pboy:fedora.im>
16:04:01
!hi
<@zodbot:fedora.im>
16:04:02
Peter Boy (pboy)
<@copperi:fedora.im>
16:04:17
!hi
<@zodbot:fedora.im>
16:04:18
Jan Kuparinen (copperi)
<@lruzicka:matrix.org>
16:04:28
Hoy, let's toy
<@lruzicka:matrix.org>
16:04:36
!hi
<@adamwill:fedora.im>
16:05:24
hi everyone
<@adamwill:fedora.im>
16:05:28
!hi
<@zodbot:fedora.im>
16:05:29
Adam Williamson (adamwill) - he / him / his
<@decathorpe:fedora.im>
16:05:48
!hi
<@zodbot:fedora.im>
16:05:48
Fabio Valentini (decathorpe) - he / him / his
<@derekenz:fedora.im>
16:06:44
!hi
<@zodbot:fedora.im>
16:06:47
Derek Enz (derekenz)
<@adamwill:fedora.im>
16:08:55
alrighty, let's get rolling with some boilerplate
<@conan_kudo:matrix.org>
16:08:58
!hi
<@zodbot:fedora.im>
16:09:00
Neal Gompa (ngompa) - he / him / his
<@adamwill:fedora.im>
16:09:06
!info The bugs up for review today are available at:
<@adamwill:fedora.im>
16:09:06
!topic Introduction
<@adamwill:fedora.im>
16:09:06
Why are we here?
<@adamwill:fedora.im>
16:09:06
!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:09:06
!info The criteria for release blocking bugs can be found at:
<@adamwill:fedora.im>
16:09:06
<@adamwill:fedora.im>
16:09:06
<@adamwill:fedora.im>
16:09:06
<@adamwill:fedora.im>
16:09:06
<@adamwill:fedora.im>
16:09:06
<@adamwill:fedora.im>
16:09:06
!info We'll be following the process outlined at:
<@adamwill:fedora.im>
16:09:36
!info 6 Proposed Freeze Exceptions
<@adamwill:fedora.im>
16:09:36
!info 2 Accepted Blockers
<@adamwill:fedora.im>
16:09:36
!info 5 Proposed Blockers
<@adamwill:fedora.im>
16:09:36
!info for F41 Final, we have:
<@adamwill:fedora.im>
16:09:36
!info 2 Accepted Freeze Exceptions
<@adamwill:fedora.im>
16:09:42
who wants to secretarialize
<@kparal:matrix.org>
16:10:24
if no one volunteers, I can do it
<@lruzicka:matrix.org>
16:10:32
thank you very much
<@lruzicka:matrix.org>
16:10:45
kparal++
<@zodbot:fedora.im>
16:10:47
lruzicka gave a cookie to kparal. They now have 71 cookies, 1 of which were obtained in the Fedora 40 release cycle
<@lruzicka:matrix.org>
16:11:12
zodbot seems to be six month behind schedule
<@lruzicka:matrix.org>
16:11:26
zodbot seems to be six months behind schedule
<@nirik:matrix.scrye.com>
16:11:48
This is the 40 release cycle. ;) 41 hasn't been released yet.
<@kparal:matrix.org>
16:12:50
That's a curious definition of a release cycle
<@adamwill:fedora.im>
16:13:59
definitions, we have em!
<@adamwill:fedora.im>
16:14:05
!info Kamil Páral will secretarialize, thanks
<@adamwill:fedora.im>
16:14:08
let's get started with:
<@adamwill:fedora.im>
16:14:12
!topic Proposed Final blockers
<@adamwill:fedora.im>
16:14:29
!topic (2317851) VLV errors in Fedora 40 with RSNv3 and pruning enabled
<@adamwill:fedora.im>
16:14:29
!info Proposed Blocker, 389-ds-base, POST
<@adamwill:fedora.im>
16:14:29
<@adamwill:fedora.im>
16:14:29
!info Ticket vote: FinalBlocker (+0,0,-2) (-nielsenb, -ngompa)
<@adamwill:fedora.im>
16:14:29
!info Ticket vote: FinalFreezeException (+1,0,-0) (+ngompa)
<@adamwill:fedora.im>
16:14:29
<@adamwill:fedora.im>
16:15:55
so, hum
<@adamwill:fedora.im>
16:16:03
the freeipa criteria we have don't actually talk about certificate issuing at all
<@adamwill:fedora.im>
16:16:28
requirements we have:
<@adamwill:fedora.im>
16:16:29
"the system must handle multiple client enrolments and unenrolments, and client authentication via Kerberos. The web UI must be available and allow at least basic configuration of user accounts and permissions"
<@adamwill:fedora.im>
16:16:38
Serve DNS SRV records for ldap and kerberos on port 53 (assuming it is deployed with DNS capability)"
<@adamwill:fedora.im>
16:16:38
" Serve LDAP requests, including TLS-encrypted LDAP requests, on port 389
<@adamwill:fedora.im>
16:16:38
Serve LDAPS (LDAP encrypted with SSL) requests on port 636
<@adamwill:fedora.im>
16:16:38
Return LDAP and LDAPS search results using simple auth or SASL/GSSAPI auth
<@adamwill:fedora.im>
16:16:38
Serve DNS host records on port 53 (assuming it is deployed with DNS capability)
<@adamwill:fedora.im>
16:17:02
so, maybe that's an oversight. but as it stands, to me it's a bit hard to make this a blocker
<@adamwill:fedora.im>
16:17:23
i'd happily give it +1 FE, though, to try and reduce the risk of the bug happening on early deployments
<@pboy:fedora.im>
16:19:02
Obviously, there is already a fix available, isn't it? So a FE would be ok.
<@conan_kudo:matrix.org>
16:19:23
I said as much in the ticket as well
<@conan_kudo:matrix.org>
16:23:27
a separate conversation might be to add criterion for the ACME feature in FreeIPA for future releases
<@conan_kudo:matrix.org>
16:23:38
but I don't know enough about that feature to determine how to word that
<@pboy:fedora.im>
16:24:16
Can we delay and I'll contact Alexander?
<@conan_kudo:matrix.org>
16:24:41
we can accept an FE now I think
<@conan_kudo:matrix.org>
16:24:50
abbra is in this room too
<@conan_kudo:matrix.org>
16:24:57
we can ask him for his opinion
<@adamwill:fedora.im>
16:25:24
Peter Boy: "IPA isn't working" is too complex of a concept
<@adamwill:fedora.im>
16:25:27
FreeIPA does a lot of stuff
<@pboy:fedora.im>
16:25:28
I know, abbra are you online and can comment**
<@adamwill:fedora.im>
16:25:36
issuing server certificates is just one of many, many, many things it does
<@pboy:fedora.im>
16:27:07
Not, that certificdates are unimportant and seldom, today.
<@adamwill:fedora.im>
16:27:53
sure, it's a significant feature, that's why i said not having it in the criteria may be an oversight. but it's tricky to just make up criteria on the fly, we do try to avoid doing it unless it's absolutely necessary
<@adamwill:fedora.im>
16:28:02
i think in this case +1 FE and punt is a good idea
<@conan_kudo:matrix.org>
16:28:09
yeah
<@conan_kudo:matrix.org>
16:28:23
and we can address the criteria gap for F42
<@pboy:fedora.im>
16:31:26
I’m not sure, what punt is (my mental dictionary is missing that), but OK for me.
<@conan_kudo:matrix.org>
16:31:51
punt means defer
<@pboy:fedora.im>
16:32:00
OK, thjanks :-)
<@pboy:fedora.im>
16:32:24
+1 FE and punt
<@lruzicka:matrix.org>
16:32:47
+1 FE and punt
<@derekenz:fedora.im>
16:33:01
+1 FE and punt
<@copperi:fedora.im>
16:33:46
+1 FE and punt
<@abbra:matrix.org>
16:35:00
Hi, sorry I'm traveling right now. Lmdb bug is real and we have a good fix. FE is good enough.
<@geraldosimiao:matrix.org>
16:35:03
+1 FE and punt
<@adamwill:fedora.im>
16:35:51
ok
<@adamwill:fedora.im>
16:37:09
proposed !agreed 2317851 - AcceptedFreezeException (Final), punt (blocker status) - we noted that the current FreeIPA criteria do not explicitly cover certificate issuance and management, but this could be considered an oversight. For now we agreed to accept this as a freeze exception issue to minimize the likelihood of problems for early deployments, and delay the blocker decision to allow for discussion of whether there should be a criterion covering this feature of FreeIPA
<@kparal:matrix.org>
16:37:26
ack
<@pboy:fedora.im>
16:37:43
ack
<@derekenz:fedora.im>
16:37:46
ack
<@copperi:fedora.im>
16:37:54
ack
<@adamwill:fedora.im>
16:38:10
!agreed 2317851 - AcceptedFreezeException (Final), punt (blocker status) - we noted that the current FreeIPA criteria do not explicitly cover certificate issuance and management, but this could be considered an oversight. For now we agreed to accept this as a freeze exception issue to minimize the likelihood of problems for early deployments, and delay the blocker decision to allow for discussion of whether there should be a criterion covering this feature of FreeIPA
<@geraldosimiao:matrix.org>
16:38:14
ack
<@adamwill:fedora.im>
16:38:22
<@adamwill:fedora.im>
16:38:22
!topic (2317287) Firmware RAID installation is impossible with automatic partitioning
<@adamwill:fedora.im>
16:38:22
<@adamwill:fedora.im>
16:38:22
!info Proposed Blocker, anaconda, ASSIGNED
<@adamwill:fedora.im>
16:38:22
!info Ticket vote: FinalBlocker (+3,0,-1) (+geraldosimiao, +nielsenb, +ngompa, -nixuser)
<@adamwill:fedora.im>
16:38:22
!info Ticket vote: FinalFreezeException (+1,0,-0) (+nixuser)
<@adamwill:fedora.im>
16:38:35
+1 for me
<@copperi:fedora.im>
16:39:16
+1
<@derekenz:fedora.im>
16:39:19
+1
<@conan_kudo:matrix.org>
16:39:23
+1
<@pboy:fedora.im>
16:39:37
+1
<@lruzicka:matrix.org>
16:39:38
+1
<@kparal:matrix.org>
16:40:32
+1 blocker
<@adamwill:fedora.im>
16:41:04
proposed !agreed - 2317287 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to detect and install to firmware RAID storage devices" when using guided partitioning
<@copperi:fedora.im>
16:42:09
ack
<@lruzicka:matrix.org>
16:42:50
ack
<@conan_kudo:matrix.org>
16:42:54
ack
<@derekenz:fedora.im>
16:42:57
ack
<@kparal:matrix.org>
16:43:05
ack
<@adamwill:fedora.im>
16:43:26
!agreed - 2317287 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to detect and install to firmware RAID storage devices" when using guided partitioning
<@adamwill:fedora.im>
16:43:35
!info Proposed Blocker, dbus-broker, NEW
<@adamwill:fedora.im>
16:43:35
!topic (2316066) dbus activated apps including the welcome dialog suffer 30-45 sec delay and/or crash on Workstation Live image randomly
<@adamwill:fedora.im>
16:43:35
<@adamwill:fedora.im>
16:43:35
<@adamwill:fedora.im>
16:43:35
!info Ticket vote: FinalBlocker (+4,2,-0) (+asciiwolf, +jmaybaum, +sumantrom, +ngompa, geraldosimiao, nielsenb)
<@adamwill:fedora.im>
16:43:42
so last week we punted this one for more testing/discussion
<@adamwill:fedora.im>
16:43:54
since then it got three new +1 votes with no rationale
<@adamwill:fedora.im>
16:44:22
from sumantro (who's on pto), Conan Kudo and catanzaro (who's not around apparently)
<@adamwill:fedora.im>
16:44:36
and we seem to have pinned it down to "So apparently it will happen on VMs using the "utc" clock offset (virt-manager default), with more than one CPU configured"
<@kparal:matrix.org>
16:45:04
no, I tested it today, no relevance to clock
<@kparal:matrix.org>
16:45:18
at least on my machine
<@kparal:matrix.org>
16:45:22
https://bugzilla.redhat.com/show_bug.cgi?id=2316066#c16
<@adamwill:fedora.im>
16:45:23
(although...I'm using a virt-manager VM with two CPUs configured and still didn't see it, so eh
<@adamwill:fedora.im>
16:45:30
(although...I'm using a virt-manager VM with two CPUs configured and still didn't see it, so eh)
<@kparal:matrix.org>
16:45:43
adamw: try 6 cores. If you have at least 8 on your host system.
<@adamwill:fedora.im>
16:45:50
it was suggested that "So apparently it will happen on VMs using the "utc" clock offset (virt-manager default), with more than one CPU configured", but Kamil Páral can't confirm that
<@conan_kudo:matrix.org>
16:46:18
3 cores + utc triggered it for me
<@conan_kudo:matrix.org>
16:46:26
2 or 4 doesn't
<@adamwill:fedora.im>
16:46:54
it only triggers with an amount of CPUs that isn't 1 or 2^n? :D
<@kparal:matrix.org>
16:46:54
this was my testing: https://bugzilla.redhat.com/show_bug.cgi?id=2316066#c8
<@conan_kudo:matrix.org>
16:47:07
well I don't have enough cores for more to verify that
<@conan_kudo:matrix.org>
16:47:18
at least not on my laptop
<@kparal:matrix.org>
16:47:27
it's a race. The likelihood seems to go up with core count
<@conan_kudo:matrix.org>
16:47:58
one core just makes everything hang anyway
<@conan_kudo:matrix.org>
16:48:14
it's been that way for me for a while (several releases)
<@kparal:matrix.org>
16:48:26
with 1 core, everything works just fine here, it's just a bit slower
<@kparal:matrix.org>
16:51:04
honestly, I'm not sure whether this is worth a blocker. I'm more concerned about some possible side-effects that we're not aware of, than the initial delay itself.
<@conan_kudo:matrix.org>
16:51:17
yeah
<@conan_kudo:matrix.org>
16:51:30
dbus not doing the thing is more worrying
<@adamwill:fedora.im>
16:51:32
yeah...the worst case is it causes something really important to crash and never recover, i guess
<@adamwill:fedora.im>
16:51:37
but we haven't seen any indication that that can happen yet?
<@adamwill:fedora.im>
16:51:46
i kinda feel like if this was the last blocker we'd -1 or waive it
<@adamwill:fedora.im>
16:52:05
(it also feels hard to debug which i admit is influencing my thinking)
<@conan_kudo:matrix.org>
16:52:43
if it was absolutely the last thing, I'd probably waive under hard to fix and mark as common bug and hope we can fix it post-GA or next release
<@conan_kudo:matrix.org>
16:53:09
but I am nervous about it because of how important dbus is for the system
<@adamwill:fedora.im>
16:53:42
btw, do we know if this happens post-install too? has anyone checked that?
<@adamwill:fedora.im>
16:53:55
that might affect my evaluation
<@kparal:matrix.org>
16:55:37
I didn't see it post-install, just Live
<@lruzicka:matrix.org>
16:55:43
I have never seen anything like that on any of my machines, they all have multiple cores, but I have been upgrading for a couple of years now. Never did a new installation of F41.
<@kparal:matrix.org>
16:56:09
lruzicka: you have to assign more than 2 cores to a VM in order to see it more frequently
<@conan_kudo:matrix.org>
16:56:20
adamw: I didn't get far enough admittedly
<@lruzicka:matrix.org>
16:56:24
So this is only on a VM?
<@adamwill:fedora.im>
16:56:31
if it doesn't happen post-install i think i'm a weak -1
<@kparal:matrix.org>
16:56:44
I saw some issues on bare metal as well, but I'm not sure whether it was the same problem
<@adamwill:fedora.im>
16:56:47
but it'd be good to know mcatanzaro's thoughts, shame he's not around
<@kparal:matrix.org>
16:56:51
I saw abrt timing out during boot
<@lruzicka:matrix.org>
16:56:54
If so, then I would be -1 FB, +1 FE, CommonBugs
<@farribeiro:matrix.org>
16:59:03
!hi
<@zodbot:fedora.im>
16:59:05
Fábio Ribeiro (farribeiro) - he / him / his
<@adamwill:fedora.im>
17:00:22
i *guess* we can punt it again, if by some miracle we get to other blockers addressed this week, we can do an RC without it fixed and argue it at go/no-go
<@adamwill:fedora.im>
17:00:42
atm we don't have a clear winner in the voting
<@geraldosimiao:matrix.org>
17:02:17
+1 to this
<@adamwill:fedora.im>
17:02:34
ok, let's go with that
<@adamwill:fedora.im>
17:02:48
oh, did we give it FE already?
<@adamwill:fedora.im>
17:02:58
no, we didn't. so let's do that at least. +1 FE
<@geraldosimiao:matrix.org>
17:03:27
+1 FE
<@lruzicka:matrix.org>
17:03:53
+1 FE
<@adamwill:fedora.im>
17:04:24
proposed !agreed 2316066 - AcceptedFreezeException (Final), punt (delay decision) on blocker status - this is still a tough one to call and the voting is split. Some people who voted in the issue didn't provide rationale and weren't at the meeting for discussion. for now we will punt on it, and if we're otherwise in a position to do an RC this week, we'll build one without a fix for this (unless it gets fixed) and discuss it again at the go/no-go meeting. It is accepted as an FE so we can get a fix in if one shows up
<@geraldosimiao:matrix.org>
17:04:35
Ack
<@farribeiro:matrix.org>
17:04:41
Ack
<@derekenz:fedora.im>
17:04:43
Ack
<@copperi:fedora.im>
17:04:53
ack
<@kparal:matrix.org>
17:05:19
ack
<@adamwill:fedora.im>
17:05:30
!agreed 2316066 - AcceptedFreezeException (Final), punt (delay decision) on blocker status - this is still a tough one to call and the voting is split. Some people who voted in the issue didn't provide rationale and weren't at the meeting for discussion. for now we will punt on it, and if we're otherwise in a position to do an RC this week, we'll build one without a fix for this (unless it gets fixed) and discuss it again at the go/no-go meeting. It is accepted as an FE so we can get a fix in if one shows up
<@adamwill:fedora.im>
17:05:50
!topic (2318535) KInfoCenter does not start
<@adamwill:fedora.im>
17:05:50
<@adamwill:fedora.im>
17:05:50
<@adamwill:fedora.im>
17:05:50
!info Proposed Blocker, kinfocenter, NEW
<@adamwill:fedora.im>
17:06:58
+1 - "system settings" is affected, and that's in the list in the criterion
<@adamwill:fedora.im>
17:07:12
Kamil Páral: how exactly did you try and launch them?
<@kparal:matrix.org>
17:07:12
I can't reproduce the issue
<@lruzicka:matrix.org>
17:07:14
+1 FB
<@derekenz:fedora.im>
17:07:26
Same
<@kparal:matrix.org>
17:07:30
from the menu by writing their name and enter
<@lruzicka:matrix.org>
17:07:40
On 20241013?
<@kparal:matrix.org>
17:07:43
yes
<@lruzicka:matrix.org>
17:07:59
maybe with 2+ cores it works
<@lruzicka:matrix.org>
17:08:22
I could not start it even with the launcher in the panel.
<@kparal:matrix.org>
17:09:57
lruzicka: have you tried turning it off and on again?
<@lruzicka:matrix.org>
17:10:30
well, not immediately, but I have restarted the VM in between occassionally. :D
<@lruzicka:matrix.org>
17:10:41
well, not immediately, but I restarted the VM in between occassionally. :D
<@kparal:matrix.org>
17:10:42
ok
<@kparal:matrix.org>
17:10:56
or waiting 45 sec, if this was the dbus issue again, by accident
<@adamwill:fedora.im>
17:11:45
hmm, there might be some variability here
<@lruzicka:matrix.org>
17:11:53
Assigned 4 cores, restarted, System Settings started, InfoCenter did not
<@lruzicka:matrix.org>
17:11:53
Update:
<@adamwill:fedora.im>
17:11:55
in openqa stg, kinfocenter failed but system settings passed
<@lruzicka:matrix.org>
17:12:12
sometimes it passed.
<@adamwill:fedora.im>
17:12:15
but system settings failed on 20241012.n.0
<@adamwill:fedora.im>
17:12:32
in 2/3 runs
<@kparal:matrix.org>
17:12:51
we seem to have another race, great
<@lruzicka:matrix.org>
17:13:01
the KDE start stop tests will need some nurturing from me ... I suspect that after they bounce back to the saved image, KDE does not respond quickly enough
<@adamwill:fedora.im>
17:13:50
Oct 12 04:34:22 fedora khelpcenter[3463]: qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0
<@adamwill:fedora.im>
17:13:50
```
<@adamwill:fedora.im>
17:13:50
Oct 12 04:34:12 fedora systemd[1095]: Started dbus-:1.2-org.kde.khelpcenter@0.service.
<@adamwill:fedora.im>
17:13:50
Oct 12 04:34:14 fedora khelpcenter[3463]: libEGL warning: egl: failed to create dri2 screen
<@adamwill:fedora.im>
17:13:50
Oct 12 04:34:43 fedora systemd[1095]: dbus-:1.2-org.kde.khelpcenter@0.service: Consumed 5.392s CPU time, 478.6M memory peak.
<@adamwill:fedora.im>
17:13:50
i do see this in the logs of a case where kinfocenter failed:
<@adamwill:fedora.im>
17:13:50
```
<@adamwill:fedora.im>
17:13:50
Oct 12 04:34:43 fedora systemd[1095]: dbus-:1.2-org.kde.khelpcenter@0.service: Unit process 3477 (QtWebEngineProc) remains running after unit stopped.
<@adamwill:fedora.im>
17:13:50
Oct 12 04:34:43 fedora systemd[1095]: dbus-:1.2-org.kde.khelpcenter@0.service: Unit process 3475 (QtWebEngineProc) remains running after unit stopped.
<@adamwill:fedora.im>
17:13:50
Oct 12 04:34:43 fedora systemd[1095]: dbus-:1.2-org.kde.khelpcenter@0.service: Unit process 3474 (QtWebEngineProc) remains running after unit stopped.
<@adamwill:fedora.im>
17:13:50
Oct 12 04:34:22 fedora khelpcenter[3494]: [3494:8:1012/073422.084372:ERROR:command_buffer_proxy_impl.cc(127)] ContextResult::kTransientFailure: Failed to send GpuControl.CreateCommandBuffer.
<@lruzicka:matrix.org>
17:13:55
With some gnome tests, I fixed it by adding some waiting time before it started to run, I might go over those 40 scripts and do it tomorrow, just for sure.
<@adamwill:fedora.im>
17:14:03
the "failed to create dri2 screen" warning is normal, i think, but the others look juicy
<@adamwill:fedora.im>
17:14:30
lruzicka: they do not bounce back to an image any more
<@adamwill:fedora.im>
17:14:33
i changed that, remember
<@adamwill:fedora.im>
17:14:44
erf, which might mean those errors aren't relevant, heh
<@adamwill:fedora.im>
17:15:30
oh, yeah, i don't think they are, these are the kinfocenter messages
<@adamwill:fedora.im>
17:15:41
```
<@adamwill:fedora.im>
17:15:41
Oct 12 04:35:20 fedora systemd[1]: Created slice system-dbus\x2d:1.3\x2dorg.kde.kinfocenter.dmidecode.slice - Slice /system/dbus-:1.3-org.kde.kinfocenter.dmidecode.
<@adamwill:fedora.im>
17:15:41
nothing too suspicious there :/
<@adamwill:fedora.im>
17:15:41
```
<@adamwill:fedora.im>
17:15:41
Oct 12 04:35:30 fedora systemd[1]: dbus-:1.3-org.kde.kinfocenter.dmidecode@0.service: Deactivated successfully.
<@adamwill:fedora.im>
17:15:41
Oct 12 04:35:20 fedora kinfocenter[3520]: qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0
<@adamwill:fedora.im>
17:15:41
Oct 12 04:35:20 fedora systemd[1]: Started dbus-:1.3-org.kde.kinfocenter.dmidecode@0.service.
<@adamwill:fedora.im>
17:15:41
Oct 12 04:35:20 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.3-org.kde.kinfocenter.dmidecode@0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
<@adamwill:fedora.im>
17:15:41
Oct 12 04:35:15 fedora kinfocenter[3520]: libEGL warning: egl: failed to create dri2 screen
<@adamwill:fedora.im>
17:15:41
Oct 12 04:35:13 fedora systemd[1095]: Started app-org.kde.kinfocenter@07a2c0cb37174e21a31d7bc2b46f3973.service - Info Center - Info Center.
<@adamwill:fedora.im>
17:17:02
i guess this might be a 'punt for more manual testing' case...
<@derekenz:fedora.im>
17:18:14
I think I had the wrong build. Running this now in a VM
<@derekenz:fedora.im>
17:19:42
Live cannot reproduce so far
<@adamwill:fedora.im>
17:20:43
oh hey, i just reproduced the doubled-character bug in my vm, so at least that's not openqa only...
<@kparal:matrix.org>
17:21:39
I have a feeling that double character sometimes occurs even on my bare metal system
<@kparal:matrix.org>
17:22:05
It's hard to be sure that it wasn't just me holding the key too long, though
<@kparal:matrix.org>
17:22:26
so, punt this one and investigate more?
<@adamwill:fedora.im>
17:22:36
hmm, i tried running 'systemsettings' from konsole a couple times in my vm, on the second try it has not shown up
<@derekenz:fedora.im>
17:23:44
So far so good on my end. Almost done installing
<@adamwill:fedora.im>
17:25:18
top shows kwin_wayland completely pegging the CPU (but then maybe it does that anyway)
<@derekenz:fedora.im>
17:25:38
Running fine for me so far
<@kparal:matrix.org>
17:26:18
for once, I'm the one for whom it just consistently works 🙂
<@adamwill:fedora.im>
17:26:28
haha
<@kparal:matrix.org>
17:26:29
Just tried it a dozen times
<@adamwill:fedora.im>
17:26:36
do you have 3d passthrough in your vm?
<@kparal:matrix.org>
17:26:55
nope
<@derekenz:fedora.im>
17:27:54
Cant break it yet
<@adamwill:fedora.im>
17:28:06
hmm, no, kwin_wayland is at 14% on a clean boot
<@adamwill:fedora.im>
17:29:16
hmm. so my issue seems kinda reproducible by launching it, quitting it, quickly launching it again. but that's not what openqa is doing...
<@lruzicka:matrix.org>
17:29:31
See the InfoCenter icon and nothing more?
<@lruzicka:matrix.org>
17:30:02
Derek Enz: ^
<@derekenz:fedora.im>
17:30:26
Yes sir
<@adamwill:fedora.im>
17:30:31
lruzicka: did you do anything besides boot the vm and run it?
<@lruzicka:matrix.org>
17:31:19
I tried to run some applications, Konsole, checked notifications (they keep failing, too, on openQA)
<@adamwill:fedora.im>
17:31:51
i'm wondering if what you do before running the app affects it
<@lruzicka:matrix.org>
17:32:50
But ... the InfoCenter was the first app I attempted to run on that VM, because I wanted to see if it is a just a glitch on openQA or if I can see it, too .... and I did
<@adamwill:fedora.im>
17:33:00
hmmf
<@adamwill:fedora.im>
17:33:14
so, this feels a lot like the dbus one...kinda random and hard to debug
<@lruzicka:matrix.org>
17:33:22
in between, I ran several, after a fresh start I could start Settings.
<@lruzicka:matrix.org>
17:33:36
Maybe another fresh start and try that? I am on it.
<@adamwill:fedora.im>
17:33:40
i'm similarly a weak -1 on it, i guess, but it'd be good to hear more people's results on different vms/hw
<@derekenz:fedora.im>
17:33:58
Just ran updates and all good still
<@adamwill:fedora.im>
17:34:34
any other votes?
<@lruzicka:matrix.org>
17:35:40
Nope, does not work.
<@derekenz:fedora.im>
17:36:07
VM?
<@lruzicka:matrix.org>
17:36:12
yes
<@adamwill:fedora.im>
17:36:26
the dbus errors look interesting, but i don't see those in openqa logs
<@derekenz:fedora.im>
17:36:32
A bare metal test might be good
<@adamwill:fedora.im>
17:37:00
should we punt this and continue to investigate async?
<@kparal:matrix.org>
17:37:00
this feels a bit more important than the Workstation dbus problem (if they are not the same). Here it happens to an installed system (did I get that correctly?), and prevents important apps from launching (sometimes).
<@lruzicka:matrix.org>
17:37:27
yes, I am reporting an installed system
<@kparal:matrix.org>
17:38:37
probably punt at this moment, and accept if we can find a better reproducer, or if people see it happen frequently
<@adamwill:fedora.im>
17:38:49
yep, that's my feeling
<@adamwill:fedora.im>
17:39:20
oh, should we accept as FE?
<@adamwill:fedora.im>
17:39:22
i am +1 FE
<@geraldosimiao:matrix.org>
17:40:30
+1 FE
<@lruzicka:matrix.org>
17:40:40
+1 FE
<@derekenz:fedora.im>
17:40:45
+1 FE
<@kparal:matrix.org>
17:41:09
I wonder if we should rename this bug to cover both apps?
<@adamwill:fedora.im>
17:41:16
proposed !agreed 2318535 - AcceptedFreezeException (Final), punt (delay decision) on blocker status - this is fairly new and reproduction is inconsistent across testers and systems so far. We will delay the decision for further investigation. It is accepted as a freeze exception issue, though, as it's at least bad enough that we should fix it before release if possible
<@farribeiro:matrix.org>
17:41:20
+1 FE
<@farribeiro:matrix.org>
17:41:22
ack
<@kparal:matrix.org>
17:41:26
just to make sure we know what we're voting on
<@pboy:fedora.im>
17:41:46
ack
<@adamwill:fedora.im>
17:42:00
Kamil Páral: sure, or 'some apps', i guess
<@kparal:matrix.org>
17:42:17
ok, I'll update the title
<@kparal:matrix.org>
17:42:30
ack
<@derekenz:fedora.im>
17:42:35
ack
<@adamwill:fedora.im>
17:42:40
!agreed 2318535 - AcceptedFreezeException (Final), punt (delay decision) on blocker status - this is fairly new and reproduction is inconsistent across testers and systems so far. We will delay the decision for further investigation. It is accepted as a freeze exception issue, though, as it's at least bad enough that we should fix it before release if possible
<@adamwill:fedora.im>
17:42:49
<@adamwill:fedora.im>
17:42:49
<@adamwill:fedora.im>
17:42:49
!info Proposed Blocker, mediawriter, NEW
<@adamwill:fedora.im>
17:42:49
!topic (2318559) Fedora media writer downloads wrong iso when kde spin is selected
<@adamwill:fedora.im>
17:42:55
this is proposed as a 0-day blocker, i believe
<@adamwill:fedora.im>
17:44:00
so we have the requirement for release-blocking images to boot
<@adamwill:fedora.im>
17:44:02
and "Release-blocking live and dedicated installer images must boot when written to a USB stick with at least one of the officially supported methods"
<@adamwill:fedora.im>
17:44:18
where "officially supported methods" links to https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-installation-image/index.html , where FMW is the top of the list
<@adamwill:fedora.im>
17:44:23
so...we could argue for this under that, i guess
<@kparal:matrix.org>
17:46:03
+1 blocker
<@derekenz:fedora.im>
17:46:24
+1
<@pboy:fedora.im>
17:46:51
+1. and I have to are about the docs :-)
<@pboy:fedora.im>
17:47:02
+1. and I have to care about the docs :-)
<@farribeiro:matrix.org>
17:47:10
+1
<@geraldosimiao:matrix.org>
17:48:44
+1
<@adamwill:fedora.im>
17:49:28
proposed !agreed 2318559 - Accepted0Day - this is accepted as a zero-day blocker for Final (meaning we need the updated fmw to be released for previous Fedoras and Windows by F41 release day). it's accepted as a violation of "All release-blocking images must boot in their supported configurations" with the footnote "Release-blocking live and dedicated installer images must boot when written to a USB stick with at least one of the officially supported methods", since FMW is the primary supported method and KDE is a release-blocking desktop
<@farribeiro:matrix.org>
17:49:35
ack
<@adamwill:fedora.im>
17:49:37
ehh, i don't love that rationale, actually. we have "at least one" in bold and there are other methods
<@adamwill:fedora.im>
17:49:48
but...mmmmeehh. it's a holiday and i want to be out of this meeting
<@geraldosimiao:matrix.org>
17:50:04
Ack
<@derekenz:fedora.im>
17:50:08
ack
<@pboy:fedora.im>
17:50:18
ack
<@adamwill:fedora.im>
17:51:20
good lord, writing this in C++ was definitely a choice
<@adamwill:fedora.im>
17:51:55
!agreed 2318559 - Accepted0Day - this is accepted as a zero-day blocker for Final (meaning we need the updated fmw to be released for previous Fedoras and Windows by F41 release day). it's accepted as a violation of "All release-blocking images must boot in their supported configurations" with the footnote "Release-blocking live and dedicated installer images must boot when written to a USB stick with at least one of the officially supported methods", since FMW is the primary supported method and KDE is a release-blocking desktop
<@adamwill:fedora.im>
17:52:10
okay, moving on
<@adamwill:fedora.im>
17:52:18
!topic Proposed Final freeze exceptions
<@adamwill:fedora.im>
17:52:24
okay, so in the interests of time:
<@adamwill:fedora.im>
17:52:55
!info there are six proposed freeze exceptions. They are all Python libraries that fail to install due to being built against Python 3.12
<@adamwill:fedora.im>
17:54:00
proposed !agreed All six proposed FEs - 2291477 , 2291818 , 2275052 , 2291961 , 2301218 , 2283616 - are accepted as they are fails-to-install bugs and by precedent we accept these if there are no unusual factors involved, to keep the frozen tree as installable as possible
<@farribeiro:matrix.org>
17:54:07
ack
<@adamwill:fedora.im>
17:54:15
consider an ack as an implied +1
<@adamwill:fedora.im>
17:54:25
if you're -1 on any of the bugs, vote nack or patch
<@derekenz:fedora.im>
17:54:26
ack
<@kparal:matrix.org>
17:54:58
ack
<@lruzicka:matrix.org>
17:55:05
ack
<@pboy:fedora.im>
17:55:20
ack
<@geraldosimiao:matrix.org>
17:55:30
Ack
<@adamwill:fedora.im>
17:55:41
!agreed All six proposed FEs - 2291477 , 2291818 , 2275052 , 2291961 , 2301218 , 2283616 - are accepted as they are fails-to-install bugs and by precedent we accept these if there are no unusual factors involved, to keep the frozen tree as installable as possible
<@adamwill:fedora.im>
17:55:44
okay
<@adamwill:fedora.im>
17:55:54
!topic Accepted blockers
<@adamwill:fedora.im>
17:56:07
!info 2311936 and 2282171 are VERIFIED, just need pushing / closing
<@adamwill:fedora.im>
17:56:21
!info 2317287 is ASSIGNED, so the anaconda team has taken responsibility for working on it
<@adamwill:fedora.im>
17:56:23
any other notes?
<@adamwill:fedora.im>
17:57:17
!topic Open floor
<@adamwill:fedora.im>
17:57:20
any other business?
<@geraldosimiao:matrix.org>
17:57:45
Nope
<@derekenz:fedora.im>
17:57:52
All good
<@adamwill:fedora.im>
17:58:12
thanks folks
<@zodbot:fedora.im>
17:58:37
farribeiro has already given cookies to adamwill during the F40 timeframe
<@zodbot:fedora.im>
17:58:43
kparal gave a cookie to adamwill. They now have 258 cookies, 16 of which were obtained in the Fedora 40 release cycle
<@adamwill:fedora.im>
17:59:29
!endmeeting