[00:40] Bug #1638425 opened: The documentation to install snapd in archlinux doesn't mention that the socket needs to be started [03:44] PR snapd#2247 opened: interfaces/builtin/mir: allow client access to /dev/shm/ === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:33] PR snapcraft#883 closed: python plugin: wheel and install in the proper order [06:38] PR snapd#2248 opened: tests: make refresh-undo wait a bit for the output of the restarted v1 service [06:41] nessita: hi! I'm getting 404 on my " To accept this share, please visit:" link in e-mail I got thanks to upload by mvo for me [07:17] bonjello [07:22] im new ...i mean right now new, to ubuntu im lost [07:49] PR snapd#2208 closed: store: add support to resume partial downloads [08:10] hey hey [08:21] nessita: seems like case sensitive e-mail address detection [08:23] nessita: got now with lower case e-mail address. the next problem is that the new store with support for 'content' field is not there, any ETA on deployment? it was reportedly fixed in master already during the sprint. === ezobn is now known as Guest98417 [08:58] pitti: ping [09:56] PR snapd#2249 opened: store: use range requests if we have a local file already === chihchun is now known as chihchun_afk [10:05] ogra_: hi, I noticed there is a new rev 24 of the dragonboard gadget. do we need this for stable? it got little testing so far [10:05] ogra_: its only in edge === chihchun_afk is now known as chihchun [10:06] ogra_: same for pc-kernel, do we need the one in edge? [10:06] mvo, ogra_: do you guys have any insight on why networkd stores its DHCP lease inside /run where they are lost on next device boot? [10:07] morphis_: pitti will probably know [10:08] Bug #1638511 opened: Can't install snap in LXD container [10:09] PR snapcraft#872 closed: Add some further bash-completion [10:11] elopio: https://github.com/snapcore/snapcraft/pull/884 [10:11] PR snapcraft#884: Implement API packaging plugin as requested in #1638508 [10:12] PR snapcraft#884 opened: Implement API packaging plugin as requested in #1638508 [10:12] mvo: yeah [10:13] mvo, yes to both [10:14] mvo, pc-kernel adds the mmc modules to the initrd (needed by NUC) [10:14] ogra_: ok [10:15] mvo, dragonbvoard just adds a tty0 console arg so all arm images are consistent [10:16] can anyone guide me how to change library path after prime stage in snapcraft snap process. Thanks in advance === chihchun is now known as chihchun_afk [10:22] what is the current ubuntu core release? === chihchun_afk is now known as chihchun [10:26] zyga, systemd mounts support setting an SELinux context [10:27] Son_Goku: how can we do this? [10:27] Son_Goku: what should be in the unit [10:27] Son_Goku: I'll make that happen [10:27] Son_Goku: (good morning) [10:27] Son_Goku: (long night) [10:27] under the [Mount] section [10:29] add 'Options=context="system_u:object_r:snappy_var_lib_t:s0"' [10:29] Son_Goku: trying [10:29] it's essentially a mount option [10:29] with the mount command, this is done as the following command [10:29] mount -o context="system_u:object_r:snappy_var_lib_t:s0" [10:30] that overrides/enforces a default label === ezobn is now known as Guest89709 [10:34] Son_Goku: just fiddling, should have a patch in a sec [10:35] It'd probably be better if systemd had a specific SELinuxContext for mounts, but it doesn't :/ [10:36] something for your systemd guys to add, maybe [10:39] Son_Goku: ok, I just pushed something to f24 [10:39] Son_Goku: tell me if that what's you expected [10:39] Son_Goku: didn't build it yet [10:39] Son_Goku: can you update f24 to have the right commit ID for the polcy? [10:40] Son_Goku: I just want to be in sync with you [10:40] yes, give me a sec [10:41] PR snapd#2250 opened: Range requests but no snap logging [10:44] zyga, also, what creates the ~/snap directory? [10:46] Son_Goku: snap [10:46] Son_Goku: cmd/snap [10:46] Son_Goku: the snap run command specifically [10:46] Son_Goku: snap confine tries as well but by now snap run already did it [10:48] policy commit updated [10:50] Son_Goku: I fixed the patch [10:50] ogra_: Still no wifi in the raspi 3 image [10:51] rvr, i just had it working for the first time ... but i went afk for like 10min before pressing enter and i had a cable plugged in to eth when i booted [10:51] PR snapd#2251 opened: interface hooks: snapctl get-attr and set-attr (phase 3) [10:51] (disabling eth0 and configuring wlan0 worked fine then) ... [10:51] might be that the system is under high load on boot [10:54] t [10:56] Son_Goku: trying, fingers crossed :) [10:57] :) [10:58] Son_Goku: lis 02 12:57:47 fedora24 audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { reload } for auid=n/a uid=0 gid=0 cmdline="systemctl daemon-reload" scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=system [10:58] Son_Goku: we just need this I think [10:59] Bug #1638524 opened: /etc/modprobe.d adds one to much directory level [11:01] can you do the ausearch thing to give me the .te file lines? [11:01] Son_Goku: the thingh is, I don't get the denial this time [11:02] that's because it was a soft-fail [11:02] Son_Goku: it's not like I get the usual selinux thing there [11:02] ah [11:02] or perhaps, do you not have setroubleshoot-server installed [11:02] sealarm -b shows nothing [11:02] one of the two [11:02] I do have it [11:02] it's just not triggering [11:03] it must be something that's specified by the policy as, not undefined by the policy (just a hunch) [11:03] (as denial) [11:03] do you have any ideas where that might be? [11:05] * Son_Goku shrugs [11:05] we're really in the weeds now [11:06] Son_Goku: I think the weeds (for hello-world) are shallow, [11:06] I'm trying to grok what might be going on now [11:08] Son_Goku: could that be a dbus request for systmed to reload? [11:08] maybe? [11:08] selinux covers that too... [11:08] jdstrand: does this ring any bells vvvv [11:08] contexts apply to literally everything [11:08] lis 02 12:57:47 fedora24 audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { reload } for auid=n/a uid=0 gid=0 cmdline="systemctl daemon-reload" scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=system [11:09] Son_Goku: we should ask on selinux channel (maybe you already did) [11:09] I don't know why you're not there :P [11:09] and no, I haven't yet [11:09] I'm still trying to work out why the homedir transition isn't occurring automatically [11:18] zyga, you *really* should be in #selinux [11:18] I'm getting asked questions I don't know the answers to [11:20] Bug #1638529 opened: Auto-connect is not working for connection between network-manager and modem-manager [11:28] hi there guyts [11:29] i'm just trying to snap a java application [11:29] i have the -jar file and i want to create a snap package but i am unable to properly install java along with the package === ezobn is now known as Guest58526 [11:31] my snapcraft.yaml looks like this: [11:32] http://hastebin.com/bofiwuviyu.sql [11:33] the app is just a window poping up a hello world message [11:35] samplejava: hey! I would try using the jdk plugin from snapcraft. This one will do the correct things to stage a local jvm that could be used by your jars [11:36] hmmm [11:36] so adding it as a part? [11:36] (also, I think you did notice that you had a typo in default-jdk stage-package) [11:36] samplejava: one part with plugin: jdk instead of copy [11:36] and use stage/snap keyword to copy the files you need [11:37] if you are using maven build system, you can also look at using this plugin [11:38] jdstrand: bug 1598309 (your comment #4) is affecting me. I have a snap which barfs accessing /dev/snd/seq. Is there anything I can do other than use --devmode? [11:38] Bug #1598309: The aplay command doesn't work [11:38] in fact it is only an old .jar file which used to work but my users always complain about needing to install jdk on fedora, ubuntu, and so on [11:38] if i can manage this for them... [11:39] noticed the typo, but the error remains... [11:39] Something like this: /snap/jsignpdf/x8/command-jsignpdf.wrapper: 7: exec: java: not found [11:39] samplejava: yeah, that's because you didn't export JAVA_HOME and such [11:39] which is what this plugin is doing [11:40] if you look at the jdk plugin, it's just creating a small wrapper with simple env variables [11:40] pointing up JAVA_HOME and PATH to your local jre/jdk install [11:40] you can do this as well [11:41] samplejava: this is what the plugin is doing: http://paste.ubuntu.com/23415767/ [11:41] oh [11:41] the root variable is $SNAP in your snap environment [11:42] i will have to review the docs [11:43] because i bet that i am not understanding [11:43] your java is local to your snap [11:43] so you need to override some variables to point to it [11:43] that's what the plugin is doing for you [11:43] (here, the jdk plugin) [11:43] okey, so you mean modifying my plugin from plugin: copy to plugin:jdk would do the trick [11:43] or ill need to add a new part [11:44] correct, just modigyin your plugin to plugin:jdk [11:44] then, you need to use "stage" and "snap" keywords to ship your files [11:44] stage and snap [11:44] okey ill try [11:44] yeah, that's the part you should look into the doc :) [11:45] http://snapcraft.io/docs/build-snaps/syntax could be a good start [11:45] got it [11:45] http://snapcraft.io/docs/build-snaps/parts [11:45] ;) [11:45] also ;) [11:45] you were faster [11:45] heh [11:46] good luck, do not hesitate if you have any blocker! [11:46] hope not [11:46] i love the philosophy [11:46] thinking about deploying elasticsearch and so on similarly [11:46] looks great really [11:50] zyga, I've bumped the policy again, this time hopefully fixing the homedir issue [11:50] I'm going to take a little break on this [11:51] if you find issues, file them on the GitLab project [11:55] zyga: https://gitlab.com/Conan_Kudo/snapcore-selinux/issues [11:55] re [11:55] Son_Goku: thank you [11:58] zyga, also, if you need help deciphering SELinux issues, #selinux is a good place to be === hikiko is now known as hikiko|ln [11:59] popey: as of today, you need to use devmode. I've added a card to implement it, but it is prioritized behind other cards. you (or someone else) could create a PR for 'alsa' if you don't want to wait [12:02] im sorry didrocks [12:02] don't see the difference between stage and snap [12:03] i have defined a fileset called binaries which includes all the -jar files in my folder (- blabla/*) [12:03] samplejava: stage is for the stage step (what's ending up in the stage/ directory), snap is for the prime/snap stages (in the prime/ directory). See http://snapcraft.io/docs/reference/snapcraft [12:03] samplejava: if you don't know what to put, it's probably because you need both (refering to the same fileset) [12:05] * didrocks goes for a run, will be back later [12:05] zyga: I don't, no. tyhicks may have an idea, but I suspect Son_Goku is right about #selinux [12:06] zyga & jdstrand: also this can be helpful: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/ [12:06] just for understanding the concepts and stuff [12:06] tyhicks: do you think we can get someone with selinux brains to help us bootstrap snapd confinement (not interfaces)? [12:07] tyhicks: to the point where snapd itself is confined and runs correctly on f24+ [12:09] zyga: I was thinking about something related, snap support in subgraph os which uses a system sandbox called oz [12:12] femme: if you are interested in expanding and improving security subsystems in snappy then we have space where you can do that [12:12] femme: the code is very modular already [12:14] femme: and it's designed for runtime choice and can easily support many things [12:15] jdstrand: ok, thanks. [12:21] Bug #1638537 opened: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0c === chihchun is now known as chihchun_afk [12:39] jdstrand: Hey. I'm making the changes suggested in https://github.com/snapcore/snapd/pull/2225 but I gather I'm not fully clear, as now I'm seeing 'snap "ubuntu-core" has no slot named "lxd"' after I changed the declaration and removed it from builtins [12:39] PR snapd#2225: Implement lxd-client interface exposing the lxd snap [12:41] Updating the tests atm which may or may not yield some hints === hikiko|ln is now known as hikiko [13:06] Bug #1638558 opened: interface to register and talk to well defined name on dbus session bus [13:12] Bug #1638524 changed: /etc/modprobe.d adds one to much directory level

[14:14] elopio: are you sprinting too? [14:21] zyga: hey - who did you have in mind for that? === daniel is now known as Guest19937 === Guest19937 is now known as Odd_Bloke [14:39] PR snapd#2252 opened: interfaces: add unconfined access to modem-manager [14:40] any idea what's wrong in here? http://paste.ubuntu.com/23416363/ [14:49] Chipaca: hey, do you know who I should talk to about testsuite failures when running run-checks locally? http://paste.ubuntu.com/23416405/ [14:49] * Chipaca looks [14:49] Chipaca: these failures have been around for a while now [14:50] jdstrand: I don't see those; how're you running things? [14:50] jdstrand: you can talk to me for example :-D [14:51] Chipaca: I just do ./run-checks [14:51] jdstrand: in what environment? [14:51] Chipaca: now, my environment is that I have the lxd snap installed, then created a container for snapd developement [14:51] jdstrand: on what branch? [14:51] ah [14:52] it is every branch, but I'm trying master now [14:52] jdstrand: so the next question is what version of snapd and core and lxd you're on :-D [14:52] yes, same thing on master [14:53] snapd 2.16ubuntu3. ubuntu-core 423, core 6, lxd 241 (2.5) [14:54] snap-confine 1.0.43-0ubuntu1~16.04.1 (if you need that) [15:10] Chipaca: fyi, same error if using a system container or setting TMPDIR=~/tmp [15:10] jdstrand: ubuntu-core *and* core? [15:10] well, yes [15:10] jdstrand: you've been having fun! [15:10] I installed core cause I was excited to use it, then I couldn't remove either [15:11] jdstrand: you should be able to remove the one you're not using [15:11] jdstrand: but that might depend on which one you're using [15:12] Chipaca: I'd love to get rid of ubuntu-core. how will I know that it isn't being used? [15:12] jdstrand: you could try "snap disable ubuntu-core; snap remove ubuntu-core" [15:13] ah [15:13] disable first [15:13] that did it [15:13] jdstrand: that's exploiting a bug to fix a different bug, but yes :-D [15:13] nice! :) [15:14] jdstrand: what does snap --version say? [15:15] $ snap --version [15:15] snap 2.16ubuntu3 [15:15] snapd 2.16ubuntu3 [15:15] series 16 [15:15] ubuntu 16.04 [15:16] ok, with just core installed and disabling then re-enabling lxd to restart everything, same issue [15:16] Chipaca: shall I install snapd 2.17 from the ppa? [15:17] jdstrand: that would be helpful, but only if you don't mind then being stuck on it [15:17] it's fine [15:18] Chipaca: I have to step away for a little bit. I'll try snapd 2.17 and circle back === didrocks1 is now known as didrocks [15:25] Hey jdstrand. After making the changes you suggested in https://github.com/snapcore/snapd/pull/2225 I'm seeing 'snap "ubuntu-core" has no slot named "lxd"' when doing 'snap connect', I'm guessing removing it from builtins I might have to add it somewhere else? [15:25] PR snapd#2225: Implement lxd-client interface exposing the lxd snap [15:30] PR snapcraft#885 opened: Release changelog for 2.21 [15:45] hello, i have a snap that depends on different packages depending on architecture. Is there a way to specify architecture for packages, or optional packages? [15:45] or do i need a snap per different architecture? [16:16] does anybody know how to generate core files in ubuntu core? [16:20] tyhicks: hey [16:20] tyhicks: sorry for the lag [16:21] tyhicks: I was thinking if there's anyone we can tap into to help us finish selinux in fedora for snapd [16:21] tyhicks: not for interfaces, just for snapd itself [16:22] zyga: I don't know of anyone that has the skills and the spare cycles to work on that [16:22] tyhicks: do you know anyone with the skills that we can maybe try to get cycles? [16:23] zyga: on the ubuntu security team? [16:23] anyone? [16:23] not these days [16:24] I haven't been around the selinux policy community for at least 5 years [16:52] zyga: it might be possible to hire a consulting firm like Quark Security to help out with selinux policy [16:52] alternately, it might be possible to rope in some graduate students if some grant money were to be offered [16:53] Trent Jaeger did some analysis of the reference policy back in the day and is now a professor at Penn State - he might be able to come up with a grad student and define a mutually beneficial project [17:04] kalikiana_: sorry, I stepped away. right, so, if the interface isn't implicit and supplied by the core snap, then an app snap needs to supply the slot implementation for the interface [17:05] kalikiana_: since lxd is what provides the socket the interface grants access to, the lxd snap needs to provide the slot implementation [17:05] kalikiana_: in this specific case, the lxd service (command) that listens on the socket needs to simply 'slots: [ lxd ]' in its snap(craft).yaml [17:06] kalikiana_: then, you install lxd and you get the slot for your client to connect to [17:07] [17:07] bzoltan: no, I'm home [17:09] zyga (cc ratliff and tyhicks): one thing that come out of the sprint that I think you may not have heard that you should be aware of is that whenever interfaces are implemented for snapd, the selinux policy for dbus will be far more open. selinux doesn't have the concept of fine-grained dbus rules. all selinux has (essentially) is 'is this process allowed to talk to that one over dbus' [17:11] zyga: the same will be true of fine-grained gsettings mediation when that lands (aiui) [17:11] that's a good point but I think zyga is only wanting snapd confinement right now and he's not as worried about selinux policy for interfaces [17:11] tyhicks: sure, but this conversation reminded me that I needed to let zyga know that [17:11] ah [17:12] that's why I said "whenever interfaces are implemented" (since aiui, that isn't what they are trying to do now) [17:12] jdstrand: the same is true even for file access rules - the selinux policy for interfaces can only be as fine-grained as the labeling applied to the inodes [17:13] it isn't as easy to arbitrarily split up access to files in /home/tyhicks/, for example [17:15] tyhicks: yeah [17:15] I haven't looked at the labeling in fedora system in a while but it'd be interesting to see the output of `ls -alZ ~/` [17:17] it wouldn't surprise me if it was (predominately) the same label [17:17] like a session label [17:18] since that corresponds with the traditional desktop trust model [17:18] yeah, that's what I would guess, as well [17:19] Chipaca: fyi, I'm back and there is no difference [17:19] Chipaca: with 2.17 [17:19] jdstrand, time to file a bug! :-/ [17:21] let me try one more thing [17:22] jdstrand: Hmmm you wouldn't by any chance happen to know where to find lxd's snapcraft yaml? I installed it from the store [17:22] kalikiana_: I would think it would be in the upstream source. if not, ask stgraber [17:23] stgraber: Any idea where to find lxd's snapcraft.yaml? [17:23] It's not in the source tree as far as I can see [17:24] Chipaca: ok, so I tried it on another system without lxd involved and it worked. I'll file a bug with a reproducer [17:35] Bug #1638558 changed: interface to register and talk to well defined name on dbus session bus [17:44] PR snapd#2253 opened: interfaces/builtin/mir: allow slot to make recvfrom syscalls [17:50] stgraber: hey, I don't seem to have any logs from containers using the lxd snap. is there something special I need to do to enable logging? [17:50] stgraber: (I'm just looking at /var/log/syslog) [17:53] Bug #1638656 opened: snapd testsuite fails when run inside an lxd container [17:54] Chipaca: ok, bug #1638656. I think I was able to rule out a whole bunch of stuff-- the reproducer I gave is for lxd from the archive so snapd/snap-confine/core/lxd/etc interactions can all be ruled out [17:54] Bug #1638656: snapd testsuite fails when run inside an lxd container [17:54] Chipaca: it is simply run the testsuite in a container and it fails [17:59] can you use lxc inside snaps? [18:00] Chipaca: I also noticed a typo in HACKING.md: https://github.com/snapcore/snapd/pull/2254 [18:00] PR snapd#2254: fix path for source files location in HACKING.md [18:00] PR snapd#2254 opened: fix path for source files location in HACKING.md [18:01] femme: an lxc interface is in development that would allow snaps to access the lxd socket [18:01] I'm not sure if that is what you were asking [18:02] but there is also an lxd snap that can be used (I use it every day) [18:02] and with a new enough kernel, snapd, snap-confine and continer (eg, ubuntu 16.10), you will be able to run snaps inside a container from the lxd snap [18:03] people are working to get all that stuff into 16.04 [18:04] jdstrand: I'm trying to package a build system that uses lxc in snappy [18:05] femme: you would need the lxc interface then. that should land in trunk in the next week or so [18:05] in the mean time, use devmode to be able to access the lxd socket [18:08] jdstrand: so i need to use lxc *inside* the snap package, the package is going to build another package [18:10] femme: yes, I understand. with the lxc interface, that will allow you to specify 'plugs: [lxd]' in your snap. when connected your snap will be able to connect to the lxd socket so you can drive it with the lxc command [18:12] jdstrand: ah great, I'll wait :) [18:14] Bug #1638661 opened: Undo on failed refresh doesn't keep the previous snap intact [18:21] ogra_, do you know why it's possible to "snap login" repeatedly with the same account? [18:23] kalikiana_: git://github.com/lxc/lxd-pkg-ubuntu, snappy-16 branch [18:23] jdstrand: they'd be logged in /var/snap/lxd/common/lxd/logs/ or some similar path [18:26] vigo, nope [18:27] ogra_, I'll file a bug for it [18:27] yep [18:30] Bug #1638665 opened: User can login with "Snap login" repeatedly with the same account [18:50] I have an interresting issue that just came up.... [18:51] So I setup my device with Ubuntu-Core. I had to make some udev rule changes, and when I reboot, the system can no longer find the core.snap. Sure enough, I look in system-data/var/lib/snapd/snaps and only the kernel.snap is there and an empty directory named partial. [18:51] Any ideas? [18:53] Also, after initial login, when I type snap list, it shows no installed snaps. [18:57] re === JanC is now known as Guest59232 === JanC_ is now known as JanC [19:08] on ubuntu 16.04 it seems that /writable/ inside a snap isn't writable, is that normal? [19:12] Croepha: The only place you can write is given by env variables with DATA in the name. [19:13] Don't be fooled by the pathname. Some things can write there. Not snaps. [19:14] qengho: ok, good to know, I had hardcoded some stuff to use /writable, worked fine before, but breaks on newer snapd [19:14] thanks [19:15] hmm, looks like $SNAP_DATA is version specific... is there a scheme to accessing data from previous version? [19:16] Croepha: The data from previous version (if any) is copied into the place for this version. It exists already. [19:16] ahh, good deal, thats a smart behavior [19:17] i imagine there is also a garbage collection/clean-up scheme? probably when you remove older versions? [19:17] Croepha: A user can roll-back your version, and get data that existed at the instant of upgrade/refresh. [19:18] Croepha: Yes. That is intended, at least. Perhaps not finished being implemented. [19:19] Croepha: Also, there are places defined in "COMMON" env vars, which are not versioned and remain constant across snap versions, in case something is very large or should never be versioned or for other reasons. [19:20] ahh, nice [19:21] thanks qengho, you have been a big help [19:21] Croepha: Welcome! Make something awesome! [19:21] trying :) [19:29] PR snapcraft#885 closed: Release changelog for 2.21 [19:50] PR snapcraft#884 closed: Implement API packaging plugin as requested in #1638508