Re: Porting Fedora for the LoongArch architecture.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Porting Fedora to a new architecture is quite a challenge but a lot of
fun.  It sounds as if you've made a lot of progress already.  A few
thoughts from the Fedora/RISC-V effort ...

(1) Cross-compiling RPMs (eg. from x86-64 to LoongArch) isn't really
useful.  Almost any significantly complex RPM must be compiled on the
same architecture as it targets.  For example it may run tests or
tools that it builds as part of building the RPM.

For Fedora/RISC-V the problem was that we didn't have a viable Linux
environment to even run RPM on (in 2016), so I came up with a pretty
nasty bootstrapping hack, which cross-compiled enough of an
environment to be able to run rpmbuild.  For historical interest
that's here: https://github.com/rwmjones/fedora-riscv-bootstrap

However you won't need to use this.  There already exists a major
distro on LoongAch (ie. Debian).  You could use Debian to build a base
set of RPMs, and then once you have enough, install them into a
buildroot and continue using the Fedora you've built.

(I guess from your email that you've already done something like this.)

(2) noarch RPMs don't need to be compiled!  You can just copy them
from x86-64.  (At least for bootstrapping purposes, you'll want to be
able to compile them eventually.)  This is a nice time-saving tip to
remember.

(3) For RISC-V we didn't start with Koji (used our own hacky build
system), but did eventually set one up:
http://fedora.riscv.rocks/koji/

You'll also want to set up a Koji instance eventually.

(4) As another reply mentioned, to get LoongArch as a primary Fedora
architecture, an essential requirement is 19" rackable server-class
hardware.  It needs to be fully manageable through a BMC.  Fedora will
probably need a few such servers to be donated.

This is the main reason why RISC-V isn't a primary Fedora architecture
yet, although progress is happening.

(5) PLEASE PLEASE PLEASE get your patches upstream!  If they are
patches to the upstream software, send them to the upstream
maintainers.  If they are patches to the RPM builds, add them to
Fedora.  (People on this list can help with both these tasks.)

Getting stuff upstream benefits the whole community beyond Fedora, and
makes everyone's life easier.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux