| mup | PR snapd#11144 opened: packaging: merge 2.53.4 (and also 2.53.3) changelogs back to master <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/11144> | 01:25 |
|---|---|---|
| amurray | ijohnson[m]: is that the right LP bug number in the 2.53.3/4 changelog? | 01:35 |
| mborzecki | morning | 06:54 |
| pstolowski | hey | 08:06 |
| mborzecki | heya | 08:40 |
| mborzecki | https://github.com/snapcore/snapd/pull/11138 needs a 2nd review | 09:13 |
| mup | PR #11138: tests/core/kernel-and-base-single-reboot-failover, tests/lib/fakestore: verify failover scenario <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11138> | 09:13 |
| mup | PR snapd#11126 closed: tests: verify that simultaneous refresh of kernel and base triggers a single reboot only <Squash-merge> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11126> | 09:17 |
| mborzecki | heh, so snap-mgmt fails on fedora 35 now, that's because /var/lib/snapd/snap is a bind mount of itself, which is fine because we accounted for that in the script, but the entry in proc/self/mountinfo is: `749 63 0:31 /root/var/lib/snapd/snap /var/lib/snapd/snap rw,relatime shared:1 - btrfs /dev/sda5 rw,seclabel,compress=zstd:1,space_cache,subvolid=256,subvol=/root`and we looked for ` var/lib/snapd/snap /var/lib/snapd/snap` because nobody | 10:55 |
| mborzecki | guessed there would be some magical /root btrfs subvolume | 10:55 |
| === alan_g_ is now known as alan_g | ||
| mup | PR snapd#11072 closed: usersession/client: provide a way for client to send messages to a subset of users <refresh app awareness> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/11072> | 11:47 |
| mup | PR snapd#11141 closed: data/env: improve fish shell env setup <Simple 😃> <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/11141> | 12:22 |
| pstolowski | jamesh: thanks for approving the notifications PR, https://github.com/snapcore/snapd/pull/11066 would be next in the queue when you have a moment for re-review | 12:26 |
| mup | PR #11066: usersession: implement method to close notifications via usersession REST API <refresh app awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/11066> | 12:26 |
| abeato | hey, how is usually snap-confine debugged/tested, without bind-mounting? | 12:28 |
| mborzecki | abeato: depends on the distro, for fedora/arch/opensuse i usually just `cd cmd/snap-confine && make hack -j` | 12:29 |
| mborzecki | on ubuntu/debian you'd probably want to disable reexec (SNAPD_REEXEC=0 IIRC) | 12:29 |
| abeato | mborzecki, thanks, will try those bits | 12:30 |
| mup | PR snapd#11145 opened: tests/main/generic-unregister: test re-registration if not blocked <Created by pedronis> <https://github.com/snapcore/snapd/pull/11145> | 14:53 |
| jawn-smith | I know I've been kind of a pain lately, sorry about that, but it appears that workflows need approval again for PR 11052 | 14:54 |
| mup | PR #11052: tests: ensure snapd can be downloaded as a module <Squash-merge> <Created by atesburak> <https://github.com/snapcore/snapd/pull/11052> | 14:54 |
| mup | Bug #1953172 opened: Find a better handling of /etc/localtime symlink on Ubuntu Core <Snappy:New for valentin.david> <https://launchpad.net/bugs/1953172> | 15:40 |
| mup | Bug #1953172 changed: Find a better handling of /etc/localtime symlink on Ubuntu Core <Snappy:New for valentin.david> <https://launchpad.net/bugs/1953172> | 15:43 |
| mup | Bug #1953172 opened: Find a better handling of /etc/localtime symlink on Ubuntu Core <Snappy:New for valentin.david> <https://launchpad.net/bugs/1953172> | 15:49 |
| mwleeds[m] | Hi folks, anyone know if checking pid cgroup membership is the official way to check if the current process is running under snap? | 18:41 |
| mwleeds[m] | That is what xdg-desktop-portal does but thought I'd try to confirm because I'm working on code that's meant to work with Flatpak portals but ideally it should work with snap too since that uses the same portals. | 18:42 |
| ijohnson[m] | mwleeds: yes that is correct snaps should be in a snap.foo cgroup essentially | 18:45 |
| mwleeds[m] | thanks | 18:46 |
| mup | PR snapcraft#3602 closed: spread: switch to yarn for electron-builder test <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3602> | 19:57 |
| mup | PR snapd#11137 closed: snapdtool, many: support additional key/value flags in info file <Simple 😃> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/11137> | 20:35 |
| mup | PR snapd#11052 closed: tests: ensure snapd can be downloaded as a module <Squash-merge> <Created by atesburak> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/11052> | 20:50 |
| jawn-smith | ijohnson[m]: thanks so much for merging that PR! | 21:09 |
| jawn-smith | ijohnson[m]: I'm actually now a little confused by some of the behavior in the latest snapd concerning validation. It seems like I can no longer use the --snap flag in ubuntu-image with a grade higher than dangerous. | 22:54 |
| jawn-smith | Is that the intended behavior? The value of the validation flag does not affect the outcome of the command | 22:55 |
| jawn-smith | (pinging you as I see you discussing this in bug 1933665 | 22:55 |
| mup | Bug #1933665: Refresh Control is not supported by ubuntu-image <snapd:Fix Committed by pedronis> <Snap Store Server:Invalid> <Ubuntu Image:Fix Committed> <https://launchpad.net/bugs/1933665> | 22:55 |
| jawn-smith | This previously worked in ubuntu-image when we were pulling in a version of snapd that was built in August. Currently digging through source code to see what's changed | 23:02 |
| ijohnson[m] | jawn-smith: yeah not gonna lie this whole situation around not supporting refresh control is extremely confusing and frustrating because we keep getting pinged about it and I assume you keep getting pinged about as well | 23:14 |
| ijohnson[m] | Really AFAICT it should work in snap prepare-image code to provide an extra snap with grade secured or grade signed as long as that snap is an asserted one | 23:14 |
| jawn-smith | ijohnson[m]: that is accurate | 23:14 |
| ijohnson[m] | So I am lost why folks keep saying this doesn't work | 23:14 |
| jawn-smith | well previously it didn't have to be asserted, which is really all I'm trying to check in on | 23:15 |
| jawn-smith | let me assert hello in my model assertion real quick to make sure that works, but AFAICT you're right about it working if it's asserted. | 23:16 |
| ijohnson[m] | I also did test this multiple times with the legacy ubuntu-image but I suppose maybe now folks are using the new Go based ubuntu-image | 23:16 |
| ijohnson[m] | oh what do you mean it didn't have to be asserted? | 23:16 |
| ijohnson[m] | if the grade is signed or secured then yes it is 100% expected that an unasserted snap is not allowed | 23:17 |
| ijohnson[m] | that's like one of the key parts of the model grade | 23:17 |
| jawn-smith | right okay, so previously if I didn't have "hello" listed in the model assertion I could still call ubuntu-image snap assert.model --snap=hello and it would get included in the resulting image | 23:18 |
| jawn-smith | That still works for core18 image | 23:18 |
| jawn-smith | s/image/images | 23:18 |
| ijohnson[m] | ah okay so to be clear, the grade signed/secured stuff only applies to uc20 | 23:19 |
| jawn-smith | okay that's good to know, thanks. | 23:20 |
| jawn-smith | However, if a snap is asserted it shouldn't have to be separately specified with --snap, right? | 23:22 |
| ijohnson[m] | so here's the thing, in your model assertion you list what snaps are required to be in the image. If you specify some snap in the model assertion and do not provide it with --snap, then snapd will try to download that snap from the store and include it - in this case it is an asserted snap that gets included from whatever channel | 23:24 |
| ijohnson[m] | if you include in your model assertion a snap that is not uploaded to the store at all (i.e. some snap name that can't be found in the store by snapd), then without --snap you cannot build the image and snapd will complain | 23:24 |
| jawn-smith | ahhhh yes, I wasn't thinking of the local snap use case | 23:25 |
| jawn-smith | okay great, I have a couple of things to test, but it sounds like everything is working as it's supposed to | 23:25 |
| ijohnson[m] | if you include in your model assertion a snap that is not uploaded to the store and then also provide a snap that is not asserted by the store with --snap, then that snap gets included into the image as an unasserted snap - BUT ONLY if the image is uc16, uc18 or uc20 + grade dangerous, if it is uc20 and grade signed, then snapd complains | 23:25 |
| ijohnson[m] | if you include in your model assertion a snap that is uploaded to the store and you also provide it with --snap, then what happens next depends on whether that snap file is asserted and what model assertion you have | 23:26 |
| ijohnson[m] | if you are providing a local snap that is unasserted by the store, then this unasserted snap only gets included in the image if your model is grade dangerous on uc20 (or if the image is uc16/uc18) | 23:27 |
| ijohnson[m] | if you are providing a local snap that is asserted by the store, then this very specific version of the asserted snap will get included in the image no matter what grade of model assertion is being used on uc20 because that snap is asserted from the store | 23:27 |
| jawn-smith | Okay great, that all makes sense. One last question: where does the --validation flag fit into this? If set to ignore does it allow you to use unasserted snaps in a signed model? | 23:28 |
| ijohnson[m] | okay yes that new flag does play a part in this somewhat | 23:29 |
| ijohnson[m] | so if you provide the --validation=NOT-IGNORE (I forget the value that means use validation, don't ignore it), then if the grade of the model is dangerous, snapd will let you use --snap=unasserted-file.snap and put that in the image | 23:30 |
| jawn-smith | aha, that makes total sense. Thanks for clearing all that up | 23:30 |
| jawn-smith | it's --validation=enforce btw :) | 23:31 |
| ijohnson[m] | if you provide --validation=NOT-IGNORE, and your model assertion is signed or secured, then the snap you provide with --snap must be asserted, and AFAICT, snapd will let you overwrite what is in the validation assertion for that snap | 23:31 |
| ijohnson[m] | the big part of using --validation=NOT-IGNORE is that you typically do not want to use --validation=NOT-IGNORE with --snap, since that's kind of defeating the purpose | 23:31 |
| ijohnson[m] | ah yes thanks | 23:31 |
| jawn-smith | Okay, I'm going to test all that out manually and put it in some unit tests as well. Thanks! | 23:32 |
| ijohnson[m] | so the use case is to run --validation=enforce with no --snap arguments and then snapd will put into your image the specific revisions mentioned by that assertion | 23:32 |
| ijohnson[m] | if you are running --validation=enforce with some --snap arguments, it's a bit unclear what you are trying to accomplish | 23:32 |
| jawn-smith | Thanks for clearing all this up, I appreciate it. | 23:33 |
| ijohnson[m] | I think part of the confusion is that I have been trying to tell people "use --snap <specific-asserted-file>.snap because --validation=enforce isn't available yet" and I guess people have been not understanding what I mean by that | 23:33 |
| ijohnson[m] | okay sounds good, certainly reach out if you have more questions, it is indeed fairly complicated but my hope is that we can get --validation=enforce to work and then I can tell everybody to stop using --snap and just tell them to use --validation=enforce and the confusion can all go away 🙂 | 23:34 |
| mup | PR snapcraft#3603 closed: [spike] new-snapcraft: fix execution in managed environment <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/3603> | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!