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. 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 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 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 || 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 Connected... Page load complete