/srv/irclogs.ubuntu.com/2020/10/05/#snappy.txt

mborzeckimorning06:24
zygagood morning06:26
zygaLucy is just waking up so I may be AFK any time06:26
pstolowskimorning07:02
mborzeckipstolowski: hey07:04
zygagood morning pstolowski07:05
zygaI could use reviews for https://github.com/snapcore/snapd/pull/944607:25
zygait's still Monday07:25
zygawe can still merge this :)07:25
zygaI'd love some advice on how to make progress07:32
pedronismborzecki: hi, should #9247 be unblocked, is it ready for another review?08:22
zygare08:22
zygahello pedronis08:22
mborzeckipedronis: hey, yes, removed the blocked label just now08:23
pedronisok08:23
pedronispstolowski: mvo: made some some small comments in 9455, maybe pstolowski could address those?08:29
pstolowskipedronis: sure i can. i'm addressing comments to #9036 atm08:30
pedronishttps://github.com/snapcore/snapd/pull/9454 can be reviewed09:12
mborzeckipedronis: reviewed09:28
pedronisthx09:50
zygabrb10:16
zygare10:31
* zyga goes on the road10:39
* zyga works on https://github.com/snapcore/snapd/pull/8573 but now needs to carry is imac for servicing11:07
zygao/11:07
pedronismborzecki: I revewied #9427 again11:32
mborzeckipedronis: thanks11:36
mborzeckipedronis: do you think we should enforce that save comes before data, so that data can be expanded on install?11:36
pedronismborzecki: I need a bit more context, I don't remember the details of that11:41
mborzeckipedronis: 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.yaml11:43
mborzeckii don't see a check for this in gadget.go11:43
mborzeckior maybe it's too native of a check, there can be some weird platforms out there after all11:44
pedronismborzecki: it's seem fine to me, if you want auto-expansion put data last, if you don't care or have other reasons don't12:01
mborzeckipedronis: ack12:01
mborzeckipedronis: pushed the tweaks to https://github.com/snapcore/snapd/pull/9443 i'll chase cmatsuoka to take a look12:02
pedronismborzecki: thanks, I readded to my queue12:06
cachioijohnson, hi12:27
cachioijohnson, i saw uc20-recovery could be failing because a real problem12:28
cachioijohnson,  do you know anything else12:29
cachioit is the only blocker for snapd snap12:29
zygare12:37
ijohnsonhi cachio no, not yet I am looking again this morning12:40
cachioijohnson, nice, thanks12:41
zygahey guys12:42
ijohnsonhi zyga12:42
ijohnsonthanks for the review I will respond in a bit12:42
ijohnsonzyga: how goes the sprint ?12:42
zygaijohnson I'm not attending actually12:43
zygajust select meetings12:43
ijohnsonah I see12:43
ijohnsonhow are things looking on the refresh app awareness front ?12:43
zygathough I did get an invite for 9:30 pm so I guess that's enough ;-)12:43
ijohnsonhaha12:43
zygaijohnson I'm working on the inhibition lock branch I got feedback from Samuele on, iterating on specific bits, some more involved than others12:43
zygathe front-end with notifications is yet to get a +1/-1 IIRC12:44
zygabut I didn't check for a few hours12:44
ijohnsonshould I give a look at the front-end pr you opened last thursday ?12:44
ijohnsonI started a review but didn't get very far unfortunately12:44
zygayeah, that would be great12:44
* zyga looks12:44
ijohnsonok, sounds good12:44
zygahttps://github.com/snapcore/snapd/pull/944612:44
zygathank you!12:44
zygaI 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 morning12:45
zygaand reading some of the logic made me wonder if that would be a fair review12:45
ijohnsonyes I saw your review thanks for the feedback12:45
ijohnsonthat is the general direction we are headed12:45
zygaI will return to it12:45
zygabtw, do we have a standup today?12:45
ijohnsonI don't think we can get there right now but I agree that would make for the best user experience12:45
zygaor are all stand-ups cancelled this week?12:45
ijohnsonzyga: I assume we have SU today?12:45
zygaI don't see any in my calendar12:46
ijohnsonhuh it does appear to not be there12:46
pedroniszyga: ijohnson: it probably will only make sense to refine or overtake the console-conf experience in the full onboarding context12:49
ijohnsonpedronis: yes agreed12:49
ijohnsonalso hi :-)12:50
ijohnsonI 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 wrong12:50
zygapedronis that's a good point12:51
mborzeckipedronis: https://github.com/snapcore/snapd/pull/9427 has been updated too13:59
ijohnsoncachio: 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
ijohnsoncachio: I thought there might be an issue but now I've run that test locally on amd64 vm's twice in a row without issue14:14
cachioijohnson, I use branch 2.4714:15
ijohnsoncachio: ok I will try with the release/2.47 branch14:15
cachiosnapd 960714:15
cachiocore20 84914:15
cachiopc 10814:15
cachiopc-kernel 61214:15
cachiothis is the manifest ofthe image I used14:16
ijohnsoncachio: ok thanks those are all the same as my image14:16
ijohnsoncachio: did you set them to be tracking beta?14:16
ijohnsonwhich model assertion and ubuntu-image arguments did you use?14:16
cachiobeta dangerous14:17
ijohnsoncachio: ack I was using edge dangerous and resetting the channel with -c option to ubuntu-image14:17
cachiosudo ubuntu-image '--image-size 8G' '' -c beta -O ./output/pc-amd64-20-beta ./models/pc-amd64-20.model14:17
ijohnsonlet me try with that model assertino too14:17
cachioijohnson, sory14:18
cachioit ishttps://paste.ubuntu.com/p/pGZFPSv35x/14:18
cachioit is edge14:18
cachiodangerous14:18
cachioswitched to beta14:18
ijohnsoncachio: ah ok so same thing I was doing14:18
cachioyes14:19
ijohnsoncachio: but let me try running with the release/2.47 branch perhaps there's something there that's up14:19
cachioijohnson, sure14:19
ijohnsoncachio: it passed again for me on amd64 with git branch of 2.47 and the same snaps and model assertion, etc.14:27
ijohnsoncachio: should I try on rpi now?14:27
cachioijohnson, yes14:28
cachiofailed here14:28
ijohnsoncachio: but to be clear you see failures on amd64 right ?14:28
cachiohow did you start the vm?14:28
ijohnsoncachio: this14:28
ijohnsonhttps://www.irccloud.com/pastebin/EH9HAiPk/14:29
ijohnsoncachio: what vm arguments do you boot with ?14:29
cachioijohnson, yes, the same14:29
cachiook, please try with rpi14:29
ijohnsonhmm14:29
ijohnsonalright I will try with arm64 on my rpi414:29
cachioijohnson, I know why it failed here for amd6414:40
cachioI used /usr/share/OVMF/OVMF_CODE.fd14:40
ijohnsoncachio: why would that make a difference ?14:40
cachioI got the comand from the history instead of my docs14:40
ijohnsoncachio: oh did you not enable secure boot ?14:40
cachioijohnson, at least it is different of what you have14:40
ijohnsonstill it should work even without secure boot14:40
cachioijohnson, right14:41
cachiono secure boot at all14:41
ijohnsoninteresting though, while my pi is running let me try without secure boot14:41
cachioijohnson, thanks14:41
ijohnsonsecure boot shouldn't be necessary to run, it will just not use/enable any encryption14:41
ijohnsonbut that could have been broken14:41
cachioijohnson, could you reproduce it?15:09
ijohnsoncachio: it's running right now, both the pi version and the amd64 with your normal OVMF_CODE.fd kvm args15:09
ijohnsonwell let you know when it's done running15:10
cachioijohnson, tx15:11
ijohnsoncachio: I think I see the issue with the pi, do you use wlan for your pi connection ?15:12
ijohnsonpi network connection that is15:12
ijohnsonalthough perhaps this problem would happen w/ normal ethernet too15:13
cachioethernet15:15
cachioI use15:15
cachioand in the lab too I think15:15
ijohnsonok, 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 device15:16
ijohnsonI think it may not be deterministic, so sometimes it comes back with the same IP and sometimes it doesn't15:16
cachioijohnson, weird15:17
cachiobut could be the raeson15:18
ijohnsoncachio: let me try with ethernet to see if this happens, but I see it with wlan consistently and IMHO this is a bug15:18
ijohnsonthis would cause spread to not be able to ssh back after the device reboots to recover mode15:18
cachioyes15:18
* cachio lunch15:33
ijohnsoncachio: even with a fresh uc20 amd64 vm w/ secure boot disable I still can't reproduce a failure of uc20-recovery15:58
ijohnsoncachio: can you share your full vm arguments you use to boot up the amd64 vm ?15:58
ijohnsoncachio: 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.fd16:23
cachioijohnson, 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=kvm16:54
cachiothis is what I used for that test16:54
ijohnsoncachio: thanks I'll try that17:20
=== seb128_ is now known as seb128
cachioijohnson, so, the change in the ip is the problem? or you could found something else?19:46
ijohnsoncachio: no I haven't found anything else, I think it's just the ip address problem19:46
ijohnsoncachio: I filed upstream issues for core20 about this, so I think you can ignore safely the rpi failures19:46
cachioijohnson, ok, thanks a lot19:47
ijohnsonI will try your kvm cmdline again to see if I can reproduce the amd64 failure at all19:47
ijohnsonbut with all of my efforts I couldn't reproduce today19:47
cmatsuokaijohnson: have you worked or are you working on issues related to fontconfig? if not, do you remember who was playing with that?19:48
ijohnsoncmatsuoka: I looked at it a bit a while ago19:48
ijohnsoncmatsuoka: why did you find another bug there19:49
cmatsuokaijohnson: no, I'm re-triaging bugs that are triaged/confirmed but have not importance set, and if possible I'm also assigning them19:49
ijohnsonI see, well I'm not currently working on fontconfig stuff, perhaps mborzecki can comment if it's a cross distro thing19:50
cmatsuokaijohnson: https://bugs.launchpad.net/snapd/+bug/186361319:50
cmatsuokaijohnson: ah ok, I'll check with maciek tomorrow19:50
cmatsuokaand yes, it seems to be cross distro19:50
=== Trevinho_ is now known as Trevinho

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!