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 tagged with:
A total of 53 bugs were filed/worked on. These include:
A total of 31 accepted uploads were made at the sprint.
(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:
git-debcherry-784159
git-debcherry script from gitpkg_0.26, enhanced to support git notes with the patch from #784159
quilt2debcherry
script to convert quilt patches in a package into a commit series with the patch metadata stored as git notes
run-debcherry
script to automate exporting patches from the commit series and notes, by first running git-debcherry itself and then mangling the results aiming for stable output with the two scripts below
notes2dep3
script to convert git format-patch output of commits with patch metadata inside git notes into a DEP3-compatible format
rename-patches
script to rename patches as created by git format-patch into names specified by the Patch-Name header stored in the git notes
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:
[buildpackage]
prebuild = GIT_DIR=$GBP_GIT_DIR git-debcherry -o debian/patches upstreamIssues:
Actions:
Dominic demonstrated git-dpm (as used in src:perl). The main differences between git-dpm and git-debcherry are:
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.
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).
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.
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.
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.
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-*
Actions:
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.
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:
A plan for producing IRC notifications on autopkgtest regressions was discussed:
previous_status=='pass') via KGBscript/kgb-ci-report in KGB. It is available so that e.g. other teams can re-use it.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.
The status of ci.debian.org autopkgtest whitelisting was reviewed. Notes from this work:
Outstanding migratations involve team maintained packages were reviewed:
Gstreamer 0.10 -> 1.0 (#785856):
would need a new libgstreamer1-perl package; few people care, so have libgstreamer-perl removed and package libgstreamer1-perl later if somebody needs it.
OGRE (#732725):
low popcon (max 26, now 22); no reverse deps (just one Recommends and one Enhances); the conclusion is that this is not really needed and seems dead upstream; let go.
libois-perl possibly doesn't make much sense without libogre-perl.
Work was done on various recurring tasks done by the team:
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).
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:
Depends: perlapi-* can be demoted to RecommendsPOD_MAN_DATENiko commented on #782879 and #782878; waiting for input from debhelper maintainers.