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


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

00:00sadap has joined #ltsp
00:01
<sadap>
Hi,
00:01
Some body can help me?
00:01
<MacIver>
probably not
00:01
<sadap>
iWy?
00:01
why?
00:02
<MacIver>
because you never asked a question that could help you
00:06
<sadap>
jejeje, Ok, since two years ago, I installed LTSP on Ubuntu, today i change to 7.10 and now when i type the user name and password, Ubuntu show me a message, it's something like ... "This Workstation is't autorized to conect the server", something like that, I need help
00:09tux_440volt has joined #ltsp
00:09
<sadap>
Note: Began when I change the IP Address
00:11
<MacIver>
you need to run sudo ltsp-update-keys or somesuch
00:12
on the server
00:14klausade has quit IRC
00:14
<sadap>
ok, I regenerate the key with , I going to try
00:14
<cyberorg>
warren, i sent in all the plugins for suse
00:14
<sadap>
with: ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
00:14
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa
00:15
<MacIver>
basically the keys are keyed off the ip (pardon the pun)
00:15
<sadap>
thank's Macliver
00:15
<MacIver>
sadap: np :)
00:17klausade has joined #ltsp
00:27tux_440volt has quit IRC
00:27sadap has left #ltsp
00:33subsume_ has joined #ltsp
00:33subsume_ is now known as subsume
00:40makghosh has joined #ltsp
00:47petre has joined #ltsp
00:48makghosh has quit IRC
00:59makghosh has joined #ltsp
01:04petre has quit IRC
01:07makghosh has quit IRC
01:22subsume has quit IRC
01:23wicuo has joined #ltsp
01:23|Paradox| has quit IRC
01:23wicuo is now known as |Paradox|
01:30makghosh has joined #ltsp
01:54makghosh has quit IRC
01:59subir has joined #ltsp
01:59chupa has joined #ltsp
02:01chup has quit IRC
02:07deavid has joined #ltsp
02:15makghosh has joined #ltsp
02:36tuukka has joined #ltsp
02:37Pascal_1 has joined #ltsp
02:38Q-FUNK has joined #ltsp
02:39
<tuukka>
hi and good morning! (i'm using gutsy) has anyone run into problem where user 'lp' (printing??) ends up taking all the available processor time?? top says that command is 'socket' and it doesn't allow the process to be closed down...
02:41
shutting down the thin client ends the process but it wakes up at some point when thin clients are used ...
02:43t-kid has joined #ltsp
02:44
<t-kid>
hellow
02:51
<Pascal_1>
hello
02:52
<gvy>
warren, ayt?
02:55
<Pascal_1>
actually i've got a litle problem with ltsp and pam, then when a user logout from a thin client for exemple pam_mount doesnt umount properly samba share. my question : is there a way to put a script somewhere to umount automaticaly this share. i know that is possible when user login on console (.bsash_logout) with gdm (/etc/gdm/PostSession/Default. ) but i dont know how to do with ldm
02:57
<tuukka>
pascal: i didn't find a proper way to do this. instead i made script which is run once in every 30 minutes that unmounts all shares that arent necessary any more...
02:58
pascal: this is propably the most inefficient solution but i didn't find any other way to do this!
02:59
<Pascal_1>
i put a bug report here : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471793 is this the same problem for you ?
02:59
<klausade>
Pascal_1: if you use kde, put an unmount-script in ~/.kde/shutdown/.
03:00
Pascal_1: or maybe even better use pam-script: http://linux.bononline.nl/linux/pamscript/
03:00
<Pascal_1>
ldm / gdm
03:00
klausade, it seems to be the problem : "ldm doesn't handle pam logouts properly"
03:00
<klausade>
Pascal_1: then use pam-script. I have that running in some libaries to to some housecleaning when users log out.
03:01
<Pascal_1>
hmm, but if ldm doesnt "use "pam module
03:02
<klausade>
Pascal_1: pam-script works fine together with ldm for me.
03:02
<Pascal_1>
i m going to look at this module
03:03
have you got some examples for me ?
03:05captain_magnus has quit IRC
03:07captain_magnus has joined #ltsp
03:08
<klausade>
Pascal_1: what distro are you on?
03:08
<Pascal_1>
debian etch
03:09
but that i dont understand is when user disconnect from ldm module pam are not readed then why pam_script would work ?
03:09
sorry for my english.....
03:10
<klausade>
Pascal_1: download and compile pam_script.so
03:11
<Pascal_1>
"Any PAM-aware application can use the module to perform arbitrary operations" ldm dont seem to be a "pam aware" application no ?
03:13
<klausade>
Pascal_1: don't belive everything you read. download and compile pam_script and see for yourself.
03:13
<Pascal_1>
;-)
03:20
Bonjour !
03:36subir has quit IRC
03:38mikkel has joined #ltsp
03:42
<Pascal_1>
klausade, same problem
03:42
it works when user logon
03:43
but it doesnt works when user logout
03:43
may be my pam.d file are wrong
03:43
<klausade>
if it works with logon, then your pam.d should be correct.
03:44
<Pascal_1>
it works for you ?
03:44
<klausade>
Pascal_1: what does your onsessionclose look like?
03:45
<Pascal_1>
i made 2 ridiculous script
03:45
touch file onsessionopen
03:45
touch another_file onsessionclose
03:45
<klausade>
Pascal_1: yes, that is how i test aswell :-)
03:45
<Pascal_1>
in the log when logout there is nothing
03:45
i paste the auth.log
03:46
<klausade>
Pascal_1: use pastebin somewhere
03:46
<Pascal_1>
ok
03:48
http://pastebin.fr/1258
03:49
<cyberorg>
Pascal_1, have you tried ~/.bash_logout
03:49
or /etc/bash_logout for system wide script
03:49
<Pascal_1>
cyberorg, it doesnt works, it's only for console
03:50
<klausade>
Pascal_1: have a look in /var/log/auth.log
03:51
<Pascal_1>
my pastebin is auth.log
03:53
<klausade>
Pascal_1: yes, me bad.
03:53
<Pascal_1>
the same fot you ?
03:53
for
03:56
<klausade>
Pascal_1: I need to rearange some servers her to test (still on Easter holiday)
04:02
Pascal_1: works for me.
04:02
Pascal_1: I use /etc/security/onsessionclose. see pastebin.
04:03
<Pascal_1>
pastebin
04:04
<klausade>
http://pastebin.fr/1259
04:04
<Pascal_1>
can you pastebin your pam.d files
04:06
<klausade>
yes 1259
04:18bobby_C has joined #ltsp
04:23ogra_cmpc has joined #ltsp
04:23ogra_cmpc has left #ltsp
04:25
<klausade>
it's 1261 now that i look at it
04:32cyberorg has quit IRC
04:33twinprism has quit IRC
04:38Faithful has quit IRC
04:50
<Pascal_1>
thank you klausade i make some test
04:55
<klausade>
Pascal_1: what version of pam-script do you use?
04:55
<Pascal_1>
i think the last one
04:57
0.1.11
04:57K_O-Gnom has joined #ltsp
05:04
<Pascal_1>
it works now with ssh
05:04
i've got to try with ldm
05:04
i've got a problem onsessionclose
05:05
i try with the same script than you but i've got that Mar 25 11:03:31 ltsp sshd[14250]: PAM-script: Unable to run as uid 534
05:05
Mar 25 11:03:31 ltsp sshd[14250]: PAM-script: waitpid error: 10
05:11
<klausade>
Pascal_1: what is the file permission on your onsessionclose?
05:12
<Pascal_1>
755 on the two
05:13
when i try from ldm (thin client) i've got this message : sshd[14313]: channel 7: open failed: administratively prohibited: open failed
05:17
the same with 777 permission
05:21
<klausade>
Pascal_1: haven't seem that before. I'm using libpam-script_0.1.8.tar.gz
05:24basanta has joined #ltsp
05:28
<Pascal_1>
it doesnt works even if i put runas=root
05:37
is it the same : http://sourceforge.net/project/showfiles.php?group_id=133192 ?
05:45
klausade, can you send me your version ?
05:45
<klausade>
Pascal_1: no, the readme file is very different.
05:46
<Pascal_1>
i mean the tar.gz
05:48
<klausade>
Pascal_1: http://user.skolelinux.no/~klaus/libpam-script_0.1.8.tar.gz
05:48chupa has quit IRC
05:48
<klausade>
Pascal_1: can say for sure where I found it, or if the one you found is better.
05:48chupa has joined #ltsp
05:51Q-FUNK has quit IRC
05:52Q-FUNK has joined #ltsp
05:53bobby_C has quit IRC
05:57sepski has joined #ltsp
05:58
<klausade>
Pascal_1: i probably got it here: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libpam-script
06:58mhterres has joined #ltsp
06:59cyberorg has joined #ltsp
07:12Guaraldo has joined #ltsp
07:17chupa has quit IRC
07:17chupa has joined #ltsp
07:17basanta has quit IRC
07:19jammcq has quit IRC
07:30stgraber_ has joined #ltsp
07:31stgraber_ has joined #ltsp
07:35slidesinger has joined #ltsp
07:36K_O-Gnom has quit IRC
07:37K_O-Gnom has joined #ltsp
07:43pdjbarber has joined #ltsp
07:47jammcq has joined #ltsp
07:48t-kid has quit IRC
07:55K_O-Gnom has quit IRC
07:55K_O-Gnom has joined #ltsp
08:04makghosh has quit IRC
08:07deavid has quit IRC
08:10tuukka has quit IRC
08:12Faithful has joined #ltsp
08:16
<Pascal_1>
klausade : now it works from ssh but nothing from ldm , does it works for you from a thin client with ldm ?
08:21bobby_C has joined #ltsp
08:22cliebow_ has joined #ltsp
08:23cliebow_ has quit IRC
08:28F-GT has quit IRC
08:30
<klausade>
Pascal_1: yes it works from ldm.
08:31
<Pascal_1>
snirf
08:32mhterres has quit IRC
08:34
<klausade>
Pascal_1: what ltsp5 version are you using?
08:35
<Pascal_1>
Version: 5.0.40~bzr20080214-1~40.etch.0
08:35
from backports
08:35mhterres has joined #ltsp
08:36
<Pascal_1>
for pam.d i'havent foreground.so, is it important ?
08:37subsume_ has joined #ltsp
08:37
<klausade>
Pascal_1: i'm using 5.0.8debian3. that ldm is written i python, while yours is written i c, yes?
08:37subsume_ is now known as subsume
08:37
<Pascal_1>
klausade, yes
08:37
<klausade>
Pascal_1: foreground is not important in this case.
08:39
Pascal_1: i think the different ldm's might be worth investigating.
08:43
<Pascal_1>
klausade, are you on debian ?
08:44Q-FUNK has quit IRC
08:44
<Pascal_1>
the logout is not seen by pam
08:45Gadi has joined #ltsp
08:46xcasex_ has joined #ltsp
08:49
<klausade>
Pascal_1: yes, i'm using debian stable.
08:49
<Pascal_1>
it's very strange then, why it doesnt works for me
08:50petre has joined #ltsp
08:50
<petre>
morning all
08:51
<klausade>
Pascal_1: we use totally different ldm's.
08:52
<Pascal_1>
what i see is the problem occure only for root.i explain from ssh it work fine but not for root user
08:52
did you modify something in your sshd_config ?
08:52
<klausade>
Pascal_1: if you can make a tarball of your chroot and upload it somewhere, I can test it here on one of the servers.
08:53
<Pascal_1>
tar -cf /home/ltsp.tar /opt/ltsp/i386/* like that ?
08:54
and about your sshd_config ?
08:58vagrantc has joined #ltsp
09:00mccann has joined #ltsp
09:02
<klausade>
Pascal_1: use tar -czf /home/ltsp.tgz /opt/ltsp/i386
09:04elisboa has quit IRC
09:08elisboa has joined #ltsp
09:12F-GT has joined #ltsp
09:16
<Pascal_1>
klausade, you didnt anwser me about the sshd_config file, did you modify it ?
09:16
<klausade>
Pascal_1: no.
09:17pdjbarber has quit IRC
09:17
<klausade>
Pascal_1: http://pastebin.fr/1262
09:21gvy has quit IRC
09:22gvy has joined #ltsp
09:22
<gvy>
phew, back from city traffic jam
09:22
!seen warren
09:22
<ltspbot>
gvy: warren was last seen in #ltsp 16 hours, 23 minutes, and 15 seconds ago: <warren> is X supposed to restart if you have the wrong password in ldm?
09:23deavid has joined #ltsp
09:23
<Pascal_1>
klausade, 150 mo !!!
09:24
<klausade>
Pascal_1: yes, is the size a problem for you?
09:24
<Pascal_1>
hmm
09:24
i dont really know how to do
09:25
i've got a ftp server (from free) i think is not very speed
09:26
<klausade>
Pascal_1: we have time.
09:26
<Pascal_1>
sure !!!
09:27
http://plegrand1.free.fr/
09:28
<klausade>
Pascal_1: please also genrate a md5sum for ltsp.tgz.
09:28
<Pascal_1>
arf
09:29
md5sum ltsp.tgz ?
09:29
<klausade>
Pascal_1: yes
09:29
Pascal_1: it will take 45 min to download, doing it now.
09:30
<Pascal_1>
right
09:30
it's ok
09:30
thanks a lot for your help
09:31Daggett has joined #ltsp
09:33chupa has quit IRC
09:34chupa has joined #ltsp
09:38xcasex_ has quit IRC
09:38dtrask has joined #ltsp
09:42mikkel has quit IRC
09:49subsume has quit IRC
09:55vmlintu has joined #ltsp
10:05Q-FUNK has joined #ltsp
10:05K_O-Gnom has quit IRC
10:10Q-FUNK has quit IRC
10:11Q-FUNK has joined #ltsp
10:11praveer_cool has joined #ltsp
10:15
<Pascal_1>
klausade, i thought about an other thing, did you put something special in your lts.conf ?
10:15
<klausade>
Pascal_1: no
10:16
<Pascal_1>
ok
10:16
here is my lts.conf : http://pastebin.fr/1264
10:17
<klausade>
looks ok to me
10:20
<Pascal_1>
i've got to leave a moment, could we see together tomorrow if my chroot is ok ?
10:21
<klausade>
Pascal_1: i'm booting a client with your chroot right now. can you wait 10 minutes?
10:22
<Pascal_1>
yes
10:22
sure !!! ;-)
10:22
the problem is about the logout
10:22
nothing happen
10:23
<klausade>
Pascal_1: i'll have a look. one sec
10:26staffencasa has joined #ltsp
10:33
<Pascal_1>
klausade, i'm sorry i've got to go now
10:33
<klausade>
Pascal_1: see you tomorrow.
10:34
<Pascal_1>
ok thank you again for the time you spend for me
10:38dtrask has quit IRC
10:39Daggett has quit IRC
11:04Faithful has quit IRC
11:13DonSilver has joined #ltsp
11:14lns has quit IRC
11:15chupa has quit IRC
11:16chupa has joined #ltsp
11:36pdjbarber has joined #ltsp
11:36pascal_2 has joined #ltsp
11:37cliebow_ has joined #ltsp
11:37
<cliebow_>
z
11:39
<Q-FUNK>
nothing but static on channnel Z
11:42
<gvy>
:)
11:45
/nick static
11:56chupa has quit IRC
11:56chupa has joined #ltsp
11:58pascal_2 has quit IRC
12:04Q-FUNK has quit IRC
12:08elisboa has quit IRC
12:09spectra has joined #ltsp
12:17elisboa has joined #ltsp
12:25staffencasa has quit IRC
12:25staffencasa has joined #ltsp
12:43
<ltsppbot>
Someone pasted "vagrantc replies" (19 lines) at http://pastebot.ltsp.org/484
12:43
<cyberorg>
vagrantc, ^^
12:46chup has joined #ltsp
12:46* vagrantc looks
12:46tux_440volt has joined #ltsp
12:46chupa has quit IRC
12:46
<vagrantc>
cyberorg: you added a --config option, and there is code in ltsp-build-client that handles --config
12:47
cyberorg: regarding chroot-tagging ... is it *possible* for someone to accidentally install the ltsp-client packages on a system, and would it be distruptive if they got installed ?
12:47
<cyberorg>
vagrantc, yes, it would be
12:48
<gvy>
vagrantc, cyberorg, halo
12:48
<vagrantc>
cyberorg: the only reason we did chroot tagging was to keep it outside of the package so that we could detect if the package was being installed in cases where it shouldn't be
12:48
<cyberorg>
does .deb do checking for such tag before installing a package?
12:48
<gvy>
vagrantc, re "gvy, led, shigorin" -- "gvy" is my nick, "mike" is my login, "shigorin" is my family name
12:49
"led" is login/nick of my colleague, apparently a different person. :)
12:49
<vagrantc>
cyberorg: there is a pre-install script which checks if the /etc/ltsp_chroot is present, and fails to install.
12:49
<cyberorg>
hi gvy led shigorin mike :)
12:49
<gvy>
i'm not that schisophrenic to pretend to work as two developers and flame as three at the same time :)
12:49
hi cyberogra :)
12:50
<vagrantc>
gvy: oh, the bzr commits were done as led.
12:50
<cyberorg>
gvy, ogra would never have opensuse/member/cyberorg ;)
12:50
<gvy>
vagrantc, btw led's pushed a few revisions more to http://ftp.linux.kiev.ua/pub/Linux/ALT/people/led/bzr/ltsp/ltsp-altlinux/
12:50
<cyberorg>
may be if he got tired of canonical
12:50
<gvy>
should cause no conflicts either, still specifics
12:51
but these might be more widely useful some day
12:51
<cyberorg>
vagrantc, i mean, if someone downloads ltsp-client package and tried to install on the server
12:51
<gvy>
that is, factored into more common code
12:51
<cyberorg>
what happens then?
12:51
<gvy>
cyberorg, well i sometimes do Conflicts: lilo, grub to help avoid that and start thinking
12:51
<vagrantc>
gvy: i don't know how to say this ... but i am ... very unhappy with ogra not being around ... and so, i have a hard time interacting with you.
12:51
<gvy>
(and reading package descriptions if not docs)
12:51
vagrantc, me too
12:52
i've searched for his mobile and jabber, found only the latter, no reply (as well as on last week's private mail) yet
12:52
<cyberorg>
gvy, great idea, chroot does not have grub/lilo
12:52
<vagrantc>
cyberorg: yes, basically, since intslling the ltsp-client package is potentially damanging ... we implemented a check to make sure it wouldn't install on a "normal" machine.
12:53
<gvy>
vagrantc, if you happen to meet him active somewhere, would you please pass my sorry to him? :(
12:53
<laga>
gvy: #edubuntu
12:53
<gvy>
cyberorg, or you can exit 1 in %pre if things look like a real system
12:53
<cyberorg>
vagrantc, i still did not understand --config being over ridden
12:54
<vagrantc>
cyberorg: there is a --config option in ltsp-build-client.
12:54
<gvy>
laga, hm, joined but never seen him replying there... thanks, trying again
12:54
<cyberorg>
what does it do?
12:54
<vagrantc>
cyberorg: for at least 2 years now.
12:54
cyberorg: it sources the file.
12:54
<cyberorg>
vagrantc, so CONFIG="/etc/sysconfig/kiwi-ltsp" won't work?
12:54
<vagrantc>
cyberorg: i.e. ltsp-build-client --config /etc/ltsp/my-custom-ltsp-build-foo.conf will source that file.
12:55
cyberorg: if your file is just a file that is safe to source in shell scripts, it's probably fine.
12:55
<cyberorg>
are you referring to 001-load-configuration-file?
12:56
vagrantc, yeah, it is meant for sourcing :)
12:56
<vagrantc>
cyberorg: grep config server/ltsp-built-client
12:57
<cyberorg>
i don't really need 001-load-configuration-file as the config files get sourced by kiwi-ltsp-setup script any way, but wanted to make use of all the generic infrastructure ltsp plugins provide
12:57
<vagrantc>
cyberorg: 001-load-configuration-file happens too late.
12:57
cyberorg: and there's also code within ltsp-build-client outside of the plugins to handle it ...
12:58
<cyberorg>
vagrantc, we call kiwi-ltsp-setup much later, so that is not an issue
12:58
<vagrantc>
cyberorg: yes, but it *breaks* debian systems.
12:58
:P
12:59
maybe it is fine for it to be there ...
12:59
but the corresponding code in ltsp-build-client should be removed.
13:00
<warren>
cyberorg, if you don't need a specific plugin in common, you can copy it to your directory as a blank file
13:00
cyberorg, sometimes it turns out nobody wants the common, then we can discuss removing/changing it on the list
13:00
<gvy>
vagrantc, yay! <ogra_cmpc> gvy, i am, but extremely busy, i was planning to come to #ltsp later tonight and write a mail as well if i have time ...
13:00
warren:
13:00
<cyberorg>
warren, just before you commited the one liner, i sent the whole plugin
13:00
<vagrantc>
gvy: that's good news.
13:00
<gvy>
<ogra_cmpc> i'll be back, i just need to sort out a lot work stuff that stacked up over easter
13:01rjune_ has joined #ltsp
13:01
<rjune_>
!g
13:01
<ltspbot>
rjune_: "g" is Gadi!!!!!!!!!!!!!!!!!!!!!!!!
13:01
<cyberorg>
warren, http://sourceforge.net/mailarchive/forum.php?thread_name=b317ae5c0803241308x3397ccb6qeda635557d29e85e%40mail.gmail.com&forum_name=ltsp-developer
13:02* warren silent.wav
13:02
<vagrantc>
cyberorg: regarding --config, i guess i'll just remove the old code ... maybe the common plugin is actually ok.
13:02
<gvy>
warren, more non-conflicting (but movable later) stuff pushed to http://ftp.linux.kiev.ua/pub/Linux/ALT/people/led/bzr/ltsp/ltsp-altlinux/
13:02
<cyberorg>
vagrantc, --config is useful
13:03
<vagrantc>
cyberorg: YES. i understand that it is useful.
13:03
<gvy>
btw re laggy pipe: i don't know why but yesterday it took me 15 minutes to clone 15 megs over 10mbit from that system
13:03
<vagrantc>
cyberorg: it ALREADY existed, and there is ALREADY code that handles it.
13:03
<cyberorg>
vagrantc, so why remove it :)
13:03
<vagrantc>
cyberorg: because i think your plugin actually works better.
13:03
<warren>
I'm under a lot of pressure before Fedora 9 devel freeze, I will personally get back to helping you other distros get stuff into upstream after the freeze.
13:04
<gvy>
warren, np
13:04
<cyberorg>
warren, could you just commit the "proper" suse plugin that is posted, it doesn't conflict with anything :)
13:05
or may be vagrantc you can do it as you have seen the diff
13:05
<warren>
didn't vagrant give suggestions to improve it?
13:05
<cyberorg>
warren, yes that is what we are discussing :|
13:06
<warren>
cyberorg, if there is already suggestions to improve it I'm not going to check it in as-is
13:06
<vagrantc>
cyberorg: i'll work with you on it.
13:06
<warren>
cyberorg, vagrantc: question regarding your Xsession script
13:06
<vagrantc>
warren: debian's Xsession script ?
13:07
<warren>
cyberorg, vagrantc: is one valid way of using your Xsession script to call a desktop session as $1?
13:07
cyberorg, vagrantc: for example, /path/to/Xsession /usr/bin/gnome-session ?
13:07
<vagrantc>
warren: yes ... /path/to/Xsession [/path/to/]foo-session
13:08
<warren>
cyberorg, vagrantc: https://bugzilla.redhat.com/show_bug.cgi?id=436912 I'm working on this bug, where launching /usr/bin/gnome-session directly might work, but it bypasses a bunch of other stuff that our desktop sessions want.
13:08
cyberorg, vagrantc: I'm considering if this works for other folks, to have ldm explicitly launch /path/to/Xsession [/path/to/]session
13:08
<cyberorg>
let me check with vuntz, he is upstream maintainer of gnome-session
13:08
<warren>
cyberorg, this isn't gnome-session, this is your xinit related scripts
13:09
<vagrantc>
warren: on debian, specifying the session at all is optional
13:09
<warren>
vagrantc, here too
13:09
<vagrantc>
warren: ok.
13:09
<warren>
vagrantc, but ldm provides you options of sessions, choosing the non-default bypasses Xsession
13:09
<vagrantc>
warren: so i would prefer to leave LDM to use the "sane defaults" without argument
13:09
<warren>
vagrantc, yes
13:09
<vagrantc>
warren: correct- that is a bug.
13:10
warren: i would much prefer to to use Xsession
13:10
<warren>
vagrantc, thus if we have ldm launch Xsession directly with no arguments by default, then Xsession with one argument if you choose a non-default session.
13:10
<vagrantc>
warren: should work good on debian.
13:10
<warren>
a separate bug... ldm isn't showing me any session options in the menu
13:10
this might have somethig to do with TOO MANY LANGUAGES from locale -a
13:11
<vagrantc>
you and your TOO MANY LANGUAGES problems :)
13:11
<warren>
vagrantc, and I do agree we should have it locate Xsession at build time, do you know how we can modify the automake stuff to do that?
13:11
<vagrantc>
warren: i'm not sure how to get automake to handle that ...
13:11
<warren>
vagrantc, how is Debian going to support the 400 Indian subcontinent languages if your glibc doesn't support them? =)
13:12
<vagrantc>
warren: we only display the languages currently enabled on the system, i believe.
13:13
<warren>
hmm
13:13
maybe I can have a temporary workaround by editing some variable that is cutting off the ldminfod
13:13
<vagrantc>
warren: how many Xsession locations are we dealing with at the moment ? ... debian/ubuntu has /etc/X11/Xsession ... fedora's got ... /etc/X11/xinit/Xsession ...
13:13
<warren>
vagrantc, suse has something else
13:14
Gentoo?
13:14
<vagrantc>
ok, so 3 so far ... surely there's more lurking out there.
13:14
<cyberorg>
warren, here is Xsession we use http://pastebin.ca/956954
13:14
/etc/X11/xdm/Xsession
13:15* warren loves it how everyone has an entirely different Xsession script
13:15
<warren>
our Xsession script is considered "legacy" for compat purposes
13:15
AFAICT
13:16
<vagrantc>
can ltsp being a "Distros with a common Xsession" campaign? :)
13:16
<warren>
vagrantc, distros are very afraid of changing those scripts
13:16
<cyberorg>
mail Author: Werner Fink <werner@suse.de> ;)
13:18
<gvy>
vagrantc, i'm afraid it'd be painful (even if very good if done)
13:18
there are lots of things dying not even in xvendor@...
13:18
<petre>
how about having a standard location for Xsession and each distro putting symlinks to its legacy location?
13:18chup has quit IRC
13:18chup has joined #ltsp
13:19
<dberkholz>
/etc/X11/Sessions
13:19
<cliebow_>
Yippee!!!!
13:19
<dberkholz>
/etc/X11/Sessions/Xsession to be precise
13:20
<vagrantc>
alright ... is there a distro that shares an Xsession script on the face of the earth?
13:20
<dberkholz>
vagrantc: i've actually got some plans to unify our xinit changes with upstream
13:20
vagrantc: and do fedora as well while i'm at it
13:20
<cliebow_>
HE"s ALIVE!!
13:21
<dberkholz>
who?
13:21
ogra?
13:21
<cliebow_>
ogra!
13:21
<warren>
dberkholz, does it work like "Xsession" (run whatever is the default) and "Xsession /path/to/something" to run something else?
13:22
<dberkholz>
eh. it will accept failsafe as an argument, doesn't look like it does anything else with args
13:23
then it merges in all the Xresources, Xmodmap etc files, then tries really part to run an Xclients file that doesn't exist
13:24
really hard*
13:24
we install session scripts to /etc/X11/Sessions/ for each session type. i've got the default "Xsession" one and "Gnome" there now
13:24
could also get kde* (kde-3.5, kde-4) and Xfce
13:26
<warren>
ok, that stinks
13:27
gentoo is doing it in a completely different way from other distros
13:27pdjbarbe1 has joined #ltsp
13:27
<warren>
vagrantc, given that, we *could* make the simple change to ldm to work for everyone but gentoo, but ...
13:27
<dberkholz>
we're probably the only ones still doing an upstream-like setup =P
13:27
<warren>
dberkholz, ...
13:28
dberkholz, ldm is doing it EXACTLY like how gdm and kdm upstream do it
13:28
<dberkholz>
how about xdm?
13:28
<warren>
xdm had no standard
13:28
i'll be back in about 30 minutes
13:29
<dberkholz>
i'm not as familiar with gdm/kdm because i maintain X, not gnome/kde, but i could take a look through their stuff to see what they do
13:29
<gvy>
bb!
13:29
back tomorrow
13:29
hopefully
13:30
<dberkholz>
if it turns out xdm is the wrong one now, i've got no problems changing it
13:30
<cyberorg>
vagrantc, what work i need to do?
13:30
<vagrantc>
cyberorg: i'm doing some minor changes ...
13:30
cyberorg: otherwise, looks good.
13:30
<cyberorg>
vagrantc, ah, ok
13:31
regarding chroot, kiwi does all that stuff for us, so we don't touch it
13:31deavid has quit IRC
13:31
<vagrantc>
cyberorg: so kiwi doesn't install a package into the chroot ?
13:32
<cyberorg>
vagrantc, yes, it does, it creates bootstrap and installs everything we list in xml file
13:32
<vagrantc>
cyberorg: is it harmful to install that package on a regular system?
13:32
cyberorg: and do you care if someone does so by accident?
13:33
that's all that mechanism was.
13:33
<cyberorg>
vagrantc, kiwi doesn't install anything on normal system
13:33
<vagrantc>
cyberorg: i'm not talking about kiwi, i'm talking about Joe User see's the ltsp-client package, installs it on their server because they want LTSP ... their server is borked.
13:34
cyberorg: i'm talking about a way to prevent something bad from happening.
13:34mikkel has joined #ltsp
13:34
<cyberorg>
vagrantc, if someone manually downloads rpm and installs on the system, i'll put Conflict: in the package as suggested by gvy
13:34
<vagrantc>
well, having grub on a thin-client is actually quite useful.
13:35
there's nothing inherrant in grub that means you can't install it on a thin-client.
13:35
<cyberorg>
then Requires: /etc/ltsp_client :)
13:35
vagrantc, we don't have grub in our client image
13:36
<vagrantc>
cyberorg: what if someone *wants* grub in their client image?
13:36
cyberorg: for purposes you've never dreamed of.
13:36
cyberorg: and now they can't easily do so because you added a conflict
13:36
it seems like an abuse of confliccts.
13:36
<cyberorg>
vagrantc, so how do we handle this? chroot is not created till kiwi is run
13:37
<vagrantc>
cyberorg: well, you can handle it however you want... i'm just explaining the rationale behind why we implemented it ...
13:37
<cyberorg>
vagrantc, i understand the rational, just not how to handle this :)
13:38
chroot doesn't exist till kiwi is run, and kiwi will not run if chroot exists
13:39
<vagrantc>
cyberorg: you probably need to include it in kiwi, then.
13:40pdjbarber has quit IRC
13:40
<cyberorg>
so we don't have any way of tagging chroot except from a package that is installed in the chroot
13:40
<vagrantc>
cyberorg: because you use one thing to do it all for you, there isn't much that ltsp can offer you.
13:40warren_treo has joined #ltsp
13:40
<cyberorg>
vagrantc, that is why i've left it out of the plugin
13:41
<warren_treo>
dberkholz, vagrantc: I had an idea regarding gentoo
13:41
<vagrantc>
cyberorg: but i still think it's important to know what you actually do, so i think it's important to have your plugin there.
13:41warren_treo has quit IRC
13:41
<dberkholz>
warren: let's hear it ! =)
13:41
<vagrantc>
can't gentoo patch ldm on the fly at build time?
13:42
seems like ... exactly what gentoo's good at, no?
13:42
<dberkholz>
vagrantc: yep we can apply patches just like anyone else, or do it conditionally if needed
13:42
<cyberorg>
vagrantc, we cannot tag it from our plugin, because kiwi will not run if the destination folder exists
13:43
<vagrantc>
cyberorg: yes, i understand. so you have to do it *within kiwi*
13:43
<dberkholz>
vagrantc: suboptimal though, would rather have code upstream
13:43
<vagrantc>
dberkholz: well, what about a configure option or something like that ...
13:44
<dberkholz>
i'd prefer to move gentoo to just act more standard if that's the problem
13:44
<cyberorg>
vagrantc, yeah, i'll have to work on something better, if not as a last resort abuse Conflicts :)
13:44
<vagrantc>
seems like warren's idea will have to wait.
13:44
<dberkholz>
and if there is a de facto standard rather than a conglomeration of differences
13:45TelnetManta has quit IRC
13:48
<vagrantc>
cyberorg: regarding --set-dist ...
13:49
cyberorg: why not create a new plugin that just sets SUSE_VERSION based on the DIST value ?
13:49
cyberorg: make sure it runs after set-dist
13:49
<cyberorg>
vagrantc, where does DIST come from?
13:50
<vagrantc>
cyberorg: the set-dist plugin ...
13:50
<cyberorg>
DIST="$option_dist_value"
13:50
SUSE_VERSION=$DIST
13:50
<vagrantc>
cyberorg: yes, but you duplicate the whole plugin, rather than just the part you need.
13:50
<cyberorg>
so i made it SUSE_VERSION="$option_dist_value"
13:51
user just passes 10.3 or 11.0
13:52
<vagrantc>
cyberorg: right.
13:52
<cyberorg>
i can rename SUSE_VERSION to DIST in my config if you like
13:52
<vagrantc>
on any distro, you should just do ... ltsp-build-client --dist SOME_DISTRO_SPECIFIC_NUMBER_OR_NAME
13:52
<Guaraldo>
vagrantc: Hi...
13:53
<vagrantc>
cyberorg: i just don't see why you've copied the plugin and then added a single line, basically...
13:53
<Guaraldo>
vagrantc: Does LDM save last session chosen to start it again?
13:53
vagrantc: There is any way of it happens?
13:53
<cyberorg>
vagrantc, because i intend to make use of ltsp-build-client --dist 10.3
13:53
<vagrantc>
Guaraldo: no
13:53
cyberorg: then why don't you just use the common plugin?
13:54
<Guaraldo>
Oh!, its no good...
13:54
<vagrantc>
cyberorg: your plugin doesn't add anything, really. except a different variable name.
13:54
<cyberorg>
vagrantc, oh, leave common as it is and add SUSE_VERSION=$DIST in this plugin
13:54
<vagrantc>
cyberorg: exactly. with a different name and make sure it runs after set-dist ...
13:55
<cyberorg>
better to remove it and use it from common and rename the SUSE_VERSION to DIST in config i am using
13:55
<vagrantc>
cyberorg: it'll be a smaller diff for you :)
13:55
<Guaraldo>
vagrantc: how do I can change to use XDMCP? (XDM_SERVER=XXX.XXX.XXX.XXX and SCREEN_07 = startx didn't work)???
13:55
<cyberorg>
vagrantc, you can safely remove that plugin
13:55
<vagrantc>
cyberorg: sure...
13:56
cyberorg: same question about debug, really.
13:56
<cyberorg>
vagrantc, DEBUG is too common a name for variable :)
13:56
<vagrantc>
cyberorg: so let's fix the common plugin :)
13:56
<cyberorg>
but it can be removed too
13:57
LTSP_DEBUG
13:58
<Guaraldo>
vagrantc: How can I use XDMCP instead LDM?
13:58
<vagrantc>
Guaraldo: well, first tear all your hair out, so you don't have to later ...
13:58pascal_2 has joined #ltsp
13:58
<vagrantc>
Guaraldo: and know that local devices and sound support will require lots of configuration ...
13:59
Guaraldo: set SCREEN_07=startx (or in newer versions, SCREEN_07=xdmcp)
13:59tux_440volt has quit IRC
13:59
<vagrantc>
Guaraldo: configure the *DM on the server to accept xdmcp connections
13:59tux_440volt has joined #ltsp
14:00
<vagrantc>
cyberorg: can't you publish bzr branches instead of a diff? ... it would be easier to merge the changes.
14:01
cyberorg: --base ... again ... just changing the name of the variable ...
14:01
<cyberorg>
vagrantc, i intend to work on ltsp-trunk direct soon, for now let me see if i can put bzr checkout on http server here
14:02
<pascal_2>
hello
14:02
hello vagrantc , any news about ldm and pam ?
14:02
<vagrantc>
pascal_2: no
14:02
<cyberorg>
vagrantc, now that you explained, i will change the variable names to be consistent with common plugins
14:03
<vagrantc>
cyberorg: 020-rootpath ... more variable swapping and some commented code ...
14:04
cyberorg: so, that's everything that came up.
14:04
<cyberorg>
vagrantc, as i explained if ROOT exists kiwi will not run
14:04
<vagrantc>
cyberorg: if you push a bzr branch, please make only related changes in a single commit.
14:04
cyberorg: ah, right.
14:05
cyberorg: i.e. one commit per plugin, per variable name change, etc.
14:06pdjbarbe1 has quit IRC
14:08
<cyberorg>
vagrantc, how do i commit locally?
14:08
never mind, i guess, i'll have to check out code from my server to another place
14:10tux_440volt has quit IRC
14:11
<warren>
vagrantc, dberkholz: sorry about that, had to go, was waiting for a hair cut
14:12
vagrantc, dberkholz: idea: provide a shell script that does the equivalent of Xsession on other distros, simply run the desired session if $1 is provided.
14:12
dberkholz, does Xsession on your distro run *other* things before gnome-session for example? on our distro it sets up accessibility and runs ssh-agent, for example.
14:17
brb, much faster this time
14:24chup has quit IRC
14:25chup has joined #ltsp
14:26kushal has joined #ltsp
14:26
<kushal>
warren, hi
14:26
<warren>
kushal, this for a permanent server?
14:27
<kushal>
warren, no, on my desktop
14:27
<warren>
kushal, Fedora 8?
14:27
<kushal>
warren, testing purpose
14:27
warren, rawhide
14:27
<warren>
kushal, ok, there are some new and interesting challenges with rawhide when not permanent
14:27
kushal, desktop or laptop?
14:27
<kushal>
warren, I did upto step 8 in https://fedoraproject.org/wiki/K12Linux/InstallGuide
14:27
warren, desktop'
14:27
<warren>
kushal, ok, you can REALLY simplify things if you turn off NetworkManager and use network instead.
14:28
<kushal>
warren, NetworkManager is off
14:28
<warren>
ok
14:28
good
14:28
kushal, does #9 work?
14:28
<kushal>
warren, what is #9 ?
14:28
<warren>
kushal, step 9?
14:29
<kushal>
oh
14:29
warren, before that, I have a eth0, I want to use that for the network
14:29
<warren>
kushal, you have only one ethernet device?
14:29
<kushal>
warren, yes
14:29
warren, 192.168.1.4
14:29
warren, now how should I configure that
14:30
<warren>
kushal, could you possibly get another ethernet card? it is far less of a pain to test/use LTSP with two cards.
14:30
<kushal>
warren, right now , not possible, will buy a new card tommrow
14:31
warren, it is 1AM here :p
14:31
warren, so now I should do "ifup ltspbr0" ?
14:32
<warren>
kushal, yes, that part is safe
14:32
<kushal>
warren, ok
14:32
<warren>
kushal, that network happens only within your desktop
14:32
kushal, does your desktop have hardware virtualization?
14:32
<kushal>
warren, I don't know
14:33
warren, I want to use my lappy as a client
14:33
<warren>
kushal, the real trouble with trying to use eth0 as the LTSP serving device is you have to manually switch it back if you want to use hte internet
14:33
kushal, and you can easily screw up your network if you accidentally switch it back improperly and serve a dhcp server to it
14:34
<kushal>
warren, I don't want to use that now :)
14:34
warren, I turned my network's dhcp server, now only in static ips
14:34
warren, Starting rpcbind: rpcbind: another rpcbind is already running. Aborting
14:34
warren, I hope that is ok ?
14:34
<warren>
kushal, still, *please* wait until you have another network card. perhaps a USB ethernet if you want extra convenience.
14:35
kushal, service rpcbind restart; service nfs restart
14:35
kushal, I have to update those directions
14:35
<vagrantc>
warren: regarding Xsession ... i know ogra would object to a server-side script ...
14:36
<kushal>
warren, if I reboot, then it should be back in normal condition isn't it
14:36
<vagrantc>
warren: but that could be something for distros to install that don't handle Xsession "normally"
14:36
<warren>
vagrantc, shouldn't bother him, he wouldn't use it
14:36
<kushal>
warren, I will stop the services by myself
14:36
<warren>
kushal, I actually recommend removing the IP from the ethernet device before adding it to a bridge
14:37
<vagrantc>
warren: ah, ok. just a provided script that distros may or may not use ... ?
14:37
<warren>
kushal, explaining how to do this isn't easy, and you would be cut off from the internet
14:37
vagrantc, yes
14:37
vagrantc, what other choice do we have?
14:37
<vagrantc>
warren: sounds good to me.
14:37
<kushal>
warren, I am on my lappy
14:37
<warren>
vagrantc, otherwise Gentoo just has to run the session directly, which might not be bad?
14:37
kushal, laptop has wireless and ethernet?
14:38
kushal, btw, let's figure out if you have hardware virt first, that's a lot easier way to test if the LTSP setup is working.
14:38
<vagrantc>
warren: what about a configuration/build-time option ...
14:38
<kushal>
warren, how to check that ?
14:38
<warren>
vagrantc, which is what we want for the Xsession path anyway...
14:38
<kushal>
warren, desktop is on a Core duo 3.0 Gz system
14:38
<warren>
vagrantc, if we only knew how
14:38
<vagrantc>
warren: sure.
14:39
<warren>
kushal, laptop?
14:39
<vagrantc>
warren: well, it's also server-dependent ... could be information passed via ldminfo
14:39
warren: ldminfod.
14:39
<kushal>
warren, laptop is 1.66, core 2 duo, 2GB RAM
14:39
<warren>
vagrantc, cat /proc/cpuinfo |grep "model name"
14:39
oops
14:40
kushal, , cat /proc/cpuinfo |grep "model name"
14:40
<kushal>
ok, 1.60
14:40
warren, Genuine Intel(R) CPU T2050 @ 1.60GHz
14:40
Genuine Intel(R) CPU T2050 @ 1.60GHz
14:41
warren, for the desktop it is cat /proc/cpuinfo |grep "model name"
14:41
oops
14:41
warren, model name : Intel(R) Pentium(R) D CPU 3.00GHz
14:43
<mnemoc>
wow, 6 lines to answer that
14:44
<pascal_2>
!!
14:44
<ltspbot>
pascal_2: Error: "!" is not a valid command.
14:44
<warren>
kushal, i'm unable to find your processors on intel.com, but I think both lack hardware virt
14:44pascal_2 has quit IRC
14:45
<kushal>
warren, ok :(
14:45
warren, I gave the command ltsp-vmclient on the desktop
14:45
<warren>
kushal, ah, /proc/cpuinfo in the flags, if you have vmx, then you have hardware virt.
14:46
kushal, although some BIOS's turn it off, which sucks.
14:46
kushal, but your model numbers are too old I think
14:46
<kushal>
warren, the qemu started, got the ip, not it is loading pxelinux.0 , very slowly
14:46
warren, let me check
14:46
<warren>
kushal, very slowly means it is working, but wont be usable because qemu is too slow.
14:47
kushal, you could try virtualbox or vmware to attempt PXE boot, if you can figure out how to add their interfaces to the ltspbr0 bridge, I have no idea how.
14:47
<kushal>
warren, ok
14:47
warren, just tell me how can I add the eth0 to that dhcp
14:47
<warren>
kushal, anyway get another ethernet device and this'll be a lot easier to test.
14:47
kushal, brctl addif ltspbr0 eth0
14:48
kushal, brctl delif ltspbr0 eth0 (to undo it)
14:48
<kushal>
warren, ok, cool
14:48
warren, let me try
14:48
<warren>
kushal, weird behavior can happen if you have another IP on eth0!
14:48
kushal, the way I do it is simpler
14:49
kushal, my laptop, I stay online with wireless. I disable NetworkManager's control of eth0, so if I plug in an ethernet device it wont auto-connect.
14:49
kushal, that way I can unplug from a real network, plug in a thin client, brctl addif ltspbr0 eth0, then boot the thin client
14:49
kushal, and remove it from the bridge afterward
14:50
<kushal>
warren, ok
14:50
warren, I will try to buy another card tommorow
14:50
<warren>
vagrantc, I'm not sure I like ldminfod passing it, I'll explore both options.
14:50
<kushal>
tomorrow
14:50
<warren>
kushal, if the ethernet card is gigabit ethernet, you'll have the benefit of auto-negotiation
14:51
<kushal>
warren, ok
14:51
<warren>
kushal, you can plug any ethernet cable between that card and directly into a thin client and it'll just work.
14:51
kushal, otherwise you'll need a hub/switch or a crossover cable
14:51
kushal, my laptop's eth0 is e1000 gigabit so I don't have that problem.
14:51
<kushal>
warren, I have a switch for my home network
14:52
<warren>
kushal, I hope you don't deploy it that way for real =)
14:53* warren wonders if this "bridge by default" LTSP server is a good idea
14:53
<warren>
experienced admins seem to love the idea, but it might be too confusing to normal people.
14:54
<kushal>
warren, to boot from the network, what should I do in my lappy ?
14:55
<warren>
kushal, every BIOS is different
14:55
kushal, F12 works on some Dell and Thinkpads
14:56Gadi has left #ltsp
14:56
<warren>
kushal, some BIOS you need to go into the BIOS menu and turn on network boot
14:56
<kushal>
warren, ok, I am gong to try
14:56
warren, rebooting , will be back
14:57kushal has quit IRC
14:58
<cyberorg>
vagrantc, not sure if this will work, but here it is: http://cyberorg.kicks-ass.org/ltsp/ltsp-trunk/
14:59
<warren>
brb
14:59
<cliebow_>
heh
15:02
<vagrantc>
cyberorg: got your branch :)
15:02
<cyberorg>
vagrantc, cool, if this worked, i don't working like this at all :)
15:03
how do i sync it to bzr head every now and then without conflicts?
15:03
*don't mind
15:05
<vagrantc>
cyberorg: basically, keep a pristine copy of ltsp-trunk and use bzr pull to update it.
15:06
cyberorg: and branch off that whenever you work on a new feature.
15:06
<cyberorg>
http://pastebin.ca/957061 ltsp GUI management GSoC project proposal draft praveer_cool is going to work on this any suggestions welcome :)
15:07kushal has joined #ltsp
15:07
<cyberorg>
vagrantc, ok, next i'll work on getting kiwi scripts and config in there too, so everything is in one place
15:07
<kushal>
warren, I got a TFTP Timeout :(
15:08
<warren>
kushal, brctl show, does this show eth0 on the ltspbr0 bridge?
15:08
<praveer_cool>
Any cool suggestion would be great :-)
15:08
<warren>
kushal, perhaps get some sleep and get another ethernet card tomorrow? much easier to test it
15:08
<kushal>
warren, yes, showing
15:08
warren, I wanna see my lappy booting to F9
15:09
warren, I got the IP , but after that it showed TFTP timedout
15:09
<cyberorg>
it's very late, got to go, 'night
15:10
<praveer_cool>
cyberorg: g nite
15:10
cyberorg: ty for the much needed help
15:10
<kushal>
warren, what next ?
15:13
<warren>
kushal, is iptables blocking it?
15:13
<kushal>
warren, no firewall is up
15:14
warren, anyway how to check that , I want to be sure
15:14
<warren>
kushal, iptables -L
15:14subsume_ has joined #ltsp
15:14subsume_ is now known as subsume
15:15
<warren>
kushal, does eth0 have no IP address at the time?
15:16
kushal, is eth0 actually up? (ifconfig shows it, but with no IP address)
15:16
<kushal>
warren, it is not up
15:16
<warren>
kushal, ifconfig eth0 up (not ifup)
15:16
<kushal>
warren, let me try
15:16
<warren>
kushal, if this doesn't work, get some sleep
15:17
<kushal>
warren, did, but still no ip for eth0
15:17
<warren>
kushal, you want NO IP on eth0
15:17
kushal, but it has to be up
15:17
<kushal>
warren, ok
15:17
warren, so, I should try again ?
15:18
warren, iptables show all accept
15:19
<warren>
kushal, if eth0 is up (without IP) and added to the bridge, make sure ltsp-dhcpd is serving on ltspbr0, and xinetd is also serving.
15:19lns has joined #ltsp
15:19
<kushal>
warren, how to check them ?
15:19
<warren>
kushal, seriously, this is a LOT easier if you have another ethernet card. I can't help you further if this advice doesn't work. I can't hold your hand.
15:19chup has quit IRC
15:19
<kushal>
hehe
15:20
warren, I will buy one tommrow
15:20
<warren>
get some sleep, it is healthier.
15:20chup has joined #ltsp
15:20
<kushal>
warren, ok , will try again after I come back from office tomorrow ..
15:20
warren, see you
15:20
<warren>
k
15:20kushal has quit IRC
15:25* warren thinks that was a RH employee. Not sure.
15:25
<warren>
oh, nope
15:26
vagrantc, are you OK with adding another conditional for SuSE's Xsession location until we figure out how to do it with automake at build time?
15:27
vagrantc, one possibility... BY DEFAULT ldm will run the session directly, unless you specify ./configure --xsession=/path/to/Xsession
15:27
vagrantc, that way we don't favor any particular distro
15:27
<vagrantc>
warren: that seems resonable.
15:27
warren: you know how to make that work?
15:27
<warren>
vagrantc, this also allows ldm to build without error-prone autodetection in the automake... that would be extra complicated to implement.
15:27
vagrantc, yes.
15:28
<vagrantc>
warren: that sounds excellent.
15:28
<warren>
I'll do this today.
15:28cliebow_ has quit IRC
15:28
<vagrantc>
warren: although, i'd keep the full list in in case the default fails ...
15:28* warren trying to fix the TOO MANY LANGUAGES! problem first
15:28
<vagrantc>
i.e. cross distro
15:29
warren: well, i guess just make the automake stuff work, and then i'll patch the cross-distro stuff.
15:29
<warren>
vagrantc, er... if we keep the full list, kind of defeats the purpose.
15:29
doh!
15:29
This sucks
15:30xai has joined #ltsp
15:30
<warren>
vagrantc, ldm looking at the filesystem for the location of Xsession is also possibly flawed, because the real Xsession is on the server, not the client.
15:30
vagrantc, so maybe ldminfod should give it to the client
15:30
vagrantc, do we want to support the client being an entirely different OS from the server?
15:31
doh, I guess ldminfod sending the client the location of Xsession is CORRECT thing to do
15:31
<vagrantc>
warren: no, if we keep the full list, the default will usually get the right one, but only make extra filesystem calls in unusual cases.
15:31
<warren>
vagrantc, this might be the first protocol break
15:31
vagrantc, extra filesystem calls and a full list only works if the client matches the server in Xsession location.
15:32
<vagrantc>
warren: well, no need to break protocol for ldminfod ...
15:32
<warren>
vagrantc, how else do we have ldminfod give the client the location of Xsession?
15:32
<vagrantc>
warren: if ldminfod specifies xsession-file:/path/to/foo , use that, if not, use the default list...
15:32
<warren>
vagrantc, without the Session menu containing "/path/to/Xsession /usr/bin/gnome-session"
15:33
vagrantc, will older clients ignore lines it doesn't understand?
15:33
<vagrantc>
warren: xsession-file-direct: true
15:33
warren: i think so
15:33
<warren>
vagrantc, OK, I suppose we can avoid breaking protocol until we begin supporting l10n
15:33
<vagrantc>
because it's only looking for lines that match language: xsession: rating: ...
15:34
at least, that's how i think it works.
15:34praveer_cool has quit IRC
15:34* vagrantc notes that the format has changed at least once before
15:34praveer_cool has joined #ltsp
15:34
<warren>
next time the format changes, we should version the protocol
15:35
<vagrantc>
i like the FOO: BAR
15:35
<warren>
I didn't suggest changing the format
15:35
<vagrantc>
if we're clever, i think we can avoid breaking protocol without it getting too messy
15:35
<warren>
we'll see
15:35
I suspect l10n will require a break
15:36
older clients wont work
15:36
(which isn't a big deal)
15:36alekibango has joined #ltsp
15:36
<warren>
vagrantc, a11y will be another big problem too
15:36
<vagrantc>
a11y ?
15:36
<warren>
vagrantc, I suspect by the time we need to support a11y, GNOME will just write an ldm equivalet into gdm.
15:36
<vagrantc>
sure hope so.
15:36
<warren>
vagrantc, accessibility support (for blind, low-sight, etc.)
15:36
<vagrantc>
ah.
15:37
<warren>
gdm and GNOME have excellent a11y in most things
15:37
except evolution...
15:37
except firefox...
15:38
LTSP Braille Interface
15:38
=)
15:40twinprism has joined #ltsp
15:41Egyptian[Home] has quit IRC
15:44
<rjune_>
what is a11y /
15:45
<warren>
rjent, any word longer than seven letters needs a number in the middle
15:45
i18n l10n a11y
15:47
<vagrantc>
klausade: oh, sounds like we may have fixed that ugly security bug for LDM even with LDM_DIRECTX ... haven't tested yet, but hope to today
15:47petre has quit IRC
15:49
<klausade>
vagrantc: also for those of us still using the ldm written in python?
15:51
<vagrantc>
klausade: no.
15:51
klausade: actually, i think the version i uploaded to debian-edu probably broke LDM_DIRECTX ...
15:52
klausade: i forgot that debian-edu added that patch, but the version in etch doesn't have LDM_DIRECTX
15:52
<klausade>
vagrantc: yes it did. but the only one that was using ldm_directx was probably me/us.
15:54
<vagrantc>
klausade: well, i can look at backporting it to the version in debian-edu ...
15:55
klausade: but you even use a newer version than that, no? 5.0.8* ?
15:55
<klausade>
vagrantc: i'm stuck in between ... I'll manage on my own, don't worry about that.
15:56
<vagrantc>
klausade: ok.
15:57
<klausade>
vagrantc: I actually have 5.0.40~bzr20080214-1~40.etch.0 working here in test (got the chroot from someone in France)
15:58
<vagrantc>
ah, cool.
15:59chup has quit IRC
15:59chup has joined #ltsp
16:01mhterres has quit IRC
16:03highvolt1ge has quit IRC
16:04mikkel has quit IRC
16:07
<warren>
vagrantc, we seriously need to tag versions
16:08
vagrantc, I realize this is a difficult subject
16:08
vagrantc, I might propose that we begin incrementing 5.1.Y with bzr tags in ltsp-trunk. they are NOT releases, but rather just milestones.
16:09
<xai>
are there docs for compact flash clients?
16:10
<warren>
vagrantc, do you know where in the ldm source it is grabbing from ldminfo?
16:17
<vagrantc>
warren: milestones, hmmm ?
16:17
<warren>
vagrantc, I want to tag version numbers so we aren't stuck at the current versions in ldm-trunk and ltsp-trunk
16:17
vagrantc, but they wouldn't be releases
16:17
vagrantc, I want Fedora 9 to have 5.1.29 for example
16:18
Given that Fedora is putting 100% upstream this isn't too unreasonable
16:18
(numbers Fedora uses matches upstream exactly)
16:18
<vagrantc>
warren: i would rather stick to 5.0, then, starting at .40
16:18
<warren>
vagrantc, ltsp-trunk already has 5.1.0
16:18
vagrantc, and my RPMS already use 5.1.0
16:18
<vagrantc>
warren: never had a 5.1.0 release
16:18
warren: gah.
16:18
<warren>
I can't go backward in numbers
16:19
vagrantc, unless we want to call 5.ODD unstable and 5.EVEN stable
16:19
<vagrantc>
heh.
16:19
<warren>
I'm fine with that.
16:19
<vagrantc>
warren: this is exactly why i never liked putting the version in release.conf
16:20
<warren>
vagrantc, 5.1.0 didn't come from release.confr
16:20
5.1.0 was somewhere else in ltsp-trunk earlier
16:20
<vagrantc>
warren: where did it come from?
16:20
<warren>
I didn't write 5.1.0
16:20
I don't remember
16:20
<vagrantc>
well, i don't like hard-coding version numbers in source.
16:20
for exactly this reason.
16:20
version numbers should come from somewhere else
16:20City_Of has joined #ltsp
16:20City_Of is now known as City
16:20
<warren>
I remember distinctly that I didn't choose 5.1.0
16:21
vagrantc, in any case I personally don't consider what I'm doing until Fedora 10 to be "stable"
16:21
<vagrantc>
i'm not blaming you, i'm just venting frustration at what got us into this mess.
16:21
<warren>
what got us into this mess? Ubuntu not doing any "releases" and instead shipping whatever snapshot he has at the time.
16:22
We have to start a version number system if we're going to become an upstream
16:22
<vagrantc>
because debian and ubuntu have been using 5.0.* for a while now, and when we made a *release* i wanted to start using 5.1 ... but whatever. we are where we are.
16:22
<warren>
It is unacceptable to have distros ship random snapshots
16:22
That's why I'm saying 5.1.0 is NOT a release, it is just a tag
16:22
<vagrantc>
warren: that's not a universal law...
16:23
warren: so what's the difference between a tag that looks an awful lot like a version and a random snapshot ?
16:24
<warren>
vagrantc, how different is debian's current ltsp tree from ltsp-trunk?
16:24* vagrantc wonders how to even get tag support on launchpad
16:24
<warren>
hm
16:24
<vagrantc>
warren: it's based on the ltsp-trunk from 20080319
16:25
warren: hence, the version 5.0.40~bzr20080319
16:25
<warren>
vagrantc, all I know is that when I began working on it, I saw 5.1.0 somewhere in the source tree, so I named my RPMS 5.1.0
16:25
vagrantc, I cannot go backwards
16:26
<vagrantc>
warren: agreed.
16:26
<warren>
I'm asking in #launchpad about --dirstate-tags
16:26
vagrantc, I can't find where in ldminfo it grabs from ldminfod, I might be blind, do you know?
16:27
<vagrantc>
warren: as someone vested in Debian's interests, i do not feel comfortable making a release as upstream. i do not feel comfortable other distros pressing their agenda, either. even if you don't call it a release, that doesn't change the fact that it's basically a release.
16:28
i do find snapshots as acceptible, though undesireable, for debian.
16:28
<warren>
vagrantc, you aren't uncomfortable with Fedora's (and soon SuSE) RPMS being named 5.1.0 when you have 5.0.40?
16:28
it is an unfortunate accident that this happened, but now what do we do?
16:28
<vagrantc>
warren: well, i can always bump the version number on my next upload ...
16:29
<warren>
vagrantc, how do we decide "this is the real 5.1.0"?
16:29
OH!
16:29
duh
16:30
<vagrantc>
i don't really know.
16:30
<warren>
grabbing ldminfod happens in screen.d/ldm
16:30
<vagrantc>
i've been asking for releases for close to 2 years now.
16:30
<warren>
Given the lack of willingness here, I'm suggesting the admittedly imperfect idea of simply tagging and incrementing numbers.
16:31
We might discover that 5.1.27 is a good number and call it a release.
16:31
<vagrantc>
warren: since most of the development has fallen to the distros, i think we should move towards getting some sort of cross-distro agreement on when to call something released.
16:31
<warren>
vagrantc, requiring cross-distro agreement is a great way to never get anything done
16:31
<vagrantc>
heh.
16:32
<warren>
vagrantc, I'm suggesting tagging and incrementing at arbitrary times, and if a number of people like it call it a release.
16:32
<vagrantc>
warren: why not make the arbitrary time ... a date ? :P
16:32
<warren>
vagrantc, Fedora is using 5.1.27. Gentoo is using 5.1.30, which is no different from 5.1.27 but with Gentoo improvements.
16:32
<vagrantc>
here's an idea ...
16:33
<warren>
vagrantc, I might even suggest time-based releases, but we clearly aren't ready for that yet.
16:33
<vagrantc>
warren: so, basically what you said, except the version gets incremented when *any* distro makes a release.
16:33
<warren>
vagrantc, that's fine with me!
16:33
vagrantc, release being a new build pushed...
16:33
<vagrantc>
well ...
16:33
<warren>
vagrantc, multiple distros might agree "I like what's there now, let's all push together."
16:34
vagrantc, I might temporarily push upstream 5.1.27 + temporary fedora branch, but 5.1.42 the fedora delta disappeared.
16:35
<vagrantc>
warren: i don't quite get you ...
16:36City has quit IRC
16:36
<warren>
vagrantc, I like the idea of tagging whenever a distro does a release
16:36
vagrantc, effectively arbitrary tagging even if it isn't ready for other people is fine by me.
16:37
<vagrantc>
warren: it keeps it fairly clear ...
16:37
<warren>
None of these tags are "official upstream"
16:37
sometime later we might decide "hey things are looking pretty good, let's publicize 5.2.0"
16:37
which is really no different
16:37
<vagrantc>
right.
16:38
<warren>
I'd like to target 5.2.0 for Fedora 10
16:38
which is likely a very similar schedule to Ubuntu
16:38
<vagrantc>
5.1 is basically the "finally we have more distros" branch.
16:38
5.2 can be the "finally, it actually works with more distros" branch.
16:39
<warren>
heh
16:39
I like this.
16:39slidesinger has quit IRC
16:39
<warren>
vagrantc, now how do we number ldm and ltspfs?
16:39
<vagrantc>
heh.
16:39
ltspfs has actually not been changing much.
16:40
<warren>
I haven't even tested it on Fedora yet
16:40
I wonder if setuid on the fuse binary is all I need
16:40* warren tests it now
16:40
<vagrantc>
currently, 0.5.0~bzr20080303 is the version in debian and ubuntu
16:40
and before that, it was 0.5 and 0.5+debian
16:40
warren: could just do the same thing ... increment it whenever a distro releases with it.
16:41
warren: ldm is arguably 2.0.0 ...
16:41
although debian and ubuntu have 5.0.* versions of it laying around, from when it was just part of the ltsp sources
16:42
but i think 2.0.0 is probably a good starting point for ldm, and increment whenever a distro releases.
16:42
this is the only way i think hard-coding it makes much sense.
16:42
<warren>
configure.ac of ldm currently has 0.1
16:43
<vagrantc>
warren: any word on tagging support from launchpad
16:43
<warren>
vagrantc, waiting for response
16:43
<vagrantc>
warren: current ldm is basically the second generation of ldm's
16:43
warren: so i think it warrants a 2.0.0 version ...
16:43chup has quit IRC
16:44chup has joined #ltsp
16:44
<vagrantc>
debian has a (somewhat ugly) way of handling when upstream changes versioning conventions... which i'm already doing for ldm in debian.
16:45
<warren>
vagrantc, ok, how about 2.0.Y for current ldm. 2.1.Y if the protocol must change in a way that breaks old clients.
16:45
<vagrantc>
warren: sounds reasonable.
16:45
<warren>
vagrantc, if 2.1.Y happens we can have a ldm-2.0 branch for further development on the old version.
16:45
vagrantc, btw, I think we need to move ldminfod into ldm. Why? Because there's no reason a server cannot have only ldminfod without ltsp-server, in the case of server clusters.
16:46
vagrantc, ltsp-server's primary purpose is to create bootable chroots right?
16:46
<vagrantc>
warren: i agree.
16:46
warren: ogra's resisted that move for quite some time.
16:46
<warren>
well ogra quit?
16:46
=)
16:46
<vagrantc>
warren: create and host
16:46
warren: i don't accept the resignation :)
16:46
<warren>
me neither
16:46
=)
16:47
vagrantc, I don't think we're ready for 2.1.Y yet, so I'm OK without moving ldminfod yet.
16:47
I know he dislikes the idea of ldm-server subpackage but I think we need it.
16:47
There's no reason why ldminfod need to be tied to ltsp-server.
16:48
vagrantc, ltsp-server ... create and host BOOTING of clients
16:48
if you are doing neither you don't need ltsp-server
16:48
<vagrantc>
warren: agreed. i've been saying that for years.
16:48
<warren>
ltspfs is 0.4.2
16:49
Let's call it 0.4.3 and do a release?
16:49
<vagrantc>
warren: in debian and ubuntu it's been 0.5* for some time.
16:49
<warren>
grr
16:49
<vagrantc>
warren: i say we call it 0.5.X ...
16:49
<warren>
what number should we start at?
16:50
<vagrantc>
warren: so, while it sounds like we (mostly) have a consensus of two ... might be good to run this idea by the list.
16:50
<warren>
God I love having a second laptop to do LTSP testing. http://wtogami.livejournal.com/ Only needed to go at it with a chisel and hammer to fix it.
16:50
vagrantc, yes I'm writing all this down
16:51
<vagrantc>
warren: i also conceed to using bzr to generate a changelog
16:52
warren: something is better than nothing, which is all we have right now.
16:52
<warren>
vagrantc, I would be OK with that only on projects that started with a fresh history
16:52
<vagrantc>
hrm.
16:53
<warren>
vagrantc, I hate that ldm is so heavy because it didn't start fresh. ltspfs is very light.
16:53
<vagrantc>
might generate it for debian anyways.
16:54
warren: i also like this idea because it's not really dependent on tagging ... we can actually just increment the version in bzr when we make a release.
16:54
warren: though tagging would be idea.
16:54
ideal
16:55
<warren>
vagrantc, what version of bzr does Debian have?
16:55
vagrantc, upgrading our repos to have --dirstate-tags support will require a certain minimum version
16:56Egyptian[Home] has joined #ltsp
16:56
<warren>
vagrantc, everyone needs a minimum of bzr-0.15
16:56
<vagrantc>
warren: i've been using 1.0 mostly
16:57
there was a huge leap from 0.teens to 0.nineties
16:57
warren: i don't think that minimum is unreasonable.
16:58gonzaloaf has joined #ltsp
16:58
<warren>
vagrantc, if we're willing to require an even newer version, it appears that we can get more performance and space savings.
16:59
vagrantc, it really isn't unreasonable to me to go with the latest format version. LTSP developers are rare enough.
17:01
vagrantc, oh interesting
17:01
vagrantc, we're already using dirstate which requires 0.15
17:01
<vagrantc>
warren: as long as it's supported in 1.0, i'm fine.
17:01
<warren>
vagrantc, yeah, 1.0 is the latest format
17:01
<vagrantc>
warren: i think that's a reasonable minimum, it being the bzr "stable" release.
17:01
<warren>
ok
17:01
good
17:02
<vagrantc>
and i sure hope bzr stops switching formats.
17:02
<warren>
as long as I get tags I'm happy
17:02
<vagrantc>
sometimes i've felt like my vcs changes more than the code i'm committing to it.
17:02
<warren>
vagrantc, oh, I'll guarantee that your code is changing faster. =)
17:02
<vagrantc>
and that's just wrong.
17:02
anyways...
17:03
warren: during the 0.8-0.92 times ... it pretty much changed default format almost every release.
17:03
<warren>
=)
17:04chup has quit IRC
17:04
<vagrantc>
warren: i'm finally testing your LDM_DIRECTX + xauth stuff
17:04
<warren>
vagrantc, it sucks but works
17:04chup has joined #ltsp
17:06
<vagrantc>
wahooo!
17:06
warren: works like a charm. :)
17:07
<warren>
ack, bzr-1.3 is out
17:07
i'm using 1.1 ancient
17:09* vagrantc wonders why bzr even has releases
17:10Guaraldo has quit IRC
17:10
<warren>
vagrantc, it should be only snapshots you mean? =)
17:12Al-Khouli has joined #ltsp
17:12
<vagrantc>
warren: they should require people to only use the latest bzr from the latest bzr branch of itself
17:12
warren: should error out of your bzr branch isn't updated
17:15
<warren>
vagrantc, I agree
17:15
vagrantc, ironically Gutsy doesn't even have 0.92 yet
17:16
launchpad itself is using 1.2 https://code.launchpad.net/
17:17
<laga>
vagrantc: yeah, and if your bzr is out of date you won't even be able to bzr up for their bzr branch ;)
17:18
<Lumiere>
warren: I think the more ironic thing is python is moving to bzr
17:18
<warren>
Lumiere, heh
17:19
<Lumiere>
so how does one
17:19
get python working?
17:19
<warren>
THAT'S why you need tarball releases
17:19
<Lumiere>
warren: or buildout
17:19
I guess
17:34chup has quit IRC
17:35chup has joined #ltsp
17:50gonzaloaf has quit IRC
17:51gonzaloaf has joined #ltsp
17:52
<dberkholz>
warren: nope, we're using something quite similar to (but not exactly, for some odd reason) the upstream Xsession provided by xdm. doesn't do anything fancy.
17:54bobby_C has quit IRC
17:56
<warren>
dberkholz, how does it decide which session is default?
17:56
dberkholz, (if you login with name and password, what happens?)
17:56
<dberkholz>
that probably depends on which *dm you're using. they seem to all do their own things because xdm/xinit upstream sucked
17:57
<warren>
that's why everyone else replaced the upstream =)
17:57
<dberkholz>
yes, well it's about time to merge changes back in because it doesn't suck anymore =)
17:57
if i'm using gdm, i'll get gnome. if i'm using kdm, i'll get kde.
17:58
<warren>
uh
17:58
dberkholz, I guess for ldm you'd want a script that runs your Xsession if no other session is chosen, or something else if $1 isn't blank.
17:59
<dberkholz>
warren: well, i don't know if you saw this earlier -- i was talking about trying to merge these files better instead of doing all these gentoo-specific hacks
17:59
i don't want to be in this position where we're doing something totally weird compared to everyone else with nonstandard configuration
17:59
<warren>
dberkholz, oh, you don't need to support older gentoo?
18:00* warren has on idea how Gentoo is supported.
18:00
<dberkholz>
no such thing really since there are no releases as such, we just tell people to sync their tree
18:00
<warren>
wow
18:01
And I thought Fedora was reckless
18:01
=)
18:01
<dberkholz>
it's basically like running a somewhat stabler rawhide
18:01* vagrantc is busy hacking in compatibility for lenny's ltsp that may not make it before ldm does ...
18:01
<dberkholz>
if they want ltsp, they automatically pull in whatever dependencies it requires
18:01
they can choose to only do other security updates, but there is no concept of backports.
18:01
<warren>
dberkholz, well, rawhide is fluctuating in stability...
18:02
vagrantc, what is that?
18:03manuel_schulte has joined #ltsp
18:03
<dberkholz>
people keep talking about doing some work for enterprises, branching off trees and such, but it just isn't fun, so volunteers aren't real into it.
18:03
plus cvs sucks
18:03
once we move to git, that'll help
18:05
<warren>
I personally don't understand how Gentoo could be supportable for enterprises.
18:06
<dberkholz>
warren: you'd take the same snapshot used for releases, branch it off, start doing backports, and optionally distribute prebuilt binaries (which gentoo can in fact do decently)
18:08
<warren>
dberkholz, btw, any objections to minimum bzr version of 1.0 to work on LTSP?
18:08
<dberkholz>
i've got 1.3, so that sounds fine
18:08
require 1.3 for all i care =D
18:08
<warren>
I'm going to propose that pack-0.92 format is the minimum
18:09
<dberkholz>
you will probably never find me opposed to depending on newer things
18:09
<warren>
dberkholz, hmm, we might get a long well =)
18:10
<dberkholz>
i generally favor forward progress over backwards compatibility
18:10
<warren>
horray
18:10
<dberkholz>
some folks at gentoo don't agree with that, so we have some fun discussions
18:12
<warren>
dberkholz, any objection to the version number tagging idea between me and vagrantc?
18:12
dberkholz, basically, version numbers upstream are not releases, only tags. Increment and tagging can happen when any distro feels like doing it.
18:12
<dberkholz>
warren: what's the distinction between a release and a tag -- a tarball?
18:13
<warren>
dberkholz, no
18:13
dberkholz, distinction tag != release is because we can't all agree when to release.
18:13* dberkholz grins
18:13
<warren>
dberkholz, so if you are building into your distro, you might increment and tag ltsp-5.1.27 at that moment.
18:14
dberkholz, the next day I might use your tag if I like it, otherwise I might add something and call it ltsp-5.1.28.
18:14
<dberkholz>
i think that could produce a somewhat confusing situation where we don't know what numbers work where
18:14
<warren>
dberkholz, OTOH, we can easily say "foo was fixed in 5.1.27. Oh, I'm using 5.1.24, I better upgrade.'
18:15
<dberkholz>
this seems like it's working around the belief that everyone needs to agree for it to be a release
18:15
<warren>
dberkholz, you might be using 5.1.27, Fedora might be using 5.1.30, which has no changes that affect Gentoo.
18:15
<dberkholz>
just call it a release and say anyone can do 'em
18:15
<warren>
dberkholz, the culture here is a bit twisted and stupid after years of Ubuntu never doing releases or tags. We need to get people used to this, then I think we can eventually agree upon actual releases.
18:16
<dberkholz>
i'm sure you've seen me say before that i agree on making actual releases
18:16
<warren>
dberkholz, I rather not call them releases if anybody can do it... that isn't encouraging good release engineering.
18:16
<vagrantc>
warren: well, the ltsp in lenny doesn't have the screen-x-common code, so i'm temporarily copying it into ldm and patching ldm's screen script to support both locations
18:17
<dberkholz>
it seems like semantics to me
18:17
<warren>
vagrantc, ah
18:17
<dberkholz>
change anybody to "any distro coordinator" and then you've got something like 5 people
18:17
presumably they can manage to talk to each other
18:18
<warren>
dberkholz, you *have* seen what happened between Ogra and that asshat on the list right? =)
18:18
<dberkholz>
warren: rumors only, i'm not on the list
18:19
<warren>
dberkholz, I propose this plan because it sounds not so different from today, meanwhile I can sneakily introduce the concept of "releases" to this backwards society.
18:19
<dberkholz>
seen that kind of thing a hundred times, though, so nothing new
18:19
<warren>
dberkholz, and it just so happens that you, vagrantc and I will likely agree "yeah, time for another tag"
18:19
<vagrantc>
dberkholz: i agree that it's basically giving a release a different name
18:19
<warren>
shhh, this isn't releases
18:19
wink wink
18:20
<jcastro>
warren for release manager!
18:20
<warren>
oh god
18:20
being release manager means everyone bitches and whines at you
18:20
<jcastro>
yeah but then you can say "No" to stuff
18:20
<warren>
I shouldn't be the gatekeeper
18:21
vagrantc is a lot more sane than me.
18:21
<vagrantc>
while i'd like to see real releases, i'm thinking this could be the incremental development between major releases.
18:21
<dberkholz>
the idea seems fine with an accompanying suggestion that you coordinate with other people
18:21
<jcastro>
warren/vagrantc for release team!
18:21
<dberkholz>
instead of just tagging, say "hey i want to tag soon -- thoughts?"
18:21
<warren>
dberkholz, as long as there's no requirement to have agreement before tagging
18:21
<vagrantc>
i just don't want ubuntu or fedora's release cycle interfering with my work.
18:21
<warren>
dberkholz, because really, we have unlimited numbers
18:21
<dberkholz>
that's why i said suggestion
18:22
<warren>
5.1.3642672342 is awesome.
18:22
<dberkholz>
eww.
18:22
<vagrantc>
and i think this allows for autonomy while still moving forward in a sane manner
18:22
<dberkholz>
dates, please
18:22
<warren>
dberkholz, numbers wont get that high
18:22
dberkholz, at some point we'll realize "wow, this is looking pretty good and we have 7 distros integrated upstream, time to call it 5.2.0"
18:22
<vagrantc>
hmmm...
18:22
<dberkholz>
5.1.200803251621 does get a little wacky, though
18:23
<vagrantc>
well, we could leave out the hours and minutes
18:23
<dberkholz>
then you've gotta wait till the next day for a bugfix, or pretend it's the next day anyway
18:23
<vagrantc>
i still think just incrementals.
18:24
<warren>
#bzr said there's no benefits of rich-root over -pack-92 which is the default.
18:24
So we'll go with pack-92
18:24
dberkholz, I'm currently using dates in a smaller package field than version
18:24
dberkholz, I'm sick of it
18:25
dberkholz, agree with this in principle, with it understood as a transition to real releases later?
18:25
<dberkholz>
sure. just needs someone to write up a release howto on the wiki
18:25
er, tag. =P
18:25
<warren>
nod
18:25* vagrantc reserves the right to call it a release in debian/changelog
18:26
<dberkholz>
xorg has a nice page for that
18:26
http://wiki.x.org/wiki/Development/Documentation/ReleaseHOWTO
18:26
<warren>
vagrantc, me too =)
18:26
<vagrantc>
let's just call them releases. :)
18:27
<warren>
how about these are releases, while future things that we agree upon are "official releases"
18:27
<dberkholz>
i liked the previous distinction better
18:27
<warren>
that seems a little confusing though
18:27
tag vs release
18:27
version number vs release which is an awesome version njob
18:27
err
18:28
version number
18:28
<dberkholz>
the other option of course is to just start off doing real releases from the start
18:28
<warren>
vagrantc, ah, here's a key question
18:28
<dberkholz>
hand off release manager roles to the person who needs the next release
18:28
<warren>
vagrantc, do we have the tag include name or not?
18:28
vagrantc, "5.1.0" vs. "ltsp-5.1.0"?
18:29
dberkholz, trouble with calling it a real release is that the stuff upstream likely wont work for anybody but the current distros
18:29
<dberkholz>
and?
18:29
<warren>
dberkholz, I'd like to call something a release only after we have lots of cross-distro upstreamed and testing
18:29
<dberkholz>
release early..
18:29
<warren>
gah!!
18:30
I know
18:30subsume has quit IRC
18:30
<warren>
God Ubuntu has twisted my mind to be afraid of calling it a release.
18:30xai has left #ltsp
18:30* warren shakes fist at jcastro.
18:30
<dberkholz>
my analogy is that new distro support in ltsp is analogous to new features in other packages
18:31
<warren>
dberkholz, how about upstream doesn't bother providing tarballs unless we do an "official release"
18:31
<dberkholz>
two different distros should be enough for a release, to say that at least the setup is reasonable
18:31
<warren>
dberkholz, it is easy enough to build a tarball directly from a tag
18:31
<dberkholz>
warren: i would really like upstream tarballs to use
18:31
<warren>
dberkholz, have you tried mkdst?
18:31
<dberkholz>
could just put them somewhere different
18:31
<warren>
dberkholz, you could add an ebuild option to mkdst.
18:32
<vagrantc>
warren: i would prefer the release not contain the name of the project, as it just seems redundant.,
18:32
<warren>
dberkholz, change something in your ltsp-trunk checkout, and ebuild it instantly in-place.
18:32
vagrantc, tag you mean?
18:32
<vagrantc>
warren: but i guess if you split something into a separate sub-project, it would need that...
18:32
warren: yes.
18:32
<dberkholz>
warren: well, ebuilds are just distributed as scripts and the source tarball is downloaded from mirrors
18:32
<warren>
vagrantc, hypothetical example of sub-project?
18:32
<dberkholz>
warren: so we like to have a source for the source, as it were
18:33
rather than me arbitrarily generating one that may be different from one generated by anyone else from the same tag
18:33
<warren>
dberkholz, I mean... mkdst ebuild would be for YOU to quickly test it.
18:33
<vagrantc>
warren: i.e. splitting jetpipe (local printer support) into it's own project ... which is more than hypothetical, sbalneav has already worked on it
18:33
<warren>
dberkholz, not to push it to the distro
18:33
<dberkholz>
warren: oh. we support live bzr builds..
18:33
<warren>
dberkholz, I'm able to rapidly test stuff on my laptop from a ltsp-trunk tree without checking in or building tarballs with "mkdst rpm"
18:33
oh
18:33
<dberkholz>
didn't understand what you were getting at =)
18:34
<warren>
vagrantc, mmm... mkdst already adds the name-version as the tag.
18:34
<vagrantc>
dberkholz: if you wanted pristine tarballs, maybe consider pristine-tar: http://packages.debian.org/pristine-tar
18:34
<dberkholz>
vagrantc: yeah i've been following the vcs-pkg stuff fairly close lately
18:34
<vagrantc>
dberkholz: more than i have, i guess. :)
18:34
warren: ok.
18:34
warren: then lets go with that.
18:35
<warren>
vagrantc, and the sub-project thing pretty much makes this weird if we don't include name in tags.
18:35tessier__ has quit IRC
18:36
<vagrantc>
warren: yeah. sounds fine. just as long as this doesn't break "mkdst debtar" ... i'll want an equivalent of that.
18:36
<warren>
vagrantc, are these version numbers good for starting?
18:36
ltsp-5.1.1
18:36
ldm-2.0.0
18:36
ltspfs-0.5.0
18:36
<vagrantc>
warren: it's good by me.
18:36
<warren>
vagrantc, did you make debtar --from-tag=FOO work?
18:36
I have to add bug fixes to mkdst and do a 0.8 release soon
18:36
<vagrantc>
warren: probably not.
18:36
<warren>
vagrantc, should be easy to implement
18:37
<vagrantc>
warren: i also wanted to add a feature which seems like it will soon be irrelevent ...
18:37
<warren>
oh?
18:37
<vagrantc>
i wanted to so something like "--release-date ~bzr" to append ~bzr$(date +%Y%m%d) to the version
18:37
<warren>
vagrantc, ah, --from-tag=FOO looks like it should already work with debtar
18:38
<vagrantc>
warren: ah, cool.
18:38
<warren>
vagrantc, but no longer?
18:38
<vagrantc>
warren: it's mainly just the name of the tarball that gets mangled... everything else should be the same.
18:38
<warren>
yeah
18:38
this is fine
18:38
<vagrantc>
warren: well, maybe that's still useful ... but my primary desire for it is because we don't have a sane versioning.
18:39
and it sounds like we're moving in a good direction with sane(r) versioninng.
18:41
<warren>
vagrantc, dberkholz: let's agree on some kind of a loose rule about tagging. TELL EVERYONE IN IRC before you do it. There might be somebody else that replies, "Wait! I have a fix coming in 15 minutes."
18:42
<dberkholz>
warren: might be nicer to have a list of people to ping
18:42
for some reason i don't check all my active windows that often
18:42
<warren>
dberkholz, we'll just kind of know based upon who does work...
18:42
<vagrantc>
sounds good, with dberkholz's recommendation.
18:42
<warren>
but yeah
18:42
and this isn't a requirement
18:42
but it makes it easier to collaborate
18:42
<vagrantc>
it's a good courtesy.
18:42
<warren>
yeah, just a courtesy
18:42
<dberkholz>
who does work, eh.
18:42
<warren>
and avoids needless conflicts
18:43
<dberkholz>
where's johnny when i need him
18:43
<vagrantc>
warren: probably with a suggested deadline of ... 15 ... 30 minutes ?
18:43F-GT has quit IRC
18:43
<vagrantc>
1 hour?
18:43
<warren>
vagrantc, don't suggest anything, this isn't a requirement
18:43
vagrantc, just if you're being nice to other contributors you want to avoid causing them conflicts.
18:44
<vagrantc>
warren: pinging someone and then releasing in 1 minute kind of defeats the purpose.
18:44
<warren>
well, if you're working on something you'll likely know a while before you have something to push
18:44
<vagrantc>
like, when i'm most actively working, i'm often not actually paying attention to irc.
18:44
<warren>
because you SHOULD be testing it before pushing =)
18:44
<vagrantc>
indeed.
18:44
<warren>
1) Fix something 2) Hey folks I have something to push soon. 3) TEST IT 4) Push
18:44
<vagrantc>
yeah.
18:44
<dberkholz>
well, if tagging is that low cost it shouldn't actually be a problem to even do it multiple times in a day
18:45
<vagrantc>
that sounds like a good route.
18:45
<warren>
dberkholz, yes
18:45
<vagrantc>
indeed.
18:45
<dberkholz>
so if you don't notice in time, oh well, new tag
18:45F-GT has joined #ltsp
18:45
<vagrantc>
sure. though i do want to avoid 5.1.100000
18:46
i.e. try to keep an eye out for needless tagging.
18:46
<dberkholz>
like warren was saying, it doesn't really matter if we get up in the hundreds or thousands. it's just an arbitrary number
18:46
<warren>
vagrantc, I suspect the rightmost number will be larger for the 5.1.x cycle, and smaller in the future.
18:46
<vagrantc>
but it's ugly.
18:47
when my users report that they're using 5.1.45462 because they displayed it on a small column, and i know that 5.1.454625789 is where it's at ...
18:47
<warren>
vagrantc, then it is time for 5.2
18:47
<vagrantc>
it's hard enough to not get reports for 5-something.
18:47
<dberkholz>
are they using 10-character terminals? =)
18:47
<warren>
hah
18:48TelnetManta has joined #ltsp
18:49
<vagrantc>
yes, when the number starts getting high, well, we should hopefully be considering moving to the next phase of versions ...
18:49gonzaloaf has quit IRC
18:49
<dberkholz>
i'd rather see more people getting bugfixes sooner than see us trying not to release to avoid bumping the version
18:49
<vagrantc>
alternately, we could say 5.1.99 +1 = 5.2.0
18:50
but i'd prefer that the 5.x numbers are actually conscious releases.
18:50
<warren>
vagrantc, if we're doing a good job, we might get to 5.2.0 before 5.1.99
18:50
<dberkholz>
me too
18:50
<vagrantc>
but that would be a relatively simple proposal to programmatically avoid the number getting crazy.
18:50
although i guess the second number might start to go crazy.
18:51
the hope is we actually start to stabalize the code :)
18:51
<warren>
My guess is that we will reach past 5.1.200 but not 5.1.300
18:51
wild guess =)
18:51
vagrantc, dberkholz: how do you like the idea of 5.1.x being unstable and 5.2.x stable?
18:51* vagrantc hands warren an extra WHEREBY
18:51
<warren>
or maybe
18:52
hmm
18:52
no
18:52
bad idea
18:52
we seriously don't have enough manpower to maintain two parallel branches
18:52
<dberkholz>
nah, i'd just add a 4th number for a stable branch if someone cares enough to maintain one
18:52
2.6 kernel style
18:52
<warren>
look at the stagnation during kernel-2.4 and kernel-2.5
18:52
<vagrantc>
dberkholz: indeed.
18:53
<warren>
dberkholz, good idea.
18:53
<dberkholz>
my head is full of other people's good ideas
18:53
<vagrantc>
warren: the really cool thing about bzr repository formats ... the name used in .bzr is different from the name used on the commandline.
18:54
so i can never figure out what format a repository actually is.
18:54gonzaloaf has joined #ltsp
18:54
<warren>
vagrantc, bzr info?
18:54
<vagrantc>
Repository tree (format: unnamed)
18:54
awesome.
18:54
<warren>
?
18:54
[warren@newcaprica ltsp-trunk]$ bzr info
18:54
Standalone tree (format: dirstate)
18:55
<vagrantc>
looks like my shared revision repository is pack-0.92
18:55
but my branches actually say unnamed
18:56
and this one: Shared repository with trees (format: dirstate or dirstate-tags or knit)
18:57
i just don't get it.
18:58
<warren>
vagrantc, upgrade your bzr maybe?
18:58
you are using ancient 1.0!
18:58
=)
18:58staffencasa has quit IRC
18:58
<vagrantc>
yeah, release like two months ago
18:59
<warren>
in Fedora time that's ancient
19:00nsar has joined #ltsp
19:01
<nsar>
hello
19:02
when i am trying to install local apps on ltsp 4.2u2 it's complaining avout libc-6 and when i put it it will complain about a tls security library but it require also glibc-2.5 i am using fc6
19:05
<warren>
vagrantc, does it bother you if tags like ltsp-5.1.27.fedora17 appear in ltsp-trunk's tags?
19:05
vagrantc, (that would mean that I pulled from ltsp-fedora and eliminated the delta)
19:08
<vagrantc>
warren: they don't bother me, but i don't quite understand it.
19:09
seems like it sort of defeates the purpose of the new incrementing versionsm thing
19:09
<warren>
vagrantc, I might do tags outside of upstream until I've stabilized something, then I push it back into upstream, by that point it might be 5.1.33 or something
19:10
vagrantc, ltsp-5.1.27.fedora17 denotes clearly that a feature was worked on 5.1.27 as a base.
19:10
maybe I'll never use this, but just wondering if it would upset anyone
19:10
<dberkholz>
would they have any upstream purpose?
19:11
<vagrantc>
probably not upstream, but it would just get pulled in when the merge happens.
19:11
<warren>
well, no, but if you're pulling from side-repositories where new features were developed it is difficult to avoid inheriting its tags as well.
19:11
<dberkholz>
i mainly use git, not entirely clear on bzr features
19:11
<vagrantc>
warren: i'm fine with it.
19:11chup has quit IRC
19:11
<warren>
If you look at any other upstream project that uses a distributed SCM you see all kinds of other tags get imported
19:11
<dberkholz>
if it's just the way it happens, don't really care
19:11
<vagrantc>
i'm really unfamiliar with tagging in bzr ... it's a newish feature.
19:11
<warren>
as long as they don't collide with upstream's tag names it should be fine.
19:11
<dberkholz>
is there any kind of hierarchy possible?
19:11chup has joined #ltsp
19:12
<vagrantc>
a tag is just a specific list of revisions
19:12
<warren>
dberkholz, you can give a tag any name at all
19:12
we can only tell people "don't use stupid names"
19:12
<dberkholz>
how about fedora/5.1.27.fedora17
19:12
<warren>
and we CAN forcefully delete stupid tags from the upstream repo, but we rather avoid that.
19:12
<dberkholz>
or whatever. you get the idea
19:13
<warren>
dberkholz, that would require special casing code that handles VERSION
19:13
possible but I'd like to avoid it
19:13
dberkholz, the thing is fedora could be any string
19:13
5.1.27.newfeature17
19:13
5.1.33.supernewfeature4
19:13
<dberkholz>
i'm not really even sure why the version number is part of that
19:13
any decent history browser should show where it branched off
19:13
<warren>
because tags are unique points in time
19:14
If your feature is sufficiently complicated you might want to have tags within it
19:14
I guess most people wont bother
19:14
dberkholz, ah, here's another key reason
19:14
<dberkholz>
that implies that you're actually releasing from a branch, doesn't it?
19:14
that would produce some version conflicts
19:14
<warren>
dberkholz, 5.1.33.awesomefeature4.tar.bz2 is on my website for an experimental feature for people to try.
19:15
dberkholz, making that tarball I would use the standard tools, not anything manual
19:15
ltsp-5.1.33.awesomefeature4-1.fc8.src.rpm
19:16
These non-upstream tags would only appear in upstream trunk if they are pulled.
19:16
which wont be often
19:22
<vagrantc>
tags don't come across in merges?
19:23
<warren>
?
19:23
<vagrantc>
"... only appear in upstream trunk if they are pulled." ?
19:24
<warren>
vagrantc, I don't know actually, asking upstream
19:27
<vagrantc>
warren: where's bzr irc channel?
19:27
<warren>
vagrantc, #bzr?
19:27
seems active
19:28nsar has quit IRC
19:41DonSilver has quit IRC
19:53jammcq has quit IRC
19:55jblack has left #ltsp
20:10hari_ has joined #ltsp
20:11hari_ has quit IRC
20:12manuel_schulte has left #ltsp
20:14chup has quit IRC
20:14chup has joined #ltsp
20:22hari_ has joined #ltsp
20:24
<hari_>
hi... i'm using ltsp on ubugntu gutsy. does anyone has experience doing multiplayer game in ltsp? how is it in ltsp. thx
20:29
<vagrantc>
warren: good job on the versioning proposal!
20:29
<warren>
oh
20:29
ok
20:29
=)
20:34otavio has quit IRC
20:41* warren fixed the TOO MANY LANGUAGES! problem
20:41* warren testing
20:41
<vagrantc>
warren: how?
20:42
<warren>
vagrantc, just increase the buffer size from 4096 bytes to 4 times as large.
20:42
vagrantc, should last Fedora's language growth for another year or so...
20:42
=)
20:42
<vagrantc>
heh
20:42
<warren>
vagrantc, maybe I should make it larger just in case the new protocol has to transmit a ton of crap... (localized strings?)
20:43
vagrantc, well, in that case we likely need to just allocate on demand instead of a fixed buffer.
20:43
yeah... will allocate on demand later if needed
20:43
I just need it to WORK now
20:44
vagrantc, highly likely after Fedora 9 our gdm guy will find a way to import the functionaly into gdm real quick.
20:44* warren hints mccann
20:46
<vagrantc>
warren: i don't want to loose the flexibility of the rc.d stuff
20:47
<warren>
vagrantc, we would have to implement something similar
20:47
vagrantc, the thing is, the amount of work necessary to l10nize and a11yize ldm might be so huge that it is likely less work to make gdm do it.
20:48
vagrantc, we can't sell ldm in a product to the US government if it doesn't have a11y... disabled persons law related.
20:49
vagrantc, now how useful LTSP is to blind people, I'm not sure.
20:54
wow
20:54
hm
20:55
-#define MAXBUFSIZE 4096
20:55
+#define MAXBUFSIZE 16384
20:55
and now X wont start
20:57
something else must be wrong...
21:01
crap
21:01
vagrantc, this might be your last minute bug
21:02Al-Khouli has quit IRC
21:06hari_ has left #ltsp
21:08
<warren>
yeah, it was your ltsp_config boolean bug
21:08
sigh
21:10
<vagrantc>
warren: hmm ?
21:11
<warren>
vagrantc, don't worry, already fixed
21:11
vagrantc, my last build was prior to one of your typo fixes
21:11
<vagrantc>
ah
21:27mccann has quit IRC
21:29alekibango is now known as aleki|away
21:33jammcq has joined #ltsp
21:33
<jammcq>
hey friends
21:36captain_magnus has quit IRC
21:38
<vagrantc>
jammcq: heya
21:46
<warren>
hey
21:46
vagrantc, ogra might not recognize what he sees when he gets back
21:46
vagrantc, a few days later in fact...
21:46
<vagrantc>
warren: well, hopefully he'll like what we've done
21:47
<jammcq>
hey guys
21:47captain_magnus has joined #ltsp
21:47
<vagrantc>
jammcq: so, we think we've come up with a sane versioning system, if not a release system, for ltsp :)
21:49
<warren>
jammcq, see the list
21:49
<jammcq>
yes, I've been watching that. I'm quite impressed
21:49
<warren>
vagrantc, so regarding location of xsession, technically the current filesystem lookups to find it are wrong, because it is really the location on the server we care about.
21:49
vagrantc, but in practice client matches server right?
21:50
<vagrantc>
warren: yes. so i think that's a good sane default.
21:50
warren: but i want it to be better than that.
21:50
warren: why not pass it with ldminfod ?
21:50
<warren>
if we have ldm rely on ldminfod, it would be correct, but doesn't this break compat?
21:50
new ldm wouldn't work with older ltsp
21:51
gah, I don't know why I'm worrying about this, there are higher priorities...
21:51* warren gives more money to Obama...
21:51
<vagrantc>
warren: we can do all three ... sane default defined at compile time, ldminfod passes the server, and it falls back to the others if that doesn't work ...
21:52
<warren>
vagrantc, a little excessive to have all three?
21:52
<vagrantc>
warren: maybe.
21:52
warren: maybe just ldminfod + sane default
21:52
<warren>
the only one that matters is the one from ldminfod
21:53
<vagrantc>
but have a sane default in case it's not defined in ldminfod ... and for unusual corner cases, they can define in lts.conf
21:54
i.e. no ldminfod response
21:55
<warren>
really overboard to have more than ldminfod and sane default
21:56
and we can get rid of sane default in a while
21:58
<vagrantc>
warren: well, the code is already in there to support defining it in lts.conf ... i don't want to remove that.
21:58
<warren>
vagrantc, oh, since when?
21:58
<vagrantc>
warren: since before it was written in C
21:58
<warren>
wow
21:58
<vagrantc>
hmmm... maybe it never made it in the python -> C transition
21:59* vagrantc looks
21:59
<vagrantc>
warren: LDM_SESSION
22:01
warren: so really, all that code could easily be handled in ltsp_config ...
22:02
<warren>
except in cases where lts.conf download failed
22:02
and your client works except you can't login for some obscure reason
22:03
<vagrantc>
oh, people and their crazy lts.conf issues.
22:03
<warren>
I suppose it doesn't hurt to keep LDM_SESSION
22:03
but ldminfod should be the primary source
22:03
<vagrantc>
please don't remove it.
22:03chup has quit IRC
22:03
<vagrantc>
it's such a trivial amount of code to keep.
22:03
for the flexibility it provides...
22:04chup has joined #ltsp
22:28vagrantc has quit IRC
22:39chupa has joined #ltsp
22:41chup has quit IRC
22:55TelnetManta has quit IRC
22:55vmlintu has quit IRC
22:56TelnetManta has joined #ltsp
22:56vmlintu has joined #ltsp
23:12praveer_cool has quit IRC
23:29basanta has joined #ltsp