[02:13] PR snapd#9576 opened: [RFC] snap-bootstrap: be more robust for recover mode, ignore some errors [02:18] PR snapd#9577 opened: many: seal a fallback object to the recovery boot chain [03:18] PR snapcraft#3344 closed: pyproject: add isort with black-compatible configuration [06:24] PR snapd#9570 closed: gadget/internal: tune ext4 setting for smaller filesystems [06:54] mvo my last day [06:54] good morning zyga-mbp [06:55] zyga-mbp: yes, sad but true [06:55] I think I got a cold though, last evening I felt terribly weak [06:55] I'll get to finish what I worked on with pedronis yesterday now [06:59] thanks zyga-mbp ! let me know if I can help in any way [07:01] sure [07:01] mvo how do I sign the CLA? [07:04] zyga-mbp: should be super easy, just go to https://ubuntu.com/legal/contributors [07:04] zyga-mbp: and navigate to https://ubuntu.com/legal/contributors/agreement [07:04] zyga-mbp: and the rest is hopefully straightforward [07:06] morning [07:08] good morning mborzecki [07:09] mborzecki: there are some questions from ian in 9565, I would have pushed myself but I'm unsure about the devicestate_test.go questions, could you please have a look? I think this is ready otherwise (and we can always land tweaks in a followup, will make other PRs easier :) [07:10] mborzecki: just to be clear, if this pr just needs tiny tweaks I would merge and do a followup to avoid the spread run time overhead :) [07:12] mvo: i'll push those fixes and we can let it run once more [07:12] and then land :P [07:12] mborzecki: ok [07:13] mvo: hm let me check whether the little tweak in the test is actually making anything different [07:13] mborzecki: sounds good [07:15] good morning mborzecki [07:15] * zyga-mbp goes to the office [07:16] mvo: yeah, i've restarted the run which shuld be quick now since most jobs were green, and we can land it [07:16] zyga: heya [07:17] o/ [07:19] zyga: so, when is the farewell party? :P [07:20] mborzecki, I can drop for a beer to Frankfurt next year ;) [07:20] zyga: sgtm ;) guess many old colleagues would love to have a beer with you [07:21] mborzecki: oh, it was just ubuntu-18.04 failing, that was a misconfigured apt-get afaict, I can force-land this (unless there is more than this one 18.04 error?) [07:21] mvo: already restarted [07:21] zyga: +1 for FRA [07:24] * mvo nods [07:24] mborzecki: no worries, will be quick :) [07:45] PR snapd#9565 closed: overlord/devicestate: bind mount ubuntu-save under /var/lib/snapd/save on startup [07:57] brb, graphics corruption on 5.9.1 strikes again [08:00] re [08:02] mborzecki, did you consider reverting to an older kernel? [08:03] zyga: 'the arch way' there is only one kernel version [08:03] mborzecki: welcome back [08:03] mborzecki, nkvd would approve, march forward ;-) [08:04] mborzecki, but not even the previous kernel you mean? [08:05] zyga: no, there's just one kernel package version eg. `linux`, you can have other kernels, eg `linux-lts` which is the latest LTS, but who runs that? :P [08:05] zyga: iirc manjaro does something funny, they have linux59, linux58 and so on [08:06] morning [08:06] zyga: on the rpm side, the kernel is also a 'special' package iirc and you can have more than one [08:06] mborzecki, I wish we can do linux snap for ubuntu classic for 22.04 [08:06] including a way to pick one of the supported LTS kernels, upstream kernels, etc [08:06] I would *love* that [08:07] even though OMG DRAGONS apply [08:07] heh, hwe/upstream kernels would be great [08:07] mborzecki, yeah, I think so, though I don't know how that is implemented [08:07] it's a bummer when an lts release does not even boot [08:07] long term unsupported release [08:10] * zyga suspends and reboots for OS update [08:14] and back [08:14] I love this part of VMs [08:14] like suspending a lisp image [08:15] PR snapd#9578 opened: o/devicestate: unit test tweaks [08:25] PR snapd#9579 opened: tests: rename hasHooks to hasInterfaceHooks in the ifacestate tests [08:35] PR snapd#9575 closed: testutil, cmd/snap/version: fix misc little errors [09:06] mborzecki: hi, I tried to answer your question [09:08] pedronis: ok, i got confused with the last commit where IsDirectory() got removed, but didn't notice save avaialble is set to true int he branch where there is no mount [09:11] ok, and keypair manager creates the path, so we're not blocked by https://github.com/snapcore/core20/pull/91 being available [09:11] PR core20#91: hooks: add /var/lib/snapd/save [09:12] and i clearly need more coffee [09:13] mborzecki: the IsDirectory was a left over for when your PR was running that code also on UC16/UC18 [09:14] ah, i see [09:20] PR snapd#9566 closed: boot: store the TPM{PolicyAuthKey,LockoutAuth}File in ubuntu-save [09:28] pedronis, I've updated the export manager [09:29] pedronis, some comments are still TODOs on my side but the main change is in place [09:33] zyga: thanks, special.go is quite simpler now [09:34] pedronis, I think the only thing we need to think about now is the instance case [09:34] pedronis, do we want .../export/snap_key/revision/set [09:35] or .../export/snap/revision_key/set [09:35] yes [09:35] ah sorry [09:35] I mean the former: /export/snap_key/revision [09:36] so the more direct [09:36] because of where we put current [09:36] sure, I'll do that shortly [09:36] it's the only reasonable thing [09:36] with the re-mapping layer we will need anyway this is easier and less surprising [09:36] +1 [09:36] and even less special cases I think [09:36] I tried adding some more tests but there's at least one missing still [09:37] coverage is good but some specific cases have no explicit tests [09:37] even though it doesn't show up as missing coverage [09:39] mborzecki: are you looking at #9560 again? [09:39] PR #9560: gadget/many: drop usage of gpt attr 59 for indicating creation of partitions [09:39] pedronis: yeah, it's on my list for today [09:45] PR snapd#9580 opened: [RFC] store: download timeout [09:45] pedronis: ^ [09:46] pstolowski: thank you, I don't think I'll get to it before I'm back next week though [09:47] pedronis: sure [10:04] pstolowski: 9580 looks pretty neat from a first glance [10:05] mvo: thanks, it's tricky stuff, so i'm cautiously optimistic ;) and looking forward to full spread runs [10:05] PR snapd#9578 closed: o/devicestate: unit test tweaks [10:05] PR snapd#9579 closed: tests: rename hasHooks to hasInterfaceHooks in the ifacestate tests [10:09] pstolowski: yeah, it looks like a winner but I have not really digged deep yet, just a first feeling from reading it :) [10:12] mvo: I tried to answer you questions in #9573, but I'm probably confused [10:12] PR #9573: o/devicetate,dirs: keep device keys in ubuntu-save/save for UC20 [10:13] pedronis: look but it's probably me being confused, I don't/did not had the full picture but let me read first [10:15] pedronis: what's the longer term plan with "saveAvailable"? will we dynamically umount /save or mount it RO or is the fact that we have /save pretty static? sorry, maybe that was the missing piece for me [10:16] mvo: I don't know, but otoh I expect a limited set of very structured places to care about that flag or final flaggs [10:16] if we get m.saveAvailable everywhere we are doing it wrong [10:17] you proposal seems more going into let's ask about save a bit everywhere [10:17] pedronis: ok and it's "static" in the sense that other parts of snapd will not mess with /save (umount,remount) without this part knowing? [10:17] mvo: yes, if you look at that my other PR, my main idea is that there will be with* helpers for each things that needs touching save [10:17] pedronis: my proposal would use saveAvailable() the same amount of times as we check the boolean, I was mostly wondering if it might be a TOCTOU issue [10:18] mvo: what I'm confused, is that sounds you expect the flag to change at random places [10:18] I would expect to have "one" place to do mount unmount, touch flag [10:18] pedronis: not the flag, but potentially the state of /var/lib/snapd/save [10:18] pedronis: aha, ok [10:19] mvo: but we control the state [10:19] pedronis: then we should be fine. I was worried because we set it three times to true currently but yeah, this makes sense [10:19] pedronis: let me re-read it again with the added context, thanks for explaining this [10:20] if we are worried about the mount state to change behind our back, and then yes we need to do something else [10:20] mvo: to be clear I mostly did the flag as a flag atm because it covers: let us return an error if something tries to use a save helper on UC16/UC18 [10:20] pedronis, used snap.Revision now, only the instance key remains [10:20] that's probably clearer in the ollow [10:20] *follow up [10:20] PR snapd#9581 opened: tests/nested/core20/save: check the bind mount and size bump [10:21] pedronis: ta [10:21] * mvo reads 9574 too [10:22] meh gofmt [10:22] mvo: but you are probably right that the TODO on saveAvailable is probably too specific [10:30] pedronis, a pass over https://github.com/snapcore/snapd/pull/9546 would be good now [10:31] PR #9546: overlord: add inert export manager [10:31] I only want to add more tests [10:31] and there's the question of ErrNoState and not returning that in a specific case that I think is okay but you should respond to that point explicitly [10:37] abeato: hey, maybe you have thoughts about https://github.com/snapcore/snapd/pull/9580#discussion_r514990758 ? this PR introduces download timeout and as is, it requires average speed of 256 bytes/sec, measured over 5-minute time windows [10:37] PR #9580: [RFC] store: download timeout [10:48] pstolowski, I've not followed the bug too much tbh, but sometimes they have cellular connections that might dropt and could cause this sort of problem [10:49] abeato: ok, good to know. do you have any thoughts about realistic throughputs from the field? [10:50] zyga: I did another pass [10:50] pstolowski, don't know the throughput, but something that can happen very realistically is that suddenly the modem is not able to rx/tx packets anymore but it won't drop the connection immediately. Effectively that means that suddenly you get zero bandwidth [10:50] zyga: and answered your question [10:51] and it can take a long time until something puts the interface down... [10:52] abeato: right, the explains the issue i'm trying to fix [10:52] thanks, looking [10:52] pstolowski, so, the safeguard you are implementing seems to me like a very good thing to have [10:52] pstolowski, and not only for this customer [10:53] abeato: yes, we have seen it once on desktop [10:53] abeato: we just need to be careful no to go overboard with this [10:54] pstolowski, right - also I think cellular is usually the hardest case, where you can have more issues [10:55] pstolowski, which is of course a quite frequent setup in IoT [11:05] mborzecki: fsck-on-boot failed here: https://github.com/snapcore/snapd/pull/9573/checks?check_run_id=1331162810 don't think is related to the PR but anyway annoying [11:05] PR #9573: o/devicetate,dirs: keep device keys in ubuntu-save/save for UC20 [11:05] mborzecki: on 18.04 [11:07] hmm `umount: /boot/grub: target is busy` [11:07] maybe snapd was writing something there? [11:15] pedronis, updated some, replied to others [11:16] zyga: I re-replied [11:16] oh that was quick :) [11:16] mborzecki: mvo: I'll force merge 9573, I'll work some tweaks in 74 [11:16] ok [11:17] pedronis: ta [11:17] pedronis: https://github.com/snapcore/snapd/pull/9573#discussion_r515005938 would be nice to get a yes/no or followup :) [11:17] PR #9573: o/devicetate,dirs: keep device keys in ubuntu-save/save for UC20 [11:17] ok [11:19] mvo: I answered to it [11:19] ta [11:21] mvo: core20 will ship with /save precreated [11:21] PR snapd#9573 closed: o/devicetate,dirs: keep device keys in ubuntu-save/save for UC20 [11:21] right now it works anyway because a couple of path will auto-create it anyway [11:21] pedronis: sorry, one more question - when you write " [11:21] in the final world it will always come from core20 itself" do you mean the core20 snap? asking because this is on the writable partition [11:21] yes, the core20 snap [11:21] ok [11:22] mvo: core18 and core20 come with a bunch of defined dirs in /var/lib/snapd [11:22] mborzecki has a PR to do add /save to core20 [11:22] I think it was even merged [11:22] not sure if it's on some channel yet or not though [11:23] pedronis: ok, then we are good. thanks [11:25] hmmm [11:25] I wonder if there's a subtle mistake in this logic [11:26] snapstate.CurrentInfo requires the snap to have a current revision [11:26] that's correct [11:26] snaps always have a current revision [11:26] I check for NotInstalledError [11:26] or they are not installed [11:26] so perhaps that's fine [11:26] they might not be active though [11:27] I was wondering if this worked because we are not hitting the path for snapd in practice [11:27] being active and having a current revision is orthogonal [11:27] if something is inactive [11:27] ah, I didn't realize this, that's much better then [11:27] then the curren revision is the last active revision [11:27] because it has to work for inactive case as well [11:27] that's okay then [11:27] pedronis: yes, it was merged, but the latest edge is from 10.27, so still without the change [11:31] pedronis, pushed again [11:32] I'll rebase the full branch on this and see if everything passes [11:33] zyga: the helper to remove the full export/snap is the rest? for remove? [11:34] *is in the rest [11:34] pedronis, hmm, sorry, which helper exactly? [11:34] pedronis, all of the export manager is in in the smaller PR [11:35] zyga: when we remove a snap we need to remove the export/snap dir? unlink just remove a version? not current for example [11:35] the unexport-content task removes that [11:35] it is in this branch, but it is not used until the full branch [11:36] the helper to remove the content is here as well, we simply remove the manifest serialized in the state IIRC [11:36] I'm probably confused [11:36] there is something wrong or I'm misunderstanding [11:36] the function that removes files for a given manifest is removeExportedFiles [11:36] it is called from doUnexportContent [11:37] which is the handler for unexport-content task [11:37] is that what you were expecting? [11:38] good morning ijohnson [11:39] zyga: I think it depens on order of things I suppose [11:40] I think the bits are there [11:40] zyga: I suppose the issue, is that actual I don't when we unexport content, we do it after we switched it, right? [11:40] in the sense of task ordering, the remove-content runs after unlink-snap, ensuring we, by that time, have picked a new current symlink (or removed it) [11:40] *actually I don't know [11:41] rigth [11:41] *right [11:41] all content with corresponding snaps is on disk [11:41] then I think this should work [11:41] we rewrite the current symlink before we remove the content [11:41] * pedronis lunch [11:41] I'll break for coffee while tests run [11:46] PR snapd#9582 opened: [RFC] gadget/quantity: introduce a new package that captures quantities [12:04] hey cachio [12:04] zyga, hey [12:04] cachio, my last day :) [12:05] can I review anything for you? [12:05] zyga, yes, I know :( [12:05] zyga, #9524 [12:06] PR #9524: tests: new boot state tool [12:06] that one that you already started [12:06] sure, let me look [12:06] thanks [12:14] PR snapcraft#3345 opened: project_loader, formatting_utils: take empty env values into account [12:25] cachio, https://github.com/snapcore/snapd/pull/9524#pullrequestreview-520607334 [12:25] PR #9524: tests: new boot state tool [12:26] zyga, looking [12:31] PR snapd#9583 opened: features: enable classic-preserves-xdg-runtime-dir [12:37] brb [12:46] ogra: Do you have a tip how I can improve build time for the WPE kiosk snap on ARM? Building on a Pi 4 with 4GB RAM in an LXD container fails most of the time (“unexpected EOF”), I guess its too resource-intensive. Launchpad works, but aborts after ~6 hours because of https://bugs.launchpad.net/launchpad/+bug/1885164 (reported by cjp256). Next escalation step would be to attempt cross-compilation … [12:46] Bug #1885164: snap builds: network access timeout

[12:47] dot-tobias, add swap ? [12:47] buy 8GB riscv board and cross-compile (/me runs) [12:53] haha [12:53] ogra: That is … something I completely overlooked 🙈 [12:55] dot-tobias, also, make sure your storage pool is large enough to write all temporary files during build ... this error sounds more like there isnt enough disk space ... [12:55] zyga: Nice, but still would require to read up quite a bit on cross compiling to do it right and not sink in more days than necessary 😅 I just came here to package a web app! 😄 [12:57] ogra: I'm using the “dir” storage, followed your blog article https://ograblog.wordpress.com/2020/07/10/building-snap-packages-on-ubuntu-core/ → default lxd snap configuration. I thought that meant it can use 100% of the host resources, which is a 64GB SD card [12:59] zyga, #9524 updated, thanks for the review [12:59] PR #9524: tests: new boot state tool [12:59] ah, that might be fine then ... [12:59] cachio, looking [13:02] cachio, +1 [13:02] tx [13:02] cachio, I'd call the command functions cmd_ ... so that they stand out a little bit more but meh :) [13:02] it's internal now [13:02] part of the benefits of having programs [13:03] hehe [13:06] mborzecki, could you help me with the selinux denial in https://github.com/snapcore/snapd/pull/9530/ please? [13:06] PR #9530: interfaces: share /tmp/.X11-unix/ from host or provider

<⚠ Critical> <⛔ Blocked> [13:07] specifically in centos7 only [13:09] zyga: sure, let me see [13:12] mborzecki: I'm looking at Ian RFC PR, and now I'm very confused, where do we mount save in initramfs? we mount to /run/mnt/ubuntu-save, right? [13:12] yes [13:15] I'll pick up https://github.com/snapcore/snapd/pull/9204 [13:15] PR #9204: sandbox: track applications unconditionally [13:16] ijohnson: your RFC PR seems quite confused about the 2nd argument to maybeMountSave [13:18] pedronis: in meeting let's talk in our meeting later [13:18] / ExecutableExists returns whether there an exists an executable with the given name somewhere on $PATH. [13:18] :P [13:20] niemeyer, that an an an mistake :D [13:24] zyga: well the doc document it that way, so I suppose it was intentional [13:24] lol [13:24] # we are expecting the test to fail on a cgroup v2 system [13:24] it's very oddly placed though [13:24] this is why the xdg-settings test was failing :) [13:25] it's fixed now [13:25] pedronis, "there an exists" => "there exists" perhaps [13:25] ah, that as well [13:26] my point is that it's in stat.go [13:26] I only meant the typo [13:27] I see, I thought the question was more that FileExists and ExecutableExits are very different beasts similarly named [13:28] mborzecki, there's some SNAFU in centos-7 now [13:28] https://paste.ubuntu.com/p/6GyXX4FWZM/ [13:29] that is from https://github.com/snapcore/snapd/pull/9546/checks?check_run_id=1331732115 [13:29] PR #9546: overlord: add inert export manager [13:29] there's no selinux-policy-base 3.13.1-268 [13:29] archive skew? [13:40] mborzecki, woot, https://github.com/snapcore/snapd/pull/9204 should now pass [13:40] PR #9204: sandbox: track applications unconditionally [13:40] have a look at the last patch, it's pretty much what was expected [13:41]