/srv/irclogs.ubuntu.com/2016/05/31/#snappy.txt

=== chihchun_afk is now known as chihchun
=== vincent is now known as Guest97747
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
zygao/07:49
davidcalledidrocks: hey, can you have a quick look at https://github.com/ubuntu/snappy-playpen/pull/11 ? Thanks :)08:33
didrocksdavidcalle: can you expand a little bit what you are trying to fix?08:34
didrocksah, the Testing atom/parts/plugins08:35
didrocksbecause we have a custom plugin08:35
didrocksso subdir08:35
didrocksdavidcalle: I think that can be done maybe in an easier way (don't like the double xargs)08:36
davidcalledidrocks: sure, note that if you just strip the second dir, you end up with duplicates, that was the shorter diff I could come up with :)08:38
davidcalledidrocks: also, not sure if you have noticed, but travis is trying to apt-get an older rev of a package, hence, all runs are failing since a couple days. (https://travis-ci.org/ubuntu/snappy-playpen/builds/133371927#L544)08:40
didrocksdavidcalle: it's because I'm using sergiusens docker08:40
didrocksdavidcalle: let me set up ours + daily refresh08:40
didrocksdavidcalle: I'm playing with the regexp :)08:40
didrocksdavidcalle: got it in a way shorter, do you want me to setup a branch you can review (or pull or whatever)?08:42
davidcalledidrocks: I'm fine with your branch replacing this one08:43
=== chihchun_afk is now known as chihchun
didrocksdavidcalle: mind reviewing? https://github.com/ubuntu/snappy-playpen/pull/1408:49
davidcalledidrocks: hah, wfm :)08:52
didrocksdavidcalle: we should specialized those changes in ci-run btw :)08:53
davidcalledidrocks: although... look at the ci-run :D08:53
didrocksdavidcalle: yeah, it tries to run on the top_dir08:53
didrockswhich was already the case08:53
didrocksLet me try to special-case this08:53
davidcalledidrocks: nope, yours considers the ci-run file as a folder08:54
didrocksdavidcalle: yeah, because it doesn't care of file type08:54
didrockswe can just say "if file type == file" -> change is in the root dir08:54
didrocksI guess that's the best fix for other files in root08:55
didrocksdavidcalle: refresh (see second commit)08:57
davidcalledidrocks: ty :)08:59
didrocksdavidcalle: thanks for spotting it!09:00
didrocksdavidcalle: so, I guess having our own docker image refreshed daily makes sense, right?09:01
davidcalledidrocks: sounds like a good solution, yes09:02
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
didrocksdavidcalle: ok, master have most of the tests passing with my image (which is daily built)09:30
didrocksdavidcalle: however, unsure who did merge ffmepg, but it seems to fail09:30
didrocksdavidcalle: I'll push the docker image change first, then, we can iterate to get other fixed09:31
davidcallepopey: ^09:42
davidcalleThanks didrocks09:42
popeyeh?09:45
popeyI did ffmpeg as a standalone snap.09:46
popeydavidcalle merged them09:46
davidcallepopey: was just a heads up in case you had a fix. didrocks, do you have a log for ffmpeg? The original pr was fine afair.09:48
popeymy snap worked fine, what did you do? :)09:50
didrocksdavidcalle: I did a local ci-run09:51
didrocksit seems snapcraft can't find the ffmepg command (which is in bin/ffmepg)09:51
didrocksnote that this can be an upstream issue with latest snapcraft :)09:51
didrockspopey: davidcalle: I did request cron enablement as well on Travis to build master regularly (the API token method don't work, despite saying success)09:54
davidcalleok09:55
valletteahello, I new to snappy and would like to know how can I monitor the the size of the update of my snap. I run a lot of sensors over 3G and the amount of data transfered is really important in my case10:51
=== vejmarie_ is now known as vejmarie
=== JanC is now known as Guest93383
=== JanC_ is now known as JanC
hathor008can anyone shed some insights on this? would be greatly appreciated :) http://gamedev.stackexchange.com/questions/122197/how-do-i-create-an-ubuntu-snap-for-a-monogame-application12:40
sborovkovHello. Are config interfaces back or still not?12:42
ogra_not yet12:42
sborovkovogra_: is there some issue on launchpad for that? I did not find one :-(12:44
didrockssborovkov: you're right, there is none: please file one https://bugs.launchpad.net/ubuntu/+source/snapd12:46
sborovkovUnderstood, thanks.12:48
didrockshathor008: the issue is in your snapcraft.yaml12:48
didrocksyou have:12:48
didrocksfiles:12:48
didrocks    "*":12:48
didrocksyou need:12:49
didrocksfiles:12:49
didrocks    "*": '.'12:49
didrockshathor008: but please, file a bug against https://bugs.launchpad.net/ubuntu/+source/snapcraft as the error message isn't obvious12:49
hathor008lol that's all it is? i figured it was something simple like that12:49
hathor008ok no problem12:49
didrockshathor008: please copy your invalid snapcraft.yaml and mention "copy plugin" :)12:50
didrocksbut yeah, that's all ;)12:50
* didrocks still thinks that the copy plugin shouldn't require a files: parameter for such cases "copy all"12:50
mhall119hey guys,is there any known issue with running an OpenGL-using snap on proprietary graphics drivers?12:55
mhall119someone trying to run a Krita snap on proprietary nvidia is gettign this: http://pastebin.com/WsUfEj8J12:56
mhall119sergiusens: kyrofa: ^^ any help?13:00
zygatyhicks: hey13:03
noizerHi got a little problem with my snappy. is the tmp of the installation limited? error: cannot copy request into temporary file: write /tmp/snapd-sideload-pkg-130544461: no space left on device13:06
hathor008thanks for your help, didrocks. i really appreciate it :)13:08
didrockshathor008: yw! :)13:08
sborovkovHello. What's the current status of syslog on snappy? Is there some interface so that snap can configure it? Or how would I go about it when I need to configure it remotely?13:09
didrockssborovkov: you have a log-observe interface, maybe give it a shot? (I don't think there anything for configuring it remotely yet)13:11
jdstrandtyhicks, sergiusens, sborovkov: hey, fyi, in my experience access to /proc/<pid>/mounts is almost always non-fatal (unless you are a disk usage analyzer or something). this constitutes a potential information leak, which is why it is not in the default profile (and in mount-observe)13:12
jdstrandsergiusens, sborovkov: fyi, tyhicks and I have been giving some thought to silencing logging of noisy denials13:14
sborovkovdidrocks: thanks13:15
sborovkovjdstrand: is there a way to know what denial would be fatal?13:15
jdstrandsergiusens, sborovkov: we can do that now with an explicit deny of course, but that doesn't always work the way you want13:15
sborovkovjdstrand: since in the same log I had ldconfig run... I have no idea why, and don't know if it's fatal as well13:15
jdstrandsborovkov: run it in strict mode and see if your program runs ok13:15
sborovkovjdstrand: my program accesses /dev/vchiq as well, so it does not work in strict :-)13:17
mhall119jdstrand: davidcalle is helping me debug the krita snap with snappy-debug.security scanlog, but he gets this: http://paste.ubuntu.com/16863706/13:17
davidcalleInstalling snappy-debug with --devmode helped http://paste.ubuntu.com/16863781/13:18
didrocksmhall119: jdstrand: confirmed, everytime an exception is raised, getting the stacktrace as well13:20
noizerwhat can I do with a snap thats not fits in the temporary dir while installing?13:29
zyganoizer: hmm?13:30
zyganoizer: how big is it?13:30
zyganoizer: report a bug first please13:30
zyganoizer: is your /tmp a tmpfs?13:30
noizerzyga: its my /tmp13:31
noizerzyga 250mb13:32
noizerzyga ps how can i manually make a snap?13:32
noizerzyga its for my armel build13:33
ogra_and your HDD doesnt have 250MB free ?13:33
ogra_(in /tmp)13:33
zyganoizer: just use mksquashfs13:33
jdstrandsborovkov: add '/dev/vchiq rw,' to /var/lib/snapd/apparmor/profiles/snap.your.app, then do 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.app13:33
ogra_uh13:33
ogra_no13:33
ogra_use "snapcraft snap $dir"13:34
zygaogra_: that's less manual but non the less true :)13:34
ogra_(to make sure the proper options are used for mksquashfs)13:34
ogra_:)13:34
jdstrandsborovkov: that will allow that access and let you see if the other ones are ok. I know you have a bug open on /dev/vchiq and that zyga gave comments on how the interface can move forward13:34
noizerzyga ogra_ http://paste.ubuntu.com/16864020/13:35
noizerhere you can see my diskspace13:35
jdstrandmhall119: that is the same error that we discussed last week. I submitted a PR to the log-observe interface and it was committed. it will be in the next snapd release13:36
ogra_noizer, well, /tmp is a tmpfs ... so buy more ram or change that to use the disk instead13:36
noizerheh its my raspi13:36
mhall119jdstrand: yup, for now he's got snappy-debug working in devmode13:36
ogra_oh, you are *on* snappy13:36
mhall119which revealed a syscall to 'bind' that was blocked13:36
jdstrandmhall119: let me find the commit and I can give you a workaround. yes, --devmode will work ok. when snapd 2.0.6 is out, it shouldn't be needed13:36
noizerogra_:  yes ofc13:36
mhall119so running krita in --devmode gets it working for davidcalle13:37
ogra_hmm13:37
mhall119but someone else is having issues with OpenGL still, and running krita in --devmode doesn't help him13:37
mhall119davidcalle is using open-source gpu drivers, and the other guy has proprietary nvidia13:37
jdstrandmhall119: 774d721b0d4935fcdcb1146b8e38396eca67c17f (for snappy-debug)13:37
jdstrandmhall119: opengl is a mvo/zyga thing (iirc)13:38
mhall119mvo: zyga: can you guys help me debug this: http://pastebin.com/WsUfEj8J13:38
ogra_noizer, thats a tricky one indeed13:38
jdstrandmhall119: don't forget the socketcall workaround on i386. whoever hit that traceback you pasted likely will need to add socketcall to /var/lib/snapd/seccomp/profiles/snap.krita....13:39
mhall119it's not a confinement issue, he's run krita in --devmode and it has the same error, and snappy-debug.security scanlog doesn't show anything before the krita launch fails13:39
mvomhall119: is that a nvidia (proprietary drive) system? or what HW do you use?13:39
ogra_noizer, and i guess worth a bug to tell snapd to use its own TMPDIR on disk ... as zyga said, file a bug13:39
mhall119jdstrand: he's on amd6413:39
jdstrandmhall119: not confinement> yes, I know, hence comment regarding mvo/zyga13:39
mhall119jdstrand: though I suspect that socketcall might be related to the bind denial that davidcalle sees13:39
mhall119mvo: proprietary driver, yes13:40
noizerogra_: Is there for now a workaround?13:40
jdstrandmhall119: re bind> maybe. might just need network-bind13:40
mvomhall119: do you happen to know what version?13:40
jdstrandsnappy-debug in devmode will help you decide13:40
mhall119jdstrand: yeah, but it's a digital painting program, I don't see why it would need that in the first place13:40
mhall119mvo: of what?13:40
ogra_noizer, not that i know of ... ou could try remounting /tmp at runtime to disk manually but i guess that will break some bits that currently use the tmpfs /tmp13:40
jdstrandmhall119: it is surprising what apps not designed for confinement require13:41
mhall119mvo: let me get him in this channel, so I'm not passing messages around13:41
mvomhall119: is that a system you have direct access to? what is the output of "ls -ld /usr/lib/nvidia-*" ?13:41
jdstrandmhall119: it could also be a kde think. bind is needed for binding to the server side of a unix socket too13:42
jdstrandthinkg*13:42
jdstranderr13:42
jdstrandthing*13:42
mhall119mvo: I don't, which is why I'm trying to get him to join in here13:42
jdstrandmhall119: kde has this whole ipc infrastructure which I predict it going to be challenging13:42
mvomhall119: or tell me where he is and I join there, either way is fine13:42
mhall119jdstrand: hmmm, maybe. I can add network-bind to see if that allows davidcalle to run without --devmode13:42
mhall119mvo: he's in #krita13:43
kyrofamhall119, do you know what computer he has?13:43
mhall119nick is  mattiasw13:43
mhall119kyrofa: only that it's amd64 and proprietary nvidia driver13:43
kyrofaOkay13:43
kyrofazyga, do you know anything about https://askubuntu.com/questions/779875/cant-download-the-snap-packages ?13:45
didrockskyrofa: swift is down13:47
didrocksimpacted CI and the store13:48
didrocksimpacting*13:48
didrocks(and hey!)13:48
kyrofadidrocks, oh. I guess that would do it! :P13:48
kyrofadidrocks, hey!13:48
kyrofadidrocks, that might also explain why my integration tests are having issues13:48
didrockskyrofa: not for your local test run though :p (j/k)13:49
noizerogra_: What is the difference between meta/snap.yaml and snapcraft.yaml13:50
kyrofanoizer, meta/snap.yaml is what snapd itself requires inside the snap itself13:54
kyrofanoizer, snapcraft.yaml is the "recipe" you give to snapcraft that tells it how to put the snap in question together, and it creates the meta/snap.yaml for you13:55
ogra_noizer, what kyrofa said :)13:56
zygakyrofa: looking13:57
kyrofaSorry zyga, didrocks informed me that it was likely a temporary store issue13:57
noizerhmmm ok but I can't snap my snap with snapcraft. So told me a few days earlier too snap it manualy but ... I don't understand it anymore13:59
zygakyrofa: I also replied: http://askubuntu.com/questions/779875/cant-download-the-snap-packages/779917#77991714:00
kyrofazyga, ah, good idea14:00
=== chihchun is now known as chihchun_afk
mterrytedg, looking at the unity8 lifecycle thread -- it's not just saving state, but also having apps that understand they will be frozen when not focused.  So apps need to use the correct Touch apis to do background stuff, etc.14:09
popeymhall119: do you know why the icon shows as a piece of paper for krita?14:11
popeyI have made a snap and I wonder if perhaps the meta/gui/foo.png is no longer the right way to deliver an icon?14:11
mhall119it should be...it works for me anyway14:11
mhall119popey: is it in /snap/krita/current/meta/gui/ ?14:12
popeymhall119: yes14:13
mhall119what does the .desktop list for Icon?14:14
popeyIcon=${SNAP}/meta/gui/calligrakrita.png14:14
mhall119then it should be working...14:14
popey$ file /snap/krita/current/meta/gui/calligrakrita.png14:14
popey/snap/krita/current/meta/gui/calligrakrita.png: empty14:14
popeythat won't help14:14
popeyzero byte file14:15
mhall119empty?14:15
qenghozyga: howdy!14:15
* ogra_ hands popey a spare byte to add it to the file14:15
mhall119how the heck...14:15
popeywhat copies that file?14:15
mhall119davidcalle: can you $ file /snap/krita/current/meta/gui/calligrakrita.png14:15
zygaqengho: hey14:15
tedgmterry: Yes, I guess I see that as advanced usage. In that, they just need to know they're gonna be killed, if they want to work around that they can.14:15
mhall119popey: it's just in the setup/gui/ folder of the snapcraft directory14:15
popeysetup/gui, not meta/gui?14:16
mhall119yeah, that's the snapcraft folder, it installs to meta/gui14:16
ogra_setup/gui jin the source14:16
* zyga brb14:16
popeyk14:17
davidcallemhall119: /snap/krita/current/meta/gui/calligrakrita.png: empty14:17
popeywooot, mine works14:17
popey(once I put the png in the right place)  ðŸ˜ƒ14:17
mterrytedg, not *so* advanced.  Lots of apps assume they run in background (irc etc).  But also maybe it implies a set of APIs that belong in that interface -- the download api, the push notification api, I dunno14:17
mterryInterfaces in Touch that let an app work in background, but the right way14:17
mhall119davidcalle: ok, something's gone wrong with upstream's build then....14:18
tedgSo yes, I think those should all be in the unity8 interface. I think we might be agreeing?14:18
=== davidcalle is now known as davidcalle_x86_6
=== davidcalle_x86_6 is now known as davidcalle
davidcallemhall119: looks like it14:19
mhall119davidcalle: popey: that's probably my fault in how I submitted the patch upstream14:21
mterrytedg, yeah yeah we agree.  I was just trying to give you more ammo.  Seemed like things had focused just on OOM, but background processing is another uniquely-Touch set of problems14:24
tedgmterry: Makes sense, I think that this first PR is more about getting hello world off the ground. We're gonna need *a lot* more work after that. But I need a foothold to start attaching things like UAL to.14:25
mvomhall119: do you think you could chase our nvidia packagers to include a systemd bind mount unit from "sudo mount -o bind /usr/lib/nvidia-361 /var/lib/snapd/lib/gl/" ?14:26
* popey shoves a dosbox snapcraft to snappy-playpen14:26
popeyprobably the leanest snapcraft.yaml I've ever made14:26
ogra_popey, add doom too !!14:26
popeyhah14:27
mhall119mvo: I don't even know who our nvidia packagers are...is that canonical, community, or nvidia?14:27
popeymhall119: tseliot iirc14:27
ogra_mhall119, tseliot14:27
mhall119thanks14:27
popeyJINX14:27
ogra_:)14:27
mhall119will find him14:27
popeysounded a bit http://s2.quickmeme.com/img/b3/b397b33ced963be59c76e2566b24f0547aa2ae596f148ee1339f3c8e5c5b058c.jpg14:28
ogra_heh14:28
popeywhich seems harsh, despite it being nvidia14:28
popeydidrocks: your jenkins is faulty... " g++: not found"14:29
popeydidrocks: https://travis-ci.org/ubuntu/snappy-playpen/builds/13418200614:29
mhall119mvo: I assume the nvidia package fix needs to be SRU'd into 16.04's archives, it's not something that gets fixed in ubuntu-core images14:33
mvomhall119: yeah, we need to get this SRUed14:33
mvomhall119: not something we can fix in the image14:33
ogra_also, in the image the driver would have to live in the kernel snap14:34
ogra_(not in an nvidia package)14:34
mvomhall119: thanks a lot for helping with the bind mount, really much appreciated14:34
qenghozyga, mvo: I do not remember anything in particular, but it's possible I pressed control-c during a "snap install" or "remove" before. Not to poison your debugging thoughts, but if nothing else seems obvious that might be a place to explore.14:35
zygaqengho: that wouldn't change anything14:35
zygaqengho: snapd carries the work, snap is just a rest client that says "do this please"14:35
zygaqengho: thanks for state.json14:36
zygaqengho: and for the syslog parts14:36
zygaqengho: can you still reproduce this issue?14:41
zygaqengho: and regardless, can you please pastebin the output of mount14:42
zygaqengho: and ls -l /snap/*14:42
qenghozyga: I'll try to reproduce now. mount is in the bug report already (|grep snap).14:43
zygaqengho: thanks14:46
qenghozyga: reproduced. Attached log.14:51
qenghoAw, man, and 2.0.3 is gone from APT. I can't downgrade now.14:53
zygaqengho: is there anything mounted under /snap/google-chrome/14:57
zygaqengho: under the directory (not there directly)14:57
sethjso, if one of my parts is a collection of bash and python scripts that uses an INSTALL file, what would I specify for a plugin? Or will I have to write my own? (there doesn't seem to be a list of included plugins anywhere)15:00
qenghozyga: you have my full mount list.15:00
zygaqengho: thanks, I'll check it out after this cal15:00
zygacall15:00
qengholsof |grep chrome15:01
qengho(wrong terminal. gah.)15:01
qenghosethj: "Uses an INSTALL file"?15:02
qenghosethj: I'm guessing plugin: copy15:02
sethjqengho, https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install. copy does sound like it would be right. Lemme try. (and *is* there a list of these somewhere?)15:03
qenghosethj: yes.   $ snapcraft list-plugins15:04
sethjoh very nice.15:04
sethjsomeone needs to write a manpage :P15:04
qenghosethj: It's also very easy to put a file in parts/plugins/sethj.py, import snapcraft, class Anything(snapcraft.BasePlugin): def build(): super().build(); self.run(["something specific to you")15:07
qenghosethj: in your snapcraft.yaml, that's "plugin: sethj"15:07
netphreakI'm trying to install a snap via command line, and get the following error:15:08
netphreak- Make snap "ubuntu-core" available to the system (cannot set next boot: cannot determine bootloader)15:08
netphreakI'm on a RPI with ubuntu-core15:08
qenghonetphreak: that's a known bug. Should be fixed soon.15:08
netphreak... hopefully :)15:09
qenghonetphreak: subscribe: https://bugs.launchpad.net/snappy/+bug/158040315:10
ubottuLaunchpad bug 1580403 in Snappy "snap tries to manage bootloader in snappy-on-ubuntu-classic mode" [High,Fix committed]15:10
qenghonetphreak: wait, "with ubuntu core"? Is that from a ubuntu core testing image, or from regular 16.04 image with ubuntu core from snapd?15:12
netphreakNot quite sure what it is, got it setup a couple of weeks ago - don't seem to have the image file any more..15:17
netphreakAny command i can run to see which version?15:17
qenghonetphreak: what's it look like to you? What do you see when you turn it on?15:18
qenghoDoes "apt" do anything?15:19
netphreakyes.. Apt is installed15:19
netphreaki used apt to install snapcraft and snap15:20
joc_zyga: i'm getting fails in the asserts section when executing run-checks, am I missing some setup?15:21
zygajoc_: can you be more specific please15:23
joc_zyga: yeah i'm running run-checks as per the README in snapd15:24
sergiusensdidrocks we agreed a while ago to even deprecate `files` in the copy plugin and direct people to `filesets`, `organize`, `stage` and `snap`15:24
joc_zyga: it gets as far as github.com/jocave/snapd/asserts_test15:24
joc_zyga: then i get:15:24
joc_asserts/asserts_test.go:37: undefined: asserts.TestOnlyType15:25
joc_asserts/asserts_test.go:37: too many errors15:25
qenghonetphreak: then you aren't using "ubuntu core", but ubuntu with snaps. And that is the bug here. snapd thinks it's the top OS, when it's not in your case and my case. And that bug is fixed in a few days.15:26
netphreakahh.. ok.. thx for explanation.15:27
netphreakdo you know the status of snappy classic-mode?15:27
qenghonetphreak: "apt" doesn't exist in the Ubuntu Core world. It's a specialty-device kind of place. We get to piggy-back on all its goodness, though.  :)15:27
netphreak:)15:27
joc_zyga: i've only add an interace as you suggested so wasn't expecting to get errors from anywhere else15:27
zygajoc_: hmm, can you reproduce that on master?15:28
zygajoc_: anyway, ignore run-checks15:28
zygajoc_: just go test in interfaces/builtin initially15:28
zygajoc_: and open a pull request or show me your branch15:28
zygatyhicks: hey15:28
qenghonetphreak: Not much. I used it back in February, but it's probably changed a lot since.15:28
zygajdstrand: hey :)15:28
zygajdstrand: I wanted to sync about snap-confine15:28
jdstrandzyga: hey--ok, should tyhicks be here?15:29
zygajdstrand: I think so15:29
qenghonetphreak: it, like all of snap stuff, is in heavy development. To be released soon.15:29
zygajdstrand: I have a few questions and I want to know what you are working on, e.g. if tyler will look at the bind mount interface and if you saw what's posted to the repository lately15:29
popeydavidcalle: didrocks https://github.com/ubuntu/snappy-playpen/pull/15 - feel free to merge if you want :)15:29
tyhickszyga: hi15:30
zygatyhicks: hey, good to see you15:30
joc_zyga: thanks, i'll get tests passing then get back to you15:31
jdstrandzyga: currently I am not doing anything with the launcher. I am waiting for the seccomp arg filtering reviews (I saw you commented, waiting on tyhicks too). when that is done, I will start on trying to get that into xenial and then fix various bugs blocked on that15:31
zygajoc_: note that for all the integration tests to pass you need the patched ubuntu-device-flash15:31
zyga(in your path)15:31
tyhicksjdstrand: I completed my seccomp arg filtering review friday evening15:31
jdstrandsetpriority is the big one, but others. I believe tyhicks is working on other things15:31
jdstrandawesome15:31
zygajdstrand: note that we should be careful about releases of the code today15:31
jdstrandI'm still behind on email and will get to it today15:31
zygajdstrand: as we're getting more and more snap-run/confine/exec story landed15:31
zygajdstrand: and that needs coordination15:32
jdstrandzyga: yes, I was considering SRUing something as a patch to ubuntu-core-launcher for xenial and let all the other stuff be under your control15:32
jdstrandit just depends on the timing15:32
zygajdstrand: that's sounds good, just let us know when this happens15:32
zygajdstrand: note that there's been an upload to debian that's not reflected in either tree today15:32
zygajdstrand: (the version is +1 there)15:33
zygajdstrand: ubuntu@localhost:/etc/modprobe.d/modprobe.d$ ll15:33
jdstrandI'm getting asked every day though on when bug NNN will be fixed and I keep saying 'when seccomp arg filtering is there...)15:33
zygaer15:33
zygabad paste15:33
zygajdstrand: heh15:33
tyhickszyga: I haven't started working on the bind mount support in interfaces - despite not having the time to work on it yet, it felt like a lot of things were in flux and I wasn't clear if plans had changed15:33
zygajdstrand: yes, I see that this should land as soon as we can15:33
zygatyhicks: can I ask you to review my chroot / pivot_root patch15:33
zygatyhicks: I suspect we'll go ahead with that approach (just polish it more)15:33
zygatyhicks: but I want a solid security review to preceed that15:34
tyhickszyga: sure, I can review that patch but I thought we were told not to make that change right now?15:34
zygatyhicks: yes, but the blocker is getting done :)15:34
jdstrandzyga: is what is in the debian +1 patch at least in trunk? if not, what is that?15:34
zygatyhicks: and gustavo said that it should be the next thing after that15:34
tyhickszyga: ack - i'll have a look15:34
zygajdstrand: I think slangasek uploaded something to debian and there's a change that is not integrated anywhere15:35
zygaother than that I'm proposing some tooling changes (autotools)15:35
jdstrandhttp://metadata.ftp-master.debian.org/changelogs//main/u/ubuntu-core-launcher/ubuntu-core-launcher_1.0.29+1_changelog15:35
jdstrandit's not code changes15:35
zygaand I will have a few small patches that make lintian happier (lots of little issues), some of those are related to security so I'll poke you specifically on github15:36
zygajdstrand: with native packages it is hard to see15:36
jdstrandzyga: if it's lintian, see slangasek's patch15:36
zygajdstrand: perhaps I should just ask slangasek to send that to snap-confine :-)15:36
zygaslangasek: ^^15:36
jdstrand:)15:36
zygatyhicks, jdstrand: are you both aware of what's changing to snap-run/confine/exec now?15:37
tyhickszyga: no, I'm not fully aware15:38
jdstrandnot really, no15:38
zygaokay, so the quick big picture is that snap run (a new subcommand of snap) will run snap-confine (which is the current C codebase), that will apply process confinement as it does today and then execute /usr/lib/snapd/snap-exec (xi style) which will in turn read all the yaml bits and figure out what to exec15:39
zygathat last program (snap-exec) will be written (is written by mvo actually) in go and will mainly do yaml parsing and environment setup15:40
zygaI just want to keep both of you in the loop so that you're aware of what is going on15:40
jdstrandzyga: xi style?15:41
tyhickshe means ix15:41
zygayes15:41
zygasorry15:41
zyganot changing the profile15:41
jdstrandI see15:41
zygaso snap-exec runs as the final application will15:41
zygaone thing we will get out of that is that snap-exec will also know how to run pre commands, post commands, and hooks15:41
zygaand that it will no longer have to get the command to run from command line, instead command line will just be the actual command line for the application being started15:41
tyhicksFWIW, I don't think snap-exec should run under the confinement of the application15:42
tyhicksit sounds like it'll be doing things that the application should not have access to do15:42
tyhicksbut maybe I'm wrong15:42
zygatyhicks: it will only read snap.yaml15:42
zygatyhicks: and exec the executable of the application15:42
tyhickszyga: you said pre/post commands and hooks15:43
zygatyhicks: those are just commands to run that are written down in snap.yaml15:43
jdstrandso, instead of snap-confine exec'ing the binary, it executes snap-exec which executes the binary15:43
zygatyhicks: e.g. snap run apache --command=post15:43
zygajdstrand: yes15:43
zygatyhicks: and that goes and reads what to really execute from snap.yaml15:43
zygatyhicks: so that we don't have to pass it on the command line all the time15:44
zygathis approach also kills a lot of the wrappers15:44
tyhicksjdstrand: this is good - it moves code out of the setuid root launcher and the launcher won't need to learn how to read yaml15:44
mvothe long version is here: https://docs.google.com/document/d/1Afjs72T43nN0J5DK6qiaKmIthOjhK8_bvrac6E56Bcc/edit#15:44
jdstrandzyga: what is the motivation for this? does it provide snap-confine cleanups? (if so, what?) does it allow use to clean up other parts of the system? (if so, what?)15:44
zygato the point that we may end up having no wrappers (and /snap/bin might just contain symlinks to /usr/bin/snap15:44
zygajdstrand: it unlocks hook15:44
zygahooks15:44
mvotyhicks: yeah, the u-c-l (snap-confine) really now only needs to deal with the essential stuff, everything else is done in go15:44
zygasidesteps environment15:44
zygaso that we can cleanly set environment for the process15:44
zygaand makes launchers mostly redundant15:45
jdstrandah, that doc is helpful15:45
jdstrandis it up to date?15:45
tyhicksI hope the environment stuff isn't the main motivation15:45
zygatyhicks: I don't actually know, I think the main motivation is to clean up the command line part15:45
tyhicksI'm about to SRU the apparmor changes that would allow the launcher to set up the environment15:45
zygaso snap run looks nice15:45
jdstrandtyhicks: it sounds like hooks is the price of admission15:45
zygaas do all the things after that15:45
mvojdstrand: its up-to-date to the point of "previous dicussion"15:45
arazyga, kudos to your post about first contribution to snapd <315:46
arazyga, maybe you can try to get the people at https://twitter.com/yourfirstpr to tweet about it15:46
zygaara: :-) when I saw that bug I just said "this has to be something other people can contribute"15:46
zygaara: will do15:47
zygatyhicks, jdstrand: that's all I had15:49
zygaI think you are in the loop now :)15:49
jdstrandtyhicks: so, I think in terms of security, this is good, if a little twistier. it reduces the number of lines of setuid code a bit15:49
jdstrandbut the setuid code is at least not twistier15:50
tyhicksjdstrand: reducing the amount of code in the setuid launcher's address space is a good thing15:50
jdstrandtyhicks: what was the env bits to the launcher you were talking about? the safe/unsafe stuff?15:50
tyhicksjdstrand: also, this alleviates the launcher from needing to continually expand to do more things (stuff can go into snap-exec)15:51
jdstrandwell15:51
jdstrandsome stuff15:51
jdstrandif it is root-stuff, then not so much15:52
tyhicksjdstrand: yes, the safe/unsafe stuff that should land in lp:apparmor today15:52
tyhickssure15:52
jdstrandie, this doesn't help your mount code15:52
tyhicksprivileged stuff has to go into snap-confine15:52
jdstrandyeah15:52
tyhicksbut stuff that doesn't require privs, such as parsing the yaml and/or setting up the env, can go into snap-exec15:52
jdstrandwhich is a lot of what we've been doing, but I realize it isn't all everyone's been doing15:52
jdstrandyes, that is good15:53
jdstrandof course, the safe/unsafe is unneeded now, correct? since snap-exec will do it all and it is after dropping and past the exec barrier15:53
jdstrandassuming I understand correctly-- if you can parse the yaml, you can setup the environment however you need to15:54
jdstrandwhich snap-exec is in the position to do15:55
tyhicksjdstrand: safe/unsafe is now unneeded for snappy but someone else will hit this issue during the life of 16.04 and the code is already finalized so I'm going to SRU it15:55
jdstrandtyhicks: yes, I agree. just trying to make sure I understand15:55
slangasekzyga: where is snap-confine, so that I might submit it?15:56
zygaslangasek: github.com/ubuntu-core/snap-confine15:56
zygaslangasek: it will move to snapcore later but just fork and submit away :)15:57
jdstrandtyhicks: so I think I understand the snap-confine to snap-exec attack surface (it isn't appreciably different-- we are already under confinement and actually, snap-confine should be able to lose exec on code in /snap15:57
tyhicksjdstrand: if snap-exec ends up getting its own profile, rather than using the profile of the app, then safe/unsafe would be required again15:57
jdstrandtyhicks: that is what I was trying to tease out15:57
jdstrandso today, we have the launcher that is confined calling the wrapper script15:58
slangasekzyga: thanks15:58
jdstrandwith this, snap-run is unconfined, called snap-confine (confined) which changes profile to the confinement of the app and calling snap-exec <app>15:58
jdstrands/called/calling/15:59
jdstrandsnap-run doesn't need any provileges15:59
zygacorrect15:59
jdstrandprivileges beyond calling snap-confine15:59
zygaone complication is that snap-exec will be from the OS snap15:59
zyganot from the snapd package15:59
zygaunless we do bind mount trickery to prevent that but I think that's okay as it is pretty well defined16:00
jdstrandsystemd unit's exec is still controlled (snap-run now instead of snap-confine). there is no wrapper, but the code needs to be written to make sure it call snap-confine with the correct args16:00
zygajdstrand: it would call snap run16:00
jdstrandsnap-confine if from the os snap16:00
zygajdstrand: all systemd units would just say "snap run $snap.$app --command=..."16:01
jdstrandright, I get that16:01
zygajdstrand: AFAIR that's the agreement but I may be missing bits16:01
zyga(it's not a big change)16:01
jdstrandI may not have said it clearly that I understood that16:01
zygabut yes, this has to migrate16:01
zygasorry then :)16:01
jdstrandI'm trying to understand the attack surface16:01
jdstrandsystemd unit's attack surface is unchanged16:01
jdstrandis all I meant16:02
jdstrandtyhicks: so, snap-run is resolving its argv[0] to decide how to invoke snap-confine16:03
tyhicksright16:05
jdstrandtyhicks: obviously the code has to be correct, but I don't see that as any different from being able to run the wrapper or more to the point, running ubuntu-core-launcher today16:05
tyhicksagreed16:05
tyhicksjdstrand: the user can still run snap-confine directly16:05
jdstrandright16:06
tyhicksjdstrand: snap-confine will still have to do checks to make sure the arguments passed to it are safe16:06
jdstrandand things running under snap-confine still can't run snap-confine, like today can't run ucl16:06
jdstrandtyhicks: of for sure16:06
jdstrandtyhicks: snap-confine needs to continue to be very carefully written16:07
tyhicksyep16:07
jdstrandand confined16:07
tyhicksagreed16:07
jdstrandbut I don't see a reason to confine snap-run16:07
zygado we have to change anything in the apparmor profile for snap-confine?16:07
jdstrandyes16:07
tyhicksjdstrand: I don't either16:07
jdstrandwe can remove some stuff and need to add something to exec snap-exec16:07
zygajdstrand: I did some experiments and I didn't have to add anything16:08
zygajdstrand: is it possible that this is covered by /snap/** r, rule?16:08
jdstrandno16:08
jdstrandthose would be symlinks16:08
jdstrandto snap-run16:08
jdstrandso you would've had to add a rule for snap-run to run those (which we will not)16:09
zygaI mean snap-confine executing snap-exec16:11
zygaI did an expeirment and I ended up with no permission chages required to do that16:11
jdstrandzyga: perhaps it is working for you because it is running unconfined? that would happen if you changed the name to /usr/bin/snap-confine but didn't change the profile to have: /usr/bin/snap-confine (attach_disconnected) {...16:11
zygajdstrand: I was running out of master snap-confine (which currently uses snap-run)16:11
zyga(as the name)16:11
=== ssweeny is now known as ssweeny-lunch
jdstrandI can't say why it worked for you. I can only speculate. you'll need snap-exec and we'll be able to remove several rules16:12
=== ssweeny-lunch is now known as ssweeny
zygain any case, baby steps, mvo has all of the hard work done and we can see when that lands, what is the next step16:13
jdstrandif you can come up with a reproducer for it working now when it shouldn't, I can walk through what is happening16:13
zygajdstrand: can you check if the way I patched maintainer scripts to handle the launcher rename is correct?16:13
jdstrandzyga: where is that PR?16:13
sethjwell thanks for the help qengho! copy worked and it snapped successfully.16:14
zygajdstrand: https://github.com/ubuntu-core/snap-confine/commit/3b85e3ec42a2ac837be48f78005d78248903161c16:15
sethjnow I just need to figure out how to include a font/theme so the text shows up..16:15
jdstrandboy16:15
jdstrandI wonder why people aren't using apparmor_parser there16:16
zygajdstrand: apparmor_parser --remove didn't work because it wanted to parse the now-gone file16:16
sborovkovHello, how can I get snap preinstalled on the image with snappy? Can that be done with ubuntu-device-flash? Or is it supposed to be done in some other way?16:16
zygasborovkov: hey16:17
zygasborovkov: not yet :)16:17
zygasborovkov: it will be with ubuntu-image I'm working on with a few other brave souls16:17
zygasborovkov: if you have some spare time help is appreciated16:17
zygasborovkov: I can point you the way to the code and tell you where we are16:17
jdstrandzyga: it's wrong16:18
sborovkovzyga: understood I don't have a lot of time, need to get application we are doing working on snappy...16:18
jdstrandoh wait16:18
zygajdstrand: mmm?16:18
qenghosethj: you're welcome! make awesome stuff!16:19
zygasborovkov: no worries, we'll get to it in ~1/2 weeks16:19
didrockssergiusens: when I do try to run integration tests, I always have issues with the 15.04 image creation16:19
didrockssergiusens: any hint?16:19
zygajdstrand: can you say what is wrong and how it should look like instead?16:20
zygaslangasek: https://github.com/ubuntu-core/snap-confine/pull/1516:21
didrockskyrofa: elopio: hey, maybe you will know about snapcraft integration tests ^ (no way for me to run them locally due to u-d-f wanting to create the 15.04 image)16:22
zygaslangasek: and have a look at https://github.com/ubuntu-core/snap-confine/pull/14 please, I'd like to land it to iterate on top16:22
zygadidrocks: get mvo's udf and stick it in /usr/local/bin16:22
didrockszyga: I'm pretty sure I tried this, but let me retry16:22
zygadidrocks: same issue as with snapd tests16:23
jdstrandzyga: yes it is wrong. See https://github.com/ubuntu-core/snap-confine/commit/3b85e3ec42a2ac837be48f78005d78248903161c#commitcomment-1768167816:23
didrockszyga: still http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash, right?16:23
zygadidrocks: yes16:23
* didrocks gives it a try16:23
zygajdstrand: ah16:23
jdstrandzyga: what was committed won't match16:24
zygajdstrand: that was a suggestion from tyhicks :)16:24
zygajdstrand: I'll commit your version right away16:24
zygajdstrand: https://github.com/ubuntu-core/snap-confine/pull/1616:26
didrockszyga: yeah, so I'm getting:16:28
didrocksINFO:demos_tests.testbed:Creating a snappy image to run the tests.16:28
didrocksbuilding 15.04 core images is no longer supported. Please use the ppa:snappy-dev/tools 15.04 version of this tool16:28
didrockssubprocess.CalledProcessError: Command '['sudo', 'ubuntu-device-flash', '--verbose', 'core', '15.04', '--channel', 'stable', '--output', '/tmp/tmpfu0iwno7/snappy.img', '--developer-mode']' returned non-zero exit status 116:28
didrockswith $ sudo which ubuntu-device-flash16:28
didrocks/usr/local/bin/ubuntu-device-flash16:28
didrocks(mvo's version)16:28
jdstrandzyga: thanks, responded16:28
zygadidrocks: well, you still call it with 15.04 bits16:28
jdstrandzyga: also, thank you for getting tyhicks and me up to speed on the the changes16:28
* tyhicks scratches his head16:29
didrockszyga: snapcraft does…16:29
zygadidrocks: ah, then that's snapcraft to tweak then16:29
didrocksso I don't know how to run my integration tests on 16.04, which is issue16:29
tyhicksI tested that grep command that I provided16:29
didrocksI guess there is a reason they are calling out 15.04 :p16:29
tyhicksI must have pasted in the wrong command :/16:29
zygatyhicks: is it possible that you got grep=egrep alias?16:29
zygaanyway, I'm glad this had more eyes on it :)16:29
tyhicksnope16:29
tyhicksI rarely use egrep and definitely didn't use it while testing16:30
tyhickssorry for the screw up16:30
jdstrandmaybe there was a way to do it without egrep... anyway, that one works16:30
tyhicksah, the + needs to be escaped16:30
tyhicks$ sudo grep '^/usr/bin/ubuntu-core-launcher ([[:alpha:]]\+)$' /sys/kernel/security/apparmor/profiles16:31
tyhicks/usr/bin/ubuntu-core-launcher (enforce)16:31
tyhicksanyways, egrep is fine16:31
sergiusensdidrocks no need to run udf for integration tests16:31
sergiusensdidrocks for example tests, we support testing on classic16:31
sergiusenselopio ^16:31
didrockssergiusens: is there any example for this?16:32
sergiusensdidrocks but you can also just --skip-install16:32
sergiusensdidrocks for integration_tests just ./runtests.sh integration16:32
didrockssergiusens: yeah, I just wanted to run them in some way rather than sending that to the machinery everytime :)16:32
didrockssergiusens: yeah, those are running, so your comment is that one integration test is failing, you think?16:32
sergiusensdidrocks I really think so16:33
didrocksthat's possible, the fact that we don't fake the terminal size…16:33
zygajoc_: hey, did you get past the testing issues?16:34
sergiusensdidrocks `python3 -m unittest -v -b run integration_tests.test_list_plugins`16:34
didrockssergiusens: ah yeah, there is one :)16:34
didrockssergiusens: yep, will fix it and push16:34
joc_zyga: yes thanks, sorted now16:34
didrockssergiusens: I need to think how we can have it in an terminal-independent size though16:34
didrockssergiusens: as it will be different on jenkins16:34
sergiusensdidrocks the ones that require u-d-f are the "demo" tests fwiw16:34
didrockssergiusens: yeah, and "tour" one (soon ;))16:35
sergiusensdidrocks `python3 -m demos_tests --help`16:35
didrocksok, so --skip-install16:35
didrockssergiusens: I'll fix and try to fine something to not be terminal-size dependent on the integration one16:36
sergiusensdidrocks or `SNAPCRAFT_FROM_INSTALLED=1 python3 -m demo_tests`16:36
sergiusensdidrocks that will install to classic16:36
didrocksoh nice :)16:36
sergiusensdidrocks which is what we do in debian/tests/demostests16:36
didrocksah, for the adt testbed16:36
sergiusensyup16:37
didrockssergiusens: just pushed a fix, it seems to be independent already of terminal size, we'll have to see how it goes under jenkins though once the tests run16:45
zygajdstrand, tyhicks: so how shall we call the new backend "modprobe" backend?16:47
tyhickszyga: is that something we need? I don't know if I've heard about those plans yet16:54
kyrofadidrocks, are you still around?17:11
sergiusensdidrocks maybe `isatty` and affect the result accordingly17:21
sergiusensbut let's see17:22
jdstrandtyhicks: I'll explain. remember how iptable_filter and ip6table_filter don't autoload but once loaded netfilter modules load fine?17:35
jdstrandtyhicks: the backend zyga is talking about is an idea I had and presented to niemeyer and zyga that we agreed is a good idea. basically, there is an additional backend that an interface may implement but most would not17:36
jdstrandtyhicks: so in the case of firewall-control, it would implement this new module backend and when a snap connects to firewall-control, snapd looks at the backend for the list of modules to load for the interface to be at all useful17:37
jdstrandtyhicks: snapd will then drop a file into /etc/modules-load.d for reboots and load the modules on first connection17:38
jdstrandtyhicks: in this manner, snaps niether get to specify the modules to load themselves (or there options) nor have SYS_MODULE, etc17:38
jdstrandtyhicks: like with security policy, dbus policy and udev rules, snapd has a hardcoded list of what it will make sure is loaded17:39
jdstrandtyhicks: as it turns out, this is likely useful for modem-manager as well as firewall-control17:40
zygatyhicks: yes, probably for modem manager17:40
jdstrandtyhicks: you may recall snappy config ubuntu-core allowed for the admin/gadget developer to specify modules to load on a particular device. I suspect that may still be useful, but integrating into interfaces in this manner has a way better user experience17:41
jdstrandtyhicks: the first iterations will only deal with a list of modules to load (ie, no options or other stuff). if we need that other stuff, we can look at it when requested17:42
jdstrandzyga: I was initially thinking that rather than trying to maintain a single file in /etc/modules-load.d, snapd would manage one file per interface (so, snap.firewall-control, snap.ppp (or something)). I'm not married to it, but it seems consistent with other parts of the system17:43
zygajdstrand: I'll think about it, a single file might be easier on SD cards and it's all the same technically (otherwise)17:44
jdstrandzyga: that said, garbage collection would be something to consider (removing those files on snap disconnect) and perhaps that isn't the best approach17:44
jdstrand(just some random thoughts I had)17:44
zygajdstrand: on disconnect or connect we always rewrite the file after computing the content it has to have17:44
zygajdstrand: so it's not a problem to use one file unless that file would be huge but I don't think it is a problem here17:44
jdstrandthat's true17:45
jdstrandprobably actually easier in this case17:45
jdstrandzyga: I think I prefer 'kernelModules' instead of 'modprobe'17:46
* tyhicks was lunching17:47
tyhicksjdstrand: so snaps will not be able to provide their own modules - it'll only be modules shipped by the kernel snap?17:49
jdstrandtyhicks: app snaps can't do anything with modules directly. all they can do is 'plugs: [ something ]' where the 'something' interface may define modules that snapd will load17:50
jdstrandtyhicks: and snaps can't influence what is loaded or how17:51
nimoovexit17:52
tyhicksjdstrand: ohhh, I understand now17:54
=== oparoz_ is now known as oparoz
ogra_jdstrand, zyga, please dont forget about possible module options ;)18:10
jdstrandI mentioned that. at first it is just a list. when there is something that needs options, we can expand18:11
zygajdstrand: ay, will do18:15
almejo_Hi... please please help me. I am using ubuntu 16.04 and a snap faild to uninstall. Now I can not uninstall nor install packages. IS there a way to remove all snaps and start from the beginig?19:03
almejo_like snap --forece remove <snap>19:03
almejo_i can not delete packages becouse they are mounted19:04
almejo__Hi... please please help me. I am using ubuntu 16.04 and a snap faild to uninstall. Now I can not uninstall nor install packages. IS there a way to remove all snaps and start from the beginig?19:09
sergiusenszyga ^19:22
sergiusensseems to be something widespread19:22
sergiusensmaybe we should add mention of your branch to /topic19:23
thibranhello, someone there?22:17
sergiusensthibran what's up?22:19
thibranI solved a snap bitsize bug22:19
thibranand now I would like to get it merged, but have some questions22:20
thibranto sign the contributor agreement, I need a 'project contact'22:21
thibranhow do I get one?22:22
sergiusensthibran let me check, but for starters you can start getting the PR up22:22
sergiusenskyrofa you've been dealing with CLAs lately, where should it go to?22:23
sergiusensthibran a review is not blocked by the CLA22:23
thibrank22:24
thibranthan I upload the code22:25
sergiusensthibran yeah, get your toes in technically first, leave the paper work for last :-)22:26
thibranhttps://github.com/snapcore/snapd/pull/124922:29
thibranI hope I got the i18n stuff right, my compiled bin works22:29

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!