=== c74d3 is now known as c74d [04:37] guys, we need to create additional users to Snappy Ubuntu. How we should do this in proper way? [07:00] good morning [07:01] good morning dholbach and all [07:02] hey fgimenez === chihchun_afk is now known as chihchun === erkules_ is now known as erkules [08:43] grumble ... ubuntu-fan ... grumble [08:54] Good morning all; happy Milk Chocolate Day! 😃 [09:10] ogra_: You know when you add the grumbles you sound less of a fan and more of a stalker right ;) [09:10] heh === kickinz1|afk is now known as kickinz1 [11:46] hmpf ... i dont et it [11:46] *get [11:47] ogra_: ? [11:47] buildin an armhf rootstock rootfs always fails with dependency issues [11:47] and its the same missing deps no matter what release i use [11:48] amd64 vivid is up to now the only one i manaed to get to build [11:48] wily fails there too [11:48] (though not dep issues) [11:52] ogra_: is it bad that i don't know what rootstock is in this context? (i assume you're not building a social investment society) [11:52] http://paste.ubuntu.com/11953230/ i really dont know what to make out of that ... it is using the stable archive [11:52] oh [11:52] perhaps it should also use -updates [11:53] Chipaca, a rootfs builder tool ... project-rootstock-ng on launchpad [11:53] ogra_: otherwise, check with barry maybe? he's usually ontop of python weirdness :) [11:53] well, this is vivid ... we build regular snappy imaes from it :) [11:53] *images [11:55] rootstock uses exactly the same setup as the livefs builders so theoretically there is no reason for it to fail if the official images build [11:57] * ogra_ tries adding -updates to the sources.list === chihchun is now known as chihchun_afk [11:59] OOOOH ! [11:59] * ogra_ slaps forehead [11:59] the snappy livecd-rootfs comes from the PPA [12:00] so indeed i'm missing all the hacks [12:08] hmpf, adding -updates doesnt change a thing [12:16] ogra_: hey - any news about getting a stable snappy 15.04 with the uboot.env changes? [12:17] longsleep, rsalveti wanted to release it last night, seems that didnt happen [12:17] not sure why [12:17] ogra_: ok thanks - i will keep monitoring then :) [12:29] sergiusens: /var/lib/apparmor/clicks and /var/lib/snappy/apparmor are different. basically, /var/lib/snappy/... is where we want to go and I started to go there with seccomp. /var/lib/apparmor/... is where we want to move from and we'll do that when click-apparmor is gone [12:30] jdstrand, is anyone from the security team looking into the libstagefright issue on the phone (sorry for the echan) [12:30] sounds pretty serious even for us [12:30] elopio: you around? [12:30] Chipaca: o/ [12:31] how can I help you? [12:31] elopio: integrations test asplode nicely in wily [12:31] elopio: here i was all excited because they should finally work again (because networking is working \o/) [12:32] very disappointed; i thought i'd be able to convert "made integration tests work again on wily" into "get bottle of aged rum from elopio" [12:32] Chipaca: I'm not sure if I should be happy or sad. [12:32] Chipaca: throw the log at us. fgimenez is using wily, so he should be able to tell what's going on. [12:32] http://pastebin.ubuntu.com/11953399/ [12:32] I'm just running in vivid, and it works. [12:33] Chipaca: your udf failed [12:34] ogra_: waiting to see if we could get any update from utlemming [12:34] but will release it later today [12:34] rsalveti: huh? [12:34] elopio: yep [12:34] Chipaca: this would increase your chances of getting aged rum: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1473333 [12:34] Launchpad bug 1473333 in goget-ubuntu-touch (Ubuntu) "exits with zero on error" [Undecided,Confirmed] [12:35] utlemming: hey :-), what I asked you yesterday: [12:35] utlemming: it's all your fault, see? [12:35] utlemming: we're just finishing the testing phase for our current alpha image (image 9), and that will be migrated to stable [12:35] or latest edge (132) [12:35] ogra_: not to my knowledge. tyhicks, do you know? ^ [12:35] :-p [12:35] utlemming: can you run your usual testing scenarios over it and see if there is any issue with the cloud targets? [12:35] rsalveti: ah, okay [12:35] rsalveti: sorry, I didn't see the request, doing it now [12:35] utlemming: no worries, thanks [12:36] elopio: maybe i should just rerun it :) [12:36] Chipaca: the same udf command works for me. fgimenez: ^ can you give it a try? [12:37] elopio: fgimenez: the re-run has gotten further [12:37] elopio: Chipaca yep on it, anyway that error may disappear eventually [12:38] Chipaca yep here it's working fine [12:38] so blame sergiusens, that's good B-) [12:38] \o/ then [12:38] but it's not being able to ssh in [12:39] Chipaca: that's probably because ens3 is down [12:39] fgimenez: that's what i fixed :) [12:39] Chipaca: then it must be something else :) [12:40] Chip [12:41] Chipaca: you can try to create the image, launch it with kvm and run the tests passing ip and port [12:41] Chipaca: you fixed it, but udf is deploying yesterday's rolling edge [12:41] Chipaca: go run _integration-test/main.go --ip localhost --port 8022. [12:42] and we will know if rolling edge works until later. :( [12:42] elopio: um [12:43] ah [12:43] elopio: i'm guessing it copies in snappy after ? [12:44] Chipaca: yes. Some discussion in here: https://trello.com/c/VUKDVa97/106-generate-an-image-with-snappy-from-a-branch [12:45] rsalveti: I'm seeing an image with a serial of 132 [12:45] utlemming: right, that's the one we're going to promote to stable [12:45] unless we find yet another bug [12:46] Chipaca: and note that there's one failover test that regressed, so the suite will fail. [12:47] https://bugs.launchpad.net/snappy/+bug/1476129 [12:47] Launchpad bug 1476129 in Snappy "automatic reboot fails with rc.local crash" [Undecided,New] [12:50] fgimenez: all my refactor branches are updated. What's missing I think is to give a better name to common.go like basetest.go, but I'm not sure if go test would try to run it. [12:52] elopio: ok i'll take a look, there are more failover tests that are not working because of the new location of the kernel files, i'll put hands on that too [12:52] fgimenez: oh, that's sad. [12:52] we are so close to be in-sync, but things keep falling appart. Thanks fgimenez. [12:53] rsalveti, so latest rootstock should theoretically be able to build core for vivid and wily ... but .... bug 1450980 [12:53] pitti: you around? [12:53] bug 1450980 in debootstrap (Ubuntu) "Python 3.4.3 package fails to install with deboostrap on armhf" [High,Confirmed] https://launchpad.net/bugs/1450980 [12:53] * elopio goes offline now. Telegram if you need me. [12:53] elopio: i *think* you meant to thanks fgimenez for keeping things in sync, but it reads like you're blaming him for things falling apart :) [12:53] ogra_: =\ [12:54] there is a workaround mentioned, trying that now [12:55] Chipaca: ok, to be clearer, I blame everybody except fgimenez ;) [12:55] elopio: i want my part of blame too! :) [12:58] oooh, that looks a lot better ! [12:59] hey Chipaca; yes, back from holidays [13:00] pitti: welcome back! [13:00] thanks! [13:00] pitti: i'm fighting with network-online.target; a service has it as a requires: and after: dependency, and it's still started before a network interface comes up [13:01] pitti: i'm starting to suspect either i'm misunderstanding something deeper, or something's broken in snappy wrt systemd & networking [13:02] (btw, dunno if you remember but udevadm failed to bring up the network after adding a hotplug file to interfaces.d; had to systemctl restart networking) [13:02] Chipaca: do you have a journalctl from the full boot? that shows the sequence of ifup-wait-all-auto.service, network-online.target, and your service [13:02] onions ... so tiring ... [13:02] * ogra_ yawns [13:02] ogra_: ? [13:02] pitti: how do i get that? [13:03] pitti, rootstock uses three chroots wrapped into each other to fake a real livefs builder ... ultra boring to watch it :) [13:03] Chipaca: "sudo journalctl > /tmp/journal.txt", and scp/pastebin that [13:03] onion model :) [13:03] or just "sudo journalctl | pastebin -" if you have something like that installed [13:06] pitti: http://paste.ubuntu.com/11953525/ [13:07] rsalveti: things look good for all the clouds [13:07] utlemming: great [13:07] Chipaca: so ifup-wait-all-auto.service is done at line 676, network-online.target is done at 735 [13:07] Chipaca: what's your service? [13:07] can clouds roll back ? [13:07] pitti: webdm [13:08] pitti: how is network-online done, if the network is not online? [13:08] Chipaca: erk, cloud-init runs afterwards, and calls ifupdown stuff [13:08] yeah, we should realyl get rid of it [13:09] the three to fix things it does for use all have equivalents in the distro we could use instead [13:09] Chipaca: may it be that there isn't actually an /etc/network/interfaces at boot, or cloud-init creates that? [13:09] s/fix/five/ [13:09] pitti: just to be clear, there is no configured network; it should not start at all :) [13:09] in general, I really recommend not running cloud-init on every boot, unless you have a very good reason to [13:09] Chipaca: aah [13:09] Chipaca: well, our ifup-wait-all-auto.service only waits until all configured interfaces are up [13:10] and as there are none, it succeeds immediately then [13:10] oh [13:10] daaaaamn [13:10] ok, let's see if i tell it there's a fake one [13:10] so you need some other service that hooks into network-online.target and waits until you configure your network [13:10] that might be a good option still [13:11] we can't make the default distro ifup-wait-all-auto.service not fire at all in this case [13:11] understood [13:11] as you can also use NetworkManager, connman, networkd, or something else [13:11] pitti: the "no network configured" thing is me trying to fake bug 1466672 [13:11] bug 1466672 in Snappy trunk "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,New] https://launchpad.net/bugs/1466672 [13:12] Chipaca:if cloud-init brings up the network, then perhaps it could order itself before network-online.target? [13:12] Chipaca: also: [13:12] dhclient[895]: can't create /var/lib/dhcp/dhclient.leases: Permission denied [13:12] pitti: that was me running dhclient by hand [13:12] wow [13:12] ah, ok [13:12] without sudo [13:12] :) [13:12] ok, I ignore this then :) [13:12] ogra_: de-panic :) [13:13] not panicing :) [13:13] * ogra_ is just bored ... watching rootstock ... waiting [13:13] Chipaca: it looks like cloud-init also calls ifup -a [13:13] pitti: thank you; i have plenty of things to poke for now then :) i'll pester you again if i run out again [13:13] with some errors, but did that actually work? [13:13] i. e. after it's done, do you have network? [13:13] pitti: i have no idea :) [13:14] Chipaca: well, wait until cloud-init is done, and check "ip a" and "ip route"? [13:14] pitti: sorry, to be clear, in this case no it did not do anything [13:14] Chipaca: and of course if it wrote something sensible into /etc/network/interfaces [13:14] pitti: because i manually disabled networking by moving a file away from interfaces.d [13:14] pitti: but i think your general question is whether that is the thing that actually brings up the network [13:14] pitti: i will know shortly :) [13:15] Chipaca: ok, so it's not cloud-init then; I guess you have something else that writes /e/n/i then? [13:15] or is supposed to [13:15] pitti: snappy firstboot writes a file to interfaces.d [13:16] Chipaca: that finishes on line 742, so indeed after network-online.target [13:16] Chipaca: so if you order that Before=network.target, that might help [13:17] Chipaca: i. e. it should write /e/n/i.d/ early, and then the ifup-wait-all-auto.service magic should kick in [13:17] update-initramfs: Generating /boot/initrd.img-3.19.0-25-generic [13:17] /bin/df: Warning: cannot read table of mounted file systems: No such file or directory [13:17] Warning: root device does not exist [13:17] Unable to abort; system will probably be broken! [13:17] GEEZ !" [13:17] * pitti tosses a /proc mount to ogra [13:17] could we make update-initramfs warnings a little less scary [13:17] pitti, thats expected, it is run by live-build in that context [13:18] pitti: i tried ordering firstboot before network-pre, but it didn't work [13:18] but update-initramfs is full of such warnings about trivial bits that sound like the end of the world [13:18] pitti: however you weren't here to pester :) so maybe i should retest that later [13:21] pitti: this is with the same config as just now, but with a (fake) entry in interfaces.d: http://paste.ubuntu.com/11953575/ [13:22] pitti: interesting things are, for a start, a "sh segmentation fault" [13:22] and that ifup-wait-all-auto failed, but network-online succeeded [13:22] Chipaca: right, that times out after 2 mins; I did that to do the same as what we did under upstart, i. e. block the boot for at most 2 mins on ifup [13:23] ifquery[535]: segfault at 1 ip 0000000000403187 sp 00007ffd59263e90 error 4 in ifup[400000+d000] [13:23] go, ifupdown! [13:23] lol [13:24] that might explain the 30sec delay during boot :) [13:24] pitti: to be fair, i did just tell it to try to bring up ens42 [13:24] pitti, seems to not be 2min in the new world [13:25] 13:16:29 localhost.localdomain systemd[1]: Starting Wait for all "auto" /etc/network/interfaces to be up for network-online.target... [13:25] 13:18:29 localhost.localdomain systemd[1]: Failed to start Wait for all "auto" /etc/network/interfaces to be up for network-online.target. [13:25] looks like 2 mins to me :) [13:25] well, my BBB sits for 30-40sec [13:26] ogra_: this is so big a mess, i suggest we take a look at some point [13:26] +1 [13:26] not right now tho :) [13:26] haha [13:26] ogra@anubis:~/Devel/branches/project-rootstock-ng$ ls -l out-20150728 [13:26] insgesamt 218368 [13:26] -rw-r--r-- 1 root root 188192 Jul 28 15:26 build-20150728-armhf.log [13:26] -rw-r--r-- 1 root root 163712102 Jul 28 15:26 ubuntu-core.device.tar.gz [13:26] -rw-r--r-- 1 root root 8217 Jul 28 15:26 ubuntu-core.manifest [13:26] -rw-r--r-- 1 root root 59685713 Jul 28 15:26 ubuntu-core.rootfs-armhf.tar.gz [13:27] HOORAY !!!! [13:27] * ogra_ dances [13:27] pitti: so, um, what do i do if i want to start a service after the network is up? so it works in the "network device is there but cable not plugged in" case [13:27] * pitti hugs ogra [13:27] * ogra_ hugs pitti [13:28] so now on to a wily build ... if that works too i'll declare rootstock ready for usage :) [13:28] Chipaca: can you please clarify? if there's no cable, you're technically never online [13:28] pitti: in that case, the service shouldn't start. It should start after a cable is plugged in (stopping if unplugged would be a bonus) [13:29] Chipaca: right now we delay network-online.target for up to 2 mins on /e/n/i coming up (mimicking what we did in upstart); apparently that was the right thing for desktop/server, but maybe not for snappy [13:29] Chipaca: so I guess we need a different "implementation" of n-o for that, i. e. not ifup-wait-all-auto.service [13:30] pitti: i'm not so sure; i'd like to be able to getty in even if the network is disconnected, for example [13:30] for a start, an infinite timeout [13:30] Chipaca: yes, getty doesn't need n-o, so that's always possible; ideally very few services are requires/after n-o [13:30] n-o.target is really mostly a hack for legacy software which doesn't know how to listen to networking changes itself [13:30] ah, ok [13:31] hey, i could just say "bug in webdm" and see what rsalveti says :) [13:31] but we can certainly write an implementation that makes n-o go up an down while some ifupdown interface is up [13:31] Chipaca: I'd probably say just fix webdm then :P [13:32] rsalveti: wfm, but i can see many other, lesser, app developers blaming snappy and not their code :) [13:32] sorry, need to read the entire backlog for context [13:33] rsalveti: bottom line is: my sneaky plan of making it work by hanging off of network-online.target will not work unless we rewrite stuff (and depart from what works for the rest of ubuntu) [13:34] * ogra_ thinks we should just go back to upstart :P [13:34] or forwards to systemd-networkd! [13:35] Jul 28 13:34:08 localhost kernel: [ 228.622474] audit: type=1400 audit(1438090448.373:13): apparmor="STATUS" operation="profile_load" profile="unconfined" name="mir_system-compositor_snap1.1" pid=1068 comm="apparmor_parser" [13:35] jdstrand: so got to the point of final testing.... [13:36] Chipaca: yeah, for use cases like that it'd certainly be more practical to "eternally" delay n-o; we can't do that on desktop/server where networks can be brought up by other means, but if ifupdown/snappy-firstboot is the only thing that configures it we can be stricter [13:36] and just happened to lock at the syslog, i don't have any "unconfined" in my profiles so why does it say that ^ [13:36] ogra_: FWIW, upstart has exactly the same behaviour :) [13:36] jdstrand: could it be that at one point, an unconfined template was used ? e.g. it's not specified by keyword "unconfined" [13:37] but the structure ? [13:37] pitti, yeah, but i know from the top of my head how to work around it in upstart :P [13:37] so, another thing i could do, is add a wait to the service itself [13:37] systemd isnt injected enouh in my cortical system yet :) [13:38] Chipaca, sleep 30 [13:38] :P [13:38] ExecStartPre=wait4tehnetworz [13:38] pitti: would that work? [13:39] ogra_: don't let it -- it's not designed for human brains :) [13:39] Chipaca: sure; although, that's conceptually a bit broken [13:39] pitti: tell me more [13:39] pitti, but it fits into lennarts ! [13:39] Chipaca: I'd suggest, if you have a thing like this, rather stick it in ifup-wait-all-auto.service [13:40] ogra_: obviously :) [13:40] Chipaca: well, you can eternally wait in ExecStartPre= if you also disable the unit timeout [13:40] ah. forgot about that pesky timeout thing :) [13:40] Chipaca: but it's still not very elegant; for such long (potentially indefinite) waits it's better to put that waiting logic into a separate unit (ifup-wait-all-auto.service *cough*), and order yourself after it [13:41] Chipaca: well, TimeoutStartSec=0 :) (but then real hangs won't ever be detected) [13:41] pitti: i'm reticent to modifying ifup-wait-all-auto.service though [13:41] Chipaca: it could also be a new one, like ifupdown-wait-online.service [13:41] Chipaca: there's no harm in making network-online.target wait for both [13:42] Chipaca: on a desktop it e. g. waits for ifup-wait-all-auto.service and NetworkManager-wait-online.service [13:42] pitti: and how is that difference sorted? [13:42] Chipaca: so, for experimentation: fine to put it into ExecStartPre= [13:42] Chipaca: (and disable the timeout) [13:42] that might be simplest for iterating on the logic of wait4tehnetworz [13:43] Chipaca: but once you do have a wait4tehnetworz, let's rather put that into a new ifupdown-wait-online.service which is Before=network-online.target [13:43] Chipaca: difference? [13:46] pitti: wait4tehnetworz is just “while [ "$(GET "http://start.ubuntu.com/connectivity-check.html" | md5sum | cut -d\ -f1)" != "4589f42e1546aa47ca181e5d949d310b" ]; do sleep 1; done”, for example [13:46] (possibly not *actually* in sh) :) [13:46] kgunn: that is not a denial, that is a profile load. That log entry is completely normal. it is saying an unconfined process (ie, apparmor_parser, snappy, whatever) loaded the profile [13:46] pitti: difference == how to ship one config for desktop and a different one for server (and now a different one for snappy) [13:46] i don't know how that part of the system is glued up [13:47] Chipaca: ah, just ship it in the snappy package, together with a /lib/systemd/system/network-online.target.wants/ symlink [13:48] Chipaca: I don't think you actually need to disable ifup-wait-all-auto.service -- your's should be stricter in all cases [13:48] gotcha [13:48] Chipaca: i. e. I don't see a case where ifup-wait-all-auto.service would still wait while your's would alreaydy succeed [13:49] now i understand what the symlinks are for :-D [13:49] Chipaca: shipping the symlink is the same as adding an [Install] section and calling systemctl enable (teh latter just creates that symlink) [13:49] * pitti needs to run to the grocery store, back in 30 [13:56] jdstrand: i realize that's not a denial, my point is...i'm going thru the process of making sure the mir snap and client are confined [13:57] and wondering, if i've made it all confined why is it saying unconfined....so you say the process that started it is [13:57] which i guess would be the launching script that's part of the snap ? [13:59] kgunn, I think he's saying that by design, unconfined processes start apps and services [14:00] so it's an ignorable log entry [14:00] beuno: that was my other thot, thanks for confirmation [14:01] kgunn: what is saying unconfined exactly? the log entry you pointed to doesn't say anything about the mir process or the client process [14:01] kgunn: it is only saying that the profile was loaded by an unconfined process (ie, when you ran apparmor_parser, or when you installed the snap) [14:02] kgunn: like beuno said, you can ignore it [14:02] jdstrand: got it, so pid 1068 was the unconfined thing [14:02] kgunn: if you want to know if the mir and client processes are confined, you can use 'sudo aa-status' or 'ps Z' [14:03] ta [14:03] kgunn: 1068 was ultimately apparmor_parser, yes [14:05] jdstrand: thanks, i think i'm actually done with mods to aa and seccomp to get the mir svr and client app to run confined [14:06] altho i'm sure you or designate will need to take a look [14:06] and tell me to "improve" potentially :) [14:07] kgunn: great! yeah, whenever you upload ping me and I'll look at it. at this point I imagine we are getting to the point of just filing bugs [14:07] cool [14:08] just doing some clean testing to make sure i'm all good [14:38] pitti: for the record, a delayed network-online results in no gettys for 2m [14:39] Chipaca: hmm, that's bad; so we block user-sessions on that? /me checks [14:40] ah, we had bug 1425376 earlier due to that [14:40] bug 1425376 in systemd (Ubuntu) "Ubuntu Core provides no console login prompt if network is unavailable" [Undecided,Fix released] https://launchpad.net/bugs/1425376 [14:40] ah, so we block network.target, which is really bad [14:41] pitti: it does give me a nice red ascii throbber to look at on console though :) [14:44] pitti: this is bad news for my wait4networz service, which ... um ... waits for the networz [14:45] * Chipaca should trademark that [14:49] pitti: but that bug says it's fixed released; am i missing something? [14:49] Chipaca: yes, it is, I just remembered that we had such a case before [14:49] so we need to find out why network.target is blocked on getting online [14:50] apparently something orders itself after network-online.target but before network.target, and we need to LART it [14:50] Chipaca: yeap but no wonder your network is down. I mean there are always casualties in worz [14:50] * Chipaca deploys networz on davmor2 [14:51] ah, could be /etc/init.d/networking [14:52] * davmor2 plays c6 and sinks Chipaca's battle ship [14:52] * Chipaca sneaks a spy into davmor2's capital and sets off a nuke [14:53] pitti: fwiw ifup-wait-all-auto bailed as expected [14:53] Chipaca: Thanks Wolverhampton really need a facelift [14:54] who says wars don't settle arguments [14:54] Chipaca, that is because you dont use ifup-wait-all-auto-do-no-bail [14:55] ogra_: --pretty-please [14:55] No no worz alway settle arguments the issue is in war no one remembers the argument that triggered it so they keep resetting the argument ;) [14:55] :) [14:56] Chipaca: btw, in case it's any easier, you can run stuff from /etc/network/if-up.d/, which are called when (any) interface gets connected [14:57] Chipaca: if you have a journalctl from that boot with the stalled getty, I'd be interested [14:57] Chipaca: (also, stalled -- talking to other folks) [14:57] pitti: how can i get journalctl from a stalled boot? [14:57] given no network & no getty [14:58] Chipaca: you could boot with systemd.debug-shell, and ctrl+alt+f9 [14:58] that was it [14:58] yep [14:58] Chipaca: or disable your new unit, and just let the standard stuff time out after 2 mins [14:58] pitti: i don't know how do disable my new unit :) [14:58] Chipaca: or just plug in ethernet after 2 mins :-) I'm merely interested what's (not) starting until the network comes up [14:58] Chipaca: remove the symlink [14:59] pitti: with no network and no getty [14:59] ah [14:59] :) [14:59] well, debug shell it is then, I figure :) [14:59] Chipaca: but it does sound like bug 1425376 is back? [14:59] bug 1425376 in systemd (Ubuntu) "Ubuntu Core provides no console login prompt if network is unavailable" [Undecided,Fix released] https://launchpad.net/bugs/1425376 [15:00] pitti: if it ever truly went away, yes [15:00] i've seen this spinner before, didn't realise it was a bug [15:02] jdstrand: so here's my "confined" attempt [15:02] pitti: http://paste.ubuntu.com/11954006/ [15:02] https://code.launchpad.net/~kgunn72/mir/snappy-packaging-with-secprofile/+merge/266111 [15:02] jdstrand: so dunno if that's for you or tyler feel free to change [15:02] also do you want snaps built ? [15:03] kgunn: I don't need snaps built [15:03] why are we running cloud init on *every* boot? isn't it a firstboot thing? [15:03] Chipaca: oh, cloud-init [15:03] sergiusens: do you know^? [15:03] Chipaca: right, cloud-init is indeed blocking gettys, and it takes effing long [15:03] jdstrand: ok, to test you can follow the "snappy gui anyone" blog [15:03] pitti: cloud init depends on network-online afaik [15:04] the one step not to forget is the "export LC_ALL=C.UTF-8" ;) [15:04] kgunn: ok. I probably won't get to this immediately, but will soon [15:04] Chipaca: right, and blocks user sessions [15:04] tyhicks: there is already a card for this. I'll assign it to me since I looked at the others [15:04] yes, requires: network-online [15:04] jdstrand: no worries, i just didn't want to drop our responsibility of following up :) [15:04] Chipaca: so if there's no network, cloud-init will block [15:04] lurvely [15:04] ogra_: are you saying that we use stagefright on our phones? [15:05] tyhicks: see #phablet [15:05] tyhicks, seems we dont use it but there are ~30 .so files in the android container under /system/lib [15:06] Chipaca: OOI, what do you use cloud-init for? [15:06] accordin to jhodapp they are not used by anything though [15:06] Chipaca: with the r/o file system it can't actually do much, can it? [15:06] ogra_: thanks [15:06] pitti: I don't know what we use it for, exactly :-) [15:06] pitti: i'm hoping sergiusens knows [15:08] Chipaca: cloud-init runs on every boot [15:08] yeah :/ [15:08] Chipaca: pitti that is the way of cloud-init, I was told it should be this way; maybe smoser or utlemming can expand [15:08] jdstrand: ack - thanks for taking the review [15:08] cloud-init does not run through the whole thing on every boot though [15:08] it has run-once's [15:09] right, but it blocks the boot on network-online.target, that's the main problem [15:09] i. e. if you aren't online, it stalls the boot [15:10] pitti: Chipaca wrt what we use it for, it's used for the cloud and btw https://trello.com/c/W5WiZQM7/117-core-config-for-cloud-init [15:26] sergiusens: any ideas as to where to put http://pastebin.ubuntu.com/11954094/ so we can ship it in the snappy package easily? [15:35] Chipaca: hey there, i've recently tried to confine the mir snap, i wanted to grab olli's qml app and run on top...see if i get any sec issues compared to my qt clock ref [15:35] where would i find that snap ? [15:36] kgunn: i think ted has a snap built with the qml snapcraft plugin [15:37] kgunn: otherwise chinstrap.canonical.com/~ories/public_html/digital_sign_deb2snap_tree.tar.bz2 is ollie's (old) thing [15:37] kgunn: but you probably meant the qml snapcraft route [15:37] Chipaca: yeah, preferably latest/greatest [15:37] kgunn: um, s.public_html/.. [15:38] ted might not be here though [15:38] 1 sec [15:38] kgunn: this is snapcraft with the qml plugin (not merged yet): https://code.launchpad.net/~ted/snapcraft/qml [15:39] kgunn: this is a snapcract project that uses it: https://code.launchpad.net/~ted/+junk/photoviewer [15:39] ta [15:42] kgunn: um. there's also the snapcraft ppa [15:42] kgunn: because without a patched libxkbcommon some things will fail [15:42] ah-ha [15:43] kgunn: if you're in wily, you already have the patch [15:44] kgunn: which we successfully upstreamed, btw :) https://github.com/xkbcommon/libxkbcommon/pull/25 [15:46] where's golang-uboot-go-dev supposed to be at? [15:47] sergiusens: ogra_: any idea? ^ [15:47] never heard of it [15:47] ogra_: it's mvo's uboot-go, packaged [15:47] it's a build dependency [15:47] ah [15:47] but it doesn't exist [15:47] well, he didnt want to include it anyway [15:48] the binary is like 2MB or so [15:48] so dont bother for now [15:48] he can handle it when coming back [15:48] ogra_: but i can't dpkg-buildpackage without it :-. [15:48]