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)

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 <eof@kiyuko.org>
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)

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)

Hi!

pe 15. maalisk. 2024 klo 6.56 Fabian Grünbichler <debian@fabian.gruenbichler.email> 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;debian@fabian.gruenbichler.email&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)

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 <debian@fabian.gruenbichler.email> 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)

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)