Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via or IRC
Bug 701082 - dev-qt/qtdeclarative-5.14.0_beta3::qt QA Notice: Excessive files found in the / partition
Summary: dev-qt/qtdeclarative-5.14.0_beta3::qt QA Notice: Excessive files found in the...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Overlays (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Qt Bug Alias
Depends on:
Reported: 2019-11-24 15:35 UTC by Duncan
Modified: 2020-08-27 18:37 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

emerge --verbose --info qtdeclarative (file_701082.txt,19.02 KB, text/plain)
2019-11-24 15:40 UTC, Duncan
full build log, xz compressed (dev-qt:qtdeclarative-5.14.0_beta3:20191124-150458.log.xz,66.66 KB, application/x-xz)
2019-11-24 15:48 UTC, Duncan

Note You need to log in before you can comment on or make changes to this bug.
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/, just not the tested ${D}${QT5_LIBDIR}/, 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?
Comment 4 Duncan 2020-08-27 09:33:08 UTC
Two update points since I was reviewing old still open bugs and then came across point #1 only about an hour later while working on a different bug:

1) This bug was very likely triggered by "relocatable qt", as described in

Starting with qt 5.14 (of which I was running a beta at the original report) qt can be built anywhere, and by default will look for all its components in two places:

1a) Where the executable is (useful for MS and other common lib-bundled-with-executable platforms).

1b) Where qtcore is found.

I asked earlier why the bug only appeared with 5.14-betas, not earlier versions.  The relocatable-qt intro in 5.14 is unlikely to be coincidence, and this qt 5.14-beta would have been the first one finding qtcore in my reverse-usrmerged /lib64 (either before looking in the symlinked /usr/lib64 or resolving the /usr -> . symlink to canonical path) and then using that path in later-built modules.

2) Given that I'm still running with the local patches I  was forced to apply to get 'round the bug as mentioned in comment #3, I'm unsure if the bug still exists with my current qt 5.15.0 or not.  I could of course check, but given it's nearing a year and multiple qt updates without even a comment since the bug was assigned to qt, not bothering unless/until someone decides it's worth further investigation, at which point I can check with a then-current qt, seems prudent.
Comment 5 Chiitoo gentoo-dev 2020-08-27 18:37:16 UTC
I certainly don't have any ideas regarding this at this time, but it might be worth noting that with Qt 6 the build system is changing to CMake, so indeed, whether or not this issue is still there with 5.15 might be at least somewhat irrelevant, unless of course it also happens with Qt 6 still.

At least it doesn't seem very widespread since no one else has commented or reported it still.

One can hope that it has been quietly fixed.  :]