<@amoloney:fedora.im>
17:01:35
!startmeeting F40 Final Go/No-Go meeting
<@meetbot:fedora.im>
17:01:36
Meeting started at 2024-04-18 17:01:35 UTC
<@meetbot:fedora.im>
17:01:36
The Meeting name is 'F40 Final Go/No-Go meeting'
<@amoloney:fedora.im>
17:02:07
!topic Roll Call
<@amoloney:fedora.im>
17:02:08
!hi
<@farribeiro:matrix.org>
17:02:11
!hi
<@zodbot:fedora.im>
17:02:11
Aoife Moloney (amoloney)
<@zodbot:fedora.im>
17:02:14
Fábio Ribeiro (farribeiro) - he / him / his
<@adamwill:fedora.im>
17:02:25
!hi
<@zodbot:fedora.im>
17:02:27
Adam Williamson (adamwill) - he / him / his
<@nirik:matrix.scrye.com>
17:02:48
morning
<@geraldosimiao:matrix.org>
17:02:48
!hi
<@zodbot:fedora.im>
17:02:51
Geraldo S. Simião Kutz (geraldosimiao) - he / him / his
<@coremodule:fedora.im>
17:03:41
!hello
<@zodbot:fedora.im>
17:03:42
Geoffrey Marr (coremodule)
<@amoloney:fedora.im>
17:03:51
!topic Purpose of this meeting
<@amoloney:fedora.im>
17:04:00
!info info Purpose of this meeting is to check whether or not F40 Final is ready for shipment, according to the release criteria.
<@amoloney:fedora.im>
17:04:13
!info This is determined in a few ways:
<@amoloney:fedora.im>
17:04:38
!info 1. Release candidate compose is available
<@amoloney:fedora.im>
17:04:50
!info 2. No remaining blocker bugs
<@amoloney:fedora.im>
17:05:06
!info 3.Test matrices are fully complete
<@amoloney:fedora.im>
17:05:17
!info 4. Fedora CoreOS & IoT are ready
<@amoloney:fedora.im>
17:05:31
now the good stuff
<@amoloney:fedora.im>
17:05:38
!topic Release candidate
<@amoloney:fedora.im>
17:05:47
Have we an RC to discuss today?
<@adamwill:fedora.im>
17:06:16
we have!
<@adamwill:fedora.im>
17:06:29
!info https://dl.fedoraproject.org/pub/alt/stage/40_RC-1.14/ is the current RC
<@nirik:matrix.scrye.com>
17:06:34
it's like... days old!
<@adamwill:fedora.im>
17:06:49
it probably smells
<@amoloney:fedora.im>
17:07:05
!info RC 1.14 is the release candidate that we will decide if Fedora Linux 40 will release with
<@amoloney:fedora.im>
17:07:14
Its like a fine wine
<@amoloney:fedora.im>
17:07:41
!topic Current Status - Blockers
<@adamwill:fedora.im>
17:08:04
ooo is it my turn
<@amoloney:fedora.im>
17:08:05
!link https://qa.fedoraproject.org/blockerbugs/milestone/40/final/buglist
<@amoloney:fedora.im>
17:08:22
Please welcome to the stage.... adamw !
<@adamwill:fedora.im>
17:08:26
yaaay
<@adamwill:fedora.im>
17:08:31
OK, let's start with proposed blockers
<@adamwill:fedora.im>
17:08:33
!topic (2275209) Intended final backgrounds for Fedora 40 are not included
<@zbyszek:fedora.im>
17:08:37
.hi
<@adamwill:fedora.im>
17:08:38
!link https://bugzilla.redhat.com/show_bug.cgi?id=2275209
<@adamwill:fedora.im>
17:08:41
!link https://pagure.io/fedora-qa/blocker-review/issue/1597
<@adamwill:fedora.im>
17:08:44
!info Proposed Blocker, f40-backgrounds, MODIFIED
<@adamwill:fedora.im>
17:08:47
!info Ticket vote: FinalBlocker (+0,0,-5) (-augenauf, -catanzaro, -kevin, -geraldosimiao, -lruzicka)
<@adamwill:fedora.im>
17:08:52
!info Ticket vote: FinalFreezeException (+3,0,-2) (+augenauf, +lruzicka, +kparal, -catanzaro, -geraldosimiao)
<@adamwill:fedora.im>
17:09:25
the criterion here is "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops"
<@frantisekz:fedora.im>
17:09:33
!hi
<@zodbot:fedora.im>
17:09:34
František Zatloukal (frantisekz)
<@adamwill:fedora.im>
17:09:38
up until yesterday I would have argued that technically this *is* a blocker (but we should waive it for being late)
<@nirik:matrix.scrye.com>
17:10:19
and today?
<@adamwill:fedora.im>
17:10:23
but since https://gitlab.com/groups/fedora/design/-/epics/32#note_1866027989 was posted, i think we can reasonably say the beta backgrounds are now the "intended" backgrounds again
<@adamwill:fedora.im>
17:10:27
yay logic!
<@nirik:matrix.scrye.com>
17:10:35
ah right. indeed.
<@adamwill:fedora.im>
17:10:45
so, i'll add my -1
<@amoloney:fedora.im>
17:10:50
I agree that we shouldnt delay for this when the Beta wallpaper is available (and beautiful)
<@adamwill:fedora.im>
17:10:51
anyone want to argue +1 before I propose?
<@geraldosimiao:matrix.org>
17:11:00
The bodhy update with this specific backgrounds was unpushed: I agree with mattdm and adamw. Based on feedback, I unpush the change and bring the reverted version. (luya)
<@amoloney:fedora.im>
17:11:00
-1 FB
<@frantisekz:fedora.im>
17:11:23
-1
<@geraldosimiao:matrix.org>
17:11:29
so even the mantainer thinks its a good idia to use the last background at f41
<@farribeiro:matrix.org>
17:11:37
-1 FB
<@adamwill:fedora.im>
17:13:27
proposed !agreed 2275209 - RejectedBlocker (Final) - this is rejected on the grounds that the design team now agrees the new backgrounds arrived too late, which makes the Beta backgrounds once more the "proposed final Fedora artwork". See https://gitlab.com/groups/fedora/design/-/epics/32#note_1866027989
<@nirik:matrix.scrye.com>
17:13:37
ack
<@geraldosimiao:matrix.org>
17:13:37
ack
<@farribeiro:matrix.org>
17:13:41
Ack
<@amoloney:fedora.im>
17:13:44
ack
<@frantisekz:fedora.im>
17:14:13
ack
<@adamwill:fedora.im>
17:14:17
!agreed 2275209 - RejectedBlocker (Final) - this is rejected on the grounds that the design team now agrees the new backgrounds arrived too late, which makes the Beta backgrounds once more the "proposed final Fedora artwork". See https://gitlab.com/groups/fedora/design/-/epics/32#note_1866027989
<@adamwill:fedora.im>
17:14:26
!topic (2275855) CVE-2024-2961 glibc: Out of bounds write in iconv may lead to remote code execution [fedora-all]
<@adamwill:fedora.im>
17:14:28
!link https://bugzilla.redhat.com/show_bug.cgi?id=2275855
<@adamwill:fedora.im>
17:14:30
!link https://pagure.io/fedora-qa/blocker-review/issue/1600
<@adamwill:fedora.im>
17:14:34
!info Proposed Blocker, glibc, ASSIGNED
<@adamwill:fedora.im>
17:14:58
thanks to Carlos O'Donell for being here to provide expert advice on this one (he is the glibc maintainer)
<@codonell:fedora.im>
17:15:08
:-)
<@adamwill:fedora.im>
17:15:17
the criterion here is "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop"
<@adamwill:fedora.im>
17:15:24
uhhh
<@adamwill:fedora.im>
17:15:25
no it isn't
<@zodbot:fedora.im>
17:15:36
farribeiro gave a cookie to codonell. They now have 3 cookies, 1 of which were obtained in the Fedora 39 release cycle
<@adamwill:fedora.im>
17:15:49
the criterion here is "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)"
<@nirik:matrix.scrye.com>
17:16:07
so, thats the question... ;)
<@geraldosimiao:matrix.org>
17:16:20
yeah: resolved by a package update
<@frantisekz:fedora.im>
17:16:25
"The issue can be satisfactorily resolved by a glibc package update."
<@adamwill:fedora.im>
17:16:25
per https://access.redhat.com/security/cve/CVE-2024-2961 this CVE *is* rated important. so the question is, can it be "satisfactorily resolved by a package update", which to me means, "is it plausibly exploitable against a person doing things we can reasonably anticipate they would do from a live or installer environment"
<@zodbot:fedora.im>
17:16:30
geraldosimiao gave a cookie to codonell. They now have 4 cookies, 2 of which were obtained in the Fedora 39 release cycle
<@adamwill:fedora.im>
17:17:09
i'd say any kind of exploit against a server is out (unless it's a server that is for some reason running in any of our live or installer environments)
<@codonell:fedora.im>
17:17:17
The issue is satisfactorily resolvable with a pakcage update IMO as a glibc package maintainer. The actions taken by a client during install are not exploitable IMO.
<@adamwill:fedora.im>
17:17:25
thanks a lot carlos
<@nirik:matrix.scrye.com>
17:17:31
good to hear.
<@adamwill:fedora.im>
17:17:42
with that evaluation i'd be -1 blocker
<@geraldosimiao:matrix.org>
17:17:46
yay
<@geraldosimiao:matrix.org>
17:17:54
FB -1
<@codonell:fedora.im>
17:17:55
We want to fix this ASAP for F40 for people running a Fedora 40 server though.
<@amoloney:fedora.im>
17:18:02
I would agree with the professionals :)
<@farribeiro:matrix.org>
17:18:33
-1 FB
<@geraldosimiao:matrix.org>
17:18:37
so: how to get this package to te stable repos at day 0? a zero-day blocker?
<@adamwill:fedora.im>
17:18:40
Carlos O'Donell: so, if you get an update queued ASAP we can get it some karma, and then it will be pushed when we unfreeze between this meeting and the release
<@adamwill:fedora.im>
17:19:02
we could make it a 0-day blocker but it doesn't seem worth the effort, a glibc update is gonna get plenty of karma and get in the queue
<@geraldosimiao:matrix.org>
17:19:06
or for the people doing system upgrades
<@nirik:matrix.scrye.com>
17:19:10
-1 Blocker just for the record.
<@adamwill:fedora.im>
17:19:18
i guess we can give nirik a note to try and do the 0-day push ASAP after this update is queued
<@bytehackr:matrix.org>
17:19:28
-1 FB
<@nirik:matrix.scrye.com>
17:19:38
we can't do that until we tag the final release and the last nightly finishes tho.
<@conan_kudo:matrix.org>
17:19:46
!hi
<@frantisekz:fedora.im>
17:19:47
-1 FB then
<@nirik:matrix.scrye.com>
17:19:48
so it would be sometime tomorrow
<@zodbot:fedora.im>
17:19:49
Neal Gompa (ngompa) - he / him / his
<@adamwill:fedora.im>
17:19:50
right, so i meant, do that bit as fast as possible :D
<@geraldosimiao:matrix.org>
17:20:04
0Day +1
<@codonell:fedora.im>
17:20:09
We, the glibc team, already have a Fedora 40 update queued, but we'll get another one to supersede that with the CVE fix ASAP.
<@adamwill:fedora.im>
17:20:20
Carlos O'Donell: sure, that's fine.
<@farribeiro:matrix.org>
17:20:29
0Day +1
<@nirik:matrix.scrye.com>
17:20:39
yeah, make sure to revoke the other one... so it doesn't _also_ go stable and possibly mistag
<@adamwill:fedora.im>
17:20:52
or just edit it with the new build
<@nirik:matrix.scrye.com>
17:21:02
sure
<@codonell:fedora.im>
17:21:10
Ah, good point.
<@adamwill:fedora.im>
17:22:10
seems like we have +2 for 0Day
<@adamwill:fedora.im>
17:22:22
to me it's a bit academic but we can go that way if we like...
<@zodbot:fedora.im>
17:23:33
ngompa gave a cookie to codonell. They now have 5 cookies, 3 of which were obtained in the Fedora 39 release cycle
<@nirik:matrix.scrye.com>
17:23:34
yeah, +0... I think it's pretty sure it will go before release day...
<@conan_kudo:matrix.org>
17:23:59
It's a toughie, but I think the "0Day" target is fine +1
<@adamwill:fedora.im>
17:24:43
proposed !agreed 2275855 - RejectedBlocker (Final) - this is rejected on the basis it can be "satisfactorily resolved by a package update", in the expert opinion of the glibc maintainer
<@nirik:matrix.scrye.com>
17:24:46
¯\_(ツ)_/¯ sure we can.
<@adamwill:fedora.im>
17:24:49
sigh
<@adamwill:fedora.im>
17:24:51
okay, revised proposal
<@geraldosimiao:matrix.org>
17:25:00
ack
<@geraldosimiao:matrix.org>
17:25:10
ok
<@farribeiro:matrix.org>
17:25:13
A k
<@farribeiro:matrix.org>
17:25:17
Ack
<@geraldosimiao:matrix.org>
17:25:24
whait Fabio
<@geraldosimiao:matrix.org>
17:25:33
he's reproposing
<@adamwill:fedora.im>
17:26:03
proposed !agreed 2275855 - Accepted0Day (Final) - this is accepted as a violation of the CVE criterion, but as a 0Day blocker because in the glibc maintainer's expert opinion, it is not likely to be exploitable against typical actions on live or installer media, so it is fine to resolve it with an update rather than a new candidate compose
<@nirik:matrix.scrye.com>
17:26:15
sure, ack
<@geraldosimiao:matrix.org>
17:26:24
ack
<@conan_kudo:matrix.org>
17:26:25
ack
<@farribeiro:matrix.org>
17:26:27
Ack
<@amoloney:fedora.im>
17:26:30
ack
<@adamwill:fedora.im>
17:26:32
Carlos O'Donell: (this makes no practical difference for you, don't worry)
<@adamwill:fedora.im>
17:26:46
!agreed 2275855 - Accepted0Day (Final) - this is accepted as a violation of the CVE criterion, but as a 0Day blocker because in the glibc maintainer's expert opinion, it is not likely to be exploitable against typical actions on live or installer media, so it is fine to resolve it with an update rather than a new candidate compose
<@adamwill:fedora.im>
17:27:16
!info let's revisit our outstanding 0-day blocker
<@adamwill:fedora.im>
17:27:27
!topic (2274830) Reinstate network service for Fedora 40
<@adamwill:fedora.im>
17:27:29
!link https://bugzilla.redhat.com/show_bug.cgi?id=2274830
<@adamwill:fedora.im>
17:27:31
!link https://pagure.io/fedora-qa/blocker-review/issue/1593
<@adamwill:fedora.im>
17:27:34
!info Accepted 0-day Blocker, initscripts, ON_QA
<@adamwill:fedora.im>
17:27:54
!info the update is queued for stable, so this is fine
<@adamwill:fedora.im>
17:28:02
!info let's revisit our outstanding previous release blocker
<@adamwill:fedora.im>
17:28:10
!topic (2242759) dnf system-upgrade fails on some RPi4 due to system boot date that pre-dates gpg key
<@adamwill:fedora.im>
17:28:13
!link https://bugzilla.redhat.com/show_bug.cgi?id=2242759
<@adamwill:fedora.im>
17:28:15
!link https://pagure.io/fedora-qa/blocker-review/issue/1435
<@adamwill:fedora.im>
17:28:18
!info Accepted Previous Release Blocker, distribution, NEW
<@adamwill:fedora.im>
17:28:25
okay, so, realistically, we aren't going to fix this, i don't think
<@nirik:matrix.scrye.com>
17:28:33
seems not.
<@adamwill:fedora.im>
17:28:39
i propose we either waive it or just reject it as unfixable at this point
<@adamwill:fedora.im>
17:28:46
we've been punting on it for, what, a cycle and a half
<@amoloney:fedora.im>
17:28:51
:(
<@adamwill:fedora.im>
17:29:01
i'm not a fan of the pantomime of keeping it around and waiving it forever
<@conan_kudo:matrix.org>
17:29:14
especially after we did it for shim...
<@conan_kudo:matrix.org>
17:29:26
we waived shim for at least three cycles :(
<@zbyszek:fedora.im>
17:29:27
I don't think it's unfixable. It's a real problem and a bunch of possible solutions were proposed. They are not even hard to implement.
<@amoloney:fedora.im>
17:29:33
can we just assign it to common bugs and call it at that?
<@amoloney:fedora.im>
17:29:48
or does it need to be a blocker bug every time?
<@adamwill:fedora.im>
17:29:49
yes, that's more or less what i'm proposing
<@conan_kudo:matrix.org>
17:29:53
well, let's try to see if we can get it fixed for F41
<@adamwill:fedora.im>
17:31:19
so the way I would argue it is: this is a conditional violation of the upgrade criteria (they are violated for systems with no RTC, once the system is old enough or whatever). conditional violations are subject to our subjective evaluation, per https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues?
<@geraldosimiao:matrix.org>
17:31:26
waive it just one more time and let's hope we have something for f41. If not then we can go with the other way...
<@adamwill:fedora.im>
17:31:39
one of the factors which we specifically list there is "The difficulty involved in fixing the issue: whether there is a significant chance that attempting to fix the issue could cause more serious problems"
<@adamwill:fedora.im>
17:32:22
i would propose we re-do our subjective evaluation of this bug and reject it as a blocker as it has been demonstrated that "the difficulty involved in fixing the issue" in this case is substantial and probably out of proportion to the benefit
<@adamwill:fedora.im>
17:32:40
it certainly is plausibly the case that any attempted fix for this could go wrong and break something else
<@conan_kudo:matrix.org>
17:32:46
the problem is that RPIs are basically our only blocking ARM hardware and are affected by this
<@conan_kudo:matrix.org>
17:33:03
so by definition it's widespread from our own criteria
<@adamwill:fedora.im>
17:33:09
still, i think it's reasonable to take a wider view
<@adamwill:fedora.im>
17:33:35
they're the most popular *arm* hardware, sure, but this is holding up the *entire fedora* release process each time and causing bureaucracy
<@adamwill:fedora.im>
17:34:09
so i'm willing to look at a wider context and say "we're not serving any purpose by pretending the block the entire release process on a problem with upgrading raspberry pis that nobody really seriously knows how to fix"
<@nirik:matrix.scrye.com>
17:34:33
I think we do know how to fix it, just no one has commited to/is doing that. ;)
<@adamwill:fedora.im>
17:34:47
i mean, there are ideas, but every time someone posts an idea someone else says "hmmm but"
<@amoloney:fedora.im>
17:34:54
while the problem could be viewed as widespread, how much of a widespread problem is it from the users? I would also agree with Adam on the larger issue of this blocking everything else
<@adamwill:fedora.im>
17:34:56
anyhoo, just my idea
<@adamwill:fedora.im>
17:35:17
if people disagree we can waive it again. or we can slip for a week and expect someone to fix it on monday!
<@amoloney:fedora.im>
17:35:26
no, waive
<@amoloney:fedora.im>
17:35:29
please :)
<@conan_kudo:matrix.org>
17:35:30
let's waive it please
<@conan_kudo:matrix.org>
17:35:35
no more delays, please
<@adamwill:fedora.im>
17:35:46
so i'm willing to look at a wider context and say "we're not serving any purpose by pretending to block the entire release process on a problem with upgrading raspberry pis that nobody really seriously knows how to fix"
<@nirik:matrix.scrye.com>
17:35:50
I think we definitely waive it... not sure about dropping it as a blocker. Would have to ponder on that some.
<@frantisekz:fedora.im>
17:36:02
or we could be slipping for a few months/years...
<@adamwill:fedora.im>
17:36:13
okay, it sounds like i didn't convince a ton of people to -1 this immediately, so...
<@zbyszek:fedora.im>
17:36:15
+1 to waiving
<@adamwill:fedora.im>
17:36:41
votes to waive it again as a "Difficult to fix blocker bug" per https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases ?
<@adamwill:fedora.im>
17:36:43
+1 waive
<@amoloney:fedora.im>
17:36:44
well Id be -1 FB, but concede to a +1 waive
<@geraldosimiao:matrix.org>
17:36:48
Waive +1
<@frantisekz:fedora.im>
17:36:49
let's waive then, we could decide in a stronger stance with f41
<@frantisekz:fedora.im>
17:36:54
+1 waive
<@nirik:matrix.scrye.com>
17:36:55
+1 waive
<@farribeiro:matrix.org>
17:37:41
Waive +1
<@adamwill:fedora.im>
17:37:45
proposed !agreed 2242759 - waived as a "difficult to fix blocker bug" per https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases - this is waived to Fedora 41 Beta for now, as we still have no clear solution proposed or firm timeline for one
<@frantisekz:fedora.im>
17:37:53
ack
<@geraldosimiao:matrix.org>
17:38:33
ack
<@sumantrom:fedora.im>
17:38:35
Ack
<@adamwill:fedora.im>
17:38:43
!agreed 2242759 - waived as a "difficult to fix blocker bug" per https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases - this is waived to Fedora 41 Beta for now, as we still have no clear solution proposed or firm timeline for one
<@adamwill:fedora.im>
17:38:52
okay, so:
<@adamwill:fedora.im>
17:39:18
!info we have no blockers that disqualify RC-1.14. We have two accepted 0-day blockers which are clearly on track to be fixed by release day
<@adamwill:fedora.im>
17:39:28
i think i can hand it back to Aoife Moloney
<@amoloney:fedora.im>
17:39:40
ooooh exciting!
<@amoloney:fedora.im>
17:39:57
now on to phase 3 of our cunning plan
<@geraldosimiao:matrix.org>
17:39:59
😁
<@amoloney:fedora.im>
17:40:04
!topic Test Matrices
<@adamwill:fedora.im>
17:40:07
underpants?!
<@adamwill:fedora.im>
17:40:11
aw
<@amoloney:fedora.im>
17:40:19
no :p
<@farribeiro:matrix.org>
17:40:20
Lost ack
<@geraldosimiao:matrix.org>
17:40:32
never mind
<@geraldosimiao:matrix.org>
17:40:39
averyone agreed
<@geraldosimiao:matrix.org>
17:40:48
everyone agreed
<@amoloney:fedora.im>
17:40:54
!link link https://fedoraproject.org/wiki/Category:Fedora_40_Test_Result
<@amoloney:fedora.im>
17:41:17
thats either not the link, or I have dropped it too early...
<@adamwill:fedora.im>
17:41:36
missing an s, i think
<@amoloney:fedora.im>
17:41:50
d'oh
<@geraldosimiao:matrix.org>
17:41:51
https://fedoraproject.org/wiki/Test_Results:Current_Summary
<@amoloney:fedora.im>
17:42:06
Thank you geraldosimiao
<@geraldosimiao:matrix.org>
17:42:19
😁👍️
<@conan_kudo:matrix.org>
17:42:32
!link https://fedoraproject.org/wiki/Test_Results:Current_Summary
<@amoloney:fedora.im>
17:42:58
are there any final tests that need to be run at this stage?
<@zodbot:fedora.im>
17:43:35
farribeiro has already given cookies to geraldosimiao during the F39 timeframe
<@adamwill:fedora.im>
17:43:40
i'm trying to get the arm cloud tests run
<@adamwill:fedora.im>
17:44:46
can't seem to connect to my instance, weirdly. guess i'll try creating it again
<@adamwill:fedora.im>
17:44:49
x86_64 instance was fine...
<@amoloney:fedora.im>
17:46:37
are there other ones aside from the arm cloud tests? Or are we just waiting on the results of those?
<@adamwill:fedora.im>
17:46:56
technically we seem to missing dual boot with macOS
<@amoloney:fedora.im>
17:47:02
i can set the topic to 'waiting' if we need a little time to cycle through the remaining one(s)
<@adamwill:fedora.im>
17:47:13
last run on 20240223.n.0
<@amoloney:fedora.im>
17:47:14
oh right
<@adamwill:fedora.im>
17:47:19
can anyone knock that one out?
<@geraldosimiao:matrix.org>
17:48:45
no macs here
<@nirik:matrix.scrye.com>
17:49:58
I have one in a closet somewhere, but I don't think it worked/booted on normal kernels... but that was years ago last I tried... not sure I could find it and test install with any speed.
<@adamwill:fedora.im>
17:50:23
a couple of results are missing because of openQA blips but same tests passed on nightlies, so those are fine...i'll fiddle those in the matrices
<@adamwill:fedora.im>
17:50:31
František Zatloukal: we have a mac somewhere don't we?
<@adamwill:fedora.im>
17:51:03
whew, finally got into my cloud instance. that was weird
<@adamwill:fedora.im>
17:51:14
i always seem to have weird issues with aws' firewalling. anyhoo
<@frantisekz:fedora.im>
17:51:16
nope, the one we had in the Brno office got lost in the office during the covid closures, Kamil Páral usually handled borrowing x86 mac from the it, forgot this time afaik
<@adamwill:fedora.im>
17:51:23
oh, fun
<@adamwill:fedora.im>
17:51:36
Conan Kudo: you got any lying around? :D
<@frantisekz:fedora.im>
17:51:44
non-arm :D
<@nirik:matrix.scrye.com>
17:52:03
cmurf had one at one point I think?
<@conan_kudo:matrix.org>
17:52:06
adamw: macs? yes I have one intel mac that I have Fedora running on it
<@conan_kudo:matrix.org>
17:52:10
it's an old one though
<@conan_kudo:matrix.org>
17:52:33
I blew away macOS a long time ago on it since Apple stopped supporting my 2009 MBP 😅
<@conan_kudo:matrix.org>
17:52:48
but Fedora runs great on it 😆
<@adamwill:fedora.im>
17:53:09
i guess you can't test a reinstall?
<@frantisekz:fedora.im>
17:53:22
the problem with the dualboot case unfortunately is that it needs a new install each time
<@frantisekz:fedora.im>
17:53:30
to test out grub2/os-prober/etc :(
<@adamwill:fedora.im>
17:53:38
the pass we have from february was from "osalbahr", dunno who that is
<@adamwill:fedora.im>
17:53:44
we might just have to go with that if nobody has test hw handy
<@cmurf:fedora.im>
17:54:04
my test hardware is in a box a couple thousand miles away
<@frantisekz:fedora.im>
17:54:19
we can wait a bit... :D
<@conan_kudo:matrix.org>
17:54:22
I don't have anything on hand...
<@adamwill:fedora.im>
17:54:28
i'm just finishing up the arm tests
<@cmurf:fedora.im>
17:55:09
does the release criteria require us to test it or only block on a known bug?
<@frantisekz:fedora.im>
17:55:23
we're required to test this
<@cmurf:fedora.im>
17:55:28
ha i guess we can only block on known bugs anyway 😛 no blocking on unknown bugs
<@frantisekz:fedora.im>
17:55:33
we block and not test just the cd/dvds
<@adamwill:fedora.im>
17:56:27
i think it's a 'required' test, but we can reasonably fuzz a bit for awkward hardware (like we used to do for enterprise storage till lnie solved that)
<@cmurf:fedora.im>
17:56:28
ok well if you need a thumbs up to waive and change the release criteria to block if known but not require a test, I'm on board - can't require things we can't do or no one stepping up to test it
<@adamwill:fedora.im>
17:56:41
i'm just stalling till i get the last cloud test done rn
<@conan_kudo:matrix.org>
17:57:06
🤣
<@geraldosimiao:matrix.org>
17:57:34
so we have this rc for a while and until now didn't get this specific dual boot test done
<@adamwill:fedora.im>
17:58:18
yeah, we should see if we can sort some hw for next cycle i guess
<@adamwill:fedora.im>
17:58:24
didn't realize we didn't have it in brno
<@adamwill:fedora.im>
17:58:38
sorry, i should've checked the matrices earlier, got distreacted
<@amoloney:fedora.im>
17:58:40
i have a macOS, and for the purposes of the next go/no-go meeting (in f41 cycle) if someone could help me make it dual-boot I could probably do this test
<@cmurf:fedora.im>
17:58:46
or in a box in cmurf's storage unit
<@adamwill:fedora.im>
17:59:44
Aoife Moloney: it really needs to be disposable test system, not your primary system
<@adamwill:fedora.im>
17:59:52
also yours is probably arm, not intel? if it's a recent one
<@adamwill:fedora.im>
17:59:55
an 'm' model
<@farchord:matrix.org>
17:59:58
You guys wanna test dual boot? I do have a dual boot machine on F40 already
<@cmurf:fedora.im>
18:00:05
although my mom has a 2012 macbook and I did recently (last two months) boot installation media, and it worked so while that's not proof it'll install and then boot, I'm pretty confident worst case I'd have to write up a common bugs work around
<@cmurf:fedora.im>
18:00:09
I've done that before
<@farchord:matrix.org>
18:00:12
and I do have a Winblows VM on qemu I could try adding a 2nd drive
<@adamwill:fedora.im>
18:00:19
Farchord [Fedora]: the test requires starting from a 'clean' macOS-only setup then testing that installing fedora alongside it works
<@amoloney:fedora.im>
18:00:22
well technically I use the slimbook for the day to day fedora-ing, but its an option if needed
<@adamwill:fedora.im>
18:00:26
we already have passes for windows tests
<@amoloney:fedora.im>
18:00:29
and its an m model
<@farchord:matrix.org>
18:00:31
Oh. Mac. Nvm
<@adamwill:fedora.im>
18:00:40
Aoife Moloney: M is no good for this test
<@amoloney:fedora.im>
18:00:41
rh-issued though
<@adamwill:fedora.im>
18:00:57
this test is specifically for Intel Macs. technically Fedora on ARM Macs isn't really a *thing* yet (it's still a remix)
<@amoloney:fedora.im>
18:00:59
oh well :)
<@adamwill:fedora.im>
18:01:14
at some point down the road we'll probably want to support Fedora on ARM Macs directly and make it blocking, but we're not there yet...
<@adamwill:fedora.im>
18:01:16
aaaanyhoo
<@cmurf:fedora.im>
18:01:44
there should be a testcase or howto reset a Mac back to 'clean' state without having to "nuke the Mac from orbit to be sure" - not sure where that write up is living these days
<@adamwill:fedora.im>
18:01:54
errr, did the wiki just fall over?
<@amoloney:fedora.im>
18:01:55
are we there with the arm cloud tests though now? ;)
<@adamwill:fedora.im>
18:02:01
yeah, they all passed
<@adamwill:fedora.im>
18:02:07
was just filling out results when the wiki went boom
<@adamwill:fedora.im>
18:02:10
hum, seems to be alive again
<@adamwill:fedora.im>
18:03:05
okay, done
<@adamwill:fedora.im>
18:03:06
so:
<@adamwill:fedora.im>
18:03:25
!info we are missing macOS dual boot test due to nobody having the hardware, we will have to trust that the pass in February is still valid
<@adamwill:fedora.im>
18:04:13
!info a couple of other tests are missing because they failed in openQA, the failures just look like blips, the same tests have since passed on nightlies that are identical to the RC. i'm re-running the failed tests ATM
<@adamwill:fedora.im>
18:04:35
!info other than those issues the matrices are substantially complete, i think we can consider the coverage complete
<@amoloney:fedora.im>
18:05:22
Nice! In that case, I will initiate phase 4 ....
<@amoloney:fedora.im>
18:05:43
!topic Fedora CoreOS & IoT Check in
<@amoloney:fedora.im>
18:06:08
dustymabe: are you around for the CoreOS seal of approval for F40?
<@adamwill:fedora.im>
18:06:35
coremodule: pwhalen Peter Robinson anyone here for IoT?
<@nirik:matrix.scrye.com>
18:06:40
They have a seal? Fancy! 🦭
<@coremodule:fedora.im>
18:06:41
yeah, I'm here
<@dustymabe:matrix.org>
18:06:41
👀
<@dustymabe:matrix.org>
18:07:12
we should be good from the FCOS side. `next` has been on F40 since the beta came out
<@adamwill:fedora.im>
18:07:19
coremodule: looks like the 0417.0 compose should be fine?
<@dustymabe:matrix.org>
18:07:19
our test day had good results
<@adamwill:fedora.im>
18:07:31
i believe it matches main package set exactly, and the prerelease warnings are gone
<@coremodule:fedora.im>
18:07:38
IoT tested OK, no issues. We'd like to use the 20240417.0 compose for our GA
<@amoloney:fedora.im>
18:07:45
oh brilliant dustymabe :)
<@adamwill:fedora.im>
18:07:57
i dunno why openqa didn't post results in the matrix, i'll take a look at that, but all the openqa tests passed
<@coremodule:fedora.im>
18:07:58
!link https://kojipkgs.fedoraproject.org/compose/iot/Fedora-IoT-40-20240417.0/
<@adamwill:fedora.im>
18:08:14
!link https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=40&build=Fedora-IoT-40-20240417.0&groupid=1
<@dustymabe:matrix.org>
18:08:41
adamw: we'll probably pick up the glibc CVE fix, though, since our users won't immediately `dnf upgrade` after they install
<@adamwill:fedora.im>
18:09:03
dustymabe: sure, seems reasoanble
<@adamwill:fedora.im>
18:09:08
equivalent to the 0-day push, really
<@adamwill:fedora.im>
18:09:17
okay, i've pushed the openqa results for IoT to the wiki now
<@adamwill:fedora.im>
18:09:21
!link https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_40_RC_20240417.0_General
<@adamwill:fedora.im>
18:09:29
so, looks like we're good for IoT and CoreOS
<@conan_kudo:matrix.org>
18:10:05
sweet
<@amoloney:fedora.im>
18:10:30
is...it time for the grand finale then..?🫣
<@adamwill:fedora.im>
18:11:03
i guess so!
<@amoloney:fedora.im>
18:11:19
!topic Go/No-Go Decision
<@geraldosimiao:matrix.org>
18:11:27
🚀
<@conan_kudo:matrix.org>
18:11:39
☘️
<@amoloney:fedora.im>
18:12:00
!info I will now poll each team for a Go or No-Go decision.
<@amoloney:fedora.im>
18:12:03
please reply
<@brianc07:fedora.im>
18:12:07
🚀️
<@amoloney:fedora.im>
18:12:08
Infra?
<@nirik:matrix.scrye.com>
18:12:16
go
<@amoloney:fedora.im>
18:12:29
they are a bonus poll :) sorr
<@amoloney:fedora.im>
18:12:32
FESCo?
<@nirik:matrix.scrye.com>
18:12:37
go
<@conan_kudo:matrix.org>
18:12:44
Go! 🚀
<@amoloney:fedora.im>
18:12:49
Rel-Eng?
<@nirik:matrix.scrye.com>
18:12:55
go
<@amoloney:fedora.im>
18:13:01
QA?
<@geraldosimiao:matrix.org>
18:13:06
go
<@adamwill:fedora.im>
18:13:18
go
<@amoloney:fedora.im>
18:13:27
We will now wear our party hats!!!! F40 is a GO!!!
<@amoloney:fedora.im>
18:13:47
!agreed Fedora Linux 40 Final is GO
<@geraldosimiao:matrix.org>
18:13:51
🎉
<@conan_kudo:matrix.org>
18:14:07
🎊
<@amoloney:fedora.im>
18:14:47
!info Fedora Linux 40 Final will release on the current target date (2024-04-23
<@adamwill:fedora.im>
18:15:01
yaaaay
<@amoloney:fedora.im>
18:15:03
well done everyone!
<@adamwill:fedora.im>
18:15:08
thanks everyone
<@conan_kudo:matrix.org>
18:15:18
we _did_ it
<@conan_kudo:matrix.org>
18:15:25
kind of on time even!
<@amoloney:fedora.im>
18:15:31
crazy little beta, lovely little final :)
<@conan_kudo:matrix.org>
18:15:32
that's a nice change from F39 :)
<@nirik:matrix.scrye.com>
18:16:01
I'm a bit surprised no one found any blockers this week, but happy too.
<@adamwill:fedora.im>
18:16:18
that just means the blockers are still lurking in there!
<@geraldosimiao:matrix.org>
18:16:21
Kamil its not the same...
<@geraldosimiao:matrix.org>
18:16:40
😁
<@amoloney:fedora.im>
18:17:28
we can all take a trip back down memory lane in the retro for this in a week or two... 😈
<@amoloney:fedora.im>
18:17:53
but really well done everyone and thank you for all the hard work and many many hours you've given
<@amoloney:fedora.im>
18:18:09
Im going to move this to open floor now while the credits roll
<@amoloney:fedora.im>
18:18:14
!topic Open Floor
<@amoloney:fedora.im>
18:18:27
any other business?
<@adamwill:fedora.im>
18:18:37
don't think i have anything...
<@geraldosimiao:matrix.org>
18:18:53
no more business for today
<@amoloney:fedora.im>
18:19:19
then with that....
<@amoloney:fedora.im>
18:19:25
!endmeeting