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