Element Matrix services will be upgrading our fedora.im and fedoraproject.org servers to use the new Matrix Authentication Server. This will allow clients to use the new element X and similar clients.
During the outage matrix servers will be unavailable, but messages will be received after the outage is …
admin )
on 2025-12-08 13:00:00 UTC
We will be powering off hardware in our rdu2 datacenter, it will be deracked and moved to our rdu3 datacenter, reracked, and reconfigured for the new network.
retrace/abrt/faf will be down and not accepting user reports smtp-auth-cc-rdu01 will be down and not accepting emails download-cc-rdu01 will be down …
hey everyone, it's saturday so time for another recap of adventures in fedora infrastructure and other fedora areas.
I started a discussion thread about the current scrapers we are dealing with. To summarize, anubis has cut out a bunch of them and really helped out quite a lot. It has caused some issues with clients as well, but we have been working thought those as we hear about them. The remaining scrapers are large botnets of browsers, probibly running on end user machines. Those are more troublesome to deal with.
The discussion thread is at: https://discussion.fedoraproject.org/t/scrapers-and-ideas-for-how-to-deal-with-them/175760 if anyone would like to read or contribute.
We had another run in with them eariler this morning. A great way to spend saturday morning, but I did look more carefully this time. The main cause of issues was them hitting src.fedoraproject.org and it's /history/ and /blame/ endpoints. This was causing the backend to have to do a somewhat expensive git blame/history call to the local repos and since it took a bit to come back requests piled up and latency went way up. I have for now blocked those endpoints in the src.fedoraproject.org web interface. This brought everything back to normal. If you need to do those things, you can easily clone the git repo locally and do them.
This last week, I moved pagure.io (virtually) to the new datacenter. Unfortunately it didn't go as smoothly as I had hoped. All the data synced over in about 15minutes or so, but then I tried to test it before switching it live and it just wasn't allowing me to authenticate on git pushes. Finally the light bulb went on and I realized that pagure was checking for auth, but it wasn't 'pagure.io' yet because I hadn't updated dns. ;( It's always DNS. :) After that everything went fine. There were a few loose I had to fix up the next day: mirroring out was not working because we didn't have ssh outgoing listed as allowed. Uploading releases wasn't working due to a selinux labeling issue, and finally our s390x builders couldn't reach it because I forgot they needed to do that. Hopefully pagure.io is all happy now and I even gave it more resources in the new dc.
Monday the actual physical move happens. See: https://pagure.io/fedora-infrastructure/issue/12955 for more details. Mostly, folks shouldn't notice these machines moving. abrt submissions will be down, and download-cc-rdu01 will be down, but otherwise it should be a big nothing burger for most folks. Machines will move monday and we will work tuesday to reinstall/reconfigure things and bring it all back up.
There is going to be a short outage of our fedora.im and fedoraproject.org matrix servers. We are migrating to the new MAS setup (Matrix Authentication Server). This will allow clients to use things like element-x and also is a important step we wanted to complete before moving forward on deploying our own matrix servers.
A number of groups have already moved over to forge.fedoraproject.org from pagure.io. I really was hoping to move infrastructre, but haven't had the cycles yet. We do have the orgs created now and are planning on moving our docs over very soon. I don't know if we will move tickets before the end of the year or not, but we will see.
So, I committed myself to doing a docs pr/issue/something every day in December, and so far I am doing so! 6 days and 6 PR's and more tickets updated. Hopefully I can keep it up.
admin )
on 2025-12-06 16:30:00 UTC
There is heavy scraper activity cauing high load and slow load times on https://src.fedoraproject.org.
We are investigating and trying to mitigate it.
The issue was scrapers hitting /history/ and /blame/ endpoints recursively. We have at least for now blocked those endpoints. Please git clone locally if you …
admin )
on 2025-12-05 15:43:00 UTC
TL;DNR: The Fedora Linux 43 Election schedule has been extended. Voting will now take place from 15 December 2025 through 7 January 2026.
Due to unforeseen delays in the interview coordination process, we are adjusting the election timeline. To ensure all candidates have ample opportunity to present their platforms and the community has sufficient time to vote, the election period will now extend through the year-end holidays.
Please mark your calendars with the following new critical dates:
New Election ScheduleTransparency is an important value of the Fedora Project, and I want to provide context on why this shift was necessary. I recently returned from two weeks of bereavement leave on Wednesday, 3 December. During my absence, the coordination work required to collect and process nominee interviews for the Fedora Engineering Steering Committee (FESCo) did not occur as originally planned.
Consequently, we missed the window to launch the elections today, Friday, 5 December. Rather than rushing the process, we are opting to extend the timeline. This ensures that our candidates are properly featured and that the election remains fair and accessible to all voters, despite the holiday season overlap.
The official Fedora schedule calendar is being updated to reflect these changes shortly. Thank you for your patience and understanding.
The post Important Update: Fedora Linux 43 Election Schedule Extended appeared first on Fedora Community Blog.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infratructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: December 1 – December 5 2025
This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker
Updates of the team responsible for Fedora Forge deployment and customization.
Ticket tracker
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 49 appeared first on Fedora Community Blog.
remi )
on 2025-12-05 08:58:00 UTC
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.
RPMs of PHP version 8.5.1RC1 are available
RPMs of PHP version 8.4.16RC1 are available
RPMs of PHP version 8.3.29RC1 are available
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ PHP version 8.2 is now in security mode only, so no more RC will be released.
ℹ️ Installation: follow the wizard instructions.
ℹ️ Announcements:
Parallel installation of version 8.5 as Software Collection:
yum --enablerepo=remi-test install php85
Parallel installation of version 8.4 as Software Collection:
yum --enablerepo=remi-test install php84
Parallel installation of version 8.3 as Software Collection:
yum --enablerepo=remi-test install php83
Update of system version 8.5:
dnf module switch-to php:remi-8.5 dnf --enablerepo=remi-modular-test update php\*
Update of system version 8.4:
dnf module switch-to php:remi-8.4 dnf --enablerepo=remi-modular-test update php\*
Update of system version 8.3:
dnf module switch-to php:remi-8.3 dnf --enablerepo=remi-modular-test update php\*
ℹ️ Notice:
Software Collections (php83, php84, php85)
Base packages (php)
hrw )
on 2025-12-04 17:47:00 UTC
Wait, what? RISC-V? In ‘the diary of AArch64 porter’? WTH?
Yes, I started working on Fedora packaging for the 64-bit RISC-V architecture port.
About a week ago, one of my work colleagues asked me about my old post about speeding up Mock. We had a discussion, I pointed him to the Mock documentation, and gave some hints.
It turned out that he was working on RISC-V related changes to Fedora packages. As I had some spare cycles, I decided to take a look. And I sank…
The 64-bit RISC-V port of Fedora Linux is going quite well. There are over 90% of Fedora packages already built for that architecture. And there are several packages with the riscv64 specific changes, such as:
Note that these changes are temporary. There are people working on solving toolchain issues, languages are being bootstrapped (there was a review of Java changes earlier this week), patches are being integrated upstream and in Fedora, and so on.
There is the Fedora RISC-V tracker website showing the progress of the port:
This is a simple way to check what to work on. And there are several packages, not built yet due to use of “ExclusiveArch” setting in them.
The quick look at work needed reminded me of the 2012-2014 period, when I worked on the same stuff but for AArch64 ports (OpenEmbedded, Debian/Ubuntu, Fedora/RHEL). So I had a knowledge, I knew the tools and started working.
In the beginning, I went through entries in the tracker and tried to triage as many packages as possible, so it will be more visible which ones need work and which can be ignored (for now). The tracker went from seven to over eighty triaged packages in a few days.
Then I looked at changes done by current porters. Which usually meant David Abdurachmanov. I used his changes as a base for the changes needed for Fedora packaging, while trying to minimise the amount of them to the minimum required.
I did over twenty pull requests to Fedora packages during a week of work.
But which hardware did I use to run those hundreds of builds? Was it HiFive Premier P550? Or maybe Milk-V Titan or another RISC-V SBC?
Nope. I used my 80-core, Altra-based, AArch64 desktop to run all those builds. With the QEMU userspace helper.
You see, Mock allows to run builds for foreign architectures — all you need is
the proper qemu-user-static-* package and you are ready to go:
$ fedpkg mockbuild -r fedora-43-riscv64
You can extract the “fedora-43-riscv64” Mock config from the mock-riscv64-configs.patch hosted on Fedora RISC-V port forge. I hope that these configuration files may be found in the “mock-core-configs” in Fedora soon.
At some point I had 337 qemu-user-static-riscv processes running at same
time. And you know what? It was still faster than a native build on 64-bit
RISC-V hardware.
But, to be honest, I only compared a few builds, so it may be better with other builders. Fedora RISC-V Koji uses wide list of SBCs to build on:
Also note that using QEMU is not a solution for building a distribution. I used it only to check if package builds, and then scrap the results.
Will I continue working on the RISC-V port of Fedora Linux? Probably yes. And, at some point, I will move to integrating those changes into CentOS Stream 10.
For sure I do not want to invest in RISC-V hardware. Existing models are not worth the money (in my opinion), incoming ones are still old (RVA20/RVA22) and they are slow. Maybe in two, three years there will be something fast enough.
mbooth )
on 2025-12-04 15:30:00 UTC
This article explores how to turn Fedora machines into Spotify Connect devices.
Spotify Connect is a protocol and means by which one device can remotely control playback on another device over your home network or wifi.
If you have a device that supports Spotify Connect then no longer are you limited to listening to Spotify on your phone or computer – you can instead use your phone or computer to control music playback on your Spotify Connect compatible smart speaker, TV sound bar, car stereo, etc.
You can see what Spotify Connect devices are available on your network by hitting the 
button in an official Spotify client. It will show a list of devices on which you can play music remotely:
My problem is that I don’t have a smart speaker or other Spotify Connect compatible device here in my office capable of driving my big floor standing speakers. What I do have however, is an old stereo amplifier with spare inputs in the same rack as my server equipment:
The server machine in the bottom of that rack happens to have an integrated USB audio adapter so why not connect that to the AUX-in on the amplifier and teach the server how to stream music from Spotify?
Spotifyd is an open source Spotify client that you can run as a daemon and also supports the Spotify Connect protocol, which makes it show up as a device that can be controlled from the official Spotify client.
An RPM packaged version of Spotifyd can be found in my COPR repo at mbooth/spotifyd. It’s straightforward to enable the COPR repo and install it:
# dnf copr enable mbooth/spotifyd
# dnf install spotifyd
Spotifyd uses the Avahi mDNS for service discovery, which allows the official Spotify clients to find it on your network. So we need to make sure the mDNS port is open, as well as the port used by the Spotify Connect protocol. On a default installation of Fedora Server, it may be necessary to open both ports using the firewall-cmd command like this:
# firewall-cmd --permanent --add-service=mdns
# firewall-cmd --permanent --add-service=spotify-connect
# systemctl reload firewalld
Finally, enable and start the Spotifyd service in the normal systemd way:
# systemctl enable spotifyd.service
# systemctl start spotifyd.service
The server will now show up in official Spotify clients as a device named “spotifyd.” Choosing it from the list will begin playback on that device:
If you want to run Spotifyd on a Fedora Workstation install, or any setup where you have user sessions with the audio being managed by Wireplumber/Pipewire, then you will need to start it as a user service instead:
$ systemctl --user enable spotifyd.service
$ systemctl --user start spotifyd.service
The configuration file for Spotifyd can be found at /etc/spotifyd.conf where the first thing you probably want to do is customise the name that shows in the device list:
device_name = "Mat's Office"
All the configuration options are explained further in the upstream documentation.
For issues directly relating to the RPM packaging of Spotifyd or installation from my COPR repo, please file bugs at github.com/mbooth101/spotifyd-rpm/issues.
Planned Outage - pagure.io migration - 2025-12-03 21:00-23:00 UTC
We will be migrating pagure.io to a new network in our rdu3 datacenter. All services on pagure.io will be taken down, all data synced, and then services will be restored on the new server/datacenter. IP addresses for …
feborges )
on 2025-12-03 11:03:51 UTC
We are happy to announce that the GNOME Foundation is sponsoring an Outreachy project for the December 2025 Outreachy cohort.
Outreachy provides internships to people subject to systemic bias and impacted by underrepresentation in the tech industry where they are living.
Let’s welcome Malika Asman! Malika will be working with Lucas Baudin on improving document signing in Papers, our document viewer.
The new contributor will soon get their blogs added to Planet GNOME making it easy for the GNOME community to get to know them and the projects that they will be working on. We would like to also thank our mentor, Lucas for supporting Outreachy and helping new contributors enter our project.
If you have any questions, feel free to reply to this Discourse topic or message us privately at soc-admins@gnome.org.
czanik )
on 2025-12-02 13:05:05 UTC
A long-waited feature for syslog-ng, the Kafka source, is getting ready soon. The development is still in progress, but you can already try it, and it is worth the effort. How? Using the very same tool the syslog-ng testing and release process relies on.
From this blog you can learn how to download and patch syslog-ng git sources and build packages for popular RPM and DEB Linux distributions. Once you have installable packages, comes the fun part: getting the Kafka source working.
Read the rest at https://www.syslog-ng.com/community/b/blog/posts/how-to-test-the-syslog-ng-kafka-source-by-building-the-package-yourself
admin )
on 2025-12-02 12:00:00 UTC
The FreeIPA WebUI became new interface for freeipa
The post Test Day:2025-12-02 FreeIPA-WebUI Test Day appeared first on Fedora Community Blog.
t0xic0der )
on 2025-12-01 18:30:12 UTC
It is not every day that I get the opportunity to write about bringing back a project to life, but today, finally, happens to be one such day, and Fedora Badges happens to be one such project. It feels surreal to be finally opening up about this to folks apart from those who have been actively contributing to the project, given just how many highs and lows this initiative has seen in the past three years or so. While we have not yet reached the finishing line just yet, it is with great pleasure that I want to let you know that we are closer than ever to getting there. This post captures just what we have been up to all this time and where we plan on taking this initiative next from here on out. You have been warned, though - this post would be a long one, so I would not really blame you if an LLM tool helped you cut to the chase.
Back in early 2019, Clement Verna and Justin Wheeler kicked off the discussion of user stories for Fedora Badges from the perspective of various user personas. Requirements from stakeholders, including but not limited to artwork designers, project maintainers, badge administrators, project contributors, codebase developers, service users and community members were accounted for. This was done to identify and resolve technical blockers that slowed down the Fedora Badges development within the community, and that would, in turn, ensure that the project continues to be actively maintained even when the Community Linux Engineering (prev. Community Platform Engineering) team is occupied with responsibilities of (relatively speaking) greater importance and higher priority.
While the Fedora Design team had been (and still is) active in churning out artworks for the badges, the technical blockers limited the activities for which badges could be awarded. This necessitated an active participation with the Fedora Project leadership to both incentivise developer contribution to the technological stack as well as encourage individual contributors to seek engagement opportunities. While the discussions seemed to have become inactive and the mentioned project board seemed to have become inaccessible, the progress made then helped shape the path that we would choose next. For the curious bunch, the recording of the user stories discussions can be found on YouTube, featuring the likes of Clement Verna, Mairin Duffy, Michal Konecny and Mohan Boddu.
Around in late 2021, Matthew Miller kicked off the discussion on whether we would want to have Fedora Badges in Fedora Discussion. While there was some interest in this Discourse feature (~35% voters), a majority of folks (~53% voters) voted against the idea. Ryan Lerch remarked that the frontend did not seem to be a maintenance problem, and instead, the badges awarding backend service would need work. He further elaborated on the required changes to the backend architecture while gathering feedback on having Discourse as the frontend for the Fedora Badges stack. One of the suggestions that we incorporated was to mirror Fedora Badges assets on Fedora Discussion, thus organically including them in the conversations on the primary communication channels of the Fedora Project.
For what it is worth, moving over to Discourse definitely seemed to be the right approach here at that time, given just how letting it do the heavy lifting on the frontend side allowed us to be able to focus solely on the badges awarding backend service. As much as this was something that we wanted to work on, the Community Linux Engineering (prev. Community Platform Engineering) team had their hands full with maintaining the Fedora Infrastructure and Release Engineering responsibilities. Just like the previous attempts to rejuvenate Fedora Badges, this managed to move things further (with the inclusion of assets from Fedora Badges showing up on Fedora Discussion), but here again, there was only so much possible with the limited number of hands that we had on deck at that time.
Back in mid 2022, Vipul Siddharth sent out the call for participation to maintain the Fedora Badges project on behalf of the Community Linux Engineering (prev. Community Platform Engineering) team. With Kevin Fenzi's assistance, Erol Keskin and Sandro joined in the efforts to improve the state of the codebase for the badges awarding backend service. At around that time, I was looking into its technological stack myself, so Michal Konecny and I went ahead to propose the Advanced Reconnaissance Crew report on the Fedora Badges Revamp Project. The activities around the project were finally on the rise with the talks on translations related accolades and gathering contributor testimonials, before the Fedora Badges regular meetings were scheduled by Ellen O'Carroll and Justin Wheeler.
Calls were initially planned to be fortnightly in nature from December onwards. The year closed down with Matthew Miller's proposal on accolade progression using the Badge Path feature, before 2023 began with the Fedora Badges ARC investigation and the Fedora Badges Frontend Decision. Jefferson Oliveira and Bogomil Shopov, Marie Nordin and Emma Kidney also joined. With monthly meetings, a structure for engineering and design teams was made. We started moving our repos over to the Fedora Project's GitLab namespace, thereby using the features like Kanban, Epics, Milestones, etc., to our advantage. On the side, Smera Goel and Marie Nordin also kicked off the Outreachy Mentorship project on Fedora Badges artwork design with Chris Onoja Idoko and Roland Taylor.
From the start 2023, with the discussion around directory structures, slug formats, naming conventions and developer database, we had folks like Robert Wright and Onuralp Sezer join our star cast. Matthew Miller continued chipping away at unifying Fedora Badges and Fedora Discussion. Everything seemed to be progressing just right on all sides, but then we slowly started losing numbers in the second half of the year. Folks who were previously contributing actively either had to context switch temporarily or step away permanently. This had quite an impact on those who stayed back due to the accumulating work pressure. While I kept progressing with Sandro and Onuralp Sezer, it became virtually impossible to lead this besides working on the Git Forge Move Initiative and Pagure Exporter.
If you have been keeping the count, this marked the third time when the efforts seemed to have fizzled out again. It was beyond annoying that we could not get more people actively engaged (and hence, have the agency to pass the torch when needed) while we had the momentum. With the impending end of support date for Fedora Badges' host OS, Red Hat Enterprise Linux 7, approaching, Aurelien Bompard took the responsibility to port the technological stack from Pyramid to Flask, which kept the service going, but it felt horrible to have left things undone. Before we met for the last time (for a while) in June 2024, I gathered as many learnings as possible from all these endeavours so that whenever we ended up revisiting the project in the future, we would not make the same mistakes again.
While I could not make it to the Fedora Council as an elected representative, I managed to get elected to the Fedora Mindshare during the Fedora Linux 42 Release Cycle in May 2025. As contribution retention had been one of the notable issues I wanted to address during my tenure in the committee, I wanted to make the best use of my representation to push the Fedora Badges Revamp Project back on its feet. While the repositories were out in the open, I resisted the temptation of making any public announcements on Fedora Discussion as the Fedora Badges project was not the priority at the moment. That way, I could contribute to the project at the pace that suited me the best, and others could join in asynchronously too, while both they and I were busy with our respective commitments on the side.
After almost a year-long hiatus away, I decided to create a project board and throw my plans at it. Nothing serious and nothing pressuring - But something that everyone could explore around and contribute to whenever they felt like it. We had contributors like Shounak Dey, Aurelien Bompard, Xavier Lamien, and Michael Scherer rolling in gradually, with varied degrees of contribution extent. As I was mostly working on the revamp project for approximately 20% of my work hours, there was a certain peace in the experience. With almost 70 items on the project board, around 60 commits made and 90 files changed, things might actually end up working this time around. Scratch that - it will cross the finish line this time, I am sure of it, just lend me your hands with whatever you want or can to help with.
Enough of the contextual background for now, I suppose - let's move over to some groundwork. After all, there is nothing like getting awarded the Dancing With Toshio badge during Flock To Fedora 2025, which gets you wanting to work on the Fedora Badges Revamp Project, right? Here is a walkthrough for those four of you who want this badge for yourselves from the person themselves, Toshio Kuratomi.
Dancing With Toshio - 100% Achievement Walkthrough - Flock To Fedora 2025, Prague
The test deployment can be found on https://badges.gridhead.net/. This is set up on a Fedora Linux 42 QEMU x86 virtual machine with 8GiB virtual RAM, 4 virtual cores and reverse proxied through Cloudflare. If things look broken there, some work is likely being done at that time on the deployment, but if it stays down for longer than a couple of hours, please reach out to me at @t0xic0der:fedora.im .
If you have signed the Fedora Project Contributor Agreement, you should also be able to access the administration page after logging in using your staging Fedora Accounts credentials. As the database provided here is a snapshot copy of that of the production Fedora Badges deployment on 01 December 2025, people can feel free to play around with the test deployment to see what the service is capable of.
Here is a catalogue of images that show what the user interface looks like at the moment in the legacy deployment and what it would end up looking like down the road. Please note that the Fedora Badges Revamp Project is still in development, so these elements are not representative of the final quality. As always, we welcome all feedback, big or small, on #badges:fedoraproject.org Matrix chatroom.
Can be accessed through
https://badges.gridhead.net/
Progress of Landing Page as of 01 December 2025
Can be accessed through
https://badges.gridhead.net/assembly
Progress of Collection Page as of 01 December 2025
Can be accessed through
https://badges.gridhead.net/recently
Progress of Recently Page as of 01 December 2025
Can be accessed through
https://badges.gridhead.net/rankings/y/2025/m/11
Progress of Rankings Page as of 01 December 2025
Can be accessed through
https://badges.gridhead.net/rankings
Progress of Leaderboards Page as of 01 December 2025
Can be accessed through
https://badges.gridhead.net/identity/t0xic0der
Progress of Identity Page as of 01 December 2025
Can be accessed through
https://badges.gridhead.net/userpast/t0xic0der
Progress of Userpast Page as of 01 December 2025
Can be accessed through
https://badges.gridhead.net/accolade/dancing-with-toshio
Progress of Accolade Page as of 01 December 2025
While a bunch of user interface elements were overhauled to offer a refreshed look and enhanced feel, it did not make sense to have some of them around anymore. Please note that the Fedora Badges Revamp Project is still in development, so these elements are not representative of the final quality. As always, we welcome all feedback, big or small, on #badges:fedoraproject.org Matrix chatroom.
Supports lookup for users and badges
Native support for system theming preferences
Offering custom colours for custom personalities
Easy and effective control over service
One of the new features coming to Fedora Badges as a part of the Revamp Project is computing rarities for activated accolades. Inspired by video games, this provides users with the means to find accolades with varied rates of awarding, which, in turn, should help them find renewed avenues for contributions. Here are some glimpses of what the feature would end up looking like when implemented.
Progress of Accolade Rarities as of 01 December 2025
Apart from the shiny changes, there have also been a bunch of robust changes to the foundational aspects of the Tahrir and Tahrir API projects. Please visit the GitHub repositories associated with the Fedora Badges Revamp Project in order to learn more about them. Like always, please feel free to take the projects for a spin locally, and when ready, you can contribute to the upstream in any way possible.
If you are moved by the efforts put in by the folks since three years and/or are impressed by the aforementioned changes, now is the best time to begin contributing to the project if you have not already. We could honestly use all the help we could get and would provide the mentorship required for the contributors in ensuring that the project ends up crossing the finishing line satisfactorily.
I keep not having time to work on documentation, and it's so very important, so in an effort to see what progress I can make I am going to try and submit / merge at least one doc pull-request or close / comment on at least one docs ticket every day in december.
I'm going to concentrate on the infrastructure docs of course, but I might branch out into other areas where I could help.
When we moved our docs over to https://pagure.io/infra-docs-fpo/ we also created tickets to review all our standard operating procedures, and I can definitely work on cutting those down.
I also might miss some days, but then again I might do more on some other days, but I am going to try and do something every day in december. The most challenging days are likely to be in the next few weeks before the holdays as I am trying to get a datacenter move done and finish things up.
I'm just doing this myself, but if others would like to join in feel free to do so! I'd also love to have folks reviewing the pr's I submit also.
Should be fun!
Comments/replies:
Here is a short shell script to show last logins from SSH, XRDP, SUDO and Cockpit. In addition it show potential disk problems from S.M.A.R.T.
#!/bin/sh
default_since='-1days'
default_priority=info
read -r -d "" data << END_OF_DATA
System login ^ systemd-logind ^ info ^ ^ New session
XRDP ^ xrdp-sesman ^ debug ^ -5days ^ logged in|Received system login request
Cockpit login ^ cockpit-session ^ ^ ^ session opened
SUDO ^ sudo ^ ^ ^ session opened
Storage problems ^ smartd ^ ^ -1days ^ uncorrectable|unreadable
END_OF_DATA
trim() {
local s="$*"
# remove leading whitespace
s="${s#"${s%%[![:space:]]*}"}"
# remove trailing whitespace
s="${s%"${s##*[![:space:]]}"}"
printf '%s' "$s"
}
IFS="^"
echo "$data" | while read title slid priority since grep; do
effective_since=$default_since
effective_priority=$default_priority
[[ -n "$(trim $since)" ]] && effective_since="$(trim $since)"
[[ -n "$(trim $priority)" ]] && effective_priority="$(trim $priority)"
echo "$(trim $title)"
journalctl \
--no-pager \
--no-tail \
--since $effective_since \
--priority $effective_priority \
--reverse \
--grep "$(trim $grep)" \
-- SYSLOG_IDENTIFIER="$(trim $slid)"
echo; echo
doneI made it with the help of Cockpit Logs feature that shows the actual command being executed based on how you configure it.
The most important part of the script is the journalctl command. Everything else are defaults, the list of desired syslog identifiers and what to extract from them, and output formatting.
Hoy me acordé de lo útiles que son los atajos de Readline.
Estaba tecleando un comando larguísimo y me equivoqué al final. En lugar de borrar todo, usé Ctrl + A y Ctrl + E para saltar, y Ctrl + W para borrar palabras. ¡Chido! Readline es la librería que hace que Bash sea tan poderoso. Con sus atajos, editas líneas como un pro, sin mouse. La neta, una vez que los aprendes, no vives sin ellos.
Nota
Readline viene por defecto en Bash. Si usas otro shell, puede variar.
Consejo
Usa Ctrl + A y Ctrl + E para saltar rápido al inicio o fin.
Advertencia
Ctrl + U borra todo antes del cursor, ¡cuidado con no perder comandos largos! Lo bueno es que lo reestableces con Ctrl + Y.
Consejo
Ctrl + R es genial para encontrar comandos viejos. Escribe parte y presiona Ctrl + R varias veces.
¡PELIGRO!
Ctrl + C mata el proceso actual, útil pero no lo uses en medio de algo importante sin guardar.
Nota
Estos atajos funcionan en la mayoría de shells que usan Readline, como Bash.
Readline hace la terminal mucho más eficiente. Practica estos atajos y verás cómo acelera tu workflow. La neta, es una herramienta chingona.
Consejo
Para más, lee el man de readline o visita sitios como gnu.org.
Prá quem quer investir em criptomoedas, e tem estômago, e tem tempo para esperar, e sabe fazer, e sabe guardar por longo prazo, talvez agora seja um bom momento para começar pois o preço do Bitcoin caiu bastante nos últimos dias e parece estar retomando o crescimento (mas ninguém sabe do futuro).
Lembre-se que Bitcoin é ativo escasso, que tem expectativa de valorização (ou não), e diversos países já o usam como reserva de valor. Exatamente como ouro. Você pode não compreendê-lo, achar que é moda inútil, que gasta muita energia minerá-lo — exatamente como o ouro tem todas essas características —, mas fato inegável é que há um mercado mundial pujante que paga imediatamente e legalmente o valor em Reais que aparece na imagem por 1 bitcoin, se você o colocar à venda. Novamente, exatamente como é o ouro e outros metais e pedras preciosas, com a única diferença de que o Bitcoin só precisa da Internet para existir e ser transportado.
Bitcoin em si jamais vai substituir dinheiro, exatamente da mesma forma como ouro não é aceito no caixa do supermercado — precisa ser vendido/convertido antes de usar. Outras criptomoedas têm dinâmicas, propostas e finalidades diferentes, algumas muito interessantes. Mas acima de tudo você deve evitar as memecoins, pois não tem valor intrínseco nem utilidade nenhuma.
Colecionar ou guardar relógios, arte, jóias, selos ou criptomoedas são práticas muito parecidas do ponto de vista psicológico. Todos ativam algum valor diferente no imaginário humano. Status por beleza, status intelectual pelo valor histórico ou status por status mesmo. Nada disso coloca comida na mesa, não te salva de um cataclisma apocalíptico nem dá paz de espírito. Mas são todas coisas que a psique humana valoriza de alguma forma. Vai entender.
RC5 was GOLD, so version 8.5.0 GA was just released, at the planned date.
A great thanks to Volker Dusch, Daniel Scherzer and Pierrick Charron, our Release Managers, to all developers who have contributed to this new, long-awaited version of PHP, and to all testers of the RC versions who have allowed us to deliver a good-quality version.
RPMs are available in the php:remi-8.5 module for Fedora and Enterprise Linux ≥ 8 and as Software Collection in the remi-safe repository.
Read the PHP 8.5.0 Release Announcement and its Addendum for new features and detailed description.
For memory, this is the result of 6 months of work for me to provide these packages, starting in July for Software Collections of alpha versions, in September for module streams of RC versions, and also a lot of work on extensions to provide a mostly full PHP 8.5 stack.
Installation: read the Repository configuration and choose installation mode, or follow the Configuration Wizard instructions.
Replacement of default PHP by version 8.5 installation (simplest):
Fedora (dnf 5):
dnf install https://rpms.remirepo.net/enterprise/remi-release-$(rpm -E %fedora).rpm dnf module reset php dnf module enable php:remi-8.5 dnf install php
Enterprise Linux (dnf 4):
dnf install https://rpms.remirepo.net/enterprise/remi-release-$(rpm -E %rhel).rpm dnf module switch-to php:remi-8.5/common
Parallel installation of version 8.5 as Software Collection (recommended for tests):
yum install php85
To be noticed :
Information, read:
Base packages (php)
Software Collections (php85)
We're updating Copr servers to F43
This outage impacts the copr-frontend and the copr-backend.
Getting a start on your holiday shopping this weekend? Give the gift of knowledge to yourself or the people you love! Use promo code save50 at pragprog.com through December 1 to save 50% on every ebook title (except The Pragmatic Programmers).
Not sure what you should get? If you don’t have a copy of Program Management for Open Source Projects, now’s a great time to get one. I’ve been a technical reviewer for a few other books as well:
I’ve read (or have in my stack to read) other books as well:
With hundreds of titles to choose from, there’s something for you and the techies in your life.
The post Pragmatic Bookshelf half-off sale! appeared first on Duck Alignment Academy.
renich )
on 2025-11-25 16:00:00 UTC
Hoy me acordé cuando un compa me pidió ayuda con su laptop llena de virus y lentitud. La neta, Windows es como una novia celosa: te controla todo y te deja sin libertad. Pero GNU/Linux es abierto, gratis y bien chingón. Vamos a migrar paso a paso para que no te pierdas en el camino.
Antes de empezar, guarda todo lo importante. Windows te va a dejar tirado para variar, así que no seas gacho contigo mismo y respalda tus chingaderas.
Advertencia
¡Aguas! Si te equivocas en el particionado, puedes borrar todo tu disco. Si no tienes respaldo, ya valió madres.
Windows es tan tramposo que cuando le das "Apagar", en realidad hiberna para prender más rápido. Esto deja los discos duros "bloqueados" y Linux no podrá escribir en ellos.
Consejo
Si tu compu es nueva, entra al BIOS/UEFI y desactiva el Secure Boot si te da lata, aunque Fedora suele jalar bien con él activado.
GNU/Linux tiene distros para todos los gustos. Para principiantes, elige una estable y con buena comunidad, no te compliques.
Arch Linux o Gentoo son para masoquistas o gente muy pro; la neta, evítalas si vas empezando o vas a terminar odiando la vida.
Crea USB booteable: Descarga la ISO de Fedora desde fedoraproject.org. Usa Rufus o Etcher para grabarla en una USB de al menos 8GB.
Bootea desde USB: Reinicia la PC, entra al BIOS/UEFI (teclas como F2, F10, Del) y cambia el orden de boot para priorizar la USB.
Consejo
Antes de instalar, usa el modo "Live" un rato. Checa que jale el WiFi, el sonido y el Bluetooth. Si todo está suave, dale instalar.
Instala: El instalador gráfico te guía. Selecciona idioma, zona horaria. Para particionado: * Borra Windows si no lo necesitas: asigna todo el espacio a / (raíz). ¡A la goma con Microsoft! * Dual-boot: Crea particiones separadas para Windows y Linux. Usa al menos 50GB para Linux, más si juegas.
Usuario: Crea un usuario normal, no uses root. Elige una contraseña fuerte. Configura sudo para permisos elevados.
Post-instalación: Actualiza el sistema. Abre la terminal y dale gas:
sudo dnf update
Fedora es muy purista con el software libre. Eso está chido, pero significa que "out of the box" no vas a poder ver videos MP4 ni escuchar MP3. No mames, ¿verdad? Arreglémoslo.
Este repositorio comunitario tiene todo lo "propietario" que Fedora no incluye (codecs, drivers de NVIDIA, Steam).
sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
Para que no te quedes sin ver tus series o escuchar rolas:
sudo dnf groupupdate multimedia --setop="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin
sudo dnf groupupdate sound-and-video
Si tienes tarjeta gráfica NVIDIA, esto es obligatorio para no andar con gráficos lentos:
sudo dnf install akmod-nvidia
Para instalar Spotify, Discord, Zoom y esas cosas privativas, usa Flathub. Fedora ya trae soporte Flatpak, solo añade el repo:
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
Busca equivalentes libres para tus apps favoritas.
La comunidad de GNU/Linux es muy solidaria. Aquí formas de pedir ayuda:
Migrar toma tiempo, pero vale la pena por la estabilidad y libertad. GNU/Linux te da control total sobre tu PC. Únete a comunidades como Reddit r/linux, IRC, Matrix o LUGs para ayuda. Una vez que migras, no vuelves. ¿No crees?
It’s finally here. We have an end date for OpenID in Fedora. The date is 1st May 2026. You can see it on the banner on https://id.fedoraproject.org/openid and it will be shown to you every time when trying to authenticate with OpenID. The date 1st May 2026 should give anybody still using OpenID authentication enough time to migrate to OpenID Connect.
We started our move to OpenID Connect and away from old OpenID authentication 4 years ago. This was a long road with plenty of obstacles on the way. We first ported all apps we own in Fedora Infrastructure to OpenID Connect. That took time, but we had at least control over these applications.
After porting all our applications we started to look at the application using OpenID authentication outside of Fedora ecosystem. This proved to be really difficult as those clients don’t need to register with Fedora Authentication System.
After some failures to contact the projects that we at least identified to use OpenID in Fedora, we decided that the best course of option is to separate the OpenID authentication system (the service that is providing it is called Ipsilon, which we want to decommission as well). I spent the last two months working on separating the OpenID authentication from OpenID Connect and SAML2. You can see the result on https://id.fedoraproject.org/openid.
This will now allow us to replace Ipsilon for both OpenID Connect and SAML2 and as most of the separation logic is in proxies, we should have no issue to reuse that for the new solution. This should resolve plenty of issues we are experiencing with current authentication system and let us remove one service from the portfolio of services we own in Fedora Infrastructure. We are looking forward to brighter future!
The post End of OpenID in Fedora appeared first on Fedora Community Blog.
renich )
on 2025-11-24 16:00:00 UTC
¿Quieres aprender Vim?
Vim es un editor de texto muy perro que ha estado por ahí desde hace décadas. La neta, al principio parece complicado, pero una vez que lo dominas, ¡tu productividad se dispara! En este artículo, te cuento lo básico de Vim y unos consejos útiles para que empieces.
Nota
Vim es una mejora de Vi, que viene en casi todos los sistemas Unix-like. Si no lo tienes, instálalo con dnf -y install vim en Fedora o CentOS Stream (como root).
Vim tiene varios modos, cada uno para algo específico:
Consejo
Presiona Esc cuando quieras para volver a Normal. ¡Es tu salvavidas!
Aquí te dejo los comandos esenciales para arrancar:
Advertencia
¡Cuidado! Vim distingue mayúsculas. :Q no es :q.
¡PELIGRO!
No edites archivos importantes sin respaldos. Vim no guarda automático.
Nota
Practica con vimtutor, el tutorial que viene con Vim. Solo escribe vimtutor.
Vim no es solo un editor, ¡es una herramienta que se apega a tu workflow! Con práctica, estos comandos serán instintivos. La neta, paciencia es lo que necesitas para aprenderlo.
Consejo
Únete a comunidades como el subreddit de Vim o foros para compartir tips.
OK, Zoo might slightly be overstating it.
Let's start at the beginning.
In March 2019, we moved from Barcelona into the countryside.
While I grew up in a village and studied in a small town, my recent life I spend in London and Barcelona.
It was also my first house, farmhouse even, having lived in flats most of my life.
So clearly, I thought about how I could complete my cosplaying of country life.
"A dog and a cat would be nice at some point"
A couple of months later…
I remembered that I saw a bigger cat going through or garden, which might have been pregnant.
She picked up most of the litter, but left Cheeky (black one) and Foggy (white one) back.
We obviously bought all the toys, feeding station, and a cat flap once they got a little bigger.
When they were small, they climbed on top of me and my shoulders while watching telly.
Now they are more attached to my partner and just tolerate me.
I thought: "Two cats, that's great. At least they can play together. Maybe a dog at some point".
A couple of months later…
I was in Barcelona on a Friday for Future protest when my partner called me. She had found an injured dog in the road and naturally picked him up. It took me a while to get back with train and bicycle. When I arrived, I was greeted by a sad and hurt beagle.
He might have been attacked by other dogs or wild animals. He was in a pretty bad shape.
We got him fixed up and also removed a growth on his leg.
He was chipped, but the chip was not registered.
I came up with the name Hoover, as he had a cone of shame for a while, and he did look like a vacuum cleaner when doing the sniffing around. He reacted directly to the (new) name.
After a while, we wanted to register him with the town. That's when we learned about the previous owner. He was known to the town hall, and apparently not great with animals, they would have preferred not to give the dog back.
In Spain, if you find a dog and then return it to the owner, the owner has to pay for any vet expenses. Since we had paid exceeding 1000 Euro by now, the owner decided that he didn't want Hoover back (his original name was Bruno).
He got used to us so quickly, and is now the most cuddly dog you can imagine.
He gets along with the cats well.
Me: "This is great. A dog and two cats. Pet achievement reached"
Quite a few months later…
 |
When we are travelling, we leave our dogs at a local dog hostel. We are friends with the owner, and she thought of us when she came across an abandoned dog.
The dog was called Mia at the time, which is a very common name. We renamed her Yuki after asking Reddit for suggestions.
She was super undernourished and needed a good clean.
She didn't really get along with me, or maybe men in general. She did like Hoover and my partner. The cats, not so much.
So obviously, we cared for her, fed her well, and made sure she felt at home with us.
Me: "OK, two dogs, two cats. This is perfect."
A few weeks later…
She was gaining weight, which was great. At some point on one of our walks, noticing Yuki's size, I said to my partner: "I think she is pregnant".
A trip to the vet and an X-ray confirmed this. The same vet hadn't noticed anything just two weeks ago. Hidden in Yuki's tummy were eight little puppies.
We had to feed them with bottles, as Yuki was too undernourished to provide for them.
Sadly, three of them didn't make it. I am sure we did something wrong.
I now also have a lot more respect for parents. The bottle feeding continued for two months, and I don't think I slept at all during this time. My brain was not really functioning when at work.
One, we gave to my partner's parent: Seven.
One went to a village nearby with lots of space to roam: Lola.
In what turned out to be a big mistake … which I probably would make again, we kept three of them: Neo, Baty, and Crash.
A few months later…
I am just kidding.
We did temporarily take in a cat, which sadly died in our care. I was really fond of Charlie.
And we sometimes host other dogs for a while.
For all other pets, we encounter, we have found the original owners.
As I said in the beginning, that "zoo" is overstating it a bit, and that is true. We do have constant visits from other animals in our garden: other cats, birds, snakes, badgers, foxes, rabbits, mice, rats, martens, …
If I learned anything from all of this, then it is that I am not good at saying no to an animal in need. Since we have a crowded house already, I have to be better at it.
.jpg "The gang chilling")
oaf357 )
on 2025-11-24 05:00:00 UTC
siosm )
on 2025-11-23 23:00:00 UTC
There have been a few discussions about what Flathub should do to push developers to maintain their apps on the latest versions of the published runtimes. But most of those lack important details around how this would actually happen. I will not discuss in this post the technical means that are already in place to help developers keep their dependencies up to date. See the Flathub Safety: A Layered Approach from Source to User blog post instead.
The main thing to have in mind is that Flathub is not a commercial entity like other app stores. Right now, developers that put their apps on Flathub are (in the vast majority) not paid to do so and most apps are under an open source license.
So any discussion that starts with “developers should update to the latest runtime or have their apps removed” directly contradicts the social contract here (which is also in the terms of most open source licenses): You get something for free so don’t go around making demands unless you want to look like a jerk. We are not going to persuade overworked and generally volunteer developers to update their apps by putting pressure on them to do more work. It’s counter productive.
With that out of the way, how do we gently push developers to keep their apps up to date and using the latest runtime? Well, we can pay them. Flathub wants to setup a way to offer payments for applications but unfortunately it’s not ready yet. So in the meantime, the best option is to donate to the projects or developers working on those applications.
And make it very easy for users to do so.
Now we are in luck, this is exactly what some folks have been working on recently. Bazaar is a Flathub first app store that makes it really easy to donate to the apps that you have installed.
But we also need to make sure that the developers actually have something set up to get donations.
And this is were the flatpak-tracker project comes in. This project looks for the donation links in a collection of Flatpaks and checks if there is one and if the website is still up. If it’s not, it opens issues in the repo for tracking and fixing. It also checks if those apps are using the latest runtimes and open issues for that as well (FreeDesktop, GNOME, KDE).
If you want to help, you can take a look at this repo for apps that you use and see if things needs to be fixed. Then engage and suggest fixes upstream. Some of this work does not require complex technical skills so it’s a really good way to start contributing. This is probably one of the most direct way to enable developers to receive money from their users, via donations.
Updating the runtime used by an app usually requires more work and more testing, but it’s a great way to get started and to contribute to your favorite apps. And this is not just about Flathub: updating a Qt5 app to run with Qt6, or a GNOME 48 app to 49, will help everyone using the app.
We want to build an App Store that is respectful of the time developers put into developing, submitting, publishing, testing and maintaining their apps.
We don’t want to replicate the predatory model of other app stores.
Will some apps be out of date sometimes? Probably, but I would rather have a sustainable community than an exploiting one.
Just a quick post to note my blogiversery.
22 years ago in 2003 I posted my first entry here.
Back then I was running a very new version of something called wordpress, then switched to wordpress-mu, then back to wordpress when multiuser came back into core wordpress and then finally to nikola.
It may be that blogs are out of vouge these days, but I still find them nice for longer thoughts that seem way too busy for social media.
renich )
on 2025-11-23 18:00:00 UTC
¡Heytale! ¿Quieres saber sobre Podman?
Podman es un motor de contenedores sin daemon para desarrollar, gestionar y ejecutar contenedores OCI en Linux. ¡A diferencia de Docker, no necesita un daemon corriendo, lo que lo hace más seguro y eficiente! Es compatible con imágenes Docker y se integra con Kubernetes para despliegues en la nube.
Nota
Podman se ejecuta sin root de forma predeterminada, mejorando la seguridad en comparación con Docker.
Advertencia
Mientras que Podman soporta contenedores sin root, algunas características avanzadas como la integración con systemd pueden requerir acceso root en el contenedor.
¡Vamos a crear un contenedor de CentOS Stream 10 con systemd habilitado y PostgreSQL instalado! Asegúrate de tener Podman instalado.
# podman con systemd
## iniciar contenedor
podman run -di --name cs10-systemd centos:stream10
## instalar systemd y postgresql
podman exec cs10-systemd dnf -y install systemd postgresql-server sudo
## limpiar
podman exec cs10-systemd dnf clean all
## commitear a imagen
podman commit -s cs10-systemd cs10-systemd
## borrar contenedor
podman rm -f cs10-systemd
## correr con systemd
podman run -dt -p 127.0.0.1:5432:5432 --name=cs10-systemd localhost/cs10-systemd /usr/sbin/init
## configurar postgresql
podman exec cs10-systemd postgresql-setup --initdb
## habilitar e iniciar postgresql
podman exec cs10-systemd systemctl enable --now postgresql
## crear usuario y db
podman exec cs10-systemd sudo -u postgres createuser -dRS --no-replication renich
podman exec cs10-systemd sudo -u postgres createdb renich
podman exec cs10-systemd sudo -u postgres psql -c "ALTER USER renich WITH PASSWORD 'MySuperPass';"
## crear pg_hba.conf
cat << EOF > pg_hba.conf
local all all peer
host all renich 127.0.0.1/32 scram-sha-256
host all renich ::1/128 scram-sha-256
EOF
podman cp pg_hba.conf cs10-systemd:/var/lib/pgsql/data/pg_hba.conf
rm -f pg_hba.conf
## verificar
podman exec cs10-systemd systemctl restart postgresql
podman exec cs10-systemd systemctl status postgresql
PGPASSWORD='MySuperPass' psql -h 127.0.0.1 -l
# limpieza
podman rm -f cs10-systemd
podman rmi cs10-systemd
Consejo
Siempre limpia los contenedores e imágenes después de probar para ahorrar espacio en disco.
¡Este ejemplo muestra cómo podman facilita contenedores avanzados con systemd y PostgreSQL, perfecto para desarrollo y producción!
Another busy week in fedora infrastructure. Here's my attempt at a recap of the more interesting items.
We have a vHMC vm. This is a virtual Hardware Management Console for our power10 servers. You need one of these to do anything reasonably complex on the servers. I had initially set it up on one of our virthosts just as a qemu raw image, since thats the way the appliance is shipped. But that was making the root filesystem on that server be close to full, so I moved it to a logical volume like all our other vm's. However, after I did that, it started getting high packet loss talking to the servers. Nothing at all should have changed network wise, and indeed, it was the only thing seeing this problem. The virthost, all the other vm's on it, they were all fine. I rebooted it a bunch, tried changing things with no luck.
Then, we had our mass update/reboot outage thursday. After rebooting that virthost, everything was back to normal with the vHMC. Very strange. I hate problems that just go away where you don't know what actually caused them, but at least for now the vHMC is back to normal.
We did a mass update/reboot cycle this last week. We wanted to:
Update all the RHEL9 instances to 9.7 which just came out
Update all the RHEL10 instances to 10.1 which just came out.
Update all the fedora builders from f42 to f43
Update all our proxies from f42 to f43
Update a few other fedora instances from f42 to f43
This overall went pretty smoothly and everything should be updated and working now. Please do file an issue if you see anything amiss (as always).
The new anubis is working I think quite well to keep the ai scrapers at bay now. It is causing some problems for some clients however. It's more likely to find a client that has no user-agent or accept header might be a bot. So, if you are running some client that hits our infra and are seeing anubis challenges, you should adjust your client to send a user-agent and accept header and see if that gets you working again.
The last thing we are seeing thats still anoying is something I thought was ai scraping, but now I am not sure the motivation of it, but here's what I am seeing:
LOTS of requests from a large amount of ip's
fetching the same files
all under forks/$someuser/$popularpackage/ (so forks/kevin/kernel or the like)
passing anubis challenges
My guess is that these may be some browser add on/botnet where they don't care about the challenge, but why fetch the same commit 400 times? Why hit the same forked project for millions of hits over 8 or so hours?
If this is a scraper, it's a very unfit one, gathering the same content over and over and never moving on. Perhaps it's just broken and looping?
In any case currently the fix seems to be just to block requests to those forks, but of course that means the user who's fork it is cannot access them. ;( Will try and come up with a better solution.
This datacenter move is still planned to happen. :) I was waiting for a new machine to migrate things to, but it's stuck in process, so instead I just repurposed for now a older server that we still had around. I've setup a new stg.pagure.io on it and copied all the staging data to it, it seems to be working as expected, but I haven't moved it in dns yet.
I then setup a new pagure.io there and am copying data to it now.
The current plan if all goes well is to have an outage and move pagure.io over on december 3rd.
Then, on December 8th, the rest of our RDU2-CC hardware will be powered off and moved. The rest of the items we have there shouldn't be very impactful to users and contributors. download-cc-rdu01 will be down, but we have a bunch of other download servers. Some proxies will be down, but we have a bunch of other proxy servers. After stuff comes back up on the 8th or 9th we will bring things back on line.
Next week is the US Thanksgiving holiday (on thursday). We get thursday and friday as holidays at Red Hat, and I am taking the rest of the week off too. So, I might be around some in community spaces, but will not be attending any meetings or doing things I don't want to.
As always, comment on mastodon: https://fosstodon.org/@nirik/115595437083693195
admin )
on 2025-11-21 15:38:20 UTC
You attended the F43 Virtual Release Party!
This week, I enjoyed the blog about chat programming, and coding at work, which is probably related.
Hybrid workers are putting in 90 fewer minutes of work on Fridays – and an overall shift toward custom schedules could be undercutting collaboration - Friday is always different in Spain.
Thermostats - Tuning team temperature - first rule of leadership: don't panic
Feedback doesn't scale - this is mostly about bigger teams
Managers, Don’t Bet on Your People’s Ideas! - bet on the people
AI World Clocks - some are actually good, the others are funny.
A Month of Chat-Oriented Programming - I can relate to this. I have been shouting at Claude this week.
run-ancient-unix - Version 1 on a fake PDP-11!
Coding at work (after a decade away). - "Dubious return-on-effort of manager coding"
The Pulse: Cloudflare takes down half the internet – but shares a great postmortem - good summary of the whole episode
When Bill Gates Yelled At Me About Climate Change - he is weird.
Ban on veggie ‘burgers’: plant-based products may lose meaty names in UK under EU law - "There’s no genuine, citizen-driven demand to ban veggie burgers or sausages – just a meat industry push to protect its profit margins from a rising tide of dietary change."
Why have deaths and serious injuries in collisions involving HGVs being driven in London halved since 2019? - What? You can actually improve things?
Zork is now open source - nice.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infratructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 17 November – 21 November 2025
This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker
Updates of the team responsible for Fedora Forge deployment and customization.
Ticket tracker
Minor update of FMN from 3.3.0 to 3.4.0
Minor update of FASJSON from 1.6.0 to 1.7.0
Minor update of Noggin from 1.10.0 to 1.11.0
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 47 appeared first on Fedora Community Blog.
We will be updating and rebooting various servers. Services will be up or down during the outage window.
bex )
on 2025-11-20 15:00:00 UTC
If you’re wearing more than one hat on your head something is probably wrong. In open source, this can feel like running a haberdashery, with a focus on juggling roles and responsibilities that sometimes conflict, instead of contributing. In October, I attended the first OpenSSL Conference and got to see some amazing talks and, more importantly, meet some truly wonderful people and catch up with friends.
Disclaimer: I work at Microsoft on upstream Linux in Azure and was formerly at Red Hat. These reflections draw on roles I’ve held in various communities and at various companies. These are personal observations and opinions.
Let’s start by defining a hat. This is a situation where you are in a formalized role, often charged with representing a specific perspective, team, or entity. The formalization is critical. There is a difference between a contributor saying something, even one who is active in many areas of the project, and the founder, a maintainer, or the project leader saying it. That said, you are always you, regardless of whether you have one hat, a million hats, or none. You can’t be a jerk in a forum and then expect everyone to ignore that when you show up at a conference. Hats don’t change who you are.
During a few of the panels, several panelists were trying to represent multiple points of view. They participate or have participated in multiple ways, for example on behalf of an employer and out of personal interest. One speaker has a collection of colored berets they take with them onto the stage. Over the course of their comments they change the hat on their head to talk to different, and quite often all, sides of a question. I want to be clear, I am not calling this person out. This is the situation they feel like they are in.
I empathize with them because I have been in this same situation. I have participated in the Fedora community as an individually motivated contributor, the Fedora Community Action and Impact Coordinator (a paid role provided to the community by Red Hat), and as the representative of Red Hat discussing what Red Hat thinks. Thankfully, I never did them all at once, just two at a time. I felt like I was walking a tightrope. Stressful. I didn’t want my personal opinion to be taken as the “voice” of the project or of Red Hat.
This experience was formative and helped me navigate this the next time it came up when I became Red Hat’s representative to the CentOS Project Board. My predecessor in the role had been a long-time individual contributor and was serving as the Red Hat representative. They struggled with the hats game. The first thing I was told was that the hat switching was tough to follow and people were often unsure if they were hearing “the voice of Red Hat” or the “voice of the person.” I resolved to not further this. I made the decision that I would only ever speak as “the voice of Red Hat.”1 It would be clear and unambiguous.
But, you may be thinking, what if you, bex, really have something you personally want to say. It did happen and what I did was leverage the power of patience and friendship.
Patience was in the form of waiting to see how a conversation developed. I am very rarely the smartest person in the room. I often found that someone would propose the exact thing I was thinking of, sometimes even better or more nuanced than I would have.
On the rare occasions that didn’t happen I would backchannel one of my friends in the room and ask them to consider saying what I thought. The act of asking was useful for two reasons. One, it was a filter for things that may not have been useful to begin with. Two, if someone was uneasy with sharing my views, their feedback was often useful in helping me better understand the situation.
In the worst case, if I didn’t agree with their feedback, I could ask someone else. Alternatively, I could step back and examine what was motivating me so strongly. Usually that reflection revealed this was a matter of personal preference or style that wouldn’t affect the outcome in the long term. It was always possible that I’d hit an edge case where I genuinely needed a second hat.
I recognize this is not an easy choice to make. I had the privilege of not having to give up an existing role to make this decision. However, I believe that in most cases when you do have to give up one role for another, you’re better off not trying to play both parts. You’re likely blocking or impeding the person who took on the role you gave up. If you have advice a quiet sidebar with them will go further than potentially forcing them into public conversations that don’t need to be public. Your successor may do things differently, you should be ok with that. And remember what I wrote above, you’re not being silenced.
So when do multiple hats tend to happen? Here are some common causes of hat wearing:
This raises the question of which hat you should wear if you feel like you have more than one option. Here’s how I decide which hat to wear:
Some will argue that in smaller projects or early-stage efforts the flexibility of multiple roles is a feature, not a bug, allowing for rapid adaptation before formal structures are needed. That’s fair during a “forming” phase - but it shouldn’t become permanent. As the project matures, work to clarify roles and expectations so contributors can focus on one hat at a time.
As a maintainer or project leader, when you find people wearing multiple hats, it’s a warning flag. Something isn’t going right. Figure it out before the complexity becomes unmanageable.
In the case of this role it meant I spent a lot of time not saying much as Red Hat didn’t have opinions on many community issues preferring to see the community make its own decisions. Honestly, I probably spent more time explaining why I wasn’t talking than actually talking. ↩
RPMs of PHP version 8.4.14 are available in the remi-modular repository for Fedora ≥ 41 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.3.27 are available in the remi-modular repository for Fedora ≥ 41 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ There is no security fix this month, so no update for versions 8.1.33 and 8.2.29.
These versions are also available as Software Collections in the remi-safe repository.
Version announcements:
ℹ️ Installation: use the Configuration Wizard and choose your version and installation mode.
Replacement of default PHP by version 8.4 installation (simplest):
dnf module switch-to php:remi-8.4/common
Parallel installation of version 8.4 as Software Collection
yum install php84
Replacement of default PHP by version 8.3 installation (simplest):
dnf module switch-to php:remi-8.3/common
Parallel installation of version 8.3 as Software Collection
yum install php83
And soon in the official updates:
⚠️ To be noticed :
ℹ️ Information:
Base packages (php)
Software Collections (php83 / php84)
RPMs of PHP version 8.4.15 are available in the remi-modular repository for Fedora ≥ 41 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.3.28 are available in the remi-modular repository for Fedora ≥ 41 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ There is no security fix this month, so no update for versions 8.1.33 and 8.2.29.
These versions are also available as Software Collections in the remi-safe repository.
⚠️ These versions introduce a regression in MySQL connection when using an IPv6 address enclosed in square brackets. See the report #20528. A fix is under review and will be released soon.
Version announcements:
ℹ️ Installation: use the Configuration Wizard and choose your version and installation mode.
Replacement of default PHP by version 8.4 installation (simplest):
dnf module switch-to php:remi-8.4/common
Parallel installation of version 8.4 as Software Collection
yum install php84
Replacement of default PHP by version 8.3 installation (simplest):
dnf module switch-to php:remi-8.3/common
Parallel installation of version 8.3 as Software Collection
yum install php83
And soon in the official updates:
⚠️ To be noticed :
ℹ️ Information:
Base packages (php)
Software Collections (php83 / php84)
admin )
on 2025-11-20 12:00:00 UTC
Hi,
I’m Jef, the Fedora Project Leader.
As FPL I believe Fedora needs to be part of a healthy flatpak ecosystem. I’d like to share my journey in working towards that over the last few months with you all, and include some of the insights that I’ve gained. I hope by sharing this with you it will encourage those who share my belief to join with me in the journey to take us to a better future for Fedora and the entire ecosystem.
First, my immediate goal is to get the Fedora ChangeProposal that was submitted to make Flathub the default remote for some of the Atomic desktops accepted on reproposal. I believe implementing the idea expressed in that ChangeProposal is the best available option for the Atomic desktops that help us down the path I want to see us walking together.
There seems to be wide appeal from both the maintainers of specific Fedora outputs, and the subset of Fedora users of those desktop outputs, that using Flathub is the best tradeoff available for the defaults. I am explicitly not in favor of shuttering the Fedora flatpaks, but I do see value in changing the default remote, where it is reasonable and desirable to do so. I continue to be sensitive to the idea that Fedora Flatpaks can exist because it is delivering value to a subset of users, even when it’s not the default remote but still targeting an overlapping set of applications serving different use cases. I don’t view this as a zero-sum situation; the important discussion right now is about what the defaults should be for specific Fedora outputs.
There is a history of change proposals being tabled and then coming back in the next cycle after some of the technical concerns were addressed. There is nothing precedent-setting in how the Fedora Engineering Steering Committee handled this situation. Part of getting to the immediate goal, from my point of view, was doing the due diligence on some of the concerns raised in the FESCo discussion leading to the decision to table the proposal in the last release. So in an effort to get things in shape for a successful outcome for the reproposal, I took it on myself to do some of the work to understand the technical concerns around the corresponding source requirements of the GPL and LGPL licenses.
I felt like we were making some good progress in the Fedora discussion forums back in July. In particular, Timothee was a great help and wrote up an entirely new document on how to get corresponding sources for applications built in flathub’s infrastructure. That discussion and the resulting documentation output showed great progress in bringing the signal to noise ratio up and addressing the concerns raised in the FESCo discussion. In fact, this was a critical part of the talk I gave at GUADEC. People came up to me after that talk and said they weren’t aware of that extension that Timothee documented. We were making some really great progress out in the open and setting a stage for a successful reproposal in the next Fedora cycle.
Okay, that’s all context intended to help you, dear reader, understand where my head is at. Hopefully we can all agree my efforts were aligned with the goal leading up to late July. The next part gets a bit harder to talk about, and involves a discussion of communication fumbles, which is not a fun topic.
Unfortunately, at GUADEC I found a different problem, one I wasn’t expecting to find. Luckily, I was able to communicate face to face with people involved and they confirmed my findings, committed on the spot to get it fixed, and we had a discussion on how to proceed. This started an embargo period where I couldn’t participate in the public narrative work in the community I lead. That embargo ended up being nearly 3 months. I don’t think any of us who spoke in person that day at GUADEC had any expectation that the embargo would last so long.
Through all of this, I was in communication with Rob McQueen, VP of the Gnome Foundation, and one of the Flathub founders, checking in periodically on when it was reasonable for me to start talking publicly again. It seems that the people involved in resolving the issues took it so seriously that they not only addressed the deficiencies I found -missing files- but committed to creating significant tooling changes to help prevent it from happening again. Some characterized that work as “busting their asses.” That’s great, especially considering much of that work is probably volunteer effort. Taking the initiative to solve not just the immediate problem, but building tooling to help prevent it is a fantastic commitment, and in line with what I would expect from the volunteers in the Fedora community itself. We’re more aligned than we realize I think.
What I’ve learned from this is there’s a balance with regard to embargos that must be struck. Thinking about it, we might have been better served if we had agreed to scope the embargo at the outset and then adjusted later with a discussion on extending the time further, that also gave me visibility into why it was taking additional time. It’s one of the ideas I’d like to talk to people about to help ensure this is handled better in the future. There are opportunities to do the sensitive communications a bit better in the future, and I hope in the weeks ahead to talk with people about some ideas on that.
Now with the embargo lifted, I’ve resumed working towards a successful change reproposal. I’ve restarted my investigation of corresponding source availability for the runtimes. We lost 3 months to the embargo, but I think there is still work to be done. Already, in the past couple of weeks, I’ve had one face to face discussion with a FESCo member, specifically about putting a reproposal together, and got useful feedback on the approach to that.
So that’s where we are at now. What’s next?
I am still working on understanding how source availability works for the Flathub runtimes. I think there is a documentation gap here, like there was for the flatpak-builder sources extension. My ask to the Fedora community, particularly those motivated to find paths forward for Flathub as the default choice for bootc based Fedora desktops, is to join me in clarifying how source availability for the critical FLOSS runtimes works so we can help Flathub by contributing documentation that all Flathub users can find and make use of.
Like I said in my GUADEC talk, having a coherent (but not perfect) understanding of how Fedora users can get the flatpak corresponding sources and make local patched builds is important to me to figure out as we walk towards a future where Flathub is the default remote for Fedora. We have to get to a future where application developers can look at the entire linux ecosystem as one target. I think this is part of what takes the Linux desktop to the next level. But we need to do it in a way that ensures that end users have access to all the necessary source code to stay in control of their FLOSS software consumption. Ensuring users have the ability to patch and build software for themselves is vital, even if it’s never something the vast majority of users will need to do. Hopefully, we’re just a couple more documents away from telling that story adequately for Flathub flatpaks.
I’ve found that some of the most contentious discussions can be with people with whom you actually have a significant amount of agreement. Back in graduate school, when my officemate and I would talk about anything we both felt well-informed about and were in high agreement on: politics, comic books, science, whatever it was.. we’d get into some of the craziest, heated arguments about our small differences of opinion, which were minor in comparison to how much we agreed on. And it was never about needing to be right at the expense of the other person. It was never about him proving me wrong or me proving him wrong. It was because we really deeply wanted to be even more closely aligned. After all, we valued each other’s opinions. It’s weird to think about how much energy we spent doing that. And I get some of the same feeling that this is what’s going on now around flatpaks. Sometimes we just need to take a second and value the alignment we do have. I think there’s a lot to value right now in the Fedora and Flathub relationship, and I’m committed to find ways both communities can add value to each other as we walk into the future.
The post A statement concerning the Fedora and Flathub relationship from the FPL appeared first on Fedora Community Blog.
You dropped by the Fedora booth at FOSDEM '26
A few weeks ago, Daniel Stenberg highlighted that the curl project had — for a moment, at least — zero open issues in the GitHub tracker. (As of this writing, there are three open issues.) How can a project that runs on basically everything even remotely resembling a computer achieve this? The project has written some basics, and I’ve poked around to piece together a generalizable approach.
Is “zero issues” a reasonable goal? Opinions differ. There’s no One Right Way
to manage an issue tracker. No matter how you choose to do it, someone will be mad about it. In general projects should handle issues however they want, so long as the expectations are clearly managed. If everyone involved knows what to expect (ideally with documentation), that’s all that matters.
In Producing Open Source Software, Karl Fogel wrote “an accessible bug database is one of the strongest signs that a project should be taken seriously — and the higher the number of bugs in the database, the better the project looks.” But Fogel does not say “open bugs”, nor do I think he intended to. A high number of closed bugs is probably even better than a high-ish number of open bugs.
I have argued for closing stale issues (see: Your Bug Tracker and You) on the grounds that it sends a clear signal of intent. Not everyone buys into that philosophy. To keep the number low, as the project seems to consistently do, curl has to take an approach that heavily favors closing issues quickly. Their apparent approach is more aggressive than I’d personally choose, but it works for them. If you want it to work for you, here’s how.
If you want to reach zero issues (or at least approach it) for your project, here are some basic principles to follow.
Focus the issue tracker. curl’s issue tracker is not for questions, conversations, or wishing. Because curl uses GitHub, these vaguer interactions can happen on the repo’s built-in discussion forum. And, of course, curl has a mailing list for discussion, too.
Close issues when the reporter is unresponsive. As curl’s documentation states: “nobody responding to follow-up questions or questions asking for clarifications or for discussing possible ways to move forward [is] a strong suggestion that the bug is unimportant.” If the reporter hasn’t given you the information you need to diagnose and resolve the issue, then what are you supposed to do about it?
Document known bugs. If you’ve confirmed a bug, but no one is immediately planning to fix it, then add it to a list of known bugs. curl does this and then closes the issue. If someone decides they want to fix a particular bug, they can re-open the issue (or not).
Maintain a to-do list. You probably have more ideas than time to implement them. A to-do list will help you keep those ideas ready for anyone (including Future You) that wants to find something to work on. curl explicitly does not track these in the issue tracker and uses a web page instead.
Close invalid or unreproducible issues. If a bug can’t be reproduced, it can’t be reliably fixed. Similarly, if the bug is in an upstream library or downstream distribution that your project can do nothing about, there’s no point in keeping the issue open.
Be prepared for upset people; document accordingly. Not everyone will like your issue management practices. That’s okay. But make sure you’ve written them down so that people will know what to expect (some, of course, will not read it). As a bonus, as you grow your core contributors, everyone will have a reference for managing issues in a consistent way.
This post’s featured photo by Jeremy Perkins on Unsplash.
The post curl’s zero issues appeared first on Duck Alignment Academy.
RPMs of Redis version 8.4 are available in the remi-modular repository for Fedora ≥ 41 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
Packages are available in the redis:remi-8.4 module stream.
# dnf install https://rpms.remirepo.net/enterprise/remi-release-<ver>.rpm # dnf module switch-to redis:remi-8.4/common
# dnf install https://rpms.remirepo.net/fedora/remi-release-<ver>.rpm # dnf module reset redis # dnf module enable redis:remi-8.4 # dnf install redis --allowerasing
You may have to remove the valkey-compat-redis compatibilty package.
Some optional modules are also available:
These packages are weak dependencies of Redis, so they are installed by default (if install_weak_deps is not disabled in the dnf configuration).
The modules are automatically loaded after installation and service (re)start.
The modules are not available for Enterprise Linux 8.
Valkey also provides a similar set of modules, requiring some packaging changes already proposed for Fedora official repository.
Redis may be proposed for unretirement and be back in the Fedora official repository, by me if I find enough motivation and energy, or by someone else.
I may also try to solve packaging issues for other modules (e.g. RediSearch). For now, module packages are very far from Packaging Guidelines, so obviously not ready for a review.
redis
redis-bloom
redis-json
redis-timeseries
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.
RPMs of PHP version 8.4.15RC1 are available
RPMs of PHP version 8.3.28RC1 are available
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ PHP version 8.2 is now in security mode only, so no more RC will be released.
ℹ️ Installation: follow the wizard instructions.
ℹ️ Announcements:
Parallel installation of version 8.4 as Software Collection:
yum --enablerepo=remi-test install php84
Parallel installation of version 8.3 as Software Collection:
yum --enablerepo=remi-test install php83
Update of system version 8.4:
dnf module switch-to php:remi-8.4 dnf --enablerepo=remi-modular-test update php\*
Update of system version 8.3:
dnf module switch-to php:remi-8.3 dnf --enablerepo=remi-modular-test update php\*
ℹ️ Notice:
Software Collections (php83, php84)
Base packages (php)
I've mentioned my approach to technical debt often, but I've never actually written it down. Here's the framework I use.
Technical debt is most typically brought up from individual engineers or the engineering department. If not attended to, technical debt can slow down future product development and reduce the developer experience.
To me, technical debt is simply technical work we choose to postpone, focusing on something that currently has higher priority.
I am not going to get into why it is bad, but how it is created and what you might do to reduce it.
The following is the model I use to split technical debt into three classes.
On the smallest scale it is in the individual work, where shortcuts are taken
Medium scale is the project / product level, where product work take priority over technical work
The biggest level are migrations, for example version upgrades to systems
Make quality part of every story.
This is the easiest to address by the engineers, as it is fully in their hands.
They might decide to take a shortcut, by writing fewer tests, not spending time on refactoring, or ignoring agreements about code style or quality.
This could be due to pressure from the product side, or sometimes from taking the path of least resistance, or from wanting to focus purely on functionality.
If the pressure comes from the product side, make sure that the time required for proper testing, refactoring, and code quality is included in the feature estimate. This isn’t extra work — it’s part of delivering the feature itself.
You need a team agreement about the minimum quality that is expected, and then it is part of each task.
You don’t create extra tasks for this, you don’t reserve extra time, you don’t add it to the task specification, instead it is included in the feature work.
At the same time, the team has to hold everybody responsible for this.
If the team isn't holding people accountable, no one gets to complain about quality later.
Agree as a team when to defer, and track it explicitly.
At the project level — whether you call it an initiative, epic, cycle, or sprint — technical debt often appears when product delivery takes priority over internal improvements.
If you work in an agile environment, you want to deliver iteratively to the user as fast as possible. On the product side, it might be an MVP, or individual experiments.
The faster you learn, the faster you can decide if further investment is worthwhile
In this case, it might be valuable to delay technical investment to a later part of the project. You would create separate tasks to work on once the results of the experiments are clear.
This requires trust in the product planning process. If these tasks consistently end up in the forever backlog, the team will stop agreeing to defer them.
Plan migrations early, budget them like real projects.
System-level debt typically builds up quietly over time. A few examples:
A large system, like a database, needs an upgrade
One of the libraries or frameworks in use deprecates the version you are using
A dependency of your system is abandoned
You need to change a third-party system because of a change in costs
You inherit a system that has different quality standards as yours
All of these will require not only operational work, but also changes to existing systems, and code bases.
These will be large migrations, that often require multiple people, a team, or even teams to work on them.
They have to be handled as proper projects and will take time that would normally be reserved for feature projects.
In most cases, they will just cost money and not bring any new one in. Occasionally, they can even save money, especially if the new system brings performance improvements you can leverage.
This makes it often difficult to justify the work.
On the positive side, they are typically not urgent. For most of these, you will know about the changes in version or support very early. You can plan them well in advance.
The key is to treat these migrations as part of your long-term product strategy — planned, visible, and funded like any other project.
No matter the scale, managing technical debt is about conscious trade-offs and shared accountability. What matters most is that these decisions are made transparently, understood by everyone involved, and revisited regularly.
What doesn’t work is pretending technical debt doesn’t exist, or treating it as purely an engineering problem. It’s a product and business decision as much as a technical one.
And there will always be some technical debt, it is just important to make sure that it has the lowest impact on future development.
Well, it's been a few weeks since I made one of these recap blog posts. Last weekend I was recovering from some oral surgery, the weekend before I had been on PTO on friday and was trying to be 'away'.
Lots of things happened in the last few weeks thought!
As contributors no doubt know we have been fighting a super anoying tcp timeout issue. Basically just sometimes requests from our proxies to backend services just timeout. I don't know how many hours I spent on this issue trying everything I could think of, coming up with theorys and then disproving them. Debugging was difficult because _most_ of the time everything worked as expected. Finally, after a good deal of pain I was able to get a tcpdump showing that when it happens the sending side sends a SYN and the receiving side sees nothing at all.
This all pointed to the firewall cluster in our datacenter. We don't manage that, our networking folks do. It took some prep work, but last week they were finally able to update the firmware/os in the cluster to the latest recommended version.
After that: The problem was gone!
I don't suppose we will ever know the exact bug that was happening here, but one final thing to note: When they did the upgrade the cluster had over 1 million active connections. After the upgrade it has about 150k. So, seems likely that it was somehow not freeing resources correctly and dropping packets or something along those lines.
I know this problem has been anoying to contributors. It's personally been very anoying to me, my mind kept focusing on it and not anything else. It kept me awake at night. ;(
In any case finally solved!
There is a new outstanding issue that has occurred from the upgrade: https://pagure.io/fedora-infrastructure/issue/12913 basically long running koji cli watch tasks ( watch-task / watch-logs) are getting a 502 error after a while. This does not affect the task in any way, just the watching of it. Hopefully we can get to the bottom of this and fix it soon.
We have had a number of outages of late. They have been for different reasons, but it does make it frustrating trying to contribute.
A recap of a few of them:
AI scrapers continue to mess with us. Even though most of our services are behind anubis now, they find ways around that, like fetching css or js files in loops, hitting things that are not behind anubis and generally making life sad. We continue to block things as we can. The impact here is mostly that src.fedoraproject.org is sensitive to high load and we need to make sure and block things before it impacts commits.
We had two outages ( friday 2025-11-07 and later monday 2025-11-10 ) That were caused by a switch loop when I brought up a power10 lpar. This was due to the somewhat weird setup on the power10 lpars where they shouldn't be using the untagged/native vlan at all, but a build vlan. The friday outage took a while for us to figure out what was causing it. The monday outage was very short. All those lpars are correctly configured now and up and operating ok.
We had a outage on monday ( 2025-11-10 ) where a set of crashlooping pods filled up our log server with tracebacks and generally messed with everything. Pod was fixed, storage was cleared up.
We had some kojipkgs outages on thursday ( 2025-11-13 ) and friday ( 2025-11-14 ). These were caused by many requests for directory listings for some ostree objects directories. Those directories have ~65k files in them each, so apache has to stat 64k files each time it gets those requests. But then, cloudfront (which is making the request) times out after 30s and resends. So, you get a load average of 1000 and very slow processing. So, for now we put that behind varnish, so it just has to do it the first time for a dir and then it can send the cached result to all the rest. If that doesn't fix it, we can look at just disabling indexes there, but I am not sure the implications.
We had a nice discussion in the last fedora infrastructure meeting about tracking outages better and trying to do a RCA on them after the fact to make sure we solved it or at least tried to make it less likely to happen again.
I am really hoping for some non outage days and smooth sailing for a bit.
I think we are finally done with the power10 setup. Many thanks again to Fabian on figuring out all the bizare and odd things we needed to do to configure the servers as close to the way we want them as possible.
The fedora builder lpars are all up and operating since last week. The buildvm-ppc64les on them should have more memory and cpus that before and hopefully are faster for everyone. We have staging lpars also now.
The only final thing to do is to get the coreos builders installed. The lpars themselves are all setup and ready to go.
I haven't really been able to think about this due to outages and timeout issue, but things will start heating up next week again.
It seems unlikely that we will get our new machine in time to matter now, so I am moving to a new plan: repurposing another server there to migrate things to. I plan to try and get it setup next week and sync pagure.io data to a new pagure instance there. Depending on how that looks we might move to it first week of december.
Theres so much more going on, but those are some highlights I recall...
As always, comment on mastodon: https://fosstodon.org/@nirik/115554940851319300
Short, but with lots of good stuff. The fad of engineering management, drug policy in Spain, and Mr. TIFF are my favourites.
Have a lovely weekend!
"Good engineering management" is a fad - you will have to adapt and core skills are reusable
Seven Decisions - "Inspired" -- right.
Mr TIFF - the story of the TIFF format. As an Amiga fanboy, I like to follow anything related to IFF.
Prompt Injection in AI Browsers - nice. We will have so much fun in the future.
Rust in Android: move fast and fix things - Google's experience with Rust. Faster reviews are interesting.
The Trammmformation of Diagonal [YouTube] a look at the new tram lines and some history
34-Year-Old Finds Dream Job Doing The Unexpected [YouTube] - cargo bike Olympics as a business.
Roads need to be narrower or wider to protect cyclists, says new government guidance - interesting finding. I do like smaller lanes, as this also reduces speed.
We can't have nice fountains, part 3 [YouTube] - Some great skateboarding shots.
Time to Migrate - Tim wants you to move to Mastodon. He is right.
Drugs policy: Who Does It Best? [Podcast] - another special episode from The Europeans.
admin )
on 2025-11-14 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 10th – 14th November 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 46 2025 appeared first on Fedora Community Blog.
admin )
on 2025-11-14 08:00:00 UTC
We did it again, Fedora at Kirinyaga university in Kenya. This time, we didn’t just introduce what open source is – we showed students how to participate and actually contribute in real time.
Many students had heard of open source before, but were not sure how to get started or where they could fit. We did it hands-on and began with a simple explanation of what open source is: people around the world working together to create tools, share knowledge, and support each other. Fedora is one of these communities. It is open, friendly, and built by different people with different skills.
We talked about the many ways someone can contribute, even without deep technical experience. Documentation, writing guides, design work, translation, testing software, and helping new contributors are all important roles in Fedora. Students learned that open source is not only for “experts.” It is also for learners. It is a place to grow.
After the introduction, we moved into a hands-on workshop. We opened Fedora Docs and explored how documentation is structured. Students learned how to find issues, read contribution instructions, and make changes step-by-step. We walked together through:
By the end of the workshop, students had created actual contributions that went to the Fedora project. This moment was important. It showed them that contributing is not something you wait to do “someday.” You can do it today.
“This weekend’s Open Source Event with Fedora, hosted by the Computer Society Of Kirinyaga, was truly inspiring! 
Through the guidance of Cornelius Emase, I was able to make my first pull request to the Fedora Project Docs – my first ever contribution to the open-source world. 
”
– Student at Kirinyaga University
Huge appreciation to:
And to everyone who played a part – even if your name isn’t listed here, I see you. You made this possible.
The students showed interest, curiosity, and energy. Many asked how they can continue contributing and how to connect with the wider Fedora community. I guided them to Fedora Docs, Matrix community chat rooms, and how they can be part of the Fedora local meetups here in Kenya.
We are introducing open source step-by-step in Kenya. There is a new generation of students who want to be part of global technology work. They want to learn, collaborate, and build. Our role is to open the door and walk together(I have a discourse post on this, you’re welcome to add your views).
This event is part of a growing movement to strengthen Fedora’s presence in Kenya. More events will follow so that learning and contributing can continue.
We believe that open source becomes strong when more people are included. Fedora is a place where students in Kenya can learn, grow, share, and contribute to something global.
We already had a Discourse thread running for this event – from the first announcement, planning, and budget proposal, all the way to the final workshop. Everything happened in the open. Students who attended have already shared reflections there, and anyone who wants to keep contributing or stay connected can join the conversation.
You can check the events photos submitted here on Google photos(sorry that’s not FOSS:))
Cornelius Emase,
Your Friend in Open Source(Open Source Freedom Fighter)
oaf357 )
on 2025-11-14 05:00:00 UTC
comments? additions? reactions?
As always, comment on mastodon: https://fosstodon.org/@nirik/115674367344830186