<@adamwill:fedora.im>
17:00:06
!startmeeting F40-blocker-review
<@meetbot:fedora.im>
17:00:07
Meeting started at 2024-02-19 17:00:06 UTC
<@meetbot:fedora.im>
17:00:07
The Meeting name is 'F40-blocker-review'
<@adamwill:fedora.im>
17:00:10
!topic Roll Call
<@lruzicka:matrix.org>
17:00:52
I want to apologise, I need to go out and can't take part. I have voted online. Sorry about that.
<@pboy:fedora.im>
17:01:25
!hi
<@zodbot:fedora.im>
17:01:27
Peter Boy (pboy)
<@coremodule:fedora.im>
17:01:53
!hello
<@zodbot:fedora.im>
17:01:54
Geoffrey Marr (coremodule)
<@coremodule:fedora.im>
17:01:58
Willing to act as secretary.
<@adamwill:fedora.im>
17:02:39
thanks!
<@adamwill:fedora.im>
17:02:42
how's everyone doing?
<@adamwill:fedora.im>
17:02:46
lruzicka: thanks for voting!
<@conan_kudo:matrix.org>
17:02:55
!hi
<@zodbot:fedora.im>
17:02:57
Neal Gompa (ngompa) - he / him / his
<@davdunc:fedora.im>
17:03:05
!hi
<@zodbot:fedora.im>
17:03:06
David Duncan (davdunc) - he / him / his
<@jkonecny:fedora.im>
17:03:10
!hi
<@zodbot:fedora.im>
17:03:11
Jiří Konečný (jkonecny)
<@frantisekz:fedora.im>
17:04:24
!hi
<@zodbot:fedora.im>
17:04:25
František Zatloukal (frantisekz)
<@sumantrom:fedora.im>
17:04:33
!hi
<@zodbot:fedora.im>
17:04:34
Sumantro Mukherjee (sumantrom) - he / him / his
<@amoloney:fedora.im>
17:06:11
!hi
<@zodbot:fedora.im>
17:06:13
Aoife Moloney (amoloney)
<@adamwill:fedora.im>
17:06:31
hi hi folks
<@adamwill:fedora.im>
17:06:37
alrighty, let's get rolling, boilerplate time
<@jkonecny:fedora.im>
17:06:52
Hi everyone
<@adamwill:fedora.im>
17:06:54
i'll try to move things a bit faster this week, sorry about last week
<@adamwill:fedora.im>
17:06:56
!topic Introduction
<@adamwill:fedora.im>
17:06:58
Why are we here?
<@adamwill:fedora.im>
17:07:02
!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:07:05
!info We'll be following the process outlined at:
<@adamwill:fedora.im>
17:07:07
!link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
<@adamwill:fedora.im>
17:07:09
!info The bugs up for review today are available at:
<@adamwill:fedora.im>
17:07:11
!link http://qa.fedoraproject.org/blockerbugs/current
<@adamwill:fedora.im>
17:07:14
!info The criteria for release blocking bugs can be found at:
<@adamwill:fedora.im>
17:07:16
!link https://fedoraproject.org/wiki/Basic_Release_Criteria
<@adamwill:fedora.im>
17:07:18
!link https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria
<@adamwill:fedora.im>
17:07:21
!link https://fedoraproject.org/wiki/Fedora_40_Final_Release_Criteria
<@adamwill:fedora.im>
17:07:26
!info for Beta, we have:
<@adamwill:fedora.im>
17:07:37
!info 9 Proposed Blockers
<@adamwill:fedora.im>
17:07:40
!info 5 Accepted Blockers
<@adamwill:fedora.im>
17:07:44
!info 1 Accepted Previous Release Blockers
<@adamwill:fedora.im>
17:07:47
!info 1 Proposed Freeze Exceptions
<@adamwill:fedora.im>
17:07:49
!info 6 Accepted Freeze Exceptions
<@adamwill:fedora.im>
17:07:56
!info for Final, we have:
<@adamwill:fedora.im>
17:08:03
!info 4 Proposed Blockers
<@adamwill:fedora.im>
17:08:12
!info coremodule will act as secretary
<@adamwill:fedora.im>
17:08:17
let's get started with:
<@adamwill:fedora.im>
17:08:21
!topic Proposed Beta blockers
<@adamwill:fedora.im>
17:08:28
!topic (2264419) webui: non-root btrfs subvolumes are not mounted correctly
<@adamwill:fedora.im>
17:08:31
!link https://bugzilla.redhat.com/show_bug.cgi?id=2264419
<@adamwill:fedora.im>
17:08:33
!link https://pagure.io/fedora-qa/blocker-review/issue/1464
<@adamwill:fedora.im>
17:08:36
!info Proposed Blocker, anaconda, POST
<@adamwill:fedora.im>
17:08:41
!info Ticket vote: BetaBlocker (+2,0,-0) (+lruzicka, +geraldosimiao)
<@kparal:matrix.org>
17:09:50
+1 blocker
<@frantisekz:fedora.im>
17:10:02
+1 Beta Blocker
<@kparal:matrix.org>
17:10:03
you just can't simulate a default partition layout with this bug
<@conan_kudo:matrix.org>
17:10:25
+1 blocker
<@adamwill:fedora.im>
17:11:53
jkonecny: do you have any thoughts on this one?
<@jkonecny:fedora.im>
17:12:24
+1 blocker
<@sumantrom:fedora.im>
17:12:28
I voted in. Its a +1BetaBlocker for me
<@jkonecny:fedora.im>
17:12:53
There is already fix provided
<@adamwill:fedora.im>
17:13:12
proposed !agreed 2264419 - AcceptedBlocker (Beta) - this is accepted as a violation of "Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions", applied to the webui partitioning flow
<@frantisekz:fedora.im>
17:13:22
ack
<@kparal:matrix.org>
17:13:40
ack
<@sumantrom:fedora.im>
17:13:50
ack
<@conan_kudo:matrix.org>
17:14:10
ack
<@jkonecny:fedora.im>
17:14:43
ack
<@adamwill:fedora.im>
17:15:19
!agreed 2264419 - AcceptedBlocker (Beta) - this is accepted as a violation of "Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions", applied to the webui partitioning flow
<@adamwill:fedora.im>
17:15:27
!topic (2263964) Cockpit storage: cannot "Remove a planned storage volume from the planned layout" as required in the release criteria
<@adamwill:fedora.im>
17:15:29
!link https://bugzilla.redhat.com/show_bug.cgi?id=2263964
<@adamwill:fedora.im>
17:15:31
!link https://pagure.io/fedora-qa/blocker-review/issue/1459
<@adamwill:fedora.im>
17:15:33
!info Proposed Blocker, distribution, ASSIGNED
<@adamwill:fedora.im>
17:15:35
!info Ticket vote: BetaBlocker (+1,1,-1) (+asciiwolf, geraldosimiao, -frantisekz)
<@adamwill:fedora.im>
17:15:41
so, this is the big controversial one
<@adamwill:fedora.im>
17:16:02
the criterion violation seems clear enough. the question is what to do about it. i'd kinda want to wait till we hear from fesco on https://pagure.io/fesco/issue/3169
<@adamwill:fedora.im>
17:16:13
though it'd be nice to see a bit more movement on that ticket
<@conan_kudo:matrix.org>
17:16:30
+1 blocker
<@jkonecny:fedora.im>
17:16:40
What movement do you expect to see?
<@kparal:matrix.org>
17:16:42
in my view fesco should decide whether this is ok or not. Our place is to make sure software works as designed, this was one designed without planning.
<@frantisekz:fedora.im>
17:17:05
as I said in the voting ticket, I eel this is for someone else to decide, and from a qe standpoint, this feels more like an rfe, imo
<@conan_kudo:matrix.org>
17:17:27
I'm honestly a little shocked that this isn't a thing. Being able to tally up actions and only submit it to udisks when we're ready to apply seems like a logical thing to do given all the other partitioning tools do similar things.
<@frantisekz:fedora.im>
17:17:39
as I said in the voting ticket, I feel this is for someone else to decide, and from a qe standpoint, this feels more like an rfe, imo
<@jkonecny:fedora.im>
17:17:43
The bug is not a bug. It is about preference and agreement.
<@kparal:matrix.org>
17:17:59
I agree it's a UX regression for users. But I don't think blocker meeting is the right place to accept or reject it.
<@kparal:matrix.org>
17:18:20
it's not a bug, it's an intentional design change
<@adamwill:fedora.im>
17:18:23
jkonecny: well, the ticket asks for fesco to 'weigh in' , i guess i'm expecting their input on whether they think it's ok to change the criteria and land this now, or whether they want to put it on a delayed schedule, or whatever
<@adamwill:fedora.im>
17:18:46
i doubt they'd say 'no you must revert to blivet-gui!' or 'no you must rewrite udisks!' because they don't generally dictate engineering decisions like that, but it's hard to prejudge
<@adamwill:fedora.im>
17:19:18
i doubt they'd say 'no you must revert to blivet-gui!' or 'no you must rewrite udisks!' because they don't generally dictate upstream design decisions like that, but it's hard to prejudge
<@kparal:matrix.org>
17:19:21
also I don't expect that that criterion was written with "planning must be present" in mind
<@jkonecny:fedora.im>
17:19:26
Issue is that is exactly what is discussed on the bug
<@conan_kudo:matrix.org>
17:20:46
I don't feel this was an agreed-upon intentional design change. I know that I and other members of FESCo were completely unaware of this consequence.
<@conan_kudo:matrix.org>
17:21:02
We had no idea this was going to happen with web UI anaconda
<@adamwill:fedora.im>
17:21:05
jkonecny: there are nine people in fesco, only three have posted on the bug (and only two have had really strong opinions)
<@jkonecny:fedora.im>
17:21:10
What would be outcome of taking this as a blocker? It means that the design is rejected, isn't it?
<@adamwill:fedora.im>
17:21:13
so nothing there is particularly decisive
<@kparal:matrix.org>
17:21:16
it's intentional and not agreed upon 🙂
<@adamwill:fedora.im>
17:21:29
jkonecny: it would, but i don't think we're intending to do things that way around
<@adamwill:fedora.im>
17:21:52
which is why i'm suggesting we defer to fesco
<@conan_kudo:matrix.org>
17:22:22
likely if fesco pushed about this, we'd wind up deferring webui in Fedora another cycle
<@adamwill:fedora.im>
17:22:23
but given how close we are to beta freeze and release, we do need this tracked as at least a proposed blocker, because it affects the release process. it needs to not get forgotten
<@conan_kudo:matrix.org>
17:22:30
that's the safest outcome
<@jkonecny:fedora.im>
17:22:35
In that case Anaconda team can't fix it and close it as Won't fix. There is just not a way to fix it.
<@adamwill:fedora.im>
17:22:36
you might think it's too big of a deal to forget, but you'd be amazed what i can forget when it comes to filing RC tickets. :P
<@conan_kudo:matrix.org>
17:23:06
jkonecny: it's not Anaconda to fix, since this is now a cockpit problem
<@adamwill:fedora.im>
17:23:14
jkonecny: we need it to be open to keep it tracked. i moved it back to 'distribution' to make it clear the responsibility is not really on anaconda team atm.
<@conan_kudo:matrix.org>
17:23:25
but users do not care whether it's anaconda or cockpit or something else... it's part of the integrated flow
<@adamwill:fedora.im>
17:23:38
it is not a "bug" in anaconda, precisely. it's a situation we need to manage at a distribution level.
<@jkonecny:fedora.im>
17:23:43
The bug would end up on F41 and we are still on the same page. Which is blocking the implementation.
<@jkonecny:fedora.im>
17:24:25
Cockpit can't resolve that
<@jkonecny:fedora.im>
17:24:35
You are blocking the whole effort by this
<@adamwill:fedora.im>
17:24:57
i will point out there seems to be one member of fesco present here
<@adamwill:fedora.im>
17:25:02
we cannot make fesco's decision in this meeting
<@adamwill:fedora.im>
17:25:08
so there isn't much to be gained by arguing about it here
<@conan_kudo:matrix.org>
17:25:36
fesco's meeting is two hours from now, y'all can argue about it there
<@adamwill:fedora.im>
17:25:50
Conan Kudo: btw, why isn't this issue tagged for the meeting?
<@adamwill:fedora.im>
17:26:02
marcdeop: sorry, we are getting into process weeds a bit
<@adamwill:fedora.im>
17:26:08
normal service will be resumed shortly :P
<@conan_kudo:matrix.org>
17:26:11
I have no idea
<@conan_kudo:matrix.org>
17:26:13
I'm tagging it
<@jkonecny:fedora.im>
17:26:16
Still I don't understand the outcome of this bug
<@adamwill:fedora.im>
17:26:18
thanks
<@jkonecny:fedora.im>
17:26:34
In any case it can''t be fixed
<@adamwill:fedora.im>
17:26:35
jkonecny: basically my expectation is that what we do with the bug will be determined by what fesco decides
<@adamwill:fedora.im>
17:26:48
i'm intending to attend the fesco meeting and try to explain the practical options
<@adamwill:fedora.im>
17:27:03
i guess you'll come too? or is it too late?
<@jkonecny:fedora.im>
17:27:04
OK, I see
<@jkonecny:fedora.im>
17:27:53
Not sure, even now I'm taking care of kids. It could be pretty challenging for me to join 😞
<@adamwill:fedora.im>
17:28:16
as i said, we need the bug to exist more or less for procedural reasons. the proposed/accepted blocker list is pretty much the Official Task List for releases. if something isn't on the blocker tracker it more or less doesn't exist so far as the release process is concerned. the existence of the bug and its proposed blocker status is entirely because of that.
<@adamwill:fedora.im>
17:28:51
ok, if you're not there i'll try and make sure all your points are covered
<@adamwill:fedora.im>
17:29:16
so:
<@jkonecny:fedora.im>
17:29:37
Thank you, hopefully someone else from installer will be able to join
<@adamwill:fedora.im>
17:31:29
proposed !agreed 2263964 - punt (delay decision) - this is clearly a criteria violation, but it is not a straightforward "bug", rather an upstream design choice which was not understood downstream until recently. it is part of an official Change, but was not fully covered in that Change's scope. as this is well outside of the scope of a "bug" process and involves the Change process, we will defer to FESCo's decision on https://pagure.io/fesco/issue/3169 in deciding the status of this bug.
<@adamwill:fedora.im>
17:31:50
proposed !agreed 2263964 - punt (delay decision) - this is clearly a criteria violation, but it is not a straightforward "bug", rather an upstream design choice which was not understood downstream until recently. it is part of an official Change, but was not fully covered in that Change's scope. as this is well outside of the scope of a "bug" process and involves the Change process, we will defer to FESCo's decision on https://pagure.io/fesco/issue/3169 in deciding the status of this bug, and whether to change the release criteria.
<@frantisekz:fedora.im>
17:32:44
ack
<@sumantrom:fedora.im>
17:32:48
ack
<@kparal:matrix.org>
17:33:07
ack
<@jkonecny:fedora.im>
17:33:10
ack
<@adamwill:fedora.im>
17:33:44
!agreed 2263964 - punt (delay decision) - this is clearly a criteria violation, but it is not a straightforward "bug", rather an upstream design choice which was not understood downstream until recently. it is part of an official Change, but was not fully covered in that Change's scope. as this is well outside of the scope of a "bug" process and involves the Change process, we will defer to FESCo's decision on https://pagure.io/fesco/issue/3169 in deciding the status of this bug, and whether to change the release criteria.
<@adamwill:fedora.im>
17:34:01
!topic (2264795) Workstation iso filesystem has incorrect filesystem label
<@adamwill:fedora.im>
17:34:05
!link https://bugzilla.redhat.com/show_bug.cgi?id=2264795
<@adamwill:fedora.im>
17:34:07
!link https://pagure.io/fedora-qa/blocker-review/issue/1466
<@adamwill:fedora.im>
17:34:10
!info Proposed Blocker, distribution, NEW
<@adamwill:fedora.im>
17:34:12
!info Ticket vote: BetaBlocker (+3,0,-0) (+lruzicka, +geraldosimiao, +sumantrom)'
<@adamwill:fedora.im>
17:34:28
this got +3, but i don't think it's correct. it regards an image that is not release-blocking.
<@conan_kudo:matrix.org>
17:34:39
what?
<@frantisekz:fedora.im>
17:34:47
yeah, wanted to ask, how is it with osbuilder
<@conan_kudo:matrix.org>
17:34:47
Workstation is release-blocking
<@frantisekz:fedora.im>
17:35:01
this is an issue on the osbuild image only afaik
<@adamwill:fedora.im>
17:35:04
the osbuild live image for aarch64 is very not
<@conan_kudo:matrix.org>
17:35:20
the osbuild images are not RB at all
<@adamwill:fedora.im>
17:35:34
the only blocking aarch64 workstation image is the .raw.xz disk image
<@conan_kudo:matrix.org>
17:35:36
however, I would gate issues like this on it ever graduating to RB
<@conan_kudo:matrix.org>
17:35:54
I don't know how to handle voting in that case though
<@adamwill:fedora.im>
17:35:57
marcdeop: it's https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder
<@adamwill:fedora.im>
17:36:12
Conan Kudo: well, even then, the live .iso for aarch64 is not release blocking
<@adamwill:fedora.im>
17:36:21
but still, it's well outside this meeting's scope
<@conan_kudo:matrix.org>
17:36:27
does it affect x86_64?
<@adamwill:fedora.im>
17:36:28
for blocker purposes, it's very easy to handle, we vote -1. like this :D
<@conan_kudo:matrix.org>
17:36:36
lol
<@adamwill:fedora.im>
17:36:39
Conan Kudo: dunno. worth checking, i guess, but still not blocking
<@adamwill:fedora.im>
17:36:50
the bug should block the change tracker bug i guess
<@conan_kudo:matrix.org>
17:36:52
not blocking until it is :P
<@conan_kudo:matrix.org>
17:36:53
but sure
<@conan_kudo:matrix.org>
17:36:54
-1
<@marcdeop:matrix.org>
17:36:56
-1
<@adamwill:fedora.im>
17:37:04
i'll do that
<@conan_kudo:matrix.org>
17:37:24
it would not surprise me if the labels are wrong for all osbuild artifacts
<@conan_kudo:matrix.org>
17:37:35
last I checked, this is not configurable
<@kparal:matrix.org>
17:37:40
-1 blocker
<@conan_kudo:matrix.org>
17:37:53
last I checked, this is not configurable (though it should be)
<@geraldosimiao:matrix.org>
17:38:04
Sorry I'm late
<@frantisekz:fedora.im>
17:38:08
anyhow, -1 blocker
<@geraldosimiao:matrix.org>
17:38:13
!hi
<@zodbot:fedora.im>
17:38:14
Geraldo S. Simião Kutz (geraldosimiao) - he / him / his
<@sumantrom:fedora.im>
17:38:55
In that case, I retact to -1
<@adamwill:fedora.im>
17:38:58
hi geraldosimiao
<@geraldosimiao:matrix.org>
17:39:14
Oh, that image is non blocking material?
<@adamwill:fedora.im>
17:39:28
yeah - see https://docs.fedoraproject.org/en-US/releases/f40/blocking/
<@geraldosimiao:matrix.org>
17:39:29
So I revert to -1
<@adamwill:fedora.im>
17:39:36
Conan Kudo: yes, thanks for that
<@adamwill:fedora.im>
17:39:45
although, if it had been blocking, we'd obviously be testing it harder
<@adamwill:fedora.im>
17:39:52
i *still* need to wire up openqa to test the osbuild image...sgih
<@conan_kudo:matrix.org>
17:40:06
I was very much worried that the basics wouldn't be in good shape
<@conan_kudo:matrix.org>
17:40:13
given my own experiences with it
<@sumantrom:fedora.im>
17:40:35
build systems and deliverables we get off the new buildsystem should never ideally be made blocking
<@adamwill:fedora.im>
17:40:40
ok, with that i think we have -7 / +1 (lruzicka isn't around to revote), so:
<@conan_kudo:matrix.org>
17:41:06
there is no new build system, but deliverables need blocking status to be tested and ensured useful
<@conan_kudo:matrix.org>
17:41:16
it's not a technology issue, it's a process and quality issue
<@adamwill:fedora.im>
17:41:18
oh, do we want to +1 FE it?
<@conan_kudo:matrix.org>
17:41:24
yeah
<@conan_kudo:matrix.org>
17:41:28
+1 FE
<@adamwill:fedora.im>
17:41:34
+1 FE for me too
<@frantisekz:fedora.im>
17:41:36
+1 FE, why not
<@marcdeop:matrix.org>
17:41:46
+1 FE
<@sumantrom:fedora.im>
17:41:50
sure +1 FE
<@geraldosimiao:matrix.org>
17:41:51
Yeah +1 FE
<@jkonecny:fedora.im>
17:41:58
+1 FE
<@frantisekz:fedora.im>
17:41:58
(on the other hand, you know me, I am +1 FE on anything basically ...)
<@geraldosimiao:matrix.org>
17:42:33
Let the packages run free
<@adamwill:fedora.im>
17:42:43
proposed !agreed 2264795 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this is rejected as it concerns an image which is not release-blocking . However, it's accepted as FE on the general principle we accept this kind of issue in non-blocking images as FE instead, but we will only land a fix that could not endanger blocking images
<@geraldosimiao:matrix.org>
17:42:46
;)
<@geraldosimiao:matrix.org>
17:43:06
Ack
<@frantisekz:fedora.im>
17:43:10
ack
<@conan_kudo:matrix.org>
17:43:48
ack
<@sumantrom:fedora.im>
17:44:12
ack
<@adamwill:fedora.im>
17:44:19
!agreed 2264795 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this is rejected as it concerns an image which is not release-blocking . However, it's accepted as FE on the general principle we accept this kind of issue in non-blocking images as FE instead, but we will only land a fix that could not endanger blocking images
<@adamwill:fedora.im>
17:44:26
!topic (2264415) Raspberry Pi 4 and 400 won't boot into graphical environment
<@adamwill:fedora.im>
17:44:28
!link https://bugzilla.redhat.com/show_bug.cgi?id=2264415
<@adamwill:fedora.im>
17:44:30
!link https://pagure.io/fedora-qa/blocker-review/issue/1463
<@adamwill:fedora.im>
17:44:34
!info Proposed Blocker, gdm, NEW
<@adamwill:fedora.im>
17:44:37
!info Ticket vote: BetaBlocker (+0,0,-1) (-catanzaro)
<@adamwill:fedora.im>
17:44:41
brb, call of nature - discuss among yourselves
<@conan_kudo:matrix.org>
17:45:16
wait, we can boot on RPi 400? since when?
<@frantisekz:fedora.im>
17:45:38
so, for this one, we're planning to give kde spin a try with lbrabec, to at least find out if it's a gnome or some lower in the stack issue
<@conan_kudo:matrix.org>
17:46:09
cool
<@frantisekz:fedora.im>
17:46:09
he tested that pretty recently, a few days before making the report, so I don't have tighter time-frame hen this went south
<@conan_kudo:matrix.org>
17:46:14
you anticipated my question :)
<@conan_kudo:matrix.org>
17:47:06
it's odd that this is attempting to boot X instead of Wayland though
<@marcdeop:matrix.org>
17:47:07
kde spin on rpi would be great... :-)
<@conan_kudo:matrix.org>
17:47:23
it shouldn't be doing that in the first place
<@geraldosimiao:matrix.org>
17:48:29
I didn't understood clearly if this is a software or hardware issue
<@adamwill:fedora.im>
17:49:04
to be honest, i'm not sure it matters
<@adamwill:fedora.im>
17:49:15
arm is a bit different from x86_64 here
<@adamwill:fedora.im>
17:49:24
on arm we have a list of supported platforms and we expect the criteria to be met on those
<@adamwill:fedora.im>
17:49:28
pi 4 is definitely on that list
<@adamwill:fedora.im>
17:50:36
if we're sure pi 4 doesn't get to a desktop in the only blocking desktop image, that's a blocker for me
<@conan_kudo:matrix.org>
17:50:57
KDE on AArch64 isn't blocking? I thought it's supposed to be.
<@conan_kudo:matrix.org>
17:51:04
I vaguely thought I asked for this a few releases back...
<@adamwill:fedora.im>
17:51:05
(kde is not blocking for aarch64)
<@conan_kudo:matrix.org>
17:51:21
something to fix then
<@conan_kudo:matrix.org>
17:51:41
no way I tolerate AArch64 breakage for KDE Plasma
<@frantisekz:fedora.im>
17:52:12
yeah, we're pretty sure about pi 4 too here
<@frantisekz:fedora.im>
17:52:34
KDE was meant only to figure out if the issue is (not) in GNOME or some different component
<@conan_kudo:matrix.org>
17:52:38
(esp since KDE Plasma is the flagship for FAR)
<@adamwill:fedora.im>
17:53:48
https://docs.fedoraproject.org/en-US/releases/f40/blocking/
<@adamwill:fedora.im>
17:54:25
https://fedoraproject.org/wiki/Basic_Release_Criteria#Basic_Release_Requirements
<@conan_kudo:matrix.org>
17:54:28
I'll talk to you after this meeting about fixing that so we have KDE AArch64 as release blocking
<@adamwill:fedora.im>
17:54:32
"The term release-blocking desktops means all the desktop environments in which bugs are currently considered capable of blocking a Fedora release. The current set of release-blocking desktops for x86_64 is GNOME and KDE, and for aarch64 is GNOME."
<@adamwill:fedora.im>
17:54:47
that would be a rather major change that'd need some discussion i think
<@adamwill:fedora.im>
17:54:53
anyhoo
<@marcdeop:matrix.org>
17:55:00
let's have that discussion then :-)
<@adamwill:fedora.im>
17:55:01
i'm +1 on this at least for now
<@marcdeop:matrix.org>
17:55:09
(not now)
<@conan_kudo:matrix.org>
17:55:19
At this point, the KDE SIG considers both x86_64 and aarch64 at the same level, so I don't think it's as significant it may fear to be. :)
<@adamwill:fedora.im>
17:55:36
it would be a bunch more testing on annoying hardware for us, for a start
<@conan_kudo:matrix.org>
17:55:40
anyway, _this_ issue is blockery, so +1 Blocker
<@geraldosimiao:matrix.org>
17:55:40
Ok, so BetaBlocker +1
<@frantisekz:fedora.im>
17:56:32
BetaBlocker +1
but what about the criterion?
<@frantisekz:fedora.im>
17:56:41
catanzaro mentioned the proposed is not the proper one
<@frantisekz:fedora.im>
17:56:46
in the voting ticket
<@adamwill:fedora.im>
17:57:15
no, I think the criterion is fine
<@adamwill:fedora.im>
17:57:27
i just think mcatanzaro maybe wasn't thinking about the specifics of ARM
<@marcdeop:matrix.org>
17:57:40
BetaBlocker +1
<@adamwill:fedora.im>
17:57:41
if he was here we could chat about it, but he doesn't seem to be
<@adamwill:fedora.im>
17:58:00
i'll add a comment to the ticket for him, we can always re-discuss if he has concerns
<@geraldosimiao:matrix.org>
17:58:23
Good idea
<@adamwill:fedora.im>
18:02:05
hmm, actually
<@adamwill:fedora.im>
18:02:40
we can cite "Release-blocking ARM disk images must boot to the initial-setup utility" in https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_image_boot_behavior , that seems clearer-cut
<@adamwill:fedora.im>
18:02:59
since it comes right under the "Supported ARM platforms" definition
<@adamwill:fedora.im>
18:03:07
the bug does violate that, right? we don't reach g-i-s on the workstation image?
<@conan_kudo:matrix.org>
18:03:15
yes
<@conan_kudo:matrix.org>
18:03:24
since gdm doesn't load, we don't get to g-i-s
<@jkonecny:fedora.im>
18:03:39
Interesting there is criteria for Initial setup. Good to know
<@adamwill:fedora.im>
18:03:50
well, that's not really the intent
<@adamwill:fedora.im>
18:04:00
the intent is "images must boot to the thing they're supposed to boot to"
<@adamwill:fedora.im>
18:04:15
so it's just a laundry list of "intended things to boot to" for all the blocking image types. if the intent changes, we'd have to update the list
<@adamwill:fedora.im>
18:04:46
criteria wording, it's a whole thing
<@adamwill:fedora.im>
18:05:46
proposed !agreed 2264415 - AcceptedBlocker (Beta) - this is accepted as a violation of Basic criterion "Release-blocking ARM disk images must boot to the initial-setup utility" for the ARM Workstation disk image (which is release-blocking) on the Raspberry PI 4 (which is a "supported ARM platform" as defined right above that criterion)
<@conan_kudo:matrix.org>
18:06:03
ack
<@frantisekz:fedora.im>
18:07:59
yes
<@geraldosimiao:matrix.org>
18:08:11
Ack
<@frantisekz:fedora.im>
18:08:15
ack
<@sumantrom:fedora.im>
18:10:03
ack
<@adamwill:fedora.im>
18:10:15
!agreed 2264415 - AcceptedBlocker (Beta) - this is accepted as a violation of Basic criterion "Release-blocking ARM disk images must boot to the initial-setup utility" for the ARM Workstation disk image (which is release-blocking) on the Raspberry PI 4 (which is a "supported ARM platform" as defined right above that criterion)
<@adamwill:fedora.im>
18:10:22
!topic (2263952) Update the background-logo extension for 46.beta
<@adamwill:fedora.im>
18:10:26
!link https://bugzilla.redhat.com/show_bug.cgi?id=2263952
<@adamwill:fedora.im>
18:10:28
!link https://pagure.io/fedora-qa/blocker-review/issue/1460
<@adamwill:fedora.im>
18:10:31
!info Proposed Blocker, gnome-shell-extension-background-logo, NEW
<@adamwill:fedora.im>
18:10:33
!info Ticket vote: BetaBlocker (+4,0,-1) (+asciiwolf, +catanzaro, +geraldosimiao, +lruzicka, -adamwill)
<@adamwill:fedora.im>
18:10:35
!info Ticket vote: BetaFreezeException (+1,0,-0) (+asciiwolf)
<@adamwill:fedora.im>
18:10:44
so this got +4, but i left it on the list because you're all wrong, damnit :P
<@adamwill:fedora.im>
18:11:00
does somebody have a criterion to cite for this? AFAIK there is not one
<@adamwill:fedora.im>
18:11:03
we could add one, but... there isn't one.
<@conan_kudo:matrix.org>
18:11:35
we should have a branding criterion
<@adamwill:fedora.im>
18:12:08
the closest thing is the background criterion, but it is specifically about the *background* (not a logo superimposed on it) and it's for Final not beta
<@adamwill:fedora.im>
18:13:57
i am certainly +1 FE, though
<@conan_kudo:matrix.org>
18:14:10
+1 blocker (on principle) +1 FE
<@frantisekz:fedora.im>
18:14:12
yeah, we can go +1 FE now
<@kparal:matrix.org>
18:15:14
-1 blocker +1 FE
<@sumantrom:fedora.im>
18:16:17
-1 Blocker
<@sumantrom:fedora.im>
18:16:36
+1 FE
<@pboy:fedora.im>
18:17:33
Sorry, I have to leave because of a work date. Adam knows about the current state of Server aarch64 issue.
<@adamwill:fedora.im>
18:17:37
thanks peter
<@adamwill:fedora.im>
18:18:15
geraldosimiao: do you want to keep your vote or change?
<@geraldosimiao:matrix.org>
18:18:39
I can change
<@geraldosimiao:matrix.org>
18:18:48
But keep FE
<@geraldosimiao:matrix.org>
18:19:08
-1 BetaBlocker
+1 FE
<@adamwill:fedora.im>
18:19:22
alright, so we have a split blocker vote and a clear +1 fe now
<@adamwill:fedora.im>
18:20:18
proposed !agreed 2263952 - punt (delay decision) on blocker status, AcceptedFreezeException (Beta) - the vote for blocker status is split, +4 / -4 at present, with no criterion cited. There is a clear consensus for FE status, however.
<@frantisekz:fedora.im>
18:20:52
ack
<@kparal:matrix.org>
18:20:58
proposal: grant double votes to all people present 😉
<@adamwill:fedora.im>
18:21:21
better proposal: grant me all the votes
<@kparal:matrix.org>
18:21:22
sure, ack
<@frantisekz:fedora.im>
18:21:33
aand lets start premium qa membership while at it, pay to vote the quadruple!
<@sumantrom:fedora.im>
18:21:36
ack
<@geraldosimiao:matrix.org>
18:21:37
Ack
<@adamwill:fedora.im>
18:21:40
ooooh i like that one
<@adamwill:fedora.im>
18:21:58
also you get a blue check next to your nickname in matrix
<@frantisekz:fedora.im>
18:22:08
👌👌😁
<@geraldosimiao:matrix.org>
18:22:13
Google likes this 😊
<@geraldosimiao:matrix.org>
18:22:36
Wow 😄
<@adamwill:fedora.im>
18:22:38
!agreed 2263952 - punt (delay decision) on blocker status, AcceptedFreezeException (Beta) - the vote for blocker status is split, +4 / -4 at present, with no criterion cited. There is a clear consensus for FE status, however.
<@adamwill:fedora.im>
18:22:45
!topic (2264794) Need to include devcietree files on aarch64 systems iso media
<@adamwill:fedora.im>
18:22:48
!link https://bugzilla.redhat.com/show_bug.cgi?id=2264794
<@adamwill:fedora.im>
18:22:50
!link https://pagure.io/fedora-qa/blocker-review/issue/1465
<@adamwill:fedora.im>
18:22:53
!info Proposed Blocker, lorax, NEW
<@adamwill:fedora.im>
18:23:49
as bcl says, this needs more details, but I *suspect* this also involves non-blocking media
<@conan_kudo:matrix.org>
18:24:00
+1 blocker, +1 fe
<@sumantrom:fedora.im>
18:24:21
+1 Beta Blocker
<@adamwill:fedora.im>
18:24:26
i'm +/-0 ATM
<@adamwill:fedora.im>
18:24:31
since we don't know what image or hardware is affected
<@adamwill:fedora.im>
18:24:36
that seems like important information
<@frantisekz:fedora.im>
18:24:47
yeah, +1 punt?
<@frantisekz:fedora.im>
18:26:08
(we can make it a fe anyway though)
<@adamwill:fedora.im>
18:27:06
i've added a comment on the bug asking for that info
<@geraldosimiao:matrix.org>
18:29:07
+1 punt
<@adamwill:fedora.im>
18:29:56
proposed !agreed 2263952 - punt (delay decision) - the report does not explain which images or hardware platforms are affected by this, which seems like required information to make a blocker decision
<@conan_kudo:matrix.org>
18:30:34
ack
<@sumantrom:fedora.im>
18:31:50
ack
<@frantisekz:fedora.im>
18:32:25
ack
<@adamwill:fedora.im>
18:33:18
!agreed 2263952 - punt (delay decision) - the report does not explain which images or hardware platforms are affected by this, which seems like required information to make a blocker decision
<@adamwill:fedora.im>
18:33:38
!topic (2264814) AArch64 livemedia creation fails due to running out of space
<@adamwill:fedora.im>
18:33:41
!link https://bugzilla.redhat.com/show_bug.cgi?id=2264814
<@adamwill:fedora.im>
18:33:45
!link https://pagure.io/fedora-qa/blocker-review/issue/1467
<@adamwill:fedora.im>
18:33:48
!info Proposed Blocker, lorax, NEW
<@adamwill:fedora.im>
18:33:58
again, i don't believe this can be blocking as the medium in question is not.
<@geraldosimiao:matrix.org>
18:34:21
Ack
<@adamwill:fedora.im>
18:34:38
-1 blocker
<@adamwill:fedora.im>
18:35:27
heya jednorozec
<@frantisekz:fedora.im>
18:36:13
-1 Blocker
<@humaton:fedora.im>
18:36:28
-1
<@adamwill:fedora.im>
18:36:41
+1 FE
<@frantisekz:fedora.im>
18:36:56
yeah, sure, +1 FE, but I'd say the fix would be infra side?
<@adamwill:fedora.im>
18:37:09
yeah, but they consider the freeze as applying to infra stuff
<@adamwill:fedora.im>
18:37:15
so it's useful if we grant things FEs
<@adamwill:fedora.im>
18:37:59
proposed !agreed 2264814 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this concerns an image that is not on the blocking list at https://docs.fedoraproject.org/en-US/releases/f40/blocking/ (the aarch64 Workstation live ISO), so it cannot be a blocker. However, as it's always good for images to build, we do grant an FE
<@frantisekz:fedora.im>
18:38:13
ack
<@humaton:fedora.im>
18:38:20
ack
<@frantisekz:fedora.im>
18:41:40
I guess no more acks for ya adamw , bunch of seens...
<@adamwill:fedora.im>
18:42:01
hehe
<@sumantrom:fedora.im>
18:42:05
adamw: ack
<@geraldosimiao:matrix.org>
18:42:06
ack
<@adamwill:fedora.im>
18:42:06
cya sumantro, thanks for coming
<@sumantrom:fedora.im>
18:42:07
:)
<@adamwill:fedora.im>
18:42:11
yeah, let's go in two-ack mode to get through the list
<@frantisekz:fedora.im>
18:42:14
gnight sumantro!
<@adamwill:fedora.im>
18:42:18
!agreed 2264814 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this concerns an image that is not on the blocking list at https://docs.fedoraproject.org/en-US/releases/f40/blocking/ (the aarch64 Workstation live ISO), so it cannot be a blocker. However, as it's always good for images to build, we do grant an FE
<@adamwill:fedora.im>
18:42:29
!topic (2236356) the software raid disk becomes unusable after click "Rescan" twice
<@adamwill:fedora.im>
18:42:33
!link https://bugzilla.redhat.com/show_bug.cgi?id=2236356
<@adamwill:fedora.im>
18:42:36
!link https://pagure.io/fedora-qa/blocker-review/issue/1321
<@adamwill:fedora.im>
18:42:39
!info Proposed Blocker, python-blivet, ASSIGNED
<@adamwill:fedora.im>
18:42:41
!info Ticket vote: BetaBlocker (+2,0,-0) (+nielsenb, +geraldosimiao)
<@adamwill:fedora.im>
18:42:44
!info Ticket vote: FinalBlocker (+1,0,-0) (+lruzicka)
<@adamwill:fedora.im>
18:42:46
!info Ticket vote: BetaFreezeException (+2,0,-0) (+asciiwolf, +lruzicka)
<@adamwill:fedora.im>
18:43:14
i think we were waiting for more info from lnie on f40 status here
<@adamwill:fedora.im>
18:43:50
i've added a needinfo
<@frantisekz:fedora.im>
18:44:16
okey, we can punt then
<@adamwill:fedora.im>
18:45:55
alrighty
<@adamwill:fedora.im>
18:46:28
proposed !agreed 2236356 - punt (delay decision) - we're still clarifying exactly the status with f40 here. installer team is also back looking at a fix. we have added a needinfo to the bug
<@frantisekz:fedora.im>
18:46:32
ack
<@humaton:fedora.im>
18:46:52
ack
<@geraldosimiao:matrix.org>
18:47:15
ack
<@adamwill:fedora.im>
18:48:04
!agreed 2236356 - punt (delay decision) - we're still clarifying exactly the status with f40 here. installer team is also back looking at a fix. we have added a needinfo to the bug
<@adamwill:fedora.im>
18:48:11
!topic (2249392) libblkid returns incomplete information for partitons (e.g. UUID and TYPE are missing) preventing assembly of md raid devices
<@adamwill:fedora.im>
18:48:13
!link https://bugzilla.redhat.com/show_bug.cgi?id=2249392
<@adamwill:fedora.im>
18:48:15
!link https://pagure.io/fedora-qa/blocker-review/issue/1446
<@adamwill:fedora.im>
18:48:17
!info Proposed Blocker, util-linux, NEW
<@adamwill:fedora.im>
18:48:19
!info Ticket vote: BetaBlocker (+3,0,-0) (+nielsenb, +geraldosimiao, +lruzicka)
<@adamwill:fedora.im>
18:48:25
so this one was actually closed but got reopened
<@adamwill:fedora.im>
18:48:45
i'm not really clear what issue the person who reopened it is running into. it may not be the same as the original reporter.
<@humaton:fedora.im>
18:49:44
there is not much info in the last comment
<@adamwill:fedora.im>
18:50:05
yeah
<@adamwill:fedora.im>
18:52:02
i'll set a needinfo
<@adamwill:fedora.im>
18:52:19
on the whole i'd be inclined to reject this without clearer indication there's a reproducible issue affecting f40
<@adamwill:fedora.im>
18:52:25
but we can punt it for a bit
<@frantisekz:fedora.im>
18:52:51
we have a RAID system in the office, I can ask lruzicka to try it out tomorrow (the machine is connected to piKVM, so I'd prefer not to disconnect/reconnect it)
<@frantisekz:fedora.im>
18:52:56
but punt for sure
<@adamwill:fedora.im>
18:53:20
there seems to be some subtlety regarding the details of the raid set here :/ the concrete bug that got fixed related to what version of mdadm created it, for e.g.
<@adamwill:fedora.im>
18:53:28
(earlier versions put some metadata in a different place on the disk)
<@frantisekz:fedora.im>
18:53:50
ahh, sounds fun...
<@adamwill:fedora.im>
18:54:31
proposed !agreed 2249392 - punt (delay decision) - the reporter who reopened this issue may not have the same bug as the original reporter, the situation seems less clear-cut than it was for that reporter. we will delay the decision while attempting to get more information on Sandro's case, including testing on Fedora 40
<@humaton:fedora.im>
18:55:11
ack
<@frantisekz:fedora.im>
18:55:12
ack
<@kparal:matrix.org>
18:55:22
František Zatloukal: also, mdraid is software raid, I believe. That's not the same as a firmware raid which we have in the office.
<@frantisekz:fedora.im>
18:55:48
yeah, fair point, but we can still do a sw raid test on that machine with 2 HDDs
<@kparal:matrix.org>
18:55:59
or just in a VM, that's easier
<@adamwill:fedora.im>
18:56:02
well, mdraid is actually used to manage most fimrware raid these days
<@adamwill:fedora.im>
18:56:20
as well as software raid
<@adamwill:fedora.im>
18:56:23
so that's also a confusion point
<@adamwill:fedora.im>
18:57:02
i believe this bug relates to software RAID, though
<@kparal:matrix.org>
18:57:18
ok, thanks for info
<@adamwill:fedora.im>
18:57:31
!agreed 2249392 - punt (delay decision) - the reporter who reopened this issue may not have the same bug as the original reporter, the situation seems less clear-cut than it was for that reporter. we will delay the decision while attempting to get more information on Sandro's case, including testing on Fedora 40
<@adamwill:fedora.im>
18:57:38
so, we're nearly at the time limit
<@adamwill:fedora.im>
18:57:50
everyone OK with skipping the proposed final blockers so we can all go home? :D
<@frantisekz:fedora.im>
18:58:03
yep
<@adamwill:fedora.im>
18:58:14
!info we will skip the proposed Final blockers as the meeting is almost at its time limit
<@adamwill:fedora.im>
18:58:17
!topic Open floor
<@adamwill:fedora.im>
18:58:26
anything very urgent to bring up?
<@frantisekz:fedora.im>
19:00:29
enjoy the story!
<@geraldosimiao:matrix.org>
19:00:45
Nothing urgent
<@adamwill:fedora.im>
19:02:03
ok, thanks for coming everyone!
<@adamwill:fedora.im>
19:02:05
!endmeeting