[09:57] <seb128> slyon, thanks for the MIR review! it does feel a bit weird to see update-maintainer called out in those reviews though, it doesn't feel like something that should make a difference in support level even if it's standard practice, but if that's something the MIR team care about maybe it should be mentioned on the wiki checklist?
[10:00] <slyon> seb128: Yes. I don't see that as a blocker, but only mentioned it as a common packaging practice, so it can be fixed "whenever the next upload happens". But indeed, we might want to add that to the wiki checklist. I will prepare a proposal about that
[10:01] <seb128> slyon, thanks, I wonder if we could have dpkg-buildpackage call it for us or something to avoid even having to talk about those changes :)
[10:03] <slyon> seb128: IIRC foundations (jawn-smith) did some work on this a few months ago, I'm not sure which packages we landed this checks in... let me check if I find some references. But sbuild fails for me locally, if `update-maintainer` wasn't run
[10:04] <slyon> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1951988
[10:08] <slyon> So that should already be in place IMO
[10:09] <seb128> slyon, I've a DEBEMAIL set with a @debian.org which bypass that check basically :p
[10:10] <seb128> I usually do the update-maintainer thing only when really diverging from Debian
[10:10] <slyon> ah! that's why it didn't catch it for you.
[10:10] <seb128> not when cherry picking changes from the Debian vcs or when including delta I intend to see merged in the next upload
[10:11] <seb128> but maybe I should try to be more consistent and think about doing the update-maintainer anyway
[10:14] <slyon> okay. I'm not sure if we have any formal policy written down about this anywhere. This is probably the closest we can get: https://wiki.ubuntu.com/DebianMaintainerField and it's not really specific about the "expected to be merged" changes special case
[10:15] <slyon> I always try to apply that rule as: whenever we diverge in any way, update the maintainer field. But you're probably more senior than me to make a call about that. It's a recommended TODO in the MIR anyway, so feel free to ignore it
[10:20] <seb128> slyon, right, thanks. And for the record I'm probably the one being wrong there, I've just been lazy about adding one manual step to my package updates
[10:20] <seb128> I will do the update-maintainer of I do another upload, but if things go according to plan we will rather sync and have no delta ;)
[10:21] <slyon> yes, that sounds like a good plan. a sync will solve the issue for good, without any additional upload needed. Thanks!
[10:31] <slyon> FTR: https://github.com/cpaelzer/ubuntu-mir/pull/10
[10:51] <cpaelzer> slyon: did you check if the base content of the repo was still up to date?
[10:52] <cpaelzer> I haven't synced back in a while since the wiki didn't let me edit for weeks
[10:52] <cpaelzer> it is fine to discuss the change, but we can't copy&paste all of it to update eventually
[10:52] <slyon> cpaelzer: nope. I didn't
[10:53] <slyon> so maybe we can discuss the change in today's meeting and I can copy the two sections into the wiki manually
[10:53] <cpaelzer> yep that would be my plan as well
[10:53] <slyon> ok
[10:58] <slyon> well.. I can't login to the wiki neither. let's see if we have somebody during today's meeting who is still logged in. otherwise I guess we can't deploy that change to the wiki for now
[12:27] <seb128> hum, annoying, webkitgtk started to build-depends on ccache which isn't in the i386 whitelist but build-depends on other things that aren't available either :/
[12:27] <seb128> jbicha, ^ fyi
[15:09] <jawn-smith> bdmurray, enr0n: thanks for getting u-r-u uploaded
[16:22] <Guest8108> Hello, is there any documentation on how the current Ubuntu 22.04 LTS installer image is built?