[06:06] morning [06:11] 'morning! [06:12] mardy: heya [06:12] about https://forum.snapcraft.io/t/glaxnimate-snap-error/24313: is libstdc++ something that people should ship in their snap packages, or should it use the one from the system? [06:13] mardy: afaict libstdc++ is in core20/18/core so part of the base [06:15] and GLIBCXX_3.4.26 symbol version appears in the binary, so maybe some configuration/environment problem? [06:16] but only in libstdc++ from core20, so maybe a wrong base? (or kf5 uses core18 still) [06:17] wouldn't be suprised if it's a binary the built on 20.04 host and just dropped into a snap [06:17] s/suprised/surprised/ [07:03] morning [07:05] good morning pstolowski [07:06] PR snapd#10259 closed: interfaces/dbus: allow claiming 'well-known' D-Bus names with a wildcard suffix [07:14] mvo: hey [07:14] pstolowski: and hello there too [07:21] mborzecki: good morning! [07:22] hmm https://github.com/snapcore/snapd/pull/10241 is right now at 50MB, but some tests still fail, i've just merged master and will let it run, then we can maybe bump it to 60MB if still needed [07:22] PR #10241: tests: set memory limit for snapd [07:23] i guess we could run tar pipeline for snapshots, apparmor_parser and maybe something else in a separate scope but that's like accountants cooking the books tbh [07:24] anyways, still think that having an idea of an upper limit of memory requirement during the tests is useful [07:45] good morning guys [07:45] mvo spring is finally here :) [07:45] every morning is a joy :) [07:50] I have a layout rule like this: /usr/share: [07:50] symlink: $SNAP/usr/share/ [07:50] but then snapcraft fails with this error: error: cannot pack "/root/prime": cannot validate snap "libinput-tool": layout "/usr/share" uses invalid symlink old name "/snap/libinput-tool/unset/usr/share/": must be absolute and clean [07:51] sounds like $SNAP is not being expanded, but why? [07:51] it's weird that there's 'unset' there as well [07:52] but it's a snapcraft side logic, I don't know what's going on there [07:58] oh, changing /usr/share/ to /usr/share/libinput makes it work [08:06] good morning pedronis [08:12] mvo, good morning, and thanks for merging PR 10259 ! [08:12] PR #10259: interfaces/dbus: allow claiming 'well-known' D-Bus names with a wildcard suffix [08:13] oSoMoN: thank you! I cherry picked it for 2.50, it will be part of 2.50.1 which we plan to release in ~2 weeks [08:24] mvo, that's awesome, people at Mozilla will be happy to know that [08:48] mvo: will look at the armhf pi-gadget soon! [08:53] sil2100: I think waveform did some work there already [08:55] yay [09:03] mvo: promoted the latest edge armhf snaps to beta now [09:09] sil2100: \o/ [09:34] sil2100, yes thanks I confirm this problem is gone [09:34] the most difficult part for me is to find my usb/uart cable [09:39] rZr: thanks for confirming [09:40] yw [10:05] woot [10:05] mvo is that what I think it is?! :) [10:24] zyga: dtbs from the kernel - finally! [10:24] mvo that's amazing [10:25] thank you for carrying that torch all the way [10:32] zyga: :) thanks, appreciated. took a while but finally here [10:38] The manual tests with libinput show that this interface is kind of working, so reviews are welcome :-) https://github.com/snapcore/snapd/pull/10251 [10:38] PR #10251: interfaces/builtin: introduce raw-input interface [10:53] pstolowski: hi, is https://github.com/snapcore/snapd/pull/10182 read for re-reviews? [10:53] PR #10182: o/snapstate: autorefresh phase1 for refresh-control [10:53] pedronis: yes [10:53] pstolowski: thx, re-queued [10:53] ty [11:02] * ogra gives mardy a hug, i'm waiting for such an interface since ages 🙂 [11:36] PR snapd#10260 opened: secboot: switch encryption key size to 32 byte (thanks to Chris) [12:16] ijohnson: hi, I reviewed a couple of your PRs, there are questions in both [12:18] ijohnson: cachio: what's the state https://github.com/snapcore/snapd/pull/10165 ? does it just need a force merge or it's blocked on something else [12:18] PR #10165: tests: add tests about services vs snapd refreshes [12:22] pedronis, the code has the +2 [12:22] let me check the tests which failed [12:26] pedronis, the test failure in core18 seems to be unrelated [12:26] it is hte only one blocking [12:27] we can either re-run or force merge [12:27] pedronis, [12:48] let's see what ijohnson says [12:53] pedronis for 10165, it's ready to land there is just that issue we found where sometimes the test fails because it installs the wrong snapd snap, I think it may actually be related to the PR mvo opened on Friday about the .local-install bug [12:57] PR snapd#10261 opened: o/snapstate: refresh control - autorefresh phase2 [12:58] @mvo I'm probably gonna be 2-3 minutes late to SU, sorry about that a bit of a late start for me today [14:11] mborzecki: I reviewed https://github.com/snapcore/snapd/pull/10252 [14:11] PR #10252: boot: reseal given keys when the respective boot chain has changed [14:20] * cachio afk [14:46] I'm on the linter again :-) So, this line (https://github.com/snapcore/snapd/blob/master/interfaces/builtin/i2c_test.go#L70) is unused; should I just remove it, or is it waiting for a test to be written? [14:47] BTW, most of those members only get assigned to, otherwise they seem unused [14:47] mardy: probably either cargo culted from other tests or was at one point part of a test which then got refactored etc [14:49] mardy: probably not too hard to write a unit test to check for that case if you want to try, otherwise it can probably be deleted, I think we have pretty good coverage elsewhere in the codebase about that specific issue (an interface trying to be used as a different type of interface) [14:50] pstolowski: it looks like the commit which made it obsolete is yours (https://github.com/snapcore/snapd/commit/1cf702d11819b148d228baff341c89f9cd50471b#diff-ddce5b424337522fb4e0230136dfebdede5de499d5761678ec63df822f63259a) [14:51] interestingly though it doesn't even appear to be used in that commit :-) [14:53] oh wow, 2017 [14:53] sorry, i don't remember what was it about ;) [14:53] probably interface hooks work or something related, there were massive changes [14:53] pstolowski: no worries, I was just checking in case you would say "oh, that line is super-important, we absolutely need a test with it" :-) [15:28] mardy: so is socket AF_NETLINK and network netlink raw, actually needed in raw-input interface? [15:33] pstolowski: I suspect so to talk with udev, we have the same in raw-usb [15:34] pstolowski: I reviewed https://github.com/snapcore/snapd/pull/10182 and https://github.com/snapcore/snapd/pull/10187, they look good in itself but I have some more general questions/comments. Let me know if you have questions for me [15:34] PR #10182: o/snapstate: autorefresh phase1 for refresh-control [15:34] PR #10187: o/hookstate, o/snapstate: print revision, version, channel with snapctl --pending [15:34] i see [15:34] s/itself/themselves/ [15:36] mvo: there seem to be real spread failures in https://github.com/snapcore/snapd/pull/10260, maybe some of the spread tests need changes too? [15:36] PR #10260: secboot: switch encryption key size to 32 byte (thanks to Chris) [15:37] pedronis: yeah, I'm looking at those right now, thanks [15:55] pedronis: thanks for the reviews [16:00] PR snapcraft#3520 opened: package-repositories: remove experimental flag [16:04] pedronis: one question https://github.com/snapcore/snapd/pull/10217#discussion_r630319089 [16:04] PR #10217: o/servicestate: restart slices + services on modifications [16:06] mborzecki: I have a question in https://github.com/snapcore/snapd/pull/10253 [16:06] PR #10253: boot: helpers for manipulating current and good recovery systems list <⛔ Blocked> [16:08] ijohnson: I answered [16:09] pedronis: thanks I will take your suggestion [16:48] ugh why is systemd so hard [16:48] * ijohnson lunches [18:05] ijohnson, because it replaced upstart which was so wobbly ... 🙂 [22:28] PR snapd#10262 opened: tests/nested/manual: add test for install-device + snapctl reboot