1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL.CD

  • lvm2 udebs vs. libaio1-udeb (was: Progress on t64 transition -> buildin

    From Cyril Brulebois@21:1/5 to All on Thu Mar 21 23:20:01 2024
    Hi,

    Cyril Brulebois <[email protected]> (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 ([email protected]) <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
    *
  • From Guillem Jover@21:1/5 to Cyril Brulebois on Fri Mar 22 12:30:02 2024
    Hi!

    On Thu, 2024-03-21 at 23:13:31 +0100, Cyril Brulebois wrote:
    Cyril Brulebois <[email protected]> (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)