| === benfrancis29 is now known as benfrancis2 | ||
| === not_phunyguy is now known as phunyguy | ||
| === not_phunyguy is now known as phunyguy | ||
| mborzecki | morning | 05:15 |
|---|---|---|
| mardy | mborzecki: hi! | 05:29 |
| mborzecki | mardy: hey | 05:49 |
| mborzecki | mardy: i think it's what/where, mount seems to be defined as list | 05:53 |
| mardy | mborzecki: ouch, I now realize that the formatting in the commend was lost | 05:55 |
| 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? | 05:57 |
| mborzecki | gh is kinda slow | 06:05 |
| mborzecki | mardy: yes, if i'm reading this right, there's supposed to be a `mount` attribute which has a list of mappings | 06:08 |
| 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:15 |
| pstolowski | morning | 06:28 |
| mardy | pstolowski: hi! | 06:34 |
| mardy | mborzecki: I would say that umount should also be implied | 06:34 |
| zyga-mbp | good morning | 06:37 |
| mborzecki | pstolowski: hey | 06:38 |
| mborzecki | zyga-mbp: hey | 07:04 |
| zyga-mbp | hey :-) | 07:05 |
| mborzecki | mvo: morning | 07:08 |
| mvo | good morning mborzecki and zyga-mbp | 07:08 |
| mardy | mvo: hi! | 07:09 |
| 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:10 |
| zyga-mbp | hey mvo, hey mardy :) | 07:14 |
| zyga-mbp | mardy I may know | 07:14 |
| zyga-mbp | mardy so | 07:14 |
| 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:15 |
| zyga-mbp | the mount backend will rename one of the plugs to "foo-1" | 07:16 |
| zyga-mbp | mardy hth :) | 07:16 |
| mardy | zyga-mbp: thanks!, makes sense. | 07:18 |
| pedronis | hello, reminder I need reviews for https://github.com/snapcore/snapd/pull/10458 | 07:18 |
| 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:19 |
| mborzecki | unless that's a different list of thing again | 07:20 |
| mvo | hi mardy! good morning too you too | 07:20 |
| mborzecki | mardy: iirc if multiple things are mounted at the same location, then content will be named foo, foo-1, foo-2 | 07:22 |
| 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:23 |
| 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:24 |
| 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:27 |
| pedronis | mborzecki: tbh if you working a bit with assertstest nowadays I just recommend reading it maybe | 07:30 |
| mborzecki | pedronis: started looking at it, but got buried with assertions in managers | 07:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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 ? | 07:50 |
| 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:01 |
| pedronis | mardy: (sorry, mvo was in a meeting with me) | 08:02 |
| pedronis | content is one of those exceptions for example, but mount-control is meant to be just permissions | 08:08 |
| pedronis | pstolowski: there's test-snapd-bare-base and bare | 08:10 |
| pedronis | those are minimal and tested | 08:10 |
| pstolowski | pedronis: i had something similiar but my hook wouldn't work (i was getting an error about snap-exec) | 08:15 |
| mvo | could someone please eyeball 10456? it's for the 2.51.2 backport of the pi-config fixes | 10:17 |
| mvo | and 10455 | 10:17 |
| pstolowski | mvo: done | 11:36 |
| mvo | pstolowski: \o/ | 12:45 |
| 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:50 |
| 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:51 |
| mardy | cachio__: thanks! | 14:52 |
| * mvo switches network and will be off for some minutes | 14:54 | |
| cachio__ | mardy, where make_snap_installable_with_id is defined? | 14:56 |
| cachio__ | found it | 14:56 |
| 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:58 |
| cachio__ | there you have an example | 14:59 |
| cachio__ | mardy, | 14:59 |
| 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:00 |
| cachio__ | it should be the same | 15:01 |
| pedronis | pstolowski: I reviewed the wait-chain PRs | 15:10 |
| pstolowski | pedronis: ty | 15:15 |
| 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:23 |
| pedronis | thx | 15:24 |
| cachio__ | yaw | 15:24 |
| pstolowski | thanks | 15:25 |
| * pstolowski errand, eod | 15:30 | |
| wez | .o/ | 15:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!