[00:40] PR snapd#8195 opened: tests/lib/prepare.sh: simplify, combine code paths [02:26] PR snapcraft#2953 opened: meta: remove remaining `__dict__` and key list usage in snap [06:04] PR snapd#8189 closed: seed,cmd/snap-bootstrap: introduce seed.Snap.EssentialType, simplify bootstrap code [06:05] PR snapd#8183 closed: tests: remove tmp dir for snap not-test-snapd-sh on security-private-tmp test [06:17] PR snapd#8140 closed: tests: enable more tests for UC20/UC18 [06:19] PR snapd#8186 closed: run-checks: SKIP_GMFMT really skips formatting checks [06:22] PR snapd#8085 closed: [RFC] netutil: add default gateway monitor [06:30] morning [06:30] mborzecki: good morning [06:32] PR snapd#8196 opened: client: add "Resume" to DownloadOptions and new test [06:33] PR snapd#8188 closed: spread.yaml: make qemu ubuntu-core-20-64 use ubuntu-20.04-64 [06:33] mvo: hey! so PRs are finally green :) [06:35] mborzecki: yes, it's quite nice, if we push a bit we could go below 50 today [06:35] PR snapd#8081 closed: tests/main/user-session-env: add test verifying environment variables inside the user session [06:42] hmm can't push an update to #8169 [06:42] PR #8169: tests/many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests [06:43] looks like ian didn't tick allow edits from maintainers box [06:45] mborzecki: meh, a shame [06:45] PR snapd#8195 closed: tests/lib/prepare.sh: simplify, combine code paths [06:51] PR snapd#8197 opened: snap: refacot code in `snap download` to prepare for snap downloads [07:02] PR snapd#7707 closed: snap: add TestDownloadDirectStoreHappy test [07:32] could someone restart https://travis-ci.org/snapcore/snapd/builds/655225016 for me? It looks like it failed on a timeout talking to github.com [07:46] jamesh: sure [07:46] mborzecki: thanks [07:47] jamesh: looks like it's already restarted [07:47] Dobę [07:47] Done even [07:47] I wonder how hard it'd be to cut Travis out of the loop completely [07:48] the main feature missing from github actions is the option to make secrets available to PRs [07:48] jamesh: oh? Are you sure? [07:48] I saw secrets used in some actions I looked at [07:49] zyga: yeah. Secrets come up blank if the the job is initiated by someone without write access to the repository [07:49] Aaaah [07:49] I see [07:49] I guess that is only expected [07:55] in contrast, anyone can submit a PR that changes .travis.yml so that their test run will exfiltrate the secrets [08:02] morning [08:02] pstolowski: hey [08:03] hey pstolowski [08:03] pstolowski: I saw some of these in travis: https://paste.ubuntu.com/p/3jdZTp7QPd/ [08:04] damn serial terminals [08:04] mvo: is this with latest master? [08:05] pstolowski: I think so, let me double check [08:05] mvo: pstolowski: i saw this locally today when merging master to ijohnson's branch [08:07] mborzecki: ah, ok. that's annoying :(. i'll intensify my efforts on the followup then, i was hoping the last bump of the sleep time was enough as a temporary workaround [08:08] pstolowski: we could bump again by 1s or so [08:08] pstolowski: until we have the fix [08:09] mvo: I noticed that, and had it happen locally. I needed to up the wait to 3 seconds [08:09] wasn't sure if it was something I'd introduced [08:11] jamesh: it's a recent change from pstolowski [08:11] jamesh: 3s each? anything unusal about your machine? particularly slow or fast? [08:12] okay, i can propose one more bump, and in the meantime will continue working on the better fix [08:13] mvo: just that one test. [08:14] mvo: I tried bumping in smaller increments locally, but had no idea what it was doing with the time [08:15] the system is not particularly fast [08:16] jamesh: thank you for letting us know [08:21] PR snapd#8198 opened: o/tests: bump TestEnsureLoopPruneAbortsOld sleep time <⚠ Critical> [08:25] Sleep bump a day keeps those pesky races at bay [08:27] PR snapd#7146 closed: [sketch] UC20: cmd/snap-verify: sketch of snap-verify <⛔ Blocked> [08:30] Is it true Ubuntu ships chromium or chrome as Snap soon/by default or something along the lines? [08:33] kbroulik: dunno, is that announced somewhere? [08:34] https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-transition I think this [08:35] This seems like a deb is migrating to a snap, is that what you meant? [08:35] yeah, sorry, my wording wasn't clear [08:35] That is not the same as ship by default (preinstall) [08:35] "is it true Ubuntu ships chromium as a snap instead of a deb?" :) [08:35] right [08:36] Given that post it would seem so [08:36] hm maybe I should try it first and see if it breaks my project :) [08:48] PR snapd#8199 opened: tests: enable snapd-failover on uc20 [08:52] mborzecki: for your recovery-chooser pr - you need to install it in the debian packaging to some place [08:52] mborzecki: check e.g. debian/snapd.install [08:53] mvo: it's already added there [08:53] hmmm [08:53] uhh 14.04 [08:55] mborzecki: was just looking over the recent failure in spread, not really looking closely [08:56] ok so yeah I tried chromium snap and as I feared: it breaks plasma-browser-integration as it cannot find the native host :/ [08:59] interestingly it does have a whitelist for /etc/chromium which should allow this [09:06] ah. ok, so chromium snap also breaks gnome chrome shell. so the whitelist doesnt actually work [09:06] https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1741074 ok, is known. thanks anyway :) [09:06] Bug #1741074: [snap] chrome-gnome-shell extension fails to detect native host connector [09:41] mvo: I wonder if master will be red by Friday [09:44] zyga: mh, why? [09:45] zyga: it looks mostly green right now [09:45] mvo: that prune thing [09:45] mvo: feels like a deeper problem [09:47] zyga: no worries, pawel is working on a better version of this test === pedronis_ is now known as pedronis [10:17] PR snapd#8200 opened: [RFC] cmd/snap-chooser-ui-demo: a demo of recovery chooser UI [10:17] zyga: #7219 was force pushed a bunch of times, that is not great [10:17] mvo: the UI demo bit ^^ [10:17] PR #7219: devicestate/firstboot: check for missing bases early [10:18] heh, I meant #7129 [10:18] PR #7129: userd: allow setting default-url-scheme-handler <⛔ Blocked> [10:18] unfortunately rebasing onto master was required and that requires a force [10:18] this has been open a looong time heh [10:18] pedronis: yeah, I noticed, I just +1 the fact that the contributor has not lost interest [10:19] jwheare: well, it means now it needs a review by me, even it got a lot of +1s already [10:19] it looks like the entire history is kept, just rebased [10:19] damn, github ui popup when you start entering # is so confusing and buggy [10:20] pedronis: can you delegate that review to others? [10:20] zyga: maybe [10:20] I still need to understand what the PR does either way [10:20] I planned to do that in any case [10:21] also, as was mentioned in the comments, i was iterating yesterday just to force sloow test reruns, often including white space changes, which were useless. during that time there were some comments before i had finished, and i squashed at the end. the squashed part is clearly marked out [10:22] I had a look at this originally, the key is the {Check,Get,Set}Sub API - it's a part of the xdg-settings system https://portland.freedesktop.org/doc/xdg-settings.html [10:22] the rest is glue to our stack [10:22] pedronis: ^ [10:22] I marked it for me, hopefully I can decide something about it still this week [10:24] pedronis: perhaps github UI has improved as the rebase did not break the flow of the comments [10:24] it seems it has [10:29] zyga: also it should probably not go in 2.44, we are too close to wanting to cut it [10:29] and it's already full of things [10:29] yeah, the comments stay and are marked as outdated, you can also click on the rebase change and see the diff [10:30] mborzecki: nice! [10:31] pedronis: it's not my decision, I would probably let it in as it's been there for a while and I'm not sure how getting it in at the next cycle will help - it probably won't be tested by anyone apart from the currently, single user interested in it (as in single snap) [10:31] time to put all the recover bits back together again [10:31] zyga: if nothing else it changes spread tests, that's reason enough not to merge just before cutting [10:32] PR snapd#8194 closed: o/devicestate: unset recovery_system when done seeding [10:41] zyga: I looked a bit, there are actually issues with the code [10:42] pedronis: I'll check your review [10:42] zyga: I haven't reviewe, I'm just skimming, but saw a place where it could panic for example [10:44] pedronis: on SplitN? [10:44] yes for example [10:44] also why the cast to string [10:46] on checkOutput? bytes / strings [10:46] that was in the original code [10:46] no, there's SplitN(string(thing)... but thing is already a string [10:46] anyway it needs clearly another review pass and checking for coverage [10:46] sorry [10:47] https://github.com/snapcore/snapd/blob/master/usersession/userd/settings.go#L168 [10:50] PR snapd#8201 opened: [WIP,RFC] Mock prune ticker in overlord tests to reduce wait times [10:52] jwheare: different assumptions, but yes that code is fragile too, but that code doesn't even assume there's a path wher the 2nd part is not there [10:53] probably down to me copy/pasting existing code to a different place. well spotted [10:53] the string bit is needed because output is []byte there [10:53] yeah [10:54] * zyga straces systemd-run to see why it hangs [10:54] good old 18.04 [10:54] everything works [10:54] anyway, I'll try to give this some attention still this week (next week we are at a sprint), but no promises, my own queue is long atm [10:54] extend tests to all systems [10:54] 16.04 shows it's rusty fangs [10:55] pedronis: there is no rush, more eyes are always good [10:55] i have to say i lost a lot of time to that "not" command [10:56] "why is this erroring when i test this on some dummy bash code locally" [10:57] also trying to work out what's happening in failing tests that check stderr output by redirecting to a file when set -x prints to stderr too is fun [10:58] PR snapd#8202 opened: cmd/snap-bootstrap,seed: verify only in-play snaps [10:58] 90% of this PR was probably test wrangling heh [10:59] mvo: mborzecki: #8202 should speed up snap-bootstrap a bit [10:59] PR #8202: cmd/snap-bootstrap,seed: verify only in-play snaps [11:04] so I guess I have a solution for the systemd-run getting stuck [11:04] it changes the usability a little but not by much, at least for testing [11:05] pstolowski: hi, should I look at #8201, or not yet? [11:05] PR #8201: [WIP,RFC] Mock prune ticker in overlord tests to reduce wait times [11:05] pedronis: let's see if it passes first, i'll re-run it a few times [11:06] ok [11:08] fun on arm64 it seems http://paste.ubuntu.com/p/Q7CMcqRK5T [11:08] * mvo retries the ppa build where this happend [11:09] mvo: that's the new stopper code? [11:09] yes [11:09] yes [11:10] maybe want to see my simple epoll code instead [11:10] though it's kind of close to release [11:10] so dunno [11:10] lookng now [11:10] maybe just more locking / if nil things [11:13] zyga: yeah, looks like the timeout is nil for some reason [11:14] pedronis: cool, let me take a look [11:16] PR snapd#8192 closed: tests: add more debug output to the snapd-failure handling [11:17] mborzecki sorry not sure why the box wasn't ticked on 8169 but it should be good now [11:18] ijohnson: cool, let me merge again and push [11:18] mvo: ah, you cannot pass nil for timeout on arm64 [11:19] pedronis: interessting, shall I push a fix or will you? [11:19] pedronis: breaks the arm64 builds right now [11:20] mvo: yes, but it's a bit unclear what the fix should be, null means don't timeout [11:21] 0 means don't even try [11:23] mvo: this is fixed in newer versions of go :/ [11:23] pedronis: oh no [11:23] pedronis: we could workaround with timeout.Sec: 999999 [11:24] mvo: perhaps the man page is relevant [11:24] pedronis: fugly but would probably be ok? [11:24] I didn't read the code so not sure if that's the culprit [11:24] https://www.irccloud.com/pastebin/zFnzXT9r/ [11:24] mvo: we probably should workaround but setting everything to the max but only on arm64 [11:24] pedronis: +1 [11:24] pedronis: I can prepare a PR [11:24] zyga: the panic points to a place and the place is reading timeout [11:25] mborzecki did you see my typo in the PR too? Seems the spread tests didn't run due to my typo in that PR [11:25] it's fixed in newer go [11:25] pedronis: I see [11:25] see the if at line 90 here: https://golang.org/src/syscall/syscall_linux_arm64.go [11:25] older go don't have it [11:25] * pedronis lunch [11:26] uh, I see [11:26] sucks, bug in the wrapper [11:26] yep [11:27] ijohnson: yeah, i'm looking and shellcheck, it's unhappy about some things, also one of the warnings looks like a bug in shellcheck ;) [11:28] :-( [11:29] ijohnson: hahah https://paste.ubuntu.com/p/yb6d9NMN3B/ [11:30] Ahh [11:44] PR snapd#8203 opened: netlink: fix panic on arm64 with the new rawsockstop code [11:45] mvo: in theory if we timeout the subsquent read will give us EWOULDBLOCK or similar and we retry, so just having some kind of long timeout should work [11:46] mvo: not sure if we can test somehow that scenario though [11:46] pedronis: I pushed the workaround with int64 seconds timeout [11:48] ijohnson: pushed [11:48] pedronis: it's enough time I think, still worth double checking if select behaves sanely for such a huge value [11:49] mvo: or we don't make it huge but as I said check that the udev code does the right thing if select timeouts [11:49] it should (in theory) [11:50] pedronis: I have no strong opinion either way, I pushed the simplest thing but I can iterate on this [11:51] ijohnson: i should probably file an issue with shellcheck about the for loop [11:57] * zyga stops banging the head against the wall and breaks for a quick snack [12:00] PR snapd#8204 opened: data/systemd: improve the description [12:04] mvo: I'll try something test-wise on top of your PR in a bit [12:05] pedronis: sure [12:07] ijohnson: https://github.com/koalaman/shellcheck/issues/1847 heh [12:07] back [12:08] ijohnson: wouldn't be surprised if _ is an actual variable getting assigned to at this point [12:08] mborzecki: what were you expecting? [12:08] oh [12:08] actually [12:08] zyga: nothing ;) [12:08] I'm surprised now [12:08] mborzecki: bash and dash disagree [12:08] mborzecki: _ is ok in dash [12:08] mborzecki: and a no-op in bash [12:09] I suspect it is documented somewhere [12:10] zyga: fwiw it's flagged for -s bash too [12:40] mvo: not for 2.44 but we should consider using x/sys/unix for a our few syscall needs maybe [12:43] mvo: there's a missing import in _other.go [12:51] PR snapd#8199 closed: tests: enable snapd-failover on uc20 [12:55] pedronis: probably worth mentioning the force push thing in the contribution guide btw, since different projects have different norms https://github.com/snapcore/snapd/blob/master/CONTRIBUTING.md [13:04] wl [13:04] sorry, [13:04] thunder :) [13:04] winter is over [13:07] and hail [13:08] mvo: pstolowski: I pushed a fix and one more test (at the cost of some changes) to #8203 [13:08] PR #8203: netlink: fix panic on arm64 with the new rawsockstop code [13:09] pedronis: ok, will rereview [13:10] * pstolowski lunch [13:11] zyga: nb, #8170 is ready for re-review [13:11] ack [13:11] PR #8170: snap-preseed: support for preseeding of snapd and core18 [13:11] looking [13:11] ty [13:14] heh, last minute changes are always a bad idead [13:16] mborzecki: what did you break? [13:16] ;) [13:17] zyga: heh little tweaks in the ui before opening the PR [13:17] ofc unit tests are passing ;) [13:33] PR snapd#8196 closed: client: add "Resume" to DownloadOptions and new test [13:55] pstolowski: reviewed [13:56] zyga: thanks! [13:56] pstolowski: thank you, I just did the last review :) [14:37] PR snapd#8205 opened: tests: just remove user when the system is not managed on create-user-2 test [14:41] pstolowski: we should bring barylki [14:41] they will function both as sweets [14:41] hand sanitizers [14:41] and throat sanitizers [14:42] PR snapd#8204 closed: data/systemd: improve the description [14:42] I'll take a break to take the dog out [14:42] brb [14:45] mvo: it's a minor thing but it might make sense to backport 8204 to 2.44 if it's what is going into 20.04 [14:45] and is not too annoying [14:45] pedronis: +1 [14:47] PR snapd#8206 opened: travis.yml: run unit tests on arm64 as well [14:50] zyga: i'm actually thinking about some 'stronger' sweets this time ;) [14:53] mvo: for the race with mount units: https://paste.ubuntu.com/p/z7ZpDRmKcW/ [14:54] back [14:54] my phone just got an ... ubuntu touch update [14:54] mborzecki: oh, nice! [14:55] yeah [14:59] zyga: woot!? [14:59] ubuports? [15:01] yes [15:01] booting now [15:05] pstolowski: heh, there's a new UI [15:06] * cachio lunch [15:13] mborzecki: hmm seems the merge went a bit awry on 8169, okay if I push up some changes or are you working on it ? [15:17] zyga: show me a screenshot pls [15:18] how do I make screenshots on core [15:18] er [15:18] phone [15:20] it's pretty, I"ll bring it [15:20] you'll see :) [15:20] back to services [15:23] mborzecki: well I'll just push anyways [15:30] zyga: mvo: at this point #7825 targets 2.45, right? [15:30] PR #7825: many: use transient scope for tracking apps and hooks [15:31] pedronis: yes [15:31] pedronis: there's one real issue that needs fixing [15:31] pedronis: and tests to cover it [15:31] it's fine, changing the milestone [15:31] pedronis: it's not critical (not desktop) but needs to be debugged all the way because it's critical path [15:31] pedronis: +1 [15:32] ijohnson: yeah, please do, there were 2 merges, both had conflicts because of related things landing [15:33] mborzecki: ack [15:46] pedronis: I reviewed your essential snaps PR, thanks for that [15:46] pedronis: if you could quick take a look at my question on https://github.com/snapcore/snapd/pull/8185#issuecomment-591193478 that would be appreciated thanks [15:46] PR #8185: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs [15:50] ijohnson: thank you [15:50] ijohnson: looking (was having a different chat somewhere else) [15:50] pstolowski: should I re-review #8170, seems to have changed a bit since I last reviewed [15:50] PR #8170: snap-preseed: support for preseeding of snapd and core18 [15:50] pedronis: thanks [15:51] ijohnson: ah, that, we always keep 2 or 3 older revisions per snap, so it's normal that the unpacked assets for them would stay around, you need to install 4 kernels before you see assets go away I think [15:51] keep 2 or 3 XoldX revisions [15:51] pedronis: ok, not sure if we wanted to keep the assets around on ubuntu-boot [15:52] looks like the unit test is correct then and I'll just remove that last check [15:52] ijohnson: that's the logic as is right now, we might want to change it but needs a larger discussion [15:52] ijohnson: i think the changes are very small, not necessary [15:52] pstolowski: ok thanks for confirming [15:53] ijohnson: np, thanks for asking! [15:54] ijohnson: that's what we do on uboot devices atm for UC16 UC18 [15:54] pedronis: makes sense. today I will work on cross-checking the signing keys in the kernel.efi we booted with in snap-bootstrap vs the ones in the current_kernels kernel snaps and open the other boot robustness PR then [15:55] thx [15:55] ijohnson: ping me if you need input on something [15:55] sure [16:06] I'll grab some food, family's back [16:15] pstolowski: I reviewed #8190, looks like what I expected, some comments on details [16:15] PR #8190: overlord, taskrunner: exit on task/ensure error when preseeding [16:15] pedronis: thanks! i forgot about state lock [16:16] pedronis: nb #8170 is probably close if you can re-review [16:16] PR #8170: snap-preseed: support for preseeding of snapd and core18 [16:18] pstolowski: I don't think #8170 needs a review by me, I think you address my main point, right? [16:18] PR #8170: snap-preseed: support for preseeding of snapd and core18 [16:18] *addressed [16:18] pedronis: that's fine, i wasn't sure if that was all. thanks [16:19] pstolowski: actually, I am a bit confused, I thought preseeding worked with core 16 ? [16:19] it seems you are blocking that too? [16:19] or am I misreading the code [16:19] or are you being careful because there is not spread test yet? [16:23] pstolowski: to be clear I'm fine, we don't have a strong use case for core atm, especially core 16, just trying to understand [16:26] pedronis: my intent was to allow only classic with core snap or core18+snapd, and consider core systems in followups (with tests) [16:26] pstolowski: ok, that's fine [17:08] cachio: what was the name of the sb/tpm enabled image again? [17:10] cmatsuoka, google-tpm is the server [17:10] backend [17:10] ah ok, let me try that... thanks! [17:10] cmatsuoka, https://github.com/snapcore/snapd/blob/master/spread.yaml#L128 [17:11] you should try something like google-tpm:ubuntu-20.04-64: [17:12] cmatsuoka, you are the first one using those images [17:12] cmatsuoka, please tell me if you need any change [17:18] pstolowski: what's the first release that hotplug worked on ? 2.42 ? [17:19] ijohnson: hmm, tough question, i need to dig a bit, one moment [17:19] thanks [17:19] PR snapcraft#2952 closed: spread: introduce appstream parse-info test [17:22] ijohnson: 2.39 it seems [17:23] thanks pstolowski [17:23] ijohnson: based on https://forum.snapcraft.io/t/hotplug-implementation-plan/4554/3 cause debian changelog wasn't too helpful [17:23] pstolowski: degville: I made a small edit to https://forum.snapcraft.io/t/hotplug-support/10750 to reflect that snapd edge isn't useful anymore [17:23] err rather isn't needed anymore for enabling hotplug [17:24] ijohnson: thank you! [17:26] ijohnson: thanks, makes sense [19:23] mvo: are you building a new 2.43 ? [19:24] of snapd [20:31] mvo, pedronis: snapd is held up in store review [20:31] types: New type "application" does not match the type of the latest approved revision, r6625 ("snapd") [20:32] zyga: that's a 2.43 build, that's why I asked mvo [20:32] I see [20:50] pedronis: no plan to re-build 2.43, cherry picked one commit though in this branch just in case, I think we can ignore this [20:54] uh, looks like master is red - is that because of "tests/main/retry-network" failing? [20:57] looks like it - oh well [20:57] something for my morning I guess [21:06] mvo: yes, something strange going on with retry-network [21:07] lots of red [21:07] not just master === JanC_ is now known as JanC [21:11] pedronis, I am testing a fix for the retry-network [21:11] it is a timing issue [21:24] cachio: what's the timing issue for retry-network? [21:29] ijohnson, takes some time to NoNetwork: true [21:29] cachio: ah as in the network namespace isn't created immediately? [21:30] in the output file I see NoNetwork: false [21:30] but after a time it appears NoNetwork: true [21:33] ijohnson, I am testing the fix right now [21:34] cachio: cool let me know when/if you want me to review [21:34] ijohnson, sure, thanks!! [21:49] there are 2 problems [21:49] timing issue [21:49] which is fixed [21:49] also getent hosts www.ubuntu.com is returning the ipv6 instead of the ip [21:49] todya I updated the images [21:50] I think there was a change in a package which is affecting this [21:51] ijohnson, ~ [21:51] cachio: ah I see yeah ipv6 could break things I suppose [21:52] cachio: I need to step out for a while, but feel free to request my review, I'll be back in a hour or two [21:52] ijohnson, sure, np [22:17] PR snapd#8207 opened: tests: fix retry network test after image update [22:41] * cachio afk