mborzecki | morning | 06:24 |
---|---|---|
zyga | good morning | 06:26 |
zyga | Lucy is just waking up so I may be AFK any time | 06:26 |
pstolowski | morning | 07:02 |
mborzecki | pstolowski: hey | 07:04 |
zyga | good morning pstolowski | 07:05 |
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:25 |
zyga | I'd love some advice on how to make progress | 07:32 |
pedronis | mborzecki: hi, should #9247 be unblocked, is it ready for another review? | 08:22 |
zyga | re | 08:22 |
zyga | hello pedronis | 08:22 |
mborzecki | pedronis: hey, yes, removed the blocked label just now | 08:23 |
pedronis | ok | 08:23 |
pedronis | pstolowski: mvo: made some some small comments in 9455, maybe pstolowski could address those? | 08:29 |
pstolowski | pedronis: sure i can. i'm addressing comments to #9036 atm | 08:30 |
pedronis | https://github.com/snapcore/snapd/pull/9454 can be reviewed | 09:12 |
mborzecki | pedronis: reviewed | 09:28 |
pedronis | thx | 09:50 |
zyga | brb | 10:16 |
zyga | re | 10:31 |
* zyga goes on the road | 10:39 | |
* zyga works on https://github.com/snapcore/snapd/pull/8573 but now needs to carry is imac for servicing | 11:07 | |
zyga | o/ | 11:07 |
pedronis | mborzecki: I revewied #9427 again | 11:32 |
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:36 |
pedronis | mborzecki: I need a bit more context, I don't remember the details of that | 11:41 |
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:43 |
mborzecki | or maybe it's too native of a check, there can be some weird platforms out there after all | 11:44 |
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:01 |
mborzecki | pedronis: pushed the tweaks to https://github.com/snapcore/snapd/pull/9443 i'll chase cmatsuoka to take a look | 12:02 |
pedronis | mborzecki: thanks, I readded to my queue | 12:06 |
cachio | ijohnson, hi | 12:27 |
cachio | ijohnson, i saw uc20-recovery could be failing because a real problem | 12:28 |
cachio | ijohnson, do you know anything else | 12:29 |
cachio | it is the only blocker for snapd snap | 12:29 |
zyga | re | 12:37 |
ijohnson | hi cachio no, not yet I am looking again this morning | 12:40 |
cachio | ijohnson, nice, thanks | 12:41 |
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:42 |
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:43 |
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:44 |
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:45 |
zyga | I don't see any in my calendar | 12:46 |
ijohnson | huh it does appear to not be there | 12:46 |
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:49 |
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:50 |
zyga | pedronis that's a good point | 12:51 |
mborzecki | pedronis: https://github.com/snapcore/snapd/pull/9427 has been updated too | 13:59 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:27 |
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:28 |
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:29 |
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:40 |
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 | 14:41 |
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:09 |
ijohnson | well let you know when it's done running | 15:10 |
cachio | ijohnson, tx | 15:11 |
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:12 |
ijohnson | although perhaps this problem would happen w/ normal ethernet too | 15:13 |
cachio | ethernet | 15:15 |
cachio | I use | 15:15 |
cachio | and in the lab too I think | 15:15 |
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:16 |
cachio | ijohnson, weird | 15:17 |
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:18 |
* cachio lunch | 15:33 | |
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 ? | 15:58 |
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:23 |
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 | 16:54 |
ijohnson | cachio: thanks I'll try that | 17:20 |
=== seb128_ is now known as seb128 | ||
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:46 |
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:47 |
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:48 |
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:49 |
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 | 19:50 |
=== Trevinho_ is now known as Trevinho |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!