Architectures/ARM/Fedora15 HardFP Bootstrap package status

We are currently engaged in bootstrap of support for armv7hl ("hardfp") ARM systems in Fedora. The purpose of this page is to track the individual status of packages (and their dependencies) that have been built for Fedora.

Known F15 issues

linux/videodev.h

hno: Hmm.. have quite many packages FTBFS with "fatal error: linux/videodev.h: No such file or directory".
kwizart: hno, they need to be converted to fully support v4l2
kwizart: but the workaround is to make them built with /usr/include/libv4l1-videodev.h from libv4l-devel and make them link with -lv4l1

Updates packages to build directly into ARM GA

If a F15 update is needed to solve an ARM-related problem that exists with the GA package, simply push that update into stage4 and note this (and the reasoning) under "Completed" below. When we come to do the koji build, the stage4 SRPMs will be used as a source, so there is no need to seperately record/list the packages that had to pulled in from updates.

clutter-gesture

available in stage3 only, NO SOURCES!

mainline FTBFS

gesture_recog.c: In function 'compute_ols':
gesture_recog.c:142:17: error: variable 'lyy' set but not used [-Werror=unused-but-set-variable]
gesture_recog.c:141:12: error: variable 's_s' set but not used [-Werror=unused-but-set-variable]
gesture_recog.c: In function 'gesture_process':
gesture_recog.c:804:11: error: variable 'point' set but not used [-Werror=unused-but-set-variable]

ecj

in stage 3 only

No obvious error in logs. Ends when calling ant. Rescheduled for build.

libdc1394

libgphoto2

libvpx

in stage 3 only

perl-Coro

in stage 3 only

perl-Tk

in stage 3 only

rrdtool

in stage 3 only

u-boot

in stage3 only

do not exists in F15.

uboot-tools exists in F15, build from u-boot sources. Here we should probably propose to make uboot-tools a subpackage of uboot. (If the idea is to provide u-boot images, as decision toward targeted hardware/boards is needed, references?)

w3m

in stage 3 only

xalan-j2

in stage 3 only

gtksourceview2

Mainline FTBFS with patches available but seems the maintainers are not responding.

libmpc

Pulled in version libmpc-0.8.3-0.4.svn855.fc15 from koji which avoids using -Werror.

nss

GA version fails tests on ARM. nss-3.12.10-6.fc15 pulled in from F15 updates to avoid this.

GA version also fails to build on Linux 3.0 host. Updates version may or may not face the same issue - armv5tel version built on Linux 2.6 host.

nspr

nspr-4.8.7-2.fc15 passes bad arguments to gcc and fails to compile. Fixed in nspr-4.8.8-4.fc15, pulled in from F15 updates.

uClibc

uClibc-0.9.32-2.fc15 pulled in from F15 updates (needed for busybox, GA version doesn't work right)

atlas

atlas-3.8.4-1.fc15 pulled in from F15 updates (first version with ARM support).

libtool

libtool-2.4-6.fc15 was pulled in from F15 updates for armv5tel as this is the version that works alongside gcc-4.6.1.

binutils

binutils-2.21.51.0.6-9.fc15 was pulled in from F15 updates to fix [1] (ghc and gcc build segfaults)

coreutils

Had trouble building coreutils-8.10-2.fc15 for armv5tel on koji2.laptop.org: it failed on tests/cp/fiemap-perf on "Nothing can read (much less write) that many bytes in so little time." More recent versions of coreutils fix this by skipping that test if the host filesystem is ext3 (which is the case on koji2, running Linux 3.1-rc7).

So, trying to avoid having to patch and bump coreutils in F15, I then tried to build this on an OLPC XO, which uses ext4 and runs Linux 3.0.0. This time, fiemap-perf passed but 5 gnulib readlink tests failed because the kernel returns EINVAL in a specific case where it never used to. Again, this test is fixed in more recent versions of coreutils, but in order to try and avoid patching the build, I patched in this kernel fix on my XO (still not upstream as of time of writing). The build then succeeded.

So the options for building this are:

Use a suitably old kernel (2.6.38 or older) and ext4 for the build, or

findutils

findutils includes gnulib so the readlink test failures noted in the coreutils section above apply exactly. findutils-4.5.9-3.fc15 built for armv5tel on OLPC XO with a patched kernel.

xerces-j2

in stage 3 only

zenity

in stage 3 only

usermode

in stage 3 only

tcl

in stage 3 only

ksh

in stage 3 only

systemtap

in stage 3 only

libtirpc

in stage 3 only

upower

upower-0.9.12-1.fc15 built without modification (post stage3-trim)

pinentry

pinentry-0.8.1-4.fc15 built without modification (post stage3-trim)

mesa

mesa-7.11-1.fc15 built without modification (post stage3-trim).

Not sure how, because the sis driver should get built, and that requires x86 or x86_64 before #713609 produced mesa-7.11-4.fc15 (F15 updates). Anyway, if it works it works! -Dsd 14:38, 8 October 2011 (UTC)

There is however mesa-dri-llvmcore left in stage3

gnome-bluetooth

gnome-bluetooth-3.0.1-1.fc15 built without modification (post stage3-trim)

PackageKit

Required changing src/pk-main.c to check version glib version 2,29,4 instead of 2,28,7. This later version is where glib-unix.h begins getting installed by glib2-devel.

mysql

mysql-home.patch: define DEFAULT_HOME_ENV
mysql-valist_fix.patch: Use a dummy va_list for client_plugin.c

Additionally, the perfschema.func_mutex and perfschema.func_file_io test cases were removed as they failed during build/test time. These should be investigated and a proper fix put in place.

could not find how the test cases were disabled in the spec file. 5.5.15 fails on the same two tests. Only the valist patch is needed. The DEFAULT_HOME_ENV patch is not needed. Hno 14:48, 10 October 2011 (UTC)

phonon

Have a circular dependency on it's backend providers. Main phonon package have been built but can not be installed as there is no backend providers, and blocks the backend providers from being built.

As the main package is already in stage4 the normal boostrap procedure of temporarily removing dependencies do not work well.

Resulting phonon-backend-gstreamer however depends on PackageKit-gstreamer-plugin which is not yet built..??

Another possible approach would have been to make a temporary phonon-backend-gstreamer-0.0.bootstrap package that only provides "phonon(backend}". This is probably recommended way of solving this kind of user experience runtime dependencies causing circular build dependencies.

systemtap-sdt

Was build in stage3 somehow.

Depends on crash-devel, which fails on ExclusiveArch check.

There is an update koji build which removes the dependency on crash. Now scheduled for build. First attempts crashed for unknown reasons, but after rescheduling it again it seems to be building.

Worked fine this time.

arts

Stray /usr/lib/*.la files packaged in the binary rpm with "bad" content. These files are both developer files and did contain further references to other unpackaged .la files in the stage3 build. Rebuilt in stage4 which cleaned up the contents of the .la files a bit, but strangely kdelibs3 still fails with the same error?

Turns out the .la files is supposed to be there for kde3. And the stage4 build contains the correct files.

The failure with same error even after arts was rebuilt was caused by yum picking the wrong repository. Using the fixed yum version and it works much better.

kdelibs3

kdelibs3 in F15 is FTBFS.

There is an updated kdelibs3-3.5.10-28.fc15 in which did succeed building in koji. This was never pushed as an update however and have already been cleaned by the koji garbage collector

Even the updated version fails to build on ARM but now with the following error

This seems to be caused by stray .la files which have been packaged in the arts binary rpm package (not even -devel). These stray .la files is seen even on the primary arches but contents seem to differ and build there succeeds.

arts have been rebuilt in stage4 and looks better. kdelibs3 build now suceeding

ARMv5tel: Unmodified gcc-4.6.1-9.fc15 built fine (GA version fails, this is an update to fix #697685 and #733549). Needed to be bootstrapped first without cloog (trivial spec change), then libtool compiled, then cloog, then gcc(unmodified). Done successfully.

soprano

Depends on qt-docs (why?) which were not included in the stage3 build.

Others having the same problem reports it fixed after rebuilding raptor and soprano. Trying. Noticeable is that both raptor and soprano uses Qt4 which was just rebuilt with both different compiler flags & version.

soprano & raptor rebuilt. New kdelibs build running.

crash

Fails on ExclusiveArch check.

There is an updated version which adds arm to the list of supported architectures (koji build), but not built in stage3 and never pushed as an official F15 update. The build have expired in koji and have been garbage collected.'

Running an mock build for testing. Should reach the failing point in some hours.

An interesting "hint" found in Debian:

+ ./configure --prefix=/usr `dpkg-architecture -qDEB_HOST_GNU_TYPE`
+ # * ARM: CLN's assembler support is not working properly (it was only
+ # 'theoretically' ported by copying from code that had once worked in
+ # CLISP under BSD). Same for armel.
+ # * HPPA: Assembler support is not working properly. Somebody needs to
+ # investigate but currently I don't have the inspiration for fixing
+ # things on exotic architectures.
+ # * SPARC: With some versions of GCC, there are apparently problems in
+ # passing return values in %g1.
+ case `dpkg-architecture -qDEB_HOST_ARCH` in \
+ arm|armel|hppa|sparc) \
+ ${MAKE} CPPFLAGS="-DNO_ASM" CXXFLAGS="-O2";; \
+ *) \

which is the fix for the debian bug report mentioned above. Why haven't the upstream been contacted to by default disable asm on these? This have been in Debian since 2001 (cln-1.0 something).

which almost matches Debian. The list above do not indicate known problems on linux/sparc, only solaris (sparc).

foomatic

Depends on itself.

Nicely commented in the spec how to bootstrap.

bootstrap version queued & built.

full version queued, but probably depends on other stuff as well not built yet.

seems to have built fine.

kdebase

KDE Core Applications

Depends on kdebase-workspace which depends on google-gadgets. google-gadgets is both mainline FTBFS and deprecated from F16+. There should be some hints by looking at how it's built on F16. May even be fixed by the updated versions in F15.

Alternatively convince google-gadgets to build again.

Discussed the topic with package owners. google-gadgets is dead, let it rest in piece. Rex Dieter have excluded google-gadgets on the arm platform in koji F15 build kdebase-workspace-4.6.5-6.fc15.

This requires all of KDE to be updated to 4.6.5. Downloaded to SRPMS/build/kde-4.6.5/ to be ready to queue them when kdebase is done.

Locally queued kdelibs, kdepimlibs, kdebase-workspace, kdebase, will queue the others when these are done.

Failed on kdebase-workspace again, this time due to missing libcln-devel.

llvm

ocaml

in stage 3 only

ocaml has two problems: First, the spec file has armv4 instead of %{arm}. Second, the configury does not enable the "natdynlink" feature for arm, so the list of installed files doesn't match the spec file's list. I have not determined if natdynlink works for arm, so I don't know whether the configury or the spec file need changing. [dj]

Processing files: ocaml-3.12.0-5.fc15.0.arm1.armv7hl
error: File not found by glob: /builddir/build/BUILDROOT/ocaml-3.12.0-5.fc15.0.arm1.arm/usr/lib/ocaml/*.cmxs

is this from the "natdynlink" mismatch mentioned above?

Yes, the files have different names if they're not the "natdynlink" style. [dj]

To bootstrap ocaml: In a suitable build environment (i.e. not mock), rpmbuild -bc ocaml.spec. This will eventually fail, but you'll have a boot/ocamlrun binary. If you don't already have a partial ocaml RPM, you can "make install" this build; if you do have a partial ocaml RPM, you still need to copy the just-built boot/ocamlrun to /usr/bin/ocamlrun. Then rpmbuild again.

testbuild of hscolour

Fix ExclusiveArch in hscolour.spec and attempt rebuilding it with --nodeps.

failed. Not sure why.

./Setup configure
./Setup build
sudo ./Setup install

works however. Closer inspection of the rpmbuild output shows that it's probably profiling related. The debian install do not have profiling libs. Digging a little in /etc/rpm/ghc.macros shows there is a without_prof define.

First had problems with GCC crashing on internal error, but the reason to that was that I had forgot to activate the right swap partition after a reboot between manual build and rpmbuild steps.

Then a little overoptimisic on the mainline patchwork. It seems the patch to use system provided libffi only works on platforms where ghci is supported. A bit unfortunate as it means we will be using a bundled copy instead of the system provided one. This should be looked into.

There is also some mention in the above bug report about Thumb2 not really being a supported platform for Qt.

Seems armv7 is not a supported platform either. Supported platforms are "Generic ARM" and "ARMv6", and ours gets detected as "Generic ARM". If QT had detected it as QT_ARHC_ARMV6 it probably would have worked. Later versions supposedly support ARMv7 as well.

python-pyblock

The issues with this package are discussed here. Needs a little upstream (anaconda team) intervention.

anaconda

anaconda-15.31-2.fc15.src.rpm in stage4 is a modified package which adds an ARM screen font (only for armv7, not for v5). It may be better to specify that ARM doesn't want a font (like S390 already). Resolution being tracked in #743429.

glibc

GA version suffers from various failures which are fixed by the updates version.

The armv7hl tree includes glibc-2.13.90-9.0.arm1.src.rpm with the following changes. The ones crossed out are no longer necessary in the F15 updates version.