TL;DR: Focused on the OpenSSL 4 migration, opened my first MP, and created an AI skill to automate patches.
Welcome to my first +1 Maintenance shift report! Overall, the week went quite well (no catastrophes!) and I learned a few interesting things. This was also my first time doing non-security package maintenance and fixing non-Rust packages.
Before my shift started, I shadowed @ravi-sharma (who is leading the OpenSSL 4 transition effort) and @richard-scott-mcnew (my manager). This was key to understand what would be expected from me during my shift, and how to actually go about fixing those packages. I thank both for the opportunity, and recommend that everyone doing a shift for the first time shadow someone too - it’s incredibly helpful.
During my week, I was joined by @rinconjr who had also never done +1 Maintenance and wanted to shadow someone - we did some nice work together (can we call it a +2 Maintenance shift?). We were both mentored by @maxgmr, who reviewed the work I had done so far and walked me through the process of opening my first Merge Proposal - thank you so much, Max!
Work-needed items
- There are still many packages to be fixed for the OpenSSL 4 migration. Read the ubuntu-devel mailing list OpenSSL 4.0 email for more info, and feel free to reach out to me if you want to contribute and don’t know where to start.
- The work items recommended by people in previous +1 Maintenance shifts.
- I developed a patch for
pypy3to make it compatible with OpenSSL 4.0 (and it builds), but I still need to test it and build in a PPA before submitting an MP or forwarding the patch to Debian and upstream. - I developed a patch for
yubico-piv-toolto make it compatible with OpenSSL 4.0 (and it builds), but I still need to test it and build in a PPA before submitting an MP or forwarding the patch to Debian and upstream. The patch is almost identical to an upstream PR, so I need to decide whether both are equivalent, and if we should act or just wait until it gets merged and propagated into Debian and Ubuntu. - I started working on
golang-github-mendersoftware-mender-artifact, but didn’t get very far and would be happy to hand it over.
Sponsorship Needed
virtuoso-opensourcefix for OpenSSL 4.0 compatibility- (Debian)
virtuoso-opensourcefix for OpenSSL 4.0 compatibility
Detailed Log
I found work items by picking packages that were not yet assigned to anyone in @ravi-sharma’s tracking spreadsheet for the OpenSSL 4 migration effort. I selected packages by their popularity count, as this means that working on them would have the biggest impact.
pypy3
This was admittedly not a good choice for a first package because it takes a long time to build and is not easy to test.
I noticed that there was already a pull request upstream addressing the OpenSSL 4 compatibility, but the patch couldn’t be directly applied to the source code available on Launchpad. I think that the reason for this is that the PR targets the main branch, but the package uses a different branch as its source (but I might be wrong).
I then proceeded to develop a patch that allows me to build pypy3 locally against both OpenSSL 3 and 4, and published the patch to a PPA where the package also built successfully. I reached out to pypy3’s maintainer on Debian and he mentioned that we could apply my patch to the Debian package as long as I’m able to successfully test (not only build) it.
I still need to do this testing before opening an MP for Ubuntu and forwarding the patch to Debian.
virtuoso-opensource
I noticed that there were no patches in development upstream, so I worked on this one from scratch. Developing a patch for OpenSSL 4 compatibility is not too hard after you familiarize yourself with the official migration guide. All I needed to do was to try to build the package against OpenSSL4 (available in the PPAs by the openssl-testing group), see it fail, read the error messages, and fix them one by one.
The only issue I had here is that virtuoso-opensource depends on libnet-ssleay-perl. Even though libnet-ssleay-perl had already been patched for OpenSSL 4 compatibility in the openssl4-fixes PPA, a new version in the Archive was shadowing it. It took me a good couple of hours to figure this out (sorry I’m a newbie!), but the fix was simple: I asked Ravi to source-copy the new package into the PPA to get it rebuilt against OpenSSL 4. After this was done, my patch just worked.
I opened a Merge Proposal to fix this on Ubuntu, and also forwarded the patch to Debian and to upstream. This was my first time doing all of this 
yubico-piv-tool
For this package, I took a different route. I noticed that there was already a PR upstream fixing the OpenSSL 4 compatibility, so I took the opportunity to develop an AI agent skill to automate the migration work and compare it with what was done upstream.
The result was almost exactly the same! Feel free to reach out if you’d like to try out this skill with your favorite coding agent.
I still need to decide if I’ll open an MP and submit the patch to Debian, or if we should just wait until the PR gets merged upstream and the changes propagate to Debian and to Ubuntu.
golang-github-mendersoftware-mender-artifact
I decided to work on this because it’s written in Go, but I didn’t really have much time to understand the package and fix it for OpenSSL 4 compatibility.
I did get an initial build error caused by a dependency not being rebuilt against OpenSSL 4. I then source-copied this dependency (golang-defaults) to a PPA and got this specific error fixed.
Closing
Whew, that was a big write-up! Thanks for reading 
