<@adamwill:fedora.im>
17:00:40
!startmeeting F40-blocker-review
<@meetbot:fedora.im>
17:00:41
Meeting started at 2024-03-04 17:00:40 UTC
<@meetbot:fedora.im>
17:00:41
The Meeting name is 'F40-blocker-review'
<@adamwill:fedora.im>
17:00:44
!topic Roll Call
<@nielsenb:fedora.im>
17:00:57
!hi
<@zodbot:fedora.im>
17:00:58
Brandon Nielsen (nielsenb)
<@conan_kudo:matrix.org>
17:01:31
!hi
<@zodbot:fedora.im>
17:01:33
Neal Gompa (ngompa) - he / him / his
<@frantisekz:fedora.im>
17:01:51
!hi
<@zodbot:fedora.im>
17:01:52
František Zatloukal (frantisekz)
<@coremodule:fedora.im>
17:01:54
Willing to act as secretary.
<@adamwill:fedora.im>
17:02:08
hi hi everyone
<@adamwill:fedora.im>
17:02:10
thanks coremodule
<@pboy:fedora.im>
17:03:12
!hi
<@zodbot:fedora.im>
17:03:12
Peter Boy (pboy)
<@adamwill:fedora.im>
17:04:01
which part
<@frantisekz:fedora.im>
17:04:52
none apparently 🫣😄
<@adamwill:fedora.im>
17:05:17
hehe
<@adamwill:fedora.im>
17:05:20
alrighty, let's get rolling
<@adamwill:fedora.im>
17:05:25
boilerplate alert
<@adamwill:fedora.im>
17:05:32
!topic Introduction
<@adamwill:fedora.im>
17:05:35
Why are we here?
<@adamwill:fedora.im>
17:05:38
!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>
17:05:41
!info We'll be following the process outlined at:
<@adamwill:fedora.im>
17:05:44
!link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
<@adamwill:fedora.im>
17:05:47
!info The bugs up for review today are available at:
<@adamwill:fedora.im>
17:05:49
!link http://qa.fedoraproject.org/blockerbugs/current
<@adamwill:fedora.im>
17:05:52
!info The criteria for release blocking bugs can be found at:
<@adamwill:fedora.im>
17:05:55
!link https://fedoraproject.org/wiki/Basic_Release_Criteria
<@adamwill:fedora.im>
17:05:57
!link https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria
<@adamwill:fedora.im>
17:05:59
!link https://fedoraproject.org/wiki/Fedora_40_Final_Release_Criteria
<@adamwill:fedora.im>
17:06:07
!info for Beta, we have:
<@adamwill:fedora.im>
17:06:11
!info 6 Accepted Blockers
<@adamwill:fedora.im>
17:06:14
!info 1 Accepted Previous Release Blockers
<@adamwill:fedora.im>
17:06:17
!info 4 Proposed Freeze Exceptions
<@adamwill:fedora.im>
17:06:20
!info 6 Accepted Freeze Exceptions
<@adamwill:fedora.im>
17:06:25
!info for Final, we have:
<@adamwill:fedora.im>
17:06:34
!info 3 Proposed Blockers
<@adamwill:fedora.im>
17:06:44
as there are no proposed Beta blockers, let's get started with:
<@adamwill:fedora.im>
17:06:48
!topic Proposed Beta freeze exceptions
<@adamwill:fedora.im>
17:06:59
!topic (2267486) Include Java 21 as system Java Change in Fedora 40 Beta
<@adamwill:fedora.im>
17:07:03
!link https://bugzilla.redhat.com/show_bug.cgi?id=2267486
<@adamwill:fedora.im>
17:07:05
!link https://pagure.io/fedora-qa/blocker-review/issue/1488
<@adamwill:fedora.im>
17:07:07
!info Proposed Freeze Exceptions, distribution, NEW
<@adamwill:fedora.im>
17:07:10
!info Ticket vote: BetaFreezeException (+2,0,-0) (+nielsenb, +frantisekz)
<@adamwill:fedora.im>
17:07:34
so honestly i'm not personally super happy with this. this is appearing very late. to make the early release target we need an image by tomorrow or wednesday at the latest
<@adamwill:fedora.im>
17:08:04
but given the choices of landing it now, landing it after beta, or unpicking the SCM commits...none of them looks great.
<@nielsenb:fedora.im>
17:08:22
Aren't we likely snagged on shim anyway?
<@adamwill:fedora.im>
17:08:34
i'm assuming we'd waive shim if it can't be ready in time
<@frantisekz:fedora.im>
17:08:36
we're going to waive that imo
<@nielsenb:fedora.im>
17:08:43
*sigh*
<@adamwill:fedora.im>
17:08:51
i've asked pjones for a status update
<@frantisekz:fedora.im>
17:08:53
it may be ready for final
<@frantisekz:fedora.im>
17:09:07
but blocking beta on this doesn't make much sense
<@conan_kudo:matrix.org>
17:09:10
can we just stop waiving it?
<@conan_kudo:matrix.org>
17:09:23
I'm tired of waiving it especially now it's becoming more problematic
<@frantisekz:fedora.im>
17:09:24
we'd be stuck on f36 in that case... :D
<@adamwill:fedora.im>
17:09:26
i agree with František Zatloukal for beta at least
<@adamwill:fedora.im>
17:09:51
Conan Kudo: what's the alternative? we all sit on our hands till the great sb signing machine cranks its gears?
<@nielsenb:fedora.im>
17:09:51
I don't think we're blocking on this, just FE
<@conan_kudo:matrix.org>
17:09:53
realistically, we're going to waive it again at final :(
<@adamwill:fedora.im>
17:10:05
but anyhow, that's not the topic we're on
<@nielsenb:fedora.im>
17:10:42
All <del>gas</del> Java, no brakes
<@adamwill:fedora.im>
17:11:00
i'm probably gonna vote 0 on this because i don't really love any of the alternives
<@adamwill:fedora.im>
17:11:09
i'm probably gonna vote 0 on this because i don't really love any of the alternatives
<@nielsenb:fedora.im>
17:11:28
That's why I'm +1, everything else sucks more, but I can see a +0 too
<@nielsenb:fedora.im>
17:13:19
If it's going to break something, I would like it to start breaking stuff with the first beta
<@adamwill:fedora.im>
17:13:25
please don't everyone vote 0, we'll never get anywhere. :P
<@adamwill:fedora.im>
17:13:29
do as i say, not as i do!
<@frantisekz:fedora.im>
17:13:31
I am staying with +1 as in the ticket (also, thanks a lot adamw for fighting with the outfall in rawhide)
<@pboy:fedora.im>
17:14:03
+1 from me too, we need Java as planned
<@nielsenb:fedora.im>
17:14:04
I'm also still +1
<@adamwill:fedora.im>
17:15:59
i think that makes the vote +3
<@adamwill:fedora.im>
17:16:02
any other votes?
<@amoloney:fedora.im>
17:17:29
fwiw I'd be +1
<@amoloney:fedora.im>
17:18:07
maintainers seem highly engaged, they would likely be quite responsive to issues if any come up (fingers crossed things wont break though)
<@nirik:matrix.scrye.com>
17:18:48
This seems like more than an FE really, but I can be a weak +1 I guess... just landing it seems the least bad.
<@nielsenb:fedora.im>
17:19:09
More testing, more betterer
<@adamwill:fedora.im>
17:19:10
proposed 1agreed 2267486 AcceptedFreezeException (Beta) - this is reluctantly accepted on the grounds that we don't really prefer the alternatives of landing it after Beta or unpicking the SCM changes, and on the Java team's assurance that they have tested the changes
<@adamwill:fedora.im>
17:19:21
nirik: yeah, it really needs fesco signoff too, I guess
<@adamwill:fedora.im>
17:19:31
proposed !agreed 2267486 AcceptedFreezeException (Beta) - this is reluctantly accepted on the grounds that we don't really prefer the alternatives of landing it after Beta or unpicking the SCM changes, and on the Java team's assurance that they have tested the changes
<@adamwill:fedora.im>
17:19:35
when's the fesco meeting again?
<@amoloney:fedora.im>
17:19:40
today
<@nirik:matrix.scrye.com>
17:19:44
later today as it happens.
<@adamwill:fedora.im>
17:19:45
yes, what time i meant
<@nirik:matrix.scrye.com>
17:20:04
2 hours from now?
<@amoloney:fedora.im>
17:20:07
sorry 1930 UTC I think
<@adamwill:fedora.im>
17:20:13
okay
<@adamwill:fedora.im>
17:20:20
maybe we can make it a conditional acceptance?
<@adamwill:fedora.im>
17:20:46
proposed !agreed 2267486 AcceptedFreezeException (Beta), conditional on FESCo approval - this is reluctantly accepted on the grounds that we don't really prefer the alternatives of landing it after Beta or unpicking the SCM changes, and on the Java team's assurance that they have tested the changes. As this is a late Change, it also requires FESCo approval at the meeting later today
<@adamwill:fedora.im>
17:20:50
proposal adjusted
<@frantisekz:fedora.im>
17:21:21
ack
<@nielsenb:fedora.im>
17:21:41
How is it a late change?
<@nielsenb:fedora.im>
17:21:54
The original change was accepted by Fesco 2 months ago
<@nielsenb:fedora.im>
17:22:02
It just didn't land
<@adamwill:fedora.im>
17:22:10
Brandon Nielsen: it's a late Change. the testable and complete deadlines both passed already.
<@nielsenb:fedora.im>
17:22:18
Ah, I see
<@adamwill:fedora.im>
17:22:24
the implementation of the Change is late, not its proposal
<@nielsenb:fedora.im>
17:22:34
ack
<@adamwill:fedora.im>
17:23:17
any more acks?
<@coremodule:fedora.im>
17:23:22
ack
<@pboy:fedora.im>
17:23:31
ack
<@adamwill:fedora.im>
17:24:03
!agreed 2267486 AcceptedFreezeException (Beta), conditional on FESCo approval - this is reluctantly accepted on the grounds that we don't really prefer the alternatives of landing it after Beta or unpicking the SCM changes, and on the Java team's assurance that they have tested the changes. As this is a late Change, it also requires FESCo approval at the meeting later todayy
<@adamwill:fedora.im>
17:24:05
gah
<@adamwill:fedora.im>
17:24:08
!undo
<@adamwill:fedora.im>
17:24:33
....well now i don't know where we are.
<@adamwill:fedora.im>
17:24:41
!agreed 2267486 AcceptedFreezeException (Beta), conditional on FESCo approval - this is reluctantly accepted on the grounds that we don't really prefer the alternatives of landing it after Beta or unpicking the SCM changes, and on the Java team's assurance that they have tested the changes. As this is a late Change, it also requires FESCo approval at the meeting later today
<@amoloney:fedora.im>
17:24:49
you might be able to edit the agreed statement directly
<@adamwill:fedora.im>
17:24:52
there, if we get two, we get two
<@adamwill:fedora.im>
17:24:56
yes, but I don't know if meetbot understands that
<@amoloney:fedora.im>
17:25:07
oh I see...!
<@adamwill:fedora.im>
17:25:18
i didn't get a thumbs-up on the undo so i dunno where meetbot is at
<@adamwill:fedora.im>
17:25:28
i figured possibly having two agreeds is better than possibly having none
<@adamwill:fedora.im>
17:25:30
aaaanyhoo
<@adamwill:fedora.im>
17:25:31
!topic (2267713) intel-media-driver-free inclusion in F40+ breaks system upgrades for users with media-driver in F<=39
<@adamwill:fedora.im>
17:25:35
!link https://bugzilla.redhat.com/show_bug.cgi?id=2267713
<@adamwill:fedora.im>
17:25:38
!link https://pagure.io/fedora-qa/blocker-review/issue/1492
<@adamwill:fedora.im>
17:25:42
!info Proposed Freeze Exceptions, intel-media-driver-free, MODIFIED
<@frantisekz:fedora.im>
17:26:03
so, that is my package and my fe, fire questions away :)
<@adamwill:fedora.im>
17:26:39
since they no longer explicitly conflict, what happens if you wind up with both? which wins?
<@frantisekz:fedora.im>
17:27:17
yeah, that is to be figured out, I asked kwizart in the pr, but didn't get answer (and didn't actually test that)
<@conan_kudo:matrix.org>
17:27:20
freeworld does
<@conan_kudo:matrix.org>
17:27:33
nonfree -> freeworld -> regular, is what I think he's doing
<@conan_kudo:matrix.org>
17:27:49
https://src.fedoraproject.org/rpms/libva/c/ce2dd11f52f21df134b19d5a3727f08b52756137?branch=rawhide
<@frantisekz:fedora.im>
17:27:55
which would be a desired outcome I guess? users with fullblown installed before the upgrade stay with it
<@nielsenb:fedora.im>
17:28:20
Is it documented somewhere what I give up by using the free one?
<@nielsenb:fedora.im>
17:28:31
I get confused by all the different Intel media drivers
<@frantisekz:fedora.im>
17:28:34
in my brain unfortunately, I'll work on thath
<@adamwill:fedora.im>
17:28:51
that's probably a good idea
<@adamwill:fedora.im>
17:29:05
you don't want people examining your brain too often, it gets sticky
<@frantisekz:fedora.im>
17:29:07
😅 , short tldr, the free one doesn't support non-free codecs and some post-process shaders, and unfortunately av1 due to bugs upstream
<@conan_kudo:matrix.org>
17:29:28
this will also fix the mesa-freeworld issue too
<@salimma:fedora.im>
17:29:33
.hi
<@adamwill:fedora.im>
17:29:41
alright. if you all reckon this is an improvement, since it affects upgrades, I'm +1 (we like to fix upgrade issues during the freeze as upgrades don't run with u-t enabled usually)
<@nielsenb:fedora.im>
17:29:51
I think I'm _supposed_ to use the other one on my hardware anyway, for some reason
<@nielsenb:fedora.im>
17:29:54
But yeah
<@conan_kudo:matrix.org>
17:29:57
+1 FE
<@nielsenb:fedora.im>
17:29:58
BetaFE +1
<@geraldosimiao:matrix.org>
17:30:37
Sorry I'm late.
<@geraldosimiao:matrix.org>
17:30:43
! Hi
<@adamwill:fedora.im>
17:30:53
hi geraldo!
<@geraldosimiao:matrix.org>
17:30:57
!hi
<@adamwill:fedora.im>
17:31:39
proposed !agreed #2267713 - AcceptedFreezeException (Beta) - this is accepted on the grounds that upgrades usually run without updates-testing enabled, and this is a significant issue for the fairly large number of folks with this driver installed from a third-party source
<@frantisekz:fedora.im>
17:31:49
ack
<@zodbot:fedora.im>
17:32:09
Geraldo S. Simião Kutz (geraldosimiao) - he / him / his
<@nielsenb:fedora.im>
17:32:21
ack
<@geraldosimiao:matrix.org>
17:32:43
Ack
<@adamwill:fedora.im>
17:33:07
!agreed #2267713 - AcceptedFreezeException (Beta) - this is accepted on the grounds that upgrades usually run without updates-testing enabled, and this is a significant issue for the fairly large number of folks with this driver installed from a third-party source
<@conan_kudo:matrix.org>
17:33:10
ack
<@adamwill:fedora.im>
17:33:16
!topic (2259571) F40FailsToInstall: libzypp
<@adamwill:fedora.im>
17:33:20
!link https://bugzilla.redhat.com/show_bug.cgi?id=2259571
<@adamwill:fedora.im>
17:33:22
!link https://pagure.io/fedora-qa/blocker-review/issue/1491
<@adamwill:fedora.im>
17:33:25
!info Proposed Freeze Exceptions, libzypp, MODIFIED
<@adamwill:fedora.im>
17:33:27
!info Ticket vote: BetaFreezeException (+1,0,-0) (+nielsenb)
<@frantisekz:fedora.im>
17:34:00
hmm, I don't know, we give out +1 to FTIs for Final
<@frantisekz:fedora.im>
17:34:05
but what's the gain for beta
<@adamwill:fedora.im>
17:34:06
Conan Kudo: put your hand on your copy of the btrfs handbook and swear you didn't sneak any other changes in there
<@conan_kudo:matrix.org>
17:34:16
I swear :)
<@adamwill:fedora.im>
17:34:22
František Zatloukal: same deal - upgrades run without u-t enabled
<@frantisekz:fedora.im>
17:34:31
yeah, fair point
<@adamwill:fedora.im>
17:34:33
so fti issues can prevent upgrade if you have the fti package installed
<@adamwill:fedora.im>
17:34:53
(unless you use `--allowerasing`, which is a bit dangerous)
<@frantisekz:fedora.im>
17:35:22
FE +1
<@conan_kudo:matrix.org>
17:35:33
boost is evil :/
<@geraldosimiao:matrix.org>
17:35:47
FE +1
<@adamwill:fedora.im>
17:36:13
+1 here too
<@nielsenb:fedora.im>
17:36:35
BetaFE +1
<@adamwill:fedora.im>
17:36:47
proposed #agreed 2259571 - AcceptedFreezeException (Beta) - this is accepted on the usual grounds that FTI issues can interfere with upgrades, so straightforward FTI fixes are typically accepted
<@frantisekz:fedora.im>
17:36:53
ack
<@geraldosimiao:matrix.org>
17:37:01
ack
<@nielsenb:fedora.im>
17:37:01
ack
<@adamwill:fedora.im>
17:37:42
!agreed 2259571 - AcceptedFreezeException (Beta) - this is accepted on the usual grounds that FTI issues can interfere with upgrades, so straightforward FTI fixes are typically accepted
<@adamwill:fedora.im>
17:37:46
you're all fired, you didn't notice the #
<@adamwill:fedora.im>
17:37:58
!topic (2266081) Consider LLVM 18 pull in during Beta Freeze
<@adamwill:fedora.im>
17:38:01
!link https://bugzilla.redhat.com/show_bug.cgi?id=2266081
<@adamwill:fedora.im>
17:38:05
!link https://pagure.io/fedora-qa/blocker-review/issue/1478
<@adamwill:fedora.im>
17:38:08
!info Proposed Freeze Exceptions, llvm, NEW
<@adamwill:fedora.im>
17:38:13
oh, but vote on this before security escorts you out. ;)
<@adamwill:fedora.im>
17:38:31
there is *always* a test
<@nhanlon:beeper.com>
17:38:39
🤔
<@adamwill:fedora.im>
17:38:57
František Zatloukal: so, well, this is still NEW
<@frantisekz:fedora.im>
17:39:01
so, i see this similarly to the java stuff we've started with
<@conan_kudo:matrix.org>
17:39:05
yeah
<@frantisekz:fedora.im>
17:39:16
the builds are basically ready to be pushed: https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=84965&order=-build_id&latest=1
<@frantisekz:fedora.im>
17:39:26
it is in rawhide since the last week
<@adamwill:fedora.im>
17:39:27
i would feel much happier if there was an update with +3 karma
<@adamwill:fedora.im>
17:39:33
note "if it is built sufficiently early in the freeze process" from the bug
<@frantisekz:fedora.im>
17:39:39
but
<@frantisekz:fedora.im>
17:39:53
I'd need https://bodhi.fedoraproject.org/updates/FEDORA-2024-fadeea3975 to be pushed under this/another FE for the LLVM to be able to land
<@frantisekz:fedora.im>
17:40:05
it needs spirv-llvm-translator rebuilt
<@frantisekz:fedora.im>
17:40:11
which requires the newer spirv-*
<@frantisekz:fedora.im>
17:40:20
that newer spirv is in f41 and f9
<@frantisekz:fedora.im>
17:40:22
*f39
<@adamwill:fedora.im>
17:42:05
it's just a lot of stuff. landing late. i'm really not happy with this or the java change. we need people to stick to schedules
<@frantisekz:fedora.im>
17:42:25
I mean, llvm people got better
<@adamwill:fedora.im>
17:42:28
but it's hard to say no to this after saying yes to java. which is another reason i hate saying yes to java.
<@frantisekz:fedora.im>
17:42:39
we used to argue about this before final go/no-go :D
<@nielsenb:fedora.im>
17:42:54
But is less testing really the right stick to get people to finish earlier?
<@adamwill:fedora.im>
17:43:10
the stick should be you don't get in the release
<@frantisekz:fedora.im>
17:43:17
and as a bonus, mesa isn't part of it now...
<@adamwill:fedora.im>
17:43:19
get it done by beta freeze or it's in the next cycle
<@conan_kudo:matrix.org>
17:43:22
well it will be
<@frantisekz:fedora.im>
17:43:30
it'll get rebuilt after the freeze, wouldn't it?
<@adamwill:fedora.im>
17:43:38
mesa not being part of it helps, sure
<@adamwill:fedora.im>
17:43:50
what will get rebuilt after the freeze?
<@frantisekz:fedora.im>
17:44:03
mesa against llvm 18
<@adamwill:fedora.im>
17:44:10
oh. great.
<@frantisekz:fedora.im>
17:44:37
but Conan Kudo may correct me here? mesa wasn't rebuilt in rawhide against llvm 18 yet, so I am extrapolating from that
<@adamwill:fedora.im>
17:44:48
i don't know why we bother having a change process at all! let's just let everyone land new major versions of everything two days before GA, that'll go fine
<@conan_kudo:matrix.org>
17:44:50
yes
<@conan_kudo:matrix.org>
17:45:11
adamw: don't get me started :/
<@nielsenb:fedora.im>
17:45:14
Are you proposing we add another "F"? "Finished on time"?
<@farchord:matrix.org>
17:45:20
Lol
<@humaton:fedora.im>
17:45:49
there is a special place in hell for people who ignore schedules
<@humaton:fedora.im>
17:46:06
and I have the heat knob
<@adamwill:fedora.im>
17:46:30
this just in, jednorozec is satan
<@nhanlon:beeper.com>
17:46:52
no no, just satan's hvac tech ;)
<@humaton:fedora.im>
17:46:57
adamw: just deputy for java corner of the hell
<@farchord:matrix.org>
17:47:26
Humans are evil enough, no need for a mythological creature lol
<@adamwill:fedora.im>
17:47:33
well, obviously that means lennart is satan, and the internet trolls were right all along!
<@conan_kudo:matrix.org>
17:47:45
oof
<@adamwill:fedora.im>
17:47:56
it all fits, people
<@adamwill:fedora.im>
17:48:12
alrighty. anyhow. votes? i vote "meh".
<@nielsenb:fedora.im>
17:48:20
BetaFE +1
<@conan_kudo:matrix.org>
17:48:23
I hate that you make too much sense here
<@frantisekz:fedora.im>
17:48:25
+1 from me :)
<@nielsenb:fedora.im>
17:48:29
I hate it to death, but that's my vote
<@conan_kudo:matrix.org>
17:48:31
+1 FE meh
<@adamwill:fedora.im>
17:48:52
i think, regardless, we need to set a harder policy in advance next cycle, notify it, and stick to it
<@frantisekz:fedora.im>
17:48:57
(the process thing, adamw do you need a separate fe for the spirv-* stuff? I can assign updates/reopen the bug just fine)
<@humaton:fedora.im>
17:49:08
+ meh
<@adamwill:fedora.im>
17:49:18
no, it doesn't need a separate FE if it's a necessary precursor. mark it as fixing the bug but *not* as 'close bugs on stable'.
<@pboy:fedora.im>
17:49:20
+1 too
<@frantisekz:fedora.im>
17:49:29
copy
<@conan_kudo:matrix.org>
17:50:28
adamw: we're going to need a harder stick to get LLVM folks to push earlier
<@conan_kudo:matrix.org>
17:50:53
they don't really want to, which is a huge part of the problem
<@frantisekz:fedora.im>
17:51:13
I believe the issue is a bit in the upstream schedule
<@frantisekz:fedora.im>
17:51:26
it can change api/abi in the rc cycle...
<@adamwill:fedora.im>
17:51:36
we can't really be synced with every upstream schedule
<@conan_kudo:matrix.org>
17:51:41
so does gcc and glibc and we do it anyway
<@adamwill:fedora.im>
17:51:44
i feel like sometimes we are just gonna have to accept that something hits late
<@conan_kudo:matrix.org>
17:51:50
and GNOME too
<@adamwill:fedora.im>
17:51:51
but anyhow. we can argue about that outside the meeting
<@adamwill:fedora.im>
17:52:10
GNOME's fine lately. 46 was in weeks ago,.
<@adamwill:fedora.im>
17:52:14
GNOME's fine lately. 46 was in weeks ago.
<@frantisekz:fedora.im>
17:52:19
speaking of which... watabout the 46 rc, shall I propose a FE?
<@conan_kudo:matrix.org>
17:52:26
yes
<@nielsenb:fedora.im>
17:52:34
Yay, VRR
<@conan_kudo:matrix.org>
17:52:44
yuup
<@conan_kudo:matrix.org>
17:52:53
now just get all the other things too :P
<@adamwill:fedora.im>
17:53:28
i think i woke up in a weird parallel universe where "freeze" means "that time where you land major changes to three core components of your product"
<@humaton:fedora.im>
17:54:02
yup this release cycle is like that
<@conan_kudo:matrix.org>
17:54:06
more than three :(
<@humaton:fedora.im>
17:54:09
everything is late
<@farchord:matrix.org>
17:54:17
Global warming. ‘Nuff said.
<@conan_kudo:matrix.org>
17:54:31
even my stuff is late despite my best efforts to do everything early/on-time
<@conan_kudo:matrix.org>
17:54:40
it was out of my control :(
<@adamwill:fedora.im>
17:55:50
so we have +3 right now, but one of them is from franta, and we *do* of course have a strict conflict-of-interest policy that is written down in the same place as the docs on the libva drivers
<@adamwill:fedora.im>
17:55:55
any other votes?
<@geraldosimiao:matrix.org>
17:56:20
+1
<@conan_kudo:matrix.org>
17:57:09
(funnily enough, if it weren't for F40 _itself_ being delayed due to mass build issues, I'd be in the same boat with KDE Plasma 6.0)
<@conan_kudo:matrix.org>
17:57:24
the schedule slipped enough that 6.0 GA landed before freeze'
<@conan_kudo:matrix.org>
17:57:26
the schedule slipped enough that 6.0 GA landed before freeze
<@geraldosimiao:matrix.org>
17:57:48
Reluctantly
<@conan_kudo:matrix.org>
17:57:54
yeah
<@adamwill:fedora.im>
17:58:00
i guess we should also make this subject to fesco approval
<@adamwill:fedora.im>
17:59:00
proposed !agreed 2266081 - AcceptedFreezeException (Beta) (conditional on FESCo approval) - this is reluctantly approved, along the same lines as the Java 21 approval, if FESCo also approves it
<@nielsenb:fedora.im>
17:59:11
ack
<@frantisekz:fedora.im>
17:59:24
ack
<@geraldosimiao:matrix.org>
17:59:34
ack
<@adamwill:fedora.im>
17:59:35
i also do not like the justification "Pulling it earlier may ease burden on the developers, QA and other parties that may come with pulling the change in after the beta release" - the alternative to "pulling it during freeze" should not be "pulling it after freeze" but "deferring it to the next release", in a properly-working process
<@nielsenb:fedora.im>
17:59:55
I agree
<@nielsenb:fedora.im>
18:00:16
But then we'll very rarely be "First" 🫤
<@adamwill:fedora.im>
18:00:30
i am sure we did not used to have so many of these cases
<@adamwill:fedora.im>
18:00:37
and we still had First as a foundation then
<@adamwill:fedora.im>
18:00:47
we can't land literally everything the day it's done. it's just not feasible. that's not what First should mean,.
<@conan_kudo:matrix.org>
18:00:52
we didn't have RHEL so tightly linked to Fedora before too
<@conan_kudo:matrix.org>
18:01:10
I remember F34 being similarly chaotic
<@nielsenb:fedora.im>
18:01:25
I think trying to sync to release schedules was a bit of a footgun
<@adamwill:fedora.im>
18:01:27
i don't think RHEL is driving the LLVM change. i've no idea about Java.
<@nielsenb:fedora.im>
18:01:46
Being 3 months out of sync might almost be better
<@nielsenb:fedora.im>
18:02:14
At least in regards to Gnome / KDE
<@conan_kudo:matrix.org>
18:02:41
well funnily enough KDE is eventually going to sync to our schedule :)
<@adamwill:fedora.im>
18:02:44
i'm not worried about gnome/kde
<@adamwill:fedora.im>
18:02:53
both of those are in fine
<@adamwill:fedora.im>
18:03:17
!agreed 2266081 - AcceptedFreezeException (Beta) (conditional on FESCo approval) - this is reluctantly approved, along the same lines as the Java 21 approval, if FESCo also approves it
<@adamwill:fedora.im>
18:03:22
anyhow, more fun
<@adamwill:fedora.im>
18:03:26
!topic (2267754) Include GNOME Shell (etc.) 46 rc1 in Fedora 40 Beta
<@adamwill:fedora.im>
18:03:28
!link https://bugzilla.redhat.com/show_bug.cgi?id=2267754
<@adamwill:fedora.im>
18:03:31
!link https://pagure.io/fedora-qa/blocker-review/issue/1493
<@adamwill:fedora.im>
18:03:33
!info Proposed Freeze Exceptions, distribution, NEW
<@adamwill:fedora.im>
18:03:38
ok, that's enough, i am -1 to this
<@conan_kudo:matrix.org>
18:03:48
oof
<@nielsenb:fedora.im>
18:03:49
But I was just told Gnome was fine
<@adamwill:fedora.im>
18:03:50
we have a GNOME 46 build. it is fine for Beta. this is not time for a new one.
<@adamwill:fedora.im>
18:03:58
yes. GNOME *is* fine. it does not need a new build.
<@conan_kudo:matrix.org>
18:04:03
but VRRRRRRRRRR
<@conan_kudo:matrix.org>
18:04:16
it's the thing everyone will talk about(tm)
<@adamwill:fedora.im>
18:04:18
you can get VRR with a zero-day update if you like
<@adamwill:fedora.im>
18:04:24
knock yourself out
<@adamwill:fedora.im>
18:04:33
it doesn't need to be in the images we are supposed to be building *tomorrow*
<@conan_kudo:matrix.org>
18:04:34
lol
<@frantisekz:fedora.im>
18:04:49
but don't you need that on live too? for super-smooth spinners!
<@adamwill:fedora.im>
18:04:58
there are a bunch of failures in the openQA tests for today's rawhide and i've no idea yet which of them are just needle updates and which might be real bugs
<@frantisekz:fedora.im>
18:05:05
(I am going to make that argument for hdr spinners in the future too!)
<@conan_kudo:matrix.org>
18:05:06
yup :P
<@adamwill:fedora.im>
18:05:22
https://openqa.fedoraproject.org/tests/2462612 looks worrying though
<@conan_kudo:matrix.org>
18:05:27
well okay, real failures is another issue
<@frantisekz:fedora.im>
18:06:01
I thought, it may make sense if we delay by one week to the #1 release target...
<@adamwill:fedora.im>
18:06:19
yeah, sure, we can reconsider if there's a slip, and we have better info on any bugs caused by this change by then
<@adamwill:fedora.im>
18:06:23
i am -1 to it today, for this week
<@frantisekz:fedora.im>
18:06:33
shouldn't we punt then?
<@conan_kudo:matrix.org>
18:06:55
yes
<@conan_kudo:matrix.org>
18:07:13
if it's a toss-up based on whether we slip or not, then we should punt
<@nielsenb:fedora.im>
18:07:22
Agreed
<@adamwill:fedora.im>
18:07:35
eh, it doesn't make much of a practical difference
<@frantisekz:fedora.im>
18:08:03
(for getting out of the radar maybe? it'd stay in the web app if it's punted... idk)
<@conan_kudo:matrix.org>
18:08:36
yeah, I'd rather it stay in the web app
<@adamwill:fedora.im>
18:11:30
so is that three votes for punt?
<@adamwill:fedora.im>
18:11:35
anyone else?
<@geraldosimiao:matrix.org>
18:13:03
Punt +1
<@pboy:fedora.im>
18:13:29
+1 too
<@adamwill:fedora.im>
18:15:32
okay
<@adamwill:fedora.im>
18:16:42
proposed !agreed 2267754 - punt (delay decision) - we do not want to accept this for a candidate to be built in the next day or two for release next week. that timeframe is too tight without any significant justification to pull in this update (and initial results from openQA suggesting it may cause at least one problem). we will reconsider this if the Beta release slips and we have more definite testing results by then
<@adamwill:fedora.im>
18:16:50
proposed !agreed #2267754 - punt (delay decision) - we do not want to accept this for a candidate to be built in the next day or two for release next week. that timeframe is too tight without any significant justification to pull in this update (and initial results from openQA suggesting it may cause at least one problem). we will reconsider this if the Beta release slips and we have more definite testing results by then
<@frantisekz:fedora.im>
18:17:00
ack
<@conan_kudo:matrix.org>
18:17:02
ack
<@nielsenb:fedora.im>
18:17:08
ack
<@geraldosimiao:matrix.org>
18:17:15
ack
<@adamwill:fedora.im>
18:17:28
!agreed #2267754 - punt (delay decision) - we do not want to accept this for a candidate to be built in the next day or two for release next week. that timeframe is too tight without any significant justification to pull in this update (and initial results from openQA suggesting it may cause at least one problem). we will reconsider this if the Beta release slips and we have more definite testing results by then
<@pboy:fedora.im>
18:17:29
ack
<@adamwill:fedora.im>
18:17:42
okay, moving on to:
<@adamwill:fedora.im>
18:17:46
!topic proposed Final blockers
<@adamwill:fedora.im>
18:17:56
!topic (2247872) Don't write /etc/lvm/devices/system.devices when not doing an end-user install
<@adamwill:fedora.im>
18:17:59
!link https://bugzilla.redhat.com/show_bug.cgi?id=2247872
<@adamwill:fedora.im>
18:18:02
!link https://pagure.io/fedora-qa/blocker-review/issue/1438
<@adamwill:fedora.im>
18:18:05
!info Proposed Blocker, anaconda, POST
<@adamwill:fedora.im>
18:18:08
!info Ticket vote: FinalBlocker (+0,0,-1) (-nielsenb)
<@adamwill:fedora.im>
18:18:29
where are we at with this, Peter Boy ?
<@pboy:fedora.im>
18:19:04
+1 from me :-) we need the outsanding fixes to make the VMs equal to the iso installation.
<@pboy:fedora.im>
18:19:42
It affects not only the aarch64 image, but specifically the default VM image, too.
<@pboy:fedora.im>
18:20:52
Unfortunately, these are the after-effects of a system-wide change that was not announced.
<@adamwill:fedora.im>
18:21:46
what is the exact concrete consequence if this isn't fixed?
<@pboy:fedora.im>
18:23:42
The default VM image will get unusable, unless you use a strict default KVM configuration. The same is true for aarch64, is you use direct installation (not arm-installer-image) which is a supported way for some boards, spec. Raspberrys
<@pboy:fedora.im>
18:24:04
Unsuable, because all the LVM administration tools doesn't work.
<@pboy:fedora.im>
18:24:41
And we would have different installation results depending on the media you use.
<@adamwill:fedora.im>
18:24:52
i don't see anything that could be described as "the default VM image" at https://docs.fedoraproject.org/en-US/releases/f40/blocking/
<@conan_kudo:matrix.org>
18:25:08
it's not release blocking
<@adamwill:fedora.im>
18:25:15
so that makes it hard for me to be +1 blocker. +1 FE, sure (though we're not in freeze yet for final)
<@conan_kudo:matrix.org>
18:25:37
+1 FE
<@frantisekz:fedora.im>
18:25:37
+1 FE for sure
<@nielsenb:fedora.im>
18:26:02
Isn't it only "unusable" in the sense you can't do LVM operations after the install, unless you modify a file?
<@pboy:fedora.im>
18:26:03
We have 3 standard way to distribute, dvd ise, net iso and VM wcow2
<@nielsenb:fedora.im>
18:26:10
The actual install succeeds
<@adamwill:fedora.im>
18:27:09
well, that's not what the release blocking image list says, and that's canonical...if server WG wants the qcow2 image to be release-blocking, I think that needs to be run by fesco for approval?
<@adamwill:fedora.im>
18:27:29
(other teams get a vote, like quality, because it means we have to do more testing)
<@adamwill:fedora.im>
18:27:57
as of right now, there is no openqa testing of the qcow2 image because it's not release blocking
<@geraldosimiao:matrix.org>
18:28:15
Sorry folks, must go now 😔
Bye
<@adamwill:fedora.im>
18:28:33
thanks geraldo!
<@frantisekz:fedora.im>
18:28:45
thanks, bye!
<@adamwill:fedora.im>
18:29:57
so, i'm -1 blocker/+1 fe on this. i don't think qcow2 can be release blocking for f40, the list is locked in for this release cycle.
<@pboy:fedora.im>
18:30:04
Practically, FE should be enough, as the fix is already half finished. But coming out with an inferior distribution image once again is garbage.
<@pboy:fedora.im>
18:30:21
F39 was bad enough.
<@adamwill:fedora.im>
18:30:55
then, the thing to do is to propose making the image release blocking, if you want this process as a backstop
<@pboy:fedora.im>
18:31:19
OK, that's for the next release, I sppose.
<@adamwill:fedora.im>
18:31:28
yes. file a fesco issue and we could change it for f41.
<@adamwill:fedora.im>
18:32:06
last i counted, we built over 80 images in each compose, and it's probably more than that by now. we can't block the release on every one of them, the list needs to exist for sanity's sake. :P
<@adamwill:fedora.im>
18:32:39
83!~
<@adamwill:fedora.im>
18:32:42
83!
<@adamwill:fedora.im>
18:32:54
(and that's just ones fedfind recognizes, some might have slipped in that it doesn't know about...I need to check)
<@pboy:fedora.im>
18:33:00
Not all may be equally important.
<@adamwill:fedora.im>
18:33:10
right, which is why we have the list.
<@adamwill:fedora.im>
18:33:18
any other votes?
<@nielsenb:fedora.im>
18:33:31
I'll hold my nose and vote
<@coremodule:fedora.im>
18:33:33
+1FE, -1 blocker
<@nielsenb:fedora.im>
18:33:37
FinalBlocker -1
<@nielsenb:fedora.im>
18:33:40
FinalFE +1
<@adamwill:fedora.im>
18:35:23
proposed !agreed 2247872 RejectedBlocker (Final) AcceptedFreezeException (Final) - this cannot block the release as it affects the qcow2 image only, which is not in the release-blocking list for Fedora 40. As it's a significant issue in a non-blocking image, we grant it a freeze exception
<@conan_kudo:matrix.org>
18:35:41
ack
<@coremodule:fedora.im>
18:35:48
ack
<@nielsenb:fedora.im>
18:35:52
ack
<@adamwill:fedora.im>
18:35:59
!agreed 2247872 RejectedBlocker (Final) AcceptedFreezeException (Final) - this cannot block the release as it affects the qcow2 image only, which is not in the release-blocking list for Fedora 40. As it's a significant issue in a non-blocking image, we grant it a freeze exception
<@adamwill:fedora.im>
18:36:06
!topic (2266050) [abrt] plasma-workspace-libs: _execute_child(): subprocess.py:1953:_execute_child:FileNotFoundError: [Errno 2] No such file or directory: 'qtpaths'
<@adamwill:fedora.im>
18:36:16
!link https://bugzilla.redhat.com/show_bug.cgi?id=2266050
<@adamwill:fedora.im>
18:36:19
!link https://pagure.io/fedora-qa/blocker-review/issue/1481
<@adamwill:fedora.im>
18:36:21
!info Proposed Blocker, plasma-workspace, NEW
<@adamwill:fedora.im>
18:36:24
!info Ticket vote: FinalBlocker (+1,0,-0) (+nielsenb)
<@adamwill:fedora.im>
18:37:17
this isn't a 'system service' within the meaning of the act
<@adamwill:fedora.im>
18:37:22
(afaik anyway)
<@adamwill:fedora.im>
18:37:43
but could be a violation of https://fedoraproject.org/wiki/Fedora_40_Final_Release_Criteria#SELinux_and_crash_notifications if there's a notification
<@adamwill:fedora.im>
18:38:15
lruzicka: around to clarify?
<@nielsenb:fedora.im>
18:38:38
If it makes it to libreport, shouldn't it appear in abrt?
<@adamwill:fedora.im>
18:38:58
the bug kinda implies people are seeing a notification, but it'd be nice to be sure
<@adamwill:fedora.im>
18:39:00
i don't think openqa is
<@adamwill:fedora.im>
18:39:23
https://openqa.fedoraproject.org/tests/2463555#step/desktop_notifications/31
<@nielsenb:fedora.im>
18:39:54
I don't think I saw this the last time I tested a KDE image, but that was a bit ago now
<@adamwill:fedora.im>
18:40:16
maybe punt for info?
<@frantisekz:fedora.im>
18:40:45
yeah, let's punt
<@nielsenb:fedora.im>
18:41:00
I'm okay with punting
<@conan_kudo:matrix.org>
18:41:49
I'm fine with punting
<@adamwill:fedora.im>
18:43:22
alrighty
<@adamwill:fedora.im>
18:44:07
proposed !agreed 266050 - punt (delay decision) - it's not clear if a system service is actually failing here (as defined in the criterion and test case), or if this may alternatively be a violation of https://fedoraproject.org/wiki/Fedora_40_Final_Release_Criteria#SELinux_and_crash_notifications . We'll delay the decision to ask lruzicka for more information
<@nielsenb:fedora.im>
18:44:19
ack
<@frantisekz:fedora.im>
18:44:25
ack
<@conan_kudo:matrix.org>
18:44:56
ack
<@adamwill:fedora.im>
18:45:03
!agreed 266050 - punt (delay decision) - it's not clear if a system service is actually failing here (as defined in the criterion and test case), or if this may alternatively be a violation of https://fedoraproject.org/wiki/Fedora_40_Final_Release_Criteria#SELinux_and_crash_notifications . We'll delay the decision to ask lruzicka for more information
<@adamwill:fedora.im>
18:45:10
!topic (2248071) systemd-oomd doesn't kick in on high memory pressure, leading to system lockup
<@adamwill:fedora.im>
18:45:13
!link https://bugzilla.redhat.com/show_bug.cgi?id=2248071
<@adamwill:fedora.im>
18:45:15
!link https://pagure.io/fedora-qa/blocker-review/issue/1454
<@adamwill:fedora.im>
18:45:18
!info Proposed Blocker, systemd, NEW
<@adamwill:fedora.im>
18:45:20
!info Ticket vote: FinalBlocker (+0,0,-2) (-nielsenb, -catanzaro)
<@nielsenb:fedora.im>
18:46:45
I would like to know why systemd-oomd doesn't kick in
<@nielsenb:fedora.im>
18:46:53
But I don't really see how it can be a blocker
<@adamwill:fedora.im>
18:47:17
yeah...there just doesn't seem to be enough buzz around this
<@adamwill:fedora.im>
18:47:31
it's one of those things where i feel like if there was a serious widespread problem, more people would be complaining
<@adamwill:fedora.im>
18:47:35
has anyone here had issues?
<@nielsenb:fedora.im>
18:47:48
I mean, none of us managed to make systemd-oomd kick in, did we?
<@nielsenb:fedora.im>
18:47:56
We all got the kernel killer
<@frantisekz:fedora.im>
18:48:37
I am usually also not hitting the mem + swap limit (which is around 42 gigs in total, and I learned to close my chrome before building huge things... :D )
<@adamwill:fedora.im>
18:48:40
not with the specific reproducer from the bug, i guess
<@adamwill:fedora.im>
18:49:05
i suppose i mostly try to avoid getting into the situation where *any* oom killer should kick in...:P
<@nielsenb:fedora.im>
18:49:11
Yeah
<@adamwill:fedora.im>
18:49:23
still...is it a release blocking bug if systemd-oomd never works? it's hard to see how, really
<@nielsenb:fedora.im>
18:49:29
Just because I can reproduce the issue, doesn't mean I have a problem
<@adamwill:fedora.im>
18:50:33
we released a whole lot of releases without systemd-oomd at all!
<@adamwill:fedora.im>
18:50:58
it's kinda easier to see "systemd-oomd kills too many things" as a blocker than "it doesn't kill enough things"
<@nielsenb:fedora.im>
18:51:14
I agree
<@adamwill:fedora.im>
18:51:48
any other thoughts?
<@conan_kudo:matrix.org>
18:53:03
I think it's easier to say that this is a problem if it results in hangs or freezes
<@conan_kudo:matrix.org>
18:53:14
but if that's not happening, it's... less an issue
<@adamwill:fedora.im>
18:55:09
well, that's what the reporters upstream say, but still...if you run your system out of memory, something bad is gonna happen, is the bottom line
<@adamwill:fedora.im>
18:55:17
maybe something gets killed, maybe the whole thing freezes
<@adamwill:fedora.im>
18:55:28
i have a difficult time calling any particular result in that situation *release blocking*
<@adamwill:fedora.im>
18:55:34
so i'm -1 to this
<@frantisekz:fedora.im>
18:56:00
yeah, great description for rejecting, -1
<@nielsenb:fedora.im>
18:56:51
Yeah
<@nielsenb:fedora.im>
18:56:56
I'm still FinalBlocker -1
<@conan_kudo:matrix.org>
18:57:14
-1
<@adamwill:fedora.im>
18:57:50
proposed !agreed #2248071 - RejectedBlocker (Final) - we can't find a justification for calling this a release blocker. Even if systemd-oomd never kicks in at all, we have no release criteria covering what should happen if you run your system out of memory, and it will always be *something* bad. There's no requirement in Fedora that the bad thing be "systemd kills an app" rather than "the kernel kills an app" or "everything seizes up".
<@frantisekz:fedora.im>
18:58:15
ack
<@nielsenb:fedora.im>
18:58:18
ack
<@coremodule:fedora.im>
18:58:51
ack
<@conan_kudo:matrix.org>
18:59:00
ack
<@adamwill:fedora.im>
19:00:00
!agreed #2248071 - RejectedBlocker (Final) - we can't find a justification for calling this a release blocker. Even if systemd-oomd never kicks in at all, we have no release criteria covering what should happen if you run your system out of memory, and it will always be something bad. There's no requirement in Fedora that the bad thing be "systemd kills an app" rather than "the kernel kills an app" or "everything seizes up".
<@adamwill:fedora.im>
19:00:05
okay, and we're at time
<@adamwill:fedora.im>
19:00:08
very quickly:
<@adamwill:fedora.im>
19:00:27
!info accepted Beta blocker status - I'm poking the artwork team, I'm poking pjones for shim, and I'm poking pbrobinson for ARM. lots of poking is occurring
<@adamwill:fedora.im>
19:00:41
!topic Open floor
<@adamwill:fedora.im>
19:00:45
any other wildly important business?
<@frantisekz:fedora.im>
19:01:18
regarding the llvm/openjdk fesco approvals, shall I create a tickets so it doesn't get stuck?
<@adamwill:fedora.im>
19:01:39
i was hoping nirik would ensure it gets brought up
<@adamwill:fedora.im>
19:02:06
there is a "#3173 F40 Change Proposal Status: Incomplete Changes" topic on the agenda
<@adamwill:fedora.im>
19:02:09
which should be the place
<@nirik:matrix.scrye.com>
19:02:13
I can try and remember... thats a whole 30min from now!
<@adamwill:fedora.im>
19:02:22
i'll be there too
<@nirik:matrix.scrye.com>
19:02:28
(the llvm one is pretty expected I think)
<@frantisekz:fedora.im>
19:03:03
okey dokey, thanks to anybody who'd remind that, if there's any comment needed from me (for llvm), please do feel free to ping
<@frantisekz:fedora.im>
19:03:53
coremodule: would you be able to handle the secretary duty before CET morning? I'll handle that tomorrow otherwise, no problem
<@adamwill:fedora.im>
19:04:47
i will handle the critical ones if necessary
<@frantisekz:fedora.im>
19:05:30
if you need/prefer them handled asap, otherwise don't overwork yourself 😁
<@adamwill:fedora.im>
19:06:20
alrighty, thanks for coming everyone!
<@frantisekz:fedora.im>
19:06:35
👋
<@adamwill:fedora.im>
19:08:25
!endmeeting