/srv/irclogs.ubuntu.com/2020/08/18/#snappy.txt

zygagood morning06:08
zygabattery running low, brb06:37
zygare06:39
zygamvo: quiet day, eh?06:42
mvozyga: good morning06:45
mvozyga: yes, pretty quiet06:45
mvozyga: did you enjoy your long weekend?06:46
zygayes, though lucy had fever yesterday and we were worried06:46
zygait's all meant to be quite different, my wife returned to work today and (before I got sick) I was supposed to take two weeks off06:47
zygabut reality struck and here we are :)06:47
mvozyga: yeah, reality is annoying sometimes - but you can't argue with it - it's always right :/06:48
zyga:D06:48
zygayep06:48
pstolowskimorning07:01
mvogood morning pstolowski07:04
mvopstolowski: hope you had a nice long weekend07:04
pstolowskimvo: hey! yes, was very nice07:10
* zyga had breakfast07:25
zygaLucy still sleeping :)07:25
zygaI'm working on the udev integration branch07:25
zygait's open for so long and should not take long to finish07:26
mvozyga: nice!07:27
zygahmm, some store EOFs07:27
zyga- Download snap "core18" (1885) from channel "stable" (unexpected EOF)07:28
zygais unexpected EOF something we retry on?07:29
mvopstolowski: unless you disagree I will (squash) merge 915207:29
mvozyga: probably, might be worthwhile to check the logs07:29
zygamvo: here it was during "snap install shellcheck" before we ran spread07:29
zygaso no logs07:29
pstolowskimvo: fantastic! yes, go for it, thanks07:30
mupPR snapd#9152 closed: cmd/snapd-generator: generate drop-in to use fuse in container <Bug> <Preseeding 🍞> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9152>07:34
zygastore is really unhappy today07:49
mupPR snapd#9102 closed: corecfg: add "system.timezone" setting to the system settings <Run nested> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9102>07:49
pstolowskijamesh: hi! minor comment to your snapctl is-connected PR08:25
jameshpstolowski: looking08:25
jameshpstolowski: would it actually be possible to call snapctl in a context where implicit plugs and slots existed?08:31
pstolowskijamesh: we have a 'hack' for implicit slots (AddImplicitSlots helper) that we explicitly call over SnapInfo of system snap in various places. if core had interface hooks for slots than I image it would be needed. but i'd leave it as is for now because it's not going to be needed any time soon08:34
pstolowskis/image/imagine/08:35
jameshI suppose core has a configure hook where it could make a difference if it actually checked08:36
pstolowskijamesh: it has but the hook is "hijacked" and handled internally08:40
* zyga moves to the office, lucy is now awake and handled by grandparents08:43
pstolowskimvo: there is one question from Samuele pending your input on https://github.com/snapcore/snapd/pull/9084, can you take a look?08:53
mupPR #9084: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>08:53
mvopstolowski: sure, looking08:54
mvopstolowski: replied08:58
pstolowskity08:58
zygamvo: uh09:47
zygawe have a very silly bug in master09:47
zygamvo: patch coming right up09:48
mvozyga: oh, ok09:48
mupPR snapd#9171 opened: [RFC] "virtual" configuration for timezone <Needs Samuele review> <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9171>09:50
mupPR snapd#9172 opened: tests: update spread test for unknown plug/slot with snapctl is-connected <Simple 😃> <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9172>09:55
pstolowskijamesh: i've updated snapctl spread test to test the new error message ^09:58
zyga-mbpmvo https://github.com/snapcore/snapd/pull/917310:03
mupPR #9173: cmd: compile snap gdbserver shim correctly <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/9173>10:03
mupPR snapd#9173 opened: cmd: compile snap gdbserver shim correctly <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/9173>10:05
mvozyga-mbp: thank you10:19
zyga-mbpI really wonder what tests will say10:19
zyga-mbpI never tried this10:19
mvo9084 needs a second review if someone has some spare cycles10:20
mupPR snapd#9120 closed: interfaces: add kernel-crypto-api interface <Needs Samuele review> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9120>10:40
mupPR snapd#9165 closed: interfaces: add kernel-crypto-api interface - 2.46 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9165>10:40
zyga-mbplooking10:44
mupPR snapd#9167 closed: many: correctly calculate the desktop file prefix everywhere <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9167>10:45
zyga-mbppstolowski https://github.com/snapcore/snapd/pull/9084#pullrequestreview-46920748910:50
mupPR #9084: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>10:50
zyga-mbpbrb, I'll fetch some water10:50
mvo9081 also needs a second review10:52
mvojdstrand: 8301 has conflicts now, could you please have a look?11:00
mvopstolowski: just fyi, I uploaded a new snapd to groovy with the lxd generator fix so that should allow groovy lxd preseed images. could you please let the relevant people know (still needs some hours before it enters groovy proper, still building of course)11:13
pstolowskimvo: sure, thanks11:18
* zyga fetched lunched instead11:36
zygare11:36
zygaopensuse tumbleweed seems to be unhappy11:40
zygaerror: cannot query the store for updates: got unexpected HTTP status code 503 via POST to "https://api.snapcraft.io/v2/snaps/refresh"12:46
zygamore store woes12:46
zygapstolowski: ping12:49
zygaI have this in a debug shell12:49
zyga+ lxd.lxc exec my-nesting-ubuntu -- snap set lxd waitready.timeout=24012:49
zygaerror: cannot perform the following tasks:12:49
zyga- Run configure hook of "lxd" snap (snap "lxd" has no "configure" hook)12:49
zyganested snaps are all broken, not mounted12:50
pstolowskizyga: ok, that's weird12:50
pstolowskizyga: is it master?12:51
zygayep12:51
zygabut seems random12:51
zygahttps://paste.ubuntu.com/p/3YspQRfGvT/12:51
zygainteresting failed unit12:51
zygano snap mounted12:51
zygaI guess one idea would be to not run hooks on broken snaps12:52
zygathe snaps are on disk12:52
zygalooking at the mount units12:52
zygathere are no mount units?!?12:53
pstolowskidid i broke something with systemd generator thing..?12:53
zygamaybe12:54
zygalooking12:54
pstolowskimvo: was #9152 green when it landed, or did you merge manually?12:54
mupPR #9152: cmd/snapd-generator: generate drop-in to use fuse in container <Bug> <Preseeding 🍞> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9152>12:54
zygafstab has only LABEL=cloudimg-rootfs/ ext4defaults0 012:55
zygabut there's no /dev/disk/by-label12:55
zygaI guess that's because of a container12:55
zygaand also explains the failed unit12:55
zygaseems like a separate container bug12:55
zygaI don't see any evidence that snapd generator ran12:56
zygawell12:56
zygaactually12:56
zygaI do see snap.mount12:56
mvopstolowski: I thought it was, maybe I was mistaken12:56
zygaand nothing else12:56
mvopstolowski: do you see errors now?12:56
zygawhat's the other file we should have created?12:57
zygathe file /run/systemd/container is present12:57
zygaand has the word "lxc"12:57
zygaI guess that's why nothing mounted btw12:57
zygabut it's funny12:57
zygaI guess terrible12:57
zygathat we INSTALLED snaps in broken state after mounting failed12:57
zygamounting should have undone everything12:57
zygachanges and tasks from the container https://paste.ubuntu.com/p/VPH4DwbGvx/12:58
pstolowskizyga: there should drop-ins in /run/systemd/generator for all the snap mount  untis for /etc/systemd/system12:58
pstolowskizyga: are there mount units in /etc/../system ?12:59
zygathere are no drop ins12:59
zygahttps://paste.ubuntu.com/p/ft8pr6qXrC/12:59
zygaand there are no mount nits12:59
zygabut we remove them in undo12:59
zygaalthough this makes no sense because "snap list" shows all the snaps installed and broken13:00
zygathis is tests/main/lxd13:00
zygaperhaps it's using older non-repackaged core18 + snapd13:00
zygahmm hmm13:00
pstolowskizyga: ok if there are no mount units then root cause is elsewhere, not in the generator13:00
zygacan you just spread 16.04 + tests/main/lxd13:00
zygaand see if that fails13:00
zygapstolowski: well, mount units do get removed on undo13:01
zygabut I really don't know what to make of this13:01
zygathe generator only has the /snap sharing mount13:01
zygabut doesn't have the drop ins13:01
zygaah13:01
zyga1337.2.46~pre213:01
zygawell13:01
zyga1337 is the repackaged13:01
zygaso...13:01
zygahmmm13:01
mvozyga, pstolowski standup13:01
zygait seems broken13:01
zygaoh13:01
zygajoining13:01
jdstrandmvo: hi! certainly, I'd love to. thanks for the reviews/merges! :)13:17
mvojdstrand: thank you!13:17
jdstrandmvo: fyi, the cups one should good for re-review whenever people have a chance (though I'm going to merge master real quick). I'll quickly respond to any feedback there. moving on to 'misc policy updates' then after, will go through any PR reviews that need me13:20
zygajdstrand: could you try to look at https://github.com/snapcore/snapd/pull/7614 again13:21
mupPR #7614: cmd/snap-confine: implement snap-device-helper internally <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>13:21
zygajdstrand: I pushed it forward13:21
jdstrandzyga: sure13:23
pstolowskizyga: main/lxd failed for me as well13:23
zygagood13:23
zygaso it's a real thing13:23
zyga(reproducible)13:23
zygapstolowski: try reverting the generator changes to see if that does something13:24
jdstrand"corecfg: add "system.timezone" setting to the system settings"13:25
jdstrandnice! :)13:25
zygajdstrand: snap regedit ...13:25
zyga;-)13:25
jdstrandah, I wonder if that lxd thing is what was causing my spread tests to fail...13:25
jdstrandzyga: heh13:25
zygajdstrand: I think we may have broken master13:25
pstolowskizyga: ok will do just in case, although it would contradict what ijohnson said13:26
zygapstolowski: sure - just a sanity check13:26
pstolowskioh it wasnt't squash-merged13:26
* jdstrand will keep an eye on commits to master for something to unbreak things then13:27
ijohnsonzyga: yeah I saw it on my PR's last night before the generator stuff had landed13:27
zygaah, sorry, I couldn't hear that exactly13:27
zygathat's good, maybe something environmental changed13:27
zygajdstrand: and comments in that PR are a bit in a weird state, I could not reply to some13:36
zygajdstrand: so please open new comments on anything that you find wrong13:36
mupPR snapcraft#3165 closed: Update cmake plugin to support Ninja generator <enhancement> <Created by GamePad64> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3165>13:37
zygapstolowski, ijohnson: interesting13:39
zygain a debug shell look at the other container (my-ubuntu)13:39
zygait has core installed as well13:39
zygaand guess what, core works13:39
zygaall the seeded snaps are broken13:39
zygacore is not seeded13:39
zygadoes this make _any_ sense to you?13:40
zygamaybe what is really broken13:40
zygais that /etc/systemd/system just doesn't have any mount units13:40
zygamaybe the image is broken to begin with13:40
* zyga looks13:40
zygapstolowski: confirmed13:42
zygathe image is busted13:42
zygahowever it was made is wrong13:43
zygapstolowski: should I expect to see mount units inside a squashfs lxd image? (in a container image downloaded by lxd)13:43
zygaI see the snaps and everything else13:43
zygabut the mount units are simply missing13:43
zygaas if it was seeded but then something filtered out the .mount units13:44
zygapstolowski: to reproduce look at /var/snap/lxd/common/lxd/images/97c470e427c425cf2ec4d7d55b6f1397ea55043c518b194a58fc6b9da426f540.rootfs on /tmp/dupa type squashfs (ro,relatime)13:44
zygacc stgraber ^13:44
jdstrandmvo: fyi, PR 8301 is deconflicted13:44
mupPR #8301: interfaces/many: deny arbitrary desktop files and misc from /usr/share <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8301>13:44
zygastgraber: it seems that 20.04.1 images that lxd pulls in are snap seeded in a broken way13:45
zygastgraber: etc/systemd/system does not have any mount units13:45
stgraberzyga: that'd be a bit concerning as the squashfs we use is supposed to be identical filesystem as the cloud image13:45
zygastgraber: can you double check that I'm not making some rookie mistake13:45
zygaI mounted the .rootfs as downloaded by lxd13:46
zygaand looked at /etc/systemd/system therein13:46
stgraberit's this image in your case: http://cloud-images.ubuntu.com/releases/focal/release-20200804/13:46
zygaare they all identical?13:47
* zyga pulls the squashfs13:47
stgraberthey should be13:47
zygaa bit slow to pull, I'll let it do its thing13:48
pstolowskii wonder if they started preseeding them and something went wrong13:48
zygathe date says 4th of August13:48
zygamaybe it is before we had some fixes?13:48
zygaand it's just busted \13:49
ogra_zyga, my yesterdays focal image that i installed looks fine here ... why would mount units be n the readonly squashfs though ?13:50
zygaogra_: IIRC because we pre-seed things13:50
zygaso they start faster13:50
zygaisn't the squashfs expanded anyway, it's just a template13:50
zygait's not a snap13:50
ogra_root@focal:~# ls /etc/systemd/system/*.mount|wc -l13:51
ogra_813:51
zygaogra_: that's not what I'm seeing13:51
ogra_root@focal:~# snap list|wc -l13:51
ogra_613:51
zygawhat are the mount units?13:51
zygaI had 0 mount units13:51
zyga(though I'm still getting the image stgraber suggestd)13:51
ogra_root@focal:~# ls /etc/systemd/system/*.mount13:51
ogra_root@focal:~#13:51
ogra_bah13:51
ogra_let me pastebin that13:51
zygaI saw the failure in a spread test that was just "lxd launch ..." things13:51
zygathanks13:51
ogra_https://paste.ubuntu.com/p/HJJ3NN9hxm/13:52
zygaright13:52
zygathis is more like what I would expect13:52
zygaI think an image is broken then, the only question is why and how to fix it13:52
stgraberstgraber@castiana:~/Downloads$ tar Jtvf ubuntu-20.04-server-cloudimg-amd64-root.tar.xz | grep etc/systemd | grep mount13:52
ogra_thats what i got with "lxc launch ubuntu:20.04 focal" ...13:52
stgraberstgraber@castiana:~/Downloads$13:52
pstolowskizyga: also, it's from 4th Aug but started failing yesterday?13:52
zygapstolowski: yeah, I think we are missing something13:53
zygastgraber: 97c470e427c425cf2ec4d7d55b6f1397ea55043c518b194a58fc6b9da426f540.rootfs can we map that hash to something on cdimage?13:53
stgraberpstolowski: assuming it's using ubuntu:, the images are manually promoted by CPC IIRC, though indeed feels a bit old13:53
stgraberzyga: I did it for you13:53
stgraberzyga: that's the URL I gave you13:53
zygaah13:54
* zyga looks at one more idea13:54
stgrabercurrent ubuntu:focal is indeed 20200804 on cloud-images.u.c13:54
stgraberubuntu-daily:focal would be 2020081413:54
stgraberthere's a pretty good chance that the cloud images would similarly be missing those files, it's really meant to be identical across the board13:55
stgraberso you probably should be talking to CPC :)13:55
mupPR snapd#9173 closed: cmd: compile snap gdbserver shim correctly <Bug> <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9173>13:56
zygathanks mvo13:57
ijohnsonsorry had to step out for IRL things13:57
ijohnsonso is the lxd image just busted then ?13:57
zygaijohnson: it seems so but unclear why13:58
zygaI noticed something buggy in the test13:58
zygalooking now13:58
zyga    lxd.lxc launch --quiet "ubuntu:${VERSION_ID:-}" my-ubuntu13:58
zygaVERSION_ID is not defined anywhere13:58
zygawhat does that fetch?13:58
zygalatest?13:58
stgraberah so you went from bionic to focal last week then13:59
zygaI think it's a bug and it was meant to fetch the one matching13:59
zygaso it's likely that this bug triggers another one13:59
stgraber"ubuntu:" fetches the latest recommended LTS13:59
stgraberthat was bionic until 20.04.113:59
stgrabernow is focal13:59
ijohnsonzyga: I think we get VERSION_ID from /etc/os-release which gets sourced somewhere in the prepare for a spread run iirc14:00
zygaijohnson: I doubt that14:00
zygathre was some code in that task.yaml14:00
zygait's gone now14:00
zygamust have been killed by accident14:00
zygaand ${VERSION_ID:-} masked that14:00
ijohnsonhaha fair enough14:00
zygait used to load version id from the host14:00
zygabecause it was about alignment of the container to the system14:00
zygaas we copy stuff inside14:00
pstolowskizyga: i'm looking at ubuntu-20.04-server-cloudimg-amd64-root.tar.xz (also dated 4/08) is this as good as any other image there? fwtw it is NOT preseeded, it's still seeding the old way14:01
zygaI see14:01
zygaI'll start by fixing that VERSION_ID14:02
zygabut it seems we have more bugs14:02
zygapstolowski: can you focus on trying to understand what's going on in the inner layer14:02
zygaI'll send a patch fixing the symptom we see14:03
zygaijohnson: you broke it ;D14:05
* ijohnson runs and hides14:06
ijohnsonzyga: was it my use the same version of lxd everywhere PR ?14:06
zygad4a802934b1e62ec8924ea1c165a627695df504414:06
zygathat's the broken patch14:06
zygaanyway, fixes coming14:06
ijohnsonzyga: haha to be fair though you approved the PR :-D14:07
zygano hard feelings14:07
zygaat this point I'm beyond shame14:07
zygaI made so many bugs14:07
ijohnsonyeah bugs happen14:07
ijohnsonno worries14:07
pstolowskizyga: so what's actually broken? do i need to keep looking?14:08
zygapstolowski: that test is broken when invoked with a focal image14:08
zygapstolowski: on a xenial host14:08
zygapstolowski: it should work14:08
zygapstolowski: to reproduce just grab xenial VM14:08
zygapstolowski: install lxd the same way14:08
zygapstolowski: and boot focal14:08
zygapstolowski: that should work and give you a working focal container with working snaps14:09
pstolowskizyga: ok so it's a test issue, not a real problem?14:09
zygapstolowski: it's a real problem14:09
zygapstolowski: the test just now stumbled onto it14:09
zygapstolowski: it was not exercising that before14:09
pstolowskiah ok14:09
zygapstolowski: but effectively started doing that because of another issue and recent promotion of focal14:09
zygapstolowski: PR coming up, I've explained it there as well14:10
zygajust confirming that my patch fixes it14:11
ijohnsonzyga: so the right thing for this lxd test is for a xenial host to run a xenial container and a focal host to run a focal container ?14:17
zygaijohnson: yes14:17
zygathere's a comment there explaining why14:17
ijohnsonzyga: I wonder if we should expand the lxd test to have more variants i.e. xenial host launches focal, bionic and xenial14:18
ijohnsonoh14:18
* ijohnson goes to read that comment14:18
zygayes but then we should not just blindly copy snapd14:18
zygabut I agree14:18
ijohnsonah yes14:18
ijohnsonI see14:18
ijohnsonsee if we built the snapd snap and used that as part of our tests we could avoid this14:18
zygayes14:18
zygaI'm sure we could14:18
zygait's just a limitation of the current setup14:18
zygaall proper builds will work14:18
zyga(properly built rpm will work on rpm distros)14:19
zygageez that test is sloooooow14:19
ijohnsonmmmm also this test is disabled for uc20 too14:19
zyga(network)14:19
ijohnsonwe should re-enable that and make sure lxd works on uc2014:19
zygaI agree14:19
zygamaybe worth splitting lxd test14:19
zygaand thinking of a cache for lxd images if that helps14:19
zygaFYI https://github.com/snapcore/snapd/pull/917414:19
mupPR #9174: tests: fix lxd test wrongly tracking 'latest' <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9174>14:19
zygaopened while local test is still going14:20
zygaso likely it works now14:20
zygabut I want to break now as my wife just returned from her first day of work after Lucy was born14:20
zygaI'll work later in the evening, to focus on bug triage14:20
zygaI think it's still broken though14:20
zygajust got this14:20
zygahttps://paste.ubuntu.com/p/yJ6HThPdN6/14:21
mupPR snapd#9174 opened: tests: fix lxd test wrongly tracking 'latest' <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9174>14:21
* zyga akf14:21
ijohnsonzyga: approved14:21
zygaijohnson: let's see it pass14:21
ijohnsonwell it "looks correct" :-)14:21
zygaI agree :)14:22
zygaoh14:22
zygait passed14:22
zygawoooot14:22
zygaOk14:22
zygaI'm really afk now14:22
mvozyga \o/14:22
mvojdstrand: one quick question in 830114:23
cmatsuokaijohnson: do you have any idea on why chooser triggering is not working in recover mode? the trigger file in /run is not there but I still didn't check if it's not being generated at all, or it's not being moved from initramfs to the real system14:30
ijohnsoncmatsuoka: oh hey I tried that and it seemed to work for me with all edge snaps just now14:31
cmatsuokaoh really? then it must be something I'm doing locally, let me recheck14:31
ijohnsoncmatsuoka: yes it took like a minute to trigger the chooser, etc. but it definitely wasn't 10 minutes or longer before the chooser came up14:41
jdstrandmvo: answered14:46
mupPR snapcraft#3251 opened: build providers: honour http proxy settings for snapd <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3251>14:47
cmatsuokaijohnson: indeed it works with edge, so probably my remastering of initramfs is the source of the problem14:52
cachiomvo, hey14:57
cachiofailover tests failing on master as well14:58
mvocachio: hey14:58
mvocachio: oh no! can you please paste the full error log?14:58
cachiomvo, https://paste.ubuntu.com/p/7c56xfYGwC/14:59
cachioI just merged before running the tests14:59
cachioso my master is up to date14:59
mupPR snapcraft#3252 opened: snapcraft: use system certificates by default for https requests <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3252>15:02
mvocAug 18 14:55:53 localhost.localdomain snapd[3776]: Aug 18 14:55:28 localhost.localdomain systemd[3584]: snapd.service: Failed at step EXEC spawning /snap/snapd/x1/usr/lib/snapd/snapd: Exec format error15:04
mvohm, but maybe this is just the message that it failed correctly15:05
mvocachio: the "external:" image, how was this build?15:10
mvocachio: also, what is the output of "journalctl -u snapd-failover.service"?15:10
cachiomvo, ubuntu-image snap15:11
mvocachio: I need to be afk for some minutes but I guess my question is, what commands do I need to run to trigger this error myself (to reproduce :)15:11
* mvo is afk for some minutes but will read scrollback15:12
cachiolet me run again15:14
cachiomvo, wget https://storage.googleapis.com/spread-snapd-tests/images/pc-amd64-16-beta/pc.img.xz15:15
cachiosudo kvm -snapshot -smp 2 -m 1500 -net nic,model=virtio -net user,hostfwd=tcp::8022-:22  -serial mon:stdio pc.img15:15
cachiothen run15:15
cachioexport SPREAD_EXTERNAL_ADDRESS=localhost:802215:16
cachio./tests/lib/external/prepare-ssh.sh localhost 8022 <your-lp-id>15:16
cachiospread -debug external:ubuntu-core-16-64:tests/core/core-to-snapd-failover1615:16
cachiomvo, following those step you can reproduce 100%15:16
pstolowskizyga: i'm playing with this broken lxc container. in this state i cannot remove or refresh broken snapd snap, a dead end15:19
cmatsuokaijohnson, mvo: I ran some extra tests here and apparently what makes the difference in the reboot from chooser is using a local, unchanged core20 snap vs the edge asserted core2015:19
pstolowskizyga: interestingly, i could manually snap install lxd and core18 snaps from seeds, and after that snap set lxd waitready... woks15:20
pstolowski*works15:20
cmatsuokaijohnson, mvo: erm, wait. that's strange. let me do it again15:20
pstolowskizyga: also saw this, not sure if it means anything https://pastebin.ubuntu.com/p/sJvDhxp5gy/15:21
cmatsuokaijohnson, mvo: the actual problem with the server connection timeout is caused by snapd snap injection, not sure exactly why, but it's local, so sorry for the noise15:41
zygapstolowski: re15:55
zygapstolowski: that's a known issue, I can explain but I think it is neither new nor a problem for this test15:56
zygapstolowski: today it is late so I won't dig deeper15:56
zygaI will focus on bug triage and a small thing I was working on earlier15:56
zygalet's attack this tomorrow morning15:57
pstolowskizyga: yeah i think i'll stop here as well15:57
zygahttps://github.com/snapcore/snapd/pull/9174 is making progress, though 16.04-64 is still in progress15:58
mupPR #9174: tests: fix lxd test wrongly tracking 'latest' <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9174>15:58
mupPR snapd#9175 opened: tests: find -ignore_readdir_race when scanning cgroups <Simple 😃> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9175>16:16
mupPR snapcraft#3253 opened: extensions: prepend the snapd glvnd path <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/3253>16:18
zygaSaviq: o/ I noticed your question yesterday but I was off16:18
zygaSaviq: can you grab me tomorrow - we can discuss that then16:18
zygaijohnson: commented and asked a question on https://bugs.launchpad.net/snapd/+bug/188909216:32
mupBug #1889092: getent does not support extrausers on uc18 <snapd:Confirmed> <https://launchpad.net/bugs/1889092>16:32
ijohnsonzyga: interesting point, perhaps getent works fine with uc20 or even uc2216:34
ijohnsonzyga: also your lxd test PR failed again same problem16:36
zygahttps://github.com/snapcore/snapd/pull/9174#issuecomment-67558674516:37
mupPR #9174: tests: fix lxd test wrongly tracking 'latest' <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9174>16:37
zygano16:38
zyganot the same problem16:38
zygamvo: we may need to revert pawel's generator16:38
zygamvo: now that we test it better16:38
zygait doesn't work on 16.0416:38
zygait was just never tested correctly16:38
ijohnsonzyga: sorry how do you know that it is the generator?16:38
zygathe generator never ran16:38
zygaor ran and did nothing16:38
ijohnsonzyga: your PR tests failed with the same configure hook problem16:38
zygathis test passed when we were testing against a different, more recent container (by accident)16:38
zygaijohnson: https://github.com/snapcore/snapd/pull/9174/checks?check_run_id=998982860 shows a different error16:39
mupPR #9174: tests: fix lxd test wrongly tracking 'latest' <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9174>16:39
ijohnsonRun configure hook of "lxd" snap (snap "lxd" has no "configure" hook)16:39
zygaI see this failure:16:40
zyga2020-08-18T15:30:31.5864620Z Sanity check that mount overrides were generated inside the container16:40
zyga2020-08-18T15:30:31.5864910Z + MATCH '/var/run/systemd/generator/snap-core-.*mount.d/container.conf'16:40
zyga2020-08-18T15:30:31.5865202Z + lxd.lxc exec my-ubuntu -- find /var/run/systemd/generator/ -name container.conf16:40
zyga2020-08-18T15:30:31.5865318Z grep error: pattern not found, got:16:40
zygawhich suggests that what I wrote above is likely16:40
ijohnsonzyga: ok so 16.04 failed but 20.04 failed same way with the configure hook16:40
ijohnsonzyga: I was only looking at the 20.04 failure16:40
zygaI see16:40
zygawell16:40
zyga20.04 is broken because the image is broken :)16:40
ijohnsonhey bionic is working well then16:40
zygawe are now testing image matching the host16:40
ijohnsonwith pawel's generator16:40
zygaso it's totally expected that focal is broken16:40
zygathat's the issue pawel was looking into just a moment ago16:41
zygaand that's what we immediately saw16:41
zygathe PR doesn't change that, it just makes host match the container16:41
ijohnsonright ok so this makes sense then16:41
zygayeah16:41
zygaI think we need to fix more than one issue here16:41
zygaand if this is something we badly need for 2.46 we need to delay16:41
ijohnsonso focal is totally broken because broken images, and xenial is broken because the generator didn't run16:41
zygaijohnson: if focal is preseeded then yes16:42
zygaif it's not pre-seeded then I thing something else is at play16:42
zygamvo: ^ please ack if this is a release blocker16:42
zygaI'll copy this log to pawel16:42
zygaso that he knows about it16:42
* cachio lunch16:43
* zyga EODs16:44
=== ijohnson is now known as ijohnson|lunch
mupPR snapd#9176 opened: cmd/snap: use ⬏ instead of ↑ where applicable <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9176>17:42
mupPR snapcraft#3253 closed: extensions: prepend the snapd glvnd path <Created by Saviq> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3253>18:03
mvozyga: hey, I was just looking at the scrollback18:31
zygamvo: mmm18:31
mvozyga: so the generator needs reverting?18:31
zygamvo: it might18:32
zygamvo: I have a hunch it doesn't work on 16.0418:32
mvozyga: oh, ok18:32
zygamvo: the test was flaky, it never ran on a 16.04 container18:32
zygamvo: we should discuss with pawel when he reads this tomorrow18:32
zygamvo: I just wanted to let you know18:32
zygamvo: as this seems to be relevant to 2.4618:32
mvozyga: totally18:33
mvozyga: let's tackle this in the morning when pawerl and you and me are around18:33
zygaindeed18:33
mvozyga: thanks for the heads up18:33
zyga:)18:33
mupPR snapcraft#3219 closed: meta: detailed warnings for resolution of commands <enhancement> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3219>18:58
dariballhey hey, I am building a ubuntucore image with some snaps targetting raspi4, is there some best practice to test the image in some virtualisation/emulation ? qemu seems not to be trivial. the ubuntucore docs propose `multipass` but I assume this is then x86 only as long as I do not run it on a raspi, right ?19:06
zyga-mbpijohnson|lunch https://listed.zygoon.pl/17533/measuring-coverage-of-shell-scripts19:09
=== ijohnson|lunch is now known as ijohnson
zyga-mbpdariball for raspi4 you pretty much need a raspi419:09
ijohnsonzyga-mbp: nice! :-)19:10
ijohnsonI'm really curious now how much of our shell scripts actually get run :-)19:13
zyga-mbpijohnson so was I :)19:14
zyga-mbpalthough I have a second agenda here, that's a bit more annoying to accomplish19:14
zyga-mbpI want to write unit tests for makefiles19:14
zyga-mbpbut the way make executes stuff makes that hard19:15
zyga-mbpthis was a step towards that19:15
zyga-mbpijohnson an aggregate mode would be nice19:15
ijohnsonyou mean a unit test for a makefile itself ?19:15
zyga-mbpsomething like bashcov --cumulative ...19:15
zyga-mbpyes19:15
zyga-mbpI wrote a build system a while ago19:16
ijohnsoninteresting what's the use case for it?19:16
zyga-mbpand I really want to get to 100% coverage and documentation19:16
zyga-mbphttps://github.com/zyga/zmk/19:16
zyga-mbpdocumentation is still sparse19:16
zyga-mbpbut testing is pretty solid19:16
dariballzyga-mbp: means using a raspi4 with a regular ubuntu where I then run multipass, right ?19:16
zyga-mbpI know some things are not tested as I didn't write any tests yet (for certain modules)19:16
zyga-mbpbut for those that are, I want to see if anything is missing19:17
zyga-mbpdariball no, I mean you need to run it on real metal19:17
zyga-mbpthe best way forward is to automate deployment19:17
zyga-mbpwe're doing that for tests of snapd and ubuntu core itself19:17
zyga-mbpbut it's not something that's easy or fun19:17
zyga-mbpdariball CPU architecture is just one aspect of the problem19:17
zyga-mbpyou really need an emulated "raspberry pi" virtualized but nobody made one that's not broken19:18
zyga-mbpso deployment on the real thing is really the only viable option19:18
zyga-mbpthere are hardware add-ons that allow you to deploy to a SD card and boot a PI with that card19:18
dariballyeah this was my impression until now ... tried some qemu stuff, but thanks for confirming my impression19:18
zyga-mbpsome companies manufacture them19:18
zyga-mbpsome people make more or less successful implementations of that idea19:19
zyga-mbpIIRC canonical even has the most successful as a test engineer now :)19:19
zyga-mbpbut anyway, it's not something I can recommend19:19
zyga-mbpunless you have a budget to spend19:19
zyga-mbpijohnson as for testing19:19
zyga-mbpijohnson I wrote unit tests in make19:19
zyga-mbpfor make19:19
zyga-mbpijohnson for example, how to compile a library written in C++19:20
zyga-mbphttps://github.com/zyga/zmk/blob/master/examples/libhello-cpp/Test.mk19:20
zyga-mbpbut there's some complexity involved in making sure all combinations are covered19:20
ijohnsoninteresting I remember you mentioning zmk before19:20
zyga-mbpit's slowly growing19:21
zyga-mbpI paused all development while I was ill as working was hard as-is19:21
zyga-mbpanyway :)19:21
zyga-mbpi think bashcov is more interesting for us19:21
zyga-mbpijohnson (although to be fair, that was a smoke test for an example, unit tests are more complex as they try to cover all the features, some being optional)19:23
ijohnsonyeah bashcov seems very interesting in combination with our spread-shellcheck19:24
zyga-mbpfor spread task.yaml's the problem will also be the fact that it just streams a bunch of text and not let us trace much19:26
zyga-mbpbut we could find ways around that19:26
zyga-mbpwe could patch spread to generate something that mimics the tests tree19:26
zyga-mbpand has actual scripts for everything19:26
zyga-mbpthat source each other or what not19:26
zyga-mbpthen bashcov could trace the whole execution19:26
zyga-mbpplease read my post, play with the code, the idea came to me yesterday19:27
zyga-mbpand I implemented a working copy half an hour ago19:27
zyga-mbpI'm sure there's room for improvement19:27
zyga-mbp(bashcov handles ". foo.sh" sourcing today)19:27
zyga-mbptime to slack now19:28
* zyga-mbp goes away19:28
mupPR snapd#9177 opened: tests: remove support for ubuntu 19.10 from spread tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9177>20:32
mupPR snapd#9178 opened: secboot: document exported functions <Simple 😃> <Skip spread> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9178>21:07
mupPR snapcraft#3254 opened: tests: restrict colcon / ros2-foxy test to amd64 & arm64 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3254>22:33

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