Bug#1003176: transition: perl 5.34
On 2022-02-10 15:19:57, Alex wrote: > On donderdag 10 februari 2022 14:59:59 CET Paul Gevers wrote: > > > The "collectd" package recommends libperl5.34 as it has a loadable > > > module built against libperl5.34. The transition criteria however > > > will not consider rebuilding the package even though in the > > > current state in unstable it is broken for any practical usage. The > > > module still loads, as libperl5.32 is still present, but the > > > executed perl code fails on lots of missing packages as their 5.32 > > > version is already replaced with the 5.34 version. > > > > > > Hmm, I *think* libperl* is co-installable on purpose, > > Probably, but that's only useful if the perl script doesn't use any > modules with compiled code. > > > > > so if stuff > > breaks, is it because you expect more than you ask for or because you > > also link against other packages that link against the latest > > version and you get symbols double > > I'm not compiling anything, just trying to run a script which uses > "HTML::Parser" via an embedded perl interpreter in collectd. > > > > > (I am not sure if I use the right > > terminology, but I hope you understand what I mean)? Do you know? > > I don't think I do, unfortunately. > > > Because the collectd perl plugin is linked against libperl5.32, my > script fails as libhtml-parser-perl is already upgraded to 5.34. > > I agree that package dependencies probably won't be able to solve this, > but that's not the message I'm trying to convey. > > The issue is that in order for my script to work again, I must wait > until collectd is recompiled against libperl5.34. Because of the > criteria/conditions in the transition, this won't happen automatically > as collectd only has a recommends against libperl5.32, not a depends. > > I think in case of a recommends on a _library_, it is warranted to > trigger a rebuild too, as recommends on libraries mostly implies that it > will be dl-opened instead of linked. And dl-opended libraries have the > same versioning constraints as directly linked ones. > > Hence my request to add "recommends ~ libperl5.43" to the transition > criteria. The tracker is mostly a copy of trackers that we used for other perl transitions. I don't remember Packages that only recommend libperlX being a problem for perl transitions. The tracker now also checks for recommends and I have binNMUed collectd. Cheers > -- > mvg, > > Alex Hermann > -- Sebastian Ramacher
Bug#1003176: transition: perl 5.34
On donderdag 10 februari 2022 14:59:59 CET Paul Gevers wrote: > > The "collectd" package recommends libperl5.34 as it has a loadable > > module built against libperl5.34. The transition criteria however > > will not consider rebuilding the package even though in the > > current state in unstable it is broken for any practical usage. The > > module still loads, as libperl5.32 is still present, but the > > executed perl code fails on lots of missing packages as their 5.32 > > version is already replaced with the 5.34 version. > > > Hmm, I *think* libperl* is co-installable on purpose, Probably, but that's only useful if the perl script doesn't use any modules with compiled code. > so if stuff > breaks, is it because you expect more than you ask for or because you > also link against other packages that link against the latest > version and you get symbols double I'm not compiling anything, just trying to run a script which uses "HTML::Parser" via an embedded perl interpreter in collectd. > (I am not sure if I use the right > terminology, but I hope you understand what I mean)? Do you know? I don't think I do, unfortunately. Because the collectd perl plugin is linked against libperl5.32, my script fails as libhtml-parser-perl is already upgraded to 5.34. I agree that package dependencies probably won't be able to solve this, but that's not the message I'm trying to convey. The issue is that in order for my script to work again, I must wait until collectd is recompiled against libperl5.34. Because of the criteria/conditions in the transition, this won't happen automatically as collectd only has a recommends against libperl5.32, not a depends. I think in case of a recommends on a _library_, it is warranted to trigger a rebuild too, as recommends on libraries mostly implies that it will be dl-opened instead of linked. And dl-opended libraries have the same versioning constraints as directly linked ones. Hence my request to add "recommends ~ libperl5.43" to the transition criteria. -- mvg, Alex Hermann
Bug#1003176: transition: perl 5.34
Hi Alex, On 10-02-2022 13:21, Alex wrote: I was wondering why the condition for the perl-5.34 transition has the "depends" in the condition, but not the "recommends"? I think because we never did that in the past, I *assume* the tracker was based on the previous one. The "collectd" package recommends libperl5.34 as it has a loadable module built against libperl5.34. The transition criteria however will not consider rebuilding the package even though in the current state in unstable it is broken for any practical usage. The module still loads, as libperl5.32 is still present, but the executed perl code fails on lots of missing packages as their 5.32 version is already replaced with the 5.34 version. Hmm, I *think* libperl* is co-installable on purpose, so if stuff breaks, is it because you expect more than you ask for or because you also link against other packages that link against the latest version and you get symbols double (I am not sure if I use the right terminology, but I hope you understand what I mean)? Do you know? Please consider adding "recommends ~ libper5.34" to the transition criteria. For now, I'll leave this call to Sebastian. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1003176: transition: perl 5.34
Hi, I was wondering why the condition for the perl-5.34 transition has the "depends" in the condition, but not the "recommends"? The "collectd" package recommends libperl5.34 as it has a loadable module built against libperl5.34. The transition criteria however will not consider rebuilding the package even though in the current state in unstable it is broken for any practical usage. The module still loads, as libperl5.32 is still present, but the executed perl code fails on lots of missing packages as their 5.32 version is already replaced with the 5.34 version. Please consider adding "recommends ~ libper5.34" to the transition criteria. -- mvg, Alex Hermann
Bug#1003176: transition: perl 5.34
Hi Niko,
On 09-02-2022 22:49, Niko Tyni wrote:
Not sure about the format but hope the attached will do. Each line has
the package to be rescheduled, and then a list of packages that need
to be pulled from unstable. I haven't checked whether the lists are
absolutely minimal for this, but a few too much shouldn't hurt as they
are going to migrate at the same time anyway.
I'll construct lines like this from the list
"""
echo
'[{"trigger":"perl/5.34.0-3","package":"libtickit-console-perl","pin-packages":[["src:libtickit-console-perl,src:libobject-pad-perl,src:perl","unstable"]]}]'
> tmp4.json
"""
because that's the format needed for the debci API, that I can trigger
with the following command:
"""
for arch in amd64 arm64 armhf i386 ppc64el s390x; do curl --cacert
/etc/ssl/ca-global/ca-certificates.crt --header @britney_key.header
--form tests=@tmp4.json --form priority=10
"https://ci.debian.net/api/v1/test/testing/${arch}; ; done
"""
If you can reschedule these, I can then sort through the results to see
whether this worked at all.
Working on it.
(BTW: Could I do the rescheduling myself via the ci.d.n API, or do the
requests need to come from britney to be considered grounds for
migration?)
Indeed, you can't schedule these jobs as it needs the credentials for
the britney user on ci.d.n which should be only available to release
team members.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1003176: transition: perl 5.34
Hi Paul, Sebastian and others,
as discussed on IRC, here's a list of packages that need rescheduling on
ci.debian.net for the Perl 5.34 transition. Their autopkgtest checks are
failing as their Recommendations are not installable without explicitly
pulling their rebuilt dependencies from unstable.
We also have another class of problem where a handful of packages are
failing their tests because of version skew between testing and unstable.
If the testing version of the package itself is uninstallable with perl
from unstable, autopkgtest falls back to downloading everything from
unstable ("package is not installed though it should be"). Most of the
time this works OK, but in some cases it can include other packages that
break tests in testing, or even a newer version of the package itself that
is incompatible with the tests extracted from the older source package.
I've included a couple of arch:all packages that I hope can be made
installable in testing with some help. We can revisit the rest when these
'easier' ones have been sorted out.
Not sure about the format but hope the attached will do. Each line has
the package to be rescheduled, and then a list of packages that need
to be pulled from unstable. I haven't checked whether the lists are
absolutely minimal for this, but a few too much shouldn't hurt as they
are going to migrate at the same time anyway.
If you can reschedule these, I can then sort through the results to see
whether this worked at all.
(BTW: Could I do the rescheduling myself via the ci.d.n API, or do the
requests need to come from britney to be considered grounds for
migration?)
Thanks,
--
Niko
# make package recommendations installable
libapache-session-perl/1.94-1 needs libhtml-parser-perl libdbi-perl
libcpanplus-perl/0.9914-1 needs libdbd-sqlite3-perl libdbi-perl
libdata-stag-perl/0.14-2 needs libgd-perl libhtml-parser-perl
libnet-ssleay-perl libset-object-perl libxml-libxml-perl libxml-libxslt-perl
libxml-parser-perl perl-tk
libhttp-tinyish-perl/0.17-1 needs libhtml-parser-perl libnet-ssleay-perl
libjavascript-beautifier-perl/0.25-2 needs libb-hooks-op-check-perl
libclass-xsaccessor-perl libdevel-callchecker-perl libparams-classify-perl
liblog-agent-perl/1.005-1 needs libnet-ssleay-perl
liblog-log4perl-perl/1.54-1 needs libb-hooks-op-check-perl
libdevel-callchecker-perl libparams-classify-perl libparams-util-perl
libstring-crc32-perl libsub-identify-perl libsub-name-perl
libvariable-magic-perl libxstring-perl
libmojolicious-perl/9.22+dfsg-1 needs libcommon-sense-perl
libcpanel-json-xs-perl libev-perl libfuture-asyncawait-perl libnet-ssleay-perl
libxs-parse-keyword-perl libxs-parse-sublike-perl
libnet-server-mail-perl/0.28-1 needs libnet-ssleay-perl
libpdf-builder-perl/3.023-1 needs libgraphics-tiff-perl libimage-png-libpng-perl
libpoe-test-loops-perl/1.360-1.1 needs libfilter-perl
libspreadsheet-wright-perl/0.107-3 needs libb-hooks-op-check-perl
libdatetime-perl libdevel-callchecker-perl libparams-classify-perl
libparams-util-perl libsub-identify-perl libsub-name-perl
libvariable-magic-perl libxml-libxml-perl libxstring-perl
libsyntax-highlight-engine-kate-perl/0.14+dfsg-1 needs libhtml-parser-perl
libnet-ssleay-perl libxml-parser-perl
libsys-info-base-perl/0.7807-3 needs libunix-processors-perl
# make the package itself installable
libxml-atom-perl/0.42-2.1 needs libb-hooks-op-check-perl libdatetime-perl
libdevel-callchecker-perl libhtml-parser-perl libnet-ssleay-perl
libparams-classify-perl libparams-util-perl libsub-identify-perl
libsub-name-perl libvariable-magic-perl libxml-libxml-perl libxml-libxslt-perl
libxml-parser-perl libxstring-perl
libdigest-bcrypt-perl/1.209-3 needs libb-hooks-op-check-perl
libcrypt-eksblowfish-perl libdevel-callchecker-perl libparams-classify-perl
Bug#1003176: transition: perl 5.34
On Sat, Feb 05, 2022 at 12:40:53PM +0200, Niko Tyni wrote: > Uploading this afternoon. perl_5.34.0-3 uploaded and accepted. -- Niko
Bug#1003176: transition: perl 5.34
On Sat, Feb 05, 2022 at 11:07:19AM +0100, Sebastian Ramacher wrote: > On 2022-02-04 10:52:11, Niko Tyni wrote: > > On Thu, Feb 03, 2022 at 09:49:28PM +0100, Sebastian Ramacher wrote: > > > > On 2022-01-05 17:00:54 +, Niko Tyni wrote: > > > > > we'd like a transition slot for Perl 5.34. > > > ocaml is done, so please go ahead. > > > > Thanks! > > > > My last rebuilds found that graphviz has regressed and doesn't build > > anymore (#1004956). Do we need to get that fixed first? > > libgv-perl does not have any reverse dependencies. None of the other > binaries built by graphviz are affected by this transition. Ack, thanks. > Unless there are any other packages that build perl and php bindings > using swig that would fail to build, I don't think that this bug is a > blocker. No other regressions turned up in my rebuild tests, so I think we should be fine. Uploading this afternoon. -- Niko
Bug#1003176: transition: perl 5.34
On 2022-02-04 10:52:11, Niko Tyni wrote: > On Thu, Feb 03, 2022 at 09:49:28PM +0100, Sebastian Ramacher wrote: > > > On 2022-01-05 17:00:54 +, Niko Tyni wrote: > > > > we'd like a transition slot for Perl 5.34. > > ocaml is done, so please go ahead. > > Thanks! > > My last rebuilds found that graphviz has regressed and doesn't build > anymore (#1004956). Do we need to get that fixed first? libgv-perl does not have any reverse dependencies. None of the other binaries built by graphviz are affected by this transition. Unless there are any other packages that build perl and php bindings using swig that would fail to build, I don't think that this bug is a blocker. Cheers -- Sebastian Ramacher
Bug#1003176: transition: perl 5.34
On Thu, Feb 03, 2022 at 09:49:28PM +0100, Sebastian Ramacher wrote: > > On 2022-01-05 17:00:54 +, Niko Tyni wrote: > > > we'd like a transition slot for Perl 5.34. > ocaml is done, so please go ahead. Thanks! My last rebuilds found that graphviz has regressed and doesn't build anymore (#1004956). Do we need to get that fixed first? If not, I can hopefully upload 5.34 some time tomorrow (Saturday). -- Niko
Bug#1003176: transition: perl 5.34
Control: tags -1 confirmed On 2022-01-23 12:45:16, Sebastian Ramacher wrote: > Control: block -1 by 1002681 > Control: forwarded -1 > https://release.debian.org/transitions/html/perl-5.34.html > > On 2022-01-05 17:00:54 +, Niko Tyni wrote: > > Package: release.debian.org > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: debian-p...@lists.debian.org, p...@packages.debian.org > > Control: block -1 with 1002093 997267 997189 > > > > Hi, > > > > we'd like a transition slot for Perl 5.34. > > > > Should have done this months ago, but real life has interfered. Sorry > > about that. > > > > Perl 5.36 is scheluded for May or so, and I expect that will be our target > > for bookworm. Nevertheless, it's probably best to do this incrementally > > and have a 5.34 transition now in case 5.36 turns out to be difficult > > for some reason. > > > > The changes in 5.34 are quite small, as upstream spent most of that > > release cycle planning Perl 7 (which did not quite work out.) This > > reflects in the very low number regressions we found in our test > > rebuilds, visible at > > > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.34-transition;users=debian-p...@lists.debian.org > > > > with just one bug open (openscap, not in testing). > > > > I did a full archive test rebuild back in May, and partial test rebuilds > > in August. Coming back to this now, I've done another round of test > > rebuilds for those packages that will need binNMUs. I don't think another > > full round is necessary: it seems unlikely that the other packages might > > have introduced any Perl 5.34 related regressions in the meantime. > > > > There's a few packages that have unrelated build failures in current sid. > > I'm marking the ones in testing as blockers for this. > > Some packages are also involved in the ongoing ocaml transition. So > let's wait for ocaml to be done. ocaml is done, so please go ahead. Cheers -- Sebastian Ramacher
Bug#1003176: transition: perl 5.34
Control: block -1 by 1002681 Control: forwarded -1 https://release.debian.org/transitions/html/perl-5.34.html On 2022-01-05 17:00:54 +, Niko Tyni wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-p...@lists.debian.org, p...@packages.debian.org > Control: block -1 with 1002093 997267 997189 > > Hi, > > we'd like a transition slot for Perl 5.34. > > Should have done this months ago, but real life has interfered. Sorry > about that. > > Perl 5.36 is scheluded for May or so, and I expect that will be our target > for bookworm. Nevertheless, it's probably best to do this incrementally > and have a 5.34 transition now in case 5.36 turns out to be difficult > for some reason. > > The changes in 5.34 are quite small, as upstream spent most of that > release cycle planning Perl 7 (which did not quite work out.) This > reflects in the very low number regressions we found in our test > rebuilds, visible at > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.34-transition;users=debian-p...@lists.debian.org > > with just one bug open (openscap, not in testing). > > I did a full archive test rebuild back in May, and partial test rebuilds > in August. Coming back to this now, I've done another round of test > rebuilds for those packages that will need binNMUs. I don't think another > full round is necessary: it seems unlikely that the other packages might > have introduced any Perl 5.34 related regressions in the meantime. > > There's a few packages that have unrelated build failures in current sid. > I'm marking the ones in testing as blockers for this. Some packages are also involved in the ongoing ocaml transition. So let's wait for ocaml to be done. Cheers > > Not sure if this Ben file is correct but hope it helps a bit: > > title = "perl"; > is_affected = .depends ~ "libperl5.32|perlapi-5.32" | .pre-depends ~ > "libperl5.32|perlapi-5.32"; > is_good = .depends ~ "libperl5.34|perlapi-5.34" | .pre-depends ~ > "libperl5.34|perlapi-5.34"; > is_bad = .depends ~ "libperl5.32|perlapi-5.32" | .pre-depends ~ > "libperl5.32|perlapi-5.32"; > > Thanks for your work, > -- > Niko Tyni nt...@debian.org > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#1003176: transition: perl 5.34
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-p...@lists.debian.org, p...@packages.debian.org Control: block -1 with 1002093 997267 997189 Hi, we'd like a transition slot for Perl 5.34. Should have done this months ago, but real life has interfered. Sorry about that. Perl 5.36 is scheluded for May or so, and I expect that will be our target for bookworm. Nevertheless, it's probably best to do this incrementally and have a 5.34 transition now in case 5.36 turns out to be difficult for some reason. The changes in 5.34 are quite small, as upstream spent most of that release cycle planning Perl 7 (which did not quite work out.) This reflects in the very low number regressions we found in our test rebuilds, visible at https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.34-transition;users=debian-p...@lists.debian.org with just one bug open (openscap, not in testing). I did a full archive test rebuild back in May, and partial test rebuilds in August. Coming back to this now, I've done another round of test rebuilds for those packages that will need binNMUs. I don't think another full round is necessary: it seems unlikely that the other packages might have introduced any Perl 5.34 related regressions in the meantime. There's a few packages that have unrelated build failures in current sid. I'm marking the ones in testing as blockers for this. Not sure if this Ben file is correct but hope it helps a bit: title = "perl"; is_affected = .depends ~ "libperl5.32|perlapi-5.32" | .pre-depends ~ "libperl5.32|perlapi-5.32"; is_good = .depends ~ "libperl5.34|perlapi-5.34" | .pre-depends ~ "libperl5.34|perlapi-5.34"; is_bad = .depends ~ "libperl5.32|perlapi-5.32" | .pre-depends ~ "libperl5.32|perlapi-5.32"; Thanks for your work, -- Niko Tyni nt...@debian.org
