[00:00] <stgraber> HedgeMage: getting whitelisted can be done by opening a ticket at: https://launchpad.net/launchpad/+addquestion if we don't get it done quick enough, feel free to poke me and I'll nag the right people ;)
[00:03] <alkisg> stgraber: I'm thinking of proposing a patch for 000-daemon-handling to also handle initctl of the upstart package, because I think it's the new acpid script that's using $ROOT/proc at the end of ltsp-build-client... is that OK?
[00:03] <alkisg> (Hi all, btw :))
[00:05] <alkisg> Debian is also (slowly) switching to upstart, so that script would be again common, right?
[00:06] <stgraber> alkisg: yeah, you'll probably need to verwrite initctl, start, stop, restart and status (assuming all these aren't simple symlink to initctl)
[00:06] <alkisg> symlinks, so initctl should be enough
[00:06] <stgraber> ok, they are symlinks to initctl ;)
[00:06] <stgraber> right, sounds good
[00:06] <alkisg> But it won't have the same name, so I'll have to call it with initctl.real $action "$@"
[00:07] <alkisg> OK, will do that tomorrow, thanks
[00:07] <alkisg> *tommorow
[00:07] <stgraber> well, I'm wondering why we actually have to overwrite the binary ...
[00:07] <HedgeMage> stgraber: thanks, I'll file it away and take a look as soon as I can.
[00:08] <stgraber> stgraber@castiana:~$ initctl() { echo "It's not really initctl"; }
[00:08] <stgraber> stgraber@castiana:~$ initctl blah
[00:08] <stgraber> It's not really initctl
[00:08] <stgraber> alkisg: ^
[00:08] <alkisg> stgraber: what if some C program tries to execute /sbin/initctl?
[00:09] <alkisg> (or shell program, with an absolut path /sbin/initctl...)
[00:09] <stgraber> alkisg: they shouldn't, upstart uses dbus for communication and library exists for C programs, initctl is only there for shell scripts.
[00:09] <stgraber> yeah, calling with the full path is the only case where doing shell function overwrite won't work
[00:09] <alkisg> Oooops so if someone uses dbus to start acpid, we can't block it?
[00:09] <stgraber> but I don't know if we have any scripts doing that
[00:10] <stgraber> alkisg: indeed
[00:10] <alkisg> So we probably *need* umount -l to be safe... :-/
[00:10] <alkisg> ...or at the very least, to exclude /proc from the squashfs line
[00:11] <stgraber> alkisg: I did a quick check, on my laptop I don't have any software that's calling start/stop/restart or start-stop-daemon with a full path
[00:11] <stgraber> alkisg: well, then the issue is that we are actually starting process inside the chroot that should never have started
[00:12] <alkisg> Well, if they're started from a postinst script, what else can we do?
[00:12] <stgraber> alkisg: so ideally we should have: function overwrite for start/stop/restart/start-stop-daemon + kill all process started from within the chroot + umount -l
[00:12] <stgraber> then we'd be safe
[00:12] <alkisg> stgraber: I think dpkg-divert is a little safer, because it also helps *after* the ltsp-build-client script, i.e. when the user wants to update his chroot
[00:12] <alkisg> export LTSP_HANDLE_DAEMONS=false, chroot, update etc
[00:13] <alkisg> (but I'd prefer it if LTSP_HANDLE_DAEMONS was "autodetected", so that it worked automagically...)
[00:14] <stgraber> alkisg: right, though I'd be very very careful with initctl as I'd suspect it gets copied to the initrd and so you may end up with a non booting thin client
[00:14] <alkisg> Ooops :(
[00:14] <stgraber> it's one thing to override a Debian helper software (start-stop-daemon), it's another to overwrite some part of init ;)
[00:15]  * alkisg thinks it would be safer if he left this for stgraber, and just did the umount -l / squashfs etc stuff :D
[00:17] <stgraber> root@ltsp-root01:~# ls -l /proc/[0-9]*/exe | grep "/opt/ltsp/" | awk '{print $8}' | cut -d / -f3
[00:17] <stgraber> replacing /opt/ltsp by $CHROOT
[00:17] <stgraber> that'll list you all remaining process running from the chroot, you can then kill them and /proc will unmount just fine
[00:18] <stgraber> that's probably the easiest until upstart starts causing us more issues
[00:18] <stgraber> ls -l /proc/[0-9]*/exe | grep $CHROOT | awk '{print $8}' | cut -d / -f3 | xargs kill -9
[00:19]  * alkisg is thinking where that would fit best...
[00:19] <stgraber> ls -l /proc/[0-9]*/exe | grep $CHROOT | awk '{print $8}' | cut -d / -f3 | xargs kill -9 2>/dev/zero || true
[00:19] <stgraber> actually ;)
[00:19] <alkisg> Right now, and excluding the fat client script, ltsp-update-image is what unmounts $ROOT/proc first
[00:19] <stgraber> as if we don't have any process to kill we don't want ltsp-build-client to fail
[00:20] <stgraber> ok, ltsp-update-image would make sense
[00:20] <stgraber> as you also want all process to be killed before compressing an updated chroot
[00:20] <alkisg> But then again, ltsp-update-image could be modified to not bother with $ROOT/proc at all, and just exclude that directory from the squashfs image
[00:20] <stgraber> yeah but usually you don't want a second cron running on your system ;)
[00:21] <alkisg> Uhm care to clarify that?
[00:21] <alkisg> I mean for ltsp-update-image to pass an "exclude /proc" param to squashfs
[00:21] <stgraber> if you update your chroot and get a cron update which uses upstart, it'll update cron inside the chroot and start it
[00:21] <stgraber> so if you do a ps aux, you'll see two cron running
[00:22] <stgraber> one inside the chroot, one outside
[00:22] <stgraber> so even if you ignore /proc when doing the squashfs, you still end up with two cron running on your server
[00:22] <stgraber> which can't be good ;)
[00:22] <stgraber> umount -l and mksquashfs -e only workaround the fact that you have some process running that shouldn't be running
[00:23] <alkisg> Well, that problem would also be faced by someone who doesn't use nbd/ltsp-update-image
[00:23] <stgraber> so that fixes the issue of compressing the squashfs but not the fact that you have some process running from within the chroot and that should never happen
[00:23] <stgraber> indeed and we won't be able to do much for them
[00:24] <stgraber> what we can do is call that command line once at the end of ltsp-build-client and in ltsp-update-image
[00:24] <alkisg> "ltsp-enter-chroot" "ltsp-exit-chroot" commands would be helpful :D
[00:24] <stgraber> so for nbd users that will be working perfectly and for NFS users, that'll be fine during the chroot build process but they'll need to be careful when updating
[00:25] <alkisg> OK, I'll try to put that in ltsp-update-image
[00:26] <alkisg> I'll also try to bypass the daemon starting by defining an initctl in the fat client script
[00:26] <alkisg> Thanks man :)
[00:26] <stgraber> ok, if you use the shell hack, remember that you'll need to also define start, stop and restart
[00:26] <stgraber> even if they are symlinks
[00:27] <alkisg> OK, I'll try them and see if they work
[02:20] <sbalneav> evening all
[02:29] <stgraber> evening sbalneav
[03:03] <sbalneav> Hmmm, new pulseaudio seems flaky
[03:03] <sbalneav> At least, I think it's pulse.
[03:04] <stgraber> volume mixer was a bit broken here and video playback got a bit laggy afterwards (as if audio couldn't catch up with video and mplayer would drop frames to sync)
[03:04] <stgraber> so I reverted to the previous version for now
[03:05] <sbalneav> When I play a game under Wine, pulse disappears entirely
[03:05] <sbalneav> it's still running, but only shows the dummy device.
[03:15] <Ahmuck> thank goodness pulse is getting tested ...
[03:25] <sbalneav> Ahmuck: Anything else you'd like tested?
[03:26] <Ahmuck> i deserved that
[03:27] <sbalneav> The sniping's getting a little annoying, quite frankly.
[03:27] <sbalneav> If you've got a complaint, I wish you'd make it plain.
[03:27] <sbalneav> So we can deal with it, and move on.
[03:29] <Ahmuck> so there is a pulse issue in edubuntu?
[03:29] <sbalneav> There's a pulse issue, period.
[03:29] <Ahmuck> nm
[03:30] <sbalneav> Pulse is a great peice of software, but like all peices of software, it has bugs.
[03:30] <Ahmuck> sorry, i need a break for a while
[03:31] <sbalneav> You know, Ahmuck's passive-agressive baloney's really getting to be a nuisance.
[03:32] <sbalneav> If he has a complaint about something, I sure wish he'd just make the complaint, we could deal with the complaint, and move on.
[03:32] <sbalneav> Instead, he just makes vague hints and sarcastic remarks.
[03:54] <stgraber> yeah ... it's getting boring
[04:55] <CarlitoI3rigante> is anyone live?
[04:55]  * CarlitoI3rigante shout for a live person
[04:59] <dhillon-v10> CarlitoI3rigante, that's a tough question ;)
[05:11] <sbalneav> CarlitoI3rigante: Hello
[05:21] <HedgeMage> I'm alive.  Awake is debatable, but I'm definitely alive.
[05:22] <dhillon-v10> HedgeMage, hi there :) I thought you were going to sleep :P
[05:23] <HedgeMage> Yeah, that didn't happen...well, sort of...I dozed off cuddling in front of a movie with LF, almost ruined dinner, rescued dinner, ate dinner, played with a treasure I found while unpacking, and now can't sleep.
[05:23] <dhillon-v10> HedgeMage, nice :)
[05:24] <HedgeMage> heh
[05:24] <HedgeMage> On the up side, there's something incredibly relaxing about typing on a good manual typewriter.
[05:24] <HedgeMage> I love computers, but they can't come close to that sound and feel.
[05:25]  * HedgeMage gets all nostalgic and makes people think she's crazy.
[05:29] <dhillon-v10> HedgeMage, gotta go, bye and good night :)
[05:31] <HedgeMage> Good night
[05:31] <HedgeMage> oops, too late
[05:32] <crimsun> sbalneav: which version of pulseaudio are you using?
[05:33] <crimsun> sbalneav: the fixed one is 1:0.9.22~0.9.21+stable-queue-24-gfa64-0ubuntu1
[05:38] <sbalneav> 1:0.9.22~0.9.21+stable-queue-24-gfa64-0ubuntu1
[05:38] <sbalneav> crimsun: ^^^
[05:39] <crimsun> sbalneav: what sort of behaviour?
[05:39] <crimsun> sbalneav: also, a verbose PA log might help debug (https://wiki.ubuntu.com/PulseAudio/Log)
[05:40] <sbalneav> Well, I've got an old windows game I like to play from time to time (homeworld), and after I play it, pulse kind of... stops responding.
[05:40] <sbalneav> crimsun: Ah, thanks, I'll maybe produce a log.
[05:40] <crimsun> sbalneav: so this is using Wine /without/ Neil's Winepulse ppa, I presume
[05:41] <sbalneav> Yes.
[05:41] <crimsun> sbalneav: and otherwise all completely current 10.04?
[05:41] <sbalneav> yup.
[05:41] <sbalneav> I updated an hour or so.
[05:41] <crimsun> yes, a verbose log would be helpful
[05:41] <sbalneav> Okiedokie, I'll produce one tomorrow.
[05:41] <crimsun> thanks
[05:42] <sbalneav> I was trying to find something else I could make it die with
[05:42] <crimsun> try anything using alsa
[05:42] <sbalneav> Since "Dies on playing a windows game produced in 1999 under wine" isn't a use case that'll get taken too seriously :)
[05:42] <crimsun> i.e., anything that would route through the pulse pcm+ctl alsa-plugin
[05:42] <sbalneav> ok, will do.
[05:43] <crimsun> my most simple tests are speaker-test, ogg123, and mpg123
[05:44] <sbalneav> ogg123's a good one.  I got oodles of oggs. I'll try that.
[05:44] <sbalneav> Thanks!
[21:41] <alkisg> Hmmm dpkg-reconfigure edubuntu-artwork gives 3 choices: default, young, and plain. Would it be possible to also have an "ubuntu" choice there? :)
[21:43] <alkisg> Or, could we modify "plain" to use the ubuntu icons instead of the gnome icons, etc?
[21:43] <alkisg> Relevant files are in /usr/share/edubuntu-artwork/gconf
[22:00] <alkisg> Maybe the best thing to do would be to lower "atomix, edubuntu-artwork, gnome-icon-theme-gartoon, khelpcenter4, kolourpaint4, xaos" from "Depends:" to "Recommends:" in edubuntu-desktop.
[22:00] <alkisg> This way if someone doensn't want one of those, he can still keep the rest of the edubuntu-desktop.
[22:12] <sbalneav> alkisg: Makes sense
[22:13] <alkisg> OK, filed there: https://bugs.launchpad.net/ubuntu/+source/edubuntu-meta/+bug/508923