1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Re: 64-bit time_t transition: cargo needs manual intervention

    From Samuel Thibault@21:1/5 to All on Wed Mar 13 12:40:01 2024
    Simon McVittie, le mer. 13 mars 2024 10:52:35 +0000, a ecrit:
    2. i386 is 32-bit but has been excluded from the 64-bit time_t transition
    because its major purpose this decade is running legacy 32-bit binaries,
    a purpose that would no longer be possible if it broke ABI
    - non-release architectures in the same category: hurd-i386 (I think)

    We asked hurd-i386 to be there indeed, because we plan to have
    hurd-amd64 replace hurd-i386 way before 2038 :)

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrea Bolognani@21:1/5 to Samuel Thibault on Wed Mar 13 18:10:01 2024
    On Wed, Mar 13, 2024 at 12:34:55PM +0100, Samuel Thibault wrote:
    Simon McVittie, le mer. 13 mars 2024 10:52:35 +0000, a ecrit:
    2. i386 is 32-bit but has been excluded from the 64-bit time_t transition
    because its major purpose this decade is running legacy 32-bit binaries,
    a purpose that would no longer be possible if it broke ABI
    - non-release architectures in the same category: hurd-i386 (I think)

    We asked hurd-i386 to be there indeed, because we plan to have
    hurd-amd64 replace hurd-i386 way before 2038 :)

    Wouldn't it make sense to migrate hurd-i386 to 64-bit time_t
    regardless of the plans for hurd-amd64? Contrary to linux-i386, it's
    not like there is a wealth of (possibly proprietary/binary-only)
    hurd-i386 software out there that we would benefit from remaining
    compatible with.

    --
    Andrea Bolognani <[email protected]>
    Resistance is futile, you will be garbage collected.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEO48t9niVypx3EjLf954fxUKFg6wFAmXx3GgACgkQ954fxUKF g6xNVw//cWffDcorF9SjSLCJXWerErEA1D74N0Zl+1IvgXYIK7S6PT82fWHYZetd rzd9fNgk8Oyo20AwSj0HQWmVhVGpCqJ4Vb7Alct7/Uf8vuc7mVunkyoR5sG6z/gm ptGEmXnDXAUmARQwo0ZrWTfS6GLJar9Q2x+KCAhXdyYVAWyqxxbeRQFkR63QCR1W gpKiidMWj7zS7ag+crF4oMeTXNfnhLg6y0WSTWmv9t9tY64WIahommwUMzXV187S VtEsGdm5dEY2ehwoO3lsWtUrCKXQJJlMlkziX7QzFA4Itelm94yxrPFkzEsy4c+M 8lSv4JDdMY53ZGSNQesRpTkHx0LZCFT6QZj6K6JaBXlahGswC+LdJ8VH0krQDYm1 TD93EdbSTO8XnjeTX7sENNpewqI8M8DFjENnCpDRfDVRIHDtA9R0LjPVTc46bD9h 2kRzprFKnbeIFOpbXwQXN6k18MOlRDTFx6koIO9d3FDhC91lyjw/bNInJGVpkOAv OjoqR0xvMS4AqD3TgoIj3m4UVtGHsjbZOGCwSFSOEjXUn7CG7ttRfKY9whLpiALa I6S3PKdnhhBE4yNFO++tNnSM9p6PJDYXBqouqztUFlgbhSYwlesdTAdhArfE8tVb xKxNJyetsjmFM+wcrBtY6NMfr99sB5V6ehSoUQI/G8DHEqm9H8w=
    =9JV3
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Wed Mar 13 18:20:01 2024
    Andrea Bolognani, le mer. 13 mars 2024 18:03:40 +0100, a ecrit:
    On Wed, Mar 13, 2024 at 12:34:55PM +0100, Samuel Thibault wrote:
    Simon McVittie, le mer. 13 mars 2024 10:52:35 +0000, a ecrit:
    2. i386 is 32-bit but has been excluded from the 64-bit time_t transition
    because its major purpose this decade is running legacy 32-bit binaries,
    a purpose that would no longer be possible if it broke ABI
    - non-release architectures in the same category: hurd-i386 (I think)

    We asked hurd-i386 to be there indeed, because we plan to have
    hurd-amd64 replace hurd-i386 way before 2038 :)

    Wouldn't it make sense to migrate hurd-i386 to 64-bit time_t
    regardless of the plans for hurd-amd64?

    When seeing the pain that arm* suffer, I believe we made the right
    choice.

    Contrary to linux-i386, it's not like there is a wealth of (possibly proprietary/binary-only) hurd-i386 software out there that we would
    benefit from remaining compatible with.

    Sure, but the migration itself takes manpower, for no real benefit.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?@21:1/5 to All on Fri Mar 15 16:20:02 2024
    Hi!

    pe 15. maalisk. 2024 klo 6.56 Fabian Grünbichler <[email protected]> kirjoitti:

    On Thu, Mar 14, 2024 at 10:03:57PM -0700, Otto Kekäläinen wrote:
    Hi!

    Is anyone perhaps planning to fix cargo?

    For example curl isn't building on armel/armhf now and numerous packages that depend of curl are not building on armel/armhf.

    Thanks in advance to the person who steps up.

    see the (linked) t64 transition bug:

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#197


    That link doesn't answer my question. The link is to bug report summarizing that cargo is broken and suggesting it needs to be re-bootstrapped.

    Currently we haven't seen anybody step up to do it. I would be very
    grateful if somebody with enough expertise would be available to do it and
    thus help resolve the whole chain of broken builds.




    <div dir="auto"><div>Hi!<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pe 15. maalisk. 2024 klo 6.56 Fabian Grünbichler &lt;[email protected]&gt; kirjoitti:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .
    8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Mar 14, 2024 at 10:03:57PM -0700, Otto Kekäläinen wrote:<br>
    &gt; Hi!<br>
    &gt; <br>
    &gt; Is anyone perhaps planning to fix cargo?<br>
    &gt; <br>
    &gt; For example curl isn&#39;t building on armel/armhf now and numerous packages<br>
    &gt; that depend of curl are not building on armel/armhf.<br>
    &gt; <br>
    &gt; Thanks in advance to the person who steps up.<br>

    see the (linked) t64 transition bug:<br>

    <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#197" rel="noreferrer noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#197</a></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That
    link doesn&#39;t answer my question. The link is to bug report summarizing that cargo is broken and suggesting it needs to be re-bootstrapped.</div><div dir="auto"><br></div><div dir="auto">Currently we haven&#39;t seen anybody step up to do it. I would
    be very grateful if somebody with enough expertise would be available to do it and thus help resolve the whole chain of broken builds.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #
    ccc solid;padding-left:1ex"><br>
    </blockquote></div></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fabian =?utf-8?Q?Gr=C3=BCnbichler?=@21:1/5 to All on Fri Mar 15 18:40:01 2024
    On Fri, Mar 15, 2024 at 08:16:40AM -0700, Otto Kek�l�inen wrote:
    Hi!

    pe 15. maalisk. 2024 klo 6.56 Fabian Gr�nbichler <[email protected]> kirjoitti:

    On Thu, Mar 14, 2024 at 10:03:57PM -0700, Otto Kek�l�inen wrote:
    Hi!

    Is anyone perhaps planning to fix cargo?

    For example curl isn't building on armel/armhf now and numerous packages that depend of curl are not building on armel/armhf.

    Thanks in advance to the person who steps up.

    see the (linked) t64 transition bug:

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#197


    That link doesn't answer my question. The link is to bug report summarizing that cargo is broken and suggesting it needs to be re-bootstrapped.

    Currently we haven't seen anybody step up to do it. I would be very
    grateful if somebody with enough expertise would be available to do it and thus help resolve the whole chain of broken builds.

    it does (the replies afterwards are about people stepping up, the
    coordination then shifted to IRC where it is still ongoing..). it will
    take a bit though, there are very large and intertwined dep chains to
    analyze and unwind (and/or temporarily break), as well as lots of manual rebootstrapping along the way..

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon McVittie@21:1/5 to Matthias Klose on Sat Mar 16 16:50:01 2024
    On Sat, 16 Mar 2024 at 15:37:20 +0100, Matthias Klose wrote:
    build gdb without libdebuginfo on the bootstrap archs for a while.

    That's likely also good advice, but the cycle involving gdb isn't the
    only one involving curl.

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)