I have just seen at https://docs.mesa3d.org/amber.html that all graphics cards using the Radeon driver should be affected. That would nearly be catastrophic since I am running many Core 2 Quad Duos (with 16GB RAM or so) and Radeon R5 graphics cards which ought to continue to function.

Exchanging just the graphics cards on the FTS Esprimo machines won´t be possible since newer cards are known to conflict with s2ram on a machine level (neither works with Windows nor with Linux).

Can anyone point me onto how to open up an upstream report for this, Bug 31921? where should it be?: https://gitlab.freedesktop.org/drm, https://gitlab.freedesktop.org/search?search=mesa

You should accept that the support for 20 years old hardware is diminishing. There are no serious devs out there which are willing to waste time on such hardware.

A good example is the openSUSE i586 port. There was an outcry of two or three museum piece owners that the world will end if openSUSE carves out the i586 repos. openSUSE asked the last users of such hardware to maintain these ports, as no actual serious dev still has such hardware and time to maintain the software for it. 
Guess what: None of the loudmouthed i586 users stepped forward to provide some help to maintain the software for 20 years old hardware. The repos are several months behind because many packages are no longer buildable. Thats how time goes by...

I have lots of hardware that I run with the i586 target like my Atombook. You could basically also install with x86_64 there, but I wouldn´t recommend that. First Atombooks usually just had 1GB or 2GB of ram and if every pointer occupies twice the space it needed then you can run low in memory easily. The same issue applies to performance critical software like f.i. SAT-solvers. If the solver requires more memory access cycles, it simply runs slower. I learned to know that when I was developing DualSAT for my diploma thesis; though in the use of the newest amd64 hardware I had always compiled with -m32 (Some solvers don´t even compile on x64). Concerning openSUSE I have been using it a lot in former times, but today I still want a distribution that makes stable releases you can burn on DVD or flash on sdcard. If one distro like Arch-Linux ceases the i586 target, people won´t bother and simply move to other distros that do support this arch. I would have or say, I had made a similar choice some time ago. However you can´t compare that with Amber-branch support for Mesa as this is an upstream issue and not an issue of the distributor. I simply need that and if the Mesa project won´t accept me as a maintainer/developer, I will simply fork and underground git repo. I am not willing to crap all my running machinery, except the System76 i7-8565U notebook with 32GB (instead of 16GB) ram, just because a flull of the Mesa stuff. Possibly I still have some time for it to do since I am running Debian stable on most of these machines.

Having perused briefly the related links, it seems that you are the expert here.
You are offering to maintain the upstream version; would you equally offer to be its packager for Mageia?

CC: (none) => lewyssmith

I am not that much of an expert with Linux graphics, nor with Mesa; it´s the first time that I have touched this code. Facing a task like this I would have appreciated a little help from the upstream maintainers for the future. As long as making the code of the Amber branch compile remains relatively easy to do like cherry-picking some changes from the main branch, I am likely to do, and I will also be likely to upload respective Mageia packages to some place where they can be accessed (like https://www.elstel.info/uploads/). I don´t wanna be understood wrong, I´d love to do it as suggested by you, but there is currently lots of work left undone here at me. I don´t even manage to commit my last changes for index2web to the git repo, nor to put a few links of value online from the last days (hope they won´t get lost). I had already expressed some desire to package my own software from elstel.org for Mageia in the past. However at the time I didn´t manage to insert a sole ${x%.*} bash expression into xchroot to make it cope with hostname.domain instead of just hostname. I have packages for all of it at the openSUSE Build Service, but guess I did not manage to update dependencies for the bundsteg package to refer to package names that do really exist like texlive-collection-basic or pdftk up to some time ago when I wanted to install it from that repo ... - I am not complaining but I wish just opening a text editor for a few minutes to be suggestedly easier for me. If I should feel ready to do in the future I will tell you. At the moment my thoughts rather focus on what will be in the 9 release and when it will be published and, hey didn´t I want to do a test install for bug 31916?

Trying to assess the impact of this for users & maintenance.

(In reply to Elmar Stellnberger from comment #5)
It would be an irony of history if support for IA32/x86_32 would be ceased exactly now in this moment where it has become free for an open implementation: https://en.wikipedia.org/wiki/X86 . If I were to choose about implementing a 32bit system as open silicon I would probably prefer IA32 over riscv32. It is a highly optimized instruction set with widely supported toolchain and lots of software still available for it. If I install on AMD64 f.i., I use to have an i586 chroot as most, if not all of my Wine programs are for x32. - and keeping IA32 supported for Linux also means keeping it supported for Mesa.

(In reply to Lewis Smith from comment #8)
> Trying to assess the impact of this for users & maintenance.

Do we yet have any progress on this issue?

(In reply to Elmar Stellnberger from comment #9)
> It would be an irony of history if support for IA32/x86_32 would be ceased
> exactly now in this moment where it has become free for an open
> implementation: https://en.wikipedia.org/wiki/X86 . 

The open implementation startet in 2008 and died already in 2013. 10 years ago! Homepages got archived in 2018.

Then we are not going to include it.

Resolution: (none) => WONTFIX
Status: NEW => RESOLVED
CC: (none) => fri

(In reply to sturmvogel from comment #11)
> The open implementation startet in 2008 and died already in 2013. 10 years
> ago! Homepages got archived in 2018.

Can you give reference to this implementation?

P.S.: Please leave it up to Lewis Smith to report about this issue. AFAIK he is currently away.

Status: RESOLVED => REOPENED
Resolution: WONTFIX => (none)