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 wrong here. 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. Helmut _______________________________________________ Help-libidn mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-libidn
