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)
On 2024-03-30 Julian Gilbey <julian@d-and-j.net> 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.
My very limited understanding of this major transition was that theI assume it's not intentional, some packages just didn't get a dpkg dep
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?
On 2024-03-30 Julian Gilbey <julian@d-and-j.net> 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.
Afaict these are broken, though:[...]
tnat64 0.06-1
On 2024-03-31 06:54 +0200, Andreas Metzler wrote:[...]
On 2024-03-30 Julian Gilbey <julian@d-and-j.net> 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.
hdf5 1.10.10+repack-3.3This one has an unanswered question from the maintainer in the NMU report,
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:15:06 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,863 |