[00:34] i have flashed ubuntu core to my SD card for QualComm 410c. I inserted the coard into my system. Can anyone tell me how to let it boot from the SD card instead of the built in android system? thanks [00:48] What are some disadvantages to using snaps? would there be duplication of dependencies? Say, package X uses Y dependency. package Z uses Y dependency. Both snaps include Y dependency. [00:54] SamYaple_: python3, and then in ubuntu 16.04 i call python3-pip, and python3-dev [01:28] for qualcomm snapdragon board, without network access, it cannot complete the installation. on the board, it does not have the Ethernet, how can I set up the WLAN network? thanks [05:10] Hi all. Is there a way to install and use Snappy Ubuntu 16.04 without having an account on ubuntu.com? [06:28] mvo, ping === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:47] PR snapd#1888 opened: interfaces: allow special casing for auto-connect until we have assertions [06:51] liuxg: pong [06:52] mvo, I just got a snapdragon 410c board. I have flashed the latetst software at http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/. however, I cannot get the netowork up so that I cannot complete the network config. Do you know how to do it? thanks [06:53] PR snapd#1884 closed: tests: get the gadget name from snap list [06:54] mvo, the board only has a WLAN, but it does not have a ethernet interface for use. May I modify some part of the software to get my WLAM working so that I can connect to the device? [06:55] hery hey [06:56] mvo, ogra_, we are going to have a talk at Qualcom event. I am now trying to build some demos for the board :) [06:59] liuxg: its a known issue, sorry that I did not write a followup on that to the list. the console-conf software does not yet support wlan, however mwhudson is working on this AFAIK. in the meantime the workaround is a usb network adapter [07:00] liuxg: would the usb (lan) network adaper unblock you? we might also get mwhudson to release a early version of the new wlan code. when do you need this? i.e. when is the event? [07:01] PR snapd#1876 closed: cmd/snap: make "snap find" error nicer [07:02] mvo, ok. in that case, we probably need to have a ethernet network adapter for it. good to know the workaround. thanks. I am not sure whether it is good to disable console-conf for development software. to developers, it may be a problem. [07:09] PR snapd#1889 opened: tests: add yakkety test host [07:22] mvo, hey! Could you help me with Ubuntu Snappy 16.04? Trying to figure out if it is required now to have Ubuntu One account to use Snappy [07:26] tzununbekov: this is the case right now, we are working on local users that are created differently, but the current image needs a u1 account that is used to setup your local user. the upside is that this is super convinient, i.e. your ssh keys are on the device, your prefered username and we plan to sync the ssh keys in the future so that key update will be totally transparent [07:28] mvo, I see, thanks === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:57] pitti: ping [07:57] morphis: contentless pong :) [07:57] good morning [07:57] tvoss, pitti: morning :-) [07:57] pitti: have a question about systemd and how it sets up /sys/fs/cgroup [07:58] morphis: good morning! [07:58] pitti: we're running systemd on a 3.4 based kernel [07:58] its kind of unsupported by upstream, but works [07:59] it somehow fails to setup /sys/fs/cgroup on its own on startup so we have to workaround via https://paste.ubuntu.com/23168270/ [08:00] pitti: from what I read in the source it should actually do this on its owner so I am wondering if there might be some hidden thing I am missing in the picture [08:00] pitti: as further context info, this is systemd 229 as it comes in xenial [08:00] morphis: hm, I tried a reasonably modern systemd (~ 220 or so) on 3.4, back then this worked well enough [08:00] pitti: yeah 219 works like a charm [08:00] morphis: ah, is that your /sbin/init wrapper? [08:01] yes [08:01] it should also mount /proc and /sys etc. on its own [08:01] right [08:01] well, you need /sys if you manually mount /sys/fs/cgroup of course, but shouldn't need /proc and /dev [08:01] if I don't put this wrapper in place it fails with error message like "too many symlinks on /sys/fs/cgroup" [08:01] morphis: so, I can't say off the top of my head, do you have dmesg from a boot with init=/lib/systemd/systemd directly? [08:01] that should have some error message [08:02] yes [08:04] pitti: it fails very early: https://paste.ubuntu.com/23168277/ [08:04] that are the relevant lines [08:08] pitti: this somehow looks like its failing to mount a tmpfs on /sys/fs/cgroup [08:08] but it doesn't print out any error message for this [08:09] morphis: this might be related to 3.4 not supporting name_to_handle_at() or /proc//fdinfo yet? [08:09] hm, that could it be [08:10] https://github.com/systemd/systemd/blob/master/src/basic/mount-util.c [08:10] morphis: these are the helper functions that determine whether a path or a fd is a mount point [08:10] then both fallbacks doesn't seem to work here [08:10] it normally uses name_to_handle_at() as that's the most robust/fastest, then falls back to fdinfo, then falls back to stat9) [08:10] stat() [08:11] morphis: maybe wrap it in strace, to get an idea what it does? [08:11] yes, will check that [08:11] pitti: thanks! [08:12] morphis: src/core/mount-setup.c, mount_one() indeed uses path_is_mount_point(), and that matches the error message [08:12] yeah [08:13] hello all im using python3 with pip. the snap creates properly, but when executing the script it says it cant find pip via python in the snap [08:13] morphis: are there any actual symlinks involved in that environment? [08:13] can someone tell me how to inject pip into the snap its self for use? [08:14] pitti: no [09:18] mvo: hey, i guess now beta is done we should feed you a new console-conf release [09:18] mvo: it has wlan support now :) [09:21] mwhudson, copy it over ! [09:21] ogra_: need to upload it first! (am editing changelog now) [09:21] \o/ [09:24] woo got my gpg passphrase right first time [09:27] ogra_: 0.0.16~xenial in https://launchpad.net/~canonical-foundations/+archive/ubuntu/ubuntu-image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial [09:30] ah, the publisher ... [09:30] (might take a while) [09:30] PR snapd#1801 closed: snap: make snap download also download the assertions for the snap [09:36] mvo, i think you need to re-do (xz) the pi3 image, seeme the xz step is corrupt (nothing to notice on the running image, so i guess only the zeroed parts are affected, but it is ugly) [09:36] *seems [10:06] ogra_: it published now at last [10:07] do you have access to copy it to the image PPA ? [10:08] ogra_: no [10:11] done ... waiting for the next publisher now :) [10:11] https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial [10:11] i'll trigger an ubuntu-core build once it is done [10:15] zyga: did you get your collab-maint access sorted? [10:28] ogra_: as a snap app developer how can I know what system library I can expect to be on the core snap? Is there a minimal image I can see what packages the snap core is built from? [10:30] ogra_: sure, lets redo it [10:30] mwhudson: \o/ for wlan [10:34] bzoltan, since you shouldnt use anything except libc from the core snap thats a moot question .. beyond that there is bug 1608432 [10:34] Bug #1608432: snaps with type: os should allow publishing of .manifest files

[10:35] libc and /bin/sh are the only guaranteed bits in ubuntu-core [10:35] mvo, hey, you know a lot about systemd & deb packaging - any advice on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1622045 ? adding #DEBHELPER# didn't fix it. removing the symlinks in the postrm script "manually" caused the problem with these units after re-installing the deb [10:35] Bug #1622045: /etc/systemd/system/multi-user.target.wants/snapd.* symlinks not cleaned up when package is removed/purged

[10:35] mvo, i mean after reainstalling, the units are disabled [10:36] arent the units conffiles ? [10:36] you need to use the right tools for them if they are [10:37] ogra_, there are debian/*.service & debian/*socket files for them if that's your question? [10:37] pstolowski: the lack of #debhelper# looks like a bug in itself [10:38] ogra_, ah, no i don't see any conffiles declared [10:40] PR snapd#1861 closed: tests: fixes to actually run the spread tests inside autopkgtest [10:40] i think you want the deb-systemd-helper tool in your scripts [10:41] or dh_systemd_* [10:41] (afaik both should work) [10:41] err [10:42] **and* dh_systemd (in debian/rules) [10:44] new ubuntu-core building [10:47] ogra_: thanks, that is clear [11:04] mvo, two things ... steve said we can drop grub from the amd64 rootfs ... i'll do that today ... and i uploaded https://myapps.developer.ubuntu.com/dev/click-apps/5912/ onn the weekend, could you approve it ? [11:05] ogra_: grub-- ? cool, we still need grub-editenv for now, I can write it natively if we want to get rid of it fully [11:06] ogra_: and linux-generic-bb +++ ! [11:06] hah, thanks ... the mail was fast :) [11:06] (store mail) [11:07] mvo, yeah, i think it would be preferrable if we handle both bootloaders directly from snapd ... but i'll keep grub-common around for now === ant__ is now known as antdillon [11:09] mwhudson, ubuntu-core done in case you still want to test (i imagine its EOD for you) === bloodearnest_ is now known as bloodearnest [11:11] ogra_: yeah, SMOP [11:11] yep [11:13] pitti: do you know / have an idea when / why would 'systemd' take over a serial console on the device, so that device, after it boots , doesn't have console (uart gpio's) to log in? virtual consoles show up... any pointers to getty@tty*.service ? I was looking at http://0pointer.de/blog/projects/serial-console.html - but maybe I am missing something else ? [11:16] mwhudson: not yet, I'll get it sorted out soon [11:19] Hello everybody [11:20] I have a question about snappy as a user, hope i will get answer here. [11:21] I'm using ubuntu 16.04 and working as a freelancer on upwork.com and i need to track my working hours. About 6 months ago, their app for tracking working hours failed to work on Linux [11:22] The problem is - they need this "libnss3_3.19.2.1-0ubuntu0.14.04.2_amd64.deb" so their app can send info about working hours to their server [11:23] So the question is, can close-sourced programs be packed in snappy too? If yes, can somebody ask/help upwork with snappy for linux users this will be very usefull. thank you guys for your work. [11:25] indeed you can package closed source apps ... snap doesnt care whats inside [11:25] Cool, so can somebody with @canonical.com e-mail contact upwork team? [11:26] if snappy supports all linux distros they would love to switch i guess [11:26] do they use some bug tracking system ? you could file an issuue there and ask them to offer a snap ... we'll happily help here if they drop by or ask on the mailing list [11:26] But who i'm to tell them about snappy, they will ignore my mail.. [11:27] i will check this, if yes i will provide link here so ppl can upvote issue. [11:27] k [11:29] There is only community forum, users need to have account to write there. [11:34] If here are people from canonical, please contact upwork linux team >https://www.upwork.com/about/contact/ drop them a message from @canonical.com domain about snappy package for their app, and how this will help them fix their problems with their app for linux users partners@upwork.com [11:35] Pharma: closed source software can be packed in a snap, just as it can be packed in debs [11:36] zyga, thanks, hope somebody from canonical will notice my message and will do something. [11:38] PR snapd#1890 opened: tests: add spread test for snap create-key/snap sign [11:39] PR snapd#1891 opened: doscs: add create-user documentation [11:41] TinoGuest: this is usually controlled with the console= kernel cmdline argument; any consoles specified there will also get a getty and boot messages [11:42] pitti: is this happening "automatically"? getting getty. and enabling console ? [11:43] kernel cmd line is ok. i can boot non systemd rootfs, and keep using console on the device [11:43] pitti, seemingly systemd always creates tty1 regardless if we have console= pointing to serial (which is the default on the arm images ... x86 has two console= options [11:43] same kernel , same initramfs, cmd line [11:43] ) [11:44] TinoGuest: well, what is the actual problem -- you don't get a console on ttyS1, or an unwanted one on tty1, ..? [11:44] * ogra_ understood the prob to be the latter [11:44] (but i might misunderstand) [11:44] pitti: issue is that console stops at some point of systemd initialisation [11:45] TinoGuest, which one [11:45] its actual, serial console on the device. not a virtual console [11:45] on what arch is that ? [11:45] on x86 ones this is expected ... [11:45] ogra_: right, we statically enable getty on tty1 [11:45] btw, virtual console is up.... [11:45] since we use two console= args there [11:45] ogra_: so provide a default if console= is not given, or for containers etc. [11:45] arch=armhf [11:46] so kernel adn bootloader messages go to the first defined console ... subsequent boot messages (userspace) go to the second defined console= [11:46] that doc url talks about serial-getty and just getty [11:46] on armhf we dont really do that [11:48] ogra_: "we" means Ubuntu Core or Server or Classic? [11:48] i.e. the raspeberry pi images only have "console=ttyS0,115200" on their cmdline ... so you wont see boot messages on the screen, but a tty will start there as pitti said above [11:48] i'm talking only about ubuntu core images here [11:48] no idea what server or classic do [11:48] ogra_: maybe changing kernel cmd line would help [11:49] no it wont, as pitti said above, there is a static default for tty1 [11:50] ogra_: ttyS0 or tty1 - same serial console ? what is ttyHSL0 ? [11:50] a device name :) [11:50] the tty name really depends on your hardware === hikiko is now known as hikiko|ln [11:51] i.e. ... dragoboard (arm64) images use console=ttyMSM0,115200n8 ... rppi2/3 images use console=ttyS0,115200 ... [11:52] whatever your HW normally uses for serial needs to be defined there [11:52] ogra_: ok.... i got the impression that systemd somehow supressed serial console and kept virtual console (on the monitor attached) [11:52] if you defined the right values for the console= option you should have both [11:53] ogra_: console= has only one option... this somehow turned into virtual... [11:54] well, whoever ctreated your gadget snap needs to set the right option there ... based on the actual hardware used [11:54] you can specify console= multiple times if you want multiple consoles, the boot output will be multiplexed then [11:54] so the difference in "serial-getty@...." and "getty@..." is not relevant for this? [11:55] not really; the latter gets auto-activated by logind when you Ctrl+Alt+Fn (VT switching), serial console don't [11:55] that's the main difference AFAIK [11:55] ogra_: thats why i asked u if u referring to ubuntu core only :-) [11:55] pitti, nope, it wont be multiplexed ... [11:55] it will always only go to one [11:55] if you define two the first is kernel+bootloader, the second is usersapce messages [11:55] what's the equivalent to "snappy enable-classic" now? [11:56] popey, sudo snap install classic --devmode --edge [11:56] popey, sudo classic [11:56] ogra_: it does get multiplexed [11:56] pitti, thats news to me and alll my installs here disagree :) [11:57] at least the initial grub, kernel messages etc, until userspace kicks in [11:57] oh, right [11:57] initial bootloader stuff might ... [11:57] sweet, thanks ogra_ [11:57] kernel messages then go to the first console= though [11:57] and userspace (initd, systemd boot log etc) go to the second [11:57] *initrd [11:58] pitti: so when userspace kicks in, u still get serial console msgs, and virtual terminal? [11:58] on that level there is no multiplexing [11:58] TinoGuest, yes, because tty1 is statically hardcoded [11:58] so you get a login prompt on both [11:59] yes! thats what i want.... hm somehow i lost it.... ok i will look more into rootfs .... [12:01] I see the "Starting..." messages on both, too [12:01] that is, in installs without "splash" -- plymouth is of course a wholly different story [12:02] on arm HW ? [12:02] i wonder if there is an arch specific difference here [12:02] no, x86 [12:02] aha [12:06] Hi, I've managed to get my code snapped by Launchpad, however when it tries to upload to the store it fails with "Click and Snap packages cannot be mixed." [12:06] Now, I already have a click in the store with the old style package name "com.ubuntu.developer.andrew-hayzen.volleyball2d" but the snap is configured to the package name "volleyball2d". [12:07] Is the problem that it thinks these two have the same name? Or is this a different issue? [12:09] * ogra_ guesses thats a store question [12:12] ogra_: will snapcraft pull the recommended/suggested packages too for the packages listed in the stage-packages? [12:13] bzoltan, nope, it uses --no-install-recommends ... you need to list them [12:14] also note it doesnt run any maintainer scripts (so alternatives dont get set etc) [12:14] ogra_: I will not do it :) I like it exactly this way .. skinny and light [12:20] PR snapd#1892 opened: snap,store: capture newest digest from the store, make it DownloadInfo only [12:27] bzoltan: note the definition of recommends -- "you can remove a recommended package if you know what you are doing" -- i. e. not a good default [12:36] pitti: Of course [12:37] pitti: I am working on to make our IDE package ligher and many of its dependencies pull lots of packages as recommendations what we do not really need... but of course heavy testing follows each removal :) [12:47] mvo, hrm, dropping grub from livecd-rootfs has no effect ... [12:48] * ogra_ wonders where it comes from now === hikiko|ln is now known as hikiko [13:03] oh man [13:04] cjwatson, do you have any hint for me how i can remove a package from a task in an already released release ? http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/view/head:/system-image defines grub binaries which means they get pulled in regardless [13:06] ogra_: You can't unfortunately - this is why point releases tend to use metapackages === chihchun is now known as chihchun_afk [13:07] It's an awkward deficiency that stems from the way tasks are implemented as fields in the Packages file, combined with the fact that we never republish the release suite after release [13:07] yeah, i remembered that, i just had hopes there is some secret trick [13:08] I'm afraid metapackages are the best secret trick I have [13:09] well, except that we dont have them at all for core [13:09] that will be quite a set of changed to livecd-rootfs too [13:09] *changes [13:10] i wonder if i could push a grub package with ripped out task header to the PPA instead ... but that would forever bind us to the PPA [13:10] PR snapcraft#793 opened: Unify python plugin === chihchun_afk is now known as chihchun [13:17] Hi. can somebody triage bug 1621525? I'm wondering how to fix this [13:17] Bug #1621525: classic environment variables for daemon snaps [13:19] arges, i think thats a duplicate of bug 1584811 [13:19] Bug #1584811: Support a snapcraft environment keyword [13:20] ogra_: well i won't know them when I type snapcraft. [13:20] thing HTTP_PROXY, which may or may not exist [13:20] think [13:20] sergiusens: have you seen an issue with snapcraft (or the part) where, during make (make plugin) it copies things to stage but under stage followed by my home directory name.. e.g. i end up with /home/alan/Development/Snappy/foo/stage/home/alan/Development/Snappy/foo/parts/bar/build/... ? [13:21] sergiusens: I don't understand what's doing that, looks like something is using `pwd` [13:22] sergiusens: build stage has the dir correctly, seems to fail going build -> stage [13:29] ogra_: It's indeed not quite trivial but I think it's probably unfortunately what you have to do [13:29] yeah ... *sniff* [13:30] so silly that we picked a task at all for 49 packages (of which i'll drop 6 now) [13:31] cjwatson, oh, i just see there is grub-xen-bin in the list, i think i added it on your request ... is that still needed inside the rootfs ? === SamYaple_ is now known as SamYaple [13:32] (technically all bootloaders moved to the gadget snap now ... ) [13:34] ogra_: I just wanted it to be available at all; I don't currently understand gadget snaps, so if that's a more appropriate place then fine [13:39] well, depends how you use it ... if you actually boot an img file the gadget is what you use ... if you'd do something like "kvm --kernel ... --initrd ... --hda ..." that wouldnt use the gadget [13:39] * ogra_ has no clue about xen :) [13:45] ogra_: You normally have a virtualised disk and boot that. [13:45] ok, then i guess you have a gadget in use [13:46] ogra_: Except that Xen needs to get at the boot loader somehow; there's a protocol for figuring out the right path inside the guest [13:47] and that protocol support is provided by the grub-xen-bin package ? [13:49] ogra_: It sounds closer to a gadget snap, provided that that can cause files to exist under /boot/xen/ [13:49] oh, yeah ... [13:49] (in the same way that grub-install does when told to install for a Xen target) [13:49] though we dont have that mountoint supported atm ... [13:49] mvo, ^^^ [13:50] The protocol in question is documented upstream as https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/x86-xenpv-bootloader.markdown;h=ec8854e6589bcc67e7043410a7157bb0bf481347;hb=HEAD [13:51] (There are older methods as well - I'm ignoring those since they typically involve more manual work) [14:17] oh what a pain ... [14:18] PR snapd#1885 closed: tests: add upower-observe spread test [14:19] o/ [14:19] popey what project? or is it one of our demos? Can I see snapcraft.yaml for it? [14:20] snapcraft cleanbuild just failed to access http://start.ubuntu.com/connectivity-check.html with "http.client.RemoteDisconnected: Remote end closed connection without response" [14:20] sergiusens: trying to repeat it [14:20] I'm wondering if it could be network conflict with docker [14:22] sergiusens: okay, reproduced it. http://paste.ubuntu.com/23169430/ - it's the ptex part which gets built incorrectly [14:23] my output with additional ifconfig and brctl show as extra info: http://paste.ubuntu.com/23169433/ [14:23] akash try snapcraft 2.17 (if you can from the master repo). It is in the process of being released. [14:24] sergiusens: thanks can you point me at where/how to get it for ubuntu 16.04, ill give it a shot [14:29] akash f you are on 16.04; eiter wait for it to be released and it will show up as an update or git clone https://github.com/snapcore/snapcraft.git and look at the .md files in there [14:34] tyhicks: asdasdaasdasda [14:34] ? [14:34] PR snapd#1892 closed: snap,store: capture newest digest from the store, make it DownloadInfo only [14:34] tyhicks: sorry :) [14:34] keyboard stuck [14:34] heh :) [14:35] tyhicks: would you mind lookign at https://github.com/snapcore/snap-confine/pull/135 [14:35] PR snap-confine#135: Add snap-discard-ns [14:35] it's pretty short [14:36] tyhicks: and it will unblock another pull request that actually enables this feature [14:36] tyhicks: note, unlike snap-confine, snap-discard-ns is not setuid root [14:37] zyga: looking [14:40] PR snapd#1893 opened: Remove symlinks for systemd units on apt-get purge [14:52] ogra_: is there a way to create multi arch snaps? [14:52] bzoltan, you dont really want that ... just create one snap per arch with the same name and upload them [14:53] ogra_: Okey, thanks [14:53] else you end up with a gigantic thing that shiops cruft you will never use [14:53] * bzoltan likes poor i386 users [14:53] bzoltan, https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core ... [14:53] take a look at how we do that for ubuntu-core [14:54] ogra_: thanks, that is useful! [15:00] tyhicks: thanks for the review, currently only snap-confine creates /run/snapd/ [15:01] zyga: ah, sc_initialize_ns_groups() creates it, doesn't it? [15:01] tyhicks: correct [15:02] zyga: nice - we're all good then [15:02] zyga: I'll follow up in the PR [15:02] tyhicks: thanks :) [15:03] sergiusens: thank you very much for the pointer that worked!! At least the app seems to have fired up in devmode, ill see if it functions is strict as well. In devmode it fires up on port 8123 just fine. [15:04] PR snapd#1894 opened: README.md: tweaks to the spread+qemu instructions [15:19] I have no idea what I did wrong, but I'm getting "error: cannot find signatures with metadata for snap" when installing a snap I've just created [15:20] PR snapd#1894 closed: README.md: tweaks to the spread+qemu instructions [15:27] popey the readme for ptex mentions this: make prefix=$PWD/install [15:27] in make-parameters you might want to add prefix=$SNAPCRAFT_PART_INSTALL [15:27] oh we're not allowed to install things we make without telling it we really really really want to install a thing we made (--force-dangerous)... o_O [15:28] * diddledan pinkyswears that his snap won't be naughty [15:30] right. so corebird needs some new schemas installed into gsettings or it fails to start. how do I go about telling my snap about these settings? [15:30] ref: (corebird:26868): GLib-GIO-ERROR **: Settings schema 'org.baedert.corebird' is not installed [15:32] diddledan, where is that schemas getting installed in your snap? [15:32] seb128: my point is I don't know how to install the settings, hence why they're not installed [15:33] sergiusens: will try, thanks [15:33] diddledan, usually the upstream make install does that for you [15:37] seb128: the make install might have put the file at /snap/corebird/current/share/glib-2.0/schemas/org.baedert.corebird.gschema.xml ?? [15:38] otherwise it's not installed at all [15:38] I think this is the file that should be somewhere: https://github.com/baedert/corebird/blob/master/corebird.gresource.xml [15:39] tyhicks: this enables namespace sharing https://github.com/snapcore/snap-confine/pull/134/files [15:39] PR snap-confine#134: Enable snap-confine namespace sharing [15:39] tyhicks: there's one thing that jdstrand suggested that I change (use change profile instead of change hat) [15:39] tyhicks: I'm worried about interactions between device cgroup and the ns sharing feature though [15:40] tyhicks, jdstrand: ^^ your review would be appreciated [15:40] zyga: what is the system-wide writable directory for a snap? [15:40] sergiusens: :( still does it even with that set [15:40] mhall119: /var/snap/$SNAP_NAME/{common,$SNAP_REVISION} AFAIR [15:41] tyhicks: and for you specifically; I could really use some insight into https://github.com/snapcore/snap-confine/pull/133 [15:41] PR snap-confine#133: Adjust apparmor policy for compatibility with snap-exec [15:41] zyga: that's $SNAP_DATA right? [15:41] mhall119: that's correct [15:42] diddledan, that seems about right, you might hit bug #1590831 if you use prefix=/usr and the desktop launcher it should work [15:42] Bug #1590831: having prefix='' by default is non standard and confusing [15:43] zyga: I'm getting some permission errors: [15:43] mhall@mhall-thinkpad:~/projects/Ubuntu/snaps/tomcat/snap$ snap run tomcat [15:43] cp: cannot create regular file '/var/snap/tomcat/x1/conf/jaspic-providers.xsd': Permission denied [15:43] cp: cannot create regular file '/var/snap/tomcat/x1/conf/catalina.policy': Permission denied [15:43] trying to copy files from $SNAP to $SNAP_DATA [15:43] what's odd is that it creates the 'conf' directory just fine, but as user 'root' and then fails to copy files into it [15:44] mhall119: that directory is only designed for stuff that runs as root [15:44] mhall119: it's not writable by all users [15:44] seb128: yeah that bug report does look like it might be relevant, thanks [15:44] mhall119: to "services" [15:44] zyga: should webservices like Tomcat use that or use $SNAP_USER_DATA? [15:45] diddledan, yw, comment on it maybe more people hitting the problem is going to convince the snapcraft team that it's an issue [15:45] it will eventually be running as a daemon [15:45] also, why does it allow creating a directory but not files? [15:46] mhall119: if it's a service it runs as root and it cannot use $SNAP_USER_DATA, it must use $SNAP_DATA [15:46] stgraber: FYI: https://github.com/snapcore/snap-confine/pull/134 [15:46] PR snap-confine#134: Enable snap-confine namespace sharing [15:46]