<@jistone:fedora.im>
17:00:10
!startmeeting FESCO (2024-07-09)
<@meetbot:fedora.im>
17:00:12
Meeting started at 2024-07-09 17:00:10 UTC
<@meetbot:fedora.im>
17:00:12
The Meeting name is 'FESCO (2024-07-09)'
<@jistone:fedora.im>
17:00:15
!meetingname fesco
<@meetbot:fedora.im>
17:00:15
The Meeting Name is now fesco
<@jistone:fedora.im>
17:00:19
Chairs: @conan_kudo:matrix.org, @ngompa:fedora.im, @nirik:matrix.scrye.com, @humaton:fedora.im, @zbyszek:fedora.im, @sgallagh:fedora.im, @jistone:fedora.im, @dcantrell:fedora.im, @decathorpe:fedora.im, @salimma:fedora.im
<@jistone:fedora.im>
17:00:24
!topic Init Process
<@jistone:fedora.im>
17:00:29
!hi
<@dcantrell:fedora.im>
17:00:33
!hi
<@humaton:fedora.im>
17:00:40
!hi
<@marcdeop:matrix.org>
17:00:51
!hi
<@salimma:fedora.im>
17:01:12
!hi
<@zbyszek:fedora.im>
17:01:15
!hi
<@jnsamyak:matrix.org>
17:01:17
!hi
<@jistone:fedora.im>
17:01:39
hmm, where are the ID responses?
<@nirik:matrix.scrye.com>
17:01:40
morning
<@nirik:matrix.scrye.com>
17:01:58
we just had a db server outage.. things are still recovering
<@nirik:matrix.scrye.com>
17:01:58
we just had a db server outage.. things are still recovering
<@conan_kudo:matrix.org>
17:02:01
!hi
<@conan_kudo:matrix.org>
17:02:01
!hi
<@zodbot:fedora.im>
17:02:03
Neal Gompa (ngompa) - he / him / his
<@zodbot:fedora.im>
17:02:03
Neal Gompa (ngompa) - he / him / his
<@conan_kudo:matrix.org>
17:02:17
well it listens to me :)
<@zbyszek:fedora.im>
17:02:23
Maybe zodbot needs a cookie: zodbot ++
<@sgallagh:fedora.im>
17:02:39
zbyszek: !hi
<@sgallagh:fedora.im>
17:02:41
!hi
<@zodbot:fedora.im>
17:02:43
Stephen Gallagher (sgallagh) - he / him / his
<@salimma:fedora.im>
17:03:00
!hi
<@zodbot:fedora.im>
17:03:01
Michel Lind (salimma) - he / him / his
<@conan_kudo:matrix.org>
17:03:01
seems like it's back
<@salimma:fedora.im>
17:03:03
phew
<@nirik:matrix.scrye.com>
17:03:16
now you can know who you are.
<@salimma:fedora.im>
17:03:21
yeah, fedpkg / dist-git finally started working again too, and luckily pagure.io/fesco is fine
<@marcdeop:matrix.org>
17:04:04
!hi
<@gui1ty:fedora.im>
17:04:05
!hi
<@zodbot:fedora.im>
17:04:06
Marc Deop (marcdeop)
<@zodbot:fedora.im>
17:04:07
Sandro . (gui1ty)
<@jistone:fedora.im>
17:04:47
ok, we have some non-members here, but I think there's quorum, right?
<@gui1ty:fedora.im>
17:05:23
I joined in case of questions. I'll be mostly lurking in the backseats.
<@adamwill:fedora.im>
17:06:01
i'm going to try and be around for the kde release blocking thing, maybe from my phone
<@jistone:fedora.im>
17:06:10
let's get started then
<@jistone:fedora.im>
17:06:22
!topic #3231 Update exception request for rust-add-determinism
<@decathorpe:fedora.im>
17:06:23
!hi
<@zodbot:fedora.im>
17:06:25
Fabio Valentini (decathorpe) - he / him / his
<@decathorpe:fedora.im>
17:06:26
sorry for being late
<@jistone:fedora.im>
17:06:28
!fesco 3231
<@zodbot:fedora.im>
17:06:30
<@zodbot:fedora.im>
17:06:30
**fesco #3231** (https://pagure.io/fesco/issue/3231):**Update exception request for rust-add-determinism**
<@zodbot:fedora.im>
17:06:30
● **Opened:** a week ago by zbyszek
<@zodbot:fedora.im>
17:06:30
● **Last Updated:** an hour ago
<@zodbot:fedora.im>
17:06:30
● **Assignee:** Not Assigned
<@jistone:fedora.im>
17:07:11
zbyszek: do you actually want an exception that continues in f41+?
<@zbyszek:fedora.im>
17:07:21
Yes. I think that's the most reasonable.
<@zbyszek:fedora.im>
17:07:34
The package, by definition, needs to remain strict backwards compatibility.
<@zbyszek:fedora.im>
17:07:59
So if it is changed in FN+1, the update can be always safely backported to FN.
<@decathorpe:fedora.im>
17:08:03
the question is ... if you're going to provide strict backwards compatibility, why do you need an updates policy exception at all?
<@conan_kudo:matrix.org>
17:08:07
No, it doesn't, and it won't. Because the point of it is to change the behavior of the build environment.
<@conan_kudo:matrix.org>
17:09:09
And because it's a buildroot critical component, I'm extremely wary to allow it. I still remember how much of a disaster the GCC plugins were, and we've already had a taste of breakage from the first attempt at adding this to the buildroot.
<@zbyszek:fedora.im>
17:09:16
The policy says:
<@zbyszek:fedora.im>
17:09:16
> Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience.
<@zbyszek:fedora.im>
17:09:21
I want to introduce new features.
<@zbyszek:fedora.im>
17:10:00
For example, I was asked to implement a mode where the tool does not make any changes, but instead allows the maintainer the check that everything is deterministic.
<@sgallagh:fedora.im>
17:10:12
zbyszek: I honestly think it's time to revise that part of the policy, because it hasn't been enforced since... ever?
<@zbyszek:fedora.im>
17:10:17
This was implemented as `--check`, a new switch for a new feature.
<@zbyszek:fedora.im>
17:10:40
Since this is a developer tool, it makes the most sense to allow this to be used in F40 too.
<@jistone:fedora.im>
17:10:41
would those features be enabled on the older branches? or just available for devs?
<@nirik:matrix.scrye.com>
17:10:46
note the 'aim' there... doing some heavy lifting
<@sgallagh:fedora.im>
17:10:49
I think the intent there was "don't materially impact the user experience" and was phrased in a way that kind of made sense at the time
<@decathorpe:fedora.im>
17:11:12
Stephen Gallagher: it's 1) only a SHOULD, and 2) new features don't usually affect user or developer experience, especially when they're additive
<@zbyszek:fedora.im>
17:11:20
I agree that the policy is often not followed. I think we should change it. But let's treat that as a separate topic.
<@sgallagh:fedora.im>
17:11:44
Fair enough
<@zbyszek:fedora.im>
17:12:53
We have one policy for the whole distro. I think that this policy makes more sense in some areas. For example, for graphical programs, a new "feature" would not be desired in an update. In particular, because it might affect the layout, or confuse newbie users, etc.
<@salimma:fedora.im>
17:12:54
given this package is meant to be intertwined with mock - and we keep mock in sync across stable releases - giving it an exception makes sense, right?
<@conan_kudo:matrix.org>
17:13:19
Well, mock is _outside_ the environment
<@decathorpe:fedora.im>
17:13:24
it's not intertwined with mock
<@decathorpe:fedora.im>
17:13:36
it provides a BRP
<@conan_kudo:matrix.org>
17:13:38
mock hosts it, but is not part of it
<@salimma:fedora.im>
17:13:47
ok. *used* with mock
<@conan_kudo:matrix.org>
17:13:54
no, used with rpmbuild
<@nirik:matrix.scrye.com>
17:14:00
I'm fine with just an exception, or just saying that part of the policy is should and its ok for it to not do that... whichever makes more sense
<@conan_kudo:matrix.org>
17:14:06
buildroot policies are not at the mock level, they are at the rpm level
<@salimma:fedora.im>
17:14:11
it will be weird if someone's experience building a package is different depending on what version of Fedora is running on a host
<@conan_kudo:matrix.org>
17:14:17
they affect _everything_
<@decathorpe:fedora.im>
17:14:28
this is not the case
<@nirik:matrix.scrye.com>
17:14:34
well, it's already somewhat different right? different packages in the buildroot
<@conan_kudo:matrix.org>
17:14:41
nope
<@salimma:fedora.im>
17:14:49
would it not though, if add-determinism is at a different version in different releases?
<@decathorpe:fedora.im>
17:14:56
no
<@salimma:fedora.im>
17:15:03
oh... the add-determinism for the Fedora release is installed
<@decathorpe:fedora.im>
17:15:05
add-determinism from inside the buildroot is used
<@conan_kudo:matrix.org>
17:15:05
well, maybe... we should have `@buildsys-build` being used everywhere
<@salimma:fedora.im>
17:15:09
in the mock buildroot
<@zbyszek:fedora.im>
17:15:34
So… it would. But that is expected. For example, you have different versions of gcc in different releases of Fedora. So builds results are generally expected to be different.
<@nirik:matrix.scrye.com>
17:15:41
The place this will be bad is where a maintainer starts using a new feature in rawhide and can't then easily merge that use back to stable branches...
<@decathorpe:fedora.im>
17:16:22
so ... just as with every other new feature that is only added to rawhide?
<@decathorpe:fedora.im>
17:16:25
I don't see the problem.
<@conan_kudo:matrix.org>
17:16:44
this would be the first time we'd allow an exception for something that actually affects the rpmbuild setup
<@conan_kudo:matrix.org>
17:16:52
which I am really loathed to do
<@conan_kudo:matrix.org>
17:17:46
I would rather policy exceptions be requested each time significant changes occur that could cause behavioral changes
<@conan_kudo:matrix.org>
17:17:58
I would rather update exceptions be requested each time significant changes occur that could cause behavioral changes
<@decathorpe:fedora.im>
17:17:58
I would be OK with approving an exception for Fedora <41 since it's not used in Fedora <41
<@jistone:fedora.im>
17:18:07
is anyone against an exception for <=F40? it seems only >=F41 is controversial, right?
<@conan_kudo:matrix.org>
17:18:17
I don't think we need to do anything for F40 and older
<@conan_kudo:matrix.org>
17:18:39
it's a rando leaf package and normal compat rules apply (which it somewhat follows)
<@sgallagh:fedora.im>
17:18:56
I think I agree with Conan Kudo here; it's probably not a great idea to give a blanket exception at least until it has a few releases under its belt that we can use to gauge the need and risk
<@zbyszek:fedora.im>
17:19:13
Sorry, but I don't understand what this is based on. The Updates Policy text I quoted above is pretty clear.
<@conan_kudo:matrix.org>
17:19:25
as long as nobody changes redhat-rpm-config in F40 and older or epel-rpm-macros in EPEL9 and older to invoke it, we should be fine
<@zbyszek:fedora.im>
17:19:32
I don't think it's OK for me to slip around the policy, esp. as a member of FESCo.
<@decathorpe:fedora.im>
17:19:55
you're not slipping around the policy. the provision you quoted is a SHOULD only.
<@conan_kudo:matrix.org>
17:19:58
if you feel you need an exception for F40 and older, we can grant it
<@sgallagh:fedora.im>
17:20:10
zbyszek: I think what we're saying is that it's a SHOULD and we're not willing to treat it as a MUST in this case.
<@conan_kudo:matrix.org>
17:20:14
I just don't want to grant one for F41+
<@sgallagh:fedora.im>
17:20:47
Enforced policy is really only around *breaking* changes, which it doesn't sound like this would be
<@zbyszek:fedora.im>
17:21:24
OK, so are you saying that the policy as written does not apply and I can update the package in stable releases if there are no breaking changes?
<@sgallagh:fedora.im>
17:21:41
That's *my* interpretation, yes
<@jistone:fedora.im>
17:22:17
is that interpretation conditional on rpm-build's dependency? (for F41+)
<@conan_kudo:matrix.org>
17:22:17
however, for F41+, any change to how add-determinism works counts as a breaking change
<@conan_kudo:matrix.org>
17:22:23
yes
<@zbyszek:fedora.im>
17:22:50
That again doesn't make any sense. A breaking change, by common sense, is a change that can break something.
<@sgallagh:fedora.im>
17:22:54
Conan Kudo: I think that's an overstatement
<@dcantrell:fedora.im>
17:22:58
we've been on this topic for a while
<@jistone:fedora.im>
17:23:29
yes, we need a proposal to vote on
<@sgallagh:fedora.im>
17:23:41
But I agree that we don't need to give it a permanent exception. I trust zbyszek to bring it to our attention when a change might be problematic and request approval when needed.
<@nirik:matrix.scrye.com>
17:23:45
If thats a should and doesn't matter, it shouldn't matter for f41+ too
<@adamwill:fedora.im>
17:24:20
"The policy only applies to breaking changes" feels like a mistake to me. If we knew in advance what broke stuff, we could just never break stuff
<@adamwill:fedora.im>
17:24:39
The policy exists to try and preclude *unexpected* breakage
<@sgallagh:fedora.im>
17:24:46
adamw: Bugs happen. If they do, we revert the change.
<@jistone:fedora.im>
17:25:32
Proposal: An update exception is explicitly granted to rust-add-determinism for Fedora <= 40, but not yet for 41+
<@zbyszek:fedora.im>
17:25:36
adamw: this is a developer tool that only makes sense for rpm builds. So I don't think the usual considerations about updates in stable releases really make sense.
<@sgallagh:fedora.im>
17:25:37
adamw: As I said before, I think the policy (as written) is unrealistic and in need of updating, but that's orthogonal to the question before us today.
<@sgallagh:fedora.im>
17:25:44
Josh Stone: +1
<@decathorpe:fedora.im>
17:26:57
Josh Stone: +1
<@conan_kudo:matrix.org>
17:27:07
Josh Stone: +1
<@salimma:fedora.im>
17:27:16
+1
<@humaton:fedora.im>
17:27:16
Josh Stone: +1
<@nirik:matrix.scrye.com>
17:27:28
+1 I guess... I am thinking it doesn't need any exception now, but meh...
<@dcantrell:fedora.im>
17:27:43
+1
<@zbyszek:fedora.im>
17:28:12
-0, I think it's marginally better to have the exception, but it's hardly worth the time.
<@sgallagh:fedora.im>
17:28:21
nirik: I tend to agree, but if approving it explicitly gets us past this discussion, I'm all for it
<@jistone:fedora.im>
17:28:55
!agreed An update exception is explicitly granted to rust-add-determinism for Fedora <= 40, but not yet for 41+ (+8, 1, -0)
<@zbyszek:fedora.im>
17:29:18
OK, let's move on.
<@jistone:fedora.im>
17:29:21
!topic #3232 Change: Mark Fedora KDE AArch64 as Release-Blocking
<@jistone:fedora.im>
17:29:25
!fesco 3232
<@zodbot:fedora.im>
17:29:29
● **Opened:** a day ago by amoloney
<@zodbot:fedora.im>
17:29:29
● **Assignee:** ngompa
<@zodbot:fedora.im>
17:29:29
● **Last Updated:** an hour ago
<@zodbot:fedora.im>
17:29:29
**fesco #3232** (https://pagure.io/fesco/issue/3232):**Change: Mark Fedora KDE AArch64 as Release-Blocking**
<@zodbot:fedora.im>
17:29:29
<@jistone:fedora.im>
17:29:36
cc adamw
<@conan_kudo:matrix.org>
17:30:07
ping marcdeop Farchord (Steve Cossette) Troy Dawson
<@sgallagh:fedora.im>
17:31:02
So, just so I'm caught up: the revised request is to make KDE on aarch64 *disk images* blocking for F41+?
<@conan_kudo:matrix.org>
17:31:11
yes
<@sgallagh:fedora.im>
17:31:22
We're going to postpone trying to make installer images blocking due to the high failure rate, yes?
<@conan_kudo:matrix.org>
17:31:32
live iso images, but yes
<@nirik:matrix.scrye.com>
17:31:59
the lives are the ones that fail. ;)
<@nirik:matrix.scrye.com>
17:32:03
(I thought)
<@zbyszek:fedora.im>
17:32:09
What is the failure rate for disk images?
<@sgallagh:fedora.im>
17:32:21
nirik: I think he was replying to my second question there.
<@conan_kudo:matrix.org>
17:32:24
~50% failure rate is pretty bad, and I'm prioritizing migrating all Fedora KDE artifacts to kiwi for F42 because of this
<@sgallagh:fedora.im>
17:32:52
Correcting "installer images" with "live iso images"
<@adamwill:fedora.im>
17:33:01
Sorry, I'm here now, reading scroll back
<@conan_kudo:matrix.org>
17:33:26
nirik: if it's possible to get access to the environment that runs it to test and reproduce, I'd be happy to poke at it a bit
<@jistone:fedora.im>
17:33:27
IMO, release-blocking status should entirely rely on official QA, not SIG augmentation
<@jistone:fedora.im>
17:33:43
so iff QA agrees, then I'm fine with it
<@adamwill:fedora.im>
17:33:47
Josh Stone: that is absolutely not scalable
<@jistone:fedora.im>
17:34:00
no? is that not where we are today?
<@conan_kudo:matrix.org>
17:34:05
it is not
<@adamwill:fedora.im>
17:34:06
We would be a hard no to this if qa is expected to test it. We do not have the cycles
<@nirik:matrix.scrye.com>
17:34:25
and just doing the live is worse. ;(
<@sgallagh:fedora.im>
17:34:26
Josh Stone: We'd have to drop aarch64-Workstation from blocking in that case, at least
<@jistone:fedora.im>
17:34:44
sorry, then I already had a too-rosy picture
<@conan_kudo:matrix.org>
17:34:53
Fedora KDE SIG is also exploring whether we can stand up our own server infrastructure separately from Fedora since there is no funding or support to run automated tests
<@adamwill:fedora.im>
17:34:54
No, there is already an expectation that sigs help with testing, for existing arm stuff, iot stuff, server...it doesn't always happen, but it's there
<@conan_kudo:matrix.org>
17:35:23
I believe marcdeop intends to reach out on the infrastructure@ list to find out more about how to do that
<@conan_kudo:matrix.org>
17:35:37
Stephen Gallagher: we'd have to drop release-blocking entirely
<@sgallagh:fedora.im>
17:35:49
Conan Kudo: I did say "at least ":)
<@adamwill:fedora.im>
17:35:52
We're more amenable to this with the folks proposing it committing to doing the testing and fixing bugs, we are just worried about the possibility that doesn't happen and we're left with the bag
<@decathorpe:fedora.im>
17:36:08
I don't think this is even the case for *existing* release-blocking deliverables ... is it?
<@conan_kudo:matrix.org>
17:36:16
It is not.
<@jistone:fedora.im>
17:36:35
that's fine, I stand corrected
<@farchord:matrix.org>
17:36:45
We're kindof trying to meet people halfway, I guess you could say :)
<@sgallagh:fedora.im>
17:37:00
adamw: Would this be an acceptable compromise? "Treat KDE aarch64 disk images as blocking for F40. If Fedora QA determines after GA that there was insufficient outside assistance to maintain it going forward, we will drop it from release blocking in F41+"?
<@conan_kudo:matrix.org>
17:37:16
uhhh
<@adamwill:fedora.im>
17:37:20
Do we have ARM Sig representation, BTW? Because historically this has always been arranged with the arm sig
<@conan_kudo:matrix.org>
17:37:21
F40 is done already?
<@sgallagh:fedora.im>
17:37:34
Sorry, braining bad today.
<@adamwill:fedora.im>
17:37:41
Bump the numbers by one
<@salimma:fedora.im>
17:37:51
Stephen Gallagher: was about to propose something like frame pointer - but I think one release cycle is too short. and yeah you mean F41?
<@sgallagh:fedora.im>
17:37:53
"Treat KDE aarch64 disk images as blocking for F41. If Fedora QA determines after GA that there was insufficient outside assistance to maintain it going forward, we will drop it from release blocking in F42+"?
<@adamwill:fedora.im>
17:38:13
That's better, sure
<@sgallagh:fedora.im>
17:38:40
This is what I get for watching Doctor Who over lunch-break...
<@nirik:matrix.scrye.com>
17:38:42
sorry, lost everything in a transporter accident. :) anyhow....
<@farchord:matrix.org>
17:39:01
Careful, the TARDIS usually only lands in the UK. Very often London.
<@salimma:fedora.im>
17:39:02
or... we can try something like a "release blocking lite" - if the release gets delayed by more than a week because there's insufficient resource to fix, the blocking status is dropped
<@nirik:matrix.scrye.com>
17:39:06
How about adding in a beta there?
<@adamwill:fedora.im>
17:39:14
Still wondering if arm Sig has an opinion here
<@nirik:matrix.scrye.com>
17:39:19
ie, try for beta and reevaluate?
<@conan_kudo:matrix.org>
17:39:31
this is pretty hard because it depends on where the failure case is
<@adamwill:fedora.im>
17:39:39
All previous decisions about blocking desktops on arm have gone through that group
<@conan_kudo:matrix.org>
17:39:45
and sometimes it takes a while to root cause a bug
<@sgallagh:fedora.im>
17:39:59
adamw: I'm kind of interpreting this as being more driven by Asahi downstream needs than ARM SIG specifically, but that's maybe just my assumption
<@nirik:matrix.scrye.com>
17:40:01
I'm fine punting this and asking arm folks their thoughts.
<@conan_kudo:matrix.org>
17:40:11
Stephen Gallagher: it is a big driver, yes
<@conan_kudo:matrix.org>
17:40:25
but we definitely want to support more ARM platforms in Fedora KDE too
<@adamwill:fedora.im>
17:40:28
We do already have the blocker waiver mechanism that can effectively achieve that, not sure we need a new one
<@salimma:fedora.im>
17:40:40
adamw: good point
<@sgallagh:fedora.im>
17:41:00
Yeah, let's drop "blocking lite" as a concept please
<@adamwill:fedora.im>
17:41:05
I agree, what I'm saying is we should probably make sure the arm Sig has the opportunity to be involved since this clearly affects them
<@salimma:fedora.im>
17:41:15
and yeah Conan Kudo I was thinking more of "blocking bugs nobody is looking at" - if someone is working on it but root cause takes longer that seems reasonable (and we can bypass them if necessary)
<@sgallagh:fedora.im>
17:41:36
nirik: I'm out of the loop; what's the deal with Snapdragon?
<@farchord:matrix.org>
17:41:41
This is one of the reasons why we're trying to hit the ground running on this one, to be honest
<@humaton:fedora.im>
17:41:51
WIndows laptops
<@conan_kudo:matrix.org>
17:42:04
Right, we're looking to acquire and do bringup work on those platforms for upstream Fedora KDE.
<@adamwill:fedora.im>
17:42:09
There's a new one that's getting a lot of buzz
<@sgallagh:fedora.im>
17:42:11
Oh, right. The new Microsoft Surfaces, right?
<@farchord:matrix.org>
17:42:18
Snapdragon support (The Copilot+ PCs) should be in the Linux kernel """"soon"""":tm:
<@conan_kudo:matrix.org>
17:42:20
Windows on ARM devices from Lenovo _et al_
<@salimma:fedora.im>
17:42:23
the Lenovo one is quite nice too
<@nirik:matrix.scrye.com>
17:42:26
there are a bunch of new ones
<@sgallagh:fedora.im>
17:42:34
Ack, got it.
<@nirik:matrix.scrye.com>
17:42:46
lenovo, acer, ms, etc etc
<@conan_kudo:matrix.org>
17:42:46
they're still kind of weird and special, but less so than ARM SBCs
<@conan_kudo:matrix.org>
17:43:03
mostly because Linux can't use the standardized boot method Windows uses
<@nirik:matrix.scrye.com>
17:43:05
they have nice stats and would be lovely when/if supported well
<@farchord:matrix.org>
17:43:16
I think the snapdragon systems have uefi no?
<@conan_kudo:matrix.org>
17:43:23
we can't use it
<@conan_kudo:matrix.org>
17:43:28
we have to use DeviceTree and such
<@adamwill:fedora.im>
17:43:37
We're off track
<@jistone:fedora.im>
17:43:43
for the topic at hand -- are we agreed that we need ARM SIG input?
<@nirik:matrix.scrye.com>
17:43:44
proposal: punt to next week, have kde sig ask arm sig for thoughts and rediscuss next week
<@conan_kudo:matrix.org>
17:43:44
anyway not the point
<@conan_kudo:matrix.org>
17:44:06
who is left in the ARM SIG?
<@nirik:matrix.scrye.com>
17:44:08
yeah, we have to have DT and thus each one will be somewhat of a snowflake. ;(
<@sgallagh:fedora.im>
17:44:16
Could we actually vote on my proposal first?
<@jistone:fedora.im>
17:44:17
thanks nirik , +1 from me
<@salimma:fedora.im>
17:44:34
if we invite the ARM SIG and they don't show up I'm fine not waiting on them
<@sgallagh:fedora.im>
17:44:38
I guess I didn't formulate it properly.
<@jistone:fedora.im>
17:44:38
Stephen Gallagher: I missed yours
<@salimma:fedora.im>
17:44:42
+1 for nirik's proposal
<@zbyszek:fedora.im>
17:44:47
+1
<@adamwill:fedora.im>
17:44:54
Peter, obviously
<@nirik:matrix.scrye.com>
17:44:59
Conan Kudo: pbrobinson, pwhalen, coremodule, jlayton, dgilmore?
<@conan_kudo:matrix.org>
17:45:00
+1
<@sgallagh:fedora.im>
17:45:02
Proposal: "Treat KDE aarch64 disk images as blocking for F41. If Fedora QA determines after GA that there was insufficient outside assistance to maintain it going forward, we will drop it from release blocking in F42+"
<@conan_kudo:matrix.org>
17:45:22
nirik: of those, I have seen none of them recently
<@dcantrell:fedora.im>
17:45:24
+1
<@salimma:fedora.im>
17:45:29
well... if the others are mostly OK voting now, then yeah +1
<@nirik:matrix.scrye.com>
17:45:46
-1, I'd like to get the arm folks thoughts and I don't know that we are in a super rush.
<@decathorpe:fedora.im>
17:46:06
I'm not sure that second part is needed. QA can always ask FESCo to drop release blocking status again, no provision needed for that
<@sgallagh:fedora.im>
17:46:13
nirik: I think if nothing else we want the KDE SIG to have ample time to acquire testing hardware. If we punt, that shortens their lead-time.
<@conan_kudo:matrix.org>
17:46:30
yes
<@conan_kudo:matrix.org>
17:46:37
it's not cheap and not quick to acquire hardware
<@conan_kudo:matrix.org>
17:46:54
and this is all self-funded
<@sgallagh:fedora.im>
17:47:01
Fabio Valentini: I'm saying that we're voting today to trust their decision, rather than needing to re-vote. But if you want to do it that way, I'm ambivalent
<@jistone:fedora.im>
17:47:08
it's kind of chicken-and-egg, but it seems to me that hardware should be a prereq, not scrambled afterward
<@adamwill:fedora.im>
17:47:30
That was kparal's suggestion, yes
<@sgallagh:fedora.im>
17:47:42
Josh Stone: It's definitely chicken-egg. So let's hatch the egg :)
<@conan_kudo:matrix.org>
17:47:43
but why should I ask the SIG members to buy hardware when we aren't going to have the status to make it useful?
<@farchord:matrix.org>
17:47:57
So you want me to get hardware with the risk that you guys vote the idea down, meaning the hardware becomes an expensive paperweight?
<@nirik:matrix.scrye.com>
17:48:03
only blocking makes it useful?
<@zbyszek:fedora.im>
17:48:04
Wouldn't it be useful anyway?
<@conan_kudo:matrix.org>
17:48:16
we do the work and then can't get the fixes through
<@conan_kudo:matrix.org>
17:48:30
remember that we don't respin ARM images at all
<@sgallagh:fedora.im>
17:48:36
I count (+4, 0, -1) so far
<@conan_kudo:matrix.org>
17:48:36
so post-GA updates are effectively useless
<@sgallagh:fedora.im>
17:48:38
Any other votes?
<@humaton:fedora.im>
17:48:49
+1
<@jistone:fedora.im>
17:48:52
I'm -1 on moving before ARM SIG input
<@salimma:fedora.im>
17:49:02
we can consider this alternative too, surely - why can't we respin ARM images?
<@sgallagh:fedora.im>
17:49:13
(+5, 0, -2)
<@nirik:matrix.scrye.com>
17:49:22
respinning things causes it's own set of issues.
<@zbyszek:fedora.im>
17:49:28
So -1 to Stephen's proposal for now to honour nirik's and Josh's request for delay.
<@zbyszek:fedora.im>
17:49:28
OK, I'll change my vote too. We generally have a rule that we punt if people have questions and the matter is not urgent.
<@zbyszek:fedora.im>
17:49:28
<@conan_kudo:matrix.org>
17:49:32
the Respins SIG lacks compute resources to do it
<@conan_kudo:matrix.org>
17:50:04
a large part of the problem is that ARM is underinvested in within Fedora _period_
<@salimma:fedora.im>
17:50:07
yeah... given there are already two negatives... I think a week extra is fine. I will not vote for an extra delay if nobody from ARM shows up though
<@salimma:fedora.im>
17:50:08
-1
<@sgallagh:fedora.im>
17:50:11
Conan Kudo: Given that we have *effectively* passed this (modulo the delay), is that good enough to start the process on ordering hardware?
<@conan_kudo:matrix.org>
17:50:20
we lack QA compute, we lack releng compute, we lack dev resources, etc.
<@nirik:matrix.scrye.com>
17:50:22
they could have such resources if they asked...
<@jistone:fedora.im>
17:50:52
are we +5/-4? or was one of those -1 a change?
<@zbyszek:fedora.im>
17:51:01
Yes, I changed.
<@salimma:fedora.im>
17:51:06
I flipped from +1 to -1, zbyszek too
<@jistone:fedora.im>
17:51:53
ok, I'm unsure of totals, but it lost majority
<@conan_kudo:matrix.org>
17:52:10
we can start researching and scheduling team acquisitions for hardware, need to identify compatibility list wrt fedora and figure it out
<@farchord:matrix.org>
17:52:12
yeah it's essentially 50/50 rn
<@sgallagh:fedora.im>
17:52:32
Conan Kudo: But at least it's positive enough that you don't need to wait on that, right?
<@zbyszek:fedora.im>
17:52:34
I think the argument about hardware only being useful for blocking deliverables is specious. You generally want to have the hardware *before*, and test for a while before asking for something to be blocking.
<@sgallagh:fedora.im>
17:52:38
So things can start moving forward
<@sgallagh:fedora.im>
17:53:12
zbyszek: I would agree if we were providing them funding for hardware. As it's out of pocket, I can see their point about needing some guarantees about wasted effort
<@zbyszek:fedora.im>
17:53:15
I have a bunch of risc-v boards that I test with, and I don't expect risc-v stuff to be blocking any time soon. In fact, I'm sure that those boards will be useless long before that.
<@conan_kudo:matrix.org>
17:53:16
maybe... the lack of recognition of how expensive this is going to be for us is kind of bad
<@decathorpe:fedora.im>
17:53:26
I understand that people might not want to spend money on things that by definition can't prevent a bad release from shipping
<@zbyszek:fedora.im>
17:53:54
They can still be used to fix bugs… This should be the main motivation.
<@conan_kudo:matrix.org>
17:54:07
if the fixes aren't shipping to users, there's no point
<@decathorpe:fedora.im>
17:54:24
yeah. bugs that get fixed during freezes will not matter at all
<@conan_kudo:matrix.org>
17:54:29
we already do a lot of work around Fedora Asahi KDE and ship those fixes because we can ship them right away
<@jistone:fedora.im>
17:54:38
I'm not comfortable even asking you to buy HW just because FESCo voted so.
<@conan_kudo:matrix.org>
17:54:45
but upstream Fedora KDE is screwed unless it's release-blocking
<@zbyszek:fedora.im>
17:54:46
Sure, but let's not fixate on the freeze. Most of the time we're not in a freeze.
<@decathorpe:fedora.im>
17:55:12
why not? the freezes are the most important part of the whole thing.
<@humaton:fedora.im>
17:55:33
Yes but its understandably frustrating to do stuff and it wont make it to the release...
<@farchord:matrix.org>
17:55:41
We're doing it to help the project as a whole, we volunteered :) We just don't want the effort (and money) to go to waste :)
<@decathorpe:fedora.im>
17:55:45
if critical fixes for Fedora KDE can't be pulled in during a freeze - and they *only* can if they fix release-blocking stuff - they won't be fixed at GA.
<@humaton:fedora.im>
17:55:46
because image build failed with unrelated issue
<@nirik:matrix.scrye.com>
17:55:48
the freeze exception process doesn't work?
<@conan_kudo:matrix.org>
17:55:58
no
<@conan_kudo:matrix.org>
17:56:03
because it will be denied
<@nirik:matrix.scrye.com>
17:56:04
why not?
<@nirik:matrix.scrye.com>
17:56:08
what?
<@jistone:fedora.im>
17:56:12
Farchord (Steve Cossette): and that's great! but I don't think it's a waste without release-blocker either
<@salimma:fedora.im>
17:56:36
I've gotten FE for things that are not release blocking before...
<@kparal:matrix.org>
17:56:45
We frequently approve FEs which are important for non-release-blocking images
<@conan_kudo:matrix.org>
17:56:46
nirik: QA has been getting harder on the FE/FB pulls for a while now for stuff that ships to media
<@sgallagh:fedora.im>
17:56:47
We still have other topics on the agenda, so if we're punting, let's take this conversation to another channel and move to the next topic?
<@jistone:fedora.im>
17:57:20
formally, do we need a complete vote to punt it?
<@nirik:matrix.scrye.com>
17:57:21
additionally, kde is release blocking on x86_64...
<@nirik:matrix.scrye.com>
17:57:36
so, I am not sure what FE's you are seeing rejected....
<@sgallagh:fedora.im>
17:57:49
Josh Stone: We've got a general consensus, I think?
<@nirik:matrix.scrye.com>
17:57:50
anyhow, yes, driving off into the :weeds
<@jistone:fedora.im>
17:58:17
maybe, but I don't know an explicit count
<@conan_kudo:matrix.org>
17:58:19
I have been scolded before for abusing KDE's x86_64 r-b for aarch64 fixes
<@conan_kudo:matrix.org>
17:58:57
and the last couple of cycles it has been hard to get fixes through in time to be part of GA images
<@conan_kudo:matrix.org>
17:59:09
and it wound up not even mattering because the image builds kept failing :(
<@jistone:fedora.im>
17:59:10
but yes, we have 3 more topics, though not *all* controversial, I hope...
<@nirik:matrix.scrye.com>
17:59:14
I think it's +3, -4
<@zbyszek:fedora.im>
17:59:39
I get the same tally.
<@conan_kudo:matrix.org>
17:59:57
anyway, we'll probably start building a list at least of hardware to acquire, but we're not pulling the trigger unless we get the status to make it useful
<@sgallagh:fedora.im>
18:00:10
+1 punt, let's move on please
<@conan_kudo:matrix.org>
18:00:12
there is no point in spending so much money ourselves otherwise
<@jistone:fedora.im>
18:00:42
ok, I think there's just no `!agreed` here
<@jistone:fedora.im>
18:00:57
!topic #3233 Change: GIMP version 3
<@jistone:fedora.im>
18:01:02
!fesco 3233
<@zodbot:fedora.im>
18:01:06
● **Assignee:** nphilipp
<@zodbot:fedora.im>
18:01:06
**fesco #3233** (https://pagure.io/fesco/issue/3233):**Change: GIMP version 3**
<@zodbot:fedora.im>
18:01:06
<@zodbot:fedora.im>
18:01:06
● **Opened:** a day ago by amoloney
<@zodbot:fedora.im>
18:01:06
● **Last Updated:** 2 hours ago
<@jistone:fedora.im>
18:01:49
I think we generally agree that we want gimp-3, no more gimp-2 nor gimp3, right?
<@zbyszek:fedora.im>
18:01:54
I don't think the proposal make sense as written. We should punt and wait for @nphillip's reply in the ticket.
<@conan_kudo:matrix.org>
18:01:56
yes
<@nirik:matrix.scrye.com>
18:02:04
yep.
<@salimma:fedora.im>
18:02:29
yep
<@sgallagh:fedora.im>
18:02:29
I'm of the opinion that F41+ should move to gimp3 and if F40 and earlier want it, it should come as a flatpak
<@sgallagh:fedora.im>
18:02:50
And gimp2 should be dropped from F41+ (or shipped as a flatpak)
<@zbyszek:fedora.im>
18:02:52
It's already available as a normal rpm in F40.
<@salimma:fedora.im>
18:02:52
right, but we also need to agree on naming. F41+ should have gimp just be gimp v3
<@zbyszek:fedora.im>
18:03:09
`gimp3-2.99.18-8.fc40.x86_64`
<@sgallagh:fedora.im>
18:03:27
Right, let me rephrase...
<@conan_kudo:matrix.org>
18:03:29
`gimp` should obsolete `gimp3` in F41+
<@nirik:matrix.scrye.com>
18:03:35
lets let nphillip rework it.
<@sgallagh:fedora.im>
18:03:38
Conan Kudo: Yes, that.
<@zbyszek:fedora.im>
18:03:42
I don't think *we* need to agree on the naming. The maintainer can figure this out and we can than rubberstamp the choice.
<@salimma:fedora.im>
18:04:02
right. sorry, I mean it should be in the proposal that we vote on
<@nirik:matrix.scrye.com>
18:04:04
it still needs/should have a change tho... so folks know it's moving in f41
<@sgallagh:fedora.im>
18:04:11
But can we at least agree that gimp v2 must not be part of F41+?
<@sgallagh:fedora.im>
18:04:19
Because that's blocking Python 2 removal
<@salimma:fedora.im>
18:04:27
obsolete/provide, right? should be a drop in replacement. or just obsolete and users need to deal with removing the old gimp2 by hand?
<@conan_kudo:matrix.org>
18:04:29
yes
<@sgallagh:fedora.im>
18:04:30
At least as an RPM
<@salimma:fedora.im>
18:04:40
yes
<@jistone:fedora.im>
18:04:55
Proposal: We would like the Change reworked to have GIMP v3 replace v2, without any `gimp3` package going forward
<@sgallagh:fedora.im>
18:05:05
Proposal: FESCo would like to see the proposal reworked. We also require that GIMP v2 must not be present in Fedora 41+ due to python 2 removal.
<@sgallagh:fedora.im>
18:05:23
Josh Stone: I don't really want to dictate the naming as FESCo. That seems excessive.
<@dcantrell:fedora.im>
18:05:42
+1
<@zbyszek:fedora.im>
18:05:50
Stephen Gallagher: +1
<@jistone:fedora.im>
18:05:51
that's fine, let's vote on Stephen Gallagher 's formulation
<@jistone:fedora.im>
18:05:52
+1
<@humaton:fedora.im>
18:05:56
+1
<@conan_kudo:matrix.org>
18:06:00
+1 to both
<@salimma:fedora.im>
18:06:07
+1
<@decathorpe:fedora.im>
18:06:15
+1
<@nirik:matrix.scrye.com>
18:06:16
+1
<@jistone:fedora.im>
18:06:27
!agreed FESCo would like to see the proposal reworked. We also require that GIMP v2 must not be present in Fedora 41+ due to python 2 removal. (+9, 0, -0)
<@jistone:fedora.im>
18:06:29
nice
<@jistone:fedora.im>
18:07:15
!topic #3234 Change: Replace Nose with Pynose
<@jistone:fedora.im>
18:07:19
!fesco 3234
<@zodbot:fedora.im>
18:07:22
● **Assignee:** gui1ty
<@zodbot:fedora.im>
18:07:22
<@zodbot:fedora.im>
18:07:22
**fesco #3234** (https://pagure.io/fesco/issue/3234):**Change: Replace Nose with Pynose**
<@zodbot:fedora.im>
18:07:22
● **Last Updated:** an hour ago
<@zodbot:fedora.im>
18:07:22
● **Opened:** a day ago by amoloney
<@salimma:fedora.im>
18:07:45
the license issue and the origin of the fork seem ... messy
<@nirik:matrix.scrye.com>
18:07:57
I think at this point we should just not do this.
<@sgallagh:fedora.im>
18:07:58
I'm not sure there's much to discuss on this one. This seems pretty clearly problematic now. I suggest they can resubmit if the upstream issues get cleaned up.
<@nirik:matrix.scrye.com>
18:08:16
I'm not too sure we want it even then...
<@decathorpe:fedora.im>
18:08:21
If the change is on the verge of being withdrawn due to issues, I don't really like to vote +1 here :)
<@sgallagh:fedora.im>
18:08:34
nirik: I said they could resubmit. I didn't say we'd approve it necessarily :)
<@nirik:matrix.scrye.com>
18:08:42
sure, anyhow, -1
<@conan_kudo:matrix.org>
18:08:43
we could also just keep nose which we have now
<@gui1ty:fedora.im>
18:08:51
The dust (or ashes) after the fire upstream have not yet settled. It seems the `pynose` maintainer wants to fix it, but has little understanding regarding licensing.
<@conan_kudo:matrix.org>
18:08:51
so -1 to this Change
<@jistone:fedora.im>
18:08:53
seems like we should just keep the current deprecated nose and encourage nose2 adoption?
<@humaton:fedora.im>
18:09:04
-1
<@salimma:fedora.im>
18:09:05
yeah, -1
<@sgallagh:fedora.im>
18:09:14
-1 (as I was in the ticket)
<@zbyszek:fedora.im>
18:09:15
I think we should wait.
<@salimma:fedora.im>
18:09:25
if the upstream is this confused it sounds like we should not encourage downstream projects to keep using the old API
<@gui1ty:fedora.im>
18:09:45
Why `pynose` wasn't forked properly from `nose` remains unclear.
<@gui1ty:fedora.im>
18:10:14
I suppose waiting until next meeting and punting for now is an option.
<@zbyszek:fedora.im>
18:10:20
I really really seems like the upstream maintainer is fixated on going down the wrong path, but let's say that there's 1% chance that the direction changes. We can vote next week once the situation is clear.
<@salimma:fedora.im>
18:10:31
how much work, do you think, will it be for upstream pynose to re-fork and reapply all their commits without the license change?
<@salimma:fedora.im>
18:10:58
but yeah if we can get this answer soon I'm OK punting
<@nirik:matrix.scrye.com>
18:11:01
I suppose I'm fine waiting, but I don't hold out much hope.
<@gui1ty:fedora.im>
18:11:27
Not much work I think. But I'm not sure they are willing to fork properly. There's another ticket now covering that part, the attribution.
<@zbyszek:fedora.im>
18:11:39
The last comment in the github issue is 6 minutes old.
<@gui1ty:fedora.im>
18:12:00
🔥
<@jistone:fedora.im>
18:12:42
at least, it seems they are not established enough for us to choose this in F41
<@gui1ty:fedora.im>
18:12:49
https://github.com/mdmintz/pynose/issues/28 not sure this has been added to the ticket yet. I believe Miro might have mentioned it.
<@salimma:fedora.im>
18:13:33
Red flag
<@salimma:fedora.im>
18:13:33
> This is apparently not the first time you've done this, either, and it should be considered unacceptable practice in the open source community.
<@salimma:fedora.im>
18:13:33
<@jistone:fedora.im>
18:14:41
-1 from me on the Change
<@gui1ty:fedora.im>
18:14:44
I have a little hope myself and will only pursuit this if resolved satisfactory upstream. But, as Irish folk say, good things come to those who wait. 🍺 (black and creamy)
<@dcantrell:fedora.im>
18:14:50
this pynose project is a disaster (reading issue 16 comments). this should not find its way in to fedora for now
<@dcantrell:fedora.im>
18:15:29
-1 to the change
<@gui1ty:fedora.im>
18:15:35
It's in rawhide only now. But I agree. I would not have added it knowing what I know now.
<@jistone:fedora.im>
18:15:42
(do I record `!agreed` with negative majority?)
<@nirik:matrix.scrye.com>
18:16:03
I'd say yes...
<@nirik:matrix.scrye.com>
18:16:08
they can resubmit if things change
<@salimma:fedora.im>
18:16:16
if we -1 the change today... should we revisit this with a view of retiring/blocking the package in a couple of weeks?
<@dcantrell:fedora.im>
18:16:35
huh, this pynose guy is in Boston. some of us could just go talk to him in person and ask what's up
<@salimma:fedora.im>
18:16:43
either resubmit the change or retire the package -- or keep it but don't promote it as a replacement
<@sgallagh:fedora.im>
18:17:12
dcantrell: Should I bring the brass knuckles? :)
<@nirik:matrix.scrye.com>
18:17:34
nope. You shouldn't threaten people.
<@jistone:fedora.im>
18:17:36
I think that's (+0, 2, -7), counting "wait" as 0
<@salimma:fedora.im>
18:17:41
"such a lovely package you have..."
<@gui1ty:fedora.im>
18:18:10
If that change is not going through, I will retire the package myself on grounds of licensing issues. No need to revisit.
<@dcantrell:fedora.im>
18:18:15
while it likely wouldn't help, I find that when conversations online are going nowhere or in circles, talking to people in person can help a lot
<@salimma:fedora.im>
18:18:19
thak you
<@jistone:fedora.im>
18:18:22
maybe "wait" should not be counted like that
<@salimma:fedora.im>
18:18:24
thank you
<@dcantrell:fedora.im>
18:18:26
but for some reason I feel this guy is too far gone
<@sgallagh:fedora.im>
18:18:28
nirik: You've met me. I'm really not threatening in any way.
<@nirik:matrix.scrye.com>
18:18:29
working with free software (even poorly) shouldn't be the cause for any threats. If they want to meet with folks, great.
<@nirik:matrix.scrye.com>
18:18:47
I know people were joking, but... it's not a good joke.
<@jistone:fedora.im>
18:18:57
let's record it this way and move on:
<@jistone:fedora.im>
18:18:58
!agreed Change: Replace Nose with Pynose (+0, 0, -7)
<@sgallagh:fedora.im>
18:19:18
Fair enough. Long meeting.
<@jistone:fedora.im>
18:19:22
!topic #3238 Change: Nvidia Driver Installation with Secure Boot
<@jistone:fedora.im>
18:19:26
!fesco 3238
<@zodbot:fedora.im>
18:19:27
**fesco #3238** (https://pagure.io/fesco/issue/3238):**Change: Nvidia Driver Installation with Secure Boot**
<@zodbot:fedora.im>
18:19:27
<@zodbot:fedora.im>
18:19:27
● **Assignee:** eischmann
<@zodbot:fedora.im>
18:19:27
● **Last Updated:** 2 hours ago
<@zodbot:fedora.im>
18:19:27
● **Opened:** a day ago by amoloney
<@sgallagh:fedora.im>
18:19:41
I apologize for the tasteless joke.
<@sgallagh:fedora.im>
18:20:22
I've been chatting with mcrha today about this a bit.
<@sgallagh:fedora.im>
18:20:36
!link https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2034#note_2162304
<@salimma:fedora.im>
18:21:08
me too
<@nirik:matrix.scrye.com>
18:21:32
So, I haven't read all that. ;) is there a TLDR? or perhaps we should just move this to next week too?
<@sgallagh:fedora.im>
18:21:38
I'm still not a huge fan of the security implications of this, but I'm open to their providing a warning about the risks involved as part of the process.
<@dcantrell:fedora.im>
18:21:47
next week! next week! next week!
<@jistone:fedora.im>
18:21:50
would it be feasible to have a dedicated MOK per akmod?
<@sgallagh:fedora.im>
18:21:57
nirik: I linked to a specific subthread there that's fairly short
<@salimma:fedora.im>
18:22:06
I was wondering too
<@sgallagh:fedora.im>
18:22:14
Josh Stone: Not possible without a major rework of our kernel builds.
<@sgallagh:fedora.im>
18:22:28
I've investigated this personally in the past.
<@jistone:fedora.im>
18:23:21
then, maybe a config on whatever is using that key, limiting allowed akmods?
<@zbyszek:fedora.im>
18:23:25
The change as proposed effectively neuters SecureBoot by providing a locally stored signing key that is trusted during boot. I understand that this existing situation is hard for people who want to use out-of-tree drivers. But I don't think this is enough of justification for this.
<@sgallagh:fedora.im>
18:23:28
I'd be fine with punting this one more week, as I think the discussion is circling around a possible compromise I could accept.
<@jistone:fedora.im>
18:23:57
using that key *to sign*, I mean
<@sgallagh:fedora.im>
18:24:10
Josh Stone: that would be the major rework I was talking about
<@jistone:fedora.im>
18:24:16
ok
<@salimma:fedora.im>
18:24:42
yeah. Fedora only ships nvidia and steam subrepos from RPM Fusion IIRC, and only nvidia's has an akmod. it might be a surprise for someone to approve the akmod key being enrolled and then discovering if they install the rest of RPM Fusion's repo that any akmod there is also allowed in
<@sgallagh:fedora.im>
18:25:02
zbyszek: Right, which is why my compromise solution is making sure that the UX for this is sufficiently scary.
<@nirik:matrix.scrye.com>
18:25:34
I'm not sure scary will help. people will just click thru
<@sgallagh:fedora.im>
18:25:38
Because yes, it does effectively disable a major part of Secure Boot
<@zbyszek:fedora.im>
18:25:43
But this is not limited to packages. *Anything* you run locally can use the signing key (if it gets appropriate privs, but really, 99% of people run with sudo enabled for the user, so the that's generally not a big barrier).
<@sgallagh:fedora.im>
18:27:03
Michel Lind 🎩: My concern is that if this becomes ubiquitous, one malicious actor who maintains a package in Fedora could stuff an akmod into an update that gets into `updates` without being noticed and they've now rooted any system that package was installed on.
<@jistone:fedora.im>
18:27:08
SystemTap has a MOK setup with server/client access
<@salimma:fedora.im>
18:27:27
my concern too. though as zbyszek noted it's worse than that
<@sgallagh:fedora.im>
18:27:32
But, as has been noted elsewhere, this has always been possible to a greater or lesser extent in Fedora
<@conan_kudo:matrix.org>
18:27:49
And has also been that way for a while in other distributions
<@sgallagh:fedora.im>
18:27:49
We have some tricks with SELinux that help mitigate it, of course
<@sgallagh:fedora.im>
18:27:57
(Blocking setuid binaries, etc.)
<@zbyszek:fedora.im>
18:28:19
"this"?
<@conan_kudo:matrix.org>
18:28:24
Over the years there have been attempts to try to drive an improved setup, but nobody cares enough unfortunately
<@conan_kudo:matrix.org>
18:28:25
so here we are
<@nirik:matrix.scrye.com>
18:28:26
we could possibly do something with ima here... but would need a exploring.
<@sgallagh:fedora.im>
18:28:43
zbyszek: Malware delivered by a package that was approved previouslyt.
<@conan_kudo:matrix.org>
18:28:51
the mistake was requiring kernel module certificates to be loaded in firmware
<@conan_kudo:matrix.org>
18:29:14
we never needed that for root of trust, and yet we do, so now the damage is so much worse than on Windows and macOS that don't do that
<@zbyszek:fedora.im>
18:29:33
Yes. But now we're extending that to "make the malware trivially trusted via MOK".
<@conan_kudo:matrix.org>
18:30:28
if we had a kernel keyring to trust certificates for kmods, then we could probably have better UX around it
<@conan_kudo:matrix.org>
18:32:12
but we don't so here we are
<@smooge:fedora.im>
18:32:34
I don't think it is that no one cares.. there are just way too many things which ALSO need to be worked on and only a couple dozen people
<@salimma:fedora.im>
18:33:19
the vendor in question (cough) clearly could have done better
<@sgallagh:fedora.im>
18:33:22
Right, the problem is that the Venn diagram of "People who care about this" and "People with the knowledge, experience and time to do something about it" is a pair of sunglasses.
<@conan_kudo:matrix.org>
18:33:59
well, hilariously, for RHEL, they're getting a second certificate compiled into the kernel so that another cert doesn't need to be loaded into firmware
<@conan_kudo:matrix.org>
18:34:11
so the mechanism exists, just only at build-time rather than at runtime
<@decathorpe:fedora.im>
18:34:34
I'm wondering why this is such a concern for Fedora when other distributions have clearly been doing this for a while?
<@decathorpe:fedora.im>
18:34:47
and I haven't seen scary "ubuntu users got hacked via akmod" stories
<@sgallagh:fedora.im>
18:35:10
Fabio Valentini: To be fair, that's one of the big risks: a hack wouldn't be easily detectable :(
<@conan_kudo:matrix.org>
18:35:18
openSUSE uses auto-built kmod packages, Ubuntu uses DKMS, and both use autogenerated and auto-enrolled keys
<@jistone:fedora.im>
18:35:21
You probably haven't seen scary "user got hacked with SecureBoot disabled" stories either
<@salimma:fedora.im>
18:35:45
and the key can't be reused later on?
<@conan_kudo:matrix.org>
18:36:01
Ubuntu uses one MOK for everything thing
<@conan_kudo:matrix.org>
18:36:05
openSUSE uses a MOK per driver
<@conan_kudo:matrix.org>
18:36:24
the problem with MOK per driver is that a shockingly high number of UEFI platforms don't have enough NVRAM for it
<@salimma:fedora.im>
18:36:38
the openSUSE approach... if we want to use it we'd have to ship the driver ourselves instead of it being part of RPM Fusion huh
<@salimma:fedora.im>
18:36:44
ugh
<@conan_kudo:matrix.org>
18:37:19
the openSUSE approach requires us to start allowing kmods or at least start having some mechanism to ensure every kernel build comes with kmod packages built too
<@conan_kudo:matrix.org>
18:37:40
there's a lot more policy things to fix for the openSUSE approach
<@conan_kudo:matrix.org>
18:38:47
at least to make it viable in Fedora
<@jistone:fedora.im>
18:38:56
how many external drivers do people use that makes NVRAM an issue?
<@smooge:fedora.im>
18:39:02
many UEFI are just going to implement the bare minimums a spec requires and that may be only a couple of entries (or may not be easily updateable beyond clear them all and start from scratch)
<@conan_kudo:matrix.org>
18:39:25
nvidia, v4l2loopback, virtualbox, and evdi alone make 4
<@jistone:fedora.im>
18:39:59
and even that handful is too much sometimes?
<@conan_kudo:matrix.org>
18:40:00
and iirc, until recently, openSUSE made a new key for every driver update, which was significantly worse
<@conan_kudo:matrix.org>
18:40:04
yes
<@conan_kudo:matrix.org>
18:40:16
hell, some systems (I own a few) can't even handle ***one***
<@salimma:fedora.im>
18:40:53
I've had similar issues with TPMs :(
<@conan_kudo:matrix.org>
18:41:27
it's why I tried for years to convince the kernel folks to make the kmod signature keyring runtime modifiable at the OS level
<@jistone:fedora.im>
18:41:31
This is the last agenda topic, so I've been letting it run, but it seems like we won't reach any conclusions today, right?
<@smooge:fedora.im>
18:41:45
sorry to bring this up but I think there are only 10-15 minutes more in this meeting
<@jistone:fedora.im>
18:41:54
right
<@smooge:fedora.im>
18:41:58
ah what josh just said
<@smooge:fedora.im>
18:42:37
to be honest I don't think there is an agreeable solution. It isn't even clear if there is a 60% solutio
<@jistone:fedora.im>
18:42:50
let's punt/delay for now
<@jistone:fedora.im>
18:43:03
!topic Next week's chair
<@jistone:fedora.im>
18:43:40
btw, I'm going to be on holiday for the next two
<@salimma:fedora.im>
18:44:03
I can chair next week
<@jistone:fedora.im>
18:44:23
!action Michel Lind 🎩 will chair next meeting
<@jistone:fedora.im>
18:44:27
thanks
<@zodbot:fedora.im>
18:44:33
jistone gave a cookie to salimma. They now have 41 cookies, 1 of which were obtained in the Fedora 40 release cycle
<@jistone:fedora.im>
18:44:37
!topic Open Floor
<@nirik:matrix.scrye.com>
18:45:43
I'm going to open a discussion (On the list I guess? or discussion? or both?) about the f41 schedule. I just happened to notice that branching is currently scheduled for the 2024-08-06... which is, the day before flock. :( So, I would like to propose moving it... but we can discuss in the thread, this is just a heads up.
<@salimma:fedora.im>
18:46:43
presumably you're proposing moving it later, not earlier, right?
<@nirik:matrix.scrye.com>
18:47:12
yeah, likely so.
<@smooge:fedora.im>
18:47:27
after flock and any flock flu
<@nirik:matrix.scrye.com>
18:47:38
"but we can discuss in the thread, this is just a heads up."
<@nirik:matrix.scrye.com>
18:47:47
zbyszek: you had something?
<@zbyszek:fedora.im>
18:48:23
Yeah.
<@zbyszek:fedora.im>
18:48:31
I built packages for the bin-sbin merge today.
<@zbyszek:fedora.im>
18:48:40
The update is https://bodhi.fedoraproject.org/updates/FEDORA-2024-3aafcac6a8.
<@zbyszek:fedora.im>
18:49:18
There are some "failures", but the first few I looked at at false positives caused by the tests not understanding that packages may not be coninstallable.
<@zbyszek:fedora.im>
18:49:29
I guess that I should open a thread on fedora-devel about this.
<@zbyszek:fedora.im>
18:49:47
This makes the CI for systemd generally useless, and for some other crit-path packages too.
<@zbyszek:fedora.im>
18:50:00
But anyway, feel free to take a look at the update and test it.
<@smooge:fedora.im>
18:50:10
would the fix for that be explicite conflicts in the package?
<@jistone:fedora.im>
18:50:11
is the overall upgrade path ok?
<@zbyszek:fedora.im>
18:50:31
There are explicit conflicts. The tests faceplant.
<@sgallagh:fedora.im>
18:50:49
zbyszek: Yeah, the installability test is broken for many packages. Including `fedora-release`
<@smooge:fedora.im>
18:50:49
ah ok sorry
<@nirik:matrix.scrye.com>
18:50:53
this is a long running issue with PR's for fedora-release. ;) I think there's a ci issue on it.
<@decathorpe:fedora.im>
18:50:56
it looks like your update supersesed multiple postfix and httpd updates that were supposedly stuck because of failed gating tests?
<@decathorpe:fedora.im>
18:51:36
you'll likely need to check in with maintainers of those packages if tests can be waived?
<@zbyszek:fedora.im>
18:52:08
Yeah, not sure what's going on there.
<@zbyszek:fedora.im>
18:52:39
It seems that people do some kinds of automatic builds and don't even check if those builds are going anywhere.
<@nirik:matrix.scrye.com>
18:52:47
Not looked at those, but I had a iperf3 test failure because... dnf5 in rawhide has different args than dnf4 and it broke the gating tests that were written a while back
<@nirik:matrix.scrye.com>
18:53:28
there was some talk about packit updates not sending bodhi stuff to maintainers. I don't know if thats the case, but if so, they just may not notice it.
<@decathorpe:fedora.im>
18:54:20
I'm pretty sure bodhi emails never reach maintainers who use packit
<@zbyszek:fedora.im>
18:54:51
Anyway, a heads-up from my side. I plan to look at the failures and merge the update tomorrow if nothing major pops up.
<@jistone:fedora.im>
18:55:55
ok, anything else?
<@sgallagh:fedora.im>
18:56:19
Remember to register for Flock!
<@salimma:fedora.im>
18:56:54
we should follow up with the packit team I think?
<@sgallagh:fedora.im>
18:57:23
I'm not sure if it notified all of you, but the "Live FESCo Session" was approved for Aug. 7th at 10am local time
<@salimma:fedora.im>
18:57:40
we get to be on stage!
<@zbyszek:fedora.im>
18:57:57
Yep, right after Matthew's keynote.
<@jistone:fedora.im>
18:58:02
I didn't see anything, but unfortunately I can't attend anyway
<@jistone:fedora.im>
18:58:57
alright, let's wrap on time!
<@jistone:fedora.im>
18:59:01
!endmeeting