Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 701082

Summary: dev-qt/qtdeclarative-5.14.0_beta3::qt QA Notice: Excessive files found in the / partition
Product: Gentoo Linux Reporter: Duncan <1i5t5.duncan>
Component: OverlaysAssignee: Qt Bug Alias <qt>
Status: UNCONFIRMED ---    
Severity: normal CC: jstein
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: emerge --verbose --info qtdeclarative
full build log, xz compressed

Description Duncan 2019-11-24 15:35:21 UTC
This very likely has something to do with my "reverse usr-merge" layout:

/usr -> .

So what would normally be /usr/lib64/ canonically resolves to /lib64.  If something's canonically-resolving the path for, say qtcore, and trying to use that as the installation path for the static-lib *.a files, instead of installing them in the normal /usr/ path, that would result in installation to /lib64, which would of course trigger this QA warning in portage.

But why did several other dev-qt/* packages merge beyond qtcore, before qtdeclarative caused problems, and why didn't earlier versions of qtdeclarative (including the merged 5.13.2 that I'm trying to upgrade) trigger similar issues?

Here's the emerge pretend output for USE flags:


[ebuild     U  ] dev-qt/qtdeclarative-5.14.0_beta3:5/5.14::qt [5.13.2:5/5.13::gentoo] USE="jit widgets -debug -gles2 -localstorage -test" 0 KiB

And the error (full build log attached):

>>> Completed installing dev-qt/qtdeclarative-5.14.0_beta3 into /tmp/portage/dev-qt/qtdeclarative-5.14.0_beta3/image

* Final size of build directory: 323676 KiB (316.0 MiB)
* Final size of installed tree:   29336 KiB ( 28.6 MiB)

* 
* The ebuild is installing to one or more unexpected paths:
* 
*   /include
* 
* Please fix the ebuild to use correct FHS/Gentoo policy paths.

* QA Notice: Excessive files found in the / partition
* /tmp/portage/dev-qt/qtdeclarative-5.14.0_beta3/image/lib64/libQt5PacketProtocol.a
* /tmp/portage/dev-qt/qtdeclarative-5.14.0_beta3/image/lib64/libQt5QmlDebug.a
* /tmp/portage/dev-qt/qtdeclarative-5.14.0_beta3/image/lib64/libQt5QmlDevTools.a

* ERROR: dev-qt/qtdeclarative-5.14.0_beta3::qt failed:
*   static archives (*.a) and libtool library files (*.la) belong in /usr/lib*, not /lib*
Comment 1 Duncan 2019-11-24 15:40:11 UTC
Created attachment 597434 [details]
emerge --verbose --info qtdeclarative
Comment 2 Duncan 2019-11-24 15:48:15 UTC
Created attachment 597436 [details]
full build log, xz compressed
Comment 3 Duncan 2019-11-25 18:42:47 UTC
[Sorry, this feels like poorly explaining to the experts what I suspect they can better explain to me, but what do I leave out and still properly describe ...?]

The warning itself is of course a QA check from portage, found in (portage's) ${S}/bin/install-qa-check.d/80libraries (installed as /usr/lib/portage/$PYVER/install-qa-check.d/80libraries), lib_check function, in the "# Make sure people don't store libtool files or static libs in /lib" check, starting on line 155 in portage-2.3.79.

That check triggers the die on line 162 (again, in the portage file) with the "static archives ... belong in /usr/lib ..." die message that's the error above.

While that's normally fine and good, and does not *normally* trigger here because in the (pre-live-merge) fake-install image that it checks /usr continues to be a separate directory, which only happens to end up at the same libdir as / on my merged live system, obviously something's going wrong with the build system here and it's merging the dirs in the fake-install image as well, thereby triggering the die.

Unfortunately portage doesn't appear to have a QA_* var or the like I can set to bypass this and continue testing, so I ended up test-patching portage to change the die into a non-fatal QA_WARN.

That allowed me to test-bypass the warning and continue the install, not a real problem here since on my live system it's the same dir in any case.

Which allows me to finish merging all of qt-5.14.0-beta3 (with a few more such warnings due to the same bug in other qt packages, but the same fix should fix it in all I expect) that I need for what I have installed of kde, etc, EXCEPT for qtwebengine-5.14.0-beta3, which builds fine, but then ends up tripping over its bug #601472 check in src_install().

But unsurprisingly given this bug the file it's checking for is there, ${D}/lib64/libQt5WebEngine.so, just not the tested ${D}${QT5_LIBDIR}/libQt5WebEngine.so, where ${QT5_LIBDIR} apparently remains /usr/lib64 as it should be.

So apparently ${QT5_LIBDIR} remains correct, and the bug appears to be, as I said, something in the build system presumably detecting and using the live-system-canonical-path /lib64 instead of the standard /usr/lib64 that it's supposed to use (and that's apparently still correctly set in ${QT5_LIBDIR}, thereby triggering both portage's QA-check die that I patched out for testing as above, and the sanity check in the qtwebengine ebuild, which it appears I'll have to test-patch down to a warn to get the install done and actually run-time and downstream-dep-build-test the beta as well.

But I haven't (yet?) dived into the qt build system to figure out why it's bugging out; where is it wrongly detecting the live canonical path instead of using the settings its given and what to do to fix it?