[06:24] morning [06:26] good morning [06:26] Lucy is just waking up so I may be AFK any time [07:02] morning [07:04] pstolowski: hey [07:05] good morning pstolowski [07:25] I could use reviews for https://github.com/snapcore/snapd/pull/9446 [07:25] it's still Monday [07:25] we can still merge this :) [07:32] I'd love some advice on how to make progress [08:22] mborzecki: hi, should #9247 be unblocked, is it ready for another review? [08:22] re [08:22] hello pedronis [08:23] pedronis: hey, yes, removed the blocked label just now [08:23] ok [08:29] pstolowski: mvo: made some some small comments in 9455, maybe pstolowski could address those? [08:30] pedronis: sure i can. i'm addressing comments to #9036 atm [09:12] https://github.com/snapcore/snapd/pull/9454 can be reviewed [09:28] pedronis: reviewed [09:50] thx [10:16] brb [10:31] 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] o/ [11:32] mborzecki: I revewied #9427 again [11:36] pedronis: thanks [11:36] pedronis: do you think we should enforce that save comes before data, so that data can be expanded on install? [11:41] mborzecki: I need a bit more context, I don't remember the details of that [11:43] 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] i don't see a check for this in gadget.go [11:44] or maybe it's too native of a check, there can be some weird platforms out there after all [12:01] 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] pedronis: ack [12:02] pedronis: pushed the tweaks to https://github.com/snapcore/snapd/pull/9443 i'll chase cmatsuoka to take a look [12:06] mborzecki: thanks, I readded to my queue [12:27] ijohnson, hi [12:28] ijohnson, i saw uc20-recovery could be failing because a real problem [12:29] ijohnson, do you know anything else [12:29] it is the only blocker for snapd snap [12:37] re [12:40] hi cachio no, not yet I am looking again this morning [12:41] ijohnson, nice, thanks [12:42] hey guys [12:42] hi zyga [12:42] thanks for the review I will respond in a bit [12:42] zyga: how goes the sprint ? [12:43] ijohnson I'm not attending actually [12:43] just select meetings [12:43] ah I see [12:43] how are things looking on the refresh app awareness front ? [12:43] though I did get an invite for 9:30 pm so I guess that's enough ;-) [12:43] haha [12:43] 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] the front-end with notifications is yet to get a +1/-1 IIRC [12:44] but I didn't check for a few hours [12:44] should I give a look at the front-end pr you opened last thursday ? [12:44] I started a review but didn't get very far unfortunately [12:44] yeah, that would be great [12:44] * zyga looks [12:44] ok, sounds good [12:44] https://github.com/snapcore/snapd/pull/9446 [12:44] thank you! [12:45] 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] and reading some of the logic made me wonder if that would be a fair review [12:45] yes I saw your review thanks for the feedback [12:45] that is the general direction we are headed [12:45] I will return to it [12:45] btw, do we have a standup today? [12:45] I don't think we can get there right now but I agree that would make for the best user experience [12:45] or are all stand-ups cancelled this week? [12:45] zyga: I assume we have SU today? [12:46] I don't see any in my calendar [12:46] huh it does appear to not be there [12:49] zyga: ijohnson: it probably will only make sense to refine or overtake the console-conf experience in the full onboarding context [12:49] pedronis: yes agreed [12:50] also hi :-) [12:50] 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] pedronis that's a good point [13:59] pedronis: https://github.com/snapcore/snapd/pull/9427 has been updated too [14:14] 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] 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] ijohnson, I use branch 2.47 [14:15] cachio: ok I will try with the release/2.47 branch [14:15] snapd 9607 [14:15] core20 849 [14:15] pc 108 [14:15] pc-kernel 612 [14:16] this is the manifest ofthe image I used [14:16] cachio: ok thanks those are all the same as my image [14:16] cachio: did you set them to be tracking beta? [14:16] which model assertion and ubuntu-image arguments did you use? [14:17] beta dangerous [14:17] cachio: ack I was using edge dangerous and resetting the channel with -c option to ubuntu-image [14:17] sudo ubuntu-image '--image-size 8G' '' -c beta -O ./output/pc-amd64-20-beta ./models/pc-amd64-20.model [14:17] let me try with that model assertino too [14:18] ijohnson, sory [14:18] it ishttps://paste.ubuntu.com/p/pGZFPSv35x/ [14:18] it is edge [14:18] dangerous [14:18] switched to beta [14:18] cachio: ah ok so same thing I was doing [14:19] yes [14:19] cachio: but let me try running with the release/2.47 branch perhaps there's something there that's up [14:19] ijohnson, sure [14:27] cachio: it passed again for me on amd64 with git branch of 2.47 and the same snaps and model assertion, etc. [14:27] cachio: should I try on rpi now? [14:28] ijohnson, yes [14:28] failed here [14:28] cachio: but to be clear you see failures on amd64 right ? [14:28] how did you start the vm? [14:28] cachio: this [14:29] https://www.irccloud.com/pastebin/EH9HAiPk/ [14:29] cachio: what vm arguments do you boot with ? [14:29] ijohnson, yes, the same [14:29] ok, please try with rpi [14:29] hmm [14:29] alright I will try with arm64 on my rpi4 [14:40] ijohnson, I know why it failed here for amd64 [14:40] I used /usr/share/OVMF/OVMF_CODE.fd [14:40] cachio: why would that make a difference ? [14:40] I got the comand from the history instead of my docs [14:40] cachio: oh did you not enable secure boot ? [14:40] ijohnson, at least it is different of what you have [14:40] still it should work even without secure boot [14:41] ijohnson, right [14:41] no secure boot at all [14:41] interesting though, while my pi is running let me try without secure boot [14:41] ijohnson, thanks [14:41] secure boot shouldn't be necessary to run, it will just not use/enable any encryption [14:41] but that could have been broken [15:09] ijohnson, could you reproduce it? [15:09] cachio: it's running right now, both the pi version and the amd64 with your normal OVMF_CODE.fd kvm args [15:10] well let you know when it's done running [15:11] ijohnson, tx [15:12] cachio: I think I see the issue with the pi, do you use wlan for your pi connection ? [15:12] pi network connection that is [15:13] although perhaps this problem would happen w/ normal ethernet too [15:15] ethernet [15:15] I use [15:15] and in the lab too I think [15:16] 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] I think it may not be deterministic, so sometimes it comes back with the same IP and sometimes it doesn't [15:17] ijohnson, weird [15:18] but could be the raeson [15:18] 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] this would cause spread to not be able to ssh back after the device reboots to recover mode [15:18] yes [15:33] * cachio lunch [15:58] cachio: even with a fresh uc20 amd64 vm w/ secure boot disable I still can't reproduce a failure of uc20-recovery [15:58] cachio: can you share your full vm arguments you use to boot up the amd64 vm ? [16:23] 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] 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] this is what I used for that test [17:20] cachio: thanks I'll try that === seb128_ is now known as seb128 [19:46] ijohnson, so, the change in the ip is the problem? or you could found something else? [19:46] cachio: no I haven't found anything else, I think it's just the ip address problem [19:46] cachio: I filed upstream issues for core20 about this, so I think you can ignore safely the rpi failures [19:47] ijohnson, ok, thanks a lot [19:47] I will try your kvm cmdline again to see if I can reproduce the amd64 failure at all [19:47] but with all of my efforts I couldn't reproduce today [19:48] 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] cmatsuoka: I looked at it a bit a while ago [19:49] cmatsuoka: why did you find another bug there [19:49] 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] I see, well I'm not currently working on fontconfig stuff, perhaps mborzecki can comment if it's a cross distro thing [19:50] ijohnson: https://bugs.launchpad.net/snapd/+bug/1863613 [19:50] ijohnson: ah ok, I'll check with maciek tomorrow [19:50] and yes, it seems to be cross distro === Trevinho_ is now known as Trevinho