[00:09] <tyhicks> jdstrand: circling back to our earlier discussion... a review of the code netlink code doesn't show anything odd and a simple test program which calls socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE) definitely requires a 'network netlink raw,' apparmor rule
[00:10] <tyhicks> here's the denial I get if I don't add that rule to the profile:
[00:10] <tyhicks> audit: type=1400 audit(1488499593.813:25): apparmor="DENIED" operation="create" profile="test" pid=1969 comm="nl" family="netlink" sock_type="raw" protocol=0 requested_mask="create" denied_mask="create"
[02:53] <mup> PR snapcraft#1171 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1171>
[07:49] <mup> PR snapd#2973 closed: cmd/snap-confine: use sc_do_mount everywhere <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2973>
[08:00] <mup> PR snapd#2953 closed: release: detect if we are in ForcedDevMode by inspecting the kernel <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2953>
[08:23] <mup> PR snapd#2978 opened: cmd/snap-confine: use sc_do_umount everywhere <Created by zyga> <https://github.com/snapcore/snapd/pull/2978>
[08:29] <liuxg> ogra_, ping
[08:31] <liuxg> ogra_, I used your sample code in the mailinglist to launch google.com using xdg-open, but it did not work in my place. the source code is at https://github.com/liu-xiao-guo/launchwebsite
[08:46] <mup> PR snapd#2950 closed: interfaces: use spec in kmod backend, updated firewall_control, openvswitch_support, ppp <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2950>
[08:46] <mardy> cjwatson: hi! Just found out about build.snapcraft.io :-) Are there plans to make it support gitlab.com?
[09:21] <stub> How to I revert a channel to an older release?
[09:21] <stub> Do I need to download the old snap and reupload it, or is there a smarter way?
[10:01] <mup> PR snapd#2970 closed: many: add support for retrieving snap history from API <Created by justincan> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2970>
[10:15] <ogra_> liuxg, do you have snapd-xdg-open installed on the host ?
[10:26] <joedborg> o/ all
[10:28] <joedborg> I'm trying to set an environment variable inside an app declaration (inside snapcraft.yaml).  I need to base this off the $SNAP variable, but I can't get it to resolve.
[10:28] <joedborg> e.g. $ echo $PYTHONPATH
[10:28] <joedborg> $SNAP/horizon
[10:38] <mup> PR snapd#2979 opened: tests: add ubuntu-core-16-32 system to the external backend and fix docker test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2979>
[10:38] <kalikiana_> stub: Unpublish, re-publish, that's the best way I found to do it
[10:39] <stub> ta.
[10:42] <liuxg> ogra_, ping
[10:42] <ogra_> liuxg, hey, did you see my reply above ?
[10:42] <liuxg> ogra_, sorry, I did not see the reply :) I will try it. thanks
[10:43] <liuxg> ogra_, is it a snap or debian?
[10:44] <ogra_> its a deb you need installed on your desktop (it was discussed in the thread)
[10:46] <cjwatson> mardy: Not at present
[10:46] <liuxg> ogra_, sorry, I did not read it through. I think it is good to have it as a build-package in the snapcraft.yaml
[10:46] <ogra_> liuxg, nope
[10:46] <ogra_> you need it installed on the desktop, nothing in snapcraft.yaml will help with that
[10:46] <liuxg> ogra_, I just installed it, and it worked.
[10:47] <liuxg> ogra_, so build-package will not install it onto the desktop?
[10:47] <ogra_> no
[10:47] <ogra_> snapcraft only operates inside the snap
[10:47] <liuxg> ogra_, ok. I got it. thanks.
[10:48] <liuxg> ogra_, thanks for your help on this. so, this is an dependence.
[10:48] <ogra_> right
[11:56] <didrocks> ogra_: I think the user wants to install a snap in the store (ktouch)
[11:56] <didrocks> not creating it
[11:57] <ogra_> didrocks, hmm, that wasnt clear to me, yeah, you might be right
[11:57] <didrocks> ogra_: so, the issue I guess is that the platform snap isn't connected to it, and the KDE helper (but I don't know how it works exactly) don't do this check with a nice error message unlike our desktop helper
[11:57] <popey> yeah, i agree
[11:58] <popey> they need to connect the content snap
[11:58] <didrocks> sitter: hey, you might way to either use our desktop helpers or add this kind of check as we do
[11:58] <didrocks> ogra_: feel free to rephase ;)
[11:58] <didrocks> rephrase*
[11:58] <didrocks> even
[12:00]  * ogra_ re-phases and is now fully positive charged 
[12:01] <didrocks> ahah
[12:01] <didrocks> two or three phases? :)
[12:02] <ogra_> old school .... only two and a grounding (at times) :)
[12:02] <didrocks> heh
[12:51] <mup> PR snapd#2977 closed: releasing package snapd version 2.23 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2977>
[13:11] <jdstrand> tyhicks: maybe I got rate limited (even though I set it to '0')
[13:13] <jdstrand> tyhicks: but it was weird-- if I added the seccomp rule, no apparmor denial, if I removed it, seccomp denial. I then tried it multiple times...
[13:13] <jdstrand> (ie, went back and forth)
[13:16]  * jdstrand tries with dgram
[13:18] <stokachu> hmm how do i select a different organization in build.snapcraft.io?
[13:18] <stokachu> i made sure it had access to that org on github
[13:21] <jdstrand> dgram makes no difference
[13:22] <jdstrand> tyhicks: maybe it was incredibly poor timing-- I can confirm that it is denied by apparmor as root and non-root. I can also confirm that if I go fast enough even with rate limiting disabled, I don't always see it in the log
[13:23] <didrocks> mvo: hey, didn't you tell yesterday that 2.23 was blocked for zesty due to autopkgtests failing?
[13:28] <mvo> didrocks: it was, then things fixed themself, it was an outdated core snap on ppc64el that held it back. sorry, I understand this is annoying now :(
[13:29] <didrocks> mvo: we maybe should have put a hold… yeah, annoying it did fixed himself
[13:31] <Jasem[m]> Quick question: If I build a snap on 17.04, it will work on 16.04?
[13:34] <didrocks> Jasem[m]: if you include your all dependencies in your snap for a fully confined one, it should, indeed :)
[14:05] <Jasem[m]> didrocks: Thanks, I decided to build on 16.04 just to be safe
[14:07] <ogra_> Jasem[m], if you restrict yourself to run "snapcraft cleanbuild"  the host distro shouldnt matter (it will build in a xenial lxd container then)
[14:08] <Jasem[m]> ogra_: thanks will take that into consideration. So I'm building a snap now in 16.04, so deploying it to Ubuntu-Core wouldn't be an issue I presume?
[14:08] <ogra_> right
[14:09] <Jasem[m]> Anyone here used Ubuntu-Core with Snapdragon board? I just saw the Embedded Linux videos
[14:09] <ogra_> well, i'm maintaining the port ... so i occasionally actually use it ;)
[14:10] <ogra_> s/port/image port/
[14:10] <Jasem[m]> ogra_: I was considering it for my embedded project, but then read some issues about WiFi.. I think I might be eventually settle for the good-old RPI3
[14:10] <ogra_> the dragonboard has no wifi issues
[14:10] <ogra_> the pi3 does though :)
[14:11] <Jasem[m]> PI3 working fine here with WiFi.. well, I tried other boards but each has its own issues. RPI3 is the most reliable so far despite its shortcomings
[14:11] <ogra_> (only for the inital setup, it is rock solid afterwards ... but pi3 needs to do the setup wired )
[14:11] <Jasem[m]> No USB3, no Gigabit Ethernet
[14:12] <Jasem[m]> From the Embedded Linux presentation, it seems everything around Ubuntu-Core is free.. how does Canonical make any money of that then?
[14:13] <ogra_> services, support, contracts with device manufacturers for porting/maintaining an image for their HW
[14:14] <Jasem[m]> is there a service for "Here is X, Y, Z software I need. Make them into snaps and give me an image" ?
[14:18] <Jasem[m]> Oh I'll just contact Canonical and find out
[15:00] <mup> PR snapd#2980 opened: client, daemon: move "snap list" name filtering into snapd <Created by chipaca> <https://github.com/snapcore/snapd/pull/2980>
[15:07] <mup> PR snapd#2981 opened: tests: add kernel-module-control interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2981>
[15:23] <joedborg> is there any reason why snapcraft doesn't stage hidden files?
[15:23] <joedborg> as in it seems to explicitly seems to ignore them
[15:48] <mup> PR snapd#2944 closed: interfaces/builtin/alsa: add read access to alsa state dir <Created by ssweeny> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2944>
[15:49] <ssweeny> thanks jdstrand
[15:50] <jdstrand> ssweeny: np
[16:10] <SuperJonotron> running into an odd issue here with snaps, done this a thousand times before but just rebuild a snap with two commands, both show up in the binary and if I navigate to that directory and call them by name ./snapName.command it says no such file or directory when trying to run
[16:11] <SuperJonotron> does this maybe indicate snapcraft created a bad snap?
[16:28] <mup> PR snapd#2982 opened: daemon: add desktop file location for app to the API <Created by mvo5> <https://github.com/snapcore/snapd/pull/2982>
[17:31] <cholcombe> i'm giving snappy-debug a try and it cannot connect to log-observe: error: snap "ubuntu-core" has no slot named "log-observe".  Anyone else encountered this?
[17:32] <kyrofa> cholcombe, can you pastebin the output of `snap interfaces`?
[17:32] <cholcombe> sure one sec
[17:32] <cholcombe> kyrofa: http://paste.ubuntu.com/24103211/
[17:32] <cholcombe> this is on an ec2 xenial box
[17:33] <kyrofa> Uh... huh. It says it's connected
[17:33] <cholcombe> lol i know
[17:33] <kyrofa> Does it work now? :P
[17:33] <cholcombe> nope
[17:33] <cholcombe> snap connect snappy-debug:log-observe ubuntu-core:log-observe
[17:33] <cholcombe> error: snap "ubuntu-core" has no slot named "log-observe"
[17:33] <cholcombe> is that the right command?
[17:33] <kyrofa> Ohhh
[17:33] <kyrofa> cholcombe, no, it's only core now
[17:33] <kyrofa> cholcombe, in fact, you can leave the last arg off completely
[17:33] <cholcombe> oh ok
[17:33] <kyrofa> cholcombe, just run `snap connect snappy-debug:log-observe`
[17:33] <cholcombe> yeah that works now
[17:34] <kyrofa> cholcombe, ooo, gluster, that sounds like fun
[17:34] <cholcombe> kyrofa: gluster has a new iscsi manager that i'm trying out
[17:34] <cholcombe> i might even be bold and snap gluster
[17:35] <cholcombe> the daemon is hanging when i start it and i'm not sure what's going on.  maybe strace will tell me something
[17:36] <cholcombe> oh maybe this doesn't fork.  i must've misread the C code
[17:37] <kyrofa> Hahaha
[17:37] <kyrofa> So it's actually working?
[17:37] <cholcombe> i'm not certain.  i'm messing around with it
[17:37] <cholcombe> strace says it's waiting on futex
[17:39] <cholcombe> kyrofa: yeah i think it is working
[17:39] <cholcombe> looks like i need targetcli and some other crap.  need to rebuild the snap
[17:39] <ogra_> snap "ubuntu-core" ?????
[17:39] <ogra_> you shouldnt have that at all
[17:40] <kyrofa> ogra_, probably referring to out-of-date docs
[17:40] <ogra_> everyone should have been moved from ubuntu-core to core nowadays
[17:40] <ogra_> kyrofa, well, it is in the error message above
[17:41] <kyrofa> ogra_, because it's not intelligent
[17:41] <kyrofa> $ sudo snap connect foo:bar baz:qux
[17:41] <kyrofa> error: snap "foo" has no plug named "bar"
[17:41] <ogra_> oh
[17:41] <ogra_> silly !
[17:41] <kyrofa> Agreed
[17:41] <ogra_> add AI !!!!!
[17:41] <cholcombe> kyrofa: if gluster-blockd needs to access targetcli do i need an interface for that?
[17:42] <kyrofa> cholcombe, are they in separate snaps?
[17:42] <cholcombe> i'm not sure if targetcli is snapped.  i could just apt install it
[17:43] <kyrofa> cholcombe, is that something that should be contained within the snap?
[17:43] <cholcombe> hmm.  i'm guessing not
[17:44]  * kyrofa isn't sure what targetcli is
[17:45] <cholcombe> kyrofa: it's a python program that configures iscsi initators
[17:45] <kyrofa> cholcombe, think about it this way. If someone installs your snap on a clean install of Ubuntu, what's going to happen?
[17:45] <kyrofa> cholcombe, you can't depend on a deb
[17:45] <cholcombe> then yeah targetcli's python script will be missing
[17:45] <kyrofa> cholcombe, so an interface isn't going to help you here
[17:45] <cholcombe> and tcmu-runner whatever that is.  it's also complaining about that
[17:46] <kyrofa> Oh man. Out of coffee before 10am. This will not be a good day
[17:46] <cholcombe> ah crap tcmu-runner is another C program i need to snap
[17:47] <cholcombe> so yeah i guess i should package this all together
[17:47] <kyrofa> Yeah I think so
[17:47] <kyrofa> cholcombe, just consider what happens if someone installed your snap alongside, I dunno, the ceph snap that also bundles those things (let's assume). Will it still work okay?
[17:48] <cholcombe> i'm not sure
[17:48] <cholcombe> ceph will likely also want iscsi targets
[17:48] <cholcombe> it's unlikely they'll both be on the same machine but you never know
[17:49] <kyrofa> Yeah it doesn't really change what you need to do (just bundle them), just something to keep in mind
[17:49] <cholcombe> ok
[19:21] <mup> PR snapcraft#1169 closed: tests: update the ftp source for integration test <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1169>
[19:51] <mup> PR snapd#2983 opened: Support spread testing with proxy <Created by nuclearbob> <https://github.com/snapcore/snapd/pull/2983>
[20:27] <kyrofa> jdstrand, within a snap, /tmp used to be unique to each app
[20:27] <kyrofa> jdstrand, is that no longer the case? i.e. is the same /tmp/ shared across apps in the same snap?
[20:27] <kyrofa> jdstrand, I guess it was specific to the instantiation, huh
[20:28] <kyrofa> jdstrand, but has that changed?
[20:31] <jdstrand> kyrofa: /tmp is shared across commands in the same snap
[20:32] <kyrofa> jdstrand, do you remember when that change was introduced? Or was is all snap-confine?
[20:32] <jdstrand> kyrofa: all commands share the same mount namespace. this is part of the reason why the snap-update-ns exists
[20:32] <jdstrand> kyrofa: iirc it was snap-confine 1.0.43
[20:32] <kyrofa> jdstrand, wonderful, that really simplifies some things
[20:36] <jdstrand> snap-update-ns issue*
[20:46] <cholcombe> kyrofa: gluster-blockd makes a unix socket in /var/run/gluster-blockd.socket.  If i want to access that from a user space program do i need to do anything special?
[20:46] <cholcombe> i guess i'm asking which way the confinement goes.
[20:47] <kyrofa> cholcombe, gluster-blockd is the thing you're trying to snap? And "a user space program" is outside of snaps?
[20:47] <cholcombe> correct
[20:47] <cholcombe> can user space programs access that socket or does it go both ways and i have to be in the snap to access it?
[20:47] <kyrofa> cholcombe, you wouldn't need to do anything special from the user-space point of view, but I don't think a confined snap can place something directly in /var/run
[20:47] <cholcombe> ok
[20:48] <cholcombe> yeah i'm still in dev mode
[20:48] <kyrofa> cholcombe, for the most part, you're not running a chroot (ala docker or lxd)
[20:48] <cholcombe> ok
[20:49] <kyrofa> cholcombe, well, I guess that's not quite right nowadays
[20:49] <kyrofa> cholcombe, you're essentially chrooted into the core snap with stuff from the system bind-mounted in
[20:49] <cholcombe> i see
[20:50] <cholcombe> that's what i thinking
[20:50] <cholcombe> so if i stay in classic of dev mode i'm good to go.  but if i go strict i'm going to have issues with that unix socket
[20:51] <kyrofa> cholcombe, indeed. If strict you'll need to put that somewhere the snap can actually write
[20:51] <cholcombe> yeah
[21:03] <cholcombe> coreycb: for https://github.com/open-iscsi/tcmu-runner/blob/91d23191f97937bb92c19cc73565c8ea73c3cc7e/CMakeLists.txt do you know how to set LIBNL_LIB in the snapcraft.yaml?
[21:07] <coreycb> cholcombe, it looks like you can set environment variables in snapcraft.yaml - https://bugs.launchpad.net/snappy/+bug/1583259
[21:07] <cholcombe> kyrofa: looks like tcmu-runner wants me to drop files into /etc/dbus-1/system.d
[21:07] <mup> Bug #1583259: Snappy needs to influence environment variables in applications  <snap-desktop-issue> <verification-done> <Canonical Click Reviewers tools:Fix Released by jdstrand> <Snappy Launcher:Invalid> <Snapcraft:Fix Released by sergiusens> <Snappy:Fix Released> <click-reviewers-tools
[21:07] <mup> (Ubuntu):Fix Released> <click-reviewers-tools (Ubuntu Xenial):Fix Released> <click-reviewers-tools (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1583259>
[21:07] <kyrofa> cholcombe, so it needs the systemd dbus eh? That sounds like an interface
[21:07] <cholcombe> coreycb: cool thanks for
[21:08] <cholcombe> kyrofa: like i need to write an interface or i just make use of one?
[21:09] <kyrofa> cholcombe, I'm not quite sure. I've successfully avoided dbus in snaps so far, so I don't have experience to fall back on here. jdstrand can probably help you more
[21:09] <cholcombe> ok
[21:10] <jdstrand> cholcombe: take a look at the dbus interface and specify 'bus: system'. that will give you the dbus policy in /etc/dbus-1/system.d
[21:10] <cholcombe> jdstrand: ok
[21:10] <jdstrand> cholcombe: if that interface isn't enough for you, you will need to a new interface
[21:10] <jdstrand> to write*
[21:11] <cholcombe> jdstrand: ok i'll take a peek in a minute
[21:11] <jdstrand> cholcombe: https://github.com/snapcore/snapd/wiki/Interfaces#dbus
[21:12] <cholcombe> this is prob a silly question but when i'm building snapcraft packages are all the dependencies being apt installed on my local system or are they in a chroot?
[21:12] <kyrofa> cholcombe, no silly questions here :)
[21:12] <cholcombe> :)
[21:12] <kyrofa> cholcombe, it actually depends
[21:12] <kyrofa> cholcombe, which depedencies are we talking about? How are they specified?
[21:13] <cholcombe> i guess the question is should i building in a lxc container
[21:13] <cholcombe> anything i say as build dependencies
[21:13] <cholcombe> i'm wondering if i'm polluting my desktop with tons and tons of dev packages
[21:13] <kyrofa> cholcombe, yep. build-packages are installed on the host
[21:13] <cholcombe> ok
[21:13] <kyrofa> cholcombe, stage-packages aren't-- they're unpacked right into the snap
[21:13] <cholcombe> hmm alright
[21:14] <kyrofa> cholcombe, indeed, every snap I personally build is in a new lxc container
[21:14] <cholcombe> yeah i was wondering :D
[21:14] <cholcombe> i need to start doing that
[21:14] <kyrofa> cholcombe, is also ensures that I determine ALL dependencies
[21:14] <cholcombe> exactly
[21:39] <pmcgowan> kyrofa, does a configure hook run before or after connecting interfaces
[21:39] <kyrofa> pmcgowan, neither, there are new hooks being written for that (called interface hooks)
[21:40] <kyrofa> pmcgowan, oh wait, do you mean when installing?
[21:40] <pmcgowan> kyrofa, well I mean in general
[21:40] <kyrofa> pmcgowan, the configure hook won't run when you use `snap connect/disconnect`
[21:40] <pmcgowan> I just added a configure hook to my snap and now the content interface is not really connecting
[21:40] <kyrofa> pmcgowan, interesting, that shouldn't affect anything there
[21:41] <kyrofa> pmcgowan, do you get an error?
[21:41] <pmcgowan> wondering if its related before I back off
[21:41] <pmcgowan> no error
[21:41] <kyrofa> So helpful :P
[21:41] <pmcgowan> just that I should connect the interface
[21:41] <pmcgowan> whih shows connected
[21:41] <pmcgowan> kyrofa, I will back up and see then
[21:41] <kyrofa> Huh... not sure what's happening there
[21:44] <Pharaoh_Atem> wtf
[21:44] <Pharaoh_Atem> why is 2.23 not 2.23?
[21:44] <Pharaoh_Atem> the snapd 2.23 tagged in git doesn't match what I expect it to be
[21:44] <Pharaoh_Atem> it's ~14 days old
[21:45] <pmcgowan> kyrofa, oy, I removed the hook and it works again
[21:45] <pmcgowan> enough for friday
[21:46] <kyrofa> pmcgowan, haha, okay, well ping me Monday then, happy to dig into that with you
[21:46] <pmcgowan> kyrofa, k have a good weekend
[21:46] <kyrofa> pmcgowan, you too!
[21:53] <cholcombe> kyrofa: think you could take a quick peek at this? http://paste.ubuntu.com/24104552/  i'm trying to build the targetcli python part
[21:53] <cholcombe> it seems to build correctly and then fail
[21:54] <cholcombe> i can paste my snapcraft.yaml also
[21:55] <cholcombe> http://paste.ubuntu.com/24104562/