[06:05] <mup> PR snapd#9939 opened: RFC: Vendor apparmor3 for improved cross-distro/platform support and easier ongoing maintenance <Created by alexmurray> <https://github.com/snapcore/snapd/pull/9939>
[07:14] <mborzecki> morning
[07:49] <mborzecki> mvo: hey
[07:49] <mvo> hey mborzecki !
[07:51] <mup> PR snapd#9940 opened:  boot: cmd/snap-bootstrap: handle a candidate recovery system v2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9940>
[08:04] <pstolowski> morning
[08:10] <mvo> good morning pstolowski
[08:21] <mup> PR snapd#9901 closed: o/devicestate,many: introduce DeviceManager.preloadGadget for EarlyConfig <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9901>
[08:22] <mborzecki> hmmm
[08:22] <mborzecki> that labeler does silly things sometimes
[08:22] <mborzecki> https://github.com/snapcore/snapd/pull/9940#event-4345279407
[08:22] <mup> PR #9940:  boot: cmd/snap-bootstrap: handle a candidate recovery system v2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9940>
[08:33] <zyga> o/
[08:44] <pedronis> mborzecki: hi, I'm looking at #9940, it feels weird that we need to check that new flag in so many places? am I missing something?
[08:44] <mup> PR #9940:  boot: cmd/snap-bootstrap: handle a candidate recovery system v2 <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9940>
[08:45] <mborzecki> pedronis: you mean the flat to not allow fallback keys?
[08:45] <pedronis> yes
[08:47] <mborzecki> pedronis: hm i guess i could simplify that to do the check only in the fallback* state handlers
[08:49] <pedronis> mborzecki: we are probably misunderstanding each other on something else
[08:49] <mborzecki> pedronis: quick chat?
[08:50] <pedronis> mborzecki: I have a meeting in 10
[08:51] <mborzecki> pedronis: after the meeting then?
[08:52] <pedronis> I need to chat with mvo after the meeting
[08:52] <pedronis> mborzecki: what I don't understand is also why we don't finish early in this mode?
[08:53] <mborzecki> pedronis: we do, right after the initramfs mounts state machine finishes
[08:53] <pedronis> mborzecki: but shouldn't the state machine finish early too?
[08:53] <pedronis> maybe
[08:55] <mborzecki> pedronis: it's done after mounting save
[08:58] <pedronis> mborzecki: anyway we should find a way to reduce the ifs and diff size, maybe we'll also need less tests then
[08:58] <pedronis> *fewer
[08:59] <mborzecki> pedronis: added something to the calendar to discuss it, maybe i missed something
[09:00] <pedronis> mborzecki: also why the mountsErr vs err thing ?
[09:01] <mborzecki> pedronis: here? https://github.com/snapcore/snapd/pull/9940/files#diff-aec04aa8357bab6140f694de4af1f79a69d615f74585f349e7a389fb43e975d8R1029
[09:01] <mup> PR #9940:  boot: cmd/snap-bootstrap: handle a candidate recovery system v2 <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9940>
[09:01] <pedronis> mborzecki: well a bit everywhere
[09:01] <pedronis> mborzecki: also do we stop asking for the recovery key?
[09:04] <mborzecki> pedronis: yes, the handling returns early if fallback keys are to be skipped
[09:05] <pedronis> mborzecki: I mean the user input recovery key, not the fallback keys to be clear
[09:07] <mborzecki> pedronis: yes, that place is not reached, but yeah, i see now how moving the check to the fallback state handler would make it clearer
[09:11] <pedronis> mborzecki: yes, moving the fail to the actual states we don't want, instead of all the places that call them would be much easier
[09:11] <mup> PR snapd#9941 opened: Snapshot save fails with sockets in folder <Created by mapero> <https://github.com/snapcore/snapd/pull/9941>
[09:12] <mborzecki> pedronis: i've added quick sync at 1030 after the desktop meeting
[09:14] <pedronis> mborzecki: as I said I should sync with mvo at that time
[09:15] <mborzecki> pedronis: ah ok, got a quick errand at 11, so 12 then?
[09:15] <pedronis> mborzecki: maybe you have already input now anyway?
[09:15] <pedronis> mborzecki: my main ask it to make the diff smaller and less churny
[09:16] <pedronis> *enough input
[09:17] <mborzecki> pedronis: ok, let me work on this for a bit then and push something, and then we can discuss
[09:56] <mborzecki> quick errand, back in 30
[10:50] <mborzecki> re
[10:53] <mborzecki> pedronis: i'm thiniking, i could split the boot bits into a separate pr, should make the whole thing easier to review hopefully
[10:54] <pedronis> mborzecki: yes, that is also true
[10:54] <mborzecki> pedronis: just the tests in s-b are like 350+ inflating the whole thing a lot
[10:55] <pedronis> mborzecki: I still hope the diff of cmd_initramfs_mounts.go itself can be shrunk
[10:58] <mborzecki> pedronis: it is a bit smaller now: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/uc20-recovery-mgmt-sb-try-handling-v2-wip#diff-aec04aa8357bab6140f694de4af1f79a69d615f74585f349e7a389fb43e975d8
[11:01] <pedronis> mborzecki: yes, it looks a bit easier to review without getting lost at least
[11:01] <mborzecki> tests are still large, but sadly there's lot of state to mock :/
[11:01] <mup> PR snapd#9942 opened: boot: helper for checking and marking tried recovery system status from initramfs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9942>
[11:01] <mborzecki> pedronis: just the boot bits ^^
[11:02] <pedronis> mborzecki: that's ok, at the end of the day the code needs to look right first even before considering the tests
[11:04] <mborzecki> in the meantime, not sure how gorename ended up renaming so many bits to mountsErr, hmm
[11:05] <pedronis> mborzecki: ah, well that was messy
[11:05] <mborzecki> it's not even gorename, but godoctor rename
[11:06] <pedronis> ok but for sure didn't win points :) no cookies for that tool
[11:11] <mborzecki> hahah that's true
[11:12] <mborzecki> surprising golsp doesn't have that functionality yet
[11:53] <pstolowski> pedronis: i've updated #9930 but I'm going to remove bulk.go changes from it and work on it in a separate PR
[11:53] <mup> PR #9930: 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>
[11:54] <pstolowski> (overlord/assertate/* will be moved to a separate PR)
[11:55] <pedronis> pstolowski: sounds good
[11:56] <pedronis> pstolowski: let me know when it's ready to review
[11:58] <pedronis> mborzecki: I will start with 9942 but is 9940 also re-ready for review?
[11:58] <mborzecki> pedronis: yes, i've updated it
[11:58] <pedronis> thx, I will look in a bit
[12:04] <pstolowski> pedronis: it is now
[12:14] <mborzecki> pedronis: wondering, shall we s/good_recovery_sytems/verified_recovery_systems/ or does verified imply too much here?
[12:17]  * cachio afk
[12:39] <mvo> pedronis: I updated 9907 with the most simple version of a filter func, please have a look (not urgent) and if it looks too simplistic I will have to do a version of mountedfilesystemwriter that also takes the filter func (separate PR as discussed). thanks again for all your suggestions
[12:44] <pedronis> mborzecki: it implies the wrong things, we use verify for the checks we do based on assertions, and we really never boot something that is not verified
[12:45] <mborzecki> ack
[12:45] <pedronis> or at least shouldn't
[13:27] <pedronis> mborzecki: I did a pass on 9942
[13:28] <mborzecki> pedronis: thanks, finishing the modeenv bits and will take a look after
[13:40] <pedronis> mvo: I commented on #9907
[13:40] <mup> PR #9907: gadget,devicestate: perform kernel asset update for $kernel: style refs <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9907>
[13:47] <mup> PR snapd#9943 opened: boot: introduce good recovery systems, provide compatibility handling <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9943>
[13:47] <mborzecki> pedronis: hopefully this one is simpler ^^
[13:57] <mup> PR snapd#9944 opened: github: temporarily disable action labeler due to issues with labels being removed <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9944>
[14:12] <mup> PR snapd#9905 closed: asserts: validation sets WIP <Skip spread> <validation-sets :white_check_mark:> <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/9905>
[15:42] <mborzecki> heh, so now i know why my spread test didn't work, ofc boot-state is completely unaware of grubenv being somewhere else, especially not under /run/mnt/ubuntu-seed..
[15:43] <mborzecki> mvo: debian testing is getting installed in a vm
[15:51] <ijohnson> thanks mborzecki
[15:51] <ijohnson> mborzecki: I made a spreadsheet to track the testing on debian, I'll PM it to you
[15:52] <mborzecki> ijohnson: thanks, i'l try to run some tests today, if not then tomorrow morning
[15:52] <ijohnson> great!
[15:53] <mborzecki> ijohnson: s/debian 10/debian 11/ in the spreadsheet right?
[15:53] <ijohnson> ah yeah probably
[15:53] <ijohnson> I made it during another meeting so typos 🤷‍♂️
[15:57] <mvo> mborzecki: \o/ you rock
[16:03]  * cachio afk & lunch
[17:02] <pedronis> pstolowski: I made maybe a simplifying suggestion in #9930
[17:02] <mup> PR #9930: asserts: pool changes for validation-sets <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9930>
[17:02] <pstolowski> pedronis: ty, looking
[17:04] <pstolowski> pedronis: sounds sensible, i'll see how it goes, thanks
[17:43] <kkoukiou> Hi :) I want to ask if there is plan/interest for resolving https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1714941 ? In cockpit [1] we have a udisks2 UI where we display available volumes, and we got one issue about it [2]
[17:43] <kkoukiou> [1] cockpit-project.org/
[17:43] <kkoukiou> [2] https://github.com/cockpit-project/cockpit/issues/14424
[17:43] <mup> Bug #1714941: mounts should hint ignore <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1714941>
[19:06] <mup> PR snapcraft#3438 opened: flutter: Specify arch specific bundle dirs fixes LP:1915991 <Created by kenvandine> <https://github.com/snapcore/snapcraft/pull/3438>
[19:10] <diddledan> kkoukiou: I've remapped that bug to snapd because it isn't related to the snapcraft utility that is for building snaps
[20:52] <lord4163> Hi
[20:53] <lord4163> I have lxd installed as a snap on raspbian and I try to import a qcow2 image using `lxc image import <image>`, but it fails... Error: exec: "qemu-img": executable file not found in $PATH
[20:53] <lord4163> I have qemu and qemu-utils installed as regular packages
[21:08] <ijohnson> lord4163: that's probably a bug with the lxd snap, try the #LXD channel
[21:08] <ijohnson> cc stgraber ^
[21:11] <mup> PR snapcraft#3439 opened: Don't error out if font cache generation fails.  This can cause <Created by kenvandine> <https://github.com/snapcore/snapcraft/pull/3439>
[21:36] <diddledan> ijohnson: as you're around, and I don't know who to ping, can you point a security person at https://forum.snapcraft.io/t/cve-2021-3177/22843 who can advise as to the processes in place for Ubuntu and the base snaps (separately)
[21:37] <ijohnson> haha I literally _just_ replied to that :-D
[21:37] <ijohnson> but thanks for the ping diddledan
[21:37] <diddledan> haha
[21:37] <diddledan> I see it now :-)
[21:38]  * diddledan clicks the heart