rawhide builds are built in bootstrap mode on purpose until the gcc5 mass rebuild happens.

*** Bug 1212750 has been marked as a duplicate of this bug. ***

%changelog
* Fri May 01 2015 Rex Dieter <rdieter> - 5.4.1-12
- backport a couple more upstream fixes
- introduce -common noarch subpkg, should help multilib issues
- drop bootstrap (#1211203)

- drop bootstrap (#1211203)

bit reverted, doc generation is (still) failing, will retry when (ongoing) gcc5 mass rebuild is done.

Tried again, fun, most builds still fail on i686, one succeeded,

http://koji.fedoraproject.org/koji/buildinfo?buildID=666333

then all subsequent i686 builds with docs enabled beyond that fail again :(

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Finally,

%changelog
* Wed Jul 15 2015 Rex Dieter <rdieter> 5.5.0-8
- %%build: hack around 'make docs' failures (on f22+)

now, seeing weird failure(s) on arm,

http://koji.fedoraproject.org/koji/taskinfo?taskID=10395868

and have a backtrace at least, but it's helpfulness is questionable:

+ gdb -q --eval-command=run '--eval-command=thread apply all bt' --eval-command=quit --args /builddir/build/BUILD/qtbase-opensource-src-5.5.0/bin/qdoc.orig -outputdir /builddir/build/BUILD/qtbase-opensource-src-5.5.0/doc/qtcore -installdir /usr/share/doc/qt5 /builddir/build/BUILD/qtbase-opensource-src-5.5.0/src/corelib/doc/qtcore.qdocconf -prepare -indexdir /builddir/build/BUILD/qtbase-opensource-src-5.5.0/doc -no-link-errors
Reading symbols from /builddir/build/BUILD/qtbase-opensource-src-5.5.0/bin/qdoc.orig...done.
Starting program: /builddir/build/BUILD/qtbase-opensource-src-5.5.0/bin/qdoc.orig -outputdir /builddir/build/BUILD/qtbase-opensource-src-5.5.0/doc/qtcore -installdir /usr/share/doc/qt5 /builddir/build/BUILD/qtbase-opensource-src-5.5.0/src/corelib/doc/qtcore.qdocconf -prepare -indexdir /builddir/build/BUILD/qtbase-opensource-src-5.5.0/doc -no-link-errors
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
Cannot parse expression `.L1046 4@r4'.
Thread 1 (process 12484):
#0  0xb6fd10b0 in dl_main () from /lib/ld-linux-armhf.so.3
#1  0xb6fe6670 in _dl_sysdep_start () from /lib/ld-linux-armhf.so.3
#2  0xb6fd23a8 in _dl_start () from /lib/ld-linux-armhf.so.3
#3  0xb6fcdb50 in _start () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
A debugging session is active.
	Inferior 1 [process 12484] will be killed.
Quit anyway? (y or n) [answered Y; input not from terminal]

The stack trace is unfortunately bogus, see the discussion about an identical backtrace:
https://bugzilla.redhat.com/show_bug.cgi?id=1222286#c3
The actual crash is different, but we cannot use GDB in Koji to produce the backtrace for us. Koji appears to be using VMs now, and according to the discussion in the other bug, GDB is broken in qemu-system-arm. So now I don't know how to get a usable backtrace.

One guess I have is that qdoc is using the wrong Qt (the installed one instead of the just built one), but should that matter?

Latest attempt at debugging this... running qdoc through valgrind during the build.

From,
http://koji.fedoraproject.org/koji/buildinfo?buildID=675943

We get this (which may or may not be helpful) in arm build.log:


==14891== 
==14891== Conditional jump or move depends on uninitialised value(s)
==14891==    at 0x401C014: index (in /usr/lib/ld-2.21.90.so)
==14891== 
==14891== Conditional jump or move depends on uninitialised value(s)
==14891==    at 0x401C018: index (in /usr/lib/ld-2.21.90.so)
==14891== 
==14891== Conditional jump or move depends on uninitialised value(s)
==14891==    at 0x4008B34: fillin_rpath (in /usr/lib/ld-2.21.90.so)
==14891==    by 0x4009357: _dl_init_paths (in /usr/lib/ld-2.21.90.so)
==14891== 
==14891== 
==14891== HEAP SUMMARY:
==14891==     in use at exit: 34,118 bytes in 232 blocks
==14891==   total heap usage: 6,006,976 allocs, 6,006,744 frees, 524,833,014 bytes allocated
==14891== 
==14891== LEAK SUMMARY:
==14891==    definitely lost: 4,224 bytes in 33 blocks
==14891==    indirectly lost: 7,174 bytes in 180 blocks
==14891==      possibly lost: 0 bytes in 0 blocks
==14891==    still reachable: 22,720 bytes in 19 blocks
==14891==         suppressed: 0 bytes in 0 blocks
==14891== Rerun with --leak-check=full to see details of leaked memory
==14891== 
==14891== For counts of detected and suppressed errors, rerun with: -v
==14891== Use --track-origins=yes to see where uninitialised values come from
==14891== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)

> backtrace for us. Koji appears to be using VMs now, and according to the

koji on ARM isn't using VMs. They're physical nodes

So the QEMU thing was probably a red herring, even in https://bugzilla.redhat.com/show_bug.cgi?id=1222286#c3 . There is an uninitialized variable being used, it's a typical random bug that can appear and disappear at random. It looks like we have a genuine glibc bug here.

We are also still seeing weird failures on F23 i686, maybe the same or a similar issue.

%changelog
* Wed Nov 18 2015 Helio Chissini de Castro <helio> - 5.5.1-9
- Get rid of valgrind hack. It sort out that we don't need it anymore (#1211203)