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


Channel log from 24 January 2010   (all times are UTC)

00:59alkisg has joined #ltsp
01:34artista-frustrad has joined #ltsp
01:37Egyptian[Home] has left #ltsp
01:53artista-frustrad has quit IRC
02:10artista-frustrad has joined #ltsp
02:16Kicer86 has joined #ltsp
02:30artista_frustrad has joined #ltsp
02:32artista-frustrad has quit IRC
02:45Kicer86 has quit IRC
02:51artista_frustrad has quit IRC
04:14rhodan_ has joined #ltsp
04:21rhodan has quit IRC
04:39alkisg1 has joined #ltsp
04:40alkisg has quit IRC
05:52artista_frustrad has joined #ltsp
06:11artista-frustrad has joined #ltsp
06:11artista_frustrad has quit IRC
06:19mikkel has joined #ltsp
06:28artista has joined #ltsp
06:29artista-frustrad has quit IRC
07:00lucascoala has joined #ltsp
07:25artista has quit IRC
07:26artista-frustrad has joined #ltsp
07:34alkisg1 is now known as alkisg
08:23alkisg has quit IRC
09:27gentgeen__ has joined #ltsp
09:58gentgeen__ has quit IRC
10:00gentgeen__ has joined #ltsp
10:01_gentgeen_ has quit IRC
10:28sene has quit IRC
10:30_gentgeen_ has joined #ltsp
10:40alkisg has joined #ltsp
10:40_gentgeen_ has quit IRC
10:41sene has joined #ltsp
10:43vagrantc has joined #ltsp
10:44_gentgeen_ has joined #ltsp
10:50_gentgeen_ has quit IRC
11:16rhodan_ has quit IRC
11:18rhodan has joined #ltsp
11:19pmatulis has joined #ltsp
11:24
<vagrantc>
stgraber: get a chance to test the new group handling?
11:33lucascoala has quit IRC
11:37mikkel has quit IRC
11:39etyack has joined #ltsp
11:41artista-frustrad has quit IRC
11:41etyack has joined #ltsp
11:49
<alkisg>
vagrantc, I'd like to correct the IFS handling, but I'm in doubt about what of the following to use:
11:49
(1) test "$oldifs" = "not set" && unset IFS || IFS="$oldifs"
11:49
(2) if [ "$oldifs" = "not set" ]; then unset IFS; else IFS="$oldifs"; fi
11:49
(3) the same `if` written in 4 separate lines
11:49
I think I'd go for (2) but I'm not sure if it's acceptable by our CodingStyle...
11:50
<vagrantc>
we wrote the codingstyle down somewhere...
11:51
pfft. README_DEVELOPMENT_POLICY is an empty file.
11:51
alkisg: from what i recall, one-liners should be like the 1st one.
11:51
alkisg: if you use if [ ] ... it should be split on multiple lines.
11:52
<alkisg>
Yup.... it's just less readable than (2) :-/
11:52
<vagrantc>
alkisg: so 1 and 3 were acceptible.
11:52
<alkisg>
I'd go for 1 then, it's more "copy/paste-able"
11:52
<vagrantc>
alkisg: i think a full if statement is really hard to read on one line.
11:52
so it's a matter of personal preference.
11:53
<alkisg>
The whole IFS thing needs attention, so even in (3), the developers reading it would need to read about the {-} operator... so I don't mind that (1) looks a bit more cryptic...
11:53litlebuda has joined #ltsp
11:54
<alkisg>
OK, I'll commit something based on (1).
11:55
<vagrantc>
alkisg: that doesn't use the {-} thing at all?
11:55
<alkisg>
vagrantc: all those cases start with: oldifs="${IFS-not set}"
11:56
http://ltsp.pastebin.com/m59481063
11:56
<vagrantc>
we sure make extensive use of IFS ...
11:57
alkisg: ah, that was just the restore portion of the code...
11:57
<alkisg>
Yup
11:57
<vagrantc>
alkisg: so it'll be one line at the top, and one line at the bottom?
11:57
<alkisg>
Right
11:57
<vagrantc>
of a given block of code
11:57
that's about as close to good as we can get :)
11:57
<alkisg>
Unless of course if we use (3) :)
11:58
OK, committing something with (1), and I'll send a mail to ltsp-developers talking about it, as it's not something obvious.
11:59
<vagrantc>
and woe to the fool who attempts nested IFS values.
11:59
<alkisg>
If it's inside a function, oldifs should be declared local
11:59
If it's outside a function, well, woe :)
12:00
<vagrantc>
i think it's woe in either case.
12:00
it's just plain painful
12:00
<alkisg>
Maybe tr should be used instead of IFS in most cases...
12:00
The performance hit wouldn't be so bad to justify all the possible side effects...
12:01
<vagrantc>
well, parsing /proc/mounts, /etc/group and /etc/passwd is actually so much more elegant with IFS
12:02
but we definitely should be cautious with over-use of IFS for that reason.
12:02
<alkisg>
parsing /proc/mounts doesn't need IFS
12:02
<vagrantc>
ah, true. it's the passwd/group stuff that makes it easier...
12:02
it's basically because shell has stupid handling of spaces.
12:03
<alkisg>
Right...
12:03
<vagrantc>
and that's because it was never intended to be used for such crazy things as we are doing... i'm guessing. :)
12:05
<alkisg>
I do think that we shouldn't bother with saving/restoring IFS at all, though. Just forcing it to ' \t\n' after any changes should be better than saving/restoring it...
12:06
Anyway, commiting (1)...
12:06
<vagrantc>
alkisg: hmmm... good point.
12:06
alkisg: we could make a "use of IFS" policy.
12:07
alkisg: or simply unsetting it.
12:07
<alkisg>
vagrantc: I don't know if all the shells/systems behave well when unsetting it
12:07
E.g. I _rely_ on IFS being ' \t\n' on some cases
12:07
<vagrantc>
alkisg: seems to work fine in bash and dash.
12:07
<alkisg>
If the default IFS on some shell is only ' ', then it'd break some parts of the code
12:07
<vagrantc>
alkisg: that isn't equivalent to the defaults?
12:08
ah, got it.
12:08
<alkisg>
E.g. var=$(echo $var) ==> consolidate spaces, tabs and enters to single spaces ==> doesn't work with IFS=' '
12:09
Anyway, I'll commit (1), and if we want we make explicitly set IFS at the start of each script
12:09
*may
12:27highvolt1ge has joined #ltsp
12:28Appiah has quit IRC
12:36highvolt2ge has joined #ltsp
12:39highvoltage has quit IRC
12:45waldo323 has joined #ltsp
12:54highvolt1ge has quit IRC
12:58waldo323 has quit IRC
13:20
<k-train>
how does one tell what the xorg.conf file looks like of a ltsp-client workstation?
13:23
<vagrantc>
!release
13:23
<ltspbot`>
vagrantc: "release" :: please mention the linux distro and release you're using :)
13:23
<vagrantc>
k-train: ^^
13:23
<k-train>
wow.. i'm such a noob. what does ^^ mean...
13:24
<vagrantc>
k-train: read the previous line
13:24
<highvolt2ge>
k-train: look at the line above
13:24
<stgraber>
alkisg: hello
13:24
<alkisg>
hello stgraber
13:25
<vagrantc>
ideally, we could tell ltspbot to direct the comments at someone in particular... but until then... we're stuck with ^^
13:25
<stgraber>
alkisg: any reason why you didn't use that one-liner you posted yesterday instead of the one you explained on the ML ?
13:25sebas891 has quit IRC
13:25
<stgraber>
is that because the one you commited is easier to read or was there actual technical issue with the other ?
13:25
<alkisg>
stgraber: I prefered a one-liner, and the CodingStyle said we have to use "test" in one-liners
13:26
<vagrantc>
k-train: it's really helpful when you ask a question if we know the context ...so knowing what distro/releaes you're using helps us determine how to best answer your question.
13:26
<alkisg>
stgraber: ah, you mean the "eval" one?
13:26
<highvolt2ge>
stgraber: howdy
13:26
<alkisg>
The eval one wasn't a good solution because it has problems if IFS contains '
13:27
<highvolt2ge>
stgraber: did you get that lucid lxc guest working?
13:27
<vagrantc>
and for our next episode in "Adventures with IFS" ...
13:27
<k-train>
k... sorry. I installed ubuntu 9.10-ltsp a bit ago.
13:27
<stgraber>
highvolt2ge: hey, nope I haven't had the time to look at it, way too much stuff to do and still something like two days late in what I was supposed to do this week ...
13:28
<k-train>
And i have a bunch of old machines that have an intel 815 video chip set and the refresh ir real bad when there is movement on the screen
13:28
<highvolt2ge>
stgraber: ok no problem, I was just wondering
13:28
<stgraber>
highvolt2ge: first issue is that networking issue, then I suspect we have some /dev/pts & /proc issue as well
13:28
alkisg: yep
13:28
ah, ok
13:28
<k-train>
I looked at the ltsp manual and tried many options in the lts.conf file.
13:28
<highvolt2ge>
stgraber: ok, with that info I'll poke a bit with it tonight, maybe I'll get lucky
13:29
<k-train>
link x_video_ram, xserver=810, but nothing seems to help.
13:29
<vagrantc>
k-train: you might try "ltsp-localapps x-terminal-emulator" which should give you an xterm running on the local client
13:29
k-train: and then look in /var/run/ltsp-xorg.conf ...
13:29
<k-train>
thanks tons. i will try that.
13:31highvolt2ge is now known as highvoltage
13:36
<stgraber>
I'm going to do a new upstream snapshot of ltsp-trunk, if testing goes well, I'll likely tag + release 5.1.99 today, any reason I shouldn't ?
13:36
<alkisg>
Yey!
13:38
<vagrantc>
it's probably about time.
13:38
hoping the group changes isn't borked.
13:39
<stgraber>
yeah, that's part of the testing I'll do
13:40
alkisg: did you try the latest package in my PPA, does it boot faster ?
13:40
<alkisg>
stgraber: sorry, I didn't try it, I'm trying to finish my private ltsp plugins for teachers here to test as soon as 5.1.99 is out...
13:42Kicer86 has joined #ltsp
13:52
<k-train>
vagrantc: thank you. I was able to see the ltsp-xorg.conf file on my client. So.. am i right to think that since the 'xserver-xorg-video-intel' package is installed (i tired installing it in the chroot environment for the clients and it said it already existed) that my problems could be solved by simply supplying a xorg.conf file for the client via the lts.conf files that contains the proper parameters for an i815 video chipset?
13:53
<vagrantc>
k-train: it's possible.
13:54
<k-train>
ok... well i'm off to see if my amateur linux self can complete such a task. Thanks again.
13:55
<alkisg>
k-train: what exactly do you see?
13:55
<k-train>
in the ltsp-xorg.conf file?
13:55
<alkisg>
If you login and change the resolution/refresh rate etc, do you still see the problem?
13:55
No, on your screens...
13:59
<k-train>
well.. ultimately things look ok all the time.... minus the poor refresh rates... I can't adjust the display on the clients while they are running because my server has an nvidia graphics card w/ the proprietary drivers installed so when i try to do so it tells me the i have to run nvdia-xconfig
13:59
<stgraber>
ok, uploaded a new ltsp-trunk to my PPA, should take 30min or so to build
13:59
I'll also do one for ldm-trunk
13:59
<k-train>
or maybe i'm expecting too much from the thin clients.
14:01
<stgraber>
ldm-trunk snapshot uploaded
14:02
<alkisg>
k-train: logon on a client, and run this: xrandr
14:02
Then, upload the results to this site: http://ltsp.pastebin.com
14:02highvoltage has quit IRC
14:02
<alkisg>
It'll give you a URL, paste it here so that we can see the output.
14:04
<k-train>
k. i will do that
14:07japerry has joined #ltsp
14:09highvoltage has joined #ltsp
14:18
<k-train>
alkisg: here it is. http://ltsp.pastebin.com/d28b319cf
14:19
<alkisg>
k-train: you can try different resolutions with:
14:19bobby_C has joined #ltsp
14:19
<alkisg>
xrandr --output default --mode 1440x900
14:19
And see if they help...
14:19
<k-train>
ok. i will try that. thank you.
14:19
<alkisg>
If they do, you can make one of those modes the default.
14:21japerry has quit IRC
14:21japerry has joined #ltsp
14:30
<k-train>
alkisg: i tried as you suggested and it appears to have helped a bit. there is one application that "trails the mouse" worse that the others. Does this happen?
14:31
<alkisg>
I'm not really sure what you're seeing...
14:31
I had a problem with the AC current in one of my labs, it messed with the monitors,
14:31
so I was unable to use them in their native resolutions, and I had to lower them
14:32
It had too much flickering and it got worse when someone moved the mouse
14:32Kicer86 has quit IRC
14:32
<alkisg>
If you find a resolution that is better and you want to use it, you can specify it in lts.conf.
14:34
<k-train>
ok. Thanks for the example. I guess i'm not sure what to expect since this is my first go with Linux terminal server stuff. hearing what other people have done helps me to determine if the hard ware is incorrectly setup, or if what i'm asking to be done can't be done. (applicaitons, resolutions, etc) Thanks for your time.
14:35
<alkisg>
np. If it's possible, try to also boot the terminals as normal clients, to see if there's any difference.
14:35
(e.g. if they have >= 512 RAM)
14:36
<k-train>
ok. Thanks. So, in your experience, should the LTS client act the same, visually, as it would as a normal client?
14:37
<alkisg>
With intel clients, yes, because they don't require proprietary drivers.
14:38
<k-train>
Ok. Another quick question, does it matter the video device on the server?
14:38
Is one preferred over another?
14:38
<alkisg>
Yes, the proprietary nvidia/ati drivers shouldn't be installed on the server
14:39
So you could either keep your nvidia, but uninstall the drivers, or you could use another card. Or you could keep using the proprietary drivers and risk some problems.
14:39
<vagrantc>
it's so ridiculous that drivers installed on the server would cause problems with thin clients.
14:39
poorly written code.
14:39
<alkisg>
In Ubuntu there's an effort to separate the proprietary opengl libs from the opensource ones
14:40
The end result will be that ALL drivers can be installed simultaneously
14:40
Even nvidia-96 with nvidia-173 will be able to coexist, and of course only the right one will be used
14:41
If that actually happens, we'll be able to install all drivers to the ltsp chroot, and all clients would work automatically either with the open source or the proprietary drivers... that'd be cool.
14:42
<k-train>
I can follow the last statement. :-) The others I kinda get the idea but don't understand details.
14:44
<vagrantc>
still doesn't make sense why the $proprietary_driver code wouldn't ask the X.org server which driver it's actually using... instead of assuming it based on weather a certain set of files are installed...
14:45
<alkisg>
I think the problem is that e.g. nvidia needs to ship its own, closed source opengl libs, and puts them in the same place where the opensource libs are, overwriting them
14:45
It should use a separate place for its proprietary libs, I think that's what they're trying to do, maybe with dpkg-divert, not sure...
14:46
And update-alternatives will point to the right lib, determined by some init script...
14:46
<vagrantc>
"we can do whatever we want to your system"isms.
14:47
<alkisg>
Right, it sucks :(
14:51
<k-train>
Thanks for the great input guys. I'm off to play with my kids. I'll chat with you guys later.
14:51
<alkisg>
Bye
14:52k-train has left #ltsp
14:59Faithful1 has quit IRC
15:07
<vagrantc>
hrm.
15:08
stgraber, alkisg: looks like my add_mirrors changes are broken.
15:08
<alkisg>
Whoops. How so?
15:08
<vagrantc>
or did they work for y'all, and i botched my packaging?
15:08* alkisg hasn't tried them
15:12
<alkisg>
We should create a test case, i.e. all the possible different calls to add_mirrors :)
15:12
<vagrantc>
stupid typo.
15:13
<alkisg>
btw, " if [ -z "$mirror" ] || [ "$mirror" = "none" ]; then" ==> I don't think [ -z "$mirror" ] is needed...
15:14
<vagrantc>
alkisg: it's possible.
15:14
alkisg: i think i half-way converted to a different approach at some point and didn't finish it
15:14
<alkisg>
Ehm sorry no it's needed if a line is empty
15:16
<vagrantc>
stgraber: so there's definitely a bug in ltsp-build-client that will break...
15:17
<alkisg>
file:///*) dir=$(echo "$mirror" | sed -e 's,^file://,,g') ==> can be written simplier as ==> file:///*) dir=${mirror#file://}
15:17
<vagrantc>
pushing fix now
15:17
<stgraber>
vagrantc: ok, I'll re-snapshot ltsp-trunk then ;)
15:17
<vagrantc>
alkisg: more compact. don't know if i'd call it simpler :)
15:17
stgraber: just pushed the fix
15:18
it's amazing what happens when you actually fully test code.
15:21
<stgraber>
I guess 5.1.99 will probably be our most tested release ;)
15:21
looking at the number of fix and optimization that went in
15:22
<alkisg>
And 5.2 will be rock stable :)
15:25
<stgraber>
then we can start breaking everything again ;)
15:30
<vagrantc>
heh
15:33vagrantc has quit IRC
15:34rjune has joined #ltsp
15:45bobby_C has quit IRC
15:45
<stgraber>
looks like the PPA builders are a bit overloaded, will take a while before we have ldm and ltsp built (unless you want them for amd64 as these are already built)
15:45
<alkisg>
stgraber: would it be possible to reduce tftpd-hpa to recommends? It'll still be installed, but if someone wants to use dnsmasq, he'll be able to remove it...
15:46
(e.g. I'll be able to make my sch-scripts package depend on ltsp-server and dnsmasq and confict with tftpd-hpa)
15:48
<stgraber>
ok, that should happen with the next build (so either another rebuild or with 5.1.99)
15:49
<alkisg>
Thank you
15:49
<stgraber>
btw, any idea why we depend on openssh-client | ssh on the server ?
15:49
I don't think we ever use the ssh client in ltsp-server ...
15:49
<alkisg>
ssh-keygen?
15:50
openssh-client: /usr/bin/ssh-keygen
15:50
<stgraber>
don't we simply copy the keys over from the server if they exist ?
15:50
<alkisg>
server/plugins/ltsp-build-client/ALTLinux/010-ssh-keys: ssh-keygen -f "$ROOT"/etc/openssh/ssh_host_rsa_key -t rsa -C '' -N '' >&2
15:50
Hmmm...
15:51
<stgraber>
well, that's ALTLinux ;)
15:52
<alkisg>
Right, I don't see anything else that relates to ssh client in the sources...
15:53
BTW, openssh-server depends on the client, so we could safely remove it in any case :)
15:53kaos01 has joined #ltsp
15:56Faithful has joined #ltsp
15:58alkisg has quit IRC
16:31Appiah has joined #ltsp
16:31vagrantc has joined #ltsp
16:51johnny has left #ltsp
17:02
<rjune>
ogra, you around?
17:37pmatulis has quit IRC
17:48
<kaos01>
im assuming root in the chroot doesnt correspond to /root on the client ? As I dont see roots ssh keys
17:50johnny has joined #ltsp
17:57
<vagrantc>
kaos01: correct.
17:57
kaos01: /opt/ltsp/i386 on the server corresponse to / on the thin client.
17:57
typically
17:57
sort of
17:57
<kaos01>
i made /opt/ltsp/i386/root/.ssh but cant see it in /root/ on client
17:58
<vagrantc>
!release
17:58
<ltspbot`>
vagrantc: "release" :: please mention the linux distro and release you're using :)
17:58
<vagrantc>
kaos01: ^^
17:58
<kaos01>
fedora 12
17:58
<vagrantc>
is it using NFS or NBD?
17:58
<kaos01>
NBD
18:00
<vagrantc>
kaos01: and you rebuilt the NBD image?
18:00
<kaos01>
i believe so, but i should prob test it again before speeking :)
18:00* vagrantc isn't too familar with fedora
18:01
<kaos01>
alos it seems my usb is mounted as sdb and not sdb1
18:01
its not mounting the partition
18:13johnny has quit IRC
18:32
<kaos01>
yeap i cant see /root/.ssh
18:33
using NFS or NBD
19:01pmatulis has joined #ltsp
19:13litlebuda has quit IRC
19:16johnny has joined #ltsp
19:23
<vagrantc>
hey, i stumbled upon something to minimize the risk to certain processes when the out of memory killer goes on a rampage...
19:23
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562884#34
19:25
<stgraber>
yep, I use that to protect dbus and some ltsp-cluster daemons on my application servers
19:25
<vagrantc>
maybe worth doing that by default for some things in general?
19:26
instead of/in addition to X_RAMPERC
19:28
<stgraber>
we could protect X though it might already do some magic to avoid getting oomkilled
19:28
<vagrantc>
it sure didn't used to do any magic
19:28
and was a big target, taking up so much memory
19:30
<stgraber>
hmm, it doesn't seem to be protected against oomkills, though IIRC the oom-killer avoids processes with many children which is often the case for X and instead kills processes using a large amount of ram and without children (dbus for example)
19:30
I remember reading the exact logic it uses to determine what to kill
19:31
though protecting X is probably a very good idea in all cases and can easily be done from the xinittrc
19:34
<vagrantc>
stgraber: X doesn't typically have many subprocesses in ltsp's case
19:35
er, children
20:09_gentgeen_ has joined #ltsp
20:22johnny has left #ltsp
20:25vagrantc has quit IRC
20:42sene has quit IRC
20:46pmatulis has quit IRC
21:01etyack has joined #ltsp
21:04alexqwesa has quit IRC
21:06etyack has joined #ltsp
21:08etyack has joined #ltsp
21:11alexqwesa has joined #ltsp
21:19
<sbalneav>
Evening all
21:25johnny has joined #ltsp
21:41rjune has quit IRC
22:00etyack has quit IRC
22:09
<stgraber>
for these interested in the new ltsp-cluster web interface: https://ltsp-control01.stgraber.org/loadbalancer/overview
22:09
feel free to play with the UI, it's a test database
22:24
<sbalneav>
Ooooh
22:24
all web-2.0-ey drag-and-dropy
22:24
Slick
22:26
<stgraber>
yep ;)
22:26
quite a change from our old one ;)
22:27
(which was more like web 0.1 ;))
23:24
<johnny>
stgraber, now.. if only i could control my whole system with that :)
23:24
non ltsp..
23:28alkisg has joined #ltsp
23:59mikkel has joined #ltsp