| 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: | Overlays | Assignee: | 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 |
||
Created attachment 597434 [details]
emerge --verbose --info qtdeclarative
Created attachment 597436 [details]
full build log, xz compressed
[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?
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 https://www.qt.io/blog/qt-is-relocatable 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. 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. :] I've ran into this as well with dev-qt/qtdeclarative-5.15.10-r2::gentoo. My setup links /usr/lib -> /lib. (In reply to Duncan from comment #4) > 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. (In reply to Vic Kerr (wikky) from comment #6) > I've ran into this as well with dev-qt/qtdeclarative-5.15.10-r2::gentoo. My > setup links /usr/lib -> /lib. I guess that answers /that/ question: Yes it still exists. But given... (In reply to Chiitoo from comment #5) > 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 ... We're certainly in "soon to be irrelevant" territory, particularly since kde/plasma is scheduled to do their irst qt6 release in February (previews starting in Dec IIRC), after which qt5 will likely go irrelevant pretty fast, altho it'll probably be another six months before full tree cleaning. Given the limited remaining time and that it has apparently only affected two people, both of which have done a "you're somewhat on your own with this" reverse-usrmerge (at least for /usr/lib(64) -> /lib(64)), it's likely not worth fixing at the gentoo level. The question then becomes... do you (VK) want me to post the patches I've used as workarounds? No use duplicating my work unnecessarily, but if you have other options and aren't going to pursue this further or in fact have already done your own patches... |
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*