DEV Community: Rodolfo Olivieri

Let’s talk about: Goose!

Rodolfo Olivieri — Fri, 19 Dec 2025 17:20:00 +0000

In today’s post I would love talk with you all about an exciting open source project, Goose.

But before we deep dive on why Goose is so amazing, let me give you some backstory context first.

Let’s start from the beginning

Back in September, I got a task at my job in Red Hat to research about new upstream AI clients. As many of you may imagine, there are dozens and dozens of choices in the wild for you to pick your favorite, however, the intention behind this was to join forces with such community and initiate an effort to bring to Fedora and later to RHEL this upstream client.

This is not an easy task, as just “yeah, this feels good!”. You need some data, research, consideration and a bunch of other things to keep in mind. So, back in September, I started researching the different variations of upstream clients, with the intention to bring one of them to Fedora, and that’s when I landed my eyes on Goose.

Some of my team mates were already using Goose for some sporadic tasks here and there, but neither of us actually had an opinion on it other than “It looks pretty good!”.

I have also to add in this context, that, even though I’m working for RHEL Lightspeed, a team primarily dealing with AI toolings, I understand that the primary thought is that I’m a die hard AI user. Well, hate to say, but… not that much.

I have been using more AI lately for some side projects and searching, but I’m not the kinda of person that lies all my coins on this technology. I think it’s useful, for sure, if you use it with caution and for specific actions, but, I will reserve myself to talk about it in another post in the future.

Phew! Much context, right? Let’s jump to the good part now.

What were we looking for in the research?

Primarily, we were looking out for an LLM client that could match the following basic criteria:

Stdio redirection
File attachments
Interactive mode
Simple question asking
History management
Shell bindings
MCP support

I know this does not look an extensive or surprise to any one, but we figured out that for a good LLM client, this was the most basic feature support we could even ask for. In our conception, any LLM client, to be considered “usable”, would indeed check each of those criteria above.

Of course, all LLM clients out there have a miriad of features available, some of them going even way beyond than we can imagine, but one requirement was the most crucial for us. The community around the project.

Which clients were considered in the research?

Well, we did a long list of analysis:

Project Name	SCM URL	License	UXD Considerations	Other Details	Pros/Cons
Goose	GitHub	Apache	👍 Session-based (modal) interaction method by default, with direct interaction available

👍 Built-in themes, but unclear on how custom theming works

😐 Desktop counterpart (does this provide the same, full functionality?), web interface as well

😐 Possible opportunity for rich onboarding — existing configuration menus are good | Goose feels like the most complete project on the list. It has all the tools, functionality and features that we may require. (Written in Rust) | 👍Multi-provider support

👍 Custom provider

👍 MCP client

👍Extensions support (Bultin and community)

👎Different tech stack than the team knows |
| Gemini CLI | GitHub | Apache | | Since this does not offer multi-provider support, we would need to fork the proejct and continue on our own. While this is an option, we may lack the “contribute back to the community” aspect of our work, and we might lose new features due to being harder to rebase. | 👎No multi-provider support

👍 MCP client

👍 Bulti-in useful tool calling out of the box

👍 Focus on security |
| LLM | GitHub | Apache | | This is one of the most interesting projects we have in the list, but, it does not have mcp support (as of now). It would be a great fit if we didn’t had to have mcp as required feature.

Also, it feels to me that this integrates very well with other datasette projects, so it would be a case where we would need to ship this project, plus a couple of more. | 👍Multi-provider support

👎Not an MCP client |
| QWEN Code | GitHub | Apache | | It falls under the same category as any other gemini-cli based clients. It has a lot of functionality, it looks good, but in the end, there is no real multi-provider, we would need to fork and continue work separated from the community, and all else | 👍Has MCP capabilities in the client

👍Multi-provider support |
| Open Code | GitHub | MIT | | We would need to fork the project as it does not accept core functionality PRs.

Nanocoder has a pretty good statement about opencode that I think it’s worth to document here: https://github.com/Nano-Collective/nanocoder?tab=readme-ov-file#how-is-this-different-to-opencode | 👎Does not accept Core PR |
| Crush | GitHub | FSL-1.1-MIT | | Some controversy about git history rewrite | 👎Not so open-source license

👎Does not feel like an CLI app |
| Codex | GitHub | Apache 2.0 | | Same problem as the gemini-cli ones. We would need to fork in order to use it. | 👍MCP client support

👍MCP server support (experimental)

👎Multi-provider is not supported |
| Terminal AI | GitHub | MIT | | The project feels very configurable and the look/feel is very intuitive. However, the “assistant” mode is experimental for now, and is subject to change. | 👍It is very intuitive

👎MCP support is experimental (assistant mode) |
| Nanocoder | GitHub | MIT | | If the current directory you’re running nanocoder does not have a agents.config.json, nanocoder won’t work. This make the user to be stuck on the same directory, or move the configuration file everywhere with them. | 👍MCP client support

👍Multi-provider support

👍Very community-based

👎It works on a directory based setup |
| copilot-cli | GitHub | GitHub | | Not really open source | 👎Source code is not available yet

👎License does not tell much |
| aichat | GitHub | Apache 2.0 or MIT | 👍Direct interaction method by default, with session-based (modal) available

👍Theme support

😐Current onboarding is minimal | MCP Support is not “native”. One have to use https://github.com/sigoden/llm-functions/tree/main/mcp/bridge to configure MCP | 👎MCP is supported as part of external project

👍Multi client support

👍Has an RAG ingestion tool |
| Fabric | GitHub | MIT | | Fabric is a very different tool from the rest of the tools in this table, but I would say that if we want to push this forward, we would need to customize the way it works to “behave” like a tool calling/question asking software.

Right now, fabric is pretty good in some general knowledge fields, like the “extract wisdom from text” and a couple of other defined ones.

It also has “limited” mcp support, and by “limited”, I mean, it only works with what they have built in the codebase. We can’t really plug other servers or tool calling to it without modifying the code to support. | 👍Very customizable

👍Multi provider support (including ollama)

👎Not really a tool for asking question, but could be extended for that

👎Limited mcp support. |

A small disclaimer: The UXD team got pulled in to the research in the last minute, so, that’s why we only have so few considerations on this column. We would like to have more, but due to time constraints, I asked them to limit the analysis to Goose and AIChat.

While this research was proposed and directed to be released on Fedora mindset, our goal is also to bring this LLM client to RHEL, following the cascade model of packaging, meaning that, we will start in Fedora and get our way down until RHEL Extensions¹.

flowchart LR
    Fedora-->EPEL
    EPEL-->RHEL-EXTENSIONS[RHEL Extensions]
    EPEL-->RHEL-REPOS[RHEL AppStream?]

This is very important to keep in mind because we want to provide to our customers something that meets the following criteria:

Can be customizable
Has multi provider support (ollama, gemini, vertex, anthropic, etc…)
Is open source
Cert based authentication

And when we thought about the above criteria, we decided to split the research in two parts, the forking model and the non-forking model , what is that you may think? Let’s see each of them below.

A quick side note: We were also looking to be partners in this community, meaning that, whatever we decided that is the project we wanted to bring to Fedora and way down to RHEL, we would like to give back to the community and push patches, bugfixes and etc. We don’t just want to pick something, package, and call it a day. We want to be involved with them and make sure that we are causing an positive impact in this upstream project.

Forking model

The forking model is what we understand we would need to literaly fork the upstream project, to patch the source code to add the above criteria you just read. While this was a valid option, we tried to avoid this at all cost, because now, we would have to support a full product that we are not familiar with the code, and managing all the rebases on top of our patches and etc. If it was just a configuration file here and there, this forking model would be probably viable, but we are talking about mulit provider support, cert based authentication and etc. You can imagine how painful it would be to go down that route. Although this was something we wanted to avoid at all costs, we still researched and looked into it, just to have an idea of what is out there.

This is a very recurring model that most folks use againstgemini-cli, while this approach works on most of the cases, we would fall behind on innovation and giving back to the community. For instance, if gemini-cli implements a new feature that will be needed by our customers, it would become very hard for us to rebase and pick their changes, since our fork and theirs would have diverged so much at some point.

The following upstream projects fit in this category of forking model:

All of the above are in the “state of art” LLM clients. They are all pretty good, but, if we want to have customization, we would need to fork it 🙁.

Comparative analysis

Here is a comparative analysis of gemini-cli, qwen-code, opencode, and codex (OpenAI’s Codex CLI / agent offering).

Project	Description	Architecture	Maturity
gemini-cli	Google’s open-source AI agent in the terminal, exposing Gemini capabilities (code, search, tools, etc.).	Node.js / TypeScript (CLI), MCP support, integration with tools, search grounding, toolchain	High profile (Google-backed), ~8k forks, many stars
qwen-code	A coding agent tailored for “Qwen-Coder” models; aims to provide code understanding, editing, and automation.	Primarily command-line / agent wrapper around Qwen-style models, with compatibility with OpenAI‑style APIs	Moderate; niche focus (Qwen models), less broad community than Google / OpenAI tools
opencode	Provider-agnostic AI coding agent built for the terminal, with modular architecture (client/server) and emphasis on TUI / terminal user experience.	Node.js / TypeScript + Go for backends, client/server model, supports multiple LLM providers.	Growing; ~1.8k forks, MIT license.
codex	OpenAI’s AI coding agent / CLI — part of its push to embed an “agent” into developer workflows.	Cloud-based agent model + local CLI / sandbox environment, integrated with ChatGPT, GitHub, IDEs.	Very high (OpenAI’s flagship), many users, high expectations

And here is a dimension comparision about the same tools.

Tool	Scope & ambition	Provider / model dependence	User interface / UX	Context & memory / session state	Sandboxing, safety / permissions	Extensibility / plugin / tools integration	Complexity / maintainability	Community / adoption risks
gemini-cli	Full-featured agent: code, search grounding, tool access, “reason & act” loop with local/remote tools.	Primarily built around Gemini / Google ecosystem (supports MCP extensibility).	CLI / terminal-first; tool commands, project context, session management.	“Reason & act” loops, checkpointing, context files (e.g. `GEMINI.md`).	Built-in tools (shell, file ops, web fetch); security sensitive due to local execution.	Supports MCP (Model Context Protocol) for custom integrations / tool servers.	High complexity due to rich agent features and tool integration.	Strong visibility from Google backing; risk of dependency on Google models, quotas, and policies.
qwen-code	Focused on code editing and understanding, especially for Qwen-Coder models; narrow domain.	Tightly coupled to Qwen (Qwen-Coder) models; compatible with OpenAI APIs.	CLI / prompt-based, command-driven sessions.	Maintains history and sessions; less emphasis on complex agent behavior.	Minimal scope; fewer dangerous operations and simpler sandboxing.	Limited extensibility; custom commands but less infrastructure for tool chaining.	Lower complexity due to narrower scope.	Dependency on Qwen models and smaller user base increases risk.
opencode	Balanced: broad agent features with modular, provider-agnostic design.	Strongly provider-agnostic: supports OpenAI, Google, local models, etc.	TUI / terminal-first with client/server architecture and flexible frontends.	Modular architecture enabling persistent, server-side context across sessions.	Sandboxing is critical due to provider independence and modularity.	Designed for extensibility via client-server architecture and custom tool backends.	Moderate complexity balancing flexibility and features.	Risk of fragmentation across providers and difficulty maintaining parity.
codex	Ambitious: embeds AI coding across terminal, IDEs, GitHub, and cloud workflows.	OpenAI-centric; leverages OpenAI infrastructure and models (CLI runs locally with sandboxing).	CLI plus deep integration with IDEs, GitHub, and ChatGPT web UI.	Strong context handling with isolated sandboxes and project metadata (e.g. `AGENTS.md`).	Strong sandboxing with approval models for file writes and shell commands.	Deep integrations (GitHub, IDEs, agent pipelines) with task-level tool orchestration.	Very high complexity from extensive integrations and safety mechanisms.	Risk of lock-in, cost, API constraints, and agent-task reliability.

Non-forking model

The following upstream projects fit in the category of non-forking model, i.e, we would be able to just contribute back to their community, pull the changes, adapt and stay in parity with upstream and downstream. Of course, not all projects listed here are super flexible, so we would need to do downstream patching to accomodate some of our needs, but it still fit the category of “let’s not fork and diverge from the upstream community” model.

With that in mind, here are the considered non-forking projects:

Comparative analysis

Here is a comparative analysis of goose, crush, and aichat. I break down their key differences, strengths, and weaknesses (from the perspective of architecture, features, maturity, extensibility, etc.).

Project	Description / goal	Primary language / tech stack	Maturity / popularity
goose	An “on-machine AI agent” that goes beyond code suggestions: installs, executes, tests, and debugs tasks; integrates with any LLM.	Rust + TypeScript (with some Go and Python components)	High: ~20k stars, ~1.8k forks
crush	A “glamorous AI coding agent for your favorite terminal” — CLI integrating LLM APIs, sessions, context, LSPs, and extensions.	Go (100%)	Strong: ~13.4k stars, active development
aichat	All-in-one LLM CLI: shell assistant, chat REPL, RAG, AI tools, and agents; multi-provider support.	Mixed stack (likely Python plus shell scripts)	Moderate: ~8.2k stars, fewer recent open issues

And here is a dimension comparision about the same tools.

Project	Scope / ambition	Extensibility / plugin / model support	User interface / UX	Context handling / sessions	Complexity vs simplicity	Community / stability
goose	Very ambitious: full agent capabilities (run code, orchestrate workflows, interact, test) beyond chat or suggestions.	Multi-model, modular architecture; supports any LLM and “recipes” (developer-contributed agents).	Desktop GUI plus CLI components; dedicated UI module.	Strong agent-oriented context and orchestration support.	Very high complexity with many moving parts due to agent orchestration.	Large community, many contributors, frequent releases.
crush	Developer / terminal-first focus: sessions, LSP integration, tool access, context switching.	Extensible via MCP servers (HTTP, stdio, SSE); model switching mid-session; LSP and plugin-like capabilities.	Pure terminal / CLI experience targeting developers.	Project-based sessions, context switching, LSP-enhanced context.	More focused design with fewer moving parts; easier to reason about.	Strong and mature user base with many commits.
aichat	Broad feature set: chat REPL, agents, RAG, and wide multi-provider support.	Supports many backends (OpenAI, Claude, Gemini, Ollama, Groq, etc.).	CLI / REPL-style interface, possibly with shell integration.	Conversation history, tools, and some session management (less mature).	Moderate complexity: many features, less deep orchestration than goose.	Growing community, but smaller contributor base compared to others.

Cool! But, why Goose then?

From all the reading above, you can see that a long list of LLM clients got considered to be our chosen one. We always try to go and pick the non-forking model, because that’s what give flexibility and stability for us, allowing customers and all users to play with such tools they way the like (running locally, changing providers, mcp, etc..).

We tried all of the clients in the above lists, and we had a deep consideration for each of them, wether or not it would be a good fit for such downstream repositories, user experience and maintainence as well.

Goose really made us be impressed with the power, simplicity and flexibility the tool has. It has a fast growing environment, with an amazing community behind it, and we had a lot of folks trying it out internally at that point too, so we felt pretty confident that Goose would meet our expectations, and, would meet users expectations as well.

Also, I just want to expand a bit more on the community side of Goose, the folks there just embraced my questions and were eager to help no matter what. From dumb questions (that I always ask, I know, sorry.), to more advance questions and etc. Folks there were happy to answer and guide us if necessary. That was one of the huge points that made us consider Goose as our favorite LLM client in our day to day work.

That collaboration was not only virtual, some folks from my team went to a F2F for Goose and met some of the engineers there, I heard that their experience was the same as mine virtually 😄. Always amazing to work with such upstream groups.

And to finalize, not sure if you all had the change to read this news, but, the Linux Foundation announced on December 9th, 2025 the formation of Agentic AI Foundation, and guess who is involved in that? That’s right, 🪿!

linuxfoundation.org

Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF), Anchored by New Project Contributions Including Model Context Protocol (MCP), goose and AGENTS.md

Linux Foundation Announces the Formation of the Agentic AI Foundation

Acknowledgments

I would like to give a shout out to my entire team at Red Hat and for all the folks that helped in this research. The list is long and I would be unfair if I tried to list all of them here, but you know who you are, so please, accept my deep gratitude for the hard work and patience at answering my questions 💖.

Also, a huge shout out to the Goose community for their amazing work and quickiness in replying to all questions and being eager to help who is new in there! 💖💖

Footnotes

Red Hat Enterprise Linux Extensions ↩︎

Packaging for Fedora: Python projects

Rodolfo Olivieri — Thu, 18 Dec 2025 12:49:00 +0000

In this post, I want to share with you what I know about packaging Pythonprojects for Fedora. I must start this text admitting that I don’t know a whole lot (yet), but I figured that it would be very valuable, not for myself, but also for others, if I shared my learning process and the roadblocks I have been facing recently. More like documenting what is happening and how I solved such problems.

How do I get started?

Packaging can be seem as a challenging task, no matter your level of experience, but, let’s try to understand how it works from the beginning.

Before jumping straight to writing specfiles, patches and all the fun stuff, let’s first understand a couple of resources that can make your life easier in this process. Fedora has a great online documentation available to everyone that can guide you in this process, going from what you need to know about packaging in general, and down to the more specific topics in each language, for instance, take a look at the below docs:

Fedora Packaging Guidelines

The Fedora Packaging Guidelines Has a complete set of information about packaging and what you should and should not do when packaging any software.

That piece of documentation goes in detail about all the pieces of packaging, from licensing to architecture support, build scripts and much, much more! It’s always good to read or bookmark that URL for further reference when needed.

Now, if you take a look at the below one:

Python Packaging Guidelines

The Python Packaging Guidelines, much like the Fedora Packaging Guidelineswill give you a complete tour on the specifics about packaging Pythonapplications, whici, is what we are intetrested in here.

In that one, you will learn about the structurue that is expected of your specfile, where to pull the source tarball, and many more information.

Keep in mind that, while it is always recommended that you read those documentation above, you can always bookmark and check them before submiting anything for review. Depending on your style of work, it may be more interesting to read such docs on the fly.

Knowing that such materials exists will be extremely helpful to us when we proceed to submit our newly built package for review inbugzilla, but don’t worry, we will cover this in another post, as there is quite a lot of information for us to go through. This post is more intended to be a hands-on, practical, python packaging and not really about package reviews or procedures.

Finding your upstream community/project

Finding a community that you like is one of the most crucial steps before you start hacking your packages. This step is important because if you find yourself trying to package something that is not even related to your day-to-day work or of your interest, you may find it boring when errors and workarounds appears. My advice to you, my fellow beginner packager, is:

Pick something that you use on your workflow and that does not exist in Fedora currently.

I’m not saying that packaging just for the fun of it is wrong, but, when you give a purpose to your work, then, it does not feel boring or a “hard requirement”. Our goal here is that you can learn how packaging is done, and also, have fun 😃!

Once you know what you want to introduce to Fedora, either because you need it, or you have a higher purpose (like contributing with a given community), then you are all set to go!

What is a specfile?

Working with specfiles can be challenging with many terms to identify and understand, but once you get the hang of it, the packaging part starts to be fun! I could go over here in details of each field, component and techniques for writing good specfiles, but, that would make this post be three times bigger than it already is. Instead, since this topic is huge and contain a lot of information, I will leave here the official documentation of the RPM Packaging Guide linked directly to the explanation of what is a specfiles, and instead of deep diving on it myself, let’s try to get to other topics that are not covered in the official docs.

RPM Packaging Guide

Pulling sources from pypi or GitHub/Gitlab/etc?

When working with packaging, we need to identify from where we want to pull the sources for our builds. The Python Packaging Guidelines states that you _MAY_pull the sources from PyPi for better convenience, however, that scenario may be complicated some times.

Let’s see below when to pull from PyPi or when to pull from another SCM.

When to pull from PyPI?

Usually, I like to start my packaging process by pulling the sources from PyPi and taking a good look at what is being present in the source tarball. You are not required to do this, but I prefer starting my workflow like that.

For instance, let’s take a look at this section of one of my specfile:

python-sse-starlette.spec (L1-L8)

Name: python-sse-starlette
Version: 3.0.3
Release: %autorelease
Summary: SSE plugin for Starlette

License: BSD-3-Clause
URL: https://github.com/sysid/sse-starlette
Source0: %{pypi_source sse_starlette}

You see that I’m using this macro called %pypi_source, right? This is aConvenience Macrothat we can use to generate the full PyPi URL. With that, you only need to pass the package name in PyPi and optionally, the version, as it pick the version from the Version field.

The good part is that it is convenient to pull the sources from PyPi directly with this macro, but, sometimes the upstream maintainer may not include required files/folders that we need to use in downstream packaging. For instance, the upstream project may be using a new shiny tooling/builder that generate metadata differently what is currently expected (like poetry, uv, setuptools, etc…). This can cause problem during the package build as you may be missing the license information, tests folders (which is good to execute during the specfile builds) and more.

When that happens, we may need to switch to pull sources from other SCM variants, like GitHub. From there, it’s more likely to get a full overview of the project setup, and then you can manually pick what you want from the tarball.

When to pull from GitHub/Gitlab/etc?

As stated before, sometimes the PyPi sources may not contain all the required metadata, tests, or essential files for your package building, when such cases happen, we need to switch our plan and start pulling from the upstream SCM, for instance, take a look at this other package:

python-openapi-pydantic.spec (L1-L8)

Name: python-openapi-pydantic
Version: 0.5.1
Release: %autorelease
Summary: Pydantic OpenAPI schema implementation

License: MIT
URL: https://github.com/mike-oakley/openapi-pydantic
Source: %{url}/archive/v%{version}/openapi-pydantic-%{version}.tar.gz

This project was exceptional one, as the PyPI sources didn’t contain the tests folder for me to check under the %check directive. For that, I had to change my approach to pull from GitHub (were the project is hosted), as in that one, I would have the same copy of the project, but with the tests folder that I needed.

You can go with the upstream SCM directly if you wish, that’s not a big deal at all. This is more a question of preference and from where you want to pull your trusted tarball.

Patching in downstream

Patching is one of the most needed useful techniques that we can bring to the packaging world! This help us modify the behavor of the project before the builds. Why this is necessary, you may think? Well, let’s think that your project depends on libXX == 1.0.0, but Fedora only has libXX == 0.9.0packaged in the repositories, what should you do now?

Well, it’s always possible to ask for the maintainer of the libXX package to update to the newest version, but, that may not be possible all the time. Instead, it’s when patching comes to the rescue!

You could use different strategies and methods you like, for instance, sed is a pretty good viable option for patching if you’re familiar with it.

Patching toml files

I like to use a tool called tomcli, which is a bit confusing on the first try, I must admit, but it makes the patching much easier once you get the hang of it.

Take a look at this example where I wanted to relax one of the dependencies for python-sse-starlette:

python-sse-starlette.spec (L37-L38)

# Relax daphne dependency
tomcli set pyproject.toml arrays replace project.optional-dependencies.daphne "daphne>=([0-9]+\.[0-9]+\.[0-9]+)" "daphne>=4.1,<4.3"

Another useful way of patching toml files with tomcli is like this:

# Patch pyproject.toml to use setuptools instead of uv_build (not available in Fedora)
tomcli set pyproject.toml lists str "build-system.requires" "setuptools>=61" "wheel"
tomcli set pyproject.toml str "build-system.build-backend" "setuptools.build_meta"

Disclaimer: Using cookiecutter-fp template

Alternatively, you can get started using my cookiecutter packaging template. This template is written in a way to help bootstrap some of your manual work with copr/builds/logs by providing a set of crafted make targets for convenience. You can read more about it in my blog post below:

Packaging for Fedora: General purpose cookiecutter template

Want to learn more? Joing the Matrix channel!

Did you find this interesting? Please, feel free to join the Fedora Matrix channel to learn more and get started. The community is amazing and I’m pretty sure that you will find what you need there.

If you want to get in touch with me, just send a message to @r0x0d:fedora.im.

References

RPM Packaging Guide

Packaging for Fedora: General purpose cookiecutter template

Rodolfo Olivieri — Fri, 12 Dec 2025 17:38:00 +0000

To make the effort on packaging easier, I developed a custom cookiecutter template to help bootstraping this work.

The template currently comes with pre-defined settings for packaging Rust andPython applications, which is my main target as of now. The details on how to package such proejcts will be detailed in another blog post, not here. In here, we will try to focus on how this cookiecutter template works and how you can use it in your workflow (if you like it.)

Getting started

In order to use this template, you will need to have cookiecutter andjinja2_time installed (preferably in a virtualenv), so let’s begin with:

pip install cookiecutter jinja2_time

The jinja2_time is used here as a convenience to update the current year in the LICENSE file once it is generated.

Once both are installed, we can proceed with calling cookiecutter to generate our new project:

# This will pull the template with ssh
cookiecutter git@github.com:r0x0d/cookiecutter-fp

You will be prompted to answer a few bootstraping questions for the template. Don’t worry, this won’t execute any hidden hooks on your system. This is mainly to track the correct names of the upstream project, GitHub/Gitlab/Codeberg URLs and etc. You should have something looking like this:

  [1/6] project_slug (rust-my-awesome): my-super-project
  [2/6] pkg_name (my-awesome): super-project
  [3/6] upstream_repo (https://github.com/my/awesome-repo): https://github.com/my-username/super-project
  [4/6] Select tool_2_rpm
    1 - rust2rpm
    2 - pyp2spec
    Choose from [1/2] (1): 2
  [5/6] year (2025):
  [6/6] copr_username (<your username>): my-username

Let me break down what each prompt above means for you:

Prompt	Description
project_slug	Used to match the downstream package name (e.g; `python-flask`, `rust-serde`, etc…)
pkg_name	The name of the package you are trying to get to fedora (e.g; `flask`, `serde`, etc…)
upstream_repo	URL to the upstream repository for the package (e.g; `Github`, `Gitlab`, etc…)
tool_2_rpm	Choose from `rust2rpm` or `pyp2spec` (more details on that below)
year	The year used in the `LICENSE` file for your mid-stream repository
copr_usernam	The COPR username to manage the builds

Once all of the prompts are answered, you will se a new folder in the directory you are that matches the project_slug name you entered before.

It is not required to set the project_slug to be the same downstream package name, but, this help in organization and knowing that you will have the same data when you go to the package review process, avoiding confusion and unnecessary drawback.

What to do with a new project?

Once you have created a new project with the above cookiecutter command, you are now ready to start modifying, building and eventually, submit it to package review. This part is one of the most important in the process of packaging, as it is here where you will do your experimentation and get the builds right, so don’t be afraid of messing stuff up 😊.

This template comes with a set of make targets that will help you quickly experiment with the builds and iterate over the changes. We will talk about them in each of the sub-sections bellow.

Creating a new copr repository

First things first, we need to create a new copr repository for you to track your builds. In Fedora, you can use mockbuilds that will execute locally, but they will, at some point, get your directories dirty. I’m not sure about you, but I don’t like having dangling files all around my computer that I won’t remember why they are there 6 months or 1 year later.

Setting up a copr account

You will need to create a new Fedora account (FAS) first before working with copr, this will be necessary for further steps as well when we reach the package review process.

Once you have your new FAS account, go back tocopr and click on the OIDC loginto use your FAS credentials.

With those steps done, go ahed to copr api page to grab your credentials. This is very important as we can’t create a repository for you in the next steps if you don’t get your API keys set up.

Don’t worry, that page tells you exactly where to place the contents you grabbed from the site.

Installing necessary rpms

There is a set of RPMs that are necessary for you to install on your system in order to proceed, we can start with the following:

fedpkg
copr

sudo dnf instal fedpkg copr

Alternatively, if you don’t like installing things directly to your system, or if you are like me who is using Fedora Silverblue, then I got you covered… I have created a toolbox environment for Fedora packaging that comes with most of what you will need configured.

To use my fedora-packaging contianer, you could do it with toolbox/distrobox:

toolbox create --image quay.io/toolbox-dev/environment/fedora-packaging fedora-packaging

Once everything is ready and set up, we can now proceed to create the repository with the make target:

make create-copr-repository

Generating the specfile

In order to generate the specfiles for the given project you want to package, it is highly recommended that either rust2rpm or pyp2spec is used, depending on the type of project you are trying to package.

rust2rpm (required if you’re packaging rust applications)
pyp2spec (required if you’re packaging python applications)

sudo dnf install rust2rpm pyp2spec

Once the tool is installed, it is time to run the below make target to generate the specfile automatically:

make spec

Some manual changes will be necessary in case you are packaging pythonapplications due to the limitations of the pyp2spec tooling. For rust RPMs, it should be straightforward.

Depending on the project you will package, some patching will be required in order to have a successful build. The specifics on how to patch will be covered on a different post.

Building the project

Now that we already have the specfile in place, it is time to trigger our first build! First, we will need to download the sources from the specfile, given that we don’t have a dist-git set up yet, we will reloy on srpm generation, which requires that you have the tarball sources present in the same directory as of your specfile. Luckily, the template also comes with two useful targets that can be used to bootstrap and automate this process.

# Get the sources from the specfile
make sources

# Submit a new build to copr
make build

Once the build is triggered, and if everything is working correctly, you will see that your srpm will be uploaded to copr and a build will start to happen!

Watching the logs with fuzzytail

The cookiecutter template comes by default with a target for watching the logs of your copr build:

make logs

To know more about fuzzytail, check out my other blog post Packaging for Fedora: fuzzytail! Watching logs on your terminal.

Tracking the repository in github (optional)

Lastly, as an optional task, you can create a github repository to track your work (either because you want to version it, or you are working on mulptiple machines). This step is not required at all, so it may be safely ignored if you have enough experience on this process.

There is a set of RPMs that are necessary for you to install on your system in order to proceed, we can start with the following:

gh-cli

make crate-gh-repository

Contributing

If you would like to contribute to the cookiecutter template, please, feel free to do so in the Github repository

Packaging for Fedora: fuzzytail! Watching logs on your terminal

Rodolfo Olivieri — Wed, 10 Dec 2025 20:22:00 +0000

If you are an experienced fedora packager or even if you are starting out, you probably have come across COPR and its tooling, right? Well, if you have, then you know how painful it is, for each build, to come back to the UI and keep refreshing manually to watch your logs in “real time”.

This is where fuzzytail comes to the party!

What is fuzzytail?

fuzytail is an small application that let you interact with your builds inCOPR, either by looking at the status of the build or by watching the logs live.

By no means fuzzytail replaces thecopr-cli, it is actually meant to be an extension to aid packagers to visualize their build logs in the terminal instead of using the UI.

By the time you see yourself packaging 5+ upstream projects to Fedora, you probably will end up going crazy trying to watch the builds and figuring out what exactly happened to your failed ones, this is where fuzzytail enters to shiny!

As a developer, it is much, much, much more comfortable for me to look at stuff in my own terminal instead of my web browser, it makers me feel like a_hacker_, you know? And fuzzytail is helping me keeping this feeling while I prepare builds for various packages.

Fantastic! How do I get fuzzytail?

fuzzytail is available from pypi, therefore, a simple:

pip install fuzzytail

# or

pipx install fuzzytail

Will get you to the latest version.

How do I use fuzzytail?

To get started with fuzzytail is actually pretty simple. All you have to do is run the following command on your terminal after you get it installed:

fuzzytail <owner>/<project>

By default, fuzzytail will start in the watch mode, meaning that, once you specify the owner and project that you are interested in, it will stream the logs directly to your terminal, that’s the most basic execution mode for the program.

Don’t believe me? Here, take a look!

A gif showing fuzzytail streaming the logs in a split terminal while the build happens

In case you don’t want to stream the logs directly, it is also possible to view the logs after they happen with:

fuzzytail logs <owner>/<project>

Filtering for chroot logs

fuzzytail has the ability to allow you to select which chroot logs you want to see during the build. Maybe you only care about fedora-43-x86_64, and not about rawhide or fedora 42 and etc. With fuzzytail , this is easily selected with the --chroot parameter:

fuzzytail <owner>/<project> --chroot fedora-43-x86_64

Filtering for build logs only

In some cases, you might not want to see all copr build logs, like srpm,import, backend, etc. Maybe you just care about the actual rpm log, because that’s what is important for you right now, and thinking in that, fuzzytail also has a mode to allow you to specify which logs you want to capture and display in your terminal:

# Will only show the rpm build logs
fuzzytail <owner>/<project> --rpm-only

# Will only show the srpm build logs
fuzzytail <owner>/<project> --srpm-only

Checking build status

fuzzytail also has a nice command for you to check the status of the builds (without getting their logs). This command is useful for quickly finding out if your long-running build has failed or succeeded!

fuzzytail builds r0x0d/python-openapi-pydantic

That will generate the following output:

┏━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ ID ┃ Package ┃ State ┃ Chroots ┃
┡━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 9896298 │ python-openapi-pydantic │ ❌ failed │ fedora-43-x86_64, fedora-rawhide-x86_64 │
│ 9896292 │ python-openapi-pydantic │ ❌ failed │ fedora-43-x86_64, fedora-rawhide-x86_64 │
│ 9896235 │ python-openapi-pydantic │ ❌ failed │ fedora-43-x86_64, fedora-rawhide-x86_64 │
│ 9896230 │ python-openapi-pydantic │ ❌ failed │ fedora-rawhide-x86_64, fedora-43-x86_64 │
│ 9878007 │ python-openapi-pydantic │ ❌ failed │ fedora-rawhide-x86_64, fedora-43-x86_64 │
│ 9877978 │ python-openapi-pydantic │ ❌ failed │ fedora-43-x86_64, fedora-rawhide-x86_64 │
│ 9877438 │ python-openapi-pydantic │ ❌ failed │ fedora-43-x86_64, fedora-rawhide-x86_64 │
│ 9877277 │ python-openapi-pydantic │ ✅ succeeded │ fedora-43-x86_64, fedora-rawhide-x86_64 │
│ 9869333 │ python-openapi-pydantic │ ✅ succeeded │ fedora-rawhide-x86_64, fedora-43-x86_64 │
│ 9869332 │ python-openapi-pydantic │ ❌ failed │ fedora-43-x86_64, fedora-rawhide-x86_64 │
└─────────┴─────────────────────────┴──────────────┴─────────────────────────────────────────┘

Contributing to fuzzytail

All types of contributions are very welcome to the project! If you are interested in contributing, whether with code, documentation, or even reporting problems, please feel free to do so through the repository on Github.

Packaging for Fedora: woolly! Checking the dependency hell

Rodolfo Olivieri — Wed, 10 Dec 2025 12:56:00 +0000

If you’ve ever been interested in bringing software to Fedora that you use and thought would be interesting for the community, but were unsure about what you’d need to package to make it work, fear not as woolly is here to help with this arduous process!

What is woolly?

In general, woolly is a project I started due to a demand from my work at Red Hat. My team had a requirement to deliver two large projects on Fedora:

Some people on the team already had experience in packaging, but others did not.

Both projects mentioned above bring with them several dependencies (which are often not present in the Fedora repositories), therefore, it becomes a challenge for experienced and amateur packagers to discover the complete list of dependencies that will be necessary to bring from the upstream projects to downstream.

So, from this need, woolly was born.

If you’ve ever had to package something for Fedora (or any other Linux distribution), you know how painful that task can be. An endless sea of dependencies, projects that don’t configure their dependencies as optional, etc. All of this contributes to the difficulty of identifying and putting together an action plan to start this journey, especially for projects that are still active, since the list of dependencies can change considerably depending on the maintainers.

In short, woolly can discover the dependencies needed for your project, and tell you exactly what already exists in the Fedora repositories (which versions are present, too!), what’s missing, and generate reports that can facilitate your (or your team’s) understanding.

It looks perfect! How do I get the woolly?

woolly is available from pypi, therefore, a simple:

pip install woolly

# or

pipx install woolly

Will get you to the latest version.

How do I use woolly?

Using woolly is very easy! The user interface was designed to be intuitive and simple, so we don’t want distractions, but rather useful information! Take a look at the following example:

woolly check serde

The above command will produce the following output:

Analyzing Rust package: serde
Registry: crates.io
Cache directory: /home/r0x0d/.cache/woolly

  Analyzing Rust dependencies ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% • 0:00:05 complete!

Dependency Summary for 'serde' (Rust)
╭────────────────────────────┬───────╮
│ Metric │ Value │
├────────────────────────────┼───────┤
│ Total dependencies checked │ 10 │
│ Packaged in Fedora │ 7 │
│ Missing from Fedora │ 0 │
╰────────────────────────────┴───────╯

Dependency Tree:
serde v1.0.228 • ✓ packaged (1.0.225, 1.0.228)
└── serde_core v1.0.228 • ✓ packaged (1.0.225, 1.0.228)
    └── serde_derive v1.0.228 • ✓ packaged (1.0.225, 1.0.228)
        ├── proc-macro2 v1.0.103 • ✓ packaged (1.0.101, 1.0.103)
        │ └── unicode-ident v1.0.22 • ✓ packaged (1.0.19, 1.0.22)
        ├── quote v1.0.42 • ✓ packaged (0.3.15, 1.0.40, 1.0.41)
        │ └── proc-macro2 v1.0.103 • ✓ (already visited)
        └── syn v2.0.111 • ✓ packaged (1.0.109, 2.0.106, 2.0.111)
            ├── proc-macro2 v1.0.103 • ✓ (already visited)
            └── unicode-ident v1.0.22 • ✓ (already visited)

Log saved to: /home/r0x0d/.local/state/woolly/logs/woolly_20251210_091241.log

See how simple it is to use woolly to check the dependencies of a given upstream project? Rust is used by default in woolly since the project was born from the need to check the dependencies of projects in Rust, but it also has support for Python.

woolly check -l py flask

And the output is:

Analyzing Python package: flask
Registry: PyPI
Cache directory: /home/r0x0d/.cache/woolly

  Analyzing Python dependencies ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% • 0:00:07 complete!

    Dependency Summary for 'flask'
               (Python)
╭────────────────────────────┬───────╮
│ Metric │ Value │
├────────────────────────────┼───────┤
│ Total dependencies checked │ 13 │
│ Packaged in Fedora │ 11 │
│ Missing from Fedora │ 0 │
╰────────────────────────────┴───────╯

Dependency Tree:
flask v3.1.2 • ✓ packaged (3.1.2)
├── blinker v1.9.0 • ✓ packaged (1.9)
├── click v8.3.1 • ✓ packaged (8.1.7)
│ └── colorama v0.4.6 • ✓ packaged (0.4.6)
├── importlib-metadata v8.7.0 • ✓ packaged (8.7)
│ ├── zipp v3.23.0 • ✓ packaged (3.23)
│ └── typing-extensions v4.15.0 • ✓ packaged (4.15)
├── itsdangerous v2.2.0 • ✓ packaged (2.2)
├── jinja2 v3.1.6 • ✓ packaged (3.1.6)
│ └── markupsafe v3.0.3 • ✓ packaged (3.0.2)
├── markupsafe v3.0.3 • ✓ (already visited)
└── werkzeug v3.1.4 • ✓ packaged (3.1.3)
    └── markupsafe v3.0.3 • ✓ (already visited)

Log saved to: /home/r0x0d/.local/state/woolly/logs/woolly_20251210_091548.log

Showing only optional dependencies

Woolly also has support for displaying the optional dependencies of projects, as this can be useful to check to find out which extras you can enable for your project.

woolly check -l py flask --optional

Obviously, the command above takes much longer to execute, since the project may have several optional dependencies to be consulted:

Analyzing Python package: flask
Including optional dependencies
Registry: PyPI
Cache directory: /home/r0x0d/.cache/woolly

  Analyzing Python dependencies ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% • 0:00:01 complete!

    Dependency Summary for 'flask'
               (Python)
╭────────────────────────────┬───────╮
│ Metric │ Value │
├────────────────────────────┼───────┤
│ Total dependencies checked │ 41 │
│ Packaged in Fedora │ 10 │
│ Missing from Fedora │ 0 │
│ │ │
│ Optional dependencies │ 27 │
│ ├─ Packaged │ 2 │
│ └─ Missing │ 0 │
╰────────────────────────────┴───────╯

Dependency Tree:
flask v3.1.2 • ✓ packaged (3.1.2)
├── blinker v1.9.0 • ✓ packaged (1.9)
├── click v8.3.1 • ✓ packaged (8.1.7)
│ └── colorama (max depth reached)
├── importlib-metadata v8.7.0 • ✓ packaged (8.7)
│ ├── zipp (max depth reached)
│ ├── typing-extensions (max depth reached)
│ ├── pytest (optional) (max depth reached)
│ ├── importlib-resources (optional) (max depth reached)
│ ├── packaging (optional) (max depth reached)
│ ├── pyfakefs (optional) (max depth reached)
│ ├── flufl-flake8 (optional) (max depth reached)
│ ├── pytest-perf (optional) (max depth reached)
│ ├── jaraco-test (optional) (max depth reached)
│ ├── sphinx (optional) (max depth reached)
│ ├── jaraco-packaging (optional) (max depth reached)
│ ├── rst-linker (optional) (max depth reached)
│ ├── furo (optional) (max depth reached)
│ ├── sphinx-lint (optional) (max depth reached)
│ ├── jaraco-tidelift (optional) (max depth reached)
│ ├── ipython (optional) (max depth reached)
│ ├── pytest-checkdocs (optional) (max depth reached)
│ ├── pytest-ruff (optional) (max depth reached)
│ ├── pytest-cov (optional) (max depth reached)
│ ├── pytest-enabler (optional) (max depth reached)
│ └── pytest-mypy (optional) (max depth reached)
├── itsdangerous v2.2.0 • ✓ packaged (2.2)
├── jinja2 v3.1.6 • ✓ packaged (3.1.6)
│ ├── markupsafe (max depth reached)
│ └── babel (optional) (max depth reached)
├── markupsafe v3.0.3 • ✓ packaged (3.0.2)
├── werkzeug v3.1.4 • ✓ packaged (3.1.3)
│ ├── markupsafe (max depth reached)
│ └── watchdog (optional) (max depth reached)
├── asgiref v3.11.0 (optional) • ✓ packaged (3.8.1)
│ ├── typing-extensions (max depth reached)
│ ├── pytest (optional) (max depth reached)
│ ├── pytest-asyncio (optional) (max depth reached)
│ └── mypy (optional) (max depth reached)
└── python-dotenv v1.2.1 (optional) • ✓ packaged (1.1)
    └── click (optional) (max depth reached)

Whenever you check the optional dependencies of a project, remember to use the --max-depth parameter to limit the analysis, otherwise, woolly will happily check all the optional dependencies of everything 😅

Showing missing only dependencies

Following the same idea as optional dependencies, woolly also has the ability to show only what is missing from the Fedora repositories:

woolly check -l py cyclopts -m

Analyzing Python package: cyclopts
Registry: PyPI
Cache directory: /home/r0x0d/.cache/woolly

  Analyzing Python dependencies ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% • 0:00:00 complete!

  Dependency Summary for 'cyclopts'
               (Python)
╭────────────────────────────┬───────╮
│ Metric │ Value │
├────────────────────────────┼───────┤
│ Total dependencies checked │ 12 │
│ Packaged in Fedora │ 9 │
│ Missing from Fedora │ 2 │
╰────────────────────────────┴───────╯

Missing packages that need packaging:
  • cyclopts
  • rich-rst

Log saved to: /home/r0x0d/.local/state/woolly/logs/woolly_20251210_093409.log

This option is useful for large projects, since the list of dependencies can reach 100+, so, using the --missing-only parameter, we have a view of only what is missing.

Generating reports

One of the coolest features we have with woolly is the ability to generate reports in different formats, allowing you to customize how you see the results of your project’s dependencies!

Format	Description	Aliases
stdout	Rich console output (default)	console, terminal
markdown	Markdown report file	md
json	JSON report file (machine-readable)	-
template	Custom template-based report (requires –template)	tpl, jinja, jinja2

Contributing to woolly

Programming languages are not just a tool

Rodolfo Olivieri — Tue, 11 Nov 2025 20:39:45 +0000

While I was browsing LinkedIn this week (I know!), I came across a post that discussed the idea that people consider programming languages to be just a tool, which, in my view, is a completely wrong conception.

Unfortunately, I don't have the link to the post to reference here, but I think the idea of the debate is still valid for discussion. I vaguely remember that the post mentioned some different programming languages to try to justify its point, which I believe is the most reasonable argument for the debate, since if we analyze language by language, we can notice that, even though many have a common ancestor (the C language), their ideation and conception are totally different.

Let's take the example of Rust[^1](https://rust-lang.org/) and Python[^2](https://www.python.org/), both are popular languages used in various open (and closed) source projects, however, the nature of both languages differs greatly, even though they can be used for the same purpose, in which Rust has a focus on performance, memory safety and stands out in embedded systems, while Python has an extreme appeal for prototyping, data science and is included in practically every current operating system.

Not that the possibility of reproducing the same idea in different languages is impossible, but thinking that languages are merely tools that can be swapped between projects, and that they will continue to work the same way, is not a constant or absolute truth. Can you create an operating system[^3](https://os.phil-opp.com/) in Rust? The answer is yes! Can you do the same with Python? Technically possible[^4](https://github.com/crcollins/pyOS), but extremely impractical due to the interpreted nature and overhead of the language.

In some projects, you will need the performance of language X, or the ease of use of language Y, or even the availability of language Z, making your project's architecture change considerably depending on your choice, even the way you think about your programming is modified depending on the use of a particular language.

Thinking this way, we have to take into consideration the aspect of language paradigms; when we work with functional languages, we have a more immutable way of thinking, which differs completely from object orientation, since in it, we think more about structures, code coupling, etc.

Another very important point is the seniority of your team (considering a commercial project) with the language in question. If you have a team that is very efficient and experienced with Python, why risk building a system in Go, for example? You will end up reducing your team's performance and autonomy, sacrificing important (human) resources simply for the sake of the idea that "languages are just tools".

toolbox, IDEs and atomic desktops

Rodolfo Olivieri — Fri, 22 Aug 2025 15:36:05 +0000

My experience so far with Fedora Atomic desktops (or ostree based desktops) has been positive, of some sorte. First things first, there are a couple of features that I like about such desktops, for example:

It's easy to switch between desktop environments¹
All updates are signed with GPG Keys, so you know that you're pulling from trusted sources
You can enable a systemd service to automatically update your system (In this case, every day)

And a bunch more that I won't go into too much details. Whoever, you should know that there are a couple of "bad ux" in such environments, more related to development than anything else.

In short, I think ostree environments are really well suited for daily uses and or cloud deployments (their original intention), regular users would probably not run into such cases if they are mainly using the their computer for browsing, gaming or basic text editting.

Running text editors (i.e; IDEs)

One of the main deals with atomic desktops is the ability to run your favorite text editor. If you are a developer, then you are probably more likely to bump into such issues more frequently.

For regular text editing, like reading a file or writing to a textual file, that should not be a problem.

Let's say that you're running vanilla Fedora and you usually install your VSCode through the official Microsoft repository and follow all the instructions, and in a couple of minutes, you have your development environment partially ready. At least, in regards of text editing. Pretty simple, right?

When you make a switch to an ostree environment, you now face three options to install the same tool.

You add VSCode using rpm-ostree and now you have a new package layer on top of your runnign system
You decide to try the flatpak version of the same application
You decide to go with toolbox/distrobox and install all the necessary tools inside it

While all of the three options are equally good, they have different approaches to installing your development packages (python, go, rust, libs, etc..) and interacting with your codebase.

The first approach

For instance, if you choose the 1. option, well, now you have a thirdy-party package layered on top of your system and that will integrate very well with most of the things, but, you still need to install the packages and libs somehow, right? Well, you could either continue layering your system with all the dependencies (but that's not quite why ostree is good at), or, find yourself having a toolbox/distrobox container running that you install all of those in there.

For this instance, I would say that you are still in the best shape out of the three options, you are more likely to set up DevContainers and probably won't notice much difference when using your tools. The downside, at least in my opinion, is that now you have a development package layered on top of your OS that should not really be there. While this is fine, it is not an approach that I like. One of the advantages of ostree environments is that you have a reproducible environment no matter where you go, and layered such packages can break this experience with bad updates and all sort of other stuff.

The second approach

Alright, but what about the 2. approach then? The VSCode package, specifically, does not really offer any support in their flatpak version, actually, it is something maintained by a community of people, and not really by Microsoft. While the folks that maintain such flatpak are amazing, you can't (and should not) really expected frequent updates or more in-depth problem solving.

For instance, flatpaks are really small containers that package all you need inside it and let you execute the application in this "sandbox" env, and as you can imagine, this makes things a bit complicated when you have a flatpak (that is good mention, is read-only), being isolated and not being able to properly access the development packages.

The third approach

While this approach is one of the most recommended out there (and I use that too), you might face problems such as, opening external programs if they are not properly set up inide the container, or and some other minimal problems.

For instance, if you use VSCode and want to authenticated with GitHub to pull your settings, you might need to do a couple of workarounds to get a firefox or any other browser inside the container to launch it and authenticate. Personally, I don't like this approach, and it seems that there isn't a very good solution so far.

Personally, I have made the switch to neovim as I can install it inside my toolbox container, mainly because I wanted to use neovim for a long time now, but haven't had any good opportunity, as using VSCode or any other text editor felt way more convenient.

The power of toolbox (or even distrobox)

Toolbox is an amazing tool that you can spawn a container (either the default) or a custom image that you made.It allow for so many customization and possibility, and it is all sandboxed!

Well, kinda of sandboxed. The toolbox container is created/ran with parameters that attach your $HOME folder and other devices to the container

In short, you can enable a very powerful development environment and experience through toolbox usage and keep all the various packages individually contained within each set of containers that I maintain.

References

Trying different desktop environments using “rpm-ostree rebase” ↩

My experience with Fedora Atomic

Rodolfo Olivieri — Thu, 03 Jul 2025 15:34:55 +0000

Backstory

I've beeng using Linux for the past couple of years now as my mainly driver. Started using Debian, Ubuntu, Gentoo, and now, I have estabilished Fedora as my main OS.

My experience was always using the classic RPM-based Fedora daily for the past 5-6 years now. And, you know, it's been good and I never had any problems with it for the most part. Out of all the systems I have tried before, Fedora was the only one I really felt that I liked using. From package manager, to community, decisions and everything else.

A year or two ago, a colleague from work introduced me the concept of Atomic desktops. It felt weird at first, but I liked the idea of having my "core" system separated from my applications.

When I tried to use Fedora Silverblue for the first time, it was a shock. I didn't know how to install the development packages I needed, the system had problems upgrading from one version to another, and man, everything felt so broken and clumsy that I gave up. The concept still looked very cool to me, but it was too much for me to learn back then.

Up recently, I decided to give it another go, since a few years have passed, I thought that my experience would be different now.

What version have I chosen now?

For my current experience, I went with Fedora Kinoite due to be more familiar with the interface and feeling that it was more responsive than GNOME.

GNOME UI still looks better in my opinion, but the performance of KDE looks way better.

How good (or bad) is to use such desktop daily?

To be honest, it still feels a bit weird having to use rpm-ostree than dnfwhen I need to install a package, but overral, I really like the separation of "layers" that we have due to the entire OS being run in a container.

Knowing that most of the applications that I need to use (VSCode, Slack, Firefox, etc...) are available through Flatpaks is also great. Not all of them are official, but the support is good enough.

So far, I haven't figured out any blockers that a flatpak or a layer rebase couldn't do it for my system.

Will I keep using it?

It's very possible that I will adopt Fedora Kinoite as my main OS from now on. I like the separation of concerns here, the gpg verified updates, automatic updates, and the ability to "force" me to be more creative to solve daily problems.

Those problems are not complex, though. For instance, I've been dealing a lot with toolbox to create development boxes or default boxes with the most used tools I use daily.

It's hard for me to say "Yeah, I will go back to rpm based because it is way better" for now, so, I will give this experience a couple more months.

Closing thoughts

If you are looking for a change in your personal machines and want to try something new and exciting, I really recommend trying out any distribution of Fedora Atomic available. You don't have to go with Fedora Kinoite like I did, maybe GNOME or Sway is your thing.

Maybe start with a VM so you don't lose your sanity on the first couple of days :)

Writting a GH extension with AI

Rodolfo Olivieri — Wed, 01 Jan 2025 15:34:09 +0000

I was looking out for some github repositories in my home page recently, with the hopes to find some interesting project or just to browse out the updates from the people that I follow. While I was looking out for those updates, I bumped into DeekSeek-Coder.

At first, I thought to myself that it was just another AI experimental project, but to my fortune, I discovered gold here.

My history with AI

I was always the type of person who didn't care too much about AI as I felt that it was not worth it to use it to do the job that I was supposed to do. That changed drastically when I started using zed and it's awesome AI integration.

Zed makes interacting with AI pretty simple and straightforward. You just need to configure either a local LLM provider, an API Key to a service (like OpenAI), or you could just use the out-of-the-box Zed solution with Claude.

The later was my choice for diving into the AI world. I felt that Claude had good code generation and was driving giving me good answers here and there.

When I bumped into the free tier limit with this integration, I started using other providers like ChatGPT or even GitHub Copilot.

ChatGPT, of course, had the best results when you ask the question using that limited amout of tokens for the good model they provide, and GitHub Copilot on the free tier was... Strange...

With the bad experience with GitHub Copilot I had and not wanting to pay for a subscription in ChatGPT, DeepSeek-Coder felt like a good option for myself.

Writting some code with it

So, to test this out, I asked DeepSeek-Coder to write some code for me. It couldn't be just some random code, but something that I really wanted. I askedDeepSeek-Coder to write me a bash script to interact with gh api command and retrieve the stargazer from a user.

Why this matters, you may think? Well, I've grown to use stargazers in github a lot recently, and every time that I wanted to clone a particular repository or a set of repositories from a tag or a topic, it was a pain to do that all by hand. So I asked DeepSeek-Coder to help me out with that and write some simple bash script that could do the following:

Fetch the user starred repositories
Filter the repositories by a "tag"
Show it using TUI (mainly fzf) the repositories for the user to select which repo they want to download
If the repo already exists, skip it.

A pretty simple challenge, and something that an AI can do.

All of the questions I asked in that chat window, DeepSeek-Coder did it amazingly well. The code itself was not that difficult and did not contain trick regex expressions and stuff like that, but it managed to handle all my use case above pretty nicely.

I need to test it a bit more and try to generate some more complex use cases, but DeepSeek-Coder was on point with what I wanted and was able to generate for me a single bash script that could do all the above. Something that GitHub Copilot failed to do.

Conclusion

If you want to take a look at what I did using DeepSeek-Coder, please feel free to check out the gh extension repository I created:r0x0d/gh-stargazer-clone.

SystemBus vs SessionBus

Rodolfo Olivieri — Fri, 27 Dec 2024 15:30:11 +0000

Have you ever tried to develop an entire application that relies on d-bus (without knowing too much of d-bus) and when you had to run that application in a headless server, all of the sudden everything stops to work?

Well... That's basically what I did.

Today, we gonna talk about the differences between system bus and session bus, and why it is important for you to develop your application with the correct term in mind.

Session Bus

Session bus is a special term for d-bus that identifies a message bus (communication) between processes, and is tied to user connnection. You can use a session bus if your application has the necessity to run for this single user and is tied to that environment, the session. But keep in mind that it will require that your application runs on a server that has graphical display capabilities

Examples of that:

KDE
GNOME
etc...

System Bus

System bus, on the other hand, is used for system-wide process communication, they do not require a graphical session (like the Session Bus), and can be executed in headless servers without any problems.

System bus is indicated for you to use whenever you have to develop an application that needs to communicate with another service in that server/computer, and does not necessarily depends on anything graphical.

Why the difference between the two matters?

The difference between the two is important to know mainly when developing a new application. If you want to develop something that will run in a server/cloud/ephemeral environment, you need to keep this in mind as those type of machines won't have a graphical display available for you. You need to know which type of message bus to connect before you can publish your code to production.

In the end, you won't have a lot of headache if you choose to develop your service in with the "wrong" kind of message bus, but, that could mean that you will have to patch, delay, and possibily adapt your workflow to make it work with the correct bus.

How do I choose the correct bus?

Essentially, you should follow a very simple rule. If you are developing a new daemon that needs to notify the user about something (that is running in the backend), your daemon needs graphical access or to communicate with KDE, GNOME and etc.. That is the perfect use case for a session bus.

If you are developing a service that will talk with a external backend service (let's say an API), do some calculations, won't need to update any UI elements or, and will need to communicate with more system services, then you can go with a system bus.

It's that simple.

A specific note about the system bus option

System bus has a particularity that it needs to be told here. If you are running your service with a regular session bus, you won't need any extra tweaks or tricks, as you are already authenticated and using the user session, the bus will be automatically set that your user will be able to intecract with it.

However, for the system bus, since that doesn't require a graphical session, you will need to create a .conf file under a specific folder managed by dbus to allow your service to own the name in the bus, and also, specify which users can send and receive messages from your dbus.

The file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

  <policy context="default">
    <allow own="com.example.service"/>
  </policy>


  <policy context="default">
    <allow send_destination="com.example.service"/>
    <allow receive_sender="com.example.service"/>
  </policy>
</busconfig>

And it should be placed under: /etc/dbus-1/system.d/com.example.service.conf

By doing that, you will be able to let your service to acquire the bus name you want and make also allow the specific users to communicate with it.

References

Chapter 01 - DBus The Message Bus System

Systemd unit activation via dbus

Rodolfo Olivieri — Thu, 26 Dec 2024 15:30:11 +0000

The problem

Recently a co-worker of my team has asked me this trivial question:

Hey, the users will need to call systemctl ... on their own to activate our daemon?

Well, this is a simple question, right? I mean, it implies that we want to reduce friction from the user point of view to use our tool. If they call any commands we have in our terminal client, it should activate the daemon on it's own.

In my full ignorance, I thought to myself

Yeah, that's pretty easy. I think I can just change this setting in the service level and we are done...

What a fool I am.

We all know that systemd anddbus are beast of their own, but what I didn't know was that just a simple change on our own service files would lead me to hours of exploration, some documentations that are not properly documentated (don't judge, we all have done that.), and to my surprise, the answer again was very simple.

Why this is important?

Well, let me try to be real quick and conscise here. I work on a tool that will ship a client and a daemon that will work together to deliver some answer to the user in their own terminal. The tool is calledcommand-line-assistant. The daemon encapsulates all the core logic behind the operations we do and the client is just a regular client. It show stuff on the terminal.

To reduce the user friction and adoption, we thought that it would be a good idea that after you install the tool with:

sudo dnf install command-line-assistant

You could just easily do:

c "why systemd is so complex?"

And that would give you a real answer.

Pretty good, right? You don't need to tweak any configuration file, any settings, nothing. We deal with that stuff for you.

And why this was so difficult?

Well, to begin with, I'm not that experienced with systemd and dbus. This is my first time working with it, and it's been amazing. I'm loving all the challenges and knowledge I'm gaining, but dude... Sometimes I wonder why those things exists.

The main problem (besides the one above) is that we decided to split our dbus objects into two main categories:

query - com.redhat.lightspeed.query
history - com.redhat.lightspeed.history

The query category is responsabile for exporting and managing all stuff related to user queries, like the example above about systemd. The history category, on the other hand, serve the purpose to store, read and manage the user conversation cache. This is mainly used for users to remember the interactions they had with the tool.

Coulnd't you just follow a tutorial?

Well. I tried. And that was mainly my source of confusion...

See the below snippet:

[D-BUS Service]
Name=org.example.simple-dbus-service
Exec=/usr/sbin/simple-dbus-service
User=root
SystemdService=simple-dbus-service.service

Now, approach this with the idea of "I don't know what I'm doing" and your first guess, if you're like me, would be that this is something managed by systemd, right?

The docs for systemd gives you this nice paragraph:

For bus-activatable services, do not include a [Install] section in the systemd service file, but use the SystemdService= option in the corresponding DBus service file, for example (/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service):

Self-explanatory, right? I know...

The deal with that is that this small snippet I pasted above is actually a unit service... for dbus... Yeah, that's right. It turns our that dbus can have "units like" files just like systemd.

Any time that you end up seeing a path that begins with/usr/share/dbus-1/system-services, you know that this will be a dbus service, not systemd service.

In short, the purpose of this file is: Act as a intermediate service for activating your systemd unit.

What does the trick for activating the systemd unit is this part right here:

SystemdService=simple-dbus-service.service

By specifying the name of the systemd service it needs to trigger, whenever you publish a new message to your dbus object, it will trigger the systemd unit start for you.

What they don't tell you is, if you have a multi-object daemon, one service like that won't ever trigger your systemd unit.

Alright! And how did you overcome this?

The fix is pretty simple. For every object (or in this case, I'm calling "sub" object), you have to create a new dbus service file to hold the trigger for you.

Using the above categories I mentioned about my project, query and history, I would need to have two dbus services that would look something like this:

File: /usr/share/dbus-1/system-services/com.redhat.lightspeed.query.service

[D-BUS Service]
Name=com.redhat.lightspeed.query
Exec=/bin/false
User=root
SystemdService=simple-dbus-service.service

File: /usr/share/dbus-1/system-services/com.redhat.lightspeed.history.service

[D-BUS Service]
Name=com.redhat.lightspeed.history
Exec=/bin/false
User=root
SystemdService=simple-dbus-service.service

They can (and often will, in that setup) point to the same systemd unit file. The deal is that dbus will use the name of the service, in this case:

...
Name=com.redhat.lightspeed.history
...

To know that you sent a message from a client and dbus needs to trigger your systemd unit.

Conclusion

That's mainly it! It took me some long hours debugging and trying stuff out. Working with systemd/dbus is not easy, but when you learn something new about those huge systems, you feel so good.

That's it! Hope you liked the reading so far, and see you in the next post.

References

How to keep track of day-to-day workflow problems?

Rodolfo Olivieri — Thu, 26 Dec 2024 15:30:11 +0000

TLDR; Here's the repository: https://github.com/r0x0d/troubleshoot

What I'm even talking about?

So, recently I decided to start out a repository in GitHub to track out all the workarounds/solutions for common problems that I faced regularily in my machines. Problems like: "Why is my RDP in gnome not working?" or "I have configured fingerprintd, but it does not work"

Such problems are very common when you reset your machines and start from zero, or things just break when are you are sleeping. I was tired of losing countless hours looking around the internet to find that one answer from a forum in 2002 that solved the issue, hence, I created this new repository with the idea of tracking all those solutions.

How do you even structure something like that?

Well, the repository structure is quite simple. Is just a markdown file with well-defined headers. I choose to go simple here to avoid custom tooling or getting myself a new problem and make this the chicken-egg problem.

## <Operating system>
### <Category of the problem>
- <A small description>
-- <The solution>

This helps me to keep track of specific problems by category and by operating system. On my day to day, I usually use Linux for my work/development, and Windows for gaming.

Exceptions to the simple structure

Recently, I started to track out problems that are not OS specifics, but rather_tooling_ specifics. With that in mind, I had to add an exception to my simple structure:

## <Operating system>
### <Category of the problem>
- <A small description>
-- <The solution>

## Tooling

The Tooling header is platform agnostic. It is used for problems that could be seen either in Linux or Windows.