[Debian GNUstep maintainers] Bug#593898: gnustep-back-common: Fails to upgrade in postinst script
Axel Beckert
abe at debian.org
Fri Aug 27 16:20:03 UTC 2010
Hi,
Yavor Doganov wrote:
> ?? 15:01 +0200 ???? 27.08.2010 (????), Axel Beckert ????????????:
> > Running Cenon remotely via ssh with tunnelled X display results in the
> > following messages on the console:
> >
> > $ Cenon
> > 2010-08-27 14:25:21.002 Cenon[24964] QueryTree window is 90401287 (root 837 cwin root 837)
> > 2010-08-27 14:25:21.017 Cenon[24964] QueryTree window is 90401286 (root 837 cwin root 837)
>
> Never seen that before, it should be an impossible (or very rare) code
> path these days. What window manager are you using?
FVWM 2.5 on Debian Stable (Lenny), but I started those programs
remotely via SSH with tunneled X display. Maybe that's the cause?
> That is perhaps the cause (gnustep-back has special support for
> different window managers, some are very poorly supported).
Just tried it locally on that box, with ratpoison as window manager,
there I got an uncaught exception:
2010-08-27 17:24:28.179 Cenon[28637] Did not find correct version of backend (libgnustep-cairo-018.bundle), falling back to std (libgnustep-cairo.bundle).
2010-08-27 17:24:28.192 Cenon[28637] NSApplication.m:304 Assertion failed in initialize_gnustep_backend. Unable to find backend libgnustep-cairo
Cenon: Uncaught exception NSInternalInconsistencyException, reason: NSApplication.m:304 Assertion failed in initialize_gnustep_backend. Unable to find backend libgnustep-cairo
> > and a dialog box saying:
> >
> > Button Critical Error in Cenon
> > NSInternalInconsistencyException: Abstract model loader
> > [Abort <-']
>
> This indicates a bug in gnustep-gui, or much more likely, cenon.app
> being incompatible with gnustep-gui/0.18.
Didn't come locally until I installed gnustep-back0.18-cairo. Then I
got a bunch of other messages about styleoffsets and the quote dialog
box after them.
> > GWorkspace also has problems:
> >
> > $ GWorkspace
> > 2010-08-27 14:31:18.351 GWorkspace[25108] File NSUserDefaults.m: 685. In +[NSUserDefaults standardUserDefaults] Improper installation: No language locale found
> > 2010-08-27 14:31:18.885 GWorkspace[25108] No fonts found!
>
> This should not happen. Does it start if you do
>
> $ defaults write NSGlobalDomain GSBackend libgnustep-cairo
>
> ?
Nothing happens (now with gnustep-back0.18-cairo installed) when doing
it via the SSH remote display. It exits with return value 0.
But GWorkspace now segfaults:
$ GWorkspace
2010-08-27 17:31:35.057 GWorkspace[31635] File NSUserDefaults.m: 685. In +[NSUserDefaults standardUserDefaults] Improper installation: No language locale found
2010-08-27 17:31:35.072 GWorkspace[31635] Did not find correct version of backend, falling back to std.
2010-08-27 17:31:35.073 GWorkspace[31635] NSApplication.m:286 Assertion failed in initialize_gnustep_backend. Unable to find backend libgnustep-cairo
[2] 31635 abort (core dumped) GWorkspace
$
> What does
>
> $ defaults read NSGlobalDomain NSFont
$ defaults read NSGlobalDomain NSFont
defaults read: couldn't read default
$
> on the machine you're testing at return? I suspect nothing, if you
> didn't set NSFont explicitly. In this case, the art backend tries to
> find Helvetica, BitStream Vera, and DejaVu (in that order) and aborts if
> it cannot. Do you have ttf-dejavu installed?
Yes:
ii ttf-dejavu 2.31-1 Metapackage to pull in ttf-dejavu-core and t
> > So maybe mknfont did not segfault anymore but perhaps also not work
> > properly?
>
> I don't believe so, but
> sending /var/lib/GNUstep/Fonts/<anything>.nfont/FontInfo.plist will
> confirm that. (Preferrably, <anything> = DejaVu-related)
/var/lib/GNUstep/Fonts/DejaVuSans.nfont/FontInfo.plist:
{
Faces = (
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-BoldOblique.ttf"
);
Name = "Bold Oblique";
PostScriptName = "DejaVuSansMono-BoldOblique";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Oblique.ttf"
);
Name = Oblique;
PostScriptName = "DejaVuSansMono-Oblique";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Bold.ttf"
);
Name = Bold;
PostScriptName = "DejaVuSansMono-Bold";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf"
);
Name = Book;
PostScriptName = DejaVuSansMono;
}
);
}{
Faces = (
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansCondensed-BoldOblique.ttf"
);
Name = "Condensed Bold Oblique";
PostScriptName = "DejaVuSansCondensed-BoldOblique";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf"
);
Name = Book;
PostScriptName = DejaVuSans;
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-BoldOblique.ttf"
);
Name = "Bold Oblique";
PostScriptName = "DejaVuSans-BoldOblique";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-ExtraLight.ttf"
);
Name = ExtraLight;
PostScriptName = "DejaVuSans-ExtraLight";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansCondensed-Oblique.ttf"
);
Name = "Condensed Oblique";
PostScriptName = "DejaVuSansCondensed-Oblique";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansCondensed.ttf"
);
Name = Condensed;
PostScriptName = DejaVuSansCondensed;
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansCondensed-Bold.ttf"
);
Name = "Condensed Bold";
PostScriptName = "DejaVuSansCondensed-Bold";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Oblique.ttf"
);
Name = Oblique;
PostScriptName = "DejaVuSans-Oblique";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf"
);
Name = Bold;
PostScriptName = "DejaVuSans-Bold";
}
);
}{
Faces = (
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf"
);
Name = Book;
PostScriptName = DejaVuSerif;
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerifCondensed-BoldItalic.ttf"
);
Name = "Condensed Bold Italic";
PostScriptName = "DejaVuSerifCondensed-BoldItalic";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif-Italic.ttf"
);
Name = Italic;
PostScriptName = "DejaVuSerif-Italic";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif-Bold.ttf"
);
Name = Bold;
PostScriptName = "DejaVuSerif-Bold";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerifCondensed-Italic.ttf"
);
Name = "Condensed Italic";
PostScriptName = "DejaVuSerifCondensed-Italic";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerifCondensed-Bold.ttf"
);
Name = "Condensed Bold";
PostScriptName = "DejaVuSerifCondensed-Bold";
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerifCondensed.ttf"
);
Name = Condensed;
PostScriptName = DejaVuSerifCondensed;
},
{
Files = (
"/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif-BoldItalic.ttf"
);
Name = "Bold Italic";
PostScriptName = "DejaVuSerif-BoldItalic";
}
);
}
[No newline at end of file]
> > Cynthiune segfaults:
> >
> > [1] 25191 segmentation fault (core dumped) Cynthiune
>
> Disturbing.
But only if started remotely via SSH tunneled X display. Seems to work
fine locally with ratpoison as window manager.
Only tons of these style offset messages, too, but I guess that's
because ratpoison is one of these tiling window managers which resize
windows automatically.
> > > and see if you can spot some bugs (except the
> > > usual ones, I mean :-)).
> >
> > I guess that unfortunately counts as "some bugs". :-(
>
> Absolutely. We (I) need to analyze them and clone/reassign as
> appropriate. Do they occur with gnustep-base/1.20.1-3 from the official
> archive? I see nothing that would lead me think so -- if NSProcessInfo
> + proc was not working on GNU/kFreeBSD, they would abort much earlier.
Ah, ok.
With nustep-base/1.20.1-3 from the official archive and
gnustep-back0.18-cairo installed via SSH tunneled X display to my
Lenny box with FVWM 2.5 running:
$ Cenon
2010-08-27 18:02:41.192 Cenon[39307] XShm not supported, XShmAttach() failed.
2010-08-27 18:02:41.195 Cenon[39307] Falling back to normal XImage: s (will be slower).
Cenon: Uncaught exception NSInternalInconsistencyException, reason: Abstract model loader.
[Well known dialog box as documented above appeared at that point, too]
$ GWorkspace
2010-08-27 18:03:20.090 GWorkspace[42613] File NSUserDefaults.m: 685. In +[NSUserDefaults standardUserDefaults] Improper installation: No language locale found
2010-08-27 18:03:20.116 GWorkspace[42613] Did not find correct version of backend, falling back to std.
2010-08-27 18:03:20.117 GWorkspace[42613] NSApplication.m:286 Assertion failed in initialize_gnustep_backend. Unable to find backend libgnustep-cairo
[2] 42613 abort (core dumped) GWorkspace
$ Cynthiune
2010-08-27 18:03:41.324 Cynthiune[43085] XShm not supported, XShmAttach() failed.
2010-08-27 18:03:41.328 Cynthiune[43085] Falling back to normal XImage: s (will be slower).
<init> : Avifile RELEASE-0.7.48-100130-08:44-../src/configure
<init> : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat b19 b21 mmxext mmx fxsr xmm sse2 b27 b28 b29 3dnow
<init> : 1608.01 MHz Intel(R) Atom(TM) CPU N270 @ 1.60GHz processor detected
[2] 43085 segmentation fault (core dumped) Cynthiune
$
More or less the same (even now the segfault of Cynthiune) happens
locally with ratpoison as window manager, too.
I noticed that due to some GNUstep already removed from the Debian
archive still being installed, older versions of gnustep-back and
gnustep-base are still installed, too. Do you think this could have
caused some of these issues?
BTW, here are the installed versions of the tools I tested:
$ apt-cache policy cynthiune.app gworkspace.app cenon.app
gworkspace.app:
Installed: 0.8.7-1
Candidate: 0.8.7-1
Version table:
*** 0.8.7-1 0
110 http://debian.ethz.ch/debian/ experimental/main kfreebsd-i386 Packages
100 /var/lib/dpkg/status
0.8.6-1+b1 0
990 http://debian.ethz.ch/debian/ unstable/main kfreebsd-i386 Packages
0.8.6-1 0
600 http://debian.ethz.ch/debian/ testing/main kfreebsd-i386 Packages
cenon.app:
Installed: 3.83-1+b1
Candidate: 3.83-1+b1
Version table:
*** 3.83-1+b1 0
990 http://debian.ethz.ch/debian/ unstable/main kfreebsd-i386 Packages
100 /var/lib/dpkg/status
3.83-1 0
600 http://debian.ethz.ch/debian/ testing/main kfreebsd-i386 Packages
cynthiune.app:
Installed: 0.9.5-10+b4
Candidate: 0.9.5-10+b4
Version table:
*** 0.9.5-10+b4 0
990 http://debian.ethz.ch/debian/ unstable/main kfreebsd-i386 Packages
100 /var/lib/dpkg/status
0.9.5-10+b3 0
600 http://debian.ethz.ch/debian/ testing/main kfreebsd-i386 Packages
$
So at least gworkspace.app is from experimental. I probably installed
it once because the one in unstable was uninstallable at some moment
or so. (All of the programs you asked me to test where already
installed on my kfreebsd box, so I didn't check their versions
initially.)
GWorkspace from unstable seems to work fine remotely as well as
locally. So that bug is only in the version in experimental. (Sorry
for the noise because of that.) Maybe it just needs a rebuild. The
version in unstable has at least been binaryNMUed once.
> > Not sure if I did this right:
> >
> > $ gcc -I/usr/include/GNUstep -lobjc -o test test.m
>
> It is tiresome to run the whole command(s) directly, because many
> additional flags for the compiler/preprocessor/linker are necessary.
> Just use the makefile I sent you earlier
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593898#20).
Thanks for that hint. 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
> > I can give you ssh access to one (or both) of the Debian GNU/kFreeBSD
> > porter machines
>
> Thanks, that would be very appreciated as I will run any tests myself
> without bothering you. But... isn't access restricted to DDs only?
Some porter boxes are DD-only, but not all of them.
Regards, Axel
--
,''`. | Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
More information about the pkg-GNUstep-maintainers
mailing list