[08:50] PR snapd#10593 opened: c/snap,o/hookstate/ctlcmd: add JSON/string strict processing flags to snap/snapctl [10:55] PR snapd#10594 opened: bootloader: fix double extract of the kernel assets [11:41] pedronis_, ijohnson[m]: the removal of the mount units created by the mount-interface, is it better to do it in overlord/snapstate/backend/setup.go (RemoveSnapFiles) or in overlord/snapstate/handlers.go (DoDiscardSnap)? [11:42] mardy_2nd: I would recommend doing it in doDiscardSnap() [11:42] sorry I still have an inprogress review for your mount-control PR that I haven't finished yet [11:43] mardy_2nd: you might need to introduce a new backend helper that calls a wrappers helper [11:43] adding a new method to the managerBackend interface? [11:43] mardy_2nd: RemoveSnapFiles is called also when there are still other revision of the files, so it has the same problem [11:43] as the original code === pedronis_ is now known as pedronis [11:53] pedronis: I think I'll add the code here: overlord/snapstate/backend/mountunit.go, unless you think it's improper [11:54] something like: func (b Backend) RemoveSnapMountUnits(info *snap.Info) error { ... } [11:55] well, the file itself is not important, I can easily move it elsewhere if needed [12:32] mardy_2nd: ok I finished my first pass review for mount-control, sorry for the tons of comments, I'll wait until you've had a chance to look at them and/or respond before I do another pass if that sounds okay? [12:47] ijohnson[m]: of course, thanks. I just pushed one new commit with the latest changes about removing the mount units a few minutes ago, not sure whether that was before or after you filed your comments. But I'm now going to read them all anyways :-) [13:42] My PR https://github.com/snapcore/snapd/pull/10592 had some checks fail because the PR name didn't have the module in it. I renamed it but don't seem to have permission to restart the checks. [13:42] PR #10592: gadget: Export mkfs functions for use in ubuntu-image [13:55] jawn-smith: I re-triggered the tests for you [13:56] ijohnson[m], hi [13:56] Thank you ijohson[m] ! [13:56] hey cachio_ [13:57] ijohnson[m], core20-early-config test is failing https://paste.ubuntu.com/p/j3sTF49xv7/ [13:57] If I do # tests.nested exec "readlink -f /etc/localtime" [13:58] cachio_: was this in GCE or locally in a VM [13:58] while debugging the localtlime and timezone are ok [13:58] pointing to Europe/Malta [13:58] So I presume it is a timing issue [13:59] ijohnson[m], should we retry checking for something to make sure the config was already applied? [14:04] cachio_: did you encounter this on GCE or in a VM locally? [14:06] ijohnson[m], it is on gce [14:06] hmm, it's possible it's a timing issue, let me read the test closely again [14:19] cachio_: it definitely would not help to retry checking anything, all the options should have already been processed from the initramfs, if they are not processed by the time the install hook runs then something is broken [14:19] ijohnson[m], ah, ok [14:21] ijohnson[m], any log could help? [14:21] I have a debug session opened [14:21] cachio_: how reproducible is this issue [14:21] I wonder if we broke something with the recently landed virtual config stuff [14:22] I saw that in the nested execution that ran nightly [14:22] and the ran the test once and it failed [14:22] cachio_: and you were able to reproduce it first try ? [14:22] :-/ [14:22] yes [14:23] ran # spread -debug -repeat 5 google-nested:ubuntu-20.04-64:tests/nested/manual/core20-early-config [14:23] let me see if I can reproduce it if so then yeah we probably introduced a regression [14:23] and first iteration failed [14:23] ijohnson[m], nice, thanks [14:23] I also note that we didn't run the pr which changed how the timezone config is applied with the "run nested" label [14:23] I'm looking at https://github.com/snapcore/snapd/pull/10562 as the suspect right now [14:23] PR #10562: configcore: register virtual config for timezone reading [14:24] oh, "systemctl show" seems to ignore all "X-" properties :-( [14:24] mardy_2nd: well that's disappointing [14:24] is there some option to make it send those too? [14:25] ijohnson[m]: looking... [14:27] does `--all` help ? [14:27] it makes parsing more difficult but maybe that would give you even the ones that systemd doesn't know about [14:28] ijohnson[m]: oh! It says "If specified more than once, all properties [14:28] with the specified names are shown. [14:28] let me try... [14:29] ah, it's not what I thought it was :-( [14:30] nevermind, I'll try to find a solution on Monday [14:31] hmm yeah I can't get it to work either [14:31] PR snapd#10595 opened: {device,snap}state: skip kernel extraction in seeding [15:11] * cachio_ lunch [15:32] yeah so https://github.com/snapcore/snapd/pull/10562 definitely seems to have broken the core20-early-config test, I'll investigate this today [15:32] PR #10562: configcore: register virtual config for timezone reading [15:32] test fails every time for me after that pr was merged, and works every time before that pr was merged [15:39] looks like a couple of my spreads failed as well, including core20 [15:40] that was the only required one that failed. Others were ubuntu-21.10 and tumbleweed. Is there any action I need to take on those? [16:05] ijohnson[m], nice, thank for taking care of this [16:09] PR snapcraft#3568 opened: cli: enable SNAPCRAFT_TARGET_ARCH envvar matching --target-arch [16:10] jawn-smith: no those are probably not related to your PR at all, we'll take care of looking into those [16:10] cachio_: have you looked into the snapd-snap:lxd test failure on 21.10 yet? seems it is running out of space ? [16:11] ijohnson[m], no, I can take a look [16:12] cachio_: see https://pastebin.ubuntu.com/p/yTbjBMBMV9/ [16:13] i.e. like [16:13] 2021-08-06T14:43:53.9210851Z go install github.com/snapcore/snapd/bootloader: copying /tmp/go-build724970219/b138/_pkg_.a to /root/parts/snapd-deb/build/_build/std/github.com/snapcore/snapd/bootloader.a: write /root/parts/snapd-deb/build/_build/std/github.com/snapcore/snapd/bootloader.a: no space left on device [16:13] 2021-08-06T14:43:53.9213436Z # github.com/snapcore/snapd/snap/internal [16:13] 2021-08-06T14:43:53.9214591Z compile: writing output: write $WORK/b155/_pkg_.a: no space left on device [16:13] 2021-08-06T14:43:53.9216486Z go build github.com/snapcore/snapd/snapdtool: mkdir /tmp/go-build724970219/b157/: no space left on device [16:14] ijohnson[m], perhaps it is not resizing correctly [16:15] could be, not sure [16:15] I am running in a loop [16:15] cachio_: seems to fail every time on 21.10 [16:15] I'll monitor the vm and in case I can reproduce I'll see why it is getting out of space [16:53] ijohnson[m]: I didn't think my PR had caused those issues, just that those issues had caused my PR's checks to fail. Will that block it from being considered further? [16:53] jawn-smith: no we'll still review the PR as-is, the failing checks on your PR aren't of any concern [16:54] great, thanks! [17:22] ijohnson[m], checking 21.10 issue [17:22] 4.1G /var/snap/lxd/common/lxd [17:22] I see this [17:25] 4G for the /var/snap/lxd/common/lxd/storage-pools/default/containers/snapcraft-snapd/rootfs [17:25] ijohnson[m], this changed with the new snapcraft 4 I think [17:27] so, the test can be fixed just adding more disk [17:27] but, not sure id it is ok that size for the lxd image [17:31] ijohnson[m], https://paste.ubuntu.com/p/cHt7mqySZ2/ [17:36] PR snapd#10467 closed: snap: support links map in snap.yaml (and later from the store API) [17:44] cachio_ ack probably increasing the disk size makes sense then [17:48] ijohnson[m], ack, I'll try with 12gb [18:18] this may not be the "perfect" place to ask this but it's iot-management related which is at least in the same ballpack :) anyway, is it possible to use Ubuntu SSO as an OAuth2 provider for a CLI tool and a REST API? [18:19] or- is there a channel you can direct me to that would be a better fit? [19:17] PR snapd#10596 opened: tests: use bigger storage on ubuntu 21.10