/srv/irclogs.ubuntu.com/2020/08/07/#snappy.txt

mborzeckimorning06:05
mupPR snapd#9078 closed: boot: fancy marshaller for modeenv values <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9078>06:08
zyga-x240good morning06:32
mupPR snapd#9107 opened: tests: remove End-Of-Life releases from spread.yaml <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9107>06:33
mborzeckizyga-x240: hey06:35
zyga-x240hey :)06:36
mvogood morning zyga-x240 and mborzecki06:36
zyga-x240I'm experimenting with a small idea that will give us a bit more CI speed06:36
zyga-x240hey mvo :)06:36
zyga-x240we can run the cla-check on self-hosted workers06:36
zyga-x240this will release a slot for the more expensive unit test jobs06:37
mborzeckimvo: hey06:37
mborzeckizyga-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-x240just a tweak to the yaml06:38
zyga-x240no need to change anything else06:38
mupPR 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-x240I'm preparing the rest for this though06:38
zyga-x240as the containers are unprivileged and devoid of sudo06:38
zyga-x240though now that we have mvo around06:38
zyga-x240I have one more idea :)06:38
zyga-x240but that's for later06:38
zyga-x240we can label workers06:38
zyga-x240so we can create a subset of workers without spread keys06:39
zyga-x240but with sudo06:39
zyga-x240and we could use those for running unit tests (I have 4 spare cores at home, soon will have more)06:39
zyga-x240with fast apt proxy and preinstalled snaps it will be speedy06:39
zyga-x240on par with those over-provisioned xeons06:40
mupPR 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
mupPR 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
mupPR 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:43
mborzeckimvo: https://github.com/snapcore/snapd/pull/9107#pullrequestreview-46306956606:47
mupPR #9107: tests: remove End-Of-Life releases from spread.yaml <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9107>06:47
mborzeckimvo: bw. we have two entries for debian-sid-64 in qemu backend06:47
mvomborzecki: haha - fun06:47
mborzeckimvo: oh, and while at it, i think we can drop fedora-30 from google backend, it's EOL anyway06:48
mupPR 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-x240mvo: left a comment there06:48
mvozyga-x240: \o/06:51
zyga-x240we should try to get that 20.04-on-zfs image06:53
zyga-x240I'd love to see it fail06:53
pedronismvo: hi, I fixed the conflicts in #9097, could you re-review it ?07:02
mupPR #9097: boot/modeenv: add deepEqual, Copy helpers to simplify bootstate20 refactor <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9097>07:02
mupPR snapd#9020 closed: cmd: add new "snap recovery" command <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9020>07:03
jameshzyga: https://github.com/snapcore/snapd/pull/9043 is probably in good shape to review now07:05
mupPR #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:05
pstolowskimorning07:06
zyga-x240hey pedronis, jamesh, pstolowski07:07
zyga-x240ack, I'll look in a moment07:07
mvopstolowski: good morning! does master have all the preseed bits we need for cpc? if so I will release a 2.46~pre1.gitXXX to groovy07:07
mupPR snapd#9109 opened: github: run CLA checks on self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/9109>07:08
mupPR snapd#9110 opened: preseed: cherry-pick #8704, #8709, #9088 (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/9110>07:08
mborzeckipedronis: thanks for pushing fixes to my PRs yesterday07:08
pedronisnp07:09
pstolowskimvo: yes07:10
mvopstolowski: cool, releasing now then07:10
pstolowskity!07:10
zyga-x240woah07:13
zyga-x240today is a good LTE day07:13
zyga-x240I was just uploading at 200MBit rate07:13
mborzeckizyga-x240: maybe everyone else is on vacation? hence lots of available bandwidth07:15
zyga-x240mborzecki: maybe07:15
zyga-x240I was wondering if getting an external antenna would help07:15
zyga-x240the BTS I'm talking to is ~ 30 meters away07:15
zyga-x240maybe 5007:16
zyga-x240but I have to go through a bit of wall and glass07:16
zyga-x240we could affix an antenna to the side of the house and just run the wires, the modem has two SMA connectors07:16
zyga-x240mvo: the 2.45 thing is broken07:17
zyga-x240src/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-x240src/github.com/snapcore/snapd/cmd/snap-preseed/preseed_linux.go:167:22: undefined: snapdtool07:17
zyga-x240src/github.com/snapcore/snapd/cmd/snap-preseed/preseed_linux.go:175:21: un07:17
zyga-x240something is not right07:17
mvozyga-x240: oh no07:18
mvozyga-x240: yeah, it's a PITA, it diverged quite a bit07:18
mvozyga-x240: maybe the answer is really 2.46 :/07:18
zyga-x240*exactly*07:18
zyga-x240we should really try07:18
zyga-x240even if it goes nowhere but beta07:18
zyga-x240we'd be backporting less07:19
pedroniswell, as long we do release .3.1 to stable07:19
zyga-x240mvo: did you see the SANFU with systemd yesterday?07:20
zyga-x240it's a bit unfortunate07:20
zyga-x240I hope it doesn't affect regular users07:20
zyga-x240upgrading in-place seems less and less supported07:20
zyga-x240*SNAFU07:20
zyga-x240how could I typo that :P07:20
pedronisalso jdstrand wanted things into 2.46 that he hasn't finished yet07:21
zyga-x240I 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.307:21
pedronisas I said, it's fine, we do need to release .3.1 though07:21
zyga-x240I agree07:22
* zyga-x240 reviews https://github.com/snapcore/snapd/pull/904307:24
mupPR #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:24
mborzeckizyga-x240: if you're uploading at 200mbit/s i doubt antennas would help07:25
zyga-x240I wonder what's the limit of this class of modem07:25
zyga-x240I, for one, will be on 5G the moment it is avaliable07:25
mborzeckizyga-x240: but, if your bts is heavily occupied, you may want to check other frequencies and force one that's rarely used by mobiles07:26
zyga-x240unfortunately my firmware is pretty locked so I have almost no choice07:26
zyga-x240on the upside I get pretty good overall speed so I think it's a pretty lucky location07:26
zyga-x240there are BTSes all around here, maybe there are just enough07:26
mborzeckizyga-x240: usually 800mhz is quite busy, but 1.8ghz and 2.6 are not :P07:27
zyga-x240brb07:32
mvopstolowski: if I set "run-nested" will that also run the nested/manual suite?07:44
pstolowskimvo: heh, i don't know of "run-nested"...  i was always invoking them manually with spread ... google-nested:...:tests/nested/manual/...07:48
mupPR snapd#9111 opened: releases: release 2.46~pre1 to groovy <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9111>07:48
mborzeckiwow, it's warm today07:49
pedronispstolowski: I updated #9086 after your feedback07:49
mupPR #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
pstolowskipedronis: yes, looking atm, ty07:49
zyga-x240could we change things so that without run-nested there are "skips" not green ticks07:50
* zyga-x240 returns to review after a small interrupt to fix a test 08:00
zyga-x240mvo, pedronis: could you please look at https://github.com/snapcore/snapd/pull/7825 and +1/-1 merging as-is08:02
mupPR #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-x240it's +2 technically but I wanted to triple check08:02
pedroniszyga-x240: you told me yesterday not to look at it :)08:02
zyga-x240it's a +13 -355 leftover from the "backend" work08:02
zyga-x240pedronis: yeah because yesterday it was not relevant :)08:02
zyga-x240I mean, the other PRs were more interesting08:02
zyga-x240as they contain new work that needs direction08:03
zyga-x240this is just pushing a stone up the hill till it's done08:03
mupPR snapd#9112 opened: tests: run as hightest via tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9112>08:03
zyga-x240jamesh: around?08:29
zyga-x240jamesh: https://github.com/snapcore/snapd/pull/9043#pullrequestreview-463128041 (partial to ask a question)08:29
mupPR #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-x240I'm reading the rest08:29
jameshzyga-x240: yeah08:29
jameshzyga-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 sockets08:33
zyga-x240I see08:34
zyga-x240in that case I think we should do what I suggested in the second comment08:34
zyga-x240it's safer this way08:34
jameshzyga-x240: this effectively makes the existing GuestOK vs UserOK distinction meaningless08:34
zyga-x240we can revisit this once we have http08:34
zyga-x240I'll review the rest carefully08:34
zyga-x240if you want and agree please push that change to the existing checkers08:34
zyga-x240I would feel much safer with an early != nil check08:34
jameshzyga-x240: probably a good idea, on the basis of not making access decisions prematurely08:36
pstolowskimvo: we could set 'run nested' label on #910208:40
mupPR #9102: corecfg: add "system.timezone" setting to the system settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/9102>08:40
mvopstolowski: yeah, that's why I was asking earlier08:42
pstolowskimvo: aaah, sorry, i didn't have enough coffee, i though it was about run-checks etc08:42
mupPR 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>08:48
zyga-x240jamesh: https://github.com/snapcore/snapd/pull/9043#pullrequestreview-46313971610:42
mupPR #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-x240sorry for taking this long, I was really trying to think through the various consequences10:42
zyga-x240brb11:08
zyga-x240quick coffee :)11:08
pstolowskipedronis: i updated #900111:10
mupPR #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:10
pstolowskihmm, wot, unit test failed on FAIL: cmd_sign_test.go:55: SnapKeysSuite.TestHappyNonDefaultKey, seems like it called real gpg?11:12
zyga-x240what was the rest of the failure?11:13
zyga-x240I saw something like this today as well11:14
mupPR 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:14
pstolowskizyga-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:15
pstolowskizyga-x240: i'm looking into it11:16
zyga-x240yeah, same error11:16
zyga-x240cool11:16
zyga-x240thanks!11:16
* zyga-x240 stops coding and goes for that coffee11:16
pedronismborzecki: 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=95759050111:37
mupPR #9097: boot/modeenv: add deepEqual, Copy helpers to simplify bootstate20 refactor <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9097>11:37
pedroniswe also got again the weird 16.04 with different cgroup setup11:38
mborzeckipedronis: hmm, let me check that11:38
mborzeckipedronis: uhh, yeah that's the usual upgrade thing where centos is lagging behind rhel again11:39
mupPR 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
mupPR 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:44
zyga-x240pstolowski: https://github.com/snapcore/snapd/pull/911511:46
mupPR #9115: interfaces: check !b.preseed earlier <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/9115>11:46
zyga-x240pedronis: I'll look at the cgroup mystery as well11:46
zyga-x240mborzecki: do you have any ideas? I'd like to ensure we boot the right kernel - depending on the spread system11:47
pstolowski+1, ty11:47
zyga-x240mborzecki: 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
ijohnsonmorning folks11:47
zyga-x240ijohnson: good morning!11:47
ijohnsonhey zyga-x24011:48
mborzeckizyga-x240: simple sanity checks are probably ok11:48
ijohnsonhow are tests today11:48
ijohnsonseems like centos and cgroups are giving us trouble still11:48
mborzeckizyga-x240: i mean, those distros are kind of fixed, so we know what to expect on each system11:48
mupPR snapd#9115 opened: interfaces: check !b.preseed earlier <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/9115>11:49
zyga-x240yeah11:49
zyga-x240mborzecki: I'll do that11:50
zyga-x240I'm very curious to find out what we get11:50
ijohnsonmvo: 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 label11:52
ijohnsonat least that's been my experience11:52
pstolowskihmm i cannot repro cmd_sign_test issue11:53
pstolowskihey ijohnson !11:53
ijohnsonhey pstolowski11:53
ijohnsonthanks for all the iface backend PR's11:54
pstolowskisure thing, thanks for reviews11:54
zyga-x240pstolowski: it's very rare11:58
zyga-x240pstolowski: maybe leave it on repeat -100011:58
mborzeckigrr mounted fs updater12:03
zyga-x240?12:03
zyga-x240what?12:03
pstolowskizyga-x240: have you seen it outside of 16.04?12:04
zyga-x240pstolowski: I don't recall where I saw that12:04
mborzeckizyga-x240: the changes for the content update observer are slightly annoying12:10
mborzeckiso are the tests12:10
zygahmm?12:10
zygacontent update observer>12:10
zyga?12:10
mborzeckizyga: yes, the resealing & gadget updates things i'm working on12:11
mborzeckizyga: hm pagure badges? wtf?12:12
zygahaha, for updates?12:13
mborzeckiyeah, but it looks buggy, i haven't pushed 1000 commits into pagure12:14
pstolowskimborzecki, cmatsuoka i've requested your re-reviews on #9001 because of the changes after addressing Samuele's comment12:24
mupPR #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
mborzeckipstolowski: ack, will do12:24
pstolowskithx12:26
mborzeckipedronis: btw. in the morning in saw 408 with a GET request from a run that happend within the last 24h12:26
cmatsuokapstolowski: checking12:29
zygahey cmatsuoka12:29
cmatsuokazyga: hi12:29
cmatsuokazyga: how's the pain? feeling better?12:31
zygayeah it's really comfortable now12:31
zygaa bit hot today but now I'm just looking for execuses12:31
cmatsuokahaha, ok12:32
mupPR 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
mupPR 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
mupPR 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
mupPR 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
zygathanks mvo12:39
ijohnsonthanks for the review pedronis12:42
mvozyga: thank you!12:43
zygamvo if you are reviewing could you please advice on the last comment on https://github.com/snapcore/snapd/pull/782512:44
mupPR #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
mupPR 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
mupPR snapd#9117 opened: tests: remove End-Of-Life opensuse/fedora releases <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9117>12:44
zygashould I keep splitting?12:44
mvozyga: looking12:47
mvozyga: that seems fine - but 7825 just rmeoves code now it seems from a casual look?12:48
zygayes, and removes a workaround needed earlier12:49
pedroniszyga: what would you split from it?  all the additions to make it removal only?12:49
zygashould I get more reviews, split it further or do something else?12:49
zygajust the removal for the explicit review12:49
zygaand leave the few odd tweaks (+13) as-is12:50
pedroniszyga: the problem with that PR at moment is that it has 197 commits and a description that I'm not sure matches the content anymore12:50
zygathat's fine, I really want to merge it to keep the history in place12:51
zygaas I said, I'm happy to shave it further12:51
zygajust looking for advice12:51
pedronisisn't the history in all the PR that landed before this one?12:51
zygathey contain a subset12:52
zygaalso I would love to just merge it eventuallu12:53
pedronisit's almost complete subset, no, if all we are left is removing and +13 ?12:53
zygaeventyally*12:53
zygayes but commit history here is more detailed12:53
zyga*eventually, sorry12:53
zygastill learning the new keyboard12:53
pedronisyou are saying that in master it will look like things came from two places?12:54
pedronisthat seems confusing to me12:54
zygano, master will contain a merge commit12:55
zygayou can dig deeper to see that12:55
zygaif you annotate master it will show what it shows currently12:55
zygaas that is not changed12:55
zygabut I think there's some useful information in that history12:55
pedronisI think I need to play with it a bit, I'm trying to understand the useful vs confusing factor here12:57
zygagit merge that into a test branch and tell me if that is confusing12:59
zygaanyway, time for standup12:59
mupPR snapd#9118 opened: tests: detect unexpected xenial kernels <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9118>13:04
mupPR snapd#9119 opened: many: remove usage and creation of hijacked pid cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/9119>13:30
zygapstolowski speaking of gpg it just failed13:31
zygahttps://github.com/snapcore/snapd/pull/9118/checks?check_run_id=95833295313:31
mupPR #9118: tests: detect unexpected xenial kernels <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9118>13:31
pstolowskizyga: wow13:31
zygain azure-hosted unit tests13:31
zygaso perhaps running it in spread is useless13:31
zygaas it fails in a different env13:31
pstolowskizyga: seems to be more frequent than before then13:32
mborzeckierrand, bbl13:43
niemeyerHmm.. still don't have anything in calendar for the next hour13:56
niemeyerijohnson: Doesn't seem to have worked13:57
ijohnsonniemeyer: hmm let me try again13:57
niemeyerGot the one from mvo though13:58
ijohnsonniemeyer: ok, well I just re-sent it, so hopefully you can see the link to join13:59
zyganiemeyer I see your're invited there14:09
zygabut not accepted14:09
niemeyerzyga: It's been fixed14:09
niemeyerThanks14:09
niemeyer(I've been in the call)14:09
zygaah, good14:10
zygaI think I need a shower14:12
zyga32C14:12
zygait's a hot day14:12
cachiozyga, this is the error that I saw https://paste.ubuntu.com/p/DrXNkRyNxm/14:20
cachioand this https://paste.ubuntu.com/p/KrFm3H9Xt6/14:21
jdstrandpedronis: 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 week14:46
jdstrandpedronis: I also need to review jamesh' dbus PR and go down the list of whatever needs security review14:48
zygacachio looking14:54
pedronisjdstrand: ok, I think mvo might have more sense about 2.46 timelines early next week15:15
mvopedronis, jdstrand in a meeting but yes, first 2.46~pre early next week, groovy has it already15:15
pedronisijohnson: I did another pass, my main comment is that more bits probably need "On commit" preambles15:16
ijohnsonpedronis: thanks yeah I saw the other places I will try to do a full pass over all relevant comments15:17
mupPR snapd#9120 opened: interfaces: add kernel-crypto-api interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9120>15:25
jdstrandpedronis: at your convenience, would you mind at least reviewing the interface name in ^15:26
* jdstrand adds appropriate label for that15:26
zygacachio I hope we can detect the cause of that cgroup weirdness soon15:27
zygahey jdstrand :-)15:27
zygagood to see you again15:27
zygaI'll break for lunch because I'm starving15:27
cachiozyga, I re executed but couldn't reproduce so far15:28
cachioI'll ping you if I have more info15:28
pedronisjdstrand: 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 though15:28
jdstrandkenvandine: 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:28
jdstrandpedronis: yeah. I picked that because that appears to be how everyone refers to it15:29
jdstrandpedronis: ie, I wasn't using -api as a new suffix, I was thinking of 'kernel-crypto-api' as like 'mir'15:29
jdstrandpedronis: fyi for your review next week15:29
jdstrands/fyi/context/15:30
jdstrandmvo: actually, iirc, you did an fc-cache update lately for that ^ (is this the libfreetype mismatch?)15:31
jdstrandhey zyga :)15:31
kenvandinejdstrand: yeah, i've seen that once myself.  I could not figure out what's going on there15:31
jdstrandzyga: 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:31
kenvandineit only started happening when we updated firefox to use the new platform15:32
jdstrandkenvandine: it basically happens at least once a day for me15:32
kenvandinewow15:32
jdstrandsometimes more often15:32
kenvandineit hasn't happened to me in months15:32
kenvandinejdstrand: if you could try to debug it... i would really appreciate it :)15:32
kenvandinevery interesting that it's that common for you15:32
jdstrandkenvandine: I don't really know what to look for... do you have debugging instructions?15:33
kenvandinei think to start with run firefox from a terminal15:33
jdstrandalso, I don't really have time atm. but I guess if it keeps happening, I can try15:33
kenvandineand grab stdout when it happens15:33
kenvandinewhen you have time, i would appreciate it15:33
kenvandinei can't figure out what triggers it15:34
zygajdstrand, let me check15:34
zygaI didn't read that yet15:34
zygabut first food15:34
jdstrandkenvandine: ok, I restarted it from a terminal. let's hope I don't accidentally close it :)15:35
kenvandinejdstrand: thanks!15:35
ijohnsonjdstrand: 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_ snap15:41
ijohnsonso if you see snap changes that happen around the time that those font boxes show up, that could probably be it15:42
kenvandineijohnson: has that fix landed?15:42
ijohnsonand also I don't think mvo's fix has made it to stable, I think it's still on edge iirc15:42
kenvandineah15:42
kenvandinei'm on edge15:42
kenvandineso maybe why i haven't seen it15:42
kenvandineperhaps :)15:42
ijohnsonwe are a bit behind getting things to stable with 2.46, had many things come up with required 2.45.x :-)15:43
ijohnsonkenvandine: well that's great actually since it seems to imply that the fix worked15:43
ijohnsonjdstrand: 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 edge15:43
kenvandinequestion is what's jdstrand running :)15:43
mborzeckire15:46
pedronisI'm using snapd from edge and I still get boxes in firefox sometimes15:50
ijohnsonpedronis: but do you get them _less often_ :-) ?15:52
pedronismaybe15:52
zyga-x240mvo: 19.10 removal has weird effects15:52
mborzeckibetter boxes than immedia segfaults15:53
zyga-x24019.10 fails on https://github.com/snapcore/snapd/pull/911915:53
mupPR #9119: many: remove usage and creation of hijacked pid cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/9119>15:53
zyga-x240but it's not there15:54
ijohnsoncachio: 8942 needs another review, it changed significantly since pstolowski's review unfortunately I think15:55
ijohnsoncachio: but I +1d it just now15:55
cachioijohnson, nice, thanks a lot15:56
cachiopstolowski, if you could take a look it should be awasome15:56
* mvo is in a meeting15:57
* cachio lunch16:05
mupPR snapd#9121 opened: github: remove Ubuntu 19.10 from actions workflow <Simple 😃> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9121>16:10
pstolowskicachio: i'll, but on monday at this point, eow now16:13
jdstrandijohnson: snapd 2.45.3.1+git2475.g9bb0e0c from edge16:14
jdstrand891616:14
* jdstrand wonders if it is happening daily since he is tracking edge and the caches are getting out of date16:15
jdstrandout of sync*16:15
ijohnsonjdstrand: mmm ok so your bug is probably not fixed by that PR16:15
jdstrandsorry, I have 2.45.3.1+git2463.gaf15176 installed, snap refresh hasn't yet happened today16:15
ijohnsonBut also yes tracking edge would result in more font cache re builds16:16
jdstrand8906 is what is installed16:16
jdstrandactually, I could test that theory16:18
* jdstrand snap refreshes snapd16:18
jdstrandthat alone didn't seem to cause the problem16:21
jdstrandunless the fix came in between 8906 and 891616:22
zyga-x240jdstrand: purge cache, restart all apps16:22
zyga-x240and see if something breaks16:22
ijohnsonjdstrand: the PR was not to snapd directly but rather to fc-cache-static-builder16:24
ijohnsonhttps://github.com/snapcore/fc-cache-static-builder/pull/216:24
mupPR 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:24
jdstrandijohnson: right-- and where does my system get that?16:28
ijohnsonjdstrand it's built in the snapd snap16:29
jdstrandthat was merged more than a month ago. certainly that was in 8906...16:29
ijohnsonSo shortly after that PR was merged the next edge snapd snap build would have got it16:29
ijohnsonYes it certainly is in 890616:29
* jdstrand nods16:29
mborzeckione more tweak to the update observer branch and eow16:30
jdstrandzyga-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-x240jdstrand: I think cache is only written to when absent,16:31
zyga-x240and that some combination of apps write the cache that other apps cannot read16:32
zyga-x240this would just give you another chance to try16:32
zyga-x240(alternatively stash the cache)16:32
ijohnsonNo, the cache is always rewritten when snap update happens iirc16:32
ijohnsonSo removing the cache and refreshing a snap would show that snapd is writing a broken cache16:33
ijohnsonThat was the bug mvo fixed by building with free type16:33
ijohnsonUnclear that jdstrand's bug is a corrupt cache or not16:33
mborzeckiijohnson: global cache you mean?16:33
mborzeckiijohnson: there's also ~/.cache/fontconfig which some of the desktop clue copies to the $SNAP_USER_COMMON/.cache/fontconfig16:34
zyga-x240ETOOMUCHFONTCONFIG16:34
ijohnsonAh yes that's right there's multiple caches16:35
ijohnsonYes snapd will just regenerate the global cache16:35
jdstrandijohnson: global as in /var/cache or ~/.cache/fontconfig?16:35
* jdstrand would be surprised if snapd went into ~/.cache/fontconfig16:36
ijohnson /var/cache16:36
jdstrandI do have a few files in there that were touched16:37
jdstrand(when I did the refresh a minute ago)16:37
jdstrandfew minutes*16:37
jdstrandijohnson: how do I trigger the snapd regeneration?16:46
ijohnsonRefresh any snap16:47
jdstrandijohnson: would an install do?16:47
ijohnsonMmm probably yes16:48
* jdstrand refreshes to another channel16:49
jdstrandwell, that didn't trigger it16:49
* jdstrand takes some notes16:49
jdstrandok, if it happens again, I'll see if there is a discrepency between /var/cache/fontconfig, ~/.cache/fontconfig and ~/snap/firefox/common/cache/fontconfig16:53
* jdstrand jots down fc-cat -v16:57
jdstrand(that let's me see what font corresponds to what cache file (among other things)16:58
* jdstrand moves along16:58
dusthi... 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:06
ijohnsondust: have you looked at `snap saved` at all ?17:09
ijohnsondust: snapd will automatically create shapshots before removing a snap that can be restored by the user if they want to after reinstalling the snap17:10
ijohnsonjdstrand: 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
dustijohnson, where to find that?17:10
dustijohnson, in ubuntu 20.0417:19
mupPR 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:26
ijohnsondust: run `snap saved` to show snapshots that have been created automatically, and `snap restore` to restore snapshots17:36
jdstrandijohnson: 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 debs17:37
jdstrandand debs from the archive17:37
ijohnsondust: see also https://snapcraft.io/docs/snapshots17:37
ijohnsonjdstrand: hmm then yeah I don't think there should be anything there17:37
mupPR 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:37
=== ijohnson is now known as ijohnson|lunch
dustijohnson|lunch, thx17:41
=== ijohnson|lunch is now known as ijohnson
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:53
zyga-x240what is that http://0/18:54
zyga-x240is that something we synthesize18:54
zyga-x2402020-08-07T15:54:53.3788099Z     - google:fedora-32-64:tests/main/snap-user-service18:56
zyga-x2402020-08-07T15:54:53.3788764Z     - google:fedora-32-64:tests/main/snap-user-service-socket-activation18:56
zyga-x2402020-08-07T15:54:53.3797466Z     - google:fedora-32-64:tests/main/snap-user-service-start-on-install18:56
zyga-x2402020-08-07T15:54:53.3798599Z     - google:fedora-32-64:tests/main/snap-user-service-upgrade-failure18:56
zyga-x240those seem to fail often18:56
ijohnsonzyga-x240: yes I've seen those a lot today as well and was wondering about that path we are posting to18:57
ijohnsonseems like that 0 should not be there18:57
zyga-x240I'll look18:58
ijohnsoni.e. I think it should be doing http://v1/service-control on /run/user/0/snapd-session-agent.socket18:58
zyga-x240the curious bit is19:03
zyga-x240that the test tries to exercise the test user19:03
zyga-x240but we really fail for root19:03
zyga-x240as we don't have perfect root "restore" path19:03
zyga-x240that socket is surely corrupted19:04
zyga-x240I'll add some logic19:04
zyga-x240IIRC we had some of this already19:04
zyga-x240in another case19:04
zyga-x240where we realized something was needed19:04
zyga-x240like restarting the socket19:04
zyga-x240or something alike19:04
zyga-x240we had something similar in pulseaudio but that was only on the surface,  I suspect19:04
zyga-x240as there pulse tried to create socket19:04
zyga-x240and systemd tried to create a socket for activation19:05
zyga-x240and that was racy19:05
zyga-x240I'll add some better debug to that test19:05
zyga-x240and add preconditions19:05
zyga-x240to all four actually19:05
ijohnsonmmm that makes sense19:20
mupPR 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:41
zyga-x240+119:43
zyga-x240hey, reproduced19:48
zyga-x240nice19:48
zyga-x240let's examine19:48
zyga-x240ha19:49
zyga-x240funny19:49
zyga-x240google:fedora-32-64 .../tests/main/snap-mgmt# ls -ld /run/user/0/snapd-session-agent.socket19:50
zyga-x240srw-rw-rw-. 1 root root 0 Aug  7 19:46 /run/user/0/snapd-session-agent.socket19:50
zyga-x240google:fedora-32-64 .../tests/main/snap-mgmt# systemctl --user status snapd-session-agent.socket19:50
zyga-x240Failed to connect to bus: Connection refused19:50
zyga-x240wat?19:50
zyga-x240google:fedora-32-64 .../tests/main/snap-mgmt# ls /run/user/0/bus -l19:50
zyga-x240srw-rw-rw-. 1 root root 0 Aug  7 19:46 /run/user/0/bus19:50
zyga-x240funny that those are around19:51
zyga-x240root       45646  0.0  0.2  27040  9888 ?        Ss   19:47   0:00 /usr/bin/python3 /snap/test-snapd-service/x1/bin/start-stop-mode sighup19:51
zyga-x240we leak those from another test19:51
cachioijohnson, hey, beta image is not booting foc uc2019:51
cachiois it known?19:51
zyga-x240connect(3, {sa_family=AF_UNIX, sun_path="/run/user/0/bus"}, 18) = -1 ECONNREFUSED (Connection refused)19:51
ijohnsoncachio: uhhhh19:52
ijohnsonno?19:52
ijohnsoncachio: how is it not booting ?19:52
ijohnsonzyga-x240: that's really weird19:52
cachiosealing problem I see19:52
zyga-x240systemd --user for root is down19:52
zyga-x240no session, no bus19:52
zyga-x240weird19:53
cachioijohnson, https://paste.ubuntu.com/p/TRCnfF6h6c/19:53
cachiocmatsuoka, any idea?19:53
zyga-x240this 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-awa19:53
zyga-x240y: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-control19:53
zyga-x240google:fedora-32-64:tests/main/interfaces-netlink-audit google:fedora-32-64:tests/main/snap-mgmt google:fedora-32-64 .../tests/runtime-state#19:53
zyga-x240I'm tired, let's fight this next week19:54
zyga-x240have a great weekend cachio, ijohnson, cmatsuoka!19:54
ijohnsonttyl zyga-x24019:54
cachiozyga-x240, you too19:54
ijohnsonyou have a good weekend too!19:54
ijohnsoncachio: looking now19:54
cachioijohnson, something related to tpm19:55
ijohnsoncachio: where did you see that? in a nested VM ?19:55
cachioijohnson, yes19:55
cachiowhen booting a beta image19:55
ijohnsonhmm, which image? built locally or from cdimage ?19:55
cachiobuilt locally19:55
cmatsuokacachio: this is a strange error19:55
cachiosergio@cachiomachine:~/workspace/snapcore/snapd$ export SPREAD_BUILD_SNAPD_FROM_CURRENT=true19:56
cachiosergio@cachiomachine:~/workspace/snapcore/snapd$           export SPREAD_ENABLE_KVM=true19:56
cachiosergio@cachiomachine:~/workspace/snapcore/snapd$ export SPREAD_ENABLE_KVM=false19:56
cachiosergio@cachiomachine:~/workspace/snapcore/snapd$ spread -debug google-nested:ubuntu-20.04-64:tests/nested/manual/refresh-revert-fundamentals:base19:56
cachiothis is for reproduce it19:56
cachiois it happening in master because it failed during the nightly suite19:56
ijohnsoncachio: let me try to reproduce, is this with master ?19:56
ijohnsoncachio: got it19:57
cmatsuokacachio: it seems that it's a signature mismatch19:57
cachiouse kvm = false19:57
ijohnsoncachio: running now, let's see what happens19:57
cmatsuokaijohnson: maybe something related to the dual signed components?19:58
cmatsuokacachio: I'll try to reproduce it here19:58
cachioijohnson, cmatsuoka thanks19:58
ijohnsoncmatsuoka: 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 it19:58
ijohnsoncmatsuoka: I notice that pc gadget has new snap from yesterday19:59
cachioit is happening just when I create a beta image19:59
cachioif I create an image from edge works well19:59
cmatsuokacachio: any special step you're taking? are you just re-signing the beta gadget?20:00
cachiocmatsuoka, we are not modiying nothing on that test20:00
cachioit has defined this:20:01
cachioBUILD_SNAPD_FROM_CURRENT: false20:01
cachio    USE_CLOUD_INIT: true20:01
cachio    ENABLE_SECURE_BOOT: true20:01
cachio    ENABLE_TPM: true20:01
cachioso, no modifications for kernel or gadget20:01
cmatsuokacachio: so it's a locally built beta image, with snapd from master?20:02
cachioyes20:02
cmatsuokaok, I'll build one here20:02
cachioI have the command line used in the test20:02
cachiothis -> /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.img20:03
cmatsuokacachio: so snapd is from master, and you're not injecting snap-bootstrap, is that correct?20:03
cachiosnapd is from beta20:04
cachiokernel gadget and core20 are from beta20:04
cachioas well20:04
cmatsuokaah, nothing changed then20:04
cmatsuokaok20:04
cachiono20:04
cachioit is an imgage from beta20:04
cmatsuokacan you paste nested-20-amd64.model somewhere, so I can use the same model?20:05
cachiocmatsuoka, 1 sec20:07
cachiocmatsuoka, https://github.com/snapcore/snapd/blob/master/tests/lib/assertions/nested-20-amd64.model20:08
cmatsuokathanks20:09
cachioyaw20:10
cmatsuokacachio: ok, reproduced the problem here, I'll investigate20:22
cachiocmatsuoka, good, thanks20:22
ijohnsonyeah I reproduced as well, I will let cmatsuoka investigate20:25
cmatsuokacachio. ijohnson: I suspect this is the dual signed shim and snapd in beta still doesn't know how to deal with it20:34
ijohnsoncmatsuoka: any idea when snapd edge would have gotten support for it?20:34
ijohnsoncmatsuoka: I assume probably with an update to secboot vendor.json ?20:35
cmatsuokaijohnson: let me check the secboot history20:35
cmatsuokaijohnson: edge has a reasonably updated secboot but I don't know about snapd in beta20:36
ijohnsoncmatsuoka: right what I mean is we should probably try to update secboot vendor.json to what's on edge before 2.45.4 is released20:36
ijohnsonerr before 2.45.4 is uploaded to beta channel20:37
cmatsuokaijohnson: let me test it here with a newer snapd...20:38
ijohnsoncmatsuoka: hmm actually that may not be enough20:38
ijohnsoncmatsuoka: I see that secboot vendor.json sha on master was last updated with https://github.com/snapcore/snapd/pull/865120:39
mupPR #8651: release: 2.45 <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8651>20:39
ijohnsoncmatsuoka: ah wait nvm I was on the release/2.45 branch haha20:39
ijohnsonone moment20:39
ijohnsoncmatsuoka: ok so last update to secboot vendor.json sha on master was from you with https://github.com/snapcore/snapd/pull/897220:40
mupPR #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
ijohnsoncmatsuoka: so we should back-port that PR to release/2.4520:40
ijohnsonahhhhhh but there's conflicts :-/20:42
cmatsuokaijohnson: I'm building an image to check if it actually fixes this issue20:43
ijohnsoncmatsuoka: thanks I'll try to prep a PR operating under the assumption that it does fix the issue20:43
cmatsuokaijohnson, cachio: it installed correctly with snapd from edge20:46
cachiocmatsuoka, yes20:46
cachiojust fails with beta20:46
cachioI just verified that20:48
ijohnsonugh we need to squash merge more PR's20:57
ijohnsonlike the amount of time wasted on trying to cleanly cherry-pick commits is ridiculous20:57
cmatsuokaijohnson: did the API change in a way that we can't just update secboot? I don't remember really21:00
ijohnsoncmatsuoka: maybe we could just try to update secboot21:00
ijohnsoncmatsuoka: 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 with21:01
cmatsuokaijohnson: let me check there, just a sec21:01
ijohnsoncmatsuoka: 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
ijohnsonthank you21:01
cmatsuokaijohnson: this is interesting, I think the version we have there is from 2020-05-12 and the fix was commited in 2020-05-1321:09
ijohnsonhaha wow21:09
cmatsuokaijohnson: so should we just apply that patch to secboot, or update all the way to the current version?21:11
ijohnsoncmatsuoka: can you build snapd from release/2.45 branch with just updating the version of secboot in vendor.json ?21:11
ijohnsonI can also try if it's too late for you21:11
cmatsuokaijohnson: I can do it21:11
cmatsuokain fact I'm very curious about the outcome of this test21:11
ijohnsoncool, 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 snap21:12
cmatsuokaijohnson: ok, it worked21:32
cmatsuokaijohnson: I'll format a PR for that21:33
ijohnsoncmatsuoka: awesome, thanks!21:42
ijohnsonHave a nice weekend21:42
* ijohnson EODs21:42
cachioijohnson, good weekend21:45
mupPR snapd#9123 opened: vendor: update secboot to support dual signed EFI binaries <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9123>21:47
cachiocmatsuoka, with that PR the issue in beta will be fixed at some point right?21:49
cmatsuokacachio: that's the idea21:49
cachiocmatsuoka, nice, thanks for htat21:49
cachiothat21:49
cmatsuokaI hope it works :) Perhaps you could test it to see if it fixes the installation for you21:50
cachiocmatsuoka, how should be the test?21:51
cachioI need to build snapd with the that branch?21:51
cmatsuokacachio: uhm, inject snapd built from that branch into a the snapd snap from beta and run the test21:52
cmatsuokayes21:52
cmatsuokaor you can build the entire snap instead of injecting21:52
cachiook, I'll try that21:52
cmatsuokaI don't know what method fits better in your workflow21:52
cachioI'll try to inject the code in the snapd snap21:55
cachioI need to see21:55
xnoxcachio: either use published beta images, or self build edge ones.21:56
xnoxcachio: there will be new snapd in beta on Monday, which will work with newly built beta images.21:56
cachiois it failing with the images which are built during the test21:56
cachioxnox, yes, but cmatsuoka did a change, not sure how it will affect next beta21:57
cachiocmatsuoka, is it needed that change you did for 2.46?21:58
cmatsuokacachio: it only fails for 2.45 AFAIK21:59
cachiocmatsuoka, yes, but next week mvo will create a 2.46 and send it to beta22:00
cmatsuokaah in this case it should work automatically22:00
cachioso perhaps your change needs to be on that beta22:00
cachiocmatsuoka, ok22:01
cachioso perhaps it is better to wait for that beta?22:01
cmatsuokaI opened a PR against release/2.45, is there a branch for 2.46 already?22:01
cachiocmatsuoka, I think mvo will create it early next week22:02
cmatsuokaah ok22:02
cachioand use all what we have in master22:02
cmatsuokaI thought there would be one more 2.45 going to beta, but if that's not the case then the patch is unnecessary22:02
cachiocmatsuoka, yes, but today mvo said next week he was going to branch and send 2.46 pre release to beta22:03
cachiocmatsuoka, but not sure which day22:04
cachiobut it is ok to have that pr on 2.4522:04
cachiobecause it we need a new point release on beta it is going to be required22:04
cmatsuokaah ok if 2.46 goes to beta we can just discard that patch22:04
cachiolets discuss it on Monday with mvo22:05
ijohnsonxnox: but the snapd that we were going to put in beta won't work hence we need cmatsuoka's PR22:06
xnoxijohnson: 😭22:06
ijohnsoncachio: 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 issue22:07
cachioijohnson, agree22:07
ijohnsonif 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
cmatsuokaok22:08
cmatsuokamy wife politely suggests that's time for me to handle SIGEOW, so I think I should do that22:09
cmatsuokahave a nice weekend!22:09
cachiocmatsuoka, you too22:09
xnoxijohnson: I have gadget that is single signed shim, with BootHole proof grub. I can revert that too, if you need to do 2.45.422:10
xnoxijohnson: but from a meeting earlier today I thought the plan was to have 2.46 beta in beta channel on Monday.22:10
cachioxnox, that's the idea, but also could be a 2.45.422:13
xnoxcachio: well, sync on Monday.22:17
cachioxnox, sure, good weekend22:20
ijohnsonxnox ah well I wasn't in that meeting, and that meeting happened after we talked about it during standup22:22
* cachio EOW22:24

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!