From Fedora Project Wiki
(llvm updates)
Line 45: Line 45:
| cxxtools || failing test "xmlserializer::testDouble: EXCEPTION" || menantea || [https://bugzilla.redhat.com/show_bug.cgi?id=1108800 1108800] || patch proposed ||
| cxxtools || failing test "xmlserializer::testDouble: EXCEPTION" || menantea || [https://bugzilla.redhat.com/show_bug.cgi?id=1108800 1108800] || patch proposed ||
|-
|-
| xorg-x11-apps and busybox || struct winsize not defined || hamzy || [https://bugzilla.redhat.com/show_bug.cgi?id=1122714 1122714] || should be fixed in glibc 2.20 ||
| <strike>xorg-x11-apps and busybox</strike> || struct winsize not defined || hamzy || [https://bugzilla.redhat.com/show_bug.cgi?id=1122714 1122714] || should be fixed in glibc 2.20 ||
|-
|-
|}
|}

Revision as of 07:05, 4 September 2014

Work Queue

This is the central point where work on build failures is organized, you can find here a list of failed builds, list of actual tasks and who works on them.

Failed builds

Tasks

  • higher on list mean higher prio
package problem who bugzilla notes resolved in build
llvm v3.5 doesn't like gcc 4.9 davids 1123103 1133508 Trying to solve the issue in glibc headers
mdadm FTBFS due bad format in printf 1125883 mdadm-3.3.1-6.fc21
mariadb tests failing on BE & LE ??? mtoman mariadb-10.0.12-7.fc21
R 3.1.1 doesn't build on LE 1136388 (R coredumps)
coreutils/findutils/gettext/augeas/... hanging test-lock from gnulib test-suite N/A isolated test case at http://jcajka.fedorapeople.org/gnulib-test-small.tar.gz
systemd missing ppc64le support in ver >= 215 N/A http://lists.freedesktop.org/archives/systemd-devel/2014-July/020884.html systemd-215-10.fc21
dyninst FTBFS on ppc64le sharkcz 1113991 dyninst-8.1.2-10.fc21
gperftools missing ppc64le support sharkcz update 2.2.1 gperftools-2.2.1-1.fc21
ceph OOM due too many CPUs and too few memory sharkcz run build on builder with only 4 or 6 CPUs online - added RFE for redhat-rpm-config
dbus-python test failing test fails on ppc64 only with latest buildroot dbus-python-1.2.0-5.fc21 rebuilt with pygobject3-3.13.3-1.fc21 in buildroot
libdb FTBFS with openjdk8 - http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1941862 jcajka 1119258 fails on all archs libdb-5.3.28-7.fc21
python3-cairo failing tests - http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1942017 jcajka probably the same problem was with pycairo python3-cairo-1.10.0-10.fc21
atlas missing ppc64le support michel_mno 1080073 still pending discussion upstream temporary build atlas-3.10.2-0.fc21.dh.1 until rebased by maintainer
erlang-rebar erlang-getopt erlang-erlydtl erlang-neotoma missing bootstrap michel_mno 1122088 I am not authorised to commit erlang-rebar all those packages have been bootstrapped and built
python FTBFS in primary - http://koji.fedoraproject.org/koji/taskinfo?taskID=7135864 - the maintainer is looking on it => root cause are changes in glibc and openssl glibc 1119769 we need a new build because python-2.7.7-2.fc21 uses the old libffi ABI on LE python-2.7.7-3.fc21 built
strace "failed to trace fstatat/fstatat64 properly" - http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1960025 sharkcz 1122323 strace-4.8-5.fc21
cxxtools failing test "xmlserializer::testDouble: EXCEPTION" menantea 1108800 patch proposed
xorg-x11-apps and busybox struct winsize not defined hamzy 1122714 should be fixed in glibc 2.20

Detailed plans

python (DONE)

  • http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1962223 which uses latest gcc-4.9.1-2.fc21 and glibc-2.19.90-30.fc21, but still fails on setegid test
  • plan agreed with Siddhesh
    • (DONE as glibc-2.19.90-31.fc22) he builds new glibc in rawhide and assures there is no problem in primary (i686), no builds in f21 until we are sure it works on all platforms
    • (DONE) we rebuild this one in f21 as scratch build - http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1964230
    • then rebuild python with it, mean a local mock build, on both ppc64 and ppc64le and wait for the result
      • if all OK, I'll forward the info to Siddhesh
      • if BAD, then we will work on isolating the failing test and give him access to the machine
      • isolating the test could mean rebuild without test suite to have the python binaries that can be then used to execute the test

Various notes

  • recently I have seen a stuck guile process (during build of graphviz-2.38.0-8.fc21 on ppc-le-builder2), very likely due the threading issue (waiting in futex), after attaching strace to the hung process, the process got unblocked