Bug#918789: gnustep-back-common: postinst fails on hurd-i386
Control: reopen -1 On Wed, 09 Jan 2019 13:39:46 +0200, Yavor Doganov wrote: > Package: gnustep-back-common > Version: 0.26.2-4 > > I noticed that gnumail and adun.app have been given back a few hundred > times because gnustep-back-common's postinst fails on GNU/Hurd. This is happening again with adun.app. I think it has something to do with the intermittent issue of the proc mount missing, but I'm not sure. The previous failures were with mknfonts.tool which was linked against gnustep-base/1.25 and 1.25.1-4+b1 was installed in the chroot. This version was built without /proc, apparently because it was not mounted at the time gnustep-base was built. It then succeeded with mknfonts.tool/0.5-12+b1 which was binNMUed for gnustep-base/1.26 and 1.26.0-2 was built with /proc. Now it is failing with gnustep-base/1.26.0-3 which was built again without /proc. I also checked back and found out that the last successful build of adun.app was on 29 Jan 2018 with gnustep-base/1.25.1-1 which was built with /proc. Does it make sense or I should put this theory to rest? > Hopefully, /var/log/gnustep-back-common.log should give some clue. That still stands. If investigating is burdensome, my theory would be either confirmed or ruled out if gnustep-base is given back and rebuilt with /proc.
Bug#918789: gnustep-back-common: postinst fails on hurd-i386
Samuel Thibault wrote: > Yavor Doganov, le mer. 16 janv. 2019 08:37:42 +0200, a ecrit: > > dbuskit, fontmanager.app and renaissance FTBFS > > It would be nice if these can be given back. > > Done so. Thanks; the first two built fine but AFAICS renaissance was not retried at all. Perhaps you missed it or mistyped the package name?
Bug#918789: gnustep-back-common: postinst fails on hurd-i386
Yavor Doganov, le mer. 16 janv. 2019 17:29:48 +0200, a ecrit: > Samuel Thibault wrote: > > Yavor Doganov, le mer. 16 janv. 2019 08:37:42 +0200, a ecrit: > > > dbuskit, fontmanager.app and renaissance FTBFS > > > It would be nice if these can be given back. > > > > Done so. > > Thanks; the first two built fine but AFAICS renaissance was not > retried at all. Perhaps you missed it or mistyped the package name? I just missed it indeed. Samuel
Bug#918789: gnustep-back-common: postinst fails on hurd-i386
Yavor Doganov, le mer. 16 janv. 2019 08:37:42 +0200, a ecrit: > dbuskit, fontmanager.app and renaissance FTBFS (all on ironforge) due > to a known issue (/proc missing): Ah, sometimes the proc mount goes away on one buildd, that's a new thing, I don't know why yet. > | pl2link GSMarkupBrowser.app/Resources/Info-gnustep.plist > ./GSMarkupBrowser.app/Resources/GSMarkupBrowser.desktop; \ > | chmod a+x > ./GSMarkupBrowser.app/Resources/GSMarkupBrowser.desktop > | Couldn't open file /proc/8331/cmdline when starting gnustep-base; No such > file or directory > | Your gnustep-base library is compiled for a kernel supporting the /proc > filesystem, but it can't access it. > | You should recompile or change your kernel. > | We try to go on anyway; but the program will ignore any argument which were > passed to it. > > It would be nice if these can be given back. Done so. > Perhaps the postinst failure was also due to this? Hard to believe as > it failed so many times on both buildds. Yes, it's most probably not the same issue, usually /proc is there. > Also, avifile needs to be binNMUed against ffmpeg as cynthiune.app is > in state BD-Uninstallable. Done so, thanks! Samuel
Bug#918789: gnustep-back-common: postinst fails on hurd-i386
Samuel Thibault wrote: > > I noticed that gnumail and adun.app have been given back a few hundred > > times because gnustep-back-common's postinst fails on GNU/Hurd. > > It seems this got fixed? Yes, it got fixed somehow although I'm still curious to know what was the problem. There are some other issues on GNU/Hurd with the GNUstep transition: dbuskit, fontmanager.app and renaissance FTBFS (all on ironforge) due to a known issue (/proc missing): | pl2link GSMarkupBrowser.app/Resources/Info-gnustep.plist ./GSMarkupBrowser.app/Resources/GSMarkupBrowser.desktop; \ | chmod a+x ./GSMarkupBrowser.app/Resources/GSMarkupBrowser.desktop | Couldn't open file /proc/8331/cmdline when starting gnustep-base; No such file or directory | Your gnustep-base library is compiled for a kernel supporting the /proc filesystem, but it can't access it. | You should recompile or change your kernel. | We try to go on anyway; but the program will ignore any argument which were passed to it. It would be nice if these can be given back. Perhaps the postinst failure was also due to this? Hard to believe as it failed so many times on both buildds. Also, avifile needs to be binNMUed against ffmpeg as cynthiune.app is in state BD-Uninstallable.
Bug#918789: gnustep-back-common: postinst fails on hurd-i386
Hello, Yavor Doganov, le mer. 09 janv. 2019 13:39:46 +0200, a ecrit: > Package: gnustep-back-common > Version: 0.26.2-4 > Severity: important > User: debian-h...@lists.debian.org > Usertags: hurd-i386 > > I noticed that gnumail and adun.app have been given back a few hundred > times because gnustep-back-common's postinst fails on GNU/Hurd. I would > appreciate if you investigate and see what's going wrong, is it mknfonts > that fails or something else? It seems this got fixed? Samuel
Bug#918789: gnustep-back-common: postinst fails on hurd-i386
Package: gnustep-back-common Version: 0.26.2-4 Severity: important User: debian-h...@lists.debian.org Usertags: hurd-i386 I noticed that gnumail and adun.app have been given back a few hundred times because gnustep-back-common's postinst fails on GNU/Hurd. I would appreciate if you investigate and see what's going wrong, is it mknfonts that fails or something else? The relevant snippet is: FONTSDIR=/var/lib/GNUstep/Fonts ... echo -n "Generating GNUstep nfont descriptions..." if [ -d $FONTSDIR ]; then rm -rf $FONTSDIR/* else mkdir -p $FONTSDIR fi cd $FONTSDIR; \ mknfonts $(fc-list : file | grep -v '\.gz' | cut -d: -f1) \ 2>/var/log/gnustep-back-common.log \ || (echo " failed, see /var/log/gnustep-back-common.log."; exit 1) Hopefully, /var/log/gnustep-back-common.log should give some clue.
