[04:37] <biezpal> guys, we need to create additional users to Snappy Ubuntu. How we should do this in proper way?
[07:00] <dholbach> good morning
[07:01] <fgimenez> good morning dholbach and all
[07:02] <dholbach> hey fgimenez
[08:43] <ogra_> grumble ... ubuntu-fan ... grumble
[08:54] <JamesTait> Good morning all; happy Milk Chocolate Day! 😃
[09:10] <davmor2> ogra_: You know when you add the grumbles you sound less of a fan and more of a stalker right ;)
[09:10] <ogra_> heh
[11:46] <ogra_> hmpf ... i dont et it
[11:46] <ogra_> *get
[11:47] <Chipaca> ogra_: ?
[11:47] <ogra_> buildin an armhf rootstock rootfs always fails with dependency issues
[11:47] <ogra_> and its the same missing deps no matter what release i use
[11:48] <ogra_> amd64 vivid is up to now the only one i manaed to get to build
[11:48] <ogra_> wily fails there too
[11:48] <ogra_> (though not dep issues)
[11:52] <Chipaca> 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] <ogra_> http://paste.ubuntu.com/11953230/ i really dont know what to make out of that ... it is using the stable archive
[11:52] <ogra_> oh
[11:52] <ogra_> perhaps it should also use -updates
[11:53] <ogra_> Chipaca, a rootfs builder tool ... project-rootstock-ng on launchpad
[11:53] <Chipaca> ogra_: otherwise, check with barry maybe? he's usually ontop of python weirdness :)
[11:53] <ogra_> well, this is vivid ... we build regular snappy imaes from it :)
[11:53] <ogra_> *images
[11:55] <ogra_> 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
[11:59] <ogra_> OOOOH !
[11:59]  * ogra_ slaps forehead
[11:59] <ogra_> the snappy livecd-rootfs comes from the PPA
[12:00] <ogra_> so indeed i'm missing all the hacks
[12:08] <ogra_> hmpf, adding -updates doesnt change a thing
[12:16] <longsleep> ogra_: hey - any news about getting a stable snappy 15.04 with the uboot.env changes?
[12:17] <ogra_> longsleep, rsalveti wanted to release it last night, seems that didnt happen
[12:17] <ogra_> not sure why
[12:17] <longsleep> ogra_: ok thanks - i will keep monitoring then :)
[12:29] <jdstrand> 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] <ogra_> jdstrand, is anyone from the security team looking into the libstagefright issue on the phone (sorry for the echan)
[12:30] <ogra_> sounds pretty serious even for us
[12:30] <Chipaca> elopio: you around?
[12:30] <elopio> Chipaca: o/
[12:31] <elopio> how can I help you?
[12:31] <Chipaca> elopio: integrations test asplode nicely in wily
[12:31] <Chipaca> elopio: here i was all excited because they should finally work again (because networking is working \o/)
[12:32] <Chipaca> 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] <elopio> Chipaca: I'm not sure if I should be happy or sad.
[12:32] <elopio> Chipaca: throw the log at us. fgimenez is using wily, so he should be able to tell what's going on.
[12:32] <Chipaca> http://pastebin.ubuntu.com/11953399/
[12:32] <elopio> I'm just running in vivid, and it works.
[12:33] <elopio> Chipaca: your udf failed
[12:34] <rsalveti> ogra_: waiting to see if we could get any update from utlemming
[12:34] <rsalveti> but will release it later today
[12:34] <utlemming> rsalveti: huh?
[12:34] <Chipaca> elopio: yep
[12:34] <elopio> Chipaca: this would increase your chances of getting aged rum: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1473333
[12:35] <rsalveti> utlemming: hey :-), what I asked you yesterday:
[12:35] <Chipaca> utlemming: it's all your fault, see?
 utlemming: we're just finishing the testing phase for our current alpha image (image 9), and that will be migrated to stable
 or latest edge (132)
[12:35] <jdstrand> ogra_: not to my knowledge. tyhicks, do you know? ^
[12:35] <Chipaca> :-p
 utlemming: can you run your usual testing scenarios over it and see if there is any issue with the cloud targets?
[12:35] <utlemming> rsalveti: ah, okay
[12:35] <utlemming> rsalveti: sorry, I didn't see the request, doing it now
[12:35] <rsalveti> utlemming: no worries, thanks
[12:36] <Chipaca> elopio: maybe i should just rerun it :)
[12:36] <elopio> Chipaca: the same udf command works for me. fgimenez: ^ can you give it a try?
[12:37] <Chipaca> elopio: fgimenez: the re-run has gotten further
[12:37] <fgimenez> elopio: Chipaca yep on it, anyway that error may disappear eventually
[12:38] <fgimenez> Chipaca yep here it's working fine
[12:38] <elopio> so blame sergiusens, that's good B-)
[12:38] <Chipaca> \o/ then
[12:38] <Chipaca> but it's not being able to ssh in
[12:39] <fgimenez> Chipaca: that's probably because ens3 is down
[12:39] <Chipaca> fgimenez: that's what i fixed :)
[12:39] <fgimenez> Chipaca: then it must be something else :)
[12:40] <fgimenez> Chip
[12:41] <fgimenez> Chipaca: you can try to create the image, launch it with kvm and run the tests passing ip and port
[12:41] <elopio> Chipaca: you fixed it, but udf is deploying yesterday's rolling edge
[12:41] <elopio> Chipaca: go run _integration-test/main.go --ip localhost --port 8022.
[12:42] <elopio> and we will know if rolling edge works until later. :(
[12:42] <Chipaca> elopio: um
[12:43] <Chipaca> ah
[12:43] <Chipaca> elopio: i'm guessing it copies in snappy after ?
[12:44] <elopio> Chipaca: yes. Some discussion in here: https://trello.com/c/VUKDVa97/106-generate-an-image-with-snappy-from-a-branch
[12:45] <utlemming> rsalveti: I'm seeing an image with a serial of 132
[12:45] <rsalveti> utlemming: right, that's the one we're going to promote to stable
[12:45] <rsalveti> unless we find yet another bug
[12:46] <elopio> Chipaca: and note that there's one failover test that regressed, so the suite will fail.
[12:47] <elopio> https://bugs.launchpad.net/snappy/+bug/1476129
[12:50] <elopio> 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] <fgimenez> 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] <elopio> fgimenez: oh, that's sad.
[12:52] <elopio> we are so close to be in-sync, but things keep falling appart. Thanks fgimenez.
[12:53] <ogra_> rsalveti, so latest rootstock should theoretically be able to build core for vivid and wily ... but .... bug 1450980
[12:53] <Chipaca> pitti: you around?
[12:53]  * elopio goes offline now. Telegram if you need me.
[12:53] <Chipaca> 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] <rsalveti> ogra_: =\
[12:54] <ogra_> there is a workaround mentioned, trying that now
[12:55] <elopio> Chipaca: ok, to be clearer, I blame everybody except fgimenez ;)
[12:55] <fgimenez> elopio: i want my part of blame too! :)
[12:58] <ogra_> oooh, that looks a lot better !
[12:59] <pitti> hey Chipaca; yes, back from holidays
[13:00] <Chipaca> pitti: welcome back!
[13:00] <pitti> thanks!
[13:00] <Chipaca> 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] <Chipaca> pitti: i'm starting to suspect either i'm misunderstanding something deeper, or something's broken in snappy wrt systemd & networking
[13:02] <Chipaca> (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] <pitti> 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] <ogra_> onions ... so tiring ...
[13:02]  * ogra_ yawns
[13:02] <pitti> ogra_: ?
[13:02] <Chipaca> pitti: how do i get that?
[13:03] <ogra_> pitti, rootstock uses three chroots wrapped into each other to fake a real livefs builder ... ultra boring to watch it :)
[13:03] <pitti> Chipaca: "sudo journalctl > /tmp/journal.txt", and scp/pastebin that
[13:03] <ogra_> onion model :)
[13:03] <pitti> or just "sudo journalctl | pastebin -" if you have something like that installed
[13:06] <Chipaca> pitti: http://paste.ubuntu.com/11953525/
[13:07] <utlemming> rsalveti: things look good for all the clouds
[13:07] <rsalveti> utlemming: great
[13:07] <pitti> Chipaca: so ifup-wait-all-auto.service is done at line 676, network-online.target is done at 735
[13:07] <pitti> Chipaca: what's your service?
[13:07] <ogra_> can clouds roll back ?
[13:07] <Chipaca> pitti: webdm
[13:08] <Chipaca> pitti: how is network-online done, if the network is not online?
[13:08] <pitti> Chipaca: erk, cloud-init runs afterwards, and calls ifupdown stuff
[13:08] <ogra_> yeah, we should realyl get rid of it
[13:09] <ogra_> the three to fix things it does for use all have equivalents in the distro we could use instead
[13:09] <pitti> Chipaca: may it be that there isn't actually an /etc/network/interfaces at boot, or cloud-init creates that?
[13:09] <ogra_> s/fix/five/
[13:09] <Chipaca> pitti: just to be clear, there is no configured network; it should not start at all :)
[13:09] <pitti> in general, I really recommend not running cloud-init on every boot, unless you have a very good reason to
[13:09] <pitti> Chipaca: aah
[13:09] <pitti> Chipaca: well, our ifup-wait-all-auto.service only waits until all configured interfaces are up
[13:10] <pitti> and as there are none, it succeeds immediately then
[13:10] <Chipaca> oh
[13:10] <Chipaca> daaaaamn
[13:10] <Chipaca> ok, let's see if i tell it there's a fake one
[13:10] <pitti> so you need some other service that hooks into network-online.target and waits until you configure your network
[13:10] <Chipaca> that might be a good option still
[13:11] <pitti> we can't make the default distro ifup-wait-all-auto.service not fire at all in this case
[13:11] <Chipaca> understood
[13:11] <pitti> as you can also use NetworkManager, connman, networkd, or something else
[13:11] <Chipaca> pitti: the "no network configured" thing is me trying to fake bug 1466672
[13:12] <pitti> Chipaca:if cloud-init brings up the network, then perhaps it could order itself before network-online.target?
[13:12] <pitti> Chipaca: also:
[13:12] <pitti> dhclient[895]: can't create /var/lib/dhcp/dhclient.leases: Permission denied
[13:12] <Chipaca> pitti: that was me running dhclient by hand
[13:12] <ogra_> wow
[13:12] <pitti> ah, ok
[13:12] <Chipaca> without sudo
[13:12] <Chipaca> :)
[13:12] <pitti> ok, I ignore this then :)
[13:12] <Chipaca> ogra_: de-panic :)
[13:13] <ogra_> not panicing :)
[13:13]  * ogra_ is just bored ... watching rootstock ... waiting 
[13:13] <pitti> Chipaca: it looks like cloud-init also calls ifup -a
[13:13] <Chipaca> 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] <pitti> with some errors, but did that actually work?
[13:13] <pitti> i. e. after it's done, do you have network?
[13:13] <Chipaca> pitti: i have no idea :)
[13:14] <pitti> Chipaca: well, wait until cloud-init is done, and check "ip a" and "ip route"?
[13:14] <Chipaca> pitti: sorry, to be clear, in this case no it did not do anything
[13:14] <pitti> Chipaca: and of course if it wrote something sensible into /etc/network/interfaces
[13:14] <Chipaca> pitti: because i manually disabled networking by moving a file away from interfaces.d
[13:14] <Chipaca> pitti: but i think your general question is whether that is the thing that actually brings up the network
[13:14] <Chipaca> pitti: i will know shortly :)
[13:15] <pitti> Chipaca: ok, so it's not cloud-init then; I guess you have something else that writes /e/n/i then?
[13:15] <pitti> or is supposed to
[13:15] <Chipaca> pitti: snappy firstboot writes a file to interfaces.d
[13:16] <pitti> Chipaca: that finishes on line 742, so indeed after network-online.target
[13:16] <pitti> Chipaca: so if you order that Before=network.target, that might help
[13:17] <pitti> 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] <ogra_> update-initramfs: Generating /boot/initrd.img-3.19.0-25-generic
[13:17] <ogra_> /bin/df: Warning: cannot read table of mounted file systems: No such file or directory
[13:17] <ogra_> Warning: root device  does not exist
[13:17] <ogra_> Unable to abort; system will probably be broken!
[13:17] <ogra_> GEEZ !"
[13:17]  * pitti tosses a /proc mount to ogra
[13:17] <ogra_> could we make update-initramfs warnings a little less scary
[13:17] <ogra_> pitti, thats expected, it is run by live-build in that context
[13:18] <Chipaca> pitti: i tried ordering firstboot before network-pre, but it didn't work
[13:18] <ogra_> but update-initramfs is full of such warnings about trivial bits that sound like the end of the world
[13:18] <Chipaca> pitti: however you weren't here to pester :) so maybe i should retest that later
[13:21] <Chipaca> 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] <Chipaca> pitti: interesting things are, for a start, a "sh segmentation fault"
[13:22] <Chipaca> and that ifup-wait-all-auto failed, but network-online succeeded
[13:22] <pitti> 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] <pitti> ifquery[535]: segfault at 1 ip 0000000000403187 sp 00007ffd59263e90 error 4 in ifup[400000+d000]
[13:23] <pitti> go, ifupdown!
[13:23] <ogra_> lol
[13:24] <ogra_> that might explain the 30sec delay during boot :)
[13:24] <Chipaca> pitti: to be fair, i did just tell it to try to bring up ens42
[13:24] <ogra_> pitti, seems to not be 2min in the new world
[13:25] <pitti> 13:16:29 localhost.localdomain systemd[1]: Starting Wait for all "auto" /etc/network/interfaces to be up for network-online.target...
[13:25] <pitti> 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] <pitti> looks like 2 mins to me :)
[13:25] <ogra_> well, my BBB sits for 30-40sec
[13:26] <Chipaca> ogra_: this is so big a mess, i suggest we take a look at some point
[13:26] <ogra_> +1
[13:26] <Chipaca> not right now tho :)
[13:26] <ogra_> haha
[13:26] <ogra_> ogra@anubis:~/Devel/branches/project-rootstock-ng$ ls -l out-20150728
[13:26] <ogra_> insgesamt 218368
[13:26] <ogra_> -rw-r--r-- 1 root root    188192 Jul 28 15:26 build-20150728-armhf.log
[13:26] <ogra_> -rw-r--r-- 1 root root 163712102 Jul 28 15:26 ubuntu-core.device.tar.gz
[13:26] <ogra_> -rw-r--r-- 1 root root      8217 Jul 28 15:26 ubuntu-core.manifest
[13:26] <ogra_> -rw-r--r-- 1 root root  59685713 Jul 28 15:26 ubuntu-core.rootfs-armhf.tar.gz
[13:27] <ogra_> HOORAY !!!!
[13:27]  * ogra_ dances
[13:27] <Chipaca> 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] <ogra_> so now on to a wily build ... if that works too i'll declare rootstock ready for usage :)
[13:28] <pitti> Chipaca: can you please clarify? if there's no cable, you're technically never online
[13:28] <Chipaca> 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] <pitti> 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] <pitti> Chipaca: so I guess we need a different "implementation" of n-o for that, i. e. not ifup-wait-all-auto.service
[13:30] <Chipaca> 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] <pitti> for a start, an infinite timeout
[13:30] <pitti> Chipaca: yes, getty doesn't need n-o, so that's always possible; ideally very few services are requires/after n-o
[13:30] <pitti> n-o.target is really mostly a hack for legacy software which doesn't know how to listen to networking changes itself
[13:30] <Chipaca> ah, ok
[13:31] <Chipaca> hey, i could just say "bug in webdm" and see what rsalveti says :)
[13:31] <pitti> but we can certainly write an implementation that makes n-o go up an down while some ifupdown interface is up
[13:31] <rsalveti> Chipaca: I'd probably say just fix webdm then :P
[13:32] <Chipaca> rsalveti: wfm, but i can see many other, lesser, app developers blaming snappy and not their code :)
[13:32] <rsalveti> sorry, need to read the entire backlog for context
[13:33] <Chipaca> 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] <Chipaca> or forwards to systemd-networkd!
[13:35] <kgunn> 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] <kgunn> jdstrand: so got to the point of final testing....
[13:36] <pitti> 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] <kgunn> 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] <pitti> ogra_: FWIW, upstart has exactly the same behaviour :)
[13:36] <kgunn> jdstrand: could it be that at one point, an unconfined template was used ? e.g. it's not specified by keyword "unconfined"
[13:37] <kgunn> but the structure ?
[13:37] <ogra_> pitti, yeah, but i know from the top of my head how to work around it in upstart :P
[13:37] <Chipaca> so, another thing i could do, is add a wait to the service itself
[13:37] <ogra_> systemd isnt injected enouh in my cortical system yet :)
[13:38] <ogra_> Chipaca, sleep 30
[13:38] <ogra_> :P
[13:38] <Chipaca> ExecStartPre=wait4tehnetworz
[13:38] <Chipaca> pitti: would that work?
[13:39] <pitti> ogra_: don't let it -- it's not designed for human brains :)
[13:39] <pitti> Chipaca: sure; although, that's conceptually a bit broken
[13:39] <Chipaca> pitti: tell me more
[13:39] <ogra_> pitti, but it fits into lennarts !
[13:39] <pitti> Chipaca: I'd suggest, if you have a thing like this, rather stick it in ifup-wait-all-auto.service
[13:40] <pitti> ogra_: obviously :)
[13:40] <pitti> Chipaca: well, you can eternally wait in ExecStartPre= if you also disable the unit timeout
[13:40] <Chipaca> ah. forgot about that pesky timeout thing :)
[13:40] <pitti> 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] <pitti> Chipaca: well, TimeoutStartSec=0 :) (but then real hangs won't ever be detected)
[13:41] <Chipaca> pitti: i'm reticent to modifying ifup-wait-all-auto.service though
[13:41] <pitti> Chipaca: it could also be a new one, like ifupdown-wait-online.service
[13:41] <pitti> Chipaca: there's no harm in making network-online.target wait for both
[13:42] <pitti> Chipaca: on a desktop it e. g. waits for ifup-wait-all-auto.service and NetworkManager-wait-online.service
[13:42] <Chipaca> pitti: and how is that difference sorted?
[13:42] <pitti> Chipaca: so, for experimentation: fine to put it into ExecStartPre=
[13:42] <pitti> Chipaca: (and disable the timeout)
[13:42] <pitti> that might be simplest for iterating on the logic of wait4tehnetworz
[13:43] <pitti> 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] <pitti> Chipaca: difference?
[13:46] <Chipaca> 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] <Chipaca> (possibly not *actually* in sh) :)
[13:46] <jdstrand> 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] <Chipaca> pitti: difference == how to ship one config for desktop and a different one for server (and now a different one for snappy)
[13:46] <Chipaca> i don't know how that part of the system is glued up
[13:47] <pitti> Chipaca: ah, just ship it in the snappy package, together with a /lib/systemd/system/network-online.target.wants/ symlink
[13:48] <pitti> 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] <Chipaca> gotcha
[13:48] <pitti> 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] <Chipaca> now i understand what the symlinks are for :-D
[13:49] <pitti> 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] <kgunn> 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] <kgunn> 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] <kgunn> which i guess would be the launching script that's part of the snap ?
[13:59] <beuno> kgunn, I think he's saying that by design, unconfined processes start apps and services
[14:00] <beuno> so it's an ignorable log entry
[14:00] <kgunn> beuno: that was my other thot, thanks for confirmation
[14:01] <jdstrand> 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] <jdstrand> 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] <jdstrand> kgunn: like beuno said, you can ignore it
[14:02] <kgunn> jdstrand: got it, so pid 1068 was the unconfined thing
[14:02] <jdstrand> 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] <kgunn> ta
[14:03] <jdstrand> kgunn: 1068 was ultimately apparmor_parser, yes
[14:05] <kgunn> 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] <kgunn> altho i'm sure you or designate will need to take a look
[14:06] <kgunn> and tell me to "improve" potentially :)
[14:07] <jdstrand> 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] <kgunn> cool
[14:08] <kgunn> just doing some clean testing to make sure i'm all  good
[14:38] <Chipaca> pitti: for the record, a delayed network-online results in no gettys for 2m
[14:39] <pitti> Chipaca: hmm, that's bad; so we block user-sessions on that? /me checks
[14:40] <pitti> ah, we had bug 1425376 earlier due to that
[14:40] <pitti> ah, so we block network.target, which is really bad
[14:41] <Chipaca> pitti: it does give me a nice red ascii throbber to look at on console though :)
[14:44] <Chipaca> pitti: this is bad news for my wait4networz service, which ... um ... waits for the networz
[14:45]  * Chipaca should trademark that
[14:49] <Chipaca> pitti: but that bug says it's fixed released; am i missing something?
[14:49] <pitti> Chipaca: yes, it is, I just remembered that we had such a case before
[14:49] <pitti> so we need to find out why network.target is blocked on getting online
[14:50] <pitti> apparently something orders itself after network-online.target but before network.target, and we need to LART it
[14:50] <davmor2> 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] <pitti> 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] <Chipaca> pitti: fwiw ifup-wait-all-auto bailed as expected
[14:53] <davmor2> Chipaca: Thanks Wolverhampton really need a facelift
[14:54] <Chipaca> who says wars don't settle arguments
[14:54] <ogra_> Chipaca, that is because you dont use ifup-wait-all-auto-do-no-bail
[14:55] <Chipaca> ogra_: --pretty-please
[14:55] <davmor2> 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] <ogra_> :)
[14:56] <pitti> 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] <pitti> Chipaca: if you have a journalctl from that boot with the stalled getty, I'd be interested
[14:57] <pitti> Chipaca: (also, stalled -- talking to other folks)
[14:57] <Chipaca> pitti: how can i get journalctl from a stalled boot?
[14:57] <Chipaca> given no network & no getty
[14:58] <pitti> Chipaca: you could boot with systemd.debug-shell, and ctrl+alt+f9
[14:58] <Chipaca> that was it
[14:58] <Chipaca> yep
[14:58] <pitti> Chipaca: or disable your new unit, and just let the standard stuff time out after 2 mins
[14:58] <Chipaca> pitti: i don't know how do disable my new unit :)
[14:58] <pitti> Chipaca: or just plug in ethernet after 2 mins :-) I'm merely interested what's (not) starting until the network comes up
[14:58] <pitti> Chipaca: remove the symlink
[14:59] <Chipaca> pitti: with no network and no getty
[14:59] <pitti> ah
[14:59] <Chipaca> :)
[14:59] <pitti> well, debug shell it is then, I figure :)
[14:59] <pitti> Chipaca: but it does sound like bug 1425376 is back?
[15:00] <Chipaca> pitti: if it ever truly went away, yes
[15:00] <Chipaca> i've seen this spinner before, didn't realise it was a bug
[15:02] <kgunn> jdstrand: so here's my "confined" attempt
[15:02] <Chipaca> pitti: http://paste.ubuntu.com/11954006/
[15:02] <kgunn> https://code.launchpad.net/~kgunn72/mir/snappy-packaging-with-secprofile/+merge/266111
[15:02] <kgunn> jdstrand: so dunno if that's for you or tyler feel free to change
[15:02] <kgunn> also do you want snaps built ?
[15:03] <jdstrand> kgunn: I don't need snaps built
[15:03] <Chipaca> why are we running cloud init on *every* boot? isn't it a firstboot thing?
[15:03] <pitti> Chipaca: oh, cloud-init
[15:03] <Chipaca> sergiusens: do you know^?
[15:03] <pitti> Chipaca: right, cloud-init is indeed blocking gettys, and it takes effing long
[15:03] <kgunn> jdstrand: ok, to test you can follow the "snappy gui anyone" blog
[15:03] <Chipaca> pitti: cloud init depends on network-online afaik
[15:04] <kgunn> the one step not to forget is the "export LC_ALL=C.UTF-8" ;)
[15:04] <jdstrand> kgunn: ok. I probably won't get to this immediately, but will soon
[15:04] <pitti> Chipaca: right, and blocks user sessions
[15:04] <jdstrand> tyhicks: there is already a card for this. I'll assign it to me since I looked at the others
[15:04] <Chipaca> yes, requires: network-online
[15:04] <kgunn> jdstrand: no worries, i just didn't want to drop our responsibility of following up :)
[15:04] <pitti> Chipaca: so if there's no network, cloud-init will block
[15:04] <Chipaca> lurvely
[15:04] <tyhicks> ogra_: are you saying that we use stagefright on our phones?
[15:05] <jdstrand> tyhicks: see #phablet
[15:05] <ogra_> tyhicks, seems we dont use it but there are ~30 .so files in the android container under /system/lib
[15:06] <pitti> Chipaca: OOI, what do you use cloud-init for?
[15:06] <ogra_> accordin to jhodapp they are not used by anything though
[15:06] <pitti> Chipaca: with the r/o file system it can't actually do much, can it?
[15:06] <tyhicks> ogra_: thanks
[15:06] <Chipaca> pitti: I don't know what we use it for, exactly :-)
[15:06] <Chipaca> pitti: i'm hoping sergiusens knows
[15:08] <sergiusens> Chipaca: cloud-init runs on every boot
[15:08] <ogra_> yeah :/
[15:08] <sergiusens> 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] <tyhicks> jdstrand: ack - thanks for taking the review
[15:08] <sergiusens> cloud-init does not run through the whole thing on every boot though
[15:08] <sergiusens> it has run-once's
[15:09] <pitti> right, but it blocks the boot on network-online.target, that's the main problem
[15:09] <pitti> i. e. if you aren't online, it stalls the boot
[15:10] <sergiusens> 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] <Chipaca> 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] <kgunn> 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] <kgunn> where would i find that snap ?
[15:36] <Chipaca> kgunn: i think ted has a snap built with the qml snapcraft plugin
[15:37] <Chipaca> kgunn: otherwise chinstrap.canonical.com/~ories/public_html/digital_sign_deb2snap_tree.tar.bz2 is ollie's (old) thing
[15:37] <Chipaca> kgunn: but you probably meant the qml snapcraft route
[15:37] <kgunn> Chipaca: yeah, preferably latest/greatest
[15:37] <Chipaca> kgunn: um, s.public_html/..
[15:38] <Chipaca> ted might not be here though
[15:38] <Chipaca> 1 sec
[15:38] <Chipaca> kgunn: this is snapcraft with the qml plugin (not merged yet): https://code.launchpad.net/~ted/snapcraft/qml
[15:39] <Chipaca> kgunn: this is a snapcract project that uses it: https://code.launchpad.net/~ted/+junk/photoviewer
[15:39] <kgunn> ta
[15:42] <Chipaca> kgunn: um. there's also the snapcraft ppa
[15:42] <Chipaca> kgunn: because without a patched libxkbcommon some things will fail
[15:42] <kgunn> ah-ha
[15:43] <Chipaca> kgunn: if you're in wily, you already have the patch
[15:44] <Chipaca> kgunn: which we successfully upstreamed, btw :) https://github.com/xkbcommon/libxkbcommon/pull/25
[15:46] <Chipaca> where's golang-uboot-go-dev supposed to be at?
[15:47] <Chipaca> sergiusens: ogra_: any idea? ^
[15:47] <ogra_> never heard of it
[15:47] <Chipaca> ogra_: it's mvo's uboot-go, packaged
[15:47] <Chipaca> it's a build dependency
[15:47] <ogra_> ah
[15:47] <Chipaca> but it doesn't exist
[15:47] <ogra_> well, he didnt want to include it anyway
[15:48] <ogra_> the binary is like 2MB or so
[15:48] <ogra_> so dont bother for now
[15:48] <ogra_> he can handle it when coming back
[15:48] <Chipaca> ogra_: but i can't dpkg-buildpackage without it :-.
[15:48] <ogra_> hmm
[15:49] <ogra_> why would he include uboot-go after telling me it is to big for inclusion
[15:49] <Chipaca> ogra_: i'm not sure what binary you mean, btw
[15:50] <ogra_> the uboot-go binary
[15:50] <Chipaca> ogra_: we need it because bootloader_uboot uses uboot-go/uenv
[15:50] <ogra_> no, it doesnt
[15:50] <Chipaca> yes it does :)
[15:50] <ogra_> it uses fw_setenv/fw_printenv
[15:50] <ogra_> mvo explicitly kept uboot-go out
[15:50] <ogra_> at least he told me so
[15:51] <Chipaca> well ... it's there on trunk
[15:51] <ogra_> hmm
[15:51]  * Chipaca does a bzr pull just in case
[15:52] <ogra_> i only ever worked with the fw_* tools
[15:52] <Chipaca> there's no fw_ in snappy
[15:52] <ogra_> its seeded
[15:52] <ogra_> uboot-tools or some such
[15:52] <Chipaca> ogra_: this uboot-go is the thing that mvo wrote that parses uenv.txt
[15:53] <Chipaca> ogra_: and writes it out without causing reallocations
[15:53] <ogra_> ogra@anubis:~/datengrab/rpi/uboot/bbb/snappy/snappy-systems$ dpkg -S $(which fw_printenv)
[15:53] <ogra_> u-boot-tools: /usr/bin/fw_printenv
[15:53] <Chipaca> ogra_: sure, but nowhere in snappy do we call out to fw_
[15:53] <ogra_> uboot-go is plain go to eventually replace the fw_ tools
[15:53] <ogra_> but today we definitely use fw_*
[15:53] <Chipaca> no we don't -- not in trunk
[15:54] <ogra_> well, thats all i know
[15:54] <Chipaca> not from snappy
[15:54] <Chipaca> :-(
[15:54] <ogra_> http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1183
[15:55] <ogra_> thats the only code i know ... beyond that mvo threw some revisions of a uboot-go binarry over the fence to me to test it for him ... but with the comment that this wont be used yet because it is to big
[15:56] <ogra_> (and afaik uboot-go doesnt use the config from that above merge at all)
[15:57] <ogra_> probably longsleep remembers more
[15:58] <sergiusens> Chipaca: ogra_ https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=uboot&field.status_filter=published&field.series_filter=
[15:58] <ogra_> ah, look
[15:58] <sergiusens> ogra_: as a separate binary maybe, but it is used within snappy itself
[15:58] <ogra_> well, he told me it wouldnt be used
[15:59] <sergiusens> ogra_: in summary, mvo was lazy to dput to the archive or maybe it's stuck in new
[15:59] <ogra_> (i actually thought he exec()s fw_*)
[15:59] <sergiusens> ogra_: nope, he uses the lib, which is fine, doesn't make for a bigger binary
[15:59] <ogra_> yeah
[15:59] <sergiusens> ogra_: btw, what is your g+ exit strategy?
[16:00] <ogra_> i have none yet
[16:00] <ogra_> lets see how it changes
[16:00]  * ogra_ will react on the go ... they dont publish actual plans, do they ? 
[16:00] <ogra_> (apart from ... "we'll split everything out")
[16:03] <longsleep> ogra_: what would i have to remember?
[16:03] <longsleep> ogra_: reading backlog now
[16:03] <Chipaca> and now tests under dpkg-buildpackage fail in very weird ways
[16:03] <Chipaca> siiigh
[16:03] <ogra_> longsleep, seems all solved ... (what was up with uboot-go)
[16:03] <longsleep> ogra_: all right
[16:08] <longsleep> ogra_: so whats the result of your discussion, fw_* is used or the go tool?
[16:09]  * longsleep has used both
[16:09] <ogra_> seems snappy internally doesnt use fw_*
[16:10] <longsleep> yeah that was what i had remember from last week as well - i think the fw_* tools were just for us to test stuff, but snappy internally was using the go library?
[16:10] <longsleep> seems that is the conclusion you reached as well?
[16:11] <ogra_> yeah, thats apparently the bit i missed
[16:11] <longsleep> well i did not check the go code what it actually does
[16:11] <ogra_> itr is the conclusion Chipaca reached by reading the code :)
[16:12] <longsleep> ah great - so the fw_* tools could go away in favor of the uboot-go commandline tool eventually
[16:12] <Chipaca> longsleep: i think they're still used to build the image though
[16:12] <Chipaca> that is, used from livecd or whatever it's called
[16:12] <longsleep> oh ok
[16:12] <Chipaca> which might be where the confusion comes from
[16:12] <longsleep> what does the livecd builder do with it?
[16:12] <Chipaca> snappy uses a go lib, because it's more careful about some things that cause corruption
[16:13] <Chipaca> but livecd-rootfs uses the fw_ tools still, presumably because there's no benefit to using a (rather massive) binary at that point
[16:13] <Chipaca> longsleep: um. Dark magic, if you ask me. :-)
[16:13] <ogra_> no, nothing uses it
[16:13] <ogra_> we could unseed it
[16:14] <longsleep> +1 - what could it be used for
[16:14] <ogra_> we use mkenvimage or what it is called during oem snap creation from the u-boot upstream tree
[16:14] <ogra_> and then dont touch the env file anymore
[16:15] <longsleep> right thats what i do when building the oem snap as well
[16:15] <ogra_> ogra@anubis:~/datengrab/rpi/uboot/bbb/snappy/snappy-systems$ apt-cache show  u-boot-tools|grep ^Installed
[16:15] <ogra_> Installed-Size: 203
[16:15] <ogra_> its not like it takes any space though
[16:15] <longsleep> fw_* writes or reads env files, so why that would be required doring rootfs build i cannot see
[16:15] <longsleep> ogra_: right
[16:16] <longsleep> ogra_: problem is that people might use the tools and eventually corrupt their env file (remember the 4 vs 5 byte header?)
[16:16] <ogra_> otoh people might use them to debug stuff without trashing the file :)
[16:16] <longsleep> ogra_: i mean the scary configuration file the fw_ tools needs is reason enough to get rid of them :)
[16:17]  * ogra_ doesnt see an urgent reason to drop the tools
[16:17] <Chipaca> sergiusens: poke (again) :)
[16:17] <longsleep> yeah they do not hurt
[16:18] <ogra_> they should be dropped once we do a general cleanup though ... one where every byte counts :)
[16:18] <ogra_> for the moment i'd leave them there
[16:41] <Chipaca> pitti: in snappy we're using dh_systemd_enable; how do i add something to wants using that?
[16:41] <Chipaca> pitti: never mind, thank you :)
[16:41] <Chipaca> i should take a break
[17:20] <Rlyeh> Hi
[17:20] <Rlyeh> Guys, where is "ubuntu-core" config file? I just can't find config file to change!
[17:21] <Rlyeh> Since "ubuntu-core" isn't a snap, ther is no any 'package.yaml '
[17:21] <beuno> Rlyeh, what are you trying to change?
[17:22] <Rlyeh> Timezone :(
[17:22] <beuno> Rlyeh, you change it through the command line
[17:22] <ogra_> you should be able to change that via the snappy config command
[17:23] <Rlyeh> "snappy config ubuntu-core" ? It just return vealues
[17:24] <Rlyeh> How can I do that?
[17:26] <ogra_> bug 1472788 has some hints irc
[17:28] <Rlyeh> This means it's not possible to change "ubuntu-core" config file?
[17:28] <beuno> Rlyeh, it's a read-only files system  :)
[17:28] <beuno> it takes config via a command line
[17:29] <Rlyeh> I knew that, but didn't thought "ubuntu-core" is read-only too!
[17:30] <Rlyeh> So, I can't change the timezone? :(
[17:30] <ogra_> Rlyeh, did you read the bug ?
[17:31] <ogra_> it has an example how to change the timezone
[17:32] <Rlyeh> No, in time, i'm using xchat on my BBB using debian, It's too slow to open a browser, but I'll check it on my PC
[17:32] <Rlyeh> Thank you all :)
[17:34] <longsleep> What is wrong when my snappy just says 'Invalid package on system' ?
[17:35] <longsleep> a colleague of mine just has that problem
[17:35] <ogra_> good question
[17:35] <ogra_> Rlyeh, snappy config ubuntu-core - <(echo -e 'config:\n ubuntu-core:\n timezone: Europe/Berlin\n')
[17:35] <ogra_> Rlyeh, that sets it to berlin for me
[17:35] <longsleep> i cant even 'snappy list'
[17:35] <ogra_> wow
[17:36] <longsleep> He was even using a pre built image Run vagrant init http://cloud-images.ubuntu.com/snappy/15.04/core/stable/current/core-stable-amd64-vagrant.box
[17:37] <Rlyeh> Thank you ogra, very much :)
[17:40] <ogra_> longsleep, broken clock or something ?
[17:40]  * ogra_ has seen weird behavior when the clock was massively off
[17:40] <longsleep> no that does not seem to be it
[17:40] <longsleep> i can reproduce
[17:40] <longsleep> hold on
[17:41] <longsleep> mhm or not :/
[17:42] <longsleep> something is strange there
[17:42] <longsleep> (amd64)root@ubuntu-core-stable-3:~# date
[17:42] <longsleep> -su: /bin/date: Input/output error
[17:42] <longsleep> wtf?
[17:43] <ogra_> disk screwed up ?
[17:43] <ogra_> (dmesg ? )
[17:43] <longsleep> mhm he deleted and reinstalling already
[17:44] <longsleep> lets see if he breaks it again
[17:48] <longsleep> mhm looks like it works now - disk must have been broken
[19:55] <elopio> I'm back.
[19:55] <elopio> mterry: are you happy with this one? https://code.launchpad.net/~elopio/snapcraft/fix1476452-python_log/+merge/265354
[19:57] <mterry> elopio, ah nice, missed your comment
[19:57] <mterry> elopio, I'm in the middle of something now but will re-review
[19:57] <elopio> mterry: ok, thanks.
[20:45] <mterry> elopio, looking at your branch -- now some things are bold that weren't before
[20:46] <mterry> elopio, look at the diff in LP and you can see some things were just print() lines before
[20:46] <mterry> elopio, specifically when we ran a subcommand, it would not be bold
[20:46] <mterry> elopio, and a couple tiny other places
[20:46] <mterry> elopio, what's the cleanest way to distinguish there?  Use another logger command than info?