Hi Simon On 2022-08-29 08:09:59 +0200, Simon Josefsson wrote: > I could upload a real version too, maybe that is faster? Can do today unless > someone objects.
The rebuilds were scheduled yesterday. See https://buildd.debian.org/status/package.php?p=libidn2 Cheers > > /Simon > > > 28 aug. 2022 kl. 14:40 skrev Johannes Schauer Marin Rodrigues > > <jo...@debian.org>: > > > > Quoting Cyril Brulebois (2022-08-28 14:20:48) > >> Johannes Schauer Marin Rodrigues <jo...@debian.org> (2022-08-28): > >>> The current version of libidn2-0 in unstable still wrongly depends on > >>> sgml-base. A rebuild of src:libidn2 against the version of debhelper > >>> that is currently in the archive will fix this problem. > >> > >> Sure, that's the part I agree with. > >> > >>> I added you to CC because you commented on #1015263 saying "This breaks > >>> d-i builds". The thing that doesn't have a udeb is sgml-base (which you > >>> pointed out in the same message). > >> > >> Let's backpedal a bit, my message had: > >> > >>> Judging by the current list of `apt-cache rdepends sgml-base`, this > >>> problem has already spread quite a bit. > >> > >> This breaks d-i builds, (at least) via libnl udebs picking up a > >> dependency on sgml-base, which doesn't exist in a udeb context. > >> > >> There, “this” = buggy sgml-base dependency spreading, which broke d-i > >> builds *via libnbl udebs* (which was worked around); that wasn't meant > >> to mean that libidn2 itself was breaking d-i builds. It can't, as it > >> doesn't build udebs, so it's no factor. > >> > >> Hope that clarifies. > > > > Ah cool, thanks! Yes, then d-i is not a reason at all to binNMU src:libidn2. > > > > The wrong dependency on sgml-base remains as a reason to do it. > > > > Thank you! > > > > cheers, josch -- Sebastian Ramacher