This project contains some short, self-contained, relatively simple tasks to enhance the quality of Debian with the intention to integrate newcomers into the project by doing valuable contributions in a short time frame. The effort should be guided/leaded by experienced Debian Developers who show their workflow to others.

• Bug of the day
  • Checklist when tackling a bug
  • Some hints
    • Importing into Salsa
      • Creating a Git repository if you can't find it on Salsa yet
      • Collaborative Maintenance: "Debian" group
      • Getting more information about a package
      • Switch on Salsa CI
    • Hints about ITS bugs for the Package Salvaging procedure
    • LowThresholdNmu and LowThresholdAdoption
  • Communication
• Autopkgtest of the day

Bug of the day

There is a daily cron job which picks 5 random bugs from UDD featuring the following criteria

• No VCS or obviously outdated VCS (alioth, svn, cvs)
• Standards-Version < 4
• not uploaded last 5 years by the maintainer of the package

The result of this query is put on the Bug of the day web page. An experienced DD should do some educated pick out of these five bugs which might be a target which is sensible for newcomers.

If the package does not fit in any team it should be imported into the Salvage Team to get the bug fixed there first. The whole procedure should follow the Package Salvaging procedure described in Developers Reference. See hints about filing ITS bugs below.

Checklist when tackling a bug

1. Go to Salsa and seek for the package name. In some cases the packaging was just migrated but it was not uploaded with Vcs-fields set. Note: The Salsa search does not seek in private developer repositories.
2. Look for other bugs of the package you want to fix by having a look at https://bugs.debian.org/src:PACKAGENAME
3. Check package tracker for more information at https://tracker.debian.org/PACKAGENAME
4. Check the Homepage of the package. Is debian/control pointing to the correct homepage or did it moved
5. Check the debian/watch file whether it reports the latest upstream version correctly
6. Does debian/source/format exist and does it contain 3.0 (quilt)
7. Is debian/rules using dh or possibly cdbs / long debhelper. It might be worth migrating to dh in case we will salvage the package.
8. Is debian/copyright in DEP-5 format? It might be worth migrating to DEP-5 in case we will salvage the package.
9. What happens if you run routine-update -f on the packaging? Its migrating the package to latest packaging standards. It might create some noise since latest packaging standards for instance mean that the upstream testsuite is run in dh_auto_test and dh_mising defaults to failmissing. These are things you might like to deal with when salvaging the package.

Some hints

Importing into Salsa

Creating a Git repository if you can't find it on Salsa yet

If you want to create a Git repository from a package that is not maintained in Git yet, you can do

gbp import-dscs --debsnap --create-missing-branches --pristine-tar PACKAGENAME

Note: There might be some problem importing a package if the maintainer provides some debian/gbp.conf with conflicting values. You can use the --ignore-repo-config in these cases but make sure you verify the branch names afterwards.

In case this procedure might fail you can also try:

dgit clone PACKAGENAME

Please note that in this case the repository layout is patches applied and you need to revert applying the patches to create the repository layout which is commonly used.

If the package in question was available on Alioth you can find old repositories at https://alioth-archive.debian.org/.

• The Git repositories you can find here are bare repositories. After untaring the archive you need to do git clone PKG.git PKG )
• If the archived repository is SVN you can use the svn2git-template

One you created the Git repository on Salsa please enable Salsa CI.

Please keep in mind that the Git repository from the alioth archive or existing archives on salsa that were migrated by someone else before might be outdated and are not featuring latest NMUs. If you need to import changes from NMUs the gbp import-dscs command above might be your friend (called from inside the Git archive).

See also:

• Petter Reinholdtsen's blog post about migrating packages to Salsa
• Package pkg-perl-tools dpt-takeover(1)

Collaborative Maintenance: "Debian" group

As its stated in the Salsa documentation the Debian team can be used to take over packages formerly maintained in collab-maint.

Getting more information about a package

For sure its recommended to check the Debian Package Tracker. There is an interesting command line alternative which is used by the Debian Perl Team inside the pkg-perl-tools package. You might like to try

dpt prepare

inside a packaging tree.

Switch on Salsa CI

salsa update_projects $NAMESPACE/$PROJECT \                                                                                                           
  --jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline

Hints about ITS bugs for the Package Salvaging procedure

There is a template for filing an ITS bug which is recommended for filing ITS bugs.

Uploads should be done via

dput --delayed=10 PACKAGE*_source.changes

and you can check the progress of the uploaded package in the Deferred uploads queue In case you might have done an unwanted upload to this queue you can remove it via

dcut cancel -f PACKAGE*_source.changes

LowThresholdNmu and LowThresholdAdoption

It might be interesting to check whether the maintainer of some package is on LowThresholdNmu or LowThresholdAdoption list.

Communication

Just join the Matrix channel bugs amongst DDs and newcomers.

There is also Package Salvaging Team on Tracker which you can reach via email.

Autopkgtest of the day

The idea is to write autopkgtests for high popcon packages (see for instance bug #1068576 of tar)