Re: Some t64 libraries already in testing; I'm confused
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 signature.asc Description: PGP signature
Re: Some t64 libraries already in testing; I'm confused
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
Re: Some t64 libraries already in testing; I'm confused
On 2024-03-31 Andreas Metzler wrote: [...] > Afaict these are broken, though: [...] > tnat64 0.06-1 false positive, grep error.
Re: Some t64 libraries already in testing; I'm confused
On 2024-03-31 Andreas Metzler wrote: > On 2024-03-31 Sven Joachim wrote: [...] >> 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. Afaict these are broken, though: cpdb-libs 2.0~b5-1.2 dante 1.4.3+dfsg-1 fuse 2.9.9-8.1 gambc 4.9.3-1.3 hdf5 1.10.10+repack-3.3 libdmapsharing 3.9.13-2 libgom 0.4-3 libgweather4 4.4.2-1 libgxps 0.3.2-4 libhinawa 4.0.1-2.2 llvm-toolchain-15 1:15.0.7-14 llvm-toolchain-16 1:16.0.6-24 llvm-toolchain-17 1:17.0.6-9 lomiri-ui-toolkit 1.3.5100+dfsg-1 ogre-1.12 1.12.10+dfsg2-6 pacman-package-manager 6.0.2-6 pangomm2.48 2.52.0-1 tnat64 0.06-1 udns 0.5-1 vte 1:0.28.2-6.1 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'
Re: Some t64 libraries already in testing; I'm confused
On 2024-03-31 Sven Joachim wrote: > On 2024-03-31 06:54 +0200, Andreas Metzler wrote: > > On 2024-03-30 Julian Gilbey 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'
Re: Some t64 libraries already in testing; I'm confused
Hi! On Sun, 2024-03-31 at 06:54:10 +0200, Andreas Metzler wrote: > On 2024-03-30 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? > > > 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
Re: Some t64 libraries already in testing; I'm confused
On Sat, Mar 30, 2024 at 10:41:55PM +, 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 signature.asc Description: PGP signature
Re: Some t64 libraries already in testing; I'm confused
On 2024-03-31 06:54 +0200, Andreas Metzler wrote: > On 2024-03-30 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? > >> 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
Re: Some t64 libraries already in testing; I'm confused
On 2024-03-30 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? > 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'
Some t64 libraries already in testing; I'm confused
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
