fidzu : Fedora

03 Dec 2025 9:00pm GMT

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.

28 Nov 2025 4:00pm GMT

26 Nov 2025 7:00am GMT

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:

• Forge Your Future with Open Source by VM Brasseur
• Designing Data Governance from the Ground Up by Lauren Maffeo
• Guiding Star OKRs by Staffan Nöteberg
• Business Success with Open Source by VM Brasseur

I've read (or have in my stack to read) other books as well:

• Manage It! by Johanna Rothman
• Real-World Kanban by Mattias Skarin
• Hands-On Rust by Herbert Wolverson
• Advanced Hands-On Rust by Herbert Wolverson
• Powerful Command-Line Applications in Go by Ricardo Gerardi

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.

25 Nov 2025 9:49pm GMT

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.

25 Nov 2025 4:00pm GMT

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.

25 Nov 2025 3:10pm GMT

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

24 Nov 2025 4:00pm GMT

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.

23 Nov 2025 11:00pm GMT

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.

23 Nov 2025 6:14pm GMT

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

# 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

23 Nov 2025 6:00pm GMT

Another busy week in fedora infrastructure. Here's my attempt at a recap of the more interesting items.

22 Nov 2025 8:48pm GMT

21 Nov 2025 3:38pm GMT

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

Fedora Infrastructure

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

• The intermittent 503 timeout issues plaguing the infra appear to finally be resolved, kudos to Kevin and the Networking team for tracking it down.
• The Power10 hosts which caused the outage last week are now installed and ready for use.
• Crashlooping OCP worker caused issues with log01 disk space
• Monitoring migration to Zabbix is moving along, with discussions of when to make it "official".
• AI scrapers continue to cause significant load. A change has been made to bring some of the hits to src.fpo under the Varnish cache, which may help.
• Update/reboot cycle planned for this week.

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It's responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

• HDD issue on internal storage server for CentOS Stream build infra
• Update Kmods SIG Tags (remove EPEL)
• cbs signing queue stuck
• Verify postfix spam checks
• Deploy new x86_64/aarch64 koji builders for CBS
• Prepare new signing host for cbs in RDU3
• https://cbs.centos.org is now fully live from RDU3 (DC-move) : kojihub/builders in rdu3 and/or remote AWS VPC isolated network, and also signing/releng process

Release Engineering

This team is taking care of day to day business regarding Fedora releases.
It's responsible for releases, retirement process of packages and package builds.
Ticket tracker

• EPEL 10.1 ppc64le buildroot broken
• Transfer device-mapper-multipath ownership to real person
• Transfer repo ownership to real person
• fcitx5-qt update didn't get to updates repository
• Fedora 43 branch for pgbouncer stuck
• Help with rebuilds
• Follow up on Packages owned by invalid users fesco#3475

RISC-V

• F43 RISC-V rebuild status: the delta for F43 RISC-V is still about ~2.5K packages compared to F43 primary. Current plan: once we hit ~2K package delta, we'll start focusing on the quality of the rebuild and fix whatever important stuff that needs fixing. (Here is the last interim update to the community.)
• Community highlight: David Abdurachmanov (Rivos Inc) has been doing excellent work on Fedora 43 rebuild, doing a lot of heavy-lifting. He also provides quite some personal hardware for Koji rebuilders.

Forgejo

Updates of the team responsible for Fedora Forge deployment and customization.
Ticket tracker

• Redirects for attachments retention during repository migration [A] [B] [C] [D]
• Fedora -> Forgejo talk for Fedora 43 release party has been recorded
• Valkey self managed cluster deployed for Forgejo caching on staging - prod next
• Private issues - Analysis on database schema, access protection, API layer
• Forgejo support for Konflux explored -Weighed in on Konflux roadmap meeting
• Action runners - cleanup for finished runners and workaround for service routes, demo of declarativeness recorded
• Migration request for Commops SIG, Cloud SIG and AI/ML SIG completed
• Fixes for user creation issue upstreamed, fixed Anubis problem in the production

List of new releases of apps maintained by I&R Team

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.

21 Nov 2025 10:00am GMT

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 :

• EL-10 RPMs are built using RHEL-10.0
• EL-9 RPMs are built using RHEL-9.6
• EL-8 RPMs are built using RHEL-8.10
• This version will also be the default version in Fedora 44
• Many extensions are already available, see the PECL extension RPM status page.

Information, read:

• PHP 8.5 Released!
• Migrating from PHP 8.4.x to PHP 8.5.x
• UPGRADING
• UPGRADING.INTERNALS

Base packages (php)

Software Collections (php85)

21 Nov 2025 7:52am GMT

20 Nov 2025 10:00pm GMT

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

1. When you're in a project because your company wants you there and you are personally interested in the technology.
2. You participate in the project and a fork, downstream, or upstream that it has a relationship with.
3. You participate in multiple projects all solving the same problem, for example multiple Linux distributions.
4. You sit on a standards body or other organization that has general purview over an area and are working on the implementation.
5. You work on both an open source project and the product it is commercially sold as.
6. You're a member of a legally liable profession, such as a lawyer (in many jurisdictions) so anything you say can be held to that standard.
7. You're in a small project and because of bootstrapping (or community apathy) you're filling multiple roles during a "forming" phase.

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:

1. Is this really a multi-hat situation? Are you just conflicted because you have views as a member of multiple projects or as someone who contributes in multiple ways that aren't in alignment? If it isn't a formalized role you're struggling with the right problem. Speak your mind. Share the conflict and lack of alignment. This is the meat of the conversation.
2. Why are you here? You generally know. That is the hat you wear. If you're at a Technical Advisory Committee Meeting on behalf of your company and an issue about which you are personally passionate comes up - remember patience and friendship because this is a company hat moment.
3. If you are in a situation where you can truly firewall off the conversations, you can change to an alternative hat. What this means is when you find yourself in a space where the provider of your other hat is very uninvolved. For example, if you normally work on crypto for your employer, but right now you are making documentation website CSS updates. Hello personal hat.
4. If you're in a 1:1 conversation and you know the person well, you can lay out all of your thoughts - just avoid the hat language. Be direct and open. If you don't know the person well, you should probably err on the side of being conservative and think carefully about states 1 and 2 above.

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.

20 Nov 2025 3:00pm GMT