My very limited understanding of this major transition was that the
t64 libraries are being held in unstable until (almost) everything is
ready, at which point there will be a coordinated migration into
testing. But I've now been asked to upgrade something on my testing
machine which pulls in a t64 library. Has something slipped through
the net, or is this intentional?

Looking through testing, I see the following t64 libraries present:

libaio1t64
libfyba0t64
libglibmm-2.68-1t64
libnetcdf19t64
libudns0t64
libczmq4t64 (virtual package; libczmq4 provides this)

Best wishes,

Julian

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

On 2024-03-30 Julian Gilbey <[email protected]> wrote:

My very limited understanding of this major transition was that the
t64 libraries are being held in unstable until (almost) everything is
ready, at which point there will be a coordinated migration into
testing. But I've now been asked to upgrade something on my testing
machine which pulls in a t64 library. Has something slipped through
the net, or is this intentional?

Looking through testing, I see the following t64 libraries present:

libaio1t64
libfyba0t64
libglibmm-2.68-1t64
libnetcdf19t64
libudns0t64
libczmq4t64 (virtual package; libczmq4 provides this)

Good morning,

I also stumbled over libaio1t64 and looked at the changelog. It is not
part of the transition in that it was simply rebuilt with different
compiler flags and therefore broke the ABI. Instead source code changes
were made to extend the ABI to support usage both from code built with
t64 flags and without.

I have not checked all the others (libczmq4: "Undo 4.2.1-1.1. There are
only 3 symbols with time_t, and they are not used in the distribution.
Avoid to carry the package rename forever."), but suspect they are
similar.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

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

On 2024-03-31 06:54 +0200, Andreas Metzler wrote:

On 2024-03-30 Julian Gilbey <[email protected]> wrote:

My very limited understanding of this major transition was that the
t64 libraries are being held in unstable until (almost) everything is
ready, at which point there will be a coordinated migration into
testing. But I've now been asked to upgrade something on my testing
machine which pulls in a t64 library. Has something slipped through
the net, or is this intentional?

Looking through testing, I see the following t64 libraries present:

libaio1t64
libfyba0t64
libglibmm-2.68-1t64
libnetcdf19t64
libudns0t64
libczmq4t64 (virtual package; libczmq4 provides this)

Good morning,

I also stumbled over libaio1t64 and looked at the changelog. It is not
part of the transition in that it was simply rebuilt with different
compiler flags and therefore broke the ABI. Instead source code changes
were made to extend the ABI to support usage both from code built with
t64 flags and without.

I have not checked all the others (libczmq4: "Undo 4.2.1-1.1. There are
only 3 symbols with time_t, and they are not used in the distribution.
Avoid to carry the package rename forever."), but suspect they are
similar.

Unfortunately the other four are not similar, but rather lacked a build dependency on dpkg-dev (>= 1.22.5) which would have prevented their
migration to testing. Testing users on armel and armhf should avoid
installing them and downgrade to the pre-t64 version if necessary.

Cheers,
Sven

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

On Sat, Mar 30, 2024 at 10:41:55PM +0000, Julian Gilbey wrote:

My very limited understanding of this major transition was that the
t64 libraries are being held in unstable until (almost) everything is
ready, at which point there will be a coordinated migration into
testing. But I've now been asked to upgrade something on my testing
machine which pulls in a t64 library. Has something slipped through
the net, or is this intentional?

I assume it's not intentional, some packages just didn't get a dpkg dep
for some reason.

--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmYJClktFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh nyIP+gO8pHBR83hA/Jy67T6a9I2HQv7Kbos2E8UjKk+1rpCqlQquGopNAc+Ki+sk F7Vwfbq4Y1Z4EFMGRDEZvZkp7v37k7fOdgNlnG3mOABMPwHEBy22s15Y8tqB2Zf9 uh5xogdpVx+TjYsVysjTx7eROJIc1BZUr49I81hkdBsYnK2CXzoKpVvRAShaspeu eMN/SCQFLum2KhwsnOyjkLKUtOnqmw0hWn2J7mdYH/mutN6uI05rIC3H/mtEepob 5YpwMLYuZsNW02y1t4rowD/fqbYbWizt+kpPph1ul3Ha+Qx21v2c7nP4GMQ9D7rW KUnl60710Etll4Ld7e1uhY1jBaURKfpOJzb6N/rS4GtfewNAkjdEHvysTRpRImpu 0Pfl6lJEdqDpxE5T2qtvkNvD8hTmyZnEl91n3JWdHBJ2QvAgxlKi4KN0u0RsOmw+ 8RkufWGxMNYIoufTM4sV1msOvM0+dhDSn2U7spspNTLwHpnDq+DHVyfpsXc8+MFF jAqrpDvFmr+JskwiqMpNGFmVmYPyKGbsxnLSBXAeiGnwzsnkQQh8w7MJB7UcrEV4 IJZw4894/s3gk9+UZ0C5HTgZtnrDtuK5asr2wkZbQw95gGjkc7IVpwbEweyuEvqt rosYOcOX2+Hs4a/rkMDyC6hxxqh5CrpsBJ7q68FMgxSN4UwR
=ssLn
-----END PGP SIGNATURE-----

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

Hi!

On Sun, 2024-03-31 at 06:54:10 +0200, Andreas Metzler wrote:

On 2024-03-30 Julian Gilbey <[email protected]> wrote:

My very limited understanding of this major transition was that the
t64 libraries are being held in unstable until (almost) everything is ready, at which point there will be a coordinated migration into
testing. But I've now been asked to upgrade something on my testing machine which pulls in a t64 library. Has something slipped through
the net, or is this intentional?

Looking through testing, I see the following t64 libraries present:

libaio1t64

I also stumbled over libaio1t64 and looked at the changelog. It is not
part of the transition in that it was simply rebuilt with different
compiler flags and therefore broke the ABI. Instead source code changes
were made to extend the ABI to support usage both from code built with
t64 flags and without.

Right, for libaio this is intentional. The changes were made to avoid
breaking the ABI (so as you say, implement dual ABI) because the
library uses direct syscalls so simply rebuilding with new flags would
have broken the ABI, although the actual SONAME change did then break
the ABI :), and it was done to avoid stomping over upstream interfaces.
Once I've looked into fixing Linux, I'll be submitting this upstream
with the hope that I can revert the SONAME change with backwards
compatibility symlink and package rename.


This also brings something I mentioned to Steve, but which I'm not
sure has been acted on. We need to check for all affected libraries
and whether they are using direct syscalls, because then if they do
not have explicit support for the equivalent 64-bit variants of those
syscalls, a simple rebuild of those libraries might actually have
broken the ABI between userland and kernel for those transitioned
packages. I had a list of the potentially affected syscalls, but need
to run out now, will try to post something better later today.

Thanks,
Guillem

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

On 2024-03-31 Andreas Metzler <[email protected]> wrote:
[...]

Afaict these are broken, though:

[...]

tnat64 0.06-1

false positive, grep error.

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

On 2024-03-31 Sven Joachim <[email protected]> wrote:

On 2024-03-31 06:54 +0200, Andreas Metzler wrote:

On 2024-03-30 Julian Gilbey <[email protected]> wrote:

[...]

Looking through testing, I see the following t64 libraries present:

libaio1t64
libfyba0t64
libglibmm-2.68-1t64
libnetcdf19t64
libudns0t64
libczmq4t64 (virtual package; libczmq4 provides this)

I have not checked all the others (libczmq4: "Undo 4.2.1-1.1. There are only 3 symbols with time_t, and they are not used in the distribution. Avoid to carry the package rename forever."), but suspect they are
similar.

Unfortunately the other four are not similar, but rather lacked a build dependency on dpkg-dev (>= 1.22.5) which would have prevented their
migration to testing. Testing users on armel and armhf should avoid installing them and downgrade to the pre-t64 version if necessary.

All of those noted above except udns have already been fixed in sid.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

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

On Sun, Mar 31, 2024 at 11:22:05AM +0200, Andreas Metzler wrote:

hdf5 1.10.10+repack-3.3

This one has an unanswered question from the maintainer in the NMU report,
and I feel like the reason for the missing line is the package having debian/control.in.

--
WBR, wRAR

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

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmYJMq0tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh L90QAJJXPlJ5ZO2wwFXIm3t5uuKKEZRZ6pk67TzTVmpiZciYcVCVuv3YP97V30jR asSpPEXeCgHcTAkr8mIBHEwjcXUBNHyhH8Cx+qd1FFvjdxiHOeNMParzyA7u84uc UR11VOQiN8zrDpT0Q5EXrAaPNws+KqDNYkcgU8uPjnV13JuQsVF8Oyh9HuxwWxku N7obHt1gs70HAMawaettAWD/+RNNYZHk3T7EPe7W2liiF8oWd2HpaSCXoFG6ePvf 59OksRRJe3JKpzEUCPZY3Eb4MZ9Agr27FPiotROgxfBsgC6nk1E3/vm9yz7jIsbA PCYsb0tujvS5BP2NPNBOl7dHz/R8dvavk9axDsed9HhGfaFMB/61ZBxqhu9+Oa19 Fj7znZZydnAuPjrY3unyHREyuRHI4oSJ7bKHkjhjeKehgexLsbVnWbIS9braNW+f tlTAbInPGhoFhWjQE1Q54R4KdXyV9HHXFV8+ExT0L2frTMXFzaopDbHzI1jbrbUp O9fAF1Fm+W/C6Fj6i3uHmDgZ41gExHYbthcrV+WwW+zgf1Rbhv9x0DpdfmKVhkwv 1Dmh65+ViQUWdhQ3pyWQaqdXCmp18AolADFRdU23LEseKhT0n8VKYB81d7qVz80I kL+7AT1AU26xZg7jNj/tXcCA4zkE4MuOQxcv/fxqewyw1lHc
=7fm8
-----END PGP SIGNATURE-----

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

31.03.2024 12:16, Andreas Metzler wrote:
...

Looking through testing, I see the following t64 libraries present:
libaio1t64
libfyba0t64
libglibmm-2.68-1t64
libnetcdf19t64
libudns0t64
libczmq4t64 (virtual package; libczmq4 provides this)

Unfortunately the other four are not similar, but rather lacked a build
dependency on dpkg-dev (>= 1.22.5) which would have prevented their
migration to testing. Testing users on armel and armhf should avoid
installing them and downgrade to the pre-t64 version if necessary.

All of those noted above except udns have already been fixed in sid.

What should be done with udns in this context?

I didn't know it should have versioned build-depend on dpkg-dev, and the original upload didn't have it either.

Thanks,

/mjt

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