Fedora is a Trademark of Red Hat, Inc, an operating system built by volunteers around the world. This page is provided so that independent volunteers can showcase our contributions to Fedora and Free Software in general. Official Fedora Download page.
|
|
"Today's the fourth of july. Another june has gone by."
(appologies to Amiee Mann).
Here's another short recap of the last week from me. I was off Thursday, and Friday was a holiday, and I'm off next monday too, so this was a short week.
I spend a bit of time reinstalling our aarch64 bvmhosts. These are the machines that run all our buildvm-a64 instances. You would think this would be a trivial task, but of course not.
When we got these machines as part of the datacenter move last year, we couldn't get them to pxe boot from their 25G network. So, we ended up patching some 1G connections to them to provision them. Then those links were removed. So, I needed to fix the issue this time.
Turned out it was just some settings in the network card eeprom/settings. To adjust it, I had to build a kernel module, load that, then poke at the settings with a tool. Quite a pain, but luckily only a one time thing.
After that, they pxe booted fine and were easy to reprovison with rhel10. Except, then I hit the next thing: One of them had a bad memory stick in it. We had hit this before, but after reseating all the memory it came up ok, but that memory just decided to croak this time.
So, dc operations folks did a bunch of testing and isolated the bad memory. Should be on the way in to get a replacement now. Until the replacement arrives that machine is down memory, so a few buildvm's on it are shutdown. Shouldn't matter too much.
Last week we moved a number of servers to balance power in racks. That went fine, but networking folks noticed that 3 of the machines were not properly using 802.3ad/lacp. That is, they were only connected on one interface. These machines were our staging openshift workers.
It took me quite a lot of poking around to see what happened and how to fix it. Openshift has a lot of ways it configures network and it was not clear at all to me the flow. I did finally figure it out though: I had installed them with net.ifnames=0 set. This meant they had eth2 and eth3 interfaces that were the active ones. After the install, they booted without that and so the interface names changed. The new ones didn't have any config, so it just picked the first one and ran it's ovh setup on. So, I had to go in and setup NetworkManager to know about the new interface names so it would bond them, then the openshift setup script would just take that bond device and setup on it.
I wish openshift made it easier to tweak this.
Off on monday, see everyone tuesday!
As always, comment on the fediverse: https://fosstodon.org/@nirik/116863452466227942
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 29 June – 3 July 2026
This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker
This is the summary of the work done regarding the RISC-V architecture in Fedora.
This is the summary of the work done regarding AI in Fedora.
This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.
This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.
This team is working on keeping Epel running and helping package things.
This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Community Update – Week 27 appeared first on Fedora Community Blog.
Version 8.6.0alpha1 has been released. It's still in development and will soon enter the stabilization phase for the developers and the test phase for the users (see the schedule).
The RPMs of this upcoming new version of PHP 8.6, are available in remi repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, CentOS, Alma, Rocky...) in a fresh new Software Collection (php86) allowing its installation beside the system version.
As I (still) strongly believe in SCL's potential to provide a simple way to allow installation of various versions simultaneously, and as I think it is useful to offer this feature to allow developers to test their applications, to allow sysadmin to prepare a migration or simply to use this version for some specific application, I decide to create this new SCL.
I also plan to propose this new version as a Fedora 46 change (as F45 should be released a few weeks before PHP 8.6.0).
Installation :
yum install php86
⚠️ To be noticed:
ℹ️ Also, read other entries about SCL especially the description of My PHP workstation.
$ module load php86
$ php --version
PHP 8.6.0alpha1 (cli) (built: Jun 30 2026 11:28:16) (NTS gcc x86_64)
Copyright © The PHP Group and Contributors
Built by Remi's RPM repository #StandWithUkraine
Zend Engine v4.6.0-dev, Copyright © Zend by Perforce
with Zend OPcache v8.6.0alpha1, Copyright ©, by Zend by Perforce
As always, your feedback is welcome on the tracking ticket.
Software Collections (php86)
RPMs of PHP version 8.5.8 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.4.23 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.3.32 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.2.32 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
ℹ� These versions are also available as Software Collections in the remi-safe repository.
ℹ� The packages are available for x86_64 and aarch64.
⚠� PHP version 8.1 has reached its end of life and is no longer maintained by the PHP project.
🛡� These Versions fix 3 security bugs (CVE-2026-12184, CVE-2026-14355), so the update is strongly recommended.
Version announcements:
ℹ� Installation: Use the Configuration Wizard and choose your version and installation mode.
Replacement of default PHP by version 8.5 installation (simplest):
On Enterprise Linux (dnf 4)
dnf module switch-to php:remi-8.5/common
On Fedora (dnf 5)
dnf module reset php dnf module enable php:remi-8.5 dnf update
Parallel installation of version 8.5 as Software Collection
yum install php85
Replacement of default PHP by version 8.4 installation (simplest):
On Enterprise Linux (dnf 4)
dnf module switch-to php:remi-8.4/common
On Fedora (dnf 5)
dnf module reset php dnf module enable php:remi-8.4 dnf update
Parallel installation of version 8.4 as Software Collection
yum install php84
And soon in the official updates:
⚠� To be noticed :
ℹ� Information:
Base packages (php)
Software Collections (php83 / php84 / php85)
This blog post is a sequel to Your _get_type() function is not G_GNUC_CONST.
GNOME developers have long used G_GNUC_CONST, which expands to __attribute__((const)), to annotate GObject _get_type() functions, despite knowing that it is incorrect to do so. const functions by definition have no side effects, but _get_type() functions actually have a side effect the first time the function is called: they initialize the type. Why apply an incorrect annotation to these functions? Because it makes the code faster.
Although this was long known to be incorrect, it worked fine in practice… until now. Regrettably, Sam James has discovered that GCC 16 may optimize away the type initialization, resulting in crashes. This is our fault for providing the compiler with wrong information about our code, so it’s time to audit your use of const attributes to remove them from _get_type() functions. Most GNOME programs use these attributes only for _get_type() functions, but if you use it in more places, then check to make sure those functions are actually const, as defined by the GCC documentation.
Sadly, there is no suitable replacement attribute for _get_type() functions. Two decades ago, Behdad requested a new idempotent attribute for expressing the desired semantics, but nobody has implemented it.
Time for a recap of the last week in my #fedora infra space (here in longer form).
Overall this week was a bunch of catch up from being away at flock, along with recovering from Jetlag.
I scheduled an outage on thursday for the last of the external colo virthosts to get a RHEL10 reinstall. I had tried to do it in the last outage, but I wasn't able to do it in the normal way that preserved all the guests data. This time I managed to get it done, but it took longer than I would have liked and I hit a number of fun issues:
Using a remote console I can't hold down shift to get a grub menu, so I had to hit escape at the right time.
rdp for Fedora is not great still. gnome-connections is still the winner, but even it has quirks.
The /boot/efi partition still did not want to let me reformat it as part of the install. I thought it was because there was a spare in the raid1 for it, but I grew it to use that spare and it still didn't help. So, I ended up just deleting it and recreating it.
Finally all reinstalled, reprovisioned and all the guests brought back up.
There's still a number of hosts to move, and we are down to trickier ones, but we will look at another outage probibly week after next to do more.
Fesco decided to require all provenpackagers to enroll a 2fa token. There's a lot of talk about expanding that to packagers, or even everyone.
I thought I would share some info around this for interested folks who may not have seen it in all the various threads or tickets:
The Fedora account system frontend (noggin) supports enrolling TOTP tokens. Once you enroll one you must use it to login to the account system, to get a kerberos ticket, and to login to any web application with your fedora account.
You can (and should!) enroll more than one token. As far as I know, there's no limit to number you can add. You can also disable or delete tokens, so long as you still have one token enrolled. ie, you can never delete the last one. Any enrolled, non deactivated token will work to authenticate you. So, it's good to have at least one saved off to a safe place in case you loose access to your primary token.
If you somehow loose access to all your tokens, the recovery process is to mail admin@fedoraproject.org and you will be asked to prove you are you. This may be a gpg signed email (with the key associated with your account), using your ssh key associated with the account, or other means.
So, please make sure you have a backup token to avoid that. :)
TOTP is pretty common and has been around a long time. Lots of software is capable of storing your secret and displaying tokens.
On friday morning our koji s390x builders were getting swamped. It was the same story with a lot of large builds taking up builders so other things couldn't get in. Or so I thought at first, but on digging there was another problem. It was caused by a koji bug (already fixed upstream, but not released yet). This caused tasks to get freed and just sit there and not progress.
I have applied the patch and updated our hubs, and then went through and reassigned all the tasks I could see that were still having problems. Let me know if you see any I missed.
I also pulled in 2 more builders to the general build pool
One I had set to only do kernel builds a while back when we were trying to get security updates out fast.
One was a compose host, but I think we can be fine with one less compose host.
So adding those two helped process the backlog too.
I've also filed another request for more resources, but so far it hasn't really gone anywhere. ;(
Next week, I am going to be taking thursday off and friday is a holiday in the US, and I am taking off the following monday too.
Of course I'll still be around, but possibly doing other things. :)
As always, comment on the fediverse: https://fosstodon.org/@nirik/116823567269032135
How to migrate Fedora OS from one system to another, across network or (better) a Thunderbolt connection, without cloning the whole disk contents, saving SSD life.
When migrating a Linux installation from a source drive to a target drive of a different size, traditional block-by-block tools like dd don’t allow to migrate to a smaller drive, and also waste SSD life by writing unused blocks. This guide describes a simple approach in which different disk sizes can be used, and the process is performed over network (or Thunderbolt), so that it’s not necessary to place two physical disks in the same device. The target system is exactly the same as the original, with all partition and filesystem UUIDs staying the same, which means no post-migration OS configuration is necessary. The time and SSD wear is minimized by pre-shrinking partitions and skipping unallocated disk space entirely. The default Fedora Workstation disk layout is supported, including LUKS encryption of the system partition.
This guide expects the following disk layout:
/dev/nvme0n1p1 -- ESP (most often FAT)/dev/nvme0n1p2 -- Boot partition (most often Ext4)/dev/nvme0n1p3 -- System partition (most often Btrfs, optionally encrypted using LUKS)
For simplicity, this will not try to skip copying all unused blocks, just most of them. The first two partitions will be cloned in raw mode. The third partition will be shrunk first (thus saving lots of blocks from being copied, and also supporting smaller target drives), and then cloned in raw mode.
On the source system:
sudo dnf install gparted pvOn the target system:
sudo dnf install sfdisk sgdisksudo wipefs -a /dev/nvme0n1sudo blkdiscard -v /dev/nvme0n1If you have both systems connected to the network and intend to use it, skip the Thunderbolt setup section below. Instead figure out the IP addresses of both systems (using the ip address command) and go to the Connectivity test.
If you want something faster than a regular network, have Thunderbolt ports on both systems and a fast USB-C cable ready, you can use that instead. With Thunderbolt, you can transfer data with 10 Gb/s speeds or more, compared to the common 1 Gb/s of a standard Ethernet.
ip linkthunderbolt0.bash sudo ip addr add 192.168.5.1/24 dev <interface_name>sudo ip link set <interface_name> upbash sudo ip addr add 192.168.5.2/24 dev <interface_name>sudo ip link set <interface_name> up export SOURCE_IP=192.168.5.1
export TARGET_IP=192.168.5.2
ping $TARGET_IPping $SOURCE_IP This will make an exact copy of the source system partition table (including partition UUIDs) on the target system. Then we will adjust it to the different disk size.
nc -l -p 2000 > table.txt
sudo sfdisk --dump /dev/nvme0n1 | nc $TARGET_IP 2000
sudo sfdisk /dev/nvme0n1 < table.txt
And then fix the GPT backup header location (because it’s unlikely that you have both disks of exactly the same size):
sudo sgdisk --move-second-header /dev/nvme0n1
Everything should be ready now to transfer all partitions data.
p1): nc -l -p 2000 | sudo dd of=/dev/nvme0n1p1 bs=4M
sudo dd if=/dev/nvme0n1p1 bs=4M | pv | nc $TARGET_IP 2000
p2): nc -l -p 2000 | sudo dd of=/dev/nvme0n1p2 bs=4M
sudo dd if=/dev/nvme0n1p2 bs=4M | pv | nc $TARGET_IP 2000
p3): nc -l -p 2000 | sudo dd of=/dev/nvme0n1p3 bs=4M
sudo dd if=/dev/nvme0n1p3 bs=4M | pv | nc $TARGET_IP 2000
Now that the target system is a complete clone of the source system, you can expand the System partition to fully utilize the remaining disk space:
sudo dnf install gpartedYou can now reboot the target system, and you should see your OS and data exactly the same as on your source system. The process is now complete.
In case the target system has a very different hardware from the source system (e.g. a different brand of a graphics card), the drivers might be missing from the current kernel initramfs and you can see a black screen or kernel errors. In that case, reboot the system again, press F8 repeatedly during boot to get into the GRUB bootloader menu, and boot the rescue Fedora option, instead of the default one. That should hopefully boot using the generic image (which should contain all known drivers), and then you can regenerate all the kernel images using your current hardware setup with: sudo dracut --regenerate-all --force
ddbtrfs send and btrfs receiveAfter about eleven months of using an AArch64 desktop, I decided to end that experiment.
About a year ago, I bought myself an Ampere Altra system. After moving some hardware around and making a few extra orders, the final setup was:
| CPU | Ampere Altra Q80-30 processor (80 cores at 3.0GHz) |
| RAM | 128 GB (8x 16GB HMA82GR7CJR8N-XN) |
| GPU | AMD Radeon RX6700XT |
| NVME | Lexar LM970 2TB ADATA SX8200 Pro 1TB |
| Motherboard | ASRock Rack ALTRAD8UD-1L2T |
| PSU | MSI MPG A850G (850W) |
| Case | Endorfy 700 Air |
| USB3 | no-name USB 3.2/10Gbps controller (PCIe x4) |
To be fair, I should mention that this is a server motherboard, not a desktop one, and Altra systems were never meant to be desktops (despite companies selling them as such). Naturally, the list of tested/approved devices (Qualified Vendor List (QVL for TLA fans)) is quite short and for Ampere Altra systems, it does not contain AMD Radeon GPU cards. They can be made to work, but this often requires additional effort.
The extra USB 3.2 controller allowed me to have more USB devices than the motherboard alone supported, and gave me some 10Gbps ports for connecting external NVMe drives.
The whole system was running just fine* under Fedora 42–44.
Have you noticed the small “*” at the end of the previous paragraph? The system I used was not quite Fedora — I had to use my own, self-built kernel.
You see, the PCI Express controller in the Ampere Altra has some issues. Let me quote the description of the Ampere Altra erratum 82288 patches:
Per Altra family erratum, PCIE_65 may cause invalid addresses to be generated on PCIe mmio writes, impacting certain device types, notably AMD GPUs, and thus the Altra family is not generally compatible with those device types.
And longer description from patch itself:
PCIe device drivers may map MMIO space as Normal, non-cacheable memory attribute (e.g. Linux kernel drivers mapping MMIO using ioremap_wc). This may be for the purpose of enabling write combining or unaligned accesses. This can result in data corruption on the PCIe interface’s outbound MMIO writes due to issues with the write-combining operation.
The workaround modifies software that maps PCIe MMIO space as Normal, non-cacheable memory (e.g. ioremap_wc) to instead Device, non-gathering memory (e.g. ioremap). And all memory operations on PCIe MMIO space must be strictly aligned.
So, to have a working Linux system, I had to rebuild the kernel on every package update. Which usually meant “weekly”. Each Monday or Tuesday, I would update the local copy of the Fedora kernel package repository and build it using my own versioning scheme, like “7.0.2-200.fc44.pcie65.6”. The “pcie65” part reminded me which patches I had applied, and the “6” was a counter for the patch rebases.
I cloned the repository from GitHub and then rebased patches, adapting them whenever they needed work. The side effect was that I often used a newer kernel than the official Fedora release — there is a “stabilisation” branch in the Fedora kernel package repo where the soon-to-be-pushed version is present. So, when Fedora had 6.19.y kernel, I had 7.0.z one.
As I wrote in my previous post, having eighty CPU cores does not mean that the system is a good, fast desktop machine.
As I mentioned above, to get my AMD Radeon RX6700XT running properly I had to alter kernel with the out-of-tree patches. It worked, I could play some games, watch videos with hardware-assisted video decode acceleration.
Until one day, around the Linux 7.0 release, when it started to fail. Running a game ended with:
kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0
kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0
kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0
Over and over again. Watching YouTube videos became impossible due to 720 out of 750 frames being dropped, etc.
Normally I would start to bisect the kernel to find out where the problem is. But I was running a tainted kernel due to PCIE65 patches so who knew where the problem actually was…
I bought an Nvidia RTX 2060 graphics card and put it in place of the AMD Radeon.
It turned out that if I wanted to use it with the nouveau kernel driver I
still needed PCIE65 patches applied…
So I tried default Fedora kernel with Nvidia binary driver. And it worked fine. Video decoding was accelerated, some games under Wine worked as well.
But then I started FreeCAD. And OrcaSlicer. And in both cases I got crash and exit…
It turned out that there was no org.freedesktop.Platform.GL.nvidia in Flatpak
repositories for AArch64. And I used both of those tools quite often.
At that point, I gave up. And booted my x86-64 system, which had been powered off all that time. There were a lot of cables to move, some new ones to arrange, and now I have both “wooster” (Ampere Altra) and “puchatek” (Ryzen 5 3600) systems running under my desk.
Moving from 80 cores to 6 cores (12 threads) was a weird experience. A much smaller number, yet things work fine. I can load all threads and the music still plays. All games from my Steam library are playable. A working FreeCAD allows me to finish designing cases for my home projects and I can 3D print prototypes straight from OrcaSlicer.
The “wooster” system stays powered on, churning through RISC-V package builds. It may be weak in single-thread, but it flies when it comes to multi-core load.
As for the Ampere Altra, I am not planning to repeat this experiment. Another AArch64 desktop attempt would require a completely new hardware platform. And I have no plans to spend over twenty thousand PLN to buy an Nvidia DGX Spark system.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 22 – 26 June 2026
This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
This is the summary of the work done regarding the RISC-V architecture in Fedora.
This is the summary of the work done regarding AI in Fedora.
This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.
This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.
This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Community Update – Week 26 2026 appeared first on Fedora Community Blog.
Updates to translations of Fedora Documentation are again available. As announced on March 3rd, the unavailability of translation updates was due to the migration of the translation repositories and necessary tools from Pagure to the Fedora Forge. It took longer than expected but we are pleased to report this undertaking came finally to the end.
The post Fedora Documentation translations again available appeared first on Fedora Community Blog.
Long time no blog, once again - as always, I'm mostly posting on Mastodon now, so follow there if you're missing the Content. This is a bit big, though, so it goes here!
I was in Prague for Flock 2026 and Brno for Devconf.cz 2026 recently. Didn't have any issues with travel, fortunately. I was in Prague a day early for a Red Hat "face-to-face", which went fine. Had a fairly quiet/jetlagged dinner with Kevin and Tomas on the first night, and a nice dinner with Lenka Segura, Kashyap Chamarthy, Cristian Le, Frantisek Lehman and Laura Barcziova on the second night; most of them I was meeting for the first time in person, which is always good.
Flock started for real the next day with workshops. I started with "The Future of Fedora Atomic", about how we can reach the goal of all the Atomic images being based on a shared bootc base container, then went to "Forging Fedora Project’s Future With Forgejo". In the afternoon I went to "PR-based Gating for Fedora: Can We Make It Work?", which was about the idea of moving all automated testing/gating to run against dist-git pull requests (instead of mainly against updates, as is the current case).
These were all more "talking shops" than "workshops", really, but they at least mostly produced interesting conversations and concrete ideas. In particular, Cristian and I were able to determine a set of priorities for Fedora CI from the "PR-based gating" session - there was a lot of discussion of potential issues and concerns further down the road of the potential migration, but in the end we found it pretty clear that we need to improve the reliability of the existing tests and pipelines, and the ease of interpreting the results, and that's uncontroversial work that can be done first.
There was also a request from Petr Khartskhaev that we make it possible to run the openQA tests on dist-git pull requests. This had already been requested by Mo Duffy before. I've resisted doing this for all dist-git pull requests because I know at least some would fail when changes to multiple packages need to be grouped and tested together. The update system allows us to group builds into updates, but dist-git does not yet have any way to mark multiple PRs as a logical group for testing/promotion. However, someone suggested a better idea: do it by request, not for all PRs automatically. So I decided to go ahead and do it. Instead of doing another workshop, I hid in the corner of the "Languages in Floss" session and bodged up a working prototype, which is deployed to staging openQA. If you comment /openqa test on a dist-git pull request, tests on it will run in staging openQA. I'm currently working on getting the results reliably reported back to the pull request.
We had a team dinner that evening, again good to meet people and a good mix of work and social chat. At some point in there I met our relatively new RH team member Jaroslav Groman in-person for the first time, which was great - he's been doing excellent work on digging out from under our tooling tech debt and it's great to have him aboard. Peter Sklenar unfortunately wasn't able to come this time.
Day two was session heavy. There was an opening keynote track with Jef's "State of Fedora" address, live Fedora Council and FESCo meetings (effectively), and a Hummingbird talk from Stef Walter. The State of Fedora produced a couple of very talked-about sets of statistics, one showing Fedora (and friends) usage climbing solidly and one showing Fedora contributor numbers declining worryingly. The usage numbers are great, of course - especially the rapidly-growing numbers for KDE and our awesome downstream distro friends (the uBlue-verse, Asahi, Bazzite et. al.) We definitely need to dig into the contributor numbers some more, see what's going on, and whether and what we need to do to reverse the trend. There are a lot of interesting questions about whether it's Red Hatters, community maintainers, or both who are declining, and how this relates to other trends like the CVE tsunami, mushrooming language ecosystems, the rise of Flatpaks / Snaps / AppImages and so on.
The Council and FESCo sessions touched on those topics and several others, though interestingly not the AI Desktop proposal which I was kinda expecting to hear a lot about. I kinda tuned out and hacked through some of them to be honest. Stef's talk gave a good clear overview of Hummingbird - I kinda knew it going in, but it's always good to have it summarized quickly and clearly (at least I thought so).
I unfortunately didn't know about the Lunch and Learns (somehow missed them on the schedule), or else I would have gone to some! But still had plenty of fun/productive lunches with various folks. In particular I met Vít Smolík (smoliicek) in person, which was great. He's been helping out with the data team and infrastructure team and is doing some great work.
In the afternoon I went to the "Packit and Fedora: The CI Story Continues" talk, which was a good summary of the work to rationalize the mess of different systems we have/had testing pull requests. It's much better than it was before. Then I went to "Fedora Server – What you can expect from the next two releases", which was great because it clearly explained the idea of the "Home Server" spinoff which I hadn't really been clear on. And of course it was good to see Peter Boy and Emmanuel Seyman again. Alexander Bokovoy also explained his latest authentication stuff, which as always I didn't entirely understand but filed under "sounds like Alexander has it under control"...
I skipped another session to do some hacking, then went to "The Engineer’s Guide to Design", which was really interesting - I like going to slightly off-the-beaten-path talks. I don't really work on front-end UX stuff a lot, but it was still interesting to hear a perspective from someone who's been both an engineer and a designer on the impedance mismatches that can happen and the basic concepts it's useful for both sides to know about the other. Then I saw "Artifact Signing in Fedora", where Jeremy Cline gave some background and an overview of his ongoing project to rewrite the Fedora signing server, which is badly-needed work that we're really grateful for.
In the evening we had the official party, at a really nice outdoor food court with a reserved space for the conference. The organizers brought over so many appetizers I barely needed to use the meal ticket, but managed to force down some tacos nevertheless. Had a great time chatting with various folks, then later headed to a Belgian beer bar for more drinks with Justin Forbes and several others.
On the final day I started with "The Packager's Guide to openQA Failures" of course - Lukas Ruzicka (my openQA henchman) did a great job covering openQA failure analysis from the perspective of a packager, and I contributed a few notes here and there. We had a good crowd who seemed really interested, which is always great news. After that I saw Kevin Fenzi's "scrapers gotta scrape scrape scrape" talk on all the fun we've been having with scraper networks flooding our infrastructure. I know some but not all of it beforehand, and of course Kevin explained it well and the audience was very engaged. Plus I got to tell my story about the time I thought a dastardly new scraper network had figured out how to evade Anubis, but it turned out that the call was coming from inside the house (i.e. I had done a slightly silly thing in openQA which made it effectively DoS Koji...)
After the coffee break I saw "Fedora Test Days - a11y", which was actually a somewhat wider talk from a couple of RH folks working on accessibility testing about their current testing and future plans. It was really interesting and it was good to be able to speak with them briefly about the possibilities of using openQA for this. I stayed in the same room for "Two Years In: Accelerating Microsoft Contribution to Fedora", where Jeremy Cline, Brian Exelbierd and Reuben Olinsky covered some Microsoft's (much-welcomed) contributions to Fedora and also some stuff about Azure Linux.
After that was "Upgrading Fedora Infrastructure from Nagios to Zabbix" - this migration has been ongoing for a while but was much-needed as a modernization and also a better architecture. I found it very useful as I do have plans to add more detailed monitoring of openQA and the talk was very helpful in letting me know how to get started with that.
After lunch came lightning talks. I had proposed one about "new stuff we did in Fedora CI lately", which kinda overlapped with some of the full-length talks in the end, but it still got a lot of votes, so Cristian Le and I went up second and did a rapid redux of the Packit consolidation work, improved result displays, optimizations and improvements to the generic tests, addition of rmdepcheck and so on. My voice was giving out by this point but we just about got through it. There were a lot of other great talks and everyone managed to come in under time, which was impressive.
After that was a Fedora Mindshare session which I half-followed and half-hacked/dozed through (was starting to get tired at this point!), then the "Fedora’s Contributor Recognition Program" session where much-deserved awards were handed out to Ankur Sinha, Fabio Valentini and Justin Forbes. I was on the voting panel for this so it was great to see the culmination, and the trophies contributed by the Nairobi GNU/Linux Users Group were awesome.
I almost forgot to mention the whole time I was struggling with some sort of wifi driver bug - it seems there was a troublesome AP or something at the hotel which caused my laptop to crash constantly. And the hotel wifi was terrible, and I only had 5GB of data on my phone, so I couldn't really rebase to F44 to avoid it. Lots of fun.
That was the end of Flock; things wound down and I had dinner with...some people...somewhere (possibly the third Vietnamese of the trip? Things are getting fuzzy). The next day was a welcome quiet day traveling from Prague to Brno - train and bus, no problem except waiting for the bus was very hot. I stayed at the Hotel Vaka, which I've never been at before, but it's quite nice. The whole event was a bit weird because Moto GP (the motorbike equivalent of Formula 1) moved their Brno race to the same weekend Devconf.cz would usually be on, and took all the hotels, so devconf was hastily moved to Thursday/Friday. Hotels were still hard to get and I only just managed to grab this one at a decent rate. I was able to rebase my laptop finally and stop worrying about wifi crashes, and had a nice quiet pizza dinner at Doe Boy.
So a shortened devconf started with the opening session, then another Hummingbird keynote, this time with Valentin Rothberg as well as Stef Walter. It added a bit of detail compared to Stef's Flock talk, and there wasn't anything else on. Then I saw "OpenShift CI: What if we stopped retesting everything all the time?", which was an interesting talk about the tradeoffs involved in doing automatic retests of complex merge chains in a big project with lots of PRs trying to be merged all the time (OpenShift). It wasn't directly applicable to anything I do, exactly - Fedora updates don't quite map to PRs in a git repo - but in a more general sense it was useful in suggesting methods for thinking about this kind of complex tradeoff and how to measure the impact and efficiency of testing processes.
Next I saw David Duncan's "From Laptop Chaos to Fedora Cloud: Quadlets and Containers", mainly because it was David, but it turned out to be a good talk about a way to make a relatively complex multi-container side project buildable and deployable the same way on your laptop and in The Cloud, using systemd quadlets. I've dealt with this general area before a few times. David made a solid case that quadlets are a good approach, in his usual fun and personable style.
After that I saw Zbigniew's "New security features in systemd" - honestly I missed some of this one, but got the gist of why systemd is trying to modernize various mechanisms here. Then I went to "Beyond the Screen: A Deep Dive into Linux Accessibility for Developers" by Vojtech Polasek, which was one of my highlights of the week - a really good explanation of how computer interaction really works for blind people, and what properties applications should have (and avoid) to make them usable. This is obviously very important for testing purposes.
Next I went to "Stop Looking for the Perfect Prompt: The Design-First Workflow for Coding Agents" to get my corporate mandatory minimum AI Content(tm) - it was actually a pretty good and accessible talk on different approaches to LLM-based feature development. I still don't really use LLM code generation heavily (for a start, I spend so little time actually sitting at a blank screen typing significant amounts of code that it's not really worth worrying about), but it's good to keep up with the latest ideas about how to do this kinda thing. Continuing with the AI theme I took in Tomas Tomecek and Laura Barcziova's "How AI helped us ship updates in a Linux distro", which was a practical talk on the system behind Hummingbird and the actual approach it takes to (sort-of) AI-driven package builds.
After that I think I did some Fedora booth cover for a while. Lukas Ruzicka and Vojtech Trefny were holding the booth down for most of the weekend, but I stopped by and did an hour here and there to give them some relief. It's always a lot of fun chatting to people about Fedora, other distributions or stuff that has nothing to do with Linux at all. Lukas had set up a Framework laptop with a MIDI keyboard attached to show off that it's pretty practical to do audio creation on stock Fedora kernel and audio stack these days; Vojtech and I had absolutely no idea how to use it, so we had lots of fun trying to talk about it to people and eventually telling them to come back when Lukas would be there...
In the evening we had the conference party, which was at the same outdoor swimming pool it's been at for a couple of years(?) now. It's a great venue - you can grab some food and a drink and then relax in the shade under some trees. I wound up sitting round with a really interesting mixed group of folks (Red Hat and non-Red Hat, some big cheeses, some medium-size cheeses and some fresh faced...cheese curds? Help, my metaphor is falling apart) most of the night, it was a great evening. Walked back most of the way to the hotel with Stef Walter, setting the world to rights as is the tradition after a few drinks at conference parties...
On the second day I started with "From Podman to Production: Building Trusted Container Images with Konflux on OpenShift" by Vladimir Sokolenko, which was probably the most understandable and useful Konflux talk I've seen so far. I think I then maybe did a bit more booth cover(?) and some hacking, then wrapped up with a nice three-talk track in the same room - "Identical Testing Environments from Laptop to CI with tmt and Testing Farm" by Cristian and Petr Šplíchal (covering their work to make tests more reproducible from Testing Farm to your local system), "systemd-sysext in Production: What We Learned Extending /usr Without a Package Manager" by Brian Exelbierd and Daniel Zaťovič (a really good retrospective on their experience using sysext in the real world to ship additional / alternative software on Flatcar), and "Local package layering on bootc systems with DNF5" by Evan Goode (explaining his design and plans for providing a convenient, dnf-ish interface to "overlaying" packages on bootc-based installs). I met Evan in person for the first time at the party, and it was great talking to him. I hope his work on this goes well - we really need it for the glorious bootc-based future.
After that was the traditional wrap-up session with the trivia quiz (I won a t-shirt!) and then I said bye to a lot of people and melted off (it was extremely hot) to the train station...to find that my train to Vienna was delayed by nearly an hour. Ah, well. Eventually made it to my hotel in Vienna (which was incredibly nice, just wish I'd stayed there longer...) and had an excellent dinner at Iki (highly recommended if you're in the area). Got in a couple of swims in the nice-but-small hotel pool before and after sleeping, then had a Vienna take on avocado toast (interesting!) for breakfast and headed off to the airport, and that was another trip in the books.
On June 19 we released systemd v261 into the wild.
In the weeks leading up to that release (and since then) I have posted a series of serieses of posts to Mastodon about key new features in this release, under the #systemd261 hash tag. In case you aren't using Mastodon, but would like to read up, here's a list of all 27 posts:
ConditionFraction=console= Initialization from UEFIbootctl linksystemd-sysinstallsystemd-boot A/Bkexec Handoversystemd-repart's BlockDeviceReplace=.rr Drop-ins for systemd-resolvedsystemd-report-cgroup & systemd-report-basicvarlinkctl serveconfext& sysextfrom the ìnitrdextra stanza in UAPI.1 Boot Loader Specificationsystemd-oomd Rules FIlesI intend to do a similar series of serieses of posts for the next systemd release (v262), hence if you haven't left tech Twitter for Mastodon yet, now is the opportunity. My series for v262 will begin in a few weeks most likely, under the #systemd262 hash tag.
In case you are interested, here is the corresponding blog story for systemd v260, here for v259, here for v258, here for v257, and here for v256.
On Saturday May 30th 2026, the XV edition of P.I.W.O. Poznań Free Software Fest was held in Poznań,
Poland.
P.I.W.O. is an event with a long history. Between 2004 and 2018, it was organized by various student associations at the PoznaÅ„ University of Technology. After 2018’s XIII edition (superstition much?), it entered a long hiatus that lasted until 2025, when members of the newly-formed Knyfyrtel PoznaÅ„ Hackerspace decided to bring it back. The reactivated event proved a huge success, with the XIV edition bringing in 197 attendees. As such, ambitions for 2026 were rather big.
This year’s edition was the result of combined efforts of three PoznaÅ„-based organizations:

Thanks to Webrains, for the first time in its history, the event was held at the Adam Mickiewicz University in PoznaÅ„ – namely, the uni’s Faculty of Mathematics and Computer Science. Also a historical first, the XV edition was granted honorary patronage by the President of PoznaÅ„ City Council.
The event spanned almost the entire Saturday, opening at 9:30 am and closing at 7:35 pm. The agenda was tightly packed, featuring 3 lecture tracks with 24 talks, 2 workshop tracks with 8 activities, plus a LAN Party track with 3 tournaments, as well as “free play” sessions. There was also a quiet corner where, thanks to the “Honte” group, attendees could relax and learn to play Go.



Throughout the years, one of P.I.W.O.’s hallmarks was the lunch break, with the attendees being provided free pizza. This year couldn’t be any different, with some 66m² (or 710 ft²) of pizza being delivered to the venue. (It disappeared frighteningly quick.)


The Fedora Community was represented by:

This year’s P.I.W.O. served as an opportunity to announce the creation of SPOIWO – Sojusz Przyjaciół Otwartego i Wolnego Oprogramowania (Alliance of Friends of Open and Free Software). This diverse coalition of social and technology organisations, cooperatives and open source businesses signed a declaration in support of digital sovereignty. The alliance was formed in response to the ever-deepening of public institutions’ dependency on closed platforms and their loss of control over data and communication.

The signing ceremony also featured speeches by representatives of SUSE Poland, Polish Linux User Group, “Internet. Czas działać!� Foundation and PLZ Spółdzielnia.
The event wrapped with 452 attendee badges issued, which exceeded even the most daring of expectations. (The number also explains why the pizza disappeared so quick.) The bar for the next edition is set high, but so are the organizing team’s ambitions.



If you’d like to learn more about the event, watch the live stream recordings, or subscribe to news so you won’t miss the announcement for the XVI edition – you can do all of that on the event’s website, at piwo.sh.
The post Fedora at XV P.I.W.O. Poznań Free Software Fest appeared first on Fedora Community Blog.
Dear testers, we're happy to announce Kiwi TCMS version 16.1!
IMPORTANT:
This is a minor version release which includes security related updates, several improvements, database migrations, new API methods and updated translations.
You can explore everything at https://public.tenant.kiwitcms.org!
---
Public container image (x86_64):
pub.kiwitcms.eu/kiwitcms/kiwi latest 12fc270ef5b9 862MB
IMPORTANT: version tagged and multi-arch container images are available only to subscribers!
hub.kiwitcms.eu/kiwitcms/version 16.1 (aarch64) ae3442ef043b 24 Jun 2026 715MB hub.kiwitcms.eu/kiwitcms/version 16.1 (x86_64) 8a98927b8581 24 Jun 2026 696MB hub.kiwitcms.eu/kiwitcms/enterprise 16.1-mt (aarch64) 0610f65a5fd5 24 Jun 2026 913MB hub.kiwitcms.eu/kiwitcms/enterprise 16.1-mt (x86_64) a3f823870351 24 Jun 2026 892MB
IMPORTANT: version tagged, multi-arch and Enterprise container images are available only to subscribers!
Follow the Upgrading instructions from our documentation.
Happy testing!
---
If you like what we're doing and how Kiwi TCMS supports various communities please help us grow!
I have a 5G modem in my Lenovo x13s and t14s. I run Fedora on them, currently Fedora 44. I have had issues in the past when traveling. The 5G modem works fine when in the US but will not connect to any provider when roaming. It has worked after some time in the UK and Australia, but not in other countries. I use Google Fi for phone service, which allows roaming with the same data allowance as in the US.
After some digging during my current trip, when it wasn’t connecting, I think I have found the issue and a workaround to ensure I can connect. Google Fi uses two networks, T-Mobile in the US and Three UK when roaming. It also uses T-Mobile for roaming. The issue seemed to be that the towers were rejecting the SIM card, attempting to register using T-Mobile’s default APN that seems to be baked into the SIM card as a default profile. The ModemManager logs looked like the following
ModemManager[1603]: <msg> [modem0] 3GPP packet service state changed (unknown -> detached)
ModemManager[1603]: <msg> [modem0] 3GPP packet service state changed (detached -> unknown)
ModemManager[1603]: <msg> [modem0] 3GPP packet service state changed (unknown -> detached)
ModemManager[1603]: <msg> [modem0] 3GPP packet service state changed (detached -> unknown)
The trick that got it to connect was to make a change to the default profile used to connect to the phone tower was to run an mmcli command: “mmcli -m 0 –3gpp-set-initial-eps-bearer-settings=”apn=h2g2,ip-type=ipv4v6” Which forces the sim to use the Google Fi APN and not the T-Mobile one
For quite some time I wanted to explore openshell. I naively thought it would be easy to set up on my workstation that has an AMD GPU, together with llama-cpp as an inference server.
After following the tutorial, I was immediately stuck even with running the gateway in a podman container.
I guess I’m too old for this stuff because I let Claude Code to investigate the problems.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 15 – 19 June 2026 (Flock Week!!)
This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker
This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.
This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.
This team is working on keeping Epel running and helping package things.
This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Community Update – Week 25, 2026 appeared first on Fedora Community Blog.

درود بر دوستان، همراهان و اعضای خانواده بزرگ طرفداران فدورا امروز با افتخار پانزدهمین سالگرد تأسیس وبسایت FedoraFans می باشد. پانزده سال پیش، با هدف ترویج فرهنگ نرمافزارهای آزاد و متنباز، آموزش لینوکس فدورا و ایجاد فضایی برای تبادل دانش و تجربه، این وبسایت فعالیت خود را آغاز کرد. آن روزها شاید تصور نمیکردیم که […]
The post پانزدهمین سالگرد وب سایت طرفداران فدورا first appeared on طرفداران فدورا.Getting a little more organized in my workshop. My pain point was boxes of nails or screws falling off shelves.
And, of course, I wanted an excuse to use the laser cutter.


I took a lesson from Minecrafters and put an instance of what was inside the box on the front id the box.
Caveat lector
This post discusses tools reluctantly written with AI assistance. If you don’t entertain using them under any circumstance, and think even reading about them legally compromise your ability to reimplement them yourselves, stop reading now
Today’s post introduces dbranch, a tool to update a Debian package in unstable, and rebuild downstream branches (currently supports Ubuntu PPAs and stable proposed-updates; backports support could be easily added once I have a package that needs it). Eagle-eyed readers might notice the naming similarity with my previous tool ebranch; and the credit for the name and inspiration eventually came from Jens Petersen’s fbrnch.
I was looking forward to this year’s Flock - Fedora Project Conference. I had to cut my vacation short and return from my river trip a day early.
I arrived in Prague at noon on Sunday, just in time to attend František Lachman’s workshop “PR-based Gating for Fedora: Can We Make It Work?�. We all agreed that we want all contributions to happen through pull requests and only after all tests pass. However, we also realized it is not easy: gating for multi-package PRs will be difficult (unless we have a monorepo). Proven packagers will need special handling (can we work on this later?), and first, we need the new Forgejo—everyone is looking forward to it. Coincidentally, later at Devconf, I spoke to Marcela, who mentioned that SUSE already has Forgejo for all packages and that it does not scale as they expected.
But the important message from Miro was: “we should not force maintainers to use a new workflow; we should make it pleasant and easy to use so they want to use it on their own.�
After this workshop, I checked into my hotel and later returned to the venue. We had a passionate conversation with Aleksandra, Miro, and Karolina during a card game. We then moved with several other people to a nearby pub that served Belgian beer. I had only one glass, but I felt very dizzy and tired, so I returned to the hotel sooner than the rest of the gang.
On Monday, I joined Collin for breakfast, and we discussed the dark corners of RPM building.
Then I moved to the venue and listened to Jef Spaleta’s “State of Fedora� talk. Fedora’s usage is growing, and KDE is working enormously well, but the decline in Fedora’s contributors is accelerating. We have to figure out why and take action, rather than just setting up plans without execution.
The “Fedora Council Strategic Proposals� session was great. Two highlights stood out:
“It’s not the new generation that is different. It’s you who is different,â€� said Aleksandra. “They talk about changing a wallpaper; we are talking about burnout.â€�

“I would not join Fedora if it were stable. I want to improve it.” Jef Spaleta

The subsequent “FESCo Q&A� was less vibrant but provided a great opportunity to learn about members' views. For newcomers, Kevin’s remark that FESCo’s role is sometimes to say “No� and stop things was likely interesting. However, FESCo cannot drive new initiatives; individual contributors must do that.
Then I watched Stef’s talk about Hummingbird; this was not new to me as we closely cooperate on agentic packaging.

I also observed the talk “Packit and Fedora: The CI Story Continues�, as it summarized what my team accomplished with Fedora CI. There were many examples, and the feedback was positive. I appreciated that Matej managed to substitute for Nikola, who got sick at the last minute.
Several ideas in the Q&A highlighted that PRs are not mandatory and that maintainers do not always follow upstream in a timely manner.
I attended “The EU CRA vs. Community: Why You’re Safe, and How Stewards Help�. The CRA was new to me, and the session was packed with concrete information. You may check the most interesting slides in my Mastodon post. The biggest takeaway is that open-source maintainers do not need to worry, but they should be prepared that companies using their software will start email-bombing them in August. There was a nice guide on how to politely reject them.
I took a break and talked to people in the hallway, sharing remarks with my team members. I talked with Kashyap about bootstrapping RISC-V; he was thankful for our support in Copr. We drafted next steps, only to find that Kashyap’s colleague already did that while I was on vacation.
I then observed “What’s Cooking in Copr, Testing Farm, tmt, Packit and Log Detectiveâ€�, where Franta and people from my team shared our current work and future plans. It was great that Franta brought the team members on stage.
After this, I was quite tired, so I headed to the hotel for a quick nap and shower to get ready for the Official Party, which took place at Manifesto—a local market with various street foods. I met many familiar faces as well as new people.
On Tuesday I listened to Adam’s “RHEL 11 is branching from Fedora 46: What this means for youâ€� talk and appreciated his honesty in answering “I do not knowâ€� to several questions. Later in the hallway, we discussed whether branching RHEL during the Fedora branching phase is ideal, and why we don’t branch during the beta phase instead.
I then moved to Kevin’s talk, “Scrapers Gotta Scrape Scrape Scrape�. This topic was familiar, as we are also fighting scrapers, and Jiri from my team helped package Anubis and its dependencies for Fedora. However, I learned several new things, and the follow-up Q&A was fun. If you think people ranting about scrapers only wrote inefficient web applications, you should definitely see a recording of this talk.
I attended Frederick’s talk, “Machine-readable package lifecycle information in repository metadata�. He spoke about their DNF plugin that can set various End-of-Life dates for different packages. This was extremely helpful, and since we wanted to do something similar in RHEL, I immediately emailed the DNF team to introduce them to Frederick.
After the talk, I bowed to Frederick, as he is reportedly the person behind the migration of AWS Linux to Fedora.
I listened to Microsoft’s talk, “Two Years In: Accelerating Microsoft Contribution to Fedoraâ€�. It was interesting to see how much Microsoft uses Fedora. The highlight was that the presenters were from different teams within Microsoft and were largely unaware of each other’s work.
I then talked to people in the corridor, including Bex, who introduced me to two students from Jihlava interested in a high school internship.
The highlight was definitely the lightning talks. They were strictly 5 minutes long (including notebook setup). I learned about current Lenovo support for Linux, how Miro sped up the last Python mass rebuild, and I reported on the current status of the SPDX migration, noting that the next steps will proceed without me. Fortunately, Max started a SIG that wants to take over the work. I shared some information with him that didn’t fit into the lightning talk. Jiri presented his achievement of packaging Goose for Fedora and even provided a live demo!
By this point, I was quite tired, so I passively watched the presentation of the Contributor Recognition Awards. Then, I went into the city to meet a friend, and we attended the theater performance Tahle země je naše.
Tip: If you want to see any mentioned talk, you can find it in the schedule and then rewind to the specific time in the Streams. The edited and cut talks are usually available weeks later on Fedora’s channel.
DevConf CZ is huge even. With over one thousand participants and eleven tracks - it is huge. As this is a conference in my hometown I volunteered to help organizers: I chaired one of the rooms and acted as a fire marshall. That includes overseeing A/V tech. Help speakers to connect to video and mic. Make sure they do not run with that. Remind them the time.
This year, I chose a room with Lightning talks. There was 15 minutes for each talk and 5 minutes for a break. And it was a blast!
I chaired the Thursday morning and Friday afternoon. One of the best delivered talks was from new junior who was speaking for the first time - yet she overperformed more senior people.
“AI accelerated learning. Mentorship directed it. Real systems grounded it.” Kaja Prokopova @ “From Sysadmin to Software Engineer: A Non-Traditional Path into Tech”
Petr Kaška spoke about detecting malicious prompts. You can attack your model using https://github.com/Security-FIT/PromptAttacker
Anežka Müller speaks about how she organizes a small one-day, one-track conference, Python Pizza. You can use her recipe for free https://docs.python.pizza/
James Freeman with his theory about technology dopamine culture.
Jan Jurca spoke about tests on the filesystem that produce different results if you use the filesystem for some time. You can artificially simulate the usage of filesystem and then run the benchmarks using Filestorm https://github.com/janjurca/Filestorm
See the interesting slides.
I did a small cameo at lightning talk by my student Peter Stefunko in his talk “From SBOM to Dependency Stacks: Making Software Structure Visible“ where he tries to visualize the state of the operating system using famous XKCD comics “Dependency�. You can check his work at github.com/peter-stefunko/rpm2xkcd2347.
I did not attend Thursday’s party as we had an anniversary with my wife and preferred my wife over all of you. 🙂
I met many old faces, former colleagues. And the biggest surprise was the booth of Free Software EU where I found the Czech edition of the book Ada & Zangemann that I helped to translate. I did not know it was already printed - that was because the print was finished that morning. I then called Tomas Stary who took the work from me and who I never met - only to find that he is standing beside me in the queue for ice cream 🙂
Mathias post about the new print https://mastodon.social/@kirschner/116770321504331386
Half of the batch. Fresh from print.
Later we discussed with Tomas, his publisher and Lucie from RH additional steps to advertise the book.
Last week I had to extend complicated, unfamiliar Helm chart. While I've discussed approach with my carbon-based coworker, actual editing and extending was done by Claude Code.
Refactors and renamings were tedious, but Claudius did them in no time. During the review we decided to significantly change the way chart is organised. Claude executed the changes perfectly.
If I had to fully understand the working of the chart, it would have taken me a good part of the week. Making the changes – another day or two. Significant rework midway – I'd probably be too demotivated to do it.
With AI assistant, I have finished work in two days. Tested, simplified, cleaned up.
But I have no more skills than I had before. I do not understand this Helm chart much better. I've spotted a thing or two during the review, but in no way I have a fuller comprehension. AI let me borrow expertise without acquiring it.
Next time when I'll have to work on this chart, I will use Claude again. I've got softly locked-in in using AI assistant to work. And I'm not happy with that.
Now, my employer sees this as an acceptable tradeoff. Paid for some tokens, unlocked couple of my pricy senior-level hours to do other stuff. It balances. Subsidising Scam Altman and his ilk is a money well spent from this perspective.
We are at the point where we offload more work to so-called AI. Those are just tools. You know what more primitive tools we had before? Assemblers. Then compilers. No one writes machine code by hand anymore. Maybe someone despairs because of it, but people commonly writing binaries are more likely to be dead by now.
No one treats high level compilers as fad and stuff kids these days do. It's just a tool, expected to work and dissappering into the background.
There's one important difference. We do not have to pay for the compilers,
thanks to work of the GNU Project last century (gcc) and Apple more recently (llvm/clang).
But at this point we are paying for tokens. I expect that as we
cannot fathom working with any codebase without a compiler now, a LLM-driven
assistant will be required to tackle bigger projects in near future.
To be free, we need to be able to run assistants at reasonable cost. Free is reasonable. Not paying through the nose for electricity is reasonable. We can hope for good quality chinese models to be available for free. We need a free toolkit revolution again. It was GNU Compiler Collection for the previous generation. Would it be Kimi now?
And we need the proprietary AI bubble to pop and rationality to return.
066/100 of #100DaysToOffload
Way back in September I apologized for the gap since my last update. I am, once again, sorry it’s been so long since I posted an update. I recently presented at talk at Flock 2026 - if you prefer consuming updates via video where live demos fail, you can find that on YouTube.
This post is something of a summary of that talk, but the short version is Siguldry has all the features Sigul has, plus some. That means we can start deploying it in the coming weeks.
In the last post, I noted I had implemented server-side support for PGP signing. That’s gone now, I’m pleased to say, because I came across a much neater approach. I implemented a small PKCS#11 module inventively called siguldry-pkcs11.
I can’t take credit for any of the ideas I’m about to describe, since I stole them from multiple other projects. Our friends over in Flatcar have to sign things as well, and they use a key stored in Azure Key Vault. The way they use it is that they implemented a minimal PKCS#11 module. That was my primary inspiration, but I also recently spent some time building a drop-in replacement for pesign-daemon and the idea of exposing the signing interface over a Unix socket that can be mounted into isolated build environments was another concept I borrowed.
For those who aren’t familiar, PKCS#11 is a standard that is made up of a C interface. To implement it, you create a shared object file with a few well-known C functions used to discover your implementations of the interface. Users load your shared library, call a well-known function to get a table of functions where you provide your implementations for the various features. What’s nice about this is that common libraries like OpenSSL can speak to PKCS#11 modules, so you can make any tool that uses those common cryptography libraries use your implementations.
PKCS#11 is a fairly broad specification that covers not just signing, but also encryption/decryption, digest calculation, random number generation, and key management (creating, modifying, deleting, etc). What I realized while poking around Flatcar’s implementation is that you actually don’t need to implement everything. You can, instead, stub out all the functions you don’t want to implement and have them return the handy “function not supported” error code. The list of functions I opted to not support is extensive.
In fact, all I implemented was the functions to authenticate, list keys, and sign. However, that’s enough to make it possible to use the Siguldry server with tools including (but definitely not limited to): rpmsign, ostree gpg-sign, cosign (if built with PKCS#11 support), gpg2 (with the gnupg-pkcs11-scd service), sq (once it merges its PKCS#11 support), systemd-measure, systemd-sbsign, pesign, and perhaps most humorously, ssh. All these tools know how to speak to PKCS#11 modules so they “just work” with Siguldry. Any new tool people make will also likely just work.
One thing that’s neat about this approach is that we sit between the tool requesting the signature and the signing server. This means we can hash the content client-side and requests to the server are very small: just a hash, the algorithm used for the hash, and the key name. No more sending a 4GiB ISO over the network only to have the server hash it, that all is done before the request starts.
The last thing that’s really cool about this approach is that if Fedora decides it needs a new signing server and spends some big bucks on a fancy hardware security module, it will definitely ship with a PKCS#11 module of its own so we can start using it with our existing tooling, no development required. If Siguldry stops being the right choice for Fedora, it’s really easy to swap it out.
The other thing I did was to implement a Siguldry client that binds a Unix socket and proxies requests from the local system to the remote Siguldry server. I did this because you can expose the socket into locked down environments, such as RPM build environments, install the PKCS#11 module into that environment, and sign things. Right now Fedora uses this general approach for SecureBoot, except it’s specific to the pesign utility. While I’d prefer to disconnect the signing event from the building of a package, it’s important to support the current workflows and this was a neat way to do that which is generic across signing tools.
It has another advantage. Since the Unix socket is set up using a systemd socket unit, we can sandbox the client proxy, and also configure it with the necessary credentials to connect to the Siguldry server and unlock signing keys. This lets you, if necessary, allow anyone to sign content without needing to manage secrets themselves. The secrets can be encrypted with systemd-creds and bound to hardware. All we have to do is ensure the keys that are configured that way get a special flag when queried via PKCS#11: the “protected authentication path” flag.
The primary way Fedora uses its signing server is via an AMQP consumer that automatically signs things. Robosignatory is the current tool used, but it needs some significant changes to work with this new workflow. In particular, we don’t want to sign content serially, but the fedora-messaging Python library commonly used to interact with the AMQP broker doesn’t handle concurrency well. And, since we now call out to the particular tool used to sign content rather than sending it to the server, the consumer is primarily a mapping between message topics and those various tools.
All those reasons led me to re-implement it, and since I’ve got no imagination with names, it’s called siguldry-fedora-autopen. It uses the lapin AMQP client with Tokio to manage hundreds or thousands of RPMs/ISOs/containers/etc signing operations at the same time. This means builds should no longer languish in the signing queue for many hours.
All this probably (hopefully) sounds great, but as with all things there are a few problems. Well, really just one big problem. Back in the Fedora 37 days, we enabled IMA signing for RPMs. The short version of how that works is that each file inside an RPM gets signed. And, unfortunately, the PKCS#11 interface is synchronous. This means that rpmsign requests a signature when it creates an OpenPGP signature on the RPM header. It then requests a signature for each file, waiting for each signature request to finish before starting the next one. Now, when the RPM only has dozens or a couple hundred files that happens fairly quickly. A signature might only take a couple milliseconds and the request/response latency might be a couple dozen more milliseconds (or a lot less depending on how close the server is from the client).
Of course, not all RPMs only have a few hundred files. Some have many, many thousand. For these, a simple OpenGPG signature takes less than a second (even if the RPM is, say, 10GiB). The IMA signing can take many minutes, depending on how many files it has. I’ve been running a client locally, with a server in a nearby datacenter, and the largest time I saw for a signing operation was around 40 minutes. This is really unfortunate, but it is important to remember that we can now do thousands of signing operations at the same time, so even when these slow builds are signed, other builds can be serviced in a timely manner.
There’s a couple ways we can make this better, but the “easiest” involve a custom signing implementation that avoids using the PKCS#11 path.
In the next few weeks I’m hopeful we’ll have enough time to sit down and deploy Siguldry to Fedora’s staging environment. I want to really kick the tires and ensure it’s rock solid before we move it to production, but I think it’s reasonable to hope for that in the next couple of months.
While that’s happening, I’m going to add support for ML-DSA signing. That will allow us to produce signatures that are safe in a post-quantum cryptography world. After that, I’ll investigate OpenPGP’s hybrid signature schemes, although given recent developments I wonder if we want to bother with those. I’ll defer to what the professional cryptographers have to say about that.
Sometime in the next few Fedora releases, though, you should expect to see new signature algorithms in use (pending FESCo approval etc etc).
Thoughts, comments, or feedback greatly welcomed on Mastodon
Another wonderfull flock is in the books. This post is likely to be kind of long, and was written a few days after I got back home, so it's likely I forgot some things or misremembered them somehow. If so, it's not intentional.
TLDR version: Another great flock. Lots of good conversations, lots of good talks, good food, good friends. I'd like to give kudos to all the people who put things on. It's not easy planning a large event like this and at least from my perspective everything went very smoothly.
My journey started a few days before flock on Thursday the 11th. I had actually planned to come in a day early to recover from travel, but it turns out there was a meeting scheduled then, so I got to recover in the meeting instead (more on that in a minute).
Two hour drive to portland airport (PDX) turned into about 2.5 due to traffic, but I had planned buffer so it was fine. This time I was taking icelandair via Keflavík (KEF) instead of my usual jump via Amsterdam. The transfer time was quite low (around an hour), but I read that it was easy to transfer there.
The flight was fine, the transfer was a bit fun: They deplaned us out on a tarmack and we had to take a bus to the terminal. That took a while as they wanted the bus fully loaded. Then, they said the customs area was understaffed today and would take longer than normal. So, I rushed as best I could and ended up at my gate only to hear that the next flight was waiting for crew and hadn't boarded yet. :)
The hotel in prague was the same one as last years flock. Last year I had stayed at a nearby hotel, but this year I just stayed at the conference one. I have to say the rooms were nicer there and it was pretty nice to not have to walk over and back a lot.
I got in friday afternoon and took a short nap, then met up with Tomas and Adam for dinner. We picked a nice sounding place nearby and it was a bunch of nice conversation and food.
Saturday I had planned to recover from travel, but instead I went to a face to face meeting we had with a bunch of the Red Hatters that were coming to flock. There wasn't anything secret here, it was mostly just discussing what various groups were working on and how we could all help each other out and get things landed/working.
There was a lot of technical discussion and planning type things along with lots of things that were further discussed at flock.
I was able to chime in on some hardware questions and some cloud resources along with some policy questions.
Saturday evening was the 'sponsors dinner' with a bunch of folks from companies sponsoring flock along with leeds of various parts of the project. Amusingly, it was in the same resturant we were at the previous night! It was all good though. I sat near Jermey Cline, David Duncan and Jef Speleta and we had a bunch of conversations on tons of topics.
The first day this year was workshops, the keynote and other regular talks would be the next day. I can understand why you might want to do things this way as it allows you to get people excited and working on something and then leverage that work for their talk in the later days. On the other hand it means that the workshops had a lot of talk/presentation before being able to get to the actual work part of the workshop.
The first slot I ended up in the 'hallway track' (as I would many times in the coming days). Talked to too many people to even list. :)
Next I went to the forgejo workshop. It was fine and there were a few questions, but either everyone had burned out their discussions on it, or the folks with those questions/discussions weren't there as it seemed to go very quietly. I think lots of contributors are getting used to forge.fedoraproject.org now and can imgaine how a migrated src.fedoraproject.org might look.
Lunch was up next. This year the mentor summit was doing a 'lunch and learn' thing each day, and I went each day. I sat at the 'operations' table on Sunday and had a great conversation with several new to fedora folks. We talked about matrix a fair bit and software we all use.
After lunch I went to the Fedora Data & Analytics Workshop with Justin and Michael. I think things were pretty interesting, but we spent a lot of time getting everyone up to speed on the background and only had a short time at the end to work on workshoppy things. Still, very interesting stuff here. We have lots of data, but we dont really analize it very much, and I am hopefull this system will allow us to do so! Right after this workshop I got pulled into a hallway track discussion and didn't get a chance to say Hi to Michael in person. :(
After that was more hallway discussions and then our team had a team dinner. Always great to see people I work with day to day over the internet in person. Some of us then rushed back from dinner for...
The flock 2026 candy swap. This year was even bigger I think that last year. We barely fit in the bar where this was happening. Tons of good stuff, lots of good stories. A few people said to me "Do you do this every year? Wow, this is great! I would have brought something if I knew". After the swap, beers in the bar and I managed to have a nice discussion on Books with MattH and Aoife along with some music discussions with many others.
Monday started out with the keynote state of Fedora from Jef. There was even a nice bit of stats out of the data workshop that was interesting.
Then up in the same room was the Council round table, followed by the FESCo one. Interestingly, the Council didn't get any AI related questions, but FESCo did. Do watch those recordings if you are interested in any of those questions/answers.
There was a talk on hummingbird after that, which was great. I'm excited to see hummingbird and to see what it's going to grow into.
Mentor summit lunch and learn monday was the 'infrastructure' table for me. We had folks from Azure linux and Amazon linux (both now based on Fedora) asking a bunch of infrastructure questions. I also asked them a bunch about their infrastructure too. It was very encouraging this year to not only see groups like this at flock, but asking how they can be more involved and help Fedora out and thus help themselves as downstreams. I'm really hopefull we can help each other and all end up better for it. This was probibly the most encouraging thing I saw at flock this year. :)
After lunch I went to Lenkas Forgejo runners on fedora forge talk. This was largely stuff I knew about, but it was great to see all in one place. There were some nice questions. We are definitely seeing some good use from these runners and it's good to see work on them continue.
I had a bunch of hallway conversations after that, then off to...
Post-quantum cryptography for Fedora infrastructure with Alexander and Jakob. The timelines here are really scary to me. There's a lot thats just starting to land now, but the dates for moving things are coming up super fast. I hope it will all work out, but it's a lot of things and a lot of work. :(
Dinner Monday was the flock reception. It was in a nearby outdoor food court, which I had actually had lunch at last year. It was a nice setup, they blocked off a large area of tables for us and gave us vouchers to get a meal at any of the... many food places. They also brought us all a bunch of free appitizers to the point where it almost wasn't worth getting a real meal. :) Had a lot of conversations on a lot of topics here. I managed to find Michael Winters and we started to talk, but then they called the group photo and we were seperated, then after that we both got pulled into other conversations. (This was a theme)
A group of us then went to a belgian beer place and stayed talking until the wee hours.
The last day already!
I started with the "RHEL11 and what it means for you" talk. Nice to see dates listed there and an attempt to get fedora things landed in time for RHEL11.
Next up was the state of the fedora kernel from Justin. Nothing too much that I didn't know, but was good to clarify things and hear questions from folks.
In the next slot I really wanted to go to Kashyap's riscv talk, but unfortunately that was when _my_ talk was scheduled also. ;( So, I gave my talk about scrapers. It was a pretty nice crowd, and there were lots of good questions from people. I did have AV problems however, they were unable to capture from the projector for the live stream, so they could only use the camera to capture it. I have no idea why that was happening. Somehow also, I wasn't able to read my notes while giving the talk, so I missed saying a few things I meant to mention. Things like: "robots.txt was orig called RobotsNotWanted.txt", and asking if anyone remembered the /. effect. ;) Overall I think it went well.
After a bit of hallway conversation, next up with the talk about Microsoft contributions to Fedora. It's great for this work to get highlighted. I am very happy with all the work Jeremy has been doing on our signing infrastructure, along with all the other places they contribute.
I then went to the "Upgrading Fedora Infrastructure from Nagios to Zabbix" talk. This was given by Michal, because Greg was unable to attend. He did a fine job going over things, and Greg was in the matrix room for the talk answering questions. I'm super happy about this finally getting over the finish line (at least the initial one) I think we are in a much better place.
Last day of Mentor summit lunch and learn I sat at the Release Engineering table. We had a mix of folks this time. Some Amazon linux folks, someone asking how to get involved that was just starting out, and someone who was involved in server/docs. We had a pretty wide ranging conversation.
After lunch were the lightning talks. There were a bunch of them, and I was amazed at how many folks had slides. I guess they were ready to talk about their thing at a minutes notice. Lots of interesting stuff in there. Worth a video re-watch.
Finally, the last session of the conference: The Fedora’s Contributor Recognition Program. I won this award last year, and was involved a small amount with choosing winners this year. All the proposed candidates were great! Fedora is nothing without it's contibutors and the folks awarded were all super well deserving folks. Make sure you say 'thanks' to those who help you.
With the conference officially over, I was very tired, so I went to take a nap. Michael Winters was down in the bar, and I said I would try and meet up after I got up. So, after my nap I wandered down and... I swear I saw him walking off to dinner with a group of folks. Missed again. (I'm not avoiding you Michael! Honest!)
I ended up at dinner with a small group and we actually talked non computer nerd things ( music, podcasts, and even politics ).
The next day was the travel home. Due to timezones I would leave the Prague airport at 2pm and get into portland at like 5:30pm. (it is NOT 3.5 hours of flights).
I again had fun with the transfer in iceland. Our plane from Pague was a few minutes late, then we needed to take the bus to the terminal, then passport control was even more backed up than it was last time. I finally got to my gate and their was an attendet there who asked me my name. I then took a bus with only 3 other people on it to the plane. They held it for us, but I made it.
The rest of the trip back was uneventfull, but will take a while to recover. Luckily, there's a holiday this friday so I do have a 3 day weekend.
Overall I think things went super nicely and smoothly, but:
The weird AV issues for my talk. It's likely something off about my aarch64 laptop. So, perhaps I should take a boring x86_64 one next time. Or spend some time poking at it before time for my talk.
There were a lot of folks that I usually look forward to talking with in person that were not able to make it this time. Due to various reasons, but it was sad to not see them. You all know who you are, you were missed.
There were a ton of hallway conversations, and I am sure I don't remember most of them but the few I do:
Alexander showed me a new rust based IDP setup he has been working on. Super cool looking and very on point for Fedora.
There was a number of AI conversations, but more of the 'what do you think is going to happen when the bubble bursts' than anything else. There was a foundations whiteboard where people could add things around the 4 foundations and under friends was "more people, less AI".
Lots of good talks with Amazon Linux and Azure Linux folks. I hope to see them chime in on matrix with questions/comments/contributions.
Jeremy and I had a number of talks about the new signing stuff.
Nice to see Toshio again and talk with him on lots of things.
Had some good talks about 2fa and otp and such with Gotmax23.
A conversation I had a number of times was "where should we do flock next year?". There were a lot of ideas, no telling what will win out. We might not do too badly to just do it in Prague again, IMHO.
As always, comment on the fediverse: https://fosstodon.org/@nirik/116784039502240226
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.
RPMs of PHP version 8.5.8RC1 are available
RPMs of PHP version 8.4.23RC1 are available
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.
ℹ️ Installation: follow the wizard instructions.
ℹ️ Announcements:
Parallel installation of version 8.5 as Software Collection:
yum --enablerepo=remi-test install php85
Parallel installation of version 8.4 as Software Collection:
yum --enablerepo=remi-test install php84
Update of system version 8.5:
dnf module switch-to php:remi-8.5 dnf --enablerepo=remi-modular-test update php\*
Update of system version 8.4:
dnf module switch-to php:remi-8.4 dnf --enablerepo=remi-modular-test update php\*
ℹ️ Notice:
Software Collections (php84, php85)
Base packages (php)
Did your pip install fail with longintrepr.h: No such file or directory? The file likely is on your system, but it sometime or another it was moved, from /usr/include/python3.xx/longintrepr.h to /usr/include/python3.xx/cpython/longintrepr.h. The proper fix is to update the package in question with the new path, but if you’re installing an old version of something or a package that’s no longer maintained you can work around it like this:
ln -s /usr/include/python3.*/cpython/longintrepr.h .venv/include
This post is tough to write because Flock to Fedora is my favorite conference, and last year’s Flock might have been the best conference I’ve ever been to. I love the Fedora community, Prague is beautiful, the venue is nice, we always have so many interesting talks and workshops, the organizers do an amazing job preparing this event for us, so I feel really guilty saying that I did not have much fun this year. That is 100% on me, though. Flock bears no blame.
It wasn’t exactly the wisest decision ever to run my first half-marathon the very evening before the conference, and then waking up early to commute to Prague. It must have hit me much more than I was willing to admit. I feel fine physically, but I can’t pay attention to anything because nothing feels exciting. That is the most lifeless I’ve felt in a long time.
So, in case anyone is wondering … it was me, not you.
Despite all that, these were the highlights of the event for me.
Great job on the migration from pagure.io to forge.fedoraproject.org. It was handled exceptionally well. Next, we look forward to the migration of src.fedoraproject.org to Forgejo, which can’t come soon enough. Tomáš Hrčka teased us that this migration may take considerably less time than the previous one because they already know how to do things (e.g., deploy Forgejo, etc).
Ellis Low showed us how to run an LLM on our laptops through Llama and how to interact with it. I really appreciated him saying that, except for this one small text-in, text-out magic black box, everything else is standard software engineering as we know it.
Most of the discussion revolved around a decline of new contributors and us failing to connect with the next generation. “They talk about changing wallpaper, we talk about burnout” – Aleksandra Fedorova.
I found Pavel Raiskup’s return to the stage hilarious.
As presentations go, Kevin Fenzi’s talk about AI scrapers was the best. It started with minor A/V dificulities, which is a nice reminder to not feel bad, the next time it happens to you, because it happens to everybody. Even the main infra guy. Semi-joking aside, I enjoyed the brief history of web scraping and Kevin’s taxonomy of scrapers, clearly showing that not all scrapers are the same (e.g., web.archive.org). However, the current AI scrapers are the plague of the internet, and I am so glad the Fedora Infra team fights them as best as they can to keep our services running.
I ran into my former Copr team mate Adam Šamalík in the hallway, and we had a nice chat about life. When we still worked together (10 years ago, oh how the time flies), I randomly asked him what he did on a weekend. “We had no plans, so we bought plane tickets and went on a date to Amsterdam with my girlfriend”. Fucking what?! That was the coolest response ever. Since that day, I remember it every time my creaking, lazy bones struggle to do something spontaneous. Why am I telling it now? Adam is now happily living in the Netherlands full-time. Funny how one impromptu decision can completely change your life.
Made friends with Emmanuel Seyman. He said hello after seeing the Fedora Podcast episode with me as a guest. I really enjoyed our chat, and I am going to follow up online because I think he’ll really like Sundaram Krishnan’s project coprtree.
Miro Hrončok shared some of his ideas about improving the Fedora Package Review Process with me. This deserves an article on its own, so stay tuned.
We use gitlab to post internal releases of archives. I want to be able to automate the process of downloading these artifacts. Here it is using the glab CLI.
export REPO=https://gitlab.com/YourCompany/sw-eng/product-manifest
glab auth login --stdin < ~/.token
glab release list -R $REPO
glab release view item/5.4.3.2 -R $REPO
glab release download item/5.4.3.2 -R $REPO --asset-name=sw-eng_5.4.3.2-product-subclass_binary-datestamp.tar.xz
Note that each of these commands can be done with the glab api subcommand instead, but the path needs to be escaped.
export REPO=YourCompany%2Fsw-eng%2Fproduct-manifest
glab api "$REPO/releases"
glab api "$REPO/releases/item%2F5.4.3.2"
This last one gives you the URLs for direct download. You want to save them to a file via redirection.
glab api "https://gitlab.com/api/v4/projects/99999999/packages/generic/sw_release/1.2.3.4/eng_1.2.3.4-product-name-version-version.tar.xz" > eng_1.2.3.4-product-name-version-version.tar.xzSome time has passed since I've tightened TLS settings on my home server. Let's move it a notch higher, this time including home k3s cluster.
In 2026, using elliptic curves cryptography certificates should be the norm. Fortunately, automatically obtaining them is easy. I'm using cert-manager for kubernetes ingresses. Switching to ECC is a just a matter of adding an algorithm annotation on Ingress:
annotations: cert-manager.io/cluster-issuer: "zerossl-production" cert-manager.io/private-key-algorithm: "ECDSA"
and removing the secret containing old cert and key.
Small caveat: FreeIPA still lags. While it supports ACME protocol, ECC through it is not possible, yet. I've left my internal domains with RSA certificates.
For the main server, I refresh certificates using small Ruby script. I had the change RSA.new(3072) to an EC key generation, rest happened automatically:
Last time I've limited support of Transport Layer Security to versions 1.2 and 1.3. Today, let's allow the latest only. I don't care about supporting Windows 7-era clients (years out of support).
Ingress on k3s is handled by Traefik. Simplest way to influence its config is by creating a global (named default) TLS
configuration option:
apiVersion: traefik.io/v1alpha1 kind: TLSOption metadata: name: default namespace: kube-system spec: minVersion: VersionTLS13
That's all!
Change to nginx configuration on the main server is minimal, too. Version 1.2 is removed from the list, leaving only 1.3:
I have to tune Postfix and few other services TLS settings later.
065/100 of #100DaysToOffload
Many GNOME projects have adopted a policy banning all contributions generated by LLMs. This policy was originally developed by Sophie for Loupe, but is now used in many other notable places:
This project does not allow contributions generated by large languages models (LLMs) and chatbots. This ban includes, but is not limited to, tools like ChatGPT, Claude, Copilot, DeepSeek, and Devin AI. We are taking these steps as precaution due to the potential negative influence of AI generated content on quality, as well as likely copyright violations.
This ban of AI generated content applies to all parts of the projects, including, but not limited to, code, documentation, issues, and artworks. An exception applies for purely translating texts for issues and comments to English.
AI tools can be used to answer questions and find information. However, we encourage contributors to avoid them in favor of using existing documentation and our chats and forums. Since AI generated information is frequently misleading or false, we cannot supply support on anything referencing AI output.
I won’t attempt to argue that you should allow use of AI for writing code. If you wish to ban LLM-generated code, fine. That’s probably inadvisable, but I am not going to object.
But this policy is far stricter than that. Notably, it strictly prohibits AI-generated content in issue reports (except to translate text). Don’t do this! Prohibiting bug reports is stupid and just makes your software worse. Please make sure your project’s AI policy allows for at least AI-generated static analysis results and AI-generated vulnerability reports. Otherwise, you prohibit entirely unobjectionable problem reports.
It’s hard to imagine what could possibly be the value of prohibiting valid bug reports. AI-generated static analysis works well: the AI is able to think about your code, follow execution paths, and automatically discard most false positives to avoid bothering you with them, and the quality of reports is generally pretty high. They are far from perfect, but the same is true of humans.
Here is a typical example of an AI-generated static analysis finding:
2. Resource leak in update_credentials_cb on gnutls_credentials_set failure
File: tls/gnutls/gtlsconnection-gnutls.c:169-172
When gnutls_credentials_set() fails, the function returns without calling g_gnutls_certificate_credentials_unref(credentials). The credentials was either freshly allocated or ref-bumped, so it leaks.
Pasting this into an issue report clearly violates the ban on AI-generated content. And yet, why would you not want to receive a clear and concrete bug report for memory leak?
I understand not all maintainers are fond of AI, but is your dislike really so extreme that you would choose to ignore valid problems and intentionally make your software worse? If not, then your AI policy should thoughtfully consider how to handle AI-generated content in issue reports. Certainly do not adopt a policy that outright bans all AI-generated content in issue reports.
As an issue reporter, you could theoretically take the problem found by the AI and rephrase all the words, then claim that it is no longer AI-generated content because it is rewritten. This is a waste of time and usually results in a lower-quality, less-detailed result, but you could plausibly do that. Or, if you want to go above and beyond, you could just jump ahead to creating a merge request. But realistically, if your project does not allow any use of AI in issue reports, it’s more likely that either (a) you won’t receive the issue report in the first place, or (b) you won’t receive such issue reports from experienced developers who read and respect your policy, while users who do not read your policy will continue to submit them.
What about security vulnerability reports? Since the start of this year, I have reviewed well over 100 vulnerability reports that I strongly suspect were generated by AI. To reach the “over 100” claim, I sadly only considered vulnerability reports submitted during a particularly heavy four week period, so this is an extremely loose lower bound. Suffice to say, I have seen a lot of them. The quality varies dramatically. Vulnerability reports are now often better or worse than before: better because an experienced human working with a good AI is able to find vulnerabilities that would have surely gone unnoticed without AI, and worse because an inexperienced human with a bad AI might create some pretty terrible issue reports, a significant proportion of which are just outright spam. Low-quality reports remain a problem, but nowadays most AI-generated issue reports are quite good.
Maintainers do not need to tolerate spammy vulnerability reports. If an issue report is bad, of course go ahead and close it. If it’s really bad, then I sometimes don’t even bother replying. But banning good vulnerability reports solely because some portion of the report was generated by AI is unacceptable. AI-assisted vulnerability reports are the new industry standard, and this is not likely to change. Prohibiting issue reports reduces the quality and safety of your software, punishing your users. This is too extreme.
E.P. Unny is a notable Indian political cartoonist, who worked/works with famed Shankar’s Weekly and new papers such as The Hindu and Indian Express.
Since 2020, all his cartoons (also 2025, 2026 so far) are published — every week — open-access by Sayahna Foundation.
Unny was using a font based on his handwriting style for the cartoons, designed by K.H. Hussain of Rachana. Recently, a new font designed by Varshini KVSS & ‘Kandam Collective’ is developed by Rachana Institute of Typography to use in the cartoons, and it is released as open source — see the specimen and download links.
The character set of the font is Latin only. There are plenty of alternate glyphs (for upper case and lower cases of i, j, l, g, etc. — for instance check the double ‘l’ in ‘Intelligence’ on the specimen above). Such characters are rendered alternately to give a feel of the randomness that handwriting evokes.
The source (and issue tracking) are available at RIT fonts repository.
I have a bunch of different ARM SBCs, some Raspberry Pis, some Rockchip based, and some others. Some of them I have in 1U rack mount cases. Some in cases that I have 3d printed. They have all had a common issue. When something goes wrong, I need to unplug them, move them to my desk, and connect them to my desktop via a USB to tty adaptor. Aside from being inconvenient, it also meant I had to be home to debug what was happening.
I figured there had to be a better way. In the end, I used Claude to help me write a solution. What I came up with is a project to make an ESP32 Web Terminal. Using an ESP32 wired to the UART on the SBCs, I can securely access the serial console of my devices. I have used a couple of different ESP32 devices, from a USD$3 ESP32 C3 Mini to a USD$8 XIAO ESP32S3. all of which work well. For the Raspberry Pis, I purchased some premade JST SH1.0 mm 3 Pin Wire connector cables to plug into the uart port, and for other devices, I made some custom cables with 2.54 mm Dupont crimp pin connectors.

I have most of my SBC’s powered by PoE. In the pictured example, I soldered some headers onto the PCB for the PoE hat to use to provide a 5V power source to the ESP32, and it all runs self-contained in the rack-mount unit. I do want to work on making the connections a little neater and the housing better. But for now, this is functional. While the software on the ESP allows resetting the SBC and controlling the power, I do not currently have that wired up.
As for provisioning the ESPs, I run FreeIPA at home for authentication, and I have dogtag set up as a CA. When I have wired up and flashed a new board, it initially runs as an access point I connect to in order to set up my home network. Once it is connected to my network, I run an Ansible playbook to create and upload SSL certificates signed by my CA and change the admin password. That way, I can connect without any SSL warnings and use a known non-default password to log in. So far, I am quite happy with how they have performed. I still have some things I want to make better, and I also want to finish testing a setup where I connect to an SBC that exposes its serial port over USB. In theory, it should work with ESP32S3, I just need to test.
While it has added quite a few more devices to my network, it is useful to be able to access and debug what is happening without having to move devices and plug them into another computer. I have considered options for externally powering the ESPs and the best ways to connect the ESPs to the SBCs. I would like to at least be more robust with a 3d printed enclosure for the ESP. Each unit has cost me between USD$5 and USD$12, and each has acceptable performance. I have intentionally stuck to using small ESP’s, though it would work well with bigger devices also. Powering each through a shared power source would require additional circuitry to isolate them and prevent voltage leaks.
Another busy week for me. Lots of little things all over the place.
We got everything updated and rebooted and cleaned up any messes from that (at least as far as I know). We did firmware updates on servers this time, and those always cause things to take much longer. Instead of a 'quick' 5m reboot of a server, it's more 20-25m to apply all the firmware updates and reboot a bunch of times. Ah well, it's good to be up to date.
We did have one arm server fail to come up after reboot. ;( It has a memory error, so we are having datacenter folks reseat all the memory (this happened once before and that cleared it up).
I was able to try and move some old long running tickets over the finish line this week:
systemd-boot signing. This is all setup, but needs to be tweaked in the package and tested. Note that this is a self signed cert, but it will still hopefully help folks using systemd-boot.
Looked over a bunch of work from Stephen Gallagher to fix some dist-git repos that have commits that break git fsck. I hope I can finish this up early next week.
Got the drm-panic 'application' deployed. (I just deployed, the change owner did all the heavy lifting).
Setup a pagure-stg-ro01 machine to test a 'readonly' pagure instance.
Got koji upgraded to 1.36.0.
Got all koji builders, hubs and kojipkgs moved to fedora 44
Moved all our proxies to fedora 44
Moved all our compose hosts to fedora 44
Fixed some openshift apps that were still pulling from docker hub (and getting rate limited). I even moved greenwave to using a hummingbird memcached container. Works great!
Flock is coming up fast now. I will be traveling to it starting next thursday. So expect me to be largely offline thursday and friday, and then only sporadically online while I am at flock.
Really looking forward to meeting up with folks and getting that good flock infusion of energy.
As always, comment on the fediverse: https://fosstodon.org/@nirik/116704516544974008
RPMs of PHP version 8.5.7 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.4.22 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
ℹ� These versions are also available as Software Collections in the remi-safe repository.
ℹ� The packages are available for x86_64 and aarch64.
ℹ� There is no security fix this month, so no update for versions 8.2.31 and 8.3.31.
Version announcements:
ℹ� Installation: Use the Configuration Wizard and choose your version and installation mode.
Replacement of default PHP by version 8.5 installation (simplest):
On Enterprise Linux (dnf 4)
dnf module switch-to php:remi-8.5/common
On Fedora (dnf 5)
dnf module reset php dnf module enable php:remi-8.5 dnf update
Parallel installation of version 8.5 as Software Collection
yum install php85
Replacement of default PHP by version 8.4 installation (simplest):
On Enterprise Linux (dnf 4)
dnf module switch-to php:remi-8.4/common
On Fedora (dnf 5)
dnf module reset php dnf module enable php:remi-8.4 dnf update
Parallel installation of version 8.4 as Software Collection
yum install php84
And soon in the official updates:
⚠� To be noticed :
ℹ� Information:
Base packages (php)
Software Collections (php83 / php84 / php85)
Â
Caveat lector
This post discusses tools reluctantly written with AI assistance. If you don’t entertain using them under any circumstance, and think even reading about them legally compromise your ability to reimplement them yourselves, stop reading now
Happy Friday! Of course it’s not Friday anymore in Asia, and if I finish this post in time, it’s still the work day in the Western Hemisphere.
When you work in a large distributed project, it’s not dissimilar to working in a large multinational company - there are too many people to know everyone (or at least not at once!) and you might not know where someone is and if you’re pinging them in the middle of the night.
Dear testers, we're happy to announce Kiwi TCMS version 16.0!
IMPORTANT:
This is a major version release which includes security related updates several improvements, backwards incompatible changes and new translations.
You can explore everything at https://public.tenant.kiwitcms.org!
---
Public container image (x86_64):
pub.kiwitcms.eu/kiwitcms/kiwi latest 3b2c789666ec 867MB
IMPORTANT: version tagged and multi-arch container images are available only to subscribers!
hub.kiwitcms.eu/kiwitcms/version 16.0 (aarch64) d972a78b065c 04 Jun 2026 720MB hub.kiwitcms.eu/kiwitcms/version 16.0 (x86_64) 876f5b848ee7 04 Jun 2026 701MB hub.kiwitcms.eu/kiwitcms/enterprise 16.0-mt (aarch64) 25fc9c88a3b5 05 Jun 2026 925MB hub.kiwitcms.eu/kiwitcms/enterprise 16.0-mt (x86_64) 3a7747c99b65 05 Jun 2026 904MB
IMPORTANT: version tagged, multi-arch and Enterprise container images are available only to subscribers!
Follow the Upgrading instructions from our documentation.
Happy testing!
---
If you like what we're doing and how Kiwi TCMS supports various communities please help us grow!
Software Engineering Radio is a podcast for people in IT/development with over 700 episodes across many topics over 20 years. They haven't touched on the Linux kernel much. I was invited on as part of my role at Red Hat as a Distinguished Engineer, but the podcast is really an insight into kernel maintenance, in graphics and beyond, touching on the scope and scale of the project.
It was my first time to record something that wasn't just me talking at a conference/meetup, and it was all very professional, with sound checks and brainstorming before hand.
The content is at a pretty broad and introductory level. We talked about kernel development processes, maintenance processes, and we touch on rust in the kernel a bit. It's mostly about the sheer size and scale of the project and how Linus releases things, how trees get to Linus and how the GPU work is done.
Hopefully you enjoy listening to it!
[1] https://se-radio.net/2026/06/se-radio-723-dave-airlie-on-linux-kernel-maintenance/
Cockpit is the modern Linux admin interface. We release regularly.
Here are the release notes from cockpit-files 41:
You can now type “Ctrl-S” to save a file in the editor.
Thanks a lot @Leone25 for this contribution!
cockpit-files 41 are available now:
Using a system with 80 AArch64 cores can be a pleasure. Or a pain…
Having 80 cores sounds nice, doesn’t it? But not so much during actual use…
You see, building Fedora packages was flying by. With all cores in use, ccache buffers filling up (in case of rebuilds), and 128 GB of RAM in constant use, etc.
But at the same time, 100% load on all cores means you cannot listen to music on Spotify or watch online videos, etc. All that because the CPU cores are occupied by the build processes.
I tried to use cgroups to limit cpu.max for each fedpkg mockbuild call. It
did not help much: the audio was still jerky.
To compare: I wrote this post on a system powered by a Ryzen 5 3600 CPU while a package build was running in the background. All twelve CPU threads were 100% busy, yet the music did not skip.
All of this shows that cores-heavy CPUs are perhaps not a good choice for a desktop machine. Latencies, the scheduler and context switching — all of this introduces enough noise to make a desktop user suffer.
Arm processors are good in many cases, as long as you do not need pure, single-thread, CPU power.
It is very noticeable in a web browser. For example, Bitwarden unlocks with a noticeable delay, while on a Ryzen 5 3600, it is nearly instant. And it feels even worse when you watch some YouTube videos like “who will make faster PC on a €100 budget”, and then you run the same browser benchmark and get worse results…
Many software builds also highlight this problem. I have a feeling that developers have grown used to a small number of fast CPU cores, which is the norm on the x86-64 architecture, and their code is written to take it for granted.
And then you look at your machine, where 70 cores do nothing, waiting for some code to finally compile or link. I have seen one software package where the bootstrap was composed of TWO source files. Both were over two megabytes in size and full of machine-generated C code. Two cores were kept busy for quite a while, while the other 78 had to wait.
Not much has changed since my the “From the diary of AArch64 porter — parallel builds” blog post from eight years ago.
Of course, there are also packages which will take all cores, whole memory and as much swap as possible, and do magic in nearly no time. When I started build of the PrusaSlicer package, I had to add some swap because Firefox was gone due to OOM. Having less than 2 GB of RAM per CPU core really sucks ;D
To use a desktop system you do not need many cores. As long as they are fast.
Another week has gone by, time for another longer form recap.
Some more rhel10 migrations this last week. This time our memcached instances, our tang servers and a few others. Slowly making progress, but this will get us down to the 'fun' ones: Database servers, virthosts that host important things, etc.
Tuesday was supposed to be the end of life for Fedora 42. For some reason, the date was set to be wed, and then there was some delays due to failed updates composes that pushed it to thursday. It's done however. Fedora 42 was a nice release, it served well. We still have just 3 Fedora 42 instances we need to move and we will do those next week...
I have updated our staging koji ( https://koji.stg.fedoraproject.org ) hub and builders all to Fedora 44 and the latest koji version (1.36.0). We have some non upstreamed patches for our theme, and koji upstream changed from cheeta to jinja2 for it's templates which completely broke that. I was able to use a clanker to rework the patch for jinja2 and then manually fix it from there to work. I'd say it was much quicker, but the process wasn't particularly satisfying. Anyhow, it's done and working as far as I have been able to test in staging.
We are going to apply updates all around and reboot things next week. There is a lot we hope to do on this outage:
rhel 9.8 and 10.2 came out, so we will be updating all rhel servers to those.
we will be upgrading the wiki servers from f42 to f44 (and newer mediawiki)
I hope to do some rhel10 reinstalls while we are in outage
Upgrade prod koji to 1.36.0 and f44 (hubs and builders)
There is a chance DC operations want us to move some servers from one set of racks to another to balance power usage out. Still to be determined if this happens.
So, it should be a busy week
The week after next, flock is already upon us! I hope to be there and able to catch up with old friends and new.
As always, comment on the fediverse: https://fosstodon.org/@nirik/116664633411162579
When reading packets or network data from a tunnel interface, the order in which they are read does matter as they can impact connectionless protocols and also cause stateful protocols to spend time re-ordering data! There were three techniques that I tried implementing to solve this issue:
~
Welcome to another update about everything that’s been happening at the GNOME Foundation. As has become my custom, this post covers a two week period, this time from 18 May until today, 29 May. As usual the Foundation continues to be busy, with events, infra, governance, and accounting activities all happening simultaneously. Read on for more information!
Linux App Summit (LAS) 2026 was held in Berlin over the 16-17 May weekend. I’ve heard quite a few reports now, and everyone seemed extremely positive about the event. Kristi wrote a nice summary if you want more details.
The GNOME Foundation had two team members on the ground helping with running the event, which we co-organize with KDE. I’d like to take this opportunity to give a big thank you to the event’s sponsors: openSUSE, Tuxedo, Nextcould and Codethink. This event wouldn’t be possible without your support.
In addition to LAS, work is continuing on arrangements for GUADEC 2026. The deadline for travel sponsorship applications has now passed, and the Travel Committee has met to decide who will be funded. Notifications will be going out soon.
The process is officially underway for this year’s Board elections. Terms on our Board of Directors are two years in length, and each year half the board seats are open for election. This year we have five seats being contested.
The 2026 election has a slightly different schedule to previous years. In the past, there was no gap between the candidacy period, in which people can announce their intention to run, and the voting period. This meant that there was little opportunity for last-minute candidates to participate in discussion prior to voting taking place.
To address this, we’ve added a one week discussion period to the schedule, which will run between 8 and 15 June, between the candidacy and voting periods. This will hopefully give us opportunity to have more structured and inclusive debate amongst the candidates. We are still figuring out what that might look like, so if people have ideas or want to help, let me know in the comments.
We are currently in the very final stages of confirming and announcing the successful candidates for the inaugural round of the Foundation’s Fellowship program. Expect an announcement very soon.
Last week we introduced a new policy for handling of concerns about the Foundation, which is now part of the project handbook.
The new policy covers how to report concerns about people who are working for the Foundation, either in a paid or voluntary capacity. It also covers more general concerns about the Foundation.
The main goals of the policy are to:
We hope that this policy will make it clear how you can inform us of a concern if you have one. We also want to emphasise that we want to hear concerns, so we can address them. Please do use the new reporting procedure.
Work has continued on the finance and accounting operation over the past two weeks. Highlights include:
Our infrastructure experienced a DDoS attack last weekend, which Bart and Andrea have been dealing with. Thankfully it seems that services weren’t too badly affected, and we’ve already improved our protection against similar attacks in the future.
Also on the infra side, Bart wasn’t at LAS this year, but he did spend some time writing two great posts about Flathub’s internals: How does Flathub even work? and Why are Flathub downloads so slow sometimes?. They’re a fascinating read if you’re interested in Flathub.
That’s it from me! As always, thanks for reading, and see you in two weeks.
It is inspired by icanhazip.com but it returns a little more information as well!
curl icanhazdns.com
~
Please help me start a petition to Apple to bring back smaller sized phones with a pro screen and a flat metal ribbon which wraps the curved glass front and back like a beautiful diamond ring design should be! The iPhone 4S was soo close, all it needed was a full AOD screen with curved corners and edges…
On Fedora:
yum install termdebug
in ~/.vimrc
let g:termdebug_config = {}
let g:termdebug_config['command'] = 'rust-gdb'
packadd! termdebug
Inside vim:
Termdebug target/debug<executable>
Use Ctrl-W DownArrow to switch between windows
Use :Break to set a breakpoint in the code window
Use Ctrl-W UpArrow to go to the gdb window
use run to run the program and cont to continue after hitting a break point.
screen -dm -S up bash -c "do-release-upgrade -d -m server ; sleep 99999"
Bonus Command:
screen -p 0 -S test -X stuff 'echo "test" \n'
~

MasterDnsVPN یک نرمافزار متنباز و پیشرفته برای DNS Tunneling است که با زبان Go توسعه داده شده و با کپسولهسازی ترافیک TCP داخل درخواستها و پاسخهای DNS، امکان عبور از محدودیتها و فیلترینگ شدید اینترنت را فراهم میکند. این پروژه با تمرکز بر پایداری، سرعت و عملکرد در شبکههای دارای Packet Loss بالا طراحی شده […]
The post آموزش نصب و راه اندازی MasterDnsVPN first appeared on طرفداران فدورا.RPMs of Redis version 8.8 are available in the remi-modular repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
Packages are available in the redis:remi-8.8 module stream.
# dnf install https://rpms.remirepo.net/enterprise/remi-release-$(rpm -E %rhel).rpm # dnf module switch-to redis:remi-8.8/common
# dnf install https://rpms.remirepo.net/fedora/remi-release-$(rpm -E %fedora).rpm # dnf module reset redis # dnf module enable redis:remi-8.8 # dnf install redis --allowerasing
You may have to remove the valkey-compat-redis compatibility package.
Some optional modules are also available:
These packages are weak dependencies of Redis, so they are installed by default (if install_weak_deps is not disabled in the dnf configuration).
The modules are automatically loaded after installation and service (re)start.
The modules are not available for Enterprise Linux 8.
redis
redis-bloom
redis-json
redis-timeseries
CVE-2026-46529 is an argument injection vulnerability in Evince, Atril, and Xreader caused by missing shell quoting when composing a command line. The reporter, Jo達o Medeiros, has published a GitHub repo for the CVE and a blog post with the story of how he discovered the flaw and developed the exploit. He also created an Atril security advisory and an Evince issue report.
The vulnerability is fixed in:
If you use one of these PDF readers, update immediately. Or at least please be seriously paranoid about clicking on links in PDFs until you do update.
This vulnerability also affects Papers, but it’s probably not urgent to update Papers. (No, not because it uses Rust. Keep reading!)
The Flatpak sandbox could have drastically reduced the danger of this attack, limiting the compromise to only files that you had previously opened in the PDF reader. Sadly, Evince and Papers both use sandbox holes that render the sandbox totally meaningless. (Atril and Xreader are not available on Flathub.)
When you click on a link in a PDF, Evince may execute itself to display the link. Normally the command line used would look something like this:
/usr/bin/evince --named-dest=/home/foo/hello.pdf
But an evil PDF may trick Evince into executing a command that is quite different than expected:
/usr/bin/evince --named-dest= --gtk-module=/home/foo/evil.so /home/foo/hello.pdf
Oops. The first part of the command is always going to be /usr/bin/evince, but the evil PDF is nevertheless able to unexpectedly load a GTK module into Evince. The fix is to quote the untrusted input using g_shell_quote() to ensure it cannot “break out” of its intended context:
/usr/bin/evince --named-dest='/home/foo/hello.pdf'
Or:
/usr/bin/evince --named-dest=' --gtk-module=/home/foo/evil.so /home/foo/hello.pdf'
Much better: now the threat is neutralized. g_shell_quote() is safe to use even if the untrusted input itself contains quotes. (However, beware: this only works because GLib is parsing the command line itself, and GLib is not a real Unix shell. It’s not safe if the input is going to be passed to an actual Unix shell. It might not even be theoretically possible to do that safely, because it’s valid for filenames to contain entirely arbitrary characters!)
All GTK 3 apps support the --gtk-module command line argument for injecting a shared library into the application. The library may of course then execute whatever code it wants via its library constructor. But GTK 4 no longer has standard GTK command line flags, so this does not work for GTK 4 applications like Papers. It’s still possible to tell a GTK 4 app to load a GTK module, but only via environment variables, not via command line flags, and I don’t see any opportunity for the malicious command to set environment variables. It’s probably not possible to exploit this vulnerability in Papers: although it has the exact same vulnerability as the other PDF readers, the impact is different.
So far this looks like a pretty typical security bug. OK, so if you trick the user into downloading an archive (or perhaps a git repo) that contains both a malicious PDF and also a malicious shared library, then you can trick the PDF reader into loading the shared library and thereby execute arbitrary code. That’s a pretty bad foreseeable exploit, sure, but at least the attacker is at considerable risk of arousing suspicion if the user is trying to download a PDF and also receives a shared library. You’d have to try pretty hard to hide the library in a forest of other boring files if you want the attack to look convincing and unsuspicious. Right?
Nope.
Jo達o used Claude Opus 4.7 to develop a sophisticated script for building malicious polyglot PDFs that are simultaneously both valid PDF files and also valid ELF binaries, so the attacker only needs to trick the victim into downloading one evil PDF file. When the victim clicks on a link in that PDF, the PDF reader will dlopen the PDF itself. The PDF/ELF polyglot’s library constructor will then execute arbitrary code. Much less suspicious, and much scarier. Polyglot files are not entirely novel, but I’d still say this required substantial creativity and expertise from the AI, and substantial persistence from the human. Needless to say, very nice job to both Claude and Jo達o.
You can easily build your own malicious PDF using the provided script and sample GTK module. The script in the Evince and Atril issue reports requires that the attacker predict the absolute path that the malicious PDF file will be saved to; however, Jo達o’s blog post and GitHub repo refine the exploit to remove that requirement.
A human inspecting this code should have been able to find the parameter injection vulnerability, but that requires considerable time and effort, so unsurprisingly nobody did. We’re probably in for a rough time in the short term as the volume of AI-generated vulnerability findings remains temporarily very high and attackers have a much easier time crafting working exploits. But in the long term, I expect we are going to be much more secure than we were before, so this will be worth it.
A human working alone would have almost certainly stopped and moved on after finding the vulnerability. Claude allowed taking the investigation much farther. It’s highly unusual for a GNOME vulnerability report to come with a working exploit. This is a dangerous change. Perhaps it will be a one-time event, but I suspect we will be seeing more frequent exploits in the future.
Silver lining: the exploit helps us better appreciate the severity of the issue. It’s often hard to assess how bad a vulnerability is. If not for the weaponized exploit, I would have thought this bug was not very scary, and would have treated it as not a big deal. We would have fixed it, perhaps or perhaps not with a CVE ID, surely without any blog post or fanfare, and probably without distro security updates. But since there is an exploit, we instead had no doubt that this vulnerability was dangerous, and were able to handle it accordingly.
Several GNOME projects have begun outright prohibiting all AI-generated contributions, including issue reports, with no exception for vulnerability reports. Such policies are misguided and unacceptable. I can sort of understand why some projects might (misguidedly) wish to prohibit AI-generated code contributions. OK, fine. But blocking AI vulnerability reports will make GNOME less safe. AI-assisted vulnerability reporting is the new industry standard for good reason: it is highly effective.
Some humans are not good at preparing AI-assisted vulnerability reports and will spam maintainers with low-quality reports. Sometimes they will be outright bogus, although more often there may be valid underlying bugs with exaggerated severity claims or bad proof of concept demos. This is annoying, but bad issue reports are a cost we are just going to have to accept and deal with.
The quality level of AI vulnerability reports reviewed by conscientious humans — as well as AI assessments of AI vulnerability reports — is now often quite encouraging. But just like humans, AIs may also miss things, especially subtle distinctions that may be highly relevant. Although I�� quite impressed with these AIs, we still need experienced humans to review and manage reports. Please don’t abuse the technology by submitting vulnerability reports that you do not understand or have not validated. And certainly please do not allow an AI agent to interact with an issue tracker on your behalf!
This was my first time scoring a vulnerability using CVSS 4.0 rather than CVSS 3.1. It’s also the first time I wasn’t terribly confused about how to set the parameters, because the scoring guide contained answers to all of my questions. Nice. My CVSS vector for CVE-2026-46529 is CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, the base score is 8.4, and I’m pretty sure my choices for each parameter are good. By comparison, using CVSS 3.1 I came up with CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H and base score 7.8.
Some more great news: I’m pleased to announce that HP has also agreed to be premier sponsor for the Linux Vendor Firmware Service (LVFS) as part of our sustainability effort.
With the industry support from HP (and our existing sponsors of Lenovo, Dell, Framework, OSFF and of course Linux Foundation and Red Hat) we can turbo-charge the growth of the LVFS even more. Thanks!
Files by age, newest first:
ls -lt
Docker images by age, newest first:
docker images --format "{{.CreatedAt}}\t{{.Repository}}:{{.Tag}}" | sort -r
Files by size, largest first:
ls -lS
Docker images by size, largest first:
docker images --format "{{.Size}}\t{{.Repository}}:{{.Tag}}" | sort -rh
Why why why??!
Welcome to another GNOME Foundation update post! Today’s installment covers highlights from what’s happened over the past two weeks.
Linux Apps Summit 2026 starts tomorrow! The organizing team, which includes members from both GNOME and KDE, has been hard at work and is on the ground in Berlin making final preparations. The schedule looks great, and it promises to be a well-attended event.
The talks are being streamed this year, so make sure to watch our social media for details, and tune in live to hear the talks.
Preparations are continuing for July’s GUADEC. The call for Birds of a Feather sessions is currently open. If you want to hold an informal discussion or working session, please fill out the form before 5th June.
Applications are still open for travel funding for GUADEC. The deadline for submissions is 24th May – that’s just over one week.
This week the Board of Directors had its regular meeting for May. A summary:
Our long-running effort to enhance our internal accounting processes has continued over the past two weeks. A notable development has been the retirement of several finance platforms, which have been effectively replaced by the new payments platform that we adopted in January. This platform reduction will reduce operational complexity, as well as workloads. It is still ongoing – we have an additional two more platforms that are currently in the process of being retired.
Another highlight has been the launch of a search for a new member to join our finance and operations team. This is a part-time, contract-based role, which has been shaped in close consultation with Dawn Matlak, who is supporting our finance and accounting operations on a temporary basis, and has already been factored into our budget projections.
We are looking for someone at director level who brings substantial nonprofit finance experience — including audit preparation and compliance experience — which reflects how much the Foundation’s operational and regulatory requirements have grown, particularly in the run up to and following our audit last March, and will provide in-house expertise which will reduce our reliance on external consultants. You can read the full posting here.
Thanks for reading, and see you in two week’s time!
Fedora 44 is out, and in this post we’d like to highlight the top Fedora Quality contributors who helped us reach the finish line. Releasing Fedora is a shared effort, and Fedora wouldn’t be a high-quality distribution without its community. Every single person who helped us detect and resolve issues, or verify that things work as expected, deserves our gratitude, thank you!
If you haven’t participated yet in testing Fedora, perhaps you’d like to give it a try? We gladly welcome everyone. Please look at our Fedora Quality homepage.

Our release validation efforts consist of running lots of test cases on the upcoming Fedora release composes. Here’s an example of a Fedora 44 release candidate. We have lots of tables like these, see Fedora 44 test results. All test cases which are not automated yet (or which are intentionally manual) need to be verified by people.
Test period: Fedora 44 branch time – Fedora 44 Final release
Contributors: 19
Test cases executed: 1380
Unique referenced bugs: 20
| Name | Test cases executed | Referenced bugs1 |
|---|---|---|
| derekenz | 468 | 2365456 2438905 2444046 2448211 2456542 2458714 (6) |
| lruzicka | 132 | 2442593 2442988 2444078 2458907 (4) |
| geraldosimiao | 132 | 2444046 (1) |
| psklenar | 112 | |
| kparal | 106 | |
| nielsenb | 81 | 2442689 2448757 (2) |
| aggraxis | 70 | |
| jlinton | 58 | 2183626 2402621 2444775 2444776 2457333 2457336 (6) |
| robatino | 56 | |
| jcline | 36 | |
| abhis3k | 35 | |
| xariann | 20 | |
| osalbahr | 19 | |
| jgroman | 15 | |
| pboy | 15 | |
| ahmedalmeleh | 9 | |
| korora | 8 | |
| adamwill | 5 | 2448283 2453216 (2) |
| supakeen | 3 |
1 This is a list of bug reports referenced in test cases results. The bug itself may not be created by the same person.

When a new problem is found, we rely on people reporting it. Not every problem can be fixed, but the better data we have, the better we can prioritize and focus on the most important ones. Especially serious bugs can be even proposed as release blockers.
Test period: Fedora 44 branch time – Fedora 44 Beta (2026-02-03 – 2026-03-10)
Contributors: 84
Bug reports submitted: 182
| Name | Bug reports submitted1 | Excess reports2 | Accepted blockers3 |
|---|---|---|---|
| Lukas Ruzicka | 20 | 9 (45%) | 1 |
| Petr Sklenar | 16 | 1 (6%) | 1 |
| Adam Williamson | 9 | 1 (11%) | 2 |
| Steven Hollingsworth | 9 | 0 (0%) | 0 |
| Steve Cossette | 7 | 0 (0%) | 0 |
| Kamil Páral | 6 | 1 (17%) | 0 |
| Mr. Beedell, Jared Richard William | 5 | 0 (0%) | 0 |
| Akira TAGOH | 4 | 1 (25%) | 0 |
| Jeremy Linton | 4 | 1 (25%) | 0 |
| lpavan at redhat.com | 4 | 0 (0%) | 0 |
| Neal Gompa | 4 | 0 (0%) | 0 |
| Adrian Vovk | 3 | 0 (0%) | 0 |
| gav at gavworld.co.uk | 3 | 0 (0%) | 0 |
| Laurențiu Nicola | 3 | 0 (0%) | 0 |
| Matt Fagnani | 3 | 0 (0%) | 0 |
| Osama Albahrani | 3 | 0 (0%) | 0 |
| Than Ngo | 3 | 0 (0%) | 0 |
| …and also 67 other reporters who created less than 3 reports each, but 76 reports combined! | |||
Test period: Fedora 44 Beta – Fedora 44 Final release (2026-03-10 – 2026-04-28)
Contributors: 252
Bug reports submitted: 426
| Name | Bug reports submitted1 | Excess reports2 | Accepted blockers3 |
|---|---|---|---|
| Davide Repetto | 18 | 1 (6%) | 0 |
| Petr Sklenar | 18 | 2 (11%) | 0 |
| Fabio Valentini | 12 | 0 (0%) | 0 |
| Kamil Páral | 11 | 5 (45%) | 1 |
| Adam Williamson | 10 | 0 (0%) | 3 |
| Ricardo Ramos | 7 | 0 (0%) | 0 |
| Lukas Ruzicka | 6 | 1 (17%) | 1 |
| Matt Fagnani | 6 | 0 (0%) | 0 |
| Calum Chisholm | 5 | 0 (0%) | 0 |
| lray+redhatbugzilla at mailbox.org | 5 | 0 (0%) | 0 |
| Andrey Motoshkov | 4 | 0 (0%) | 0 |
| Artem S. Tashkinov | 4 | 1 (25%) | 0 |
| Brian Morrison | 4 | 0 (0%) | 0 |
| Chang Qian | 4 | 0 (0%) | 0 |
| Derek Enz | 4 | 2 (50%) | 0 |
| Dominic | 4 | 0 (0%) | 0 |
| iltis at posteo.de | 4 | 0 (0%) | 0 |
| Jan Macku | 4 | 0 (0%) | 0 |
| Jeremy Nickurak | 4 | 0 (0%) | 0 |
| kxra at riseup.net | 4 | 0 (0%) | 0 |
| Luke | 4 | 0 (0%) | 0 |
| Mr. Beedell, Jared Richard William | 4 | 0 (0%) | 0 |
| Steven Hollingsworth | 4 | 0 (0%) | 0 |
| tk2345_ at outlook.com | 3 | 0 (0%) | 1 |
| Alan Altmann | 3 | 1 (33%) | 0 |
| anotheruser | 3 | 0 (0%) | 0 |
| Cristian Ciupitu | 3 | 0 (0%) | 0 |
| Eugene Mah | 3 | 0 (0%) | 0 |
| Jonathan S. | 3 | 0 (0%) | 0 |
| speedlemma at gmail.com | 3 | 2 (67%) | 0 |
| Steve Cossette | 3 | 0 (0%) | 0 |
| …and also 221 other reporters who created less than 3 reports each, but 252 reports combined! | |||
1 The total number of new bug reports (including “excess reports”). Reopened reports or reports with a changed version are not included, because it was not technically easy to retrieve those. This is one of the reasons why you shouldn’t take the numbers too seriously, but just as interesting and fun data.
2 Excess reports are those that were closed as NOTABUG, WONTFIX, WORKSFORME, CANTFIX or INSUFFICIENT_DATA. Excess reports are not necessarily a bad thing, but they make for interesting statistics. Close manual inspection is required to separate valuable excess reports from those which are less valuable.
3 This only includes reports that were created by that particular user and accepted as blockers afterwards. The user might have proposed other people’s reports as blockers, but this is not reflected in this number.

When software packages are updated in Fedora (bringing bug fixes and new features), they are not released to end users immediately. They first go to the updates-testing repository, where they undergo automated testing, and also await manual feedback from human testers. This feedback can be provided through Bodhi, either by using its web interface or CLI tools, see instructions. Alerting package maintainers by posting a negative feedback with a problem description can stop the update from reaching general audience and causing issues to all our users. Testing proposed updates is a simple, yet vital process for keeping Fedora releases of high quality during their whole lifecycle. It is used both for already stable and in-development Fedora releases.
Test period: Fedora 44 branch time – Fedora 44 Final release (2026-02-03 – 2026-04-28)
Contributors: 147
Updates commented1: 1428
| Name | Updates commented |
|---|---|
| Geraldo S. Simião Kutz (geraldosimiao) | 307 |
| Filipe Rosset (filiperosset) | 185 |
| Eugene Mah (imabug) | 98 |
| Derek Enz (derekenz) | 88 |
| anotheruser | 78 |
| bojan | 71 |
| Ian Laurie (nixuser) | 66 |
| Kamil Páral (kparal) | 37 |
| Neal Gompa (ngompa) | 35 |
| Fabio Valentini (decathorpe) | 33 |
| František Zatloukal (frantisekz) | 31 |
| Xariann Cat (xariann) | 25 |
| ramot | 24 |
| Cristian Ciupitu (ciupicri) | 23 |
| Ankur Sinha (ankursinha) | 20 |
| Adam Williamson (adamwill) | 17 |
| Alex Gurenko (agurenko) | 15 |
| Benjamin Beasley (music) | 14 |
| Lukáš Růži�ka (lruzicka) | 11 |
| Simon de Vlieger (supakeen) | 9 |
| Michel Lind (salimma) | 9 |
| brett h (bretth) | 9 |
| Dennis Gilmore (ausil) | 8 |
| Paul Whalen (pwhalen) | 7 |
| Wasser Mai (wasser19641) | 7 |
| Peter Robinson (pbrobinson) | 7 |
| Lukas Slebodnik (lslebodn) | 7 |
| Colin Thomson (g6avk) | 6 |
| Juha Uotila (inffy) | 6 |
| Steve Cossette (farchord) | 5 |
| markec | 5 |
| …and also 116 other testers who commented on less than 5 updates each, but 165 comments combined! | |
1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is not taken into account.

Test Days are events which are partly focused on testing Changes planned for an upcoming Fedora release, but they also regularly test important areas of the Fedora distribution, like upgrades, internationalization, graphical drivers, desktop environments, kernel updates, and others. The upcoming and past events can be seen in our Testdays app.
Test period: Fedora 44 branch time – Fedora 44 Final release
Contributors: 98
Test cases executed: 698
| Name | Test cases executed |
|---|---|
| lpavan | 42 |
| mcrha | 36 |
| adriend | 34 |
| tagoh | 27 |
| pnemade | 23 |
| 16levels | 23 |
| lruzicka | 17 |
| stransky | 16 |
| michal odehnal | 16 |
| pschindl | 15 |
| jgrulich | 15 |
| alciregi | 15 |
| psklenar | 12 |
| dkricka | 12 |
| jpb21 | 12 |
| romangherta | 12 |
| royboy626 | 11 |
| twinkle28 | 11 |
| vhumpa | 11 |
| alangm1001 | 11 |
| pyadav | 10 |
| rduda | 10 |
| paolojr | 10 |
| dtunma | 10 |
| bittin | 9 |
| pauloheaven | 9 |
| jgroman | 8 |
| derekenz | 8 |
| gornikfan | 8 |
| tdawson | 8 |
| vsembiba | 8 |
| mkasik | 8 |
| clnetbox | 8 |
| mzink | 8 |
…and also 64 other testers who executed less than 8 updates each
We sincerely thank all contributors!
Are you also interested to help? Please look at our Fedora Quality homepage.
This is a follow-up to the previous article.
I find it so funny that I estimated the test deployment at 3 story points; at this point I’m at like 40 with the amount of work I put into this.
But thanks to Claude it’s pretty fast to diagnose and solve problems.
This time I even let it run oc commands, even oc rsh, but I never allowed commands that would change things or write to remote services. Everything stayed local.
Here comes Claude’s writeup.
Yelp 49.1 fixes a significant Flatpak sandbox escape related to last year’s CVE-2025-3155. CVE assignment for this new issue is currently pending. June 29, 2026 update: better late than never, we have received CVE-2026-13601.
This is not a bug in Flatpak. Flatpak allows sandboxed applications to open URIs or files, meaning the sandboxed application may use a URI or file path to launch another application to open the URI or file. This is brokered via the OpenURI portal. The portal or the app may decide to require user interaction to decide which app to launch, but user interaction is generally not required. This is necessary: you would get pretty frustrated if you were prompted to select which app to use every time you click on a link or try to open something! Accordingly, unsandboxed applications that are installed on the host system are somewhat risky: any malicious sandboxed app may launch an unsandboxed app using a malicious file, generally with no user interaction required. Unsandboxed applications installed on the host OS are inherently part of the attack surface of the Flatpak sandbox.
In this case, a sandboxed application may launch Yelp to open a malicious help file. The help file can then exfiltrate arbitrary files from your host OS to a web server by using a CSS stylesheet embedded in an SVG. Suffice to say the attack is pretty clever, and certainly more impactful than the typical boring memory safety bugs I more commonly see.
This bug was discovered by Codean Labs, which performed a security audit of Flatpak and several GNOME projects thanks to generous sponsorship by the Sovereign Tech Resilience program of Germany’s Sovereign Tech Agency.