Adds AltArch (32-bit) SIG proposal doc

[anantv-arista]

SIG Proposal for 32-bit Alma 10 support (renamed to 'AltArch')

cc @bennyvasquez

[bennyvasquez]

A few small suggestions to take into account the RPi builds, and adding Meta as one of the sig leads for the RPi builds.

[metalefty]

Please keep in mind that AltArch SIG is not exclusively for the x86_32 architecture but for all alternative architectures, including RISC-V and ARM SBCs. The suggested change risks giving the impression that the AltArch SIG is being dominated by x86_32.

My understanding is that, in practice, an x86_32 team (or sub-SIG) will be established within the AltArch SIG.

[andrewlukoshko]

Is EPEL necessary? We don't build it for AlmaLinux 9 i686

[anantv-arista]

Hi Andrew.

EPEL did not support x86_32 in the EPEL 9 version as well. Due to this, we had to build the i686 versions of the below list of packages ourselves in our infrastructure. It would be helpful if a certain subset of EPEL packages are also built for i686 by Almalinux. Would this be possible?

It would be a very limited list of packages. There could be other customers who want EPEL x86_32 packages as well.

• catch2
• libconfuse
• libsodium
• openpgm
• libftdi
• python-lz4
• python-pynacl
• tomlplusplus
• zeromq
• blosc
• libaec
• python-numexpr
• hdf5
• python-tables
• libimagequant
• libraqm
• python-kiwisolver
• python-pillow
• hiredis
• libcli
• log4cplus
• py-radix
• python-bcrypt
• python-Bottleneck
• python-regex
• re2
• yaml-cpp
• ctags
• gflags

[bennyvasquez]

The board held off on voting for this one, since the PR is no longer stable. We'll review it at our next meeting!

[metalefty]

Like other SIGs, the file name shouldn't include "SIG". It should be "AltArch.md".

[metalefty]

I don't think it is necessary to include all the work in this document. As with the docs of other SIGs, providing only an overall high-level overview should be sufficient.

Then we can make it more architecture-neutral. I'd rather think detailed information such as x86_32 timeline and resource considerations should be handled in ALESCo RFCs or SIG meeting minutes.

[anantv-arista]

I don't think it is necessary to include all the work in this document. As with the docs of other SIGs, providing only an overall high-level overview should be sufficient.

Then we can make it more architecture-neutral. I'd rather think detailed information such as x86_32 timeline and resource considerations should be handled in ALESCo RFCs or SIG meeting minutes.

I've updated the document, please have a look now.

[metalefty]

Overall LGTM, just a minor comment.

[bennyvasquez]

Looks good to me! @anantv-arista If you're okay with the suggested edits, you can accept them and then we'll get it approved at the next board meeting! In the meantime, you are encouraged to start working together on the work y'all will do - the mattermost room already exists, but let us know if you need any other communication methods set up! And if any of the SIG members would like an @ almalinux email address, just let me know!