| 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:09 |
|---|---|---|
| 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" | 00:10 |
| mup | PR snapcraft#1171 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1171> | 02:53 |
| 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> | 07:49 |
| 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:00 |
| mup | PR snapd#2978 opened: cmd/snap-confine: use sc_do_umount everywhere <Created by zyga> <https://github.com/snapcore/snapd/pull/2978> | 08:23 |
| liuxg | ogra_, ping | 08:29 |
| 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:31 |
| 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? | 08:46 |
| 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? | 09:21 |
| === JamesTait is now known as Guest5139 | ||
| === Guest5139 is now known as JamesTait | ||
| 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:01 |
| ogra_ | liuxg, do you have snapd-xdg-open installed on the host ? | 10:15 |
| joedborg | o/ all | 10:26 |
| 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:28 |
| 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:38 |
| stub | ta. | 10:39 |
| 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:42 |
| liuxg | ogra_, is it a snap or debian? | 10:43 |
| ogra_ | its a deb you need installed on your desktop (it was discussed in the thread) | 10:44 |
| 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:46 |
| 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:47 |
| liuxg | ogra_, thanks for your help on this. so, this is an dependence. | 10:48 |
| ogra_ | right | 10:48 |
| didrocks | ogra_: I think the user wants to install a snap in the store (ktouch) | 11:56 |
| didrocks | not creating it | 11:56 |
| 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:57 |
| 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 | 11:58 |
| === hikiko is now known as hikiko|bbl | ||
| * ogra_ re-phases and is now fully positive charged | 12:00 | |
| didrocks | ahah | 12:01 |
| didrocks | two or three phases? :) | 12:01 |
| ogra_ | old school .... only two and a grounding (at times) :) | 12:02 |
| didrocks | heh | 12:02 |
| mup | PR snapd#2977 closed: releasing package snapd version 2.23 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2977> | 12:51 |
| === marcoceppi_ is now known as marcoceppi | ||
| jdstrand | tyhicks: maybe I got rate limited (even though I set it to '0') | 13:11 |
| 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:13 |
| * jdstrand tries with dgram | 13:16 | |
| 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:18 |
| jdstrand | dgram makes no difference | 13:21 |
| 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:22 |
| didrocks | mvo: hey, didn't you tell yesterday that 2.23 was blocked for zesty due to autopkgtests failing? | 13:23 |
| 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:28 |
| didrocks | mvo: we maybe should have put a hold… yeah, annoying it did fixed himself | 13:29 |
| Jasem[m] | Quick question: If I build a snap on 17.04, it will work on 16.04? | 13:31 |
| didrocks | Jasem[m]: if you include your all dependencies in your snap for a fully confined one, it should, indeed :) | 13:34 |
| Jasem[m] | didrocks: Thanks, I decided to build on 16.04 just to be safe | 14:05 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| ogra_ | services, support, contracts with device manufacturers for porting/maintaining an image for their HW | 14:13 |
| 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:14 |
| Jasem[m] | Oh I'll just contact Canonical and find out | 14:18 |
| === hikiko|bbl is now known as hikiko\ | ||
| 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:00 |
| mup | PR snapd#2981 opened: tests: add kernel-module-control interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2981> | 15:07 |
| 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:23 |
| 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:48 |
| ssweeny | thanks jdstrand | 15:49 |
| jdstrand | ssweeny: np | 15:50 |
| === hikiko\ is now known as hikiko | ||
| 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:10 |
| SuperJonotron | does this maybe indicate snapcraft created a bad snap? | 16:11 |
| 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> | 16:28 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| cholcombe | oh maybe this doesn't fork. i must've misread the C code | 17:36 |
| 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:37 |
| 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:39 |
| === ejat_ is now known as ejat | ||
| 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:40 |
| 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:41 |
| 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:42 |
| === hikiko_ is now known as hikiko | ||
| kyrofa | cholcombe, is that something that should be contained within the snap? | 17:43 |
| === souther_ is now known as souther | ||
| cholcombe | hmm. i'm guessing not | 17:43 |
| === Dmitrii-Sh_ is now known as Dmitrii-Sh | ||
| * kyrofa isn't sure what targetcli is | 17:44 | |
| === diddledan_ is now known as diddledan | ||
| cholcombe | kyrofa: it's a python program that configures iscsi initators | 17:45 |
| === FourDollars_ is now known as FourDollars | ||
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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 | 17:49 |
| === apw_ is now known as apw | ||
| 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:21 |
| === JanC is now known as Guest50506 | ||
| === JanC_ is now known as JanC | ||
| mup | PR snapd#2983 opened: Support spread testing with proxy <Created by nuclearbob> <https://github.com/snapcore/snapd/pull/2983> | 19:51 |
| 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:27 |
| kyrofa | jdstrand, but has that changed? | 20:28 |
| === josepht` is now known as josepht | ||
| jdstrand | kyrofa: /tmp is shared across commands in the same snap | 20:31 |
| 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:32 |
| jdstrand | snap-update-ns issue* | 20:36 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| kyrofa | cholcombe, indeed. If strict you'll need to put that somewhere the snap can actually write | 20:51 |
| cholcombe | yeah | 20:51 |
| 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:03 |
| 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:07 |
| cholcombe | kyrofa: like i need to write an interface or i just make use of one? | 21:08 |
| 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:09 |
| 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:10 |
| cholcombe | jdstrand: ok i'll take a peek in a minute | 21:11 |
| jdstrand | cholcombe: https://github.com/snapcore/snapd/wiki/Interfaces#dbus | 21:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:44 |
| pmcgowan | kyrofa, oy, I removed the hook and it works again | 21:45 |
| pmcgowan | enough for friday | 21:45 |
| 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:46 |
| 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:53 |
| cholcombe | i can paste my snapcraft.yaml also | 21:54 |
| cholcombe | http://paste.ubuntu.com/24104562/ | 21:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!