Mounting /dev/pts solved this issue. The previous releases did not need this mount. You can safely close this.
On Wed, Feb 21, 2018 at 11:12 AM, Simon McVittie <s...@debian.org> wrote: > Control: retitle -1 babl: FTBFS: aclocal segfaults > Control: reassign -1 automake > Control: tags -1 + moreinfo unreproducible > > On Wed, 21 Feb 2018 at 10:52:58 +0100, jean-christophe manciot wrote: > > make[1]: Entering directory '/home/actionmystique/src/Babl/babl-build/ > > babl-0.1.44-1' > > dh_autoreconf --as-needed > > libtoolize: putting auxiliary files in '.'. > > libtoolize: copying file './ltmain.sh' > > libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. > > libtoolize: copying file 'm4/libtool.m4' > > libtoolize: copying file 'm4/ltoptions.m4' > > libtoolize: copying file 'm4/ltsugar.m4' > > libtoolize: copying file 'm4/ltversion.m4' > > libtoolize: copying file 'm4/lt~obsolete.m4' > > Segmentation fault (core dumped) > > autoreconf: aclocal failed with exit status: 139 > > I can't reproduce this failure mode, and neither did the official Debian > buildds or reproducible-builds.debian.org. > > This looks more likely to be a bug in aclocal, which is part of > automake, or a bug in perl, which is the interpreter used to run aclocal. > babl isn't doing anything out of the ordinary here. Do other packages > that run aclocal fail in the same way for you? libgfshare and dbus-glib > are some convenient small examples, for instance. > > Can you get a backtrace from the crash? For example try using > systemd-coredump or corekeeper (on the host system if you're using a > chroot), or <https://wiki.debian.org/HowToGetABacktrace>. Because aclocal > is a perl script, the debug symbols to install would be those for perl. > > Regards, > smcv > -- Jean-Christophe
