4:59 a.m.
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