My very first non-maintainer upload to Debian

Identifying the bug

The bug I am fixing in this package is a bug that I reported myself around February 2020. It was similar to another bug, but sufficiently different so that I took the liberty to create this new bug report. Anyways, fixing one bug should fix the other.

To resume the issue, my problem was that this TFTP server was only listenning to 0.0.0.0 on my dual-stack IPv4/IPv6 system. However, when I tried to download a file from localhost, the ::1 IPv6 address was used on the loopback interface instead of the 127.0.0.1 IPv4 address. Result was that I could not download files from localhost, but could from 127.0.0.1. As today IPv6 is more and more deployed, having this kind of issue is problematic.

The other bug was that the person was using an IPv6-only system (not dual-stack like mine). But the symptoms are similar: since the server binds to 0.0.0.0 IPv4 address only (all interfaces via IPv4), it could not bind on their machine because there was no IPv4 but only IPv6. The solution is either to bind on all IPv6 interfaces with ::0, or to not specify any address to let the server bind on all IPv4 and IPv6 interfaces.

This is the solution that I implemented: remove the hardcoded 0.0.0.0 address everywhere to let a chance to the server to bind on all IPv4 and IPv6 interfaces, instead of IPv4 only.

Doing the change

What we have to do now is to change the default address used to bind when the Debian package is installed.

The original source package can be found on Salsa, Debian’s Gitlab instance. This repository was last updated for the v5.2+20150808-1 release. However, the last source package version at this time was v5.2+20150808-1.1. This means that somebody else than the maintainer uploaded a new version into the archive, without publishing their changes into the git repository.

To verify this assumption, we can have a look at the changelog.Debian.gz file to see who did the last upload and why:

$ zcat /usr/share/doc/tftp-hpa/changelog.Debian.gz | head
tftp-hpa (5.2+20150808-1.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Fix build error with GCC 10 due to multiple definition of `toplevel'
    (Closes: #957875)

 -- Salvatore Bonaccorso <carnil@debian.org>  Thu, 23 Jul 2020 06:53:24 +0200

As suspected, this was a NMU (non-maintainer upload), so it explains why it does not appear in the maintainer’s git tree. It means that we should not clone the git tree to modify the source package, because the git tree is outdated.

Instead, we can simply use the apt source command to download the latest source package:

$ apt source tftp-hpa

To keep track of my changes in a proper way, I took time to fork the maintainer’s repository. Then I created a commit of my changes. For this commit to contain only my changes, I had to backport this previous upload first, because it was not present in the git tree.

Now that all of this is done, the debian branch of my fork on Salsa should match with the latest uploaded source package.

Creating and pushing the package

After the modifications are done and registered as git commits, we now need to prepare the package for final build and upload.

The first step is to create a directory that will contain the sources, but not the .git directory, as dpkg-buildpackage will not be happy about it. For this, I have used the following command in order to have a clean folder:

$ git archive --format tar tftp-hpa-5.2+20150808-1.2 | \
  tar -x -C ~/dev/debian/tftp-hpa-5.2+20150808/

This command will create an image of the git tree at revision tftp-hpa-5.2+20150808-1.2, which is my last commit that I have tagged. The resulting folder is now .git-free and can be used to build and upload the package.

As I am not a Debian Developer nor Maintainer (I think these are the two statuses in the project with push rights), I needed to use the mentors.d.n portal to push my package. Then, someone with higher rights can approve the package and send it for FTP masters to review.

Request for sponsorship

On the mentors.d.n website, oneself can ask for “sponsorship” by setting a flag on their upload. Typically, every Debian contributor that do not have push rights use this platform to ask to someone else to push their work, and sets the flag. I set this flag for my package as well.

But, as I noticed often, things don’t just get done easily in the project. As people are volunteering, they do not have incentives to have a look at your upload (in the case of mentors.d.n) just because a bot sent them an email. This is why after waiting some time (maybe a week or two?) I decided to send a RFS (Request For Sponsorship) email.

The mentors.d.n website proposes you an email template based on your upload, that you can copy-paste and send with a mail client to the correct list. Of course, the template is a template, so I took time to add additional useful information for the person that will have a look at it. I mentioned in the request the link to my fork on Salsa, as well as the two commits that I created for an easier review of what the changes did to the source package.

After this RFS was sent, the package quickly found a sponsor (thanks kilobyte!) and was sent to the FTP masters.

Current status

After the FTP masters their gave approval (as you saw in the beginning of the article), the package made its way into the unstable (also known as sid) version of Debian. After some time and more tests, the package will be automatically moved to testing (also currently known as bullseye).

This is why I am currently using testing distribution on my day-to-day machines: packages are up to date compared to stable, but they are more solid than directly pulling from unstable because of the extra Q&A steps.

To follow the version of a package between the different Debian versions, the tracker can be used. For example, we can see on this page that the package needs to be at least 5 days old before having a chance to go to testing.

We also see that the upstream VCS git repository is not in sync with the uploaded package. This is because the changes of my fork are not in the maintainer’s git repository. I did not find a way to propose my changes back to the maintainer, so it is not clear to me what I could do to fix this issue.

Conclusion

This first successful upload to the Debian archive made me learn valuable lessons. I first reported a bug, and then made a non-maintainer upload to fix the issue in the distribution.

Hopefully I will get more and more comfortable in the Debian ecosystem to not only be a happy user, but also become able to modify it despite not having the contributing rights (yet?).

Or maybe I will install Archlinux back again. Who knows.