Bug 1211203 - qt-qtbase build without documentation
Summary: qt-qtbase build without documentation
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: qt5-qtbase
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2015-04-13 10:05 UTC by Anton Guda
Modified: 2015-11-25 13:38 UTC (History)
8 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-11-25 13:38:45 UTC


Attachments (Terms of Use)

Description Anton Guda 2015-04-13 10:05:27 UTC
Description of problem:
qt-qtbase build without documentation

Version-Release number of selected component (if applicable):
qt5-qtbase-5.4.1-[5-8]


How reproducible:
Always

Steps to Reproduce:
1. Look at qt5-qtbase packages list.
2. No documentation detected
3. Rebuild w/o touching spec - the same result.

Actual results:
No documentation package.
Addition problem - fail to update package, in old
doc package exists.

Expected results:
documentation package present.

Additional info:
Remove this lines from spec file:

%if 0%{?fedora} > 22
%global bootstrap 1
%endif

+ rebuild - works for me.

Comment 1 Rex Dieter 2015-04-13 10:11:47 UTC
rawhide builds are built in bootstrap mode on purpose until the gcc5 mass rebuild happens.

Comment 2 Rex Dieter 2015-04-17 12:52:42 UTC
*** Bug 1212750 has been marked as a duplicate of this bug. ***

Comment 3 Rex Dieter 2015-05-02 05:07:36 UTC
%changelog
* Fri May 01 2015 Rex Dieter <rdieter@fedoraproject.org> - 5.4.1-12
- backport a couple more upstream fixes
- introduce -common noarch subpkg, should help multilib issues
- drop bootstrap (#1211203)

Comment 4 Rex Dieter 2015-05-02 15:35:13 UTC
- drop bootstrap (#1211203)

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

Comment 5 Rex Dieter 2015-07-14 21:46:42 UTC
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 :(

Comment 6 Jan Kurik 2015-07-15 14:17:14 UTC
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

Comment 7 Rex Dieter 2015-07-16 14:03:55 UTC
Finally,

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

Comment 8 Rex Dieter 2015-07-18 03:06:13 UTC
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]

Comment 9 Kevin Kofler 2015-08-05 00:04:15 UTC
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?

Comment 10 Rex Dieter 2015-08-07 12:34:51 UTC
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)

Comment 11 Peter Robinson 2015-08-07 12:49:32 UTC
> 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

Comment 12 Kevin Kofler 2015-08-07 13:17:08 UTC
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.

Comment 13 Rex Dieter 2015-11-25 13:38:45 UTC
%changelog
* Wed Nov 18 2015 Helio Chissini de Castro <helio@kde.org> - 5.5.1-9
- Get rid of valgrind hack. It sort out that we don't need it anymore (#1211203)


Note You need to log in before you can comment on or make changes to this bug.