devel September 2026

devel@lists.fedoraproject.org

141 participants
119 discussions

RFC: splitting perf out of the kernel packaging
by Michel Lind 07 Oct '26

07 Oct '26

Hi all, For background: back in January, Neal and I presented a kernel refactoring proposal at CentOS Connect https://cfp.fedoraproject.org/centos-connect-2026/talk/X9JHNV/ This is informed by our work in CentOS' Hyperscale SIG, which builds faster-moving backports (many coming from Fedora) and rebuilds stock CentOS Stream packages with additional features. So - some of our work there could potentially feed back to Fedora; see my previous CentOS Showcase talk for examples - https://cfp.fedoraproject.org/centos-showcase-2024-11/talk/PTV8JM/ For the particular case of perf, we think it might make sense to split out the packaging from the kernel and build it standalone, for the reasons below: - while perf is mostly stable on x86_64, on aarch64 it is still getting a lot of fixes. e.g. the last update I made incorporated 20 cs-etm fixes: https://gitlab.com/CentOS/Hyperscale/rpms/perf/-/commit/8f8b93b559f9204d118… - perf build has some BuildRequires that are not needed for building the kernel itself. Isolating the builds help reduce the number of BRs needed on both sides (including, yes, *Java*) - separating the two makes it easier for interested contributors to help out - the kernel.spec is huge and kernel-ark packaging takes a while to get used to. - Also while kernel modules need to be specially signed for Secure Boot, perf does not need to be! - one pain point we have is that perf headers inconsistently show up in kernel-headers. If, say from F46 onwards perf is shipped standalone and perf-devel is the only place that ships perf headers, we can at least stop special-casing this. see e.g. https://gitlab.com/CentOS/Hyperscale/rpms/perf/-/blob/8f8b93b559f9204d1188b… - perf's maintainer (acme) has mentioned in the past that almost nobody consumed the standalone perf tarballs - indeed, 6.15 came out with a bug where some aarch64 headers were left out so the tarball cannot be used to build on that architecture. With a standalone packaging, like in Hyperscale, we can consume the upstream tarball, but fall back to using the full Linux tarball when necessary (or generating our own tarballs from specific Git tags; the makefile targets make this easy) Hoping to get some discussions going, and especially buy in from Justin Forbes (cc:ed) - if generally this seems like a good idea, we're going to submit a Change Proposal for Fedora 46. Anyone interested is welcome to join, we're hoping to have at least the two of us and Justin onboard. Best regards, -- _o) Michel Lind _( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README

5 5

NTFS drivers situation
by Julian Sikorski 02 Oct '26

02 Oct '26

Hi list, the rewritten ntfs driver by Namjae Jeon got enabled in kernel 7.2.6. The older nfts3 driver got dropped in parallel but got luckily reintroduced in 7.2.7. Unfortunately, ntfs-3g package is currently configured to capture ntfs filesystem type from mount calls, requiring --internal-only parameter to actually use it. Eliminating this conflict from a user perspective can be challenging because uninstalling ntfs-3g also drops some guestfs tools. We need some sort of plan moving forward. Changing what mount -t ntfs does mid-release is probably a no-go, but at the same time if ntfs filesystems could be mounted via /etc/fstab without having to resort to calling mount manually. Best regards, Julian

5 9

Wiki resource for Fedora RISC-V + KVM on the Spacemit K3 Com260 board
by James Morris 01 Oct '26

01 Oct '26

Hi Folks, I've been playing with Fedora RISC-V on the Spacemit K3 Com260 board (which implements full virtualization per the RVA23 spec). I've captured the bringup process as a wiki with the help of an LLM. This supports a native KVM host running an F44 guest image. It's current for F44, with F45-beta a WIP. Wiki: https://github.com/xjamesmorris/k3-com260-info/wiki -- James Morris <jmorris(a)namei.org> https://mastodon.social/@xjamesmorris

2 1

How can I contact the crypto team?
by Gordon Messmer 01 Oct '26

01 Oct '26

I would like to add AWS s2n-tls to Fedora https://github.com/aws/s2n-tls s2n-tls is a wrapper around some underlying crypto library. In the past, OpenSSL was one of the supported libraries, but the developers will probably remove OpenSSL support and currently recommend AWS-LC (originally a fork of BoringSSL) (I learned this when trying to fix builds on Fedora https://github.com/aws/s2n-tls/pull/5866) Fedora's crypto policies say that I should talk to crypto-team about adding a new crypto library to Fedora, and refers to a mailing list which requires membership to send messages. I sent a list subscription request ... about a month ago, I think? I haven't got a response yet.

14 34

Fedora 45 RISC-V (non-official) Beta images are available!
by Kashyap Chamarthy 01 Oct '26

01 Oct '26

(Also on Discourse: https://discussion.fedoraproject.org/t/fedora-45-risc-v-non-official-beta-i…) Hi, folks! The Fedora 45 RISC-V (non-official, community-contributed) *Beta* images are available for testing. You can find the Server, Cloud, and Container artifacts here: https://dl.fedoraproject.org/pub/alt/risc-v/releases/test/45_Beta/ Notes on server images ---------------------- There are two kinds of server images available: • Fedora-Server-Host-Generic: This image uses the standard 7.2 kernel (7.2.7-300.0.riscv64.fc45). This kernel is very close to upstream, and will work on VisionFive 2, Orange Pi RV, Milk-V Mars, and probably other boards. • Fedora-Server-Host-Omni: This image uses the Fedora "Omni" kernel, (7.2.7-300.0.riscv64.omni.fc45). The "Omni" aims to work on a wider range of RISC-V boards. Some patches in this kernel are still under review upstream. For details on the list of boards the Omni kernel should work on, refer to the overview[1] of Omni kernel. Please take these images for a spin[2] and let us know if you hit any issues. Most of the active discussion is on the Fedora RISC-V Matrix channel[2]. Regards, Fedora RISC-V Community (but any errors are mine) [1] https://copr.fedorainfracloud.org/coprs/g/forge-riscv-members/riscv64_omni_… [2] https://fedoraproject.org/wiki/Architectures/RISC-V/QEMU [3] https://chat.fedoraproject.org/#/room/#riscv:fedoraproject.org PS: Usually we send these out just to Fedora Discourse, trying to include the lists as well from this release :-)

2 2

Proposal to unconditionally pass --noclean to rpmbuild in Mock (skip %clean)
by Pavel Raiskup 01 Oct '26

01 Oct '26

Hi everyone, We are planning to change Mock's default behavior when building packages. Specifically, we intend to unconditionally pass --noclean to rpmbuild during builds. This means Mock will no longer execute the %clean section of spec files (or the implicit rmbuild cleanup phase). So far, Mock has been using --noclean only when `cleanup_on_success=False` (opt-in behavior). Modern RPM packaging guidelines consider the %clean section obsolete. Mock already manages the chroot and build root cleanups at the top level before and after builds. Running %clean inside the chroot seems redundant, and is hard to cover correctly (especially with the new "delayed %check" feature). More context and the background discussion can be found in PR #1809: https://github.com/rpm-software-management/mock/pull/1809 Request for Feedback: Before we make this change default in an upcoming release, we would like to hear from the community: Do you have any legitimate use cases where executing the %clean section or rmbuild phase inside Mock is still strictly required? Are you aware of any workflows or tooling built on top of Mock that would break if Mock always passes --noclean? If you have any objections, edge cases, or concerns, or process opinions - please let us know. Thanks, Pavel

5 7

[Fedocal] Reminder meeting : F45 Beta Go/No-Go Meeting
by amoloney＠redhat.com 30 Sep '26

30 Sep '26

Dear all, You are kindly invited to the meeting: F45 Beta Go/No-Go Meeting on 2026-10-01 from 17:00:00 to 20:00:00 UTC The meeting will be about: Please join us for the Fedora Linux 45 Beta Go/No-Go meeting in #fedora-meeting on matrix @ 1700 UTC. In this meeting, we will determine the status of the release candidate for F45 Beta. For more information on this meeting, please visit https://fedoraproject.org/wiki/Go_No_Go_Meeting Source: https://calendar.fedoraproject.org//meeting/11438/

2 1

GMail will remove ability to send email from @fedoraproject.org addresses soon
by Christopher 30 Sep '26

30 Sep '26

Hi, A colleague recently made me aware of a pending change in GMail that affects how I send email to Fedora mailing lists. Fedora documents this here: https://docs.fedoraproject.org/en-US/commops/gmail-alias/ GMail documents this feature here: https://support.google.com/mail/answer/22370 The notice of the change is documented here: https://support.google.com/mail/answer/17101213 I am very irritated by this change, since I depend on this feature to be able to send to the Fedora mailing lists using my @fedoraproject.org email address (or using my @apache.org email for ASF lists). Does anybody else depend on this? Does anybody have any good alternative solutions? Thanks, Christopher

19 41

Would your package be easier to build if you could select specific releases of dependencies?
by Gordon Messmer 30 Sep '26

30 Sep '26

( I have also posted this topic here: https://discussion.fedoraproject.org/t/would-your-package-be-easier-to-buil… ) I’ve used Red Hat / Fedora systems for almost 30 years. As an SRE, one of the things that has been most valuable to me has been not just the distribution, but RPM as a build tool. The spec files offered reusable, composable build workflows designed by people with experience integrating components into a coherent system. Earlier this year, I proposed an initiative that was mostly aimed at improving our build processes. Fedora’s systems are great for building Fedora, but it’s sometimes difficult to extend them to build applications *for* Fedora. In particular, large, complex applications tend to be compatible with specific releases of their dependencies, and as their dependency tree grows deeper, it also becomes less likely that it can coexist inside the distribution with similarly complex applications. I recently completed a prototype of a couple of tools that I used to package vLLM, because it exhibits those characteristics. The tools themselves are very similar to tools we have in place now. The configuration for an application build is very similar to the configuration we use for a Flatpak build. The main difference is that adding branches to a component’s dist-git repo which mirror upstream release branches allows a developer to select the release series of each component, independent of the version that appears in a Fedora release. That doesn’t necessarily work well in a mutable package-mode system, but I think it works very well for isolated builds, such as container images (including Flatpak). I’d like to discuss adding “upstream-release branches” in Fedora dist-git. Although it’s a small change, I expect we’ll need to discuss various aspects in detail, in a series of threads. Among other topics, we will probably discuss whether those branches can be automated to avoid increasing maintainer workload (I think we might have the confidence to do that since they wouldn’t be used directly by distribution releases). We’ll need to review previous branch-management implementations to see if any previous work is reusable or needed. We’ll need to discuss whether there are concerns specific to Forgejo. We’ll probably discuss whether we can use quay.io and the existing Flatpak registry or if a separate registry is needed. But before we discuss any of those topics, I’d like to hear first from people who think that this would help them. Would having branches that track upstream releases, so that they can build an application and dependencies decoupled from the distribution release, targeting a container output make it easier to build a package that you maintain? Would it make it possible to build something that you would like to build but currently cannot? Would these tools be useful to you outside of Fedora, to build software for your own? My experience building vLLM is described here: https://gordonmessmer.codeberg.page/dev-blog/2026/09/11/i-packaged-vllm.html Please reply if you are interested!

11 23

Problems with https://koji.fedoraproject.org/ ?
by Dmitry Belyavskiy 30 Sep '26

30 Sep '26

Hey, It looks like Koji web is behaving strangely. I'm running a scratch build. The build page opens normally, but after several refresh attempts, I'm redirected to Anubis and receive a 403 error. If I just copy the URL and open it in a new tab, it opens normally. If I open this page with a different Google account, I get a 403 immediately. -- Dmitry Belyavskiy

5 8

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel September 2026