[07:40] <zyga> good mornign
[07:50] <mborzecki> morning
[07:55] <mvo> good morning mborzecki
[07:55] <mborzecki> mvo: hey
[08:03] <mborzecki> mvo: can you land https://github.com/snapcore/snapd/pull/9927 ? it's the reference rpm spec for fedora, but a spread job on uc20 failed
[08:03] <mup> PR #9927: packaging/fedora: sync with downstream packaging in Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9927>
[08:04] <mborzecki> (oh and it needs a 2nd review)
[08:05] <mvo> mborzecki: sure
[08:08] <mborzecki> mvo: thanks!
[08:10] <mup> PR snapd#9927 closed: packaging/fedora: sync with downstream packaging in Fedora <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9927>
[08:15] <pstolowski> morning
[08:15] <mborzecki> pstolowski: hey
[08:30] <zyga> hey guys
[08:31] <mvo> hey zyga
[08:31] <mvo> and good morning pstolowski
[08:34] <pstolowski> o/
[10:34] <mborzecki> pedronis: replied under https://github.com/snapcore/snapd/pull/9921/files/940b71fefdeadd4d2d1823139a8529b907117876#r575128036
[10:34] <mup> PR #9921: boot: helper for setting up a try recover system  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9921>
[10:35] <pedronis> mborzecki: do be clear both our comments are about unexpected reboots, not expected reboots
[10:35] <pedronis> *to be clear
[10:36] <mborzecki> pedronis: right, unless snapd_recovery_mode/snapd_recovery_system is modified we should not boot into the tried recovery system
[10:37] <mborzecki> pedronis: and the first case would be when we unexpectedly reboot in SetTryRecoverySystem() cleanup, but we still haven't modified snapd_* variables, as this is done by devicemgr.Reboot(mode,system)
[10:38] <mborzecki> pedronis: and the other case is unexpected reboot when we're back in run mode after having tried the system or just cleaning up, the snapd_* boot vars should be set to boot into run mode only at this point
[10:38] <mborzecki> does that make sense? :)
[10:39] <pedronis> mborzecki: tbh, I think maybe you should quickly write down how you expect this to work, I mean the flow and the way the vars change at different point. It might make reviewing things piece by piece easier
[10:40] <mborzecki> pedronis: sure, let me update the doc
[10:40] <mborzecki> and maybe we can have a quick chat before the standup then
[10:40] <pedronis> ok
[10:40] <pedronis> maybe invite Ian as well (not sure he can make it though)
[10:42] <mborzecki> hm if he can't make it, i suspect the interview won't take the whole hour, co we can do it afterwards too
[11:05] <mborzecki> pedronis: updated the doc now
[11:08] <mborzecki> mvo: have you looked more into the boot-state tool?
[11:12] <pedronis> mborzecki: I have other meetings after the interview
[11:14] <mvo> mborzecki: was in calls until just now, I have the spread debug shell still open
[11:14] <mvo> mborzecki: I check it now
[11:25] <mvo> mborzecki: mystery solved I think, one sec
[11:26] <mvo> mborzecki: https://github.com/snapcore/snapd/blob/master/tests/lib/tools/boot-state#L107 if run_grub_editenv fails it will then fallback to manipulate it with sed
[11:26]  * pstolowski lunch
[11:27] <mvo> mborzecki: so yeah, fine to use but probably best to have snap debug set-bootenv or something
[11:27] <mvo> mborzecki: anyway, your call :)
[11:27] <mborzecki> mvo: uhh, still kind of sucks there isn't even a crc32 of the grub bootenv
[11:28] <mvo> mborzecki: +1
[11:51] <mup> PR snapd#9915 closed: snap-confine.apparmor.in: support tmp and log dirs on Yocto/Poky <Created by om26er> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9915>
[11:53] <mborzecki> mvo: can you cherry pick those patches ^^ to 2.49?
[12:12] <mvo> mborzecki: sure, done
[12:12] <mborzecki> mvo: thanks!
[12:12] <mvo> mborzecki: they will only make it into a possible 2.49.1 of course
[12:13] <mborzecki> sure
[13:31] <ijohnson> hey mborzecki just saw the meeting invite, I'll try to be there in a couple minutes but you can start without me
[13:31] <mborzecki> ijohnson: sure
[13:51] <mup> PR snapd#9893 closed: store: support validation sets with fetch-assertions action <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9893>
[14:00] <dot-tobias> just out of curiosity: Is there a way to refresh a snap if the installed revision's pre-refresh hook has an error that will always cause the hook to abort? Like
[14:01] <dot-tobias> (nmv the “Like”)
[14:32] <mup> PR snapd#9929 opened: wrappers: use proper paths for mocked mount units in tests <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9929>
[15:00] <ijohnson> dot-tobias: not unless you have the user revert the snap to a different revision with `snap revert` and then refresh past the broken one to a new one, or remove it and reinstall it
[15:02] <mup> PR snapd#9908 closed: snap: rename gdbserver option to `snap run --gdbserver` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9908>
[15:02] <mup> PR snapd#9930 opened: asserts: pool changes and RefreshValidationSetAssertions method for validation-sets <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9930>
[15:03] <ijohnson> pedronis: so the main issue with my repair branch is just that this new test account-key should have authority-id and account-id set to "testrootrepair" ?
[15:03] <ijohnson> if so I can fix that easily
[16:02] <dot-tobias> ijohnson: Thanks for clarifying! Only affects the edge channel, so shouldn't be a huge problem as it's only for internal testing and a handful of “I know things might break” users.
[16:21] <gbisson> Hi all, going back to updating my gadget from 18 to 20, as suggested I copied the logic from rpi boot.scr (https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1871831) however I have 2 issues:
[16:21] <mup> Bug #1871831: Consolidate Core and Classic bootscripts <id-5c501f2e81928a584cabbed9> <id-5ece777ab7290a556dec3440> <flash-kernel (Ubuntu):Fix Released> <https://launchpad.net/bugs/1871831>
[16:21] <gbisson> 1- the CRC of boot.sel seems to be wrong or missing as my uboot can't import boot.sel
[16:22] <gbisson> 2- even when removing the CRC check, it seems like I'm missing things as the recovery install doesn't do anything
[16:23] <gbisson> see this log when it fails: https://gist.github.com/gibsson/c09efaa2da7cd8b7c330cef8f4eb3cbb
[16:23] <gbisson> for 1) who generates the recovery boot.sel? where can I check that the CRC is generated?
[16:25] <gbisson> for 2) can I enable some debug outputs to know more? seems to be looking for a writable LABEL but I don't understand how this could work on pi: https://github.com/snapcore/pi-gadget/blob/20-arm64/gadget.yaml
[16:27] <pedronis> ijohnson: no, they both need to be testrootorg
[16:52] <ijohnson> pedronis: why do they both need to be testrootorg? it seems misleading since we are creating an additional account-key with account-id of testrootorg and even signed by the other testrootorg account-key
[16:52] <pedronis> ijohnson: sounds we need a chat
[16:52] <ijohnson> hmm ok, I have 5 minutes right now ?
[16:53] <pedronis> ijohnson: going to the SU
[17:37] <mup> PR snapd#9931 opened: asserts: repeat the authority cross-check in CheckSignature as well <Created by pedronis> <https://github.com/snapcore/snapd/pull/9931>
[17:46] <pedronis> ijohnson: ^
[17:47] <ijohnson> thanks, just got done with the interview, so I'll loop back on that now
[17:56] <pedronis> ijohnson: np, no super hurry, but it's definitely the kind of things that was easier to do immediately than queue it for me
[17:57] <mup> PR snapd#9929 closed: wrappers: use proper paths for mocked mount units in tests <Simple 😃> <Skip spread> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9929>
[18:48] <mup> PR snapd#9916 closed: daemon: move postSnap and inst.dispatch tests to api_snaps_test.go <Skip spread> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9916>
[21:08] <mup> PR snapd#9923 closed: o/snapstate/check_snap.go: add support for many subversions in assumes snapdX <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9923>
[21:32] <om26er> I changed my login.ubuntu.com username but it did not change my Snap Store ID, why ?
[21:33] <om26er> Also where can I find roadmr, I don't see him here these days ?
[21:39] <pedronis> ijohnson: I commented on your questions in the standup doc
[21:39] <ijohnson> ah thanks pedronis
[22:23] <mup> PR snapd#9932 opened: [RFC] o/configstate/configcore: support snap set system swap.size= <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9932>