Re: Bug#593898: gnustep-back-common: Fails to upgrade in postinst script
- To: Axel Beckert <email@example.com>
- Cc: firstname.lastname@example.org, Yavor Doganov <email@example.com>
- Subject: Re: Bug#593898: gnustep-back-common: Fails to upgrade in postinst script
- From: Yavor Doganov <firstname.lastname@example.org>
- Date: Fri, 27 Aug 2010 20:51:44 +0300
- Message-id: <87y6bs6j0v.GNU's_Not_Unixemail@example.com>
- Mail-followup-to: Axel Beckert <firstname.lastname@example.org>, email@example.com, Yavor Doganov <firstname.lastname@example.org>
- In-reply-to: <20100827163041.GD11022@sym.noone.org>
- References: <20100822145757.GR11022@sym.noone.org> <87zkwey4jd.GNU's_Not_Unixemail@example.com> <87r5hpxl8a.GNU's_Not_Unixfirstname.lastname@example.org> <20100823224143.GS11022@sym.noone.org> <email@example.com> <20100827103904.GZ11022@sym.noone.org> <firstname.lastname@example.org> <email@example.com> <20100827130158.GB11022@sym.noone.org> <87zkw86ngy.GNU's_Not_Unixfirstname.lastname@example.org> <20100827163041.GD11022@sym.noone.org>
tags 593898 + pending
[email@example.com 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
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 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.
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.