/srv/irclogs.ubuntu.com/2020/07/16/#snappy.txt

jameshijohnson: edge Snapcraft might let you create device files under LXD now: https://github.com/snapcore/snapcraft/pull/321801:01
mupPR 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
mborzeckimorning05:16
mborzeckiayy store is down?06:32
mborzeckimvo: hey06:48
mborzeckimvo: snap downloads fail, store is down apparently https://status.snapcraft.io/06:48
mborzeckimvo: how does one add 2.45.3 milestone to lp?06:50
mvomborzecki: there is a crate milestone button on "https://launchpad.net/snapd/trunk"06:52
mvomborzecki: uh, store down not great06:52
mborzeckimvo: cool, added 2.45.3 now06:53
mvomborzecki: thank you06:53
pstolowskimorning07:03
mvogood morning pstolowski07:03
mborzeckipstolowski: hey07:09
mupBug #1887760 opened: Installing snap app is not updating required content snap <Snappy:New> <https://launchpad.net/bugs/1887760>07:12
mborzeckimvo: interesting question in the forum https://forum.snapcraft.io/t/minimum-hw-requirements-for-running-ubuntu-core/18892/307:13
mborzeckimvo: aiui storage requirements are higher due to recovery, but not sure about ram, guessing it's roughly the same07:15
mvomborzecki: yeah, should be the same size for ram07:15
mvomborzecki: we always wanted to create a nested spread test that runs with e.g. 256mb to see if it survives our testsuite07:15
mborzeckimvo:  hmm didn't claudio try that and then he hit the grub problem?07:16
mborzecki(for uc20)07:16
mvomborzecki: yeah, I mean for uc16/uc1807:16
mvomborzecki: would still be nice to have such a nested test to ensure we don't regress07:16
mupBug #1887760 changed: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>07:18
mupBug #1887760 opened: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>07:21
mborzeckimvo: we don't have an official ballpark number for storage though?07:25
mupBug #1887760 changed: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>07:27
mborzeckihmm wonder whether there is liek a reference gadget that's within the minimal requirements range07:27
mupBug #1887760 opened: Installing snap app is not updating required content snap <snapd> <Snappy:New> <https://launchpad.net/bugs/1887760>07:30
mvomborzecki: it depends a bit on the kernel size07:33
mvomborzecki: like you can have custom kernels that are smaller07:33
mborzeckiehh, can't build an image, because snapd can't fetch any assertions :/07:33
mvomborzecki: otherwise it's 2*(55Mb+31Mb+1Mb+kernel-size)07:35
mvomborzecki: the reference kernel is very big (168mb)  but no real device is using that07:35
mvomborzecki: well, not *no* but most have a custom optimized kernel07:35
mborzeckimhm07:36
mborzeckineed to run an errand, back in 1h or so07:37
pstolowskihmm i store unhappy? even https://api.snapcraft.io times out07:54
pstolowskiokay, it works but super slow here07:57
mvopstolowski: yes, unhappy08:02
pstolowskimhm08:02
mborzeckire08:20
mborzeckithe store is back, yay08:21
pstolowskigood08:33
mborzeckiis pedronis off today?08:49
mupPR 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
pstolowskipedronis: hi! can we discuss preseed debug after the standup today?10:18
mupPR 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
pedronismvo: what is the fix-preseed branch for?11:03
mvopedronis: this looks like a mistake11:05
pstolowskiyes, was my mistake11:05
pstolowskisorry11:05
pedronisah11:06
mvono worries, I will just delete it11:06
pstolowskigithub confused me yesterday11:06
mvoremoved11:06
pstolowskity11:06
pedronispstolowski: yes, I'll try to write something down beforehand as well11:09
pstolowskipedronis: ok, great, thank you11:11
pedronispstolowski: I shared a doc11:57
pstolowskipedronis: yes, got it, thanks11:59
mupPR 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
pedronispstolowski: I did a pass on #896012:44
mupPR #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
pstolowskipedronis: ty!12:46
mupPR snapd#9020 opened: cmd: add new "snap recovery" command <Created by mvo5> <https://github.com/snapcore/snapd/pull/9020>13:01
mborzeckicachio: switching to test/main/manual now, i'll push a patch soon13:22
cachiomborzecki, nice, thanks13:22
ijohnsonmborzecki: do you mean tests/nested/manual ?13:23
mborzeckiijohnson: yeah, silly typo ;)13:23
mborzeckicachio: i've updated #901914:05
mupPR #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
cachiomborzecki, nice, thanks, I'll take a look14:07
ijohnsoncachio: 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
ijohnsonspread -debug google-nested:ubuntu-20.04-64:tests/nested/manual/core20-early-config14:09
ijohnsonis that the right test ?14:09
mborzeckiijohnson: so it booted then, hmm14:10
ijohnsonmborzecki: I was trying to reproduce the issue cachio explained about the nested test with cloud-init users not being sudoers14:10
mborzeckiijohnson: can you try running google-nested:ubuntu-20.04-64:tests/nested/manual/minimal-smoke from 9019 too?14:11
ijohnsonmborzecki: sure I can give it a try14:11
mborzeckiijohnson: thanks14:11
mupPR snapcraft#3219 opened: meta: detailed warnings for resolution of commands <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3219>14:17
cachioijohnson, yes, it is ok14:22
cachiosometimes it works 5 times14:23
cachioand then fails14:23
ijohnsoncachio: ack I'll keep trying then14:23
mborzeckiijohnson: 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 prompt14:26
ijohnsonmborzecki: are you using google-nested or qemu-nested ?14:26
mborzeckiijohnson: google-nested14:26
ijohnsonah then you start a uc20 nested vm right ?14:26
mborzeckiyes14:27
ijohnsonyeah that will need the special spread version with mvo's patches to support specifying the -bios option from an env var14:27
ijohnsonI don't know if the spread that is downloaded from that s3 link has support for that env var or not14:27
mborzeckido we use that spread binry in any of the tests arleady?14:27
ijohnsongood question, I don't know14:28
ijohnsonI have a locally built version I use14:28
mborzeckicachio: ^^ do you know where i can get it from?14:28
mborzeckiijohnson: but.. the test is running qemu directly14:28
cachiomborzecki, I think you need to build it14:28
mborzeckiijohnson: as in calling qemu-system-x86_64 arg arg ..14:28
ijohnsonmborzecki: ah hmm good point and you're using external backend14:29
ijohnsonmborzecki: maybe you're missing some of the special nested env vars to make booting uc20 work14:29
cachiomborzecki, spread pr not merged yet14:29
mborzeckihmmm i think the test is doing something wrong, we're supposed to boot with efi always14:30
cachiospread2 does not included that yet14:30
cachioI could add that14:30
mborzeckii mean, start_nested_core_vm_unit, it's not setting -bios unless secure boot is enabled14:30
mborzeckiyeah, now it's booting all right14:33
mborzeckineed to run an errand, i'll push the fix when i get back14:35
mborzeckicachio: 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 test14:36
pedronismborzecki: should I review 9005 first or 9006 ?14:36
mborzeckipedronis: i 9005 probably first, then 9006 implements the bootloader bits for grub14:37
cachiomborzecki, I'll try that after lunch14:53
* cachio lunch14:53
pedronismborzecki: is 9006 ready for review, it doesn't seem to match our last discussion?14:59
pedronisI marked it blocked for now15:03
pedronispstolowski: I think #9002 should be split (it's smallish now, but the install case likely needs more tests)15:17
mupPR #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
pstolowskipedronis: sure, will do, thanks15:19
mupPR snapd#9014 closed: snapshotstate: move sizer to osutil.Sizer() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9014>15:21
pedronispstolowski: thx15:23
ijohnsonpedronis: I'm confused as I thought 9006 does implement what we agreed on15:29
pedronisijohnson: is there a mapping between edition and command line?15:30
pedronisI undersand it has one element atm but there isn't15:30
ijohnsonyes, see my comment it's through the assets registration15:30
ijohnsoni.e.15:30
ijohnsonregisterInternal("grub.cfg:edition=1:static_cmdline", []byte(grubBootConfigStaticCmdline))15:30
pedronisheh15:32
ijohnsonit's a little odd using the edition=1 in that, but I think it works fine15:32
pedronisit's fairly odd15:33
pedronisijohnson: mborzecki: I made some more punctual comments15:52
mborzeckire15:55
mupPR snapd#9021 opened: snap: implement new `snap reboot` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/9021>15:57
pedronisijohnson: I expect the command line and the cfg to change at different pace, hopefully cfg will change more often for a while15:59
pedronismborzecki: 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 things16:04
mborzeckipedronis: 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 now16:14
ijohnsonpedronis: yes that makes sense16:15
pedronismborzecki: to be clear I think it fine to store the assets as we do now, and have a different storage16:16
pedronisfor the snippets (as I called them)16:16
mborzeckipedronis: 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
pedronismborzecki: 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
pedronismborzecki: 9005, you mean *without* the setter?16:19
mborzeckipedronis: 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
ijohnsonpedronis: 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 extras16:21
pedronismborzecki: sounds ok for now16:22
pedronismborzecki: I meand 9005 without the setter16:23
mborzeckipedronis: yup, the chats interleave, but that's what i understood16:23
pedronisijohnson: 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 variation16:24
pedroniswe can retrofit it in I suppose if we end up there16:24
ijohnsonpedronis: you could synthetically create an edition from the asset version + kernel cmdline version16:25
ijohnsonI think it is probably fine to retrofit something later on16:25
pedronisijohnson: by definition edition is not synthetic, it's way to say I think old devices should get this16:25
pedronisit's a decision we make16:26
pedronislike for gadget asserts16:26
pedronis*assets16:26
ijohnsonsorry all I meant is that the decision on whether devices get an update is a function of both edition + cmd line16:26
pedronisthat's why we reused the term edition16:26
pedronisijohnson: yea, but I don't see the static command line as separate from the asset16:27
ijohnsonI think we are in agreement that it's probably fine to not support that right now internally16:27
pedronisanyway I think we can retrofit things if needed, as long as we are conscious if we stumble on trying to do that16:27
mupPR 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
pedronisanyway it's another reason why I don't like templating in the commandline16:28
pedronisit's prone to confusion16:28
pedronisit's a case were repetition is feature16:28
pedroniswhere16:28
ijohnsonwell repetition is also prone to bugs using different things in different places16:29
pedroniswell that's why I said we need a test16:29
pedronisijohnson: the risk here is doing a change without understanding the consequences16:30
ijohnsonagreed on a test16:30
ijohnsonI don't disagree that there are many risks in this area16:30
pedronismborzecki: also one of my comments is that it's probably time to do use "go generate" or similar16:30
mborzeckipedronis: yeah, i'm not a fan of go generate, but perhaps it is the time indeed16:31
mborzeckipedronis: we'd still commit the artifacts to git right? otherwise the build process gets weird16:32
pedronismborzecki: we can yes, I don't we do for other things though16:33
pedronisI mean I don't have a strong opinion either way, as long as it works16:33
pedroniswith the packaging16:33
pedronisthis shouldn't change that often (at least after a while)16:33
mborzeckipedronis: there's some strutil helpers that were committed, but the versiontool/version.go gets generated  iirc16:34
pedronisyea16:34
mborzeckihmm why does ssh start in install mode?16:37
pedroniswe don't turn it off unless it's turned off in all modes I think16:37
pedronis(not saying we shouldn't change that)16:37
mborzeckiijohnson: cachio: pushed a tweak to #901916:38
mupPR #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
pedronismborzecki: for clarity: https://github.com/snapcore/snapd/pull/9006#discussion_r45592218116:39
mupPR #9006: bootloader: compose command line with mode and extra arguments <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>16:39
mborzeckiijohnson: 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
ijohnsonah I don't know what's the difference haha16:42
mborzeckiijohnson: to make it more interesting, botha re owned by ovmf package16:42
ijohnsonthey also are slightly different sizes with different hashes :-/16:43
mborzeckiijohnson: https://github.com/tianocore/edk2/commit/1c50db8adaf9d5ce071e27a518a46cd363ac5efe16:45
ijohnsonah so the lowercase dir one is the combined vars and code ?16:46
mborzeckiijohnson: that'd make OVMF.fd all-in-one package16:46
mborzeckiijohnson: probably makes sense given that you can use your own file to store vars?16:47
ijohnsonyes so in this context it's probably fine for CI to use a single file16:47
mborzeckiijohnson: force pushed a little note16:54
=== benfrancis6 is now known as benfrancis
mupPR 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
mupPR snapd#9023 opened: sysconfig/cloudinit: add CloudInitStatus func + CloudInitState type <Created by mvo5> <https://github.com/snapcore/snapd/pull/9023>18:42
mupPR snapd#9024 opened: sysconfig/cloudinit: add RestrictCloudInit <Created by mvo5> <https://github.com/snapcore/snapd/pull/9024>18:47
mupPR snapd#9025 opened: overlord,o/devicestate: restrict cloud-init on Ubuntu Core <Created by mvo5> <https://github.com/snapcore/snapd/pull/9025>18:47
mupPR 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
cachioijohnson, I could reproduce the error also in another test19:55
cachiothe cloud init one19:55
cachioand using an image downloaded from cdimage19:55
cachioso it is not related to that test19:55
ijohnsoncachio: yeah that's what I kinda expected19:56
ijohnsoncachio: 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 system19:57
cachioijohnson, yes, I'll try to reproduce it here19:57
cachioijohnson, quick question19:57
ijohnsonyeah sure19:57
cachioI refresh snapd snap from beta to edge and it reboots the systems19:57
ijohnsonuhhh19:58
cachiothen I revert and the reboot does not happen19:58
cachiois it expected?19:58
cachioon uc2019:58
ijohnsonwhy does it reboot when you refresh the snapd snap ?19:58
ijohnsonafaik we shouldn't reboot with snapd snap refreshes19:58
cachiowell, I expected the same19:59
ijohnsoncachio: was that just a one time thing or does it always happen ?19:59
cachioijohnson, I am trying to finish the test to refresh/revert snandp19:59
cachioand this happened last time19:59
cachionow I am running again19:59
cachioijohnson, so, the only which requires reboot is the kernel?20:08
ijohnsoncachio: 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 updates20:08
cachioijohnson, ok20:11
cachioso I need to update the gadget scenario beause I am waiting the reboot20: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!