From Fedora Project Wiki
Line 69: Line 69:


There is an update [http://kojipkgs.fedoraproject.org/packages/systemtap/1.6/1.fc15/src/systemtap-1.6-1.fc15.src.rpm 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.
There is an update [http://kojipkgs.fedoraproject.org/packages/systemtap/1.6/1.fc15/src/systemtap-1.6-1.fc15.src.rpm 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.


== crash ==
== crash ==

Revision as of 10:22, 13 September 2011

Shortcut:
Arch:ARM

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.

Problematic packages

See http://arm-temp.ausil.us/pub/fedora-arm/stage-4-failures.html for the list of pending packages that have not succeeded building

Please add notes regarding specific packages here. When completed move them down to Completed.

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

/bin/sh ../../libtool --silent --tag=CXX   --mode=link g++  -DNDEBUG -DNO_DEBUG -O2 -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -fno-exceptions -fno-check-new -fno-common  -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION  -L/usr/lib/qt-3.3/lib  -Wl,--as-needed -Wl,--enable-new-dtags  -no-undefined -version-info 3:0:2  -o libartskde.la -rpath /usr/lib libartskde_la.all_cc.lo libartskde_la.all_cpp.lo  ../../kio/libkio.la -lqtmcop -lsoundserver_idl
grep: /usr/lib/libgmodule-2.0.la: No such file or directory
/bin/sed: can't read /usr/lib/libgmodule-2.0.la: No such file or directory
make[3]: Leaving directory `/builddir/build/BUILD/kdelibs-3.5.10/arts/kde'

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

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?

kdelibs

Depends on soprano -> phonon

qt

An updated qt-4.7.3-6.fc15 was built somehow in stage3, but the -doc package was not included.

The same version fails to build from source in stage4.

The original qt-4.7.3-6.fc15 F15 release version fails with a problem related to mysql or openssl:

DEBUG util.py:247:  ERROR with rpm_check_debug vs depsolve:
DEBUG util.py:247:  openssl-devel(armv7hnl-32) is needed by mysql-devel-5.5.10-2.fc15.armv7hl
DEBUG util.py:247:  (1, [u'Please report this error in http://yum.baseurl.org/report'])

soprano

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

Depends on phonon (done)

mysql

mysql-5.5.10-2.fc15 fails with:

make[2]: /usr/bin/dtrace: Command not found

On x86_64 dtrace is included in systemtap-sdt-devel which is installed, but maybe not complete (stage3)

systemtap-sdt-devel

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.

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.'

Bug 734607 filed and fixed in crash-5.1.7-2 in (f17/rawhide).

emacs-vm

Locks up during build and never seems to finish, from the build.log:

+ make
make[1]: Entering directory `/builddir/build/BUILD/vm-8.1.1/lisp'
/bin/rm -f vm-autoloads.el
echo > vm-autoloads.el
(build_dir="`pwd`"; cd "."; \
 "emacs" -batch -q -no-site-file -no-init-file -l ./vm-build.el -l autoload \
        -f vm-built-autoloads "/builddir/build/BUILD/vm-8.1.1/lisp/vm-autoloads.el" "`pwd`")
Building autoloads file "/builddir/build/BUILD/vm-8.1.1/lisp/vm-autoloads.el"
...
"emacs" -batch -q -no-site-file -no-init-file -l ./vm-build.el -f batch-byte-compile vm-ps-print.el
Wrote /builddir/build/BUILD/vm-8.1.1/lisp/vm-ps-print.elc
"emacs" -batch -q -no-site-file -no-init-file -l ./vm-build.el -f batch-byte-compile vm-reply.el
Wrote /builddir/build/BUILD/vm-8.1.1/lisp/vm-reply.elc
"emacs" -batch -q -no-site-file -no-init-file -l ./vm-build.el -f batch-byte-compile vm-rfaddons.el
Loading vm-motion...
Loading /builddir/build/BUILD/vm-8.1.1/lisp/vm-summary.el (source)...

zziplib

Mainline FTBFS Bug #716062

Fails with

echo 'Cflags: -I${includedir}' >>zzipwrap.pc
/bin/sh ../libtool --silent --tag=CC   --mode=link gcc  -O2 -g -march=armv7-a
-mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -D_USE_MMAP -Wall -Wpointer-arith
-Wsign-compare -Wmissing-declarations -Wdeclaration-after-statement
-Werror-implicit-function-declaration -Wstrict-aliasing -Warray-bounds
-Wstrict-prototypes --export-dynamic -release 0 -version-info 13:59
-thread-safe  -o libzzipwrap.la -rpath /usr/lib wrap.lo ../zzip/libzzip.la   
/bin/sh ../libtool --silent --tag=CC   --mode=link gcc  -O2 -g -march=armv7-a
-mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -D_USE_MMAP -Wall -Wpointer-arith
-Wsign-compare -Wmissing-declarations -Wdeclaration-after-statement
-Werror-implicit-function-declaration -Wstrict-aliasing -Warray-bounds
-Wstrict-prototypes --export-dynamic  -o zzipwrap zzipwrap.o libzzipwrap.la   
gcc: error: unrecognized option '--export-dynamic'

The fix is most likely simply removing the --export-dynamic flag.


Completed

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.

Trying alternative dependency override by manually installing phonon using rpm

rm rpms/phonon-backend-gstreamer-4.5.1-1.fc15/*.log
mock -r fedora-15-armhfp --init --no-cleanup-after --result rpms/phonon-backend-gstreamer-4.5.1-1.fc15/
mock -r fedora-15-armhfp --result rpms/phonon-backend-gstreamer-4.5.1-1.fc15/ --installdeps rpms/phonon-4.5.0-2.fc15/phonon-4.5.0-2.fc15.src.rpm 
mock -r fedora-15-armhfp --result rpms/phonon-backend-gstreamer-4.5.1-1.fc15/ --copyin rpms/phonon-4.5.0-2.fc15/phonon-4.5.0-2.fc15.armv7hl.rpm builddir/
mock -r fedora-15-armhfp --result rpms/phonon-backend-gstreamer-4.5.1-1.fc15/ --chroot "rpm -i builddir/phonon-4.5.0-2.fc15.armv7hl.rpm --nodeps" 
mock -r fedora-15-armhfp --no-clean --no-cleanup-after --result rpms/phonon-backend-gstreamer-4.5.1-1.fc15/ SRPMS/phonon-backend-gstreamer-4.5.1-1.fc15.src.rpm

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