[05:32] morning [06:01] PR snapd#8893 closed: osutil/disks: refactor diskFromMountPointImpl a bit [06:20] Hey [06:20] Not going to be around today [06:20] Please relay to mvo that the fix is ready [06:20] And needs reviews [06:20] That is 8881 [06:46] zyga: mvo is off today and on monday [06:46] I see [06:46] I think jamie will +1 it [06:46] so it needs 2nd review [06:46] zyga: jdstrand already did, i can apply the little tweaks he suggested [06:47] oh, super [06:47] I didn't check [07:01] morning [07:13] pstolowski: hey [07:14] pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/8455 ? [07:14] PR #8455: tests/lib/cla_check: expect explicit commit range [07:14] mborzecki: hi! sure [07:15] thanks! [07:23] hello [07:24] hi pedronis [07:28] pstolowski: mborzecki: when you have a moment a re-review of #8702 would be great, I pushed some changes and added a spread test to it [07:28] PR #8702: overlord/configstate: add system.kernel.printk.console-loglevel option [07:28] ack [07:29] pedronis: sure [07:51] PR snapd#8455 closed: tests/lib/cla_check: expect explicit commit range [07:57] pstolowski: you remember at some point we had to snap.Info.Type -> snap.Info.GetType ? [07:58] to make a change safely [07:59] pedronis: yes.. we wanted to avoid surprises with go silently accepting function instead of struct member [08:00] pstolowski: yes, now that we are down to 50 PRs it might be time to finally undo that, I'll work on this, super mechanical PR but need to land a bit quickly [08:02] pedronis: ok, shouldn't be too annoying hopefully [08:02] pstolowski: any of your servies PRs need a 2nd review? [08:03] mborzecki: #8991 only atm, thanks [08:26] PR snapd#8894 opened: many: rename back snap.Info.GetType to Type [08:26] pstolowski: mborzecki ^ [08:27] thank you [08:33] btw. has anyone switched to the new github ui? [08:33] yeah, it's surprising go is happy with "func (s *Info) Type() Type {.." ;) [08:38] mborzecki: I get 500s if I try [08:39] or maybe I'm just getting 500s right now [08:49] now thery status says there are issues [08:49] mborzecki: pstolowski: is github working for you atm? [08:50] pedronis: yes. got 500 once, then work [08:50] *works [08:51] ok, it 500s quite consistenly here [08:53] hmm [08:54] https://www.githubstatus.com/ [09:51] PR snapd#8895 opened: tests: mock servicestate in api tests to avoid systemctl checks (6/8) [09:52] pedronis: ^ [10:04] hmm got FAIL: cmd_sign_build_test.go:108: SnapSignBuildSuite.TestSignBuildWorksDevelGrade [10:04] "cannot sign assertion: cannot sign assertion: bad GPG produced signature: it does not verify: [10:09] pstolowski: we are getting those sometimes, I haven't had a chance to dig, or anybody else afaik so far [10:09] i see. couldn't repro locally [10:24] and another thunderstorm [10:24] heh, summer weather [10:26] mborzecki: #8895 needs a 2nd review if you have a moment [10:26] PR #8895: tests: mock servicestate in api tests to avoid systemctl checks (6/8) [10:27] pstolowski: looking at 8702, then 8891, after that 8895 :) [10:28] thanks [10:36] * pstolowski lunch [11:03] pedronis: have you tried systemd-sysctl --prefix .. --prefix .. on xenial? [11:04] afaic the spread test executes the call with just one --prefix [11:05] * mborzecki spins up a xenial node [11:05] mborzecki: no, I straced it only on 20 [11:11] pedronis: and it works there too [11:11] mborzecki: good, thanks for thinking about this [11:11] I suppose we could have done multiple calls if it didn't work [11:13] yeah, but we're good so meh, one call is fine [11:13] yet another thunderstorm, 2nd today, looking at weather radars there's 2 more coming :/ [11:25] mborzecki: seems we have archive issues with fedora ? [11:26] that's unfortunate [11:27] maybe dl.fedoraproject.org is hosted on some of the hosts that are being moved [11:27] mborzecki: see https://github.com/snapcore/snapd/pull/8895/checks?check_run_id=787745417 [11:27] PR #8895: tests: mock servicestate in api tests to avoid systemctl checks (6/8) [11:29] pedronis: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/MAGJJTVR777ARZ4TVMBQQ3YK6RC7ODE6/ [11:30] pedronis: can you switch fedora-* to unstable for now? [11:30] i know mvo can, but i'm not sure anyone else has the permissions to do that [11:36] I don't think I can [11:59] mborzecki: we can turn them manual as suppose [11:59] or ping him on tg [12:03] 3rd thunderstorm [12:48] pstolowski: left a comment in #8891 [12:48] PR #8891: o/servicestate: add updateSnapstateServices helper (5/8) [12:49] ty [14:12] PR snapd#8894 closed: many: rename back snap.Info.GetType to Type [15:10] * cachio lunch [15:55] jdstrand: [15:55] any ideas about disconnect failing "- Disconnect gtk3-hello:gnome-3-28-1804 from gnome-3-28-1804:gnome-3-28-1804 (cannot update mount namespace of snap "gtk3-hello": cannot update preserved namespace of snap "gtk3-hello": cannot update snap namespace: cannot create writable mimic over "/usr/share": no such file or directory)" [15:55] that is on https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-snappy-dev-snapcraft-daily/bionic/amd64/s/snapcraft/20200619_061338_41454@/log.gz [16:25] sergiusens: otoh no. I recommend filing a bug with steps to reproduce. it looks a bit curious since a) /usr/share should be in the snap's base runtime and b) not sure why in the snap disconnect it is *creating* a writable mimic (I would think that would happen during connect, not disconnect; but this may not be an error depending on how it is unraveling the mount namespace as part of disconnect) [16:28] jdstrand: this only happens on autopkgtest infra [16:38] sergiusens: this is a normal snap install, not snap try? [16:38] (it shouldn't matter, but curious) [17:58] jdstrand: yes, normal install it is [18:00] jdstrand: this is what we do https://github.com/snapcore/snapcraft/blob/master/tests/spread/extensions/gnome-3-28/task.yaml and this works just fine on spread/google [18:23] cachio: hi, are you aware of this error? https://github.com/snapcore/snapd/pull/8824/checks?check_run_id=788996098 [18:23] PR #8824: many: move encryption and installer from snap-boostrap to gadget [18:24] cmatsuoka: that looks like a result of mborzecki's CLA fix from this morning [18:24] cmatsuoka: have you merged master to this PR ? [18:24] cmatsuoka, checking [18:24] ijohnson: hummm I think I didn't, let's do it [18:28] ijohnson, cachio: hmm, I have a different cla error now, but that one is gone at least :) [18:28] cmatsuoka: what's the new one :-) ? [18:28] now it's verifying the CLA for all email addresses in my launchpad account, it seems [18:29] :-/ [18:29] I'm doing it again just be sure it's deterministic [18:30] so this is what I'm getting now: https://github.com/snapcore/snapd/pull/8824/checks?check_run_id=789109680 [18:30] PR #8824: many: move encryption and installer from snap-boostrap to gadget [18:32] cmatsuoka: which email is configured as your contact address? [18:32] the canonical one [18:32] hmm yeah me too [18:32] let me see if the CLA check fails for me now too [18:33] I think, /me double checks [18:35] cmatsuoka: ahh seems I can't test it because both of my email addresses are already on master [18:35] hmm, git shortlog -se only lists my canonical email [18:35] which also implies I may have been a bit sloppy with some previous commits using my personal email ... [18:35] * cmatsuoka investigates how cla_check.py works [18:35] cmatsuoka: for reference this is what happened for me https://github.com/snapcore/snapd/pull/8896/checks?check_run_id=789123625 [18:35] PR #8896: README.md: make changes to test CLA checker [18:38] PR snapd#8896 opened: README.md: make changes to test CLA checker [18:52] PR snapcraft#3180 opened: build providers: nice message on bad base [18:52] cmatsuoka: did you ever figure anything out ? [18:53] ijohnson, cachio: this is interesting: if I run it locally, I get: [18:53] cmatsuoka: if it's not working anymore I can submit a PR reverting mborzecki's PR so that you can land things [18:53] Need to check 1 emails: [18:53] ✓ claudio.matsuoka@canonical.com already on master [18:53] but in the tests it lists 2 addresses, for some reason [18:53] let me check what that PR changed... [18:54] humm, unless a regular expression is failing there... [18:56] no, it can't be a regexp failure :| [18:56] I'll check the PR [19:02] ijohnson: well it's not urgent, I'll check that with maciek on Monday [19:02] cmatsuoka: ok [19:02] PR snapcraft#3181 opened: cli: don't warn about --target-arch if target_arch is None [19:21] cachio: it seems that git shortlog -se master..HEAD in the test machine is listing more email addresses than it used to do, and more than what I see locally in the same branch. Does it make any sense to you? [19:22] cachio: Did we change anything in the repository clone process, or the git version, or something like that? [19:23] cmatsuoka: I see the same as you, 5 commits by your canonical email [19:23] on my machine locally with your branch that is [19:23] that's very odd [19:23] I mean, not what you're seeing, but what the test is seeing [19:25] cmatsuoka, checking [19:44] PR snapd#8896 closed: README.md: make changes to test CLA checker [19:46] cmatsuoka, dont see any change, not sure why it is failing [20:32] PR snapcraft#3181 closed: cli: don't warn about --target-arch if target_arch is None [20:32] PR snapcraft#3182 opened: build providers: improve warning for unknown base [20:36] cmatsuoka, hi [20:36] cmatsuoka, testing the nested lib I see secboot_tpm.go:392: TPM provisioning error: the TPM is in DA lockout mode [20:36] any idea why it could be happening? [21:13] PR snapcraft#3180 closed: build providers: nice message on bad base [21:41] cachio: no idea, it seems very weird [21:45] cachio: Re: TPM error message: let me see here what could be happening [21:45] cachio: is it happening in a normal test that used to work before, or is it a new test? [21:50] cachio: our number of tries for DA is set to 32, it shouldn't lock that easily [21:53] I am starting a vm using the swtpm-mvo snap [21:53] in my machine [21:54] cmatsuoka, [21:54] cachio: so is it a new installation? [21:54] cmatsuoka, yes [21:54] cachio: are you clearing the tpm? [21:54] cmatsuoka, no [21:54] should I ? [21:55] cachio: in a new installation yes, but if you're rebooting an existing system, no [21:55] cachio: to clear it delete /var/snap/swtpm-mvo/current/tpm2-00.permall [21:58] PR snapcraft#3183 opened: static: prepare for update to black 19.10b0 [21:58] cmatsuoka, I'll try that [21:58] thnaks [21:59] cachio: yaw, if the problem persists we can investigate more [22:02] cmatsuoka, sure, thanks [22:03] PR snapcraft#3182 closed: build providers: improve warning for unknown base [23:09] PR snapd#8897 opened: tests: trying to debug the weird cla problem <⛔ Blocked>