Things I do after uploading a new package to Debian
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. 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 Debianis 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 . Ubuntu bugs are rarely Ubuntu-specific and so I will often fix them in Debian .
I also set myself as the answer contact on Launchpad Answerssince 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.
I take screenshots of my package and upload them on https://screenshots.debian.netto 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. 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* * 1-5 francois test -e /home/francois/devel/ deb && HTTPS_PROXY= 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 GitHubtags feed for git-secrets and Launchpad announcements for email-reminder .
If the upstream project maintains an announcement mailing list, I subscribe to it (e.g. rkhunter-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
1git 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).