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> | 01:01 |
mborzecki | morning | 05:16 |
mborzecki | ayy store is down? | 06:32 |
mborzecki | mvo: hey | 06:48 |
mborzecki | mvo: snap downloads fail, store is down apparently https://status.snapcraft.io/ | 06:48 |
mborzecki | mvo: how does one add 2.45.3 milestone to lp? | 06:50 |
mvo | mborzecki: there is a crate milestone button on "https://launchpad.net/snapd/trunk" | 06:52 |
mvo | mborzecki: uh, store down not great | 06:52 |
mborzecki | mvo: cool, added 2.45.3 now | 06:53 |
mvo | mborzecki: thank you | 06:53 |
pstolowski | morning | 07:03 |
mvo | good morning pstolowski | 07:03 |
mborzecki | pstolowski: hey | 07:09 |
mup | Bug #1887760 opened: Installing snap app is not updating required content snap <Snappy:New> <https://launchpad.net/bugs/1887760> | 07:12 |
mborzecki | mvo: interesting question in the forum https://forum.snapcraft.io/t/minimum-hw-requirements-for-running-ubuntu-core/18892/3 | 07:13 |
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:15 |
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:16 |
mup | Bug #1887760 changed: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760> | 07:18 |
mup | Bug #1887760 opened: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760> | 07:21 |
mborzecki | mvo: we don't have an official ballpark number for storage though? | 07:25 |
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:27 |
mup | Bug #1887760 opened: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760> | 07:30 |
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:33 |
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:35 |
mborzecki | mhm | 07:36 |
mborzecki | need to run an errand, back in 1h or so | 07:37 |
pstolowski | hmm i store unhappy? even https://api.snapcraft.io times out | 07:54 |
pstolowski | okay, it works but super slow here | 07:57 |
mvo | pstolowski: yes, unhappy | 08:02 |
pstolowski | mhm | 08:02 |
mborzecki | re | 08:20 |
mborzecki | the store is back, yay | 08:21 |
pstolowski | good | 08:33 |
mborzecki | is pedronis off today? | 08:49 |
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:10 |
pstolowski | pedronis: hi! can we discuss preseed debug after the standup today? | 10:18 |
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> | 10:40 |
pedronis | mvo: what is the fix-preseed branch for? | 11:03 |
mvo | pedronis: this looks like a mistake | 11:05 |
pstolowski | yes, was my mistake | 11:05 |
pstolowski | sorry | 11:05 |
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:06 |
pedronis | pstolowski: yes, I'll try to write something down beforehand as well | 11:09 |
pstolowski | pedronis: ok, great, thank you | 11:11 |
pedronis | pstolowski: I shared a doc | 11:57 |
pstolowski | pedronis: yes, got it, thanks | 11:59 |
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:21 |
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:44 |
pstolowski | pedronis: ty! | 12:46 |
mup | PR snapd#9020 opened: cmd: add new "snap recovery" command <Created by mvo5> <https://github.com/snapcore/snapd/pull/9020> | 13:01 |
mborzecki | cachio: switching to test/main/manual now, i'll push a patch soon | 13:22 |
cachio | mborzecki, nice, thanks | 13:22 |
ijohnson | mborzecki: do you mean tests/nested/manual ? | 13:23 |
mborzecki | ijohnson: yeah, silly typo ;) | 13:23 |
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:05 |
cachio | mborzecki, nice, thanks, I'll take a look | 14:07 |
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:09 |
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:10 |
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:11 |
mup | PR snapcraft#3219 opened: meta: detailed warnings for resolution of commands <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3219> | 14:17 |
cachio | ijohnson, yes, it is ok | 14:22 |
cachio | sometimes it works 5 times | 14:23 |
cachio | and then fails | 14:23 |
ijohnson | cachio: ack I'll keep trying then | 14:23 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
mborzecki | yeah, now it's booting all right | 14:33 |
mborzecki | need to run an errand, i'll push the fix when i get back | 14:35 |
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:36 |
mborzecki | pedronis: i 9005 probably first, then 9006 implements the bootloader bits for grub | 14:37 |
cachio | mborzecki, I'll try that after lunch | 14:53 |
* cachio lunch | 14:53 | |
pedronis | mborzecki: is 9006 ready for review, it doesn't seem to match our last discussion? | 14:59 |
pedronis | I marked it blocked for now | 15:03 |
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:17 |
pstolowski | pedronis: sure, will do, thanks | 15:19 |
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:21 |
pedronis | pstolowski: thx | 15:23 |
ijohnson | pedronis: I'm confused as I thought 9006 does implement what we agreed on | 15:29 |
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:30 |
pedronis | heh | 15:32 |
ijohnson | it's a little odd using the edition=1 in that, but I think it works fine | 15:32 |
pedronis | it's fairly odd | 15:33 |
pedronis | ijohnson: mborzecki: I made some more punctual comments | 15:52 |
mborzecki | re | 15:55 |
mup | PR snapd#9021 opened: snap: implement new `snap reboot` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/9021> | 15:57 |
pedronis | ijohnson: I expect the command line and the cfg to change at different pace, hopefully cfg will change more often for a while | 15:59 |
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:04 |
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:14 |
ijohnson | pedronis: yes that makes sense | 16:15 |
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:16 |
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:17 |
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:19 |
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:21 |
pedronis | mborzecki: sounds ok for now | 16:22 |
pedronis | mborzecki: I meand 9005 without the setter | 16:23 |
mborzecki | pedronis: yup, the chats interleave, but that's what i understood | 16:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
mborzecki | pedronis: yeah, i'm not a fan of go generate, but perhaps it is the time indeed | 16:31 |
mborzecki | pedronis: we'd still commit the artifacts to git right? otherwise the build process gets weird | 16:32 |
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:33 |
mborzecki | pedronis: there's some strutil helpers that were committed, but the versiontool/version.go gets generated iirc | 16:34 |
pedronis | yea | 16:34 |
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:37 |
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:38 |
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:39 |
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:41 |
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:42 |
ijohnson | they also are slightly different sizes with different hashes :-/ | 16:43 |
mborzecki | ijohnson: https://github.com/tianocore/edk2/commit/1c50db8adaf9d5ce071e27a518a46cd363ac5efe | 16:45 |
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:46 |
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:47 |
mborzecki | ijohnson: force pushed a little note | 16:54 |
=== benfrancis6 is now known as benfrancis | ||
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:37 |
mup | PR snapd#9023 opened: sysconfig/cloudinit: add CloudInitStatus func + CloudInitState type <Created by mvo5> <https://github.com/snapcore/snapd/pull/9023> | 18:42 |
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:47 |
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> | 18:58 |
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:55 |
ijohnson | cachio: yeah that's what I kinda expected | 19:56 |
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:57 |
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:58 |
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 | 19:59 |
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:08 |
cachio | ijohnson, ok | 20:11 |
cachio | so I need to update the gadget scenario beause I am waiting the reboot | 20:11 |
ijohnson | 👍 | 20:16 |
=== ijohnson is now known as ijohnson|EOD |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!