[00:35] <mup> PR pc-amd64-gadget#22 closed: Store changes <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/22>
[00:39] <ogra> hrm
[00:41] <ogra> why does the home interface not allow me to read data produced by one snap via the other in a ~/snap/<snapname>/current/ subdir
[00:41] <ogra> ogra@acheron:~/snap/arduino-mhall119/current/Arduino/test$ esptool -cp /dev/ttyUSB0 -cd none -ca 0x40000 -cf test.ino.generic.bin
[00:41] <ogra> produces :
[00:41] <ogra> Nov 05 01:39:38 acheron audit[4633]: AVC apparmor="DENIED" operation="open" profile="snap.esptool.esptool" name="/home/ogra/snap/arduino-mhall119/5/Arduino/test/test.ino.generic.bin" pid=4633 comm="esptool" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[00:42] <ogra> funnily enough i can copy the file to ~/ and am allowed to open it
[00:42] <ogra> i'd have thought he home interface allows this ?
[06:06] <zyga> ogra: that is by design
[06:06] <zyga> Snaps cannot read each other’s data
[06:15] <mborzecki> morning
[06:16] <mup> PR snapd#7718 closed: sandbox/seccomp: accept build ID generated by Go toolchain <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7718>
[06:27] <zyga> hey mborzecki
[06:27] <mborzecki> zyga: hey hey
[06:27] <zyga> mborzecki: we should talk today
[06:28] <zyga> mborzecki: about how to salvage app tracking
[06:33] <mborzecki> zyga: do we need mvo for this discussion too?
[06:33] <zyga> mborzecki: we can split the call into more technical and more strategic parts
[06:33] <zyga> mborzecki: in this sense we can discuss without him
[06:37] <zyga> mborzecki: let's try to have a call in an hour or so
[06:37] <zyga> mborzecki: I have one idea for a frankenstein that might owrk
[06:37] <zyga> mborzecki: but it's all terrible
[07:29] <zyga> how can I remove this *** tracker
[07:29] <zyga> it spawns every few seconds logging stuff
[07:30] <mborzecki> zyga: what tracker?
[07:30] <zyga> Started Tracker metadata database store and lookup manager.
[07:30] <zyga> this shows up every few seconds
[07:30] <zyga> it is a systemd unit in the user session
[07:30] <zyga> tried disabling it
[07:30] <zyga> doesn't hel
[07:30] <zyga> help
[07:30] <zyga> disabled search in gnome
[07:30] <zyga> removing it would remove half of ubuntu
[07:31] <mborzecki> zyga: try the tracker command, `tracker daemon <something>` iirc
[07:31] <mborzecki> hm didn't know it's already hooked up as user service
[07:32] <zyga> thanks, let's see if that helps
[07:59]  * zyga break
[08:10] <pstolowski> morning
[08:19] <mborzecki> pstolowski: mvo: hey
[08:19] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/7665 is green
[08:19] <mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Priority 🏇> <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
[08:20] <mvo> mborzecki: yes, I just looked at this and thats great
[08:20] <mvo> it just needs a second review
[08:22] <mvo> pstolowski: do you think you could have a look at 7665 ?
[08:22] <pstolowski> mvo: sure
[08:24] <mvo> thank you :)
[08:25] <mborzecki> pstolowski: thanks!
[08:25] <mborzecki> mvo: in #7715 there's a check whether a base/kernel needsInstall, and otherwise it's just adding task set with link snap task, do you think we need to do the same for gadget snap?
[08:25] <mup> PR #7715: overlord: add base->base remodel undo tests and fixes <Priority 🏇> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>
[08:27] <mvo> mborzecki: its done this way so that the bootloader is updatd
[08:27] <mvo> mborzecki: link-snap is a bit overkill actually, all we really need there is just "set-next-boot"
[08:28] <mvo> mborzecki: we may want something similar for gadget but its much less important, for bases its quite common to go e.g. core18->core20 but having core20 already installed because its used by some app snaps
[08:29] <mborzecki> mvo: ok, so maybe there's a case missing after all, iirc snapstate.Install() errors out if the snap is already installed, so a remodel back to the old one when the old gadget snap is still around could fail?
[08:34] <mvo> mborzecki: correct
[08:34] <mvo> mborzecki: I think this is not terrible, a followup is ifne
[08:34] <mborzecki> mvo: rigth, so land 7665, 7715 and then a followup using some code from 7715
[08:34] <mvo> mborzecki: its really a corner case
[08:34] <mvo> mborzecki: correct
[08:34] <mborzecki> mvo: sgtm
[08:34] <mvo> mborzecki: cool
[09:08] <zyga> re
[09:10] <Chipaca> zyga: feeling better today?
[09:10] <zyga> Chipaca: I'll feel good if we can make the feature work
[09:10] <zyga> Chipaca: last evening was grim
[09:10] <zyga> but some light at the end of the tunnel
[09:10] <Chipaca> zyga: imagine if you'd found out after implementing the whole thing
[09:14] <mborzecki> Chipaca: and merging to master ;)
[09:16] <Chipaca> mborzecki: and then steal it again!
[09:17] <Chipaca> wait no that's https://www.youtube.com/watch?v=ALZZx1xmAzg
[09:25] <mborzecki> hahah
[09:28] <Chipaca> man lubuntu is *fast*
[09:42] <mup> PR snapd#7547 closed: many: use a dedicated named cgroup hierarchy for tracking <⛔ Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7547>
[09:45] <mborzecki> mvo:  can you cherry-pick to 5995e03cf8b2e34ef4327a6419922fe49d41332f ?
[09:45] <mborzecki> mvo: to 2.42 ofc :)
[09:48] <mborzecki> mvo: looks like we're missing the release artifacts for 2.42.1
[09:53] <mvo> mborzecki: oh, right, let me fix that
[09:53] <mvo> mborzecki: cherry-picked :)
[09:53] <mborzecki> mvo: thanks!
[10:03] <mvo> mborzecki: published, sorry for that
[10:03] <mborzecki> mvo: np, i can update the arch and fedora packges now
[10:05] <mvo> ta
[10:10] <mborzecki> need to run an errand, back online in 40 or so
[10:17]  * Chipaca not feeling too good today
[10:17] <zyga> take care Chipaca
[10:17] <Chipaca> i am :) thanks
[10:18]  * dot-tobias waves
[10:22] <Chipaca> eh, might as well do this mandatory training now
[10:24] <zyga> mvo: I discussed ideas with mborzecki
[10:29] <mvo> zyga: nice
[10:29] <zyga> mvo: the idea is to use a sub-directory of whatever cgroup is assigned by systemd
[10:29] <mup> PR snapd#7659 closed: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7659>
[10:31] <mvo> zyga: oh, that will work?
[10:31] <zyga> mvo: not for notification, but we can scan /proc and find out what we need in a loop
[10:32] <Chipaca> zyga: wrt xdg thing, ask also for non-issue
[10:32] <Chipaca> zyga: otherwise nobody trying it, and everybody trying it and finding no issues, looks the same :)
[10:32] <zyga> Chipaca: pardon, I don't follow
[10:32] <zyga> Chipaca: ah
[10:32] <zyga> I see
[10:32] <zyga> +1
[10:32] <zyga> good idea
[10:35] <zyga> my mind is blank but I'll do my best to implement it
[10:35] <zyga> it's more likely to succeed than the idea from last evening
[11:07] <mborzecki> re
[11:09] <mborzecki> pstolowski: thanks for the review, i'll be addressing your comments shortly
[11:10] <pstolowski> mborzecki: np, ping me for re-review
[11:13] <mborzecki> mvo: can you also cherry pick 08397513608150c6fd796ceb974557c0e19d6085 to 2.42?
[11:15] <mvo> mborzecki: yes, done
[11:15] <mvo> mborzecki: thank you!
[11:16] <mvo> pstolowski: thanks for the review of 7665!
[11:18] <ogra> zyga, hrm ... we should really have some kind of interface to allow this ... coyping files to home first is very annoying
[11:18] <pstolowski> yw
[11:18] <mborzecki> mvo: cool, thanks!
[11:19] <zyga> ogra: it'd be somewhat tricky to make since there's a bunch of special code to make sure you cannot read /home/*/snap/ using home
[11:21] <ogra> i mean, it is the first time i hit this and i can probably mke the arduino ide store to home but it kind of hinders productivity since snaps typically point to ~/snap/snapname/current for their default paths ... and i can imagine a lot of use cases where one snap uses data created by another
[11:23] <ogra> (i.e. creating graphics with the gimp snap that i want to use in a libreoffice presentation with the libreoffice snap ... forcing people to copy around the world for that wont really make us freinds among users :) )
[11:23] <dot-tobias> zyga, mvo, jdstrand: Re: https://github.com/snapcore/snapd/pull/7655 → Thanks for the 2.42.1 candidate, I tested my snap against the new version. Does the change also cover the post-refresh hook? When I run the code that requires the Introspectable interface from a plugged app, it works fine now. But when the same code is run during post-refresh, I still get the same AppArmor denial. network-manager is plugged in top-level > hooks >
[11:23] <dot-tobias>  post-refresh > plugs, and I also added a top-level “plugs” dict with `network-manager: {}` to no avail. Holding it wrong?
[11:23] <mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
[11:24] <zyga> dot-tobias: can you check the generated apparmor profile in /var/lib/snapd/apparmor/profiles/snap.$SNAP_NAME.hooks.post-refresh
[11:24] <zyga> and see if it has the introspection chunk
[11:24] <mvo> dot-tobias: I don't recall cherry-picking anything for post-refresh, its probably in edge only. if you tell me a git rev I can cherry pick in case we do a 2.42.2
[11:25] <zyga> mvo: it wasn't for post refresh, it was for network-manager introspection on dbus
[11:25] <mvo> dot-tobias: otherwise in the next stable release in ~4 weeks
[11:25] <zyga> mvo: I could find the patch number if you want
[11:25] <mvo> zyga: aha, sry, in any case, if anything needs cherry picking please let me know but only if its really important
[11:25] <zyga> mvo: 5bc7682f2ef572f074dd0764015358cbe139d35d
[11:25] <zyga> dot-tobias: note that it was made to only affect core
[11:26] <mvo> aha, right
[11:26] <mvo> thanks
[11:26] <mvo> well, if its really important I can cherry pick, otherwise its in 2.43 (its not clear we do a 2.42.2 at this point)
[11:26] <zyga> I didn't check if that's in a point release
[11:26] <mvo> pstolowski: while in the remodel review swing, maybe you can have a look at 7715?
[11:27] <zyga> I think it might but please check what's in the apparmor profile I mentioned first
[11:27] <mvo> pstolowski: it should be very similar in style to the gadget one you just reviewed :)
[11:30] <pstolowski> mvo: sure, will do
[11:31] <dot-tobias> zyga: https://paste.ubuntu.com/p/yJbVPHnXsX/ → apparmor profile seems to contain the necessary chunk for post-refresh. Note this is after I refreshed the snap from a local unsquashed FS via `snap try`, which had the part of its post-refresh hook disabled where Introspectable would be called.
[11:31] <zyga> dot-tobias: please don't use snap try for refresh-related hooks
[11:32] <zyga> they don't operate correctly
[11:32] <zyga> because snapd is confused by "before" and "after" being the same revision
[11:33] <dot-tobias> zyga: Testing on a Core device. Oh ok, would it suffice if I reset the snap to an older revision and then `snap try` the newer revision with the patched post-refresh hook? The older revision doesn't plug network-manager for the hook, so I don't know how to test otherwise.
[11:33] <zyga> dot-tobias: I think using snap try in testing the refresh hook is not useful
[11:33] <zyga> just snap pack the new version
[11:34] <dot-tobias> zyga: And then refresh from this local .snap file?
[11:35] <zyga> correct
[11:35] <dot-tobias> Will test, brb
[11:41] <dot-tobias> zyga: Nope, still the same AppArmor denial. I packed the modified version (changed meta/snap.yaml to include a top-level plug `network-manager: {}` and incremented version number) + installed via snap install. Relevant log entry: https://paste.ubuntu.com/p/HjC6pjcb8K/
[11:42] <zyga> dot-tobias: can you look at journalctl
[11:42] <zyga> dot-tobias: perhaps we run the hook before the profile of network-manager is updated?
[11:44] <zyga> dot-tobias: if so that would be a separate bug, which would be unfortunate
[11:46] <dot-tobias> zyga: What should I look for in journalctl specifically? When I search for the AppArmor denial, the lines above indicate that the network-manager profile *is* updated before: `Nov 05 12:37:29 localhost kernel: audit: type=1400 audit(1572953849.274:306): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.network-manager.networkmanager" pid=14712 comm="apparmor_parser"`
[11:46] <dot-tobias> (same for the other network-manager 3 profiles)
[11:57] <dot-tobias> zyga: So … I checked the AppArmor profile for NetworkManager itself and it seems that even if I plug network-manager for my post-refresh hook, the profile doesn't seem to be updated. I'll open a forum thread about this.
[11:57] <zyga> dot-tobias: re
[11:57] <zyga> sorry, watching some internal HR stuff
[11:58] <zyga> dot-tobias: so in journal - look at the *order* for the events where apparmor_parser is invoked
[11:58] <zyga> for the hook
[11:58] <zyga> and for the network-manager service
[11:58] <zyga> ok
[11:58] <zyga> looking
[11:58] <zyga> it's interesting because it says "same as current"
[11:59] <zyga> perhaps the bug is not fixed afer all
[11:59] <zyga> because network manager ought to get the permission to receive it
[12:00] <dot-tobias> no worries, appreciate all the help from your side 😊
[12:01] <dot-tobias> zyga: ^ and: I'm double-checking if I made a mistake, but what trips me up is that the Introspectable access works fine once my snap is refreshed (which only works when I disable the NM-related parts of my post-refresh hook, ofc).
[12:01] <zyga> dot-tobias: review the patch I sent for fixing this and check if there is anything that looks wrong
[12:01] <zyga> it should be symmetric
[12:06] <dot-tobias> zyga: You mean the two snippets in https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1R297 right? I'm writing up my test procedure and results, brb
[12:06] <mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
[12:06] <zyga> yes
[12:08] <pstolowski> Chipaca: hey, what's the status of https://bugs.launchpad.net/snapd/+bug/1660970 ?
[12:08] <mup> Bug #1660970: snap info could autocomplete against installed snaps <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1660970>
[12:09] <Chipaca> pstolowski: still in progress: snap run doesn't complete yet
[12:10] <Chipaca> pstolowski: I've got it tagged to reply in more detail when i can
[12:10] <Chipaca> pstolowski: (from zyga asking me(
[12:10] <Chipaca> ))
[12:11] <pstolowski> Chipaca: great, thanks
[12:25] <pstolowski> Chipaca: there is one other bug where zyga asked you for a status - https://bugs.launchpad.net/snapd/+bug/1750527
[12:25] <mup> Bug #1750527: dashboard does not validate text fields <review-tools:Fix Released by jdstrand> <Snapcraft:New> <snapd:In Progress by chipaca> <Snap Store:Fix Released by matiasb> <https://launchpad.net/bugs/1750527>
[12:30] <Chipaca> pstolowski: yep, also tagged
[12:30] <pstolowski> 👍
[12:33] <dot-tobias> zyga: https://paste.ubuntu.com/p/pq29pv6zK8/ → It seems to me that your hunch is right: the NetworkManager slot rule is not updated for the post-refresh hook
[12:33] <zyga> dot-tobias: that's interesting, if you disable and enable n-m (via snap disable/enable)
[12:33] <zyga> if so that's a serious bug
[12:34] <Chipaca> pstolowski: also the ellipsis in utf8 one
[12:35] <Chipaca> and the snapd on 1804 proxy settings one
[12:35] <zyga> mborzecki: question on the idea
[12:35] <zyga> mborzecki: can we use the unified hierarchy in v1
[12:35] <dot-tobias> zyga: snap disable n-m / enable n-m shows no change to the Introspectable chunks … (don't know if *that* is the serious bug or if it would update 😉 )
[12:35] <zyga> dot-tobias: that's not bad then, it's a regular bug then
[12:35] <zyga> dot-tobias: we should check why there's no snippet there though
[12:35] <zyga> one second please
[12:36] <dot-tobias> sure
[12:36] <zyga> mborzecki: the logic I have so far looks for non-v2 cgroup hierarchy that has name=systemd
[12:36] <zyga> mborzecki: but also supports the v2 nameless, controllerless one
[12:36] <zyga> but this other choice, id=0 one is always present as /sys/fs/cgroup/unified in v1 world
[12:36] <zyga> and we can put processes there
[12:37] <zyga> so... perhaps that's consistency?
[12:37] <zyga> (after all?)
[12:41] <mborzecki> zyga: id=0 (i.e. 0::/some/path) is actually v2 hierarchy
[12:41] <zyga> I know
[12:41] <mborzecki> zyga: so yeah, we can do it ;)
[12:41] <zyga> that's why I menitoned id
[12:41] <zyga> yeah
[12:41] <zyga> I will go for it
[12:41] <zyga> it's consistent and easier
[12:41] <zyga> and actually
[12:42] <mborzecki> zyga: double check on 14.04 if we still care
[12:42] <zyga> I don't know how to make use of the ID otherwise
[12:42] <zyga> the only other piece that references it is /proc/cgroups
[12:42] <mborzecki> zyga: 0 is reserved for v2 anywya
[12:42] <zyga> but from there it's hard to match to /proc/self/mountinfo
[12:42] <zyga> unless I need to match the ID to controller
[12:42] <zyga> and then consider anything with that controller viable
[12:42] <zyga> but I don't see any supporting evidence in the documentation
[12:42] <zyga> I will check 14.04 before proceeding
[12:43] <mborzecki> zyga: w8, why matching with data from /proc/self/mountinfo?
[12:43] <zyga> mborzecki: because you don't know where the cgroup is mounted
[12:43] <zyga> is might be /sys/fs/cgroup or /sys/fs/cgroup/unified
[12:43] <zyga> I know we can check for v1-v2 mode
[12:43] <zyga> but it'd be nicer if this was not so "based on assumption"
[12:44] <zyga> hmm, my nas is down (didn't power up after last power outage)
[12:44] <zyga> so my 14.04 image os off, I'll just spawn spread
[12:44] <mborzecki> zyga: duh, right
[12:45] <mborzecki> zyga: hm there's only one possible instance of v2 so just looking for mount of type cgroup2 will do
[12:45] <zyga> yes
[12:45] <zyga> that's why I want to do it
[12:45] <zyga> it's non-ambiguous
[12:45] <zyga> unlike v1
[12:45] <zyga> it also has one more property
[12:45] <zyga> we _could_ actually use the events file
[12:45] <mborzecki> haha
[12:45] <zyga> though I didn't think about how deeper yet
[12:45] <zyga> but we could
[12:45] <zyga> anyway
[12:45] <mborzecki> zyga: double check on 14.04 ;)
[12:45] <zyga> back to checking
[12:46] <zyga> I wish spread had -workers 1 or something
[12:46] <zyga> oh well
[12:46] <mborzecki> zyga: cachio's spread does
[12:46] <zyga> yeah but you know
[12:46] <zyga> ...
[12:46] <zyga> I only have one spread
[12:46] <mborzecki> spread-ng ;)
[12:48] <cachio> zyga, https://cachio.s3.amazonaws.com/spread/spread2
[12:48] <zyga> cachio: thanks!
[12:48] <zyga> cachio: any outlook for merging -workers 1 into spread?
[12:49] <cachio> zyga, you can use -workers 1 -order
[12:49] <cachio> to follow the specific order also
[12:49] <zyga> dot-tobias: let me know if you find out more please
[12:49] <zyga> cachio: right
[12:49] <cachio> zyga, there is a PR for this https://github.com/snapcore/spread/pull/79
[12:49] <mup> PR spread#79: New -workers option used to define the number of workers by system <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/79>
[12:50] <cachio> but not reviews yet
[12:50] <zyga> cachio: try pinging gustavo maybe
[12:50] <zyga> he's really receptive when pinged IMO
[12:50] <zyga> mborzecki: we're good,
[12:50] <zyga> mborzecki: 14.04 has it and it's full of stuff already (not barren)
[12:52] <dot-tobias> zyga: Will do, is there something specific I should test? Not quite sure where to start here. In any case, I'll put the tasks that post-refresh should do for my snap in a service startup; shouldn't be too much overhead to run them on each startup instead of once per refresh.
[12:52] <zyga> dot-tobias: I think the mystery is why n-m doesn't have the new snippet
[12:52] <zyga> dot-tobias: look at the patch and at the file, I don't know why it might not be present
[12:52] <zyga> maybe our assumptions are wrong somehow?
[12:55] <dot-tobias> zyga: Slightly of my depth on this (should become my motto here …) 😄 As a starter, how is ###PLUG_SECURITY_TAGS### generated in https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1R312 ?
[12:55] <mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
[12:56] <zyga> dot-tobias: it's generated in the line above, hidden in the diff: https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1L480
[12:57] <zyga> that returns a string that describes the labels of all plugs connected to the slot
[12:59] <dot-tobias> I'm assuming the profile for n-m is only updated if there are new rules, and if my snap's post-refresh hook is somehow not recognized by the plugAppLabelExpr helper, it won't be included there?
[13:00] <dot-tobias> https://github.com/snapcore/snapd/blob/aebfc2b83d7ac3ec49ff6811ddf8bc8c4c93b92d/interfaces/builtin/utils.go#L73 → would plug.Apps() also return hooks?
[13:01] <zyga> dot-tobias: the profile is generated in memory and reloaded if it changes; we even reload them if they don't change for a specific reason, this is why you saw the message that profile was the same as before
[13:02] <zyga> dot-tobias: yes, that's correct
[13:02] <zyga> plug.Apps would not return hooks
[13:02] <zyga> perhaps that is the bug?!
[13:02] <zyga> that's cool
[13:02] <zyga> that's the bug IMO
[13:03] <dot-tobias> zyga: A shy “yes … maybe??” from me 😄
[13:03] <zyga> pstolowski: ^
[13:03] <zyga> dot-tobias: can you add that the the existing bug or open a new one
[13:03] <zyga> I think it's unfortunate for you but this is should be easy to address
[13:03] <zyga> but on the up side, now that it is know it can be fixed, otherwise the next release would be equally buggy
[13:04] <zyga> dot-tobias: thank you! you nailed it
[13:04] <dot-tobias> Hey, happy to help out once instead of just receiving help 😊 I'll open a new bug since this probably affects all hooks, brb
[13:06] <zyga> yes, I think a new bug is more appropriate
[13:06] <pstolowski> zyga: why should Apps return hooks too?
[13:06] <zyga> they should not
[13:07] <zyga> but the label ought to include hooks too
[13:07] <zyga> using slotAppLabelExpr is just wrong
[13:07] <zyga> it ought to say slotAppOrHookLabel(slot)
[13:07] <zyga> because why would we refuse to allow hooks to have those permissions?
[13:07] <dot-tobias> zyga: That might also explain why my connect-plug-network-manager hook kept failing with similar AppArmor denials for n-m:service, even though that's the whole point of connect-plug-* hooks 😄
[13:08] <zyga> oops /o\
[13:08] <zyga> thank you for catching that!
[13:08] <zyga> and I'm sorry for not writing a spread test
[13:08] <zyga> it would show this
[13:09] <zyga> mborzecki: offtopic, I learned to love #pragma once
[13:09] <zyga> every production toolchain supports it
[13:09] <zyga> and it's far less silly than the ifndef approach
[13:09] <zyga> no need to invent names
[13:10] <pstolowski> zyga: i see
[13:11]  * pstolowski school run, bbiab
[13:11] <dot-tobias> zyga: No worries, you people have so much on your plate with the snap ecosystem … there's always some workflow to improve, and resources are constrained. Happy to help 😊
[13:11] <zyga> dot-tobias: I'll gladly help you fix this if you want to
[13:12] <mborzecki> pstolowski: pushed fixes to https://github.com/snapcore/snapd/pull/7665
[13:12] <mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Priority 🏇> <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
[13:12] <dot-tobias> zyga: Very much wanted, because I'd probably overlook some helper or introduce even worse bugs 😄
[13:13] <zyga> dot-tobias: expand AppLabelExpr to take a map of hooks as well
[13:13] <zyga> the rest is a consequence of that
[13:14] <zyga> adjust names of the functions to convey the fact that it is not just apps now
[13:14] <zyga> I think this bug is silly
[13:14] <zyga> it's an old design that we lifted
[13:14] <zyga> but buggily so
[13:14] <zyga> we designed it so that hooks could not have interfaces initially, not all of them
[13:14] <zyga> I think we never noticed when this restriction went away
[13:14] <zyga> that the label expression is only for apps
[13:14] <zyga> there's some tricky code in that function
[13:14] <zyga> as it tries to produce nicer output than brute force
[13:15] <zyga> my suggestion would be to cahng it so that it considers not hooks or apps
[13:15] <zyga> but just a slice of names
[13:15] <zyga> whatever they are
[13:15] <zyga> and have the names be a concatenation of app labels and hook labels
[13:15] <dot-tobias> “apps” in that context are apps + services in snapcraft lingo?
[13:16] <zyga> dot-tobias: there are no tests for appLabelExpr so I would suggest to start with that
[13:16] <mborzecki> ok, moving back home
[13:16] <zyga> just create a test that checks the label for the current code
[13:16] <zyga> dot-tobias: yes, apps are all apps, equally
[13:16] <zyga> services are just certain apps
[13:16] <zyga> dot-tobias: there is code that tests this indirectly
[13:16] <dot-tobias> zyga: Ok, I'll install go, set up snapd locally and then get back to you in a week or two 😉
[13:17] <zyga> but a direct test that generates snap.pkg.*, snap.pkg.{app1,app2} and snap.pkg.app3 as output would be good
[13:17] <zyga> as those are all the variants the current logic handles
[13:17] <zyga> dot-tobias: let us know if you need help but I think this is fairly nicely scoped
[13:18] <zyga> dot-tobias: you can build a new function, move code over from the old function, remove the old function in stages
[13:18] <dot-tobias> zyga: Will do. I have some spare time atm, so this should be a nice way to a) contribute code and b) learn something new
[13:18] <zyga> dot-tobias: this definitely affects lots of interfaces, just git grep AppLabelExpr
[13:19] <dot-tobias> zyga: Would you recommend setting things up directly on a Ubuntu host, or can I use my main macOS env to develop?
[13:19] <zyga> dot-tobias: linux is strongly recommended, you will have issues as our code has many parts that only build on linux
[13:19] <zyga> dot-tobias: personally I use vmware fusion
[13:20] <zyga> dot-tobias: as for the host, any linux will do really
[13:20] <zyga> dot-tobias: for this sort of change at least
[13:20] <dot-tobias> zyga: thought so, check. Ok, I'll start with completing the bug report 😄
[13:26] <zyga> uh
[13:26] <zyga> found an issue
[13:26] <zyga> but I'll wait for maciek
[13:31] <dot-tobias> zyga: ^ does this relate to the issue we discussed, or sth else?
[13:31] <zyga> no no
[13:31] <zyga> it's for the cgroup thing
[13:31] <dot-tobias> 👍
[13:35] <zyga> mvo: I'll run the new plan by stgraber and xnox today
[13:35] <zyga> maybe to avoid and learn from the last experience?
[13:35]  * zyga needs a break
[13:35] <zyga> see you all at the standup
[13:53] <mvo> zyga: cool, thanks for chasing this
[14:04] <xnox> mvo:  so.... model assertions
[14:05] <xnox> mvo:  $ snap known --remote model series=20 model="ubuntu-core-20-amd64" brand-id=canonical
[14:05] <mvo> xnox: in a meeting
[14:05] <xnox> tells me that none are found =)
[14:05] <mvo> xnox: right, will reply in a wee bit
[14:05] <xnox> who should i talk to, about making a core20 pc-kernel model? =)
[14:05] <xnox> ack
[14:10] <mvo> xnox: you can try https://paste.ubuntu.com/p/DpZ2c3y4h9/ ?
[14:11] <mvo> xnox: its "my" model, not the canocnial one yet
[14:11] <mvo> xnox: but I get error: cannot use gadget snap because its base "" is different from model base "core20" with that so I need to look
[14:11] <mvo> xnox: either pc is not quite right (the snap) or something else, haven't had time yet to dig (meeting)
[14:28] <xnox> mvo:  why is it series=16?
[14:28] <mvo> xnox: loooooong story
[14:28] <xnox> mvo:  would be nice to be series 20 and make that the default track
[14:29] <xnox> mvo:  why is there no snapd snap listed?
[14:29] <mvo> xnox: the "series" is about the "format" of the entire architecture of snaps
[14:29] <xnox> mvo:  how does one specify to use "edge"?
[14:29] <mvo> xnox: its implicit, I guess we could/should make it explicit though
[14:29] <mvo> xnox: ubuntu-image --channel=edge
[14:29] <mvo> xnox: that should work
[14:29] <xnox> ok
[14:30] <mvo> xnox: I got further, my image creation is now exploding that "dangerous" is not yet supported
[14:30] <xnox> mvo:  how does one create model assertions?
[14:30]  * xnox wants to play with this stuff
[14:30] <xnox> mvo:  also do we have git models committed anywhere? or is it simply in the store?
[14:31] <mvo> xnox: use https://paste.ubuntu.com/p/VfkNwGQCHK/ as input, modify brand-id and then run snap sign
[14:31] <xnox> mvo:  ack
[14:31] <mvo> xnox: there is a doc that describes this, still in a meeting so can give you only 15% of my attention
[14:31]  * xnox ponders to commit them into the pc gadget git repo, on respective branches
[14:37] <xnox> i am confused what are the magic values of like authority-id brand-id id
[14:38] <mvo> xnox: its in your account page
[14:38] <xnox> ack
[14:38] <mvo> xnox: meeting over, now you can have more attention :)
[14:38] <mvo> xnox: https://dashboard.snapcraft.io/dev/account/
[14:38] <mvo> xnox: there is the accound-id there
[14:39] <mvo> xnox: use that for brandh-id, authority-id
[14:40] <xnox> mvo:  ok, and ids on snaps? is that the unique ids of the snaps, in addition to just their name?
[14:40] <Chipaca> xnox: snap info --verbose will show you the snap id
[14:40] <mvo> xnox: correct, snap info --verbose <name> will give you those
[14:42] <xnox> mvo:  can timestamp be in the future? we should set it to 2020-04-23T20:04:00:00.0Z
[14:42] <mvo> xnox: not sure that this will work
[14:43] <xnox> mvo:  because you think hardware clocks have real time?! that's just silly.
[14:45] <xnox> mvo:  grade dangerous is invalid, no? it's called "devel"
[14:53] <mvo> xnox: that sounds slightly outdated, let me try to find where this was written down but I can point you to the code. its "unset", "secured", "signed" and "dangerous" there
[14:53] <xnox> mvo:  i find it extremly odd to use key "grade" in both model & snapcraft, with widely different meaning and values.
[14:54] <mvo> xnox: https://github.com/snapcore/snapd/blob/master/asserts/model.go#L320
[14:54] <mvo> xnox: right, unfortunately samuele is on vac, that's a topic for him
[14:54] <xnox> mvo:  then it should be called like model-grade, not just grade =/
[14:56] <xnox> mvo:  imho we should be able to build "signed" one today, no need for "dangerous"
[14:56] <mvo> xnox: yeah, if you feel strongly, please mail samuele to discuss this, I don't think its set in stone but it will get harder to change the closer we get :)
[14:57] <xnox> mvo:  also, this implies we will have two models, and two images for core20 => with and without tpm-fde? but current working assumption is that a single image can be both.
[14:58] <xnox> i.e. "signed" should be allowed to be "secured", wheres as "secured" should not be. Ie. "signed" should be a superset of "secured", and ditto "signed" and "dangerous" should be supersets of previous one.
[14:58] <xnox> i.e. it's totally fine to have "dangerous" one effectively running as "secured" if all pieces work.
[14:59] <mvo> xnox: dangerous can still have fde, it just allows to sideload stuff, or am I misunderstanding?
[14:59] <mvo> xnox: also, my next meeting starts now ./ so back to 15% of my attention for you
[14:59] <mvo> xnox: sorry!
[15:02] <roadmr> ETOOMANYMEETINGS? 🤔
[15:05] <xnox> snap sign cannot do GPG it seems.... it cannot find a key named "default" wtf?!
[15:05]  * xnox uses a smartcard
[15:09] <mborzeck1> cmatsuoka: some comments under #7687
[15:09] <mup> PR #7687: snap-bootstrap: check gadget versus disk partitions <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7687>
[15:11] <kjackal> hey snappy people, in a classic snap, when I use sudo, should i use the "sudo" binary of core?
[15:14] <xnox> kjackal:  you should simply use sudo, with PATH discovery. ie. just "sudo" not any absolute path.
[15:14] <kjackal> I see MicroK8s in Centos 8.0 and fedora 29 failing when using sudo and I am wondering if I should package sudo or use the host's, or use the core's
[15:14] <xnox> note sudo is not universal, and is not guaranteed to be installed, or usable.
[15:15] <xnox> one might be root already, then no sudo should be needed, etc.
[15:15] <kjackal> xnox: this is the error I am getting https://forum.snapcraft.io/t/pam-account-management-error/14026
[15:16] <xnox> kjackal:  some of it, looks like a broken core snap
[15:16] <kjackal> in my case sudo is available but the libraries are not in the right places (?)
[15:17] <xnox> or rather mixed up LD configuration / overrides / preloads, ie. system pam is used with libraries from a core snap, which will never work =)
[15:18] <xnox> kjackal:  i wonder if environment that snap setup for you, is interfering with using system PAM session correctly
[15:18] <zyga> Back home now
[15:20] <kjackal> xnox: I am setting some env variables here: https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/wrappers/microk8s-enable.wrapper#L4 could these be a problem?
[15:20]  * cachio afk
[15:20]  * cachio lunch
[15:32] <xnox> kjackal:  yes, all of them.
[15:32] <xnox> kjackal:  these are good, for using binaries from inside the snap, but bad if one tries to dlopen system installed ones (like pam does for pam modules which dlopen things)
[15:33] <kjackal> xnox: but i am doing for example "sudo <something_in_my_snap>" so... ?
[15:34] <xnox> kjackal:  which is operating sudo itself with those environment variables in effect. which is bombing out.
[15:35] <xnox> because sudo, tries to open a pam session, as per system wide config, loads pam modules from the system-wide, yet with LD_ path pointing inside the snap which is incompatible with with system-wide libraries
[15:36] <xnox> kjackal:  store and export original path, ie. with export STOCK_PATH=$PATH ditto for STOCK LD_LIBRARY_PATH
[15:36] <xnox> kjackal:  and i expect something like this will work:
[15:36] <xnox> PATH=$STOCK_PATH LD_LIBRARY_PATH=$STOCK_LD_LIBRARY_PATH sudo PATH=$PATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH sed -i
[15:37] <xnox> kjackal:  ie. use system wide sudo, with system-wide PATH & LD_LIBRARY_PATH, but use snap paths for sed.
[15:37] <xnox> although imho one can rely on system sed too, as it's fundamental too.
[15:37] <xnox> although imho one can rely on system sed too, as it's fundamental tool.
[15:37] <kjackal> I see, will try that
[15:38] <kjackal> thank you xnox
[15:38] <xnox> kjackal:  your problem is that one cannot really create and use pam session from inside a snap, and expect it to work with the system-wide pam config. Meaning one has to use system-wide sudo
[15:38] <xnox> because all of those things use absolute paths to dlopen() libraries which all must match.
[15:39] <xnox> it "works" by magic on like Ubuntu due to e.g. snap build on xenial, and libraries staying compatible for basic things like that
[15:39] <xnox> (i.e. when host == snap abi's by accident)
[15:40] <xnox> kjackal:  also note that i have no idea what i'm talking about and i'm jsut a random person on irc who has zero idea about how snaps work =)
[15:41] <kjackal> :)
[15:43] <mborzecki> snapd in AUR has been updated to 2.42.1
[15:43]  * mvo hugs mborzecki 
[15:47] <pstolowski> spread tests in #7715 and #7665 are very alike, i'm not sure who was first ;) fwtw i'm adding same comments ;)
[15:47] <mup> PR #7715: overlord: add base->base remodel undo tests and fixes <Priority 🏇> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>
[15:47] <mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Priority 🏇> <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
[15:51] <xnox> mvo:  error: cannot override channels, add local snaps or extra snaps with a model of grade higher than dangerous
[15:52] <xnox> mvo:  hm..... prepare-image fails..... but i'm confused about these constraints. How do I build image of a model, using edge channels? model doesn't allow to specify channel does it?
[15:52] <mvo> xnox: yeah, I hit this too, I'm looking into it
[15:52] <mvo> xnox: basicly we need to land one more PR (7712
[15:53] <mvo> xnox: then we can have a "grade: dangerous" model that allows overriding
[15:53] <mvo> xnox: I was also looking into: https://paste.ubuntu.com/p/5bhBPMvVJj/
[15:53] <mvo> xnox: but that fails with a strange error, that it can't find core20 which I think is a lie
[15:54] <pstolowski> mvo: reviewed #7715
[15:54] <mup> PR #7715: overlord: add base->base remodel undo tests and fixes <Priority 🏇> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>
[15:54] <xnox> mvo:  hm.... i'm not sure if that's what i am hitting..... because all the snaps i'm using are acked and in store. I'm not using any unsigned, or unasserted snaps
[15:55] <mvo> xnox: you did specify --channel=edge, maybe?
[15:55] <mvo> pstolowski: cool, will look
[15:55]  * mvo needs to taxi kids around for ~30min
[15:55] <mvo> bbiab
[15:57] <xnox> for me it's fetching the wrong gadget snap!
[15:58] <zyga> re again
[15:58]  * zyga had dinner and an unexpected encounter
[15:59] <zyga> my neighbor was venting old stuff and asked me if ... I want any of his 90s games collection
[15:59] <zyga> so now I have a CD-ROM with dungeon master 2
[15:59] <zyga> and a few similar games
[15:59] <zyga> anyway
[15:59] <zyga> back to work
[15:59] <zyga> xnox: hey
[16:00] <zyga> xnox: we have an idea and before pursuing further wanted to ask you for advice
[16:00] <zyga> xnox: it is related to systemd and cgroups
[16:00] <zyga> xnox: the idea is: when snaps are invoked they put themselves into a new leaf under wherever systemd had placed them
[16:00] <zyga> xnox: in the unified v2 hierarchy
[16:01] <zyga> xnox: so for example, on /user.slice/user-1000.slice/user@100.service/snap.pkg.app
[16:01] <zyga> xnox: or something equally appropriate for system services
[16:01] <zyga> xnox: we'd be stealing the process from systemd
[16:01] <zyga> xnox: but placing it deeper in the same hierarchy
[16:02] <zyga> xnox: casual testing shows that systemd is not confused and still manages services correctly
[16:03] <zyga> xnox: we intend to use the unified hierarchy in v2 mode, obviously, because we have no other choice
[16:03] <zyga> xnox: but also in the v1 mode
[16:03] <zyga> xnox: because it is seemingly working the same way for what we intend (associating PIDs with snaps)
[16:04] <xnox> so i have this https://bugs.launchpad.net/snapd/+bug/1851401
[16:04] <mup> Bug #1851401: snap prepare-image downloads wrong snaps <snapd:New> <https://launchpad.net/bugs/1851401>
[16:07] <xnox> zyga:  "when snaps are invoked they put themselves into a new leaf under wherever systemd had placed them"  using children, and further scoping is always safe. Moving "up" is usually either not-allowed, or is a priviledged operation. Systemd should not get confused, as long as you don't change notification agents on it. And yes it should be fine under v1/v2/hybrid. BTW why do you want to do this?
[16:07] <xnox> i.e. what are you trying to solve?
[16:07] <zyga> xnox: that's good news
[16:07] <zyga> xnox: we want this to implement a feature where snapd pauses refreshes while an app is open
[16:08] <xnox> that's insecure and abusable.
[16:08] <zyga> xnox: and can, having tried to refresh but deciding not to
[16:08] <xnox> as unpriviledged user can create those cgroups and put arbitrary processes into them.
[16:08] <zyga> xnox: then decide to refresh it reasonably fast after it was closed
[16:08] <zyga> xnox: that's ok, we have safeguards for that
[16:08] <zyga> xnox: that is, firefox running forever in a snap will eventually referesh anyway
[16:08] <zyga> *refresh
[16:09] <xnox> i.e. you could make binaries be "systemd-run actual binary" cause then pid1 will put the process into a system cgroup, which is authoritative.
[16:09] <zyga> xnox: we considered that but we don't have systemd-run across all versions we support
[16:10] <zyga> xnox: but it's also a problem there
[16:10] <zyga> xnox: because we want to have this available uniformly across all apps
[16:10] <zyga> xnox: including services
[16:10] <zyga> xnox: and using systemd-run from inside what is effectively a service file with Exec line
[16:11] <xnox> zyga:  you do have sytemd-run everywhere.... given that it's in core16
[16:11] <zyga> xnox: we are at the mercy of what systemd allows us to do here sadly, as snaps need to integrate with existing system services and be managed by systemd directly
[16:11] <xnox> zyga:  you don't need systemd-run for services, as pid1 already placed them into an authoritative cgroup
[16:11] <zyga> xnox: I think we don't have that on 14.04
[16:11] <zyga> xnox: but even then the other problem is more severe
[16:11] <zyga> xnox: "apache", "firefox" and "grep" type workloads need to be supported in this mode
[16:11] <xnox> zyga:  systemd-run is inside core snap, and on 14.04 it runs against subordinate systemd which has it.....
[16:12] <zyga> xnox: I see but core is not mandatory and it would also complicate startup, what if you install a snap with bare base on 14.04?
[16:12] <xnox> zyga:  if you only do this for "user" apps, that's fine. I.e. i don't want to hold up daemon refreshes, due to unpriviledged user controlled cgroups.
[16:13] <zyga> xnox: we want this to work uniformly for all applications but there's some smarts for services
[16:13] <xnox> i.e. somebody executing "snap --help" and freezing it, should not prevent snapd refresh for example
[16:13] <zyga> xnox: snap --help won't prevent snapd from refreshing
[16:13] <xnox> zyga:  it's insecure, thus you must have security team review / signoff on this logic.
[16:14] <zyga> xnox: can you specify what is insecure specifically
[16:14] <zyga> xnox: (we always get security review for features like that)
[16:14] <xnox> zyga: arbittrary users can create the cgroups like /user.slice/user-1000.slice/user@100.service/snap.pkg.app which have never been executed via snap/snapd
[16:15] <xnox> with zombie /bin/true process
[16:15] <zyga> indeed, this is true
[16:15] <zyga> xnox: at this point we ran out of ideas for things that work across the stack unfortunately
[16:16] <xnox> you could use kernel keyrign to list snap invocation_ids which is read only, to then lock that up. Cause that's what e.g. systemd-run does
[16:16] <zyga> xnox: users don't have to be nasty, they can just run the real app
[16:16] <zyga> xnox: so it is not a new problem of the feature
[16:16] <xnox> zyga:  also i challenge you on the 14.04 assertion, i believe systemd-run is available there.
[16:16] <zyga> xnox: invocation IDs?
[16:17] <xnox> systemd creates process keyring and puts a unique key there and makes it readonly and exports it as an evironment variable. Then processes can share that keyring (ie. group of services) and then they can all know that they are part of the same "reexec" for example. Kind of like a cohort key.
[16:18] <xnox> but with kernel protection that nobody can modify or fake it
[16:18] <zyga> xnox: interesting, which syscalls govern that? I'll read about it
[16:18] <zyga> xnox: and do you know if this will work inside LXD
[16:18] <zyga> xnox: as whatever we need to do needs to work in lxd across the stack
[16:18] <xnox> it does work in lxd today, but i don't remeber when it was added.
[16:18] <zyga> (we are in this situation after we realized mounting a v1 name=snapd cgroup doesn't work)
[16:18] <xnox> zyga:  why do you care about 14.04?
[16:19] <zyga> xnox: it's still supported, we cannot abandon it without some official kick
[16:19] <zyga> xnox: but I would not hold onto 14.04
[16:19] <zyga> xnox: it's just that systemd-run doesn't do what we want to AFAIK
[16:19] <xnox> zyga:  it's passed end of basic support, and excludes support for snapd in ESM
[16:19] <zyga> xnox: unless I misunderstand
[16:19] <xnox> zyga:  it's dead to you
[16:20] <xnox> and i.e. subordinate systemd is not supported there for sure.
[16:20] <zyga> xnox: I need mvo to tell me that, I asked recently and I got a different answer
[16:20] <xnox> mvo
[16:20] <xnox> not in this channel
[16:20] <zyga> it seems he is not connected now
[16:20] <zyga> xnox: but even assuming we can run systemd-run
[16:20] <zyga> xnox: can you outline how we could use that to identify all snap execution entry points?
[16:21] <zyga> that is, all apps, hooks and services
[16:21] <zyga> so that when scanning PIDs
[16:21] <zyga> we can see where they came from
[16:21] <xnox> zyga:  and 14.04 is very unconfined, as far as i understand. i.e. most interesting interfaces are not supported on 14.04 anyway.
[16:21] <zyga> xnox: I think actually only fuse is not, everything else is not special cased on 14.04
[16:21] <zyga> it's not supported for desktop apps but that is all
[16:22] <xnox> vorlon:  what's status of supporting snapd on 14.04? i thought it's dead and not part of ESM.
[16:23] <zyga> xnox: so would snap-run invoke systemd-run which would invoke snap-confine and then snap-exec?
[16:23] <vorlon> xnox: I don't know why you had that impression; you should look to the Security Team for a specific support statement, but I'd be surprised if snapd wasn't in scope
[16:23] <zyga> I suspect that the nature of ESM is that it's too soon to say something is not supported
[16:24] <zyga> the policy in snapd team, for now, as far as I know, is that 14.04 is still a target
[16:24] <xnox> zyga:  imho that call chain "makes sense" but potentially breaks a lot of desktop integration, unless one is careful to do --user / --system for the systemd-run bit.
[16:24] <zyga> and we are not introducing features that don't support it
[16:25] <zyga> xnox: can you walk me through the operations of systemd-run, what do we get by using it and how should we invoke it?
[16:25] <xnox> zyga:  i'm very busy, and i've spend too much time talking to you already. So no, i don't. plese read man pages for systemd-run, they have a lot of details.
[16:26] <zyga> xnox: I will, thank you for the advice and for the discussion, it's very useful
[16:27] <zyga> xnox: I don't think we can use systemd-run
[16:27] <zyga> xnox: based on the man page itself
[16:27] <xnox> vorlon:  zyga: snapd is explicitely called out as an exclusion for 14.04 ESM that's where i got this impression from https://wiki.ubuntu.com/SecurityTeam/ESM/14.04#Exclusions
[16:27] <zyga> xnox: but we should be able to use the cgroup sub-directort leaf
[16:28] <xnox> zyga:  it starts an invocation, as a dynamic .service unit. meaning one can query it with systemctl list-units snapd-execs.* for example
[16:28] <xnox> and it can like prevent user from having two copies of the thing running in parallel, etc.
[16:29] <zyga> yes, but it doesn't give me a way to run a classic snap this way, e.g. a classic installation of python, to get interactive pty
[16:29] <vorlon> xnox: well, if it's published as an exclusion, there's your answer :-)
[16:29] <zyga> it needs to support all the kinds of interactions snap apps support: desktop apps, services and all the command line stuff, including classic snaps
[16:29] <xnox> mostly useful to start "dynamic" things but monitored, i.e. executing user-written hooks, which can be arbitrary long, with journald logging, confiment, etc.
[16:30] <xnox> it does break the scope & confiment, even basic things like "what is my stdin"
[16:30] <zyga> yeah, so while we could use it for services, for services arguably systemd is already giving us all of that already
[16:30] <zyga> I think it will also be a less invasive change
[16:30] <zyga> I'm very curious about the keyring operation
[16:30] <zyga> as that seems like a way out of the too-easy-to-spoof problem
[16:31] <xnox> zyga:  start with keyctl manpage about kernel keyring, and invocation_id stuff inside systemd
[16:31] <zyga> though it doesn't really solve the problem as you can just run the real thing (real snap app) and not close it for the same effect
[16:32] <zyga> it seems like a potentially interesting replacement for the snap cookie concept though
[16:32] <zyga> but I need to read on it more now
[16:32]  * zyga hugs xnox 
[16:32] <zyga> thank you :)
[16:40]  * cachio afk
[16:55]  * ijohnson hugs zyga after reading backlog
[16:55] <zyga> ijohnson: what specifically? :
[16:55] <zyga> :)
[16:55] <ijohnson> the many changes to refresh awareness, sounds like quite a rollercoaster
[16:55] <zyga> ijohnson: the only question is
[16:56] <zyga> ijohnson: is it still going up or are we already going down? ;)
[16:56] <zyga> but yeah, it's quite a feature
[16:56] <ijohnson> haha :-)
[16:57]  * ijohnson is not really around today, still in Arizona for meetings
[16:57]  * ogra waits for the time where the snapd snap is bigger than his kernel snaps on core images
[16:58]  * ijohnson quietly shoves edgex snap inside snapd to get ogra to stop waiting
[16:58] <ogra> haha
[16:59] <ogra> ijohnson, reading that ... we'll need to talk about edgex before EOM ... (got another exhibition and we want to shw edgex finally)
[16:59] <ogra> the setup doc we have seems outdated
[16:59] <ijohnson> sure that doc is probably out of date, but let's try to keep Tony and Don in the loop too
[16:59] <ijohnson> ogra: when is your exhibition?
[17:00] <ogra> last week of nov.
[17:00] <ogra> (i think at least ... /me checks)
[17:01] <ogra> yeah, 26 to 28 https://sps.mesago.com/nuernberg/en.html
[17:05] <ijohnson> ogra: ack are you going to be in vancouver next week for the sprint?
[17:11] <zyga> ogra: we will link everything into one binary so that it can stay at comfortable 20MBs forever
[17:11] <zyga> mvo: heye
[17:11] <zyga> mvo: you missed some nice discussion about systemd stuff with xnox
[17:12] <zyga> mvo: I think I will wrap it for today
[17:12] <zyga> mvo: the big takeaway is that xnox effectively confirmed that the idea from Maciek is workable
[17:12] <zyga> mvo: he also raised a number of important points for us to discuss
[17:12] <zyga> mvo: but I will try to propose the branch implementing this tomorrow
[17:13] <xnox> mvo:  everything is broken and nothing works, but i made progress!
[17:14] <mvo> hey zyga
[17:14] <zyga> mvo: hey :)
[17:15] <mvo> xnox: ha!
[17:15] <mvo> zyga: cool
[17:15] <mvo> xnox: I think we have a bug in the core20 getting
[17:15] <mvo> xnox: what kind of progress did you made?
[17:16] <mvo> xnox: the pending PR#7712 should make everything easier, I will review it tomorrow morning
[17:22] <xnox> mvo:  see email from me. if that PR helps that's great, will try that if/when it's available to me in a track/grade/branch to me
[17:22] <xnox> mvo:  some things i can work around with, by like passing locally downloaded snaps etc. but other things seem broken - i.e. ubuntu-image doesn't do anything for me.
[17:23] <mvo> xnox: aha, nice
[17:23] <mvo> xnox: got the mail now
[17:23] <xnox> mvo:  and i question some design choices in the model assertion, which i guess i need to type up and send.
[17:31] <zyga> I'm wrapping up
[17:32] <ogra> ijohnson, no vancouver for me ...
[17:32] <ijohnson> ogra: cool maybe we could setup a hangout early next week then
[17:33] <ogra> yeah, that sounds fine
[17:59] <Chipaca> ok, EOD for me
[17:59] <Chipaca> 👋
[18:48] <mup> PR snapd#7720 opened: asserts: add "snapd" type to valid types in the model assertion <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7720>
[21:04] <mup> PR snapcraft#2792 opened: pluginhandler: use well-formed build package/snap lists <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2792>
[21:10] <mup> PR snapcraft#2793 opened: tests: enable SNAPCRAFT_BUILD_INFO for spread <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2793>