| zyga | hello | 05:47 |
|---|---|---|
| mborzecki | morning | 06:01 |
| zyga | hey | 06:21 |
| zyga | mborzecki: quick qustion, does the aur packaging limit architectures? | 06:21 |
| zyga | mborzecki: someone is asking for snapd on manjaro on aarch64 | 06:21 |
| mborzecki | zyga: yes and no, iirc the general consensus was that you put x86_64 there and then people building the package on other arches can edit PKGBUILD to their liking | 06:22 |
| mborzecki | also aur helpers usually allow to ignore the arch and build with whatever the local one is | 06:22 |
| mborzecki | i've added i386 for some arch-on-x86 project poeple asked about | 06:22 |
| mborzecki | i can add aarch64 too | 06:23 |
| zyga | mborzecki: uh, that's odd, why do you have to put x86_64? | 06:24 |
| zyga | mborzecki: yeah, let's add aarch64 and just call it a day (on that issue) | 06:24 |
| mborzecki | haha i see the forum topic now | 06:25 |
| mborzecki | so poeple can close and call makepkg -i but don't bother to read the manpage :P | 06:25 |
| zyga | "snap install things quickly" :) | 06:29 |
| mborzecki | zyga: i'm seeing 434 syscalls known to libseccomp in the current master branch | 07:10 |
| zyga | mborzecki: how are you measuring? | 07:10 |
| mborzecki | zyga: there's arch-syscall-dump tool in the source code that dumps the known syscalls for that arch | 07:11 |
| zyga | ah, nice | 07:11 |
| mborzecki | zyga: this is combined for all arches: https://paste.ubuntu.com/p/3vDk88tFZf/ | 07:11 |
| zyga | brb,dog.walk() | 07:32 |
| zyga | re | 07:44 |
| zyga | hello mvo | 07:44 |
| mvo | hey zyga ! good morning | 07:45 |
| zyga | welcome back :) | 07:45 |
| zyga | how was your week off? | 07:45 |
| mvo | zyga: it was very nice | 07:46 |
| mvo | zyga: thank you | 07:46 |
| mvo | zyga: what did I miss? | 07:46 |
| zyga | mvo: let me think | 07:47 |
| zyga | mvo: I think last week was mostly quiet | 07:48 |
| zyga | mvo: for me some things that are important are 2.13 apparmor - we need to urgently release with support for it | 07:48 |
| mvo | zyga: in what distros is it used? and what changes for us? | 07:48 |
| zyga | mvo: I also raised the topic of snapd LTS but pedronis asked to move the discussion to this week, once you are back | 07:48 |
| zyga | mvo: it's going in everywhere, opensuse, debian and ubuntu as well | 07:48 |
| zyga | mvo: there's a PR from jdstrand | 07:49 |
| zyga | mvo: I proposed that 2.37 become the first LTS branch that just gets bug fixes and is periodically released again | 07:49 |
| zyga | and that we have tracks with that version | 07:49 |
| zyga | mvo: apart from that, we have ongoing beta validation | 07:50 |
| zyga | mvo: and I think that's it, lots of reviews to do | 07:50 |
| mvo | zyga: thanks | 07:50 |
| mvo | zyga: anything holding back beta validation? I mean, any issue that prevent the move to candidate? | 07:51 |
| zyga | mvo: I don't recall any details, sorry | 07:51 |
| mvo | zyga: ta, I will chase it | 07:55 |
| mborzecki | mvo: hey | 07:59 |
| pstolowski | morning | 08:01 |
| mvo | good morning mborzecki and pstolowski ! | 08:03 |
| Chipaca | moin moin | 08:18 |
| Chipaca | ooh, new git | 08:18 |
| * Chipaca accepts the gift of the apt gods | 08:18 | |
| * zyga reviews https://github.com/snapcore/snapd/pull/6079 | 08:24 | |
| mup | PR #6079: cmd/snap: `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079> | 08:24 |
| mborzecki | zyga: thanks! | 08:25 |
| mborzecki | zyga: https://paste.ubuntu.com/p/cJ2v9hfJhH/ snap-seccomp version is added at the very beginning | 08:27 |
| mborzecki | it's the library version followed by the hash of the supported syscall names | 08:28 |
| zyga | mborzecki: looks great, | 08:36 |
| zyga | mborzecki: would you mind moving the hash to the 2nd line and saying what it is | 08:36 |
| mborzecki | zyga: mhm, and the changes aren't that huge either | 08:36 |
| zyga | mborzecki: "# hash of sorted list of supported system calls | 08:36 |
| * zyga is slow today, both wife and older daughter have fever :/ | 08:36 | |
| zyga | mborzecki: bonus points for naming the hash algo | 08:38 |
| wgrant | mvo: Morning, welcome back. | 08:43 |
| wgrant | mvo: Any idea on the current situation with backporting the catalog randomisation? | 08:43 |
| mvo | wgrant: its in beta and we uploaded the SRU last week, afaict no SRU reviewer has looked at it yet, I will poke people about it today | 08:44 |
| wgrant | mvo: Does that include xenial/bionic-security? | 08:47 |
| mup | PR snapd#6558 opened: many: remove unused code (mostly) <Created by chipaca> <https://github.com/snapcore/snapd/pull/6558> | 08:52 |
| pedronis | mvo: hi, welcome back, hope the week (mostly) off was restful | 08:57 |
| === alan_g_ is now known as alan_g | ||
| pedronis | Chipaca: hi, #6545 should be mergeable if you are ok with the tweaks I pushed there | 08:58 |
| mup | PR #6545: cmd/snap, daemon: make the connectivity check use GET <Created by chipaca> <https://github.com/snapcore/snapd/pull/6545> | 08:58 |
| smallville7123 | What's the difference between kotlin and kotlin/native | 08:58 |
| smallville7123 | What's the difference between kotlin and kotlin-native* | 08:58 |
| smallville7123 | For example, "Kotlin/Native compiler" and "Command line Kotlin compiler" | 09:02 |
| smallville7123 | kotlin-native 0.9.3 jetbrains classic Kotlin/Native compiler | 09:04 |
| smallville7123 | kotlin 1.3.21 jetbrains classic Command line Kotlin compiler | 09:04 |
| Chipaca | smallville7123: read the description of both? | 09:06 |
| smallville7123 | Where do i find thay | 09:06 |
| smallville7123 | That | 09:06 |
| Chipaca | smallville7123: snap info kotlin kotlin-native (snap info kot-alt-*) | 09:07 |
| smallville7123 | Statically typed programming language for modern multiplatform applications | 09:09 |
| smallville7123 | Yet its summery is summary: Command line Kotlin compiler | 09:09 |
| smallville7123 | So which is it -_- | 09:09 |
| Chipaca | pedronis: you introduced a double-lock on state, there | 09:10 |
| Chipaca | unless i missed something | 09:10 |
| Chipaca | nope | 09:10 |
| Chipaca | smallville7123: read the description? the summary was already in the output of 'snap find' | 09:11 |
| smallville7123 | Also why are there two if both are to be the same | 09:11 |
| smallville7123 | What does one provide that the other doesnt | 09:12 |
| Chipaca | smallville7123: the information is there if you read it. And ultimately, even if it weren't, ask jetbrains; how should *we* know? | 09:12 |
| smallville7123 | Cus YOU package and provide them | 09:13 |
| pedronis | Chipaca: ? | 09:13 |
| Chipaca | smallville7123: we do not package it, jetbrains does | 09:13 |
| Chipaca | pedronis: in the POST route | 09:13 |
| pedronis | Chipaca: are we missing a test? | 09:13 |
| Chipaca | pedronis: the state you pass to checkConnectivity is locked | 09:13 |
| smallville7123 | -_- | 09:14 |
| pedronis | Chipaca: checkConnectivity and unlocks and relocks | 09:14 |
| pedronis | not locks and unlocks | 09:14 |
| Chipaca | pedronis: hah. my bad. | 09:14 |
| mup | PR snapd#6545 closed: cmd/snap, daemon: make the connectivity check use GET <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6545> | 09:16 |
| Chipaca | pedronis: any conclusion on blob vs snapfile vs ...? | 09:20 |
| Chipaca | pedronis: wrt #6532 | 09:20 |
| mup | PR #6532: daemon: allow downloading snaps blobs via .../blobs <Created by chipaca> <https://github.com/snapcore/snapd/pull/6532> | 09:20 |
| mup | PR snapd#6162 closed: interfaces/greengrass_support: update accesses for GGC 1.8 <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6162> | 09:23 |
| pedronis | Chipaca: no, was focused on 2.38 things | 09:23 |
| === cpaelzer__ is now known as cpaelzer | ||
| pedronis | Chipaca: could you re-review #6079 ? | 09:24 |
| mup | PR #6079: cmd/snap: `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079> | 09:24 |
| Chipaca | mborzecki: 6556 is included in 6079? | 09:26 |
| mborzecki | Chipaca: no, i've reverted that patch from 6079 | 09:27 |
| mborzecki | Chipaca: iirc the plan is snap conenctions for 2.38, then deprecation & hide interfaces in .39 | 09:28 |
| Chipaca | ok | 09:28 |
| Chipaca | i need to step out for a bit, i'll review when i return | 09:29 |
| zyga | mvo: one more thing, more core18 / core discovery, one more unhandled problem | 09:31 |
| zyga | sorry, forgot to mention | 09:31 |
| zyga | but we can chat again when you have time | 09:31 |
| zyga | pedronis: on 2nd thought I think snap-confine *does* know the boot base on core | 09:37 |
| zyga | pedronis: we parse os-release and differentiate classic, core18, core-other | 09:37 |
| pedronis | zyga: does it use the info though? | 09:37 |
| zyga | pedronis: yes | 09:37 |
| zyga | and specifically for this choice too | 09:37 |
| zyga | I will double check and see if we have any tests | 09:37 |
| zyga | but it may be less terrible than we thought last week | 09:38 |
| mvo | zyga: lets talk in ~45min again then my head should be a bit less busy | 09:43 |
| pedronis | zyga: yes, I see the relevant code now, it's quite spread out | 09:44 |
| zyga | pedronis: because of ns hops | 09:45 |
| pedronis | hops? | 09:45 |
| zyga | pedronis: we look and remember and then use the fact much later | 09:45 |
| zyga | but yeah | 09:45 |
| zyga | joining various namespaces | 09:45 |
| pedronis | there's a helper sc_should_use_normal_mode(distro, base_snap_name) | 09:46 |
| pedronis | it's used exactly twice | 09:46 |
| zyga | yeah, and distro is probed early | 09:46 |
| Chipaca | mborzecki: +1 to 6079 | 09:49 |
| Chipaca | mborzecki: thank you | 09:49 |
| mborzecki | Chipaca: thanks for the review! | 09:49 |
| mborzecki | will be out for a while, left a note in the forum | 10:02 |
| Chipaca | ok, _now_ i'm stepping out for a bit | 10:05 |
| * dot-tobias waves | 10:14 | |
| mup | PR snapd#6558 closed: many: remove unused code (mostly) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6558> | 10:25 |
| pedronis | mvo: you should look at #6549 (there's a question there about when to cover the snapd snap), and also re-review #6322 | 10:37 |
| mup | PR #6549: apparmor: support AppArmor 2.13 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6549> | 10:37 |
| mup | PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6322> | 10:37 |
| mup | PR snapd#6559 opened: pkg/apparmor: scratch documentation of apparmor <Created by zyga> <https://github.com/snapcore/snapd/pull/6559> | 11:05 |
| pstolowski | pedronis: hey, does this https://pastebin.ubuntu.com/p/tF3X8RV6t9/ more less match the idea re flattening? this is a dump of state with 5 timings, for each timing there are 3 nested timings, flattened per-timing | 11:30 |
| pedronis | pstolowski: yes | 11:36 |
| pedronis | assuming it works as I would expect | 11:36 |
| pstolowski | pedronis: i'll show you an example in a moment | 11:36 |
| pedronis | pstolowski: I mean what happens if there is more than one 1 etc | 11:37 |
| pedronis | zyga: it's a bit unclear which of/whether your last comments on #6549 should block it | 11:38 |
| mup | PR #6549: apparmor: support AppArmor 2.13 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6549> | 11:38 |
| zyga | pedronis: I don't want to block it yet, it mainly depends on the reaction to my small RFC branch | 11:39 |
| pedronis | zyga: we are trying to do 2.38 today or tomorrow | 11:40 |
| zyga | pedronis: I see | 11:40 |
| zyga | pedronis: I'm happy with 2.38 having this code if you don't object | 11:40 |
| zyga | and growing something easier to follow in master | 11:41 |
| pedronis | ok | 11:41 |
| pedronis | we still need to understand what to do about the snapd snap case | 11:41 |
| pstolowski | pedronis: then you have this: https://pastebin.ubuntu.com/p/Bp9gGj7gvz/ (see the first and last nested measurement of each timing) | 11:42 |
| pedronis | pstolowski: yes, that's what I would expect | 11:42 |
| pstolowski | pedronis: ok, good | 11:42 |
| pstolowski | pedronis: and this is how it's used https://pastebin.ubuntu.com/p/5hgwQqHckt/ | 11:50 |
| pedronis | pstolowski: thx, looks reasonable | 11:52 |
| mvo | pstolowski: nice stuff! | 11:55 |
| * mvo is very excited about this feature | 11:55 | |
| mup | PR snapd#6557 closed: tests/main/high-user-handling: fix the test for Go 1.12 (2.37) <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6557> | 11:56 |
| mup | PR snapd#6543 closed: Add force_turbo to the list valid pi config keys <Created by sergey-borovkov> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6543> | 11:57 |
| mborzecki | re | 11:59 |
| pstolowski | pedronis, mvo thanks for quick feedback, in that case i'll polish it a bit and propose a base PR | 12:06 |
| mvo | pstolowski: sounds great | 12:07 |
| Chipaca | we should split spread tests into "distros that often break because of mirrors and other related bull" and "real distros :-p", and use travis's can-fail flag for the former | 12:09 |
| Chipaca | allow_failures i mean | 12:10 |
| === ricab is now known as ricab|lunch | ||
| pedronis | mvo: it seems I created confusion with my comment about Active | 12:46 |
| * zyga takes the dog out | 13:01 | |
| zyga | mvo: I pushed an update to https://github.com/snapcore/snapd/pull/6498 | 13:01 |
| mup | PR #6498: cmd/libsnap: add cgroup-pids-support module <Created by zyga> <https://github.com/snapcore/snapd/pull/6498> | 13:01 |
| === mborzeck1 is now known as mborzecki | ||
| mborzecki | damn, sudden power loss :/ | 13:11 |
| Chipaca | I remember having to have an UPS for my router :-) | 13:12 |
| Chipaca | mborzecki: thank you for pointing out the changing of publisher across revisions btw | 13:13 |
| mborzecki | Chipaca: np | 13:14 |
| Chipaca | it would've been a regression | 13:14 |
| mborzecki | Chipaca: my router & nas are under a ups already, but the desktop isnt :P | 13:14 |
| Chipaca | I've got these nifty computers with an integrated UPS | 13:14 |
| mborzecki | call 'em laptops? | 13:14 |
| Chipaca | :-D | 13:15 |
| ijohnson | hey folks if I wanted to see which commit of snapd the edge channel of the core snap was built from, is this doable? i.e. I currently have 2.37.4+git1173.2c7e249~ubuntu16.04.1 but 2c7e249 doesn't seem to be a commit in snapd | 13:29 |
| pedronis | ijohnson: there is some indirection, it is built from here: https://git.launchpad.net/snapd-vendor/commit/?id=2c7e24947044fd67c166871d81374dcee76b135c | 13:41 |
| ijohnson | ah I see, so then that repo builds into the PPA here https://code.launchpad.net/~snappy-dev/+archive/ubuntu/edge which is then what goes into this: https://code.launchpad.net/~snappy-dev/+snap/core which is the core snap released, correct? | 13:45 |
| === ricab|lunch is now known as ricab | ||
| mvo | zyga: thank you for the update to 6498 | 13:58 |
| lborda | Question: I have two snaps and I need them to talk each other via redirection to sterr and stout (using example juju status > file.log ) from another classic snap. Currently I get apparmor errors (DENIED) is there a slot, plug or interface I should use to make them accept the syscall ? | 14:19 |
| lborda | looks like I got some help here: https://github.com/lborda/snap-bug/issues/1 will give it a try | 14:21 |
| lborda | sergiusens, ^ ty | 14:21 |
| jdstrand | lborda: the denial says you are doing something different than what you describe. perhaps use a pipe of /dev/stderr /dev/stdout? | 14:35 |
| jdstrand | err | 14:36 |
| jdstrand | pipe or* /dev/stderr and /dev/stdout? | 14:36 |
| lborda | jdstrand, to explain exactly what I am doing is: I am running snap-bug which call popen(juju status) and using juju status > log.file from it... should I not be using that ? see the reproducer there... I am using popen for that... https://github.com/lborda/snap-bug/blob/master/collect.py | 14:38 |
| jdstrand | yes, that is what I figured. the problem isn't the snaps, but snap-confine. they may be two classic snaps that are effectively unconfined, but they are going through a strictly confined snap-confine | 14:40 |
| jdstrand | (when you call the second snap) | 14:40 |
| jdstrand | snap-confine doesn't have access to log.file, as can be seen from the denial | 14:41 |
| jdstrand | and it needs it due to fd inheritence | 14:41 |
| mborzecki | jdstrand: hi, when you have some time, could you take a look at https://github.com/snapcore/snapd/pull/6485 ? | 14:47 |
| mup | PR #6485: interfaces/seccomp: regenerate changed profiles only <â›” Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485> | 14:47 |
| jdstrand | lborda: instead of specifying stdout and stderr as files, perhaps use Popen.communicate to get the output, then write that out yourself | 14:48 |
| jdstrand | there are probably other ways to fix it | 14:49 |
| jdstrand | mborzecki: ack | 14:49 |
| mborzecki | jdstrand: thanks! | 14:49 |
| lborda | jdstrand, I can give it a try. looks like a workaround... is this bug related to my issue ? https://bugs.launchpad.net/snapd/+bug/1815869 | 14:58 |
| mup | Bug #1815869: Command of classic snap fails with denial when output is redirected <snapd:Fix Released by zyga> <https://launchpad.net/bugs/1815869> | 14:58 |
| jdstrand | lborda: the underlying issue (fd inheritence with apparmor) is the same, but that is a different issue | 15:02 |
| jdstrand | lborda: this has some detail: https://forum.snapcraft.io/t/snapd-2-32-breaks-live-server-installer/4597/10 | 15:04 |
| jdstrand | lborda: but put more siccinctly, it is a limitation that should improve with time | 15:05 |
| jdstrand | succinctly* | 15:05 |
| lborda | jdstrand, yes agree different issue same underlying issue... | 15:07 |
| lborda | jdstrand, agree well let me do some attempts here... I am working on getting cdk and juju log output so we can gather logs for later troubleshooting... having access to the $USER env is a must | 15:08 |
| jdstrand | lborda: the individual snaps have that. snap-confine does not. it is the way you are gathering the output that is causing snap-confine to become entangled. snap-confine has access to /dev/stdout and /dev/stderr, so if you can adjsut your calls to use those, you should be fine | 15:10 |
| jdstrand | which communicate() should do (untested) | 15:10 |
| lborda | jdstrand, yes looks like it! :) give me a few to make changes here | 15:10 |
| sborovkov | hi, is there any apparmor stuff still working when snap is installed in devmode? | 15:14 |
| sborovkov | after I upgraded Qt to the latest version in my snap, I can't get qt webkit running for whatever reason, even though it's still at the same version and only qt's version went up (and all other libraries it comes with) | 15:15 |
| sborovkov | it works fine on the raspbian with 0 issues | 15:15 |
| sborovkov | does not start even in devmode on the core | 15:15 |
| zyga | re | 15:20 |
| zyga | mvo: thank you :) | 15:20 |
| zyga | jdstrand: hello :-) | 15:21 |
| zyga | jdstrand: I sent a small patch to snap-confine, your review is required https://github.com/snapcore/snapd/pull/6498 | 15:30 |
| mup | PR #6498: cmd/libsnap: add cgroup-pids-support module <Created by zyga> <https://github.com/snapcore/snapd/pull/6498> | 15:30 |
| mup | PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6079, snapd#6098, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6356, snapd#6360, snapd#6367, snapd#6381, snapd#6401, snapd#6404, | 15:30 |
| mup | snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6492, snapd#6498, snapd#6502, snapd#6532, snapd#6539, snapd#6541, snapd#6549, snapd#6553, snapd#6556, snapd#6559 | 15:30 |
| mup | PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6079, snapd#6098, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6356, snapd#6360, snapd#6367, snapd#6381, snapd#6401, snapd#6404, | 15:31 |
| mup | snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6492, snapd#6498, snapd#6502, snapd#6532, snapd#6539, snapd#6541, snapd#6549, snapd#6553, snapd#6556, snapd#6559 | 15:31 |
| Chipaca | sborovkov: in devmode, apparmor is set to allow everything but log | 15:36 |
| Chipaca | sborovkov: seccomp, also | 15:37 |
| sborovkov | Chipaca, so basically nothing is forbidden? the only messages I see bbefore it crashes is that it can't create some kind of udev monitor and send some dbus commands to NetworkManager which is followed by "could not create AF_NETLINK socket" and a crash of process | 15:47 |
| Chipaca | sborovkov: nothing is forbidden by apparmor / seccomp, but the view of the system remains the same as in strict | 15:48 |
| sborovkov | I guess the cause should be somewhere in there then :( | 15:49 |
| Chipaca | sborovkov: don't you get anything in the system logs? | 15:51 |
| sborovkov | all I see are those errors, I pasted above, it crashes right after bbeing unable to create AF_NETLINK socket | 15:52 |
| sborovkov | I thought it'd work in the devmode at least but that's not the case | 15:52 |
| sborovkov | I guess I will try to get that process running in gdb. | 15:53 |
| Chipaca | sborovkov: snap run --gdb ? | 15:55 |
| sborovkov | I did not even know that was a thing now :) | 15:56 |
| Chipaca | sborovkov: also 'snap run --strace' :-) | 15:57 |
| Chipaca | and trace-exec … | 15:57 |
| Chipaca | it's getting all fancy and grown-up | 15:57 |
| sborovkov | that's pretty cool, not sure it's going to work for me though - my main process is not crashing | 15:58 |
| sborovkov | webb process does | 15:58 |
| sborovkov | and I have done bind mount of the directory containing modified snap so gdb spews out some errors because of that I guess | 15:59 |
| zyga | popey: hey, sublime-text doesn't work on 18.10 | 16:41 |
| zyga | I'm not sure what happened because it used to work | 16:42 |
| om26er | could anyone with appropriate permissions please click "retry" there ? https://launchpad.net/~build.snapcraft.io/+snap/c7f9e9a2d76707f5da7a8175b964b834/+build/482950 | 17:00 |
| cjwatson | om26er: done | 17:00 |
| om26er | apparently the upload to store failed and I can't retry (and I am not admin on that said repo to force a rebuild) | 17:00 |
| om26er | cjwatson, thanks :) | 17:00 |
| === pstolowski is now known as pstolowski|afk | ||
| mup | PR snapd#6560 opened: cmd/snap-confine: drop uid from random /tmp name <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6560> | 17:04 |
| mvo | 6549 needs a second review | 17:09 |
| mup | PR snapd#6079 closed: cmd/snap: `snap connections` command <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6079> | 17:10 |
| pedronis | \o/ | 17:11 |
| mvo | pstolowski|afk: I will merge 6322 - I had some nitpicks (mostly tests) but can all be followups | 17:11 |
| mvo | pedronis: want to look at 6322 again before it goes in ? | 17:12 |
| mvo | 6492 also needs a second review | 17:12 |
| pedronis | mvo: 6322 should be fine if you are ok with | 17:13 |
| pedronis | mvo: yes, 6492 is next on my list | 17:13 |
| mvo | pedronis: I think you did 6492 already :) | 17:14 |
| pedronis | mvo: ah, yes, was confusing it with another one | 17:14 |
| mvo | pstolowski|afk: nice job on 6322 btw, I find this easier to read than the old code | 17:14 |
| mup | PR snapd#6322 closed: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6322> | 17:14 |
| mvo | pedronis: ok, I hope I did not merge too early then :/ | 17:15 |
| mup | PR snapd#6561 opened: cmd/snap-confine: chown private /tmp to root.root <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6561> | 17:48 |
| zyga | jdstrand: I opened one more cleanup from my review of older notes ^ | 17:48 |
| zyga | pedronis: design quesion, should the contents of private /tmp directory be preserved across "snap refresh" of said snap? | 17:51 |
| pedronis | zyga: you mean in a world where we are sure nothing runs of the snap during the refresh? | 17:56 |
| zyga | pedronis: yes | 17:58 |
| zyga | pedronis: should it retain contents across refresh? | 17:58 |
| zyga | pedronis: today it doesn't but I don't think that was deliberae | 17:58 |
| zyga | *deliberate | 17:58 |
| zyga | pedronis: it could easily do so | 17:59 |
| pedronis | zyga: that's interesting because I would have expected the reverse | 18:01 |
| zyga | pedronis: why? | 18:01 |
| zyga | pedronis: or sorry, reverse as in, it is retained? | 18:02 |
| pedronis | because if stuff can be running, how can we delete its content? | 18:02 |
| zyga | we don't technically delete the contents | 18:02 |
| pedronis | it's a tmpfs in the namespace? | 18:02 |
| zyga | ah, wait, I think I was mistaken a little, the conditions are more complex | 18:02 |
| zyga | it's not a tmpfs, it's a real directory in /tmp | 18:03 |
| zyga | we "delete" it when the base snap changes | 18:03 |
| zyga | but retain it while refreshing | 18:03 |
| zyga | I was thinking of refreshes but it is really the base that matters here, not the app | 18:03 |
| zyga | so the question, asked properly is: should we retain the /tmp that snaps see when the base has refreshed (we currently do not) | 18:04 |
| pedronis | I need to go have dinner, seems I need to understand this more | 18:04 |
| zyga | pedronis: sure, it's not urgent, just observation from the two tiny patches I posted | 18:05 |
| zyga | jdstrand: hey, I posted https://github.com/snapcore/snapd/pull/6559 with some apparmor-y things in relation to your 2.13 work | 18:12 |
| mup | PR #6559: pkg/apparmor: scratch documentation of apparmor <Created by zyga> <https://github.com/snapcore/snapd/pull/6559> | 18:12 |
| zyga | jdstrand: I understand 2.13 is urgent so I don't want to block your PR but I would like to know what you think about the ideas I posted | 18:13 |
| * zyga EODs | 18:32 | |
| pedronis | mvo: I tried to answer your naming nitpick, let me know | 18:33 |
| === tobias is now known as Guest93332 | ||
| mup | PR snapcraft#2494 opened: sources: handle network request errors <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2494> | 20:16 |
| === devil is now known as Guest97162 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!