fidzu : Fedora

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: 16 Feb - 20 Feb 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

• [GSoC Project Idea 2026] Revamp Fedora Badges project with modern fullstack architecture and dedicated MCP support [Ticket] [Followup]
• [Infra] Added package and installed size to package metadata [Review] [Lint]
• [Infra] Improve vagrant setup instructions and add container-based setup [Followup A] [Followup B]
• Migration of pagure.io repositories to forge.fedoraproject.org continues (9 more repositories migrated)
• Resolved authentication issues with wordpress instances (thanks to misc)
• Fixed database connection issues on Dist-Git
• Dep updates and CI fixes for our apps in Github
• Worked on the port of bugzilla2fedmsg to Kafka (since the UMB deprecation), deployed it to staging, asked RHIT for firewall ports.

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

• lack of ipv6 on some sponsored servers
• New Build Target and Tags for the Kmods SIG (kernel-6.18)
• Extend maximum build time for CS10 Risc-v
• Spam on the automotive-sig mailing list
• Move Hyperscale SIG docs source from pagure to gitlab
• Request: Add new SSH key for OKD / SCOS bootimage sync to cloud.centos.org
• mirror request
• Setup BuildRoot for CS10 risc-v
• allow rsync for 2 fedoraproject mirrors
• Need more disk space on Gitlab Runners
• Ensuring that gen2 images are also deleted/cleaned up from koji (through koji-gc)

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

• Fedora 44 Beta Freeze is now in effect.

RISC-V

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

• (Not a lot to report this week, besides the routine on-going work.)
• Started a discussion with the RISC-V team about RHEL builders for Konflux. (This is not about general Konflux support, that's out of scope)
• Continued to investigate Fedora 44 build failures and all that entails - working with relevant upstream maintainers to get changes reviewed, merged, etc.
• Sorted out a build-timeout issue with Copr upstream. (Jason Montleon is currently used to build some board-specific kernels.)

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.

• TestDays App was updated in production.
• Anubis no longer breaks actions in Forge thanks to our debugging (and Infra fixing it, of course).
• Blockerbugs meetings and the whole blocker review process has started since this week.
• Ran test days: Grub OOM fix, GNOME 50

Forgejo

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

• Spike of zabbix installation for ansible-role-forgejo-runner researched
• Forge image build and versioning fully automated
• Runners updated to use image version 12
• More migrations from pagure and troubleshooting
• Private Issues: Fixed tests, tied up loose ends and consolidated feature branch.
• Packit team got access to staging distgit deployment
• Create new organisation and namespace on Fedora Forge for Fedora Join [Followup] [Namespace]

UX

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

• CLE logo complete!
• F45 wallpaper mindmap session took place. Mindmap created can be found here.
• Continuing Forgejo migration.

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

20 Feb 2026 10:00am GMT

The Podman team and the Fedora Quality Assurance team are organizing a Test Week from Friday, February 27 through Friday, March 6, 2026. This is your chance to get an early look at the latest improvements coming to Podman and see how they perform on your machine.

What is Podman?

For those new to the tool, Podman is a daemonless, Linux-native engine for running, building, and sharing OCI containers. It offers a familiar command-line experience but runs containers safely without requiring a root daemon.

What's Coming in Podman 5.8?

The upcoming release includes updates designed to make Podman faster and more robust. Here is what you can look forward to, and what you can try out during this Fedora Test Day.

A Modern Database Backend (SQLite)

Podman is upgrading its internal storage logic by transitioning to SQLite. This change modernizes how Podman handles data under the hood, aiming for better stability and long-term robustness.

Faster Parallel Pulls

This release brings optimizations to how Podman downloads image layers, specifically when pulling multiple images at the same time. For a deep dive into the engineering behind this, check out the developer blog post on Accelerating Parallel Layer Creation.

Experiment and Explore: Feel free to push the system a bit and try pulling several large images simultaneously to see if you notice the performance boost. Beyond that, please bring your own workflows. Don't just follow the wiki instructions. Run the containers and commands you use daily. Your specific use cases are the best way to uncover edge cases that standard tests might miss.

What do I need to do?

• Make sure you have a Fedora Account (FAS).
• Download test materials in advance where applicable, which may include some large files.
• Follow the steps on the wiki test page one by one.
• Send us your results through the app.

Details on how to test and report results are available at the Wiki Test Day site for Podman 5.8 test day:
https://fedoraproject.org/wiki/Test_Day:2026-02-27_Podman_5.8

Test Week runs from Friday, February 27 through Friday, March 6, 2026

Thank you for taking part in the testing of Fedora Linux 44!

20 Feb 2026 8:00am GMT

Potential GSoC contributors may reach out with questions about our project ideas or GNOME internships in general. Please direct them to gsoc.gnome.org to learn more.

You can find our proposed project ideas at gsoc.gnome.org/2026.

Project proposal submissions are open from March 16th to 31st.

20 Feb 2026 6:58am GMT

19 Feb 2026 11:56am GMT

19 Feb 2026 10:19am GMT

Want to learn the latest container tech? From February 27 to March 6, 2026, you can join the Podman 5.8 Test Day. It is the perfect time to explore new features and see how the future of Fedora is built.

What is new?

• Faster Downloads: Try optimized "parallel pulls" to get your images in seconds.
• Setup: Test the new "automatic database creation" for a smoother start.
• Expert Skills: Learn how to use latest container environments before they go mainstream.

Why join?

Your setup is unique. By running Podman 5.8 on your machine, you make sure the final version works perfectly for everyone. It is a great way to learn by doing and to see how top-tier open-source software is made.

Start here

We have prepared easy-to-follow steps for you here: https://fedoraproject.org/wiki/Test_Day:2026-02-27_Podman_5.8

The post Master Podman 5.8: Join Fedora Test Week appeared first on Fedora Community Blog.

19 Feb 2026 10:00am GMT

I've used some form of DSri Seah's Compact Calendar for over seven years. The calendar is a lovingly designed single-page view of the entire year, organized into Monday-through-Sunday weeks with no breaks between months.

The point of the format is simple: my normal calendar is great at telling me what I'm doing on Tuesday. What it's terrible at is answering planning questions that are above the day level, such as:

• If we take a vacation the last two weeks of July, will it overlap business travel?
• Can we connect these two public holidays and get 14 days away for only 8 days of PTO?
• Do we have any genuinely empty weeks left this year?

For a long time, my compact calendar was a spreadsheet. That worked until it didn't.

The problem I actually needed to solve

The spreadsheet version served me well for years, but life got more complicated.

My kid is getting older, which means more activities to track: summer camps, school breaks, etc. My partner and I no longer work for the same company, so we don't share the same corporate holidays and as our roles have changed so has the amount of travel we do. And, honestly, my spreadsheet has bespoke formulas that only I understand … on Thursdays when there is a full moon.

My partner knows how to use a calendar app. She really doesn't want to learn a special spreadsheet for planning, and I don't blame her.

The real friction screaming out that there had to be a better way was the double-entry work. If my kid has summer camp in July, I'd put it on the family calendar - and then manually mark those weeks on my compact calendar spreadsheet. Two sources of truth means one of them is eventually wrong.

So the job wasn't "build a better calendar." It was: keep the year-at-a-glance view, but make the calendar app the source of truth.

The shape of the solution

I decided to build a web version of the compact calendar that could read directly from standard ICS calendar feeds.

Put the summer camp on the shared calendar once. The compact calendar picks it up automatically.

And if this was going to be something my partner and I actually used together, it needed two things:

• A simple setup flow (not "copy this spreadsheet and don't touch column Q")
• A way to always be available beyond, "go find this Google Docs Link"

What the tool does

The calendar renders a full year on a single page. Each row is one week, Monday through Sunday.

Parallel to the block of weeks running down the page is a column for displaying committed events and a second for displaying possible events.

• Committed: events that are definitely happening - travel that's booked, school terms, confirmed work trips.
• Possible: things under consideration - a conference I submitted a talk to but haven't heard back from yet, vacation options we're weighing.

The tool uses color to signal status at a glance:

• Blue background: first day of the month (anchors the continuous weeks)
• Red text: public holidays (per selected country)
• Green background: committed events
• Yellow background: possible events
• Green background with a yellow border: overlaps/conflicts that need attention

Here's what the full-year view looks like with demo data loaded:

Inputs: URL, file, or demo

While there is demo data available in the system, the key comes from loading your own data. You can choose two different kinds of sources:

• A URL - a webcal:// or https:// link to a published calendar (iCloud, Google Calendar, etc.)
• A file - a .ics file uploaded from your computer

We're an Apple household so our calendars live in iCloud, but the tool doesn't care about your calendar provider. Anything that produces a standard ICS feed works.

My practical workflow is two shared calendars in Apple Calendar:

• one for committed travel and events. For me, this is actually my shared calendar that our family maintains.
• one for possibilities we're considering

Both are published as webcal URLs, and the compact calendar fetches them and renders the year view. Using my shared calendar works because the app ignores events that aren't multi-day, all-day blocks - so dentist appointments don't drown out the year view. You can optionally include single day all-day events if that helps you.

The setup controls are intentionally simple:

The tech (and the annoying part)

This is a vanilla JavaScript app built with Vite, hosted on Azure Static Web Apps. No framework - just DOM manipulation, a CSS file, and under 500 lines of main application code.

The interesting technical problem was CORS.

Calendar providers like iCloud don't set CORS headers on their published feeds, which means a browser can't fetch them directly. The solution is a small Azure Function that acts as a proxy:

• the browser sends the calendar URL to the server
• the server fetches the calendar data
• the server returns it to the browser

The proxy doesn't store or log anything. It's a pass-through.

I built the app with an AI coding agent. I provided direction and made decisions, but I didn't hand-write every line. For this kind of tool, I'm comfortable with that. It's a static site that renders calendar data client-side, and the risk profile is low. Additionally, nothing in this code represents a new problem or a novelty. This is bog-standard code, and the agent handled the boilerplate well for this project.

Importantly, even though I could have written this code myself, I wouldn't have. I probably would have gotten myself caught in a bit of analysis paralysis over frameworks. But more importantly, writing a lot of this code is just boring code to write. The AI agent has allowed me to solve my own problem, and that's the part that matters to me. I didn't have to suddenly become more disciplined about spreadsheets or get my family dragged onto a tool that really only speaks to me. Instead, I was able to change the shape of the problem and make it more solvable within the context of the humans involved.

Privacy and the honest trade-off

All your data stays in your browser. The app stores the URLs you're loading, your selected country, and cached holiday data in local storage. This is purely functional and not for tracking.

Calendar URLs necessarily have to go through the server-side proxy because browsers won't fetch them directly. The proxy is a stateless pass-through - I don't persist calendar data in the function or in your browser. Calendar URLs are sent via POST request body rather than query parameters, which means they aren't captured in Azure's platform-level request logs. Error logging includes only the target hostname (e.g., "iCloud fetch failed"), never the full URL or authentication tokens. If your calendar URL contains authentication tokens (iCloud URLs do), understand that the proxy briefly sees them in transit.

Try it out

The calendar is live at cc.bexelbie.com. You can load the built-in demo data to explore without connecting your own calendars - select "Demo" from either input dropdown.

The source is on GitHub at bexelbie/online-compact-calendar. If you have ideas or find bugs, open an issue.

On first visit, there's a banner that points you at settings:

What's next

I'm going to live with it for a while before adding features. The spreadsheet served me for seven years with almost no changes.

18 Feb 2026 1:30pm GMT

To control which devices LVM can work with, it was always possible to configure filtering in the devices section of the /etc/lvm/lvm.conf configuration file. But filtering devices this way was not very simple and could lead to problems when using paths like /dev/sda which are not stable. Many users also didn't know this possibility exists and while using this type of filtering is possible for a single command with the --config option, it is not very user friendly. This all changed recently with the introduction of the new configuration file /etc/lvm/devices/system.devices and the corresponding lvmdevices command in LVM 2.03.12. A new option --devices was also added to the existing LVM commands for a quick way to limit which devices one specific command can use.

LVM Devices File

As was said above, there is a new /etc/lvm/devices/system.devices configuration file. When this file exists, it controls which devices LVM is allowed to scan. Instead of relying on matching the device path, the devices file uses stable identifiers like WWID, serial number or UUID.

A device file on a simple system with a single physical volume on a partition would look like this:

# LVM uses devices listed in this file.
# Created by LVM command vgimportdevices pid 187757 at Fri Feb 13 16:44:45 2026
# HASH=1524312511
PRODUCT_UUID=4d58d0c1-8b67-4fa6-a937-035d2bfbb220
VERSION=1.1.1
IDTYPE=devname IDNAME=/dev/sda2 DEVNAME=/dev/sda2 PVID=rYeMgwy0mO0THDagB6k8mZkoOSqAWfte PART=2

When the devices file is enabled, LVM will only scan and operate on devices listed in it. Any device not present in the file is invisible to LVM, even if it has a valid PV header.

This is the biggest change brought in with this feature. The old lvm.conf based filters were always optional and LVM always scanned all devices in the system, unless told otherwise. This could cause problems on systems with many disks, where LVM (especially during boot) could take a long time scanning devices that did not even "belong" to it.

By default, the LVM devices file is enabled with the latest versions of LVM and on systems without preexisting volume groups, creating new LVM setups with commands like pvcreate or vgcreate will automatically add the new physical volumes to the devices file. If desired, this feature can be disabled by setting use_devicesfile=0 in lvm.conf or by simply removing the existing devices file. On systems without the devices file, LVM will simply scan all devices in the system the same way it did before introduction of this configuration file.

Managing Devices with lvmdevices and vgimportdevices

On most newly installed systems with LVM, the devices file should be already present and populated, but you might want to either create it later on systems installed with an older version of LVM, or manage some devices manually. It is possible to modify the system.devices manually, but a new command lvmdevices was added for simple management of the file.

To simply import all devices in an existing volume group, vgimportdevices <vgname> can be used and for all volume groups in the system, vgimportdevices -a can be used.

A single physical volume can be added to the file with lvmdevices --adddev and removed with lvmdevices --deldev.

To check all entries in the devices file, lvmdevices --check can be used and any issues found by the check command can be fixed with lvmdevices --update.

Backups

In the sample devices file above, you might have noticed the VERSION field. This is the current version of the file. LVM automatically makes a backup of the file with every change and old versions of the file can be found in the /etc/lvm/devices/backup directory. So if you make some mistakes when changing the file with lvmdevices, you can simply restore to a previous version of the file.

Overriding the Devices File and Filtering with Commands

Together with the devices file feature, a new option --devices was added to all LVM commands. This option allows specifying devices which are visible to the command. This overrides the existing devices file so it can be used either to restrict the command to work only on a subset of devices specified in the devices file or even to allow it to run on devices not specified in the file at all.

This option is also very useful when dealing with multiple volume groups with the same name. This is a known limitation of LVM - two volume groups with the same name cannot coexist in one system and LVM will refuse to work without renaming one of them. This can be a problem when dealing with cloned disks or backups. With --devices, commands like vgs can be restricted to "see" only one of the volume groups.

Issue: Missing Volume Group

As mentioned above, when installing a new system with LVM, for the newly created volume groups, the used devices will be added to the devices file. Fedora (and RHEL) installer, Anaconda, will also add all other volume groups present during installation to the devices file so these will also be visible in the installed system. The problems start when a device with a volume group is added to the system after installation. The volume group (and any logical volumes in it) is suddenly invisible. Even commands like vgs will simply ignore it, because its physical volumes are not listed in the devices file.

This can be a problem on dual boot systems with encryption. Because the second system's volume group is "hidden" by the encryption layer, it is not visible during installation and not added to the devices file. When the user unlocks the LUKS device in their newly installed system, they can't access their second system. Unfortunately in this situation, the only solution is to manually add the second system's volume group with vgimportdevices as described above.

Conclusion

The LVM devices file provides a cleaner and more reliable way to control which devices LVM uses, replacing the old lvm.conf based filtering with stable device identifiers and simple management through the lvmdevices command. Overall, for most users the devices file should work transparently without any manual configuration needed.

18 Feb 2026 7:13am GMT

Mrhbaan, Fedora community! I am happy to share that as of 10 February 2026, Fedora is now available in Syria. Last week, the Fedora Infrastructure Team lifted the IP range block on IP addresses in Syria. This action restores download access to Fedora Linux deliverables, such as ISOs. It also restores access from Syria to Fedora Linux RPM repositories, the Fedora Account System, and Fedora build systems. Users can now access the various applications and services that make up the Fedora Project. This change follows a recent update to the Fedora Export Control Policy. Today, anyone connecting to the public Internet from Syria should once again be able to access Fedora.

This article explains why this is happening now. It also covers the work behind the scenes to make this change happen.

Why Syria, why now?

You might wonder: what happened? Why is this happening now? I cannot answer everything in this post. However, the story begins in December 2024 with the fall of the Assad regime in Syria. A new government took control of the country. This began a new era of foreign policy in Syrian international relations.

Fast-forward to 18 December 2025. The United States signed the National Defense Authorization Act for Fiscal Year 2026 into law. This law repealed the 2019 Caesar Act sanctions. This action removed Syria from the list of OFAC embargoed countries. The U.S. Department of the Treasury maintains this list.

This may seem like a small change. Yet, it is significant for Syrians. Some U.S. Commerce Department regulations remain in place. However, the U.S. Department of the Treasury's policy change now allows open source software availability in Syria. The Fedora Project updated its stance to welcome Syrians back into the Fedora community. This matches actions taken by other major platforms for open source software, such as Microsoft's GitHub.

Syria & Fedora, behind the scenes

Opening the firewall to Syria took seconds. However, months of conversations and hidden work occurred behind the scenes to make this happen. The story begins with a ticket. Zaid Ballour (@devzaid) opened Ticket #541 to the Fedora Council on 1 September 2025. This escalated the issue to the Fedora Council. It prompted a closer look at the changing political situation in Syria.

Jef Spaleta and I dug deeper into the issue. We wanted to understand the overall context. The United States repealed the 2019 Caesar Act sanctions in December 2025. This indicated that the Fedora Export Policy Control might be outdated.

During this time, Jef and I spoke with legal experts at Red Hat and IBM. We reviewed the situation in Syria. This review process took time. We had to ensure compliance with all United States federal laws and sanctions. The situation for Fedora differs from other open source communities. Much of our development happens within infrastructure that we control. Additionally, Linux serves as digital infrastructure. This context differs from a random open source library on GitHub.

However, the path forward became clear after the repeal of the 2019 Caesar Act. After several months, we received approval. Fedora is accessible to Syrians once again.

Opening the door to Syria

Some folks may have noticed the Fedora Infrastructure ticket last week. It requested the removal of the firewall block. We also submitted a Fedora Legal Docs Merge Request to change the Fedora Export Control Policy.

We wanted to share this exciting announcement now. It aligns with our commitment to the Fedora Project vision:

"The Fedora Project envisions a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities."

We look forward to welcoming Syrians back into the Fedora community and the wider open source community at large. Mrhbaan!

17 Feb 2026 8:00am GMT

Another weekly recap of happenings around fedora for me.

14 Feb 2026 6:20pm GMT

14 Feb 2026 8:00am GMT

13 Feb 2026 10:34am 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: 09 - 13 February 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

• Ported bugzilla2fedmsg to use Red Hat's Kafka servers, since UMB will be decommissioned. The code with Kafka support is currently in staging but requires firewall ports to be opened (ticket 13133)
• Resolved outage of stg.pagure.io caused by anubis (ticket 13128)
• Few more repositories migrated to forge.fedoraproject.org from pagure.io
• Resolved pushing issues on to src.stg.fedoraproject.org, caused by wrong permissions (ticket 13096)
• [Tahrir] Add PUT endpoint for updating for USER relation and integrate it with the frontend [Review] [Merged]
• [Tahrir] List profile invitations when the user has logged in [Pull request]

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

• Update Gitlab Runners to v18
• Spam on the automotive-sig mailing list

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

• Fedora 44 Mass Branching was successfully completed last week!
• Beta Freeze is tentatively scheduled to begin next week, Tue 2026-02-17.

RISC-V

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

• Fedora RISC-V "unified kernel" work in progress (Jason Montleon): targeted for F44. Right now they're being built in Copr. Will move to Koji once the F44 buildroot is populated.
• Work by Fabian Arrotin RISC-V builders in CentOS Build System (CBS) now can build from official sources (git+https from CentOS Stream)

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.

• Co-ordinated with releng team on branching as it involves openQA, critical path and the gating policies - things went much smoother this time but still lots of lessons learned and SOP improvements drafted and suggested
• Work ongoing to port the blockerbugs tool to forgejo , nearly complete but may be delayed as jgroman will be on PTO
• Multiple enhancements to testdays-web, see merged PRs
• Updated openQA packages deployed to production
• Another heavy week of openQA catching bugs, mostly plasma-setup and GNOME 50, details here

Forgejo

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

• Forgejo backup pruning solved
• Staging runner going offline issue fixed
• A lot of new organizations created, repo migrations
• Private Issues: Make tests succeed, ongoing: tidy up commits for PR

EPEL

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

• EPEL 11 early planning at CentOS Connect, FOSDEM, and CentOS Docs Day

UX

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

• Started migrating Fedora Design to Forgejo!
• The F45 wallpaper inspiration is officially Alan Turing!

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

13 Feb 2026 10:00am GMT

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

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

ℹ️ These versions are also available as Software Collections in the remi-safe repository.

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ There is no security fix this month, so no update for versions 8.2.30 and 8.3.30.

Version announcements:

• PHP 8.5.3 Release Annoucement
• PHP 8.4.18 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.3
• Fedora 44 - PHP 8.5.3
• Fedora 43 - PHP 8.4.18
• Fedora 42 - PHP 8.4.17

⚠️ 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)

13 Feb 2026 5:42am GMT

12 Feb 2026 11:00pm GMT

This yak is now shaved!

me

I've been working on two submissions I want to put into the CFP for installfest.cz and had them at a "man it'd be nice to have someone else read and comment on this" level of done. Normally when this happens I have to psych myself up for it, both because receiving feedback can be hard and because I have to do a format conversion. I tend to write in markdown in "all the places" and sharing a document for edits has typically meant pasting it into something like Google Docs or Office 365, where even if it still looks like markdown … it isn't.

And that's when the yak walked into the room. Instead of just pasting my drafts into Google Docs and getting on with the reviews, I decided I needed to delay getting feedback and build the markdown collaborative editing system of my dreams. Classic yak shaving - solving a problem you don't actually need to solve in order to eventually do the thing you originally set out to do. What is Yak Shaving - a video by Matthew Miller if you're unfamiliar.

When I am done, I then have to take this text back to where it was originally going, often in good clean markdown (this blog post is in markdown!). This rigmarole is tiring. I also dislike that the go to tools for this for me had turned into an exercise in ensuring guests could access a document or collecting someone's login ids to yet another system.

I knew there had to be a better way. Then it hit me. When markdown started to take off we had a slew of markdown collaborative editing sites take off. They were often modeled on the older etherpad. Well, several are still around. I looked at online options as I tend to prefer using a service when I can so I don't get more sysadmin work to do.

I hit three snags in picking one:

1. I don't like being on a free tier when I don't understand how it is supported. While I don't know that anyone in this space is nefarious, the world is trending in a specific direction. I don't mind paying, but this was also not going to generate enough value to warrant serious payments.
2. The project that first came to mind for markdown collaboration went open core back in 2019. Open source business models are hard, and doing open core well is even harder. As you'll see below I had specific needs and I had a feeling I might run into the open core wall.
3. One of the CFPs would actually benefit from implementing this as my example … bonus!

After examining a bunch of options, I settled on building something out of Hedgedoc. This was not an easy choice and the likelihood of entering analysis paralysis was super high. So I decided to try to force this to fit on a free tier Google GCP instance I have been running for years. It is the tiny e2-micro burstable instance, a literal thimble of compute.

This ran off a lot of options. Privacy first options need more compute just to do encryption work. A bunch of options want a server database (Postgres and friends) and a single person instance should be fine on SQLite, in my opinion. All roads now ran to Hedgedoc. It was the only option that could run on SQLite, tolerate my tiny VM, still give me collaborative markdown, and seemed to have every feature required if I could make it work.

It wasn't all sunshine and happiness though. Hedgedoc is in the middle of writing version 2.0, which means 1.0 is frozen for anything except critical fixes and all efforts are focused on the future. Therefore, the documentation being a bit rough in places was something I was going to have to live with.

My core requirements were:

1. Only I am allowed to create new notes
2. Anyone with the "unguessable" url can edit and should not require an account to do so
3. This should require next to zero system administration work and be easy to start and stop
4. When I need more features, I should be able to extend this with a plugin for tools like Obsidian or Visual Studio Code.

And while it took longer than I'd hoped, it works. Here's how:

1. Write yourself a configuration file for Hedgedoc

config.json:

{
  "production": {
    "sourceURL": "https://github.com/bexelbie/hedgedoc",
    "domain": "<url>",
    "host": "localhost",
    "protocolUseSSL": true,
    "loglevel": "info",
    "db": {
      "dialect": "sqlite",
      "storage": "/data/db/hedgedoc.sqlite"
    },
    "email": true,
    "allowEmailRegister": false,
    "allowAnonymous": false,
    "allowAnonymousEdits": true,
    "requireFreeURLAuthentication": true,
    "disableNoteCreation": false,
    "allowFreeURL": false,
    "enableStatsApi": false,
    "defaultPermission": "limited",
    "imageUploadType": "filesystem",
    "hsts": {
      "enable": true,
      "maxAgeSeconds": 31536000,
      "includeSubdomains": true,
      "preload": true
    }
  }
}

This sets a custom source URL for the fork I have made (more below), enables SSL, disables new account registration, and allows edits via unguessable URLs without requiring logins.

1. Decide how you want to launch the container, I am using a quadlet, and provide some environment variables:

CMD_SESSION_SECRET="<secret>"
CMD_CONFIG_FILE=/hedgedoc/config.json
NODE_ENV=production

These just put it in Production mode, point it at the config and provide the only secret required.

1. You're basically done. I happen to have put mine behind a Cloudflare tunnel and updated the main page of the site, but those are pretty straight forward.

More Yak Shaving

Naturally I planned to launch it, create my user id via the cli, and share my CFP submissions with the folks I wanted reviews from. Narrator: Naturally, that's not what happened.

I decided to push YAGNI¹ out of the way and NEED IT! Specifically I forked the v1 code into a repository to add some features. The upstream is unlikely to want any of these so I will have to carry these patches. What I did:

1. Hedgedoc will do color highlighting and gutter indicators so you can see which author added what text. Unfortunately it wasn't seeming to be working. I was getting weak indicators (underlines instead of highlighting) and often nothing. So I fixed that.
2. The colors for authorship are chosen randomly. I am a bit past my prime in the seeing department and it was hard to see the colors against the dark editor background, so I restricted color choices to those that are contrasting. It isn't perfect, but it is better.
3. My particular set up involves a lot of guest editors. Normally I share to just a few folks, but sometimes to many. They'll all be anonymous. Hedgedoc doesn't track authorship colors for guests, so I patched in a system to generate color markings for anonymous editors.
4. A feature I always loved in Etherpad was that you could temporarily hide the authorship colors when you just wanted to "read the document." So I added a button for that. While I was doing that I discovered that there is a separate toggle to switch the editor into light mode, but I couldn't see it because the status bar was black and it was set to .2 opacity!! I fixed that too. Also, now the status bar switches when the editor switches.
5. Comments, it turns out are needed. So I coded in rudimentary support for critic markup comments.

I have other ideas, but instead I am going to stop and let YAGNI win for a while. Besides, hopefully 2.0 will ship soon and render all of this unneeded.

So there you go, now if you want to offer your assistance to help me write something, I'll send you a link and you can go to town on our shared work. If you want to see more about this, well, let's see if Installfest.cz thinks you should or not :D - and whether this yak decides to grow its hair back.

12 Feb 2026 12:00pm GMT