[05:15] <mborzecki> morning
[05:29] <mardy> mborzecki: hi!
[05:49] <mborzecki> mardy: hey
[05:53] <mborzecki> mardy: i think it's what/where, mount seems to be defined as list
[05:55] <mardy> mborzecki: ouch, I now realize that the formatting in the commend was lost
[05:57] <mardy> mborzecki: you mean, that for specifying multiple mounts, there should be a single plug, with a list of what/where fields inside the "mount" attribute?
[06:05] <mborzecki> gh is kinda slow
[06:08] <mborzecki> mardy: yes, if i'm reading this right, there's supposed to be a `mount` attribute which has a list of mappings
[06:15] <mborzecki> mardy: tbh, wondering if there will be like an 'unmount' attribute too, or does it already imply that a snap can mount & unmount?
[06:15] <mborzecki> i guess it wouldn't be named mount control then
[06:28] <pstolowski> morning
[06:34] <mardy> pstolowski: hi!
[06:34] <mardy> mborzecki: I would say that umount should also be implied
[06:37] <zyga-mbp> good morning
[06:38] <mborzecki> pstolowski: hey
[07:04] <mborzecki> zyga-mbp: hey
[07:05] <zyga-mbp> hey :-)
[07:08] <mborzecki> mvo: morning
[07:08] <mvo> good morning mborzecki and zyga-mbp 
[07:09] <mardy> mvo: hi!
[07:10] <mardy> I see in the content interface, that it appends a "-[0-9]*" to the apparmor rules for accessing the target mount point: anyonw knows why?
[07:10] <mardy> emit("  mount options=(rprivate) -> %s{,-[0-9]*}/,\n", target)
[07:14] <zyga-mbp> hey mvo, hey mardy :)
[07:14] <zyga-mbp> mardy I may know
[07:14] <zyga-mbp> mardy so
[07:15] <zyga-mbp> it's the auto-unclashing system
[07:15] <zyga-mbp> there is a test for that as well
[07:15] <zyga-mbp> let's say you have a slot that accepts content in $SNAP/plugins
[07:15] <zyga-mbp> and then you have two other content interfaces that offer plugs that contain the plugin name
[07:15] <zyga-mbp> but due to some mistake, they have the same name "foo"
[07:16] <zyga-mbp> the mount backend will rename one of the plugs to "foo-1"
[07:16] <zyga-mbp> mardy hth :)
[07:18] <mardy> zyga-mbp: thanks!, makes sense.
[07:18] <pedronis> hello, reminder I need reviews for https://github.com/snapcore/snapd/pull/10458
[07:19] <mborzecki> meh, assertions, in managers tests, `s.brands.AccountsAndKeys("can0nical")`, tells me that there's no such key, so how come a model assertion for that brand can be generated?
[07:20] <mborzecki> unless that's a different list of thing again
[07:20] <mvo> hi mardy! good morning too you too
[07:22] <mborzecki> mardy: iirc if multiple things are mounted at the same location, then content will be named foo, foo-1, foo-2 
[07:23] <mborzecki> mardy: that's probbaly done by snap-update-ns but the content iface could use a comment about that behavior if there isn't one yet
[07:24] <zyga-mbp> mborzecki that's done in snapd proper, snap-update-ns just executes the orders
[07:24] <zyga-mbp> it's done in the mount backedn
[07:24] <zyga-mbp> *backend
[07:24] <pedronis> mborzecki: the store account is not registered with the others, you need to find it on the store stack itself or fix this
[07:24] <pedronis> mborzecki: only signing with it is supported atm as a convenience
[07:27] <pedronis> this is also because there can be more than one key tied to it, while the rest of that code assumes one key usually for the accounts
[07:30] <pedronis> mborzecki: tbh if you working a bit with assertstest nowadays I just recommend reading it maybe
[07:33] <mborzecki> pedronis: started looking at it, but got buried with assertions in managers
[07:34] <mborzecki> pedronis: btw. i think i'm getting a hold of it now, had to tweak seedtest a little as it's doing a bit to much for my use case
[07:35] <mborzecki> pedronis: well, at least it isn't complaining about account id, models and so on, i can open a quick PR with thw tweaks so that you can tell whether those make any sense
[07:36] <mardy> mvo: about the mount-control interface: the plug definition only specifies what mount operations are allowed, so that the application can call mount/umount itself, or are these mount points expected to be automatically mounted, when the plug gets connected?
[07:36] <mardy> or pedronis ^
[07:50] <pstolowski> do we have any doc/tutorial about building a minimal and functioning base snap and its requirements? anything more than https://snapcraft.io/docs/base-snaps ?
[08:01] <pedronis> mardy: just permissions, nothing happens on connection. that's the case for most interfaces, they given permissions, don't have side effects, with few exceptions
[08:02] <pedronis> mardy: (sorry, mvo was in a meeting with me)
[08:08] <pedronis> content is one of those exceptions for example, but mount-control is meant to be just permissions
[08:10] <pedronis> pstolowski: there's test-snapd-bare-base and bare
[08:10] <pedronis> those are minimal and tested
[08:15] <pstolowski> pedronis: i had something similiar but my hook wouldn't work (i was getting an error about snap-exec)
[10:17] <mvo> could someone please eyeball 10456? it's for the 2.51.2 backport of the pi-config fixes
[10:17] <mvo> and 10455
[11:36] <pstolowski> mvo: done
[12:45] <mvo> pstolowski: \o/
[14:50] <mardy> cachio__: hi! So, the problem I'm having with the fake store is that I create a package with make_snap_installable_with_id, but installation fails:
[14:50] <mardy> - Fetch and check assertions for snap "microk8s" (1) (cannot find supported signatures to verify snap "microk8s" and its hash (account (developer1) not found))
[14:50] <cachio__> mardy, hi, can you show me the test please?
[14:50] <cachio__> do you have a link?
[14:51] <mardy> cachio__: here's the preparation code: https://github.com/anonymouse64/snapd/blob/feature/snap-microk8s-shared-system-usernames/tests/main/system-usernames-microk8s/task.yaml#L35-L42
[14:51] <cachio__> mardy, tx
[14:51] <cachio__> I'll have a look
[14:52] <mardy> cachio__: thanks!
[14:54]  * mvo switches network and will be off for some minutes
[14:56] <cachio__> mardy, where make_snap_installable_with_id is defined?
[14:56] <cachio__> found it
[14:58] <mardy> cachio__: ah, I think I got it: I was just calling "snap ack" on the account assertions for developer1, but I also need to copy them under the store's assertions dir
[14:58] <cachio__> yes
[14:58] <cachio__> look at the test
[14:58] <cachio__> set-proxy-store
[14:59] <cachio__> there you have an example
[14:59] <cachio__> mardy, 
[15:00] <mardy> cachio__: I see, thanks! I see that most other tests, however, keep the assertions separate (they use cp and not cat), but I guess it's equivalent
[15:01] <cachio__> it should be the same
[15:10] <pedronis> pstolowski: I reviewed the wait-chain PRs
[15:15] <pstolowski> pedronis: ty
[15:23] <pedronis> pstolowski: cachio__: it seems some image has changed now we get core20 instead of core18, this makes the preseed test fail, see here for example: https://github.com/snapcore/snapd/pull/10458/checks?check_run_id=2943137639
[15:23] <cachio__> pedronis, ah, ok, I'll update that
[15:23] <pedronis> it happens 20.10 and 21.04
[15:23] <cachio__> I just updated last week one test with this problem
[15:24] <pedronis> thx
[15:24] <cachio__> yaw
[15:25] <pstolowski> thanks
[15:30]  * pstolowski errand, eod
[15:34] <wez> .o/