Debian Bug report logs - #881915
libidn FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libidn FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

Date: Thu, 16 Nov 2017 14:47:34 +0200

Source: libidn2
Version: 2.0.4-1
Severity: serious

https://buildd.debian.org/status/package.php?p=libidn2&suite=sid

...
touch scan-build.stamp
gtkdoc-mktmpl --module=libidn2 
/bin/bash: gtkdoc-mktmpl: command not found
Makefile:1259: recipe for target 'tmpl-build.stamp' failed
make[6]: *** [tmpl-build.stamp] Error 127

Message #10 received at 881915@bugs.debian.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de>

To: Adrian Bunk <bunk@debian.org>, 881915@bugs.debian.org

Subject: Re: Bug#881915: libidn FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

Date: Sat, 18 Nov 2017 09:36:58 +0100

[Message part 1 (text/plain, inline)]

Control: tags -1 + patch

On Thu, Nov 16, 2017 at 02:47:34PM +0200, Adrian Bunk wrote:
> touch scan-build.stamp
> gtkdoc-mktmpl --module=libidn2 
> /bin/bash: gtkdoc-mktmpl: command not found
> Makefile:1259: recipe for target 'tmpl-build.stamp' failed
> make[6]: *** [tmpl-build.stamp] Error 127

libidn2 does not build from source. It failed to run gtkdocize.

Helmut

[ftbfs.debdiff (text/plain, attachment)]

Message #17 received at 881915@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: Helmut Grohne <helmut@subdivi.de>, 881915@bugs.debian.org

Subject: Re: Bug#881915: libidn FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

Date: Sat, 18 Nov 2017 18:35:38 +0200

On Sat, Nov 18, 2017 at 09:36:58AM +0100, Helmut Grohne wrote:
>...
> +override_dh_autoreconf:
> +	rm -f gtk-doc.make
> +	gtkdocize
> +	dh_autoreconf
>...

The "rm -f gtk-doc.make" has to be done when cleaning,
not in autoreconf.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Message #22 received at 881915@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Adrian Bunk <bunk@debian.org>, 881915@bugs.debian.org

Cc: Helmut Grohne <helmut@subdivi.de>

Subject: Re: Bug#881915: libidn FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

Date: Thu, 23 Nov 2017 11:32:06 +0000

[Message part 1 (text/plain, inline)]

On Sat, 18 Nov 2017 at 18:35:38 +0200, Adrian Bunk wrote:
> On Sat, Nov 18, 2017 at 09:36:58AM +0100, Helmut Grohne wrote:
> >...
> > +override_dh_autoreconf:
> > +	rm -f gtk-doc.make
> > +	gtkdocize
> > +	dh_autoreconf
> >...
> 
> The "rm -f gtk-doc.make" has to be done when cleaning,
> not in autoreconf.

dh_autoreconf_clean is meant to delete whatever was changed by
dh_autoreconf if it is given a script to run instead of autoreconf,
typically either "NOCONFIGURE=1 ./autogen.sh" using upstream's autogen.sh,
or a debian/autogen.sh containing gtkdocize and autoreconf -fi. The man
page briefly mentions this method, and src:flatpak in unstable is an
example of it in use. Is that a valid approach, or is there a reason
why explicitly deleting the file during clean should be preferred?
I'd like to document whichever one is best-practice a bit more clearly.

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.

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 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.

Regards,
    smcv

[0001-Fix-FTBFS-gtkdocize-and-add-dblatex-to-Build-Depends.patch (text/x-diff, attachment)]

[0002-Run-gtkdocize-via-debian-autogen.sh.patch (text/x-diff, attachment)]

Message #27 received at 881915@bugs.debian.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de>

To: Simon McVittie <smcv@debian.org>

Cc: Adrian Bunk <bunk@debian.org>, 881915@bugs.debian.org

Subject: Re: Bug#881915: libidn FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

Date: 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
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

Message #32 received at 881915@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: Helmut Grohne <helmut@subdivi.de>, Simon McVittie <smcv@debian.org>, 881915@bugs.debian.org

Subject: Re: Bug#881915: libidn FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

Date: Thu, 23 Nov 2017 17:31:33 +0200

On Thu, Nov 23, 2017 at 03:37:59PM +0100, Helmut Grohne wrote:
>...
> Call me careless, but I am a bit annoyed by libidn2 now, as it keeps
> breaking in new ways.
>...

To be fair, there were ~ 50 packages that did FTBFS with
the new gtk-doc-tools.

The only thing special about libidn2 is that it missed the original
round of RC bugs due to being in NEW for 2.5 months.

> Helmut

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Message #37 received at 881915@bugs.debian.org (full text, mbox, reply):

From: Tim Rühsen <tim.ruehsen@gmx.de>

To: Helmut Grohne <helmut@subdivi.de>, 881915@bugs.debian.org, Simon McVittie <smcv@debian.org>

Cc: Adrian Bunk <bunk@debian.org>

Subject: Re: Bug#881915: libidn FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

Date: Fri, 24 Nov 2017 09:24:22 +0100

[Message part 1 (text/plain, inline)]

On 11/23/2017 03:37 PM, Helmut Grohne wrote:
> 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.


If it helps, I can make up a new upstream release.
Let me know if there is something that should be applied before.


With Best Regards, Tim

[signature.asc (application/pgp-signature, attachment)]

Message #42 received at 881915@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 881968@bugs.debian.org, 881915@bugs.debian.org

Cc: Helmut Grohne <helmut@subdivi.de>, Adrian Bunk <bunk@debian.org>, Andreas Beckmann <anbe@debian.org>

Subject: libidn2: NMU for FTBFS #881968 and upgrade issues #881915

Date: Fri, 24 Nov 2017 08:38:39 +0000

[Message part 1 (text/plain, inline)]

I've uploaded the attached NMU. Please note that applying the debdiff with
patch(1) is not sufficient: debian/autogen.sh needs to be executable,
which isn't represented in the diff. The git patches might be more
convenient.

These changes should also be available soon from
<https://anonscm.debian.org/cgit/users/smcv/qa/libidn2.git/>.

On Thu, 23 Nov 2017 at 17:31:33 +0200, Adrian Bunk wrote:
> The only thing special about libidn2 is that it missed the original
> round of RC bugs due to being in NEW for 2.5 months.

If the maintainer-built binaries were discarded when a NEW package
was accepted (<https://bugs.debian.org/798000>) then at least it would
have failed everywhere, avoiding cross-architecture skew. It's
unfortunate that NEW requires binary uploads for at least one
architecture.

Regards,
    smcv

[libidn2_2.0.4-1.1.diff (text/x-diff, attachment)]

[0001-Fix-FTBFS-gtkdocize-and-add-dblatex-to-Build-Depends.patch (text/x-diff, attachment)]

[0002-Run-gtkdocize-via-debian-autogen.sh.patch (text/x-diff, attachment)]

[0003-libidn2-doc-Breaks-Replaces-older-versions-of-both-l.patch (text/x-diff, attachment)]

[0004-NMU.patch (text/x-diff, attachment)]

Message #47 received at 881915@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Tim Rühsen <tim.ruehsen@gmx.de>

Cc: Helmut Grohne <helmut@subdivi.de>, 881915@bugs.debian.org, Adrian Bunk <bunk@debian.org>

Subject: Re: Bug#881915: libidn FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

Date: Fri, 24 Nov 2017 08:58:56 +0000

On Fri, 24 Nov 2017 at 09:24:22 +0100, Tim Rühsen wrote:
> On 11/23/2017 03:37 PM, Helmut Grohne wrote:
> > The bug is
> > supposedly fixed upstream, so I expected it to be fixed with a new
> > upstream release rather than applying my patch.
> 
> If it helps, I can make up a new upstream release.
> Let me know if there is something that should be applied before.

I don't think anything special needs to be done upstream now: I've changed
the Debian packaging to refresh the gtk-doc files before build, which
(if accepted by the libidn Debian maintainers) will decouple libidn from
the version of gtk-doc used when the upstream release was prepared. This is
a bit better from the point of view of ensuring Debian is self-contained
and built from "the real source code" anyway.

For future libidn releases, it might be helpful to other downstream
distributions if you could prepare the release (make dist) on a system
with gtk-doc-tools >= 1.26.

Regards,
    smcv

Message #52 received at 881915-close@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 881915-close@bugs.debian.org

Subject: Bug#881915: fixed in libidn2 2.0.4-1.1

Date: Fri, 24 Nov 2017 09:20:19 +0000

Source: libidn2
Source-Version: 2.0.4-1.1

We believe that the bug you reported is fixed in the latest version of
libidn2, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 881915@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated libidn2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 23 Nov 2017 11:11:41 +0000
Source: libidn2
Binary: libidn2-0 libidn2-dev libidn2-0-dev idn2 libidn2-doc
Architecture: source
Version: 2.0.4-1.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Libidn team <help-libidn@gnu.org>
Changed-By: Simon McVittie <smcv@debian.org>
Description:
 idn2       - Internationalized domain names (IDNA2008/TR46) command line tool
 libidn2-0  - Internationalized domain names (IDNA2008/TR46) library
 libidn2-0-dev - Internationalized domain names (IDNA2008/TR46) development files
 libidn2-dev - Internationalized domain names (IDNA2008/TR46) development files
 libidn2-doc - Internationalized domain names (IDNA2008/TR46) documentation
Closes: 881915 881968
Changes:
 libidn2 (2.0.4-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
 .
   [ Helmut Grohne ]
   * Fix FTBFS: gtkdocize and add dblatex to Build-Depends. (Closes: #881915)
 .
   [ Simon McVittie ]
   * Run gtkdocize via a script debian/autogen.sh passed as a parameter
     to dh_autoreconf, so that the changed gtk-doc.make will be recorded
     by dh_autoreconf and deleted by dh_autoreconf_clean
     - Use gtkdocize --copy to avoid gtk-doc.make becoming a symlink, which
       dh_autoreconf doesn't currently handle
   * libidn2-doc Breaks/Replaces older versions of both libidn2-dev and
     libidn2-0-dev (Closes: #881968)
Checksums-Sha1:
 30dc4e77725e24ad2c1a53336ce0d91a60a3de9d 2292 libidn2_2.0.4-1.1.dsc
 df9d704951845d90a7badb182428100b0862d10b 10285032 libidn2_2.0.4-1.1.debian.tar.xz
 dca482c8b99d978e97f6d1b95dde119e3f3b043e 11028 libidn2_2.0.4-1.1_source.buildinfo
Checksums-Sha256:
 501fe84ff95ad94d7ef8a4a7225c0d3da9969333aeceb7c46b61e7c7b970c240 2292 libidn2_2.0.4-1.1.dsc
 434c590d238e7fd86ead3c9e201ade52d1b415d453824817747ed77179e6793b 10285032 libidn2_2.0.4-1.1.debian.tar.xz
 0518a398d01ec1f9a1e6bea50f3daf1da1856ccfcae309c5b5d040642057fe94 11028 libidn2_2.0.4-1.1_source.buildinfo
Files:
 3468ca4793bc79982cdbb273f661ea45 2292 libs optional libidn2_2.0.4-1.1.dsc
 85b9d8968f7e6beb6e718f3926c8e922 10285032 libs optional libidn2_2.0.4-1.1.debian.tar.xz
 13fe1241807c192e288ada290dbab2ac 11028 libs optional libidn2_2.0.4-1.1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENuxaZEik9e95vv6Y4FrhR4+BTE8FAloX0KYACgkQ4FrhR4+B
TE/tWw//YH0m589Oc343v8XDEt4O+UarcSmvv7EhBIz2QD9QJho1gOv1DPHyOMTk
aCh7PqWjIBJuuEBXhsaEWiYDHeTleLZ61R7W602ff2Nh9jBoHbWgnb+sTBlyWdeY
CIXcr+5lmCB93WjYC4WUuqTVJBp7bRZnMJ2B6+tyJA7er05IHTJQOyNr/ZniKrhI
R4qC8q2TsFJNs0GKhiDQ+jPIKDn0zU8vHWOD2v4HbjuyTibckFxyRCH7ZXjn5vit
UUhvz/AC5zhkTlJJNcBXK0ksf5S7imcjXeg52pDxN8Zqw3g8Vg1Mt4OlKhW96CwQ
Kklh/HGB2ESt3xebp/NzcejPlBtX3osS4fI7FYZ00scxeAPqu5CkWZLN5AEy3Nm+
6jyV+MSgFKekB2jJOSssEZsARDyY7sfCEbHG4rdjGdjYD74vy8sO3mr9hemSQ128
WC/mCNMbJ+pKn3jmJkVPw6RFXO2RHECmE3kOUHXfN0eccrxE7wB1Iz8EHYy/02JC
8IwLwpxcuRxP0u3i+iFIx4PmOqmSyPgqEQLzKCB3xSxzILZK/dyQ47K0TEXGBFYN
c7kvMFPkr6dSa5+L++ux5L1AcRroBl3QvZidC6wL9AURZ1YnPGMitSGcnDH+9BO9
Ga/DY3gogANPz4et3hldz+UiaH0w3IbRvAq7roMiYsD6nfhveSs=
=jhrM
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.