| === JamesTait is now known as Guest2387 | ||
| === devil is now known as Guest83087 | ||
| === Guest83087 is now known as devil__ | ||
| === dasjoe_ is now known as dasjoe | ||
| === devil is now known as Guest51142 | ||
| === tsimonq2alt is now known as tsimonq2- | ||
| === tsimonq2- is now known as tsimonq2 | ||
| === chihchun_afk is now known as chihchun | ||
| stgraber | I just uploaded a new version of lxd to the store, no change to policy, would be nice if it could go through soon, we've had a few folks complaining that 0.21 was a bit dated (by about 6 months :)) | 07:04 |
|---|---|---|
| stgraber | jdstrand: ^ | 07:04 |
| dholbach | good morning | 07:41 |
| didrocks | good morning dholbach | 07:41 |
| dholbach | salut didrocks | 07:48 |
| noizer | good morning! | 08:05 |
| noizer | How can I see that my custom seccomp and apparmor file is applied to my snap? | 08:33 |
| noizer | jdstrand: can I see that my custom seccomp and apparmor file is applied to my snap? | 08:59 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mvo | willcooke, dpm: good news, the most recent snappy upload to xenail (should hit xenial-proposed with the next publishing) will have unity7 integration, i.e. nothing (hopefulyl) more to do. install cap-test and it will show up in dash searches etc (make sure you restart your session once after updating snappy because it installs a Xsession.d file for this). I'm very excited! | 09:18 |
| willcooke | mvo \m/ | 09:19 |
| willcooke | mvo, thank you!!! | 09:19 |
| willcooke | Trevinho, ^^ | 09:19 |
| dpm | mvo, awesome! I just managed to upload calculator to the store, for which I included the .desktop file support. I'll go ahead and test that too! | 09:19 |
| dpm | just literally a few minutes ago | 09:19 |
| dpm | so I'll give unity 7 integration a spin once I see the new snappy package in the archive | 09:20 |
| mvo | dpm: yeah, xenial-proposed, there is a build failure on powepc that I look at next so it won't promote right away | 09:23 |
| dpm | ok | 09:23 |
| mvo | dpm: but you can directly grab the two debs from LP if you are eager to test :) | 09:23 |
| mvo | dpm: plus the updated ubuntu-core-launcher but that will come as a normal update | 09:23 |
| dpm | mvo, thanks. I am eager :), but I think I'll wait if it's just a matter of hours, which might save me some extra fiddling | 09:24 |
| zyga | o/ | 09:26 |
| zyga | noizer: yes, look at /var/lib/snappy/{apparmor,seccomp} | 09:27 |
| mvo | dpm: you are eager and WISE at the same time :) | 09:27 |
| dpm | lol | 09:27 |
| noizer | zyga: ok i was looking at the correct files but with security-policy it doesn't work. http://pastebin.com/DmAdrhU3 | 09:30 |
| noizer | zyga: do you have any clue why my apparmor and seccomp files doesn't apply to my snap? | 09:36 |
| dpm | mvo, how do updates to the ubuntu-core snap happen on the desktop? It is a bit like magic to me. I've tried "sudo snappy upgrade ubuntu-core" a few times and it tells me there are no new versions. Yet every now and then I see it updated automagically when I run "snappy list --verbose". So I'm not sure if this is something that needs to be manually maintained (and how?) or is autoupdated | 09:37 |
| zyga | noizer: s/slots/plugs/ -- use the lastest released snapcraft (just released yesterday AFAIR) and it should work | 09:37 |
| zyga | noizer: good luck | 09:37 |
| zyga | noizer: sorry about the swap, it's stabilizing now | 09:37 |
| noizer | Just switch between slots and plugs? | 09:37 |
| zyga | noizer: you'll have access to many useful interfaces next week (+1/-1 image release) | 09:37 |
| zyga | ye0 | 09:38 |
| zyga | yes | 09:38 |
| noizer | But to be honest i think i need an unconfined snap just for my thing. So i try to make it by changing the apparmor and seccomp file | 09:39 |
| Trevinho | mvo: great to hear | 09:42 |
| noizer | zyga ok thx with plugs it works to edit the apparmor just need to see that mine apparmor is correct but now it fails | 09:50 |
| zyga | noizer: sorry, I don't get the last part ;; what failed? | 09:52 |
| noizer | wait i got the following error when I'm installing my snap with a custom apparmor | 09:56 |
| noizer | zyga: error, unexpected TOK_ID, expecting TOK_END_OF_RULE | 09:57 |
| noizer | zyga: thats an error of mine apparmor | 10:01 |
| zyga | noizer: yeah, I think your apparmor is just wrongly spelled | 10:02 |
| zyga | noizer: btw there's an unconfined template that you can reference | 10:02 |
| zyga | noizer: look at your desktop | 10:03 |
| ysionneau | ah, snapcraft has been updated yesterday with the plugs/slots switch o/ | 10:03 |
| ysionneau | cool | 10:04 |
| zyga | noizer: dpkg -L ubuntu-core-security-apparmor | 10:04 |
| zyga | ysionneau: yep | 10:04 |
| ysionneau | hmm would there be any interest in chrooting into $SNAP (after doing some bind mounts) ? | 10:48 |
| ysionneau | I mean, before running an app | 10:48 |
| zyga | ysionneau: why? | 10:48 |
| ysionneau | that would for instance allow the app to use hard coded absolute paths | 10:48 |
| zyga | ysionneau: and not allowed to do many other things | 10:48 |
| zyga | ysionneau: I don't think this is needed | 10:48 |
| ysionneau | this could be useful for some apps I think, so that you don't have much work to "port" them to snappy | 10:49 |
| ysionneau | instead of having to rewrite lots of code | 10:50 |
| ogra_ | i doubt chroot will be allowed by seccomp | 10:50 |
| ysionneau | That could be an option in the snapcraft.yaml like "chroot: yes" | 10:50 |
| ogra_ | bu tthat doesnt stop you from shipping a full rootfs if you want and bend the env to completely use it | 10:52 |
| ogra_ | which would be close to a chroot | 10:52 |
| ysionneau | what do you mean by "bend the env" ? | 10:54 |
| ysionneau | I'm not sure there is a trick to allow an app to write to "/var/lib/<something>" | 10:54 |
| ysionneau | other than chrooting | 10:54 |
| ogra_ | well, pretty much what the ubuntu-core-launcher does already but also make it use the shipped toolchain, linker, libc | 10:55 |
| ysionneau | or maybe an LD_PRELOAD to hook open() | 10:55 |
| ogra_ | as long as $SNAP and $SNAP_DATA are on the same device you might be able to use hgardlinks for writable bits and dirs | 10:56 |
| ysionneau | but, whatever I do, /var/lib/ will stay read-only | 10:57 |
| ysionneau | that's my main issue | 10:58 |
| ogra_ | change it to ./var/lib then :) | 10:58 |
| ogra_ | (indeed that might mean to recompile the world ... i didnt say its easy ;) ) | 10:59 |
| ysionneau | the thing is, there are lots of occurence of this type of issues in the different softwares I want to "port" to snappy | 11:01 |
| ysionneau | so I'm not a big fan of this solution | 11:01 |
| ysionneau | (by solution here I mean pushing fixes in the code everywhere to use env VAR instead of hard coded absolute paths) | 11:01 |
| ogra_ | indeed ... | 11:02 |
| ogra_ | dont you need to just re-do the linker path though ? | 11:02 |
| noizer | zyga: the unconfined template can he make some calls to /snaps/bin/... ? | 11:04 |
| ogra_ | noizer, unconfined apps have all the power a natively installed deb would have | 11:04 |
| noizer | so he can exectute all things? | 11:05 |
| ysionneau | 12:02 < ogra_> dont you need to just re-do the linker path though ? < I'm talking about normal "open()" here, not library paths issues | 11:05 |
| ogra_ | (its just the paths and workdir that are different then ... ) | 11:05 |
| ysionneau | or maybe I don't understand what you propose :o | 11:05 |
| ogra_ | oh, open() in your code, i see | 11:05 |
| ogra_ | well, if you cant get around that one, you can always use lxd or docker | 11:05 |
| ysionneau | ah, interesting! | 11:06 |
| ogra_ | that equivalent to a chroot i'd say (just a bit more secure) | 11:06 |
| ysionneau | thanks! | 11:06 |
| ysionneau | will think about that :) | 11:06 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| zyga | noizer: maybe not | 11:26 |
| zyga | noizer: it's not so simple | 11:26 |
| zyga | noizer: you cannot change aa profile anyway *AFAIR* | 11:26 |
| noizer | zyga: do you mean with AFAIR | 11:27 |
| zyga | noizer: as far as I remember | 11:27 |
| zyga | noizer: it's not identical to really unconfined | 11:27 |
| zyga | noizer: but it very broadly permissive | 11:27 |
| noizer | zyga: What I now did is took an empty apparmor and try to execute an binary from /snaps/bin/ | 11:28 |
| noizer | I see it is then possible to execute the binary | 11:28 |
| noizer | zyga: But then i see the following error: | 11:29 |
| noizer | error: /bin/sh: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory | 11:29 |
| zyga | noizer: I don't think that will work | 11:29 |
| zyga | noizer: try doing what I said | 11:30 |
| zyga | noizer: use old-security and unconfined template | 11:30 |
| noizer | ok | 11:30 |
| noizer | zyga: then i should be able to execute the binary? | 11:31 |
| noizer | zyga: got then following error: aa_change_onexec failed with -1. errmsg: Permission denied | 11:32 |
| ogra_ | noizer, why didnt you fiollow jdstrand's advise from yesterday ? | 11:39 |
| ogra_ | *advice | 11:39 |
| zyga | noizer: that's exactly what I said | 11:39 |
| zyga | noizer: you cannot change aa profiles | 11:39 |
| zyga | ogra_: what was the advice? | 11:39 |
| ogra_ | zyga, i gave him an existing (outdated) unconfined snapcraft.yaml and jamie gave all hints to adapt it to the new interfaces setup | 11:40 |
| ogra_ | there is no need to fiddle with apparmor files | 11:41 |
| zyga | ogra_: i suspect that unless there were explicit changes somewhere you still cannot (even unconfined) run other snaps from your snap | 11:41 |
| ogra_ | why not ? | 11:42 |
| zyga | ogra_: it's not allowed, even for unconfined programs (that are really confined but broadly permissive) | 11:42 |
| ogra_ | unconfined has the same powers as a deb ... just that all paths and the workdirs are completely mangled | 11:42 |
| zyga | ogra_: I went through this issue a few times | 11:42 |
| zyga | ogra_: nope | 11:42 |
| zyga | ogra_: that is not true | 11:42 |
| ogra_ | i have an unconfined debootstrap that woprks just fine | 11:42 |
| zyga | ogra_: unconfined still gives you aa profile and seccomp profile and a cgroup for devices | 11:42 |
| zyga | ogra_: it's not the same as running from the ssh shell | 11:42 |
| ogra_ | i dont see why an unconfined systemctl shouldnt be able to control services for example | 11:43 |
| zyga | ogra_: because that's what's spelled out in unconfined, we'd have to make super-unconfined that has extra powers | 11:43 |
| zyga | ogra_: FYI I'm not arguing with you; I'm just telling you how it really works today | 11:43 |
| ogra_ | so unconfined changed ? | 11:43 |
| zyga | ogra_: no, it was always like that | 11:43 |
| ogra_ | with the last iteration | 11:43 |
| zyga | ogra_: unconfined != not confined in practice | 11:43 |
| ogra_ | right | 11:44 |
| zyga | ogra_: it was like that in 15.04 | 11:44 |
| zyga | ogra_: and I suspect still is in 16.04 | 11:44 |
| ogra_ | well, unconfined in 15.04 lets me do everything with my system | 11:44 |
| ogra_ | i dont think your seccomp assumption is true | 11:44 |
| zyga | ogra_: it's 100% true for aa | 11:44 |
| ogra_ | but aa wont be used in unconfined | 11:44 |
| zyga | ogra_: you cannot load another aa profile while running unconfined profile | 11:44 |
| zyga | ogra_: it _is_ | 11:45 |
| zyga | ogra_: 100% guaranteed it is | 11:45 |
| zyga | ogra_: we've been through this many times in cert | 11:45 |
| ogra_ | you can not load another aa profile because aa_exec isnt in use at all | 11:45 |
| zyga | ogra_: I don't think this is true, in any case, as unconfined snap, you cannot run other snap's apps | 11:45 |
| ogra_ | no, but youz can run thes system systemctl | 11:46 |
| zyga | ogra_: sure but the error that noizer saw is exactly what I was describing | 11:47 |
| zyga | ogra_: not related to systemctl | 11:47 |
| dholbach | dpm, so snapcraft seems to do just what click-review expects: | 11:49 |
| dholbach | snapcraft/commands/snap.py: mksquashfs_args = ['-noappend', '-comp', 'xz', '-all-root', '-no-xattrs'] | 11:49 |
| dholbach | and for snappy it's http://paste.ubuntu.com/15340831/ | 11:51 |
| dholbach | the latter seems to miss "-all-root" | 11:51 |
| dholbach | that was in snap/squashfs/squashfs.go, but in obj-x86_64-linux-gnu/src/github.com/ubuntu-core/snappy/pkg/snapfs/pkg.go it has the "-all-root" option | 11:52 |
| dholbach | mvo, is there a reason that in one of the mksquashfs incantations the "-all-root" option is missing? | 11:53 |
| zyga | dholbach: (mvo went for lunch, may reply with lag) | 11:53 |
| dpm | dholbach, then perhaps an issue in click-review-tools? As I built the app with snapcraft, and I *think* LP does it with snapcraft as well | 11:53 |
| dholbach | zyga, thanks | 11:54 |
| ogra_ | dholbach, --all-root means that all your files are chowned to root inside the squashfs ... probably not wanted in all cases | 11:54 |
| dholbach | dpm, it might, yes | 11:54 |
| ogra_ | (definitely not for os snaps for example) | 11:55 |
| dholbach | dpm, I just thought I'd check all incantations first :) | 11:55 |
| dpm | makes sense, thanks dholbach :) | 11:55 |
| noizer | zyga: So as conclusion it is not possible at all what I want even when i get my custom aa? | 11:56 |
| noizer | zyga: or does i understand it completly wrong? | 11:57 |
| zyga | noizer: you'd have to talk to jdstrand and ask if it is possible to use a custom template to unlock running other snaps from "unconfined" snap | 12:01 |
| zyga | noizer: technically it is possible, it's just the matter of having the right template or the right extra bit in an existing template | 12:02 |
| zyga | noizer: but jdstrand will know how (though he's super-busy so you might not get a quick answer) | 12:02 |
| dholbach | jdstrand, I'm still seeing http://paste.ubuntu.com/15340881/ - do you know what the issue is? | 12:05 |
| dholbach | that's with r605 | 12:06 |
| dholbach | dpm, it might be https://bugs.launchpad.net/ubuntu/+source/click-reviewers-tools/+bug/1555305 | 12:17 |
| ubottu | Launchpad bug 1555305 in click-reviewers-tools (Ubuntu) "resquashfs test fails if snap has symlinks" [High,Confirmed] | 12:17 |
| dholbach | http://paste.ubuntu.com/15340912/ is what I tried | 12:18 |
| dholbach | http://paste.ubuntu.com/15340914/ was the result | 12:18 |
| dholbach | dpm, so it sounds like it's a known problem with snaps containing symlinks(?) | 12:19 |
| dholbach | the mksquashfs arguments cited in the error message might be a red herring | 12:19 |
| kyrofa | Good morning! | 12:26 |
| dholbach | hey kyrofa | 12:28 |
| kyrofa | lool, looks like you pinged me yesterday, you around? | 12:28 |
| kyrofa | Hey dholbach, how are you? | 12:28 |
| dholbach | good good - how about you? :) | 12:28 |
| kyrofa | Not bad! Been out the last few days, felt nice | 12:31 |
| kyrofa | Though now I have ~300 emails to slog through | 12:32 |
| dholbach | good luck with those :) | 12:33 |
| dpm | dholbach, weird, as the errors weren't triggered with the first rev1 upload | 12:35 |
| dpm | thanks for digging it out | 12:36 |
| dholbach | dpm, let me doublecheck - it could be that click-reviewers-tools didn't have the check at the time :-) | 12:36 |
| === chihchun is now known as chihchun_afk | ||
| dpm | ok! | 12:40 |
| dholbach | dpm, looks like the old snap has the same problem | 12:42 |
| dpm | strange, no errors were triggered on the rev1 upload | 12:42 |
| noizer | zyga: ok so I don't need to change the apparmor from my snap because there are some other things thats needs to be done? | 12:46 |
| zyga | noizer: no, you didn't understand what I said; I think it *is* possible technically but you have to figure out the right aa syntax by youreself | 12:55 |
| zyga | noizer: I don't know how to do this FYI | 12:56 |
| noizer | zyga ok thx in advance | 12:56 |
| ogra_ | mvo, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ ... done ... all os and kernel snaps are now published there | 13:11 |
| ogra_ | (now onward to creating the dragonboard kernel.snap ... ) | 13:12 |
| dholbach | dpm, sorry didn't see your reply... as I said earlier: I think back when you uploaded rev1, click-reviewers-tools probably didn't have this check - it was added quite recently | 13:19 |
| dpm | dholbach, ah, thanks. I had seen it, but somehow I hadn't connected the two. I'll blame it to multitasking rather than admitting I misread it :) | 13:20 |
| dholbach | no worries :) | 13:20 |
| dholbach | I just checked - there were 9 days between the uploads - an eternity in snappy's world :-P | 13:21 |
| mvo | ogra_: nice | 13:23 |
| * ogra_ tries a test build | 13:23 | |
| ogra_ | ubuntu@localhost:~$ snappy list | 13:24 |
| ogra_ | Name Date Version Developer | 13:24 |
| ogra_ | canonical-pc 2016-02-02 3.0 canonical | 13:24 |
| ogra_ | canonical-pc-linux 2016-03-10 IOTfGNaBRCTJ sideload | 13:24 |
| ogra_ | ubuntu-core 2016-03-10 IOTfGOFdgPKF sideload | 13:24 |
| ogra_ | boots :) | 13:24 |
| mvo | dholbach: that are the 9 days in which we rewrote it in hylang | 13:24 |
| dholbach | mvo, good to hear you're focusing on the important stuff :-P | 13:25 |
| ogra_ | hylang ? not perl ? | 13:26 |
| ogra_ | hmm, webdm still not proted to interfaces ? | 13:27 |
| ogra_ | funny how all snaps are pretty exactly 20MB smaller than their tarball equivalents ... that seems to be constant, not actually a percentage or anything | 13:29 |
| techraf | hello, I'm new here | 13:43 |
| ogra_ | hello techraf | 13:44 |
| kyrofa | Hey techraf, welcome! | 13:44 |
| techraf | I was trying to create example snaps -> with snapcraft 2.0 I could "snapcraft snap" and had .snap in result | 13:44 |
| techraf | the same "snapcraft snap" 1.0 does not produce anything | 13:45 |
| techraf | at least it does not create .snap | 13:45 |
| kyrofa | techraf, right, the command-line is a little different in 1.x | 13:45 |
| kyrofa | techraf, try just `snapcraft` | 13:45 |
| kyrofa | techraf, the actual step in 1.x is called "assemble," but calling snapcraft with no arguments is equivalent | 13:46 |
| techraf | snapping... | 13:46 |
| kyrofa | techraf, `snapcraft --help` might be useful | 13:47 |
| kyrofa | techraf, compare the output between versions, you'll see similarities | 13:47 |
| techraf | will do, success so far | 13:48 |
| techraf | you helped me much, thank you | 13:48 |
| kyrofa | techraf, any time :) | 13:49 |
| zyga | jdstrand: hey | 13:50 |
| zyga | jdstrand: I've send you a ping on github for a code review | 13:51 |
| zyga | jdstrand: it's not urgent but I'd love if we could spend a moment to go over the code there | 13:51 |
| zyga | jdstrand: and ensure it's all good | 13:51 |
| kyrofa | didrocks, how are things going for you this week? Examples still coming along? | 13:54 |
| jdstrand | zyga: sure thing | 14:04 |
| jdstrand | dholbach: can you give me the snap? | 14:06 |
| jdstrand | noizer: hey, as mentioned, you are pretty outside of snappy atm and this is the snappy channel. since your questions are now of the form "how to profile with apparmor" I suggest taking a look at 'man apparmor.d' and bringing your questions up on #apparmor on oftc | 14:08 |
| jdstrand | noizer: also, I saw your paste and you need to use 'plugs' instead of 'slots' | 14:10 |
| jdstrand | noizer: be sure you are using snapcraft 2.4 | 14:11 |
| noizer | jdstrand I am using now snapcraft 2.4 | 14:11 |
| noizer | jdstrand: I am trying some things but now without any success xD | 14:12 |
| jdstrand | noizer: I would start with using plugs instead of slots, otherwise you get the default confinement. also, you can see what confinement is bing used in /var/lib/snappy/apparmor/profiles | 14:15 |
| jdstrand | being | 14:15 |
| jdstrand | oh, that was in the wiki page I gave you yesterday | 14:16 |
| jdstrand | dpm: you asked for someone to push the calculator through. did that happen? when I looked it wasn't showing up for review. if it didn't happen, can you request a manual review? | 14:17 |
| noizer | jdstrand: I saw that today and now I am using plugs. and my apparmor changes | 14:19 |
| jdstrand | ok good. now you are in the realm of how to profile | 14:19 |
| jdstrand | that is where #apparmor can help | 14:19 |
| noizer | Ok is that from snappy developers too? | 14:20 |
| jdstrand | noizer: that is what I was saying you should take to #apparmor on oftc | 14:22 |
| jdstrand | that has apparmor developers and community | 14:22 |
| dholbach | jdstrand, I did a fresh checkout from c-r-t and ran ./bin/click-review on the .snap from https://myapps.developer.ubuntu.com/dev/click-apps/4630/rev/2/ | 14:39 |
| dholbach | with the installed version (0.38 from xenial) it does not crash | 14:40 |
| zyga-phone | jdstrand: thanks | 14:41 |
| jdstrand | mvo: are paths like this intended: /etc/systemd/system/snaps-cap\x2dtest.sideload-LSXRFfhCCLCY.mount | 14:49 |
| jdstrand | mvo: the '\x2d' is causing bzr (etckeeper) to crash | 14:49 |
| jdstrand | and it isn't clear why '-' is being escaped there and nowhere else | 14:50 |
| jdstrand | unless you are using '-' as a delimiter, in which case I would suggest '_', since that isn't an allowable char in the snap package name | 14:50 |
| jdstrand | (or some other not allowed char) | 14:51 |
| jdstrand | dholbach: when you checked out crt and did ./bin/click-review, did you set PYTHONPATH? if not, you need to: PYTHONPATH=./ ./bin/click-review /path/to/snap | 14:52 |
| dholbach | jdstrand, oh? | 14:53 |
| dholbach | since when? | 14:53 |
| jdstrand | always | 14:53 |
| zyga-phone | jdstrand: sounds like misisng setup.py --develop in hacking docs | 14:53 |
| jdstrand | otherwise you end up using what is in /usr | 14:53 |
| dholbach | hohum | 14:53 |
| zyga-phone | dholbach: this is typical to all python code | 14:53 |
| dpm | jdstrand, dholbach helped me on this. I hadn't realized last night that I needeed to explicitly say "Request manual review". The apps are now published. We still don't know what the issue with the checksum is, but at least the published apps work as opposed to the old ones not working after the plugs<->slots change | 14:54 |
| dholbach | jdstrand, confirmed | 14:54 |
| dholbach | thanks | 14:54 |
| jdstrand | dpm: you went offline before I could respond. the checksum issue is https://bugs.launchpad.net/ubuntu/+source/click-reviewers-tools/+bug/1555305 | 14:55 |
| ubottu | Launchpad bug 1555305 in click-reviewers-tools (Ubuntu) "resquashfs test fails if snap has symlinks" [High,Confirmed] | 14:55 |
| noizer | jdstrand pff there aren't many people on #apparmor | 14:55 |
| jdstrand | noizer: on OFTC? | 14:55 |
| jdstrand | dpm: I have disabled the test for now until I can fix that | 14:56 |
| dpm | ok, thanks | 14:56 |
| noizer | jdstrand: sorry did some typo | 14:56 |
| jdstrand | dholbach: ok, with PYTHONPATH, I can confirm it as well | 14:57 |
| jdstrand | dholbach: I don't recall, did you file a bug for this? if not, don't worry about it | 14:58 |
| mvo | jdstrand: I think the pats are the result of calling systemd-escape | 15:00 |
| jdstrand | hrm | 15:04 |
| jdstrand | I guess I'll file a bug against bzr and workaround it | 15:04 |
| didrocks | kyrofa: hey! More busy with the developer website content. On the examples, I'm waiting for the poll feedback we launched with dholbach first to see if people like them :) | 15:08 |
| kyrofa | didrocks, awesome! | 15:08 |
| kyrofa | dholbach, how is that poll coming? I'm looking forward to seeing that myself | 15:10 |
| jdstrand | dholbach: oh, heh, nm, I typoed PYTHONPATH. it works fine here, so nothing to do | 15:11 |
| zyga-phone | jdstrand: I'll dive into more coding, ping me when you have a moment to go through that diff | 15:17 |
| kyrofa | dholbach, do the review tools catch symlinks that point outside the snap? | 15:17 |
| dholbach | kyrofa, yes | 15:20 |
| jdstrand | zyga-phone: yeah, haven't gotten out of email and irc pings yet | 15:20 |
| kyrofa | dholbach, ALL of them, no allowed whitelist or anything? | 15:20 |
| dholbach | kyrofa, there's a whitelist | 15:21 |
| kyrofa | dholbach, oh darn, that throws a wrench into my plans. Can I have a look at that list? | 15:22 |
| elopio | hey kyrofa, you are back. I'm sorry, I assume we wouldn't have standup today. | 15:23 |
| kyrofa | elopio, I am indeed! And that's okay :) | 15:23 |
| elopio | I'll make it on time tomorrow. | 15:23 |
| dholbach | kyrofa, http://bazaar.launchpad.net/~click-reviewers/click-reviewers-tools/trunk/view/head:/clickreviews/common.py#L631 | 15:23 |
| kyrofa | dholbach, excellent thank you :) | 15:24 |
| kyrofa | elopio, how has the week been going? | 15:24 |
| kyrofa | I finally made it through my emails, looks like we cranked out 2.4, nice | 15:24 |
| elopio | kyrofa: yes, thinks are looking good. I'm still blocked on the closed ports to test the http examples, but most of the tests are running now. | 15:27 |
| elopio | sergio is doing good progress on the kernel, he said it's almost ready. | 15:27 |
| kyrofa | elopio, yeah I just looked through it | 15:28 |
| kyrofa | elopio, no tests to speak of, but the code is looking pretty good | 15:29 |
| kyrofa | elopio, and looks like you were able to greatly speed up travis tests, eh? Needs a rebase though | 15:34 |
| === ken__ is now known as kenvandine | ||
| elopio | kyrofa: yes, it's running again. | 15:43 |
| elopio | I'm sad because we are no longer running on xenial, but I hope they will just update the machine in april. | 15:43 |
| kyrofa | elopio, don't get your hopes up-- I think they still run on 12.04 by default unless you request trusty | 15:45 |
| kyrofa | elopio, I get the impression that their architecture is very tightly integrated | 15:45 |
| elopio | they are still calling them beta, the trusty machines... | 15:47 |
| elopio | but it's GCE. I see no possible way it will be different to manage a xenial in there. | 15:47 |
| elopio | I'm also sure they can prove me wrong :) | 15:48 |
| kyrofa | elopio, heh | 15:49 |
| varaindemian | is ubuntu trying to simlify the building process from source code? Is it trying to make something like "ports"/ABS-arch? | 16:00 |
| zyga | varaindemian: no | 16:01 |
| varaindemian | zyga, is ubuntu core a different os or is part of ubuntu? | 16:02 |
| ogra_ | it is a new type and setup of ubuntu (not using apt/dpkg in the runnung system, special filesystem setup, all the shiny new features of teh snappy package manager) but still ubuntu | 16:03 |
| genii | varaindemian: http://www.ubuntu.com/internet-of-things | 16:04 |
| varaindemian | ogra_, so ubuntu 16.04 lts won't have the snappy sotre | 16:08 |
| varaindemian | store | 16:08 |
| varaindemian | ogra_, right? | 16:08 |
| ogra_ | the snappy packagemanager will be shipped in ubuntu 16.04 installs | 16:08 |
| ogra_ | so you can indeed use snap packages from the store | 16:08 |
| varaindemian | ogra_, oh, so I cna build packages for my own system right? | 16:09 |
| ogra_ | (on these systems thats additionally to dpkg packages) | 16:09 |
| ogra_ | yeah | 16:09 |
| ogra_ | you can use snapcraft to package up your github projects as snaps | 16:09 |
| ogra_ | (or whatever other projects yoou have) | 16:09 |
| varaindemian | ogra_, nice and the building process from source code will be simplified? | 16:09 |
| ogra_ | yeah, snapcraft makes that pretty automated | 16:09 |
| varaindemian | so cool | 16:10 |
| ogra_ | you create a yaml file that describes the build and just run the snapcraft tool in your workdir ... out comes a snap :) | 16:10 |
| varaindemian | ogra_, Really really interesting. How would that differ compared to an os that uses "ports like" system? | 16:12 |
| ogra_ | dunno, i never used a "ports like" system | 16:12 |
| ogra_ | what you deal with are binary packages though ... the store also doesnt care about source (you can even snap up complete binary blobs if you want) | 16:13 |
| ogra_ | snapcraft just makes it easy to create them but source isnat mandatory | 16:13 |
| ogra_ | *isnt | 16:13 |
| ssweeny | jdstrand, I'm trying to build location-service in snappy for 16.04 and it seems to want to link against libapparmor.a rather than the shared library. As best I can tell when I stage apparmor-dev in snapcraft something isn't running that sets up the unversioned .so symlink in /lib/<triplet>. Have you seen this sort of thing before? | 16:16 |
| === JanC_ is now known as JanC | ||
| ssweeny | is it that staged packages are just unpacked and no scripts or triggers are run? | 16:17 |
| kyrofa | ssweeny, you got it | 16:18 |
| kyrofa | ssweeny, they're only unpacked | 16:18 |
| kyrofa | ssweeny, no postinst, etc | 16:18 |
| ssweeny | hm | 16:18 |
| ssweeny | thanks kyrofa. is there some easy way to manipulate the staged tree as part of the build? i.e. remove a file or add a symlink | 16:19 |
| ssweeny | this is the only library that has an issue for me while building | 16:19 |
| kyrofa | ssweeny, I typically install the -dev packages as build-packages and only include the runtime packages as stage-packages | 16:19 |
| kyrofa | ssweeny, have you tried that? | 16:20 |
| ssweeny | kyrofa, I did try that but the build step was looking for stuff in stage | 16:20 |
| ssweeny | so I assumed I was wrong | 16:20 |
| jdstrand | ssweeny: I haven't no. I imagine I am going to run into this on my next snappy-debug upload though, so I'm interested in what comes of this | 16:21 |
| ssweeny | kyrofa, so the theory of operation so to speak is the build-deps go in build-packages and runtime deps go in stage-packages. | 16:21 |
| ssweeny | i can try it again but I'm certain it was looking for headers in stage/include/foo | 16:22 |
| kyrofa | ssweeny, indeed. Not to say that having -dev in stage would hurt anything, but it bloats your snap unless you exclude them | 16:22 |
| ssweeny | right | 16:22 |
| ssweeny | ok I'll try it again. Maybe I was hitting a bug :) | 16:23 |
| ssweeny | thanks kyrofa | 16:23 |
| ssweeny | jdstrand, i'll let you know what I find | 16:23 |
| kyrofa | ssweeny, yeah let me know as well | 16:23 |
| ysionneau | do I understand correctly that it's not yet possible for an app to bind a unix socket? | 16:30 |
| ysionneau | the unix-listener policygroup is marked as # TODO | 16:32 |
| ysionneau | and I get a "denied" for this: Mar 10 16:24:48 localhost kernel: [182550.868636] audit: type=1400 audit(1457627088.221:21): apparmor="DENIED" operation="bind" profile="wifid.sideload_foreground_LSbLDVfnJSlm" pid=2988 comm="ld-linux-armhf." family="unix" sock_type="stream" protocol=0 requested_mask="bind" denied_mask="bind" addr="@776966696400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 | 16:32 |
| jdstrand | ysionneau: on 16.04 all of this is in flux. unix-listener is actually going away and there will be a proper interface for this | 16:33 |
| ogra_ | inter-app sockes within the same snap should be possible though ... | 16:33 |
| ysionneau | jdstrand: ok thx | 16:33 |
| jdstrand | ogra_: yes, but perms need to still be allowed | 16:33 |
| jdstrand | it is being worked through | 16:34 |
| ogra_ | oh, even if the socket sits in SNAP_DATA ? | 16:34 |
| jdstrand | ysionneau: today, use a named socket | 16:34 |
| jdstrand | if that is possible | 16:34 |
| jdstrand | since only file rules are in effect with those | 16:34 |
| jdstrand | ysionneau: let me check the default policy real quick | 16:35 |
| jdstrand | ogra_: this is an abstract socket | 16:36 |
| ogra_ | oh, right | 16:36 |
| jdstrand | neither 15.04 nor 16.04 allow binding to an abstract unix socket. 16.04 will have an interface for that | 16:38 |
| jdstrand | but like I said, it should work if you use a named socket | 16:38 |
| jdstrand | (iirc) | 16:38 |
| jdstrand | zyga: ok, I'm going to go pretty deep on this review and really study how things are being put together (except perhaps the xmanager bits) | 16:40 |
| ysionneau | jdstrand: ok thanks! | 16:42 |
| ysionneau | will try with a named unix socket | 16:42 |
| zyga | jdstrand: thank you | 17:19 |
| zyga | jdstrand: feel free to pull me in and ask any questions | 17:19 |
| zyga | jdstrand: I have more aa-specifc patches piled, about to be pushed out soon | 17:20 |
| zyga | jdstrand: ( https://github.com/ubuntu-core/snappy/pull/635 ) for later | 17:27 |
| === chihchun_afk is now known as chihchun | ||
| jdstrand | ack | 17:32 |
| === chihchun is now known as chihchun_afk | ||
| zyga | jdstrand: thanks | 17:33 |
| zyga | jdstrand: also FYI, for some context how I plan to plug it together, look at this list of TODOs (before it gets stale) https://github.com/zyga/snappy/blob/master/overlord/ifacestate/ifacemgr.go#L93 | 17:36 |
| jdstrand | ok | 17:36 |
| kyrofa | elopio, I just shared a google doc with you regarding the dirty build redesign | 17:44 |
| kyrofa | elopio, essentially a distilled problems/solutions doc | 17:45 |
| kyrofa | elopio, mind taking a look? | 17:45 |
| rajen | Hi folks..I am seeing apparmour issues using new ubuntu-core image | 17:46 |
| rajen | Any guidance would be of great help | 17:46 |
| rajen | We are running our app unconfined as of now | 17:46 |
| rajen | dmesg shows a lot of audit messages | 17:47 |
| rajen | http://pastebin.com/nQvfDhX5 | 17:48 |
| zyga | elopio: it's not urgent (next week) but I'd like to write a few integration tests | 17:49 |
| zyga | elopio: and I could use a quick interactive session with you | 17:49 |
| zyga | elopio: my goal is to write a test that checks that udev/apparmor support fuctions really work; this basically means setting up some files, calling a function from snappy and then checking that some stuff happened (either with more snappy functions or just with brute-force helper shell command/file poke) | 17:50 |
| zyga | elopio: when would be the best time to try this? | 17:50 |
| kyrofa | rajen, install snappy-debug (snappy install snappy-debug) and run sudo snappy-debug.security scanlog | 17:52 |
| kyrofa | rajen, wait... those messages are fine, they're just loading profiles and stuff | 17:53 |
| rajen | Here is the latest from scanlog http://pastebin.com/tAgMJX5D | 17:53 |
| jdstrand | rajen: is this on 16.04? | 17:55 |
| rajen | Yes 16.04 daily build | 17:55 |
| jdstrand | yeah, it needs to be updated | 17:55 |
| jdstrand | let me do that real quick | 17:55 |
| rajen | I picked the image an hour back from http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ | 17:56 |
| jdstrand | rajen: ok, update to snappy-debug 0.13 | 18:01 |
| jdstrand | it needed the to be updates for interfaces work | 18:02 |
| jdstrand | s/the // | 18:02 |
| rajen | jdstrand: Yeah Now I see better scalogs | 18:02 |
| rajen | I see a lot of DENIED logs | 18:03 |
| rajen | jstrand: Here is a sample from the long logs http://pastebin.com/yRJi4GMD | 18:04 |
| rajen | jdstrand: Do I have to update my snapcraft.yaml for it to work on new image? I am using slots and my snap app is working from on an ubuntu-core image 3 days back. | 18:08 |
| jdstrand | rajen: likely-- can you paste it? | 18:08 |
| ssweeny | kyrofa, using build-packages instead of stage-packages I'm getting cmake errors in the config stage. -lpthread failing and whatnot. Looking at the error log I'm seeing stuff like: | 18:09 |
| ssweeny | /usr/bin/cc -I/home/ubuntu/location-service/trunk/snappy/stage/include -I/home/ubuntu/location-service/trunk/snappy/stage/usr/include -I/home/ubuntu/location-service/trunk/snappy/stage/include/x86_64-linux-gnu -I/home/ubuntu/location-service/trunk/snappy/stage/usr/include/x86_64-linux-gnu -Wall -pedantic -Wextra -fPIC -DCHECK_FUNCTION_EXISTS=pthread_create -o CMakeFiles/cmTryCompileExec495151839.dir/CheckFunctionExists.c.o -c | 18:09 |
| ssweeny | /usr/share/cmake-3.2/Modules/CheckFunctionExists.c | 18:09 |
| rajen | jdstrand: http://pastebin.com/reRMKXHC | 18:09 |
| ssweeny | kyrofa, so it's definitely looking for -dev stuff in stage | 18:10 |
| jdstrand | rajen: yes. replace 'slots' with 'plugs' | 18:10 |
| kyrofa | ssweeny, sure it looks there, but it also looks in the standard places | 18:10 |
| jdstrand | rajen: in both places. that was very similar to what I had to do for snappy-debug incidentally. (the slots<->plugs rename is in the image now) | 18:11 |
| rajen | jdstrand: Yay! Works now. | 18:12 |
| rajen | Thanks for the help. | 18:12 |
| jdstrand | nice :) | 18:12 |
| elopio | zyga: I'm here just for that, so you chose the date and time. I usually start working at 14UTC, but I can adjust my working times easily too. | 18:12 |
| elopio | zyga: we have a really simple test for hardware assign that we can use as a base: https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/hwAssign_test.go | 18:13 |
| elopio | kyrofa: looking | 18:14 |
| ssweeny | kyrofa, at least in the logs it's not looking outside of stage | 18:17 |
| kyrofa | ssweeny, the -I arguments ADD to the system include dirs-- it doesn't replace the | 18:18 |
| kyrofa | m | 18:18 |
| zyga | elopio: cool, let's aim for Tuesday | 18:24 |
| zyga | elopio: I'll sync with you before that happens | 18:24 |
| elopio | perfect. Thanks zyga. | 18:25 |
| ssweeny | kyrofa, well I can't think of why it would fail then. I have libc6-dev installed on that system | 18:29 |
| kyrofa | ssweeny, any chance you could share both your project and the build log? | 18:30 |
| kyrofa | ssweeny, happy to look into it :) | 18:30 |
| ssweeny | kyrofa, sure. let me push my branch up | 18:31 |
| ssweeny | kyrofa, my branch is here: https://code.launchpad.net/~ssweeny/location-service/snapcraft-2.3 and it looks like you were right about includes. I was reading too much into CMakeErrors.log. However that just means I have no idea why my build is failing :) | 18:53 |
| kyrofa | ssweeny, checking it out now | 18:57 |
| ssweeny | kyrofa, many thanks | 18:57 |
| kyrofa | jdstrand, I assume I just hit bug #1555305 | 19:01 |
| ubottu | bug 1555305 in click-reviewers-tools (Ubuntu) "resquashfs test fails if snap has symlinks" [High,Confirmed] https://launchpad.net/bugs/1555305 | 19:01 |
| kyrofa | jdstrand, I requested a manual review (owncloud.canonical). Mind taking a look? | 19:02 |
| kyrofa | ssweeny, what is your intention with this glue part? | 19:05 |
| ssweeny | kyrofa, I think that's leftover from an earlier version when we didn't know how to expose the binaries properly :) | 19:06 |
| kyrofa | ssweeny, ahh, okay. Well first off, this is the first YAML I've seen in a subdirectory. I won't be surprised if that's the cause of your issues | 19:07 |
| ssweeny | kyrofa, moving the yaml to the top-level dir didn't change anything | 19:10 |
| kyrofa | ssweeny, sorry, got a few thing going at once, still investigating | 19:20 |
| ssweeny | kyrofa, no worries. it might be a legitimate build failure actually. Some "recipe failed" lines were obscured by the jumbled "-j8" output | 19:21 |
| kyrofa | ssweeny, huh. I assume you're tried outside of snapcraft though? | 19:22 |
| ssweeny | kyrofa, yeah it builds fine in a normal cmake environment | 19:22 |
| ssweeny | kyrofa, even weirder is I was able to get it to build when the build-packages were stage-packages | 19:23 |
| elopio | kyrofa: Sergio will be super happy. | 19:24 |
| kyrofa | elopio, think so? Most of that sound okay? | 19:27 |
| kyrofa | elopio, I tried to reply to your comments | 19:27 |
| elopio | kyrofa: everyting sounds great. | 19:27 |
| kyrofa | elopio, thanks for taking a look! :) | 19:29 |
| kyrofa | ssweeny, does this look like your build log? http://pastebin.ubuntu.com/15343243/ | 19:30 |
| ssweeny | kyrofa, yep that's it | 19:32 |
| kyrofa | ssweeny, because dbus/dbus.h is not in the standard include paths | 19:32 |
| kyrofa | ssweeny, it's core/dbus/dbus.h | 19:32 |
| jdstrand | pindonga: I've got one more for you: r606 | 19:32 |
| jdstrand | pindonga: adjustment for recent snap.yaml changes | 19:33 |
| pindonga | good thing I had such a busy today that I didn't even get to your previous request :/ | 19:33 |
| jdstrand | yay? | 19:33 |
| pindonga | jdstrand, and unfortunately, looking at things we won't be able to update until monday | 19:33 |
| pindonga | but I'll make sure it's top prio for early next week | 19:33 |
| kyrofa | ssweeny, also, may I express my sympathies for needing to deal with dbus-cpp and the trust store | 19:33 |
| ssweeny | kyrofa, haha, thanks | 19:34 |
| jdstrand | pindonga: thanks! I wish I could say that there weren't go to be more requests of the next couple weeks, but things continue to change fast | 19:34 |
| jdstrand | going* | 19:34 |
| kyrofa | ssweeny, okay, so this is interesting | 19:35 |
| jdstrand | kyrofa: approved | 19:35 |
| kyrofa | jdstrand, many thanks! | 19:35 |
| jdstrand | np | 19:35 |
| ssweeny | kyrofa, i like interesting | 19:35 |
| kyrofa | ssweeny, I may have been right about how -I added to the system includes rather than replacing them, but you were still right about it using the stage directory. /usr/include/dbus-1.0/ contains dbus/dbus.h, and it's added to the include path, but _within stage_ | 19:36 |
| tvoss | o/ | 19:36 |
| kyrofa | ssweeny, my question is: Why? | 19:36 |
| pindonga | jdstrand, nw | 19:37 |
| kyrofa | ssweeny, looking at the cmake output, it says it found dbus-cpp | 19:37 |
| pindonga | jdstrand, I wish we had taken the time back then to automate the pulling of new crt revnos | 19:37 |
| pindonga | instead of tying it to the normal deployment cycle | 19:38 |
| kyrofa | ssweeny, but then the paths that get tacked on are in stage rather than the system paths | 19:38 |
| pindonga | but then... :) | 19:38 |
| kyrofa | ssweeny, ah, it uses pkg-config it seems? | 19:38 |
| kyrofa | ssweeny, this may indeed be a bug | 19:38 |
| ssweeny | woo hoo I found a bug! | 19:39 |
| ssweeny | second one i found today :) | 19:39 |
| kyrofa | ssweeny, may, I say! | 19:39 |
| ssweeny | kyrofa, fair enough | 19:39 |
| kyrofa | :P | 19:39 |
| jdstrand | pindonga: yeah, well, hopefully it'll calm down a bit. I mean, click checks aren't updated very often | 19:39 |
| kyrofa | ssweeny, just a sec, this touches a bit of snapcraft code I'm not super familiar with | 19:39 |
| jdstrand | so after GA, I expect things to calm down a lot | 19:40 |
| * kyrofa gets familiar | 19:40 | |
| zyga-phone | jdstrand: thanks for reviewing the branch; do you want me to merge it and follow-up with isolated changes or do you want me to pile them in the same pull request? | 19:51 |
| nadu | I'm looking for information about security updates and auto updates. Can anyone help? | 19:58 |
| zyga-phone | nadu: what do you want to know | 19:58 |
| kyrofa | ssweeny, yup, bug. Snapcraft sets PKG_CONFIG_SYSROOT_DIR to the stage dir | 20:01 |
| nadu | Is there something similar to unattended-upgrades and how are security upgrade applied? | 20:01 |
| zyga-phone | nadu: snappy updates all snaps automatically | 20:01 |
| zyga-phone | nadu: it's on by default | 20:01 |
| ssweeny | kyrofa, aha! | 20:01 |
| zyga-phone | nadu: security updates are rolled out as new versions of the os/kernel snaps | 20:01 |
| zyga-phone | nadu: also, snappy reboots automatically to upgrade kernel/os | 20:02 |
| zyga-phone | nadu: so you plug it in and it's on and secure by default | 20:02 |
| nadu | sounds cool | 20:02 |
| nadu | can I chroot into a docker container? | 20:02 |
| zyga-phone | nadu: for other snaps the same thing happens but there's no reboot required, vendors are responsible for updating their software though | 20:02 |
| kyrofa | ssweeny, so you know that advice I gave you about having -dev packages as build? | 20:03 |
| zyga-phone | nadu: yes, you can use docker, lxd or you can use the classic dimension which gives you classic ubuntu directly on any snappy hsot | 20:03 |
| kyrofa | ssweeny, ignore it in this case I guess :P | 20:03 |
| zyga-phone | host* | 20:03 |
| ssweeny | kyrofa, haha | 20:03 |
| kyrofa | ssweeny, I'm not sure how to get it to work in both cases, though | 20:03 |
| kyrofa | ssweeny, I'll have to give it some thought. Log a bug for us? | 20:03 |
| ssweeny | kyrofa, sure | 20:03 |
| kyrofa | ssweeny, thank you! | 20:04 |
| ssweeny | kyrofa, no thank YOU | 20:04 |
| ssweeny | i thought i was losing my mind | 20:04 |
| nadu | zyga-phone: I'd like to do some configuration changes to a docker container without typing docker exec containername everytime | 20:04 |
| zyga-phone | nadu: I don't know how that's related to snappy | 20:05 |
| ssweeny | kyrofa, of course now I have the problem of libapparmor not being set up correctly when unpacked | 20:06 |
| ssweeny | so i'm back where i started :) | 20:06 |
| nadu | zyga-phone: you're right :) | 20:07 |
| kyrofa | ssweeny, yeah that's annoying. You can probaby hack Snapcraft a little to work with the build packages if you want | 20:08 |
| kyrofa | ssweeny, basically, just comment out line 366 in /usr/lib/python3/dist-packages/snapcraft/yaml.py | 20:09 |
| kyrofa | ssweeny, see if that works better | 20:09 |
| nadu | how can I print more information about a snappy packages? for example getting the maintainer? | 20:11 |
| zyga-phone | nadu: each snap has a vendor field | 20:11 |
| zyga-phone | nadu: snaps don't have maintainers | 20:11 |
| zyga-phone | nadu: snaps are binary packages, not source packages | 20:12 |
| zyga-phone | nadu: how you build your snaps is not important to snappy itself | 20:12 |
| ssweeny | kyrofa, yep that fixes it | 20:12 |
| zyga-phone | nadu: you can check the snap meta-data in snapcraft (2.x) documentation | 20:12 |
| zyga-phone | nadu: I'm sorry, I don't have a link handy | 20:13 |
| kyrofa | ssweeny, but of course, breaks it if you have .pc files in stage-packages | 20:13 |
| ssweeny | of course | 20:13 |
| zyga | jdstrand: thanks, I love how all of this is starting to take shape | 20:21 |
| zyga | jdstrand: I replied to your Unload() question; I think it's fine to still merge this; we'll do a full pass over the security side of interfaces as things get glued | 20:23 |
| ssweeny | kyrofa, looks like someone already found this issue: https://bugs.launchpad.net/snapcraft/+bug/1549570 | 20:24 |
| ubottu | Launchpad bug 1549570 in Snapcraft "pkg-config across multiple sysroots" [High,In progress] | 20:24 |
| jdstrand | zyga: yeah, it is feeling like it is coming together | 20:28 |
| jdstrand | zyga: btw, when do you think that old-security/caps will go away? I'm trying to decide if I should upload an ubuntu-core-security with my new x and unity7 policy | 20:28 |
| jdstrand | zyga: this isn't pressure btw, it is just info for me to decide my next steps | 20:29 |
| zyga | jdstrand: old-security will *probably* remain for a while but will get migrated over to interfaces as a native kind | 20:30 |
| zyga | jdstrand: as to where we want to remove it entirely, I don't know -- I suspect it will live on for 16.04 | 20:30 |
| nadu | zyga-phone: got it | 20:30 |
| zyga | jdstrand: but we'll trigger manual review and just stop allowing it | 20:30 |
| zyga | jdstrand: sure, no worries, I think we have a good cooperation flow :) | 20:30 |
| nadu | can I install vim to ubuntu-core? | 20:30 |
| jdstrand | well, we agreed old-security will exist for a while for security-override and security-policy, but I thought old-security/caps and old-security-security-template were going away as soon as these native interfaces were in place | 20:30 |
| zyga | jdstrand: mmmm | 20:31 |
| zyga | jdstrand: perhaps, if only because some of those would be hard to support | 20:31 |
| zyga | jdstrand: e.g. we'd have to parse and rewrite them partially | 20:31 |
| jdstrand | zyga: any way, the removal was actually a shorthand way of asking the question. I'm trying to decide if I should update ubuntu-core-security or if ubuntu-core-security is going away very soon cause of the interfaces work | 20:31 |
| zyga | jdstrand: that's a curious question | 20:32 |
| zyga | jdstrand: do you need u-c-s for click? | 20:32 |
| jdstrand | no | 20:32 |
| zyga | jdstrand: or is the phone using something separate? | 20:32 |
| jdstrand | phone uses other stuff | 20:32 |
| jdstrand | the last thing we want is duplicated policy between ucs and snappy | 20:32 |
| zyga | jdstrand: then I think it's slowly going to become unused | 20:33 |
| jdstrand | so I wanted to know when the snappy stuff was going live | 20:33 |
| zyga | jdstrand: ASAP | 20:33 |
| zyga | jdstrand: as soon as we glue it together | 20:33 |
| zyga | jdstrand: 16.04 ships with this | 20:33 |
| jdstrand | yes | 20:33 |
| jdstrand | hehe | 20:33 |
| jdstrand | is it hours, days or weeks? | 20:33 |
| jdstrand | if days, how many? | 20:33 |
| zyga | days | 20:33 |
| zyga | 2-3 | 20:33 |
| jdstrand | ok, then I'll hold off | 20:33 |
| zyga | bits are missing | 20:33 |
| zyga | in other parts of snappy | 20:34 |
| zyga | in particular install/remove need to move over to the state engine first | 20:34 |
| zyga | at least a little bit so that interfaces can "see" the snaps that are in the current state | 20:34 |
| jdstrand | zyga: but so we are clear-- you are going to move all the policy that is in ubuntu-core-security to native interfaces, correct | 20:34 |
| jdstrand | ? | 20:34 |
| jdstrand | (in the trunk branch that I pointed you to) | 20:34 |
| zyga | jdstrand: yes | 20:35 |
| jdstrand | ok | 20:35 |
| zyga | jdstrand: it was only nacked by gustavo last time to have me focus on bringing last bits of glue needed | 20:35 |
| zyga | jdstrand: as soon as 1st interface works end-to-end I'll pull all the others over | 20:35 |
| zyga | jdstrand: (which is simple then) | 20:35 |
| jdstrand | zyga: and behind the scenes, old-security/caps will actually map to the native interfaces (and old-security/security-template is a noop/goes away)? (ie, so ucs can go away and we don't have to keep it and snappy in sync? | 20:36 |
| zyga | jdstrand: I think that old-securtiy will become a native interface called "old-security" that emits particular security snippets | 20:36 |
| zyga | jdstrand: perhaps with a bit of parsing here and there | 20:36 |
| zyga | jdstrand: old-security as in the current codebase in snappy/ will go away sooner | 20:37 |
| zyga | jdstrand: we'll keep the feature, switch implementations | 20:37 |
| jdstrand | we can discuss that later-- so long as old-security/caps isn't using the old code that grabs policy from ucs, that is good enough for me for now | 20:37 |
| zyga | jdstrand: so that any and all security related aspects will go through the interfaces/**.go | 20:37 |
| zyga | jdstrand: yep | 20:37 |
| jdstrand | right, sounds good | 20:37 |
| zyga | jdstrand: that's guaranteed | 20:37 |
| jdstrand | ok, thanks! | 20:37 |
| * zyga wishes to see the day where big git rm -rf will happen | 20:38 | |
| zyga | :) | 20:38 |
| zyga | jdstrand: btw, while we're on the topic: https://github.com/ubuntu-core/snappy/pull/636/files | 20:39 |
| zyga | jdstrand: this one is shorter, this is the code that will reload udev rules after any rules get touched | 20:39 |
| zyga | pitti: hey, could you please have a look at https://github.com/ubuntu-core/snappy/pull/636#discussion-diff-55722473R26 | 21:06 |
| zyga | pitti: and weigh in with your udev experience? | 21:06 |
| === Guest51142 is now known as devil__ | ||
| zyga | jdstrand: thanks! | 21:37 |
| jdstrand | np | 21:38 |
| kgunn | hey all what's the _current_ way to remove an installed snap? sudo snap remove snap-name...giving me not found when it's clearly installed | 21:49 |
| ogra_ | kgunn, "snappy remove ... " | 22:48 |
| kgunn | ta | 22:49 |
| kgunn | ogra_: confusing with snap and snappy :) | 22:49 |
| ogra_ | well, naming isnt our strength in snappy (see the security ...) | 22:49 |
| ogra_ | :) | 22:49 |
| ogra_ | capaskillfaces with plugslots :P | 22:50 |
| zyga | ogra_: you confused plugslots with slotplugs | 23:05 |
| zyga | ogra_: snappy and snapd as commands are going away (from PATH) | 23:05 |
| zyga | ogra_: snap is the only thing that people will tab-complete | 23:05 |
| ogra_ | zyga, in 4 months :P | 23:07 |
| zyga | ogra_: no, more like in the next few days | 23:07 |
| zyga | ogra_: all of install/remove/config/etc ops are available in the rest api | 23:07 |
| zyga | ogra_: and exposed via snap | 23:08 |
| * ogra_ wishes back blueprints ... where things were well defined, discussed early and written down in a public place :P | 23:08 | |
| zyga | ogra_: well, we still discuss and refine but it's not like we have a grand plan for each detail for the next 6 months anymore | 23:09 |
| zyga | ogra_: too hard to do that | 23:09 |
| zyga | ogra_: too inflexible | 23:09 |
| ogra_ | you discuss at some obscure sprints ... | 23:09 |
| ogra_ | and then someone writes down something in some well hidden google doc | 23:09 |
| zyga | ogra_: I discuss most of my stuff on github | 23:09 |
| zyga | ogra_: those are drafts, they trigger coding and feedback cycle | 23:10 |
| zyga | ogra_: wanna look at some of the security work I'm doing with jdstrand? https://github.com/ubuntu-core/snappy/pull/617 | 23:10 |
| ogra_ | well, i see very rarely any discussions of implementation in here | 23:10 |
| ogra_ | but i kind of started to give up caring since i'm in this team | 23:11 |
| zyga | ogra_: that's true | 23:11 |
| ogra_ | everything got way to opaque | 23:11 |
| zyga | ogra_: tradeoffs for hard deadlines, I don't think we could have made snappy the old way we made ubuntu before, not this time | 23:12 |
| zyga | ogra_: doesn't mean we'll work this way all the time either | 23:12 |
| * zyga -> shower | 23:12 | |
| * ogra_ TV | 23:12 | |
| ogra_ | :) | 23:12 |
| * zyga -> EOD | 23:54 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!