Re: Bug#890791: stretch-pu: package dpkg/1.18.25
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 <guillem@debian.org>:
> > On Wed, 2018-02-28 at 18:45:49 +0000, 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.
Reply to: