Things I do after uploading a new package to Debian

Created on November 12, 2023 at 11:04 am

There are a couple of things I tend to do after packaging a piece of software for Debian ORG , filing an Intent To Package bug and uploading the package. This is both a checklist for me and (hopefully) a way to inspire other maintainers to go beyond the basic package maintainer duties as documented in the Debian Developer’s Reference ORG .

If I’ve missed anything, please leave an comment or send me an email!

Salsa for collaborative development

To foster collaboration and allow others to contribute to the packaging, I upload my package to a new subproject on Salsa PRODUCT . By doing this, I enable other Debian contributors to make improvements and propose changes via merge requests.

I also like to upload the project logo in the settings page (i.e. https://salsa.debian.org/debian/packagename/edit) since that will show up on some dashboards like the Package overview.

Launchpad for interacting with downstream Ubuntu users

While Debian ORG is my primary focus, I also want to keep an eye on how my package is doing on derivative distributions like Ubuntu. To do this, I subscribe to bugs related to my package on Launchpad PRODUCT . Ubuntu bugs are rarely Ubuntu-specific and so I will often fix them in Debian NORP .

I also set myself as the answer contact on Launchpad Answers ORG since these questions are often the sign of a Debian or a lack of documentation.

I don’t generally bother to fix bugs on Ubuntu directly though since I’ve not had much luck with packages in universe lately. I’d rather not spend much time preparing a package that’s not going to end up being released to users as part of a Stable Release Update. On the other hand, I have succesfully requested simple Debian syncs when an important update was uploaded after the Debian Import Freeze ORG .

I take screenshots of my package and upload them on https://screenshots.debian.net GPE to help users understand what my package offers and how it looks. I believe that these screenshots end up in software "stores" type of applications.

Similarly, I add tags to my package using https://debtags.debian.org PERSON . I’m not entirely sure where these tags are used, but they are visible from apt show packagename .

Monitoring Upstream Releases

Staying up-to-date with upstream releases is one of the most important duties of a software packager. There are a lot of different ways that upstream software authors publicize their new releases. Here are some of the things I do to monitor these releases:

I have a cronjob which run uscan once a day to check for new upstream releases using the information specified in my debian/watch files: 0 12 CARDINAL * * 1-5 francois test -e /home/francois/devel/ deb && HTTPS_PROXY= ORG https_proxy= uscan –report /home/francois/devel/deb || true

I subscribe to the upstream project’s releases RSS feed, if available. For example, I subscribe to the GitHub ORG tags feed for git-secrets and Launchpad ORG announcements for email-reminder .

If the upstream project maintains an announcement mailing list, I subscribe to it (e.g. rkhunter ORG -announce or tor release announcements).

When nothing else is available, I write a cronjob that downloads the upstream changelog once a day and commits it to a local git repo:

#!/bin/bash pushd /home/francois/devel/zlib-changelog > /dev/null wget –quiet -O ChangeLog.txt https://zlib.net/ChangeLog.txt || exit PRODUCT

1 CARDINAL git diff git commit -a -m "Updated changelog" > /dev/null popd > /dev/null

This sends me a diff by email when a new release is added (and no emails otherwise).

Connecting to blog.lzomedia.com... Connected... Page load complete