| === yofel_ is now known as yofel | ||
| === alkisg1 is now known as alkisg | ||
| alkisg | stgraber: `scratch` fails to load on thin clients because the /usr/bin/scratch launcher is forcing -xshm: | 16:13 |
|---|---|---|
| alkisg | /usr/lib/squeak/4.4.7-2357/squeakvm -encoding UTF-8 -vm-display-x11 -xshm -plugins /usr/lib/scratch/plugins/:/usr/lib/squeak/4.4.7-2357/ /usr/share/scratch/Scratch.image | 16:13 |
| alkisg | One hack would be to check for LTSP_CLIENT/LTSP_FATCLIENT in the launcher, but I don't think the scratch packagers would want that | 16:14 |
| stgraber | yeah, sounds pretty hackish. Do we know why -xshm doesn't work with LTSP? | 16:14 |
| alkisg | It's a remote display... no memory shared between client and server | 16:15 |
| alkisg | Another method is to check if the active display is a local or remote one, and I was wondering if you are aware of any better methods to detect that than ck-list-sessions | 16:15 |
| stgraber | oh, that actually makes sense ;) | 16:15 |
| stgraber | I think it'd be best to parse $DISPLAY to avoid relying on consolekit | 16:17 |
| stgraber | basically if $DISPLAY is set and contains something before the :, then it's remote (except for 127.0.0.1 but I haven't seen anyone use that yet) | 16:18 |
| alkisg | Local: :0.0, ssh -X: localhost:13.0 (-xshm should work there), let me check fat clients... | 16:18 |
| alkisg | Fat: :7.0, Thin: ip:7.0 | 16:19 |
| alkisg | So it sounds ok, with the downside that ssh -X won't use shared memory, which is pretty minor... I'll propose that in a scratch bug report | 16:19 |
| alkisg | Ty | 16:19 |
| stgraber | right, if you want the code to be absolutely right, you'd need to check for localhost/127.0.0.1/<any ip set on the machine> but that'd make the code quite a bit more complicated | 16:22 |
| alkisg | It does sound strange though that X shm functions are not automatically enabled/disabled... X could surely know if the server is remote or local to the client... | 16:23 |
| alkisg | But anyway what can we do :) | 16:23 |
| alkisg | stgraber: which way would be faster to get a precise backport? (1) fix it in debian, wait for R sync, then file SRU, or (2) fix it in R, file SRU? (and then file a bug report in debian, where I don't really care how much log it will need to be committed)? | 16:42 |
| alkisg | *long | 16:43 |
| stgraber | alkisg: fixing in R and then SRU is faster | 16:52 |
| * alkisg just sent the debian bug report | 16:52 | |
| alkisg | I'll make an R bug report as well | 16:53 |
| alkisg | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692587 (will be available in a bit..) | 16:54 |
| ubottu | Debian bug 692587 in scratch "Don't use -xshm for remote displays" [Normal,Open] | 16:54 |
| alkisg | https://bugs.launchpad.net/debian/+source/scratch/+bug/1076036 | 16:57 |
| ubottu | Launchpad bug 1076036 in scratch (Ubuntu) "Don't use -xshm for remote displays" [Undecided,New] | 16:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!