[01:52] I have a question about developer namespaces. can anyone help? [01:54] sergiusens: could you share your snapcraft.yaml or update the telegram one? === chihchun_afk is now known as chihchun [06:37] hey hey [06:51] good morning dholbach [06:54] salut didrocks [07:35] good morning everyone :) [07:35] I officially give up on reading backlog for the last three weeks [07:41] zyga, break with the past! move on to new things! ;-) [07:47] dholbach: speaking of which, https://bodhi.fedoraproject.org/updates/FEDORA-2016-0137e29c1e [07:48] https://bodhi.fedoraproject.org/updates/FEDORA-2016-0233975de8 [07:48] very nice :) [07:59] Son_Goku: hey, I cannot send bodhi request for f25 for golang-github-mvo5-goconfigparser -- I keep getting http://pastebin.ubuntu.com/22671527/ [08:00] ogra_: ping [08:00] zyga: welcome back! [08:00] morphis: hey [08:01] morphis: I saw you made a branch for udev fix, I also made one two weeks ago [08:01] morphis: did your version land? [08:01] zyga: hope you enjoiyed your time off [08:01] zyga: not yet, waiting for next review round [08:01] morphis: yes, I really needed that :-) [08:02] morphis: ok, great, I'll review it today if I can; I have a huge backlog of things to do [08:03] zyga: thanks, niemeyer is looking at it too [08:03] zyga: one other thing, you remember that we talked about loading kernel modules with interfaces once connected? [08:04] morphis: yes, I do, some people asked about that in Leiden AFAIR [08:05] zyga: yeah there is a kernel-load PR now, but this is more for the ppp interface where we don't want to give the plug side the ability to load modules but do that from snapd directly === e is now known as especiallee [08:07] zyga: wanted to check with you how we implement that the right way [08:07] morphis: I see, I think we need both types, free-form loading from within the app process and snapd-directed loading [08:07] zyga: yes [08:07] morphis: I'll make sure to review that one [08:07] ara: hey, long time no see :) [08:07] zyga, hey, how were the holidays? [08:08] ara: busy :) I'm looking forward to having some peace and quiet work time :) [08:08] zyga, hehe [08:09] ara: morning! [08:09] hey morphis :) [08:09] zyga: you have an idea in mind how to implemnt the snapd-directed loading? [08:10] zyga: we could add another security system or extend the interface API to return something like PermanentSlotKernelModules [08:10] morphis: yes, I talked to jdstrand about it; there are two parts; one that drops a line/file in /etc/modules-load.d for load on boot and another one that just modprobes the thing [08:10] yeah [08:10] morphis: I think using another security system is easier [08:10] morphis: the only thing we were worried about is options [08:10] morphis: but that all [08:11] yeah options might be tricky, but as we're doing specific modules here we may have to encode such a thing as attribute [08:11] not free-form but something we translate [08:13] morphis: jdstrand was worried that some options might be too powerful for an unrestricted interface [08:13] morphis: anyway, I think we can solve it on a case-by-case basis [08:13] yes [08:13] zyga: for now we have some well-defined use cases [08:13] ogra_: ping === especiallee is now known as e [08:28] hi! [08:28] hey ysionneau [08:34] about my friday question, someone said "SNAP_COMMON could be your solution" but I don't get how it can help me to make 2 different *snaps* communicate through unix socket [08:35] I thought I had a solution by having autopilot (which is devmode snap) create the unix socket in the SNAP_DATA of facedetect (which is a contained snap) [08:35] but since autopilot is already running when facedetect is not yet installed, it does not work [08:35] the PATH does not exist yet and the socket creation fails [08:45] ysionneau: lool mentioned SNAP_COMMON as, contrary to SNAP_DATA, it's a fixed path for whatever version of facedetect is running [08:45] but yeah, what you told is an issue if autopilot is already running before facedetect is installed [08:47] ysionneau: you need an interface for that [08:48] ysionneau: you can only communicate over tcp/ip without an interface [08:50] didrocks: ah ok goot to know, anyway I was using /current/ [08:50] zyga: :( [08:50] I guess I'll end up recompiling snapd to add my interface and stuff it into ubuntu-core [08:51] I however have no idea on how to recompile snapd =) [08:53] ysionneau: look at two links: https://github.com/zyga/devtools/ and at snapd docs (how to build) [08:53] https://github.com/snapcore/snapd/blob/master/README.md [08:53] thanks! [08:54] ysionneau: just a side note: ubuntu-image sccript in devtools is broken [08:57] ok thanks [08:57] I'm not using ubuntu-image from internet anymore [08:57] I had too many issues with updates [08:58] I commited one version that works in my repository [08:59] ysionneau: that won't work with recent snapd [08:59] ysionneau: on the upside ubu tu image official upstream is close to making first releases [09:13] zyga: "ubu tu image", that's the real name ? :D [09:14] 10:59 < zyga> ysionneau: that won't work with recent snapd < hmmm strange, I'm using an old ubuntu-image and a recent ubuntu-core :o [09:14] and it seems to work :o [09:15] morphis, hey [09:16] ysionneau: it might break at any time [09:19] ogra_: just a quick check, your all-snap pi3 image doesn't support the onboard wifi yet, right? [09:19] yeah, missing the firmware [09:20] i'll get to that once i have https://code.launchpad.net/~ogra/+snap/kernel-test-snap fully working (EOW i think) [09:28] zyga: when it will break, just updating my ubuntu-image will fix the issue? [09:29] ysionneau: you may need to remake the image [09:30] ogra_: any chance I can get the firmware manually in? [09:30] zyga: no problem, I remake the image each time I flash [09:30] morphis, you can unsquashfs the kernel snap, add the filesw and run snapcraft snap squashfs-root [09:31] then use the local kernel in u-d-f [09:31] yeah good idea [09:31] is this the official webdm repository (up to date?) ? : https://code.launchpad.net/~snappy-dev/snappy-hub/webdm [09:31] ysionneau: https://github.com/snapcore/snapweb is getting the new one [09:32] morphis: is this the current "webdm" package ? The one I can fetch by doing "sudo snap install webdm" ? [09:33] ysionneau: not sure, all I know is that webdm gets replaced by snap-web [09:33] ysionneau: I think the snap should be renamed to snapweb as well [09:33] but yes, that's the old webdm [09:34] hmm there is no "snapweb" snap in the store [09:34] but there is "webdm" [09:35] so far webdm works for me so I would like to use it, is it https://code.launchpad.net/~snappy-dev/snappy-hub/webdm ? [09:35] ysionneau: unlikely, try github.com/snapcore/snapweb perhaps [09:36] thanks [09:38] zyga: AH ok, it's the correct repository but webdm package got renamed to snapweb [09:38] https://github.com/snapcore/snapweb/commit/978fc76a95199aecb1ae735fe3c4459068eb9318 [09:38] right? [09:39] yes [09:40] * ysionneau thinking about what's easier between adding an interface to snapd, recompile, repack ubuntu-core. or modify snapweb to always install everything in devmode, recompile and repackage snapweb [09:41] one is the "clean way", the other might be easier [09:41] ysionneau: try my devtools [09:41] ysionneau: you can just compile and run fresh version directly [09:41] ysionneau: no rebuilding of any snaps required [09:41] ysionneau: see the docs there [09:42] ysionneau: that's *the* purpose of devtools, rapid interface development [09:43] zyga: I kind of get used to that :p [09:43] ah sorry was replying to something else [09:44] so, I recompile snapd and I push it via refresh-bits ? [09:44] ysionneau: refresh bits does all, just see what it does [09:44] k! [09:45] ysionneau: refresh-bits setup snap snapd run-snapd restore [09:45] ysionneau: with --host if needed [09:45] ysionneau: read the source, it's very easy to follow [09:45] ysionneau: note that run-snapd blocks, ctrl-c it to continue [09:46] cjwatson, bug 1610916 for you ... [09:46] Bug #1610916: s390x snap builds on launchpad fail with no build log [09:48] Thanks. [10:00] zyga: on debian-testing there is no systemd-activate - needed by refresh-bits [10:05] didrocks: heya [10:05] ysionneau: and hi [10:06] hey lool [10:08] pmp: I heard, any chance on how to trigger socket activation now? [10:08] s/chance/advice/ [10:13] zyga: I don't know much about systemd... sry [10:14] zyga: Plus I'm cross-compiling (well I try to) [10:15] pmp, no worries, thanks for letting me know [10:18] Hi there! === hikiko is now known as hikiko|ln [10:58] ogra_: Can you try an s390x build again? [10:59] ogra_: Firewall should be fixed, though there's still the exception-handling bug === chihchun is now known as chihchun_afk [10:59] cjwatson, triggered [10:59] https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/2574 [11:00] that looks better [11:00] You haven't hit the previous failure yet [11:00] ah, i thought the build didnt even start the last time [11:00] Oh, maybe [11:01] No, I think it started, but it crashed in such a way as to leave no log [11:01] So you wouldn't know unless you happened to be watching it [11:01] ah, k [11:03] just to check - anybody else working on a waf plugin (https://github.com/waf-project/waf) ? [11:03] I need that to try ntpsec, but wanted to avoid too much collisisons so I thought I poll for others that might work on it [11:04] cjwatson, ... so while this runs, i have another issue ... when i select Proposed from the LP UI and have picked a PPA as the archive, proposed isnt actually used unless the PPA is also enabled for proposed ... i.e. i can not get snapcraft from proposed for testing for example even though i pick it ... the UI option should set proposed regardless of the picked archive imho [11:05] (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:11] cjwatson, build is done, i got a buildlog link \o/ [11:12] hmm, but i get a "404 client error" from the store ... i wonder why [11:14] clicking the upload button manually uploads it fine ... strange [11:20] geez ... [11:20] Launchpad uploaded this snap package to the store, but the store failed to [11:20] scan it: [11:20] A file with this exact same content has already been uploaded [11:20] why did it tell me about the 404 error then ... :P [11:20] ogra_: proposed> please file a bug; I think I probably agree but doing anything about that will be a bit complicated [11:20] cjwatson, will do [11:22] [2016-08-08 11:11:45,875: DEBUG/Worker-1] "POST /dev/api/snap-push/ HTTP/1.1" 202 None [11:22] hmm, the above looks like a race in the store ... LP obviously uploaded it fine but the scanner tried to scan it to early or some such [11:22] [2016-08-08 11:11:45,988: DEBUG/Worker-1] "GET /dev/api/snaps/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7/builds/5ee23940-f5f8-49bb-9ab1-ec7b0bf4315d/status HTTP/1.1" 404 None [11:22] I think this must be an SCA bug. It should not be possible for it to return a status URL from snap-push that can't be immediately fetched. [11:22] yeah [11:22] I don't know about the "exact same content" thing. [11:23] cjwatson, well, that was mme manually clicking the "upload" button on LP ... my fault [11:23] i think i actually saw a bug fly by about the 404 error ... [11:23] Ah, right, because the 404 meant we thought it was retryable even though it actually wasn't. [11:23] * ogra_ digs his bugmail [11:23] Unfortunate. [11:23] yeah [11:24] cpaelzer: https://github.com/ubuntu/snappy-playpen/blob/master/mpv/parts/plugins/x-waf.py but it's very optiniated [11:26] looks like bug 1572963 [11:26] Bug #1572963: snapcraft upload can fail while monitoring scan status [11:28] hmm, or probably not ... but related at least [11:30] ah, because the original description was changed ... https://bugs.launchpad.net/snapcraft/+bug/1572963/comments/0 pretty much describes what i see [11:30] Bug #1572963: snapcraft upload can fail while monitoring scan status === hikiko|ln is now known as hikiko [11:52] sergiusens, not sure if bug 1610948 is for you or the store people [11:52] Bug #1610948: automated snap uploads from launchpad often cause pointless 404 errors [11:53] (i assigned to to SCA and snapcraft for now) [11:59] sigh ... === daker_ is now known as daker [11:59] the arm builders are really busy since last week ... [12:03] dz0ny: thanks for the link - I'm gonna take alook and maybe once I'm happy with the one I'm working on we can prep a PR for snapcraft === JanC is now known as Guest57323 === JanC_ is now known as JanC [12:18] zyga: I issued a pull-request for devtools, not sure if it is ok for all platforms - please review [12:18] zyga: I could cross-compile snapd with these changes on debian testing. [12:19] zyga: at least that what I think I did ;-) [12:25] zyga, f25 hasn't been bodhi activated yet [12:25] branching and the bodhi activation point are two different times [12:26] zyga: https://fedoraproject.org/wiki/Releases/25/Schedule [12:26] Bodhi activation is tomorrow [12:26] if everything makes it in today, we don't have to worry about bodhi for f25 [12:29] PR snapd#1648 opened: overlord,store: set store device authorization header [12:30] pmp: thanks, will do [12:30] Son_Goku: yep, I learned about that since asking :) [12:31] Son_Goku: I had a look at gettext but I was busy writing a blog post about snap-confine [12:31] Son_Goku: I cannot see anything wrong but I didn't check all of my email yet [12:41] Hi again [13:02] zyga, the issue with gettext is that there's a file that says it imports go-flags [13:02] but for whatever reason, it's not a dependency in gettext [13:04] zyga, the go-xgettext code uses it [13:05] actually, now I realize the thing [13:05] go-xgettext is an example program, isn't it? [13:06] jdstrand, are you around today ? [13:06] ogra_ the uploads from launchpad are driven by launchpad using the store api and not involving snapcraft at all [13:07] I'll make a note on the bug [13:07] sergiusens, thanks, feel free to invalidate it then [13:07] (teh snapcraft task) [13:07] zyga, actually, it looks like you need to add go-flags as a BR at least because it's used during the %check section [13:09] ogra_: you know directly which firmware files are missing? [13:09] Son_Goku: look now [13:09] morphis, not from the top of my head ... i think ppisati already packaged it though ... in his embedded ppa [13:10] Son_Goku: go-xgettext is a real xgettext replacement for golang sources [13:10] Son_Goku: it's a tool though you don't have to use it [13:10] ah [13:10] Son_Goku: the advantage over *gettext is that it parsers go code with go itself [13:10] ogra_: I see, thanks [13:10] Son_Goku: so it is more reliable [13:10] does it conflict with system gettext? [13:11] if not, why not slightly adjust the package so that it builds it and makes it available? [13:11] people might want to use it [13:11] Son_Goku: no, the binary is separate [13:11] Son_Goku: hmm, didn't I do exactly that? (me checks) [13:11] nope [13:11] you don't [13:11] I probably did that in suse [13:12] yeah, probably [13:12] sorry, I'll copy that change [13:12] okay, cool [13:12] be sure to update the bug with a comment indicating new changes, link the new srpm, and link to spec [13:12] yep, I'll do exactly [13:12] that [13:13] once you've done that, I can approve the package and you can push it [13:13] after I take a look at it, of course :P [13:14] yep, just looking at the suse version of the package to compare [13:14] gofed makes it a bit noisy [13:15] gofed was designed to automate packaging and updating golang libraries [13:15] as very early on, it looked like golang was going to turn into the same mess nodejs is with npm [13:16] it doesn't mean you get to switch your brain off entirely, as there are definitely certain aspects you should probably handle yourself if the package is slightly unusual [13:16] but it does make the process simpler [13:27] ogra_: also it looks like the pi3 doesn't get an IP address on subsequent boots [13:27] morphis, do you see an entry for the NIC in /etc/network/interfaces.d ? [13:28] need to pull the sdcard, sec [13:28] iirc there is still an issue with the firstboot job that doesnt always create the setup [13:28] I see the greenlight continously blinking [13:28] well, what do you see on the serial console ? :) [13:28] don't have one connected [13:28] :-) [13:29] but there is a e/n/i.d file [13:29] then it shold also get the NIC up [13:29] yes [13:29] ogra_: we're using predictable network iface names now? [13:29] are you sure it is the NIC itself or just i.e. ssh [13:30] we set net.ifnames=0 on the kernel cmdline ... [13:30] which should prevent "predictable" names [13:31] I get enxb827eb0c621b as eth name [13:31] ogra_: no, its the NIC [13:32] then i guess there iis a bug with the net.ifnames=0 recognition somewhere [13:32] otherwise nmap would find the host as up [13:32] (which i fear needs pitti input ... who is on vac.) [13:32] :-) [13:33] for the moment you can mv the eth0 file to the right name [13:33] that should get you up and running [13:33] the user experience of fedpkg vs using rpm* directly is staggering [13:34] most of the stuff that is annoying is fixed by fedpkg [13:34] hmm ... so i wonder if https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2575 will actually work now [13:35] but you cannot use it before you get the database updated :) [13:35] I might have totally missed if something like it is already available, but if a snap provides man pages "in" the snap - is (?could?) there be some auto-registration into man - so that man yousnap.command auto-maps and opens the matching snap manpage? [13:37] There's a bug for that [13:38] that will also onlly work on classic installs ... [13:38] Specifically bug 1575593 [13:38] Bug #1575593: Snappy installed manpages aren't accessible through man

[13:39] ogra_: Why? Is there a known plan to implement it? [13:39] (all-snap imges do not have man installed at all ... nor does the ubuntu-core snap itself ... on purpose) [13:39] thanks kalikiana and ogra_ [13:40] kalikiana, no idea, if there is any plan ... but it would need to happen by using the hosts "man" on classic and would need to detect if it is running on classic or an actual snappy image [13:42] zyga, the only thing I use rpmbuild for is making the SRPM [13:42] everything else is done with mock or fedpkg [13:42] Using the host makes no sense... you want the man pages of the binaries you actually run, regardless of whether they're in the core snap or any other snap. [13:42] kalikiana, well, you need the manpages in the man db and you need a man/groff binary [13:42] neither is available in ubuntu-core [13:43] and we will definitely not add it [13:43] (since the ubuntu-core snap is still megabytes to big) [13:43] ogra_: Can't all of that go to a man snap? [13:43] that could work, but then you only have man support if you have the man snap installled ... [13:44] and you get into trouble with mandb still ... since yu need to auto-update it for every snap [13:44] that requires some interaction between snaps that we dont have today [13:45] not saying it is impossible, but the interface you would need would be pretty complex [13:46] The obvious alternative would be a server - I use a script to do that today to read manpages of packages I don't have installed. But it only works for packages in the archive, so snaps wouldn't work. [13:46] Unless the store would extract man pages. [13:46] trying to run 'snapcraft cleanbuild' on my snap, but I'm getting "500 Internal Server Error"... here's the log ---> http://pastebin.ubuntu.com/22691796 my lxd otherwise appears sane [13:46] any idea what might be the problem? [13:48] Thinking about it, maybe I should snap that script [13:48] +1 [13:48] :) [13:49] ogra_: kalikiana: thanks for the discussion - I subscribed to the bug and will think about it a bit as well [13:49] ogra_: kalikiana: eventually /etc/manpath.config already has a path mapper, maybe we just have to find a way to append for installed snaps so the hosts mandb updates will pick it up [13:50] 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] jdstrand: hi [13:50] ogra_: sad but true, thanks for keeping the confinement thought up [13:51] you actually need an interface i think [13:53] arges: hey [13:54] ogra_: yes [13:54] jdstrand: https://github.com/snapcore/snapd/pull/1602#issuecomment-237949753 working on this PR. Even with apparmor rules allowing /proc/version_signature I can't seem to open the file... are there other permissions I need to worry about? [13:54] PR snapd#1602: interfaces: add kernel-module interface for module insertion [13:55] 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] arges: no. what are the permissions of the file from within the snap? [13:55] jdstrand: is there a simple way to check this.. i know there was a wrapper script at some point? [13:55] ogra_: yes. can you give me a list of snap names that should be auto-approved? [13:56] 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] ("confinement: strinct" i mean) [13:56] jdstrand, for now only ubuntu-core ... by EOW i can give you names for the kernel snaps [13:57] jdstrand, https://myapps.developer.ubuntu.com/dev/click-apps/4142/ [13:57] ogra_: ack, I'll take a look and handle all that [13:57] thanks ! [13:57] :) [13:59] arges: what I personall would do is create a 'sh' command in 'apps'. just copy the one from hello-world, adjust your yaml to copy it into place and expose it in 'apps' with whatever 'plugs' you need. then your-snap.sh and do whatever [13:59] arges: that's a handy method for testing. you can drive your other commands within confinement and iterate a bit easier [14:00] jdstrand: ok i've done it that way before... I remember there was a snap shell command, but didn't know if there was a better way todo it [14:00] there's another way that I know people have talked about. snap try or snap shell I think-- I don't know if those are implemented [14:01] jdstrand: ack i'll poke around and see what i can find. thanks [14:01] arges: I'm not 100% sure that is an exact runtime environment with try or shell [14:09] jdstrand: so, imagine I have an unix socket to communicate between a cli (running as a user) and a service (running so as root), any advice/idea where to put it to get both communicating? [14:09] I can use SNAP_COMMON + make it +w for everyone, but other opinions would be welcomed [14:09] (both ends are from the snap) [14:09] didrocks: I'd use /run [14:10] didrocks: one sec, let me check the template [14:10] didrocks: dholbach: do we have a snapcraft plugin for ant? [14:10] zyga: ah, they are common between apps from the same snaps? [14:10] mhall119: there is on built-in, yeah [14:10] mhall119: btw, snapcraft list-plugins :) [14:10] didrocks: yes though run may not be what you want [14:11] didrocks: also I should hit a publish button [14:11] didrocks: nice, thanks! [14:11] zyga: ;) well, we do use /run for this kind of socket communication on traditional desktop [14:11] mhall119: yw! [14:11] didrocks: http://www.zygoon.pl/2016/08/snap-execution-environment.html [14:11] fresh off my todo list [14:11] now let me check that run for you [14:12] thanks! I think there is a pattern like /run/snap. something in the apparmor profile [14:12] * didrocks reads the new blog post [14:13] sergiusens: when will snapcraft let me set envvars for a snap? That's blocking a few that are otherwise upstreamable [14:13] didrocks: it's not in the default template [14:13] didrocks: that's something we should consider improving [14:13] zyga: oh? indeed, sounds like it should be there [14:13] mhall119: when new snapd allows this, it's almost complete on this side [14:13] didrocks: I agree, I'll talk to jdstrand about this [14:14] zyga: oh, I thought it was just going to inject them into the generated wrapper === wililupy is now known as wililupy|travel [14:15] mhall119: I think that this falls under 'sensible defaults' as long as it doesn't allow IPC [14:15] mhall119: (across the snap boundary) [14:15] mhall119: similar to how we allow /dev/shm/... /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix, [14:16] mhall119: for cross snap IPC you always need an interface [14:16] yep! [14:16] uh, I just was to set SQLITE_TMPDIR=/tmp [14:16] jdstrand: ok... so I want my bash to have the same permissions as what 'daemon: simple' gives a program to see what it sees.. [14:16] mhall119: I guess zyga was talking to me :) [14:16] I hope so :) [14:16] * zyga needs to get his blog federated on planet arch linux [14:16] jdstrand: any suggestions for making this work with snap/snapcraft? [14:17] arges: it is just a systemd unit that runs your snap as root, with HOME set to /root and pretty much no change to how snaps otherwise execute [14:18] zyga: i'm trying to debug a daemon, and jdstrand suggested trying things as bash. So I'm trying to debug from the daemon perspective [14:18] adding 'bash -u root' to the command doesn't work, so trying to figure it out [14:19] arges: use the same plugs and execute 'sh' under sudo [14:19] arges: a few env variables aren't going to be the same but that should be good enough [14:20] jdstrand: so 'sudo su' in the snap bash shell doesn't work, so I'm guessing you mean change the command in the snapcraft.yaml to 'sudo su' ? [14:21] didrocks, zyga: /run/shm/snap.$SNAP_NAME.** is in the default template and can be used for cross-app communications, but not cross-snap communications [14:21] excellent, exactly what I wanted! [14:21] arges: sudo /snap/bin/your-thing.sh [14:21] thanks jdstrand [14:22] jdstrand: ok. using that i am able to read /proc/version_signature ... hmm [14:24] arges: check that the resulting security policy is sufficiently the same: diff -Naur /var/lib/snapd/profiles/snap.your-thing.daemon /var/lib/snapd/profiles/snap.your-thing.sh (and do the same for seccomp) [14:25] arges: if they are, then you might look at systemd to see if it is doing anything weird with /proc that it maybe shouldn't be [14:27] arges: or maybe there is a bug in your code... (hard to say, but the fact that 'sh' can access it suggests it is something outside of the sandbox that is causing the problem) [14:28] jdstrand: well it works running without snappy fwiw [14:28] i'll check the above [14:28] zyga: thanks for that blog series btw - really providing some extra insights once through the usual entry docs [14:31] jdstrand: no diff except for profile name. [14:35] cpaelzer: my pleasure, feel free to send me suggestions [14:35] jdstrand: hey, long time no see, how are you doing [14:36] jdstrand: I didn't notice the /run/shm part, just /dev/shm, is there any reason or plan for long term standarization of that? should we offer /run/snap.$SNAP_NAME.* ? [14:39] PR snapcraft#713 opened: rust plugin: mock downloads in unit tests [14:46] zyga: we do offer /run/snap.$SNAP_NAME.**. look at template.go [14:47]