Hi,

Cyril Brulebois <kibi@debian.org> (2024-03-21):

I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
is the only udeb with t64 (at least according to the output of
`apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies would be sufficient (and might happen at some point anyway).

For the sake of consistency, I think I'm tempted to suggest a revert of
the udeb part (it wasn't renamed so there's a contents vs. package name mismatch anyway).

Checking libaio's changelog (last mail got sent a little too fast,
sorry) is enlightening: this library required special attention and
wasn't just about getting rebuilt with a different package name.

https://tracker.debian.org/news/1509816/accepted-libaio-03113-6-source-into-unstable/

Guillem is absolutely right regarding avoiding the roundtrip to NEW and
d-i's not caring, but some kind of heads-up to debian-boot@ (now cc'd)
would have been welcome.

It'd be nice if the Debian LVM Team (hello waldi) could pick it up from
here and see whether requesting a binNMU is what makes most sense here,
or if there other plans on the t64 front. A local, cowbuilder-powered
rebuild of unstable's lvm2 results in udebs referencing libaio.so.1t64
as expected (i.e. libaio1t64's shlibs).


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmX8sQgACgkQ/5FK8MKz VSAw/BAAiAR10vIOyN5h7Q7d5+48Z86yMbn/uYsp0nM9S04DWwH+ZJKOfw9lAwPv Cyte5eK4vuFqQb/XB5DQG7XgWbGsRGZPVI4tsEguuGF4JXy+13848lPjFmNHIB6j aILD/n6vZkHvHdpNboqzN3k/pMIGqf6eg7VcNRZLqswsxu9F3QfUVq+q8ldW6IGG yZPPblv1oOMbDD2u4HpDC3gUKc9w7qRoQCCsNRnVCnB6OS09zgZEAVIo7TlH0rd6 xu4kbK+HqhS26LpEcpbgcXSyIIhEq1mRt4n85M7uW3Flg4+q+ue3qa01eFpyiC5f 8McjElqIOSjkqr5bANVwiHlvksEaToA8hcwRy17TQ5YQdNjgYt8mszBY4VPgSlIp IAmIis5eVlO/6dqDFno+PNKfocPqVcoKPYilsv6j4PuR5VfTxJiXy8qoqWhFRU0C YHnXO+4sGbP3O9xVFcS9EsKWS2beNzCCW8ODGSYawuBRBSGp1PoqErM4b4TlVcWp pBDFzN5QOHC/63s5wsOSa0HGL1tz6sqnP/wtXC+FKygdKs4JEHOqB1dw22tBT9hJ 8dy4y2cqPURHR61ERDXWOrLobPdBR8RbBi6srNPPCCE2z5NixvsxJyjV1zDNFSuW Ubsf3j4PZqu/zL46vFzJfLDFX30DBY+JvYVhJqTmowgpnO/Y1x0=
=4/9I
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

Hi!

On Thu, 2024-03-21 at 23:13:31 +0100, Cyril Brulebois wrote:

Cyril Brulebois <kibi@debian.org> (2024-03-21):

I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
is the only udeb with t64 (at least according to the output of
`apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies would be sufficient (and might happen at some point anyway).

For the sake of consistency, I think I'm tempted to suggest a revert of
the udeb part (it wasn't renamed so there's a contents vs. package name mismatch anyway).

Checking libaio's changelog (last mail got sent a little too fast,
sorry) is enlightening: this library required special attention and
wasn't just about getting rebuilt with a different package name.

https://tracker.debian.org/news/1509816/accepted-libaio-03113-6-source-into-unstable/

Guillem is absolutely right regarding avoiding the roundtrip to NEW and
d-i's not caring, but some kind of heads-up to debian-boot@ (now cc'd)
would have been welcome.

Ah, sorry, the heads-up part didn't cross my mind, as I guess I
assumed transitory breakage was expected as part of that transition,
and that it would auto-heal after the release-team would trigger the
necessary binNMUs. Will try to have that in mind in the future. (I'll
do so as well once/if I revert the libaio SONAME bump, even though there
I'd be planning to add backwards compatibility symlinks if the ABI does
not change from what upstream accepts.)

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)