[00:09] 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] here's the denial I get if I don't add that rule to the profile: [00:10] 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] PR snapcraft#1171 opened: beta [07:49] PR snapd#2973 closed: cmd/snap-confine: use sc_do_mount everywhere [08:00] PR snapd#2953 closed: release: detect if we are in ForcedDevMode by inspecting the kernel [08:23] PR snapd#2978 opened: cmd/snap-confine: use sc_do_umount everywhere [08:29] ogra_, ping [08:31] 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] PR snapd#2950 closed: interfaces: use spec in kmod backend, updated firewall_control, openvswitch_support, ppp [08:46] cjwatson: hi! Just found out about build.snapcraft.io :-) Are there plans to make it support gitlab.com? [09:21] How to I revert a channel to an older release? [09:21] Do I need to download the old snap and reupload it, or is there a smarter way? === JamesTait is now known as Guest5139 === Guest5139 is now known as JamesTait [10:01] PR snapd#2970 closed: many: add support for retrieving snap history from API [10:15] liuxg, do you have snapd-xdg-open installed on the host ? [10:26] o/ all [10:28] 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] e.g. $ echo $PYTHONPATH [10:28] $SNAP/horizon [10:38] PR snapd#2979 opened: tests: add ubuntu-core-16-32 system to the external backend and fix docker test [10:38] stub: Unpublish, re-publish, that's the best way I found to do it [10:39] ta. [10:42] ogra_, ping [10:42] liuxg, hey, did you see my reply above ? [10:42] ogra_, sorry, I did not see the reply :) I will try it. thanks [10:43] ogra_, is it a snap or debian? [10:44] its a deb you need installed on your desktop (it was discussed in the thread) [10:46] mardy: Not at present [10:46] 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] liuxg, nope [10:46] you need it installed on the desktop, nothing in snapcraft.yaml will help with that [10:46] ogra_, I just installed it, and it worked. [10:47] ogra_, so build-package will not install it onto the desktop? [10:47] no [10:47] snapcraft only operates inside the snap [10:47] ogra_, ok. I got it. thanks. [10:48] ogra_, thanks for your help on this. so, this is an dependence. [10:48] right [11:56] ogra_: I think the user wants to install a snap in the store (ktouch) [11:56] not creating it [11:57] didrocks, hmm, that wasnt clear to me, yeah, you might be right [11:57] 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] yeah, i agree [11:58] they need to connect the content snap [11:58] sitter: hey, you might way to either use our desktop helpers or add this kind of check as we do [11:58] ogra_: feel free to rephase ;) [11:58] rephrase* [11:58] even === hikiko is now known as hikiko|bbl [12:00] * ogra_ re-phases and is now fully positive charged [12:01] ahah [12:01] two or three phases? :) [12:02] old school .... only two and a grounding (at times) :) [12:02] heh [12:51] PR snapd#2977 closed: releasing package snapd version 2.23 === marcoceppi_ is now known as marcoceppi [13:11] tyhicks: maybe I got rate limited (even though I set it to '0') [13:13] 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] (ie, went back and forth) [13:16] * jdstrand tries with dgram [13:18] hmm how do i select a different organization in build.snapcraft.io? [13:18] i made sure it had access to that org on github [13:21] dgram makes no difference [13:22] 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] mvo: hey, didn't you tell yesterday that 2.23 was blocked for zesty due to autopkgtests failing? [13:28] 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] mvo: we maybe should have put a hold… yeah, annoying it did fixed himself [13:31] Quick question: If I build a snap on 17.04, it will work on 16.04? [13:34] Jasem[m]: if you include your all dependencies in your snap for a fully confined one, it should, indeed :) [14:05] didrocks: Thanks, I decided to build on 16.04 just to be safe [14:07] 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] 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] right [14:09] Anyone here used Ubuntu-Core with Snapdragon board? I just saw the Embedded Linux videos [14:09] well, i'm maintaining the port ... so i occasionally actually use it ;) [14:10] s/port/image port/ [14:10] 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] the dragonboard has no wifi issues [14:10] the pi3 does though :) [14:11] 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] (only for the inital setup, it is rock solid afterwards ... but pi3 needs to do the setup wired ) [14:11] No USB3, no Gigabit Ethernet [14:12] From the Embedded Linux presentation, it seems everything around Ubuntu-Core is free.. how does Canonical make any money of that then? [14:13] services, support, contracts with device manufacturers for porting/maintaining an image for their HW [14:14] is there a service for "Here is X, Y, Z software I need. Make them into snaps and give me an image" ? [14:18] Oh I'll just contact Canonical and find out === hikiko|bbl is now known as hikiko\ [15:00] PR snapd#2980 opened: client, daemon: move "snap list" name filtering into snapd [15:07] PR snapd#2981 opened: tests: add kernel-module-control interface test [15:23] is there any reason why snapcraft doesn't stage hidden files? [15:23] as in it seems to explicitly seems to ignore them [15:48] PR snapd#2944 closed: interfaces/builtin/alsa: add read access to alsa state dir [15:49] thanks jdstrand [15:50] ssweeny: np === hikiko\ is now known as hikiko [16:10] 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] does this maybe indicate snapcraft created a bad snap? [16:28] PR snapd#2982 opened: daemon: add desktop file location for app to the API [17:31] 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] cholcombe, can you pastebin the output of `snap interfaces`? [17:32] sure one sec [17:32] kyrofa: http://paste.ubuntu.com/24103211/ [17:32] this is on an ec2 xenial box [17:33] Uh... huh. It says it's connected [17:33] lol i know [17:33] Does it work now? :P [17:33] nope [17:33] snap connect snappy-debug:log-observe ubuntu-core:log-observe [17:33] error: snap "ubuntu-core" has no slot named "log-observe" [17:33] is that the right command? [17:33] Ohhh [17:33] cholcombe, no, it's only core now [17:33] cholcombe, in fact, you can leave the last arg off completely [17:33] oh ok [17:33] cholcombe, just run `snap connect snappy-debug:log-observe` [17:33] yeah that works now [17:34] cholcombe, ooo, gluster, that sounds like fun [17:34] kyrofa: gluster has a new iscsi manager that i'm trying out [17:34] i might even be bold and snap gluster [17:35] 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] oh maybe this doesn't fork. i must've misread the C code [17:37] Hahaha [17:37] So it's actually working? [17:37] i'm not certain. i'm messing around with it [17:37] strace says it's waiting on futex [17:39] kyrofa: yeah i think it is working [17:39] looks like i need targetcli and some other crap. need to rebuild the snap [17:39] snap "ubuntu-core" ????? [17:39] you shouldnt have that at all === ejat_ is now known as ejat [17:40] ogra_, probably referring to out-of-date docs [17:40] everyone should have been moved from ubuntu-core to core nowadays [17:40] kyrofa, well, it is in the error message above [17:41] ogra_, because it's not intelligent [17:41] $ sudo snap connect foo:bar baz:qux [17:41] error: snap "foo" has no plug named "bar" [17:41] oh [17:41] silly ! [17:41] Agreed [17:41] add AI !!!!! [17:41] kyrofa: if gluster-blockd needs to access targetcli do i need an interface for that? [17:42] cholcombe, are they in separate snaps? [17:42] i'm not sure if targetcli is snapped. i could just apt install it === hikiko_ is now known as hikiko [17:43] cholcombe, is that something that should be contained within the snap? === souther_ is now known as souther [17:43] hmm. i'm guessing not === Dmitrii-Sh_ is now known as Dmitrii-Sh [17:44] * kyrofa isn't sure what targetcli is === diddledan_ is now known as diddledan [17:45] kyrofa: it's a python program that configures iscsi initators === FourDollars_ is now known as FourDollars [17:45] cholcombe, think about it this way. If someone installs your snap on a clean install of Ubuntu, what's going to happen? [17:45] cholcombe, you can't depend on a deb [17:45] then yeah targetcli's python script will be missing [17:45] cholcombe, so an interface isn't going to help you here [17:45] and tcmu-runner whatever that is. it's also complaining about that [17:46] Oh man. Out of coffee before 10am. This will not be a good day [17:46] ah crap tcmu-runner is another C program i need to snap [17:47] so yeah i guess i should package this all together [17:47] Yeah I think so [17:47] 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] i'm not sure [17:48] ceph will likely also want iscsi targets [17:48] it's unlikely they'll both be on the same machine but you never know [17:49] Yeah it doesn't really change what you need to do (just bundle them), just something to keep in mind [17:49] ok === apw_ is now known as apw [19:21] PR snapcraft#1169 closed: tests: update the ftp source for integration test === JanC is now known as Guest50506 === JanC_ is now known as JanC [19:51] PR snapd#2983 opened: Support spread testing with proxy [20:27] jdstrand, within a snap, /tmp used to be unique to each app [20:27] jdstrand, is that no longer the case? i.e. is the same /tmp/ shared across apps in the same snap? [20:27] jdstrand, I guess it was specific to the instantiation, huh [20:28] jdstrand, but has that changed? === josepht` is now known as josepht [20:31] kyrofa: /tmp is shared across commands in the same snap [20:32] jdstrand, do you remember when that change was introduced? Or was is all snap-confine? [20:32] kyrofa: all commands share the same mount namespace. this is part of the reason why the snap-update-ns exists [20:32] kyrofa: iirc it was snap-confine 1.0.43 [20:32] jdstrand, wonderful, that really simplifies some things [20:36] snap-update-ns issue* [20:46] 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] i guess i'm asking which way the confinement goes. [20:47] cholcombe, gluster-blockd is the thing you're trying to snap? And "a user space program" is outside of snaps? [20:47] correct [20:47] 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] 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] ok [20:48] yeah i'm still in dev mode [20:48] cholcombe, for the most part, you're not running a chroot (ala docker or lxd) [20:48] ok [20:49] cholcombe, well, I guess that's not quite right nowadays [20:49] cholcombe, you're essentially chrooted into the core snap with stuff from the system bind-mounted in [20:49] i see [20:50] that's what i thinking [20:50] 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] cholcombe, indeed. If strict you'll need to put that somewhere the snap can actually write [20:51] yeah [21:03] 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] cholcombe, it looks like you can set environment variables in snapcraft.yaml - https://bugs.launchpad.net/snappy/+bug/1583259 [21:07] kyrofa: looks like tcmu-runner wants me to drop files into /etc/dbus-1/system.d [21:07] Bug #1583259: Snappy needs to influence environment variables in applications

(Ubuntu):Fix Released>

[21:07] cholcombe, so it needs the systemd dbus eh? That sounds like an interface [21:07] coreycb: cool thanks for [21:08] kyrofa: like i need to write an interface or i just make use of one? [21:09] 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] ok [21:10] 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] jdstrand: ok [21:10] cholcombe: if that interface isn't enough for you, you will need to a new interface [21:10] to write* [21:11] jdstrand: ok i'll take a peek in a minute [21:11] cholcombe: https://github.com/snapcore/snapd/wiki/Interfaces#dbus [21:12] 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] cholcombe, no silly questions here :) [21:12] :) [21:12] cholcombe, it actually depends [21:12] cholcombe, which depedencies are we talking about? How are they specified? [21:13] i guess the question is should i building in a lxc container [21:13] anything i say as build dependencies [21:13] i'm wondering if i'm polluting my desktop with tons and tons of dev packages [21:13] cholcombe, yep. build-packages are installed on the host [21:13] ok [21:13] cholcombe, stage-packages aren't-- they're unpacked right into the snap [21:13] hmm alright [21:14] cholcombe, indeed, every snap I personally build is in a new lxc container [21:14] yeah i was wondering :D [21:14] i need to start doing that [21:14] cholcombe, is also ensures that I determine ALL dependencies [21:14] exactly [21:39] kyrofa, does a configure hook run before or after connecting interfaces [21:39] pmcgowan, neither, there are new hooks being written for that (called interface hooks) [21:40] pmcgowan, oh wait, do you mean when installing? [21:40] kyrofa, well I mean in general [21:40] pmcgowan, the configure hook won't run when you use `snap connect/disconnect` [21:40] I just added a configure hook to my snap and now the content interface is not really connecting [21:40] pmcgowan, interesting, that shouldn't affect anything there [21:41] pmcgowan, do you get an error? [21:41] wondering if its related before I back off [21:41] no error [21:41] So helpful :P [21:41] just that I should connect the interface [21:41] whih shows connected [21:41] kyrofa, I will back up and see then [21:41] Huh... not sure what's happening there [21:44] wtf [21:44] why is 2.23 not 2.23? [21:44] the snapd 2.23 tagged in git doesn't match what I expect it to be [21:44] it's ~14 days old [21:45] kyrofa, oy, I removed the hook and it works again [21:45] enough for friday [21:46] pmcgowan, haha, okay, well ping me Monday then, happy to dig into that with you [21:46] kyrofa, k have a good weekend [21:46] pmcgowan, you too! [21:53] 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] it seems to build correctly and then fail [21:54] i can paste my snapcraft.yaml also [21:55] http://paste.ubuntu.com/24104562/