[06:30] <dholbach> good morning
[07:27] <davidcalle> Good morning!
[08:00] <seb128> hey there, not sure who has topic edit right, but you might want to "snappy-ubuntu" -> "snappy" in the Bugs launchpad url
[08:08] <beowulf> morning
[08:32] <JamesTait> Good morning all; happy Weights and Measures Day! 😃
[08:40] <Chipaca> mo'in!
[08:41] <Chipaca> mvo: hi there
[08:41] <mvo> hey Chipaca
[08:41] <ogra_> yo
[08:42] <Chipaca> mvo: I called it packageYaml.dirname because there's already Dirname(part)
[08:42] <Chipaca> mvo: also because no other word described what it did
[08:42] <Chipaca> was tempted by fqdn too
[08:42] <Chipaca> mvo: i mean: "no other word described what it did" applied more to when i worte Dirname(part)
[08:43] <Chipaca> mvo: fullname comes close, but isn't descriptive
[08:43] <mvo> Chipaca: I kind of like fqdn better, dirname pops images of directory structures into my brain, but like I said, maybe thats just me :)
[08:43] <Chipaca> mvo: otoh i know dirname is not immediately obvious
[08:44] <mvo> I guess namespacedName is too long :/
[08:44] <Chipaca> mvo: also, wrong
[08:44] <Chipaca> mvo: because it's not namespaced if it's a framework or a gadget
[08:44] <mvo> aha, because for frameworks its not
[08:44] <mvo> meh
[08:44] <Chipaca> quite :)
[08:44] <mvo> fqn() :) ?
[08:44] <mvo> fqsn() - full-qualified-snap-name?
[08:45] <mvo> but I can life with dirname(), I just wish we had a better name
[08:49] <Chipaca> nameMaybeNamespaced
[08:50] <Chipaca> although Maybe makes me think it's either the namespaced name, or nil
[08:51]  * mvo nods and scratches head
[09:05] <dholbach> mvo, in the package.yaml - am I supposed to use "name: appname" or "name: appname.username"?
[09:05] <Chipaca> dholbach: name: appname
[09:05] <dholbach> it looks like the former (else I get "package name with namespace not supported")
[09:05] <dholbach> ok
[09:05] <dholbach> thanks Chipaca
[09:05] <Chipaca> dholbach: the origin does not go in the yamel
[09:06] <dholbach> ok cool
[09:07] <dholbach> ogra_, can you pull from lp:~dholbach/+junk/chatroom?
[09:07] <dholbach> ogra_, ... and have a look at https://code.launchpad.net/~dholbach/node-snapper/update/+merge/259584?
[09:08] <ogra_> dholbach, oh, nice, but i dont think that will work for non wily ... the cdimage url is completely different for released tarballs
[09:09] <dholbach> ogra_, distro-info will always give you the current release
[09:09] <dholbach> err, current development release
[09:09] <ogra_> dholbach, right
[09:10] <ogra_> ogra@anubis:~/datengrab/holbi$ wget http://cdimage.ubuntu.com/ubuntu-core/daily/current/trusty-core-armhf.tar.gz
[09:10] <ogra_> 2015-05-20 11:10:07 FEHLER 404: Not Found.
[09:10] <dholbach> mh?
[09:10] <ogra_> the REM_ vars need to be adjusted too ...
[09:11] <ogra_> daily/current/$DIST...tar.gz only works for the durrent devel release
[09:11] <ogra_> *current
[09:11] <dholbach> right... I though that the current dev release is what we want?
[09:11] <ogra_> if you ran node-snapper on a trusty system DIST would be set to trusty
[09:12] <ogra_> but that url only works for wily :)
[09:12] <seb128> does anyone has topic edit right/saw my comment earlier?
[09:12] <ogra_> dholbach, for trusty the url would have to be http://cdimage.ubuntu.com/ubuntu-core/releases/trusty/release/ubuntu-core-14.04-core-armhf.tar.gz
[09:13] <ogra_> (note the different tarball name (along with the different path)
[09:13] <dholbach> ogra_, ok... I thought distro-info-data was backported for trusty, etc
[09:13] <dholbach> then we probably just update the string to 'wily' and be done with it :/
[09:13] <dholbach> seb128, sorry, no op privileges here :/
[09:13] <ogra_> oh
[09:14] <ogra_> ogra@anubis:~/datengrab/holbi$ distro-info -d
[09:14] <ogra_> ubuntu-distro-info: Distribution data outdated.
[09:14] <ogra_> Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details.
[09:14] <ogra_> heh
[09:14] <ogra_> i guess thats the problem here
[09:14] <dholbach> right
[09:14] <seb128> dholbach, ok, no worry, hey btw :-)
[09:14] <dholbach> hey seb128
[09:15] <ogra_> hrm
[09:15] <ogra_> apt doesnt think it is outdated ... weird
[09:15] <dholbach> ogra_, I'll leave it up to you to either update your trusty vm or just use 'wily' as string in the script - 'vivid' doesn't work :)
[09:15] <ogra_> yeah, i have the wily change local, just not merged yet
[09:15] <dholbach> ok ok
[09:15] <ogra_> yours appears better though
[09:15] <ogra_> (saving me from updating every cycle)
[09:16] <ogra_> yeah, works after update ...
[09:17] <dholbach> <3
[09:19] <dholbach> ogra_, I'm turning your blog entry into a tutorial, that's why I was verifying all the steps
[09:19] <ogra_> merged and pushed
[09:20] <dholbach> both? :)
[09:20] <ogra_> no, looking at the chatroom one now
[09:20] <dholbach> thanks ogra_
[09:21] <ogra_> i cant buiuld snaps here due to a bug in the verification for "ports" :/
[09:21] <dholbach> really?
[09:21] <ogra_> yeah
[09:21] <dholbach> which version of snappy do you have installed?
[09:21] <dholbach> is this vivid?
[09:21] <ogra_> trusty
[09:21] <ogra_> latest from the PPA
[09:21] <ogra_> snappy-tools is 10
[09:22] <ogra_> click-reviewers-tools is 0.26~snappy0.14.04.1
[09:22] <dholbach> and ubuntu-snappy-cli?
[09:22] <ogra_> 0.1.2-1+419~ubuntu15.04.1
[09:22] <ogra_> aha
[09:22] <dholbach> 1.0.1-1+439~ubuntu15.04.1
[09:23] <ogra_> yeah, just noticed
[09:23] <dholbach> from https://launchpad.net/~snappy-dev/+archive/ubuntu/beta
[09:23] <dholbach> man... you're years behind!
[09:24] <ogra_> ogra@anubis:~/datengrab/snaps$ snappy build snap-inspector-term/
[09:24] <ogra_> Generated 'snap-inspector-term_0.1-1_multi.snap' snap
[09:24] <ogra_> YAY !!!!
[09:24] <dholbach> yeeeeeeeehaw
[09:24] <ogra_> dholbach, did you try rolling a chatroom snap with that change ?
[09:24] <ogra_> (i'm surprised there is not more to change)
[09:25] <ogra_> doesnt complain though ...
[09:25]  * ogra_ merges
[09:27] <ogra_> and pushed
[09:28] <dholbach> hanks!
[09:28] <dholbach> thanks!
[09:33] <dholbach> ogra_, if you create the snap like that and sideload it using snappy-remote... does the chatroom app work for you?
[09:35] <ogra_> dholbach, no, if i create it like that the whole of node-snapper is missing :)
[09:35] <ogra_> cant work
[09:35] <ogra_> you need to follow the steps ;)
[09:36] <dholbach> I think I did
[09:36] <dholbach> http://pastebin.ubuntu.com/11241760/
[09:36] <ogra_> right, i didnt :)
[09:36] <dholbach> ahhhhhh ok :)
[09:37] <ogra_> i dont think you can start a snap service like that
[09:37] <dholbach> I was just trying to debug why it didn't start up
[09:37] <ogra_> use systemctl ... and watch syslog
[09:38] <ogra_> well, the PATH isnt right ... and you will mis all the env vars when just calling it with sh
[09:38] <dholbach> what would the systemctrl invocation be?
[09:39] <ogra_> not sure if we still redirect stdout to syslog, but you could switch to "set -ex"
[09:39] <ogra_> systemctl | grep chatroom
[09:39] <ogra_> that gives you the service  name
[09:40] <dholbach> sorry, I meant... how do I use systemctl to start the chatroom?
[09:42] <ogra_> systemctl start <name of service from teh grep command>
[09:42] <ogra_> probably sudo too :)
[09:42] <dholbach> I don't see it listed there
[09:46] <ogra_> yeah, just noticing the same with my snap-inspector-term
[09:46] <ogra_> seems the systemd handling changed
[09:47] <ogra_> (my snappy knowledhge is about as outdated as that package above was :) )
[09:49] <Chipaca> mvo: pushed with 'qualifiedName'
[09:50] <ogra_> does anyone know how systemd for snaps changed ... is that documented anywhere ?
[09:50] <ogra_> (i dont see a unit for my snap ... )
[09:51] <Chipaca> ogra_: changed when?
[09:52] <Chipaca> ogra_: hasn't changed :)
[09:52] <Chipaca> in ages. two weeks at least.
[09:52] <ogra_> Chipaca, well, i'm using a snap that works fine on my really old (several months) snappy install
[09:52] <ogra_> i re-built with a new snappy (fixed all complaints) and installed it ...
[09:53] <ogra_> systemctl doesnt list it ...
[09:54] <ogra_> (and it obviously doesnt autostart as it used to)
[09:57]  * ogra_ sees /apps/snap-inspector-term.sideload/0.1-1/meta/snap-inspector-term.snappy-systemd but nothing installed anywhere else
[09:59] <Chipaca> ogra_: interesting
[10:00] <ogra_> i see it attempted to start in syslog
[10:00] <ogra_> (amd64)ubuntu@localhost:~$ systemctl list-units| grep inspector
[10:00] <ogra_> (amd64)ubuntu@localhost:~$
[10:01] <ogra_> (amd64)ubuntu@localhost:~$ sudo grep Inspect /var/log/syslog
[10:01] <ogra_> May 20 09:43:27 localhost systemd[1]: Started Inspect the environment of a snap package in a browser.
[10:01] <ogra_> May 20 09:43:27 localhost systemd[1]: Starting Inspect the environment of a snap package in a browser...
[10:03] <Chipaca> ogra_: sudo systemctl | grep -i inspector
[10:03] <ogra_> no change ...
[10:03] <Chipaca> hrmph
[10:04] <Chipaca> ogra_: note the sudo there
[10:04] <ogra_> yeah, i tried with and without
[10:04] <Chipaca> ogra_: what's your package.yaml like?
[10:05] <ogra_> http://paste.ubuntu.com/11242104/
[10:05] <Chipaca> systemd usually prints *something* if it tried to start it. and you say there isn't a file in /etc/systemd/system for your service?
[10:06] <ogra_> there is
[10:06] <Chipaca> ah! what's it called?
[10:06] <ogra_> but systmctl doesnt seem to know about it
[10:06] <ogra_> snap-inspector-term_snap-inspector-term_0.1-1.service
[10:08] <Chipaca> ogra_: and “systemctl status snap-inspector-term_snap-inspector-term_0.1-1” isn't helpful?
[10:08] <ogra_> ok, calling it gets me a start event
[10:08] <ogra_> but it doesnt start and there is no stdout debug output in any log :/
[10:09] <ogra_> do we exclude snaps from list-units for security reasons ?
[10:11] <ogra_> also how do i get the old verbosity back ?
[10:11] <Chipaca> ogra_: no, they're always there
[10:11] <ogra_> we used to redirect stdout of the started script to journald ... seems that is suppressed now
[10:12] <ogra_> which makes debugging really hard ...
[10:12] <Chipaca> ogra_: i'm not aware of that having changed
[10:13] <ogra_> May 20 10:07:12 localhost.localdomain sudo[3133]: ubuntu : TTY=pts/1 ; PWD=/home/ubuntu ; USER=root ; COMMAND=/bin/systemctl start snap-inspector-term_snap-inspector-term_0.1-1.service
[10:13] <ogra_> May 20 10:07:12 localhost.localdomain sudo[3133]: pam_unix(sudo:session): session opened for user root by ubuntu(uid=0)
[10:13] <ogra_> May 20 10:07:12 localhost.localdomain systemd[1]: Started Inspect the environment of a snap package in a browser.
[10:13] <ogra_> May 20 10:07:12 localhost.localdomain systemd[1]: Starting Inspect the environment of a snap package in a browser...
[10:13] <ogra_> that is all i get
[10:13] <Chipaca> ogra_: let me start with a fresh image here, as i'm not seeing what you're seeing
[10:13] <Chipaca> ogra_: what image are you on?
[10:13] <ogra_> even with the start-service.sh script set to "set -x"
[10:13] <ogra_> the kvm image currently ...
[10:13] <ogra_> the released one
[10:13] <Chipaca> ogra_: rollin'?
[10:13] <ogra_> no, whatever is in the default docs for kvm
[10:14] <ogra_> 15.04 image ....
[10:14] <Chipaca> ogra_: can you give me the command you used to create the image?
[10:14] <ogra_> i didt
[10:14] <ogra_> *didnt
[10:14] <ogra_> wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz
[10:14] <ogra_> :)
[10:15]  * Chipaca wgets
[10:16] <ogra_> the script is surely still having issues (using SNAPP in the var names etc) ... but i kind of would expect that i can get some more verbose output from the failed start
[10:17] <Chipaca> you should
[10:17] <Chipaca> and it also should be in list-units
[10:17] <Chipaca> (which is the default command, btw; you don't need to say it)
[10:18] <ogra_> right
[10:18] <ogra_> well. it definitely isnt ...
[10:18] <ogra_> but this time rount it at least seems to respect the set -x ... i see a bit more output
[10:18] <Chipaca> ogra_: can you try whether the xkcd one works?
[10:21] <dholbach> installing it through webdm this at least works:
[10:21] <dholbach> (amd64)ubuntu@localhost:~$ sudo systemctl | grep -i xkcd
[10:21] <dholbach>   xkcd-webserver_xkcd-webserver_0.5.service                                                loaded active running   A fun webserver
[10:21] <dholbach> (amd64)ubuntu@localhost:~$
[10:21] <dholbach> and ps shows:
[10:21] <dholbach> /usr/bin/python3 /apps/xkcd-webserver.canonical/0.5/bin/xkcd-webserver
[10:21] <zyga> asac: hey
[10:22] <Chipaca> dholbach: and systemctl status xkcd-webserver_xkcd-webserver_0.5.service should be nice too
[10:22] <Chipaca> http://excellent.mezgr.de/snappy
[10:22] <ogra_> yeah, all fine with that
[10:23] <Chipaca> ogra_: can you put your snap somewhere so i can give it a poke?
[10:24] <ogra_> sure
[10:24] <ogra_> i would prefer to get proper output from the startup though .,... to be able to fix it myself
[10:25] <ogra_> using set -x doesnt give me any error output
[10:25] <ogra_> oh, and i see why
[10:25] <ogra_> there is an "ubuntu-core-launcher" that seems to swallow it
[10:25] <ogra_> thats not on my old snappy installs
[10:26] <Chipaca> the launcher shouldn't affect stdout/stderr
[10:26] <ogra_> http://paste.ubuntu.com/11242416/
[10:26] <ogra_> well, i seem to get stdout ...
[10:26] <asac> zyga: hello
[10:26] <ogra_> but since the start fails i would also expect something on stderr
[10:27] <ogra_> the paths look all ok
[10:27] <Chipaca> this reminds me, mvo: when you've got a sec, we should discuss the launcher private tmp branch thing
[10:30] <zyga> asac: I'd like to schedule a call with you, it's not urgent, I'd like to talk about snappy certification
[10:31] <ogra_> Chipaca, hmm, i suspect there is something wrong with the node binary actually ... setting all the vars manually and trying to run it it just silently returns
[10:32] <mvo> Chipaca: right after lunch maybe? so in about 1h? or now but then I don't know how much time I have until lunch is ready :)
[10:33] <Chipaca> mvo: basically, making the tmpdir predictable opens us up to nasty attacks
[10:33] <Chipaca> mvo: so we either need to be very careful, or we use mkdtemp
[10:33] <Chipaca> mvo: leaning towards the latter myself. think about it and tell me after lunch maybe :)
[10:35] <ogra_> yay, now i get roper ouutput
[10:35] <ogra_> *proper output
[10:36] <mvo> Chipaca: my gut feeling is mkdtemp too, being careful is not my strength and its also hard to get right IME (i.e. hard to be careful enough :/
[10:37] <mvo> Chipaca: I have not looked at this branch yet, I need to do that
[10:37] <Chipaca> ogra_: yay
[10:37] <Chipaca> mvo: tyhicks is looking :)
[10:39] <ogra_> bah, and now apparmor gets in my way
[10:51] <Chipaca> ogra_: these security modules, coming over here, stealing our jobs
[10:51] <ogra_> heh
[10:51] <ogra_> "stealing our jooobs"
[10:52] <ogra_> well, the package is a mess ... (apparently) ...
[10:54] <Chipaca> mvo: also about the launcher, what do you think of changing it so we pass in all the bits and it creates the environ 'from scratch'?
[10:58] <ogra_> what dholbach tried above seems to be very typical when debugging (just running the start script with "sh -x" ) ... is there a way to manually run the launcher instead ... heanding the path to the script to it to be able to debug ?
[10:58] <ogra_> if so we need to put it in the docs ... if not, it would be nice to have such a feature :)
[11:04]  * ogra_ just tries using /usr/bin/ubuntu-core-launcher ... seems it doesnt set a single var ...
[11:10] <ogra_> \o/
[11:10] <ogra_> finally got it working
[11:11] <ogra_> hmm, semi-working it seems
[11:24] <dholbach> ogra_, did you update the branch already? :)
[11:25] <sergiusens> Chipaca: I see mvo was not as lazy as me and commented on the review :)
[11:25] <ogra_> dholbach, yes
[11:25] <sergiusens> good morning btw!
[11:25] <ogra_> all your changes should be pushed
[11:25] <Chipaca> sergiusens: yeah, i'm thinking of firing you as a reviewer and getting another mvo instead
[11:25] <sergiusens> mvo: btw, I discussed this with Chipaca yesterday http://snappy.asac.ws:9001/p/dot.store can I get your thoughts?
[11:25] <Chipaca> sergiusens: he's not as mean
[11:25] <sergiusens> Chipaca: :(
[11:25] <sergiusens> Chipaca: you are mean!
[11:26] <sergiusens> :-P
[11:26] <Chipaca> sergiusens: only because you like it!
[11:26] <dholbach> ogra_, what's still missing?
[11:27] <sergiusens> Chipaca: in any case, I didn't find anything that bothered me, and planned to look at again today, so there
[11:27] <ogra_> dholbach, dunno, i have to run through the whole howto again ...
[11:27] <Chipaca> sergiusens: neener neener
[11:27] <ogra_> (just trying to debug the other snap now, i'll move over to chatroom after that)
[11:27] <dholbach> ogra_, ok, I'll try as well
[11:28] <sergiusens> Chipaca: should I base my origin change on top of this one or are there more coming?
[11:29] <asac> sergiusens: that one is very cryptic
[11:29] <asac> not clear what it is proposing
[11:30] <ogra_> asac, can you fix the bug link in the topic to not use snappy-ubuntu ?
[11:30] <ogra_> (seems it is readonly)
[11:30] <Chipaca> sergiusens: there's going to be "more coming" all week :)
[11:31] <Chipaca> sergiusens: this one is probably a good place for it as any
[11:31] <Chipaca> sergiusens: next one *should* be the move to make a lot of things methods on SnapPart, but i've had branches pop up in the middle of this before now :)
[11:39] <asac> ogra_: i have no idea how to change anything wrt access settings etc... so just changed it. if we want to change acls etc. or you need op powers talk to lool :P
[11:39] <asac> or i think it was beuno
[11:40] <ogra_> i'm not eager to get op powers ... usually if there is a troll i'm still searching for the right commands to gain OP when someone else already kicks him :)
[11:43] <rickspencer3> is this really the right way to set up wifi on my bbb?
[11:43] <rickspencer3> http://www.marinus.nu/2015/02/enabling-wifi-on-snappy-ubuntu-core.html
[11:43] <rickspencer3> seems like making the partition rw is sub-optimal
[11:45] <Chipaca> rickspencer3: if it needs you to set the partition rw, it is not the right way
[11:45]  * Chipaca reads
[11:47] <Chipaca> rickspencer3: we're shipping wpa_supplicant already
[11:47] <Chipaca> rickspencer3: so the post is wrong, but also outdated
[11:47] <rickspencer3> Chipaca, so I just need to drop a config file somewhere?
[11:48] <ogra_> looks like
[11:48] <Chipaca> rickspencer3: beats me :) but either drop it or edit it
[11:48] <Chipaca> (i can find out, certainly, but i don't know offhand)
[11:52] <mvo> Chipaca: launcher> if you mean that instead of generating all this env madness in the wrapper script it should go into the launcher, thats a plus one from me, we just need to make sure that we do as little as possilbe in the part that runs as root, but thats obvious anyway :)
[11:52] <Chipaca> mvo: it would mean changing the way we call the launcher (we need to give it the version and origin and some other stuff)
[11:53] <mvo> sergiusens: reading the etherpad now
[11:53] <mvo> Chipaca: yeah, I'm fine with that as long as its not too ugly :)
[11:54] <Chipaca> mvo: the alternative being to parse yaml in C
[11:54] <Chipaca> *shudder*
[11:54] <mvo> LOL
[11:54] <mvo> as root!
[11:54]  * mvo drops dead in shock
[12:01] <mvo> sergiusens: dot.store looks good, I'm a bit unhappy that /frameworks and /apps have a different dir layout now, i.e. one with /$origin/ in there and the otherwithout, but its not a big deal and probably unavoidable, I guess I just like symmetry :) I will add some inline comments
[12:02] <beuno> ogra_, I haz the power
[12:02] <beuno> (so does the ubuntu IRC council)
[12:02] <ogra_> yeah, thats usually my last resort :)
[12:03] <beuno> ogra_, happy to give you access
[12:03] <ogra_> nah, i'm find pinging someone with power ... we usually dont lock the topic iin ubuntu channnels though
[12:20] <dholbach> ogra_, does it work for you now?
[12:21] <ogra_> dholbach, havent gootten to chatoom yet ... i'll let you know then
[12:21] <dholbach> <3
[12:27] <rickspencer3> does this look to anyone like i have my wifi configured properly?
[12:27] <rickspencer3> http://pastebin.ubuntu.com/11244005/
[12:28] <dholbach> mvo, I'm looking at a tutorial which seems partly to depend on python being in the Ubuntu Core image - do you have plans to change that? :)
[12:29] <beuno> rickspencer3, depends what properly means. No IP address, not connected to anything
[12:29] <rickspencer3> beuno, right
[12:29] <rickspencer3> so, that's a "no" :)
[12:30] <mvo> dholbach: sort of, for 16.04 it will most likely change, for 15.04 it will stay (unless asac decides otherwise :)
[12:30] <dholbach> ok... do you have a bug open for it?
[12:31] <rickspencer3> beuno, does this look right? http://pastebin.ubuntu.com/11244055/
[12:31] <ogra_> rickspencer3, no, remove the EOF
[12:31] <rickspencer3> dang it
[12:31] <ogra_> the rest looks fine
[12:31] <rickspencer3> I assumed the EOF would be ignored
[12:32] <beuno> also, now we can all park in front of rickspencer3's house and leach off the wifi
[12:32] <ogra_> it is the second half of the "echo" in the blogpost :)
[12:32] <rickspencer3> oh fudge
[12:32] <rickspencer3> lol
[12:32] <ogra_> if you remove the echo line you also need to remove the EOF
[12:33] <rickspencer3> ogra_, I think I am looking at the wrong thing, can you give me the link again?
[12:33] <ogra_> dholbach, there are more issues with node-snapper (just starting to inspect them)
[12:33] <ogra_> rickspencer3, which link ?
[12:34] <ogra_> http://www.marinus.nu/2015/02/enabling-wifi-on-snappy-ubuntu-core.html ?
[12:34] <rickspencer3> ogra_, oh, I thought you were referring me to a blog post with instructions
[12:34] <rickspencer3> let me look
[12:34] <rickspencer3> right, that's the one I used
[12:34] <rickspencer3> but since Chipaca told me that wpa supplicant was already installed, I skipped installing the debs
[12:34] <ogra_> well, you need the config
[12:35] <rickspencer3> so I need to make it ro afterall?
[12:35] <rickspencer3> that seems pretty horrible
[12:35] <ogra_> and you need:
[12:35] <ogra_> sudo chmod go-r /etc/network/interfaces.d/*
[12:35] <rickspencer3> yeah, I did that
[12:35] <ogra_> no, you shouldnt need to make it ro
[12:35] <ogra_> err
[12:35] <ogra_> rw
[12:35] <ogra_> that dir should be rw
[12:35] <rickspencer3> right, rw, worry
[12:35] <rickspencer3> ogra_, so I don't need to install the debs, right?
[12:35] <ogra_> so that you can create /etc/network/interfaces.d/wlan0
[12:36] <ogra_> no, you dont need to
[12:36] <rickspencer3> right, so I made the config file
[12:36] <rickspencer3> I chmoded the file
[12:36] <ogra_> right
[12:36] <ogra_> so you should be able to bring up the interface now
[12:36] <ogra_> sudo ifup wlan0
[12:37] <rickspencer3> oh
[12:37] <rickspencer3> I can't just plug it in?
[12:37] <rickspencer3> seems suboptimal that I have to connect to ethernet to turn on wifi ;)
[12:37] <ogra_> not sure that triggers a connect
[12:37] <ogra_> it should come up on boot ...
[12:37] <rickspencer3> oh, ifup said the interface was already configured
[12:37] <ogra_> but i dont know if anything would call "ifup wlan0" if you plug it in
[12:38] <ogra_> so ifdown it first
[12:38] <rickspencer3> ogra_, I assumed that the  allow-hotplug wlan0  line meant I could just plug int eh dongle when I want
[12:38] <ogra_> might be configured with old settings
[12:38] <rickspencer3> still no ip address :/
[12:38] <ogra_> iirc it just means the interface can vanish and appear
[12:38] <rickspencer3> ok
[12:38] <ogra_> but i might be wrong
[12:39] <rickspencer3> well, ifconfig sees the dongle, just doesn't have an ip address
[12:39]  * rickspencer3 tries different dongle
[12:40] <rickspencer3> oops, the Belkin dongle categorically does not work :/
[12:40] <ogra_> dholbach, seems the armhf build of the node modules completely fails in wily ... (i get a proper amd64 tarball though)
[12:40] <ogra_> that will need some more love
[12:41] <rickspencer3> so Netgear one is recognized, but still does not get an IP address
[12:43] <ogra_> rickspencer3, hmm ... i think the underscores there are wrong
[12:43] <rickspencer3> interesting
[12:43] <rickspencer3> ogra_, just delete those?
[12:43] <ogra_> try wpa-ssid and wpa-psk
[12:45] <rickspencer3> i got some interesting messages that time :)
[12:45] <rickspencer3> ogra_, http://pastebin.ubuntu.com/11244254/  ?
[12:46] <ogra_> so it tried to get the ip vis dhcp but wasnt connected to the AP i would say
[12:46] <ogra_> does ifconfig list the wlan0 interface ?
[12:48] <dholbach> mvo, do you have a bug open for moving off of python?
[12:49] <rickspencer3> ogra_, yes, iconfig lists it
[12:49] <rickspencer3> ogra_, ima try a reboot
[12:49] <ogra_> and iwconfig ?
[12:49] <rickspencer3> command not found
[12:50] <ogra_> aha
[12:50]  * rickspencer3 braces
[12:51] <ogra_> well, i'm not sure if wpa_supplicant actually needs it installed
[12:52] <ogra_> (it is just helpful for debugging to see if there is an AP connection)
[12:53] <ogra_> rickspencer3, check the dmesg output when connecting the thing ...
[12:53] <ogra_> dmesg | tail -50 ... or so
[12:53] <rickspencer3> k
[12:53] <ogra_> (or -100 for more lines)
[12:53] <tbr> also checking the packet counters for the interface might give an indication if there is anything working
[12:53] <ogra_> yeah
[12:54] <ogra_> in ifconfig that is
[12:54] <rickspencer3> let me do ifdown/ifup and get dmesg first
[12:55]  * ogra_ needs to move for a meeting ... brb
[12:55] <rickspencer3> ogra_, kk
[12:55] <rickspencer3> http://pastebin.ubuntu.com/11244363/
[12:56] <rickspencer3> ^for when you get back
[12:57] <asac> rickspencer3: you have your interfaces files in a paste?
[12:58] <rickspencer3> asac, yes, let me get you the latest
[12:58] <rickspencer3> asac, http://pastebin.ubuntu.com/11244393/
[12:58] <rickspencer3> this time I removed my password ;)
[13:00] <ogra_> hmm
[13:00] <asac> heh
[13:00] <ogra_> [ 1894.677595] musb-hdrc musb-hdrc.1.auto: VBUS_ERROR in a_host (91, <VBusValid), retry #1, port1 00000507
[13:00] <ogra_> missing firmware ?
[13:00] <asac> rickspencer3: does that dongle work on your desktop?
[13:01] <asac> good to check there first before trying to go embedded :P
[13:01] <rickspencer3> asac, yes, but ... for all I know I had some non-free drivers installed
[13:01] <asac> ahh
[13:01] <rickspencer3> I don't recall installing non-free drivers, though, tbh
[13:02] <rickspencer3> I haven't used the thing in quite some time
[13:02]  * rickspencer3 tries on laptop
[13:02] <ogra_> well, might be that it needs a realtek driver or firmware
[13:02] <rickspencer3> I plugged it into this laptop and it started blinking instantly
[13:02] <rickspencer3> and network manager sees all the networks with it
[13:02] <ogra_> check if you have /lib/firmware/rtlwifi/
[13:03] <rickspencer3> ogra_, on my laptop, yes, there are a bunch of files in there
[13:03] <ogra_> might be needed by that card
[13:05] <rickspencer3> ogra_, it looks like I have the exact same files on this laptop as on snappy
[13:05] <rickspencer3> let me confirm that I use the card
[13:05] <rickspencer3> brb
[13:07] <rickspencer3> works perfectly on the laptop
[13:08] <rickspencer3> ogra_, rtlwifi looks exactly the same
[13:08] <rickspencer3> http://pastebin.ubuntu.com/11244579/
[13:16] <elopio> mvo: I was going to ask why the selftests were in a separate branch.
[13:17] <elopio> nice work there.
[13:17] <mvo> elopio: thanks! I am in a meeting right now, but I would love to get your input in how we can make the tests better and what needs to be changed on the CI side once we move the tests into snappy itself
[13:22] <elopio> mvo: ok, lets talk. I think today we are full of meetings on the sprint. Maybe better tomorrow.
[13:28] <mvo> elopio: ok
[14:24] <rickspencer3> Chipaca, sorry, I forget, you told me to look at go-example-webserver for a template for a new go snap, right?
[14:30] <sergiusens> mvo: I preferred having $origin in there as well, but what apparmorish thing will we break?
[14:30] <sergiusens> mvo: the security tools have no concept of origin/namespace, so maybe we can teach it through _$version.yaml?
[14:40] <beowulf> lool: hey, sorry, was it you who pinged me about webdm icon size on an xps screen?
[14:41]  * beowulf wants to know if it's a 4k screen, and if the pixel density is 141 or 282
[14:43] <Chipaca> rickspencer3: yes, want the url again?
[14:43] <rickspencer3> Chipaca, no thanks, I branch snappy-examples, just wanted to make sure I was using the right project in there
[14:44] <Chipaca> rickspencer3: it's the one that seems closed to what you said you wanted
[14:44] <rickspencer3> thanks Chipaca
[14:44] <Chipaca> rickspencer3: or rather, to what i understood you said you wanted
[14:45] <Chipaca> closest*
[14:47] <noise][> rickspencer3: fwiw, i got a wifi dongle working on my bbb with just the config file
[14:47] <rickspencer3> :(
[14:47] <rickspencer3> noise][, what kind of dongle?
[14:47] <rickspencer3> brand, I mean?
[14:47] <noise][> cheap? :) lemme check
[14:48] <rickspencer3> it just seems weird that it works instantly with the laptop and not with snappy
[14:48] <noise][> "LB-Link" , Manufacturer: Realtek
[14:49] <noise][> interface came up on 1st try but wasn't pinging - i had to disconnect the ethernet and reboot for it to actually work
[14:52] <rickspencer3> hmmm
[14:52] <rickspencer3> noise][, can you paste-bin your config for me?
[14:53] <noise][> http://pastebin.ubuntu.com/11246101/
[14:54] <noise][> added that, did the chmod as in the blog post and was good to go
[14:54] <beowulf> Chipaca: hi, where did you get/create the icon for 8nzc1x4iim2xj1g2ul64 43
[14:55] <Chipaca> beowulf: isn't it the hello world one?
[14:55] <beowulf> Chipaca: so you copied it from little jimmy?
[14:56] <Chipaca> beowulf: revision 42's description was "hello world"
[14:56] <Chipaca> beowulf: I did not invest significant amounts of time in that package
[14:56] <beowulf> Chipaca: understood, i'm just curious as to where the broken svgs came from
[14:56] <Chipaca> beowulf: ehlo wurld
[14:57] <beowulf> they're missing xmlns and xmlns:xlink attrs, so browsers turn their nose up in disgust
[14:59] <Chipaca> beowulf: i blame ... barry!
[14:59] <barry> sure, why not? :)
[15:01] <Chipaca> always breaking svgs
[15:01] <Chipaca> it's what he does between gigs
[15:04] <barry> :)
[15:20] <mterry> jdstrand, is a confined app allowed to run inotify_init1()?
[15:22] <jdstrand> mterry: not atm. that is one of the things that is queued up for the ubuntu-core-security SRU
[15:23] <mterry> jdstrand, interesting.  Right now my app halts on that call.  Is that expected?
[15:23] <jdstrand> yes
[15:23] <mterry> :(
[15:23] <mterry> jdstrand, that's an intense version of failure
[15:23] <jdstrand> mterry: to unblock yourself, modify /var/lib/snappy/seccomp/profiles/<profile for your app> to include inotify_init1
[15:23] <jdstrand> mterry: that is a limitation of seccomp
[15:24] <mterry> jdstrand, ah really?  ok
[15:24] <jdstrand> you can log or kill
[15:24] <jdstrand> you can't log and silently fail
[15:25] <jdstrand> sorry, you can log and kill, you can't log and not kill
[15:25] <mterry> jdstrand, is there an example of some package.yaml that allows this call?  Or do I have to really manually modify this thing as a temporary hack?
[15:25] <jdstrand> meh, I am really not explainging myself
[15:25] <mterry> jdstrand, I think I get ya
[15:25] <jdstrand> you can log and allow. you can log and kill. you cannot silently fail
[15:26] <jdstrand> anyway
[15:26] <jdstrand> yeah-- add that to your profile and you'll be fine
[15:26] <mterry> jdstrand, would i have to do all the inotify_* api then I guess?
[15:26] <mterry> jdstrand, you mentioned being queued up for an SRU, but I'm on wily/rolling
[15:27] <mterry> jdstrand, will wait for end of meeting, sorry
[15:27] <jdstrand> mterry: maybe, maybe not. this is what we will be adding: http://paste.ubuntu.com/11246583/
[15:27] <jdstrand> mterry: oh, if you are on wily, I can get this uploaded soonish
[15:36] <mterry> jdstrand, this inotify thing blocks any app using the sdk.  that's how I hit it  :)
[15:36] <mterry> jdstrand, because QFileSystemWatcher uses inotify
[15:37] <ogra_> dholbach, just FYI, chatroom works for me now ... i'll diff the changes i did on the snappy system to get it to work and push that to the branch
[15:37]  * dholbach hugs ogra_
[15:37]  * ogra_ finds it weird to watch himself from two different angles while working :)
[15:38] <dholbach> I'm going to be off the grid for a few days starting in just a few minutes, but I'll test the instructions again as soon as I'm back and publish the tutorial :)
[15:38] <ogra_> dholbach, cool
[15:38] <ogra_> i'll probably do a series of blog posts packaging other nodejs stuff
[15:38] <dholbach> <3
[15:39] <ogra_> since i need to update all of my packages anyway
[15:39] <ogra_> (and most of them use node)
[15:39] <dholbach> right
[15:40]  * ogra_ wants os.js in the store ... thats really awesome :)
[15:40] <ogra_> full desktop in a browser :)
[15:41] <Chipaca> we should make sure snappy runs on the in-browser linux emulator thing
[15:42] <Chipaca> then use that to run os.js
[15:42] <jdstrand> mterry: yes, it was an omission in part because no one until now has tried to use it. we decided to add it, but cause no one hit it, it wasn't top priority
[15:42] <jdstrand> mterry: I'll get that uploaded to wily today/tomorrow
[15:42] <mterry> jdstrand, understood.  Not pushing ya, just saying how I hit it  :)
[15:47] <jdstrand> yep
[15:47] <jdstrand> thank you for bringing it to my attention
[17:49] <tgm4883> Is there some documented process to go from making regular deb packages to snappy packages? We've got an automated process for making deb packages, but it seems from my reading we need to build binaries then put those in a snappy package before uploading it
[17:50] <rickspencer3> tgm4883, I think mterry might have made a script to help with that
[17:52] <tgm4883> rickspencer3: that would be handy. I'd like to get that figured out, then figure out how many dependencies I'm supposed to package as well (eg. mysql-server)
[17:53] <tgm4883> I mean, for a semi-complicated application that uses apache, mysql and listens for traffic on a non-restricted port, do I put all of that into the same snappy package?
[18:04] <sergiusens> tgm4883: yes if you intend to run them on the same server
[18:04] <tgm4883> sergiusens: can snappy packages depend on other snappy packages?
[18:05] <tgm4883> because installing a separate mysql snappy package and just referencing it over the network would work in theory
[18:06] <tgm4883> there a bit of this that I'm not sure how it will work. For instance, a mysql snappy package upgrade and rollback. What happens to the database in that scenario?
[18:07] <tgm4883> I think our mythtv and snappy work really well together in theory, and I'd like to have a mythbuntu snappy release for 16.04, but I'm just having trouble finding what I need for all this
[18:09] <sergiusens> tgm4883: I'm not sure how the rollback is going to evolve in the future, but right now your data from version 1 get copied over to a data location for version 2; if you rollback to version 1 you essentially rollback to binary and the data
[18:10] <tgm4883> sergiusens: so the old data then? that actually sounds perfect
[18:11] <sergiusens> tgm4883: yes, it solve not needed to solve inconsistencies a possible updated version might have caused to your data
[18:11] <sergiusens> data is essentially versioned in this sense
[18:13] <tgm4883> awesome, I really like that. With MythTV, if you upgrade from 0.27.X to 0.28.X (which is a major version upgrade) and don't like it. Rolling back means doing a mysql db restore (hopefully a backup was made). This would solve that I think
[18:14] <tgm4883> sergiusens: so our mythtv snap would need apache, mythtv, and mysql. How far down the dependency hole do I need to go? I'm sure apache and mysql have their own libraries and such they pull in as well
[18:16] <sergiusens> tgm4883: maybe this will solve it for you https://github.com/mikix/deb2snap
[18:32] <tgm4883> sergiusens: yep, I think that will help a bunch, thanks
[19:24] <Chipaca> mterry: just for the record
[19:25] <Chipaca> mterry: and so you don't feel i've just butted in over what you were saying with sergio
[19:25] <Chipaca> mterry: i was of the same opinion as you initially, but then we talked with sergio about it (part of his reasoning is in the mp)
[19:25] <Chipaca> mterry: and, yeah, we want to test what we control
[19:25] <Chipaca> mterry: in the fullness of time the test would be "the error fits this type: <very specific error type>"
[19:26] <Chipaca> mterry: we'll have to do that when we ourselves internationalize our strings
[19:26] <Chipaca> mterry: but meanwhile... this
[19:26] <sergiusens> Chipaca: what was mterry telling me though?
[19:26]  * sergiusens is lost
[19:27] <Chipaca> sergiusens: C.UTF-8
[19:27] <sergiusens> Chipaca: oic, that comment was from mterry not you :-P
[19:27] <Chipaca> heh
[19:27] <Chipaca> yeah
[19:27] <Chipaca> great minds etc etc
[19:27] <mterry> sergiusens, Chipaca: well OK, I get testing what we control
[19:28] <mterry> sergiusens, Chipaca: so for this MP, fine.  But *also* when we do test our own strings, we should probably run as C.UTF-8
[19:28] <Chipaca> mterry: hmmm... but then catching the ones we're testing wrong is harder :)
[19:28] <sergiusens> mterry: yeah, we should add that to the suites
[19:28] <sergiusens> mterry: as well ;-)
[19:28] <Chipaca> agreed
[19:29] <mterry> group hug!
[19:29] <Chipaca> woo!
[19:29] <sergiusens> Chipaca: this brings the need to bring in that go code we have for gettext
[19:29]  * sergiusens joins the hug
[19:31] <rickspencer3> sooo, if I just want to have an app that uploads a certain image in a certain directory every n minutes ... it just occurs to me that I could make a snap out of shell script?
[19:31] <rickspencer3> would it be that easy
[19:31] <Chipaca> rickspencer3: ssh, we're hugging, come back later
[19:32] <rickspencer3> uh
[19:32] <Chipaca> rickspencer3: that sounds suspicioulsy like the camera snap
[19:32] <Chipaca> suspiciously*
[19:32] <Chipaca> rickspencer3: i think asac wrote that one
[19:32] <rickspencer3> Chipaca, you mean lool's web cam snap?
[19:32] <Chipaca> based on a look snap
[19:32] <Chipaca> lool*
[19:32] <sergiusens> lool wrote it iirc
[19:32] <rickspencer3> I don't think it uploads, though
[19:32] <Chipaca> rickspencer3: yeah
[19:33] <Chipaca> rickspencer3: ok, expand on "uploads" :)
[19:33] <rickspencer3> sorry to be dense, but a light bulb just cam on over my head
[19:33] <sergiusens> correct, doesn't upload
[19:33] <rickspencer3> Chipaca, I want to upload the image to the cloud
[19:33] <sergiusens> rickspencer3: should be doable
[19:33] <rickspencer3> and it just occurs to me I can stop with this go code and use curl in a loop with sleep in shell script
[19:34]  * rickspencer3 checks if curl is available
[19:34] <sergiusens> rickspencer3: doing the loop in go is relatively easy
[19:34] <Chipaca> rickspencer3: you'd need to bundle something that POSTs
[19:34] <Chipaca> rickspencer3: no curl
[19:34] <rickspencer3> sergiusens, yeah, but CreateFormField looks hard
[19:34] <Chipaca> rickspencer3: no wget
[19:34] <rickspencer3> oh
[19:34] <rickspencer3> so there goes that
[19:34] <Chipaca> rickspencer3: what are you writing it in?
[19:34]  * rickspencer3 goes puts tail between legs and returns to go docks
[19:35] <rickspencer3> Chipaca, this is my first Go program
[19:35] <Chipaca> rickspencer3: i've got to go put boys to bed, but when i return i can point you at code you can copy-paste for the POSTing
[19:35] <Chipaca> that is if sergiusens doesn't beat me to it
[19:35] <rickspencer3> that would be nice
[19:36] <rickspencer3> I was going to use imgur to start, since I already have an API key
[19:36] <rickspencer3> but need a nicer cloud service for it
[19:42] <Chipaca> rickspencer3: you'd do oauth2?
[19:42] <Chipaca> rickspencer3: that's probably rather tricky for a first go program :)
[19:42] <rickspencer3> Chipaca, doesn't look that way
[19:42] <rickspencer3> I just need to supply the api key in the form data
[19:43] <rickspencer3> what I really need is a place that I can upload to and have a known url, but, ironically, I *just* canceled my shared hosting account
[19:44] <Chipaca> rickspencer3: from the imgur api i'm reading, it's oauth2
[19:44] <Chipaca> rickspencer3: e.g. https://github.com/Imgur/imgurpython/blob/master/examples/auth.py
[19:45] <Chipaca> rickspencer3: that's imported by the other example, upload.py
[19:45] <Chipaca> rickspencer3: maybe you're using an old api? or maybe i'm missing something
[19:46] <rickspencer3> hmmm
[19:46] <rickspencer3> perhaps they changed it
[19:46] <Chipaca> rickspencer3: if you show me how you would've used curl (edit out the key if you will), i'll implement that in go
[19:46] <rickspencer3> in the past I just included my api key in the post data
[19:46] <rickspencer3> Chipaca, too much yack shaving with imgur
[19:47] <rickspencer3> let me find a better place to host it
[19:47] <rickspencer3> maybe I'll make a little web server on canonistack or something
[19:48] <rickspencer3> Chipaca, thanks for the offer, I will probably take you up on it later
[19:48] <sergiusens> rickspencer3: it can also be snappy/canonistack
[19:48] <rickspencer3> sergiusens, inception!
[19:48] <rickspencer3> but, yeah
[19:48] <Chipaca> rickspencer3: sure, i'll be around for a few hours still
[19:48] <rickspencer3> so I would make a snap that accepts the form post
[19:49] <rickspencer3> for that matter, I could make my pi2 the server and my bbb the hub
[19:50] <rickspencer3> oops, I *could* do that, I mean to say :)
[19:52] <Chipaca> rickspencer3: if you're doing that, you could blat it using netcat :)
[19:55] <rickspencer3> http://i.imgur.com/DWrI2JY.gif
[19:59] <sergiusens> rickspencer3: pseudo code http://paste.ubuntu.com/11250452/
[19:59] <sergiusens> well, the post is there but the what and where's are open
[20:00] <sergiusens> Chipaca: ^ not sure that satisfies you
[20:01] <Chipaca> wfm
[20:02] <sergiusens> Chipaca: I forgot if there is a way to not need an http.Client{} instance and have a Post with headers and a body
[20:13] <lool> beowulf: yes, well I raised the issue actually; with webdm from store from 10 days ago or so, there's a fixed amount of icons whatever the screen size and browser zoom levels; it would seem like it should be adapted
[20:15] <sergiusens> Chipaca: I pushed updates to TheOrigins MP; the security.md was just a bad merge
[20:15] <Chipaca> sergiusens: hah
[20:15] <sergiusens> Chipaca: I merged trunk as there were conflicts and those were the conflicting lines, but the nice coloring failed to show :-P
[20:16] <sergiusens> oh, jdstrand I forgot to ask, if I change frameworks to live in /frameworks/$package_name/$origin/$version what are the apparmor implications?
[20:16] <sergiusens> same for /apps btw
[20:17] <sergiusens> I guess it means we move away from APP_ID == $package_name[.$origin]_$binary_$version
[20:18] <sergiusens> I guess my question is, can the templates learn about $origin to know how to expand all the dirs?
[20:19] <sergiusens> And remove it from the APP_ID itself
[20:20] <mterry> jdstrand, can default-confined apps bind abstract sockets?
[20:30] <mterry> jdstrand, looks like no?  But I'm not an expert on this syntax
[20:43] <Chipaca> tyhicks: you around?
[20:44] <tyhicks> Chipaca: hello!
[20:44] <Chipaca> tyhicks: thanks for the review(s)!
[20:44] <tyhicks> Chipaca: no problem - thanks for all the quick fixes :)
[20:44] <Chipaca> tyhicks: was wondering one thing
[20:44] <Chipaca> tyhicks: wouldn't it be better/simpler if we mounted our own tmp, at this point
[20:45] <Chipaca> tyhicks: it'd get unmounted (and nuked) on process exit, right?
[20:46] <tyhicks> Chipaca: what you have now is getting unmounted on process exit (but the source dir isn't being removed)
[20:46] <tyhicks> Chipaca: if we mounted our own tmp, where would it come from?
[20:46] <Chipaca> oh, drat
[20:46] <Chipaca> tyhicks: i was thinking tmpfs /tmp. and that's not a given
[20:47] <Chipaca> bummer
[20:47] <tyhicks> I thought about that
[20:47] <tyhicks> but I think we're really close to landing these changes and I think what you have now is a good solution
[20:47] <Chipaca> about cleanup, it'll have to be done by cron or something similar i guess
[20:47] <Chipaca> tmpreaper or whatever it's called
[20:47] <Chipaca> not sure if there's a better way
[20:48] <Chipaca> unless we can rmdir something that's the source of a bind mount
[20:48] <tyhicks> I don't think we can rmdir that
[20:48]  * Chipaca grins eveily and goes off to try
[20:48] <Chipaca> well, you can rm an open file. i don't think it'll work either, but :)
[20:49] <tyhicks> what we can do is chdir to the directory that mkdtemp() creates, then rmdir(".)
[20:49] <jdstrand> mterry: no. we will have a mechanism for that when the 'sockets' yaml is implemented (see docs/security.md for details)
[20:49] <jdstrand> mterry: what is it that you are trying to do?
[20:49] <tyhicks> Chipaca: but changing back to the previous working directory is dangerous to attempt from the privileged section of the cod
[20:49] <mterry> jdstrand, trying to run a session dbus-daemon inside a snap
[20:49] <tyhicks> code*
[20:50] <mterry> jdstrand, by default it tries to use an abstract socket
[20:50] <jdstrand> mterry: yeah, you can't do that
[20:50] <mterry> jdstrand, but I can ask it to use a path socket
[20:50] <Chipaca> well, that's weird
[20:50] <jdstrand> yes, you can
[20:50] <Chipaca> tyhicks: i could rmdir the source just fine
[20:50] <tyhicks> oh
[20:50] <Chipaca> tyhicks: but then i couldn't create things in the target
[20:50] <mterry> jdstrand, I assume no access to system bus by default either
[20:50] <Chipaca> let me try that again
[20:51] <jdstrand> but only apps shipped in your snap will be able to access the file based one
[20:51] <mterry> jdstrand, yeah
[20:51] <jdstrand> mterry: that is correct
[20:51] <mterry> jdstrand, I'm just trying to get a kiosk-style run of an sdk app (ubuntu-clock-app)
[20:51] <mterry> jdstrand, it's been interesting so far  :)
[20:51] <jdstrand> mterry: now, frameworks may ship a dbus service, and then ship framework-policy for clients to connect to it
[20:51] <tyhicks> Chipaca: I see the same behavior you described
[20:51] <mterry> jdstrand, seems like that's what we'll need for this sort of use case
[20:51] <Chipaca> tyhicks: yep, mounting foo -> bar, rmdir foo works, but then touch bar/blah fails with no such file or directory
[20:52] <jdstrand> mterry: see hello-dbus in snappy-examples
[20:52] <jdstrand> mterry: (and install hello-dbus-fwk and hello-dbus-app to see it in action)
[20:53] <jdstrand> mterry: this is part of the whole app isolation story. they really are isolated :)
[20:53] <jdstrand> mterry: but, like I said, there will be more flexibility for non-framework people when 'sockets' is implemented in the yaml
[20:54] <jdstrand> mterry: with that a 'server' will be able to specify the abstract socket path it will serve on, then the server snap can specify which client snaps can connect to it
[20:54] <mterry> jdstrand, I get it and the isolation is thumbs up for me.  I've just been trying to work around it for demo purposes
[20:54] <Chipaca> tyhicks: the only problem i see with leaving the tmpdir lying around is if something misbehaves and respawns a bunch of times and you run out of inodes on tmp
[20:55] <jdstrand> mterry: if you were able to work around it, then we would have found a hole. if you do find a hole, please report it :)
[20:55] <tyhicks> Chipaca: yeah - I expect you'll run out of possible tmp dirs (from mkdtemp()) first
[20:55] <jdstrand> that way I can close it for you :)
[20:55] <mterry> jdstrand, not like *WORK AROUND IT*, but just run a local dbus daemon for my snap
[20:55] <Chipaca> tyhicks: ah, good point :)
[20:56] <Chipaca> tyhicks: and i catch and abort on those, so \o/
[20:56] <tyhicks> Chipaca: ah, there you go
[20:56] <jdstrand> mterry: I can't think of anything that would stop you from shipping multiple binaries/services within a single snap that would block you from using a file based path
[20:56] <tyhicks> Chipaca: I think about this some more
[20:56] <Chipaca> tyhicks: ok, i'll fix the issues you found already :)
[20:57] <tyhicks> Chipaca: thanks! (note that I screwed up the white space in the patch I pasted for the apparmor profile)
[20:57] <jdstrand> mterry: but as soon as you are talking about running a service for other snaps to use, you are in framework (or the aforementioned future coordinated snap socket) territory
[20:57] <mterry> jdstrand, yeah no -- my problems are just discovering where a simple SDK app pokes out and fill in what it needs (now it's trying to connect to system bus and I have to figure out why and what to do about it)
[20:57] <mterry> jdstrand, right, I don't care about that use case right now
[20:57] <mterry> just an internal-snap thing
[20:57] <Chipaca> tyhicks: ah, i thought it was launchpad, or gmail, doing it for you
[20:58] <jdstrand> I see
[20:58] <jdstrand> ok, well, good luck! :)
[20:58] <mterry> jdstrand, but it's hard enough that I may just throw up my hands and say "we need to get a proper sdk framework for this demo"
[20:59] <tyhicks> Chipaca: that's always possible, too :)
[20:59] <Chipaca> tyhicks: ooh! i should chmod 01777 it, too
[21:00] <Chipaca> bah
[21:00] <Chipaca> dunno
[21:00] <jdstrand> tyhicks: curious, in our dbus testing, did you ever setup a name-based socket non-system bus service?
[21:00] <Chipaca> i guess just for completeness :)
[21:01] <tyhicks> Chipaca: I was going to suggest that but then when I noticed that it was 700, I kept quite
[21:01] <tyhicks> Chipaca: if it needs to be world-writeable, please do set the sticky bit
[21:01] <Chipaca> tyhicks: yeah, might as well leave it like that
[21:02] <tyhicks> jdstrand: I'm not following - do you have an example?
[21:02] <tyhicks> oh
[21:02] <jdstrand> tyhicks: start a local non-system, non-session dbus server that listens on say, /tmp/foo.sock
[21:02] <jdstrand> rather than @foo
[21:03] <tyhicks> jdstrand: I probably did not test the scenario
[21:03] <jdstrand> s/ server/-daemon/
[21:04] <jdstrand> tyhicks: that's ok. just wondering if you then we could point mterry out the apparmor tree
[21:04] <jdstrand> at*
[21:05] <mterry> jdstrand, in my case it would be a session bus (you said non-session)
[21:05] <jdstrand> well, isn't it just a private bus?
[21:06] <mterry> jdstrand, oh I suppose.  Like just for my snap.  But I guess I meant, it's a user bus
[21:06] <tyhicks> I know that people have used dbus mediation on private busses
[21:06] <tyhicks> I think mardy used one for online accounts
[21:06] <jdstrand> I guess it would use --session
[21:06] <jdstrand> but you override --address
[21:07] <tyhicks> I can test this pretty quickly by modifying tests/regression/apparmor/dbus.conf (in the apparmor tree) and running the regression tests
[21:07] <jdstrand> --session --address=$SNAP_APP_DATA_PATH/foo.sock ...
[21:13] <mterry> jdstrand, exactly
[21:17] <tyhicks> jdstrand, mterry: I was able to run through the AppArmor D-Bus mediation regression tests after applying this diff: http://paste.ubuntu.com/11251491/
[21:17] <tyhicks> jdstrand, mterry: They all passed
[21:18] <jdstrand> mterry: you might need the network-service cap
[21:18] <tyhicks> (ran on Wily, against apparmor 2.9.1-0ubuntu9 and dbus 1.8.12-1ubuntu5)
[21:18] <jdstrand> mterry: do you have seccomp denials?
[21:18] <jdstrand> tyhicks: thanks! :)
[21:18] <tyhicks> np
[21:20] <asac> Chipaca: rickspencer3: right the webcam-demo snap takes snapshots and puts that in a directory that you can then look at with webrowser...
[21:20] <asac> you could certainly improve it... make configurable the timeout etc.
[21:20] <rickspencer3> asac, I want to upload those images to a cloud
[21:20] <rickspencer3> that's the only enhancement
[21:20] <mterry> jdstrand, I'm not entirely sure what my current blocker is... I'm seeing failure to connect to /run/dbus/system_bus_socket.  I'm seeing capability denials for dac_read_search and dac_override
[21:20] <mterry> jdstrand, plus some other failures
[21:20] <mterry> everything is dying
[21:22] <mterry> jdstrand, also.. a denial for a read on /home/ubuntu/apps/clockit.sideload/3/.local/share/com.ubuntu.clock/user-preferences ?  I would have expected that to be allowed
[21:23] <mterry> jdstrand, ignore tht
[21:23] <mterry> jdstrand, that's because I was mixing sudo and user files
[21:24] <mterry> So just the system bus access...  I'll figure it out