mupPR snapd#9300 opened: boot: build bootchains data for sealing <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9300>01:22
mupPR snapd#9301 opened: tests/lib/cla_check.py: don't allow users.noreply.github.com commits to pass CLA <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9301>02:22
mupPR snapd#9273 closed: boot: mark successful with boot assets  <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9273>04:57
mupPR snapd#9298 closed: boot: represent boot chains, helpers for marshalling and equivalence checks <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9298>05:13
mvogood morning mborzecki05:15
mborzeckimvo: hey05:24
mborzeckineed to drive me daughter to school, back in a bit05:25
mvosure thing05:27
mupPR snapd#9301 closed: tests/lib/cla_check.py: don't allow users.noreply.github.com commits to pass CLA <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9301>07:03
pedronismvo: mborzecki: hi, should we have a chat in a bit?07:09
mborzeckispread job on 20.10 is required now?07:10
pedronismborzecki: I think mvo did that change07:11
mborzeckipedronis: sure, when do you want to have the chat?07:11
pedronisin 10 minutes?07:11
mborzeckiworks for me, mvo?07:13
mborzeckimerged master into https://github.com/snapcore/snapd/pull/9300 easier to see the actual changes07:15
mupPR #9300: boot: build bootchains data for sealing <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9300>07:15
pedronismborzecki: I'm joining the standup07:22
mvopedronis: hey, only now saw this message07:24
mvopedronis: joining07:24
zyga-kaverigood morning07:43
zyga-kaveriI'll get ready for the call with JJ07:43
zyga-kaverilast night I got stuck on task ordering weirdness07:43
zyga-kaveriI need to look at the code with fresh eyes07:44
zyga-kaverihow are core20 bits?07:44
mvozyga-kaveri: good morning07:54
mvozyga-kaveri: things are progressing07:54
zyga-kaverifrom the outside it looks like a lot of concentrated effort07:55
zyga-kaverihappy to chat later today if you have time07:55
mvomborzecki: I think you asked about ubuntu-20.10 as required earlier - it is now but if that is a problem I can disable that again08:08
pstolowskimvo: thanks for the comments under remove-many, was really simple change08:08
mborzeckimvo: it failed in https://github.com/snapcore/snapd/pull/9297 but I see it's green now after i pushed a merge from master there08:09
mupPR #9297: boot: add "rootdir" to baseBootenvSuite and use in tests <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9297>08:09
mvomborzecki: ta08:10
zyga-kaveriback from call08:13
zyga-kaverithis thing is making progress :)08:13
mupPR snapd#9237 closed: devicestate: enable cloud-init on uc20 for grade signed and secured <Complex> <Run nested> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9237>08:13
mupPR snapd#9297 closed: boot: add "rootdir" to baseBootenvSuite and use in tests <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9297>08:13
zyga-kaveriokay, onto exports08:14
mupPR snapd#9302 opened: tests: use `nested_exec` in core{20,}-early-config test <Run nested> <Simple 😃> <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9302>08:23
pedronismborzecki: mvo: proposed, https://github.com/snapcore/snapd/pull/930309:48
mupPR #9303: boot,secboot: switch to expose and use snapcore/secboot load event trees <Created by pedronis> <https://github.com/snapcore/snapd/pull/9303>09:48
mupPR snapd#9303 opened: boot,secboot: switch to expose and use snapcore/secboot load event trees <Created by pedronis> <https://github.com/snapcore/snapd/pull/9303>09:49
mvopstolowski: one small remark for 9294, thanks for this, looking really good09:51
* mvo has some barely controlled rage against nested tests currently09:51
pstolowskimvo: watch out, nested is dangerous for mental health09:52
mborzeckipedronis: thanks, i've opened the tweaks too: https://github.com/snapcore/snapd/pull/9304 (cc mvo)09:54
mupPR #9304: boot: tweak boot chains to support a list of kernel command lines, keep track of model and kernel boot file <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9304>09:54
mvopstolowski: yeah, I was wondering if I should play hockey tonight or not but I think I will just to get rid of this agression that is building up09:54
mvopstolowski: to be fair, a lot of it is shell09:55
pstolowskiyeah, one simple typo grants you 40 minutes of waiting for another run ;)09:57
pstolowskiand fun with quoting09:58
pedronismborzecki: thanks, I'll review it after lunch09:58
mvopstolowski: yeah, that's part of it. anyway, *rage*09:58
mvopstolowski: debugging it is also impossible, ps afx shows "sleep 1"09:59
mupPR snapd#9304 opened: boot: tweak boot chains to support a list of kernel command lines, keep track of model and kernel boot file <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9304>09:59
mvopstolowski: like why/where etc? *furryandrage*09:59
mvopstolowski: anyway, sorry, I will see that at least debugging can be improved a little bit09:59
zyga-kaverimvo: oh, what's up with nested?10:00
mvozyga-kaveri: some tests in there are broken10:00
mvozyga-kaveri: and it's unclear why and they are kind-of-important for our work :)10:00
zyga-kaveriI'm sorry this is frustrating10:00
zyga-kaverican I help?10:00
mvozyga-kaveri: maybe in some minutes, I plan to push some small tweaks10:01
mvozyga-kaveri: review/ideas about those will be great10:01
pstolowskimvo: updated #929410:01
mupPR #9294: o/snapstate: check available disk space in RemoveMany <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9294>10:01
mvopstolowski: \o/10:01
pstolowskiwe will probably need to think about --purge flag support with remove-many; with the above check the client will hint at --purge which cannot be applied to multiple snaps at once10:03
pstolowskinot super problematic but slightly confusing10:04
* mvo will note that qemu is a piece of magic10:36
zyga-kaverimvo: large piece10:37
zyga-kaverimvo: would the snapshot / restore feature help with nested tests perhaps?10:37
* zyga-kaveri doesn't understand TestEnableRunThrough10:37
mvozyga-kaveri: maybe but it's really more fundamental at this point10:37
mvozyga-kaveri: I mean, the nested vm is not creating a user right now for me10:38
mvozyga-kaveri: and afaict I have no way to debug this10:38
mvozyga-kaveri: so I need to collect some wood first to build a crafting table it seems10:38
zyga-kaverican you mount the image and look at logs?10:38
zyga-kaveriyou can use the virt tools package for that10:39
zyga-kaveriunless crypted10:39
mvozyga-kaveri: this is what I'm currently doing http://paste.ubuntu.com/p/ZkGtr2pMpb/10:40
mvozyga-kaveri: I could but I really want to have a better way, see the new -sertial option there10:40
mvozyga-kaveri: it started with qemu-nested not working for me and then I gradually crawled my way out10:41
zyga-kaveriI can see where the frustration is coming from :)10:41
zyga-kaverimvo: should sleep_reason echo the reason?10:42
mvozyga-kaveri: it could, I mostly did it for ps afx10:49
zyga-kaverimaybe I miunderstand but now the || part will always fail10:50
zyga-kaverias you run it in a subshell and give it function names10:50
* pstolowski lunch10:55
mvozyga-kaveri: it's just there so that a "ps afx" in the qemu shows why we wait. the first sleep xx will never fail so the right side of the || never runs10:59
pedronismborzecki: I'm not sure I understand your question in 9303, if next was always one element there would be no point in doing this11:01
pedronismborzecki: I answered in the PR11:07
mvonested.sh defines PARAM_SERIAL 3 times in the same way11:12
pedronismvo: after prepare.sh nested.sh is our largest shell file11:22
pedronisand prepare.sh has probably a simpler flow than nested.sh11:22
mvopedronis: yeah, did I mention I'm full of rage and furry?11:23
mvopedronis: anyway, I think there will be some good outcomes at least11:23
pedronisis uc20-recovery known to be flaky?11:27
pedronisor known to fail?11:27
pedronisit's failing in my PR11:27
mvopedronis: not know to me, let me look11:28
mvopedronis: this "2020-09-09T10:40:40.0118864Z retry: command sh -c test "$(wc -l < /tmp/mock-shutdown.calls)" = "2" keeps failing after 30 attempts" is a failure ijohnson  fixed recently in 9299 - it's not in master yet11:29
mborzeckipedronis: yeah, i was a bit confused by the tests, but it's clear now, suggested little tweaks to formatting that makes the nesting clearer11:38
pedronismborzecki: thx, I reviewed your PR11:43
mborzeckipedronis: thanks!11:44
mvoijohnson: an interessting observation - I am debugging a failed nested uc20 minimal smoke test right now and it looks like the /run/mnt/ubuntu-seed/data/etc/cloud.cfg.d/data.cfg did not get copied into the system, it's a bit hard to see why because we have no persistent journal right now. note that this is before merging your uc20 changes. anyway, I guess that is not much, I will keep digging11:50
pedronismborzecki: pushed your suggestions, please double check11:53
mborzeckipedronis: lgtm11:53
pedronismborzecki: should we chat about the next step?11:56
ijohnsonmvo yeah that would explain why the user didn't run12:00
mvoijohnson: anything I can/should debug while I'm inside the nested vm? if not I will re-run with persistent jounral enabled12:01
ijohnsonmvo I don't remember if I proposed the branch or not but I added a bit of code to make the journal persistent in nested VMs via the gadget.yanl defaults12:01
mvoijohnson: yeah, I just added the same bit :)12:01
mvoijohnson: well, don't know if it's the same12:01
mvoijohnson: but same goal12:01
ijohnsonmvo in this system do you see the disabled file in /etc/cloud ?12:02
mvoijohnson: yes12:02
mvoijohnson: and the timestamp is some seconds before my snapd log starts12:02
mvoijohnson: so I don't know what it did before :/12:02
ijohnsonYeah probably just need to re-run with persistent journal12:03
ijohnsonAfter breakfast I will propose that branch if I haven't already proposed it12:03
mvoijohnson: ok, only if it's no hassle for you. i have similar code already locally12:03
mvoijohnson: part of some bigger and slightly messier work12:04
mvoijohnson: that I will cleanup :)12:04
ijohnsonYeah I just checked I haven't proposed it yet, will do so when available this morning12:05
mvono rush, I rerun and get some lunch12:06
mborzeckipedronis: sry, yes, 1430 maybe? does not look like cmatsuoka is online yet12:08
pedronismborzecki: ok, works for me12:09
pedronismborzecki: going into the standup12:29
mupPR snapcraft#3281 closed: build providers: hide systemd setup for LXD <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3281>12:41
mvoijohnson, cachio just FYI, I'm poking at nested right now and this is my in progress stuff http://paste.ubuntu.com/p/6CTYJn3ZYs/14:00
mvoijohnson, cachio I will probably throw some away and hopefully push some things as their own PRs14:01
cachiomvo, nice, thanks14:02
mvocachio: i triggered adt for i386/focal14:04
cachiomvo, tx14:05
mupPR snapd#9302 closed: tests: use `nested_exec` in core{20,}-early-config test <Run nested> <Simple 😃> <⚠ Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9302>14:10
micahhi, i'm trying to run mattermost-desktop snap inside of an lxc container, but I get a weird error it seems related to snap-confine14:12
micahan strace shows this: execve("/snap/snapd/8790/usr/lib/snapd/snap-confine", ["/snap/snapd/8790/usr/lib/snapd/snap-confine", "--base", "core18", "snap.mattermost-desktop.mattermost-desktop", "/usr/lib/snapd/snap-exec", "mattermost-desktop"], 0xc4202a57c0 /* 38 vars */) = -1 EACCES (Permission denied)14:13
micahand it results in a segfault14:13
zyga-kaverimicah: can you please look at apparmor DENIED messages in journald?14:14
zyga-kaverimicah: usually dmesg | grep DENIED is a good start14:14
mupPR snapd#9305 opened: tests: fix nested to work with qemu and kvm <Created by mvo5> <https://github.com/snapcore/snapd/pull/9305>14:15
micahzyga-kaveri: i found these: https://paste.debian.net/1163177/14:17
zyga-kaverimicah: I think those are a bit over my head, definitely related to LXD's own apparmor profile14:19
zyga-kaveriwhat kind of setup is this? a debian host with lxd and a container that runs mattermost desktop with forwarded X?14:19
micahzyga-kaveri: debian host, running lxd with snap, and an ubuntu 20.4 container running mattermost desktop with forwarded X, yes14:20
zyga-kaverimicah: I think that may be a little bit beyond our test matrix14:21
zyga-kaverimicah: but the denial itself is related to lxd, maybe stgraber can help or delegate?14:21
zyga-kaverimaking tiny bit of progress by digging into fake backend14:27
ijohnsonthanks mvo14:37
* ijohnson is back now14:37
mvoijohnson: the gadget default is wrong (as you probably already noticed, fixed locally)14:37
ijohnsonyeah I like the bit about checking for a failed vm state immediately, I think that would make things die a lot quicker with some simple typos that can be rather frustrating :-)14:42
mvoijohnson: yeah14:45
mvoijohnson: I particularly like the change that I can telnet to the serial port of the nested qemu, qemu is really magic14:45
ijohnsonmvo: yes though that is less useful for spread runs via i.e. github actions where you don't get dropped to a debug shell14:46
ijohnsonmvo: I experimented with a pipe fd / tee solution where you would both get all of the serial output in a file for automated / non-interactive runs AND also still be able to login via serial somehow too if running an interactive debug shell, but I didn't spend enough time on it to make it all work properly unfortunately14:46
ijohnsonperhaps there's a clean way with qemu to tell it to send to multiple things at once, but I don't think there is when I looked14:47
pstolowskicachio: google-sru:ubuntu-16.04-64:tests/main/snap-run-gdbserver passed for me with release/2.4614:47
cachiopstolowski, yes14:48
pstolowskicachio: not sure if there is anything special about running these tests?14:48
cachioI'll show you how to run it14:48
cachiopstolowski, you need to use this env14:48
mborzeckipedronis: cmatsuoka: opened https://github.com/snapcore/snapd/pull/9306 with the helper14:49
mupPR #9306:  boot: helper for generating secboot load chains from a given boot asset sequence <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9306>14:49
pstolowskicachio: ah ok14:49
cachiopstolowski, https://paste.ubuntu.com/p/HJpXJ9QrCG/14:50
mupPR snapd#9306 opened:  boot: helper for generating secboot load chains from a given boot asset sequence <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9306>14:50
pstolowskicachio: thanks14:50
cachiopstolowski, yaw14:50
ijohnsonmvo: sorry can you clarify if you are running the qemu-nested:ubuntu-20.04-64:tests/nested/manual/minimal-smoke or qemu-nested:ubuntu-20.04-64:tests/core20/basic ?14:53
ijohnsonI forgot to ask which specific test you were debugging14:53
mvoijohnson: minimal-smoke14:58
ijohnsonack thanks14:59
mvoijohnson: I'm in the nested vm right now14:59
mvoijohnson: but still have no persistent log from the time of the install :/14:59
mvoijohnson: I have the /var/log/journal dir though14:59
mvoijohnson: and no data.cfg in /etc/cloud/cloud.cfg.d14:59
ijohnsonmvo: hmm how did you apply the journal persistence logging?14:59
mvoijohnson: via the gadget default, one sec, let me pastebin my latest diff15:00
mvoijohnson: this is on top of sergios PR 9284 (just to avoid duplicating fixes)15:00
mupPR #9284: tests: some fixes and improvements for nested execution <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9284>15:00
mvoijohnson: http://paste.ubuntu.com/p/p2NdDvHX9M/ - persistent log is in line 82pp15:01
ijohnsonmmm fair enough I used a heredoc, but that's neither here nor there15:02
mvoijohnson: well, the config apply did work15:02
mvoijohnson: I can see the dir15:02
ijohnsonmvo: did you confirm that the data.cfg file is in the right partition in the image and named correctly ?15:02
zyga-kaveriI've disabled more and more of the state engine and I still see auto-connect15:02
zyga-kaveriwith only the snap manager15:03
zyga-kaveriI need to break for PT soon but at some point things to disable will run out15:03
mvoijohnson: it's under /run/mnt/ubuntu-seed/data/etc/cloud/cloud.cfg.d/data.cfg15:03
ijohnsonk, looks correct15:03
mvoijohnson: so looks correct, snap model --assertion also give me a dangerous assertion so the copy should happen15:03
* ijohnson is still waiting to reproduce15:03
* cachio lunch15:03
ijohnsonmvo: can you pastebin logs from the previous boot ?15:04
mvoijohnson: however this is not master, so maybe I should merge in master to get your latest stuff15:04
ijohnsonerr the first boot I suppose15:04
ijohnsonmvo: probably not necessary to merge in master15:04
mvoijohnson: sure, I can try, it's layers of vms15:04
ijohnsonit's vms all the way down15:04
* ijohnson is a vm running a vm inside a vm on a vm15:04
* zyga-kaveri afk15:05
pstolowskimvo, cachio: re gdbserver test failure, usr/bin/gdbsever is there on 16.04. the error "cannot snap-exec: cannot use "gdbserver" command" suggests that snap-exec doesn't recognize --gdbserver15:09
pstolowskimvo: see snap-exec/main.go, the default case of findCommand15:10
mvopstolowski: oh, that's confusing, isn't that our snap-exec?15:10
mvopstolowski: or does it first need to land inside the core stable snap or something?15:11
cmatsuokamborzecki: thanks, will check after lunch15:11
pstolowskimvo: yeah i'm wondering if that means it's running old snap-exec. fwtw that code change was made 3 months ago15:11
pstolowskimvo: one sec, let me check something15:12
mborzeckineed to taxi the kids around for a bit, will check back in later15:13
mvomborzecki: good luck15:13
pstolowskimvo: so yeah, the core there is  16-  9804, release 2.45 didn't have "gdbserver" flag in snap-exec15:15
mvopstolowski: ok, mysery solved then15:16
pstolowskistrings over snap-exec confirms that15:16
mupPR snapd#9307 opened: interfaces/tee: add TEE/OPTEE interface <Needs security review> <Created by ogra1> <https://github.com/snapcore/snapd/pull/9307>15:25
pstolowskitests/main/searching strikes again (in #9305)15:46
mupPR #9305: tests: fix nested to work with qemu and kvm <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9305>15:46
mborzeckipedronis: updated 9306, will need a merge from master when you PR lands16:05
pedroniscmatsuoka: https://github.com/snapcore/snapd/pull/9306 needs a review, also we used bootloader.Role now16:37
mupPR #9306:  boot: helper for generating secboot load chains from a given boot asset sequence <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9306>16:37
cmatsuokapedronis: yes, I just noticed that, that was an interesting solution16:53
pedronisencoding/json does the right thing, though reading the docs is not very obvious16:54
pedronisI had to read the code to double check16:54
pedroniscmatsuoka: related to your comment, yes I think in a follow up we should now use bootloade constants for Role16:55
pedronisto avoid confusion16:55
ijohnsonpedronis: which pr's for resealing should I look at today17:02
ijohnsonI'm about to break for lunch but can start looking after I get back17:02
pedronisijohnson: we want to land my 9303 (that one has two reviews but tests are giving trouble)  https://github.com/snapcore/snapd/pull/9304 and https://github.com/snapcore/snapd/pull/930617:04
mupPR #9304: boot: tweak boot chains to support a list of kernel command lines, keep track of model and kernel boot file <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9304>17:04
mupPR #9306:  boot: helper for generating secboot load chains from a given boot asset sequence <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9306>17:04
pedronisijohnson: I'm dong a run to see if your uc20-recovery PR helps with 930317:05
* pedronis dinner17:07
pedronisijohnson: no, even with your PR merged uc20-recovery is failing on my PR but I'm not quite sure why, the files contains reboot requests17:25
ijohnsonpedronis: hmm ok let me have a look17:29
pedronisijohnson: I don't think the fix is completely right17:30
pedronis-r +10 reboot scheduled to update the system17:30
pedronisstop serial-getty@ttyS017:30
pedronisstop getty@tty117:30
pedronisis more than two lines17:30
pedronisbut won't match one of the patterns17:30
ijohnsonpedronis: right that's why afterwards we check for the two reboot lines we care about17:31
pedronisyes, but we might check too early17:31
ijohnsonah I see what you mean17:31
pedroniscan't we add some filtering to mock-shutdown itself17:31
ijohnsonmm, I suppose I could just put the retry's on checking the MATCH17:31
ijohnsonthat would work instead17:31
pedronisso tha we get only significative lines17:32
ijohnsonsure I can make it such that only lines for "-r ..." go to the file we grep for17:33
mupPR snapd#9308 opened: tests: allow root to connect to ubuntu core using a certificate <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9308>17:41
zyga-kaveriback from PT18:14
zyga-kaverifood and back to work18:14
ijohnsonpedronis: fixed #929918:16
mupPR #9299: tests/core/uc20-recovery: fix check for at least specific calls to mock-shutdown <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9299>18:16
* cachio -> kinesiologist18:25
pedronisijohnson: thx, reviewed18:33
pedroniscmatsuoka: ijohnson: so as I said, we should try to merge 9303 9304 9306, the two latter needs 2nd review, also merging 9299 if it passed uc20-recovery would be good18:37
mupPR snapcraft#3282 opened: v2 plugins: add catkin-tools plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/3282>18:37
ijohnsonpedronis: ok yes 9304 and 9306 are in my queue now18:38
cmatsuokapedronis: 9303 is failing on tests but it seems that it's not related to the changes there18:38
pedroniscmatsuoka: are you blocked atm? the next step is essentially reworking 9300 and 9287 on top of 9304 and 930618:38
cmatsuokapedronis: I'm using these changes in my staging branch but having them on master would be better18:39
pedroniscmatsuoka: yes, 9303 failure should be fixed by 9299, I will force merge when the test have finished18:39
* cmatsuoka checking 9304 now...18:40
pedronisbut yes, best would be landing them but we need to start from 930318:40
pedronistests have been pain today18:41
pedronisalso the store had/has some problems18:41
cmatsuokayes, I tried to re-run on 9303 a couple of times but they keep failing18:41
pedroniscmatsuoka: we should close #9278, right? is supersed by new logic and 9300 ?18:43
mupPR #9278: boot: seal using boot chains from bootloader <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9278>18:43
cmatsuokapedronis: yes, it has been obsoleted by the new PRs, we should close it18:43
mupPR snapd#9278 closed: boot: seal using boot chains from bootloader <UC20> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/9278>18:51
* cmatsuoka will make a short break18:55
pedronisI force merged 930319:06
mupPR snapd#9303 closed: boot,secboot: switch to expose and use snapcore/secboot load event trees <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9303>19:11
pedronisso arch seems to fail sometimes on google:arch-linux-64:tests/main/cgroup-tracking:root19:43
ijohnsonpedronis yes I've seen that a few times and mentioned it in the SU doc but I don't understand the error19:51
mupPR snapd#9304 closed: boot: tweak boot chains to support a list of kernel command lines, keep track of model and kernel boot file <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9304>19:56
pedronisijohnson: cmatsuoka: I merged 9304 ^ and I fixed conflicts in 930620:01
ijohnsonpedronis: ah should I just skip striaght to 9306 then ?20:03
cmatsuokapedronis: thanks! it will make things easier to reconcile here20:03
pedronisijohnson: yes20:07
pedronisijohnson: cmatsuoka: I made #9309 on top #9306, it's just a cleanup but likely conflict prone20:14
mupPR #9309: boot: be consistent using bootloader.Role* consts instead of strings <Cleanup :broom:> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9309>20:14
mupPR #9306:  boot: helper for generating secboot load chains from a given boot asset sequence <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9306>20:14
cmatsuokapedronis: ack, checking this one...20:15
mupPR snapd#9309 opened: boot: be consistent using bootloader.Role* consts instead of strings <Cleanup :broom:> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9309>20:16
pedroniscmatsuoka: it's related to your comment in the other one20:17
cmatsuokapedronis: ah, yes, I just checked the relevant commit. thanks.20:17
cmatsuokawhy are tests so slooooow today??20:32
=== jdstrand_ is now known as jdstrand
=== ahayzen_ is now known as ahayzen
pedronisijohnson: what channel did you use for core20 when built your image to test nested?20:38
ijohnsonpedronis: edge20:38
pedronisijohnson: afaict your fix https://github.com/snapcore/core20/pull/84/files is not in edge20:39
mupPR core20#84: static/writable-paths: use transition instead of none for /etc/cloud <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/core20/pull/84>20:39
ijohnson... it should be?20:39
ijohnsonpedronis: the fix for that is in edge20:40
ijohnsonpedronis: at least for revision 81920:40
ijohnsonI also double checked and the image built for the nested test here has the fix as well20:41
ijohnson(and the same revision of the core20 snap too)20:41
pedronisijohnson: mmh, notice that here https://github.com/snapcore/snapd/pull/9098 mimimal-smoke failed on 1820:46
mupPR #9098: tests: new organization for nested tests <Run nested> <Squash-merge> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>20:46
pedronisit was merged anyway20:46
ijohnsonpedronis: mmm also 16.04 failed on minimal-smoke too20:47
ijohnsonthis would confirm my theory that something in nested.sh is broken20:47
pedroniswhy did we merge that though? are they super flaky anyway?20:47
ijohnsonwell the nested tests in general are slightly flaky but there were just too many other fixes in that PR, in the future we should really be more careful to split up changes20:48
ijohnsonthe nested tests are just suffering from so much churn right now20:49
ijohnsonI'm now trying a fresh build with just snapd from that branch to see if the snapd snap is somehow broken from nested.sh now20:51
pedronisijohnson: this run worked https://github.com/snapcore/snapd/runs/1038225314 13 days ago20:53
pedronisthis one also workd: https://github.com/snapcore/snapd/runs/105296759920:55
pedronisalso this one: https://github.com/snapcore/snapd/runs/106730513820:56
pedronis6 days ago20:56
pedronisbut this from today failed https://github.com/snapcore/snapd/pull/930220:58
mupPR #9302: tests: use `nested_exec` in core{20,}-early-config test <Run nested> <Simple 😃> <⚠ Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9302>20:58
ijohnsonso yes if I just use the snapd snap that was produced for the nested run it fails20:58
ijohnsoni.e. I build my own image and boot it with my tools, and the only snap I replace is the snapd snap, then cloud-init is not run20:59
ijohnsonerr rather it is immediately disabled instead of importing from ubuntu-seed20:59
pedronisso is snapd code, not nested.sh ?20:59
pedronissome of the sysconfig changes?21:00
ijohnsonthe only changes are here https://pastebin.ubuntu.com/p/m9SvCkkmkM/21:01
ijohnsonit could be the sysconfig changes I suppose21:02
pedronisI notice we didn't run them with nested on21:02
ijohnsonyeah I guess I didn't figure that sysconfig changes would need nested runs :-(21:03
ijohnsontbh I think we should have had the uc20 tag also trigger nested tests too for all pr's21:03
ijohnsona bit late for that now though21:03
pedronisijohnson: I suspect https://github.com/snapcore/snapd/pull/9253/files21:07
mupPR #9253: sysconfig/cloudinit.go: add AllowCloudInit and use GadgetDir for cloud.conf <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9253>21:07
pedronisdo we set to true in the relevant places?21:07
pedronisthat PR wasn't setting it anywhere21:07
pedronisso I suspect it just turned it off?21:08
cmatsuokapedronis: 9306 tests finished with the usual fails21:08
cmatsuokapedronis: could you force-merge it too?21:08
ijohnsonpedronis: yeah I think you're right21:09
pedroniswe landed your last one, that use it sometimes but not sure we set it in all the places21:09
pedronisthis is a bit the risk of splitting things21:09
ijohnsonpedronis: ok, so I rebuilt snapd exe from master with my last PR merged and just replacing snapd binary in the spread snapd I extracted now cloud-init works21:10
ijohnsonso theoretically it should have been broken by the first PR's landed, then fixed with the last PR that was merged21:10
ijohnsonalso of interest is the fact that mvo was debugging things based on Sergio's PR which does not have the master merge from my final PR21:10
pedronisijohnson: so the question is, to be have only one place right calling the relevant function?21:10
ijohnsonyes we only have one place calling the sysconfig function21:10
ijohnsonerr to be more precise21:11
ijohnsonwe set sysconfig.Options for cloud-init in one place21:11
ijohnsonand on master that is correct21:11
ijohnsonso I think if I trigger a run of this on master it should pass actually21:11
ijohnsonI need to go pick up my car though, so I will trigger a run on master to see what happens21:11
ijohnsonmaybe it passes21:11
pedroniscmatsuoka: I hoped ijohnson would also look at 930621:12
ijohnsonpedronis: cmatsuoka: yes sorry I was midway through a review and got sidetracked with nested tests21:12
ijohnsonI will have to finish my review in a bit like an hour or so from now though21:13
* ijohnson afk little bit21:13
* zyga-kaveri EODs21:13
zyga-kaverigood night!21:13
pedronisijohnson: cmatsuoka: I can land it and we apply feedback after the fact (it does have two +1)21:13
cmatsuokapedronis: i would be ok with that21:14
pedroniscmatsuoka: ijohnson: done21:20
cmatsuokapedronis: thanks21:21
mupPR snapd#9306 closed:  boot: helper for generating secboot load chains from a given boot asset sequence <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9306>21:22
pedroniscmatsuoka: I merged #9309 as well (it was just replacing strings in tests anyway) and had your +121:29
mupPR #9309: boot: be consistent using bootloader.Role* consts instead of strings <Cleanup :broom:> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9309>21:29
pedroniscmatsuoka: so master should have all the bits now that you need21:30
cmatsuokapedronis: yes, I'm running an integrated test with load chains now21:30
mupPR snapd#9309 closed: boot: be consistent using bootloader.Role* consts instead of strings <Cleanup :broom:> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9309>21:32
mupPR snapcraft#3282 closed: v2 plugins: add catkin-tools plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3282>22:53

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