acidicneko's blogpost for GSoC'26

Adding FreeBSD Packaging Support

Wed, 01 Jul 2026 09:30:00 +0530

In my last post we added a shared utility, rtems-pkg.

Now that I am ahead of the proposed schedule, I decided to also add FreeBSD support as well.

The Port system

FreeBSD port is a framework for compiling and installing third-party software from its original source code. Part of the FreeBSD Ports Collection, a port is essentially a set of instructions containing the source’s download location, required patches, build parameters, and installation steps.

Building rtems-pkg: A Universal Packaging Wrapper

Tue, 16 Jun 2026 09:30:00 +0530

Love is the death of duty.

Morning ladies and gentlemen.

With the temperatures here in India reaching 43°C during the day, I realised I am made for the North which knows no king but the king in the North, whose name is Stark! ;|

Moving ahead we are close to the GSoC mid-term evaluation. I have almost completed all my mid-term goals.

After fixing the RPM packaging pipeline and building the Debian one from scratch, I ran into a problem: almost every packager has a different packaging flow, and remembering all of them is a pain. What I really wanted was a single command that could switch between packagers on the fly, without having to memorize a dozen different invocations for each one.

Completing work on Debian Packaging support.

Sat, 13 Jun 2026 10:30:00 +0530

Morning fellas! It’s sunny with a blue blue sky outside today!

My last blog was about RPMBuild Failure. This wasn’t the only thing that I was working on in the last week.

I have also been working on completing the Debian Packaging support. My blog on 3rd of March concluded some of my initial work which was buggy.

Writing templates

The first obvious step was to write templates which would serve as the base for packaging different boards.

RPMBuild Failure

Fri, 12 Jun 2026 22:00:00 +0530

Ladies and gentlemen. Turns out there were a few bugs in the existing rpmbuild packaging pipeline.

On 6th of June, I decided to test out the existing rpmbuild packaging on my freshly installed Fedora 44 system. I cd’d into rtems-deployment directory. I ran ./waf rpmspec to generate spec files from the provided template i.e pkg/rpm.spec.in. Waf successfully generated those in the out/ directory. After generating spec files, I decided to build for the amd/amd-kria-k26 board. The command to build a rpm package from spec file is:

Coding period starts

Wed, 27 May 2026 22:00:00 +0530

After almost a month of community bonding period, coding officially starts today. I went through my proposal once again to make sure I am in sync with what I have to actually build. After going through it once, I started working on debian packaging support. I laid most of the ground work for it during the proposal period itself.

I have started to setup and get my Ubuntu and FreeBSD VMs up and working, for future testing and development.

Got selected

Thu, 30 Apr 2026 23:43:01 +0530

Google Summer of Code 2026 results just got announced! I went to the GSoC website and checked the announced projects. I searched my name and……. it wasn’t there. My heart dropped. I didn’t get selected? I went through the whole proposal period wondering where did I go wrong. When I was just spiraling into self doubt, my friend asked me to search for acidicneko; my internet alias and lo behold it was there! I am so happy to be selected. I would like to thank all the people in RTEMS involved for selecting me. I cannot wait to start working on this project.

Fixing bug in existing RPM Packaging backend

Fri, 27 Mar 2026 12:13:01 +0530

On a random evening, I was going through the existing rtems-deployment codebase. Specifically the pkg/rpm.spec.in and pkg/linux.py, to understand the current packging flow. As I was going through the pkg/rpm.spec.in file, I noticed that the package’s architecture type is never actually set.

rpmbuild expects BuildArch variable to be set inside the spec files to know the architecture.

Not only the BuildArch variable was missing but also another variable, arch was being set to noarch (i.e all or architecture agnostic).

Debian Packaging Support

Tue, 03 Mar 2026 12:13:01 +0530

I have been working on adding .deb package support to RTEMS Deployment tool. I have had some initial success doing so.

After carefully studying how .rpm packages were being built, I found the following:

./waf --target=targets-required built .tar packages with compiled binaries and place it in tar/ directory.
./waf rpmspec generated rpmspec files for each of the supported hardwares using pkg/rpm.spec.in and stored them into out/hardware-name directories.
User then manually invoked the command rpmbuild -bb out/required/hardware/hardware-name.spec, which built the .rpm package in out/buildroot directory.

I have tried to mimick the exact same workflow for debian packages.

Baby Steps

Mon, 02 Mar 2026 10:37:01 +0530

Hi everyone! This is Ayush from India. This year I plan on contributing to RTEMS on Issue 82.

I have done the first steps required to contribute to RTEMS. Proof of work attached on discourse.

I am currently studying about the current packaging options and devise a plan to add more packaging options like deb packages, arch linux package, freeBSD packages, etc.

In past I have worked on Linux systems. I have built package managers, linux utilities like rice installers, bash prompt systems, custom kernels from scratch, etc.