fidzu : Fedora

Another week has gone by and so time for another bit of round up and longer form information about the last week for me in Fedora infra.

09 May 2026 5:30pm GMT

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: 4 - 8 May 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

• OpenShift Allowing Project Creating Despite Missing Relevant Permissions
• mirrormanager app no longer builds
• Monitoring of Varnish in Zabbix
• Decomission Ipsilon OpenID instance
• Copyfail: updated and rebooted key Fedora hosts, applied kernel team recommended mitigation on key EL 9 hosts

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

• Upgrade CS Koji to version 1.36
• stream9 and stream10 BuildTargets and Tags needed for nfs-ganesha-10
• isa riscv import package or add external repo again
• migrate docs.infra.centos.org to el10
• Server error on CentOS login
• Migrate ocp head instances to el10
• Create an "ansible-init" tool or container

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

• Post-release cleanup.

RISC-V

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

• OpenJDK CVE updates Wrote up initial analysis. Created an F44 branch with three small RISC-V patches on the secondary dist-git. Kicked off a boot JDK build.
• Flock prep: Started writing up notes about the updates for our talk on RISC-V. If logistics work out, we may bring a board or two for a demo.
• Explore shipping some upcoming RVA23 hardware ("SpacemiT K3") for JasonM and DavidA for Koji builders. Figure out approximate costs for it.
• Continued with LLVM's 'libomp' test failures investigation; it's a slow grind.
• Caught up with Adam Williamson's nice talk on lessons from root cause analysis.

AI

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

• The prototype AI Developer Desktop has been rebased to Fedora 44, and the associated Remix kernel with NVIDIA OpenRM has been rebased to 6.18.

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.

• Fedora QE Pagure -> Forge migration is now fully complete. The new version of Blockerbugs (that uses Forge instead of Pagure for blocker discussion tickets) is now deployed to production.
• Caught an issue with kernel module signing in ELN
• Ongoing openQA test development work
• Kernel test week testing
• Starting work on reviving the contribution statistics scripts and communications
• Some communications around copyfail, reassuring folks that it was addressed day 0 in Fedora

Forgejo

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

• Runnerhost zabbix agent updated with encryption
• Forge v15 running on staging instance
• Privileged and unprivileged aarch64 runners tested on staging, requested larger VM
• Runnerhost VM's kernel version updated to 6.19.14 to counter the CVE
• Handful of new orgs added

EPEL

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

• prep work for EPEL presentations and booth work at Summit
• routine packaging and documentation work

UX

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

• Finished Bootc Sealed Images logo [ticket]
• Flock t-shirt design finalised and handed over
• Had our first Backlog Refinement call ahead of our next sprint

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 19 2026 appeared first on Fedora Community Blog.

08 May 2026 10:00am GMT

08 May 2026 8:00am GMT

RPMs of PHP version 8.5.6 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.4.21 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.3.31 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.2.31 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.

🛡️ These Versions fix 8 to 13 security bugs (CVE-2026-6735, CVE-2026-7259, CVE-2025-14179, CVE-2026-6722, CVE-2026-7261, CVE-2026-7262, CVE-2026-7568, CVE-2026-7258, CVE-2026-6104, CVE-2026-42371, CVE-2026-7263, CVE-2026-29078, CVE-2026-29079), so the update is strongly recommended.

Version announcements:

• PHP 8.5.6 Release Annoucement
• PHP 8.4.21 Release Annoucement
• PHP 8.3.31 Release Annoucement
• PHP 8.2.31 Release Annoucement

ℹ️ 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:

• Fedora Rawhide now has PHP version 8.5.6
• Fedora 44 - PHP 8.5.6
• Fedora 43 - PHP 8.4.21
• Fedora 42 - PHP 8.4.21

⚠️ To be noticed :

• EL-10 RPMs are built using RHEL-10.1
• EL-9 RPMs are built using RHEL-9.7
• EL-8 RPMs are built using RHEL-8.10
• intl extension now uses libicu74 (version 74.2)
• mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
• oci8 extension now uses the RPM of Oracle Instant Client version 23.26 on x86_64 and aarch64
• A lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page

ℹ️ Information:

• Migrating from PHP 8.2.x to PHP 8.3.x
• Migrating from PHP 8.3.x to PHP 8.4.x
• Migrating from PHP 8.4.x to PHP 8.5.x

Base packages (php)

Software Collections (php83 / php84 / php85)

08 May 2026 5:52am GMT

08 May 2026 2:54am GMT

07 May 2026 10:00pm GMT

The Rebuild Algorithm

Slow and Steady Wins the Race

The Fedora ELN SIG maintains a tool called ELNBuildSync (or EBS) which is responsible for monitoring traffic on the Fedora Messaging Bus and listening for Koji tagging events. When a package is tagged into Rawhide (meaning it has passed Fedora QA Gating and is headed to the official repositories), EBS checks whether it's on the list of packages targeted for Fedora ELN or ELN Extras and enqueues it for the next batch of builds.

A batch begins when there are one or more enqueued builds and at least sixty wallclock seconds have passed since a build has been enqueued. This allows EBS to capture events such as a complete side-tag being merged into Rawhide at once; it will always rebuild those together in a batch. Once a batch begins, EBS stops accepting messages from the Fedora Messaging Bus. The messages remain enqueued and awaiting processing. When the current batch is complete, EBS will resume accepting messages and a new batch will begin.

The first thing that is done when processing a batch is to create a new side-tag derived from the ELN buildroot. Into the new target associated with this side-tag (which will be referred to as the "build tag" from now on), EBS will tag most¹ of the Rawhide builds. It will then wait until Koji has regenerated the buildroot for the batch tag before triggering the rebuild of the batched packages. This strategy avoids most of the ordering issues (particularly bootstrap loops) inherent in rebuilding a side-tag, because we can rely on the Rawhide builds having already succeeded.

Once the preparations are complete, we divide the batch up into one or more "batch slices". The EBS configuration file contains information about certain packages that must be built and added to the buildroot before or after other packages. (Most packages will be part of the same primary slice, but some packages must be built early, such as llvm). EBS triggers all of the builds for a batch slice in the side-tag concurrently, sourcing the content from the git commit that was used to build the triggering Rawhide build. This is to ensure we are building the same content, in case dist-git has received subsequent changes. EBS monitors these builds for completion. Internally, we call these "rebuild attempts".

Once all of the tasks in a rebuild attempt have completed (successfully or not), EBS will trigger another rebuild attempt of the failures. While a heavyweight solution, this helps us avoid failures due to infrastructure outages, flaky tests and bootstrapping issues not covered by the Rawhide build tagging. Rebuild attempts will continue to be initiated until the same number of failures occurs twice in a row. At that point, we assume they are legitimate build issues and we continue on.

Once all of the rebuild attempts have concluded, EBS moves on to the next slice in order until they have all completed, at which point, the next phase of operation begins: errata creation.

In earlier versions of ELNBuildSync, EBS would now tag all successful builds into the eln-updates-candidate tag and then remove the build tag. The effect of this would be to trigger Bodhi to generate an erratum for each individual package in the batch.

In modern versions of ELNBuildSync, it will now create a second² side-tag (call it the "errata tag"). EBS then tags all of the successful package builds from the batch into this new errata tag. This ensures that the tag contains only the new ELN builds and none of the Rawhide packages that were tagged into the build tag. From there, EBS talks to Bodhi via its public API and requests that a single Bodhi update erratum be created for all of the packages in this errata tag. This is done to reduce the load on Fedora QA, as the infrastructure there is far better equipped to deal with a single update of a few hundred packages than it is with a few hundred separate updates.

At this point, the batch is complete and EBS moves on to preparing another batch, if there are packages waiting.

History

In its first incarnation, ELNBuildSync (at the time known as DistroBuildSync) was very simplistic. It listened for tag events on Rawhide, checked them against its list and then triggered a build in the ELN target. Very quickly, the ELN SIG realized that this had significant limitations, particularly in the case of packages building in side-tags (which was becoming more common as the era of on-demand side-tags began). One of the main benefits of side-tags is the ability to rebuild packages that depend on one another in the proper order; this was lost in the BuildSync process and many times builds were happening out of order, resulting in packages with the same NVR as Rawhide but incorrectly built against older versions of their dependencies.

Initially, the ELN SIG tried to design a way to exactly mirror the build process in the side-tags, but that resulted in its own new set of problems. First of all, it would be very slow; the only way to guarantee that side-tags are built against the same version of their dependencies as the Rawhide version would be to perform all of those builds serially. Secondly, even determining the order of operations in a side-tag after it already happened turned out to be prohibitively difficult.

Instead, the ELN SIG recognized that the Fedora Rawhide packagers had already done the hardest part. Instead of trying to replicate their work in an overly-complicated manner, instead the tool would just take advantage of the existing builds. Now, prior to triggering a build for ELN, the tool would first tag the current Rawhide builds into ELN and wait for them to be added to the Koji buildroot. This solved about 90% of the problems in a generic manner without engineering an excessively complicated side-tag approach. Naturally, it wasn't a perfect solution, but it got a lot further. (See below for "Why are some package not tagged into the batch side-tag?" for more details.

A more recent modification to this strategy came about as CentOS Stream 10 started to come into the picture. With the intent to bootstrap CS 10 initially from ELN, tagging Rawhide packages to the ELN tag suddenly became a problem, as CS 10 needs to use that tag event as its trigger. The solution here was not to tag Rawhide builds into Fedora ELN directly, but instead to create a new ELN side-tag target where we could tag them, build the ELN packages there and then tag the successful builds into ELN. As a result, CS 10 builds were only triggered on ELN successes.

In late 2025, Fedora QA came to the ELN SIG and requested that we find some way to reduce the number of individual errata we were generating, as when they attempted to turn on automated testing for ELN, the result was an overload and significant queuing around mass-rebuilds and other large batches. When it got to the point that the Standard Operating Procedure for mass-rebuilds included disabling all the tests for ELN, it became clear that changes were needed and EBS was modified to start directly requesting errata for all the builds in the batch instead.

Frequently Asked Questions

Why does it sometimes take a long time for my package to be rebuilt?

Not all batches are created equal. Sometimes, there will be an ongoing batch with one or more packages whose build takes a very long time to complete. (e.g. gcc, firefox, LibreOffice). This can lead to up to a day's lag in even getting enqueued. Even if your package was part of the same batch, it will still wait for all packages in the batch to complete before the tag occurs.

As of this writing, we are currently investigating having certain extremely large packages built and tagged directly and without batching in order to shorten the average batch time.

Why do batches not run in parallel?

Simply put, until the previous batch is complete, there's no way to know if a further batch relies on one or more changes from the previous batch. This is a problem we're hoping might have a solution down the line, if it becomes possible to create "nested" side-tags (side-tags derived from another side-tag instead of a base tag). Today however, serialization is the only safe approach.

Why are some packages not tagged into the batch side-tag?

Some packages have known incompatibilities, such as libllvm and OCAML. The libraries produced in the ELN build and Rawhide build are API or ABI incompatible and therefore cannot be tagged in safely. We have to rely on the previous ELN version of the build in the buildroot.

Why do you not tag successes back into ELN immediately?

Despite the fact that we do not block ELN builds going to the stable repository based on test results, we do want to know about and address any issues revealed. Many packages are interdependent and it's far simpler to test the result of all the builds collectively, once we know they have all been rebuilt.

1. There are certain packages that we exclude from this so that the Rawhide package is not used in the ELN buildroot; see the skip_tag section of the configuration file for the current set. ︎
2. In the case of very large batches (such as mass-rebuilds), the set of packages may be split into more than one Bodhi update, to avoid in overtaxing things. ︎

07 May 2026 6:03pm GMT

This is a report created by the 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 with some initiatives inside the Fedora project.

Week: 27 April - 01 May 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

• Put risc-v Koji behind anubis and tightened its robots.txt to mitigate a scraper flood
• Somehow managed to keep the lights on with Kevin on PTO, teamwork win!
• Status.fpo webpage does not pickup status changes merged into status github repo
• Signing problem with the latest rawhide kernels
• vmhost-x86-copr04 rebooting

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 Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

• ELNBuildSync is unable to connect to Fedora Messaging
• Add GenericCloud images tests on testing.stream.centos.org
• Please add ogajduse to ocp-cico-foreman
• Fix openshift underlying issue (investigate) and upgrade
• Replace sigs.centos.org infra with el10 host
• Modernize centos mirror network CDN
• Create an "ansible-init" tool or container

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

• Release of Fedora 44 and torrents.
• Automation works for Mass Branching Bits.
• Unretirement workflow is now being processed from the fedpkg command; I found one bit to solve, which is being worked on.
• Samyak is trying to solve the dependency checker, which didn't account for alternative providers and rich dependencies.

RISC-V

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

• F44 rebuild update (community work): 60% of rebuild is done so far. (This is expected as we're with reduced Koji builders for a little while.)
• LLVM related debugging (this is slow-grind work)
  • Started a local rebase of my Fedora LLVM patches in my fork. I still have to test it on P550 and submit for review. The builds are time-consuming; it'll be a background task over the week.
  • Resumed debugging 'libomp' test suite failures. Setup an environment on DP1000.
• Explored what it takes to create a shadow Koji instance for RISC-V that tracks Rawhide. DavidA already tried several years ago and had to drop it due to deep-sync issues; there are some workarounds to deal with it today. (Half-baked ideas: we could write an updated koji-shadow but it's time-intensive. Experiment with a local copy, we don't want to mess with the active RISC-V Koji instance. (Also needs a capable "volunteer" with time to try this out.)
• Investigated and ordered an eGPU (external GPU) docks; last time I looked the one we needed was out of stock. Luckily one came back in stock. This dock helps us drive Tenstorrent's AI accelerator card.

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.

• Executive summary: F44 signed off and released, LFNW, blockerbugs forgejo migration and test enablement work
• Fedora 44 released, Lots of common issues notes written
• awilliam attended LinuxFest Northwest (with brendan, carl and gordon), gave a well-attended talk on root-causing theory and practice - video, slides , did booth duty
• PR to add openQA test of installing with a kickstart containing a non-existent package is blocked because anaconda handling of this is currently broken, anaconda team working on a fix
• Blockerbugs port to Forgejo is merged, deployed to staging and undergoing testing
• Kernel 7.0 Test Week now running (till May 1)
• Provided testing support for Silverblue migration to image-builder
• Various investigations and tweaks related to ELN moving to a new release package with several changes in behavior and bugs

Forgejo

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

• Foundational private issues frontend codebase implementation.
• Had a discussion on the collaboration strategy for the private issues
• Private Issues, Web UI: Push the foundational private issues frontend codebase implementation.
• Made some headway in the private issues dependencies implementation [Ticket]
• Spent a lot of Claude credits while brainstorming, nay, CUDA-storming what-if conditions
• Aarch64 runner successfully tested on staging (running on an AWS arm64 VM)
• New Forge Runner automation successfully deployed to production (and fixing discrepancy between openshift staging and production volume snapshots)
• Work towards getting the runnerhostvm enrolled in zabbix.

EPEL

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

• presented RPM packaging workshop and staffed booth at LinuxFest Northwest
• routine packaging work, including CVE fixes in forgejo-runner, glow, and vhs packages

UX

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

• Sketches for Bootc Sealed Images logo [ticket]
• Mockup for Flock 2026 t-shirt [ticket]
• Aligning with Brand for Fedora Hummingbird Linux
• Providing feedback to Jess Chitas from OSAIPO for Flock to Fedora Website Redesign [ticket]

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 18, 2026 appeared first on Fedora Community Blog.

06 May 2026 2:37pm GMT

06 May 2026 12:00pm GMT

06 May 2026 11:28am GMT

The Fedora QA team invites you to participate in the Podman 6.0 Test Days from Monday, May 11-15, 2026.

Podman 6.0 is a major modernization release that removes legacy
components and finalizes previously announced deprecation:

What's New in Podman 6.0

• Modern networking: Netavark switches from iptables to nftables,
  aligning with current Fedora defaults
• Simplified architecture: Removal of slirp4netns (replaced by Pasta)
  and BoltDB (replaced by SQLite)
• Cleaner configuration: Redesigned client/server configuration

These changes reduce technical debt and create a cleaner, more
maintainable codebase.

How to Participate

Requirements:

• Fedora 45 (Rawhide) - use the latest nightly image
• Virtual or physical machine
• Fully updated system

Testing:

1. Visit Podman 6.0 Test Days wiki and find links to rawhide iso and test cases.
2. Run tests and report results.

Need help?

Join us on Matrix: #podman:fedoraproject.org - developers and QA
specialists will be available all throughout the week. Or join our mailing list test@lists.fedoraproject.org.

Learn more:

• Podman 6.0 Change page
• Podman 6.0 Test Days

The post Join Us for Podman 6.0 Test Days - May 11-15, 2026 appeared first on Fedora Community Blog.

05 May 2026 11:56am GMT

05 May 2026 10:00am GMT

04 May 2026 8:00am GMT

During my work on the RISC-V 64-bit architecture port of Fedora, I created several pull requests to Fedora packages. And some were stalled…

Non-responsive maintainer process

Fedora project has a process called 'non-responsive maintainer'. You check is maintainer on vacation, check latest activity and open a bug asking for action.

The problem was that it linked to fedora_active_user.py script which does not work since Fedora 41. During cycle of that release the python-fedora package got retired and no one updated the script.

Let me look

As my actions brought some complains (and some discussions) I decided to take a look at the script and make it work with current Fedora releases. Created pull request, mailed original author etc.

There was no answer of any kind so I decided to take over maintaining the script. Rewrote it to be Python 3 only, moved from urllib to requests, refactored some repeated code into functions etc.

Then started checking service by service how to get things working better. Turned out that script had several assumptions which not always apply.

FAS has separate email for Bugzilla

Fedora Accounts Service (FAS) has a separate field for the Bugzilla email. I did not had to look for testing accounts for this because that's my case - I use 'short' Red Hat email in Bugzilla due to Single Sign-On (SSO) service we use and my 'long' one for the rest. So fedora-active-user script grabs user information from FAS and checks for separate Bugzilla email and use it if present.

FAS query requires Kerberos

To query FAS you need Kerberos ticket. Both urllib and requests packages have a way to use it for authentication - one extra package is needed to make it work.

Lack of valid ticket is caught and info is provided to the user.

Bugzilla is tricky

Querying Bugzilla service is the trickiest part. You can request data but there is no warranty that you get the latest one. Sure, there is the 'order' field for a query but it feels like a mere suggestion. It is nothing strange to get 2008 entries next to 2023 ones.

Wanna help?

For now, I am hosting fedora-active-user on GitHub. Will move it to Fedora Forge later this year. Feel free to open issues, send pull requests if you have suggestions or changes.

Current version is not the best one. It is a bit better than it was two weeks ago.

At the moment package is present in Fedora rawhide. I am waiting for branches for stable releases and updates will follow.

Example output

$ fedora-active-user --user hrw

Last action on koji:
   2026-05-04 built fedora-active-user-26.05.04-1.fc45
   2024-09-12 built python-system-calls-6.11.0-1.fc42
   2024-01-08 built python-system-calls-6.7.0-1.fc40
   2023-09-18 built python-system-calls-6.6.0-1.fc40
   2023-05-08 built python-system-calls-6.4.0-2.fc39
   2022-08-06 built python-system-calls-5.19.0-2.fc37
   2022-07-25 built python-system-calls-5.19.0-1.fc36
   2022-07-25 built python-system-calls-5.19.0-1.fc37
   2022-01-10 built python-system-calls-5.16.2-1.fc36
   2021-11-15 built python-system-calls-5.16.0-1.fc35

Last package updates on bodhi:
   2026-05-04 fedora-active-user-26.05.04-1.fc45
   2024-09-12 python-system-calls-6.11.0-1.fc42
   2024-01-08 python-system-calls-6.7.0-1.fc40
   2023-09-18 python-system-calls-6.6.0-1.fc40
   2023-05-08 python-system-calls-6.4.0-2.fc39
   2022-08-06 python-system-calls-5.19.0-2.fc37
   2022-07-25 python-system-calls-5.19.0-1.fc36
   2022-07-25 python-system-calls-5.19.0-1.fc37
   2022-01-10 python-system-calls-5.16.2-1.fc36
   2021-11-15 python-system-calls-5.16.0-1.fc35
   2021-11-15 python-system-calls-5.16.0-1.fc36
   2021-09-21 python-system-calls-5.15.5-1.fc36

Last actions performed according to fedmsg:
   2026-05-04 hrw commented on the pull-request rpms/prusa-slicer#67
   2026-05-04 hrw's Badges rank changed from 272 to 260
   2026-05-04 hrw was awarded the badge `Missed the Train`
   2026-05-04 hrw commented on update fedora-active-user-26.05.04-1.fc45 (karma: 0)
   2026-05-04 fedora-active-user-26.05.04-1.fc45 was tagged into f45 by bodhi
   2026-05-04 fedora-active-user-26.05.04-1.fc45 was untagged from f45-updates-candid
   2026-05-04 hrw's fedora-active-user-26.05.04-1.fc45 bodhi update has met stable te
   2026-05-04 fedora-active-user-26.05.04-1.fc45 was untagged from f45-updates-testin
   2026-05-04 fedora-active-user-26.05.04-1.fc45 was tagged into f45-updates-testing-
   2026-05-04 fedora-active-user-26.05.04-1.fc45 was untagged from f45-signing-pendin

Last emails on Fedora mailing lists:
   2026-04-29 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
   2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
   2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
   2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
   2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
   2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
   2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
   2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
   2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
   2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora

Bugzilla activity (may not be the latest):
   No activity found on Bugzilla

Looks like I still need to work on querying Bugzilla ;D

04 May 2026 6:37am GMT

I'm back from my vacation, so time for another weekly recap...

02 May 2026 5:41pm GMT

Hello travelers!

Loadouts for Genshin Impact v0.1.16 is OUT NOW with the addition of support for recently released characters like Linnea and for recently released weapons like Golden Frostbound Oath from Genshin Impact Luna VI or v6.5 Phase 2. Take this FREE and OPEN SOURCE application for a spin using the links below to manage the custom equipment of artifacts and weapons for the playable characters.

Resources

• Loadouts for Genshin Impact - GitHub
• Loadouts for Genshin Impact - PyPI
• Loadouts for Genshin Impact v0.1.15
  • Executable for GNU/Linux distributions
  • Executable for Microsoft Windows

Installation

Besides its availability as a repository package on PyPI and as an archived binary on PyInstaller, Loadouts for Genshin Impact is now available as an installable package on Fedora Linux. Travelers using Fedora Linux 42 and above can install the package on their operating system by executing the following command.

$ sudo dnf install gi-loadouts --assumeyes --setopt=install_weak_deps=False

Changelog

• Automated dependency updates for GI Loadouts by @renovate[bot] in #516
• Resolve the SEST assets alignment issue by @gridhead in #524
• Change the default artifact to None by @gridhead in #526
• Update dependency pillow to v12.2.0 [SECURITY] by @renovate[bot] in #527
• Update dependency pytest to v9.0.3 [SECURITY] by @renovate[bot] in #528
• Resolve the DGFT assets alignment issue by @gridhead in #525
• Switch packaging from PyInstaller to Nuitka by @gridhead in #518
• Update GitHub workflows with Fedora Linux 43 by @gridhead in #523
• Update dependency python to 3.13 || 3.14 by @renovate[bot] in #529
• Update dependency nuitka to v4 by @renovate[bot] in #530
• Automated dependency updates for GI Loadouts by @renovate[bot] in #517
• Introduce the recently added weapon Golden Frostbound Oath by @gridhead in #533
• Introduce the recently added character Linnea to the roster by @gridhead in #532
• Document the evolving Windows SmartScreen errors by @gridhead in #541
• Stage the release v0.1.16 for Genshin Impact Luna VI (v6.5 Phase 2) by @gridhead in #542
• Automated dependency updates for GI Loadouts by @renovate[bot] in #534

Characters

One character has debuted in this version release.

Linnea

Linnea is a bow-wielding Geo character of five-star quality.

Weapons

One weapon has debuted in this version release.

Appeal

While allowing you to experiment with various builds and share them for later, Loadouts for Genshin Impact lets you take calculated risks by showing you the potential of your characters with certain artifacts and weapons equipped that you might not even own. Loadouts for Genshin Impact has been and always will be a free and open source software project, and we are committed to delivering a quality experience with every release we make.

Disclaimer

With an extensive suite of over 1558 diverse functionality tests and impeccable 100% source code coverage, we proudly invite auditors and analysts from MiHoYo and other organizations to review our free and open source codebase. This thorough transparency underscores our unwavering commitment to maintaining the fairness and integrity of the game.

The users of this ecosystem application can have complete confidence that their accounts are safe from warnings, suspensions or terminations when using this project. The ecosystem application ensures complete compliance with the terms of services and the regulations regarding third-party software established by MiHoYo for Genshin Impact.

All rights to Genshin Impact assets used in this project are reserved by MiHoYo Ltd. and Cognosphere Pte., Ltd. Other properties belong to their respective owners.

01 May 2026 6:30pm GMT