I would like to suggest creating a dedicated x86_32bit branch.
Supporting native 32-bit x86 systems often requires architecture-specific fixes, package adjustments, dependency changes, toolchain work, Python-related fixes, and other compatibility patches that are not always relevant to the main branch. Having a dedicated branch would make it easier to develop, test, and maintain these changes without affecting other architectures.
I am willing to actively help maintain both the arm32bit (on mark-31) and x86_32bit branches, test updates, report regressions, and contribute fixes when needed.
This would help preserve support for legacy and low-resource hardware while keeping development organized and allowing architecture-specific improvements to be managed independently.
After discussing this with @geaaru on Discord, and based on the issues encountered and reported in PR #432, I believe a dedicated x86_32bit branch would provide a cleaner and more sustainable path for maintaining 32-bit support moving forward.
I would like to suggest creating a dedicated x86_32bit branch.
Supporting native 32-bit x86 systems often requires architecture-specific fixes, package adjustments, dependency changes, toolchain work, Python-related fixes, and other compatibility patches that are not always relevant to the main branch. Having a dedicated branch would make it easier to develop, test, and maintain these changes without affecting other architectures.
I am willing to actively help maintain both the arm32bit (on mark-31) and x86_32bit branches, test updates, report regressions, and contribute fixes when needed.
This would help preserve support for legacy and low-resource hardware while keeping development organized and allowing architecture-specific improvements to be managed independently.
After discussing this with @geaaru on Discord, and based on the issues encountered and reported in PR #432, I believe a dedicated x86_32bit branch would provide a cleaner and more sustainable path for maintaining 32-bit support moving forward.