[00:02] kyrofa: note that process-control can be used for setpriority until seccomp arg filtering policy is available [02:34] PR snapd#2105 opened: snapstate: only import defaults from gadget on install [02:47] for a cmake snap, is there any way I can specify which directory the source lives in within the repo I have set to 'source'? [02:48] oh nvm, found it 'source-subdir' :) [06:32] good morning [06:36] good morning dholbach [06:36] Good morning, dholbach ^_^ [06:37] salut didrocks, hey pbek [07:10] zyga: ping [07:45] good morning zyga [07:45] zyga, any updates on snap-confine 1.0.43 in xenial-proposed? is that happening? [07:53] pedronis, morning! found the issue why it wasn't connecting to staging. The env variable is SNAPPY_USE_STAGING_STORE (rather than USE_STAGING_STORE only, that we talked yesterday) [07:53] pedronis, it works that way, thanks a lot for your help yesterday! [08:09] ara: yes, I think I pinged late about that, sorry I recalled from memory and memory had dropped the prefix [08:13] PR snapd#2106 opened: tests: exclude all-snap arm systems for the snap-connect test === ant_ is now known as Guest48995 [08:39] ogra_, o/ [08:46] morphis__: hey, I'm working on some more fixes, I'll be pushing code at each airport I'm at today, I'll write an update in the evening before I depart on the final connection [08:46] zyga: awesome! thanks a lot! [08:46] ara: I don't know, if you can please work with jdstrand to get this into yakkety and sru https://github.com/snapcore/snap-confine/releases/tag/1.0.43 [08:46] ara: no packaging changes required [08:47] morphis__: as a precaution I added support for offline testing so I'm good on the (long) journey ;) [08:58] zyga: ok [09:18] silly core-m going to sleep in funky ways [09:18] ogra_, i got the dragonboard working wiht the nexdock :-) [09:19] ogra_, do i get a putty medal [09:43] PR snapcraft#857 opened: Document the grade option [09:44] Chipaca, heh [09:50] PR snapd#2103 closed: store: send correct JSON type of string for expected payment amount [09:57] PR snapd#2107 opened: many: add payment-declined error kind [10:18] mwhudson: if you or cyphermox could merge https://launchpadlibrarian.net/288530592/subiquity_0.0.19~xenial_0.0.19~xenial+mvo1.diff.gz that would be great [10:31] PR snapcraft#855 closed: tools: script to talk to the staging servers [10:40] dholbach hey hey; are you a bash completion master? I wish you are and can look into allowing file completion, it drives me nuts :-P [11:00] sergiusens, I'm not :-/ [11:01] sergiusens, but I can see if I can find something [11:11] dholbach heh, cwayne did the original contrib, we should pester him ;-) [11:12] sergiusens: uh oh what'd I do [11:15] cwayne bash completion :-) [11:15] you are up early ;-) [11:17] sergiusens: :) [11:17] i can take a look at expanding it, sure [11:18] what specifically are you lookin for? [11:19] cwayne we have a bug report from dholbach LP: #1630922 [11:19] Bug #1630922: Bash completion for "push" is incomplete [11:20] cwayne but basically anything that takes a file as an argument has me banging the tab key to no avail :-) [11:20] get a new tab key :P [11:21] ogra_: where can i download pi2-kernel_15.snap? i need the physical file to change some of its content (and regenerate an image) [11:22] ppisati, https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel [11:22] ogra_: ta [11:22] (click on "Successfully built") === hikiko is now known as hikiko|ln === hikiko|ln is now known as hikiko [12:12] PR # closed: snapd#2033, snapd#2058, snapd#2065, snapd#2072, snapd#2083, snapd#2087, snapd#2091, snapd#2096, snapd#2104, snapd#2105, snapd#2106, snapd#2107 [12:13] ara (cc zyga): do you want me to upload 1.0.43 to yakkety and xenial? [12:14] jdstrand, please, apparently .42 (in xenial-proposed) had a regression, so it is never going to be go to -updates [12:15] I see [12:16] ara: ok, I'll do that now and ping you [12:16] jdstrand, thanks! [12:20] Bug #1630976 opened: Incomplete home directory mapping [12:25] PR # opened: snapd#2033, snapd#2058, snapd#2065, snapd#2072, snapd#2083, snapd#2087, snapd#2091, snapd#2096, snapd#2104, snapd#2105, snapd#2106, snapd#2107 [12:29] ara: do you have the bug for the regression? [12:29] jdstrand, let me check, zyga mentioned yesterday on this same channel, let me check the backlog [12:33] jdstrand, https://bugs.launchpad.net/snap-confine/+bug/1630479 [12:33] Bug #1630479: PATH is not set after namespace is initialized

[12:34] zyga: can you make sure this is in 1.0.44: http://paste.ubuntu.com/23284317/ [12:34] ara: thanks! [12:35] zyga: also http://paste.ubuntu.com/23284321/ [12:37] jdstrand: sure [12:37] jdstrand: re, .43, yes, let's please get it into yakkety and xenial [12:41] jdstrand: will mount options=(ro rbind) /snap/{,ubuntu-}core/*/var/lib/** -> /var/lib/**, [12:42] jdstrand: will that cover /snap/core/current//var/lib/logrotate -> /var/lib/logrotate [12:42] jdstrand: or do I need some /**/ to cover directories? [12:46] What do I do here? https://pastebin.canonical.com/167232/ . It seems the python3 pulled in by the python plugin does not patch the python3 pulled in as a stage package in another part (that embeds a Python interpreter) [12:49] zyga: /snap/{,ubuntu-}core/*/var/lib/** would cover it. is ../** needed though? can you use /snap/{,ubuntu-}core/*/var/lib/logrotate/ -> /var/lib/logrotate/ instead? [12:50] PR snapd#2108 opened: devicestate: merge overlord/boot into devicestate [12:51] well , we don't know which directories there are there [12:51] we're seeing a failure in autopkgtests [12:51] cannot bind mount /snap/core/current//var/lib/logrotate -> /var/lib/logrotate with flags 0x85007. errmsg: Permission denied [12:51] no apparmor denial log though, we'd have to reproduce it now [12:51] I was wondering if apparmor changed in any way [12:52] the mount happens with the following flags MS_RDONLY | MS_REC | MS_SLAVE | MS_NODEV | MS_NOSUID [12:52] but AFAIK apparmor doesn't model all of them [12:55] zyga: re don't know> this is an old conversation. is it truly dynamic now and we don't know or is it just to ease future maintenance? if the former, we need a glob rule, if the later, let's continue adding more specific rules [12:56] zyga: you probably need: /snap/{,ubuntu-}core/*/var/lib/*/ -> /var/lib/*/ [12:56] huh. The only difference is munged shebang lines. I think I saw the python plugin messing around with shebangs [12:56] jdstrand: ack, I'll try to reproduce this and fix it when I'm in korea with better network [12:57] zyga: ie, the trailing '/' (and you don't need **/, just */ iirc the mirrored /var/lib code [12:57] ) [12:58] thanks! [12:58] this doesn't explain why adt fails but at least I have more knowledge [13:00] zyga: looking at that source mount (/snap/{,ubuntu-}core/*/var/lib/*/), we should be able to enumerate those since we know what is in the core snap. however, would we list everything in /var/lib or would we skip stuff? iirc, there are things we would skip, so a more exact match would be best (though I'd be ok with a glob rule with deny rules for what we wouldn't mount from /snap/{,ubuntu-}core/*/var/lib/*/) [13:00] jdstrand: jdstrand overdue gift from the plane [13:01] geeez net is slow from the phone [13:01] jdstrand: https://github.com/snapcore/snap-confine/pull/166 [13:01] PR snap-confine#166: Allow running qemu spread tests offline [13:01] woo! [13:01] Ill merge things on the plane [13:01] just adding remotes [13:02] Bug #1616605 changed: Cannot open files from NFS drive mounted in /media [13:03] jdstrand: hey! I see that to be able to run the "ping" command, we need one of those interfaces: firewall-control, network-control, network-observe [13:03] jdstrand: so, it means, there is no interface that autoconnects to enable pinging a remote server? [13:03] (I guess there are security implications…) [13:08] PR snapd#2033 closed: many: move firstboot code into the snapd daemon [13:08] didrocks: that's correct. it has to do with the fact that it is setuid and what that would mean with 'safe' policy [13:11] didrocks: however, there are several things here to consider: 1) snaps can test for connectivity using other means that don't need setuid (eg, perform a GET / on http), 2) recent kernels allow ping to be used without setuid, so the snap could ship that ping, 3) snap declarations will allow autoconnecting interfaces after the snap is approved, d) I *might* be able to make something work now that the seccomp arg filtering feature landed [13:12] jdstrand: actually, I'm just trying to ship some toolbox for health check that consul would use. ping utility is one of them. Is there any ping tool that you know for 2)? [13:13] jdstrand: also, I just tried to network-observe + connect the socket, I'm still getting ping: icmp open socket: Operation not permitted [13:13] (but nothing in scanlogs now) [13:13] (and nothing in syslogs) [13:13] didrocks: you mean s/socket/interface/? [13:14] interface, yeah, sorry [13:14] :network-observe consul [13:16] tyhicks: what is the status of setuid-less ping? [13:16] didrocks: note, tyhicks will be online in a bit [13:16] jdstrand: that would be great as a simple utility for use with health checks ;) [13:17] however, in the fact that there is no log in syslog and that error ^ I'm puzzled [13:17] didrocks: there was this: http://tinyurl.com/h6obc5g [13:18] didrocks: what ping is it using? the system ping or its own ping? if its own ping, does it work with sudo? [13:19] jdstrand: it's coming from a stage-package I took (can use another one if needed): iputils-ping [13:19] let me try with sudo [13:19] yep, works with sudo [13:19] didrocks: the problem with that ping is it requires kernel support. I forget the details of the earliest kernels, so an old 3.10 kernel (for example) might not work with this ping [13:19] $ uname -a [13:19] Linux n1 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [13:19] not that old :) [13:19] didrocks: right, so with stage-packages, the setuid bits are (correctly) stripped [13:20] ah, that's the reason why… [13:20] ok, making sense then [13:20] didrocks: but the ping in stage-packages doesn't have the patch for setuid-lessness [13:20] so, I guess the setuid-less ping is the only way [13:20] didrocks: well, use /bin/ping from the core snap instead of stage-packages [13:20] didrocks: that will work with network-observe [13:21] ok, let me give it try! [13:21] jdstrand: indeed, works perfectly with that + network-observe [13:22] it might be fun to have a part or something with the patched ping. iirc, the patch to ping went upstream and it was accepted. that patch just didn't make it into Debian/Ubuntu yet. tyhicks would need to confirm [13:22] thanks a lot, that would do it for now :) [13:22] oh ok [13:22] yeah, I'm creating some sort of general "utility" part/content-interface [13:22] to be used as health check toolbox [13:23] didrocks: compiling upstream ping from source might be the way to go then if connecting network-observe is onerous [13:25] jdstrand: yeah, sounds like it. do you have the link for the official upstream source (I find some github and such…), and debian/copyright doesn't point to a working ftp [13:25] didrocks: fyi, I added exploring 'd' (hehe, meant '4' in my list) to the card on implementing seccomp arg filtering policy. that card is down a ways cause of various critical cards [13:26] didrocks: I'll defer to tyhicks there. iirc, he submitted the patch [13:26] oki :) [13:26] jdstrand: yeah, no worry, thanks for helping, at least, I have options and I am unblocked :) [13:27] cool [13:41] ogra: I am trying to port minicom from 15.04 to UC16 and need to access tty devices, isn't there a serial-port plug? [13:42] mbenz, i think there is ....https://github.com/snapcore/snapd/blob/master/docs/interfaces.md look for serial [13:42] needs the user to manually connect though [13:43] ogra_: our discussion was that it's not listed via snap interfaces though, even being in the code [13:43] is that ubuntu-core doesn't provide the slot? [13:44] didrocks, hmm, thats a zyga question i fear [13:44] ogra: I will look at doc but some background on what I have tried. I added the plug in yaml and install but see '-' listed as slot and trying to connect gives a failure unlike using modem-manager which works but doesn't have access to /dev/ttySx [13:45] righ, smells like something is missing here [13:45] as didrocks said [13:46] should I work with zyga or log a bug? [13:47] well, perhaps it is known, i guess zyga had enough pings from us to notice the discussion once he checks IRC again ;) [13:47] wait for him ... then log a bug if he thinks you should [13:47] ok [13:48] for now I will just run in devmode and debug lock file and config file locations [14:00] tyhicks: as it happens, I am preparing a snap-confine upload and so I can remove the owner check from '@{PROC}/*/mountinfo r,' if that would help things. please advise [14:00] tyhicks: oh, I see you said to drop it in comment #4 [14:06] jdstrand: thanks! could you also add the rule in comment #5? [14:06] jdstrand: @{PROC}/[0-9]*/attr/current w, [14:20] jdstrand, didrocks: re setuid-less ping, the patches landed in upstream iputils but we don't yet have a new enough iputils in any of our releases [14:20] jdstrand, didrocks: it isn't as simple as that, though [14:21] jdstrand, didrocks: setuid-less ping doesn't have full functionality so there's decisions to be made about whether that loss of functionality is ok, if we need to have multiple packages (one for setuid, one for no setuid), etc. [14:25] jdstrand, didrocks: also, you can't ship your own setuid-less ping in a snap until Ubuntu opens up the net.ipv4.ping_group_range sysctl to a range that includes our normal user's gid [14:28] tyhicks: hmm, so a snap that build iputils from upstream still wouldn't work cause of the sysctl, which we could allow setting, but probably in network-control, a non-auto-connected interface [14:29] tyhicks: yes, already done. about to upload this: http://paste.ubuntu.com/23284740/ [14:29] tyhicks: fyi, https://github.com/snapcore/snap-confine/pull/167 [14:29] PR snap-confine#167: drop 'owner' check on mountinfo and allow write to @{PROC}/[0-9]*/attr/current [14:29] tyhicks: hum, ok, so I'm going with the ubuntu-core ping version now, with the correct interface [14:30] tyhicks: if you +1 that PR, I'll commit it [14:31] jdstrand: I've +1'ed [14:31] didrocks: yeah, that's your best option right now [14:32] jdstrand: we wouldn't want to allow a snap to set the sysctl, we'd want to set it ourselves [14:32] jdstrand: the least risky option would be set it at the distro level but continue to ship the setuid ping [14:33] jdstrand: that would allow snaps to ship their own setuid-less ping [14:33] tyhicks: technically, it could be at the core snap level [14:34] jdstrand: yeah, it could be [14:39] ara (cc zyga): uploaded snap-confine 1.0.43-0ubuntu1 to yakkety just now. aiui, autopkgtests have a long queue due to glibc upload. I'll work on xenial now [14:39] jdstrand, thanks! [14:44] PR snapd#2105 closed: snapstate: only import defaults from gadget on install [15:09] PR snapd#2109 opened: tests: update tests now that we do not have snapd.boot-ok anymore [15:09] hum, the consul snap is already taken, I think it's you elopio? [15:10] elopio: I have a working version of it (which does a little bit than --help or local dev agent) and want to upload it to the store, do you mind add me to collaborators if it's really you? :) [15:13] ara (cc zyga and tyhicks): ok, snap-confine 1.0.43 with https://github.com/snapcore/snap-confine/pull/167 uploaded to both yakkety and xenial-proposed. yakkety is building, xenial-proposed needs a member of the sru team and the bugs to be done [15:13] PR snap-confine#167: drop 'owner' check on mountinfo and allow write to @{PROC}/[0-9]*/attr/current [15:14] ara: at this point, I think my part for helping zyga is done? [15:14] jdstrand, thanks! [15:16] jdstrand: thank you! [15:18] np [15:22] PR snapd#2106 closed: tests: enable tests related to the home interface in all-snaps [16:27] PR snapd#2109 closed: tests: update tests now that we do not have snapd.boot-ok anymore [16:35] PR snapd#2110 opened: overlord/devicestate: don't bail out on the first error in DeviceManager.Ensure, subcalls are fairly orthogonal [16:42] roadmr: hey. ok, I'm going to start work on the review tools for snap declarations now [16:42] roadmr: and wanted to sync up. is now a good time? [16:43] PR snapcraft#854 closed: Decouple state handling from plugin options [17:15] jdstrand: https://launchpad.net/~command-not-found-developers/+member [17:15] er [17:15] bad link [17:15] I meant this: http://paste.ubuntu.com/23285366/ [17:17] zyga: you mean that is what you wanted uploaded instead of what I did? [17:19] jdstrand: no, that's just a patch we should probably add to .43's debian packaging [17:19] jdstrand: I found this on the plane [17:19] jdstrand: not sure why it broke, it definitely used to work [17:20] jdstrand: maybe a fault in how tests were set up [17:20] this is strictly packaging, the upstream release is OK [17:21] jdstrand: I merged some of your branches on the plane [17:23] zyga: fyi, 1.0.42-0ubuntu3 on yakkety has 755 [17:24] zyga: can you file a bug? I'd like to see the yakkety version migrate. I need to focus on snap declarations now, but can circle back to this maybe later today/tomorrow [17:26] jdstrand: sure, thanks! [17:26] jdstrand: I will, filing bugs on the plane is harder than sbuilding fixes :) [17:28] jdstrand: hello! Sorry, I was out but i'm back. Sure, let's chat [17:28] roadmr: o/ [17:28] hello zyga [17:28] (just saying hi :) [17:28] zyga: hello :) how are you doing? [17:29] roadmr: good, sprinting, patching, hacking :) [17:29] you hacker :) [17:30] zyga: awesome work btw, congrats [17:30] jdstrand: (or if you're e.g. out lunching or something, we could sync later today) [17:31] roadmr: hey, so my plan is to embed the snapd base declaration for now. then take the snap declaration as a command line argument. on initial upload, the store would provide an empty snap declaration. after that, whatever is saved via the store ui. is this what you had in mind? [17:31] roadmr: no, I'm here [17:31] jdstrand: ohai :) [17:32] jdstrand: no, our code would pass the meat of the plugs and slots, it's how we've coded it right now [17:32] roadmr: sorry, that is what I meant [17:32] jdstrand: we had a call earlier today where the issue of "how is it serialized?" came up, which applies to the tools as well [17:32] roadmr: can you paste me an example of what it will feed to the tools? [17:33] jdstrand: so on initial upload or if the snap-declaration has no plugs/slots, we call crt without the --plugs or --slots arguments [17:33] that works fine [17:34] roadmr: oh, you are splitting up --slots and --plugs? [17:34] jdstrand: yes, that's why I meant by the "meat" [17:34] jdstrand: because if not, I'd have to pass you a blob containing both plugs and slots which you'd have to parse... [17:35] jdstrand: and I'd have to massage it too, since I'd have to aggregate both headers somehow [17:35] roadmr: I was thinking you'd do --decl=... and that would just have slots: and plugs: [17:35] jdstrand: we could modify our code to give you the snap-declaration document in its entirety [17:35] well I haven't gotten very far, so I can adjust [17:36] roadmr: what is in --plugs and --slots? [17:36] jdstrand: yea... ok so what we'd pass is a json representation of slots/plugs, as edited my the reviewer [17:36] json? === fginther` is now known as fginther [17:36] jdstrand: yep. I guess it could be a collapsed-in-one-line json thing [17:37] roadmr: so the store has 'Edit declaration assertion' [17:37] roadmr: and two text areas [17:38] jdstrand: so the workflow is: we call crt with either --plugs/slots or not. If c-r-t says there's trouble with the payload (say, this payload would cause the snap to not install), the reviewer is expected to craft a suitable payload in those fields [17:38] roadmr: what goes in there? the yaml-esque payload and you convert that to json for the tools? [17:38] jdstrand: then redo the crt review (there's a button for that) and once it passes, it approves the snap [17:38] jdstrand: no, the json payload goes there. We'll never edit the yamlesque version by hand [17:39] the json payload [17:39] hmm [17:39] jdstrand: what happens is, once the tools are happy with the json payload, we update the snap-declaration, passing a dict built from that json (essentially plugs=json.loads(the_json_payload)) [17:39] jdstrand: then the snap-declaration will have the yamlesque thing. But the store keeps a copy of the original JSON for human editing [17:40] jdstrand: now, on subsequent upload, I pass the tools the json; if they're happy, then automated review just passes and I don't update the assertion at all (since it's supposed to already have that payload) [17:40] roadmr: I have some concerns that the reviewer needs to enter json instead of yaml, since the declaration spec uses yaml [17:41] jdstrand: hehe what I keep hearing about that is "it's not really yaml" :) [17:41] roadmr: plugs and slots are just dicts [17:42] jdstrand: that leaves us in a weird situation because we could help the reviewer by at least superficially validating json or pure-yaml syntax, but if it's some yamloid thing, the thought of crafting a custom validator sounds painful [17:42] jdstrand: yes; one characteristic of the json is that it has to parse to a dict. For example, '"string yay"' is valid json but won't result in a dict [17:43] roadmr: json doesn't *have to* parse to a dict, most parses can just return any valid json type [17:43] zyga: yes, I meant for this particular case, because SAS does expect a dictionary/map [17:43] roadmr: ok, let's backburner this discussion since it is only something the reviewer would see and for the moment, that would be me [17:44] jdstrand: sure [17:44] roadmr: alright, so the tools gets no --plugs or --slots on initial upload. after that the store will give a json file for --plugs and/or --slots? [17:45] roadmr: then the tools do its thing. if the tools are not happy, what do you want it to do, exit with error? (I can use a particular error code if that helps) [17:46] jdstrand: so we could give you an inline string --plugs='{"foo": "bar", ...}' *or* we could point to a file containing the separated payload --plugs=/tmp/plugs-for-snap-XXXXX.json) [17:46] jdstrand: yes, that sounds good, we can check for that error code and say "needs to edit the payload". [17:46] roadmr: I think a file would be best. that string might get long and hit an argv limit [17:47] roadmr: what should we do if there are errors/warnings in addition to a payload error? [17:47] jdstrand: I think the tools output a jsony thingy with the results too, right? if you could have a specific key there with a meaningful message (e.g. plugs don't allow use of interface FOO which the snap wants to use") that'd make reviewers' (you!) jobs much easier [17:48] jdstrand: ok, let's aim for passing you a file [17:49] roadmr: the tools can do that helpful stuff no problem (we do that already). as for the json thingy, are you already passing --json to the tools? [17:50] jdstrand: I think we are! let me check [17:50] jdstrand: yes, /path/to/click-review --json /path/to/package.snap [17:51] jdstrand: a new invocation would be /path/to/click-review --json --plugs /path/to/plugs.json --slots=/path/to/slots.json /path/to/package.snap [17:52] roadmr: if so, this is easy. I will add this code to a new file (sr_declaration.py) which means it'll automatically get put into an area you can process (eg, decl-snap-v2) [17:52] ok good [17:52] awesome :) [17:52] roadmr: these are the return codes currently: [17:52] RETURN CODES [17:52] 0 found no errors or warnings [17:52] 1 checks not run due to fatal error [17:52] 2 found errors and/or warnings [17:52] 3 found warnings [17:52] PR snapd#2111 opened: snap: ignore /dev/loop addings from udev [17:53] roadmr: add '4 found snap declartion conflicts' [17:54] jdstrand: sounds good to me. It'd be for correctness only because I checked and we don't use the return code at all :( [17:54] jdstrand: we rely entirely on the json output [17:54] roadmr: the question then is, should I return 2 if have snap decl conflicts + errors/warnings? [17:54] jdstrand: yes, sounds like 2 encompasses "other errors *and* snap decl conflicts" fine [17:54] roadmr: ok, then I return 4 if just snap decl conflicts and 2 if other conflicts. we can revisit that [17:55] ok cool [17:55] totally, that makes sense [17:56] roadmr: what is the status of the store today? I imagine you are just waiting on me so you can uncomment the code to pass --slots and --plugs? [17:57] jdstrand: yes, but we also need to fix the "parse json and pass the dict to SAS" (so: please DON'T edit those plugs/slots fields :) [17:57] np [17:58] jdstrand: the code to pass --slots/--plugs is behind a toggle so we can flip it quickly if we break something [17:58] jdstrand: but right now it won't work really because it passes inline strings [17:59] roadmr: ok, so, is this ok as part of the json output: http://paste.ubuntu.com/23285610/ [17:59] jdstrand: perfect! [17:59] roadmr: ok, great [17:59] I think that is everything [18:00] at least on my end [18:00] do you have questions or is there anything else I need to know about? [18:00] jdstrand: I think this is clear, just a few tweaks to what we were envisioning [18:01] ok, I'll get to work on this. I will ask for a review when ready' [18:03] jdstrand: thanks! I'll summarize in the design doc we have and get cracking [18:03] \o/ [18:04] roadmr: great :) [18:04] this is awesome, almost as awesome as when sas started exploding due to me having created a bad payload \o/ [18:10] haha :) [18:15] PR snapd#2112 opened: systemd: Correct the mount arguments when mounting with squashfuse === Pharaoh_Atem is now known as Conan_Kudo === Conan_Kudo is now known as Pharaoh_Atem [18:19] Hi! Where can I find documentation on how to consume the gpio interface ? [18:20] roadmr: in the json output, lets use snap.v2_declaration instead of snap.v2_decl [18:20] "snap.v2_declaration": { [18:20] "error": {}, [18:20] "info": {}, [18:20] "warn": {} [18:20] } [18:22] jdstrand: sounds good, noted [18:28] PR snapcraft#844 closed: Add `snapcraft history` [18:29] maxiberta mind fixing snapcraft#845 [18:29] PR snapcraft#845: Add `snapcraft status` [18:29] ? [18:29] zyga: thanks for the review! do you know if there's going to be another snapd release and upload before yakkety is released? [18:41] Hey, I tried building a snap of mpv using the examples from snappy-playpen on GitHub. [18:42] I successfully built the snap but mpv can't access any files when I try to play something using it. [18:42] I tried also playing a YouTube url. ffmpeg showed some error. [18:42] What may be the reason? [18:47] niemeyer: hi - I'm looking for some guidance on getting https://github.com/snapcore/snapd/pull/2112 into yakkety [18:47] PR snapd#2112: systemd: Correct the mount arguments when mounting with squashfuse [18:47] niemeyer: everything is in place, except for that small change, for snaps to work in unprivileged lxd containers [18:48] niemeyer: I don't know if there's another snapd upload planned before yakkety's release, if I should apply that patch to what's in yakkety-proposed and make a new upload, or if you're fine with including that fix in an SRU [18:50] PR snapd#2110 closed: overlord/devicestate: don't bail out on the first error in DeviceManager.Ensure, subcalls are fairly orthogonal [18:50] PR snapd#2111 closed: snap: ignore /dev/loop addings from udev