[16:13] <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:14] <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:15] <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:17] <stgraber> I think it'd be best to parse $DISPLAY to avoid relying on consolekit
[16:18] <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:19] <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:22] <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:23] <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:42] <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:43] <alkisg> *long
[16:52] <stgraber> alkisg: fixing in R and then SRU is faster
[16:52]  * alkisg just sent the debian bug report
[16:53] <alkisg> I'll make an R bug report as well
[16:54] <alkisg> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692587 (will be available in a bit..)
[16:57] <alkisg> https://bugs.launchpad.net/debian/+source/scratch/+bug/1076036