| menn0 | I have a question about developer namespaces. can anyone help? | 01:52 |
|---|---|---|
| ahoneybun | sergiusens: could you share your snapcraft.yaml or update the telegram one? | 01:54 |
| === chihchun_afk is now known as chihchun | ||
| dholbach | hey hey | 06:37 |
| didrocks | good morning dholbach | 06:51 |
| dholbach | salut didrocks | 06:54 |
| zyga | good morning everyone :) | 07:35 |
| zyga | I officially give up on reading backlog for the last three weeks | 07:35 |
| dholbach | zyga, break with the past! move on to new things! ;-) | 07:41 |
| zyga | dholbach: speaking of which, https://bodhi.fedoraproject.org/updates/FEDORA-2016-0137e29c1e | 07:47 |
| zyga | https://bodhi.fedoraproject.org/updates/FEDORA-2016-0233975de8 | 07:48 |
| dholbach | very nice :) | 07:48 |
| zyga | Son_Goku: hey, I cannot send bodhi request for f25 for golang-github-mvo5-goconfigparser -- I keep getting http://pastebin.ubuntu.com/22671527/ | 07:59 |
| morphis | ogra_: ping | 08:00 |
| morphis | zyga: welcome back! | 08:00 |
| zyga | morphis: hey | 08:00 |
| zyga | morphis: I saw you made a branch for udev fix, I also made one two weeks ago | 08:01 |
| zyga | morphis: did your version land? | 08:01 |
| morphis | zyga: hope you enjoiyed your time off | 08:01 |
| morphis | zyga: not yet, waiting for next review round | 08:01 |
| zyga | morphis: yes, I really needed that :-) | 08:01 |
| zyga | morphis: ok, great, I'll review it today if I can; I have a huge backlog of things to do | 08:02 |
| morphis | zyga: thanks, niemeyer is looking at it too | 08:03 |
| morphis | zyga: one other thing, you remember that we talked about loading kernel modules with interfaces once connected? | 08:03 |
| zyga | morphis: yes, I do, some people asked about that in Leiden AFAIR | 08:04 |
| morphis | zyga: yeah there is a kernel-load PR now, but this is more for the ppp interface where we don't want to give the plug side the ability to load modules but do that from snapd directly | 08:05 |
| === e is now known as especiallee | ||
| morphis | zyga: wanted to check with you how we implement that the right way | 08:07 |
| zyga | morphis: I see, I think we need both types, free-form loading from within the app process and snapd-directed loading | 08:07 |
| morphis | zyga: yes | 08:07 |
| zyga | morphis: I'll make sure to review that one | 08:07 |
| zyga | ara: hey, long time no see :) | 08:07 |
| ara | zyga, hey, how were the holidays? | 08:07 |
| zyga | ara: busy :) I'm looking forward to having some peace and quiet work time :) | 08:08 |
| ara | zyga, hehe | 08:08 |
| morphis | ara: morning! | 08:09 |
| ara | hey morphis :) | 08:09 |
| morphis | zyga: you have an idea in mind how to implemnt the snapd-directed loading? | 08:09 |
| morphis | zyga: we could add another security system or extend the interface API to return something like PermanentSlotKernelModules | 08:10 |
| zyga | morphis: yes, I talked to jdstrand about it; there are two parts; one that drops a line/file in /etc/modules-load.d for load on boot and another one that just modprobes the thing | 08:10 |
| morphis | yeah | 08:10 |
| zyga | morphis: I think using another security system is easier | 08:10 |
| zyga | morphis: the only thing we were worried about is options | 08:10 |
| zyga | morphis: but that all | 08:10 |
| morphis | yeah options might be tricky, but as we're doing specific modules here we may have to encode such a thing as attribute | 08:11 |
| morphis | not free-form but something we translate | 08:11 |
| zyga | morphis: jdstrand was worried that some options might be too powerful for an unrestricted interface | 08:13 |
| zyga | morphis: anyway, I think we can solve it on a case-by-case basis | 08:13 |
| morphis | yes | 08:13 |
| morphis | zyga: for now we have some well-defined use cases | 08:13 |
| morphis | ogra_: ping | 08:13 |
| === especiallee is now known as e | ||
| ysionneau | hi! | 08:28 |
| didrocks | hey ysionneau | 08:28 |
| ysionneau | about my friday question, someone said "SNAP_COMMON could be your solution" but I don't get how it can help me to make 2 different *snaps* communicate through unix socket | 08:34 |
| ysionneau | I thought I had a solution by having autopilot (which is devmode snap) create the unix socket in the SNAP_DATA of facedetect (which is a contained snap) | 08:35 |
| ysionneau | but since autopilot is already running when facedetect is not yet installed, it does not work | 08:35 |
| ysionneau | the PATH does not exist yet and the socket creation fails | 08:35 |
| didrocks | ysionneau: lool mentioned SNAP_COMMON as, contrary to SNAP_DATA, it's a fixed path for whatever version of facedetect is running | 08:45 |
| didrocks | but yeah, what you told is an issue if autopilot is already running before facedetect is installed | 08:45 |
| zyga | ysionneau: you need an interface for that | 08:47 |
| zyga | ysionneau: you can only communicate over tcp/ip without an interface | 08:48 |
| ysionneau | didrocks: ah ok goot to know, anyway I was using /current/ | 08:50 |
| ysionneau | zyga: :( | 08:50 |
| ysionneau | I guess I'll end up recompiling snapd to add my interface and stuff it into ubuntu-core | 08:50 |
| ysionneau | I however have no idea on how to recompile snapd =) | 08:51 |
| zyga | ysionneau: look at two links: https://github.com/zyga/devtools/ and at snapd docs (how to build) | 08:53 |
| zyga | https://github.com/snapcore/snapd/blob/master/README.md | 08:53 |
| ysionneau | thanks! | 08:53 |
| zyga | ysionneau: just a side note: ubuntu-image sccript in devtools is broken | 08:54 |
| ysionneau | ok thanks | 08:57 |
| ysionneau | I'm not using ubuntu-image from internet anymore | 08:57 |
| ysionneau | I had too many issues with updates | 08:57 |
| ysionneau | I commited one version that works in my repository | 08:58 |
| zyga | ysionneau: that won't work with recent snapd | 08:59 |
| zyga | ysionneau: on the upside ubu tu image official upstream is close to making first releases | 08:59 |
| ysionneau | zyga: "ubu tu image", that's the real name ? :D | 09:13 |
| ysionneau | 10:59 < zyga> ysionneau: that won't work with recent snapd < hmmm strange, I'm using an old ubuntu-image and a recent ubuntu-core :o | 09:14 |
| ysionneau | and it seems to work :o | 09:14 |
| ogra_ | morphis, hey | 09:15 |
| zyga | ysionneau: it might break at any time | 09:16 |
| morphis | ogra_: just a quick check, your all-snap pi3 image doesn't support the onboard wifi yet, right? | 09:19 |
| ogra_ | yeah, missing the firmware | 09:19 |
| ogra_ | i'll get to that once i have https://code.launchpad.net/~ogra/+snap/kernel-test-snap fully working (EOW i think) | 09:20 |
| ysionneau | zyga: when it will break, just updating my ubuntu-image will fix the issue? | 09:28 |
| zyga | ysionneau: you may need to remake the image | 09:29 |
| morphis | ogra_: any chance I can get the firmware manually in? | 09:30 |
| ysionneau | zyga: no problem, I remake the image each time I flash | 09:30 |
| ogra_ | morphis, you can unsquashfs the kernel snap, add the filesw and run snapcraft snap squashfs-root | 09:30 |
| ogra_ | then use the local kernel in u-d-f | 09:31 |
| morphis | yeah good idea | 09:31 |
| ysionneau | is this the official webdm repository (up to date?) ? : https://code.launchpad.net/~snappy-dev/snappy-hub/webdm | 09:31 |
| morphis | ysionneau: https://github.com/snapcore/snapweb is getting the new one | 09:31 |
| ysionneau | morphis: is this the current "webdm" package ? The one I can fetch by doing "sudo snap install webdm" ? | 09:32 |
| morphis | ysionneau: not sure, all I know is that webdm gets replaced by snap-web | 09:33 |
| zyga | ysionneau: I think the snap should be renamed to snapweb as well | 09:33 |
| zyga | but yes, that's the old webdm | 09:33 |
| ysionneau | hmm there is no "snapweb" snap in the store | 09:34 |
| ysionneau | but there is "webdm" | 09:34 |
| ysionneau | so far webdm works for me so I would like to use it, is it https://code.launchpad.net/~snappy-dev/snappy-hub/webdm ? | 09:35 |
| zyga | ysionneau: unlikely, try github.com/snapcore/snapweb perhaps | 09:35 |
| ysionneau | thanks | 09:36 |
| ysionneau | zyga: AH ok, it's the correct repository but webdm package got renamed to snapweb | 09:38 |
| ysionneau | https://github.com/snapcore/snapweb/commit/978fc76a95199aecb1ae735fe3c4459068eb9318 | 09:38 |
| ysionneau | right? | 09:38 |
| zyga | yes | 09:39 |
| * ysionneau thinking about what's easier between adding an interface to snapd, recompile, repack ubuntu-core. or modify snapweb to always install everything in devmode, recompile and repackage snapweb | 09:40 | |
| ysionneau | one is the "clean way", the other might be easier | 09:41 |
| zyga | ysionneau: try my devtools | 09:41 |
| zyga | ysionneau: you can just compile and run fresh version directly | 09:41 |
| zyga | ysionneau: no rebuilding of any snaps required | 09:41 |
| zyga | ysionneau: see the docs there | 09:41 |
| zyga | ysionneau: that's *the* purpose of devtools, rapid interface development | 09:42 |
| ysionneau | zyga: I kind of get used to that :p | 09:43 |
| ysionneau | ah sorry was replying to something else | 09:43 |
| ysionneau | so, I recompile snapd and I push it via refresh-bits ? | 09:44 |
| zyga | ysionneau: refresh bits does all, just see what it does | 09:44 |
| ysionneau | k! | 09:44 |
| zyga | ysionneau: refresh-bits setup snap snapd run-snapd restore | 09:45 |
| zyga | ysionneau: with --host if needed | 09:45 |
| zyga | ysionneau: read the source, it's very easy to follow | 09:45 |
| zyga | ysionneau: note that run-snapd blocks, ctrl-c it to continue | 09:45 |
| ogra_ | cjwatson, bug 1610916 for you ... | 09:46 |
| mup | Bug #1610916: s390x snap builds on launchpad fail with no build log <launchpad-buildd:New> <https://launchpad.net/bugs/1610916> | 09:46 |
| cjwatson | Thanks. | 09:48 |
| pmp | zyga: on debian-testing there is no systemd-activate - needed by refresh-bits | 10:00 |
| lool | didrocks: heya | 10:05 |
| lool | ysionneau: and hi | 10:05 |
| didrocks | hey lool | 10:06 |
| zyga | pmp: I heard, any chance on how to trigger socket activation now? | 10:08 |
| zyga | s/chance/advice/ | 10:08 |
| pmp | zyga: I don't know much about systemd... sry | 10:13 |
| pmp | zyga: Plus I'm cross-compiling (well I try to) | 10:14 |
| zyga | pmp, no worries, thanks for letting me know | 10:15 |
| kaisoz | Hi there! | 10:18 |
| === hikiko is now known as hikiko|ln | ||
| cjwatson | ogra_: Can you try an s390x build again? | 10:58 |
| cjwatson | ogra_: Firewall should be fixed, though there's still the exception-handling bug | 10:59 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | cjwatson, triggered | 10:59 |
| ogra_ | https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/2574 | 10:59 |
| ogra_ | that looks better | 11:00 |
| cjwatson | You haven't hit the previous failure yet | 11:00 |
| ogra_ | ah, i thought the build didnt even start the last time | 11:00 |
| cjwatson | Oh, maybe | 11:00 |
| cjwatson | No, I think it started, but it crashed in such a way as to leave no log | 11:01 |
| cjwatson | So you wouldn't know unless you happened to be watching it | 11:01 |
| ogra_ | ah, k | 11:01 |
| cpaelzer | just to check - anybody else working on a waf plugin (https://github.com/waf-project/waf) ? | 11:03 |
| cpaelzer | I need that to try ntpsec, but wanted to avoid too much collisisons so I thought I poll for others that might work on it | 11:03 |
| ogra_ | cjwatson, ... so while this runs, i have another issue ... when i select Proposed from the LP UI and have picked a PPA as the archive, proposed isnt actually used unless the PPA is also enabled for proposed ... i.e. i can not get snapcraft from proposed for testing for example even though i pick it ... the UI option should set proposed regardless of the picked archive imho | 11:04 |
| ogra_ | (in the case of my ubuntu-core builds, i can not actually get livecd-rootfs from proposed since the outer sources.list doesnt contain it unless the image PPA defaults to it too) | 11:05 |
| ogra_ | cjwatson, build is done, i got a buildlog link \o/ | 11:11 |
| ogra_ | hmm, but i get a "404 client error" from the store ... i wonder why | 11:12 |
| ogra_ | clicking the upload button manually uploads it fine ... strange | 11:14 |
| ogra_ | geez ... | 11:20 |
| ogra_ | Launchpad uploaded this snap package to the store, but the store failed to | 11:20 |
| ogra_ | scan it: | 11:20 |
| ogra_ | A file with this exact same content has already been uploaded | 11:20 |
| ogra_ | why did it tell me about the 404 error then ... :P | 11:20 |
| cjwatson | ogra_: proposed> please file a bug; I think I probably agree but doing anything about that will be a bit complicated | 11:20 |
| ogra_ | cjwatson, will do | 11:20 |
| cjwatson | [2016-08-08 11:11:45,875: DEBUG/Worker-1] "POST /dev/api/snap-push/ HTTP/1.1" 202 None | 11:22 |
| ogra_ | hmm, the above looks like a race in the store ... LP obviously uploaded it fine but the scanner tried to scan it to early or some such | 11:22 |
| cjwatson | [2016-08-08 11:11:45,988: DEBUG/Worker-1] "GET /dev/api/snaps/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7/builds/5ee23940-f5f8-49bb-9ab1-ec7b0bf4315d/status HTTP/1.1" 404 None | 11:22 |
| cjwatson | I think this must be an SCA bug. It should not be possible for it to return a status URL from snap-push that can't be immediately fetched. | 11:22 |
| ogra_ | yeah | 11:22 |
| cjwatson | I don't know about the "exact same content" thing. | 11:22 |
| ogra_ | cjwatson, well, that was mme manually clicking the "upload" button on LP ... my fault | 11:23 |
| ogra_ | i think i actually saw a bug fly by about the 404 error ... | 11:23 |
| cjwatson | Ah, right, because the 404 meant we thought it was retryable even though it actually wasn't. | 11:23 |
| * ogra_ digs his bugmail | 11:23 | |
| cjwatson | Unfortunate. | 11:23 |
| ogra_ | yeah | 11:23 |
| dz0ny | cpaelzer: https://github.com/ubuntu/snappy-playpen/blob/master/mpv/parts/plugins/x-waf.py but it's very optiniated | 11:24 |
| ogra_ | looks like bug 1572963 | 11:26 |
| mup | Bug #1572963: snapcraft upload can fail while monitoring scan status <verification-done> <Snapcraft:Fix Released by vila> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1572963> | 11:26 |
| ogra_ | hmm, or probably not ... but related at least | 11:28 |
| ogra_ | ah, because the original description was changed ... https://bugs.launchpad.net/snapcraft/+bug/1572963/comments/0 pretty much describes what i see | 11:30 |
| mup | Bug #1572963: snapcraft upload can fail while monitoring scan status <verification-done> <Snapcraft:Fix Released by vila> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1572963> | 11:30 |
| === hikiko|ln is now known as hikiko | ||
| ogra_ | sergiusens, not sure if bug 1610948 is for you or the store people | 11:52 |
| mup | Bug #1610948: automated snap uploads from launchpad often cause pointless 404 errors <Snapcraft:New> <Software Center Agent:New> <https://launchpad.net/bugs/1610948> | 11:52 |
| ogra_ | (i assigned to to SCA and snapcraft for now) | 11:53 |
| ogra_ | sigh ... | 11:59 |
| === daker_ is now known as daker | ||
| ogra_ | the arm builders are really busy since last week ... | 11:59 |
| cpaelzer | dz0ny: thanks for the link - I'm gonna take alook and maybe once I'm happy with the one I'm working on we can prep a PR for snapcraft | 12:03 |
| === JanC is now known as Guest57323 | ||
| === JanC_ is now known as JanC | ||
| pmp | zyga: I issued a pull-request for devtools, not sure if it is ok for all platforms - please review | 12:18 |
| pmp | zyga: I could cross-compile snapd with these changes on debian testing. | 12:18 |
| pmp | zyga: at least that what I think I did ;-) | 12:19 |
| Son_Goku | zyga, f25 hasn't been bodhi activated yet | 12:25 |
| Son_Goku | branching and the bodhi activation point are two different times | 12:25 |
| Son_Goku | zyga: https://fedoraproject.org/wiki/Releases/25/Schedule | 12:26 |
| Son_Goku | Bodhi activation is tomorrow | 12:26 |
| Son_Goku | if everything makes it in today, we don't have to worry about bodhi for f25 | 12:26 |
| mup | PR snapd#1648 opened: overlord,store: set store device authorization header <Created by matiasb> <https://github.com/snapcore/snapd/pull/1648> | 12:29 |
| zyga | pmp: thanks, will do | 12:30 |
| zyga | Son_Goku: yep, I learned about that since asking :) | 12:30 |
| zyga | Son_Goku: I had a look at gettext but I was busy writing a blog post about snap-confine | 12:31 |
| zyga | Son_Goku: I cannot see anything wrong but I didn't check all of my email yet | 12:31 |
| kaisoz | Hi again | 12:41 |
| Son_Goku | zyga, the issue with gettext is that there's a file that says it imports go-flags | 13:02 |
| Son_Goku | but for whatever reason, it's not a dependency in gettext | 13:02 |
| Son_Goku | zyga, the go-xgettext code uses it | 13:04 |
| Son_Goku | actually, now I realize the thing | 13:05 |
| Son_Goku | go-xgettext is an example program, isn't it? | 13:05 |
| ogra_ | jdstrand, are you around today ? | 13:06 |
| sergiusens | ogra_ the uploads from launchpad are driven by launchpad using the store api and not involving snapcraft at all | 13:06 |
| sergiusens | I'll make a note on the bug | 13:07 |
| ogra_ | sergiusens, thanks, feel free to invalidate it then | 13:07 |
| ogra_ | (teh snapcraft task) | 13:07 |
| Son_Goku | zyga, actually, it looks like you need to add go-flags as a BR at least because it's used during the %check section | 13:07 |
| morphis | ogra_: you know directly which firmware files are missing? | 13:09 |
| zyga | Son_Goku: look now | 13:09 |
| ogra_ | morphis, not from the top of my head ... i think ppisati already packaged it though ... in his embedded ppa | 13:09 |
| zyga | Son_Goku: go-xgettext is a real xgettext replacement for golang sources | 13:10 |
| zyga | Son_Goku: it's a tool though you don't have to use it | 13:10 |
| Son_Goku | ah | 13:10 |
| zyga | Son_Goku: the advantage over *gettext is that it parsers go code with go itself | 13:10 |
| morphis | ogra_: I see, thanks | 13:10 |
| zyga | Son_Goku: so it is more reliable | 13:10 |
| Son_Goku | does it conflict with system gettext? | 13:10 |
| Son_Goku | if not, why not slightly adjust the package so that it builds it and makes it available? | 13:11 |
| Son_Goku | people might want to use it | 13:11 |
| zyga | Son_Goku: no, the binary is separate | 13:11 |
| zyga | Son_Goku: hmm, didn't I do exactly that? (me checks) | 13:11 |
| Son_Goku | nope | 13:11 |
| Son_Goku | you don't | 13:11 |
| zyga | I probably did that in suse | 13:11 |
| Son_Goku | yeah, probably | 13:12 |
| zyga | sorry, I'll copy that change | 13:12 |
| Son_Goku | okay, cool | 13:12 |
| Son_Goku | be sure to update the bug with a comment indicating new changes, link the new srpm, and link to spec | 13:12 |
| zyga | yep, I'll do exactly | 13:12 |
| zyga | that | 13:12 |
| Son_Goku | once you've done that, I can approve the package and you can push it | 13:13 |
| Son_Goku | after I take a look at it, of course :P | 13:13 |
| zyga | yep, just looking at the suse version of the package to compare | 13:14 |
| zyga | gofed makes it a bit noisy | 13:14 |
| Son_Goku | gofed was designed to automate packaging and updating golang libraries | 13:15 |
| Son_Goku | as very early on, it looked like golang was going to turn into the same mess nodejs is with npm | 13:15 |
| Son_Goku | it doesn't mean you get to switch your brain off entirely, as there are definitely certain aspects you should probably handle yourself if the package is slightly unusual | 13:16 |
| Son_Goku | but it does make the process simpler | 13:16 |
| morphis | ogra_: also it looks like the pi3 doesn't get an IP address on subsequent boots | 13:27 |
| ogra_ | morphis, do you see an entry for the NIC in /etc/network/interfaces.d ? | 13:27 |
| morphis | need to pull the sdcard, sec | 13:28 |
| ogra_ | iirc there is still an issue with the firstboot job that doesnt always create the setup | 13:28 |
| morphis | I see the greenlight continously blinking | 13:28 |
| ogra_ | well, what do you see on the serial console ? :) | 13:28 |
| morphis | don't have one connected | 13:28 |
| morphis | :-) | 13:28 |
| morphis | but there is a e/n/i.d file | 13:29 |
| ogra_ | then it shold also get the NIC up | 13:29 |
| morphis | yes | 13:29 |
| morphis | ogra_: we're using predictable network iface names now? | 13:29 |
| ogra_ | are you sure it is the NIC itself or just i.e. ssh | 13:29 |
| ogra_ | we set net.ifnames=0 on the kernel cmdline ... | 13:30 |
| ogra_ | which should prevent "predictable" names | 13:30 |
| morphis | I get enxb827eb0c621b as eth name | 13:31 |
| morphis | ogra_: no, its the NIC | 13:31 |
| ogra_ | then i guess there iis a bug with the net.ifnames=0 recognition somewhere | 13:32 |
| morphis | otherwise nmap would find the host as up | 13:32 |
| ogra_ | (which i fear needs pitti input ... who is on vac.) | 13:32 |
| morphis | :-) | 13:32 |
| ogra_ | for the moment you can mv the eth0 file to the right name | 13:33 |
| ogra_ | that should get you up and running | 13:33 |
| zyga | the user experience of fedpkg vs using rpm* directly is staggering | 13:33 |
| zyga | most of the stuff that is annoying is fixed by fedpkg | 13:34 |
| ogra_ | hmm ... so i wonder if https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2575 will actually work now | 13:34 |
| zyga | but you cannot use it before you get the database updated :) | 13:35 |
| cpaelzer | I might have totally missed if something like it is already available, but if a snap provides man pages "in" the snap - is (?could?) there be some auto-registration into man - so that man yousnap.command auto-maps and opens the matching snap manpage? | 13:35 |
| kalikiana | There's a bug for that | 13:37 |
| ogra_ | that will also onlly work on classic installs ... | 13:38 |
| kalikiana | Specifically bug 1575593 | 13:38 |
| mup | Bug #1575593: Snappy installed manpages aren't accessible through man <Snappy:New> <ubuntu-snappy (Ubuntu):Confirmed> <https://launchpad.net/bugs/1575593> | 13:38 |
| kalikiana | ogra_: Why? Is there a known plan to implement it? | 13:39 |
| ogra_ | (all-snap imges do not have man installed at all ... nor does the ubuntu-core snap itself ... on purpose) | 13:39 |
| cpaelzer | thanks kalikiana and ogra_ | 13:39 |
| ogra_ | kalikiana, no idea, if there is any plan ... but it would need to happen by using the hosts "man" on classic and would need to detect if it is running on classic or an actual snappy image | 13:40 |
| Son_Goku | zyga, the only thing I use rpmbuild for is making the SRPM | 13:42 |
| Son_Goku | everything else is done with mock or fedpkg | 13:42 |
| kalikiana | Using the host makes no sense... you want the man pages of the binaries you actually run, regardless of whether they're in the core snap or any other snap. | 13:42 |
| ogra_ | kalikiana, well, you need the manpages in the man db and you need a man/groff binary | 13:42 |
| ogra_ | neither is available in ubuntu-core | 13:42 |
| ogra_ | and we will definitely not add it | 13:43 |
| ogra_ | (since the ubuntu-core snap is still megabytes to big) | 13:43 |
| kalikiana | ogra_: Can't all of that go to a man snap? | 13:43 |
| ogra_ | that could work, but then you only have man support if you have the man snap installled ... | 13:43 |
| ogra_ | and you get into trouble with mandb still ... since yu need to auto-update it for every snap | 13:44 |
| ogra_ | that requires some interaction between snaps that we dont have today | 13:44 |
| ogra_ | not saying it is impossible, but the interface you would need would be pretty complex | 13:45 |
| kalikiana | The obvious alternative would be a server - I use a script to do that today to read manpages of packages I don't have installed. But it only works for packages in the archive, so snaps wouldn't work. | 13:46 |
| kalikiana | Unless the store would extract man pages. | 13:46 |
| camako | trying to run 'snapcraft cleanbuild' on my snap, but I'm getting "500 Internal Server Error"... here's the log ---> http://pastebin.ubuntu.com/22691796 my lxd otherwise appears sane | 13:46 |
| camako | any idea what might be the problem? | 13:46 |
| kalikiana | Thinking about it, maybe I should snap that script | 13:48 |
| ogra_ | +1 | 13:48 |
| ogra_ | :) | 13:48 |
| cpaelzer | ogra_: kalikiana: thanks for the discussion - I subscribed to the bug and will think about it a bit as well | 13:49 |
| cpaelzer | ogra_: kalikiana: eventually /etc/manpath.config already has a path mapper, maybe we just have to find a way to append for installed snaps so the hosts mandb updates will pick it up | 13:49 |
| ogra_ | cpaelzer, well, that would break confinement ... you dont really want to blindly pull in manpages that could ppotentially be malicious binaries instead of manpages ... | 13:50 |
| arges | jdstrand: hi | 13:50 |
| cpaelzer | ogra_: sad but true, thanks for keeping the confinement thought up | 13:50 |
| ogra_ | you actually need an interface i think | 13:51 |
| jdstrand | arges: hey | 13:53 |
| jdstrand | ogra_: yes | 13:54 |
| arges | jdstrand: https://github.com/snapcore/snapd/pull/1602#issuecomment-237949753 working on this PR. Even with apparmor rules allowing /proc/version_signature I can't seem to open the file... are there other permissions I need to worry about? | 13:54 |
| mup | PR snapd#1602: interfaces: add kernel-module interface for module insertion <Created by arges> <https://github.com/snapcore/snapd/pull/1602> | 13:54 |
| ogra_ | jdstrand, awesome ... so we have auto-builds for ubuntu-core in place now ... together with auto-uploads ... the one remaining prob for me is that "type: os" now blocks the auto-accepting, could we do wsome special casing in the review tools ? | 13:55 |
| jdstrand | arges: no. what are the permissions of the file from within the snap? | 13:55 |
| arges | jdstrand: is there a simple way to check this.. i know there was a wrapper script at some point? | 13:55 |
| jdstrand | ogra_: yes. can you give me a list of snap names that should be auto-approved? | 13:55 |
| ogra_ | oh, and one other thing, when i build with snapcraft ... which i now do for kernel and os, the review tools complain about confinemment (obviously a snapcraft bug that it secretly adds it) ... could we also ignore that ? | 13:56 |
| ogra_ | ("confinement: strinct" i mean) | 13:56 |
| ogra_ | jdstrand, for now only ubuntu-core ... by EOW i can give you names for the kernel snaps | 13:56 |
| ogra_ | jdstrand, https://myapps.developer.ubuntu.com/dev/click-apps/4142/ | 13:57 |
| jdstrand | ogra_: ack, I'll take a look and handle all that | 13:57 |
| ogra_ | thanks ! | 13:57 |
| ogra_ | :) | 13:57 |
| jdstrand | arges: what I personall would do is create a 'sh' command in 'apps'. just copy the one from hello-world, adjust your yaml to copy it into place and expose it in 'apps' with whatever 'plugs' you need. then your-snap.sh and do whatever | 13:59 |
| jdstrand | arges: that's a handy method for testing. you can drive your other commands within confinement and iterate a bit easier | 13:59 |
| arges | jdstrand: ok i've done it that way before... I remember there was a snap shell command, but didn't know if there was a better way todo it | 14:00 |
| jdstrand | there's another way that I know people have talked about. snap try or snap shell I think-- I don't know if those are implemented | 14:00 |
| arges | jdstrand: ack i'll poke around and see what i can find. thanks | 14:01 |
| jdstrand | arges: I'm not 100% sure that is an exact runtime environment with try or shell | 14:01 |
| didrocks | jdstrand: so, imagine I have an unix socket to communicate between a cli (running as a user) and a service (running so as root), any advice/idea where to put it to get both communicating? | 14:09 |
| didrocks | I can use SNAP_COMMON + make it +w for everyone, but other opinions would be welcomed | 14:09 |
| didrocks | (both ends are from the snap) | 14:09 |
| zyga | didrocks: I'd use /run | 14:09 |
| zyga | didrocks: one sec, let me check the template | 14:10 |
| mhall119 | didrocks: dholbach: do we have a snapcraft plugin for ant? | 14:10 |
| didrocks | zyga: ah, they are common between apps from the same snaps? | 14:10 |
| didrocks | mhall119: there is on built-in, yeah | 14:10 |
| didrocks | mhall119: btw, snapcraft list-plugins :) | 14:10 |
| zyga | didrocks: yes though run may not be what you want | 14:10 |
| zyga | didrocks: also I should hit a publish button | 14:11 |
| mhall119 | didrocks: nice, thanks! | 14:11 |
| didrocks | zyga: ;) well, we do use /run for this kind of socket communication on traditional desktop | 14:11 |
| didrocks | mhall119: yw! | 14:11 |
| zyga | didrocks: http://www.zygoon.pl/2016/08/snap-execution-environment.html | 14:11 |
| zyga | fresh off my todo list | 14:11 |
| zyga | now let me check that run for you | 14:11 |
| didrocks | thanks! I think there is a pattern like /run/snap.<snapname> something in the apparmor profile | 14:12 |
| * didrocks reads the new blog post | 14:12 | |
| mhall119 | sergiusens: when will snapcraft let me set envvars for a snap? That's blocking a few that are otherwise upstreamable | 14:13 |
| zyga | didrocks: it's not in the default template | 14:13 |
| zyga | didrocks: that's something we should consider improving | 14:13 |
| didrocks | zyga: oh? indeed, sounds like it should be there | 14:13 |
| zyga | mhall119: when new snapd allows this, it's almost complete on this side | 14:13 |
| zyga | didrocks: I agree, I'll talk to jdstrand about this | 14:13 |
| mhall119 | zyga: oh, I thought it was just going to inject them into the generated wrapper | 14:14 |
| === wililupy is now known as wililupy|travel | ||
| zyga | mhall119: I think that this falls under 'sensible defaults' as long as it doesn't allow IPC | 14:15 |
| zyga | mhall119: (across the snap boundary) | 14:15 |
| zyga | mhall119: similar to how we allow /dev/shm/... /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix, | 14:15 |
| zyga | mhall119: for cross snap IPC you always need an interface | 14:16 |
| didrocks | yep! | 14:16 |
| mhall119 | uh, I just was to set SQLITE_TMPDIR=/tmp | 14:16 |
| arges | jdstrand: ok... so I want my bash to have the same permissions as what 'daemon: simple' gives a program to see what it sees.. | 14:16 |
| didrocks | mhall119: I guess zyga was talking to me :) | 14:16 |
| mhall119 | I hope so :) | 14:16 |
| * zyga needs to get his blog federated on planet arch linux | 14:16 | |
| arges | jdstrand: any suggestions for making this work with snap/snapcraft? | 14:16 |
| zyga | arges: it is just a systemd unit that runs your snap as root, with HOME set to /root and pretty much no change to how snaps otherwise execute | 14:17 |
| arges | zyga: i'm trying to debug a daemon, and jdstrand suggested trying things as bash. So I'm trying to debug from the daemon perspective | 14:18 |
| arges | adding 'bash -u root' to the command doesn't work, so trying to figure it out | 14:18 |
| jdstrand | arges: use the same plugs and execute 'sh' under sudo | 14:19 |
| jdstrand | arges: a few env variables aren't going to be the same but that should be good enough | 14:19 |
| arges | jdstrand: so 'sudo su' in the snap bash shell doesn't work, so I'm guessing you mean change the command in the snapcraft.yaml to 'sudo su' ? | 14:20 |
| jdstrand | didrocks, zyga: /run/shm/snap.$SNAP_NAME.** is in the default template and can be used for cross-app communications, but not cross-snap communications | 14:21 |
| didrocks | excellent, exactly what I wanted! | 14:21 |
| jdstrand | arges: sudo /snap/bin/your-thing.sh | 14:21 |
| didrocks | thanks jdstrand | 14:21 |
| arges | jdstrand: ok. using that i am able to read /proc/version_signature ... hmm | 14:22 |
| jdstrand | arges: check that the resulting security policy is sufficiently the same: diff -Naur /var/lib/snapd/profiles/snap.your-thing.daemon /var/lib/snapd/profiles/snap.your-thing.sh (and do the same for seccomp) | 14:24 |
| jdstrand | arges: if they are, then you might look at systemd to see if it is doing anything weird with /proc that it maybe shouldn't be | 14:25 |
| jdstrand | arges: or maybe there is a bug in your code... (hard to say, but the fact that 'sh' can access it suggests it is something outside of the sandbox that is causing the problem) | 14:27 |
| arges | jdstrand: well it works running without snappy fwiw | 14:28 |
| arges | i'll check the above | 14:28 |
| cpaelzer | zyga: thanks for that blog series btw - really providing some extra insights once through the usual entry docs | 14:28 |
| arges | jdstrand: no diff except for profile name. | 14:31 |
| zyga | cpaelzer: my pleasure, feel free to send me suggestions | 14:35 |
| zyga | jdstrand: hey, long time no see, how are you doing | 14:35 |
| zyga | jdstrand: I didn't notice the /run/shm part, just /dev/shm, is there any reason or plan for long term standarization of that? should we offer /run/snap.$SNAP_NAME.* ? | 14:36 |
| mup | PR snapcraft#713 opened: rust plugin: mock downloads in unit tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/713> | 14:39 |
| jdstrand | zyga: we do offer /run/snap.$SNAP_NAME.**. look at template.go | 14:46 |
| jdstrand | zyga: oh sorry, I thought you meant /run/shm | 14:47 |
| jdstrand | zyga: there is no reason we couldn't offer /run/snap.$SNAP_NAME.** technically-- it is clean from an application isolation pov, but /run is typically for well-known locations like mir, lxd, docker, etc and they won't want to conform to snap.$SNAP_NAME | 14:48 |
| ogra_ | GRRR | 14:49 |
| jdstrand | so I suspect it won't really help anything, but if it makes things easier, I'm fine with it | 14:49 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/writable/system-data/snap/pi2-kernel/ | 14:49 |
| ogra_ | unset | 14:49 |
| ogra_ | why does u-d-f not like me ! | 14:49 |
| ogra_ | *sniff* | 14:49 |
| zyga | jdstrand: I did check template.go, I just missed it among the {/dev,} variants | 14:50 |
| jdstrand | arges: ok, then I suspect systemd is doing something. why or what, I don't know (but that is really the only thing that is different) | 14:50 |
| jdstrand | zyga: well, it doesn't help that /run/shm/$SNAP_NAME.** and /run/snap.$SNAP_NAME.* look pretty similar when reading quickly :) | 14:51 |
| zyga | jdstrand: FYI: http://www.zygoon.pl/2016/08/snap-execution-environment.html :) | 14:51 |
| jdstrand | zyga: so, /run/shm/$SNAP_NAME.** is allowed now, /run/snap.$SNAP_NAME.* is not. if want /run/snap.$SNAP_NAME.*, that is easy, but see above | 14:51 |
| jdstrand | zyga: nice! /me reads | 14:52 |
| zyga | yes, I wonder about this myself, some of the apps would probably happily switch to /var/snap.$SNAP_NAME | 14:52 |
| zyga | but perhaps not all and this is a tricky subject | 14:52 |
| jdstrand | maybe | 14:52 |
| jdstrand | I mean, we can allow it | 14:52 |
| zyga | I'd perhaps offer /run/$SNAP_NAME.* directly | 14:52 |
| jdstrand | it's fine from an application isolation perspective | 14:52 |
| zyga | because snap names are something that can be managed separately | 14:52 |
| jdstrand | no | 14:52 |
| zyga | no? | 14:52 |
| jdstrand | that is not fine | 14:52 |
| jdstrand | need snap. | 14:53 |
| jdstrand | or an interface | 14:53 |
| sergiusens | mhall119 as soon as I can get to it; probably 2.15 | 14:53 |
| zyga | what's the difference betwen /run/$SNAP_NAME and /run/snap.$SNAP_NAME? | 14:53 |
| jdstrand | cause people will create an 'acpid' snap and be allowed to create /run/acpid.socket and wreack havoc | 14:53 |
| jdstrand | wreak | 14:54 |
| zyga | acpid should be reserved for other reasons | 14:54 |
| jdstrand | it's all the same arguments for why we have snap. prefixed everywhere already | 14:54 |
| zyga | and if and when it is a genuine snap, why wouldn't it be ok to access? | 14:54 |
| jdstrand | ntpd? docker? lxd? ekeyd? etc etc | 14:54 |
| zyga | yes | 14:54 |
| zyga | docker, for sure! | 14:54 |
| zyga | think about it | 14:55 |
| jdstrand | snap.$SNAP_NAME is ok by default. $SNAP_NAME needs an interface | 14:55 |
| zyga | if you own docker name, docker executable name, etc | 14:55 |
| zyga | well, /run won't be available to anyone outside of the snap | 14:55 |
| ogra_ | that makes you non-evil ? | 14:55 |
| zyga | I totally agree about cross-snap IPC | 14:55 |
| jdstrand | why? | 14:55 |
| jdstrand | we are mounting /run separate too? | 14:56 |
| jdstrand | that is going to be really complicated for cross-snap stuff | 14:56 |
| zyga | jdstrand: because $various_projects use /run/$SNAP_NAME already | 14:56 |
| zyga | ah, I see | 14:56 |
| zyga | I was just curious | 14:56 |
| jdstrand | I think we should avoid bind mounts except where absolutely necessary and stay in the global namespace | 14:57 |
| mup | PR snapcraft#713 closed: rust plugin: mock downloads in unit tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/713> | 14:57 |
| jdstrand | we are already seeing lots of complications with what we are doing and they are only going to get more complicated | 14:57 |
| jdstrand | cause then there is ordering, uninstalls are problematic, etc, etc | 14:58 |
| zyga | jdstrand: I don't think we'll get many more non-interface-specific bind mounts | 14:58 |
| jdstrand | ok | 14:58 |
| jdstrand | I think it is worth taking a moment to think about why apps are creating sockets and stuff in /run-- it is for IPC. inter-snap IPC is supposed to be governed by interfaces (a design goal). inter-app communication within a snap we can do whatever makes sense | 14:59 |
| jdstrand | so, if you want to add /run/snap.$SNAP_NAME.** today, I'm ok with that. but /run/$SNAP_NAME.** I think we'd need to have a conversation about with nie meyer so we are all on the same page | 15:00 |
| zyga | jdstrand: agreed | 15:01 |
| * zyga -> break | 15:03 | |
| jdstrand | zyga: reading your article, I didn't see you reference scmp_sys_resolver (and that it must be run on the same arch as the snap). or hint towards using snappy-debug.security scanlog (we should rename that since it seems clear nothing else is going to end up in snappy-debug) | 15:06 |
| zyga | jdstrand: I did mention snappy-debug but not any details | 15:07 |
| jdstrand | ah, I see that now | 15:07 |
| zyga | jdstrand: I decided not to mention scmp_sys_resolver because it is geeky and doesn't win much | 15:07 |
| jdstrand | I didn't get that far yet | 15:07 |
| zyga | jdstrand: :-) | 15:07 |
| zyga | jdstrand: I'll probably upload syscall snap to the store that resolves syscall numbers across architectures | 15:07 |
| jdstrand | zyga: note, apparmor cannot check system call arguments | 15:07 |
| jdstrand | zyga: that is for seccomp (and not necessarily for the article, only integers, not structs, etc) | 15:08 |
| zyga | jdstrand: ah, so the fact that you can open /foo is implemented as LSM check in the VFS, not on open itself? | 15:08 |
| jdstrand | zyga: correct | 15:08 |
| cpaelzer | a daemon: forking snap should automatically get some sort of generated systemd service that one can check right? | 15:08 |
| zyga | jdstrand: I know about the seccomp not reading userspace memory | 15:08 |
| * cpaelzer searches the hiding systemd unit | 15:09 | |
| ogra_ | cpaelzer, yeah, snapd creates it at install time ... it gets prefixed with snap.* | 15:09 |
| zyga | jdstrand: I really wonder how apple's sandboxd works now | 15:09 |
| zyga | jdstrand: anyway, noted, thank you for being precise | 15:09 |
| jdstrand | there are a ton of LSM hooks that give access to the thing being mediated. seccomp isn't consulted at the same points so doesn't have the ability to look at the filename of 'open', for example | 15:09 |
| ogra_ | (as long as you defined it in your "app:" entry in snapcraft.yaml) | 15:10 |
| cpaelzer | ogra_: it is in the app entry I'd have expected snap.ntpd for this http://paste.ubuntu.com/22698736/ | 15:10 |
| jdstrand | zyga: I suggest s/ulted at the same points so doesn't | 15:11 |
| jdstrand | zyga: strike that-- bad paste | 15:11 |
| ogra_ | cpaelzer, try: snap-ntpsec.ntpd.service | 15:12 |
| ogra_ | or some such | 15:12 |
| jdstrand | zyga: I suggest: s/system call arguments/traditional UNIX IPC like signals and sockets,/ | 15:12 |
| jdstrand | zyga: 2 cents | 15:12 |
| ogra_ | cpaelzer, systemctl | grep ntp | 15:12 |
| ogra_ | ;) | 15:12 |
| cpaelzer | obviously :-) thanks why didn't I just search that way :-) | 15:12 |
| cpaelzer | thanks | 15:12 |
| ogra_ | oh, actually snap.ntpsec.ntpd.service | 15:12 |
| cpaelzer | snap.ntpsec.ntpd.service | 15:12 |
| cpaelzer | ack | 15:13 |
| ogra_ | (sorry, typoed that) | 15:13 |
| zyga | jdstrand: updated :) | 15:14 |
| * zyga -> really ADFK | 15:14 | |
| mup | PR snapd#1634 closed: store: add device nonce API support <Reviewed> <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1634> | 15:18 |
| mup | PR snapd#1648 closed: overlord,store: set store device authorization header <Reviewed> <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1648> | 15:20 |
| mup | PR snapd#1493 closed: store/auth: add SnapUbuntuStoreAuthService with device identity methods <Created by wgrant> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1493> | 15:22 |
| mup | PR snapd#1528 closed: overlord/devstate: add DeviceManager which checks assertions <Created by wgrant> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1528> | 15:23 |
| jdstrand | niemeyer: hi! fyi, https://github.com/snapcore/snapd/pull/1409#issuecomment-238269429 | 15:31 |
| mup | PR snapd#1409: docs/interfaces.md: improve interfaces documentation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1409> | 15:31 |
| jdstrand | niemeyer: basically an integration test is failing that is unrelated to the PR | 15:31 |
| jdstrand | niemeyer: also as fyi, I got the PR pings for other stuff and will take a look a bit later | 15:33 |
| john-mcaleely | ogra_, how long do you expect it to take for an rpi3 to boot all-snaps image? it seems to be aaaageeess | 15:39 |
| qengho | 10 minutes? | 15:39 |
| ogra_ | john-mcaleely, around 1-2 mins for the first boot | 15:39 |
| ogra_ | subsequent ones take aless | 15:39 |
| ogra_ | *less | 15:39 |
| john-mcaleely | hmm, more like 15 so far. green led blinking. raspberries just disappeared | 15:40 |
| john-mcaleely | will let you know if it completes | 15:40 |
| john-mcaleely | I assume I get a login prompt? | 15:40 |
| ogra_ | note that it only boots to serial console | 15:40 |
| cpaelzer | since there is no "snap config" https://developer.ubuntu.com/en/snappy/guides/config/ feels outdated. If I need to provide a /ect/something.conf to a snap app that is somewhat user controllable what is the best current doc or example to start with? | 15:40 |
| john-mcaleely | ogra_, which appears where? (I am stupid!) | 15:40 |
| ogra_ | on your attached serial cable indeed :) | 15:41 |
| ogra_ | it should eventually also pop up a login prompt on the screen though | 15:41 |
| john-mcaleely | ogra_, ah. I need to google how to get such a thing :-) | 15:41 |
| ogra_ | (ubnless systemd doesnt spawn consoles if you dont set console=tty1) | 15:42 |
| john-mcaleely | (still wating on the HDMI output) | 15:42 |
| ogra_ | are oyu using my image ? | 15:42 |
| ogra_ | or something self breed | 15:42 |
| ogra_ | *bewed | 15:42 |
| ogra_ | bah | 15:42 |
| ogra_ | *brewed | 15:42 |
| john-mcaleely | ogra_, yours indeed: http://people.canonical.com/~ogra/snappy/all-snaps/ | 15:43 |
| ogra_ | yeah, that should boot ... it dpoes at least on serial | 15:43 |
| ogra_ | ( i always test the early builds with serial and eth attached) | 15:44 |
| john-mcaleely | ok, I need to rummage for a serial port then | 15:44 |
| qengho | john-mcaleely: Is there a change in eth status? | 15:44 |
| john-mcaleely | lights, sure | 15:44 |
| john-mcaleely | (on the eth) | 15:44 |
| qengho | john-mcaleely: I think you can change the boot config files to make it try hdmi. | 15:45 |
| john-mcaleely | hmm | 15:45 |
| ogra_ | qengho, seems we are suffering from a systemd bug ... i.e. net.ifnames=0 isnt respected anymore all of a sudden | 15:45 |
| ogra_ | so there wont be any config | 15:45 |
| qengho | Oh man. | 15:45 |
| ogra_ | (for the NIC that is) | 15:45 |
| ogra_ | john-mcaleely, try editing the cmdline.txt and add console=tty0 to the end of the line in that file ... directly on the SD card | 15:46 |
| ogra_ | that should redirect output to the LCD so you can debug without serial cable | 15:46 |
| john-mcaleely | ogra_, aha, ok I will rummage there! | 15:46 |
| john-mcaleely | thank you! | 15:47 |
| ogra_ | :) | 15:47 |
| arges | jdstrand: ok figured it out. I forgot to restart the daemon after connecting it. | 15:47 |
| arges | * connecting the interfaces that is | 15:47 |
| * qengho still wishes for image build bots. pi2, pi3, pandaboard, etc. Built nightly if any change. | 15:48 | |
| arges | I'm guessing that restarting it reloads the apparmor profile? | 15:48 |
| john-mcaleely | +1 | 15:48 |
| ogra_ | qengho, working on that ... | 15:48 |
| ogra_ | https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core was the first step ... just needs some review tools fixage now then we have dailies for the ubuntu-core snap ... i'm battlling with the same setup for kernels ... once we have daily auto-pushes to the store we can have daily images from these packages | 15:50 |
| qengho | ogra_: Awesome! | 15:50 |
| ogra_ | (btw, you can actually branch the bzr branch this uses to inject personal changes and do sideloaded images with them) | 15:51 |
| ogra_ | (i'll blog about it once everything is in place) | 15:51 |
| stgraber | jdstrand: when you have 5 minutes, can you review https://github.com/snapcore/snapd/pull/1598 ? it's a simple fuse interface to run a fuse filesystem | 15:52 |
| mup | PR snapd#1598: interfaces: implement a fuse interface <Reviewed> <Created by stgraber> <https://github.com/snapcore/snapd/pull/1598> | 15:52 |
| mup | PR snapcraft#714 opened: Release changelog for 2.14 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/714> | 15:57 |
| ogra_ | whee ! | 15:57 |
| * ogra_ looks forward to drop the hacked snapcraft from the image build PPA | 15:58 | |
| jdstrand | stgraber: it's on my todo for later today | 16:00 |
| sborovkov | ogra_: hello. do you by any chance have some recent RPI2 snappy only image? Accidentaly removed one I built 2 weeks ago and I can't build now because of some errors popping up about hardware configuration... | 16:04 |
| ogra_ | sborovkov, yes, as announced last week on the ML :) | 16:06 |
| ogra_ | http://people.canonical.com/~mvo/all-snaps/16/ | 16:06 |
| ogra_ | note that this is all still experimental | 16:06 |
| stgraber | jdstrand: cool, thanks | 16:07 |
| sborovkov | ogra_: ah cool, so it's out. missed that | 16:09 |
| ogra_ | sborovkov, nothing is out ... it is really highlly experimental still and will likely stay so for a while | 16:10 |
| sborovkov | But it was the same before, was not it? ) | 16:10 |
| ogra_ | yeah | 16:11 |
| ogra_ | since we started on series 16 | 16:11 |
| mup | PR snapd#1649 opened: store: minor store improvements from previous reviews <Created by matiasb> <https://github.com/snapcore/snapd/pull/1649> | 16:20 |
| john-mcaleely | ogra_, so, adding tty0 got output on screen. It's to a busbox prompt, which is a surprise | 16:21 |
| ogra_ | yeah, that sounds messed up | 16:21 |
| john-mcaleely | last line of log above is 'no init found. try passing init= bootarg' | 16:21 |
| ogra_ | yeah, thats useless | 16:21 |
| ogra_ | the actual error is lines above | 16:22 |
| ogra_ | most likely scrolled off screen ... | 16:22 |
| john-mcaleely | right. looks that way. i have a screen full of errors | 16:22 |
| john-mcaleely | I will set up a UART so these things are captureable | 16:22 |
| ogra_ | (this is where you actually need serial to capture the logs) | 16:22 |
| john-mcaleely | odd though - I assumed my pi3 was a standard object... | 16:22 |
| ogra_ | well, you are testing the very first experimental image for a new setup | 16:23 |
| john-mcaleely | ha | 16:23 |
| ogra_ | (which only got a very lax smokke test before being published ... i.e. snap install hello-world after manually setting up networking) | 16:24 |
| john-mcaleely | my pi is silkscreened 'Raspberry Pi 3 Model B V1.2' | 16:24 |
| ogra_ | well, it should just work | 16:24 |
| john-mcaleely | as always! | 16:25 |
| ogra_ | but there can be bugs where a failed firstboot setup eats your filesystem and such stuff | 16:25 |
| === matiasb1 is now known as matiasb | ||
| ogra_ | try a fresh flash and edit the cmdline.txt before the first boot | 16:25 |
| john-mcaleely | hmm. now I know the tty0 trick, let me see what a fresh sd card does with just that change | 16:25 |
| ogra_ | yeah | 16:25 |
| john-mcaleely | snap! | 16:25 |
| ogra_ | snappy !! | 16:25 |
| ogra_ | :) | 16:25 |
| ogra_ | schnaps ! | 16:26 |
| john-mcaleely | better | 16:26 |
| john-mcaleely | best! | 16:26 |
| niemeyer | jdstrand: Sweet, thanks! Want to try getting some of those interfaces handled today | 16:28 |
| * ogra_ sighs ... something is really wrong with either u-d-f or our new kernel spec | 16:29 | |
| mup | PR snapd#1409 closed: docs/interfaces.md: improve interfaces documentation <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1409> | 16:31 |
| john-mcaleely | ogra_, fyi. it's alive! logged in, and installed hello-world | 16:38 |
| ogra_ | yay | 16:38 |
| ogra_ | did the NIC come up properly OOTB ? | 16:38 |
| john-mcaleely | should I raise a bug to add tty0 to the cmdline? seems useful for typical pi3 hackers ogra_? | 16:38 |
| ogra_ | no, i explicitly removed it :) | 16:38 |
| john-mcaleely | sigh | 16:38 |
| ogra_ | it will come back once the images have stabilized :) | 16:38 |
| mup | PR snapd#1643 closed: many: support interactive payments in snapd, filter from command line <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1643> | 16:38 |
| ogra_ | (no worries, i wont forget it) | 16:39 |
| john-mcaleely | sometimes I wonder if anyone wants us to use this stuff. I shall sign off for the day | 16:39 |
| ogra_ | well, that is what "experimental" means :) | 16:39 |
| john-mcaleely | it's a long word for 'broken' ;-0 | 16:40 |
| ogra_ | we are still developing these images ... everything will change | 16:40 |
| ogra_ | and for development we need the defaulting to serial | 16:40 |
| john-mcaleely | I get that. in the mean time I need to pass a hardware hazing ritual (install a uart) in order to follow along | 16:40 |
| john-mcaleely | I'm a software dude, and snappy is cool software | 16:40 |
| ogra_ | sure and i can give you a hand (like i did) to get your use-case going ... but the image might completely eat itself with the first update for example | 16:41 |
| ogra_ | nothing is stable there yet | 16:41 |
| john-mcaleely | I understand and expect that part | 16:41 |
| john-mcaleely | :-) | 16:41 |
| ogra_ | so even if you try your SW on it ... take everything with a grain of salt | 16:42 |
| qengho | Weird that it doesn't detect carrier or clear-to-send pin to decide whether to use serial or HDMI. | 16:43 |
| ogra_ | (i cant even guarantee yet that it will survive a few reboots) | 16:43 |
| ogra_ | qengho, we can surely add such features to uboot one day | 16:43 |
| ogra_ | note that we can not use the rpi bootloader | 16:43 |
| ogra_ | (only as jumpstart thing ) | 16:43 |
| john-mcaleely | anyway, thanks for the help ogra_. As you say, I'm now up and playing | 16:44 |
| john-mcaleely | I will expect breakage | 16:44 |
| ogra_ | cool | 16:44 |
| ogra_ | tell me about it if you hit it | 16:44 |
| john-mcaleely | ok! | 16:44 |
| niemeyer | joc_: snapd#1644 is ready for some love | 16:49 |
| mup | PR snapd#1644: interfaces/builtin: add gpio interface <Reviewed> <Created by jocave> <Conflict> <https://github.com/snapcore/snapd/pull/1644> | 16:49 |
| niemeyer | joc_: With that plus jdstrand's security review, we can land this | 16:49 |
| niemeyer | morphis: ^ | 16:49 |
| joc_ | niemeyer: thanks, i'll get on those comments | 16:50 |
| arges | I'm getting integration test failures that I don't think are caused by my PR... is this a known issue? | 16:57 |
| arges | http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/4129/ | 16:57 |
| mup | PR snapd#1649 closed: store: minor store improvements from previous reviews <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1649> | 17:01 |
| arges | jdstrand: ^^^ not sure if you are the one who knows about this stuff. still having fun with https://github.com/snapcore/snapd/pull/1602 | 17:14 |
| mup | PR snapd#1602: interfaces: add kernel-module interface for module insertion <Created by arges> <https://github.com/snapcore/snapd/pull/1602> | 17:14 |
| mup | Bug #1611063 opened: can't mkdir SNAP_USER_COMMON directory <Snappy:New> <https://launchpad.net/bugs/1611063> | 17:34 |
| blackboxsw | hmmm peeking around the cmdline snap tool docs, what is a snap assertion. cmdline help is slightly lacking about the intent | 17:47 |
| jdstrand | arges: I know about it and hit it in one of my PRs. There seems to be a problem with one of the integration tests. I don't know if elopio or others are aware. I suggest adding a comment in the PR that the test isn't due to you | 18:05 |
| arges | jdstrand: ok thanks | 18:05 |
| ahasenack | does the name of the slot have to match the name of the plug? Or all we care about is the interface name? | 18:14 |
| ahasenack | because the example on snapcraft.io (front page) uses "db" for A, and "database" for B | 18:14 |
| mup | Bug #1611078 opened: could not install hello-world snap <Snappy:New> <https://launchpad.net/bugs/1611078> | 18:41 |
| blackboxsw | so, the howto for creating a snap references snapcraft version 2.11 as required to get through the tutorial, but only snapcraft version 2.8.4 is available in xenial/universe. Where should folks go to get 2.11? | 18:41 |
| blackboxsw | http://snapcraft.io/create/ is the reference page I'm using | 18:41 |
| ahasenack | I was also wondering about ppas for a more up-to-date version | 18:42 |
| blackboxsw | yeah, it'd be nice to document that at the top (whatever the solution is) | 18:42 |
| ahasenack | the instructions on snapcract.io prefix every command with sudo, but that doesn't seem needed anymore | 18:42 |
| dpb1_ | you should just create a snap for it | 18:42 |
| dpb1_ | :) | 18:42 |
| ahasenack | and snap find doesn't have the --broad option the docs talk about | 18:42 |
| blackboxsw | heh | 18:42 |
| ahasenack | blackboxsw: I got 2.11 from xenial-updates | 18:45 |
| ahasenack | ah, snapcraft | 18:45 |
| ahasenack | sorry | 18:45 |
| ahasenack | blackboxsw: I have snapcraft 2.13.1 from xenial-updates/universe | 18:45 |
| blackboxsw | hrm | 18:45 |
| blackboxsw | trying apt-get update | 18:46 |
| blackboxsw | http://paste.ubuntu.com/22720373/ | 18:46 |
| ahasenack | blackboxsw: you don't seem to have xenial-updates for universe enabled | 18:46 |
| mup | Bug #1611080 opened: snapcraft.io says snap find has --broad, but it doesn't <Snappy:New> <https://launchpad.net/bugs/1611080> | 18:47 |
| blackboxsw | yeah I'm adding the source now | 18:47 |
| mup | Bug #1611083 opened: Users without xenial-updates/universe can't get snapcraft version 2.11 tour. <Snappy:New> <https://launchpad.net/bugs/1611083> | 18:56 |
| morphis | niemeyer: great, lets wait for jdstrand_ then | 19:20 |
| stokachu | how do i include files from my parts/build? | 19:21 |
| ahasenack | the "parts:" key shown in the first snapcraft example isn't described in http://snapcraft.io/docs/snaps/metadata | 19:29 |
| ahasenack | are these things out of date? Too old or too new? | 19:29 |
| qengho | ahasenack: The docs are ancient and so is "parts:". | 19:30 |
| qengho | ahasenack: What do you want to know? | 19:30 |
| ahasenack | what you just said, "docs are ancient" :) | 19:30 |
| ahasenack | i.e., want to know what to trust | 19:31 |
| ahasenack | should I file a bug? | 19:31 |
| cpaelzer | isn't this just metadata vs snapcraft yaml content? | 19:31 |
| ahasenack | this is a first-journey type of thing | 19:31 |
| qengho | ahasenack: Sure. | 19:31 |
| cpaelzer | parts is part of the snapcraft yaml | 19:31 |
| cpaelzer | and there it is fine and current IIRC | 19:31 |
| ahasenack | so snapcraft.yaml is like snap.yaml plus snapcraft specific things? | 19:32 |
| cpaelzer | and if you use snapcraft it will build the meta/snap.yaml for you (but you could build a snap without) and in there there is no parts | 19:32 |
| qengho | ahasenack: snapcraft is still in development. I don't think there's anything to "trust". There is a new version every couple of days. | 19:32 |
| cpaelzer | ahasenack: snapcraft will build the snap and its metadata - so snapcraft yaml has some similar content - but it is not just like a superset | 19:32 |
| ahasenack | cpaelzer: ah, I see | 19:33 |
| qengho | ahasenack: You should be writing for snapcraft. That is the human end of making a package. | 19:33 |
| cpaelzer | ack | 19:33 |
| qengho | ahasenack: All the rest of the details, you shouldn't care about. | 19:33 |
| cpaelzer | and as a first journey I'd recommend the tour | 19:33 |
| cpaelzer | ahasenack: http://snapcraft.io/create/ | 19:33 |
| ahasenack | it's where I am at now, that's where I saw this new "parts:" key | 19:33 |
| morphis | niemeyer: can you give https://github.com/snapcore/snapd/pull/1623 another round? | 19:34 |
| mup | PR snapd#1623: interfaces/udev,osutil: avoid doubled rules and put all in a per snap file <Reviewed> <Created by morphis> <https://github.com/snapcore/snapd/pull/1623> | 19:34 |
| cpaelzer | ahasenack: so you just want a link at some doc telling you more about it? | 19:34 |
| ahasenack | cpaelzer: no, I was just wondering if http://snapcraft.io/docs/snaps/metadata was outdated | 19:34 |
| qengho | ahasenack: "parts" are the parts needed to construct the package. Have a source tree somewhere? That's a part. Have some other component you need to include? That's another part. | 19:34 |
| cpaelzer | ahasenack: everything is a bit outdated as it is evolving, but not that bad - the reason is not there is just as it was a snap.yaml and not a snapcraft yaml | 19:35 |
| cpaelzer | ahasenack: https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-parts/ that would be some place to look at for parts | 19:35 |
| ahasenack | cpaelzer: cool, thanks for the explanation | 19:35 |
| qengho | ahasenack: Inside part, you need a name key that you invent, and inside that, you use some names that are part of every part, and some that are specific to the kind of part that is, which you will have indicated by the plugin needed to handle that part, like "plugin: cmake" or "plugin: go" or "plugin: autotools" or "plugin: copy" | 19:36 |
| cpaelzer | ahasenack: or rather clsoe to the link you had http://snapcraft.io/docs/build-snaps/syntax | 19:37 |
| cpaelzer | ahasenack: http://snapcraft.io/docs/build-snaps/parts | 19:37 |
| qengho | Here's a big snapcraft yaml that has a while bunch of kinds of parts needed to construct a package. | 19:38 |
| qengho | http://bazaar.launchpad.net/~privacy-squad/+junk/tor-middle-relay-snap/view/head:/snapcraft.yaml | 19:38 |
| ahasenack | nice | 19:38 |
| ahasenack | one more quick question about the docs, they show "sudo snap <command>", but I've been using it without sudo and it's working, or looks like it | 19:41 |
| ahasenack | even the tour | 19:41 |
| ahasenack | i.e., | 19:41 |
| ahasenack | $ snap install ./hello_2.10_amd64.snap | 19:41 |
| ahasenack | hello 2.10 installed | 19:41 |
| ahasenack | is that something new? | 19:41 |
| cpaelzer | ahasenack: with sudo it goes to /snap without to ~/snap | 19:41 |
| ahasenack | or am I setting myself up to fail soon? | 19:41 |
| ahasenack | ah | 19:41 |
| cpaelzer | ahasenack: depending what it is supposed to do you are prepping some pitalls -but in general it can work | 19:42 |
| cpaelzer | a (little) bit like (sudo) make install | 19:42 |
| ahasenack | hm, my ~/snap is empty | 19:42 |
| cpaelzer | to a different prefix | 19:42 |
| Ursinha | without sudo it says I have to login | 19:42 |
| Ursinha | with sudo it just works | 19:42 |
| ali1234 | right. | 19:42 |
| ali1234 | without sudo you have to log in to the snap store through U1 | 19:43 |
| Ursinha | why is that? | 19:43 |
| ali1234 | no idea | 19:43 |
| Ursinha | :) | 19:43 |
| ali1234 | ~/snap is where snaps write data | 19:44 |
| ahasenack | yeah, the user data bits | 19:44 |
| ahasenack | common and versioned | 19:45 |
| Ursinha | right, trying to understand what logging in the store has to do with local permissions, there might be an explanation I'm sure :) | 19:45 |
| ahasenack | hm, everytime I repeat "snap install ./mysnap" | 19:45 |
| ahasenack | its rev gets bumped in "snap lisT" | 19:46 |
| Ursinha | yeah | 19:46 |
| Ursinha | it installs normally and increases the count | 19:46 |
| ahasenack | ok, I remember reading somewhere that the snap version doesn't mean anything | 19:46 |
| Ursinha | xN | 19:46 |
| ali1234 | revision isnt the same as version | 19:46 |
| qengho | ahasenack: The version is defined by the developer. The revision is local to you. | 19:46 |
| ali1234 | you can install the exact same snap multiple times and each one will get a different revision | 19:46 |
| ali1234 | like literally the same .snap file | 19:47 |
| Ursinha | yeah, I did that here | 19:47 |
| ali1234 | it tends to happen a lot when you are developing | 19:47 |
| Ursinha | do you know why is that? | 19:47 |
| ali1234 | so that you can revert to the previous version | 19:47 |
| qengho | ahasenack: You will be able to set particular local revisions to be active. So, if a new install or something has trouble, you can back out. | 19:47 |
| Ursinha | ali1234: version or revision? :) | 19:48 |
| ahasenack | is there a way to list all revisions, other than ls -la /snap/<name>? | 19:48 |
| ali1234 | either. whatever you had before, you can go back to it | 19:48 |
| Ursinha | right | 19:49 |
| qengho | Ursinha: In normal, nondevelopment usage, a new version and only a new version will become a new local package revision. | 19:49 |
| Ursinha | qengho: because you wouldn't install the same snap twice? | 19:50 |
| qengho | Because you can't. | 19:50 |
| Ursinha | hm? | 19:50 |
| qengho | Ursinha: That revision will equal version. | 19:51 |
| Ursinha | maybe I'm not that far in the tour yet to know there are other "usages" | 19:51 |
| ali1234 | most of this stuff isn't even decided yet | 19:51 |
| Ursinha | ah, right | 19:52 |
| ali1234 | notice that there isn't even a 16 release yet | 19:53 |
| mup | Bug #1611094 opened: http://snapcraft.io/create/ mentions readmes in each tour subdirectory, they are missing <landscape> <Snappy:New> <https://launchpad.net/bugs/1611094> | 19:53 |
| dpb1 | Ursinha: ya, I get the same login issue you do. | 19:58 |
| dpb1 | (as non sudo) | 19:58 |
| dpb1 | did you file an issue? | 19:58 |
| Ursinha | not yet | 19:58 |
| dpb1 | Ursinha: k | 20:05 |
| Ursinha | dpb1: have you tried logging in and then without sudo? does that work? | 20:11 |
| dpb1 | hm | 20:11 |
| Ursinha | login is being difficult for me now | 20:11 |
| dpb1 | no | 20:11 |
| mup | Bug #1611098 opened: snap install tab completion lacking filenames <landscape> <Snappy:New> <https://launchpad.net/bugs/1611098> | 20:12 |
| mup | Bug #1611099 opened: snap install tab completion lacking filenames <landscape> <Snappy:New> <https://launchpad.net/bugs/1611099> | 20:12 |
| dpb1 | Can snaps work in lxd containers? | 20:24 |
| dpb1 | I got this | 20:24 |
| Ursinha | dpb1: it works after login | 20:25 |
| dpb1 | - Mount snap "ubuntu-core" ([start snap-ubuntu\x2dcore-122.mount] failed with exit status 1: Job for snap-ubuntu\x2dcore-122.mount failed. See "systemctl status "snap-ubuntu\\x2dcore-122.mount"" and "journalctl -xe" for details. | 20:25 |
| dpb1 | ah, ok | 20:25 |
| dpb1 | maybe system wide it doesn't in a lxd? | 20:25 |
| ericsnow | dpb1: I opened bug #1611078 for that | 20:25 |
| mup | Bug #1611078: could not install hello-world snap <Snappy:New> <https://launchpad.net/bugs/1611078> | 20:25 |
| dpb1 | ericsnow: ty | 20:25 |
| ericsnow | sparkiegeek: apparently LXD and snappy aren't compatible yet | 20:26 |
| dpb1 | I'll back out from the container | 20:26 |
| sparkiegeek | ericsnow: huh? wrong ping? | 20:26 |
| dpb1 | hah | 20:26 |
| ericsnow | sparkiegeek: yep :) | 20:26 |
| ericsnow | sparkiegeek: must have been thinking about you :) | 20:27 |
| sparkiegeek | ericsnow: :) | 20:27 |
| dpb1 | awww | 20:28 |
| Ursinha | qengho: do you know of any docs that would explain having to login to u1 to install snaps without sudo? | 20:32 |
| qengho | Ursinha: No. I think someone confused a permission problem with installing with a non-authorized problem with downloading restricted/paid snaps. Same exception, different uses. Maybe. | 20:34 |
| qengho | Ursinha: No need to speculate. $ ubuntu-bug snapd and say it's confusing and broken anyway. | 20:34 |
| dpb1 | :) | 20:35 |
| Ursinha | qengho: alright, checking first :) thanks for the information | 20:36 |
| stokachu | whats the proper way to copy files from one parts build dir to another parts build dir? | 20:38 |
| stokachu | right now im just copying the files into the top level directory of the snapcraft.yaml and then using the copy plugin | 20:39 |
| niemeyer | morphis: Out on a bike ride and not quite back yet, but will check for sure once back | 20:39 |
| qengho | stokachu: The "organize:" section in a part is probably best. | 20:39 |
| mup | Bug #1611108 opened: snap install without sudo asks to login to snap store <apport-bug> <i386> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1611108> | 20:57 |
| ahasenack | so build-packages is more or less like build-depends, | 21:27 |
| ahasenack | and stage-packages is like Depends | 21:27 |
| ahasenack | these "cloud" parts, are they really taken from the wiki at https://wiki.ubuntu.com/Snappy/Parts? | 21:29 |
| niemeyer | ahasenack! | 21:50 |
| ahasenack | niemeyer: hey | 21:51 |
| elopio | ahasenack: https://wiki.ubuntu.com/snapcraft/parts | 21:52 |
| ahasenack | elopio: hm, Snappy/Parts is what's in the snapcraft tutorial | 21:53 |
| niemeyer | morphis: Still around? | 21:53 |
| elopio | ahasenack: can you please report a bug? That's old. | 21:53 |
| ahasenack | elopio: https://github.com/ubuntudesign/snapcraft.io/issues/170 | 21:55 |
| elopio | thank you. | 21:55 |
| ahasenack | welcome | 21:55 |
| dpb1 | when publishing a snap, should I publish a trunk version as 'blah-snapshot', or should I use the edge/beta/etc channels to do that? | 21:58 |
| qengho | dpb1: depends on who your audience for that version is for. | 22:02 |
| qengho | Will blah ever see a stable, tagged version? | 22:03 |
| dpb1 | qengho: yes | 22:05 |
| dpb1 | thinking more about it | 22:05 |
| dpb1 | I could see people wanting to install 'edge' | 22:05 |
| dpb1 | and I would keep updating that | 22:05 |
| mup | PR snapd#1650 opened: Merge master onto #1623 to check tests <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1650> | 22:29 |
| mup | PR snapcraft#715 opened: Add artifacts option to make plugin <Created by jhobbs> <https://github.com/snapcore/snapcraft/pull/715> | 22:30 |
| blackboxsw | how does a person find a list of defined slots. I'm currently combing through examples in https://github.com/ubuntu/snappy-playpen and I know that can't be right | 22:38 |
| niemeyer | blackboxsw: $ snap interfaces | 22:40 |
| blackboxsw | cheers gustavo, that was easy, thx. | 22:40 |
| niemeyer | np! | 22:43 |
| rcj | speaking of interfaces. I'm having problems connecting a snap to an interface (I think). snapcraft.yaml is http://paste.ubuntu.com/22748234/ | 23:05 |
| rcj | running the command in the snap shows that /run/cups/cups.sock access is denied when not in devmode. | 23:06 |
| rcj | 'snap interfaces' output @ http://paste.ubuntu.com/22748234/ | 23:06 |
| rcj | (correction) 'snap interfaces' output @ http://paste.ubuntu.com/22748451/ | 23:09 |
| rcj | I know that cups-control is restricted so I attempted to connect it with 'snap connect cups-control cloudprint:cups-control' but that returns: error: cannot perform the following tasks: | 23:11 |
| rcj | - Connect :cups-control to cloudprint:cups-control (cannot connect plug "cups-control" from snap "", no such plug) | 23:11 |
| invapid | is there a default thread for compiling snap dependencies (made via cmake) | 23:19 |
| invapid | I'm seeing -j4 being used when running snapcraft, but never specified that | 23:19 |
| mup | PR snapd#1623 closed: interfaces/udev,osutil: avoid doubled rules and put all in a per snap file <Reviewed> <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1623> | 23:27 |
| mup | PR snapd#1644 closed: interfaces/builtin: add gpio interface <Reviewed> <Created by jocave> <Conflict> <https://github.com/snapcore/snapd/pull/1644> | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!