Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1044932 > unrolled thread

Bug#981232: unblock: perl/5.32.1-1

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#981232: unblock: perl/5.32.1-1 Dominic Hargreaves <dom@earth.li> - 2021-01-28 00:50 +0100
    Bug#981232: unblock: perl/5.32.1-1 Paul Gevers <elbrus@debian.org> - 2021-01-28 21:30 +0100
      Bug#981232: unblock: perl/5.32.1-1 Dominic Hargreaves <dom@earth.li> - 2021-01-28 22:10 +0100
        Bug#981232: unblock: perl/5.32.1-1 Paul Gevers <elbrus@debian.org> - 2021-01-28 22:30 +0100
          Bug#981232: unblock: perl/5.32.1-1 Dominic Hargreaves <dom@earth.li> - 2021-01-28 22:40 +0100
            Bug#981232: unblock: perl/5.32.1-1 Paul Gevers <elbrus@debian.org> - 2021-01-30 07:40 +0100
              Bug#981232: unblock: perl/5.32.1-1 Niko Tyni <ntyni@debian.org> - 2021-01-30 20:20 +0100
                Bug#981232: unblock: perl/5.32.1-1 Dominic Hargreaves <dom@earth.li> - 2021-01-30 20:50 +0100
                  Bug#981232: unblock: perl/5.32.1-1 Niko Tyni <ntyni@debian.org> - 2021-01-31 10:10 +0100
                    Bug#981232: unblock: perl/5.32.1-1 Niko Tyni <ntyni@debian.org> - 2021-01-31 22:00 +0100
                      Bug#981232: unblock: perl/5.32.1-1 Paul Gevers <elbrus@debian.org> - 2021-02-01 20:40 +0100
                        Bug#981232: unblock: perl/5.32.1-1 Dominic Hargreaves <dom@earth.li> - 2021-02-02 09:00 +0100
                          Bug#981232: unblock: perl/5.32.1-1 Paul Gevers <elbrus@debian.org> - 2021-02-02 09:20 +0100
                            Bug#981232: unblock: perl/5.32.1-1 Dominic Hargreaves <dom@earth.li> - 2021-02-02 23:20 +0100
          Bug#981232: unblock: perl/5.32.1-1 Niko Tyni <ntyni@debian.org> - 2021-01-29 13:50 +0100

#1044932 — Bug#981232: unblock: perl/5.32.1-1

Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock

This is a pre-approval request.

As I wrote in 
https://lists.debian.org/debian-release/2021/01/msg00296.html

we'd like to get 5.32.1 into bullseye if possible. I should have probably
written all that in a bug instead so it can be tracked effectively.

As always, perl point releases are pretty conservative and we've
effectively imported them into s-p-u before.

All the reset of the context is in that post so I won't repeat it.
My preference is to upload 5.32.1 in whole as it's probably overall
less risky, and less maintenance work, but there is the option of
cherry-picking the targetted fixes too.

5.32.1 would need a binnmu of a few leaf packages
(libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl
libcommon-sense-perl) as usual.

perl 5.32.1 is currently in experimental - see
<https://salsa.debian.org/perl-team/interpreter/perl/-/tree/experimental-5.32>

Cheers
Dominic

[toc] | [next] | [standalone]

#1045097

[Multipart message — attachments visible in raw view] — view raw

Control: tags -1 moreinfo

Hi Dominic,

(Your bug title is wrong, as you can't use that version anymore as it's
already in experimental ;) )

On 28-01-2021 00:39, Dominic Hargreaves wrote:
> I should have probably
> written all that in a bug instead so it can be tracked effectively.

Indeed.

> As always, perl point releases are pretty conservative and we've
> effectively imported them into s-p-u before.
> 
> All the reset of the context is in that post so I won't repeat it.

Wouldn't have hurt though.

> My preference is to upload 5.32.1 in whole as it's probably overall
> less risky, and less maintenance work, but there is the option of
> cherry-picking the targetted fixes too.
> 
> 5.32.1 would need a binnmu of a few leaf packages
> (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl
> libcommon-sense-perl) as usual.

Just to be clear, these binNMU's would be needed too if we would go for
the cherry-pick option?

Paul

[toc] | [prev] | [next] | [standalone]

#1045105

On Thu, Jan 28, 2021 at 09:21:54PM +0100, Paul Gevers wrote:
> (Your bug title is wrong, as you can't use that version anymore as it's
> already in experimental ;) )
> 
> On 28-01-2021 00:39, Dominic Hargreaves wrote:

> > My preference is to upload 5.32.1 in whole as it's probably overall
> > less risky, and less maintenance work, but there is the option of
> > cherry-picking the targetted fixes too.
> > 
> > 5.32.1 would need a binnmu of a few leaf packages
> > (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl
> > libcommon-sense-perl) as usual.
> 
> Just to be clear, these binNMU's would be needed too if we would go for
> the cherry-pick option?

No, the binaries relate to a change of upstream version number
which ends up being encoded in these packages. If we cherry pick
fixes, the binNMUs wouldn't be needed.

Dominic

[toc] | [prev] | [next] | [standalone]

#1045107

[Multipart message — attachments visible in raw view] — view raw

Hi Dominic,

On 28-01-2021 22:05, Dominic Hargreaves wrote:
>>> 5.32.1 would need a binnmu of a few leaf packages
>>> (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl
>>> libcommon-sense-perl) as usual.
>>
>> Just to be clear, these binNMU's would be needed too if we would go for
>> the cherry-pick option?
> 
> No, the binaries relate to a change of upstream version number
> which ends up being encoded in these packages. If we cherry pick
> fixes, the binNMUs wouldn't be needed.

But then, that relation is strictly speaking too tight? Is that
something that can be improved (without jumping through hoops)? Maybe
not for this time, but for future changes. Normally perl packages look
for the perl-something-api right? Which would make it clear that this is
no transition.

Would you have also asked us if you wouldn't have needed the binNMU's?

Paul

[toc] | [prev] | [next] | [standalone]

#1045108

On Thu, Jan 28, 2021 at 10:21:21PM +0100, Paul Gevers wrote:
> Hi Dominic,
> 
> On 28-01-2021 22:05, Dominic Hargreaves wrote:
> >>> 5.32.1 would need a binnmu of a few leaf packages
> >>> (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl
> >>> libcommon-sense-perl) as usual.
> >>
> >> Just to be clear, these binNMU's would be needed too if we would go for
> >> the cherry-pick option?
> > 
> > No, the binaries relate to a change of upstream version number
> > which ends up being encoded in these packages. If we cherry pick
> > fixes, the binNMUs wouldn't be needed.
> 
> But then, that relation is strictly speaking too tight? Is that
> something that can be improved (without jumping through hoops)? Maybe
> not for this time, but for future changes. Normally perl packages look
> for the perl-something-api right? Which would make it clear that this is
> no transition.

The packages in the mini-transition have a full version dependency
built into them - it's not API/ABI related. It's been a while but we've
looked at improving this before and it's not really practical given
the assumptions built into the upstream code. It's also generally
not been an issue to do the binNMUs.

> Would you have also asked us if you wouldn't have needed the binNMU's?

Yes, since https://release.debian.org/bullseye/freeze_policy.html says
changes to build-essential may only be made with pre-approval...

[toc] | [prev] | [next] | [standalone]

#1045294

[Multipart message — attachments visible in raw view] — view raw

Hi,

On 28-01-2021 22:36, Dominic Hargreaves wrote:
>> Would you have also asked us if you wouldn't have needed the binNMU's?
> 
> Yes, since https://release.debian.org/bullseye/freeze_policy.html says
> changes to build-essential may only be made with pre-approval...

Right. Thank you, I should learn that list by heart.

The pseudo excuses [1] report quite some autopkgtest regressions. Can
you please check them, fix them if relevant or explain why they are not
relevant for bullseye (e.g. unstable only)?

Paul

[1] https://release.debian.org/britney/pseudo-excuses-experimental.html#perl

[toc] | [prev] | [next] | [standalone]

#1045398

On Sat, Jan 30, 2021 at 07:35:04AM +0100, Paul Gevers wrote:

> The pseudo excuses [1] report quite some autopkgtest regressions. Can
> you please check them, fix them if relevant or explain why they are not
> relevant for bullseye (e.g. unstable only)?

> [1] https://release.debian.org/britney/pseudo-excuses-experimental.html#perl

I spent most of today going through logs of the 300 or so packages showing
regressions. The gain was not worth the maintainer time IMHO. I'm not
looking forward to doing this again for the actual testing migration.

I found about 160 network/proxy failures on arm64 hosts with apt bailing
out, and about 120 installability failures relating to the four packages
that we already knew will need a rebuild.

The remaining 19 failures are categorized below with comments.

I'm away from my credentials for the self service, can schedule retries
probably tomorrow if necessary. Happy if somebody else beats me to it.

Needs fixing for 5.32.1
-----------------------

- libdevel-mat-dumper-perl
     real issue; needs a strict dependency and a rebuild for 5.32.1
     also means this is a fifth package that needs a binnmu
     filed #981408

- perl 
    filed as #981409
    minor issue, can be fixed when uploading to sid

Retry suggested
---------------

bioperl # flaky; API rate limit exceeded, similar to testing/amd64/1.7.7-2  2020-12-02 04:21:20 UTC
backuppc # one-off? unlikely it's perl's fault
jellyfish # test suite timeout, not perl specific?
ikiwiki-hosting # not perl specific: apache2.service: Failed to set up mount namespacing: Permission denied
libbio-db-ncbihelper-perl # network error? MSG: Can't query website: 500 Status read failed: Connection reset by peer
trinityrnaseq # probably flaky?
libtest-valgrind-perl # no idea, worth a retry. Might be a valgrind issue on ppc64el

Issues elsewhere, not triggered by src:perl
-------------------------------------------

apache2 # fails with just src:openssl from experimental
kopanocore # not in testing; fails with e.g. src:e2fsprogs from experimental too
libcrypt-smime-perl # probably triggered by src:openssl in experimental, failed the same way on ppc64el earlier with perl/5.32.1~rc1-1
libdata-alias-perl # not in testing, uninstallable
libtemplate-plugin-calendar-simple-perl # #964155; not in testing
libwebsockets # tested from experimental, fails just by itself
mysql-8.0 # not in testing; fails without src:perl too
metastudent # not a regression, missing/old reference? #981293
licensecheck # failures in testing too, filed #981410

-- 
Niko Tyni   ntyni@debian.org

[toc] | [prev] | [next] | [standalone]

#1045402

On Sat, Jan 30, 2021 at 09:13:42PM +0200, Niko Tyni wrote:
> On Sat, Jan 30, 2021 at 07:35:04AM +0100, Paul Gevers wrote:
> 
> > The pseudo excuses [1] report quite some autopkgtest regressions. Can
> > you please check them, fix them if relevant or explain why they are not
> > relevant for bullseye (e.g. unstable only)?
> 
> > [1] https://release.debian.org/britney/pseudo-excuses-experimental.html#perl
> 
> I spent most of today going through logs of the 300 or so packages showing
> regressions. The gain was not worth the maintainer time IMHO. I'm not
> looking forward to doing this again for the actual testing migration.

Thanks!

> I found about 160 network/proxy failures on arm64 hosts with apt bailing
> out, and about 120 installability failures relating to the four packages
> that we already knew will need a rebuild.
> 
> The remaining 19 failures are categorized below with comments.
> 
> I'm away from my credentials for the self service, can schedule retries
> probably tomorrow if necessary. Happy if somebody else beats me to it.

I pressed retry a bunch of times.

> Needs fixing for 5.32.1
> -----------------------
> 
> - libdevel-mat-dumper-perl
>      real issue; needs a strict dependency and a rebuild for 5.32.1
>      also means this is a fifth package that needs a binnmu
>      filed #981408
> 
> - perl 
>     filed as #981409
>     minor issue, can be fixed when uploading to sid

Fixed in git.

> Retry suggested
> ---------------
> 
> bioperl # flaky; API rate limit exceeded, similar to testing/amd64/1.7.7-2  2020-12-02 04:21:20 UTC
> backuppc # one-off? unlikely it's perl's fault
> jellyfish # test suite timeout, not perl specific?
> ikiwiki-hosting # not perl specific: apache2.service: Failed to set up mount namespacing: Permission denied
> libbio-db-ncbihelper-perl # network error? MSG: Can't query website: 500 Status read failed: Connection reset by peer
> trinityrnaseq # probably flaky?
> libtest-valgrind-perl # no idea, worth a retry. Might be a valgrind issue on ppc64el

[toc] | [prev] | [next] | [standalone]

#1045465

On Sat, Jan 30, 2021 at 07:39:36PM +0000, Dominic Hargreaves wrote:

> I pressed retry a bunch of times.

Thanks. Looks like all those failures went away, except
libtest-valgrind-perl. I cannot reproduce that ppc64el failure on
plummer.debian.org (though it's a bit hard to simulate the exact
autopkgtest conditions without actually running autopkgtest there.)

I've just scheduled one more retry on ci.debian.net. In any case, I
suggest we ignore this for now and revisit if it still shows up with
the testing migration runs.
-- 
Niko

[toc] | [prev] | [next] | [standalone]

#1045573

Control: tag -1 - moreinfo

On Sun, Jan 31, 2021 at 11:00:16AM +0200, Niko Tyni wrote:
> 
> Thanks. Looks like all those failures went away, except
> libtest-valgrind-perl. I cannot reproduce that ppc64el failure on
> plummer.debian.org (though it's a bit hard to simulate the exact
> autopkgtest conditions without actually running autopkgtest there.)

The libtest-valgrind-perl tests ran successfully now, so I suppose we
were just unlucky to have it fail twice in a row earlier. In any case
the new perl version doesn't seem to be the cause for the failures.

I don't think there are any open issues left, so removing the moreinfo
tag.

Paul (and others): please consider approving 5.32.1. I think it would be
better to release bullseye with that than a Debian-specific 5.32.0 with
the patches from 5.32.1 (but both options are better than not having
the patches at all.)

Thanks for your work on the release,
-- 
Niko Tyni   ntyni@debian.org

[toc] | [prev] | [next] | [standalone]

#1045773

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 confirmed

Hi,

On 31-01-2021 21:50, Niko Tyni wrote:
> please consider approving 5.32.1. I think it would be
> better to release bullseye with that than a Debian-specific 5.32.0 with
> the patches from 5.32.1 (but both options are better than not having
> the patches at all.)

Please go ahead.

Paul

[toc] | [prev] | [next] | [standalone]

#1045838

On Mon, Feb 01, 2021 at 08:38:40PM +0100, Paul Gevers wrote:
> Control: tag -1 confirmed
> 
> Hi,
> 
> On 31-01-2021 21:50, Niko Tyni wrote:
> > please consider approving 5.32.1. I think it would be
> > better to release bullseye with that than a Debian-specific 5.32.0 with
> > the patches from 5.32.1 (but both options are better than not having
> > the patches at all.)
> 
> Please go ahead.

Thanks, this is now uploaded and building:

https://buildd.debian.org/status/package.php?p=perl

Please rebuild these packages as discussed:

$ wb nmu libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl libcommon-sense-perl libdevel-mat-dumper-perl . ANY . -m "Rebuild against perlapi-5.32.1." --extra-depends 'perl-base (>= 5.32.1)'

Thanks!
Dominic

[toc] | [prev] | [next] | [standalone]

#1045840

[Multipart message — attachments visible in raw view] — view raw

Hi,

On 02-02-2021 08:47, Dominic Hargreaves wrote:
> Please rebuild these packages as discussed:
> 
> $ wb nmu libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl libcommon-sense-perl libdevel-mat-dumper-perl . ANY . -m "Rebuild against perlapi-5.32.1." --extra-depends 'perl-base (>= 5.32.1)'

Scheduled.

Paul

[toc] | [prev] | [next] | [standalone]

#1045981

On Tue, Feb 02, 2021 at 09:08:28AM +0100, Paul Gevers wrote:
> Hi,
> 
> On 02-02-2021 08:47, Dominic Hargreaves wrote:
> > Please rebuild these packages as discussed:
> > 
> > $ wb nmu libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl libcommon-sense-perl libdevel-mat-dumper-perl . ANY . -m "Rebuild against perlapi-5.32.1." --extra-depends 'perl-base (>= 5.32.1)'

Thanks!

[toc] | [prev] | [next] | [standalone]

#1045190

On Thu, Jan 28, 2021 at 10:21:21PM +0100, Paul Gevers wrote:
> Hi Dominic,
> 
> On 28-01-2021 22:05, Dominic Hargreaves wrote:
> >>> 5.32.1 would need a binnmu of a few leaf packages
> >>> (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl
> >>> libcommon-sense-perl) as usual.
> >>
> >> Just to be clear, these binNMU's would be needed too if we would go for
> >> the cherry-pick option?
> > 
> > No, the binaries relate to a change of upstream version number
> > which ends up being encoded in these packages. If we cherry pick
> > fixes, the binNMUs wouldn't be needed.
> 
> But then, that relation is strictly speaking too tight? Is that
> something that can be improved (without jumping through hoops)? Maybe
> not for this time, but for future changes. Normally perl packages look
> for the perl-something-api right? Which would make it clear that this is
> no transition.

There's a reason for each of them of course.

libpar-packer-perl (#551356) would definitely involve jumping through
hoops.  It's the worst one of the four I think and really requires a
tight dependency.

The version skew warning in libdevel-cover-perl (#562214) could probably 
be patched away easily, but that seems a bit risky to me. Presumably
upstream has a reason for the check. I'm not sure if we've ever asked
though, and OTOH autopkgtest runs should notice if the newer Perl version
breaks something.

For libcommon-sense-perl, I quote #722332:

> Not sure if all the internals that common::sense fiddles with are under
> the 'no ABI changes in minor Perl version updates' promise. I suspect they
> are, but we might still be best off rebuilding it even for minor updates.

libclass-xsaccessor-perl only has this changelog entry:

  * Add dependency on same upstream version of perl to make sure
    #define PERL_CORE never breaks things.
  [...]
   -- Ansgar Burchardt <ansgar@43-1.org>  Wed, 18 Aug 2010 13:21:04 +0900

Not sure if that one could be relaxed but keeping it tight seems prudent 
to me.

As Dominic said, the related binNMUs have not been much of an issue in 
the past.
-- 
Niko Tyni   ntyni@debian.org

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web