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

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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8  Next page →

#108140

On Fri, Jun 09, 2023 at 12:25:21PM +0800, Paul Wise wrote:
> Has anyone checked what percentage of these binaries will still run
> adequately after 2038 with 32-bit time_t?

All, because you don't need to provide those programs with a correct
time.  But this is all a positive decisions.

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

What difference does this make?

Bastian

-- 
He's dead, Jim.
		-- McCoy, "The Devil in the Dark", stardate 3196.1

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

#108509

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

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

I missed most of this conversation due to being on holiday, so just catching up now.

I hesitate to continue the i386-distraction thread because what's
actually important is getting this transition underway on the other
arches, particularly arm32 (hf/el). But at least one aspect seems to
have been missed in the discussion so I thought I should point this
out (and we can't easily move forward without a plan for i386 as dpkg
defaults affect all arches unless we make explicit excetions).

> 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:
> 
> 1. i386 as a fully-featured architecture that you can run independently
>    on 32-bit x86 systems from roughly the 2000-2010 era
> 
> 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)

It is possible to have both these things, by treating this transtion
as a new-ABI (i.e new architecture) transition, not a within-arch ABI transition.

i.e we could keep the existing i386 for the gamers and have i386t64
(or whatever we call it) for ongoing use of i386 as a real OS.

This seems to me the 'right' way to deal with this 'the two possible
i386 ABIs are different but both useful in different ways'. 

That way we don't have to choose one or the other and everyone could be happy.

If we do that for other arches too then it greatly simplifies the
transition because we don't have to do a library transition at all. And
bootstrapping an arch is dramatically easier than it used to be thanks
to rebootstrap.

However there are major disadvantages too.

We'd end up quite a few new arches for at least one release, and we'd
spoil the upgrade path for people who would like their existing arch
to just move with the times. We'd have to think up and agree new
triplets and get them into toolchains, and fix architecture exceptions
in packaging.

There is no appetite for this (new triplet) work outside debian, but
if we do it right people will probably agree/follow (because it is
technically correct).

My assessment is that this is just as much work as doing the
transition in-arch, and will probably take longer due to the external
co-ordination needed.

Given all that I don't think the option of 'new arch for everyone' makes much sense.

Which gets us back to 'new arch for i386, other arches do in-arch
transition'. So we still get to do the library transition anyway.

But we _could_ also make a new i386t64 arch to enable i386-the-real-OS
a post 2038 future.  Does anyone care enough about that to do the
work?  If so I think we should let them.  This is the only i386
use-case I care about, but in practice I'm only going to care about it
for a few more years which will be served by the current releases so I
don't think I'm going to bother bootstrapping the new version. Happy
to help others though. 

Just thought this was worth bringing up because whilst the existing
'i386' arch has to choose one ABI or another, nothing stops us from
having both variants in the archive if we want them enough.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

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

#108105

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

Hi Helmut,

On Tue, Jun 06, 2023 at 09:33:22AM +0200, Helmut Grohne wrote:
> On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote:
> > * … 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.

> I've been reading the discussion around i386 a bit and found the
> direction it has taken a little unproductive. I hope we can agree that
> there is no consensus on keeping or changing the time ABI for i386 while
> there is quite some consensus for your plan on changing the time ABI for
> all other 32bit architectures in roughly the way you brought forward.

I have a different read on the consensus here.  While there has been a lot
of discussion about whether to continue supporting i386 as a host arch,
almost everyone participating in the thread who said they want this is not a
voting member of Debian.  The lone exception that I can recall from the
thread was Guillem, who, as dpkg maintainer, is certainly a stakeholder in
this decision (and since we don't really have an "i386 porting team",
probably the most important individual stakeholder).

Since my read is that Guillem was in the "rough" of "rough consensus", I
asked him directly how we should move forward on a decision.  A GR is one
option, and I think it's definitely a better option than going through the
TC: while there is a decision to be made here about a "technical" detail of
what dpkg-buildflags will do, you're right to point out that it's really a
decision about what we want to support as a project.

> While the i386 discussion seemed a little unproductive at times, I think
> there is one major argument that I feel is missing here. If keeping the
> 32bit time ABI for i386, that effectively becomes a divergence from
> every other architecture. i386 will be the one and only architecture to
> be time32. As it happens, I have some experience with such divergence
> from how bootstrapping interacted with other transitions such as PIE.
> Maintaining this kind of divergence has a non-trivial cost. Over time it
> becomes more and more difficult and less and less people are interested
> in doing it. As such, I see the addition of this kind of divergence as a
> way of killing i386.

Hmm, I don't share this particular concern.  PIE is a change to compiler
behavior.  32-bit time_t is a change to defines that modify types (and
prototypes) used in header files.  Maintaining a compiler is hard,
maintaining a library ABI is "easy" - glibc has avoided breaking ABI for 25
years so far.

> Judging from the conversation, killing i386 quite obviously is desired
> by some participants, but evidently not by all. How quickly we want to
> kill it is not obvious to me. However, I think it is fair to say that
> keeping time32 on i386 will kill it rather sooner than later. With
> time32, we cannot reasonably extend i386 beyond forky as we'd be running
> too close to the final deadline.

As a reliable host OS, sure.  As a compatibility layer, as Simon has pointed
out, having a wrong idea of the time is not a big deal for a lot of
applications.

> Some of you may have been aware of that Debian Reunion in Hamburg
> recently. There was a BoF on how Debian should decide about non-trivial
> matters and one result of that BoF was "maybe we should GR more often".
> I think the decision of what to do with time32 is not a really important
> one despite some people being very opinionated about it. How about
> settling it using a GR anyway? We perceive GRs as painful and there is a
> saying that if something is difficult, let's do it more often. How about
> trying to do GRs more often with this decision? I think it is pretty
> clear that neither answer is wrong. It's a choice that we have make and
> then to stick to. And we can learn something about whether GRs really
> are painful. I think the worst of outcomes we could get here is going
> into much further detail in a GR and adding lots of competing proposals
> there. If that were to happen, I'd consider the experiment as failed.
> Leaving the details to those who put up with the work (and that quite
> obviously is Steve et al here) is important in my book. So unless we can
> do it as simple as "i386 should keep being time32" vs "i386 should
> become time64 by default", we probably shouldn't GR it.

I am not keen to try to drive a GR on this, but if you raised one I'm likely
to second it.

-- 
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

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

#108108

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

On Tue, 2023-06-06 at 12:45 -0700, Steve Langasek wrote:

> since we don't really have an "i386 porting team"

The release team have registered Adrian Bunk as an i386 porter:

https://release.debian.org/testing/arch_spec.yaml

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

#108130

Hi Steve,

On Tue, Jun 06, 2023 at 12:45:42PM -0700, Steve Langasek wrote:
> I have a different read on the consensus here.  While there has been a lot
> of discussion about whether to continue supporting i386 as a host arch,
> almost everyone participating in the thread who said they want this is not a
> voting member of Debian.  The lone exception that I can recall from the
> thread was Guillem, who, as dpkg maintainer, is certainly a stakeholder in
> this decision (and since we don't really have an "i386 porting team",
> probably the most important individual stakeholder).

I concur. Given Simon's analysis and the replies even when combined with
earlier messages, I now see significantly more voices for the opinion:

    i386 primarily exists for running legacy binaries and binary
    compatibility with legacy executables is more important than correct
    representation of time beyond 2038.

I'm inclined to call this consensus now and therefore ask those that do
not agree with it to reply here - even if your reply is only stating
that you disagree. As such, I think we can skip the GR part unless we
get (5?) disagreeing replies here.

Guillem, I understand that you see things differently, but that now
seems like a minority opinion to me. Are you ok with moving forward with
the proposed consensus-or-GR process? My understanding is that you
disagree with the opinion stated above, correct?

While Gunar also raises the question of whether i386 should continue as
a full or partial architecture, I do not think this is influences the
time_t bits decision. The default for now is keeping it as a full
architecture and the time_t migration does not benefit from changing
this. Therefore, I propose restricting the potential GR to the binary
way that Simon presented.

> Since my read is that Guillem was in the "rough" of "rough consensus", I
> asked him directly how we should move forward on a decision.  A GR is one
> option, and I think it's definitely a better option than going through the
> TC: while there is a decision to be made here about a "technical" detail of
> what dpkg-buildflags will do, you're right to point out that it's really a
> decision about what we want to support as a project.

Yes, dragging this question on is - as usual - the worst of options.

> Hmm, I don't share this particular concern.  PIE is a change to compiler
> behavior.  32-bit time_t is a change to defines that modify types (and
> prototypes) used in header files.  Maintaining a compiler is hard,
> maintaining a library ABI is "easy" - glibc has avoided breaking ABI for 25
> years so far.

The similarity is that both is changing flags. I expect that some
packages will need special handling for time64 and some of them may fail
to handle i386 correctly when they only match on bits. If we can get
maintainers to match on the resulting dpkg-buildflags rather than bits,
that's a non-issue probably.

> I am not keen to try to drive a GR on this, but if you raised one I'm likely
> to second it.

Cool. From my point of view consensus is better than GR is better than
deferring or invoking the CTTE. Hope consensus works out. :)

Helmut

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

#108131

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

On Thu, Jun 08, 2023 at 07:14:17PM +0200, Helmut Grohne wrote:
> I concur. Given Simon's analysis and the replies even when combined with
> earlier messages, I now see significantly more voices for the opinion:
> 
>     i386 primarily exists for running legacy binaries and binary
>     compatibility with legacy executables is more important than correct
>     representation of time beyond 2038.

I agree. (And personally I don't care about i386 at all. I'm happy if
we support i386 usecases if this seems reasonable for all involved.)
 
> I'm inclined to call this consensus now [...]

I'm inclined to call this consensus of the few people who participated
(activly or passivly) in this short & short-lived thread, but I'm not
sure we can call this project wide consensus *yet*.

RFC on d-d-a? That's at least less heavy than a GR and yet way more
visible than just a thread on d-d.


-- 
cheers,
	Holger

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

Just because other people are also responsible, does not mean you are not
responsible.

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

#108132

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

On Thu, Jun 08, 2023 at 05:57:49PM +0000, Holger Levsen wrote:
> RFC on d-d-a? That's at least less heavy than a GR and yet way more
> visible than just a thread on d-d.

The problem with doing an RFC on d-d-a is that it doesn't give us a clear,
timeboxed path to converging on a decision if we find that there isn't
consensus.  If we need more assurance that the project supports the
decision, I think it's better to go straight for a GR.

I wouldn't like this to drag on too long into the trixie release cycle.

-- 
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

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

#108162

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA384

Helmut Grohne dixit:

>I'm inclined to call this consensus now and therefore ask those that do
>not agree with it to reply here - even if your reply is only stating

I disagree.

I would like to see a long-term commitment against electronic waste
and to see support for i386 as a second-class but fully supported
platform, with 64-bit time_t and off_t, d-i, kernel and everything.

In particular I would, at the same time, like the baseline lowered
to i586 again. It was raised mostly for multimedia stuff, and it’s
now justifyable to ask people to use amd64 or armhf or something for
that.

Besides being a fully supported bootable platform for old but still
serviceable hardware the M-A support is also worthwhile. I run the
i386 version of firefox-esr on some systems to naturally limit its
resource usage, for example.

Ideally we’d keep the old i386 around for legacy binary-only libraries
and executables and add an i586 architecture with a differing dynamic
linker path; all solibs would be in the M-A-qualified path anyway. Maybe
we could even use one of the various existing ELF header fields to
distinguish them for the kernel, if needed.

I’m mildly willing to help out as part of a porter team, but not be the
only porter. I do have an affected system (EeePC, though I need to
do some hardware maintenance (HDD swap etc.) first) which I occasionally
use. That being said I’ve reduced my involvement in bookworm/sid due to
the systemdification, so I would prefer to not be the primarily respon‐
sible developer.

bye,
//mirabilos
- -- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
	-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (MirBSD)
Comment: ☃ ЦΤℱ—８　☕☂☄

iQIcBAEBCQAGBQJkg1XOAAoJEHa1NLLpkAfgTvYP/ie/yyFeDYQTGJjKdjYoFThr
ckaL1VYC2C1pBQLFbcdeRG2Zy2VyQQzJQnFxfBey4PKJAvvY78VyI/1Kn4eGXWKE
7KNPB11tm5IZaQa/fIUpWDTruzkFydkuYAjT72qiHqkBphF32YbiNSLeQEf8pEfJ
bbk2Z1awKM5wm6dw0iXEn+IV2YDXzPt2Mb0HgLu08b2MjyFI6pou6UjLmriqeKd6
qpiTH1XzKGkOrRh00LRGEg4GuRpjboaxtaJoTykEj+42xxyy21yzrxigrpxc7fpl
7gkCfpBvf8XFORHsZuLA/ZoepKpII4BIP8qgwip3D8sy9kyJRlFpN87KGJhMiTMz
2cPtXHtwYkMMRjMcOJazaGXm3QgzOKF1cNBaQFer/N74X9P8k5ax4e9B6plrsDdX
eI62d8U2D9IUSHE3S+OWRIqXhb/2RJ+DcCca182344PyDKz+j0x3RLwXcAPTGTZS
Dxf7LSSZ4nOFUAW31ZNbeByjM40RXlzGbQu63Bps1Vwzy3N+xMNfj0fd3XEx+rDd
edDYXHe2gt5lQJuG6n6REs/DdoBD1724IOIAm0j4IF4UDPuhpILN9RSmvSECDDnP
+aPQ+P8YkKOP3NeVnE/Jd7pbqvt0vvYjXUhuXEMf2I2UT2KG1j0tonv/5G8W4ui0
+ZX+kIdFDYBmx2opmp/Z
=lfL0
-----END PGP SIGNATURE-----

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

#108362

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

On 2023-06-09 16:39, Thorsten Glaser wrote:
> In particular I would, at the same time, like the baseline lowered
> to i586 again. It was raised mostly for multimedia stuff, and it’s
> now justifyable to ask people to use amd64 or armhf or something for
> that.

This is plainly wrong. The current baseline of the i386 architecture
does NOT include any multimedia extension, and certainly not MMX nor
SSE.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net

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

#108369

On Mon, 26 Jun 2023 at 20:33, Aurelien Jarno <aurel32@debian.org> wrote:
>
> On 2023-06-09 16:39, Thorsten Glaser wrote:
> > In particular I would, at the same time, like the baseline lowered
> > to i586 again. It was raised mostly for multimedia stuff, and it’s
> > now justifyable to ask people to use amd64 or armhf or something for
> > that.
>
> This is plainly wrong. The current baseline of the i386 architecture
> does NOT include any multimedia extension, and certainly not MMX nor
> SSE.
>
> --
> Aurelien Jarno                          GPG: 4096R/1DDD8C9B
> aurelien@aurel32.net                     http://aurel32.net

I agree with Aurelien on this.

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

#108526

On Wed, 05 Jul 2023 at 17:22:14 +0100, Wookey wrote:
> On 2023-06-06 11:45 +0100, Simon McVittie wrote:
> > 1. i386 as a fully-featured architecture that you can run independently
> >    on 32-bit x86 systems from roughly the 2000-2010 era
> > 
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> >    modern x86_64 systems
>
> It is possible to have both these things, by treating this transtion
> as a new-ABI (i.e new architecture) transition, not a within-arch ABI transition.
> 
> i.e we could keep the existing i386 for the gamers and have i386t64
> (or whatever we call it) for ongoing use of i386 as a real OS.

On Fri, 09 Jun 2023 at 16:39:38 +0000, Thorsten Glaser wrote:
> Ideally we’d keep the old i386 around for legacy binary-only libraries
> and executables and add an i586 architecture with a differing dynamic
> linker path

These are essentially the same suggestion, and if there are enough
developers interested in the use-case that I labelled (1.) above, then
I agree that i386t64 (or i586t64 or ia32 or whatever its newly-formed
porting team wants to call it) would be the way to achieve that.

Because legacy binaries already "know" that the backwards-compatible
architecture is labelled i386 and i?86-linux-gnu with its dynamic linker
at /lib/ld-linux.so.2, and by definition legacy binaries don't have
the opportunity to to change their assumptions, I think the new time64
architecture would need to have a new dpkg architecture name, multiarch
tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path.

If the new architecture is fully co-installable and distinguishable via
ELF flags (like the way amd64, i386 and x32 are), then the procedure to
switch to it could be similar to switching from i386 to amd64, or armhf to
arm64: either reinstall, or add it as a foreign architecture and gradually
"crossgrade" core system packages to it. If it isn't distinguishable by
ELF flags (so the dynamic linker would attempt to load i386t64 libraries
into an i386 process or vice versa, and sometimes crash as a result)
then a reinstall would be required.

I am personally only interested in i386 for the use-case that I labelled
(2.) above, but I don't want to prevent anyone else from working on (1.).

(It's perhaps also worth noting that it's possible to upgrade from
i386 to amd64 without a net increase in e-waste by switching from i386
hardware to older amd64 hardware that has already been discarded by its
original owner: I'm typing this into a second-hand ex-corporate Lenovo
T480s, built in 2018 according to its serial number label, and the X220
that was previously very popular with DDs was a UEFI-capable amd64 from
around 2012.)

    smcv

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

#108527

Simon McVittie dixit:

>On Wed, 05 Jul 2023 at 17:22:14 +0100, Wookey wrote:
[…]
>> i.e we could keep the existing i386 for the gamers and have i386t64
>> (or whatever we call it) for ongoing use of i386 as a real OS.
>
>On Fri, 09 Jun 2023 at 16:39:38 +0000, Thorsten Glaser wrote:
>> Ideally we’d keep the old i386 around for legacy binary-only libraries
>> and executables and add an i586 architecture with a differing dynamic
>> linker path
>
>These are essentially the same suggestion, and if there are enough

Right. However, my suggestion involves *reducing* the architecture
baseline again to make it accessible to more real-existing systems.
But that’s orthogonal from the rest. (In fact, we might even want
to do that for both.)

>Because legacy binaries already "know" that the backwards-compatible
>architecture is labelled i386 and i?86-linux-gnu with its dynamic linker

Oh, i?86-linux-gnu is a good point I had not considered.

>architecture would need to have a new dpkg architecture name, multiarch
>tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path.

Definitely (and let’s just use the multiarch path for the ELF linker).

Bit of bikeshedding on the name, of course. timet64 (or a shortened
version) is a possibility but I’d also want off_t to be 64 bit in it
like the BSDs have been doing for decades, for example. Ideas welcome,
but it’s not important upfront.

>If the new architecture is fully co-installable and distinguishable via
>ELF flags (like the way amd64, i386 and x32 are), then the procedure to

It will unfortunately have to be more than just how these three differ.

i386 is ELF32 (ELFCLASS32) with e_machine EM_386 and ELFOSABI_LINUX
or possibly ELFOSABI_NONE(?).

amd64 is ELF64 (ELFCLASS64) with e_machine EM_X86_64.

x32 is ELF32 (ELFCLASS32) with e_machine EM_X86_64.

The new architecture would also have to be ELFCLASS32 and EM_386.
Maybe we can distinguish them using e_flags… using a new EI_OSABI
or, worse, e_machine sounds bad.

How do we distinguish arm, armel and armhf? They all use EM_ARM
probably (armeb is probably distinguished via ELFDATA2MSB).

>"crossgrade" core system packages to it. If it isn't distinguishable by
>ELF flags (so the dynamic linker would attempt to load i386t64 libraries
>into an i386 process or vice versa, and sometimes crash as a result)

I would like for things to be coïnstallable, of course. But why would
the dynamic linker attempt to load the respective foreign libraries…
oh right, not all are in the M-A path yet (on my box, they are, but
legacy i386 systems would not have that).

So we need a way to distinguish them in the ELF header and possibly
also patch the i386 loader to check the new bit? field? note? and
not load the solib if set.

We’ll also need a cpp define, like we have…

#if defined(__amd64__) && defined(__ILP32__)
// x32
#if defined(__amd64__) && !defined(__ILP32__)
// amd64

… and 「echo | gcc -m32 -E -dD - | less」 does not yet have anything
suitable. Either patch it into gcc… (I’ve patched gcc/config/**.h
files before) or… apparently, /usr/include/stdc-predef.h is included
by recent GCC, if that were in the M-A path it might work.

Is there any cross-distro effort for such a thing that we’d need to
coordinate with?

>(It's perhaps also worth noting that it's possible to upgrade from
>i386 to amd64 without a net increase in e-waste by switching from i386
>hardware to older amd64 hardware that has already been discarded by its
>original owner: I'm typing this into a second-hand ex-corporate Lenovo
>T480s, built in 2018 according to its serial number label, and the X220
>that was previously very popular with DDs was a UEFI-capable amd64 from
>around 2012.)

Right, that’s possible for part of the use cases, and not a bad
idea anyway.

(Radical idea: application and framework developers ought to still
test their things on low-spec machines, to get a feeling for just
how much bloat they introduce…)

bye,
//mirabilos
-- 
<cnuke> den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │ <nvb> damals, als der pizzateig noch auf dem monior "gegangen" ist

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

#108536

On Thu, 06 Jul 2023 at 16:33:22 +0000, Thorsten Glaser wrote:
> Simon McVittie dixit:
> >architecture would need to have a new dpkg architecture name, multiarch
> >tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path.
> 
> Bit of bikeshedding on the name, of course. timet64 (or a shortened
> version) is a possibility but I’d also want off_t to be 64 bit in it
> like the BSDs have been doing for decades, for example.

That's easy, because glibc doesn't support 64-bit time_t without also
having 64-bit off_t (to avoid combinatorial explosion), so there are
three possible 32-bit ABIs instead of the four that you might expect:

1. 32-bit everything
2. large file support (64-bit off_t and inode numbers) but 32-bit time_t
3. large file support as above, and also 64-bit time_t

The current (backwards-compatible) i386 port is (1.) by default. An
opt-in to (2.) is available via -D_FILE_OFFSET_BITS=64 for the subset
of libraries that can support it without breaking ABI, and similarly
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 is an opt-in to (3.).
Specifying -D_TIME_BITS=64 on its own is an error, to avoid creating
a fourth mutually incompatible ABI.

Newer 32-bit ports like x32 started as (2.) or maybe even (3.) by
default.

Your proposed port would be (3.) from the beginning.

On the backwards-compatible i386 port, a lot of libraries already opt-in
to (2.), because it's relatively rare to have off_t or struct stat in
the ABI, therefore a lot of libraries can safely do this without breaking
their own ABI (for example libdbus, GLib and SDL all do this).

*Some* libraries can safely opt-in to (3.) as well (for example I proposed
a merge request for libdbus, and it looks as though SDL is also going
to do this, at least in version 3), but time_t in the ABI seems to be a
lot more common than struct stat in the ABI, so not all libraries can
safely do this (for example, GLib can't do this because unfortunately
it has some time_t in its ABI), hence the need to consider doing this
as a more general transition.

> I would like for things to be coïnstallable, of course. But why would
> the dynamic linker attempt to load the respective foreign libraries…
> oh right, not all are in the M-A path yet

That wasn't actually the reason for my concern. As far as I'm aware, the
glibc dynamic linker doesn't guarantee not to look at libraries from other
architectures' multiarch library directories, or even know which directory
is for which architecture. There's only one /etc/ld.so.conf(.d), which
all architectures share, and similarly there's only one ld.so.cache, so
the dynamic linker needs to be able to distinguish between co-installable
architectures and avoid loading "wrong" libraries.

You can see this by the error message you get if you try to load a
dlopen'd plugin for the wrong architecture, for example running an i386
Vulkan app if you only have amd64 Vulkan drivers: it's often something
like "wrong ELF type", as opposed to the "not found" that you might
expect.

I agree that this is less like amd64 vs x32 vs i386, and more like arm vs
armel vs armhf (all 32-bit ARM and all mutually incompatible). I believe
32-bit mips also has more than one ABI ("o32" and "n32") which might be
useful prior art for what you can and can't do in the ELF header.

(Of course, orthogonally, it would be nice if we could finally stop
shipping shared libraries in the non-multiarch directories before trixie.)

    smcv

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

#108537

Simon McVittie dixit:

>opt-in to (2.) is available via -D_FILE_OFFSET_BITS=64 for the subset
>of libraries that can support it without breaking ABI, and similarly

Right, but e.g. <fts.h> refuses to work under it.

>That wasn't actually the reason for my concern. As far as I'm aware, the
>glibc dynamic linker doesn't guarantee not to look at libraries from other
>architectures' multiarch library directories, or even know which directory
>is for which architecture. There's only one /etc/ld.so.conf(.d), which

Oh okay.

>I agree that this is less like amd64 vs x32 vs i386, and more like arm vs
>armel vs armhf (all 32-bit ARM and all mutually incompatible). I believe

Indeed.

>32-bit mips also has more than one ABI ("o32" and "n32") which might be

n32 is 64-bit, but from a short research, let’s not look at how
MIPS did this because it’s apparently convoluted and “historical
reasons” enough to make people despair (and apparently one can
compile an o32 file for MIPS64…).

But, yes, e_flags seems to be the way to go.

>(Of course, orthogonally, it would be nice if we could finally stop
>shipping shared libraries in the non-multiarch directories before trixie.)

Wouldn’t help here, considering that the old i386 has to be there
for legacy reasons so people might manually throw in, oh idk, an
OpenSSL 0.x and libstdc++5 even. But, yeah, M-A is nice now that
it works.

bye,
//mirabilos
-- 
<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design.  <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)

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

#108535

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

>>>>> "Helmut" == Helmut Grohne <helmut@subdivi.de> writes:

    Helmut> I concur. Given Simon's analysis and the replies even when
    Helmut> combined with earlier messages, I now see significantly more
    Helmut> voices for the opinion:

    Helmut>     i386 primarily exists for running legacy binaries and
    Helmut> binary compatibility with legacy executables is more
    Helmut> important than correct representation of time beyond 2038.

    Helmut> I'm inclined to call this consensus now and therefore ask
    Helmut> those that do not agree with it to reply here - even if your
    Helmut> reply is only stating that you disagree. As such, I think we
    Helmut> can skip the GR part unless we get (5?) disagreeing replies
    Helmut> here.

I agree this represents consensus of the thread here.

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

#108110

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

On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote:

> I've been reading the discussion around i386 a bit and found the
> direction it has taken a little unproductive.

I note that there are a number of packages available on i386 but not
available on amd64, is anyone planning on an MBF about this issue?

$ grep -h arch=.*i386 /var/lib/apt/lists/*Sources | grpe -v amd64 | grep -v -- -modules- | grep -v  -- -image- | grep -v -- -headers- | grep -v -- -dbg  | grep -v lib64 | grep -v x86-64-linux-gnu
 fp-units-i386 deb devel optional arch=i386
 fp-units-i386-3.2.2 deb devel optional arch=i386
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 profile=!noudeb,!stage1
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 profile=!noudeb,!stage1
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 profile=!noudeb,!stage1
 sse2-support deb misc optional arch=any-i386
 netdata-core-no-sse deb net optional arch=i386
 steam deb contrib/oldlibs optional arch=i386
 steam-libs-i386 deb metapackages optional arch=i386
 etqw deb contrib/games optional arch=i386
 etqw-server deb contrib/games optional arch=i386
 quake4 deb contrib/games optional arch=i386
 quake4-server deb contrib/games optional arch=i386
 speech-dispatcher-ibmtts deb contrib/sound optional arch=i386
 adlibtracker2 deb sound optional arch=i386
 atitvout deb misc optional arch=i386,ia64
 sb16ctrl-bochs deb otherosfs optional arch=any-i386
 cmucl deb lisp optional arch=i386
 cmucl-clm deb lisp optional arch=i386
 fenix deb devel optional arch=arm,armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,mipsn32,mipsn32el,powerpc,s390,sh4,sparc
 fenix-plugin-mpeg deb devel optional arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
 fenix-plugins deb devel optional arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
 fenix-plugins-system deb devel optional arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
 fnfx-client deb utils optional arch=i386
 fnfxd deb utils optional arch=i386
 fp-units-i386 deb devel optional arch=i386
 fp-units-i386-3.2.2 deb devel optional arch=i386
 fwupd-i386-signed-template deb admin optional arch=i386
 fwupd-i386-signed deb admin optional arch=i386
 gatos deb misc extra arch=i386
 libgatos-dev deb libdevel extra arch=i386
 libgatos0 deb libs extra arch=i386
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 profile=!noudeb,!stage1
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 profile=!noudeb,!stage1
 grub-efi-ia32-signed deb admin optional arch=i386
 grub-efi-ia32-signed-template deb admin optional arch=i386
 grub-efi-ia32-signed-template deb admin optional arch=i386
 sse2-support deb misc optional arch=any-i386
 lmms-vst-server deb sound optional arch=i386
 longrun deb utils optional arch=i386
 lphdisk deb admin optional arch=i386
 mig-i686-gnu deb devel optional arch=any-i386
 netdata-core-no-sse deb net optional arch=i386
 pcsx2 deb games optional arch=i386
 pixbros deb games optional arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4
 pixfrogger deb games optional arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4
 shim-helpers-i386-signed-template deb admin optional arch=i386
 shim-helpers-i386-signed deb admin optional arch=i386
 sqlite3-tools deb database optional arch=linux-any,hurd-i386
 steam deb contrib/oldlibs optional arch=i386
 steam-libs-i386 deb metapackages optional arch=i386
 strace64 deb utils optional arch=i386,powerpc,s390,sparc
 syslog-ng-mod-snmp deb admin optional arch=linux-any,hurd-i386
 wine32 deb otherosfs optional arch=i386,armel,armhf
 wine32-preloader deb otherosfs optional arch=i386,armel,armhf
 wine32-tools deb libdevel optional arch=i386,armel,armhf
 xserver-xorg-video-geode deb x11 optional arch=any-i386
 zsnes deb otherosfs optional arch=any-i386
 intel-mkl-linktool deb non-free/utils optional arch=i386
 libmkl-gf deb non-free/libs optional arch=i386
 libmkl-intel deb non-free/libs optional arch=i386
 libmkl-p4 deb non-free/libs optional arch=i386
 libmkl-p4m deb non-free/libs optional arch=i386
 libmkl-p4m3 deb non-free/libs optional arch=i386
 libmkl-vml-ia deb non-free/libs optional arch=i386
 libmkl-vml-p4 deb non-free/libs optional arch=i386
 libmkl-vml-p4m deb non-free/libs optional arch=i386
 libmkl-vml-p4m2 deb non-free/libs optional arch=i386
 libmkl-vml-p4m3 deb non-free/libs optional arch=i386
 steamcmd deb non-free/games optional arch=i386
 etqw deb contrib/games optional arch=i386
 etqw-server deb contrib/games optional arch=i386
 quake4 deb contrib/games optional arch=i386
 quake4-server deb contrib/games optional arch=i386
 speech-dispatcher-ibmtts deb contrib/sound optional arch=i386
 adlibtracker2 deb sound optional arch=i386
 atitvout deb misc optional arch=i386,ia64
 binutils64 deb devel optional arch=i386,powerpc,mips,mipsel,mips,mipsn32,mipsn32el,mipsr6,mipsr6el,mipsn32r6,mipsn32r6el,x32
 sb16ctrl-bochs deb otherosfs optional arch=any-i386
 cmucl deb lisp optional arch=i386
 cmucl-clm deb lisp optional arch=i386
 dxvk-wine32-development deb libs optional arch=i386,armel,armhf
 fenix deb devel optional arch=arm,armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,mipsn32,mipsn32el,powerpc,s390,sh4,sparc
 fenix-plugin-mpeg deb devel optional arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
 fenix-plugins deb devel optional arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
 fenix-plugins-system deb devel optional arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
 fnfx-client deb utils optional arch=i386
 fnfxd deb utils optional arch=i386
 fp-units-i386 deb devel optional arch=i386
 fp-units-i386-3.2.2 deb devel optional arch=i386
 fwupd-i386-signed-template deb admin optional arch=i386
 fwupd-i386-signed deb admin optional arch=i386
 gatos deb misc extra arch=i386
 libgatos-dev deb libdevel extra arch=i386
 libgatos0 deb libs extra arch=i386
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 profile=!noudeb,!stage1
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 profile=!noudeb,!stage1
 grub-efi-ia32-signed deb admin optional arch=i386
 grub-efi-ia32-signed-template deb admin optional arch=i386
 grub-efi-ia32-signed-template deb admin optional arch=i386
 sse2-support deb misc optional arch=any-i386
 lmms-vst-server deb sound optional arch=i386
 longrun deb utils optional arch=i386
 lphdisk deb admin optional arch=i386
 mac-fdisk-cross deb otherosfs optional arch=i386,m68k
 pmac-fdisk-cross deb otherosfs optional arch=i386,m68k
 mig-i686-gnu deb devel optional arch=any-i386
 mlton-runtime-i486-kfreebsd-gnu deb devel optional arch=kfreebsd-i386
 mlton-runtime-i486-linux-gnu deb devel optional arch=i386
 mlton-runtime-i486-kfreebsd-gnu deb devel optional arch=kfreebsd-i386
 mlton-runtime-i486-linux-gnu deb devel optional arch=i386
 netdata-core-no-sse deb net optional arch=i386
 pcsx2 deb games optional arch=i386
 pixbros deb games optional arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4
 pixfrogger deb games optional arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4
 shim-helpers-i386-signed-template deb admin optional arch=i386
 shim-helpers-i386-signed deb admin optional arch=i386
 sqlite3-tools deb database optional arch=linux-any,hurd-i386
 steam deb contrib/oldlibs optional arch=i386
 steam-libs-i386 deb metapackages optional arch=i386
 strace64 deb utils optional arch=i386,powerpc,s390,sparc
 syslog-ng-mod-snmp deb admin optional arch=linux-any,hurd-i386
 wine32 deb otherosfs optional arch=i386,armel,armhf
 wine32-preloader deb otherosfs optional arch=i386,armel,armhf
 wine32-tools deb libdevel optional arch=i386,armel,armhf
 wine32-development deb otherosfs optional arch=i386,armel,armhf
 wine32-development-preloader deb otherosfs optional arch=i386,armel,armhf
 wine32-development-tools deb libdevel optional arch=i386,armel,armhf
 wine32-development deb otherosfs optional arch=i386,armel,armhf
 wine32-development-preloader deb otherosfs optional arch=i386,armel,armhf
 wine32-development-tools deb libdevel optional arch=i386,armel,armhf
 xserver-xorg-video-geode deb x11 optional arch=any-i386
 zsnes deb otherosfs optional arch=any-i386
 intel-mkl-linktool deb non-free/utils optional arch=i386
 libmkl-gf deb non-free/libs optional arch=i386
 libmkl-intel deb non-free/libs optional arch=i386
 libmkl-p4 deb non-free/libs optional arch=i386
 libmkl-p4m deb non-free/libs optional arch=i386
 libmkl-p4m3 deb non-free/libs optional arch=i386
 libmkl-vml-ia deb non-free/libs optional arch=i386
 libmkl-vml-p4 deb non-free/libs optional arch=i386
 libmkl-vml-p4m deb non-free/libs optional arch=i386
 libmkl-vml-p4m2 deb non-free/libs optional arch=i386
 libmkl-vml-p4m3 deb non-free/libs optional arch=i386
 libnvidia-legacy-340xx-cuda1-i386 deb non-free/libs optional arch=i386
 nvidia-legacy-340xx-driver-libs-i386 deb non-free/libs optional arch=i386
 libnvidia-legacy-390xx-cuda1-i386 deb non-free/libs optional arch=i386
 nvidia-legacy-390xx-driver-libs-i386 deb non-free/libs optional arch=i386
 nvidia-legacy-390xx-driver-libs-nonglvnd-i386 deb non-free/libs optional arch=i386
 sl-modem-daemon deb non-free/misc optional arch=i386
 steamcmd deb non-free/games optional arch=i386

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

#108112

On 2023-06-07, Paul Wise <pabs@debian.org> wrote:
> On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote:
>
>> I've been reading the discussion around i386 a bit and found the
>> direction it has taken a little unproductive.
>
> I note that there are a number of packages available on i386 but not
> available on amd64, is anyone planning on an MBF about this issue?

I got curious. Some of them are hurd specific. Others are a i386
specific version, either for fewer processor capabilities or just a
specific one, like sigend bootloader packages and such. Lets remove
those and see what we have left. 

oh. and a few are miscategorized. And some binary-only non-free.

Some byte code interpreter for games and games. Apparantly puts pointers
in ints.
>  fenix deb devel optional arch=arm,armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,mipsn32,mipsn32el,powerpc,s390,sh4,sparc
>  fenix-plugin-mpeg deb devel optional arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
>  fenix-plugins deb devel optional arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
>  fenix-plugins-system deb devel optional arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
>  pixbros deb games optional arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4
>  pixfrogger deb games optional arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4

Last upstream release uploaded in 2004. Unsure why restricted
>  fnfx-client deb utils optional arch=i386
>  fnfxd deb utils optional arch=i386

TV card grabber. Last upstream release uploaded in 2002. Unsure why
restricted
>  gatos deb misc extra arch=i386
>  libgatos-dev deb libdevel extra arch=i386
>  libgatos0 deb libs extra arch=i386

Tv card configuration. Last upstream uploadde in 2002. Unsure why
restricted
>  atitvout deb misc optional arch=i386,ia64

loads vst plugins. But others does that on 64bit as well
>  lmms-vst-server deb sound optional arch=i386

Hardware driver helper. The accompanying dkms package seems to also be
x86_86
>  sl-modem-daemon deb non-free/misc optional arch=i386

playstation2 emulator. Requires sse2.
>  pcsx2 deb games optional arch=i386

snes emulator. last upstream release 2007
>  zsnes deb otherosfs optional arch=any-i386


Old soundblaster card related:
>  adlibtracker2 deb sound optional arch=i386
>  sb16ctrl-bochs deb otherosfs optional arch=any-i386

m68k helper. Unsure why restricted
>  mac-fdisk-cross deb otherosfs optional arch=i386,m68k
>  pmac-fdisk-cross deb otherosfs optional arch=i386,m68k

lisp runtie. unsure why restricted
>  cmucl deb lisp optional arch=i386
>  cmucl-clm deb lisp optional arch=i386

game stuff, mostly contrib, likely binary data for binary blobs
>  steam deb contrib/oldlibs optional arch=i386
>  steam-libs-i386 deb metapackages optional arch=i386
>  etqw deb contrib/games optional arch=i386
>  etqw-server deb contrib/games optional arch=i386
>  quake4 deb contrib/games optional arch=i386
>  quake4-server deb contrib/games optional arch=i386
>  steamcmd deb non-free/games optional arch=i386

Non-free or non-free binary dependencies
>  intel-mkl-linktool deb non-free/utils optional arch=i386
>  libmkl-gf deb non-free/libs optional arch=i386
>  libmkl-intel deb non-free/libs optional arch=i386
>  libmkl-p4 deb non-free/libs optional arch=i386
>  libmkl-p4m deb non-free/libs optional arch=i386
>  libmkl-p4m3 deb non-free/libs optional arch=i386
>  libmkl-vml-ia deb non-free/libs optional arch=i386
>  libmkl-vml-p4 deb non-free/libs optional arch=i386
>  libmkl-vml-p4m deb non-free/libs optional arch=i386
>  libmkl-vml-p4m2 deb non-free/libs optional arch=i386
>  libmkl-vml-p4m3 deb non-free/libs optional arch=i386
>  speech-dispatcher-ibmtts deb contrib/sound optional arch=i386

i386-version of something and helpers and hardware enablement:
>  fp-units-i386 deb devel optional arch=i386
>  fp-units-i386-3.2.2 deb devel optional arch=i386
>  fwupd-i386-signed-template deb admin optional arch=i386
>  fwupd-i386-signed deb admin optional arch=i386
>  libnvidia-legacy-340xx-cuda1-i386 deb non-free/libs optional arch=i386
>  nvidia-legacy-340xx-driver-libs-i386 deb non-free/libs optional arch=i386
>  libnvidia-legacy-390xx-cuda1-i386 deb non-free/libs optional arch=i386
>  nvidia-legacy-390xx-driver-libs-i386 deb non-free/libs optional arch=i386
>  nvidia-legacy-390xx-driver-libs-nonglvnd-i386 deb non-free/libs optional arch=i386
>  grub-efi-ia32-signed deb admin optional arch=i386
>  grub-efi-ia32-signed-template deb admin optional arch=i386
>  grub-efi-ia32-signed-template deb admin optional arch=i386
>  sse2-support deb misc optional arch=any-i386
>  shim-helpers-i386-signed-template deb admin optional arch=i386
>  shim-helpers-i386-signed deb admin optional arch=i386
>  strace64 deb utils optional arch=i386,powerpc,s390,sparc
>  wine32 deb otherosfs optional arch=i386,armel,armhf
>  wine32-preloader deb otherosfs optional arch=i386,armel,armhf
>  wine32-tools deb libdevel optional arch=i386,armel,armhf
>  wine32-development deb otherosfs optional arch=i386,armel,armhf
>  wine32-development-preloader deb otherosfs optional arch=i386,armel,armhf
>  wine32-development-tools deb libdevel optional arch=i386,armel,armhf
>  dxvk-wine32-development deb libs optional arch=i386,armel,armhf
>  netdata-core-no-sse deb net optional arch=i386
>  longrun deb utils optional arch=i386 (last upstream 2001)
>  lphdisk deb admin optional arch=i386 (last upstream 2001)
>  xserver-xorg-video-geode deb x11 optional arch=any-i386
>  mlton-runtime-i486-kfreebsd-gnu deb devel optional arch=kfreebsd-i386
>  mlton-runtime-i486-linux-gnu deb devel optional arch=i386
>  mlton-runtime-i486-kfreebsd-gnu deb devel optional arch=kfreebsd-i386
>  mlton-runtime-i486-linux-gnu deb devel optional arch=i386
>  binutils64 deb devel optional arch=i386,powerpc,mips,mipsel,mips,mipsn32,mipsn32el,mipsr6,mipsr6el,mipsn32r6,mipsn32r6el,x32


hurd/fbsd:
>  libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
>  libc0.3-dev deb libdevel optional arch=hurd-i386
>  libc0.3-udeb udeb debian-installer optional arch=hurd-i386 profile=!noudeb,!stage1
>  libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
>  libc0.3-dev deb libdevel optional arch=hurd-i386
>  libc0.3-udeb udeb debian-installer optional arch=hurd-i386 profile=!noudeb,!stage1
>  mig-i686-gnu deb devel optional arch=any-i386

false found:
>  syslog-ng-mod-snmp deb admin optional arch=linux-any,hurd-i386
>  sqlite3-tools deb database optional arch=linux-any,hurd-i386

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

#108113

Hi,

On Wed, Jun 7, 2023, at 09:19, Sune Vuorela wrote:
> lisp runtie. unsure why restricted
>>  cmucl deb lisp optional arch=i386
>>  cmucl-clm deb lisp optional arch=i386

cmucl contains a compiler and is self hosting (the compiler is used to create the new version of the environment). x86 is the last active architecture for this system, but as a whole it is slowly drying.

Most people moved on to using sbcl, which supports amd64 and has a more active development. I planned to ask for removal of cmucl after the next release. End of an era...

Best regards, Peter

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

#108114

On Wed, 07 Jun 2023 at 07:19:39 -0000, Sune Vuorela wrote:
> On 2023-06-07, Paul Wise <pabs@debian.org> wrote:
> > I note that there are a number of packages available on i386 but not
> > available on amd64, is anyone planning on an MBF about this issue?
> 
> game stuff, mostly contrib, likely binary data for binary blobs
> >  steam deb contrib/oldlibs optional arch=i386
> >  steam-libs-i386 deb metapackages optional arch=i386
> >  steamcmd deb non-free/games optional arch=i386

Steam consists of proprietary binaries which are a mixture of i386 and
amd64. It functionally requires *both* architectures to work. The top-level
package for how this now works in Debian is steam-installer.

The 'steam' package is a transitional package from an older packaging
scheme where it was possible to run on purely 32-bit systems (that is
not true any more), so it is only useful when upgrading existing
32-bit-capable machines.

Even if Valve chose to port the main Steam client executable to amd64,
the purpose of Steam is to run Steam games, and a lot of the older
games (like Team Fortress 2) are proprietary i386 binaries. As long as
that's the case, which in practice it will be forever, we'll need the
steam-libs-i386 metapackage to pull in at least the subset of those games'
dependencies that they cannot usefully bundle (mainly glibc and Mesa).

steamcmd is a proprietary i386 binary. No amd64 version exists, so
until/unless Valve produce one (likely to be a vanishingly low priority),
the only options are i386 or remove.

> >  etqw deb contrib/games optional arch=i386
> >  etqw-server deb contrib/games optional arch=i386
> >  quake4 deb contrib/games optional arch=i386
> >  quake4-server deb contrib/games optional arch=i386

These are wrappers around proprietary i386 binaries which are not in
Debian for licensing reasons, but can be packaged locally by using
game-data-packager. No amd64 version exists, and only their developer
(indirectly Microsoft, which owns ZeniMax, which owns id Software)
could produce one, which in practice is unlikely to happen; so the only
options are i386 or remove.

    smcv

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

#108115

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

On 2023-06-07 at 03:19, Sune Vuorela wrote:

> On 2023-06-07, Paul Wise <pabs@debian.org> wrote:
>
>> On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote:
>>
>>> I've been reading the discussion around i386 a bit and found the
>>> direction it has taken a little unproductive.
>>
>> I note that there are a number of packages available on i386 but not
>> available on amd64, is anyone planning on an MBF about this issue?
> 
> I got curious. Some of them are hurd specific. Others are a i386
> specific version, either for fewer processor capabilities or just a
> specific one, like sigend bootloader packages and such. Lets remove
> those and see what we have left. 
> 
> oh. and a few are miscategorized. And some binary-only non-free.

> snes emulator. last upstream release 2007
>>  zsnes deb otherosfs optional arch=any-i386

FWIW: though I haven't touched it in quite some while, I recall from all
those years ago that the reason zsnes is i386-only is that part of its
code is hand-written assembly language for (some variant of) that
architecture, and that rewriting it for that not to be the case would be
at best impractical.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

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

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

csiph-web