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


Channel log from 25 February 2008   (all times are UTC)

00:09plamengr has joined #ltsp
00:14indradg_ has quit IRC
00:31cyberorg has joined #ltsp
00:42ian_ has quit IRC
00:47ian_ has joined #ltsp
00:47cyberorg_ has joined #ltsp
00:48cyberorg has quit IRC
00:48cyberorg_ is now known as cyberorg
01:05
<vagrantc>
klausade: updated: *
01:05
klausade: updated: deb http://pkg-ltsp.alioth.debian.org/debian etch-ltsp-backports main
01:05
anyone else using debian etch with ltsp backports is encouraged to try them out.
01:05ian__ has joined #ltsp
01:05
<vagrantc>
main thing is some new features in ldm
01:06
autologin, guest login ...
01:08
sound support isn't as good as i'd like, but local devices are working good.
01:09ian_ has quit IRC
01:15ian__ has quit IRC
01:56
<sep>
vagrantc, i'm considering using ltsp backports. so i will definitiftly try them out
01:56plamengr has quit IRC
01:58
<vagrantc>
sep: cool.
01:59
sep: i was also meaning to ping you regarding http://bugs.debian.org/445312
01:59
<sep>
yes ?
01:59
<vagrantc>
sep: mainly, can you reproduce it with the current version in sid ?
02:00
i don't really have a good debian-installer test environment for ltsp at the moment.
02:01
<sep>
vagrantc, i could try making a cd, but it would be easier waiting for it to hit lenny since i then just could use the debian-edu lenny dvd
02:01
<vagrantc>
sep: it may be a long wait, the way mips buildd's are going ...
02:03
<sep>
vagrantc, could ofcourse uploading it to debian-edu lenny local,
02:04
but ill try making a lenny cd with sid ltsp
02:11Q-FUNK has joined #ltsp
02:24
<vagrantc>
build in a lenny chroot, or is sid chroot ok?
02:33indradg has joined #ltsp
02:36Nuba1 has left #ltsp
02:48
<daduke>
vagrantc: howdy!
03:11soneyka has quit IRC
03:14soneyka has joined #ltsp
03:28mikkel has joined #ltsp
03:47Q-FUNK has quit IRC
03:48Q-FUNK has joined #ltsp
04:29Q-FUNK has quit IRC
04:58uioreoiwr has joined #ltsp
04:59
<uioreoiwr>
Hi, I am getting "client isn't authorized to connect to server" in ltsp
04:59
Have tried updating the keys and image as per the forums
05:00ace_suares has joined #ltsp
05:03* ogra_cmpc wonders what the forum say ... i doubt ant dev reads them to verify its correct ... can you describe what you did yet ?
05:05
<uioreoiwr>
I ran ltsp-update-sshkeys and ltsp-update-image on the server.
05:05
<ogra_cmpc>
and your ssh server is running properly ?
05:06
<uioreoiwr>
Yes, pk logon and password logon both functional.
05:06
<ogra_cmpc>
hmm, which release is that ?
05:06
<uioreoiwr>
tftpboot works, everything is ok up to gdm. This is where I get the message.
05:06
<ogra_cmpc>
s/gdm/ldm
05:06
(we dont use gdm :) )
05:07
<uioreoiwr>
Running multiple archs: ltsp-update-image -a i386
05:07
<ogra_cmpc>
right
05:07
<uioreoiwr>
This may well do the trick. I think I found my problem, i.e. Architecture of this image. Default is arch of the host.
05:07
Server is AMD64.
05:09
<vagrantc>
6
05:09
<ogra_cmpc>
can you check that each /opt/ltsp/$ARCH/etc/ssh/ssh_known_hosts contains a key for the server
05:09
sounds like a multiarch bug with ltsp-update-sshkeys or so
05:12lexa_ has joined #ltsp
05:12soneyka has quit IRC
05:13lexa_ has quit IRC
05:14soneyka has joined #ltsp
05:17ace_suares has quit IRC
05:37
<uioreoiwr>
ogra, all happily working. The image MUST be generated for every arch.
05:38
I think filing a but report is unnecessary
05:38
ogra_cmpc, thanks for helping. People like you give community software a good name.
05:38
<ogra>
no, file it, i'd like to fix it ... (probably not for hardy, but a reminder bug helps to not forget about it)
05:38uioreoiwr has quit IRC
05:39
<ogra>
meh
05:39
<laga>
heh :)
05:43Guaraldo has joined #ltsp
06:01K_O-Gnom has joined #ltsp
06:02Q-FUNK has joined #ltsp
06:03mhterres has joined #ltsp
06:10Guaraldo has left #ltsp
06:30meduxa has joined #ltsp
06:53jammcq has quit IRC
07:05cdealer has joined #ltsp
07:05
<cdealer>
good morning
07:05elisboa has joined #ltsp
07:07
<cdealer>
I have set the TMP, TMPDIR, TEMP, TEMPDIR env in the ltsp server to point to /tmp/${USER}_ltsp but seens that these folder arent being used... how can I set to ltsp to use these folders as the clients temp dir ??
07:09
im using /etc/bash.bashrc no /opt/ltsp/i386/etc/bash.bashrc
07:09
*not
07:13
<vagrantc>
i think /etc/X11/Xsession will unset those variables
07:13
which is used when you log in
07:14
many programs refuse to respect those variables, as there are some negative security implications
07:15
<ogra>
additionally bashrc isnt read by X at all
07:15
use /etc/environment instead
07:15
<vagrantc>
though arguably, it prevents better security by having each user using a different temporary directory
07:15
<ogra>
vagrantc, up early ?
07:15
<vagrantc>
be sure to "export" the variables as well ...
07:16
ogra: late becomes early
07:16
<ogra>
heh
07:16
<vagrantc>
i should have turned in at least 4 hours ago
07:18
<cdealer>
we use an web application that works with java and user session, on ltsp the users constantly lost connection this does not happen on users using ubuntu local ...
07:18
<vagrantc>
ogra: i think i have network booting code for mips and arm ... and a tiny sub-set of mipsel
07:18
<cdealer>
so I thought in the ideia of testing trying to separate the users temp dir ... to see if I get rid of these lost connections problem
07:19
<ogra>
vagrantc, whee ... how do you test that ?
07:19
<vagrantc>
ogra: test?
07:19
<ogra>
yes
07:19
i mean, how do you know it works
07:19
<vagrantc>
ogra: i just adapted it from debian-installer's netboot image generation code
07:19
<ogra>
ah
07:19
cool
07:20
<vagrantc>
and i'm actually having luck with qemu-system-mips and qemu-system-mipsel ... :)
07:20* ogra still hasnt solved the grub thing properly
07:21
<ogra>
the code we have in ubuntu-vm-builder is so scary i dont think i have the balls to touch that ...
07:21
dd'ing a mbr together ... bytewise from grubs stage 1 and stage 2 files
07:22
<cdealer>
you know if a shared environment like ltsp provides can bring problems with session and remote application usage experience, specially with java? We are up to pay for support if is need to get rid of this problem on our ltsp server...
07:23
<ogra>
well, as long as you use the debian way to use the java stuff and dont set crap like JAVA_HOME etc it should just work
07:23
<cdealer>
this "web application" is the main app used here by the users... if this start geting problems is like we trowed $10k on the trash
07:23
<ogra>
i wonder if its display related
07:24* vagrantc is building a mipsel ltsp chroot from debian-installer ...
07:24
<cdealer>
ogra, display ?
07:24
<ogra>
cdealer, wel, you said its only happening on ltsp ...
07:24
<cdealer>
ogra, yeap... on the local installations no problem
07:24
never
07:24
<ogra>
the only real difference here is the display the screen is shown on ..
07:25
<cdealer>
but with ltsp it constantly drops the connection
07:25
the client is still up with server but this application send a "lost connection with server" and then the user have to login again
07:25
<ogra>
sounds really like an app problem to me ...
07:26
did you talk to the devs there ?
07:26
i cant imagine how ltsp should have any influence on the connection
07:27
<cdealer>
ogra, its an oracle application, trhough ias server ...its automatically generated and they demand us to use java version 1.4.0.6
07:28
<ogra>
do you have any debugging output, logs etc from the app ?
07:28exodos has joined #ltsp
07:28
<ogra>
1.4 ?
07:28
thats not even supported upstream anymore
07:28
(we just dropped it from hardy)
07:28
(because of that fact)
07:29
but still, i dont see a reason why ltsp should be able to influence the connection
07:29
<cdealer>
ogra, its because is the java version that oracle have build support for this ias application
07:29
<ogra>
doe the app have a check that you cant connect multiple times from the same machine or so ?
07:29
<cdealer>
I realy dont like the ideia of using an old java version
07:29
but we having any choice
07:30
ogra, I start thinking that this could be a possibility
07:30
<ogra>
dont forget all your user sessions come from the same ip
07:30
<cdealer>
yeah... this come to my head friday
07:31
we asked they to look if there are any maximum connection on the server or something like that... no answer yeat
07:31
ogra, do you think its possibly to the ltsp is overwriting some sessions ? Or this isnt a possible think to be happen ?
07:32
<ogra>
??
07:32
<cdealer>
like
07:32
<ogra>
can you rephrase that
07:32
<cdealer>
yea
07:34
like... imagine if a temp file with the same name is being write for the user when he logs in the application, then other user logs in too and so his session is overwritten setting a new "timeout" and then the other user, the first one... stays of a zombie session that was overwritten by the user that logged after him ... this was the main reason why I though in setting separeted temp dirs for the users
07:34
<ogra>
ah
07:35
<vagrantc>
a very poorly written app...
07:35
<ogra>
well, tat might be the issue then, how about prefixing the app call with the variable to test that ?
07:35
<cdealer>
I start thinking why only the ltsp client of the app are having this strange connection loss problem
07:36
<ogra>
if you have such temp files to steer the session, it probably puts the display in there .. indeed that changes with every new login
07:37
<cdealer>
Hmmm
07:37
<ogra>
put a little wrapper script around it
07:37
that makes sure the var is set and the dir exists
07:38
<cdealer>
sorry, didnt gotcha...
07:38
<ogra>
wrap your app in a shellscript that sets TEMPDIR and makes sure the dir is existing before the app starts up
07:38
and test isf that helps you
07:39
(its horrible to hear tat someone gto 10k for such badly written things)
07:39
*got
07:40
<cdealer>
well ... let see if I understand right... you said to me to set in my ltsp a shellscript to set the tempdir of the user (the original idea) or to set in the APP code ?
07:40
ogra, 10K is our ltsp server.. the application it self is a investiment of almost 1 million ...
07:41
<ogra>
heh
07:41
even worse
07:41
<cdealer>
yea
07:41
the problem is that one are being the first state to change our entire users environment to ltsp ...
07:42
<ogra>
well, they might not have had such scenarios in mind when creating the app
07:42
<cdealer>
so every problem we get with that we are most part of time alone.. trying to prove that the problem arent of our system
07:42
<ogra>
but its very likely an app issue not a ltsp one
07:43
<cdealer>
ogra, so you think that some in the app like to use a $user/session could help ?
07:45gonzaloaf has joined #ltsp
07:45meduxa has quit IRC
08:02
<ogra>
cdealer, no idea, just a guess for you to test :)
08:04
<cdealer>
ogra, yeah... we have send this issue to the developers... they are going to take a look and make some tests there...
08:05cliebow_ has joined #ltsp
08:22
<cdealer>
ogra, /etc/environment doesnt accept vars... I can set /tmp/${USER}_ltsp ... O.o
08:23
<ogra>
did you try with a wrapper script as i said above ?
08:23
vagrantc already told you it gets unset in Xsession :)
08:24
<cdealer>
ogra, but you told after to use /etc/environment ... I just dont get it where to set the wrapper script...
08:25
<ogra>
mv /usr/bin/app /usr/bin/app.orig
08:25
vi /usr/bin/app
08:25
make it a shellscript, export the vars etc .. and call /usr/bin/app.orig at the bottom
08:25
<cdealer>
ogra, ah! the app is a web application ... using a java applet
08:25
<ogra>
well, even easier
08:26
edit /usr/bin/firefox :)
08:26
<cdealer>
Hmmm
08:26
<ogra>
its only a script
08:26
<cdealer>
so .. you realy are smart lol
08:26
=X
08:42jammcq has joined #ltsp
08:44
<cliebow_>
jammcq!!!!
08:44
<Lumiere>
hi jammcq *runs*
08:47plamengr has joined #ltsp
08:52ccherret1 has joined #ltsp
08:53ccherrett has quit IRC
08:55
<cliebow_>
see jammcq run?
08:58
<jammcq>
cliebow_: howdie
08:58
hey Lumiere
08:59
<cliebow_>
jammcq:always good to see you..
08:59
<jammcq>
cliebow_: hey, carrying a little tail today, eh?
09:00
<cliebow_>
ohhh..i guess so..not sure why..
09:02* ogra doesnt see that as "tail" specifically :P
09:02
<ogra>
(its rather at the fron than on the back)
09:02
*front
09:02
hi jammcq
09:03
<cliebow_>
reprihensible....err...prehensile tail
09:09
<jammcq>
ogra: I guess it depends on which direction his name is going
09:09
<ogra>
nah
09:09
the words appear at the right side ... thats where his mouth must face then :)
09:09
<jammcq>
so it's a tongue
09:09
<ogra>
so _cliebow would be a tail ... ;)
09:09mccann has joined #ltsp
09:10
<cliebow_>
i am left handed though
09:10
<ogra>
indeed ... i didnt mean to suggest anything nasty :)
09:10
<jammcq>
that screws up everything
09:10toscalix has joined #ltsp
09:20cliebow_ is now known as cliebow____
09:20
<cliebow____>
ther
09:20
e
09:21
<ogra_cmpc>
lol
09:23cliebow____ is now known as cliebow__
09:27
<ogra_cmpc>
jammcq, any news from scottie ?
09:27
!seen sbalneav
09:27
<ltspbot>
ogra_cmpc: sbalneav was last seen in #ltsp 2 weeks, 5 days, 0 hours, 28 minutes, and 21 seconds ago: <sbalneav> What are we looking at?
09:27bobby_C has joined #ltsp
09:27
<jammcq>
umm, nope
09:28
<ogra_cmpc>
not that he's specifically needed atm, the community currebtly greatly provides us with patches for ldm bugs
09:29
so all he was urgently needed for is taken care of for the moment
09:29
but i wouldnt like to start implementing localapps without him around for hardy+1 ... its his brainchild
09:29
<jammcq>
indeed
09:29
I hope he frees up soon
09:30
<ogra_cmpc>
still that busy ?
09:30
(did you talk to him some more ?)
09:30
<jammcq>
last time was about 2 weeks ago
09:30
his last words were something like: You gonna be around tonight? I'll call you
09:31
<ogra_cmpc>
ah, thats the time he was around and telling me about his mail crashes
09:31
seems he had a hard time switching people to thunderbird or so
09:31
<jammcq>
but it sounded like he got that all worked out
09:32
<ogra_cmpc>
but given the amount of time he invested here the last two years i would understand if his boss wants him to do more inhouse now :)
09:33
<jammcq>
well, over the 9 years I've known him, I've seen him dissappear for months at a time. then he comes back ready to get busy again
09:33
<ogra_cmpc>
yeah
09:34
<jammcq>
I see you are going to Prague for UDS
09:34
<ogra_cmpc>
indeed
09:34
<jammcq>
how far is that from you?
09:34
<ogra_cmpc>
no ltsp sponsoring planned though :(
09:34
<jammcq>
yeah, I figured
09:34
<ogra_cmpc>
not sure but must be less than 800km
09:35
prague is the non german european city i was most in my life yet
09:35
i drove there two times by car already, so its not that far
09:35
<jammcq>
you've been there?
09:35
wow
09:35
I've heard it's a beautiful city
09:35
<ogra_cmpc>
five times
09:36
sadly it turned into the bordello of europe since the wall fell
09:36
i was there two times before the iron courtain went down
09:37
and its sad to see what capitalism did to it
09:37
<jammcq>
when I was a kid, I used to actually envision a real curtain made of Iron
09:38
<ogra_cmpc>
the inner city turned into a fair after that ...
09:38
but its still the home of art deco
09:38
one of the most beautiful cities i know
09:40
if i would ever marry i'd have my honeymoon there ;)
09:43Nubae has joined #ltsp
09:43
<Nubae>
hi, I know I've seen this error before, but I can't remember what I did to fix it nor is there anything on the web about it:
09:44
mount: Mounting /rofs on /root/rofs failed: Invalid argument
09:44
cp: unable to open '/root/etc/': Is a directory
09:44
<ogra_cmpc>
your nbd server is down or something like that
09:44
the actual error is above
09:44
thats only a result
09:45
<Nubae>
nbd cant be down, because I'm on a thin client
09:45
I meant started up from one
09:45
but then another won't start
09:45
its a different chroot though
09:45
<ogra_cmpc>
well, its definately not getting nbd from the server
09:46
<Nubae>
i checked inetd.conf and that seems correct
09:46
<ogra_cmpc>
matches the entries in the pxe config ?
09:46
<Nubae>
yep
09:46
<ogra_cmpc>
do you see it connecting in the server logs ?
09:46
<Nubae>
yep
09:46
<ogra_cmpc>
nbd server usually tells you
09:47
did you fiddle with the initramfs in any kind for the chroot that doesnt work ?
09:47
<Nubae>
nope
09:48
<ogra_cmpc>
weird
09:48
its either not having nbd or it cant mount the squashfs
09:48
thats gutsy i suppose ?
09:49
<Nubae>
Feb 25 16:41:31 mayserve nbdrootd[12524]: connect from 192.168.0.3 (192.168.0.3)
09:49
Feb 25 16:41:31 mayserve nbd_server[12525]: connect from 192.168.0.3, assigned file is /opt/ltsp/images/fati386.img
09:49
heron
09:49
<ogra_cmpc>
ah
09:49
<Nubae>
ah :-) ?
09:50
<ogra_cmpc>
well, there might be issues with lzma, i havent checked the last ltsp build yet
09:50
its hardy :)
09:50
<Nubae>
but my main image works
09:50
<ogra_cmpc>
suppoosed to be in flux and brak fromj time to time
09:50
when did you build your main image and did you upgrade ltsp-server inbetween ?
09:51
<Nubae>
maybe its because of the way I did it... to cut time, I copied and pasted /opt/ltsp/i386 to /opt/ltsp/fati386
09:51
<ogra_cmpc>
note that i uploaded a new version pretty recently (feb 13th)
09:51
<Nubae>
I installed a regular ubuntu and then installed ltsp-server-standalong ssh-server
09:51
<ogra_cmpc>
that shouldnt matter as long as you never touched /opt/ltsp/i386
09:52
<Nubae>
i didn't
09:52
<ogra_cmpc>
if you tewaked that before copying it it might cause probs indeed
09:52
hmm
09:52
<Nubae>
the regular i386 loads up perfetly
09:53
i guess creating another chroot and testing would be the next step, but why can't it see the image, I dont get it
09:53
<ogra_cmpc>
mv the working image out of the way and run ltsp-update-image again ...
09:53
test if it works then
09:53
<Nubae>
that I did too
09:53
same thing happened
09:53
<ogra_cmpc>
i dropped the -nolzma option in the recent upload
09:53
same thing means ?
09:53
it worked ?
09:53
<Nubae>
no
09:53
doesnt
09:54
<ogra_cmpc>
yeah, then its liukely the lzma change
09:54
<Nubae>
moving the image, then redoing ltsp-update-image has same effect
09:54
I'm not sure what that is, is there a way I can fix that?
09:54
<ogra_cmpc>
dpkg -l squashfs-tools
09:54
what does that give you
09:55
<Nubae>
squashfs-tools 1:3.3-1ubuntu2
09:55
<ogra_cmpc>
hmm
09:55
that has the fix...
09:55
(was added in 1:3.3-1ubuntu1)
09:56
<Nubae>
could it be the size of my image?
09:56
is there a limit?
09:56
<ogra_cmpc>
nope
09:56
well, general linux partition size would be the limit
09:56
but that should be in the terabyte area
09:56
<Nubae>
heh, my image is not that big ;-)
09:57
<ogra_cmpc>
it has apparently nothing to do with your chroot
09:57
since it breqaks as well with the normal chroot
09:57rjune has quit IRC
09:57
<Nubae>
well, no, my /opt/ltsp/i386 loads fine
09:57
its just the other chroot
09:58
<ogra_cmpc>
you just said it doesnt if you rebuild it
09:58
<ogra_cmpc> mv the working image out of the way and run ltsp-update-image again ...
09:58
<ogra_cmpc> test if it works then
09:58
<Nubae> that I did too
09:58
<Nubae> same thing happened
09:58
<Nubae>
the /opt/ltsp/fati386
09:58
that is
09:58
<ogra_cmpc>
so please do as i said
09:59
and tell me if it breaks with that as well
09:59
<Nubae>
I'm doing ltsp-update-image like this ltsp-update-image -a fati386 -b /opt/ltsp
09:59
ok, I'll move the regular one and rebuild
10:00
<ogra_cmpc>
right
10:00
and see if that breaks too, then i know where to look
10:00
also check in busybox if the error occurs what /proc/mounts contains
10:00
and if nbd-client is running
10:01
<Nubae>
so... backup/move /var/lib/tftpboot/ltsp/i386, right?
10:01
<ogra_cmpc>
err
10:01
nope
10:02
mv /opt/ltsp/images/i386.img /opt/ltsp/images/i386.img.bak
10:02
sudo ltsp-update-image
10:02
reboot a client that uses that image
10:03rjune has joined #ltsp
10:04
<Nubae>
hmmm, well I never did mv /opt/ltsp/images/fati386.img, I thought the image was linked from /var/lib/tftpboot/ltsp/
10:05
<ogra_cmpc>
thats the pxe stuff, not the filesystem image
10:05
kernel and initramfs
10:05
<Nubae>
ah ok...
10:05
<ogra_cmpc>
you usually dont need to mv it :) it just gets overwritten
10:05
<Nubae>
so they are bootstrap images
10:05
<ogra_cmpc>
i just want to prevent you from losin the working one
10:05
<Nubae>
I'm still learning all this
10:05
well, that worked fine
10:06
moving then updating the image
10:06
<ogra_cmpc>
if you boot a client: it broadcasts a pxe request, gets answer, pulls kernel, pulls initramfs and unpacks and executes both ....
10:06
the initramfs is a mini linux ...
10:07
<Nubae>
yeah I get it now
10:07
<ogra_cmpc>
inside the initramfs we have scripts that mount the image from /opt/ltsp/images as rootfs
10:07
<Nubae>
would u be able to (maybe this is a dumb question) load a windows xp image via pxe?
10:08
<ogra_cmpc>
i dont think windows supports that
10:08
technically it would be possible (from a pxe POV)
10:08
<Nubae>
and loading a vmware/virtualbox image via pxe?
10:08
<ogra_cmpc>
you might need some special imaging software for win
10:53ccherret1 is now known as ccherrett
10:59mccann has quit IRC
11:06mccann has joined #ltsp
11:09mccann has quit IRC
11:12mikkel has quit IRC
11:14staffencasa has joined #ltsp
11:27exodos has quit IRC
11:51otavio has quit IRC
11:59Nubae has quit IRC
12:03spectra has joined #ltsp
12:10nicoAMG has joined #ltsp
12:11Q-FUNK has quit IRC
12:15mccann has joined #ltsp
12:24mccann has quit IRC
12:35mccann has joined #ltsp
12:36otavio has joined #ltsp
12:37plamengr has quit IRC
13:01cesar_ has joined #ltsp
13:01
<cesar_>
hi people
13:01
I try use local devices
13:01
in a client terminal
13:01
buy
13:01
pardom
13:01
but
13:02
in terminal appeared the icon for the floppy disk
13:02
and when I try access
13:02
at the floppy
13:03
it is 0 bytes
13:03
in the TS I try start
13:03
./lbus-start.sh
13:04
and get a error
13:04
Use of uninitialized value in substitution (s///) at /usr/sbin/lbussd line 46.
13:04
Use of uninitialized value in concatenation (.) or string at /usr/sbin/lbussd line 62.
13:05
Couldn't establish a connection to :9202: IO::Socket::INET: Bad hostname ':9202'
13:05
<johnny>
cesar_, you're going to find much less help with 4.2 than 5 here
13:05
<cesar_>
I found in google for something that help me
13:05
yes
13:06
I am using LTSP 4.2 update 3
13:06
on Debian
13:06
Linux ltsp 2.6.18-5-amd64
13:06
<ogra_cmpc>
especially on debian
13:07
ltsp 4.2 isnt been developed for more than two years, current devs wont know much about the old 4.2
13:07
<cesar_>
ups..
13:07
<ogra_cmpc>
cesar_, your best hope is that sbalnev shows up again or jammcq finds some time to walk you through it
13:08
<cesar_>
:-/
13:08
<ogra_cmpc>
but in the end i'd suggest to use ltsp5 .... *especially* on ubuntu or debian
13:09
(wher ltsp5 is the default since two years)
13:09
<vagrantc>
well, a year and a half
13:09
<cesar_>
yes, I install ltsp from package
13:09
debian package
13:09
<vagrantc>
actually, not even a year
13:09
heh
13:09
<ogra_cmpc>
vagrantc, 5.10 was my first release shipping ltsp5
13:10
<cesar_>
but in repositories not found ltsp5
13:10
<ogra_cmpc>
cesar_,
13:10
!debian
13:10
<ltspbot>
ogra_cmpc: "debian" is is a GNU/Linux based operating system that makes an excellent LTSP server. You can find it at http://www.debian.org. for information about LTSP on debian see http://wiki.debian.org/LTSP
13:10
<cesar_>
ok
13:10
thanks
13:10
<ogra_cmpc>
vagrantc, ocy 2005, thats nearly three years :)
13:10
err
13:10
oct
13:10
<vagrantc>
ogra_cmpc: first debian to have an ltsp5 was last april ... i think ... although debian-edu actually had one before 5.10
13:11
<ogra_cmpc>
sarge ?
13:11
i think that was released at the same time
13:11
<vagrantc>
debian-edu's sarge-based release was slightly before 5.10, if i remember correctly.
13:11
<ogra_cmpc>
deec 05 or so
13:11
<cesar_>
ok... a try install ltsp5
13:11
but .. again start all the process
13:12
:-(
13:12
<vagrantc>
cesar_: i'd also recommend the backported packages if you want local devices.
13:12* vagrantc forgot to sleep
13:12
<johnny>
vagrantc, :(
13:13* vagrantc makes a late breakfast (and extremely late dinner)
13:13
<cesar_>
uff..
13:14
bye bye
13:29
one question
13:29
I am downloading the package for ltsp5 on Debian
13:30
I'm currently have installed ltsp4.2 on the TS
13:31
and it's working .. only not work local devices
13:32
<vagrantc>
cesar_: you'll need to follow the instructions for backports at the bottom of http://wiki.debian.org/LTSP/Howto
13:32
<cesar_>
if I install ltsp5 I have make a lot of changes in
13:32
dhcp
13:32
tftp
13:32
<vagrantc>
you'll also have to move /opt/ltsp/i386 aside ... and configure dhcpd and maybe tftp
13:33
<cesar_>
ok
13:33
well
13:33
not is necesary a lot of changes
13:33
<vagrantc>
and if there's any server-side ltspfs stuff, you'll need to remove it
13:33Guaraldo has joined #ltsp
13:34
<cesar_>
I don't understand very well
13:34
<Guaraldo>
Hi, all...
13:34
<vagrantc>
cesar_: you'll need to remove all the stuff you added for ltsp 4.x
13:34
<cesar_>
ah..
13:34
ok
13:34
<Guaraldo>
I'm heaving some trobles with LTSPFS... Can anyone help me?
13:34
<vagrantc>
Guaraldo: linux distro and release?
13:35
<Guaraldo>
vagrantc: Ubuntu Gutsy with LTSP4.2
13:35
<vagrantc>
Guaraldo: and just go ahead and start asking your question
13:35
<cesar_>
I have installed on TS this packages
13:35
ii ltsp-utils 0.25-1 Linux Terminal Server Project (LTSP) adminis
13:35
ii ltspfs 0.5.0~bzr20080109-3 Fuse based remote filesystem for LTSP thin c
13:35
<vagrantc>
Guaraldo: you might have a hard time finding help with that
13:36
<Guaraldo>
When any client plugs a pen-drive, I get this error message: "Couldn't read LTSPFS_TOKEN atom."
13:36
<vagrantc>
cesar_: if you install the backports, it should remove ltsp-utils
13:36
<cesar_>
then I need uninstall this two packages
13:36
ok
13:36
thanks
13:36
<vagrantc>
Guaraldo: the server-side ltspfs is incompatible with ltspfs in ltsp 4.x
13:36
<cesar_>
ltspfs isn't necesary uninstall?
13:36
<vagrantc>
cesar_: you're running lenny or sid?
13:37
<cesar_>
Linux ltsp 2.6.18-5-amd64 #1 SMP Sat Dec 22 20:43:59 UTC 2007 x86_64 GNU/Linux
13:37
<Guaraldo>
Oh!... What does you sugest, vagrantc?
13:37
ops... What do you sugest, vagrantc?
13:37
<vagrantc>
Guaraldo: well, ubuntu has been ltsp5 since the breezy release ... 5.10
13:38
Guaraldo: that's over two years ago...
13:38
<cesar_>
vagrantc: I think it's lenny version
13:38
but.. I don't sure
13:39
<vagrantc>
cesar_: ok, you'll want to install ltsp-server-standalone from sid, and build a sid ltsp environment.
13:39
cesar_: it's the only version in debian right now.
13:39
<Guaraldo>
vagrantc: Yes... But on a network with over 1000 clients I cant change to LTSP5 yet! It's to slow to get up...
13:40
<vagrantc>
Guaraldo: well, if you really want to switch to ltsp 4.x on gutsy, you're going to have to remove all the ltsp5 related packages and install ltsp 4.2 ... and hope it works.
13:44
<Guaraldo>
Thanks vagrantc... I'll try it...
13:45
<vagrantc>
Guaraldo: what part of ltsp5 is too slow?
13:47
Guaraldo: is it just the boot process, or the actual use? LDM_DIRECTX can improve performance at the cost of security (about the same resources as ltsp 4.x with startx/xdmcp)
13:48
<Guaraldo>
booting ts
13:49
vagrantc: When we are talning about 1000 terminals booting at the same time, LTSP4.2 makes a big diferance...
13:49
talnin=talking
13:51
<vagrantc>
Guaraldo: how does your electrical system even handle 1000 machines booting at the very same time
13:51
:)
13:52
<Guaraldo>
vagrantc: That's a big network, over 10 buildings, conected by optical fiber...
13:54
The servers handle all them together, but testing LTSP5 in a little network (over 5 clients), I've got over 2 minutes to boot a client...
13:55
So, I can imagine what would be with 1000 clients booting together...
13:55radoeka has joined #ltsp
13:56radoeka has left #ltsp
13:59
<lns>
Guaraldo, sounds like there's something missing with your setup - LTSP5 has major boot speed improvements
14:00
<vagrantc>
lns: it's still slow as molasses compared to ltsp 4.x
14:00
<Guaraldo>
lns: But is still slower than ltsp4.2
14:00
<lns>
vagrantc, you mean boot?
14:00
<vagrantc>
lns: yes
14:01
<lns>
wow
14:01
i think it's pretty damn fast myself
14:01
<Guaraldo>
lns: Don't forget that I'm talking about 1000 clients...
14:01
<lns>
maybe 20sec to boot up total
14:01
Guaraldo, i know - how many servers?
14:01
i'm hoping you have some pretty crazy ethernet bonding/clustering going on
14:01
for 1k clients
14:01
<Guaraldo>
lns: 9 Linux and 5 Windows
14:02
<lns>
not bad, ~100 clients per linux server
14:02
<Guaraldo>
All them have 2 Xeon 64 DuoCore or QuadCore...
14:03
<lns>
Guaraldo, amd64 ubuntu or i386 (on the server)?
14:03
<Guaraldo>
AMD64 Gutsy
14:03
<lns>
how much ram?
14:03
<Guaraldo>
8 GB in each...
14:03
<lns>
sounds like my setup almost to a T
14:04
i have five 2x dualcore xeon 1.6GHz w/8GB ram (i386 server though, thanks to adobe)
14:04
and a single 2x quadcore xeon 3.0ghz
14:04
of course that's serving labs + classrooms of ~50-60 total at each site
14:05
Guaraldo, are the servers serving specific clients or are they clustered?
14:05
<Guaraldo>
AMD64 runs perfectly Adobe Reader i386...
14:05
<johnny>
flash..
14:05
not adobe reader..
14:05
<Guaraldo>
johnny: Yep... i386 firefox...
14:06
<lns>
yack..i was in that mess a while ago
14:06
took ogra's advice and re-build the servers with i386
14:06
<Guaraldo>
lns: I've solved this installing firefox i386...
14:06
<lns>
Guaraldo, did you solve the printing problems too w/i386 ff and amd64 cups libs?
14:07
unless that's been fixed in the code since i had the issue
14:07
<Guaraldo>
lns: I did not have this problems...
14:08
<lns>
heh, you're lucky then ;)
14:08
vagrantc, what's up with ltsp5 being slower than 4.2? is there a simple explanation or is it just that there's code to be optimized?
14:09
<vagrantc>
lns: it's mostly using binaries built for a desktop system
14:09
lns: it's using straight ubuntu/debian (soon to be fedora) binaries
14:09
<lns>
vagrantc, so the distro integration
14:09
yea
14:09
catch 22 there =p
14:09
<vagrantc>
it's also using a recent kernel
14:10
<lns>
i never really used 4.2 much but i did really like the console-based ltspadmin
14:10
<vagrantc>
but, it gets security updates and it's much easier to install client-side software
14:10
<lns>
exactly
14:11
i just got thin-client-manager working the other day - sooo nice
14:11
<vagrantc>
yeah, nobody's gotten around to writing a replacement for ltspadmin ... ogra_cmpc's worked on a few projects towards that, but i don't think any of them ever got ready really.
14:12
<lns>
ogra's got too many things he's doing, when i start getting enough income from my ltsp-based clients i want to hire at least a part-time ltsp coder
14:12
or find out whatever the best way would be to pay someone to help out
14:12
<johnny>
too bad you're not nearby.
14:12
<lns>
johnny, ?
14:13
<johnny>
to know somebody who works nearby with ltsp
14:13
<lns>
location is irrelevant when you have vnc over ssh ;) cept for the setup part of course
14:14
<johnny>
i mean working diretly with the hardware to see what is happenin
14:14
which is useful
14:14
to be in the deployed environment
14:14
<lns>
yeah
14:15
well there's always ups ;)
14:15
and youtube..i've done a troubleshooting video over yt before
14:15
and/or stickam, or ekiga/skype
14:18cdealer has quit IRC
14:19Guaraldo has left #ltsp
14:23indradg has quit IRC
14:30
<cliebow__>
cesar_:first thing Scottie would ask is..have you gone carefully thru the troubleshooting 12 step in wiki.ltsp.org..
14:32
<cesar_>
:-|
14:33
what?
14:34
<vagrantc>
for ltsp4.2 localdev ... there's ...
14:34
!checklist
14:34
<ltspbot>
vagrantc: "checklist" is The checklist for debugging problems with local device access is at http://wiki.ltsp.org/twiki/bin/view/Ltsp/LTSP-42-LocalDev#Troubleshooting. Please work through all 12 steps, record the results, and paste the results to the pastebot at http://pastebot.ltsp.org
14:34
<cesar_>
yes..
14:35
I saw this steps
14:35
in http://wiki.ltsp.org/twiki/bin/view/Ltsp/LTSP-42-LocalDev#Troubleshooting
14:36
<vagrantc>
some of them are applicable to ltsp5 and localdev, but some of it is just misleading for ltsp5
14:36
<cesar_>
but.. I found the error in "step 8"
14:37
the program "lbussd" not workind in terminal client
14:37Q-FUNK has joined #ltsp
14:39
<vagrantc>
yeah, lbusd is something not present in ltsp5
14:39
<cesar_>
and.. I not found the correct response for this error
14:39
ufff.
14:40
if lbussd not is present
14:40
in ltsp5
14:40
is the same for me use ltsp4.2 or ltsp5
14:40
because..
14:41alekibango has quit IRC
14:44Egyptian[Home] has quit IRC
14:45Egyptian[Home] has joined #ltsp
15:00mhterres has quit IRC
15:04Guaraldo has joined #ltsp
15:07cliebow__ has quit IRC
15:07
<warren>
vagrantc, here's the latest idea:
15:08
option root-path "192.168.0.254:/opt/ltsp/i386";
15:08
this syntax has been used for years already
15:08
vagrantc, option root-type "nbd";
15:08
vagrantc, option root-path "192.168.0.254:2000";
15:08
<vagrantc>
the syntax is actually "<ip:>PATH<,options>"
15:08
ip and options being... optional
15:09
<warren>
,options can be things like "noatime"?
15:09
<vagrantc>
whatever mount options you care to pass
15:10
warren: so, a machine boots with that eand tries to mount /2000 on your server ... ?
15:10
<warren>
vagrantc, it was only a suggestion, I do dislike the idea of reusing root-path for this.
15:10
<vagrantc>
warren: the point you had made was to avoid using root-path for anything it isn't already established for
15:10
<warren>
vagrantc, the other idea was to define something new like nbd-root-path
15:11
<vagrantc>
warren: i think the second idea is better
15:11Guaraldo has left #ltsp
15:12
<vagrantc>
warren: you pretty much convinced me by the time i finished typing my complaint
15:13
<warren>
convinced of what?
15:13
vagrantc, btw, with bzr is there a way to say exactly which files you want to checkin changes but not others?
15:13
<vagrantc>
warren: that we should use some newly defined option
15:14
warren: bzr ci files/i want/to/commit
15:14
<warren>
ah
15:14
<vagrantc>
warren: i also make use of bzr shelve from bzrtools a lot
15:15
warren: to set aside changes within a file that don't belong in a single commit
15:18
<warren>
vagrantc, I'm personally preferring nbd-root-path, but there is the possibility that we're simply overblowing the danger of redefining root-path.
15:19
<vagrantc>
warren: it's not really a path, though ...
15:19
warren: anyways, i think the options are merely numbers client-side ...
15:19
warren: the server-side human-readable names i think are merely in dhcpd.conf
15:20
i could be wrong on that ...
15:22
<warren>
pjones argues convincingly that a client that screws up due to IP:port isn't going to work anyway.
15:22
So this really isn't a danger.
15:23
<vagrantc>
on any network where you have clients that need the traditional NFS root, and you also have clients with NBD root, you'll have to configure it in dhcpd.conf anyways ...
15:24
if you want both to work
15:24Guaraldo has joined #ltsp
15:24
<vagrantc>
i can't really think of a case where it would really, truely be harmful
15:26Guaraldo has left #ltsp
15:28
<warren>
yeah
15:29
<vagrantc>
then we could have a heuristic determine if it's NFS or NBD based on the content
15:30
although, the way initramfs-tools is designed, that won't work so well ....
15:30
it kind of assumes you know if you're doing a hard drive, nfs or FOO type boot
15:31
but whatever. we'll figure it out eventually
15:31
hmmm...
15:32
well, we could a ltsp script that just sources the appropriate NFS/NBD/FOO scripts ... not so ugly, i guess.
15:33
<laga>
for initramfs?
15:34
<vagrantc>
yes
15:34
<laga>
isn't that already done for debian? eg, you have different scripts for nfs/"normal"/ltsp_nbd..
15:35
<vagrantc>
yes, but you have to hard-code or define at the boot prompt which to use
15:35
i want to get that information from dhcp
15:36
or at least, be able to.
15:37
<laga>
that sounds great
15:39
<vagrantc>
maybe i'll call this meta-script "dhcp" ... then you can say boot="dhcp" at the boot prompt or BOOT="dhcp" in the configuration file, it'll make a dhcp request and source the local (hard drive) script if it doesn't get any promising information, and figure out if it should use NFS or NBD and source the appropriate scripts if needed
15:39
and possibly other scripts ...
15:41
warren: i also want NBD root to be more than just unions+squashfs+NBD ... i tested NBD+squashfs+tmpfs bind mounts once and it worked well
15:42
NBD+FILESYSTEM(s)+WRITE_METHOD(s)
15:42
that's what i'd like to be able to support in the long run.
15:43
warren: what are you looking at using? neither unionfs or squashfs are in the mainline kernel, are they?
15:43
warren: NBD + tmpfs bind mounts ?
15:44
<warren>
vagrantc, initially readonly root with fedora's readonly-root mode, which does tmpfs bind mounts automatically.
15:44
vagrantc, a little later dm-snap for block-level changes instead of unionfs.
15:44
vagrantc, looks like our people were correct in believing unionfs will never hit upstream anytime soon
15:44
didn't hit 2.6.25 like the media said it would
15:45
<vagrantc>
warren: NBD + $filesystem + readonly-root ?
15:45
<warren>
LKML has some very harsh criticisms remaining of unionfs
15:45
vagrantc, NBD + squashfs + readonly-root mode at first, already works
15:45
<vagrantc>
warren: squashfs is in kernel now?
15:45
<warren>
vagrantc, good question
15:46* warren looks
15:46
<laga>
nicoAMG: i currently use NBD + aufs and it's working great.
15:46
err, vagrantc i meant. sorry nicoAMG
15:46
<warren>
vagrantc, we switched to squashfs from something else because the something else couldn't handle images above a certain size
15:46
<vagrantc>
i've been focusing mostly on ltspfs and ldm lately ... haven't really looked forward to messing with the underlying filesystem too much.
15:47
<nicoAMG>
laga: NP :)
15:47
<warren>
vagrantc, oh I see. squashfs isn't usptream either.
15:48K_O-Gnom has quit IRC
15:48
<vagrantc>
warren: that's what i meant ... that always seemed to be a major issue for you
15:48
<warren>
vagrantc, squashfs is considered to be less crack filled though. So we're only partially hypocritical.
15:48cesar_ has quit IRC
15:48
<warren>
vagrantc, we are still very careful about what we put into the kernel
15:49
vagrantc, squashfs has little chance of causing some unexpected failure, while unionfs still has known cases where it can fail spectacularly (which is why it continues to undergo heavy revision and review upstream)
15:49
<notting> squashfs, being a read-only filesystem, tends to avoid many of the races and deadlocks that unionfs is subject to
15:49
<vagrantc>
sure.
15:49
<warren>
So yes we are hypocritical
15:49
but just only slightly
15:49
<vagrantc>
choose your battles wisely :)
15:50
i'm somewhere between idealist and pragmatist :)
15:50
sometimes i swing heavily one way or the other
15:50
<warren>
oh nice, we have an engineer upstreaming squashfs
15:50
<vagrantc>
ok, so qemu-system-mips works reasonably well. yay.
15:51
hopefully i can actually test some of this mips hardware now.
15:51
easier to network boot than install an OS :)
15:57
<warren>
really?
15:57
how fast?
16:00
<vagrantc>
i've got it running in a xen instance on a dual 2.4GHz xeon
16:00
it feels a little sluggish
16:01
although qemu-system-mips is written to take advantage of multiple procs as far as i can tell ... unless there's a commandline option
16:02rcy` has joined #ltsp
16:03
<vagrantc>
both mips and mipsel seem to work reasonably well in debian sid
16:03
in qemu
16:04nicoAMG has quit IRC
16:06
<warren>
cool
16:14gonzaloaf has quit IRC
16:18pawsmacker has joined #ltsp
16:21jammcq has quit IRC
16:22mccann has quit IRC
16:32mccann has joined #ltsp
16:36toscalix has quit IRC
16:44rcy` has quit IRC
16:45rcy` has joined #ltsp
16:47rcy` has joined #ltsp
16:51pawsmacker has left #ltsp
17:05bobby_C has quit IRC
17:12
<vagrantc>
warren: you deleted a couple revisions from the ltsp-trunk branch.
17:12
<warren>
vagrantc, huh?
17:12
vagrantc, i did a bzr pull first
17:13
:q
17:13
oops
17:13
<vagrantc>
warren: you changed the order of commits
17:13
<warren>
your commits?
17:13
<vagrantc>
hrm. i don't quite understand what happened.
17:14
<warren>
vagrantc, all I did was bzr pull, it told me to use merge, it said everything merged fine (we didn't touch any files in common)
17:14
<laga>
the missing revisions probably show up in the changelog.
17:14
<vagrantc>
warren: unfortunately, this is where bzr gets a little brain-dead
17:14
<warren>
I was trusting bzr too much?
17:15
I did this several times before
17:15
did I lose other things?
17:15* vagrantc investigates
17:15
<vagrantc>
i thought i set a flag so that wouldn't happen anymore...
17:15
i got an email sainy 2 revisions were removed from the branch ... now the question is ... which two
17:16
<warren>
all I did was bzr pull, bzr merge, bzr push
17:16
<vagrantc>
warren: ok, so what happened is you clobbered my 561 and 562
17:16
warren: yes, and that will cause this to happen
17:16
<warren>
what should I have done?
17:17
<vagrantc>
pull and push need to be used with care.
17:17
<warren>
I have more changes to push soon
17:18
<vagrantc>
warren: what should happen is it should refuse to allow you to push if you're overwriting revisions ...
17:18
this almost makes me want to abandon bzr entirely.
17:18
way more than performance issues.
17:18
<warren>
no, I mean what shoudld I have done locally to ensure that I don't clobber your changes?
17:18
I've done this a few other times so I wonder if I clobbered other things.
17:18
vagrantc, note... launchpad seems to be a really slow place to host bzr
17:18
vagrantc, bzr on fedora's servers are WAY faster
17:18
<vagrantc>
warren: rather than merge the upstram changes into your branch, you should merge your changes into upstream.
17:19
i honestly don't care much about the performance issues with bzr at all.
17:19
<warren>
vagrantc, so I made local changes, I should use what commands?
17:19
vagrantc, I clobbered your actual changes or only the changelogs?
17:19
<vagrantc>
warren: so instead of merging ltsp-trunk into your branch, you should have grabbed a new copy of ltsp-trunk and merged your changes into it.
17:20
warren: yoclobbered the commit history.
17:20
<warren>
OK, I didn't know this before.
17:20
<vagrantc>
warren: what was previously revisions 561 and 562 are now your merge 563
17:20
<warren>
cd ltsp-trunk; bzr pull ../ltsp-warren; bzr merge; bzr push?
17:21
vagrantc, like that?
17:21
vagrantc, I guess git has rebase for this purpose...
17:21
<vagrantc>
warren: cd ltsp-trunk ; bzr pull ; bzr merge ../ltsp-warren ; bzr push
17:21
pull and push is where the revision history will get overwritten.
17:22
<warren>
OK, I didn't know this before, I'll be more careful in the future.
17:22
<vagrantc>
and i frequently throw a few "bzr missing" in for good measure.
17:22J45p3r has joined #ltsp
17:24
<vagrantc>
warren: thing is... you should have to worry about a Version Control System cloberring ... Version information.
17:24
s,should,shouldn't,
17:25
<warren>
vagrantc, this wasn't malicious intent. I've never used a VCS that behaves in this way before.
17:25
It seems that bzr is missing anything like git-rebase
17:25
which seems stupid
17:25
<vagrantc>
warren: git does it all the time.
17:25
every time you rebase, it changes the revision history
17:26
it's not like the commits are gone, but how the history of how they entered the repository is lost.
17:26
pwd
17:26
ls
17:26
and so the revision where you merged changes has unrelated changes in a single commit, which i generally don't like.
17:26
<warren>
vagrantc, I now know what to do
17:27
vagrantc, there's no need to be upset and continue to remind me of the mistake I made. I had no way of knowing.
17:27
I thought you even stopped this from happening on the server side
17:27
<vagrantc>
warren: i'm *not* blaming you!
17:27
i'm blaming BZR
17:27
this is my most hated "feature" of bzr.
17:27
<warren>
launchpad is so slow....
17:28
<vagrantc>
i thought i stopped this from happening too, but clearly there's something wrong.
17:28
<warren>
are your revision history things actually gone
17:28
didn't it just rename it?
17:29
<vagrantc>
warren: what was previously 561 and 562 are now both mushed into 563
17:29
and in revision 563 you can see the two separate commits
17:29
<warren>
vagrantc, if you bzr pull from your previous tree it isn't able to step to the current contents on the server?
17:30
<vagrantc>
warren: not without re-writing history
17:30
<warren>
(are you sure it didn't just rename the revision numbers?)
17:30
<vagrantc>
warren: what do you mean by rename?
17:30
<warren>
Maybe it is designed to rename the revision numbers
17:30
it didn't actually lose it
17:31
<vagrantc>
the content of the commits is still there, but the revision history is changed.
17:31
<warren>
maybe append-only actually is working
17:31
bzr is just designed to rename the revision numbers
17:31
nothing is actually lost?
17:31
<vagrantc>
so if i tell someone "look at the changes introduced in revision 531" and they'll be looking at a totally different set of changes
17:31
<warren>
I don't know, just guessing.
17:32
<vagrantc>
append-only is *supposed* to prevent it from mucking with the revision history ... but it doesn't work if your branch format isn't recent enough
17:32
that's probably what it is
17:32Q-FUNK has quit IRC
17:33* warren pushing more
17:34* laga also loves how bzr frequently breaks backwards compatibility by introducing new branch formats
17:35
<vagrantc>
yeah, it's been stable for like 3 whole months!
17:35
<laga>
oh, neat.
17:35
i felt bad when i created a new branch and forced someone from my team to upgrade his bzr install
17:36
<vagrantc>
probably about time to go through a swift period of a couple new formats with each release
17:36
<laga>
sure. gotta keep those users on their toes ;)
17:37
ah well, it could be worse. :)
17:40johnny_ has joined #ltsp
18:09iMav has quit IRC
18:09twinprism has quit IRC
18:26alekibango has joined #ltsp
18:43iMav has joined #ltsp
18:43twinprism has joined #ltsp
18:48alekibango has quit IRC
18:51mistik1_ has joined #ltsp
18:56alekibango has joined #ltsp
18:59staffencasa has quit IRC
19:02ogra_cmpc_ has joined #ltsp
19:03ogra_cmpc has quit IRC
19:03ogra_cmpc_ is now known as ogra_cmpc
19:05mistik1 has quit IRC
19:05mistik1_ is now known as mistik1
19:46alekibango has quit IRC
19:46alekibango has joined #ltsp
19:54johnny_ has quit IRC
20:02rmxnoc has joined #ltsp
20:02rmxnoc has joined #ltsp
20:09Q-FUNK has joined #ltsp
20:20elisboa_ has joined #ltsp
20:21spectra has quit IRC
20:21rmxnoc has quit IRC
20:23elisboa_ has quit IRC
20:23elisboa_ has joined #ltsp
20:25elisboa_ has quit IRC
20:25elisboa_ has joined #ltsp
20:31iMav has quit IRC
20:42vagrantc has quit IRC
21:03J45p3r has quit IRC
21:14Q-FUNK has quit IRC
21:22otavio has quit IRC
21:23otavio has joined #ltsp
21:39ogra has quit IRC
21:39ogra_cmpc has quit IRC
21:40ogra has joined #ltsp
21:40ogra_cmpc has joined #ltsp
21:44alekibango has quit IRC
21:48mccann has quit IRC
22:17mccann has joined #ltsp
22:28BGomes has joined #ltsp
22:46
<warren>
sigh, launchpad is very slow for me
23:13
<johnny>
warren, how's the port goin?
23:13mccann has quit IRC