tags 593898 + pending thanks [libk...@p.d.o BCCed -- relevant part at the end of the message.]
Axel Beckert wrote: > > If not, then the -art backend package must surely depend on it. > > If yes, running with --GNU-Debug=ftfont might give some clues why > > this happens. > > As this just affects GWorkspace in experimental, shall I still try > that? No, not needed. It is completely clear what's going on: once you upgraded gnustep-back to 0.18, its maintainer scripts wiped out the old (/var/lib/defoma/...) font directory, and the new version is patched to look at the new location (/var/lib/GNUstep/...) which we populate in postinst with the help of fc-list and mknfonts. Because the version of gworkspace in experimental was built against old GNUstep core combination, it naturally fails -- the old gnustep-gui GWorkspace links against dynamically opens the old art bundle, and there are no fonts available at the place it is looking. Expected situation, and not a bug in itself because the old (0.16) defoma-ized art backend has been broken long before that. > > > Cynthiune segfaults: > In then installed libgnustep-gui0.18-dbg, fired it up again it via SSH > remotely and it didn't segfault anymore but showed up. Strange. > Removed libgnustep-gui0.18-dbg again, still works. Very strange. Then > I upgraded the gnustep-base packages to the version with /proc and > without libkvm again. Still works. Looks like a Heisenbug to me. Worth analyzing. But now that you gave me an account, I'll do that myself. > Maybe that's related to the downgrade of GWorkspace from > experimental to unstable, too? Shouldn't be related, but it _might_ be due to the sequence in which you performed the other tests. Probably you tried GWorkspace first, which left a gdnc instance running, and/or possibly with the DO (Distributed Objects) database corrupted (because of the ABI-incompatible changes). Cynthiune uses DO intensively (for in-process inter-thread communication), so it's quite possible that something went wrong in the way. At some point probably GDNC invalidated itself and became non-functional, and then launching Cynthiune again should have spawned another gdnc instance, doing its job properly. Or, it might be an(other) NSThread/NSLock bug in GNUstep Base, or some implementations of the GUI classes not completely thread-safe... I'll try to reproduce and investigate. The most important thing is this: > Here's the output of calling obj/test (with the non-libkvm but > /proc-using version of gnustep-base being installed): > > PASS: +processInfo > PASS: -arguments > PASS: -environment > PASS: -globallyUniqueString > Unique string: metisse_ethz_ch_7d7b_122813f1_0 > PASS: -hostName > Hostname: metisse.ethz.ch > 2010-08-27 17:40:33.094 test[32123] File NSProcessInfo.m: 1170. In > determineOperatingSystem Unable to determine O/S ... assuming GNU/Linux > PASS: -operatingSystem > PASS: -operatingSystemName > Operating system: GSGNULinuxOperatingSystem > PASS: -operatingSystemVersionString > Version: 8.0-1-686-smp > PASS: -processIdentifier > PID: 32123 > PASS: -processName > Process name: test > PASS: -setProcessName: > New process name: foo > PASS: -setLogFile: > Log file: /tmp/GNUstepSecure1000/NSProcessInfo_test This confirms that gnustep-base with /proc support is working properly on GNU/kFreeBSD -- all method tests pass, and you wouldn't be able to launch any program linked against -base if something was really wrong. I'm going to prepare an upload shortly. @libkvm people: The fact that kvm_getargv returns NULL during gnustep-base's initialization might be a libkvm bug. I'm hesitating to reassign (even with low severity), as I'm not sure at all. I downloaded the freebsd-libs package and looked at the manpage; there is no indication under what circumstances kvm_getargv is supposed to return NULL. I looked at the source too and I see a case when the function will do that, but I'm afraid I can't understand it without some further diving/reading -- something I'm currently unwilling to do, given that there's a clear way out and some other (GNUstep) RC bugs were discovered that need urgent fixing. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6bs6j0v.gnus_not_unix!%ya...@gnu.org
