Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
On 2016-07-29 04:48 +0100, Wookey wrote: > OK. I've done a better job of ensuring configure is generated before > first usage, and backed-up/restored so a second build works as > well. Basically a manual dh_autoreconf. Wouldn't it be simpler to just delete configure in the clean target? Anyway, I can confirm the problem is fixed now. :-) Cheers, Sven
Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
On 2016-07-28 20:28 +0200, Sven Joachim wrote:
> On 2016-07-28 17:45 +0100, Wookey wrote:
>
> > On 2016-07-28 15:19 +0200, Sven Joachim wrote:
> >>
> >> They should not be used at all, but Mr. Davis has these special broken
> >> tests for them. :-( And while I appreciate that you applied my patch to
> >> autoconf/aclocal.m4, the problem is not fixed as long as 'configure' is
> >> not regenerated.
> >
> > Hmm. But configure is regenerated (on a second build dpkg-source
> > complains that 'configure' has changed). And I checked that the
> > updated configure has the debian terminfo directory, added from the
> > aclocal patch.
> >
> > Run dpkg-buildpackage and check the configure file:
> > grep terminfo configure
> > { $as_echo "$as_me:${as_lineno-$LINENO}: checking for terminfo" >&5
> > $as_echo_n "checking for terminfo... " >&6; }
> >MISC_TERMINFO_DIRS=`$nc5config --terminfo`
> > /usr/lib/terminfo \
> > /usr/share/terminfo \
> > /usr/share/lib/terminfo \
> > /usr/local/lib/terminfo \
> > /lib/terminfo"
> >
> > What test are you doing to determine that this problem is not fixed?
>
> I ran pbdebuild, where /usr/share/terminfo has been rmdir'ed from the
> build chroot beforehand. Attached is a build log.
I use sbuild, but this shouldn't matter.
> > It is possible I guess that the configure flie is being updated too
> > late so the dir is not checked in time, but I just checked
> > that removing the /usr/share/terminfo did not break the build.
>
> Did you also ensure that libtinfo-dev is not installed on the build
> system? Because if it is, linking with -ltermcap succeeds, and the
> jed package gains a spurious dependency on libtinfo5.
My build chroot is clean so that package is not in it. Still builds OK for me.
Same with a local build in jessie.
OK. I've managed to reproduce it now.
> Well, in a normal build system configure _is_ updated, but only after
> building jed and before building xjed. Which is a bit too late.
OK. I've done a better job of ensuring configure is generated before
first usage, and backed-up/restored so a second build works as
well. Basically a manual dh_autoreconf.
3rd time lucky... uploaded.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
On 2016-07-28 17:45 +0100, Wookey wrote:
> On 2016-07-28 15:19 +0200, Sven Joachim wrote:
>>
>> They should not be used at all, but Mr. Davis has these special broken
>> tests for them. :-( And while I appreciate that you applied my patch to
>> autoconf/aclocal.m4, the problem is not fixed as long as 'configure' is
>> not regenerated.
>
> Hmm. But configure is regenerated (on a second build dpkg-source
> complains that 'configure' has changed). And I checked that the
> updated configure has the debian terminfo directory, added from the
> aclocal patch.
>
> Run dpkg-buildpackage and check the configure file:
> grep terminfo configure
> { $as_echo "$as_me:${as_lineno-$LINENO}: checking for terminfo" >&5
> $as_echo_n "checking for terminfo... " >&6; }
>MISC_TERMINFO_DIRS=`$nc5config --terminfo`
> /usr/lib/terminfo \
> /usr/share/terminfo \
> /usr/share/lib/terminfo \
> /usr/local/lib/terminfo \
> /lib/terminfo"
>
> What test are you doing to determine that this problem is not fixed?
I ran pbdebuild, where /usr/share/terminfo has been rmdir'ed from the
build chroot beforehand. Attached is a build log.
> It is possible I guess that the configure flie is being updated too
> late so the dir is not checked in time, but I just checked
> that removing the /usr/share/terminfo did not break the build.
Did you also ensure that libtinfo-dev is not installed on the build
system? Because if it is, linking with -ltermcap succeeds, and the
jed package gains a spurious dependency on libtinfo5.
> I realise that my latest attempt at a fix is not at all clean, and
> makes the package one of those annoying 'won't build twice' packages,
> but it did seem to me to be working.
Well, in a normal build system configure _is_ updated, but only after
building jed and before building xjed. Which is a bit too late.
Cheers,
Sven
W: /home/sven/.pbuilderrc does not exist
dpkg-buildpackage: info: source package jed
dpkg-buildpackage: info: source version 1:0.99.19-6
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Wookey
dpkg-source -i --before-build jed-0.99.19
fakeroot debian/rules clean
dh_testdir
dh_autotools-dev_restoreconfig
dh_clean
[ ! -f Makefile ] || /usr/bin/make distclean
rm -f build-stamp
dpkg-source -i -b jed-0.99.19
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building jed using existing ./jed_0.99.19.orig.tar.gz
dpkg-source: info: building jed in jed_0.99.19-6.debian.tar.xz
dpkg-source: info: building jed in jed_0.99.19-6.dsc
dpkg-genchanges --build=source >../jed_0.99.19-6_source.changes
dpkg-genchanges: info: not including original source code in upload
dpkg-source -i --after-build jed-0.99.19
dpkg-buildpackage: info: binary and diff upload (original source NOT included)
W: /home/sven/.pbuilderrc does not exist
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Thu Jul 28 15:06:38 CEST 2016
I: pbuilder-time-stamp: 1469711198
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/base.tgz]
I: copying local configuration
I: mounting /proc filesystem
I: mounting /sys filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Installing the build-deps
-> Attempting to satisfy build-dependencies
-> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: i386
Maintainer: Debian Pbuilder Team
Description: Dummy package to satisfy dependencies with aptitude - created by
pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper (>= 9), dh-autoreconf, libxft-dev, libgpm-dev, libxt-dev,
pkg-config, autotools-dev, slsh, libslang2-dev, chrpath, hevea
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 13820 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring
anyway as you requested:
pbuilder-satisfydepends-dummy depends on libxft-dev; however:
Package libxft-dev is not installed.
pbuilder-satisfydepends-dummy depends on libgpm-dev; however:
Package libgpm-dev is not installed.
pbuilder-satisfydepends-dummy depends on libxt-dev; however:
Package libxt-dev is not installed.
pbuilder-satisfydepends-dummy depends on pkg-config; however:
Package pkg-config is not installed.
pbuilder-satisfydepends-dummy depends on slsh; however:
Package slsh is not installed
Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
On 2016-07-28 15:19 +0200, Sven Joachim wrote:
> Control: found -1 1:0.99.19-6
>
> On 2016-07-25 18:21 +0100, Wookey wrote:
>
> > On 2016-07-25 18:45 +0200, Sven Joachim wrote:
> >>
> >> I have tried the attached patch, but unfortunately the build broke:
> >>
> >> ,
> >> | dh_testdir
> >> | #
> >> | # --- MAKE ---
> >> | #
> >> | /usr/bin/make DL_LIB="" OTHERLIBS=-lutil XRENDERFONTLIBS=-lXft jed #
> >> getmail
> >> | make[1]: Entering directory '/build/jed-0.99.19'
> >> | cd autoconf && autoconf && mv ./configure ..
> >> | Makefile is older than the configure script.
> >> | Please re-run the configure script.
> >> | Makefile:18: recipe for target 'Makefile' failed
> >> | make[1]: *** [Makefile] Error 1
> >> | make[1]: Leaving directory '/build/jed-0.99.19'
> >> | debian/rules:72: recipe for target 'build-stamp' failed
> >> `
> >>
> >> Apparently there's something fishy with the build system, I don't know
> >> whether it's related to debian/rules or if it is an upstream bug.
>
> > OK. I wasn't sure whether this bug was actually fixed by my changes. I
> > hoped that updating with autoreconf would make it go away (and it
> > worked for me in a fresh chroot). I admit I didn't check the details
> > very hard. So that for doing that.
> >
> > I'll look at the autofoo and try and work out what the correct fix
> > is. My main problem is that I don't really understand how the terminfo
> > libraries are used.
>
> They should not be used at all, but Mr. Davis has these special broken
> tests for them. :-( And while I appreciate that you applied my patch to
> autoconf/aclocal.m4, the problem is not fixed as long as 'configure' is
> not regenerated.
Hmm. But configure is regenerated (on a second build dpkg-source
complains that 'configure' has changed). And I checked that the
updated configure has the debian terminfo directory, added from the
aclocal patch.
Run dpkg-buildpackage and check the configure file:
grep terminfo configure
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for terminfo" >&5
$as_echo_n "checking for terminfo... " >&6; }
MISC_TERMINFO_DIRS=`$nc5config --terminfo`
/usr/lib/terminfo \
/usr/share/terminfo \
/usr/share/lib/terminfo \
/usr/local/lib/terminfo \
/lib/terminfo"
What test are you doing to determine that this problem is not fixed?
It is possible I guess that the configure flie is being updated too
late so the dir is not checked in time, but I just checked
that removing the /usr/share/terminfo did not break the build.
So I think I must be misunderstanding something here.
I realise that my latest attempt at a fix is not at all clean, and
makes the package one of those annoying 'won't build twice' packages,
but it did seem to me to be working.
Thanks for checking - I do actually want to get this right, although I
was hoping to avoid investing loads of time in a major autoconf update
(even though that is the right thing to do).
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
Control: found -1 1:0.99.19-6 On 2016-07-25 18:21 +0100, Wookey wrote: > On 2016-07-25 18:45 +0200, Sven Joachim wrote: >> >> I have tried the attached patch, but unfortunately the build broke: >> >> , >> | dh_testdir >> | # >> | # --- MAKE --- >> | # >> | /usr/bin/make DL_LIB="" OTHERLIBS=-lutil XRENDERFONTLIBS=-lXft jed # >> getmail >> | make[1]: Entering directory '/build/jed-0.99.19' >> | cd autoconf && autoconf && mv ./configure .. >> | Makefile is older than the configure script. >> | Please re-run the configure script. >> | Makefile:18: recipe for target 'Makefile' failed >> | make[1]: *** [Makefile] Error 1 >> | make[1]: Leaving directory '/build/jed-0.99.19' >> | debian/rules:72: recipe for target 'build-stamp' failed >> ` >> >> Apparently there's something fishy with the build system, I don't know >> whether it's related to debian/rules or if it is an upstream bug. > OK. I wasn't sure whether this bug was actually fixed by my changes. I > hoped that updating with autoreconf would make it go away (and it > worked for me in a fresh chroot). I admit I didn't check the details > very hard. So that for doing that. > > I'll look at the autofoo and try and work out what the correct fix > is. My main problem is that I don't really understand how the terminfo > libraries are used. They should not be used at all, but Mr. Davis has these special broken tests for them. :-( And while I appreciate that you applied my patch to autoconf/aclocal.m4, the problem is not fixed as long as 'configure' is not regenerated. Cheers, Sven
Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
On 2016-07-25 18:45 +0200, Sven Joachim wrote:
> Control: found -1 1:0.99.19-5
>
> > The configure script tries to run "ncurses5-config --terminfo", and if
> > this does not succeed, uses a hardcoded list of terminfo directories
> > which unfortunately does not include the directories /etc/terminfo and
> > /lib/terminfo which we ship in ncurses-base. Failing to find a terminfo
> > directory, it then concludes that the system must be using termcap and
> > adds "-ltermcap" to the linker line which fails.
> >
> > I will work around that by shipping an /usr/share/terminfo directory in
> > ncurses-base, but jed might still FTBFS on the buildds until they
> > upgrade their base system.
>
> I have re-opened the bug, since removing the /usr/share/terminfo
> directory from the build system still triggers the FTBFS bug, and maybe
> we want to drop the empty directory from ncurses-base at some point in
> the future.
> > Properly fixing this bug requires patching the buggy test in
> > autoconf/aclocal.m4 and regenerating configure, but since jed does not
> > currently build-depend on autoconf and uses dpatch which I haven't used
> > for years I can't really come up with a patch.
>
> I have tried the attached patch, but unfortunately the build broke:
>
> ,
> | dh_testdir
> | #
> | # --- MAKE ---
> | #
> | /usr/bin/make DL_LIB="" OTHERLIBS=-lutil XRENDERFONTLIBS=-lXft jed # getmail
> | make[1]: Entering directory '/build/jed-0.99.19'
> | cd autoconf && autoconf && mv ./configure ..
> | Makefile is older than the configure script.
> | Please re-run the configure script.
> | Makefile:18: recipe for target 'Makefile' failed
> | make[1]: *** [Makefile] Error 1
> | make[1]: Leaving directory '/build/jed-0.99.19'
> | debian/rules:72: recipe for target 'build-stamp' failed
> `
>
> Apparently there's something fishy with the build system, I don't know
> whether it's related to debian/rules or if it is an upstream bug.
OK. I wasn't sure whether this bug was actually fixed by my changes. I
hoped that updating with autoreconf would make it go away (and it
worked for me in a fresh chroot). I admit I didn't check the details
very hard. So that for doing that.
I'll look at the autofoo and try and work out what the correct fix
is. My main problem is that I don't really understand how the terminfo
libraries are used.
> Anyway, thanks for switching away from dpatch!
Yeah, that makes everyone's lives a little easier. It turned out to be
easy when I got round to it, as the only 'non-patch' dpatch patch was
doing config.{sub,guess} updates, and I know how to do that properly
using other mechanisms (modulo failing to actually get it right on
first attempt :-)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
Control: found -1 1:0.99.19-5 On 2015-11-04 18:46 +0100, Sven Joachim wrote: > Source: jed > Version: 1:0.99.19-4 > > Your package currently FTBFS in unstable. From my pbuilder log: > > , > | i586-linux-gnu-gcc -g -Wall -Wformat=2 -Wunused -Wundef -Wextra > | -Wswitch-enum -Wpointer-arith -Wnested-externs -Wbad-function-cast > | -Wcast-qual -Wcast-align -Wshadow -O2 -I/usr/include/freetype2 > | -Dunix -DJED -DUSE_GPM_MOUSE -Wl,-export-dynamic > | /build/jed-0.99.19/src/chkslang.c -o > | /build/jed-0.99.19/src/objs/chkslang -Wl,-export-dynamic > | -Wl,-R/usr/lib/i386-linux-gnu -L/usr/lib/i386-linux-gnu -lslang > | -lgpm -ltermcap -lutil > | /usr/bin/ld.bfd.real: cannot find -ltermcap > ` > > This is an unexpected fallout from the fix for bug #745479[1], I did not > really consider it possible that packages use the ncurses5-config script > without a build dependency on libncurses5-dev. Anyway, here's the > analysis: > > The configure script tries to run "ncurses5-config --terminfo", and if > this does not succeed, uses a hardcoded list of terminfo directories > which unfortunately does not include the directories /etc/terminfo and > /lib/terminfo which we ship in ncurses-base. Failing to find a terminfo > directory, it then concludes that the system must be using termcap and > adds "-ltermcap" to the linker line which fails. > > I will work around that by shipping an /usr/share/terminfo directory in > ncurses-base, but jed might still FTBFS on the buildds until they > upgrade their base system. I have re-opened the bug, since removing the /usr/share/terminfo directory from the build system still triggers the FTBFS bug, and maybe we want to drop the empty directory from ncurses-base at some point in the future. > Properly fixing this bug requires patching the buggy test in > autoconf/aclocal.m4 and regenerating configure, but since jed does not > currently build-depend on autoconf and uses dpatch which I haven't used > for years I can't really come up with a patch. I have tried the attached patch, but unfortunately the build broke: , | dh_testdir | # | # --- MAKE --- | # | /usr/bin/make DL_LIB="" OTHERLIBS=-lutil XRENDERFONTLIBS=-lXft jed # getmail | make[1]: Entering directory '/build/jed-0.99.19' | cd autoconf && autoconf && mv ./configure .. | Makefile is older than the configure script. | Please re-run the configure script. | Makefile:18: recipe for target 'Makefile' failed | make[1]: *** [Makefile] Error 1 | make[1]: Leaving directory '/build/jed-0.99.19' | debian/rules:72: recipe for target 'build-stamp' failed ` Apparently there's something fishy with the build system, I don't know whether it's related to debian/rules or if it is an upstream bug. Anyway, thanks for switching away from dpatch! Cheers, Sven Description: check for /lib/terminfo in addition to other directories The configure script tries to run "ncurses5-config --terminfo", and if this does not succeed, uses a hardcoded list of terminfo directories which unfortunately does not include the directories /etc/terminfo and /lib/terminfo which we ship in ncurses-base. Failing to find a terminfo directory, it then concludes that the system must be using termcap and adds "-ltermcap" to the linker line which fails. . To avoid this problem, add /lib/terminfo to the list of directories to search. Author: Sven Joachim Bug-Debian: https://bugs.debian.org/804083 --- --- jed-0.99.19.orig/autoconf/aclocal.m4 +++ jed-0.99.19/autoconf/aclocal.m4 @@ -481,7 +481,8 @@ JD_Terminfo_Dirs="$MISC_TERMINFO_DIRS \ /usr/lib/terminfo \ /usr/share/terminfo \ /usr/share/lib/terminfo \ - /usr/local/lib/terminfo" + /usr/local/lib/terminfo \ + /lib/terminfo" TERMCAP=-ltermcap for terminfo_dir in $JD_Terminfo_Dirs
Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
On 2015-11-04 23:39 +0100, Wookey wrote: > +++ Sven Joachim [2015-11-04 19:46 +0100]: >> Source: jed >> Version: 1:0.99.19-4 >> >> >> This is an unexpected fallout from the fix for bug #745479[1], I did not >> really consider it possible that packages use the ncurses5-config script >> without a build dependency on libncurses5-dev. Anyway, here's the >> analysis: >> >> The configure script tries to run "ncurses5-config --terminfo", and if >> this does not succeed, uses a hardcoded list of terminfo directories >> which unfortunately does not include the directories /etc/terminfo and >> /lib/terminfo which we ship in ncurses-base. Failing to find a terminfo >> directory, it then concludes that the system must be using termcap and >> adds "-ltermcap" to the linker line which fails. >> >> I will work around that by shipping an /usr/share/terminfo directory in >> ncurses-base, but jed might still FTBFS on the buildds until they >> upgrade their base system. >> >> Properly fixing this bug requires patching the buggy test in >> autoconf/aclocal.m4 and regenerating configure, but since jed does not >> currently build-depend on autoconf and uses dpatch which I haven't used >> for years I can't really come up with a patch. > > OK, thanks for the analysis. Sounds like jed should build-dep on > libncurses5-dev, or am I misunderstanding here? I don't think that's the best solution, jed has no business to link with any of the ncurses libraries. Patching src/Makefile.in worked for me: --8<---cut here---start->8--- --- jed-0.99.19.orig/src/Makefile.in +++ jed-0.99.19/src/Makefile.in @@ -76,7 +76,7 @@ # X and Miscellaneous libraries #--- # Some systems need -ltermcap (NeXT) -TERMCAP_LIB = @TERMCAP@ +TERMCAP_LIB = # X library location XLIBDIR = @X_LIBS@ --8<---cut here---end--->8--- See the same problem in slrn (#804084). > Or even better I could teach it to use pkgconfig and generally be less > crufty and ancient. Using pkgconfig would not actually help here, there is no pkgconfig equivalent for "ncurses5-config --terminfo" after all. But I think the package badly needs some modernization, the most urgent one is switching from hardening-wrapper to dpkg-buildflags, since the former is currently non-functional (#801597). Cheers, Sven
Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
+++ Sven Joachim [2015-11-04 19:46 +0100]: > Source: jed > Version: 1:0.99.19-4 > > > This is an unexpected fallout from the fix for bug #745479[1], I did not > really consider it possible that packages use the ncurses5-config script > without a build dependency on libncurses5-dev. Anyway, here's the > analysis: > > The configure script tries to run "ncurses5-config --terminfo", and if > this does not succeed, uses a hardcoded list of terminfo directories > which unfortunately does not include the directories /etc/terminfo and > /lib/terminfo which we ship in ncurses-base. Failing to find a terminfo > directory, it then concludes that the system must be using termcap and > adds "-ltermcap" to the linker line which fails. > > I will work around that by shipping an /usr/share/terminfo directory in > ncurses-base, but jed might still FTBFS on the buildds until they > upgrade their base system. > > Properly fixing this bug requires patching the buggy test in > autoconf/aclocal.m4 and regenerating configure, but since jed does not > currently build-depend on autoconf and uses dpatch which I haven't used > for years I can't really come up with a patch. OK, thanks for the analysis. Sounds like jed should build-dep on libncurses5-dev, or am I misunderstanding here? Or even better I could teach it to use pkgconfig and generally be less crufty and ancient. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap
Source: jed Version: 1:0.99.19-4 Your package currently FTBFS in unstable. From my pbuilder log: , | i586-linux-gnu-gcc -g -Wall -Wformat=2 -Wunused -Wundef -Wextra -Wswitch-enum -Wpointer-arith -Wnested-externs -Wbad-function-cast -Wcast-qual -Wcast-align -Wshadow -O2 -I/usr/include/freetype2 -Dunix -DJED -DUSE_GPM_MOUSE -Wl,-export-dynamic /build/jed-0.99.19/src/chkslang.c -o /build/jed-0.99.19/src/objs/chkslang -Wl,-export-dynamic -Wl,-R/usr/lib/i386-linux-gnu -L/usr/lib/i386-linux-gnu -lslang -lgpm -ltermcap -lutil | /usr/bin/ld.bfd.real: cannot find -ltermcap ` This is an unexpected fallout from the fix for bug #745479[1], I did not really consider it possible that packages use the ncurses5-config script without a build dependency on libncurses5-dev. Anyway, here's the analysis: The configure script tries to run "ncurses5-config --terminfo", and if this does not succeed, uses a hardcoded list of terminfo directories which unfortunately does not include the directories /etc/terminfo and /lib/terminfo which we ship in ncurses-base. Failing to find a terminfo directory, it then concludes that the system must be using termcap and adds "-ltermcap" to the linker line which fails. I will work around that by shipping an /usr/share/terminfo directory in ncurses-base, but jed might still FTBFS on the buildds until they upgrade their base system. Properly fixing this bug requires patching the buggy test in autoconf/aclocal.m4 and regenerating configure, but since jed does not currently build-depend on autoconf and uses dpatch which I haven't used for years I can't really come up with a patch. Sorry for the inconvenience. 1. https://bugs.debian.org/745479
