| 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> | 04:22 |
|---|---|---|
| mborzecki | morning | 05:11 |
| pstolowski | morning | 07:04 |
| 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:25 |
| 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:29 |
| mardy | and indeed I see the same issue | 07:30 |
| mardy | now I'll try without pivot_root | 07:30 |
| mardy | ok, at least I verified it's not pivot_root's fault | 07:32 |
| 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:15 |
| mborzecki | mardy: haha yes --propagation, but i didn't remember it's private by default, i though it's not changing anything | 08:17 |
| mup | PR snapd#11671 opened: Snapshot exclusions fu <Simple 😃> <Skip spread> <Created by mardy> <https://github.com/snapcore/snapd/pull/11671> | 09:58 |
| mborzecki | mardy: does it work now? | 10:09 |
| 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:13 |
| mup | Bug #1968867 opened: Ubuntu Core 20 Raspberry Pi 4 4Gb "start4.elf not compatible" <Snappy:New> <https://launchpad.net/bugs/1968867> | 10:31 |
| mup | Bug #1968867 changed: Ubuntu Core 20 Raspberry Pi 4 4Gb "start4.elf not compatible" <Snappy:New> <https://launchpad.net/bugs/1968867> | 10:34 |
| mup | Bug #1968867 opened: Ubuntu Core 20 Raspberry Pi 4 4Gb "start4.elf not compatible" <Snappy:New> <https://launchpad.net/bugs/1968867> | 10:37 |
| mardy | mborzecki: yep :-) | 10:52 |
| mup | PR snapd#11673 opened: snap-confine: remove obsolete code <Created by mardy> <https://github.com/snapcore/snapd/pull/11673> | 10:59 |
| 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:15 |
| 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> | 13:54 |
| 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:28 |
| mborzecki | mardy: in case the snaps mount on those directories, but are not allowed to create them? | 14:30 |
| 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:37 |
| 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:48 |
| 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:49 |
| 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 | 14:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!