[Debian GNUstep maintainers] Bug#593898: gnustep-back-common: Fails to upgrade in postinst script

[Yavor Doganov]

tags 593898 + pending
thanks

[libkvm0 at 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.