[05:23] <mborzecki> morning
[06:17] <mborzecki> mvo: hey
[06:21] <mvo> hey mborzecki
[06:24] <mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/8686 ?
[06:24] <mup> PR #8686: o/devicestate: cleanup system actions supported by recover mode <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8686>
[06:24] <mvo> mborzecki: sure
[06:28] <mborzecki> mvo: thanks!
[06:30] <mup> PR snapd#8686 closed: o/devicestate: cleanup system actions supported by recover mode <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8686>
[06:30] <mborzecki> yay
[07:00] <pstolowski> morning
[07:01] <pedronis> zyga: hi, could you complete the comment #8123? is the only thing stopping it from landing
[07:01] <mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
[07:01] <zyga> Good morning
[07:01] <zyga> pedronis: certainly, in a moment
[07:10] <pedronis> mvo: should we land #8682 and change the pattern after? or do you prefer it changed first?
[07:10] <mup> PR #8682: tests: port interfaces-password-manager-service to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8682>
[07:11] <zyga> Smak conflict there, lets resolve it
[07:14] <mvo> pedronis: either way is fine
[07:14] <mvo> pedronis: let's land as it will make tests better
[07:14] <mvo> landed
[07:15] <mup> PR snapd#8682 closed: tests: port interfaces-password-manager-service to session-tool <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8682>
[07:16] <pedronis> anyway there's the other one that needs some tweaks
[07:16] <pedronis> still
[07:27] <pedronis> mborzecki: hi, I re-reviewed #8689
[07:27] <mup> PR #8689: o/devicestate: raise conflict when requesting system action while seeding <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8689>
[07:27] <mborzecki> pedronis: thanks, i'm merging master and will address those in the next batch of patches
[07:33] <pedronis> mborzecki: zyga: the fedora failure here is interesting: https://github.com/snapcore/snapd/pull/8692
[07:33] <mvo> I will push a new test-snapd-with-configure{,-core18} to edge, should not affect anyting but if you notice anything strange please let me know and I can revert
[07:33] <mup> PR #8692: configcore: add nomanagers buildtag for conditional build <Created by stolowski> <https://github.com/snapcore/snapd/pull/8692>
[07:34] <zyga> looking
[07:34] <pedronis> mborzecki: zyga: the cleanup is confusing snap.rootfs_* for a snap
[07:34] <pedronis> a bit unclear why there's one around but never the less
[07:44] <zyga> hmmm
[07:44] <zyga> the snap.rootfs_ pattern is unusual to persist
[07:44] <zyga> something has failed earlier and left it there
[07:44] <mborzecki> btw. https://github.com/actions/cache/issues/208 is fixed
[07:45] <mborzecki> mvo: ^^
[07:45] <zyga> oooo
[07:45] <zyga> good :)
[07:45] <mborzecki> we should be able to revive the issue with caches
[07:45] <mborzecki> s/issue/PR/
[07:45] <zyga> 2020-05-20T06:18:51.4079959Z `-/tmp/snap.rootfs_9l42OX    /dev/sda1[/tmp/snap.rootfs_9l42OX] ext4       rw,relatime,seclabel                                                           shared
[07:45] <mvo> mborzecki: holly cow
[07:45] <mvo> mborzecki: let me update my PR
[07:47] <zyga> yeah, this is curious
[07:49] <zyga> I can only say this
[07:50] <zyga> at some point snap-confine -> snap-* startup sequence failed
[07:50] <zyga> this is the only possibility of a leftover /tmp/snap.rootfs_ mount point
[07:50] <zyga> I have two simple ideas: we can add an invariant check to detect those and fail early
[07:50] <zyga> probably a good idea in general
[07:51] <pedronis> pstolowski: mvo: I think #8692 can be either force merged or it needs another run
[07:51] <zyga> and we can also change the temporary directory name to contain the snap name
[07:51] <mup> PR #8692: configcore: add nomanagers buildtag for conditional build <Created by stolowski> <https://github.com/snapcore/snapd/pull/8692>
[07:51] <zyga> but probably not so useful because we use test-snapd-sh a lot so it may be less revealing than a failure at a specific test
[07:52] <zyga> I'll finish with conflicts and then look at this
[07:52] <mvo> pedronis: I can force merge, let me look at the failures
[07:54] <mup> PR snapd#8692 closed: configcore: add nomanagers buildtag for conditional build <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8692>
[07:56] <pstolowski> mvo: thanks
[07:56] <zyga> for the first time I resolved a mount-ns test conflict manually
[07:57] <pedronis> pstolowski: there are some comments in #8697
[07:57] <mup> PR #8697: [RFC] packaging: build cmd/snap with nomanagers tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8697>
[07:58] <pstolowski> pedronis: yes, i've been adressing them (almost done), except for your last comment
[08:00] <mvo> I resurrected 8508 let's see how that goes
[08:01] <pedronis> pstolowski: thx
[08:03] <mup> PR snapd#8631 closed: image,cmd/snap,tests: add support for store-wide cohort keys <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8631>
[08:25] <zyga> hmmm
[08:25] <zyga> mup: ping
[08:25] <mup> zyga: Roses are red, violets are blue, and I don't understand what you just said.
[08:25] <zyga> so mup responds
[08:25] <zyga> is github down?
[08:26] <zyga> no...
[08:26] <zyga> weird
[08:26] <zyga> I cannot git-push
[08:28] <zyga> dns works
[08:28] <zyga> wth?
[08:28] <zyga> mborzecki: can you git push anything to gh?
[08:29] <zyga> or maybe even git fetch
[08:29] <mborzecki> zyga: yup, but had some problems fetching/pushing yesterday afternoon too
[08:29] <zyga> I cannot add comments either
[08:30]  * zyga reboots
[08:32] <zyga> rebooted
[08:32] <zyga> git push hangs
[08:32] <zyga> ssh hangs on
[08:32] <zyga> debug1: Connecting to github.com [140.82.118.4] port 22.
[08:33] <zyga> what does github.com resolve on your machine mborzecki ?
[08:33] <mborzecki> zyga: 140.82.114.3 atm
[08:33] <zyga> hmmm
[08:33] <zyga> same result
[08:33] <zyga> sigh
[08:33] <zyga> what a morning
[08:35] <mup> PR snapd#8702 opened: overlord/configstate: add log-control option <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8702>
[08:42] <zyga> gah
[08:42] <zyga> any ideas
[08:50] <zyga> it works :)
[08:52] <mvo> zyga: 8578 looks ready - does it need jdstrand first or can I merge?
[08:52] <zyga> checking
[08:52] <mvo> zyga: hrm, I guess it does need him?
[08:52] <zyga> yeah, I think he wanted to see it
[09:06] <pedronis> mvo: should we turn all the ubuntu-20.04-* in our tests task.yaml to ubuntu-2* ?
[09:11] <zyga> brb
[09:16] <mvo> pedronis: I think so
[09:16] <mvo> pedronis: not sure if zyga replied to my suggestion yet, I don't see a downside
[09:16] <mvo> (but maybe I'm missing something?)
[09:16] <zyga> mmm, mvo the one on tests to use 2*
[09:17] <zyga> I didn't but I think it's a good idea
[09:17] <mvo> zyga: cool, then we are in agreement
[09:17] <zyga> but perhaps as a separate pass to do everything in one go
[09:17] <mvo> sure
[09:22] <mborzecki> pedronis: i've updated https://github.com/snapcore/snapd/pull/8689 also with some additional checks for non-uc20
[09:22] <mup> PR #8689: o/devicestate: raise conflict when requesting system action while seeding <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8689>
[09:23] <mborzecki> pedronis: i suppose it's ok to assume that there's no explicit system mode in non-uc20
[09:26] <pedronis> mborzecki: various methods will say we are in run mode?
[09:27] <pedronis> zyga: mvo: yes, as a separate pass, there's a bunch, also there are core20 nested tests that I think really want 20.04 precisely
[09:27] <zyga> pedronis: mmm, indeed, I think a simple guideline is that if a test is precise and targets one thing it can stay that way, if it targets subsequent LTSes we can expand that to include 2*
[09:37] <mborzecki> pedronis: it's in the contxt of system requests on uc16/18, we don't support that and might as well error out early in such case
[09:37] <pedronis> mborzecki: yes, I'm actually looking at that code
[09:37] <pedronis> we don't do that anywhere else
[09:37] <pedronis> I'm not sure it's a good check
[09:38] <pedronis> mborzecki: which reminds me that the code should use m.SystemMode() and not systemMode much more
[09:38] <mborzecki> pedronis: it will be blocked later on anyway, so it's ok to drop that
[09:40] <pedronis> or maybe we should change things to just set systemMode to run
[09:40] <pedronis> and make SystemMode a straight accessor
[09:41] <mborzecki> pedronis: yes, it's a bit confusing, otoh knowing when it's != "" gives us a little more insight as it's set only based on modeenv
[09:42] <pedronis> yes, what something has to give, either we refuse to operate on modeenv without mode
[09:42] <pedronis> early
[09:42] <pedronis> or something
[09:42] <pedronis> right is all a bit not well defined
[09:45] <pedronis> mborzecki: we never write modeenvs without mode, right?
[09:46] <mborzecki> pedronis: i don't think we do, but looking at the modeenv code there's no sanity check for Mode != ""
[09:47] <mborzecki> and tests seem to disagree now that i added such check, heh
[09:49] <mborzecki> fortunately it's just the test mocks
[09:51] <pedronis> mborzecki: yea, I think we want the read in boot to fail if no mode
[09:51] <pedronis> an deal with it
[09:51] <pedronis> mborzecki: can be a follow up
[09:59] <pedronis> mvo: thanks for the new test, I added some comments in #8351, I see the newline issue only in the full diff view
[09:59] <mup> PR #8351: config: apply vitality-hint immediately when the config changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/8351>
[10:01] <mvo> pedronis: aha, thanks! I misread your comment about the gadget service, I will add that too
[10:09] <pedronis> #8689 needs 2nd reviews
[10:09] <mup> PR #8689: o/devicestate: raise conflict when requesting system action while seeding <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8689>
[10:20] <pedronis> mborzecki: #8661 is unblocked now, can you do another pass? (I will look myself but later)
[10:20] <mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
[10:45] <mup> PR snapd#8703 opened: tests: detect signs of crashed snap-confine <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8703>
[11:05] <mup> PR snapd#8123 closed: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8123>
[11:20] <mup> PR snapcraft#3132 closed: go v1 plugin: warn when using go.mod and go < 1.13 <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3132>
[11:44] <mup> PR snapcraft#3133 opened: go v1 plugin: go.mod support for 1.11 and 1.12 <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3133>
[11:49] <zyga> pedronis: thanks for merging
[12:11] <cmatsuoka> cachio: I pushed a fix for PR 8700 but we need to check with zyga if the latest spread is in use
[12:11] <mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
[12:11] <zyga> cmatsuoka: thanks, I'll check that now
[12:11] <cachio> cmatsuoka, checking
[12:13] <cachio> cmatsuoka, I see the test is failing with
[12:13] <cachio> panic: cannot seal the encryption key: cannot seal and store encryption key: cannot add EFI secure boot policy profile: cannot compute secure boot policy digests: the current boot was performed with secure boot disabled in firmware
[12:13] <zyga> updating spread
[12:13] <cmatsuoka> cachio: yes, it should work after zyga updates spread
[12:14] <pedronis> cmatsuoka: that's an example of the errors that we need to think now to imrpove
[12:14] <pedronis> *how
[12:14] <zyga> our our defense it's much better than random errors from software
[12:15] <zyga> but we do need to think about how to make a pattern for such errors that is easier to understand
[12:15] <pedronis> yes, at least in this one most levels add some info (except the first two that feals redundant)
[12:15] <pedronis> the one I saw the other day was worse
[12:16] <zyga> that's true
[12:16] <zyga> at least it's not a backtrace :)
[12:16] <cmatsuoka> pedronis: in this case the first three are ours and we can clean them up, I'll check that
[12:16] <pedronis> cmatsuoka: ah, interesting
[12:25] <mup> PR snapd#8704 opened: cmd/snap-preseed: improve mountpoint checks of the preseeded chroot (1/2) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8704>
[12:27] <cmatsuoka> pedronis: the tpm-sealing-in-secboot PR already gets rid of the second level
[12:33] <zyga> cmatsuoka: done
[12:33] <cmatsuoka> zyga: thanks!
[12:34] <cmatsuoka> I restarted the tests, let's see what happens...
[12:38] <cmatsuoka> zyga: I was playing with the pi4 here, and interestingly it keeps the cpu frequency at the maximum value even idle and with the ondemand governor
[12:38] <zyga> cmatsuoka: on ubuntu or raspbian?
[12:38] <cmatsuoka> changing it to conservative made it drop the frequency
[12:38] <cmatsuoka> it's the current core20 beta
[12:38] <zyga> I see
[12:39] <zyga> feels like a bug
[12:39] <zyga> how do I check the freq?
[12:39] <zyga> I can check core18 on mine
[12:39] <cmatsuoka> zyga: yes, please do, I'll check classic too
[12:40] <cmatsuoka> hmm, interesting, switching back to ondemand now keeps the freq low
[12:41] <zyga> not sure if that's the right measurement
[12:41] <zyga> zyga@pi4-1:/sys/devices/system/cpu/cpufreq/policy0$ sudo cat cpuinfo_cur_freq
[12:41] <zyga> 1500000
[12:41] <cmatsuoka> root@ubuntu:/home/cmatsuoka# cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
[12:41] <cmatsuoka> 600000
[12:42] <zyga> I'm on "ondemand"
[12:42] <zyga> perhaps a kernel bug?
[12:42] <cmatsuoka> try to switch to powersave and go back to ondemand
[12:43] <zyga> cmatsuoka: raspbian on a pi0w has the same behavior
[12:43] <zyga> 1GHz
[12:43] <cmatsuoka> humm interesting
[12:43] <zyga> I don't have another pi4 to confirm raspbian semantics there
[12:43] <zyga> I have a large heatsink with two fans so it's not a problem
[12:43] <zyga> but perhaps it does save some power
[12:44] <zyga> I could connect it to my power supply and measure later if you are interested
[12:45] <cmatsuoka> I'm using a small heatsink with no fans so it tends to heat up a little bit
[12:46] <cmatsuoka> zyga: yeah, measuring could be interesting -- at least we'll know how well cpufreq works power-wise
[12:46] <zyga> cmatsuoka: I need to look how to do that, I have a hacked micro cable but not a hacked usb-c cable
[13:25] <zyga> stgraber: I think lxc file push needs confuses --mode
[13:25] <zyga> an octal input is doing funny thing
[13:28] <zyga> jdstrand: some low hanging fruit: https://github.com/snapcore/snapd/pull/8578
[13:28] <mup> PR #8578: interfaces: add system-packages-doc interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
[13:29] <jdstrand> zyga: yes, I'm pivoting to PR reviews later today once I finish the store reviews which are almost done
[13:29] <zyga> super, thank  you :)
[13:29] <zyga> it's not urgent
[13:29] <zyga> just low-hanging
[13:29]  * jdstrand nods
[13:37] <zyga> stgraber: s/needs// -- i meant to say that it seems it is confused by what --mode= is supposed to be, giving octal values does funny stuff
[13:38] <court_jester> What's the difference between #snappy and #snapcraft?
[13:39] <stgraber> zyga: with our without leading 0?
[13:39] <zyga> without
[13:39] <zyga> I think decimal mode is quite unusual so I didn't pass it
[13:41] <zyga> court_jester: snappy is where most snapd developers talk
[13:41] <ogra> court_jester, they kind of overlap ... but the fcus here is snapd development, Ubuntu Core development and such
[13:41] <zyga> court_jester: snapcraft is where the snapcraft developer hang and where loads of people ask questions
[13:41] <ogra> while the snapcraft channel is for developing snapcraft but also of packaging etc
[13:41] <zyga> snapd is the package manager, snapcraft is the package builder
[13:42] <ogra> s/of/for/
[13:42] <zyga> mvo: should I drop the bitcacher now?
[13:42] <ogra> take 8 of them and make it a bytecacher ;)
[13:44] <mvo> zyga: yes please
[13:44] <zyga> over the parallel port
[13:44] <zyga> mvo: ack
[13:45] <zyga> done
[13:45] <mvo> ta
[14:02] <zyga> gah
[14:02] <zyga> I need to reboot again
[14:02] <zyga> suspend during the standup nuked X input
[14:04] <zyga> re
[14:05] <zyga> cmatsuoka: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=274595&sid=05bfd24c66e0458db63482ae20121427
[14:05] <zyga> ^ also a case for that eeprom update we talked about
[14:05] <zyga> very tempted to buy a pi4 for testing this
[14:05] <cmatsuoka> ah intersting
[14:06] <zyga> pair pi4 with a SSD
[14:06] <zyga> also case for ubuntu core *installer* that you use to write from sd to other storage
[14:07] <zyga> I only wish pi4 firmware was open source
[14:13] <pstolowski> short break, bbiab
[14:13]  * ogra recommends https://www.amazon.co.uk/dp/B078SVRH4B/ref=twister_B07XTSVFS4?_encoding=UTF8&psc=1 for the pi4 
[14:13] <ogra> it flies with writable on the SSD (and system-boot on SD)
[14:15] <cmatsuoka> nice!
[14:15] <zyga> ogra: thanks!
[14:15] <zyga> oh, and usb-c too
[14:16] <zyga> I personally would prefer something that I can fuse into one big enclosure, so that it's not a tangled mess of wires
[14:16] <zyga> but I think that's very hard with pi design
[14:18] <ogra> well, you might find cases to print on thingverse
[14:20] <zyga> yeah, that's true
[14:21] <zyga> I wish WD kept making those pi-specific usb drives
[14:21] <zyga> just updated to SSDs now
[14:21] <zyga> I still have the original set and it is amazing, apart from being a hdd
[14:21] <zyga> (and the notion of native USB-HDD is fuN)
[14:23] <ogra> i wish the pi foundation would add an M.2 PCIe socket to the next pi4 interation :)
[14:24] <ogra> that saves all case issues by simply mounting it to the board itself
[14:24] <zyga> yeah
[14:25] <zyga> with pi4 having pci-e anyway, I think it's doable
[14:25] <zyga> and could be something to put on that bottom side :)
[14:25] <ogra> i really love the nanopc-t4 for that ... but still having driver issues (it occasionally dies even with BSP kernel snap)
[14:25] <ogra> (but if it doesnt die ... OMG it is fast !)
[14:25] <ogra> :)
[14:27] <cmatsuoka> "tangled mess of wires" is something I'm getting increasingly familiar with
[14:27] <mvo> zyga: 2020-05-20T12:53:27.3457005Z invariant-tool: system is corrupted - in https://github.com/snapcore/snapd/pull/8703/checks?check_run_id=692478727 maybe that is helpful?
[14:28] <mup> PR #8703: tests: detect signs of crashed snap-confine <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8703>
[14:29] <zyga> mvo: yes!
[14:29] <zyga> looking
[14:29] <zyga> fantastic
[14:29] <zyga> thank you
[14:30] <zyga> I think it's a red herring here as old snap-confine did not clean some things up
[14:30] <zyga> but it surely works
[14:30] <zyga> and I wonder why it only failed here
[14:30] <zyga> ah, that's the PR introducing it
[14:30] <zyga> :D
[14:30] <zyga> I'll adjust the test
[14:30] <zyga> thanks
[14:45] <cachio> cmatsuoka, https://paste.ubuntu.com/p/WQ7ZcDKmD5/
[14:45] <cachio> I see thie error now
[14:45] <cachio> I'll try to update the fedora image
[14:45] <cmatsuoka> this error is strange
[14:46] <cmatsuoka> ah, I think you're trying to create the instance with shieldedInstanceConfig empty
[14:47] <cmatsuoka> does it make sense?
[14:50] <cachio> cmatsuoka, I am just sending the parameters list empty when secboot is not enabled
[14:50] <cachio> as I do with all the systems
[14:50] <zyga> hmm
[14:50] <zyga> 2020-05-20 14:49:17 Cannot allocate google:amazon-linux-2-64: cannot allocate new Google server for amazon-linux-2-64: invalid value for field 'resource.shieldedInstanceConfig': ''. Shielded VM Config can only be set when using a UEFI-compatible disk
[14:50] <zyga> I think the thing we did did not do the thing we hoped it does
[14:50] <zyga> cmatsuoka: ^
[14:50] <zyga> does this indicate the spread patch is buggy
[14:50] <cmatsuoka> cachio: and only fedora didn't like it?
[14:51] <cachio> zyga, mmm, also amazon-linux
[14:51] <zyga> this is from upstream spread now failing on our tests
[14:51] <cachio> zyga, yes
[14:51] <zyga> it feels like we need to revert something
[14:51] <cachio> semms to be a gce thing
[14:51] <zyga> I'll break for lunch and let you figure it out, I can happily deploy updated spread in minutes
[14:51] <zyga> it seems the setting only works if the image is using UEFI
[14:51] <zyga> which is sensible
[14:51] <zyga> spread patch was not tested properly
[14:52] <cachio> I know the simple fix for spread , but perhaps I can solve it from gce
[14:52] <cachio> zyga, agree, I just validates that in some systems
[14:55] <pstolowski> re
[14:56] <zyga> cachio, cmatsuoka: please get a patch reviewed and ping me for deployment
[14:57] <cmatsuoka> zyga: ack
[14:57] <cachio> zyga, I'll update the images first
[15:00] <cachio> zyga, I think the main problem is how we create the images, but seems to be also a problem in gce, because it doesn't like the configuration parameter even if it goes empty
[15:00] <cachio> so for fedora we send the parameter empty and gce does not like the parameter
[15:01] <cachio> I need to fix  that on spread
[15:01] <cachio> zyga, but first I'll update our images to support uefi configurations
[15:01] <zyga> cachio: perhaps fixing spread is faster
[15:01] <cachio> and that is a trivial change
[15:01] <zyga> there's no telling what happens if we move to uefi boot
[15:02] <zyga> maybe something else breaks
[15:02] <cachio> zyga, we are not moving to uefi oot
[15:02] <cmatsuoka> cachio: I changed your code a little bit and I'll run a test here
[15:02] <zyga> so what does the image update entail?
[15:03] <cachio> zyga, the change I am doing is telling to gce that the image now is compatible with uefi, but it does not mean we are going to use uefi
[15:04] <cachio> zyga, will just allow us to send uefi parameters
[15:04] <cachio> while the instance is created
[15:04] <zyga> so are there two knobs in GCE: 1) uefi supported 2) really use uefi to boot?
[15:04] <cachio> yes
[15:04] <zyga> weird :)
[15:04] <zyga> ok
[15:04] <cachio> uefi suported you set when you create the image
[15:05] <cachio> boot with uefi you set it when you start the image
[15:05] <cachio> so you can choose
[15:05] <cachio> either if you want to boot with uefi or not
[15:05] <cachio> the same image
[15:06] <cachio> lets make a try with this change, and then make the update in spread
[15:11] <zyga> sounds good
[15:13] <zyga> brb
[15:14] <zyga> mborzecki: I'll update opensuse today
[15:14] <zyga> mborzecki: maybe next week we could chat about suse security's group idea
[15:19] <cachio> zyga, fedora 31 is updated and now boots well
[15:19] <cachio> I'll run the entire suite to validate there is not side efect
[15:20] <cachio> zyga, udpating amazon linux now
[15:42] <zyga> ta
[15:44] <cmatsuoka> cachio: wdyt about something like https://pastebin.ubuntu.com/p/vtNg3Nx5Gk/ ?
[15:45] <mvo> mborzecki: probably for tomorrow 8508 is ready but sadly all spread tests worked so we can't test the re-run in a meaningful way
[15:45] <mvo> mborzecki: still ready for review
[15:45] <cmatsuoka> cachio: it also addresses some of gustavos comments on your original patch
[15:47] <mup> Issue core18#153 opened: missing /etc/cloud/cloud.cfg.d/99-snappy-azure.cfg <Created by anonymouse64> <https://github.com/snapcore/core18/issue/153>
[15:48]  * zyga break to rest from standing
[15:49] <zyga> more more more tests coming after
[15:52] <cachio> cmatsuoka, I'll check it
[15:52] <cachio> in the mean time I already updated fedora and amazon linux images
[15:52] <cachio> so those are now working again
[15:54] <cmatsuoka> cachio: it's important to fix spread as well, I suppose we're not the only users
[15:54] <cachio> cmatsuoka, we I update the images that all use
[15:55] <cachio> cmatsuoka, but the spread fix is also important
[15:55] <cachio> cmatsuoka, are you creating a PR with that?
[15:56] <cmatsuoka> I could, than perhaps you could run some tests on it?
[15:56] <cachio> zyga, cmatsuoka as retrospective I think we need to be able to run some tests to validate the google backend
[15:57] <cachio> cmatsuoka, ok, let me test it
[15:57] <cmatsuoka> s/than/then/
[15:59] <cachio> cmatsuoka,  in the PR 8700 just failing the ubuntu-secboot system
[15:59] <mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
[15:59] <cachio> cmatsuoka, do you know how to fix it?
[15:59] <cmatsuoka> cachio: is it the secure boot disabled bug? in this case I think we're running the old spread there
[16:00] <cachio> cmatsuoka, well, we can run the new spread now
[16:01] <cachio> zyga, is it possible to use the new spread there?
[16:01] <zyga> where?
[16:01] <cachio> in the pr 8700
[16:02] <mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
[16:02] <zyga> cachio: ?
[16:02] <cachio> zyga are we using the old spread there?
[16:02] <zyga> cachio: spread is not specific to a PR
[16:02] <zyga> cachio: I don't understand your question
[16:02] <zyga> cachio: since we don't print spread version anywhere it's hard to guess
[16:02] <cachio> zyga, I misunderstood what claudio said I think
[16:03] <zyga> cachio: but I've updated spread across all the runners during the standup call
[16:03] <cachio> zyga, we are using the last spread right?
[16:03] <zyga> cachio: master
[16:03] <cmatsuoka> it's interesting, because 8700 fails with the "current boot was performed with secure boot disabled in firmware" error
[16:03] <cachio> zyga, perfect
[16:03] <cachio> cmatsuoka, yes
[16:03] <zyga> when did it fail, was it after the standup?
[16:03] <cachio> not sure why but I debugged that test and secure boot is enabled
[16:04] <cmatsuoka> zyga: I restarted the tests after the standup, yes
[16:05] <zyga> hmmm
[16:05] <zyga> one sec
[16:05] <zyga> drat, my fault
[16:05] <zyga> sorry, updating on nodes other than 1
[16:05] <cachio> zyga, nice
[16:06] <cachio> thanks
[16:06] <cachio> zyga, I need to see if another image needs to be updated
[16:06] <zyga> cachio: please restart them again
[16:07] <cmatsuoka> restarted
[16:11] <cachio> cmatsuoka, I already did it
[16:11] <cachio> but for everything
[16:11] <cachio> I need to see if any systems needs to be updated
[16:12] <zyga> cachio: can you update leap / tw as well please
[16:12] <zyga> maybe you did earlier
[16:13] <cachio> I'll need to update some other images as well
[16:15] <zyga> ok
[16:23] <kyrofa> Does https://snapcraft.io/build build a new snap for pushes on ANY branch? Or only the default?
[16:23] <diddledan> only the default IIRC
[16:25] <kyrofa> Oh, that's unfortunate
[16:25] <kyrofa> roadmr, can you confirm?
[16:30] <ijohnson> mvo: reviewed 8661, it has 2 +1's now
[16:32] <pedronis> ti doesn't need my review I think, but maybe Pawel should give it a quick look
[16:35] <mvo> ijohnson: I merged your suggestion too, thanks for this
[16:35] <cjwatson> kyrofa: it's a web team thing
[16:35] <cjwatson> rather than store team
[16:37] <kyrofa> cjwatson, ah, I was wondering if I might end up addressing that question to you
[16:37] <cjwatson> I stopped working on this a year or two ago - definitely owned by the web team now :)
[16:37] <cjwatson> (I was involved in getting the thing up and running, but not long-term)
[16:38] <kyrofa> I don't actually know who that is these days, can you point me in the right direction?
[16:38] <pedronis> time is hard our gdoc thinks monday was the 17
[16:38] <diddledan> pedronis, well to be fair time is an illusion since we went into lockdown ;-p
[16:38] <cjwatson> kyrofa: https://github.com/canonical-web-and-design/snapcraft.io/issues probably
[16:38] <cjwatson> (I don't have names for you)
[16:39] <kyrofa> Ah, someone there should probably idle here
[16:39] <diddledan> yeah it'ld be a good idea for someone who maintains the build service to idle around here for questions
[16:40] <diddledan> or in #snapcraft.. I still haven't worked out how to determine which channel I should be talking in ;-p
[16:40] <kyrofa> Lukewh, any chance you know everything there is to know about https://snapcraft.io/build?
[16:40] <ijohnson> pedronis: I think most of those issues are my fault tbh since I'm usually the one to add the new day in the gdoc haha
[16:42] <pedronis> ijohnson: it's not a serious problem but I was confused for a bit
[16:42] <zyga> cachio: can you please ping me when all images are up-to-date
[16:42] <ijohnson> yeah I was quite confused myself when I realized we are not actually in june yet
[16:42] <cachio> zyga, all of them are updated
[16:43] <zyga> cachio: ah, excellent
[16:43] <zyga> cachio: I'll restart a few PRs to see what we get
[16:43] <cachio> I just retriggered the tests on that PR
[16:43] <zyga> thanks!
[16:43] <Lukewh> kyrofa: please file an issue. I need to verify the flow and I'm EODing so it'll remind me to check tomorrow :)
[16:44] <cachio> I already run a test in all the ysstems to validate it
[16:44] <kyrofa> Lukewh, will do
[16:44] <Lukewh> kyrofa: thanks. make sure you say what you'd like to happen and we can see if we can do it
[16:47] <zyga> mvo: https://github.com/snapcore/snapd/pull/8508#pullrequestreview-415527869
[16:47] <mup> PR #8508: github: run all spread systems in a single go with cached results <Created by mvo5> <https://github.com/snapcore/snapd/pull/8508>
[16:51] <zyga> mvo: https://github.com/snapcore/snapd/pull/8681#discussion_r428163052
[16:51] <mup> PR #8681: tests: port interfaces-accounts-service to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8681>
[16:52] <zyga> and I'll send a follow up to update tests to cover 2*
[16:54] <mvo> zyga: thanks, merged
[16:54] <zyga> thanks!
[16:55] <mup> PR snapd#8681 closed: tests: port interfaces-accounts-service to session-tool <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8681>
[16:55] <zyga> mvo: if you have a moment today, pushing forward that caching PR would be great
[16:55] <cachio> zyga, now I see this error
[16:55] <cachio> https://paste.ubuntu.com/p/F3Vgw6bp4V/
[16:55] <zyga> cachio: looking
[16:55] <cachio> this image didn't change
[16:55] <zyga> cachio: heh
[16:55] <zyga> cachio: /dev/sda1             9983268 4923644   5043240  50% /
[16:55] <zyga> but
[16:55] <zyga>  /dev/mapper/loop2p3    380872  372800         0 100% /mnt
[16:55] <zyga> this is full
[16:56] <cachio> yes
[16:56] <cachio> it happens after I merged with master
[16:56] <zyga> what do we mount at /mnt?
[16:56] <cachio> did yo usee that in another pr?
[16:56] <zyga> no
[16:57] <zyga> I said "heh" because it seems that today everything breaks a little
[16:57] <cachio> zyga, ok I'll research in that case
[16:57] <zyga> it seems like the reflash magic
[16:57] <cachio> yes
[16:57] <zyga> note that ubuntu-core-16-64 uses an explicit image name
[16:57] <cachio> yes
[16:57] <zyga> maybe the implicit name we get for ubuntu-16.04-64 is different?
[16:58] <cachio> but that image didnt receive any change
[16:58] <zyga> check what we mount and what determines the size
[16:58] <cachio> zyga, yes
[16:58] <zyga> btw
[16:58] <zyga> the exclude patterns look wrong
[16:59] <zyga> we don't use /gopath, do we? we moved to /home/gopath
[16:59] <zyga> so those are probably copying build noise
[16:59] <zyga> anyway, 7PM
[16:59]  * zyga EODS
[16:59] <zyga> o/
[17:00] <cachio> zyga, enjoy, lets continue tomorrow
[17:00] <cachio> see you
[17:24] <pedronis> mmh, 8681 needed a tweak before merging
[17:31] <zyga> pedronis: what kind, I can send a patch quickly
[17:31] <pedronis> zyga: it was in my comments there
[17:31] <zyga> (back in the office for some stuff)
[17:31] <zyga> looking
[17:32] <pedronis> the autoremove will not remove the thin we installed manually
[17:32] <zyga> I see it
[17:32] <zyga> thanks, I'll fix that in a moment
[17:32] <pedronis> we need to first remove it and then autoremove the rest
[17:32] <pedronis> zyga: thx
[17:35] <zyga> pedronis: https://github.com/snapcore/snapd/pull/8705
[17:35]  * zyga back to afk
[17:35] <pedronis> thx
[17:35] <mup> PR #8705: tests: remove gnome-online-accounts we install <Simple 😃> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8705>
[17:35] <mup> PR snapd#8705 opened: tests: remove gnome-online-accounts we install <Simple 😃> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8705>
[18:42] <mup> PR snapcraft#3133 closed: go v1 plugin: go.mod support for 1.11 and 1.12 <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3133>
[18:53] <cmatsuoka> cachio: https://github.com/snapcore/spread/pull/105 is my attempt to solve the issue
[18:54] <mup> PR spread#105: google: only configure shielded instance when secure boot is enabled <Created by cmatsuoka> <https://github.com/snapcore/spread/pull/105>
[18:54] <cmatsuoka> cachio: it also changes secureboot: to secure-boot: so PR 8700 will have to be changed accordingly
[18:54] <mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
[18:56] <cachio> cmatsuoka, yes, but once this pr is merged into spread
[18:56] <cmatsuoka> yes
[18:56] <cmatsuoka> or when zyga makes this version available to snapd, I don't know how our private deployments work
[18:58] <cachio> cmatsuoka, didn't work
[18:58] <cachio> same issue I see
[18:59] <cachio> cmatsuoka, I need to go to the doctor now, I'll fix it and test it and push
[18:59] <cachio> once I am back
[18:59] <cmatsuoka> cachio: oh really? I tested it here with create-partitions-encrypted and it worked (with secureboot changed to secure-boot in spread.yaml)
[18:59] <cmatsuoka> ok
[19:00] <cachio> cmatsuoka, I tested to run a test with not secboot
[19:00] <cachio> and it fails with the same error
[19:00] <cachio> https://paste.ubuntu.com/p/c7NQcNQmfB/
[19:01] <cachio> cmatsuoka, I'll run again when I am back
[19:01] <cachio> in 1 hour
[19:01] <cmatsuoka> ok, I'll test with fedora in the meantime
[19:01]  * cachio afk
[19:02] <cachio> remember all the images support uefi now
[19:03] <cachio> so it will work :)
[19:03] <cachio> cmatsuoka, you can try with the image fedora-31-64-base
[19:03] <cmatsuoka> ok!
[19:04] <zyga> cmatsuoka: I can do it now
[19:04]  * zyga waves from the garden
[19:05] <zyga> cmatsuoka: is spread master updated?
[19:42] <mup> PR snapcraft#3134 opened: cli: nicer message for status with no releases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3134>
[20:03] <cmatsuoka> cachio: I got this with fedora-31-64: https://pastebin.ubuntu.com/p/c5t9RdzBqv/
[20:21] <zyga> cmatsuoka: o/
[20:21] <zyga> 020-05-20 16:24:43 Project content is packed for delivery (176.12MB). <- ??
[20:21] <zyga> that's a lot
[20:22] <cmatsuoka> zyga: indeed, maybe there's something that shouldn't be there
[20:22]  * cmatsuoka checks
[20:23] <zyga> do you need me to do anything with spread?
[20:23] <cmatsuoka> zyga: I'm waiting for sergio to validate my fixes, it works in my tests but it seems that it failed for him in an unexpected way
[20:24] <cmatsuoka> and yes, there was a compressed image in the spread-image directory
[20:24] <cmatsuoka> I mean, a compressed core image
[20:24] <zyga> cmatsuoka: maybe a candidate to spread exclude
[20:25] <cmatsuoka> I really don't know why it was there
[20:25] <cmatsuoka> probably a leftover from a previous test
[20:37] <mup> PR core20#60 closed: Copy-in launchpad's build-archive <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/60>
[20:39] <mup> Issue core20#57 closed: "man" command should not suggest running unminimize <Created by anonymouse64> <Closed by xnox> <https://github.com/snapcore/core20/issue/57>
[20:39] <mup> PR core20#59 closed: static: provide friendly message when "man" is used <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/59>
[21:02] <cachio> cmatsuoka, hey
[21:03] <cachio> cmatsuoka, #8700 is in green now
[21:03] <mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
[21:03] <cachio> cmatsuoka, zyga left some comments there about the changes that you did to the test, could you please answer those?
[21:04] <cmatsuoka> cachio: ack, also I'm wondering why PR 105 failed for you, I succesfully opened a shell in fedora-31-64
[21:04] <mup> PR #105: Track capability types <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/105>
[21:10] <cmatsuoka> cachio: answered the comments in the PR
[21:12] <cmatsuoka> cachio: is there a non-uefi image I can use to test spread?
[21:13] <cmatsuoka> cachio: I see you used fedora-32-64 in your test and I tested fedora-31-64, are those different to the point it could affect this test?
[21:16] <cachio> cmatsuoka, you need to test fedora-31-64-base and fedora-31-64
[21:16] <cachio> cmatsuoka, the first does not support uefi
[21:16] <cachio> the second it does
[21:17] <cachio> cmatsuoka, in my case it failed with the images that don't support uefi
[21:17] <cmatsuoka> ah ok, let me try the -base variant...
[21:17] <cachio> the image you used it was updated by me :)
[21:18] <cmatsuoka> Hmm, I think I tested -base already, I'll test both again to be sure
[21:21] <zyga> cachio: is opensuse updated as well?
[21:21] <zyga> cachio: I ran into some issues but perhaps that was from an earlier run
[21:21] <cmatsuoka> cachio: so this is -base: https://pastebin.ubuntu.com/p/4MrXX4nscd/
[21:22] <cmatsuoka> cachio: and this is the non-base: https://pastebin.ubuntu.com/p/PnXFBpmrZk/
[21:26] <cachio> zyga, opensuse is updated
[21:26] <cachio> 15.1 and tumbleweed
[21:26] <zyga> ta, I'll get back to stuff tomorrow!
[21:27] <cachio> cmatsuoka, nice, in that case I got an error
[21:28] <cachio> zyga, ig #8700 ok for you?
[21:28] <mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
[21:29] <cachio> cmatsuoka, and for you?
[21:29] <zyga> +1
[21:30] <cmatsuoka> cachio: 8700 works with the current spread, for PR-105 we'll need one more change (secureboot: to secure-boot:)
[21:31] <cmatsuoka> but I'm still very intrigued with sergio's error with PR-105
[21:31] <cmatsuoka> cachio: could you check if the binary was built from the correct branch and try the test that failed again?
[21:32] <cachio> cmatsuoka, ok, once spread works using secure-boot we update snapd accordingly
[21:32] <cachio> does it make sense?
[21:32] <cachio> cmatsuoka, checking the error
[21:33] <cmatsuoka> cachio: yes, we must keep things consistent
[21:33] <cachio> cmatsuoka, it is merged now
[21:34] <cachio> so tomorrow we update snapd and zyga deployes the new spread
[21:34] <zyga> do you need master or something else?
[21:34] <cachio> zyga, we have on master the fix
[21:34] <zyga> ah, excellent
[21:35] <zyga> I will deploy that in the morning
[21:35] <cachio> nice
[21:35] <cachio> I'll create the change on snapd to address that, so tomorrow you can approve it once the deploy is done
[21:37] <cachio> cmatsuoka, is it ok to merge 8700 now?
[21:38] <cmatsuoka> cachio: if it's passing the tests it should be fine
[21:39] <cmatsuoka> cachio: I just noticed here that neither fedora-31-64 nor fedora-31-64-base have /sys/firmware/efi
[21:39] <cmatsuoka> cachio: is that expected?
[21:39] <cachio> cmatsuoka, yes
[21:40] <cachio> cmatsuoka, what I did it to configure gce to allow uefi
[21:40] <cmatsuoka> ah, it's allowed but not necessarily used?
[21:40] <cachio> cmatsuoka, yes
[21:40] <cmatsuoka> ah cool, ok
[21:41] <cachio> I need to specify that when I start the instance
[21:41] <cmatsuoka> and why did it failed for you?
[21:41] <cachio> and we are sending the configuration empry
[21:41] <cachio> because the image was not set to use uefi
[21:41] <cachio> so when we sent the configuration empty, then gce rejects the parameters
[21:42] <cmatsuoka> so in PR-105 we're not sending it empty anymore
[21:42] <cachio> even when the arrey is empty
[21:42] <cmatsuoka> we don't send it if secure-boot is disabled
[21:42] <cachio> cmatsuoka, exact
[21:42] <cmatsuoka> so PR-105 should have worked for you
[21:42] <cachio> perhaps I did something wrong
[21:43] <cachio> I'll try again in 1 minutes
[21:44] <mup> PR snapd#8700 closed: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
[21:44] <cmatsuoka> ah ok, no hurry, I'm just intrigued
[21:58] <cachio> cmatsuoka, it works
[21:58] <cmatsuoka> ah nice, thanks :)
[21:58] <cachio> I think I made a mistake to build
[21:59] <cachio> just verified
[21:59] <cachio> zyga, dont use master yet, it is still no merged
[21:59] <cachio> the change on spread