[00:31] <mup> PR snapcraft#2764 closed: Snapd doesn't actually honor the slot specified in the default-provider <Created by kenvandine> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2764>
[05:24] <mvo> hey mbo
[05:36] <mborzecki> morning
[05:38] <mvo> hey mborzecki
[05:39] <mborzecki> mvo: PRs still red?
[05:39] <mvo> mborzecki: looks better today
[05:39] <mvo> mborzecki: at least the one from zyga 7h ago is green
[05:40] <mborzecki> wth https://github.com/snapcore/snapd/pull/7647 has pending build status, but when you go to the details page it's actually green
[05:40] <mup> PR #7647: gadget: skip structures with MBR role during remodel <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7647>
[05:41] <mvo> mborzecki: oh no
[05:41] <mborzecki> mvo: i've restated the cla check job, maybe it's enough to switch the status :/
[05:42] <mvo> mborzecki: the cla job is not finished
[05:42] <mvo> mborzecki: which is slightly strange
[05:42] <mvo> mborzecki: I can cancel and restart?
[05:42] <mborzecki> mvo: restarted it just now intentionally
[05:42] <mvo> mborzecki: aha, ok
[05:43] <mborzecki> mvo: all the other jobs were green, and cla runs are shortest, hope that when it completes travis will report the status back to gh
[05:43] <mvo> mborzecki: right, makes sense. if not, I will just merge and override the missing check
[06:02] <mup> PR snapd#7647 closed: gadget: skip structures with MBR role during remodel <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7647>
[06:16] <mup> PR snapd#7657 closed: snap: fix default-provider in seed validation <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7657>
[06:20] <zyga> hey
[06:21] <zyga> mborzecki: the secret for green spread PRs is to open them at 1AM
[06:21] <zyga> spread has logic for that
[06:21] <zyga> really ;)
[06:21] <zyga> juts look at 1AM and you will see it
[06:21] <mborzecki> zyga: i.e. switch timezones then
[06:21] <mborzecki> zyga: and hey :)
[06:21]  * zyga had a horrible horrible night
[06:22] <zyga> Janek decided to sleep in our bed and we couldn't convince him otherwise
[06:22] <zyga> and that's just not enough space
[06:22] <zyga> my whole body hurts
[06:22] <zyga> mvo: I found a curious bug
[06:22] <zyga> I discussed it with jamie a little
[06:22] <zyga> but I couldn't convince him at the time
[06:23] <zyga> mvo: I opened a thread about it to discuss it https://forum.snapcraft.io/t/classic-confinement-breaks-high-dpi-support/13868
[06:23] <zyga> mvo: I think the bug is more serious for non-x-wayland sockets because it is likely that classic software is broken and unable to open files it expects
[06:24] <jamesh> Ideally we wouldn't change XDG_RUNTIME_DIR for confined snaps either...
[06:24] <zyga> by applying the attached fix all my snap apps are non-blurry now
[06:24] <zyga> jamesh: I tend to agree, after all we have apparmor for confinement
[06:25] <zyga> jamesh: I think jamie wanted to do this (set it to a custom value) to support things like instances
[06:25] <zyga> but I don't know if that is sensible, how are apps expected to talk to each other?
[06:25] <zyga> hey jamesh :-)
[06:25] <jamesh> zyga: by that I mean mounting something over /run/user/$UID for strict confinement, with bind mounts of wayland, dbus, pulse sockets
[06:26] <zyga> jamesh: mhm
[06:26] <zyga> jamesh: for strict apps that's sensible IMO
[06:26] <zyga> jamesh: especially that we can "recover" those socktes via hostfs
[06:26] <mvo> zyga: is this 7659 ?
[06:26] <zyga> jamesh: so even regular mount backend code would make it work
[06:26] <zyga> mvo: yes
[06:27] <mvo> zyga: aha, I see
[06:27] <zyga> actually using wayland, snaps on the desktop
[06:27] <zyga> brave new world
[06:27] <zyga> I need to figure out the horrid suspend issue where x input breaks
[06:27] <zyga> (but works in console)
[06:27] <mvo> zyga: this looks fine to me but I don't know enough
[06:27] <zyga> I only can reboot to recover from that
[06:27] <zyga> need to learn how xinput works
[06:28] <mvo> zyga: do you think could have a look at 7640? this would allow us to ship this in the initramfs
[06:28] <zyga> yes, I think you pinged me about that yesterday
[06:28] <zyga> let me do so now
[06:29] <zyga> mvo: question about the path, we have /run/snapd/* already, could that path be /run/snapd/recovery or something like that?
[06:29] <mvo> zyga: sure, I can change that
[06:29] <mvo> zyga: this is in initramfs
[06:30] <mvo> zyga: so we don't have /run/snapd yet but its fine to add it
[06:30] <zyga> yeah, just for consistency,
[06:30] <zyga> it's not a blocker in any way
[06:30] <zyga> mvo: total lack of docstrings makes this harder to review
[06:31] <zyga> mvo: I'm not following core20 work as closely
[06:31] <zyga> mvo: what kind of filesystems are going to be mounted?
[06:31] <mvo> zyga: vfat and ext4 currently
[06:31] <zyga> mvo: by deployFilesystemContent
[06:31] <zyga> ok
[06:38] <mborzecki> zyga: i'm looking for the place where we creat that per snap XDG_RUNTIME_DIR but i don't see it
[06:38] <mborzecki> zyga: there's some dead code in s-c
[06:38] <mborzecki> zyga: and nothing in snap run?
[06:39] <zyga> mborzecki: snap run
[06:39] <zyga> mborzecki: cmd/snap/cmd_run.go:495
[06:39] <mborzecki> zyga: btw. wonder if that also breaks the thing with xdg-open & classic snaps that cause new browser window to pop up
[06:39] <zyga> mborzecki: probably
[06:39] <zyga> yeah, it's just silly we set it
[06:39] <zyga> for classic I mean
[06:39] <mup> PR snapd#7660 opened: snap-recovery: rename to "snap-bootstrap" <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7660>
[06:43] <mborzecki> zyga: hmm that code in snap run doesn't create /run/user/<uid>/snap.*
[06:45] <jamesh> there's code in snapcraft-desktop-helpers that creates it, with a comment referencing https://bugs.launchpad.net/snappy/+bug/1656340
[06:45] <mup> Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <bionic> <cosmic> <eco-team> <xenial> <Snappy:Triaged by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1656340>
[06:49] <zyga> mvo: https://github.com/snapcore/snapd/pull/7640#pullrequestreview-307007679
[06:49] <mup> PR #7640: snap-recovery: deploy gadget content when creating partitions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7640>
[06:50] <mvo> zyga: thank you! about the ShiftStructureTo - thats something for mborzecki
[06:51] <mvo> zyga: I will follow the second suggestion in a followup, I need to make it transactional and then its good for now
[06:51] <mup> PR snapd#7640 closed: snap-recovery: deploy gadget content when creating partitions <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7640>
[06:52] <zyga> +1
[06:56] <mvo> thanks zyga !
[06:59] <zyga> mvo: is https://github.com/snapcore/snapd/pulls/zyga something for 2.42.1 or 2.43?
[07:02] <zyga> I'll get breakfast and then work on follow ups
[07:05] <pstolowski> morning
[07:08] <zyga> hey palasso
[07:08] <zyga> pawel :)
[07:08] <palasso> hello zyga
[07:11] <mup> PR snapd#7630 closed: overlord/devicestate: check snap handler for gadget remodel compatibility <Remodel 🚋> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7630>
[07:17] <mvo> hey pstolowski ! good morning
[07:19] <mborzecki> zyga: reading the comments from ian about docker snap, wtf is docker doing there?
[07:20] <mborzecki> btw. wonder if we could snap podman and use the same docker interface
[07:23] <zyga> i have ideas
[07:23] <zyga> breakfasting
[07:28] <mborzecki> zyga: #7632 is green
[07:28] <mup> PR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
[07:29] <zyga> yep
[07:36] <zyga> re
[07:36] <zyga> okay
[07:36] <zyga> mborzecki: we had an issue with docker in the past
[07:37] <zyga> mborzecki: it was trying to use /sys from ... /var/lib/snapd/hostfs/sys
[07:37] <zyga> mborzecki: I think it's a bit "too" smart
[07:37] <zyga> mborzecki: I'll start by hiding the cgroup from snap view
[07:37] <zyga> mborzecki: let's see if that is enough to fix it
[07:37] <mborzecki> zyga: so smart that the smartness overflowed
[07:38] <mborzecki> zyga: won't the cgroup always appear via /proc/$$/cgroup?
[07:39] <zyga> mborzecki: nuclear gandhi
[07:40] <zyga> mborzecki: yes but if it doesn't show up mounted maybe it will ignore it
[07:40] <zyga> mborzecki: we need to check docker logic
[07:40] <zyga> afk again
[07:41] <mborzecki> zyga: iirc when i looked at libcontainer it tried to parse /proc/self/cgroup and /proc/mountinfo
[07:43] <zyga> mborzecki: we can remove it from mountinfo
[07:43] <zyga> if it parses cgroup then we're SOL
[07:43] <zyga> but then again, it's silly to do :P
[08:03] <mup> PR snapd#7661 opened: packaging: tweak handling of usr.lib.snapd.snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/7661>
[08:06] <zyga> mvo: thanks
[08:06] <zyga> mvo: is it working?
[08:06] <zyga> is that tested?
[08:06] <zyga> we did that before and it was a hit-and-miss
[08:06] <zyga> mborzecki: I wrote a small patch - checking if that makes docker work
[08:06] <mvo> zyga: we test it in one spread test but I could not reproduce
[08:07] <zyga> aha
[08:07] <zyga> well
[08:07] <zyga> I wrote that patch for moving that out of /etc
[08:07] <zyga> but it's not finished (tests need adjusting)
[08:07] <zyga> I think it's fine
[08:07]  * mvo nods
[08:12] <zyga> mborzecki: it works
[08:13] <zyga> mborzecki, ijohnson: this fixes docker
[08:13] <zyga> https://github.com/snapcore/snapd/pull/7547/commits/1c60b84df1faf7ca2e80bf30d50850e6322da87b
[08:13] <mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
[08:13] <zyga> so yay
[08:44] <pedronis> mvo: should #7642 be merged?  #7626 and #7645 need a master merge I think
[08:44] <mup> PR #7642: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/7642>
[08:44] <mup> PR #7626: managers: add remodel undo test for new required snaps case <Created by mvo5> <https://github.com/snapcore/snapd/pull/7626>
[08:44] <mup> PR #7645: client: add xerrors and wrap errors coming from "client" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7645>
[08:45] <pedronis> mborzecki: hi, maybe you can do a 2nd review of 7626
[08:48] <mup> PR snapd#7632 closed: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7632>
[09:22] <pedronis> lots of repeated red :/
[09:29]  * dot-tobias says hi
[09:31] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/7662
[09:31] <zyga> hey dot-tobias
[09:31] <mup> PR snapd#7662 opened: interfaces: simplify AddUpdateNS and emit <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7662>
[09:31] <mup> PR #7662: interfaces: simplify AddUpdateNS and emit <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7662>
[09:33] <pstolowski> zyga: ty
[09:37] <pedronis> mvo: did you see my ping here about some of your PRs ?
[09:41] <mvo> pedronis: re 7642> if we don't see the mysterious error 6 anymore I think we can omit it
[09:41] <mvo> pedronis: I suspect something with travis was wrong that triggered these errors
[09:44] <pedronis> ok
[09:45] <mvo> pedronis: feel free to close, we can always reopen if these mysterious errors  come ack
[09:51] <mup> PR snapd#7663 opened: tests: add 14.04 canonical-livepatch test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7663>
[09:52] <mup> PR snapd#7664 opened: cmd/cmdutil: version helper <Prebaking> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7664>
[10:03] <mup> PR snapd#7642 closed: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7642>
[10:16] <mup> PR snapd#7665 opened:  devicestate: add support for gadget->gadget remodel  <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
[10:17] <mborzecki> mvo: pedronis: ^^ decided against splitting it further for now
[10:18] <mborzecki> still 12 files changed, 820 insertions(+), 97 deletions(-) :/ meh
[10:22] <ijohnson> zyga nice
[10:22] <zyga> hey :)
[10:22] <zyga> yeah
[10:25] <ijohnson> Much better than trying to patch docker :-)
[10:33] <pedronis> mborzecki: sounds ok size wise, I imagine a bunch is the managers_test.go test ?
[10:33] <mborzecki> pedronis: yup, managers_test, devicestate tests, spread test ;)
[10:34] <pedronis> yea, sounds alright :)
[10:37] <mvo> thanks mborzecki
[10:37] <mborzecki> mvo: got some reviews for zyga and then i'll look into the copr repo with xerrrors to unblock you
[10:38] <mvo> mborzecki: \o/
[10:50]  * Chipaca gets confuzzled and takes a break
[10:51]  * pstolowski lunch
[11:25] <Wimpress> mvo Chipaca We (popey and I) have things to discuss with you for todays catch up :-)
[11:27] <mup> PR snapd#7648 closed: interfaces/policy: expand cstrs/cstrs1 to altConstraints/constraints <Simple 😃> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7648>
[11:28] <zyga> Wimpress: sounds interesting
[11:29] <mup> PR snapd#7655 closed: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
[11:30] <mvo> Wimpress: I can make it if we keep it short
[12:10]  * zyga afk
[12:35] <mup> PR snapcraft#2707 closed: manifest: sort package and snap lists for consistency <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2707>
[12:35] <mup> PR snapcraft#2755 closed: extensions: kde-neon: add icon and sound themes <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2755>
[12:50] <ijohnson> morning
[12:50] <pedronis> pstolowski: I did a pass on #7658
[12:50] <mup> PR #7658: cmd/snap-start-preseed: add snap-start-preseed executable (1/N) <Prebaking> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
[12:59] <pstolowski> pedronis: yes just saw it, thank you
[12:59] <ijohnson> pstolowski: thanks for the review, will address your suggestions today
[13:08] <mvo> mborzecki: about this copr repo - do I need to add something to the xerrors pr under review?
[13:09] <mborzecki> mvo: i'll open a PR adding that to the early setup we do on fedora
[13:09] <mvo> mborzecki: \o/
[13:10] <mup> PR snapd#7662 closed: interfaces: simplify AddUpdateNS and emit <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7662>
[13:18] <zyga> jdstrand: can you re-review https://github.com/snapcore/snapd/pull/7547
[13:18] <mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
[13:18] <zyga> jdstrand: mainly to check the comments about v1 vs v2 mode
[13:23] <zyga> huh
[13:23] <zyga> https://www.irccloud.com/pastebin/eonsNHRx/
[13:23] <zyga> mborzecki: did you see this when changing delta code in spread recently?
[13:23] <zyga> not sure why this didn't flag before
[13:24] <zyga> perhaps just 19.10 -> amazon is the problem
[13:24] <mborzecki> zyga: nope? this an opensuse host?
[13:24] <zyga> no, ubuntu 19.10
[13:24] <mborzecki> ah 19.10 hm, maybe some defaults changed?
[13:24] <zyga> mhm
[13:28] <sergiusens> how good is "snap set core experimental.refresh-app-awareness=true"?
[13:31] <zyga> sergiusens: it's partially useful, it's not handling classic confinement which will be fixed shortly (code ready, waiting on reviews)
[13:31] <zyga> sergiusens: there's no UX but that's under development
[13:31] <mup> PR snapd#7666 opened: tests: don't depend on GNU time <Created by zyga> <https://github.com/snapcore/snapd/pull/7666>
[13:31] <zyga> sergiusens: there will be some in the next two weeks
[13:32] <sergiusens> zyga: I just want to prevent updates for when running confined snaps like the browser, which updates frequently and too many weird things start to happen :-)
[13:32]  * sergiusens sets the flag
[13:32] <zyga> sergiusens: yes, please set it
[13:32] <zyga> sergiusens: and report all weird stuff
[13:32] <zyga> sergiusens: I'm working on making it much better
[13:33] <zyga> mborzecki: small python helper if you want to look
[13:33] <zyga> https://github.com/snapcore/snapd/pull/7666/files
[13:33] <mup> PR #7666: tests: don't depend on GNU time <Created by zyga> <https://github.com/snapcore/snapd/pull/7666>
[13:37] <ijohnson> pedronis: I will look at your seedwriter PR now
[13:38] <zyga> Installing updates....
[13:43] <pedronis> ijohnson: thx
[13:46] <mup> PR snapd#7667 opened: spread: enable bboozzoo/snapd-devel-deps COPR repo for getting golang-x-xerrors <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7667>
[13:46] <mborzecki> mvo: ^^
[13:57] <ijohnson> pedronis: reviewed one question about the tests
[13:57]  * ijohnson goes to get coffee before meeting
[14:02] <jdstrand> zyga: it is on the list, yes. pedronis, I commented (only) on pr 7659. I am not explicitly blocking the PR, but wanted to make sure my concerns were considered
[14:02] <mup> PR #7659: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7659>
[14:02] <zyga> jdstrand: ack
[14:03] <jdstrand> well, I did vote -1 for 2.42.x
[14:03] <jdstrand> but anyhoo, it is all in the PR
[14:04] <jdstrand> zyga: also, I don't think I'm needed for 7666, but I glanced at it and the approach looks good. thanks for the followup :)
[14:05] <zyga> jdstrand: thanks! :)
[14:20] <abeato> jdstrand, hey, is https://github.com/snapcore/snapd/pull/7603 on your radar? the MP contains a couple of new interfaces for dpdk
[14:20] <mup> PR #7603: interfaces: add dpdk and hugepages interfaces <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7603>
[14:22] <jdstrand> abeato: it is. I need to dig in a bit on that one
[14:22] <abeato> great
[14:27] <hellsworth> i see two content snaps listed when i do snap connections on my snap so can someone point me to where connections grabs its info from?
[14:27] <hellsworth> i'm building my snap in a normal way, only pointing to one extension. that extension only points to one platform snap.
[14:33] <hellsworth> does the core18 base know about extensions?
[14:36] <ijohnson> hellsworth: look at `sudo cat /var/lib/snapd/state.json | jq .data.conns`.
[14:37] <ijohnson> hellsworth: probs you are suffering from the bug where your snap you are working on was previously installed and had that connection to the other content interface and so now `snap connections` shows that
[14:37] <hellsworth> how can i clear that history though
[14:37] <hellsworth> yes i did previously have this snap installed with the old extension
[14:38] <hellsworth> which connected to the old content snap
[14:38] <ogra> Oct 25 16:19:28 ... systemd[1]: [/etc/systemd/system/snap-pi2\x2dkernel-102.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
[14:38] <ogra> Oct 25 16:19:28 ... systemd[1]: [/etc/systemd/system/snap-core18-1226.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
[14:38] <ogra> hmm, thats a new one
[14:38] <ogra> (my log is full of these)
[14:44]  * zyga goes for lunch
[14:49] <oSoMoN> jdstrand, have you seen my last message on https://forum.snapcraft.io/t/auto-connecting-the-personal-files-interface-for-the-chromium-snap-part-ii/13705/8 ?
[14:49] <oSoMoN> auto-connection of personal-files for chromium is refused, I thought you had allowed it?
[14:50] <jdstrand> oSoMoN: I hadn't, but I'll look at it
[14:50] <jdstrand> zyga: ok, reviewed pr 7547, please see both the review comments and the additional comment I added after
[14:51] <mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
[14:51] <oSoMoN> jdstrand, you wrote "Granting use of the updated path. This is now live.", I assumed this was good to go
[14:52] <jdstrand> oSoMoN: it should be. that is why I need to look at it :)
[14:52] <oSoMoN> ok, thanks :)
[14:53]  * cachio lunch
[14:55] <zyga> jdstrand: ack
[14:56] <jdstrand> oSoMoN: btw, the memory usage PR as merged. it should be in edge whenever the core snap is rebuilt
[14:56] <jdstrand> zyga: it probably wouldn't be terrible to get that ^ in 2.42
[14:56] <jdstrand> I'll let others decide
[14:57] <zyga> jdstrand: the apparmor memory fix? I think that's up to mvo to cherry pick but I agree it's not likely to be hard to do or breaking stuff
[14:57] <zyga> so yeah =1
[14:57] <zyga> +1
[14:57] <jdstrand> zyga: yeah
[14:59] <mvo> zyga: if you and jdstrand are good I can cherry pick the appamror de-dup fix to 2.42.1  (unless pedronis  objects of course)
[14:59] <oSoMoN> jdstrand, I subscribed to the PR so I got a notification when it was merged, that's very nice, thanks!
[15:00] <oSoMoN> my opinion doesn't count, but I'm totally +1 for cherry-picking :)
[15:00] <jdstrand> mvo: +1
[15:00] <zyga> mvo: yes, just remember it was split into three PRs
[15:00] <zyga> mvo: 1) OrderedSet, 2) emit 3) the actual fix with spread test
[15:01] <oSoMoN> btw, thanks zyga for working on this
[15:02] <jdstrand> mvo: regression potential should be shallow. if snap-update-ns isn't working right, it should be broken in many places. asking QA for explicitly testing the preinstalled gnome snaps is likely not a bad idea to build confidence
[15:02] <mvo> zyga, jdstrand lets quickly catchup with pedronis  (he is in a meeting right now) and if he is +1 I will cherry-pick
[15:05] <jdstrand> oSoMoN: typo in snap decl. I thought it was chromium-browser-init. it is chromium-browser.init
[15:05] <jdstrand> oSoMoN: shall I fix the snap decl or you fix the snap?
[15:05] <jdstrand> oSoMoN: it is easy to fix the snap decl
[15:07] <jdstrand> oSoMoN: I see the original request was for chromium-browser.init, so I'll fix the snap decl
[15:10] <jdstrand> oSoMoN: fixed: https://forum.snapcraft.io/t/auto-connecting-the-personal-files-interface-for-the-chromium-snap-part-ii/13705/8
[15:11] <jdstrand> oSoMoN: be sure to 'snap refresh' before install if using the same system
[15:13]  * zyga made coffee
[15:13] <ogra> zyga, did you see my error above ? seems all my machines are spamming their logs with that
[15:13] <zyga> ogra: no, I did not
[15:13] <ogra> Okt 24 20:52:26 anubis systemd[1]: [/etc/systemd/system/snap-core-7917.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'
[15:13] <zyga> I see that now
[15:13] <ogra> ogra@anubis:~$ journalctl |grep -c lvalue
[15:13] <ogra> 1483
[15:13] <jdstrand> ogra: oh, I've seen that. I kept meaning to mention it somewhere
[15:13] <zyga> older versions of systemd don't understand lazy unmount
[15:13] <zyga> ogra: which version is that?
[15:14] <zyga> of the distribution
[15:14] <jdstrand> zyga: for me it was uc16
[15:14] <ogra> i just noticed it on a pi here ... and checked the other machines ... seems all of them show it
[15:14] <zyga> I see
[15:14] <ogra> thats 16.04 and a Core 16 Pi
[15:14] <zyga> it's a part of a fix
[15:14] <zyga> that doesn't work on old systems
[15:14] <ogra> so both, core and desktop
[15:14] <pedronis> mvo: what's the question?
[15:14] <ogra> yeah, i was guessing you use some new systemd feature there :)
[15:15] <jdstrand> zyga: perhaps use of the conditional needs to be conditional on new enough systemd? not sure if that is system-key material...
[15:15] <jdstrand> meh
[15:15] <zyga> it is https://github.com/snapcore/snapd/commit/5f16e6b0738410d07995b85bc516d9bbb50263c8
[15:15] <jdstrand> use of the feature*
[15:16] <mvo> pedronis: if we can backport the de-duplication for apparmor lines into 2.42.1
[15:16] <zyga> jdstrand: we don't re-generate mount units today, system key won't help
[15:16] <zyga> jdstrand: I agree it would be nicer to know if it is supported
[15:17] <zyga> I need a moment to finish the coffee
[15:17] <zyga> then jumping into a customer bug
[15:17] <jdstrand> ogra: I'm thinking there should be a bug. I suspect we'll get customers wondering about it
[15:18] <jdstrand> ogra: and that will help the snapd team to prioritize
[15:18] <pedronis> mvo: it seems ok, if jdstrand is also +1
[15:20] <mvo> zyga: has the 3rd part landed already?
[15:20] <zyga> mvo: yes, all parts are inn
[15:20] <zyga> *in
[15:20] <jdstrand> pedronis (cc mvo): I am, though asking for some light additional QA for say running gnome snaps and verifying no new denials would not be unreasonable. I know there are nice tests for that in the PRs, so, all of your call
[15:21] <ogra> zyga, jdstrand https://bugs.launchpad.net/snapd/+bug/1849861
[15:22] <mup> Bug #1849861: Unknown lvalue 'LazyUnmount' message in logs with latest snapd on 16.04 based systems <snapd:New> <https://launchpad.net/bugs/1849861>
[15:22] <jdstrand> ogra: thanks!
[15:25] <pedronis> mvo: as jdstrand says a bit of extra QA would be good? what was your plan, do 2.42.1 straight? do a pre?
[15:30] <mvo> pedronis: probably no pre, should be very controlled but we can keep it longer in candidate for example
[15:30] <pedronis> ok
[15:30] <mvo> zyga: what was the pr number for the 3rd part
[15:30] <zyga> mvo: just install a snap before and after and check sha1 of the kernel image of the profile
[15:30] <zyga> mvo: one moment
[15:31] <zyga> mvo: 7632 7633 7639
[15:32] <zyga> mvo: please make sure to cherry pick the test as well, so that you can see it pass
[15:34] <mvo> zyga: thank you! 7632
[15:35] <mvo> zyga: 7632 tripped me over
[15:35] <zyga> mvo: do you need help?
[15:42] <mvo> zyga: in a meeting right now, I will probably do this on monday, but you are welcome to prepare a PR against 2.42 - but no worries, I will get to it eventually
[15:43] <zyga> mvo: not today, I'll just inspect that bug and EOD
[15:43] <zyga> mvo: I -1 one of your branches, sorry, just a  question but need to make sure it does not land unanswered
[15:51] <mvo> zyga: thats fine, its a valid question, we do it in other tests too but I will have a look later
[15:52]  * zyga is under invasion from a particularly lovely toddler :D
[15:55] <mvo> zyga: eod> totally fine!
[16:01]  * zyga breaks to run an errand
[16:36] <ijohnson> hellsworth: sorry I missed your response, probably what you can do is first remove the snap, then make a backup of your state.json, stop snapd with `systemctl stop snapd.socket && systemctl stop snapd` and then delete the conns for the snap in question in state.json and then re-enable snapd with `systemctl start snapd.socket && systemctl start snapd`and finally try installing your snap again
[16:36] <ijohnson> note that afaik the bug is just about the connections showing up in `snap connections`, I don't think the security policy still actually has the stuff that those connections implies
[16:39] <hellsworth> ok thanks. should snap-discard-ns also cleare this cached history too?
[17:10] <ijohnson> hellsworth: snap-discard-ns will clean up the security policy stuff (well specifically the mount ns), but it won't clean up the connections themselves
[17:11] <hellsworth> ok thanks for clearing that up ijohnson
[17:11] <ijohnson> np, sorry you are encountering that bug
[17:11] <hellsworth> bugs happen :)
[17:12] <ijohnson> hellsworth: that bug fwiw is https://bugs.launchpad.net/snapd/+bug/1848516
[17:12] <mup> Bug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1848516>
[17:12] <hellsworth> ah thanks
[18:11] <jdstrand> zyga: oh, I meant to ask, what was up with all the .keep files in PR 7632?
[18:11] <mup> PR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7632>
[18:23] <zyga> jdstrand: those are so that we have a
[18:23] <zyga> Directory structure
[18:23] <zyga> It is like gnome system monitor snap
[18:23] <zyga> Just frozen in time
[18:23] <zyga> And empty
[18:24] <jdstrand> zyga: oh right, git
[18:24] <zyga> Yeah :-)
[18:24] <jdstrand> zyga: it was weird cause github said 'No changes' in the PR
[18:24] <jdstrand> so it threw me
[18:24] <zyga> Yeah, all empty
[18:24] <jdstrand> ok, thanks :)
[18:24] <zyga> :-)
[19:00] <mup> PR snapcraft#2768 opened: remote-build: autorecovery and improved resiliency <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2768>
[19:08]  * cachio afk
[19:29] <kenvandine> sergiusens: https://paste.ubuntu.com/p/HTgWjC9tJV/
[19:29] <kenvandine> that is me building with the WIP gnome-3-34 extension which uses gnome-3-34-1804-sdk build snap
[19:30] <kenvandine> libffi.so.7 is in the same directory as libgobject-2.0.so
[19:30] <mup> PR snapcraft#2761 closed: Core20 base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2761>
[19:31] <kenvandine> sergiusens: any suggestions appreciated
[19:31] <mup> PR snapd#7667 closed: spread: enable bboozzoo/snapd-devel-deps COPR repo for getting golang-x-xerrors <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7667>
[19:35] <mup> PR snapd#7664 closed: cmd/cmdutil: version helper <Prebaking> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7664>
[19:37] <mup> PR snapd#7654 closed: cmd/snap, store: include snapcraft.io page URL in snap info output <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7654>
[19:38] <mup> PR snapd#7605 closed: tests: configure the journald service for core systems <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7605>
[19:53] <mup> PR snapd#7656 closed: tests: verify host is not affected by mount-ns tests <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7656>