| === 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 | ||
| zyga | o/ | 07:49 |
|---|---|---|
| davidcalle | didrocks: hey, can you have a quick look at https://github.com/ubuntu/snappy-playpen/pull/11 ? Thanks :) | 08:33 |
| didrocks | davidcalle: can you expand a little bit what you are trying to fix? | 08:34 |
| didrocks | ah, the Testing atom/parts/plugins | 08:35 |
| didrocks | because we have a custom plugin | 08:35 |
| didrocks | so subdir | 08:35 |
| didrocks | davidcalle: I think that can be done maybe in an easier way (don't like the double xargs) | 08:36 |
| davidcalle | didrocks: 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 |
| davidcalle | didrocks: 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 |
| didrocks | davidcalle: it's because I'm using sergiusens docker | 08:40 |
| didrocks | davidcalle: let me set up ours + daily refresh | 08:40 |
| didrocks | davidcalle: I'm playing with the regexp :) | 08:40 |
| didrocks | davidcalle: got it in a way shorter, do you want me to setup a branch you can review (or pull or whatever)? | 08:42 |
| davidcalle | didrocks: I'm fine with your branch replacing this one | 08:43 |
| === chihchun_afk is now known as chihchun | ||
| didrocks | davidcalle: mind reviewing? https://github.com/ubuntu/snappy-playpen/pull/14 | 08:49 |
| davidcalle | didrocks: hah, wfm :) | 08:52 |
| didrocks | davidcalle: we should specialized those changes in ci-run btw :) | 08:53 |
| davidcalle | didrocks: although... look at the ci-run :D | 08:53 |
| didrocks | davidcalle: yeah, it tries to run on the top_dir | 08:53 |
| didrocks | which was already the case | 08:53 |
| didrocks | Let me try to special-case this | 08:53 |
| davidcalle | didrocks: nope, yours considers the ci-run file as a folder | 08:54 |
| didrocks | davidcalle: yeah, because it doesn't care of file type | 08:54 |
| didrocks | we can just say "if file type == file" -> change is in the root dir | 08:54 |
| didrocks | I guess that's the best fix for other files in root | 08:55 |
| didrocks | davidcalle: refresh (see second commit) | 08:57 |
| davidcalle | didrocks: ty :) | 08:59 |
| didrocks | davidcalle: thanks for spotting it! | 09:00 |
| didrocks | davidcalle: so, I guess having our own docker image refreshed daily makes sense, right? | 09:01 |
| davidcalle | didrocks: sounds like a good solution, yes | 09:02 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| didrocks | davidcalle: ok, master have most of the tests passing with my image (which is daily built) | 09:30 |
| didrocks | davidcalle: however, unsure who did merge ffmepg, but it seems to fail | 09:30 |
| didrocks | davidcalle: I'll push the docker image change first, then, we can iterate to get other fixed | 09:31 |
| davidcalle | popey: ^ | 09:42 |
| davidcalle | Thanks didrocks | 09:42 |
| popey | eh? | 09:45 |
| popey | I did ffmpeg as a standalone snap. | 09:46 |
| popey | davidcalle merged them | 09:46 |
| davidcalle | popey: 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 |
| popey | my snap worked fine, what did you do? :) | 09:50 |
| didrocks | davidcalle: I did a local ci-run | 09:51 |
| didrocks | it seems snapcraft can't find the ffmepg command (which is in bin/ffmepg) | 09:51 |
| didrocks | note that this can be an upstream issue with latest snapcraft :) | 09:51 |
| didrocks | popey: 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 |
| davidcalle | ok | 09:55 |
| vallettea | hello, 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 case | 10:51 |
| === vejmarie_ is now known as vejmarie | ||
| === JanC is now known as Guest93383 | ||
| === JanC_ is now known as JanC | ||
| hathor008 | can 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-application | 12:40 |
| sborovkov | Hello. Are config interfaces back or still not? | 12:42 |
| ogra_ | not yet | 12:42 |
| sborovkov | ogra_: is there some issue on launchpad for that? I did not find one :-( | 12:44 |
| didrocks | sborovkov: you're right, there is none: please file one https://bugs.launchpad.net/ubuntu/+source/snapd | 12:46 |
| sborovkov | Understood, thanks. | 12:48 |
| didrocks | hathor008: the issue is in your snapcraft.yaml | 12:48 |
| didrocks | you have: | 12:48 |
| didrocks | files: | 12:48 |
| didrocks | "*": | 12:48 |
| didrocks | you need: | 12:49 |
| didrocks | files: | 12:49 |
| didrocks | "*": '.' | 12:49 |
| didrocks | hathor008: but please, file a bug against https://bugs.launchpad.net/ubuntu/+source/snapcraft as the error message isn't obvious | 12:49 |
| hathor008 | lol that's all it is? i figured it was something simple like that | 12:49 |
| hathor008 | ok no problem | 12:49 |
| didrocks | hathor008: please copy your invalid snapcraft.yaml and mention "copy plugin" :) | 12:50 |
| didrocks | but 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 | |
| mhall119 | hey guys,is there any known issue with running an OpenGL-using snap on proprietary graphics drivers? | 12:55 |
| mhall119 | someone trying to run a Krita snap on proprietary nvidia is gettign this: http://pastebin.com/WsUfEj8J | 12:56 |
| mhall119 | sergiusens: kyrofa: ^^ any help? | 13:00 |
| zyga | tyhicks: hey | 13:03 |
| noizer | Hi 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 device | 13:06 |
| hathor008 | thanks for your help, didrocks. i really appreciate it :) | 13:08 |
| didrocks | hathor008: yw! :) | 13:08 |
| sborovkov | Hello. 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 |
| didrocks | sborovkov: you have a log-observe interface, maybe give it a shot? (I don't think there anything for configuring it remotely yet) | 13:11 |
| jdstrand | tyhicks, 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 |
| jdstrand | sergiusens, sborovkov: fyi, tyhicks and I have been giving some thought to silencing logging of noisy denials | 13:14 |
| sborovkov | didrocks: thanks | 13:15 |
| sborovkov | jdstrand: is there a way to know what denial would be fatal? | 13:15 |
| jdstrand | sergiusens, sborovkov: we can do that now with an explicit deny of course, but that doesn't always work the way you want | 13:15 |
| sborovkov | jdstrand: since in the same log I had ldconfig run... I have no idea why, and don't know if it's fatal as well | 13:15 |
| jdstrand | sborovkov: run it in strict mode and see if your program runs ok | 13:15 |
| sborovkov | jdstrand: my program accesses /dev/vchiq as well, so it does not work in strict :-) | 13:17 |
| mhall119 | jdstrand: davidcalle is helping me debug the krita snap with snappy-debug.security scanlog, but he gets this: http://paste.ubuntu.com/16863706/ | 13:17 |
| davidcalle | Installing snappy-debug with --devmode helped http://paste.ubuntu.com/16863781/ | 13:18 |
| didrocks | mhall119: jdstrand: confirmed, everytime an exception is raised, getting the stacktrace as well | 13:20 |
| noizer | what can I do with a snap thats not fits in the temporary dir while installing? | 13:29 |
| zyga | noizer: hmm? | 13:30 |
| zyga | noizer: how big is it? | 13:30 |
| zyga | noizer: report a bug first please | 13:30 |
| zyga | noizer: is your /tmp a tmpfs? | 13:30 |
| noizer | zyga: its my /tmp | 13:31 |
| noizer | zyga 250mb | 13:32 |
| noizer | zyga ps how can i manually make a snap? | 13:32 |
| noizer | zyga its for my armel build | 13:33 |
| ogra_ | and your HDD doesnt have 250MB free ? | 13:33 |
| ogra_ | (in /tmp) | 13:33 |
| zyga | noizer: just use mksquashfs | 13:33 |
| jdstrand | sborovkov: 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.app | 13:33 |
| ogra_ | uh | 13:33 |
| ogra_ | no | 13:33 |
| ogra_ | use "snapcraft snap $dir" | 13:34 |
| zyga | ogra_: 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 |
| jdstrand | sborovkov: 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 forward | 13:34 |
| noizer | zyga ogra_ http://paste.ubuntu.com/16864020/ | 13:35 |
| noizer | here you can see my diskspace | 13:35 |
| jdstrand | mhall119: 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 release | 13:36 |
| ogra_ | noizer, well, /tmp is a tmpfs ... so buy more ram or change that to use the disk instead | 13:36 |
| noizer | heh its my raspi | 13:36 |
| mhall119 | jdstrand: yup, for now he's got snappy-debug working in devmode | 13:36 |
| ogra_ | oh, you are *on* snappy | 13:36 |
| mhall119 | which revealed a syscall to 'bind' that was blocked | 13:36 |
| jdstrand | mhall119: 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 needed | 13:36 |
| noizer | ogra_: yes ofc | 13:36 |
| mhall119 | so running krita in --devmode gets it working for davidcalle | 13:37 |
| ogra_ | hmm | 13:37 |
| mhall119 | but someone else is having issues with OpenGL still, and running krita in --devmode doesn't help him | 13:37 |
| mhall119 | davidcalle is using open-source gpu drivers, and the other guy has proprietary nvidia | 13:37 |
| jdstrand | mhall119: 774d721b0d4935fcdcb1146b8e38396eca67c17f (for snappy-debug) | 13:37 |
| jdstrand | mhall119: opengl is a mvo/zyga thing (iirc) | 13:38 |
| mhall119 | mvo: zyga: can you guys help me debug this: http://pastebin.com/WsUfEj8J | 13:38 |
| ogra_ | noizer, thats a tricky one indeed | 13:38 |
| jdstrand | mhall119: 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 |
| mhall119 | it'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 fails | 13:39 |
| mvo | mhall119: 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 bug | 13:39 |
| mhall119 | jdstrand: he's on amd64 | 13:39 |
| jdstrand | mhall119: not confinement> yes, I know, hence comment regarding mvo/zyga | 13:39 |
| mhall119 | jdstrand: though I suspect that socketcall might be related to the bind denial that davidcalle sees | 13:39 |
| mhall119 | mvo: proprietary driver, yes | 13:40 |
| noizer | ogra_: Is there for now a workaround? | 13:40 |
| jdstrand | mhall119: re bind> maybe. might just need network-bind | 13:40 |
| mvo | mhall119: do you happen to know what version? | 13:40 |
| jdstrand | snappy-debug in devmode will help you decide | 13:40 |
| mhall119 | jdstrand: yeah, but it's a digital painting program, I don't see why it would need that in the first place | 13:40 |
| mhall119 | mvo: 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 /tmp | 13:40 |
| jdstrand | mhall119: it is surprising what apps not designed for confinement require | 13:41 |
| mhall119 | mvo: let me get him in this channel, so I'm not passing messages around | 13:41 |
| mvo | mhall119: is that a system you have direct access to? what is the output of "ls -ld /usr/lib/nvidia-*" ? | 13:41 |
| jdstrand | mhall119: it could also be a kde think. bind is needed for binding to the server side of a unix socket too | 13:42 |
| jdstrand | thinkg* | 13:42 |
| jdstrand | err | 13:42 |
| jdstrand | thing* | 13:42 |
| mhall119 | mvo: I don't, which is why I'm trying to get him to join in here | 13:42 |
| jdstrand | mhall119: kde has this whole ipc infrastructure which I predict it going to be challenging | 13:42 |
| mvo | mhall119: or tell me where he is and I join there, either way is fine | 13:42 |
| mhall119 | jdstrand: hmmm, maybe. I can add network-bind to see if that allows davidcalle to run without --devmode | 13:42 |
| mhall119 | mvo: he's in #krita | 13:43 |
| kyrofa | mhall119, do you know what computer he has? | 13:43 |
| mhall119 | nick is mattiasw | 13:43 |
| mhall119 | kyrofa: only that it's amd64 and proprietary nvidia driver | 13:43 |
| kyrofa | Okay | 13:43 |
| kyrofa | zyga, do you know anything about https://askubuntu.com/questions/779875/cant-download-the-snap-packages ? | 13:45 |
| didrocks | kyrofa: swift is down | 13:47 |
| didrocks | impacted CI and the store | 13:48 |
| didrocks | impacting* | 13:48 |
| didrocks | (and hey!) | 13:48 |
| kyrofa | didrocks, oh. I guess that would do it! :P | 13:48 |
| kyrofa | didrocks, hey! | 13:48 |
| kyrofa | didrocks, that might also explain why my integration tests are having issues | 13:48 |
| didrocks | kyrofa: not for your local test run though :p (j/k) | 13:49 |
| noizer | ogra_: What is the difference between meta/snap.yaml and snapcraft.yaml | 13:50 |
| kyrofa | noizer, meta/snap.yaml is what snapd itself requires inside the snap itself | 13:54 |
| kyrofa | noizer, 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 you | 13:55 |
| ogra_ | noizer, what kyrofa said :) | 13:56 |
| zyga | kyrofa: looking | 13:57 |
| kyrofa | Sorry zyga, didrocks informed me that it was likely a temporary store issue | 13:57 |
| noizer | hmmm 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 anymore | 13:59 |
| zyga | kyrofa: I also replied: http://askubuntu.com/questions/779875/cant-download-the-snap-packages/779917#779917 | 14:00 |
| kyrofa | zyga, ah, good idea | 14:00 |
| === chihchun is now known as chihchun_afk | ||
| mterry | tedg, 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 |
| popey | mhall119: do you know why the icon shows as a piece of paper for krita? | 14:11 |
| popey | I 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 |
| mhall119 | it should be...it works for me anyway | 14:11 |
| mhall119 | popey: is it in /snap/krita/current/meta/gui/ ? | 14:12 |
| popey | mhall119: yes | 14:13 |
| mhall119 | what does the .desktop list for Icon? | 14:14 |
| popey | Icon=${SNAP}/meta/gui/calligrakrita.png | 14:14 |
| mhall119 | then it should be working... | 14:14 |
| popey | $ file /snap/krita/current/meta/gui/calligrakrita.png | 14:14 |
| popey | /snap/krita/current/meta/gui/calligrakrita.png: empty | 14:14 |
| popey | that won't help | 14:14 |
| popey | zero byte file | 14:15 |
| mhall119 | empty? | 14:15 |
| qengho | zyga: howdy! | 14:15 |
| * ogra_ hands popey a spare byte to add it to the file | 14:15 | |
| mhall119 | how the heck... | 14:15 |
| popey | what copies that file? | 14:15 |
| mhall119 | davidcalle: can you $ file /snap/krita/current/meta/gui/calligrakrita.png | 14:15 |
| zyga | qengho: hey | 14:15 |
| tedg | mterry: 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 |
| mhall119 | popey: it's just in the setup/gui/ folder of the snapcraft directory | 14:15 |
| popey | setup/gui, not meta/gui? | 14:16 |
| mhall119 | yeah, that's the snapcraft folder, it installs to meta/gui | 14:16 |
| ogra_ | setup/gui jin the source | 14:16 |
| * zyga brb | 14:16 | |
| popey | k | 14:17 |
| davidcalle | mhall119: /snap/krita/current/meta/gui/calligrakrita.png: empty | 14:17 |
| popey | wooot, mine works | 14:17 |
| popey | (once I put the png in the right place) 😃 | 14:17 |
| mterry | tedg, 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 dunno | 14:17 |
| mterry | Interfaces in Touch that let an app work in background, but the right way | 14:17 |
| mhall119 | davidcalle: ok, something's gone wrong with upstream's build then.... | 14:18 |
| tedg | So 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 | ||
| davidcalle | mhall119: looks like it | 14:19 |
| mhall119 | davidcalle: popey: that's probably my fault in how I submitted the patch upstream | 14:21 |
| mterry | tedg, 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 problems | 14:24 |
| tedg | mterry: 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 |
| mvo | mhall119: 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-playpen | 14:26 | |
| popey | probably the leanest snapcraft.yaml I've ever made | 14:26 |
| ogra_ | popey, add doom too !! | 14:26 |
| popey | hah | 14:27 |
| mhall119 | mvo: I don't even know who our nvidia packagers are...is that canonical, community, or nvidia? | 14:27 |
| popey | mhall119: tseliot iirc | 14:27 |
| ogra_ | mhall119, tseliot | 14:27 |
| mhall119 | thanks | 14:27 |
| popey | JINX | 14:27 |
| ogra_ | :) | 14:27 |
| mhall119 | will find him | 14:27 |
| popey | sounded a bit http://s2.quickmeme.com/img/b3/b397b33ced963be59c76e2566b24f0547aa2ae596f148ee1339f3c8e5c5b058c.jpg | 14:28 |
| ogra_ | heh | 14:28 |
| popey | which seems harsh, despite it being nvidia | 14:28 |
| popey | didrocks: your jenkins is faulty... " g++: not found" | 14:29 |
| popey | didrocks: https://travis-ci.org/ubuntu/snappy-playpen/builds/134182006 | 14:29 |
| mhall119 | mvo: 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 images | 14:33 |
| mvo | mhall119: yeah, we need to get this SRUed | 14:33 |
| mvo | mhall119: not something we can fix in the image | 14:33 |
| ogra_ | also, in the image the driver would have to live in the kernel snap | 14:34 |
| ogra_ | (not in an nvidia package) | 14:34 |
| mvo | mhall119: thanks a lot for helping with the bind mount, really much appreciated | 14:34 |
| qengho | zyga, 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 |
| zyga | qengho: that wouldn't change anything | 14:35 |
| zyga | qengho: snapd carries the work, snap is just a rest client that says "do this please" | 14:35 |
| zyga | qengho: thanks for state.json | 14:36 |
| zyga | qengho: and for the syslog parts | 14:36 |
| zyga | qengho: can you still reproduce this issue? | 14:41 |
| zyga | qengho: and regardless, can you please pastebin the output of mount | 14:42 |
| zyga | qengho: and ls -l /snap/* | 14:42 |
| qengho | zyga: I'll try to reproduce now. mount is in the bug report already (|grep snap). | 14:43 |
| zyga | qengho: thanks | 14:46 |
| qengho | zyga: reproduced. Attached log. | 14:51 |
| qengho | Aw, man, and 2.0.3 is gone from APT. I can't downgrade now. | 14:53 |
| zyga | qengho: is there anything mounted under /snap/google-chrome/ | 14:57 |
| zyga | qengho: under the directory (not there directly) | 14:57 |
| sethj | so, 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 |
| qengho | zyga: you have my full mount list. | 15:00 |
| zyga | qengho: thanks, I'll check it out after this cal | 15:00 |
| zyga | call | 15:00 |
| qengho | lsof |grep chrome | 15:01 |
| qengho | (wrong terminal. gah.) | 15:01 |
| qengho | sethj: "Uses an INSTALL file"? | 15:02 |
| qengho | sethj: I'm guessing plugin: copy | 15:02 |
| sethj | qengho, 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 |
| qengho | sethj: yes. $ snapcraft list-plugins | 15:04 |
| sethj | oh very nice. | 15:04 |
| sethj | someone needs to write a manpage :P | 15:04 |
| qengho | sethj: 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 |
| qengho | sethj: in your snapcraft.yaml, that's "plugin: sethj" | 15:07 |
| netphreak | I'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 |
| netphreak | I'm on a RPI with ubuntu-core | 15:08 |
| qengho | netphreak: that's a known bug. Should be fixed soon. | 15:08 |
| netphreak | ... hopefully :) | 15:09 |
| qengho | netphreak: subscribe: https://bugs.launchpad.net/snappy/+bug/1580403 | 15:10 |
| ubottu | Launchpad bug 1580403 in Snappy "snap tries to manage bootloader in snappy-on-ubuntu-classic mode" [High,Fix committed] | 15:10 |
| qengho | netphreak: 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 |
| netphreak | Not 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 |
| netphreak | Any command i can run to see which version? | 15:17 |
| qengho | netphreak: what's it look like to you? What do you see when you turn it on? | 15:18 |
| qengho | Does "apt" do anything? | 15:19 |
| netphreak | yes.. Apt is installed | 15:19 |
| netphreak | i used apt to install snapcraft and snap | 15:20 |
| joc_ | zyga: i'm getting fails in the asserts section when executing run-checks, am I missing some setup? | 15:21 |
| zyga | joc_: can you be more specific please | 15:23 |
| joc_ | zyga: yeah i'm running run-checks as per the README in snapd | 15:24 |
| sergiusens | didrocks 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_test | 15:24 |
| joc_ | zyga: then i get: | 15:24 |
| joc_ | asserts/asserts_test.go:37: undefined: asserts.TestOnlyType | 15:25 |
| joc_ | asserts/asserts_test.go:37: too many errors | 15:25 |
| qengho | netphreak: 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 |
| netphreak | ahh.. ok.. thx for explanation. | 15:27 |
| netphreak | do you know the status of snappy classic-mode? | 15:27 |
| qengho | netphreak: "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 else | 15:27 |
| zyga | joc_: hmm, can you reproduce that on master? | 15:28 |
| zyga | joc_: anyway, ignore run-checks | 15:28 |
| zyga | joc_: just go test in interfaces/builtin initially | 15:28 |
| zyga | joc_: and open a pull request or show me your branch | 15:28 |
| zyga | tyhicks: hey | 15:28 |
| qengho | netphreak: Not much. I used it back in February, but it's probably changed a lot since. | 15:28 |
| zyga | jdstrand: hey :) | 15:28 |
| zyga | jdstrand: I wanted to sync about snap-confine | 15:28 |
| jdstrand | zyga: hey--ok, should tyhicks be here? | 15:29 |
| zyga | jdstrand: I think so | 15:29 |
| qengho | netphreak: it, like all of snap stuff, is in heavy development. To be released soon. | 15:29 |
| zyga | jdstrand: 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 lately | 15:29 |
| popey | davidcalle: didrocks https://github.com/ubuntu/snappy-playpen/pull/15 - feel free to merge if you want :) | 15:29 |
| tyhicks | zyga: hi | 15:30 |
| zyga | tyhicks: hey, good to see you | 15:30 |
| joc_ | zyga: thanks, i'll get tests passing then get back to you | 15:31 |
| jdstrand | zyga: 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 that | 15:31 |
| zyga | joc_: note that for all the integration tests to pass you need the patched ubuntu-device-flash | 15:31 |
| zyga | (in your path) | 15:31 |
| tyhicks | jdstrand: I completed my seccomp arg filtering review friday evening | 15:31 |
| jdstrand | setpriority is the big one, but others. I believe tyhicks is working on other things | 15:31 |
| jdstrand | awesome | 15:31 |
| zyga | jdstrand: note that we should be careful about releases of the code today | 15:31 |
| jdstrand | I'm still behind on email and will get to it today | 15:31 |
| zyga | jdstrand: as we're getting more and more snap-run/confine/exec story landed | 15:31 |
| zyga | jdstrand: and that needs coordination | 15:32 |
| jdstrand | zyga: yes, I was considering SRUing something as a patch to ubuntu-core-launcher for xenial and let all the other stuff be under your control | 15:32 |
| jdstrand | it just depends on the timing | 15:32 |
| zyga | jdstrand: that's sounds good, just let us know when this happens | 15:32 |
| zyga | jdstrand: note that there's been an upload to debian that's not reflected in either tree today | 15:32 |
| zyga | jdstrand: (the version is +1 there) | 15:33 |
| zyga | jdstrand: ubuntu@localhost:/etc/modprobe.d/modprobe.d$ ll | 15:33 |
| jdstrand | I'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 |
| zyga | er | 15:33 |
| zyga | bad paste | 15:33 |
| zyga | jdstrand: heh | 15:33 |
| tyhicks | zyga: 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 changed | 15:33 |
| zyga | jdstrand: yes, I see that this should land as soon as we can | 15:33 |
| zyga | tyhicks: can I ask you to review my chroot / pivot_root patch | 15:33 |
| zyga | tyhicks: I suspect we'll go ahead with that approach (just polish it more) | 15:33 |
| zyga | tyhicks: but I want a solid security review to preceed that | 15:34 |
| tyhicks | zyga: sure, I can review that patch but I thought we were told not to make that change right now? | 15:34 |
| zyga | tyhicks: yes, but the blocker is getting done :) | 15:34 |
| jdstrand | zyga: is what is in the debian +1 patch at least in trunk? if not, what is that? | 15:34 |
| zyga | tyhicks: and gustavo said that it should be the next thing after that | 15:34 |
| tyhicks | zyga: ack - i'll have a look | 15:34 |
| zyga | jdstrand: I think slangasek uploaded something to debian and there's a change that is not integrated anywhere | 15:35 |
| zyga | other than that I'm proposing some tooling changes (autotools) | 15:35 |
| jdstrand | http://metadata.ftp-master.debian.org/changelogs//main/u/ubuntu-core-launcher/ubuntu-core-launcher_1.0.29+1_changelog | 15:35 |
| jdstrand | it's not code changes | 15:35 |
| zyga | and 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 github | 15:36 |
| zyga | jdstrand: with native packages it is hard to see | 15:36 |
| jdstrand | zyga: if it's lintian, see slangasek's patch | 15:36 |
| zyga | jdstrand: perhaps I should just ask slangasek to send that to snap-confine :-) | 15:36 |
| zyga | slangasek: ^^ | 15:36 |
| jdstrand | :) | 15:36 |
| zyga | tyhicks, jdstrand: are you both aware of what's changing to snap-run/confine/exec now? | 15:37 |
| tyhicks | zyga: no, I'm not fully aware | 15:38 |
| jdstrand | not really, no | 15:38 |
| zyga | okay, 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 exec | 15:39 |
| zyga | that last program (snap-exec) will be written (is written by mvo actually) in go and will mainly do yaml parsing and environment setup | 15:40 |
| zyga | I just want to keep both of you in the loop so that you're aware of what is going on | 15:40 |
| jdstrand | zyga: xi style? | 15:41 |
| tyhicks | he means ix | 15:41 |
| zyga | yes | 15:41 |
| zyga | sorry | 15:41 |
| zyga | not changing the profile | 15:41 |
| jdstrand | I see | 15:41 |
| zyga | so snap-exec runs as the final application will | 15:41 |
| zyga | one thing we will get out of that is that snap-exec will also know how to run pre commands, post commands, and hooks | 15:41 |
| zyga | and 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 started | 15:41 |
| tyhicks | FWIW, I don't think snap-exec should run under the confinement of the application | 15:42 |
| tyhicks | it sounds like it'll be doing things that the application should not have access to do | 15:42 |
| tyhicks | but maybe I'm wrong | 15:42 |
| zyga | tyhicks: it will only read snap.yaml | 15:42 |
| zyga | tyhicks: and exec the executable of the application | 15:42 |
| tyhicks | zyga: you said pre/post commands and hooks | 15:43 |
| zyga | tyhicks: those are just commands to run that are written down in snap.yaml | 15:43 |
| jdstrand | so, instead of snap-confine exec'ing the binary, it executes snap-exec which executes the binary | 15:43 |
| zyga | tyhicks: e.g. snap run apache --command=post | 15:43 |
| zyga | jdstrand: yes | 15:43 |
| zyga | tyhicks: and that goes and reads what to really execute from snap.yaml | 15:43 |
| zyga | tyhicks: so that we don't have to pass it on the command line all the time | 15:44 |
| zyga | this approach also kills a lot of the wrappers | 15:44 |
| tyhicks | jdstrand: this is good - it moves code out of the setuid root launcher and the launcher won't need to learn how to read yaml | 15:44 |
| mvo | the long version is here: https://docs.google.com/document/d/1Afjs72T43nN0J5DK6qiaKmIthOjhK8_bvrac6E56Bcc/edit# | 15:44 |
| jdstrand | zyga: 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 |
| zyga | to the point that we may end up having no wrappers (and /snap/bin might just contain symlinks to /usr/bin/snap | 15:44 |
| zyga | jdstrand: it unlocks hook | 15:44 |
| zyga | hooks | 15:44 |
| mvo | tyhicks: yeah, the u-c-l (snap-confine) really now only needs to deal with the essential stuff, everything else is done in go | 15:44 |
| zyga | sidesteps environment | 15:44 |
| zyga | so that we can cleanly set environment for the process | 15:44 |
| zyga | and makes launchers mostly redundant | 15:45 |
| jdstrand | ah, that doc is helpful | 15:45 |
| jdstrand | is it up to date? | 15:45 |
| tyhicks | I hope the environment stuff isn't the main motivation | 15:45 |
| zyga | tyhicks: I don't actually know, I think the main motivation is to clean up the command line part | 15:45 |
| tyhicks | I'm about to SRU the apparmor changes that would allow the launcher to set up the environment | 15:45 |
| zyga | so snap run looks nice | 15:45 |
| jdstrand | tyhicks: it sounds like hooks is the price of admission | 15:45 |
| zyga | as do all the things after that | 15:45 |
| mvo | jdstrand: its up-to-date to the point of "previous dicussion" | 15:45 |
| ara | zyga, kudos to your post about first contribution to snapd <3 | 15:46 |
| ara | zyga, maybe you can try to get the people at https://twitter.com/yourfirstpr to tweet about it | 15:46 |
| zyga | ara: :-) when I saw that bug I just said "this has to be something other people can contribute" | 15:46 |
| zyga | ara: will do | 15:47 |
| zyga | tyhicks, jdstrand: that's all I had | 15:49 |
| zyga | I think you are in the loop now :) | 15:49 |
| jdstrand | tyhicks: so, I think in terms of security, this is good, if a little twistier. it reduces the number of lines of setuid code a bit | 15:49 |
| jdstrand | but the setuid code is at least not twistier | 15:50 |
| tyhicks | jdstrand: reducing the amount of code in the setuid launcher's address space is a good thing | 15:50 |
| jdstrand | tyhicks: what was the env bits to the launcher you were talking about? the safe/unsafe stuff? | 15:50 |
| tyhicks | jdstrand: also, this alleviates the launcher from needing to continually expand to do more things (stuff can go into snap-exec) | 15:51 |
| jdstrand | well | 15:51 |
| jdstrand | some stuff | 15:51 |
| jdstrand | if it is root-stuff, then not so much | 15:52 |
| tyhicks | jdstrand: yes, the safe/unsafe stuff that should land in lp:apparmor today | 15:52 |
| tyhicks | sure | 15:52 |
| jdstrand | ie, this doesn't help your mount code | 15:52 |
| tyhicks | privileged stuff has to go into snap-confine | 15:52 |
| jdstrand | yeah | 15:52 |
| tyhicks | but stuff that doesn't require privs, such as parsing the yaml and/or setting up the env, can go into snap-exec | 15:52 |
| jdstrand | which is a lot of what we've been doing, but I realize it isn't all everyone's been doing | 15:52 |
| jdstrand | yes, that is good | 15:53 |
| jdstrand | of course, the safe/unsafe is unneeded now, correct? since snap-exec will do it all and it is after dropping and past the exec barrier | 15:53 |
| jdstrand | assuming I understand correctly-- if you can parse the yaml, you can setup the environment however you need to | 15:54 |
| jdstrand | which snap-exec is in the position to do | 15:55 |
| tyhicks | jdstrand: 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 it | 15:55 |
| jdstrand | tyhicks: yes, I agree. just trying to make sure I understand | 15:55 |
| slangasek | zyga: where is snap-confine, so that I might submit it? | 15:56 |
| zyga | slangasek: github.com/ubuntu-core/snap-confine | 15:56 |
| zyga | slangasek: it will move to snapcore later but just fork and submit away :) | 15:57 |
| jdstrand | tyhicks: 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 /snap | 15:57 |
| tyhicks | jdstrand: if snap-exec ends up getting its own profile, rather than using the profile of the app, then safe/unsafe would be required again | 15:57 |
| jdstrand | tyhicks: that is what I was trying to tease out | 15:57 |
| jdstrand | so today, we have the launcher that is confined calling the wrapper script | 15:58 |
| slangasek | zyga: thanks | 15:58 |
| jdstrand | with 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 |
| jdstrand | s/called/calling/ | 15:59 |
| jdstrand | snap-run doesn't need any provileges | 15:59 |
| zyga | correct | 15:59 |
| jdstrand | privileges beyond calling snap-confine | 15:59 |
| zyga | one complication is that snap-exec will be from the OS snap | 15:59 |
| zyga | not from the snapd package | 15:59 |
| zyga | unless we do bind mount trickery to prevent that but I think that's okay as it is pretty well defined | 16:00 |
| jdstrand | systemd 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 args | 16:00 |
| zyga | jdstrand: it would call snap run | 16:00 |
| jdstrand | snap-confine if from the os snap | 16:00 |
| zyga | jdstrand: all systemd units would just say "snap run $snap.$app --command=..." | 16:01 |
| jdstrand | right, I get that | 16:01 |
| zyga | jdstrand: AFAIR that's the agreement but I may be missing bits | 16:01 |
| zyga | (it's not a big change) | 16:01 |
| jdstrand | I may not have said it clearly that I understood that | 16:01 |
| zyga | but yes, this has to migrate | 16:01 |
| zyga | sorry then :) | 16:01 |
| jdstrand | I'm trying to understand the attack surface | 16:01 |
| jdstrand | systemd unit's attack surface is unchanged | 16:01 |
| jdstrand | is all I meant | 16:02 |
| jdstrand | tyhicks: so, snap-run is resolving its argv[0] to decide how to invoke snap-confine | 16:03 |
| tyhicks | right | 16:05 |
| jdstrand | tyhicks: 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 today | 16:05 |
| tyhicks | agreed | 16:05 |
| tyhicks | jdstrand: the user can still run snap-confine directly | 16:05 |
| jdstrand | right | 16:06 |
| tyhicks | jdstrand: snap-confine will still have to do checks to make sure the arguments passed to it are safe | 16:06 |
| jdstrand | and things running under snap-confine still can't run snap-confine, like today can't run ucl | 16:06 |
| jdstrand | tyhicks: of for sure | 16:06 |
| jdstrand | tyhicks: snap-confine needs to continue to be very carefully written | 16:07 |
| tyhicks | yep | 16:07 |
| jdstrand | and confined | 16:07 |
| tyhicks | agreed | 16:07 |
| jdstrand | but I don't see a reason to confine snap-run | 16:07 |
| zyga | do we have to change anything in the apparmor profile for snap-confine? | 16:07 |
| jdstrand | yes | 16:07 |
| tyhicks | jdstrand: I don't either | 16:07 |
| jdstrand | we can remove some stuff and need to add something to exec snap-exec | 16:07 |
| zyga | jdstrand: I did some experiments and I didn't have to add anything | 16:08 |
| zyga | jdstrand: is it possible that this is covered by /snap/** r, rule? | 16:08 |
| jdstrand | no | 16:08 |
| jdstrand | those would be symlinks | 16:08 |
| jdstrand | to snap-run | 16:08 |
| jdstrand | so you would've had to add a rule for snap-run to run those (which we will not) | 16:09 |
| zyga | I mean snap-confine executing snap-exec | 16:11 |
| zyga | I did an expeirment and I ended up with no permission chages required to do that | 16:11 |
| jdstrand | zyga: 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 |
| zyga | jdstrand: 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 | ||
| jdstrand | I 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 rules | 16:12 |
| === ssweeny-lunch is now known as ssweeny | ||
| zyga | in any case, baby steps, mvo has all of the hard work done and we can see when that lands, what is the next step | 16:13 |
| jdstrand | if you can come up with a reproducer for it working now when it shouldn't, I can walk through what is happening | 16:13 |
| zyga | jdstrand: can you check if the way I patched maintainer scripts to handle the launcher rename is correct? | 16:13 |
| jdstrand | zyga: where is that PR? | 16:13 |
| sethj | well thanks for the help qengho! copy worked and it snapped successfully. | 16:14 |
| zyga | jdstrand: https://github.com/ubuntu-core/snap-confine/commit/3b85e3ec42a2ac837be48f78005d78248903161c | 16:15 |
| sethj | now I just need to figure out how to include a font/theme so the text shows up.. | 16:15 |
| jdstrand | boy | 16:15 |
| jdstrand | I wonder why people aren't using apparmor_parser there | 16:16 |
| zyga | jdstrand: apparmor_parser --remove didn't work because it wanted to parse the now-gone file | 16:16 |
| sborovkov | Hello, 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 |
| zyga | sborovkov: hey | 16:17 |
| zyga | sborovkov: not yet :) | 16:17 |
| zyga | sborovkov: it will be with ubuntu-image I'm working on with a few other brave souls | 16:17 |
| zyga | sborovkov: if you have some spare time help is appreciated | 16:17 |
| zyga | sborovkov: I can point you the way to the code and tell you where we are | 16:17 |
| jdstrand | zyga: it's wrong | 16:18 |
| sborovkov | zyga: understood I don't have a lot of time, need to get application we are doing working on snappy... | 16:18 |
| jdstrand | oh wait | 16:18 |
| zyga | jdstrand: mmm? | 16:18 |
| qengho | sethj: you're welcome! make awesome stuff! | 16:19 |
| zyga | sborovkov: no worries, we'll get to it in ~1/2 weeks | 16:19 |
| didrocks | sergiusens: when I do try to run integration tests, I always have issues with the 15.04 image creation | 16:19 |
| didrocks | sergiusens: any hint? | 16:19 |
| zyga | jdstrand: can you say what is wrong and how it should look like instead? | 16:20 |
| zyga | slangasek: https://github.com/ubuntu-core/snap-confine/pull/15 | 16:21 |
| didrocks | kyrofa: 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 |
| zyga | slangasek: and have a look at https://github.com/ubuntu-core/snap-confine/pull/14 please, I'd like to land it to iterate on top | 16:22 |
| zyga | didrocks: get mvo's udf and stick it in /usr/local/bin | 16:22 |
| didrocks | zyga: I'm pretty sure I tried this, but let me retry | 16:22 |
| zyga | didrocks: same issue as with snapd tests | 16:23 |
| jdstrand | zyga: yes it is wrong. See https://github.com/ubuntu-core/snap-confine/commit/3b85e3ec42a2ac837be48f78005d78248903161c#commitcomment-17681678 | 16:23 |
| didrocks | zyga: still http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash, right? | 16:23 |
| zyga | didrocks: yes | 16:23 |
| * didrocks gives it a try | 16:23 | |
| zyga | jdstrand: ah | 16:23 |
| jdstrand | zyga: what was committed won't match | 16:24 |
| zyga | jdstrand: that was a suggestion from tyhicks :) | 16:24 |
| zyga | jdstrand: I'll commit your version right away | 16:24 |
| zyga | jdstrand: https://github.com/ubuntu-core/snap-confine/pull/16 | 16:26 |
| didrocks | zyga: yeah, so I'm getting: | 16:28 |
| didrocks | INFO:demos_tests.testbed:Creating a snappy image to run the tests. | 16:28 |
| didrocks | building 15.04 core images is no longer supported. Please use the ppa:snappy-dev/tools 15.04 version of this tool | 16:28 |
| didrocks | subprocess.CalledProcessError: Command '['sudo', 'ubuntu-device-flash', '--verbose', 'core', '15.04', '--channel', 'stable', '--output', '/tmp/tmpfu0iwno7/snappy.img', '--developer-mode']' returned non-zero exit status 1 | 16:28 |
| didrocks | with $ sudo which ubuntu-device-flash | 16:28 |
| didrocks | /usr/local/bin/ubuntu-device-flash | 16:28 |
| didrocks | (mvo's version) | 16:28 |
| jdstrand | zyga: thanks, responded | 16:28 |
| zyga | didrocks: well, you still call it with 15.04 bits | 16:28 |
| jdstrand | zyga: also, thank you for getting tyhicks and me up to speed on the the changes | 16:28 |
| * tyhicks scratches his head | 16:29 | |
| didrocks | zyga: snapcraft does… | 16:29 |
| zyga | didrocks: ah, then that's snapcraft to tweak then | 16:29 |
| didrocks | so I don't know how to run my integration tests on 16.04, which is issue | 16:29 |
| tyhicks | I tested that grep command that I provided | 16:29 |
| didrocks | I guess there is a reason they are calling out 15.04 :p | 16:29 |
| tyhicks | I must have pasted in the wrong command :/ | 16:29 |
| zyga | tyhicks: is it possible that you got grep=egrep alias? | 16:29 |
| zyga | anyway, I'm glad this had more eyes on it :) | 16:29 |
| tyhicks | nope | 16:29 |
| tyhicks | I rarely use egrep and definitely didn't use it while testing | 16:30 |
| tyhicks | sorry for the screw up | 16:30 |
| jdstrand | maybe there was a way to do it without egrep... anyway, that one works | 16:30 |
| tyhicks | ah, the + needs to be escaped | 16:30 |
| tyhicks | $ sudo grep '^/usr/bin/ubuntu-core-launcher ([[:alpha:]]\+)$' /sys/kernel/security/apparmor/profiles | 16:31 |
| tyhicks | /usr/bin/ubuntu-core-launcher (enforce) | 16:31 |
| tyhicks | anyways, egrep is fine | 16:31 |
| sergiusens | didrocks no need to run udf for integration tests | 16:31 |
| sergiusens | didrocks for example tests, we support testing on classic | 16:31 |
| sergiusens | elopio ^ | 16:31 |
| didrocks | sergiusens: is there any example for this? | 16:32 |
| sergiusens | didrocks but you can also just --skip-install | 16:32 |
| sergiusens | didrocks for integration_tests just ./runtests.sh integration | 16:32 |
| didrocks | sergiusens: yeah, I just wanted to run them in some way rather than sending that to the machinery everytime :) | 16:32 |
| didrocks | sergiusens: yeah, those are running, so your comment is that one integration test is failing, you think? | 16:32 |
| sergiusens | didrocks I really think so | 16:33 |
| didrocks | that's possible, the fact that we don't fake the terminal size… | 16:33 |
| zyga | joc_: hey, did you get past the testing issues? | 16:34 |
| sergiusens | didrocks `python3 -m unittest -v -b run integration_tests.test_list_plugins` | 16:34 |
| didrocks | sergiusens: ah yeah, there is one :) | 16:34 |
| didrocks | sergiusens: yep, will fix it and push | 16:34 |
| joc_ | zyga: yes thanks, sorted now | 16:34 |
| didrocks | sergiusens: I need to think how we can have it in an terminal-independent size though | 16:34 |
| didrocks | sergiusens: as it will be different on jenkins | 16:34 |
| sergiusens | didrocks the ones that require u-d-f are the "demo" tests fwiw | 16:34 |
| didrocks | sergiusens: yeah, and "tour" one (soon ;)) | 16:35 |
| sergiusens | didrocks `python3 -m demos_tests --help` | 16:35 |
| didrocks | ok, so --skip-install | 16:35 |
| didrocks | sergiusens: I'll fix and try to fine something to not be terminal-size dependent on the integration one | 16:36 |
| sergiusens | didrocks or `SNAPCRAFT_FROM_INSTALLED=1 python3 -m demo_tests` | 16:36 |
| sergiusens | didrocks that will install to classic | 16:36 |
| didrocks | oh nice :) | 16:36 |
| sergiusens | didrocks which is what we do in debian/tests/demostests | 16:36 |
| didrocks | ah, for the adt testbed | 16:36 |
| sergiusens | yup | 16:37 |
| didrocks | sergiusens: 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 run | 16:45 |
| zyga | jdstrand, tyhicks: so how shall we call the new backend "modprobe" backend? | 16:47 |
| tyhicks | zyga: is that something we need? I don't know if I've heard about those plans yet | 16:54 |
| kyrofa | didrocks, are you still around? | 17:11 |
| sergiusens | didrocks maybe `isatty` and affect the result accordingly | 17:21 |
| sergiusens | but let's see | 17:22 |
| jdstrand | tyhicks: I'll explain. remember how iptable_filter and ip6table_filter don't autoload but once loaded netfilter modules load fine? | 17:35 |
| jdstrand | tyhicks: 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 not | 17:36 |
| jdstrand | tyhicks: 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 useful | 17:37 |
| jdstrand | tyhicks: snapd will then drop a file into /etc/modules-load.d for reboots and load the modules on first connection | 17:38 |
| jdstrand | tyhicks: in this manner, snaps niether get to specify the modules to load themselves (or there options) nor have SYS_MODULE, etc | 17:38 |
| jdstrand | tyhicks: like with security policy, dbus policy and udev rules, snapd has a hardcoded list of what it will make sure is loaded | 17:39 |
| jdstrand | tyhicks: as it turns out, this is likely useful for modem-manager as well as firewall-control | 17:40 |
| zyga | tyhicks: yes, probably for modem manager | 17:40 |
| jdstrand | tyhicks: 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 experience | 17:41 |
| jdstrand | tyhicks: 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 requested | 17:42 |
| jdstrand | zyga: 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 system | 17:43 |
| zyga | jdstrand: I'll think about it, a single file might be easier on SD cards and it's all the same technically (otherwise) | 17:44 |
| jdstrand | zyga: that said, garbage collection would be something to consider (removing those files on snap disconnect) and perhaps that isn't the best approach | 17:44 |
| jdstrand | (just some random thoughts I had) | 17:44 |
| zyga | jdstrand: on disconnect or connect we always rewrite the file after computing the content it has to have | 17:44 |
| zyga | jdstrand: 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 here | 17:44 |
| jdstrand | that's true | 17:45 |
| jdstrand | probably actually easier in this case | 17:45 |
| jdstrand | zyga: I think I prefer 'kernelModules' instead of 'modprobe' | 17:46 |
| * tyhicks was lunching | 17:47 | |
| tyhicks | jdstrand: so snaps will not be able to provide their own modules - it'll only be modules shipped by the kernel snap? | 17:49 |
| jdstrand | tyhicks: 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 load | 17:50 |
| jdstrand | tyhicks: and snaps can't influence what is loaded or how | 17:51 |
| nimoov | exit | 17:52 |
| tyhicks | jdstrand: ohhh, I understand now | 17:54 |
| === oparoz_ is now known as oparoz | ||
| ogra_ | jdstrand, zyga, please dont forget about possible module options ;) | 18:10 |
| jdstrand | I mentioned that. at first it is just a list. when there is something that needs options, we can expand | 18:11 |
| zyga | jdstrand: ay, will do | 18: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 mounted | 19: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 |
| sergiusens | zyga ^ | 19:22 |
| sergiusens | seems to be something widespread | 19:22 |
| sergiusens | maybe we should add mention of your branch to /topic | 19:23 |
| thibran | hello, someone there? | 22:17 |
| sergiusens | thibran what's up? | 22:19 |
| thibran | I solved a snap bitsize bug | 22:19 |
| thibran | and now I would like to get it merged, but have some questions | 22:20 |
| thibran | to sign the contributor agreement, I need a 'project contact' | 22:21 |
| thibran | how do I get one? | 22:22 |
| sergiusens | thibran let me check, but for starters you can start getting the PR up | 22:22 |
| sergiusens | kyrofa you've been dealing with CLAs lately, where should it go to? | 22:23 |
| sergiusens | thibran a review is not blocked by the CLA | 22:23 |
| thibran | k | 22:24 |
| thibran | than I upload the code | 22:25 |
| sergiusens | thibran yeah, get your toes in technically first, leave the paper work for last :-) | 22:26 |
| thibran | https://github.com/snapcore/snapd/pull/1249 | 22:29 |
| thibran | I hope I got the i18n stuff right, my compiled bin works | 22:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
