fidzu : Fedora

Hoy se me ocurrió que quiero mi módem de Megacable en modo puente. La neta, tener doble NAT es un dolor de cabeza si quieres hospedar tus servicios, recibir conexiones directas o simplemente tener un ruteo limpio. Así que decidí ponerlo en modo puente y, de paso, resolver el detalle de que el perfil de IP pública no incluye IPv6.

Aquí te cuento toda la historia y cómo configuré mi gateway con NetworkManager y Firewalld para que todo jalara bien chingón.

# Crear interfaz de túnel SIT en NetworkManager
nmcli connection add \
   type ip-tunnel \
   con-name he-ipv6 \
   ifname he-ipv6 \
   mode sit \
   remote 198.51.100.1 \
   ip-tunnel.parent enp3s0 \
   ipv4.method disabled \
   ipv6.method manual \
   ipv6.addresses "2001:db8:1::2/64" \
   ipv6.gateway "2001:db8:1::1" \
   ipv6.route-metric 100 \
   connection.zone external

# Asignar ULA y GUA pública a la LAN
nmcli connection modify enp2s0 \
   ipv6.method manual \
   ipv6.addresses "fd41::1/64, 2001:db8:2::1/64"
nmcli connection up enp2s0

# Permitir protocolo 41 en la zona externa
firewall-cmd --permanent --zone=external --add-rich-rule='rule family="ipv4" source address="198.51.100.1" protocol value="41" accept'

# Quitar masquerading global de IPv6
firewall-cmd --permanent --zone=external --remove-rich-rule='rule family="ipv6" masquerade'

# Habilitar masquerading exclusivo para la ULA
firewall-cmd --permanent --zone=external --add-rich-rule='rule family="ipv6" source address="fd41::/64" masquerade'

# Aplicar cambios
firewall-cmd --reload

# /etc/radvd.conf
interface enp2s0 {
   AdvSendAdvert on;
   MinRtrAdvInterval 30;
   MaxRtrAdvInterval 100;
   prefix fd41::/64 {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr on;
   };
   prefix 2001:db8:2::/64 {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr on;
   };
};

systemctl enable radvd
systemctl restart radvd

#!/usr/bin/bash
# Despachador de NetworkManager para actualizar la IP del túnel
set -euo pipefail
IFS=$'\n\t'

readonly Interface="enp3s0"
readonly ConfigFile="/usr/local/etc/tunnelbroker.bash"
readonly UpdateUrl="https://ipv4.tunnelbroker.net/nic/update"

main() {
    local -r interface="${1:-}"
    local -r action="${2:-}"

    if [[ "$interface" != "$Interface" ]] || [[ "$action" != "up" && "$action" != "dhcp4-change" ]]; then
        return 0
    fi

    # shellcheck source=/dev/null
    source "$ConfigFile"

    # Enviar actualización a HE
    local response
    response=$(curl -4 -sS -G \
        --data-urlencode "username=$username" \
        --data-urlencode "password=$password" \
        --data-urlencode "hostname=$hostname" \
        --data-urlencode "myip=AUTO" \
        "$UpdateUrl")

    if [[ "$response" =~ ^(good|nochg) ]]; then
        # Reiniciar conexión he-ipv6 para refrescar
        nmcli connection up he-ipv6 &>/dev/null || true
    fi
}

main "$@"

ssh vps.ejemplo.net "curl -6 -I -m 5 http://[2001:db8:2::100]/"

07 Jul 2026 8:50pm GMT

Unlike the Flock To Fedora 2025 event proceedings, the workshops were planned to be frontloaded into the conference this time. As there were no presentations or townhalls on the first day, it also meant that there was no live streaming on our YouTube channel either. Heading to bed a little early the day before was the right thing to do, as that allowed me to wake up at around 0500am Central European Summer Time on 14th June 2026. Of course, the jet lag prevented me from getting proper respite, but still it was better than nothing at all. After one last look at the slide decks for the (newly created) Fedora Forge Progress Update and the (FOSSAsia-intentioned) Fedora Badges Revamp Project, I uploaded them on the Pretalx platform for them to be available to both in-person and remote attendees.

While I had Tomáš Hrčka's help for the former, I had to drive the latter by myself since Chris Onoja Idoko could not make it to the conference this time. I also found it an amusing observation that while the Fedora Badges Revamp Project was scheduled as the last presentation for FOSSAsia 2026, the workshop on the same topic was planned as the first workshop for Flock To Fedora 2026. As it was scheduled for 0900am Central European Summer Time, I had to ensure that I had the venue's audio/video setup configured properly for my purposes. On meeting the likes of Frantisek Lachman and Michal Konecny at the breakfast table at around 0700am Central European Summer Time, we shared conversations about contemporary governance and technological innovations around the world.

Michal and I left for the venue at around 0800am Central European Summer Time after a quick trip back to our rooms to fetch our conference backpacks, because we anticipated the early crowd to be denser at the registration desk with the attendees rolling in swiftly. Amidst meeting up with a bunch of familiar faces during our short walk to the event venue, I could not shake the familiar feeling of attending the Flock event at the same place and at nearly the same time as the previous year. Unlike the last time, I did not assume that I would automatically get registered when my proposals got selected, and that led the registration check to go smoothly. Meeting up with Dorka Volavkova at events had always been a pleasure, especially even more so when she promptly helped out with the venue's audio/video setup.

Running into the likes of Kevin Fenzi and Alexander Bokovoy in the hallway track did lead to some interesting community conversations, but I decided to keep those short to be present in the Opal room and prepare my distributable apparatus of sticky notes and sketch pens that I flew in all the way from Kolkata for this usage. Since the event venue provided multiple thin-sized A4 notebooks and rolling ballpoint pens at the attendee seats, all I had to do was provide the sticky notes for the hands-on activity on the heuristic user experience evaluation. After wishing Hristo Marinov the best, as even he was running an interactive workshop at the same time although in a different room, I found attendees gradually arriving at the Opal room for my workshop by around 0915am Central European Summer Time.

I realized that I had to manage the workshop's cadence on the move to ensure that I was addressing both the folks who had been there from the beginning and those who were just joining after some time. As I wanted to respect the time of the three folks - Vittorio Cioe, Jonáš Hubený, and Vít Smolík - who decided to join, I kicked off the workshop session then while recapping for the joining folks whenever we had them dropping in every now and then. My intuition to front-load the years-long backstory of the revamp initiative was on point, as it made little to no sense to start off the interactive parts with just three people attending. While I explained the architecture of the project system and the progress of the efforts through the multiple years, the attendee number increased from just three to over fifteen.

It was the right time to begin handing out the sticky notes, all while revealing the staging instance of the Fedora Badges deployment to the community. Gauging the individual awareness of the project also helped me cater specifically to those who did not know much about it but were deeply engrossed in learning. Since I had to cover the design modernization too, I blended superficial experience with technical talks, all while giving folks the time to provide feedback on the overall experience. While folks like Matthew Miller, Matthew Holmes, Justin Wheeler, Jona Azizaj, Cornelius Emase, and Ankur Sinha added to the activity as longtime volunteers, I also got feedback from interested newcomers to Fedora Badges like Shawn Dunn, Emmanuel Seyman, Guillermo Leiro, Misia Mary, Vittorio, Jonáš, Vit and more.

Matthew even mentioned handing over the ecosystem Discourse syncing script that integrated the achievements from the Fedora Badges backend into the Fedora Discussion platform. I was also helped with brilliant photography by Jakub Jelen and Misia, who took care of the entire event's photography efforts. The lenient ask of using either a mobile phone or a laptop computer to access the staging service also allowed me to obtain more involved feedback that I was able to take back to Aurelien Bompard and Shounak Dey. The second half of the interactive session became more involved, and I ended up overshooting the designated time by ten minutes or so. As there had been a twenty-minute-long break planned between the one-hour-and-forty-minute-long workshops, that was not really a deal breaker.

While I did not necessarily eat into someone else's designated time, I barely had about ten minutes to take a resting breath before heading back into the Sapphire room. If you can believe it - not only, did I have two workshops to organize on that day, but those were also scheduled in succession. With Tomáš being surprised that his HDMI support on Fedora Linux Asahi Remix was working flawlessly, I made it into the room at around 1055am Central European Summer Time. This was also a whole lot more packed with folks than the previous one, so the two of us decided to start five minutes after the designated time. If I had to attribute why there were relatively more folks here than in the previous workshop, a small part of it would be the scheduled time, but a large part had to do with the significant relevance.

Being a critical initiative for the last couple of years in the Fedora Project, we were now heading into the Dist Git service aspect and were planning on rendering the Pagure service read-only. I spent the first half sharing the progress updates since the previous year's Flock event before handing it over to Tomáš for the plans for the Dist Git migration development. I made it a point to inform attendees on the housekeeping aspects, continuous integration, private issues, migration progress, learning pathways, and community involvement with due credit. That helped us take advantage of the attendees being present there in person for interactivity. The reception was a lot better than the previous year, with the folks participating not only in the hands-on updates but also in the future plans of the critical initiative.

We encouraged the attendees to pause us in between to ask questions or convey concerns as they felt like it. Sure enough, we had discussions around the potential private branches feature from Justin Forbes, the lookaside cache technological implementation from Miro Hroncok, the forced-pushing prevention policy from Fabio Valentini, the possible Pagure documentation change from David Duncan, the Pagure sunsetting service action from Ankur, the Forgejo Actions trigger config from Frantisek, the potential Bugzilla replacement development from Kevin, and other things. Even though there were a lot of talks to do, the workshop interactions felt well-spaced in a way that could be absorbed in the notes that I was taking along the way to share with the team members who could not attend the event.

The neighbouring discussions also included concerns about the support for the Packager Dashboard, the templating of project repositories to include the files for European Union Cyber Resilience Act Stewardship, the need for SSH access for Dist Git project repositories, the methods for conveying the archival state of the source repositories, and other areas. Finishing off the workshop at around 1245pm Central European Summer Time, my involvements continued at the dining area with the Fedora Mentor Summit 2026's Lunch And Learn Matching. Ankur also decided to accompany me in helping out with the organization, and we headed to the lunch area to meet with Shaun McCance and Jona, who were helping prepare the tables for the folks to discuss various topics, all while enjoying delicious food.

On Shaun's expedient advice, we used the whiteboard to draw the attendee crowd towards us, while detailing the topics scoped for discussions on that day. On the fifth year of the Fedora Mentor Summit event, we departed from the need for pre-dated registration for the Lunch And Learn Matching and opened it up to everyone at the conference. This not only allowed for greater participation along the way, but we were also able to curate the involvement based on the selected topics for the three days. Take, for instance, the topics for that day: Documentation, Operations, Development, and Marketing. In a community where everyone is both a mentor and a mentee, anyone could join any table they desired to share what they have or learn from the others, thus making meaningful connections at an in-person event.

Astonishingly enough, it was mostly down to Jona and me at the event to run the Fedora Mentor Summit 2026 proceedings, as many of the helping folks could not make it to Flock To Fedora 2026. We decided to get seated ourselves after setting up the table presences with the likes of Hristo, Kevin, Cornelius, and Ankur with their interested topics. I also suggested to Jona that he take the first separated dining segment from the next day onwards to be able to catch attendees right after they had taken their plates, since the Pretalx platform mistakenly noted that the social event was taking place in the Sapphire room. Also, offering a distinct Fedora Badge allowed us to pull in more folks to our little event, and we were able to close the lunch event as a success by around 0145pm Central European Summer Time.

This also meant that I had no more scheduled obligations for the day - some free time that I used to catch up with the likes of Michael Scherer and Carol Chen after a year or so, since I did not visit FOSDEM that year. Paired up with Ankur now, the two of us headed into the Fedora Data & Analytics Workshop, which was chaired by Michael Winters at around 0200pm Central European Summer Time. Honestly, it was rather impressive to see just how he was able to use the Datanommer store in building a Data Lakehouse that could potentially answer question on effective community health metrics. He even detailed my previous attempts at generating the activity information that I worked on ages ago, called Fedora Contributor or User Activity Statistics, and how he built the first prototype of the Hatlas Project.

The interactive workshop also detailed a variety of data-related infrastructure tools that he made use of and our frustrations with the synchronously built Datagrepper API for fetching information. With Jef Spaleta and Matthew working to fetch data for the Fedora Project Leader Keynote to be presented on the next day, that also involved a bunch of technical debugging and agentic development. Following the closing of that workshop and meeting with Michael on Fedora Badges, Ankur and I headed next into Ellis Low's interactive workshop on Do-It-Yourself AI: Build a Private Customizable Chatbot on Lean Hardware at around 0400pm Central European Summer Time. While the presenter suggested building the projects from source, Ankur and I realised that both of them were packaged in Fedora Linux.

We suggested the use of the officially updated llama-cpp and whisper-cpp packages on Fedora Linux while competing on CPU-bound build times and running lighter hardware models. Strangely enough, at around this time, I found myself banned inadvertently by the automated moderation from one of the Flock To Fedora 2026 Matrix rooms after posting photographs from the event to serve the remote folks, since the workshop proceedings were not live streamed on that day. I was startled, but the banning action was immediately rectified by Steve Cosette, who helped us by remotely moderating the chatrooms manually. We also ran the Docs2DB project locally on our laptops from the PyPI source, and it was impressive to see just how the documentation database could be queried as if it were an expensive chatbot.

I appreciated the deeper focus on decentralizing artificial intelligence workloads and the greater emphasis on running models on local hardware. While Ellis did acknowledge the potential shortcomings of CPU inferencing, the advantages found in data security far outweighed the possible frustrations with slower task. The first day of the event's proceedings was done by 0600pm Central European Summer Time, and I realized that I barely had a few minutes to make it to the lobby for a group dinner with my colleagues from the Red Hat Community Linux Engineering Team. After meeting the ever disciplined and always punctual Fedora Quality Assurance Team at the venue lobby, we marched towards the dining place soon, as we wanted to be back at the venue for the International Candy Swap event too.

I caught up with the likes of Adam Williamson, Kamil Paral, Kashyap Chamarthy, and Lukas Ruzicka, and after being joined by Lenka Segura and Michal, we finally made it to the restaurant. As luck would have it, even this ended up being an Asian place like the day before, but I honestly did not have any complaints with that. Following Tomáš' meal advice from the day before on the dish, and after a chat on the introductory mails for the sysadmin-main incoming membership with Kevin, we departed for the venue again at around 0700pm Central European Summer Time for the International Candy Swap event. Michal and I had to run back to Ibis Praha Mala Strana first to fetch our event offerings, but we were able to rush back to the celebration place right when the introductions were barely about to kick off.

Making a note of the potential allergens and origin introductions for my delicious haul on the paper piece, we went around the table with those discussions. For the hard candies of flavours like Orange, Guava, Mango, Lychee, Tamarind, and Coffee that I flew in all the way from Kolkata, I feared that I might have overdone those additions to the already massive toothache variety. Since Michal and I were stuffed from the team dinner, we had to be extremely choosy with what we tried tasting. I was accompanied by Christopher Klooz, Artur Frenszek-Iwicki, Kacper Skrzyński, Matthew, Ankur, and Emi for the tasting trials before finding a nearby table for a round of Michal's board game, Cyanide and Happiness: Trial By Trolley. We took turns playing the train driver and made comically difficult choices for scoring high.

After being briefly joined by Matthew and Justin at the game table, I found myself getting sleepier by the passing minute, so I decided to call it quits after the first couple of games. I realized that I was struggling to get adequate sleep anyway, and the last thing I would want to do then was to deprive myself of what was duly deserved. I struck a chat with Jona about the planning of the next day's Fedora Mentor Summit proceedings, all while following Justin's advice in getting small pieces of regional candies I wanted to fly back home for my family and friends. I decided to head back to my hotel right after bidding everyone farewell at around 1030pm Central European Summer Time and attempt to catch some shut eye to see just how successful I would end up being after the super eventful first day.

07 Jul 2026 6:30pm GMT

07 Jul 2026 8:00am GMT

I work at Red Hat in the Python Maintenance team mostly taking care of the Python ecosystem in Fedora. For the past year or so, I've been motivated by my employer to use agentic AI to deliver my work. Clearly, we are not the only ones.

At the beginning, I struggled to find reasonable use cases for this tool. I maintain software, which involves a lot more communication and coordination than actually writing code. When people ask me what I do, I often half-jokingly reply that I read and write a lot of emails. How can AI boost my productivity when I spend 80% of my time essentially talking to people? Where is the fun in replacing the remaining 20% of actually crafting code with more talking, this time to half-competent robots?

In time, I found ways to use AI that felt productive. And, ever so hypocritically, not only at work. But at what cost? I am supporting an industry that regularly harms open source projects such as Fedora, helps destroy the planet and uses stolen data. Moreover, I've become reliant on a proprietary tool. Is my AI-boosted contribution to Fedora worth it?

Despite my moral dilemma, I still love my job. I am a long-standing, well-known Fedora contributor, working for the most part on whatever I feel is needed, earning a competitive salary. In theory, I could go look for another job where I would not be motivated to do this, but I wouldn't be able to keep doing the thing I love. I try to make the best out of this situation and, despite my initial distaste, use the tool to improve the project. So at the end of the day, I close my eyes and think of Fedora¹.

However, the implications of embracing AI are not just impacting me. The nature of my work means I've made hundreds (thousands?) of small open source contributions here and there. And sometimes, when I use AI to deliver those, it kinda feels like bringing a chunk of meat to a vegan BBQ. The people on the receiving end of my contribution for the most part don't care about my job sustainability or IBM shareholders, nor should they.

Once, I used AI to contribute to a Fedora packaging project. It was reluctantly reviewed by another long-standing, well-known Fedora contributor (who happens not to be employed by Red Hat and is not well-compensated for this work). When talking to them, I realized that they were uncomfortable reviewing such a change. I made them uncomfortable by choosing to use AI for this. My employer made me uncomfortable; I passed it on to a volunteer. What an outstanding open source citizen.

I appreciate the irony of this; and yet, I am no slop generator. I understand what I submit and I put my name on it. I disclose the usage for transparency, because it matters. I don't just drop a vibecoded patch on an open source project. If you have an AI policy, I read it and respect it. So it pains me deeply when our carefully considered contributions are outright branded AI slop or LLM hallucinations, and the person bringing them is evaluated solely on the basis of the tool they used. Especially when such judgment is made by people I respect².

No, I am not a tool. Please don't treat me as such.

PS On a lighter note, here are some examples of AI usage that somehow eliminate this problem for me:

• Debugging a problem - in our team we've been very successful in showing a failing test to Claude and telling it that it started failing with Python 3.15. While burning thousands of tokens and wasting gallons of drinking water it can usually successfully determine what caused the failure. We were able to determine this ourselves in the past, but this actually boosted our productivity. We can then report the problem to upstream after we have verified the find.
• My own/my team's semi-internal tooling -³ the omnipresent bunch of random scripts I am not proud of and which would desperately need a rewrite but ain't nobody got time for that. Just slop 'em. If it works, it works. If it doesn't, roll-back. Nobody needs to see this code anyway. Excellent for AI - I am still kinda killing the planet but at least I don't shove it in your face.
• Reporting to management - somehow people keep asking me what I did. There's no dilemma in providing AI-generated reports to the same people who asked me to use AI. If nothing else, it demonstrates how progressive I am with it.
• Reviews for me - when I don't use AI to generate code, but rather ask it to review my design and implementation, nobody is forced to deal with my AI usage. For example, I wrote this blogpost myself, then asked AI for feedback on typos, grammar, tone, voice, argument, rhetoric, structure, flow…⁴

07 Jul 2026 12:00am GMT

07 Jul 2026 12:00am GMT

Hoy te vengo a hablar de una herramienta que, para muchos, nomás sirve para mandar memes o jugar trivias en chats grupales. Pero la neta, si eres sysadmin o te late el desmadre del self-hosting y la administración de servidores, la API de Bots de Telegram es una mina de oro. Es, sin temor a equivocarme, la consola de ChatOps más barata y potente que te puedes echar a la bolsa.

Dejate de andar batallando con pasarelas de SMS de paga o configurando servidores de correo SMTP que de todos modos van a terminar en la carpeta de spam. Con un bot de Telegram tienes un canal de comunicación directo, encriptado y gratis para controlar tus fierros desde cualquier lugar.

Aquí te cuento las características clave y ejemplos bien prácticos para que los corras tú mismo:

# /usr/local/bin/systemd-telegram-notify.bash
#!/usr/bin/bash
set -euo pipefail
IFS=$'\n\t'

readonly BotToken="123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
readonly ChatId="987654321"

main() {
    local -r service_name="${1:-}"
    if [[ -z "$service_name" ]]; then
        printf "Usage: %s <service_name>\n" "${0##*/}" >&2
        return 1
    fi

    local message
    message=$(printf "❌ *Servicio Caído*\n*Host:* %s\n*Servicio:* \`%s\`\n*Hora:* %s" \
        "$(hostname)" \
        "$service_name" \
        "$(date '+%Y-%m-%d %H:%M:%S')")

    curl -s -X POST "https://api.telegram.org/bot${BotToken}/sendMessage" \
         -d "chat_id=${ChatId}" \
         -d "parse_mode=MarkdownV2" \
         -d "text=${message}"
}

main "$@"

# /etc/systemd/system/telegram-notify@.service
[Unit]
Description=Enviar alerta de Telegram al fallar %I

[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-telegram-notify.bash %i

# /usr/local/bin/telegram-bot.cr
require "http/server"
require "json"
require "process"

ADMIN_ID = 987654321_i64
BOT_TOKEN = "123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"

server = HTTP::Server.new do |context|
  if context.request.method == "POST" && context.request.path == "/webhook"
    if body = context.request.body
      payload = JSON.parse(body.gets_to_end)
      msg = payload["message"]?
      sender_id = msg.try(&.["from"]?.try(&.["id"]?.try(&.as_i64?)))
      text = msg.try(&.["text"]?.try(&.as_s?)) || ""

      if sender_id == ADMIN_ID && text.starts_with?("/status")
        # Ejecuta un comando rápido de diagnóstico
        stdout = IO::Memory.new
        Process.run("df", args: ["-h", "/"], output: stdout)
        disk_res = stdout.to_s

        reply = "Estado de discos:\n<pre>#{disk_res}</pre>"
        send_reply(msg.not_nil!["chat"]["id"].as_i64, reply)
      end
    end
  end

  context.response.content_type = "application/json"
  context.response.status = HTTP::Status::OK
  context.response.print({status: "ok"}.to_json)
end

def send_reply(chat_id : Int64, text : String)
  client = HTTP::Client.new(URI.parse("https://api.telegram.org"))
  payload = {
    chat_id: chat_id,
    text: text,
    parse_mode: "HTML"
  }.to_json

  client.post(
    "/bot#{BOT_TOKEN}/sendMessage",
    headers: HTTP::Headers{"Content-Type" => "application/json"},
    body: payload
  )
end

address = server.bind_tcp "0.0.0.0", 8443
puts "Escuchando en http://#{address}"
server.listen

# /etc/systemd/system/telegram-bot-api.service
[Unit]
Description=Telegram Bot API Local Server
After=network.target

[Service]
Type=simple
User=telegram
ExecStart=/usr/local/bin/telegram-bot-api --local --api-id=tu_api_id --api-hash=tu_api_hash --dir=/var/lib/telegram-bot-api --working-dir=/var/lib/telegram-bot-api/temp
Restart=always

[Install]
WantedBy=multi-user.target

# /usr/local/bin/send-report.cr
require "http/client"
require "json"

BOT_TOKEN = "123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
CHAT_ID = "987654321"

# Plantilla HTML que entiende el motor Rich HTML de Telegram
rich_html = <<-HTML
<h1>Reporte del Servidor srv01</h1>
<hr/>
<p>Estado de los servicios críticos de la infraestructura:</p>
<table bordered striped>
  <tr><th>Servicio</th><th>Estado</th></tr>
  <tr><td>Nginx Webserver</td><td>🟢 Activo</td></tr>
  <tr><td>MariaDB Cluster</td><td>🟢 Activo</td></tr>
  <tr><td>Podman Daemon</td><td>🔴 Inactivo</td></tr>
</table>
<br/>
<details>
  <summary>Ver logs de error de Nginx</summary>
  <pre>2026/07/06 15:30:12 [error] 1234#0: *5 open() "/var/www/html/favicon.ico" failed</pre>
</details>
HTML

payload = {
  chat_id: CHAT_ID,
  rich_message: {
    html: rich_html
  }
}

response = HTTP::Client.post(
  "https://api.telegram.org/bot#{BOT_TOKEN}/sendRichMessage",
  headers: HTTP::Headers{"Content-Type" => "application/json"},
  body: payload.to_json
)

puts "Respuesta: #{response.status_code} - #{response.body}"

06 Jul 2026 9:15pm GMT

Across the various Fedora working groups, the primary focus is actively preparing for the upcoming Fedora 45 release cycle, marked by a large influx of system-wide Change Proposals such as GNU Toolchain updates, Fontconfig 2.18, and the transition to oo7 as the default secrets provider. Concurrently, a major infrastructure modernization effort is underway, with multiple teams-including Infrastructure, Release Engineering, and Docs-coordinating the final stages of the repository migration from Pagure to Forgejo, alongside the adoption of Konflux for unified container builds and Zabbix for system monitoring. On the governance front, leadership has indefinitely paused the Community Initiatives process to design a new Technology Innovation Lifecycle (Sandbox) for incubating large, experimental features. Despite the resulting closure of the AI Developer Desktop proposal, artificial intelligence remains a strong technical focus across the project, with groups exploring local LLM integrations like the "Anthony" voice assistant and expanding AI/ML framework packaging. Finally, security and compliance are key priorities, as teams ramp up policy preparations for the EU Cyber Resilience Act (CRA) and push necessary incompatible package updates to mitigate high-severity vulnerabilities.

Announcements

The Fedora Council has paused the Community Initiatives process, closing the AI Developer Desktop proposal until a new strategic direction mechanism is designed, and is actively seeking community feedback on a proposed Technology Innovation Lifecycle Process (this statement was also cross-posted to the announce and devel-announce lists). In community news, the F44 Election Results have been announced for the Council, FESCo, Mindshare, and EPEL Steering Committee. Additionally, maintainers are urged to review the list of long-term FTBFS (Fails To Build From Source) packages scheduled for retirement in early August ahead of the Fedora 45 branch so they can be fixed or exempted.

A large batch of Change Proposals has been submitted for Fedora 45. System and security updates include enabling Shadow Stack by default on x86_64, switching to oo7 as the default Secrets Service Provider to replace KWallet and GNOME Keyring, and disabling DNF5 vendor changes by default to prevent unexpected package overwrites in multi-vendor setups. Core software updates feature a GNU Toolchain update (GCC 16.2, glibc 2.44, binutils 2.47, GDB 17.2), Ruby on Rails 8.1, and Fontconfig 2.18. Finally, user experience improvements are proposed with Stratis Storage support in Anaconda and a highly customizable Bash Color Prompt 1.0.

Council

The Council made a significant shift in project governance this week by suspending the Community Initiatives process indefinitely. As a result, the Fedora AI Developer Desktop Initiative proposal was closed, though contributors are strongly encouraged to continue this work through collaborative spaces like the AI/ML SIG. Leadership is now directing community feedback toward the proposed Fedora Innovation Lifecycle (Sandbox) to establish a better framework for incubating large, experimental features. In other news relevant to the broader Linux ecosystem, the Council officially approved extending the "Fedora Atomic" branding to encompass Fedora's bootable container base images.

To improve contributor engagement and clarity, a new community policy document was merged to help manage user expectations around volunteer response times. The Council also finalized the F44 Council election interview questions, shifting the focus toward candidates' strategic visions and governance experience. Furthermore, new discussions are underway regarding improvements to Fedora's public-facing presence to better attract new contributors, alongside a forum thread clarifying trademark guidelines for regional community sites migrating their infrastructure.

Learn more about the Council team.

FESCo

This week, FESCo reviewed a large batch of Fedora 45 Change Proposals, including updates to the GNU Toolchain, LLVM 23, Ruby on Rails 8.1, Fontconfig 2.18, Bash Color Prompt 1.0, and libxml2. Major system-wide feature discussions included enabling Shadow Stack by default on x86_64, disabling DNF5 vendor change by default, switching the default secrets service provider to oo7, and adding Stratis storage support in Anaconda. The committee also debated policy and infrastructure topics, such as the upcoming Forgejo distgit migration, handling pre-built binary content in node_modules, and whether to drop signoff requirements from the defunct Fedora crypto team to unblock modern cryptography libraries like aws-lc.

In terms of contributor engagement and process, FESCo is looking for volunteers to co-own an upcoming Change Proposal to make 2FA mandatory for all packagers. During their weekly meeting, members clarified that the proposed "technology innovation lifecycle" (sandbox) process is not intended to bypass FESCo approval. Finally, the non-responsive maintainer process was initiated for the ledger package, opening the door for new co-maintainers to take over.

Decisions

• Council Representative: It was agreed that decathorpe will continue as FESCo's Council representative until the end of his current term.
• ELN Draft Builds: FESCo approved permitting the ELNBuildSync (EBS) service to use draft builds in Koji sidetags inherited from eln-build for ELN rebuild batches. The Kojihub policy will be updated to grant the eln-buildsync user permissions to tag and promote these draft builds.

Learn more about the FESCo team.

Mindshare

This week, the Mindshare group discussed using Fedora trademarks with 3rd party projects. A representative from the Polish Fedora community, which has been active since 2003, sought guidance on compliance regarding their fedora.pl domain, automated emails, logos, and favicons after losing their infrastructure sponsor. Respondents directed the inquiry to the official Fedora trademark guidelines, highlighting that the community's usage likely falls under the allowable provisions for "Community Sites and Accounts."

Learn more about the Mindshare team.

Workstation / GNOME

The Fedora Workstation Working Group discussed "Anthony," a voice-driven desktop assistant utilizing local large language models (LLMs) for task automation and accessibility. The team explored hardware constraints, security improvements-such as transitioning from TCP ports to D-Bus portals for flatpak sandboxing-and leveraging existing accessibility trees. Contributors are encouraged to test the project and help with internationalization efforts by aligning it with IBus speech-to-text initiatives. Additionally, the upcoming Fontconfig 2.18 release was noted, which may require a rebuild of all font packages due to cache format changes.

On the forums, a community proposal to merge GNOME Software and DNFdragora into a single, unified package manager for all Fedora editions was met with skepticism. Respondents highlighted that GNOME Software must remain distro-agnostic, the merger would not suit environments like KDE Plasma, and maintaining a strict separation between GUI application management and CLI package management remains the preferred, less confusing approach for users.

Decisions

• The group decided to explore integrating the Anthony voice control project into Fedora Workstation as a default feature.
• A dedicated meeting will be organized to discuss collaboration between the Anthony project and general IBus speech-to-text efforts.
• The regular meeting schedule will be paused for the month of July to accommodate summer travel and the GUADEC conference, with plans to reconvene in August.

Learn more about the Workstation / GNOME team.

Server

The Server Working Group met on July 1, 2026 to coordinate early testing for the upcoming Fedora 45 release and to advance the new Fedora Home Server spin-off. To proactively catch virtual machine and networking issues, the team is starting F45 Rawhide testing ahead of schedule, with an immediate focus on VM images and NFS client connections. A dedicated project board will soon be established to organize these F45 testing efforts, providing a clear and accessible way for community contributors to get involved.

Significant progress was also made on the Fedora Home Server spin-off. The group finalized the core application stack for the upcoming alpha release, prioritizing essential home lab services, privacy, and self-hosted management. Furthermore, the team discussed the image development process, comparing KIWI and Image Builder. To lower the barrier to entry for new contributors, they opted for a local-first development philosophy, ensuring anyone can build and test the spin-off images on their own machines.

Decisions

• The alpha version of the Fedora Home Server spin-off will initially include Samba, NFS, Mail service (IMAP/POP3 storage), Cockpit, Calendar and to-do server, Apache reverse proxy, and Ansible.
• The working group will use the home server repository to share all configuration data and installation instructions, allowing interested contributors to easily set up their own local image development environments.

Learn more about the Server team.

Infrastructure

This week, the Infrastructure team focused heavily on monitoring modernization, officially removing Nagios and Collectd in favor of Zabbix, while actively refining Zabbix triggers, predictive disk space checks, and SLA structures. Significant progress was also made on OpenShift migrations, including standardizing openshift-apps playbooks to use a new deployment role and migrating ELNBuildSync. Routine maintenance continued with careful RHEL 10 virthost reinstalls to avoid outages, and testing Forgejo 15.0.3 in staging. The team also resolved several minor service disruptions, including a Postorius 500 error caused by missing email bodies and Anubis proxy lockouts.

In the forums, a helpful discussion clarified the roles of Bugzilla, Forgejo, and Dist-Git for users confused by the ongoing transition away from Pagure. Contributors also explored the possibility of shared LLM inference services for community applications like Log Detective, and proposed restoring pre-commit hooks in the infra/ansible repository to gradually improve code quality. For contributors looking to get involved, the ongoing Zabbix template refinements and Ansible playbook conversions offer excellent, low-risk entry points into infrastructure work.

Decisions

• Nagios and Collectd are officially deprecated and are being removed from Ansible and servers.
• Pagure.io will become read-only at the end of July, with Fedora-related projects migrating to the new Forgejo instance (forge.fedoraproject.org).
• Old openQA Proof-of-Concept instances running in AWS will be deleted to save resources.

Learn more about the Infrastructure team.

Release Engineering

The Fedora 45 release cycle is officially ramping up, with the Mass Rebuild scheduled for July 15th and the creation of F47 release signing keys due shortly after. The Release Engineering team is currently reviewing several F45 system-wide changes, including Stratis Storage in Anaconda, Fontconfig 2.18, and disabling DNF vendor changes by default. In broader news, investigations into building a Fedora container base image using Konflux are ongoing, and an updated respin of Fedora 44 featuring Linux kernel 7.1 is planned for the coming weeks.

Infrastructure migrations from Pagure to Forgejo are continuing, prompting active architectural discussions on whether to process fedora-scm-requests using native Forgejo Actions or by extending the existing Toddlers infrastructure. During their weekly meeting, the team also clarified procedures for stalled EPEL requests and coordinated prep work for the upcoming mass rebuild. Furthermore, a significant pipeline improvement was unblocked when FESCo approved a policy to allow draft builds for ELN, which will allow the ELNBuildSync process to safely restart after crashes without prematurely consuming NVRs.

Decisions

• FESCo approved a policy permitting the ELNBuildSync service to use draft builds in Koji sidetags inherited from eln-build for ELN rebuild batches (Ticket #13374).
• The team clarified that users requesting to take over stalled EPEL packages must already be official package maintainers (in the FAS packager group) before they can be added as repository collaborators (Meeting).

Learn more about the Release Engineering team.

Quality

The Quality team saw active discussions and tool developments this week, highlighted by a community proposal to eliminate Fedora's version numbering in favor of automatic, version-less updates. The community largely pushed back on the idea, noting that the current release model is necessary for users who prefer to delay updates for stability, and that rolling-release alternatives already exist. In broader ecosystem news, a new GTK4 frontend for DNF5 called DNF UI has reached its 0.3.x series and is actively seeking user feedback. Behind the scenes, Quality Engineering (QE) advanced their compose-critical package script to an MVP state, progressed on the Dist-git PR test feature, and investigated significant bugs, including a grub2 issue breaking image builds and a haveged update causing boot failures.

There are several immediate opportunities for contributors to get involved in testing. The team is calling for participation in the Linux Kernel 7.1 Test Days (running June 28 to July 4) for Fedora 43 and 44, which was also announced on the test mailing list. Additionally, testers are invited to validate the latest Fedora 45 Rawhide 20260630.n.0 nightly compose to help ensure the stability of upcoming releases.

Learn more about the Quality team.

Design

The Design team is finalizing the F45 default wallpaper following the end of its feedback period, and is actively working on several branding initiatives, including simplified icons for Fedora Messaging tools, Artemis, and various Matrix bot avatars. Infrastructure and asset management were also key topics, with discussions on migrating the fedora-logos package from pagure.io and whether to archive old Community Blog and Fedora Magazine image repositories. Additionally, preparations are underway to automate Flock 2026 YouTube thumbnails using Inkscape extensions and schedule data.

A major focus this week is the development of a Contributor Onboarding Video Series to help newcomers navigate Fedora's systems. To make these videos more authentic, the team has launched an open call for horizontal video footage from past Fedora events to replace stock assets. Contributors are also invited to help design Community Personas that visually represent different types of Fedora participants, offering a highly creative way to get involved.

Decisions

• Community Event Footage: The team aligned to solicit horizontal video footage from Fedora events via an open call on Fedora Discussions to replace stock assets and enhance future video content.
• Icon Design Refinement: The Datagrepper interface icon will be simplified, moving away from complex line art to utilize color blocks and shading for improved visual clarity at smaller sizes.

Learn more about the Design team.

Docs

The Fedora Docs team is actively modernizing its infrastructure and continuous integration pipelines. A major focus is refactoring the local preview script (docsbuilder.sh) and exploring a shared Forgejo Actions workflow that utilizes a pre-built container image to enable fast, cross-referenced CI builds for individual pull requests. To address security issues in outdated containers, the team plans to transition container builds to Konflux and Quay.io, aligning with broader Fedora infrastructure practices. Additionally, the team is finalizing its migration to Forgejo ahead of the July 31 Pagure.io sunset, investigating monitoring solutions for staging build failures, and evaluating tools like CryptPad for collaborative draft writing.

To better distribute documentation maintenance and empower subject matter experts, the team launched a "Fedora Docs Captain" pilot program to embed documentation liaisons within specific groups, starting with the Kernel, Multimedia, and AI/ML SIGs. There are immediate opportunities for contributors to help refactor multiple contribution guides-including those for Quick Docs and new modules-to emphasize the modern local authoring workflow. The team is also working to unblock and refine the documentation translation processes alongside the localization team.

Decisions

• Repository PR and Forking Guidelines: During the June 30 meeting, the team agreed that pull requests should normally be submitted via a fork, particularly for changes requiring lengthy discussion and refinement. However, organization owners and content owners who maintain an article on an ongoing basis may submit pull requests from upstream branches or push directly. Repository settings will be adjusted to enforce branch protections, ensuring only owners can push to main and requiring at least one review approval before merging.

Learn more about the Docs team.

Internationalization

In a recent discussion, returning contributor Javier Blanco inquired about the current activity levels on the translation mailing lists. The community welcomed him back and clarified that the mailing lists are currently quiet because the majority of localization work is now handled upstream, with contributors often utilizing alternative communication channels such as Matrix and forums.

To provide deeper context on the state of the localization community, Jean-Baptiste shared two presentations detailing the structural health and tooling of open-source translation efforts. These included an analysis of language community health using 20 years of Fedora translation data and a proposal for new tools to improve translator efficiency. Contributors interested in improving localization workflows and community collaboration are encouraged to review these resources.

Learn more about the Internationalization team.

EPEL

This week, the EPEL team focused heavily on addressing security vulnerabilities through necessary incompatible updates and package retirements. Notably, caddy was updated across multiple branches to resolve 22 CVEs, and an incompatible update for routinator was proposed to address several high-severity vulnerabilities. Contributors are also discussing a proposal to drop the rust-rpki binary subpackage to simplify package maintenance. Furthermore, early planning discussions for EPEL 11 have begun, with current conversations centering around the challenges of maintainer ownership and content resolver workflows.

Decisions

• The steering committee approved an incompatible update for syncthing to v2 in EPEL 10.3 and 10.2. Because of outdated SQLite and Golang dependencies in older RHEL releases, syncthing will be retired in EPEL 8 and 9 around July 14 to mitigate unresolvable CVEs.
• The committee confirmed the rollout of the incompatible update replacing p7zip with 7zip in EPEL 9, which has been pushed to testing without automatic karma or time-based pushes to ensure adequate community feedback.

Learn more about the EPEL team.

ELN

The ELN SIG meeting on June 30, 2026, was brief due to low attendance and participants being occupied with other tasks, such as debugging EBS with Fedora Infrastructure. Consequently, no major subjects were discussed, and no formal decisions were made during this session.

For those looking to engage with the group, contributors are encouraged to bring topics for discussion to the next scheduled meeting, which will take place on Tuesday, July 7, 2026, at 12:00 EDT.

Learn more about the ELN team.

Atomic

The Fedora Atomic Initiative discussed a draft Change Proposal to unify all atomic and bootc variant pipelines into a single monorepo using Konflux. This consolidation aims to streamline infrastructure across teams by establishing a shared atomic tenant for bootc base images, Atomic Desktops, and potentially Fedora CoreOS. To manage the scope and avoid disrupting existing workflows, the migration will be iterative. The immediate focus is moving bootc images to the new forge to verify builds, which will be followed by dedicated change requests for official artifact signing and the broader pipeline unification.

In community discussions, interest continues to build around the proposal to create a systemd-sysexts SIG. This initiative presents a great opportunity for contributors to help design the official building, distribution, and documentation of systemd system-extensions, which are crucial for extending atomic systems with software that doesn't run well in containers or Flatpaks.

Decisions

• The team agreed to pursue a unified atomic Konflux tenant and monorepo to house current bootc base images, Atomic Desktops, and potentially future variants.
• The pipeline unification will be broken down into smaller, sequential change requests, starting with migrating bootc images to the new forge and establishing artifact signing before fully transitioning other variants.

Learn more about the Atomic team.

CoreOS

In the CoreOS meeting, the team reviewed upcoming Fedora 45 changes, noting that a GoLang update and an RPM 6.1 version bump will require dedicated tracking issues and investigation, while the adoption of PURL metadata is not expected to affect Fedora CoreOS. Contributors interested in packaging can engage with the ongoing work to support passing Butane configs directly to instances, which prompted a restructuring of how Ignition and Butane are maintained. For the broader Linux community, Podman 6.0 has officially landed in Rawhide and is ready for testing. Additionally, the forum proposal to create a systemd-sysexts Special Interest Group (SIG) continues to gather support from developers interested in building and distributing systemd system-extensions.

Decisions

• The team agreed to combine the Ignition and Butane spec files, making Butane a subpackage of Ignition and archiving the standalone Butane spec.

Learn more about the CoreOS team.

AI & ML

During their July 2nd meeting, the AI & ML SIG discussed upcoming packaging and testing plans, noting that the ollama 0.30.x update will likely be delayed until Fedora 46 due to upstream instability with llama-cpp. The group is actively seeking testing and packaging help to diversify supported llama-cpp backends, particularly for the upcoming Vulkan transition. In broader community news, there is an active proposal to evolve the SIG into the "Fedora AI Working Group" to better reflect its expanding scope in both hardware enablement and open AI best practices. Additionally, there is a large backlog of open tickets for packaging major AI frameworks and tools-including TensorFlow, Bazel, and various Python libraries-alongside early discussions about proposing a dedicated Fedora AI Spin and building hardware-enabled inferencing images.

To boost contributor engagement, the SIG is revamping its documentation to create a more welcoming onboarding experience and is forming a new "Skills Reviewers" sub-team to curate shared AI skills using the Agent Skills specification. The group also addressed the management of donated AMD GPU nodes (like gpu01), emphasizing the need for public documentation to clarify hardware allocation and CI usage. This initiative aims to ease bureaucratic friction, provide transparency on how community hardware is utilized, and make it easier for contributors to understand how they can leverage these resources.

Decisions

• @jflory7 will open a ticket to propose a new "Hardware" module for the documentation site to track and manage hardware donated for Fedora Infrastructure.
• @jflory7 will chair the next SIG meeting on July 16, 2026.

Learn more about the AI & ML team.

RISC-V

The RISC-V group focused heavily on expanding infrastructure and hardware support this week. Discussions are underway with the cloud vendor Scaleway to host potential Fedora Koji builders in their Paris datacenter, an effort being coordinated through RISE. Hardware availability for developers is also improving: the newly released Milk-V Titan boards are currently shipping to RISC-V engineers for Fedora use, which will further aid platform optimization and broader Linux ecosystem integration.

On the software front, active development continues on the Fedora Omni kernel to expand support for devices like the Muse Pi Pro and K3, while steady progress is being made on the Fedora RISC-V tracker. To avoid disruptive surprises, contributors should note ongoing 'fedora-devel' discussions regarding potential improvements to the Changes Process, as well as internal deliberations about implementing two-factor authentication (2FA) for packagers.

Decisions

• It was decided to provision an additional "K3" hardware unit (sponsored by CLE) to maintainer DavidA to serve as a new Fedora RISC-V Koji builder.

Learn more about the RISC-V team.

Security

The Security SIG held a meeting this week to welcome new members from Red Hat's Product Security and Open Source Office. The expanded team will focus on navigating the upcoming EU Cyber Resilience Act (CRA) and implementing practical, developer-centric security measures. The group also initiated a debate on the scope of the Security Docs repository, specifically whether it should consolidate all Fedora security topics or strictly house documentation actively maintained by the SIG to prevent stale content. This documentation discussion will continue in upcoming meetings.

For contributors looking to get involved, the SIG noted that help is needed with defining security policies, which are obligatory for the CRA Steward role. Community members can follow the published meeting agendas to see when topics of interest are being discussed or drop into open office hours to participate.

Decisions

• Agendas for upcoming meetings will be published in advance. If there are no agenda items, the scheduled time will serve as informal open-floor office hours.
• Formal decisions within the SIG now require a quorum of at least three member votes.

Learn more about the Security team.

Go

During the Go SIG meeting, members discussed the upcoming Go release and shared that a mass prebuild of Go 1.27rc1 has been completed; contributors are encouraged to review the prebuild results report to catch any potential regressions. The team also highlighted ongoing work on a new Go utility designed to test Kubernetes installations locally on VMs, which will help validate new Fedora Kubernetes releases (like 1.36) before deployment. Furthermore, participants praised Fedora's current approach to vendored Go packages, noting it provides a smoother packaging experience compared to other ecosystems.

In terms of packaging standards, the SIG reviewed Issue #67 regarding CGO_CFLAGS. A contributor proposed establishing default values for these flags that are consistent with Fedora's standard build practices, as some packages currently require manual configuration to build correctly. The team will investigate past configurations and work toward defining sensible defaults that packagers can easily override if necessary.

Learn more about the Go team.

Perl

This week's activity in the Perl group centered around package maintenance and compatibility pull requests. Notably, a pull request for perl-Module-Starter-Plugin-CGIApp was submitted to fix compatibility with Module::Starter 1.80+ author arrayrefs. Additionally, contributors opened PRs to prevent building Class::Storage::Debug in bootstrap mode for perl-SQL-Abstract and to utilize -any virtual provides for MariaDB/MySQL dependencies within perl-Test-mysqld.

Decisions

• The maintainer for perl-Module-Starter-Plugin-CGIApp decided against adopting the %autorelease and %autochangelog macros, requesting their removal from the pending compatibility pull request.

Learn more about the Perl team.

Rust

Michel Lind submitted a Request for Comments (RFC) to drop the rpki binary subpackage from the rust-rpki crate. These unneeded programs were accidentally shipped due to a bug in older versions of cargo2rpm (< 0.3.0) and unnecessarily complicate package maintenance by requiring frequent license audits for statically-linked dependencies.

Since the crate is currently only used by routinator, Lind proposed retiring the binary packages to simplify ongoing maintenance. As this counts as a package retirement, Lind is seeking clearance on the EPEL side and noted that the removal could be gated to only affect Fedora 45 and newer if required.

Learn more about the Rust team.

Other Discussions

• Future of the Fedora i3 Spin in Fedora Linux 45 (cross-posted to the devel and i3wm mailing lists): Justin Wheeler called for new maintainers to keep the i3 Spin alive for F45, noting light maintenance recently. Dan &Ccaron;ermák and Eduard Lucena stepped up to continue packaging and comps/bug tracking respectively, ensuring the Spin will continue to be produced.
• Hummingbird Community Meeting Notes - 25 June 2026: Laura Santamaria shared notes from the Hummingbird community meeting, discussing community growth, DevConfCZ recaps, AI integration with a "human-in-the-loop" approach, image requests, and LTS strategy. Adam Miller and Jorge Castro further discussed the potential of integrating AI agents natively into the OS via an OpenClaw experience.
• Some news about the Audinux activity for June: Yann Collette shared updates on the Audinux repository, highlighting the return of kernel-rt builds and listing 21 new packages (mostly audio plugins and tools) and 140 package updates added in June 2026.
• How can we improve the Changes Process?: Maxwell G proposed modernizing the Fedora Changes Process by moving away from the Wiki and wikitext to a Git-based repository using Markdown and structured metadata (like YAML/TOML frontmatter). The discussion highlighted frustrations with the current fractured discussions across mailing lists and Discourse, and the burden on the Change Wrangler, though some raised concerns about the maintenance of custom web apps versus using existing forges.
• F45 Change Proposal: Grub EFI For Confidential Computing (self-contained): Aoife Moloney announced a proposal to create an independent, minimal GRUB package for UEFI to boot Unified Kernel Images (UKIs) for Confidential Computing. The thread discussed the trade-offs of using an intermediate "bootstrap" kernel versus a minimal GRUB, with Lennart Poettering noting that Windows has proven PCR prediction viable for broad audiences and Linux is getting closer to that goal.
• How can I contact the crypto team?: Gordon Messmer inquired about adding AWS's s2n-tls and aws-lc to Fedora, noting modern crypto libraries are moving away from runtime configuration. Simo Sorce and others debated the risks of relying on corporate-owned libraries like aws-lc that don't integrate well with distribution policies, while acknowledging that upstreams like rustls are increasingly defaulting to them over OpenSSL.
• binary content in node_modules: Gordon Messmer asked about handling pre-built binaries and WebAssembly files bundled inside node_modules during Node.js package reviews. He suggested using a tool like npm2rpm to avoid bundling modules with native binaries, requiring them to be installed as system modules instead.
• Distribution conditionals in spec files: Florian Weimer proposed updating the Packaging Guidelines to explicitly permit macros like %fedora, %rhel, %centos, %epel, and %hummingbird. The discussion revealed a divide between maintainers who prefer a single spec file across multiple distributions (like LLVM) and those who find the resulting "macro jungle" harder to read and maintain.
• F45 Change Proposal: oo7 Secrets Service Provider (system-wide): Aoife Moloney shared a proposal to switch the default Secrets Service provider from KWallet and GNOME Keyring to oo7. Bilal Elmoussaoui (oo7 author) clarified that it automatically migrates existing keyrings and supports multiple keyrings, addressing concerns about compatibility and maintenance of the older daemons.
• Inactive packager script notifications from fork (and a related thread): Several active packagers received false-positive inactivity notifications. Jef Spaleta apologized, explaining that while testing the script's transition to the Forgejo API on a personal fork, the @username mentions in the ticket templates accidentally triggered live notifications.
• Other discussions included a call for a zig co-maintainer, a proposal to Disable Vendor Change by Default, the Council Bi-Weekly Meeting Agenda, packaging the JS Trix editor, a list of New packages in Fedora Linux, multiple review swaps requests across the lists, FCOS release related issues on ppc64le, the archiving of fedora-lorax-templates, dropping rust-rpki's rpki binary subpackage, the Council Statement on the Future of Community Initiatives (and duplicate), the expiration of the MPEG-4 Visual final patent, a proposal for Stratis Storage in Anaconda, a proposal for Bash Color Prompt 1.0, an invitation to the Java SIG Matrix room, and an issue with s390x cloud images hanging.

Orphaning packages

• List of long term FTBFS packages to be retired in August: Miro Hron&ccaron;ok posted the first reminder for packages failing to build from source since F42, which will be retired before F45 branching.
• Orphaned package wavemon updated to 0.9.7: Viktor Erdelyi provided a COPR build for the orphaned wavemon package, and Iñaki Ucar successfully unretired and updated it in Fedora.
• Question about the orphaned "fx" package: Emanuele Petriglia asked about the controversy that led to fx being orphaned and subsequently submitted a Bugzilla review ticket to package its new Go-based rewrite.
• Orphaned packages looking for new maintainers: An automated report listed packages that will be retired in six weeks unless adopted by a new maintainer.

Package updates

• [rawhide] fmt and spdlog upgrade/soname bump: Frantisek Zatloukal announced rebuilds for packages depending on fmt-12.1.0 and spdlog-1.17.0 in a side tag.
• [heads-up] libcamel soname version bump in evolution-data-server 3.61.1: Milan Crha completed the soname bump and side tag merge for evolution-data-server.
• [heads-up] updating onnx to 1.21.0 & onnxruntime to 1.26.0 in rawhide: Diego Herrera announced an upcoming soname and protobuf version bump for onnx and onnxruntime.
• RFC: incompatible update for routinator for Fedora and EPEL 9 and 10: Michel Lind announced an incompatible update to routinator 0.15.2 to fix multiple high-severity CVEs, including a path traversal vulnerability.
• Highfive 3.3.0 coming to rawhide: Ankur Sinha successfully updated highfive to 3.3.0.
• GNOME 51.alpha update: Milan Crha created a side tag for the GNOME 51.alpha update and invited other maintainers to include their related updates.
• xmlsec 1.3 update: Tomas Halman announced that the xmlsec 1.3 update has landed in Rawhide.
• Upgrade to sundials 7.8.0: Antonio Trande announced an upcoming upgrade to Sundials 7.8.0 in Rawhide.
• F45 Change Proposal: Ruby on Rails 8.1 (self-contained): Aoife Moloney forwarded a proposal by Vít Ondruch to update the Ruby on Rails stack to 8.1.
• F45 Change Proposal: GNU Toolchain Update (system-wide): Aoife Moloney forwarded Carlos O'Donell's proposal to update the GNU Toolchain to gcc 16.2, binutils 2.47, glibc 2.44, and gdb 17.2.
• F45 Change Proposal: Fontconfig 2.18 (system-wide): Aoife Moloney forwarded Akira TAGOH's proposal to update fontconfig to 2.18.

New contributor introductions

• Self Introduction: Simone: Simone (tollsimy), a computer engineer with a background in electronics, embedded systems, and cloud infrastructure, introduced themselves and expressed a desire to give back to the Fedora community.

06 Jul 2026 6:59am GMT

My onwards journey began at around 0600pm Indian Standard Time on 12th June 2026 when I departed for the Netaji Subhash Chandra Bose International Airport (CCU) in Kolkata. After my longstanding troubles with the travel agency, I was able to rebook the previously cancelled connecting flight from Dubai (DXB) to Prague (PRG). When I thought that I was finally out of the woods, my backpack was weighed at the Emirates desk for the first time. While my check-in luggage was well under the weight limit of 25 kilograms, my backpack ended up weighing a little more than 7 kilograms. Upon my declining to move my electronics into the check-in luggage, as that would have ended up being a safety hazard, I was finally able to make it to the immigration gates at around 0700pm Indian Standard Time.

Although the Fast Track Immigration Trusted Travellers' Programme would have helped me cut through the moderately occupied passenger queue, I decided to join the manual queue anyway as the digital kiosk wanted me to have my biometric entries registered in advance. Imagine having to verify your identity after doing so multiple times with the passport verification and visa registration! After a quick discussion about the requirements with the immigration staff, I was able to breeze through the security checks quite swiftly. With the first leg of my onwards journey, Emirates EK0573, departing at around 0900pm Indian Standard Time, I had about an hour before boarding began. To my surprise, it did start early at around 0750pm Indian Standard Time after I was done chatting with my family members.

Given that I had a dreadfully arduous eight-hour layover period ahead of me at Dubai International Airport (DXB), I initially planned on catching some sleep on the flight itself. Amidst munching on the served dinner and watching Oshi No Ko (2023), I had limited success with resting my eyes as the onwards flight moved closer to the first stop. As there was no hurry to make it to the next flight, I went for one of the twin seats at the very end of the aircraft, 50K. Chatting with my fellow passenger and dozing off right after, I did not realize how quickly the five hours passed, and I found myself landing at Dubai International Airport (DXB) at around 12:00am Gulf Standard Time. Unfortunately, my first flight did not land directly at the terminal gates and, hence, we had to board the transit bus instead.

It took around 30 to 40 minutes for the buses to get us to Terminal 3, and after a rather uneventful security check, I was back indoors. The time it took to get to the terminal gates helped me realize just how massive the area was - or conversely, just how slowly our transit bus was moving. I did not have any complaints as I had nothing to do for the eight-hour-long wait before my second leg kicked off. While I initially planned on getting myself a sleeping pod, I eventually decided to find myself a reclining area to sleep in near the silent area of Gate B26. After building rudimentary security for my travelling backpack so that I would get tugged awake in the rare occurrence of someone attempting to pull it away from me, I decided to try catching up on some sleep. Of course, you know just how it must have gone...

Those eight hours felt like eternity as I kept zoning in and out of my sleep state while the night grew darker and colder with the passing of time. In retrospect, I should have carried some warm clothing, which I ended up skipping this time because the summer season had me confused. But it felt a whole lot safer amidst a bunch of travellers struggling to catch some sleep, rather than being somewhere alone. The moment I was just about to catch some shut eye, I was nudged awake by a helpful person who thought I was waiting for the flight to Delhi departing at around 0355am Gulf Standard Time. While they apologized after I told them about my situation, I thanked them for their well-intentioned, caring gesture towards ensuring that their (potentially possible) fellow passenger was not left behind.

After about an hour of trying to sleep again, I eventually gave up on my attempts at around 0630am Gulf Standard Time and instead decided to browse the Dubai Duty Free Stores. As my flight was departing from Gate B31, that would mean that I could also slowly start moving towards the departure gate too. I also wanted to get something for my family and friends from there because I would be unable to do so on my way back with a layover of just 90 minutes. Using the public WiFi at the international airport behind a secure VPN allowed me to connect with my brother over a WhatsApp call. After making a couple of purchases for the house warming, I finally made it to the departure gate, where I could simply get to the second flight without queuing as the boarding had already begun by that time.

This time around too, I had to board a transit bus that took us from the terminal gates to Emirates EK0139, and even that took long. That explained to me why the boarding had begun sooner, as they had to compensate for the travelling time to the actual flight as well. Seated at 44K, I had a small talk with a fellow traveller from the Philippines while I tried to plug my work laptop into the power outlets. I also noticed a lot of travellers from East Asia flying into Prague, which was mostly an interesting observation to make. After multiple failed attempts at getting some power to my work laptop-even after using the plug converters offered by the flight stewardesses-I eventually had to stow it into my travelling backpack. That meant that I had to discover other ways to keep myself occupied for the next seven hours!

I knew that sleep had become quite the exorbitant affair at that point, and while I clearly needed some, there was no way in which I could have gotten it given just how the timezone shift had affected my internal biology. I continued chatting with the (rather overprepared) Philippines traveller, who had a full-blown travelling kit, all while continuing to watch Oshi No Ko (2023). Just like the fellow passenger from the first flight, I helped her with some pictures from the airplane window too. When it came to the meals, I intentionally kept it lightweight and strictly avoided alcoholic liquor to ensure that I was well hydrated. In between keeping myself entertained and zoning out of consciousness, I soon found myself nearing Václav Havel Airport Prague (PRG) at around 0100pm Central European Summer Time.

With zero transit buses to catch, as we landed directly at the arrival gates, I left for the automated immigration registration kiosks after bidding my fellow passengers farewell. There were manual checks too, which got expedited due to the presence of these automated border check kiosks, and I was able to pass through the massive queue in just about 20 minutes or so. As I observed that the passengers from East Asia were struggling with the language choices, I decided to stay back a little to help them pick the correct language using nothing but gestures to connect. While I initially planned on purchasing a Czech Republic SIM card from there, I decided to get to the hotel first because it had been 24 hours since I had left home, and some rest after checking in would do wonders in helping my body recover.

Using Uber's automated digital kiosk to book a rented cab and the public WiFi for authorization purposes, I was finally able to get to the Ibis Praha Mala Strana hotel by about 0200pm Central European Summer Time. This was the same hotel where I stayed the last time too, and it was just convenient to stay at a location which was barely a couple of minutes away from the event venue. I got in touch with the likes of Michal Konecny and Tomáš Hrčka after checking into Room 401, all while checking in with the likes of Kevin Fenzi and Justin Wheeler. One of the first things I worked on as I waited for Michal and Tomáš to become available was ensuring that the staging Fedora Badges deployment was working correctly, as I wanted to use that as an apparatus for experiments in the workshop the next day.

I witnessed my plans of getting some rest turn to blazing ashes before my eyes as I stepped out to meet Michal, who had just checked in at around 0300pm Central European Summer Time. We moved on to have a late lunch at an Asian restaurant in the Nový Smíchov Shopping Centre's food court, all while catching up after almost a year since meeting in person. Surprisingly enough, we ran into Aoife Moloney when we went downstairs into the TESCo supermarket to purchase some cold drinks. As Michal purchased some cookies to share during the International Candy Swap Event, I kept an eye out for SIM cards to purchase. I was lucky to find a Vodafone kiosk right after exiting TESCo, and I ended up getting one without even having to share my personal details or passport information, for that matter.

With my connectivity restored, Michal and I quickly visited the hotel to drop our things before heading out to the event venue. While the event venue had remained the same from the previous year, the institution got renamed from Vienna House Andel Prague to OREA Hotel Andel Prague due to the management change. Much akin to a corridor conversation during FOSDEM events, the two of us met up with Hristo Marinov, whom we caught up with before running into Emma Kidney at the same place too. Amidst the talks about Forgejo Runners for Fedora Atomic and heading to Brno for DevConf.CZ 2026, our circle became bigger with the joining of Lenka Segura and Tomáš. As I wanted to join Tomáš to prepare for the Fedora Forge interactive workshop the next day, I quickly left for the conference venue.

While there was nothing significant to be done at the event venue on that day as the event was starting the next day, going there definitely gifted us Clement Verna, with whom I was meeting again after almost three years. Leaving Hristo to have a chat with him after a swift introduction to the Fedora CoreOS team members, Michal and I ran into Daniel Mellado and Fernando Fernandez Mancera at an adjacent cafeteria. Since I could not visit the FOSDEM 2026 event, I was meeting them again after almost a year as well since the previous Flock event. After a quick chat with Kacper Skrzyński, the two of us went into a nearby bookstore as Michal wanted to redeem a discount coupon while buying two volumes of the Chainsaw Man (2018) manga at around 0500pm Central European Summer Time.

Coincidentally enough, we met up with Tomáš again at the Anděl crossing and, with Michal heading back to the hotel, Tomáš and I moved through Nový Smíchov Shopping Centre to make our way into the green hills behind it. With just how tucked in it was behind the low-height concrete structures, it was surprising how he knew about the location in the first place. Visiting a densely vegetated park area also reminded me of us doing the same thing about a year back, although that was a different location and we had more folks around. The peaceful ambience of the green zone allowed us to work on the workshop preparations all while catching up on our conversations. Even though I initially planned on demonstrating the private issues feature, I ultimately ended up scrapping it in favor of more interaction.

Tomáš' initial dining plans with the Fedora Quality team members did not come to fruition as they seemed to have gone for food already. After some more visits to the Nový Smíchov Shopping Centre to purchase some mineral water, the two of us headed over to a nearby quaint Vietnamese-themed restaurant called Old Hanoi at around 0700pm Central European Summer Time. With some delicious bites after the dry meat I had on the incoming flight, and even more fun conversations, this felt like the right way to kick off the next three days of community celebrations at Flock To Fedora 2026. I had already been running on fumes while being awake for almost over 30 hours by that time, so I decided to call it a day a little early at around 0830pm Central European Summer Time to get some well-deserved rest.

05 Jul 2026 6:30pm GMT

"Today's the fourth of july. Another june has gone by."

(appologies to Amiee Mann).

Here's another short recap of the last week from me. I was off Thursday, and Friday was a holiday, and I'm off next monday too, so this was a short week.

04 Jul 2026 7:35pm GMT

Here is the list of sessions that I participated in during Flock To Fedora 2026, which was organized from June 14th 2026 to June 16th 2026 in Prague, Czechia.

Fedora Badges Revamp Project Progress Update

Metadata

• Verdict: Rejected
• Location: Unavailable
• Schedule:
  • Undefined
• Submitters:
  • Akashdeep Dhar
  • Shounak Dey
• Type:
  • Short presentation
    25 minutes
• Themes:
  • Empowering Collaboration: Tools and Practices for Fedora's Future
  • Welcoming New Voices: Pathways for Fedora Contributors
  • Driving Innovation: Fedora and Emerging Technologies
• Complexity:
  • Beginner
    Anyone can follow along without previous context
• Resource:
  • https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/VQ87RYXJJCBYGK39XAKQX8CMZHGF7SXZ

Abstract

How do you replace the engine of a moving car? Or better yet, how do you replace the heart of a living human? For decades, Fedora Badges has been a crucial partner for gamifying contributor engagement, but its ageing frontend technologies and backend infrastructure were becoming unmaintainable. This talk dives into the multi-year project to completely revamp Fedora Badges, piece by piece, while having it run just fine with sustainably equivalent feature parity. We will explore the transition from a legacy system to a modern architecture with our move from synchronous backend libraries like Flask to asynchronous backend libraries like FastAPI and from static templating systems like Jinja to progressive interface frameworks like React.

Particulars

• Identifying technical debt and associated risks of maintaining legacy systems past their end-of-support timeline
• Why we moved on to a modern stack centered around asynchronous processing and progressive application
• Moving code was not hard, moving data was - Complexities and learnings of the runtime active migration procedure
• Evolving system administration from legacy centered virtual machines to cloud native OpenShift deployments
• Demonstration and interactions of the live deployment of Fedora Badges, with the plans for further development
• Interactive feedback from the participants on both the backend infrastructure and frontend technologies

Takeaways

• Strategies for tackling massive technical debt acquired through years in established open source projects
• Real world lessons on live migration of databases and tooling using examples from Fedora Infrastructure
• Understanding the benefits of modern stack for community tooling and onboarding community contributors
• Balancing technical innovation with community continuity - You can revamp, but should you revamp?
• Encouragement and retention of voluntary contributors through gamifying aspects of community activities
• Strategies for ensuring the longevity of the project codebase by working with various community disciplines

References

• Update on Fedora Badges Revamp Project - https://gridhead.net/update-on-fedora-badges-revamp-project/
• Tahrir - Fedora Infrastructure - GitHub - https://github.com/fedora-infra/tahrir
• #badges-team topics on Fedora Discussions - Discourse - https://discussion.fedoraproject.org/tag/badges-team
• Fedora Badges - Advanced Reconnaissance Crew - https://fedora-arc.readthedocs.io/en/latest/badges/index.html
• Discourse as frontend for Fedora Badges - Discourse - https://discussion.fedoraproject.org/t/so-we-investigated-discourse-to-confirm-if-it-is-worthy-of-be...
• Getting Fedora Badges Back in Shape - Discourse - https://discussion.fedoraproject.org/t/getting-fedora-badges-back-in-shape/42942

Fedora Badges Revamp Project - Design and Development Workshop

Metadata

• Verdict: Accepted
• Location: Opal hall, OREA Hotel Andel's Prague
• Schedule:
  • 14th June 2026, 0900am - 1040am CEST
• Submitters:
  • Akashdeep Dhar
  • Chris Onoja Idoko
• Type:
  • Workshop / BoF
    1.8 hours
• Themes:
  • Empowering Collaboration: Tools and Practices for Fedora's Future
• Complexity:
  • Beginner
    Anyone can follow along without previous context
• Resource:
  • https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/HUXM7JYBFJMRUMDQXVBWPCBYD9XENEM3

Abstract

How do you replace the engine of a moving car while simultaneously replacing its paintjob? For over a decade, Fedora Badges has been the cornerstone of gamifying contributions and engaging achievements. However, as we head into 2026, the project faces a double deficit: crippling technical debt on the backend, and a trust problem regarding undeployed modern artwork redesigns.

Our hybrid session dives into the multi year perspective of the Fedora Badges Revamp Project and the artwork design mentoring initiative. In the first half, we will explore the live migration of legacy synchronous systems to a modern application stack, on a staging environment. In the second half, we will find ourselves leveraging the Forgejo Migration to get redesigned artworks online.

This "Design To Deploy Sprint" takes advantage of the recent aggressive move away from Fedora Pagure to Fedora Forge, to finally integrate our lost modern style guidelines into the upcoming Fedora Badges revamp. Thus, emerging from our past coordination disconnects to not just move code and data, but evolve the reward system that unmistakably, establishes the Fedora Project brand.

Questions

• Primary question: How can we simultaneously modernize the legacy Fedora Badges system for the Fedora Forge era while designing modern gamification incentives to revitalize various subprojects and SIGs?
• Engagement question: How do we retroactively honor the modern badge artwork redesigns to restore the trust among the community designers while keeping up with the evolving requirements of the communities?

Relevance

• Experience sharing: Understanding the user personas interacting with the Fedora Badges service platform, their happinesses and their pain points, to find targets to pursue and potentially improve.
• Coordination healing: To openly acknowledgement the disconnection and discover ways to ensure that the efforts do not go unnoticed and time does not go sidelined due to more pressing affairs.
• Tangible progress: To give a milestone update to the community about the engineering progress and design efforts - all while setting the community expectations on the project's future.
• End-to-end onboarding: To produce a verified batch of production-ready artwork and provide a hands-on experience to the attendees so that they can immediately start contributing to the design.

Methodology

• Part 1 - The Engine (Technical walkthrough)
  • Identifying the potential risks of continually maintaining legacy systems and finding reasons to modernize the stack
  • Recognizing the complexities of the migrating data and evolving service system administration to cloud-native deployments
  • Interacting with the staging environment and discussing on balancing technical innovations with community continuity
• Part 2 - The Paintjob (Design modernization)
  • Reviewing the legacy guidelines against the modern ones and capitalizing on the Forgejo migration for the artwork overhaul
  • Collaborating with the attendees to create/refine existing badge artworks using the modern artwork design guidelines
  • Uploading the refined badges design artwork to demonstrate the roadmap for the replacing legacy badges artwork process

Forging Fedora Project's Future With Forgejo

Metadata

• Verdict: Accepted
• Location: Sapphire hall, OREA Hotel Andel's Prague
• Schedule:
  • 14th June 2026, 1100am - 1240pm CEST
• Submitters:
  • Akashdeep Dhar
  • Tomas Hrcka
• Type:
  • Workshop / BoF
    1.8 hours
• Themes:
  • Empowering Collaboration: Tools and Practices for Fedora's Future
• Complexity:
  • Intermediate
    Some background knowledge/context is required
• Resource:
  • https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/UGZ9KQXDHNX7ZURGENPH3VMZQCMBJ93U

Abstract

Fedora Project is undergoing significant infrastructure changes that affect everyone from distribution users to individual contributors - that is, migrating from Pagure to Forgejo as its primary Git forge for both source code and package sources. Our talk chronicles the journey from the early days of collective debating between GitLab and Forgejo with Fedora Council, through the ongoing migration of thousands of repositories with Fedora Infrastructure.

While the initiative began due to the need to move away from Pagure, it gradually evolved into one that also aimed at fixing the long-standing pain points faced with workflows. We got the opportunity to streamline the processes that made sense about a decade back, and have since then, slowly started getting in the way of contribution. This also allowed us to contribute back to the Forgejo upstream with the features that would end up benefiting all.

This workshop aims to progress along with the work that we have been up to so far with creating solutions for migrating projects from Fedora Pagure and Package Sources. Participants can take advantage of the learnings on building compatibility bridges, CI/CD workflow modernisation, granular permission models, existing toolchain integration and comprehensive documentation writing, while working on building the Fedora Forge platform.

Resources

• Fedora Moves Towards Forgejo - Fedora Magazine https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/
• Announcing the Soft Launch of Fedora Forge - Fedora Community Blog https://communityblog.fedoraproject.org/announcing-the-soft-launch-of-fedora-forge/
• Forging Fedora's Future with Forgejo - Fedora Community Blog https://communityblog.fedoraproject.org/forging-fedoras-future-with-forgejo/
• Git Forge Initiative - Fedora Council - Fedora Wiki https://fedoraproject.org/wiki/Initiatives/Git_Forge_Initiative_2025
• Dist Git Move - Advanced Reconnaissance Crew - Read The Docs https://fedora-arc.readthedocs.io/en/latest/dist-git-move/index.html
• Dist Git Comparison - Advanced Reconnaissance Crew - Read The Docs https://fedora-arc.readthedocs.io/en/latest/dist-git-comparison/index.html

Fedora Mentor Summit: Lunch and Learn Matching

Metadata

• Verdict: Accepted
• Location: Lunch area, OREA Hotel Andel's Prague
• Schedule:
  • 14th June 2026, 1245pm-0145pm CEST
  • 15th June 2026, 0100pm-0200pm CEST
  • 16th June 2026, 0100pm-0200pm CEST
• Submitters:
  • Akashdeep Dhar
  • Cornelius Emase
  • Jona Azizaj
  • Justin Wheeler
  • Kevin Fenzi
  • Luis Bazan
• Type:
  • Social event
    45 minutes
• Themes:
  • Freedom: The Open Frontier
  • Friends: Our Fedora Story
  • Features: Engineering Fedora's Core
  • First: Blueprint for the Future: Fedora Linux 45 & 46
  • Empowering Collaboration: Tools and Practices for Fedora's Future
  • Welcoming New Voices: Pathways for Fedora Contributors
  • Driving Innovation: Fedora and Emerging Technologies
• Complexity:
  • Beginner
    Anyone can follow along without previous context
• Resources:
  • https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/UGZ9KQXDHNX7ZURGENPH3VMZQCMBJ93U
  • https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/YKEZMKUWPAXN8UQYYPQGZALKGEBPGVTW
  • https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/N8FKD9BGNMCJSVEEVCP9EUPFVB3SKFZS

Abstract

Mentorship has always been a big part of what makes Fedora special. After a great response last year, we're bringing back the Mentor-Mentee Lunch at the Fedora Mentor Summit at Flock 2026, with a small tweak. A casual lunch matching session where everyone can meet face-to-face, share stories, swap ideas, and connect over common goals.

Instructions

• Anyone attending Flock can join.
• Participants are grouped based on topic of interest, no pre-signup required.
• Each day features different topics, so people can explore multiple areas across the event.
• Need a conversation starter? We'll have a few prompts ready to help break the ice.
• Take a group selfie during lunch and you'll earn a Fedora Badge as a fun keepsake.

Topics

• Day 1 - Sunday, 14th June 2026
  • Documentation
  • Operations
  • Development
  • Marketing
• Day 2 - Monday, 15th June 2026
  • Packaging
  • Infrastructure
  • Interpersonal Skills
  • Events
• Day 3 - Tuesday, 16th June 2026
  • Artificial Intelligence
  • Governance
  • Release Engineering
  • Design

No formal structure - just good food and good conversation with someone else who cares about growing the Fedora community.

Fedora Council Strategic Proposals

Metadata

• Verdict: Accepted
• Location: Plenary hall, OREA Hotel Andel's Prague
• Schedule:
  • 15th June 2026, 1100am - 1240pm CEST
• Submitters:
  • Akashdeep Dhar
  • Aleksandra Fedorova
  • Aoife Moloney
  • Jef Spaleta
  • Jona Azizaj
  • Justin Wheeler
  • Miro Hroncok
  • Peter Boy
  • Petr Bokoc
• Type:
  • Long presentation
    55 minutes
• Themes:
  • Empowering Collaboration: Tools and Practices for Fedora's Future
  • Driving Innovation: Fedora and Emerging Technologies
• Complexity:
  • Intermediate
    Some background knowledge/context is required
• Resource:
  • https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/UTX3M9QDPCM3DCN8ARXXBXPHKT8K97XB

Abstract

The Fedora Council would like to provide an overview of in-progress draft proposals to the community and hold a live community question and answer session to help refine the proposals further before adoption as project policy.

This proposal is an action item from the Fedora Council Strategic Summit to ensure we take advantage of Flock as a key milestone to communicate the status of strategic policy work items that were agreed to as part of the meeting.

Fedora Mindshare Townhall Session - From Conferences To Recognition

Metadata

• Verdict: Accepted
• Location: Plenary hall, OREA Hotel Andel's Prague
• Schedule:
  • 16th June 2026, 0245am - 0345pm CEST
• Submitters:
  • Akashdeep Dhar
  • Aoife Moloney
  • Emma Kidney
  • Gregory Sutcliffe
  • Joseph Gayoso
  • Justin Wheeler
  • Luis Bazan
  • Mat H
  • Samyak Jain
• Type:
  • Long presentation
    55 minutes
• Themes:
  • Welcoming New Voices: Pathways for Fedora Contributors
• Complexity:
  • Beginner
    Anyone can follow along without previous context
• Resource:
  • https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/JX8ZPEBRMVMZQTV3EDPEHHUH7W7BGYL7

Abstract

From getting resources for swagpacks to laying foundations for conferences, the Fedora Mindshare Townhall Session creates an inclusive and structured space for attendees to meet with their representatives, discuss community health, talk engagement strategies, and identify recognition opportunities and evaluate regional growth. This session will briefly cover what the committee has been up to since the last Flock To Fedora conference, before opening up the space for curious questions and open conversations.

While focusing on surfacing challenges and exploring opportunities related to contributor experience, crossteam collaboration, event impacts and outreach effectiveness, participants will be encouraged to share perspectives from their home regions, propose improvements to the committee's processes, and identify concrete next steps that can strengthen the Fedora Project's global community over the next release cycles. Hence, this session intends to take full advantage of both the participants and attendees present at the event.

Fedora Mentor Summit: Contributor Recognition

Metadata

• Verdict: Accepted
• Location: Plenary hall, OREA Hotel Andel's Prague
• Schedule:
  • 16th June 2026, 0400pm-0420pm CEST
• Submitters:
  • Akashdeep Dhar
  • Cornelius Emase
  • Jona Azizaj
  • Justin Wheeler
• Type:
  • Short presentation
    25 minutes
• Themes:
  • Empowering Collaboration: Tools and Practices for Fedora's Future
• Complexity:
  • Beginner
    Anyone can follow along without previous context
• Resources:
  • https://cfp.fedoraproject.org/flock-to-fedora-2026/talk/review/JPWK8PH3QKMBWXGQHPXBGKUBXRECR8AP

Abstract

Fedora is built by contributors working across many areas such as development, documentation, design, quality assurance, infrastructure, user support, mentoring, and outreach, many of which happen behind the scenes. The Fedora Contributor Recognition Program was created to recognize and reward outstanding contributions to the Fedora community. In this session, we will explain how the program works, from the open nomination process to the review and selection process carried out by experienced Fedora contributors using criteria such as impact, quality, innovation, and community engagement. We will also share lessons learned from running the program last year. The session will conclude with the announcement of this year's winners, celebrating their work and highlighting the many ways people contribute to Fedora.

03 Jul 2026 6:30pm GMT

Hoy me dió por tener corriendo mi daemon de BitTorrent preferido: Transmission, como un servicio de sistema. La neta, correrlo de manera global con el usuario transmission por defecto está chido si estás en un servidor dedicado, pero en mi compu personal (mi Fedora 44 de diario) es una lata. Yo quería que leyera mis configuraciones locales, que las descargas cayeran directo en mi carpeta personal (~/Downloads/torrents) y, sobre todo, que se levantara nomás cuando yo inicio mi sesión de usuario.

Así que me di a la tarea de crearle un servicio de usuario a nivel de systemd para quitarme de broncas. Aquí te cuento de volada cómo lo armé pa' que no le batalles.

03 Jul 2026 4:45pm GMT

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 29 June - 3 July 2026

Fedora Infrastructure

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

• Planned Outage - download-ib01, torrent, people outage - 2026-06-25 20:00 UTC
• Planned Outage - server moves - 2026-06-25 14:00 UTC
• RFE: Add a role for deploying through OpenShift deployment
• rhel10: colo_virt virthosts
• Migrate ELNBuildSync to Fedora Infrastructure OpenShift

CentOS Infra including CentOS CI

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

• Deploy staging el10 signing host for Stream to validate worfklow
• Rebuild all needed pkgs for el10 signing service
• all s390 builders for Stream are unreachable (blocking all rpm build tasks)
• abuse on website
• Init new donated/sponsored server for CentOS infra
• Update Firmware in Risc-V P550's
• mirror.dsp-lad.space add to mirror list
• Automotive SIG - key rotation
• Change AltImage documentation to use gitlab.com repo
• Update boot-server ansible role for el10
• Renew our yearly RH subscription for CDN access
• migrate status.centos.org to el10

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

• Continued investigation into building a Fedora container base image using Konflux.
• Continued work on remaining Pagure -> Forgejo migrations.
• F45 release cycle is set to begin soon, starting with Mass Rebuild in the middle of July. This will require some prep work next week.

RISC-V

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

• Discussion with Scaleway (a cloud vendor in France) for potential Fedora Koji builders in their Paris datacenter. To be coordinated via RISE.
• Hardware
  • Coordinated shipping another "K3" hardware to DavidA (one of the Fedora RISC-V maintainers). This will be used as another RISC-V Koji builder. Sponsored by CLE.
  • Milk-V Titan hardware is now available to buy. A handful of machines are being shipped to a couple of RISC-V engineers, including for Fedora use.
• Community work
  • Fedora Omni kernels for Muse Pi Pro hardware discussion with Trevor from Baylibre and Jason (Fedora RISC-V kernel)
  • Marcin (hrw) Juszkiewicz continues to chip away at the Fedora RISC-V tracker
  • Fedora Omni kernel work continues, with support for Muse Pi Pro, K3, and more: Jason Montleon and Jennifer Berringer
• Other:
  • Discussions on 'fedora-devel': "How can we improve the Changes Process?" thread
  • A lot of internal discussion about 2FA for packagers
  • Several internal and upstreams meetings

AI

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

• Aurelien Bompard improved the This Week in Fedora script to include the CLE status reports

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

• Lots of PTO: psklenar on extended PTO, kparal and adamwill each took some post-travel PTO days. Also post-event travel, bureaucracy (trip and expense reports) and decompression cut into work time for most
• Compose-critical package script now in MVP state - see pull request, it works and does useful stuff but needs more refinement
• Dist-git PR test feature progress: status report now works, still needs polish and tests
• Tool work: CI optimization in blockerbugs, reverse proxy handling improvement in testdays-web
• Significant bug investigations: grub2 changes broke image builds, haveged update could cause boot failure

Forgejo

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

• Forge 15.0.3 in staging
• New runner for koji organization
• Continued work on Private Issues: public/private comments
• Zabbix template developed to monitor health of runnerhost VM, moving onto the forge instance next.

EPEL

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

• Updated caddy in f44, f43, epel10.3, and epel10.2 resolving 22 CVEs
• EPEL 11 planning discussions

UX

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

• Open Call for Fedora Event Video Footage! [discussions post]
• Feedback period for F45 wallpaper has just ended. Here is the current iteration.

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

03 Jul 2026 11:00am GMT

Version 8.6.0alpha1 has been released. It's still in development and will soon enter the stabilization phase for the developers and the test phase for the users (see the schedule).

The RPMs of this upcoming new version of PHP 8.6, are available in remi repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, CentOS, Alma, Rocky...) in a fresh new Software Collection (php86) allowing its installation beside the system version.

As I (still) strongly believe in SCL's potential to provide a simple way to allow installation of various versions simultaneously, and as I think it is useful to offer this feature to allow developers to test their applications, to allow sysadmin to prepare a migration or simply to use this version for some specific application, I decide to create this new SCL.

I also plan to propose this new version as a Fedora 46 change (as F45 should be released a few weeks before PHP 8.6.0).

Installation :

yum install php86

⚠️ To be noticed:

• the SCL is independent from the system and doesn't alter it
• this SCL is available in remi-safe repository (or remi for Fedora)
• installation is under the /opt/remi/php86 tree, configuration under the /etc/opt/remi/php86 tree
• the FPM service (php86-php-fpm) is available, listening on /var/opt/remi/php86/run/php-fpm/www.sock
• the php86 command gives simple access to this new version, however, the module or scl command is still the recommended way.
• for now, the collection provides 8.6.0-alpha1, and alpha/beta/RC versions will be released in the next weeks
• some of the PECL extensions are already available, see the extensions status page
• tracking issue #342 can be used to follow the work in progress on RPMS of PHP and extensions
• the php86-syspaths package allows to use it as the system's default version

ℹ️ Also, read other entries about SCL especially the description of My PHP workstation.

$ module load php86
$ php --version
PHP 8.6.0alpha1 (cli) (built: Jun 30 2026 11:28:16) (NTS gcc x86_64)
Copyright © The PHP Group and Contributors
Built by Remi's RPM repository  #StandWithUkraine
Zend Engine v4.6.0-dev, Copyright © Zend by Perforce
    with Zend OPcache v8.6.0alpha1, Copyright ©, by Zend by Perforce

As always, your feedback is welcome on the tracking ticket.

Software Collections (php86)

03 Jul 2026 5:38am GMT

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

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

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

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

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

ℹ️ The packages are available for x86_64 and aarch64.

⚠️ PHP version 8.1 has reached its end of life and is no longer maintained by the PHP project.

🛡️ These Versions fix 3 security bugs (CVE-2026-12184, CVE-2026-14355), so the update is strongly recommended.

Version announcements:

• PHP 8.5.8 Release Annoucement
• PHP 8.4.23 Release Annoucement
• PHP 8.3.32 Release Annoucement
• PHP 8.2.32 Release Annoucement

ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.5 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.5/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.5
dnf update

Parallel installation of version 8.5 as Software Collection

yum install php85

Replacement of default PHP by version 8.4 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.4/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.4
dnf update

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

• Fedora Rawhide now has PHP version 8.5.8
• Fedora 44 - PHP 8.5.8
• Fedora 43 - PHP 8.4.23

⚠️ To be noticed :

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

ℹ️ Information:

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

Base packages (php)

Software Collections (php83 / php84 / php85)

03 Jul 2026 4:31am GMT

02 Jul 2026 10:00pm GMT

I'm part of a project that's been hibernating longer than many projects have existed. As part of awaking from slumber, the project's leadership decided to adopt a code of conduct. Like me, they believe that it's a necessary starting point for a community in 2026 (or whatever year you read this) and a rare exception to the "don't add policies until you need them" rule.

Some people, as is usually the case, questioned the need for a code of conduct this early. The project is small, barely active, and fairly collegial. Why bother? As I've written before, planning ahead is the most important part of code of conduct enforcement. The worst time to figure out how to deal with bad behavior in your community is while you're trying to deal with bad behavior in your community.

But how large does a project really have to be before it needs a code of conduct? I'm tempted to say "one person. Maybe two." That's a justifiable answer because a code of conduct defines the acceptable behavior for everyone who interacts with the project. It's not just for core contributors; it's for everyone who stops into a chat channel, files an issue, submits a pull request, and so on. As long as there's one person for someone to interact with, a code of conduct is a reasonable part of the project's governance.

A better answer might be "three people". This means that if two people are having trouble, there's one person to address the issue.

As I said above, a code of conduct should be part of the initial foundation of a project. It's just as important as git init to building a healthy, sustainable open source community. This means that no project is too small to have a code of conduct.

This post's featured photo by krakenimages on Unsplash.

The post What size project needs a code of conduct? appeared first on Duck Alignment Academy.

02 Jul 2026 12:00pm GMT