Your message dated Sun, 16 Jun 2024 16:17:19 +0200 with message-id <a99fb5d5-513e-4ed9-900b-6a78c5b6258f@debian.org> and subject line Re: transition: perl 5.38 has caused the Debian Bug report #1055955, regarding transition: perl 5.38 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 1055955: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055955 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: transition: perl 5.38
- From: Niko Tyni <ntyni@debian.org>
- Date: Tue, 14 Nov 2023 20:28:01 +0200
- Message-id: <ZVO8MY3ohksSiFkX@birgitta.local.invalid>
Package: release.debian.org User: release.debian.org@packages.debian.org Usertags: transition X-Debbugs-Cc: perl@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
--- End Message ---
--- Begin Message ---
- To: 1055955-done@bugs.debian.org
- Subject: Re: transition: perl 5.38
- From: Paul Gevers <elbrus@debian.org>
- Date: Sun, 16 Jun 2024 16:17:19 +0200
- Message-id: <a99fb5d5-513e-4ed9-900b-6a78c5b6258f@debian.org>
- In-reply-to: <ZVO8MY3ohksSiFkX@birgitta.local.invalid>
- References: <ZVO8MY3ohksSiFkX@birgitta.local.invalid> <ZVO8MY3ohksSiFkX@birgitta.local.invalid>
Hi, On Tue, 14 Nov 2023 20:28:01 +0200 Niko Tyni <ntyni@debian.org> wrote: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.The ben tracker for Perl 5.38 has been moved to old in the beginning of March, thus closing this bug.PaulAttachment: OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---