Bug#961443: buster-pu: package perl/5.28.2

[Dominic Hargreaves]

Control: tags -1 - moreinfo

On Thu, Jun 04, 2020 at 09:44:29AM +0100, Dominic Hargreaves wrote:
> Control: tags -1 + moreinfo
> 
> On Tue, Jun 02, 2020 at 12:14:27AM +0100, Dominic Hargreaves wrote:
> > Further to the above, we now have a no-dsa security issue to push out
> > to buster (and stretch, but we prefer a more traditional approach there
> > because of the relative size of changes and age of the release).
> > 
> > The security issues in question are tracked at #962005.
> > 
> > I attach the additional diff between 5.28.2 and 5.28.3 (which was
> > purely a security release) - again, excluding doc and version churn.
> > 
> > Please do let me know if you would be okay with this approach, and
> > we can get the ball rolling.
> 
> We're no longer proposing this approach for the immediate update
> pending concerns around smooth upgrades (cf #962138). We expect this
> an be fixable but in the meantime I'm temporarily withdrawing the
> proposal.
> 
> Expect to see a regular point release proposal with cherry-picks
> shortly (for both buster and stretch).

Okay, we seem to have a stable fix for this issue (as of 5.30.3-4),
so I think we can put the new version bump proposal for buster back on
the table.

What do you think?

Cheers
Dominic

Bug#961443: buster-pu: package perl/5.28.2

[Dominic Hargreaves]

Control: tags -1 + moreinfo

On Tue, Jun 02, 2020 at 12:14:27AM +0100, Dominic Hargreaves wrote:
> Further to the above, we now have a no-dsa security issue to push out
> to buster (and stretch, but we prefer a more traditional approach there
> because of the relative size of changes and age of the release).
> 
> The security issues in question are tracked at #962005.
> 
> I attach the additional diff between 5.28.2 and 5.28.3 (which was
> purely a security release) - again, excluding doc and version churn.
> 
> Please do let me know if you would be okay with this approach, and
> we can get the ball rolling.

We're no longer proposing this approach for the immediate update
pending concerns around smooth upgrades (cf #962138). We expect this
an be fixable but in the meantime I'm temporarily withdrawing the
proposal.

Expect to see a regular point release proposal with cherry-picks
shortly (for both buster and stretch).

Best
Dominic

Bug#961443: buster-pu: package perl/5.28.2

[Dominic Hargreaves]

Control: retitle -1 buster-pu: package perl/5.28.3

On Sun, May 24, 2020 at 04:58:31PM +0100, Dominic Hargreaves wrote:
> The perl interpreter team would like to move to a model where we
> attempt to keep Debian stable releases more or less in sync with
> upstream maint branches - which are conservatively maintained along the
> lines of the policies here, which match pretty well with Debian's:
> 
> https://perldoc.perl.org/5.30.0/perlpolicy.html#MAINTENANCE-BRANCHES
> 
> In the past we have done a more or less complete import of new
> upstream releases (excluding patches which do not affect Debian) whilst
> keeping the previous version number intact[1]. This was done out of
> an abundance of caution (not knowing the risks of the upstream version
> number changing in stable) but, after a few more years of relatively
> pain free transitions in unstable, we think that the cost/risk of the
> manual cherry-picking procedure, together with the lack of transparency
> to users about which version they are running, outweighs the potential
> benefits of keeping the upstream version unchanged.
> 
> Therefore, we propose to apply the 5.28.2 release to buster at the next
> opportunity (is the next stable update scheduled?)
> 
> A tentative branch is at [2], and an abbreviated patch (excluding
> churn caused by version numbers and developer documentation) and
> separately, the upstream changelog, is attached.
> 
> One complicating factor would be the need to binnmu four packages
> that are sensitive to the upstream version number as part of the
> stable update, as we routinely do for updates in unstable. Beyond that,
> we don't anticipate any major issues. We would do a complete test
> rebuild of perl-related packages in advance to catch any other
> issues (an learning point from the update in [1]).
> 
> Thanks for your consideration.
> 
> [1] 
> [2] 
> 

Further to the above, we now have a no-dsa security issue to push out
to buster (and stretch, but we prefer a more traditional approach there
because of the relative size of changes and age of the release).

The security issues in question are tracked at #962005.

I attach the additional diff between 5.28.2 and 5.28.3 (which was
purely a security release) - again, excluding doc and version churn.

Please do let me know if you would be okay with this approach, and
we can get the ball rolling.
diff -urN perl-5.28.2/dist/Module-CoreList/Changes perl-5.28.3/dist/Module-CoreList/Changes
--- perl-5.28.2/dist/Module-CoreList/Changes	2019-03-28 22:14:50.0 +
+++ perl-5.28.3/dist/Module-CoreList/Changes	2020-05-14 16:50:06.0 +0100
@@ -1,3 +1,54 @@
+5.20200601_28
+  - Updated for v5.28.3
+
+5.20200428
+  - Updated for v5.31.11
+
+5.20200320
+  - Updated for v5.31.10
+
+5.20200314
+  - Updated for v5.30.2
+
+5.20200220
+  - Updated for v5.31.9
+
+5.20200120
+  - Updated for v5.31.8
+
+5.20191220
+  - Updated for v5.31.7
+
+5.20191120
+  - Updated for v5.31.6
+
+5.20191110
+  - Updated for v5.30.1
+
+5.20191020
+  - Updated for v5.31.5
+
+5.20190920
+  - Updated for v5.31.4
+
+5.20190820
+  - Updated for v5.31.3
+
+5.20190720
+  - Updated for v5.31.2
+
+5.20190620
+  - Updated for v5.31.1
+
+5.20190524
+  - Updated for v5.31.0
+
+5.20190522
+  - Updated for v5.30.0
+
+5.20190420
+  - Updated for v5.29.10
+
 5.20190419
   - Updated for v5.28.2
 
diff -urN perl-5.28.2/dist/Module-CoreList/lib/Module/CoreList/Utils.pm perl-5.28.3/dist/Module-CoreList/lib/Module/CoreList/Utils.pm
--- perl-5.28.2/dist/Module-CoreList/lib/Module/CoreList/Utils.pm	2019-04-04 21:14:49.0 +0100
+++ perl-5.28.3/dist/Module-CoreList/lib/Module/CoreList/Utils.pm	2020-05-14 17:01:48.0 +0100
@@ -4,7 +4,7 @@
 use warnings;
 use Module::CoreList;
 
-our $VERSION = '5.20190419';
+our $VERSION = '5.20200601_28';
 our %utilities;
 
 sub utilities {
@@ -1485,6 +1485,127 @@
 changed => {
 },
 removed => {
+}
+},
+5.029010 => {
+delta_from => 5.029009,
+changed => {
+},
+removed => {
+}
+},
+5.03 => {
+delta_from => 5.029010,
+changed => {
+},
+removed => {
+}
+},
+5.031000 => {
+delta_from => 5.03,
+changed => {
+},
+removed => {
+}
+},
+5.031001 => {
+delta_from => 5.031,
+changed => {
+},
+removed => {
+'podselect' => 1,
+}
+},
+5.031002 => {
+delta_from => 5.031001,
+changed => {
+},
+removed => {
+}
+},
+5.031003 => {
+delta_from => 5.031002,
+changed => {
+},
+removed => {
+}
+},
+5.031004 => {
+delta_from => 5.031003,
+changed => {
+},
+removed => {
+}
+   

Bug#961443: buster-pu: package perl/5.28.2

[Dominic Hargreaves]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
X-Debbugs-Cc: nt...@debian.org, debian-p...@lists.debian.org

Hi release team,

The perl interpreter team would like to move to a model where we
attempt to keep Debian stable releases more or less in sync with
upstream maint branches - which are conservatively maintained along the
lines of the policies here, which match pretty well with Debian's:

https://perldoc.perl.org/5.30.0/perlpolicy.html#MAINTENANCE-BRANCHES

In the past we have done a more or less complete import of new
upstream releases (excluding patches which do not affect Debian) whilst
keeping the previous version number intact[1]. This was done out of
an abundance of caution (not knowing the risks of the upstream version
number changing in stable) but, after a few more years of relatively
pain free transitions in unstable, we think that the cost/risk of the
manual cherry-picking procedure, together with the lack of transparency
to users about which version they are running, outweighs the potential
benefits of keeping the upstream version unchanged.

Therefore, we propose to apply the 5.28.2 release to buster at the next
opportunity (is the next stable update scheduled?)

A tentative branch is at [2], and an abbreviated patch (excluding
churn caused by version numbers and developer documentation) and
separately, the upstream changelog, is attached.

One complicating factor would be the need to binnmu four packages
that are sensitive to the upstream version number as part of the
stable update, as we routinely do for updates in unstable. Beyond that,
we don't anticipate any major issues. We would do a complete test
rebuild of perl-related packages in advance to catch any other
issues (an learning point from the update in [1]).

Thanks for your consideration.

[1] 
[2] 

=encoding utf8

=head1 NAME

perldelta - what is new for perl v5.28.2

=head1 DESCRIPTION

This document describes differences between the 5.28.1 release and the 5.28.2
release.

If you are upgrading from an earlier release such as 5.28.0, first read
L, which describes differences between 5.28.0 and 5.28.1.

=head1 Incompatible Changes

=head2 Any set of digits in the Common script are legal in a script run of
another script

There are several sets of digits in the Common script.  C<[0-9]> is the most
familiar.  But there are also C<[\x{FF10}-\x{FF19}]> (FULLWIDTH DIGIT ZERO -
FULLWIDTH DIGIT NINE), and several sets for use in mathematical notation, such
as the MATHEMATICAL DOUBLE-STRUCK DIGITs.  Any of these sets should be able to
appear in script runs of, say, Greek.  But the previous design overlooked all
but the ASCII digits C<[0-9]>, so the design was flawed.  This has been fixed,
so is both a bug fix and an incompatibility.

All digits in a run still have to come from the same set of ten digits.

L<[perl #133547]|https://rt.perl.org/Ticket/Display.html?id=133547>

=head1 Modules and Pragmata

=head2 Updated Modules and Pragmata

=over 4

=item *

L has been upgraded from version 5.20181129_28 to 5.20190419.

=item *

L has been upgraded from version 0.29 to 0.30.

=item *

L has been upgraded from version 3.08 to 3.08_01.

=back

=head1 Platform Support

=head2 Platform-Specific Notes

=over 4

=item Windows

The Windows Server 2003 SP1 Platform SDK build, with its early x64 compiler and
tools, was accidentally broken in Perl 5.27.9.  This has now been fixed.

=item Mac OS X

Perl's build and testing process on Mac OS X for C<-Duseshrplib> builds is now
compatible with Mac OS X System Integrity Protection (SIP).

SIP prevents binaries in F (and a few other places) being passed the
C environment variable.  For our purposes this prevents
C from being passed to the shell, which prevents that
variable being passed to the testing or build process, so running C
couldn't find F.

To work around that, the initial build of the F executable expects to
find F in the build directory, and the library path is then
adjusted during installation to point to the installed library.

L<[perl #126706]|https://rt.perl.org/Ticket/Display.html?id=126706>

=back

=head1 Selected Bug Fixes

=over 4

=item *

If an in-place edit is still in progress during global destruction and the
process exit code (as stored in C<$?>) is zero, perl will now treat the
in-place edit as successful, replacing the input file with any output produced.

This allows code like:

  perl -i -ne 'print "Foo"; last'

to replace the input file, while code like:

  perl -i -ne 'print "Foo"; die'

will not.  Partly resolves [perl #133659].

L<[perl #133659]|https://rt.perl.org/Ticket/Display.html?id=133659>

=item *

A regression in Perl 5.28 caused the following code to fail

 close(STDIN); open(CHILD, "|wc -l")'

because the child's stdin would be closed on exec.  This has now been fixed.

=item *