[00:42] <mup> Bug #1571497 changed: snapd crashes on slot disconnection <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1571497>
[00:42] <mup> Bug #1628592 changed: no camera slot in pi2 or pi3 image <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1628592>
[01:02] <guy_davis> Hiya, anyone installed dockerd on snap core 16 beta?  Looking to evaluate Ubuntu Snappy as a minimal OS for hosting docker containers.
[01:46] <mup> Bug #1633289 opened: network-observe plug is not working for dracnmap snap <Snappy:New> <https://launchpad.net/bugs/1633289>
[07:03] <dholbach> good morning
[07:08] <ejat> morning
[07:44] <mardy> how can I specify which Ubuntu release should be used by "stage-packages" and "build-packages"?
[08:32] <vicamo> hi there, do any one know where to send a merge proposal for ubuntu snap-confine package?
[08:32] <vicamo> would like to propose a change to enable running snappy on Ubuntu M10
[08:36] <Rick_> Hello
[08:38] <Rick_> Does someone know the solution of No ssh keys found, at creating user profile setup
[08:56] <mup> PR snapd#2145 opened: cmd/snap: update remove command help <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2145>
[09:12] <ogra_> mardy, i dont think you can (by default it uses the hosts sources.list ...)
[09:15] <mardy> ogra_: OK. It would be nice if there was a way to specify that in snapcraft.yaml, so that one would know in which release a certain snap was built
[09:19] <ogra_> mardy, well, for now you can put it in the description or so
[09:19] <mardy> yep
[09:19] <ogra_> long term -> file a whishlist bug ;)
[09:20] <ogra_> though since you dont really need to use any debs i'*m not sure it is an option thats wanted by default
[09:20] <ogra_> (you can make your snapcraft.yaml complex and build all deps for source for example ... i.e. you wouldnt need to use any debs if you like)
[09:29] <zyga> vicamo: hey
[09:30] <zyga> vicamo: I'm the maintainer of snap-confine, please send me a pull request on github
[09:30] <zyga> vicamo: can you tell me more about what you were working on?
[09:31] <vicamo> zyga: I have to modify the apparmor rules for ubuntu for snap-confine package
[09:31] <vicamo> I guess that's not for the rest of the world?
[09:32] <zyga> vicamo: can you tell me more about what you need to modify and why?
[09:33] <vicamo> zyga: it's an open bug in https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1633367
[09:33] <mup> Bug #1633367: missing ptrace options needed by snap-confine <snappy> <systemd> <Canonical System Image:New> <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1633367>
[09:33]  * zyga looks
[09:35] <zyga> vicamo: can you tell me which kernel version are you using on m10
[09:35] <vicamo> zyga: a pretty outdated 3.10
[09:36] <ogra_> could be worse ... could be 2.18 :P
[09:36] <zyga> vicamo: does it include the patched apparmor stack?
[09:36] <vicamo> zyga: yes, it has, but again, outdated 3.1 or so
[09:36] <zyga> vicamo: I mean the updated patch for 3.10 kernels?
[09:37] <zyga> vicamo: one sec
[09:37] <zyga> vicamo: https://github.com/snapcore/sample-kernels
[09:37] <mup> PR snapcraft#869 opened: Bring docs/upload-your-snap.md in line with http://snapcraft.io/docs/… <Created by dholbach> <https://github.com/snapcore/snapcraft/pull/869>
[09:37] <zyga> vicamo: in any case, please fork snap-cofnine and open a pull request
[09:37] <zyga> vicamo: the code is on github.com/snapcore/snap-confine
[09:38] <zyga> vicamo: I'll work with jamie to review it
[09:38] <zyga> vicamo: and be sure to try current master
[09:38] <vicamo> zyga: that sameple kernel has a 3.10 tree, but its apparmor part is not up-to-date, either
[09:38] <zyga> vicamo: a large change just landed
[09:38] <zyga> vicamo: ah, I see, I wasn't aware of that
[09:38] <Rick_> At the first boot of snappy core, at the login/registration, where i must fill in my email, it is saying that there are no ssh keys found and that my account could not be breate
[09:39] <Rick_> created
[09:39] <zyga> Rick_: your keys are taken from your launchpad.net account
[09:39] <Rick_> Could someone help me?
[09:39] <vicamo> I've also checked the rest of snap-confine code base on github, I need to land a change in the apparmor rules, not snap-confine itself
[09:40] <zyga> vicamo: that is in src/snap-confine.apparmor.in
[09:40] <Rick_> Zyga: Thank you!
[09:40] <vicamo> zyga: ah!
[09:50] <Rick_> Zyga: How can i get my keys?
[09:50] <Rick_> I created my account, and tried it again, but the same error, the account could not be created, no ssh keys found
[09:52] <Rick_> Aah, i must register a key, using launchpad.net i saw, gonna try i
[09:52] <Rick_> *it
[09:55] <Brad__> join
[09:55] <Brad__>  hello
[09:56] <Brad__> Anyone creating snaps?
[09:56] <Brad__> Anyone here?
[09:56] <ogra_> only 302 people
[09:57] <Brad__> Oh !
[09:57] <davmor2> ogra_: I'm not I'm breaking them :P
[09:57] <ogra_> heh, true :)
[09:58] <Brad__> That's about as far as i have got, too
[09:58] <ogra_> thats a good start ;)
[09:59] <zyga> Rick_: look at your launchpad profile, there's a SSH section there
[09:59] <Rick_> Thanks Zyga, i followed the instructions and it is working. :) Jeahh Thankss, This awnser was the only one i could find
[10:01] <zyga> Rick_: I'm glad to hear that :)
[10:01] <vicamo> zyga: https://github.com/snapcore/snap-confine/pull/170 pr ready, but it seems CI is currently broken?
[10:01] <mup> PR snap-confine#170: Add apparmor ptrace options for snap-confine <Created by vicamo> <https://github.com/snapcore/snap-confine/pull/170>
[10:05] <Brad__> Can anyone help me create a basic calculator, chat or notepad snap? I tried the yaml on github but it says an error msg. Do i need to install packages? Has anyone got some yaml code which will work?
[10:08] <Brad__> bump
[10:13] <Brad__> only 302 people
[10:14] <ogra_> !patience
[10:14] <ogra_> ;)
[10:14] <Brad__> oh, thank :)
[10:15] <ogra_> it might be helpful if you pasted the error you get on paste.ubuntu.com and give the pastebin url so people can look at it
[10:16] <Brad__> okay, great!
[10:31] <Brad__> http://paste.ubuntu.com/23322759/
[10:32] <ogra_> Brad__, so you are using a PPA that has no xenial packages it seems
[10:34] <Brad__> okay -do you know how i can the xenial packages? Or exclude the PPA?
[10:34] <ogra_> snapcraft uses your hosts apt sources ... disable it on your PC and snapcraft wont try to use it
[10:37] <ogra_> (alternatively call "snapcraft cleanbuild" that will build inside a container and not use the info from the host machine)
[10:37] <Brad__> okay, thanks so much. do you know how i can disable it? :)
[10:37] <ogra_> well, how did you enable it ... ? :)
[10:37] <ogra_> you obviously set it up once ... to install ubuntu-tweak i guess
[10:38] <Brad__> oh, :/ :)
[10:38] <ogra_> just go to your software sources in the settings and turn it off there
[10:38] <Brad__> great. thank you.
[10:45] <mup> PR snapd#2146 opened: asserts: remove serial-proof type <Created by emgee> <https://github.com/snapcore/snapd/pull/2146>
[11:13] <mectors> sudo snap create-user --sudoer --json tadhackuser@gmail.com
[11:13] <mectors> error: while creating user: cannot create user: device already managed
[11:13] <mectors> ???
[11:13] <mectors> Why can I not add another user to Ubuntu Core 16
[11:15] <mectors> found it. You have to logout
[11:20] <mattyw> hey folks, which repository should snap be coming from on trusty?
[11:20] <mattyw> (snapd that is)
[11:22] <mup> PR snapd#2147 opened: asserts: validate optional account username <Created by emgee> <https://github.com/snapcore/snapd/pull/2147>
[11:22] <zyga> mattyw: eventually the same one
[11:23] <zyga> mattyw: the trusty archive
[11:23] <mattyw> zyga, I was expecting to just be able to do apt-get install snapd, but it can't be found
[11:25] <joc_> zyga: hi, if you are happy with the comments from jamie could you merge my PR in to your branch https://github.com/zyga/snapd/pull/2
[11:25] <mup> PR zyga/snapd#2: Make sure gpio exported before apparmor setup <Created by jocave> <https://github.com/zyga/snapd/pull/2>
[11:26] <zyga> mattyw: It's not available yet
[11:26] <mup> Bug #1632453 changed: snapd won't start on dragonboard <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1632453>
[11:26] <zyga> joc_: I'll check that out next week, I'm on holidays, in theory, this week
[11:26] <mup> PR snapd#2146 closed: asserts: remove unused serial-proof type <Created by emgee> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2146>
[11:26] <zyga> joc_: (but hey, /media support landed today)
[11:27] <joc_> zyga: ok that's fine, lets see if we can get it resolved next week
[11:27] <zyga> joc_: we'll work on the release next week
[11:27] <zyga> joc_: face to face will be faster
[11:27] <joc_> +1 :)
[11:27] <zyga> (hopefully over beer at the bar)
[11:28] <mattyw> zyga, ok thanks
[11:30] <mattyw> zyga, is there a ppa it can be got from though?
[11:57] <liuxg> ogra_, now I am removing a snap, but it shows me "2016-10-14T11:54:33Z ERROR cannot remove snap file "lights", will retry in 3 mins: umount: /snap/lights/x1: not mounted". what shall I do next? I just want to remove the app.
[11:58] <ogra_> well, why is the snap not mounted ?
[11:58] <ogra_> did you manually unmount it ?
[11:58] <liuxg> ogra_, it was mounted yesterday. today, I want to install a new version. Before that, I wanted to remove it first.
[11:58] <liuxg> ogra_, No, I did not do that.
[11:59] <liuxg> ogra_, using snap list, it shows "lights                            x1              devmode,disabled,broken"
[11:59] <ogra_> well, it looks like you tinkered with it manually somehow
[11:59] <liuxg> ogra_, frankly, I did not do that.
[12:00] <ogra_> check snap changes and take a look at the offending change there with "snap change <number>"
[12:01] <liuxg> ogra_, I quit the command by Ctrl+c. then http://paste.ubuntu.com/23323101/
[12:01] <ogra_> well, obviously take a look at 92
[12:02] <liuxg> ogra_, what can I look at?
[12:02] <ogra_> the details of that change
[12:02] <liuxg> ogra_, in the step, it just happened like the message I showed you.
[12:03] <liuxg> ogra_, where can I find the detail of the change？
 check snap changes and take a look at the offending change there with "snap change <number>"
[12:04] <liuxg> ogra_, http://paste.ubuntu.com/23323114/
[12:05] <ogra_> Error   2016-10-14T11:51:46Z  2016-10-14T11:54:24Z  Remove security profile for snap "lights" (x1)
[12:05] <ogra_> now, no idea why that fails
[12:06] <ogra_> probably ask someone from the snapd team or security how o debug this further
[12:06] <ogra_> *how to
[12:06] <ogra_> (and file a bug if you are sure you havent manually tinkered with the snap in any way)
[12:07] <liuxg> ogra_, it is ok. thanks. Have a good night! I really do not know how to debug this kind of issue.
[12:07] <ogra_> that is why i point you to people that do know :)
[12:07] <ogra_> (i dont either and for me it is also still early afternoon btw ;) )
[12:09] <liuxg> ogra_, many thanks. it is a night here :) I may find someone to help out.
[12:09] <ogra_> perhaps zyga has an idea (seems mvo is off today)
[12:12] <didrocks> even if there has been some manual tinkering, it's a good use case to make snapd reliable against that and recover its state from it :)
[12:12] <didrocks> like not being mounted sounds like the code isn't there anymore, and it's safe to proceed
[12:12] <ogra_> yes, which is why i suggested to file a bug :)
[12:12] <didrocks> yep!
[13:25] <kgunn> cjwatson: if you're about, i have a particular snap build failure that seems "sticky" to a particular project
[13:25] <kgunn> https://launchpadlibrarian.net/289526453/buildlog_snap_ubuntu_xenial_amd64_miral-snap_BUILDING.txt.gz
[13:26] <kgunn> i mean i can build that locally & the error is a unknown to me...wondering if you could take a look and give me your $0.02
[13:29] <ogra_> kgunn, try adding the ubuntu image build PPA to your snap build
[13:30] <ogra_> we have a fixed bzr
[13:30] <ogra_> or enable proposed, the fix is there as well, but not yet landed
[13:30] <kgunn> ogra_: ah thanks!
[13:30] <kgunn> ogra_: so just proposed instead of "updates"
[13:31] <ogra_> bug 1606203
[13:31] <mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <verification-needed> <Bazaar:Fix Committed by vila> <Snapcraft:Invalid by sergiusens> <bzr (Ubuntu):Fix
[13:31] <mup> Released> <bzr (Ubuntu Xenial):Fix Committed by cjwatson> <https://launchpad.net/bugs/1606203>
[13:31] <ogra_> kgunn, yeah
[13:31] <kgunn> ta
[13:36] <cjwatson> oh, I've been meaning to verify that
[13:36] <cjwatson> kgunn: hey, if you enable proposed and it works, could you do me a favour and replace the verification-needed tag on that bug with verification-done?
[13:37] <kgunn> happy to
[13:37] <cjwatson> 'cos that was basically what I was going to test
[13:37] <cjwatson> and definitely use proposed rather than the PPA, that way it's a valid test for SRU verification purposes
[13:41] <kgunn> cjwatson: ah, same error...but wonder, is it b/c i'm targeting xenial?
[13:41] <kgunn> https://code.launchpad.net/~kgunn72/+snap/miral-snap/+build/6938
[13:44] <niemeyer> jdstrand: ping
[13:44] <cjwatson> kgunn: you didn't enable -proposed there
[13:44] <jdstrand> niemeyer: hey
[13:44] <niemeyer> jdstrand: Yo, good morning
[13:45] <niemeyer> jdstrand: How're things going in snap-declaration land?
[13:45] <cjwatson> kgunn: and, well, yes it's because you're building from xenial, but the proper fix for that isn't to build from some other series, it's for us to get this fix verified :)
[13:46] <cjwatson> kgunn: huh.  you did *try* to enable -proposed.  but no mention of it in the build log ...
[13:46] <cjwatson> that's weird
[13:46] <jdstrand> niemeyer: I have checks against the base declaration working, except for alternations. after that, will add the bits for when the store gives the payload
[13:47] <kgunn> cjwatson: lemme know if you want me to try something else
[13:47] <jdstrand> niemeyer: so the review tools are pretty close. it took longer than I expected but it should be solid
[13:47] <cjwatson> kgunn: let me scratch my head about this for a bit first
[13:47] <kgunn> you bet
[13:47] <jdstrand> niemeyer: I don't know the status on the store side
[13:47] <niemeyer> jdstrand: As we discussed earlier in the week, the main concern at this point is the snap-declaration text itself
[13:48] <niemeyer> jdstrand: We need the text ready so that we can take out the hardcoded logic
[13:48] <niemeyer> jdstrand: We can import the initial declarations by hand if necessary
[13:48] <niemeyer> jdstrand: But we need them there so that we can update and release snapd
[13:48] <jdstrand> niemeyer: yes. my understanding was that the store guys were going to put that in the store db
[13:49] <niemeyer> jdstrand: Right, but do we have "that"? :)
[13:49] <jdstrand> roadmr: can you comment on that work ^
[13:49] <niemeyer> jdstrand: The question is really the snap-declaration body for the constraints
[13:49] <roadmr> jdstrand: sure, give me a bit as I'm OTP
[13:49]  * jdstrand nods
[13:50] <niemeyer> jdstrand: We're in touch with matiasb as well, who's working on the feature and aware of these ideas
[13:50] <jdstrand> I see
[13:51] <niemeyer> jdstrand: So the main thing I'm bothering you about (sorry!) is the final/real text for the base and the individual snaps that allows us taking out the hardcoded logic.. with that in hands we can land the declarations and update snapd
[13:51] <cjwatson> kgunn: ah, this is because you're building against a PPA and they have confusingly different rules
[13:51] <matiasb> jdstrand, fyi, from the store UI it is already possible as reviewer to push update plugs/slots for a snap declaration
[13:51] <cjwatson> ogra_: did you have a snap that builds only from the primary archive where you could test the bzr fix in -proposed?
[13:52] <jdstrand> matiasb: ok. so, for example, I can handcraft the payload for lxd, and the store will regenerate the snap declaration for snapd to consume?
[13:52] <ogra_> cjwatson, hmm, not really ... all my snaps that need bzr actually also need to use the PPA for other bits
[13:53] <matiasb> jdstrand, exactly
[13:53] <jdstrand> ok cool
[13:54] <jdstrand> niemeyer: so, since that is done ^ shall I transition to making the change to the base declaration in snapd? I need that anyway and I also worked through that a bit yesterday, so it should be quick
[13:54] <jdstrand> quickish
[13:55] <niemeyer> jdstrand: Yeah, that plus the few special allowances we have would be great to have ready, thank you!
[13:55] <jdstrand> it's possible I might need some help with the testsuite, but I'll know more when I get in there
[13:56] <jdstrand> ok, I'll move to that
[14:02] <roadmr> jdstrand: finally of the phone, but yeah, what matiasb said, the store is already spitting out snap-declaration with plugs/slots which can be edited by reviewers. Plus it gets a small amount of validation against the most basic shot-in-the-foot scenarios
[14:06] <jdstrand> roadmr: ack. I made several commits to the review tools. I need to pivot to snapd now, but the tools should be ready for a pull pretty soon after I finish with snapd
[14:08] <roadmr> jdstrand: awesome! we can push that to the store when available, and there's a switch we can flip if things misbehave, so at least we'd call the tools "the old way" (no slots/plugs for preapproval). Recall we'll be sprinting next week so that may affect response times a bit
[14:09] <jdstrand> I definitely remember we'll be sprinting next week :)
[14:10] <cjwatson> ogra_: all right, let me see if I can hack something up
[14:10] <ogra_> i can surel dpo something like that too, but a nnit later today if you dont get to it
[14:10] <roadmr> jdstrand: hehe :)
[14:11] <ogra_> *but a bit
[14:18] <cjwatson> ogra_,kgunn: OK, verified now, I expect it'll be released on Monday (no SRU releases on Friday, normally)
[14:24] <mup> PR snapd#2140 closed: asserts,snap: validate attributes to a JSON-compatible type subset <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2140>
[14:39] <mup> PR snapd#2138 closed: many: removed frameworks target, and some leftover frameworks helpers… <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2138>
[14:41] <mup> PR snapd#2145 closed: cmd/snap: update remove command help <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2145>
[14:50] <mup> PR snapd#2107 closed: client,daemon,cmd: add payment-declined error kind <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2107>
[14:51] <mup> PR snapd#2139 closed: cmd/snap: tweak unknown command error message <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2139>
[15:08] <kgunn> ogra_: hey what was the ppa containing the fix for this lp issue?
[15:08] <abeato> jdstrand, ofono PR refreshed after changing the comment. Spread tests are failing but it looks unrelated to the PR
[15:09] <abeato> "cannot bind mount /snap/core/current//var/lib/console-conf -> /var/lib/console-conf with flags 0x85007. errmsg: Permission denied"
[15:50] <Croepha> Hi
[15:51] <Croepha> So, using current version of snapcraft using kernel plugin is most current way to make a kernel snap for core 16 right?
[16:06] <kyrofa> Croepha, yep
[16:06] <ogra_> kgunn, https://launchpad.net/~snappy-dev/+archive/ubuntu/image
[16:06] <Croepha> and by current version i mean the version that ubuntu desktop 16.04 sais is stable?
[16:06] <Croepha> says
[16:07] <Croepha> kyrofa: ok thanks :)
[16:18] <jdstrand> pedronis: hey, so I have an updated base declaration, but all the snowflake handling in the testsuite is taking me a bit to sort through
[16:19] <pedronis> jdstrand: we need a bit to coordinate
[16:21] <pedronis> jdstrand: do you want to push something for me to look at?
[16:22] <pedronis> jdstrand: also are now all interfaces mentioned at least once in slots or plugs?
[16:23] <jdstrand> let me push something
[16:25] <jdstrand> pedronis: https://github.com/jdstrand/snapd/tree/finish-decl-based-checks
[16:27] <pedronis> jdstrand: so basically need to work to make test pass again?
[16:28] <jdstrand> pedronis: that and then to remove the hardcoded stuff for lxd, docker, etc, and then to make pass again.
[16:28] <jdstrand> pedronis: I saw a snowflake for snapd-control too
[16:28] <pedronis> yes
[16:28] <pedronis> we didn't block it
[16:29] <pedronis> anyway before this can land
[16:29] <pedronis> we need all the matching decl in the store
[16:29] <jdstrand> oh, it is deny-auto-connection: false still in the base declaration
[16:29] <jdstrand> so that is stilla  snowflake
[16:30] <jdstrand> pedronis: should I change that now?
[16:30] <pedronis> jdstrand: I think the idea is to change everything
[16:30] <pedronis> but we need the decls
[16:30] <pedronis> that one is snapweb?
[16:31] <jdstrand> I can supposedly add the decls
[16:31] <pedronis> and I don't know what else
[16:31] <pedronis> jdstrand: maybe matiasb can also help telling how to search things that use some of those plugs
[16:33] <matiasb> pedronis, jdstrand, we should be able to search CPI for plugs/slots, at least for plugs/slots declared in the yaml (I think, maybe cprov can confirm?)
[16:35] <cprov> matiasb: I am not sure it's working, we never finished that implementation.
[16:36] <matiasb> ah, ok, I can try and take a look to confirm
[16:38] <jdstrand> pedronis: ok, I updated snapd-control to not auto-connect but the testsuite doesn't show there is an error there, which I expected it would
[16:39] <jdstrand> pedronis: (I made the change in the base decl)
[16:39] <Elleo> is there some way to make URL opening work from snappy apps? I'm currently trying to snap up podbird, but external links using Qt.openUrlExternally() just result in things like "Unable to detect a web browser to launch 'http://community.ubuntu.com/contribute/translations'"
[16:40] <jdstrand> matiasb, cprov: I was told I would be able to add plugs and slots via the web form now. is that the case?
[16:40] <pedronis> jdstrand: that sound strange, wrong syntax, I see the test that should fail
[16:40] <ogra_> Elleo, try adding /usr/local/bin to your PATH ...
[16:40] <ogra_> Elleo, inside yor snap that is
[16:40] <Elleo> ogra_: okay, thanks
[16:41] <ogra_> which reminds me ... jdstrand was there any conclusion about the /usr/local/bin stuff inside the core snap yet ?
[16:41] <matiasb> jdstrand, correct, when reviewing a snap revision, you should now have an interfaces section with a link to the form to update the snap declaration
[16:41] <pedronis> jdstrand: I need to have dinner, back in a bit
[16:42] <jdstrand> matiasb: is that something I can do without an upload? ie, I go find lxd, then add the necessary plugs/slots and then it is done, or does it have to be tied to an upload?
[16:42] <cprov> matiasb: https://search.apps.ubuntu.com/docs/#slots, not exactly a direct filter, more like 'given the provided slots, omit incompatible plugs' ...
[16:45] <jdstrand> cprov: I barely remember the context for that. I think I mentioned it to mvo and he agreed it needed to be fixed
[16:45] <jdstrand> err
[16:45] <jdstrand> cprov: nm
[16:45] <jdstrand> ogra_: ^
[16:46] <ogra_> jdstrand, ah, well ... thats about teh xdg-open hack we ship (but also a fake "apt" that just echost "please use snap" )
[16:46] <ogra_> i guess a topic for next week then
[16:47] <matiasb> jdstrand, not tied to an upload, you can update the declaration at any time; link available there atm because it is expected that you may need to update a decl if review indicates so
[16:49] <cprov> jdstrand: It's definitely not useful atm and it's not even supported for snap-specific searches (v1/snaps/search), we should not count on this.
[16:49] <cprov> matiasb: ^
[16:49] <matiasb> jdstrand, you can try with this search: https://search.apps.ubuntu.com/api/v1/snaps/search?fields=name,plugs,slots (4 pages)
[16:49] <matiasb> jdstrand, that will return all snap pakages, and their indexed values for plugs/slots, I guess that should help
[16:53] <jdstrand> matiasb: in this url: https://search.apps.ubuntu.com/api/v1/package/Oulq6jI8qkI4ScWVafl3VsxSsd52HSGu is Oulq6jI8qkI4ScWVafl3VsxSsd52HSGu the snap id?
[16:54] <jdstrand> matiasb: also, that page is incomplete
[16:54] <jdstrand> but that's ok
[16:54] <jdstrand> today, all slots implementations are flagged for manual review by the store
[16:55] <jdstrand> actually, that's not true
[16:55] <jdstrand> I need everything
[16:56] <cprov> jdstrand: try this https://pastebin.canonical.com/168034/
[16:57] <cprov> for overview purposes
[17:01] <jdstrand> cprov: that's incomplete. for example, locationd is not listed: https://myapps.developer.ubuntu.com/dev/click-apps/5666
[17:02] <cprov> jdstrand: it's not published on stable channel
[17:02] <jdstrand> cprov: what is the query for alls snaps and all channels?
[17:03] <cprov> jdstrand: unfortunately not, search was designed to operate on stable only.
[17:03] <jdstrand> docker isn't either
[17:04] <jdstrand> I guess I'll just have to go with what I know is implementing the slot side and using the plugs
[17:06] <jdstrand> matiasb: I'm looking at the web form. do I need to add 'slots:' to the slots textarea or will it add it for me?
[17:07]  * jdstrand tries on a test snap
[17:09] <cprov> jdstrand: Snap admin/overview APIs are non-existent at moment and we are starting to miss them.
[17:14] <jdstrand> hmm
[17:14] <jdstrand> matiasb: if I add this to slots: {"bluez": {"allow-connection": {"plug-publisher-id": [".*"]}}}
[17:14] <jdstrand> matiasb: I get "could not sign assertion (cannot assemble assertion snap-declaration: plug-publisher-id in allow-connection in slot rule for interface "bluez" contains an invalid element: ".*")"
[17:15] <jdstrand> I can use something else, but that seems like a bug
[17:16] <matiasb> jdstrand, that's an error from SAS... pedronis, fyi ^
[17:16] <jdstrand> {"bluez": {"allow-connection": {"plug-snap-type": ["app"]}}} worked
[17:16] <pedronis> jdstrand: regexps are not supported in id lists
[17:16] <pedronis> (they are not in the spec as far as I know)
[17:17] <jdstrand> I thought they were supported anywhere a string is
[17:17] <jdstrand> anyway, no matter for now, I can do a different thing
[17:17] <pedronis> jdstrand: no
[17:18] <pedronis> jdstrand:  Plug and slot attributes are specified with the following syntax
[17:18] <pedronis> and the it mentions regexps
[17:18] <jdstrand> pedronis: so, I can add the snap declarations to the store. and I can pull out the lxd, docker, etc hard coded things. I think I'll need help with getting the testsuite working properly though
[17:18] <pedronis> jdstrand: understood
[17:21] <jdstrand> pedronis: I also don't know how to 'turn it on' per se. iiuc, the base declaration changes are what do that. is it enough for me to compile a snapd with my base decl change, then try to install something from the store and see that it fails, then adjust the snap decl in the store and see that it works?
[17:21] <pedronis> jdstrand: yes
[17:21] <jdstrand> ok, let me try that
[17:22] <pedronis> we still want to cover with the unit tests
[17:22] <jdstrand> of course
[17:22] <pedronis> but yes, to try for real we need that
[17:22] <jdstrand> I'm not sure how to fake a snap declaration in the testsuite
[17:23] <jdstrand> iirc, we were testing primarily against the base decl, not a snap decl
[17:24] <pedronis> jdstrand: no we already did a bit of that, see the test for LXD
[17:24] <pedronis> and mockSnapDecl
[17:25] <pedronis> you can pass in plugs and slots stanzas
[17:25] <pedronis> (not used yet but supported by that)
[17:26] <jdstrand> pedronis: ok, so I'm still not clear on who is doing what
[17:28] <pedronis> jdstrand: well it makes for you to fill in as much snap decl as possible, and then to push the branch as far as possible but reasonable and then I pick up from there
[17:28] <pedronis> jdstrand: I have another couple of things to finish/start first so I cannot simply jump on that right now
[17:28] <jdstrand> ok. I think I see what I need to do with lxd. let's see how far I get
[17:48] <jdstrand> pedronis: fyi, https://github.com/snapcore/snapd/commit/173152497e8e3e9d1966982ca4cd875376d94590 - I expected the second test to fail
[17:51] <pedronis> jdstrand: why is the first one also passing, with IsNil?
[17:51] <pedronis> jdstrand: I agree, I need to try and debug
[17:52] <jdstrand> pedronis: well, on the first one I was trying to create a snap decl that would allow the lxd snap to auto connect
[17:53] <jdstrand> pedronis: did I not do it right?
[17:53] <pedronis> jdstrand: I really need to grab your branch and play a sec
[17:55] <pedronis> jdstrand: let me try
[17:59] <pedronis> jdstrand: you have lxd-support on both slots and plugs side of the base decl for example, remember only one side of those is used
[17:59] <jdstrand> pedronis: oh, the very first one shouldn't pass, you are right. I had IsNil, I meant to have NotNil
[17:59] <jdstrand> TestAutoConnectionLxdSupport
[17:59] <jdstrand> cand := s.connectCand(c, "lxd-support", "", "") <- should fail
[17:59] <pedronis> yea
[18:00] <pedronis> but passes
[18:00] <pedronis> because of what I mentioned
[18:00] <jdstrand> lxdDecl := s.mockSnapDecl(c, "lxd", "J60k4JY0HppjwOjW8dZdYc8obXKxujRu", "canonical", plugsSlots) <- should pass
[18:00] <jdstrand> oh
[18:00] <jdstrand> hmm
[18:00] <jdstrand> ok, that explains snapd-control too
[18:00] <pedronis> jdstrand: it's the rule we wrote down
[18:01] <pedronis> not let me try to understand the other one
[18:01] <pedronis> now
[18:01] <jdstrand> pedronis: remind me why only one side?
[18:02] <pedronis> jdstrand: you decided that
[18:02] <pedronis> or you mean technically?
[18:02] <jdstrand> I don't recall deciding that... maybe I was thinking of something else
[18:03] <jdstrand> anyway, let me see if I can make it work with the current implementation
[18:03] <pedronis> jdstrand:  # - the final decision is taken by evaluating the opinion of the snap plug,
[18:03] <pedronis> #   then the snap slot, then the base plug, and finally the base slot, in that
[18:03] <pedronis> #   order. The first of those that define any rule about the circumstance is
[18:03] <pedronis> #   taken as the final decision. No merging is performe
[18:03] <pedronis> d
[18:04] <jdstrand> the no merging I was thinking was between the snap and base declarations
[18:05] <jdstrand> but I see in the plugs side there is no auto-connection, so it goes through
[18:05] <pedronis> jdstrand: well, you also reviewed the code
[18:05] <jdstrand> man, this is tricky to get the base declaration correct
[18:05] <pedronis> it sort of means
[18:06] <pedronis> you can only use one side for most stuff
[18:06] <pedronis> or it gets delicate
[18:06] <jdstrand> indeed
[18:06] <jdstrand> that is the sort of thing that was hard to see until stuff was implemented and tried to be put into use
[18:06] <jdstrand> anyway, working through it
[18:07] <pedronis> I don't expect doing merge
[18:07] <pedronis> to make the life easier for the code
[18:07] <pedronis> so probably it wouldn't be easy to understand
[18:07] <pedronis> what happens
[18:07] <pedronis> though it my DWIM
[18:07] <jdstrand> I'm not suggesting we change it. I'm only saying that it makes defining the base declaration tricky and I have to work through some of the corner cases
[18:08] <pedronis> jdstrand: yea, that's why being to write tests reasonably is good
[18:08] <pedronis> being able
[18:11] <jdstrand> hrm
[18:12] <pedronis> jdstrand: about there other test is not picking up the slots declaration, trying to see why
[18:13] <jdstrand> I'm not sure this is going to work right for super-privileged interfaces. maybe I need to rethink what that means
[18:13] <jdstrand> cause it makes no sense to use 'plugs' for a plugging snap cause you can't specify the plug-snap-id on the plugs side
[18:14] <pedronis> well if you are in snap
[18:14] <pedronis> it doesn't make sense to limit by snap-id
[18:14] <pedronis> you just say
[18:14] <pedronis> yes
[18:15] <jdstrand> pedronis: I'm trying to be able to say "only the lxd snap may use lxd-support'
[18:15] <pedronis> jdstrand: you can say it on lxd snap
[18:15] <pedronis> though
[18:16] <pedronis> anyway still working through your other failing test
[18:16] <jdstrand> if I use deny-connection: true in the slots side of the base declaration, what does that mean for an implicit slot?
[18:16] <pedronis> ?
[18:16] <pedronis> it means nothing can connect
[18:16] <pedronis> (that's not specific to implicit though)
[18:17] <pedronis> but you can override in the snap plug rule
[18:17] <jdstrand> pedronis: ok, let me put it this way: can you show me a base decl for implicit slot 'foo' that should be denied to everyone. and then a snap decl for a snap that plugs: [foo] that allows it?
[18:18] <pedronis> base-decl:
[18:18] <pedronis>    slots:
[18:18] <jdstrand> (denied to everyone on the plugs side that is)
[18:18] <pedronis>    foo:
[18:18] <pedronis>    deny-connection: true
[18:18] <pedronis> snap-decl
[18:18] <pedronis> plugs:
[18:18] <pedronis>    foo:
[18:18] <pedronis>    allow-connection: true
[18:18] <pedronis> ?
[18:19] <jdstrand> right, that is what I was planning to do, but what does that mean on the slots side for an implicit slot?
[18:19] <pedronis> sorry
[18:19] <pedronis> I'm not parsing that sentence
[18:19] <jdstrand> ie, will the core snap not connect?
[18:19] <pedronis> connect to what?
[18:20] <jdstrand> there are two side of a connection
[18:20] <jdstrand> a slot and a plug
[18:20] <pedronis> jdstrand: we discussed this
[18:20] <pedronis> jdstrand: this checks happen at higher level
[18:20] <pedronis> so the implicit side does whatever
[18:20] <pedronis> it does
[18:20] <pedronis> that's about installation
[18:20] <pedronis> I imagine
[18:21] <pedronis> jdstrand: we don't check these rules
[18:21] <jdstrand> so you are saying I should ignore the fact that an interface is implicit?
[18:21] <pedronis> until we are giving two sides
[18:21] <pedronis> s/giving/given/
[18:21] <jdstrand> and an implicit slot only has one side in the code?
[18:21] <pedronis> I don't know
[18:21] <jdstrand> right, me either
[18:21] <jdstrand> which was why I was trying to be careful here
[18:21] <pedronis> I suspect is lower level than this
[18:22] <pedronis> I haven't seen anything that connect those as things
[18:22] <jdstrand> let me just try to work through it the way we were thinking (slot only in base decl and plug snap decl override)
[18:23] <pedronis> I suspect the implicit stuff is written when you have connections
[18:23] <pedronis> but is not a connection
[18:23] <pedronis> or something like that
[18:23] <jdstrand> also, what does this mean:
[18:23] <jdstrand> base decl:
[18:24] <jdstrand> slots:
[18:24] <jdstrand>   foo:
[18:24] <jdstrand>     allow-installation: false
[18:24] <jdstrand> within the context of an implicit slot
[18:24] <pedronis> probabbly means you cannot refresh the snap os
[18:24] <jdstrand> right
[18:24] <jdstrand> that isn't great :)
[18:24] <jdstrand> which is why I had:
[18:24] <jdstrand> plugs:
[18:24] <pedronis> installation rules
[18:25] <pedronis> should mostly be about
[18:25] <jdstrand>   lxd-support:
[18:25] <pedronis> snap-type
[18:25] <jdstrand>     allow-installation: false
[18:25] <pedronis> or be on the plugs side
[18:25] <jdstrand> but that doesn't work
[18:25] <pedronis> why?
[18:25] <jdstrand> I mean, it would work, but then I have both sides in the base decl
[18:25] <pedronis> that's ok
[18:25] <pedronis> as long they are not about the same kind of rule
[18:25] <pedronis> we can add a sanity check test about that sort of stuff
[18:26] <pedronis> installation rules vs connection vs auto-connection
[18:26] <pedronis> are orthogonal
[18:26] <pedronis> that order for each
[18:26] <jdstrand> the allow-installation rules are weird though in that the snap id isn't in there
[18:26] <pedronis> is not about any rules in general
[18:26] <pedronis> s/that order/that order is/
[18:27] <jdstrand> I would have to do in the snap decl
[18:27] <jdstrand> plugs:
[18:27] <jdstrand>   lxd-support:
[18:27] <jdstrand>     allow-installation: true
[18:27] <pedronis> yes
[18:27] <jdstrand> I guess that is good enough
[18:27] <jdstrand> cause the snap id is up above
[18:27] <pedronis> yes
[18:27] <jdstrand> ok
[18:27] <pedronis> I honestly  hope/expect
[18:27] <pedronis> most snap level
[18:27] <pedronis> rule to be simple turn on
[18:27] <pedronis> something denied in general
[18:28] <pedronis> but allowed for this one
[18:28] <pedronis> snap
[18:29] <pedronis> jdstrand: ok, I find out the issue with your tests as it is
[18:32] <pedronis> jdstrand: you are using  slot rules on the plug side
[18:32] <pedronis> even the passing test is wrong
[18:33] <jdstrand> pedronis: I'm reworking this base on our conversation
[18:33] <pedronis> jdstrand: anyway let me show you the diff so we are on the same page
[18:34] <pedronis> jdstrand: http://pastebin.ubuntu.com/23324868/
[18:34] <pedronis> s/docker-support/lxd-support/
[18:35] <pedronis> and lxdDecl goes into the cand.SlotSnapDeclaration side
[18:35] <jdstrand> oh, haha
[18:35] <pedronis> it's lxd is offers the slot
[18:35] <pedronis> we check slot rules only on the slot snap
[18:35] <jdstrand> lxd-support is an implicit slot
[18:35] <pedronis> and plug rules only on the plug snap
[18:36] <pedronis> ah ok
[18:36] <pedronis> then the test is a bit non-sensical
[18:36] <pedronis> but anyway we discussed
[18:36] <pedronis> this stuff
[18:36] <jdstrand> let me work through it
[18:36] <pedronis> ok
[18:36] <pedronis> but the infra seems to do the right things
[18:37] <pedronis> but positive tests are delicate
[18:37] <pedronis> (given that allow is the default)
[18:37] <jdstrand> we also discussed it weeks ago. putting it into practice with the nuances that are there is tricky
[18:37]  * jdstrand is working through it
[18:37] <pedronis> jdstrand: I understand, just saying not seeing a bug yet
[19:50] <mup> PR snapd#2148 opened: many: introduce an assertion format iteration concept, refuse to add unsupported assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/2148>
[19:59] <barry> hi all; i'm wondering if the python plugin for snapcraft has changed has changed recently.  my snapcraft.yaml that used to build ubuntu-image now does't get all the stage-packages installed correctly: https://github.com/CanonicalLtd/ubuntu-image/blob/master/snapcraft.yaml
[20:00] <barry> it worked fine for 0.7ubuntu1 (2016-10-06)
[20:00] <barry> but now it can't import 'attrs'
[20:08] <sergiusens> barry define recently
[20:08] <barry> sergiusens: as of oct 6
[20:09] <sergiusens> barry the deb, right? Then the answer is no https://launchpad.net/ubuntu/+source/snapcraft
[20:09] <sergiusens> unless you updated much after that
[20:10] <barry> sergiusens: interesting.  i'm fairly sure i would have picked that one up
[20:12] <sergiusens> barry we run an extra `pip wheel` since then and do an explicit `pip download`
[20:14] <sergiusens> barry for which I wanted to follow up with you on some other topic; seems there is a change in direction on what `install_data` should do in setup.py and that the whole thing is moving into a declarative setup. Any insight on that? I want the default plugin to follow the future and if necessary come up with another plugin that would live in the past
[20:14] <barry> sergiusens: i see all the whls in parts/ubuntu-image/packages but not in stage/user/lib/python3/dist-packages.  do i need to explicitly stage things in stage-packages?
[20:14] <sergiusens> barry those should be in lib/pythonXX/site-packages
[20:15] <barry> sergiusens: there's not even a site-packages directory in stage/usr/lib/python3.5
[20:15] <sergiusens> barry oh, add lib to your filters
[20:15] <barry> (or a dist-packages)
[20:15] <barry> ah
[20:15] <barry> thanks, trying that
[20:16] <barry> sergiusens: do you mean setup.cfg?
[20:16] <sergiusens> barry this was part of the warning email I sent a month ago or so; $SNAP/lib is PYTHONUSERBASE
[20:16] <barry> sergiusens: i feel a sense of deja vu ;)
[20:17] <barry> sergiusens: thanks
[20:18] <sergiusens> barry np
[20:18] <sergiusens> barry this thread https://github.com/pypa/pip/issues/2874#issuecomment-109429489
[20:19] <barry> sergiusens: i have a short day today.  let me look at this in detail on monday
[20:19] <sergiusens> barry sure, no rush; it is future planning after all
[20:20] <barry> cool
[20:34] <mup> PR snapd#2149 opened: Finalize declaration based checks <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2149>
[21:13] <jdstrand> pedronis (cc niemeyer): fyi, https://github.com/snapcore/snapd/pull/2149. see the comments-- I updated the store
[21:13] <mup> PR snapd#2149: Finalize declaration based checks <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2149>
[21:13]  * jdstrand is heading out for a while
[22:18] <niemeyer> jdstrand: Sounds great, thank you!
[22:36] <mup> Bug #1633638 opened: Can no longer install snaps with multiline plugs <Snappy:New> <https://launchpad.net/bugs/1633638>
[22:39] <mup> PR snapd#2150 opened: tests: unflake ubuntu-core-reboot <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2150>
[22:40] <niemeyer> jdstrand, matiasb: this looks like a bug in the assertion text, or in the assertion parser:
[22:40] <niemeyer> https://bugs.launchpad.net/snappy/+bug/1633638
[22:40] <mup> Bug #1633638: Can no longer install snaps with multiline plugs <Snappy:New> <https://launchpad.net/bugs/1633638>
[23:24] <pedronis> niemeyer: doesn't make a lot of sense, the parsing should be the same on the server and client
[23:27] <pedronis> matiasb: did we ignore some error somewhere ? ^
[23:29] <pedronis> or it's roundtripping bug
[23:32] <pedronis> but no
[23:51] <niemeyer> jdstrand: Huston, we have a problem
[23:54] <niemeyer> jdstrand: We need to revert the new decls in the store.. I failed to anticipate the fact old snapd's can't parse maps in assertions.. we'll need to tune the infra early next week
[23:55] <niemeyer> Meanwhile, can you please take out the new slot/plug syntax, and keep it safe so we can readd next week?