The second quarter of 2026 is over, and so in this post we’d like to highlight the top Fedora Quality contributors who helped us maintain the quality bar for Fedora during this time period. 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.

Testing proposed updates

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: Q2 2026 (2026-04-01 – 2026-06-30)
Contributors: 408
Updates commented¹: 5103

¹ 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 participation

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: Q2 2026 (2026-04-01 – 2026-06-30)
Contributors: 25
Test cases executed: 76

We sincerely thank all contributors!

Are you also interested to help? Please look at our Fedora Quality homepage.

I work at Red Hat in the Python Maintenance team mostly taking care of the Python ecosystem in Fedora. For the past year or so, I’ve been motivated by my employer to use agentic AI to deliver my work. Clearly, we are not the only ones.

At the beginning, I struggled to find reasonable use cases for this tool. I maintain software, which involves a lot more communication and coordination than actually writing code. When people ask me what I do, I often half-jokingly reply that I read and write a lot of emails. How can AI boost my productivity when I spend 80% of my time essentially talking to people? Where is the fun in replacing the remaining 20% of actually crafting code with more talking, this time to half-competent robots?

In time, I found ways to use AI that felt productive. And, ever so hypocritically, not only at work. But at what cost? I am supporting an industry that regularly harms open source projects such as Fedora, helps destroy the planet and uses stolen data. Moreover, I’ve become reliant on a proprietary tool. Is my AI-boosted contribution to Fedora worth it?

Despite my moral dilemma, I still love my job. I am a long-standing, well-known Fedora contributor, working for the most part on whatever I feel is needed, earning a competitive salary. In theory, I could go look for another job where I would not be motivated to do this, but I wouldn’t be able to keep doing the thing I love. I try to make the best out of this situation and, despite my initial distaste, use the tool to improve the project. So at the end of the day, I close my eyes and think of Fedora¹.

However, the implications of embracing AI are not just impacting me. The nature of my work means I’ve made hundreds (thousands?) of small open source contributions here and there. And sometimes, when I use AI to deliver those, it kinda feels like bringing a chunk of meat to a vegan BBQ. The people on the receiving end of my contribution for the most part don’t care about my job sustainability or IBM shareholders, nor should they.

Once, I used AI to contribute to a Fedora packaging project. It was reluctantly reviewed by another long-standing, well-known Fedora contributor (who happens not to be employed by Red Hat and is not well-compensated for this work). When talking to them, I realized that they were uncomfortable reviewing such a change. I made them uncomfortable by choosing to use AI for this. My employer made me uncomfortable; I passed it on to a volunteer. What an outstanding open source citizen.

I appreciate the irony of this; and yet, I am no slop generator. I understand what I submit and I put my name on it. I disclose the usage for transparency, because it matters. I don’t just drop a vibecoded patch on an open source project. If you have an AI policy, I read it and respect it. So it pains me deeply when our carefully considered contributions are outright branded AI slop or LLM hallucinations, and the person bringing them is evaluated solely on the basis of the tool they used. Especially when such judgment is made by people I respect².

No, I am not a tool. Please don’t treat me as such.

PS On a lighter note, here are some examples of AI usage that somehow eliminate this problem for me:

• Debugging a problem — in our team we’ve been very successful in showing a failing test to Claude and telling it that it started failing with Python 3.15. While burning thousands of tokens and wasting gallons of drinking water it can usually successfully determine what caused the failure. We were able to determine this ourselves in the past, but this actually boosted our productivity. We can then report the problem to upstream after we have verified the find.
• My own/my team’s semi-internal tooling —³ the omnipresent bunch of random scripts I am not proud of and which would desperately need a rewrite but ain’t nobody got time for that. Just slop ‘em. If it works, it works. If it doesn’t, roll-back. Nobody needs to see this code anyway. Excellent for AI — I am still kinda killing the planet but at least I don’t shove it in your face.
• Reporting to management — somehow people keep asking me what I did. There’s no dilemma in providing AI-generated reports to the same people who asked me to use AI. If nothing else, it demonstrates how progressive I am with it.
• Reviews for me — when I don’t use AI to generate code, but rather ask it to review my design and implementation, nobody is forced to deal with my AI usage. For example, I wrote this blogpost myself, then asked AI for feedback on typos, grammar, tone, voice, argument, rhetoric, structure, flow…⁴

"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.

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

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

• Planned Outage – download-ib01, torrent, people outage – 2026-06-25 20:00 UTC
• Planned Outage – server moves – 2026-06-25 14:00 UTC
• RFE: Add a role for deploying through OpenShift deployment
• rhel10: colo_virt virthosts
• Migrate ELNBuildSync to Fedora Infrastructure OpenShift

CentOS Infra including CentOS CI

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

• Deploy staging el10 signing host for Stream to validate worfklow
• Rebuild all needed pkgs for el10 signing service
• all s390 builders for Stream are unreachable (blocking all rpm build tasks)
• abuse on website
• Init new donated/sponsored server for CentOS infra
• Update Firmware in Risc-V P550’s
• mirror.dsp-lad.space add to mirror list
• Automotive SIG – key rotation
• Change AltImage documentation to use gitlab.com repo
• Update boot-server ansible role for el10
• Renew our yearly RH subscription for CDN access
• migrate status.centos.org to el10

Release Engineering

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

• Continued investigation into building a Fedora container base image using Konflux.
• Continued work on remaining Pagure -> Forgejo migrations.
• F45 release cycle is set to begin soon, starting with Mass Rebuild in the middle of July. This will require some prep work next week.

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

• Discussion with Scaleway (a cloud vendor in France) for potential Fedora Koji builders in their Paris datacenter.  To be coordinated via RISE.
• Hardware
  • Coordinated shipping another “K3” hardware to DavidA (one of the Fedora RISC-V maintainers). This will be used as another RISC-V Koji builder.  Sponsored by CLE.
  • Milk-V Titan hardware is now available to buy.  A handful of machines are being shipped to a couple of  RISC-V engineers, including for Fedora use.
• Community work
  • Fedora Omni kernels for Muse Pi Pro hardware discussion with Trevor from Baylibre and Jason (Fedora RISC-V kernel)
  • Marcin (hrw) Juszkiewicz continues to chip away at the Fedora RISC-V tracker
  • Fedora Omni kernel work continues, with support for Muse Pi Pro, K3, and more: Jason Montleon and Jennifer Berringer
• Other:
  • Discussions on ‘fedora-devel’: “How can we improve the Changes Process?” thread
  • A lot of internal discussion about 2FA for packagers
  • Several internal  and upstreams meetings

AI

This is the summary of the work done regarding AI in Fedora.

• Aurelien Bompard improved the This Week in Fedora script to include the CLE status reports

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

• Lots of PTO: psklenar on extended PTO, kparal and adamwill each took some post-travel PTO days. Also post-event travel, bureaucracy (trip and expense reports) and decompression cut into work time for most
• Compose-critical package script now in MVP state – see pull request, it works and does useful stuff but needs more refinement
• Dist-git PR test feature progress: status report now works, still needs polish and tests
• Tool work: CI optimization in blockerbugs, reverse proxy handling improvement in testdays-web
• Significant bug investigations: grub2 changes broke image builds, haveged update could cause boot failure

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

• Forge 15.0.3 in staging
• New runner for koji organization
• Continued work on Private Issues: public/private comments
• Zabbix template developed to monitor health of runnerhost VM, moving onto the  forge instance next.

EPEL

This team is working on keeping Epel running and helping package things.

• Updated caddy in f44, f43, epel10.3, and epel10.2 resolving 22 CVEs
• EPEL 11 planning discussions

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

• Open Call for Fedora Event Video Footage! [discussions post]
• Feedback period for F45 wallpaper has just ended. Here is the current iteration.

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.

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.

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.

Background

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.

Migration steps

Shrink the system partition on the source system

On the source system:

1. Delete all necessary data, prune cash dirs, empty the trash, etc.
2. Boot to a Fedora Workstation Live system from a USB drive.
3. Install necessary tools: sudo dnf install gparted pv
4. Run Gparted. In it, unlock the system partition, if encrypted. Then shrink the partition to a reasonable degree. For example, if the partition has 950 GB (from a 1 TB disk), but only 300 GB is used, you can shrink it e.g. to 350 GB. That still leaves enough free space for regular usage if you had to boot it for any reason, and saves 600 GB from being copied needlessly. This operation might take some time, because any data blocks currently present after the new size limit will need to be moved (therefore don’t be too aggressive in setting the limit). If your partition was encrypted, make sure that both the LUKS encryption container and the filesystem inside it correctly show up as resized.
5. Unmount all partitions (if any), lock the encrypted partition (if applicable) and close GParted.

Erase the target system

On the target system:

1. Ensure that this is really the system you want to completely erase (and replace with the OS from the source system).
2. Ensure that the disk size is sufficient to fit all partitions from the source system (now that the system partition on the source system has been shrunk).
3. Boot to a Fedora Workstation Live system from a USB drive.
4. Install necessary tools: sudo dnf install sfdisk sgdisk
5. Unmount all partitions (if any). You can use e.g. GNOME Disks for this.
6. Erase the whole drive (make sure you’re using the correct system): sudo wipefs -a /dev/nvme0n1
7. Discard all blocks on your drive (better for your SSD longevity): sudo blkdiscard -v /dev/nvme0n1

Establish an Ethernet/Thunderbolt network link

If 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.

Thunderbolt setup

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.

1. On both laptops, after connecting them through a Thunderbolt cable, locate the network interface name: ip link
   Look for an interface like thunderbolt0.
2. Assign static IP addresses to them:

• Source system:
  bash sudo ip addr add 192.168.5.1/24 dev <interface_name>
sudo ip link set <interface_name> up
• Target system:
  bash sudo ip addr add 192.168.5.2/24 dev <interface_name>
sudo ip link set <interface_name> up

Connectivity test

1. Let’s use a well-named variable for both numbers, so that we don’t mix them up later. On both systems, run:

   export SOURCE_IP=192.168.5.1
   export TARGET_IP=192.168.5.2

2. Test connectivity between your systems.

• From the source system: ping $TARGET_IP
• From the target system: ping $SOURCE_IP
  
  You should see both systems pinging the other system correctly.

Replicate partition table from source to target

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.

1. On target system, start listening for data and save it:

   nc -l -p 2000 > table.txt

2. On source system, dump the partition table and send it over:

   sudo sfdisk --dump /dev/nvme0n1 | nc $TARGET_IP 2000

3. On target system, apply the partition layout to the disk:

   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

Copy all partitions

Everything should be ready now to transfer all partitions data.

1. Clone the ESP partition (p1):

• On target system, listen and write the data:

   nc -l -p 2000 | sudo dd of=/dev/nvme0n1p1 bs=4M

• On source system, send the data:

   sudo dd if=/dev/nvme0n1p1 bs=4M | pv | nc $TARGET_IP 2000

2. Clone the Boot partition (p2):

• On target system, listen and write the data:

   nc -l -p 2000 | sudo dd of=/dev/nvme0n1p2 bs=4M

• On source system, send the data:

   sudo dd if=/dev/nvme0n1p2 bs=4M | pv | nc $TARGET_IP 2000

3. Clone the System partition (p3):

• On target system, listen and write the data:

   nc -l -p 2000 | sudo dd of=/dev/nvme0n1p3 bs=4M

• On source system, send the data:

   sudo dd if=/dev/nvme0n1p3 bs=4M | pv | nc $TARGET_IP 2000

Expand the System partition on the target system

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:

1. Install GParted on the target system: sudo dnf install gparted
2. In Gparted, unlock the system partition, if encrypted. Then enlarge it according to your preferences. If your partition was encrypted, make sure that both the LUKS encryption container and the filesystem inside it correctly show up as resized.

Reboot the target system

You 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.

Boot problems

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

Mentions of other cloning approaches

1. Using dd
   This works fine when cloning to a larger disk (if you fix the partition table afterwards), but unused blocks are written needlessly (wearing down SSD), and migrating to a smaller drive is problematic.
2. Native Btrfs streams using btrfs send and btrfs receive
   This perfectly copies only used blocks of the main partition, but it only submits a single subvolume. Which means there’s some extra work needed to make sure exactly the same subvolumes are replicated from source to target. Also, this works above the LUKS encryption, which also needs to be created manually on the target (while keeping IDs, etc).
3. Using Clonezilla
   Clonezilla will copy LUKS partitions as raw data, because it can’t see inside. Furthermore, it doesn’t support cloning to a smaller drive by default (there are some tweaks in Expert Mode, but you need to repair the GPT backup table manually anyway).
4. Sparse-copying the whole disk
   You can clone and restore the whole disk image with sparse blocks support, as seen in this guide. With a little tweaking, this approach could potentially be used even for my use case. One would need to make sure all the unallocated blocks are freed and really contain zeroes (which means running fstrim or blkdiscard and testing if it zeroed it out), and the partitions would need to be shrunk first in case of migrating to a smaller drive. The GPT backup header would need to be fixed (the same way as in the main article). So this might be a viable alternative approach for those who know how to tweak the steps.

After about eleven months of using an AArch64 desktop, I decided to end that experiment.

Hardware used

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:

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.

The first issue

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.

So many cores, not enough speed

As I wrote in my previous post, having eighty CPU cores does not mean that the system is a good, fast desktop machine.

AMD GPU started failing

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…

Let’s get Nvidia

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.

Powering up the old x86-64…

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.

Conclusion

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

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 2026

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.

Devconf.cz 2026

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 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.

Teamwork makes the dream work

This year’s edition was the result of combined efforts of three PoznaÅ„-based organizations:

• Knyfyrtel Hackerspace PoznaÅ„
• “Webrains” Students’ Scientific Association at the Adam Mickiewicz University
• “Linux Academic Group” Students’ Scientific Association at the PoznaÅ„ University of Technology

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.

Busy, busy day

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:

• Zbyszek JÄ™drzejewski-Szmek, who gave 2 (!) talks
• Mat Holmes, who volunteered as a photographer
• Kacper SkrzyÅ„ski, who handled various urgent tasks
• Artur Frenszek-Iwicki, who gave a talk and held a workshop session

Historical moment: creation of SPOIWO

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.

Exceeding all expectations

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!

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

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!!)

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.

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.

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

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

export REPO=YourCompany%2Fsw-eng%2Fproduct-manifest
glab api "$REPO/releases"
glab api "$REPO/releases/item%2F5.4.3.2"

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.xz

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.

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!

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/ 

Using a system with 80 AArch64 cores can be a pleasure. Or a pain…

Multicore heaven?

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.

The lack of single-thread speed

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

Summary

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.

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:

• Map a packet address to a thread index during the entire time of every connection state
• Index and order every packet read by number and wait to write them out in the same sequence
• Lock and time and order each threaded process just like many pistons firing inside of an engine block

~

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!

Events

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.

Board Elections

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.

GNOME Fellowship

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.

Got a Concern?

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:

• have a documented reporting procedure for those who have concerns relating to the Foundation
• clarify how concerns will be responded to
• provide reassurance for those reporting concerns, including that concern reports are welcome, are taken seriously, and will never result in retaliation

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.

Finance/Accounting

Work has continued on the finance and accounting operation over the past two weeks. Highlights include:

• Our transition to a monthly rather than quarterly close reached a significant milestone this week, with the completion of our April finance reports within three weeks of the previous month end. This is probably the fastest ever turnaround for our finance operation, and is a huge win for us in being able to effectively manage our finances.
• Following input from the board, corrections have now been sent to the accountants for our audit and annual tax filing.
• Applications are still open for our Director of Finance and Operations part-time contract. Candidates have until 4 June to submit.
• Finally, as I mentioned in my last update, we are in the process of retiring a number of finance platforms as we consolidate and streamline our operation. This week saw another platform retired, which brings the total number of eliminated platforms to four.

Infrastructure

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.

https://fossjon.com

https://xorcipher.com

https://icanhazdns.com

~

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'

~

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:

• Evince 48.4 (fix commit) (I originally reported that it is fixed in 48.2, but there was no successful release for that tag)
• Atril 1.28.4 and 1.26.3 (fix commit)
• Xreader 4.6.4 and 3.6.7 (fix commit)

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.)

The Vulnerability

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.

The Exploit

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.

Thoughts on AI Vulnerability Reports

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!

For Security Geeks

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??!