Yeah I would like to fix those too but sudo is the one I encounter most. Also the existence of sudo-rs meant there was less push-back. I seriously doubt the maintainers of openssh or passwd would accept this change.
I was the only one who handed in a solution for that particular problem, it was scored 70 out of 100. I no longer have my solution, but I doubt that it was very accurate, and I didn't have time for experiments.
Debian ships Chromium on many architectures for a long time now, apparently. I never tried it outside of x86_64, so I can't say how usable it is. What am I missing? Is this about V8 JIT and widewine? Although those must be already supported on chromebooks, so I don't know.
Lists of architectures on oldstable (bookworm): amd64, arm64, armhf, i386, ppc64el
From where I stand it seems they enabled a build architecture for Chrome, but I don't think this required a lot of porting effort. Kudos for the official support though.
I'd guess that the issue is running the `%install` and `%check` stages of the .spec file. The Python library rpy (to pull a random example from Marcin's PRs) runs rpy's pytest test suite and had to be modified to avoid running vector tests on RISC-V.
Obviously a solvable problem to split build and test but perhaps the time savings aren't worth the complexity.
Maybe the tests could be run with user-mode qemu instead of the whole thing running under qemu or on RISC-V hardware. Could possibly be more or less seamless with binfmt_misc being set up in the builders.
Near as I know, Fedora prefers native compilation for the builds.
Your question made me look up Arm's history in Fedora and came up on this 2012 LWN thread[1]. There's some discussion against cross-compilation already back then.
Yocto, which we use at work, manages it just fine to build a whole embedded Linux distro. So I don't see why Fedora couldn't make it work if they wanted. You could even scp over the test suites to run that on native systems if you wanted.
Yocto manages it thanks to the tireless effort of a community of people maintaining patches and unholy hacks for a ton of software to make it cross compilable. And they have nowhere near the amount of recipes that Fedora has.
This is true, but the hacks are mostly in the C and C++ recipes as I understand it. Something like Rust or especially Go or Zig is far easier to cross compile.
I personally found cross compiling Rust easy, as long as you don't have C dependencies. If you have C dependencies it becomes way harder.
This suggests that spending time to upstream cross compilation fixes would be worth it for everyone, and probably even in the C world, 20% of the packages need 80% of the effort.
I value ctrl+U a lot more for password prompts than the visual feedback, it's even used by GUI on Linux.
reply