| 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> | 00:58 |
| 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:09 |
| mwhudson | cyphermox: fair enough | 01:12 |
| 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 | 01:14 |
| mup | PR snapcraft#1222 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1222> | 03:03 |
| mup | PR snapcraft#1222 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1222> | 04:21 |
| mup | PR snapd#3089 opened: interfaces: drop udev tagging from framebuffer interface <Created by chunsangjeong> <https://github.com/snapcore/snapd/pull/3089> | 06:12 |
| 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:40 |
| didrocks | ubuntu-make classic snap is still not published on amd64 (but acked on all other archs) since yesterday. Is that an oversight? | 06:46 |
| 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:47 |
| 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> | 06:48 |
| 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> | 07:26 |
| mardy | pstolowski: hi! I'll address the chanegs requested by Jamie -- thanks for your other updates! | 08:17 |
| 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:20 |
| pstolowski | mardy, cool, yw! | 08:26 |
| 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:31 |
| 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:36 |
| ogra_ | ptrtng, did you try using the removable-media interface ? | 08:46 |
| ogra_ | (assuming your partition mounts under /media this should be accessible) | 08:47 |
| 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:49 |
| 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:50 |
| 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:54 |
| 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:55 |
| === vigo_ is now known as vigo | ||
| ogra_ | ppisati, should bluetooth work on the pi3 ? did you ever test that ? | 08:58 |
| 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 | 08:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| chani | i have one more issue though | 09:04 |
| ptrtng | the snap in question is: openmvs 0.7.0-2a41453-0 2 | 09:05 |
| ptrtng | sorry I was wrong the app is: mve 20170210-0 1 mardy. | 09:06 |
| 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:07 |
| ptrtng | From the same people. I'll contact them by myself. Thanks for the help | 09:08 |
| 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:09 |
| 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:10 |
| 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:12 |
| 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:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| === ycheng is now known as ycheng-afk | ||
| chani | where can i get the details of this implementation. just out of curiosity :P | 09:18 |
| chani | is it in the whitepapers | 09:19 |
| ogra_ | i think there is some of it, yeah ... under FHS | 09:20 |
| ogra_ | and in "Snap security policy" too | 09:20 |
| 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:24 |
| mardy | ptrtng: try "snap refresh" | 09:37 |
| mup | PR snapd#3092 opened: interfaces: capitalize Udev... as UDev <Created by zyga> <https://github.com/snapcore/snapd/pull/3092> | 09:38 |
| mup | PR snapcraft#1223 opened: kernel plugin: check_config() and check_initrd() support <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1223> | 09:49 |
| 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:06 |
| koza | ogra_, hey, reading | 10:14 |
| koza | unity | 10:15 |
| 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? | 10:25 |
| === hikiko is now known as hikiko|bbl | ||
| 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:22 |
| === hikiko|bbl is now known as hikiko | ||
| 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? | 11:51 |
| 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:15 |
| 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:16 |
| 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:18 |
| 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:19 |
| ptrtng | mardy: I used 'meshlab-mardy 2016.12-20170302-2 4' | 12:20 |
| 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:21 |
| 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:24 |
| 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:33 |
| 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:45 |
| didrocks | jdstrand: yeah, I noticed that meanwhile, it was actually done, great! | 12:49 |
| zyga | jdstrand: thank you | 13:03 |
| morphis | zyga: ok, you're right, it is the missing largefile support: https://paste.ubuntu.com/24267713/ | 13:03 |
| 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:05 |
| 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:06 |
| morphis | Son_Goku: btw. if you have a min, I've updated the templating PR | 13:08 |
| mardy | ptrtng: done, please refresh meshlab | 13:09 |
| 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:10 |
| Son_Goku | morphis: you need to fix snapd.system-shutdown.service too | 13:11 |
| 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:13 |
| 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:14 |
| morphis | and if you don't want people to use it another way than what it is supposed for then enforcement is better | 13:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| Son_Goku | that name is still trademarked by Red Hat | 13:21 |
| 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:25 |
| 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:29 |
| Son_Goku | morphis: poking people in #fedora-admin might be appropriate then | 13:30 |
| morphis | Son_Goku: sounds like a good idea | 13:30 |
| morphis | Son_Goku, zyga: ok also requested admin access for snapd / snapd-glib | 13:33 |
| 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:36 |
| 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:37 |
| zyga | looking | 13:38 |
| 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:39 |
| morphis | but can't explain yet why .. | 13:40 |
| morphis | zyga: https://paste.ubuntu.com/24267906/ | 13:41 |
| zyga | morphis: no idea, autotools magic | 13:43 |
| morphis | let me try one thing .. | 13:43 |
| morphis | actually that paste is wrong one .. but anyway | 13:44 |
| cyphermox | mvo: ta, this will really help | 13:48 |
| 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:50 |
| zyga | morphis: checking | 13:54 |
| 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:10 |
| ptrtng | mardi: I've checked out your meshlab update: Fails. See https://pastebin.com/gafuPLAg for more info. | 14:17 |
| 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:41 |
| NicolinoCuralli | hi all is it possibile to bind udp/67 port in strict mode? | 14:43 |
| mup | PR snapd#3095 opened: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095> | 14:51 |
| 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:17 |
| 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:19 |
| 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:20 |
| morphis | jdstrand, kyrofa: AFAIK this isn't possible today | 15:26 |
| kyrofa | morphis, alright, thank you | 15:28 |
| morphis | kyrofa: according to what I've heard from pedronis this should be possible in some way later | 15:29 |
| morphis | kyrofa: btw. I've started to use the nextcloud snap recently and have it now in a production environment, awesome work :-) | 15:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| kyrofa | morphis, the only weirdness with the snap is that automatically updating will sometimes disable your apps | 15:39 |
| 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:40 |
| morphis | kyrofa: yeah .. had this with the regular install too | 15:43 |
| morphis | always had my dad crying his calendar and contacts disappeared :-) | 15:44 |
| kyrofa | Yeah... annoying | 15:45 |
| morphis | kyrofa: but good to know they are fixing this at the root of the whole thing | 15:50 |
| 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> | 15:55 |
| kyrofa | barry, in case you didn't notice, snapcraft v2.28 is in -updates | 16:18 |
| 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:22 |
| kyrofa | barry, hmm... indeed, I may have lied | 16:23 |
| 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:27 |
| mup | PR snapd#3096 opened: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096> | 16:30 |
| cachio | jdstrand, hey | 16:36 |
| 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:37 |
| cachio | jdstrand, tyhicks in case the confinement is strict the overhead is aroud 15 to 20 % | 16:38 |
| tyhicks | cachio: when you say "when the confinement is not strict", are you referring to devmode, classic, or both of those confinement modes? | 16:40 |
| cachio | devmode | 16:41 |
| tyhicks | interesting | 16:41 |
| cachio | tyhicks, I used to install it with --devmode | 16:41 |
| 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:42 |
| cachio | tyhicks, it is about 35% with devmod confinment | 16:43 |
| tyhicks | cachio, jdstrand: this is starting to feel like an auditing overhead to me | 16:46 |
| tyhicks | cachio: are audit messages being sent to /var/log/syslog for every message you send? | 16:47 |
| tyhicks | cachio: you'll have a ton of apparmor="ALLOWED" messages if that's the case | 16:48 |
| cachio | tyhicks, let me see | 16:48 |
| 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:52 |
| cachio | tyhicks, this one http://paste.ubuntu.com/24268835/ | 16:53 |
| tyhicks | cachio: ok, that is definitely coming from dbus-daemon | 16:54 |
| tyhicks | the in-code overhead for a devmode snap talking on dbus is two calls to this function: http://paste.ubuntu.com/24268842/ | 16:55 |
| 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 | 16:56 |
| 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:00 |
| tyhicks | cachio: I don't think so | 17:01 |
| barry | kyrofa: cool. if it's verification-done, it'll show up soon enough | 17:04 |
| kyrofa | ogra_, I just noticed that the Dragonboard gadget has architectures: [armhf] | 17:11 |
| kyrofa | ogra_, shouldn't that be arm64? | 17:11 |
| zyga | jdstrand: hey | 17:12 |
| 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:14 |
| 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:15 |
| barry | sergiusens: what's the hold up? | 17:16 |
| jdstrand | cachio: curious-- are you connecting the interface when in strict mode and not connecting the interface in devmode? | 17:17 |
| jdstrand | tyhicks: ^ | 17:17 |
| 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:18 |
| 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:19 |
| * zyga needs to walk again | 17:20 | |
| zyga | (offline) | 17:20 |
| 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:22 |
| 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:25 |
| jdstrand | kyrofa: done | 17:26 |
| 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:27 |
| 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:28 |
| cachio | jdstrand, I install, then I connect and then I run the tests | 17:37 |
| 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:38 |
| jdstrand | ok | 17:39 |
| jdstrand | tyhicks: ^ (you probably figured all that out already...) | 17:39 |
| 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:08 |
| kyrofa | Hey barry, I just hit an interesting python problem if you have a sec | 18:29 |
| barry | kyrofa: i do | 18:29 |
| kyrofa | I have a plugin that ends up pulling two dependencies, one of which is python2, the other is python3 | 18:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| kyrofa | barry, alright, thanks for the insight! I'll mull this over | 18:36 |
| barry | kyrofa: okay, good luck! | 18:36 |
| 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:37 |
| 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:38 |
| 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:41 |
| 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:42 |
| kyrofa | barry, I seem to remember that python checks in ~/.local somewhere by default as well as the system-wide location? | 18:44 |
| 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:47 |
| 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:48 |
| 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:50 |
| kyrofa | Good deal | 18:51 |
| === E-werd is now known as beckyblack | ||
| === beckyblack is now known as E-werd | ||
| === E-werd is now known as rebeccablack | ||
| === rebeccablack is now known as E-werd | ||
| 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? | 18:59 |
| 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:00 |
| 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:02 |
| 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:03 |
| barry | ah, nspkg.pth files. yeah those are magical and problematic | 19:04 |
| 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:05 |
| 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:06 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| barry | (it's kind of a trick for them to do that level of __path__ hackery) | 19:12 |
| 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:13 |
| 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:17 |
| barry | sergiusens: cool. let me know how it goes | 19:18 |
| * zyga EODs | 19:20 | |
| zyga | Pharaoh_Atem: I'll work on golang-sig ACLs first thing tomorrow | 19:20 |
| Pharaoh_Atem | okay | 19:20 |
| anorgrull | <zyga>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:21 |
| 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> | 19:24 |
| 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:04 |
| kyrofa | You can tell it's not done yet | 20:05 |
| 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:06 |
| 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:07 |
| 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:08 | |
| jdstrand | pmcgowan: the ubuntu-app-platform issue should be resolved | 20:27 |
| pmcgowan | jdstrand, great thanks, what was it | 20:27 |
| jdstrand | pmcgowan: the review tools were correct. needed to tweak the snap decl slightly | 20:28 |
| pmcgowan | I guess thats good | 20:28 |
| 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:29 |
| 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:30 |
| pmcgowan | jdstrand, 2 reviews requested | 20:32 |
| jdstrand | ok, I triggered the autoreview | 20:32 |
| jdstrand | pmcgowan: ok, armhf passed. running the autoreview for arm64 | 20:33 |
| pmcgowan | great | 20:34 |
| jdstrand | pmcgowan: arm64 passed. feel free to release like normal | 20:35 |
| 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:36 |
| jdstrand | the store itself only does rudimentary checks. perhaps it could be made to use this tool when its written | 20:37 |
| kyrofa | Haha, eject has a security update? I must read this... | 20:44 |
| kyrofa | Dang | 20:45 |
| 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> | 21:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!