[fedora-arm] Fedora 15 ARM hardfp status update & notes

Henrik Nordström henrik at henriknordstrom.net
Fri Sep 9 09:59:45 UTC 2011


Here comes a little status update from a fellow Fedora developer working
on the hardfp bootstrap.

The hardfp bootstrap is progressing quite well with currently

  3857 packages built (stage4)
  2063 packages left to build

both counted in number of source packages.


However, there have been som minor issues and shortcomings found in the
autoamted arm-rebuild.sh script, so if you are running this script then
please get an updated copy from
http://arm-temp.ausil.us/pub/fedora-arm/arm-rebuild.sh
and preferably also update yum by running "yum update yum yum-utils".
There is no rush in doing this and your build node will continue to
operate even if you don't do any of this but the quality of your results
improve if you do.


We are now nearing the end of the automatic brute force dependency
resolution, and next we need to get packages manually fixed to continue
the build.

Quite many of the failures are FTBFS in mainline F15 and then often have
a fixed package available. When there is a fixed package available for
F15 then feel free to grab that one and build it.

To quickly find if so is the case then open
http://admin.fedoraproject.org/pkgdb/acls/name/<packagename> and select
"Build status". If no fixed F15 build is seen then select "Bug reports"
instead and see if there is an existing FTBFS bug report open.

When you see that the package maintainer have fixed the build failure in
rawhide/F16 but not pushed fix to F15 then file a request to have the
fix pushed as an update to F15. You can use the following short template

    Description:
    <packagename> fails to build from source in F15, have been fixed in
F16/rawhide

    Text:
        Please push the <package-version> update to F15 as well. The
        current package in F15 fails to build and the armv7 bootstrap
        needs a working F15 source package to build from.


There is also a number of circular dependencies that need manual action
to bootstrap the packages. Many times it's sufficient to temporarily
disable some features in one package to allow the chain to be built.
Please remember to change Release 0.0.armbootstrap or similar when doing
so to avoid confusion with the full package.

Then there is also some FTBFS packages that have not been fixed in the
main repository. When seeing these try nagging the package maintainer(s)
a little extra on it by commenting in existing FTBFS bug reports etc.
But chances are high that the maintainer have gone unresponsive or that
the package is dead. If you see in the admin page above that the package
have been removed from F16 then it's probably not worth the effort to
investigate further.

If you can fix the issue yourself then please do so. When doing so
update Release to add .0.arm.1 after the %{?dist} tag to cleanly
differentiate the fixed package from mainline. I.e

from
        Release:        2%{?dist}
to
        Release:        2%{?dist}.0.arm.1

and file a bug report (or update existing FTBFS report) with your needed
package changes.

Over the next days I hope to provide more detailed information on
packages that need manual action, but I can name a couple that need some
love & care to bootstrap.

ghc
        The Haskell compiler. This needs a quite heavy manual bootstrap
        process as ghc is itself compiled by ghc. This bootstrap have
        quite recently been done for PPC64 so there is people who can
        help with advice and guidance. The primary idea is to leverage
        of the arm hardfp build available in debian to short-circuit the
        bootstrap.
    
PyQt4 <-> qscintilla
        Circular dependency that needs to be unwinded somehow.

at-spi2-core
        Depends on itself. See spec file for details. Should be a simple
        matter of temporarily disabling features.

kdelibs & kdelibs3
        both have been failing, blocking the whole of KDE. kdelibs due
        to dependency failures (may be resolved now) and kdelibs3 due to
        mainline FTBFS.
        
There is obviously many many more. If you need inspiration on finding
some candidates to work on or help resolving some related issue feel
free to ask in the #fedora-arm IRC channel.

It's probably a good idea to notify if you start working on some of the
more troublesome cases to avoid duplicated efforts.

It's obviously also a good idea to check the armv5tel repositories if
there is a fix there. But remember to file bug reports as above even
then.


And as always, and fixes you do to upstream package sources should be
reported upstream. That is the actual upstream, not just Fedora
bugzilla.


Regards
Henrik Nordström



More information about the arm mailing list