[05:46] <mborzecki> morning
[05:50] <mborzecki> mwhudson: to satisfy your curiosity, this may have been an issue on the snapd side too: https://github.com/snapcore/snapd/pull/10911 apparently calling os.File.Fd() on a file made from UnixConn has some unwanted side effects
[05:50] <mup> PR #10911: daemon: use the syscall connection to get the socket credentials <Needs Samuele review> <cherry-picked> <Created by mardy> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10911>
[06:22] <mborzecki> mardy: hah nice, https://github.com/snapcore/snapd/pull/10945 can we bikeshed with benchmarks now? 🙂
[06:22] <mup> PR #10945: osutil/disks/labels: simplify decoding algorithm <Simple 😃> <Skip spread> <Created by mardy> <https://github.com/snapcore/snapd/pull/10945>
[07:01] <pstolowski> morning
[07:08] <mborzecki> pstolowski: hey
[07:10] <flotter> Is ubuntu Trusty/14.04 still a valid target in snapd as of today? 
[07:10] <flotter> Is ubuntu Trusty/14.04 still a valid target in snapd as of today?
[07:11] <pstolowski> jamesh: hi, can you take a look at https://github.com/snapcore/snapd/pull/10867 when you have some time?
[07:11] <mup> PR #10867: desktop, usersession: observe notifications <Created by stolowski> <https://github.com/snapcore/snapd/pull/10867>
[07:11] <jamesh> pstolowski: sure.
[07:14] <pstolowski> thanks
[07:15] <flotter> I see spread testing includes trusty, but multipass/lxd no longer supports it from what I can achieve from a fresh install. Getting tricky to test anything trusty related unless there are some other tricks.
[07:17] <mborzecki> flotter: trusty cloud images should still be avaialble at https://cloud-images.ubuntu.com/
[07:19] <flotter> mborzecki: yes true, thanks. Is there a simple story why this is still supported?
[07:20] <mborzecki> flotter: iirc it's because of livepatch being distributed via snaps only
[07:26] <flotter> "ESM for 14.04 provides ongoing kernel security fixes through a secure, private archive for three years until April 2022"
[07:27] <flotter> mborzecki: Thank you for pointing me in the right direction, makes sense now!
[08:27] <mwhudson> mborzecki: what on earth!!
[08:35] <jamesh> mwhudson: if a feature isn't needed by livepatch, it's not guaranteed to work on trusty though
[08:36] <mwhudson> jamesh: that was a reply to a much earlier message :)
[08:36] <jamesh> ah
[08:37] <mup> PR snapd#10945 closed: osutil/disks/labels: simplify decoding algorithm <Simple 😃> <Skip spread> <Created by mardy> <Merged by mardy> <https://github.com/snapcore/snapd/pull/10945>
[08:43] <mborzecki> https://github.com/snapcore/snapd/pull/10947 needs 2nd review
[08:43] <mup> PR #10947: tests: run spread tests on debian 11 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10947>
[08:57] <mup> PR snapd#10944 closed: [RFC] o/snapstate: maintain a stack of enforced validation sets per snap revision <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/10944>
[09:02] <mup> PR snapd#10914 closed: spread: fix lxd channel for pc-i386 <Created by xnox> <Closed by xnox> <https://github.com/snapcore/snapd/pull/10914>
[10:12] <mup> PR snapd#10949 opened: tests: ensure systemd-timesyncd is installed on debian <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10949>
[10:14] <ack> hi, I have a clean impish install here. is it expected that I get snapd 2.53 as a deb, while the snapd snap is not installed?
[10:16] <mborzecki> ack: are any other snaps installed?
[10:17] <ack> mborzecki, a lot
[10:18] <mborzecki> ack: can you list them? and also provide output of `SNAPD_DEBUG=1 snap version`
[10:19] <ack> mborzecki, https://paste.ubuntu.com/p/D4g6Q6k43M/
[10:20] <ack> is 2.53 stable?
[10:21] <mborzecki> ack: bit weird, i would expect the snapd snap to be there, but maybe it's something funny about reexec again, as the snapd package in deb is 2.53, so newer than the one from core
[10:21] <mborzecki> ack: no
[10:21] <ack> mborzecki, right, I thought it would get installed automatically, always was in the past
[10:23] <ack> mborzecki, I guess installing it won't make a difference though, as it's older than the deb anyway?
[10:24] <mborzecki> ack: yes, the host binaries will still be used
[10:25] <ack> mborzecki, ok, it's not really an issue. I just got tricked by the fact that I thought snap-refresh-control plug was available in stable snapd, but it's not yet :)
[10:36] <pstolowski> miguelpires: hi, afair you implemented a test checker for comparing containers regardless of the ordering, can you remind me the name? i completely fail to find it ;/
[10:40] <miguelpires> pstolowski: it's DeepUnsortedMatches 
[10:41] <miguelpires> it's in testutil
[10:42] <pstolowski> miguelpires: right! thanks1
[10:43] <miguelpires> yw :] 
[11:12] <mup> PR snapd#10950 opened: asserts, o/snapstate: honor ignoreValidation flag on snaps when checking installed snaps <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10950>
[11:58] <mup> PR snapd#10951 opened: sandbox/apparmor, interfaces/apparmor: detect bpf capability, generate snippet for s-c <Needs security review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10951>
[12:15] <jamesh> pstolowski: just sent through those review comments.  Sorry for the delay.
[12:16] <pstolowski> jamesh: np, thanks for the review. I was too busy with other things too notice the delay ;)
[12:18] <jamesh> pstolowski: I think all code in the fdo backend accessing the ID maps needs to be protected by the mutex. As well as the possibility of having concurrent SendNotification() calls, we've got the signal handler goroutine running that could update the maps at any time.
[12:22] <pstolowski> jamesh: oh, i must have missed those cases. thanks, also for the extra insight in your other comments
[12:58] <mup> PR snapd#10952 opened: tests/lib/pkgdb: install strace on Debian 11 and Sid <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10952>
[14:38] <mup> PR snapd#10953 opened: tests/main/snapd-sigterm: fix race conditions <Created by mardy> <https://github.com/snapcore/snapd/pull/10953>
[14:40] <mardy> ijohnson[m]: hi! Unfortunately the previous attempt to fix the tests failed, so I made a new one ^
[14:40] <mardy> ijohnson[m]: I don't know if you want to backport that one too (maybe not, since it only affects the tests?)
[14:52] <ijohnson[m]> mardy hmm I'll have a look 
[14:52] <ijohnson[m]> Thanks for the ping 
[15:09] <mup> PR snapd#10954 opened: tests: update the ubuntu-image channel to candidate <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10954>
[17:09] <mup> PR snapd#10948 closed: tests: skip interfaces-timeserver-control on debian-sid <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10948>
[17:51] <tokam> Hi
[17:51] <tokam> I cannot remove the leagueoflegends snap 
[17:52] <tokam> https://paste.ubuntu.com/p/hdPBHGczTX/
[17:52] <tokam> Maybe I caused this fault by closing the tty of an running snap remove leagueoflegends process
[17:53] <tokam> it did not react to my ctrl + c so I killed it. because I forgot to add --purge and it has several GB 
[17:53] <tokam> now it is in a bad state I can neither enable it or refresh or install or remove it
[17:53] <tokam> is it possible to somehow manually remove it?
[17:54] <tokam> if I want to enable it, it says: - Sicherheitsprofile für Snap "leagueoflegends" (95) einrichten (cannot find installed snap "leagueoflegends" at revision 95: missing file /snap/leagueoflegends/95/meta/snap.yaml)
[18:47] <tokam> https://paste.ubuntu.com/p/CJC3Dn4D87/
[18:48] <tokam> once again as posted on 19:52 I like to make clear that I killed the snap proccess while removing leagueoflegends without --purge
[19:11] <tokam> https://paste.ubuntu.com/p/XyT96HxYRB/