FinalFE +1

FinalFE +1

Same question as for m1n1.

Also, as a procedural note, please don't propose "new version is available" bugs as FEs. Those bugs are supposed to be closed as soon as the new version is in Rawhide. If we want an FE to fix a specific bug, please file an FE for the specific bug. (Also, by policy, the update should backport the specific fix, not provide a whole new version, though we can be a bit lax on this for things that have no effect outside of Asahi.)

Can this not be fixed with an update? The fact that it's in an installer suggests it can't, but things aren't always well-named.

Not really without manual intervention, no. :(

Also, as a procedural note, please don't propose "new version is available" bugs as FEs. Those bugs are supposed to be closed as soon as the new version is in Rawhide. If we want an FE to fix a specific bug, please file an FE for the specific bug. (Also, by policy, the update should backport the specific fix, not provide a whole new version, though we can be a bit lax on this for things that have no effect outside of Asahi.)

Will do, thanks for clarifying, I wasn't entirely sure if these needed a dedicated bug or not.

Can this not be fixed with an update? The fact that it's in an installer suggests it can't, but things aren't always well-named.

asahi-installer is the installer, but in the context of Fedora what this package actually builds is the firmware gathering logic that's then used by asahi-scripts (we don't build the actual installer in Fedora at this point). It could be fixed with an update but it would mean users would get crappy webcam quality out of the box, which isn't ideal.

I think a 0-day update is OK here too, assuming an update can fix it. Few people are going to do much before an update, and many (like me) who use the net install option will get the fix from the start anyway.

FinalFE -1

So I just realized now we're actually still at 0.6.2 in f39. My mistake, I thought we had a later one in already before the latest update. That makes this more important, as without https://github.com/AsahiLinux/asahi-installer/commit/4e901d1ece8d9357169c904dd0fbfeea7ffa6ae0 folks will get broken wifi on recent firmwares, which would make installing a zero day update problematic.

I have the same concern as in ticket 1401. I don't understand why we're dealing with this instead of Asahi.

You're not really dealing with it at all.

Aside from the FE request, this is really not something you have to worry about. Fedora Asahi Remix is operating as if it's like a Fedora thing as much as possible. The Fedora Asahi SIG maintains almost everything in the Fedora context, and we use the Fedora processes as much as possible so that we are in sync with Fedora.

I didn't ask for a blocker or anything of the sort. And this update is necessary so that images don't come with broken Wi-Fi on F39. And MacBooks don't have Ethernet to work around that.

FinalFE +1

Accepting FE for a deliverable that isn't blocking doesn't risk breaking anything, and for PR reasons, it'd be nice to have working Fedora on M class devices with as many features as possible.

(Honestly, I don't really think we should freeze and get involved with stuff that's not part of Fedora-produced composes/our package groups, etc. at all, but that's for another debate. "Fedora" Asahi is an amazing effort, I've seen firsthand how people are interested in it on a conference, for start, we don't need to throw a monkey wrench into it, imo.)

You're not really dealing with it at all.

Of course I am. Reading the ticket, the bug, assessing impact, discussing, voting - that all costs time. Times number of people involved.

"Fedora" Asahi is an amazing effort

And I'm happy for it. But I'm looking at it from a more systematic approach. Fedora has many downstream projects, and if all of them start asking for FEs which have nothing to do with Fedora deliverables, it just affects downstreams, we won't be doing anything else. I don't have anything personal against Asahi, and I very much believe in good and friendly upstream behavior. At the same time, I'm asking why they don't have an override repo for this.

At the same time, I'm asking why they don't have an override repo for this.

COPR builds with a different vendor than Fedora, which means that our sticky vendor configuration (which we use to keep people from accidentally breaking their systems from dnf update to a kernel that doesn't work, for example) would lead to people being permanently switched off Fedora to the COPR vendor without human intervention. Same for vice vera. It's a bit tricky for us with packages that are built in Fedora infra.

As this can't affect anything besides asahi and apparently can't easily be fixed with a 0-day update, and given that asahi doesn't have a mechanism for pulling specific things from u-t, I'm fine with:

FinalFE +1

I recognize kparal's concerns, but honestly, I don't think it's as bad as you think. We don't have that many downstreams, and they aren't flooding us with FE requests. if it comes to that at some point, we can deal with it then.

that gives this +4 / -1, so:

AGREED AcceptedFinalFE

The following votes have been closed:

• Accepted FinalFreezeException (+4, 0, -1)
  • +1 by thebeanogamer, ngompa, frantisekz, adamwill
  • -1 by nixuser

Release F39 is no longer tracked by BlockerBugs, closing this ticket.