czanik )
on 2025-12-11 12:15:55 UTC
The December syslog-ng newsletter is now on-line:
It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2025-12-logrotation-release-rpm-nightly-rpm
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 …
bcotton )
on 2025-12-10 12:00:00 UTC
LFX Insights is a handy platform from the Linux Foundation that provides a variety of data on open source projects. Among the statistics it reports is contributions outside of working hours. Some users reported errors with how this information is reported, which got me thinking about the value of this measure. The short version: there’s very little value.
LFX Insights includes this measure as a signal of a project’s sustainability. Projects that rely heavily on people making after hours contributions, the thinking goes, will have a harder time attracting and retaining contributors.
As a software consumer, you don’t want your upstreams to suddenly disappear because that will present supply chain risks. It could mean vulnerabilities go unpatched. It could also mean that new features aren’t added. Either way, this puts the onus on the project’s users to carry the load.
As a project leader, you may be less concerned about whether or not a company downstream has to devote extra engineering time, but you probably do want your contributors to stick around anyway. Onboarding, mentoring, and growing contributors takes a lot of time and effort. You want to make sure people can stick around.
Despite the good intentions of measuring contributions outside working hours, the reality fails to deliver. There are some straightfoward reasons for this. Not everyone’s working hours are the same. Not everyone’s working hours are consistent. Some people use a different time zone on their computer. Not everyone’s working days are the same. Holidays vary widely across countries and religions. People (hopefully) take time off.
Then there’s the cultural mismatch. Linux Foundation projects are, to a first approximation, by companies for companies. The Linux Foundation is a 501(c)(6), not a charity, so it makes sense that it would view the world through a business lens. I don’t fault them for that. LF project contributors are more likely to make contributions during the working day than contributors to a “hobbyist” project.
But that workday tendency doesn’t necessarily mean people will stick around projects longer if the project is tied to their job. As the last few years have shown, tech sector layoffs can come for anyone at any time. If someone is only working on an open source project because it’s part of their job, then when the job changes, they’ll probably stop. People who work on an open source project for non-job reasons will likely stick around through job changes.
Thus one could argue that a project with a high degree of outside-working-hours contributions is more sustainable.
If measuring contributions outside of working hours isn’t helpful, what is? Focus on what you’re worried about. Worried that everyone will disappear? Measure the activity over time. Worried that when a new vulnerability is discovered the lone maintainer will be backpacking through the Alps? Measure the spread of the contributions. Worried that the project doesn’t have enough people to follow secure coding practices? Measure the security posture.
Of course, the best answer is to stop trying to measure sustainability and contribute to making the project more sustainable instead.
This post’s featured photo by Joshua Olsen on Unsplash.
The post The do’s and don’ts of measuring contributions “outside of working hours” appeared first on Duck Alignment Academy.
admin )
on 2025-12-10 08:00:00 UTC
Generative AI systems are changing the way people interact with computers. MCP (model context protocol) is a way that enables generate AI systems to run commands and use tools to enable live, conversational interaction with systems. Using the new linux-mcp-server, let’s walk through how you can talk with your Fedora system for understanding your system and getting help troubleshooting it!
Large language models (LLMs) can be an invaluable tool when investigating an issue on a Linux system. However, this can involve a lot of copy/pasting of information from the Linux terminal into a web based interface to an LLM model.
The model context protocol (MCP) acts as a bridge, enabling LLMs to interact with external tools and data sources. The linux-mcp-server utilizes this protocol to give LLMs the ability to interact with a Fedora Linux system. Instead of you manually copying and pasting terminal output, the linux-mcp-server enables the LLM to directly query system information and log entries.
By enabling an LLM direct access to system information and logs, it is transformed into an active part of the investigation process when troubleshooting an issue. It empowers an LLM to directly query the system state, allowing it to help identify performance bottlenecks, and identify important log entries that might be missed by a manual review.
Anthropic introduced MCP in November 2024 as an open standard for LLM tool use. This provides a way for LLMs to interact with outside systems and data sources.
Prior to MCP, there wasn’t as strong a standard and ecosystem for LLM systems to call tools. LLMs were thus frequently limited to have only the information contained in their training. They were isolated from the outside world. For example, if you asked an LLM “what is the weather going to be next week”, the LLM would respond with a message indicating that it doesn’t know what the weather will be, as it doesn’t have access to that information. MCP helps solve this problem by enabling a standardized way for an LLM to access an outside data source, such as the weather forecast.
At a high level, users can use an AI agent application, such as Goose (open source), or Claude Desktop, and specify which MCP servers they would like to use. The AI agent application informs the LLM that there are tools available via these MCP servers that can be used to help answer the requests from the user. The LLM model can then decide when to invoke these tools.
MCP is an open standard. You have the flexibility to use MCP servers, such as linux-mcp-server, with either open source-licensed LLM models, or hosted proprietary LLM models.
The linux-mcp-server is a project started by Red Hat’s RHEL Engineering team. It provides a number of tools that enable an LLM to query information from a Linux system, such as system info, service information and logs, process information, journald and other logs, network information, and storage and disk information. For a full list of the tools provided, refer to the project’s Github page.
These tools, provided by linux-mcp-server, are focused on providing the LLM access to read-only information. In the future, we’ll be exploring expanding past these read-only use cases.
The linux-mcp-server can be used to interact with the local Fedora Linux system that it is running on. It can also be used to interact with remote Fedora Linux systems over SSH. For example, if you have SSH key authentication setup with the remote systems, you could make a request to your AI agent application such as “Determine the current memory usage on the fedora1.example.com, fedora2.example.com, and fedora3.example.com servers”.
The main components needed are an AI agent application, access to LLM model inference, and the linux-mcp-server.
There are a number of options for the AI agent application, both open source and proprietary. An example of an open source AI agent is Goose, which provides an RPM that can be installed on Fedora.
There are several LLM model inference options, ranging from locally hosted open source models, to proprietary hosted LLM models. If hosting a model locally, you generally need to have GPU/accelerator hardware available. Open source tools that can be used to locally host LLM models include RamaLama, llama.cpp, and Ollama. There are a number of open source LLM models capable of tool calling. These include models such as gpt-oss-20b and Granite 4 small.
Once you’ve installed your preferred AI agent application, the next step is to install the linux-mcp-server and configure your AI agent application to use it. The linux-mcp-server Github page includes installation instructions, and configuration details for Goose and Claude Desktop.
Has this happened to you? Time to hop on a call and give a demo. You’re pumped. It’s your go-time aaaaand… your system starts lagging. Folks on the call say your video is choppy or they can’t understand you. OH NO.
You’ve got to assess what’s up, quickly. Run `top`, check `dmesg`, check your network connection (read the man page for `netstat` because you can’t remember the flag you want), check `journalctl`, cross-reference what you’re seeing, then start killing processes, restarting services, reloading kernel modules willy-nilly based on hastily-crafted theories, see if it improves…
This is a case where you could actually ask the system to tell you why it’s slow and give it the ability to do the analysis via linux-mcp-tools. The LLM you connect with won’t just run the commands through the MCP server; it will understand what the numbers it gets means in context and be able to explain in human terms.
So let’s start working with a relatively new laptop. It’s a Thinkpad T14S with the AMD Ryzen
AI Pro 7 ( Ryzen AI 360 chip.) Recently one of the wifi networks it must connect to regularly was upgraded. It now has issues with the network connection stability. So let’s talk to Goose + gpt-oss:20b + linux-mcp-server about it. Here’s the initial prompt I used:
My Wifi doesn't work very well. It cuts out after a few minutes. Help me fix it. Can you find the error messages in the system logs and diagnose the problem?
It responded with the following:
I'll help you diagnose your WiFi connectivity issues by examining the system logs for error messages related to your network interfaces and wireless connectivity. Let me start by gathering information about your system and checking the relevant logs.
It then made a series of tool calls, including Get System Information, Get Network Interfaces, Get Journal Logs, Get Hardware Information, Get Service Status service_name:NetworkManager, Get Service Status service_name:wpa_supplicant, Read Log File. The result was this analysis, which is the actual problem I was hoping it could find!
Problem SummaryYour ATH12K PCI (Qualcomm 802.11ax) wireless card repeatedly reports
ath12k_pci 0000:c2:00.0: failed to enqueue rx buf: -28
every few minutes, which triggers a drop of the wireless link. The driver is trying to enqueue an RX buffer for the hardware but fails with errno ‑28.
‑28 →
(out‑of‑memory for the driver buffer); the kernel cannot allocate a DMA‑coherent RX descriptor.-ENOMEM
Likely Root Causes| Cause | Evidence / Typical Scenario | Fix / Work‑around |
|---|---|---|
| Driver bug or missing patch | The kernel’s ath12k driver has had a long‑running issue with RX ring management in older 5.15/5.4 series. | Update the kernel or apply the latest patch from the
linux ath12k |
| Out‑of‑memory in the driver | The error itself is “‑28” – a memory‑allocation failure inside the driver. | Reduce the number of RX descriptors, or enable fast‑RX disabled mode (
modprobe ath12k_pci ath12k_pci_disable_fast_rx=1 |
| Firmware mismatch / corruption | Old firmware (
ath12k_hwgen |
Reinstall firmware from your distro (
sudo apt‑install --reinstall linux‑firmware |
| System memory pressure | If many big processes run, DMA‑coherent memory pool can be exhausted. | Free RAM, close memory‑heavy apps, or add swap. |
| ACPI/PCIe power‑management quirk | Some laptops throttle the Wi‑Fi device after idle, resetting the buffer queue. | Add
pci_bus_reset = off ath12k_pci_disable_ps=1 |
| Hardware issue (e.g., faulty PCIe slot or NIC) | Persistent failure after multiple driver/kernel upgrades. | Test on another machine/PCIe slot or replace the card. |
Diagnostic Checklistuname -r
modinfo ath12k_pci | grep ^version:
cat /sys/module/ath12k_pci/parameters/*
– See if
ls /lib/firmware/ath12k/ath12k/ar9009/ | grep wlan0 | head
– If the files are missing or older than the driver, copy newer ones from
sudo dmesg --ctime | grep -A3 'ath12k_pci 0000:c2:00.0'
– Observe if there are any other “-ENOMEM” or “resource exhaustion” messages.
free -h
vmstat 1 5
sudo lspci -vvv -s c2:00.0 | grep -iE "link|latency"
Quick‑Fix Path (Try in this order)| Step | Command | What it does |
|---|---|---|
| 1 |
|
Refresh firmware to the latest distro version. |
| 2 |
|
Apply latest kernel with patched ath12k driver (or switch to 5.18+ if still on 5.15). |
| 3 |
|
Force the driver to use a more conservative RX scheme. |
| 4 | Reboot and monitor:
dmesg -T | grep ath12k_pci |
Verify the error disappears. |
| 5 | Optional: test on another machine or use a USB‑WiFi dongle (USB 802.11ax / 802.11ac) as a temporary workaround. | Ensure the issue is not hardware‑specific. |
**Tip:** After reboot, you can also verify driver parameters:
Advanced Debugging (if basic fixes don’t help)sudo bash -c 'echo 1 > /sys/module/ath12k_pci/parameters/debug'
sudo dmesg -T | grep ath12k
sudo lspci -vv -s c2:00.0
sudo ethtool -S wlp4s0
grep -i 'ath12k' /var/log/syslog
Bottom LineThe “failed to enqueue rx buf: –28” is an internal driver allocation failure that typically follows one of two paths:
If you're still stuck after following the quick‑fix path, it's worth capturing more detailed logs with the above diagnostic commands and sharing them. We can then cross‑reference the exact kernel version/driver commit to see if a known patch exists.
Feel free to let me know which step you’ve tried or if you encounter any new log messages, and we’ll dig deeper!
Not too bad an analysis and set of debugging steps! I’ll follow up in the comments and let you know if the solution works.
Trawling through `du` on the command line, converting the numbers in your head, sorting them – it can be tedious. We even have graphical tools like `baobab`, but it takes time to load in the results and explore the data. And sometimes you might have questions it can’t answer in terms of the risk of deleting a specific directory, or the age of a specific file. It’s easier to be sloppy and just let the disk fill up. But there comes a time where that is no longer an option.
You can ask the system using the linux-mcp-server to analyze your disk usage, give you a hitlist of the top space-eating places on the file system, and give you advice with a risk analysis of how to clean it up.
Here’s my prompt:
I need help analyzing disk usage on my system. Can you: 1. Show me the current disk usage across all filesystems using get_disk_usage 2. Use list_directories_by_size to show me the 10 largest directories (this will help identify where disk space is being consumed) 3. Check if there are any large log files consuming space using get_journal_logs or read_log_file 4. Review running processes with list_processes to see if any are consuming excessive resources or creating temporary files After gathering this information, help me identify potential space-saving opportunities and assess the safety of cleaning up specific directories. Please don't only examine top-level directories. I want you to go deep if needed to find out where the largest files are!
I ran this prompt on my Fedora 42 system using linux-mcp-server with Goose connected to locally-served gpt-oss:20b, and here’s the output I got:
Disk‑space overview (as of Nov 24 2025 15:21)
| Filesystem | Size | Used | Avail | Use % | Mounted on |
| /dev/mapper/luks‑61cedb0e… | 952.3 GB | 548.9 GB | 399.6 GB | 57.9 % | / |
| /dev/mapper/luks‑61cedb0e… | 952.3 GB | 548.9 GB | 399.6 GB | 57.9 % | /home |
| /dev/nvme0n1p2 | 973.4 MB | 462.8 MB | 443.4 MB | 51.1 % | /boot |
| /dev/nvme0n1p1 | 598.8 MB | 19.3 MB | 579.6 MB | 3.2 % | /boot/efi |
Overall usage is comfortably below 60 % of a 952 GB volume, so immediate capacity pressure isn’t a concern. The biggest contributors to disk space today are in the ~/. hierarchy.
| Path (relative to the mount point) | Size (≈) | Notes |
| ~/ – User home (2 mounts: /home + /) | 1 TB total | 57 % used; the bulk of the space is in ~/ |
| ~/duffy/.local/share | 238 GB | Containers sub-dir, followed by Trash (7GB) – typical podman/docker container images |
| ~/duffy/.local/share/containers | 238 GB | Container layers, images, root filesystems – the prime candidate for cleanup |
| ~/duffy/.local | 266 GB | share (237 GB) dominates it |
| ~/duffy/.local/share/containers (inside share) | 238 GB | Same as above – just a different view |
| ~/duffy/.local/lib | 13 GB | Likely a virtual‑environment library set |
| ~/duffy/.local/bin | 4 GB | Helper binaries |
| ~/duffy/.local/share/Trash | 7 GB | User‑deleted items still resident on disk |
| ~/duffy/.local/share/containers (nested) | 238 GB | Same as above; redundant listings from recursive depth‑1 scans |
| ~/duffy/.local/share (top‑level) | 238 GB | containers is the absolute largest item |
Take‑away – 75 % of the 238 GB live inside three nested directories:
| Category | Recommendation | Rationale |
| Containers | podman system prune -a (or docker system prune -a if Docker is in use) | Removes unreferenced images, containers, and caches. This can reclaim 200–250 GB if most containers are outdated or no longer referenced. |
| Trash | gio trash –empty | The 7 GB in Trash is still taking physical space; simply emptying it will free that amount. |
| Large libs/binaries | Check ~/duffy/.local/lib – 13 GB, and ~/duffy/.local/bin – 4 GB | If these are not actively used by a project, consider uninstalling or moving them to a secondary, less‑frequented store. |
| Ramalama & UV | 9 GB (ramalama), 8 GB (uv) | Possibly temporary files or caches from development tools. Inspecting the contents of these directories (du -h) can reveal if they are still needed. |
| Other caches | pnpm store prune, virtualenv or pip cache purge | Development tool caches often accumulate; they’re usually safe to delete once you’re done with the current development sessions. |
| Logs | The system journal shows normal activity, and syslog access is blocked by policy. | Systemd journal stores are rotated automatically; no urgent action required. |
| Boot partitions | Not relevant – they’re low‑usage (boot/efi only 3 % used). | No action needed. |
# 1. Empty Trash
gio trash --empty
# 2. Prune unused containers/images
podman system prune -a # or docker system prune -a
# 3. Remove leftover caches
pnpm store prune # if pnpm is installed
pip cache purge # for Python
virtualenv --clean # optional
# 4. Inspect large “RAM” directories manually if you need deeper cleanup
du -h --max-depth=1 ~/duffy/.local/share/containers
Tip: After each step run df -h /home or du -sh ~/duffy/.local/* to see the impact.
| Action | Why it’s safe (or risk) |
| Emptying Trash | Deletes only user‑deleted files; confirm you don’t need the content. |
| podman system prune -a | Deletes container images, containers, and volumes that are not referenced by any running or stopped container. Verify with podman ps -a before pruning. |
| Removing lib/bin from .local | Only safe if you’re sure those libraries/bin files aren’t part of a running application. |
| Caution with tmpfs or moving large directories | If you move a directory on‑the‑fly, ensure no running application depends on that path. |
Feel free to ask what next steps you’d like to dig into (e.g., detailed contents of the containers dir, specific application logs, or targeted pruning commands).
So you may have noticed a little detail above – the system is a Fedora 42 system… and Fedora 43’s been out a month now! 
So, time to upgrade.
This example shows where we have some tools missing from the set provided in the linux-mcp-server. We’re including it for two reasons:
Here’s the prompt I started with, with the same Goose + gpt-oss:20b + linux-mcp-server combination:
You are a Linux system administrator assistant analyzing a Fedora system for upgrade readiness. TASK: Examine this Fedora 42 system and provide a comprehensive upgrade readiness report for Fedora 43. ANALYSIS CHECKLIST: 1. Check current Fedora version: cat /etc/fedora-release 2. Review system updates status: dnf check-update 3. Identify third-party repositories: dnf repolist 4. List installed packages from non-Fedora repos: dnf list installed | grep -v @fedora 5. Check for broken dependencies: dnf check 6. Review disk space on root partition: df -h / 7. Check for unsupported or deprecated packages 8. Identify custom kernel modules: lsmod | grep -v "^Module" 9. Review SELinux status: sestatus 10. Check for pending system updates: dnf upgrade --refresh --assumeno REPORT FORMAT: # Fedora 43 Upgrade Readiness Report ## Current System Status - Fedora version: [version] - Kernel: [kernel version] - Updates status: [current/outdated] ## Potential Issues [List blocking issues with HIGH/MEDIUM/LOW severity] ## Third-Party Software [List non-Fedora packages that may need attention] ## Recommendations [Specific pre-upgrade steps needed] ## Overall Readiness: [READY/NEEDS ATTENTION/NOT READY] Run the necessary commands and provide this analysis. Be specific about any issues found and give actionable recommendations.
Now, right away the model came back to me to complain it doesn’t have access to `dnf`, `cat`, etc. And that’s expected here. What it did was give me a list of homework to run for it to complete the analysis… for example, `dnf check-update` and `cat /etc/fedora-release`. I had a little back and forth in Goose with the model where it would ask me to run a command and I’d copy the output into the context. This resulted, finally, in the following report:
Analyzed System – Fedora 42 (Kernel 6.17.7‑200.fc42.x86_64)
Date – 2025‑11‑24
| Item | Value |
| Fedora release | 42 (Adams) |
| Kernel | 6.17.7‑200.fc42.x86_64 |
| Root filesystem | 953 GB LUKS, 58 % used (411 GB free) – > 15 % free |
| /var /usr | Same as root partition (mounted the same LUKS device) |
| SELinux | enabled (policy targeted), currently permissive |
| System‑wide packages | No held packages (dnf versionlock list empty) |
| System modules | No modules held. |
TL;DR – The base system is clean; the kernel is up‑to‑date for 42, there is ample disk space, and there are no version‑locked packages.
| Repository | Description | Current dnf repolist status |
| rpm-fusion-free, rpm-fusion-nonfree, rpm-fusion-updates | Widely used RPM‑Fusion components | Enabled |
| google-cloud-cli | Google Cloud SDK (RPM built for EL 10) | Enabled |
| visual-studio-code | Microsoft VS Code RPMs | Enabled |
| command‑line‑assistant, google‑chrome, PyCharm, unsupported‑fedora‑packages, goose, leaktk | Various Copr builds (mostly Fedora‑42 based) | Enabled |
What we need to verify
| Issue | Severity | Why it matters | Immediate Remedy |
| Non‑Fedora packages (e.g., google‑cloud‑cli) | MEDIUM | May contain packages built for EL 10; could conflict with Fedora 43 libs. | Verify if a Fedora 43 build exists or plan to remove/re‑build it. |
| Third‑party repos without 43 builds | MEDIUM | dnf system-upgrade pulls all enabled repos; lacking 43 packages causes transaction failure. | Disable such repos temporarily (dnf config-manager –set-disabled <repo>) or enable the 43 stream when available. |
| Custom kernel modules | LOW | Modules compiled against 42 kernel won’t load on 43; services may drop. | Re‑compile or patch modules after upgrade. |
| Broken dependencies reported by dnf check | HIGH | Would block the upgrade transaction. | Run sudo dnf check now; fix any reported issues. |
| Insufficient disk space | HIGH | Upgrade scripts need > 15 % free. | Not an issue (58 % free). |
Current High‑Risk Items – None detected yet.
Next Action – Confirm each third‑party repo has 43‑compatible packages and set SELinux to enforcing.
| Step | Command | Purpose |
| Confirm 43‑stream packages | `dnf list –available * | grep <repo-id>` |
| Verify SELinux enforcement | sestatus | Should show enforcing. |
| Check for broken dependencies | sudo dnf check | No errors should appear. |
| Refresh all repos | sudo dnf upgrade –refresh | Pull latest metadata. |
| Dry‑run upgrade | sudo dnf system-upgrade download –releasever=43 –allowerasing | Detect any missing packages or conflicts. |
| Optional: Disable problematic repos | sudo dnf config-manager –set-disabled <repo> | Prevent upgrade crash if a repo has no 43 build. |
| Persist SELinux config | sudo sed -i ‘s/SELINUX=permissive/SELINUX=enforcing/’ /etc/selinux/config | Make enforcement permanent. |
| Criteria | Status | Comment |
| Disk space | Ready | 58 % free |
| Package health | Ready | No held or broken packages |
| Third‑party repos | Conditional | Verify 43‑compatibility |
| Custom modules | Pending | Need to identify modules and re‑compile |
| Final verdict | READY (after addressing above points) |
Next step – Run the three verification commands below and share the output with me:
sudo dnf check
sudo dnf repolist
dnf list installed | grep -v @fedora
With those outputs I can pinpoint any remaining blockers and give you a final, ready‑to‑proceed plan.
Happy upgrading!
You can see from these few examples that tool calling with LLMs is a valuable tool for troubleshooting Linux systems. We could use your help building this and making it awesome! How can you help?
Join us upstream at https://github.com/rhel-lightspeed/linux-mcp-server! And come chat with us in the Fedora AI/ML SIG chat room on Matrix!
admin )
on 2025-12-10 07:00:00 UTC
This outage impacts the Fedora Copr Frontend. Seems like these bots were attracted by our outage announce: Baudispider, YandexBot, ClaudoBot, AmazonBot, Presto, https://openai.com/bot TikTokSpider, which are currently DDoSing us and causing performance degradation.
oaf357 )
on 2025-12-10 05:00:00 UTC
catanzaro )
on 2025-12-09 15:29:11 UTC
WebKitGTK 2.50.3 contains a workaround for CVE-2025-13947, an issue that allows websites to exfiltrate files from your filesystem. If you’re using Epiphany or any other web browser based on WebKitGTK, then you should immediately update to 2.50.3.
Websites may attach file URLs to drag sources. When the drag source is dropped onto a drop target, the website can read the file data for its chosen files, without any restrictions. Oops. Suffice to say, this is not how drag and drop is supposed to work. Websites should not be able to choose for themselves which files to read from your filesystem; only the user is supposed to be able to make that choice, by dragging the file from an external application. That is, drag sources created by websites should not receive file access.
I failed to find the correct way to fix this bug in the two afternoons I allowed myself to work on this issue, so instead my overly-broad solution was to disable file access for all drags. With this workaround, the website will only receive the list of file URLs rather than the file contents.
Apple platforms are not affected by this issue.
admin )
on 2025-12-09 08:00:00 UTC
Apply now for the Flock to Fedora 2026 Call for Proposals (CfP) at cfp.fedoraproject.org. This year, the submission deadline for the Flock CfP is Monday, February 2nd, 2026.
Last month we announced that we’ll be convening again in Prague for Flock 2026 in June. Everyone interested in attending can head over to the Flock 2026 website and register today! For those of you who want to contribute to Flock by presenting your thoughts and ideas in front of your fellow contributors, we’ve got some inspiration for you in the form of updated proposal themes.
This year’s proposal themes are inspired by Fedora’s four foundations:
These themes are here to help get you thinking about topics you’d like to present. If you have something you want to talk about that doesn’t quite fit neatly into these themes, but you feel it belongs at Flock, go ahead and submit anyways! The reviewers are open to alternative topics. They are on the look out for topics that Fedora contributors are interested in discussing.
Financial travel assistance applications are now open as well. When you go to register to attend on the Flock 2026 website, you should also see links on how to apply for travel assistance if you need it. Financial assistance will be open until March 8th (several weeks after CfP closes on Febuary 8th). This is to give those with accepted talks an opportunity to figure out if they’ll need travel assistance.
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.
comments? additions? reactions?
As always, comment on mastodon: https://fosstodon.org/@nirik/115674367344830186