[03:39] Issue # closed: pc-amd64-gadget#20, pc-amd64-gadget#30, pc-amd64-gadget#36, pc-amd64-gadget#41 [03:40] PR pc-amd64-gadget#37 closed: Drop duplicate grub.cfg-* [03:41] Issue # opened: pc-amd64-gadget#20, pc-amd64-gadget#30, pc-amd64-gadget#36, pc-amd64-gadget#41 [03:41] PR pc-amd64-gadget#37 opened: Drop duplicate grub.cfg-* [03:44] hi i found some snap packages are incorrectly marked as proprietary [03:44] https://snapcraft.io/sunwait [03:44] https://snapcraft.io/mgba === faenil_ is now known as faenil [13:09] PR snapcraft#3029 closed: tests: speed up clean command unit tests [13:34] cmatsuoka: cachio_: could y'all take a look at https://github.com/snapcore/snapd/pull/8474 ? [13:34] master seems to still be red [13:34] PR #8474: tests: fix timeserver-control-test <⚠ Critical> [13:37] ijohnson: sure [13:38] thanks [13:41] ijohnson: done [13:42] I will say it is nice that with github actions, it's nice that for spread runs on CI, we only end up racing with ourselves, so even if the rest of the world is having a bad day for CI, our queue is only affected by how many PR's we have open [13:43] so on a quiet day like today, stuff runs instantly without any waiting [13:48] I almost locked myself out of my bank account because I was trying to use it with the ubuntu sso 2fa [13:52] cmatsuoka, ijohnson: hey [13:52] can I interest you in https://github.com/snapcore/snapd/pull/8482 [13:52] it fixes PRs for master [13:52] PR #8482: tests: rewrite timeserver-control test [13:52] zyga: hey zyga! checking that, thanks [13:52] zyga: hmm, looks shiny [13:54] ijohnson: it's surprisingly able to pass on 14.04+ [13:54] and all systems [13:55] that is impressive [13:55] I was going to just use pawel's PR to unbreak master but this does seem to be the better way to write the test [13:55] I don't want to encourage working on Sunday nights though :-) [13:56] I love redef.sh [13:56] :D [13:56] did I write redef.sh? [13:56] it was meant to be defer backwards :) [13:56] and the best use for tac I've seen this far [13:56] refed [13:57] sorry, my dyslexia [13:58] I thought refed but I just typed redef automatically :D [14:04] zyga: a good one to process in background: what could cause random processes to be killed on a single cpu vm but not when it's configured with a higher smp count? [14:05] cmatsuoka: a linux process dies on a SMP=n vm that doesn't die otherwise? [14:05] cmatsuoka: what is the process doing? [14:06] sergio reported this behavior, apparently a set of processes including ssh is being killed only when n=1 [14:06] hmm [14:07] and it happens when cpu usage hits 100% [14:07] cmatsuoka: do we know any more, we should get a bug report with whatever kind of way to reproduce it [14:08] cachio_: ^^, did I describe it correctly? do you have any further details? [14:08] please report a bug if you can [14:08] I'll look [14:08] (I'm off today) [14:10] cmatsuoka, zyga I'll report a bug with the information about how we create the instance and how to run the tests so we can discuss it tomorrow [14:10] super [14:10] zyga: you're not very good at being off from what I see :) [14:10] meanwhile I think master will not be red anymore and everyone can make some progress :) [14:24] hi zyga [14:24] hi [14:24] any chance to get your help with something ? [14:25] maybe, what do you need? [14:25] zyga https://forum.snapcraft.io/t/vulkan-is-broken-on-snaps-when-using-nvidia-proprietary-drivers/16378 [14:28] if you can take a look i will appreciate it [14:29] hmmm [14:30] there are several things here [14:30] the-mentor: currently many snaps ship userspace hardware drivers [14:30] the-mentor: mesa and everything it pulls in [14:31] the-mentor: this is not scalable and we want to stop doing that at some point [14:31] zyga the snaps i'm building do not pull mesa or any userspace drivers [14:31] the-mentor: another thing is that userspace drivers are not just .so files, as you see here there are various data that are loaded from fixed locations [14:31] the-mentor: those are scattered all around the FS and are hard to support [14:32] I'm just trying to find a way to get vulkan to work [14:32] the-mentor: the presence of libvulkan_intel.so in your post seems to counter that [14:32] the-mentor: the last part is that nvidia handling is a special snowflake [14:32] the-mentor: it was never meant to last this long [14:32] the-mentor: we were supposed to replace it by now [14:32] but that didn't happen [14:32] now [14:32] can we do a one-off patch that addresses this specific failure somehow - perhaps [14:33] but that's not the replacement for the better system where we don't need to perpetually play catch-up [14:33] the-mentor: I cannot spare any cycles now. I know this is not what you want to hear sadly. [14:33] the-mentor: after 20.04 and core 20 ships [14:33] the-mentor: and we have a new allocation for roadmap items [14:33] the-mentor: we may be able to do it [14:34] the-mentor: unfortunately this is a huge chunk of work end-to-end [14:35] zyga I appreciate the feedback [14:35] also i think you gave me a few pinpoints to look at [14:35] the-mentor: unofficially I made some snaps that provide nvidia userspace bits [14:35] the-mentor: but I didn't even reach vulcan testing [14:35] the-mentor: one thing that would be really useful [14:36] is some kind of test payload [14:36] an app that you can use to verify that various bits work [14:36] (different versions of opengl, vulkan, etc) [14:36] zyga i think you are right about the snap shipping mesa since i have these so i'll try to remove them and see if it helps [14:36] ## vulkan [14:36] - libvulkan1 [14:36] - mesa-vulkan-drivers [14:37] the-mentor: mesa, nvidia should be snaps [14:37] the-mentor: this would allow one to make a snap based on core16 [14:37] the-mentor: build it once in 2020 [14:37] the-mentor: and then use it to run on future hardware in 2022 [14:37] the-mentor: without rebuilding on core18, core20 or core22 [14:37] zyga make sense as a long term solution [14:39] I'm working on packaging a few wine based games and I see a lot of issues with nvidia which led me down this path [14:39] I appreciate you are showing us the limitations of our current system [14:39] we are well aware, I wish we I had the allocation to improvei t [14:39] *improve it [14:41] zyga i'm sure it will happen eventually [14:41] i was hoping a can snap battle net :D but i guess i'll have to wait a little longer :D [14:42] snaps are amazing and i'm really excited that they even exist [14:44] the-mentor: note, you could probably use a layout to put nvidia_icd.json in place [14:44] the-mentor: and that _might_ fix your particular case [14:44] I tried doing it but maybe i didnt do it properly [14:45] the-mentor: bind-file to /usr/share/vulkan/icd.d/nvidia_icd.json [14:45] and make sure that at runtime you see libGLX_nvidia.so.0 in $SNAP_LIBRARY_PATH (/var/lib/snapd/lib/gl/*) [14:45] or maybe /var/lib/snapd/lib/* [14:45] I forgot the details now [14:46] zyga this is what i tried based on a forum post somewhere https://pastebin.com/wXn4MuAC [14:47] the symlinks for libraries are not needed [14:47] can you send me the right way if you dont mind ? [14:47] try with just what I said above [14:47] just the one item that gives you the json icd [14:47] make sure you can read if from snap run --shell [14:48] ok i'll try it out and report back [14:48] that ought to give vulkan a way to know the soname to dlopen [14:48] then look if you can find that soname from the snap's point of view [14:48] im trying to first build the snap without mesa etc [14:49] the-mentor: I don't think that's useful for now [14:49] the-mentor: until the system is in place everyone bundles mesa [14:49] i see [14:49] so just do the bind workaround ? [14:50] yeah, put the icd file where vulkan wants to see it [14:50] but honestly, I don't remember the details anymore, you may need to jump through more hoops [14:51] * zyga goes away [15:06] ijohnson: it was already Monday, no? :-) [15:07] maybe in Australia :-) [15:08] I think I EODed after midnight [15:08] But just slightly [15:09] That test was interesting [15:12] ijohnson: if you guys land one of the fixes subsequent master PRs should be more less green. There are few random issues still but I won’t touch more today [15:14] zyga: sure I will land things in a bit, debugging uc20 things with cmatsuoka right now [15:26] PR snapd#8482 closed: tests: rewrite timeserver-control test [15:53] PR snapd#8473 closed: tests: when restoring chrony do not restart systemd-timesyncd [15:53] PR snapd#8474 closed: tests: fix timeserver-control-test <⚠ Critical> [15:54] PR snapd#8480 closed: tests: fix timeserver-control-test for 2.44 <β›” Blocked> [15:54] thanks cachio [15:55] cachio: can you merge updated master into 8481? [15:59] sure [15:59] ijohnson, 1 minutes [16:01] Issue core20#37 opened: Missing mkfs.vfat, should have tests for mkfs.vfat and mkfs.ext4 existing [16:02] ijohnson, done [16:04] * cachio lunch [16:05] thanks cachio [16:09] ijohnson: uhm, what was the command line to create a new focal image suitable for qemu-backed spread testing? [16:09] cmatsuoka: it's in the HACKING.md [16:10] cmatsuoka: `autopkgtest-buildvm-ubuntu-cloud -r focal` [16:10] ah thanks, I knew I read it somewhere [16:10] afaik it didn't change in focal [16:39] PR snapd#8483 opened: snap-bootstrap: fix partition numbering in create-partitions [16:40] ijohnson: refactored it a bit more and created the PR above [16:40] nice thanks [16:40] will take a look in a bit === ijohnson is now known as ijohnson|lunch === ijohnson|lunch is now known as ijohnson [18:06] re [18:06] guys can you please make sure 2.44 passes tests? [18:06] a 8482 variant for 2.44 would be great [18:40] cachio: not sure if this helps [18:40] https://github.com/snapcore/snapd/pull/8484 [18:41] cachio: I don't have spread 2 build [18:41] PR #8484: tests: ignore user@12345.service hierarchy [18:41] can you check if that still fails with the test case you had please [18:41] PR snapd#8484 opened: tests: ignore user@12345.service hierarchy [18:41] zyga, ahh, let see, but it seems to be ok [18:42] zyga, thanks!! [18:42] sure, let me know if it passes please [18:42] I'm in the office for now, making the space tidy [18:42] so much dust everywhere [18:42] zyga, hhehe [18:42] I'll follow the execution [18:55] PR snapcraft#3033 opened: build providers: do not print network test output for LXD [20:12] PR snapd#8485 opened: cmd/snap/debug/boot-vars: add opts for setting dir and/or uc20 vars [20:15] PR snapd#8486 opened: bootloader, gadget, cmd/snap-bootstrap: misc cosmetic things [20:21] PR snapd#8487 opened: [RFC] gadget, cmd/snap-bootstrap: hack some things into place to get rpi4 semi-working [20:58] PR snapcraft#3030 closed: repo: drop _AptCache and add migrate to install_stage_packages() [20:58] PR snapcraft#3033 closed: build providers: do not print network test output for LXD [21:37] PR snapcraft#3034 opened: repo: add initialize_snapcraft_defaults() to set default source lists [22:00] PR snapd#8486 closed: bootloader, gadget, cmd/snap-bootstrap: misc cosmetic things [22:54] PR snapd#8488 opened: bootloader: add efi pkg for reading efi variables [23:22] PR snapcraft#3032 closed: plugins: introduce v2.MakePlugin with rebuilding