[03:09] Bug #1916816 opened: File picker and other native windows have garbled fonts in Arch & Manjaro [03:12] Bug #1916816 changed: File picker and other native windows have garbled fonts in Arch & Manjaro [03:15] Bug #1916816 opened: File picker and other native windows have garbled fonts in Arch & Manjaro [03:40] oerheks: I ended up nuking the system, reinstalling snapd, then restoring from the snapshot that I made after things went south. Then I installed the Nextcloud snap after that. Everything is fine now -- I didn't lose anything. But my fs was boogered up from crashing, I guess. [03:53] oerheks: I ended up nuking the system, reinstalling snapd, then restoring from the snapshot that I made after things went south. Then I installed the Nextcloud snap after that. Everything is fine now -- I didn't lose anything. But my fs was boogered up from crashing, I guess. (repost in case you missed it, and in case you care) [06:56] morning [07:45] mvo: hey [07:48] good morning mborzecki [07:53] PR snapd#9884 closed: tests/main/snap-repair: test running repair assertion w/ fakestore [08:08] morning [08:09] alan_g: I think https://github.com/MirServer/snapd/pull/4 should help fix the spread failures in your desktop-launch PR [08:09] PR MirServer/snapd#4: usersession/userd: only pass --collect if we have a new enough systemd [08:13] PR snapd#9952 closed: interfaces: allow reading the Xauthority file KDE Plasma writes for Wayland sessions [08:18] mvo: can you cherry pick https://github.com/snapcore/snapd/pull/9952 to 2.49? [08:18] PR #9952: interfaces: allow reading the Xauthority file KDE Plasma writes for Wayland sessions [08:22] mborzecki: sure, done [08:22] mvo: thank you! [08:23] hmm the version i get in snap/snapd binaries built out of the development tree are weird, they are like `+git1000.gb5e86eb` [08:24] mborzecki: oh, hm, it should be relativel to the last stable tag [08:24] mkversion didn't change recently [08:31] mvo: https://github.com/snapcore/snapd/pull/9961 fixes it for me [08:31] PR #9961: mkversion: check that version from changelog is set before overriding the output version [08:32] (and I can refresh snapcraft again) [08:33] PR snapd#9961 opened: mkversion: check that version from changelog is set before overriding the output version [08:41] hello guys! [08:44] zyga: hey [08:44] https://git.ostc-eu.org/OSTC/OHOS/components/staging/xts_acts/-/pipelines/1156 [08:45] first spread job in openharmony [08:45] fingers crossed, it will probably not work okay :) [08:45] with a bit of luck the results will be displayed in gitlab UI [08:45] as a nice navigable set of suites and tests [08:46] mvo: intersting, didn't realize we had HostScaledTimeout, should we fixup all the places where settle and other timeouts are used in the tests? [08:47] mborzecki: it's probably fine, we added it because of the slow risv-v virtual builders but it's been a problem only in some of the tests [08:47] ok [08:47] mborzecki: in theory it would be good to be consistent but probably not worth it [08:47] mborzecki, it was added for riscv IIRC [08:47] zyga: woah, nice [08:48] mvo, exploring the unknown :) [08:49] zyga: "To boldly go where no man has gone before!" [08:50] mvo, I can repeat that, it will be even more interesting in zephyr === oerheks1 is now known as oerheks [09:48] PR snapd#9945 closed: cmd/snap, boot: add debug set-boot-vars === TooLmaN_ is now known as TooLmaN === jnsgruk0 is now known as jnsgruk === padge_ is now known as padge === not_phunyguy is now known as phunyguy === mborzeck1 is now known as mborzecki [10:17] mvo_, one more patch for spread https://git.ostc-eu.org/OSTC/packaging/spread/-/blob/master/debian/patches/0004-Allow-disabling-kvm-with-SPREAD_QEMU_KVM.patch [10:48] PR snapd#9962 opened: asserts: include the assertion timestamp in error message when outside of signing key validity range [11:01] cachio: hi, did you get a chance to play with the openssue images from yesterday? [11:20] pedronis_: do you think refreshing of validation set asserts on install/remove deserves own task handler? while on install we can do it in validate-snap, for remove i don't see a good candidate [11:24] PR snapd#9963 opened: wrappers: install D-Bus service activation files for snapd session tools on core === pedronis_ is now known as pedronis [11:27] pstolowski: we can't do it with a task, we need to do it before we do the actual operation [11:27] pstolowski: is the same as how we refresh snap-declarations [11:27] we do that from daemon or helper, not tasks [11:28] hmm [11:28] pstolowski: but yes, it's different from snap-declarations, we really need the snap declaration to do the actual ops, but for validations they matter before and during we talk to the store [11:28] not after [11:29] basically there is nothing to do in validate-snap about validation sets [11:29] pstolowski: you sound a bit confused, maybe we shouuld have a chat [11:33] pedronis: if you have a moment that would be great i think [11:36] pstolowski: going to the SU [12:00] mborzecki, hi [12:00] yes [12:00] I created a new image based on the one published for openstack [12:01] cachio: did you manage to get it to boot in gce? [12:01] it is getting stuck also that one [12:01] cachio: on govendor sync? [12:01] mborzecki, yes, I had to update that [12:01] mborzecki, yes [12:01] hey cachio [12:01] cachio: can i try that somehow? [12:01] the image is published [12:02] cachio, I have four patches for spread now [12:02] cachio, no luck in merging anything recently though [12:02] cachio: ah, so i can just lanuch a test on tw with spread and it should pick up the new image? [12:02] mborzecki, opensuse-tumbleweed-2-64-base-v20210224 [12:03] oh, ok [12:03] thanks [12:03] no [12:03] this is the new imaage [12:03] the disk is not big [12:03] but it is just for testing [12:03] zyga, hey [12:03] nice [12:03] zyga, it is difficult to merge patches in spread :) [12:04] zyga, which are the new patches? [12:12] cachio: thanks [12:13] cachio, I didn't open the PRs yet, they are all here: https://git.ostc-eu.org/OSTC/packaging/spread/-/tree/master/debian/patches [12:14] zyga, awesome, I'll take a look [12:14] cachio, I can open a few PRs if you want [12:14] we can discuss there [12:15] niemeyer_, do you have some time to review several small spread patches? [12:15] zyga, it is ok for me, if you have patches it is better to add a pr [12:16] cachio, yeah, I'll do that in a moment [12:18] tx [12:20] * cachio afk [13:04] mborzecki, hey https://paste.ubuntu.com/p/jVYtFCvbgP/ [13:04] this is what I found in tes tsecurity-dev-input-event-denied [13:05] adter connect the joystick, apparmor is not denying any more [13:05] something else is doing that [13:14] PR snapd#9964 opened: asserts: use Fetcher in AddSequenceToUpdate

[13:18] morning folks [13:38] hey ijohnson [13:38] hello zyga [13:38] cachio, udev [13:38] cachio, you can verify that by looking at the device cgroup [13:38] and listing the set of allowed devices [13:39] cachio, check out /sys/fs/cgroup/devices/snap.snap-store.ubuntu-software/devices.list (the snap name is just an example) [13:40] compare that with stat /dev/input/event2 [13:40] it's based on major:minor numbers [13:42] on that [13:43] zyga, access is different [13:43] https://paste.ubuntu.com/p/BtMyBXGVpW/ [13:44] https://paste.ubuntu.com/p/kB6WF8hrp4/ [14:25] cachio: got this on opensuse: https://paste.ubuntu.com/p/vZPPTtCy6z/ looks like we need to accept the key somehow [14:26] mborzecki, yes [14:26] update the line to zypper --no-gpg-checks ref [14:26] line 560 in spread.yaml [14:26] ok [14:44] cachio, stating the device cgroup file is useless, that is not relelevant there [14:44] cachio, just the major:minor of the input device [14:44] and the contents of the access list [14:44] but this should give you everything to debug the rest [14:45] zyga, sure, let me create a new debug session [14:57] mborzecki, I know that [14:57] * zyga thinks [14:57] there's a command line option to agree [14:58] cachio: heh, still fails in the kernel: https://paste.ubuntu.com/p/mH3C3ftRY8/ [14:59] mborzecki, yes [14:59] it is the same error that we got with the previous image [15:05] cachio: filed https://bugzilla.suse.com/show_bug.cgi?id=1182761 [15:07] mborzecki, awesome [15:07] thanks [15:08] hmm, maybe on monda i can try to fork their kiwi repo, and build as an image with ext4 instead of xfs [15:09] hey cachio so I looked at your pastebins above about the device group vs apparmor denial and I think I see the problem [15:09] ijohnson, nice, which is it? [15:10] cachio: in https://paste.ubuntu.com/p/BtMyBXGVpW/ we can see that the device major/minor number for /dev/input/event2 is (in hex) d,42 (or in decimal 13,66) [15:10] but from your other paste, https://paste.ubuntu.com/p/kB6WF8hrp4/ the device cgroup does not have any rules for major number 13 [15:10] so for whatever reason /dev/input/event2 on this system has a device major/minor number that we don't allow for [15:11] ijohnson, ah, well, that explains why it is failing [15:12] ijohnson, what's the test scenario [15:13] I mean, we know about several bugs in how this works [15:13] zyga: the security-dev-input-event-denied spread test fails [15:13] zyga: see cachio's PR #9960 [15:13] PR #9960: tests: update permission denied message for test-snapd-event on ubuntu 2104 <⛔ Blocked> [15:14] ijohnson, looking [15:16] hmm although now I'm confused [15:17] that bit of the test is supposed to fail on AppArmor, not on the device cgroup [15:17] so the fact that we don't have rules in the device cgroup makes sense [15:21] cachio, ijohnson: do we know what changed? [15:22] is it a new kernel? [15:23] zyga: this test has been sporadically failing on arch, ubuntu 18.04, 20.04, and possibly others for a few months now, at least a couple times a week I have seen this failure [15:23] ijohnson, weird and interesting [15:23] when I try to reproduce it I always seem to fail, but maybe cachio can now reproduce it consistently with 21.04 [15:23] I added some more thoughts to the PR [15:23] maybe something is racy [15:24] name="/dev/input/event2" pid=32386 comm="read-evdev-devi" [15:24] what is that program? [15:24] read-evdev-device? [15:24] it always fails for me [15:24] cachio: which system ? [15:24] is that a test program [15:25] it's a bit opaque in test-snapd-event [15:25] zyga: that program is tests/lib/snaps/test-snapd-event/bin/read-evdev-device script [15:25] ah, so not a part of udev or something like that [15:25] it just tries to open the /dev node [15:25] * zyga looks [15:26] cachio: if you can reproduce it please let me know what system you can reproduce it on, I would be really interested in reproducing it here too [15:26] hmm [15:26] looks complex [15:26] but in reality it means that the device just refuses to open [15:28] ijohnson, well, I reproduce it running -> spread -debug google:ubuntu-21.04-64:tests/main/security-dev-input-event-denied [15:28] ijohnson, when you run it locally, have a look at the apparmor and device list before trying [15:28] to see if it makes sense in both cases [15:28] * zyga goes to deploy DCO checks [15:28] zyga: well I think what this means (the err msg being EPERM and not EACCESS) w/ the interface disconnected is that something was let through AppArmor first or for some odd reason we checked the device cgroup first [15:28] thanks for your thoughts zyga, ttyl [15:28] cachio: great, let me have a try here [15:28] ijohnson, I think those are under kernel control [15:28] unless something broke and now we check something that was dormant before [15:28] ping me back, I'll be around [15:37] yeah I dunno, I'm trying to reproduce on hirsute [15:42] * zyga runs 20.04 on the thinkpad and 20.10 on the desktop [16:19] pstolowski: I did a pass on the assertstate bits of #9922 [16:19] PR #9922: api: validation sets monitor mode

[16:19] pedronis: ty [16:32] pstolowski: let me know if my comment are unclear, anyway worst case we'll chat on Monday as you are off tomorrow [16:32] sure [16:37] * cachio lunch [16:55] cachio: zyga: so I have confirmed that at least on hirsute, indeed the device cgroup is being used _before_ apparmor, so if I add the /dev/input/event2 to the device cgroup for the snap, then instead of getting EPERM from the device cgroup, I now get EACCES from AppArmor, and this is 100% reproducible for me [16:55] so I think something has changed in hirsute for some reason [16:55] ijohnson, ha [16:55] interesting [16:55] yeah, must be the new kernel [16:55] ijohnson, it's still cgroup v1? [16:55] this could be what changed in the other systems too, but what's weird is we see this same failure in like bionic for example on GCE, which shouldn't be using the new kernel [16:56] zyga: I need to check but I'm fairly confident that the move to cgroups v2 for ubuntu was pushed out to 21.10 [16:56] just type mount [16:57] https://www.irccloud.com/pastebin/T9pMQVDp/ [16:57] I think that means hybrid ? [16:58] yeah but without any controllers in v2 [16:58] so cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) matters [16:58] so v1 in practice [16:58] right which should be what is in i.e. bionic too [16:59] ijohnson, my suggestion would be to ask jj or the kernel team [16:59] zyga: ack thanks yeah this does seem some sort of kernel related issue [17:04] ijohnson, I hope :) [17:13] pedronis: i addressed most of your comments but not all, just pushed what i've but it's not ready for re-review yet, i need to ponder a bit about these tests [17:18] o k [17:21] zyga: one more thing if you're curious, I can reproduce this with the generic kernel we have in hirsute, not just the gce one, and interestingly the gcp kernel is 5.8 based, while the "new" one in hirsute is 5.10, so I actually am not sure that it is kernel related === ijohnson is now known as ijohnson|lunch [17:21] ijohnson|lunch, oh [17:23] ijohnson|lunch, what makes you think this is not related to the kernel? [17:23] because it is happening with an older kernel in gce and a new one [17:24] but yeah honestly don't know, but I did ask jj [17:24] so we'll see what he thinkgs [17:24] anyways lunch for realz this time [17:25] ah, I misread that [17:25] so it happens with two different kernels (5.8 and 5.10) [17:25] what was the last working kernel? [17:25] enjoy :) [17:31] * zyga EODs === ijohnson|lunch is now known as ijohnson|groceri [19:04] Is there a convention for snap authors (looking at Nextcloud) to release news about upcoming efforts/releases? === dariball_ is now known as dariball === ogra_ is now known as Guest97578 === ba is now known as bandali === E_Eickmeyer is now known as Eickmeyer === ijohnson|groceri is now known as ijohnson