FrostyX's blog

Fedora Package Review Process reimagined

Tue, 07 Jul 2026 00:00:00 +0000

The Fedora Package Review Process is clunky, archaic, and not on par with what we expect when contributing to Open Source projects in this century. We all know that, and we all want it to improve. That being said, we need to realize what is currently our main bottleneck. Even though the process is not friendly to new contributors, they are doing just fine - at all times, we have hundreds of new packages in the queue. Our biggest problem is our inability to effectively review them.

I don’t think we talk about this problem enough. That’s why it felt so validating to hear Miro Hrončok voice my exact thoughts during the Flock to Fedora 2026 keynote.

In this blog post, I am going to elaborate on the ideas that we (mostly Miro) came up with, shooting shit in the hallway after the session.

Proposing new packages through PRs

This is an obvious one, we talked about the same idea with Zbigniew Jędrzejewski-Szmek at Flock to Fedora 2025. It is a necessary prerequisite for any potential improvements, which will allow us to have a workflow that contributors are familiar with, inline code comments, CI/CD, and other things that are not possible in Bugzilla.

Proposing new packages through PRs would be trivial to implement if we had all Fedora packages in a monorepo. Which we don’t, and we probably don’t want to have. And even if we wanted to have, it would require massive changes throughout the ecosystem.

As a workaround, we discussed having an intermediate repository on the forge.fedoraproject.org into which we would only propose new packages. It would have Packit CI enabled, and therefore every proposed package would automatically get a scratch build and a test suite run on top of it. Currently supported tests are rpmlint, rpminspect, and license-validate. We know that adding new tests is easy, as I am currently working on support for fedora-review.

Of course, a final approval from a fellow package maintainer would still be needed. Once accepted, we would merge the PR and automatically create a new DistGit repository and import the package. Then we would delete all data from the intermediate repository to keep it clean.

Bulk review

The review queue is and always has been in hundreds. Many of the packages are dependencies for something else, and people have no motivation to review them separately. And even if they do, it’s not always easy to test them on their own. This currently leads to accepting broken packages that nobody tested or ignoring the tickets completely.

We discussed the possibility of proposing multiple packages within one PR. They could be reviewed, tested, and accepted all at once.

For such PRs, we could automatically create a new project in Copr and build the packages in the order they were committed. We could nicely use Copr’s build batches feature here. If multiple packages were added in one commit, they could be built in parallel. If the contributor decides to force-push into their PR, we would wipe the Copr project and start over.

Auto import into DistGit

There is no reason why the contributor would have to manually run

fedpkg request-repo my-package 12345
fedpkg request-branch --all-releases

fedpkg clone foo
cd foo
fedpkg import /path/to/the/foo.src.rpm
fedpkg push
fedpkg build

fedpkg switch-branch f44
git rebase rawhide
fedpkg push
fedpkg build
# ...
# repeat for f43, f42, etc

We can request all the DistGit repositories and branches for them. And once they are created, we can automatically import the packages. There are some open questions though. How can the contributor signalize what branches they want? Should we use the git history from the PR? Can we use Forgejo actions to trigger the requests and imports?

Proposal vs prototype

I realize this is not a formal proposal but merely a blog post on my personal website. That was an intentional decision. We’ve been discussing and bike-shedding this topic for years, and yet we don’t have much to show for it. I am writing this article mainly not to forget the ideas we’ve had, and even though I am interested in your thoughts, this is not an RFC. I already started implementing a prototype, and soon I’ll record a demo for you. Then, I’ll start bothering you and asking for feedback.

In my opinion, it doesn’t have to be perfect. We just need to kick this off, implement something small that works, and improve it as time goes.

Maybe I should also say that I am not aiming to replace the current Package Review Process. My goal is to provide an alternative version of this process and allow contributors to choose which one they want to follow. Then, someday in the future, if the alternative turns out to be popular, possibly deprecating the old review process.

Flock to Fedora report 2026

Wed, 17 Jun 2026 00:00:00 +0000

This post is tough to write because Flock to Fedora is my favorite conference, and last year’s Flock might have been the best conference I’ve ever been to. I love the Fedora community, Prague is beautiful, the venue is nice, we always have so many interesting talks and workshops, the organizers do an amazing job preparing this event for us, so I feel really guilty saying that I did not have much fun this year. That is 100% on me, though. Flock bears no blame.

It wasn’t exactly the wisest decision ever to run my first half-marathon the very evening before the conference, and then waking up early to commute to Prague. It must have hit me much more than I was willing to admit. I feel fine physically, but I can’t pay attention to anything because nothing feels exciting. That is the most lifeless I’ve felt in a long time.

So, in case anyone is wondering … it was me, not you.

Highlights

Despite all that, these were the highlights of the event for me.

Forging Fedora Project’s Future With Forgejo

Great job on the migration from pagure.io to forge.fedoraproject.org. It was handled exceptionally well. Next, we look forward to the migration of src.fedoraproject.org to Forgejo, which can’t come soon enough. Tomáš Hrčka teased us that this migration may take considerably less time than the previous one because they already know how to do things (e.g., deploy Forgejo, etc).

DIY AI: Build a Private, Customizable Chatbot on Lean Hardware

Ellis Low showed us how to run an LLM on our laptops through Llama and how to interact with it. I really appreciated him saying that, except for this one small text-in, text-out magic black box, everything else is standard software engineering as we know it.

Fedora Council Strategic Proposals + FESCo Q&A

Most of the discussion revolved around a decline of new contributors and us failing to connect with the next generation. “They talk about changing wallpaper, we talk about burnout” – Aleksandra Fedorova.

What’s Cooking in Copr, Testing Farm, tmt, Packit and Log Detective

I found Pavel Raiskup’s return to the stage hilarious.

Scrapers gotta scrape scrape scrape

As presentations go, Kevin Fenzi’s talk about AI scrapers was the best. It started with minor A/V dificulities, which is a nice reminder to not feel bad, the next time it happens to you, because it happens to everybody. Even the main infra guy. Semi-joking aside, I enjoyed the brief history of web scraping and Kevin’s taxonomy of scrapers, clearly showing that not all scrapers are the same (e.g., web.archive.org). However, the current AI scrapers are the plague of the internet, and I am so glad the Fedora Infra team fights them as best as they can to keep our services running.

Chat with Adam

I ran into my former Copr team mate Adam Šamalík in the hallway, and we had a nice chat about life. When we still worked together (10 years ago, oh how the time flies), I randomly asked him what he did on a weekend. “We had no plans, so we bought plane tickets and went on a date to Amsterdam with my girlfriend”. Fucking what?! That was the coolest response ever. Since that day, I remember it every time my creaking, lazy bones struggle to do something spontaneous. Why am I telling it now? Adam is now happily living in the Netherlands full-time. Funny how one impromptu decision can completely change your life.

Chat with Emmanuel

Made friends with Emmanuel Seyman. He said hello after seeing the Fedora Podcast episode with me as a guest. I really enjoyed our chat, and I am going to follow up online because I think he’ll really like Sundaram Krishnan’s project coprtree.

Chat with Miro

Miro Hrončok shared some of his ideas about improving the Fedora Package Review Process with me. This deserves an article on its own, so stay tuned.

Edit: Please read the Fedora Package Review Process reimagined article.

Copr builders powered by bootc

Tue, 17 Jun 2025 00:00:00 +0000

As of today, all Copr builder virtual machines are now being spawned from bootc images, which is no small feat because the builder infrastructure involves multiple architectures (x86_64, aarch64, ppc64le, s390x), multiple clouds (Amazon AWS, IBM Cloud), and on-premise hypervisors. It scales up to 400 builders running simultaneously and peaking at 30k builds a day.

Before bootc

You can find some interesting history and previous numbers in Pavel’s article - Fedora Copr farm of builders - status of July 2021. The part it leaves out is how we used to generate the Copr builder images.

The process is documented in the official Copr documentation. In a nutshell, it involved manually spawning a VM from a fresh Fedora Cloud image, running Ansible playbooks to provision it, and then using custom scripts to upload the image to the right place. Because we need to build the images natively, we had to follow this process for every architecture.

The easiest workflow was for x86_64 builders running on our own hypervisors. It meant connecting to the hypervisor using SSH and running a custom copr-image script from the praiskup/helpers repository. While its usage looks innocent, internally it had to execute many virt-sysprep commands. It also required some guestfish hacks to modify cloud-init configuration inside of the image so that it works outside of an actual cloud. Then, finally, using the upload-qcow2-images script to upload the image into libvirt.

The same exact workflow for ppc64le builders. However, internally it had a special case uploading the image also to OSU OSL OpenStack.

For s390x builders, we don’t have a hypervisor where we could natively build the image. Thus we needed to spawn a new VM in IBM Cloud and run the previously mentioned copr-image script inside of it. Once finished, we needed to upload the image to IBM Cloud. This is supposed to be done using the ibmcloud tool, but the problem is that it is not FOSS, and as such, it cannot be packaged for Fedora. We don’t want to run random binaries from the internet, so we containerized it.

At this point, only x86_64 and aarch64 images for Amazon AWS remain.

While not straightforward to create a new AMI from a local qcow2 image, it’s quite easy to create an AMI from a running EC2 instance. That was our strategy. Spawn a new instance from a fresh Fedora Cloud image, provision it, and then create an AMI from it.

Current situation

I disliked exactly three aspects concerning the previous solution. It required a lot of manual work, the process was different for every cloud and architecture, and the bus factor was less than one.

Even though at this moment generating a fresh set of builder images still requires about the same amount of manual work as before, there is a potential for future automation. By switching to bootc and Image Builder, we were able to offload some dirty work to them while also unifying the process to follow the same steps for all architectures and clouds (with minor caveats).

The current process is temporarily documented here. We spawn a VM for every architecture and use it to build the system image from our Containerfile via the quay.io/centos-bootc/bootc-image-builder. Then we fetch the results and upload them where needed.

For Amazon AWS, we can utilize the image-builder upload feature which is amazing. But for other clouds and hypervisors, we still need our custom upload-qcow2-images and quay.io/praiskup/ibmcloud-cli. If image-builder could implement the missing support and enable uploading to all of them, that would be a major win for us.

Future plans

My goal is simple, I want one-button deployment. Well, almost.

When a change is made to our Containerfile, or when triggered manually, or periodically after a period of inactivity, I want the images to be automatically built for all architectures and uploaded to all the necessary places. Then seeing a list of image names and AMIs that I can either choose to use or ignore.

The bootc-image-builder-action seems like the perfect candidate, but the problem is that it cannot natively build images for ppc64le and s390x.

SNThrailkill recommended GitLab Runners but that would require us to maintain the runner VMs, which is annoying. Moreover, there is a potential chicken-and-egg problem, meaning that if we break our image, we might not be able to spawn a VM to build a new working image. We also wouldn’t be able to use the existing GitHub action and would have to port it for GitLab.

At this moment, our team is leaning towards Konflux and a tekton pipeline for building images. Fedora Konflux instance is limited to x86_64 and aarch64, so we would temporarily have to use an internal Red Hat instance which provides all the architectures needed by us.

Many questions are yet to be answered. Is Konflux ready? Does the pipeline for building images already exist? Does it support everything we need? Is it built on top of image-builder so that we can use its upload feature?

Pitfalls along the way

Hopefully, this can help Image Builder and bootc developers better understand their blind spots in the onboarding process, and also prevent new users from repeating the same mistakes.

Before discovering that bootc exists, our original approach was to use just Image Builder and its blueprints, and automatize the process using Packit. There were several problems. It was easy to build the image locally from our blueprint, but it wasn’t possible to upload the same blueprint to be built in a hosted Image Builder service. Additionally, I had several issues with the Blueprint TOML format. The order of operations is pre-defined (e.g. all users are always created before any packages are installed). There is no escape hatch to run a custom command. And finally, it’s yet another specification to learn. My recommendation? Just go with bootc.

Our main problem with bootc is the immutability of the filesystem. Can somebody please help me understand whether the immutable filesystem is a fundamental building block, a key piece of technology that enables bootable containers, or whether it is an unrelated feature? If it is technologically possible, our team would love to see officially supported mutable bootc base images. Currently, we are going forward with a hack to make the root filesystem transient.

One of the issues that probably stems out of the immutable filesystem is the necessity to change the default location of the RPM database. This hack is baked into the bootc base images and we needed to revert it because it causes Mock to fail under some specific circumstances. This unfortunately cost us many many hours of debugging.

The process of building system images is quite storage intensive in /var/lib/containers and /run. To avoid running out of disk space on our virtual machines, we had to turn our swap partition into a data volume and mount the problematic directories there. Not sure if there is something that image-builder can do to make this a less of problem.

We build the system images natively on VMs of the same architecture that they are targeted for, but then we fetch all of them to an x86_64 machine and upload the images to the respective clouds from there. We discovered a bug in cross-arch upload to AWS, which was promptly confirmed and fixed by the image-builder team. Big customer satisfaction right here.

We also struggled with setting up AWS permissions for the image-builder upload command to work correctly. We tried running it, fixing the insufficient permissions it complained about, running it again, and again, and so on. I don’t recommend this approach. It turns out there is a documentation page with instructions.

I hope this chapter doesn’t come across as too discouraging. In fact, we found workarounds for all of our problems, and we are now happily using this in production. So you can probably too.

Flock to Fedora report 2025

Mon, 09 Jun 2025 00:00:00 +0000

Flock to Fedora is my favorite conference and this year was no exception.

Too many good presentations and workshops to name them all. But I want to mention at least the most surprising (in a good way) ones. It takes some courage to be the first person to go for a lightning talk, especially when lightning talks aren’t even scheduled and organizers open the floor at the very moment. Smera, I tip my hat to you. Also, I was meaning to ask, how do graphic designers choose the FOSS project they want to work on? As an engineer, I typically get involved in sofware that I use but is broken somehow, or is missing some features. I am curious what is it like for you. Another pleasant surprise was Marta and her efforts to replace grub with nmbl. I will definitely try having no more boot loader. In a VM though, I’d still like to boot my workstation :D.

Random thoughts

We bunked with Pavel, which made me think of this office scene.

Something happened to me repeatedly during this conference and amused me every time. I introduced myself to a person, we talked for five minutes, and then the person asked “so what do you do in Fedora?”. I introduced myself once more, by my nickname. To which the immediate reaction was “Ahaaa, now I know exactly what you do!”. I am still laughing about this. Organizers, please bring back FAS usernames on badges.

It was nice to hear Copr casually mentioned in every other presentation. It makes the work that much more rewarding.

My favorite presentation was Bootable Containers: Moving From Concept to Implementation. I’ve spent all my free time over the last couple of months trying to create a bootc image for Copr builders, and seeing Sean falling into and crawling out of all the same traps as myself was just cathartic. We later talked in the hallway and I appreciated how quickly he matched my enthusiasm about the project. He gave me some valuable advice regarding CI/CD for the system images. Man, now I am even more hyped.

I learned about Fedora Ready, an amazing initiative to partner with laptop vendors and provide a list of devices that officially support Fedora. Slimbook loves Fedora so much that they even offer a laptop with Fedora engravings. How amazing would it be if my employer provided this option for a company laptop? What surprised me, was not seeing System76 on the list. I am a fan of theirs, so I am considering reaching out.

Feeling a tap on your shoulder 30 seconds after you push a commit is never a good sign. When you turn around, Karolina is looking into your eyes and saying that f’d up, you immediately know that push was a bad idea. For a petite lady, she can be quite terrifying :D. I am exaggerating for effect. We had a nice chat afterward and I pitched an idea for an RPM macro that would remove capped versions from Poetry dependencies. That should make our lives easier, no?

One of my favorite moments this year was chilling out with Zbigniew on a boat deck, cruising the Vltava River, and watching the sunset over the beautiful city of Prague. Kinda romatic if you ask me. Just joking, but indeed, it was my pleasure to get to know you Zbigniew.

The JefFPL exchange

The conference began with a bittersweet moment - the passing of the Fedora Project Leadership mantle from Matthew Miller to Jeff Spaleta.

I didn’t know Jeff before, probably because he was busy doing really effin cool stuff in Alaska, but we had an opportunity to chat in the hallway after the session. He is friendly, well-spoken, and not being afraid to state his opinions. Good qualities for a leader. That being said, Matthew left giant shoes to fill, so I think it is reasonable not to be overly enthusiastic about the change just yet.

Matthew, best wishes in your next position, but at the same time, we are sad to see you go.

FESCo and Fedora Council

The FESCo Q&A and the Fedora Council AMA were two different sessions on two different days, but I am lumping them together here. Both of them dealt with an unspecified Proven Packager incident, the lack of communication surrounding it, and the inevitable loss of trust as a consequence.

I respectfully disagree with this sentiment.

Let’s assume FESCo actions were wrong. So what? I mean, really. Everybody makes mistakes. I wrote bugfixes that introduced twice as many new bugs, I accidentally removed data in production, and I am regularly wrong in my PR comments. Yet I wasn’t fired, demoted, or lost any trust from the community. Everybody makes mistakes, it’s par for the course. Even if FESCo made a mistake (I am not in the position to judge whether they did or not), it would not overshadow the majority of decisions they made right. They didn’t lose any of my trust.

As for the policies governing Proven Packagers, one incident in a decade does not necessarily imply that new rules are needed. It’s possible to just make a gentlemen’s agreement, shake hands, and move on.

That being said, I wanted to propose the same thing as Alexandra Fedorova. Proven Packagers are valuable in emergencies, and I think, it is a bad idea to disband them. But requiring +1 from at least one other person before pushing changes, makes sense to me. Alexandra proposed +1 from at least one other Proven Packager, but I would broaden the eligible reviewers to also include Packager Sponsors and FESCo members. I would also suggest requiring the name of the reviewer to be clearly mentioned in the commit description.

Don’t be sad if you missed the conference. There are recordings.

Shoving a chess engine up your butt

Sun, 29 Dec 2024 00:00:00 +0000

In the Lex Fridman Podcast episode #327, Levy Rozman (aka GothamChess) explained a scandal, alleging a chess grandmaster Hans Niemann of cheating at a tournament. Supposedly, it was done through a remotely controlled device inserted into his backside, allowing him to receive the next best move encoded in Morse code vibrations. And because I am evidently twelve years old, I thought it would be really funny to implement this. By the way, Ron Sijm is likely as immature as me, because he beat me to it.

Disclaimer: I am not endorsing cheating in chess or any other sport, I don’t know if the allegations were true or not, and to be honest, I don’t care. I don’t know any of the people involved, and I don’t even play chess. This project is just for shits and giggles, not so that y’all can experience more pleasure during chess tournaments.

Two-minute demo

This post is too long and you will probably not read it. So here is a fun demo of the final product.

Scope of the project

At our disposal, we have several chess engines capable of beating any human. We also have a large offering of intimate hardware built on top of open standards. The most straightforward way to encode chess moves is the Morse code, even though it is not the most effective choice in this situation. Squares on chess boards go from a1 to h8, which leaves us with two-thirds of the alphabet unused, making the code for every character n-times (I am bad at math) longer than necessary. However, creating an optimized encoding is outside the scope of this project.

Playing one side of the chess board will be a two-man job. The agent in the field, receiving intelligence through his anal cavity, and the operator behind the computer monitor, querying a chess engine through the interface we will create.

Joking aside, I could probably crank out a working solution in Python in under an hour just by gluing inquirer, stockfish, morse-talk, and buttplug-py together. But where would be the fun in that? That’s why I am going to learn a new programming language on this project.

Chess engines

There are several chess engines to choose from, such as Stockfish, AlphaZero, Lc0, Shredder, etc. Some of them giving us a choice between running them locally or spawning an instance through lichess.org. I randomly picked Stockfish out of the hat because it is an open-source project, and it is easy to run locally.

Chess grandmasters average around 2600 Elo rating, and according to Gary Linscott, Stockfish performs at 3600 Elo. Don’t worry that it won’t beat our opponents.

To keep things simple, we can say that chess engines are services running in the background (and liken them to Unix daemons). They don’t have any graphical interfaces or CLI tools for interacting with them. At least not tools in the conventional sense. Instead, third-party programs can communicate with chess engines through the Universal Chess Interface (UCI).

$ stockfish
...

uci
id name Stockfish 17
id author the Stockfish developers (see AUTHORS file)
...
uciok

isready
readyok

ucinewgame

position startpos moves a2a3 h7h6 b2b3

go depth 15
...
bestmove d7d5 ponder c1b2

As you can see, Stockfish provides a painfully bad REPL and UCI arms as with a set of usable commands. There is no TAB completion, no help, no command history, no syntax highlighting, no prompt to distinguish between commands and their output, and so on. For better readability, I rendered the inputs red, but in the terminal, everything is the same color.

In this session, we started the game, white moved from a2 to a3, black moved from h7 to h6, then again white moved from b2 to b3. Stockfish then recommends black to move from d7 to d5 and expect white to retaliate with c1 to b2.

Gleam, Elixir, and the BEAM

One of my goals for this project was to learn Gleam, which is a new addition to the BEAM family of languages, preceded by Erlang and Elixir. The main purpose of these languages is to be used for building massively distributed, high-availability systems. So I will be the first one to admit that this project doesn’t exactly fit the use-case. Who knows, maybe I plan to build some distributed system in the future and treat this project as a means to learn the languages.

The BEAM is a virtual machine for running Erlang bytecode in the same sense that JVM is a virtual machine for Java, and .NET is a ~~virtual machine~~ platform for C#. And just as Java, Clojure and Scala compile to the JVM bytecode, C#, Visual Basic, and F# compile to the .NET bytecode, Erlang, Elixir, and Gleam compile to the BEAM bytecode. Allowing us to share code across the related languages.

The main part of this project will be written in Gleam, but we will use Elixir interop for some peripherals. Starting with one of them right now. To control Stockfish we can use Elixir ports, which is the best abstraction for interacting with stdin-based programs that I’ve ever seen.

defmodule Stockfish do
  def new_game do
    port = Port.open({:spawn, "stockfish"}, [:binary])
    Port.command(port, "uci\n")
    Port.command(port, "isready\n")
    Port.command(port, "ucinewgame\n")
    port
  end
end

At the, we are returning the port, so we can pass it to other functions. To implement a move function for example.

defmodule Stockfish do
  ...

  def move(port, position, history) do
    moves =
      history
      |> Enum.concat([position])
      |> Enum.join(" ")
    Port.command(port, "position startpos moves #{moves}\n")
  end
end

You wouldn’t believe how easy it is to use this code from Gleam through externals. Since Gleam is statically typed, we need to tell the compiler the shape of our Elixir functions, but that’s all.

import gleam/erlang/port.{type Port}

@external(erlang, "Elixir.Stockfish", "new_game")
fn new_game() -> Port

@external(erlang, "Elixir.Stockfish", "move")
fn move(game: Port, position: String, history: List(String)) -> Nil

For illustrative purposes, we are going to avoid the domain-specific type masturbation and stick with lists and strings. In the actual implementation, we’ll likely want to avoid exposing the Port directly, and create custom types for Position and History.

Now we can use the functions in Gleam.

new_game() |> move("a2a3", [])

Morse code

Several packages for encoding and decoding Morse code were available, but I decided to write my own called Morsey. I don’t expect any rapid development in the Morse code department, causing this reinvention of the wheel to be the final blow to my personal life, and putting me on a hamster wheel of perpetual maintenance of my Open Source projects.

The source code is available in FrostyX/morsey repository, and look, we already got a star from the one and only Hayleigh Thompson. The package can be used like this:

import gleam/io
import morsey

let text = "Hello world!"
case morsey.encode(text) {
  Ok(symbols) ->
    io.println("Morse code for " <> text <> " is " <> morsey.to_string(symbols))
  Error(morsey.InvalidCharacter(char)) ->
    io.println_error("Invalid character: " <> char)
}

// And the output will be:
// .... . .-.. .-.. --- / .-- --- .-. .-.. -.. -.-.--

We can see several Gleam features in this example. It doesn’t have exceptions and instead returns errors as values. It leans heavily towards pattern matching, there is not even an if-else statement in the language. The pattern matching is exhaustive, otherwise, I would definitely forget to handle the error case. I love all of these features. The one I quite dislike, however, is that for the sake of simplicity, Gleam doesn’t support string formatting.

Intimate hardware

On paper, hardware should’ve been the easy part. There is an exhaustive list of manufacturers and devices supported by the buttplug.io project. I randomly picked some device that was possible to buy in Czech Republic. It paired with my phone within seconds, so I started celebrating an easy victory, just to waste the rest of the day trying to pair the device with my computer.

Here is the ten-thousand-foot view. A toy communicates with your computer via Bluetooth LE. Some manufacturers require pairing before use, some don’t. You don’t use the system Bluetooth manager to connect to the device. Clients like buttplug-py, buttplug-js, etc, don’t control the toy directly, they only communicate with a server like intiface-engine via websockets. The server then does the heavy lifting. You can run the server like this:

$ cargo install intiface-engine
$ ~/.cargo/bin/intiface-engine --websocket-port 12345 --use-bluetooth-le

Websockets

The previous chapter linked officially supported libraries that provide a high-level interface to control the devices. However, there weren’t any for the BEAM family of languages, so I had to raw-dog the websocket communication. It’s almost embarrassing that in fifteen years of programming, I have never used websockets, and this was my first exposure.

An example session can look like this (The snippet only shows messages from the client to the server. The responses were omitted).

$ cargo install websocat
$ ~/.cargo/bin/websocat ws://127.0.0.1:12345/
[{"RequestServerInfo": {"ClientName": "Test Client", "MessageVersion": 1, "Id": 1}}]
[{"RequestDeviceList": {"Id": 2}}]
[{"StartScanning": {"Id": 3}}]
[{"VibrateCmd": {"DeviceIndex": 0, "Speeds": [{"Index": 0, "Speed": 500}], "Id": 4}}]
[{"StopDeviceCmd": {"DeviceIndex": 0, "Id": 5}}]

I created a Gleam package with a high-level interface around this, called Bummer. Its usage is fairly simple.

import bummer

case bummer.connect("ws://127.0.0.1:12345/") {
  Ok(socket) -> {
    io.println("Connected to intiface-engine websocket")
    io.println("Initiating a test sequence")

    bummer.scan(socket, 5000)
    bummer.vibrate(socket, 500)
    bummer.rotate(socket, 500)

    io.println("Test sequence finished")
  }
  Error(_) ->
    "Cannot connect to intiface-engine websocket. Is it running?"
    |> io.println_error

The public API is leaking some internals. The users probably don’t even want to know what communication protocol is being used, and it should be treated as an implementation detail. This calls for more custom types.

Also, websockets are a bi-directional protocol but bummer is currently unidirectional. It was really easy to send messages to the server but due to the Gleam + Elixir interop, I couldn’t figure out how to properly handle messages from the server. I started running out of time, so this remains unfinished. PRs are more then welcome.

Tying it all together

Throughout this blog post, we’ve seen code snippets for communicating with Stockfish, converting text to Morse code, and controlling intimate toys via websockets. The last missing piece is vibrating a Morse code sequence.

fn vibrate(socket: bummer.Connection, sequence: morsey.Sequence) -> Nil {
  // International Morse Code
  // 1. The length of a dot is one unit.
  // 2. A dash is three units.
  // 3. The space between parts of the same letter is one unit.
  // 4. The space between letters is three units.
  // 5. The space between words is seven units.
  let interval = 200
  case sequence {
    [] -> Nil
    [first, ..rest] -> {
      case first {
        morsey.Dot -> bummer.vibrate(socket, interval)
        morsey.Comma -> bummer.vibrate(socket, interval * 3)
        morsey.Space -> sleep(interval * 3)
        morsey.Break -> sleep(interval * 7)
        morsey.Invalid(_) -> Nil
      }
      vibrate(socket, rest)
    }
  }
}

All code is available in my FrostyX/crooked-rook repository.

A room for improvement

This being a fun little project to keep myself busy over the holidays, having no real use-case, and providing zero value to anyone, it had to be cut short. Codes for letters in the Morse alphabet are too long. One could come up with much more effective encoding. Additionally, there is no need to encode the whole move (e.g. a2a3). An experienced chess player can infer the starting position (a2) from the end position (a3). These two combined improvements would result in significantly shorter messages.

The other limitation is having a human relay between the player and the chess engine. I am sure there are AI models capable of observing a chessboard and recognizing all the figures and their positions. The whole system could be autonomous with the exception of the human player.

Sounds like a pt.2 next holiday?

Copr Modularity, the End of an Era

Wed, 23 Oct 2024 00:00:00 +0000

Our team has put a lot of effort into the possibility of building modules in Copr. This feature went through many iterations and rewrites from scratch as the concepts, requirements, and goals of Fedora Modularity kept changing. This will be my last article about this topic because we are planning to drop Modularity and all of its functionality from Copr. The only exceptions are Module hotfixes and module dependencies, which are staying for good (until they are supported by Mock and DNF).

Why?

The Fedora Modularity project never really took off, and building modules in Copr even less so. We’ve had only 14 builds in the last two years. It’s not feasible to maintain the code for so few users. Modularity has also been retired since Fedora 39 and will die with RHEL 9.

Additionally, one of our larger goals for the upcoming years is to start using Pulp as a storage for all Copr build results. This requires rewriting several parts of the backend code. Factoring in reimplementation for module builds would result in many development hours wasted for very little benefit. All projects with modules will remain in the current storage until the Modularity is finally dropped.

Schedule

In the ideal world, we would keep the feature available as long as RHEL 9 is supported, but we cannot wait until 2032.

October 2024 - All Modularity features in Copr are now deprecated
April 2025 - It won’t be possible to submit new module builds
October 2025 - Web UI and API endpoints for getting module information will disappear
April 2026 - All module information will be removed from the database, and their build results will be removed from our storage

Communication

It was me who introduced all the Modularity code into Copr, so it should also be me who decommissions it. Feel free to ping me directly if you have any questions or concerns, but you are also welcome to reach out on the Copr Matrix channel, mailing list, or in the form of GitHub issues. In the meantime, I will contact everybody who submitted a module build in Copr in the past two years and make sure they don’t rely on this feature.

Ruff my dirty code

Tue, 17 Sep 2024 00:00:00 +0000

Static analysis tools have their limitations but regardless they help us quickly discover many types of bugs. That is not a controversial take. What may be disputed is whether enabling them for large projects with a long-standing history is worth the effort and I would say it most definitely is. In this article will take a look at how to report problems only for new code, lowering the barrier to entry to the minimum.

The dilemma

Creating a new project from scratch is so enjoyable, isn’t it? No technical debt, no backward compatibility, no compromises, all the code is beautifully formatted and brilliantly architected. We don’t really need to run any static analysis tools but we do it anyway just so that they can say that “All checks passed!” and that we are awesome. Obviously, I am being sarcastic, but the point is that enabling such tools for new projects is easy.

Now, let’s consider projects that have been developed in the span of decades. Everything is a mess. Running pylint, mypy or ruff overwhelms you with hundreds or thousands of reports and leaves you with the following dilemma - Should you just abandon all hope and pretend that this never happened? Should you pollute your codebase with a bunch of # pylint: disable=foo comments? Or should you devote the next month of your life to rewriting all the problematic code while risking to introduce even more bugs in the process?

There is one more option that worked for our team quite well for years now - running static analysis tools for the whole project but reporting only newly introduced problems.

Reporting only new problems

There is a tool called csdiff which takes two lists of defects (formatted errors from static analysis tools), compares them, and prints only defects that newly appeared or that are missing from the second list. This can be understood either as newly added or fixed defects.

We created a tool called vcs-diff-lint which does the obvious thing. It runs pylint, mypy, and ruff for the main branch of your git repository, and then runs them again for your current branch. There we have our two lists of defects which get internally passed to csdiff. The output looks like this.

$ vcs-diff-lint
Error: RUFF_WARNING:
fedora_distro_aliases/__init__.py:23:20: F821[undefined-name]: Undefined name `requests`

Error: MYPY_ERROR:
fedora_distro_aliases/__init__.py:11: mypy[error]: "None" has no attribute "append"  [attr-defined]

We can clearly see that our code introduced two new errors. Sometimes it may be useful to also see how many existing errors our code fixed. In that case, use vcs-diff-lint --print-fixed-errors.

Please follow the installation instructions here.

Github Action

I don’t trust myself (or anyone else for that matter) to run the vcs-diff-lint tool manually for every proposed change. And neither should you. There is an easy-to-use GitHub action that runs the tool automatically for every pull request. It tries to be as user-friendly as possible and reports the problems as comments directly in your “Files changed” section.

Please follow the installation instructions here or take a look at our setup as an example.

Ruff support

Ruff is all the rage nowadays, and rightfully so. It checks our whole codebase in under a second (20ms actually) while mypy takes its sweet time and finishes around a one-minute mark. Up until recently, the vcs-diff-lint tool supported only pylint and mypy but since the last release, ruff is supported as well. Please give it a try.

As a matter of fact, I am writing this article as a celebration of the new vcs-diff-lint release.

But what about diff-cover

Speaking about differential static analysis, you may have already heard about diff-cover. It has many more contributors and GitHub stars so why would I recommend trying vcs-diff-lint instead?

diff-cover runs static analysis for the whole project but reports only problems for lines changed by the patch. This can’t fundamentally catch problems caused by the changed code but lying outside of it. For example when you add a parameter to a function definition but forget to update all of its calls
diff-cover doesn’t provide a GitHub action
vcs-diff-lint supports ruff and ruff is cool now

Do you want to contribute to Copr?

Thu, 27 Jun 2024 00:00:00 +0000

I had a realization at this year’s DevConf. Even if people want to contribute to large open-source projects, they have no idea how. Or they don’t even realize they can contribute in the first place and that such a thing would be appreciated That’s why I wanted to try this experiment and offer 5 interesting RFEs for the Fedora community to implement.

Why you should contribute

Copr is a build system and third-party package repository for RPM-based distributions. It’s similar to AUR for example. The project has been around since 2012 and has become an integral part of the Fedora packaging ecosystem, as corroborated by many conference talks and articles mentioning it. We currently host 29000 projects from 7000 Fedora users and the package downloads are in millions.

At this moment, there are 275 valid and triaged issues and RFEs in the issue tracker. On this board, you can see the roadmap for the upcoming months, years, and possible futures. One obvious reason for contributing to the project is getting a feature implemented sooner. Another reason is to improve your skills as a software developer. It may be more fun and more useful than creating a new TODO application from scratch. Last but not least, it’s never a bad idea to show your skills and collaborate with people who can do job referrals. That’s how I got my dream job 9 years ago. I think this is a great opportunity for students looking to get some infield experience during the summer break.

Don’t worry if you don’t feel competent enough to contribute. We have documentation for setting up your local development environment, tests and a review process to improve the code quality, and a Matrix channel for more informal communication. If you ever get stuck somewhere in the process, please ping me and mention this article.

How you can contribute

Of course, you can pick any issue from the Copr issue tracker that seems interesting to you. Or you can pick any other project for that matter, help is appreciated everywhere. However, In this article, I wanted to put together a list of interesting and useful RFEs that our team won’t have time to implement in the near future. Please let us know if you would like to collaborate with us on any of them. We will get you started and make sure you have all the information you need.

1. External repository validation

Difficulty:	Trivial
Required skills:	Python
Ticket:	fedora-copr/copr#1178
Contributor:	@jaitjacob

Copr projects can depend on other projects. It is possible to specify such a dependency via a fully qualified URL or a shortcut in the copr://owner/project format. It would be nice to have a validation making sure that users cannot set a dependency on a non-existing project (due to typos for example).

2. Possibility to force delete a project

Difficulty:	Easy
Required skills:	Python
Ticket:	fedora-copr/copr#2629

Through the Copr CLI utility, it is possible to delete an existing project with all of its builds. This, however, fails when some of the builds are not yet finished. We would like to improve the respective API endpoint to automatically cancel all running builds, making sure that no matter the state of the project, it can be deleted.

3. Dark mode support

Difficulty:	Medium
Required skills:	HTML, CSS, Javascript
Ticket:	fedora-copr/copr#3150

The Copr website offers only one theme and that is black text on a white background. According to many online articles, dark-mode web designs are getting increasingly more popular, helping to reduce eye strain and power consumption. We would like our users to have the option to choose whether they prefer light or dark mode of the website.

4. Webhook history

Difficulty:	Medium
Required skills:	Python, HTML
Ticket:	fedora-copr/copr#304
Contributor:	@jaitjacob

Copr provides integration with Git forges like GitHub, GitLab, and Bitbucket through webhooks. Usually, everything works smoothly. However, when builds are not being triggered when they should be, or conversely, when they are triggered multiple times, it is hard for users to debug the issue. We would to have a table of all received webhooks. This would allow project owners to understand what exactly happened.

5. Actions overview

Difficulty:	Hard
Required skills:	Python, HTML
Ticket:	fedora-copr/copr#1108

Copr is a complex system, requiring various so-called “actions” to run in the background. For example, in a project overview, there is a button for regenerating the project repositories. When clicked, it triggers an asynchronous action which is performed on an entirely different server. It usually takes seconds to complete but it may take longer depending on the current queue. It may even fail for some unexpected reason. Project owners have no way of knowing what actions affected their projects and whether they finished successfully. We would like to have a table for every project, showing all the actions that happened.

DevConf 2024 report

Sat, 15 Jun 2024 00:00:00 +0000

This year’s DevConf was a blast and the best time I had at a conference probably since 2019 Flock in Budapest. Thank you all who make events like these happen.

Day 1

It all started a bit unfavorable for me. I arrived underslept, forgot that am supposed to have a ticket, and when I finally got to the Go language basis course, which I was very much looking forward to, the room was already packed and we weren’t allowed in.

Without much thinking, I joined the Upstream maintainers meetup instead, which turned out to be a good choice. For me, the most interesting part was a discussion between an OpenSSL maintainer and an LVM maintainer about why they don’t have many contributions from the community. What I realized afterward:

People only care about one or two layers below whatever they are working on. For the lack of a better example, as a Copr developer, I am likely to provide feedback or a small patch for createrepo_c which we directly build on top of. But it is very unlikely I will ever submit a patch for some of its dependencies like libxml2 or zchunk. They are too far removed from me.
Even if I was feeling philanthropic and wanted to spend my vacation hacking on OpenSSL, I have no idea which of the 2k issues in their tracker would be a good fit.

Two takeaways for me. First, I think we should try to reach contributors only one level up and one level down from our project. Also, I would like to pick five RFEs from the Copr backlog which would be nice to have but our team won’t have time to implement them. Probably ever. I will write a short paragraph about each of them, score them with difficulty, and list the needed skills for their completion. I want to see if anyone from the community would be interested in implementing them.

On my way to another talk, I stumbled into Florian Festi. We haven’t talked in person for years, so I tried to re-introduce myself. I have high regard for Florian, so of course, I couldn’t even stutter out my name. I don’t know why. He is a kind and friendly dude with a majestic fluffy beard. There was no reason to be nervous. Anyway, we discussed the insufficiencies of the Python RPM documentation, and what should be done with them.

The price for the best presentation of the conference goes to Evan Goode for Learning from Nix: how other package managers can do better. The topic was novel, the analysis was on point, and I very much appreciate his speaking skills. After the talk, I lamented about Nix not being packaged for Fedora, which is in my opinion a big drawback. During the lecture, the whole room raised their hands that they know Nix. Then the whole room raised their hands again that they use an RPM-based GNU/Linux distribution. Yet nobody raised their hand that they actually use Nix. I think the reason is that it isn’t easily available on Fedora. And many of us just are not willing to run curl ... |sudo bash.

After lunch, I finally got the opportunity to meet and chat with Dan Čermák in person, after having several online discussions about rpm-spec-language-server. His lightning talk was on the same topic - Creating a Language Server for RPM Spec Files. Cudos for doing a live demo with a mic in one hand. Also, it was nice to see somebody else use Emacs.

Day 2

This year, I decided to try something different, and … don’t go. I stayed home, recharged my social battery, and worked on all the action items from the previous day.

I submitted a PR with Python API examples for the RPM documentation and texted Evan a Copr project with Nix that could be a good starting point for the official package. I created a containerized reproducer for a Vim issue we are having with Dan in the rpm-spec-language-server project. And finally, I picked some interesting Copr RFEs that I would like to offer to the community.

Not attending the second day hugely paid off. I was pumped for Day 3.

Day 3

I skipped breakfast and came in early to see Gickup - Keep your repositories safe by Andreas Wachter. I was the first one in the room and Andy promised to do the talk even if I was the only one. Fortunately, more people came. Afterward, we had a long chat about the Gickup project and the things I am planning to contribute. You see, I started working on a similar project a few weeks ago but Gickup is miles ahead, which is great because now I don’t have to implement all of it by myself from scratch.

Mainly I am planning to create a systemd service so it doesn’t have to be run in a container, add support for backing up project metadata like followers, stars, etc (a good opportunity to learn Go), and package the tool for Fedora.

On the Self-hosting/homelab meetup, I learned about new interesting ways how to over-engineer my 200€ ThinkCentre running from behind the couch. Specifically, I am planning to take a look at healthchecks.io, Borg, gethomepage.dev, and some services for push notifications like ntfy or gotify.

During a lunch break, I picked switches for my next mechanical keyboard and tried to hit 10 WPM on this … thing.

I got unexpectedly mentioned in Michel Lind’s talk about Applying Production Engineering mindset to RPM Packaging for fun and profit. Not going to lie, felt really good.

After the lecture, we brainstormed on moving the fedora-review project from Pagure to GitLab so that we can set up Packit for it and have a proper release process and CI. Which is currently the biggest pain point of the project. As Neal Gompa pointed out, that is the exact reason why neither of us publishes a release even though it is needed. It is so bad I rather generated a downstream patch for the Fedora package the last time I needed to ship something.

And that was it, the end of the conference.

Closing thoughts

The event schedule was packed with ten tracks going in parallel at any given moment. It was virtually impossible to attend everything I wanted to. Good thing there are recordings to keep me occupied during all my meals this week.

Also, I am not a social person. I know that, you know that, everybody knows that. I loved to see you all but I cannot handle being three consecutive days in crowds of hundreds of people without feeling like shit. That’s something I had to contend and reconcile with. Skipping one day paid off, my social battery held up, and I am already looking forward to DevConf 2025.

Surprisingly, I felt so great afterward, that on my way home I even approached a beautiful woman that smiled at me in a park. We had a nice conversation but she was married so we parted ways after a few minutes. She liked my compliment though. Hopefully, it made her day better.

LSP for Vim Boomers

Tue, 21 May 2024 00:00:00 +0000

There are many great videos and articles about configuring NeoVim LSP using quickstart plugins or opinionated NeoVim distributions. Here I would like to focus on people who still use Vim and refuse to use plugins and custom configuration.

This is a supporting article for my LSP for Vim Boomers video, so you can easily copy-paste things. Please watch the video for more information.

Installation

mkdir -p ~/.vim/pack/vendor/start
cd ~/.vim/pack/vendor/start
git clone https://github.com/prabirshrestha/vim-lsp.git
sudo dnf install python3-lsp-server+all

Configuration

let g:lsp_diagnostics_enabled = 0

if executable('pylsp')
    au User lsp_setup call lsp#register_server({
        \ 'name': 'pylsp',
        \ 'cmd': {server_info->['pylsp']},
        \ 'allowlist': ['python'],
        \ })
endif

function! s:on_lsp_buffer_enabled() abort
    setlocal omnifunc=lsp#complete
    nmap <buffer> gd <plug>(lsp-definition)
    nmap <buffer> gr <plug>(lsp-references)
    nmap <buffer> K <plug>(lsp-hover)
endfunction

augroup lsp_install
    au!
    " call s:on_lsp_buffer_enabled only for languages that has the server registered.
    autocmd User lsp_buffer_enabled call s:on_lsp_buffer_enabled()
augroup END

Appendix

1. Pre-configured servers

There is a plugin not mentioned in the video called vim-lsp-settings. It features a long list of programming languages, and for each, configuration which LSP server should be used. If you wish to make the tradeoff and depend on one more plugin in exchange for a shorter ~/.vimrc, then throw away the Python-specific configuration from the previous example and do

cd ~/.vim/pack/vendor/start
git clone https://github.com/prabirshrestha/vim-lsp.git

2. Performance

A Reddit comment suggests that the following configuration line can noticeably boost the LSP performance.

let g:lsp_use_native_client = 1

3. Alternative LSP plugins

A possible alternative to vim-lsp might be yegappan/lsp. It should have a similarly easy configuration and it may be slightly faster. However, it requires Vim 9 and higher. Another alternative is ALE which should provide a faster autocomplete according to this Reddit comment. Example configuration:

set omnifunc=ale#completion#OmniFunc
nnoremap K <cmd>ALEHover<CR>
nnoremap <leader>gd <cmd>ALEGoToDefinition<CR>
nnoremap <leader>gr <cmd>ALEFindReferences<CR>
nnoremap <leader>ca <cmd>ALECodeAc
let g:ale_completion_enabled = 1