[03:18] PR snapcraft#3383 opened: isort: sort remaining python files [06:51] morning [06:56] good morning mborzecki [06:56] mvo: hey [07:05] mborzecki: could you please have a look at 9672? [07:05] (should be super easy) [07:05] mborzecki: and maybe 9656 but that is less trivial [07:07] heh 16mb binary :P [07:08] PR snapd#9672 closed: vendor: update secboot repo to avoid including secboot.test binary [07:08] mborzecki: \o/ thank you [07:08] mborzecki: yeah, I was a bit surprised when I checked the orig.tar.xz size ;) [07:09] mborzecki: and also a bit worried that I messed things up with one of the build scripts or something [07:09] aaaaaaaaand cherry-picked :) [08:07] morning [08:11] pstolowski: hey [08:25] good morning pstolowski [08:34] o/ [08:35] thanks for the comments on download-timeout PR, updating [08:50] pstolowski: feel free to ignore what you feel is silly, I think I was super nitpicky in there [08:53] - Fetch and check assertions for snap "core" (10448) (cannot get nonce from store: store server returned status 503) [09:22] mvo: no worries, these were nice touches [09:23] mborzecki: updated #9850 [09:23] in case you want to take another loook [09:23] mborzecki: i think store wanted to know when we see them again [09:26] * pedronis errands [10:13] pstolowski: thanks for the update, this really looks amazingly good now [10:15] 👍 [10:44] PR snapd#9580 closed: store: download timeout [10:50] woah [10:57] mvo: I think I've got most of the relevant go-gettext changes up as PRs. The only one I'm not sure about is adding langpack support, which is why I've left that as draft. [10:58] jamesh: nice! I did peek at the goyacc one but need some quiet time for this :) [10:58] jamesh: I will try to get to at least the dgettext one [10:58] (today) [10:59] PR snapcraft#3384 opened: Add core20 to various /Dockerfile/s [11:39] hmm, i should probably close #8947, squash it, split it and then reopen individual bits [11:39] PR #8947: many: update managed boot config when refreshing snapd <⛔ Blocked> [11:42] mborzecki: +1 [11:44] PR snapd#8947 closed: many: update managed boot config when refreshing snapd <⛔ Blocked> [12:34] PR snapd#9676 opened: bootloader: indicate when boot config was updated [13:28] ogra: Will a model assertion with “serial-authority: [generic]" result in an actual serial number, which is counted by the snap store towards Weekly Active Devices? Or does this just silence the hook? (Preparing a PR for Core docs on this) [13:29] i have not much insight into that bit but i would assume you actually get a generic srial from the global store (pretty much similar to a "canonical" serial you get for the official images) [13:29] dot-tobias: it gets a serial [13:30] ogra, pedronis: Thanks! That's what I was hoping for 😊 As long as I don't have a brand store, there's no way to update the model assertion on existing installations, correct? [13:31] there's correct in the sense that the store doesn't support remodeling atm [13:49] mborzecki: we had a long discussion with Ian exactly how to avoid doing this: https://github.com/snapcore/snapd/pull/9677/files [13:49] PR #9677: gadget: a helper for querying the name of the bootloader required by the gadget [13:50] pedronis: haha [13:50] PR snapd#9263 closed: interfaces/fpga: add fpga interface

[13:50] PR snapd#9677 opened: gadget: a helper for querying the name of the bootloader required by the gadget [13:50] mborzecki: I don't want to go there atm [13:50] mborzecki: especially the find the first one is strange [13:51] pedronis: yeah, we kind of complain when there's more than one, but the way volume is defined in theory allows having more than one :/ [13:51] morning folks [13:52] I see perhaps mborzecki has taken up the reins of trying to make bootloader/gadget detection less guessy ? [13:52] ijohnson: haha yeah, didn't know about the previous discussions you guys had [13:52] :-P [13:52] mborzecki: ijohnson: yes, but I'm going to close it, because it has its own open questions, I don't think I have to dig into that atm [13:53] pedronis: sure [13:53] makes sense [13:53] ijohnson: but yes, mborzecki is right and maybe now your PR doesn't need the map anymore [13:53] we had a bit of back and forth on the design [13:53] ok, sure [13:53] * ijohnson hasn't read any reviews just yet [13:54] pedronis: hm not sure the map was needed before too [13:54] mborzecki: at some point Present and new were conflated [13:54] ha, so maybe it was just left behind [13:55] PR snapd#9677 closed: gadget: a helper for querying the name of the bootloader required by the gadget [13:55] mborzecki: also I'm not sure whether importing gadget from bootloaders will bite use at some point or not [13:55] another reason not try that [13:56] gadget was importing bootloader recently then we undid that, but could happen again [13:56] pedronis: this could be a subpackage, also used a thin structure to unmarshal the volume.bootlaoder basically [13:56] just to be clear, we can go back to the previous way ForGadget was written, as mentioned in the commit message it's just a refactor it's not necessary I could revert that commit to go back to the old way if folks have opinions [13:57] ijohnson: the biggest win I suppose it that the order is deterministic, it should matter [13:57] it shouldn't matter [13:57] but it's a plus [13:57] ok, I will get rid of the map and make it a list again then [13:57] unless mborzecki has already done that patch [13:58] ijohnson: i didn't [13:58] mborzecki: yes, but again more work. but basically the fact we don't have a way to tell which volume is the boot volume is kind of the biggest problem [13:58] k, well I guess I will do it after the SU at this point, but I will do that first thing :-) [13:58] pedronis: yeah that was the biggest todo I realized working on it yesterday is "which is the boot volume" [13:59] and what about weird dual boot situations, what if somebody had multiple bootloaders on a system [13:59] though I don't think we support dual booting uc with anything [13:59] anyways SU [14:15] PR snapd#9674 closed: bootloader/lkenv: mv v1 to separate file, include/lk/snappy_boot_v1.h: little fixups [14:18] pedronis: Follow-up to generic serials: Are the serials still unique if I boot a fresh UC image *without network*, until seeding is done (would take ~15min during which the end user would have no idea when it's finished), and then dd a copy of that image for distibution? So first contact to the snap store is from the pre-seeded copy. [14:25] dot-tobias: without network yes, in general though we don't support pre-booted images (there might be other things that are not unique) [14:27] pedronis: Good to know, can work with that at the moment 😊 Main reason is to have a better picture of active installations through the dashboard. [14:27] degville: Opened a PR for “serial-authority” header in model assertion docs, https://github.com/canonical-web-and-design/ubuntu-core-docs/pull/127 → only based on what I learned here in the channel, so should get a review before merge. [14:27] PR canonical-web-and-design/ubuntu-core-docs#127: Add info about serial-authority header in model.md #1 [14:28] dot-tobias: will do - thank you, and thanks for letting me know. [14:55] pedronis: have you started a review of #9675 ? just wondering if I could force push a rebase of it, if you have already started a review I will just wait and do a merge commit instead to update it [14:55] PR #9675: bootloader/lkenv: add v2 struct + support using it [14:56] ijohnson: no, haven't started looking at it [14:56] ack I will force push a rebase then for cleaner git history [15:00] PR snapd#9678 opened: wrappers, o/devicestate: remove EnableSnapServices [15:04] mborzecki: I addressed your comments in #9673 [15:04] PR #9673: bootloader/many: rm ConfigFile, add Present for indicating presence of bloader [15:06] Bug #1903452 changed: snap 2.47.1 build issue [15:09] Bug #1903452 opened: snap 2.47.1 build issue [15:12] Bug #1903452 changed: snap 2.47.1 build issue [16:55] PR snapd#9656 closed: devicestate: support "storage-safety" defaults during install [16:58] pstolowski: for next week, now that the download timeout detection has landed, can you please write something into the forum? [16:59] mvo: sure, about this particular fix? [17:05] pstolowski: well, the risk is that we may break refreshes if the download monitoring for some reasons is faulty [17:05] pstolowski: so I think we should ask people to watch out for this, especially on slow/exotic hardware [17:05] pstolowski: but next week is fine, no need to do it tonight [17:06] mvo: sure, good idea, will do [17:50] PR snapcraft#3385 opened: yaml_utils: promote module to a package [17:51] PR snapd#9657 closed: snap: use the boot-base for kernel hooks

=== ijohnson is now known as ijohnson|lunch [19:21] Bug #1905077 opened: Cannot launch snaps [19:51] PR snapd#9679 opened: daemon: start cleaning up api tests === ijohnson|lunch is now known as ijohnson [21:07] PR snapd#9680 opened: osutil/disks: allow mocking DiskFromDeviceName