Re: 64-bit time_t: an update

2023-07-31 Thread Simon Chopin
Hi all, Quoting Steve Langasek (2023-07-19 23:27:21) [snip] > The "good" news is that, although there are over 1500 -dev packages yet to > be analyzed, we have prioritized libraries based on the number of > reverse-dependencies and therefore these 1500 -dev packages have among them > less than

Re: 64-bit time_t: an update

2023-07-21 Thread Steve Langasek
On Thu, Jul 20, 2023 at 12:30:50AM +0100, Simon McVittie wrote: > On Wed, 19 Jul 2023 at 14:27:21 -0700, Steve Langasek wrote: > > to understand the impact that a change to the size of > > time_t will have on a library's ABI, it must be possible to compile the > > headers that expose that API >

Re: 64-bit time_t: an update

2023-07-19 Thread Simon McVittie
On Wed, 19 Jul 2023 at 14:27:21 -0700, Steve Langasek wrote: > to understand the impact that a change to the size of > time_t will have on a library's ABI, it must be possible to compile the > headers that expose that API Would the results of this analysis also be suitable for telling interested

64-bit time_t: an update

2023-07-19 Thread Steve Langasek
Hi folks, Two months ago, I posted with a proposal for how to handle a transition to 64-bit time_t on 32-bit archs in the trixie cycle. https://lists.debian.org/debian-devel/2023/05/msg00168.html We have pretty good consensus on the path forward; however, at the time I posted I had hoped to