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

Groups > linux.debian.devel > #107899 > unrolled thread

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

Started bySteve Langasek <vorlon@debian.org>
First post2023-05-17 06:20 +0200
Last post2023-06-09 13:30 +0200
Articles 20 on this page of 144 — 52 participants

Back to article view | Back to linux.debian.devel

Contents

  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

Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8  Next page →

#108133

FromSimon McVittie <smcv@debian.org>
Date2023-06-08 21:10 +0200
Message-ID<GEtbb-ezaY-7@gated-at.bofh.it>
In reply to#108106
On Tue, 06 Jun 2023 at 21:45:31 +0200, Alexis Murzeau wrote:
> On 06/06/2023 12:45, Simon McVittie wrote:
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> >     modern x86_64 systems
> >     2a. legacy native Linux i386 binaries
> >     2b. legacy Windows i386 binaries via Wine (which requires a somewhat
> >         complete i386 Linux library stack)
> > 
> 
> Windows already uses 64 bits time_t on i386 since Visual Studio 2005,
> unless _USE_32BIT_TIME_T is defined ([msvcrt-time]), and even if it is
> defined, Wine implementation of 32 bits time() will not use Linux' time_t.
> 
> So I'm not sure Windows i386 binaries will be affected by a Linux-side change of
> time_t, unless you think about something else.

If the point you're making is this:

We have source code for the whole Wine stack, and the size of Linux time_t
used to compile/implement that stack does not affect the time_t used for
the Windows-side ABI presented to the binaries Wine runs, therefore we
could recompile all of i386 (including Wine) with a 64-bit time_t and
still be able to run 32-bit Windows binaries

then, yes, that's all true, if we assume the whole of the stack
"underneath" Wine copes gracefully with 64-bit time_t on an otherwise
ILP32 ABI (I think implementation experience from x32 might indicate
otherwise, but that'll need to be solved for a 64-bit-time_t transition
in other ILP32 architectures like armhf anyway).

However, I would argue that providing i386 as a multiarch foreign
architecture that can run 32-bit Windows binaries via Wine (2b), but can
no longer safely run 32-bit Linux binaries (2a) because they're relatively
likely to crash, is less useful than being able to have both 2a and 2b.

Do we expect users of old 32-bit Linux binary-only software to always
obtain and run the corresponding Windows software instead, via Wine,
assuming it's available? I know people like to complain about Linux not
having stable ABIs and/or troll us with comparisons to things that Windows
does better, but it would seem like a shame if the solution for (for
example) players of TF2 and Portal is "stop running the Linux version,
start running the Windows version via Wine/Proton".

> This means that Wine will probably require 32 bits Linux libraries for
> probably a long time and not only for legacy Windows binaries.

I was assuming that 32-bit Windows binaries can be considered to be
inherently legacy software at this point, even if people are still
releasing them today :-)

    smcv

[toc] | [prev] | [next] | [standalone]

#108109

FromPaul Wise <pabs@debian.org>
Date2023-06-07 06:40 +0200
Message-ID<GDT7I-ecWP-3@gated-at.bofh.it>
In reply to#108098

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

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:

> When considering the future of i386, a factor that we need to bear in
> mind is that there are two major use-cases for i386, with requirements
> that sometimes conflict:

There was another option mentioned earlier in the thread that could
help resolve some aspects of these conflicts; make 32-bit arches
(or just i386) support both time_t ABIs, like glibc and Linux do.

The 64-bit time_t ABI would be the default but the 32-bit time_t ABI
would be present for running old binaries that still kind of work with
the 32-bit ABIs after 2038, or under faketime when they do not.

This would be more work for Debian and a lot more work for upstreams
but would be a better outcome for the diversity of uses for 32-bit.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#108119

FromAndreas Metzler <ametzler@bebt.de>
Date2023-06-08 07:10 +0200
Message-ID<GEg4h-erlS-1@gated-at.bofh.it>
In reply to#108109
On 2023-06-07 Paul Wise <pabs@debian.org> wrote:
[...]
> There was another option mentioned earlier in the thread that could
> help resolve some aspects of these conflicts; make 32-bit arches
> (or just i386) support both time_t ABIs, like glibc and Linux do.

> The 64-bit time_t ABI would be the default but the 32-bit time_t ABI
> would be present for running old binaries that still kind of work with
> the 32-bit ABIs after 2038, or under faketime when they do not.

> This would be more work for Debian and a lot more work for upstreams
> but would be a better outcome for the diversity of uses for 32-bit.

Hello,

I doubt it is a realistic option, though. This is a non-trivial change
and imho way over Debian's resources.

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'

[toc] | [prev] | [next] | [standalone]

#108134

FromSimon McVittie <smcv@debian.org>
Date2023-06-08 21:20 +0200
Message-ID<GEtkS-eze4-3@gated-at.bofh.it>
In reply to#108109
On Wed, 07 Jun 2023 at 12:25:58 +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> > When considering the future of i386, a factor that we need to bear in
> > mind is that there are two major use-cases for i386, with requirements
> > that sometimes conflict:
> 
> There was another option mentioned earlier in the thread that could
> help resolve some aspects of these conflicts; make 32-bit arches
> (or just i386) support both time_t ABIs, like glibc and Linux do.
> 
> The 64-bit time_t ABI would be the default but the 32-bit time_t ABI
> would be present for running old binaries that still kind of work with
> the 32-bit ABIs after 2038, or under faketime when they do not.

Showing my $WORK bias a bit here by using the latest version of the
Steam Runtime (based on Debian 11) as an example of a "reasonably small"
library stack for running 32-bit binaries:

$ podman pull registry.gitlab.steamos.cloud/steamrt/sniper/sdk
$ podman run --rm -it registry.gitlab.steamos.cloud/steamrt/sniper/sdk
$ grep -rl '\<time_t\>' /usr/include

I see that libX11, ALSA, libstdc++, libcups, GLib, GNUTLS, GTK 3, libelf,
libpng, libsoup, libllvm, NSPR and OpenSSL all have time_t in their
APIs. In most cases that's going to reflect it being in their ABIs too.

In many cases it's probably a deprecated library call
(like g_bookmark_file_set_app_info(), which takes a time_t argument,
and is deprecated in favour of g_bookmark_file_set_application_info()
which takes a GDateTime object) but one of the things about legacy
binaries is that they'll continue to call into old ABIs, however hard
you might try to deprecate them.

Doing similar searches for timeval and timespec (which contain a time_t)
finds more relatively low-level libraries with time_t-sensitive ABIs.

glibc supports both time_t sizes by using heroic efforts to do so,
and conditionally redefining various symbols. I'm not at all sure that
that scales beyond glibc, particularly for libraries like libX11 that
are already on life-support; and if we switch to 64-bit time_t *before*
giving all of those libraries similar elaborate symbol-renaming, then
it'll be too late, because their ABI will have already changed and it
would be equally disruptive to go back.

    smcv

[toc] | [prev] | [next] | [standalone]

#108120

FromPaul Wise <pabs@debian.org>
Date2023-06-08 07:40 +0200
Message-ID<GEgxj-ervP-1@gated-at.bofh.it>
In reply to#108098

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

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:

> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>    modern x86_64 systems
>    2a. legacy native Linux i386 binaries
>    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>        complete i386 Linux library stack)

Would it be feasible to drop i386 but still support this use-case by
requiring folks to use historical releases on archive.debian.org?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#108121

FromBastien ROUCARIES <roucaries.bastien@gmail.com>
Date2023-06-08 08:40 +0200
Message-ID<GEhtn-es4E-1@gated-at.bofh.it>
In reply to#108120
Le jeu. 8 juin 2023 à 05:31, Paul Wise <pabs@debian.org> a écrit :
>
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
>
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> >    modern x86_64 systems
> >    2a. legacy native Linux i386 binaries
> >    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
> >        complete i386 Linux library stack)
>
> Would it be feasible to drop i386 but still support this use-case by
> requiring folks to use historical releases on archive.debian.org?

In some countries wine (32 bits) is the only solution to run software
as a citizen needed for relation to some state administration...

Regards
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#108122

FromHakan Bayındır <hakan@bayindir.org>
Date2023-06-08 10:50 +0200
Message-ID<GEjvb-etdy-7@gated-at.bofh.it>
In reply to#108120

> On 8 Jun 2023, at 06:19, Paul Wise <pabs@debian.org> wrote:
> 
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> 
>> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>>    modern x86_64 systems
>>    2a. legacy native Linux i386 binaries
>>    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>>        complete i386 Linux library stack)
> 
> Would it be feasible to drop i386 but still support this use-case by
> requiring folks to use historical releases on archive.debian.org?

Wouldn’t this make installation of i386 packages harder and harder as packages diverge from the dependencies stated in the historical packages? This will defeat the very purpose of having i386 as an installable compatibility layer in my opinion.

Cheers,

H.

> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#108124

FromHolger Levsen <holger@layer-acht.org>
Date2023-06-08 11:00 +0200
Message-ID<GEjER-etgH-9@gated-at.bofh.it>
In reply to#108120

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

On Thu, Jun 08, 2023 at 11:19:15AM +0800, Paul Wise wrote:
> Would it be feasible to drop i386 but still support this use-case by
> requiring folks to use historical releases on archive.debian.org?

You mean by somehow refreshing the signatures there?

Would IMO also be useful for other archs. :)


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"Climate change" is an euphenism. "Global warming" as well.

[toc] | [prev] | [next] | [standalone]

#108138

FromPaul Wise <pabs@debian.org>
Date2023-06-09 06:00 +0200
Message-ID<GEBs5-eEan-3@gated-at.bofh.it>
In reply to#108124

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

On Thu, 2023-06-08 at 08:57 +0000, Holger Levsen wrote:

> You mean by somehow refreshing the signatures there?

Some ideas for that are here:

https://bugs.debian.org/763419
https://bugs.debian.org/820423

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#108146

FromHolger Levsen <holger@layer-acht.org>
Date2023-06-09 11:30 +0200
Message-ID<GEGBr-eHGz-5@gated-at.bofh.it>
In reply to#108138

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

On Fri, Jun 09, 2023 at 11:49:21AM +0800, Paul Wise wrote:
> > You mean by somehow refreshing the signatures there?
> Some ideas for that are here:
> https://bugs.debian.org/763419
> https://bugs.debian.org/820423

interesting. thanks for those pointers!


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

https://showyourstripes.info

[toc] | [prev] | [next] | [standalone]

#108147

FromAnsgar <ansgar@43-1.org>
Date2023-06-09 11:40 +0200
Message-ID<GEGL7-eHJH-5@gated-at.bofh.it>
In reply to#108146
On Fri, 2023-06-09 at 09:22 +0000, Holger Levsen wrote:
> On Fri, Jun 09, 2023 at 11:49:21AM +0800, Paul Wise wrote:
> > > You mean by somehow refreshing the signatures there?
> > Some ideas for that are here:
> > https://bugs.debian.org/763419
> > https://bugs.debian.org/820423
> 
> interesting. thanks for those pointers!

I did write a prototype once, but haven't touched it for some time. For
example:

https://defi.43-1.org/debian-defi-archive/debian/dists/stretch-backports/InRelease

(It should also work for other things.)

The test key is available from
https://defi.43-1.org/defibrillator-test-key.asc

Ansgar

[toc] | [prev] | [next] | [standalone]

#108125

FromBastian Blank <waldi@debian.org>
Date2023-06-08 11:40 +0200
Message-ID<GEkhz-etIm-3@gated-at.bofh.it>
In reply to#108120
On Thu, Jun 08, 2023 at 11:19:15AM +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> >    modern x86_64 systems
> >    2a. legacy native Linux i386 binaries
> >    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
> >        complete i386 Linux library stack)
> Would it be feasible to drop i386 but still support this use-case by
> requiring folks to use historical releases on archive.debian.org?

No.  One package for different architectures is only co-installable if
they have the same version.

Bastian

-- 
Conquest is easy. Control is not.
		-- Kirk, "Mirror, Mirror", stardate unknown

[toc] | [prev] | [next] | [standalone]

#108126

FromSimon McVittie <smcv@debian.org>
Date2023-06-08 11:40 +0200
Message-ID<GEkhz-etIm-7@gated-at.bofh.it>
In reply to#108120
On Thu, 08 Jun 2023 at 11:19:15 +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> 
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> >    modern x86_64 systems
> >    2a. legacy native Linux i386 binaries
> >    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
> >        complete i386 Linux library stack)
> 
> Would it be feasible to drop i386 but still support this use-case by
> requiring folks to use historical releases on archive.debian.org?

Not really, for two reasons. Suppose we had done as you suggest in trixie,
and then a user in 2030 tries to run legacy binaries.

- Multiarch co-installability requires a matching version, so you can't
  co-install libc6:amd64 from 2030 with libc6:i386 from 2023. That would
  mean requiring use of a pure i386 chroot/container to run i386 binaries,
  which doesn't really work well for something like Steam or Wine that
  wants to provide a mixed x86_64/i386 environment that can run x86_64
  or i386 binaries interchangeably. Steam has both x86_64 and i386 games
  available (most of which will never be recompiled or updated by their
  developers), and Wine wants to provide an environment compatible
  with modern Windows, which is essentially the same shape as amd64
  Debian in terms of architecture support: it's an x86_64 OS (kernel,
  services and core libraries) with a secondary i386 library stack
  ("WoW64" in Windows' case).

  Debian-style multiarch or Fedora/Arch-style multilib is a much, much
  more convenient way to handle legacy i386 binaries than a chroot or
  container - there's a reason that essentially all distros supporting
  x86_64 have one or the other of those.

  Even if you use a container framework like Flatpak to run Steam,
  it isn't an i386 container - in Debian terminology, it's an x86_64
  container with i386 as a foreign architecture (and in fact the fd.o
  Flatpak runtimes use Debian-style multiarch paths for this).

- For game-related use cases in particular, 2030 GPU models aren't going
  to work with 2023 user-space graphics drivers (typically Mesa or
  NVIDIA-proprietary) because the 2030 GPU didn't exist yet at the time
  the 2023 driver was written, so if we don't compile a modern Mesa
  for i386, all i386 programs will eventually lose the ability to do
  accelerated graphics and end up using the 2023 version of llvmpipe.

    smcv

[toc] | [prev] | [next] | [standalone]

#108129

FromGunnar Wolf <gwolf@debian.org>
Date2023-06-08 17:10 +0200
Message-ID<GEpqV-ewUU-5@gated-at.bofh.it>
In reply to#108126
Simon McVittie dijo [Thu, Jun 08, 2023 at 10:33:45AM +0100]:
> - For game-related use cases in particular, 2030 GPU models aren't going
>   to work with 2023 user-space graphics drivers (typically Mesa or
>   NVIDIA-proprietary) because the 2030 GPU didn't exist yet at the time
>   the 2023 driver was written, so if we don't compile a modern Mesa
>   for i386, all i386 programs will eventually lose the ability to do
>   accelerated graphics and end up using the 2023 version of llvmpipe.

This makes the case for an ideal GPU paravirtualized implementation!

(yes, yes, I know it's not doable... Just had to say it!)

[toc] | [prev] | [next] | [standalone]

#108135

Fromnick black <dankamongmen@gmail.com>
Date2023-06-09 01:30 +0200
Message-ID<GExeN-eBvP-1@gated-at.bofh.it>
In reply to#108126

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

Simon McVittie left as an exercise for the reader:
>   Debian-style multiarch or Fedora/Arch-style multilib is a much, much

this is at least the second time you've drawn this distinction
in this thread. for anyone else who, like me, was uneasy with
their understanding of the concept:

https://wiki.debian.org/ToolChain/Cross#Multiarch_vs_Multilib

seems to be a solid resource (and sadly low on my google
returns).

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.

[toc] | [prev] | [next] | [standalone]

#108144 — Re: multiarch vs. multilib

FromSimon McVittie <smcv@debian.org>
Date2023-06-09 11:00 +0200
SubjectRe: multiarch vs. multilib
Message-ID<GEG8p-eHhg-5@gated-at.bofh.it>
In reply to#108135
On Thu, 08 Jun 2023 at 19:22:02 -0400, nick black wrote:
> Simon McVittie left as an exercise for the reader:
> >   Debian-style multiarch or Fedora/Arch-style multilib is a much, much
> 
> this is at least the second time you've drawn this distinction
> in this thread. for anyone else who, like me, was uneasy with
> their understanding of the concept

Sorry, I spend a lot of my work time immersed in this sort of thing and
how it differs between distributions, so I tend to forget that most
developers are able to stick to one distro and don't need to know this!

I think this is important background knowledge for anyone who wants to
change how we handle architectures that are generally used as a foreign
architecture, particularly i386.

> https://wiki.debian.org/ToolChain/Cross#Multiarch_vs_Multilib

That's talking about the different gcc toolchains, but I actually meant
the difference in how libraries are packaged, which is a slightly separate
concept but tends to go together.

Readers of this thread are hopefully all familiar with Debian
multiarch, where the linker (both runtime and compile-time) searches
/{usr/,}lib/x86_64-linux-gnu, /{usr/,}lib/i386-linux-gnu or equivalent
non-x86 paths, as appropriate for the architecture, and we install shared
libraries to those paths. The dynamic string token ${LIB} (see ld.so(8))
expands to lib/x86_64-linux-gnu or similar.

Fedora and its relatives (RHEL, CentOS and so on) use the directory
layout described by LSB/FHS, in which i386 libraries are installed into
/usr/lib and x86_64 libraries into /usr/lib64 (a "libQUAL" directory
using FHS terminology), and the runtime and compile-time linkers search
those paths as appropriate for the architecture. They install most
libraries for x86_64 only, from packages like glib2-*.x86_64.rpm, into
/usr/lib64. A subset of libraries (enough to support Wine and legacy i386
binaries) are also available for i386, from packages lke glib2-*.i686.rpm,
into /usr/lib. The dynamic string token ${LIB} expands to lib64 or lib
as appropriate.

Arch Linux and its relatives (Manjaro and so on) use the reverse of
Fedora's layout: they mostly install x86_64 libraries from packages like
glib2-*-x86_64.pkg.tar.zst into /usr/lib, and a subset of libraries are
also available for i386, from packages like lib32-glib2-*-x86_64.pkg.tar.zst,
installing into /usr/lib32. ${LIB} expands to lib or lib32 as appropriate.

Other distributions *usually* match one of those families (often the same
as Fedora, for example openSUSE and Gentoo seem to match that), but there
are exceptions, like Exherbo which sets the ${prefix} to /usr/GNU_TUPLE for
each architecture, resulting in libraries in /usr/GNU_TUPLE/lib.

Debian *mostly* uses multiarch, but we still have a small subset of
packages that install a library of a different architecture to the libQUAL
directories, for use with multilib compilers. On x86_64 they're named like
lib32stdc++6_*_amd64.deb and follow the Arch-like directory layout with a
lib32 directory, while on i386 they're named like lib64stdc++6_*_i386.deb
and follow the Fedora-like layout with a lib64 directory.

    smcv

[toc] | [prev] | [next] | [standalone]

#108180 — Re: multiarch vs. multilib

Fromnick black <dankamongmen@gmail.com>
Date2023-06-11 10:00 +0200
SubjectRe: multiarch vs. multilib
Message-ID<GFo9s-f871-3@gated-at.bofh.it>
In reply to#108144

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

Simon McVittie left as an exercise for the reader:
> Sorry, I spend a lot of my work time immersed in this sort of thing and
> how it differs between distributions, so I tend to forget that most
> developers are able to stick to one distro and don't need to know this!

no offense at all, and thanks tremendously for the detailed
explanation! i've learned a lot in this thread.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.

[toc] | [prev] | [next] | [standalone]

#108137

FromPaul Wise <pabs@debian.org>
Date2023-06-09 05:20 +0200
Message-ID<GEAPn-eDVJ-1@gated-at.bofh.it>
In reply to#108098

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

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:

> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>    modern x86_64 systems

Are these use-cases likely to work with future library ABIs, or
do they need old library ABIs from when the binaries were compiled?

>    2a. legacy native Linux i386 binaries

It seems like modern Debian library ABIs will be bumped away from what
the old i386 binaries were built against, so future Debian i386 won't
be useful for this use-case anyway, except for very stable libraries,
symbol versioned libraries or libraries with multiple ABIs. That sounds
like glibc, X11 and SDL with compat libs. Anything else?

>    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>        complete i386 Linux library stack)

I guess Wine provides a translation layer between legacy 32-bit Windows
APIs/ABIs and modern Debian library ABIs, so this should still work?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#108145

FromSimon McVittie <smcv@debian.org>
Date2023-06-09 11:30 +0200
Message-ID<GEGBr-eHGz-3@gated-at.bofh.it>
In reply to#108137
On Fri, 09 Jun 2023 at 11:04:47 +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> 
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> >    modern x86_64 systems
> 
> Are these use-cases likely to work with future library ABIs, or
> do they need old library ABIs from when the binaries were compiled?

I'm not sure how this could be in question? They're legacy binaries,
so almost by definition, legacy ABIs.

> >    2a. legacy native Linux i386 binaries
> 
> It seems like modern Debian library ABIs will be bumped away from what
> the old i386 binaries were built against, so future Debian i386 won't
> be useful for this use-case anyway, except for very stable libraries,
> symbol versioned libraries or libraries with multiple ABIs. That sounds
> like glibc, X11 and SDL with compat libs. Anything else?

When you say "ABIs will be bumped", do you mean SONAME transitions like
libtiff.so.4 -> .5 -> .6?

Those don't have to prevent running legacy binaries if we don't want them
to, because the whole point of SONAMEs is that different versions of the
same library are co-installable: if you have a legacy binary linked to
libtiff4, you can still run it on a system that normally uses libtiff6
by keeping a copy of libtiff4 from an old Debian suite (I know it's in
Ubuntu 12.04, but I've lost track of how old you would need to go in
Debian-world to get it).

This will generally work fine as long as the legacy binary doesn't
also link to a higher-level library that depends on a modern version of
libtiff, like for example libsdl-image1.2 or libsdl2-image-2.0-0. Even if
the legacy binary *does* link to such a library, then it might still work,
if both the old and new versions of libtiff have ELF symbol versioning
(libtiff6 does, I think libtiff4 also did) and the higher-level library
doesn't expose libtiff objects through its own ABI (SDL_image doesn't).

If the legacy binary mostly calls into higher-level "middleware" libraries
like SDL_image, then it is quite likely that it doesn't actually directly
reference any symbols from a lower-level library like libtiff, and the
lower-level libraries tend to be the ones that break ABI most often.

>From my experience in dealing with the Steam Runtime, I can tell you that
surprisingly many of the libraries linked by legacy binaries still have
an ABI that is backwards-compatible with versions of the same library from
more than 10 years ago. For example, PulseAudio never bumped SONAME; GLib,
libdrm and fontconfig had some SONAME bumps in their early history but
are long-term-backwards-compatible now; and libjpeg bumped SONAME somewhat
recently, but Debian is using the maximally-backwards-compatible ABI.

I can't tell you a comprehensive list of libraries used by legacy binaries,
but if someone wants to audit all the "commonly used" libraries for whether
64-bit time_t breaks their ABIs, the Steam Runtime is probably quite a good
approximation of what is "commonly used":
https://repo.steampowered.com/steamrt-images-sniper/snapshots/latest-container-runtime-public-beta/com.valvesoftware.SteamRuntime.Platform-amd64%2Ci386-sniper.source-required.txt

I must admit that I stopped looking when I saw that libX11 and libasound
have time_t in their ABI, because those are both going to be extremely
common dependencies, and I am not optimistic about the prospects of
getting glibc-style parallel ABIs into libX11.

    smcv

[toc] | [prev] | [next] | [standalone]

#108139

FromPaul Wise <pabs@debian.org>
Date2023-06-09 06:30 +0200
Message-ID<GEBV7-eEJr-1@gated-at.bofh.it>
In reply to#108098

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

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:

> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>    modern x86_64 systems
>    2a. legacy native Linux i386 binaries
>    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>        complete i386 Linux library stack)

Has anyone checked what percentage of these binaries will still run
adequately after 2038 with 32-bit time_t?

Presumably any network components will be dead or require modern
protocols by then, so this could only be offline programs?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8  Next page →

Back to top | Article view | linux.debian.devel

csiph-web