IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 8 February 2010 (all times are UTC)
| 00:10 | Faithful has quit IRC | |
| 00:23 | F-GT has quit IRC | |
| 00:25 | Faithful has joined #ltsp | |
| 00:39 | F-GT has joined #ltsp | |
| 02:03 | frederickjh1 has joined #ltsp | |
| 02:03 | frederickjh1 has left #ltsp | |
| 02:04 | frederickjh1 has joined #ltsp | |
| 02:06 | frederickjh1 has left #ltsp | |
| 02:08 | alkisg has quit IRC | |
| 02:10 | alkisg has joined #ltsp | |
| 02:19 | gnunux has joined #ltsp | |
| 02:21 | frederickjh has joined #ltsp | |
| 03:08 | avolkovi has joined #ltsp | |
| 03:20 | <frederickjh> Anyone here using the new ltsp cluster packages with Ubuntu LTSP on Karmic 9.10?
| |
| 03:21 | I have a Karmic LTSP install now and am wondering about the upgrade path to ltsp cluster?
| |
| 03:26 | <appiah> upgrade?
| |
| 03:40 | ogra has quit IRC | |
| 03:48 | ogra has joined #ltsp | |
| 04:02 | bobby_C has joined #ltsp | |
| 04:08 | ogra has quit IRC | |
| 04:16 | ogra has joined #ltsp | |
| 04:25 | frederickjh has quit IRC | |
| 04:29 | <alkisg> stgraber, highvoltage: just noticing that I did try adding `dpkg-divert initctl` to 000-daemon-handling, and while the clients boot fine with the diversion, that didn't solve the problem of $CHROOT/proc being in use right after a fat client installation. So I forced umount -l in ltsp-update-image for now. :-(
| |
| 04:40 | <highvoltage> alkisg: ok
| |
| 04:44 | <ogra> alkisg, meh, cant you do it from the plugin in the finalization stage instead ?
| |
| 04:45 | <alkisg> ogra: there was already a call to umount in ltsp-update-image...
| |
| 04:46 | <ogra> yes, but a proper one
| |
| 04:46 | <alkisg> Hmmm how proper is it? :)
| |
| 04:46 | <ogra> -l should really only be used as a workaround ...
| |
| 04:46 | <alkisg> If the user installed something in the chroot manually, ltsp-update-image will still have problems
| |
| 04:46 | <ogra> so if your plugin makes it break, your plugin should have the workaround as well
| |
| 04:47 | <alkisg> It's not exactly a problem with the plugin. The same can happen if the user installs something manually in the chroot.
| |
| 04:47 | <ogra> (the filesystem stays physically mounted with -l ... its just hidden everywhere)
| |
| 04:47 | (in case of proc that will damage your server)
| |
| 04:47 | <alkisg> We need to find which daemon does that, and a way to bypass it
| |
| 04:47 | It isn't upstart - related, and it isn't hal. I don't know what it is.
| |
| 04:47 | <ogra> you need to fix the daemon handling indeed
| |
| 04:48 | not using -l in ltsp-update-image was done deliberately though
| |
| 04:48 | to save the user from wiping his server setup
| |
| 04:48 | <alkisg> How would not using it save the user?
| |
| 04:48 | <ogra> it blocks
| |
| 04:48 | <alkisg> It doesn't...
| |
| 04:49 | <ogra> so the user has to unmount it in the chroot first
| |
| 04:49 | <alkisg> It just causes a hell of errors in the squashfs
| |
| 04:49 | <ogra> ltsp-update-image will fail rolling the squashfs
| |
| 04:49 | <alkisg> It didn't fail for me
| |
| 04:49 | <ogra> it should
| |
| 04:49 | <alkisg> It just created a squashfs with a lot of /proc/* empty files in it
| |
| 04:49 | <ogra> then something changed and nobody updated the code accordingly
| |
| 04:50 | in any case ltsp-build-client shouldnt move on if /proc is still mounted
| |
| 04:50 | since that can severely damage the host
| |
| 04:50 | <alkisg> build-client? or update-image?
| |
| 04:50 | <ogra> update-image, sorry
| |
| 04:50 | <alkisg> I'm not sure I understand this
| |
| 04:51 | <ogra> too many tools with similar names :)
| |
| 04:51 | <alkisg> The problem is there, sure. But how can creating a squashfs damage the server?
| |
| 04:51 | <ogra> having proc mounted gives you full access to the server HW and all running processes of the host system
| |
| 04:51 | <alkisg> But ltsp-update-image runs *on the server* not on the chroot...
| |
| 04:51 | It already has full access.
| |
| 04:52 | So now I'm just generating a visible error on the user, instead of a filesystem with /proc in it..
| |
| 04:58 | <ogra> wow, ltsp-update-image changed a lot ... so the proc unmounting doesnt block anymore apparently ... and the forcefully excluding of proc in the mksquashfs call was dropped as well
| |
| 04:58 | (it used to have -e cdrom proc)
| |
| 04:59 | and "umount ${CHROOT}/proc" used to be "umount ${CHROOT}/proc || exit"
| |
| 05:01 | hersonls has joined #ltsp | |
| 05:01 | <alkisg> Ugh :)
| |
| 05:01 | I also proposed excluding proc from the squashfs command line...
| |
| 05:03 | If `umount ${CHROOT}/proc || exit` was still there, I'd just modify the finalization plugin... :-/ anyway
| |
| 05:03 | <ogra> either way i wouldnt use -l
| |
| 05:04 | <alkisg> The main problem is that I have no clue on how to find what uses /proc
| |
| 05:04 | <ogra> only for temporary workarounds
| |
| 05:04 | <alkisg> And without umount -l, the fat client plugin wouldn't work in many cases...
| |
| 05:05 | <ogra> right, as i said ... temporary ... but that should definately be solved before releasing it
| |
| 05:05 | <alkisg> How? :)
| |
| 05:05 | * alkisg is all ears! | |
| 05:05 | <ogra> no idea, i have no time to work on ltsp atm
| |
| 05:05 | else i'D do some testbuilds
| |
| 05:06 | <alkisg> I even tried killing almost everything on the server when $CHROOT/proc was in use, but that didn't help!
| |
| 05:06 | <ogra> unlikely that its something that runs on the server
| |
| 05:06 | <alkisg> I wonder if it's some mysterious upstart interprocess communication with sockets involved in this...
| |
| 05:06 | <ogra> might be
| |
| 05:07 | look at the code :)
| |
| 05:07 | <alkisg> Right... only 10.000.000 lines of code, shouldn't take long... :D
| |
| 05:07 | <ogra> upstart isnt that big
| |
| 05:07 | <alkisg> I did try dpkg-divert'ing upstart (initctl) like the karmic release notes advice. To no avail...
| |
| 05:07 | <ogra> and grepping for proc shouldnt take long in upstarts source
| |
| 05:08 | but i doublt upstart uses proc ... its more likely using something in /var for IPC
| |
| 05:09 | * alkisg thinks that the correct solution will be when we use lxc or qemu to build/test/update the chroot :D | |
| 05:10 | <ogra> ugh, why qemu ?
| |
| 05:10 | thats definately a waste over a chroot
| |
| 05:10 | i see a reason to use lxc with chroots in general though
| |
| 05:16 | <alkisg> Doesn't qemu also emulate different architectures?
| |
| 05:16 | <ogra> it does
| |
| 05:16 | <alkisg> (for e.g. powerpc clients...)
| |
| 05:16 | <ogra> but there is no reason to use it if you dont need to
| |
| 05:17 | i.e. waste all the computing power (and slow down everything significantly) surely makes no sense if you build on x86 compatible HW for x86 compatible clients
| |
| 05:18 | mikkel has joined #ltsp | |
| 05:40 | pmatulis has joined #ltsp | |
| 06:03 | avolkovi has quit IRC | |
| 06:33 | pmatulis has quit IRC | |
| 06:44 | vvinet has quit IRC | |
| 06:59 | <alkisg> Hrm. It seems like the tftpd-hpa problem also affects debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551828
| |
| 07:00 | Up until Karmid, tftpd-hpa.postinst used inetd and /var/lib/tftpboot
| |
| 07:00 | Now it runs as a daemon by default, and uses /srv/tftp
| |
| 07:01 | That debconf setting also has a high priority, so the user is prompted to verify that this is the correct directory.
| |
| 07:02 | So should LTSP in Ubuntu switch to /svr/tftp as well?!
| |
| 07:03 | gnunux has quit IRC | |
| 07:04 | lucascoala has joined #ltsp | |
| 07:05 | gnunux has joined #ltsp | |
| 07:08 | <_UsUrPeR_> good morning
| |
| 07:09 | jammcq has quit IRC | |
| 07:09 | lucascoala has quit IRC | |
| 07:09 | <ogra> alkisg, if tftp-hps is used it should pull the settings from /etc/default imho
| |
| 07:09 | at least for new builds
| |
| 07:10 | <alkisg> ogra, I installed Lucid 3 days ago...
| |
| 07:10 | <ogra> existing installs should be covered by the tftp-hpa fix
| |
| 07:10 | <alkisg> (re-installed :))
| |
| 07:10 | <ogra> (which might not have entered lucid yet)
| |
| 07:11 | <alkisg> Hmmm
| |
| 07:11 | Got it, thanks. Looking...
| |
| 07:11 | <ogra> hmm, nov 2009 ... that should definately be in testing and thus in lucid
| |
| 07:11 | probably the fix didnt work right
| |
| 07:11 | but the file shouldnt be touched on upgrades
| |
| 07:13 | if you see issues with upgrades, file a bug :)
| |
| 07:13 | <alkisg> ogra, but what about new installations?
| |
| 07:14 | Is the user expected to manually modify the path to /var/lib/tftpboot ?
| |
| 07:14 | (and also put it to inetd.conf?)
| |
| 07:14 | <ogra> no
| |
| 07:14 | no
| |
| 07:14 | ltsp should properly follow the new defaults
| |
| 07:14 | but definately not break on upgrades
| |
| 07:15 | <alkisg> Then I should probably file a bug in LTSP for it
| |
| 07:15 | <ogra> check with vagrant what he did for debian
| |
| 07:15 | <alkisg> ...and we should also modify a lot of wiki pages... hmm... :-/
| |
| 07:15 | <ogra> definately
| |
| 07:15 | <alkisg> k, I'll try to contact stgraber and vagrantc later on. Ty! :)
| |
| 07:16 | <ogra> i'm sure vagrant already dealt with that for debian/testing
| |
| 07:16 | should just be an issue of copying some code
| |
| 07:16 | * alkisg is modifying sch-scripts to conflict with tftpd-hpa and use only dnsmasq for the time being... Good thing that stgraber lowered tftpd-hpa to recommends! :D | |
| 07:22 | etyack has joined #ltsp | |
| 07:23 | shawnp0wers has joined #ltsp | |
| 07:29 | Kicer86 has joined #ltsp | |
| 07:29 | cliebow has joined #ltsp | |
| 07:30 | <cliebow> a
| |
| 07:40 | <appiah> b
| |
| 07:41 | <ogra> c
| |
| 07:43 | <alkisg> d
| |
| 07:45 | <alincoln> f
| |
| 07:45 | oops
| |
| 07:45 | highvoltage has quit IRC | |
| 07:46 | <ogra> you broke at !
| |
| 07:47 | *it
| |
| 07:47 | highvoltage has joined #ltsp | |
| 07:47 | <alincoln> ah, darnit!
| |
| 07:47 | :P
| |
| 07:51 | cliebow has quit IRC | |
| 07:51 | cliebow has joined #ltsp | |
| 08:02 | cliebow has quit IRC | |
| 08:02 | cliebow has joined #ltsp | |
| 08:06 | cliebow has quit IRC | |
| 08:07 | cliebow has joined #ltsp | |
| 08:09 | slidesinger has joined #ltsp | |
| 08:14 | highvoltage has quit IRC | |
| 08:28 | Gadi has joined #ltsp | |
| 08:31 | pmatulis has joined #ltsp | |
| 08:33 | GodFather has joined #ltsp | |
| 08:34 | highvoltage has joined #ltsp | |
| 08:38 | <sbalneav> Morning all
| |
| 08:40 | <alkisg> Good morning sbalneav
| |
| 08:42 | <sbalneav> looks like tftp-hpa's changed?
| |
| 08:42 | <alincoln> yeah, an update to that broke my lucid stuff.
| |
| 08:46 | cliebow has quit IRC | |
| 08:46 | <alkisg> Heh, LTSP 5.2 will also need a tftp dir change :)
| |
| 08:46 | cliebow has joined #ltsp | |
| 08:46 | <alkisg> (for debian/ubuntu, that is....)
| |
| 08:47 | I think it's a good time to get rid of that 2000 port as well :D
| |
| 08:47 | CAN-o-SPAM has joined #ltsp | |
| 08:54 | <sbalneav> alkisg: What we ought to do is apply to IANA and get an assigned port number.
| |
| 08:54 | <alkisg> sbalneav: hmmm I just happen to know the right person to do that... :D
| |
| 08:55 | But we might need more than one number
| |
| 08:55 | (i.e more than one chroots)
| |
| 08:55 | <sbalneav> Yeah,we'd need 2
| |
| 08:55 | Well, I don't think you can be greedy
| |
| 08:55 | I think one for root and one for swap's all you can pretty much ask for.
| |
| 08:55 | <alkisg> 2 for chroots + 1 for nbdswapd?
| |
| 08:56 | <sbalneav> one for i386, one for x64?
| |
| 08:56 | <alkisg> one for fat, one for nvidia clients... whatever
| |
| 08:56 | Usage cases might vary
| |
| 08:57 | <sbalneav> Well, the specifiction process doesn't go like that.
| |
| 08:57 | <alkisg> I wonder if we should always be passing the port as a kernel parameter...
| |
| 08:57 | <sbalneav> You have to be VERY explicit about what each port's going to be used for
| |
| 08:57 | You can't just say "We want 3 ports"
| |
| 08:58 | IANA says, "yeah, you and everyone else. There's 65535 of 'em, why should we assign you 3? " :)
| |
| 08:58 | <alkisg> Roger that. I'm just saying that it would be nice to have swapd first and nbdroot second, so that we may... abuse the ports a little to add extra chroots
| |
| 08:59 | Those extra chroots will be per-site anyways...
| |
| 08:59 | <sbalneav> Well, iana aside, where would we put them?
| |
| 08:59 | <alkisg> 9571 + ?
| |
| 08:59 | <ogra> just make sure to properly handle upgrades :)
| |
| 08:59 | <sbalneav> i.e. what number/range do we want?
| |
| 09:00 | <alincoln> are there stretches in the port numbers that IANA sets aside that they won't assign?
| |
| 09:00 | possibly those can be assumed to be "clearer".
| |
| 09:00 | <alkisg> 9571 = ldminfod, 9572 = nbdswapd, 9573 = nbd-server
| |
| 09:00 | <sbalneav> ogra: Would "properly handle upgrades" mean, you need to re-run ltsp-update-image to install the image on the new port?
| |
| 09:00 | or something more automagic?
| |
| 09:00 | <alkisg> (and, additional, not iana-approved chroots, to 9574+...)
| |
| 09:01 | <ogra> sbalneav, adjust inetd.conf if you upgrade the server side
| |
| 09:01 | frederickjh has joined #ltsp | |
| 09:01 | <alkisg> ogra: I disagree with that tactic. That's what makes people still use woody and dapper. If it broke on updates, they'd upgrade... :D
| |
| 09:01 | <ogra> and dont forget if you have 10 chrtoots you will need $portnum+10 free
| |
| 09:02 | alkisg, if it broke on upgrades they would go to redhat since thats default behavior :P
| |
| 09:03 | <sbalneav> Now, now :)
| |
| 09:03 | * Gadi suggests a config file for ltsp-update-kernels (or whatever will write to inetd.conf) to pull from | |
| 09:05 | <Gadi> /etc/ltsp-update.conf
| |
| 09:05 | er, /etc/ltsp/ltsp-update.conf
| |
| 09:05 | <alkisg> Gadi, it's currently called /etc/ltsp/update-kernels.conf
| |
| 09:06 | <ogra> Gadi, that doesnt help during upgrade ... should be handled by posinst scripts
| |
| 09:06 | Comete has joined #ltsp | |
| 09:06 | <Comete> hi
| |
| 09:06 | <Gadi> the postinit scripts should include a call to ltsp-update-whatever-changes-the-ports
| |
| 09:06 | <ogra> right
| |
| 09:06 | <Comete> i'm trying to setup an Edubuntu 9.10 LTSP server for a school
| |
| 09:07 | <alkisg> Hi
| |
| 09:07 | <Gadi> we should probably have a flag to ltsp-update-image that just updates inetd.conf and skips updating the image
| |
| 09:07 | <Comete> after updating my server, i've rebuild the chroot environment with ltsp-build-client
| |
| 09:08 | <sbalneav> You know what's really missing from /etc/group? a gcos field.
| |
| 09:08 | <Comete> but know when i boot my thin clients i get error about "mtab"
| |
| 09:08 | <alkisg> Would that help in solving the LTSP ports problem? :P
| |
| 09:09 | <ogra> sbalneav, heh, feel free to get into a 5 year discussion with upstream *g*
| |
| 09:09 | * ogra personally agrees though | |
| 09:09 | <alkisg> Comete, the mountall warnings are "normal"... what's your actual problem?
| |
| 09:10 | <ogra> Gadi, ltsp-update-image should get similar options to update-initramfs imho
| |
| 09:10 | and we should probably add a timestamp to the image name
| |
| 09:10 | <Gadi> why?
| |
| 09:11 | <ogra> to only update specific images
| |
| 09:11 | <Comete> alkisg: normal ?
| |
| 09:11 | alkisg: i didn't get this before rebuilding the chroot
| |
| 09:11 | <ogra> so you can have the same chroot but subsequently add stuff and just call ltsp-update-image
| |
| 09:12 | <alkisg> Comete: what's the exact wording of that error?
| |
| 09:13 | "according to mtab, <filesystem> is already mounted"?
| |
| 09:14 | <ogra> these are just warnings ... not errors, dont do any harm
| |
| 09:15 | <Comete> alkisg: ok thanks, so next problem :)
| |
| 09:15 | if i try to reboot i get a lot of SQUASHFS errors
| |
| 09:16 | "Unable to read page, block ..."
| |
| 09:16 | and the thin client doesn't reboot
| |
| 09:16 | <alkisg> That was fixed shortly after Karmic
| |
| 09:16 | a "reboot -f" in a script needs to be "reboot -fp"
| |
| 09:17 | You can either change that manually, or put some ppa in your sources, which has (much) updated ltsp versions..
| |
| 09:17 | !stgraber-ppa
| |
| 09:17 | <ltspbot> alkisg: "stgraber-ppa" :: https://launchpad.net/~stgraber/+archive/ppa
| |
| 09:18 | <Comete> alkisg: ok, but it is "production safe" ?
| |
| 09:18 | <alkisg> Urm, hard to say. It's used in production by many people, but of course they're not official updates (even though they are by the ubuntu/ltsp maintainer)
| |
| 09:19 | Search the launchpad bug page for ltsp for the manual fix - it's been filed there
| |
| 09:19 | <Comete> alkisg: which script should i modify ?
| |
| 09:20 | ok thanks
| |
| 09:20 | GodFather has quit IRC | |
| 09:20 | <vbundi> with IPAPPEND 3, do I need to have an "ip=..." line too?
| |
| 09:20 | <alkisg> No
| |
| 09:21 | <vbundi> ty
| |
| 09:23 | <alkisg> Was anyone able to run googleearth as a localapp with SSH_FOLLOWSYMLINKS=true (=the default)?
| |
| 09:24 | <Comete> another problem, i've set up SOUND = Yes but i get no sound on my thin clients, any idea ?
| |
| 09:24 | <vbundi> did you have sound before your upgrade?
| |
| 09:24 | <alkisg> (it displays an error about not being able to create a lock == a symlink from ~/.googleearth/file to /proc/pid)
| |
| 09:25 | (and I wonder if there's some trick, like HOME=/tmp/xxx googleearth, to bypass the problem...)
| |
| 09:26 | (it runs fine with SSH_FOLLOWSYMLINKS=false)
| |
| 09:27 | <Comete> vbundi: no sound before
| |
| 09:28 | vbundi: no speaker icon either...
| |
| 09:28 | Ahmuck-Jr has left #ltsp | |
| 09:29 | <ogra> are you sure there is a driver for your sound HW in the kernel ?
| |
| 09:30 | mikkel has quit IRC | |
| 09:31 | <Comete> ogra: don't know
| |
| 09:31 | <ogra> well, do you know what sound HW the client has ?
| |
| 09:32 | <Comete> it's an HP thin client
| |
| 09:32 | HP t5145 exactly
| |
| 09:32 | <alkisg> Comete: sit on a client. Open a gnome terminal. Run: ltsp-localapps xterm. An xterm will open. In that, run: lspci -nn
| |
| 09:35 | <Comete> alkisg: it's a VIA Azalia HDAC
| |
| 09:36 | * alkisg knows how to run lspci, but has no clue about hardware newer than 1995 :) | |
| 09:37 | <Comete> :)
| |
| 09:38 | if i run alsamixer in the same xterm, i can see "master", "PCM" etc...
| |
| 09:38 | Faithful has quit IRC | |
| 09:40 | <ogra> thats a good sign
| |
| 09:40 | can you adjust volumes ?
| |
| 09:41 | dro has joined #ltsp | |
| 09:41 | <Comete> ogra: yes i can
| |
| 09:42 | <ogra> was anything muted ?
| |
| 09:42 | sutula has joined #ltsp | |
| 09:42 | Kicer86 has quit IRC | |
| 09:43 | <Comete> ogra: no nothing
| |
| 09:53 | Faithful has joined #ltsp | |
| 09:54 | The_Code has joined #ltsp | |
| 09:55 | <vbundi> alkisg: on friday you had suggested I log my terminal's bootup using bootchart to diagnose the very long boot times
| |
| 09:55 | alkisg: I installed bootchart in my chroot but after booting a terminal, I have no logs... am I doin this right?
| |
| 09:58 | <ogra> did you run ltsp-update-kernels ?
| |
| 09:58 | bootchart logs from the initramfs
| |
| 09:58 | s/logs/starts/
| |
| 10:05 | Comete has quit IRC | |
| 10:06 | <vbundi> ogra: you lost me... I just thought it would write to /var/log/bootchart/ why would I need to update the kernel, sorry
| |
| 10:06 | <ogra> you need the updated initramfs, thats where the bootchart binary starts from
| |
| 10:06 | at the end of the install the bootchart package runs update-initramfs to copy itself into the initrd
| |
| 10:07 | <vbundi> ohh
| |
| 10:07 | <ogra> the initrd lives under /opt/ltsp/...
| |
| 10:07 | <vbundi> I see
| |
| 10:07 | yes
| |
| 10:07 | <ogra> so you need to run ltsp-update-kernels
| |
| 10:07 | <vbundi> cool thanks, I'll try it again now
| |
| 10:11 | jbrett has joined #ltsp | |
| 10:17 | staffencasa has joined #ltsp | |
| 10:29 | gnunux has quit IRC | |
| 10:38 | <vbundi> ogra: so should this log file be in /opt/ltsp/i386/var/log/bootchart/ ?
| |
| 10:39 | <ogra> no, it should be on the running client in /var/log/bootchart
| |
| 10:40 | <vbundi> oh, I've got my terminals booting directly into an rdesktop client
| |
| 10:41 | <alkisg> add also screen_02=shell in lts.conf, switch to vt2, and scp it to the server...
| |
| 10:41 | <ogra> right
| |
| 10:41 | <alkisg> Does anyone have any good or bad opinion about using dnsmasq as the tftp server?
| |
| 10:42 | <ogra> apart from the fact that its not supported in ubuntu ?
| |
| 10:42 | no
| |
| 10:44 | <vbundi> alright so I'll boot to a shell on my thin client... vt2 is a type of terminal? never used it though as far as I know
| |
| 10:45 | <alkisg> ogra: it's not supported? it's in *main* :)
| |
| 10:45 | <ogra> huh ?
| |
| 10:45 | thats news to me
| |
| 10:46 | <alkisg> dnsmasq-base has been in main since hardy, I think...
| |
| 10:46 | <ogra> ogra@osiris:~/Devel/branches/project-rootstock$ apt-cache show dnsmasq|grep Filename
| |
| 10:46 | Filename: pool/universe/d/dnsmasq/dnsmasq_2.52-1_all.deb
| |
| 10:47 | <alkisg> vbundi: yes, it's a terminal which you can switch to by pressing alt+ctrl+f2. To return to rdesktop, you press alt+ctrl+f7.
| |
| 10:47 | <vbundi> alkisg: ohh always referred to em as tty's
| |
| 10:48 | I get what you guys are saying now... lol
| |
| 10:48 | <ogra> its just another name :)
| |
| 10:48 | <vbundi> I'm thinking.. scp my terminal?... scp the log file..
| |
| 10:48 | <ogra> vitual treminal ... tele type terminal
| |
| 10:48 | or so ...
| |
| 10:49 | not sury why the last terminal in tele type terminal is abbreviated with y though, sbalneav might know such stuff :)
| |
| 10:49 | <vbundi> I was in minicom not too long ago and saw VT2 I thought and I thought it was a type of terminal ie ansi vs vt2
| |
| 10:50 | oh nm I'm thinking vt102
| |
| 10:52 | hmm so /var/log/bootchart/ is empty
| |
| 10:52 | I chrooted into /opt/ltsp/i386, apt-get install bootchart, exit, ltsp-update-kernels, ltsp-update-image
| |
| 10:53 | dunno if the image update is required but I did it
| |
| 11:01 | johnny has left #ltsp | |
| 11:01 | <vbundi> found the log file under cow/var/log/bootchart/
| |
| 11:03 | pmatulis has quit IRC | |
| 11:04 | <alkisg> Is there any difference in `chroot "$ROOT" mount -t proc proc /proc` vs `mount -t proc proc "$ROOT/proc"` ?
| |
| 11:08 | rhodan_ has joined #ltsp | |
| 11:08 | rhodan has quit IRC | |
| 11:09 | pmatulis has joined #ltsp | |
| 11:13 | <vbundi> cool, this bootchart is pretty neat... it looks like around 115s it starts trying to load alsa-utils and amixer.. and it does that for over 3 minutes
| |
| 11:13 | <ogra> sounds broken to me
| |
| 11:13 | <vbundi> and I get a ton of pgrep/sleep processes
| |
| 11:14 | <ogra> can you upload it somewhere ?
| |
| 11:14 | <vbundi> yea lemme see here
| |
| 11:16 | my disk utilization is 2MB/s, pretty slow isn't it
| |
| 11:17 | <ogra> well, thats your network utilization
| |
| 11:17 | since your disk is a nbd device
| |
| 11:17 | <vbundi> thats what I thought.. and 2MB a sec is pretty bad
| |
| 11:18 | <ogra> well, upload the chart somewhere
| |
| 11:18 | <vbundi> trying to upload this png to imageshack but it's timing out
| |
| 11:18 | <alkisg> imagebin.org
| |
| 11:18 | <vbundi> thanks
| |
| 11:20 | http://imagebin.org/83902
| |
| 11:22 | <ogra> whats that cmdline you have set, where does it come from ?
| |
| 11:22 | etyack has quit IRC | |
| 11:22 | <vbundi> ?
| |
| 11:22 | <ogra> also why do you have avahi installed in the chroot
| |
| 11:23 | kernel options: at the top
| |
| 11:23 | thats surely not standard
| |
| 11:24 | <vbundi> I installed ubuntu server 9.10 x64, apt-get install ltsp-server-standalone, and have installed bootchart into this image
| |
| 11:24 | <ogra> the 2MB are fine ... it doent access the disk much anymore afterwards
| |
| 11:24 | <alkisg> ogra, ? Afaik, those are the standard options...
| |
| 11:24 | <vbundi> I don't think I've done anything else
| |
| 11:24 | <ogra> your CPU is permanently at 100%
| |
| 11:24 | alkisg, shouldnt
| |
| 11:24 | <alkisg> Which one?
| |
| 11:25 | <ogra> kernel options:
| |
| 11:25 | see the top of the image
| |
| 11:25 | we dont set initrd= or BOOT_IMAGGE
| |
| 11:25 | <alkisg> Yes, but which one of those seem wrong to you?
| |
| 11:25 | <ogra> i'm not sure that doesnt confuse the kernel
| |
| 11:25 | <alkisg> We do set initrd, and BOOT_IMAGE is set by pxelinux.0
| |
| 11:25 | <ogra> we shouldnt have to set initrd
| |
| 11:26 | well, in any case its not the network, nothing is loaded anymore after 15 sec
| |
| 11:26 | <alkisg> When we use "append initrd..." in pxelinux.cfg/default, then pxelinux appends that to the kernel command line
| |
| 11:26 | <ogra> well, not nothing but not enough to cause an issue
| |
| 11:26 | alkisg, right, i said we shouldnt need to :)
| |
| 11:27 | <alkisg> vbundi: here's another image to compare: http://www.stgraber.org/download/bootchart-ltsp-20100126.png
| |
| 11:27 | <ogra> anyway, looks like ltspfs is totally broken
| |
| 11:28 | <alkisg> vbundi, what's your network speed?
| |
| 11:28 | <ogra> to bad one cant really read the things
| |
| 11:28 | <vbundi> 100Mbit
| |
| 11:28 | my pxelinux.cfg/default if it matters
| |
| 11:28 | <alkisg> Does it work fast once it completes booting?
| |
| 11:28 | <ogra> alkisg, its not the network, its an issue with the crusoe CPU i guess
| |
| 11:28 | <vbundi> http://pastebin.org/88327
| |
| 11:28 | <alkisg> ogra, I'm wondering if the network driver could cause the cpu issue...
| |
| 11:29 | <ogra> i doubt that would explain the endless loops of the scripts
| |
| 11:29 | <vbundi> to be honest, I thought it would be faster, they're 800MHZ terminals with plenty of ram and youtube video is pretty choppy running at 1280x1024
| |
| 11:29 | <ogra> does the client have any kind of HD ?
| |
| 11:29 | <vbundi> no
| |
| 11:29 | well.. it does
| |
| 11:29 | but I don't think it's being used
| |
| 11:29 | <ogra> ltspfs tries to mount it i think
| |
| 11:30 | <vbundi> they're HP T5700 thin clients.. they used to run XPe
| |
| 11:30 | <ogra> that costs you about a minute
| |
| 11:30 | <vbundi> I wonder...
| |
| 11:30 | they have disk space but it's set to read only
| |
| 11:31 | HP tool sets it that way so your users don't mess with your base image in XPembedded
| |
| 11:31 | <ogra> oh, so its a flash disk ?
| |
| 11:31 | <vbundi> yea
| |
| 11:32 | you can write to it but you have to use lamo hp tools I believe
| |
| 11:32 | <ogra> hmm
| |
| 11:32 | <vbundi> I wonder if I can change the write-protect in the bios of the terminal
| |
| 11:32 | afk
| |
| 11:32 | bobby_C has quit IRC | |
| 11:32 | <ogra> for a test i'D try to remove ltspfsd from the image
| |
| 11:32 | i guess that gains you a lot speedup
| |
| 11:33 | the sound stuff is another different beast
| |
| 11:33 | try to set SOUND=N in lts.conf
| |
| 11:34 | err
| |
| 11:34 | what is gdm and metacity doing there ?
| |
| 11:34 | that chroot is totally messed up
| |
| 11:34 | avahi and gdm should definately not be in there
| |
| 11:34 | <vbundi> ohh you know what
| |
| 11:35 | I installed gnome-core or something I think because I didn't have any graphical
| |
| 11:35 | <alkisg> Ouch
| |
| 11:35 | <vbundi> probably not the way to do it, forgot I did it even
| |
| 11:35 | <ogra> wipe and redo
| |
| 11:35 | <vbundi> can I just build another image?
| |
| 11:35 | <ogra> yes
| |
| 11:36 | <vbundi> k
| |
| 11:36 | <ogra> well, another chroot
| |
| 11:36 | you should start from a clean setup
| |
| 11:36 | i.e. a full ltsp-build-client run
| |
| 11:36 | <vbundi> rm -rf /opt/ltsp/i386
| |
| 11:37 | building client now
| |
| 11:38 | I seem to recall that I had to set the write/protect flag on a USB flash drive and write it to the image that way when I made them for the HP Terminals... I'll see if I can check that out while I wait for it to build
| |
| 11:54 | etyack has joined #ltsp | |
| 12:04 | <vbundi> if I were to use the internal flash (256MB) on these thin clients, it'd really only be for runnin local apps right? not going to improve performance for running RDP to a w2k3 server
| |
| 12:05 | <ogra> if you wipe it you could use it as local swap
| |
| 12:06 | but flash isnt really suited for swapping so it would wear out pretty quickly
| |
| 12:08 | * alkisg would like to have an option to install an ltsp image locally in such a case :) | |
| 12:12 | <knipwim> my keyboard stops working when entering ldm, does anyone know why?
| |
| 12:14 | <dro> knipwim: you using any adapters on the keyboard?
| |
| 12:15 | knipwim: any type of converters?
| |
| 12:15 | <knipwim> nope, normal ps/2 keyboard, ldm-2.0.50
| |
| 12:15 | <ogra> what desktop is running on the server ?
| |
| 12:15 | <dro> knipwim: as silly as it sounds have you tried another keyboard?
| |
| 12:16 | <knipwim> dro: no
| |
| 12:16 | <dro> knipwim: what os you running on the server
| |
| 12:16 | <knipwim> gentoo
| |
| 12:16 | <ogra> might be gnome-settings-daemon ... it takes over the kbd config after login, if thats broken that might make the kbd stop working ...
| |
| 12:16 | <knipwim> ogra: what desktop?
| |
| 12:16 | <ogra> (just guessing)
| |
| 12:16 | knipwim, the desktop you log in to
| |
| 12:17 | knipwim, ltsp needs a desktop session on the server
| |
| 12:17 | <knipwim> haven't set it yet
| |
| 12:17 | but i can't even type in a username in ldm
| |
| 12:18 | <ogra> ah
| |
| 12:18 | is hal running ?
| |
| 12:18 | <knipwim> i just typed in 4 chars
| |
| 12:18 | and after that it stopped
| |
| 12:18 | Egyptian[Home] has quit IRC | |
| 12:18 | <ogra> that rather sounds like a system lockup
| |
| 12:18 | can you still ping the client ?
| |
| 12:19 | <knipwim> yes
| |
| 12:19 | Gadi has quit IRC | |
| 12:19 | <dro> knipwim: have you updated the chroot?
| |
| 12:19 | <ogra> mouse works too ?
| |
| 12:19 | <knipwim> yes, usb mouse
| |
| 12:19 | and i can still log in with ssh
| |
| 12:19 | <ogra> hmm, then its not hal hanging ...
| |
| 12:19 | Lns has joined #ltsp | |
| 12:20 | Egyptian[Home] has joined #ltsp | |
| 12:20 | <knipwim> could it still be the gnome-settings-daemon?
| |
| 12:20 | <dro> knipwim: have you updated the chroot?
| |
| 12:20 | <knipwim> dro: fresh install
| |
| 12:21 | Gadi1 has joined #ltsp | |
| 12:21 | <dro> knipwim: never hurts to update it just to make sure
| |
| 12:21 | in the last week 3 people have had weird problems that I've helped, and the fix has been to update the chroot
| |
| 12:21 | knipwim: what is the chroot running, ubuntu?
| |
| 12:22 | <knipwim> dro: also gentoo
| |
| 12:22 | <dro> knipwim: i am unfamiliar with updating the chroot in gentoo
| |
| 12:23 | <ogra> knipwim, do you have a usb kbd around to rule out the kernel ?
| |
| 12:25 | <knipwim> what a suprise, i actually have
| |
| 12:27 | <ogra> heh
| |
| 12:28 | johnny has joined #ltsp | |
| 12:32 | pmatulis has quit IRC | |
| 12:34 | cliebow has quit IRC | |
| 12:34 | cliebow has joined #ltsp | |
| 12:34 | pmatulis has joined #ltsp | |
| 12:34 | <knipwim> ogra: but to no avail
| |
| 12:35 | <ogra> rebooted the client ?
| |
| 12:35 | same behavior with a fresh boot and usb kbd plugged in
| |
| 12:35 | ?
| |
| 12:35 | <knipwim> twice with usb kbd
| |
| 12:35 | once, some characters
| |
| 12:35 | and second no input at all
| |
| 12:36 | <ogra> that realkly sounds like the input layer of either the kernel or xorg
| |
| 12:36 | <alkisg> Try with SCREEN_07=shell, to see if it's xorg or not?
| |
| 12:37 | rjune has joined #ltsp | |
| 12:37 | <ogra> yeah
| |
| 12:37 | <knipwim> the keyboard works in the shell
| |
| 12:38 | a default xorg.conf is created at client boot
| |
| 12:38 | <ogra> then its X or one of the related layers
| |
| 12:39 | <knipwim> is it located somewhere on the client?
| |
| 12:39 | <ogra> you shouldnt use an xorg.conf with recent xorg versions
| |
| 12:39 | what version of xorg-server does gentoo use on your system atm ?
| |
| 12:40 | <knipwim> 1.6.5
| |
| 12:40 | <ogra> that should autodetect all
| |
| 12:41 | try without xorg.conf and see if it behaves any better
| |
| 12:41 | <knipwim> i don't have one
| |
| 12:41 | thought creating one helped
| |
| 12:42 | but it's not a real solution
| |
| 12:42 | <ogra> you said one is created during client boot
| |
| 12:42 | no, you should not need one
| |
| 12:42 | <knipwim> i thought that was the case
| |
| 12:42 | <ogra> not with recent ltsp
| |
| 12:42 | cliebow has quit IRC | |
| 12:42 | <knipwim> my current chroot build i'm using
| |
| 12:42 | is from 3 nov 2009
| |
| 12:42 | cliebow has joined #ltsp | |
| 12:42 | <ogra> it switched about a year ago
| |
| 12:42 | <knipwim> and doesn't have these problems
| |
| 12:43 | is something done to ldm in the meantime?
| |
| 12:43 | <ogra> no, its not an ldm issue
| |
| 12:44 | i thought gentoo is on the edge of things, why is your xserver that old ?
| |
| 12:44 | * ogra just checked lucid and it has 1.7.3 | |
| 12:44 | <dro> sounds like you need to update your server and chroot :)
| |
| 12:45 | <knipwim> ogra: yeah, laugh at the gentoo people :)
| |
| 12:45 | <ogra> knipwim, if you have a working chroot from nov. and a broken one thats newer, i'D suggest comparing app versions
| |
| 12:46 | specifically since you use an xserver that still needs hal and dbus look at their versions
| |
| 12:46 | the 1.7 series should already use udev/devicekit
| |
| 12:47 | i didnt laugh at you for older versions :)
| |
| 12:48 | i only laugh about gentoo people if i see them compiling half the world sometimes ... but thats been your deliberate choice :)
| |
| 12:48 | <knipwim> weird, on my working chroot i have xorg-server-1.6.3 and no hal or dbus
| |
| 12:50 | i can install the unstable 1.74
| |
| 12:51 | err, 1.7.4 xorg-server
| |
| 12:51 | * ogra checks https://launchpad.net/ubuntu/+source/xorg-server | |
| 12:52 | <ogra> i know for sure that we switched to hal input in jaunty
| |
| 12:52 | and out xorg team closely follows upstream
| |
| 12:53 | 1.7 should drop the need for hal but moves on to devicekit
| |
| 12:53 | <dro> knipwim: once booted, and the usb keyboard doens't work, try unplugging it and then plugging it back in
| |
| 12:54 | <ogra> well, that would clearly point to a kernel/udev issue if that fixed it
| |
| 12:55 | <dro> knipwim: i found this link, describes your situation
| |
| 12:55 | http://www.linuxquestions.org/questions/gentoo-87/mouse-and-keyboard-unresponsive-when-x-starts-gentoo-744261/
| |
| 12:56 | <ogra> hmm, that indicates that default gentoo doesnt build evdev
| |
| 12:57 | knipwim, do you have INPUT_DEVICES="evdev" in /etc/make.conf ?
| |
| 12:57 | and do you see evdev being used in the log
| |
| 12:59 | 1) Change make.conf and xorg.conf to use "evdev" for both mouse and keyboard. Add 'hal' and 'dbus' to global USE flags.
| |
| 12:59 | 2) Run 'emerge -uDN world' to rebuild everything to use evdev (as specified in make.conf).
| |
| 12:59 | that seems to be a proper reciepe to fix the issue
| |
| 13:00 | <knipwim> evdev is already in the make.conf
| |
| 13:00 | <ogra> though i doubt you need the mentioned xorg.conf change
| |
| 13:00 | hal will get it from the fdi file
| |
| 13:01 | <knipwim> going for the xorg-server-1.7.4 install now
| |
| 13:01 | <ogra> that might need other setting though
| |
| 13:01 | <knipwim> that should take a while
| |
| 13:01 | <ogra> hal isnt used in 1.7.4 anymore
| |
| 13:01 | <knipwim> also recompiling with event debugging on
| |
| 13:02 | <ogra> well, i'll call it a day now ... still recovering from jetlag
| |
| 13:03 | <knipwim> ogra: thanks very much
| |
| 13:03 | dro: and you
| |
| 13:04 | well replugging the usb kbd didn't work
| |
| 13:04 | <dro> ogra: i'm with you there.....my stomach is done for today
| |
| 13:11 | <vbundi> hey thanks for the help btw ogra
| |
| 13:15 | hey I noticed when this terminal is booting it looks like it's saying it's setting ramswap to 58xxxK
| |
| 13:15 | I think this terminal has either 256 or 512MB ram, I figured more would be used
| |
| 13:16 | <johnny> you don't need much to just boot and do everything
| |
| 13:16 | it's only with local apps that you actually need more memory than that
| |
| 13:16 | <vbundi> ah
| |
| 13:16 | The_Code has quit IRC | |
| 13:17 | <vbundi> I did a new client build because I screwed my old chroot up, and now I'm getting squashfs errors and memory errors etc
| |
| 13:17 | <dro> vbundi: did you update the kernels, update the image, reboot, and then update t he image again ?
| |
| 13:18 | <vbundi> didn't reboot but I did the other
| |
| 13:18 | <dro> did you move the chroot from the default location?
| |
| 13:19 | <vbundi> dro: no
| |
| 13:19 | <dro> vbundi: do just like you did before
| |
| 13:19 | <vbundi> dro: looks like my server is still running 2.6.31-17.. the new client I built is running the new 31-19 kernel
| |
| 13:19 | <dro> vbundi: update the chroot, do the kernel u pdate, update the image, reboot, then udpate the image again
| |
| 13:20 | <vbundi> alrighty
| |
| 13:24 | spectra has joined #ltsp | |
| 13:26 | dro_ has joined #ltsp | |
| 13:30 | dro has quit IRC | |
| 13:30 | dro_ has quit IRC | |
| 13:30 | dro has joined #ltsp | |
| 13:30 | <dro> vbundi: that resolve it?
| |
| 13:30 | <vbundi> dro: just trying it now
| |
| 13:33 | alkisg has quit IRC | |
| 13:33 | <vbundi> hey, if I update pxelinux.cfg/default do I need to update the image or kernel
| |
| 13:33 | it keeps losing my changes and reverting back to it's old self
| |
| 13:34 | <dro> vbundi: i already told youa bout that, the ltsp-update-kernels has a known bug that over writes the pxelinux.cfg/default when you run it
| |
| 13:35 | so you kernel update then your image update, then adjust your pxelinux.cfg/default accordingly
| |
| 13:36 | <vbundi> dro: ah I must have missed that
| |
| 13:36 | Gadi1 is now known as Gadi | |
| 13:36 | <dro> vbundi: k well now you know!
| |
| 13:36 | <Gadi> ... and knowing is half the battle...
| |
| 13:37 | <dro> Gadi: agreed...the rest is done with LIGHTSABERS!
| |
| 13:37 | lol
| |
| 13:37 | <vbundi> kids: The more you know. *Star in background*
| |
| 13:37 | alkisg has joined #ltsp | |
| 13:37 | <vbundi> ok well we'll see it's still taking a while to boot, but maybe my bootchart will make a little more sense this time
| |
| 13:38 | I screwed up my chroot last time...
| |
| 13:44 | <dro> ||||||||||/|\-----------------------------\
| |
| 13:44 | ||||||||||\|/-----------------------------/
| |
| 13:44 | lightsaber fight?
| |
| 13:50 | <vbundi> apparenlty there's something wrong with my sound?
| |
| 13:50 | http://imagebin.org/83916
| |
| 13:50 | in any event.. I've shaved over a minute off my boot time!
| |
| 13:51 | <sbalneav> !docs
| |
| 13:51 | <ltspbot> sbalneav: "docs" :: For the most current documentation, see https://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstream
| |
| 13:51 | <dro> vbundi: grats
| |
| 13:52 | GodFather has joined #ltsp | |
| 13:52 | <vbundi> dro: you'll notice i'm sittin at 4:04 still lol
| |
| 13:53 | <dro> vbundi: 4 minute boot time?
| |
| 13:53 | <vbundi> dro: yes look at the bootchart lol
| |
| 13:54 | sbalneav: are you directing me toward SOUND=false?
| |
| 13:57 | <dro> vbundi: probably but also to read the documentation
| |
| 13:57 | i've always used sound=false
| |
| 13:58 | <sbalneav> vbundi: No, I was responding to an email on ltsp-discuss, and just needed a link to the documentation :)
| |
| 13:58 | lol, sorry if you thought I was "sending you a message"
| |
| 14:00 | <Gadi> vbundi: I was actually working on a similar troubleshooting exercise over the weekend
| |
| 14:00 | vbundi: if you drop to a shell and run: ps -efw|grep udev
| |
| 14:00 | do you see multiple udevd instances?
| |
| 14:02 | <vbundi> Gadi: I will let you know when I Get back, I have to run out for a few
| |
| 14:03 | sbalneav: I wasn't offended or anything ;)
| |
| 14:03 | bbl
| |
| 14:07 | dro has quit IRC | |
| 14:45 | ogra has quit IRC | |
| 14:45 | ogra has joined #ltsp | |
| 14:46 | <cliebow> Gadi: how do i pick up exit status..or results of $answer=`dhcping -c 10.10.0.4 -s 10.10.0.3 `;
| |
| 14:47 | <Gadi> in perl?
| |
| 14:47 | <cliebow> yeah
| |
| 14:47 | <Gadi> prolly still $?
| |
| 14:47 | <cliebow> k!
| |
| 14:50 | <Lns> CAN-o-SPAM: I can't believe that expo is on the 19th...Everything under the sun is scheduled for that day, most notably the LAN party I was going to for the weekend =( So I guess I can't make it!
| |
| 14:52 | <CAN-o-SPAM> Lns: ah shoot! we'll these games better be more entertaining than tux type and tux math
| |
| 14:52 | yanu has quit IRC | |
| 14:53 | yanu has joined #ltsp | |
| 14:53 | <Lns> CAN-o-SPAM: =p I'd skip it but my sister is also going to be in town from Denver, but also it's the first LAN party with all my friends since years! it's almost like a reunion
| |
| 14:54 | CAN-o-SPAM: are you going to take any video of the lectures/etc? That would be so good to get up on YouTube or something..
| |
| 14:59 | <sbalneav> Lns: I heard that tcm-ng's shelved?
| |
| 14:59 | <Lns> sbalneav: no..? who'd you hear that from?
| |
| 15:01 | <sbalneav> Can't remember who
| |
| 15:01 | <Lns> sbalneav: we just picked up a new dev actually, we were going to start planning a gameplan. The codebase has been totally cleaned up - just not in primetime readiness yet
| |
| 15:01 | sbalneav: https://launchpad.net/tcm-ng
| |
| 15:02 | wanna join the dev team? :)
| |
| 15:02 | hersonls has quit IRC | |
| 15:03 | <sbalneav> heh, everyone needs a piece of me :)
| |
| 15:06 | <Lns> that's cuz you're so awesome!
| |
| 15:10 | <cliebow> Gadi:Thanks..Senior moment,,
| |
| 15:11 | cliebow has quit IRC | |
| 15:12 | pmatulis has quit IRC | |
| 15:21 | johnny has left #ltsp | |
| 15:23 | Dantix has joined #ltsp | |
| 15:24 | <Dantix> hi all, I can't find how to customize the screen geometry for a particular session. Can someone help me?
| |
| 15:30 | <alkisg> Dantix: for a session? Can't you use gnome-display-properties for that?
| |
| 15:32 | GodFather has quit IRC | |
| 15:33 | <Dantix> alkisg: the problem is my sessions boots direct into an RDP client, so I have not window manager running
| |
| 15:33 | <Lns> Dantix: can't you adjust your rdp client connect settings for resolution?
| |
| 15:33 | <alkisg> Dantix: and I assume you don't want to set the resolution for all sessions on that PC, just for one rdp session, right?
| |
| 15:35 | <Dantix> Lns: I suppose can, but the X screen seems to be 800x600 from the boot and that is I don't know how to change
| |
| 15:35 | alkisg: yes, I need a few session running on 1024x768 and the other on 800x600
| |
| 15:36 | <Lns> ldm.conf... x_mode_0 or something isn't it?
| |
| 15:36 | <alkisg> Dantix: and how are you planning on notifying the client to change the resolution from within the windows session?
| |
| 15:37 | Will that be a per-user setting?
| |
| 15:37 | <Dantix> alkisg: I hope if I have an X session of 1024x768 the RDP client will open its session within that resolution
| |
| 15:37 | automagically
| |
| 15:37 | <Lns> alkisg: i don't think he means 'user session' as you and i thought
| |
| 15:38 | <alkisg> Dantix: sure, but how/when will it switch to 800x600?
| |
| 15:38 | <Lns> Dantix: try adding a section in ldm.conf for that machine, with "X_MODE_0=1024x768" as an option in it
| |
| 15:39 | <alkisg> I mean, at what point is the decision of 800x600 vs 1024x768 going to be made? When the thin client boots? When the user logs on to the windows server?
| |
| 15:39 | <Dantix> alkisg: the user should not to switch manually, the session (tied to its MAC) should be boot within the resolution I want..
| |
| 15:39 | when the client boots
| |
| 15:40 | Lns: I'll try with that.. thanks
| |
| 15:40 | <Lns> np
| |
| 15:40 | <alkisg> Dantix: ah, ok, so you want all sessions on that particular client to use the same resolution.
| |
| 15:42 | <Dantix> yes
| |
| 15:42 | for me session like PC
| |
| 15:42 | or workstation
| |
| 15:44 | thank both, I'll back tomorrow with news
| |
| 15:44 | <alkisg> OK... The "modern" way to force a resolution is with XRANDR_MODE_0, but if you don't see more than 800x600, you might also have a problem with the monitor EDID settings, and you might need X_VERTREFRESH / X_HORZSYNC.
| |
| 15:45 | <Dantix> alkisg: but all that tweak must be done in which file?
| |
| 15:45 | <alkisg> !lts.conf
| |
| 15:45 | <ltspbot> alkisg: "lts.conf" :: http://manpages.ubuntu.com/lts.conf
| |
| 15:45 | <alkisg> ^^ that file
| |
| 15:45 | <Dantix> right, thanks
| |
| 15:46 | see you o/
| |
| 15:46 | Dantix has left #ltsp | |
| 15:46 | <alkisg> Good luck
| |
| 15:52 | <frederickjh> Anyone out there upgraded to Ubuntu Karmic LTSP and then set up the LTSP Cluster packages?
| |
| 15:52 | I a have a working Karmic LTSP system and am wondering about the "upgrade" path to add the LTSP Cluster packages.
| |
| 15:55 | shawnp0wers has quit IRC | |
| 15:57 | vagrantc has joined #ltsp | |
| 16:08 | <vbundi> Gadi: I've got that ps -efw|grep udev for you if you're around
| |
| 16:09 | <alkisg> vagrantc, hi, did you handle the tftpd-hpa change to /srv/tftp? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551828 It just reached Ubuntu...
| |
| 16:09 | <vagrantc> alkisg: i'm pondering switching to atftpd, honestly.
| |
| 16:10 | <alkisg> Heh!!!
| |
| 16:10 | * alkisg is thinking about using dnsmasq solely | |
| 16:10 | <vagrantc> the default upgrade path resulted in a totally broken setup
| |
| 16:10 | <alkisg> vagrantc: the most important is, on which path?
| |
| 16:10 | <vagrantc> dnsmasq is appealing as well
| |
| 16:10 | <alkisg> /var/lib/tftpboot or /srv/tftp?
| |
| 16:10 | Is the latter supposed to be fhs compliant?
| |
| 16:10 | <vagrantc> alkisg: oh, even if you get the path right, that's not necessarily enough ... i had to specify some commandline flags.
| |
| 16:11 | alkisg: yeah, it's an FHS compliance issue
| |
| 16:11 | alkisg: i did add support in ltsp-update-kernels so that it also copies to /srv/tftp if present
| |
| 16:12 | <vbundi> could I get some feedback on what is up with my boot process on this thin client? it seems as though I'm having issues with alsa
| |
| 16:12 | http://imagebin.org/83940
| |
| 16:13 | <alkisg> vagrantc: but which one's the "proposed" one for debian/ltsp for now on?
| |
| 16:13 | <vagrantc> alkisg: does it matter?
| |
| 16:14 | <alkisg> Ehm, shouldn't we have one?
| |
| 16:14 | There's a bunch of wiki pages out there, that would need to be updated
| |
| 16:14 | <Gadi> vbundi: multiple udevd?
| |
| 16:14 | <vagrantc> alkisg: ah, i see what you're saying...
| |
| 16:14 | <alkisg> I.e. "when tftpd-hpa prompts you to enter the directory, put /var/lib/tftpboot in the text box"...
| |
| 16:14 | <vagrantc> alkisg: well, honestly, i'd prefer to keep it as is.
| |
| 16:15 | alkisg: does it prompt on fresh installs?
| |
| 16:15 | <alkisg> Yup
| |
| 16:15 | <vagrantc> well, at least it does that.
| |
| 16:15 | the upgrade process is wretched ...
| |
| 16:15 | johnny has joined #ltsp | |
| 16:15 | <alkisg> vagrantc: but if there's going to be a change, then a combined LTSP 5.2 / path change / 2000 port change might be better...
| |
| 16:15 | <vagrantc> alkisg: i see
| |
| 16:15 | * vagrantc still needs to file bugs on tftpd-hpa ... | |
| 16:16 | <vagrantc> it was one of those excersizes in yak shaving that i never got around to wrapping up
| |
| 16:16 | <alkisg> Heh :D
| |
| 16:16 | <vbundi> Gadi: yea looks like it, http://pastebin.org/88508
| |
| 16:16 | <vagrantc> i fixed it enough to test LTSP, but keep forgetting to file bugs
| |
| 16:17 | <Gadi> vbundi: yeah, I was having the same issues - and it drives up CPU and memory
| |
| 16:18 | <vbundi> Gadi: I'm not sure if it's caused by the integrated sound, but I'll try disabling it and see what changes...
| |
| 16:18 | <Gadi> vbundi: I think if we can figure out the LOCALDEV and SOUND issues, we can fix the slow booting on a lot of these platforms
| |
| 16:18 | vbundi: from what I read, there are issues between the kernel 2.6.31 and udev
| |
| 16:19 | and I bet you are not on a standard intel or amd CPU, right?
| |
| 16:19 | * alkisg is already using dnsmasq in proxydhcp mode, so votes for a switch to dnsmasq :D We just drop a file in /etc/dnsmasq.d/ltsp.conf and we're done! :) | |
| 16:19 | <Gadi> are you on an NSC Geode or Transmeta?
| |
| 16:19 | <vbundi> Gadi: no it's an hp terminal running a Trasnmeta TM5700
| |
| 16:19 | Gadi: pretty standard terminal though
| |
| 16:20 | <Gadi> yeah, I bet the transmeta gets very little love from the test department
| |
| 16:20 | vbundi: the CPU is not standard at all
| |
| 16:20 | how much market share does transmeta have?
| |
| 16:20 | and how many kernel devs are testing it?
| |
| 16:20 | <vbundi> more than intel in the terminal market I bet ;)
| |
| 16:21 | <Gadi> I bet ur wrong
| |
| 16:21 | <vagrantc> alkisg: it's definitely tempting ... although tricky to determine how to drop that file there automatically without disrupting existing network setups.
| |
| 16:21 | <alkisg> Indeed. But it will provide cleaner upgrades in the future.
| |
| 16:22 | <vagrantc> alkisg: at least on debian, it requires the sysadmin to add a one-liner to the dhcp configuration ... i guess i could do the same with dnsmasq.
| |
| 16:22 | <vbundi> What does intel put in thin clients anyways, Atoms are really the first thing thats got into the ULV market right?
| |
| 16:23 | <Gadi> vbundi: prolly more atom cpus out there than transmeta
| |
| 16:24 | * vagrantc hasn't heard transmeta mentioned for 6 or so years | |
| 16:24 | <vbundi> Gadi: yeah I can't really say for sure, I mean... atoms have been around for 2 years and they're extremely popular
| |
| 16:25 | Gadi: but I mean.. there are boatloads of these thin clients out there from a lot longer than 2 years ago, you'd think the support would be there
| |
| 16:25 | <Gadi> for the brand new kernel?
| |
| 16:25 | :)
| |
| 16:29 | <vbundi> Gadi: yeah well geeze, can't it just work? ;D
| |
| 16:33 | what do you guys recommend for cost effective terminals nowadays then?
| |
| 16:34 | etyack has quit IRC | |
| 16:34 | <Gadi> vbundi: oh, we'll make it work
| |
| 16:34 | :)
| |
| 16:35 | vbundi: have you ever taken a liveCD to that thing?
| |
| 16:35 | ie a karmic livecd
| |
| 16:35 | to see if it takes long to boot?
| |
| 16:37 | mushroomtwo has joined #ltsp | |
| 16:37 | <vbundi> hmm no, they don't have CD-roms actually.. I suppose I could boot it with a usb drive
| |
| 16:37 | mushroomblue has quit IRC | |
| 16:39 | <vagrantc> how does ubuntu's alsa detect that you're using remote pulseaudio support?
| |
| 16:39 | when logged in from an ltsp client?
| |
| 16:40 | <Gadi> vagrantc: .asoundrc or some such
| |
| 16:40 | <vagrantc> Gadi: the ~/.asoundrc ?
| |
| 16:40 | <Gadi> yeah
| |
| 16:40 | it makes pulseaudio a virtual sound device
| |
| 16:41 | <vagrantc> on debian, i have the instructions to use /etc/asound.conf ... though that doesn't work for servers. although there's a nice way to support that with environment variables.
| |
| 16:41 | <Gadi> pcm.!default { type pulse }
| |
| 16:41 | ctl.!default { type pulse }
| |
| 16:41 | something along those lines
| |
| 16:41 | <vagrantc> yeah, that's what i have in the instructions for debian's sound support
| |
| 16:42 | though not on a per-user basis ... ?!
| |
| 16:42 | what tweaks ~/.asoundrc ?
| |
| 16:44 | i'm thinking i'd like to add hooks to ldm to set some environment variables, so that there's less to tweak server-side.
| |
| 16:45 | <Gadi> Im not sure what ubuntu does these days
| |
| 16:46 | I know a few versions ago, we had an Xsession.d/ script on the server
| |
| 16:46 | <vagrantc> yeah, i included that in debian until i realized it relied on patches to one of the alsa packages that weren't in debian
| |
| 16:46 | <Gadi> but, yeah, an env var is most welcome
| |
| 16:47 | but, be sure to make it depend on SOUND_DAEMON setting
| |
| 16:48 | and also be sure to set the local env vars accordingly for localapps
| |
| 16:48 | <vbundi> Gadi: 5+ minutes and counting on a 9.10 liveusb
| |
| 16:49 | <vagrantc> Gadi: debian-edu is using this: http://svn.debian.org/wsvn/debian-edu/trunk/src/debian-edu-config/etc/asound.conf
| |
| 16:49 | Gadi: in conjunction with this: http://svn.debian.org/wsvn/debian-edu/trunk/src/debian-edu-config/etc/X11/Xsession.d/15debian-edu-ltsp
| |
| 16:49 | Gadi: but i'd like to drop the second bit, and just set the variable from LDM
| |
| 16:50 | <Gadi> vbundi: great news! that means it is out of the realm of our LTSP scripts
| |
| 16:50 | :)
| |
| 16:51 | * vagrantc hands Gadi a brew for passing the buck | |
| 16:51 | <Gadi> hehe
| |
| 16:52 | mushroomblue has joined #ltsp | |
| 16:52 | <Gadi> no, its just another example of where we ltsp folks have to step in and fix the problems the rest of the linux world leaves behind
| |
| 16:52 | :)
| |
| 16:52 | <vagrantc> Gadi: so, the tricky part of setting ALSA_DEFAULT_PCM from LDM is if they're not using that ...
| |
| 16:52 | <Gadi> which is why we accumulate so many hacks and workarounds
| |
| 16:52 | <vagrantc> if they're not using LDM ... i guess nothing will go wrong ...
| |
| 16:52 | mushroomtwo has quit IRC | |
| 16:52 | <vagrantc> er, if they're not using ALSA
| |
| 16:53 | <Gadi> vagrantc: well, so you still have a server side tweak
| |
| 16:53 | frederickjh has quit IRC | |
| 16:53 | <Gadi> the only reason those vars are honored is because of the asound.conf
| |
| 16:53 | <vagrantc> if they've got some wacky alsa setup though, we might have to make all kinds of tweaks anyways...
| |
| 16:54 | Gadi: ah, true enough ... it requires some server-side tweaking, that they could do something with if they didn't like our reasonable defaults.
| |
| 16:54 | <Gadi> now, if you could set the location of asoundrc with an env var,
| |
| 16:55 | <vagrantc> then we could really abuse XDG_DATA_DIRS to the max!
| |
| 16:55 | <Gadi> you could have your own asoundrc in a tmp dir that supercedes the one in home
| |
| 16:55 | :)
| |
| 16:55 | speaking of which, we should have a LOCAL_APPS_MENU_FORCE option
| |
| 16:55 | <vbundi> Gadi: is there anything I can do to help?
| |
| 16:56 | <vagrantc> well, i think i'm going to split up ldm-trunk/rc.d/X95-run-x-session into a few more pieces and tweak the sound stuff a little.
| |
| 16:56 | <Gadi> which would remove conflicting entries oin a user's homedir
| |
| 16:56 | vbundi: well, you could try removing ltspfsd from the chroot
| |
| 16:57 | and seeing if that speeds things up
| |
| 16:57 | <vagrantc> Gadi: that'll just cause clever people to use a different desktop filename :)
| |
| 16:57 | and most people to feel the authoritarian hand
| |
| 16:57 | <Gadi> vagrantc: we don't ddesign around clever people
| |
| 16:57 | :)
| |
| 16:57 | <vagrantc> we design for the weak willed!
| |
| 16:58 | <Gadi> we respect clever people, by not preventing them from cleverly working around an authoritarian system
| |
| 16:58 | :)
| |
| 16:58 | * vagrantc hands Gadi another brew | |
| 16:59 | GodFather has joined #ltsp | |
| 17:03 | <vbundi> Gadi: removing ltspfsd will break everything else won't it?
| |
| 17:04 | <Gadi> vbundi: does it allow you to just remove ltspfsd?
| |
| 17:05 | <vbundi> no ltsp-client depends on it
| |
| 17:05 | unless I do dpkg --force or something
| |
| 17:05 | <Gadi> if not, try just renaming /opt/ltsp/i386/lib/udev/ltspfs_entry
| |
| 17:06 | to something else
| |
| 17:06 | and updating the image
| |
| 17:06 | <vbundi> k
| |
| 17:06 | <Gadi> that should cause the boot to go much faster, based upon your bootchart with all of the udev calls to ltspfs_entry
| |
| 17:07 | now, that won't necessarily tell us why there are so many udev calls, but it is a place to start
| |
| 17:08 | * Gadi thinks he read about a udevadm call that we can make in the initramfs to limit the number of udevd children spawned | |
| 17:08 | <Gadi> funny how there's even birth control for udevd these days
| |
| 17:08 | :)
| |
| 17:14 | <vagrantc> Gadi: you think it's a good idea or a bad idea to split out all the environment variable setting in ldm-trunk/rc.d/X95-run-x-session into separate hooks?
| |
| 17:16 | * Gadi looks... | |
| 17:16 | <vagrantc> it's a few more filesystem calls, but allows for a little more flexibility to insert something in between each setting of variables...
| |
| 17:17 | i think i'd at the very least split it into one hook that sets the variables, and another that actually does something
| |
| 17:20 | <Gadi> well...
| |
| 17:20 | hmm...
| |
| 17:21 | you can still insert your own stuff right now
| |
| 17:21 | just by setting CLIENT_ENV
| |
| 17:22 | and at least this way, the core stuff is all self-contained
| |
| 17:22 | <vagrantc> Gadi: but not conditionally ...
| |
| 17:22 | <vbundi> Gadi: that's more like it! 2:11 http://imagebin.org/83960
| |
| 17:22 | <vagrantc> Gadi: i.e. you can't set a variable based on the detected value of SOUND_DAEMON or some such
| |
| 17:22 | <Gadi> vagrantc: sure you can, with just an earlier script that is sourced
| |
| 17:22 | sure you can
| |
| 17:22 | make an X94-myscript
| |
| 17:23 | that does:
| |
| 17:23 | [ "$SOUND_DAEMON" = "pulse" ] && CLIENT_ENV="$CLIENT_ENV foo"
| |
| 17:23 | <vagrantc> Gadi: the sound handling code has: if [ -z "$SOUND_DAEMON" ]; then SOUND_DAEMON=pulse ...
| |
| 17:23 | <vbundi> I'm out till tomorrow, thanks for all the help
| |
| 17:23 | <Gadi> oh, I see, you cant override what is there, you mean
| |
| 17:24 | <vagrantc> Gadi: yes.
| |
| 17:24 | <Gadi> vbundi: great!
| |
| 17:24 | btw
| |
| 17:24 | :)
| |
| 17:24 | vbundi: see, we know the problem but not the cause
| |
| 17:24 | <vbundi> yeah If you want more help with testing I'll be glad to do so tomorrow
| |
| 17:25 | <Gadi> vbundi: always happy to have testers
| |
| 17:25 | :)
| |
| 17:25 | thanks for helping to prove that "slow hardware" is not necessarily the cause of "ltsp's bloat"
| |
| 17:25 | :)
| |
| 17:25 | LTSP 4.2 just didn't use udev
| |
| 17:25 | or, well, not today's udev
| |
| 17:26 | vagrantc: how do you propose to code it with overrides?
| |
| 17:26 | vagrantc: wothout removing a file from the package/
| |
| 17:27 | <vagrantc> Gadi: move all the variable setting to X90-*, to give room to break everything before X95-*
| |
| 17:28 | <Gadi> ok
| |
| 17:28 | while ur at it, maybe you can come up with better var names than MY_SOUND
| |
| 17:28 | :)
| |
| 17:28 | <vagrantc> heh. i just realized that i can't test if my new patches are working with virtual thin clients on the same machine as the virtual ltsp server...
| |
| 17:30 | * vagrantc disables sound support on the server. | |
| 17:31 | <vagrantc> Gadi: maybe i'll just make my tweak for ALSA_DEFAULT_PCM and be happy.
| |
| 17:31 | <Gadi> hehe
| |
| 17:31 | slacker
| |
| 17:32 | meanwhile, I think I am about to set out on a quest to prove that ltsp5 can indeed work on low end clients
| |
| 17:33 | as long as we workaround the real issues
| |
| 17:33 | <vagrantc> heh
| |
| 17:33 | without features, we can boot at any speed we want!
| |
| 17:33 | <Gadi> ie, if you set SCREEN_07=shell and it takes 4 minutes to get there, it aint the features
| |
| 17:34 | the problem's not the features, its all these new systems that they move to
| |
| 17:34 | that work great in limited situations
| |
| 17:34 | XuzhouJim has joined #ltsp | |
| 17:34 | <Gadi> but are left untested in many cases
| |
| 17:35 | "I sped up performance, but I set my timeouts so short that on slow hardware, it spawns a million procs and makes things even slower!"
| |
| 17:35 | <vagrantc> i wonder if instead of using ALSA_DEFAULT_PCM i should use LTSP_ALSA_PCM or some such ...
| |
| 17:37 | <johnny> Gadi, considered rebuilding everything against a different c lib?
| |
| 17:37 | <vagrantc> LTSP_ALSA_DEFAULT ...
| |
| 17:37 | <alkisg> Gadi: my 500 mhz / 64 ram clients boot on 1:10. I think that's fine..
| |
| 17:37 | <Gadi> johnny: gentoo's ur domain
| |
| 17:37 | :)
| |
| 17:38 | alkisg: ever done a bootchart?
| |
| 17:38 | <johnny> Gadi, no.. i mean like finding an existing maintained rebuild of ubuntu packages against a different c lib..
| |
| 17:38 | <alkisg> Gadi, nope...
| |
| 17:38 | <johnny> Gadi, i can't even run gentoo on this machine.. too old
| |
| 17:38 | <alkisg> Doesn't ubuntu does that for lucid :D
| |
| 17:38 | <johnny> 5 year old laptop
| |
| 17:38 | i mean i can.. it's just too slow to install packages
| |
| 17:38 | tha'tts why i use fedora
| |
| 17:39 | <Gadi> I am just saying, before we jump to "we need a smaller image" or "we need fewer services" or "we need a different distro", we should actually scientifically figure out the problem
| |
| 17:39 | it was like when we tackled video way back when
| |
| 17:40 | everybody had theories on why playing movies on the LTSP server may have issues
| |
| 17:40 | none of which were founded in reality
| |
| 17:40 | :)
| |
| 17:40 | alkisg's the PhD here - he knows where Im coming from
| |
| 17:40 | :)
| |
| 17:41 | <alkisg> :D
| |
| 17:41 | <vagrantc> oh no, science!
| |
| 17:42 | next thing people will be calling for is testing code before uploading!
| |
| 17:42 | <Gadi> as soon as we *demonstrated* the lack of sync between video and audio caused most of the problems and *demonstrated* that playing with "-ao null" allowed fullscreen video with no degradation
| |
| 17:42 | * alkisg is waiting for Gadi to bring up the big formulas... | |
| 17:42 | <johnny> Gadi, go ahead
| |
| 17:42 | fix it
| |
| 17:42 | <Gadi> ... we were able to show how moving from ESD to pulse along with LDM_DIRECTX could resolve most of the bottleneck
| |
| 17:42 | <johnny> i don't care.. my stuff is fine :)
| |
| 17:42 | <Gadi> hehe
| |
| 17:43 | spoken like a true member of the FOSS
| |
| 17:43 | <johnny> as long as it doesn't get worse, i'm OK :)
| |
| 17:43 | <Gadi> community
| |
| 17:43 | <johnny> Gadi, well.. it would help if i had more than 3 terminals
| |
| 17:43 | i don't have lots of requirements for ltsp ...
| |
| 17:43 | no speakers even
| |
| 17:44 | <vagrantc> all it needs to do is handle a few disasterous coffee spills, and you're set.
| |
| 17:44 | <johnny> as long as people can use firefox/openoffice/solitaire
| |
| 17:44 | it's all there
| |
| 17:44 | mfdutra has joined #ltsp | |
| 17:44 | <johnny> flash sucks still
| |
| 17:44 | but that's not your fault
| |
| 17:44 | or ltsps fault
| |
| 17:45 | <Gadi> well, we'll try to break your 3 terminals before lucid
| |
| 17:45 | :)
| |
| 17:46 | <mfdutra> hello. who writes /tmp/ldm-logout-action ?
| |
| 17:46 | I never get it written
| |
| 17:47 | <alkisg> mfdutra: I think that moved to /var/run... what version are you using?
| |
| 17:47 | <vagrantc> mfdutra: what version of ldm? newer versions write to /var/run/ldm-logout-action
| |
| 17:47 | <mfdutra> 2:2.0.48-0ubuntu1
| |
| 17:47 | I can't find either
| |
| 17:48 | well, maybe ldm is writing there and when it starts over, it deletes the file... dunno
| |
| 17:50 | <Gadi> g'night guys
| |
| 17:50 | Gadi has left #ltsp | |
| 17:50 | <alkisg> g'night from me too :)
| |
| 17:50 | <vagrantc> mfdutra: the files in /opt/ltsp/i386/usr/share/ldm/rc.d/ is where to look for the code
| |
| 17:50 | <mfdutra> so did I
| |
| 17:51 | alkisg has quit IRC | |
| 17:51 | <mfdutra> I can only see a reference to it in X99-zzz-logout-action
| |
| 17:51 | but that's where it reads the file, not writes
| |
| 17:52 | <vagrantc> ah, right ...
| |
| 17:52 | <mfdutra> I grepped all the ldm code also
| |
| 17:52 | <vagrantc> mfdutra: you need to use a custom .desktop file
| |
| 17:52 | <mfdutra> uh?
| |
| 17:53 | XuzhouJim has quit IRC | |
| 17:53 | <vagrantc> the desktop file created /tmp/ldm-logout-action and called gnome-session --logout or whatever it was called
| |
| 17:53 | <mfdutra> hmm
| |
| 17:53 | people logout through the indicator-applet-session
| |
| 17:53 | <vagrantc> ltsp-trunk/localapps/doc/examples/*.desktop
| |
| 17:54 | the new way, if the patches make it into gnome-session, will "just work".
| |
| 17:54 | <mfdutra> hmm
| |
| 17:55 | <vagrantc> and wouldn't be hard to backport the functionality... it's just two files to drop into place
| |
| 17:56 | but still requires a custom .desktop file or support built-in to gnome-session (or whatever calls your logout action)
| |
| 17:57 | <mfdutra> gnome-session could have an exit status for logout or reboot
| |
| 17:57 | <vagrantc> if it does, it should be easy to write a wrapper script
| |
| 17:57 | <mfdutra> yup
| |
| 17:58 | I'll check what that indicator thing fires when the user clicks on it
| |
| 18:05 | <vagrantc> i tried to do something similar with lxde-logout, ended up filing a bug
| |
| 18:12 | CAN-o-SPAM has quit IRC | |
| 18:42 | mfdutra has quit IRC | |
| 18:48 | vagrantc has quit IRC | |
| 19:05 | rjune has quit IRC | |
| 19:46 | Lns has quit IRC | |
| 20:16 | <sbalneav> Who here knows enough about irc to remove this registration thing
| |
| 20:16 | freenode's upgraded, I say we take it off
| |
| 20:17 | slidesinger has joined #ltsp | |
| 20:22 | <sbalneav> sigh, I can't remember how to get ops
| |
| 20:22 | it's /msg chanserv sommatorother
| |
| 20:22 | ChanServ sets mode: +o sbalneav | |
| 20:23 | <sbalneav> ah
| |
| 20:36 | Uuuuugh
| |
| 20:38 | Anyone know how to remove this /mode +q $~a
| |
| 20:39 | I see lots of information on how to add things to the quiet list, none on how to remove 'em
| |
| 20:42 | sbalneav sets mode: -q $~a | |
| 20:43 | <sbalneav> Ooooh
| |
| 20:43 | think I did it.
| |
| 21:00 | loather-work has quit IRC | |
| 21:02 | loather-work has joined #ltsp | |
| 21:09 | GodFather has quit IRC | |
| 22:05 | jhutchins has quit IRC | |
| 22:07 | jhutchins_lt has quit IRC | |
| 22:10 | daya_ has joined #ltsp | |
| 22:19 | rjune has joined #ltsp | |
| 22:20 | Faithful has quit IRC | |
| 22:42 | daya_ has quit IRC | |
| 22:52 | shogunx has quit IRC | |
| 22:54 | shogunx has joined #ltsp | |
| 22:58 | Lns has joined #ltsp | |
| 23:11 | Lns has quit IRC | |
| 23:13 | johnny has left #ltsp | |
| 23:14 | Lns has joined #ltsp | |
| 23:16 | johnny has joined #ltsp | |
| 23:47 | yanu has quit IRC | |