[04:38] <mup> PR snapd#9299 closed: tests/core/uc20-recovery: fix check for at least specific calls to mock-shutdown <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9299>
[05:34] <mborzecki> morning
[05:56] <mvo> good morning mb
[05:56] <mvo> mborzecki: good morning
[06:06] <mborzecki> mvo: hey
[06:06] <mborzecki> mvo: i see the PRs have landed mostly, and claudio updated #9300
[06:06] <mup> PR #9300: boot: build bootchains data for sealing <Run nested> <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9300>
[06:07] <mvo> mborzecki: yeah
[06:08] <mvo> mborzecki: that's great, so just one more to go, right?
[06:10] <mborzecki> hopefully ;)
[06:11] <mvo> haha
[06:11] <mvo> yes
[06:24] <mup> PR snapd#9310 opened: tests: remove "set -e" from function only shell libs <Created by mvo5> <https://github.com/snapcore/snapd/pull/9310>
[06:56] <zyga-kaveri> good morning
[06:56] <zyga-kaveri> starting early although I'm still pretty sleepy
[06:56] <zyga-kaveri> today is a strong coffee day
[06:57] <mvo> good morning zyga-kaveri
[06:57] <mvo> and good morning pstolowski
[06:57] <zyga-kaveri> pstolowski: hey :)
[06:57] <pstolowski> hey, good morning!
[06:57] <zyga-kaveri> pstolowski: are you by any chance using vscode?
[06:58] <pstolowski> zyga-kaveri: yes
[06:58] <zyga-kaveri> pstolowski: I would like to try a code sharing session sometime today
[06:58] <pstolowski> zyga-kaveri: sure
[06:58] <zyga-kaveri> I have a question and I wanted to check how this works compared to screen sharing
[06:58] <zyga-kaveri> but please let me wake up first
[07:02] <zyga-kaveri> pstolowski: try https://prod.liveshare.vsengsaas.visualstudio.com/join?D184D6AF59242DB6AAB93D1D2585F4E2A08E
[07:04] <mborzecki> zyga-kaveri: pstolowski: hey
[07:05] <zyga-kaveri> hey :)
[07:05] <mborzecki> zyga-kaveri: hm interesting, i joined with a browser(?!)
[07:05] <zyga-kaveri> mborzecki: cool
[07:05] <zyga-kaveri> mborzecki: it's pretty neat
[07:05] <zyga-kaveri> did you have to log in?
[07:05] <zyga-kaveri> I've installed the audio sharing extension as well
[07:05] <mborzecki> zyga-kaveri: feels like it's pulling vs into firefox atm
[07:06] <zyga-kaveri> so I could talk to you if you did the same
[07:06] <pstolowski> zyga-kaveri: ok, i think i joined after a few hops
[07:06] <mborzecki> kinda flaky in firefox, let me try chromium instead
[07:08] <zyga-kaveri> mborzecki: try in vscode
[07:08] <zyga-kaveri> one sec guys
[07:08] <pstolowski> zyga-kaveri: i think you session died
[07:08] <pstolowski> *your
[07:08] <zyga-kaveri> yeah one sec :)
[07:09] <mborzecki> yeah. 404
[07:09] <zyga-kaveri> I had to reload to install the extension
[07:09] <zyga-kaveri> mborzecki: I sent you an invite by mail now
[07:10] <zyga-kaveri> https://prod.liveshare.vsengsaas.visualstudio.com/join?8A0945F1FF41E82128AF4EB5930C2A992FB4
[07:10] <zyga-kaveri> or try this
[07:11] <mborzecki> hahah working
[07:12] <zyga-kaveri> can you see the session chat?
[07:19] <mup> PR snapd#9311 opened: nested: add support to telnet to serial port in nested VM <Created by mvo5> <https://github.com/snapcore/snapd/pull/9311>
[07:22] <zyga-kaveri> woot
[07:22] <zyga-kaveri> that was quick and productive, thank you both
[07:22] <pstolowski> zyga-kaveri: yw
[07:23] <zyga-kaveri> how was the quality on your end?
[07:23] <zyga-kaveri> was it better than video share?
[07:23] <pstolowski> zyga-kaveri: you closed the session right? cause it said i left it
[07:23] <pstolowski> zyga-kaveri: yeah i think it's much better, no artifacts
[07:23] <mborzecki> zyga-kaveri: goot that at least it works in the browser
[07:23] <pstolowski> zyga-kaveri: plus the client controls the look/fonts etc
[07:23] <zyga-kaveri> I'm not sure, I sometimes hit a wrong key on my all-blank-keycaps keyboard
[07:24] <zyga-kaveri> could you see my three-tab view
[07:24] <pstolowski> zyga-kaveri: i think it makes sense for longer sessions
[07:24] <zyga-kaveri> I wonder how it adjusts from one screen size to another
[07:25] <zyga-kaveri> pstolowski: it also supports read/write editing
[07:25] <pstolowski> zyga-kaveri: yes i saw this
[07:25] <pstolowski> also terminal can be interactive
[07:26] <pstolowski> zyga-kaveri: i don't think i saw your three-tab view
[07:26] <pstolowski> but i'm unclear what you mean by that
[07:26] <zyga-kaveri> pstolowski: ah that's good, I have a wide monitor and I was worried that would not translate well to other aspect ratios
[07:26] <zyga-kaveri> pstolowski: three columns of text
[07:26] <zyga-kaveri> + terminal at the bottom
[07:27] <zyga-kaveri> mvo: do you need the run nested label?
[07:27] <pstolowski> zyga-kaveri: see the screenshot on mattermost
[07:27] <mvo> zyga-kaveri: yeah, probably. let me do that
[07:29] <zyga-kaveri> pstolowski: I see it
[07:29] <zyga-kaveri> so the editor layout is custom per participant
[07:30] <zyga-kaveri> ok
[07:30] <zyga-kaveri> now that I understand the problem all I need to do is to code the fix
[07:30] <zyga-kaveri> thank you again :)
[07:31] <pstolowski> great
[07:32] <pstolowski> i don't remember the exact reason it's done that way there. maybe we could have fixed auto-connect and make it smarter. but perhaps there was a good reason
[07:32] <pstolowski> i touched this line 2 years ago, amazing...
[07:32] <zyga-kaveri> it seems like an upgrade path for old systems
[07:33] <zyga-kaveri> that upgrade to new snapd and new snapd needs to run their tasks maybe?
[07:34] <pstolowski> zyga-kaveri: ah yes, there is a comment at the top
[07:47] <pedronis> mvo: did you see? we found the (one) issue with nested
[07:49] <mborzecki> pedronis: hi, shall we have a quick chat about 9300?
[07:49] <pedronis> mborzecki: yes
[07:50] <mborzecki> pedronis: ok, in 5/10 maybe?
[07:50] <pedronis> ok
[07:51] <mvo> pedronis: yes, I'm wrapping my tweaks up now right now
[07:52] <mvo> pedronis: good that it's not something deeper and that nested is back to function it seems
[07:52] <pedronis> mvo: yes, but annoying, one of those situation where splitting a PR created its own issues
[07:52] <mvo> pedronis: yeah, it's a combinations of issues it seems, the fact that the nested tests only run sometimes is also contributing to the issue
[07:53] <pedronis> mvo: yes, but otoh our tests are flaky and slow already :/
[07:53] <pedronis> even before nested
[07:53] <zyga-kaveri> mvo: we could add an action that runs nested every 12 hours
[07:53] <mvo> pedronis: yeah
[07:53] <zyga-kaveri> it gets reported in github pretty nicely
[07:53] <zyga-kaveri> (on master)
[07:54] <pedronis> mvo: I mean I had a very frustrating evening, staying around to force merge things
[07:54] <mvo> zyga-kaveri: as long as we make sure that each nested failure is considered high priority I think that's a good one
[07:54] <mvo> pedronis: .(
[07:54] <mvo> pedronis: what tests in particular ?
[07:54] <mvo> pedronis: or all over the place?
[07:54] <zyga-kaveri> mvo: I'll cook something today
[07:54] <pedronis> a bit all over the place
[07:54] <mvo> pedronis: the nested suite *should* be more robust, we only tests very robust stuff there
[07:54] <pedronis> one issue was uc20-recovery, but we have also random failures in ohter places
[07:55] <mvo> pedronis: well, "should"
[07:55] <mvo> pedronis: uc20-recover should now be fixed after merging ian PR
[07:55] <pedronis> like arch seems to fail on cgroup-tracking:root often but not always
[07:55] <mvo> pedronis: but yeah, I feel your pain :(
[07:55] <mvo> pedronis: I saw this one too!
[07:55] <pedronis> and then various interface-* tests failing sometimes
[07:56] <pedronis> and snap run timeouts sometimes but not always on strace
[07:56] <pedronis> I saw it on 18
[07:56] <pedronis> saw all over the place
[07:56] <pedronis> but in places that are required
[07:57] <mvo> :(
[07:58] <mborzecki> pedronis: joining standup
[07:58] <mvo> pedronis: sry! I will watch out for failures and see if I can fix them
[08:19] <pedronis> mborzecki: maybe I confused you:  https://github.com/snapcore/snapd/pull/9300#discussion_r486149013
[08:19] <mup> PR #9300: boot: build bootchains data for sealing <Run nested> <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9300>
[08:20] <pedronis> mborzecki: the Kernel BootFile should have full paths, it's the Kernel fields that should be ok with just names
[08:21] <pedronis> (it's not super deep, it's mostly for consistency)
[08:31]  * zyga-x240 caved and ran from the office upstairs
[08:31] <zyga-x240> it's so much warmer in the sun
[08:31] <zyga-x240> I'll go there later
[08:32] <zyga-x240> PT is at home today so I can get to the bottom of remaining tests :)
[08:44] <mup> PR snapd#9312 opened: o/snapstate: disk space check with snap update <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9312>
[08:57] <pedronis> mvo: I reviewed #9021, it needs a new 2nd review
[08:57] <mup> PR #9021: snap: implement new `snap reboot` command <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9021>
[08:59] <mvo> pedronis: \o/ thank you
[08:59] <mvo> pstolowski: are you up for a second review of 9021?
[09:00] <mvo> pedronis: I assume 9300 is not quite ready for a review yet(?)
[09:00] <pstolowski> mvo: sure. btw is #9284 now critical to unbreak something in nested?
[09:00] <mup> PR #9284: tests: some fixes and improvements for nested execution <Run nested> <⚠ Critical> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9284>
[09:00] <pedronis> mvo: mborzecki is working on it
[09:00] <mvo> pstolowski: I see failures with nested on master right now
[09:01] <mvo> pstolowski: and with 9284 it seems no failures anymore
[09:02] <mvo> I will also make the nested runs required, so that if they are activated we can only merge if they are green
[09:02] <pstolowski> +1
[09:02] <pstolowski> ok, i'll conclude my review of 9284 then
[09:05] <mup> PR snapd#9313 opened: boot: do not reorder boot assets when generating predictable boot chains <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9313>
[09:05] <mborzecki> pedronis: mvo: https://github.com/snapcore/snapd/pull/9313 a prerequisite
[09:05] <mup> PR #9313: boot: do not reorder boot assets when generating predictable boot chains <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9313>
[09:05] <mborzecki> skipped spread, so that we can land it quickly
[09:06] <mvo> mborzecki: thanks, checking
[09:09] <zyga-x240> I switched to a hybrid
[09:09] <zyga-x240> with tasks for the things where undo is easier as tasks (export, unexport)
[09:09] <pedronis> mborzecki: I am bit confused by tests there
[09:09] <zyga-x240> and a pointer helper for the link
[09:09] <zyga-x240> to avoid the complexity of link snap relationship
[09:09] <zyga-x240> making the changes now but I think this is best of both worlds
[09:12] <pedronis> mborzecki: I think the tests needs a cleanup, now that the assets are not ordered in themselves we don't need so many weird cases in them
[09:17] <pedronis> if I'm making sense
[09:45] <mborzecki> pedronis: i've updated #9300
[09:45] <mup> PR #9300: boot: build bootchains data for sealing <Run nested> <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9300>
[10:20] <pedronis> mborzecki: did you forget to push to 9313 ?
[10:23] <mborzecki> pedronis: #9313 is updated now too
[10:23] <mup> PR #9313: boot: do not reorder boot assets when generating predictable boot chains <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9313>
[10:42] <mvo> mborzecki, pedronis fwiw, I just merged 9284 and nested runs are green, I also made green nested runs a requirement for merging PRs (anything without the run-nested label gets an automatic green here)
[10:44] <mvo> mborzecki: thanks for the update on 9313 - fwiw, looks all right to me
[10:45] <mup> PR snapd#9284 closed: tests: some fixes and improvements for nested execution <Run nested> <⚠ Critical> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9284>
[11:00] <mup> PR snapd#9314 opened: o/snapstate: disk space check on UpdateMany <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9314>
[11:01] <mup> Issue core20#32 closed: The machine-id file should be writable <question> <Created by zyga> <Closed by xnox> <https://github.com/snapcore/core20/issues/32>
[11:01] <mup> Issue core20#72 closed: move docker user/group to extrausers <Blocked> <Created by anonymouse64> <Closed by xnox> <https://github.com/snapcore/core20/issues/72>
[11:01] <mup> PR core20#82 closed: [RFC] hooks: mv docker user/group definition to extrausers <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/core20/pull/82>
[11:01] <mup> PR core20#83 closed: static/writable-paths: make /etc/default/crda writable <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/core20/pull/83>
[11:01] <zyga-x240> pstolowski: do we need a check on remove?
[11:01] <zyga-x240> currently remove can fail if we have no space for the snapshot
[11:02] <pstolowski> zyga-x240: that's done and landed already
[11:02] <pstolowski> zyga: unless you found a bug
[11:03] <pstolowski> it's behind feature flag too
[11:03] <pedronis> mborzecki: thanks for the changes in 9300, there are probably some tweaks that can make it easier to reuse the bits for reseal
[11:05] <pstolowski> zyga-x240: correction, single snap remove does that already in master; remove-many is about to land
[11:05] <zyga-x240> pstolowski: ah, no I just realized this should be so while reading the other PR
[11:05] <zyga-x240> pstolowski: that's great
[11:05] <pstolowski> ok
[11:05] <pstolowski> zyga-x240: yeah i think all major ops are covered now
[11:27] <pedronis> mvo: mborzecki: I pushed some small tweaks/simplifcations to 9313
[11:28] <mborzecki> pedronis: thanks!
[11:29] <pedronis> I will look at 9300 again in a bit
[11:29] <mvo> pedronis: looking
[11:34] <mborzecki> pedronis: do you know whether #9032 is getting replaced by something else?
[11:34] <mup> PR #9032: secboot: add call to reseal an existing key <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9032>
[11:35] <pedronis> it's not afaik, it's used by #9287 which is the one to tweaks after we are happy with 9300
[11:35] <mup> PR #9287: secboot: reseal key to parameters specified in modeenv <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9287>
[11:40] <mborzecki> hmm wonder whether claudio has some unpushed merge with master in 9287
[11:47]  * pstolowski lunch
[11:49] <pedronis> mborzecki: anyway, I reviewed 9300, there are things to improve there
[11:50] <mborzecki> let me see
[12:03] <mborzecki> pedronis: tweaked buildRecoveryBootChain to actually takea list of systems, which in the initial install case will be just the current recovery system, or in a general case, the recovery systems we have
[12:14]  * zyga-x240 -> lunch
[12:21] <mborzecki> pedronis: ok, another push to #9300
[12:21] <mup> PR #9300: boot: build bootchains data for sealing <Run nested> <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9300>
[12:22] <mborzecki> cmatsuoka: hi, we've hijacked a bit your PRs :) please take a look at 9300 as well, hope i've not messed up something
[12:22] <cmatsuoka> mborzecki: thanks, I'm glad you're working on it
[12:24]  * zyga-x240 also errand
[12:24] <zyga-x240> mvo: my update in case I cannot connect for standup
[12:25] <zyga-x240> mvo: synced with pawel and maciek in the morning to debug issue from yesterday, guys solved it instantly!
[12:25] <pedronis> mborzecki: thanks
[12:25] <zyga-x240> mvo: split tasks so that export/unexport just handles files and not the "current" symlink
[12:25] <zyga-x240> mvo: used a hack to update current inside doLinkSnap, avoiding complex test failures related to task changes after link-snap
[12:26] <zyga-x240> mvo: tweaked description of the exported content so that undo path has no custom code left, just loads data from task state and calls the regular remove method
[12:27] <zyga-x240> mvo: I will tweak some tests and open a new PR today
[12:27] <zyga-x240> now everything should pass okay
[12:27]  * zyga-x240 runs to do the errand
[12:28] <mborzecki> pedronis: cmatsuoka: should we sync before the standup?
[12:32] <cmatsuoka> mborzecki: I can, SU room?
[12:39] <pedronis> cmatsuoka: mborzecki: I'm there
[12:40] <mborzecki> cmatsuoka: we're there
[12:55] <mup> PR snapd#9313 closed: boot: do not reorder boot assets when generating predictable boot chains and other small tweaks <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9313>
[13:01] <mup> PR snapd#9315 opened: tests: fix snap-routime-portal-info test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9315>
[13:35] <cachio> ijohnson, #9208 has conflicts
[13:35] <mup> PR #9208: tests/nested/core20/kernel-failover: add test for failed refresh of uc20 kernel <Run nested> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9208>
[13:38] <ijohnson> cachio: ack I see, I will resolve those now
[13:47] <cachio> ijohnson, nice, thanks
[14:06] <zyga-kaveri> re
[14:16] <mup> PR snapd#9021 closed: snap: implement new `snap reboot` command <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9021>
[14:16] <mup> PR snapd#9316 opened: tests: use full path to test-snapd-refresh.version binary <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9316>
[14:21] <mup> PR snapd#9317 opened: [RFC] devicestate: keep log from install-mode on installed system <Created by mvo5> <https://github.com/snapcore/snapd/pull/9317>
[14:29] <pedronis> mborzecki: cmatsuoka: 9300 seems to have passed all relevant tests, still needs the 2nd review
[14:34] <mborzecki> yay
[14:35] <mup> PR snapcraft#3278 closed: cli: client side check for setting default tracks <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3278>
[14:36] <mborzecki> pedronis: cmatsuoka: since it's green, and if 2nd review comments on cosmetics/messages, i think we should land it and do a simple followup with the tweka
[14:40] <mborzecki> s/tweka/tweaks/ ofc
[15:00] <mvo> pedronis, mborzecki, cmatsuoka I have one more meeting, then I should be able to have a look
[15:00] <mvo> (unless someone else beats me to it :)
[15:06] <cmatsuoka> mvo: thanks, it would be great if you could have a look
[15:11]  * cmatsuoka will return after lunch
[15:14] <ijohnson> one question on 9300
[15:14] <ijohnson> (left in the PR that is)
[15:16] <pedronis> ijohnson: I answered
[15:16]  * cachio lunch
[15:37] <ijohnson> pedronis: I +1d 9300, not sure if you still want someone else like mvo to +1 it, I have not kept up to date on all the resealing pr's this week
[15:40] <pedronis> at this point I think we should land it and cmatsuoka can work on the small follow ups, and the next ones. OTOH if mvo has time to post-review it that's also welcome
[15:41] <mvo> sure, let's land it
[15:46] <mup> PR snapd#9312 closed: o/snapstate: disk space check with snap update <Disk space awareness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9312>
[15:46] <mup> PR snapd#9314 closed: o/snapstate: disk space check on UpdateMany <Disk space awareness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9314>
[15:51] <mup> PR snapd#9300 closed: boot: build bootchains data for sealing <Run nested> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9300>
[15:51] <mup> PR snapd#9310 closed: tests: remove "set -e" from function only shell libs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9310>
[16:01] <mup> PR snapd#9294 closed: o/snapstate: check available disk space in RemoveMany <Disk space awareness> <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9294>
[16:06] <mup> PR snapd#9318 opened: .github/workflows/test.yaml: also run 20.04 nested tests with UC20 label <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9318>
[16:07] <mvo> pedronis: I get dinner now, please let me know if I can do anything after dinner, I will read backlog
[16:16] <pedronis> mvo: I think we need more code from cmatsuoka before anything else
[16:18] <mvo> pedronis: ok, thanks, I will just read backlog then :)
[16:24] <pedronis> cmatsuoka: I don't know if you noticed yet, but 9032 itself needs update because of the change to the params
[16:25] <pedronis> to support trees
[16:25] <cmatsuoka> pedronis: I'll check
[16:25] <pedronis> it's fascinating, it doesn't conflict, but then it gets unhappy about types
[16:26] <cmatsuoka> pedronis: ah yes, that's true, I'll open a PR with the small fixes for 9300 and fix 9032
[16:26]  * mvo hugs cmatsuoka and pedronis 
[16:30] <zyga-mbp> I think pedronis deserves a day off, at least, for recent crunch
[16:30] <zyga-mbp> he seems to work in all the timezones at once
[16:31] <ijohnson> agreed
[16:31] <cmatsuoka> zyga-mbp: and all the complex subsystems
[16:31] <mup> PR snapd#9319 opened: seal: error message and function name adjusts <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9319>
[16:32] <zyga-mbp> that was a given
[16:33] <zyga-mbp> today is a bit more patchy, with errands and now remote school meeting
[16:33] <zyga-mbp> gosh if we ever complain about hangouts or anything like that
[16:33] <zyga-mbp> try putting 30 parents with poor tech know-how
[16:33] <zyga-mbp> and have them achieve anything
[16:33] <cmatsuoka> been there
[16:34] <ijohnson> #9208 is ready for a review, I de-conflicted it now
[16:34] <mup> PR #9208: tests/nested/core20/kernel-failover: add test for failed refresh of uc20 kernel <Run nested> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9208>
[16:34] <ijohnson> cachio: ^
[16:34] <cachio> ijohnson, tx
[16:41] <pedronis> #9319 should have had skip spread
[16:41] <mup> PR #9319: boot: in seal.go adjust error message and function names <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9319>
[16:50] <pedronis> ijohnson: ^ should be quick to review, and has the comment you asked now
[16:50]  * pedronis dinner
[16:50] <ijohnson> ok
[17:26] <pedronis> now GH is sending (resending?) old emails ??
[17:34] <cmatsuoka> hmm I didn't receive anything strange from GH recently
[17:35] <zyga-mbp> neither did I
[17:37] <mup> PR snapd#9320 opened: boot: group SealKeyModelParams by model <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9320>
[17:40] <cmatsuoka> afk for a short while, /me completely forgot to pay some bills yesterday
[17:42] <cachio> mvo, I see that is really weird
[17:42] <cachio> https://paste.ubuntu.com/p/3YQrFW6F22/
[17:43] <cachio> mvo, starting stopping many times until it reaches the limit
[18:02] <mup> PR snapd#9319 closed: boot: in seal.go adjust error message and function names <Skip spread> <UC20> <Created by cmatsuoka> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9319>
[18:08] <pedronis> cmatsuoka: I reviewed 9032, my remark can probably be addressed in a follow up
[18:09] <cmatsuoka> pedronis: thanks, I'll check
[18:22] <pedronis> cmatsuoka: are you assuming we land #9320 (I didn't think it was urgent) ?
[18:22] <mup> PR #9320: boot: group SealKeyModelParams by model <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9320>
[18:22] <mup> PR snapd#9321 opened: cmd/snap/model: specify grade in the model command output <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9321>
[18:22] <cmatsuoka> pedronis: not urgent, I prepared it because it looked easy enough
[18:23] <cmatsuoka> pedronis: now working on the new reseal call
[19:19] <mup> PR snapd#9032 closed: secboot: add call to reseal an existing key <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9032>
[19:38]  * zyga-mbp works on a few more tests
[19:44] <cachio> ijohnson, hey
[19:44] <ijohnson> Hi
[19:45] <cachio> I am checking basic20 test which fails
[19:45] <cachio> and see this
[19:45] <cachio> MATCH '# Snapd-Boot-Config-Edition: [0-9]+' < /run/mnt/ubuntu-seed/EFI/ubuntu/grub.cfg
[19:45] <cachio> the check fails
[19:46] <cachio> ijohnson, but, it metches
[19:46] <cachio> MATCH '# Snapd-Boot-Config-Edition: [0-9]+' < /boot/grub/grub.cfg
[19:48] <ijohnson> cachio those are two different files
[19:48] <ijohnson> One is /boot/grub/grub.cfg and the other is /run/mnt/ubuntu-seed/EFI/ubuntu/grub.cfg
[19:49] <ijohnson> cachio which test is this
[19:50] <cachio> core/basic20
[19:50] <cachio> the check for /run/mnt/ubuntu-seed/EFI/ubuntu/grub.cfg is failing
[19:50] <cachio> ijohnson, https://paste.ubuntu.com/p/25wQdj2qFW/
[19:51] <ijohnson> cachio so this test will only work if the image that was created was flashed with a new enough snapd used by ubuntu-image
[19:52] <ijohnson> cachio how was that image built?
[19:52] <cachio> ijohnson, I build that today, using beta
[19:52] <cachio> channel
[19:53] <cachio> ijohnson, should I update snapd?
[19:53] <ijohnson> cachio you need to point ubuntu-image to snapd from your system with an env var
[19:54] <ijohnson> cachio set UBUNTU_IMAGE_SNAP_CMD=$(which snap)
[19:54] <pedronis> cmatsuoka: how it's going? any problems?
[19:54] <ijohnson> Then call ubuntu-image
[19:55] <cachio> ijohnson, ahh, nice, I'll retry with that
[19:55] <cmatsuoka> pedronis: I did reseal, now I'm running a quick test before opening the PR
[19:55] <cachio> ijohnson, thanks
[19:56] <ijohnson> cachio just to be on the safe side try with snapd from edge or beta on your host too
[19:57] <cmatsuoka> and... it failed! for some reason
[19:57]  * cmatsuoka investigates
[20:00] <zyga-mbp> far fewer failures
[20:00] <zyga-mbp> but some bugs still remain,
[20:00] <zyga-mbp> I think snapstate.Info description is misleading
[20:00] <zyga-mbp> it doesn't work for snaps that are not in state
[20:02] <cmatsuoka> I think i just can't do what I'm trying to do (resealing just after sealing)
[20:03] <zyga-mbp> cmatsuoka: do you think the TPM does not support that?
[20:03] <cmatsuoka> zyga-mbp: I think we lock the tpm after we seal because reseal can't even open it
[20:04] <mup> PR snapd#9322 opened: boot: add call to reseal an existing key <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9322>
[20:05] <cmatsuoka> also closing the previous PR that did the same thing
[20:08] <zyga-mbp> brb, need to restart wifi
[20:09] <mup> PR snapd#9287 closed: secboot: reseal key to parameters specified in modeenv <UC20> <⛔ Blocked> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/9287>
[20:11] <cachio> ijohnson, I also see this change https://paste.ubuntu.com/p/Vft4S47VP4/
[20:11] <cachio> which fails
[20:11] <cachio> it should be fixed whith the new snapd?
[20:12] <ijohnson> cachio: no that test needs to be updated for external systems
[20:12] <cachio> or I need to update the test
[20:12] <ijohnson> cachio: that test depends on the image used
[20:12] <cachio> ijohnson, ok
[20:12] <cachio> yes, makes sense
[20:12] <cachio> thanks
[20:14] <zyga_> 2K insertions
[20:14] <zyga_> I need about 500 more to finish
[20:14] <mup> PR snapd#9248 closed: exportstate: add scaffolding for the export manager <Needs Samuele review> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/9248>
[20:14] <mup> PR snapd#9323 opened: snap/naming: upgrade TODO to TODO:UC20 <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/9323>
[20:16] <cachio> ijohnson, do you know where I can get the info to check snap recovery?
[20:16] <ijohnson> cachio: the info comes from the model assertion and the recovery system label
[20:19] <cachio> ijohnson, and do we store that in a file?
[20:19] <ijohnson> cachio: the 2nd column in the output of `snap recovery` will match the output of the brand from `snap model`
[20:19] <ijohnson> cachio: the 3rd column will match the output of `snap model | grep model`
[20:19] <cachio> ijohnson, nice
[20:20] <cachio> I'll get the info from there
[20:20] <cachio> thanks
[20:26] <cmatsuoka> zyga-kaveri: ha, the tpm device was left open after sealing
[20:28] <cmatsuoka> and now it works
[20:46] <zyga> time for spread
[20:46] <zyga> I have one unit test failure but debugging some of the state engine failures is a bit mysterious
[20:46] <zyga> but that's okay, let's see what spread shows
[20:47]  * cachio afk
[20:54] <mup> PR core18#169 opened: snapcraft.yaml: use build-base for modern snapcraft, and use lxd in travis to build the snap <Created by anonymouse64> <https://github.com/snapcore/core18/pull/169>
[21:04] <mup> PR snapd#9323 closed: snap/naming: upgrade TODO to TODO:UC20 <Simple 😃> <Skip spread> <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9323>
[21:04] <mup> PR snapd#9324 opened: secboot: adjust parameters to buildPCRProtectionProfile <Simple 😃> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9324>
[21:05] <zyga> thanks!
[21:05] <ijohnson> np, thanks for fixing it :-)
[21:13] <zyga> ah,
[21:13] <zyga> I know what to do next
[21:24] <mup> PR snapd#9325 opened: strutil: add SortedListsUniqueMerge <Created by pedronis> <https://github.com/snapcore/snapd/pull/9325>
[21:30] <zyga> ok, no unit test failures,
[21:30] <zyga> a few XXXes
[21:30] <zyga> running spread again
[21:30] <zyga> should be all green now
[21:34] <pedronis> ijohnson: cmatsuoka: I worked a bit more on #9320, it has more tests for some of things in the previous PRs, it needs #9325
[21:34] <mup> PR #9320: boot: group SealKeyModelParams by model, improve testing <Run nested> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9320>
[21:34] <mup> PR #9325: strutil: add SortedListsUniqueMerge <Created by pedronis> <https://github.com/snapcore/snapd/pull/9325>
[21:34] <cmatsuoka> pedronis: ack, checking
[21:35] <zyga> pedronis what does sh stand for?
[21:35] <zyga> size?
[21:35] <pedronis> where ?
[21:35] <zyga> line 79
[21:35] <zyga> https://github.com/snapcore/snapd/pull/9325/files#diff-342c12787e3c9ff0147933bb2fe7aa7fR79
[21:35] <mup> PR #9325: strutil: add SortedListsUniqueMerge <Created by pedronis> <https://github.com/snapcore/snapd/pull/9325>
[21:36] <pedronis> sz
[21:36] <pedronis> yes, size
[21:37]  * zyga reads sz as sh due to the pronounciation in his language which sometimes makes things confusing
[21:48] <zyga> pedronis why the else at the end
[21:48] <zyga> cannot we drain both lists?
[21:48] <zyga> oh
[21:48] <zyga> only one would be
[21:48] <zyga> right?
[21:51] <zyga> +1
[21:53] <zyga> I'll wait for tests to finish
[21:53] <zyga> and run one more overnight
[21:53] <zyga> I'm mainly interested in seeing core tests
[21:53] <zyga> tomorrow the last stretch to complete this
[21:54] <pedronis> zyga: yes, if they are both true we would still be in the previous loop
[21:54] <zyga> right
[21:54] <zyga> nice code :)
[22:02] <cmatsuoka> afk, phone call
[22:02] <pedronis> ijohnson: I commented on your note in the standup, the difference between snap recovery and snap model is expected
[22:03] <pedronis> we have the same difference in other places (is the difference between list vs info-like output)
[22:04] <pedronis> cmatsuoka: I missed you had opened #9322
[22:04] <mup> PR #9322: boot: add call to reseal an existing key <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9322>
[22:05] <mup> PR snapd#9326 opened: tests: fix for basic20 test running on external backend and rpi <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9326>
[22:05] <cmatsuoka> pedronis: and now I noticed it failed the macos test, probably something related to nosecboot
[22:07] <pedronis> cmatsuoka: looks good looking quickly, but one comment, I will look closer in the morning
[22:07] <cmatsuoka> pedronis: ok, thanks, I'll see the macos and the other issue you raised in a moment, I need to make a few phone calls first
[22:08] <pedronis> thx, calling it a day
[22:10] <zyga> good night pedronis