IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 25 March 2008 (all times are UTC)
| 00:00 | sadap 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:09 | tux_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:14 | klausade 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:17 | klausade has joined #ltsp | |
| 00:27 | tux_440volt has quit IRC | |
| 00:27 | sadap has left #ltsp | |
| 00:33 | subsume_ has joined #ltsp | |
| 00:33 | subsume_ is now known as subsume | |
| 00:40 | makghosh has joined #ltsp | |
| 00:47 | petre has joined #ltsp | |
| 00:48 | makghosh has quit IRC | |
| 00:59 | makghosh has joined #ltsp | |
| 01:04 | petre has quit IRC | |
| 01:07 | makghosh has quit IRC | |
| 01:22 | subsume has quit IRC | |
| 01:23 | wicuo has joined #ltsp | |
| 01:23 | |Paradox| has quit IRC | |
| 01:23 | wicuo is now known as |Paradox| | |
| 01:30 | makghosh has joined #ltsp | |
| 01:54 | makghosh has quit IRC | |
| 01:59 | subir has joined #ltsp | |
| 01:59 | chupa has joined #ltsp | |
| 02:01 | chup has quit IRC | |
| 02:07 | deavid has joined #ltsp | |
| 02:15 | makghosh has joined #ltsp | |
| 02:36 | tuukka has joined #ltsp | |
| 02:37 | Pascal_1 has joined #ltsp | |
| 02:38 | Q-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:43 | t-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:05 | captain_magnus has quit IRC | |
| 03:07 | captain_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:36 | subir has quit IRC | |
| 03:38 | mikkel 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:18 | bobby_C has joined #ltsp | |
| 04:23 | ogra_cmpc has joined #ltsp | |
| 04:23 | ogra_cmpc has left #ltsp | |
| 04:25 | <klausade> it's 1261 now that i look at it
| |
| 04:32 | cyberorg has quit IRC | |
| 04:33 | twinprism has quit IRC | |
| 04:38 | Faithful 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:57 | K_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:24 | basanta 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:48 | chupa 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:48 | chupa has joined #ltsp | |
| 05:51 | Q-FUNK has quit IRC | |
| 05:52 | Q-FUNK has joined #ltsp | |
| 05:53 | bobby_C has quit IRC | |
| 05:57 | sepski 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:58 | mhterres has joined #ltsp | |
| 06:59 | cyberorg has joined #ltsp | |
| 07:12 | Guaraldo has joined #ltsp | |
| 07:17 | chupa has quit IRC | |
| 07:17 | chupa has joined #ltsp | |
| 07:17 | basanta has quit IRC | |
| 07:19 | jammcq has quit IRC | |
| 07:30 | stgraber_ has joined #ltsp | |
| 07:31 | stgraber_ has joined #ltsp | |
| 07:35 | slidesinger has joined #ltsp | |
| 07:36 | K_O-Gnom has quit IRC | |
| 07:37 | K_O-Gnom has joined #ltsp | |
| 07:43 | pdjbarber has joined #ltsp | |
| 07:47 | jammcq has joined #ltsp | |
| 07:48 | t-kid has quit IRC | |
| 07:55 | K_O-Gnom has quit IRC | |
| 07:55 | K_O-Gnom has joined #ltsp | |
| 08:04 | makghosh has quit IRC | |
| 08:07 | deavid has quit IRC | |
| 08:10 | tuukka has quit IRC | |
| 08:12 | Faithful 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:21 | bobby_C has joined #ltsp | |
| 08:22 | cliebow_ has joined #ltsp | |
| 08:23 | cliebow_ has quit IRC | |
| 08:28 | F-GT has quit IRC | |
| 08:30 | <klausade> Pascal_1: yes it works from ldm.
| |
| 08:31 | <Pascal_1> snirf
| |
| 08:32 | mhterres 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:35 | mhterres has joined #ltsp | |
| 08:36 | <Pascal_1> for pam.d i'havent foreground.so, is it important ?
| |
| 08:37 | subsume_ 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:37 | subsume_ 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:44 | Q-FUNK has quit IRC | |
| 08:44 | <Pascal_1> the logout is not seen by pam
| |
| 08:45 | Gadi has joined #ltsp | |
| 08:46 | xcasex_ 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:50 | petre 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:58 | vagrantc has joined #ltsp | |
| 09:00 | mccann has joined #ltsp | |
| 09:02 | <klausade> Pascal_1: use tar -czf /home/ltsp.tgz /opt/ltsp/i386
| |
| 09:04 | elisboa has quit IRC | |
| 09:08 | elisboa has joined #ltsp | |
| 09:12 | F-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:17 | pdjbarber has quit IRC | |
| 09:17 | <klausade> Pascal_1: http://pastebin.fr/1262
| |
| 09:21 | gvy has quit IRC | |
| 09:22 | gvy 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:23 | deavid 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:31 | Daggett has joined #ltsp | |
| 09:33 | chupa has quit IRC | |
| 09:34 | chupa has joined #ltsp | |
| 09:38 | xcasex_ has quit IRC | |
| 09:38 | dtrask has joined #ltsp | |
| 09:42 | mikkel has quit IRC | |
| 09:49 | subsume has quit IRC | |
| 09:55 | vmlintu has joined #ltsp | |
| 10:05 | Q-FUNK has joined #ltsp | |
| 10:05 | K_O-Gnom has quit IRC | |
| 10:10 | Q-FUNK has quit IRC | |
| 10:11 | Q-FUNK has joined #ltsp | |
| 10:11 | praveer_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:26 | staffencasa 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:38 | dtrask has quit IRC | |
| 10:39 | Daggett has quit IRC | |
| 11:04 | Faithful has quit IRC | |
| 11:13 | DonSilver has joined #ltsp | |
| 11:14 | lns has quit IRC | |
| 11:15 | chupa has quit IRC | |
| 11:16 | chupa has joined #ltsp | |
| 11:36 | pdjbarber has joined #ltsp | |
| 11:36 | pascal_2 has joined #ltsp | |
| 11:37 | cliebow_ 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:56 | chupa has quit IRC | |
| 11:56 | chupa has joined #ltsp | |
| 11:58 | pascal_2 has quit IRC | |
| 12:04 | Q-FUNK has quit IRC | |
| 12:08 | elisboa has quit IRC | |
| 12:09 | spectra has joined #ltsp | |
| 12:17 | elisboa has joined #ltsp | |
| 12:25 | staffencasa has quit IRC | |
| 12:25 | staffencasa has joined #ltsp | |
| 12:43 | <ltsppbot> Someone pasted "vagrantc replies" (19 lines) at http://pastebot.ltsp.org/484
| |
| 12:43 | <cyberorg> vagrantc, ^^
| |
| 12:46 | chup has joined #ltsp | |
| 12:46 | * vagrantc looks | |
| 12:46 | tux_440volt has joined #ltsp | |
| 12:46 | chupa 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:01 | rjune_ 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:18 | chup has quit IRC | |
| 13:18 | chup 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:27 | pdjbarbe1 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:31 | deavid 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:34 | mikkel 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:40 | pdjbarber 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:40 | warren_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:41 | warren_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:45 | TelnetManta 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:58 | pascal_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:59 | tux_440volt has quit IRC | |
| 13:59 | <vagrantc> Guaraldo: configure the *DM on the server to accept xdmcp connections
| |
| 13:59 | tux_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:06 | pdjbarbe1 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:10 | tux_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:24 | chup has quit IRC | |
| 14:25 | chup has joined #ltsp | |
| 14:26 | kushal 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:44 | pascal_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:56 | Gadi 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:57 | kushal 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:07 | kushal 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:14 | subsume_ has joined #ltsp | |
| 15:14 | subsume_ 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:19 | lns 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:19 | chup 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:20 | chup 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:20 | kushal 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:28 | cliebow_ 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:30 | xai 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:34 | praveer_cool has quit IRC | |
| 15:34 | * vagrantc notes that the format has changed at least once before | |
| 15:34 | praveer_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:36 | alekibango 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:40 | twinprism has joined #ltsp | |
| 15:41 | Egyptian[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:47 | petre 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:59 | chup has quit IRC | |
| 15:59 | chup has joined #ltsp | |
| 16:01 | mhterres has quit IRC | |
| 16:03 | highvolt1ge has quit IRC | |
| 16:04 | mikkel 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:20 | City_Of has joined #ltsp | |
| 16:20 | City_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:36 | City 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:39 | slidesinger 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:43 | chup has quit IRC | |
| 16:44 | chup 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:56 | Egyptian[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:58 | gonzaloaf 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:04 | chup 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:04 | chup 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:10 | Guaraldo has quit IRC | |
| 17:10 | <warren> vagrantc, it should be only snapshots you mean? =)
| |
| 17:12 | Al-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:34 | chup has quit IRC | |
| 17:35 | chup has joined #ltsp | |
| 17:50 | gonzaloaf has quit IRC | |
| 17:51 | gonzaloaf 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:54 | bobby_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:03 | manuel_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:30 | subsume has quit IRC | |
| 18:30 | <warren> God Ubuntu has twisted my mind to be afraid of calling it a release.
| |
| 18:30 | xai 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:35 | tessier__ 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:43 | F-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:45 | F-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:48 | TelnetManta 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:49 | gonzaloaf 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:54 | gonzaloaf 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:58 | staffencasa has quit IRC | |
| 18:58 | <vagrantc> yeah, release like two months ago
| |
| 18:59 | <warren> in Fedora time that's ancient
| |
| 19:00 | nsar 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:11 | chup 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:11 | chup 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:28 | nsar has quit IRC | |
| 19:41 | DonSilver has quit IRC | |
| 19:53 | jammcq has quit IRC | |
| 19:55 | jblack has left #ltsp | |
| 20:10 | hari_ has joined #ltsp | |
| 20:11 | hari_ has quit IRC | |
| 20:12 | manuel_schulte has left #ltsp | |
| 20:14 | chup has quit IRC | |
| 20:14 | chup has joined #ltsp | |
| 20:22 | hari_ 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:34 | otavio 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:02 | Al-Khouli has quit IRC | |
| 21:06 | hari_ 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:27 | mccann has quit IRC | |
| 21:29 | alekibango is now known as aleki|away | |
| 21:33 | jammcq has joined #ltsp | |
| 21:33 | <jammcq> hey friends
| |
| 21:36 | captain_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:47 | captain_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:03 | chup has quit IRC | |
| 22:03 | <vagrantc> it's such a trivial amount of code to keep.
| |
| 22:03 | for the flexibility it provides...
| |
| 22:04 | chup has joined #ltsp | |
| 22:28 | vagrantc has quit IRC | |
| 22:39 | chupa has joined #ltsp | |
| 22:41 | chup has quit IRC | |
| 22:55 | TelnetManta has quit IRC | |
| 22:55 | vmlintu has quit IRC | |
| 22:56 | TelnetManta has joined #ltsp | |
| 22:56 | vmlintu has joined #ltsp | |
| 23:12 | praveer_cool has quit IRC | |
| 23:29 | basanta has joined #ltsp | |