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