Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #107930

Re: 64-bit time_t transition for 32-bit archs: a proposal

From Steve Langasek <vorlon@debian.org>
Newsgroups linux.debian.devel
Subject Re: 64-bit time_t transition for 32-bit archs: a proposal
Date 2023-05-18 21:10 +0200
Message-ID <GwRaF-9OZi-1@gated-at.bofh.it> (permalink)
References <GwgNP-9s1z-1@gated-at.bofh.it> <GwAjv-9E54-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On Thu, May 18, 2023 at 03:04:30AM +0200, Guillem Jover wrote:
> On Tue, 2023-05-16 at 21:04:10 -0700, Steve Langasek wrote:
> > === Technical details ===

> > The proposed implementation of this transition is as follows:

> > * Update dpkg-buildflags to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64
> >   by default on 32-bit archs.  (Note that this enables LFS support, because
> >   glibc’s 64-bit time_t implementation is only available with LFS also
> >   turned on, to avoid a combinatorial explosion of entry points.)

> As has been mentioned, there's future=+time64 support in dpkg git HEAD
> targeted at 1.22.0. This gets automatically disabled on ports where
> time_t is known to be 64-bits (even if the port is 32-bits). When time64
> is set it does indeed force future=+lfs. (But I've got locally a few
> commits fixing and improving the logic for some of the ports which
> will push out in a bit.)

> I'm perhaps missing something, but the ordering here seems wrong/odd?
> Enabling this by default globally before the shared libraries affected
> by the ABI have been handled seems to me would mean a mess of ABIs
> in unstable until the entire thing converges?

The proposal is to treat this as a flag day, where the toolchain (in this
case, dpkg-buildflags) changes, then we upload the affected libraries in a
short period of time, then once they're built and through new we rebuild the
reverse-dependencies.  This is basically the same approach as was used for
past ABI transitions (ldbl, c102, c2) with the only difference here that the
change triggering the flag day would be in dpkg rather than gcc(-defaults).

There could be some misbuilt binaries in unstable if the maintainer uploads
them after dpkg is uploaded, but before the libraries are built.  If we
uploaded all of the library packages to set DEB_BUILD_MAINT_OPTIONS =
feature=+time64 we would avoid this race, but it would mean more
non-scriptable changes to debian/rules which I would rather avoid, and this
didn't prove necessary in past transitions; the impact of any misbuilt
binaries would be short-lived as they would be replaced ASAP with binNMUs.

> > * … but NOT on i386.  Because i386 as an architecture is primarily of
> >   interest for running legacy binaries which cannot be rebuilt against a new
> >   ABI, changing the ABI on i386 would be counterproductive, as mentioned in
> >   https://wiki.debian.org/ReleaseGoals/64bit-time.

> Like Russ, I'm also dubious about this, and introduces a special case
> and complexity that does not seem warranted TBH. If this was the case it
> would seem to me it would disallow SOVERSION bumps for example, which we
> have never been concerned with.

I didn't see anything in Russ's email in this thread that implied he was
dubious of this approach?  He simply has a library he maintains for which he
believes binary compatibility is uninteresting.

FWIW in Ubuntu where we maintain i386 strictly as an architecture for
compatibility with third-party binaries, we have 1034 source packages that
build Arch: i386 debs.  Not all of those source packages are shared
libraries, but enough of them are that manually updating them to maintain
ABI compatibility on i386 would be a substantial amount of work.  In terms
of overall complexity, I think the scales tip in favor of the toolchain not
defaulting to _TIME_BITS=64 on i386.

> > * For a small number of packages (~80) whose ABI is not sensitive to time_t
> >   but IS sensitive to LFS, along with their reverse-dependencies, filter out
> >   the above buildflags with DEB_BUILD_MAINT_OPTIONS=future=-lfs[1]. 
> >   Maintainers may choose to introduce an ABI transition for LFS, but as this
> >   is not required for time_t, we should not force it as part of *this*
> >   transition.  If there is a package that depends on both a time_t-sensitive
> >   library and an LFS-sensitive but time_t-insensitive library, however, then
> >   the LFS library will need to transition.  

> Hmm, I'm not sure whether I'm not understanding this point. Perhaps it
> is assuming that future=-lfs will strip the LFS options from the
> emitted flags? (If so that only disables the feature, but does no
> stripping). Also as mentioned above when the +time64 feature is enabled
> an -lfs would not be effective at all anyway, and should not! Because if
> the time64 flags are emitted glibc will error out if the LFS ones are
> not set. (See <features-time64.h>.)

> So perhaps this means to say that in these cases we'd use:

>   DEB_BUILD_MAINT_OPTIONS=future=-time64

> ?

Yes, my expectation was that future=-lfs would remove the LFS and time_t
flags from the output (the latter, because time64 depends on lfs).  But I'm
not wedded to this particular interface!  My only intent is that there be a
simple, short interface for disabling time64+lfs when needed.

(I do think that continuing to use 'future' as the canonical category for
these flags is wrong and confusing, given that we're talking about them no
longer being 'future' but enabled by default.)

> > * In order to not unnecessarily break compatibility with third-party (or
> >   obsolete) packages on architectures where the ABI is not actually
> >   changing, on 64-bit archs + i386, emit a Provides/Replaces/Breaks of the
> >   old library package name.  A sample implementation of the necessary
> >   packaging changes is at
> >   https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/time-t-me.

> I appreciate the desire to reduce inflicting these effects on arches
> that are not affected, but I don't _think_ (or do not recall) we have
> ever done this kind of special casing when doing similar ABI changing
> transitions in the past? And while ports have clearly arch-specific
> divergences when it comes to dependencies, it seems to me this would
> create a divide at a very different scale? Say for upgrade paths and
> similar testing.

You're right, we haven't done this before.  I thought it worth doing because
although this is roughly the same order of magnitude of transition as the
others we've done, it is still larger and affects not just C++ but also C
libraries.  

shlibs and symbol versions follow the rename, and binNMUs would happen
across all architectures *specifically* to ensure there's not a difference
in upgrade paths.  The only difference would be continued installability of
third-party or obsolete binary packages.

> Personally, I'm not sure I'd be thrilled to add that kind of code to
> packages I maintain. :)

One suggestion I received out-of-band was to put the debian/rules logic
inside of debhelper instead.  Would you find that more palatable?

> > [1] Seeing that the future is now, maybe we want to consider changing the
> >     canonical name for this from future=-lfs to abi=-lfs?  Bikeshed at will!

> Well, we are still not done with LFS, and I'm not seeing the end of that,
> so it seemed appropriate at the time, and it kind of still does. :) The
> «abi» name seems nice in that it conveys more clearly than «future» that
> this can break the ABI (although not necessarily so), but in this case
> it's probably better to err on the scarier meaning. So I'll check what
> it would take to introduce an alias for that and ponder about it as
> there's of course the danger of added confusion. But thanks for the
> suggestion!

Thanks!

And btw, given the analysis that there are likely < 100 shared libraries
overall whose ABI changes when enabling LFS, this might be a change we want
to consider in the trixie cycle as well - just preferably not bundled with
the time_t transition at the same time, as that would just cause more delays
for testing migration vs splitting the two transitions.

-- 
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/
slangasek@ubuntu.com                                     vorlon@debian.org

Back to linux.debian.devel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-17 06:20 +0200
  Re: 64-bit time_t transition for 32-bit archs: a proposal Russ Allbery <rra@debian.org> - 2023-05-17 06:40 +0200
    Re: 64-bit time_t transition for 32-bit archs: a proposal YunQiang Su <wzssyqa@gmail.com> - 2023-05-17 07:50 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-18 22:10 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Florian Lohoff <f@zz.de> - 2023-05-22 10:30 +0200
    Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-18 07:10 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Marco d'Itri <md@Linux.IT> - 2023-05-18 12:10 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Russ Allbery <rra@debian.org> - 2023-05-18 16:50 +0200
          Re: 64-bit time_t transition for 32-bit archs: a proposal Wookey <wookey@wookware.org> - 2023-05-18 18:20 +0200
            Re: 64-bit time_t transition for 32-bit archs: a proposal Olaf Titz <olaf@bigred.inka.de> - 2023-06-26 20:50 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Russ Allbery <rra@debian.org> - 2023-05-18 16:50 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Christoph Biedl <debian.axhn@manchmal.in-ulm.de> - 2023-05-18 21:20 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Russ Allbery <rra@debian.org> - 2023-05-18 21:40 +0200
  Re: 64-bit time_t transition for 32-bit archs: a proposal Helmut Grohne <helmut@subdivi.de> - 2023-05-17 11:40 +0200
    Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-18 07:40 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Helmut Grohne <helmut@subdivi.de> - 2023-05-28 21:20 +0200
  Re: 64-bit time_t transition for 32-bit archs: a proposal Craig Small <csmall@debian.org> - 2023-05-17 14:30 +0200
    Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-17 17:50 +0200
  Re: 64-bit time_t transition for 32-bit archs: a proposal Guillem Jover <guillem@debian.org> - 2023-05-18 03:10 +0200
    Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-18 21:10 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Guillem Jover <guillem@debian.org> - 2023-05-19 05:40 +0200
        i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Steve McIntyre <steve@einval.com> - 2023-05-19 13:50 +0200
          Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Luca Boccassi <bluca@debian.org> - 2023-05-19 14:40 +0200
            Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Steve McIntyre <steve@einval.com> - 2023-05-19 16:10 +0200
              Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2023-05-19 16:30 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Colin Watson <cjwatson@debian.org> - 2023-05-19 16:40 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2023-05-19 17:10 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Steve McIntyre <steve@einval.com> - 2023-05-19 19:40 +0200
                Re: i386 in the future  Ivan Shmakov <ivan@siamics.net> - 2023-05-25 13:30 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Simon McVittie <smcv@debian.org> - 2023-05-19 17:40 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Steve Langasek <vorlon@debian.org> - 2023-05-19 18:00 +0200
                partial support for i386 (Re: i386 in the future (was Re: 64-bit  time_t transition for 32-bit archs: a proposal)) Michael Biebl <biebl@debian.org> - 2023-05-19 19:50 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Jonathan Carter <jcc@debian.org> - 2023-05-22 12:30 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-05-19 17:40 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Steve Langasek <vorlon@debian.org> - 2023-05-19 18:00 +0200
              Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386 Ansgar <ansgar@43-1.org> - 2023-05-19 17:40 +0200
                Re: Bug#1036358: release-notes: Debian 12 expected to be last release  w/ installer for i386 Michael Biebl <biebl@debian.org> - 2023-05-19 19:40 +0200
              Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) "Andrew M.A. Cater" <amacater@einval.com> - 2023-05-19 19:10 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Cyril Brulebois <kibi@debian.org> - 2023-05-19 19:30 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Michael Biebl <biebl@debian.org> - 2023-05-19 20:30 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Steve McIntyre <steve@einval.com> - 2023-05-19 19:40 +0200
              Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Bjørn Mork <bjorn@mork.no> - 2023-05-19 21:30 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Ansgar <ansgar@43-1.org> - 2023-05-19 22:00 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Bjørn Mork <bjorn@mork.no> - 2023-05-19 22:40 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Cyril Brulebois <kibi@debian.org> - 2023-05-20 07:10 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) James Addison <jay@jp-hosting.net> - 2023-05-20 14:00 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a  proposal) Diederik de Haas <didi.debian@cknow.org> - 2023-05-31 01:00 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Steve Langasek <vorlon@debian.org> - 2023-05-31 06:00 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) John Goerzen <jgoerzen@complete.org> - 2023-05-31 14:40 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Sven Hoexter <sven@stormbind.net> - 2023-05-31 16:20 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Gunnar Wolf <gwolf@debian.org> - 2023-05-31 18:40 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Wookey <wookey@wookware.org> - 2023-05-31 20:50 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Ansgar <ansgar@43-1.org> - 2023-05-31 21:30 +0200
                Re:  Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-05-31 07:00 +0200
                Re: Re: i386 in the future (was Re: 64-bit time_t transition for  32-bit archs: a proposal) James Addison <jay@jp-hosting.net> - 2023-05-31 10:30 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Wouter Verhelst <wouter@debian.org> - 2023-05-31 12:50 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Alexandre Detiste <alexandre.detiste@gmail.com> - 2023-05-31 13:10 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Sven Hoexter <sven@stormbind.net> - 2023-05-31 16:10 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Gunnar Wolf <gwolf@debian.org> - 2023-05-31 18:30 +0200
                  Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a  proposal) Diederik de Haas <didi.debian@cknow.org> - 2023-05-31 23:30 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) "Andrew M.A. Cater" <amacater@einval.com> - 2023-06-01 00:20 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Adam Borowski <kilobyte@angband.pl> - 2023-06-01 15:20 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) nick black <dankamongmen@gmail.com> - 2023-06-02 19:00 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Wouter Verhelst <wouter@debian.org> - 2023-06-02 21:10 +0200
                  Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a  proposal) Diederik de Haas <didi.debian@cknow.org> - 2023-06-02 23:40 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for  32-bit archs: a proposal) Paul Wise <pabs@debian.org> - 2023-06-01 03:40 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) "Theodore Ts'o" <tytso@mit.edu> - 2023-06-01 14:20 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> - 2023-06-08 02:20 +0200
          Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Steve Langasek <vorlon@debian.org> - 2023-05-19 17:50 +0200
            Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Steve McIntyre <steve@einval.com> - 2023-05-19 19:50 +0200
          Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Guillem Jover <guillem@debian.org> - 2023-05-19 20:10 +0200
          Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) James Addison <jay@jp-hosting.net> - 2023-05-19 20:50 +0200
            Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Ansgar <ansgar@43-1.org> - 2023-05-20 00:00 +0200
              Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) James Addison <jay@jp-hosting.net> - 2023-05-21 08:00 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) Roger Lynn <Roger@rilynn.me.uk> - 2023-05-26 01:30 +0200
                Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit  archs: a proposal) James Addison <jay@jp-hosting.net> - 2023-05-26 06:50 +0200
            Using i386 by mistake on 64-bit hardware [was Re: i386 in the future  32-bit archs: a proposal)] Josh Triplett <josh@joshtriplett.org> - 2023-05-20 09:20 +0200
              Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the  future 32-bit archs: a proposal)] Simon Richter <sjr@debian.org> - 2023-05-20 11:30 +0200
              Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the  future 32-bit archs: a proposal)] Adam Borowski <kilobyte@angband.pl> - 2023-05-20 18:50 +0200
                Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the  future 32-bit archs: a proposal)] Stephen Kitt <skitt@debian.org> - 2023-05-21 20:00 +0200
                Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the  future 32-bit archs: a proposal)] James Addison <jay@jp-hosting.net> - 2023-05-22 14:30 +0200
          Re: i386 in the future Wookey <wookey@wookware.org> - 2023-05-20 05:30 +0200
            Re: i386 in the future Ansgar <ansgar@43-1.org> - 2023-05-20 10:00 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-23 03:20 +0200
          Re: 64-bit time_t transition for 32-bit archs: a proposal Guillem Jover <guillem@debian.org> - 2023-06-08 04:10 +0200
            Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-06-14 06:50 +0200
              Re: 64-bit time_t transition for 32-bit archs: a proposal Guillem Jover <guillem@debian.org> - 2023-06-17 17:50 +0200
  Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-18 08:40 +0200
  Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-20 02:30 +0200
  Re: 64-bit time_t transition for 32-bit archs: a proposal Wookey <wookey@wookware.org> - 2023-05-20 13:30 +0200
    Re: 64-bit time_t transition for 32-bit archs: a proposal Andreas Metzler <ametzler@bebt.de> - 2023-05-20 17:50 +0200
    Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-23 03:30 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-23 03:30 +0200
  Re: 64-bit time_t transition for 32-bit archs: a proposal Helmut Grohne <helmut@subdivi.de> - 2023-06-06 09:40 +0200
    Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-06 12:50 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Luca Boccassi <bluca@debian.org> - 2023-06-06 13:10 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Marco d'Itri <md@Linux.IT> - 2023-06-06 17:30 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Gunnar Wolf <gwolf@debian.org> - 2023-06-06 20:30 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-06 21:50 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Alexis Murzeau <amubtdx@gmail.com> - 2023-06-06 21:50 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-08 21:10 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-07 06:40 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Andreas Metzler <ametzler@bebt.de> - 2023-06-08 07:10 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-08 21:20 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-08 07:40 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2023-06-08 08:40 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Hakan Bayındır <hakan@bayindir.org> - 2023-06-08 10:50 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Holger Levsen <holger@layer-acht.org> - 2023-06-08 11:00 +0200
          Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-09 06:00 +0200
            Re: 64-bit time_t transition for 32-bit archs: a proposal Holger Levsen <holger@layer-acht.org> - 2023-06-09 11:30 +0200
              Re: 64-bit time_t transition for 32-bit archs: a proposal Ansgar <ansgar@43-1.org> - 2023-06-09 11:40 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Bastian Blank <waldi@debian.org> - 2023-06-08 11:40 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-08 11:40 +0200
          Re: 64-bit time_t transition for 32-bit archs: a proposal Gunnar Wolf <gwolf@debian.org> - 2023-06-08 17:10 +0200
          Re: 64-bit time_t transition for 32-bit archs: a proposal nick black <dankamongmen@gmail.com> - 2023-06-09 01:30 +0200
            Re: multiarch vs. multilib Simon McVittie <smcv@debian.org> - 2023-06-09 11:00 +0200
              Re: multiarch vs. multilib nick black <dankamongmen@gmail.com> - 2023-06-11 10:00 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-09 05:20 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-09 11:30 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-09 06:30 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Bastian Blank <waldi@debian.org> - 2023-06-09 08:00 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Wookey <wookey@wookware.org> - 2023-07-05 18:30 +0200
    Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-06-06 21:50 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-07 06:40 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Helmut Grohne <helmut@subdivi.de> - 2023-06-08 19:20 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Holger Levsen <holger@layer-acht.org> - 2023-06-08 20:00 +0200
          Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-06-08 21:00 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Thorsten Glaser <tg@debian.org> - 2023-06-09 19:00 +0200
          Re: 64-bit time_t transition for 32-bit archs: a proposal Aurelien Jarno <aurel32@debian.org> - 2023-06-26 21:40 +0200
            Re: 64-bit time_t transition for 32-bit archs: a proposal James Addison <jay@jp-hosting.net> - 2023-06-27 10:20 +0200
          Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-07-06 11:40 +0200
            Re: 64-bit time_t transition for 32-bit archs: a proposal Thorsten Glaser <tg@debian.org> - 2023-07-06 18:50 +0200
              Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-07-06 23:40 +0200
                Re: 64-bit time_t transition for 32-bit archs: a proposal Thorsten Glaser <tg@debian.org> - 2023-07-07 01:40 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Sam Hartman <hartmans@debian.org> - 2023-07-06 22:50 +0200
    Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-07 06:40 +0200
      Re: 64-bit time_t transition for 32-bit archs: a proposal Sune Vuorela <nospam@vuorela.dk> - 2023-06-07 09:30 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal "Peter Van Eynde" <pvaneynd@debian.org> - 2023-06-07 10:30 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-07 12:50 +0200
        Re: 64-bit time_t transition for 32-bit archs: a proposal The Wanderer <wanderer@fastmail.fm> - 2023-06-07 13:10 +0200
          Re: 64-bit time_t transition for 32-bit archs: a proposal Thorsten Glaser <tg@debian.org> - 2023-07-06 19:00 +0200
            Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-07-06 19:20 +0200
        [i386] adlibtracker2 and fp-units-i386  Ivan Shmakov <ivan@siamics.net> - 2023-06-07 15:40 +0200
  Constructive contributions (was: Re: 64-bit time_t transition for  32-bit archs: a proposal) Jonathan Carter <jcc@debian.org> - 2023-06-09 13:30 +0200

csiph-web