[00:09] This is the specific error they are seeing: http://pastebin.ubuntu.com/23789609/ [01:01] Hi, I'm trying to generate 'ubuntu-img' with my kernel-snap [01:01] sudo ubuntu-image -o cumulus-snappy.img --extra-snaps snappygenerickernel_4.4.0_amd64.snap pc-amd64-model.assertion [01:02] I get the following error [01:02] error: unknown flag `extra-snaps' [01:02] COMMAND FAILED: snap prepare-image --extra-snaps=snappygenerickernel_4.4.0_amd64.snap pc-amd64-model.assertion /tmp/tmpm30zktj9/unpack [01:02] any suggestion would be really helpful [02:58] zyga: http://people.canonical.com/~jj/lp1656121/ [05:30] PR snapcraft#1046 closed: godeps plugin: work when GOBIN is set [06:42] PR snapcraft#1047 opened: meta: support core libraries [07:00] jjohansen: thank you for the kernel, I'm trying it as we speak === mup_ is now known as mup === chihchun_afk is now known as chihchun [08:54] Issue snapd#2625 opened: feature request: ability to talk to sysctl [09:37] Hi guys! Just playing around with snappy core on my Raspberry Pi3. [09:37] zyga, mvo, hey, did you notice that snap-confine has a xenial SRU stucked since novembrer waiting on a bug verification? [09:46] I have an issue with plugs and slots in combination with the snap hugo (or even in general). Is there someone out there to help a bit? [09:54] Matthias___: I would describe your issue and then see if anyone is able to help [10:02] seb128: I wasn't aware of this but its probably superseeded by name, no? [10:02] seb128: the binary snap-confine is now build by snapd itself [10:10] mvo, oh ok, so maybe that SRU should be deleted? [10:11] seb128: yes [10:21] mvo, zyga, can one of you let the SRU know about that then? [10:36] ogra_, mvo: was there any movement recently on getting groups like lxd created on Ubuntu Core systems? [10:40] PR snapd#2626 opened: interfaces: relax path requirments for serial [10:51] PR snapcraft#1048 opened: bdocs: update deprecation links [10:52] morphis, i worked on it and then got distracted by the GLES stuff [10:53] (see the bug, i attached a first patch) [10:53] morphis, i'll move on with it next week if thats ok for you [11:07] ogra_: hm, currently don't find the bug anymore, you have a link handy? [11:36] I have an issue: I am using Ubuntu Core 16.04.1 on a Raspberry Pi3. [11:36] I am also using the hugo snap 0.18.1 on this system [11:37] With hugo installed I am not able to access my home directory where my web site should be generated. [11:38] Because the interfaces hugo is using are: Slot Plug :network-bind hugo,nextcloud,snapweb - hugo:home [11:39] Sofar so good. Now I thought that I just need to connect the slot home of my core system with the plug of hugo:home. [11:39] snap connect hugo:home core:home [11:40] The interfaces situation changed to: Slot Plug :home hugo [11:40] But still hugo can not do anything on my home location. [11:40] Any idea? [11:49] if I claimed a reserved name in the store, how can I check the status of my request? who reviews and makes decisions? [11:52] PR snapcraft#1047 closed: meta: support core libraries [11:52] PR snapcraft#1048 closed: bdocs: update deprecation links [11:56] morphis, bug 1647333 [11:56] Bug #1647333: adduser misses extrausers support for group management [11:56] ogra_: thanks [11:57] ogra_: and how would this be triggered from a snap? [11:57] it wouldnt [11:58] no idea how a user/grooup management interface would look like, i just make sure the low level works at all ... the rest is interface stuff in snapd [11:59] building such an interface today would simply not work, the extrausers setup has no concept of group mgmt at all today (only at user creadion a user group gets created, adding, removing and managing is not implemented) [12:00] (we simply never needed it on phones) [12:01] at least gpasswd and adduser itself still need additional patches for this to work [12:10] Ok guys, I found my mistake. The command to connect the home directory needs to be: [12:10] snap connect hugo:home :home [12:11] I thought I had to put "core" infront of home. Now it works. [12:11] Still a bit strange. [12:13] PR snapcraft#1049 opened: Release changelog for 2.25 [12:16] PR snapd#2627 opened: daemon: make activation optional === chihchun is now known as chihchun_afk === hikiko is now known as hikiko|ln [13:00] is it possible to use stage-packages but avoid installing all dependencies? [13:01] hard dependencies are always installed i dont think you can get around this [13:02] likewise recommends are always suppressed [13:19] Have a nice day, I am leaving for today. [13:24] ogra_: thanks [13:26] oSoMoN: hi! In your post about the snapification of webbrowser-app you mentioned that there's a known bug in snapcraft where ldd is used to fetch dependencies regardless of the libs provided by ubuntu-app-platform; do you have a bug number? [13:26] PR snapd#2628 opened: many: (mis)feature/no more snapd.socket === ben_r_ is now known as ben_r [13:43] mardy, https://bugs.launchpad.net/snapcraft/+bug/1587358 [13:43] Bug #1587358: Pack wrong libraries into snap [13:43] mardy, that’s not quite as I initially reported it, but my issue was folded into that bug report [13:44] mardy, however there’s a reliable workaround for the issue: add back stage packages for the libs that snapcraft chooses to add, and exclude their files [13:45] mardy, this way snapcraft will acknowledge that the libs are being included (even though you can still exclude them from the resulting snap), so it won’t force their addition [13:47] oSoMoN: to make sure I understood it right: I should explicitly list all the stage-packages dependencies in stage-packages, and then use exclude rules to remove their files? [13:48] mardy, yes, although you don’t need all the stage packages, only the one that contain the libs that otherwise would be pulled in by snapcraft [13:48] the ones* [13:49] mardy, typically you don’t need packages for qml modules, are those are loaded dynamically, not linked to your executables [13:49] oSoMoN: ah, got it! [13:49] thanks! [13:50] yw [13:56] popey, do you know who handles the requests to claim a reserved name in the snap store? [14:01] PR snapcraft#1049 closed: Release changelog for 2.25 === davmor2_ is now known as davmor2 [14:42] PR snapd#2629 opened: interfaces: allow reading installed files from previous revisions by default [15:07] ogra_: hey-- thanks for the upload of linux-generic-bbb to edge. I notice that r8 is in edge, r7 in beta and r6 in stable. do you recommend I follow edge? [15:07] jdstrand, ah, sorry, i havent pushed it to the other channels yet [15:08] ogra_: I promise I'm not trying to be a pest. it seems that the review tools allowed it (there was a fast turn around on the store pull yesterday) [15:08] it is definitely in ... [15:09] it is in. I just don't know if you poked someone or if it was automatic [15:09] * jdstrand checks the log [15:09] i triggered the build ... [15:09] thats all [15:09] OK (override 'linux-generic-bbb' for 'type: kernel') lint-snap-v2_snap_type_redflag [15:09] and it is at r824. cool [15:09] the rest seems to have been automatic .. [15:09] 'it' being the review tools [15:09] perfect. that was the goal :) [15:10] and i just pushed it to all channels [15:10] * jdstrand hugs ogra_ :) [15:10] well, thanks for the ping, i would have forgotten about it [15:11] :) [15:19] PR snapd#2549 opened: cmd/snap-confine: add shutdown helper [15:38] jdstrand: hey, shouldn't this be the case https://bugs.launchpad.net/snap-confine/+bug/1620442/comments/9 ? [15:38] Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 [15:40] Trevinho: this was reverted [15:40] Trevinho: the fix was partially incorrect, I'll get back to it after some other snap-confine work [15:41] zyga: mhmhmhmhmmh, soooooo.... I should expect that var not to be set again? [15:41] zyga: That's on xenial's snapd [15:41] and I'd like to use that path for some temporary data that the classic os should be able to read [15:45] it's not going to exist, it will be set but should be unusable for now [15:46] mvo: Have you seen anything similar to this errors before? http://paste.ubuntu.com/23792712/ [15:46] zyga: When creating it it currently works... [15:47] Trevinho: right, the part that was reverted was the mkdir-like code that created the directory on app startup [15:47] zyga: ah, ok.. and is that going to be readded, though... Right? [15:48] Trevinho: it should be. zyga removed the PR to snap-confine (before 2.20 release) that did that since he was changing some other bits and wanted to get those sorted first. AIUI, he was going to add it back at some point [15:48] ah, heh [15:48] jdstrand: yes, we'll add it back after snap-alter-ns I suspect [15:48] so... I'm opening a bug and assignging that to zyga then :-) [15:49] jdstrand: I'm doing small clean-ups and I wanted to resurrect the improved mkdir code and then use it it [15:49] yep, thank you [15:49] * jdstrand nods [15:49] Hi all [15:50] zyga: note that bug #1656289 is being discussed on the list. I assigned to you so you'd see the bug email, but feel free to adjust [15:50] Bug #1656289: [Regression] 2.20.1ubuntu1 breaks snaps that use ALSA [15:50] PR snapd#2627 closed: daemon: make activation optional [15:50] PR snapd#2629 closed: interfaces: allow reading installed files from previous revisions by default [15:51] I would like to ask a question regarding plugging into a specific interface. I've read few papers about ubuntu core/apparmor/seccomp [15:51] but I'm stuck with connection to specific interface [15:51] jdstrand: thanks, I'll check it out soon [15:51] which is: "kernel-module-control" [15:51] I was out most of the day, my laptop needed to be delivered to a service center and I took some time off to walk aroudn [15:51] zyga: this only just came up [15:52] do you know guys if it is super prohibited interface ? I'm unable to install app that plugs into this i-face [15:52] so, no worries [15:52] snappy_beginner: it is super-privileged [15:52] Ok. [15:52] sudoer could install such app then? [15:52] jdstrand: ALSA lib conf.c:3759:(snd_config_update_r) Cannot access file /usr/share/alsa/alsa.conf -- this looks like core snap change if nothing else [15:53] snappy_beginner: as such it needs something called a snap declaration in the store to allow installation via the store. however, newer snapd (I think 2.20) allows local installs to work when installing with --dangerous [15:53] * zyga looks at email [15:53] zyga: the core snap should never have had that file [15:53] zyga: I can't assign it to you it seems, but... here it is https://bugs.launchpad.net/snapd/+bug/1656340 [15:53] Bug #1656340: XDG_RUNTIME_DIR is not created on app startup [15:53] zyga: but perhaps it did... [15:53] jdstrand: yes, I'm trying to install it locally with devmode and dangerouse switches [15:53] :) [15:53] snappy_beginner: what version of snapd do you have installed? [15:54] zyga, there has never been any alsa in the core snap [15:54] (and there likely wont be) [15:54] 2.16 [15:54] (jdstrand: 2.16 [15:54] snappy_beginner: upgrade to 2.20 and it will be installable with --dangerous [15:55] Oh yeah [15:55] thanks jdstrand [15:55] btw: I would have another question then. [15:55] suppose I'm device owner and it has already kernel module up and running - I can connect to it and it is operable. [15:56] Is it a great effort to create the interface from a scratch? [15:56] I mean, it would be similar to 'tpm' which is already ready to use [15:57] snappy_beginner: no. look at the recent openvswitch-support interface [15:57] snappy_beginner: all it does is ask snapd to load the openvswitch module [15:57] ok [15:58] snappy_beginner: I might point out a coupel of things. many modules autoload when you try to access the kernel functionality, so you don't need an interface like this. a few do, like openvswitch and ip6table_filter and iptable_filter, so there are interfaces for those [15:59] ok ok [15:59] jdstrand: last question [16:00] snappy_beginner: 2nd, depending on what your project is, you might be able to have your own kernel snap. I think (perhaps this is a future thing), the gadget snap will allow you to have certain modules loaded (ogra_, do you know otoh?) [16:00] this module is already there [16:00] on the snappy ubuntu [16:00] well, you could ship an /etc/modules-load.d file in the gadget [16:01] thats why I want from my app to plug into kernel-module-control i-face [16:01] ah, there you go [16:01] and if I;m understanding this correctly, my app will get access over apparmor and seccomp to specific device which requires privileged access? [16:02] through an interface, yes [16:02] great [16:02] it is awesome. [16:02] really [16:03] snappy_beginner: kernel-module-control gives device ownership to the snap since it can modify how the kernel behaves, including disabling all security policy. its use is strongly discouraged which is why the other methods exist. having an interface that asks snapd to load it is safe. having the gadget ensure it is loaded is safe. letting a snap load any modules into the kernel places ultimate trust in that snap [16:03] it sounds logic [16:04] some things obviously need kernel-module-control. eg, a livepatch snap [16:05] jdstrand: so anyway. the ultimate conclusion is: I should provide new interface over a gadget that can send i/o to this specific kernel module right? [16:05] so snapd regulates kernel-module-control. unsigned installs (ie, using --dangerous) you're free to do what you want of course [16:06] snappy_beginner: the gadget doesn't need an interface. the gadget is there to configure things for the system/device. ogra_ mentioned it is allowed to drop a file in /etc/modules-load.d. put the name of your module in there and create an image using your gadget and install on the device and your set [16:06] ah ok [16:07] understand [16:07] snappy_beginner: an interface is only needed if you want an 'app snap' to ask snapd to load the module for you [16:07] well, you can define interfaces in the gadget.yaml file too [16:07] snappy_beginner: and how snapd does that is dropping a file into /etc/modules-load.d [16:07] ogra_: fair point [16:07] Ok [16:08] if an interface is defined, the gadget could use it. if it isn't, it can put a file in /etc/modules-load.d [16:08] snappy_beginner: mind saying which module it is? [16:08] you can even do both ;) [16:08] it is /dev/mei :) [16:08] force the module to be permanently loaded ... use an interface for device access management [16:09] and this one requires the accessing process to be privileged [16:09] snappy_beginner: that sounds like it would be good for an interface actually. you create a PR that loads the kernel module, and then add accesses to allow using it in the security policy [16:10] snappy_beginner: see openvswitch-support for the former and io-ports-control for the latter [16:10] So I'm thinking on how it should be implemented in the new security fashion of ubuntu core [16:10] the module is already loaded === hikiko|ln is now known as hikiko [16:11] if you are implementing this, reference https://www.kernel.org/doc/Documentation/misc-devices/mei/mei.txt. we can iterate on the contents of the security policy in the pr [16:44] Issue # closed: snapd#2484, snapd#2514, snapd#2541, snapd#2552, snapd#2553, snapd#2568, snapd#2569, snapd#2572, snapd#2576, snapd#2594, snapd#2603, snapd#2625 [16:44] PR # closed: snapd#2226, snapd#2230, snapd#2236, snapd#2251, snapd#2256, snapd#2277, snapd#2302, snapd#2328, snapd#2347, snapd#2359, snapd#2360, snapd#2368, snapd#2392, snapd#2397, snapd#2407, snapd#2411, snapd#2416, snapd#2417, snapd#2421, snapd#2448, snapd#2449, snapd#2475, snapd#2477, [16:44] snapd#2482, snapd#2488, snapd#2513, snapd#2515, snapd#2524, snapd#2528, snapd#2529, snapd#2542, snapd#2545, snapd#2546, snapd#2549, snapd#2558, snapd#2570, snapd#2575, snapd#2579, snapd#2581, snapd#2583, snapd#2585, snapd#2586, snapd#2588, snapd#2591, snapd#2592, snapd#2595, snapd#2596, snapd#2600, [16:44] snapd#2604, snapd#2613, snapd#2622, snapd#2623, snapd#2624, snapd#2626, snapd#2628 [16:44] hm [16:45] Issue # opened: snapd#2484, snapd#2514, snapd#2541, snapd#2552, snapd#2553, snapd#2568, snapd#2569, snapd#2572, snapd#2576, snapd#2594, snapd#2603, snapd#2625 [16:45] PR # opened: snapd#2226, snapd#2230, snapd#2236, snapd#2251, snapd#2256, snapd#2277, snapd#2302, snapd#2328, snapd#2347, snapd#2359, snapd#2360, snapd#2368, snapd#2392, snapd#2397, snapd#2407, snapd#2411, snapd#2416, snapd#2417, snapd#2421, snapd#2448, snapd#2449, snapd#2475, snapd#2477, [16:45] snapd#2482, snapd#2488, snapd#2513, snapd#2515, snapd#2524, snapd#2528, snapd#2529, snapd#2542, snapd#2545, snapd#2546, snapd#2549, snapd#2558, snapd#2570, snapd#2575, snapd#2579, snapd#2581, snapd#2583, snapd#2585, snapd#2586, snapd#2588, snapd#2591, snapd#2592, snapd#2595, snapd#2596, snapd#2600, [16:45] snapd#2604, snapd#2613, snapd#2622, snapd#2623, snapd#2624, snapd#2626, snapd#2628 [17:29] hey folks once again [17:29] I do have last question. [17:30] Ask. [17:30] supousedly I will have my own interface in snapd [17:33] Like this? http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html [17:35] sorry, got disconnected [17:36] so the question was - how to deliver modified snapd to this system abeato when it is read only? [17:36] Like this? http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html [17:40] thanks :P [17:40] oh === JanC is now known as Guest43962 === JanC_ is now known as JanC [17:43] snappy_beginner: merge it upstream [17:43] snappy_beginner: that's the only way [17:44] snappy_beginner: we will happily take contributions [17:44] I should write a 2nd version of that blog post soon [17:45] sorry, zyga. [17:47] zyga: I will be more than happy to contribute ;) [18:05] qengho: about what? [18:05] * zyga was referring to the new interface APIs that are slowly happening next week [18:06] zyga: for referring someone to something you feel you must rewrite. [18:06] qengho: that blog post is accurate for now [18:07] qengho: I just realized that with the patches I've been working on this week it will get out of date [18:07] Ah. [18:07] qengho: I'll document it on the wiki so that it is easier to keep up-to-date [18:07] and I cannot wait to see the new APIs in place, it will be much easier to write an interface :) [18:39] PR snapd#2595 closed: daemon: re-enable reexec === ben_r_ is now known as ben_r [19:26] zyga: does the configure hook get run before or after the daemons are started? [19:28] mhall119: after [19:28] AFAIK [19:28] is there anything that runs before? I need to create a config file before the service starts [19:32] zyga: or is there a way to restart the daemon from within the hook? [19:33] mhall119: no [19:33] mhall119: no [19:33] sorry :/ [19:33] zyga: hey, so this is fun: http://paste.ubuntu.com/23793926/ [19:37] jdstrand: this one's for you, the snappy-debug scanlog advises me to use plugs I'm already using: http://paste.ubuntu.com/23793938/ [19:37] mhall119: is there any apparmor or seccomp denial? [19:37] mhall119: the hook is not using those [19:37] zyga: the apparmor denials in that second pastebin [19:37] mhall119: are they connected? [19:37] mhall119: snap interfaces [19:38] jdstrand: not sure, the install fails because of what I pasted to zyga [19:38] mhall119: I really doubt transmission would need 'network-control' [19:39] mhall119: I bet that the hook doesn't have those (see snapcraft.yaml) and thus cannot work [19:39] mhall119: mount-observe and network-control are not auto-connected [19:39] zyga: ah, snapcraft doesn't like the hooks: section, I'll try adding it to snap.yaml [19:39] mhall119: I don't know about that, sorry [19:39] mhall119: and there's also a bug in golang that causes all the hooks to require network-bind [19:40] mhall119: it's tracked but I don't recall the URL now [19:40] mhall119: and because snapctl is implemented in golang all the hooks are affected [19:42] ogra_: it's still correct that pulse audio doesnt' work right? [19:42] re kodi, it'd only be good for silent movies atm :) [19:44] Hmm. I thought I had PA working in a game I snapped a while ago, in dosbox... [19:54] PR snapd#2630 opened: many: detect potentially insecure use of snap-confine [20:01] * zyga EODs [20:41] PR snapd#2631 opened: releasing package snapd version 2.21 [20:57] zyga: jdstrand: anything I can do about this: [20:57] = Seccomp = [20:57] Time: Jan 13 15:56:45 [20:57] Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=25360 comm="transmission-da" exe="/snap/ubuntu-desktop-seed/x3/usr/bin/transmission-daemon" sig=31 arch=c000003e 179(quotactl) compat=0 ip=0x7f301989b0ca code=0x0 [20:57] Syscall: quotactl [20:57] there is a bug on that. for transmission in particular [20:57] * jdstrand finds it [20:59] mhall119: https://bugs.launchpad.net/snappy/+bug/1626359. See comment #1. I'm actually working on seccomp arg filtering policy as we speak and this is one of the things I'm going to fix [20:59] Bug #1626359: Cannot authorise quotactl syscall for Q_GETQUOTA [20:59] mhall119: to work around it, add quotactl to /var/lib/snapd/seccomp/profiles/snap.your.thing [20:59] mhall119: if yoy install/remove/refresh you will have to add it back [21:28] thanks jdstrand, that fixes my last issue [22:02] hi [22:02] I am looking for help: how can I provide multiple executibles in a snap? [22:03] executables* [22:04] skri: the apps: section of your snapcraft.yaml can have multiple entries, one for each executab;e [22:05] skri: see "Apps and commands" section here: http://snapcraft.io/docs/build-snaps/syntax [22:05] http://snapcraft.io/docs/build-snaps/metadata has some examples of doing this [22:05] mhal119: thank you, but I am missing something because I get an error: Issues while validating snapcraft.yaml: The 'apps' property does not match the required schema: Additional properties are not allowed [22:06] skri: sounds like a simple syntax error somewhere, can you put your snapcraft.yaml on paste.ubuntu.com? [22:10] mhall119: I uploaded it to pastebin http://pastebin.com/8mRk0A1W [22:11] skri: hmmm, you may not be able to have periods in your app name [22:12] oooh [22:12] that is not so good news :-( [22:12] also, python and pip aren't going to do much for you in strict confinement, are you aware of the new "classic" interface? [22:12] thanks for your help, mhall119! [22:12] no, I am not [22:13] I am still learning snappy [22:13] ok, so "classic" was introduced to support things that don't make sense to run in strict confinement [22:13] I wanted to have an easily deployable python build [22:13] I'm not sure the new documentation for "classic" has even been published yet... [22:14] I was imagining that I could tell pip to use the workspace provided by snappy somehow [22:14] snaps are usually aimed at "leaf" applications, which can be confineed and self-contained [22:14] but in confinement they can't read or write to the rest of the filesystem, which python and pip would certainly need to do [22:15] classic confinement will let them do that [22:15] I *think* all you have to do is switch your line 4 to confinement: classic [22:15] but zyga (already off for the day) can give more info tomorrow if you're around earlier [22:16] ah, we did published the new docs: http://snapcraft.io/docs/reference/confinement [22:17] sounds like a simple change, thanks :-) [22:18] I wanted to move in small steps and get some i/o error from python or something [22:21] it seems from the confinement docs that even in strict confinement the global path /var/snap//common and the user-specific path /home/$USER/snap//common are both writable in strict confinement [22:25] skri, indeed, SNAP_DATA and SNAP_USER_DATA are always writable, even in strict comfinement [22:26] As are SNAP_COMMON and SNAP_USER_COMMON [23:39] so, I managed to finally create a simple python snap [23:40] lessons learnt: 1. no points in identifiers 2. plugins != plugin [23:40] the second one took a while [23:41] I can start the python interpreter in strict confinement [23:41] maybe this'll be enough [23:42] thanks for the help from mhall119 and kyrofa