Re: 64-bit time_t transition in progress in unstable
Hi,
Am 08.03.24 um 00:12 schrieb Eric Valette:
On 07/03/2024 21:16, Rene Engelhard wrote:
ct more people.
But not so much for dependency issues like this. Which is my sole
point. In 99,9% of cases this won't even migrate to testing. And
unstable won't be released - testing will.
What is your point? Without known bugs or new versions packages
migrate from unstable to testing automatically.
You should be happy people debug code
*debug code*, yes. debug *actual* (dependency) issues, yes.
I did my part for example with this one, that maintainer denied first
but fixed later in his next upload as suggested...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065349
Well, you haven't seen the various discussion how to fix smbclient on IRC...
Not really. This is an affect of
* d/genshlibs: run dh_makeshlibs on libsmbclient0
(Closes: #1065349)
where the side effect is that one gets the provides via
Package: libsmbclient0
Provides: ${t64:Provides}
X-Time64-Compat: libsmbclient
That is the correct fix (with a similar result of what you suggests),
not what you suggested in the first mail, though.
Besides that your wrote:
You cannot install libsmbclient0 without breaking libsmbclient if the
version of libsmbclient is not at least 2:4.19.5+dfsg-3. It will then
replace libsmbclient.
BUT the package libsmbclient 2:4.19.5+dfsg-3 is never going to be
generated nor latter versions unless the names change back to
libsmbclient. So the condition will never happen.
That is plain wrong. Breaks: is not waiting for anything be there. It's
just a lesser version of Conflicts
> And as you state, if the time_t type is already 64 bits why should
package depending on libsmbclient need to be regenerated?
Here again you show that you don't get why this is done at all. And you
again ignore release archs in your reasoning completely.
(Whether one likes that those are release archs or not, is not relevant
here.):
Exactly because of armel/armhf where the time_t was not 64bit before.
libsmbclient r-deps *have* to be rebuilt. On armel/armhf for sure. For
the rest there's Provides:
Regards,
Rene
Re: 64-bit time_t transition in progress in unstable
Am 08.03.24 um 00:12 schrieb Eric Valette: On 07/03/2024 21:16, Rene Engelhard wrote: ct more people. But not so much for dependency issues like this. Which is my sole point. In 99,9% of cases this won't even migrate to testing. And unstable won't be released - testing will. What is your point? Without known bugs or new versions packages migrate from unstable to testing automatically. Except if their dependencies break in testing. Or dependencies of other packages are broken by migrating. That is something the testing scripts check - amongst other stuff. Regards, Rene
Re: 64-bit time_t transition in progress in unstable
On 07/03/2024 21:16, Rene Engelhard wrote: ct more people. But not so much for dependency issues like this. Which is my sole point. In 99,9% of cases this won't even migrate to testing. And unstable won't be released - testing will. What is your point? Without known bugs or new versions packages migrate from unstable to testing automatically. You should be happy people debug code *debug code*, yes. debug *actual* (dependency) issues, yes. I did my part for example with this one, that maintainer denied first but fixed later in his next upload as suggested... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065349 -- eric
Re: 64-bit time_t transition in progress in unstable
On Thu, Mar 07, 2024 at 09:16:10PM +0100, Rene Engelhard wrote: > Hi, > > Am 07.03.24 um 21:07 schrieb Eric Valette: > > On 07/03/2024 20:55, Rene Engelhard wrote: > > > > > unstable is unstable. Don't use it if you can't handle stuff like > > > this. And yes, be it even for more days or however it takes. > > > > > > The usual mantra. However, if no one use unstable and debug it to make > > it work correctly, maintainers will discover existing bug very late in > > the process and they will impact more people. > > But not so much for dependency issues like this. Which is my sole point. In > 99,9% of cases this won't even migrate to testing. And unstable won't be > released - testing will. > > > > You should be happy people debug code > > *debug code*, yes. debug *actual* (dependency) issues, yes. > > Insisting on (bogus) bug reports about dependency issues out of maintainer > control which will "magically" be solved once the release team does the > required bin-NMU: no. One might even go so far as to say that this - uncovering problems not foreseen by the people who planned (and put a lot of work into that) the transition, then started it (and put a lot of work into that, too), and are now working every day on analyzing the problems that pop up and resolving them ASAP - so, yeah, this is the *whole point* of unstable. Catching *all* of these problems and making sure none of the libraries that might cause them ever migrates to testing - this is the whole point. So yeah, thanks a lot to the drivers of this transition, to the Release Team, and to DDs (porters and otherwise) who help with that! IMHO, it is going even better than I expected :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: 64-bit time_t transition in progress in unstable
Hi, Am 07.03.24 um 21:07 schrieb Eric Valette: On 07/03/2024 20:55, Rene Engelhard wrote: unstable is unstable. Don't use it if you can't handle stuff like this. And yes, be it even for more days or however it takes. The usual mantra. However, if no one use unstable and debug it to make it work correctly, maintainers will discover existing bug very late in the process and they will impact more people. But not so much for dependency issues like this. Which is my sole point. In 99,9% of cases this won't even migrate to testing. And unstable won't be released - testing will. You should be happy people debug code *debug code*, yes. debug *actual* (dependency) issues, yes. Insisting on (bogus) bug reports about dependency issues out of maintainer control which will "magically" be solved once the release team does the required bin-NMU: no. Regards, Rene
Re: 64-bit time_t transition in progress in unstable
On 07/03/2024 20:55, Rene Engelhard wrote: unstable is unstable. Don't use it if you can't handle stuff like this. And yes, be it even for more days or however it takes. The usual mantra. However, if no one use unstable and debug it to make it work correctly, maintainers will discover existing bug very late in the process and they will impact more people. You should be happy people debug code in advance and thanks them instead of using this mantra (and I dunno how many debian bugs (100+) I have reported and sometime fixed myself). -- eric
Re: 64-bit time_t transition in progress in unstable
Hi, Am 07.03.24 um 20:33 schrieb Eric Valette: On 07/03/2024 19:58, Rene Engelhard wrote: > My point also was that your reopening of the bug is wrong since the maintainer can't do anything about it. E.g. if libreoffice wasn't rebuilt against most t64 r-deps since it a) also has libraries needing the rename which I b) did when the transition starts c) had a new release anyway. If that did't happen and LO wasn't rebuilt for the t64 libraries it now needs I'd have reacted the same way as for the bug you reopened. Can't do anything about that, the binNMUs will happen somwehen when ready. And you probably need to get out of your amd64 bubble, see below My "bubble" probably represent in volume 99% of debian users/installations so that is a big bubble! True. My laptop also is one (but incidentially runs stable as main system until the freeze when it will start running testing. rinse and repeat). I personally have a sid only in said sid VM. I admit that unstable installation volume is far less than stable but the proportion of people using unstable on arm/xxx is probably identical as stable. I don't think so, actually. It's probably lesser on sid for arm than the stable vs. unstable ratio of amd64. But it doesn't really matter anyway. arm* is release architectures and so need to get the rebuilds anyway at some time. I completely can understand that the RT doesn't do those bin-NMUs per arch (when?) but just when it's actually ready. Well well, you annoy 99% of unstable debian users. unstable is unstable. Don't use it if you can't handle stuff like this. And yes, be it even for more days or however it takes. Regards, Rene
Re: 64-bit time_t transition in progress in unstable
On Thu, Mar 07, 2024 at 12:20:22AM -0500, Theodore Ts'o wrote: > > Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I > > actually would expect unstable to be dist-upgradeable on non-32-bit archs: > > either the existing non-t64 library will be kept installed because nothing > > yet needs the t64 version, or something does want the t64 version and apt > > will accept it as a replacement for the non-t64 version because it Provides: > > the non-t64 name. > > So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is > > NOT working, I think we should want to see some apt output showing what's > > not working. > Sorry, I've been crazy busy so I didn't have time to object to > libuuid1t64 as bewing compltely unnecessary before it had rolled out > to unstable. Similarly, libcom-err2 and libss2 don't use time_t, so > the rename to ...t64 was completely unnecessary. Yes, apologies, we can't assume any particular mapping from -dev packages to runtime lib packages in packages that have multiple -dev packages, so libcom-err2 and libss2 were swept up in the renaming and I only noticed after the fact that this was unnecessary. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: 64-bit time_t transition in progress in unstable
On 07/03/2024 19:58, Rene Engelhard wrote: I'm sure it will be done at some point. However, I just point out that on amd64 Maybe, though in my sid VM with all tasks installed plasma-workspace fails to upgrade, claiming about gdb-minmal | gdb not to be installed whereas both of that install, but that doesn't help it futher. Didn't debug, no KDE person. If you look at my first post in this thread I explain how to install libelfxxx without removing gdb. Apt has problem finding a correct path for some T64 packages but if you explicitly put each packages apt naively and wrongly wants to remove in the install line it find the correct path. Other have confirmed this methods works (see in thread) and not only for libelf but many others problematic packages. A bug or limitation of apt. Dunno. My point also was that your reopening of the bug is wrong since the maintainer can't do anything about it. And you probably need to get out of your amd64 bubble, see below My "bubble" probably represent in volume 99% of debian users/installations so that is a big bubble! I admit that unstable installation volume is far less than stable but the proportion of people using unstable on arm/xxx is probably identical as stable. I completely can understand that the RT doesn't do those bin-NMUs per arch (when?) but just when it's actually ready. Well well, you annoy 99% of unstable debian users. A choice that you are perfectly entitled to make, as I am for complaining of consequences because of having hard time to help apt to find a migration path (and time consuming solution). I imagine it is even worse on other arch. -- eric
Re: Libfuse interoperability/ABI broken.
Hi all,
this is certainly not kind of the mail I was hoping for as a new libfuse
maintainer.
As you can see from the title and from discussion below (sorry this is
not typical ML discussion style), we have a bit of of problem with
libfuse ABI compatibility.
While scanning through git history, Ashley found a commit that was adding
members in the middle of struct - doesn't break API, but binary
compatibility. That commit already landed a year ago in these releases:
git tag --contains a5eb7f2a0117ab43119ef5724cf5f4f2f181804a
fuse-3.14.1
fuse-3.15.0
fuse-3.15.1
fuse-3.16.1
fuse-3.16.2
Obviously this needs improved testing for, but right now we wonder what
would be the preferred action to avoid issues.
a) We could fix it and move bits to the right place. Fixes everything
compiled with old versions, but breaks everything compiled with the
versions above
b) Increase the .so version - enforces recompilation of all binaries.
Intrusive, especially for distributions, but probably safest.
c) Other ideas?
I don't think there is anything in libfuse that would allow us to
detect which version of libfuse a library was linked to.
The commit shifted these members in struct fuse_file_info {
struct fuse_file_info {
...
/** Can be filled by open/create, to allow parallel direct writes on
this
* file */
unsigned int parallel_direct_writes : 1; --> introduced the shift
/** Indicates a flush operation. Set in flush operation, also
maybe set in highlevel lock operation and lowlevel release
operation. */
unsigned int flush : 1;
/** Can be filled in by open, to indicate that the file is not
seekable. */
unsigned int nonseekable : 1;
/* Indicates that flock locks for this file should be
released. If set, lock_owner shall contain a valid value.
May only be set in ->release(). */
unsigned int flock_release : 1;
/** Can be filled in by opendir. It signals the kernel to
enable caching of entries returned by readdir(). Has no
effect when set in other contexts (in particular it does
nothing when set by open()). */
unsigned int cache_readdir : 1;
/** Can be filled in by open, to indicate that flush is not needed
on close. */
unsigned int noflush : 1;
};
I.e. setting flush would actually set parallel_direct_writes
(note: with binaries compiled against older libfuse versions)
For the high level API it is probably less critical, in struct fuse_config
these fields are shifted:
struct fuse_config {
...
/**
* Allow parallel direct-io writes to operate on the same file.
*
* FUSE implementations which do not handle parallel writes on
* same file/region should NOT enable this option at all as it
* might lead to data inconsistencies.
*
* For the FUSE implementations which have their own mechanism
* of cache/data integrity are beneficiaries of this setting as
* it now open doors to parallel writes on the same file (without
* enabling this setting, all direct writes on the same file are
* serialized, resulting in huge data bandwidth loss).
*/
int parallel_direct_writes;
/**
* The remaining options are used by libfuse internally and
* should not be touched.
*/
int show_help;
char *modules;
int debug;
};
I don't think there is a security concern, but probably more a
data safety issue. So I included open mailing lists.
Thanks,
Bernd
On 3/7/24 19:02, Ashley Pittman wrote:
>
> Simply bumping the .so number and forcing a rebuild would certainly work. It
> would probably be the safest option but also put the highest cost on users,
> although I think for this kind of bug then a manual step of verifying the
> versions are correct is needed so forcing a build failure isn’t a bad option.
> It would massively increase the visibility if this if nothing else.
>
> Perhaps we should bring in the distro package maintainers here for their
> guidance/input? Like I say I’ve not had experience of this type of issue
> before but I’m sure the distros will have.
>
> Ashley.
>
>> On 7 Mar 2024, at 16:05, Bernd Schubert wrote:
>>
>> Hi Ashley,
>>
>> thanks for spotting and embarrassing as I had been involved in
>> development that feature.
>>
>> Hard to decide if revert it right - issue is, if we revert, everything
>> linked with the new version would broken as well. And it is now already
>> a year...
>>
>> I think we can only increase the .so version and send out a warning
>> (mailing list, distributions).
>>
>> In order to avoid it in the future, we can probably add some compile
>> time asserts about struct member positions.
>>
>>
>> Bernd
>>
>> On 3/7/24 16:43, Ashley Pittman wrote:
>>>
>>> I’ve spotted an issue with the linked
Re: 64-bit time_t transition in progress in unstable
Am 07.03.24 um 19:21 schrieb Eric Valette: On 07/03/2024 18:57, Rene Engelhard wrote: That one is tracked and will get appropriate bin-NMUs from the release team, I am sure. It is right that this uninstallability is "being part of the normal things due to transition". I'm sure it will be done at some point. However, I just point out that on amd64 Maybe, though in my sid VM with all tasks installed plasma-workspace fails to upgrade, claiming about gdb-minmal | gdb not to be installed whereas both of that install, but that doesn't help it futher. Didn't debug, no KDE person. My point also was that your reopening of the bug is wrong since the maintainer can't do anything about it. He will not schedule the bin-NMU (actually can't, and a manual binary only build will just make it blocked from entering testing, requiring a bin-NMU _again_). As he said it IS "being part of the normal things due to transition". Even if it it like that for a week now or longer. And you probably need to get out of your amd64 bubble, see below this is the last set of packages that are uninstallable currently on all my systems (except the one when i manually edited the control file) and this has been so since 29 february. And I guess it will be for some longer since the archs where t64 actually matters (armel/armhf) has most of the affected packages not being rebuilt since it's stuck behind uninstallable stuff and needs manual bootstrap uploads. I completely can understand that the RT doesn't do those bin-NMUs per arch (when?) but just when it's actually ready. Regards, Rene
Re: 64-bit time_t transition in progress in unstable
On 07/03/2024 18:57, Rene Engelhard wrote: That one is tracked and will get appropriate bin-NMUs from the release team, I am sure. It is right that this uninstallability is "being part of the normal things due to transition". I'm sure it will be done at some point. However, I just point out that on amd64 this is the last set of packages that are uninstallable currently on all my systems (except the one when i manually edited the control file) and this has been so since 29 february. -- eric
Re: 64-bit time_t transition in progress in unstable
Am 07.03.24 um 09:55 schrieb Eric Valette: On 07/03/2024 07:25, Kevin Bowling wrote: As of this evening these are the packages that currently have broken deps on amd64 for me: gstreamer1.0-plugins-good gstreamer1.0-pulseaudio libkf5akonadisearch-bin libkf5akonadisearch-plugins occt-misc Someone already opened a bug for libkf5akonadisearch-bin libkf5akonadisearch-plugins that has been closed as "being part of the normal things due to transition" but I reopened it as: The maintainer transitionned the "abi name" to "abi name"t64 but many package still depend on old "abi name" and are not going to be rebuild unless someone force it. https://release.debian.org/transitions/html/auto-akonadi-search.html That one is tracked and will get appropriate bin-NMUs from the release team, I am sure. It is right that this uninstallability is "being part of the normal things due to transition". Regards, Rene
Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote: > On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote: > > Hi Dima, > > > > > On 7 Feb 2024, at 18:27, Dima Kogan wrote: > > > > > > Hi. Thanks for your contribution. I looked at the upstream code a tiny > > > bit, and it looks like it might have portability bug, at least on > > > big-endian architectures. For instance: > > > > > > > > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > > > > > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be > > > nice to fix. Are you upstream or do you know upstream? Can yall fix > > > these? > > > > The kernel expects a 4 byte write here, since unsigned long is defined as > > at least 32 bit this shall work on all architectures. > > > > If your concern is about endianess this is not in the current scope of > > libuio and needs to be addressed by a higher layer. > > > > I am very familiar with library and in close contact with upstream. > > In the case of uio_disable_irq() the bug is nicely hidden by the fact > that tmp is guaranteed to be all-zeroes. However, consider the previous > function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8, > then the "tmp" variable's value of 1 will be encoded in memory as > 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively. > When uio_enable_irq() calls write(..., &tmp, 4), it will only send > the first four bytes to the kernel - and they are 0, 0, 0, and... 0. > So it turns out that uio_disable_irq() and uio_enable_irq() do > exactly the same - send a 32-bit zero value to the kernel. ...of course, this will only happen on a big-endian system, as Dima Kogan was concerned about. On a little-endian system, this will work by chance. > Is this the expected behavior indeed? -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote: > Hi Dima, > > > On 7 Feb 2024, at 18:27, Dima Kogan wrote: > > > > Hi. Thanks for your contribution. I looked at the upstream code a tiny > > bit, and it looks like it might have portability bug, at least on > > big-endian architectures. For instance: > > > > > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > > > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be > > nice to fix. Are you upstream or do you know upstream? Can yall fix > > these? > > The kernel expects a 4 byte write here, since unsigned long is defined as at > least 32 bit this shall work on all architectures. > > If your concern is about endianess this is not in the current scope of libuio > and needs to be addressed by a higher layer. > > I am very familiar with library and in close contact with upstream. In the case of uio_disable_irq() the bug is nicely hidden by the fact that tmp is guaranteed to be all-zeroes. However, consider the previous function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8, then the "tmp" variable's value of 1 will be encoded in memory as 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively. When uio_enable_irq() calls write(..., &tmp, 4), it will only send the first four bytes to the kernel - and they are 0, 0, 0, and... 0. So it turns out that uio_disable_irq() and uio_enable_irq() do exactly the same - send a 32-bit zero value to the kernel. Is this the expected behavior indeed? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
Hi Dima, > On 7 Feb 2024, at 18:27, Dima Kogan wrote: > > Hi. Thanks for your contribution. I looked at the upstream code a tiny > bit, and it looks like it might have portability bug, at least on > big-endian architectures. For instance: > > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be > nice to fix. Are you upstream or do you know upstream? Can yall fix > these? The kernel expects a 4 byte write here, since unsigned long is defined as at least 32 bit this shall work on all architectures. If your concern is about endianess this is not in the current scope of libuio and needs to be addressed by a higher layer. I am very familiar with library and in close contact with upstream. Best regards Manuel
Re: Rebuilding old packages to get rid of overalignment on amd64 which reduces ASLR
On Thu, Mar 7, 2024 at 6:06 AM Mathias Krause wrote: > I, thereby, request to rebuild affected packages. We are rebuilding thousands of packages for the ongoing 32-bit time_t transition. Maybe you can propose this again after the rebuilds for that are finished? Thank you, Jeremy Bícha
Rebuilding old packages to get rid of overalignment on amd64 which reduces ASLR
Dear Debian developers, I've filled a few individual bugs[1,2,3,4] but Emilio suggested, to bring up the topic here for effectiveness and coordination. Triggered by a blog post[5], I started to look into some of my Debian amd64 based systems and noticed, certain binaries and libraries have an overly huge segment alignment (2MB instead of the usual 4kB). This was no issue until "recently", as it was basically ignored by the Linux kernel ELF loader and the (glibc based) runtime linker. However, kernel[6] and glibc[7] patches changed this and the ELF segment alignment will be honored by each respectively since then (kernel ELF loader, aligning PT_LOAD entries of binaries accordingly; runtime linker, aligning PT_LOAD entries of loaded shared libraries). I wrote an article[8] about the topic, providing some history and relating it to Debian releases. Basically, all binary packages that haven't been rebuild since stretch are prone to the over-alignment. The over-alignment is bad, as it reduces the number of available ASLR bits and, thereby, weakens this probabilistic mitigation, accelerating brute force attacks. Fortunately, it's mostly only old packages that are affected. However, some of these are used with recent software as well (the X related libraries, for example). To get rid of the over-alignment, a rebuild with a linker that doesn't enforce the overly huge alignment any more is sufficient. In Debian terms that would be anything starting with buster. I, thereby, request to rebuild affected packages. Detecting if a package is affected can be done with either the script[9] we provided along with the blog post, or by making use of readelf. For the latter it would be to look for oddities like below: minipli@nuc:~$ readelf -WSl /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 There are 27 section headers, starting at offset 0x5208: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .note.gnu.build-id NOTE01c8 0001c8 24 00 A 0 0 4 [ 2] .gnu.hash GNU_HASH01f0 0001f0 000180 00 A 3 0 8 [ 3] .dynsym DYNSYM 0370 000370 000600 18 A 4 1 8 [ 4] .dynstr STRTAB 0970 000970 00041f 00 A 0 0 1 [ 5] .gnu.version VERSYM 0d90 000d90 80 02 A 3 0 2 [ 6] .gnu.version_rVERNEED 0e10 000e10 50 00 A 4 2 8 [ 7] .rela.dyn RELA0e60 000e60 c0 18 A 3 0 8 [ 8] .rela.plt RELA0f20 000f20 000258 18 AI 3 22 8 [ 9] .init PROGBITS1178 001178 17 00 AX 0 0 4 [10] .plt PROGBITS1190 001190 0001a0 10 AX 0 0 16 [11] .plt.got PROGBITS1330 001330 08 00 AX 0 0 8 [12] .text PROGBITS1340 001340 001908 00 AX 0 0 16 [13] .fini PROGBITS2c48 002c48 09 00 AX 0 0 4 [14] .rodata PROGBITS2c60 002c60 001020 00 A 0 0 32 [15] .eh_frame_hdr PROGBITS3c80 003c80 00016c 00 A 0 0 4 [16] .eh_frame PROGBITS3df0 003df0 0008d4 00 A 0 0 8 [17] .init_array INIT_ARRAY 00204de0 004de0 08 08 WA 0 0 8 [18] .fini_array FINI_ARRAY 00204de8 004de8 08 08 WA 0 0 8 [19] .jcr PROGBITS00204df0 004df0 08 00 WA 0 0 8 [20] .dynamic DYNAMIC 00204df8 004df8 0001e0 10 WA 4 0 8 [21] .got PROGBITS00204fd8 004fd8 28 08 WA 0 0 8 [22] .got.plt PROGBITS00205000 005000 e0 08 WA 0 0 8 [23] .data PROGBITS002050e0 0050e0 08 00 WA 0 0 8 [24] .bss NOBITS 002050e8 0050e8 08 00 WA 0 0 1 [25] .gnu_debuglinkPROGBITS 0050e8 34 00 0 0 1 [26] .shstrtab STRTAB 00511c ec 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), D (mbind), l (large), p (processor specific) Elf file type is DYN (Shared object file) Entry point 0x1340 There are 7 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x 0x 0x0046c4 0x0046c4 R E 0x20 LOAD
Re: 64-bit time_t transition in progress in unstable
On 07/03/2024 07:25, Kevin Bowling wrote: As of this evening these are the packages that currently have broken deps on amd64 for me: gstreamer1.0-plugins-good gstreamer1.0-pulseaudio libkf5akonadisearch-bin libkf5akonadisearch-plugins occt-misc Someone already opened a bug for libkf5akonadisearch-bin libkf5akonadisearch-plugins that has been closed as "being part of the normal things due to transition" but I reopened it as: The maintainer transitionned the "abi name" to "abi name"t64 but many package still depend on old "abi name" and are not going to be rebuild unless someone force it. -- eric
