[06:24] <mborzecki> morning
[06:26] <zyga> good morning
[06:26] <zyga> Lucy is just waking up so I may be AFK any time
[07:02] <pstolowski> morning
[07:04] <mborzecki> pstolowski: hey
[07:05] <zyga> good morning pstolowski
[07:25] <zyga> I could use reviews for https://github.com/snapcore/snapd/pull/9446
[07:25] <zyga> it's still Monday
[07:25] <zyga> we can still merge this :)
[07:32] <zyga> I'd love some advice on how to make progress
[08:22] <pedronis> mborzecki: hi, should #9247 be unblocked, is it ready for another review?
[08:22] <zyga> re
[08:22] <zyga> hello pedronis
[08:23] <mborzecki> pedronis: hey, yes, removed the blocked label just now
[08:23] <pedronis> ok
[08:29] <pedronis> pstolowski: mvo: made some some small comments in 9455, maybe pstolowski could address those?
[08:30] <pstolowski> pedronis: sure i can. i'm addressing comments to #9036 atm
[09:12] <pedronis> https://github.com/snapcore/snapd/pull/9454 can be reviewed
[09:28] <mborzecki> pedronis: reviewed
[09:50] <pedronis> thx
[10:16] <zyga> brb
[10:31] <zyga> re
[10:39]  * zyga goes on the road
[11:07]  * zyga works on https://github.com/snapcore/snapd/pull/8573 but now needs to carry is imac for servicing
[11:07] <zyga> o/
[11:32] <pedronis> mborzecki: I revewied #9427 again
[11:36] <mborzecki> pedronis: thanks
[11:36] <mborzecki> pedronis: do you think we should enforce that save comes before data, so that data can be expanded on install?
[11:41] <pedronis> mborzecki: I need a bit more context, I don't remember the details of that
[11:43] <mborzecki> pedronis: right now we will expand ubuntu-data until the end of the disk iff it's the last partition, so the question really is whether we should check that ubuntu-data comes last in gadget.yaml
[11:43] <mborzecki> i don't see a check for this in gadget.go
[11:44] <mborzecki> or maybe it's too native of a check, there can be some weird platforms out there after all
[12:01] <pedronis> mborzecki: it's seem fine to me, if you want auto-expansion put data last, if you don't care or have other reasons don't
[12:01] <mborzecki> pedronis: ack
[12:02] <mborzecki> pedronis: pushed the tweaks to https://github.com/snapcore/snapd/pull/9443 i'll chase cmatsuoka to take a look
[12:06] <pedronis> mborzecki: thanks, I readded to my queue
[12:27] <cachio> ijohnson, hi
[12:28] <cachio> ijohnson, i saw uc20-recovery could be failing because a real problem
[12:29] <cachio> ijohnson,  do you know anything else
[12:29] <cachio> it is the only blocker for snapd snap
[12:37] <zyga> re
[12:40] <ijohnson> hi cachio no, not yet I am looking again this morning
[12:41] <cachio> ijohnson, nice, thanks
[12:42] <zyga> hey guys
[12:42] <ijohnson> hi zyga
[12:42] <ijohnson> thanks for the review I will respond in a bit
[12:42] <ijohnson> zyga: how goes the sprint ?
[12:43] <zyga> ijohnson I'm not attending actually
[12:43] <zyga> just select meetings
[12:43] <ijohnson> ah I see
[12:43] <ijohnson> how are things looking on the refresh app awareness front ?
[12:43] <zyga> though I did get an invite for 9:30 pm so I guess that's enough ;-)
[12:43] <ijohnson> haha
[12:43] <zyga> ijohnson I'm working on the inhibition lock branch I got feedback from Samuele on, iterating on specific bits, some more involved than others
[12:44] <zyga> the front-end with notifications is yet to get a +1/-1 IIRC
[12:44] <zyga> but I didn't check for a few hours
[12:44] <ijohnson> should I give a look at the front-end pr you opened last thursday ?
[12:44] <ijohnson> I started a review but didn't get very far unfortunately
[12:44] <zyga> yeah, that would be great
[12:44]  * zyga looks
[12:44] <ijohnson> ok, sounds good
[12:44] <zyga> https://github.com/snapcore/snapd/pull/9446
[12:44] <zyga> thank you!
[12:45] <zyga> I had a look at the race PR and though it looked good I didn't approve it as I was not feeling very well in the morning
[12:45] <zyga> and reading some of the logic made me wonder if that would be a fair review
[12:45] <ijohnson> yes I saw your review thanks for the feedback
[12:45] <ijohnson> that is the general direction we are headed
[12:45] <zyga> I will return to it
[12:45] <zyga> btw, do we have a standup today?
[12:45] <ijohnson> I don't think we can get there right now but I agree that would make for the best user experience
[12:45] <zyga> or are all stand-ups cancelled this week?
[12:45] <ijohnson> zyga: I assume we have SU today?
[12:46] <zyga> I don't see any in my calendar
[12:46] <ijohnson> huh it does appear to not be there
[12:49] <pedronis> zyga: ijohnson: it probably will only make sense to refine or overtake the console-conf experience in the full onboarding context
[12:49] <ijohnson> pedronis: yes agreed
[12:50] <ijohnson> also hi :-)
[12:50] <ijohnson> I saw your feedback on the do* pr, I think it looks okay, I was a bit naive and hoped that test wouldn't be so silly on github actions seems I was wrong
[12:51] <zyga> pedronis that's a good point
[13:59] <mborzecki> pedronis: https://github.com/snapcore/snapd/pull/9427 has been updated too
[14:14] <ijohnson> cachio: when you run the uc20-recovery tests for amd64, are you using master version of the test? and what revisions of snaps are you using to build the image ?
[14:14] <ijohnson> cachio: I thought there might be an issue but now I've run that test locally on amd64 vm's twice in a row without issue
[14:15] <cachio> ijohnson, I use branch 2.47
[14:15] <ijohnson> cachio: ok I will try with the release/2.47 branch
[14:15] <cachio> snapd 9607
[14:15] <cachio> core20 849
[14:15] <cachio> pc 108
[14:15] <cachio> pc-kernel 612
[14:16] <cachio> this is the manifest ofthe image I used
[14:16] <ijohnson> cachio: ok thanks those are all the same as my image
[14:16] <ijohnson> cachio: did you set them to be tracking beta?
[14:16] <ijohnson> which model assertion and ubuntu-image arguments did you use?
[14:17] <cachio> beta dangerous
[14:17] <ijohnson> cachio: ack I was using edge dangerous and resetting the channel with -c option to ubuntu-image
[14:17] <cachio> sudo ubuntu-image '--image-size 8G' '' -c beta -O ./output/pc-amd64-20-beta ./models/pc-amd64-20.model
[14:17] <ijohnson> let me try with that model assertino too
[14:18] <cachio> ijohnson, sory
[14:18] <cachio> it ishttps://paste.ubuntu.com/p/pGZFPSv35x/
[14:18] <cachio> it is edge
[14:18] <cachio> dangerous
[14:18] <cachio> switched to beta
[14:18] <ijohnson> cachio: ah ok so same thing I was doing
[14:19] <cachio> yes
[14:19] <ijohnson> cachio: but let me try running with the release/2.47 branch perhaps there's something there that's up
[14:19] <cachio> ijohnson, sure
[14:27] <ijohnson> cachio: it passed again for me on amd64 with git branch of 2.47 and the same snaps and model assertion, etc.
[14:27] <ijohnson> cachio: should I try on rpi now?
[14:28] <cachio> ijohnson, yes
[14:28] <cachio> failed here
[14:28] <ijohnson> cachio: but to be clear you see failures on amd64 right ?
[14:28] <cachio> how did you start the vm?
[14:28] <ijohnson> cachio: this
[14:29] <ijohnson> https://www.irccloud.com/pastebin/EH9HAiPk/
[14:29] <ijohnson> cachio: what vm arguments do you boot with ?
[14:29] <cachio> ijohnson, yes, the same
[14:29] <cachio> ok, please try with rpi
[14:29] <ijohnson> hmm
[14:29] <ijohnson> alright I will try with arm64 on my rpi4
[14:40] <cachio> ijohnson, I know why it failed here for amd64
[14:40] <cachio> I used /usr/share/OVMF/OVMF_CODE.fd
[14:40] <ijohnson> cachio: why would that make a difference ?
[14:40] <cachio> I got the comand from the history instead of my docs
[14:40] <ijohnson> cachio: oh did you not enable secure boot ?
[14:40] <cachio> ijohnson, at least it is different of what you have
[14:40] <ijohnson> still it should work even without secure boot
[14:41] <cachio> ijohnson, right
[14:41] <cachio> no secure boot at all
[14:41] <ijohnson> interesting though, while my pi is running let me try without secure boot
[14:41] <cachio> ijohnson, thanks
[14:41] <ijohnson> secure boot shouldn't be necessary to run, it will just not use/enable any encryption
[14:41] <ijohnson> but that could have been broken
[15:09] <cachio> ijohnson, could you reproduce it?
[15:09] <ijohnson> cachio: it's running right now, both the pi version and the amd64 with your normal OVMF_CODE.fd kvm args
[15:10] <ijohnson> well let you know when it's done running
[15:11] <cachio> ijohnson, tx
[15:12] <ijohnson> cachio: I think I see the issue with the pi, do you use wlan for your pi connection ?
[15:12] <ijohnson> pi network connection that is
[15:13] <ijohnson> although perhaps this problem would happen w/ normal ethernet too
[15:15] <cachio> ethernet
[15:15] <cachio> I use
[15:15] <cachio> and in the lab too I think
[15:16] <ijohnson> ok, well for the pi I think the issue is that when it gets rebooted into recover mode I see a different IP address for the device
[15:16] <ijohnson> I think it may not be deterministic, so sometimes it comes back with the same IP and sometimes it doesn't
[15:17] <cachio> ijohnson, weird
[15:18] <cachio> but could be the raeson
[15:18] <ijohnson> cachio: let me try with ethernet to see if this happens, but I see it with wlan consistently and IMHO this is a bug
[15:18] <ijohnson> this would cause spread to not be able to ssh back after the device reboots to recover mode
[15:18] <cachio> yes
[15:33]  * cachio lunch
[15:58] <ijohnson> cachio: even with a fresh uc20 amd64 vm w/ secure boot disable I still can't reproduce a failure of uc20-recovery
[15:58] <ijohnson> cachio: can you share your full vm arguments you use to boot up the amd64 vm ?
[16:23] <ijohnson> cachio: also releavnt is that I am using ovmf from focal, I even reinstalled that package to be sure I'm not using an accidentally modified version of OVMF_VARS.ms.fd
[16:54] <cachio> ijohnson, sudo qemu-system-x86_64 -smp 2 -m 2048 -snapshot -net nic,model=virtio -net user,hostfwd=tcp::8022-:22 -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive  file=output/pc-amd64-20-beta/pc.img,cache=none,format=raw,id=disk1,if=none -device virtio-blk-pci,drive=disk1,bootindex=1 -machine accel=kvm
[16:54] <cachio> this is what I used for that test
[17:20] <ijohnson> cachio: thanks I'll try that
[19:46] <cachio> ijohnson, so, the change in the ip is the problem? or you could found something else?
[19:46] <ijohnson> cachio: no I haven't found anything else, I think it's just the ip address problem
[19:46] <ijohnson> cachio: I filed upstream issues for core20 about this, so I think you can ignore safely the rpi failures
[19:47] <cachio> ijohnson, ok, thanks a lot
[19:47] <ijohnson> I will try your kvm cmdline again to see if I can reproduce the amd64 failure at all
[19:47] <ijohnson> but with all of my efforts I couldn't reproduce today
[19:48] <cmatsuoka> ijohnson: have you worked or are you working on issues related to fontconfig? if not, do you remember who was playing with that?
[19:48] <ijohnson> cmatsuoka: I looked at it a bit a while ago
[19:49] <ijohnson> cmatsuoka: why did you find another bug there
[19:49] <cmatsuoka> ijohnson: no, I'm re-triaging bugs that are triaged/confirmed but have not importance set, and if possible I'm also assigning them
[19:50] <ijohnson> I see, well I'm not currently working on fontconfig stuff, perhaps mborzecki can comment if it's a cross distro thing
[19:50] <cmatsuoka> ijohnson: https://bugs.launchpad.net/snapd/+bug/1863613
[19:50] <cmatsuoka> ijohnson: ah ok, I'll check with maciek tomorrow
[19:50] <cmatsuoka> and yes, it seems to be cross distro