Package: release.debian.org User: release.debian....@packages.debian.org Usertags: transition X-Debbugs-Cc: p...@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-p...@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
