Debian Perl Sprint 2015


7 members of the Debian Perl Group met in Barcelona over the weekend from May 22 to May 24 2015 to kick off the development around perl for Stretch and to work on QA tasks across our 3000+ packages. The preparation details can be found on the sprint wiki.

The participants would like to thank the Computer Architecture Dept. of the Universitat Polit├Ęcnica de Catalunya (DAC UPC) for hosting us, and all donors to the Debian project who helped to cover a large part of our expenses.

Bugs and Uploads


Bugs tagged with:

A total of 53 bugs were filed/worked on. These include:

A total of 31 accepted uploads were made at the sprint.

Upstream Bug Reports Filed


Git and Patches

(Followup to pkg-perl BoF at DebConf14.)

The group discussed the current practice for patch management, and possible alternatives.

Currently we are storing patches in git with quilt, with the actual source in git unpatched.

This has downsides like having to remember quilt push -a when running debian/rules build manually from a git checkout. Also, git would be a better tool at rebasing/merging the patches to new upstream releases, but currently this needs to be done manually with quilt.

The upside is that it's very simple and straightforward; we need to consider also less deeply involved team members, and requiring complicated workflows can drive them away.


One tool: git-debcherry (David Bremner), shipped in the gitpkg package.

Missing piece: preserving patch meta-information (DEP3).

git-notes is still a bit rough UI-wise:

Niko presented a demo of the patched git-debcherry and proof of concept conversion scripts:

Conclusions wrt. git-debcherry: it needs a separate export step to keep debian/patches synced with the actual git commits, and it's not clear how that should fit in a standard workflow. Possibly this is comparable to debian/changelog handling with tools like gbp-dch, and it should be the responsibility of everybody who works on a package to leave debian/patches in a sane state afterwards.

Storing patch metadata in git notes looks very interesting and may have broader applications than just with git-debcherry.

There's still not much experience in how well git-debcherry works in the long run.

Integration into git-buildpackage (~/.gbp.conf) by gregor:

prebuild = GIT_DIR=$GBP_GIT_DIR git-debcherry -o debian/patches upstream




Dominic demonstrated git-dpm (as used in src:perl). The main differences between git-dpm and git-debcherry are:

Debian Perl Tools

dpt (short for Debian Perl Tools) is a wrapper around a couple of helper scripts useful for pkg-perl, and packaged in pkg-perl-tools.

Importing Upstream Git History

The group discussed whether upstream git history should be imported into pkg-perl git repositories.

Some of us use dpt import-orig, dpt upstream-repo and dpt debian-upstream to import upstream's Git history into our upstream branch, when importing a new upstream release.

It is recommended to do that as well, especially for packages where it has already been done in the past (to avoid messy history on the upstream Git branch).

Pushing Upstream Git Tags to Alioth

Related to the above, the group discussed whether upstream tags should be pushed. The current practice is to not do so, but it's easy to accidentally do if git push --tags is used. However, dpt push does not do it by default.

No change to the status quo is needed.

Maintaining debian/upstream/metadata

The group reviewed current practice.

dpt upstream-metadata creates this file. It is usually only run once, further changes must be done manually. We have to keep an eye on such updates when importing new upstream releases.

Documenting More dpt Commands

It was noted that the team's documentation (git.html) needs to be checked for new dpt commands (as discussed above). Damyan made small corrections here and there.

Documentation Review

src:perl Plans and Packaging Changes for Stretch

Niko presented plans for reorganizing src:perl packaging to achieve co-installability of libperl5.xx (including the standard library) for multiple versions and architectures, and asked for feedback. The ensuing discussion was good and constructive.

Preference for Option S (least packages, with the standard library bundled into libperl5.xx), with perl-modules-*


Investigating Build Failures for perl on buildds

Bug #785557 seems to relate to the times(2) system call returning zero for user CPU time. Some investigation work on this bug was done.

Upcoming perl 5.22 Release and Cleanup

Bugs on packages build-depending on perl5 (will be gone in 5.22) were filed by Dominic:

A test repository containing packages rebuilt again perl 5.22 was prepared:

CI and KGB

A plan for producing IRC notifications on autopkgtest regressions was discussed:

Newly autopkgtest-able Packages

Some of those were already on the whitelist, some others were fixed so that they can now be autopkgtest'ed.

Several other packages got fixed to make their autopkgtests work.

Whitelist Updates

The status of autopkgtest whitelisting was reviewed. Notes from this work:


Outstanding migratations involve team maintained packages were reviewed:

Recurring Tasks

Work was done on various recurring tasks done by the team:

Bugs in Launchpad

There is the pkg-perl-maintainers launchpad team that people can join and then get mails (and the launchpad account for the Debian Perl Group). The status of this arrangement was reviewed.

For the valid-also-for-Debian reports, forwarding to the BTS sounds like the way to go; and/or close them with an upload to Debian (with the LP: #nn syntax).

Handling debian/changelog

After some discussion we discovered that the sensible way is already described in our documentation as a commit policy:

The current group policy states that whenever you stop working on a package, the changelog should be updated and pushed.


The problem mentioned in #677865 was discussed; conclusions:

Reproducibility and POD_MAN_DATE

Niko commented on #782879 and #782878; waiting for input from debhelper maintainers.