[06:05] morning [06:08] PR snapd#9078 closed: boot: fancy marshaller for modeenv values [06:32] good morning [06:33] PR snapd#9107 opened: tests: remove End-Of-Life releases from spread.yaml [06:35] zyga-x240: hey [06:36] hey :) [06:36] good morning zyga-x240 and mborzecki [06:36] I'm experimenting with a small idea that will give us a bit more CI speed [06:36] hey mvo :) [06:36] we can run the cla-check on self-hosted workers [06:37] this will release a slot for the more expensive unit test jobs [06:37] mvo: hey [06:38] zyga-x240: do we need to move the check to the tests yaml file or can this be changed in the github repo actions configuration? [06:38] just a tweak to the yaml [06:38] no need to change anything else [06:38] PR snapd#9088 closed: cmd/snap-preseed: use snapd from the deb if newer than from seeds

[06:38] I'm preparing the rest for this though [06:38] as the containers are unprivileged and devoid of sudo [06:38] though now that we have mvo around [06:38] I have one more idea :) [06:38] but that's for later [06:38] we can label workers [06:39] so we can create a subset of workers without spread keys [06:39] but with sudo [06:39] and we could use those for running unit tests (I have 4 spare cores at home, soon will have more) [06:39] with fast apt proxy and preinstalled snaps it will be speedy [06:40] on par with those over-provisioned xeons [06:43] PR snapd#9092 closed: interfaces/udev: do not reload udevadm rules when preseeding

[06:43] PR snapd#9093 closed: interfaces/kmod: don't load kernel modules in kmod backend when preseeding [06:43] PR snapd#9101 closed: interfaces/systemd: use emulation mode when preseeding [06:47] mvo: https://github.com/snapcore/snapd/pull/9107#pullrequestreview-463069566 [06:47] PR #9107: tests: remove End-Of-Life releases from spread.yaml [06:47] mvo: bw. we have two entries for debian-sid-64 in qemu backend [06:47] mborzecki: haha - fun [06:48] mvo: oh, and while at it, i think we can drop fedora-30 from google backend, it's EOL anyway [06:48] PR snapd#9108 opened: gadget, osutil: use atomic file copy, adjust tests (2.45) [06:48] mvo: left a comment there [06:51] zyga-x240: \o/ [06:53] we should try to get that 20.04-on-zfs image [06:53] I'd love to see it fail [07:02] mvo: hi, I fixed the conflicts in #9097, could you re-review it ? [07:02] PR #9097: boot/modeenv: add deepEqual, Copy helpers to simplify bootstate20 refactor [07:03] PR snapd#9020 closed: cmd: add new "snap recovery" command [07:05] zyga: https://github.com/snapcore/snapd/pull/9043 is probably in good shape to review now [07:05] PR #9043: daemon: replace access control flags on commands with access checkers [07:06] morning [07:07] hey pedronis, jamesh, pstolowski [07:07] ack, I'll look in a moment [07:07] pstolowski: good morning! does master have all the preseed bits we need for cpc? if so I will release a 2.46~pre1.gitXXX to groovy [07:08] PR snapd#9109 opened: github: run CLA checks on self-hosted workers [07:08] PR snapd#9110 opened: preseed: cherry-pick #8704, #8709, #9088 (2.45) [07:08] pedronis: thanks for pushing fixes to my PRs yesterday [07:09] np [07:10] mvo: yes [07:10] pstolowski: cool, releasing now then [07:10] ty! [07:13] woah [07:13] today is a good LTE day [07:13] I was just uploading at 200MBit rate [07:15] zyga-x240: maybe everyone else is on vacation? hence lots of available bandwidth [07:15] mborzecki: maybe [07:15] I was wondering if getting an external antenna would help [07:15] the BTS I'm talking to is ~ 30 meters away [07:16] maybe 50 [07:16] but I have to go through a bit of wall and glass [07:16] we could affix an antenna to the side of the house and just run the wires, the modem has two SMA connectors [07:17] mvo: the 2.45 thing is broken [07:17] src/github.com/snapcore/snapd/cmd/snap-preseed/preseed_linux.go:31:2: imported and not used: "github.com/snapcore/snapd/cmd/cmdutil" [07:17] src/github.com/snapcore/snapd/cmd/snap-preseed/preseed_linux.go:167:22: undefined: snapdtool [07:17] src/github.com/snapcore/snapd/cmd/snap-preseed/preseed_linux.go:175:21: un [07:17] something is not right [07:18] zyga-x240: oh no [07:18] zyga-x240: yeah, it's a PITA, it diverged quite a bit [07:18] zyga-x240: maybe the answer is really 2.46 :/ [07:18] *exactly* [07:18] we should really try [07:18] even if it goes nowhere but beta [07:19] we'd be backporting less [07:19] well, as long we do release .3.1 to stable [07:20] mvo: did you see the SANFU with systemd yesterday? [07:20] it's a bit unfortunate [07:20] I hope it doesn't affect regular users [07:20] upgrading in-place seems less and less supported [07:20] *SNAFU [07:20] how could I typo that :P [07:21] also jdstrand wanted things into 2.46 that he hasn't finished yet [07:21] I think having an early outlook would be great, after all it's all just a number, we could really finally push to stable something more like 2.46.3 [07:21] as I said, it's fine, we do need to release .3.1 though [07:22] I agree [07:24] * zyga-x240 reviews https://github.com/snapcore/snapd/pull/9043 [07:24] PR #9043: daemon: replace access control flags on commands with access checkers [07:25] zyga-x240: if you're uploading at 200mbit/s i doubt antennas would help [07:25] I wonder what's the limit of this class of modem [07:25] I, for one, will be on 5G the moment it is avaliable [07:26] zyga-x240: but, if your bts is heavily occupied, you may want to check other frequencies and force one that's rarely used by mobiles [07:26] unfortunately my firmware is pretty locked so I have almost no choice [07:26] on the upside I get pretty good overall speed so I think it's a pretty lucky location [07:26] there are BTSes all around here, maybe there are just enough [07:27] zyga-x240: usually 800mhz is quite busy, but 1.8ghz and 2.6 are not :P [07:32] brb [07:44] pstolowski: if I set "run-nested" will that also run the nested/manual suite? [07:48] mvo: heh, i don't know of "run-nested"... i was always invoking them manually with spread ... google-nested:...:tests/nested/manual/... [07:48] PR snapd#9111 opened: releases: release 2.46~pre1 to groovy [07:49] wow, it's warm today [07:49] pstolowski: I updated #9086 after your feedback [07:49] PR #9086: many: reorg cmd/snapinfo.go into snap and new client/clientutil [07:49] pedronis: yes, looking atm, ty [07:50] could we change things so that without run-nested there are "skips" not green ticks [08:00] * zyga-x240 returns to review after a small interrupt to fix a test [08:02] mvo, pedronis: could you please look at https://github.com/snapcore/snapd/pull/7825 and +1/-1 merging as-is [08:02] PR #7825: many: use transient scope for tracking apps and hooks

[08:02] it's +2 technically but I wanted to triple check [08:02] zyga-x240: you told me yesterday not to look at it :) [08:02] it's a +13 -355 leftover from the "backend" work [08:02] pedronis: yeah because yesterday it was not relevant :) [08:02] I mean, the other PRs were more interesting [08:03] as they contain new work that needs direction [08:03] this is just pushing a stone up the hill till it's done [08:03] PR snapd#9112 opened: tests: run as hightest via tests.session [08:29] jamesh: around? [08:29] jamesh: https://github.com/snapcore/snapd/pull/9043#pullrequestreview-463128041 (partial to ask a question) [08:29] PR #9043: daemon: replace access control flags on commands with access checkers [08:29] I'm reading the rest [08:29] zyga-x240: yeah [08:33] zyga-x240: the ucred == nil case would be true if the REST API was available via TCP. It should always be non-nil for unix domain sockets [08:34] I see [08:34] in that case I think we should do what I suggested in the second comment [08:34] it's safer this way [08:34] zyga-x240: this effectively makes the existing GuestOK vs UserOK distinction meaningless [08:34] we can revisit this once we have http [08:34] I'll review the rest carefully [08:34] if you want and agree please push that change to the existing checkers [08:34] I would feel much safer with an early != nil check [08:36] zyga-x240: probably a good idea, on the basis of not making access decisions prematurely [08:40] mvo: we could set 'run nested' label on #9102 [08:40] PR #9102: corecfg: add "system.timezone" setting to the system settings [08:42] pstolowski: yeah, that's why I was asking earlier [08:42] mvo: aaah, sorry, i didn't have enough coffee, i though it was about run-checks etc [08:48] PR snapd#9113 opened: tests: port regression-home-snap-root-owned to tests.session [10:42] jamesh: https://github.com/snapcore/snapd/pull/9043#pullrequestreview-463139716 [10:42] PR #9043: daemon: replace access control flags on commands with access checkers [10:42] sorry for taking this long, I was really trying to think through the various consequences [11:08] brb [11:08] quick coffee :) [11:10] pedronis: i updated #9001 [11:10] PR #9001: o/snapshotstate: helpers for calculating disk space needed for an automatic snapshot (2/N) <⛔ Blocked> [11:12] hmm, wot, unit test failed on FAIL: cmd_sign_test.go:55: SnapKeysSuite.TestHappyNonDefaultKey, seems like it called real gpg? [11:13] what was the rest of the failure? [11:14] I saw something like this today as well [11:14] PR snapd#9114 opened: tests: fix debug section of appstream-id test [11:15] zyga-x240: value *errors.errorString = &errors.errorString{s:"cannot sign assertion: bad GPG produced signature: it does not verify: openpgp: invalid signature: RSA verification failure" [11:16] zyga-x240: i'm looking into it [11:16] yeah, same error [11:16] cool [11:16] thanks! [11:16] * zyga-x240 stops coding and goes for that coffee [11:37] mborzecki: we are hitting some kind of new issue on centos related to selinux and package versions: https://github.com/snapcore/snapd/pull/9097/checks?check_run_id=957590501 [11:37] PR #9097: boot/modeenv: add deepEqual, Copy helpers to simplify bootstate20 refactor [11:38] we also got again the weird 16.04 with different cgroup setup [11:38] pedronis: hmm, let me check that [11:39] pedronis: uhh, yeah that's the usual upgrade thing where centos is lagging behind rhel again [11:44] PR snapd#9097 closed: boot/modeenv: add deepEqual, Copy helpers to simplify bootstate20 refactor [11:44] PR snapd#9105 closed: tests: work around bug in systemd/debian <⚠ Critical> [11:46] pstolowski: https://github.com/snapcore/snapd/pull/9115 [11:46] PR #9115: interfaces: check !b.preseed earlier [11:46] pedronis: I'll look at the cgroup mystery as well [11:47] mborzecki: do you have any ideas? I'd like to ensure we boot the right kernel - depending on the spread system [11:47] +1, ty [11:47] mborzecki: and then depending on the kernel that some super basic things hold (I know it intersects with systemd so I'd like to just constrain this to xenial for now) [11:47] morning folks [11:47] ijohnson: good morning! [11:48] hey zyga-x240 [11:48] zyga-x240: simple sanity checks are probably ok [11:48] how are tests today [11:48] seems like centos and cgroups are giving us trouble still [11:48] zyga-x240: i mean, those distros are kind of fixed, so we know what to expect on each system [11:49] PR snapd#9115 opened: interfaces: check !b.preseed earlier [11:49] yeah [11:50] mborzecki: I'll do that [11:50] I'm very curious to find out what we get [11:52] mvo: in case you didn't figure it out adding the run-nested label to a PR only works if you add the label before opening it, or close and re-open the PR after adding the label [11:52] at least that's been my experience [11:53] hmm i cannot repro cmd_sign_test issue [11:53] hey ijohnson ! [11:53] hey pstolowski [11:54] thanks for all the iface backend PR's [11:54] sure thing, thanks for reviews [11:58] pstolowski: it's very rare [11:58] pstolowski: maybe leave it on repeat -1000 [12:03] grr mounted fs updater [12:03] ? [12:03] what? [12:04] zyga-x240: have you seen it outside of 16.04? [12:04] pstolowski: I don't recall where I saw that [12:10] zyga-x240: the changes for the content update observer are slightly annoying [12:10] so are the tests [12:10] hmm? [12:10] content update observer> [12:10] ? [12:11] zyga: yes, the resealing & gadget updates things i'm working on [12:12] zyga: hm pagure badges? wtf? [12:13] haha, for updates? [12:14] yeah, but it looks buggy, i haven't pushed 1000 commits into pagure [12:24] mborzecki, cmatsuoka i've requested your re-reviews on #9001 because of the changes after addressing Samuele's comment [12:24] PR #9001: o/snapshotstate: helpers for calculating disk space needed for an automatic snapshot (2/N) [12:24] pstolowski: ack, will do [12:26] thx [12:26] pedronis: btw. in the morning in saw 408 with a GET request from a run that happend within the last 24h [12:29] pstolowski: checking [12:29] hey cmatsuoka [12:29] zyga: hi [12:31] zyga: how's the pain? feeling better? [12:31] yeah it's really comfortable now [12:31] a bit hot today but now I'm just looking for execuses [12:32] haha, ok [12:39] PR snapd#9108 closed: gadget, osutil: use atomic file copy, adjust tests (2.45) [12:39] PR snapd#9114 closed: tests: fix debug section of appstream-id test [12:39] PR snapd#9115 closed: interfaces: check !b.preseed earlier [12:39] PR snapd#9116 opened: tests: adding system information and image information when debug info is equired [12:39] thanks mvo [12:42] thanks for the review pedronis [12:43] zyga: thank you! [12:44] mvo if you are reviewing could you please advice on the last comment on https://github.com/snapcore/snapd/pull/7825 [12:44] PR #7825: many: use transient scope for tracking apps and hooks

[12:44] PR snapd#9107 closed: tests: remove End-Of-Life releases from spread.yaml [12:44] PR snapd#9117 opened: tests: remove End-Of-Life opensuse/fedora releases [12:44] should I keep splitting? [12:47] zyga: looking [12:48] zyga: that seems fine - but 7825 just rmeoves code now it seems from a casual look? [12:49] yes, and removes a workaround needed earlier [12:49] zyga: what would you split from it? all the additions to make it removal only? [12:49] should I get more reviews, split it further or do something else? [12:49] just the removal for the explicit review [12:50] and leave the few odd tweaks (+13) as-is [12:50] zyga: the problem with that PR at moment is that it has 197 commits and a description that I'm not sure matches the content anymore [12:51] that's fine, I really want to merge it to keep the history in place [12:51] as I said, I'm happy to shave it further [12:51] just looking for advice [12:51] isn't the history in all the PR that landed before this one? [12:52] they contain a subset [12:53] also I would love to just merge it eventuallu [12:53] it's almost complete subset, no, if all we are left is removing and +13 ? [12:53] eventyally* [12:53] yes but commit history here is more detailed [12:53] *eventually, sorry [12:53] still learning the new keyboard [12:54] you are saying that in master it will look like things came from two places? [12:54] that seems confusing to me [12:55] no, master will contain a merge commit [12:55] you can dig deeper to see that [12:55] if you annotate master it will show what it shows currently [12:55] as that is not changed [12:55] but I think there's some useful information in that history [12:57] I think I need to play with it a bit, I'm trying to understand the useful vs confusing factor here [12:59] git merge that into a test branch and tell me if that is confusing [12:59] anyway, time for standup [13:04] PR snapd#9118 opened: tests: detect unexpected xenial kernels [13:30] PR snapd#9119 opened: many: remove usage and creation of hijacked pid cgroup [13:31] pstolowski speaking of gpg it just failed [13:31] https://github.com/snapcore/snapd/pull/9118/checks?check_run_id=958332953 [13:31] PR #9118: tests: detect unexpected xenial kernels