Bug#915948: dak: arch:all lag from amd64 causes old binaries to disappear?
> The source-only upload of perl_5.28.1-3 yesterday resulted in a mirror
> push where the new arch:any binaries (perl, perl-base etc.) were in the
> amd64 Packages list, but the arch:all ones (perl-modules-5.28, perl-doc
> etc.) were missing altogether.
This bug hit postgresql-common yesterday after the 144+nmu1 upload.
Only postgresql-server-dev-all:amd64 was present in the sid Packages
file, all arch:all packages from that source (postgresql-common and
others) were missing.
Britney was complaining pretty loudly that the binaries were missing.
One dinstall later things were in order again.
rmadison reported the packages present during that time ("source, all"),
I think, but possibly that was already after the next dinstall, before
deb.debian.org had been updated.
Christoph
Bug#915948: dak: arch:all lag from amd64 causes old binaries to disappear?
Control: severity -1 important On 2018-12-08 11:19 +0200, Niko Tyni wrote: > Package: ftp.debian.org > User: ftp.debian@packages.debian.org > Usertags: dak > > The source-only upload of perl_5.28.1-3 yesterday resulted in a mirror > push where the new arch:any binaries (perl, perl-base etc.) were in the > amd64 Packages list, but the arch:all ones (perl-modules-5.28, perl-doc > etc.) were missing altogether. This caused issues for people upgrading > their chroots, as for instance build-essential was not installable > anymore. The situation was fixed with the next mirror push. Upgrading chroots is not so much of a problem (perl will just be held back), but creating new ones is problematic (or, as in the above case, impossible). > The problem is visible in > > > http://snapshot.debian.org/archive/debian/20181207T214432Z/dists/sid/main/binary-amd64/Packages.xz Another example is https://snapshot.debian.org/archive/debian/20180717T222551Z/dists/sid/main/binary-amd64/Packages.xz where there is no ncurses-base present. This is much worse than the perl example above, since debootstrap will happily create a chroot lacking the ncurses-base package, but without any terminfo files all kind of breakages will happen there. :-/ For those who want to see for themselves, # debootstrap --variant=minbase sid /whatever/dir https://snapshot.debian.org/archive/debian/20180717T222551Z Then chroot into /whatever/dir, even bash is already "interesting" to use with backspace and delete keys producing funny results. > I assume this happened because the amd64 builds were finished three > hours before the 'all' builds, and the mirror push happened in between. > > ISTR there at least used to be a check where arch:all binaries are not > exposed before the corresponding arch:any ones are built, but it looks > like the reverse is not true? In any case, even the old versions (5.28.1-2 > in this case) of the arch:all binaries disappearing seems incorrect to me? Cheers, Sven
Bug#915948: dak: arch:all lag from amd64 causes old binaries to disappear?
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: dak The source-only upload of perl_5.28.1-3 yesterday resulted in a mirror push where the new arch:any binaries (perl, perl-base etc.) were in the amd64 Packages list, but the arch:all ones (perl-modules-5.28, perl-doc etc.) were missing altogether. This caused issues for people upgrading their chroots, as for instance build-essential was not installable anymore. The situation was fixed with the next mirror push. The problem is visible in http://snapshot.debian.org/archive/debian/20181207T214432Z/dists/sid/main/binary-amd64/Packages.xz I assume this happened because the amd64 builds were finished three hours before the 'all' builds, and the mirror push happened in between. ISTR there at least used to be a check where arch:all binaries are not exposed before the corresponding arch:any ones are built, but it looks like the reverse is not true? In any case, even the old versions (5.28.1-2 in this case) of the arch:all binaries disappearing seems incorrect to me? Thanks for your work on Debian, -- Niko Tyni nt...@debian.org
