=== mmrazik is now known as mmrazik|afk === doko_ is now known as doko === mmrazik|afk is now known as mmrazik [06:47] slangasek, there is not much you could help with i fear ... the tarball we have coming out of cadejo is usable, for turning it into a zip we currently need a binary install tool included that needs to be cross built with a bionic toolchain ... i worked out a workaround script in my home on nusakan for the moment that does the zip production, just need to couple it with my phablet-sync tool for publishing somehow [06:50] bionic toolchain? [06:51] You need a Borg drone? [06:51] haha [06:52] StevenK, i need an infinity/doko coproduction :) [06:53] we need to package up the android parts of the touch image ... [08:15] cjwatson, did the behavior of the default-arches command when called manually change or did my last change mess up etc/default-arches ? [08:16] it always returns "amd64 amd64+mac i386 powerpc" no matter what args i use [08:16] i.e. [08:16] cdimage@nusakan:~$ default-arches lubuntu daily-preinstalled saucy [08:16] amd64 amd64+mac i386 powerpc [08:17] that should only return armhf+ac100 [08:17] (it did once at least) [08:18] That's not the correct calling sequence [08:19] default-arches takes no arguments [08:19] well, it used to work with args in the past [08:19] *shrug* [08:19] I feel no obligation to preserve that interface [08:20] $ PROJECT=lubuntu DIST=saucy IMAGE_TYPE=daily-preinstalled default-arches [08:20] armhf+ac100 [08:20] ok [08:20] http://irclogs.ubuntu.com/2013/02/26/%23ubuntu-release.txt ... [08:21] cdimage@nusakan:~$ PROJECT=ubuntu-touch DIST=saucy IMAGE_TYPE=daily-preinstalled default-arches [08:21] armhf [08:21] right [08:22] I changed it in r1069 [08:22] now i wonder about the ubuntu-touch builds from last night ... [08:22] It was unnecessarily difficult to preserve the old (irregular) interface while also adding reliable support for SUBPROJECT and UBUNTU_DEFAULTS_LOCALE [08:23] Those were manually triggered, yes? [08:23] yeah, fine with me, i just never called it that way [08:23] How did you trigger those builds? [08:23] it doesnt look like SUDO_USER was set, no [08:23] i didnt [08:23] thats the fun part [08:23] But then why multiple builds ... [08:23] i stopped working rather early yesterday [08:24] They were eight minutes apart [08:24] the mails i have are from ~1:30 here [08:24] I guess perhaps that was slangasek; he was asking questions about that on IRC at around the same time [08:24] yes, saw that [08:24] it shouldnt build these arches at all [08:25] So I'm going to disregard those failures until he appears and says what he was doing :) [08:25] and if he ran it manually thatr should be in the mail subject [08:25] No [08:25] Only livefs build failures do that right now [08:25] was that dropped ? [08:25] oh, ok [08:25] It was never there for non-livefs builds, AFAIK [08:26] There's certainly some code unification possible [08:26] well, the first set of mails are livefs failures actually [08:26] I've deleted the mails now so can't check [08:27] SUDO_USER isn't always set either. [08:27] Do you mean that the subject starts with "LiveFS"? [08:27] http://people.canonical.com/~ubuntu-archive/livefs-build-logs/saucy/ubuntu-touch/20130506/ [08:28] yes [08:29] infinity, apparently [08:29] I've adjusted image build failure mails to mention SUDO_USER if it's set, too [08:29] but as infinity says ... [08:29] yup [08:30] i still dont get why it tried all these arches though ... but slangasek might be ablle to tell [08:32] (the 06 and 06.1 armhf builds were mine from around noon btw) [08:35] i wonder if the buildds were just busy for 12h and they were queued up [08:48] ogra_: I expect because slangasek used cron.daily-live rather than cron.daily-preinstalled [08:48] ah [08:50] hmm, i fear BOOTAPEND_LIVE wont gain us much in the ubuntu-touch images === smartboyhw_ is now known as smartboyhw === greyback is now known as greyback|lunch === greyback|lunch is now known as greyback [14:03] ogra_: yeah, those failed builds were mine. So why does building a .zip require such special tooling? [14:03] slangasek, we dont have the needed binary built in the archive yet [14:04] ogra_: what tool do you need that isn't "zip"? [14:05] slangasek, http://bazaar.launchpad.net/~phablet-team/touch-preview-images/phablet-build-scripts/files/head:/META-INF/com/google/android/ [14:05] the update-binary binary [14:05] lives inside the adnroid metadata dir [14:05] *android [14:06] will be easy to build it once we have a cross bionic ... until then, not so much ... we could ship it in restricted i guess but that fellt to uglt [14:06] Application-level code is specifically per policy (and Mark) excluded from restricted [14:06] ogra_: ok, but what is this tool supposed to *do*? Creating a .zip file is not hard and doesn't require building binaries for bionic [14:06] fwiw, since people seem to keep bringing that up as a possibility ... [14:07] slangasek, its not *creating* the zip, thats stuff android uses during verificastiion when installing it [14:07] http://stackoverflow.com/questions/15608292/meta-inf-com-google-android-update-binary-source-code has some stuff about this program [14:07] it is used during unpack [14:08] ogra_: ok [14:08] we have the source living on phablet.u.c ... its just that we dont have a package atm [14:08] is it more appropriate to ask for sru approval in this channel or -devel? [14:08] if you look in my home on nusakan, the whole zipping code is there [14:09] (in the utouch-android dir [14:09] ) [14:12] ogra_: ok, but why does this need to be a *bionic* binary at all? [14:12] it is executed in the android recovery mode [14:12] ah [14:12] It's statically linked. [14:12] during unpacking/installling [14:13] So, the bionic bit is somewhat of a red herring. [14:13] well, we need it built from source and in a package [14:13] But it needs to be statically linked against some libc that it doesn't hate. :P [14:13] right, so we could just as well statically link an eglibc binary? [14:13] It looks like some sick cross between busybox and every decompression method EVAR. [14:14] At least, from a quick scan with strings(1). I imagine the source would be more enlightening. :P [14:14] Looks like its own mini-language thing [14:15] sergiusens should know ehere the source is on phablet.u.c [14:15] *where [14:15] ogra_: I don't see any source in ~ogra/utouch-android [14:15] there is none [14:15] It can't just be this edify thing. [14:16] slangasek, its my script to roll a zip from the tarball ... essentially what will go into livecd-rootfs modulo the binary [14:16] sergiusens: hi, can you help me find the source to the 'update-binary' program needed for the root .zip? [14:21] i think in a checked our tree it lives under ./bootable/recovery/updater/ [14:21] http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_bootable_recovery.git;a=tree [14:21] that should be the right tree [14:22] yeah ... #include "edify/expr.h" [14:22] http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_bootable_recovery.git;a=blob;f=updater/updater.c;h=5f1580870d54c3ef8058ffc6230103aa728c40e2;hb=HEAD [14:22] that must be it [14:27] * sergiusens reads [14:28] * sergiusens is late [14:29] no prob :) [14:29] it made me look at git ... thats a good thing ... i have to get used to it :) [14:30] ogra_: slangasek we can probably add that to the recovery image and remove it from the zip... if that would speed things up, I'll see to it [14:31] if the zip still works then, that would likely help ... but we need a cross bionic anyway [14:32] and in the end we should have it packaged [14:32] especially in the light that not everyone uses our recovery image [14:33] we would pertty much exclude everyone using a plain CWm recovery for installation [14:38] ogra_: yeah, that would be the case... I thought that long term the recovery image would be rewritten anyways, right? [14:38] would be fine for our own devices ... not so sure about ports [14:38] i guess that would need broader discussion [14:39] ogra_: also, next time you can't find something easily look in .repo/manifest.xml, you'' have the directory<->git_repo translation [14:39] oh [14:39] ogra_: yup, seems like two conflicting objectives [14:39] thanks ! [14:40] np [14:47] cjwatson, hmm, regarding that image build failure that just hit my inbox ... should cron.daily not exit 0 if there are no default arches at all ? (i dropped ubuntu daily-preinstalled from default-arches but left the cronjob in place assuming it would just not do anything) [14:48] I'd rather there were some incentive to clear up clutter [14:48] yeah, i will dissable the cronjob too ... but it looks to me like it shouldnt just fall back to defaults [14:49] -s [14:50] It's doing what it's told *shrug* [14:50] The format's clear, I think [14:50] indeed [14:51] There's a "* * *" wildcard, which covers everything [14:51] oh, right ... the top line [14:51] Bottom [14:52] oh, right, top is source [14:52] (and i386 only) [14:53] Well, insofar as the arch is any more than a cheat there [14:54] cjwatson, gtw, by the looks of it there are no plans for user creation etc on fist boot of the touch images [14:54] would using live-debconf ig be appropriate if we need to create it during build ? [14:55] (vs the hackish scripts the images use now) [14:56] No idea what live-debconf is [14:56] (xnox indicated that there wont be anything like oem-config at all) [14:57] live-debconfig ... seems to be a new part in live-build [14:57] run away [14:57] http://live.debian.net/manpages/current/en/txt/live-debconfig-set-selections.1.txt [14:57] heh [14:58] I don't really see the point in "reusing" that given that it isn't used by us anywhere else [14:58] well, i think using something other thna a ton of adduser calls from a live-build hook script might still be better [14:58] did i say re ? [14:59] Well, no, but the only reason to use it would be if it were reuse [14:59] i only just discovered it in universe searching for a saner way to replace the hooks [15:00] (and wanted an opinion ... run away sounds pretty clear :) ) [15:00] live-build is allergic to stable interfaces; I would be very cautious about using it [15:00] for this kind of thing [15:00] k [15:01] Yeah, that seems very very specific to a particular view of the world in live-build [15:01] I don't think it will actually make your life easier in more than the very short term [15:01] well, i'd obviously like a sane solution [15:02] Why's there more than one adduser call and a few fixups? [15:02] I realise it's suboptimal to have to duplicate this stuff, but I'm not sure why it's a ton of stuff [15:02] its like 20 groups with fixed numbers ... setting up sudoers etc [15:03] Why not imitate what casper does? [15:03] during install ? [15:03] It preseeds some stuff and calls user-setup-apply [15:03] No, casper, not install-time [15:03] ah [15:03] scripts/casper-bottom/25adduser [15:03] yeah, i know casper [15:04] we have something similar in the hooks in livecd-rootfs [15:04] just using direct adduser calls though [15:05] casper's scheme would involve less code duplication if you can make it work [15:05] so you would propose to keep the hook system but use more of a casper like script [15:05] k [15:05] stgraber: Is queubot having a sad again? [15:05] infinity: possibly, let me kick it [15:06] stgraber: Give it a rexec command with a simple hostmask ACL (if you fear abuse), and we can all kick it. :P [15:07] ogra_: Or something. I don't mean the general format of casper's scripts, I just mean the way it handles that particular case [15:14] cjwatson, yeah [15:15] cjwatson, actually i'll register a spec for UDS, i think we should define that properly (assuming tablet images will want something like oem-config while phones dont and need the GIDs for android etc etc) [15:16] so that sounds like a divergent think in the converged world :) [15:16] *thing [15:17] ogra_: I thought we already had some design-led work for that [15:17] cjwatson, me too, until xnox told me it wont do user creation or use any debconf in the backend [15:18] i think there is a big gap still [15:18] There's a "personalisation" slot in it, but it's not clear to me that it's worth the overhead of using oem-config [15:18] We already know we'd have to put a lot of work into performance to make that workable [15:19] well i dont care what we use, but it should be consistent [15:19] and it doesnt look like any techincal design has happened there [15:38] ogra_: based on the actual requirements for the OOBE on the phone, there doesn't seem to be much reason to reuse oem-config. We certainly aren't going to be prompting the user to configure a username, so I don't see any reason to do this at install time instead of at image build time [15:39] slangasek, well, i would expect us to ask for a real name [15:39] so that we have some GECOS changes at least [15:39] we may or may not do; but even if we store that in GECOS, that doesn't involve adding the user to groups at install time [15:40] as well as timezone and language (unless we produce one img per lang) [15:40] what about tablets with multiuser option ? [15:40] out of scope for 13.10 [15:40] will they just use oem-config ? [15:41] timezone/language> I don't know what the plan is there; but this needs to be confirmed with design before we commit ourselves to any technical implementation [15:41] well, might be out of scope for 13.10 ... but we are laying a foundation here for the convergence [15:41] and at least a raw idea should be defined [15:41] imho [15:43] ogra_: IMHO, laying the foundation for convergence means that, *when* we need to do work for the phone, we think about how it applies to other form factors. For OOBE, that means we need to first get an agreed design, then figure out what's needed to support that design in the larger ecosystem [15:43] so we wait for the UI ? [15:43] but we shouldn't insist on using oem-config before we know it's needed/wanted [15:43] i didnt insist using oem-config [15:44] ogra_: I wouldn't say "wait". The language prompting is a good point, I don't remember this in the OOBE presentation last week - I'm checking now [15:44] but if i write something it would be good if it could be used on the tablet too [15:44] also worth remembering that oem-config is a very old design and not necessarily worth hanging onto as the number of reused items decreases [15:45] i just want to replace: [15:45] ogra@chromebook:~/branches/livecd-rootfs-2.132$ ls live-build/ubuntu-touch/hooks/ [15:46] 01-setup_user.chroot 02-add_user_to_groups.chroot 45-add-adming-group-nm.chroot 48-setup-env.chroot 49-setup-demo-assets.chroot 99-remove-documentation.chroot [15:46] but if i invest work it would be good to do it based on a design we can re-use later [15:46] like cjwatson said above, using caspers user setup etc [15:48] sure [15:49] (and it sadly needs to take all these android groups into account) [15:49] fwiw, here's the current design for OOBE: https://docs.google.com/a/canonical.com/document/d/1JHFd_6mYdUTd0RpR-Sm7-WnX-06rY8r58K3Cz32mhJg/edit# [15:50] android groups> doubtful, in the long term? [15:50] as long as we use the android kernel and blobs i fear we have to [15:51] kernels and blobs certainly shouldn't care about userspace groups [15:51] One would hope not. [15:51] it hardcodes some GIDs that have access to certain services in the kernel iirc [15:51] oh dear God [15:51] its android :) [15:51] yes [15:52] I expect a minimum level of sanity from Android [15:52] it's not a very high bar [15:52] it definitely does it for the paranoid network stuff .... and i suspect there is a lot more [15:52] (we switch off paranoid network, but thats the only modification in that area) [15:53] (.. other services, sensors etc will expect certain GIDs too) [15:55] * ogra_ points at live-build/ubuntu-touch/hooks/02-add_user_to_groups.chroot ... in the livecd-rootfs source [15:55] groupadd -g 1015 sdcard_rw [15:55] .... [15:56] groupadd -g 1004 android_input [15:56] ... [15:56] etc [16:12] ogra_: anyway, there's definitely a language selection step in the OOBE (see google doc). You may or may not get to set a username. [16:13] well, at least in the U1 config step you will get one [16:15] yay [16:15] dropping the hardcoded packagelist worked === mmrazik is now known as mmrazik|afk [17:06] cjwatson, does http://paste.ubuntu.com/5642091/ look ok to you ? [17:10] ogra_: Should be fine. A test for at least the first part would be nice (there's one you can copy and paste) [17:21] cjwatson, like that http://paste.ubuntu.com/5642150/ ? [17:21] (i'll need to switch that to zips once we can build them though ... ) [17:25] ogra_: yep [17:25] * ogra_ commits ... lets see if i now get non-empty output dirs :) === Ursinha-afk is now known as Ursinha [19:49] royal rainbow! === apachelogger is now known as Phonon [22:50] hmm, still an ubuntu zh_CN build for saucy?