| jaitaiwan | Hey folks, just wondering if snaps are supposed to be apart of your $PATH by default or if there's some sort of setup steps I'm missing before using CLI snaps | 01:23 |
|---|---|---|
| nacc | jaitaiwan: /etc/profile.d/apps-bin-path.sh on ubuntu (from snapd) | 03:51 |
| mborzecki | morning | 06:06 |
| mup | PR snapd#4800 closed: cmd/snap: in changes and tasks, default to human-friendly times <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4800> | 07:22 |
| zyga-ubuntu | good morning | 07:30 |
| zyga-ubuntu | jaitaiwan: hey, it's supposed to be automatic but if you just installed the snapd package you may need to reboot / log out for the changes to take effect | 07:31 |
| zyga-ubuntu | mvo: good morning | 07:32 |
| * zyga-ubuntu was up at 6AM but $KIDS needed more help today | 07:32 | |
| mvo | zyga-ubuntu: hey, good morning | 07:33 |
| zyga-ubuntu | man, this bug is more elusive than we thought :/ | 07:33 |
| mvo | zyga-ubuntu: yeah, I was thinking it was caching | 07:34 |
| mborzecki | zyga-ubuntu: mvo: morning guys | 07:34 |
| zyga-ubuntu | mvo: did you get to a point where you can reproduce it on your machine? | 07:34 |
| mvo | hey mborzecki | 07:34 |
| mvo | zyga-ubuntu: I did manage that | 07:34 |
| zyga-ubuntu | mvo: and if so did you have to run all of main or was a subset sufficient? | 07:35 |
| zyga-ubuntu | mborzecki: hey! :) | 07:35 |
| mvo | zyga-ubuntu: I have to run all | 07:35 |
| zyga-ubuntu | mvo: I tried just the cgroup tests and I was "lucky" | 07:35 |
| mvo | zyga-ubuntu: I managed to get into a shell last night and changed the profile and reload and then things were good again | 07:35 |
| zyga-ubuntu | mvo: so just *one* test (with sub-tests) | 07:35 |
| mvo | zyga-ubuntu: I suspect its something subtle like the cache | 07:35 |
| zyga-ubuntu | ok, I can try disabling all of the cache | 07:36 |
| mvo | zyga-ubuntu: oh, just the cgroup tests, cool | 07:36 |
| zyga-ubuntu | and see if that helps | 07:36 |
| mvo | zyga-ubuntu: sounds great, how do you disable the caches? | 07:36 |
| mvo | zyga-ubuntu: I rm -f them in my PR but that is not enough | 07:36 |
| zyga-ubuntu | mvo: apparmor_parser explicitly controls this so we'd have to pass some options in a few places, the patch should be minor | 07:36 |
| zyga-ubuntu | mvo: the only exception is /etc/init.d/apparmor | 07:36 |
| zyga-ubuntu | but I _think_ we can ignore that | 07:37 |
| zyga-ubuntu | because it just runs once on boot | 07:37 |
| zyga-ubuntu | hmm hmm | 07:37 |
| zyga-ubuntu | but then again, some tests do reboot | 07:37 |
| zyga-ubuntu | I'll focus on the cgroup test | 07:37 |
| zyga-ubuntu | and on disabling cache | 07:37 |
| zyga-ubuntu | maybe it will show us something usefil | 07:37 |
| zyga-ubuntu | oh | 07:37 |
| mvo | zyga-ubuntu: is there magic to dump a profile from memory? i.e. to see if the in-memory state matches the on disk state? | 07:38 |
| zyga-ubuntu | and I have a small patch, though not a bug fix, related to what I did yesterday | 07:38 |
| zyga-ubuntu | yes | 07:38 |
| zyga-ubuntu | ish | 07:38 |
| zyga-ubuntu | you can dump the profile from memory | 07:38 |
| zyga-ubuntu | hold on, I will show you how | 07:38 |
| mvo | zyga-ubuntu: cool, when I am in the broken state I will try that | 07:38 |
| zyga-ubuntu | mvo: it's not easy or useful without some extra tools | 07:40 |
| zyga-ubuntu | mvo: you can go to /sys/kernel/security/apparmor/policy/raw_data/ | 07:40 |
| zyga-ubuntu | (raw_data is a magic symlink which behaves as a magic directory) | 07:40 |
| zyga-ubuntu | then you will see a lot of numbers | 07:40 |
| zyga-ubuntu | each time you insert a new profile you get a new number (including replaces I think) | 07:41 |
| zyga-ubuntu | then you can see the raw_data file inside the number directory | 07:41 |
| zyga-ubuntu | now | 07:41 |
| zyga-ubuntu | this doesn't match the cache I think | 07:41 |
| zyga-ubuntu | but there is a way to compile a profile and get the raw data | 07:41 |
| zyga-ubuntu | from apparmor_parser that is | 07:41 |
| zyga-ubuntu | so with some tooling we might compile all the profiles from disk | 07:41 |
| zyga-ubuntu | to get their raw_data | 07:42 |
| zyga-ubuntu | and compare that to the raw_data that the kernel knows about | 07:42 |
| zyga-ubuntu | and in the end try to match files to loaded profiles | 07:42 |
| zyga-ubuntu | I wrote a decompiler for the raw_data format a while ago | 07:42 |
| zyga-ubuntu | but did not manage to get the most interesting part of the policy | 07:42 |
| zyga-ubuntu | that is the set of regular exressions and matching permissions | 07:42 |
| zyga-ubuntu | I do get profile names and a lot of other things out though | 07:43 |
| zyga-ubuntu | the format is not documented well, I did this by following the kernel code that parses the binary profiles | 07:43 |
| zyga-ubuntu | so, that's that, not sure if useful | 07:43 |
| mvo | zyga-ubuntu: uh, ok | 07:44 |
| zyga-ubuntu | *fun* :-) | 07:44 |
| mvo | zyga-ubuntu: yeah | 07:44 |
| zyga-ubuntu | the format is not hard either | 07:44 |
| zyga-ubuntu | it's mostly tagged strutures and some tables | 07:44 |
| zyga-ubuntu | the devil is in the details | 07:44 |
| zyga-ubuntu | and the yet-not-understood (by me) format to which the DFAs are compiled | 07:44 |
| zyga-ubuntu | it's also coupled with some compression | 07:44 |
| zyga-ubuntu | mvo: though having such a decompiler would be very useful as it's our backbone in many ways | 07:46 |
| * mvo nods | 07:48 | |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:53 |
| zyga-ubuntu | hey hey | 07:54 |
| mvo | zyga-ubuntu: so you reproduced it without the core transition tests? I suspected those might be the culprits :/ | 07:55 |
| zyga-ubuntu | yes, I did | 07:55 |
| zyga-ubuntu | I'm running another pass now | 07:55 |
| zyga-ubuntu | I'm tweaking prepare/restore debugging | 07:55 |
| mvo | zyga-ubuntu: ta | 07:56 |
| mup | PR snapd#4821 opened: tests: define MATCH from spread <Created by zyga> <https://github.com/snapcore/snapd/pull/4821> | 08:00 |
| mvo | zyga-ubuntu: I replied to your question about the system-key | 08:01 |
| mvo | zyga-ubuntu: let me know if that is reasonable, if not happy to have a quick HO to discuss | 08:01 |
| zyga-ubuntu | thanks, looking | 08:01 |
| mvo | zyga-ubuntu: my theory is essentially that during one of the tests we generate/load a snap.core.*.snap-confine profile from the real core in edge instead of from our modified core | 08:03 |
| mvo | zyga-ubuntu: and never undo this | 08:03 |
| zyga-ubuntu | hmm hmm | 08:03 |
| mvo | zyga-ubuntu: and then things fall apprt | 08:03 |
| zyga-ubuntu | can you explain when system key would be stale and we would not regenerate it? | 08:03 |
| mvo | zyga-ubuntu: and also its super confusing because we restore the profile *on-disk* (via tar) but of course do not reload | 08:03 |
| zyga-ubuntu | ahh | 08:03 |
| mvo | zyga-ubuntu: the core snap is 4422 (or whatever) | 08:03 |
| mvo | zyga-ubuntu: that is the one in edge | 08:03 |
| zyga-ubuntu | maybe as a part of restore we can do apparmor_parser -r /some/path/* | 08:04 |
| mvo | zyga-ubuntu: and also the one we "hack" | 08:04 |
| mvo | zyga-ubuntu: yes, that could be it | 08:04 |
| zyga-ubuntu | I just ran the cgroup tests and they didn't fail | 08:04 |
| zyga-ubuntu | your patch from yesterday (the 1st one) makes it less likely things break | 08:04 |
| mvo | zyga-ubuntu: the core transition tests will (most) definitely do that, use the "real" edge with the "wrong" snap-confine profile and load that | 08:04 |
| mvo | zyga-ubuntu: yeah | 08:04 |
| zyga-ubuntu | I'll run the core transition tests and the cgroup test in sequence now | 08:05 |
| zyga-ubuntu | mvo: so to get back to the PR with the system-key question | 08:08 |
| mvo | zyga-ubuntu: I suspect that we will see the error now in the 2.32 branch only, edge is up-to-date with core again so the apprmor profiles are essentially the same | 08:08 |
| mvo | zyga-ubuntu: sure | 08:08 |
| zyga-ubuntu | if I understand you correctly, you are saying that because we remove system key we trigger profile loads | 08:08 |
| mvo | zyga-ubuntu: correct | 08:08 |
| zyga-ubuntu | yeah, I work on the release branch all the time | 08:08 |
| zyga-ubuntu | mvo: I would strongly prefer if this was a bit less magic and more organized | 08:09 |
| mvo | zyga-ubuntu: we *could* also force this in restore as a big hammer | 08:09 |
| zyga-ubuntu | there's a lot of voodoo in our scripts | 08:09 |
| mvo | zyga-ubuntu: I think we are all in agereement about this :) | 08:09 |
| mvo | zyga-ubuntu: part of the problem is that the problem domain itself is confusing, I mean, re-exec make things confusing and we do some strange things in the suite | 08:10 |
| mvo | zyga-ubuntu: if we could rely on snapshots, that would be best | 08:10 |
| zyga-ubuntu | yeah, no question about that, a snapshot (though at a right time, this is tricky too) would be wonderful | 08:10 |
| mvo | zyga-ubuntu: or some way to ensure that prepare/restore really go back to a pristine state but given the amount of things that could change (apparmor profiles in memory, kernel bootloader vars, on-disk state) this is really hard | 08:11 |
| zyga-ubuntu | ahem | 08:11 |
| mvo | zyga-ubuntu: haha | 08:11 |
| * mvo hugs zyga-ubuntu | 08:11 | |
| zyga-ubuntu | https://github.com/snapcore/spread/pull/47 | 08:11 |
| mup | PR spread#47: Add support for project-wide measure-each stanza <Created by zyga> <https://github.com/snapcore/spread/pull/47> | 08:11 |
| mvo | zyga-ubuntu: do you feel better today? | 08:11 |
| zyga-ubuntu | mvo: yes, less coughing :) | 08:11 |
| mvo | zyga-ubuntu: I remember this one! | 08:11 |
| zyga-ubuntu | I wish we could just land it | 08:11 |
| mborzecki | could we dump the profiles, clean the state in prepare/restore each steps instead of just the selected tasks? | 08:11 |
| mvo | zyga-ubuntu: btw when I use less leaves from your tea its not so strong, I like this better | 08:12 |
| zyga-ubuntu | mborzecki: I think part of the problem is how our prepare/restore is organised, it's not really prepare and restore | 08:12 |
| zyga-ubuntu | prepare does restore internally | 08:12 |
| zyga-ubuntu | and restore is mostly a no-op | 08:12 |
| mvo | mborzecki: I think the profile restore is something to explore, I'm try to reproduce now again and then will add it | 08:12 |
| mvo | zyga-ubuntu: yeah, this part is also slightly terrible | 08:13 |
| zyga-ubuntu | mvo: yeah, I also use the same set of leaves throughout the day, it's easily good enough for 2-3 infusions | 08:13 |
| zyga-ubuntu | mvo: I'm fixing that now | 08:13 |
| mvo | zyga-ubuntu: \o/ | 08:13 |
| zyga-ubuntu | mvo: the MATCH pr is the first step now | 08:13 |
| zyga-ubuntu | chipaca had this idea some months ago | 08:13 |
| zyga-ubuntu | mvo: I'm making it so that prepare really prepares (applies tarball) and restore really cleans up | 08:14 |
| zyga-ubuntu | using the measure feature to ensure it's happening for real | 08:14 |
| zyga-ubuntu | though it will be a few PRs to review | 08:14 |
| zyga-ubuntu | mvo: what I found interesting is places that are not covered by the tarball | 08:14 |
| zyga-ubuntu | like various caches | 08:14 |
| zyga-ubuntu | like the apparmor cache you started cleaning now | 08:14 |
| mborzecki | afair apparmor has an in kernel db so even if you clean the cache, the rules may still be there right? | 08:15 |
| zyga-ubuntu | yes | 08:15 |
| zyga-ubuntu | totally | 08:15 |
| zyga-ubuntu | that is another thing we should clean | 08:15 |
| zyga-ubuntu | but it's not trivial as we really want to restore the right state | 08:16 |
| zyga-ubuntu | not discard it | 08:16 |
| zyga-ubuntu | part of the state is "competed" by the Apparmor init script | 08:16 |
| zyga-ubuntu | it will parse, compile, cache and load all the profiles | 08:16 |
| mborzecki | clean by rebooting :) | 08:16 |
| zyga-ubuntu | haha | 08:16 |
| zyga-ubuntu | yeah ;) | 08:16 |
| zyga-ubuntu | mvo: I ran core transition and security cgroups and it passed :/ | 08:16 |
| zyga-ubuntu | (I don't have your branch in yet) | 08:17 |
| zyga-ubuntu | hey chihchun_afk :-) | 08:17 |
| zyga-ubuntu | mvo: would the edge being really newer affect the failure rate in the release branch? | 08:18 |
| mborzecki | zyga-ubuntu: otoh reboot is pretty much instant with the cloud images running under qemu | 08:19 |
| itsfemme[m] | is there a way to search for free software snaps? | 08:19 |
| zyga-ubuntu | itsfemme[m]: yes though it's not exposed in the UI yet AFAIK | 08:21 |
| itsfemme[m] | got a URL? | 08:22 |
| zyga-ubuntu | no | 08:22 |
| zyga-ubuntu | it's just implemented on the store now | 08:22 |
| mvo | zyga-ubuntu: yeah, the fact that edge is now in sync (more or less) with master means even with the "wrong" profiles being loaded things are ok because the profile in edge is pretty much identical | 08:22 |
| mvo | zyga-ubuntu: I have some hopes in release/2.32 but its only on 22/232 and ok so far | 08:22 |
| mvo | zyga-ubuntu: I run one with just the cgroups now | 08:22 |
| zyga-ubuntu | mvo: can we do an experiment that would not affect master | 08:22 |
| zyga-ubuntu | mvo: publish 2.31 in some channel | 08:23 |
| zyga-ubuntu | and I can run tests against that channel | 08:23 |
| zyga-ubuntu | I want to nail the issue, not hide it till next time | 08:23 |
| mvo | zyga-ubuntu: again, we are in agreement, lets nail it | 08:24 |
| mvo | zyga-ubuntu: I would need a track to publish 2.31 (or a branch). I think I need store support for this | 08:24 |
| zyga-ubuntu | yes, | 08:24 |
| zyga-ubuntu | perhaps pedronis and noise][ can arrange that | 08:25 |
| mup | PR snapd#4815 closed: tests: fix re-exec profile generation in tests on classic <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4815> | 08:29 |
| pedronis | I cannot create tracks, but for sure store can help with a track or branch | 08:34 |
| mwhudson | do i want to think about why downloading snaps is way slower inside a lxd than outside? | 08:35 |
| zyga-ubuntu | proxy settings not used? | 08:37 |
| zyga-ubuntu | how much slower is slower? | 08:37 |
| === LtWorf_ is now known as LtWorf | ||
| zyga-ubuntu | mvo: do you want to keep https://github.com/snapcore/snapd/pull/4814/files ? | 08:40 |
| mup | PR #4814: tests: fix re-exec profile generation in tests on classic (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4814> | 08:40 |
| mvo | zyga-ubuntu: for now, I want to see if it breaks and in what way | 08:41 |
| zyga-ubuntu | ok | 08:41 |
| mvo | zyga-ubuntu: I will set it to blocked if the tests pass | 08:41 |
| mvo | zyga-ubuntu: I think the first commit is actually correct and should land but the rest is dubious | 08:41 |
| mvo | zyga-ubuntu: also, the first commit is not sufficient (as we established) so :( | 08:41 |
| mborzecki | anyone wants to take a look at #4781? | 08:46 |
| mup | PR #4781: wrappers: refactor desktop file sanitizer to support autostart files <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4781> | 08:46 |
| mvo | zyga-ubuntu: yay, now I have the bug in the 2.32 PR | 08:48 |
| zyga-ubuntu | !! | 08:48 |
| zyga-ubuntu | where? | 08:48 |
| mvo | zyga-ubuntu: in the fix-reexec-snap-confine-profile-generateion (2.32 based) branch | 08:49 |
| mvo | zyga-ubuntu: in canonical-livepatch | 08:49 |
| mvo | zyga-ubuntu: the on-disk profile is correct AFAICT | 08:49 |
| mvo | zyga-ubuntu: but I get an error | 08:49 |
| zyga-ubuntu | if you reload the profile | 08:50 |
| zyga-ubuntu | is that fixing things? | 08:50 |
| zyga-ubuntu | I assume you have a shell now | 08:50 |
| mvo | zyga-ubuntu: just reloading does not help | 08:50 |
| zyga-ubuntu | ok, what is the denial you see | 08:50 |
| mvo | zyga-ubuntu: *but* changing the profile (adding a whitespace) and reloading | 08:50 |
| mvo | zyga-ubuntu: fixes it | 08:50 |
| zyga-ubuntu | exactly the same as before? | 08:50 |
| zyga-ubuntu | oooooooh | 08:50 |
| zyga-ubuntu | so caching? | 08:51 |
| mvo | zyga-ubuntu: yeah, looks very much like it | 08:51 |
| zyga-ubuntu | head.wall() | 08:51 |
| mvo | zyga-ubuntu: its "funny", I had this discussion back in the click days iirc, that the cache should use more data than just the mtime :/ | 08:51 |
| mvo | zyga-ubuntu: I suspect it is something like "a new aa profile is written; profile is cached; we restore to the previous aa profile in the restore step; the apparmor-parser sees that the mtime of the cache is nwewer than the mtime of the profile -> does nothing" | 08:52 |
| zyga-ubuntu | yeah | 08:53 |
| zyga-ubuntu | that's very likely | 08:53 |
| mvo | zyga-ubuntu: the question is how to nuke all apparmor caches | 08:53 |
| zyga-ubuntu | one sec | 08:53 |
| mvo | zyga-ubuntu: i.e. what to do short term, then what to do longer term | 08:53 |
| zyga-ubuntu | I have a patch for the nuclear option | 08:53 |
| mvo | zyga-ubuntu: bring it on! | 08:54 |
| mvo | pedronis: are you working on a backport of the refrsh hold PR that was recently merged? or shall I have a look? | 08:56 |
| mvo | pedronis: fwiw, 2.32 is blocked right now on this apparmor caching bug zyga-ubuntu and I are chasing | 08:56 |
| pedronis | mvo: I will work on it, I forgot to squash it though, so it will be a bit annoying | 08:57 |
| pedronis | mvo: it needs a follow up anyway, with the actual policy (which is what I'm working on right now, I had a variant yesterday but I had some ideas to simplify it a bit) | 08:58 |
| mvo | pedronis: cool, please let me know if I can help in any way | 08:59 |
| zyga-ubuntu | mvo: https://github.com/snapcore/snapd/pull/4822 | 09:03 |
| mup | PR #4822: interfaces/apparmor: skip apparmor cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4822> | 09:03 |
| zyga-ubuntu | mvo: just for consideration | 09:03 |
| zyga-ubuntu | I wonder what will happen | 09:03 |
| mup | PR snapd#4822 opened: interfaces/apparmor: skip apparmor cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4822> | 09:03 |
| mvo | zyga-ubuntu: lets run that against 2.32 and we will know :) | 09:04 |
| zyga-ubuntu | ah, sorry, I'll make a 2.32 variant | 09:04 |
| zyga-ubuntu | mvo: the backport is https://github.com/snapcore/snapd/pull/4823 | 09:09 |
| mup | PR #4823: interfaces/apparmor: skip apparmor cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4823> | 09:09 |
| mup | PR snapd#4823 opened: interfaces/apparmor: skip apparmor cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4823> | 09:09 |
| mvo | zyga-ubuntu: cool, lets see what the tests say | 09:09 |
| zyga-ubuntu | just in case the smoking gun is found | 09:10 |
| zyga-ubuntu | what do we do | 09:10 |
| zyga-ubuntu | fix apparmor parser caching ourselves? | 09:10 |
| mvo | zyga-ubuntu: its mostly test related, I think we fix the tests and "gently" remind the team that the apparmor caching could need some love | 09:10 |
| mvo | zyga-ubuntu: I suspect https://bugs.launchpad.net/snappy/+bug/1460152 | 09:11 |
| 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> | 09:11 |
| zyga-ubuntu | mvo: I recall we had a spike on error.u.c | 09:11 |
| zyga-ubuntu | could that be related? | 09:11 |
| mvo | zyga-ubuntu: maybe, but I suspect its different reason, this looks tests related to me still (but maybe I'm wrong) | 09:12 |
| zyga-ubuntu | on a related note, can you look at https://github.com/snapcore/snapd/pull/4821 | 09:13 |
| mup | PR #4821: tests: define MATCH from spread <Created by zyga> <https://github.com/snapcore/snapd/pull/4821> | 09:13 |
| zyga-ubuntu | it will help me land small refactors to prepare-restore next | 09:13 |
| mvo | zyga-ubuntu: sure, looking | 09:22 |
| mvo | zyga-ubuntu: why tail -n +2 ? | 09:23 |
| mvo | zyga-ubuntu: what is in the first two lines? | 09:23 |
| zyga-ubuntu | thank you | 09:23 |
| zyga-ubuntu | https://www.irccloud.com/pastebin/4E4oqQqV/ | 09:24 |
| mvo | zyga-ubuntu: aha, I see | 09:29 |
| mvo | zyga-ubuntu: replied in the PR | 09:30 |
| zyga-ubuntu | replied as well | 09:34 |
| mvo | ta | 09:34 |
| === __chip__ is now known as Chipaca | ||
| zyga-ubuntu | mvo: I see an error | 09:42 |
| zyga-ubuntu | but it makes no sense | 09:42 |
| zyga-ubuntu | + MATCH gadget | 09:43 |
| zyga-ubuntu | + snap list | 09:43 |
| zyga-ubuntu | error: pattern not found, got: | 09:43 |
| zyga-ubuntu | Name Version Rev Tracking Developer Notes | 09:43 |
| zyga-ubuntu | core 16-2.31.2+git610.7a79b84 4229 edge canonical core | 09:43 |
| zyga-ubuntu | this is in https://github.com/snapcore/snapd/pull/4822 | 09:43 |
| mup | PR #4822: interfaces/apparmor: skip apparmor cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4822> | 09:43 |
| mup | PR snapd#4768 closed: [RFC] snap userd autostart v2 <Sprint> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4768> | 09:43 |
| zyga-ubuntu | mvo: shall I restart? | 09:43 |
| zyga-ubuntu | those were in master | 09:43 |
| zyga-ubuntu | (not in the 2.32) | 09:43 |
| mvo | zyga-ubuntu: yeah, master is probably not it | 09:44 |
| zyga-ubuntu | does the error make any sense to you? | 09:45 |
| mvo | zyga-ubuntu: does apparmor have more caches except /etc/apparmor.d/cache - do you happen to know? | 09:45 |
| Chipaca | very unhappy with the tests state right now :-( | 09:45 |
| mvo | zyga-ubuntu: no | 09:45 |
| zyga-ubuntu | yes | 09:45 |
| zyga-ubuntu | it has two caches | 09:45 |
| zyga-ubuntu | one legacy | 09:45 |
| mvo | Chipaca: we are as well | 09:45 |
| zyga-ubuntu | and one "modern" | 09:45 |
| * Chipaca hugs everybody | 09:45 | |
| zyga-ubuntu | one is in /var/apparmor/cache | 09:45 |
| mvo | Chipaca: we are head first diving into it and its not pretty | 09:45 |
| * Chipaca is still grumpy tho | 09:45 | |
| mvo | Chipaca: rightfully so | 09:45 |
| zyga-ubuntu | another one is in /etc/apparmor.d/cache AFAIR | 09:45 |
| zyga-ubuntu | hey Chipaca :) | 09:45 |
| mvo | zyga-ubuntu: thanks | 09:46 |
| zyga-ubuntu | why are you grumpy? | 09:46 |
| Chipaca | zyga-ubuntu: tests breakage | 09:46 |
| zyga-ubuntu | Chipaca: hug the tests | 09:46 |
| zyga-ubuntu | :D | 09:46 |
| Chipaca | zyga-ubuntu: my huggage would be to feature flag errything | 09:46 |
| Chipaca | so maybe not the best approach | 09:47 |
| zyga-ubuntu | mvo: any ideas? | 09:47 |
| zyga-ubuntu | (caches in /etc are "fun") | 09:47 |
| zyga-ubuntu | mvo: shall we restart that PR/ | 09:48 |
| mvo | zyga-ubuntu: works for me | 09:48 |
| mvo | zyga-ubuntu: I'm trying different things in parallel but its seems to be all not quite fixing it :( | 09:48 |
| mvo | zyga-ubuntu: I think I am getting annoyed as well | 09:48 |
| mvo | Chipaca: master at least should be more happy now, no? tests there? | 09:49 |
| zyga-ubuntu | mvo: that's good, this is a great motivation technique | 09:49 |
| mvo | Chipaca: because we got a new core overnight | 09:49 |
| zyga-ubuntu | mvo: let's merge my MATCH pr (with changes if you wish) and let's reorganise prepare-restore | 09:49 |
| Chipaca | mvo: dunno master; #4820 has been red five times already, for everything from layouts to cgroups to network | 09:50 |
| mup | PR #4820: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <https://github.com/snapcore/snapd/pull/4820> | 09:50 |
| zyga-ubuntu | mvo: and the 2.32 PR failed now | 09:50 |
| mvo | Chipaca: oh, right - layout will still be a problem | 09:50 |
| zyga-ubuntu | cannot execute snap-update-ns: Permission denied | 09:50 |
| mvo | Chipaca: but cgroups should be ok now, did that run today? | 09:50 |
| zyga-ubuntu | :-( | 09:50 |
| zyga-ubuntu | I don't know what's going on now | 09:50 |
| mvo | zyga-ubuntu: meh, that is exactly the failure that I think comes from a stale cache | 09:50 |
| zyga-ubuntu | mvo: hold on, maybe the --skip-cache does something silly | 09:51 |
| * zyga-ubuntu looks | 09:51 | |
| Chipaca | mvo: it might've been late yesterday, or today, one side or the other of the date line | 09:51 |
| zyga-ubuntu | -K, --skip-cache | 09:51 |
| zyga-ubuntu | Perform no caching at all: disables -W, implies -T. | 09:51 |
| mvo | zyga-ubuntu: also maybe for some reason aa thinks the profile has not changed? | 09:51 |
| mvo | Chipaca: ok, just for "fun", please restart | 09:51 |
| zyga-ubuntu | mvo: but without any caching how could it decide? | 09:51 |
| mvo | Chipaca: if it still fails in the cgroups I will consider start drinking | 09:52 |
| zyga-ubuntu | mvo: one more idea | 09:52 |
| Chipaca | mvo: i did (and then it failed on another thing) | 09:52 |
| mvo | zyga-ubuntu: I have no idea | 09:52 |
| zyga-ubuntu | actually, not sure | 09:52 |
| mvo | Chipaca: aha, what is this other thing? | 09:52 |
| zyga-ubuntu | I wanted to say that we could wrap apparmor_parser | 09:52 |
| mvo | zyga-ubuntu: ohhhh | 09:52 |
| zyga-ubuntu | oh? | 09:52 |
| mvo | zyga-ubuntu: you probably need my first commit | 09:52 |
| mvo | zyga-ubuntu: wait a sec | 09:52 |
| zyga-ubuntu | kk | 09:52 |
| zyga-ubuntu | just push to those PRs | 09:52 |
| Chipaca | mvo: a bunch of unrelated stuff like econnreset | 09:53 |
| Chipaca | mvo: and now it's failed yet again, this time in suite prepare | 09:53 |
| mvo | zyga-ubuntu: I think you need https://github.com/snapcore/snapd/pull/4814/commits/8c065f9f22547497ca0c925009fe1b448ea78045 or you will never have the right profile in the first place | 09:53 |
| mup | PR #4814: tests: fix re-exec profile generation in tests on classic (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4814> | 09:53 |
| Chipaca | so that's six times | 09:53 |
| mvo | zyga-ubuntu: i.e. without that commit the snap-confine profile for core is always incorrect | 09:53 |
| zyga-ubuntu | Chipaca: in suite prepare? | 09:53 |
| * Chipaca gives up on this programming stuff and goes shopping | 09:53 | |
| mvo | zyga-ubuntu: with that commit it becomes a caching issue (I think) | 09:53 |
| mvo | Chipaca: in prepare suite :( | 09:54 |
| mvo | Chipaca: what is the link to the log? | 09:54 |
| zyga-ubuntu | mvo: will you push or do you want me to cherry-pick? | 09:54 |
| Chipaca | https://api.travis-ci.org/v3/job/352504456/log.txt | 09:54 |
| zyga-ubuntu | + tar -C/ -xf /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz | 09:55 |
| zyga-ubuntu | tar: /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz: Cannot open: No such file or directory | 09:55 |
| zyga-ubuntu | I have no words | 09:55 |
| zyga-ubuntu | is there a gnome pissing into the milk | 09:55 |
| zyga-ubuntu | and messing up our tests | 09:55 |
| Chipaca | zyga-ubuntu: s/gnome/elephant/ | 09:55 |
| mborzecki | hmm GNOME? :) | 09:56 |
| mvo | zyga-ubuntu: if you could cherry-pick | 09:57 |
| zyga-ubuntu | sure | 09:57 |
| zyga-ubuntu | mvo: pushed, | 09:59 |
| zyga-ubuntu | do you think it's worth to try to wrap apparmor_parser | 09:59 |
| zyga-ubuntu | and do caching ourselves? | 09:59 |
| zyga-ubuntu | we can use apparmor_parser to get the raw data | 09:59 |
| zyga-ubuntu | and use any logic we wish to cache or discard the raw data (compiled profiles) | 10:00 |
| pedronis | zyga-ubuntu: is the branch just to check if it helps? or is the plan to really turn off the cache? | 10:02 |
| zyga-ubuntu | pedronis: just to check | 10:02 |
| zyga-ubuntu | (hence the rfc) | 10:02 |
| zyga-ubuntu | if the caching system is broken we can work around it | 10:02 |
| zyga-ubuntu | I think we really could cache ourselves | 10:02 |
| zyga-ubuntu | since the parser gives us the primitives | 10:02 |
| pedronis | the rfc? | 10:03 |
| pedronis | the description is very not rfcs | 10:03 |
| pedronis | but maybe I'm misunderstanding | 10:04 |
| Chipaca | mvo: are you still using that log, or can i nuke it? | 10:04 |
| mvo | Chipaca: nuke it | 10:04 |
| mvo | zyga-ubuntu: thats a nice idea, use our own wrapper at least in the tests to understand things better | 10:05 |
| zyga-ubuntu | ok, I'll get to it | 10:05 |
| mvo | zyga-ubuntu: but same deal I think all followup work needs https://github.com/snapcore/snapd/pull/4814/commits/8c065f9f22547497ca0c925009fe1b448ea78045 first | 10:06 |
| mup | PR #4814: tests: fix re-exec profile generation in tests on classic (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4814> | 10:06 |
| mvo | (so that the initial profile is ok) | 10:06 |
| zyga-ubuntu | mvo: is this ok? https://github.com/snapcore/snapd/pull/4823 | 10:07 |
| mup | PR #4823: interfaces/apparmor: skip apparmor cache (2.32) <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/4823> | 10:07 |
| mvo | zyga-ubuntu: yes, can't wait to see the result | 10:07 |
| mvo | zyga-ubuntu: its also super annoying, spread failed, my local run is still going strong :( | 10:07 |
| mvo | zyga-ubuntu: for 4814 | 10:08 |
| zyga-ubuntu | yeah, it's a day that keeps giving | 10:08 |
| zyga-ubuntu | Son_Goku: hey, I have a working F28 chroot now | 10:12 |
| zyga-ubuntu | thank you for that! | 10:12 |
| mvo | zyga-ubuntu: hm, another problem is that we have ~8 workers, so ideally I would like to know what tests run on exactly the worker that failed. but spread does not give me this info, does it? | 10:14 |
| zyga-ubuntu | no, it does not | 10:14 |
| zyga-ubuntu | I wish it did | 10:14 |
| zyga-ubuntu | a sequence of tests on the worker who failed | 10:14 |
| mvo | zyga-ubuntu: yeah, in the travis run it fails after ~70 tests so with 8 works that is not that many that run on each worker | 10:15 |
| zyga-ubuntu | mvo: I'll work on a wrapper for the cache | 10:16 |
| zyga-ubuntu | just a small prototype | 10:16 |
| zyga-ubuntu | to see where this goes | 10:16 |
| mvo | ok | 10:16 |
| pedronis | can't we keep tab of the relevant raw_hash and see when it changes? | 10:19 |
| zyga-ubuntu | pedronis: can you explain please? | 10:19 |
| BjornT_ | mvo: hi! could you please rebuild and push base-18 to the store again, so that it gets the latest glibc? | 10:20 |
| pedronis | zyga-ubuntu: /sys/kernel/security/apparmor/policy/profiles/usr.lib.snapd.snap-confine.17/raw_hash | 10:20 |
| zyga-ubuntu | yeah but that's the hash of the (assuming, I didn't check) blob that comes out of the compiler | 10:20 |
| zyga-ubuntu | how does that help with the parser? | 10:20 |
| mvo | BjornT_: started a build now | 10:21 |
| mvo | BjornT_: https://code.launchpad.net/~mvo/+snap/base-18 <- sorry for the delay | 10:21 |
| pedronis | zyga-ubuntu: I assume the parser is deterministic? | 10:21 |
| * zyga-ubuntu knocks on wood | 10:21 | |
| zyga-ubuntu | I hope so | 10:21 |
| pedronis | so we can track the values of that and when it changes | 10:21 |
| zyga-ubuntu | hold on | 10:21 |
| zyga-ubuntu | when what changes? | 10:21 |
| pedronis | or also try hold of what we expect to be sane | 10:21 |
| zyga-ubuntu | is the idea designed to optimise the cache or to do something else? | 10:22 |
| pedronis | zyga-ubuntu: when we load the profile for real and the profile is different that should change no? | 10:22 |
| mvo | pedronis: yeah, we can store the value when the suite starts and fail if the fails, then we can narrow down what test breaks it | 10:22 |
| pedronis | zyga-ubuntu: to understand if we have loaded what we expect | 10:22 |
| zyga-ubuntu | pedronis: yes, I agree | 10:22 |
| BjornT_ | mvo: thanks | 10:22 |
| mvo | fail if the value changes | 10:22 |
| mvo | sorry | 10:22 |
| zyga-ubuntu | (this assumes we understand what that value is) | 10:23 |
| zyga-ubuntu | there are more hashes there | 10:23 |
| zyga-ubuntu | I don't know what they do | 10:23 |
| zyga-ubuntu | (yet) | 10:23 |
| * zyga-ubuntu is experimenting | 10:23 | |
| pedronis | mvo: something like that, to make this a bit tractable | 10:23 |
| zyga-ubuntu | pedronis: for debugging yeah | 10:23 |
| pedronis | yes, for debugging | 10:23 |
| zyga-ubuntu | though it's not super clear how to map that, the profiles are loaded into subsequent slots | 10:23 |
| zyga-ubuntu | and each loaded profile is really a set of profiles | 10:24 |
| zyga-ubuntu | but I think we can come up with something | 10:24 |
| zyga-ubuntu | I have an idea | 10:25 |
| zyga-ubuntu | that we can use to make the cache reliable | 10:25 |
| zyga-ubuntu | it's essentially the same problem as ccache | 10:25 |
| zyga-ubuntu | resolve all imports, use some hash of the full text as key | 10:26 |
| zyga-ubuntu | compile the pre-processed text | 10:26 |
| zyga-ubuntu | and store that in the cache under that key | 10:26 |
| zyga-ubuntu | that's it | 10:26 |
| zyga-ubuntu | ccache for apprmor | 10:26 |
| pedronis | zyga-ubuntu: afaiu raw_hash is the sha1sum of raw_data | 10:26 |
| mup | PR snapd#4824 opened: tests: fix re-exec profile generation in tests on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4824> | 10:28 |
| zyga-ubuntu | mvo: can you vote on 4821 | 10:29 |
| zyga-ubuntu | I can make it a stub if that's what you want | 10:29 |
| pedronis | zyga-ubuntu: mvo: piece of good news afaict (here) : apparmor_parser -S of the snap_confine profile |sha1sum produces the same value as raw_hash | 10:31 |
| mvo | zyga-ubuntu: I'm a bit on the fence, if there is a use case for it, then lets keep it, otherwise I would say make it a stub (YAGNI and all that) | 10:31 |
| zyga-ubuntu | good | 10:31 |
| mvo | pedronis: \o/ | 10:31 |
| zyga-ubuntu | mvo: I can make it a stub | 10:31 |
| zyga-ubuntu | mvo: I need it for real stuff after that | 10:32 |
| pedronis | mvo: zyga-ubuntu: I mean this: https://pastebin.ubuntu.com/p/4XGYSmk8zt/ | 10:33 |
| mvo | zyga-ubuntu: ok, if a stub is enough lets do that (if you don't mind) | 10:33 |
| zyga-ubuntu | yes | 10:33 |
| zyga-ubuntu | that's fine | 10:33 |
| mborzecki | why do we enable the services first and the do a daemon-reload? | 10:33 |
| zyga-ubuntu | I'll finish the parser wrapper and do it in a moment | 10:33 |
| zyga-ubuntu | mborzecki: huh? | 10:33 |
| zyga-ubuntu | that's odd | 10:33 |
| mborzecki | https://github.com/snapcore/snapd/blob/master/wrappers/services.go#L244 runs before daemon-reload | 10:34 |
| pedronis | mvo: saw I think we could compute the hash in prepare somewhere and fail when it changes (and decide when is expected and what we need to do) | 10:34 |
| pedronis | s/saw/so/ | 10:34 |
| mup | PR snapd#4825 opened: overlord/snapstate: implement policy of holding refreshes for up to 6h since seeding on classic <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4825> | 10:37 |
| mvo | BjornT_: core build failed with what looks like a snapcraft error: if ElfFile.is_elf(path): | 10:39 |
| mvo | File "/usr/lib/python3/dist-packages/snapcraft/internal/elf.py", line 152, in is_elf | 10:39 |
| mvo | with open(path, 'rb') as bin_file: | 10:39 |
| mvo | OSError: [Errno 6] No such device or address: '/build/base-18/prime/dev/tty' | 10:39 |
| mvo | sergiusens: -^ | 10:39 |
| mup | PR snapd#4826 opened: wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4826> | 10:41 |
| mvo | zyga-ubuntu: and no build slots right now, a bit frustrating | 10:42 |
| zyga-ubuntu | I have a wrapper | 10:42 |
| zyga-ubuntu | man | 10:42 |
| mborzecki | mvo: sorry, feel free to cancel the job for my PR, i'll restart it later | 10:43 |
| BjornT_ | mvo: ah. we saw those errors when building locally. i think it's fixed already in snapcraft master, though. | 10:44 |
| mvo | mborzecki: no worries, I think cacneling will not even help | 10:48 |
| mvo | BjornT_: aha, ok | 10:48 |
| mvo | BjornT_: thank you! | 10:48 |
| mborzecki | zyga-ubuntu: https://forum.snapcraft.io/t/race-condition-between-snapd-and-nm-when-providing-permissions/4451 serial devices go though device cgroups too right? | 10:49 |
| zyga-ubuntu | yes | 10:49 |
| zyga-ubuntu | mvo: can you please look at https://github.com/snapcore/snapd/pull/4827 | 10:51 |
| mup | PR #4827: cmd/snap-apparmor-parser: add a prototype apparmor parser <Created by zyga> <https://github.com/snapcore/snapd/pull/4827> | 10:51 |
| zyga-ubuntu | I will replace the real stuff with this now, ok? | 10:51 |
| zyga-ubuntu | and we can implement the cache in a real language next | 10:51 |
| mup | PR snapd#4827 opened: cmd/snap-apparmor-parser: add a prototype apparmor parser <Created by zyga> <https://github.com/snapcore/snapd/pull/4827> | 10:51 |
| * Chipaca goes for a walk | 10:52 | |
| mvo | zyga-ubuntu: looks good but I think we first need to figure out if that fixes our issues before replace the real thing (i.e. one step at a time :) | 11:02 |
| zyga-ubuntu | mvo: hold on, how do we know that if we replace the real thing | 11:03 |
| zyga-ubuntu | I meant to write it and use it to see if this makes anything better | 11:04 |
| zyga-ubuntu | we don't have to merge it | 11:04 |
| zyga-ubuntu | s/if we replace the real thing/if we *don't* replace the real thing/ | 11:04 |
| pedronis | do we even know what is broken? | 11:05 |
| zyga-ubuntu | pedronis: mvo ran a test where the profile on disk was ok, in memory was bad, running the parser did nothing unless a trivial whitespace change was introduced | 11:05 |
| zyga-ubuntu | this hints at a bug in the cache | 11:05 |
| zyga-ubuntu | which is based solely on mtime | 11:05 |
| pedronis | well, it would be good to have a reproducer then | 11:05 |
| pedronis | to submit a bug | 11:05 |
| pedronis | it also sounds very bad | 11:06 |
| zyga-ubuntu | upstream knows about this bug | 11:06 |
| zyga-ubuntu | we had this conversation a few times now | 11:06 |
| Son_Goku | zyga-ubuntu, \o/ | 11:06 |
| pedronis | is the mtime a problem for us in general or because the tests do strange things? | 11:06 |
| mvo | pedronis: I think our tests make the story more complicated | 11:07 |
| mvo | pedronis: and +100 for a reliable reproducer | 11:07 |
| zyga-ubuntu | yeah, but I want to say that pedronis is right we don't have a single, well defined problem | 11:08 |
| zyga-ubuntu | we had a problem with edge version | 11:08 |
| zyga-ubuntu | how "went away" (not really fixed) | 11:08 |
| zyga-ubuntu | we definitely have a problem with mtime and cache but it is unclear why | 11:08 |
| zyga-ubuntu | and we may have more problems we don't know about yet | 11:08 |
| pedronis | I still think that adding logic to the tests that check what we expect to be loaded | 11:08 |
| zyga-ubuntu | the wrapper is meant to make the mtime problem void | 11:08 |
| mvo | pedronis: so what I ran into was that I got a denial from "canonical-livepatch status" about it being not able to run snap-device-helper. then I tried appamror_parser -r which did not help, then a whitespace change in the profile and then apparmor_parser -r and things were ok | 11:08 |
| pedronis | vs what is laoded match would halep | 11:08 |
| pedronis | help | 11:08 |
| mvo | pedronis: unfortunately super hard to get into the right (i.e. broken) state | 11:08 |
| zyga-ubuntu | mvo: I pushed the stub MATCH | 11:09 |
| zyga-ubuntu | and I'll merge when green | 11:09 |
| pedronis | anyway if it's naively mtime based | 11:09 |
| zyga-ubuntu | but first, I need to take a break and take the dog for a walk | 11:09 |
| pedronis | problem should occur only if we go back in time | 11:09 |
| mvo | zyga-ubuntu: ok | 11:09 |
| pedronis | I suppose our revert might not work | 11:09 |
| pedronis | anyway we could test this stuff out | 11:09 |
| mvo | pedronis: I have not looked in ages how it works, it used to be mtime based and the pattern I saw indicates it but I did not double check | 11:10 |
| cachio | mvo, hey, I didn't see any error reported in the forum on candidate | 11:10 |
| Chipaca | zyga-ubuntu: good idea wrt making the stub MATCH dummy | 11:10 |
| cachio | mvo, may I promote to stable? | 11:10 |
| Chipaca | zyga-ubuntu: if you visit that file again, maybe make it echo to stderr instead of stdout | 11:10 |
| pedronis | mvo: ok, as I said I just fear that fixing things before understanding them will just add to the confusion | 11:10 |
| mvo | cachio: yay, then I would say lets just give a quick heads up in the store channel | 11:10 |
| mvo | cachio: and go | 11:10 |
| pedronis | of which it seems we have plenty | 11:10 |
| mvo | pedronis: yeah | 11:10 |
| cachio | mvo, sure | 11:10 |
| mvo | pedronis: not disagreeing at all | 11:11 |
| Chipaca | brb, changing machines around | 11:11 |
| mvo | pedronis: we found one thing that is broken | 11:11 |
| mvo | pedronis: but there is more lurking, I added a crude hash compare now to one of my test PRs | 11:12 |
| mvo | pedronis: essentially what you suggested, maybe that gives us a clue | 11:12 |
| mvo | pedronis: it hooks into restore so hopefully it gives us a hint what test is changing things | 11:12 |
| pedronis | mvo: -k seems also interesting for debugging | 11:13 |
| mvo | pedronis: indeed | 11:15 |
| pedronis | anyway the man page is quite explicit about it being time based | 11:18 |
| pedronis | fwiw | 11:18 |
| * mvo nods | 11:18 | |
| Chipaca | mvo: zyga-ubuntu: any problem about merging things to master right now? (finally got green..) | 11:32 |
| cachio | mvo, well, core promoted to stable | 11:33 |
| Chipaca | niemeyer: it seems you changed spread to only build with a go newer than 1.6 and it's breaking autopackagetest | 11:33 |
| Chipaca | niemeyer: “go get -u github.com/snapcore/spread/cmd/spread” spits out “package context: unrecognized import path "context" (import path does not begin with hostname)” with 1.6 now | 11:34 |
| zyga-ubuntu | Chipaca: still Alf | 11:40 |
| zyga-ubuntu | Afk | 11:40 |
| zyga-ubuntu | But I think it is ok | 11:41 |
| Chipaca | zyga-ubuntu: https://i.imgur.com/ZTNhK7W.png | 11:41 |
| zyga-ubuntu | lol | 11:42 |
| zyga-ubuntu | Alf says “let’s eat this cat” | 11:42 |
| mvo | cachio: thanks | 11:43 |
| mvo | Chipaca: should be fine | 11:43 |
| Chipaca | ack | 11:44 |
| mup | PR snapd#4820 closed: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4820> | 11:44 |
| cachio | mvo, niemeyer I'll be few minutes late today in the standup | 11:45 |
| * cachio afk | 11:45 | |
| zyga-ubuntu | re | 11:56 |
| zyga-ubuntu | Chipaca: can you please look at https://api.travis-ci.org/v3/job/352784798/log.txt | 11:58 |
| zyga-ubuntu | it looks like logger unit tests panicked | 11:59 |
| Chipaca | ahahaha | 11:59 |
| Chipaca | zyga-ubuntu: yes i can look | 11:59 |
| zyga-ubuntu | ah | 11:59 |
| zyga-ubuntu | sorry, not logger | 11:59 |
| zyga-ubuntu | osutil | 11:59 |
| zyga-ubuntu | RunWithContext | 11:59 |
| zyga-ubuntu | hmm hmm | 11:59 |
| Chipaca | zyga-ubuntu: timeout | 12:00 |
| Chipaca | zyga-ubuntu: that's a timeout | 12:00 |
| Chipaca | zyga-ubuntu: *** Test killed with quit: ran too long (10m0s). | 12:00 |
| mup | PR snapd#4788 closed: packaging/fedora: Merge changes from Fedora Dist-Git plus trivial fix <Created by Conan-Kudo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4788> | 12:00 |
| zyga-ubuntu | Chipaca: real bug or shall I restart | 12:01 |
| * zyga-ubuntu tries to figure out what the test is | 12:01 | |
| zyga-ubuntu | TestRunRace? | 12:01 |
| Chipaca | zyga-ubuntu: yes | 12:04 |
| * zyga-ubuntu asks the wrong precise questions | 12:04 | |
| Chipaca | zyga-ubuntu: this shouldn't happen, but if it happens again let me know; there should be a way to make it exponentially less likely to happen | 12:04 |
| Chipaca | I thought this was less-likely-enough :-) | 12:04 |
| zyga-ubuntu | can you explain what went wrong here? | 12:05 |
| zyga-ubuntu | we called RunWithContext | 12:05 |
| Chipaca | zyga-ubuntu: it times how long it takes /bin/false to run | 12:05 |
| Chipaca | zyga-ubuntu: then it calls /bin/false in a loop with a timeout of exactly that time | 12:05 |
| Chipaca | zyga-ubuntu: it _should_ fail to finish, at least once, after a little bit | 12:06 |
| Chipaca | zyga-ubuntu: and it also _should_ be able to succeed, at least once, after a little bit | 12:06 |
| zyga-ubuntu | so how come it did not? after 10 minutes | 12:06 |
| Chipaca | zyga-ubuntu: it was really (un)lucky the first time | 12:06 |
| Chipaca | zyga-ubuntu: or the vm got clamped as soon as it got into a tight loop | 12:06 |
| zyga-ubuntu | I see | 12:06 |
| zyga-ubuntu | ok, I'll reboot | 12:07 |
| Chipaca | so an easy way would be | 12:07 |
| Chipaca | if it happens even one more time | 12:07 |
| Chipaca | to do two things in each loop: once with dt/2, once with 2*dt | 12:07 |
| Chipaca | if that still sometimes hiccups, change it to 4, etc :-) | 12:07 |
| Chipaca | zyga-ubuntu: that test is meant to have some surety around it not failing if the deadline happens at just the same time the command finishes though, which is why it's written as it is | 12:09 |
| Chipaca | (that's why the only thing it reports as an error is an unexpected error) | 12:10 |
| Chipaca | the more i try to work on 18.04, the less productive it feels and the more i stick with 16.04 :-( | 12:11 |
| Chipaca | can no longer alt-space x to maximize a window, for example | 12:11 |
| * Chipaca working in the 18 live cd | 12:12 | |
| zyga-ubuntu | Chipaca: how is it? I heard that snapd doesn't work but it was on old build | 12:13 |
| Chipaca | zyga-ubuntu: snapd works | 12:14 |
| Chipaca | zyga-ubuntu: snaps don't :-) | 12:14 |
| zyga-ubuntu | Chipaca: SHIP IT ;-) | 12:14 |
| Chipaca | zyga-ubuntu: yesterday I was getting the thing about snap-confine escalation yadda yadda | 12:14 |
| zyga-ubuntu | on the same ISO? | 12:15 |
| Chipaca | today i'm getting 'cannot create lock directory' | 12:15 |
| zyga-ubuntu | Chipaca: do you get an apparmor denial? | 12:15 |
| Chipaca | zyga-ubuntu: http://cdimage.ubuntu.com/daily-live/20180313/ vs http://cdimage.ubuntu.com/daily-live/20180312/ | 12:15 |
| zyga-ubuntu | are you getting a denial on /run/snapd/ns/ stuff? | 12:15 |
| zyga-ubuntu | aha | 12:15 |
| zyga-ubuntu | so daily | 12:15 |
| mvo | Chipaca: oh, you are working on the script? how nice | 12:16 |
| Chipaca | zyga-ubuntu: [ 2114.200898] audit: type=1400 audit(1520943269.861:58): apparmor="DENIED" operation="open" profile="/snap/core/4206/usr/lib/snapd/snap-confine" name="/upper/" pid=4392 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 | 12:19 |
| Chipaca | mvo: trying to | 12:19 |
| zyga-ubuntu | Chipaca: that's interesting | 12:19 |
| Chipaca | mvo: I'm going to have to rebuild it at some point, do you know if there's an easy way of doing that? | 12:19 |
| zyga-ubuntu | Chipaca: can you look at /var/lib/snapd/apparmor/snap-confine | 12:19 |
| zyga-ubuntu | and can you please paste system-eky | 12:19 |
| zyga-ubuntu | *key | 12:19 |
| zyga-ubuntu | Chipaca: unsquash, dpkg --extract | 12:20 |
| zyga-ubuntu | Chipaca: _probably) | 12:20 |
| Chipaca | zyga-ubuntu: which system key? | 12:21 |
| zyga-ubuntu | Chipaca: in /var/lib/snapd/system-key | 12:21 |
| Chipaca | zyga-ubuntu: /var/lib/snapd/apparmor/snap-confine is empty | 12:21 |
| zyga-ubuntu | Chipaca: that's expected given the symptom | 12:21 |
| zyga-ubuntu | it says that there's no overlay workaround in place | 12:22 |
| Chipaca | zyga-ubuntu: /var/lib/snapd/system-key does not exist | 12:22 |
| zyga-ubuntu | if it's also not in the system-key then either you have an old snapdo | 12:22 |
| zyga-ubuntu | or the logic is broken | 12:22 |
| * zyga-ubuntu looks | 12:22 | |
| Chipaca | 2.31.2 | 12:22 |
| zyga-ubuntu | that's too old :/ | 12:22 |
| zyga-ubuntu | you need master or 2.32 | 12:22 |
| Chipaca | I wasn't expecting it to work given just yesterday you were saying it was only fixed on master | 12:22 |
| zyga-ubuntu | I wonder why there's no system-key though | 12:22 |
| zyga-ubuntu | 2.31 should have it | 12:22 |
| * Chipaca takes a break from 18.04 and looks at lunch | 12:27 | |
| zyga-ubuntu | lunch sounds nice | 12:27 |
| zyga-ubuntu | I'm preparing a prototype of snapd-side apparmor cache | 12:27 |
| Chipaca | zyga-ubuntu: cuban black beans sounds a'ight today, with it being dull outside | 12:28 |
| Chipaca | pedronis: if you have a bit of time I could use a look at #4790 (which purports to fix #1750527) | 12:29 |
| mup | PR #4790: jsonutil/puritan: introducing puritan.String & etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/4790> | 12:29 |
| mup | PR snapd#4828 opened: many: support holding refreshes by setting refresh.hold (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4828> | 12:32 |
| pedronis | mvo: I made the backport ^ needs to go together with #4825 (once landed in master) | 12:33 |
| mup | PR #4825: overlord/snapstate: implement policy of holding refreshes for up to 6h since seeding on classic <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4825> | 12:33 |
| mborzecki | Chipaca: do you recall if `snap pack --check-skeleton` was to run ValidateContainer too? | 12:33 |
| Chipaca | mborzecki: the way we talked about it I imagined ValidateContainer growing a no-fail-on-missing mode | 12:33 |
| Chipaca | mborzecki: (or equivalently checking for and ignoring snap.ErrMissingPath when calling ValidateContainer from --check-skellie) | 12:35 |
| Chipaca | mborzecki: it'll still _log_ the error though (not sure if that's a pro or a con) | 12:36 |
| mborzecki | Chipaca: ok, i like the error checking approach better ;) | 12:36 |
| pedronis | Chipaca: I'll try to look at 4790 later today, 4825 from me also needs a review | 12:37 |
| Chipaca | pedronis: thanks | 12:37 |
| Chipaca | I'm grabbing lunch now, will look at it after | 12:37 |
| mup | PR snapd#4829 opened: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store <Created by pedronis> <https://github.com/snapcore/snapd/pull/4829> | 12:43 |
| zyga-ubuntu | mvo: hey, +1 to merge 4821 now? | 12:46 |
| * zyga-ubuntu finishes lunch | 12:47 | |
| mvo | zyga-ubuntu: sounds good | 13:00 |
| mup | PR snapd#4821 closed: tests: define MATCH from spread <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4821> | 13:01 |
| zyga-ubuntu | mvo: interesting, on a 2.32 branch that passed --skip-cache to apparmor_parser I got the denial again | 13:29 |
| zyga-ubuntu | and this PR includes your patch for re-exec profile g eneration | 13:29 |
| zyga-ubuntu | I will look at apprmor_parser now | 13:29 |
| zyga-ubuntu | maybe it ignores that flag | 13:29 |
| zyga-ubuntu | this is https://github.com/snapcore/snapd/pull/4823 | 13:29 |
| mup | PR #4823: interfaces/apparmor: skip apparmor cache (2.32) <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/4823> | 13:29 |
| tyhicks | it definitely doesn't ignore the --skip-cache flag | 13:30 |
| zyga-ubuntu | tyhicks: hey | 13:31 |
| zyga-ubuntu | so something else is broken | 13:31 |
| tyhicks | I use --skip-cache regularly and I also know that there's quite a bit of test coverage for that in parser/tst/caching.py | 13:31 |
| zyga-ubuntu | tyhicks: I'll try the snapd-side-cache prototype next | 13:31 |
| tyhicks | hey zyga-ubuntu :) | 13:31 |
| zyga-ubuntu | thank you for confirming that | 13:31 |
| zyga-ubuntu | tyhicks: I wrote https://github.com/snapcore/snapd/pull/4827 as a shoot-in-the-dark (ish) on the issues we are seeing | 13:32 |
| mup | PR #4827: cmd/snap-apparmor-parser: add a prototype apparmor parser <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/4827> | 13:32 |
| tyhicks | zyga-ubuntu: is there a short writeup on the issues you're seeing? | 13:32 |
| tyhicks | (I need to finish publishing a security update before I get too involved here) | 13:33 |
| zyga-ubuntu | tyhicks: we see an apparmor denial on snap-confine, the rest is hazy but in one case we confirmed that calling apparmor_parser --replace did _not_ fix the issue without making a no-op whitespace change. | 13:33 |
| zyga-ubuntu | tyhicks: it's probably an error related to just our testing process but it's keeping a few people busy as tests are broken. | 13:34 |
| tyhicks | zyga-ubuntu: have you been able to reproduce the issue manually, outside of your testing process, or are you stuck having to tickle the issue via the testing process? | 13:37 |
| zyga-ubuntu | it's inside the testing process | 13:37 |
| zyga-ubuntu | and it's not super reliable to reproduce because one factor changed | 13:38 |
| zyga-ubuntu | we'll try to restore that factor so that we can really understand and nail the issue | 13:38 |
| zyga-ubuntu | if we nail the issue I'll tell you what it was for sure | 13:38 |
| tyhicks | ok, let me know if I can answer any questions or help wade through apparmor_parser code | 13:40 |
| zyga-ubuntu | thank you | 13:40 |
| mvo | zyga-ubuntu: does http://paste.ubuntu.com/p/4TcqxcRdgh/ ring a bell? | 13:58 |
| zyga-ubuntu | yes | 13:59 |
| mvo | zyga-ubuntu: I see this on 14.04 and the profile does not allow running update-ns from core snap | 13:59 |
| zyga-ubuntu | it looks like we are in the system where we try to run snap-update-ns without profile transition | 13:59 |
| zyga-ubuntu | do you have a debug shell? | 13:59 |
| zyga-ubuntu | can you look at the profile for snap-confine from core | 14:00 |
| zyga-ubuntu | what's at the bottom? | 14:00 |
| mvo | zyga-ubuntu: I am | 14:00 |
| zyga-ubuntu | is is the rule -> snap-update-ns.* | 14:00 |
| zyga-ubuntu | it looks like this thing we had on Thursday | 14:00 |
| zyga-ubuntu | right? | 14:00 |
| mvo | zyga-ubuntu: http://paste.ubuntu.com/p/B2fXb62yy4/ | 14:00 |
| zyga-ubuntu | we didn't get to the bottom of that problem | 14:01 |
| zyga-ubuntu | this is the wrong profile :( | 14:01 |
| zyga-ubuntu | /var/lib/snapd/hostfs/usr/lib{,exec,64}/snapd/snap-update-ns Cxr -> snap_update_ns, | 14:01 |
| zyga-ubuntu | this is the old code, we changed that in 2.32 and master now | 14:01 |
| zyga-ubuntu | can you look at the profile in the core snap | 14:02 |
| zyga-ubuntu | is it the same? | 14:02 |
| zyga-ubuntu | mvo: to be clear, I'm saying this looks like a 2.31 profile | 14:02 |
| dan_it__ | hi all, I need some help with snapcraft, not sure if this is the right channel | 14:09 |
| dan_it__ | is there anyone online? | 14:10 |
| === pstolowski is now known as pstolowski|afk | ||
| Chipaca | dan_it__: yesish | 14:17 |
| mborzecki | i'm off to pick up the kids | 14:18 |
| Chipaca | dan_it__: things are a little hectic today | 14:18 |
| mup | PR snapd#4830 opened: many: generate and use per-snap snap-update-ns profile (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4830> | 14:28 |
| zyga-ubuntu | that's the backport | 14:28 |
| zyga-ubuntu | I'll work on layout fixes noww | 14:28 |
| mvo | zyga-ubuntu: ta | 14:32 |
| niemeyer | dan_it__: The forum is always a good place.. lots of eyes, and async so people respond as soon as they can | 14:34 |
| niemeyer | Chipaca: hangout? | 14:34 |
| Chipaca | omw | 14:34 |
| Chipaca | niemeyer: standup one? | 14:34 |
| niemeyer | Yeah | 14:34 |
| Muravey | Hi | 14:44 |
| zyga-ubuntu | coffee | 14:44 |
| Muravey | What variables are available in snapcraft.yaml | 14:45 |
| Muravey | ? | 14:45 |
| Muravey | And how to install fonts into package? | 14:46 |
| zyga-ubuntu | Muravey: we have a very very busy week, can you please look at the forum, there are (probably) people with the same desires as you now | 14:51 |
| zyga-ubuntu | Muravey: you can also open a new topic and ask your questions there | 14:51 |
| Muravey | zyga-ubuntu: ok..sorry | 14:53 |
| zyga-ubuntu | Muravey: no worries, it's not your fault we're busy today, just ask your questions there as there are more than just the snapd and snapcraft teams participating there | 14:53 |
| zyga-ubuntu | the whole snapcraft community is there | 14:53 |
| zyga-ubuntu | making and using snaps | 14:53 |
| zyga-ubuntu | it's the best place to talk | 14:53 |
| zyga-ubuntu | mvo: 4830 is green now | 15:16 |
| zyga-ubuntu | mvo: or, green from 1st try | 15:16 |
| mvo | zyga-ubuntu: green on first run? woah | 15:19 |
| zyga-ubuntu | it's magic | 15:19 |
| zyga-ubuntu | also | 15:19 |
| zyga-ubuntu | it never uses stale profiles | 15:19 |
| zyga-ubuntu | actually, it would still use stale profile for the transition | 15:20 |
| mvo | zyga-ubuntu: does it keep changing what is loaded? it must do something different | 15:20 |
| zyga-ubuntu | it does change things but it would still be affected by a stale profile | 15:20 |
| zyga-ubuntu | because it cannot do a transition without confinement permission | 15:22 |
| mvo | zyga-ubuntu: then maybe it was a lucky PR | 15:25 |
| mvo | zyga-ubuntu: still strange | 15:25 |
| zyga-ubuntu | maybe | 15:25 |
| zyga-ubuntu | I suspect there's something to it though | 15:26 |
| mvo | yeah I think so too | 15:26 |
| mvo | zyga-ubuntu: maybe it is because now edge and 2.32 are close? | 15:26 |
| zyga-ubuntu | shall we land it? | 15:26 |
| mvo | zyga-ubuntu: no | 15:26 |
| mvo | zyga-ubuntu: please not | 15:26 |
| zyga-ubuntu | yes, I suspect something like that | 15:26 |
| zyga-ubuntu | ok | 15:26 |
| mvo | zyga-ubuntu: lets wait a wee bit, I guess we could land it and then use 2.31 as the testcase | 15:27 |
| zyga-ubuntu | 2.31 as a test case? what do you mean? | 15:28 |
| mvo | zyga-ubuntu: running release/2.31 with the edge core should also show the bug | 15:29 |
| zyga-ubuntu | interesting | 15:29 |
| zyga-ubuntu | does it? | 15:29 |
| mvo | zyga-ubuntu: i.e. we probably don't need 2.32 for this | 15:29 |
| mvo | zyga-ubuntu: I have not tried yet :) but I would be surprised if not | 15:30 |
| zyga-ubuntu | careful what you wish for :) | 15:30 |
| mvo | zyga-ubuntu: haha | 15:30 |
| zyga-ubuntu | oh man | 15:30 |
| zyga-ubuntu | 16:30 | 15:30 |
| mvo | zyga-ubuntu: well, if the bug shows itself for core snap-confine profile != our snap-confine profile | 15:30 |
| zyga-ubuntu | and I forgot about the coffee | 15:30 |
| mvo | zyga-ubuntu: then… | 15:30 |
| zyga-ubuntu | yes | 15:30 |
| mvo | zyga-ubuntu: heh, go for it! | 15:30 |
| zyga-ubuntu | it will be a second | 15:30 |
| mvo | zyga-ubuntu: no worries - fwiw, test-classic-firstboot is another one of the tests that will use a unmodified core and install it. all these tests will trigger the issue I bet. /me tries | 15:32 |
| zyga-ubuntu | mvo: keep me posted, I'm curious | 15:35 |
| mvo | zyga-ubuntu: trying this now, hopefully its a minimal testcase | 15:36 |
| mvo | zyga-ubuntu: aha, maybe 2.31 is not enough - we need the system-key to trigger the bug I think | 15:38 |
| * mvo tries that too | 15:38 | |
| mup | Issue snapcraft#2001 opened: node-engine does not support NodeJS 8.X.X <Created by arkuhn> <https://github.com/snapcore/snapcraft/issue/2001> | 15:43 |
| sergiusens | mvo: that's fixed on edge, the 2.40 release will be this week which fixes that | 15:45 |
| zyga-ubuntu | hey sergiusens how are you | 15:45 |
| mvo | sergiusens: cool, thank you | 15:45 |
| zyga-ubuntu | did you get home safely and without surprises? | 15:45 |
| sergiusens | zyga-ubuntu: doing well. I am home, no further surprises or incidents | 15:46 |
| Chipaca | niemeyer: what does 'spread -list' do, to take 2s to print out the list? | 15:58 |
| * Chipaca is too lazy to go look | 15:58 | |
| Chipaca | niemeyer: if that could take an order of magnitude less, I'd write a tab-completer for it :-) | 15:59 |
| niemeyer | Chipaca: Generates the full matrix of tests, which includes reading and parsing everything | 15:59 |
| mvo | $GOPATH/bin/spread -v qemu:ubuntu-14.04-64:tests/main/classic-firstboot qemu:ubuntu-14.04-64:tests/main/interfaces-broadcom-asic-control | 16:09 |
| mvo | zyga-ubuntu: -^ | 16:10 |
| mvo | zyga-ubuntu: that works for me to reproduce, I'm testing on 16.04 now, also 4814 seems to be good now | 16:10 |
| mvo | zyga-ubuntu: slightly heavy handed though | 16:11 |
| Chipaca | mvo: completely left-field question: is there a way to tell apt to not use /var/cache/apt/archives? | 16:16 |
| mvo | cachio: yes, run "sudo apt install foo -o dir::cache=/tmp/my-cache | 16:18 |
| cachio | mvo, it was for Chipaca perhaps | 16:19 |
| mvo | Chipaca: you may need to create archives/partial in there | 16:19 |
| mvo | cachio: ups | 16:19 |
| mvo | Chipaca: -^ | 16:19 |
| Chipaca | heh | 16:19 |
| Chipaca | mvo: gotcha | 16:19 |
| mvo | Chipaca: why? | 16:19 |
| Chipaca | mvo: chatting with a guy just now and they were talking about how they have a load of space wasted in their vms because of that dir | 16:20 |
| Chipaca | mvo: an always-do-apt-clean would probably also work | 16:20 |
| mvo | Chipaca: yes | 16:21 |
| mvo | Chipaca: also unattended-upgrades cleans properly after itself | 16:21 |
| Chipaca | mvo: is there a way to do the latter? :-) | 16:21 |
| mvo | Chipaca: not right now it seems, would be very easy to have a "apt::tidy=1" option that does that automatically | 16:23 |
| mvo | Chipaca: in fact, "ulink" right after the deb was installed sounds prudent | 16:23 |
| Chipaca | mvo: thanks | 16:25 |
| mvo | Chipaca: sounds like a fun evening patch, please remind me, I think it will be a good way to forget this apparmor profile drama I'm in right now | 16:26 |
| * Chipaca hugs mvo | 16:26 | |
| popey | hi fireclawTheFox , hows the snap coming along? | 16:29 |
| fireclawTheFox | Hey popey, haven't done much yesterday and just came back from work. But yeah so far it looks good everything works. Just need to see if I can lower the size again, I think it got a few things that doesn't need to ship. | 16:31 |
| popey | ooh, we have done some of that optimisation in other snaps | 16:32 |
| zyga-ubuntu | mvo: re (dog), so does it mean you still see the issue but now have a better way of reproducing it? | 16:32 |
| Chipaca | zyga-ubuntu: mvo: FWIW my new laptop is nvidia (prime, so it has an intel mode as well), running 16.04, if you ever need to test something there (not 18 because lots of oem stuff) | 16:33 |
| zyga-ubuntu | !!! | 16:33 |
| zyga-ubuntu | wooot | 16:33 |
| zyga-ubuntu | perfect | 16:33 |
| zyga-ubuntu | first step | 16:33 |
| zyga-ubuntu | update to 18.04 :D | 16:33 |
| zyga-ubuntu | just kidding | 16:33 |
| Chipaca | zyga-ubuntu: i would, but even if i didn't hate it, i'd still not have some of the hardware | 16:33 |
| zyga-ubuntu | but some 2nd disk (usb is fine) to boot into 18.04 once in a while would help | 16:33 |
| Chipaca | ah, that i could do | 16:34 |
| zyga-ubuntu | Chipaca: I think you can reproduce the GLVND issue easily then | 16:34 |
| zyga-ubuntu | Chipaca: and you could beta-test fixes | 16:34 |
| Chipaca | i had to choose between a second disk and more battery (and i chose battery of course) | 16:34 |
| zyga-ubuntu | nah, I mean external disk | 16:34 |
| zyga-ubuntu | even a usb thumb drive | 16:34 |
| zyga-ubuntu | just for testing at home | 16:34 |
| zyga-ubuntu | no need to affect your daily experience | 16:34 |
| Chipaca | :+1: | 16:34 |
| zyga-ubuntu | you can install on it, if you are careful that is (don't overwrite your boot records) | 16:35 |
| zyga-ubuntu | are you on the nvidia driver now? | 16:35 |
| Chipaca | yes | 16:35 |
| zyga-ubuntu | and if so, which version is it? | 16:35 |
| zyga-ubuntu | does Minecraft snap work? | 16:35 |
| popey | fireclawTheFox: I find doing "ncdu /snap/<snapname>/current" is a good way to see what's taking up space in the snap | 16:35 |
| Chipaca | zyga-ubuntu: 384.111 | 16:35 |
| fireclawTheFox | popey: ah, thanks will try. | 16:36 |
| zyga-ubuntu | Chipaca: that's good, I think you are the missing link :-) | 16:36 |
| zyga-ubuntu | Chipaca: I wish you had this machine last week, I'd love to see it :) | 16:36 |
| Chipaca | minecraft snap installing | 16:36 |
| popey | \o/ | 16:36 |
| Chipaca | zyga-ubuntu: it arrived at 11am on the monday | 16:36 |
| zyga-ubuntu | Chipaca: murphy strikes | 16:36 |
| Chipaca | zyga-ubuntu: i sat all through the sprint knowing this was waiting for me on my bed | 16:36 |
| fireclawTheFox | popey: Well, basically I shouldn't need much to add aside of the things that are packed by the engine. I think I just needed some libs like pulse, and xlib stuff. | 16:36 |
| Chipaca | i had the jitters | 16:36 |
| zyga-ubuntu | Chipaca: do you own a copy of Minecraft? | 16:37 |
| zyga-ubuntu | (disclaimer: it's a fantastic procrastination helper) | 16:37 |
| Chipaca | zyga-ubuntu: 3 | 16:37 |
| zyga-ubuntu | really?! | 16:37 |
| Chipaca | zyga-ubuntu: i play with the boys | 16:38 |
| zyga-ubuntu | nice! :) | 16:38 |
| Chipaca | the minecraft launcher works | 16:38 |
| zyga-ubuntu | (we also own three haha | 16:38 |
| zyga-ubuntu | try logging in and see if it works | 16:38 |
| zyga-ubuntu | on 16.04 it should be OK | 16:38 |
| Chipaca | now downloading minecraft itself | 16:38 |
| zyga-ubuntu | so 16.04 is the baseline | 16:38 |
| Chipaca | yes it works | 16:38 |
| zyga-ubuntu | ok, sometime this week it'd be great to try if Minecraft works with nvidia on 18.04 | 16:39 |
| zyga-ubuntu | do you have a spare disk to install bionic on? | 16:39 |
| Chipaca | zyga-ubuntu: pendrives, yes | 16:39 |
| zyga-ubuntu | cool | 16:40 |
| Chipaca | actual disk, maybe? still usb though | 16:40 |
| zyga-ubuntu | I don't have a fix yet, I'll do one just after layouts (I need two days perhaps, for layouts) | 16:40 |
| zyga-ubuntu | pen drives are fine | 16:40 |
| Chipaca | zyga-ubuntu: also it'll be good to know if it works when in intel mode | 16:41 |
| zyga-ubuntu | I didn't even consider that | 16:41 |
| Chipaca | :-) | 16:41 |
| zyga-ubuntu | I don't know how the switching works | 16:41 |
| Chipaca | i need to log out and back in, so not that magic | 16:41 |
| Chipaca | it's not the old voodoo switch thing :-) | 16:42 |
| mvo | zyga-ubuntu: I thought so but its random and now its no longer reproducible and its all horrible | 16:42 |
| zyga-ubuntu | aaaah | 16:42 |
| zyga-ubuntu | so crazy | 16:42 |
| mvo | zyga-ubuntu: yes, I think I give up for today | 16:48 |
| mvo | zyga-ubuntu: well, almost, one more run | 16:48 |
| zyga-ubuntu | mvo: I'm working on something to finish this exercise of the day | 16:48 |
| zyga-ubuntu | but tomorrow I focus solely on symlink bug and on the writable leak bug | 16:48 |
| zyga-ubuntu | and nothing else | 16:48 |
| zyga-ubuntu | so :-) | 16:48 |
| zyga-ubuntu | unless you ask | 16:48 |
| mvo | zyga-ubuntu: ok, on the layouts bug, right? | 16:49 |
| pedronis | mvo: so there is still no good reproducer? | 16:49 |
| pedronis | did you ask for a way to use 2.31 as a baseline? | 16:49 |
| zyga-ubuntu | oh right, did that turn out anything? | 16:49 |
| mvo | pedronis: I thought I had one (and it all made sense): classic-firstboot installs the real core, that will generate a snap.core.xxx.usr.lib.snapd.snap-confine profile from the "real" core snap (which is out-of-sync with the profile from the branch). that gets loaded into the kernel. now the interfaces-broadcom-asic-control test runs, that runs snap-confine with the wrong profile and boom. except it exploded once and then did not explode even thou | 16:51 |
| mvo | gh the order is correct (i.e. first classic-firstboot test runs, then the interfaces test runs) | 16:51 |
| mvo | pedronis: 2.31 has no system-key yet so we always re-generate profiles there so its hidden there | 16:51 |
| pedronis | so it was 2.31 but a old edge? | 16:52 |
| zyga-ubuntu | mvo: I think we want the track/channel | 16:52 |
| zyga-ubuntu | and to put 2.31 there | 16:52 |
| zyga-ubuntu | and test against that | 16:52 |
| mvo | pedronis: yeah, when we had 2.31 on edge briefly things were really wrong | 16:52 |
| mvo | zyga-ubuntu: yeah, I think that is a good plan | 16:53 |
| pedronis | Chipaca: I did a pass on that branch, is not super easy to review | 17:22 |
| niemeyer | cachio: Any news on https://github.com/snapcore/snapd/pull/4778? | 17:22 |
| mup | PR #4778: tests: moving debian 9 from linode to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4778> | 17:22 |
| niemeyer | cachio: 11 days old, conflicts | 17:23 |
| Chipaca | pedronis: sorry... | 17:23 |
| Chipaca | pedronis: if it's any consolation mborzecki futzed it and it was a'ight | 17:23 |
| Chipaca | (then i broke it, and he futzed it again and found the breakage, so i unbroke it) | 17:23 |
| pedronis | Chipaca: it still feels a bit too fiddly | 17:24 |
| Chipaca | pedronis: but also, thank you for the pass | 17:24 |
| pedronis | Chipaca: I mean, I'm not looking forward about expanding this over more fields in the apis | 17:26 |
| Chipaca | pedronis: in what sense? | 17:26 |
| pedronis | do we need to use these things in other places? | 17:27 |
| pedronis | or is info the only source of things we print? | 17:27 |
| pedronis | it also feels like all the fields that are not freeform | 17:27 |
| pedronis | should have specific validators and not this | 17:28 |
| zyga-ubuntu | jjohansen: hey, I have a question about the kernel apparmor interface | 17:28 |
| Chipaca | pedronis: agreed on the latter; on the former I'm still not sure what you mean: currently it's checking everything that comes from the store that doesn't have its own type | 17:29 |
| Chipaca | pedronis: if you're asking whether we'd need to do this over the things we get from snap.yaml, I don't know | 17:29 |
| zyga-ubuntu | jjohansen: under what circumstances would /sys/kernel/security/apparmor/policy/profiles/$something/raw_{abi,data,sha1} be broken links? | 17:29 |
| zyga-ubuntu | I see that on my system and don't understand the cause | 17:29 |
| pedronis | Chipaca: no, we have other store apis | 17:30 |
| pedronis | do they need the same treatment? | 17:30 |
| pedronis | it's a bit strange why we do this to urls for example | 17:30 |
| Chipaca | pedronis: yes they'd need the same treatment (or equivalent) (and i just realised what you mean) | 17:31 |
| pedronis | I mean, this doesn't seem to scale to me | 17:31 |
| pedronis | we need to decide to use it a bit less | 17:31 |
| pedronis | or rethink how to make it scale | 17:31 |
| Chipaca | pedronis: how doesn't it scale? | 17:31 |
| pedronis | Chipaca: we need a checker that we don't use string in our json | 17:32 |
| pedronis | or something | 17:32 |
| Chipaca | ah | 17:32 |
| Chipaca | I can probably do that :-) | 17:32 |
| Chipaca | yes | 17:32 |
| pedronis | is that sane though? | 17:32 |
| pedronis | I understand the fix data on input | 17:32 |
| pedronis | but make all our json painful because we might print it | 17:33 |
| pedronis | is also strange | 17:33 |
| Chipaca | pedronis: I think the alternative would be perhaps to have our own json decoder, but I'm not sure that's a movement towards origin on the sanity line | 17:33 |
| Chipaca | pedronis: it seemed saner to clean everything than to answer, for each thing, 'is this going to be printed' | 17:34 |
| Chipaca | the latter seems a lot more bug-prone | 17:34 |
| fireclawTheFox | popey: do you maybe know if there's a way to automatically install snap-xdg-open with the snap or a way to not have to install it at all? | 17:35 |
| popey | What's the problem you want to solve? | 17:35 |
| pedronis | Chipaca: people have invented language level solutions for this kind of problems (tainting), so it's hard | 17:35 |
| fireclawTheFox | open a weblink from my application in a webbrowser | 17:37 |
| Chipaca | pedronis: I'm aware | 17:37 |
| pedronis | Chipaca: also afaiu, yes, we need the same for snap.yaml | 17:37 |
| Chipaca | pedronis: sigh | 17:37 |
| pedronis | Chipaca: I still think we might need to step back and rethink a bit the trade offs | 17:38 |
| fireclawTheFox | popey: currently doing this using subprocess.Popen(["xdg-open_", self.website]) as last time I tried webbrowser.open from python didn't work on snaps. | 17:39 |
| popey | xdg-open should work AIUI | 17:39 |
| pedronis | Chipaca: there are things that definitely don't come from the user | 17:39 |
| pedronis | sha3_384, the download urls for example | 17:40 |
| fireclawTheFox | yeah, xdg-open does work, but afaik only when the deb package snap-xdg-open is installed, right? | 17:41 |
| zyga-ubuntu | fireclawTheFox: no, this is long gone now | 17:41 |
| popey | i dont think that's needed anymore | 17:41 |
| zyga-ubuntu | fireclawTheFox: the whole setup is now part of snapd | 17:41 |
| fireclawTheFox | ah ok, didn't know that | 17:41 |
| pedronis | Chipaca: I mean, is there anything that is marked SimpleString that comes from the user? or doesn't have other validation? | 17:42 |
| Chipaca | pedronis: there shouldn't be | 17:42 |
| pedronis | Chipaca: do we need SimpleString? | 17:44 |
| jjohansen | zyga-ubuntu: uh it shouldn't ever be broken links | 17:44 |
| zyga-ubuntu | wanna see? :) | 17:44 |
| zyga-ubuntu | this is on artful | 17:44 |
| jjohansen | under newer kernels its moved to symlinks, but they shouldn't be broken | 17:44 |
| pedronis | Chipaca: anyway we can also start from the other end, what tooling we need to make sure we don't forget any string field? or we mark them somehow | 17:44 |
| zyga-ubuntu | https://usercontent.irccloud-cdn.com/file/oZ3RpjNO/Zrzut%20ekranu%202018-03-13%20o%2018.44.34.png | 17:44 |
| jjohansen | zyga-ubuntu: yes, if its broken it would be helpful to see how, so I can chase it down | 17:45 |
| Chipaca | pedronis: I don't know; what I understood from jdstrand was that I needed to check _everything_ | 17:45 |
| zyga-ubuntu | https://usercontent.irccloud-cdn.com/file/7ul07q75/Zrzut%20ekranu%202018-03-13%20o%2018.45.12.png | 17:45 |
| zyga-ubuntu | jjohansen: I'm not quite sure how I got to this state | 17:45 |
| zyga-ubuntu | this is on 4.13.0-36-generic | 17:45 |
| pedronis | Chipaca: I don't know if you checked everything, I'm also not if we checked everything tomorrow | 17:45 |
| zyga-ubuntu | jjohansen: I was just looking at my system | 17:45 |
| Chipaca | pedronis: this does not check everything yet, no | 17:46 |
| pedronis | Chipaca: I can add a string field, copy it, and nothing will fail | 17:46 |
| Chipaca | pedronis: you're right about needing a static checker if we're taking this route | 17:46 |
| zyga-ubuntu | jjohansen: I actually see plenty of broken links | 17:47 |
| zyga-ubuntu | jjohansen: if you have any snaps, can you do a quick check | 17:47 |
| zyga-ubuntu | jjohansen: maybe the way we remove loaded profiles is wrong | 17:47 |
| zyga-ubuntu | and something ends up staying behind | 17:47 |
| Chipaca | pedronis: but if I understand correctly, your position is that this route might be wrong | 17:47 |
| pedronis | Chipaca: it seems very fiddly and given that we need static checking, we might make lighter weight at that point | 17:48 |
| pedronis | Chipaca: is the fear only things that can be printed? | 17:48 |
| pedronis | or was the worry something else | 17:48 |
| pedronis | Chipaca: who is the attacker? | 17:48 |
| pedronis | there's a lot of things that comes in and we print | 17:49 |
| pedronis | there is also config | 17:49 |
| pedronis | stuff | 17:49 |
| jjohansen | zyga-ubuntu: no, there shouldn't be a way to remove profiles wrong, there is the potential for a race of sorts because the symlink doesn't have the same hard reference, but that isn't something you should be seeing | 17:49 |
| zyga-ubuntu | find /sys/kernel/security/apparmor/policy/profiles -type l -exec sh -c "file -b {} | grep -q ^broken" \; -print | 17:50 |
| Chipaca | pedronis: what sort of lighter weight thing could it be? | 17:50 |
| jjohansen | zyga-ubuntu: the raw_data file should not be going away as long as that profile directory exists | 17:50 |
| zyga-ubuntu | this reports a load of broken symlinks for me | 17:51 |
| pedronis | Chipaca: we could have a white list of things that are store produced | 17:51 |
| zyga-ubuntu | Chipaca: ^ can you run that and see if you get any output | 17:51 |
| zyga-ubuntu | (anyone with snaps on their system really) | 17:51 |
| jjohansen | so yeah there is a bug, I will have to hunt down | 17:51 |
| pedronis | like sha3_384 or the download urls | 17:51 |
| pedronis | and some other bits | 17:51 |
| Chipaca | zyga-ubuntu: no output | 17:51 |
| zyga-ubuntu | Chipaca: thank you | 17:51 |
| zyga-ubuntu | uptime? | 17:51 |
| zyga-ubuntu | for me I only see 3 hours | 17:51 |
| Chipaca | zyga-ubuntu: i can try on other boxes; on this one: | 17:51 |
| Chipaca | 17:52:01 up 20:36, 1 user, load average: 0.31, 0.24, 0.35 | 17:52 |
| zyga-ubuntu | thansk | 17:52 |
| zyga-ubuntu | mvo: ^ can you run the find command above | 17:52 |
| zyga-ubuntu | pedronis: ^ | 17:52 |
| Chipaca | hmm | 17:52 |
| Chipaca | zyga-ubuntu: i have a lot of output on my other box | 17:52 |
| zyga-ubuntu | (unless "broken" is localised) | 17:52 |
| zyga-ubuntu | !! thank you | 17:52 |
| ubottu | You're welcome! But keep in mind I'm just a bot ;-) | 17:52 |
| Chipaca | 17:52:29 up 2 days, 21:14, 3 users, load average: 0.18, 0.39, 0.27 | 17:52 |
| zyga-ubuntu | Chipaca: which kernel? | 17:52 |
| zyga-ubuntu | jjohansen: where can I report this | 17:52 |
| pedronis | nothing here | 17:52 |
| Chipaca | 4.13.0-36-generic on the one with lots of broken bts | 17:52 |
| Chipaca | 4.4.0-116-generic on the one without | 17:53 |
| zyga-ubuntu | ha | 17:53 |
| zyga-ubuntu | I have the same kernel as you then (the one with broken symlinks) | 17:53 |
| zyga-ubuntu | mvo: ^ a _maybe_ problem related to what we are seeing | 17:53 |
| pedronis | 4.4.0 | 17:53 |
| zyga-ubuntu | mborzecki, and you perhaps? | 17:54 |
| pedronis | Chipaca: I'm happy to have a HO on Thu | 17:54 |
| pedronis | if we really need to do this for everything we really need a tool | 17:54 |
| pedronis | of sorts | 17:54 |
| Chipaca | pedronis: to check, or to do? | 17:55 |
| Chipaca | i'd be fine with writing a checker, seems not that much work | 17:55 |
| pedronis | Chipaca: to check, but I would also understand if we really need SimpleString once we have a checker | 17:56 |
| pedronis | the exact attack worries are still a bit unclear to me | 17:57 |
| pedronis | s/also/also like/ | 17:57 |
| Chipaca | pedronis: AIUI it's about decoupling things; we need it on the editable ones, but if it were already on everything we wouldn't have to worry about it at all so why not do it | 17:57 |
| pedronis | if it had no costs that would make sense | 17:58 |
| pedronis | but is not cost free | 17:58 |
| Chipaca | pedronis: do you mean in complexity? | 17:58 |
| pedronis | yes | 17:59 |
| pedronis | also speed apparently | 17:59 |
| pedronis | you had to make it fast | 17:59 |
| pedronis | to apply it everywhere | 17:59 |
| Chipaca | yes, i worried about this impacting that, as these were potentially big fields | 18:00 |
| pedronis | anyway I should almost call it a day | 18:02 |
| pedronis | we should chat again on Thu | 18:02 |
| Chipaca | (but maybe less than you might think, as the more arcane bits of this are from a de-escaper for terminal stuff i'm working on elsewhere) | 18:02 |
| Chipaca | ok | 18:02 |
| Chipaca | pedronis: you're off tomorrow? | 18:02 |
| pedronis | yes | 18:02 |
| Chipaca | hmmm :-) | 18:02 |
| Chipaca | pedronis: enjoy | 18:02 |
| Chipaca | maybe I should too | 18:02 |
| Chipaca | mvo: you're taking friday off, right? | 18:02 |
| pedronis | Chipaca: it's a bit unclear to me why anything but description and summary needs the heavy handed approach | 18:04 |
| jjohansen | zyga-ubuntu: if you want to file a bug against apparmor or even the ubuntu kernel in launchpad, and subscribe me, that would be the best place atm | 18:04 |
| zyga-ubuntu | thank you, I'll file one against artful kernel then | 18:04 |
| zyga-ubuntu | jjohansen: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755563 | 18:12 |
| mup | Bug #1755563: dangling symlinks to loaded apparmor policy <amd64> <apport-bug> <artful> <linux (Ubuntu):New> <https://launchpad.net/bugs/1755563> | 18:12 |
| jjohansen | thanks | 18:12 |
| zyga-ubuntu | jjohansen: reproduced on bionic just now | 18:28 |
| zyga-ubuntu | jjohansen: I updated all the packages and got this (not snaps!) | 18:29 |
| zyga-ubuntu | /sys/kernel/security/apparmor/policy/profiles/libreoffice-senddoc.17/raw_data | 18:29 |
| zyga-ubuntu | I updated the bug report | 18:30 |
| jjohansen | thanks | 18:32 |
| zyga-ubuntu | I cannot reproduce this by simply installing the deb again, tried downgrading and upgrading, nothing | 18:41 |
| mup | Bug #1755568 opened: Snaps are refreshed on metered connection <Snappy:New> <https://launchpad.net/bugs/1755568> | 18:47 |
| Chipaca | zyga-ubuntu: fwiw the one where i repro this is xenial | 18:57 |
| zyga-ubuntu | excellent | 18:57 |
| zyga-ubuntu | I updated the bug | 18:58 |
| zyga-ubuntu | jjohansen: it affects all supported kernels | 18:58 |
| mup | PR snapd#4810 closed: osutil: DropPrivs morphs an *exec.Cmd to drop privileges <Created by chipaca> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4810> | 19:11 |
| Chipaca | heh | 19:11 |
| Chipaca | that's not what i call 'tentative' :-) | 19:11 |
| Chipaca | niemeyer: the driver for that PR is superseded by the hash cache, so, eh | 19:12 |
| * Chipaca -> eol | 19:12 | |
| niemeyer | It's tentative, in that there's a "reopen" button.. | 19:13 |
| niemeyer | Dear hit-and-run chipaca.. | 19:13 |
| mup | PR snapd#4831 opened: tests: force profile re-generation via system-key <Created by mvo5> <https://github.com/snapcore/snapd/pull/4831> | 19:24 |
| mvo | ^- *might* be enough to workaround the profile issue | 19:25 |
| mup | PR snapd#4832 opened: tests: move fedora 27 to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832> | 19:48 |
| niemeyer | mvo: Nice | 19:54 |
| mvo | niemeyer: well, I was wrong for this particular bug before, so I will hold my breath until the tests pass :) | 19:55 |
| Chipaca | niemeyer: i didn't mean to hit-n-run! sorry | 20:05 |
| Chipaca | i mean, i didn't mean it as a hit | 20:05 |
| Chipaca | i definitely meant to run, because, dinner | 20:05 |
| mup | PR snapd#4833 opened: tests: add a detector for kernel bug https://pad.lv/1755563 <Created by zyga> <https://github.com/snapcore/snapd/pull/4833> | 20:06 |
| Chipaca | niemeyer: but the order in which i saw things was: your comment about "tentative -1", then mup said "closed" -- I didn't get to see the 'tentatively closing' comment until just now | 20:06 |
| Chipaca | so it was funny | 20:06 |
| Chipaca | (but also i agreed, because the driver for the pr was gone) | 20:07 |
| * Chipaca handwaves more | 20:07 | |
| niemeyer | Chipaca: No worries :) | 20:09 |
| niemeyer | Chipaca: Hope dinner was good | 20:09 |
| Chipaca | niemeyer: I am learning to make my mum's cheese roll | 20:12 |
| Chipaca | niemeyer: hell yeah it was good :-D | 20:12 |
| niemeyer | Wow.. I'm instantly hungry now :) | 20:12 |
| Chipaca | still things to tweak but getting better | 20:12 |
| mvo | Chipaca: to answer your earlier question - yes | 20:13 |
| Chipaca | wooooo | 20:13 |
| * mvo hugs Chipaca | 20:13 | |
| Chipaca | mvo: wait, was that the "can i have a million euros" quesiton | 20:13 |
| Chipaca | mvo: or was it the "are you taking friday off" question | 20:13 |
| Chipaca | mvo: either way "woo!", but I need to prepare differently | 20:14 |
| Chipaca | with one of them there's going to be a massive party | 20:14 |
| Chipaca | with the other, i need a financial advisor | 20:14 |
| zyga-ubuntu | does https://amdflaws.com/ mean we will not see the security team for the next few weeks? | 20:15 |
| zyga-ubuntu | or was jdstrand going on holidays just a kind way to say he's busy ;-) | 20:17 |
| mup | PR snapcraft#2002 opened: pluginhandler: add builtin functions to scriptlets <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2002> | 20:18 |
| Chipaca | nice that in writing code I find other code that was tested improperly and wasn't actually testing the thing and we weren't actually doing the thing we were testing for | 20:23 |
| Chipaca | /o\ | 20:23 |
| niemeyer | mvo: Quickie if you're still around: is #4814 still relevant given #4831? | 20:26 |
| mup | PR #4814: tests: fix re-exec profile generation in tests on classic (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4814> | 20:26 |
| mup | PR #4831: tests: force profile re-generation via system-key <Created by mvo5> <https://github.com/snapcore/snapd/pull/4831> | 20:26 |
| zyga-ubuntu | jjohansen: https://api.travis-ci.org/v3/job/353025489/log.txt and look for "kernel bug detected" | 20:34 |
| zyga-ubuntu | it looks like a race to me | 20:35 |
| jjohansen | zyga-ubuntu: hrmmm, okay I believe you, not that I didn't hours ago ;-) | 20:37 |
| zyga-ubuntu | jjohansen: is there anything I can provide that would help you? | 20:38 |
| jjohansen | zyga-ubuntu: not atm, but maybe some testing when I get a patch togeth | 20:38 |
| jjohansen | together | 20:38 |
| cachio | Pharaoh_Atem, hey | 20:42 |
| cachio | almost ready fedora 27 | 20:42 |
| cachio | I just see errors on snaps connecting with dbud | 20:42 |
| cachio | Pharaoh_Atem, any idea how to allow snaps connect through dbus? | 20:43 |
| cachio | Pharaoh_Atem, this is an example https://api.travis-ci.org/v3/job/353017992/log.txt | 20:43 |
| cachio | Pharaoh_Atem, the PR related is https://github.com/snapcore/snapd/pull/4832 | 20:44 |
| mup | PR #4832: tests: move fedora 27 to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832> | 20:44 |
| Pharaoh_Atem | cachio: dbus between snaps should already be allowed | 20:47 |
| Pharaoh_Atem | ah | 20:47 |
| Pharaoh_Atem | we only allow dbus comms with polkit | 20:47 |
| cachio | Pharaoh_Atem, I tested it and selinux is blocking that | 20:47 |
| Pharaoh_Atem | so we probably need a policy update to allow snaps to communicate with each other | 20:48 |
| Pharaoh_Atem | though I'm not exactly sure how to do that... | 20:48 |
| cachio | what I see is that is not aloowed niether connection between snaps nor using dbus-send | 20:49 |
| Pharaoh_Atem | cachio: are you able to give me access to the machine that has the denials happening? | 20:49 |
| cachio | I need to trigger again the test, it will take 10 minutes | 20:49 |
| cachio | Pharaoh_Atem, tests triggered | 20:50 |
| Chipaca | slangasek: ping | 21:03 |
| slangasek | Chipaca: hi there | 21:03 |
| Chipaca | slangasek: hiya | 21:03 |
| Pharaoh_Atem | cachio: okay ;) | 21:04 |
| mup | PR snapd#4834 opened: snap/squashfs: when installing from seed, try symlink before cp <Created by chipaca> <https://github.com/snapcore/snapd/pull/4834> | 21:04 |
| Chipaca | slangasek: so today in the standup we came up with a better plan | 21:04 |
| Chipaca | slangasek: ^ that pr is the first (and probably more important) half of it :-D | 21:04 |
| Chipaca | slangasek: (this is about first boot from livecd being slow) | 21:04 |
| Chipaca | slangasek: second half is doing the hash check only once, which will speed things up; that'll be a bit more code, but the whole thing ended up being a lot more straightforward than we feared | 21:05 |
| slangasek | ah, symlink, not hardlink? | 21:05 |
| Chipaca | slangasek: yup | 21:06 |
| slangasek | seems more portable from my side, if it meets all your requirements on the snapd side | 21:06 |
| Chipaca | slangasek: we don't typically do that because we don't control the source (this codepath is used when sideloading for ex), but in the seed case we do | 21:06 |
| Chipaca | slangasek: yep, much happier with it | 21:06 |
| slangasek | Chipaca: excellent. will we need any changes on the image mastering side to integrate this? | 21:07 |
| slangasek | or will it be transparent to us? | 21:07 |
| Chipaca | slangasek: it should be entirely transparent | 21:07 |
| slangasek | wfm | 21:08 |
| Chipaca | niemeyer: ping | 21:16 |
| mup | PR snapcraft#2000 closed: elf: remove dead code <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2000> | 21:28 |
| Chipaca | niemeyer: before I forget: the ping was about going over a rewrite of the login help with you before pushing it | 21:33 |
| Chipaca | niemeyer: also ping about quoting :-) | 21:35 |
| mup | PR snapd#4814 closed: tests: fix re-exec profile generation in tests on classic (2.32) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4814> | 21:56 |
| mvo | Chipaca: thanks for the PR! | 21:57 |
| mvo | niemeyer: I closed 4814 and will close all related ones, 4831 is hopefully enough | 21:58 |
| mup | PR snapd#4824 closed: tests: fix re-exec profile generation in tests on classic <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4824> | 21:58 |
| mup | PR snapd#4822 closed: interfaces/apparmor: skip apparmor cache <Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4822> | 22:00 |
| mup | PR snapd#4823 closed: interfaces/apparmor: skip apparmor cache (2.32) <Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4823> | 22:00 |
| mup | PR snapd#4827 closed: cmd/snap-apparmor-parser: add a prototype apparmor parser <Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4827> | 22:00 |
| * mvo <- bed | 22:03 | |
| Chipaca | niemeyer: also question: is it ok to talk about 'tracking channel' and 'channel tip' in user docs | 22:37 |
| niemeyer | Chipaca: Yo | 22:38 |
| Chipaca | niemeyer: hi | 22:38 |
| Chipaca | niemeyer: taking the opportunity to improve the docs for find, install and refresh, via changing the help for login | 22:38 |
| Chipaca | niemeyer: but some of these things are hard to explain :-) | 22:38 |
| niemeyer | Chipaca: Tracking channel sounds fine, although there's a minor conflict with the term "channel track" which is slightly sad but okayish | 22:39 |
| niemeyer | Chipaca: Channel tip feels too developer-oriented | 22:39 |
| Chipaca | niemeyer: https://pastebin.ubuntu.com/p/D758SWrydd/ | 22:39 |
| niemeyer | Chipaca: Expanding it to "current revision in the channel" feels more clear to someone that doesn't have as much baggage, I guess | 22:40 |
| niemeyer | Chipaca: Reading... | 22:40 |
| Chipaca | yeah, s/tip/current revision/ works | 22:40 |
| Chipaca | niemeyer: this comes about because I tweaked the 'login' help: https://pastebin.ubuntu.com/p/BQGfmJQxXw/ | 22:42 |
| niemeyer | Chipaca: The --beta/etc references doesn't seem necessary there.. --channel is generally more interesting to teach after we introduced tracks and branches as it's the general form that works across all cases | 22:42 |
| Chipaca | niemeyer: so then i had to change the 'find' help: https://pastebin.ubuntu.com/p/YKWRbmrnNt/ :-) | 22:42 |
| Chipaca | niemeyer: yeah, was in the middle of dropping that | 22:43 |
| Chipaca | as in the help output it can be obvious | 22:43 |
| nacc | Chipaca: "has access to" | 22:43 |
| * Chipaca adds a 'to' to 'has access' | 22:43 | |
| Chipaca | heh | 22:43 |
| nacc | :) | 22:43 |
| niemeyer | Chipaca: Mentioning --revision is nice since it's a bit of an edge case, but I think we could do a trick there by mentioning the constraint before mentioning the option, so that people don't stop reading in excitement mid-way through | 22:44 |
| niemeyer | E.g. | 22:44 |
| Chipaca | hmm, interesting, that might make refresh read easier too | 22:44 |
| niemeyer | For revisions that are currently installed in the local system and for personal snaps, --revision will blah blah blah... | 22:44 |
| niemeyer | Or similar | 22:45 |
| Chipaca | ok, will tinker a bit more, then push and call it a night | 22:45 |
| niemeyer | Chipaca: That last sentence is a bit cryptic.. I mean, I get what you mean, but I suspect most people won't | 22:46 |
| Chipaca | niemeyer: the one about security options? | 22:46 |
| niemeyer | Yeah | 22:46 |
| niemeyer | I suggest just dropping it and letting the error messages play their role.. | 22:47 |
| Chipaca | niemeyer: perhaps. I'll try to make it obvious in context (ie when the options are spelled out below) | 22:47 |
| Chipaca | that's fair | 22:47 |
| Chipaca | i mean, it's what we do today :-) | 22:47 |
| niemeyer | Yeah :) | 22:47 |
| Chipaca | i could drop the whole 'only one at a time' thing in fact | 22:47 |
| Chipaca | it's very discoverable and fast | 22:47 |
| * Chipaca tinkers | 22:48 | |
| Chipaca | niemeyer: ah, one more thing | 23:04 |
| Chipaca | niemeyer: i had a hard time understanding your comment about 'temporarely', and i don't know if you were making a joke or not :-) | 23:04 |
| niemeyer | Chipaca: haha | 23:07 |
| niemeyer | Chipaca: Yeah, it was a joke :P | 23:07 |
| Chipaca | phew :) | 23:07 |
| niemeyer | That's such a great typo, though | 23:07 |
| niemeyer | Is there a place we can submit candidate words? | 23:07 |
| Chipaca | niemeyer: you'll need a wig and a posh accent | 23:08 |
| Chipaca | niice | 23:10 |
| Chipaca | https://forum.snapcraft.io/t/explain-permissions-better-or-people-will-freak-out/4456 | 23:10 |
| Chipaca | I didn't know we had that in place already :-) | 23:10 |
| Chipaca | robert_ancell: that you ^? | 23:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
