IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 28 December 2008   (all times are UTC)

00:22aristidezzz has joined #ltsp
00:24Ryan52 has quit IRC
00:26|Ryan52 has joined #ltsp
00:49warren has quit IRC
00:55Egyptian[Home] has quit IRC
00:56Egyptian[Home] has joined #ltsp
01:01japerry has quit IRC
01:04alkisg has joined #ltsp
01:08japerry has joined #ltsp
01:18|Ryan52 is now known as Ryan52
01:48hanthana has joined #ltsp
02:20aristidezzz has quit IRC
02:25warren has joined #ltsp
02:39hanthana has quit IRC
02:51BrunoX1ambert has joined #ltsp
02:56warren has quit IRC
03:03BrunoXLambert has quit IRC
03:14warren has joined #ltsp
03:19usman has joined #ltsp
03:23
<usman>
hello i am using fedora 9 and i want to make it a LTSP server , i have two LAN cards in this machine , but i don't know how to configure LTSP properly
03:23
i want that eth0 serves the LTSP client and eth1 is connected to a LAMP server
03:24
<warren>
usman: eth1 connected to a LAMP server means what?
03:24
usman: where would it get internet from?
03:24
usman: and did you read the InstallGuide?
03:25
<usman>
warren: well i am not using internet , i just made two Database Servers
03:25
by eth1
03:26
<warren>
Did you follow the InstallGuide?
03:26
the server must be online to run the ltsp-build-client where it downloads stuff to install /opt/ltsp/i386
03:27
<usman>
warren: well i am not sure of which Install Guide you are saying, i only read about k12 linux
03:27
<warren>
the directions at k12linux.org should be what you need
03:28alkisg has quit IRC
03:28
<warren>
usman: can you reinstall the LTSP server? the F10 media is ready for download
03:28
you can install a preconfigured LTSP server from that media
03:29
<usman>
warren: you mean fedora 10
03:29
<warren>
yes
03:29
usman: http://alt.fedoraproject.org/pub/alt/ltsp/k12linux/f10/untested2/
03:30
usman: I am soon releasing this, only updating the documentation first
03:30
<usman>
warren: man that will be nice , i only need it for testing purpose
03:30
<warren>
usman: you can boot from this liveusb or livedvd image without installing anything on the hard drive
03:30
it can serve netboot thin clients directly from demo mode
03:31
<usman>
warren: ok but there can be a small problem
03:52usman has quit IRC
04:13hanthana has joined #ltsp
04:43alkisg has joined #ltsp
05:34BrunoX1ambert is now known as BrunoXLambert
05:51dirigeant has quit IRC
06:03sepski has joined #ltsp
06:11sepone has joined #ltsp
06:17sepski has quit IRC
06:26sepski has joined #ltsp
06:39toscalix has joined #ltsp
06:44sepone has quit IRC
06:44sepone has joined #ltsp
06:47sepski has quit IRC
06:58toscalix has quit IRC
07:00sepski has joined #ltsp
07:01Barbosa has joined #ltsp
07:04alkisg1 has joined #ltsp
07:04|Paradox| has quit IRC
07:04cmg has joined #ltsp
07:04cmg is now known as |Paradox|
07:05alkisg has quit IRC
07:05alkisg1 is now known as alkisg
07:20sepone has quit IRC
07:20sepone has joined #ltsp
07:24Barbosa has quit IRC
07:30sepski has quit IRC
07:31sepski has joined #ltsp
07:52sepone has quit IRC
08:10gate_keeper_ has quit IRC
08:32sepski has quit IRC
08:33gentgeen__ has quit IRC
09:15Sarten-X has quit IRC
09:20phantom has joined #ltsp
09:20F-GT has quit IRC
09:37cib0 has joined #ltsp
09:37
<cib0>
hello
09:38
does anyone where i can find an example for lts.conf under debian and where i must put them? the documentation isn't very helpful
09:39
<alkisg>
!lts.conf
09:39
<ltspbot>
alkisg: "lts.conf" is http://wiki.ltsp.org/twiki/bin/view/Ltsp/LtsConf
09:39|Paradox| has quit IRC
09:40|Paradox| has joined #ltsp
09:41
<cib0>
whuh, it seems to still be unter /opt on my system, is the debian testing package that old?
09:41
<alkisg>
I don't use Debian, but AFAIK it's like ubuntu: there isn't a default lts.conf in /var/lib/tftpboot/ltsp/i386, but it's there that you should put it
09:42
<cib0>
ah, i see
09:42
<alkisg>
If you put it in /opt, you'll have to rebuild the image for every change in lts.conf...
09:43
<cib0>
if i create a new lts.conf, will it clear some values or only overwrite those i set myself?
09:43
<alkisg>
Only the things you specify will change, nothing else
09:43
Remember to put a [Default] stanza on top
09:44
<cib0>
ok, thanks
09:47Eghie has joined #ltsp
09:51|Paradox| has quit IRC
10:16gate_keeper_ has joined #ltsp
10:29|Paradox| has joined #ltsp
10:38johnny has quit IRC
10:38johnny has joined #ltsp
11:25hanthana has quit IRC
11:28rjune_ has quit IRC
11:28leio has quit IRC
11:28pscheie has quit IRC
11:28EAG has quit IRC
11:28yanu has quit IRC
11:28jcastro has quit IRC
11:28twinprism has quit IRC
11:28xmagixx has quit IRC
11:34leio has joined #ltsp
11:34pscheie has joined #ltsp
11:34twinprism has joined #ltsp
11:34xmagixx has joined #ltsp
11:34EAG has joined #ltsp
11:34yanu has joined #ltsp
11:34jcastro has joined #ltsp
11:37Ahmuck has joined #ltsp
11:41
<stgraber>
ogra: did you see my ltspfs sync request ? (Bug #311873)
11:42tarbo has quit IRC
11:43Patina has quit IRC
11:43Patina has joined #ltsp
11:47rjune_ has joined #ltsp
12:11alkisg has quit IRC
12:24alkisg has joined #ltsp
12:26vagrantc has joined #ltsp
12:43aristidezzz has joined #ltsp
12:55Ryan52 has quit IRC
12:55|Ryan52 has joined #ltsp
13:07|Ryan52 is now known as Ryan52
13:29Ahmuck has quit IRC
13:40alkisg has quit IRC
13:54johnny has left #ltsp
14:03
<stgraber>
vagrantc: hey, I was wondering, how do you handle the init scripts on the thin client in Debian ?
14:04
vagrantc: are you using the upstream ones ? or do you have your own ?
14:04
(because I'm trying to improve the situation in Ubuntu where we currently have our own that need syncing with upstream)
14:08
<vagrantc>
stgraber: upstream
14:08
stgraber: it's a little wonky, but i copy them into place from upstream, and apply patches if needed (currently none)
14:09
stgraber: my packaging branches are all mirrored at: https://code.launchpad.net/~vagrantc
14:10
i'm noticing that the current screen-session.d/XS* scripts for some reason detect X_DEVICE_OPTION even when none is set
14:10
at least on my lenny/experiemental setup
14:12
i'm also experimenting with fewer calls to >> ${XCONF} ... so each *_hacks function would just care for outputting to stdout, and then the assembleXorgConf function would actually handle the appending to ${XCONF}
14:13
<stgraber>
yeah, XS scripts shouldn't edit XCONF directly at least it was the initial goal :)
14:13
<vagrantc>
it also seems like we don't write a screen session if no screen_hacks are defined ... so i'm ending up with a /var/run/ltsp-xorg.conf that has only a Device section
14:13
does that work?
14:13
<stgraber>
yeah
14:13
<vagrantc>
i.e. only a Device section?
14:13
<stgraber>
yes, that works
14:14
<vagrantc>
in debian lenny, xorg doesn't seem to respect monitor settings unless it's explicity mentioned in the Screen section
14:14
<stgraber>
on my lappy I only have a Device section including a Device name and a Driver and it works fine (on Intrepid with xorg 1.5)
14:17
vagrantc: I was wondering, is there a way (clean if possible) to basically use initrscripts/... then use dpatch or similar on that and then move it to debian/ so it's handled by dh_installinit ?
14:17
(I'm currently on my netbook and haven't download your packaging branch yet)
14:17
<vagrantc>
stgraber: that's what i do
14:18
<stgraber>
cool, I really need to look at your debian/ :)
14:18
is there any other distros using the upstream init scripts ?
14:18alkisg has joined #ltsp
14:19
<vagrantc>
stgraber: i forget which, but i think *some* other distro is using them... maybe opensuse? but i know fedora and gentoo have their own ... not even initscripts
14:19
or something :)
14:19
<stgraber>
hmm, ok so we should avoid any debian-specific bit in there ...
14:20
<vagrantc>
or we'll hear a bit of yelling and deal with it :)
14:20
<stgraber>
:)
14:20
<vagrantc>
stgraber: where are you based, by the way?
14:24
<stgraber>
Sherbrooke, QC, Canada
14:25
(moved there 4 months ago)
14:25
<ltsppbot>
"vagrantc" pasted "only have assembleXorgConf handle outputting to XCONF" (143 lines) at http://pastebot.ltsp.org/150
14:26
<vagrantc>
stgraber: how's that look to you?
14:26
only risk i see if someone uses a noisy tool to detect their *_hacks stuff ...
14:28
the other idea i was was to put it in write_screen 0 >> ${XCONF} ... but then you might end up with an empty xorg.conf if for some reason none of the sections produced anthing.
14:28
<stgraber>
the diff looks good. We'll just have to make sure to redirect any output to /dev/null if we don't want it to end up in xorg.conf :)
14:28Sarten-X has joined #ltsp
14:28
<vagrantc>
stgraber: worth pushing?
14:29
<stgraber>
yeah and IIRC X doesn't start with a blank xorg.conf
14:29vvinet has joined #ltsp
14:29dirigeant has joined #ltsp
14:29
<stgraber>
vagrantc: yeah, go ahead
14:30
vagrantc: something else we might want to do is to put the PCIID (product and vendor) of the Video card in the environment as I think multiple scripts will use them
14:30
that'll also reduce the risk of having a bad implement of lspci fail on some distro and output to xorg.conf
14:32
<vagrantc>
so far, all the lspci calls happen only with variable setting, rather than inside of the *_hacks functions
14:33
<stgraber>
ah, right
14:34
<vagrantc>
if possible, the functions should only output stuff, and whatever fancy variable setting should happen elsewhere
14:36
i don't understand why XS85-xserver-device-options is triggering generation of an xorg.conf
14:36
env | grep X_DEVICE_OPTION ...
14:39
<stgraber>
vagrantc: well, the first part of the scripts export all X_DEVICE_OPTION_XX
14:39
<vagrantc>
none of which are set
14:40
<stgraber>
vagrantc: so X_DEVICE_OPTION_01 is matched by that grep
14:40
<vagrantc>
an empty X_DEVICE_OPTION ?
14:40
<stgraber>
stgraber@sahal:~/ltsp-trunk/client/screen-session.d$ export X_DEVICE_OPTION_01=""
14:40
stgraber@sahal:~/ltsp-trunk/client/screen-session.d$ env | grep X_DEVICE_OPTION
14:40
X_DEVICE_OPTION_01=
14:42
<vagrantc>
aha.
14:42
i thought that looked a bit wonky.
14:44
<stgraber>
[ -n "$X_DEVICE_OPTION_10" ] || [ -n "$X_OPTION_10" ] export X_DEVICE_OPTION_10=${X_DEVICE_OPTION_10:-${X_OPTION_10}}
14:45
<vagrantc>
heh.
14:45
<stgraber>
(or anthing better looking/faster/cleaner, I don't quite like that code :))
14:45
<vagrantc>
yeah.
14:47edoardo has joined #ltsp
14:47
<edoardo>
Hey you guys
14:47
Is cyberorg online?
14:48
I'm trying to run sane under KIWI-Ltsp, and it is proving quite difficult, indeed.
14:48
There virtually being no referncing on Google, too.
14:52
There are pointers about doing it in different LTSP setups, but not on KIWI.
14:52
Any clues?
14:53
<warren>
stgraber: "something else we might want to do is to put the PCIID (product and vendor) of the Video card in the environment"
14:53
stgraber: good in theory, but how do you know which to put there?
14:53
stgraber: what happens if there is more than one?
14:54
stgraber: the hacks we have upstream so far are only triggered on chipsets that can't possibly have another
14:55
<stgraber>
right, we haven't yet looked at what happens when you have two video cards :)
14:55
<warren>
I mean, the current hacks are not a problem with two video cars
14:55
cards
14:55
because they wont matc
14:56
stgraber: oh, unless you were proposing storing the entire output of lspci in an env string
14:57
stgraber: which would be fine... and we can avoid running lscpi multiple times
14:57
<stgraber>
well, I initially planned to stock a lspci -n | grep VGA
14:57
which I think should be good in most case but a whole lspci is also possible
14:58vvinet has quit IRC
14:58
<warren>
lspci -n | grep VGA would never output anything
14:58
<stgraber>
hmm, right :)
14:59
what about lspci -nn | grep VGA ?
14:59
<warren>
does every video appear as VGA?
15:00
stgraber: lspci -n might be better, because we might want to detect against other devices in the future.
15:00
lspci -n is also smaller
15:00
lspci -n can work with less stuff in the chroot
15:01
<stgraber>
right, as long as nobody wants to match against the board name (which currently isn't the case)
15:02
<warren>
oh wait
15:02
stgraber: I do match against the board name...
15:02
stgraber: a wide range of different ATI Rage 128's on ppc are broken
15:03
<stgraber>
ah right, just noticed ppc-r128-hack
15:03
so we'd need lspci -nn then
15:20
<vagrantc>
are X_DEVICE_OPTION_NN the new options, or X_OPTION_NN the new ones?
15:20
i.e. ltsp 4.x vs. 5.x
15:31
stgraber: wait a minute... you're living in sherbrooke? as in the song "barret's privateers?"
15:32
http://en.wikipedia.org/wiki/Barrett%27s_Privateers
15:32* vagrantc hopes to give that a good singing at the next hackfest
15:36
<stgraber>
vagrantc: doesn't seem to be the same sherbrooke but spelling is the same :)
15:47alkisg has quit IRC
15:55warren has quit IRC
16:05BrunoXLambert has quit IRC
16:17Sarten-X has quit IRC
16:21johnny has joined #ltsp
16:25sterne has joined #ltsp
16:27
<vagrantc>
hm.
16:28
in order to get X_HORZSYNC And X_VERTREFRESH to register, it requires a screen section pointing to a monitor
16:31ogra has quit IRC
16:46ogra has joined #ltsp
17:02|Paradox| has quit IRC
17:03|Paradox| has joined #ltsp
17:04Sarten-X has joined #ltsp
17:08
<cib0>
hm, in what file is the resolution for the thin clients stored_
17:08
<johnny>
nowhere by default
17:08
it is discovered
17:09
by asking the monitor
17:09
<cib0>
ah, where can i specify it manually?
17:09
im running it on virtualbox and that one doesnt handle the situation very well :p
17:10
<johnny>
you need to install the vbox drivers
17:10
then it might work correctly
17:16
<vagrantc>
virtualbox seems to crash when using xrandr, which is how the resolution gets set
17:17
cib0: i usually reduce the video memory on virtualbox clients down to 1MB, and then it comes up as 800x600
17:19phantom is now known as F-GT
17:19F-GT has joined #ltsp
17:20cib0 has quit IRC
17:25kaufe has joined #ltsp
17:25|Paradox| has quit IRC
17:25kaufe is now known as |Paradox|
17:27alkisg has joined #ltsp
17:34sterne has left #ltsp
17:55Eghie has quit IRC
18:20J45p3r__ has joined #ltsp
18:21J45p3r__ has left #ltsp
18:29alkisg has quit IRC
18:41dirigeant has quit IRC
18:48
<vagrantc>
heh. debian's been shipping ldm with a dependency on gtk2-engines-clearlooks for ages, but i don't think it actually needs it at all. and the pretty-ification that clearlooks gives it wasn't working.
18:49
talk about a waste.
18:50
i'm considering defaulting to gtk2-engines-ubuntulooks for debian, as the package is only 160k installed, vs. 1.2m
18:56* vagrantc finds it all kind of ironic
19:04
<Ryan52>
the other one is installed anyway.
19:04
isn't it?
19:05
<vagrantc>
it's installed, but unused.
19:06* Ryan52 is talking about clearlooks
19:06
<vagrantc>
gtk2-engines (which provides gtk2-engines-clearlooks) is installed, but un-used.
19:07
i built packages which only recommend on gtk2-engines*, removed all gtk2-engines* packages, and you still get the same, slightly ugly theme that ldm has had all along.
19:07
<Ryan52>
ldm depends on libgtk2.0-0 which depends on gtk2-engines
19:08
wiat, does it? /me thinks he might be insane
19:09
nevermind then...
19:11
<vagrantc>
i think it's just raw gtk, no?
19:15
hmmm... i'm tempted to patch it (back) to use ubuntulooks for debian, and recommend gtk2-themes-ubuntulooks, just due to the size issues.
19:15
but it feels weird.
19:40japerry has quit IRC
19:44Faithful has joined #ltsp
19:48japerry has joined #ltsp
19:49vagrantc has quit IRC
19:53vagrantc has joined #ltsp
20:15
<stgraber>
vagrantc: in Jaunty I now depend on murrine and ldm really looks good then
20:17
(It depends on human-theme which in turn depends on dmz-cursor-theme, human-icon-theme, gtk2-engines-murrine)
20:18
vagrantc: the main issue with gtk theming is to have the right gtkrc in the ldm theme directory
20:22
<vagrantc>
stgraber: don't have "human-theme" yet, but have the others
20:23
<stgraber>
I'm not sure if human-theme does actually something more than depends on the others, looks like a meta package to me
20:23
<vagrantc>
ah
20:23
<stgraber>
hmm, no it's in fact the package that contains the gtkrc :(
20:23
<vagrantc>
well, i'm certainly not real artwork savvy
20:24
<stgraber>
yeah but unthemed gtk is usually ugly :)
20:24* vagrantc uploads ldm 2.0.27-1 to experimental
20:24
<vagrantc>
stgraber: that's what the default has been in debian for ages
20:25
stgraber: though ldm 2.0.27-1 should hit experimental in a few hours, which at least uses ubuntulooks ...
20:25
<stgraber>
and you got nobody complaining ?
20:26
<vagrantc>
small complaints here and there, but nobody with any idea how to improve it
20:26
<stgraber>
I had one of the Jaunty upload using a non-existent theme (which should look the same as what you currently have) and got complaint two hours afterwards :)
20:26
<vagrantc>
heh
20:27
<stgraber>
it's probably the: It was good looking, now it's ugly, you broke it !! thing
20:27
<vagrantc>
i think many of the debian ltsp users have their own themes anyways
20:27
<stgraber>
right
20:27
<vagrantc>
i wonder what it would take to play with gtk2-engines-murrine and all that other stuff
20:28
<stgraber>
we could probably do some nice stuff playing with murrine but it's not really something I'm good at :)
20:28
<vagrantc>
just a tweaked gtkrc, i'm guessing
20:32
<stgraber>
vagrantc: do you have a link to 2.0.27 orig.tar.gz ?
21:03
vagrantc: nevermind, just did another tarball :)
21:39
<vagrantc>
stgraber: http://incoming.debian.org/ldm_2.0.27.orig.tar.gz
21:40
would be good to use the same tarball, just to avoid annoying diffs with the auto-generated makefiles and such
21:40
oh wow. looks like incoming.debian.org is processed 4 times a day now, instead of 2.
21:41
stgraber: should be at http://incoming.debian.org for another 4 or so hours
21:42japerry has quit IRC
21:44
<stgraber>
vagrantc: well, too late mine is already uploaded to Jaunty ...
21:45
vagrantc: that's weird, when you told me you uploaded it I first checked in incoming and it wasn't there ...
21:45japerry has joined #ltsp
21:48
<vagrantc>
stgraber: sometimes it takes a while to go live
22:01CaScAdE^FarAway has joined #ltsp
22:01* vagrantc plays with gtk2-themes-murrine
22:02
<stgraber>
vagrantc: does it work ?
22:07
<vagrantc>
stgraber: yeah.
22:08
dmz-cursor-themes is also nice to have, although the package is moderately large
22:09
can't just s,clearlooks,ubuntulooks, in the gtkrc, though
22:09
er, s,clearlooks,murrine,
22:09
works fairly well with ubuntulooks
22:10
there's a murrine-themes package, and i've tried a couple of the gtkrc's that come from those
22:10
looks nice
22:11CaScAdE^1arAway has quit IRC
22:16japerry has quit IRC
22:17japerry has joined #ltsp
22:22
<stgraber>
it's like the 30th bug or so I close tonight ... we really have a lot of crap on launchpad :)
22:22
<vagrantc>
heh
22:27
i haven't actually closed many reported with uploads ... though there aren't a whole lot of bugs reported
22:27
though certainly closed many bugs upstream
22:28
<stgraber>
I closed an upstream ldm bug tonight but most of the bugs were ltsp-cluster (most of them being closed as not being related to ltsp-cluster) and some are ubuntu bugs for ldm/ltsp packages
22:28
things like: The automated testing xyz failed while installing ltsp-client-core :) (which is the normal behavior on a non-ltsp system)
22:29
and a few other user-related bugs, not that much upstream bugs actually :)
22:35Gadi has joined #ltsp
22:35
<Gadi>
hey, guys
22:35
<vagrantc>
hi!
22:35
<Gadi>
vagrantc: a quick thx for those recent commits
22:35
cleaned up some of my sloppiness
22:35
:)
22:35
<vagrantc>
yeah.
22:36
i'm also looking to kill some of the [ -z "$FOO" ] && \ blah blah
22:36
two-liners
22:36
<Gadi>
sounds good
22:36
<vagrantc>
if it's more than a line, we should use a full if ; then ; fi
22:36* vagrantc despises \
22:37
<Gadi>
btw, speaking of bugs, I think I had squashed one of the localdev bugs recently thats on lp
22:37
wrt non-latin chars
22:37
<vagrantc>
in ltspfs ?
22:37
<Gadi>
yeah
22:37
I added LOCALDEV_MOUNT_OPTIONS
22:37
<stgraber>
Gadi: will you be around tomorrow ?
22:37
<Gadi>
and a stanza that adds utf8 by default for vfat, iso9660, and ntfs
22:38
stgraber: should be
22:38
<stgraber>
Gadi: ok, there won't be much people at the office tomorrow so I'll be able to get that Windows box for rdesktop testing
22:39
<Gadi>
ah, good
22:39
I realized on Friday what I was missing
22:39
wrt the xauth stuff
22:39
<stgraber>
Gadi: I had a quick look at your ltspfs branch, do you have a package of it ? (I noticed you change one of the .c so needing compilation of the new code)
22:39
<Gadi>
but, I still think its better if we disable the xauth checking on local connections
22:40
that change was to disable auth checking for local connections
22:40
we *may* be able to do without it
22:40
but, I think it will be better if we dont
22:40
I mean, I think it makes more sense for ltspfs to be a pure automounter when run locally
22:40
as opposed to expecting multiple users on the local system
22:41
<stgraber>
yeah
22:41
<Gadi>
(multiple concurrent users, that is)
22:41
<stgraber>
all I want is all the mountpoints to appear in a (known) directory :)
22:41
<Gadi>
heh
22:41
we'll get there
22:41
<stgraber>
then I can use some -r disk: magic
22:41
<Gadi>
ultimately, we should have:
22:41
-r disk:drives=/media
22:41
and be done with it
22:42
<stgraber>
sounds good
22:43
<Gadi>
I may even donate my rdesktop wrapper script to the cause
22:43
which has a bunch of automagic stuff
22:43
but, I need to hammer this stuff out first
22:44
so, I can take the hackish stuff out
22:44
:)
22:44
<stgraber>
hehe :)
22:44
<Gadi>
btw: where do you put ldm-dialog in your package?
22:45
/usr/sbin?
22:45
<stgraber>
hmm, that's a good question, let me ssh a thin client :)
22:45
Gadi: btw, I have intrepid backports for ldm, ltsp and ltspfs in my ppa (often more up to date than jaunty :))
22:45
<Gadi>
good to know
22:45
when is jaunty freeze?
22:46
<stgraber>
/usr/bin/ldm-dialog
22:46
<Gadi>
ah, good
22:46
<stgraber>
Gadi: sometimes in february I think
22:46
<Gadi>
I need to de-zenity-ize my dialogs
22:48Ahmuck has joined #ltsp
22:49
<stgraber>
+ . /usr/share/ltsp/screen-session.d/XS85-xserver-device-options
22:49
+ unset X_DEVICE_OPTION
22:49
+ export X_DEVICE_OPTION_01="VBEModes" "true"
22:49
export: 1: "true": bad variable name
22:49F-GT has quit IRC
22:49
<stgraber>
Gadi: is that your fault ? ^ :)
22:49
(I'm not running the latest upstream, it may have been fixed by then)
22:50
<Gadi>
hmm - yeah, vagrant's code may fix that
22:50F-GT has joined #ltsp
22:51
<Gadi>
damn quotes :p
22:52
<stgraber>
ok, trying the latest screen-session.d from upstream, let's see if it improves things
22:54
if it works, I'll probably tag a new ltsp-trunk tommorrow
22:54
<vagrantc>
stgraber: yeah, latest upstream is pretty different
22:54
<Gadi>
vagrantc: did you say you needed to add a Monitor line to the Screen section?
22:55
to get the sync ranges to work?
22:55
<stgraber>
argh, VIA crap ... that thin client crashed when I was trying to make it reboot with the new code ...
22:56
<Gadi>
we should get that into upstream before tagging again
22:56* Gadi wonders if screen_hacks should force monitor_hacks to run and include a Monitor "Monitor0" line
22:57
<Gadi>
this new Xorg is great - but can be quite mysterious
22:57
:)
23:03
<vagrantc>
Gadi: yes. without a Monitor line in the Screen session, it ignored the sync ranges
23:03
<Gadi>
well, if we have a monitor line, we should have a monitor section, too
23:03
even if empty
23:04
<vagrantc>
Gadi: but what i don't know is if newer versions have the same problem ...
23:04
<Gadi>
newer versions?
23:04
of Xorg?
23:04
<vagrantc>
i'm still using xserver-xorg-core 1.4.2
23:04
<Gadi>
still
23:04
<vagrantc>
well, 2:1.4.2-9
23:04
<Gadi>
we should support both
23:04
imho
23:04
may I add it?
23:04
<vagrantc>
Gadi: i've already got some code to handle it, sort of.
23:05
Gadi: what are you thinking
23:05
?
23:05
<Gadi>
well, I would add the monitor line to the write_screen function
23:05
and add a conditional
23:06
for: if screen_hacks -> monitor_hacks
23:06
actually
23:06
<vagrantc>
i was thinking of just setting an appropriate screen_hack in the sync-ranges plugin
23:06
<Gadi>
if write_screen -> write_monitor
23:06
<vagrantc>
well, that's what i did
23:07* Gadi is afraid that it would be true of all screen hacks
23:07
<vagrantc>
is there an issue with always writing out all sections if any need to be written?
23:07* Gadi shrugs
23:07
<Gadi>
actually, wait
23:07
sync ranges are monitor hacks
23:07alkisg has joined #ltsp
23:07
<Gadi>
not screen hacks
23:08
why did it print in screen for u?
23:08
<vagrantc>
yes, but you need to put the monitor line into a screen hack?
23:08
<Gadi>
so, you need a screen section
23:08
<vagrantc>
no, if i generate the Monitor section, i need to generate a screen section with the Monitor section referenced in it
23:08
<Gadi>
not just a monitor section
23:08
gotcha
23:08
hmm...
23:09
<vagrantc>
the way i implemented it was to add a screen_hack to add the monitor section...
23:09
<Gadi>
right, but perhaps it should always do that
23:09
ie add that screen_hack to the write_monitor function
23:09
<vagrantc>
i have no idea
23:10
<Gadi>
and move the write_monitor function above write_screen
23:10
<vagrantc>
it's all black magic to me
23:10
<stgraber>
I don't think it's sync range specific
23:10
<vagrantc>
who committed the stuff where it only writes the sections that are needed, and why?
23:11
<stgraber>
I guess that the Monitor section needs to be referred from the Screen section to work (sounds weird though)
23:11
<vagrantc>
i'm just curious, because i don't know this modern X.org stuff well
23:11
<Gadi>
I prolly did
23:11
but only under the assumption that with new Xorg less is more
23:11
<stgraber>
vagrantc: because for things like Device you don't need a Screen/Monitor/... section so it was weird to generate an empty section in that case
23:11
<vagrantc>
maybe weird, but is it harmful?
23:11
<Gadi>
ie only give it incremental diffs
23:12
<vagrantc>
overall, i like the idea, there just may be some glitches
23:12
it definitely didn't need the Device referenced ...
23:13
so we could just hard-code the monitor in it
23:13
but i have no idea how that plays out with multiple monitors...
23:13
<Gadi>
well, atm we only support one monitor with xorg.conf (multi only with xrandr)
23:14
<vagrantc>
is that "atm" likely to stay that way?
23:14
<Gadi>
likely
23:14
I think everything is moving to xrandr1.2 support
23:14
everything = drivers
23:14
should be true for nvidia, ati, intel, via
23:14
at very least
23:15
and for others, there is always X_CONF
23:15
for multimonitors
23:16
<ltsppbot>
"vagrantc" pasted "always add monitor if monitor_hacks is defined" (18 lines) at http://pastebot.ltsp.org/151
23:16gate_keeper_ has quit IRC
23:16
<vagrantc>
how's that?
23:17
<Gadi>
well, that wont produce a monitor section, will it?
23:18
because monitor_hacks may be empty
23:18
<vagrantc>
if monitor_hacks is set, it will.
23:18
<Gadi>
ah, wait
23:18
ur right
23:18
<vagrantc>
using the same conditions for adding it that will trigger it to be generated
23:18
<Gadi>
right
23:19
looks good
23:19
<vagrantc>
that'll make it possible to fix the bug i was having at freegeek with a thin-client connected through a KVM
23:19
by setting the sync ranges stuff
23:19
<Gadi>
cool
23:20
yeah, KVMs can be evil
23:20
I have had some BIOSes that will take forever to come back from X -configure through a KVM
23:21
<vagrantc>
we could also use: echo 'Section "FOO"' instead of echo "Section \"FOO\""
23:21
but i think i'll save those changes for another day
23:23* Gadi calls it a night
23:23
<Gadi>
catch you guys tomorrow
23:23Gadi has left #ltsp
23:24
<vagrantc>
pushing ...
23:25
might try and tag and upload ltsp-trunk tonight, or maybe tomorrow morning
23:32Ahmuck has quit IRC
23:43Ahmuck has joined #ltsp
23:53
<vagrantc>
stgraber: i noticed the LANG for localapps stuff isn't using the stuff gotten from ~/.dmrc
23:55aristidezzz has quit IRC