[05:47] <zyga> hello
[06:01] <mborzecki> morning
[06:21] <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:22] <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:23] <mborzecki> i can add aarch64 too
[06:24] <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:25] <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:29] <zyga> "snap install things quickly" :)
[07:10] <mborzecki> zyga: i'm seeing 434 syscalls known to libseccomp in the current master branch
[07:10] <zyga> mborzecki: how are you measuring?
[07:11] <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:32] <zyga> brb,dog.walk()
[07:44] <zyga> re
[07:44] <zyga> hello mvo
[07:45] <mvo> hey zyga ! good morning
[07:45] <zyga> welcome back :)
[07:45] <zyga> how was your week off?
[07:46] <mvo> zyga: it was very nice
[07:46] <mvo> zyga: thank you
[07:46] <mvo> zyga: what did I miss?
[07:47] <zyga> mvo: let me think
[07:48] <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:49] <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:50] <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:51] <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:55] <mvo> zyga: ta, I will chase it
[07:59] <mborzecki> mvo: hey
[08:01] <pstolowski> morning
[08:03] <mvo> good morning mborzecki  and pstolowski !
[08:18] <Chipaca> moin moin
[08:18] <Chipaca> ooh, new git
[08:18]  * Chipaca accepts the gift of the apt gods 
[08:24]  * 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:25] <mborzecki> zyga: thanks!
[08:27] <mborzecki> zyga: https://paste.ubuntu.com/p/cJ2v9hfJhH/ snap-seccomp version is added at the very beginning
[08:28] <mborzecki> it's the library version followed by the hash of the supported syscall names
[08:36] <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:38] <zyga> mborzecki: bonus points for naming the hash algo
[08:43] <wgrant> mvo: Morning, welcome back.
[08:43] <wgrant> mvo: Any idea on the current situation with backporting the catalog randomisation?
[08:44] <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:47] <wgrant> mvo: Does that include xenial/bionic-security?
[08:52] <mup> PR snapd#6558 opened: many: remove unused code (mostly) <Created by chipaca> <https://github.com/snapcore/snapd/pull/6558>
[08:57] <pedronis> mvo: hi, welcome back, hope the week (mostly) off was restful
[08:58] <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*
[09:02] <smallville7123> For example, "Kotlin/Native compiler" and "Command line Kotlin compiler"
[09:04] <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:06] <Chipaca> smallville7123: read the description of both?
[09:06] <smallville7123> Where do i find thay
[09:06] <smallville7123> That
[09:07] <Chipaca> smallville7123: snap info kotlin kotlin-native (snap info kot-alt-*)
[09:09] <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:10] <Chipaca> pedronis: you introduced a double-lock on state, there
[09:10] <Chipaca> unless i missed something
[09:10] <Chipaca> nope
[09:11] <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:12] <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:13] <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:14] <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:16] <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:20] <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:23] <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:24] <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:26] <Chipaca> mborzecki: 6556 is included in 6079?
[09:27] <mborzecki> Chipaca: no, i've reverted that patch from 6079
[09:28] <mborzecki> Chipaca: iirc the plan is snap conenctions for 2.38, then deprecation & hide interfaces in .39
[09:28] <Chipaca> ok
[09:29] <Chipaca> i need to step out for a bit, i'll review when i return
[09:31] <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:37] <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:38] <zyga> but it may be less terrible than we thought last week
[09:43] <mvo> zyga: lets talk in ~45min again then my head should be a bit less busy
[09:44] <pedronis> zyga: yes, I see the relevant code now, it's quite spread out
[09:45] <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:46] <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:49] <Chipaca> mborzecki: +1 to 6079
[09:49] <Chipaca> mborzecki: thank you
[09:49] <mborzecki> Chipaca: thanks for the review!
[10:02] <mborzecki> will be out for a while, left a note in the forum
[10:05] <Chipaca> ok, _now_ i'm stepping out for a bit
[10:14]  * dot-tobias waves
[10:25] <mup> PR snapd#6558 closed: many: remove unused code (mostly) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6558>
[10:37] <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>
[11:05] <mup> PR snapd#6559 opened: pkg/apparmor: scratch documentation of apparmor <Created by zyga> <https://github.com/snapcore/snapd/pull/6559>
[11:30] <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:36] <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:37] <pedronis> pstolowski: I mean what happens if there is more than one 1 etc
[11:38] <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:39] <zyga> pedronis: I don't want to block it yet, it mainly depends on the reaction to my small RFC branch
[11:40] <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:41] <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:42] <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:50] <pstolowski> pedronis: and this is how it's used https://pastebin.ubuntu.com/p/5hgwQqHckt/
[11:52] <pedronis> pstolowski: thx, looks reasonable
[11:55] <mvo> pstolowski: nice stuff!
[11:55]  * mvo is very excited about this feature
[11:56] <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:57] <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:59] <mborzecki> re
[12:06] <pstolowski> pedronis, mvo thanks for quick feedback, in that case i'll polish it a bit and propose a base PR
[12:07] <mvo> pstolowski: sounds great
[12:09] <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:10] <Chipaca> allow_failures i mean
[12:46] <pedronis> mvo: it seems I created confusion with my comment about Active
[13:01]  * 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:11] <mborzecki> damn, sudden power loss :/
[13:12] <Chipaca> I remember having to have an UPS for my router :-)
[13:13] <Chipaca> mborzecki: thank you for pointing out the changing of publisher across revisions btw
[13:14] <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:15] <Chipaca> :-D
[13:29] <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:41] <pedronis> ijohnson: there is some indirection, it is built from here: https://git.launchpad.net/snapd-vendor/commit/?id=2c7e24947044fd67c166871d81374dcee76b135c
[13:45] <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:58] <mvo> zyga: thank you for the update to 6498
[14:19] <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:21] <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:35] <jdstrand> lborda: the denial says you are doing something different than what you describe. perhaps use a pipe of /dev/stderr /dev/stdout?
[14:36] <jdstrand> err
[14:36] <jdstrand> pipe or* /dev/stderr and /dev/stdout?
[14:38] <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:40] <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:41] <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:47] <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:48] <jdstrand> lborda: instead of specifying stdout and stderr as files, perhaps use Popen.communicate to get the output, then write that out yourself
[14:49] <jdstrand> there are probably other ways to fix it
[14:49] <jdstrand> mborzecki: ack
[14:49] <mborzecki> jdstrand: thanks!
[14:58] <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>
[15:02] <jdstrand> lborda: the underlying issue (fd inheritence with apparmor) is the same, but that is a different issue
[15:04] <jdstrand> lborda: this has some detail: https://forum.snapcraft.io/t/snapd-2-32-breaks-live-server-installer/4597/10
[15:05] <jdstrand> lborda: but put more siccinctly, it is a limitation that should improve with time
[15:05] <jdstrand> succinctly*
[15:07] <lborda> jdstrand, yes agree different issue same underlying issue...
[15:08] <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:10] <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:14] <sborovkov> hi, is there any apparmor stuff still working when snap is installed in devmode?
[15:15] <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:20] <zyga> re
[15:20] <zyga> mvo: thank  you  :)
[15:21] <zyga> jdstrand: hello :-)
[15:30] <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:31] <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:36] <Chipaca> sborovkov: in devmode, apparmor is set to allow everything but log
[15:37] <Chipaca> sborovkov: seccomp, also
[15:47] <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:48] <Chipaca> sborovkov: nothing is forbidden by apparmor / seccomp, but the view of the system remains the same as in strict
[15:49] <sborovkov> I guess the cause should be somewhere in there then :(
[15:51] <Chipaca> sborovkov: don't you get anything in the system logs?
[15:52] <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:53] <sborovkov> I guess I will try to get that process running in gdb.
[15:55] <Chipaca> sborovkov: snap run --gdb ?
[15:56] <sborovkov> I did not even know that was a thing now :)
[15:57] <Chipaca> sborovkov: also 'snap run --strace' :-)
[15:57] <Chipaca> and trace-exec …
[15:57] <Chipaca> it's getting all fancy and grown-up
[15:58] <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:59] <sborovkov> and I have done bind mount of the directory containing modified snap so gdb spews out some errors because of that I guess
[16:41] <zyga> popey: hey, sublime-text  doesn't work on 18.10
[16:42] <zyga> I'm not sure what happened because it used to work
[17:00] <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:04] <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:09] <mvo> 6549 needs a second review
[17:10] <mup> PR snapd#6079 closed: cmd/snap: `snap connections` command <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6079>
[17:11] <pedronis> \o/
[17:11] <mvo> pstolowski|afk: I will merge 6322 - I had some nitpicks (mostly tests) but can all be followups
[17:12] <mvo> pedronis: want to look at 6322 again before it goes in ?
[17:12] <mvo> 6492 also needs a second review
[17:13] <pedronis> mvo: 6322 should be fine if you are ok with
[17:13] <pedronis> mvo: yes, 6492 is next on my list
[17:14] <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:15] <mvo> pedronis: ok, I hope I did not merge too early then :/
[17:48] <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:51] <zyga> pedronis: design quesion, should the contents of private /tmp directory be preserved across  "snap  refresh" of said snap?
[17:56] <pedronis> zyga: you mean in a world where we are sure nothing runs of the snap during the refresh?
[17:58] <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:59] <zyga> pedronis: it could easily do so
[18:01] <pedronis> zyga: that's interesting because I would have expected the reverse
[18:01] <zyga> pedronis: why?
[18:02] <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:03] <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:04] <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:05] <zyga> pedronis: sure, it's not urgent, just observation from the  two tiny patches I posted
[18:12] <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:13] <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:32]  * zyga EODs
[18:33] <pedronis> mvo: I tried to answer your naming nitpick, let me know
[20:16] <mup> PR snapcraft#2494 opened: sources: handle network request errors <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2494>