[00:58] <mwhudson> who can i bribe to get https://github.com/snapcore/snapd/pull/3065 merged?
[00:58] <mup> PR snapd#3065: Allow seeding a snap with classic confinement <Created by cyphermox> <https://github.com/snapcore/snapd/pull/3065>
[01:09] <cyphermox> mwhudson: I can ping zyga in the morning to see what's missing with that merge.
[01:09] <cyphermox> I meant to today, but when I thought of it it looks like it was too late, he wasn't online.
[01:12] <mwhudson> cyphermox: fair enough
[01:14] <cyphermox> mwhudson: if someone else answers before then... well we'll see here :)
[01:14] <mwhudson> cyphermox: yeah pinging at this time of day is more in hope than expectation
[03:03] <mup> PR snapcraft#1222 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1222>
[04:21] <mup> PR snapcraft#1222 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1222>
[06:12] <mup> PR snapd#3089 opened: interfaces: drop udev tagging from framebuffer interface <Created by chunsangjeong> <https://github.com/snapcore/snapd/pull/3089>
[06:40] <mup> PR snapd#3083 closed: tests: move unity test to nightly suite <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3083>
[06:46] <didrocks> ubuntu-make classic snap is still not published on amd64 (but acked on all other archs) since yesterday. Is that an oversight?
[06:47] <mup> PR snapd#3065 closed: Allow seeding a snap with classic confinement <Created by cyphermox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3065>
[06:48] <mup> PR snapd#3071 closed: many: ignore configure hook failures on core refresh <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3071>
[07:26] <mup> PR snapd#3078 closed: tests: remove stale apt proxy leftover from cloud-init <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3078>
[08:17] <mardy> pstolowski: hi! I'll address the chanegs requested by Jamie -- thanks for your other updates!
[08:20] <mup> PR snapd#3090 opened: hookstate: add ability to report hook failures to the errtracker <Created by mvo5> <https://github.com/snapcore/snapd/pull/3090>
[08:26] <pstolowski> mardy, cool, yw!
[08:31] <mup> PR snapd#3064 closed: packaging: rename the file shipping snap-confine AA profile <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3064>
[08:36] <ptrtng> 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] <ogra_> ptrtng, did you try using the removable-media interface ?
[08:47] <ogra_> (assuming your partition mounts under /media this should be accessible)
[08:49] <ptrtng> here is my current fstab entry:  UUID=XXXXXXXXXXXXXXXX /data ntfs  uid=1000,gid=1000,users,nodev,noexec,noatime  0   0
[08:49] <ptrtng> note uid and gid are from my own tries to bend the user to my username. didn't work.
[08:50] <ptrtng> the /data dir is accessible from bash and file manager.
[08:50] <ptrtng> 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] <ogra_> 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] <mup> PR snapd#3091 opened: interfaces/seccomp: add bind as part of the default seccomp policy for hooks <Created by morphis> <https://github.com/snapcore/snapd/pull/3091>
[08:58] <ogra_> ppisati, should bluetooth work on the pi3 ? did you ever test that ?
[08:59] <ptrtng> 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] <ogra_> ptrtng, goo, now make your snap use the removable-media interface and your snap apps should be able to see it
[08:59] <chani> guys i have a fundamental question
[08:59] <ogra_> *good even
[09:00] <chani> does snaps use os level virtualization
[09:00] <ptrtng> ok.  thats why the app doesn't see the /media directory.
[09:00] <ogra_> no, snaps dont use virtualization by default
[09:00] <ptrtng> BTW its not my own. I merely try to use it.
[09:01] <ogra_> well, then you should probaly contact the developer so he/she adds that interface :)
[09:01] <chani> so how is the isolation of snaps atchived
[09:01] <ogra_> 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] <mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <Snappy:New> <https://launchpad.net/bugs/1674509>
[09:02] <chani> *achieved
[09:02] <ogra_> chani, via apparmor, seccomp and namespaces
[09:02] <ogra_> chani, https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ has all the dirty details
[09:03] <ptrtng> @orgac thanks for your help.  I see me just using apt in this case. Pity.
[09:03] <nothal> ptrtng: No such command!
[09:03] <chani> thanks ogra
[09:03] <ptrtng> pitty
[09:03] <ogra_> ptrtng, what app was it ? i'm sure the maintainer would like to know about your issue
[09:03] <ogra_> (i know i would if it was my app)
[09:04] <chani> i have one more issue though
[09:05] <ptrtng> the snap in question is:  openmvs   0.7.0-2a41453-0  2
[09:06] <ptrtng> sorry I was wrong the app is: mve       20170210-0       1     mardy.
[09:07] <chani> i have used apache as my stage-packages and once i have installed the app
[09:07] <chani> i want the apache to start
[09:08] <ptrtng> From the same people. I'll contact them by myself. Thanks for the help
[09:09] <chani> 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] <ogra_> 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] <mardy> ptrtng, ogra_: hi :-)
[09:09] <ogra_> :)
[09:09] <mardy> sure, I'll do that
[09:09] <ptrtng> thanks!
[09:09] <chani> like it fetches webpages from /var/www rather than /snap/my_app/current/var/www
[09:10] <ogra_> chthen you need to adjust the config
[09:10] <chani> so what should i do to make the root of my apache /snap/my_app/current/
[09:10] <ogra_> 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] <chani> 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] <ogra_> yeah
[09:12] <chani> did i get it right
[09:13] <chani> ok thanks i will try that thanks :)
[09:13] <ogra_> 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] <ppisati> 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] <ppisati> ogra_: i need to test it
[09:15] <ogra_> koza, see above ... we are not actually sure BT should work on the pi3 ...
[09:16] <chani> 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] <chani> if so how is the root changed to /snap/my_app/current/
[09:17] <ogra_> thats done by a builtin wrapper when the snap app gets executed
[09:17] <ogra_> along with adding $SNAP/lib to your library path etc
[09:18] <chani> where can i get the details of this implementation. just out of curiosity :P
[09:19] <chani> is it in the whitepapers
[09:20] <ogra_> i think there is some of it, yeah ... under FHS
[09:20] <ogra_> and in "Snap security policy" too
[09:24] <chani> 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] <mardy> ptrtng: try "snap refresh"
[09:38] <mup> PR snapd#3092 opened: interfaces: capitalize Udev... as UDev <Created by zyga> <https://github.com/snapcore/snapd/pull/3092>
[09:49] <mup> PR snapcraft#1223 opened: kernel plugin: check_config() and check_initrd() support <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1223>
[10:06] <morphis> Pharaoh_Atem: looks like we have one minor issue left for i386 builds of snap-confine
[10:06] <morphis> Pharaoh_Atem: https://copr-be.cloud.fedoraproject.org/results/mrmorph/snapcore/fedora-25-i386/00533426-snapd/build.log.gz
[10:14] <koza> ogra_, hey, reading
[10:15] <koza> unity
[10:25] <didrocks> 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?
[11:22] <zyga> jdstrand: hey, can you review https://github.com/snapcore/snapd/pull/3091
[11:22] <mup> PR snapd#3091: interfaces/seccomp: add bind to default seccomp template for hooks <Created by morphis> <https://github.com/snapcore/snapd/pull/3091>
[11:51] <ptrtng> 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] <mardy> ptrtng: which version is it ("snap info")?
[12:15] <mardy> ptrtng: for some reason it seems that "snap refresh" is not actually updating anything, weird
[12:16] <zyga> mardy: snap refresh is not updating devmode snaps
[12:16] <zyga> mardy: which OS is this?
[12:16] <zyga> mardy: we had a bug where we'd mark everything as devmode unless confinement was on
[12:16] <zyga> mardy: so no snaps would update
[12:16] <zyga> mardy: we'd fix core as a special-case but not any other snap
[12:18] <mardy> 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] <Son_Goku> mardy: check bash history :)
[12:18] <mardy> Son_Goku: eh, that was long ago :-)
[12:19] <zyga> mardy: snap info says tihs
[12:19] <Son_Goku> if you didn't clobber ~/.bash_history, it should still be there
[12:19] <zyga> mardy: if you see devmode there it's devmode
[12:20] <ptrtng> mardy: I used 'meshlab-mardy  2016.12-20170302-2  4'
[12:21] <mardy> 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] <ogra_> mardy, (x2) tells you it was local, yeah
[12:24] <zyga> mardy: yes
[12:24] <zyga> mardy: those won't refresh
[12:24] <mardy> zyga, ogra_: ah ok, that's expected, sorry for the noise
[12:33] <mup> PR snapd#3093 opened: cmd: discard the C implementation of snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3093>
[12:45] <jdstrand> 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] <jdstrand> zyga: hey, sure
[12:49] <didrocks> jdstrand: yeah, I noticed that meanwhile, it was actually done, great!
[13:03] <zyga> jdstrand: thank you
[13:03] <morphis> zyga: ok, you're right, it is the missing largefile support: https://paste.ubuntu.com/24267713/
[13:05] <zyga> morphis: glad to hear that was it
[13:05] <ogra_> xfs ?
[13:05] <ogra_> why the hell is anyone using xfs :P
[13:05] <ogra_> (apart from IBM)
[13:06] <Son_Goku> IBM would be using JFS
[13:06] <morphis> ogra_: its for some constants coming from xfs/xqm.h for confinement
[13:06] <Son_Goku> SGI was XFS
[13:06] <ogra_> oh, right, not IBM
[13:06] <zyga> yeah, just constants
[13:08] <morphis> Son_Goku: btw. if you have a min, I've updated the templating PR
[13:09] <mardy> ptrtng: done, please refresh meshlab
[13:10] <davmor2> 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] <mardy> ptrtng: there's a problem though: you need to explicitly type /media/<user> in the filename field, because the /media directory itself is not actually readable
[13:11] <Son_Goku> morphis: you need to fix snapd.system-shutdown.service too
[13:13] <Son_Goku> mvo: hey, you there?
[13:13] <morphis> Son_Goku: you mean adding template vars to it?
[13:13] <Son_Goku> morphis: yep
[13:14] <morphis> Son_Goku: it's not going to be used on any classic system, that is why I skipped it
[13:14] <Son_Goku> if you're going to do this, do it right :)
[13:14] <Son_Goku> you never know
[13:15] <morphis> and if you don't want people to use it another way than what it is supposed for then enforcement is better
[13:16] <morphis> AFAIK we don't test it anywhere else and therefor shouldn't ship it as an option
[13:16] <morphis> but leave this up to mvo and zyga
[13:16] <Son_Goku> your makefile already installs it
[13:16] <ogra_> 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] <Son_Goku> morphis, and it's better to not presume that you guys will be the only "Snappy" system producers
[13:17] <davmor2> ogra_: hahahahaha
[13:17] <Son_Goku> 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] <ogra_> Son_Goku, we''ll just trademark it :P
[13:18] <Son_Goku> ogra_: you already did :/
[13:18] <morphis> Son_Goku: but you mean by "snappy" system? that word is already too overloaded :-)
[13:18] <ogra_> clever us ;)
[13:18] <Son_Goku> morphis: I mean that a system is composed as a snap-centric system like Ubuntu Core
[13:18] <Son_Goku> except not being Ubuntu based
[13:18] <ogra_> morphis, yeah, we should trademark "core" :)
[13:18] <Son_Goku> ogra_: too generic :)
[13:18] <morphis> :-)
[13:19] <zyga> coreOS ;-)
[13:19] <Son_Goku> Canonical holds trademarks for "Ubuntu Core" and "Ubuntu Snappy Core",  think
[13:19] <ogra_> yeah
[13:19] <ogra_> to specific :P
[13:19] <Son_Goku> but if I want to make "Fedora Snappy Core", it's not particularly difficult
[13:19] <morphis> zyga, mvo: its your call on templating for snapd.system-shutdown.service or not
[13:19] <davmor2> ogra_: I think the gym guys beat you too it and intel and ..... well you know the list goes on
[13:19] <zyga> Son_Goku: fedora core, like ubuntu core, mozilla ;-)
[13:19] <zyga> Son_Goku: make it an user-agent problem
[13:19] <Son_Goku> well, Fedora Core was a thing :)
[13:20] <ogra_> ubuntu core was a thing since 6 years or so
[13:20] <ogra_> but not the core you are looking for :)
[13:20] <Son_Goku> ogra_: Fedora Core was the original name of the Fedora distribution :)
[13:20] <Son_Goku> when Red Hat Linux was merged into the Fedora Project, "Fedora Core" represented the RHL bits
[13:21] <Son_Goku> that name is still trademarked by Red Hat
[13:25] <morphis> Son_Goku: btw. do you have packages for snapd-glib somewhere too?
[13:25] <Son_Goku> in Fedora dist-git
[13:25] <Son_Goku> that builds fine and can be upgraded
[13:25] <Son_Goku> it just can't be installed because snapd isn't available
[13:25] <Son_Goku> zyga is the maintainer of snapd-glib, you'll need to request comaint privs on pkgdb
[13:29] <morphis> Son_Goku: ok, let me do that
[13:29] <morphis> Son_Goku: still waiting for the golang-* packages to be added to pkgdb here .
[13:30] <Son_Goku> morphis: poking people in #fedora-admin might be appropriate then
[13:30] <morphis> Son_Goku: sounds like a good idea
[13:33] <morphis> Son_Goku, zyga: ok also requested admin access for snapd / snapd-glib
[13:36] <Son_Goku> 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] <morphis> Son_Goku: aye
[13:37] <morphis> Son_Goku: thanks
[13:37] <morphis> zyga: ok, https://github.com/morphis/snapd/commit/26a1a4b695d608596c76ee84ee00e9ecf4188267 solves the xqm.h problem but it looks a bit clumpy
[13:38] <zyga> looking
[13:39] <zyga> morphis: you can alternatively use a custom checker and just #define the right stuff inside
[13:39] <zyga> morphis: no need to touch CFLAGS
[13:39] <morphis> zyga: no that doesn't work
[13:39] <morphis> I tried it
[13:40] <morphis> but can't explain yet why ..
[13:41] <morphis> zyga: https://paste.ubuntu.com/24267906/
[13:43] <zyga> morphis: no idea, autotools magic
[13:43] <morphis> let me try one thing ..
[13:44] <morphis> actually that paste is wrong one .. but anyway
[13:48] <cyphermox> mvo: ta, this will really help
[13:50] <mup> PR snapd#3094 opened: cmd: rework header check for xfs/xqm.h <Created by morphis> <https://github.com/snapcore/snapd/pull/3094>
[13:50] <morphis> zyga: ^^
[13:54] <zyga> morphis: checking
[14:10] <steve_fi> 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] <ptrtng> mardi: I've checked out your meshlab update: Fails. See https://pastebin.com/gafuPLAg for more info.
[14:41] <mup> PR snapd#3093 closed: cmd: discard the C implementation of snap-update-ns <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3093>
[14:43] <NicolinoCuralli> hi all is it possibile to bind udp/67 port in strict mode?
[14:51] <mup> PR snapd#3095 opened: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
[15:17] <kyrofa> 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] <jdstrand> 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] <kyrofa> jdstrand, alright, I may be pinging you about that in a bit, then
[15:20] <jdstrand> kyrofa: if it doesn't work, I can issue a snap decl if needed, but please file a bug in that case
[15:20] <kyrofa> Sounds good
[15:20] <kyrofa> Yeah this has been a good exercise
[15:20] <jdstrand> I don't have the specifics on gadgets and autoconnection. I think morphis has done a few though
[15:26] <morphis> jdstrand, kyrofa: AFAIK this isn't possible today
[15:28] <kyrofa> morphis, alright, thank you
[15:29] <morphis> kyrofa: according to what I've heard from pedronis this should be possible in some way later
[15:34] <morphis> kyrofa: btw. I've started to use the nextcloud snap recently and have it now in a production environment, awesome work :-)
[15:35] <kyrofa> morphis, why thank you!
[15:35] <morphis> kyrofa: I really liked how it did everything for me including the lets-encrypt setup
[15:35] <morphis> magic :-)
[15:36] <kyrofa> morphis, yeah that took some time to work out, heh
[15:36] <morphis> 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] <morphis> s/no because/now because/
[15:37] <kyrofa> Yeah it was always painful to maintain for me, too
[15:37] <morphis> but having something coming officially from nextcloud is quite nice and is enough for my trust level :-)
[15:37] <morphis> yeah
[15:37] <morphis> 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] <kyrofa> Haha, "we support 12.04 too!"
[15:38] <morphis> :-D
[15:38] <morphis> kyrofa: I always only believe those things when I see and feel it them
[15:39] <kyrofa> morphis, the only weirdness with the snap is that automatically updating will sometimes disable your apps
[15:40] <kyrofa> morphis, keep that in mind, if they disappear, just re-enable them, you didn't lose anything
[15:40] <kyrofa> morphis, they're working on fixing that in nextcloud itself, sounds like
[15:43] <morphis> kyrofa: yeah .. had this with the regular install too
[15:44] <morphis> always had my dad crying his calendar and contacts disappeared :-)
[15:45] <kyrofa> Yeah... annoying
[15:50] <morphis> kyrofa: but good to know they are fixing this at the root of the whole thing
[15:55] <mup> PR snapcraft#1224 opened: tests: fix name registration window limit test to latest changes  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1224>
[16:18] <kyrofa> barry, in case you didn't notice, snapcraft v2.28 is in -updates
[16:22] <barry> 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] <barry> kyrofa: conveniently, it's lunch time :)
[16:23] <kyrofa> barry, hmm... indeed, I may have lied
[16:27] <kyrofa> 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] <mup> PR snapd#3096 opened: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096>
[16:36] <cachio> jdstrand, hey
[16:37] <cachio> 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] <cachio> jdstrand, tyhicks in case the confinement is strict the overhead is aroud 15 to 20 %
[16:40] <tyhicks> cachio: when you say "when the confinement is not strict", are you referring to devmode, classic, or both of those confinement modes?
[16:41] <cachio> devmode
[16:41] <tyhicks> interesting
[16:41] <cachio> tyhicks, I used to install it with --devmode
[16:42] <cachio> then I removed that and I started getting results with 15-20$ of overhead
[16:42] <tyhicks> cachio: to make sure I understand, the dbus mediation with strict confinement mode is within our expected range (15-20%)
[16:42] <cachio> tyhicks, yes
[16:42] <cachio> agree
[16:42] <tyhicks> cachio: the dbus mediation with devmode confinement mode sometimes exceeds our expected range (> 25%)
[16:42] <tyhicks> ok
[16:42] <tyhicks> that could be really helpful when reviewing the code
[16:43] <cachio> tyhicks, it is about 35% with devmod confinment
[16:46] <tyhicks> cachio, jdstrand: this is starting to feel like an auditing overhead to me
[16:47] <tyhicks> cachio: are audit messages being sent to /var/log/syslog for every message you send?
[16:48] <tyhicks> cachio: you'll have a ton of apparmor="ALLOWED" messages if that's the case
[16:48] <cachio> tyhicks, let me see
[16:52] <cachio> tyhicks, well there are many entries for dbus in syslog
[16:52] <cachio> tyhicks, but not sure if there are so many to cause that
[16:52] <tyhicks> cachio: is there one that looks to repeat a lot?
[16:52] <tyhicks> cachio: if so, please paste it
[16:53] <cachio> tyhicks, this one http://paste.ubuntu.com/24268835/
[16:54] <tyhicks> cachio: ok, that is definitely coming from dbus-daemon
[16:55] <tyhicks> the in-code overhead for a devmode snap talking on dbus is two calls to this function: http://paste.ubuntu.com/24268842/
[16:56] <tyhicks> 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] <cachio> tyhicks, something that also could help you is that I am also plugging the mount-observe interface
[17:00] <cachio> tyhicks, could that affect in the results?
[17:00] <Pharaoh_Atem> mvo: would it be possible to split the vendoring for snapd into an overlay tarball?
[17:00] <Pharaoh_Atem> that is, a tarball that is overlaid on top of an unvendored snapd tarball
[17:01] <tyhicks> cachio: I don't think so
[17:04] <barry> kyrofa: cool.  if it's verification-done, it'll show up soon enough
[17:11] <kyrofa> ogra_, I just noticed that the Dragonboard gadget has architectures: [armhf]
[17:11] <kyrofa> ogra_, shouldn't that be arm64?
[17:12] <zyga> jdstrand: hey
[17:14] <jdstrand> zyga: hey
[17:14] <zyga> 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] <mup> PR snapd#3091: interfaces/seccomp: add bind to default seccomp template for hooks <Created by morphis> <https://github.com/snapcore/snapd/pull/3091>
[17:15] <jdstrand> zyga: I plan to
[17:15] <zyga> jdstrand: it's a workaround for golang doing "bind" and snapctl
[17:15] <jdstrand> I read it. I'm thinking about my response
[17:15] <sergiusens> barry: kyrofa I haven't pulled the trigger yet on releasing to -updates
[17:15] <zyga> 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] <barry> sergiusens: what's the hold up?
[17:17] <jdstrand> cachio: curious-- are you connecting the interface when in strict mode and not connecting the interface in devmode?
[17:17] <jdstrand> tyhicks: ^
[17:18] <Pharaoh_Atem> zyga: did you have a chance to talk to mvo about overlay tarballs?
[17:18] <jdstrand> people sometimes forget to connect their interfaces in devmode...
[17:18] <zyga> Pharaoh_Atem: no, because there was no release plan decision until today
[17:18] <zyga> Pharaoh_Atem: I'll ask
[17:18] <Pharaoh_Atem> zyga: cool
[17:18] <zyga> mvo: Pharaoh_Atem had an idea that we could release vanilla git tree + the vendor/ directory separately as that would ease packaging
[17:18] <zyga> Pharaoh_Atem: for vendorized builds we would consume both tarballs
[17:19] <zyga> Pharaoh_Atem: and for de-vendorized builds just one
[17:19] <zyga> Pharaoh_Atem: it shouldn't be be harder than what we do now (vendorized)
[17:19] <zyga> er
[17:19] <zyga> mvo: ^^
[17:19]  * zyga is tired
[17:19] <Pharaoh_Atem> it would make it much less painful for supporting EL7 builds along with Fedora builds
[17:19] <zyga> mvo: and once we have a script for making this should be essentially free
[17:20]  * zyga needs to walk again
[17:20] <zyga> (offline)
[17:22] <kyrofa> jdstrand, could you take a look at the dragonboard-turtlebot-kyrofa gadget when you're able, please?
[17:22] <kyrofa> Same thing as the amd64 gadget (serial-port workaround)
[17:25] <cachio> jdstrand, I am connecting in both
[17:25] <cachio> jdstrand, it is the same execution
[17:25] <cachio> jdstrand, the diff is the when I install
[17:26] <jdstrand> kyrofa: done
[17:27] <jdstrand> 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] <kyrofa> jdstrand, thank you!
[17:27] <jdstrand> (you see a difference)
[17:28] <jdstrand> 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] <kyrofa> jdstrand, indeed I've already experienced the pc passing, thank you :)
[17:37] <cachio> jdstrand, I install, then I connect and then I run the tests
[17:38] <cachio> jdstrand, that for strict and devmode
[17:38] <cachio> jdstrand, all the steps are equal, but hte install
[17:38] <cachio> jdstrand, the diff I see is when I run the tests
[17:38] <cachio> it is once the whole snap setup is done
[17:39] <jdstrand> ok
[17:39] <jdstrand> tyhicks: ^ (you probably figured all that out already...)
[18:08] <mup> PR snapd#3091 closed: interfaces/seccomp: add bind to default seccomp template for hooks <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3091>
[18:29] <kyrofa> Hey barry, I just hit an interesting python problem if you have a sec
[18:29] <barry> kyrofa: i do
[18:30] <kyrofa> I have a plugin that ends up pulling two dependencies, one of which is python2, the other is python3
[18:31] <kyrofa> barry, which means that I have two different python installs essentially contained in my part directory
[18:31] <kyrofa> 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] <barry> 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] <kyrofa> 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] <barry> kyrofa: hmm
[18:33] <kyrofa> Nasty
[18:33] <barry> yep :)
[18:34] <barry> too bad you can't just port the py2 bits to py3 :)
[18:34] <kyrofa> 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] <barry> kyrofa: can you arrange for a module to get imported early in the build process?
[18:34] <kyrofa> barry, the build process is actually cmake. You would cry if you saw this
[18:35] <barry> because that module could test for the python version and then hack sys.path accordingly
[18:35] <barry> kyrofa: i'm tearing up just thinking about it ;)
[18:36] <kyrofa> barry, alright, thanks for the insight! I'll mull this over
[18:36] <barry> kyrofa: okay, good luck!
[18:37] <anorgrull> hi, trying to install snapd on a raspberry pi 3 running raspbian. Any shortcut from installing go and building from sources ?
[18:37] <kyrofa> anorgrull, I don't believe raspbian includes the necessary appamor kernel patches
[18:38] <kyrofa> 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] <zyga> anorgrull: hey
[18:41] <zyga> anorgrull: hmm, raspbian is based on which version of debian now?
[18:41] <zyga> anorgrull: you may be able to just get it
[18:41] <kyrofa> barry, I suppose PYTHONPATH will still be needed even if I use .pth files?
[18:41] <zyga> anorgrull: in any case you can build snapd from source
[18:41] <anorgrull> maybe recompiling kernel to add it seem possible, an other route is to swich to ubuntu
[18:41] <zyga> anorgrull: I'd love to know how that feels like
[18:42] <zyga> anorgrull: a while ago I wrote this: https://new.zygoon.pl/post/case-study-snapd-on-centos/
[18:42] <zyga> anorgrull: it's a centos build but the main idea holds
[18:42] <barry> kyrofa: ah, that's a good (as in evil :) hack.  if the .pth is on the normal import path you won't, but if you need to put that in a non-standard place, you will.  you can do a lot with .pth files (for better or worse ;)
[18:44] <kyrofa> barry, I seem to remember that python checks in ~/.local somewhere by default as well as the system-wide location?
[18:47] <barry> kyrofa: there are differences depending on whether you're running it interactively or not, but you can always find out definitively with `python3 -c "import sys; print(sys.path)"
[18:48] <kyrofa> barry, wait... since the part owns the python in question I can create wrappers/aliases that set the right environment. Disgusting, but the best option yet I think
[18:48] <kyrofa> It also owns the PATH, so I can make sure those are called
[18:50] <barry> kyrofa: that's definitely the better way to go.  i've done $PATH hacking in my snapcraft.yaml (originally also needing to hack $PYTHONPATH but then found i didn't need it).  i'm not sure if the environment section can apply to a single part or to the whole thing (don't remember, didn't affect u-i)
[18:51] <kyrofa> Good deal
[18:59] <sergiusens> is this "ask barry"? If so, I have a question -> https://bugs.launchpad.net/snapcraft/+bug/1675479
[18:59] <mup> Bug #1675479: python plugin doesn't work for namespace packages <openstack> <plugin> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1675479>
[18:59] <kyrofa> Hahaha
[18:59] <sergiusens> we use pure upstream pip, setuptools and wheels... any weird thing you can think of?
[19:00] <barry> python story time with the flufl
[19:00] <sergiusens> the fix mentioned in there involved driving the install with setup.py instead of pip btw (in case you have better ideas)
[19:02] <barry> sergiusens: that's odd because 2.7 doesn't have pep 420 style namespace packages.  it has a hacky thing but still requires __init__.pys
[19:02] <barry> or it *can* have a hacky thing if the top-level package puts stuff in __init__.py
[19:03] <barry> the paste deploy pastebin doesn't seem related to that because it's a top level package
[19:03] <mup> PR snapd#3097 opened: interfaces/seccomp: add bind as part of the default seccomp policy (backport) <Created by zyga> <https://github.com/snapcore/snapd/pull/3097>
[19:04] <barry> ah, nspkg.pth files.  yeah those are magical and problematic
[19:05] <Pharaoh_Atem> zyga: so morphis' golang packages have been approved
[19:05] <mup> PR core#30 opened: Update core snap cloud-init configuration <Created by raharper> <https://github.com/snapcore/core/pull/30>
[19:05] <Pharaoh_Atem> they are awaiting his import of the packages
[19:06] <Pharaoh_Atem> he should make sure that golang-sig and you are comaintainers of the golang packages
[19:06] <Pharaoh_Atem> zyga: and you should also grant golang-sig similar privileges for your golang-* packages
[19:06] <Pharaoh_Atem> only commit privileges, not approveacls and such
[19:08] <sergiusens> barry: any clues on how to circumvent this or have the interpreter read these?
[19:08] <kyrofa> jdstrand, alright, I've got two gadgets that both provide a `kobuki` serial-port slot, and one snap that has a `kobuki` serial-port plug. I'd like to get that snap to autoconnect to both gadgets
[19:08] <kyrofa> jdstrand, how do I go about this?
[19:08] <sergiusens> barry: but bottom line is packages added with .pth don't need __init__.py ?
[19:08] <sergiusens> did I read that correctly?
[19:09] <jdstrand> kyrofa: give me all the snap names and I'll do a snap declaration for them. please file a bug that you cannot do this with the gadget since that is the design
[19:10] <kyrofa> jdstrand, will do. The app snap's name is turtlebot-demo-kyrofa
[19:10] <kyrofa> jdstrand, the gadgets are pc-turtlebot-kyrofa and dragonboard-turtlebot-kyrofa
[19:11] <barry> sergiusens: i believe that's the case, although it's dependent on a properly written .pth file.  i believe the standard ones hack the top-level module object's __path__ to include the path to the sub-package, which python's import machinery uses to find subpackages
[19:11] <zyga> Pharaoh_Atem: sounds good, I will look into it
[19:12] <barry> (it's kind of a trick for them to do that level of __path__ hackery)
[19:13] <jdstrand> kyrofa: I've got several things I'm working on but will ping you when I add it
[19:13] <kyrofa> jdstrand, no rush, this week will make me happy
[19:13] <barry> sergiusens: it's all keyed off of sys.prefix and sys.exec_prefix.  i'm not sure what snapped python's do to those variables
[19:17] <sergiusens> barry: nothing really to sys.prefix and sys.exec_prefix, we just rely on the interpreter figuring it out relative to its exec path
[19:17] <barry> sergiusens: in that case it *should* find .pth files relative to those paths
[19:17] <sergiusens> but now that you mention no __init__ I'll look into running coreycb's full example and see how it goes
[19:18] <barry> sergiusens: cool.  let me know how it goes
[19:20]  * zyga EODs
[19:20] <zyga> Pharaoh_Atem: I'll work on golang-sig ACLs first thing tomorrow
[19:20] <Pharaoh_Atem> okay
tanks for the tuto, but i'm stuck on getting some dependencies header's, will try ubuntu mate 16
[19:21] <zyga> anorgrull: good luck,
[19:24] <mup> PR snapd#3098 opened: cmd: Select what socket to use in cmd/snap{,ctl} <Created by mvo5> <https://github.com/snapcore/snapd/pull/3098>
[20:04] <mwhudson> ahem
[20:04] <mwhudson> $ snap info snapcraft | grep ^summary
[20:04] <mwhudson> summary:   "Single-line elevator pitch for your amazing snap"
[20:04] <kyrofa> Hahaha
[20:05] <kyrofa> You can tell it's not done yet
[20:06] <mwhudson> there is a certain irony here :)
[20:06] <mwhudson> kyrofa: will launchpad use snapcraft 2.28 yet or only once it hits xenial-updates?
[20:06] <kyrofa> mwhudson, depends on the pocket you use
[20:07] <kyrofa> mwhudson, if updates, then yeah
[20:07] <mwhudson> oh right
[20:07] <kyrofa> mwhudson, you can of course use proposed
[20:07] <kyrofa> mwhudson, but then everything comes from proposed
[20:07] <mwhudson> yeah, that's ok for me i think
[20:08] <mwhudson> i guess i could also copy 2.28 into a ppa and depend on that
[20:08] <kyrofa> Indeed, though that sounds annoying
[20:08]  * mwhudson shrugs
[20:27] <jdstrand> pmcgowan: the ubuntu-app-platform issue should be resolved
[20:27] <pmcgowan> jdstrand, great thanks, what was it
[20:28] <jdstrand> pmcgowan: the review tools were correct. needed to tweak the snap decl slightly
[20:28] <pmcgowan> I guess thats good
[20:29] <pmcgowan> let me try to republish
[20:29] <jdstrand> pmcgowan: hold on
[20:29] <jdstrand> pmcgowan: let me just rerun the checks
[20:29] <pmcgowan> holding
[20:30] <jdstrand> pmcgowan: actually can you request a manual review in https://myapps.developer.ubuntu.com/dev/click-apps/6271/rev/42/ and https://myapps.developer.ubuntu.com/dev/click-apps/6271/rev/43/
[20:32] <pmcgowan> jdstrand, 2 reviews requested
[20:32] <jdstrand> ok, I triggered the autoreview
[20:33] <jdstrand> pmcgowan: ok, armhf passed. running the autoreview for arm64
[20:34] <pmcgowan> great
[20:35] <jdstrand> pmcgowan: arm64 passed. feel free to release like normal
[20:36] <jdstrand> pmcgowan: fyi, I added a task to a card to add a simple verification tool to the review tools so this doesn't happen again
[20:36] <jdstrand> (to verify the snap decl)
[20:36] <pmcgowan> ok
[20:36] <pmcgowan> thanks
[20:37] <jdstrand> the store itself only does rudimentary checks. perhaps it could be made to use this tool when its written
[20:44] <kyrofa> Haha, eject has a security update? I must read this...
[20:45] <kyrofa> Dang
[21:19] <mup> PR snapd#3074 closed: configstate,hookstate: limit runtime of the configure hook to 5 minutes <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3074>