[06:05] <mborzecki> morning
[06:08] <mup> PR snapd#9078 closed: boot: fancy marshaller for modeenv values <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9078>
[06:32] <zyga-x240> good morning
[06:33] <mup> PR snapd#9107 opened: tests: remove End-Of-Life releases from spread.yaml <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9107>
[06:35] <mborzecki> zyga-x240: hey
[06:36] <zyga-x240> hey :)
[06:36] <mvo> good morning zyga-x240 and mborzecki
[06:36] <zyga-x240> I'm experimenting with a small idea that will give us a bit more CI speed
[06:36] <zyga-x240> hey mvo :)
[06:36] <zyga-x240> we can run the cla-check on self-hosted workers
[06:37] <zyga-x240> this will release a slot for the more expensive unit test jobs
[06:37] <mborzecki> mvo: hey
[06:38] <mborzecki> 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] <zyga-x240> just a tweak to the yaml
[06:38] <zyga-x240> no need to change anything else
[06:38] <mup> PR snapd#9088 closed: cmd/snap-preseed: use snapd from the deb if newer than from seeds <Preseeding 🍞> <Run nested> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9088>
[06:38] <zyga-x240> I'm preparing the rest for this though
[06:38] <zyga-x240> as the containers are unprivileged and devoid of sudo
[06:38] <zyga-x240> though now that we have mvo around
[06:38] <zyga-x240> I have one more idea :)
[06:38] <zyga-x240> but that's for later
[06:38] <zyga-x240> we can label workers
[06:39] <zyga-x240> so we can create a subset of workers without spread keys
[06:39] <zyga-x240> but with sudo
[06:39] <zyga-x240> and we could use those for running unit tests (I have 4 spare cores at home, soon will have more)
[06:39] <zyga-x240> with fast apt proxy and preinstalled snaps it will be speedy
[06:40] <zyga-x240> on par with those over-provisioned xeons
[06:43] <mup> PR snapd#9092 closed: interfaces/udev: do not reload udevadm rules when preseeding <Bug> <Preseeding 🍞> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9092>
[06:43] <mup> PR snapd#9093 closed: interfaces/kmod: don't load kernel modules in kmod backend when preseeding <Bug> <Preseeding 🍞> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9093>
[06:43] <mup> PR snapd#9101 closed: interfaces/systemd: use emulation mode when preseeding <Bug> <Preseeding 🍞> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9101>
[06:47] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/9107#pullrequestreview-463069566
[06:47] <mup> PR #9107: tests: remove End-Of-Life releases from spread.yaml <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9107>
[06:47] <mborzecki> mvo: bw. we have two entries for debian-sid-64 in qemu backend
[06:47] <mvo> mborzecki: haha - fun
[06:48] <mborzecki> mvo: oh, and while at it, i think we can drop fedora-30 from google backend, it's EOL anyway
[06:48] <mup> PR snapd#9108 opened:  gadget, osutil: use atomic file copy, adjust tests (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/9108>
[06:48] <zyga-x240> mvo: left a comment there
[06:51] <mvo> zyga-x240: \o/
[06:53] <zyga-x240> we should try to get that 20.04-on-zfs image
[06:53] <zyga-x240> I'd love to see it fail
[07:02] <pedronis> mvo: hi, I fixed the conflicts in #9097, could you re-review it ?
[07:02] <mup> PR #9097: boot/modeenv: add deepEqual, Copy helpers to simplify bootstate20 refactor <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9097>
[07:03] <mup> PR snapd#9020 closed: cmd: add new "snap recovery" command <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9020>
[07:05] <jamesh> zyga: https://github.com/snapcore/snapd/pull/9043 is probably in good shape to review now
[07:05] <mup> PR #9043: daemon: replace access control flags on commands with access checkers <Needs security review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9043>
[07:06] <pstolowski> morning
[07:07] <zyga-x240> hey pedronis, jamesh, pstolowski
[07:07] <zyga-x240> ack, I'll look in a moment
[07:07] <mvo> 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] <mup> PR snapd#9109 opened: github: run CLA checks on self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/9109>
[07:08] <mup> PR snapd#9110 opened: preseed: cherry-pick #8704, #8709, #9088 (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/9110>
[07:08] <mborzecki> pedronis: thanks for pushing fixes to my PRs yesterday
[07:09] <pedronis> np
[07:10] <pstolowski> mvo: yes
[07:10] <mvo> pstolowski: cool, releasing now then
[07:10] <pstolowski> ty!
[07:13] <zyga-x240> woah
[07:13] <zyga-x240> today is a good LTE day
[07:13] <zyga-x240> I was just uploading at 200MBit rate
[07:15] <mborzecki> zyga-x240: maybe everyone else is on vacation? hence lots of available bandwidth
[07:15] <zyga-x240> mborzecki: maybe
[07:15] <zyga-x240> I was wondering if getting an external antenna would help
[07:15] <zyga-x240> the BTS I'm talking to is ~ 30 meters away
[07:16] <zyga-x240> maybe 50
[07:16] <zyga-x240> but I have to go through a bit of wall and glass
[07:16] <zyga-x240> we could affix an antenna to the side of the house and just run the wires, the modem has two SMA connectors
[07:17] <zyga-x240> mvo: the 2.45 thing is broken
[07:17] <zyga-x240> 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] <zyga-x240> src/github.com/snapcore/snapd/cmd/snap-preseed/preseed_linux.go:167:22: undefined: snapdtool
[07:17] <zyga-x240> src/github.com/snapcore/snapd/cmd/snap-preseed/preseed_linux.go:175:21: un
[07:17] <zyga-x240> something is not right
[07:18] <mvo> zyga-x240: oh no
[07:18] <mvo> zyga-x240: yeah, it's a PITA, it diverged quite a bit
[07:18] <mvo> zyga-x240: maybe the answer is really 2.46 :/
[07:18] <zyga-x240> *exactly*
[07:18] <zyga-x240> we should really try
[07:18] <zyga-x240> even if it goes nowhere but beta
[07:19] <zyga-x240> we'd be backporting less
[07:19] <pedronis> well, as long we do release .3.1 to stable
[07:20] <zyga-x240> mvo: did you see the SANFU with systemd yesterday?
[07:20] <zyga-x240> it's a bit unfortunate
[07:20] <zyga-x240> I hope it doesn't affect regular users
[07:20] <zyga-x240> upgrading in-place seems less and less supported
[07:20] <zyga-x240> *SNAFU
[07:20] <zyga-x240> how could I typo that :P
[07:21] <pedronis> also jdstrand wanted things into 2.46 that he hasn't finished yet
[07:21] <zyga-x240> 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] <pedronis> as I said, it's fine, we do need to release .3.1 though
[07:22] <zyga-x240> I agree
[07:24]  * zyga-x240 reviews https://github.com/snapcore/snapd/pull/9043
[07:24] <mup> PR #9043: daemon: replace access control flags on commands with access checkers <Needs security review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9043>
[07:25] <mborzecki> zyga-x240: if you're uploading at 200mbit/s i doubt antennas would help
[07:25] <zyga-x240> I wonder what's the limit of this class of modem
[07:25] <zyga-x240> I, for one, will be on 5G the moment it is avaliable
[07:26] <mborzecki> 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] <zyga-x240> unfortunately my firmware is pretty locked so I have almost no choice
[07:26] <zyga-x240> on the upside I get pretty good overall speed so I think it's a pretty lucky location
[07:26] <zyga-x240> there are BTSes all around here, maybe there are just enough
[07:27] <mborzecki> zyga-x240: usually 800mhz is quite busy, but 1.8ghz and 2.6 are not :P
[07:32] <zyga-x240> brb
[07:44] <mvo> pstolowski: if I set "run-nested" will that also run the nested/manual suite?
[07:48] <pstolowski> mvo: heh, i don't know of "run-nested"...  i was always invoking them manually with spread ... google-nested:...:tests/nested/manual/...
[07:48] <mup> PR snapd#9111 opened: releases: release 2.46~pre1 to groovy <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9111>
[07:49] <mborzecki> wow, it's warm today
[07:49] <pedronis> pstolowski: I updated #9086 after your feedback
[07:49] <mup> PR #9086: many: reorg cmd/snapinfo.go into snap and new client/clientutil <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9086>
[07:49] <pstolowski> pedronis: yes, looking atm, ty
[07:50] <zyga-x240> 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] <zyga-x240> mvo, pedronis: could you please look at https://github.com/snapcore/snapd/pull/7825 and +1/-1 merging as-is
[08:02] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[08:02] <zyga-x240> it's +2 technically but I wanted to triple check
[08:02] <pedronis> zyga-x240: you told me yesterday not to look at it :)
[08:02] <zyga-x240> it's a +13 -355 leftover from the "backend" work
[08:02] <zyga-x240> pedronis: yeah because yesterday it was not relevant :)
[08:02] <zyga-x240> I mean, the other PRs were more interesting
[08:03] <zyga-x240> as they contain new work that needs direction
[08:03] <zyga-x240> this is just pushing a stone up the hill till it's done
[08:03] <mup> PR snapd#9112 opened: tests: run as hightest via tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9112>
[08:29] <zyga-x240> jamesh: around?
[08:29] <zyga-x240> jamesh: https://github.com/snapcore/snapd/pull/9043#pullrequestreview-463128041 (partial to ask a question)
[08:29] <mup> PR #9043: daemon: replace access control flags on commands with access checkers <Needs security review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9043>
[08:29] <zyga-x240> I'm reading the rest
[08:29] <jamesh> zyga-x240: yeah
[08:33] <jamesh> 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] <zyga-x240> I see
[08:34] <zyga-x240> in that case I think we should do what I suggested in the second comment
[08:34] <zyga-x240> it's safer this way
[08:34] <jamesh> zyga-x240: this effectively makes the existing GuestOK vs UserOK distinction meaningless
[08:34] <zyga-x240> we can revisit this once we have http
[08:34] <zyga-x240> I'll review the rest carefully
[08:34] <zyga-x240> if you want and agree please push that change to the existing checkers
[08:34] <zyga-x240> I would feel much safer with an early != nil check
[08:36] <jamesh> zyga-x240: probably a good idea, on the basis of not making access decisions prematurely
[08:40] <pstolowski> mvo: we could set 'run nested' label on #9102
[08:40] <mup> PR #9102: corecfg: add "system.timezone" setting to the system settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/9102>
[08:42] <mvo> pstolowski: yeah, that's why I was asking earlier
[08:42] <pstolowski> mvo: aaah, sorry, i didn't have enough coffee, i though it was about run-checks etc
[08:48] <mup> PR snapd#9113 opened: tests: port regression-home-snap-root-owned to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9113>
[10:42] <zyga-x240> jamesh: https://github.com/snapcore/snapd/pull/9043#pullrequestreview-463139716
[10:42] <mup> PR #9043: daemon: replace access control flags on commands with access checkers <Needs security review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9043>
[10:42] <zyga-x240> sorry for taking this long, I was really trying to think through the various consequences
[11:08] <zyga-x240> brb
[11:08] <zyga-x240> quick coffee :)
[11:10] <pstolowski> pedronis: i updated #9001
[11:10] <mup> PR #9001: o/snapshotstate: helpers for calculating disk space needed for an automatic snapshot (2/N) <Disk space awareness> <Needs Samuele review> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9001>
[11:12] <pstolowski> hmm, wot, unit test failed on FAIL: cmd_sign_test.go:55: SnapKeysSuite.TestHappyNonDefaultKey, seems like it called real gpg?
[11:13] <zyga-x240> what was the rest of the failure?
[11:14] <zyga-x240> I saw something like this today as well
[11:14] <mup> PR snapd#9114 opened: tests: fix debug section of appstream-id test <Simple 😃> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9114>
[11:15] <pstolowski> 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] <pstolowski> zyga-x240: i'm looking into it
[11:16] <zyga-x240> yeah, same error
[11:16] <zyga-x240> cool
[11:16] <zyga-x240> thanks!
[11:16]  * zyga-x240 stops coding and goes for that coffee
[11:37] <pedronis> 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] <mup> PR #9097: boot/modeenv: add deepEqual, Copy helpers to simplify bootstate20 refactor <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9097>
[11:38] <pedronis> we also got again the weird 16.04 with different cgroup setup
[11:38] <mborzecki> pedronis: hmm, let me check that
[11:39] <mborzecki> pedronis: uhh, yeah that's the usual upgrade thing where centos is lagging behind rhel again
[11:44] <mup> PR snapd#9097 closed: boot/modeenv: add deepEqual, Copy helpers to simplify bootstate20 refactor <Simple 😃> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9097>
[11:44] <mup> PR snapd#9105 closed: tests: work around bug in systemd/debian <Test Robustness> <⚠ Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9105>
[11:46] <zyga-x240> pstolowski: https://github.com/snapcore/snapd/pull/9115
[11:46] <mup> PR #9115: interfaces: check !b.preseed earlier <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/9115>
[11:46] <zyga-x240> pedronis: I'll look at the cgroup mystery as well
[11:47] <zyga-x240> mborzecki: do you have any ideas? I'd like to ensure we boot the right kernel - depending on the spread system
[11:47] <pstolowski> +1, ty
[11:47] <zyga-x240> 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] <ijohnson> morning folks
[11:47] <zyga-x240> ijohnson: good morning!
[11:48] <ijohnson> hey zyga-x240
[11:48] <mborzecki> zyga-x240: simple sanity checks are probably ok
[11:48] <ijohnson> how are tests today
[11:48] <ijohnson> seems like centos and cgroups are giving us trouble still
[11:48] <mborzecki> zyga-x240: i mean, those distros are kind of fixed, so we know what to expect on each system
[11:49] <mup> PR snapd#9115 opened: interfaces: check !b.preseed earlier <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/9115>
[11:49] <zyga-x240> yeah
[11:50] <zyga-x240> mborzecki: I'll do that
[11:50] <zyga-x240> I'm very curious to find out what we get
[11:52] <ijohnson> 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] <ijohnson> at least that's been my experience
[11:53] <pstolowski> hmm i cannot repro cmd_sign_test issue
[11:53] <pstolowski> hey ijohnson !
[11:53] <ijohnson> hey pstolowski
[11:54] <ijohnson> thanks for all the iface backend PR's
[11:54] <pstolowski> sure thing, thanks for reviews
[11:58] <zyga-x240> pstolowski: it's very rare
[11:58] <zyga-x240> pstolowski: maybe leave it on repeat -1000
[12:03] <mborzecki> grr mounted fs updater
[12:03] <zyga-x240> ?
[12:03] <zyga-x240> what?
[12:04] <pstolowski> zyga-x240: have you seen it outside of 16.04?
[12:04] <zyga-x240> pstolowski: I don't recall where I saw that
[12:10] <mborzecki> zyga-x240: the changes for the content update observer are slightly annoying
[12:10] <mborzecki> so are the tests
[12:10] <zyga> hmm?
[12:10] <zyga> content update observer>
[12:10] <zyga> ?
[12:11] <mborzecki> zyga: yes, the resealing & gadget updates things i'm working on
[12:12] <mborzecki> zyga: hm pagure badges? wtf?
[12:13] <zyga> haha, for updates?
[12:14] <mborzecki> yeah, but it looks buggy, i haven't pushed 1000 commits into pagure
[12:24] <pstolowski> mborzecki, cmatsuoka i've requested your re-reviews on #9001 because of the changes after addressing Samuele's comment
[12:24] <mup> PR #9001: o/snapshotstate: helpers for calculating disk space needed for an automatic snapshot (2/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9001>
[12:24] <mborzecki> pstolowski: ack, will do
[12:26] <pstolowski> thx
[12:26] <mborzecki> pedronis: btw. in the morning in saw 408 with a GET request from a run that happend within the last 24h
[12:29] <cmatsuoka> pstolowski: checking
[12:29] <zyga> hey cmatsuoka
[12:29] <cmatsuoka> zyga: hi
[12:31] <cmatsuoka> zyga: how's the pain? feeling better?
[12:31] <zyga> yeah it's really comfortable now
[12:31] <zyga> a bit hot today but now I'm just looking for execuses
[12:32] <cmatsuoka> haha, ok
[12:39] <mup> PR snapd#9108 closed:  gadget, osutil: use atomic file copy, adjust tests (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9108>
[12:39] <mup> PR snapd#9114 closed: tests: fix debug section of appstream-id test <Simple 😃> <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9114>
[12:39] <mup> PR snapd#9115 closed: interfaces: check !b.preseed earlier <Simple 😃> <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9115>
[12:39] <mup> PR snapd#9116 opened: tests: adding system information and image information when debug info is equired <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9116>
[12:39] <zyga> thanks mvo
[12:42] <ijohnson> thanks for the review pedronis
[12:43] <mvo> zyga: thank you!
[12:44] <zyga> mvo if you are reviewing could you please advice on the last comment on https://github.com/snapcore/snapd/pull/7825
[12:44] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[12:44] <mup> PR snapd#9107 closed: tests: remove End-Of-Life releases from spread.yaml <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9107>
[12:44] <mup> PR snapd#9117 opened: tests: remove End-Of-Life opensuse/fedora releases <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9117>
[12:44] <zyga> should I keep splitting?
[12:47] <mvo> zyga: looking
[12:48] <mvo> zyga: that seems fine - but 7825 just rmeoves code now it seems from a casual look?
[12:49] <zyga> yes, and removes a workaround needed earlier
[12:49] <pedronis> zyga: what would you split from it?  all the additions to make it removal only?
[12:49] <zyga> should I get more reviews, split it further or do something else?
[12:49] <zyga> just the removal for the explicit review
[12:50] <zyga> and leave the few odd tweaks (+13) as-is
[12:50] <pedronis> 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] <zyga> that's fine, I really want to merge it to keep the history in place
[12:51] <zyga> as I said, I'm happy to shave it further
[12:51] <zyga> just looking for advice
[12:51] <pedronis> isn't the history in all the PR that landed before this one?
[12:52] <zyga> they contain a subset
[12:53] <zyga> also I would love to just merge it eventuallu
[12:53] <pedronis> it's almost complete subset, no, if all we are left is removing and +13 ?
[12:53] <zyga> eventyally*
[12:53] <zyga> yes but commit history here is more detailed
[12:53] <zyga> *eventually, sorry
[12:53] <zyga> still learning the new keyboard
[12:54] <pedronis> you are saying that in master it will look like things came from two places?
[12:54] <pedronis> that seems confusing to me
[12:55] <zyga> no, master will contain a merge commit
[12:55] <zyga> you can dig deeper to see that
[12:55] <zyga> if you annotate master it will show what it shows currently
[12:55] <zyga> as that is not changed
[12:55] <zyga> but I think there's some useful information in that history
[12:57] <pedronis> I think I need to play with it a bit, I'm trying to understand the useful vs confusing factor here
[12:59] <zyga> git merge that into a test branch and tell me if that is confusing
[12:59] <zyga> anyway, time for standup
[13:04] <mup> PR snapd#9118 opened: tests: detect unexpected xenial kernels <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9118>
[13:30] <mup> PR snapd#9119 opened: many: remove usage and creation of hijacked pid cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/9119>
[13:31] <zyga> pstolowski speaking of gpg it just failed
[13:31] <zyga> https://github.com/snapcore/snapd/pull/9118/checks?check_run_id=958332953
[13:31] <mup> PR #9118: tests: detect unexpected xenial kernels <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9118>
[13:31] <pstolowski> zyga: wow
[13:31] <zyga> in azure-hosted unit tests
[13:31] <zyga> so perhaps running it in spread is useless
[13:31] <zyga> as it fails in a different env
[13:32] <pstolowski> zyga: seems to be more frequent than before then
[13:43] <mborzecki> errand, bbl
[13:56] <niemeyer> Hmm.. still don't have anything in calendar for the next hour
[13:57] <niemeyer> ijohnson: Doesn't seem to have worked
[13:57] <ijohnson> niemeyer: hmm let me try again
[13:58] <niemeyer> Got the one from mvo though
[13:59] <ijohnson> niemeyer: ok, well I just re-sent it, so hopefully you can see the link to join
[14:09] <zyga> niemeyer I see your're invited there
[14:09] <zyga> but not accepted
[14:09] <niemeyer> zyga: It's been fixed
[14:09] <niemeyer> Thanks
[14:09] <niemeyer> (I've been in the call)
[14:10] <zyga> ah, good
[14:12] <zyga> I think I need a shower
[14:12] <zyga> 32C
[14:12] <zyga> it's a hot day
[14:20] <cachio> zyga, this is the error that I saw https://paste.ubuntu.com/p/DrXNkRyNxm/
[14:21] <cachio> and this https://paste.ubuntu.com/p/KrFm3H9Xt6/
[14:46] <jdstrand> pedronis: wrt 2.46, I'm actively working on various items for k8s, I will be picking up the cups-control/cups pr after that, the pickup 8301, then go through the list of misc policy updates. that should all be happening in the next week
[14:48] <jdstrand> pedronis: I also need to review jamesh' dbus PR and go down the list of whatever needs security review
[14:54] <zyga> cachio looking
[15:15] <pedronis> jdstrand: ok, I think mvo might have more sense about 2.46 timelines early next week
[15:15] <mvo> pedronis, jdstrand in a meeting but yes, first 2.46~pre early next week, groovy has it already
[15:16] <pedronis> ijohnson: I did another pass, my main comment is that more bits probably need "On commit" preambles
[15:17] <ijohnson> pedronis: thanks yeah I saw the other places I will try to do a full pass over all relevant comments
[15:25] <mup> PR snapd#9120 opened: interfaces: add kernel-crypto-api interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9120>
[15:26] <jdstrand> pedronis: at your convenience, would you mind at least reviewing the interface name in ^
[15:26]  * jdstrand adds appropriate label for that
[15:27] <zyga> cachio I hope we can detect the cause of that cgroup weirdness soon
[15:27] <zyga> hey jdstrand :-)
[15:27] <zyga> good to see you again
[15:27] <zyga> I'll break for lunch because I'm starving
[15:28] <cachio> zyga, I re executed but couldn't reproduce so far
[15:28] <cachio> I'll ping you if I have more info
[15:28] <pedronis> jdstrand: thx, I'll try to look earl next week. My initial comment is that we don't have any other *-api named interface, though many are for apis though
[15:28] <jdstrand> kenvandine: boy, I don't know what has been going on lately but on my focal host and firefox snap, periodically the fonts show the little utf-8 boxes and I have to restart the browser. I think jamesh was looking at that some (or at least commented on something similar in the forum)?
[15:29] <jdstrand> pedronis: yeah. I picked that because that appears to be how everyone refers to it
[15:29] <jdstrand> pedronis: ie, I wasn't using -api as a new suffix, I was thinking of 'kernel-crypto-api' as like 'mir'
[15:29] <jdstrand> pedronis: fyi for your review next week
[15:30] <jdstrand> s/fyi/context/
[15:31] <jdstrand> mvo: actually, iirc, you did an fc-cache update lately for that ^ (is this the libfreetype mismatch?)
[15:31] <jdstrand> hey zyga :)
[15:31] <kenvandine> jdstrand: yeah, i've seen that once myself.  I could not figure out what's going on there
[15:31] <jdstrand> zyga: you too! hey, I've been looking for us being on at the same time. did you see my comment in https://forum.snapcraft.io/t/alternate-home-workaround-request/18679/11 ?
[15:32] <kenvandine> it only started happening when we updated firefox to use the new platform
[15:32] <jdstrand> kenvandine: it basically happens at least once a day for me
[15:32] <kenvandine> wow
[15:32] <jdstrand> sometimes more often
[15:32] <kenvandine> it hasn't happened to me in months
[15:32] <kenvandine> jdstrand: if you could try to debug it... i would really appreciate it :)
[15:32] <kenvandine> very interesting that it's that common for you
[15:33] <jdstrand> kenvandine: I don't really know what to look for... do you have debugging instructions?
[15:33] <kenvandine> i think to start with run firefox from a terminal
[15:33] <jdstrand> also, I don't really have time atm. but I guess if it keeps happening, I can try
[15:33] <kenvandine> and grab stdout when it happens
[15:33] <kenvandine> when you have time, i would appreciate it
[15:34] <kenvandine> i can't figure out what triggers it
[15:34] <zyga> jdstrand, let me check
[15:34] <zyga> I didn't read that yet
[15:34] <zyga> but first food
[15:35] <jdstrand> kenvandine: ok, I restarted it from a terminal. let's hope I don't accidentally close it :)
[15:35] <kenvandine> jdstrand: thanks!
[15:41] <ijohnson> jdstrand: kenvandine: if it is the issue that mvo fixed with freetype update to the fc-cache binary in the snapd snap, it will happen when snapd updates _any_ snap
[15:42] <ijohnson> so if you see snap changes that happen around the time that those font boxes show up, that could probably be it
[15:42] <kenvandine> ijohnson: has that fix landed?
[15:42] <ijohnson> and also I don't think mvo's fix has made it to stable, I think it's still on edge iirc
[15:42] <kenvandine> ah
[15:42] <kenvandine> i'm on edge
[15:42] <kenvandine> so maybe why i haven't seen it
[15:42] <kenvandine> perhaps :)
[15:43] <ijohnson> we are a bit behind getting things to stable with 2.46, had many things come up with required 2.45.x :-)
[15:43] <ijohnson> kenvandine: well that's great actually since it seems to imply that the fix worked
[15:43] <ijohnson> jdstrand: what version of snapd have you been tracking? if it is not edge then probably you have this bug and it may go away if you track snapd edge
[15:43] <kenvandine> question is what's jdstrand running :)
[15:46] <mborzecki> re
[15:50] <pedronis> I'm using snapd from edge and I still get boxes in firefox sometimes
[15:52] <ijohnson> pedronis: but do you get them _less often_ :-) ?
[15:52] <pedronis> maybe
[15:52] <zyga-x240> mvo: 19.10 removal has weird effects
[15:53] <mborzecki> better boxes than immedia segfaults
[15:53] <zyga-x240> 19.10 fails on https://github.com/snapcore/snapd/pull/9119
[15:53] <mup> PR #9119: many: remove usage and creation of hijacked pid cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/9119>
[15:54] <zyga-x240> but it's not there
[15:55] <ijohnson> cachio: 8942 needs another review, it changed significantly since pstolowski's review unfortunately I think
[15:55] <ijohnson> cachio: but I +1d it just now
[15:56] <cachio> ijohnson, nice, thanks a lot
[15:56] <cachio> pstolowski, if you could take a look it should be awasome
[15:57]  * mvo is in a meeting
[16:05]  * cachio lunch
[16:10] <mup> PR snapd#9121 opened: github: remove Ubuntu 19.10 from actions workflow <Simple 😃> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9121>
[16:13] <pstolowski> cachio: i'll, but on monday at this point, eow now
[16:14] <jdstrand> ijohnson: snapd 2.45.3.1+git2475.g9bb0e0c from edge
[16:14] <jdstrand> 8916
[16:15]  * jdstrand wonders if it is happening daily since he is tracking edge and the caches are getting out of date
[16:15] <jdstrand> out of sync*
[16:15] <ijohnson> jdstrand: mmm ok so your bug is probably not fixed by that PR
[16:15] <jdstrand> sorry, I have 2.45.3.1+git2463.gaf15176 installed, snap refresh hasn't yet happened today
[16:16] <ijohnson> But also yes tracking edge would result in more font cache re builds
[16:16] <jdstrand> 8906 is what is installed
[16:18] <jdstrand> actually, I could test that theory
[16:18]  * jdstrand snap refreshes snapd
[16:21] <jdstrand> that alone didn't seem to cause the problem
[16:22] <jdstrand> unless the fix came in between 8906 and 8916
[16:22] <zyga-x240> jdstrand: purge cache, restart all apps
[16:22] <zyga-x240> and see if something breaks
[16:24] <ijohnson> jdstrand: the PR was not to snapd directly but rather to fc-cache-static-builder
[16:24] <ijohnson> https://github.com/snapcore/fc-cache-static-builder/pull/2
[16:24] <mup> PR fc-cache-static-builder#2: build freetype from the security pocket too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/fc-cache-static-builder/pull/2>
[16:28] <jdstrand> ijohnson: right-- and where does my system get that?
[16:29] <ijohnson> jdstrand it's built in the snapd snap
[16:29] <jdstrand> that was merged more than a month ago. certainly that was in 8906...
[16:29] <ijohnson> So shortly after that PR was merged the next edge snapd snap build would have got it
[16:29] <ijohnson> Yes it certainly is in 8906
[16:29]  * jdstrand nods
[16:30] <mborzecki> one more tweak to the update observer branch and eow
[16:31] <jdstrand> zyga-x240: are you talking about ./.cache/fontconfig/ ? how would removing all that be a valid reproducer? (ie, I'm personally not doing that, is something else?)
[16:31] <zyga-x240> jdstrand: I think cache is only written to when absent,
[16:32] <zyga-x240> and that some combination of apps write the cache that other apps cannot read
[16:32] <zyga-x240> this would just give you another chance to try
[16:32] <zyga-x240> (alternatively stash the cache)
[16:32] <ijohnson> No, the cache is always rewritten when snap update happens iirc
[16:33] <ijohnson> So removing the cache and refreshing a snap would show that snapd is writing a broken cache
[16:33] <ijohnson> That was the bug mvo fixed by building with free type
[16:33] <ijohnson> Unclear that jdstrand's bug is a corrupt cache or not
[16:33] <mborzecki> ijohnson: global cache you mean?
[16:34] <mborzecki> ijohnson: there's also ~/.cache/fontconfig which some of the desktop clue copies to the $SNAP_USER_COMMON/.cache/fontconfig
[16:34] <zyga-x240> ETOOMUCHFONTCONFIG
[16:35] <ijohnson> Ah yes that's right there's multiple caches
[16:35] <ijohnson> Yes snapd will just regenerate the global cache
[16:35] <jdstrand> ijohnson: global as in /var/cache or ~/.cache/fontconfig?
[16:36]  * jdstrand would be surprised if snapd went into ~/.cache/fontconfig
[16:36] <ijohnson>  /var/cache
[16:37] <jdstrand> I do have a few files in there that were touched
[16:37] <jdstrand> (when I did the refresh a minute ago)
[16:37] <jdstrand> few minutes*
[16:46] <jdstrand> ijohnson: how do I trigger the snapd regeneration?
[16:47] <ijohnson> Refresh any snap
[16:47] <jdstrand> ijohnson: would an install do?
[16:48] <ijohnson> Mmm probably yes
[16:49]  * jdstrand refreshes to another channel
[16:49] <jdstrand> well, that didn't trigger it
[16:49]  * jdstrand takes some notes
[16:53] <jdstrand> ok, if it happens again, I'll see if there is a discrepency between /var/cache/fontconfig, ~/.cache/fontconfig and ~/snap/firefox/common/cache/fontconfig
[16:57]  * jdstrand jots down fc-cat -v
[16:58] <jdstrand> (that let's me see what font corresponds to what cache file (among other things)
[16:58]  * jdstrand moves along
[17:06] <dust> hi... when someone uninstalls a package all app data gets deleted... so when u reinstall the app u lose all data... thats a huge bug!
[17:09] <ijohnson> dust: have you looked at `snap saved` at all ?
[17:10] <ijohnson> dust: snapd will automatically create shapshots before removing a snap that can be restored by the user if they want to after reinstalling the snap
[17:10] <ijohnson> jdstrand: just to confirm you don't have any special font setup like manually installed fonts that you configured firefox to use everywhere right ?
[17:10] <dust> ijohnson, where to find that?
[17:19] <dust> ijohnson, in ubuntu 20.04
[17:26] <mup> PR snapd#9117 closed: tests: remove End-Of-Life opensuse/fedora releases <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9117>
[17:36] <ijohnson> dust: run `snap saved` to show snapshots that have been created automatically, and `snap restore` to restore snapshots
[17:37] <jdstrand> ijohnson: the only thing I would say is special about this machine is tha it is pretty old so I've gone through many do-release-upgrades, but I've not installed any fonts from anywhere. all just from debs
[17:37] <jdstrand> and debs from the archive
[17:37] <ijohnson> dust: see also https://snapcraft.io/docs/snapshots
[17:37] <ijohnson> jdstrand: hmm then yeah I don't think there should be anything there
[17:37] <mup> PR snapcraft#3240 opened: cli: skip sudo check for lxd/multipass if not running in tty <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3240>
[17:41] <dust> ijohnson|lunch, thx
[18:53] <zyga-x240>  /me wonders about - Make snap "test-snapd-user-service" (unset) available to the system (Post http://0/v1/service-control: dial unix /run/user/0/snapd-session-agent.socket: connect: connection refused)
[18:54] <zyga-x240> what is that http://0/
[18:54] <zyga-x240> is that something we synthesize
[18:56] <zyga-x240> 2020-08-07T15:54:53.3788099Z     - google:fedora-32-64:tests/main/snap-user-service
[18:56] <zyga-x240> 2020-08-07T15:54:53.3788764Z     - google:fedora-32-64:tests/main/snap-user-service-socket-activation
[18:56] <zyga-x240> 2020-08-07T15:54:53.3797466Z     - google:fedora-32-64:tests/main/snap-user-service-start-on-install
[18:56] <zyga-x240> 2020-08-07T15:54:53.3798599Z     - google:fedora-32-64:tests/main/snap-user-service-upgrade-failure
[18:56] <zyga-x240> those seem to fail often
[18:57] <ijohnson> zyga-x240: yes I've seen those a lot today as well and was wondering about that path we are posting to
[18:57] <ijohnson> seems like that 0 should not be there
[18:58] <zyga-x240> I'll look
[18:58] <ijohnson> i.e. I think it should be doing http://v1/service-control on /run/user/0/snapd-session-agent.socket
[19:03] <zyga-x240> the curious bit is
[19:03] <zyga-x240> that the test tries to exercise the test user
[19:03] <zyga-x240> but we really fail for root
[19:03] <zyga-x240> as we don't have perfect root "restore" path
[19:04] <zyga-x240> that socket is surely corrupted
[19:04] <zyga-x240> I'll add some logic
[19:04] <zyga-x240> IIRC we had some of this already
[19:04] <zyga-x240> in another case
[19:04] <zyga-x240> where we realized something was needed
[19:04] <zyga-x240> like restarting the socket
[19:04] <zyga-x240> or something alike
[19:04] <zyga-x240> we had something similar in pulseaudio but that was only on the surface,  I suspect
[19:04] <zyga-x240> as there pulse tried to create socket
[19:05] <zyga-x240> and systemd tried to create a socket for activation
[19:05] <zyga-x240> and that was racy
[19:05] <zyga-x240> I'll add some better debug to that test
[19:05] <zyga-x240> and add preconditions
[19:05] <zyga-x240> to all four actually
[19:20] <ijohnson> mmm that makes sense
[19:41] <mup> PR snapd#9122 opened: mkversion.sh: if the changelog version has git in it, don't add git version info <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9122>
[19:43] <zyga-x240> +1
[19:48] <zyga-x240> hey, reproduced
[19:48] <zyga-x240> nice
[19:48] <zyga-x240> let's examine
[19:49] <zyga-x240> ha
[19:49] <zyga-x240> funny
[19:50] <zyga-x240> google:fedora-32-64 .../tests/main/snap-mgmt# ls -ld /run/user/0/snapd-session-agent.socket
[19:50] <zyga-x240> srw-rw-rw-. 1 root root 0 Aug  7 19:46 /run/user/0/snapd-session-agent.socket
[19:50] <zyga-x240> google:fedora-32-64 .../tests/main/snap-mgmt# systemctl --user status snapd-session-agent.socket
[19:50] <zyga-x240> Failed to connect to bus: Connection refused
[19:50] <zyga-x240> wat?
[19:50] <zyga-x240> google:fedora-32-64 .../tests/main/snap-mgmt# ls /run/user/0/bus -l
[19:50] <zyga-x240> srw-rw-rw-. 1 root root 0 Aug  7 19:46 /run/user/0/bus
[19:51] <zyga-x240> funny that those are around
[19:51] <zyga-x240> root       45646  0.0  0.2  27040  9888 ?        Ss   19:47   0:00 /usr/bin/python3 /snap/test-snapd-service/x1/bin/start-stop-mode sighup
[19:51] <zyga-x240> we leak those from another test
[19:51] <cachio> ijohnson, hey, beta image is not booting foc uc20
[19:51] <cachio> is it known?
[19:51] <zyga-x240> connect(3, {sa_family=AF_UNIX, sun_path="/run/user/0/bus"}, 18) = -1 ECONNREFUSED (Connection refused)
[19:52] <ijohnson> cachio: uhhhh
[19:52] <ijohnson> no?
[19:52] <ijohnson> cachio: how is it not booting ?
[19:52] <ijohnson> zyga-x240: that's really weird
[19:52] <cachio> sealing problem I see
[19:52] <zyga-x240> systemd --user for root is down
[19:52] <zyga-x240> no session, no bus
[19:53] <zyga-x240> weird
[19:53] <cachio> ijohnson, https://paste.ubuntu.com/p/TRCnfF6h6c/
[19:53] <cachio> cmatsuoka, any idea?
[19:53] <zyga-x240> this is the test sequence: google:fedora-32-64:tests/main/degraded google:fedora-32-64:tests/main/interfaces-broadcom-asic-control google:fedora-32-64:tests/main/login google:fedora-32-64:tests/main/snapshot-cross-revno google:fedora-32-64:tests/main/interfaces-content-mimic google:fedora-32-64:tests/main/refresh-undo google:fedora-32-64:tests/main/media-sharing google:fedora-32-64:tests/main/snap-switch google:fedora-32-64:tests/main/try-snap-goes-awa
[19:53] <zyga-x240> y:test_snapd_service google:fedora-32-64:tests/main/security-seccomp google:fedora-32-64:tests/main/core18-with-hooks google:fedora-32-64:tests/main/security-dev-input-event-denied google:fedora-32-64:tests/main/snap-run google:fedora-32-64:tests/main/interfaces-content-mkdir-writable:snap google:fedora-32-64:tests/main/retryable-error google:fedora-32-64:tests/main/snap-handle-link google:fedora-32-64:tests/main/interfaces-location-control
[19:53] <zyga-x240> google:fedora-32-64:tests/main/interfaces-netlink-audit google:fedora-32-64:tests/main/snap-mgmt google:fedora-32-64 .../tests/runtime-state#
[19:54] <zyga-x240> I'm tired, let's fight this next week
[19:54] <zyga-x240> have a great weekend cachio, ijohnson, cmatsuoka!
[19:54] <ijohnson> ttyl zyga-x240
[19:54] <cachio> zyga-x240, you too
[19:54] <ijohnson> you have a good weekend too!
[19:54] <ijohnson> cachio: looking now
[19:55] <cachio> ijohnson, something related to tpm
[19:55] <ijohnson> cachio: where did you see that? in a nested VM ?
[19:55] <cachio> ijohnson, yes
[19:55] <cachio> when booting a beta image
[19:55] <ijohnson> hmm, which image? built locally or from cdimage ?
[19:55] <cachio> built locally
[19:55] <cmatsuoka> cachio: this is a strange error
[19:56] <cachio> sergio@cachiomachine:~/workspace/snapcore/snapd$ export SPREAD_BUILD_SNAPD_FROM_CURRENT=true
[19:56] <cachio> sergio@cachiomachine:~/workspace/snapcore/snapd$           export SPREAD_ENABLE_KVM=true
[19:56] <cachio> sergio@cachiomachine:~/workspace/snapcore/snapd$ export SPREAD_ENABLE_KVM=false
[19:56] <cachio> sergio@cachiomachine:~/workspace/snapcore/snapd$ spread -debug google-nested:ubuntu-20.04-64:tests/nested/manual/refresh-revert-fundamentals:base
[19:56] <cachio> this is for reproduce it
[19:56] <cachio> is it happening in master because it failed during the nightly suite
[19:56] <ijohnson> cachio: let me try to reproduce, is this with master ?
[19:57] <ijohnson> cachio: got it
[19:57] <cmatsuoka> cachio: it seems that it's a signature mismatch
[19:57] <cachio> use kvm = false
[19:57] <ijohnson> cachio: running now, let's see what happens
[19:58] <cmatsuoka> ijohnson: maybe something related to the dual signed components?
[19:58] <cmatsuoka> cachio: I'll try to reproduce it here
[19:58] <cachio> ijohnson, cmatsuoka thanks
[19:58] <ijohnson> cmatsuoka: i saw xnox say that dual signed shim? I think was ready and he wanted to upload it, could be he uploaded it and things actually aren't ready for it
[19:59] <ijohnson> cmatsuoka: I notice that pc gadget has new snap from yesterday
[19:59] <cachio> it is happening just when I create a beta image
[19:59] <cachio> if I create an image from edge works well
[20:00] <cmatsuoka> cachio: any special step you're taking? are you just re-signing the beta gadget?
[20:00] <cachio> cmatsuoka, we are not modiying nothing on that test
[20:01] <cachio> it has defined this:
[20:01] <cachio> BUILD_SNAPD_FROM_CURRENT: false
[20:01] <cachio>     USE_CLOUD_INIT: true
[20:01] <cachio>     ENABLE_SECURE_BOOT: true
[20:01] <cachio>     ENABLE_TPM: true
[20:01] <cachio> so, no modifications for kernel or gadget
[20:02] <cmatsuoka> cachio: so it's a locally built beta image, with snapd from master?
[20:02] <cachio> yes
[20:02] <cmatsuoka> ok, I'll build one here
[20:02] <cachio> I have the command line used in the test
[20:03] <cachio> this -> /bin/ubuntu-image --image-size 10G /home/gopath/src/github.com/snapcore/snapd/tests/lib/assertions/nested-20-amd64.model --channel beta --output /tmp/work-dir/image/ubuntu-core-20-beta.img
[20:03] <cmatsuoka> cachio: so snapd is from master, and you're not injecting snap-bootstrap, is that correct?
[20:04] <cachio> snapd is from beta
[20:04] <cachio> kernel gadget and core20 are from beta
[20:04] <cachio> as well
[20:04] <cmatsuoka> ah, nothing changed then
[20:04] <cmatsuoka> ok
[20:04] <cachio> no
[20:04] <cachio> it is an imgage from beta
[20:05] <cmatsuoka> can you paste nested-20-amd64.model somewhere, so I can use the same model?
[20:07] <cachio> cmatsuoka, 1 sec
[20:08] <cachio> cmatsuoka, https://github.com/snapcore/snapd/blob/master/tests/lib/assertions/nested-20-amd64.model
[20:09] <cmatsuoka> thanks
[20:10] <cachio> yaw
[20:22] <cmatsuoka> cachio: ok, reproduced the problem here, I'll investigate
[20:22] <cachio> cmatsuoka, good, thanks
[20:25] <ijohnson> yeah I reproduced as well, I will let cmatsuoka investigate
[20:34] <cmatsuoka> cachio. ijohnson: I suspect this is the dual signed shim and snapd in beta still doesn't know how to deal with it
[20:34] <ijohnson> cmatsuoka: any idea when snapd edge would have gotten support for it?
[20:35] <ijohnson> cmatsuoka: I assume probably with an update to secboot vendor.json ?
[20:35] <cmatsuoka> ijohnson: let me check the secboot history
[20:36] <cmatsuoka> ijohnson: edge has a reasonably updated secboot but I don't know about snapd in beta
[20:36] <ijohnson> cmatsuoka: right what I mean is we should probably try to update secboot vendor.json to what's on edge before 2.45.4 is released
[20:37] <ijohnson> err before 2.45.4 is uploaded to beta channel
[20:38] <cmatsuoka> ijohnson: let me test it here with a newer snapd...
[20:38] <ijohnson> cmatsuoka: hmm actually that may not be enough
[20:39] <ijohnson> cmatsuoka: I see that secboot vendor.json sha on master was last updated with https://github.com/snapcore/snapd/pull/8651
[20:39] <mup> PR #8651: release: 2.45 <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8651>
[20:39] <ijohnson> cmatsuoka: ah wait nvm I was on the release/2.45 branch haha
[20:39] <ijohnson> one moment
[20:40] <ijohnson> cmatsuoka: ok so last update to secboot vendor.json sha on master was from you with https://github.com/snapcore/snapd/pull/8972
[20:40] <mup> PR #8972: gadget/install,secboot: use snapcore/secboot luks2 api <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8972>
[20:40] <ijohnson> cmatsuoka: so we should back-port that PR to release/2.45
[20:42] <ijohnson> ahhhhhh but there's conflicts :-/
[20:43] <cmatsuoka> ijohnson: I'm building an image to check if it actually fixes this issue
[20:43] <ijohnson> cmatsuoka: thanks I'll try to prep a PR operating under the assumption that it does fix the issue
[20:46] <cmatsuoka> ijohnson, cachio: it installed correctly with snapd from edge
[20:46] <cachio> cmatsuoka, yes
[20:46] <cachio> just fails with beta
[20:48] <cachio> I just verified that
[20:57] <ijohnson> ugh we need to squash merge more PR's
[20:57] <ijohnson> like the amount of time wasted on trying to cleanly cherry-pick commits is ridiculous
[21:00] <cmatsuoka> ijohnson: did the API change in a way that we can't just update secboot? I don't remember really
[21:00] <ijohnson> cmatsuoka: maybe we could just try to update secboot
[21:01] <ijohnson> cmatsuoka: I don't fully understand all the changes that have happened, as there are numerous PR's from you and Maciej that are "related" to using secboot / gadget / partitioning that are pre-reqs for the single most recent PR where I assume that secboot was updated with
[21:01] <cmatsuoka> ijohnson: let me check there, just a sec
[21:01] <ijohnson> cmatsuoka: perhaps it would just be quicker to try and build a snapd with an updated secboot, do you want to try that quickly ?
[21:01] <ijohnson> thank you
[21:09] <cmatsuoka> ijohnson: this is interesting, I think the version we have there is from 2020-05-12 and the fix was commited in 2020-05-13
[21:09] <ijohnson> haha wow
[21:11] <cmatsuoka> ijohnson: so should we just apply that patch to secboot, or update all the way to the current version?
[21:11] <ijohnson> cmatsuoka: can you build snapd from release/2.45 branch with just updating the version of secboot in vendor.json ?
[21:11] <ijohnson> I can also try if it's too late for you
[21:11] <cmatsuoka> ijohnson: I can do it
[21:11] <cmatsuoka> in fact I'm very curious about the outcome of this test
[21:12] <ijohnson> cool, yeah just checkout release/2.45, then `govendor update github.com/snapcore/secboot` or something to update the dependency in the vendor.json and then build snapd exe and inject it into the snapd snap
[21:32] <cmatsuoka> ijohnson: ok, it worked
[21:33] <cmatsuoka> ijohnson: I'll format a PR for that
[21:42] <ijohnson> cmatsuoka: awesome, thanks!
[21:42] <ijohnson> Have a nice weekend
[21:42]  * ijohnson EODs
[21:45] <cachio> ijohnson, good weekend
[21:47] <mup> PR snapd#9123 opened: vendor: update secboot to support dual signed EFI binaries <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9123>
[21:49] <cachio> cmatsuoka, with that PR the issue in beta will be fixed at some point right?
[21:49] <cmatsuoka> cachio: that's the idea
[21:49] <cachio> cmatsuoka, nice, thanks for htat
[21:49] <cachio> that
[21:50] <cmatsuoka> I hope it works :) Perhaps you could test it to see if it fixes the installation for you
[21:51] <cachio> cmatsuoka, how should be the test?
[21:51] <cachio> I need to build snapd with the that branch?
[21:52] <cmatsuoka> cachio: uhm, inject snapd built from that branch into a the snapd snap from beta and run the test
[21:52] <cmatsuoka> yes
[21:52] <cmatsuoka> or you can build the entire snap instead of injecting
[21:52] <cachio> ok, I'll try that
[21:52] <cmatsuoka> I don't know what method fits better in your workflow
[21:55] <cachio> I'll try to inject the code in the snapd snap
[21:55] <cachio> I need to see
[21:56] <xnox> cachio: either use published beta images, or self build edge ones.
[21:56] <xnox> cachio: there will be new snapd in beta on Monday, which will work with newly built beta images.
[21:56] <cachio> is it failing with the images which are built during the test
[21:57] <cachio> xnox, yes, but cmatsuoka did a change, not sure how it will affect next beta
[21:58] <cachio> cmatsuoka, is it needed that change you did for 2.46?
[21:59] <cmatsuoka> cachio: it only fails for 2.45 AFAIK
[22:00] <cachio> cmatsuoka, yes, but next week mvo will create a 2.46 and send it to beta
[22:00] <cmatsuoka> ah in this case it should work automatically
[22:00] <cachio> so perhaps your change needs to be on that beta
[22:01] <cachio> cmatsuoka, ok
[22:01] <cachio> so perhaps it is better to wait for that beta?
[22:01] <cmatsuoka> I opened a PR against release/2.45, is there a branch for 2.46 already?
[22:02] <cachio> cmatsuoka, I think mvo will create it early next week
[22:02] <cmatsuoka> ah ok
[22:02] <cachio> and use all what we have in master
[22:02] <cmatsuoka> I thought there would be one more 2.45 going to beta, but if that's not the case then the patch is unnecessary
[22:03] <cachio> cmatsuoka, yes, but today mvo said next week he was going to branch and send 2.46 pre release to beta
[22:04] <cachio> cmatsuoka, but not sure which day
[22:04] <cachio> but it is ok to have that pr on 2.45
[22:04] <cachio> because it we need a new point release on beta it is going to be required
[22:04] <cmatsuoka> ah ok if 2.46 goes to beta we can just discard that patch
[22:05] <cachio> lets discuss it on Monday with mvo
[22:06] <ijohnson> xnox: but the snapd that we were going to put in beta won't work hence we need cmatsuoka's PR
[22:06] <xnox> ijohnson: 😭
[22:07] <ijohnson> cachio: cmatsuoka: yes we need to discuss with mvo if we will do snapd 2.46 as beta or if we will go ahead as planned with 2.45.4, the latter does not currently have the fix for this dual-signed shim issue
[22:07] <cachio> ijohnson, agree
[22:08] <ijohnson> if we do end up not doing a 2.45.4, then we don't need to fix release/2.45, but aiui we are still waiting on a couple things before we could branch 2.46, so beta would be broken until we land those other things (which are not uc20 related)
[22:08] <cmatsuoka> ok
[22:09] <cmatsuoka> my wife politely suggests that's time for me to handle SIGEOW, so I think I should do that
[22:09] <cmatsuoka> have a nice weekend!
[22:09] <cachio> cmatsuoka, you too
[22:10] <xnox> ijohnson: I have gadget that is single signed shim, with BootHole proof grub. I can revert that too, if you need to do 2.45.4
[22:10] <xnox> ijohnson: but from a meeting earlier today I thought the plan was to have 2.46 beta in beta channel on Monday.
[22:13] <cachio> xnox, that's the idea, but also could be a 2.45.4
[22:17] <xnox> cachio: well, sync on Monday.
[22:20] <cachio> xnox, sure, good weekend
[22:22] <ijohnson> xnox ah well I wasn't in that meeting, and that meeting happened after we talked about it during standup
[22:24]  * cachio EOW