[06:25] good morning [06:50] morning [06:52] mborzecki hey [06:52] zyga-mbp: hey [08:08] morning [09:03] mborzecki, https://git.kernel.dk/cgit/linux-block/commit/?h=swap-fix [09:03] mborzecki, any chance this is killing suse images? [09:03] maybe it's not the fs but swapfile vs swap partition? [09:07] zyga: no i don't think so, from the backtraces we have it's like xfs workqueue is building up [09:07] mborzecki, mmm [09:08] mborzecki, I'm puzzled by the fact that the official images use xfs [09:08] is there btrfs involved as well? [09:08] I recall that the "snapper" program was really heavy and it was a part of the default install [09:08] zyga: not in this one, but default kvm images use btrfs iirc ;) [09:09] that's even more confusing, why differ so much [09:09] oh well [09:09] good luck on tracking that bug down [09:10] zyga: fwiw, i have kiwi that sets up ext4 on rootfs and the image seems to be working fine so far in gce [09:11] mborzecki, did you try talking to anyone at suse? [09:11] zyga: https://bugzilla.suse.com/show_bug.cgi?id=1182761 [09:12] nice [10:22] PR snapd#9985 opened: boot: fix typo, should be systems === pedronis_ is now known as pedronis [10:41] pstolowski: hi, looks like #9978 can be merged [10:41] PR #9978: asserts: use Fetcher in AddSequenceToUpdate [10:42] pedronis: uff, finally, thanks [10:43] mborzecki: I should review #9921 and #9940 right? [10:43] PR #9921: boot: helper for setting up a try recover system [10:43] PR #9940: boot: cmd/snap-bootstrap: handle a candidate recovery system v2 [10:43] pedronis: yes, please do if you can [10:47] PR snapd#9978 closed: asserts: use Fetcher in AddSequenceToUpdate [10:52] PR snapd#9980 closed: o/devicestate: test that users.create.automatic is configured early [11:02] PR snapd#9986 opened: polkit: add a package to validate polkit policy files [11:16] pedronis: i think i'll re-open #9922 anew (the comments so far were addressed). rebasing is confusing again [11:16] PR #9922: api: validation sets monitor mode [11:49] pstolowski: silly question, are you dropping things when you rebase? [11:51] pedronis: i usually 'rebase -i' and mark commits for squashing [11:52] that's only when i want to clean history of course [11:54] pstolowski: you usually need to use d as well, if you are rebasing because master had got a different variant of the same code [11:55] pstolowski: but maybe that's what you meant [11:56] pedronis: use 'd' where? [11:56] pstolowski: in the commands you pass with -i [11:56] when you edit the instructions [11:57] pedronis: ah there, ok.. i need to see [11:57] PR snapd#9985 closed: boot: fix typo, should be systems [12:06] pedronis: yes, that did it! thanks! [12:07] PR snapd#9987 opened: tests: improve tests documentation - part 1 [12:40] meh, tweaking modenv for good/current recovery systems [12:41] did some naiive changes and it feels a bit silly to load essential snaps from seed twice for the same system [12:41] pedronis: I updated 9981 a bit more, needs a bunch of more docstring text I think but the gist should be there now [12:41] pedronis: thanks again for your suggestions about this one! [12:42] mvo: thanks, I have no time to look at it right now though [12:42] pedronis: no problem, not urgent [12:42] pedronis: the other two need to land first anyway or it's too messy to review [12:42] pedronis: I will poke ppl [12:53] mborzecki, hi, is it ok to merge #9975 ? [12:53] PR #9975: tests: fix new tumbleweed image [12:53] the idea is to continue with the other tests in a second PR [12:53] cachio: ah. ok, then, let me +1 it [12:54] thanks [12:54] cachio: left some notes what about the tweaks we need: https://github.com/snapcore/snapd/pull/9975#issuecomment-789489540 [12:54] PR #9975: tests: fix new tumbleweed image [12:54] mborzecki, yes I saw that, I'll include that in the next PR [12:55] cachio: cool, thank you! [12:55] snap run issue is happening since long time ago [12:55] the seg fault one [12:57] PR snapd#9975 closed: tests: fix new tumbleweed image [13:22] PR snapd#9988 opened: o/snapshotstate: create snapshots directory on import [13:25] Is there a manifest of what packages are used to form core20 somewhere? [13:25] I'm not sure if this the right place to ask. Which team makes the core images? [13:26] mborzecki: I reviewed 9921, it looks ok, but still a bit unsure if the helper has the right granularity [13:26] rbasak, /snap/core20/current/snap/manifest.yaml [13:26] rbasak: core20 is produced by foundations [13:26] ogra: perfect, thanks! And useful to know for next time, thanks pedronis [13:26] rbasak, though note that even though that lists the packages, bits and pieces of them might be removed [13:27] Sure [13:27] The issue is that I'm trying to work around snapcraft not including recursive dependencies stated in stage-packages when using a classic snap [13:27] I'm working through them one by one, which is really tedious. [13:27] hehm yeah [13:27] I thought I'd try the set difference between what I need, and what core20 includes [13:28] Uh [13:28] Intersection I guess [13:37] PR snapd#9989 opened: boot: reseal the run key for all recovery systems, but recovery keys only for the good ones [13:42] PR snapd#9990 opened: tests: fix tumbleweed spread tests part 2 [14:43] PR snapd#9977 closed: bootloader/lkenv: add recovery systems related variables [15:25] PR snapcraft#3460 opened: repo: introduce DebPackage class to standardize package name parsing [15:45] PR snapcraft#3459 closed: repo: account for arch & version when filtering stage packages [15:45] PR snapcraft#3461 opened: repo: account for arch & version when filtering stage packages [16:05] * cachio lunch [16:23] degville: btw did you finish that system user assertion doc you were working on and wanted me to review? [16:26] ijohnson: I did - I actually made my edits to the forum post. It would be really helpful if you wanted to take a look over it: https://discourse.ubuntu.com/t/system-user/19740 [16:27] degville: ah ok, I for some reason was waiting for a gdoc to review, I'll haea look at the forum then thanks [16:27] *have [16:27] just noticed that https://ubuntu.com/core/docs/system-user is a 404. I'll fix that. [16:28] ijohnson: thank you! [16:28] ijohnson: (feel free to paste it into a gdoc if it's easier for you to leave comments) [16:29] I'll just comment on the forum that's fine with me [16:29] (or edit it myself if it's trivial enough :-) ) [16:31] degville: actually doc looks great as-is thanks for all the work on it [16:32] ijohnson: brilliant, thanks for looking! [16:32] np [16:53] PR snapd#9991 opened: tests/main/lxd/prep-snapd-in-lxd.sh: dump contents of sources.list [17:09] oops store is unhappy now [17:11] yes, see ~is-outage on MM [17:11] yeah not a big deal for me, just noticed some tests failing in CI [17:33] PR snapd#9992 opened: snapstate: error is "snap refresh" has no updates because of conflicts === ijohnson is now known as ijohnson|lunch === ijohnson|lunch is now known as ijohnson [22:34] is there a way for a project to have multiple snapcraft.yaml files in it i.e. can we tell `snapcraft` cli too somehow to use a specific yaml file ? [23:44] om26er: no unfortunately not [23:45] ijohnson bummer! that'd make for a very useful feature for projects that want to do "variants" of their software [23:47] om26er: yeah it would be useful, you could try filing a bug/feature request at bugs launchpad.net/snapcraft