Hi all, in my case I fall every time over the gnustep-updater who tries to update the gnustep-back-art package. /bin/sh: line 2: 9612 Segmentation fault plmerge libgnustep-back-020.bundle/Resources/Info-gnustep.plist libgnustep-back-020Info.plist Regards j0inty Reproducible: Always Steps to Reproduce: 1. update to new gnustep 2. emerge gnustep-updater 3. run gnustep-updater Actual Results: Failed to compile gnustep-back-art package Needed logs and infos will attach.
Created attachment 272781 [details] gnustep-back-art-0.20.1 build.log
Created attachment 272783 [details] emerge --info
Created attachment 274075 [details] gdb plmerge core - bt full plmerge segmentation fault during emerging gnustep-back-0.20.1 I have gnustep-base/gnustep-base-1.22.0 install. I try to have a look at the source but I don't understand the stackoverflow. Regards
a bit nasty that it crashes in sandbox...
but plmerge only fails under emerge but not run directly under bash or zsh.
Same problem with gnustep-base/gnustep-back-cairo-0.20.1 on i686 (gnustep-base/gnustep-base-1.22.0 installed): ... /bin/sh: line 2: 17848 Segmentation fault plmerge libgnustep-back-020.bundle/Resources/Info-gnustep.plist libgnustep-back-020Info.plist ...
Created attachment 274231 [details] emerge --info =gnustep-base/gnustep-back-cairo-0.20.1
Created attachment 274233 [details] build.log
I can confirm problem with gnustep-base/gnustep-back-cairo-0.20.1 but on AMD64 during emerge gnustep-base/gnustep-back-cairo-0.20.1: /bin/sh: line 2: 30572 Segmentation fault plmerge libgnustep-back-020.bundle/Resources/Info-gnustep.plist libgnustep-back-020Info.plist make[3]: *** [libgnustep-back-020.bundle/Resources/Info-gnustep.plist] Error 139 ...
I don't know what changed, but I can now reproduce it also... strace-ing plmerge shows it seems to loop forever reading /root/GNUstep/Defaults/.GNUstepDefaults (I'll attach output) The file in itself is short: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//GNUstep//DTD plist 0.9//EN" "http://www.gnustep.org/plist-0_9.xml"> <plist version="0.9"> <dict> <key>NSGlobalDomain</key> <dict> </dict> <key>gdnc</key> <dict> </dict> </dict> But this should not be accessed, for compilation we set (in gnustep-base eclass) HOME, GNUSTEP_USER_DIR, GNUSTEP_USER_DEFAULTS_DIR to ${T}, so it should not use root's one. Fixing this should make it work As for sandbox's behavior, not sure why it causes a loop, may be a bug...
Created attachment 274607 [details] Build log with plmerge replaced by strace plmerge
You're right. I moved /root/GNUStep to /root/GNUstep.old and I succeed to compile gnustep-back-0.20.1 Does someone are interesting for having my /root/GNUstep.old to try finding where was the bug ?
My /root/GNUstep.old/Defaults/.GNUstepDefaults is : { NSGlobalDomain = { }; gdnc = { }; }
Ok, I have a fix, testing with some other GNUstep packages to be on the safe side. The problem: we override (in gnustep-base.eclass) GNUSTEP_USER_DIR and other env variables to point to ${T}, but these are only honoured by gnustep-make, not by GNUstep programs themselves (like plmerge). These first load GNUstep.conf and use the settings from it (using /root/GNUstep in the end when running plmerge here). I've modified the eclass to create a temporary GNUstep.conf, based on system one but with the needed sed commands, which is then used in make commands. So far it seems to work great :) If nothing breaks in my tests, I'll commit the eclass update tonight
Updated gnustep-base.eclass committed to CVS, thanks everyone for help on fixing this bug :) If plmerge still fails, check that /usr/portage/eclass/gnustep-base.eclass has a header version 1.17 (the updated one) and reopen
It solves the problem with plmerge but exactly the same problem appear with mknfonts
Created attachment 276249 [details] gnustep-back-art-0.20.1 build.log
Same here on my ~amd64 box. regards j0inty
Created attachment 276251 [details] mknfonts - gdb bt full
Indeed, I tested with the cairo backend, but art ebuild has a separate call for mknfonts... Thanks for testing! This one should be fixed in gnustep-back-art-0.20.1 ebuild (no revbump) now (crossing fingers)
I just test and gnustep-back-art compiles well now Great job, Regards,
Hi, i was running the gnustep-updater yesterday and everything that was on the list compiled fine. Best Thanks and very good job regards j0inty j0inty@arko ~ $ qlist -Iv gnustep gnustep-apps/remotedesk-0.1 gnustep-base/gnustep-back-art-0.20.1 gnustep-base/gnustep-base-1.22.0 gnustep-base/gnustep-gui-0.20.0 gnustep-base/gnustep-make-2.6.1 gnustep-base/gnustep-updater-0.1 gnustep-base/mknfonts-0.5-r1 virtual/gnustep-back-0.20.1
Thanks everyone for your help and patience, we have a new clean layout now in ~arch :)
It looks like I run into this bug from 3 years ago, when trying to rebuild GNUstep packages with Clang... I'll attach the failing logs etc., but I'm not able to reopen/change status of this bug report.
Created attachment 381096 [details] emerge --info '=gnustep-base/gnustep-back-cairo-0.24.0'
Created attachment 381098 [details] emerge -pqv '=gnustep-base/gnustep-back-cairo-0.24.0'
Created attachment 381100 [details] Config log =gnustep-base/gnustep-back-cairo-0.24.0
Created attachment 381102 [details] Build log =gnustep-base/gnustep-back-cairo-0.24.0
Created attachment 381104 [details] Build log =gnustep-apps/systempreferences-1.2.0
Created attachment 381106 [details] Build log =gnustep-apps/gworkspace-0.9.2
Found this link: https://lists.gnu.org/archive/html/discuss-gnustep/2013-08/msg00257.html and downgraded to current Gentoo stable llvm-3.3-r3/clang-3.3-r100. After that, I was able to recompile all GNUstep packages without the plmerge errors (but still all apps segfault when run). Case closed here, for the plmerge bugs.
Thanks, it's nice that this was not this old problem that was the cause :) Don't hesitate to open a new bugreport on cases like that, we can sort if it was a duplicate in the end later on
