[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bug#881915: libidn FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no lo
Bug#881915: libidn FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available
Thu, 23 Nov 2017 15:37:59 +0100
On Thu, Nov 23, 2017 at 11:32:06AM +0000, Simon McVittie wrote:
> It looks as though plain gtkdocize replaces gtk-doc.make with a symbolic
> link, which dh-autoreconf won't delete (bug filed), breaking the ability
> to build twice in a row; so gtkdocize --copy (which works like I expected)
> is probably better, at least until/unless dh-autoreconf can be taught
> to remove files that were replaced with a symlink. I've changed flatpak
> in git to use gtkdocize --copy.
Thank you for your attention to detail.
> Helmut: similarly, is there a reason that I'm not seeing why explicitly
> removing gtk-doc.make before gtkdocize was necessary, or were you only
> doing that as a way to be completely sure that the old one wasn't used, or
> was it a workaround for gtkdocize turning the plain file into a symlink?
I was under the impression that my first attempt was just running
gtkdocize without removing gtk-doc.make and that didn't work. I might be
Call me careless, but I am a bit annoyed by libidn2 now, as it keeps
breaking in new ways. I was in need of a patch to make bootstrap builds
proceed, so I only looked as far as making it barely build. The bug is
supposedly fixed upstream, so I expected it to be fixed with a new
upstream release rather than applying my patch.
> I can confirm that using the same approach as in src:flatpak (but with
> gtkdocize --copy) makes libidn2 build correctly, producing binaries
> that should be functionally identical to what the maintainer uploaded
> (diffoscope reports only trivial differences). Patches attached.
Please NMU. This bug is very annoying for cross building due to the
version skews induced from the amd64 upload.