[00:05] <mup> PR snapcraft#3781 opened: extensions: refactor <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3781>
=== mwhudson_ is now known as mwhudson
[05:24] <mborzecki> morning
[05:51] <mardy> mborzecki: hi!
[05:57] <mborzecki> hey
[07:54] <mardy> jamesh: hi! I'm trying to build a Gtk test app in Go (on Focal), but it looks like I'm not passing the build tags in the right way:
[07:54] <mardy> $ go build -tags "glib_2_66" -o /tmp/test ./cmd/cerberus-ui-prompt/
[07:54] <mardy> # github.com/gotk3/gotk3/glib
[07:54] <mardy> ../../gotk3/gotk3/glib/gbinding_since_2_68.go:14:9: could not determine kind of name for C.g_binding_dup_source
[07:54] <mardy> ../../gotk3/gotk3/glib/gbinding_since_2_68.go:23:9: could not determine kind of name for C.g_binding_dup_target
[07:55] <mardy> reference: https://github.com/gotk3/gotk3/issues/838
[07:55] <mardy> jamesh: do you know what I'm doing wrong?
[07:57] <jamesh> mardy: there's no mention of glib_2_66 in https://github.com/gotk3/gotk3/blob/master/glib/gbinding_since_2_68.go
[07:57] <jamesh> what if you use "-tags glib_deprecated"?
[08:00] <jamesh> mardy: it looks like that change happened after the last tagged revision: https://github.com/gotk3/gotk3/commit/4339d2baed7e8f86e2c34b7ffc3e86747da70c90
[08:00] <jamesh> so you could also specify v0.6.1 in your go.mod file
[08:11] <jamesh> mardy: for what it is worth, Go seemed kind of terrible for doing GUIs last time I tried.
[08:44] <mardy> jamesh: thanks, using the tag "glib_deprecated" brings me a bit further :-) This is just a quick PoC, for me to verify and demo a few things
[08:50] <mborzecki> mardy: that's the apparmor prompting code from zyga?
[09:09] <jamesh> mardy: did the idea of using the xdg-desktop-portal backend not work out?
[09:37] <zyga[m]> I, for one, would welcome our flutter overlords now
[09:37] <zyga[m]> flutter is so nice 
[09:37] <zyga[m]> hey everyone :)
[09:46] <mup> PR snapd#11780 closed: overlord/hookstate/ctlcmd: add 'snapctl model' command (3/3) <Needs Samuele review> <Created by Meulengracht> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11780>
[11:21] <mardy> jamesh: it works, but the D-Bus API of the Access dialog backend is a bit limited. We'd like to have things like separators, frames and maybe more text fields
[11:22] <jamesh> mardy: are you still going to be asking questions a user could realistically be expected to answer then?
[11:23] <mardy> jamesh: that's the goal
[11:42] <mup> PR snapd#11853 opened: daemon,systemd: support for journal namespaces when retrieving snap logs (6/n) <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/11853>
[11:52] <mup> PR snapd#11854 opened: interfaces/builtin: add more permissions for steam-support <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/11854>
[13:35] <leftyfb> any thoughts on my post from yesterday about the 65MB storage device showing up in nautilus which seems like it's for one of the previous version core20 snaps installed on my machine?
[13:39] <zyga[m]> leftyfb: I've seen this countless times when snaps refrehs, seems to be a race around loopback devices, I would advise you to see which loopback devices are in the system and cross-check that to snap revisions - it's possible there's a device that has no (more) matching snap 
[13:44] <leftyfb> zyga[m]: yeah, I see loop5 as being the culprit. Should I just deregister that loopback device?
[13:45] <zyga[m]> perhaps look at logs with that device as the key
[13:45] <zyga[m]> maybe someone will finally grok the problem
[13:45] <zyga[m]> we had several ideas but they all went nowhere
[13:45] <zyga[m]> systemd version is also useful
[13:45] <leftyfb> systemd is 249.11-0ubuntu3.1
[13:45] <synthmeat> someone should change freenode link to libera, on the status page :) https://status.snapcraft.io/
[13:47] <zyga[m]> leftyfb: perhaps collect this and the logs, it's still mostly unlikely anyone has the focus to fix that now
[13:47] <leftyfb> zyga[m]: this is all I have in my journal logs the past week https://pastebin.ubuntu.com/p/gpzwt4JdDb/
[13:48] <leftyfb> I think that was just me messing with the mount
[13:49] <zyga[m]> leftyfb: I would suggest at looking at the log to see when the loopback device (the specific number) is first mounted and anything related around that
[13:49] <zyga[m]> still, I don't know - something is racy, but what?
[13:50] <leftyfb> zyga[m]: I just went back 21 days (my uptime) nothing else in the journal logs containing "loop5"
[13:50] <zyga[m]> then it's still a mystery
[13:50] <zyga[m]> for me it happened when my system was particularly bogged down
[13:51] <zyga[m]> on a more idle system it never happened
[13:52] <leftyfb> any problem with me just removing the loopback?
[13:52] <leftyfb> with: sudo losetup -d /dev/loop5 
[13:54] <leftyfb> I would have done it already, but not sure if it's helpful to keep a reproduction of the issue for you to help troubleshoot. But it sounds like it's low priority and nobody has the time at the moment anyway
[13:55] <zyga[m]> I don't have time to trouble-shoot the issue now,
[13:55] <zyga[m]> I think it's okay to remove iff it's not mounted anywhere and it's not really a snap revision that's listed anywhere
[13:56] <zyga[m]> I would leave it as is unless you are very bothered by it
[13:57] <leftyfb> it's annoying but I'm mostly curious. Also maybe confirming a temporary "workaround" if a bug gets filed
[13:58] <leftyfb> zyga[m]: is there a bug already? If not, is it worth it for me to file one?
[13:58] <zyga[m]> I think there is, it was first reported years ago 
[13:58] <zyga[m]> I spent a lot of time chasing this 
[13:58] <zyga[m]> But I don't have a reference handy 
[13:59] <zyga[m]> I'm not involved in snapd on a daily basis 
[14:06] <mup> PR snapcraft#3782 opened: Feat/sigint <Created by Guillaumebeuzeboc> <https://github.com/snapcore/snapcraft/pull/3782>
[14:26] <mup> PR snapcraft#3778 closed: extensions: Add environment variables for runtime <Created by sergio-costas> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3778>
[14:56] <mup> PR snapcraft#3773 closed: extensions: Add paths for Gtk3 modules <Created by sergio-costas> <Closed by sergio-costas> <https://github.com/snapcore/snapcraft/pull/3773>
[14:56] <mup> PR snapcraft#3781 closed: extensions: refactor <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3781>
[15:47] <leftyfb> zyga[m]: losetup didn't remove the loopback device. Rebooting removed it of course
[16:36] <zyga[m]> leftyfb: interesting, what was the name of the snap that ws attached there again?
[16:37] <leftyfb> core20
[16:37] <leftyfb>  /var/lib/snapd/snaps/core20_1434.snap (deleted) on /media/leftyfb/disk type squashfs (ro,nosuid,nodev,relatime,errors=continue,uhelper=udisks2)
[16:42] <zyga[m]> HA
[16:42] <zyga[m]> I think I know what happens then
[16:42] <zyga[m]> I had a hunch - it had to be a base snap leaking
[16:42] <zyga[m]> and indeed it was
[16:42] <zyga[m]> thanks
[16:44] <leftyfb> zyga[m]: sweet, so I was able to provide some info to help with fixing the overall issue?
[16:44] <zyga[m]> yes but I won't have time to look at it
[16:44] <zyga[m]> but perhaps someone from the snapd team (disclaimer: I left almost two years ago) might?
[16:45] <leftyfb> ogra: ?
[16:45] <zyga[m]> perhaps bboozzoo can think of something 
[16:46] <zyga[m]> ogra is not touching that part AFAIK and it's a bit tricky on first contact
[16:46] <zyga[m]> or mardy ?
[18:19] <stgraber> hey there, we've recently been seeing "cannot refresh "lxd": snap "lxd" has running apps (lxc), pids: XYZ". What's the way to disable this particular check to get the "old" behavior back?
[18:20] <stgraber> For LXD, the service handles being restarted just fine and for the CLI client, it's not a problem at all if it remains running during a refresh. LXD has logic to then internally wait up to 5min for all clients to be done with what they're doing, send notifications and then process with the daemon restart anyway.
[18:21] <stgraber> this change of behavior from snapd now allows an unpriv user on a system to prevent a lxd refresh which is a security issue
[18:21] <stgraber> (as even users that aren't part of the "lxd" group can effectively hold a refresh)
[19:23] <zyga[m]> stgraber: I don't remember if there's a check you can opt into, the stack was using systemd scope to keep track of living pids that belong to an app
[19:23] <zyga[m]> stgraber: perhaps discuss with pedroinis for ideas on how to make exceptions 
[19:24] <zyga[m]> stgraber: non-daemon apps were in the holding set, perhaps there's a CLI tool that is not a daemon but is long-enough-lived?
[19:24] <stgraber> yeah, looking at the snapd code, I see it skipping daemons but I don't see any logic to skip non-daemon
[19:24] <stgraber> I'll file a security issue against snapd and see what folks say
[19:29] <zyga[m]> it's by design
[19:30] <zyga[m]> there's an upper limit after which the refresh continues
[19:30] <zyga[m]> it's on the order of a week or two (last time I worked on this was in 2020 so ... it may have changed)
[19:30] <stgraber> right but that limit appears to be days, not minutes
[19:30] <zyga[m]> after that time the refresh is carried out no matter what
[19:30] <zyga[m]> yes
[19:30] <zyga[m]> it was aimed as "I'm not restarting my browser" 
[19:30] <stgraber> for us, this new behavior can hold an entire cluster, preventing all API interactions for days
[19:30] <zyga[m]> *at
[19:30] <zyga[m]> indeed
[19:30] <zyga[m]> do you know which process is the holdout?
[19:31] <stgraber> right, I wrote that in the security bug, it's fine for firefox, makes sense :)
[19:31] <stgraber> in our case, it was a random long-running "lxc exec' or "lxc monitor"
[19:31] <zyga[m]> I see
[19:31] <zyga[m]> perhaps snap run --no-track might be something like on the right track
[19:31] <stgraber> those can run for days/weeks but are expected to be terminated by LXD when it handles an upgrade
[19:31] <zyga[m]> with a flag to excempt an app from tracking
[19:32] <zyga[m]> per app
[19:32] <zyga[m]> or an API, hard to say what is right
[19:32] <zyga[m]> btw, I think lxd CI would benefit from testing snapd experimental features
[19:32] <zyga[m]> this was around for literally years
[19:32] <zyga[m]> not blaming anyone (my participation is small) but I think it's surprising this came out this late
[19:37] <stgraber> https://bugs.launchpad.net/snapd/+bug/1978005
[19:37] <mup> Bug #1978005: Snap application prevents daemon refresh <snapd:New> <https://launchpad.net/bugs/1978005>
[19:38] <stgraber> I've heard of the feature being developed for a while (the whole desktop refresh notification) but apparently wrongly assumed that it would be opt-in
[19:38] <stgraber> and not forced on everyone without even a way to opt-out of it
[19:39] <zyga[m]> I see, I think there was a missing comms link then
[19:41]  * zyga[m] clones snapd
[19:42] <stgraber> I see a function being passed that's called to determine if a given application will hold refresh or not but it's currently only used to let daemons through
[19:43] <stgraber> looks like plumbing that to a new field in app YAML shouldn't be particularly difficult
[19:43] <zyga[m]> yes, I think this is simple to patch, apart from design on what the right thing is
[19:43] <zyga[m]> yes
[19:43] <zyga[m]> I will do that in a moment
[19:43] <zyga[m]> I wish I could see people's faces when they see a PR from me :P
[19:43] <zyga[m]> snapd has a lot of history...
[19:45] <zyga[m]> stgraber: I must say I'm happy to see this discussion here, where I can casually notice it, instead of happening on mattermost
[19:46] <stgraber> yeah, not sure why people use MM for what should be public discussions
[19:46] <stgraber> but then we have the problem of not having mvo or pedronis online on here after work hours
[19:47] <zyga[m]> I think they may be a bit overworked, also not that much is happening on irc anymore :/
[19:48] <zyga[m]> (though with matrix, it's a silly excuse not to have a client connected)
[19:48] <zyga[m]> (still cloning)
[20:05]  * zyga[m] pokes snapd a little
[20:20] <zyga[m]> stgraber: running regression test now
[20:22] <stgraber> cool!
[20:31] <zyga[m]> I think CI is not in a happy place
[20:31] <zyga[m]> quiet: eatmydata apt-get install --no-install-recommends -y python3 autoconf automake autotools-dev build-essential ca-certificates clang curl devscripts expect gdb gdebi-core git indent jq apparmor-utils libapparmor-dev libglib2.0-dev libseccomp-dev libudev-dev man mtools netcat-openbsd pkg-config python3-docutils udev... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e3bc4b738917f0e38ae4c0fc3fbfa1e8b985de3f)
[20:32] <zyga[m]> let me try a draft PR perhaps?
[20:41] <zyga[m]> https://github.com/snapcore/snapd/pull/11855
[20:41] <mup> PR #11855: Do not track apps that wish to stay outside of the life-cycle system <Created by zyga> <https://github.com/snapcore/snapd/pull/11855>
[20:44] <mup> PR snapd#11855 opened: Do not track apps that wish to stay outside of the life-cycle system <Created by zyga> <https://github.com/snapcore/snapd/pull/11855>
[21:00] <zyga[m]> CI is in a happier spot, I will know if my patch works soon
[21:06] <zyga[m]> stgraber: the fix seems to work
[21:06] <stgraber> zyga[m]: nice!
[21:06] <zyga[m]> I will extend the regression test to make sure it's not a fluke, to test both ways
[21:18] <zyga[m]> stgraber: force-pushed with both scenarios tested
[23:32] <mup> PR snapcraft#3779 closed: meta: handle version git <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3779>
[23:52] <mup> PR snapcraft#3783 opened: pack: display snap filename <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/3783>