=== jamesh_ is now known as jamesh [05:26] o/ [05:26] good morning [05:36] zyga: based on your mention of i18n a few days ago, I was looking at the current state. It looks like no new po template has been picked up by Launchpad since 2018. Also, we don't seem to distribute translations outside of Ubuntu's langpacks [05:36] yes, that last bit is indeed sad and true [05:37] I was wondering if we could at some point really try to import translations at around beta time [05:37] commit them to the tree for real [05:37] I think we'd need to have them in-tree to e.g. merge translations into the desktop file or polkit actions [05:37] and distribute them in releases [05:37] I agree stronglyt [05:37] *strongly [05:37] *sorry, my thinkpad lost a key and it's annoying to type on now [05:38] If the Ubuntu packaging ran update-pot during build, that might be enough to have LP pick up new strings [05:39] mmm [05:39] how can we export translations from launchpad? [05:39] are they in a git anywhere? [05:39] we can ask Launchpad to periodically write them to a Bazaar branch [05:40] oh that's interesting :D [05:40] but we can use actions to get that [05:40] a periodic action can checkout bzr repo [05:40] copy translations [05:40] could have something to periodically copy those to git and create a pull request [05:40] and commit [05:40] or open a PR [05:40] yeah [05:40] it's doable with actions for sure [05:43] * zyga is a bit under the weather today, courtesy of all the rain lately [05:43] I'll get some tea and breakfast [05:44] jamesh: i would not overdo it for l10n yet [05:44] we can look at it more calmly after core20 ships and the team has more time [05:44] and the message domain is still "snappy" :-) [05:46] lalala [05:46] :D [06:03] * zyga looks if store tests are happy now [06:04] 16 tests in progress [06:04] oh well, I'll take the dog for a walk and check again [06:12] morning [06:18] hey mborzecki [06:18] I restarted some tests but I see red [06:18] searching test still fails [06:19] zyga: hey [06:19] ehh, so no luch today either eh? [06:20] i suppose we can ask mvo to merge some of those PRs [06:21] mborzecki: we can propose a PR that ignores searching error [06:21] it's not a great test [06:21] it proves that things on the internet are not working sometimes [06:21] not great not terrible :P [06:21] if anything, store should run that test [06:21] not us [06:28] I'll start at around 9, need to run an errand at home [06:46] mvo: morning [06:46] good morning mborzecki [06:46] mborzecki: how are you? anything I can help with? [06:46] mvo: pinged you in a couple of PRs that could use a force merge [06:47] mborzecki: aha, I have a look [06:47] mvo: https://github.com/snapcore/snapd/pull/9420 https://github.com/snapcore/snapd/pull/9474 and https://github.com/snapcore/snapd/pull/9443 [06:47] PR #9420: tests/nested/manual/minimal-smoke: use 384MB of RAM for nested UC20 [06:47] PR #9474: boot, overlord/devicestate: list trusted and managed assets upfront [06:47] PR #9443: gadget, gadget/install: support for ubuntu-save, create one during install if needed [06:47] hey mvo [06:48] good morning zyga-mbp [06:49] zyga-mbp: anything I can do for you this morning? [06:49] PR snapd#9443 closed: gadget, gadget/install: support for ubuntu-save, create one during install if needed [06:49] PR snapd#9474 closed: boot, overlord/devicestate: list trusted and managed assets upfront [06:49] mvo, mmm [06:49] mvo only a review for 9446 is something that is ready-to-go [06:49] mborzecki: done and thanks^2 for the TODO:UC20: about making the mem requirement official. I would actually really like to drive it down to 256 again but it seems we need kernel/foundations team help for this [06:49] I'm working on remaining comments to 9406 [06:50] mvo last night I was trying to figure out how to sort out fsck on core16 [06:50] zyga-mbp: sounds good [06:50] but I think that's something that can only be done in core itself [06:50] so I dropped that [06:50] zyga-mbp: fsck> what did you figure out? [06:50] mvo: i recall xnox said it may be a problem if we do an efi boot [06:50] mvo well, we just need the equivalent of systemd-fsck [06:51] but that's non-trivial [06:51] we should think about options and what we can do, I just dropped that because it was late and I was tired [06:51] I think I got the same cold my wife has now, so that was a factor as well :/ [06:52] I had to wait for nearly an hour for the vet visit [06:52] and wasn't dressed for it [06:53] mvo: can you land https://github.com/snapcore/snapd/pull/9500 too? [06:53] PR #9500: tests/main/sudo-env: snap bin is avaialble on Fedora [06:53] pstolowski: hey [06:53] hey pawel [06:53] hey o/ [06:53] good morning pstolowski [06:53] mborzecki: sure, done [06:54] mvo: thanks! [06:54] PR snapd#9500 closed: tests/main/sudo-env: snap bin is avaialble on Fedora [06:54] zyga-mbp: oh no! hope you get well soon (or at least not more unwell) [07:01] morning mvo [07:03] zyga-mbp: thanks for the review of 9501 [07:04] :-) [07:04] looks like errors.Is is a new thing in go and we don't have it :( [07:04] pstolowski: we're using xerrors package for that [07:04] pstolowski you can probably just use == errno.EROFS [07:04] as errors.Is may rely on wrappers and interfaces that we are not using universally [07:26] mvo: are you looking into the sbuild errors in #9502? [07:26] PR #9502: tests: more output for sbuild test [07:26] mborzecki: I haven't yet, looking now [07:26] mvo: i'll try to figoure out what's going on there, maybe we're missing some mocking [07:27] mborzecki: yeah, that seems likely [07:27] mborzecki: sbuild puts the process into a sandbox [07:28] mborzecki: maybe some implicit assumption that grub is installed or a valid bootloader or something? [07:29] mvo: idk, maybe, weird, cause we run the unit tests on sid too [07:29] mborzecki: hrm, hrm, yeah, there are more further down that are also strange [07:30] mvo: the panic/timeout is probably due to some assert in a callback [07:33] * mvo nods [08:02] mvo: heh, so tests are run with nosecboot tag [08:03] mvo: destkop review call if you have the time to join === zyga_ is now known as zyga-mbp [08:05] i just hit missing current symlink for snapd on failed refresh while working on a spread test for core18 [08:07] mborzecki: ohhhh, nice [08:09] mborzecki: nice find [08:14] mborzecki in a call [08:14] kk [08:31] mborzecki not yet, last evening I wasn't feeling very well so I worked upstairs on PRs [08:31] mborzecki I plan to do that in my afternoon [08:31] brb, [08:46] back with tea [08:49] PR snapd#9463 closed: seed/seedwriter/writer.go: check DevModeConfinement for dangerous features [09:33] heh, initramfs-mounts unit tests seem to not be mocking everything correctly [09:34] mmm [09:36] mborzecki: I was wondering if it'd be possible to avoid global state [09:36] by organizing that anything done is accessed through arguments [09:37] including distant APIs [09:44] mborzecki: it might be more work at first but it would prevent "missing" a mock [09:51] ok, i think i got all the tests passing with nosecboot tag now [10:12] mvo: this was pretty annoying, but i got #9504 and it should unblock sid sbuild [10:12] PR #9504: many: verify that unit tests work with nosecboot tag and without secboot package [10:15] PR snapd#9504 opened: many: verify that unit tests work with nosecboot tag and without secboot package [10:27] duh, hate shell really [10:30] mborzecki: nice work [10:34] mborzecki: \o/ [10:34] mborzecki +1 [10:34] mborzecki: let me review [10:34] mborzecki: thanks so much [10:34] it's raining all day again [10:34] my wife is sick [10:34] they are about to close the city due to covid [10:34] and I need to pick up my fixed imac from the service center [10:34] and my dog is sick now too (though differently of course) [10:34] oh boy [10:34] what a morning [10:35] mborzecki: woah, that looks like it was hard indeed [10:35] zyga-mbp: oh no! that sounds horrible, stay strong! [10:36] dog just needs meds but I need to pick everything up today somehow [10:36] it's okay, we'll sort this out [10:40] heh ./run-checks: line 303: tags[@]: unbound variable, but passing locally here, wtf? [10:40] mborzecki bash version perhaps [10:41] try declare -A tags [10:41] but not 100% sure [10:41] zyga-mbp: there's an assignment a bit to the top, tags=() [10:41] I know [10:41] but ... it's shel [10:41] unless we need some magic incantation again [10:41] also known ash hell [10:42] zyga-mbp: but it's /usr/bin/bash now [10:42] yeah but bash _version_ matters [10:42] ehh [10:42] I was playing with arrays the other day and I noticed older versions didn't have some of the features [10:42] can't we use perl/tcl/python/any^shell [10:42] where does it fail" [10:42] mborzecki well [10:42] sure, we can [10:46] mvo: could you check for me how old (roughly) is snapd rev 8144 ? [10:46] pstolowski: checking [10:47] thanks [10:47] pstolowski: 2020-06-05 16:30 - 4 months, 1 week ago [10:47] oh [10:47] mvo was faster [10:47] btw, which command did you run? [10:47] mvo, zyga thank you :) [10:48] I tried snapcraft list-revisions snapd [10:49] zyga I used https://dashboard.snapcraft.io/snaps/snapd/revisions/8144/ [10:49] zyga: omg, bash 4.3.48 (from enial) complains about unbound variable, bash 5.0.18 does not [10:49] mborzecki: did I win a cookie? [10:50] mvo: that page is not available for me [10:50] mborzecki: my advice is to revert backto sh [10:50] mvo: thanks [10:50] zyga: https://paste.ubuntu.com/p/Mc93wY3j5W/ this fails [10:50] right [10:51] mborzecki: use a variable and just append to it [10:51] sad as it is [10:51] zyga: that won't work if you want to passs say `'nosecboot foo'`, because shell will chop it up when expanding the variable [10:52] either that, or `shellcheck disable=SC2086` at every relevant place [10:52] mborzecki: not exactly, you can always quote it enough [10:52] or sharp dirty pieces of metal under one's fingertips [10:52] finger*nails* [10:52] not sure which is worse [10:52] zyga: afaik not really, it's array, function or try a differnt interpreter :P [10:53] mborzecki: hmm? [10:53] you can also if-then-else this [10:53] anyway, I'm sure it is solvable [10:53] zyga: yeah, but the tools are broken :/ [10:54] heh, "${tags[@]-}" is apparently fine (?) [10:57] hmmmm [10:57] hmm [10:58] mborzecki, zyga-mbp fun, I was stumbling on the same wondering [10:59] I cannot find any documentation on what {foo-} stands for [11:01] pedronis: https://github.com/snapcore/snapd/pull/9406 is good to go now, I think [11:01] PR #9406: many: allow ignoring running apps for specific request [11:02] zyga: it's documented under ${parameter:-word}, with the general comment above that "Omitting the colon results in a test only for a parameter that is unset" [11:02] oh [11:03] huh [11:03] mborzecki does it do what you expect? [11:03] cjwatson thank you! [11:03] np [11:08] pedronis do you think you will have time to have a quick look at the link participant PR? [11:08] pedronis +145,-0 [11:08] yes, I will try to look at it this afternoon [11:08] that is https://github.com/snapcore/snapd/pull/9422 [11:08] PR #9422: overlord: add link participant for linkage transitions [11:09] at this point is 2nd or 3rd in my queue [11:09] that's excellent, thanks! [11:18] mvo: can you also update the golang-github-mvo5-goconfigparser-dev package in sid? [11:20] mvo: it is missing this fix: https://github.com/mvo5/goconfigparser/pull/6 [11:20] PR mvo5/goconfigparser#6: configparser: fix section header regex to not interfere with JSON data [11:25] heh, so with {..-} we get `go build '' -v github.com/...` so useless [11:26] I'm going to pick up my imac now, I will do my best to get back home by standup but if I cannot I'll join from my phone [11:30] mborzecki: oh, yes [11:38] re, sorry, had to reboot to get LTE working [11:49] mborzecki: I prepared the goconfigparser upload, just waiting for an ack from vorlon to ensure I don't step on anyones toes (but I'm sure he will not mind if I take this debian package over from him) [11:50] mvo: thank you! [11:50] I need a review for https://github.com/snapcore/snapd/pull/9406 [11:50] PR #9406: many: allow ignoring running apps for specific request [11:50] it's pretty simple and not too long [11:50] pedronis, zyga : added some inisght into https://bugs.launchpad.net/snapd/+bug/1899665 [11:50] Bug #1899665: Failed refresh of snapd drops current symlink [11:52] mvo: shall we disable the searching test for now? [11:52] pstolowski: looking [11:53] zyga: yes [11:53] mvo: k [11:53] zyga: can we infer that the store is under load from the returned error? [11:53] I'll check [11:54] maybe we could adjust the test to not fail under these conditions [11:54] also funny that it seems everything else is working on the store side [11:54] we get 403 [11:56] I think we can [12:01] mvo: how does https://github.com/snapcore/snapd/pull/9505 look like? [12:01] PR #9505: tests: allow the searching test to fail under load [12:05] PR snapd#9505 opened: tests: allow the searching test to fail under load [12:08] zyga: looks good, I was hoping the store would tell us a little bit more in their payload than just the 403 :/ [12:08] zyga i can try to have a look (but will need lunch soon :) [12:08] zyga but maybe it really does not give us more info [12:08] (and maybe my idea is kind-a dumb) [12:09] I don't know [12:09] I think it's not that critical [12:09] and it's probably gonna vary over time [12:09] I marked the branch as ready for review [12:09] picking up my imac now, I'll re-connect later [12:09] ok [12:09] good luck [12:10] it comes from the proxy/LB iirc [12:13] PR pc-amd64-gadget#50 closed: grub: boot configuration is shipped and managed by snapd [12:13] yay [12:24] zyga-mbp: I have a question in #9422 [12:24] PR #9422: overlord: add link participant for linkage transitions [12:30] PR snapd#9506 opened: boot: skip some unit tests when running as root [12:42] re [12:57] pstolowski, mborzecki: I will try to reproduce the old kernel upgrade of core18 after the standup [12:57] we can chat after I have the outcome, either way it's something we learn [12:57] I was also thinking we could stream compressed, non-empty blocks of the SD card [12:57] and probably re-image the device locally [12:58] that would eliminate all but SD card corruption [12:58] unless pi revisions matter but I hope not [12:58] pstolowski: nice analysis in https://bugs.launchpad.net/snapd/+bug/1899665 [12:58] Bug #1899665: Failed refresh of snapd drops current symlink [12:59] and last point is very sobering [12:59] because it means that bugs have a delayed fuse [13:11] yes [13:57] re [13:57] pstolowski: we're done, if you need to talk to mvo [14:00] zyga-x240: thanks; no, i was just joining back standup [14:01] ah right [14:02] zyga-x240: btw I looked at https://github.com/snapcore/snapd/pull/9497 I don't think it needs my review particularly, it does need one more on top of yours though [14:02] PR #9497: usersession/agent: have session agent connect to the D-Bus session bus [14:02] pedronis checking [14:03] right, I will do a complete review [14:03] and then maybe pawel or maciek can look [14:04] mborzecki could you go for core desktop call? [14:22] jamesh https://github.com/snapcore/snapd/pull/9497#pullrequestreview-509416040 [14:22] PR #9497: usersession/agent: have session agent connect to the D-Bus session bus [14:51] * cachio lunch [14:56] zyga-mbp: sorry, late lunch [14:56] found a silly problem in snapshots though [14:57] mborzecki: in "snap snapshots"? [14:57] mvo: more liek snapshots backend, see https://github.com/snapcore/snapd/pull/9507 [14:57] PR #9507: overlord/snapshotstate/backend: specify tar format for snapshots [14:58] mborzecki: nice! [14:58] mvo: somehow suse defaults to POSIX tar for format, so the unit tests of snapshot export failed because they assume a known archive size [14:59] mborzecki: right [14:59] uh, [14:59] nice! [14:59] mborzecki: nice find! [14:59] Bug #1899992 opened: refresh.timer=managed prevents setting other configurations, e.g. proxy.http [15:00] mborzecki reviewed [15:01] zyga-mbp: yeah, doesn't look like we do a very strict checking of the archives [15:01] PR snapd#9507 opened: overlord/snapshotstate/backend: specify tar format for snapshots [15:01] anyways, i can look into that on monday, got some errands to run [15:01] understood [15:01] ok I should stop coding but I want one more thing [15:01] then I'll re-create that pi [15:02] I NEED PI(e) [15:02] ;-) [15:02] zyga-mbp: fwiw this came up when i tried to update the package on opensuse [15:02] mvo can I revert that last commit in 9505 and merge without any extra checks [15:02] zyga-mbp: so a distro patch will be needed [15:02] I don't want to dig into that (that other variant of the failure now) [15:05] mvo: sorry, what ack are you waiting on from me re: goconfigparser? I don't see any email about this from you [15:07] mvo perhaps someone should attend https://developers.tpm.dev 's https://developers.tpm.dev/posts/tpmdev-2020-miniconf [15:08] vorlon: just a high-level ack :) [15:08] vorlon: if you are ok with that I will just upload if you prefer to review the diff that also works etc [15:10] mvo: please go ahead [15:11] ta [15:13] zyga-mbp: yeah, just do it [15:13] ok [15:14] done [15:14] pstolowski can you review 9505 quickly [15:14] (tiny) [15:14] looking [15:15] https://github.com/snapcore/snapd/pull/8573 needs a 2nd review but not sure who has time for it [15:15] PR #8573: overlord/snapstate: inhibit startup while unlinked [15:18] zyga-mbp: in a meeting but I can do after, this one looks straightforward [15:18] woot, thanks [15:43] pedronis, pstolowski: question about link/unlink snap, some actions explicitly set Done/Undone status [15:43] but this is not consistent among the set of handlers that change linkage [15:43] is this by design or is there an omission somewhere? [15:45] zyga-mbp: I need to recheck, in general is always ok to do it, it's really needed though if the task does internal state changes that are not clearly idempotent [15:46] mmm [15:46] zyga-mbp: yes, i noticed something similar thing wrt maybeRestart recently [15:46] we should scrutinize that then - I suspect there's a subtle bug there [15:47] this can be problematic if an unplanned restart happens and we re-execute same task [15:50] zyga-mbp: basically adding it to the (un)doUnlinkCurrentSnap should be fine and maybe needed [15:50] I'll send a separate PR for that [15:50] but OTOH I think pstolowski change that code again [15:50] anyway as I said, it's never a bug to have it [15:51] it might be a bug not to have it [15:51] it's a bit of annoying property of our state/task model [15:51] * zyga-mbp nods [15:51] true [15:52] I mean, assuming is done after any error path [15:52] right [15:52] pretty much at the bottom of those functions [15:56] PR snapd#8573 closed: overlord/snapstate: inhibit startup while unlinked [15:56] \o/ [15:56] thank you [15:57] zyga-mbp: *thank you* [16:01] mvo: reviewed snapshot import [16:02] the next time we might revisit the runner we might want to consider holding the lock to be the default for tasks, and not holding it fully to be the exception [16:03] pstolowski: just saw it - thanks so much! [16:03] * mvo takes a dinner break [16:04] we would need to see if it's true that most task do hold it [16:04] when we started there were less tasks and some it was more mixed [16:04] s/some/so/ [16:19] so, after reordering removing of snap revisions undo looks more sane [16:23] \o/ [16:24] the battle is not over to be clear ;), but at least i'm back with lxd snap and attempt to remove it again. no more errors from undo handlers because of wrong current [16:25] *can attempt* [16:25] eod, cu [16:29] o/ [16:44] eh, I messed up redirect in search fix [16:44] I'll change that shortly [17:13] actually [17:13] I did not [17:13] some new error showed up [17:14] pedronis I've updated https://github.com/snapcore/snapd/pull/9422 [17:14] PR #9422: overlord: add link participant for linkage transitions [17:14] I will EOD now, need to help my family [17:14] see you tomorrow [17:15] mvo if you are back, consider merging https://github.com/snapcore/snapd/pull/9505 [17:15] PR #9505: tests: allow the searching test to fail under load [17:15] it's not perfect as other things failed now (store related) [17:15] but may be better [17:15] * zyga-x240 EODs [17:57] PR snapd#9508 opened: tests: remove ausearch which fails during prepare [18:57] PR snapd#9505 closed: tests: allow the searching test to fail under load [19:57] PR snapd#9509 opened: multipass/docker-support: Mount /etc/apparmor* from the base snap