Arch Linux User Repository Requires Packages To Support x86_64: No ARM-Only Software

[Quackdoc]

No, you can cross compile ARM packages from x86 to ARM (and viceversa). You just need a sysroot (the generic ALARM AArch64 image suffices), a cross compiler (either stock clang or a specific build of GCC like the one in the repos) and a custom makepkg.conf. That's it.

Distcc is for distributed compilation, not necessarily cross compiling btw.

can you point to some documentation? I've tried to set this up before but I just don't have the time I once did to go about mucking around anymore. I could figure this out im sure but realistically unless I can find docs now, my hands are to crap to really be doing much tinkering.

[Quackdoc]

I don't understand the current hype around ARM. Historically ARM has always been the e-waste ISA with FOSS hostile vendors and mostly proprietary ecosystem with zero standards. No UEFI, no ACPI, no sane boot process, unless it's one of those ARM server ready boards. It's all garbage.


And why the hype for RISC-V? Is there anything to prevent vendors to do the same shit? Proprietary drivers, fucking device trees and special sauce firmware.

I mean what exactly you as the end user are getting by replacing AMD64 with any of that TODAY (not in 10 years)?

And Qualcomm does not exactly have a good track record. I would hope Intel or AMD comes to the rescue and develop sane platforms for either ARM or RISC-V, where you can boot just about any OS on any hardware.

ARM is a mess, but this is mainly because of half baked device trees and shoddy upstream support. Nothing stops risc-v vendors from doing this too, but at least for now it's not been happening. Pretty much every riscv vendor has been really good with trying to get stuff upstream. Imagination even has developers working on mesa now too. UEFI and ACPI really aren't necessary to have a decent generic experience.

You can have "generic kernels" for arm and riscv already that will work on some software, but like I said, shoddy upstream support is the issue. I think brucehoult could comment more on this assuming this is the right account

EDIT: it's also worth noting once you have kernel bring up, you can pretty much plunk any rootfs ontop of your system and have it working as long as you get init stuff properly setup. This is how I use archlinux on my crappy RK3188 box. I really need to see if I can install to emmc tho because the SD card and USB on it is uselessly slow.

EDIT2: IIRC the current risc-v situation isn't too terrible either. openSBI + uboot handles bootloader stuff, then you can run a generic linux image assuming your kernel works for your hardware. You do need the openSBI + Uboot for your soc. but that is an SBC issue to deal with, not a distro maintainer... hopefully

[mittorn]

Last time, i tried to use AUR, it failed to build python2. Not because build failed, but because of broken checks. AUR tries to build it with LTO/PGO enabled, which takes hours... Just to fail checks!
Why it's OK to have unbuildable at all packages in AUR, but not ok to have aarch64-only packages???

[Quackdoc]

Last time, i tried to use AUR, it failed to build python2. Not because build failed, but because of broken checks. AUR tries to build it with LTO/PGO enabled, which takes hours... Just to fail checks!
Why it's OK to have unbuildable at all packages in AUR, but not ok to have aarch64-only packages???

did you modify your makepkg? all packages should be able to be built in a clean chroot, if not it should be reported, and if continues not to be it will be removed, that being said, are you sure it uses PGO? LTO I can see if you enabled it in makepkg.conf but I dont think it should use pgo

[Vermilion]

How do they get away with straight-up Arch branding while not being a part of Arch?

By asking for permission from the original project. From ALARM website footer:

The Arch Linux™ name and logo are used under permission of the Arch Linux Project Lead.

[Vermilion]

As far as I know, the rule has been around for a while. Maybe I am mistaken or took a different rule out of context. Perhaps fex-emu pkgbuild predated that however I don't believe so.

Check the wiki history.

I think you are misunderstanding what "political" means. politics as in policies.

I usually avoid diverting discussions into linguistics, but no, the adj from 'policy' is still 'policy', not politics (e.g. policy framework != political framework). Two different words that have different roots (Greek 'politikos' vs Latin 'polita').

[Quackdoc]

Check the wiki history.

I usually avoid diverting discussions into linguistics, but no, the adj from 'policy' is still 'policy', not politics (e.g. policy framework != political framework). Two different words that have different roots (Greek 'politikos' vs Latin 'polita').

Im not talking about etymoligy. Policies are set by politics, politics being the governance of an organization.

[Dukenukemx]

Linux users being upset at arch linux only supporting it's officially supported platform is hilarious. "How dare you not support this thing you never officially supported!" lol

All 5 Linux users on ARM are upset about that.

I don't understand the current hype around ARM. Historically ARM has always been the e-waste ISA with FOSS hostile vendors and mostly proprietary ecosystem with zero standards. No UEFI, no ACPI, no sane boot process, unless it's one of those ARM server ready boards. It's all garbage.

The reason why Microsoft and Apple want to go ARM is to make an ecosystem that they control alone. What little advantage ARM had is now gone. Go ARM and you lose performance compared to x86 while also losing application compatibility. Not to forget no UEFI and etc.

And why the hype for RISC-V? Is there anything to prevent vendors to do the same shit? Proprietary drivers, fucking device trees and special sauce firmware.

The problem with computing is someone always has an ideology, that they want you to enforce with zero benefits.

And Qualcomm does not exactly have a good track record. I would hope Intel or AMD comes to the rescue and develop sane platforms for either ARM or RISC-V, where you can boot just about any OS on any hardware.

There's no reason to continue to support ARM. AMD has proven that x86 can be just as efficient if not more so than ARM. Once AMD and Intel dump 32-bit and switch over to x86S then there's less than zero reasons to support ARM. Leave ARM to the mess that is the Android device market. Maybe when ARM enforces a UEFI or some sort of universal boot loader we can take another look at ARM.

[mittorn]

did you modify your makepkg? all packages should be able to be built in a clean chroot, if not it should be reported, and if continues not to be it will be removed, that being said, are you sure it uses PGO? LTO I can see if you enabled it in makepkg.conf but I dont think it should use pgo

I did not touch makepkg. It seems, AUR python2 is old python2 pkgbuild that used in Arch before it was removed, with many many checks and optimizations enabled, which do not pass on modern system
But same time, in gentoo python2 builds and runs fine, so i can use legacy software. Now i replaced arch system by Gentoo, but i wondering why AUR removes working arm-only pkgbuilds, but keeps broken unmaintained legacy

[Quackdoc]

But same time, in gentoo python2 builds and runs fine, so i can use legacy software. Now i replaced arch system by Gentoo, but i wondering why AUR removes working arm-only pkgbuilds, but keeps broken unmaintained legacy

they don't. It will need to be reported by someone and then removed.