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

Reply via email to