[02:48] <highvoltage> hola
[02:48] <highvoltage> (I don't understand spanish though)
[02:49] <stgraber> hallo
=== alkisg1 is now known as alkisg
[14:04] <highvoltage> alk<tab>
[15:36] <highvoltage> hey alkisg
[15:36] <alkisg> high highvoltage :)
[15:37] <highvoltage> alkisg: we still have an iTalc slide on http://people.ubuntu.com/~jonathan/files/precise/edubuntu-ubiquity-slideshow/
[15:38] <highvoltage> alkisg: would you be able to come up with some new text we can put in there for epoptes?
[15:38] <alkisg> highvoltage: well at first glance we can keep the existing message there, epoptes can do all the stuff italc does
[15:38] <alkisg> But if we need something more ... hm...
[15:39] <highvoltage> heh, ok. I'll just rename it and replace the screenshot
[15:42] <alkisg> Some features that epoptes has, that italc doesn't... dynamic client detection, ltsp integration, ...most stuff actually works (e.g. not even logout worked in italc/linux), execute custom commands on the clients, and some minor features like broadcasting in a window or sound muting
[15:45]  * highvoltage adds that
[16:08] <highvoltage> Installation de udev...
[16:08] <highvoltage> Mise à jour du serveur virtuel...
[16:08] <highvoltage> ERREUR: L'exécution du script '/etc/vsmanage/models/base/all/post.d/05upgrade.sh' a échoué (retour d'un code de sortie différent de zéro).
[16:08] <highvoltage> Voir /var/log/vsmanage/vsmanage.log pour plus de détails.
[16:08] <highvoltage> (sorry, totally wrong channel)
[16:13] <alkisg> stgraber: can we move ./ltsp-trunk/server/scripts/debian/policy-rc.d.ltsp to ltsp-client, and dpkg-divert it on ltsp-client.postinst, and also symlink it to /etc/grub.d/00-avoid-grub-update?
[16:15] <stgraber> alkisg: not sure I follow, policy-rc.d should only be done from ltsp-build-client as otherwise, installing ltsp-client on a non-LTSP machine will prevent all init scripts from starting (I know it's not possible yet, but it's the long term goal still)
[16:16] <alkisg> stgraber: once use case is to be able to build clients on regular machines but still be able to transfer them to the server and maintain them with chroot afterwards
[16:16] <alkisg> That policy wrapper doesn't do harm on regular machines
[16:16] <alkisg> (otherwise ltsp clients wouldn't even boot)
[16:16]  * stgraber needs to read the script
[16:17] <alkisg> stgraber: in https://bugs.launchpad.net/ltsp/+bug/936810 I have a list of things to do, most of them are packaging tasks
[16:17] <ubottu> Launchpad bug 936810 in ltsp (Ubuntu) "Make ltsp-client package installable on regular machines" [Wishlist,In progress]
[16:17] <stgraber> right, it checks the environment
[16:17] <alkisg> I can send a debdiff + test them. I don't think we can do it in sync with vagrantc as we're too diverted with debian on that
[16:17] <stgraber> dpkg-divert is generally considered evil, so the least we have to do it, the better really
[16:17] <alkisg> So when we're done he can check the diff + sync what he wants
[16:18] <alkisg> Indeed, we only do it for the chroot maintainance
[16:18] <alkisg> We don't need it for maintaining or booting ltsp in regular machines
[16:18] <alkisg> And I think it's documented that for chroots that's the appropriate method
[16:18] <stgraber> I'd prefer we ship a separate file as /etc/grub.d/00-avoid-grub-update that exits "1" instead of "101" and tells the user why it's exitting
[16:19] <alkisg> Yes, that'd be better
[16:19] <stgraber> can't we make ltsp-chroot write and remove the policy-rc.d file instead?
[16:19] <alkisg> ...sure why not!
[16:19] <stgraber> I think it'd make sense to move that kind of chroot maintenance stuff to ltsp-chroot and maybe have ltsp-build-client call ltsp-chroot
[16:21] <alkisg> In the same sense, ltsp-chroot can also install the grub-update diversion
[16:23] <alkisg> Do you want us to go through the packaging stuff together whenever you have time? Would you like me to prepare a .debdiff instead?
[16:26] <stgraber> indeed grub should be done by ltsp-chroot too (writting and removing the file)
[16:26] <stgraber> for the packaging, it'd be great if you could commit your changes by small chunks to a branch of ubuntu:ltsp, then send a merge proposal
[16:26] <stgraber> that way I can see the different commits and it's much easier to review
[16:26] <alkisg> Sure, will do the same for ltspfs too
[16:27] <alkisg> (if it's a different packaging, haven't looked)
[16:27] <stgraber> ltspfs is maintained directly in Debian, so ideally, send your changes to vagrant
[16:27] <stgraber> and if we need them in Ubuntu 12.04, we'll need to do some paperwork ;)
[16:28] <alkisg> Nah for ltspfs it's just a small bugfix :D
[16:28] <alkisg> For ltsp, yes I think we'll need it :)
[16:29] <alkisg> Ah stgraber can I upload a new version of epoptes with modified UI, no additional features?
[16:29] <alkisg> UI freeze is tomorrow, right?
[16:29] <alkisg> Or do I need to get it to debian first, and sync later? (which will get me past uif...)
[16:30] <stgraber> alkisg: upload it as <version>-0ubuntu1 to Ubuntu directly, then have vagrant upload <version>-1 and sync it to Ubuntu
[16:30] <alkisg> Thanks!
[16:30] <stgraber> that way we have the new UI before UI freeze and then we're back in sync with Debian
[16:35] <highvoltage> alkisg: I updated the slide for epoptes on http://people.ubuntu.com/~jonathan/files/precise/edubuntu-ubiquity-slideshow/ - let me know if I should change anything further
[17:52] <stgraber> highvoltage: the Edubuntu grey looks a bit weird on the blue background, did you try in white instead?
[18:02] <highvoltage> I could do that
=== JanC_ is now known as JanC
[21:22] <alkisg> stgraber: bit of help? epoptes/trunk$ debuild -S -sa
[21:22] <alkisg> ...dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../epoptes_0.4.3.orig.tar.{bz2,gz,lzma,xz}
[21:23] <stgraber> well, you're obviously missing a .orig.tar.gz tarball ;)
[21:23] <alkisg> :) some magic to tell debuild to create one?
[21:24] <stgraber> not really, it's not debuild's job
[21:24] <stgraber> let me have a look at the branch, I'm not familiar with epoptes' trunk
[21:25] <stgraber> oh, you have a debian directory in your trunk, interesting ...
[21:25] <alkisg> It's easier for maintainance...
[21:26] <alkisg> I also had a native package at first but vagrantc changed it
[21:26] <alkisg> Let me push the changelog btw
[21:26] <stgraber> yeah, and it looks like vagrant has been repacking your tarball too
[21:26] <alkisg> OK, pushed, that's what I want to upload
[21:27] <stgraber> so in theory:
[21:27] <alkisg> So, am I supposed to manually generated a tar.gz before running debuild?!
[21:27] <stgraber> - bzr export ../epoptes-0.4.3
[21:27] <stgraber> - cd ../epoptes-0.4.3
[21:27] <stgraber> - rm -Rf debian/
[21:27] <stgraber> - cd ..
[21:27] <stgraber> - tar -zcf epoptes_0.4.3.orig.tar.gz epoptes-0.4.3/
[21:27] <stgraber> - cp -R trunk/debian epoptes-0.4.3/
[21:27] <stgraber> - cd epoptes-0.4.3/
[21:27] <stgraber> - debuild -S -sa
[21:28] <alkisg> Gotcha, thanks, trying...
[21:28] <stgraber> that should give you: epoptes_0.4.3.orig.tar.gz (without debian/) + epoptes_0.4.3-0ubuntu1.debian.tar.gz (with only debian/)
[21:28] <stgraber> put them somewhere before you upload so I can make sure it's indeed clean and vagrant won't have an heart attack when seeing them ;)
[21:31] <alkisg> stgraber: epoptes_0.4.3.orig.tar.gz contains an epoptes-0.4.3 folder, while epoptes_0.4.3-0ubuntu1.debian.tar.gz contains debian/ without any parent folders, is this ok?
[21:31] <alkisg> (other than that all seem fine, uploading...)
[21:31] <alkisg> (to an ftp dir... :))
[21:32] <alkisg> http://people.ubuntu.com/~alkisg/tmp/epoptes/
[21:35] <stgraber> yep
[21:35] <stgraber> looking now
[21:36] <stgraber> yep, looks all good
[21:36] <alkisg> Many thanks! :)
[21:37] <alkisg> Uploaded, /me crosses fingers...