See https://wiki.debian.org/Sprints/2020/DebianPerlSprint


Main room:
- https://meetings.opusvl.com/DebianPerlSprintMay2020

Breakout rooms, for smaller discussions:
- https://meetings.opusvl.com/DebianPerlSprintMay2020BreakOut1
- https://meetings.opusvl.com/DebianPerlSprintMay2020BreakOut2

alternative: https://jitsi.debian.social/DebianPerlSprintMay2020

usertag XXX

https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=XXX&user=debian-perl%40lists.debian.org
or
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=XXX;users=debian-perl@lists.debian.org

bts user debian-perl@lists.debian.org . usertag nnnnnn + XXX

LOG OF ACTIVITY
===============

Sunday
------

### Packages removals

Dashboards:

 - https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=rm-candidate&user=debian-perl%40lists.debian.org
 - https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libparse-debian-changelog-perl-removal&user=debian-perl%40lists.debian.org
 - https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=gtk2-removal&user=debian-perl%40lists.debian.org
 - https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=any-moose&user=debian-perl%40lists.debian.org

Progress:

 - libparse-debianchangelog-perl had 3 remaining blockers:
    - [x] license-reconcile: removed today!
    - [x] customdeb: maintainer already agreed it can be removed ⇒ nothing to do
    - [ ] aptitude (#934135): nudged maintainers by testing Guillem's patch

 - libpoe-loop-event-perl: nudged upstream ⇒ remove after June 8 if no reply

 - liblog-dispatch-perl-perl: believe or not, I've convinced myself
   that we should _not_ remove this package; opinions welcome
   on #935868 --intrigeri

 - libclass-forward-perl: I propose we remove it (#935867) --intrigeri

 - Any::Moose

   Meta: I doubt we can/should remove Any::Moose in time for Bullseye,
   and that's OK. I'm not aiming for that. Rather, I'm taking
   this as an opportunity to detect modules that are in a shape
   that suggests to me the cost/benefit of keeping them around
   is not worth it (e.g. there are better alternatives
   + this one is inactive upstream, so both
   our users and us can easily end up in a bad place in the future
   if they pick the "wrong" one). --intrigeri

    - already tracked reverse-deps:
    
      - libterm-editoredit-perl: proposed removing after upgrading
        pinto (#845807)
      - libconfig-jfdi-perl: proposed removing it together with
        libmojomojo-perl (#845772)
      - libtest-cukes-perl: forwarded upstream, proposed removal
        in 3 months (#845808)
      - libtext-clip-perl: proposed removal once libterm-editoredit-perl
        is gone (#845809)
      - libwww-nicovideo-download-perl: forwarded upstream, proposed removal
        in 3 months (#845811)
      - libdata-amf-perl: proposed to remove together with
        get-flash-videos (#845812, #960838)
      - libnet-trac-perl: removing feels a bit extreme?
      - alice: user-facing app, low popcon but apparently
        some folks still use it; I guess it fits a niche use case
        → keep for now?

      ACTION: intrigeri points the rest of the team to the removal
      proposals he has strong(er) doubts about.
      #845772

    - new reverse-deps:

      - libbarcode-datamatrix-png-perl: fixed, uploaded, sent patches upstream
      - libmethod-signatures-perl: filed #960854 with pointers to upstream
      - libmousex-foreign-perl: filed #960855, nudged upstream
      - libmousex-nativetraits-perl: filed #960857, nudged upstream
      - libmousex-types-perl: filed #960858, nudged upstream
      - barnowl (not team-maintained): build-dep is actually unused,
        filed #960861 with a proposed trivial fix
      - libapp-perlrdf-command-query-perl: removed from testing 2.5 years ago,
        due to perlrdf being removed → filed #960864

### Perl 5.31:

  - review and classify test rebuild logs, analyze issues
  - uploaded pdl with libpod-parser-perl dependencies added
  - filed https://github.com/Perl/perl5/pull/17789 for Configure regeneration issues
  - filed https://salsa.debian.org/debian/po4a/-/merge_requests/2 for libpod-parser-perl dependencies
  - filed #960863 for a perl-tk new upstream release

### Hardening

- following yesterday's discussion: change packages from hardening=+bindnow
  to hardening=+all in git

### Pod::Parser removal

- start to upload packages with libpod-parser-perl added

### MUT (Multi Upstream Tarball) and libwww-search-perl

- updated d/rules to install components into binary package
  - it's not the cleanest and could be simplified with make/shell vars
  - need to tune some paths to components in d/rules overrides
- patching required for NO_NETWORK
- reviewed and tested all current components locally
  - https://lists.debian.org/debian-perl/2020/05/msg00021.html
- considering including WWW::Search::PubMed

### Sunday's video meeting

 - Alien::* provides ways to express dependencies on (mostly C) non-Perl
   libraries. Alien::* either downloads the source of that external
   library & builds it, or uses the system-wide library.
   One can set this install type via an environment variable
   or a config file.

   More and more other packages build-depend on Alien::*.

   Should we package this? We would need to ensure we set install type
   to "system", at least for official package builds. Where we would
   do that?

    - Patch Alien::* to set the defaults
      Cons: users who want to use Alien::* in the "download source
      + build" way have to opt-in for that. A big deal?
      Rebuttal: target audience is very technical, we could mention
      this divergence from upstream defaults in the package description,
      and/or README.Debian, and/or by printing a warning.
    - Set the environment variable during package builds: unsolved
      problem so far.

   What does Policy say about downloading source code at runtime?
   Possible irrelevant since Alien::* is only used at build time.

   And what about folks who would install Alien::* and want to use
   it in the "download source + build" way?
   Can we detect that we're running in the context of a Debian
   package build? Apparently not, and even if it was possible,
   the would violate the principle of least surprise.

   

Saturday
--------

### New upstream releases

 - libtype-tiny-xs-perl
 - libtext-glob-perl
 - libexporter-tiny-perl

### dh-sequence-<foo>

instead of --with <foo>

#### Providers

- cme Provides: dh-sequence-cme-upgrade (--with cme_upgrade)
- libdbi-perl Provides: dh-sequence-perl-dbi (--with perl_dbi)
- libimager-perl Provides: dh-sequence-perl-imager (--with perl_imager)
- perl-openssl-defaults Provides: dh-sequence-perl-openssl (--with perl_openssl)

all re-uploaded with improved documentation
👏 :)

#### Consumers

(numbers: packages maintained by us)

- cme_upgrade: 0
- perl_dbi: 8
libdbd-firebird-perl
libdbd-mariadb-perl
libdbd-mysql-perl
libdbd-odbc-perl
libdbd-oracle-perl
libdbd-pg-perl
libdbd-sqlite2-perl
libdbd-sqlite3-perl
- perl_imager: 0
- perl_openssl: 9
libcrypt-openssl-bignum-perl
libcrypt-openssl-dsa-perl
libcrypt-openssl-pkcs10-perl
libcrypt-openssl-pkcs12-perl
libcrypt-openssl-rsa-perl
libcrypt-openssl-x509-perl
libcrypt-smime-perl
libcrypt-ssleay-perl
libnet-ssleay-perl

all updated in git

### debhelper 13

- sets HOME and some XDG_* environment variables
  → works, so we can remove the BUILDHOME dance in d/rules when upgrading to 13
  Q: we still need to set HOME in debian/tests/pkg-perl/smoke-env for autopkgtests,
     typically to $AUTOPKGTEST_TMP or $TDIR; can we do this in autopkgtest's 
     smoke test itself?
  FWIW, /usr/share/doc/autopkgtest/README.package-tests.html reads
  "Tests can expect that the <tt class="docutils literal">$HOME</tt>
  environment variable to be set to a directory that
  exists and is writeable by the user running the test"

- override_dh_auto_test (and others) skip the whole target, so no need for
  ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
  	<some command from a package with '<!nocheck>'>
  	dh_auto_test
  fi
  any more
  → works, we can remove the check when upgrading to 13
  → done for all packages in git

- execute_before_X and execute_after_X instead of override_foo: something; foo; something
  (not new in dh13)
  → works, probably too much for changing all packages in git at once

- variable substitution in helper files, for dh_install
  ${var}; DEB_HOST_*, DEB_BUILD_*, DEB_TARGET_*; env:NAME; etc.
  → practical use for us?

### Misc

- fix circular build dependency between libobject-pad-perl and libfuture-asyncawait-perl
- update virtual packages in libconfig-model-dpkg-perl, add debhelper sequences
- packaged libpod-parser-perl (removed from perl core in 5.31.x)

### Website

- policy.pod: added example in embedded inc section
- make the CI job fail if the pod has errors
- 18:46 < intrigeri> our website pipeline now has 3 stages: test (the POD source), build, and finally deploy: 
                   https://salsa.debian.org/perl-team/perl-team.pages.debian.net/pipelines/137200
  currently 2 scripts in different repos (scripts vs. website)


### Perl 5.31.11

- packaging pushed to salsa (branch ntyni/debian-5.31)
- updated perl.debian.net
- built test binNMUs on perl.debian.net http://perl.debian.net/rebuild-logs/perl-5.32/report.html
- filed https://github.com/Perl/metaconfig/pull/64
- started test rebuilds for perl reverse dependencies
- QA gobby doc Teams/Perl/Perl-5.32-QA
- issues for team
  - packaging libobject-pad-perl circular dependency/libfuture-asyncawait-perl - FIXED
  - libpod-parser-perl needs packaging (gregoa - in NEW); libauthen-sasl-cyrus-perl needs a build-dep on that
    - see https://perldoc.pl/5.31.5/perl5311delta#Removed-Modules-and-Pragmata
    - guess we'll find more missing deps for this...
    
### Perl 5.30.2

Got Configure and metaconfig back in sync:
- https://github.com/Perl/metaconfig/releases/tag/5.30.2
- https://github.com/Perl/perl5/pull/17788

### Tools

- released pkg-perl-tools (0.60): various small fixes
- released dh-make-perl (0.112): debhelper (compat) 13

### MUT - Multi Upstream Tarball

- work is progressing well to migrate libwww-search-perl from pkg-components
  - debian/components is gone bar install scripts
  - debian/update.sh removed
  - d/watch and gbp.conf updated to handle components
- TODO: need to update d/rules to install components into binary package
  - will refer to JS acorn packaging for hints
  - gregoa also mentioned (thanks!) libhtml-template-pluggable-perl on IRC 

### Saturday's meeting

 - What happened since yesterday's meeting (see log on this very Gobby doc)

 - Plans for today

 - d/NEWS, d/NEWS.Developer

   Problem statement:
   
    - Hide developer-oriented changes from users who would not care about them.
    - This would allow us to feel more at ease documenting more breaking
      changes (e.g. API) than we currently do.

   Ideas:
   
    - add opt-in support to apt-listchanges for displaying d/NEWS.Developer
    - teach debhelper to install NEWS.Developer automatically

   For which sort of changes do we want to use NEWS.Developer, as opposed
   to NEWS?
   For modules, the target audience is generally a developer themselves,
   so d/NEWS could work?
   For user-facing changes, and the "user" is not necessarily a developer,
   then use d/NEWS?

   nodens would like to work on this but not alone. (+dom, but probably not
   this weekend, +knowledgejunkie?)

   Next steps:
   
   1. Start using d/NEWS.Developer ourselves + document in team policy
    → MR: https://salsa.debian.org/perl-team/perl-team.pages.debian.net/-/merge_requests/8

   2. Patch debhelper so we don't need to manually install
      every d/NEWS.Developer we create
   3. Patch apt-listchanges so consumers of this info get it
      (otherwise, any info we write in NEWS.Developer is effectively
      hidden from the target audience, unless they voluntarily look
      in /usr/share/doc)

 - hardening flags: all or bindnow ?
   e.g. export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
    vs. export DEB_BUILD_MAINT_OPTIONS = hardening=+all

   Data points:

    - Some of us manually add this manually to debian/rules for XS packages,
      but we don't do it consistently (wrt. doing it at all, and wrt.
      enabling bindnow vs. all)
    - The definition of hardening=+all has not changed much and we can't
      recall breakage it would have caused.
    - We currently add hardening= build options in every d/rules
      for XS packages. That's not very fun and not done in a standard,
      team-wide manner.

   Decision: we use hardening=+all by default when we add these flags manually.
   If that breaks the build, feel free to drop it or to set a more fine-grained
   hardening=.

   Action: nodens documents this in our team's policy → MR: https://salsa.debian.org/perl-team/perl-team.pages.debian.net/-/merge_requests/7 (Merged)

   How to avoid having to do this manually?

    - We have other reasons to include a Makefile snippet in our packages.
    - Could be a pkg-perl-tools thing
    - or a debhelper (perl buildsystem specific) change
      → may need a debhelper compat level bump to enable by default
      Rebuttal: debhelper is not the right place for things that are
      not project-wide defaults; there are packages we don't maintain,
      that use the perl buildsystem. Perhaps not a blocker if it comes
      in a new debhelper compat level.
      ⚠ The default flags are set by dpkg-buildflags, not by debhelper.

   Next steps:

     - check with Niels if doing this in debhelper sounds crazy (debhelper vs. dpkg)
     - $someone writes a debhelper draft patch
     - Dom tests that debhelper patch on the rebuilder
     - How to identify affected packages? Either:
        - Cheap test: lib*-perl
        - Complete test: look at the perl buildsystem auto-enabling logic

 - libgit-raw-perl

    - Something in the packaging is a mess
    - Potential blocker for upcoming libgit2 transition
    - Reverse-deps: libgit-objectstore-perl + torrus

### MUT - Multi Upstream Tarball

- start work on migrating libwww-search-perl from pkg-components

 - Next meetings

    - Saturday, 18:00 UTC: mostly social (distanced 🤝)
    - Sunday, 13:00 UTC

Friday
------

### Initial meeting on Jitsi

(see rooms on top of doc)

Availability over the weekend:

Nick: Available but has children
Dom: On call:
  - not available from 10 to 12 UTC, 14:30-17:30 UTC
gregoa: no other plans on saturday, sunday other short appointment in the afternoon
utkarsh: on vacation so available
nodens: mostly available
ntyni: no fixed other plans, mostly available
intrigeri (added post-meeting): low-energy mode, will be vaguely around from
   time to time

Plans:

Saturday: 

Meet at 13:00 UTC in the main room
- https://meetings.opusvl.com/DebianPerlSprintMay2020

- Perl (dom & niko)
  - 5.30.2
  - 5.31.11

- autopkgtest-pkg-perl improvements
  - https://lists.debian.org/debian-perl/2020/04/msg00023.html
  - Nick
  - utkarsh

- debhelper 13
  - some new interesting features
  - gregoa (explore, dh-make-perl, update packages)
  
- MUT - Multi Upstream Tarball
  https://wiki.debian.org/Projects/DebSrc3.0#How_to_use_multiple_upstream_tarballs_in_3.0_.28quilt.29_format.3F
  - we want to get rid of some components on packages using MUT
  - Nick
  - new uscan features: https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-March/040739.html
  - list of existing packages using pkg-components support:
    - libcgi-application-perl
    - libcgi-application-plugin-authentication-perl
    - libcgi-application-plugin-authorization-perl
    - libcgi-application-plugin-devpopup-perl
    - libcgi-application-plugin-tt-perl
    - libcgi-application-plugin-viewcode-perl
    - libwww-search-perl
  - slowly working to get libwww-search-perl ported to uscan v4 new features

- hardening flags: all or bindnow ?
  - export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
  - discuss
  
- d/NEWS, d/NEWS.Developer
  - discuss
  
- inc/
  - check if there is work, then discuss if needed
  - debhelper compat level change (no . in @INC -> inc/ often ignored, e.g. for M::I)
  - nodens
  
- HTTP::Tiny
  - 954089 - verify SSL certs in dual-lifed HTTP::Tiny
  - send a mail to bug/damyan to check with him if he has plans
  - Dom can run the tests on perl.debian.net
  
- --with foo -> dh-sequence-foo
  - Gregor was thinking about looking at d/rules anyway
  
- Alien::*
  - package it and patch install_type (-> system) ?
  - discuss
  

### new upstream releases

* libnet-prometheus-perl
* libffi-checklib-perl
* libhttp-tinyish-perl
* libnet-dns-sec-perl
* libmail-dkim-perl
* libinfluxdb-lineprotocol-perl
* libfont-freetype-perl