=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === zyga is now known as zyga_ [08:25] I have a question regarding: https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/ [08:26] It says that the snap will only work on Core, so how do we pick a target since snaps can also be created for the desktop? [08:27] oparoz: actually, the snappy is running on core on the desktop, so yes, it should work as long as the snap targets the right arch [08:28] s/the snappy/the snap :) [08:29] Thanks davidcalle, so it's just a problem with the doc then. I can install snapcraft on a desktop, create a multi-arch snap and deploy on desktop,server and core without any issue as long as they all use the same Snappy engine (16.04) [08:29] good morning [08:31] Do we report doc problems on LP, in the Snapcraft project? [08:31] oparoz: yes, snapcraft doc is being updated to match the latest state of things. Examples in here (https://developer.ubuntu.com/en/desktop/) are the most recent (less detailled, though). [08:31] oparoz: snapcraft project, yes. https://bugs.launchpad.net/snapcraft [08:32] Thank you davidcalle [08:32] yw === zyga_ is now known as zyga [09:00] hello ... a few questions : 1) I have a few .click (arm, native binary) package for ubuntu phones, does it make sense to upgrade to snappy package ? [09:02] slvn: what kind of app is that? [09:02] slvn: I guess right now the answer is "if that snap would run on desktops" [09:02] zyga, games based on libSDL2 [09:03] slvn: sure, you can target the desktop with your snap [09:03] the games could also run on desktop, provided I compiled them for desktop [09:03] slvn: and inevitably the phone will adopt snaps at some point so you will already know how things work there [09:04] also I tried to install my .click package on my destkop and it refused to be installed (cannot be install on X ...) [09:05] so I should look how to provide a snap package that contains both arm and x86 libs for arm and desktop [09:06] Will snapy packages run *confined* like .click on phones ? === chihchun is now known as chihchun_afk === JamesTait is now known as Guest6158 === Guest6158 is now known as JamesTait [09:14] slvn: to some extent, yes. Eg. snaps on the desktop can be granted access to $HOME [09:15] slvn: note that the phone switch to snap will take time. === chihchun_afk is now known as chihchun === seb128_ is now known as seb128 [09:36] davidcalle, zyga, thanks for the answers, I will have a look on snapy ! [09:37] is there an "apt-cache show" equivalent in the snap world? [09:38] snap list lists names, but that's not very useful to figure out what the snaps are exactly [09:40] seb128: I don't think there is one [09:40] :-/ [09:41] seb128: as a hack, you can look at /snap/$name/current/meta/snap.yaml [09:41] seb128: but that's just a portion of the information we have about each snap (2nd part comes from the store) [09:41] zyga, I'm not hacking [09:41] just trying to use it as an user [09:41] seb128: I know that Chipaca is working on a richer REST API [09:42] k, I'm also trying if we have those info available so we integrate them with the desktop frontend [09:46] seb128: you mean in gnome-software? [09:46] yes [09:46] seb128: AFAIR gnome software should use the rest api [09:46] seb128: there we can expose many details easily [09:46] right [09:46] I was just trying to see what is currently exposed [09:46] and I though I would start as an user with using the command line to see what is displayed there [09:47] but I hit that wall ;-) [09:48] yep, I understand [09:48] seb128: perhaps this can be of some use: https://github.com/ubuntu-core/snappy/blob/master/client/packages.go [09:48] this is the client side rest API [09:48] popey: you still have these problems like we discussed yesterday with building images with udf, right? fgimenez just sent me a rebuilt binary, but it didn't seem to help, and then I found myself wondering if there was some known-fix that I just didn't hear about yet [09:48] it's in go but you can make the query in any language [09:49] right [09:49] plars: i haven't tested since it made my laptop unusable [09:49] zyga, is there an easy way to see what is currently available? I'm looking after the license info [09:49] seb128: available as in "can install"? [09:49] popey: ack, thanks [09:50] happy to test to confirm any thing you might need plars [09:50] zyga, no, I was wonder if there is a way to query the license from a snap through the rest api atm [09:50] ah [09:50] * zyga looks [09:50] popey: I just wonder how it works for others [09:50] plars: i expect people don't run that commanbd [09:50] seb128: no, I don't think so, AFAIR some license code was removed before 16.04 as it wasn't ready [09:50] attente, ^ [09:51] seb128, Chipaca: will know more for sure [09:51] zyga, thanks [09:51] no i won't [09:51] * Chipaca reads [09:51] willcooke, do we maintain a list of things we would need? until ^ is resolved g-s is going to show snaps with a "that software is non free" banner [09:52] Chipaca, can we query the license of a snap through the rest api? [09:52] seb128: nope [09:52] not sure why not though [09:52] gimme a sec [09:53] seb128: so, no. But it could be added easily. [09:54] Chipaca, we have https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1555567 could you comment/triage the snappy/store side? [09:54] Launchpad bug 1555567 in gnome-software (Ubuntu) "License information from the store not being used" [Medium,Triaged] [09:54] seb128, we need to get it on to the backlog, so we attend the stakeholders meeting and request it. (wow! such manager speak) [09:54] willcooke, :-) [09:54] willcooke, ^ bug reference there [09:54] seb128, so I think we should log bugs and tag them [09:55] ah nice [09:55] I'll think up a suitable tag name [09:57] seb128: done [09:57] Chipaca, willcooke, thanks [09:57] willcooke: our bad, wrt licensing [09:57] as long as we're not talking of *accepting a license prompt*, shipping the info should be doable rsn [09:57] if it's urgent i mean :-D [09:58] the interactive license thing is for in about a month? wild-arsed guess [09:59] yeah, no need of interaction [09:59] just spoke to seb128 about this - this issue is that there is a fairly large and unsightly banner in g-s which nags "Freedom hater" [09:59] so it would be /nice/ to have that fixed [09:59] for the first release of the snappy enabled g-s === chihchun is now known as chihchun_afk [10:37] https://code.launchpad.net/~stevenwilkin/webdm/snappy-2-0/+merge/292902 # gets WebDM building against recent Snappy === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [10:57] got some error when doing "snappy -v" : "snappy version 0.3.7" .... "(snappy:16290): GLib-GObject-CRITICAL **: g_object_set: assertion 'G_IS_OBJECT (object)' failed.No media set. ' [10:57] http://paste.ubuntu.com/16061735/ [11:10] sorry stupid question, don't know which tutorial makes me install that :) [11:14] slvn: that's probably not this snappy [11:14] :-) [11:15] If I create a snap that uses a reserved interface in a snap, such as unity7, is it subject to manual review when submitted to the stire. [11:15] *store [11:16] Chipaca, yes, I figured out :) (though this "snappy" fails anyway). Just build the hello-world opencv snap :) [11:22] In addition to "snappy", the package "snap" is also confusing .. one should install "snapd" [11:51] flexiondotorg, thats the idea, yes [11:56] Good morning [11:58] hm... it seems somehow 'ubuntu-core' got uninstalled from my system? [11:58] Is this a known issue, shall I just manually reinstall? [11:58] on a 16.04 desktop, that is [12:00] flexiondotorg, although I believe right now only 'home' triggers manual review in the store. 'opengl' will trigger manual review too until the store starts recognizing it [12:02] so somehow 'snap list' does not list 'ubuntu-core' for me, yet if I try to install it, snap install tells me it's already installed [12:03] and 'snap interfaces' does not list any slots available [12:03] ubuntu-core cannot be removed, either [12:05] dpm, jamiebennett Is there a 'mir' interface as an alternative to x11 and unity? [12:05] If so, is it confined? [12:07] flexiondotorg, these are the interfaces currently available: https://github.com/ubuntu-core/snappy/blob/master/docs/interfaces.md, but there is ongoing discussion about interfaces in general [12:09] dpm, Thanks. Understood. I thought I'd seen mention of a 'mir' interface, but I must have been mistaken. [12:09] flexiondotorg, perhaps you've seen it in a discussion here on the mailing list, but I don't think it's available [12:10] Maybe, I thought I'd seen something. [12:10] flexiondotorg, it will probably be available once snaps replace clicks === mcphail_ is now known as mcphail [12:40] 'snap refresh ' gives me a wrapper error. I have to 'snap remove ' twice to remove both revisions and then 'snap install ' to get it working again. [12:45] josepht, any chance you had an app running when you tried to remove? [12:45] kyrofa: no [12:52] josepht kyrofa this happens when sideloading, I hope the fix lands soon [12:53] kyrofa I have gulp working btw! EOD I might get vscode working; then I'll try atom but we need to support grunt [12:53] sergiusens: ah, thanks. [12:54] sergiusens, yeah make sure you create bugs so we don't forget to upstream what we're working on! [12:55] stevebiscuit as a user, would you prefer using a nodejs snapcraft plugin with a possibility to select npm, gulp or grunt as a build driver or individual plugins for each? So we'd have a nodejs plugin (which already exists), then a gulp plugin and a grunt one? [12:55] kyrofa upstream? as in snapcraft? [12:55] kyrofa the bug report depends on stevebiscuit's output ;-) [12:55] sergiusens, haha, yeah [12:55] * sergiusens puts some weight on someone else [12:56] sergiusens, same question to you regarding qmake for qt4 versus 5 [13:07] kyrofa qmake afaik is tied to Qt versions, is it not? [13:08] sergiusens, sort of. There are different qmake packages for each version, but the qt5 one can call the qt4 one [13:08] sergiusens, but maybe it would be more clear to keep them separate [13:11] kyrofa yeah, I'd hop on to #ubuntu-touch and ask those guys ;-) [13:11] sergiusens, alright [13:13] jdstrand: http://pastebin.ubuntu.com/16062943/ # AppArmor is giving a denial when starting WebDM, I think similar has already been reported? [13:15] sergiusens: I'd be tempted to see which toolchain the JS community is favouring, build a solution based on that and wait to see if there's demand for the other options [13:15] jdstrand, hi there! beuno sent me your way regards finding out more about a) cgroups/namespace used to confine snaps, and b) the kernel boot/rollback process, if you've any pointer to docs? [13:17] i think jdstrand is out this week [13:17] ogra_: cheers for the headsup [13:18] stevebiscuit: try tyhicks [13:19] tyhicks: http://pastebin.ubuntu.com/16062943/ # AppArmor is giving a denial when starting WebDM, I think similar has already been reported? [13:20] ogra_: ta [13:20] stevebiscuit from what I am seeing, gulp and grunt are a waste of time [13:21] stevebiscuit used when the project target's windows as people think npm scripts need to be shell scripts [13:21] stevebiscuit: what version of webdm are you using? [13:21] ogra_: I was only out yesterday [13:22] stevebiscuit http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/ [13:24] jdstrand: building from https://code.launchpad.net/webdm [13:24] stevebiscuit ok, I think I'm sold on separate plugins that inherit from the nodejs plugin [13:24] so I can deprecate the other ones in an easier fashion [13:24] jdstrand: oops :) [13:25] jdstrand: hey, how are you [13:25] bloodearnest: the documentation is all in flux. I believe that the community team (dpm) is handling updating that [13:25] zyga: hi, good. you? [13:25] bloodearnest: if you had specific questions, I might be able to help with some [13:25] jdstrand: good :-) [13:25] jdstrand, ah, ok [13:25] stevebiscuit: I don't see snap.yaml or snapcraft.yaml in that tree. what are you using for that? [13:26] jdstrand, wasn't there a whitepaper something or another? [13:26] beuno: there is a whitepaper for 15.04, yes, but it wasn't ever published (I asked to have it done but don't think that ever happened) [13:27] beuno: the whitepaper for 16 is done except it'll need updates for GA [13:27] ah [13:27] jdstrand, ok, so I've seen various mentions of cgroups and namespace usage for snaps, would like to know what cgroups/namespaces are used, and how they interact with plugs/slots [13:27] jdstrand: I read that on developer.u.c somewhere (the whitepaper) [13:27] bloodearnest, there's also apparmor [13:27] jdstrand: http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/view/head:/pkg/meta/snap.yaml [13:27] to complete a buzzwork bingo [13:27] beuno, right, that part I understand [13:27] beuno, bloodearnest: and dbus and seccomp and udev tagging [13:27] or at least, understand enough of [13:28] at least there's no synergy! [13:28] jdstrand: it needs updating to use snapcraft and currenly has it's own build.sh [13:29] stevebiscuit: ah, I missed that. what are the perms of /snap/webdm/100001/snappyd? [13:29] sergiusens: so you're going to have something that can be installed via npm initially? the JS community seems intent or re-inventing *everything* in JS heh [13:30] stevebiscuit I am chatting from a snap that uses the nodejs plugin already ;-) [13:30] nodejs/npm [13:30] but I ignored gulp and grunt; but turns out vscode uses gulp and atom uses grunt [13:30] jdstrand: 0755. It can be run fine standalone oddly [13:31] stevebiscuit: sorry, what is the ownership [13:32] jdstrand: it's owned by ubuntu:ubuntu [13:32] stevebiscuit: ok, that is your problem. how are you building your snap? [13:32] dholbach: note, https://developer.ubuntu.com/en/snappy/guides/security/ is terribly out of date [13:33] dpm: ^ [13:33] jdstrand, yes, we're on it [13:33] AFAICT it's not more than 2 weeks out of date [13:33] jdstrand: it's still being built with sergiusens origional build.sh, I've not yet looked into what it needs to be moved to using snapcraft [13:33] dholbach: zyga mentioned the 15.04 security whitepaper was on developer.u.c. I can't seem to find it. do you know where it is? [13:33] jdstrand, no, I don't think it ever was on there [13:33] stevebiscuit: ok, let me look at that real quick [13:34] you need to at least use snapcraft snap instead of snappy build [13:34] that was a while ago [13:34] stevebiscuit: right, build.sh is using 'snappy build $builddir' [13:35] stevebiscuit: I think if you change that to 'snapcraft snap $builddir' it should work [13:35] jdstrand: cool, I've give that a whirl [13:37] Hi [13:37] bloodearnest: I shared the link with you [13:38] bloodearnest: for 16 [13:38] bloodearnest: note in general most things should be all settled, but there might be a few things that will change (nothing architecturally) [13:39] bloodearnest: but for the benefit of people in this channel, Ubuntu Core uses a combination of technologies to implement the sandbox. the heart is apparmor, but we also use seccomp, device cgroups, private /tmp and devpts newinstance [13:40] jdstrand, great, thanks! [13:41] Hi [13:41] bloodearnest: the only namespace is the mount namespace for /tmp. we chose to implement the snadbox in this manner because it allows snaps to integrate more fully with the system and to better interact with each other. for people wanting full containers, people can use lxd or docker (though atm neither is available on 16, but will be before GA) [13:41] I have a question about the configuration file [13:42] How are they handle since the snaps are read only [13:42] tyhicks: fyi, in case you didn't notice, I answered stevebiscuit [13:42] I tried the mosquitto snap but I can't edit the mosquitto.conf file. [13:42] jdstrand, right, I assumed a fairly limited namespace usage, was just looking for details [13:43] thomas25: I'll answer since I happened to have seen the question. In general, the snap would be set up to copy the configuration file from $SNAP to $SNAP_DATA and have the daemon use the file in $SNAP_DATA so that the file is then readable. I don't know how mosquitto is packaged though [13:44] thomas25: there used to be a "snap config" command that would use the conf as input and put it into the writable space ... that is temporarily gone and being re-worked [13:44] ok thanks [13:44] thomas25 mosquitto from snapcraft sources? [13:45] yes [13:45] that is just an example, not meant to be configurable afaik [13:45] bloodearnest: if you want the implementation details of what we do with the devices cgroup, see http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/view/head:/README [13:45] boo [13:45] you can add the smarts for it thought (like have it read from SNAP_DATA or SNAP_USER_DATA) [13:45] ogra_ the examples are also a stress tester for snapcraft itself; not for snaps [13:46] ogra_ I wish the core guys wrote more snaps as that would really make sure the system is good [13:46] I should have said "is then *writable*" [13:46] they will come over time :) [13:48] SNAP_DATA nad SNAP_USER_DATA are used to override the path of configuration file in snaps ? [13:48] jdstrand, thanks! already skimming the whitepaper has answers most of my questions! :D [13:48] cool [13:48] thomas25, this question might help: https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data [13:49] Or the snap just copy the configuration file in SNAP_DATA path ? [13:49] thats up to you :) [13:50] the snap only provides the path ... weather you copy it and make your service use it is up to you [13:50] (you could ship an immutable config just in the readonly dir and not allow the user to alter it at all) [13:53] In the snapcraft.yaml how to you say that this goes to SNAP_DATA and that in SNAP_USER_DATA ? [13:54] Just using "copy" plugin ? [13:54] no, you would write a wrapper that does the copying for you on service startup [13:55] kyrofa with great pleasure I deliver this bug to you https://bugs.launchpad.net/bugs/1575188 ;-) [13:55] Launchpad bug 1575188 in Snapcraft "Fix for bug #1572664 had broken my snap package build" [Undecided,New] [13:55] sergiusens, yes I just saw that come in [13:56] sergiusens, thanks :P [13:56] ogra_: Thanks [13:56] kyrofa while the snapping might work, not sure it would ever be accepted by the store with so many dead symlinks [13:57] sergiusens, yeah might be a question for beuno [13:57] jdstrand rather [13:57] I'm sure it won't [13:58] sergiusens, so is this a wontfix, or should the review tools change? [13:58] kyrofa I'd ask him if the review tools passed without warnings in his previous working snaps [13:59] sergiusens, alright :) === zyga_ is now known as zyga [14:14] the pi2 really has no reset button right? (or do i need glasses?) [14:15] asac: it has no buttons at all AFAIK [14:15] looking at mine now [14:15] good :) [14:15] you can use a strobe light to reset it though [14:15] lol [14:15] heheh [14:15] we need strobe interface [14:16] hehe [14:16] maybe i should use my ttl power and then i can use some tricks with /dev/ttyUSB to repower? [14:16] asac: whad are you trying to do? [14:17] just rebooting [14:17] without having to fiddle myself through 5 layers of cables :) [14:18] hoping to not unplug some other board or ttl [14:18] ok installing hello-0world to look at hello-world.sh [14:18] to see what is going on [14:18] nice [14:18] doesnt work :) [14:19] bah the pi2 kernel really always get a reset by peer [14:19] so i cannot even try the latest [14:19] error: cannot perform the following tasks: [14:19] - Download snap "canonical-pi2-linux" from channel "stable" (read tcp 10.42.0.95:56112->69.88.149.140:443: read: connection reset by peer) [14:20] you really dont make friends with that nordic guy today eh ? [14:20] hehe [14:20] he seems to not like the pi2 [14:20] i just built aa set of images here [14:20] db worked fine [14:20] no issues [14:20] to update [14:20] hmmmmmmm [14:20] think its only when you use it from the device [14:21] not during udf [14:21] yep, same here [14:21] hmm [14:21] asac: are you on 3g? [14:21] lol [14:21] no stble landline [14:21] super stable [14:21] 4g :-) ? [14:21] 5L [14:21] : [14:21] :P [14:21] who would do a kernel update of his pi2 over 3G ? [14:21] super proxy in betweeen to read your mail? [14:21] not that i know [14:21] hmm [14:21] i am direct [14:21] * zyga looks from device [14:22] its really something else [14:22] but the device goes through my desktop [14:22] e.g. connection share [14:22] so could be due to that [14:22] hmm, all up-todate [14:22] ahh [14:22] let me think [14:22] maybe, try direct [14:22] have no lan [14:22] but i never had problems [14:23] until today ;) AFAIR n-m doesn't use a proxy but I might be wrong [14:23] no it doesnt [14:23] its pure routing [14:23] too bad nothing works on image so i cannot download a big iso to see [14:23] i am sure that would work :) [14:23] well not so [14:23] let me get a wget [14:24] oh i have chroots [14:24] let me try there [14:24] snap install doesnt work either ? [14:24] for instance i had zero issues setting up those chroots [14:24] works for me [14:24] just tried on pi2 [14:24] image built yesterday [14:25] ok wget http://cdimage.ubuntu.com/ubuntu-core/releases/xenial/release/ubuntu-core-16.04-core-amd64.tar.gz is running [14:25] wget finished [14:25] * zyga goes to pick up kids from school [14:25] no issues [14:26] ogra_: tells me its already installed [14:26] asac, i mean a random snap [14:26] * asac tries [14:27] yeah nmap gives me same error [14:27] xkcd-webserver works [14:28] install mvos image, try refresh [14:28] not working [14:29] weird [14:52] Is it asking for trouble if bundling python 2.7 in a snap? [14:52] just use snapcrafts python plugin [14:53] ogra_, I don't need to build anything in python, it's just that dtrx needs python 2.7 [14:54] ogra_, So I'm just wondering what should be done for such scripts [14:54] using the python plugin ;) [14:54] it makes sure the right bits get bundled [14:54] there was some trick to only get the interpreter ... [14:55] source: . [14:55] or some such [14:55] ogra_, So you mean, not use the deb, but the source archive? [14:55] no, define a snapcraft part that uses the python plugin [14:55] in your snapcraft.yaml [14:55] and use the deb as a staging deb [14:55] which deb ? [14:55] dtrx [14:56] oh [14:56] yeah, with teh copy plugin or so [14:56] The problem is how to run it on the other side [14:56] But I'm guessing Snapcraft will include python2.7 [14:57] Thus my question whether it's a good idea since python 3 is already present [14:58] Because the script calls /usr/bin/python [14:58] well, what does the deb depend on ? [14:58] Depends: python (>= 2.7), python (<< 2.8), bzip2, unzip, cpio, rpm, binutils, p7zip-full, cabextract, unshield, lzma, xz-utils [14:58] smaller than 2.8 ... [14:58] there you got your answer :) [14:59] OK, so Snapcraft will ship Python2.7 and create a wrapper which points /usr/bin/python to /usr/bin/python2.7 ? [15:00] i dont know, thats a sergiusens or kyrofa question :) [15:00] ogra_, oparoz if python is pulled in via stage-packages snapcraft won't do anything special [15:00] but i think it replaces the shebang line in all py scripts it finds [15:00] kyrofa: no, via the python plugin [15:01] kyrofa, Ah, then the script will fail in the snap [15:02] Ah, but ogra_ is right-- the shebangs should be fixed via the stage-packages [15:03] Ah, no, the default in core is 2.7, so I'm guessing v3 scripts in debs use /python3 [15:03] kyrofa, Ah, that's good if snapcraft fixes shebangs [15:04] oparoz, should be replaced with "#!/usr/bin/env python" [15:04] kyrofa, OK and the wrapper will provide the correct env [15:05] yeah [15:05] oparoz, assuming you're using the python plugin, yeah [15:05] OK, I'm going to try that and see if it works, thanks [15:05] python is very unflexible about installation paths which is sad for such a flexible language in itself [15:06] wobbly-python :) [15:07] :D [15:19] <_morphis> zyga: whats with the changes you did for the bluez itnerface? did jdstrand review them? [15:19] I wanted to sync on that today. I'm not sure what is expected at this point [15:20] will be interesting to see what happens if you install it on a desktop :) [15:22] that's another converstation that needs to be had. sdoc interfaces vs core interfaces [15:25] jdstrand, hey, I think you had a go at making at snap from gnome-calculator, is your work available somewhere? we are at a sprint and would like to have a look to start tomorrow, would be nice to restart from scratch if you resolved some of the issues already though [15:26] seb128: I tried, it failed. I talked to dsert and he gave some tips but I was unable to continue. someone I think last week was trying something similar and so I gave my notes. let me find that [15:27] jdstrand, thanks [15:31] seb128: this is the branch (note, it is horrible) -- lp:~jdstrand/+junk/gnome-calculator . Still digging up notes [15:32] jdstrand, thanks [15:32] right, it was sergiusens I talked to about it [15:32] seb128: http://paste.ubuntu.com/15923754/ [15:33] sergiusens, ^ did you look more into that one (before we dup work)? [15:33] seb128: sergiusens was looking at snapping firefox (which is gtk) and I gave him those notes. not sure how much farther he got if at all [15:33] jdstrand, thanks, hopefully we can move things forward at the sprint this week [15:33] cool [15:34] seb128 no I haven't [15:34] though I imagine you're going to need some interfaces work. I was trying to get it to a point where I could look at that, but couldn't at first and then was busy helping with interfaces/etc for release [15:35] sergiusens, no worry [15:35] so a working snap in --devmode would be great [15:35] right [15:36] <_morphis> jdstrand: not sure, zyga just said he wanted your eyes on what we he implemented [15:36] I thought I did that... [15:37] <_morphis> jdstrand: https://github.com/ubuntu-core/snappy/pull/1037#issuecomment-214386816 [15:37] * jdstrand looks at the PR again [15:37] <_morphis> jdstrand: hah, sounds like we're deadlocking :-) [15:38] _morphis: I need zyga to comment. I gave zyga a patch for him to build off of. I haven't seen anything else [15:38] <_morphis> jdstrand: he implemented https://github.com/zyga/snappy/commit/16228ad739da17d0ff975a1d781db4a53dfdbc79 [15:44] _morphis: ok, commented in both [15:44] <_morphis> jdstrand: thanks [15:45] <_morphis> jdstrand: didn't looked through the snappy code yet for this, but isn't there an easy way to figure the plug name? [15:45] _morphis: not at that point in the code [15:46] <_morphis> jdstrand: ok [15:46] <_morphis> ssweeny: can you pull those changes in from zyga? [15:46] <_morphis> jdstrand: will implement the same for networkmanager tomorrow [15:46] _morphis: that is the bit that zyga needed to look at (I gave him a similar patch as the commit which he was going to work off of to get the app name, which isn't available in any of the structures in that function atm) [15:46] _morphis, already pulled them locally and tested them [15:46] _morphis, pushing now [15:47] <_morphis> ssweeny: awesome! [15:47] please add a FIXME comment though [15:48] <_morphis> jdstrand: could you have a look on the minimize dbus policy at https://github.com/ubuntu-core/snappy/pull/1036 too? [15:48] <_morphis> jdstrand: will add the same changes we're doing for security label tomorrow [15:48] jdstrand, it should end up as "snap.bluez." ? [15:48] trying to parse the punctuation in your comment [15:50] ssweeny: what 'it' are you referring to? [15:50] the future fix or the current implementation? [15:51] current proposed* implementation [15:51] _morphis: commented [15:52] <_morphis> jdstrand: thanks [15:52] jdstrand, I mean, should the comment be "FIXME: this glob turns into snap.bluez.* where it *SHOULD* be snap.bluez." [15:54] ssweeny: 'where it *SHOULD* be snap.bluez.' [15:55]