[00:58] who can i bribe to get https://github.com/snapcore/snapd/pull/3065 merged? [00:58] PR snapd#3065: Allow seeding a snap with classic confinement [01:09] mwhudson: I can ping zyga in the morning to see what's missing with that merge. [01:09] I meant to today, but when I thought of it it looks like it was too late, he wasn't online. [01:12] cyphermox: fair enough [01:14] mwhudson: if someone else answers before then... well we'll see here :) [01:14] cyphermox: yeah pinging at this time of day is more in hope than expectation [03:03] PR snapcraft#1222 opened: beta [04:21] PR snapcraft#1222 closed: beta [06:12] PR snapd#3089 opened: interfaces: drop udev tagging from framebuffer interface [06:40] PR snapd#3083 closed: tests: move unity test to nightly suite [06:46] ubuntu-make classic snap is still not published on amd64 (but acked on all other archs) since yesterday. Is that an oversight? [06:47] PR snapd#3065 closed: Allow seeding a snap with classic confinement [06:48] PR snapd#3071 closed: many: ignore configure hook failures on core refresh [07:26] PR snapd#3078 closed: tests: remove stale apt proxy leftover from cloud-init [08:17] pstolowski: hi! I'll address the chanegs requested by Jamie -- thanks for your other updates! [08:20] PR snapd#3090 opened: hookstate: add ability to report hook failures to the errtracker [08:26] mardy, cool, yw! [08:31] PR snapd#3064 closed: packaging: rename the file shipping snap-confine AA profile [08:36] Question: How do I access data on a mounted ntfs partition from a snappy-packaged application on 16.04? paths on mounted drive don't show up. fsstab uses fuseblk fs as per installation. [08:46] ptrtng, did you try using the removable-media interface ? [08:47] (assuming your partition mounts under /media this should be accessible) [08:49] here is my current fstab entry: UUID=XXXXXXXXXXXXXXXX /data ntfs uid=1000,gid=1000,users,nodev,noexec,noatime 0 0 [08:49] note uid and gid are from my own tries to bend the user to my username. didn't work. [08:50] the /data dir is accessible from bash and file manager. [08:50] the current mount entry is: /dev/sdb1 on /data type fuseblk (rw,nosuid,nodev,noexec,noatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096) [08:54] the /data dir wont be accessible by snaps ... as i said ... use something like /media/ntfsdrive to mount it and use the removable-media interface in your snap [08:55] PR snapd#3091 opened: interfaces/seccomp: add bind as part of the default seccomp policy for hooks === vigo_ is now known as vigo [08:58] ppisati, should bluetooth work on the pi3 ? did you ever test that ? [08:59] ok. I removed the fstab entry. mounted using dolphin. mount says: dev/sdb1 on /media/USERNAME/data type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2) . [08:59] ptrtng, goo, now make your snap use the removable-media interface and your snap apps should be able to see it [08:59] guys i have a fundamental question [08:59] *good even [09:00] does snaps use os level virtualization [09:00] ok. thats why the app doesn't see the /media directory. [09:00] no, snaps dont use virtualization by default [09:00] BTW its not my own. I merely try to use it. [09:01] well, then you should probaly contact the developer so he/she adds that interface :) [09:01] so how is the isolation of snaps atchived [09:01] ppisati, bug 1674509 ... and i'm not sure if it shoudl work (i definitely see the devices created in dmesg if i load the module) [09:01] Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 [09:02] *achieved [09:02] chani, via apparmor, seccomp and namespaces [09:02] chani, https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ has all the dirty details [09:03] @orgac thanks for your help. I see me just using apt in this case. Pity. [09:03] ptrtng: No such command! [09:03] thanks ogra [09:03] pitty [09:03] ptrtng, what app was it ? i'm sure the maintainer would like to know about your issue [09:03] (i know i would if it was my app) [09:04] i have one more issue though [09:05] the snap in question is: openmvs 0.7.0-2a41453-0 2 [09:06] sorry I was wrong the app is: mve 20170210-0 1 mardy. [09:07] i have used apache as my stage-packages and once i have installed the app [09:07] i want the apache to start [09:08] From the same people. I'll contact them by myself. Thanks for the help [09:09] i tried to start it through my terminal it seems to use my system path rather than snap application path to search for files [09:09] mardy, mind adding support for the removable-media interface to mve ? sounds like a valid addition if you want to use files from removable media [09:09] ptrtng, ogra_: hi :-) [09:09] :) [09:09] sure, I'll do that [09:09] thanks! [09:09] like it fetches webpages from /var/www rather than /snap/my_app/current/var/www [09:10] chthen you need to adjust the config [09:10] so what should i do to make the root of my apache /snap/my_app/current/ [09:10] choh, wait ... how do you start it ? you should have a daemon entry in your snapcraft.yaml for it and use systemctl if it is a daemon [09:12] so if i write a bash file and run it as a deamon it would by default use my /snap/my_app/current/ as root [09:12] yeah [09:12] did i get it right [09:13] ok thanks i will try that thanks :) [09:13] an example is at: https://github.com/snapcore/snapcraft/blob/master/demos/webcam-webui/snap/snapcraft.yaml and https://github.com/snapcore/snapcraft/blob/master/demos/webcam-webui/webcam-webui is a script it uses to run the httpd and a cam capturing service in a loop [09:15] ogra_: uhm, i don't remember testing it, and the problem on the rpi3 is that serial and bluetooth are contending the uart [09:15] ogra_: i need to test it [09:15] koza, see above ... we are not actually sure BT should work on the pi3 ... [09:16] the bash script uses #!/bin/bash as its shell right so when the deamon runs the bash file will it use bash shell to run the script [09:17] if so how is the root changed to /snap/my_app/current/ [09:17] thats done by a builtin wrapper when the snap app gets executed [09:17] along with adding $SNAP/lib to your library path etc === ycheng is now known as ycheng-afk [09:18] where can i get the details of this implementation. just out of curiosity :P [09:19] is it in the whitepapers [09:20] i think there is some of it, yeah ... under FHS [09:20] and in "Snap security policy" too [09:24] thanks a lot ogra i was struck on the changing root dir for a day now it would have been a day or more if you didn't clarify it. :) :) :) [09:37] ptrtng: try "snap refresh" [09:38] PR snapd#3092 opened: interfaces: capitalize Udev... as UDev [09:49] PR snapcraft#1223 opened: kernel plugin: check_config() and check_initrd() support [10:06] Pharaoh_Atem: looks like we have one minor issue left for i386 builds of snap-confine [10:06] Pharaoh_Atem: https://copr-be.cloud.fedoraproject.org/results/mrmorph/snapcore/fedora-25-i386/00533426-snapd/build.log.gz [10:14] ogra_, hey, reading [10:15] unity [10:25] jdstrand: unsure if it's on your plate as well or not: ubuntu-make classic snap is not published on amd64 (but acked on all other archs) since yesterday. Is that an oversight? === hikiko is now known as hikiko|bbl [11:22] jdstrand: hey, can you review https://github.com/snapcore/snapd/pull/3091 [11:22] PR snapd#3091: interfaces/seccomp: add bind to default seccomp template for hooks === hikiko|bbl is now known as hikiko [11:51] mardy: I just tried your meshlab-mardy snap. I am seeing the same external-disks-accessible' issue as with openmvg. Would you care to fix that too? [12:15] ptrtng: which version is it ("snap info")? [12:15] ptrtng: for some reason it seems that "snap refresh" is not actually updating anything, weird [12:16] mardy: snap refresh is not updating devmode snaps [12:16] mardy: which OS is this? [12:16] mardy: we had a bug where we'd mark everything as devmode unless confinement was on [12:16] mardy: so no snaps would update [12:16] mardy: we'd fix core as a special-case but not any other snap [12:18] zyga: I'm on xenial, the snapcraft.yaml has "confinement: strict", but I don't remember if I used --devmode when installing it [12:18] mardy: check bash history :) [12:18] Son_Goku: eh, that was long ago :-) [12:19] mardy: snap info says tihs [12:19] if you didn't clobber ~/.bash_history, it should still be there [12:19] mardy: if you see devmode there it's devmode [12:20] mardy: I used 'meshlab-mardy 2016.12-20170302-2 4' [12:21] zyga: oh, could it be that I installed it from a local snap? I see that "publisher" is empty: http://paste.ubuntu.com/24267528/ [12:24] mardy, (x2) tells you it was local, yeah [12:24] mardy: yes [12:24] mardy: those won't refresh [12:24] zyga, ogra_: ah ok, that's expected, sorry for the noise [12:33] PR snapd#3093 opened: cmd: discard the C implementation of snap-update-ns [12:45] didrocks: it was approved but not released. I don't personally release snaps after they are approved since the I don't know what channel things should go in. I think popey may have approved these yesterday though. anyway, if you want to release it still (I see you have a new upload for amd64), you can use snapcraft to do so (or just tell me here what channels it should go to) [12:45] zyga: hey, sure [12:49] jdstrand: yeah, I noticed that meanwhile, it was actually done, great! [13:03] jdstrand: thank you [13:03] zyga: ok, you're right, it is the missing largefile support: https://paste.ubuntu.com/24267713/ [13:05] morphis: glad to hear that was it [13:05] xfs ? [13:05] why the hell is anyone using xfs :P [13:05] (apart from IBM) [13:06] IBM would be using JFS [13:06] ogra_: its for some constants coming from xfs/xqm.h for confinement [13:06] SGI was XFS [13:06] oh, right, not IBM [13:06] yeah, just constants [13:08] Son_Goku: btw. if you have a min, I've updated the templating PR [13:09] ptrtng: done, please refresh meshlab [13:10] ogra_: would it annoy you if someone did use xfs.....if so they are probably using it because I paid them to annoy you sorry ;) [13:10] ptrtng: there's a problem though: you need to explicitly type /media/ in the filename field, because the /media directory itself is not actually readable [13:11] morphis: you need to fix snapd.system-shutdown.service too [13:13] mvo: hey, you there? [13:13] Son_Goku: you mean adding template vars to it? [13:13] morphis: yep [13:14] Son_Goku: it's not going to be used on any classic system, that is why I skipped it [13:14] if you're going to do this, do it right :) [13:14] you never know [13:15] and if you don't want people to use it another way than what it is supposed for then enforcement is better [13:16] AFAIK we don't test it anywhere else and therefor shouldn't ship it as an option [13:16] but leave this up to mvo and zyga [13:16] your makefile already installs it [13:16] davmor2, well, the paste was showing pokey-linux ... which is usually embedded ... using something like xfs or zfs in embedded would be rather insane (memory hog) [13:17] morphis, and it's better to not presume that you guys will be the only "Snappy" system producers [13:17] ogra_: hahahahaha [13:17] I know zyga keeps shooting me down about it, but I fully expect that someone will want to build a snappy system on CentOS or Yocto or whatnot [13:17] Son_Goku, we''ll just trademark it :P [13:18] ogra_: you already did :/ [13:18] Son_Goku: but you mean by "snappy" system? that word is already too overloaded :-) [13:18] clever us ;) [13:18] morphis: I mean that a system is composed as a snap-centric system like Ubuntu Core [13:18] except not being Ubuntu based [13:18] morphis, yeah, we should trademark "core" :) [13:18] ogra_: too generic :) [13:18] :-) [13:19] coreOS ;-) [13:19] Canonical holds trademarks for "Ubuntu Core" and "Ubuntu Snappy Core", think [13:19] yeah [13:19] to specific :P [13:19] but if I want to make "Fedora Snappy Core", it's not particularly difficult [13:19] zyga, mvo: its your call on templating for snapd.system-shutdown.service or not [13:19] ogra_: I think the gym guys beat you too it and intel and ..... well you know the list goes on [13:19] Son_Goku: fedora core, like ubuntu core, mozilla ;-) [13:19] Son_Goku: make it an user-agent problem [13:19] well, Fedora Core was a thing :) [13:20] ubuntu core was a thing since 6 years or so [13:20] but not the core you are looking for :) [13:20] ogra_: Fedora Core was the original name of the Fedora distribution :) [13:20] when Red Hat Linux was merged into the Fedora Project, "Fedora Core" represented the RHL bits [13:21] that name is still trademarked by Red Hat [13:25] Son_Goku: btw. do you have packages for snapd-glib somewhere too? [13:25] in Fedora dist-git [13:25] that builds fine and can be upgraded [13:25] it just can't be installed because snapd isn't available [13:25] zyga is the maintainer of snapd-glib, you'll need to request comaint privs on pkgdb [13:29] Son_Goku: ok, let me do that [13:29] Son_Goku: still waiting for the golang-* packages to be added to pkgdb here . [13:30] morphis: poking people in #fedora-admin might be appropriate then [13:30] Son_Goku: sounds like a good idea [13:33] Son_Goku, zyga: ok also requested admin access for snapd / snapd-glib [13:36] zyga, morphis: I've approved snapd-glib ACLs, but I'm going to wait on snapd ones until after you have your golang stuff [13:37] Son_Goku: aye [13:37] Son_Goku: thanks [13:37] zyga: ok, https://github.com/morphis/snapd/commit/26a1a4b695d608596c76ee84ee00e9ecf4188267 solves the xqm.h problem but it looks a bit clumpy [13:38] looking [13:39] morphis: you can alternatively use a custom checker and just #define the right stuff inside [13:39] morphis: no need to touch CFLAGS [13:39] zyga: no that doesn't work [13:39] I tried it [13:40] but can't explain yet why .. [13:41] zyga: https://paste.ubuntu.com/24267906/ [13:43] morphis: no idea, autotools magic [13:43] let me try one thing .. [13:44] actually that paste is wrong one .. but anyway [13:48] mvo: ta, this will really help [13:50] PR snapd#3094 opened: cmd: rework header check for xfs/xqm.h [13:50] zyga: ^^ [13:54] morphis: checking [14:10] Hey, I've created an Ubuntu Core LXD container and I want to be able to create users on it (which I think means I need to make the system writable) ... According to this man page (http://manpages.ubuntu.com/manpages/xenial/man5/writable-paths.5.html) I should be editing the file /etc/system-image/writable-paths however, it doesn't exist and I cannot find it anywhere on the container, does anyone have any ideas? [14:17] mardi: I've checked out your meshlab update: Fails. See https://pastebin.com/gafuPLAg for more info. [14:41] PR snapd#3093 closed: cmd: discard the C implementation of snap-update-ns [14:43] hi all is it possibile to bind udp/67 port in strict mode? [14:51] PR snapd#3095 opened: cmd/snap-update-ns: add C preamble for setns [15:17] jdstrand, if I publish a gadget and also publish a snap that uses a serial-port slot provided by that gadget, do I need an assertion to autoconnect those? [15:19] kyrofa: you may need to today, but my understanding was that the gadget snap has a voice in autoconnection, so I think the design is you shouldn't [15:20] jdstrand, alright, I may be pinging you about that in a bit, then [15:20] kyrofa: if it doesn't work, I can issue a snap decl if needed, but please file a bug in that case [15:20] Sounds good [15:20] Yeah this has been a good exercise [15:20] I don't have the specifics on gadgets and autoconnection. I think morphis has done a few though [15:26] jdstrand, kyrofa: AFAIK this isn't possible today [15:28] morphis, alright, thank you [15:29] kyrofa: according to what I've heard from pedronis this should be possible in some way later [15:34] kyrofa: btw. I've started to use the nextcloud snap recently and have it now in a production environment, awesome work :-) [15:35] morphis, why thank you! [15:35] kyrofa: I really liked how it did everything for me including the lets-encrypt setup [15:35] magic :-) [15:36] morphis, yeah that took some time to work out, heh [15:36] coming from a 14.04 setup where I throw everything away no because they told me to install php5.6 from some ppa to be still able to install nextcloud 11 [15:36] s/no because/now because/ [15:37] Yeah it was always painful to maintain for me, too [15:37] but having something coming officially from nextcloud is quite nice and is enough for my trust level :-) [15:37] yeah [15:37] its quite interesting that they officially still state they support 14.04 where they clearly don't unless you install php from a ppa which also ships a patched version of openssl .. [15:38] Haha, "we support 12.04 too!" [15:38] :-D [15:38] kyrofa: I always only believe those things when I see and feel it them [15:39] morphis, the only weirdness with the snap is that automatically updating will sometimes disable your apps [15:40] morphis, keep that in mind, if they disappear, just re-enable them, you didn't lose anything [15:40] morphis, they're working on fixing that in nextcloud itself, sounds like [15:43] kyrofa: yeah .. had this with the regular install too [15:44] always had my dad crying his calendar and contacts disappeared :-) [15:45] Yeah... annoying [15:50] kyrofa: but good to know they are fixing this at the root of the whole thing [15:55] PR snapcraft#1224 opened: tests: fix name registration window limit test to latest changes [16:18] barry, in case you didn't notice, snapcraft v2.28 is in -updates [16:22] kyrofa: oh cool. i don't see them in rmadison yet, but that might just be delay. as soon as the autopkgtests w/o -proposed passes, i can land the branch and get u-i 1.0 classic snap uploaded [16:22] kyrofa: conveniently, it's lunch time :) [16:23] barry, hmm... indeed, I may have lied [16:27] barry, yeah it's verification-done, but not in -updates yet. I may have been fooled by an lxd container setup with proposed darnit, sorry [16:30] PR snapd#3096 opened: many: abstract path to /bin/{true,false} [16:36] jdstrand, hey [16:37] jdstrand, tyhicks , I was making some changes to the dbus performance tests and I noticed the big overhead is when the confinment is not strict [16:38] jdstrand, tyhicks in case the confinement is strict the overhead is aroud 15 to 20 % [16:40] cachio: when you say "when the confinement is not strict", are you referring to devmode, classic, or both of those confinement modes? [16:41] devmode [16:41] interesting [16:41] tyhicks, I used to install it with --devmode [16:42] then I removed that and I started getting results with 15-20$ of overhead [16:42] cachio: to make sure I understand, the dbus mediation with strict confinement mode is within our expected range (15-20%) [16:42] tyhicks, yes [16:42] agree [16:42] cachio: the dbus mediation with devmode confinement mode sometimes exceeds our expected range (> 25%) [16:42] ok [16:42] that could be really helpful when reviewing the code [16:43] tyhicks, it is about 35% with devmod confinment [16:46] cachio, jdstrand: this is starting to feel like an auditing overhead to me [16:47] cachio: are audit messages being sent to /var/log/syslog for every message you send? [16:48] cachio: you'll have a ton of apparmor="ALLOWED" messages if that's the case [16:48] tyhicks, let me see [16:52] tyhicks, well there are many entries for dbus in syslog [16:52] tyhicks, but not sure if there are so many to cause that [16:52] cachio: is there one that looks to repeat a lot? [16:52] cachio: if so, please paste it [16:53] tyhicks, this one http://paste.ubuntu.com/24268835/ [16:54] cachio: ok, that is definitely coming from dbus-daemon [16:55] the in-code overhead for a devmode snap talking on dbus is two calls to this function: http://paste.ubuntu.com/24268842/ [16:56] however, if the message/signal is not allowed by the snappy policy, it'll generate an audit message through libaudit which could add significant overhead if a large number of messages/signals are sent [17:00] tyhicks, something that also could help you is that I am also plugging the mount-observe interface [17:00] tyhicks, could that affect in the results? [17:00] mvo: would it be possible to split the vendoring for snapd into an overlay tarball? [17:00] that is, a tarball that is overlaid on top of an unvendored snapd tarball [17:01] cachio: I don't think so [17:04] kyrofa: cool. if it's verification-done, it'll show up soon enough [17:11] ogra_, I just noticed that the Dragonboard gadget has architectures: [armhf] [17:11] ogra_, shouldn't that be arm64? [17:12] jdstrand: hey [17:14] zyga: hey [17:14] jdstrand: can you please try to review https://github.com/snapcore/snapd/pull/3091 today, I think mvo wants this for an SRU [17:14] PR snapd#3091: interfaces/seccomp: add bind to default seccomp template for hooks [17:15] zyga: I plan to [17:15] jdstrand: it's a workaround for golang doing "bind" and snapctl [17:15] I read it. I'm thinking about my response [17:15] barry: kyrofa I haven't pulled the trigger yet on releasing to -updates [17:15] jdstrand: aha, that's great, I just wanted to make sure you had an eye on this before it gets merged (it has two +1s) [17:16] sergiusens: what's the hold up? [17:17] cachio: curious-- are you connecting the interface when in strict mode and not connecting the interface in devmode? [17:17] tyhicks: ^ [17:18] zyga: did you have a chance to talk to mvo about overlay tarballs? [17:18] people sometimes forget to connect their interfaces in devmode... [17:18] Pharaoh_Atem: no, because there was no release plan decision until today [17:18] Pharaoh_Atem: I'll ask [17:18] zyga: cool [17:18] mvo: Pharaoh_Atem had an idea that we could release vanilla git tree + the vendor/ directory separately as that would ease packaging [17:18] Pharaoh_Atem: for vendorized builds we would consume both tarballs [17:19] Pharaoh_Atem: and for de-vendorized builds just one [17:19] Pharaoh_Atem: it shouldn't be be harder than what we do now (vendorized) [17:19] er [17:19] mvo: ^^ [17:19] * zyga is tired [17:19] it would make it much less painful for supporting EL7 builds along with Fedora builds [17:19] mvo: and once we have a script for making this should be essentially free [17:20] * zyga needs to walk again [17:20] (offline) [17:22] jdstrand, could you take a look at the dragonboard-turtlebot-kyrofa gadget when you're able, please? [17:22] Same thing as the amd64 gadget (serial-port workaround) [17:25] jdstrand, I am connecting in both [17:25] jdstrand, it is the same execution [17:25] jdstrand, the diff is the when I install [17:26] kyrofa: done [17:27] cachio: the diff is when you install? I don't understand. you mean you see a difference between when you install and when you connect the interfaces? as such, in strict mode before connecting and complain mode before connecting? [17:27] jdstrand, thank you! [17:27] (you see a difference) [17:28] kyrofa: I made a change to the review tools as well. the pc gadget should now pass automated review, but this one will be a little while for prod [17:28] jdstrand, indeed I've already experienced the pc passing, thank you :) [17:37] jdstrand, I install, then I connect and then I run the tests [17:38] jdstrand, that for strict and devmode [17:38] jdstrand, all the steps are equal, but hte install [17:38] jdstrand, the diff I see is when I run the tests [17:38] it is once the whole snap setup is done [17:39] ok [17:39] tyhicks: ^ (you probably figured all that out already...) [18:08] PR snapd#3091 closed: interfaces/seccomp: add bind to default seccomp template for hooks [18:29] Hey barry, I just hit an interesting python problem if you have a sec [18:29] kyrofa: i do [18:30] I have a plugin that ends up pulling two dependencies, one of which is python2, the other is python3 [18:31] barry, which means that I have two different python installs essentially contained in my part directory [18:31] barry, however, I only have one PYTHONPATH. Is there a way for me to set an environment that says "python2 stuff look here, python3 stuff look there"? [18:32] kyrofa: unfortunately there isn't. $PYTHONPATH is the same envar for both python2 and python3. you'll have to put that on the command line, e.g. PYTHONPATH=foo:bar python2 whatever.py [18:33] barry, hmm... the problem is that a third dependency drives the actual build process, so I can't get anything into the cli [18:33] kyrofa: hmm [18:33] Nasty [18:33] yep :) [18:34] too bad you can't just port the py2 bits to py3 :) [18:34] I didn't actually realize I had a python3 dependency in there until I saw a build failure happen on LP which apparently doesn't include lsb-release [18:34] kyrofa: can you arrange for a module to get imported early in the build process? [18:34] barry, the build process is actually cmake. You would cry if you saw this [18:35] because that module could test for the python version and then hack sys.path accordingly [18:35] kyrofa: i'm tearing up just thinking about it ;) [18:36] barry, alright, thanks for the insight! I'll mull this over [18:36] kyrofa: okay, good luck! [18:37] hi, trying to install snapd on a raspberry pi 3 running raspbian. Any shortcut from installing go and building from sources ? [18:37] anorgrull, I don't believe raspbian includes the necessary appamor kernel patches [18:38] anorgrull, zyga or morphis could probably talk you through building the necessary bits while disabling confinement, if you want to go that route [18:41] anorgrull: hey [18:41]