> ======== 32-bit arches ========
> 
> This includes stable arches x86, arm, ppc, sparc32, dev arches s390, and
> maybe more. Those are in much worse situation, with a mess on various
> fronts, some of them super hard to continue support. For example
> qtwebengine is less and less likely to manage to compile on a
> real-hardware, and not 32-bit chroot on 64-bit host. Arch Team want to
> minimize our work on those arches, meaning mass-destable and even
> mass-dekeyword, with potentially full drop of stable status.

We've got several different types of problems here.

1) Different data type sizes
This is the least problematic point, since testing in a chroot works fine.

2) Limitations, e.g. limited memory address space
Also not that problematic, since testing in a chroot on a 64bit kernel
circumvents the limitation somewhat.
Whether it makes sense to be able to build something in a chroot but never 
on real hardware is another question.

3) time64
This is work in progress. I guess we'll get it done until 2038.

4) isa- and hardware-related regressions.
This is the real problem that cannot be caught via chroots and testing
on fast 64bit machines...
We recently had an upstream regression in glibc that (from memory) broke
all machines without SSE. It took a surprisingly long time for anyone to
notice that, since of course any x86-64 machine understands these 
instructions. The only way to really reproduce it on modern hardware is
in qemu-system with disabled kvm.
Can we call an architecture "stable" if we never test on real (and not
"downward-emulated") hardware?

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)