[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Report from the Debian Perl Sprint at Barcelona (May 2015)

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.

[sprint wiki]: https://wiki.debian.org/Sprints/2015/DebianPerlSprint
[DAC UPC]: http://www.ac.upc.edu/

Bugs and Uploads


Bugs [tagged][] with:

* user: debian-perl@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-perl@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)


* 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


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:

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


* where to export (and commit?) patches; in master, a separate release
  branch? (question for bremner)
* needs more thoughts, good documentation, ...


* 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


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.


* 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

* [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 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


Outstanding migratations involve team maintained packages were

* 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


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,
* [#677865][] updated, upstream cc'd with the feature request about this

[#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

Attachment: signature.asc
Description: Digital signature

Reply to: