[01:01] <jamesh> ijohnson: edge Snapcraft might let you create device files under LXD now: https://github.com/snapcore/snapcraft/pull/3218
[01:01] <mup> PR snapcraft#3218: lxd: enable security.syscalls.intercept.mknod if supported to allow snaps to create some device nodes <bug> <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3218>
[05:16] <mborzecki> morning
[06:32] <mborzecki> ayy store is down?
[06:48] <mborzecki> mvo: hey
[06:48] <mborzecki> mvo: snap downloads fail, store is down apparently https://status.snapcraft.io/
[06:50] <mborzecki> mvo: how does one add 2.45.3 milestone to lp?
[06:52] <mvo> mborzecki: there is a crate milestone button on "https://launchpad.net/snapd/trunk"
[06:52] <mvo> mborzecki: uh, store down not great
[06:53] <mborzecki> mvo: cool, added 2.45.3 now
[06:53] <mvo> mborzecki: thank you
[07:03] <pstolowski> morning
[07:03] <mvo> good morning pstolowski
[07:09] <mborzecki> pstolowski: hey
[07:12] <mup> Bug #1887760 opened: Installing snap app is not updating required content snap <Snappy:New> <https://launchpad.net/bugs/1887760>
[07:13] <mborzecki> mvo: interesting question in the forum https://forum.snapcraft.io/t/minimum-hw-requirements-for-running-ubuntu-core/18892/3
[07:15] <mborzecki> mvo: aiui storage requirements are higher due to recovery, but not sure about ram, guessing it's roughly the same
[07:15] <mvo> mborzecki: yeah, should be the same size for ram
[07:15] <mvo> mborzecki: we always wanted to create a nested spread test that runs with e.g. 256mb to see if it survives our testsuite
[07:16] <mborzecki> mvo:  hmm didn't claudio try that and then he hit the grub problem?
[07:16] <mborzecki> (for uc20)
[07:16] <mvo> mborzecki: yeah, I mean for uc16/uc18
[07:16] <mvo> mborzecki: would still be nice to have such a nested test to ensure we don't regress
[07:18] <mup> Bug #1887760 changed: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>
[07:21] <mup> Bug #1887760 opened: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>
[07:25] <mborzecki> mvo: we don't have an official ballpark number for storage though?
[07:27] <mup> Bug #1887760 changed: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>
[07:27] <mborzecki> hmm wonder whether there is liek a reference gadget that's within the minimal requirements range
[07:30] <mup> Bug #1887760 opened: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>
[07:33] <mvo> mborzecki: it depends a bit on the kernel size
[07:33] <mvo> mborzecki: like you can have custom kernels that are smaller
[07:33] <mborzecki> ehh, can't build an image, because snapd can't fetch any assertions :/
[07:35] <mvo> mborzecki: otherwise it's 2*(55Mb+31Mb+1Mb+kernel-size)
[07:35] <mvo> mborzecki: the reference kernel is very big (168mb)  but no real device is using that
[07:35] <mvo> mborzecki: well, not *no* but most have a custom optimized kernel
[07:36] <mborzecki> mhm
[07:37] <mborzecki> need to run an errand, back in 1h or so
[07:54] <pstolowski> hmm i store unhappy? even https://api.snapcraft.io times out
[07:57] <pstolowski> okay, it works but super slow here
[08:02] <mvo> pstolowski: yes, unhappy
[08:02] <pstolowski> mhm
[08:20] <mborzecki> re
[08:21] <mborzecki> the store is back, yay
[08:33] <pstolowski> good
[08:49] <mborzecki> is pedronis off today?
[10:10] <mup> PR snapd#9017 opened: o/snapstate: disk space check in Ensure (4/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9017>
[10:18] <pstolowski> pedronis: hi! can we discuss preseed debug after the standup today?
[10:40] <mup> PR snapd#9018 opened: cmd/snap-preseed: check that target path exists and is a directory on --reset <Preseeding 🍞> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9018>
[11:03] <pedronis> mvo: what is the fix-preseed branch for?
[11:05] <mvo> pedronis: this looks like a mistake
[11:05] <pstolowski> yes, was my mistake
[11:05] <pstolowski> sorry
[11:06] <pedronis> ah
[11:06] <mvo> no worries, I will just delete it
[11:06] <pstolowski> github confused me yesterday
[11:06] <mvo> removed
[11:06] <pstolowski> ty
[11:09] <pedronis> pstolowski: yes, I'll try to write something down beforehand as well
[11:11] <pstolowski> pedronis: ok, great, thank you
[11:57] <pedronis> pstolowski: I shared a doc
[11:59] <pstolowski> pedronis: yes, got it, thanks
[12:21] <mup> PR snapd#9019 opened: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9019>
[12:44] <pedronis> pstolowski: I did a pass on #8960
[12:44] <mup> PR #8960: o/snapstate,servicestate: use service-control task for service actions (9/9) <Needs Samuele review> <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8960>
[12:46] <pstolowski> pedronis: ty!
[13:01] <mup> PR snapd#9020 opened: cmd: add new "snap recovery" command <Created by mvo5> <https://github.com/snapcore/snapd/pull/9020>
[13:22] <mborzecki> cachio: switching to test/main/manual now, i'll push a patch soon
[13:22] <cachio> mborzecki, nice, thanks
[13:23] <ijohnson> mborzecki: do you mean tests/nested/manual ?
[13:23] <mborzecki> ijohnson: yeah, silly typo ;)
[14:05] <mborzecki> cachio: i've updated #9019
[14:05] <mup> PR #9019: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9019>
[14:07] <cachio> mborzecki, nice, thanks, I'll take a look
[14:09] <ijohnson> cachio: I've run the core20-early-config nested spread test 3 times now and it hasn't failed yet, I'm running this on master:
[14:09] <ijohnson> spread -debug google-nested:ubuntu-20.04-64:tests/nested/manual/core20-early-config
[14:09] <ijohnson> is that the right test ?
[14:10] <mborzecki> ijohnson: so it booted then, hmm
[14:10] <ijohnson> mborzecki: I was trying to reproduce the issue cachio explained about the nested test with cloud-init users not being sudoers
[14:11] <mborzecki> ijohnson: can you try running google-nested:ubuntu-20.04-64:tests/nested/manual/minimal-smoke from 9019 too?
[14:11] <ijohnson> mborzecki: sure I can give it a try
[14:11] <mborzecki> ijohnson: thanks
[14:17] <mup> PR snapcraft#3219 opened: meta: detailed warnings for resolution of commands <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3219>
[14:22] <cachio> ijohnson, yes, it is ok
[14:23] <cachio> sometimes it works 5 times
[14:23] <cachio> and then fails
[14:23] <ijohnson> cachio: ack I'll keep trying then
[14:26] <mborzecki> ijohnson: cachio: ha, so i'm starting the vm manually with -serial stdio, and i'm getting `error: invalid signature` (probably coming from grub) and then it gets back to the prompt
[14:26] <ijohnson> mborzecki: are you using google-nested or qemu-nested ?
[14:26] <mborzecki> ijohnson: google-nested
[14:26] <ijohnson> ah then you start a uc20 nested vm right ?
[14:27] <mborzecki> yes
[14:27] <ijohnson> yeah that will need the special spread version with mvo's patches to support specifying the -bios option from an env var
[14:27] <ijohnson> I don't know if the spread that is downloaded from that s3 link has support for that env var or not
[14:27] <mborzecki> do we use that spread binry in any of the tests arleady?
[14:28] <ijohnson> good question, I don't know
[14:28] <ijohnson> I have a locally built version I use
[14:28] <mborzecki> cachio: ^^ do you know where i can get it from?
[14:28] <mborzecki> ijohnson: but.. the test is running qemu directly
[14:28] <cachio> mborzecki, I think you need to build it
[14:28] <mborzecki> ijohnson: as in calling qemu-system-x86_64 arg arg ..
[14:29] <ijohnson> mborzecki: ah hmm good point and you're using external backend
[14:29] <ijohnson> mborzecki: maybe you're missing some of the special nested env vars to make booting uc20 work
[14:29] <cachio> mborzecki, spread pr not merged yet
[14:30] <mborzecki> hmmm i think the test is doing something wrong, we're supposed to boot with efi always
[14:30] <cachio> spread2 does not included that yet
[14:30] <cachio> I could add that
[14:30] <mborzecki> i mean, start_nested_core_vm_unit, it's not setting -bios unless secure boot is enabled
[14:33] <mborzecki> yeah, now it's booting all right
[14:35] <mborzecki> need to run an errand, i'll push the fix when i get back
[14:36] <mborzecki> cachio: ijohnson: afaict we're always expecting efi for uc20, so we need to pass -bios /usr/share/ovmf/OVMF.fd even if secure boot is not enabled in the test
[14:36] <pedronis> mborzecki: should I review 9005 first or 9006 ?
[14:37] <mborzecki> pedronis: i 9005 probably first, then 9006 implements the bootloader bits for grub
[14:53] <cachio> mborzecki, I'll try that after lunch
[14:53]  * cachio lunch
[14:59] <pedronis> mborzecki: is 9006 ready for review, it doesn't seem to match our last discussion?
[15:03] <pedronis> I marked it blocked for now
[15:17] <pedronis> pstolowski: I think #9002 should be split (it's smallish now, but the install case likely needs more tests)
[15:17] <mup> PR #9002: o/snapstate: integrate free space checks with install/refresh and remove (3/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9002>
[15:19] <pstolowski> pedronis: sure, will do, thanks
[15:21] <mup> PR snapd#9014 closed: snapshotstate: move sizer to osutil.Sizer() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9014>
[15:23] <pedronis> pstolowski: thx
[15:29] <ijohnson> pedronis: I'm confused as I thought 9006 does implement what we agreed on
[15:30] <pedronis> ijohnson: is there a mapping between edition and command line?
[15:30] <pedronis> I undersand it has one element atm but there isn't
[15:30] <ijohnson> yes, see my comment it's through the assets registration
[15:30] <ijohnson> i.e.
[15:30] <ijohnson> 	registerInternal("grub.cfg:edition=1:static_cmdline", []byte(grubBootConfigStaticCmdline))
[15:32] <pedronis> heh
[15:32] <ijohnson> it's a little odd using the edition=1 in that, but I think it works fine
[15:33] <pedronis> it's fairly odd
[15:52] <pedronis> ijohnson: mborzecki: I made some more punctual comments
[15:55] <mborzecki> re
[15:57] <mup> PR snapd#9021 opened: snap: implement new `snap reboot` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/9021>
[15:59] <pedronis> ijohnson: I expect the command line and the cfg to change at different pace, hopefully cfg will change more often for a while
[16:04] <pedronis> mborzecki: sorry to have turned a bit more prescriptive in 9006, I'm happy to have a chat tomorrow but I think I explained what I think is a workable approach, that doesn't get annoying the first time we need to change one of the two things
[16:14] <mborzecki> pedronis: thanks for the comments, i see what you mean now, i'll tweak how per edition assets are stored internally the, the current string->[]byte would be cumbersome without coming up with a key like i did now
[16:15] <ijohnson> pedronis: yes that makes sense
[16:16] <pedronis> mborzecki: to be clear I think it fine to store the assets as we do now, and have a different storage
[16:16] <pedronis> for the snippets (as I called them)
[16:17] <mborzecki> pedronis: as for 9005, i think that having some code to consume the api would make it clear how SetExtraCommandLineArgs should work (i.e. reseal internally or not?), maybe i should split out the bits that fix the command line and just leave a PR with the setter?
[16:19] <pedronis> mborzecki: ijohnson: also about 9006, does it make sense to change the commandline without bumping the edition (this is not supported by my approach either) ?
[16:19] <pedronis> mborzecki: 9005, you mean *without* the setter?
[16:21] <mborzecki> pedronis: yes, without, there's bits that make it clear that the order is <mode> <static> <extra> and a tweak to bootloader.ManagedAssetsBootloader.CommandLine()
[16:21] <ijohnson> pedronis: mmm so in that case we would be changing the static portion of the kernel command line. tbh I don't think that will change much if at all for amd64/grub, so I don't think it's imperative we have that accounted for right now, what I think would change more likely over the lifetime of a device is the gadget defined extras
[16:22] <pedronis> mborzecki: sounds ok for now
[16:23] <pedronis> mborzecki: I meand 9005 without the setter
[16:23] <mborzecki> pedronis: yup, the chats interleave, but that's what i understood
[16:24] <pedronis> ijohnson: yea, anyway to support changing the commandline without bumping the edition, we would need both edition (that controls the updating) and some kind of version to track variation
[16:24] <pedronis> we can retrofit it in I suppose if we end up there
[16:25] <ijohnson> pedronis: you could synthetically create an edition from the asset version + kernel cmdline version
[16:25] <ijohnson> I think it is probably fine to retrofit something later on
[16:25] <pedronis> ijohnson: by definition edition is not synthetic, it's way to say I think old devices should get this
[16:26] <pedronis> it's a decision we make
[16:26] <pedronis> like for gadget asserts
[16:26] <pedronis> *assets
[16:26] <ijohnson> sorry all I meant is that the decision on whether devices get an update is a function of both edition + cmd line
[16:26] <pedronis> that's why we reused the term edition
[16:27] <pedronis> ijohnson: yea, but I don't see the static command line as separate from the asset
[16:27] <ijohnson> I think we are in agreement that it's probably fine to not support that right now internally
[16:27] <pedronis> anyway I think we can retrofit things if needed, as long as we are conscious if we stumble on trying to do that
[16:28] <mup> PR snapcraft#3220 opened: review tools: link or copy snap to snap common <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3220>
[16:28] <pedronis> anyway it's another reason why I don't like templating in the commandline
[16:28] <pedronis> it's prone to confusion
[16:28] <pedronis> it's a case were repetition is feature
[16:28] <pedronis> where
[16:29] <ijohnson> well repetition is also prone to bugs using different things in different places
[16:29] <pedronis> well that's why I said we need a test
[16:30] <pedronis> ijohnson: the risk here is doing a change without understanding the consequences
[16:30] <ijohnson> agreed on a test
[16:30] <ijohnson> I don't disagree that there are many risks in this area
[16:30] <pedronis> mborzecki: also one of my comments is that it's probably time to do use "go generate" or similar
[16:31] <mborzecki> pedronis: yeah, i'm not a fan of go generate, but perhaps it is the time indeed
[16:32] <mborzecki> pedronis: we'd still commit the artifacts to git right? otherwise the build process gets weird
[16:33] <pedronis> mborzecki: we can yes, I don't we do for other things though
[16:33] <pedronis> I mean I don't have a strong opinion either way, as long as it works
[16:33] <pedronis> with the packaging
[16:33] <pedronis> this shouldn't change that often (at least after a while)
[16:34] <mborzecki> pedronis: there's some strutil helpers that were committed, but the versiontool/version.go gets generated  iirc
[16:34] <pedronis> yea
[16:37] <mborzecki> hmm why does ssh start in install mode?
[16:37] <pedronis> we don't turn it off unless it's turned off in all modes I think
[16:37] <pedronis> (not saying we shouldn't change that)
[16:38] <mborzecki> ijohnson: cachio: pushed a tweak to #9019
[16:38] <mup> PR #9019: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9019>
[16:39] <pedronis> mborzecki: for clarity: https://github.com/snapcore/snapd/pull/9006#discussion_r455922181
[16:39] <mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
[16:41] <mborzecki> ijohnson: hmm i see both /usr/share/ovmf/OVMF.fd and /usr/share/OVMF/OVMF_CODE.fd, i've always used the first one, so what's the difference? :)
[16:42] <ijohnson> ah I don't know what's the difference haha
[16:42] <mborzecki> ijohnson: to make it more interesting, botha re owned by ovmf package
[16:43] <ijohnson> they also are slightly different sizes with different hashes :-/
[16:45] <mborzecki> ijohnson: https://github.com/tianocore/edk2/commit/1c50db8adaf9d5ce071e27a518a46cd363ac5efe
[16:46] <ijohnson> ah so the lowercase dir one is the combined vars and code ?
[16:46] <mborzecki> ijohnson: that'd make OVMF.fd all-in-one package
[16:47] <mborzecki> ijohnson: probably makes sense given that you can use your own file to store vars?
[16:47] <ijohnson> yes so in this context it's probably fine for CI to use a single file
[16:54] <mborzecki> ijohnson: force pushed a little note
[18:37] <mup> PR snapd#9022 opened: usersession/userd: do not modify XDG_DATA_DIRS when calling xdg-open <Created by mvo5> <https://github.com/snapcore/snapd/pull/9022>
[18:42] <mup> PR snapd#9023 opened: sysconfig/cloudinit: add CloudInitStatus func + CloudInitState type <Created by mvo5> <https://github.com/snapcore/snapd/pull/9023>
[18:47] <mup> PR snapd#9024 opened: sysconfig/cloudinit: add RestrictCloudInit <Created by mvo5> <https://github.com/snapcore/snapd/pull/9024>
[18:47] <mup> PR snapd#9025 opened: overlord,o/devicestate: restrict cloud-init on Ubuntu Core <Created by mvo5> <https://github.com/snapcore/snapd/pull/9025>
[18:58] <mup> PR snapd#9026 opened: tests/nested/manual: add spread tests for cloud-init vuln <Created by mvo5> <https://github.com/snapcore/snapd/pull/9026>
[19:55] <cachio> ijohnson, I could reproduce the error also in another test
[19:55] <cachio> the cloud init one
[19:55] <cachio> and using an image downloaded from cdimage
[19:55] <cachio> so it is not related to that test
[19:56] <ijohnson> cachio: yeah that's what I kinda expected
[19:57] <ijohnson> cachio: I have now run that other test 6 times and couldn't reproduce it, if you get a debug shell let me know I would love to take a look at the system
[19:57] <cachio> ijohnson, yes, I'll try to reproduce it here
[19:57] <cachio> ijohnson, quick question
[19:57] <ijohnson> yeah sure
[19:57] <cachio> I refresh snapd snap from beta to edge and it reboots the systems
[19:58] <ijohnson> uhhh
[19:58] <cachio> then I revert and the reboot does not happen
[19:58] <cachio> is it expected?
[19:58] <cachio> on uc20
[19:58] <ijohnson> why does it reboot when you refresh the snapd snap ?
[19:58] <ijohnson> afaik we shouldn't reboot with snapd snap refreshes
[19:59] <cachio> well, I expected the same
[19:59] <ijohnson> cachio: was that just a one time thing or does it always happen ?
[19:59] <cachio> ijohnson, I am trying to finish the test to refresh/revert snandp
[19:59] <cachio> and this happened last time
[19:59] <cachio> now I am running again
[20:08] <cachio> ijohnson, so, the only which requires reboot is the kernel?
[20:08] <ijohnson> cachio: the kernel, the base snap (core20 for uc20, core18 for uc18, core for uc16), and the gadget snap if and only if there are gadget updates
[20:11] <cachio> ijohnson, ok
[20:11] <cachio> so I need to update the gadget scenario beause I am waiting the reboot
[20:16] <ijohnson> 👍