| === yofel_ is now known as yofel | ||
| === jbicha is now known as Guest6354 | ||
| === Guest6354 is now known as jbicha_ | ||
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| stgraber | highvoltage: yeah, I can probably do an omap4 build once ogra_ is done landing the live image changes | 18:14 |
| stgraber | ogra_: ^ | 18:14 |
| 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:15 |
| 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:17 |
| 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:18 |
| stgraber | highvoltage: actually wondering if there's anything to do besides kicking a build ;) | 18:20 |
| 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:21 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| highvoltage | stgraber: I'd feel kind of more easy about it even just having a minimal debootstrapped ubuntu in there | 18:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| highvoltage | that seems to pretty much rule that option out for the immediate future then, doesn't it? | 18:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| highvoltage | yeah I was going to mention that as a possibility too | 18:43 |
| 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:44 |
| highvoltage | ogra_: are you around? | 18:45 |
| stgraber | highvoltage: http://paste.ubuntu.com/1051408/ | 19:05 |
| 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:07 |
| stgraber | yeah | 19:08 |
| highvoltage | I like it. | 19:10 |
| 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:16 |
| 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:17 |
| 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:18 |
| stgraber | highvoltage: http://pad.ubuntu.com/edubuntu-server-quantal | 19:33 |
| 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:38 |
| stgraber | highvoltage: it's slightly dangerous but not scary | 19:39 |
| 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:40 |
| highvoltage | ok | 19:41 |
| === jbicha_ is now known as jbicha | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!