[00:03] PR snapcraft#2369 closed: Hide progress bar for dumb terminals [01:21] cjwatson: I've looked into alternative routes. The stack build fails because it's linked against an old version of Cabal, and the docker build fails because multistage builds weren't introduced before 17.05 (xenial has 17.03) [04:23] PR snapd#6038 closed: release: 2.36 [05:43] morning [05:47] how can i put an apparmor profile of a snap into complain mode? === chihchun_afk is now known as chihchun [06:25] good morning everyone [06:27] dot-tobias: morning [06:39] Good morning [06:40] mborzecki: you can use apparmor tools [06:40] But I never remember which [06:40] Just edit the profile [06:40] zyga: something i wanted to avoid :) [06:40] Change the part that reads (attach_disconnected,....) [06:41] And insert “complain” there AFAIR [06:41] Then parse and load into the kernel [06:42] zyga: tried aa-complain, but expects a path to the binary, which is sligtly funny as you can have a profile just with a label like we do for snaps === pstolowski|afk is now known as pstolowski [07:04] heyas [07:05] Hey [07:06] looks like this test is slightly incorrect: https://github.com/snapcore/snapd/blob/master/cmd/snapd/main_test.go#L57-L94 the daemon is started, but we never wait for it to finish [07:08] added some synchronization and now it's clear that Run() does not exit with nil, but raises value *errors.errorString = &errors.errorString{s:"cannot gracefully finish, still active connections on /tmp/check-8792093359864697921/0/run/snapd.socket after 5s"} ("cannot gracefully finish, still active connections on /tmp/check-8792093359864697921/0/run/snapd.socket after 5s") [07:09] that's probably because http connections from the client are kept alive [07:31] there are 2 intersting failures in unit tests i've seen today, first one https://paste.ubuntu.com/p/kTHywvD39V/ i can reproduce it locally if i change the sleep to something really small, hence i started adding extra synchronization around snapd.Run() [07:32] and the 2nd one: https://paste.ubuntu.com/p/SwXy77XJ6H/ where userd got SIGQUIT ? [07:32] this one is appearing quite often in 2.36 branch [07:39] eh, I fucked up [07:39] Can anyone check if the right pc i386 and amd64 gadget snaps are in stable and candidate now? [07:40] I never use the snapcraft dashboard UI for promoting snaps ever again... [07:46] mborzecki: thank you [07:46] sil2100: define correct [07:48] The last one that was supposed to be there, but I found it in the stable images [07:48] Damn I'm pissed off [07:49] I'm still sleepy, not sure how to check [07:49] I can tell you the revisions I see [07:49] but not sure if that helps [07:49] Wanted to promote 18 gadget snaps, thought the dashboard UI is smart and will promote to the right 18/stable etc. [07:50] sil2100: 18/stable is empty [07:50] so perhaps not correct [07:51] there are some revisions in 18/beta and edve [07:52] zyga: I was talking about 16 [07:52] I now just promoted the 18 ones [07:53] stable: 16.04-0.8 (9) 856kB - [07:53] candidate: 16.04-0.8 (9) 856kB - [07:53] beta: 16.04-0.9 (24) 872kB - [07:53] edge: 16.04-0.9 (24) 872kB - [07:53] zyga: want to make sure the 16 ones are as correct as they were [07:53] it looks rather unchanged [07:53] phew [07:53] but I don't know what they were before [07:53] so hard to say [08:19] heh, looking into problem 1, we're doing a graceful shutdown and daemon is stuck calling net.Conn.Close() [08:22] pstolowski: could you please look at 6010, landing this would unblock me [08:22] zyga: sure [08:22] this doesn't make any sense, it's like close(fd) which should not block [08:22] mmm [08:23] mborzecki: is it really just that? [08:23] zyga: https://golang.org/src/net/net.go#L197 [08:23] mborzecki: sorry, I don't feel very well today and I'm slow at thinking, can you walk me through the problem statement [08:24] zyga: take a look here: https://github.com/snapcore/snapd/blob/master/cmd/snapd/main_test.go#L57-L94, there's a gorouting which runs `err := snapd.Run()` [08:24] zyga: but in the test we do not wait for the goroutine to finish [08:25] zyga: now if we wait, it's either stuck or exits with error `cannot gracefully finish, still active connections on /tmp/check-8792093359864697921/0/run/snapd.socket after 5s` [08:25] aha [08:26] and where is the graceful shutdown code? [08:26] zyga: that's because the test is poking the API via http, but net/http does not close the connection right away after the request is finished, so it's still 'seen' at the server side and we try to go through graceful shutdown calling Close() nicely on each connection [08:27] zyga: it's here https://github.com/snapcore/snapd/blob/master/daemon/daemon.go#L462-L490 [08:28] zyga: specifically i see it stuck on https://github.com/snapcore/snapd/blob/master/daemon/daemon.go#L471 now === chihchun is now known as chihchun_afk [08:38] mborzecki: and the net.Conn that we re interacting with [08:38] what is it in reality? [08:38] that is, what Close are we really calling [08:39] zyga: this one https://golang.org/src/net/net.go#L197 [08:39] and netFD? [08:40] heh added DisableKeepAlives to the transport config and now it's closing right away [08:45] zyga: https://golang.org/src/net/fd_unix.go#L182 and then it goes into some internal/poll https://golang.org/src/internal/poll/fd_unix.go#L86 there's a comment that Close() may block [08:46] greyback: Regarding i3 WM in chromium-mir-kiosk not picking up rotation: I dug into the configuration and it seems that i3 does indeed not pick up the mir-kiosk vertical rotation. However, when I enable kiosk mode in the snap, chromium is forced to fullscreen, and resizing commands are discarded by i3. Do you have a hint on where I can disable the fullscreen? Maybe in xwayland-kiosk-helper? === chihchun_afk is now known as chihchun [08:48] dot-tobias: the helper auto-generates a config file to make a surface fullscreen, see https://github.com/MirServer/xwayland-kiosk-helper/blob/master/xwayland-preload/xwayland-kiosk-launch#L121 [08:49] dot-tobias: however chromium-mir-kiosk provides it's own i3 config file [08:49] I don't think enabling/disabling kiosk mode impacts the use of that config file at all [08:50] mborzecki: a bit of internals for the morning [08:50] are we holding it wrong? [08:51] greyback: Yeah, just found that variable 😊 I'm uncertain how the two i3 configs interact, but what I can observe is that commands in the chromium-mir-kiosk i3 config are ignored when kiosk mode is enabled for chromium-mir-kiosk. which “just” loads the kiosk Chrome app AFAIR [08:51] zyga: i think it's outside of our control, let me check the unixDialer we use [08:51] dot-tobias: that's not what I intended anyway. The goal was: if snap provides its own i3 config, use that. If not, fallback to an auto-generated one [08:57] mborzecki: given that we don't do real http we could disable keepalive [08:57] mborzecki: and perhaps leave a clear note that dragons lurk beyond [09:03] pstolowski: one for you https://forum.snapcraft.io/t/hook-run-script-when-an-interface-is-connected/8155 [09:05] zyga: thanks, i'll answer [09:11] zyga: i've just hit the issue popey reported recently, with gnome-calculator. i installed its snap yesterday, it's connected to gnome platform snap yet it doesn't see it. i'm on 2.36 [09:13] zyga: my laptop has been running for only a few days (since monday) [09:13] can you nester [09:13] nsenter [09:13] and then see if that place $SNAP/gnome-platform looks sane please [09:13] yay! [09:14] zyga: will do [09:25] pstolowski: any files inside? [09:25] and any changes recently? [09:26] zyga: sorry, tryng to finish the review of your PR, will check that issue next. the only changes are [09:26] 195 Done yesterday at 17:39 CEST yesterday at 17:39 CEST Auto-refresh snap "lxd" [09:26] 196 Done today at 09:04 CEST today at 09:05 CEST Auto-refresh snaps "core", "lxd" [09:26] thanks [09:26] so, unrelated [09:26] aha, core refreshed [09:26] core change is related (perhaps) [09:26] * zyga tries locally [09:26] hmm [09:28] h [09:28] HA [09:28] reproduced :) [09:28] popey: I got this now [09:29] I switched core from edge to beta [09:29] * zyga investigates [09:29] \o/ [09:30] and I got the sudo nsenter + ctrl-d bug :/ [09:34] also yay :) [09:35] PR snapd#6041 opened: client, cmd/daemon: allow disabling keepalive, improve degraded mode unit tests [09:52] zyga: a few comments [09:53] zyga: wow, you reproduced, yay x2 [09:53] nonetheless, looking into my namespace [10:06] pstolowski: you can discard the namespace, I will fix that issue [10:07] thank you for the review, looking at the response [10:08] can someone take a look at this: https://github.com/snapcore/snapd/blob/master/overlord/standby/standby.go#L80-L105 if i'm reading this right, when Stop() is called at the bad moment and m.stopCh is nil, the goroutine will go into sleep waiting for timeout even though it's supposed to exit [10:11] zyga: great you found the problem! thanks [10:18] degville: hey, https://forum.snapcraft.io/t/hook-run-script-when-an-interface-is-connected/8155/3 reminded me of the missing doc for interface hooks [10:19] degville: shall i describe all that in an email and send to you? [10:21] PR snapd#6042 opened: overlord/standby: fix a race between standby goroutine and stop [10:21] pstolowski: hello - yes, that would be great - thanks! [10:24] degville: ok, will do [10:32] * zyga breaks [10:32] sorry guys, I feel sick [10:42] why am i getting shellcheck errors for something that's already on master :-( [10:44] and why is shellcheck now saying "unable to decommit memory" [10:44] Chipaca: whcih file? [10:45] Chipaca: btw. 6042 might be interesting for you [10:46] Chipaca: uname? [10:46] oh. new shellcheck. [10:47] mborzecki: https://pastebin.ubuntu.com/p/KSJXRVXFVz/ [10:47] zyga: GO AWAY YOU'RE SICK FFS [10:47] zyga: we'll get IRC cooties [10:48] mborzecki: fixing [10:48] Chipaca: which PR is that? shellcheck version should be printed in the log [10:49] mborzecki: this is the spread-run shellcheck, so it's the snap [10:50] mborzecki: the snap was created 2018-10-25T05:05:12.188830+00:00 [10:51] I think that means koala_man found out that haskell-stack does not have the "cabal does not do good http" bug [10:51] heh [10:51] mborzecki: anyway, to answer your question, https://api.travis-ci.org/v3/job/445913480/log.txt [10:52] mborzecki: and AFAIK the spread run does not print the shellcheck version [10:53] Chipaca: https://ghc.haskell.org/trac/ghc/ticket/12865 [10:53] PR snapd#6028 closed: testutil, cmd/snap: introduce and use testutil.EqualsWrapped and fly [10:59] “This is a stylistic issue that does not affect correctness. If you prefer the original expression, you can't not Ignore it with a directive or flag.” [10:59] ^ shellcheck being snarky about the double-negative implied by ! -z / ! -n [11:01] PR snapd#6043 opened: tests/main: fixes for the new shellcheck [11:01] mborzecki: ^ [11:03] Chipaca: yeah, looks good [11:03] nice that it's picky about such small things too [11:05] mborzecki: also nice that it catches [ ! -z ] and ! [ -z ] the same [11:06] yeah, one of these days it'd be nice to look at the implementation, my money is on having those actually encoded as pattern matching directly in the code [11:08] haskell doing pattern matching? sounds about right :-) [11:09] pstolowski: updated https://github.com/snapcore/snapd/pull/6010 [11:09] PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces [11:09] ok [11:16] zyga: +1 [11:16] any ideas about https://paste.ubuntu.com/p/SwXy77XJ6H/ ? i've looked in go and check, does not look like any of those would send SIGQUIT [11:17] the test sends SIGUSR1 to itself, but that's handed properly already [11:21] mborzecki: nope, nothing remotely SIGQUITS this [11:21] maybe it is spread itself? [11:21] but I don't know [11:22] zyga: grepped through spread, came up empty [11:22] actually, I grepped in spread as well [11:22] :/ [11:27] pushing an update to arch pacakge in a bit [11:43] Chipaca: They installed an even more terrifying hack than that [11:43] cjwatson: … emacs? [11:43] https://bugs.launchpad.net/launchpad-buildd/+bug/1797809/comments/3 [11:43] Bug #1797809: Build fails on snapcraft.io, works locally (during `cabal update`) [11:44] hah [11:44] proxies all the way down [11:45] I also discovered that the reason newer cabal "works" even without curl is that it now supports multiple mirrors and just falls back to the next one in the list when its connection gets terminally confused by the first one [11:46] So I'm trying to hack persistent connection support into launchpad-buildd's internal proxy [11:50] PR snapd#6043 closed: tests/main: fixes for the new shellcheck [12:00] greyback: re: fullscreen chromium-mir-Kiosk in rotate => https://git.launchpad.net/~gerboland/+git/chromium-kiosk-app-snap/tree/manifest.json#n35 [12:01] mborzecki, Chipaca, pstolowski: would you mind stating your opinions on https://github.com/snapcore/snapd/pull/6010/commits/0ecf1448668b726021ff94408981599d335576d0 [12:01] PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces [12:02] greyback: I suspect this launches chromium in fullscreen, and i3 does not seem to pick up the rotation coming from mir-kiosk / xwayland. Resizing commands in i3 do not work for fullscreen windows (which is logical, but impractical for my use-case) [12:05] greyback: I‘ll add this to the forum topic (http://discourse.ubuntu.com/t/snaps-to-develop-a-web-kiosk-on-ubuntu-core-using-wayland/6424?page=5) once I‘m back at work. Would be very glad if you have suggestions how I can force i3 to respect the rotated layout. Thank you for your work on all the kiosk snaps 😊 [12:05] dot-tobias: hmm interesting, I forgot about that policy setting [12:06] dot-tobias: yes please do update the forum. I'll try to find time to look into the problem [12:08] greyback: I’ll do that and ping you here once done. Thank you for your time in advance 😊I’ll try to find a way to hide chromium UI when not in fullscreen mode. [12:15] zyga, hey, I need to take my son to make an audition study [12:15] zyga, I'll try to be back for the stand up but not sure [12:17] cachio: noted [12:17] thanks, good luck :) [12:18] zyga, tx [12:22] zyga: will do in a moment [12:30] snapd updated in AUR, i've also updated the wiki with some extra info [12:30] funny cause someone else edited the wiki while i was editing it and added a note about apparmor, which was like 10-15 minutes after i pushed the change to aur [12:31] mborzecki: so is snapd on Arch now fully confined? [12:32] ijohnson: not everything is supported yet, jdstrand left some details here: https://forum.snapcraft.io/t/arch-linux-and-apparmor/7036 [12:35] zyga: I have close to 0 opinions on C formatting style [12:35] Chipaca: mainly if you are -1 on moving to clang-format [12:35] zyga: I am not [12:36] zyga: the only C formatting style I think is bad is the one that pushes the {}s and the ;s to column 80 [12:38] degville: you around? [12:39] Chipaca: yep [12:39] degville: could you give the long help strings in https://github.com/snapcore/snapd/blob/dfef243c027b84ae8331a36dddbf61b6bf847813/cmd/snap/cmd_snapshot.go a once over? [12:39] degville: (search for "var long") [12:39] zyga: the clang-format lgtm, nothing out of ordinary,+1 [12:40] Chipaca: will do - looking now. [12:40] thanks! [12:43] sborovkov: hi [12:43] Chipaca, hello [12:43] sborovkov: remind me, if I'm not being rude, what was it you worked on? [12:43] screenly, digital signage :) [12:44] sborovkov: are you, or is your team, sensitive to snapd api changes? [12:44] I think it wasn't you, fwiw [12:45] hmm, not to a big extent, We currently only use it to set config.txt options [12:45] a shame, I'm going to have to talk to field engineering to get them to talk with the team in question, more roundabout than i would've preferred [12:45] so you might be thinking about someone else [12:45] sborovkov: yep yep :-) [12:45] sborovkov: this is about a screenshots -> media transition [12:46] happening in the 2.36 … 2.39 timeline [12:46] definitely not us then :) [12:46] sborovkov: thank you for confirming :-) I'll go pester field eng [12:51] mborzecki: do you know why the set of panics we see in unit tests surfaced now? [12:51] mborzecki: is it something that changed on our side recently? [12:54] mborzecki: which panics? [12:54] um [12:54] zyga: ^ [12:54] Chipaca: unit tests time out and panic [12:54] just look at recent test failure [12:55] zyga: in cmd/snap? [12:55] yes [12:55] hmm [12:55] yes I did see that, thought it was a one-off [12:55] machine taking a sleep or sth [12:55] i'll dig [12:57] Chipaca: w8, whci one? there's a PR addressing one of the issues i saw [12:57] mborzecki: ah! which pr is that? [12:57] Chipaca: there's one here https://github.com/snapcore/snapd/pull/6041 [12:57] PR #6041: client, cmd/daemon: allow disabling keepalive, improve degraded mode unit tests [12:58] Chipaca: another one https://github.com/snapcore/snapd/pull/6042 this was not caught by unit tests but race detector suggested and issue and IMO there is one [12:58] PR #6042: overlord/standby: fix a race between standby goroutine and stop [12:58] mborzecki: the one I saw (and I thought zyga was asking about) was one where you get the test killed by go because it times out [12:59] intersting, what PR is that? [12:59] mborzecki: I mean your PRs are good but I wonder what happened that this started to happen [12:59] zyga: do you have one of these failures handy? [12:59] guys, I feel sick and could need to... break, at any time [12:59] can one of you run the standup please [13:00] my update: working on user mounts but interrupted by reproducing the issue popey discovered [13:00] fixing it with top priority [13:00] Chipaca: let me look [13:01] Chipaca: here is one https://api.travis-ci.org/v3/job/445642309/log.txt [13:02] whoops standup [13:03] cachio: standup [13:04] mborzecki: he said he would probably not make it [13:04] ah ok [13:04] sorry, I should have mentioned that above [13:04] zyga: you coming? [13:04] no, sorry [13:04] ah ok [13:15] the cmd/snap unit tests really need the new WrappedEquals checkers -- otherwise you can't run them from the 'go test -c' binary unless your terminal is 80 columns (or you redirect stdin) [13:16] mborzecki: do you see what i mean about StandbyOpinions not being goroutine-safe? [13:18] mborzecki: OTOH, why is timerCh an attribute, instead of a variable? [13:18] Chipaca: heh, probably went through a couple of review changes [13:20] Chipaca: using tomb we'd drop stopCh, then timerCh could be variable and we're left with AddOpinion() which could use some locking but not necessarily, slapping a comment that it needs to be called before Start() should be sufficient [13:20] mborzecki: also setting closeCh to nil doesn't make sense; you want it closed, not nil, so the receive works (as opposed to blocking on nil) [13:21] Chipaca: oh and daemon should probably wait for standby to finish [13:21] Chipaca: right now it does not [13:24] mborzecki: are either of your PRs fixing the ... value *errors.errorString = &errors.errorString{s:"dbus: connection closed by user"} ("dbus: connection closed by user") failure? [13:25] Chipaca: nope, where did you get that one? [13:26] mborzecki: /snap/bin/go test -count=100 -failfast ./cmd/snap [13:27] mborzecki: fails with that rather quickly [13:27] mborzecki: /snap/bin/go becaue 1.10 has -failfast [13:28] Chipaca: hmm is godbus reusing the connection? [13:29] mborzecki: dunno :-) i'm skipping the test to go on and find the hanging one [13:34] more pre-refresh hook questions! Is it possible to manually run a hook? Otherwise testing this is a bit tricky. [13:34] perhaps via "snap run --shell " [13:35] that gives you a shell inside the snap env ... [13:36] ooh, that might do it, thanks ogra [13:36] Chipaca: it is reusing the connection [13:48] PR snapd#6040 closed: data/apt: close stderr when calling snap in the apt install hook [13:56] zyga: ping [13:56] yes? [14:00] zyga: problem with the ptrace thing in other arches [14:00] zyga: PTRACE_GETFPREGS i mean [14:00] zyga: syscall.PTRACE_GETFPREGS is not always there [14:00] i'm adding a test for this, hopefully [14:01] xnox: are you around? question about gcc-arm-linux-gnueabihf vs gcc-multilib [14:02] yes [14:02] I think that's an arch specific thing but let me look [14:03] zyga: do you know about gcc-arm-linux-gnueabihf vs gcc-multilib? [14:03] probably not [14:03] ok [14:04] http://man7.org/linux/man-pages/man2/ptrace.2.html [14:04] Chipaca: floating point regs, not on all arches [14:05] Chipaca, sup? two are different; and also different depending on the host's arch. [14:05] Chipaca, so which host arch are you on, what are you using, and why / what do you want to achieve? [14:06] xnox: I was once again trying to cross-build go to armhf, and your blog post is my only reliable reference :-) but every time I come to it I have to install one and remove the other, and then time passes and I have to reverse it, and it seems broken [14:06] xnox: so I was wondering if that was The Way, or if it was outdated and I was missing a trick [14:06] ha [14:06] Chipaca, which blog is that? [14:06] http://blog.surgut.co.uk/2014/06/cross-compile-go-code-including-cgo.html [14:06] I use this vintage tech called a "bookmark" [14:07] Chipaca, no idea what that is? is like a star? [14:07] :) [14:07] Chipaca, also well, click chroots, don't exist anymore.... so do you use $ mk-sbuild --arch armhf bionic ; schroot -u root -c bionic-armhf ? [14:08] xnox, nah, starts are for favourites ... [14:08] xnox: CGO_ENABLED=1 GOOS=linux GOARCH=arm CC=arm-linux-gnueabihf-gcc GOPATH=~/canonical/snappy/ go build -v -o /dev/null ./cmd/snap-seccomp/ [14:08] (the GOOS is spurious and you can ignore it) [14:08] Chipaca, gcc-multilib is usually to allow building "co-pairs" of things - e.g. armel/armhf/arm64 on arm platforms; i386/amd64 on x86 platforms and so on. [14:09] gcc-arm-linux-gnueabihf is a generic cross-compiler which should be available on all arches; and as a bonus point it is the native compiler on armhf. [14:09] this way wherever one is, one should always be able to install and use gcc-arm-linux-gnueabihf [14:09] Chipaca, i'm not sure how/why/where that would conflict with gcc-multilib [14:09] cause it shouldn't..... [14:10] and if you are doing all that, you shouldn't need to ever install gcc-multilib, on any host. [14:10] xnox: ah, ok. Then don't look because you'll get lost down the warren. [14:10] Chipaca, i see that gcc-multilib declares conflicts on everything.... so like stop using gcc-multilib i guess? [14:11] xnox: ok, I'll stay like this, and the next time I need to revert it I'll flag you down again [14:11] maybe the other flow is broken :-) [14:11] xnox: thank you [14:11] Chipaca, on the surface, i see that gcc-multilib potentially overdeclares conflicts..... [14:26] jdstrand, I could use your help with bug #1738164 (see my last two comments). I now have a yubikey 4 so I can easily test things [14:26] Bug #1738164: [snap] U2F doesn't work with yubikey

[14:29] Chipaca: so -count=n with dbus test does not work because the connection is shared, there is one reference in used and another one in dbustest, i'm working on some changes to use private connection instead [14:33] mborzecki: ok [14:33] mborzecki: I've forked to writing a mutliarch spread test [14:47] ogra: can you still reproduce those rpi wifi issues you were mentioning me some time ago? [14:49] is master fixed now? [15:00] ppisati, it seems to have been gotten a bit more stable lately but i still see it reboot at times (i have a acrit that pings the GW and force-reboots the board if it cant reach it) see https://paste.ubuntu.com/p/B7kDjxjKbt/ [15:01] *a script === chihchun is now known as chihchun_afk [15:03] popey: I know what the bug is [15:03] it's very simple to fix [15:03] man [15:03] THANK YOU [15:03] it's super important!!! [15:07] zyga: oh!? [15:07] I will land a quick one liner [15:07] but then proceed with better fix [15:07] I love a one-liner [15:07] I also added a logging subsystem to show what is going on [15:13] ogra: are you using a raspberrypi official power supply? [15:14] ppisati, nope, a 2A phone charger [15:16] Chipaca: hey [15:16] do you have a sec? [15:16] ogra: ok, if you could get one and try that, it will surely help - with my rpi3b+ i encountered a lot of instabilities, in particular duing the boot phase, and they all went away when i switched to an official raspberry power supply [15:17] ogra: other than that, a tentative fix landed in the rpi tree so i might have a kernel to test, if you could give it a spin [15:18] PR snapd#6044 opened: cmd/snap-confine: remove stale mount profile along stale namespace [15:18] ppisati, well, i can surely try but thats a normal pi3 ... i doubt it is underpowered ... there is a USB wbcam attached that permanently streams though ... my guess would rather go towards USB saturation than to missing power [15:18] sure, i'll happily test [15:19] zyga: more or less, why? [15:19] Chipaca: can you please look at https://github.com/snapcore/snapd/pull/6044 [15:19] PR #6044: cmd/snap-confine: remove stale mount profile along stale namespace <⚠ Critical> [15:19] it's pretty critical [15:19] I wanted to do a staged patch, a quick fix that is provided here [15:19] (needs a bit though, this image is not running a sideloaded kernel, i'll need to build a new one) [15:19] a more lengthy fix that uses snap-discard-ns instead of reimplementing it locally [15:19] zyga: is this the one for --classic not going away? [15:19] and perhaps a spread test if I can come up with a way to write one [15:19] no, for mount profiles going away on base refreshes [15:20] or breaking all desktop apps [15:20] :/ [15:20] popey: ^ [15:20] that's the fix [15:20] it won't fix any affected systems but for those snap-discard-ns can be ued [15:21] subsequently it will be OK [15:21] ah [15:21]