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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
