[00:50] <mup> PR snapd#10856 opened: osutil/disks: add Disk.KernelDevice{Node,Path} methods <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10856>
[01:45] <mup> PR snapd#10857 opened: osutil/disks: add Partition struct and Disks.Partitions() <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10857>
[02:10] <mup> PR snapd#10858 opened: osutil/disks: add Disk.FindMatchingPartitionWith{Fs,Part}Label <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10858>
[05:46] <mborzecki> morning
[06:06] <zyga-mbp> good morning :)
[06:08] <mardy> 'morning mborzecki, zyga-mbp
[06:08] <mborzecki> mardy: zyga-mbp: hey
[06:08] <mborzecki> snapd in fedora is broken, same thing as in tumbleweed 😕
[06:09] <zyga-mbp> how are cgroup things going?
[06:09] <zyga-mbp> mborzecki oh?
[06:09] <zyga-mbp> on cgroups or on something else?
[06:09] <mborzecki> yeah, i need to add clone3 to the default seccomp profile, not sure how it didn't come up earlier, but maybe new glibc/go is triggering this code path now
[06:10] <zyga-mbp> I remember clone3, it was long while ago
[06:10] <zyga-mbp> clone with struct instead of flags, right?
[06:12] <zyga-mbp> mborzecki can I help you with karma or anything else?
[06:13] <mborzecki> zyga-mbp: i haven't pushed updates to bodhi yet, but i'll ping you when i do
[06:13] <zyga-mbp> ok
[06:22] <mardy> mborzecki: you mentioned that I should pay attention to snap-update-helper if I leave the PID in the snap scope created by systemd, but you also said that for cgroup v2 there's some code which locates the right cgroups; can you please point me to that?
[06:39] <mborzecki> mardy: https://github.com/snapcore/snapd/blob/master/sandbox/cgroup/freezer.go#L180 take a look here
[06:40] <mborzecki> mardy: there's applyToSnap which walks the hierarchy basically
[06:42] <mardy> mborzecki: ah, ok, but I cannot reuse it as-is, right? snap-device-helper is in C
[06:44] <mardy> mborzecki: of course another alternative is to create a symlink (or just a text file) somewhere, which tells the path to the real cgroup. Somewhere under /var/run/ maybe.
[06:44] <mborzecki> mardy: there's some C code for a similar purpose https://github.com/snapcore/snapd/blob/master/cmd/libsnap-confine-private/cgroup-support.c#L159
[06:49] <mardy> mborzecki: thanks!
[07:02] <pstolowski> morning
[07:22] <mvo> good morning pstolowski
[07:27] <mardy> pstolowski: hi!
[07:28] <zyga-mbp> hey mvo!
[07:32] <mborzecki> mvo: hi, can you cherry pick this fix to 2.52? https://github.com/snapcore/snapd/pull/10565
[07:32] <mup> PR #10565: cmd/libsnap-confine-private: g_spawn_check_exit_status is deprecated since glib 2.69 <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10565>
[07:32] <mborzecki> damn, not this one
[07:32] <mborzecki> ah yes, this one 🙂
[07:38] <jamesh> pstolowski: I've left some feedback on your notifications PR
[07:40] <pstolowski> jamesh: thank you!
[07:41] <jamesh> pstolowski: I could also see a bunch of complaints about imports from a "gci" linter.
[07:41] <jamesh> looks like it wants new lines in different places for some of the import lists
[07:43] <pstolowski> yeah i saw those
[07:50] <mvo> mborzecki: sure
[07:51] <mvo> mborzecki: done
[07:51] <mborzecki> mvo: thank you!
[09:31] <mup> PR snapd#10859 opened: snap-confine: do not create an additional cgroup <Created by mardy> <https://github.com/snapcore/snapd/pull/10859>
[09:51] <mborzecki> mardy: i've force pushed to the branch that waits for job removed, idk the dbustest thingy is rather flaky, i'm getting errors at random related to the mocked transport
[10:16] <mborzecki> mardy: ok, cleaned it up and opened https://github.com/snapcore/snapd/pull/10860
[10:16] <mup> PR #10860: sandbox/cgroup: wait for start transient unit job to finish <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10860>
[10:16] <mup> PR snapd#10860 opened: sandbox/cgroup: wait for start transient unit job to finish <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10860>
[10:36] <mardy> mborzecki: will look at it soon
[10:37] <mardy> I'm getting similar errors when connecting interfaces: cannot compile /var/lib/snapd/seccomp/bpf/snap.microk8s.hook.remove.src: error: cannot parse line: cannot parse token "AF_QIPCRTR" (line "socket AF_QIPCRTR")
[10:39] <mardy> I see these errors when using the snapd I built from the master branch ^
[10:44] <mborzecki> mardy: i think this should degrade gracefully, but maybe i'm mistaken
[11:32] <mup> PR snapd#10861 opened: snap-bootstrap: wait in `mountNonDataPartitionMatchingKernelDisk` <Created by mvo5> <https://github.com/snapcore/snapd/pull/10861>
[11:53] <mardy> mborzecki: ah, I think it's because I have the new snapd but the old snap seccomp parser
[12:08] <mborzecki> hmmm, that systemd job branch failed a lot on 18.04
[12:09] <mborzecki> as in barely anything ran at all
[12:19] <ijohnson[m]> mvo: can you force merge https://github.com/snapcore/snapd/pull/10852 ? the failures are unrelated
[12:19] <mup> PR #10852: osutil/disks: add DiskFromDevicePath, other misc changes <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10852>
[12:21] <ijohnson[m]> mardy: can you share where you saw that failure around AF_QIPCRTR ? we made the apparmor bits for that conditional on apparmor_parser supporting it, just wondering if we need to make the seccomp bits conditional in some way too?
[12:33] <mardy> ijohnson[m]: it was because I was running the new snapd, whereas snap-seccomp was still the old one. I don't think this is going to affect users
[12:33] <ijohnson[m]> Oh okay I see yeah snap-seccomp doesn't re-exev
[12:33] <ijohnson[m]> *re-exec
[13:17] <mup> PR snapd#10852 closed: osutil/disks: add DiskFromDevicePath, other misc changes <Simple 😃> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10852>
[15:48] <mup> PR snapd#10855 closed: tests: reset some mount units failing on ubuntu impish <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10855>
[16:38] <mup> PR snapd#10862 opened: osutil/disks: add RootMountPointsForPartition <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10862>
[17:58] <mup> PR snapd#10863 opened: tests: fix nested tests on uc20 <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10863>
[18:29]  * cachio afk


[12:58] <penguin42> Danger! Robots with crumpets  https://ichef.bbci.co.uk/news/976/cpsprodpb/A319/production/_133035714_luton2024-ogrp-36.jpg.webp
[15:57] <davef> Get to the safety shelters!!
[16:07] <zxmpi> i'm in ireland by the sea, the salty damp is kryptonite for robots
[17:12] <penguin42> until the robots find the wd40
[17:55] <zxmpi> i'm betting on seagull crap dissolving their exteriors
[19:15] <daftykins> ah i picked up a bottle of Irn Bru today, what a treat
[19:20] <zxmpi>  haven't they changed the recipie?
[19:22] <daftykins> pass
[19:22] <daftykins> i'd imagine nothing's quite what it once was
[19:24] <zxmpi> i think it fell foul of a uk sugar tax iirc
[19:25] <zxmpi> ah ha, back to the original https://inews.co.uk/news/consumer/irn-bru-permanently-reintroduces-original-1901-high-sugar-recipe-scotland-924623
[19:27] <daftykins> \o/
[19:27] <daftykins> it does blab about 1901 on the label
[19:30] <zxmpi> there was a lot of unhappy scots after they took half the sugar out
[19:30] <zxmpi> all those extra years of healthy living stuck in scotland :-P
[19:31] <daftykins> "dunnae dewm us tah livin' 'ere longah!"


[12:57] <BluesKaj> Howdy folks
 both NVidia machines I own (1080 and 960M) are running the latest NVidia drivers and Opengl render with no issues.  It would be interesting to know if anyone else with 20 series NVidia cards experience the same issue.
 oops, wrong channel