В 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? That is perhaps the cause (gnustep-back has special support for different window managers, some are very poorly supported). > 2010-08-27 14:25:26.501 Cenon[24964] XShm not supported, XShmAttach() failed. > 2010-08-27 14:25:26.501 Cenon[24964] Falling back to normal XImage: s (will > be slower). This is harmless. > 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. > 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 ? What does $ defaults read NSGlobalDomain NSFont 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? > 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) > Cynthiune segfaults: > > [1] 25191 segmentation fault (core dumped) Cynthiune Disturbing. > > 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. > 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). > 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? (I'll send you a separate message privately.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org