/srv/irclogs.ubuntu.com/2021/08/06/#snappy.txt

mupPR snapd#10593 opened: c/snap,o/hookstate/ctlcmd: add JSON/string strict processing flags to snap/snapctl <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/10593>08:50
mupPR snapd#10594 opened: bootloader: fix double extract of the kernel assets <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/10594>10:55
mardy_2ndpedronis_, 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:41
ijohnson[m]mardy_2nd: I would recommend doing it in doDiscardSnap()11:42
ijohnson[m]sorry I still have an inprogress review for your mount-control PR that I haven't finished yet11:42
pedronis_mardy_2nd: you might need to introduce a new backend helper that calls a wrappers helper11:43
mardy_2ndadding a new method to the managerBackend interface?11:43
pedronis_mardy_2nd: RemoveSnapFiles is called also when there are still other revision of the files, so it has the same problem11:43
pedronis_as the original code11:43
=== pedronis_ is now known as pedronis
mardy_2ndpedronis: I think I'll add the code here: overlord/snapstate/backend/mountunit.go, unless you think it's improper11:53
mardy_2ndsomething like: func (b Backend) RemoveSnapMountUnits(info *snap.Info) error { ... }11:54
mardy_2ndwell, the file itself is not important, I can easily move it elsewhere if needed11:55
ijohnson[m]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:32
mardy_2ndijohnson[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 :-)12:47
jawn-smithMy 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
mupPR #10592: gadget: Export mkfs functions for use in ubuntu-image <Created by GlenPickle> <https://github.com/snapcore/snapd/pull/10592>13:42
ijohnson[m]jawn-smith: I re-triggered the tests for you13:55
cachio_ijohnson[m], hi13:56
jawn-smithThank you ijohson[m] !13:56
ijohnson[m]hey cachio_ 13:56
cachio_ijohnson[m], core20-early-config test is failing https://paste.ubuntu.com/p/j3sTF49xv7/13:57
cachio_If I do # tests.nested exec "readlink -f /etc/localtime" 13:57
ijohnson[m]cachio_: was this in GCE or locally in a VM13:58
cachio_while debugging the localtlime and timezone are ok13:58
cachio_pointing to Europe/Malta13:58
cachio_So I presume it is a timing issue13:58
cachio_ijohnson[m], should we retry checking for something to make sure the config was already applied?13:59
ijohnson[m]cachio_: did you encounter this on GCE or in a VM locally?14:04
cachio_ijohnson[m], it is on gce14:06
ijohnson[m]hmm, it's possible it's a timing issue, let me read the test closely again14:06
ijohnson[m]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 broken14:19
cachio_ijohnson[m], ah, ok14:19
cachio_ijohnson[m], any log could help?14:21
cachio_I have a debug session opened14:21
ijohnson[m]cachio_: how reproducible is this issue14:21
ijohnson[m]I wonder if we broke something with the recently landed virtual config stuff14:21
cachio_I saw that in the nested execution that ran nightly14:22
cachio_and the ran the test once and it failed14:22
ijohnson[m]cachio_: and you were able to reproduce it first try ? 14:22
ijohnson[m]:-/14:22
cachio_yes14:22
cachio_ran # spread -debug -repeat 5 google-nested:ubuntu-20.04-64:tests/nested/manual/core20-early-config14:23
ijohnson[m]let me see if I can reproduce it if so then yeah we probably introduced a regression14:23
cachio_and first iteration failed14:23
cachio_ijohnson[m], nice, thanks14:23
ijohnson[m]I also note that we didn't run the pr which changed how the timezone config is applied with the "run nested" label14:23
ijohnson[m]I'm looking at https://github.com/snapcore/snapd/pull/10562 as the suspect right now14:23
mupPR #10562: configcore: register virtual config for timezone reading <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10562>14:23
mardy_2ndoh, "systemctl show" seems to ignore all "X-" properties :-(14:24
ijohnson[m]mardy_2nd: well that's disappointing14:24
ijohnson[m]is there some option to make it send those too?14:24
mardy_2ndijohnson[m]: looking...14:25
ijohnson[m]does `--all` help ?14:27
ijohnson[m]it makes parsing more difficult but maybe that would give you even the ones that systemd doesn't know about14:27
mardy_2ndijohnson[m]: oh! It says "If specified more than once, all properties14:28
mardy_2nd           with the specified names are shown.14:28
mardy_2ndlet me try...14:28
mardy_2ndah, it's not what I thought it was :-(14:29
mardy_2ndnevermind, I'll try to find a solution on Monday14:30
ijohnson[m]hmm yeah I can't get it to work either14:31
mupPR snapd#10595 opened: {device,snap}state: skip kernel extraction in seeding <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/10595>14:31
* cachio_ lunch15:11
ijohnson[m]yeah so https://github.com/snapcore/snapd/pull/10562 definitely seems to have broken the core20-early-config test, I'll investigate this today15:32
mupPR #10562: configcore: register virtual config for timezone reading <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10562>15:32
ijohnson[m]test fails every time for me after that pr was merged, and works every time before that pr was merged15:32
jawn-smithlooks like a couple of my spreads failed as well, including core2015:39
jawn-smiththat was the only required one that failed. Others were ubuntu-21.10 and tumbleweed. Is there any action I need to take on those?15:40
cachio_ijohnson[m], nice, thank for taking care of this16:05
mupPR snapcraft#3568 opened: cli: enable SNAPCRAFT_TARGET_ARCH envvar matching --target-arch <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3568>16:09
ijohnson[m]jawn-smith: no those are probably not related to your PR at all, we'll take care of looking into those16:10
ijohnson[m]cachio_: have you looked into the snapd-snap:lxd test failure on 21.10 yet? seems it is running out of space ?16:10
cachio_ijohnson[m], no, I can take a look16:11
ijohnson[m]cachio_: see https://pastebin.ubuntu.com/p/yTbjBMBMV9/16:12
ijohnson[m]i.e. like16:13
ijohnson[m]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 device16:13
ijohnson[m]2021-08-06T14:43:53.9213436Z # github.com/snapcore/snapd/snap/internal16:13
ijohnson[m]2021-08-06T14:43:53.9214591Z compile: writing output: write $WORK/b155/_pkg_.a: no space left on device16:13
ijohnson[m]2021-08-06T14:43:53.9216486Z go build github.com/snapcore/snapd/snapdtool: mkdir /tmp/go-build724970219/b157/: no space left on device16:13
cachio_ijohnson[m], perhaps it is not resizing correctly16:14
ijohnson[m]could be, not sure16:15
cachio_I am running in a loop16:15
ijohnson[m]cachio_: seems to fail every time on 21.1016:15
cachio_I'll monitor the vm and in case I can reproduce I'll see why it is getting out of space16:15
jawn-smithijohnson[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
ijohnson[m]jawn-smith: no we'll still review the PR as-is, the failing checks on your PR aren't of any concern16:53
jawn-smithgreat, thanks!16:54
cachio_ijohnson[m], checking 21.10 issue17:22
cachio_4.1G/var/snap/lxd/common/lxd17:22
cachio_I see this 17:22
cachio_4G for the /var/snap/lxd/common/lxd/storage-pools/default/containers/snapcraft-snapd/rootfs17:25
cachio_ijohnson[m], this changed with the new snapcraft 4 I think 17:25
cachio_so, the test can be fixed just adding more disk17:27
cachio_but, not sure id it is ok that size for the lxd image17:27
cachio_ijohnson[m], https://paste.ubuntu.com/p/cHt7mqySZ2/17:31
mupPR snapd#10467 closed: snap: support links map in snap.yaml (and later from the store API) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/10467>17:36
ijohnson[m]cachio_ ack probably increasing the disk size makes sense then 17:44
cachio_ijohnson[m], ack, I'll try with 12gb 17:48
futuretim_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:18
futuretim_or- is there a channel you can direct me to that would be a better fit?18:19
mupPR snapd#10596 opened: tests: use bigger storage on ubuntu 21.10 <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10596>19:17

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!