My Journey with QubesBuilderV2: From Installation to Contribution. My First Open source Contribution Experience

I constantly seek opportunities to dive deep into complex projects, challenging myself to learn new things. My recent experience with QubesBuilderV2, a tool for building Qubes OS components, was one such challenge—a whirlwind of learning, adaptation, and perseverance. Here’s how my journey unfolded, from setting up QubesBuilderV2 in my Debian environment to pushing a meaningful pull request that addressed key reproducibility issues.

Setting Up QubesBuilderV2 on Debian

The adventure started when I was tasked with contributing to the Qubes OS project by working on reproducibility issues in its core-admin-client component. I first had to install QubesBuilderV2, a tool used to build Qubes OS components. Since I was working in a Debian environment, the installation process required careful attention to dependencies and build configurations. I remember being completely new to QubesBuilder, but after going through documentation and following detailed instructions, I successfully installed the tool and got it running on my system.

This initial step helped me grasp the basics of how QubesBuilderV2 worked. It was my first dive into dealing with such a build system, but soon, I’d be neck-deep in much more complex tasks.

Moving from Debian to Fedora

After setting things up on Debian, I had to shift to Fedora, which Qubes OS primarily uses. This meant adapting to a new environment and ensuring that my builds were compatible with Fedora’s architecture. I ran into issues, including problems with dependencies and differences in how Fedora handles package management.

Setting up Fedora and resolving compatibility issues taught me to work with .rpm packages, handle different build environments, and use Fedora’s package management tools like dnf. Once I had Fedora set up correctly, I was able to run the QubesBuilderV2 tool more smoothly.

Tackling Reproducibility Issues in Core-Admin-Client

The main challenge of my contribution was addressing reproducibility issues in the core-admin-client component. For Qubes OS, ensuring that builds are reproducible—where two builds produce identical results—is crucial for security and transparency. My task was to identify and fix areas where timestamps and environment-specific data were affecting reproducibility.

Resetting $SOURCE_DATE_EPOCH A key step was to normalize timestamps by resetting the $SOURCE_DATE_EPOCH variable, which is used to standardize build dates. By modifying several build scripts, I was able to ensure that this variable was used consistently across the build process. This step involved:

Locating and replacing direct calls to date commands in the build scripts.

Ensuring that environment variables like $SOURCE_DATE_EPOCH were utilized instead, so that the builds would always use a consistent timestamp.

Dealing with CI Pipeline Failures

As I worked on fixing reproducibility, I encountered numerous CI pipeline failures. One issue was related to ShellCheck, which flagged errors in the shell scripts I had modified. I learned how to address shell scripting best practices, resolving these errors and making my code pass all ShellCheck tests.

Another major hurdle was GPG key signing. My pull request initially failed because I didn’t have the correct GPG setup, leading to errors in the code-signing checks. It took several attempts, generating new keys, and troubleshooting GPG errors to finally get my code properly signed and accepted by the CI pipeline.

Working with Mentors and Opening My Pull Request

Throughout the process, I worked closely with mentors from the Qubes OS team. Their feedback was invaluable in helping me understand how to better structure my changes, and they provided guidance on ensuring my modifications were aligned with the project’s overall goals. The iterative process of submitting changes, getting feedback, refining the code, and resubmitting was a key part of the learning journey.

Finally, after several iterations, all the tests passed, and I opened my pull request. The pull request addressed the following:

Ensuring reproducibility in the core-admin-client component by normalizing timestamps. Fixing environment-specific values to ensure identical builds across different systems. Passing all CI pipeline checks, including ShellCheck, code signing, and reproducibility tests.

Conclusion

Contributing to an open-source project like Qubes OS has been a rewarding experience. It taught me not only technical skills—working with build systems, resolving reproducibility issues, and mastering CI pipelines—but also the value of perseverance and collaboration. The feedback from my mentors helped shape my contribution, and the satisfaction of seeing my pull request pass all checks and get merged into the project was a defining moment.

This journey was more than just about fixing code. It was about learning, adapting, and growing as a cloud engineer and open-source contributor.