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 <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... 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
Attachment:
signature.asc
Description: PGP signature