[04:23] <alkisg> Good morning
[04:23] <HedgeMage> hi :)
[04:25] <stgraber> oh, it's already this late ? ;)
[04:28] <HedgeMage> yes, sadly it is
[04:28] <HedgeMage> (creeping up on midnight here)
[04:30] <alkisg> stgraber: do I have 1 hour before you tag ltsp? I think that "tasksel failed because aptitude returned 100" is a file descriptor problem, and actually means "aptitude returned 100% completed", so I'm just now testing ltsp-build-client to see if it's safe to ignore it at least for now...
[04:31] <stgraber> alkisg: you have a bit more than that, I did a lot of changes today in ltsp-trunk and ldm-trunk, so I'll wait until tomorrow (late morning / early afternoon) to tag + upload
[04:31] <alkisg> Ah, perfect :)
[04:31] <stgraber> I merged that nbd-proxy bit and implemented some initial caching for ltsp_config + some other stuff I had laying around
[04:32] <alkisg> stgraber: what's the easiest way for me to test your commits?
[04:32] <alkisg> I.e. to make a local ubuntu package out of the bzr branch?
[04:32] <stgraber> alkisg: I have an updated ltsp in my PPA (bzr snapshot), I can update it with what's currently in trunk so you can easily test it
[04:32] <stgraber> give me 2 minutes
[04:33] <alkisg> Merci :)
[04:33] <stgraber> sorry, don't know the greek for no problem ;)
[04:33] <alkisg> :D (or if you could tell me how you do the bzr => ubuntu package thing, I can do it on my own here...)
[04:34] <stgraber> I usually use mkdst (that tool we use to tag/release ltsp) to build me a new tarball, then rename it to mention it's a snapshot and include the bzr revision and make sure the version number is lower than the next upstream version
[04:35] <crimsun> ok, seed time
[04:35] <alkisg> Thanks, I'll put "learn how mkdst works" in my TODO list :)
[04:35] <stgraber> so, for the one I'm doing, it's: ltsp_5.1.99~bzr1517.orig.tar.gz
[04:35] <crimsun> (now that I've closed 76 bugs with the latest upload)
[04:35] <alkisg> crimsun: hi, will we see that libsdl-pulse inclusion any time soon?
[04:36] <stgraber> crimsun: that's a lot of bugs :)
[04:36] <alkisg> wow, 76 bugs, yeah...
[04:36] <crimsun> alkisg: that's the seed thing mentioned above
[04:36]  * alkisg dances :)
[04:37] <stgraber> alkisg: new snapshot build for ltsp, uploaded.
[04:37] <stgraber> alkisg: I'll do one for ldm too or you'll have some issue getting to ldm
[04:37]  * alkisg thinks Lucid will be the best Ubuntu version ever :)
[04:37] <alkisg> stgraber: the nbd-client patch I reported? don't worry I have a local patch for it here...
[04:38] <alkisg> *bug
[04:38] <stgraber> alkisg: not only that, nbd-proxy makes nbd-client connect to localhost, so it's introducing a lot of other issues ;)
[04:39] <alkisg> Oooh ok, waiting for your ppa upload then
[04:41] <stgraber> uploaded
[04:42] <stgraber> alkisg: you should have both built in an hour or so, the builders seem a bit slower now than they were this afternoon
[04:43] <stgraber> alkisg: I also uploaded a new ltspfs but this one was uploaded directly to archive, not to my PPA (it's an actual release, not a snapshot)
[04:43] <alkisg> Btw, here's what I'll be commiting in a few hours. It has "TODOs" in it, but I think it works better than the last version. I'll debug those in the next few days.
[04:43] <alkisg> http://ltsp.pastebin.com/m20e9470
[04:44] <alkisg> stgraber: ok, I'll be trying all those in the next few hours
[04:44] <stgraber> are you sure your tasksel works correctly "
[04:44] <stgraber> ?
[04:44] <alkisg> I'm testing as we speak
[04:45] <stgraber> I'd have done: chroot $ROOT "tasksel install $desktop || true"
[04:45] <alkisg> Ooops
[04:45] <alkisg> dammit
[04:46] <stgraber> also, AFAIK that APT_GET_OPTS isn't actually part of apt's environment, it's something we usually append to an apt-get command and I don't see one in your script, not sure it's actually doing anything ;)
[04:46] <alkisg> I was fiddling with tty handling a while ago, and I saw tasksel's gui (whiptail) going to 100%, and right after that "aptitude failed (100)"
[04:46] <alkisg> So I'm beginning to think it's a descriptor/return value interpretation problem
[04:46] <stgraber> and IIRC I actually have a plugin writting a file in /etc/apt/conf.d/ to do the same as --no-install-recommends, so you may want to get rid of it too
[04:47] <alkisg> APT_GET_OPTS is used later on to write the "recommends" stuff to apt.conf.d
[04:47] <alkisg> So I remove "recommends" to prevent it from being written to apt.conf.d
[04:47] <stgraber> oh, interesting, I forgot I actually checked for that variable before writting apt.conf.d ;)
[04:47] <alkisg> :)
[04:48] <stgraber> btw, that same chroot fix also applies to the last chroot call
[04:48] <stgraber> the || true should be in the chrooted command, not outside
[04:48] <alkisg> It's not really useful in the script, it's only useful for updates later on
[04:48] <alkisg> Does it make any difference?
[04:48] <stgraber> chroot $ROOT "gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --set --type list --list-type string /apps/panel/global/disabled_applets \"[OAFIID:GNOME_FastUserSwitchApplet,OAFIID:GNOME_IndicatorApplet]\" || true"
[04:49] <stgraber> well, with: "chroot $ROOT something || true", if $ROOT doesn't exist or chroot isn't installed (for some unlikely examples), it won't complain
[04:49] <alkisg> In any case I'll try to change that to a gconf file, and put it in the correct dir
[04:50] <stgraber> whereas with 'chroot $ROOT "something || true"', you'll still get the most important errors but ignore the return code of the command called inside it
[04:50] <stgraber> for your debconf issue, it's actually quite simple to workaround I guess
[04:50] <alkisg> Well sure but it'd be weird for chroot to return an error there, if it was working in all the lines above
[04:50]  * alkisg is all ears... :)
[04:51] <stgraber> we're using the Passthrough backend which uses that fd that you are getting error for to report status to the debian-installer (at least it was the idea)
[04:51] <stgraber> you could set it to NonInterractive for the fat client part and that won't use any fd
[04:51] <alkisg> :)
[04:52] <alkisg> stgraber: finished succesfully - but it was unable to unmount /proc, and that got me a lot of squashfs compression errors (file in use etc)
[04:52] <alkisg> I also got that when I tried the version of the script that's currently in bzr
[04:52] <stgraber> OLD_DEBIAN_FRONTEND=$DEBIAN_FRONTEND
[04:53] <stgraber> DEBIAN_FRONTEND=noninteractive
[04:53] <stgraber> tasksel blah
[04:53] <alkisg> Thanks, got it :)
[04:53] <stgraber> DEBIAN_FRONTEND=$OLD_DEBIAN_FRONTEND
[04:53] <alkisg> Can I force umount -l /proc there temporarily, until I properly debug it in the next days?
[04:53] <stgraber> alkisg: check for running process inside the chroot
[04:54] <stgraber> alkisg: something must have start a process during the installation of some package and that's what blocking /proc
[04:54] <stgraber> if you kill that process, you'll be able to unmount /proc
[04:54] <alkisg> I think `sudo lsof /opt/ltsp/i386/proc` is giving me the server's processes... !!!
[04:54] <stgraber> sure
[04:54] <alkisg> How else would I check to see what's running inside the chroot?
[04:54] <stgraber>  /proc and /opt/ltps/i386/proc are exactly the same thing ;)
[04:55] <stgraber> ps aux and look at the start time
[04:55] <stgraber> it's usually the easiest
[04:55] <alkisg> Ah. /me feels silly :)
[04:55] <alkisg> notify-osd it is
[04:56] <alkisg> Hmm, no, looking....
[04:59] <alkisg> I actually don't have any such process running. Maybe it's some daemon that's being reused from some program in the chroot?
[05:00] <stgraber> it shouldn't anyway, you can do a "umount -l" on it, it'll solve your squashfs issue
[05:00] <alkisg> OK, so temporarily I'm going to umount -l && remount it, with a # TODO to properly solve it later
[05:14] <stgraber> going for some sleep, last night was really short due to that livedvd issue ;) see you all in 7-8 hours.
[05:15] <alkisg> goodnight :)
[05:30] <alkisg> !info gimp lucid
[12:29] <ma3x> hello
[12:29] <ma3x> i installed ubuntu and edubuntu as extra. can i make the distro edubuntu or at least how can ichange the splash screen to edubuntu
[12:32] <ma3x> helloooooo
[13:11] <highvoltage> stgraber: good morning to you
[13:11] <highvoltage> stgraber: did yesterday's image become the alpha 2 or do I need to do another sync?
[13:12] <alkisg> highvoltage: I'm having problems to find a *correct* way to prevent gdm from being installed while keeping everything else in place. Is it a problem if it gets installed instead, but of course while keeping ldm as the default display manager?
[13:13] <alkisg> (i.e. `echo "/usr/sbin/ldm" > $ROOT/etc/X11/default-display-manager` before installing ubuntu-desktop)
[13:14] <stgraber> highvoltage: it became the alpha-2
[13:49] <highvoltage> alkisg: I wonder whether ldm could get a Provides field so that it provides GDM and KDM (that should solve it on Kubuntu too then, if it's installed before the desktop main metapackage)
[13:49] <alkisg> highvoltage: I don't think it's a bad idea to make ldm able to work beside gdm
[13:49] <highvoltage> stgraber: yay!
[13:49] <alkisg> It could also be used in the future in standalone workstations
[13:50] <stgraber> alkisg: I suspect your LTSP boot didn't work, right ?
[13:50] <alkisg> E.g. I setup ubuntu normally, then install ldm, and I have something like a fat client but with centralized administration...
[13:50] <stgraber> alkisg: I just found this bug in my current package: http://pastebin.com/f7b8424bd
[13:50] <alkisg> stgraber: it works but only when I manually install the needed packages
[13:51] <alkisg> Ah, ok, I used IPAPPEND 3 to bypass this
[13:51] <alkisg> Thanks
[13:52] <alkisg> highvoltage: I think with a small patch in ltsp_config, the client should be able to boot even with gdm installed
[13:52] <alkisg> And gdm won't start if it sees '/usr/sbin/ldm' in /etc/X11/default-display-manager
[13:52]  * alkisg tries all these...
[14:06] <alkisg> highvoltage: Yup, with a 2 lines-patch in ltsp_config, now ldm works fine for me with gdm also installed in the chroot
[14:06] <alkisg> highvoltage: could you tell me about the other "blacklisted" packages in your fat client script?
[14:06] <alkisg> (I mean, why they were blacklisted?)
[14:13] <alkisg> Supposedly, the correct way to install ubuntu-desktop is with `tasksel install ubuntu-desktop`. I tried that, but I ended up with a chroot without e.g. lspci, which broke many xorg scripts.
[14:13] <alkisg> Should I try `tasksel install ubuntu-desktop` AND apt-get install ubuntu-standard?
[14:13] <alkisg> Or should I just do `apt-get install ubuntu-desktop` and get on with it? :)
[14:43] <sbalneav> Morning all
[14:44] <stgraber> hey sbalneav
[14:45] <stgraber> alkisg: that's fixed in the new package, I depend on lspci
[14:45] <stgraber> alkisg: the reason why it didn't work is that it was dropped from ubuntu-minimal and so was dropped from the chroot
[14:45] <alkisg> Ah, ok
[14:46] <alkisg> stgraber: I'm trying to do this: apt-get install ubuntu-standard ubuntu-desktop
[14:46] <alkisg> (or any other user defined desktop)
[14:46] <alkisg> I.e. I assume that fat == those packages only...
[14:47] <alkisg> And I only left those in the blacklisted packages: etwork-manager modemmanager ubufox apport jockey-common
[14:54] <mhall119|work> what is ldm?
[14:55] <alkisg> The LTSP display manager
[14:56] <sbalneav> mhall119|work: The bit that manages the login process for thin clients
[14:57] <mhall119|work> ah, cool
[14:57] <mhall119|work> thought it was maybe an lxde display manager
[14:57] <mhall119|work> highvoltage: I've been reading about how to customize the new GDM and XSplash
[14:58] <mhall119|work> it doesn't look too hard, but it's not nearly an flexible as the old GDM and USplash
[15:43] <alkisg> ...almost ...there :)
[17:07] <alkisg> stgraber: I commited the modified script, could you ping me when you upload a new ltsp version to Ubuntu, so that I can test again from scratch?
[17:09] <stgraber> alkisg: ok
[17:09] <alkisg> ty
[18:59] <sbalneav> alkisg: Two months ago you couldn't even spell "Upstream Free Software Developer", and today you is one :)
[19:00] <sbalneav> \o/ for alkisg
[19:01] <alkisg> And who was the one that almost "pushed" me upstream? Thanks to sbalneav!!! :)
[19:02] <alkisg> sbalneav: but really, I've been a floss developer for decades. Just in assembly/Delphi, away from Linux :)
[19:06] <sbalneav> Well, I think being made a member of upstream is, if nothing else, a recognition of skill, and dedication.
[19:07] <sbalneav> One of the things I've always loved about Free Software is, it's one of the true meritocracies in the world.
[19:07] <sbalneav> You were making a significant contribution.
[19:07] <sbalneav> You *should* be recognized.
[19:08] <alkisg> Yup, being part of a good upstream project is a new experience for me, and a very good one
[19:08] <alkisg> Thank you guys for accepting me :)
[19:08]  * alkisg has to leave the keyboard again because his daughter needs to play ikariam :P :D
[19:49] <stgraber> alkisg: I have two guys here debugging an issue with nbd-proxy, I expect to tag + upload once it's fixed.
[19:49] <alkisg> stgraber: np, thanks, what's nbd-proxy all about? what will it solve?
[19:50] <alkisg> Will clients need more ram for it?
[19:50] <stgraber> no they won't
[19:50] <stgraber> it's just something that makes sure you'll never get any squashfs or input/output error
[19:51] <alkisg> Cool :)
[19:51] <stgraber> it's handling the NBD reconnect in place of the current nbd kernel module and does a lot more checks
[19:51] <stgraber> I actually am testing it by doing a checksum of all files in the chroot while killing the server once every second ;)
[19:52] <alkisg> Wow!!!
[19:52] <alkisg> Sounds rock solid indeed :)
[19:52] <stgraber> haven't seen any dataloss or corruption yet but I sometimes have a process hanging and forcing me to reboot
[19:52] <stgraber> so that's what's being fixed now
[19:52] <stgraber> (something about sending a byte too much when reconnecting, leading to squashfs crashing ;))
[19:54] <alkisg> So is that also included in the initramfs, completely replacing the kernel module?
[20:03] <mgariepy> sbalneav, ping
[21:22] <alkisg> sync -zthhP rsync://cdimage.ubuntu.com/edubuntu/releases/10.04/alpha-2/lucid-dvd-amd64.iso ./lucid-dvd-amd64.iso
[21:22] <alkisg> @ERROR: Unknown module 'edubuntu'
[21:22] <alkisg> rsync error: error starting client-server protocol (code 5) at main.c(1521) [receiver=3.0.6]
[21:22] <alkisg> How can I rsync to see if what I have is == alpha 2?
[21:30] <alkisg> Hmmm pitivi recommends hal...