[03:02] PR snapd#10719 opened: interfaces/network-control: additional ethernet rule [06:05] morning [06:10] pstolowski: hi! [06:26] pstolowski: mardy: morning [06:28] mborzecki: hi! [06:38] a trivial needs 2nd review: https://github.com/snapcore/snapd/pull/10713 [06:38] PR #10713: tests: use host-scaled settle timeout for hookstate tests [06:52] PGP during unit tests but this time on OBS https://paste.ubuntu.com/p/Brxxc2VW6x/ so it's not only ubuntu where we see this [07:03] PR snapd#10702 closed: interfaces: introduce snap-refresh-control interface [07:04] ahh no, i was tweaking it ;) [07:08] pstolowski: do tweaks in a followup [07:08] yeah just did [07:08] at least somethign landed :P [07:08] https://github.com/snapcore/snapd/pull/10720 [07:08] PR #10720: interfaces: no need for snapRefreshControlInterface struct [07:08] PR snapd#10720 opened: interfaces: no need for snapRefreshControlInterface struct [07:23] PR snapd#10721 opened: interface/builtin: add qualcomm-ipc-router interface for AF_QIPCRTR socket protocol (2.52) [07:27] o/ [07:27] hello [07:27] hej zyga [07:38] PR snapd#10720 closed: interfaces: no need for snapRefreshControlInterface struct [07:50] good news! 10634 is green green, i.e. all tests happy - it looks like we solved a lot of the recent flakyness in the tests [07:50] WELCOME GO MODULES [07:50] (let's see how much breaks after this merge ;) [07:53] PR snapd#10634 closed: many: move to go modules [08:11] yay! [08:20] jamesh: hi! When you have a minute (or two :-) ), please give another look to the portals PR [08:29] hey mvo :) [08:29] congrats on modules [08:29] I hope that debian side of that won't be a problem [08:29] I've spent several days looking at go in yocto and it's not a happy picture [08:32] mardy: hi. Sorry for the delays. [08:33] zyga: I had a go at trying to set up a Debian-friendly Go package build, and got something that mostly works [08:34] jamesh in yocto the problem is with the missing fetcher [08:34] so the package is not really offline-friendly [08:34] hey zyga - in a meeting right now, sry, will get back to you :) [08:34] packaging anything but applications is thus a bit pointless [08:34] zyga: the trick was to run a bunch of "go mod edit -replace ..." calls to point all the dependencies at the packaged versions under /usr/share/gocode [08:34] mvo no worries, just saying hello [08:34] jamesh that's interesting [08:35] did you run into multi-version problems? [08:35] I found that check.v1 has two versions of one library as a dependencyu [08:35] one for itself [08:35] and one for another dependency [08:35] I don't want to fight that, just embrace `go mod download` with a fetcher [08:36] so that we don't package libraries, just apps but with the correct offline files and correct (complex) license tracking [08:36] that's the plan I've shared with the yocto go maintainers and they seem to align [08:37] zyga: I personally think distro packaging Go libraries is a losing proposition, so I was mainly doing it from the point of view of reducing friction with Debian rather than because I think it is a good idea [08:37] I agree [08:37] it'd be possible iff debian and yocto actually had multi-version libs [08:37] since they don't, it's really pointless to try [08:37] zyga: as far as multiple versions, you should only end up with a single version of each major version of a library in the executable [08:38] that's true [08:38] but test deps are different [08:38] even if the go.mod files for the dependencies reference different versions [08:38] yes [08:38] I've read the mod spec (painfully long) [08:38] since they define the same types [08:38] but since tests are separate built binaries [08:38] they do end up with two [08:38] one in each package [08:38] so some insanity if you want to package the libs as two separate versions [08:39] so technically check.v1 depends on two different versions for a complete, tested build [08:39] oh fun :) [08:40] On the Debian side, I don't think it really matters: you'd only have a single copy of check.v1 packaged, so you'd replace them both to the same version [08:41] (even though that's not what the upstream tested) [08:50] zyga: anyway: this was the proof of concept: https://git.launchpad.net/~jamesh/+git/go-mod-test/tree/?h=main [08:51] PR core20#112 opened: doc: add instructions on enabling bootcharts [08:56] jamesh yes but I think in the long term that's going to be very painful unless we're lucky (no API breakage) and it's fully automated around distro tooling [08:56] that's very interesting though [08:57] jamesh it's funny we have nearly the same go dependencies [08:57] check and dbus [08:58] zyga: in a modules world, API breakage should be accompanied by a major version bump (unless it is a v0 package) [08:58] yes [08:58] so pre-modules and v0 are indeed the problem [08:58] I think modules are a bit immature though, in the community, and people are likely not to bump the version reliably yet [08:59] I don't think there is an equivalent of ABI checker that's used by default for go [09:01] zyga: you see that kind of problem in pretty much all language environments though [09:03] PR snapd#10713 closed: tests: use host-scaled settle timeout for hookstate tests [09:04] heh gopls it totally confused with modules right now when master has it but some of the branches i work on don't [09:07] mborzecki yeah, happens to me too [09:07] just restart gopls [09:23] heh i see set -u leaking somewhere to the test from sourced files [09:44] PR snapd#10722 opened: tests/nested/manual/refresh-revert-fundamentals: fix variable use [09:44] should be trivial ^^ [10:12] mvo: I just updated to master and I get a local diff after running get-deps [10:23] meh systemd reloading its bpf programs is kind of annyoing [10:33] pedronis: Hi! I wanted to ask about your feedback on https://github.com/snapcore/snapd/pull/10704; do I understand it correctly, that you are suggesting to replace the dummy implementation of the methods with calls to the real systemd, so that this type could be used in existing tests without much changes? [10:33] PR #10704: systemd: add fake type for easier mocking of systemd functions [10:34] PR snapd#10723 opened: o/ifacestate: special-case system-files and force refreshing its static attributes [10:44] PR snapd#10724 opened: many: update deps [11:02] fun, now getting EPERM on any bpf operation on sid :/ [11:12] interestingly only when the service is started by systemd [11:17] mborzecki systemd cgroups in effect? [11:18] zyga: i don't think so, there's only EPEM when creating a map or attaching a program [11:18] hmm [11:18] zyga: fwiw BPF_OBJ_GET works, so not all bpf syscalls fail [11:18] hmm [11:19] which cgroup the service is in at the time? [11:19] is there any stacking of cgroups going on? as in a bfp program attached up in the hierarchy [11:19] is that a system or user service? [11:19] PR snapd#10719 closed: interfaces/network-control: additional ethernet rule [11:20] zyga: the one systemd created, but the program should be allowed to create a map at least [11:20] (that's even before it tries to attach a program with BPF_PROG_TYPE_CGROUP_DEVICE [11:20] and when you did the test without systemd in the way, what was the cgroup you were in? [11:21] right but even then you may have a seccomp filter attached [11:21] that was a as user, but it worked for both root and uid 1000+ [11:22] and when does it not work? [11:22] zyga: when running as a system service, and only seen this on sid [11:23] hmm [11:23] new systemd? [11:23] new filters applied [11:23] different configuration options [11:23] not newer than what i have on arch and tw [11:24] can you check the bpf program attached to snap-confine as it starts up?/ [11:26] brb, reboot [11:47] re [11:50] Morning folks [11:51] pstolowski hey do you think you can just include the working version of my regression test in your PR fixing the system-files thing? I think it would be ideal to have the spread test in the same branch/PR as the fix [11:51] ijohnson[m]: sure i can [11:53] Thank you! [11:53] I will close mine then [11:54] PR snapd#10707 closed: tests/regression: add regression test for LP #1942266 [11:56] pedronis I noticed the same thing too, we seem to have an untidy go.mod [11:57] The solution to this is to ensure that go.mod is tidy as part of run-checks I think [11:59] hey ijohnson[m] :) [12:15] jamesh: thanks for the review! [12:16] now if someone is bored, I promise that https://github.com/snapcore/snapd/pull/10628 is super exciting! ;-) [12:16] PR #10628: usersession/xdgopenproxy: move PortalLauncher class to own package [12:26] do we have some randomness in our unit tests? I'm asking because looking at the coverage changes, they often report changes in files which cannot be possibly affected by the PR: https://app.codecov.io/gh/snapcore/snapd/compare/10704/changes [12:32] Hey zyga-mbp [12:33] mardy we certainly could maybe it would be worth trying to track which files that could not possibly have had their coverage change show up in PRs, that's probably where our non-deterministic coverage comes in [12:39] I know we have some tests about sorting helper that show some coverage randomness [12:39] mardy: I made some comments in the systemd testing PR [12:40] ijohnson[m]: mvo: what's the status with core20 issues? is it worth re-running tests in PRs or not yet? [12:44] ijohnson[m]: #10723 now includes your test [12:44] Bug #10723: shadow: new changes from Debian require merging [12:44] PR #10723: o/ifacestate: special-case system-files and force refreshing its static attributes [12:45] pedronis yeah core20 in edge is working now [12:45] Great thanks [12:45] pedronis : mvo managed to land the revert into core20 edge channel before I landed my PR switching to beta channel so it was unnecessary and things are happy again [14:27] mvo: I added https://github.com/snapcore/snapd/pull/10723 to the 2.52 milestone I think we should include it in 2.52 if possible [14:27] PR #10723: o/ifacestate: special-case system-files and force refreshing its static attributes [14:29] cachio_: do you think you could take a look at https://github.com/snapcore/snapd/pull/10718 ? it has 2 +1's but I'd like your review before landing it [14:29] PR #10718: tests/lib/prepare.sh: download core20 for UC20 runs via BASE_CHANNEL [14:55] PR snapd#10725 opened: o/hookstate: require snap-refresh-control interface for snapctl refresh --proceed [15:24] mvo: ijohnson[m]: I get this state on master D vendor/.gitignore after get-deps.sh [15:26] ah, miguelpires PR addresses that too [15:31] pedronis: yeah miguelpires 's PR fixes that too [15:39] mborzecki: I re-reviewed the remodel PR, it still seem that some situations are not covered by the code, see my comments [15:39] mvo can you merge this https://github.com/snapcore/snapd/pull/10724 please? [15:40] PR #10724: many: update deps [15:40] PR snapd#10726 opened: systemd: add mock systemd helper [15:45] PR snapd#10704 closed: systemd: add fake type for easier mocking of systemd functions [15:54] miguelpires: sure [15:55] PR snapd#10724 closed: many: update deps [16:21] ijohnson[m], sorry, for the delay, I'll take a look [16:40] thanks [16:40] * ijohnson[m] -> lunch [17:05] PR snapd#10678 closed: o/snapstate: enforce validation sets assertions when removing snaps

[17:10] PR snapd#10590 closed: image,c/snap,tests: support enforcing validations in prepare-image via --customize JSON validation enforce(|ignore) [20:00] ijohnson: trying to make xdo available in opensuse https://build.opensuse.org/request/show/916054 next step will be to prepare a pr for etrace [20:01] bboozzoo: oh hey! I was actually just looking at using xdo in etrace, it seems like this order of command works (with various options for identifying the window): [20:01] xdo id -m -N "Antstream Arcade"; while xdo id -N "Antstream Arcade" > /dev/null; do xdo close -N "Antstream Arcade"; done [20:01] the problem is that `xdo kill` kills the client before the window is actually displayed [20:02] ijohnson: ha, that's interesting [20:02] but `xdo close` doesn't work totally until the window is displayed, otherwise it just returns with exit code 0 as if nothing happened [20:02] so you have to keep calling close in a loop until the window is actually properly closed and can't be identified anymore [20:02] at least that is the most logical sequence of events I could figure out [20:02] ijohnson: have you maybe tried to raise the window? [20:03] bboozzoo: hmm let me look, I didn't try anything with raise [20:04] nope, raise doesn't block waiting for the window to actually be visible either [20:04] heh [20:04] but that's maybe an interesting question to see if the other commands manipulating the window would block until it's actually visible [20:05] ijohnson: there are actual 'show' and 'hide' commands, but i guess the problem is that the window isn't painted yet [20:06] (or mapped?) anyways iirc you actually have to create a window before, so it already has an id, don't recall though if properties are already set by this time [20:07] yeah that seems to be the problem indeed, none of the show/hide/raise/lower/resize commands actually block until the window is painted/mapped so they just return [20:07] in any case I think the loop of trying to close the window until it no longer shows up with `xdo id` seems to work well enough [20:09] hm wonder if all we need is maybe a simple hack in xdo to call xcb_get_geometry() and check whether the window is mapped [20:10] yeah I dunno, I suppose we could patch/hack on xdo inside the snap of etrace [20:11] heh, it's 2 C files and 2 headers ;) [20:11] oh wow haha [20:13] ijohnson: anyways, need to wrap it up, if you plan to open a PR to etrace then please ping me in it and i'll give it a try tomorrow morning [20:13] bboozzoo: yeah probably not tonight, just exploring a bit how xdo works and looking at the bugs popey filed for me :-) [20:14] sure thing [21:37] Hey all. I'm pretty new to Ubuntu Core and I'm having a network issue that's giving me trouble. Ubuntu Core 20 with the LXD snap. Running a container with a proxy device. If I ssh into Core host, I can see port is bound to `*:[port]` in `ss`, but I cannot hit that port from outside of the Core host. [21:38] grip__: you might have better luck asking your question on the forum, either the snapcraft forum or the LXD forum, since many folks are offline for EOD and may not see your message here [21:41] Thanks, ijohnson[m]. I'll give it a go on the snapcraft forum. Far as I can tell, LXD is doing what it's supposed to so better to start there, I guess.