Re: Re-evaluating architecture inclusion in unstable/experimental

[Thorsten Glaser <tg@debian.org>]

Eek! I only saw this by accident, as I’m also not subscribed to
d-devel.

>On Sat, Sep 29, 2018 at 07:48:09AM +0100, Ben Hutchings wrote:

>> - x32 has 64-bit time_t and that never worked quite right.  This may
>>   have finally been fixed this year by Arnd Bergmann's work, but I'm
>>   not sure.

They have. Also, most of the ioctls. His work is important for
other architectures, both future ones and current-ones-which-
will-need-a-new-ABI-in-2038 ones, and so it’s good that this
is showcased on x32.

>> - There have been several regressions specific to x32, some of which
>>   stuck around for a year or so before someone and fixed them.

I’m trying to fix things as I go along. I’m not always skilled
enough to fix everything, though, nor are maintainers applying
patches, or upstreams. I know Adrian also does, and occasionally
others.

>As a (lapsed) porter for x32 here in Debian, I don't think it's worth
>keeping.  Despite all the touted benefits, no one uses the arch.  There's a

That’s wrong. I’ve crossgraded my desktop at work to x32, with
M-A to i386 for a continuously smaller-becoming number of things.

>Thus: I propose to drop x32, and reallocate your tuits to other archs.

That would inconvenience me quite a bit, *and* tell me that all
the effort I invested, all the time spent hacking, debugging,
learning and teaching, is worth nothing.

It’s also surprising how this has not found its way to me on
the ports mailing list, which I’m fairly sure I’m subscribed to.

[ m68k ]

> But the available hardware is either too slow to be useful, or only
> available through crowdfunding (maybe, eventually).

In quite a *lot* of scenarios, slowness of hardware isn’t the
most important criterion. People are willing to take it, as the
gains outweigh it, for a number of applications.

Also, having a lot of ports helps. Just this week, I found a
stack overflow in dietlibc because the testsuite failed on alpha.
It was an integer array overwriting half the return address, found
only by sheer luck of not only the actual stack layout of the
function working for us but also its architectural constraints,
such as general memory and stack layout. (I could tell of many
more such cases, where porting found bugs in code, but most of
them are quite some time ago.)

bye,
//mirabilos
--  
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival