menn0I have a question about developer namespaces. can anyone help?01:52
ahoneybunsergiusens: could you share your snapcraft.yaml or update the telegram one?01:54
=== chihchun_afk is now known as chihchun
dholbachhey hey06:37
didrocksgood morning dholbach06:51
dholbachsalut didrocks06:54
zygagood morning everyone :)07:35
zygaI officially give up on reading backlog for the last three weeks07:35
dholbachzyga, break with the past! move on to new things! ;-)07:41
zygadholbach: speaking of which, https://bodhi.fedoraproject.org/updates/FEDORA-2016-0137e29c1e07:47
dholbachvery nice :)07:48
zygaSon_Goku: hey, I cannot send bodhi request for f25 for golang-github-mvo5-goconfigparser -- I keep getting http://pastebin.ubuntu.com/22671527/07:59
morphisogra_: ping08:00
morphiszyga: welcome back!08:00
zygamorphis: hey08:00
zygamorphis: I saw you made a branch for udev fix, I also made one two weeks ago08:01
zygamorphis: did your version land?08:01
morphiszyga: hope you enjoiyed your time off08:01
morphiszyga: not yet, waiting for next review round08:01
zygamorphis: yes, I really needed that :-)08:01
zygamorphis: ok, great, I'll review it today if I can; I have a huge backlog of things to do08:02
morphiszyga: thanks, niemeyer is looking at it too08:03
morphiszyga: one other thing, you remember that we talked about loading kernel modules with interfaces once connected?08:03
zygamorphis: yes, I do, some people asked about that in Leiden AFAIR08:04
morphiszyga: 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 directly08:05
=== e is now known as especiallee
morphiszyga: wanted to check with you how we implement that the right way08:07
zygamorphis: I see, I think we need both types, free-form loading from within the app process and snapd-directed loading08:07
morphiszyga: yes08:07
zygamorphis: I'll make sure to review that one08:07
zygaara: hey, long time no see :)08:07
arazyga, hey, how were the holidays?08:07
zygaara: busy :) I'm looking forward to having some peace and quiet work time :)08:08
arazyga, hehe08:08
morphisara: morning!08:09
arahey morphis :)08:09
morphiszyga: you have an idea in mind how to implemnt the snapd-directed loading?08:09
morphiszyga: we could add another security system or extend the interface API to return something like PermanentSlotKernelModules08:10
zygamorphis: 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 thing08:10
zygamorphis: I think using another security system is easier08:10
zygamorphis: the only thing we were worried about is options08:10
zygamorphis: but that all08:10
morphisyeah options might be tricky, but as we're doing specific modules here we may have to encode such a thing as attribute08:11
morphisnot free-form but something we translate08:11
zygamorphis: jdstrand was worried that some options might be too powerful for an unrestricted interface08:13
zygamorphis: anyway, I think we can solve it on a case-by-case basis08:13
morphiszyga: for now we have some well-defined use cases08:13
morphisogra_: ping08:13
=== especiallee is now known as e
didrockshey ysionneau08:28
ysionneauabout 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 socket08:34
ysionneauI 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
ysionneaubut since autopilot is already running when facedetect is not yet installed, it does not work08:35
ysionneauthe PATH does not exist yet and the socket creation fails08:35
didrocksysionneau: lool mentioned SNAP_COMMON as, contrary to SNAP_DATA, it's a fixed path for whatever version of facedetect is running08:45
didrocksbut yeah, what you told is an issue if autopilot is already running before facedetect is installed08:45
zygaysionneau: you need an interface for that08:47
zygaysionneau: you can only communicate over tcp/ip without an interface08:48
ysionneaudidrocks: ah ok goot to know, anyway I was using /current/08:50
ysionneauzyga: :(08:50
ysionneauI guess I'll end up recompiling snapd to add my interface and stuff it into ubuntu-core08:50
ysionneauI however have no idea on how to recompile snapd =)08:51
zygaysionneau: look at two links: https://github.com/zyga/devtools/ and at snapd docs (how to build)08:53
zygaysionneau: just a side note: ubuntu-image sccript in devtools is broken08:54
ysionneauok thanks08:57
ysionneauI'm not using ubuntu-image from internet anymore08:57
ysionneauI had too many issues with updates08:57
ysionneauI commited one version that works in my repository08:58
zygaysionneau: that won't work with recent snapd08:59
zygaysionneau: on the upside ubu tu image official upstream is close to making first releases08:59
ysionneauzyga: "ubu tu image", that's the real name ? :D09:13
ysionneau10:59 < zyga> ysionneau: that won't work with recent snapd < hmmm strange, I'm using an old ubuntu-image and a recent ubuntu-core :o09:14
ysionneauand it seems to work :o09:14
ogra_morphis, hey09:15
zygaysionneau: it might break at any time09:16
morphisogra_: just a quick check, your all-snap pi3 image doesn't support the onboard wifi yet, right?09:19
ogra_yeah, missing the firmware09: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
ysionneauzyga: when it will break, just updating my ubuntu-image will fix the issue?09:28
zygaysionneau: you may need to remake the image09:29
morphisogra_: any chance I can get the firmware manually in?09:30
ysionneauzyga: no problem, I remake the image each time I flash09:30
ogra_morphis, you can unsquashfs the kernel snap, add the filesw and run snapcraft snap squashfs-root09:30
ogra_then use the local kernel in u-d-f09:31
morphisyeah good idea09:31
ysionneauis this the official webdm repository (up to date?) ? : https://code.launchpad.net/~snappy-dev/snappy-hub/webdm09:31
morphisysionneau: https://github.com/snapcore/snapweb is getting the new one09:31
ysionneaumorphis: is this the current "webdm" package ? The one I can fetch by doing "sudo snap install webdm" ?09:32
morphisysionneau: not sure, all I know is that webdm gets replaced by snap-web09:33
zygaysionneau: I think the snap should be renamed to snapweb as well09:33
zygabut yes, that's the old webdm09:33
ysionneauhmm there is no "snapweb" snap in the store09:34
ysionneaubut there is "webdm"09:34
ysionneauso 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
zygaysionneau: unlikely, try github.com/snapcore/snapweb perhaps09:35
ysionneauzyga: AH ok, it's the correct repository but webdm package got renamed to snapweb09:38
* 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 snapweb09:40
ysionneauone is the "clean way", the other might be easier09:41
zygaysionneau: try my devtools09:41
zygaysionneau: you can just compile and run fresh version directly09:41
zygaysionneau: no rebuilding of any snaps required09:41
zygaysionneau: see the docs there09:41
zygaysionneau: that's *the* purpose of devtools, rapid interface development09:42
ysionneauzyga: I kind of get used to that :p09:43
ysionneauah sorry was replying to something else09:43
ysionneauso, I recompile snapd and I push it via  refresh-bits ?09:44
zygaysionneau: refresh bits does all, just see what it does09:44
zygaysionneau: refresh-bits setup snap snapd run-snapd restore09:45
zygaysionneau: with --host if needed09:45
zygaysionneau: read the source, it's very easy to follow09:45
zygaysionneau: note that run-snapd blocks, ctrl-c it to continue09:45
ogra_cjwatson, bug 1610916 for you ...09:46
mupBug #1610916: s390x snap builds on launchpad fail with no build log <launchpad-buildd:New> <https://launchpad.net/bugs/1610916>09:46
pmpzyga: on debian-testing there is no systemd-activate - needed by refresh-bits10:00
looldidrocks: heya10:05
loolysionneau: and hi10:05
didrockshey lool10:06
zygapmp: I heard, any chance on how to trigger socket activation now?10:08
pmpzyga: I don't know much about systemd... sry10:13
pmpzyga: Plus I'm cross-compiling (well I try to)10:14
zygapmp, no worries, thanks for letting me know10:15
kaisozHi there!10:18
=== hikiko is now known as hikiko|ln
cjwatsonogra_: Can you try an s390x build again?10:58
cjwatsonogra_: Firewall should be fixed, though there's still the exception-handling bug10:59
=== chihchun is now known as chihchun_afk
ogra_cjwatson, triggered10:59
ogra_that looks better11:00
cjwatsonYou haven't hit the previous failure yet11:00
ogra_ah, i thought the build didnt even start the last time11:00
cjwatsonOh, maybe11:00
cjwatsonNo, I think it started, but it crashed in such a way as to leave no log11:01
cjwatsonSo you wouldn't know unless you happened to be watching it11:01
ogra_ah, k11:01
cpaelzerjust to check - anybody else working on a waf plugin (https://github.com/waf-project/waf) ?11:03
cpaelzerI need that to try ntpsec, but wanted to avoid too much collisisons so I thought I poll for others that might work on it11: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 imho11: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 why11:12
ogra_clicking the upload button manually uploads it fine ... strange11:14
ogra_geez ...11:20
ogra_Launchpad uploaded this snap package to the store, but the store failed to11:20
ogra_scan it:11:20
ogra_  A file with this exact same content has already been uploaded11:20
ogra_why did it tell me about the 404 error then ... :P11:20
cjwatsonogra_: proposed> please file a bug; I think I probably agree but doing anything about that will be a bit complicated11:20
ogra_cjwatson, will do11:20
cjwatson[2016-08-08 11:11:45,875: DEBUG/Worker-1] "POST /dev/api/snap-push/ HTTP/1.1" 202 None11: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 such11: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 None11:22
cjwatsonI 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
cjwatsonI 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 fault11:23
ogra_i think i actually saw a bug fly by about the 404 error ...11:23
cjwatsonAh, right, because the 404 meant we thought it was retryable even though it actually wasn't.11:23
* ogra_ digs his bugmail11:23
dz0nycpaelzer: https://github.com/ubuntu/snappy-playpen/blob/master/mpv/parts/plugins/x-waf.py but it's very optiniated11:24
ogra_looks like bug 157296311:26
mupBug #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 least11:28
ogra_ah, because the original description was changed ... https://bugs.launchpad.net/snapcraft/+bug/1572963/comments/0 pretty much describes what i see11:30
mupBug #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 people11:52
mupBug #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
cpaelzerdz0ny: 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 snapcraft12:03
=== JanC is now known as Guest57323
=== JanC_ is now known as JanC
pmpzyga: I issued a pull-request for devtools, not sure if it is ok for all platforms - please review12:18
pmpzyga: I could cross-compile snapd with these changes on debian testing.12:18
pmpzyga: at least that what I think I did ;-)12:19
Son_Gokuzyga, f25 hasn't been bodhi activated yet12:25
Son_Gokubranching and the bodhi activation point are two different times12:25
Son_Gokuzyga: https://fedoraproject.org/wiki/Releases/25/Schedule12:26
Son_GokuBodhi activation is tomorrow12:26
Son_Gokuif everything makes it in today, we don't have to worry about bodhi for f2512:26
mupPR snapd#1648 opened: overlord,store: set store device authorization header <Created by matiasb> <https://github.com/snapcore/snapd/pull/1648>12:29
zygapmp: thanks, will do12:30
zygaSon_Goku: yep, I learned about that since asking :)12:30
zygaSon_Goku: I had a look at gettext but I was busy writing a blog post about snap-confine12:31
zygaSon_Goku: I cannot see anything wrong but I didn't check all of my email yet12:31
kaisozHi again12:41
Son_Gokuzyga, the issue with gettext is that there's a file that says it imports go-flags13:02
Son_Gokubut for whatever reason, it's not a dependency in gettext13:02
Son_Gokuzyga, the go-xgettext code uses it13:04
Son_Gokuactually, now I realize the thing13:05
Son_Gokugo-xgettext is an example program, isn't it?13:05
ogra_jdstrand, are you around today ?13:06
sergiusensogra_ the uploads from launchpad are driven by launchpad using the store api and not involving snapcraft at all13:06
sergiusensI'll make a note on the bug13:07
ogra_sergiusens, thanks, feel free to invalidate it then13:07
ogra_(teh snapcraft task)13:07
Son_Gokuzyga, actually, it looks like you need to add go-flags as a BR at least because it's used during the %check section13:07
morphisogra_: you know directly which firmware files are missing?13:09
zygaSon_Goku: look now13:09
ogra_morphis, not from the top of my head ... i think ppisati already packaged it though ... in his embedded ppa13:09
zygaSon_Goku: go-xgettext is a real xgettext replacement for golang sources13:10
zygaSon_Goku: it's a tool though you don't have to use it13:10
zygaSon_Goku: the advantage over *gettext is that it parsers go code with go itself13:10
morphisogra_: I see, thanks13:10
zygaSon_Goku: so it is more reliable13:10
Son_Gokudoes it conflict with system gettext?13:10
Son_Gokuif not, why not slightly adjust the package so that it builds it and makes it available?13:11
Son_Gokupeople might want to use it13:11
zygaSon_Goku: no, the binary is separate13:11
zygaSon_Goku: hmm, didn't I do exactly that? (me checks)13:11
Son_Gokuyou don't13:11
zygaI probably did that in suse13:11
Son_Gokuyeah, probably13:12
zygasorry, I'll copy that change13:12
Son_Gokuokay, cool13:12
Son_Gokube sure to update the bug with a comment indicating new changes, link the new srpm, and link to spec13:12
zygayep, I'll do exactly13:12
Son_Gokuonce you've done that, I can approve the package and you can push it13:13
Son_Gokuafter I take a look at it, of course :P13:13
zygayep, just looking at the suse version of the package to compare13:14
zygagofed makes it a bit noisy13:14
Son_Gokugofed was designed to automate packaging and updating golang libraries13:15
Son_Gokuas very early on, it looked like golang was going to turn into the same mess nodejs is with npm13:15
Son_Gokuit 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 unusual13:16
Son_Gokubut it does make the process simpler13:16
morphisogra_: also it looks like the pi3 doesn't get an IP address on subsequent boots13:27
ogra_morphis, do you see an entry for the NIC in /etc/network/interfaces.d ?13:27
morphisneed to pull the sdcard, sec13:28
ogra_iirc there is still an issue with the firstboot job that doesnt always create the setup13:28
morphisI see the greenlight continously blinking13:28
ogra_well, what do you see on the serial console ? :)13:28
morphisdon't have one connected13:28
morphisbut there is a e/n/i.d file13:29
ogra_then it shold also get the NIC up13:29
morphisogra_: we're using predictable network iface names now?13:29
ogra_are you sure it is the NIC itself or just i.e. ssh13:29
ogra_we set net.ifnames=0 on the kernel cmdline ...13:30
ogra_which should prevent "predictable" names13:30
morphisI get enxb827eb0c621b as eth name13:31
morphisogra_: no, its the NIC13:31
ogra_then i guess there iis a bug with the net.ifnames=0 recognition somewhere13:32
morphisotherwise nmap would find the host as up13:32
ogra_(which i fear needs pitti input ... who is on vac.)13:32
ogra_for the moment you can mv the eth0 file to the right name13:33
ogra_that should get you up and running13:33
zygathe user experience of fedpkg vs using rpm* directly is staggering13:33
zygamost of the stuff that is annoying is fixed by fedpkg13:34
ogra_hmm ... so i wonder if https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2575 will actually work now13:34
zygabut you cannot use it before you get the database updated :)13:35
cpaelzerI 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
kalikianaThere's a bug for that13:37
ogra_that will also onlly work on classic installs ...13:38
kalikianaSpecifically bug 157559313:38
mupBug #1575593: Snappy installed manpages aren't accessible through man <Snappy:New> <ubuntu-snappy (Ubuntu):Confirmed> <https://launchpad.net/bugs/1575593>13:38
kalikianaogra_: 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
cpaelzerthanks 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 image13:40
Son_Gokuzyga, the only thing I use rpmbuild for is making the SRPM13:42
Son_Gokueverything else is done with mock or fedpkg13:42
kalikianaUsing 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 binary13:42
ogra_neither is available in ubuntu-core13:42
ogra_and we will definitely not add it13:43
ogra_(since the ubuntu-core snap is still megabytes to big)13:43
kalikianaogra_: 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 snap13:44
ogra_that requires some interaction between snaps that we dont have today13:44
ogra_not saying it is impossible, but the interface you would need would be pretty complex13:45
kalikianaThe 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
kalikianaUnless the store would extract man pages.13:46
camakotrying 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 sane13:46
camakoany idea what might be the problem?13:46
kalikianaThinking about it, maybe I should snap that script13:48
cpaelzerogra_: kalikiana: thanks for the discussion - I subscribed to the bug and will think about it a bit as well13:49
cpaelzerogra_: 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 up13: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
argesjdstrand: hi13:50
cpaelzerogra_: sad but true, thanks for keeping the confinement thought up13:50
ogra_you actually need an interface i think13:51
jdstrandarges: hey13:53
jdstrandogra_: yes13:54
argesjdstrand: 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
mupPR 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
jdstrandarges: no. what are the permissions of the file from within the snap?13:55
argesjdstrand: is there a simple way to check this.. i know there was a wrapper script at some point?13:55
jdstrandogra_: 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 snaps13:56
ogra_jdstrand, https://myapps.developer.ubuntu.com/dev/click-apps/4142/13:57
jdstrandogra_: ack, I'll take a look and handle all that13:57
ogra_thanks !13:57
jdstrandarges: 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 whatever13:59
jdstrandarges: that's a handy method for testing. you can drive your other commands within confinement and iterate a bit easier13:59
argesjdstrand: 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 it14:00
jdstrandthere's another way that I know people have talked about. snap try or snap shell I think-- I don't know if those are implemented14:00
argesjdstrand: ack i'll poke around and see what i can find. thanks14:01
jdstrandarges: I'm not 100% sure that is an exact runtime environment with try or shell14:01
didrocksjdstrand: 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
didrocksI can use SNAP_COMMON + make it +w for everyone, but other opinions would be welcomed14:09
didrocks(both ends are from the snap)14:09
zygadidrocks: I'd use /run14:09
zygadidrocks: one sec, let me check the template14:10
mhall119didrocks: dholbach: do we have a snapcraft plugin for ant?14:10
didrockszyga: ah, they are common between apps from the same snaps?14:10
didrocksmhall119: there is on built-in, yeah14:10
didrocksmhall119: btw, snapcraft list-plugins :)14:10
zygadidrocks: yes though run may not be what you want14:10
zygadidrocks: also I should hit a publish button14:11
mhall119didrocks: nice, thanks!14:11
didrockszyga: ;) well, we do use /run for this kind of socket communication on traditional desktop14:11
didrocksmhall119: yw!14:11
zygadidrocks: http://www.zygoon.pl/2016/08/snap-execution-environment.html14:11
zygafresh off my todo list14:11
zyganow let me check that run for you14:11
didrocksthanks! I think there is a pattern like /run/snap.<snapname> something in the apparmor profile14:12
* didrocks reads the new blog post14:12
mhall119sergiusens: when will snapcraft let me set envvars for a snap? That's blocking a few that are otherwise upstreamable14:13
zygadidrocks: it's not in the default template14:13
zygadidrocks: that's something we should consider improving14:13
didrockszyga: oh? indeed, sounds like it should be there14:13
zygamhall119: when new snapd allows this, it's almost complete on this side14:13
zygadidrocks: I agree, I'll talk to jdstrand about this14:13
mhall119zyga: oh, I thought it was just going to inject them into the generated wrapper14:14
=== wililupy is now known as wililupy|travel
zygamhall119: I think that this falls under 'sensible defaults' as long as it doesn't allow IPC14:15
zygamhall119: (across the snap boundary)14:15
zygamhall119: similar to how we allow /dev/shm/...   /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix,14:15
zygamhall119: for cross snap IPC you always need an interface14:16
mhall119uh, I just was to set SQLITE_TMPDIR=/tmp14:16
argesjdstrand: 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
didrocksmhall119: I guess zyga was talking to me :)14:16
mhall119I hope so :)14:16
* zyga needs to get his blog federated on planet arch linux14:16
argesjdstrand: any suggestions for making this work with snap/snapcraft?14:16
zygaarges: 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 execute14:17
argeszyga: i'm trying to debug a daemon, and jdstrand suggested trying things as bash. So I'm trying to debug from the daemon perspective14:18
argesadding 'bash -u root' to the command doesn't work, so trying to figure it out14:18
jdstrandarges: use the same plugs and execute 'sh' under sudo14:19
jdstrandarges: a few env variables aren't going to be the same but that should be good enough14:19
argesjdstrand: 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
jdstranddidrocks, zyga: /run/shm/snap.$SNAP_NAME.** is in the default template and can be used for cross-app communications, but not cross-snap communications14:21
didrocksexcellent, exactly what I wanted!14:21
jdstrandarges: sudo /snap/bin/your-thing.sh14:21
didrocksthanks jdstrand14:21
argesjdstrand: ok. using that i am able to read /proc/version_signature  ... hmm14:22
jdstrandarges: 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
jdstrandarges: if they are, then you might look at systemd to see if it is doing anything weird with /proc that it maybe shouldn't be14:25
jdstrandarges: 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
argesjdstrand: well it works running without snappy fwiw14:28
argesi'll check the above14:28
cpaelzerzyga: thanks for that blog series btw - really providing some extra insights once through the usual entry docs14:28
argesjdstrand: no diff except for profile name.14:31
zygacpaelzer: my pleasure, feel free to send me suggestions14:35
zygajdstrand: hey, long time no see, how are you doing14:35
zygajdstrand: 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
mupPR snapcraft#713 opened: rust plugin: mock downloads in unit tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/713>14:39
jdstrandzyga: we do offer /run/snap.$SNAP_NAME.**. look at template.go14:46
jdstrandzyga: oh sorry, I thought you meant /run/shm14:47
jdstrandzyga: 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_NAME14:48
jdstrandso I suspect it won't really help anything, but if it makes things easier, I'm fine with it14:49
ogra_ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/writable/system-data/snap/pi2-kernel/14:49
ogra_why does u-d-f not like me !14:49
zygajdstrand: I did check template.go, I just missed it among the {/dev,} variants14:50
jdstrandarges: 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
jdstrandzyga: well, it doesn't help that /run/shm/$SNAP_NAME.** and /run/snap.$SNAP_NAME.* look pretty similar when reading quickly :)14:51
zygajdstrand: FYI: http://www.zygoon.pl/2016/08/snap-execution-environment.html :)14:51
jdstrandzyga: 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 above14:51
jdstrandzyga: nice! /me reads14:52
zygayes, I wonder about this myself, some of the apps would probably happily switch to /var/snap.$SNAP_NAME14:52
zygabut perhaps not all and this is a tricky subject14:52
jdstrandI mean, we can allow it14:52
zygaI'd perhaps offer /run/$SNAP_NAME.* directly14:52
jdstrandit's fine from an application isolation perspective14:52
zygabecause snap names are something that can be managed separately14:52
jdstrandthat is not fine14:52
jdstrandneed snap.14:53
jdstrandor an interface14:53
sergiusensmhall119 as soon as I can get to it; probably 2.1514:53
zygawhat's the difference betwen /run/$SNAP_NAME and /run/snap.$SNAP_NAME?14:53
jdstrandcause people will create an 'acpid' snap and be allowed to create /run/acpid.socket and wreack havoc14:53
zygaacpid should be reserved for other reasons14:54
jdstrandit's all the same arguments for why we have snap. prefixed everywhere already14:54
zygaand if and when it is a genuine snap, why wouldn't it be ok to access?14:54
jdstrandntpd? docker? lxd? ekeyd? etc etc14:54
zygadocker, for sure!14:54
zygathink about it14:55
jdstrandsnap.$SNAP_NAME is ok by default. $SNAP_NAME needs an interface14:55
zygaif you own docker name, docker executable name, etc14:55
zygawell, /run won't be available to anyone outside of the snap14:55
ogra_that makes you non-evil ?14:55
zygaI totally agree about cross-snap IPC14:55
jdstrandwe are mounting /run separate too?14:56
jdstrandthat is going to be really complicated for cross-snap stuff14:56
zygajdstrand: because $various_projects use /run/$SNAP_NAME already14:56
zygaah, I see14:56
zygaI was just curious14:56
jdstrandI think we should avoid bind mounts except where absolutely necessary and stay in the global namespace14:57
mupPR 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
jdstrandwe are already seeing lots of complications with what we are doing and they are only going to get more complicated14:57
jdstrandcause then there is ordering, uninstalls are problematic, etc, etc14:58
zygajdstrand: I don't think we'll get many more non-interface-specific bind mounts14:58
jdstrandI 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 sense14:59
jdstrandso, 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 page15:00
zygajdstrand: agreed15:01
* zyga -> break15:03
jdstrandzyga: 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
zygajdstrand: I did mention snappy-debug but not any details15:07
jdstrandah, I see that now15:07
zygajdstrand: I decided not to mention scmp_sys_resolver because it is geeky and doesn't win much15:07
jdstrandI didn't get that far yet15:07
zygajdstrand: :-)15:07
zygajdstrand: I'll probably upload syscall snap to the store that resolves syscall numbers across architectures15:07
jdstrandzyga: note, apparmor cannot check system call arguments15:07
jdstrandzyga: that is for seccomp (and not necessarily for the article, only integers, not structs, etc)15:08
zygajdstrand: ah, so the fact that you can open /foo is implemented as LSM check in the VFS, not on open itself?15:08
jdstrandzyga: correct15:08
cpaelzera daemon: forking snap should automatically get some sort of generated systemd service that one can check right?15:08
zygajdstrand: I know about the seccomp not reading userspace memory15:08
* cpaelzer searches the hiding systemd unit15:09
ogra_cpaelzer, yeah, snapd creates it at install time ... it gets prefixed with snap.*15:09
zygajdstrand: I really wonder how apple's sandboxd works now15:09
zygajdstrand: anyway, noted, thank you for being precise15:09
jdstrandthere 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 example15:09
ogra_(as long as you defined it in your "app:" entry in snapcraft.yaml)15:10
cpaelzerogra_: it is in the app entry I'd have expected snap.ntpd for this http://paste.ubuntu.com/22698736/15:10
jdstrandzyga: I suggest s/ulted at the same points so doesn't15:11
jdstrandzyga: strike that-- bad paste15:11
ogra_cpaelzer, try: snap-ntpsec.ntpd.service15:12
ogra_or some such15:12
jdstrandzyga: I suggest: s/system call arguments/traditional UNIX IPC like signals and sockets,/15:12
jdstrandzyga: 2 cents15:12
ogra_cpaelzer, systemctl | grep ntp15:12
cpaelzerobviously :-) thanks why didn't I just search that way :-)15:12
ogra_oh, actually snap.ntpsec.ntpd.service15:12
ogra_(sorry, typoed that)15:13
zygajdstrand: updated :)15:14
* zyga -> really ADFK15:14
mupPR 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
mupPR 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
mupPR 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
mupPR 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
jdstrandniemeyer: hi! fyi, https://github.com/snapcore/snapd/pull/1409#issuecomment-23826942915:31
mupPR snapd#1409: docs/interfaces.md: improve interfaces documentation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1409>15:31
jdstrandniemeyer: basically an integration test is failing that is unrelated to the PR15:31
jdstrandniemeyer: also as fyi, I got the PR pings for other stuff and will take a look a bit later15:33
john-mcaleelyogra_, how long do you expect it to take for an rpi3 to boot all-snaps image? it seems to be aaaageeess15:39
qengho10 minutes?15:39
ogra_john-mcaleely, around 1-2 mins for the first boot15:39
ogra_subsequent ones take aless15:39
john-mcaleelyhmm, more like 15 so far. green led blinking. raspberries just disappeared15:40
john-mcaleelywill let you know if it completes15:40
john-mcaleelyI assume I get a login prompt?15:40
ogra_note that it only boots to serial console15:40
cpaelzersince 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-mcaleelyogra_, 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 though15:41
john-mcaleelyogra_, 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 breed15:42
john-mcaleelyogra_, yours indeed: http://people.canonical.com/~ogra/snappy/all-snaps/15:43
ogra_yeah, that should boot ... it dpoes at least on serial15:43
ogra_( i always test the early builds with serial and eth attached)15:44
john-mcaleelyok, I need to rummage for a serial port then15:44
qenghojohn-mcaleely: Is there a change in eth status?15:44
john-mcaleelylights, sure15:44
john-mcaleely(on the eth)15:44
qenghojohn-mcaleely: I think you can change the boot config files to make it try hdmi.15:45
ogra_qengho, seems we are suffering from a systemd bug ... i.e. net.ifnames=0 isnt respected anymore all of a sudden15:45
ogra_so there wont be any config15:45
qenghoOh 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 card15:46
ogra_that should redirect output to the LCD so you can debug without serial cable15:46
john-mcaleelyogra_, aha, ok I will rummage there!15:46
john-mcaleelythank you!15:47
argesjdstrand: ok figured it out. I forgot to restart the daemon after connecting it.15:47
arges* connecting the interfaces that is15:47
* qengho still wishes for image build bots. pi2, pi3, pandaboard, etc. Built nightly if any change.15:48
argesI'm guessing that restarting it reloads the apparmor profile?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 packages15:50
qenghoogra_: 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
stgraberjdstrand: 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 filesystem15:52
mupPR snapd#1598: interfaces: implement a fuse interface <Reviewed> <Created by stgraber> <https://github.com/snapcore/snapd/pull/1598>15:52
mupPR 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 PPA15:58
jdstrandstgraber: it's on my todo for later today16:00
sborovkovogra_: 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_note that this is all still experimental16:06
stgraberjdstrand: cool, thanks16:07
sborovkovogra_: ah cool, so it's out. missed that16:09
ogra_sborovkov, nothing is out ... it is really highlly experimental still and will likely stay so for a while16:10
sborovkovBut it was the same before, was not it? )16:10
ogra_since we started on series 1616:11
mupPR snapd#1649 opened: store: minor store improvements from previous reviews <Created by matiasb> <https://github.com/snapcore/snapd/pull/1649>16:20
john-mcaleelyogra_, so, adding tty0 got output on screen. It's to a busbox prompt, which is a surprise16:21
ogra_yeah, that sounds messed up16:21
john-mcaleelylast line of log above is 'no init found. try passing init= bootarg'16:21
ogra_yeah, thats useless16:21
ogra_the actual error is lines above16:22
ogra_most likely scrolled off screen ...16:22
john-mcaleelyright. looks that way. i have a screen full of errors16:22
john-mcaleelyI will set up a UART so these things are captureable16:22
ogra_(this is where you actually need serial to capture the logs)16:22
john-mcaleelyodd though - I assumed my pi3 was a standard object...16:22
ogra_well, you are testing the very first experimental image for a new setup16: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-mcaleelymy pi is silkscreened 'Raspberry Pi 3 Model B V1.2'16:24
ogra_well, it should just work16:24
john-mcaleelyas always!16:25
ogra_but there can be bugs where a failed firstboot setup eats your filesystem and such stuff16:25
=== matiasb1 is now known as matiasb
ogra_try a fresh flash and edit the cmdline.txt before the first boot16:25
john-mcaleelyhmm. now I know the tty0 trick, let me see what a fresh sd card does with just that change16:25
ogra_snappy !!16:25
ogra_schnaps !16:26
niemeyerjdstrand: Sweet, thanks!  Want to try getting some of those interfaces handled today16:28
* ogra_ sighs ... something is really wrong with either u-d-f or our new kernel spec16:29
mupPR 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-mcaleelyogra_, fyi. it's alive! logged in, and installed hello-world16:38
ogra_did the NIC come up properly OOTB ?16:38
john-mcaleelyshould 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
ogra_it will come back once the images have stabilized :)16:38
mupPR 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-mcaleelysometimes I wonder if anyone wants us to use this stuff. I shall sign off for the day16:39
ogra_well, that is what "experimental" means :)16:39
john-mcaleelyit's a long word for 'broken' ;-016:40
ogra_we are still developing these images ... everything will change16:40
ogra_and for development we need the defaulting to serial16:40
john-mcaleelyI get that. in the mean time I need to pass a hardware hazing ritual (install a uart) in order to follow along16:40
john-mcaleelyI'm a software dude, and snappy is cool software16: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 example16:41
ogra_nothing is stable there yet16:41
john-mcaleelyI understand and expect that part16:41
ogra_so even if you try your SW on it ... take everything with a grain of salt16:42
qenghoWeird 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 day16:43
ogra_note that we can not use the rpi bootloader16:43
ogra_(only as jumpstart thing )16:43
john-mcaleelyanyway, thanks for the help ogra_. As you say, I'm now up and playing16:44
john-mcaleelyI will expect breakage16:44
ogra_tell me about it if you hit it16:44
niemeyerjoc_: snapd#1644 is ready for some love16:49
mupPR snapd#1644: interfaces/builtin: add gpio interface <Reviewed> <Created by jocave> <Conflict> <https://github.com/snapcore/snapd/pull/1644>16:49
niemeyerjoc_: With that plus jdstrand's security review, we can land this16:49
niemeyermorphis: ^16:49
joc_niemeyer: thanks, i'll get on those comments16:50
argesI'm getting integration test failures that I don't think are caused by my PR... is this a known issue?16:57
mupPR 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
argesjdstrand: ^^^ not sure if you are the one who knows about this stuff. still having fun with https://github.com/snapcore/snapd/pull/160217:14
mupPR snapd#1602: interfaces: add kernel-module interface for module insertion <Created by arges> <https://github.com/snapcore/snapd/pull/1602>17:14
mupBug #1611063 opened: can't mkdir SNAP_USER_COMMON directory <Snappy:New> <https://launchpad.net/bugs/1611063>17:34
blackboxswhmmm peeking around the cmdline snap tool docs, what is a snap assertion. cmdline help is slightly lacking about the intent17:47
jdstrandarges: 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 you18:05
argesjdstrand: ok thanks18:05
ahasenackdoes the name of the slot have to match the name of the plug? Or all we care about is the interface name?18:14
ahasenackbecause the example on snapcraft.io (front page) uses "db" for A, and "database" for B18:14
mupBug #1611078 opened: could not install hello-world snap <Snappy:New> <https://launchpad.net/bugs/1611078>18:41
blackboxswso, 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
blackboxswhttp://snapcraft.io/create/ is the reference page I'm using18:41
ahasenackI was also wondering about ppas for a more up-to-date version18:42
blackboxswyeah, it'd be nice to document that at the top  (whatever the solution is)18:42
ahasenackthe instructions on snapcract.io prefix every command with sudo, but that doesn't seem needed anymore18:42
dpb1_you should just create a snap for it18:42
ahasenackand snap find doesn't have the --broad option the docs talk about18:42
ahasenackblackboxsw: I got 2.11 from xenial-updates18:45
ahasenackah, snapcraft18:45
ahasenackblackboxsw: I have snapcraft 2.13.1 from xenial-updates/universe18:45
blackboxswtrying apt-get update18:46
ahasenackblackboxsw: you don't seem to have xenial-updates for universe enabled18:46
mupBug #1611080 opened: snapcraft.io says snap find has --broad, but it doesn't <Snappy:New> <https://launchpad.net/bugs/1611080>18:47
blackboxswyeah I'm adding the source now18:47
mupBug #1611083 opened: Users without xenial-updates/universe can't get snapcraft  version 2.11 tour. <Snappy:New> <https://launchpad.net/bugs/1611083>18:56
morphisniemeyer: great, lets wait for jdstrand_ then19:20
stokachuhow do i include files from my parts/build?19:21
ahasenackthe "parts:" key shown in the first snapcraft example isn't described in http://snapcraft.io/docs/snaps/metadata19:29
ahasenackare these things out of date? Too old or too new?19:29
qenghoahasenack: The docs are ancient and so is "parts:".19:30
qenghoahasenack: What do you want to know?19:30
ahasenackwhat you just said, "docs are ancient" :)19:30
ahasenacki.e., want to know what to trust19:31
ahasenackshould I file a bug?19:31
cpaelzerisn't this just metadata vs snapcraft yaml content?19:31
ahasenackthis is a first-journey type of thing19:31
qenghoahasenack: Sure.19:31
cpaelzerparts is part of the snapcraft yaml19:31
cpaelzerand there it is fine and current IIRC19:31
ahasenackso snapcraft.yaml is like snap.yaml plus snapcraft specific things?19:32
cpaelzerand 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 parts19:32
qenghoahasenack: 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
cpaelzerahasenack: snapcraft will build the snap and its metadata - so snapcraft yaml has some similar content - but it is not just like a superset19:32
ahasenackcpaelzer: ah, I see19:33
qenghoahasenack: You should be writing for snapcraft. That is the human end of making a package.19:33
qenghoahasenack: All the rest of the details, you shouldn't care about.19:33
cpaelzerand as a first journey I'd recommend the tour19:33
cpaelzerahasenack: http://snapcraft.io/create/19:33
ahasenackit's where I am at now, that's where I saw this new "parts:" key19:33
morphisniemeyer: can you give https://github.com/snapcore/snapd/pull/1623 another round?19:34
mupPR 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
cpaelzerahasenack: so you just want a link at some doc telling you more about it?19:34
ahasenackcpaelzer: no, I was just wondering if http://snapcraft.io/docs/snaps/metadata was outdated19:34
qenghoahasenack: "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
cpaelzerahasenack: 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 yaml19:35
cpaelzerahasenack: https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-parts/ that would be some place to look at for parts19:35
ahasenackcpaelzer: cool, thanks for the explanation19:35
qenghoahasenack: 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
cpaelzerahasenack: or rather clsoe to the link you had http://snapcraft.io/docs/build-snaps/syntax19:37
cpaelzerahasenack: http://snapcraft.io/docs/build-snaps/parts19:37
qenghoHere's a big snapcraft yaml that has a while bunch of kinds of parts needed to construct a package.19:38
ahasenackone 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 it19:41
ahasenackeven the tour19:41
ahasenack$ snap install ./hello_2.10_amd64.snap19:41
ahasenackhello 2.10 installed19:41
ahasenackis that something new?19:41
cpaelzerahasenack: with sudo it goes to /snap without to ~/snap19:41
ahasenackor am I setting myself up to fail soon?19:41
cpaelzerahasenack: depending what it is supposed to do you are prepping some pitalls  -but in general it can work19:42
cpaelzera (little) bit like (sudo) make install19:42
ahasenackhm, my ~/snap is empty19:42
cpaelzerto a different prefix19:42
Ursinhawithout sudo it says I have to login19:42
Ursinhawith sudo it just works19:42
ali1234without sudo you have to log in to the snap store through U119:43
Ursinhawhy is that?19:43
ali1234no idea19:43
ali1234~/snap is where snaps write data19:44
ahasenackyeah, the user data bits19:44
ahasenackcommon and versioned19:45
Ursinharight, trying to understand what logging in the store has to do with local permissions, there might be an explanation I'm sure :)19:45
ahasenackhm, everytime I repeat "snap install ./mysnap"19:45
ahasenackits rev gets bumped in "snap lisT"19:46
Ursinhait installs normally and increases the count19:46
ahasenackok, I remember reading somewhere that the snap version doesn't mean anything19:46
ali1234revision isnt the same as version19:46
qenghoahasenack: The version is defined by the developer. The revision is local to you.19:46
ali1234you can install the exact same snap multiple times and each one will get a different revision19:46
ali1234like literally the same .snap file19:47
Ursinhayeah, I did that here19:47
ali1234it tends to happen a lot when you are developing19:47
Ursinhado you know why is that?19:47
ali1234so that you can revert to the previous version19:47
qenghoahasenack: 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
Ursinhaali1234: version or revision? :)19:48
ahasenackis there a way to list all revisions, other than ls -la /snap/<name>?19:48
ali1234either. whatever you had before, you can go back to it19:48
qenghoUrsinha: In normal, nondevelopment usage, a new version and only a new version will become a new local package revision.19:49
Ursinhaqengho: because you wouldn't install the same snap twice?19:50
qenghoBecause you can't.19:50
qenghoUrsinha: That revision will equal version.19:51
Ursinhamaybe I'm not that far in the tour yet to know there are other "usages"19:51
ali1234most of this stuff isn't even decided yet19:51
Ursinhaah, right19:52
ali1234notice that there isn't even a 16 release yet19:53
mupBug #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
dpb1Ursinha: ya, I get the same login issue you do.19:58
dpb1(as non sudo)19:58
dpb1did you file an issue?19:58
Ursinhanot yet19:58
dpb1Ursinha: k20:05
Ursinhadpb1: have you tried logging in and then without sudo? does that work?20:11
Ursinhalogin is being difficult for me now20:11
mupBug #1611098 opened: snap install tab completion lacking filenames <landscape> <Snappy:New> <https://launchpad.net/bugs/1611098>20:12
mupBug #1611099 opened: snap install tab completion lacking filenames <landscape> <Snappy:New> <https://launchpad.net/bugs/1611099>20:12
dpb1Can snaps work in lxd containers?20:24
dpb1I got this20:24
Ursinhadpb1: it works after login20: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
dpb1ah, ok20:25
dpb1maybe system wide it doesn't in a lxd?20:25
ericsnowdpb1: I opened bug #1611078 for that20:25
mupBug #1611078: could not install hello-world snap <Snappy:New> <https://launchpad.net/bugs/1611078>20:25
dpb1ericsnow: ty20:25
ericsnowsparkiegeek: apparently LXD and snappy aren't compatible yet20:26
dpb1I'll back out from the container20:26
sparkiegeekericsnow: huh? wrong ping?20:26
ericsnowsparkiegeek: yep :)20:26
ericsnowsparkiegeek: must have been thinking about you :)20:27
sparkiegeekericsnow: :)20:27
Ursinhaqengho: do you know of any docs that would explain having to login to u1 to install snaps without sudo?20:32
qenghoUrsinha: 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
qenghoUrsinha: No need to speculate.  $ ubuntu-bug snapd  and say it's confusing and broken anyway.20:34
Ursinhaqengho: alright, checking first :) thanks for the information20:36
stokachuwhats the proper way to copy files from one parts build dir to another parts build dir?20:38
stokachuright now im just copying the files into the top level directory of the snapcraft.yaml and then using the copy plugin20:39
niemeyermorphis: Out on a bike ride and not quite back yet, but will check for sure once back20:39
qenghostokachu: The "organize:" section in a part is probably best.20:39
mupBug #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
ahasenackso build-packages is more or less like build-depends,21:27
ahasenackand stage-packages is like Depends21:27
ahasenackthese "cloud" parts, are they really taken from the wiki at https://wiki.ubuntu.com/Snappy/Parts?21:29
ahasenackniemeyer: hey21:51
elopioahasenack: https://wiki.ubuntu.com/snapcraft/parts21:52
ahasenackelopio: hm, Snappy/Parts is what's in the snapcraft tutorial21:53
niemeyermorphis: Still around?21:53
elopioahasenack: can you please report a bug? That's old.21:53
ahasenackelopio: https://github.com/ubuntudesign/snapcraft.io/issues/17021:55
elopiothank you.21:55
dpb1when 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
qenghodpb1: depends on who your audience for that version is for.22:02
qenghoWill blah ever see a stable, tagged version?22:03
dpb1qengho: yes22:05
dpb1thinking more about it22:05
dpb1I could see people wanting to install 'edge'22:05
dpb1and I would keep updating that22:05
mupPR snapd#1650 opened: Merge master onto #1623 to check tests <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1650>22:29
mupPR snapcraft#715 opened: Add artifacts option to make plugin <Created by jhobbs> <https://github.com/snapcore/snapcraft/pull/715>22:30
blackboxswhow 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 right22:38
niemeyerblackboxsw: $ snap interfaces22:40
blackboxswcheers gustavo, that was easy, thx.22:40
rcjspeaking of interfaces.  I'm having problems connecting a snap to an interface (I think).  snapcraft.yaml is http://paste.ubuntu.com/22748234/23:05
rcjrunning 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
rcjI 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
invapidis there a default thread for compiling snap dependencies (made via cmake)23:19
invapidI'm seeing -j4 being used when running snapcraft, but never specified that23:19
mupPR 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
mupPR 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!