<@amoloney:fedora.im>
17:03:03
!startmeeting F41 Beta Go/No-Go
<@meetbot:fedora.im>
17:03:04
Meeting started at 2024-09-12 17:03:03 UTC
<@meetbot:fedora.im>
17:03:04
The Meeting name is 'F41 Beta Go/No-Go'
<@nirik:matrix.scrye.com>
17:03:23
morning everyone.
<@frantisekz:fedora.im>
17:03:39
evening :) o/
<@lruzicka:matrix.org>
17:03:52
Hello hello v hodinu cellou.,
<@amoloney:fedora.im>
17:04:25
!info We've done some early roll call, and present is nirik František Zatloukal Stephen Gallagher sircharles lruzicka
<@amoloney:fedora.im>
17:04:40
!topic Roll Call
<@sgallagh:fedora.im>
17:04:41
!hi
<@zodbot:fedora.im>
17:04:43
Stephen Gallagher (sgallagh) - he / him / his
<@amoloney:fedora.im>
17:06:24
I feel it would be rude to move on without his entrance :)
<@amoloney:fedora.im>
17:06:43
But...we will!
<@amoloney:fedora.im>
17:06:47
!info Purpose of this meeting is to check whether or not F40 Beta is ready for shipment, according to the release criteria.
<@sgallagh:fedora.im>
17:07:01
Uh, F40?
<@farribeiro:matrix.org>
17:07:02
!hi
<@zodbot:fedora.im>
17:07:04
Fábio Ribeiro (farribeiro) - he / him / his
<@sgallagh:fedora.im>
17:07:26
This meeting is already going at 88 miles per hour, it seems...
<@amoloney:fedora.im>
17:07:28
!info correction - we are determining F41 Beta is ready for shipment
<@amoloney:fedora.im>
17:08:00
!info The F41 Beta is determined release ready in a few ways
<@lruzicka:matrix.org>
17:08:02
backwards :D
<@amoloney:fedora.im>
17:08:21
hold on to your hats!#
<@amoloney:fedora.im>
17:08:31
!info 1. Release candidate compose is available
<@amoloney:fedora.im>
17:08:44
!info 2. No remaining blocker bugs
<@amoloney:fedora.im>
17:08:59
!info 3. Test matrices are fully completed
<@amoloney:fedora.im>
17:09:11
!info 4. Fedora CoreOS and IoT are ready
<@amoloney:fedora.im>
17:09:49
Now that we know the basic boiler plate criteria, lets get crackin' :)
<@amoloney:fedora.im>
17:10:08
!topic Current Status - RC
<@amoloney:fedora.im>
17:10:19
Do we have a beta rc to discuss?
<@nirik:matrix.scrye.com>
17:10:28
we do!
<@nirik:matrix.scrye.com>
17:10:37
!releng 12321
<@zodbot:fedora.im>
17:10:37
● **Last Updated:** 16 seconds ago
<@zodbot:fedora.im>
17:10:37
<@zodbot:fedora.im>
17:10:37
● **Assignee:** Not Assigned
<@zodbot:fedora.im>
17:10:37
● **Closed: Fixed with Explanation** 17 seconds ago by kevin
<@zodbot:fedora.im>
17:10:37
**releng #12321** (https://pagure.io/releng/issue/12321):**Create Fedora 41 Beta candidates**
<@zodbot:fedora.im>
17:10:37
● **Opened:** 22 hours ago by adamwill
<@nirik:matrix.scrye.com>
17:10:47
we have a RC-1.2
<@amoloney:fedora.im>
17:11:23
excellent - many thanks to releng for your work :)
<@amoloney:fedora.im>
17:11:37
this'll bring us to our next topic
<@amoloney:fedora.im>
17:11:50
!topic Current Status - Blockers
<@amoloney:fedora.im>
17:12:09
!link link https://qa.fedoraproject.org/blockerbugs/milestone/41/beta/buglist
<@amoloney:fedora.im>
17:12:33
QA, how we lookin?
<@lruzicka:matrix.org>
17:12:37
Yeah, there are two proposed blockers at the moment
<@frantisekz:fedora.im>
17:13:36
and 2 accepted blockers, are we expected to run through the mini blocker review now? (with meeting formatting and so on)?
<@sgallagh:fedora.im>
17:13:58
yes
<@amoloney:fedora.im>
17:13:59
yes please, Ill turn it over to you folks to walk us through them if thats ok?
<@frantisekz:fedora.im>
17:14:15
sure, missing adam real bad at the moment, I'll take it
<@frantisekz:fedora.im>
17:14:37
!info 2 Proposed Blockers
<@frantisekz:fedora.im>
17:14:41
!info 2 Accepted Blockers
<@frantisekz:fedora.im>
17:14:46
!info 0 Accepted 0-day Blockers
<@frantisekz:fedora.im>
17:14:50
!info 1 Accepted Previous Release Blockers
<@frantisekz:fedora.im>
17:14:54
!info 4 Proposed Freeze Exceptions
<@frantisekz:fedora.im>
17:14:57
!info 7 Accepted Freeze Exceptions
<@frantisekz:fedora.im>
17:15:28
!topic Proposed Beta blockers
<@frantisekz:fedora.im>
17:15:40
!topic (2311964) Discover does not discover upgrades to Fedora 41.
<@frantisekz:fedora.im>
17:15:42
!link https://bugzilla.redhat.com/show_bug.cgi?id=2311964
<@frantisekz:fedora.im>
17:15:46
!link https://pagure.io/fedora-qa/blocker-review/issue/1659
<@frantisekz:fedora.im>
17:15:50
!info Proposed Blocker, plasma-discover, NEW
<@nirik:matrix.scrye.com>
17:16:19
Hum. Does gnome-software work in this case? ie, do we know it's discover only issue?
<@lruzicka:matrix.org>
17:16:41
Gnome Software works fine. DNF also works ok.
<@lruzicka:matrix.org>
17:16:51
This looks to be a KDE only issue.
<@nirik:matrix.scrye.com>
17:17:49
This might also be a previous release blocker? you are using discover in f40 right?
<@lruzicka:matrix.org>
17:17:56
I was not sure whether the criterion about System Upgrade applies to all methods, or whether this would be a malfunction in Discover and therefore a Basic Application Func for Final.
<@lruzicka:matrix.org>
17:18:08
yes
<@frantisekz:fedora.im>
17:18:28
yeah, seems like this would be previous release blocker (as the fix will need to happen in f40)
<@geraldosimiao:matrix.org>
17:18:46
!hi
<@zodbot:fedora.im>
17:18:56
Geraldo S. Simião Kutz (geraldosimiao) - he / him / his
<@nirik:matrix.scrye.com>
17:19:08
Yeah, the critera seems to say " it must be possible to successfully complete a direct upgrade" but doesn't say all methods must work
<@nirik:matrix.scrye.com>
17:19:26
https://fedoraproject.org/wiki/Fedora_41_Beta_Release_Criteria#Upgrade_requirements
<@nirik:matrix.scrye.com>
17:20:05
oh, and discover isn't listed even?
<@nirik:matrix.scrye.com>
17:20:23
in the recommended upgrade mechanisms
<@frantisekz:fedora.im>
17:20:48
hmm, this would seem like an oversight?
<@sgallagh:fedora.im>
17:20:58
Proposal: PreviousReleaseBlocker for Final?
<@nirik:matrix.scrye.com>
17:21:01
yeah, probibly because it only came in in f40?
<@lruzicka:matrix.org>
17:21:35
Ok.
<@frantisekz:fedora.im>
17:21:37
ahh, yeah, +1 PreviousReleaseBlocker (Final), we can adjust the criteria to apply for the beta if we want later on
<@amoloney:fedora.im>
17:22:09
is it possible to upgrade it at all? The bz mentions dnf as a potential workaround, so if that works would it be ok to ship with this mention?
<@sgallagh:fedora.im>
17:22:09
The Beta does say it has to work on anything listed at https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/
<@nirik:matrix.scrye.com>
17:22:12
definitely +1 for that. I guess if we can fix it for beta that would be great, but if not people could work around it by using one of the other methods
<@sgallagh:fedora.im>
17:22:14
But that doesn't include Discover
<@nirik:matrix.scrye.com>
17:22:43
yeah, the docs likely need an update there.
<@adamwill:fedora.im>
17:22:55
hi, sorry
<@adamwill:fedora.im>
17:22:58
thought we had another day
<@nirik:matrix.scrye.com>
17:23:16
so few days. welcome to the beta nogo thunderdome. ;)
<@amoloney:fedora.im>
17:23:30
yeah sorry about the speed :)
<@adamwill:fedora.im>
17:23:54
kde never said they wanted discover to be a recommended method, afaik
<@lruzicka:matrix.org>
17:24:34
in that case, we are good and we can move this to Final.
<@nirik:matrix.scrye.com>
17:24:35
I just assumed they did... but yeah...
<@frantisekz:fedora.im>
17:24:36
but we have " QA:Testcase_upgrade_plasma-discover_current_kde" for Beta though...
<@adamwill:fedora.im>
17:24:46
sure
<@adamwill:fedora.im>
17:24:49
hmm
<@nirik:matrix.scrye.com>
17:25:13
well, if it's not a desired thing, we shouldn't even set it for final (at least until we know kde sig wants it)
<@lruzicka:matrix.org>
17:25:32
is there anybody from the sig?
<@adamwill:fedora.im>
17:25:41
the test case was created last august, maybe for a test day, can't find any context
<@adamwill:fedora.im>
17:25:43
Conan Kudo: ahoy
<@sgallagh:fedora.im>
17:27:10
Well, do we generally agree we don't need it for Beta? If so, we can just defer the GA discussion for the Blocker Review on Monday
<@adamwill:fedora.im>
17:27:27
yeah, makes sense
<@nirik:matrix.scrye.com>
17:27:44
sounds reasonable to me if we don't require it for beta.
<@frantisekz:fedora.im>
17:27:51
okay, so -1 Beta Blocker sounds bout right for this meeting
<@lruzicka:matrix.org>
17:28:24
Sure, -1 brigitte bardot
<@adamwill:fedora.im>
17:28:29
yeah, -1
<@sgallagh:fedora.im>
17:28:48
-1
<@nirik:matrix.scrye.com>
17:29:03
-1 BetaBlocker
<@geraldosimiao:matrix.org>
17:29:20
-1
<@adamwill:fedora.im>
17:29:40
hum you know what
<@adamwill:fedora.im>
17:29:50
i wonder if this is as simple as 'the test case should say kwriteconfig6 now'
<@nirik:matrix.scrye.com>
17:30:39
can someone test that and we can circle back?
<@lruzicka:matrix.org>
17:30:43
Let me check quickly
<@adamwill:fedora.im>
17:30:50
it doesn't matter to the discussion
<@adamwill:fedora.im>
17:30:54
let's just get the proposal and move on
<@nirik:matrix.scrye.com>
17:31:03
alright
<@lruzicka:matrix.org>
17:31:32
I am checking anyway.
<@adamwill:fedora.im>
17:32:32
František Zatloukal: i'm fine for you to keep on running things
<@frantisekz:fedora.im>
17:33:07
ah, okay okay then, gimme a few seconds
<@frantisekz:fedora.im>
17:35:24
proposed !agreed 2311964 - RejectedBlocker (Beta) - we found out that the TestCase got into the matrices by mistake, KDE upgrade via Discover isn't listed as recommended on https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/
<@nirik:matrix.scrye.com>
17:35:59
+1
<@nirik:matrix.scrye.com>
17:36:13
(or rather ack I guess)
<@adamwill:fedora.im>
17:36:15
i'd say maybe "this doesn't violate the beta criterion as Discover isn't listed as recommend on..."
<@sgallagh:fedora.im>
17:36:23
ack
<@adamwill:fedora.im>
17:36:25
we can just tweak the milestone for the test case without noting it
<@frantisekz:fedora.im>
17:37:11
okey dokey
<@frantisekz:fedora.im>
17:37:12
proposed !agreed 2311964 - RejectedBlocker (Beta) - this doesn't violate the beta criterion as Discover isn't listed as recommended on https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/
<@adamwill:fedora.im>
17:37:27
ack
<@nirik:matrix.scrye.com>
17:37:37
sure
<@lruzicka:matrix.org>
17:37:41
ack
<@geraldosimiao:matrix.org>
17:37:43
ack
<@frantisekz:fedora.im>
17:38:05
!agreed 2311964 - RejectedBlocker (Beta) - this doesn't violate the beta criterion as Discover isn't listed as recommended on https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/
<@lruzicka:matrix.org>
17:38:27
And up the path, we move.
<@frantisekz:fedora.im>
17:38:30
!topic (2311907) Anaconda crashes when an error occurs and should be reported.
<@frantisekz:fedora.im>
17:38:35
!link https://bugzilla.redhat.com/show_bug.cgi?id=2311907
<@frantisekz:fedora.im>
17:38:39
!link https://pagure.io/fedora-qa/blocker-review/issue/1657
<@frantisekz:fedora.im>
17:38:44
!info Proposed Blocker, python3.13, ASSIGNED
<@nirik:matrix.scrye.com>
17:39:05
Is this related to that abrt FE?
<@frantisekz:fedora.im>
17:39:07
so, we both encountered this today with lruzicka on two different generations of Intel fw raids
<@frantisekz:fedora.im>
17:39:15
no no, afaik
<@frantisekz:fedora.im>
17:39:29
oh, scratch my sentences please
<@lruzicka:matrix.org>
17:39:31
No, this is not the problem. It is a different issue.
<@frantisekz:fedora.im>
17:39:38
I thought about different thingie...
<@adamwill:fedora.im>
17:40:08
huh, i wonder if this is the cause of my https://bugzilla.redhat.com/show_bug.cgi?id=2308279
<@lruzicka:matrix.org>
17:40:13
The thing is when I attempted a simulated crash on Anaconda, it crashed for real on text mode.
<@lruzicka:matrix.org>
17:40:46
It crashed on graphics, too, but did not stop anaconda from finishing the installation.
<@lruzicka:matrix.org>
17:41:11
And later, when I discovered a RAID bug, Anaconda crashed for real and was able to report correctly.
<@adamwill:fedora.im>
17:42:46
lruzicka: wait, i don't understand what happened in graphical mode exactly
<@adamwill:fedora.im>
17:43:05
but if crash reporting worked ok for a 'real' crash, that seems kinda -1...
<@lruzicka:matrix.org>
17:43:29
In graphical mode, the crash was shown in the Anaconda console, but the GUI proceeded with the installation which completed successfully.
<@nirik:matrix.scrye.com>
17:44:31
yeah, if real crashes work, this doesn't seem as bad...
<@lruzicka:matrix.org>
17:44:46
yeah, I contacted Jirka Konecny about it, but I do not have the resolution so far, where the problem lies. Maybe it was caused by the simulated crash and it is not caused by a real crash.
<@adamwill:fedora.im>
17:44:48
i wonder if we need to change the instructions in the test case or something...that sounds like it killed the wrong process?
<@adamwill:fedora.im>
17:44:53
or maybe this is due to all the dbusification
<@adamwill:fedora.im>
17:46:28
or...hmm, looking at the traceback, it looks like this might depend on the details of the crash
<@nirik:matrix.scrye.com>
17:46:33
sounds like it would be good to know more, but... we need to decide what to do with it now...
<@amoloney:fedora.im>
17:47:52
perhaps a basic question, but maybe useful for a decision - what part of the release criteria does this potentially violate?
<@frantisekz:fedora.im>
17:48:46
it'd violate "The installer must be able to report failures to Bugzilla, with appropriate information included." , a basic criterion ( https://fedoraproject.org/wiki/Basic_Release_Criteria#failure-reporting )
<@amoloney:fedora.im>
17:48:58
ack, thank you
<@frantisekz:fedora.im>
17:49:18
but, I am thinking, if we can do it like this on go/no-go, punt to gather more information?
<@amoloney:fedora.im>
17:50:00
I dont think we can in this one unfortunately
<@adamwill:fedora.im>
17:50:01
i'm trying to figure it out rn
<@sgallagh:fedora.im>
17:50:01
František Zatloukal: Could you rephrase? Do you mean "since we can't reproduce it using real crashes"?
<@adamwill:fedora.im>
17:50:13
i *think* this is quite likely tied to the fact that we're using a special codepath in anaconda for testing crash handling
<@frantisekz:fedora.im>
17:50:16
yeah yeah, that'd work even better for sure
<@nirik:matrix.scrye.com>
17:50:20
we could also reject it as a blocker but it could be re-proposed with more info?
<@amoloney:fedora.im>
17:50:33
with Stephen Gallagher wording that sounds like it'll work
<@adamwill:fedora.im>
17:50:58
when we send it a USR1 it winds up in this `test_exception_handling` function in pyanaconda/exception.py and then in the block commented "XXX: this is a huge hack" where the problem happens
<@adamwill:fedora.im>
17:51:14
so it seems at least plausible to me this is specific to this kinda-special path and doesn't affect 'real' crashes
<@adamwill:fedora.im>
17:51:37
i'd maybe have to reproduce it with some debug statements in the upstream python code to verify that which will take longer than we have
<@adamwill:fedora.im>
17:52:00
i'd *guess* we might be able to avoid this by fiddling with the test exception, but it'll take a bit of time to figure it out. on the whole, i'd lean -1 on current info
<@lruzicka:matrix.org>
17:52:34
Ok, I saw today that it did not crash on real crash, so I can be -1, too
<@frantisekz:fedora.im>
17:53:18
okey dokey, I kinda like rejecting it for beta more, -1 Beta Blocker (we can count those and those who prefer punt here)
<@nirik:matrix.scrye.com>
17:53:48
-1 BetaBlocker
<@adamwill:fedora.im>
17:54:18
punt is effectively a no-go vote at this point, i think
<@amoloney:fedora.im>
17:55:09
it is, its either a blocker, which would mean we are a No-Go, or its not a blocker which means we can continue with this meeting
<@adamwill:fedora.im>
17:55:41
i will poke around at it a bit as the meeting continues
<@amoloney:fedora.im>
17:56:05
thanks Adam
<@frantisekz:fedora.im>
17:56:10
any more votes for -1 ? , or shall we move forward to one more proposed blocker?
<@adamwill:fedora.im>
17:57:19
we should stick on this until it's decided one way or another, we can't leave anything in ambiguous state at a go/no-go
<@nirik:matrix.scrye.com>
17:57:25
I see 4 -1s and 0 +1s for it... so, shall we propose it as rejected?
<@frantisekz:fedora.im>
17:57:26
okey dokey
<@frantisekz:fedora.im>
17:57:44
(I can do the proposal now)
<@amoloney:fedora.im>
17:57:45
we could take a short break and I can set the status to waiting?
<@adamwill:fedora.im>
17:57:55
yeah, we have enough votes for rejected
<@geraldosimiao:matrix.org>
17:58:15
-1
<@frantisekz:fedora.im>
17:58:31
proposed !agreed 2311907 - RejectedBlocker (Beta) - we can't reproduce it using real crashes, and we have a great confidence that the issue would occur only in special code-path for testing the crash reporting feature in Anaconda
<@geraldosimiao:matrix.org>
17:58:47
ack
<@lruzicka:matrix.org>
17:58:52
ack
<@amoloney:fedora.im>
17:58:56
ack
<@adamwill:fedora.im>
17:58:58
s/great/moderate/ :D
<@sgallagh:fedora.im>
17:58:58
patch
<@nirik:matrix.scrye.com>
17:59:00
ack
<@sgallagh:fedora.im>
17:59:26
Exactly what adamw said; reduce "great confidence" to "strong suspicion" please
<@frantisekz:fedora.im>
17:59:48
proposed !agreed 2311907 - RejectedBlocker (Beta) - we can't reproduce it using real crashes, and we have a strong suspicion that the issue would occur only in special code-path for testing the crash reporting feature in Anaconda
<@lruzicka:matrix.org>
18:00:05
ack again
<@frantisekz:fedora.im>
18:00:19
(I am really sorry for my lower expertise and non-native speaker skills here)
<@adamwill:fedora.im>
18:00:27
ack
<@adamwill:fedora.im>
18:00:28
it's fine
<@amoloney:fedora.im>
18:00:35
youre doing a great job!
<@adamwill:fedora.im>
18:00:42
gotta practice somehow :D
<@sgallagh:fedora.im>
18:00:54
It's all good :)
<@sgallagh:fedora.im>
18:01:02
axk
<@sgallagh:fedora.im>
18:01:07
ack
<@frantisekz:fedora.im>
18:01:07
!agreed 2311907 - RejectedBlocker (Beta) - we can't reproduce it using real crashes, and we have a strong suspicion that the issue would occur only in special code-path for testing the crash reporting feature in Anaconda
<@frantisekz:fedora.im>
18:01:30
!topic (2311936) pyanaconda.modules.common.errors.storage.UnknownDeviceError: Volume0_0
<@frantisekz:fedora.im>
18:01:34
!link https://bugzilla.redhat.com/show_bug.cgi?id=2311936
<@frantisekz:fedora.im>
18:01:39
!link https://pagure.io/fedora-qa/blocker-review/issue/1658
<@frantisekz:fedora.im>
18:01:43
!info Proposed Blocker, anaconda, ASSIGNED
<@frantisekz:fedora.im>
18:02:06
so, this was proposed for final, but I do believe we should discuss/consider this for beta
<@frantisekz:fedora.im>
18:02:59
tldr would be that the simple partitioning doesn't work with FW RAID, one has to use custom/advanced which do work correctly
<@frantisekz:fedora.im>
18:03:20
I would personally incline to having it as a common bug right now though
<@frantisekz:fedora.im>
18:03:34
we did test this on two generations of intel fw raids
<@nirik:matrix.scrye.com>
18:03:37
I thought we moved firmware raid specifically to final for some reasons...
<@adamwill:fedora.im>
18:03:52
firmware raid is *specifically* in the final criteria
<@adamwill:fedora.im>
18:03:56
that seems pretty intentional to me
<@frantisekz:fedora.im>
18:04:05
heh, so, https://fedoraproject.org/wiki/Test_Results:Fedora_41_Beta_1.2_Installation#Storage_devices fooled me once again
<@nirik:matrix.scrye.com>
18:04:08
ah indeed: Firmware RAID requirement move from Beta to Final proposed 2018-09-14, implemented 2018-11-16
<@lruzicka:matrix.org>
18:04:09
I proposed for Final, originally.
<@adamwill:fedora.im>
18:04:17
oh yes, we should change that
<@lruzicka:matrix.org>
18:04:58
no, we should not. It is better when we test earlier. The criterion says Final, so we'll know.
<@adamwill:fedora.im>
18:05:07
fixed the matrix
<@nirik:matrix.scrye.com>
18:05:12
so I am -1 BetaBlocker, but sure, it could be a common bug...
<@adamwill:fedora.im>
18:05:23
lruzicka: the column is meant to tell you what milestone it is blocking for
<@adamwill:fedora.im>
18:05:32
not what column to test it at. we should run all non-optional tests at all milestones
<@frantisekz:fedora.im>
18:05:42
!info the criterion doesn't apply to Beta release, on purpose, and the wiki test matrix was updated accordingly
<@adamwill:fedora.im>
18:06:31
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/RYRDJ5EJOE3AJ6WQBOHDUW23QU4HL6PO/ was the proposal to make this final not beta, btw
<@frantisekz:fedora.im>
18:06:49
mhm, so, off to accepted beta blockers
<@frantisekz:fedora.im>
18:07:05
!topic Accepted Beta blockers
<@frantisekz:fedora.im>
18:07:21
!topic (2282171) gsk: vulkan renderer causes gtk4 apps to crash on resize operations on Raspberry Pi 4 and 400
<@frantisekz:fedora.im>
18:07:28
!link https://bugzilla.redhat.com/show_bug.cgi?id=2282171
<@frantisekz:fedora.im>
18:07:31
!link https://pagure.io/fedora-qa/blocker-review/issue/1605
<@frantisekz:fedora.im>
18:07:35
!info Accepted Blocker, bcm283x-firmware, ASSIGNED
<@adamwill:fedora.im>
18:07:55
Peter Robinson has been working on fixing this but i guess it's not done yet
<@nirik:matrix.scrye.com>
18:08:28
yeah. So, I guess we are no go then? unless we can lawyer this away.
<@frantisekz:fedora.im>
18:09:04
to give a mall tldr here: it used to be far worse with graphical issues all around the Workstation env, we now have crashes on resizing and some modal(?) dialogs in gtk4 apps (eg. saving a document in text editor)
<@adamwill:fedora.im>
18:09:05
we could say that documenting the kernel parameter is sufficient to address it, i guess
<@amoloney:fedora.im>
18:09:14
creative release notes maybe? :)
<@adamwill:fedora.im>
18:09:23
František Zatloukal: does the kernel param to fix the memory assignment resolve all issues?
<@frantisekz:fedora.im>
18:09:28
that'd seem just fine for my taste... for beta
<@frantisekz:fedora.im>
18:09:31
yes
<@frantisekz:fedora.im>
18:09:41
simply adding cma=256M resolves all
<@lruzicka:matrix.org>
18:10:33
CommonBugs with a workaround could be sufficient on a Beta release, I think.
<@adamwill:fedora.im>
18:10:42
i guess i'm having evil thoughts because i'm thinking 'maybe we can keep this as a blocker so we can do another rc with some good fe fixes'
<@adamwill:fedora.im>
18:10:54
but those are Wrong Thoughts
<@adamwill:fedora.im>
18:10:56
bad me
<@nirik:matrix.scrye.com>
18:10:57
so this is pi4 with a gui? is that super common?
<@frantisekz:fedora.im>
18:11:01
heh, I personally wouldn't do that for Beta
<@sgallagh:fedora.im>
18:11:03
!fire adamw
<@frantisekz:fedora.im>
18:11:13
everybody is going to forget about it in a month or so
<@adamwill:fedora.im>
18:11:13
nirik: it's probably the *most* common official aarch64 desktop config, if anything.
<@amoloney:fedora.im>
18:11:34
A gentle reminder we are technically already one week behind due to the request in August to accomodate Flock for branching
<@amoloney:fedora.im>
18:11:42
now, time is irrelevant
<@conan_kudo:matrix.org>
18:11:42
!hi
<@adamwill:fedora.im>
18:11:43
on the face of it, i'm ok with saying that documenting the kernel param as a workaround is sufficient mitigation for beta
<@zodbot:fedora.im>
18:11:44
Neal Gompa (ngompa) - he / him / his
<@nirik:matrix.scrye.com>
18:11:55
yeah, I guess I would be too.
<@amoloney:fedora.im>
18:12:00
so if we need to push to get a better beta, its worth the consideration
<@nirik:matrix.scrye.com>
18:12:03
we should of course fix it more better for final
<@adamwill:fedora.im>
18:12:12
moar bettar fixing
<@sgallagh:fedora.im>
18:12:21
I don't think this alone is worth a delay
<@frantisekz:fedora.im>
18:12:42
well... one would wish for this being alone, but we'll get there
<@adamwill:fedora.im>
18:12:53
yeah, i don't think we have release fever here, this is clearly much less of a problem than it was a few weeks ago, objectively
<@conan_kudo:matrix.org>
18:13:14
Oh crap, it should be on there
<@conan_kudo:matrix.org>
18:13:29
I don't know why discover isn't there
<@adamwill:fedora.im>
18:14:31
i filed a ticket
<@frantisekz:fedora.im>
18:14:31
we can circle back to kde discover after accepted blockers?
<@nirik:matrix.scrye.com>
18:14:44
so, shall we revote this and -1 it as a blocker then?
<@lruzicka:matrix.org>
18:15:03
By the way, the `kwriteconfig6` did not fix it.
<@sgallagh:fedora.im>
18:15:05
-1 Beta Blocker, +1 Final Blocker
<@frantisekz:fedora.im>
18:15:15
-1 Beta Blocker, +1 Final
<@nirik:matrix.scrye.com>
18:15:19
-1 Beta Blocker, +1 Final Blocker
<@adamwill:fedora.im>
18:16:07
lruzicka: aw
<@adamwill:fedora.im>
18:16:32
-1 beta so long as we commonbugs it, +1 final
<@conan_kudo:matrix.org>
18:17:44
This requires updates to fedora appstream metadata package, which I thought we had reached out to add to the SOP
<@frantisekz:fedora.im>
18:17:55
proposed !agreed 2282171 - RejectedBlocker (Beta) AcceptedCommonBug (Beta) AcceptedBlocker (Final) - this wasn't deemed worthy to block the beta release on, but we agreed that the final release has to have a fix for the issue. We also accept is as a common bug to have a documented trivial workaround.
<@adamwill:fedora.im>
18:18:50
acceptedcommonbug isn't a thing
<@adamwill:fedora.im>
18:19:16
i'd drop that bit and just mention in the text that we will mark it as CommonBugs
<@nirik:matrix.scrye.com>
18:19:19
might avoid calling the workaround trivial...
<@frantisekz:fedora.im>
18:19:33
what about
<@frantisekz:fedora.im>
18:19:33
proposed !agreed 2282171 - RejectedBlocker (Beta) AcceptedBlocker (Final) - this wasn't deemed worthy to block the beta release on, but we agreed that the final release has to have a fix for the issue. We also accept is as a common bug to have a documented workaround.
<@frantisekz:fedora.im>
18:19:43
is/it
<@frantisekz:fedora.im>
18:19:53
proposed !agreed 2282171 - RejectedBlocker (Beta) AcceptedBlocker (Final) - this wasn't deemed worthy to block the beta release on, but we agreed that the final release has to have a fix for the issue. We also accept it as a common bug to have a documented workaround.
<@amoloney:fedora.im>
18:19:53
I like it, fwiw
<@adamwill:fedora.im>
18:20:17
ack
<@sgallagh:fedora.im>
18:20:22
Ack
<@lruzicka:matrix.org>
18:20:24
ack
<@nirik:matrix.scrye.com>
18:20:24
ack
<@frantisekz:fedora.im>
18:20:30
!agreed 2282171 - RejectedBlocker (Beta) AcceptedBlocker (Final) - this wasn't deemed worthy to block the beta release on, but we agreed that the final release has to have a fix for the issue. We also accept it as a common bug to have a documented workaround.
<@frantisekz:fedora.im>
18:20:52
!topic (2283978) Raspberry Pi 4 automatically suspends when idle, claims to support suspend, but can't be woken up
<@frantisekz:fedora.im>
18:20:57
!link https://bugzilla.redhat.com/show_bug.cgi?id=2283978
<@frantisekz:fedora.im>
18:21:02
!link https://pagure.io/fedora-qa/blocker-review/issue/1607
<@frantisekz:fedora.im>
18:21:06
!info Accepted Blocker, kernel, ASSIGNED
<@nirik:matrix.scrye.com>
18:21:10
looks like peter would like this to just be common bugged for beta.
<@lruzicka:matrix.org>
18:21:24
good so
<@frantisekz:fedora.im>
18:21:29
the previous one with gsk, right?
<@frantisekz:fedora.im>
18:22:02
ah no, this one :)
<@adamwill:fedora.im>
18:22:19
yeah, i think we can waive this as not realistically fixable
<@frantisekz:fedora.im>
18:22:36
+1 waive this
<@nirik:matrix.scrye.com>
18:22:55
I mean, the workaround is basically "don't do that" right?
<@frantisekz:fedora.im>
18:23:20
the bad thing about it is that both Workstation and KDE do it for you :/
<@adamwill:fedora.im>
18:23:35
well, disable the auto-suspend setting
<@adamwill:fedora.im>
18:23:39
and then avoid suspending manually, yeah
<@frantisekz:fedora.im>
18:24:53
proposed !agreed 2283978 - RejectedBlocker (Beta) - This issue isn't realistically fixable in Fedora 41 timeline, we'll document it as a common bug with instructions on how to disable auto-suspend in both blocking environments (GNOME, and KDE).
<@lruzicka:matrix.org>
18:25:13
ack
<@sgallagh:fedora.im>
18:25:14
ack
<@adamwill:fedora.im>
18:25:16
nack
<@adamwill:fedora.im>
18:25:19
that's not how we waive
<@nirik:matrix.scrye.com>
18:25:36
well... this might be somewhat fixed before final right?
<@nirik:matrix.scrye.com>
18:25:58
I guess unclear
<@adamwill:fedora.im>
18:26:26
i should update the meeting sop with guidance on handling waives i guess
<@adamwill:fedora.im>
18:26:42
but it should be something like:
<@frantisekz:fedora.im>
18:27:05
WaivedBlocker ? 😅
<@adamwill:fedora.im>
18:27:49
proposed !agreed 2283978 - waive to F41 Final - this is waived under "Difficult to fix blocker bugs" at https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases , on the advice of the maintainers involved (see the bug for details)
<@lruzicka:matrix.org>
18:27:59
ack
<@nirik:matrix.scrye.com>
18:28:18
sure. ack
<@sgallagh:fedora.im>
18:28:34
ack
<@lruzicka:matrix.org>
18:28:35
but you should know that to word those reasonings is extremely difficult for non-native speakers as it is required basically in no time.
<@frantisekz:fedora.im>
18:28:36
ack :) , thanks!
<@frantisekz:fedora.im>
18:28:49
!agreed 2283978 - waive to F41 Final - this is waived under "Difficult to fix blocker bugs" at https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases , on the advice of the maintainers involved (see the bug for details)
<@adamwill:fedora.im>
18:29:18
lruzicka: the important point is that we're waiving it, not rejecting it
<@frantisekz:fedora.im>
18:29:35
!info those were all accepted blockers, circling back to the proposed one
<@lruzicka:matrix.org>
18:30:05
okee doke
<@frantisekz:fedora.im>
18:30:29
!topic Proposed Beta Blockers
<@frantisekz:fedora.im>
18:30:42
!topic (2311964) Discover does not discover upgrades to Fedora 41.
<@frantisekz:fedora.im>
18:30:46
!link https://bugzilla.redhat.com/show_bug.cgi?id=2311964
<@frantisekz:fedora.im>
18:30:50
!link https://pagure.io/fedora-qa/blocker-review/issue/1659
<@frantisekz:fedora.im>
18:30:53
!info Proposed Blocker, plasma-discover, NEW
<@adamwill:fedora.im>
18:30:57
Conan Kudo: so where does the fix for this go?
<@frantisekz:fedora.im>
18:30:59
Conan Kudo:
<@nirik:matrix.scrye.com>
18:32:26
fedora-appstream-metadata I guess?
<@adamwill:fedora.im>
18:32:35
but in f40 or f41?
<@nirik:matrix.scrye.com>
18:32:55
glad to see there's another place that keeps a hard coded list of releases.
<@nirik:matrix.scrye.com>
18:33:19
in f40 I would think.
<@nirik:matrix.scrye.com>
18:33:55
like: https://src.fedoraproject.org/rpms/fedora-appstream-metadata/c/0f2f7e200345fcea15f1cbe0099e8ffd0c8532a2?branch=rawhide
<@adamwill:fedora.im>
18:33:55
nirik: to be fair, *this* dumb hardcoded list is sourced from the *other* dumb hardcoded list. wait, is that better? :D
<@nirik:matrix.scrye.com>
18:35:19
see also: https://bugzilla.redhat.com/show_bug.cgi?id=2267547
<@frantisekz:fedora.im>
18:36:33
hmm, it was BetaFreezeException
<@frantisekz:fedora.im>
18:36:40
good catch nirik
<@nirik:matrix.scrye.com>
18:37:28
but I don't see why it has to be the beta version updated... I would think it would be the previous release
<@adamwill:fedora.im>
18:38:13
yeah, on the face of it that seems logical
<@frantisekz:fedora.im>
18:38:31
anyhow, I'd feel like leaving it as voted in previously on a first take, it's not up on https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/ as of now, it was discovered late, wdyt?
<@nirik:matrix.scrye.com>
18:38:32
Anyhow, I don't think we should have this as a beta blocker.
<@adamwill:fedora.im>
18:39:30
i mean, in theory we could argue that kde team *intended* it to be there, but ehhh
<@frantisekz:fedora.im>
18:40:18
so, shall we revote now? or just note that we aren't revoting?
<@nirik:matrix.scrye.com>
18:40:28
it should be fixable I think by a f40 update... which can happen anytime.
<@nirik:matrix.scrye.com>
18:42:19
so whats our best course of action here? revote and make it not a blocker? waive as discovered late?
<@nirik:matrix.scrye.com>
18:42:41
take up yak ranching?
<@adamwill:fedora.im>
18:42:54
i was waiting for conan
<@adamwill:fedora.im>
18:43:01
but as things stand i'm fine keeping this not a blocker
<@geraldosimiao:matrix.org>
18:43:39
I'm fine too, its beta anyway
<@lruzicka:matrix.org>
18:43:42
+1
<@frantisekz:fedora.im>
18:44:20
!info we aren't revoting the 2311964
<@frantisekz:fedora.im>
18:44:44
so, this would be all of the blockers, are we going through FEs too now?
<@geraldosimiao:matrix.org>
18:45:07
the more time we have beta out, the more people test it and we can fix it...
<@adamwill:fedora.im>
18:45:07
not for a go/no-go no
<@adamwill:fedora.im>
18:45:10
there's no point to it
<@amoloney:fedora.im>
18:45:40
I dont think so, the blockers are the main ones
<@frantisekz:fedora.im>
18:45:49
oh, sorry...
<@frantisekz:fedora.im>
18:45:56
one more ugly thingie
<@frantisekz:fedora.im>
18:46:03
!topic Accepted Previous Release Blockers
<@frantisekz:fedora.im>
18:46:16
!topic (2242759) dnf system-upgrade fails on some RPi4 due to system boot date that pre-dates gpg key
<@frantisekz:fedora.im>
18:46:18
!link https://bugzilla.redhat.com/show_bug.cgi?id=2242759
<@frantisekz:fedora.im>
18:46:22
!link https://pagure.io/fedora-qa/blocker-review/issue/1601
<@frantisekz:fedora.im>
18:46:25
!info Accepted Previous Release Blocker, distribution, NEW
<@sgallagh:fedora.im>
18:46:43
We've waived this for multiple releases now; when is it time to just admit this isn't going to get fixed?
<@frantisekz:fedora.im>
18:46:46
we've been rolling this one for quite some time
<@frantisekz:fedora.im>
18:46:48
yeah
<@adamwill:fedora.im>
18:47:12
i proposed that last cycle
<@adamwill:fedora.im>
18:47:15
but couldn't get people to bite
<@nirik:matrix.scrye.com>
18:47:23
I guess it's time now..
<@conan_kudo:matrix.org>
18:47:37
Sorry I'm out right now, we can get it out in the next days and it will work for beta
<@adamwill:fedora.im>
18:47:38
i am fine with making it -1 we just can't fix this let's stop pretending.
<@adamwill:fedora.im>
18:47:49
Conan Kudo: so it doesn't need to be updated in f41, right?
<@mattdm:fedora.im>
18:47:50
I am +1 to adam's -1
<@frantisekz:fedora.im>
18:47:59
uff, seen +1 first... :D
<@frantisekz:fedora.im>
18:48:10
anyhow, -1 Beta Blocker
<@lruzicka:matrix.org>
18:48:16
-1
<@nirik:matrix.scrye.com>
18:48:40
I'm ok dropping this as a previous release blocker at this point... it doesn't seem like anyone is going to fix it.
<@conan_kudo:matrix.org>
18:49:03
Not really, no
<@adamwill:fedora.im>
18:49:11
Conan Kudo: cool.
<@sgallagh:fedora.im>
18:49:16
let's just close it as CANTFIX
<@conan_kudo:matrix.org>
18:49:18
Unless you want to test updates to f42
<@nirik:matrix.scrye.com>
18:49:22
well, it should be updated in f41... so you can go to f42
<@nirik:matrix.scrye.com>
18:49:24
yeah
<@adamwill:fedora.im>
18:49:41
yeah, but i mean, we don't need to fix it *right now* in f41 to fix upgrades to f41.
<@nirik:matrix.scrye.com>
18:49:49
agreed
<@adamwill:fedora.im>
18:49:50
+1 CANTFIX
<@frantisekz:fedora.im>
18:51:17
proposed !agreed 2242759 - RejectedBlocker (Beta) - this is dropped as hard to fix bug as we don't have proposals how to properly fix the issue, and there is no point in rolling this one from release to release.
<@adamwill:fedora.im>
18:51:51
sure, ack
<@geraldosimiao:matrix.org>
18:51:57
ack
<@adamwill:fedora.im>
18:51:59
i support anything which means we don't have to talk about this bug any more
<@lruzicka:matrix.org>
18:52:02
ack
<@nirik:matrix.scrye.com>
18:52:05
well, it's a previousrelease blocker right?
<@frantisekz:fedora.im>
18:52:13
oh, right
<@amoloney:fedora.im>
18:52:21
and previousprevious
<@adamwill:fedora.im>
18:52:34
but RejectedBlocker is still appropriate
<@adamwill:fedora.im>
18:52:42
we have various Accepteds but only one Rejected. :D
<@nirik:matrix.scrye.com>
18:52:51
ok, sure then, ack
<@frantisekz:fedora.im>
18:53:00
!agreed 2242759 - RejectedBlocker (Beta) - this is dropped as hard to fix bug as we don't have proposals how to properly fix the issue, and there is no point in rolling this one from release to release.
<@frantisekz:fedora.im>
18:53:44
uff, this was all for the blocker mini, back to you Aoife Moloney I guess? we have 0 outstanding blockers if I am looking right
<@nirik:matrix.scrye.com>
18:53:53
amazingly
<@amoloney:fedora.im>
18:54:15
!info All blockers have been addressed for RC 1.2 beta
<@amoloney:fedora.im>
18:54:43
!info Current Status - Test Matrices
<@amoloney:fedora.im>
18:54:55
that should have been topic, apologies
<@nirik:matrix.scrye.com>
18:55:51
Given that 1.2 landed just yesterday, coverage might be low...
<@adamwill:fedora.im>
18:56:03
we're supposed to have at least one real-media test on aarch64
<@amoloney:fedora.im>
18:56:13
yeah I just checked the test page link and there wasnt anything on it
<@lruzicka:matrix.org>
18:56:17
Coverage is fine on x86_64
<@amoloney:fedora.im>
18:56:32
no i did not, I had a typo
<@amoloney:fedora.im>
18:56:34
ignore please
<@amoloney:fedora.im>
18:57:02
!link https://fedoraproject.org/wiki/Category:Fedora_41_Test_Results
<@frantisekz:fedora.im>
18:57:15
sigh, we don't have any HW that could be used to test this in Brno (if it can't be hacked on rpis somehow)
<@farchord:matrix.org>
18:57:46
and the x1e laptops are not Linux-worthy yet. By 42, maaaaayyybe?
<@adamwill:fedora.im>
18:57:46
ah, that's an issue
<@geraldosimiao:matrix.org>
18:58:01
we have for minimal and workstation
<@pwhalen:fedora.im>
18:58:09
I can test aarch64, but it would take a bit
<@nirik:matrix.scrye.com>
18:58:12
yeah, I could boot on my x1e, but... not sure how clear of a test that would be for this.
<@pwhalen:fedora.im>
18:58:26
downloading now
<@farchord:matrix.org>
18:58:30
Considering the sheer amount of "hacks" we have to go through....
<@adamwill:fedora.im>
18:58:49
the test is basically to ensure the image manages to boot and install on a real system
<@adamwill:fedora.im>
18:58:52
if that works, it's ok
<@nirik:matrix.scrye.com>
18:59:12
with mainline kernel I think it could work, but will not have internal keyboard/mouse working and will require blocklisting a few modules.
<@farchord:matrix.org>
18:59:40
Yup. Though it's a bit volatile (i.e. it worked on a kernel, and no longer after a kernel update) lol
<@adamwill:fedora.im>
18:59:44
the KDE line for aarch64 disk images is also not filled in, but lbrabec filed some kde desktop test results, so that kinda implies he did that?
<@adamwill:fedora.im>
18:59:57
the KDE line for aarch64 disk images is also not filled in, but lbrabec filed some kde desktop test results, so that kinda implies he did a deployment somehow, so maybe that is covered?
<@adamwill:fedora.im>
19:00:35
we're missing a couple of storage tests, sas and hw raid
<@frantisekz:fedora.im>
19:00:35
he used a VM :/
<@adamwill:fedora.im>
19:00:40
who has hw raid...is it me...i don't think so
<@lbrabec:matrix.org>
19:00:55
I also used Rpi4
<@frantisekz:fedora.im>
19:01:06
ah, sorry then, forgot
<@adamwill:fedora.im>
19:01:55
also missing ec2 cloud testing, let me check that quick
<@frantisekz:fedora.im>
19:01:57
Lili used to do HW RAIDS in the past, at least on some matrices
<@amoloney:fedora.im>
19:02:27
in past meetings I have seen status be set to 'waiting' while testing happens. Im happy to do that now if we have people available to run the necessary tests?
<@adamwill:fedora.im>
19:02:29
Lukas Brabec: ah i see you checked it off :D
<@adamwill:fedora.im>
19:02:54
Aoife Moloney: not sure we can do the sas / hw raid if nobody has hardware, but we can work on the arm uefi install and cloud tests
<@amoloney:fedora.im>
19:03:20
ack, we can note that as part of the testing coverage results
<@amoloney:fedora.im>
19:03:30
ack, we can note that as part of the testing coverage results in the meeting logs
<@amoloney:fedora.im>
19:04:39
so is the arm uefi install and cloud tests now being worked on? just confirming before I change the topic to 'waiting'
<@adamwill:fedora.im>
19:05:03
huh, the amis are missing for cloud page...uff...let's see
<@nirik:matrix.scrye.com>
19:05:13
35% on my download.
<@adamwill:fedora.im>
19:05:17
Aoife Moloney: i am yak shaving the cloud tests. :D
<@amoloney:fedora.im>
19:05:32
May your blades remain sharp
<@amoloney:fedora.im>
19:05:44
!topic Status - Waiting
<@adamwill:fedora.im>
19:05:52
nirik: oh hey. did we switch to the new cloud uploader thingy?
<@amoloney:fedora.im>
19:06:33
!info a number of tests are being run to confirm test coverage. The meeting will resume once test results are complete
<@nirik:matrix.scrye.com>
19:07:32
adamw: yes?
<@adamwill:fedora.im>
19:07:37
ah.
<@adamwill:fedora.im>
19:07:54
i forgot i need to change relvalamiconsumer for that.
<@nirik:matrix.scrye.com>
19:08:14
ah... I guess the names changed slightly...
<@adamwill:fedora.im>
19:09:23
well, it's a completely different message now
<@adamwill:fedora.im>
19:09:42
relvalamiconsumer consumes org.fedoraproject.prod.fedimg.image.publish which hasn't been published for a month
<@adamwill:fedora.im>
19:09:57
it looks like the new thing is supposed to publish `org.fedoraproject.prod.fedora_image_uploader.published.v1.aws` but i can't find any such messages :9
<@adamwill:fedora.im>
19:10:01
it looks like the new thing is supposed to publish `org.fedoraproject.prod.fedora_image_uploader.published.v1.aws` but i can't find any such messages :(
<@adamwill:fedora.im>
19:10:08
did we ever check if publishing is working for it?
<@nirik:matrix.scrye.com>
19:10:17
I thought it was re-using the fedimg one.
<@nirik:matrix.scrye.com>
19:10:24
but let me look
<@adamwill:fedora.im>
19:10:33
https://pagure.io/cloud-image-uploader/blob/main/f/fedora-image-uploader-messages/fedora_image_uploader_messages/publish.py doesn't look like that
<@adamwill:fedora.im>
19:10:54
(this is relevant because i have no idea where the damn AMIs are without this)
<@nirik:matrix.scrye.com>
19:13:20
https://apps.fedoraproject.org/datagrepper/raw?rows_per_page=1&delta=127800&category=fedora_image_uploader
<@adamwill:fedora.im>
19:13:50
ah, it gets more added to the topic.
<@adamwill:fedora.im>
19:14:58
okay, now i know where the amis are
<@adamwill:fedora.im>
19:15:03
i can fix the consumer after the meeting
<@nirik:matrix.scrye.com>
19:15:54
my download finished. arm-image-installer running
<@adamwill:fedora.im>
19:17:00
nirik: er, we don't want to use arm-image-installer?
<@adamwill:fedora.im>
19:17:10
we need to test booting like on x86_64, that's what this matrix square is for
<@adamwill:fedora.im>
19:17:14
'normal' uefi boot
<@adamwill:fedora.im>
19:17:49
so it needs to be tested on arm hardware that can do that
<@nirik:matrix.scrye.com>
19:17:52
uh? what... I thought this was an arm thing?
<@nirik:matrix.scrye.com>
19:18:01
like on x86_64... ah.
<@nirik:matrix.scrye.com>
19:18:15
well, it is going to boot uefi in this case...
<@adamwill:fedora.im>
19:19:28
right, but the idea with this matrix square is to test booting just like you would on x86_64, write the image to a USB stick, attach it, boot. some arm hardware can do that, or at least that's what peter keeps telling me. :P
<@adamwill:fedora.im>
19:19:39
if we can't do it, we can't do it.
<@nirik:matrix.scrye.com>
19:19:43
yes, this is one of those. ;)
<@adamwill:fedora.im>
19:19:48
oh good.
<@nirik:matrix.scrye.com>
19:20:10
except, it rebooted on boot... but that could be just some x1e problem with mainline kernel. ;(
<@adamwill:fedora.im>
19:20:15
fun
<@nirik:matrix.scrye.com>
19:21:27
oh, I see. I need to pass dtb also...
<@adamwill:fedora.im>
19:23:04
siiigh, ec2 instance doesn't want to let me in...
<@adamwill:fedora.im>
19:26:21
okay, i'm in.
<@pwhalen:fedora.im>
19:28:49
470/611 on my server install
<@nirik:matrix.scrye.com>
19:29:10
ok, FWIW, if I pass devicetree to it, it does boot. I am not sure how much this matters for mainstream devices. ;)
<@nirik:matrix.scrye.com>
19:29:35
and as expected, no intternal keyboard/mouse.
<@nirik:matrix.scrye.com>
19:29:41
but firstboot comes up. ;)
<@adamwill:fedora.im>
19:29:45
cloud tests are good, just finishing the last one
<@nirik:matrix.scrye.com>
19:31:19
but gnome-initial-setup comes up. ;)
<@adamwill:fedora.im>
19:33:46
ok, done for x64
<@adamwill:fedora.im>
19:34:11
so i think we're looking good
<@amoloney:fedora.im>
19:34:18
nice!
<@nirik:matrix.scrye.com>
19:35:38
so, ok with coverage in the end? amazing.
<@adamwill:fedora.im>
19:36:58
nirik: since you managed to install and boot and pwhalen seems to be also, sure
<@amoloney:fedora.im>
19:37:10
just waiting on conf from @pwhalen afaiu
<@adamwill:fedora.im>
19:37:11
only hwraid and sas missing at that point i think, and we don't have the hw for those here
<@pwhalen:fedora.im>
19:37:38
its at configuring now, taking a while to finish up
<@adamwill:fedora.im>
19:37:50
i'll run through the aarch64 cloud tests too then
<@adamwill:fedora.im>
19:41:44
cloud tests done on both arches
<@adamwill:fedora.im>
19:41:47
all good
<@nirik:matrix.scrye.com>
19:42:45
cool
<@amoloney:fedora.im>
19:47:19
pwhalen: roughly how long do you think you'd need to wrap up your tests? thank you for doing them, btw
<@geraldosimiao:matrix.org>
19:47:30
good news, SOAS liveinstall bug is fixed!!!!!
<@pwhalen:fedora.im>
19:47:50
should be finished anytime now, generating the initramfs. Just slow hw
<@amoloney:fedora.im>
19:48:08
understood, and thank you
<@adamwill:fedora.im>
19:48:34
lruzicka: go ahead and head out if you like, we don't need everyone any more
<@adamwill:fedora.im>
19:48:40
i will do the vote for qa
<@geraldosimiao:matrix.org>
19:48:41
added a line at matrix for the new spin MiracleWM live, tested id and is working (x86 on VM)
<@amoloney:fedora.im>
19:49:11
yeah at this point I just need someone from QA, FESCo & Releng to make the decision post test coverage part
<@frantisekz:fedora.im>
19:50:30
we're kinda wanting to see it to the finish line at this point 😎 , and enjoy some empty office space :D
<@amoloney:fedora.im>
19:50:56
oh wow! Im impressed you stayed in the office!
<@adamwill:fedora.im>
19:51:03
pwhalen should livestream his install so we all have something to watch. :D
<@amoloney:fedora.im>
19:51:25
I was rushing home to be at least at_home for this marathon, I mean meeting
<@nirik:matrix.scrye.com>
19:51:29
in case anyone wants something to look at/discuss... missing images from 1.2:
<@nirik:matrix.scrye.com>
19:51:33
Jam_KDE no x86_64
<@nirik:matrix.scrye.com>
19:51:33
Workstation no aarch64/ppc64le
<@nirik:matrix.scrye.com>
19:51:33
Design_suite no x86_64
<@nirik:matrix.scrye.com>
19:51:33
KDE no aarch64
<@nirik:matrix.scrye.com>
19:51:33
Robotics no x86_64
<@frantisekz:fedora.im>
19:52:21
that doesn't seem that bad
<@pwhalen:fedora.im>
19:52:35
Server usb install complete, no issues
<@amoloney:fedora.im>
19:53:01
are any of them likely to get pulled in before we ship on Tuesday if this is a go nirik ? Or would that need a new compose to be run?
<@nirik:matrix.scrye.com>
19:53:28
it would need a new compose, so no... but some of them are fixed in the nightly tree now, so people could get them from there post beta
<@amoloney:fedora.im>
19:54:00
ok thats good to hear. We will make sure that msg gets out there if we ship this rc :)
<@nirik:matrix.scrye.com>
19:54:25
we will need to let websites know they are not there for the beta...
<@amoloney:fedora.im>
19:54:34
ack
<@frantisekz:fedora.im>
19:55:22
Jam_KDE and Robotics failed due to python3-colcon-common-extensions being FTI
<@amoloney:fedora.im>
19:55:41
!action @amoloney to coordinate with websites so that the correct information is available on release day that some deliverables are missing from the proposed rc 1.2, but some will be available from the nightly tree and available post release from here
<@adamwill:fedora.im>
19:56:01
i already wrote up the issues at https://pagure.io/releng/failed-composes/issue/6956#comment-931510
<@nirik:matrix.scrye.com>
19:56:18
yep.
<@nirik:matrix.scrye.com>
19:57:07
ok, so where are we? are we waiting for anything further then?
<@adamwill:fedora.im>
19:57:36
don't think so
<@amoloney:fedora.im>
19:58:18
oh! So I can go ahead and !info the test matrices?
<@nirik:matrix.scrye.com>
19:58:35
yep
<@adamwill:fedora.im>
19:59:01
yeah, coverage is sufficient (100% except hardware we don't have)
<@amoloney:fedora.im>
20:00:02
!info Test matrices are complete for RC 1.2 beta and we have sufficient coverage. The only coverage we were unable to provide at this time is testing on sas / hw raid as there was no available hardware.
<@amoloney:fedora.im>
20:00:15
Righteo, I think its now the voting!!
<@geraldosimiao:matrix.org>
20:00:58
🥁
<@amoloney:fedora.im>
20:01:44
!info We also have a number of missing deliverables from RC 1.2, captured in the failed-compose issue https://pagure.io/releng/failed-composes/issue/6956#comment-931510 . Availability of some of these deliverables will be from the nightly tree and will be noted at beta release time
<@amoloney:fedora.im>
20:02:15
!topic Go/No-Go Decision
<@amoloney:fedora.im>
20:02:40
I will now poll each team. Please reply GO or NO-GO
<@amoloney:fedora.im>
20:02:56
QA?
<@adamwill:fedora.im>
20:03:03
GO
<@amoloney:fedora.im>
20:03:05
Releng?
<@lruzicka:matrix.org>
20:03:07
GO
<@nirik:matrix.scrye.com>
20:03:08
shockingly GO.
<@amoloney:fedora.im>
20:03:11
FESCo?
<@sgallagh:fedora.im>
20:03:13
GO
<@geraldosimiao:matrix.org>
20:03:45
GO
<@amoloney:fedora.im>
20:03:45
!info Fedora Linux 41 Beta is GO and will be shipped on Tuesday 17th September 2024
<@amoloney:fedora.im>
20:03:51
thank you all for your hard work!!!
<@amoloney:fedora.im>
20:04:05
and most importantly, patience in these meetings :)
<@frantisekz:fedora.im>
20:04:10
thank you everybody, fyi, I'll secretalize the blockers in about 1-2 hours
<@nirik:matrix.scrye.com>
20:04:10
thanks everyone. :)
<@lruzicka:matrix.org>
20:04:16
Great. Lets have a celebration by the sea.
<@amoloney:fedora.im>
20:04:24
!topic Open Floor
<@geraldosimiao:matrix.org>
20:04:26
🎉
<@adamwill:fedora.im>
20:04:33
yay, thanks everyone
<@lruzicka:matrix.org>
20:04:36
thank you, I am going now :D have a nice time
<@amoloney:fedora.im>
20:04:48
any other business, or can I release you from your meeting-bonds?
<@nirik:matrix.scrye.com>
20:05:28
I am going to celebrate with lunch.
<@amoloney:fedora.im>
20:06:01
!endmeeting