=== yofel_ is now known as yofel
=== jbicha is now known as Guest6354
=== Guest6354 is now known as jbicha_
[18:05] <highvoltage> stgraber: so.
[18:05] <highvoltage> stgraber: I want to start putting the seeds together for the kubuntu tablet builds
[18:05] <highvoltage> stgraber: so that we could have them start building
[18:06] <highvoltage> s/kubuntu/edubuntu/g
[18:06] <highvoltage> stgraber: going to look at what they did at https://code.launchpad.net/~kubuntu-dev/ubuntu-seeds/kubuntu-active.precise
[18:06] <highvoltage> stgraber: any thoughts?
[18:06] <stgraber> highvoltage: do we actually need to change anything in our seeds?
[18:07] <highvoltage> stgraber: I'll probably be able to tell you that in a minute or so
[18:07] <stgraber> highvoltage: AFAICT the only thing we'll want to change is disabling edubuntu-netboot/ltsp-live
[18:07] <stgraber> highvoltage: the rest will be identical as I'm expecting us to use an sdcard as install media with the live environment and /pool like on a DVD, then have it install to the internal storage
[18:08] <highvoltage> * !linux-image-*                # xorg transitively depends on this, but this would pull in grub-pc; we handle that separately
[18:08] <highvoltage> not sure if that bit is relevant (since we wouldn't want grub)
[18:08] <highvoltage> stgraber: ok, so it's definitely not going to use the expand thingy anymore?
[18:09] <stgraber> highvoltage: unless we want it to always boot from sdcard, we definitely don't want that
[18:09] <stgraber> highvoltage: and as ubuntu is moving away from it, I'm not sure we want to end up maintaining it anyway
[18:09] <highvoltage> ok, since the zatab has internal storage it seems reasonable to do it like that
[18:10] <stgraber> highvoltage: any progress on getting the hardware btw?
[18:10] <highvoltage> stgraber: yes it's ordered
[18:10] <highvoltage> stgraber: there was a problem with the form on the website where we didn't get the discount on the first try, but it's been fixed
[18:10] <highvoltage> hopefully we won't get any further delays with customs
[18:10] <stgraber> with alpha-2 being next week, I'm starting to become a bit nervous about that tablet build ;)
[18:11] <highvoltage> stgraber: me too, especially since the kernel for it isn't in universe yet, I'm talking to the kubuntu folk to see what we could work out
[18:12] <highvoltage> stgraber: I'm not that failiar with packaging kernel modules and it's slightly tricky since some of the modules would need to go into multiverse
[18:12] <stgraber> highvoltage: right... sounds like we won't have it for alpha2...
[18:13] <highvoltage> stgraber: but I'd like to get builds going so long. I just want to confirm something... the binaries (except for the kernel) will be the same for that as on the pandaboard, right? (the same armhf executables?)
[18:13] <stgraber> highvoltage: yep
[18:13] <highvoltage> stgraber: could we perhaps use the pandaboard kernel in the meantime just to check and find other bugs in the meantime?
[18:14] <stgraber> highvoltage: yeah, I can probably do an omap4 build once ogra_ is done landing the live image changes
[18:14] <stgraber> ogra_: ^
[18:15] <highvoltage> stgraber: that would be nice. can the pandaboard boot from USB? (since it's storage is sd card to begin with?)
[18:15] <highvoltage> well I guess testing from a live environment would be sufficient for now anyway
[18:15] <stgraber> highvoltage: I think so, otherwise you can boot from sdcard, install to another sdcard that's plugged in USB, then swap
[18:15]  * highvoltage wonders if kubuntu active is going to have an alpha 2
[18:15] <highvoltage> ah right
[18:17] <highvoltage> stgraber: I'd really like to have *a* image for alpha2, even if it's not perfect or working properly in any meaningful way, at least it would also give us a point of reference for the work that needs to be done for the next alpha
[18:18] <stgraber> highvoltage: yeah, I'm having a quick look in the cdimage branches to see what's needed to build Edubuntu for omap4, if it's not a gigantic diff, I may steal an armhf builder and do a quick test build
[18:20] <stgraber> highvoltage: actually wondering if there's anything to do besides kicking a build ;)
[18:21] <stgraber> highvoltage: the archive is a bit broken at the moment so I can really test it though
[18:21] <highvoltage> stgraber: well, I guess we need uboot instead of grub but I can't think of anything else specific at this point
[18:21] <stgraber> highvoltage: we're not seeding grub AFAIK so that's not a problem
[18:23] <highvoltage> stgraber: for edubuntu server, I guess we'll support i386 and amd64 since the desktop media will be for both and we're shipping it alongside that?
[18:24] <highvoltage> (just want to be sure that I'm not just assuming anything)
[18:24] <highvoltage> (I'd actually be ok with amd64 only for servers but I guess that would be too tricky, shipping-wise)
[18:24] <stgraber> highvoltage: well, technically the installer on arm could support it but I don't think we want that ;)
[18:24] <highvoltage> yeah, maybe for 14.04 :)
[18:25] <highvoltage> oic
[18:25] <stgraber> we'd need hardware for an arm server build, I don't feel like asking people to use a pandaboard
[18:26] <highvoltage> yeah, so how about my i386/amd64 question?
[18:26] <highvoltage> let me rephrase, I can see how I could have been a bit unclear
[18:26] <highvoltage> stgraber: we're supporting i386 for edubuntu server too, right?
[18:28] <stgraber> highvoltage: yeah, our build scripts are already weird enough wrt architectures, don't want to introduce an extra hack in there ;)
[18:28] <stgraber> besides it wouldn't save us much to only ship on amd64 as it wouldn't reduce the number of media being built
[18:29] <highvoltage> yeah
[18:29] <stgraber> do you have any news from the zentyal guys? we're kind of waiting on the samba4 support stuff to implement edubuntu server ;)
[18:29] <highvoltage> stgraber: is it a big deal getting those squashfs's built already? I guess the ltsp scripts could be recycled somewhat? I know that ubiquity needs some work, but it would be kind of nice having those images kind of building already
[18:30] <highvoltage> stgraber: yeah, indeed. I'll have solid news on that next week. from what I understand the samba4 parts are working, but I'm fuzzy on the exact extent of the schooltool integration that's currently working
[18:31] <stgraber> highvoltage: I'm still not sure of the exact architecture we want for edubuntu server so can't really work on the seeds or the build scripts until that's done
[18:31] <stgraber> highvoltage: at least I have commit rights to most of them now, so should be easy to land whenever we know how we want to build that stuff
[18:33] <highvoltage> stgraber: I'd feel kind of more easy about it even just having a minimal debootstrapped ubuntu in there
[18:34] <highvoltage> stgraber: because I know that gets harder to do the further we get along the cycle
[18:34] <stgraber> highvoltage: for example, I don't know if we want to have the installer create the containers and setup all that stuff or if we should have these preinstall in the squashfs
[18:35] <stgraber> because we'll basically end up shipping an ubuntu system for Edubuntu itself, another for the ltsp chroot, another for the server, another as the lxc template and one per container ;)
[18:35] <highvoltage> it depends. we want off-line installations to be possible. so if the containers don't already exist then the packages should be shipped on the disc
[18:35] <highvoltage> stgraber: wouldn't it make sense then to create the containers instead?
[18:36] <stgraber> I think shipping one big squashfs is the easiest, using squashfs to solve the data duplication problem
[18:36] <highvoltage> stgraber: because it would get a bit bit if we ship multiple containers? or would they use overlayfs or something?
[18:36] <highvoltage> ok
[18:36] <stgraber> the problem is that we then need to have all our server build happen on a buildd without internet connectivity and without being able to start the containers on it
[18:39] <highvoltage> that seems to pretty much rule that option out for the immediate future then, doesn't it?
[18:40] <stgraber> highvoltage: for alpha-2, definitely, for alpha-3, not necessarily, depends how much time you can spend on it ;)
[18:40] <stgraber> highvoltage: we essentially need to introduce a package that contains a script used to build edubuntu-server, then push that to the archive and then I can update our build process for it
[18:41] <highvoltage> I feel that we should discuss this tonight :)
[18:41] <stgraber> that package (edubuntu-server-base or something like that) would depend on everything that the "host" needs and ship a command that'll build all the containers without ever starting them
[18:42] <highvoltage> yeah that sounds reasonable
[18:42] <stgraber> worst case scenario we can just ship a squashfs with that package installed and have the user run the command post-install
[18:42] <stgraber> best case scenario, that command gets run on the buildds and everything gets preinstall in the squashfs
[18:43] <highvoltage> yeah I was going to mention that as a possibility too
[18:44] <highvoltage> have something basic and flexible but easy to extend based on the requirements. I'm /almost/ be satisfied if the first iteration of edubuntu server is just a nice lxc host, but it should be possible to do better than that, at least :)
[18:45] <highvoltage> ogra_: are you around?
[19:05] <stgraber> highvoltage: http://paste.ubuntu.com/1051408/
[19:07] <highvoltage> ".1 - .9 is reserved for servers"
[19:07] <highvoltage> what kind of servers?
[19:07] <stgraber> LTSP or secondary edubuntu servers
[19:07] <highvoltage> ah, physical servers then?
[19:08] <stgraber> yeah
[19:10] <highvoltage> I like it.
[19:16] <stgraber> highvoltage: hmm, I'm starting to think that we won't be able to ship the containers on the media because we won't know the domain name or subnet at that time
[19:16] <stgraber> highvoltage: and it seems easier to call the whole build script at install time rather than trying to patch a preinstalled system
[19:17] <stgraber> highvoltage: so we could have the .squashfs ship the host without the containers but with a basic tpl-edubuntu-server container that contains our base install and gets copied to all the others
[19:18] <highvoltage> stgraber: I'll have to take your word for it, I don't have enough insight yet to judge the amount of work for either. prebuilt could probably be templated somewhat... but yes I kind of like the idea that they're built at install time anyway
[19:18] <highvoltage> stgraber: yes that sounds very, very good
[19:18] <highvoltage> (and very sensible)
[19:33] <stgraber> highvoltage: http://pad.ubuntu.com/edubuntu-server-quantal
[19:38] <highvoltage> stgraber: is nesting containers safe? (not just in terms of how it works, but is it in any way confusing or problematic implementatin wise?)
[19:39] <stgraber> highvoltage: it's slightly dangerous but not scary
[19:40] <stgraber> highvoltage: essentially the first level (juju in this case) will be able to bypass the cgroup restrictions
[19:40] <stgraber> IIRC the sub-containers are still moved to the same usual apparmor profile so they're as safe as usual
[19:41] <highvoltage> ok
=== jbicha_ is now known as jbicha