[00:22] <mup> PR snapcraft#3271 opened: build providers: use the releases endpoint for LXD <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3271>
[03:38] <mup> PR snapcraft#3272 opened: storeapi: improve to channel map docstrings <bug> <documentation> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3272>
[06:31] <clmsy> Hello everyone! any chance we have a date in mind for this milestone :) https://launchpad.net/snapd/+milestone/2.46 ?
[07:06] <pstolowski> morning
[07:07] <mvo> good morning pstolowski
[07:25] <mup> PR snapd#9251 opened: o/snapstate, features: add feature flag for disk space check on remove <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9251>
[07:27] <mup> PR core#117 closed: extrafiles/writable-paths: make /etc/default/crda writable <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/core/pull/117>
[07:35] <mup> PR snapd#9138 closed: many: refactor tpm seal parameter setting <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9138>
[08:57] <zyga> I need a review for a test helper https://github.com/snapcore/snapd/pull/9243
[08:57] <mup> PR #9243: testutil: add checkers for symbolic link target <Created by zyga> <https://github.com/snapcore/snapd/pull/9243>
[08:58] <zyga> this will unblock my other patches as they all rely on it
[09:00] <zyga> tests/main/interfaces-cups-control  is failing in a weird way on 20.10
[09:00] <zyga> lpr: Error - no default destination available.
[09:00] <zyga> it looks like really wants to print
[09:16] <zyga> ok, I'll make coffee and will return shortly
[09:16] <mup> PR snapd#8843 closed: [RFC] many: export tools from core/snapd to mount namespaces <Needs Samuele review> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8843>
[09:33] <zyga> back with coffee
[09:33] <zyga> mvo good morning
[09:33] <zyga> how was your luck yesterday?
[09:35]  * zyga spends a moment to move hexchat config to a different host
[09:43] <zyga> now to prepare a ZFS test environment
[09:45] <zyga> I have a pair of old 10K RPM drives
[09:45] <zyga> perfect for scratch disks
[09:46] <zyga> now to install them
[09:48] <zyga> I live very far away from train  tracks but once a day a huge cargo train supplies the power plan and uses the horn/whistle while crossing roads
[09:48] <zyga> that sound travels!
[10:21] <zyga> drives installed, let's do ZFS
[10:22] <mvo> zyga: hey, sorry in various meetings this morning
[10:22] <zyga> hmm, I think I didn't plug power
[10:22] <zyga> mvo no worries, how are you doing?
[10:22] <zyga> thank you for the review on the test helper
[10:22] <mvo> zyga: doing fine, wish I had more time for $things but that's it
[10:24] <zyga> mvo I'm sorry, maybe it will be better with time
[10:26]  * zyga checks cables as disk are not detected in bios or anywhere
[10:29] <zyga> got it, the power cable was unplugged :D
[10:32] <zyga-x240> ok, disks are working
[10:40] <zyga> all this rebooting
[10:41] <zyga> the drives have an MD array and I want to take a peek before wiping them
[10:51] <mup> PR snapd#9241 closed: tests: do not set rsyslog.disable in core18 config defaults test <Test Robustness> <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/9241>
[11:06] <zyga-x240> pstolowski: would you mind doing a 2nd review on a small test helper
[11:06] <zyga-x240> https://github.com/snapcore/snapd/pull/9243
[11:06] <mup> PR #9243: testutil: add checkers for symbolic link target <Created by zyga> <https://github.com/snapcore/snapd/pull/9243>
[11:16] <pedronis> mvo: I re-reviewed #9210
[11:16] <mup> PR #9210: daemon: add /v2/systems "reboot" action API <Created by mvo5> <https://github.com/snapcore/snapd/pull/9210>
[11:19] <mvo> pedronis: \o/ thank you
[11:21] <zyga-kaveri> I've installed ZFS and am familiarizing myself with the CLI
[11:31] <pstolowski> zyga-kaveri: sure
[11:32] <zyga-kaveri> pstolowski: thank you, it's simple and unlocks interesting code
[11:49] <zyga-kaveri> pstolowski: thank you
[11:51] <mup> PR snapd#9243 closed: testutil: add checkers for symbolic link target <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9243>
[12:18] <zyga-kaveri> playing with zfs
[12:18] <zyga-kaveri> I used zfs on freebsd a long while ago
[12:18] <zyga-kaveri> most things are similar but I don't remember the details
[12:19] <zyga-kaveri> first odd thing is that creating a pool called "test" mounted it at /test
[12:37] <mup> PR snapd#9252 opened: osutil: add ExchangeFiles <Created by zyga> <https://github.com/snapcore/snapd/pull/9252>
[12:41] <zyga-kaveri> so I played with zfs, renameat2() fails with EINVAL, we just need to code the flock-based replacement for that
[12:41] <zyga-kaveri> I'll do that now
[12:57] <mup> PR snapd#9253 opened: sysconfig/cloudinit.go: add AllowCloudInit and use GadgetDir for cloud.conf <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9253>
[13:32] <zyga-kaveri> mvo: I figured out why my sound broke
[13:32] <zyga-kaveri> mvo: I booted a VM, this re-configures bluetooth and stuff falls a apart, known issue in vmware
[13:32] <zyga-kaveri> mvo: I routinely boot infrequently used VMs to upgrade them during standup calls
[13:33] <zyga-kaveri> so now I know ;0
[13:34] <mvo> zyga-kaveri: ok
[13:35] <ijohnson> zyga-kaveri: why the new IRC nick ?
[13:35] <zyga-kaveri> ijohnson: I don't use irc cloud for a while
[13:35] <zyga-kaveri> ijohnson: so each of my systems uses a distinct one to avoid clashes
[13:35] <ijohnson> zyga-kaveri: right but what does kaveri mean
[13:35] <ijohnson> ah I see, that's one of your machines
[13:35] <zyga-kaveri> ijohnson: this is my old kaveri FM2 system
[13:35] <zyga-kaveri> ijohnson: it's a AMD APU fro 2016 IIRC
[13:35] <zyga-kaveri> *from
[13:36] <ijohnson> ah it's an amd processor line
[13:36] <zyga-kaveri> ijohnson: it's native too :)
[13:36] <ijohnson> nice
[13:36] <zyga-kaveri> ijohnson: I have zyga-matisse as well but that's not booted now :) (upgrades)
[13:36] <zyga-kaveri> but I probably won't use it for daily work as this box is good enough for typing
[13:37] <ijohnson> zyga-kaveri: I see makes sense
[13:38] <ijohnson> after my irccloud subscription runs out, I'm going to try and migrate IRC to mattermost with the bridge and see how that fares
[13:38] <ijohnson> I've heard mixed reviews of using the bridge like that
[13:38] <ijohnson> it would be nice to have all chats in one app though
[13:39] <cmatsuoka> pedronis: I have some questions related to bootloader boot chains, please let me know when you have some time to discuss
[13:39] <zyga-kaveri> ijohnson: interesting, let me know how that works
[13:41] <ijohnson> yeah I'm hoping it works out fine, remains to be seen how resilient / robust my local network connection actually is to get 24 hr connections, I'm sure it will cut out and I will lose/reconnect the bridge every so often
[13:41] <zyga-kaveri> ah, so the bridge is local?
[13:44] <zyga-kaveri> s
[13:51] <mvo> pstolowski: I merged 9251 it will need a dedicated PR for 2.46. cherry pick has conflicts unfortunately
[13:52] <mup> PR snapd#9251 closed: o/snapstate, features: add feature flag for disk space check on remove <Disk space awareness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9251>
[13:52] <pedronis> cmatsuoka: we can chat before the 2nd Town Hall or after it? do you have a preference?
[13:52] <cmatsuoka> I have both slots open, either will do
[13:53] <pedronis> cmatsuoka: how much time do you think we need?
[13:53] <cmatsuoka> pedronis: ten minutes or so, it should be a quick alignment
[13:53] <pedronis> ok
[13:56] <pedronis> cmatsuoka: done
[13:56] <cmatsuoka> pedronis: thanks
[13:56] <pstolowski> mvo: yes, i was expecting it due to the safeMargin helper
[13:57] <pstolowski> mvo: i'll prepare it
[13:58] <mvo> pstolowski: ta
[14:04] <mup> PR snapcraft#3273 opened: spread tests: lock down setuptools for plainbox <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3273>
[14:14] <pedronis> ijohnson: I forgot about also this option: https://github.com/snapcore/snapd/pull/9237#discussion_r481169582
[14:14] <mup> PR #9237: [RFC] many: enable cloud-init on uc20 for grade signed and secured <Complex> <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9237>
[14:31] <ijohnson> sorry was afk a bit, silly plumbing problems with our new faucet
[14:31] <ijohnson> pedronis: looking
[14:33] <ijohnson> pedronis: right yes that's true in general, but numbering the files we copy from seed is an orthogonal concern to the current PR
[14:33] <ijohnson> or maybe it's not, just that this PR doesn't change how files from seed are handled
[14:48] <pedronis> ijohnson: yes, but changes the reasoning around picking a number there
[14:48] <ijohnson> pedronis: how does the numbering scheme for files from seed affect the numebring scheme for the gadget ?
[14:48] <pedronis> ijohnson: because the question we discussed the last time
[14:48] <ijohnson> pedronis: I have not yet talked with the maas/curtin team about what numbering scheme they use and what we should fit into with that
[14:48] <pedronis> ijohnson: (in a differe meeting I will get back to you in a bit)
[14:48] <ijohnson> ok
[14:54] <pedronis> ijohnson: my point is that we know we have the option to renumber, we don't have to pick a number based on what we expect the numbering used by curtin, we can decide when we renumber whether to renumber before or after our chosen number
[14:56] <pedronis> ijohnson: we can pick 70- and make what comes from the seed either 69- or 71-
[14:56] <pedronis> for example
[14:56] <pedronis> depending the sematics we want
[14:56] <ijohnson> ok, so does that mean we want the gadget cloud.conf to be 70 ?
[15:01] <pedronis> ijohnson: I would pick "80_" as prefix
[15:11] <ijohnson> pedronis: ok
[15:12] <pedronis> ijohnson: I proposed something, but not 100% happy with it yet
[15:20] <ijohnson> ah I forgot to fix that PR I just opened with the filename
[15:20]  * ijohnson has too many open branches / prs
[15:30] <cachio> zyga-kaveri, bad news, my zfs instance is not booting anymore locally, need to see which dependency caused that
[15:32] <cachio> zyga-kaveri, I have a snapshot to restore
[15:58]  * cachio lunch
[16:05] <pstolowski> mvo: opened https://github.com/snapcore/snapd/pull/9255 ; it's slightly annoying, it's a single cherry pick but i guess it will conflict when marging back (not sure)
[16:05] <mup> PR #9255: o/snapstate, features: add feature flag for disk space check on remove (2.46) <Created by stolowski> <https://github.com/snapcore/snapd/pull/9255>
[16:05] <zyga-kaveri> cachio: ok, keep me poosted please
[16:06] <pstolowski> mvo: basically it depended on the new helper and new error type name from another PR, but it's impossible to cherry pick those as they already depended on install-many changes
[16:07] <mup> PR snapd#9254 opened: sysconfig/cloudinit.go: add DisableNoCloud to CloudInitRestrictOptions <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9254>
[16:07] <mup> PR snapd#9255 opened: o/snapstate, features: add feature flag for disk space check on remove (2.46) <Created by stolowski> <https://github.com/snapcore/snapd/pull/9255>
[16:07] <mvo> pstolowski: thanks, that's ok - unavoidable sometimes
[16:08] <zyga-kaveri> mvo: thank you for the review
[16:23] <pedronis> #9249 needs a 2nd review
[16:23] <mup> PR #9249: boot,bootloader,gadget: apply new bootloader.Options.Role <Run nested> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9249>
[17:48] <ijohnson> pedronis: I reviewed 9249
[17:54] <mup> PR core20#83 opened: static/writable-paths: make /etc/default/crda writable <Created by anonymouse64> <https://github.com/snapcore/core20/pull/83>
[17:54] <mup> PR core18#167 opened: static/writable-paths: make /etc/default/crda writable <Created by anonymouse64> <https://github.com/snapcore/core18/pull/167>
[18:03] <cachio> zyga-kaveri, this is better
[18:03] <cachio> https://blog.iqonda.net/ubuntu-server-20-04-zfs-root-and-oci/
[18:03] <cachio> I'll try that
[18:04] <cachio> zyga-kaveri, it is very hard to create a cloud image based on a desktop because I need to upload 4 GB to gcloud and I tried but at some point my internet breanks and the upload too
[18:07] <pedronis> ijohnson: thanks I'll merge it and consider your comments for a follow, so cmatsuoka can possibly start using Role and its constants
[18:07] <ijohnson> pedronis: sure that's fine
[18:09] <cmatsuoka> pedronis: thanks, I'll use it in BootFile
[18:13] <mup> PR snapd#9249 closed: boot,bootloader,gadget: apply new bootloader.Options.Role <Run nested> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9249>
[18:54] <pedronis> ijohnson: created https://github.com/snapcore/snapd/pull/9256
[18:54] <mup> PR #9256: boot,bootloader: clarifications after the changes to introduce bootloader.Options.Role <Created by pedronis> <https://github.com/snapcore/snapd/pull/9256>
[18:55] <ijohnson> cool I'll have a look
[18:56] <ijohnson> +1
[18:58] <mup> PR snapd#9256 opened: boot,bootloader: clarifications after the changes to introduce bootloader.Options.Role <Created by pedronis> <https://github.com/snapcore/snapd/pull/9256>
[19:38] <ijohnson> why is our assertion database so complicated :-(
[19:41] <pedronis> ijohnson: anything in particular?
[19:43] <ijohnson> pedronis: I am still fighting getting uc20 with test keys to finish seeding properly, I thought I had it working with just seeding the fake snapd snap, but then realized it was failing to seed actually because snap-bootstrap needs to be built with test keys too, so I need to seed both the fake snapd snap and the fake kernel snap and now my change I made to prepare-image to pick up the local assert files isn't working
[19:43] <ijohnson> for multiple fake snaps
[19:43] <ijohnson> what's confusing right now is that I add these assertions to the db, then immediately after seedwriter goes to find those assertions and doesn't find them somehow
[19:43] <pedronis> you made a change to prepare-image ?
[19:44] <ijohnson> pedronis: yes I have to change prepare-image, as it doesn't work with the test keys as I mentioned in the SU doc
[19:44] <ijohnson> I changed it to (try to) import/use assert files matching the --snap file arguments
[19:45] <ijohnson> otherwise, prepare-image thinks all --snap arguments are dangerous unasserted snaps
[19:45] <pedronis> this is going to be very hard to land
[19:46] <ijohnson> mmm
[19:46] <ijohnson> I mean it's getting very hard just to get working
[19:46] <ijohnson> unless I'm missing something very obvious
[19:47] <pedronis> ijohnson: my idea was to point prepare-image to the fakestore
[19:47] <pedronis> and have the snaps there
[19:47] <ijohnson> pedronis: yeah I guess I haven't tried that yet, perhaps I should try that instead of pointing prepare-image at everything locally
[19:47] <pedronis> I thought at least one of the tests I mentioned does that
[19:48] <ijohnson> yes there is an example of that there, it just seemed like more work than using the local files/assertions but actually in hindsight it is probably less work if it just works
[19:48] <ijohnson> it just _feels_ like providing local assertions and files to prepare-image should be simpler
[19:48] <pedronis> ijohnson: the problem with what you are trying is that there's no design for it
[19:49] <ijohnson> that's also what I'm confused about, because ubuntu-image specifically works like this, and I thought it worked like this because of prepare-image, but perhaps ubuntu-image has it's own magic
[19:49] <ijohnson> because I can do `ubuntu-image --snap=my-local-snap.snap` and if there's an my-local-snap.assert file, then the snap is not treated as unasserted
[19:49] <ijohnson> but prepare-image doesn't work that way it seems
[19:49] <pedronis> ijohnson: yes, but you still need the fake store
[19:50] <ijohnson> does ubuntu-image use the fake store ?
[19:50] <pedronis> ijohnson: what happens in that case is that the file is locally but the assertions come from the store
[19:50] <ijohnson> pedronis: ahhhhhhhhhh so it's cheating really
[19:50] <ijohnson> well that's just silly but ok
[19:50] <ijohnson> alright I will switch to trying to use fakestore as a proxy
[19:50] <pedronis> is not silly
[19:51] <pedronis> but is not very intuitive
[19:51] <ijohnson> ... but what if you wanted to build an image without a connection to the store ? you have the assert files and the snap files, but you still need to talk to the store because ... ?
[19:51] <ijohnson> anyways it's not material at this point I suppose
[19:51] <pedronis> that's not the use case that was added for
[19:52] <pedronis> the use case is I have kept old snaps and I want to rebuild an image excactly with those
[19:53] <pedronis> it also shows up in some usage pattern when building classic images
[19:54] <ijohnson> sorry I guess as a user it just feels very weird to say "here take these snaps and assertions and build me an image with them" and snapd then proceeds to ignore the assertions provided and goes and gets it's own assertions from the storyt
[19:55] <pedronis> there's no way to say take this assertion atm though
[19:55] <ijohnson> haha yes that is quite clear to me now
[19:55] <mup> PR snapcraft#3273 closed: spread tests: lock down setuptools for plainbox <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3273>
[19:55] <ijohnson> sorry anyways I am probably getting us both off track now
[20:00] <pedronis> ijohnson: so the easiest is probably to use the fakestore only for assertions
[20:00] <pedronis> still pass your snaps with --snap
[20:00] <pedronis> and then maybe it should work
[20:00] <ijohnson> mmm I don't think I can do that tho
[20:00] <pedronis> yes
[20:01] <ijohnson> whenever I try to provide --snap ... to prepare-image it says local snaps are not allowed with dangerous
[20:01] <ijohnson> err not allowed with signed
[20:01] <pedronis> that sounds strange but possible
[20:01] <ijohnson> I mean unless ubuntu-image has some magic that prepare-image doesn't
[20:06] <pedronis> ijohnson: afaict it should give that error if we could not fetch assertions for the snap
[20:06] <pedronis> the check seems late enough
[20:06] <pedronis> at least
[20:07] <ijohnson> mmm I guess I didn't have the SAS mocking setup when I tried it, perhaps now with the right mocking of the fakestore it will work
[20:08] <pedronis> ijohnson: anyway I don't know if I pointed to it, but tests/main/classic-prepare-image-no-core does what I described
[20:08] <pedronis> in terms of using the fakestore only for some assertions
[20:09] <ijohnson> ok
[20:18] <ijohnson> pedronis: alright well that was actually much easier
[20:18]  * ijohnson feels rather foolish
[20:19] <pedronis> sorry
[20:20] <ijohnson> nah it's my fault for being stubborn and trying to make it work the way I thought it should work
[20:22] <pedronis> anyway afaict using --snap with signed (as long as we can find assertions) works, but is not tested, I should add a test
[20:23] <ijohnson> yes it does work with mocking SAS
[20:23] <pedronis> there's a test about this in seedwriter but is using dangerous anyway because is doing also some other things that aren't allowed
[20:24] <pedronis> I should have a test with also just the allowed subset
[20:24] <pedronis> and signed
[20:24] <ijohnson> can I just say how thankful I am that we don't also depend on signed assets from the core20 snap
[20:24] <ijohnson> if we did, then literally every snap would need to be resigned to do local builds like this
[20:24] <ijohnson> I'm already at 3/4 snaps
[20:30] <ijohnson> yay we at least made it out of the initramfs
[20:30]  * ijohnson waits anxiously to see if we make it out of install mode
[20:31] <ijohnson> mmm seems not :-/
[20:43] <mup> PR snapd#9256 closed: boot,bootloader: clarifications after the changes to introduce bootloader.Options.Role <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9256>
[21:03] <cachio> zyga, around?
[21:11]  * pedronis calling it a day
[21:16] <ijohnson> eyyyyy got it working
[21:16]  * ijohnson soft EODs
[22:00] <mup> PR snapcraft#3271 closed: build providers: use the releases endpoint for LXD <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3271>
[22:00] <mup> PR snapcraft#3272 closed: storeapi: improve to channel map docstrings <bug> <documentation> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3272>
[22:33] <cachio> ijohnson, hey, about the test in 8
[22:33] <cachio> 9208
[22:33] <cachio> we do have all the failover tests as part of the core suite
[22:34] <cachio> is it different to have it in the nested one?
[23:05] <ijohnson> cachio: well it's fine to include for the regular core suite, but I also want that test to run with secure boot and fde, even though it's not specifically fde related, it's boot related
[23:15] <mup> PR snapcraft#3274 opened: schema: rename package-repository's "deb-types" to "format" <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3274>
[23:35] <mup> PR snapcraft#3275 opened: cli: ignore sudo warning when using multipass <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3275>
[23:40] <mup> PR snapcraft#3276 opened: meta: add suite/component validation checks for package-repositories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3276>