| mup | PR snapcraft#915 closed: cache: cleanup logic to pass project name <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/915> | 02:48 |
|---|---|---|
| mup | PR snapcraft#916 opened: sources: missing command instead of package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/916> | 03:12 |
| mup | PR snapcraft#917 opened: wip <Created by elopio> <https://github.com/snapcore/snapcraft/pull/917> | 04:00 |
| === chihchun_afk is now known as chihchun | ||
| === JanC_ is now known as JanC | ||
| mup | PR snapcraft#918 opened: create the deltas package/class with xdetal generation implementation <Created by seawaywen> <https://github.com/snapcore/snapcraft/pull/918> | 06:51 |
| foxmask | bonjello | 07:06 |
| tvoss | zyga: o/ | 08:12 |
| oSoMoN | 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:21 |
| oSoMoN | 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:22 |
| Mirv | oSoMoN: the whole usr/lib is being exported, but it's not there. I guess you mean /lib/ ... | 09:29 |
| Mirv | oSoMoN: it should be part of Ubuntu Core | 09:30 |
| Mirv | oSoMoN: at least it looks to be for me | 09:30 |
| Mirv | oSoMoN: so on my platform using snap there is /lib/x86_64-linux-gnu/libgcc_s.so.1 | 09:30 |
| oSoMoN | Mirv, indeed it’s part of ubuntu-core, but it looks like the app is not seeing it for some reason | 09:31 |
| oSoMoN | 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:37 |
| Mirv | 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:42 |
| Mirv | oSoMoN: I assume your dep including snap has the $SNAP/lib/arch/libgcc_s.so.1 however? | 09:43 |
| Mirv | 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:43 |
| oSoMoN | 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:45 |
| oSoMoN | Mirv, https://bugs.launchpad.net/snappy/+bug/1642900 | 09:47 |
| mup | Bug #1642900: libgcc_s.so.1 not found by app using ubuntu-app-platform content snap <Snappy:New> <https://launchpad.net/bugs/1642900> | 09:47 |
| mup | Bug #1642900 opened: libgcc_s.so.1 not found by app using ubuntu-app-platform content snap <Snappy:New> <https://launchpad.net/bugs/1642900> | 09:47 |
| === pachulo_ is now known as pachulo | ||
| binchen | 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:24 |
| tvoss | binchen: it depends on the interface, some interfaces sit on top of IPC mechanisms (say DBus), others sit on top of the filesystem | 10:25 |
| binchen | tvoss: and they are transparent to the user? | 10:26 |
| tvoss | 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 |
| tvoss | binchen: transparent as in? | 10:26 |
| binchen | I mean the user don't aware of or care about what the actually ipc is | 10:27 |
| binchen | and the producer thus are free the change the way the method is called.. | 10:28 |
| binchen | I come from a Android backgroud, and kind of trying to do a analogy here | 10:29 |
| binchen | in Android, a component can expose a service/interface through binder | 10:30 |
| binchen | and will always through binder.. | 10:31 |
| binchen | I'm not sure if it is correct to equivalent a snap interface to the Binder interface though | 10:32 |
| binchen | http://docs.ubuntu.com/core/en/reference/interfaces | 10:33 |
| tvoss | binchen: not really, binder would be just another transport | 10:49 |
| tvoss | binchen: and yes, to a user, the underlying implementation is transparent | 10:50 |
| binchen | tvoss: pierrchen@localhost:~$ snap interfaces camera | 10:51 |
| binchen | Slot Plug | 10:51 |
| binchen | is this expected? I'm using a kvm , and was trying to see what are included for the camera interface | 10:52 |
| binchen | I'm expecting see some kind of APIS. | 10:52 |
| binchen | but may be that expectation is wrong .. | 10:52 |
| tvoss | binchen: it's not apis, more like functional blocks | 10:52 |
| tvoss | binchen: an example would be location-observe | 10:52 |
| binchen | hmm... | 10:53 |
| binchen | so there is no need to know what are the APIs provided by a snap | 10:53 |
| binchen | or we just treat them as a whole function?? | 10:53 |
| tvoss | binchen: well, as a package if you want so (to draw an equivalent to Android's java runtime) | 10:54 |
| tvoss | binchen: so in the snap world, interfaces help to wire functional requirements together | 10:54 |
| binchen | basically, I'm trying to see how snaps are talk to each others | 10:54 |
| tvoss | binchen: there is no canonical answer, depends on the functional block | 10:54 |
| binchen | especially, talk to the core snaps - iiuc, core snaps provided the core functionalitys such as camera, bluetooth, | 10:55 |
| tvoss | 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 |
| binchen | OK, what about the core snapps | 10:55 |
| tvoss | binchen: nope, the core snap is really lightweight, camera, bluetooth and friends all come in via additional snaps | 10:55 |
| binchen | how a core snaps provided services to other "user snaps"? | 10:56 |
| binchen | OK | 10:56 |
| tvoss | 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 |
| binchen | is it possible we have two camera snaps, all declare provide camera functionality? | 10:57 |
| tvoss | binchen: sure | 10:57 |
| binchen | hm....won't there be problem, say both two camera snaps trying to use the /dev/vidoe nodes? | 10:57 |
| binchen | and they aren't aware of each other? | 10:58 |
| tvoss | ah, now we get to an interesting point. sure, but that's where interfaces come in handy, too | 10:59 |
| binchen | 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 | 10:59 |
| tvoss | nope, it is not an interface in the software engineering sense | 11:00 |
| binchen | yeah, I guess that is my biggest confusion so far :) | 11:00 |
| binchen | as a software person :) | 11:00 |
| binchen | it is hard to get my head around that.. | 11:00 |
| tvoss | 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 |
| tvoss | binchen: no worries :) | 11:01 |
| binchen | "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 |
| binchen | from here http://docs.ubuntu.com/core/en/guides/build-device/interfaces | 11:01 |
| tvoss | the intermediate service, e.g. camera-service snap, would use an interface camera-hw-access | 11:01 |
| binchen | so what exactly happen after the plug? | 11:01 |
| binchen | I can understand the concept of plug/slot | 11:02 |
| tvoss | the interface camera-hw-access would contain code to make sure that camera-service can access /dev/video* | 11:02 |
| tvoss | 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 |
| binchen | that make sense | 11:03 |
| binchen | just to make sure I understand you correctly, camera-hw-access is a snap right? | 11:04 |
| binchen | and it is not provided by canonical? could be anyone? | 11:04 |
| tvoss | 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 |
| binchen | how about camera-service snap? who will provided it? Can we have two? | 11:04 |
| tvoss | binchen, sure, you can have two camera-service snaps, they both would have a plug for camera-hw-access | 11:05 |
| binchen | hha.. | 11:05 |
| binchen | so what exactly is the pierrchen@localhost:~$ snap interfaces | 11:06 |
| binchen | Slot Plug | 11:06 |
| binchen | :bluetooth-control - | 11:06 |
| binchen | :camera | 11:06 |
| binchen | the camera interface here? | 11:06 |
| binchen | is that the camera-hw or camera-service, or neither? | 11:07 |
| tvoss | in that list, there is something providing a slot for interface camera | 11:07 |
| tvoss | that's camera-hw | 11:07 |
| tvoss | binchen: for reference: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/camera.go | 11:07 |
| binchen | cool!!! | 11:07 |
| binchen | I guess that is whant I want to check out | 11:07 |
| tvoss | ack | 11:07 |
| tvoss | so camera.go is obviously hw and super simple (just access to a bunch of device nodes) | 11:08 |
| tvoss | a hypothetical camera-observe interface would be more sophisticated, capturing ipc specific requirements etc (in the example of camera service <-> apps) | 11:09 |
| binchen | is the only operation we can do to interface is to connect and disconnect? | 11:12 |
| binchen | and after connect it, you are able to access the resource (e.g the dev nodes in camrea interface) in that package> | 11:14 |
| tvoss | yup, exactly | 11:15 |
| binchen | so, it's about security only | 11:16 |
| binchen | I checked other buildin interfaces | 11:17 |
| binchen | seems all AppArmor, SecComp related | 11:17 |
| binchen | so, what is the way to implement normal functionality/API exposing? | 11:18 |
| binchen | say one snap can do add(), substract() | 11:19 |
| binchen | and aonther snap want to use that functionality? | 11:19 |
| tvoss | binchen: so we typically use dbus for that, but the choice is ultimately up to you :) | 11:20 |
| tvoss | binchen: say you had your own idl/ddl and framework, you could use a unix socket as a transport | 11:20 |
| binchen | OK.. | 11:20 |
| binchen | I get it | 11:21 |
| binchen | so the snap is more focus on the security side of things | 11:21 |
| binchen | its not about the idl/binder/dbus stuff | 11:22 |
| tvoss | 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 |
| tvoss | binchen: precisely that | 11:22 |
| binchen | I finally get that! | 11:22 |
| tvoss | binchen: *ideally* existing software would run unmodified. | 11:22 |
| binchen | yeah, otherwise, much bigger changes | 11:23 |
| binchen | to the legacy code | 11:23 |
| binchen | so snap is more a package innovation | 11:24 |
| binchen | not how you write your software :) | 11:24 |
| binchen | tvoss: really appreciate you taking your time answer my dumb questions! | 11:27 |
| tvoss | binchen, happy to, and there is no such thing as a dumb question :) | 11:28 |
| binchen | I'm heading for bed now. it is 10:30PM. See you | 11:28 |
| tvoss | binchen: see you :) have a good night | 11:28 |
| binchen | have a good day! | 11:29 |
| tvoss | thx | 11:29 |
| mup | PR snapcraft#916 closed: sources: missing command instead of package <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/916> | 11:30 |
| mup | PR snapcraft#912 closed: Add a gradle demo and test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/912> | 11:33 |
| iliv | 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? | 11:57 |
| === chihchun is now known as chihchun_afk | ||
| didrocks | 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 |
| didrocks | iliv: maybe time to open a feature request, you can override this in a custom plugin (inherited) meanwhile | 13:08 |
| iliv | didrocks, https://launchpad.net/snapcraft is this the project? | 13:17 |
| didrocks | iliv: correct! | 13:19 |
| iliv | diddledan, okay, I'll create a feature request. What are other variables besides $DESTDIR, though? And where can I look them up? | 13:20 |
| sergiusens | davidcalle dholbach and/or didrocks mind looking at https://github.com/snapcore/snapcraft/pull/919 | 13:25 |
| mup | PR snapcraft#919: docs: update GUI related integrations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/919> | 13:25 |
| didrocks | iliv: I just grepped in the snapcraft code directly, like the cmake plugin at snapcraft/plugins/cmake.py | 13:25 |
| didrocks | sergiusens: davidcalle will have a look (finishing a meeting right now) I think, thanks for the ping! | 13:26 |
| sergiusens | wait wait, are you a marketting manager now ? :) | 13:26 |
| * sergiusens does his Friday trol-lol-lol :-) | 13:26 | |
| didrocks | rohlalala :) | 13:27 |
| mup | PR snapcraft#919 opened: docs: update GUI related integrations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/919> | 13:27 |
| * didrocks files more bugs on snapcraft as a revenge :) | 13:27 | |
| sergiusens | didrocks I can just do what other projects do ;-) | 13:28 |
| sergiusens | wrt bugs | 13:28 |
| davidcalle | sergiusens: thanks, will have a look in a moment :) | 13:28 |
| sergiusens | davidcalle great, this will be fluctuating in the coming days as I implement declarative desktop files | 13:29 |
| davidcalle | sergiusens: 🎆 | 13:30 |
| didrocks | sergiusens: tsssss, you wouldn't go that easy path, would you? :) | 13:30 |
| sergiusens | didrocks nah | 13:30 |
| Chipaca | tyhicks, jdstrand, is https://bugs.launchpad.net/snappy/+bug/1611078 actually fixed in xenial via #1628285 or is that separate? | 14:03 |
| mup | Bug #1611078: Support snaps inside of lxd containers <landscape> <lxd> <nova-lxd> <verification-failed-xenial> <Snappy:Fix Released by stgraber> <apparmor (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu):Fix Released by jjohansen> <lxd (Ubuntu):Fix Released by stgraber> <apparmor (Ubuntu | 14:03 |
| mup | Xenial):Confirmed> <linux (Ubuntu Xenial):Fix Released by jjohansen> <lxd (Ubuntu Xenial):Fix Committed> <apparmor (Ubuntu Yakkety):Fix Released by tyhicks> <linux (Ubuntu Yakkety):Fix Released by jjohansen> <lxd (Ubuntu Yakkety):Fix Released by stgraber> <https://launchpad.net/bugs/1611078> | 14:03 |
| mup | Bug #1628285: apparmor should be allowed to start in containers <lxd> <verification-done> <apparmor (Ubuntu):Fix Released by tyhicks> <upstart (Ubuntu):Invalid> <apparmor (Ubuntu | 14:03 |
| mup | Trusty):Incomplete by tyhicks> <upstart (Ubuntu Trusty):Incomplete by tyhicks> <apparmor (Ubuntu Xenial):Fix Released by tyhicks> <https://launchpad.net/bugs/1628285> | 14:03 |
| Chipaca | stgraber, and is it fixed in lxd on xenial? | 14:03 |
| * jdstrand defers to tyhicks | 14:04 | |
| Son_Goku | sergiusens, any luck on the pluggable engines for (stage|build)-packages? | 14:05 |
| jjohansen | 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 |
| mup | jjohansen: I apologize, but I'm pretty strict about only responding to known commands. | 14:07 |
| jjohansen | however you will note that the apparmor userspace component is not currently marked fix released for xenial | 14:08 |
| Chipaca | jjohansen, hence me asking | 14:09 |
| jjohansen | even the full set of srus, apparmor, kernel, lxd, and fuse there are still some bugs to iron out for some snaps | 14:09 |
| jjohansen | Chipaca: iirc there was still some verification to be done on the sru | 14:09 |
| Chipaca | 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 |
| mup | Bug #1630789: normal users can't run snaps inside of LXD containers <verification-needed> <Snappy Launcher:Fix Released by jdstrand> <Snappy:In Progress by tyhicks> <snap-confine (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu):Fix Released by tyhicks> <snap-confine (Ubuntu Xenial):Fix Committed> | 14:10 |
| mup | <snap-confine (Ubuntu Yakkety):Fix Committed> <https://launchpad.net/bugs/1630789> | 14:10 |
| Chipaca | that is, there's no way for this one to be fixed before that one is fixed :-) | 14:10 |
| jjohansen | Chipaca: yeah, I would not call this fixed on xenal yep | 14:11 |
| Chipaca | fgimenez, I think I deserve a cookie for saving you some work. Shame I didn't notice you were doing this before... :-) | 14:12 |
| jjohansen | which does mean 160789 is not fixed either | 14:12 |
| Chipaca | jjohansen, that's fine, it's hairy but we'll get it sorted eventually | 14:12 |
| Chipaca | i don't mean to be rushing anybody, just that we know where we are | 14:13 |
| jjohansen | Chipaca: we are close | 14:13 |
| jjohansen | I'm not sure exactly what is left as tyhicks has been handling that while I try to squash bugs | 14:14 |
| zyga | jjohansen: hey, nice to see you again :) | 14:15 |
| jjohansen | hey zyga :) | 14:15 |
| fgimenez | Chipaca, a very big cookie, yes :) | 14:25 |
| didrocks | 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 |
| didrocks | s/gstreamer/pulseaudio/ | 15:16 |
| jdstrand | didrocks: I don't know. I git cloned it, snapcrafted it, installed it and it worked | 15:17 |
| didrocks | jdstrand: you didn't embeeded the pulseaudio configuration files on purpose though, right? | 15:18 |
| didrocks | or that may be ubuntu patches? | 15:18 |
| jdstrand | didrocks: I don't know how the locking on all of that works. no I didn't. did they end up there? | 15:18 |
| jdstrand | 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 |
| didrocks | 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 |
| didrocks | yeah, the alsa config files are cloned from upstream? | 15:19 |
| didrocks | (not from our ubuntu package) | 15:19 |
| didrocks | I thought you copied files from /usr/share/alsa and so, omitted the pulse thingy on purpose | 15:20 |
| jdstrand | didrocks: /usr/share/alsa/pulse-alsa.conf isn't going to be in the core snap though | 15:21 |
| jdstrand | didrocks: no. I grabbed those files from the ubuntu packaging | 15:21 |
| didrocks | I was thinking on the file that you copied in etc/ | 15:21 |
| didrocks | ah interesting | 15:21 |
| didrocks | they are surely in the pulseaudio package | 15:21 |
| jdstrand | didrocks: and modified them to work well enough here | 15:21 |
| didrocks | hum libasound2-plugins:amd64: /usr/share/alsa/alsa.conf.d/50-pulseaudio.conf | 15:22 |
| didrocks | yeah | 15:22 |
| jdstrand | $ ls -lR /snap/alsa-utils/current/|grep pulse | 15:22 |
| didrocks | jdstrand: I really wonder if this isn't card dependent… some accepting multiple streams, other not | 15:22 |
| jdstrand | [1] | 15:22 |
| jdstrand | there is nothing in the snap about pulse. I'm confused why you keep talking about pulseaudio files in /usr/share | 15:22 |
| didrocks | sorry, I probably misexplained myself | 15:23 |
| jdstrand | 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 |
| didrocks | so, my system aplay works well, but not the one from the snap "device is busy" with exactly the same parameters | 15:23 |
| jdstrand | I see. yeah, I don't know :) | 15:24 |
| didrocks | 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 |
| jdstrand | 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 |
| didrocks | contrary to the one in the snap, and maybe my card isn't capable of handling multiple stream | 15:24 |
| didrocks | yeah | 15:24 |
| didrocks | if I can get it work and forward in pulseaudio, we may need 2 parts | 15:25 |
| didrocks | once with alsa-with-pulseaudio | 15:25 |
| didrocks | and one with alsa-only | 15:25 |
| jdstrand | ah, you are working on the part. ok, now things are making more sense to me :) | 15:25 |
| didrocks | (one of the example is timidity, which only has alsa support) | 15:25 |
| didrocks | yeah, but before working on the part, I need to get it working on my desktop :) | 15:25 |
| jdstrand | I suspect that would make sense-- to try to emulate what we are doing on Ubuntu | 15:25 |
| didrocks | that's why, out of this theory, I don't understand why it's working for you and not for me | 15:26 |
| jdstrand | I just don't really have any experience with alsa | 15:26 |
| didrocks | yeah, same :/ | 15:26 |
| jdstrand | didrocks: perhaps start by forking my branch and then adding those pulse files in usr/share/alsa (modifying as needed) | 15:26 |
| didrocks | yeah | 15:27 |
| didrocks | I need to add a lot of pulseaudio libs as well | 15:27 |
| didrocks | for the module | 15:27 |
| sergiusens | davidcalle so are we good with snapcraft#919 | 15:28 |
| mup | PR snapcraft#919: docs: update GUI related integrations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/919> | 15:28 |
| sergiusens | ? | 15:28 |
| didrocks | jdstrand: I will just cross fingers that my theory is the correct one :) | 15:28 |
| jdstrand | didrocks: it wouldn't surprise me if it was. that is a big reason why things like pulseaudio exist-- limitations of hardware | 15:33 |
| didrocks | yeah, let's cross fingers. I'll keep you posted | 15:33 |
| tyhicks | Chipaca: Hi - the apparmor userspace fix of bug #1628285 has already landed - I've just updated the bug | 15:38 |
| mup | Bug #1628285: apparmor should be allowed to start in containers <lxd> <verification-done> <apparmor (Ubuntu):Fix Released by tyhicks> <upstart (Ubuntu):Invalid> <apparmor (Ubuntu | 15:38 |
| mup | Trusty):Incomplete by tyhicks> <upstart (Ubuntu Trusty):Incomplete by tyhicks> <apparmor (Ubuntu Xenial):Fix Released by tyhicks> <https://launchpad.net/bugs/1628285> | 15:38 |
| tyhicks | Chipaca: last I checked, there was still a kernel change needed to allow fuse filesystems to be mounted inside of user namespaces | 15:39 |
| tyhicks | Chipaca: you'll probably want to check with stgraber on that remaining issue because, AFAIK, he was handling the squashfuse stuff | 15:40 |
| stgraber | 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 |
| stgraber | for my part, I made sure squashfuse is available in xenial, yakkety and zesty | 15:43 |
| stgraber | that's https://bugs.launchpad.net/snappy/+bug/1628289 which is still marked as New against snappy... | 15:44 |
| mup | Bug #1628289: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:New> <squashfuse (Ubuntu):Fix Released by stgraber> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289> | 15:44 |
| davidcalle | sergiusens: yes, wfm | 15:56 |
| mterry | So I filed bug 1642350 about snapcraft in Launchpad silently ignoring a stage-package. Does anyone know why that would happen? | 15:56 |
| mup | Bug #1642350: webbrowser-app silently being excluded from stage-packages <Snapcraft:New> <https://launchpad.net/bugs/1642350> | 15:56 |
| stgraber | 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 |
| mup | PR snapd#2225: Implement lxd-client interface exposing the lxd snap (LP: #1634880) <Created by kalikiana> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2225> | 15:57 |
| stgraber | 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 | 15:58 |
| didrocks | 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:28 |
| didrocks | even adding to LD_LIBRARY_PATH, it's still looking at it in /usr/lib… | 16:29 |
| jdstrand | didrocks: boo :) | 16:29 |
| jdstrand | didrocks: at least that can be done in a part... | 16:29 |
| didrocks | jdstrand: yeah… I have a very very big hammer workaround for the deadline at least | 16:30 |
| zyga | jdstrand: https://github.com/snapcore/snap-confine/pull/183 | 16:42 |
| mup | PR snap-confine#183: Detach the hostfs version of /sys <Created by zyga> <https://github.com/snapcore/snap-confine/pull/183> | 16:42 |
| zyga | jdstrand: a trivial branch that may unbreak docker | 16:42 |
| zyga | jdstrand: the diff is long because of test data changes (but in very expected ways) | 16:43 |
| zyga | 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:43 |
| zyga | jdstrand: once this lands I'll run a pass of snapd tests against snap-confine master | 16:44 |
| zyga | jdstrand: and a related apparmor question, is there a confinement option for umount to say unount but only when MNT_DETACH was passed? | 16:44 |
| zyga | lool: ^^ any opinions on /dev and /proc | 16:46 |
| lool | zyga: I'd suggest doign the same on devpts, dev and proc | 16:47 |
| lool | seems consistent since these aren't accessible anyway | 16:47 |
| zyga | lool: all of /dev (includes devpts) | 16:47 |
| zyga | lool: yeah, I'll follow up after I get a +1 from jdstrand | 16:48 |
| zyga | (or tyhicks if he wants to look) | 16:48 |
| lool | ok; I usually have to bind mount devpts separately in chroots, but I dont know about mount namespaces behavior there | 16:48 |
| zyga | lool: we have that in /dev | 16:48 |
| zyga | lool: this is the one from "outside" that nobody is supposed to use anyway | 16:48 |
| zyga | 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 |
| lool | can I get an unconfined shell in the right namespace with snap run? | 16:49 |
| zyga | lool: easily with nsenter | 16:50 |
| zyga | lool: not with snap-confine | 16:50 |
| zyga | lool: just try nsenter -m/var/lib/snapd/ns/$SNAP_NAME.mnt | 16:51 |
| zyga | lool: very useful! | 16:51 |
| zyga | lool: you cannot have a space after -m, it's totally annoying | 16:51 |
| zyga | er | 16:51 |
| zyga | sorry | 16:51 |
| stgraber | 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 |
| zyga | lool: that path is /run/snapd/.ns/$SNAP_NAME.mnt | 16:51 |
| zyga | 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 |
| zyga | stgraber: snapd ignores unknown interfaces | 16:52 |
| stgraber | zyga: sounds good | 16:52 |
| lool | zyga: that's great, cause I could now confirm that this fixes docker | 16:52 |
| lool | umount --lazy /var/lib/snapd/hostfs/sys | 16:52 |
| zyga | lool: great to know, please add this to the pull request | 16:53 |
| jdstrand | zyga: ack, I'll look. I don't see anything in man apparmor.d about detach | 16:53 |
| zyga | 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 |
| lool | zyga: and also that unmont dev along is enough | 16:53 |
| jdstrand | zyga: jjohansen would know for sure (he'll be back later) | 16:53 |
| zyga | lool: thanks | 16:54 |
| jdstrand | zyga and lool: note that snap-confine has special handling of devpts | 16:54 |
| zyga | right | 16:54 |
| lazyPower | Hey, do we know if there is a weechat snap or a WIP of one? | 16:58 |
| lazyPower | i checked uappexplorer, not sure if there's a better place to look | 16:58 |
| lazyPower | before i tackled snapping up weechat i thought it would be best to ask the community at large | 16:58 |
| lool | 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 |
| didrocks | lazyPower: not that I know of. I would be interested by it, running weechat currently :) | 16:59 |
| lazyPower | didrocks patch-pilot me? :D | 16:59 |
| jdstrand | zyga: ok, approved. now can you reciprocate and review 181 and 182? | 16:59 |
| zyga | lool: I could detach all of hostfs | 16:59 |
| jdstrand | zyga: :) | 16:59 |
| zyga | jdstrand: yes! | 17:00 |
| zyga | jdstrand: taking my laptop on the go and going to review those two | 17:00 |
| didrocks | lazyPower: heh, with pleasure! (but not today, EOW now ;)) | 17:00 |
| didrocks | lazyPower: I don't think it would be complex | 17:00 |
| lazyPower | ack, i'll circle back on Monday with my WIP didrocks | 17:00 |
| didrocks | (famous last words…) | 17:00 |
| didrocks | yeah ;) | 17:00 |
| lazyPower | i tried this before and ran into issues with the addons | 17:00 |
| lazyPower | it was the perl/tcl backend stuff iirc | 17:00 |
| jdstrand | zyga: sure, please don't have it interrupt your evening or weekend | 17:00 |
| didrocks | right, that's my fear | 17:00 |
| lazyPower | but i nuked that disk and didnt have it pushed anywhere, like a swell developer making swell decisions :| | 17:00 |
| didrocks | lazyPower: classical :) | 17:01 |
| didrocks | lazyPower: good luck then and talk to you on Monday! :) | 17:01 |
| zyga | jdstrand: no worries, I'm not working today but since I love my job I'm doing it anyway :) | 17:04 |
| jdstrand | zyga: ok, well, only if you love my PRs can you work on them :) | 17:15 |
| jdstrand | zyga: seriously though, thank you :) | 17:15 |
| zyga | jdstrand: my pleasure :) | 17:16 |
| snap_question | 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 |
| jdstrand | 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 |
| zyga | snap_question: no, you have to mention each one separately | 17:38 |
| snap_question | so I tried to do that but I ran into an issue where I would have to do packagename.executable1 , packagename.executable2 | 17:39 |
| snap_question | and so on to get each executable to run | 17:39 |
| jdstrand | 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 |
| jdstrand | snap_question: work is actively underway to make it possible to remove that restriction | 17:42 |
| roadmr | jdstrand: sure thing | 17:42 |
| jdstrand | there may be a bug on it | 17:42 |
| jdstrand | snap_question: https://bugs.launchpad.net/snappy/+bug/1607748 | 17:44 |
| mup | Bug #1607748: Ability to use two registered names for the same snap <lxd> <Snappy:Confirmed> <https://launchpad.net/bugs/1607748> | 17:44 |
| jdstrand | snap_question: in the short term, you might use an alias as a workaround until this is implemented. eg alias bar=foo.bar | 17:45 |
| snap_question | Was knocked offline but just asked the question regarding publishing all the apps using the apps: flag in yaml | 17:47 |
| snap_question | Was there an updated message about running the executable without listing the snappackage.executable1, snappackage.executable2, etc... | 17:48 |
| zyga | 18:42 < jdstrand> 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, | 17:49 |
| zyga | you may refer to it as 'snapname' rather than 'snapname.command' | 17:49 |
| zyga | 18:42 < jdstrand> snap_question: work is actively underway to make it possible to remove that restriction | 17:49 |
| zyga | 18:42 < roadmr> jdstrand: sure thing | 17:49 |
| zyga | snap_question: ^^ | 17:49 |
| zyga | 18:42 < jdstrand> there may be a bug on it | 17:49 |
| zyga | 18:44 < jdstrand> snap_question: https://bugs.launchpad.net/snappy/+bug/1607748 | 17:49 |
| mup | Bug #1607748: Ability to use two registered names for the same snap <lxd> <Snappy:Confirmed> <https://launchpad.net/bugs/1607748> | 17:49 |
| jdstrand | roadmr: thanks! | 17:52 |
| snap_question | <zyga> thanks for restating the responses | 17:53 |
| snap_question | <jdstrand> looks like the LXD issue is exactly what I'm seeing. | 17:53 |
| snap_question | Some of the tool suites I am looking to put into snap have like 7-10 or more executables in them, hopefully a compromise is found | 17:54 |
| zyga | dillema: should I spread test locally in qemu and get less battery life or send them to linode and use more data? | 17:56 |
| jdstrand | snap_question: well, as mentioned, people are working on that so it works better for people | 17:57 |
| zyga | snap_question: it's just a matter of non-conflicting namespaces, many projects have a myriad of tools that could be better aggregated (this is a simplification but it's not uncommon). snapd supports one top-level command per project now because it was easier (snap name registration doubles as top level command registration) but we're working on unconstrained support for additional top level cmmands | 17:58 |
| zyga | commands* | 17:58 |
| zyga | jdstrand: offtopic, I'm working on a new tool that allows to inspect squashfs files at a raw level, analyzing each byte on disk and mapping it to some data structure | 17:59 |
| zyga | jdstrand: it's in very early stages of development now but if you'd like to see a specific feature please let me know | 17:59 |
| snap_question | zyga: understood, is the best place to keep an eye on this on the bug#1607748 page or is there a different status page to watch | 17:59 |
| zyga | jdstrand: the goal is visual inspection, forensics and looking for hidden data or maliciously crafted files | 17:59 |
| zyga | jdstrand: it's a pure python codebase for now | 18:00 |
| jdstrand | zyga: this is something that tyhicks and I might want to see inre store reviews | 18:00 |
| zyga | snap_question: I think that one is the best, also look for announcements of new snapd releases | 18:00 |
| zyga | snap_question: my magic ball says 2.20 | 18:00 |
| zyga | jdstrand: the code associates each data structures with particular intervals in the analyzed object and can do simple reporting and human readable dumps | 18:01 |
| zyga | jdstrand: plus, fun way to learn squashfs :) | 18:01 |
| jdstrand | I bet! | 18:04 |
| jdstrand | it might mean we can skip the resquash test or it might show what is wrong with the resquash test | 18:04 |
| zyga | jdstrand: quick question https://github.com/snapcore/snap-confine/pull/181/files#diff-e6f0d601e8a1dea1cff5b48e16c13661R512 -- why are you using strncmp for the rest but not for x86_64 and i686? | 18:11 |
| mup | PR snap-confine#181: add compatibility architectures for supported architectures (LP: #1592022) <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/181> | 18:11 |
| jdstrand | zyga: because uname will return longer strings and we want them to match. eg, armv7l | 18:13 |
| jdstrand | zyga: that should be 'arm' | 18:14 |
| jdstrand | this is the methodology lxc uses | 18:14 |
| zyga | jdstrand: I see | 18:15 |
| zyga | jdstrand: I added a few comments, look at https://github.com/snapcore/snap-confine/pull/181#discussion_r88708613 | 18:15 |
| mup | PR snap-confine#181: add compatibility architectures for supported architectures (LP: #1592022) <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/181> | 18:15 |
| zyga | jdstrand: other than that I'll merge it and iterate with tiny tweaks and some unit tests | 18:15 |
| jdstrand | zyga: thanks! | 18:25 |
| sergiusens | davidcalle so I merged, how often are the docs updated? | 18:28 |
| Kurdiez | I had to install Ubuntu Core on regular Ubuntu I had on PC to start using snappy. I am kind of having hard time understanding the Ubuntu Core. Does it also become a layer on top of the OS like JVM and you are forced to program with the SDK given by the Ubuntu Core? | 18:29 |
| Kurdiez | For example, opening socket connection or writing files to disk. | 18:30 |
| mup | PR snapcraft#919 closed: docs: update GUI related integrations <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/919> | 18:30 |
| tptr | hi, release question: the latest image here http://cdimage.ubuntu.com/ubuntu-snappy/16.04/ does not have the mmcblk driver. (so cannot be installed on an Intel stick pc for example). This is the place where the latest stable snappy release is published, right? | 18:36 |
| kyrofa | Kurdiez, no, not at all. The OS itself is structured a bit differently though, and applications need to abide by a certain set of rules. That's not to say that they need to use a specific SDK to write a file, they just need to write files in a specific location | 18:49 |
| Kurdiez | Well, I understand the whole contain snaps file activities within its own folder | 18:50 |
| Kurdiez | due to security reasons, I like that part | 18:50 |
| kyrofa | Kurdiez, right. Not folder, more like "area" (since it's multiple folders), but you get the idea | 18:50 |
| kyrofa | Kurdiez, but yeah, no special SDK needed, no specific language needed, etc | 18:51 |
| Kurdiez | but i'm just worried about any other run time restrictions I would get | 18:51 |
| Kurdiez | It seems like you are given a way to talk to snaps using some kind of sdk that is provided to you | 18:51 |
| kyrofa | Kurdiez, so snaps are confined in a number of different ways. One is filesystem access (there are a limited number of places snaps can write), the other is syscall access (there are a limited number of things a snap can do) | 18:51 |
| kyrofa | Kurdiez, by default, it's quite restrictive, i.e. you can't open sockets, etc. But if you declare in your snap that you need such a capability (i.e. by utilizing "plugs") you can expand your sandbox a bit | 18:52 |
| Kurdiez | what if I want process from one snap to manually signal the process in another snap? | 18:52 |
| kyrofa | Kurdiez, that's likely the `process-control` interface | 18:54 |
| Kurdiez | ok... is there document that tells me what is restricted? | 18:55 |
| Kurdiez | I read their website but couldn't find it | 18:55 |
| Kurdiez | it'd be nice to know up-front what i can't do | 18:55 |
| Kurdiez | before deciding to use it | 18:55 |
| Kurdiez | If I am to migrate current code into snap packages. | 18:55 |
| kyrofa | Kurdiez, this might be helpful: https://github.com/snapcore/snapd/wiki/Interfaces | 18:56 |
| kyrofa | Kurdiez, by default you can run apps and services and read/write files in specific areas. Beyond that, you need to use those interfaces to expand the capabilities | 18:57 |
| Kurdiez | oh snap... | 18:58 |
| Kurdiez | so anything not provided by these interfaces here | 18:58 |
| Kurdiez | I can't do | 18:58 |
| Kurdiez | that's the idea behind snappy platform? | 18:58 |
| kyrofa | Kurdiez, essentially. And new interfaces are being added all the time, so if you find something missing, please log a bug | 18:59 |
| Kurdiez | Thanks for the help kyrofa. You are the man. | 18:59 |
| kyrofa | Kurdiez, need to hit the network? Use network/network-bind. Want to play sound? Use pulseaudio. You get the idea :) | 19:00 |
| Kurdiez | so if I write C code, i still have to manage garbage collection myself | 19:00 |
| kyrofa | Kurdiez, and then, since interfaces are connections, a user can simply break the connection at any time (see your current connections via `snap interfaces`) | 19:00 |
| kyrofa | Kurdiez, yeah, snaps don't change the game there :) | 19:00 |
| Kurdiez | which I like. If I wanted garbage collection, I would probably install jvm snap and run java code I guess | 19:01 |
| kyrofa | Kurdiez, indeed | 19:01 |
| Kurdiez | thank you | 19:01 |
| kyrofa | Kurdiez, any time-- let us know if you have any questions as you explore! | 19:02 |
| jjohansen | zyga: not atm, there is an out of tree patch that could give that ability but nothing currently in yakkety/xenial kernels. It would be possible to drop it onto those kernels in an sru, but any such work would need to be scheduled with ty hicks and ratliff | 19:34 |
| Ardinis | Hello, is there any limitation for using snappy on ubuntu core? | 19:39 |
| jdstrand | mhall119: hey, I'm working on https://github.com/snapcore/snapd/pull/1613 and since apachelogger isn't here, I'm coming to you. do you know of two kde snaps that talk to each other over dbus in the manner that this PR is trying to address? | 20:19 |
| mup | PR snapd#1613: interfaces/builtin: add dbus-app interface <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/1613> | 20:19 |
| jdstrand | I've solved the binding to a well-known name case fine but would like to verify the connection policy | 20:20 |
| zyga | jjohansen: I don't think this is required, I was just curious, thank you for the explanation | 20:32 |
| _markfeatherston | How would I go about mounting a snap rw? I need to tweak a file in the core snap for a test and I'm assuming this is the simplest way to do it. | 21:42 |
| _markfeatherston | the obvious mount -o rw,loop doesn't seem to work | 21:42 |
| _markfeatherston | nm, found unsquashfs | 21:48 |
| mup | PR snapcraft#920 opened: Ensure staged files are included in the prime step <Created by josepht> <https://github.com/snapcore/snapcraft/pull/920> | 21:54 |
| kyrofa | _markfeatherston, yeah, you can't actually mount squashfs images as rw | 22:09 |
| kyrofa | _markfeatherston, you can use unsquashfs and re-squash a modified version, as you found, or you can use overlayfs for temporary tweaks | 22:09 |
| _markfeatherston | good to know there is another option, I'll remember overlays next time. Thanks | 22:10 |
| _markfeatherston | I found a bug in probert bringing up new hardware, trying to fix that | 22:10 |
| tedg | jdstrand: Did you see my ping the other day about disabling interface checking on devmode snaps? | 22:21 |
| tedg | jdstrand: WRT uploading to the store. | 22:21 |
| === devil is now known as Guest65744 | ||
| lzyPwr | Silly question that i cant seem to find in the docs or the playpen. I'm working on a weechat snap and i need to pass some args to the cmake builder. is there a way for me to pass these args to the cmake build process? | 23:10 |
| kyrofa | lzyPwr, indeed, run `snapcraft help cmake` | 23:10 |
| lzyPwr | ah, thanks for the pointer | 23:11 |
| kyrofa | lzyPwr, you'll see a description of the `configflags` option | 23:11 |
| kyrofa | lzyPwr, sure thing :) | 23:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!