| sergiusens | kyrofa and? | 00:35 |
|---|---|---|
| kyrofa | sergiusens, seems to work, but my test case is broken anyway (opencv) so I still want to poke at it some more tomorrow. Left some comments on the PR | 00:55 |
| stgraber | zyga-suse: not crazy urgent, not warranting a point release on its own, but it is something we need sorted to have LXD actually be at feature parity with the deb package. Custom seccomp policies is a feature we've had quite a bit of interest for lately and it's pretty unfortunate that it's not working with the snap. | 00:59 |
| sergiusens | kyrofa it would be nice to know how it is broken and what is the test case, I'll most likely be off tomorrow but all the info you can get would be good | 01:08 |
| kyrofa | sergiusens, it's the bug I logged about snapcraft on trusty | 01:21 |
| kyrofa | Details are there | 01:21 |
| === chihchun_afk is now known as chihchun | ||
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| zyga-suse | stgraber: I understand, I'll talk to mvo | 05:24 |
| morphis | stgraber: zyga-suse: not sure what I see here: https://paste.ubuntu.com/25770362/ | 05:40 |
| stgraber | that's a snapd bug | 05:41 |
| stgraber | that got fixed in a 2.28 point release | 05:41 |
| morphis | ah good to know | 05:41 |
| morphis | which isn't yet in stable as it seems | 05:41 |
| morphis | stgraber: yeah, with latest candidate of core it seems to be fixed | 05:43 |
| zyga-suse | morphis: indeed, this is fixed in one of the point releases after 2.28, try .5 to be sure | 06:03 |
| elopio | snappy-m-o autopkgtest 1630 xenial:amd64:integration | 06:10 |
| snappy-m-o | elopio: I've just triggered your test. | 06:10 |
| sborovkov | ogra_: hi. Looks like psplash is not present in cm3? Is it like forgotten there? | 06:18 |
| zyga-suse | mvo: good morning | 06:46 |
| mvo | hey zyga-suse | 06:46 |
| mvo | zyga-suse: how ar ethings? | 06:46 |
| zyga-suse | mvo: sorry to start like that straight when you join | 06:46 |
| zyga-suse | https://bugs.launchpad.net/snapd/+bug/1724697 | 06:47 |
| mup | Bug #1724697: snap-confine shouldn't setup a seccomp policy if policy is @unrestricted <snapd:Triaged> <https://launchpad.net/bugs/1724697> | 06:47 |
| zyga-suse | we need to solve this quickly | 06:47 |
| zyga-suse | mvo, stgraber said it's not a 2.28.6 thing but important for him | 06:47 |
| zyga-suse | mvo: I think the idea to keep the file and put a unique string into it is simple and should be enough | 06:48 |
| mvo | zyga-suse: ok, sounds reasonable | 06:49 |
| mvo | zyga-suse: I'm just reading the bugreport | 06:49 |
| mvo | zyga-suse: I can work on a fix this morning, just doing some pi2 related research but I'm almost done | 07:09 |
| zyga-suse | mvo: I can help too | 07:10 |
| zyga-suse | mvo: I'm working on loads of tests for the new overlayfs mount feature | 07:10 |
| mvo | zyga-suse: overlays are priority | 07:10 |
| zyga-suse | ok | 07:10 |
| mvo | zyga-suse: at least that is my understanding :) | 07:10 |
| mvo | zyga-suse: hey, if we could get that for 2.29 ... | 07:10 |
| mvo | zyga-suse: maybe as a experimental thing or so? | 07:10 |
| zyga-suse | I think it's too soon as neither gustavo nor jamie saw it yet | 07:11 |
| zyga-suse | but we'll see :) | 07:11 |
| zyga-suse | I need to land a prereq branch | 07:11 |
| zyga-suse | I may yet tweak it to move files around and shrink diff for future PRs but not my priority yet | 07:11 |
| kalikiana | o/ | 07:34 |
| c-lobrano | morning :) | 07:37 |
| c-lobrano | kalikiana: thinking about hardening `get_os_release_info`, as suggested by kryofa. What about a little bit more robust `get_os_release_info` and some `get_os_release_fieldname` that wrap the first and provide fallback? Like `get_os_release_version_id()`. This way, the user does not need to know the actual dictionary key name | 07:43 |
| kalikiana | c-lobrano: Hmm maybe one step further and make it a little class? | 07:45 |
| c-lobrano | kalikiana: yes, that would be good | 07:50 |
| mup | PR snapcraft#1633 opened: recording: record information from the image in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1633> | 08:47 |
| kalikiana | elopio: since you're awake: we hit the timeout again in snapcraft#1632 :-( | 08:50 |
| mup | PR snapcraft#1632: libraries: exclude the full set of libc6 <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1632> | 08:50 |
| elopio | I'm working on the split. | 08:57 |
| * zyga-suse -> coffee | 08:57 | |
| kalikiana | awesome | 09:06 |
| Chipaca | pedronis: how're things? | 09:10 |
| Chipaca | mvo: has #4050 earned your +1? | 09:10 |
| mup | PR #4050: cmd/snap: tell translators about arg names and descs req's <Created by chipaca> <https://github.com/snapcore/snapd/pull/4050> | 09:10 |
| mvo | Chipaca: I look in a tiny bit | 09:14 |
| Chipaca | mvo: how's things? | 09:15 |
| mvo | Chipaca: I can foresee nitpicking about tidyNoticef, as the name gives no hint that it transforms into a panic under certain conditions. but I have not made up my mind much | 09:15 |
| mvo | Chipaca: otherwise things are good mostly, looking at pi firware stuff right now | 09:16 |
| Chipaca | mvo: do we have a reproducer for the insane flip-flops? | 09:16 |
| mvo | Chipaca: what flip-flops, do you have a reference to a forum post or a bugreport? | 09:18 |
| mup | PR snapd#4054 opened: snap-{confine,seccomp}: make @unrestricted fully unrestricted <Created by mvo5> <https://github.com/snapcore/snapd/pull/4054> | 09:20 |
| mvo | zyga-suse: and you may say "told you so" now :) I remeber we talked about fully unrestricted seccomp and iirc you suggested we should do it in the above way | 09:20 |
| jacekn | aaaaaaaaaaaaaaaaaaaaaaaaaaaaa3aaaaaaad | 09:21 |
| jacekn | sorry | 09:21 |
| Chipaca | mvo: sorry, i meant the thing where sergio's pi3 would boot into one thing but think it's booting into another? something like that | 09:25 |
| mvo | Chipaca: we know it is caused by the ubuntu-image snap, once sergio uses the deb things are ok. my plan was to look into it more once I have a pi3 (should arrive today) | 09:26 |
| Chipaca | ah ok | 09:26 |
| mvo | Chipaca: which is a huge relief that its not a snapd issue | 09:26 |
| Chipaca | mvo: we can shake our fists at barry and move on :D | 09:27 |
| mvo | Chipaca: :-D | 09:30 |
| zyga-suse | mvo: impossible, I don't recall saying that ;-) | 09:38 |
| * zyga-suse is progressing thrgough testing, with some nice simplifications and improvements to code in result of finding tiny details off | 09:39 | |
| Son_Goku | mvo, zyga-suse: https://github.com/canonical-docs/snappy-docs/pull/138 | 09:46 |
| mup | PR canonical-docs/snappy-docs#138: Update Fedora snapd to 2.28.5 <Created by Conan-Kudo> <https://github.com/canonical-docs/snappy-docs/pull/138> | 09:46 |
| Son_Goku | davidcalle ^ | 09:46 |
| Son_Goku | zyga-suse: this will likely be the end of the line for Fedora 25 | 09:46 |
| Son_Goku | as by the time 2.29 becomes available, Fedora 25 will EOL | 09:47 |
| Son_Goku | zyga-suse, you should reach out to pitti at some point to talk about downstream Fedora CI | 09:49 |
| Son_Goku | he's been working on a project to introduce the equivalent of autopkgtests in Fedora for a while now | 09:49 |
| mvo | zyga-suse: does "cannot open current mount profile: /run/snapd/ns/snap.*<snap_name>*.fstab:permission denied" ring any bell? we got a bugreport about this, I can forward | 09:59 |
| * kalikiana break | 10:17 | |
| mup | PR snapd#4055 opened: daemon: generate a forbidden response message if polkit dialog is dismissed <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4055> | 10:20 |
| mup | PR snapd#4056 opened: tests: improve revert related testing <Created by mvo5> <https://github.com/snapcore/snapd/pull/4056> | 10:21 |
| zyga-suse | mvo: hmmm, no, not immediately, looks like apparmor | 10:44 |
| zyga-suse | mvo: please forward | 10:44 |
| mvo | zyga-suse: I did | 10:44 |
| mvo | zyga-suse: its the mail from pierre, I don't have many details yet | 10:44 |
| zyga-suse | mvo: ePierre? | 10:44 |
| mvo | zyga-suse: yeah, I think so | 10:48 |
| mvo | zyga-suse: does http://paste.ubuntu.com/25771634/ ring a bell? | 10:49 |
| zyga-suse | mvo: that looks like a custom base snap with no /dev | 10:49 |
| mvo | zyga-suse: that is from core stable -> edge auto refresh test http://paste.ubuntu.com/25771638 has the debug | 10:50 |
| mvo | zyga-suse: anyway, I have a look | 10:51 |
| mvo | zyga-suse: but it looks like pierre foudn a bug | 10:51 |
| zyga-suse | mvo: this code didn't change | 10:51 |
| zyga-suse | mvo: I bet it's /dev missing | 10:51 |
| zyga-suse | mvo: FYI, I'm chatting with ePierre on #chekbox | 10:51 |
| zyga-suse | #checkbox | 10:51 |
| mvo | zyga-suse: aha, ok | 10:52 |
| zyga-suse | I want to collect some quick info since pierre is likely to EOD any time now | 10:52 |
| zyga-suse | mvo: can you forward the rport please? | 10:52 |
| mvo | zyga-suse: I did that already, you are in the CC | 10:53 |
| mvo | zyga-suse: message-id: 20171019102101.h7wlysxnpqjfufqk@bod | 10:54 |
| zyga-suse | I get 0 matches | 10:54 |
| zyga-suse | maybe gmail doesn't filter on those | 10:54 |
| zyga-suse | mvo: ok, I understand the issue now | 10:56 |
| zyga-suse | mvo: not sure why it happens but here's what happens: | 10:56 |
| zyga-suse | mvo: when we introduced snap-update-ns as the namespace initializer | 10:57 |
| zyga-suse | mvo: we removed the ability to read / process .fstab files from snap-confine | 10:57 |
| zyga-suse | mvo: after reverting we are running on the profile from the +next version | 10:57 |
| zyga-suse | mvo: I think it looks like a bug in the code that re-builds snap-confine's apparmor profile | 10:57 |
| zyga-suse | mvo: does that make sense? | 10:58 |
| zyga-suse | mvo: after revert we should immediately rebuild the profile | 10:58 |
| zyga-suse | mvo: what is curious here is that since the profile is *path based* it should not be a problem | 10:59 |
| zyga-suse | the old profile is around | 10:59 |
| zyga-suse | mvo: (around as in loaded in memory) | 10:59 |
| mvo | zyga-suse: well, we reboot in between in tests on core | 11:00 |
| mvo | zyga-suse: but yeah, it makes sense | 11:00 |
| zyga-suse | hmmm | 11:00 |
| mvo | zyga-suse: I mean, if its loaded in memory it will get lost accross the reboot | 11:01 |
| zyga-suse | this should not be an issue on core | 11:01 |
| zyga-suse | yes | 11:01 |
| zyga-suse | well | 11:01 |
| zyga-suse | no | 11:01 |
| mvo | zyga-suse: the report is about core afaict | 11:01 |
| zyga-suse | across reboot we'll keep the file in /etc/apparmor.d | 11:01 |
| zyga-suse | so it will get re-loaded | 11:01 |
| zyga-suse | was this on core on classic? | 11:01 |
| mvo | zyga-suse: from what I read its a regular core device (caracalla/stlouis9 | 11:01 |
| mvo | ) | 11:01 |
| zyga-suse | right | 11:01 |
| * zyga-suse thinks | 11:01 | |
| zyga-suse | it doesn't seem device specific | 11:02 |
| zyga-suse | so we should be able to reproduce it | 11:02 |
| mvo | yeah | 11:02 |
| zyga-suse | that was edge->stable? | 11:02 |
| mvo | I did a PR that tests some more things with reverts | 11:02 |
| mvo | yeah | 11:02 |
| zyga-suse | thank you | 11:02 |
| zyga-suse | do you want me to explore or shall I keep at layouts? | 11:02 |
| mvo | see the linked PR | 11:02 |
| zyga-suse | ack | 11:03 |
| mvo | I can work a bit on this and get a reliable test, then we can brainstorm again | 11:03 |
| mvo | zyga-suse: just wanted to double check that its not something obvious | 11:03 |
| mvo | (or known) | 11:03 |
| zyga-suse | no, nothing obviously smoking-gun-wrong | 11:04 |
| mvo | ta | 11:04 |
| zyga-suse | mvo: when we run reexecing snap-confine do we follow the current symlink? | 11:10 |
| zyga-suse | meh | 11:11 |
| zyga-suse | mvo: I'm dumb | 11:11 |
| zyga-suse | mvo: I understand now | 11:11 |
| zyga-suse | mvo: on core / is the core snap | 11:11 |
| zyga-suse | mvo: so when we get new core via update | 11:11 |
| zyga-suse | mvo: (and we don't reload the profile there) | 11:11 |
| zyga-suse | mvo: so when we get the new core, we must not follow any current symlinks and must use the old profile | 11:12 |
| zyga-suse | mvo: right? | 11:12 |
| zyga-suse | mvo: so we literally run /usr/lib/snapd/snap-confine | 11:12 |
| mvo | zyga-suse: correct | 11:13 |
| zyga-suse | mvo: so dump my other theories, the cause still is likely (we removed the right to touch .fstab profiles) but why it gets applied here is unclear | 11:14 |
| zyga-suse | mvo: (assuming before reboot) | 11:14 |
| zyga-suse | I'm getting hungry, let's break for some lunch | 11:19 |
| mvo | zyga-suse: good idea | 11:22 |
| kalikiana | mwhudson: Hey! I was wondering if we should discuss snapcraft#1557 a bit | 11:56 |
| mup | PR snapcraft#1557: cleanbuild: add a --image option to build in a different image <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1557> | 11:56 |
| zyga-suse | re | 12:07 |
| Chipaca | kalikiana: you know it's 1am for mwhudson, yes? | 12:07 |
| kalikiana | Chipaca: Oh, I didn't realize. What timezone is he in? | 12:08 |
| zyga-suse | kalikiana: NZ | 12:09 |
| zyga-suse | "the far side of the moon^Hearth" | 12:09 |
| kalikiana | Heh | 12:09 |
| kalikiana | Thanks | 12:09 |
| kalikiana | I'll try to ping him at a better time then | 12:09 |
| Chipaca | kalikiana: that's not to say he isn't sometimes around at this time, but it's usually bad news :-) | 12:10 |
| * zyga-suse works on 4008 | 12:14 | |
| zyga-suse | I can put some future code there to make eventual diff smaller | 12:14 |
| zyga-suse | hmm | 12:15 |
| zyga-suse | on go 1.9.1 I cannot "go test" stuff anoymre | 12:15 |
| zyga-suse | *anymore | 12:16 |
| zyga-suse | zyga@faroe:~/snapd/cmd/snap-update-ns> go test . | 12:16 |
| zyga-suse | # github.com/snapcore/snapd/vendor/gopkg.in/tomb.v2 | 12:16 |
| zyga-suse | flag provided but not defined: -goversion | 12:16 |
| zyga-suse | niemeyer: ^ does this ring any bells? | 12:16 |
| * zyga-suse reboots | 12:20 | |
| zyga-suse | ok, all good now | 12:22 |
| zyga-suse | probably stale env after update | 12:22 |
| jdstrand | zyga-suse: overlayfs? I thought this was being done with bind mounts... | 12:28 |
| zyga-suse | jdstrand: with both | 12:36 |
| niemeyer | zyga-suse: No, I've never seen that flag either I think | 12:37 |
| zyga-suse | niemeyer: it's all good now | 12:37 |
| niemeyer | zyga-suse: Perhaps go tool was out of date with underlying tooling | 12:38 |
| zyga-suse | yes, I just updated; it's okay now, probably some stale stuff while I was logged in | 12:38 |
| cachio | mvo, I am creating a test for gsettings interface, an I am getting "gsettings: not found" when I execute a command | 12:42 |
| mvo | cachio: curious what this is about | 12:42 |
| mvo | cachio: it is installed and in /usr/bin/gsettings I pressume? | 12:42 |
| cachio | yes | 12:43 |
| cachio | mvo, it is just a wrapper for gsettings command | 12:44 |
| cachio | the snap makes gsettings "$@" | 12:45 |
| zyga-suse | mvo: just saw this from go vet | 12:46 |
| zyga-suse | cmd/snap-repair/runner.go:254: arg r.RepairID() for printf verb %d of wrong type: string | 12:46 |
| zyga-suse | cmd/snap-repair/runner.go:415: arg repair.RepairID() for printf verb %d of wrong type: string | 12:46 |
| zyga-suse | mvo: shall I fix? | 12:46 |
| zyga-suse | odd, I don't see the issue | 12:48 |
| zyga-suse | %d is printing int's | 12:48 |
| cachio | pedronis, hey, tests/lib/assertions/auto-import.assert is expired, do you know how to generate a new one? | 12:49 |
| jdstrand | zyga-suse: I was unaware that layouts required overlayfs. when was the greenlight given on overlayfs? we can't guarantee it is going DTRT with apparmor in modern kernels or in backported apparmor to older kernels. overlayfs is unbackportable to older kernels. all the same arguments as always... | 12:50 |
| Chipaca | zyga-suse: in 451, it's doing ("... %s/%d != %s/%d", repair.BrandID(), repair.RepairID(), brandID, repairID) | 12:51 |
| zyga-suse | jdstrand: this is a new development (relatively), we plan to use overlayfs to poke writable holes over squashfs; I made a RFC branch that does this | 12:51 |
| zyga-suse | Chipaca: I know, I think go vet is wrong here | 12:51 |
| ogra_ | sborovkov, i changed teams and all, i simply didnt get to cm3 yet, but should be ready before end of this week (i'm currently working on the remaining bits for cm3 and dragonbard splash support) | 12:52 |
| zyga-suse | Chipaca: especially after fixing it tests are failing | 12:52 |
| Chipaca | zyga-suse: RepairID() returns a string | 12:52 |
| zyga-suse | aha | 12:52 |
| jdstrand | zyga-suse: obviously it's a new development :) my question is where was it discussed? it seems to be ignoring the previous discussions | 12:52 |
| zyga-suse | jdstrand: I don't remember if it was a hangout recently or IRC recently | 12:52 |
| zyga-suse | jdstrand: I recall the earlier discussion but this is an experiment to see if we can use overlay for this purpose | 12:53 |
| jdstrand | zyga-suse: I thought things like this were supposed to be captured in the forum? this is a major technical decision | 12:53 |
| zyga-suse | jdstrand: as it presents simpler semantics and has easier undo story | 12:53 |
| zyga-suse | jdstrand: indeed, I wanted to talk to you about this because it's a big change but all the sprints/holidays were in the way | 12:54 |
| zyga-suse | jdstrand: the short summary is that we'd like to use overlayfs over squashfs | 12:54 |
| zyga-suse | jdstrand: as a hole-poking tool | 12:54 |
| zyga-suse | Chipaca: no, it's an int: | 12:55 |
| zyga-suse | ... error string = "cannot fetch repair, repair id mismatch canonical/%!s(int=2) != canonical/4" | 12:55 |
| zyga-suse | ... regex string = "cannot fetch repair, repair id mismatch canonical/2 != canonical/4" | 12:55 |
| zyga-suse | jdstrand: anyway, let's put that on hold now | 12:55 |
| zyga-suse | jdstrand: (the discussion) | 12:55 |
| Chipaca | zyga-suse: i was wrong ¯\_(ツ)_/¯ | 12:55 |
| * Chipaca tries to find out why he was wrong | 12:56 | |
| zyga-suse | jdstrand: I'll have a thread and PR to review (very short) soon after https://github.com/snapcore/snapd/pull/4008 lands | 12:56 |
| mup | PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008> | 12:56 |
| zyga-suse | (that's what I'd like to focus on now) | 12:56 |
| jdstrand | I understand that. I have little confidence it is going to work reliably with apparmor considering people are backporting apparmor to older kernels (or even an unpatched kernel). I mean, it might work with a recent Ubuntu kernel. note that overlayfs wasn't even an official thing in the upstream kernrel til relatively recently. this makes snaps that utilize the feature impossible to use on older kernels where you can't backport overlayfs | 12:57 |
| * Chipaca disappears again | 12:57 | |
| * zyga-suse nods | 12:58 | |
| jdstrand | tyhicks: warning ^. the plan is to try overlayfs to poke holes in squashfs in an exploratory PR | 12:59 |
| jdstrand | tyhicks: (in support of layouts) | 13:00 |
| zyga-suse | jdstrand: I have the undo logic to tweak but it looks promising (so far) | 13:00 |
| zyga-suse | jdstrand: the diff is very small so far, which is also very very promising | 13:00 |
| zyga-suse | ohg | 13:00 |
| zyga-suse | standup | 13:00 |
| jdstrand | well, except the technologies you are utilizing have to actually work right | 13:00 |
| jdstrand | not to mention my point that overlayfs is new so its use means those snaps can't work on older kernels | 13:01 |
| mup | PR snapd#3972 closed: interfaces: sanitize plugs and slots early in ReadInfo <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3972> | 13:03 |
| jdstrand | zyga-suse: I should also stress that overlafs didn't land in its current form. it landed early and had lots of trouble with LSMs. It still has trouble with LSMs. this means that there is a huge test matrix to make sure the feature even works for kernels that claim to support the feature | 13:03 |
| * jdstrand still wonders why he or tyhicks weren't pulled into the conversation | 13:04 | |
| jdstrand | or jj | 13:04 |
| ogra_ | pobably zyga will simply fix all missing LSM bits with overlayfs on the go then ;) | 13:05 |
| ogra_ | ... will just delay the ETA for the feature by a few years :) | 13:09 |
| skjensen | Hi guys, I'm trying to build an image for my Nvidia TK1. I made an attempt on a snap gadget for the device and have created the model.json. But to make it into a image I need the gadget snap to be available. I'm on Ubuntu 16.04 (amd64) but the device I'm building for is armhf. So I can't use the snap install --dangerous to install the gadget snap I need. How do I build the image on my arm64 workstation? | 13:20 |
| ogra_ | skjensen, you need to use the ubuntu-image tool (theer is a snap with it) and use the --extra-snaps optin to point to your local gadget | 13:21 |
| ogra_ | skjensen, https://docs.ubuntu.com/core/en/guides/build-device/image-building | 13:22 |
| skjensen | I did try that but with little luck.. | 13:22 |
| ogra_ | see part 3 | 13:22 |
| ogra_ | sudo ubuntu-image -c edge --extra-snaps /path/to/your/gadget.snap /path/to/your/model.assertion | 13:23 |
| skjensen | Still can't find it.. | 13:27 |
| ogra_ | whats the exact error ? | 13:27 |
| skjensen | skj@laptop:~/Documents/snap/TK1$ sudo ubuntu-image -c edge --extra-snaps /home/skj/Documents/snap/TK1/tk1_16-0.1_armhf.snap /home/skj/Documents/snap/TK1/tk1.model | 13:27 |
| skjensen | error: cannot find snap "tk1_16-0.1_armhf": snap not found | 13:27 |
| skjensen | COMMAND FAILED: snap prepare-image --channel=edge --extra-snaps=/home/skj/Documents/snap/TK1/tk1_16-0.1_armhf.snap /home/skj/Documents/snap/TK1/tk1.model /tmp/tmp904xzqti/unpack | 13:27 |
| skjensen | and I have defined the gadget like this in the model.json file "gadget": "tk1_16-0.1_armhf", | 13:28 |
| ogra_ | ah | 13:28 |
| ogra_ | you just want the name in there | 13:29 |
| ogra_ | "tk1" | 13:29 |
| ogra_ | change that and re-create the assertion | 13:29 |
| skjensen | Yes, that's working.. :) | 13:30 |
| ogra_ | ;) | 13:30 |
| skjensen | I had it with only the name to start with, but because it couldn't find it I changed to the complete name of the file.. | 13:30 |
| skjensen | Okay, so far so good.. Now I need the kernel snap.. ogra, did you say I can use the bbb kernel? | 13:31 |
| ogra_ | yeah "linux-generic-bbb" is the name ... | 13:31 |
| ogra_ | though ubuntu-image might complain that this isnt a "canonical" package ... in that case use snap download oor grab it from https://code.launchpad.net/~snappy-dev/+snap/linux-generic-bbb/+build/76303 and use the --extra-snaps arg for it as well | 13:32 |
| skjensen | It found it correctly.. | 13:33 |
| ogra_ | cool | 13:33 |
| ogra_ | i knoow there is some builtin policy that the owner of the gadget must match the owner of the kernel snap ... unless the kernel is owned by canonical ... seems we dropped it | 13:34 |
| skjensen | Nope.. you are right.. Just a delayed error message.. | 13:34 |
| skjensen | error: cannot use kernel "linux-generic-bbb" published by "QfOqF7d2M1Pk2O0SbEKqTdB9Ry2aI0BP" for model by "bdSXYoRKHbnUgDeg0MU6rJIID8IODntX" | 13:34 |
| ogra_ | so just pull it from the LP build page and use --extra-snaps | 13:35 |
| ogra_ | that should ignore the requirement | 13:35 |
| skjensen | It's downloading.. :) | 13:35 |
| ogra_ | (i hope) | 13:35 |
| skjensen | Me too.. Unfortunately I got to go pick up my son.. so will have to wait before I can test the image.. I'm right in saying I can flash this image to a SD card and boot from that? | 13:36 |
| ogra_ | yes | 13:36 |
| ogra_ | (if your booard generally can boot from SD indeed) | 13:37 |
| skjensen | It's one of it's best features, if there is a bootable SD card it will boot from that by default.. | 13:37 |
| skjensen | Okay, I'm gone.. Thanks a lot for the help again.. :) | 13:39 |
| ogra_ | then it shoould just woork (if your gadget is correct :) ) | 13:39 |
| zyga-suse | ok, stuff is reabsed | 13:49 |
| zyga-suse | now to tie overlay mount entries to things that use them | 13:49 |
| zyga-suse | so that undo works :) | 13:49 |
| zyga-suse | come to think of it, I think it's actually easier than I thought | 13:50 |
| zyga-suse | perhaps we don't need to annotate overlays | 13:51 |
| zyga-suse | we can just keep them IFF there's anything mounted underneath | 13:51 |
| zyga-suse | so yeah, less patches needed :) | 13:51 |
| * kalikiana lunch time | 13:54 | |
| Son_Goku | zyga-suse: overlays? | 13:58 |
| Son_Goku | are we using overlayfs now? | 13:58 |
| zyga-suse | well, I'm trying to | 13:58 |
| sergiusens | zyga-suse if you have a discussion on irc or a hangout the "minutes" for it at least should really make their way to the forum | 13:58 |
| sergiusens | kalikiana kyrofa elopio et. al. reminder I am out today | 13:59 |
| zyga-suse | sergiusens: are you referring to overlays or something else? | 13:59 |
| sergiusens | zyga-suse yes, but anything really needs to go there if it "matters" | 14:00 |
| sergiusens | kyrofa mind looking at snapcraft#1607 and snapcraft#1583 ? Those are yours and getting those failures out of the way would be great! ;-) | 14:01 |
| mup | PR snapcraft#1607: python plugin: use extracted pip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1607> | 14:01 |
| mup | PR snapcraft#1583: ament plugin: new plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1583> | 14:01 |
| zyga-suse | yes, you are right; I wanted to describe this on the forum but I had a few crazy days and I spent most of the time on just coding this | 14:01 |
| zyga-suse | I'll write something now | 14:02 |
| Son_Goku | so for once, a feature that actually already has SELinux support :) | 14:02 |
| zyga-suse | Son_Goku: https://github.com/zyga/snapd/commit/f34aca5625013b3d02ee6dba384e9918770f94ef#diff-4480ffd44957efa3395867c929f88014R145 | 14:04 |
| cachio | mvo, same error using devmode | 14:11 |
| cachio | to use gsettings | 14:11 |
| zyga-suse | cachio: any denials? | 14:11 |
| cachio | mvo, no | 14:11 |
| cachio | zyga-suse, I am using snap try | 14:11 |
| cachio | zyga-suse, could that affect? | 14:12 |
| Son_Goku | hmm | 14:12 |
| zyga-suse | yes, perhaps | 14:12 |
| kalikiana | kyrofa: mind taking another look at snapcraft#1412 today? I hope I made it clearer now what's addressed there vs. the other PR | 14:42 |
| mup | PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412> | 14:42 |
| kalikiana | kyrofa, elopio: also snapcraft#1627 should be fairly straight-forward. I'm splitting lxd.py into different classes/ files to make the code more maintainable. It's getting a bit unwieldy :-D so might even be better to get this in first, since it probably makes other PRs easier to review | 14:46 |
| mup | PR snapcraft#1627: lxd: split container classes into different files <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1627> | 14:46 |
| kyrofa | kalikiana, will do. Just want to fix my branches now that slow tests have landed etc. | 14:46 |
| zyga-suse | niemeyer: gentle ping about https://github.com/snapcore/snapd/pull/3958 | 14:47 |
| mup | PR #3958: many: add support for /home on NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/3958> | 14:47 |
| kalikiana | kyrofa: Aye, no rush. Let me know if you need another review from me there. | 14:48 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| mvo | cachio: if you post your work-in-progress branch I can have a look | 14:51 |
| cachio | mvo, sure | 14:51 |
| === chihchun is now known as chihchun_afk | ||
| cachio | mvo, this is the branch https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings | 14:56 |
| kyrofa | Agh, test_list_plugins will be the death of me | 14:57 |
| cachio | niemeyer, I think the problem about the refresh core is that after I start the stable version I see https://paste.ubuntu.com/25773077/ | 14:57 |
| niemeyer | zyga-suse: Ack | 14:58 |
| niemeyer | cachio: Looking | 14:58 |
| cachio | niemeyer, I am using the stable version from long time ago | 14:58 |
| niemeyer | cachio: Yeah, so exactly what we discussed | 14:58 |
| cachio | so it triggers a refresh to the current stable | 14:58 |
| cachio | reboots the device and then I start the tests | 14:59 |
| cachio | running against stable instead of using beta | 14:59 |
| niemeyer | cachio: Yeah.. it's a simple race with auto-refresh | 14:59 |
| niemeyer | cachio: As mvo predicted | 14:59 |
| cachio | niemeyer, I should wait until the autorefresh is done to trigger the refresh to beta | 15:00 |
| niemeyer | cachio: Yeah, that should work | 15:00 |
| cachio | niemeyer, nice, thanks for the support | 15:01 |
| niemeyer | cachio: np! | 15:01 |
| kyrofa | elopio, kalikiana I'm getting this a lot on the pip PR: https://travis-ci.org/snapcore/snapcraft/jobs/289625934 | 15:06 |
| kyrofa | elopio, kalikiana have you guys seen that elsewhere? | 15:07 |
| kyrofa | It's definitely not my error, but it only surfaces when running pip stuff, which makes me think I'm doing something to surface it | 15:07 |
| kalikiana | kyrofa: Yeah, I've seen and mentioned that before... the answer I got in the past was "Re-run"... | 15:07 |
| kyrofa | kalikiana, oh really? Okay so maybe not this PR then | 15:07 |
| kyrofa | kalikiana, I wasn't seeing it elsewhere, so was starting to question myself | 15:08 |
| kalikiana | kyrofa: I try to add a comment these days quoting the last lines of such errors, so we can check other PRs for the same false negatives | 15:09 |
| kalikiana | Otherwise it really is difficult to keep track of | 15:09 |
| === cachio is now known as cachio_lunch | ||
| mvo | zyga-suse: fwiw, I can reproduce the issue the ePiere was describing, I think I have a test, my local spread is just unhappy, steps are pretty simple, will send via mail | 15:30 |
| mvo | zyga-suse: i.e. the error is: "cannot open current mount profile: ....fstab: permission denied" | 15:30 |
| mvo | zyga-suse: and I get an apparmor denied from /usr/lib/snapd/snap-confine | 15:31 |
| zyga-suse | mvo: aha | 15:32 |
| zyga-suse | mvo: right | 15:32 |
| zyga-suse | mvo: I'll check it out, let me look at the mail | 15:32 |
| mvo | zyga-suse: I have not written the mail yet | 15:33 |
| zyga-suse | mvo: if you have access to the shell there | 15:33 |
| zyga-suse | mvo: look at the profile in /etc/apparmor.d | 15:33 |
| zyga-suse | mvo: you can also collect the data about the loaded profile in sysfs | 15:34 |
| zyga-suse | mvo: can you paste the denial really quick please? | 15:34 |
| mup | PR snapd#4057 opened: interfaces: remove duplicated MockPlug/MockSlot helpers from interface tests <Created by stolowski> <https://github.com/snapcore/snapd/pull/4057> | 15:34 |
| pstolowski | zyga-suse, can you look at this trivial if you have a moment? ^ | 15:35 |
| mvo | zyga-suse: http://paste.ubuntu.com/25773282/ | 15:35 |
| zyga-suse | mvo: you can also poke at /sys/kernel/security/apparmor | 15:35 |
| zyga-suse | pstolowski: yes | 15:35 |
| mvo | zyga-suse: http://paste.ubuntu.com/25773287/ is the denial | 15:35 |
| zyga-suse | mvo: and the denial? | 15:35 |
| zyga-suse | ah | 15:35 |
| zyga-suse | oh | 15:35 |
| zyga-suse | mknod? | 15:36 |
| zyga-suse | that's odd | 15:36 |
| zyga-suse | that's totally unexpected | 15:36 |
| zyga-suse | can you run with SNAP_CONFINE_DEBUG=yes | 15:36 |
| mvo | zyga-suse: this is the strace (the last few lines) http://paste.ubuntu.com/25773303/ | 15:37 |
| zyga-suse | open("/run/snapd/ns/snap.test-snapd-tools.fstab", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 EACCES (Permission denied) | 15:37 |
| zyga-suse | mvo: that looks like a bug in apparmor | 15:38 |
| zyga-suse | mvo: we get open and mknod | 15:38 |
| zyga-suse | mvo: that doesn't make sense | 15:38 |
| mvo | zyga-suse: and http://paste.ubuntu.com/25773306/ | 15:38 |
| zyga-suse | jdstrand: ^ | 15:38 |
| zyga-suse | pstolowski: why do you want that change? | 15:38 |
| zyga-suse | pstolowski: I wanted it the other way around but I didn't find a way to do it | 15:38 |
| zyga-suse | pstolowski: now we're keeping more test-only code in the real package | 15:39 |
| zyga-suse | mvo: thinking | 15:39 |
| jdstrand | is there actually an *apparmor* denial? | 15:39 |
| zyga-suse | mvo: ` /run/snapd/ns/*.fstab rw,` is the rule that should allow the open | 15:39 |
| pstolowski | zyga-suse, cause I need two other Mock* helpers like that in my other branch, so I thought I'd go ahead and change existing ones to avoid duplication | 15:39 |
| jdstrand | http://paste.ubuntu.com/25773282/ doesn't show there is anything in syslog/journalctl | 15:40 |
| zyga-suse | [ 290.377428] audit: type=1400 audit(1508427272.862:36): apparmor="DENIED" operation="mknod" profile="/usr/lib/snapd/snap-confine" name="/run/snapd/ns/snap.test-snapd-tools.fstab" pid=4066 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 | 15:40 |
| zyga-suse | jdstrand: it's a separate pastebin | 15:40 |
| jdstrand | ok, yes, I see that | 15:40 |
| zyga-suse | pstolowski: can you make it so that we call one of the mock from the other and still use the test package rather than the main package? | 15:40 |
| zyga-suse | mvo: I don't have any theory yet | 15:41 |
| pstolowski | zyga-suse, i'm not totally clear on what do you mean? you don't want builtin.Mock*? | 15:42 |
| zyga-suse | pstolowski: no, I don't want builtin.Mock | 15:42 |
| zyga-suse | pstolowski: we can keep the mock in test-only code | 15:42 |
| zyga-suse | pstolowski: but becase we cannot do that yet there are two copies of the code | 15:43 |
| jdstrand | mvo: are you sure that the .real is what is being used and not snap.core.... | 15:43 |
| zyga-suse | pstolowski: I was thinking one could call the other | 15:43 |
| zyga-suse | mvo: are there .real and plain profiles? | 15:43 |
| pstolowski | zyga-suse, ah, that. let me see | 15:43 |
| zyga-suse | pstolowski: and in general we should perfer test package to the main package | 15:43 |
| zyga-suse | pstolowski: thank you! | 15:44 |
| jdstrand | mvo: you pasted 'cat /etc/apparmor.d/usr.lib.snapd.snap-confine.real' | 15:44 |
| mvo | jdstrand, zyga-suse http://paste.ubuntu.com/25773336/ | 15:44 |
| zyga-suse | mvo: (I mean are there both) | 15:44 |
| zyga-suse | mvo: good | 15:44 |
| mvo | zyga-suse, jdstrand so that is the only apparmor profile for snap-confine (this is on a core system) | 15:44 |
| jdstrand | mvo: what kernel are you using? | 15:45 |
| zyga-suse | yeah, my question exactly | 15:45 |
| jdstrand | cat /proc/version_signature | 15:45 |
| mvo | jdstrand: http://paste.ubuntu.com/25773342/ | 15:45 |
| zyga-suse | mvo: that product may have a different kernel snap | 15:45 |
| zyga-suse | mvo: but I assume you have done this on generic | 15:45 |
| zyga-suse | aha | 15:46 |
| mvo | jdstrand: http://paste.ubuntu.com/25773346/ | 15:46 |
| mvo | yeah, this is a stock (spread) core VM | 15:46 |
| zyga-suse | mvo: at this time I'd collect verbose apparmor debug data | 15:46 |
| zyga-suse | mvo: can you look at /sys/kernel/apparmor | 15:47 |
| mvo | zyga-suse: sure, what do I need to do ? | 15:47 |
| zyga-suse | mvo: and collect (cat + redirect) the profile for snap-confine | 15:47 |
| zyga-suse | just a moment | 15:47 |
| zyga-suse | cd /sys/kernel/security/apparmor | 15:47 |
| zyga-suse | cd policy/profiles | 15:48 |
| jdstrand | mvo: what if you downgrade the kernel to stable | 15:48 |
| zyga-suse | cd usr.lib.snapd.snap-confine.* | 15:48 |
| zyga-suse | mvo: collect everything there | 15:48 |
| zyga-suse | mvo: note that tar is silly and gets empty files | 15:48 |
| zyga-suse | you need a dumb cp -R copy | 15:49 |
| zyga-suse | then tarball | 15:49 |
| zyga-suse | then please send/attach that | 15:49 |
| zyga-suse | I'll have a look | 15:49 |
| zyga-suse | if you could, save the snap_confine profile text as well | 15:49 |
| zyga-suse | verbatim as it appears for you | 15:49 |
| zyga-suse | I know you pastebinned it but if it's in the same tarball it's more convenient | 15:50 |
| zyga-suse | mvo: after that you can experiment in any way, change the kernel as jdstrand suggeste | 15:50 |
| zyga-suse | *suggested, perhaps | 15:50 |
| mup | PR snapd#4057 closed: interfaces: remove duplicated MockPlug/MockSlot helpers from interface tests <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/4057> | 15:50 |
| mvo | zyga-suse: on the way via mail | 15:52 |
| mvo | zyga-suse: jdstrand going to the stable kernel now and trying it again | 15:53 |
| zyga-suse | thank you | 15:54 |
| jdstrand | mvo: you said this is part of spread. what test? | 15:54 |
| pstolowski | zyga-suse, I can make the Mock* method from tests call the one from builtin, so we get rid of duplicated body, a little win.. | 15:54 |
| mvo | jdstrand: its a new spread test I'm currently working on. we got a report from CE QA about this issue | 15:54 |
| jdstrand | I see a test for that file in tests/main/snap-discard-ns, but that wouldn't be confined since calling snap-discard-ns directly... | 15:54 |
| pstolowski | but not the other way around | 15:54 |
| zyga-suse | pstolowski: yeah, that's good | 15:54 |
| zyga-suse | pstolowski: little by little :) | 15:55 |
| mvo | jdstrand: and we have no test yet that checks snap refresh stable->edge and revert back | 15:55 |
| pstolowski | ok.. | 15:55 |
| mvo | jdstrand: fwiw, stable kernel shows the same message | 15:55 |
| jdstrand | mvo: how can I reproduce? | 15:55 |
| jdstrand | mvo: do you have a branch somewhere? | 15:56 |
| === cachio_lunch is now known as cachio | ||
| jdstrand | mvo: what is it that you are reverting btw? | 15:57 |
| mvo | jdstrand: I reverted core | 15:57 |
| * jdstrand wonders if it is a timing issue | 15:57 | |
| mvo | jdstrand: one sec, I'm writing a mail and will CC you | 15:57 |
| jdstrand | eg, if the policy gets updated but the snap-confine binary does not... | 15:57 |
| jdstrand | (eg, as part of the revert) | 15:58 |
| mup | PR snapd#4058 opened: interfaces: reduce duplicated code in interface tests mocks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4058> | 15:59 |
| jdstrand | fwiw, I would be surprised if there is a bug in apparmor for file mediation. I am not saying it isn't possible, but I would expect we would see a ton more issues if there was | 15:59 |
| pstolowski | zyga-suse, ^ | 15:59 |
| zyga-suse | jdstrand: yes, it's a bit mysterious why this happens | 15:59 |
| zyga-suse | jdstrand: remember when we once saw a case of apparmor profile staying stale after being loaded? | 15:59 |
| zyga-suse | mvo: is this reproducible or did you just get it once and didn't try again? | 16:00 |
| jdstrand | if it happens as a result of reverting core, I suspect we are loading the policy from the reverted core but using the snap-confine binary from the unreverted core, or something similar | 16:00 |
| zyga-suse | pstolowski: +1 | 16:00 |
| zyga-suse | jdstrand: but note that on core we reboot and we don't have any core-derived profiles | 16:00 |
| pstolowski | tx | 16:01 |
| zyga-suse | mvo: maybe one more sanity check | 16:01 |
| jdstrand | I bet it is the cache file then | 16:01 |
| mvo | zyga-suse: I rebooted at least twice, manually loaded the profile to double check, definitely reproducible for me. but I have not done a full scenario yet | 16:01 |
| zyga-suse | mvo: reload that profile from disk | 16:01 |
| zyga-suse | mvo: and see if the data in sysfs changes | 16:01 |
| zyga-suse | mvo: and if the error goes away | 16:01 |
| zyga-suse | jdstrand: yes, that's a good idea | 16:01 |
| zyga-suse | mvo: hold on, you reloaded the profile manually and it still failed? | 16:01 |
| jdstrand | eg, boot into current core, generate the cache. reboot into an older core, the mtime check is older than the previous cache file | 16:01 |
| mvo | zyga-suse: apparmor_parse -r /etc... ? I did that, same failure | 16:01 |
| zyga-suse | mvo: yes | 16:01 |
| zyga-suse | holly molly | 16:02 |
| jdstrand | I need a reproducer | 16:02 |
| jdstrand | I strongly suspect there is something along these lines | 16:02 |
| mvo | jdstrand: what file is the cache? I think your theory is correct | 16:02 |
| zyga-suse | mvo: /var/cache/apparmor I think | 16:02 |
| mvo | jdstrand: I can touch the file and see | 16:02 |
| zyga-suse | mvo: for that file | 16:02 |
| jdstrand | /etc/apparmor.d/cache | 16:02 |
| mvo | zyga-suse: cool, let me try that | 16:02 |
| zyga-suse | jdstrand: oh, sorry | 16:03 |
| jdstrand | /var/cache/apparmor is for snaps. /etc/apparmor.d/cache is for system | 16:03 |
| mup | PR snapcraft#1591 closed: snapd integration tests: print stdout/stderr <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591> | 16:03 |
| mvo | jdstrand: http://paste.ubuntu.com/25773431/ <- looks suspcious | 16:03 |
| jdstrand | mvo: a better test might be to rm -f /etc/apparmor.d/cache/usr.lib.snapd.snap-confine* before the reboot | 16:03 |
| zyga-suse | september 27th? | 16:04 |
| zyga-suse | wat? | 16:04 |
| jdstrand | mvo: exacctly | 16:04 |
| mvo | jdstrand: if I remove the cache file and reload the profile things are ok. | 16:04 |
| zyga-suse | the cache looks good though | 16:04 |
| jdstrand | ok | 16:04 |
| jdstrand | so, I think the revert needs to remove the cache file unconditionally | 16:04 |
| zyga-suse | mvo: is that september 27th the moment when the profile was loaded? | 16:04 |
| zyga-suse | er | 16:04 |
| zyga-suse | when the image was built | 16:04 |
| mvo | zyga-suse: yes | 16:04 |
| jdstrand | it'll be regenerated on reboot | 16:05 |
| zyga-suse | jdstrand: when is the cache not used? | 16:05 |
| jdstrand | it's always used as part of boot | 16:05 |
| zyga-suse | always even if stale? | 16:05 |
| zyga-suse | is there any staleness check? | 16:05 |
| jdstrand | no | 16:05 |
| jdstrand | yes | 16:05 |
| jdstrand | it doesn't use a stale cache. it has a check. it will regenerate it if stale | 16:06 |
| zyga-suse | what is the condition? | 16:06 |
| jdstrand | the problem is it doesn't look stale | 16:06 |
| jdstrand | mtime | 16:06 |
| mvo | could we rework the cache? I remember we had issues with this before, I vaguely remember some discussion to move to md5sum/sha1 or similar for cache comparing | 16:06 |
| zyga-suse | aha | 16:06 |
| zyga-suse | I see | 16:06 |
| jdstrand | the cache file is always going to be newer than the reverted core's profile | 16:06 |
| zyga-suse | jdstrand: I think this will explain what I saw earlier as well | 16:06 |
| zyga-suse | jdstrand: the issue that federico ran into right in front of my eyes | 16:07 |
| jdstrand | mvo: just remove the cache files on revert | 16:07 |
| zyga-suse | jdstrand: all of them? /var/cache/apparmor /etc/apparmor/cache ? | 16:07 |
| jdstrand | that is the fast and correct fix for today. if want to use checksums, that could come later | 16:07 |
| jdstrand | no | 16:07 |
| jdstrand | we are talking about snap-confine. just remove the /etc/apparmor.d/cache/*snap-confine* profiles on core revert | 16:08 |
| mvo | jdstrand: I just found something, it makes me weep a bit | 16:08 |
| * zyga-suse hugs mvo and is curious to know | 16:08 | |
| mvo | jdstrand: https://bugs.launchpad.net/snappy/+bug/1460152 | 16:08 |
| mup | Bug #1460152: apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates) <patch> <Snappy:Fix Released by mvo> <Snappy 15.04:Fix Released by mvo> <apparmor (Ubuntu):Fix Released> <https://launchpad.net/bugs/1460152> | 16:08 |
| zyga-suse | oh my https://code.launchpad.net/~mvo/ubuntu/vivid/ubuntu-core-config/lp1460152-workaround/+merge/261179 | 16:09 |
| zyga-suse | mvo: we barely notice this bug because the profile for snap-confine rarely changes in ways that newer revision can do *less* than the older revision | 16:10 |
| zyga-suse | mvo: where shall we change this? | 16:11 |
| zyga-suse | mvo: in request snapd restart? | 16:11 |
| zyga-suse | mvo: or in the apparmor backend? | 16:11 |
| zyga-suse | mvo: we could purge the cache whenever core is installed | 16:12 |
| zyga-suse | mvo: just in case | 16:12 |
| zyga-suse | jdstrand: is the apparmor cache location the same in various distros? | 16:12 |
| jdstrand | in thinking about this, on core, should rm -rf /etc/apparmor.d/cache/* | 16:12 |
| jdstrand | on refresh/revert of the core snap | 16:12 |
| zyga-suse | jdstrand: yeah, because new policy can be inside and we won't know | 16:12 |
| jdstrand | zyga-suse: we are talking about Ubuntu Core here. on classic, re-exec solves all this ith per-revision profiles | 16:13 |
| jdstrand | so on Ubuntu Core, we can depend on /etc/apparmor.d/cache | 16:13 |
| zyga-suse | jdstrand: yes, but what about !snap-confine profiles? | 16:13 |
| zyga-suse | jdstrand: well, we ge-gen those on startup now | 16:13 |
| jdstrand | what about them? | 16:13 |
| zyga-suse | jdstrand: I think you are right, those are fine | 16:14 |
| * jdstrand is confused. I thought we were talking about snap-confine | 16:14 | |
| zyga-suse | jdstrand: yes but I was thinking that the cache issue may affect other profiles too | 16:14 |
| zyga-suse | jdstrand: but I agree with you that it is just for this single profile | 16:14 |
| jdstrand | snap profiles? | 16:14 |
| mvo | jdstrand: what was the downside of https://bugs.launchpad.net/snappy/+bug/1460152/+attachment/4409034/+files/lp1460152-apparmor.diff ? this syncs mtime of profile and cache, if there is a difference we re-generate. cheap and (at first glance) reliable, no? | 16:15 |
| mup | Bug #1460152: apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates) <patch> <Snappy:Fix Released by mvo> <Snappy 15.04:Fix Released by mvo> <apparmor (Ubuntu):Fix Released> <https://launchpad.net/bugs/1460152> | 16:15 |
| jdstrand | no-- cause of the overlord or whatever making sure if they are different they are regenerated | 16:15 |
| elopio | kyrofa: sorry, I didn't see the error and now that link is an execution in progress. | 16:17 |
| mvo | jdstrand: I can prepare something that "rm -rf /etc/apparmor.d/cache/* on core devices when the core snap changes. but I still would to discuss how to make apprmor itself more reliable here" | 16:17 |
| elopio | kyrofa: when I get repeated errors, I report them in a bug even if it's not clear if they are snapcraft's fault. | 16:17 |
| kyrofa | elopio, good idea. I'll do that again if I see it | 16:18 |
| mvo | jdstrand: if you think the syncing is ugly, just embedding the timestamp of the source file in the cache is also super cheap or putting an .aux file next to it with the timestamp | 16:18 |
| jdstrand | mvo: the downside is that apparmor would need an SRU everywhere. that will be too slow for you | 16:18 |
| mvo | jdstrand: *cough* dput ppa:snappy-dev/image apparmor_13371+ppa1_source.changes. problem solved until the SRU is in | 16:19 |
| mvo | jdstrand: it seems more correct to me and I'm happy to give it a shot | 16:20 |
| jdstrand | mvo: I'll defer to jjohansen on the best approach. It looks like he started to pick up that work | 16:20 |
| jdstrand | mvo: you know I very much hate that :P | 16:20 |
| jdstrand | mvo: I would very much prefer to not be ahead of upstream apparmor on this point | 16:20 |
| kyrofa | elopio, is snapcraft#1629 good to go? | 16:20 |
| mup | PR snapcraft#1629: lxd: fix the unit test for the user id map <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1629> | 16:20 |
| elopio | yes, it even got a green autopkgtest execution | 16:21 |
| zyga-suse | mvo: so we need a .6? | 16:21 |
| mvo | jdstrand: thats ok, I can do both: add code to snapd and poke at apparmor (or poke you guys to do that) | 16:21 |
| zyga-suse | mvo: I think we need a .6 :/ | 16:21 |
| mvo | zyga-suse: no, not a regression | 16:21 |
| zyga-suse | mvo: it breaks revert | 16:21 |
| zyga-suse | mvo: CE won't like that | 16:21 |
| kyrofa | elopio, excellent, I'm merging it. So tired of bad autopkgtests | 16:21 |
| mvo | zyga-suse: but its stable->edge so far, no? | 16:21 |
| zyga-suse | no, this is ever since we have snap-update-ns | 16:21 |
| elopio | thanks kyrofa. | 16:21 |
| mvo | zyga-suse: if its old-stable->stable thats different | 16:21 |
| zyga-suse | mvo: hmmmm | 16:21 |
| jdstrand | mvo: note that we are probably going to do an apparmor SRU for the af_unix issue, so maintaining an extra apparmor in a ppa makes that more complicated | 16:21 |
| zyga-suse | not sure | 16:21 |
| * zyga-suse looks | 16:22 | |
| jdstrand | mvo: yes, rm -rf in PR +1. working with upstream on better parser +1 | 16:22 |
| mvo | jdstrand: my suggestion about the ppa is only to quicken the sru process, i.e. we would not maintain something, we would just upload something that you guys have already in the upstream git | 16:22 |
| mvo | jdstrand: let me know if I can help, happy to poke at this again, the fact that I worked on this 2y ago and it came back indicates to me that I don't want to do this again in 2y :/ | 16:23 |
| jdstrand | mvo: right, but then we'd need to remember to include that in the SRU so it isn't dropped | 16:23 |
| mvo | jdstrand: agreed | 16:23 |
| jdstrand | I'm not saying it isn't impossible or anything, just, we need to think through coordination, etc | 16:23 |
| mvo | jdstrand: as long as we have a regression test in our tree things should be ok. | 16:24 |
| mup | PR snapcraft#1629 closed: lxd: fix the unit test for the user id map <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1629> | 16:24 |
| zyga-suse | mvo: dccfcb26c5fe59fb259a800a22208f355e79d6bd is the patch that changes the policy | 16:26 |
| jdstrand | mvo: looking at trunk, it seems like there were commits related to this | 16:26 |
| zyga-suse | mvo: I don't see it in 2.28 release branch | 16:26 |
| zyga-suse | mvo: so I think it's looking like a quiet weekend | 16:26 |
| mvo | zyga-suse: :) | 16:28 |
| mvo | zyga-suse: yay, big hugs to the CE QA team then | 16:28 |
| jdstrand | mvo: with a regression fix: https://bugs.launchpad.net/apparmor/+bug/1484178 | 16:29 |
| mup | Bug #1484178: Policy cache file mtimes are not being set correctly <AppArmor:Fix Released by tyhicks> <apparmor (Ubuntu):Fix Released by jdstrand> <https://launchpad.net/bugs/1484178> | 16:29 |
| jdstrand | mvo: so it looks like a version of your patch made it in, but "Starting in AppArmor 2.10, the policy cache file's mtime was meant to be updated to be equal to the newest mtime detected on the profile and abstraction files used to generate the policy cache file" | 16:29 |
| jdstrand | mvo: this was something I was trying to think through. the include files are going to be a problem on revert | 16:30 |
| jdstrand | I think | 16:30 |
| jdstrand | so the parser is supposed to use the newest value of mtime between the profile and include files | 16:31 |
| tyhicks | that's correct | 16:32 |
| jdstrand | so if /etc/apparmor.d/tunables/global is newer than /etc/apparmor.d/*snap-confine*, the mtime of global will be used for the cache | 16:32 |
| jdstrand | if we revert but global did not change, then the mtime will be the same and the cache won't be stale | 16:33 |
| kyrofa | kalikiana, snapcraft#1412 has conflicts | 16:33 |
| mup | PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412> | 16:33 |
| tyhicks | jdstrand: sounds like the cache read should be skipped in such a situation | 16:34 |
| tyhicks | the '--skip-read-cache' option of apparmor_parser | 16:34 |
| jdstrand | tyhicks: which part are you talking about? | 16:35 |
| jdstrand | tyhicks: in snapd on refresh/revert? | 16:35 |
| tyhicks | jdstrand: yes | 16:35 |
| jdstrand | for core | 16:35 |
| tyhicks | yes | 16:35 |
| jdstrand | that would work too, but having the stale cache files around seems wrong too | 16:35 |
| jdstrand | so long as we use --write-cache, that would be ok | 16:36 |
| tyhicks | jdstrand: you're talking about stale cache files for app snaps? | 16:36 |
| zyga-suse | the parser could unlink them | 16:36 |
| jdstrand | tyhicks: no, snap-confine | 16:36 |
| jdstrand | zyga-suse: I don't think the parser is the place to do this. it is doing what everyone asked | 16:37 |
| jdstrand | it still has a concept of 'newer' | 16:37 |
| jdstrand | in terms of what it is including. if there is a concept of 'newer' then reverts are problematic to handle in the parser itself | 16:37 |
| * zyga-suse feels that cache in apparmor is not as transparent as it should and needs hand-holiding | 16:37 | |
| * mvo dinner | 16:38 | |
| jdstrand | tyhicks: the problem is on core revert, the newer cache file is still used but with an older snap-confine. that broke things | 16:39 |
| mvo | yeah, I think hashes or list of mtimes of the inputs would be more reliable | 16:39 |
| * mvo vanishes | 16:39 | |
| * zyga-suse too | 16:39 | |
| jdstrand | mvo: if you recall from the bug, hashes will slow things down | 16:39 |
| tyhicks | jdstrand: how about simply updating the mtime of the profile on revert? | 16:39 |
| jdstrand | tyhicks: that could work too | 16:39 |
| jdstrand | tyhicks: well, no. it is in rofs | 16:40 |
| tyhicks | imo, that's what needs to happen | 16:40 |
| tyhicks | oh | 16:40 |
| jdstrand | /etc/apparmor.d is read-only. /etc/apparmor.d/cache is rw | 16:40 |
| jdstrand | mvo: the cache is meant to be pretty much as fast as you can read them off the disk. if we add hashes, consider hundreds or more profiles | 16:41 |
| mvo | jdstrand: if hashes are slow we could store the [(input1,mtime1),...(inputN,mtimeN)] and compare those, that should be quick | 16:41 |
| zyga-suse | jdstrand: out of my PRs I'd like your review on https://github.com/snapcore/snapd/pull/4008 -- it's long but most of that is tests | 16:42 |
| mup | PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008> | 16:42 |
| zyga-suse | jdstrand: it contains go's version of mkpath | 16:42 |
| jdstrand | zyga-suse: it is already on my list. I'll put it towards the top. I've seen commits as recent as today-- is it ready for another review? | 16:42 |
| zyga-suse | jdstrand: freeze/thaw logic that's new | 16:42 |
| mup | PR snapd#4059 opened: tests: add test that checks core reverts on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/4059> | 16:43 |
| mvo | jdstrand: please don't get me wrong, I don't want to be pushy or anything, happy to help wit hthis stuff. but dinner now really :) | 16:43 |
| jdstrand | mvo: that would require changes to the format on disk and thus require jjohansen's input | 16:43 |
| zyga-suse | jdstrand: and small glue that uses mkdir when we want to mount something but target is gone | 16:43 |
| kyrofa | elopio, will python3 -m unittest discover -b -v -s integration_tests" not run _all_ the integration tests, including the packages below? | 16:43 |
| zyga-suse | jdstrand: there's loads of unit tests and one comprehensive integration test | 16:44 |
| elopio | Not until tomorrow | 16:44 |
| kyrofa | elopio, isn't that how discover works? | 16:44 |
| jdstrand | mvo: checking and comparing the mtimes of everything is likely performant enough. I'm not sure of other ramifications. maybe it makes sense to bring up on the apparmor ML? | 16:44 |
| * jjohansen reads backscroll to pickup context | 16:44 | |
| tyhicks | jjohansen: don't spend time reading all of backscroll | 16:44 |
| tyhicks | jjohansen: I'll summarize | 16:44 |
| elopio | kyrofa: I'm moving some integration tests to a general suite, so we can properly filter. | 16:45 |
| zyga-suse | jjohansen: hey, long time no see :) | 16:45 |
| jdstrand | zyga-suse: I think I heard "yes, it is ready for you to review"? | 16:45 |
| jjohansen | hi zyga-suse | 16:45 |
| zyga-suse | jdstrand: hmm? | 16:45 |
| zyga-suse | jdstrand: I think it's ready now | 16:45 |
| zyga-suse | jdstrand: NB, this is the code without any overlayfs | 16:45 |
| jdstrand | 11:42 < jdstrand> zyga-suse: it is already on my list. I'll put it towards the op. I've seen commits as recent as today-- is it ready for another review? | 16:46 |
| zyga-suse | jdstrand: so should be non-controversial | 16:46 |
| zyga-suse | jdstrand: ah, I didn't notice | 16:46 |
| kyrofa | elopio, ah, integration_tests/snapd, integration_tests/store etc. aren't packages, I see | 16:46 |
| elopio | kyrofa: at some point, somebody, probably not me but maybe... removed the init.py from some subdirs, so they are not discovered. | 16:46 |
| zyga-suse | jdstrand: it's ready, the code today was more tests and shrinking the diff for next PRs | 16:46 |
| kyrofa | elopio, gotcha | 16:46 |
| tyhicks | jjohansen: on snap revert, snapd is rolling back profiles to old versions but there could be an include file that is newer so the mtime of the policy cache file isn't updated and the old cache file is loaded | 16:46 |
| jdstrand | zyga-suse: ok | 16:46 |
| niemeyer | zyga-suse: You've got a review | 16:46 |
| zyga-suse | niemeyer: thank you | 16:46 |
| niemeyer | zyga-suse: Thanks for the PR! | 16:46 |
| elopio | kyrofa: I'm moving everything around to make the split for Travis a little less painful. | 16:47 |
| niemeyer | zyga-suse: Ah, one more note, can we please drop the "generated-" prefix and use something more contextual? | 16:47 |
| niemeyer | zyga-suse: Every profile we have is generated | 16:47 |
| tyhicks | jjohansen: apparmor's policy cache implementation assumes that mtimes should only ever go forward but that's not the case when reverting back to older, read-only versions of a profile | 16:47 |
| jdstrand | tyhicks: that summarizes things ok, but more precisely, it is core snap revert, which includes system profiles in /etc/apparmor.d. non-core snap profiles are not affected because of how snapd manages them. there is an interplay with the /etc/apparmor.d profiles and the init script that is causing trouble | 16:47 |
| zyga-suse | niemeyer: whatever we want, we just need to have a prefix | 16:47 |
| tyhicks | jdstrand: sure but jj doesn't need that info | 16:48 |
| niemeyer | zyga-suse: What's common across all of the files? | 16:48 |
| tyhicks | at least, I didn't think he did :) | 16:48 |
| zyga-suse | niemeyer: so far we only have one file | 16:48 |
| jdstrand | tyhicks: I thought the system profile point was important, but ok | 16:48 |
| zyga-suse | niemeyer: but the theme is "local tweaks to work around something" | 16:48 |
| niemeyer | zyga-suse: How about nfs then? | 16:48 |
| niemeyer | zyga-suse: Or perhaps... | 16:48 |
| jjohansen | tyhicks: ? ah, so what you want is the hashing consistency check | 16:48 |
| zyga-suse | niemeyer: we need a glob to match the set we manage, we can juse use `*` | 16:49 |
| zyga-suse | niemeyer: then we can drop generated- | 16:49 |
| niemeyer | zyga-suse: If it's just one file, it'd be better to use that one file instead | 16:49 |
| jjohansen | which we started on ages ago, and never finished because its priority was dropped | 16:49 |
| jdstrand | jjohansen: I think what mvo wants is that if the profile or any included files are different, then regenerate the cache. how that is done I don't think he cares | 16:49 |
| tyhicks | jjohansen: I'm not asking for that but the snapd folks want something along those lines or for a list of profile and include file mtimes to be stored alongside the policy cache file | 16:49 |
| niemeyer | zyga-suse: nfs-support is a good name for the file | 16:50 |
| zyga-suse | ok | 16:50 |
| zyga-suse | I'll review the review comments and tweak this, I think it should land tomorrow | 16:50 |
| niemeyer | zyga-suse: The file is included/imported by name, right, not by glob? | 16:50 |
| zyga-suse | niemeyer: no | 16:50 |
| zyga-suse | niemeyer: everything in the directory is imported | 16:51 |
| zyga-suse | niemeyer: apaprmor includes are recursive | 16:51 |
| niemeyer | zyga-suse: Oh? | 16:51 |
| jdstrand | jjohansen: I speculated in the old bug that prompted the setting of mtime of the cache to that of the newest file patch that a hash of everything would be slow, so people thought about storiing of the list of all the mtimes and comparing those | 16:51 |
| niemeyer | zyga-suse: Okay, so the glob needs to be * indeed | 16:51 |
| jjohansen | jdstrand: well, its either store everything and compare. Or a hash and compare | 16:51 |
| niemeyer | Otherwise we may be including things we have no idea about | 16:51 |
| jdstrand | jjohansen: right | 16:51 |
| tyhicks | jjohansen: I'm currently of the opinion that snapd is subverting the policy cache, out from under apparmor_parser, and should be smart enough to use --skip-read-cache when appropriate | 16:51 |
| tyhicks | jdstrand: we could hash all the mtimes instead of hashing the profiles and include files themselves | 16:52 |
| jdstrand | it is true that snapd is moving forward and backward in time in arbitrary ways with the concept of revert | 16:52 |
| jdstrand | tyhicks: that's interesting | 16:52 |
| jjohansen | jdstrand: the hashing isn't that slow when you realize we read in those files already anyways, because we the time comparison is in the parse | 16:53 |
| tyhicks | and it doesn't have to be an cryptographic hash | 16:53 |
| jjohansen | right | 16:53 |
| kyrofa | snappy-m-o, autopkgtest 1627 xenial:amd64 | 16:53 |
| snappy-m-o | kyrofa: I've just triggered your test. | 16:53 |
| jjohansen | I believe I was using murmer hash3, which is faster than a crypto hash but still fairly good | 16:54 |
| jdstrand | jjohansen: did you profile its performance? | 16:54 |
| tyhicks | jjohansen: I used djb2 for my old multiple policy cache implementation | 16:55 |
| jjohansen | jdstrand: it was never completed to the point where performance could be checked, but it should be at least a couple order of magnitudes faster than the disk read | 16:55 |
| jdstrand | cause while this is prompted by the system cache and the system profile in ro media, if we introduce a hash check I would expect it to be used for all profile loads (where we are considering the use of the cache), which could easily be hundreds of profiles | 16:55 |
| jjohansen | so I expect you won't even notice it | 16:55 |
| jjohansen | jdstrand: right, which brings us to another optimization that has never been finished. Calling the parser once with all the profiles to load and caching each file once (which means hashing them once) | 16:57 |
| jdstrand | just so it is understood why a crypto hash is not required, the idea is that if you can modify the files in /etc/apparmor.d{,/cache} to create a collision, you may as well just change them | 16:57 |
| tyhicks | jdstrand: speed is the #1 reason followed by what you just said | 16:58 |
| jdstrand | jjohansen: that would be quite nice since we are using templates, etc (we could actually optimize what snapd does to leverage that even more when the feature was there). I'm guessing that is quite far out though | 16:58 |
| jjohansen | jdstrand: we are hardening against an attack, this is just an optimization, and detecting files changes. A good hash makes that almost guarenteed | 16:58 |
| * zyga-suse cannot find any bug reports about NFS and apparmor | 16:59 | |
| jjohansen | a crypto hash would make the odds against an accidental collision even better, but for this, not worth the cost | 16:59 |
| tyhicks | if we do hashing, I'd think that we would want to use something very fast (djb2/murmur) and also continue to check the most recent mtime (like what we're doing today) to slightly reduce the chance of a collision under normal usage (doesn't help with snapd's revert situation) | 17:00 |
| jdstrand | right, I understand the reasoning, I just wanted it explicitly stated for posterity :) | 17:00 |
| jjohansen | zyga-suse: oh they have happened in the past, but you may need to file a new one. I am not sure there are any in launchpad, perhaps suse bugzilla | 17:00 |
| jdstrand | zyga-suse: let me check. I thought there was one | 17:00 |
| zyga-suse | jjohansen: aha, I'll look at suse then | 17:00 |
| zyga-suse | thank you! | 17:00 |
| jjohansen | tyhicks: yep that was the plan | 17:00 |
| zyga-suse | I looked at apparmor on LP and general google | 17:00 |
| tyhicks | jjohansen: do you agree that we just hash the mtimes rather than the file contents? | 17:01 |
| jjohansen | zyga-suse: I remember something around 2004-2006, can't remember the details, tony dealt with it | 17:01 |
| jjohansen | tyhicks: uh no | 17:01 |
| jdstrand | zyga-suse: I think I was only thinking of https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552, which you are familiar with | 17:02 |
| mup | Bug #1662552: snaps don't work with NFS home <snapd:In Progress by zyga> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1662552> | 17:02 |
| jjohansen | tyhicks: we can consider it, but its not something I have spent enough time with to agree | 17:02 |
| zyga-suse | hmm, it feels I should file a new bug on apparmor specifically | 17:03 |
| jjohansen | zyga-suse: please do | 17:03 |
| jdstrand | tyhicks, jjohansen: to be clear, this conversation is about a proper solution. mvo and the snapd team will implement something to work with what is currently there (maybe --skip-read-cache, maybe rm -f of the cache files, etc) | 17:04 |
| tyhicks | jdstrand, jjohansen: I think that this was a useful technical deep dive but we don't currently have plans to work on this for 18.04 | 17:04 |
| jdstrand | mvo: ^ | 17:04 |
| zyga-suse | jjohansen: https://bugs.launchpad.net/apparmor/+bug/1724903 | 17:06 |
| mup | Bug #1724903: NFS access is not transparent to processes with apparmor profile containing network rules <AppArmor:New> <https://launchpad.net/bugs/1724903> | 17:06 |
| zyga-suse | jjohansen: if you have insight into how this works and why the workaround is needed could you pleaseadd it there | 17:08 |
| zyga-suse | I'm only aware of the surface of the issue | 17:08 |
| jjohansen | zyga-suse: hrmmm, my guess is because nfs is using the task asking the files cred instead of a kernel cred via the act as cb when doing the network stuff. But I will have to actually dig into it to be sure | 17:10 |
| jjohansen | zyga-suse: how about I distract you with the fedora kernel I gave stgraber instead ;) | 17:11 |
| zyga-suse | jdstrand: :D | 17:11 |
| zyga-suse | fedora kernel? | 17:11 |
| stgraber | :) | 17:12 |
| zyga-suse | jjohansen: note that that was just a gentle idea, I don't want you to drop what you are doing and work on that bug :) | 17:12 |
| jjohansen | hence the distraction to keep you occupied, so you don't realize I haven't worked on the bug :) | 17:12 |
| zyga-suse | I think I need to EOD now, kids are running unchecked here and I bet they have homework :) | 17:13 |
| mvo | jdstrand, tyhicks would you accept patches if there is agreement about the approach? | 17:23 |
| tyhicks | mvo (cc jjohansen): definitely :) | 17:24 |
| mvo | tyhicks: cool! and agreement is fast-hash+mtime? (cc jjohansen)? | 17:25 |
| jjohansen | zyga-suse: yes fedora kernel, its stack apparmor and selinux | 17:25 |
| jjohansen | mvo: give me a minute | 17:26 |
| mvo | jjohansen: sure :) | 17:27 |
| zyga-suse | jjohansen: oh, shiny! | 17:31 |
| zyga-suse | jjohansen: do you have RPM? | 17:31 |
| jjohansen | zyga-suse: for the kernel only atm | 17:31 |
| jjohansen | zyga-suse: http://people.canonical.com/~jj/fedora/ | 17:32 |
| stgraber | jjohansen: one thing that was mentioned last week is that we could probably call the apparmor tools from within the core snap | 17:32 |
| zyga-suse | jjohansen: 1.1G? | 17:32 |
| jjohansen | give me a minute and I can send you an email with some instructions | 17:32 |
| stgraber | jjohansen: at which point we'd only really need apparmor support in the kernel, everything else would be coming from the core snap | 17:32 |
| jjohansen | zyga-suse: its all the rpms from the kernel build | 17:32 |
| jjohansen | stgraber: yep that is a possibility, just wanted to make sure zyga-suse understood there is no apparmor userspace rpm atm | 17:33 |
| zyga-suse | jjohansen: ack, I understand | 17:36 |
| cachio | niemeyer, is it any way to stop the auto-refresh? | 17:39 |
| kyrofa | cjwatson, any chance you're still around? | 17:41 |
| cjwatson | kyrofa: about to finish. what is it? | 17:43 |
| kyrofa | cjwatson, quick question | 17:43 |
| Pharaoh_Atem | jjohansen: what is this? | 17:43 |
| kyrofa | cjwatson, back when we were discussing the `architectures` key at the sprint, we settled on using the grammar we already have | 17:44 |
| kyrofa | cjwatson, but this is something LP will need to parse | 17:44 |
| kyrofa | cjwatson, we discussed your using the grammar processing we already wrote, and I'd like to quickly discuss how you'd like to consume that | 17:45 |
| cjwatson | kyrofa: and I think what Sergio (or you?) said was that the relevant bit of the parser would be made available on PyPI as a thing we could use | 17:45 |
| Pharaoh_Atem | jjohansen: it's 1.1GB! | 17:45 |
| jjohansen | Pharaoh_Atem: development work towards LSM stacking, which will allow for multiple LSMs on a system at once. So if enabled, apparmor based snaps would work (in enforcing, not dev mode) on an selinux fedora | 17:45 |
| jjohansen | or you could use and Ubuntu container with apparmor on an selinux fedora | 17:45 |
| jjohansen | etc | 17:45 |
| kyrofa | cjwatson, that was my question: is that best for you? Or do you simply want it as part of the public API in snapcraft so you can import it, etc. | 17:45 |
| jjohansen | Pharaoh_Atem: its all the kernel rpms from a kernel build, you don't need all of them, just like an ubuntu kernel build you get lots of different debs out, but only need 1 or 2 for most things | 17:46 |
| cjwatson | kyrofa: PyPI would be much better for us; recall that LP is running in fairly tightly-controlled environments. | 17:46 |
| kyrofa | cjwatson, yep, good deal, that's all I needed! Just planning out tasks | 17:46 |
| kyrofa | cjwatson, thank you :) | 17:47 |
| cjwatson | kyrofa: And while we do still consume a few Python packages from the system, we want to move away from doing that. | 17:47 |
| Pharaoh_Atem | jjohansen: does someone want to start talking to the Fedora kernel team about this? | 17:47 |
| Pharaoh_Atem | because this is not something to enable lightly | 17:47 |
| Pharaoh_Atem | jjohansen: where's the src.rpm? | 17:47 |
| kyrofa | cjwatson, makes sense | 17:47 |
| jjohansen | Pharaoh_Atem: no, none of its upstream, its a work in progress. The selinux people are aware of it, we have been discussing LSM stacking for 5 years, slowly working towards it | 17:48 |
| jjohansen | Pharaoh_Atem: hrmm, if its not in the tarball then the build must have dropped it in a different location | 17:48 |
| Pharaoh_Atem | it's in SRPMS in the rpmbuild/ tree | 17:48 |
| jjohansen | I tared up the build dir | 17:48 |
| Pharaoh_Atem | looks like you archived rpmbuild/RPMS/* | 17:49 |
| Pharaoh_Atem | but not rpmbuild/SRPMS/* | 17:49 |
| jjohansen | Pharaoh_Atem: ack, so a different location, I didn't check, and its been a long time since I have dealt with rpm packaging | 17:49 |
| Pharaoh_Atem | jjohansen: you should get out more ;) | 17:50 |
| === JoshStrobl is now known as JoshStrobl|Nap | ||
| jjohansen | this was a quick one off for a demo, it wasn't meant for public consumption | 17:50 |
| jjohansen | well general public, people are welcome to play but I haven't even put together a good list of instructions | 17:51 |
| Pharaoh_Atem | jjohansen: feel free to set up something on https://copr.fedorainfracloud.org/ | 17:51 |
| Pharaoh_Atem | it's not particularly hard ;) | 17:51 |
| jjohansen | the plan was to fix some bugs, and make the git tree public, along with some instructions | 17:51 |
| zyga-ubuntu | jjohansen: I can help | 17:51 |
| Pharaoh_Atem | the only thing I'm not particularly happy about is that the LSM stacking doesn't help anything for RHEL/CentOS users | 17:52 |
| jjohansen | zyga-ubuntu: thanks for the offer, I will take you up on it, but it will be a few days before I can get back to playing with this | 17:52 |
| Pharaoh_Atem | as in, even if we got AppArmor enabled in Fedora, and had the userspace utilities packaged (not particularly difficult), it won't help for RHEL/CentOS users who use the RHEL kernel | 17:52 |
| zyga-ubuntu | Pharaoh_Atem: we won't necessairly have to package them | 17:53 |
| Pharaoh_Atem | zyga-ubuntu: trust me, that *will* be a requirement of the kernel team | 17:53 |
| jjohansen | Pharaoh_Atem: hrmm, maybe apparmor was enabled in at one of those at one point. not default, and not supported but enabled | 17:53 |
| jjohansen | s/enabled/compiled in/ so some one could set it on the grub kernel line | 17:53 |
| Pharaoh_Atem | jjohansen: it's not currently enabled in the Fedora kernel or the RHEL7 kernel | 17:54 |
| Pharaoh_Atem | as in, not compiled in at all | 17:54 |
| Pharaoh_Atem | zyga-ubuntu: it's not an unreasonable requirement to package and maintain the userspace for AppArmor | 17:54 |
| jjohansen | Pharaoh_Atem: yep, that may change. stgraber did a demo of an ubuntu container running on fedora with selinux enforcing the host and apparmor the guest | 17:55 |
| jjohansen | being able to fully support other OS containers is a compelling use case | 17:55 |
| Pharaoh_Atem | well, LXD will be fine with SELinux across the board | 17:55 |
| Pharaoh_Atem | I fixed the SELinux policy to add the LXD binaries, so now LXD just has to use it | 17:55 |
| Pharaoh_Atem | jjohansen: most people are fine with security systems being disabled | 17:56 |
| Pharaoh_Atem | and historically, it's been a huge burden to be an AppArmor user | 17:56 |
| Pharaoh_Atem | though hopefully that is changing with the more upstream-y policy of AppArmor team | 17:57 |
| skjensen | Any where I can find the source for building this kernel? https://code.launchpad.net/~snappy-dev/+snap/linux-generic-bbb/+build/76303 Downloading it and using it as an extra snap still give me the with different signatures on the kernel and gadget.. :( | 17:59 |
| Pharaoh_Atem | so at some point soon, kyrofa and zyga-ubuntu will work with the lxd copr packager to bring those into Fedora mainline | 17:59 |
| cjwatson | kyrofa: (BTW I don't particularly object if this is a matter of dumping snapcraft onto PyPI, but I also don't know whether that would be a pain due to non-standard packaging or whatever) | 18:01 |
| kyrofa | cjwatson, haha, me neither | 18:01 |
| cjwatson | kyrofa: though I guess adding all of snapcraft to our dependencies would bloat our virtualenv a *lot*, so it might be better if there were a more focused dependency split off from it, if that isn't too much hassle | 18:02 |
| cjwatson | kyrofa: oh, err - also, LP is currently Python 2 | 18:02 |
| kyrofa | cjwatson, oh nooooooo | 18:02 |
| kyrofa | Hahaha | 18:02 |
| cjwatson | kyrofa: making just the parser bilingual might be easier than making the whole thing bilingual | 18:03 |
| cjwatson | which I'm fairly sure you have no interest in | 18:03 |
| kyrofa | cjwatson, indeed, that's definitely a point in favor of refactoring into its own thing (which is what I was planning for anyway) | 18:03 |
| kyrofa | cjwatson, glad we talked, that changes my time estimate a little | 18:03 |
| cjwatson | I obviously want to get LP onto Python 3 eventually, but it's lots of code and lots of dependencies | 18:03 |
| Pharaoh_Atem | will LP become Python 3? | 18:04 |
| cjwatson | glad I thought of that, that obviously changes things | 18:04 |
| cjwatson | Pharaoh_Atem: ... as I just wrote :) | 18:04 |
| kyrofa | cjwatson, but not unreasonably so | 18:04 |
| Pharaoh_Atem | well, you want it to, doesn't mean that's actually planned :P | 18:04 |
| kyrofa | cjwatson, sure, no problem at all | 18:04 |
| Pharaoh_Atem | last time I talked to anyone about LP, they said the project is effectively dead :/ | 18:04 |
| kyrofa | But I appreciate the heads up | 18:04 |
| cjwatson | Pharaoh_Atem: they were lying | 18:04 |
| cjwatson | or misinformed | 18:05 |
| kyrofa | Pharaoh_Atem, it's a huge part of our infra | 18:05 |
| cjwatson | that sort of thing makes me quite cross because it erases e.g. my work | 18:05 |
| Pharaoh_Atem | kyrofa: plenty of people run on dead projects :) | 18:05 |
| Pharaoh_Atem | cjwatson: it gets said *a lot* | 18:05 |
| cjwatson | Pharaoh_Atem: turns out that porting three-quarters of a million lines of Python with 200 dependencies to Python 3 is a ton of work, and when it has to be fitted around the edges of feature work, that's tough | 18:05 |
| Pharaoh_Atem | X_X | 18:05 |
| Pharaoh_Atem | it'll be impressive at the end :) | 18:06 |
| kyrofa | cjwatson, 200? That's all? | 18:06 |
| cjwatson | Pharaoh_Atem: it's significantly less funded than it used to be, certainly, but it is not dead and if you're hearing that I'd appreciate correcting the misapprehensions | 18:06 |
| Pharaoh_Atem | kyrofa: dude, GitLab has almost 600 dependencies | 18:06 |
| Pharaoh_Atem | you should be glad LP only has 200 | 18:06 |
| kyrofa | Pharaoh_Atem, I know, I wasn't being sarcastic, I'm genuinely surprised | 18:06 |
| cjwatson | kyrofa: last exact count was 208 I think | 18:06 |
| cjwatson | though that's not counting .deb-packaged deps | 18:07 |
| Pharaoh_Atem | cjwatson: the last couple of times I've reported LP bugs, people have messaged me to say to not bother | 18:07 |
| cjwatson | bah | 18:07 |
| Pharaoh_Atem | so *shrugs* | 18:07 |
| Pharaoh_Atem | sorry | 18:07 |
| cjwatson | next time please tell me who they are so I can correct them | 18:07 |
| Pharaoh_Atem | will do | 18:07 |
| cjwatson | possibly just by fixing the bug in question :P | 18:07 |
| kyrofa | Hahaha | 18:08 |
| cjwatson | if they're Canonical people, then I think it's actually really unprofessional | 18:08 |
| Pharaoh_Atem | yeah, it was definitely Canonicalers | 18:09 |
| Pharaoh_Atem | last year or so | 18:09 |
| Pharaoh_Atem | and again after I filed this: https://bugs.launchpad.net/launchpad/+bug/1678486 | 18:10 |
| mup | Bug #1678486: Enable watching Red Hat Bugzilla bugs <Launchpad itself:New> <https://launchpad.net/bugs/1678486> | 18:10 |
| cjwatson | I didn't notice that, but will look into the history | 18:10 |
| Pharaoh_Atem | the other time recently was when I asked about some of the incorrect project associations in LP | 18:11 |
| Pharaoh_Atem | I was told that no one maintains those and there's nothing anyone can do about it | 18:12 |
| cjwatson | That's not really about the LP codebase; those were always designed (rightly or wrongly) to be gardened by the community | 18:12 |
| Pharaoh_Atem | for example, the rpm5 guys hijacked the rpm registration on LP: https://launchpad.net/rpm | 18:13 |
| cjwatson | Pretty much anyone can change them, but the flip side is that pretty much anyone can change them back | 18:13 |
| Pharaoh_Atem | which means it's impossible to glue upstream rpm bugs to downstream issues | 18:13 |
| cjwatson | Oh, you don't mean the project/package associations, you mean metadata on projects? | 18:13 |
| Pharaoh_Atem | yeah | 18:13 |
| Pharaoh_Atem | as an example, this: https://bugs.launchpad.net/rpm/+bug/1475755 | 18:14 |
| mup | Bug #1475755: rpmbuild auto provides not listing shared libraries <RPM:Invalid> <https://launchpad.net/bugs/1475755> | 18:14 |
| cjwatson | Somebody must've specifically asked for that | 18:14 |
| cjwatson | Honestly I think it might be best to register a new project name for upstream rpm | 18:14 |
| cjwatson | Or we could fight it out with ~rpm5 to get the project renamed to rpm5 | 18:14 |
| Pharaoh_Atem | that's hard, since the "rpm" name is tied to the rpm package and all the tooling | 18:14 |
| cjwatson | The project name in Launchpad can't possibly be | 18:14 |
| cjwatson | I wasn't suggesting renaming rpm upstream ... | 18:15 |
| cjwatson | Just LP's view of it | 18:15 |
| Pharaoh_Atem | ah | 18:15 |
| Pharaoh_Atem | well, if the current "RPM" is renamed to RPM5 and kicked out of the associations, that'd fix it | 18:15 |
| cjwatson | Anyway, doesn't sound like you asked anyone who actually knew how this stuff is handled | 18:16 |
| * Pharaoh_Atem shrugs | 18:16 | |
| Pharaoh_Atem | I don't know anything | 18:16 |
| Pharaoh_Atem | all I know is what people tell me | 18:16 |
| Pharaoh_Atem | which apparently is 120% wrong :) | 18:16 |
| cjwatson | Can you (get somebody with suitable authority to) file a ticket on https://answers.launchpad.net/launchpad/+addquestion about the rpm issues with as much detail as possible? | 18:16 |
| cjwatson | It may take some archaeology to sort out what's been happening | 18:16 |
| Pharaoh_Atem | I can try | 18:16 |
| cjwatson | thanks | 18:16 |
| Pharaoh_Atem | no promises, as most of the rpm guys just want to stay the fuck away from rpm5 maintainer | 18:17 |
| Pharaoh_Atem | he's kind of a toxic asshole | 18:17 |
| cjwatson | well, LP by policy wants to stay away from that sort of thing, it's not our business; we just want to have a semi-reasonable modelling of what things are called | 18:17 |
| Pharaoh_Atem | yeah | 18:18 |
| cjwatson | Pharaoh_Atem: oh, re "you want it to, doesn't mean that's actually planned" - I landed a bunch of branches just today making concrete progress towards it, even if it does feel a bit drop-in-the-ocean sometimes :) | 19:16 |
| cjwatson | (lots of "from __future__ import absolute_import, print_function, unicode_literals" and associated fixups) | 19:19 |
| sergiusens | cjwatson and kyrofa snapcraft is already on pypi and yes we will split the package out as a stretch goal | 19:34 |
| kyrofa | sergiusens, you missed it: needs to be python2 | 19:34 |
| kyrofa | Can't be a stretch goal :) | 19:34 |
| sergiusens | It can still be stretch. | 19:36 |
| niemeyer | cachio: Stop one in progress? snap abort | 19:40 |
| niemeyer | cachio: Prevent it from even getting started? schedule the refresh | 19:40 |
| cachio | niemeyer, yes, testing that, because wait of the auto refresh is taking so long | 19:44 |
| niemeyer | cachio: The --last parameter of abort may come in handy | 19:44 |
| cachio | niemeyer, well the --last is not present inthe stable version so it makes the script fail | 19:55 |
| niemeyer | cachio: I'm pretty sure it is | 19:55 |
| niemeyer | cachio: It's been added a long while ago | 19:55 |
| cachio | niemeyer, https://paste.ubuntu.com/25774590/ | 19:56 |
| cachio | this stable release is from mack I guess | 19:56 |
| cachio | march | 19:56 |
| niemeyer | cachio: lol | 19:57 |
| niemeyer | cachio: I'm sure *some day* stable didn't have it :) | 19:57 |
| cachio | niemeyer, :) sadly, np, I'll continue working with the change id instead | 19:59 |
| === bashfulrobot is now known as bashfulrobot_AFK | ||
| === bashfulrobot_AFK is now known as bashfulrobot | ||
| facubatista | sergiusens, push metadata to the store: https://github.com/snapcore/snapcraft/pull/1634 | 20:51 |
| mup | PR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634> | 20:51 |
| mup | PR snapcraft#1634 opened: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634> | 20:51 |
| === JoshStrobl|Nap is now known as JoshStrobl|AFK | ||
| === JoshStrobl|AFK is now known as JoshStrobl | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!