[04:22] <mup> PR snapd#11670 opened: When running a desktop file, run via the desktop launcher <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/11670>
[05:11] <mborzecki> morning
[07:04] <pstolowski> morning
[07:25] <mborzecki> mardy: looking at your snap namespace again, /var/lib/snapd/hostfs/snap/test-snapd-content-slot/3 isn't there either, so something is missing indeed
[07:29] <mardy> mborzecki: yes, I noticed that too. Now I've prepare a couple of scripts to test it locally on my host, without using qemu -- this makes thigns way faster
[07:30] <mardy> and indeed I see the same issue
[07:30] <mardy> now I'll try without pivot_root
[07:32] <mardy> ok, at least I verified it's not pivot_root's fault
[08:15] <mardy> mborzecki: argh! the `unshare` command has a `--propagation` option, which if unspecified defaults to "private". And I wasted almost one day there... :-D
[08:17] <mborzecki> mardy: haha yes --propagation, but i didn't remember it's private by default, i though it's not changing anything
[09:58] <mup> PR snapd#11671 opened: Snapshot exclusions fu <Simple 😃> <Skip spread> <Created by mardy> <https://github.com/snapcore/snapd/pull/11671>
[10:09] <mborzecki> mardy: does it work now?
[10:13] <mup> PR snapd#11672 opened: interfaces,overlord: move parameters from interfaces/backend Setup/SetupMany to a struct <Needs Samuele review> <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/11672>
[10:31] <mup> Bug #1968867 opened: Ubuntu Core 20 Raspberry Pi 4 4Gb "start4.elf not compatible" <Snappy:New> <https://launchpad.net/bugs/1968867>
[10:34] <mup> Bug #1968867 changed: Ubuntu Core 20 Raspberry Pi 4 4Gb "start4.elf not compatible" <Snappy:New> <https://launchpad.net/bugs/1968867>
[10:37] <mup> Bug #1968867 opened: Ubuntu Core 20 Raspberry Pi 4 4Gb "start4.elf not compatible" <Snappy:New> <https://launchpad.net/bugs/1968867>
[10:52] <mardy> mborzecki: yep :-)
[10:59] <mup> PR snapd#11673 opened: snap-confine: remove obsolete code <Created by mardy> <https://github.com/snapcore/snapd/pull/11673>
[13:15] <mardy> mborzecki: the spread tests are failing on https://github.com/snapcore/snapd/pull/11673 because the hostfs dir is not created there; aren't we install the snapd package there?
[13:15] <mup> PR #11673: snap-confine: remove obsolete code <Created by mardy> <https://github.com/snapcore/snapd/pull/11673>
[13:54] <mup> PR snapd#11662 closed: tests: do not run mount-order-regression test on i386 <Simple 😃> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/11662>
[14:28] <mardy> mborzecki: do you know why this mkdir is only done on bidirectional mounts? https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L334-L337 (the commit which created is 5682a74d45b167706bd257ddc0e5432224a038d8)
[14:30] <mborzecki> mardy: in case the snaps mount on those directories, but are not allowed to create them?
[14:37] <mardy> mborzecki: yes, but my question is not really about the mkdir, which is understandable, but why it's done only on bidirectional mounts
[14:48] <mborzecki> mardy: that's beacuse a snap could mount things, eg a snap with udisks2 slot could mount stuff under /mnt or /media which then becomes visible elsewhere
[14:49] <mborzecki> mardy: and for bidirectional mounts you want them to have shared propagation, so s-c will probably convert them to mount points by bind mounting them on top of themselves
[14:52] <mardy> mborzecki: mmm... all this makes sense, but it doesn't explain (or I'm not understanding) why the mkdir is not done on unidirectional mount points. I start to suspect that this was written and tested specifically for /run/netns