| mborzecki | morning | 05:02 |
|---|---|---|
| mup | PR snapd#5177 closed: interfaces/builtin: allow access to libGLESv* too for opengl interface <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5177> | 05:29 |
| mup | PR snapd#5180 closed: tests/main/snap-service-timer: account for service timer being in the 'running' state <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5180> | 05:29 |
| mup | PR snapd#4497 closed: many: make rebooting of core on refresh immediate, refactor logic around it <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4497> | 05:34 |
| mvo | 5181 looks like an easy win if someone wants to do a quick review | 05:34 |
| mup | PR snapd#5181 closed: userd: add the "snap" scheme to the whitelist <Simple> <Created by oSoMoN> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5181> | 05:36 |
| mvo | yay, down to 25 PRs | 05:37 |
| * mvo hugs mborzecki | 05:37 | |
| mborzecki | yup | 05:37 |
| mborzecki | wonder if we should have a `snap timers` command, or include some information in the output of `snap services` that some services are timer activated | 05:40 |
| jamesh | mvo: hi. I was wondering if you could help me in registering another snap package for use in some snapd spread tests | 06:24 |
| jamesh | mvo: this is to test some interfaces for evolution-data-server's contacts and calendar APIs: so it needs a binary client. | 06:26 |
| mvo | jamesh: sure, I just need a (possible empty) snap and I can do this | 06:26 |
| jamesh | mvo: I've got a 13 MB test-snapd-eds_0.1_amd64.snap. Let me see if I can upload it somewhere | 06:28 |
| jamesh | mvo: or can you just register the name and add me as a collaborator? | 06:29 |
| mvo | jamesh: I can register the name but canont add people before there is a snap. its a store thing | 06:33 |
| wgrant | mvo: That changed a couple of weeks back. You can add collaborators from registration now. | 06:34 |
| mvo | wgrant: oh, cool | 06:34 |
| mvo | jamesh: I can add you without a snap now, thanks to wgrant for this tip | 06:35 |
| jamesh | okay. Well the snap is currently "test-snapd-eds" -- I used a single test snap for both calendar and contacts, since they share much of the client code | 06:36 |
| mvo | jamesh: you should have access now | 06:36 |
| jamesh | just as I finish uploading it to https://people.canonical.com/~jamesh/test-snapd-eds_0.1_amd64.snap :) | 06:37 |
| mvo | jamesh: heh, sorry | 06:38 |
| mborzecki | mvo: is there a need to have all *.deb and all *.a files in the all snap image for tests? | 06:38 |
| jamesh | no problem. Blame my slow ADSL :) | 06:38 |
| jamesh | I might actually get something faster this year, assuming the NBN rollout doesn't get delayed again | 06:39 |
| mvo | mborzecki: probably not, this is the integraton test? | 06:39 |
| mborzecki | mvo: yes in ubuntu-core prepare in #5134 | 06:39 |
| mup | PR #5134: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134> | 06:40 |
| mvo | jamesh: nice, how much do you have now and how much will you get (if I may ask)? | 06:40 |
| mvo | mborzecki: hm, hm, lets kill it. is that triggering the space problem? | 06:41 |
| mborzecki | mvo: yeah, the built image is running out of space, and we seem to take 60-80MB of space just with the archives and debs | 06:42 |
| jamesh | mvo: On ADSL currently, I've got about 7.6 Mb/s down, 0.9 up. NBN could potentially go as high as 100/40 (but probably won't hit that in practice) | 06:43 |
| mvo | jamesh: nice improvement! | 06:44 |
| mborzecki | jamesh: that's nice! is it expensive? | 06:52 |
| mborzecki | mvo: so the image is ~400MB, data partition is 346MB, once it's built we have 80MB left, /home/gopath (all of it is copied in prepare) is ~125MB | 06:53 |
| jamesh | mborzecki: haven't actually looked at the pricing, since it has seemed so far off. There are a number of speed tiers for the NBN ranging from 12/1 up to 100/40. So I'll probably be constrained by price rather than technology | 06:53 |
| jamesh | mborzecki: looks like my current ISP is offering AU$70/month for the 12 Mb/s plan, going up to AU$100 for 100 Mb/s | 06:55 |
| mborzecki | jamesh: i have some shitty adsl here, it's a bit outside of the city and i'm bit far from the concentrator, paying for 20mbps, actually getting ~12-13mbps, upside is it really costs pennies, ~9eur/month | 06:55 |
| mborzecki | jamesh: for comparison, if i were in the city, fiber 100/50 is ~10eur | 06:56 |
| jamesh | mborzecki: my current ADSL is $80/month for unlimited data (roughly what the 50MB/s NBN plan costs). That's a "naked DSL" plan, so there is no line rental on top of that (which would usually be ~ $25/month) | 06:58 |
| jamesh | actually, looks like I'm on a grandfathered plan at $70/month | 06:59 |
| jamesh | anyway: a lot more than what you're paying :) | 06:59 |
| mborzecki | jamesh: yeah | 06:59 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:03 |
| jamesh | mvo: Okay, I've an amd64 version of the snap uploaded and requested manual review. Thank you for your help. | 07:04 |
| pstolowski | zyga, i understood the problem you have on your box, i'm starting working on a fix | 07:05 |
| mvo | jamesh: it is in but you should talk to jamie to ensure the review-tools gets updated | 07:07 |
| pstolowski | mvo: hey, i needed to try to reproduce an issue with an older revision of edge yesterday, but apparently i'm not allowed to specify --revision for core unless i'm in the core snap dev group. i think i don't need older edge anymore (the bug is present in current one as well), but perhaps it may be useful in the future | 07:09 |
| pstolowski | mvo: can you add me to the core devs? | 07:10 |
| mvo | pstolowski: if you need it to reproduce I'm happy to add you, otherwise I prefer to keep the list as small as possible | 07:12 |
| pstolowski | mvo: i see, fair enough | 07:13 |
| pstolowski | mvo: i don't think reproducing this particular problem is important anymore, i understand it now | 07:14 |
| pstolowski | mvo: it's more about future cases like this | 07:14 |
| pstolowski | mvo: so i guess i'm fine if it's on case-by-case basis as need arises in the future, and can be temporary membership | 07:16 |
| mvo | pstolowski: thank you | 07:16 |
| mvo | pstolowski: that sounds reasonable | 07:16 |
| pstolowski | great | 07:16 |
| mup | PR snapd#5182 opened: snapstate/hooks: reorder autoconnect and reconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5182> | 07:18 |
| mborzecki | mvo: heh, ok, so the amount of free space is probably some factor of the amount of data in the system partition, with ondra's change, that size has shrunk, so there is less free space and the whole image is ~60% of the old size, https://paste.ubuntu.com/p/ghdFfrT9yJ/ | 07:19 |
| jamesh | mvo: I think I just have to live with the manual review until the new interfaces get merged to snapd: the review tools are driven off the current snapd version | 07:20 |
| mvo | jamesh: ok | 07:20 |
| mvo | mborzecki: oh, woah | 07:21 |
| mborzecki | mvo: well, it'd be nice if there was a way to pass desired amount of free space in the image | 07:23 |
| mvo | mborzecki: don't we calc the image size during the tests? or does our code have no control over that? (pardon my ignorance, I don't remember without looking to the test scripts) | 07:24 |
| mborzecki | mvo: we don't | 07:25 |
| mborzecki | mvo: well, for sure we don't need go *.a files and *.debs, this will save enough space, then we can think of hardcoding the image size or asking ubuntu-image guys how to force some amount of free space | 07:26 |
| mvo | mborzecki: hrm, hrm, I'm sure I miss something. the writable partition should be big. or are using something else here? | 07:27 |
| mvo | mborzecki: yeah, this all sounds dubious, iirc ubuntu-image has some code that calculates some free space area but there is iirc an option to override (and again, I think I miss something) | 07:27 |
| mborzecki | mvo: afaiu ondra's change, we no longer have 2 copies of the snaps, but instead /var/lib/snapd/snaps files are symlinked to ones from /var/lib/snapd/seed/snaps/ | 07:33 |
| ondra | mborzecki I don't think this has landed yet, there seem to be some mysterious lock down in tests | 07:36 |
| mborzecki | ondra: Could not get lock /var/lib/apt/lists/lock thing? iirc it was resolved by cachio or sth | 07:38 |
| ondra | mborzecki yeah that one | 07:38 |
| ondra | mborzecki what was the problem? and can somebody then restart test so we can re-check pull request | 07:38 |
| mborzecki | ondra: i'm looking in the no space left thing | 07:39 |
| mborzecki | ondra: your change seems to have triggered a problem elsewhere | 07:40 |
| mborzecki | ondra: i can keep looking into it and push a fix if you don't mind | 07:41 |
| mvo | mborzecki: isn't it "just" a matter of tweaking tests/lib/prepare.sh:348 (the ubuntu-image call) | 07:45 |
| ondra | mvo yeah that would great | 07:46 |
| mvo | mborzecki: and adding --image-size=1G or something? | 07:46 |
| mvo | mborzecki: or whatever we need (not sure if the file is sparse so we may need to ensure its not crazy :) | 07:46 |
| mborzecki | mvo: yes | 07:46 |
| mvo | mborzecki: cool, thank you! | 07:47 |
| mvo | mborzecki: and thanks for diving into it :) | 07:47 |
| * Son_Goku groans to life | 07:48 | |
| Chipaca | moin moin | 07:57 |
| mvo | hey Chipaca ! good morning | 07:58 |
| Chipaca | mvo: welcome back! how're things? | 07:58 |
| mvo | Chipaca: good, good. how are you? | 07:58 |
| mborzecki | mvo: hm --image-size 700M, the file is 700MB, partition is still 360MB :/ | 07:58 |
| === LarreaMikel1 is now known as LarreaMikel | ||
| mvo | mborzecki: :( booo | 07:58 |
| Chipaca | i'm without context, but resize was done from initramfs wasn't it? | 07:59 |
| mborzecki | mvo: sil2100 says we'd have to list the partition in gadget.yaml to set the desired size | 07:59 |
| mborzecki | Chipaca: https://github.com/snapcore/snapd/pull/5134#issuecomment-390898663 | 08:00 |
| mup | PR #5134: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134> | 08:00 |
| mvo | mborzecki: don't we use writable? | 08:00 |
| Chipaca | i suspected it was related to that :-) | 08:00 |
| mborzecki | mvo: writable? | 08:01 |
| Chipaca | i'm getting a «Running task 3777 on Doing: Reconnect interfaces for snap "core"» every 5 seconds | 08:01 |
| mborzecki | Chipaca: talk to pstolowski | 08:01 |
| Chipaca | pstolowski: OHAI | 08:01 |
| mvo | mborzecki: we have two partitons (well, three) on core, system-boot and writable - I'm pretty sure that --image-size used to work to make writable bigger (but not system-boot which should be irrelevant for this test or so I hope) | 08:02 |
| mborzecki | mvo: hm maybe it does not work if the partition is not listed in gadget.yaml | 08:04 |
| pstolowski | Chipaca: yes, there is at least one critical bug around there that I'm fixing right now. can your try abort it | 08:04 |
| pstolowski | ? | 08:04 |
| mvo | Chipaca: i started looking into the snapd snap and hit bug #1772584 - I think I might have an idea for a workaround but its all a bit messy | 08:04 |
| mup | Bug #1772584: Having a "snap" directory with actual content causes build failures <Snapcraft:New> <https://launchpad.net/bugs/1772584> | 08:04 |
| mborzecki | mvo: this is what we have now https://paste.ubuntu.com/p/qStWjg56NV/ | 08:04 |
| Chipaca | pstolowski: done | 08:04 |
| mvo | mborzecki: yeah, thats the default and this should work | 08:04 |
| mvo | mborzecki: I can look in a wee bit if that blocks you | 08:05 |
| Chipaca | mborzecki: got an error (not reported because I've got SNAPPY_TESTING=1) | 08:05 |
| Chipaca | um | 08:05 |
| Chipaca | pstolowski: ^ that one was for you | 08:05 |
| Chipaca | pstolowski: should I pastebin the report for you instead? | 08:06 |
| pstolowski | Chipaca: yes please, not sure what's the context | 08:06 |
| Chipaca | by error i mean an oops | 08:06 |
| Chipaca | pstolowski: I did "sudo snap abort --last=auto-refresh" | 08:07 |
| Chipaca | pstolowski: that succeeded | 08:07 |
| Chipaca | pstolowski: or more or less succeeded :-) | 08:07 |
| Chipaca | pstolowski: and that ended up in an error i think | 08:07 |
| Chipaca | pstolowski: I'll pastebin the whole thing, then you tell me | 08:07 |
| mborzecki | mvo: not really blocki, just wanted to push that PR a bit further | 08:08 |
| Chipaca | pstolowski: this is the log, including the oops at the end: https://pastebin.ubuntu.com/p/75RZSmVGmm/ | 08:08 |
| mvo | mborzecki: yeah, I think this is great (pusing it further) | 08:08 |
| Chipaca | pstolowski: let me know if you need anything further to figure it out | 08:09 |
| pstolowski | Chipaca: can you send me your state.json? | 08:11 |
| Chipaca | pstolowski: people.canonical.com:/home/john/state.json.bz2 | 08:16 |
| mup | PR snapd#5183 opened: snapcraft.yaml: add minimal snapcraft.yaml with custom build <Created by mvo5> <https://github.com/snapcore/snapd/pull/5183> | 08:16 |
| Chipaca | pstolowski: if you can't ssh to p.c.c i can put it elsewhere | 08:18 |
| pstolowski | Chipaca: indeed i can't | 08:18 |
| Chipaca | pstolowski: you need the vpn up, fwiw | 08:18 |
| pstolowski | i haven't used it for years | 08:18 |
| pstolowski | Chipaca: right. can you email it? | 08:19 |
| Chipaca | pstolowski: sent | 08:20 |
| Chipaca | it's 12MB uncompressed, so I bzipped | 08:20 |
| Chipaca | pstolowski: also i formatted it and removed secrets from it (i think :-) ) | 08:21 |
| pstolowski | Chipaca: good, thanks | 08:21 |
| pstolowski | mvo: core in edge is very broken because of reconnect bug, can we prevent people from using it (in fact last few revisions are broken)? | 08:23 |
| mvo | pstolowski: I think so, I can revert edge to a previous revision, if you tell me which one | 08:23 |
| pstolowski | mvo: problem is the PR landed 10 days aog | 08:24 |
| pstolowski | *ago | 08:24 |
| pstolowski | so you can hit the bug with any revision since then | 08:24 |
| mvo | pstolowski: ok | 08:27 |
| mvo | Chipaca: if at some point later you have time to talk about the snapd snap that would be great, it feels like we have a lot of work ahead of us :/ I will try to write up something about what we need to do to get there | 08:35 |
| mvo | Chipaca: i.e. what is missing etc | 08:35 |
| Chipaca | mvo: ok | 08:35 |
| Chipaca | mvo: right now i'm working on the conn check branch, beating tests into submission | 08:35 |
| mvo | Chipaca: sounds good | 08:36 |
| eraserpencil | what is the interface to choose if i wish to expose the Ethernet port? | 08:38 |
| popey | eraserpencil: https://docs.snapcraft.io/reference/interfaces | 08:42 |
| popey | that's the full list. we don't have one for the ethernet device/port, it's "network" | 08:42 |
| popey | (and network-bind if you want to run a server/service) | 08:42 |
| pstolowski | Chipaca: the bug you hit is same as zyga's | 08:43 |
| Chipaca | pstolowski: huzzah | 08:43 |
| zyga | High five | 08:44 |
| zyga | All 70000 of them | 08:44 |
| pstolowski | so that's what I'm fixing. there may also be a related problem with conflict checking but i haven't looked into that yet | 08:44 |
| pstolowski | basically the issue is that i iterate over all potential connections and create tasks as I go. however, if an error is detected during the iteration (such as conflict with another snap op) i error out (with Retry in some cases), and that leaves already created tasks and they are not assigned to a change. so the main task is retried and it all repeats | 08:46 |
| mvo | pstolowski: does 4646 2018-05-11T04:29:24Z arm64 16-2.32.6+git716.83cec93 edge looks reasonable to go back to? the next one we have is 2018-05-14T04:30:30Z | 08:49 |
| pstolowski | mvo: 1 moment | 08:53 |
| pstolowski | mvo: that wouldn't include https://github.com/snapcore/snapd/pull/5120 that landed on 05/11 right? | 08:57 |
| mup | PR #5120: interfaces: interface hooks for refresh <Critical> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5120> | 08:57 |
| mvo | pstolowski: it seems it does not, the r4646 was build 2018-05-11 at 04:29 in the morning | 08:59 |
| pstolowski | mvo: good, that solves it for edge | 09:00 |
| pstolowski | mvo: i fear we have a potential to hit similar issue with autoconnect logic, and that's in stable already right? | 09:01 |
| mvo | pstolowski: autoconnect is in stable, yes | 09:02 |
| mvo | pstolowski: hm, at least iirc, let me double check | 09:02 |
| mvo | pstolowski: that is "Done 2018-05-22T09:02:31Z 2018-05-22T09:02:33Z Automatically connect eligible plugs and slots of snap "test-snapd-tools" | 09:02 |
| mvo | " ? | 09:02 |
| pstolowski | mvo: yes | 09:03 |
| mvo | pstolowski: thats in stable | 09:03 |
| pstolowski | right, that's what i remembered | 09:04 |
| Chipaca | mvo: feedback on my changes to your conncheck pr appreciated | 09:07 |
| * Chipaca off to physio | 09:09 | |
| pedronis | pstolowski: I was reading the logs a bit, what's the issue? never ending retry cycles? | 09:17 |
| pstolowski | pedronis: yes, and continuous adding of hook tasks because of that, and they have no change associated if error out on Retry | 09:18 |
| pedronis | pstolowski: the latter is expected, we prune them but probably could be more aggressive, see state.go | 09:19 |
| pstolowski | pedronis: hmm that's interesting, i wasn't aware of that | 09:20 |
| pstolowski | pedronis: also while working on a fix i think i found another general flaw in reconnect logic | 09:20 |
| pedronis | pstolowski: do we know why the we retry forever? some kind of recursive case we didn't consider? | 09:20 |
| pstolowski | but that's probably not directly involved in the issue | 09:20 |
| pstolowski | pedronis: i haven't actually got the retry logic yet, you found general problem with error handling and focues on that first | 09:21 |
| pstolowski | d/you/ | 09:22 |
| pedronis | ok | 09:22 |
| pedronis | let me know if I can help | 09:22 |
| pstolowski | thanks | 09:23 |
| * Chipaca really off to physio now | 09:24 | |
| pstolowski | pedronis: would you like to take a look at John's state.json to see if you can spot the cause of retries? | 09:36 |
| pstolowski | nb, i think my remark about general flaw in reconnect logic may be premature | 09:37 |
| pedronis | pstolowski: the issue might be related to the ordering of refreshes we do now | 09:43 |
| pstolowski | pedronis: you mean ordering of refresh vs autoconnect? | 09:43 |
| pedronis | pstolowski: the fact that we refresh core first and then other snaps in a multi-refresh, I suppose auto-connect/or reconnect of core will never finish now | 09:44 |
| mvo | Chipaca: looks great, I will do a formal review now | 09:48 |
| pedronis | pstolowski: I think we didn't notice with auto-connect because we don't do anything if the connection is already there which is the common case with core and another snap | 09:50 |
| pedronis | pstolowski: you should try to write a test, have core and another snap that has a connected interface to core, then do a refresh (UpdateMany) that needs to refresh both core and this other one, I think you get the bug | 09:53 |
| pstolowski | pedronis: thanks, this sounds plausible | 09:53 |
| pstolowski | pedronis: btw, i also proposed https://github.com/snapcore/snapd/pull/5182 | 09:58 |
| mup | PR #5182: snapstate/hooks: reorder autoconnect and reconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5182> | 09:58 |
| eraserpencil | popey: I was checking the documentation on that, and erm just double checking if there was an "ethernet" option. Thanks anyway, I'll try out network. | 09:59 |
| mup | PR snapd#5184 opened: [WIP] interfaces: add desktop-{contacts,calendar}-service interfaces <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5184> | 10:16 |
| mup | PR snapd#5185 opened: tests: shellchecks part 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5185> | 10:49 |
| pstolowski | pedronis: thanks for the review | 10:50 |
| mborzecki | fwiw #5134 is green now | 11:05 |
| mup | PR #5134: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134> | 11:05 |
| ondra | mborzecki that helped :) | 11:10 |
| ondra | mborzecki tests do pass now | 11:10 |
| ondra | mborzecki I added you there also comment how to actually change writable size, in case this ever comes back | 11:10 |
| mborzecki | ondra: i tried something like this and ubuntu-image seems to ignore any edits to gadget.yaml :/ is there anyhing else i'd need to do beside dropping a new partition entry? | 11:12 |
| ondra | mborzecki not really, that there is bug in u-i | 11:13 |
| ondra | mborzecki it should not ignore that section | 11:13 |
| mborzecki | ondra: maybe what i added made no sense (but then there was no error or whatever) | 11:14 |
| ondra | mborzecki you can paste it to me, and I will see if I can spot some problem | 11:15 |
| mborzecki | ondra: let me try your snippet | 11:16 |
| pedronis | pstolowski: btw, are you working on writing the test I described? | 11:19 |
| pstolowski | not yet, but getting to it, addressed your feedback re reorder PR and finished part of the fix related to error handling. onto test now. | 11:20 |
| mwhudson | Chipaca: what was your terrible snap called again? | 11:22 |
| mwhudson | ah interdenominational-counterintelligences | 11:25 |
| Chipaca | mwhudson: yup | 11:26 |
| mwhudson | Chipaca: ah heh another non-maximal field! | 11:26 |
| mwhudson | Chipaca: publiser | 11:26 |
| mwhudson | *publisher | 11:26 |
| mwhudson | (or did you say that already) | 11:26 |
| Chipaca | mwhudson: I did not | 11:27 |
| Chipaca | mwhudson: good point. Want to register a maximal lp user? | 11:27 |
| mwhudson | i'm not sure what the upper limit is there | 11:27 |
| Chipaca | mwhudson: probably less than an exabyte | 11:30 |
| mwhudson | probably | 11:30 |
| mwhudson | https://staging.launchpad.net/~m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789 | 11:34 |
| mwhudson | Chipaca: ^ | 11:34 |
| * Chipaca hugs mwhudson | 11:35 | |
| mwhudson | https://staging.launchpad.net/~ | 11:36 |
| mwhudson | m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123 | 11:36 |
| mwhudson | 456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m1234567 | 11:36 |
| mwhudson | 89m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m1 | 11:36 |
| mwhudson | 23456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m12345 | 11:36 |
| mwhudson | 6789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789 | 11:36 |
| mwhudson | m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123 | 11:36 |
| mwhudson | 456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m1234567 | 11:36 |
| mwhudson | 89m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789 | 11:36 |
| mwhudson | yeah ok so maybe not much less than an exabyte | 11:36 |
| mwhudson | (sorry!) | 11:36 |
| Chipaca | mwhudson: if it's just a text field, it might not be much less | 11:39 |
| mborzecki | ondra: looks like gadget.yaml comes from gadget snap which is downloaded on every build | 11:39 |
| mwhudson | Chipaca: that user has a 3600 char name so... | 11:39 |
| Chipaca | mwhudson: I would argue that it's a bug if it's longer than ~20 chars, myself | 11:39 |
| niemeyer | Good mornings! | 11:40 |
| Chipaca | although I might be convinced to thinking 32 isn't too bad either | 11:40 |
| pedronis | Chipaca: should we s/url/host/ in a bunch of docs, variables in the connectivity check PR ? | 11:41 |
| Chipaca | pedronis: no | 11:41 |
| Chipaca | pedronis: accurate documentation is for the feeble-minded | 11:41 |
| pedronis | ok :) | 11:41 |
| * Chipaca fixes | 11:41 | |
| mup | PR snapd#5080 closed: many: support 'system' nickname in interfaces <Created by bboozzoo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5080> | 11:47 |
| Chipaca | pedronis: fixed | 11:47 |
| pedronis | Chipaca: I'm removing your +1 because it has changed so much by you since | 11:49 |
| Chipaca | pedronis: that seems fair to me :-) | 11:49 |
| Chipaca | I +1'ed it, and then rewrote it | 11:49 |
| Chipaca | :-D | 11:49 |
| Chipaca | "yeah that's fine, let's do something COMPLETELY DIFFERENT" | 11:49 |
| Chipaca | *merge* | 11:49 |
| Chipaca | I've been taking lessons from the US congress | 11:49 |
| pedronis | let's add a random thing at the last minute before the vote? fix conflicts, non-sense laters? | 11:50 |
| pedronis | seems it's a style there | 11:51 |
| Chipaca | > @niemeyer approved this pull request. | 11:51 |
| * Chipaca dances | 11:51 | |
| Chipaca | i feel like i should bring out the champagne and the cigars | 11:52 |
| mborzecki | Chipaca: (snap)shots for everyone? | 11:52 |
| Chipaca | mborzecki: let me sneakily rename them to schnappshots before the merge | 11:52 |
| * niemeyer grabs the domain name | 11:52 | |
| mup | PR snapd#5066 closed: overlord/snapshotstate/backend: introducing the snapshot backend <Complex> <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5066> | 11:53 |
| mborzecki | off to school, back for standup | 12:08 |
| ondra | mwhudson ah if you are using gadget snap from store, then you are out of luck | 12:12 |
| ondra | mwhudson ups sorry wrong nick | 12:12 |
| ondra | mborzecki ah if you are using gadget snap from store, then you are out of luck | 12:13 |
| ondra | mwhudson you can always change u-i command and pass it own gadget snap instead, but that will make test a bit more static | 12:13 |
| mwhudson | ondra: you did it again! | 12:13 |
| ondra | mwhudson damn irc client, sorry for that | 12:14 |
| mwhudson | heh heh it's funny | 12:14 |
| mwhudson | no worries :) | 12:14 |
| * mwhudson goes to bed | 12:14 | |
| ondra | mborzecki you can always change u-i command and pass it own gadget snap instead, but that will make test a bit more static | 12:14 |
| ondra | good night :) | 12:14 |
| cachio | Son_Goku, hey | 12:38 |
| Son_Goku | yo | 12:38 |
| cachio | Son_Goku, I am working again with the fedora 28 for google | 12:38 |
| cachio | I just see the oslogin package | 12:38 |
| Son_Goku | which ones do you need? | 12:38 |
| cachio | Son_Goku, https://paste.ubuntu.com/p/g9HByWRgbg/ | 12:39 |
| cachio | those | 12:39 |
| Son_Goku | okay, so you need all three | 12:41 |
| Son_Goku | I'll try to work on that today | 12:41 |
| cachio | Son_Goku, great, thanks a lot | 12:42 |
| === pbek_ is now known as pbek | ||
| mborzecki | re | 12:45 |
| mborzecki | master unit tests are broken, i'll be opening a pr in a while | 12:45 |
| mborzecki | there should be a github feature that triggers a build on a PR whenever it's about to be merged into master | 12:47 |
| mup | PR snapd#5186 opened: daemon: update unit tests to match current master <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5186> | 12:54 |
| mborzecki | should fix master builds ^^ | 12:55 |
| sergiusens | joc, thresh, diddledan, popey, Wimpress https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-42-1/5540 has the snapcraft you want or need (a quick validation, if time permits, would be nice) | 13:14 |
| popey | hah | 13:14 |
| popey | you always have the snapcraft I need | 13:14 |
| joc | sergiusens: thanks, how quick were you hoping for? | 13:15 |
| popey | sergiusens: looks like I'm already on edge, so have been using that for at least the last 24 hours | 13:15 |
| sergiusens | joc: the test can be quick, but it is not urgent ;-) | 13:15 |
| sergiusens | popey: thanks | 13:16 |
| mvo | sergiusens: do you want me to write a forum post about the "snap" directory isssue outlined in 1772584? | 13:17 |
| sergiusens | mvo: this bug plays nicely with the fact that we also want to make `parts` relocatable for build environments | 13:17 |
| sergiusens | but this one is a bit more special even | 13:18 |
| mvo | sergiusens: being able to put it all under .snapcraft might also be an option | 13:18 |
| sergiusens | because it is our main entry point into the source of truth to build | 13:18 |
| mvo | sergiusens: I don't really mind, but the hack I had to do to make it work makes my cry | 13:18 |
| sergiusens | mvo: yeah, let's start with a post to brainstomr | 13:18 |
| mvo | sergiusens: cool, will do | 13:19 |
| sergiusens | hacks always make us want to cry until they stand the test of time, from then on, we are proud of them :-P | 13:19 |
| diddledan | sergiusens: I used it yesterday from edge (purposefully) to build gimp 2.10.2 - works great - fixes the argument length issue gimp build was encountering | 13:22 |
| popey | yay | 13:23 |
| popey | https://usercontent.irccloud-cdn.com/file/11QDTn3O/Good%20news%21 | 13:23 |
| thresh | sergiusens, hey I've tried the edge multiple times and it worked fine for me - no time to test the actual release atm, sorry | 13:24 |
| diddledan | speaking of gimp - I've been building the world because glib needed to be newer than that of xenial, but because I'm now not using the themes and such from the ubuntu repo I'm missing icons that I can't work out how to get back - I'm building gnome-themes-extra and gnome-icon-theme and gnome-icon-theme-extra and adwaita-icon-theme but still there are missing icons :-( | 13:25 |
| diddledan | oh, and hicolor-icon-theme, too | 13:25 |
| popey | diddledan: is it possible to build using some of the magic kenvandine does to get newer gnome in desktop snaps? (or use 18 core) | 13:26 |
| diddledan | using 18 core would probably fix it | 13:27 |
| diddledan | how do I do that? | 13:27 |
| popey | I installed a snap the other day that pulled in core 18, surprised people are using it already | 13:27 |
| popey | https://forum.snapcraft.io/t/the-road-to-core18/5547 | 13:27 |
| diddledan | it's not official yet is it? | 13:27 |
| popey | oh, that's not what you want | 13:27 |
| diddledan | "Sorry, you don't have access to that topic!" :-p | 13:27 |
| diddledan | that's a secrit topic | 13:28 |
| popey | ignore that then | 13:28 |
| popey | sorry. | 13:28 |
| * diddledan haxx0rs it | 13:28 | |
| thresh | mmm fresh warez | 13:28 |
| popey | i think there's some work still to do in the store and snapcraft before core18 is commonplace | 13:28 |
| sergiusens | thresh: having used edge is good enough, thanks! | 13:29 |
| * diddledan surmises that popey has insider information from a secrit topic that he can't tell me about that makes popey "think there's some work still to do". 'the road to core18' is long and winding? :-p | 13:30 | |
| mup | PR snapd#5187 opened: overlord: introduce snapshotstate <Created by chipaca> <https://github.com/snapcore/snapd/pull/5187> | 13:30 |
| mup | PR snapd#5186 closed: daemon: update unit tests to match current master <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5186> | 13:48 |
| mborzecki | cachio: can you post the *.timer file somewhere? | 13:54 |
| jdstrand | roadmr: hi! can you pull r1074 of the review tools? note that most of the changes are around snap usn support, but there are a few things for regular reviews | 14:06 |
| roadmr | jdstrand: sure! | 14:07 |
| jdstrand | thanks! | 14:07 |
| roadmr | jdstrand: we still haven't re-enabled resquash enforcement, right? | 14:07 |
| cachio | mborzecki, well, it fails to install and it doers not leave the .timer | 14:07 |
| jdstrand | note to channel: ^ that includes support for the new 'timer' yaml | 14:07 |
| cachio | mborzecki, is it any way to see the .timer in that case? | 14:07 |
| jdstrand | roadmr: that is correct. plan to do it the week of June 4th. electron upstream is the last thing and they are working on it (several commits already pushed) | 14:08 |
| mborzecki | cachio: no i think not, what's your snapd version? | 14:08 |
| cachio | 2.32.8 | 14:08 |
| mborzecki | cachio: w8, timers are in 2.33, any timer entry you have there will be ignored | 14:10 |
| jdstrand | cachio: note, I'm approving your gce-cleaner snap now | 14:11 |
| cachio | jdstrand, ok, thanks | 14:11 |
| cachio | mborzecki, weird, I tried with edge and I had same problem | 14:11 |
| jdstrand | cachio: all approved. you'll need to publish to a channel | 14:11 |
| cachio | mborzecki, let me check it again | 14:11 |
| cachio | jdstrand, perfect, tx | 14:12 |
| mborzecki | cachio: can you double check that there are no snap.*.timer files before you attempt to install that snap? | 14:13 |
| cachio | mborzecki, yes | 14:13 |
| cachio | mborzecki, I am refreshing core now, let me try once it is finished | 14:13 |
| cachio | mborzecki, I have snapd.snap-repair.timer | 14:15 |
| cachio | for example | 14:15 |
| mborzecki | cachio: this one is ok, it's part of snapd package iirc | 14:15 |
| cachio | mborzecki, https://paste.ubuntu.com/p/ztXv9HSRhw/ | 14:17 |
| cachio | mborzecki, it is weird becase it works in a xenial machine on google | 14:18 |
| mborzecki | cachio: tried 2.32.9, the timers are ignored as expected | 14:20 |
| mborzecki | and -git version creates the timer files as needed | 14:20 |
| cachio | which systemd do you have? | 14:21 |
| cachio | mborzecki, I have systemd 229 | 14:22 |
| mborzecki | cachio: 238, but that shouldn't matter, the error you had suggests that the timer was incorrectly generated | 14:22 |
| cachio | mborzecki, and the core is 16-2.32.9+git734.7763a07 (4718) 91MB core | 14:22 |
| mborzecki | cachio: can you post the snap.yaml somewhere? | 14:23 |
| cachio | mborzecki, sure | 14:23 |
| zyga | jdstrand: Hi | 14:23 |
| cachio | mborzecki, https://paste.ubuntu.com/p/DMncjbGVMJ/ | 14:23 |
| zyga | From redhat docs about the new security issues related to speculative access to the store buffer | 14:24 |
| zyga | Since it will take time to enable explicit mitigations in all impacted third-party software, steps have been taken to automatically enable mitigation for some classes of applications. The Linux kernel “seccomp” (“secure computing”) framework allows an application to request that limits be placed upon itself, for example, to prevent further use of certain system calls and other system interfaces after its initial startup phase. Seccomp is often | 14:24 |
| zyga | used by sandboxes and managed code frameworks to limit the ability for sandbox escape once potentially malicious untrusted code begins to execute. The seccomp framework has been modified in the latest Linux kernel updates such that its use will automatically have the side-effect of disabling Speculative Store Buffer Bypass, equivalent to applications making an explicitly programmed “prctl” request | 14:24 |
| zyga | This implies that all snap software automatically runs slower | 14:24 |
| zyga | mvo: ^ FYI | 14:24 |
| zyga | Which imo sucks | 14:25 |
| jdstrand | zyga: put another way, it means that all snap software is protected | 14:25 |
| zyga | From itself? This is infra-process attack | 14:25 |
| jdstrand | but yes. speculative execution continues to be a pain | 14:25 |
| zyga | Not applicable to snapd mounting a sandbox around an otherwise single-security-level process | 14:26 |
| mborzecki | cachio: hm the spec is even the same as our test snap | 14:26 |
| cachio | mborzecki, do you want to try it https://github.com/sergiocazzolato/gce-cleaner.git | 14:28 |
| mborzecki | cachio: ok, let me fire xenial vm | 14:30 |
| zyga | jdstrand: imo, we should prctl this off in snap-confine, software that actually needs this (like browsers) should re-enable it | 14:31 |
| zyga | jdstrand: otherwise all software inside a snap seccomp profile becomes slower | 14:31 |
| jdstrand | zyga: I have not studied the issue to the extent to say that is ok. tyhicks, do you have an opinion? | 14:32 |
| zyga | I haven’t studied this in depth either but the article makes a connection between the use of seccomp and implicates that the process must use multiple security contexts inside so should automatically be protected from using the store buffer speculation attack | 14:38 |
| mborzecki | cachio: your snap builds and installs just fine | 14:38 |
| zyga | That is, doesn’t take into account the massive use of seccomp for software that doesn’t have multiple security contexts but is under general sandboxing like snapd | 14:38 |
| cachio | mborzecki, well, it works for me in a vm on gce | 14:40 |
| cachio | on xenial | 14:40 |
| cachio | but fails on my machine | 14:40 |
| mborzecki | cachio: ok, let me try with edge (that's what you're using right?) in xenial vm | 14:41 |
| tyhicks | zyga: this was known and documented in the Ubuntu KnowledgeBase (3rd paragraph of Mitigations): https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/Variant4 | 14:41 |
| cachio | mborzecki, I used edge and stabl | 14:41 |
| cachio | e | 14:41 |
| tyhicks | zyga: the idea is being secure by default | 14:41 |
| jdstrand | zyga (cc tyhicks): snaps can contain anything. I don't think we can assume that a snap doesn't use an affected pattern. also, it sounds like if we disable via the prctrl then an application would have to reenable with the prctl, where as app developers may assume that "since I'm using seccomp, I don't have to do that" | 14:42 |
| mborzecki | cachio: well stable does not have timers, so there's that | 14:42 |
| jdstrand | zyga: so, for your browser example, turning it off would likely turn it off for all the snapped browsers | 14:42 |
| tyhicks | zyga: while the impact of this issue doesn't seem to be very high, it hasn't received a lot of attention yet because it has been embargoed | 14:42 |
| zyga | tyhicks, jdstrand: I agree but I find this suboptimal, high-performance software (or games) now runs slower because they just happen to be sandboxed; | 14:43 |
| zyga | I'm off for most of this week but I will definitely get back to this issue in snapd context | 14:43 |
| jdstrand | zyga: do you know that? have you measured it? | 14:43 |
| mborzecki | cachio: xenial vm also working fine :/ | 14:43 |
| zyga | jdstrand: no, but it is purely a preformance feature (speculative store) so it must have some impact, how grave it is I don't yet know | 14:44 |
| jdstrand | zyga: btw, you can't measure yet cause the microcode isn't available yet | 14:44 |
| tyhicks | zyga, jdstrand: I've measured about a 3.2% percent performance hit for CPU bound workloads (compiling the kernel using the default kernel configuration) | 14:44 |
| jdstrand | tyhicks: I thought we meeded microcode to be able to measure... granted, I am not up on the issue | 14:45 |
| tyhicks | jdstrand: yes, you need to have updated microcode to test | 14:45 |
| jdstrand | ok | 14:46 |
| jdstrand | we don't have that :) | 14:46 |
| jdstrand | tyhicks: curious, is it possible (and perhaps desirable) for snaps to opt out of the protection? Ie, it is on be default now, but yaml is introduced that tells snap-confine to use the prctl to turn it off? | 14:49 |
| tyhicks | zyga: I'm not saying that you shouldn't make use of the prctl to disable it but you may want to wait a little bit to see how the discussion around this flaw turns | 14:49 |
| zyga | tyhicks: ack, I didn't mean to imply ugrency, I'm just reading about this as it is becoming public | 14:49 |
| jdstrand | zyga (cc tyhicks): suse said: "A common pattern where this happens would be leaks out of zeroed cryptographic material storage" | 14:50 |
| zyga | jdstrand: since we have speciifc interfaces that allow to construct a seccomp sandbox we could tie it to that, perhaps | 14:50 |
| jdstrand | zyga (cc tyhicks): there are all kinds of snaps that take sensitive info | 14:50 |
| tyhicks | jdstrand: yes, the launcher would need to use the prctl to disable the mitigation and then load the seccomp filter with a newly added (and backported) seccomp filter flag that allows the mitigation to be disabled for applications using seccomp | 14:51 |
| jdstrand | it still sounds like by default is the correct choice. *perhaps* a mechanism to opt out would be ok | 14:51 |
| zyga | jdstrand: senstive info yes but isn't the whole attack only mountable from within a process? that is a process running untrusted code? | 14:52 |
| tyhicks | zyga, jdstrand: this is not a user friendly solution but, for completeness, a user could use the spec_store_bypass_disable=prctl kernel boot option to turn off mitigations for seccomp processes (see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/MitigationControls#CVE-2018-3639) | 14:53 |
| jdstrand | zyga: we don't know what snaps are running. maybe it is a lamp stack that is reachable over the internet and processes sensitive info and tries to dtrt with it | 14:53 |
| tyhicks | (the default is spec_store_bypass_disable=seccomp) | 14:53 |
| jdstrand | tyhicks: yes, I was just going to say that sounds like what people were thinking. set it to something lower then opt into more rather then setting to high and opting out | 14:54 |
| zyga | jdstrand: yes, I'm just trying to consider if, among snaps, the only scope of attack is a process attacking itself (by, for example, running untrusted code) | 14:54 |
| zyga | jdstrand: or if the scope is larger | 14:54 |
| jdstrand | zyga: I can't comment on that. it sounds like due to embargo it hasn't been studied. my point is it is enough of a reason to leave it on (at least by default) | 14:55 |
| * zyga nods | 14:55 | |
| tyhicks | a browser process crunching of arbitrary javascript is an example of a process that isn't attacking itself but is potentially being attacked by an external attacker | 14:55 |
| jdstrand | zyga: but opting out sounds difficult since we'd need new kernel support that everyone would need to pick up since all distros are choosing spec_store_bypass_disable=seccomp | 14:55 |
| zyga | jdstrand: yes, I agree, it may be a while before an opt-out is even something me way offer | 14:56 |
| tyhicks | jdstrand: if distros are supporting spec_store_bypass_disable=seccomp then they're definitely supporting the prctl | 14:56 |
| jdstrand | tyhicks: right, but you said we need a new flag backported when =seccomp from kernel command line and we want to opt out | 14:57 |
| jdstrand | tyhicks: or did I misunderstand? | 14:57 |
| tyhicks | jdstrand: I think you misunderstood | 14:57 |
| tyhicks | jdstrand: if the kernel is opting seccomp'ed processes into SSBD, then it very likely supports the prctl and seccomp filter flag to allow those processes to opt out of SSBD | 14:58 |
| zyga | is the prctl code public now? | 14:58 |
| tyhicks | (the prctl comes before the seccomp patches in the patch set and the seccomp patches rely on the prctl patches) | 14:58 |
| tyhicks | zyga: yes | 14:58 |
| * zyga pulls his linux tree | 14:59 | |
| tyhicks | zyga: there's not much need for that - the prctl is simple | 14:59 |
| * jdstrand notes that the act of having a seccomp sandbox at all is a performance impact | 14:59 | |
| jdstrand | regardless of this | 14:59 |
| jdstrand | ie, snaps were already a little slower | 14:59 |
| zyga | jdstrand: that's true | 15:00 |
| jdstrand | an ideally complied seccomp filter will have the most used call first with the least last | 15:01 |
| * zyga tries to return to his holidays but this is too interesting | 15:01 | |
| jdstrand | we can, today, do some instrumenting and reorder our template to add some performance | 15:01 |
| jdstrand | the template is in alphabetical order now. we could put open, write, read, etc first | 15:01 |
| zyga | jdstrand: that's intereting, I didn't think that the template would be compiled top-to-bottom | 15:02 |
| jdstrand | (it is alphabetical because at the time it was not known that the ordering mattered) | 15:02 |
| zyga | jdstrand: for instance, today we order it alphabetically | 15:02 |
| zyga | (I think we sort it internally) | 15:02 |
| jdstrand | zyga: I've thought that we could strace several applications and then see how much each call was hit, and do some ordering in (at least) the template | 15:03 |
| zyga | jdstrand: that's a good idea, I agree | 15:03 |
| jdstrand | it wouldn't have to be perfect to have an improvement. it would all have to be measured of course | 15:03 |
| mborzecki | cachio: not sure what's happening in your system, given the log, the template that's generated seems to have some incorrect characters inside, the 'n' may come from '\n' but we don't use that explicitly when generating the file, so maybe it's some printing problem in systemd/journalctl? to make things even more awkward the snap seems to work elsewhere | 15:05 |
| zyga | jdstrand: since seccomp profiles are per-app we might even do some eventual automatic tuning | 15:05 |
| cachio | mborzecki, good | 15:06 |
| jdstrand | zyga: you mean, like, "if browser-support is plugged, then assume we should tune as a browser" type things? | 15:06 |
| cachio | mborzecki, I'll try to update systemd and test with a new version | 15:06 |
| zyga | jdstrand: if one-of-set-of-interfaces is plugged then the app has an ability to construct a sandbox so enable the security hardening | 15:08 |
| jdstrand | zyga: if so, that shouldn't be out of the realm of possibility. I suspect (but again, just a gut feeling) that we are going to see a top 20 (or whatever) list of syscalls and that putting them ordered first we'd see the biggest benefit, with everything else falling off fast | 15:08 |
| zyga | yeah | 15:08 |
| jdstrand | who knows, maybe we can just do that and negate tyhicks' 3.2% impact :) | 15:10 |
| tyhicks | jdstrand: don't strace! set SECCOMP_RET_LOG as the default seccomp action | 15:12 |
| * tyhicks does all this work on seccomp logging and jdstrand just forgets about it... | 15:13 | |
| tyhicks | ;) | 15:13 |
| tyhicks | oh, not the default action but used in place of SECCOMP_RET_ALLOW | 15:13 |
| roadmr | :~( | 15:13 |
| jdstrand | heh, well, I *had* actually thought of it be then was worried about kernel rate limiting and using a special snap-seccomp | 15:13 |
| jdstrand | but sure | 15:13 |
| zyga | it'd be nice if we could do SECCOMP_RET_HISTOGRAM or something similar, so that we don't need to log all of them, just increment a per-process counter somewhere | 15:14 |
| zyga | maybe with some perf way to get it out | 15:14 |
| tyhicks | if you disable rate limiting, you'll probably get much better performance than with strace | 15:14 |
| tyhicks | s/if you disable/even if you disable/ | 15:14 |
| jdstrand | well, I wasn't suggesting measuring under strace, just gathering data, then adjusting the order, then measuring. rinse and repeat | 15:16 |
| tyhicks | zyga: definitely an interesting idea but I think that's probably adding too much complexity to seccomp for something that can be done easily in userspace | 15:16 |
| tyhicks | SECCOMP_RET_TRACE is probably the best option because the tracer, in userspace, could easily keep a tally | 15:16 |
| jdstrand | there are probably system-tap like things that could be done | 15:16 |
| jdstrand | ah yes, SECCOMP_RET_TRACE | 15:17 |
| pstolowski | pedronis: fyi, still fighting with the test but close, had to move it to managers_test and now its seems to be missing snap declaration only.. | 15:22 |
| pedronis | pstolowski: that's probably the best place yes | 15:23 |
| * cachio lunch | 15:40 | |
| mvo | sergiusens: I wrote the forum post about the "snap" directory in the source tree now btw | 16:51 |
| pstolowski | i'm calling it day, feeling really under the weather. the test for reconnect hasn't been succesfull so far, it's not failing as expected.. i might be missing something still in the setup/mocking | 17:28 |
| === pstolowski is now known as pstolowski|afk | ||
| === MrGeneral_ is now known as MrGeneral | ||
| jdstrand | niemeyer: hi! when you get a chance would you mind reviewing https://github.com/snapcore/snapd/pull/5016? Specifically https://github.com/snapcore/snapd/pull/5016#issuecomment-390186013 | 18:57 |
| mup | PR #5016: interfaces/home: add 'read' attribute to allow non-owner read to @{HOME} <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5016> | 18:57 |
| niemeyer | jdstrand: Will do, and thanks! | 18:59 |
| jdstrand | np | 19:14 |
| mup | PR snapd#5188 opened: tests: ubuntu core abstraction <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5188> | 20:16 |
| niemeyer | jdstrand: Perhaps instead of "own" or "owner" we should go with "user" | 20:34 |
| niemeyer | jdstrand: Rationale being that this vaguely resembles the u/g/o permission set, except the "o" has the opposite meaning | 20:35 |
| jdstrand | niemeyer: I actually like 'owner' because it matches apparmor terminalogy (eg, it is not uncommon to say 'we allow access to this file with owner match'. but, I'm not married to it. your point for 'u'ser is as valid as that | 20:36 |
| jdstrand | terminology* | 20:37 |
| niemeyer | jdstrand: Ouch.. so many standards :) | 20:37 |
| jdstrand | I know | 20:37 |
| jdstrand | I guess a regular person might under 'user' better, but 'owner' is pretty clear too since it is very typical to talk about file ownership | 20:38 |
| jdstrand | understand* | 20:38 |
| jdstrand | I don't have a strong opinion. I'm probably too close to 'owner' to be objective :) | 20:38 |
| niemeyer | jdstrand: We might also solve the dilemma by forbidding either, and just assuming the default to be that | 20:41 |
| niemeyer | jdstrand: This has the advantage of no ambiguity | 20:42 |
| niemeyer | (two syntaxes with same meaning) | 20:42 |
| jdstrand | well, user and owner really are communicating the same thing ime | 20:43 |
| jdstrand | they could really be interchangable at a high level. I liked 'owner' because 'all' removes 'owner' match and 'owner' (the default) adds it | 20:44 |
| jdstrand | at the lower level | 20:44 |
| jdstrand | if we take apparmor out of it, it might make sense to use user | 20:45 |
| jdstrand | we could use uid | 20:45 |
| jdstrand | owner means uid match with apparmor. user with u/g/o corresponds to the uid | 20:45 |
| jdstrand | and people understand what a uid is | 20:46 |
| niemeyer | jdstrand: I mean we might forbid both of them | 20:46 |
| niemeyer | jdstrand: And allow only "read: all" | 20:46 |
| jdstrand | oh I see what you mean | 20:46 |
| niemeyer | The other syntax is everything we already have today | 20:46 |
| jdstrand | I thought you meant find a 3rd alternative | 20:46 |
| niemeyer | So we don't need to express it | 20:47 |
| jdstrand | that's true | 20:47 |
| jdstrand | we could turn it into a boolean then... did we have that conversation already? | 20:47 |
| * jdstrand looks in the forum | 20:47 | |
| niemeyer | Finding "read: own/owner" will make people wonder what it matters | 20:47 |
| niemeyer | and the answer is it doesn't | 20:47 |
| * jdstrand nods | 20:47 | |
| niemeyer | jdstrand: I think "read: all" is nice and clear | 20:48 |
| niemeyer | jdstrand: We might just omit the other option for now, and keep it as the default | 20:48 |
| jdstrand | ok, wfm | 20:48 |
| niemeyer | jdstrand: That does not prevent us from having a third option later | 20:48 |
| niemeyer | jdstrand: LGTM too | 20:48 |
| * jdstrand will summarize and drop 'owner' and leave only all | 20:48 | |
| niemeyer | jdstrand: Will comment on the PR | 20:48 |
| jdstrand | ok | 20:49 |
| jdstrand | :) | 20:49 |
| niemeyer | jdstrand: Sent the review, with another minor detail | 20:53 |
| jdstrand | niemeyer: thanks! | 20:53 |
| niemeyer | jdstrand: Sorry, my point about the mishandling of incorrect type was incorrect. The simplifcation note remains, though. | 20:55 |
| jdstrand | ack | 21:00 |
| JHOSMAN | Hello, how to I can make conecction of Hamachi in Ubuntu Core? | 21:22 |
| mup | PR snapd#5189 opened: interfaces/many: miscellaneous updates for default, desktop, desktop-legacy, system-observe, hardware-observe, opengl and gpg-keys <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5189> | 21:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!