[03:49] <biezpal> jdstrand, hey, sorry high latency :)
[03:51] <biezpal> jdstrand, again about ubuntu-core-launcher apparmor profile - remounted / to rw, added "/dev/null rw" and everything worked
[03:52] <biezpal> jdstrand, how we can do the same without remounting ro volume?
[03:53] <biezpal> jdstrand, Isn't a read access to /dev/null a normal behavior for app?
[03:53] <biezpal> *write
[04:06] <jjohansen> biezpal: PoLP, its not used by many apps
[04:07] <jjohansen> if ubuntu-core-launcher is using it then we need to make sure it gets added to the profile so that it is there as part of the ro image
[04:09] <biezpal> jjohansen, ok, then how could I run my app?
[04:09] <biezpal> without changing ubuntu-core-launcher profile
[04:10] <jjohansen> I would assume, that there is an abstraction that allows it, if not there should be
[04:10] <jjohansen> or you could go the route of additional rules
[04:10] <jjohansen> I think that would trigger a rule
[04:11] <jjohansen> s/rule/review/
[04:12] <jjohansen> eg. the permy app has additional read paths set, and additional write paths
[04:12] <jjohansen> oh hrmm, just check not additional write, but additional read
[04:13] <jjohansen> I'd have to lookup how to specify that in the manifest
[04:13] <biezpal> but the problem is that ubuntu-core-launcher cannot write to /dev/null, even before my app starts
[04:13] <biezpal> apparmor="DENIED" operation="file_inherit" profile="/usr/bin/ubuntu-core-launcher" name="/dev/null" pid=17552 comm="ubuntu-core-lau" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
[04:14] <jjohansen> biezpal: then the ubuntu-core-launcher app is missing a rule it needs, its profile will have to be updated
[04:15] <jjohansen> you can remount and run your app locally but until that change rolls out ...
[04:15] <biezpal> jjohansen, I've added /den/null rw to the launcher profile as jdstrand advised and everything became ok
[04:16] <biezpal> so, we should wait until next Snappy update?
[04:17] <jjohansen> right, it needs to be updated in the base image, other wise other people won't be able to run it without doing the remount, and adding of the permission
[04:17] <biezpal> jjohansen, ok, thank you. Waiting for update :)
[07:11] <dholbach> good morning
[07:16] <biezpal> good morning
[08:37] <ogra_> off to the dentist ...
[09:23] <Chipaca> ogra_: you have all the fun
[09:29] <Chipaca> whee! in wily rolling we now can do "sudo snappy service xkcd-webserver stop" \o/
[09:29] <Chipaca> also "snappy man|less"
[09:29] <Chipaca> which is only useful if you can read troff
[09:29] <Chipaca> :)
[09:34] <biezpal> wow, nice
[10:01]  * ogra_ sees the recent systemd discussion on ubuntu-devel-discuss and wonders if "snappy service" was such a clever idea :P
[10:01] <ogra_> (oh, and re ... :))
[12:04] <Chipaca> woo, random-versioned sideloaded packages works
[12:04] <Chipaca> the tests are all grumpy tho
[13:13] <jdstrand> biezpal: re /dev/null and remounting> for now, you can't do anything else. it is a bug in the launcher. we should get it fixed
[13:15] <Chipaca> jdstrand: what's the bug?
[13:17] <jdstrand> Chipaca: lack of /dev/null rw in the profile
[13:18] <jdstrand> Chipaca: I am preparing an upload for wily as we speak
[13:18] <Chipaca> ahh
[13:18] <Chipaca> ok :)
[13:18] <Chipaca> jdstrand: i read "bug in the launcher" as something wrong in the c code
[13:18] <jdstrand> Chipaca: are you guys planning an upload for the launcher for vivid?
[13:18] <jdstrand> if not, I'll upload to the ppa too
[13:18] <Chipaca> jdstrand: i know of no such plans
[13:19] <Chipaca> jdstrand: which says more about how much attention i'm paying to that kind of plans than of the plans themselves
[13:19] <jdstrand> haha
[13:19] <jdstrand> well, the launcher has been pretty stable for a while. I'll just do the upload :)
[13:20] <Chipaca> which reminds me
[13:21] <Chipaca> elopio: with yesterday's image, amd64 and armhf images should now have a network interface on first boot
[13:21] <Chipaca> let me confirm that just in case
[13:24] <Chipaca> yep! just booted kvm, got an iface right away
[13:24] <Chipaca> \o/
[13:34] <jdstrand> biezpal: ok, uploaded fix to wily and the image ppa. the fix should be in edge in the next image or two
[13:34] <longsleep> Chipaca: will the random sideload version stuff available in 15.04 eventually?
[13:39] <beowulf> hi, can anyone tell me why the store gives me these errors with a snap that doesn't define any apparmor profiles? http://pastebin.ubuntu.com/12124699/
[13:39] <beowulf> it's just a test snap for working in the store, the package.yaml is http://bazaar.launchpad.net/~stephen-stewart/+junk/test-snap/view/head:/meta/package.yaml
[13:41] <jdstrand> beowulf: what version of snappy are you using to create those packages?
[13:42] <jdstrand> beowulf: it seems you are using a very old version...
[13:44] <Chipaca> longsleep: sergiusens said yes
[13:44] <Chipaca> longsleep: i am not so sure :) but hope so
[13:45] <Chipaca> elopio: i'm still getting “adt-virt-ssh: WARNING: ssh connection failed. Retrying in 3 seconds...” from the integration tests
[13:45] <Chipaca> elopio: which is a bummer, because i'm pretty sure i'm breaking them with this branch
[13:46] <beowulf> jdstrand: oops, yes i am, thanks!
[13:49] <Chipaca> longsleep: btw, i & we have been calling it "random version", but that didn't really work, so it's a monotonically increasing version instead
[13:49] <Chipaca> longsleep: that if you look really carefully just happens to be the current time in nanoseconds, in base36
[13:50] <Chipaca> which is fairly arbitrary, but (1) is reasonably monotonically increasing for our purpose, and (2) is a one-liner to implement :)
[14:55] <elopio> Chipaca: checking...
[15:01] <elopio> Chipaca: it's working for me.
[15:01] <elopio> Chipaca: can you paste the log somewhere to see the adt messages?
[15:10] <elopio> Chipaca: All good, what could possibly go wrong
[15:10] <elopio> \o/
[15:12] <Chipaca> elopio: http://pastebin.ubuntu.com/12125512/
[15:20] <elopio> Chipaca: http://paste.ubuntu.com/12125594/
[15:22] <elopio> plars: do you want to jump into a hangout to set up the manifest details?
[15:23] <longsleep> Chipaca: sounds good and will not give dups when developing
[15:23] <Chipaca> elopio: https://code.launchpad.net/~chipaca/snappy/schmideload/+merge/268498
[15:23] <Chipaca> longsleep: yep
[15:27] <plars> elopio: sure
[15:27] <plars> elopio: I'm not sure the manifest bits work right now, ask ev about that
[15:27] <plars> elopio: I have no idea how they are used either... but we can talk about a spec
[15:35] <elopio> plars: https://plus.google.com/hangouts/_/canonical.com/qa?authuser=0
[15:35] <clobrano> hi all :) is there a way to have a second terminal on snappy (virtual consoles do not seem to work)?
[15:36] <ogra_> well, whatever the systemd way of enabling more is ...
[15:37] <ogra_> sudo systemctl enable getty@tty2.service
[15:37] <ogra_> sudo systemctl start getty@tty2.service
[15:37] <ogra_> that seems to work
[16:01] <elopio> Chipaca: All good, what could possibly go wrong
[16:02] <elopio> that was running with the snappy binary from your branch, faking the updates and rollbacks.
[16:02] <elopio> do you want me to run something else, like real updates from a specific image #?
[16:07] <elopio> Chipaca: ah, I think your branch only modifies the sideloaded snaps. We don't have integration tests for that, so of course they all pass.
[16:08] <Chipaca> elopio: \o/
[16:08] <elopio> I'm not sure how to test sideloads. We would have to receive arguments with the snaps that you want to install, and write tests for those snaps, that maybe will install from the store only if they are not already installed.
[16:09] <elopio> I'll add a card to trello.
[16:10] <elopio> Chipaca: https://trello.com/c/02SDJD9x/198-tests-for-sideloaded-snaps in case you want to add requirements.
[16:49] <Chipaca> elopio: 198 tests for sideloaded snaps is probably a bit much :)
[16:51] <elopio> Chipaca: that's what you say now, but let's talk again when the missing test #199 breaks a stable release.
[16:51] <Chipaca> elopio: dealopio
[17:17] <elopio> plars: I triggered a test.
[17:18] <plars> elopio: yeah, I just heard the relays firing :)
[17:18] <elopio> plars: that's fast :D
[17:18] <plars> elopio: right, at this point it's just booting back to a stable image it can flash the sd card from
[17:19] <plars> elopio: so it'll be booting the emmc right now, creating/flashing your image will take a bit longer obviously
[17:28] <plars> elopio: sounds like it just booted the test image