Bug#890791: stretch-pu: package dpkg/1.18.25

[Guillem Jover]

Hi!

On Sun, 2018-06-24 at 16:34:53 +0100, Adam D. Barratt wrote:
> Control: tags -1 = stretch confirmed
> 
> On Sun, 2018-02-18 at 22:26 +0100, Guillem Jover wrote:
> > I'd like to update dpkg in stretch. This includes several fixes for
> > documentation, regressions, misbheavior, minor security issues, and
> > a new arch definition so that DAK can accept packages using it. The
> > fixes have been in sid/buster for a while now.
> 
> With apologies for the delay in getting back to this again, please feel
> free to go ahead with the upload, so we can make sure to get this in
> for 9.5.

Thanks, I've started rechecking the branch, and preparing the release
process. To minimize string translation fuzz, I'm taking the strings
from master. I'll run this again over the functional test suite and
upload in a few hours during the morning.

Regards,
Guillem

Bug#890791: stretch-pu: package dpkg/1.18.25

[Adam D. Barratt]

Control: tags -1 = stretch confirmed

On Sun, 2018-02-18 at 22:26 +0100, Guillem Jover wrote:
> I'd like to update dpkg in stretch. This includes several fixes for
> documentation, regressions, misbheavior, minor security issues, and
> a new arch definition so that DAK can accept packages using it. The
> fixes have been in sid/buster for a while now.

With apologies for the delay in getting back to this again, please feel
free to go ahead with the upload, so we can make sure to get this in
for 9.5.

(I realise there's a slight irony, but a quick upload would be
appreciated, so we can get as much testing as possible before the -
hopefully quite soon - freeze for 9.5.)

Regards,

Adam

Processed: Re: Bug#890791: stretch-pu: package dpkg/1.18.25

[Debian Bug Tracking System]

Processing control commands:

> tags -1 = stretch confirmed
Bug #890791 [release.debian.org] stretch-pu: package dpkg/1.18.25
Added tag(s) confirmed.

-- 
890791: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890791
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#890791: stretch-pu: package dpkg/1.18.25

[Vagrant Cascadian]

On 2018-05-12, Karsten Merker wrote:
> On Sun, Apr 22, 2018 at 12:39:42AM +0200, Manuel A. Fernandez Montecelo wrote:
>> 2018-04-20 1:52 GMT+02:00 Guillem Jover :
>> > On Wed, 2018-02-28 at 18:45:49 +, Adam D. Barratt wrote:
>> >> On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote:
>> >> > 2018-02-18 22:26 Guillem Jover:
>> >> > > I'd like to update dpkg in stretch. This includes several fixes for
>> >> > > documentation, regressions, misbheavior, minor security issues, and
>> >> > > a new arch definition so that DAK can accept packages using it. The
>> >> > > fixes have been in sid/buster for a while now.
>> >> >
>> >> > We depend on this version being accepted and installed in the systems
>> >> > where DAK lives to learn about the new architecture.  After that,
>> >> > several other packages can add support for the architecture, without
>> >> > receiving an automatic reject when uploaded.
>> >> >
>> >> > It would be great if this update could enter in the next stable
>> >> > update, so we can make progress on that front.
>> >
>> >> We've been discussing this amongst the SRMs and are quite wary of a
>> >> dpkg update this close to the p-u freeze. We appreciate that the
>> >> changes individually seem self-contained but would like to have an
>> >> update of such a key package able to be tested more than is feasible in
>> >> the time available.
>> >>
>> >> (On a related note, in practical terms it's very unlikely that there
>> >> would be sufficient time to get the new strings that are introduced
>> >> translated.)
>> >
>> > Is there perhaps anything you are waiting for me to do here?
>> >
>> > For the strings I realized afterwards I can take the ones from sid.
>> > I've not yet checked how many, or if I'd really need a call for
>> > translation, but I'd rather do that only after I know which parts you
>> > are going to accept. :) But TBH, this being gettext I'm not sure it
>> > matters that much, as only those strings might end up not being
>> > translated and dpkg does not have 100% coverage for all languages
>> > anyway. :)
> [...]
>> So in the 2+ months since that original request, we went from
>> scattered packages outside the Debian infrastructure to having a port
>> in debian-ports infra, with >60% of packages built.
>> 
>> Unfortunately, important packages like binutils, glibc or linux-* have
>> to stay in the separate "unreleased" suite for that reason, so the
>> lack of support in dak for riscv64 is causing us to do this extra
>> work, which would be otherwise unneeded
>
> To add some further information: having to always manually build
> and upload a number of otherwise perfectly working essential
> riscv64 packages like glibc to unreleased due to the missing
> dpkg/stable update doesn't only cause unnecessary additional work
> for the riscv64 porters but also poses practical problems for
> package maintainers trying to sort out portability issues as they
> cannot simply debootstrap a current riscv64 chroot (and therefore
> easily use pbuilder) because debootstrap cannot handle pulling
> the base system from more than one suite (unstable+unreleased in
> this case).
>
> Previous stretch point releases have been published every 2.5-3
> months, and since the 9.4 release more than two months have
> passed already, so I would again like to ask the stable release
> managers what exactly they require to be done for the proposed
> dpkg update to be accepted into the 9.5 release.  Guillem had
> asked a similar question already three weeks ago (see above), but
> has AFAICS received no reply to it.  I would really like to avoid
> the dpkg/stable update necessary for proper riscv64 support being
> pushed back yet another release cycle because of communication
> issues...

I hear mumblings of preparation for the next stable point release, and
so wondering if there's any chance to get the dpkg patches necessary to
enable riscv64 in dak before that happens?

I had the impression the riscv64 patch of the patch was rather trivial.

The riscv64 port has been hovering around the 80% mark for built
packages, which is pretty exciting to see, and would be nice to keep
that momentum going!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#890791: stretch-pu: package dpkg/1.18.25

[Karsten Merker]

On Sun, Apr 22, 2018 at 12:39:42AM +0200, Manuel A. Fernandez Montecelo wrote:
> 2018-04-20 1:52 GMT+02:00 Guillem Jover :
> > On Wed, 2018-02-28 at 18:45:49 +, Adam D. Barratt wrote:
> >> On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote:
> >> > 2018-02-18 22:26 Guillem Jover:
> >> > > I'd like to update dpkg in stretch. This includes several fixes for
> >> > > documentation, regressions, misbheavior, minor security issues, and
> >> > > a new arch definition so that DAK can accept packages using it. The
> >> > > fixes have been in sid/buster for a while now.
> >> >
> >> > We depend on this version being accepted and installed in the systems
> >> > where DAK lives to learn about the new architecture.  After that,
> >> > several other packages can add support for the architecture, without
> >> > receiving an automatic reject when uploaded.
> >> >
> >> > It would be great if this update could enter in the next stable
> >> > update, so we can make progress on that front.
> >
> >> We've been discussing this amongst the SRMs and are quite wary of a
> >> dpkg update this close to the p-u freeze. We appreciate that the
> >> changes individually seem self-contained but would like to have an
> >> update of such a key package able to be tested more than is feasible in
> >> the time available.
> >>
> >> (On a related note, in practical terms it's very unlikely that there
> >> would be sufficient time to get the new strings that are introduced
> >> translated.)
> >
> > Is there perhaps anything you are waiting for me to do here?
> >
> > For the strings I realized afterwards I can take the ones from sid.
> > I've not yet checked how many, or if I'd really need a call for
> > translation, but I'd rather do that only after I know which parts you
> > are going to accept. :) But TBH, this being gettext I'm not sure it
> > matters that much, as only those strings might end up not being
> > translated and dpkg does not have 100% coverage for all languages
> > anyway. :)
[...]
> So in the 2+ months since that original request, we went from
> scattered packages outside the Debian infrastructure to having a port
> in debian-ports infra, with >60% of packages built.
> 
> Unfortunately, important packages like binutils, glibc or linux-* have
> to stay in the separate "unreleased" suite for that reason, so the
> lack of support in dak for riscv64 is causing us to do this extra
> work, which would be otherwise unneeded

To add some further information: having to always manually build
and upload a number of otherwise perfectly working essential
riscv64 packages like glibc to unreleased due to the missing
dpkg/stable update doesn't only cause unnecessary additional work
for the riscv64 porters but also poses practical problems for
package maintainers trying to sort out portability issues as they
cannot simply debootstrap a current riscv64 chroot (and therefore
easily use pbuilder) because debootstrap cannot handle pulling
the base system from more than one suite (unstable+unreleased in
this case).

Previous stretch point releases have been published every 2.5-3
months, and since the 9.4 release more than two months have
passed already, so I would again like to ask the stable release
managers what exactly they require to be done for the proposed
dpkg update to be accepted into the 9.5 release.  Guillem had
asked a similar question already three weeks ago (see above), but
has AFAICS received no reply to it.  I would really like to avoid
the dpkg/stable update necessary for proper riscv64 support being
pushed back yet another release cycle because of communication
issues...

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#890791: stretch-pu: package dpkg/1.18.25

[Manuel A. Fernandez Montecelo]

Hi,

2018-04-20 1:52 GMT+02:00 Guillem Jover :
> Hi!
>
> On Wed, 2018-02-28 at 18:45:49 +, Adam D. Barratt wrote:
>> On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote:
>> > 2018-02-18 22:26 Guillem Jover:
>> > > I'd like to update dpkg in stretch. This includes several fixes for
>> > > documentation, regressions, misbheavior, minor security issues, and
>> > > a new arch definition so that DAK can accept packages using it. The
>> > > fixes have been in sid/buster for a while now.
>> >
>> > We depend on this version being accepted and installed in the systems
>> > where DAK lives to learn about the new architecture.  After that,
>> > several other packages can add support for the architecture, without
>> > receiving an automatic reject when uploaded.
>> >
>> > It would be great if this update could enter in the next stable
>> > update, so we can make progress on that front.
>
>> We've been discussing this amongst the SRMs and are quite wary of a
>> dpkg update this close to the p-u freeze. We appreciate that the
>> changes individually seem self-contained but would like to have an
>> update of such a key package able to be tested more than is feasible in
>> the time available.
>>
>> (On a related note, in practical terms it's very unlikely that there
>> would be sufficient time to get the new strings that are introduced
>> translated.)
>
> Is there perhaps anything you are waiting for me to do here?
>
> For the strings I realized afterwards I can take the ones from sid.
> I've not yet checked how many, or if I'd really need a call for
> translation, but I'd rather do that only after I know which parts you
> are going to accept. :) But TBH, this being gettext I'm not sure it
> matters that much, as only those strings might end up not being
> translated and dpkg does not have 100% coverage for all languages
> anyway. :)

Thanks Guillem.

So in the 2+ months since that original request, we went from
scattered packages outside the Debian infrastructure to having a port
in debian-ports infra, with >60% of packages built.

Unfortunately, important packages like binutils, glibc or linux-* have
to stay in the separate "unreleased" suite for that reason, so the
lack of support in dak for riscv64 is causing us to do this extra
work, which would be otherwise unneeded

It would be very nice if this update could move to stable-updates to
unblock the situation in a few weeks/months time.


Thanks!
-- 
Manuel A. Fernandez Montecelo 

Bug#890791: stretch-pu: package dpkg/1.18.25

[Guillem Jover]

Hi!

On Wed, 2018-02-28 at 18:45:49 +, Adam D. Barratt wrote:
> On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote:
> > 2018-02-18 22:26 Guillem Jover:
> > > I'd like to update dpkg in stretch. This includes several fixes for
> > > documentation, regressions, misbheavior, minor security issues, and
> > > a new arch definition so that DAK can accept packages using it. The
> > > fixes have been in sid/buster for a while now.
> > 
> > We depend on this version being accepted and installed in the systems
> > where DAK lives to learn about the new architecture.  After that,
> > several other packages can add support for the architecture, without
> > receiving an automatic reject when uploaded.
> > 
> > It would be great if this update could enter in the next stable
> > update, so we can make progress on that front.

> We've been discussing this amongst the SRMs and are quite wary of a
> dpkg update this close to the p-u freeze. We appreciate that the
> changes individually seem self-contained but would like to have an
> update of such a key package able to be tested more than is feasible in
> the time available.
> 
> (On a related note, in practical terms it's very unlikely that there
> would be sufficient time to get the new strings that are introduced 
> translated.)

Is there perhaps anything you are waiting for me to do here?

For the strings I realized afterwards I can take the ones from sid.
I've not yet checked how many, or if I'd really need a call for
translation, but I'd rather do that only after I know which parts you
are going to accept. :) But TBH, this being gettext I'm not sure it
matters that much, as only those strings might end up not being
translated and dpkg does not have 100% coverage for all languages
anyway. :)

Thanks,
Guillem

Bug#890791: stretch-pu: package dpkg/1.18.25

[Manuel A. Fernandez Montecelo]

Hi,

2018-03-20 7:33 GMT+01:00 Karsten Merker :
> On Wed, Feb 28, 2018 at 06:45:49PM +, Adam D. Barratt wrote:
>>
>> We've been discussing this amongst the SRMs and are quite wary of a
>> dpkg update this close to the p-u freeze. We appreciate that the
>> changes individually seem self-contained but would like to have an
>> update of such a key package able to be tested more than is feasible in
>> the time available.
>> [...]
>> We understand that this is inconvenient for the riscv porters, so are
>> exploring whether it would be possible to have the dak support made
>> available via p-u after the upcoming point release.
>
> Hello,
>
> I wanted to kindly ask whether there are any news on this topic
> and whether there is anything that the RISC-V porters can do
> to help.

I pinged Guillem today, basically he's waiting for an ack of the
.debdiff before uploading to proposed-updates.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#890791: stretch-pu: package dpkg/1.18.25

[Karsten Merker]

On Wed, Feb 28, 2018 at 06:45:49PM +, Adam D. Barratt wrote:
> On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote:
> [..]
> > 2018-02-18 22:26 Guillem Jover:
> [...]
> > > I'd like to update dpkg in stretch. This includes several fixes for
> > > documentation, regressions, misbheavior, minor security issues, and
> > > a new arch definition so that DAK can accept packages using it. The
> > > fixes have been in sid/buster for a while now.
> > 
> > We depend on this version being accepted and installed in the systems
> > where DAK lives to learn about the new architecture.  After that,
> > several other packages can add support for the architecture, without
> > receiving an automatic reject when uploaded.
> > 
> > It would be great if this update could enter in the next stable
> > update, so we can make progress on that front.
> 
> We've been discussing this amongst the SRMs and are quite wary of a
> dpkg update this close to the p-u freeze. We appreciate that the
> changes individually seem self-contained but would like to have an
> update of such a key package able to be tested more than is feasible in
> the time available.
> 
> (On a related note, in practical terms it's very unlikely that there
> would be sufficient time to get the new strings that are introduced 
> translated.)
> 
> We understand that this is inconvenient for the riscv porters, so are
> exploring whether it would be possible to have the dak support made
> available via p-u after the upcoming point release.

Hello,

I wanted to kindly ask whether there are any news on this topic
and whether there is anything that the RISC-V porters can do 
to help.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#890791: stretch-pu: package dpkg/1.18.25

[Adam D. Barratt]

On Wed, 2018-02-28 at 20:11 +0100, Manuel A. Fernandez Montecelo wrote:
> 2018-02-28 19:45 GMT+01:00 Adam D. Barratt 
> :
> > We understand that this is inconvenient for the riscv porters, so
> > are
> > exploring whether it would be possible to have the dak support made
> > available via p-u after the upcoming point release.
> 
> I'd appreciate if you can find some alternative solution for the
> RISC-V support, waiting to the next stable update is a bit too much,
> and still there's no guarantee that it'll be accepted then.

For the record, I don't foresee any issues with getting the RISC-V
support accepted, it's simply unfortunate timing for this point
release.

Regards,

Adam

Bug#890791: stretch-pu: package dpkg/1.18.25

[Manuel A. Fernandez Montecelo]

2018-02-28 19:45 GMT+01:00 Adam D. Barratt :
> We understand that this is inconvenient for the riscv porters, so are
> exploring whether it would be possible to have the dak support made
> available via p-u after the upcoming point release.

I'd appreciate if you can find some alternative solution for the
RISC-V support, waiting to the next stable update is a bit too much,
and still there's no guarantee that it'll be accepted then.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#890791: stretch-pu: package dpkg/1.18.25

[Adam D. Barratt]

Hi,

On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote:
[..]
> 2018-02-18 22:26 Guillem Jover:
[...]
> > I'd like to update dpkg in stretch. This includes several fixes for
> > documentation, regressions, misbheavior, minor security issues, and
> > a new arch definition so that DAK can accept packages using it. The
> > fixes have been in sid/buster for a while now.
> 
> We depend on this version being accepted and installed in the systems
> where DAK lives to learn about the new architecture.  After that,
> several other packages can add support for the architecture, without
> receiving an automatic reject when uploaded.
> 
> It would be great if this update could enter in the next stable
> update, so we can make progress on that front.

We've been discussing this amongst the SRMs and are quite wary of a
dpkg update this close to the p-u freeze. We appreciate that the
changes individually seem self-contained but would like to have an
update of such a key package able to be tested more than is feasible in
the time available.

(On a related note, in practical terms it's very unlikely that there
would be sufficient time to get the new strings that are introduced 
translated.)

We understand that this is inconvenient for the riscv porters, so are
exploring whether it would be possible to have the dak support made
available via p-u after the upcoming point release.

Regards,

Adam

Bug#890791: stretch-pu: package dpkg/1.18.25

[Manuel A. Fernandez Montecelo]

block 886440 by 890791
block 888793 by 890791
block 889841 by 890791
stop


Hello,

2018-02-18 22:26 Guillem Jover:

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi!

I'd like to update dpkg in stretch. This includes several fixes for
documentation, regressions, misbheavior, minor security issues, and
a new arch definition so that DAK can accept packages using it. The
fixes have been in sid/buster for a while now.


We depend on this version being accepted and installed in the systems
where DAK lives to learn about the new architecture.  After that,
several other packages can add support for the architecture, without
receiving an automatic reject when uploaded.

It would be great if this update could enter in the next stable update,
so we can make progress on that front.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#890791: stretch-pu: package dpkg/1.18.25

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi!

I'd like to update dpkg in stretch. This includes several fixes for
documentation, regressions, misbheavior, minor security issues, and
a new arch definition so that DAK can accept packages using it. The
fixes have been in sid/buster for a while now.

Attached the git diff 1.18.24..next/1.18.x (excluding translation
updates). Also given that unfortunately this time around there are
several string changes, I might need to do a translation round before
the upload, if the changes get approved.

Also available as a branch at
.

Thanks,
Guillem
diff --git a/data/cputable b/data/cputable
index a2bd7d687..9f2a8e0e4 100644
--- a/data/cputable
+++ b/data/cputable
@@ -41,6 +41,7 @@ powerpc		powerpc		(powerpc|ppc)		32	big
 powerpcel	powerpcle	powerpcle		32	little
 ppc64		powerpc64	(powerpc|ppc)64		64	big
 ppc64el		powerpc64le	powerpc64le		64	little
+riscv64		riscv64		riscv64			64	little
 s390		s390		s390			32	big
 s390x		s390x		s390x			64	big
 sh3		sh3		sh3			32	little
diff --git a/debian/changelog b/debian/changelog
index 26a8b14cd..64d09cb40 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,44 @@
+dpkg (1.18.25) stretch; urgency=medium
+
+  [ Guillem Jover ]
+  * Parse start-stop-daemon usernames and groupnames starting with digits in
+-u and -c correctly. Reported by Bodo Eggert <7egg...@online.de>.
+  * Always use the binary version for the .buildinfo filename in
+dpkg-genbuildinfo. Reported by Raphaël Hertzog .
+Closes: #869236
+  * Fix integer overflow in deb(5) format version parser.
+Closes: #868356
+  * Fix directory traversal with dpkg-deb --raw-extract, by guaranteeing
+that the DEBIAN pathname does not exist. Closes: #879982
+Reported by Jakub Wilk .
+  * Do not try to recompute hashes for the .dsc file when signing binary-only
+builds in dpkg-buildpackage. Reported by Ximin Luo .
+  * Architecture support:
+- Add support for riscv64 CPU. Closes: #822914
+  Thanks to Manuel A. Fernandez Montecelo 
+  * Perl modules:
+- Do not normalize args past a passthrough stop word in Dpkg::Getopt.
+  Some commands pass some arguments through to another command, and
+  those must not be normalized as that might break their invocation.
+  Reported by Helmut Grohne .
+  * Documentation:
+- Update buildinfo information in dpkg-buildpackage man page to match
+  the current implementation.
+- Use correct name for archname validator value in dpkg(1) man page.
+  Reported by Niels Thykier   Sun, 18 Feb 2018 22:15:36 +0100
+
 dpkg (1.18.24) unstable; urgency=medium
 
   [ Guillem Jover ]
diff --git a/debian/control b/debian/control
index f2cd11766..1b20f8f04 100644
--- a/debian/control
+++ b/debian/control
@@ -14,6 +14,8 @@ Build-Depends:
  dpkg-dev (>= 1.17.14),
  debhelper (>= 9.20141010),
  pkg-config,
+# Needed for --clamp-mtime in dpkg-source -b.
+ tar (>= 1.28-1) ,
 # Needed for --add-location.
  gettext (>= 0.19),
 # Needed for --porefs.
diff --git a/dpkg-deb/dpkg-deb.h b/dpkg-deb/dpkg-deb.h
index bc90c271e..54a5d71fd 100644
--- a/dpkg-deb/dpkg-deb.h
+++ b/dpkg-deb/dpkg-deb.h
@@ -53,6 +53,8 @@ enum dpkg_tar_options {
 	DPKG_TAR_PERMS = DPKG_BIT(2),
 	/** Do not set tar mtime on extract. */
 	DPKG_TAR_NOMTIME = DPKG_BIT(3),
+	/** Guarantee extraction into a new directory, abort if it exists. */
+	DPKG_TAR_CREATE_DIR = DPKG_BIT(4),
 };
 
 void extracthalf(const char *debar, const char *dir,
diff --git a/dpkg-deb/extract.c b/dpkg-deb/extract.c
index b1d66ee15..f91d18ad8 100644
--- a/dpkg-deb/extract.c
+++ b/dpkg-deb/extract.c
@@ -336,15 +336,15 @@ extracthalf(const char *debar, const char *dir,
   unsetenv("TAR_OPTIONS");
 
   if (dir) {
-if (chdir(dir)) {
-  if (errno != ENOENT)
-ohshite(_("failed to chdir to directory"));
-
-  if (mkdir(dir, 0777))
+if (mkdir(dir, 0777) != 0) {
+  if (errno != EEXIST)
 ohshite(_("failed to create directory"));
-  if (chdir(dir))
-ohshite(_("failed to chdir to directory after creating it"));
+
+  if (taroption & DPKG_TAR_CREATE_DIR)
+ohshite(_("unexpected pre-existing pathname %s"), dir);
 }
+if (chdir(dir) != 0)
+  ohshite(_("failed to chdir to directory"));
   }