[02:48] PR snapcraft#915 closed: cache: cleanup logic to pass project name [03:12] PR snapcraft#916 opened: sources: missing command instead of package [04:00] PR snapcraft#917 opened: wip === chihchun_afk is now known as chihchun === JanC_ is now known as JanC [06:51] PR snapcraft#918 opened: create the deltas package/class with xdetal generation implementation [07:06] bonjello [08:12] zyga: o/ [09:21] Mirv, when running the webbrowser-app snap that depends on ubuntu-app-platform, I’m seeing the following message at app shutdown: "libgcc_s.so.1 must be installed for pthread_cancel to work" [09:22] Mirv, and indeed, usr/lib/x86_64-linux-gnu/libgcc_s.so.1 is not included in the ubuntu-app-platform snap, do you know why? It should be, given that it’s a direct dependency of liboxideqt-qmlplugin [09:29] oSoMoN: the whole usr/lib is being exported, but it's not there. I guess you mean /lib/ ... [09:30] oSoMoN: it should be part of Ubuntu Core [09:30] oSoMoN: at least it looks to be for me [09:30] oSoMoN: so on my platform using snap there is /lib/x86_64-linux-gnu/libgcc_s.so.1 [09:31] Mirv, indeed it’s part of ubuntu-core, but it looks like the app is not seeing it for some reason [09:37] Mirv, I’ve reverted to the version of the webbrowser-app snap that ships all its dependencies (including oxide), and I’m not getting the error message about libgcc_s.so.1 [09:42] oSoMoN: I don't know how it'd be even possible to remove the Core's /lib path from the library search path. looking at the desktop-launch launcher, that also just adds new directories http://pastebin.ubuntu.com/23494754/ [09:43] oSoMoN: I assume your dep including snap has the $SNAP/lib/arch/libgcc_s.so.1 however? [09:43] oSoMoN: I could export the /lib too from platform snap and add it to LD_LIBRARY_PATH, but I was under impression that would make no sense [09:45] Mirv, I don’t think this should be necessary, it looks to me more like a bug in snappy itself, I’m filing a bug so we can track/investigate it [09:47] Mirv, https://bugs.launchpad.net/snappy/+bug/1642900 [09:47] Bug #1642900: libgcc_s.so.1 not found by app using ubuntu-app-platform content snap [09:47] Bug #1642900 opened: libgcc_s.so.1 not found by app using ubuntu-app-platform content snap === pachulo_ is now known as pachulo [10:24] hi, i have one question.. how a snap actually call the interface in another snap? I assume there should be some sort of IPC, right? [10:25] binchen: it depends on the interface, some interfaces sit on top of IPC mechanisms (say DBus), others sit on top of the filesystem [10:26] tvoss: and they are transparent to the user? [10:26] binchen think about an interface as a means to describe an interaction (arbitrary on purpose) and the permissions that are required to carry out the interaction [10:26] binchen: transparent as in? [10:27] I mean the user don't aware of or care about what the actually ipc is [10:28] and the producer thus are free the change the way the method is called.. [10:29] I come from a Android backgroud, and kind of trying to do a analogy here [10:30] in Android, a component can expose a service/interface through binder [10:31] and will always through binder.. [10:32] I'm not sure if it is correct to equivalent a snap interface to the Binder interface though [10:33] http://docs.ubuntu.com/core/en/reference/interfaces [10:49] binchen: not really, binder would be just another transport [10:50] binchen: and yes, to a user, the underlying implementation is transparent [10:51] tvoss: pierrchen@localhost:~$ snap interfaces camera [10:51] Slot Plug [10:52] is this expected? I'm using a kvm , and was trying to see what are included for the camera interface [10:52] I'm expecting see some kind of APIS. [10:52] but may be that expectation is wrong .. [10:52] binchen: it's not apis, more like functional blocks [10:52] binchen: an example would be location-observe [10:53] hmm... [10:53] so there is no need to know what are the APIs provided by a snap [10:53] or we just treat them as a whole function?? [10:54] binchen: well, as a package if you want so (to draw an equivalent to Android's java runtime) [10:54] binchen: so in the snap world, interfaces help to wire functional requirements together [10:54] basically, I'm trying to see how snaps are talk to each others [10:54] binchen: there is no canonical answer, depends on the functional block [10:55] especially, talk to the core snaps - iiuc, core snaps provided the core functionalitys such as camera, bluetooth, [10:55] binchen: trying to rephrase: there is not the IPC as in Android, but apps and services are free to use to cover their requirements [10:55] OK, what about the core snapps [10:55] binchen: nope, the core snap is really lightweight, camera, bluetooth and friends all come in via additional snaps [10:56] how a core snaps provided services to other "user snaps"? [10:56] OK [10:57] for the core snap specifically, that happens on a filesystem level. the core snap mostly exports libc (I'm oversimplifying here, but I think you get the message) [10:57] is it possible we have two camera snaps, all declare provide camera functionality? [10:57] binchen: sure [10:57] hm....won't there be problem, say both two camera snaps trying to use the /dev/vidoe nodes? [10:58] and they aren't aware of each other? [10:59] ah, now we get to an interesting point. sure, but that's where interfaces come in handy, too [10:59] I may still didn't get the exactly meaning of interface here. I thought it is just a interface as it normal mean in java, for example [11:00] nope, it is not an interface in the software engineering sense [11:00] yeah, I guess that is my biggest confusion so far :) [11:00] as a software person :) [11:00] it is hard to get my head around that.. [11:01] okay, so let me follow up on your camera example: simultaneous access to /dev/video* whatever is not possible, so you would need an intermediate service, right [11:01] binchen: no worries :) [11:01] "Interfaces allow snaps to communicate or share resources according to the protocol established by the interface. Each connection has two ends, a "plug" (consumer) and a "slot" (provider). A plug and a slot can be connected if they use the same interface name. The connection grants necessary permissions for snaps to operate according to the protocol." [11:01] from here http://docs.ubuntu.com/core/en/guides/build-device/interfaces [11:01] the intermediate service, e.g. camera-service snap, would use an interface camera-hw-access [11:01] so what exactly happen after the plug? [11:02] I can understand the concept of plug/slot [11:02] the interface camera-hw-access would contain code to make sure that camera-service can access /dev/video* [11:03] applications using the camera would then use camera-service, which in turn could provide a slot for camera-access (note the missing hw :)) [11:03] that make sense [11:04] just to make sure I understand you correctly, camera-hw-access is a snap right? [11:04] and it is not provided by canonical? could be anyone? [11:04] nope, camera-hw-access is an interface, that describes how security policy has to be setup to allow a snap with a camera-hw-access plug to access /dev/video* [11:04] how about camera-service snap? who will provided it? Can we have two? [11:05] binchen, sure, you can have two camera-service snaps, they both would have a plug for camera-hw-access [11:05] hha.. [11:06] so what exactly is the pierrchen@localhost:~$ snap interfaces [11:06] Slot Plug [11:06] :bluetooth-control - [11:06] :camera [11:06] the camera interface here? [11:07] is that the camera-hw or camera-service, or neither? [11:07] in that list, there is something providing a slot for interface camera [11:07] that's camera-hw [11:07] binchen: for reference: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/camera.go [11:07] cool!!! [11:07] I guess that is whant I want to check out [11:07] ack [11:08] so camera.go is obviously hw and super simple (just access to a bunch of device nodes) [11:09] a hypothetical camera-observe interface would be more sophisticated, capturing ipc specific requirements etc (in the example of camera service <-> apps) [11:12] is the only operation we can do to interface is to connect and disconnect? [11:14] and after connect it, you are able to access the resource (e.g the dev nodes in camrea interface) in that package> [11:15] yup, exactly [11:16] so, it's about security only [11:17] I checked other buildin interfaces [11:17] seems all AppArmor, SecComp related [11:18] so, what is the way to implement normal functionality/API exposing? [11:19] say one snap can do add(), substract() [11:19] and aonther snap want to use that functionality? [11:20] binchen: so we typically use dbus for that, but the choice is ultimately up to you :) [11:20] binchen: say you had your own idl/ddl and framework, you could use a unix socket as a transport [11:20] OK.. [11:21] I get it [11:21] so the snap is more focus on the security side of things [11:22] its not about the idl/binder/dbus stuff [11:22] binchen: the key thing really is: snappy does not have an opinion on the way communication is established, it just wants to know certain aspects about the connection (like security) to be able manage connections between plugs and slots for a given interface [11:22] binchen: precisely that [11:22] I finally get that! [11:22] binchen: *ideally* existing software would run unmodified. [11:23] yeah, otherwise, much bigger changes [11:23] to the legacy code [11:24] so snap is more a package innovation [11:24] not how you write your software :) [11:27] tvoss: really appreciate you taking your time answer my dumb questions! [11:28] binchen, happy to, and there is no such thing as a dumb question :) [11:28] I'm heading for bed now. it is 10:30PM. See you [11:28] binchen: see you :) have a good night [11:29] have a good day! [11:29] thx [11:30] PR snapcraft#916 closed: sources: missing command instead of package [11:33] PR snapcraft#912 closed: Add a gradle demo and test [11:57] what are other variables similar to $(DESTDIR) that can be used in custom Makefile's? specifically, I'm wondering if there is a variable that points to parts/$PAR_NAME/build directory? === chihchun is now known as chihchun_afk [13:08] iliv: it's a good question, by convention, this is BUILDDIR in the debian world, but it doesn't seem that snapcraft has anything like this [13:08] iliv: maybe time to open a feature request, you can override this in a custom plugin (inherited) meanwhile [13:17] didrocks, https://launchpad.net/snapcraft is this the project? [13:19] iliv: correct! [13:20] diddledan, okay, I'll create a feature request. What are other variables besides $DESTDIR, though? And where can I look them up? [13:25] davidcalle dholbach and/or didrocks mind looking at https://github.com/snapcore/snapcraft/pull/919 [13:25] PR snapcraft#919: docs: update GUI related integrations [13:25] iliv: I just grepped in the snapcraft code directly, like the cmake plugin at snapcraft/plugins/cmake.py [13:26] sergiusens: davidcalle will have a look (finishing a meeting right now) I think, thanks for the ping! [13:26] wait wait, are you a marketting manager now ? :) [13:26] * sergiusens does his Friday trol-lol-lol :-) [13:27] rohlalala :) [13:27] PR snapcraft#919 opened: docs: update GUI related integrations [13:27] * didrocks files more bugs on snapcraft as a revenge :) [13:28] didrocks I can just do what other projects do ;-) [13:28] wrt bugs [13:28] sergiusens: thanks, will have a look in a moment :) [13:29] davidcalle great, this will be fluctuating in the coming days as I implement declarative desktop files [13:30] sergiusens: 🎆 [13:30] sergiusens: tsssss, you wouldn't go that easy path, would you? :) [13:30] didrocks nah [14:03] tyhicks, jdstrand, is https://bugs.launchpad.net/snappy/+bug/1611078 actually fixed in xenial via #1628285 or is that separate? [14:03] Bug #1611078: Support snaps inside of lxd containers

Xenial):Confirmed> [14:03] Bug #1628285: apparmor should be allowed to start in containers

Trusty):Incomplete by tyhicks> [14:03] stgraber, and is it fixed in lxd on xenial? [14:04] * jdstrand defers to tyhicks [14:05] sergiusens, any luck on the pluggable engines for (stage|build)-packages? [14:07] mup: 1611078 is the bug the kernel portion was done under, I believe tyhicks is also doing the user space sru for under that as well [14:07] jjohansen: I apologize, but I'm pretty strict about only responding to known commands. [14:08] however you will note that the apparmor userspace component is not currently marked fix released for xenial [14:09] jjohansen, hence me asking [14:09] even the full set of srus, apparmor, kernel, lxd, and fuse there are still some bugs to iron out for some snaps [14:09] Chipaca: iirc there was still some verification to be done on the sru [14:10] fgimenez was trying to see if https://bugs.launchpad.net/snappy/+bug/1630789 was done, but to verify that from a xenial host is not possible because of this [14:10] Bug #1630789: normal users can't run snaps inside of LXD containers

[14:10]

[14:10] that is, there's no way for this one to be fixed before that one is fixed :-) [14:11] Chipaca: yeah, I would not call this fixed on xenal yep [14:12] fgimenez, I think I deserve a cookie for saving you some work. Shame I didn't notice you were doing this before... :-) [14:12] which does mean 160789 is not fixed either [14:12] jjohansen, that's fine, it's hairy but we'll get it sorted eventually [14:13] i don't mean to be rushing anybody, just that we know where we are [14:13] Chipaca: we are close [14:14] I'm not sure exactly what is left as tyhicks has been handling that while I try to squash bugs [14:15] jjohansen: hey, nice to see you again :) [14:15] hey zyga :) [14:25] Chipaca, a very big cookie, yes :) [15:16] jdstrand: hey! so, I'm wondering why your alsa snap doesn't work for me as a snap and works for you (and seb). My only plausible explanation is that the system aplay is using the gstreamer backend and forward it to it, while the version you are shipping don't have that backend and sends directly to the card… My card may not support multiple streams hence the "device is busy" message? [15:16] s/gstreamer/pulseaudio/ [15:17] didrocks: I don't know. I git cloned it, snapcrafted it, installed it and it worked [15:18] jdstrand: you didn't embeeded the pulseaudio configuration files on purpose though, right? [15:18] or that may be ubuntu patches? [15:18] didrocks: I don't know how the locking on all of that works. no I didn't. did they end up there? [15:19] didrocks: you saw the snapcraft.yaml, right? I literally stage-packages and ship a few alsa config files. that's it. no source code, nothing fancy [15:19] jdstrand: they are not in the snap while there is /usr/share/alsa/pulse-alsa.conf and /usr/share/alsa/alsa.conf.d/ [15:19] yeah, the alsa config files are cloned from upstream? [15:19] (not from our ubuntu package) [15:20] I thought you copied files from /usr/share/alsa and so, omitted the pulse thingy on purpose [15:21] didrocks: /usr/share/alsa/pulse-alsa.conf isn't going to be in the core snap though [15:21] didrocks: no. I grabbed those files from the ubuntu packaging [15:21] I was thinking on the file that you copied in etc/ [15:21] ah interesting [15:21] they are surely in the pulseaudio package [15:21] didrocks: and modified them to work well enough here [15:22] hum libasound2-plugins:amd64: /usr/share/alsa/alsa.conf.d/50-pulseaudio.conf [15:22] yeah [15:22] $ ls -lR /snap/alsa-utils/current/|grep pulse [15:22] jdstrand: I really wonder if this isn't card dependent… some accepting multiple streams, other not [15:22] [1] [15:22] there is nothing in the snap about pulse. I'm confused why you keep talking about pulseaudio files in /usr/share [15:23] sorry, I probably misexplained myself [15:23] I mean, feel free to try to put the pulseaudio file in there-- maybe that works, but since this was about accessing the device directly I was keeping pulseaudio out of it [15:23] so, my system aplay works well, but not the one from the snap "device is busy" with exactly the same parameters [15:24] I see. yeah, I don't know :) [15:24] the only difference I can think of is that the system aplay, in /usr/share/alsa/ has those pulseaudio config and so, forward it to pulseaudio [15:24] like I said, I'm not claiming anything about that snap except that it worked here enough to develop security policy for the interface [15:24] contrary to the one in the snap, and maybe my card isn't capable of handling multiple stream [15:24] yeah [15:25] if I can get it work and forward in pulseaudio, we may need 2 parts [15:25] once with alsa-with-pulseaudio [15:25] and one with alsa-only [15:25] ah, you are working on the part. ok, now things are making more sense to me :) [15:25] (one of the example is timidity, which only has alsa support) [15:25] yeah, but before working on the part, I need to get it working on my desktop :) [15:25] I suspect that would make sense-- to try to emulate what we are doing on Ubuntu [15:26] that's why, out of this theory, I don't understand why it's working for you and not for me [15:26] I just don't really have any experience with alsa [15:26] yeah, same :/ [15:26] didrocks: perhaps start by forking my branch and then adding those pulse files in usr/share/alsa (modifying as needed) [15:27] yeah [15:27] I need to add a lot of pulseaudio libs as well [15:27] for the module [15:28] davidcalle so are we good with snapcraft#919 [15:28] PR snapcraft#919: docs: update GUI related integrations [15:28] ? [15:28] jdstrand: I will just cross fingers that my theory is the correct one :) [15:33] didrocks: it wouldn't surprise me if it was. that is a big reason why things like pulseaudio exist-- limitations of hardware [15:33] yeah, let's cross fingers. I'll keep you posted [15:38] Chipaca: Hi - the apparmor userspace fix of bug #1628285 has already landed - I've just updated the bug [15:38] Bug #1628285: apparmor should be allowed to start in containers

Trusty):Incomplete by tyhicks> [15:39] Chipaca: last I checked, there was still a kernel change needed to allow fuse filesystems to be mounted inside of user namespaces [15:40] Chipaca: you'll probably want to check with stgraber on that remaining issue because, AFAIK, he was handling the squashfuse stuff [15:43] I believe you still need to manually install squashfuse, that's not something I can do much about though, I've requested the snapd team to make it a dependency quite a while ago... [15:43] for my part, I made sure squashfuse is available in xenial, yakkety and zesty [15:44] that's https://bugs.launchpad.net/snappy/+bug/1628289 which is still marked as New against snappy... [15:44] Bug #1628289: snapd should depend on squashfuse (for use in containers)

[15:56] sergiusens: yes, wfm [15:56] So I filed bug 1642350 about snapcraft in Launchpad silently ignoring a stage-package. Does anyone know why that would happen? [15:56] Bug #1642350: webbrowser-app silently being excluded from stage-packages [15:57] so quick question, related to https://github.com/snapcore/snapd/pull/2225, what happens if I add a "slots" entry which snapd doesn't know about yet? [15:57] PR snapd#2225: Implement lxd-client interface exposing the lxd snap (LP: #1634880) [15:58] I'd like to add "slots: [lxd]" to the lxd snap to make that ^ interface useful, but I don't want to suddenly break anyone who doesn't have a recent enough snapd [16:28] jdstrand: I think the only way to get something clean is to rebuild alsa-lib (but I don't know how to not hardcode /snap). There is no way to define a dynamic plugin directory (for the pulse one) [16:29] even adding to LD_LIBRARY_PATH, it's still looking at it in /usr/lib… [16:29] didrocks: boo :) [16:29] didrocks: at least that can be done in a part... [16:30] jdstrand: yeah… I have a very very big hammer workaround for the deadline at least [16:42] jdstrand: https://github.com/snapcore/snap-confine/pull/183 [16:42] PR snap-confine#183: Detach the hostfs version of /sys [16:42] jdstrand: a trivial branch that may unbreak docker [16:43] jdstrand: the diff is long because of test data changes (but in very expected ways) [16:43] jdstrand: looking at this I'd like to do /dev and /proc as well, this would cut down on weird filesystems showing up twice [16:44] jdstrand: once this lands I'll run a pass of snapd tests against snap-confine master [16:44] jdstrand: and a related apparmor question, is there a confinement option for umount to say unount but only when MNT_DETACH was passed? [16:46] lool: ^^ any opinions on /dev and /proc [16:47] zyga: I'd suggest doign the same on devpts, dev and proc [16:47] seems consistent since these aren't accessible anyway [16:47] lool: all of /dev (includes devpts) [16:48] lool: yeah, I'll follow up after I get a +1 from jdstrand [16:48] (or tyhicks if he wants to look) [16:48] ok; I usually have to bind mount devpts separately in chroots, but I dont know about mount namespaces behavior there [16:48] lool: we have that in /dev [16:48] lool: this is the one from "outside" that nobody is supposed to use anyway [16:49] lool: I think that it makes sense, we want access to host / classic files (e.g. fonts) but not to the duplicated fileystems like /proc which we bind mount anyway [16:49] can I get an unconfined shell in the right namespace with snap run? [16:50] lool: easily with nsenter [16:50] lool: not with snap-confine [16:51] lool: just try nsenter -m/var/lib/snapd/ns/$SNAP_NAME.mnt [16:51] lool: very useful! [16:51] lool: you cannot have a space after -m, it's totally annoying [16:51] er [16:51] sorry [16:51] zyga: can you answer my earlier question? Is it safe to add "slots: [lxd]" to the lxd snap even if some/most snapd don't know what that interface is yet? [16:51] lool: that path is /run/snapd/.ns/$SNAP_NAME.mnt [16:52] stgraber: sorry I didn't see that earlier, the answer is 1) yes 2) it must not clash with any plug (plug and slot names must be unique in one snap) 3) the store will choke on that [16:52] stgraber: snapd ignores unknown interfaces [16:52] zyga: sounds good [16:52] zyga: that's great, cause I could now confirm that this fixes docker [16:52] umount --lazy /var/lib/snapd/hostfs/sys [16:53] lool: great to know, please add this to the pull request [16:53] zyga: ack, I'll look. I don't see anything in man apparmor.d about detach [16:53] lool: I plan to work on live namespace mutation soon after classic confinement, what you just did will be done by snapd on interface changes :) [16:53] zyga: and also that unmont dev along is enough [16:53] zyga: jjohansen would know for sure (he'll be back later) [16:54] lool: thanks [16:54] zyga and lool: note that snap-confine has special handling of devpts [16:54] right [16:58] Hey, do we know if there is a weechat snap or a WIP of one? [16:58] i checked uappexplorer, not sure if there's a better place to look [16:58] before i tackled snapping up weechat i thought it would be best to ask the community at large [16:59] zyga: these are the fses I would expect apps to try to access, but there might be more and generally this pollutes mount output; would you be able to simply unmount everything under /var/lib/snapd/hostfs? [16:59] lazyPower: not that I know of. I would be interested by it, running weechat currently :) [16:59] didrocks patch-pilot me? :D [16:59] zyga: ok, approved. now can you reciprocate and review 181 and 182? [16:59] lool: I could detach all of hostfs [16:59] zyga: :) [17:00] jdstrand: yes! [17:00] jdstrand: taking my laptop on the go and going to review those two [17:00] lazyPower: heh, with pleasure! (but not today, EOW now ;)) [17:00] lazyPower: I don't think it would be complex [17:00] ack, i'll circle back on Monday with my WIP didrocks [17:00] (famous last words…) [17:00] yeah ;) [17:00] i tried this before and ran into issues with the addons [17:00] it was the perl/tcl backend stuff iirc [17:00] zyga: sure, please don't have it interrupt your evening or weekend [17:00] right, that's my fear [17:00] but i nuked that disk and didnt have it pushed anywhere, like a swell developer making swell decisions :| [17:01] lazyPower: classical :) [17:01] lazyPower: good luck then and talk to you on Monday! :) [17:04] jdstrand: no worries, I'm not working today but since I love my job I'm doing it anyway :) [17:15] zyga: ok, well, only if you love my PRs can you work on them :) [17:15] zyga: seriously though, thank you :) [17:16] jdstrand: my pleasure :) [17:38] I am building a snap that has a package that build 7 tools in the /usr/local/bin and /usr/local/sbin and would like to expose all of them. Is there a way to wildcard the the app command? I have done this already with filesets and stage being $binaries and snap being $binaries. [17:38] roadmr: can you pull r798? no code changes, just an update to the base declaration that has the new interfaces that were committed this week [17:38] snap_question: no, you have to mention each one separately [17:39] so I tried to do that but I ran into an issue where I would have to do packagename.executable1 , packagename.executable2 [17:39] and so on to get each executable to run [17:42] snap_question: yes, that is a limitation of the current implementation. you get one 'top' command such that if the command name is the same as the snap name, you may refer to it as 'snapname' rather than 'snapname.command' [17:42] snap_question: work is actively underway to make it possible to remove that restriction [17:42] jdstrand: sure thing [17:42] there may be a bug on it [17:44] snap_question: https://bugs.launchpad.net/snappy/+bug/1607748 [17:44] Bug #1607748: Ability to use two registered names for the same snap [17:45]