Bug#1055955: transition: perl 5.38

[Niko Tyni]

Package: release.debian.org
User: release.debian.org at packages.debian.org
Usertags: transition
X-Debbugs-Cc: perl at packages.debian.org

Hi release team,

this has taken me much longer than necessary for various reasons, but I
think we're almost ready to push Perl 5.38 to sid now.

We should aim to release trixie with 5.40 (which will be released in May
2024 or so), but it's still better to do these transitions one at a time.

TL;DR:

- can we raise the remaining bugs to severity:serious?

- I'll request a transition slot once the easy ones are fixed

- should we worry about time64?

Perl 5.38 been in experimental since July, and we've been running
continuous amd64 rebuilds on perl.debian.net all the time. I also
checked for related autopkgtest regressions back in August/September
in all packages declaring Testsuite: autopkgtest-pkg-perl or having
Testsuite-Triggers: perl. The bugs we found are tracked with the usual
usertags:

  https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.38-transition;users=debian-perl@lists.debian.org

There's a few packages that are nontrivially broken and will probably
need to be removed from testing.

  libapache-db-perl #1040396

  libembperl-perl #1042845

  polymake #1042521

AFAICS polymake has one reverse dependency (gap-polymaking) and the
others have none, so removal shouldn't be too difficult.

Then there's some that already have patches or where the fixes are
trivial, but just need an upload:

  docknot #1042853

  elinks #1042844

  libgtk3-imageview-perl #1050445

  libperl-languageserver-perl #1050451

  libregexp-debuggperl-perl #1050454

  localehelper #1042525

I haven't checked reverse dependencies as I'm hoping they will be fixed.
Can we raise these bugs to severity:serious?

I can report back when these are fixed and request a transition slot.

Finally I just ran one more rebuild test for all the packages that will
need binNMUs, and found a couple of unrelated FTBFS bugs.  These would
block binNMUs.

  cod-tools #1055896 (fixed in sid today, needs to migrate)

  os-autoinst #1054776

  libprelude #1054793

  libauthen-sasl-cyrus-perl #1052871 (not in testing)

I haven't checked for version skew between testing and unstable, or for
any architecture specific issues on !amd64 as I don't have any good tools
for those. I suppose we'll need to handle them during the transition if
we hit any.

One more thing to mention: I'm slightly worried about the time64
transition that I think was supposed to happen this release cycle. As
I mentioned in July [1] I think it will need a perlapi-* bump and the
related binNMUs of the same set of packages.

[1] https://lists.debian.org/debian-devel/2023/07/msg00302.html

But things seem to be quiet and I still haven't looked at the perl side
of that at all. (I also have no idea how it can be done without a flag
day but I hope somebody does.) I don't think we should block on this
unless there's some activity that I've missed?


Ben file proposal, just copy-pasting from last year:

title = "perl";
is_affected = .depends ~ "libperl5.36|perlapi-5.36" | .pre-depends ~ "libperl5.36|perlapi-5.36";
is_good = .depends ~ "libperl5.38|perlapi-5.38" | .pre-depends ~ "libperl5.38|perlapi-5.38";
is_bad = .depends ~ "libperl5.36|perlapi-5.36" | .pre-depends ~ "libperl5.36|perlapi-5.36";

Thanks for your work on Debian,
-- 
Niko