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