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- instead of --with #### 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 $HOME 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))) '> 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