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

#107988 — Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)]

On Sat, 20 May 2023 at 17:47, Adam Borowski <kilobyte@angband.pl> wrote:
>
> On Sat, May 20, 2023 at 09:15:00AM +0200, Josh Triplett wrote:
> > How easily could we add 64-bit system detection to the i386 installer,
> > and a message saying something like:
> >
> > "You're installing the i386 architecture on a 64-bit system. While this
> > will work, this is the last release it'll be supported. We recommend
> > installing the 64-bit amd64 architecture instead.

Note that similar messaging could be used for
compatible-and-higher-spec installation targets on other architectures
too.

(attempting to install armhf on an arm64 machine, for example)

I guess a challenge here is that the installation environment (kernel
and/or userspace) needs to know and provide information about the fact
that 64-bit mode works on the hardware it's running on, and for that
to be discoverable by the installer.

>From testing: when I load the i386 bullseye CD-ISO in x86-64 qemu (so:
running an i386 kernel), it was unclear to me from the shell whether
64-bit mode is supported on the hardware (it is, but we'd need a good,
reasonably portable and scriptable way to discover that).

> This is not a valid use for i386.  Running the i386 kernel on _modern_
> hardware is insecure, slower (esp. if you have a non-tiny amount of
> memory), etc.  We should put a big fat warnings for _that_.

What kind of insecurities would result from using an i386 kernel
instead of an amd64 one?

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

#107966 — Re: i386 in the future

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

On 2023-05-19 12:42 +0100, Steve McIntyre wrote:
> If they're still running
> i386 *hardware*, then they should be replacing that hardware with more
> modern, more capable, more *efficient* stuff.

I'm still using an i386 early acer netbook. (I even just upgraded it 4
releases from Wheezy to Bookworm to get a newer Alfa wifi card working
with a mdern kernel). It's only used for ~1 month/year, primarily as a
fancy long-range wifi router and it's reasonably low power. An rPI
would not be a useful replacement as it's not the same form factor
(robust clamshell, with screen/mouse).

I agree with you about i386 desktops/servers running under stairs
being a bad idea at this point, but I'm not convinced that this
netbook hardware should just be binned. One probably could find some
other hardware (and we will one day - the plan is to find/configure
some open router hardware that can actually run the fancy
scriptage/setup needed then everything can be in one box, but not this
year).

Removing the installer to stop supporting _new_ installs is probably
fair enough but I don't think we can yet say there are no reasonable
use cases for old i386 hardware.

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

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

#107970 — Re: i386 in the future

On Sat, 2023-05-20 at 04:25 +0100, Wookey wrote:
> On 2023-05-19 12:42 +0100, Steve McIntyre wrote:
> > If they're still running
> > i386 *hardware*, then they should be replacing that hardware with more
> > modern, more capable, more *efficient* stuff.
> 
> I'm still using an i386 early acer netbook. (I even just upgraded it 4
> releases from Wheezy to Bookworm to get a newer Alfa wifi card working
> with a mdern kernel). It's only used for ~1 month/year, primarily as a
> fancy long-range wifi router and it's reasonably low power. An rPI
> would not be a useful replacement as it's not the same form factor
> (robust clamshell, with screen/mouse).
[...]
> Removing the installer to stop supporting _new_ installs is probably
> fair enough but I don't think we can yet say there are no reasonable
> use cases for old i386 hardware.

I don't think that is a good use case to keep i386 installations on
i386 hardware alive beyond 2028 (which is what we are talking about):
just grab a slightly newer amd64 netbook out of the junk by the time
LTS support for Debian bookworm ends.

Ansgar

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

#107990

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

On Fri, May 19, 2023 at 05:34:56AM +0200, Guillem Jover wrote:

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

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

> Given the potential amount of libraries involved that would need an
> upload and the chokepoint in NEW, to me this seems like a big window
> of opportunity for unstable users that might not be following along
> to get a broken system (I mean yes «unstable» and all that, but if it
> can be avoided?).

Some options that I can see here:

- Do the NEW processing in experimental first.  In order to avoid additional
  per-source changes that should be cleaned up later, if we go that route I
  suggest doing it with an intentionally-incorrect ABI (i.e.: no versioned
  build-dep on dpkg and no manual enabling with DEB_BUILD_MAINT_OPTIONS).
- Get a committment from the ftp team to prioritize binary NEW review for
  this transition (and without blocking on unrelated source issues, such as
  buggy debian/copyright...) so that these can all be accepted in a fairly
  narrow window

> Enabling time64 explicitly is what also had first come to my mind,
> which does not seem too onerous if all the debhelper override
> disappears? :) Then NEW processing could be done in one go to let the
> flood gates open at a specific coordinated date and time range (or
> staged via NEW into experimental, then mass uploaded to unstable to
> reduce the pressure on the ftpmaster(s) having to approve those), at
> which point dpkg could also be uploaded with the default switched.

The difference in my view is that the changes to handle Provides: are
something that should persist in the packaging (until the next soname
change, at which point it's easy to handle as part of the overall renaming),
whereas explicit changes to set DEB_BUILD_OPTIONS to the future default are
something that ideally would be dropped immediately after dpkg-buildflags is
updated, and could (though unlikely) be a source of bugs later.  I'd prefer
to avoid any transition plan which means I should be NMUing all of the
affected library packages twice.

> Another option, perhaps, could be to flip the defaults, but then block
> uploads for affected packages using
> <https://ftp-master.debian.org/transitions.yaml>, which I think the
> release team controls?

I wasn't familiar with this interface, but it sounds like a good option - I
can easily provide the list of source packages to populate it with.

> But, if people in general are not bothered about this transitory
> breakage, and say, an announcement is considered enough, then sure
> I guess.


> If the other concern is that this would make Ubuntu's life harder due
> having chosen to keep i386 as such compat arch, I don't see why the
> Ubuntu vendor code in dpkg could not disable the switch for i386 there.

We would certainly do this in Ubuntu no matter what decision Debian takes. 
I am advocating it in Debian because I think it is the right thing for
Debian to do as well.

Either way, we will need to come to some sort of decision about what to do
on i386 before we can move forward.  How should we reach that decision?  Are
you persuaded by the arguments presented in this thread?

> Hmm, rechecking the script, I think we'd want to at least
> unconditionally add the Breaks and Replaces (no need for substvars
> then), otherwise we'd get upgrade errors?

> That would leave only the Provides as potentially conditional…

You're absolutely right, thanks for catching this!  Fixed in git.

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

> If the plan is to go with a flag day by switching the default for
> time64, then I don't see how the LFS change can be decoupled, as that
> automatically will also forcibly enable LFS globally on glibc arches.
> I've also in general been worried about automatically enabling LFS w/o
> someone looking into each package, given the greater potential for
> data loss. :/

I think in the case of LFS-sensitive libraries that aren't part of the
dependency graph of packages affected by the time_t change, it's easy enough
to patch them to not turn on the LFS flag and avoid a transition.

You raise a valid concern about data loss.  However, I fail to see any way
that we can effectively mitigate this in advance - either now or by delaying
the time_t transition.  I don't see any way to avoid this via automated
source analysis, so the only option (given that we can't avoid the time_t
transition forever) is to rebuild and then find out what breaks, which I
think is best done at the beginning of a release cycle - do you agree?

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

#108118

Hi!

On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote:
> On Fri, May 19, 2023 at 05:34:56AM +0200, Guillem Jover wrote:
> > Enabling time64 explicitly is what also had first come to my mind,
> > which does not seem too onerous if all the debhelper override
> > disappears? :) Then NEW processing could be done in one go to let the
> > flood gates open at a specific coordinated date and time range (or
> > staged via NEW into experimental, then mass uploaded to unstable to
> > reduce the pressure on the ftpmaster(s) having to approve those), at
> > which point dpkg could also be uploaded with the default switched.
> 
> The difference in my view is that the changes to handle Provides: are
> something that should persist in the packaging (until the next soname
> change, at which point it's easy to handle as part of the overall renaming),
> whereas explicit changes to set DEB_BUILD_OPTIONS to the future default are
> something that ideally would be dropped immediately after dpkg-buildflags is
> updated, and could (though unlikely) be a source of bugs later.  I'd prefer
> to avoid any transition plan which means I should be NMUing all of the
> affected library packages twice.

I think I understand where you are coming from, and I see how ideally
these would be dropped soon, but I also don't see this as a pressing
matter that would even need NMUs, as the explicit settings should map
to the then current defaults. Of course that precludes those defaults
then changing globally in the future, but if needed (!?) that could be
handled later on. But again, I think the flag day can potentially be
done in multiple other ways that might avoid the breakage w/o needing
these changes, and if so I'm happy with that as well.

> Either way, we will need to come to some sort of decision about what to do
> on i386 before we can move forward.  How should we reach that decision?  Are
> you persuaded by the arguments presented in this thread?

I think it depends a bit on the overall timing and support guarantees.
If say i386 was to be dropped very soon from the archive, then it does
not seem to me that making it an exception might be a good trade-off,
because people could then use an unsupported release for time32 and
a later unsupported one for time64 if they want to use either of those
ABIs. If there is a will to keep it longer (either as a full or partial
arch), then that changes the equation and it depends what people would
value more between ABI compat or time64-ready.

I think I covered part of this in
<https://lists.debian.org/debian-devel/2023/05/msg00228.html>. So if
there's consensus either way, I'm OK with that, but given that this is
a matter of trade-offs and what we'd want to support, Helmut's proposal
for a GR also sounds very enticing TBH, and would be a clear signal
and remove ambiguity over what the project wants to do.

> > Hmm, rechecking the script, I think we'd want to at least
> > unconditionally add the Breaks and Replaces (no need for substvars
> > then), otherwise we'd get upgrade errors?
> 
> > That would leave only the Provides as potentially conditional…
> 
> You're absolutely right, thanks for catching this!  Fixed in git.

As hinted above, I think the source:Version substvar should be
switched to a hardcoded version at the point the migration was done,
otherwise it will be floating forward and not catch older affected
versions?

> > > And btw, given the analysis that there are likely < 100 shared libraries
> > > overall whose ABI changes when enabling LFS, this might be a change we want
> > > to consider in the trixie cycle as well - just preferably not bundled with
> > > the time_t transition at the same time, as that would just cause more delays
> > > for testing migration vs splitting the two transitions.
> 
> > If the plan is to go with a flag day by switching the default for
> > time64, then I don't see how the LFS change can be decoupled, as that
> > automatically will also forcibly enable LFS globally on glibc arches.
> > I've also in general been worried about automatically enabling LFS w/o
> > someone looking into each package, given the greater potential for
> > data loss. :/
> 
> I think in the case of LFS-sensitive libraries that aren't part of the
> dependency graph of packages affected by the time_t change, it's easy enough
> to patch them to not turn on the LFS flag and avoid a transition.

Just to try to understand whether we are on the same page. If these
libraries have no time_t usage at all, then disabling time64 should
then provoke no time_t issue and should stop implicitly enabling LFS.
But if the library contains internal time_t usage that is not part of
the exposed ABI, but part of its operation, then I'm not sure I see
how we can patch them to disable LFS w/o at the same time losing
time64 support (as the latter forces/requires the former).

I'm not sure whether you are talking about the first or second case?
And whether we have no libraries at all falling under the second case?

> You raise a valid concern about data loss.  However, I fail to see any way
> that we can effectively mitigate this in advance - either now or by delaying
> the time_t transition.  I don't see any way to avoid this via automated
> source analysis, so the only option (given that we can't avoid the time_t
> transition forever) is to rebuild and then find out what breaks, which I
> think is best done at the beginning of a release cycle - do you agree?

To me that sounds like a rather scary and dangerous prospect, and I
guess the main reason we have never considered doing this before. And
I'm not sure all these cases can be discovered within a release cycle,
even if this is done at the beginning of it. But that would certainly
then become a blocker for the time64 transition. :/ Here again, I
think if people in general are OK with the consequences, then I guess
that would be OK, although TBH my ideal preference would be code review
and enabling things manually (which is what I've done with packages I
maintain, but yeah meh). The GR here also seems rather enticing I guess.

Thanks,
Guillem

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

#108200

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

On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote:

> On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote:

> > The difference in my view is that the changes to handle Provides: are
> > something that should persist in the packaging (until the next soname
> > change, at which point it's easy to handle as part of the overall renaming),
> > whereas explicit changes to set DEB_BUILD_OPTIONS to the future default are
> > something that ideally would be dropped immediately after dpkg-buildflags is
> > updated, and could (though unlikely) be a source of bugs later.  I'd prefer
> > to avoid any transition plan which means I should be NMUing all of the
> > affected library packages twice.

> I think I understand where you are coming from, and I see how ideally
> these would be dropped soon, but I also don't see this as a pressing
> matter that would even need NMUs, as the explicit settings should map
> to the then current defaults. Of course that precludes those defaults
> then changing globally in the future, but if needed (!?) that could be
> handled later on. But again, I think the flag day can potentially be
> done in multiple other ways that might avoid the breakage w/o needing
> these changes, and if so I'm happy with that as well.

After thinking about it, I'd like to suggest the following approach.

- dpkg with the new default behavior uploaded to experimental
- libraries uploaded to experimental with the new package names (so, NEW
  processing gets done) and with a versioned build-dependency (easy to
  automate with sed on debian/control)
- once all the libraries have cleared NEW, copy to unstable without dropping
  the versioned build-dependency; it will never be wrong, it will always at
  most be cruft that can be cleaned up lazily

What do you think?

> > > Hmm, rechecking the script, I think we'd want to at least
> > > unconditionally add the Breaks and Replaces (no need for substvars
> > > then), otherwise we'd get upgrade errors?

> > > That would leave only the Provides as potentially conditional…

> > You're absolutely right, thanks for catching this!  Fixed in git.

> As hinted above, I think the source:Version substvar should be
> switched to a hardcoded version at the point the migration was done,
> otherwise it will be floating forward and not catch older affected
> versions?

Oh ok, I didn't catch that this is what you meant.  But it's not clear to me
what you mean by "not catch older affected versions" - why would it be wrong
to Breaks/Replaces against non-existent, newer versions of an obsolete
binary package name?

It's not a difficult change to make, I just don't understand why it's
important.

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

> > > If the plan is to go with a flag day by switching the default for
> > > time64, then I don't see how the LFS change can be decoupled, as that
> > > automatically will also forcibly enable LFS globally on glibc arches.
> > > I've also in general been worried about automatically enabling LFS w/o
> > > someone looking into each package, given the greater potential for
> > > data loss. :/

> > I think in the case of LFS-sensitive libraries that aren't part of the
> > dependency graph of packages affected by the time_t change, it's easy enough
> > to patch them to not turn on the LFS flag and avoid a transition.

> Just to try to understand whether we are on the same page. If these
> libraries have no time_t usage at all, then disabling time64 should
> then provoke no time_t issue and should stop implicitly enabling LFS.
> But if the library contains internal time_t usage that is not part of
> the exposed ABI, but part of its operation, then I'm not sure I see
> how we can patch them to disable LFS w/o at the same time losing
> time64 support (as the latter forces/requires the former).

> I'm not sure whether you are talking about the first or second case?
> And whether we have no libraries at all falling under the second case?

I was only thinking about the first case, I had not previously considered
the second case.  We should be able to determine fairly easily whether there
are any in the second case; for all ELF binaries which are built from the
same source package as an LFS-sensitive library, check whether they have
references to any of the static list of symbols in glibc that are affected
by time_t, and if they are, add them to the list of libraries to transition.

I'll add this to the analysis in progress.

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

#108221

On Tue, 2023-06-13 at 21:41:50 -0700, Steve Langasek wrote:
> After thinking about it, I'd like to suggest the following approach.
> 
> - dpkg with the new default behavior uploaded to experimental
> - libraries uploaded to experimental with the new package names (so, NEW
>   processing gets done) and with a versioned build-dependency (easy to
>   automate with sed on debian/control)
> - once all the libraries have cleared NEW, copy to unstable without dropping
>   the versioned build-dependency; it will never be wrong, it will always at
>   most be cruft that can be cleaned up lazily
> 
> What do you think?

Yeah, sounds good to me.

> On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote:
> > On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote:
> > > > Hmm, rechecking the script, I think we'd want to at least
> > > > unconditionally add the Breaks and Replaces (no need for substvars
> > > > then), otherwise we'd get upgrade errors?
> 
> > > > That would leave only the Provides as potentially conditional…
> 
> > > You're absolutely right, thanks for catching this!  Fixed in git.
> 
> > As hinted above, I think the source:Version substvar should be
> > switched to a hardcoded version at the point the migration was done,
> > otherwise it will be floating forward and not catch older affected
> > versions?
> 
> Oh ok, I didn't catch that this is what you meant.  But it's not clear to me
> what you mean by "not catch older affected versions" - why would it be wrong
> to Breaks/Replaces against non-existent, newer versions of an obsolete
> binary package name?

Err, sorry right, that paragraph didn't make much sense, I think I might
have lost context between the first time I checked this and the next. :)

> It's not a difficult change to make, I just don't understand why it's
> important.

Rereading my own comment, I think what I might have been thinking about
was that the version restrictions do not make much sense, and would not
protect against potential reintroduction of those obsolete package
(probably not in Debian but elsewhere). So probably not important in
the Debian context, but it would seem more correct and future-proof to
me to completely drop the version restrictions?

> > Just to try to understand whether we are on the same page. If these
> > libraries have no time_t usage at all, then disabling time64 should
> > then provoke no time_t issue and should stop implicitly enabling LFS.
> > But if the library contains internal time_t usage that is not part of
> > the exposed ABI, but part of its operation, then I'm not sure I see
> > how we can patch them to disable LFS w/o at the same time losing
> > time64 support (as the latter forces/requires the former).
> 
> > I'm not sure whether you are talking about the first or second case?
> > And whether we have no libraries at all falling under the second case?
> 
> I was only thinking about the first case, I had not previously considered
> the second case.  We should be able to determine fairly easily whether there
> are any in the second case; for all ELF binaries which are built from the
> same source package as an LFS-sensitive library, check whether they have
> references to any of the static list of symbols in glibc that are affected
> by time_t, and if they are, add them to the list of libraries to transition.
> 
> I'll add this to the analysis in progress.

Perfect, thanks!

Regards,
Guillem

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

#107924

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

On Wed, May 17, 2023 at 08:14:52PM -0500, Richard Laager wrote:
> They mention, "We likely have to complete Modern C porting first to remove
> any instances of -Wimplicit-function-declaration otherwise the redirects in
> glibc for e.g. time->time64 won't actually work." That links to:
> https://inbox.sourceware.org/libc-alpha/874js2iqlg.fsf@oldenburg.str.redhat.com/

> Has that issue been considered here? (I can't speak intelligently on it at
> this time. I just want to make sure it's on your radar.)

Thanks, I was unaware of this.  Sounds like feature=+time64 should also emit
-Wno-implicit-function-declaration; cc:ing the bug on dpkg regarding
implementation of that interface.

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

#107965

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

On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote:
> Based on the analysis to date, we can say there is a lower bound of ~4900
> source packages which will need to be rebuilt for the transition, and an
> upper bound of ~6200.  I believe this is a manageable transition, and
> propose that we proceed with it at the start of the trixie release cycle.

With more progress on making the headers analyzable, the lower bound is now
5063 and the upper bound is 5975 (not counting any entanglement with
lfs-sensitive libraries whose reverse-dependencies also depend on
time_t-sensitive libraries, that's still to be worked out).

In case that gives anyone more confidence in the plan :)

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

#107972

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

On 2023-05-17 20:14 -0500, Richard Laager wrote:
> 
> They mention, "We likely have to complete Modern C porting first to remove
> any instances of -Wimplicit-function-declaration otherwise the redirects in
> glibc for e.g. time->time64 won't actually work."

> Has that issue been considered here? (I can't speak intelligently on it at
> this time. I just want to make sure it's on your radar.)

I was aware of it (the gentoo info is linked on the 64bit-time wiki
page), but had not yet looked into how significant an issue this actually
was, so had not documented it. (frankly, I was hoping we could avoid
tying yet another transition into this one). Thanks for the reminder.

So having re-read that, if I understand this correctly, we do need to
be mindful that software which looks up functions or function
parameters in unusual ways (e.g. cross-language Foreign Function
Interfaces, or using implicit declarations) is likely to get the
wrong-size definition (because glibc makes both versions available).

So we should enable -Wimplicit-function-declaration on libraries being
rebuilt because their ABIs changed. We don't need to enable/fix it for
everything though. A rebuild check of affected libraries to see how
much work this adds would be a good idea.

I'll add this info the the wiki and do some tests.

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

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

#107976

On 2023-05-20 Wookey <wookey@wookware.org> wrote:
> On 2023-05-17 20:14 -0500, Richard Laager wrote:
>> They mention, "We likely have to complete Modern C porting first to remove
>> any instances of -Wimplicit-function-declaration otherwise the redirects in
>> glibc for e.g. time->time64 won't actually work."

>> Has that issue been considered here? (I can't speak intelligently on it at
>> this time. I just want to make sure it's on your radar.)

> I was aware of it (the gentoo info is linked on the 64bit-time wiki
> page), but had not yet looked into how significant an issue this actually
> was, so had not documented it. (frankly, I was hoping we could avoid
> tying yet another transition into this one). Thanks for the reminder.
[...]

Hello,

There is an ongoing Fedora project by Florian Weimer which includes this
issue.

https://fedoraproject.org/wiki/Changes/PortingToModernC

Not sure whether there is a similar effort for Debian but it should help
a lot, everything with active upstream that is packaged by Fedora will
be fixed.

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]

#107991

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

On Sat, May 20, 2023 at 12:28:41PM +0100, Wookey wrote:
> I was aware of it (the gentoo info is linked on the 64bit-time wiki
> page), but had not yet looked into how significant an issue this actually
> was, so had not documented it. (frankly, I was hoping we could avoid
> tying yet another transition into this one). Thanks for the reminder.

> So having re-read that, if I understand this correctly, we do need to
> be mindful that software which looks up functions or function
> parameters in unusual ways (e.g. cross-language Foreign Function
> Interfaces, or using implicit declarations) is likely to get the
> wrong-size definition (because glibc makes both versions available).

> So we should enable -Wimplicit-function-declaration on libraries being
> rebuilt because their ABIs changed.

I guess this needs to be -Werror=implicit-function-declaration, to ensure it
fails the build if used, regardless of whether -Werror is set elsewhere?

> We don't need to enable/fix it for everything though.  A rebuild check of
> affected libraries to see how much work this adds would be a good idea.

Isn't it a problem not just for library ABIs but also for any other packages
rebuild with -D_TIME_BITS=64, because the code will be consuming the 64-bit
prototype from the headers but using the 32-bit symbol at runtime?

(Which is a better answer in terms of automation, because then we can just
put it in dpkg-buildflags)

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

#107992

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

On Mon, May 22, 2023 at 06:24:53PM -0700, Steve Langasek wrote:
> > We don't need to enable/fix it for everything though.  A rebuild check of
> > affected libraries to see how much work this adds would be a good idea.

> Isn't it a problem not just for library ABIs but also for any other packages
> rebuild with -D_TIME_BITS=64, because the code will be consuming the 64-bit
> prototype from the headers but using the 32-bit symbol at runtime?

To clarify: not every package will be affected by this because not every
package is going to use the libc time_t functions.  But enough will that I
think the better path forward is to enable
-Werror=implicit-function-declaration across the board and fix any build
failures, which makes for better code in the long run anyway, than to enable
this by hand only for affected libraries and then have to deal with a bunch
of runtime bugs.

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

#108097

Hi Steve,

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.

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.

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.

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.

Helmut

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

#108098

On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote:
> 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.

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)

For example, Ubuntu has ceased to support i386 for the first use-case,
and only supports the second use-case. I personally think that Ubuntu
has made a good pragmatic decision here, which Debian should seriously
consider adopting.

Most non-Debian-derived distributions like Fedora and Arch seem to be in
approximately the same position as Ubuntu for their i386 support, although
they tend to use multilib (lib64+lib or lib+lib32) instead of multiarch.

Which of these use-cases is more interesting to us has an impact on how
we (should) want to do the time32 transition. For users who do not have
any legacy i386 binaries and only use open source software that can be
recompiled, the need to recompile everything is a one-time cost for the
distribution or for users of locally-compiled software, but does not make
anything impossible.

However, if the ABI of commonly-used libraries like libX11 undergoes an
incompatible change for the time32 transition, in a way that breaks the
ability to run legacy i386 binaries, then the second use-case is going
to become essentially impossible for native Linux binaries.

Conversely, the ability to tell the time correctly is probably less
important for games and similar legacy i386 binaries than it would be for
a full, bootable OS, because timestamps that can be subtracted to get a
relative time interval are probably sufficient for many legacy uses of
time_t. Even in cases where a time_t is used for an absolute date/time,
displaying the wrong date/time after 2038 seems like a less bad failure
mode than a segmentation fault caused by disagreeing on the size of a
struct in memory.

The i386-legacy-binaries use-case is particularly visible to game players,
because older proprietary native Linux games, including a number of
older games available on Steam, are a high-visibility source of legacy
i386 binaries that we cannot recompile. At the moment, the Steam client
is also an example of a legacy i386 binary: this was originally for
portability to 32-bit hardware, which it no longer supports, but the
bootstrap executable that launches the rest of Steam has continued to be
32-bit, partly for historical reasons and partly as a canary to detect and
diagnose non-32-bit-capable OSs before the user tries to run any actual
games. Steam does have the ability to run legacy games in a container
(which I've spent a lot of time working on over the last few years),
but that still requires the host system to contribute at least glibc
and Mesa, together with their dependencies.

Whether we care about the 32-bit-system use case or only the
i386-legacy-binaries use case is also a key input into other decisions
that need to be made around x86, like whether we raise the baseline
to include SSE2: if we want to be able to run i386 on older 32-bit
CPUs indefinitely, then that's a reason to keep the current baseline,
but if we are no longer interested in supporting 32-bit x86 hardware,
then we can (and arguably should) raise the baseline to require all the
features that are mandatory for x86_64, notably SSE2 (which would allow
compiling everything with -mfpmath=sse and therefore avoiding weird
i386-specific bugs caused by excess precision in the legacy i387 FPU).

    smcv

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

#108099

On Tue, 6 Jun 2023 at 11:46, Simon McVittie <smcv@debian.org> wrote:
>
> On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote:
> > 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.
>
> 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)
>
> For example, Ubuntu has ceased to support i386 for the first use-case,
> and only supports the second use-case. I personally think that Ubuntu
> has made a good pragmatic decision here, which Debian should seriously
> consider adopting.

+1

Given native 32-bit x86 hardware is no longer produced (and has not
been produced for a good while), so it has a de-facto limited life, as
consumer-grade electronics are what they are. Let's say hypothetically
that Trixie is the last full-i386 release, going out in 2025 plus 10
years of LTS+ELTS support that gives a supported OS till 2035, just
shy of the Y2038 deadline and with ~25 years of full support for the
most recent piece of hardware that was produced. And it's not like
those OSes versions are going to evaporate into thin air at that point
- they can still be used. Probably should not be connected to the open
internet and used to browse the web, but realistically already today I
doubt browsing the modern web is a good experience on 32bit hardware
from 2010, I can't imagine it would much better be in 2035...

On the other hand, i386 binaries that can run on x86_64 are
realistically going to be around for much, much longer as you pointed
out, so to me prioritizing this use case seems more prudent and
future-proof between the two alternatives.

Kind regards,
Luca Boccassi

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

#108101

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

On Jun 06, Simon McVittie <smcv@debian.org> 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:
Agreed. I will be more blunt: an i386 port which cannot run old i386 
binaries would be almost useless.

-- 
ciao,
Marco

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

#108103

Simon McVittie dijo [Tue, Jun 06, 2023 at 11:45:26AM +0100]:
> On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote:
> > 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.
> 
> 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)
> (...)

I completely agree with your analysis here, and I agree we should
strive to keep 2a and 2b covered, as they are (and they will be, every
time by a bigger margin) by far more common and productive than 1.  I
agree with your assessment that date woes will be minor for the i386
user than incompatibility woes going forward; there is the possible
case of people running I-don't-know-which proprietay productivity tool
provided as a binary that cannot be convinced of a 64-bit time_t that
will receive errors when the timeocalypse approaches, but I guess the
gaming use cases will be much more frequent than that; even though
your vision might be somewhat skewed by the fact that you work in
Steam, it makes complete sense.

Of course, given our i386 users would be running (>10 years for now) a
Debian architecture used mostly for compatibility with old non-free
binaries, we'd have to think whether it makes sense to provide a full
Debian experience (i.e. you don't want i386 users to have a PostgreSQL
with a known-borked time implementation storing important information
in it -- and of course, this is only the first of too many examples
that comes to my mind, but won the race to get to my fingers 😉)

But anyway, back to what matters here: I support Helmut's idea. I have
long thought we fear the GR process too much, and we should excercise
it more. Not every GR has to be a flamefest. Having a clear statement
of what is being voted on, and the possible consequences on each of
the options, can lead to a civil, useful way to measure the opinion of
project members interested in the subject.

Right now, I imagine a ballot similar to:

The future of i386 in Debian from Trixie onwards

   A. Drop support of i386 completely
   B. Keep support of i386 as a multiarch-foreign arch, with 32-bit time_t
   C. Keep support of i386 as a multiarch-foreign arch, with 64-bit time_t
   D. Commit to supporting i386 as a full-featured arch, with 32-bit time_t
   E. Commit to supporting i386 as a full-featured arch, with 64-bit time_t
   F. Further discussion

I know this woul conflate two decisions in one ballot, but arguably
they are part of the same issue. I do not feel qualified to draft the
full vote, as I have not followed the discussion as closely as I'd
like to and I'm not directly affected anyway, but would be very happy
to second it.

FWIW, I believe the only real danger in having non-controversial GRs
would be that a vote does not reach quorum (48 voters in the last GR),
but I don't believe it is a real danger to worry about; in any case,
failure to reach quorum would mean the project does not _mandate_ a
decision, but it can be anyway implemented by porters / RT.

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

#108104

On Tue, 06 Jun 2023 at 12:27:56 -0600, Gunnar Wolf wrote:
> there is the possible
> case of people running I-don't-know-which proprietay productivity tool
> provided as a binary that cannot be convinced of a 64-bit time_t that
> will receive errors when the timeocalypse approaches

Sure, and that's unfortunate; but if those same people run the same binary
on i386 + 64-bit time_t, and it gets memory corruption and crashes
because some library that was recompiled for this transition is now trying
to put a 64-bit time_t into a 32-bit location, that's not actually going
to be any more suitable for their needs.

    smcv

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

#108106

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

Hi,

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.


For the same reason, this line in the wiki [wiki] may not be true:
> 32-bit wine (i386 only). This does not make much sense with 64-bit time. It's whole purpose is to run old i386-ABI binaries. The ABI for this arch (and thus wine-32) should not change. 



Also, as said in this interesting Wine-devel thread about i386 [wine-devel-32bits]:
> Many 64-bit applications still use either a 32-bit installer or some
> 32-bit components. In comparison 64-bit Windows will support 32-bit
> (probably) forever.

And even if newer Wine versions supports WoW (32 bits Windows on 64 bits
within the same Wine prefix), 64 bit Wine still require 32 bits Linux
libraries to run 32 bits Windows programs.

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



[msvcrt-time]
  - https://sources.debian.org/src/wine/8.0~repack-4/include/msvcrt/time.h/#L92
  - https://sources.debian.org/src/wine/8.0~repack-4/dlls/msvcrt/time.c/#L781

[wiki] https://wiki.debian.org/ReleaseGoals/64bit-time
[wine-devel-32bits] https://www.winehq.org/pipermail/wine-devel/2019-June/147869.html

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F                |

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

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

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

csiph-web