What happened to armhfp support? about termux-fedora HOT 8 OPEN

DOCKERIMAGE=https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Container/armhfp/images/Fedora-Container-Base-Rawhide-20190306.n.1.armhfp.tar.xz

from termux-fedora.

Install fd28_arm first,then run dnf update --releasever=29

from termux-fedora.

Try this https://github.com/MFDGaming/fedora-in-termux

from termux-fedora.

Starting from Fedora 29, they no longer provide the container base tar.xz file for armhfp architecture.

from termux-fedora.

One wonders WHY RedHat/Fedora no longer supports the container bas tar.xz format for armhfp. They do for aarch64, which has to represent a lot fewer phones/tablets than does armhfp. Seems like a ridiculous policy to me. With Fedora 29, I discovered some sites that suggested that armhfp was a "blocker" for F29. There are no such blocker suggestions for F30, yet no official release of armhfp in the proper container base tar.xz format is available. However, I did discover a "beta" of F30 in the correct format here:

https://dl.fedoraproject.org/pub/fedora/linux/development/30/Container/armhfp/images/Fedora-Container-Base-30-20190312.n.0.armhfp.tar.xz

This "works" with termux, but with some caveats:

1. dnf update will break dnf. To avoid this, do dnf update --exclude="dnf"
   Dnf had problems with armhfp and F27 and F28 under Termux, as well.
2. X fails. I can't run either startxfce4 or startlxde on either of my phones or tablet. With F24-F28 I could run LXDE, but not Xfce4.

On the positive side, a gcc compiler error that existed for F26-F28 has been fixed. I had code that compiles and works fine with every x86_64 flavor of Linux I've tried over the past 8 years. It also worked fine with F24 and F25 armhfp under Termux. Then with F26-F28 the code would compile, but crashed when run. Now, with the F30 "beta" on Termux, everything works fine with this code again. I have no idea what the problem could have been, but am glad it is fixed.

from termux-fedora.

By the way, the "upgrade" approach from F28 to F29 armhfp under Termux, suggested earlier, was a total disaster. Had to reinstall F28 from scratch. Now it's history, since I discovered an F30 that works (as documented above). Now, if only X worked... It fails in three different ways on my three Android devices (two different Androids on phones, one LineageOS on tablet) using XServer XSDL. On one phone, startxfce4 or startlxde simply return, with no apparent effect or error. On the other phone, activity occurs briefly (a mouse pointer) under XServer XSDL, but then it reverts to the blue screen, and Termux's Fedora run gets blown away - like it never existed. On the tablet, the same blowing away of Termux's Fedora run occurs, but XServer XSDL briefly shows either Xfce or LXDE screens before it dies; on the tablet, LXDE leaves the F30 background behind on XServer XSDL. WTF?

from termux-fedora.

Well,it's pretty much because Container format is actually tailored for edge servers that using ARM server chips running VMs. For this market segment, ARMv8 is the dominate architecture. And mainline kernel support for ARMv8 is a lot better than armhfp. We basically re-purpose the Container format as it happen to be the easiest one to run with proot.

Running in a proot environment on an Android has never been a target user scenario for Fedora. Despite of a lot of interests during my demonstration on FUDCon even today I can hardly find a very convincing user scenario to prompt it to an official method of distributed Fedora under the official umbrella.

from termux-fedora.

If anyone cares about this issue, the solution is simply to use Fedora Rawhide. Here is the setup to get the container image for armhfp. Do not use the Minimal version - it doesn't support dnf.
DOCKERIMAGE=https://dl.fedoraproject.org/pub/fedora/linux/developmen
t/rawhide/Container/armhfp/images/Fedora-Container-Base-Rawhide-20190306.n.1.arm
hfp.tar.xz

from termux-fedora.