[09:08] <Unit193> schopin: Heya, I presume you saw your email?
[09:12] <schopin> Unit193: I hadn't so far, but now I did! Thanks for the NMU sponsoring :)
[09:13] <Unit193> Happy to have that done.
[09:15] <schopin> I don't suppose there's an explicit package->lowNMU mapping available somewhere, is there?
[09:17] <Unit193> 1. https://wiki.debian.org/LowThresholdNmu  2. https://tracker.debian.org/pkg/irssi-plugin-xmpp top left
[09:20] <schopin> I knew about the first page, but I'd never noticed the notice on the tracker, thanks!
[09:42] <slyon> seb128: would you mind if I push my NetworkManager-netplan integration work to https://git.launchpad.net/network-manager directly? (as a separate "ubuntu/jammy+netplan" branch, of course) – I think that's the central place where everybody could easily find (and modify) it.
[09:42] <slyon> It currently sits at: https://git.launchpad.net/~slyon/network-manager/log/?h=ubuntu/jammy%2bnetplan
[10:11] <seb128> slyon, hey, feel free to push there, it's only a branch
[10:11] <slyon> thanks, will do!
[11:56] <rbasak> In bug 1979933 an SRU upload patches the configure script directly instead of using dh-autoreconf. Is this OK? There's future risk with maintaining such a patch in the face of eg. a future security update, but there's also regression risk in introducing autoreconf in a stable release when it wasn't there previously, as the version of autoconf being used might differ from upstream.
[11:56] <rbasak> Opinions?
[12:35] <mdeslaur> rbasak: personally, I think it's ok if it also modifies the source files, so that if autoreconf is added in the future nothing will get lost...as you say, there's a risk both ways, not sure if there's a recommended way
[12:35] <mdeslaur> or rather, an ideal way
[12:36] <slyon> rbasak: o/ thanks for rebasing that protobuf-c SRU!
[12:39] <mdeslaur> rbasak: I assume the change to configure.d/config_os_libs2 would regenerate the configure changes, no?
[12:41] <rbasak> mdeslaur: you're right - I just simultaneously noticed and commented in the bug
[12:42] <mdeslaur> cool
[12:42] <rbasak> Accepted into proposed - thank you for the discussion.
[12:50] <bluca> slyon: any answer from rel team on repartd?
[12:55] <slyon> bluca: not yet (I guess most a busy with spinning the 22.04.1 release). If I do not get any reply until after the .1 release, I will escalate that email to the ubuntu-devel/ubuntu-release mailinglist (and put you in CC)
[12:55] <bluca> thank you
[12:55] <slyon> yw
[12:56] <bluca> on a somewhat-related topic: once you merged the latest changes from Salsa, and with a couple additional changes in d/rules which would be fine to have, it becomes possible to do i386 builds that produce only the two public libraries and the EFI binaries
[12:57] <bluca> with a reduced set of dependencies among other things
[12:57] <bluca> is that something you'd be interested in for ubuntu?
[13:15] <slyon> bluca: IIRC we added some EFI binary quirks in our most recent build, so yes, that sounds interesting. @enr0n might know more ^
[13:17] <bluca> the main advantage is to reduce the i386 build set, instead of the full set of binary packages, only libs + efi
[13:17] <enr0n> slyon: the EFI build quirks were just for new linker warnings in binutils
[13:17] <bluca> IIRC your goal is to have libs-only i386?
[13:18] <bluca> (reduce here is in the context of src:systemd)
[13:22] <slyon> bluca: yes, indeed. the systemd binary is even uninstallable in recent Ubuntu releases on i386 (since jammy, according to https://autopkgtest.ubuntu.com/packages/systemd), so getting rid of it would be nice
[13:23] <bluca> ok, I'll get the missing bits in d/rules added and CC you to the MR
[13:25] <bluca> you'll need to keep the Architecture: list diff in your downstream tree, but that shouldn't be too much burden
[13:33] <slyon> cool thanks!
[18:26] <jawn-smith> vorlon: There's a package called hedgewars in the NBS report that depends on a package that hasn't existed since bionic. It has no reverse dependencies and is just a video game so not critical. Feel like breaking out the old archive chainsaw?
[18:28] <jawn-smith> oh hold up on that, I'm surprised to see it somehow built in jammy and would like to understand how it did so
[18:33] <vorlon> jawn-smith: which package do you say hasn't existed since bionic?
[18:35] <jawn-smith> I was looking at haskell-gnuidn
[18:36] <jawn-smith> But I think that was incorrect as it isn't actually a dependency of hedgewars
[19:37] <LocutusOfBorg> jawn-smith, what?
[19:37] <LocutusOfBorg> hedgewars does not depend on gnuidn
[19:38] <LocutusOfBorg> oh already answered nice
[19:39] <jawn-smith> Yeah I mistyped some commands to apt-cache so that was an incorrect statement
[19:46] <LocutusOfBorg> for sure hedgewars is a blocker for haskell and ffmpeg
[19:46] <LocutusOfBorg> I'm working on it
[20:09] <jawn-smith> Okay great, I'll focus my efforst elsewhere
[22:12] <Unit193> mapreri: Thanks for the -backport ACKs, they're in the queue now. \o/