[00:59] PR snapcraft#3035 opened: repo: fix resolution of virtual build packages [02:24] PR snapd#8484 closed: tests: ignore user@12345.service hierarchy [02:26] PR snapcraft#3036 opened: travis: use stable channel for building snapcraft snap [05:07] Good morning [05:13] morning [05:21] Hey Maciek [05:23] zyga: hey hey [05:32] Frosty morning [05:32] hm we should package the .3 release [05:33] Or make .4 [05:33] Let’s wait for mvo [05:33] I suspect we may do .4 [05:33] .4? interesting things happend over the weekend then? [05:33] Yes [05:33] Look at my PRs [05:34] There is one still open IIRC [05:34] https://github.com/snapcore/snapd/pull/8481 [05:34] PR #8481: cmd/snap-update-ns: handle EBUSY when unlinking files [06:08] Back from walk [06:09] I fixed random failures plaguing master over Easter [06:09] Hopefully all most common [06:09] I didn’t rebase that important fix though [06:11] I’ll make coffee and start the day soon [06:12] PR snapd#8479 closed: release: 2.44.3 [06:16] Hey mvo [06:17] zyga: good morning [06:22] good monring zyga [06:24] Hey the-mentor [06:24] mvo: so, I guess I need to ask [06:24] Do we do a .4 [06:24] Or are we pushing for with .3 and buffer fixes for now [06:24] zyga i tried what you told me yesterday with the bind-file but from within the snap the file seems empty or cant be opened [06:25] What layout did you specify? [06:25] Note: you have to add the icd file into your snap for now [06:25] layout: [06:25] /usr/share/vulkan/implicit_layer.d/nvidia_layers.json: [06:25] bind-file: $SNAP/usr/share/vulkan/implicit_layer.d/nvidia_layers.json [06:26] Also note that mborzecki has some knowledge about vulkan and might offer advice [06:26] mborzecki howdy ! [06:27] Did you try using the same name as you had on your host originally? [06:27] i did [06:27] Not sure if this is relevant or not [06:27] i'm pointing too the file on the host [06:27] the-mentor: hm? vulkan? [06:27] haven't heard that name in a long time [06:27] mborzecki i'm trying to get vulkan to work in my sanp [06:28] Note that you have to put the actual file in your snap as well [06:28] since i'm trying to snap a few wine based games [06:28] On nvidia [06:28] zyga ahh i see but that file might be different depending on the host no ? [06:30] mborzecki seems like vulkan is the new hot stuff in the gaming world so many games work better with vulkan + dxvk [06:31] zyga: why would we do a .4 again, please remind me [06:32] the-mentor: isn't making sure that nvidia icd.d files are at the right place enough? [06:34] mborzecki https://forum.snapcraft.io/t/vulkan-is-broken-on-snaps-when-using-nvidia-proprietary-drivers/16378 [06:34] check out this post i've made with more info about my issue [06:36] mvo: to apply the patch fixing microk8s with strict confinement [06:38] zyga: 8481? [06:38] indeed [06:39] zyga: maybe we need a .4 - let me check the bugreport. do people need to enable robust namespace updates to make the fix work? iirc you mentioned yes(?) [06:39] oh, yes, they would [06:39] hmm, so that suggest 2.45 instead [06:39] but I don't know the details on their side, it just seems that if we need to do a .5 it's either now or not at all (because schedules) [06:40] zyga: yeah, if we need the robust namespace updates it suggests to get on with 45 asap [06:41] the-mentor: try setting VK_ICD_FILENAMES to point it to nvidia icd file and see if that makes vulkaninfo happy [06:41] mborzecki what do you mean ? using bind-file ? [06:42] the-mentor: no, snap run --shell, then probably something like: `VK_ICD_FILENAMES=/var/lib/snapd/hostfs/usr/share/vulkan/icd.d/nvidia_icd.json vulkaninfo` [06:45] mborzecki ok i'll give it a shot [06:46] the-mentor: hmm actually can you check that /usr/share/vulkan/icd.d/nvidia*.json exists inside the snap? [06:46] mborzecki i need classic confinment to access /var/lib/snapd/hostfs right ? [06:46] mborzecki it doesnt [06:46] so i added these layers config to try and make it available [06:47] layout: [06:47] /usr/share/vulkan/implicit_layer.d/nvidia_layers.json: [06:47] bind-file: $SNAP/usr/share/vulkan/implicit_layer.d/nvidia_layers.json [06:48] the-mentor: how about /var/lib/snapd/lib/vulkan/icd.d/nvidia*.json? [06:49] mborzecki that exists and has content [06:49] and i can read it from inside the snap [06:49] the-mentor: ok, cool, try running `VK_ICD_FILENAMES=/var/lib/snapd/lib/vulkan/icd.d/nvidia_icd.json vulkaninfo` and see if that works [06:50] the-mentor: perhaps it's enough to use layouts to move that file into /usr/share/vulkan/icd.d/ [06:50] zyga: do layouts allow using /var/lib/snapd/lib? [06:50] that works [06:50] it ran vulkaninfo properly [06:51] mborzecki: no [06:51] mborzecki: you cannot put files there [06:51] zyga: hm i meant to use /var/lib/snapd/lib/ as a source [06:52] layouts cannot use anything but $SNAP, $SNAP_DATA or $SNAP_COMMON as source [06:52] a mount profile could use anything [06:52] hmm ok [06:53] the-mentor: so maybe as a workaround you'd need to have a wrapper that globs /usr/share/vulkan/icd.d* and /var/lib/snapd/lib/vulkan/icd.d/* and sets VK_ICD_FILENAMES to the list of all paths that were found [06:54] that or teaching the vulkan loader upstream about directories [06:54] mborzecki i already have a wrapper that launches the wine executable [06:54] zyga: are you working on the gh action partitioning currently? if not I can do it now [06:55] mborzecki so what should VK_ICD_FILENAMES look like ? [06:55] mvo: no, not yet [06:55] mvo: sure, give it a try :) [06:55] the-mentor: https://github.com/KhronosGroup/Vulkan-Loader/blob/master/loader/LoaderAndLayerInterface.md#overriding-the-default-icd-usage [06:55] iirc it's file:file:file [06:57] mborzecki i wonder if there is a way to check within the snap what is the graphics driver and only overwrite if its nvidia propriatery [06:57] mborzecki: since we only have nvidia support via hostfs I would suggest to special case the single nvidia icd file [06:57] and nothing else [06:57] after all, there are no other .so files to load [06:58] the-mentor: i think you shouldn't need to, it's up to the loader and specific implementations to check that [06:58] mborzecki would the /usr/share/vulkan/icd.d/nvidia*.json file not exists if the drivers is not installed? [06:59] mborzecki: can 8464 be merged or does it need changes in the initrmafs first? [07:00] the-mentor: it likely wouldn't but i still think that app should not make assumptions about that, it's up the loader to figure out what's available by trying to load all implementations, find out which work, and give a choice to the vk consumer app [07:01] mborzecki ok let me send you what i'm going to set the VK_ICD_FILENAMES to so i can see if i understand it correctly [07:02] mvo: we're waiting for a fix in initramfs from xnox, there was some dependency problem on thursday where initramfs would stop before switch-root [07:03] mborzecki VK_ICD_FILENAMES=/var/lib/snapd/lib/vulkan/icd.d/nvidia_icd.json:$SNAP/usr/share/vulkan/icd.d/intel_icd.x86_64.json:$SNAP/usr/share/vulkan/icd.d/radeon_icd.x86_64.json [07:03] morning [07:03] PR snapd#8296 closed: httputil/client_test.go: add two TLS version tests [07:04] mborzecki just ran some testing on my system and it seems to know which file to use [07:05] good morning pawel [07:05] the-mentor: yeah, looks ok to me [07:06] good morning pstolowski [07:07] the-mentor: let me put some notes in the topic [07:07] mborzecki ill rebuild the snap and see if it works in there. thank you very much for all the help [07:19] PR snapd#8489 opened: github: partition the github action workflows <⛔ Blocked> [07:21] mvo: did you forget to git add? [07:29] zyga: no, it's still draft, want to make sure the right go version is picked up [07:29] ah ok :) [07:39] good morning! What would be the easiest way to get the sign-key-sha3-384 for a key registered by a user in the store? [07:43] abeato: do you mean the key that signed the key itself? that should be the store key [07:43] or the hash of the key? [07:43] abeato: what do you have as starting point? [07:43] pedronis, the hash that is used in assertions [07:44] pedronis, a key registered with snapcraft register-key [07:46] abeato: snapcraft list-keys and snap keys shows exactly that under "SHA3-384..." [07:47] pedronis, I thinka that is public-key-sha3-384, not sign-key-sha3-384, by looking at the account-key assertion [07:48] abeato: the sign-key-sha3-384 of a signed assertion matches the public-key-sha3-384 of the signing key [07:48] pedronis, as a side note, of course the information is in that asssertion, but to get it I had to create an image with ubuntu-image :) [07:48] but maybe I still don't understand what you need [07:49] pedronis, I'd like to get that info to manually craft a system-user assertion [07:50] abeato: you need the key to craft an assertion [07:51] mborzecki: yes [07:51] pedronis, I have registered a key, which is shown by: [07:51] $ snapcraft list-keys [07:52] * labkey -aWK1CFTXhjR8BpMMplySRp3hRS6AKD8q-mJglQDXxA9-1LknJVV5cEI2pExGj6c [07:52] I'd like to create a system-user assertion signed by that one [07:52] PR snapd#8490 opened: cmd/snap-bootstrap: no error when not input devices are found [07:52] snap sign -k labkey [07:52] so I need to access sign-key-sha3-384 [07:53] -aWK1CFTXhjR8BpMMplySRp3hRS6AKD8q-mJglQDXxA9-1LknJVV5cEI2pExGj6c is what will end up in sign-key-sha3-384 [07:53] I don't think it helps you though [07:53] you need snap sign -k labkey and the right json input [07:54] unless I'm still missing what you are trying to do [07:54] pedronis, I am trying to create a system-user assertion [07:54] snap sign -k labkey [07:55] the sign-sha-3-384 is added by the tooling [07:55] pedronis, ah, got it, so I do not need sign-key-sha3-384 in the json, snap sign does that for me [07:55] thanks! [07:55] yes, same as with model [07:55] right [08:34] PR core18#98 closed: hooks: add symlinks for snapd's D-Bus configuration files [08:41] PR core18#150 opened: static: make /etc/dbus-1/session.d writable [08:57] small comment there jamesh [08:58] zyga: as mentioned in the PR, I think it would probably be harmless to switch to just /etc/dbus-1 in core18 too [08:58] zyga: I'd definitely go for /etc/dbus-1 for core20, yeah. [08:59] I don't know about 18 to be sure (it would be okay after testing) [08:59] just suggesting that we do it straight away for 20 :) [08:59] maybe it's not worth it for core18 [09:00] btw. anyoen remember why `snap debug boot-vars` is hidden? [09:00] nope [09:00] because we hide stuff left and right? [09:04] zyga: heh, idk ;) [09:04] zyga: heh, idk ;) [09:05] zyga: https://github.com/snapcore/core20/pull/38 [09:05] PR core20#38: static: make all of /etc/dbus-1 writable [09:05] PR core20#38 opened: static: make all of /etc/dbus-1 writable [09:06] mborzecki: because it was introduced for our own tests, and never got a extra review/polish pass [09:10] PR snapd#8491 opened: cmd/snap: do not hide debug boot-vars on core [09:14] wonder whether pushing the error on classic is too far, one could try to inspect the root directories populated by snap image [09:15] mborzecki: should it output = or : [09:15] mborzecki: it was hidden not to have to find answers to all these questions === pedronis_ is now known as pedronis [09:25] mborzecki: mvo: we are getting failures now in travis with the devel go version [09:26] some are obvious, one is not [09:27] pedronis: looking at it [09:33] is that go 1.14? [09:37] no, it's really devel I think [09:39] it's annoying, it looks like even --channel=latest/edge is not failing yet [09:40] maybe not worth testing with devel then [09:40] (so travis is really ahread) [09:44] zyga: it's a good question, probably still worth it as it will eventually bite us. but yeah, kind of annoying if it happens out of the blue [09:44] PR snapd#8492 opened: overlord: update tests to work with latest go [09:45] mvo: I agree that there's some value in seeing what's on the horizon but I think we have enough things that are flaky; we need to find the right balance [09:46] zyga: yeah [09:47] right now these tests are still required, I mentioned it because the keys one is puzzling/unclear what is going on [09:47] the duration ones are trivial if annyoing [09:47] PR snapd#8483 closed: snap-bootstrap: fix partition numbering in create-partitions [09:47] *annoying [09:50] PR snapd#8461 closed: github: run non-canary if label is present [09:54] pedronis: 8492 (go-latest) fixes passes on travis, so should be good [09:55] ok, so the key one was a fluke? [09:55] pedronis: probably [09:56] pedronis: I don't even remember seeing it on the failure I looked at [10:01] zyga: I guess there is no "include" in workflows? I was looking into moving the common code out [10:01] mvo: maybe at yaml level [10:02] I don't think so [10:36] mwhudson: hey, I noticed that go/latest/edge was not updated in a couple of days, is that expected? [10:36] mvo: builds have been failing, i haven't looked at why [10:37] mvo: https://launchpad.net/~mwhudson/+snap/go-tip [10:37] maybe tests are not passing? ;-) [10:37] zyga: it's possible! [10:37] https://www.irccloud.com/pastebin/kBpBEI5J/ [10:38] oh is that the hacks i put in for trusty i wonder [10:38] mwhudson: aha, that's fine, was mostly wondering if it's known [10:39] hm that wouldn't explain the failures on ppc64el [10:39] mvo: well someone asking makes it more likely that i'll look into it i guess [10:40] mwhudson: actually the same error is reported on other arhces [10:40] *arches [10:40] weird [10:40] PR snapd#8490 closed: cmd/snap-bootstrap: no error when not input devices are found [10:40] mwhudson: heh :) fwiw, we value it as a very useful way to test things [10:40] (it being go/latest/edge) [10:40] mvo: hush, don't tell anyone [10:40] it's our secret! [10:41] though there's one downside [10:41] makes you gray quickly [10:46] * zyga ventures into dbus [10:50] mborzecki: btw, not sure if you noticed [10:50] mborzecki: I changed the pulseaudio test on Friday [10:50] mborzecki: some lessons learned there [10:51] mborzecki: it needs more love though [10:51] mborzecki: the restore section is still racy [10:51] zyga: https://github.com/snapcore/snapd/pull/8478 ? [10:51] PR #8478: tests: fix racy pulseaudio tests [10:51] yes [10:53] * zyga is afk [10:54] zyga: heh, yeah, we should probably port the test [10:55] zyga: although masking seems fine now, the test starts its own pulseaudio with a specific config [11:05] PR snapd#8491 closed: cmd/snap: do not hide debug boot-vars on core [11:12] mborzecki i'm also seeing this issue [11:12] libGL error: No matching fbConfigs or visuals found [11:12] libGL error: failed to load driver: swrast [11:12] X Error: GLXBadContext [11:12] Request Major code 151 (GLX) [11:12] Request Minor code 6 () [11:12] Error Serial #174 [11:12] Current Serial #173 [11:12] PR #174: added missing hyphen to autoupdate config example [11:13] PR #173: asserts: generate just a couple private keys and reuse them across tests [11:13] any ideas ? [11:14] zyga maybe you know ? [11:17] re [11:17] mborzecki: I saw a failure just now where it failed because XDG_RUNTIME_DIR was still busy [11:18] mborzecki: so some work required on making shutdown not race [11:18] the-mentor: strace the app, I saw a failure where it looked for an innocent looking file [11:18] the-mentor: and failed entirely when that file was absent [11:18] zyga strace? [11:18] the-mentor: it's a PCI ID to driver name mapping file [11:18] snap run --strace [11:18] the-mentor: are you familiar with strace? [11:19] no i'm not [11:19] but ill try it out [11:19] the-mentor: it's a very useful analysis tool, read the manual page but it's generally showing interactions with the system at the system call level [11:19] the-mentor: so you see which syscalls are executed and if they succeed or not [11:19] the-mentor: you can use it to see which files are being accessed, for example [11:19] the-mentor: strace -e openat ls [11:20] zyga ok thats good to know [11:21] zyga how can i filter only open files with the snap strace? [11:21] since its a wine app there is tons and tons of info [11:21] the-mentor: --strace= is an argument you can pass to snap run [11:22] you can pass strace options this way [11:22] you can then use it to filter by system calls that access files such as stat, open etc [11:22] remember that you have to give the real system call name [11:22] e.g. openat vs open, 2 or 3 suffixes on some [11:22] requires some practice to get the right result [11:22] the-mentor: you can use strace -o to save the result to a file [11:22] and analyze this way [11:23] may be easier [11:23] the-mentor: you can also look for ENOENT error [11:23] that's something that was searched for but not found [11:23] should help you find the right things [11:23] ok i'll give it a shot and see what i can find [11:23] i'm happy that the vulkan smoketest now works [11:33] hey cachio [11:34] i've been waiting for you ;) [11:42] pstolowski, hey [11:44] the-mentor: so vulkan works now, but gl does not yet? [11:45] cachio: hey, see private message [12:09] cmatsuoka: good morning! I pushed a tiny commit to 8476 to make it build on fedora/debian [12:09] cmatsuoka: just fyi [12:12] cmatsuoka: hrm, apparently my push there is somehow incomplete, I took it from the other tpm one, I have a look after lunch (but feel free to push a fix yourself if its something obvious, probably just something with -tags quoting [12:12] ) [12:14] mvo: thanks! yeah, I was unsure about cherry-picking your commit from the other PR or just waiting for the other one to land and then merge master to have things automagically working [12:14] mvo: I'll check what's wrong and fix it [12:15] PR core20#39 opened: ensure that /host exists [12:15] mvo: ^^ [12:18] ijohnson: hi, I'm going to work a bit on #8488 to avoid the back and forth [12:18] PR #8488: bootloader: add efi pkg for reading efi variables <⛔ Blocked> [12:24] pedronis sure thanks [12:24] And hello again by the way, hope you all enjoyed your long weekend [12:26] PR snapd#8493 opened: If finalrd is available, do not run snapd.system-shutdown service [12:28] PR core20#39 closed: ensure that /host exists [12:28] PR snapd#8494 opened: tests: preserve size for centos images on spread.yaml [12:29] PR core20#38 closed: static: make all of /etc/dbus-1 writable [12:51] mvo, hey, is https://bugs.launchpad.net/snapd/+bug/1872486 under your radar? [12:51] Bug #1872486: snap prepare-image gets confused when the default track is not "latest" [13:02] mborzecki i think that gl was broken before but yea vulkan works and gl doesnt [13:03] mborzecki i'm adding mesa-utils to the snap so i can get more info [13:06] jdstrand, you might be interested in https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/commit/?id=82ee1ce51514ee197ee6fd908c9f0af881f1f2ac [13:11] abeato: thanks, not on my radar yet [13:22] mborzecki looks like glxgears and glxinfo are working as expected [13:22] maybe its related to wine somehow but it looks like i'm not the only one that has these issues [13:48] * zyga -> lunch [14:34] oSoMoN: interesting [14:34] oSoMoN: I should talk to you about the snapctl APIs for checking and getting information about updates [14:37] PR core20#40 opened: hook-tests: fix extra files test [14:37] zyga, I'd be very interested in those, what I implemented for the chromium snap is only a stop-gap [14:38] mvo: trivial fix for issue that jamesh spotted ^^ [14:40] PR snapcraft#3036 closed: travis: use stable channel for building snapcraft snap [14:56] PR core20#40 closed: hook-tests: fix extra files test [15:06] abeato: mvo: I confirmed https://bugs.launchpad.net/snapd/+bug/1872486 and assigned it to pedronis, perhaps it should go to someone else, but it does seem to be a bad bug for building images [15:06] Bug #1872486: snap prepare-image gets confused when the default track is not "latest"