[03:18] <mup> PR snapcraft#3383 opened: isort: sort remaining python files <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3383>
[06:51] <mborzecki> morning
[06:56] <mvo> good morning mborzecki
[06:56] <mborzecki> mvo: hey
[07:05] <mvo> mborzecki: could you please have a look at 9672?
[07:05] <mvo> (should be super easy)
[07:05] <mvo> mborzecki: and maybe 9656 but that is less trivial
[07:07] <mborzecki> heh 16mb binary :P
[07:08] <mup> PR snapd#9672 closed: vendor: update secboot repo to avoid including secboot.test binary <Run nested> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9672>
[07:08] <mvo> mborzecki: \o/ thank you
[07:08] <mvo> mborzecki: yeah, I was a bit surprised when I checked the orig.tar.xz size ;)
[07:09] <mvo> mborzecki: and also a bit worried that I messed things up with one of the build scripts or something
[07:09] <mvo> aaaaaaaaand cherry-picked :)
[08:07] <pstolowski> morning
[08:11] <mborzecki> pstolowski: hey
[08:25] <mvo> good morning pstolowski
[08:34] <pstolowski> o/
[08:35] <pstolowski> thanks for the comments on download-timeout PR, updating
[08:50] <mvo> pstolowski: feel free to ignore what you feel is silly, I think I was super nitpicky in there
[08:53] <mborzecki> - Fetch and check assertions for snap "core" (10448) (cannot get nonce from store: store server returned status 503)
[09:22] <pstolowski> mvo: no worries, these were nice touches
[09:23] <pstolowski> mborzecki: updated #9850
[09:23] <pstolowski> in case you want to take another loook
[09:23] <pstolowski> mborzecki: i think store wanted to know when we see them again
[09:26]  * pedronis errands
[10:13] <mvo> pstolowski: thanks for the update, this really looks amazingly good now
[10:15] <pstolowski> 👍
[10:44] <mup> PR snapd#9580 closed: store: download timeout <Bug> <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9580>
[10:50] <pstolowski> woah
[10:57] <jamesh> 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] <mvo> jamesh: nice! I did peek at the goyacc one but need some quiet time for this :)
[10:58] <mvo> jamesh: I will try to get to at least the dgettext one
[10:58] <mvo> (today)
[10:59] <mup> PR snapcraft#3384 opened: Add core20 to various /Dockerfile/s <Created by martijnbastiaan> <https://github.com/snapcore/snapcraft/pull/3384>
[11:39] <mborzecki> hmm, i should probably close #8947, squash it, split it and then reopen individual bits
[11:39] <mup> PR #8947: many: update managed boot config when refreshing snapd <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8947>
[11:42] <mvo> mborzecki: +1
[11:44] <mup> PR snapd#8947 closed: many: update managed boot config when refreshing snapd <UC20> <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/8947>
[12:34] <mup> PR snapd#9676 opened: bootloader: indicate when boot config was updated <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9676>
[13:28] <dot-tobias> 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] <ogra> 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] <pedronis> dot-tobias: it gets a serial
[13:30] <dot-tobias> 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] <pedronis> there's correct in the sense that the store doesn't support remodeling atm
[13:49] <pedronis> mborzecki: we had a long discussion with Ian exactly how to avoid doing this: https://github.com/snapcore/snapd/pull/9677/files
[13:49] <mup> PR #9677: gadget: a helper for querying the name of the bootloader required by the gadget <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9677>
[13:50] <mborzecki> pedronis: haha
[13:50] <mup> PR snapd#9263 closed: interfaces/fpga: add fpga interface <Needs Samuele review> <Squash-merge> <Created by alfonsosanchezbeato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9263>
[13:50] <mup> PR snapd#9677 opened: gadget: a helper for querying the name of the bootloader required by the gadget <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9677>
[13:50] <pedronis> mborzecki: I don't want to go there atm
[13:50] <pedronis> mborzecki: especially the find the first one is strange
[13:51] <mborzecki> 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] <ijohnson> morning folks
[13:52] <ijohnson> I see perhaps mborzecki has taken up the reins of trying to make bootloader/gadget detection less guessy ?
[13:52] <mborzecki> ijohnson: haha yeah, didn't know about the previous discussions you guys had
[13:52] <ijohnson> :-P
[13:52] <pedronis> 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] <mborzecki> pedronis: sure
[13:53] <ijohnson> makes sense
[13:53] <pedronis> ijohnson: but yes, mborzecki is right and maybe now your PR doesn't need the map anymore
[13:53] <pedronis> we had a bit of back and forth on the design
[13:53] <ijohnson> ok, sure
[13:53]  * ijohnson hasn't read any reviews just yet 
[13:54] <mborzecki> pedronis: hm not sure the map was needed before too
[13:54] <pedronis> mborzecki: at some point Present and new were conflated
[13:54] <mborzecki> ha, so maybe it was just left behind
[13:55] <mup> PR snapd#9677 closed: gadget: a helper for querying the name of the bootloader required by the gadget <Simple 😃> <UC20> <Created by bboozzoo> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/9677>
[13:55] <pedronis> mborzecki: also I'm not sure whether importing gadget from bootloaders will bite use at some point or not
[13:55] <pedronis> another reason not try that
[13:56] <pedronis> gadget was importing bootloader recently then we undid that, but could happen again
[13:56] <mborzecki> pedronis: this could be a subpackage, also used a thin structure to unmarshal the volume.bootlaoder basically
[13:56] <ijohnson> 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] <pedronis> ijohnson: the biggest win I suppose it that the order is deterministic, it should matter
[13:57] <pedronis> it shouldn't matter
[13:57] <pedronis> but it's a plus
[13:57] <ijohnson> ok, I will get rid of the map and make it a list again then
[13:57] <ijohnson> unless mborzecki has already done that patch
[13:58] <mborzecki> ijohnson: i didn't
[13:58] <pedronis> 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] <ijohnson> k, well I guess I will do it after the SU at this point, but I will do that first thing :-)
[13:58] <ijohnson> pedronis: yeah that was the biggest todo I realized working on it yesterday is "which is the boot volume"
[13:59] <ijohnson> and what about weird dual boot situations, what if somebody had multiple bootloaders on a system
[13:59] <ijohnson> though I don't think we support dual booting uc with anything
[13:59] <ijohnson> anyways SU
[14:15] <mup> PR snapd#9674 closed: bootloader/lkenv: mv v1 to separate file, include/lk/snappy_boot_v1.h: little fixups <Simple 😃> <Skip spread> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9674>
[14:18] <dot-tobias> 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] <pedronis> 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] <dot-tobias> 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] <dot-tobias> 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] <mup> PR canonical-web-and-design/ubuntu-core-docs#127: Add info about serial-authority header in model.md #1 <Created by tobias-grasse> <https://github.com/canonical-web-and-design/ubuntu-core-docs/pull/127>
[14:28] <degville> dot-tobias: will do - thank you, and thanks for letting me know.
[14:55] <ijohnson> 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] <mup> PR #9675: bootloader/lkenv: add v2 struct + support using it <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9675>
[14:56] <pedronis> ijohnson: no, haven't started looking at it
[14:56] <ijohnson> ack I will force push a rebase then for cleaner git history
[15:00] <mup> PR snapd#9678 opened: wrappers, o/devicestate: remove EnableSnapServices <Run nested> <Services ⚙️> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9678>
[15:04] <ijohnson> mborzecki: I addressed your comments in #9673
[15:04] <mup> PR #9673: bootloader/many: rm ConfigFile, add Present for indicating presence of bloader <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9673>
[15:06] <mup> Bug #1903452 changed: snap 2.47.1 build issue <Snapcraft:New> <https://launchpad.net/bugs/1903452>
[15:09] <mup> Bug #1903452 opened: snap 2.47.1 build issue <Snapcraft:New> <https://launchpad.net/bugs/1903452>
[15:12] <mup> Bug #1903452 changed: snap 2.47.1 build issue <Snapcraft:New> <https://launchpad.net/bugs/1903452>
[16:55] <mup> PR snapd#9656 closed: devicestate: support "storage-safety" defaults during install <Run nested> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9656>
[16:58] <mvo> pstolowski: for next week, now that the download timeout detection has landed, can you please write something into the forum?
[16:59] <pstolowski> mvo: sure, about this particular fix?
[17:05] <mvo> pstolowski: well, the risk is that we may break refreshes if the download monitoring for some reasons is faulty
[17:05] <mvo> pstolowski: so I think we should ask people to watch out for this, especially on slow/exotic hardware
[17:05] <mvo> pstolowski: but next week is fine, no need to do it tonight
[17:06] <pstolowski> mvo: sure, good idea, will do
[17:50] <mup> PR snapcraft#3385 opened: yaml_utils: promote module to a package <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3385>
[17:51] <mup> PR snapd#9657 closed: snap: use the boot-base for kernel hooks <Needs Samuele review> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9657>
[19:21] <mup> Bug #1905077 opened: Cannot launch snaps <Snappy:New> <https://launchpad.net/bugs/1905077>
[19:51] <mup> PR snapd#9679 opened: daemon: start cleaning up api tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/9679>
[21:07] <mup> PR snapd#9680 opened: osutil/disks: allow mocking DiskFromDeviceName <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9680>