Debian Perl Sprint 2015 ======================= Introduction ------------
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. [sprint wiki]: https://wiki.debian.org/Sprints/2015/DebianPerlSprint [DAC UPC]: http://www.ac.upc.edu/ Bugs and Uploads ================ Overview -------- Bugs [tagged][] with: * user: debian-p...@lists.debian.org * usertags: bcn2015 A total of 53 bugs were filed/worked on. These include: * newly filed: 28 bugs - incl. 6 fixed during the sprint - incl. 8 RM bugs to drop RC-buggy unmaintained upstream software - incl. 6 bugs on DUCK after running it over all group's packages * resolved: 13 bugs - incl. 6 bugs filed during the sprint A total of 31 accepted uploads were made at the sprint. [tagged]: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=bcn2015;users=debian-p...@lists.debian.org Upstream Bug Reports Filed -------------------------- * [Config::Model::TkUi](https://github.com/dod38fr/config-model-tk-ui/issues/1) (already fixed) * [Gtk3](https://mail.gnome.org/archives/gtk-perl-list/2015-May/msg00020.html) FTBFS Bugs ---------- * 7 RM bugs filed for packages with FTBFS bugs since Perl 5.18 (i.e. for 2 years). * [OpenTasks wiki page][opentasks] updated [opentasks]: https://wiki.debian.org/Teams/DebianPerlGroup/OpenTasks Git and Patches =============== (Followup to [pkg-perl BoF at DebConf14][bof2014].) 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. [bof2014]: https://lists.debian.org/debian-perl/2014/08/msg00044.html git-debcherry ------------- One tool: git-debcherry (David Bremner), shipped in the gitpkg package. Missing piece: preserving patch meta-information (DEP3). * the commits changing upstream code don't get rebased in this workflow, but the metadata is volatile * git notes solve this neatly: the metadata is attached to commits but can be modified later git-notes is still a bit rough UI-wise: * merging is not straightforward if several people work on the same notes at the same time (not expected to be a real problem) * needs manual pushing/fetching, could probably be integrated into team-specific tools like dpt-push 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 upstream ``` Issues: * where to export (and commit?) patches; in master, a separate release branch? (question for bremner) * needs more thoughts, good documentation, ... Actions: * David to review git-debcherry patch. * Looking at it again at the Rolling Sprint (DebCamp). [demo]: http://anonscm.debian.org/cgit/pkg-perl/scripts.git/tree/debcherry [#784159]: https://bugs.debian.org/784159 git-dpm ------- Dominic demonstrated git-dpm (as used in src:perl). The main differences between git-dpm and git-debcherry are: * git-dpm has exported and applied debian/patches in master; * git-debcherry needs export (so not always buildable from the git master branch). 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. [git.html]: http://pkg-perl.alioth.debian.org/git.html Documentation Review ==================== * It was noted that many of the HTML docs on pkg-perl.alioth.debian.org should be reviewed. * All ancient ones (everything not touched since 2011) were removed. * The autopkgtest docs were improved, with some notes and a new section about setting up schroot by Alex. 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-*` * Option S most simple, but with some file duplication * Option L most perfect (no duplication, etc.) but quite complex and maybe hard to maintain properly (lots of break/conflicts/replaces, etc, possible pre-depends fragility) * The perl package maintainers (Niko and Dominic) prefer Option S due to its simplicity. Actions: * Niko and Dominic to move forward with Option S (with perl-modules-5.xx) with Perl 5.22 * upload to experimental (DONE), aimed for sid in a couple of months * normal rebuild testing (already started), plus possibly re-running autopkgtest checks * announce on -devel (TBD) * change Perl policy where needed + [draft][] by Dominic (to file bug once upload to experimental is done) [plans]: http://people.debian.org/~ntyni/perl/libperl/ [draft]: http://lists.alioth.debian.org/pipermail/perl-maintainers/2015-May/004889.html 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. [#785557]: https://bugs.debian.org/785557 Upcoming perl 5.22 Release and Cleanup ====================================== Bugs on packages build-depending on perl5 (will be gone in 5.22) were filed by Dominic: * dh-lisp * fte (DONE via QA upload) * htag * libconvert-units-perl (likely can be put under the pkg-perl umbrella as eloy was fine with similar cases) * liblingua-en-words2nums-perl (DONE) * libmasonx-request-withapachesession-perl (DONE) * librtf-document-perl * mimefilter A test repository containing packages rebuilt again perl 5.22 was prepared: * [https://people.debian.org/~dom/perl/test/perl-5.22.0/setup.sh](https://people.debian.org/~dom/perl/test/perl-5.22.0/setup.sh) * [https://people.debian.org/~dom/perl/test/perl-5.22.0/setup.sh.asc](https://people.debian.org/~dom/perl/test/perl-5.22.0/setup.sh.asc) ci.debian.net ============= CI and KGB ---------- A plan for producing IRC notifications on autopkgtest regressions was discussed: * Parse [CI JSON] every day and report any new failures (`previous_status=='pass'`) via KGB * Only for pkg-perl packages (list retrieved via UDD) * adt-kgb tool idea appeared, reusable by other teams. Then Damyan wrote `script/kgb-ci-report` in KGB. It is available so that e.g. other teams can re-use it. [CI JSON]: http://ci.debian.net/data/status/unstable/amd64/packages.json Newly autopkgtest-able Packages ------------------------------- Some of those were already on the whitelist, some others were fixed so that they can now be autopkgtest'ed. * libb-hooks-op-annotation-perl * libcairo-gobject-perl * libcairo-perl * libclutter-perl * libdevice-cdio-perl * libgtk3-perl * libmoox-handlesvia-perl * libmoox-late-perl * libmoox-types-mooselike-perl * libnet-dbus-perl * libpango-perl * libparse-debianchangelog-perl Several other packages got fixed to make their autopkgtests work. Whitelist Updates ----------------- The status of ci.debian.org autopkgtest whitelisting was reviewed. Notes from this work: * ci.debian.net has a whitelist for perl packages which succeeded on initial manual run. * Perl packages are tested via autopkgtest-pkg-perl even if they don't have a *Testsuite* header. * [Cleanup][] of the ci.debian.net whitelist. * Test run results of [non-whitelisted][] packages. * Updated autopkgtest.pod with the results plus a list of [work needing][] packages. [Cleanup]: http://anonscm.debian.org/cgit/collab-maint/debian-ci-config.git/commit/?id=b27313668c16bc77f3d11c027c4fb5fe902c772a [non-whitelisted]: http://anonscm.debian.org/cgit/collab-maint/debian-ci-config.git/commit/?id=1421bfbcd1b62e0125bf323cdb33771734c9679a [work needing]: http://anonscm.debian.org/cgit/pkg-perl/website.git/commit/?id=07a1031986e96974bb55f4d216f1476c9832bc43 Migrations ========== 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. [#785856]: https://bugs.debian.org/785856 [#732725]: https://bugs.debian.org/732725 Recurring Tasks =============== Work was done on various recurring tasks done by the team: * [Running DUCK][] over all our packages by Axel: + 6 bug reports filed against duck due to false positives. Already positive feedback from duck's maintainer. + Axel managed to go through all non-e-mail issues up to *libf* during the sprint and travelling back, continuing afterwards. Currently [still open][] issue. * gregor (re)subscribed pkg-perl launchpad team to all our packages [Running DUCK]: https://people.debian.org/~abe/pkg-perl-duck-2015-05-23.txt [still open]: https://people.debian.org/~abe/pkg-perl-duck-2015-05-23.updated.txt 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). [launchpad team]: https://launchpad.net/~pkg-perl-maintainers [launchpad account]: https://launchpad.net/~pkg-perl-maintainers-lists-alioth 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. [commit policy]: https://pkg-perl.alioth.debian.org/git.html#commit_policy libfile-fcntllock-perl ====================== The problem mentioned in [#677865] was discussed; conclusions: * File::FcntlLock (upstream?) needs to fall back to ::Pure if ::XS is not available * the Debian package needs to install ::Pure into a non-version specific path as above * `Depends: perlapi-*` can be demoted to Recommends * dpkg-dev can Depend on libfile-fcntllock-perl * newer versions of perl may want to Break older versions of libfile-fcntllock-perl, but what about the varying binNMU suffixes, etc.? * [#677865][] updated, upstream cc'd with the feature request about this fallback [#677865]: https://bugs.debian.org/677865 Reproducibility and `POD_MAN_DATE` ================================== Niko commented on [#782879][] and [#782878][]; waiting for input from debhelper maintainers. [#782879]: https://bugs.debian.org/782879 [#782878]: https://bugs.debian.org/782878
signature.asc
Description: Digital signature
