[opensuse-factory] Dependencies of python3-qt5-devel, hplip build failures for ppc64 and armv7l
Hi, the hplip build fails on openSUSE:Factory:PowerPC because of the following dependency change: hplip (buildreq) -> python3-qt5-devel -> libqt5-qttools-devel -> libqt5-qttools-doc -> clang = 8.0.0 ... because clang is unavailable on ppc64. Likewise, the following chain breaks the build on armv7l: hplip (buildreq) -> python3-qt5-devel -> libqt5-qtwebengine-devel -> libavcodec58 -> libdav1d.so.1 It seems that I can fix my build using #!BuildIgnore. Yet I'd like to question whether these are really hard dependencies. Is it reasonable to require libavcodec to be installed in order to compile for Qt5? Regards, Martin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Martin, Am 27.08.19 um 15:53 schrieb Martin Wilck:
Hi,
the hplip build fails on openSUSE:Factory:PowerPC because of the following dependency change:
hplip (buildreq) -> python3-qt5-devel -> libqt5-qttools-devel -> libqt5-qttools-doc -> clang = 8.0.0
... because clang is unavailable on ppc64.
Clang should be available, the issue is probably the "= 8.0.0" part, because we're at 8.0.1 now. It seems that libqt5-qttools doesn't build on ppc64 anymore. (Looks like an LTO issue.) I think that libqt5-qttools-doc only needs libclang8, the explicit dependency to clang8 should no longer be necessary. As for the other dependencies, I don't think you can break any of them, but I'm not an expert on Qt.
Likewise, the following chain breaks the build on armv7l:
hplip (buildreq) -> python3-qt5-devel -> libqt5-qtwebengine-devel -> libavcodec58 -> libdav1d.so.1
It seems that libqt5-qtwebengine doesn't build on PowerPC anymore, the spec file has # http://www.chromium.org/blink not ported to PowerPC ExcludeArch: ppc ppc64 ppc64le s390 s390x Best regards, Aaron -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mittwoch, 28. August 2019 23:18:29 CEST Aaron Puchert wrote:
Hi Martin,
Am 27.08.19 um 15:53 schrieb Martin Wilck:
Hi,
the hplip build fails on openSUSE:Factory:PowerPC because of the following dependency change:
hplip (buildreq) -> python3-qt5-devel -> libqt5-qttools-devel
-> libqt5-qttools-doc -> clang = 8.0.0
... because clang is unavailable on ppc64.
Clang should be available, the issue is probably the "= 8.0.0" part, because we're at 8.0.1 now. It seems that libqt5-qttools doesn't build on ppc64 anymore. (Looks like an LTO issue.)
I think that libqt5-qttools-doc only needs libclang8, the explicit dependency to clang8 should no longer be necessary. As for the other dependencies, I don't think you can break any of them, but I'm not an expert on Qt.
Thats only partially right - the comment above is still spot on: "# qdoc hardcodes clang include paths: boo#1109367, QTBUG-70687" The headers are no longer part of the the "clang" package, but are in libclang<soverversion> now, so the requires should be updated. On the other hand, both libqt5-qttools and libqt-qttools-doc should not be pulled in by the devel package, as the binary tools are not required when linking to the libraries. Especially as qdoc pulls in quite some more packages. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Hi Stefan, Am 29.08.19 um 01:50 schrieb Stefan Brüns:
On Mittwoch, 28. August 2019 23:18:29 CEST Aaron Puchert wrote:
I think that libqt5-qttools-doc only needs libclang8, the explicit dependency to clang8 should no longer be necessary. As for the other dependencies, I don't think you can break any of them, but I'm not an expert on Qt.
Thats only partially right - the comment above is still spot on: "# qdoc hardcodes clang include paths: boo#1109367, QTBUG-70687"
The headers are no longer part of the the "clang" package, but are in libclang<soverversion> now, so the requires should be updated.
The libclang dependency should be detected automatically though, so I think it can be removed entirely.
On the other hand, both libqt5-qttools and libqt-qttools-doc should not be pulled in by the devel package, as the binary tools are not required when linking to the libraries. Especially as qdoc pulls in quite some more packages.
That's quite possible. My thinking was that maybe qttools-doc uses libclang to generate some kind of documentation from C++ source code, and could thus be required for developers, but maybe that isn't it. Best regards, Aaron -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Samstag, 31. August 2019 00:51:28 CEST Aaron Puchert wrote:
Hi Stefan,
Am 29.08.19 um 01:50 schrieb Stefan Brüns:
On Mittwoch, 28. August 2019 23:18:29 CEST Aaron Puchert wrote:
I think that libqt5-qttools-doc only needs libclang8, the explicit dependency to clang8 should no longer be necessary. As for the other dependencies, I don't think you can break any of them, but I'm not an expert on Qt.
Thats only partially right - the comment above is still spot on: "# qdoc hardcodes clang include paths: boo#1109367, QTBUG-70687"
The headers are no longer part of the the "clang" package, but are in libclang<soverversion> now, so the requires should be updated.
The libclang dependency should be detected automatically though, so I think it can be removed entirely.
Have you read the bugreports linked above? Obviously not ... The automatic dependency only pulls in a specific major version (e.g. libclang.so.8), but binaries often compile in the path to the headers, which contains the full version (e.g. 8.0.1). A method to retrieve the path to the header files is only provided starting with with LLVM 9.
On the other hand, both libqt5-qttools and libqt-qttools-doc should not be pulled in by the devel package, as the binary tools are not required when linking to the libraries. Especially as qdoc pulls in quite some more packages.
That's quite possible. My thinking was that maybe qttools-doc uses libclang to generate some kind of documentation from C++ source code, and could thus be required for developers, but maybe that isn't it.
The devel package covers all parts of libqt5-qttools, but most packages only need the headers and libraries for compiling and linking. QDoc is only required to generate HTML help files from inline source documentation. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Am 31.08.19 um 01:21 schrieb Stefan Brüns:
The automatic dependency only pulls in a specific major version (e.g. libclang.so.8), but binaries often compile in the path to the headers, which contains the full version (e.g. 8.0.1). A method to retrieve the path to the header files is only provided starting with with LLVM 9.
I know, but it's a well known problem and there are solutions to that. (e.g. https://phabricator.kde.org/D15955 in KDevelop) Admittedly it's not ideal and Clang should have named their builtin header directory like GCC does, but I guess the ship has sailed on that. It might be a leftover from the times when Clang still had minor versions != 0. I'd be curious to know about the change in LLVM 9 that makes this easier because it doesn't seem to be mentioned in the release notes. Perhaps it should be mentioned there.
On the other hand, both libqt5-qttools and libqt-qttools-doc should not be pulled in by the devel package, as the binary tools are not required when linking to the libraries. Especially as qdoc pulls in quite some more packages. That's quite possible. My thinking was that maybe qttools-doc uses libclang to generate some kind of documentation from C++ source code, and could thus be required for developers, but maybe that isn't it. The devel package covers all parts of libqt5-qttools, but most packages only need the headers and libraries for compiling and linking. QDoc is only required to generate HTML help files from inline source documentation.
If libqt-qttools[-doc] contain no libraries needed by the -devel package, then maybe the package name is misleading? I guess there is some reason for this naming scheme, but we have this convention that libX-devel should depend on libX for all X. Best regards, Aaron -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 31.08.19 um 01:21 schrieb Stefan Brüns:
The devel package covers all parts of libqt5-qttools, but most packages only need the headers and libraries for compiling and linking. QDoc is only required to generate HTML help files from inline source documentation.
On second thought, it sounds very plausible that the -devel package should not depend on the -doc package. Best regards, Aaron -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2019-08-31 at 04:23 +0200, Aaron Puchert wrote:
Am 31.08.19 um 01:21 schrieb Stefan Brüns:
The devel package covers all parts of libqt5-qttools, but most packages only need the headers and libraries for compiling and linking. QDoc is only required to generate HTML help files from inline source documentation.
On second thought, it sounds very plausible that the -devel package should not depend on the -doc package.
That's the general point I was trying to make. IMO "Requires" for -devel packages should be used very conservatively. Only such packages should be pulled in that are positively, strictly necessary for *all* other packages that build against the given -devel package. For others (your -doc package, for example), it would be little effort to add them as an additional build dependencies to those spec files that actually need them during build. It would also be easily detected, because those packages would fail to build (in the example: once the -devel -> -doc dependency was removed). The benefit would be leaner build environments. Regards Martin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2019-08-31 at 04:23 +0200, Aaron Puchert wrote:
Am 31.08.19 um 01:21 schrieb Stefan Brüns:
The devel package covers all parts of libqt5-qttools, but most packages only need the headers and libraries for compiling and linking. QDoc is only required to generate HTML help files from inline source documentation.
On second thought, it sounds very plausible that the -devel package should not depend on the -doc package.
That's the general point I was trying to make. IMO "Requires" for -devel packages should be used very conservatively. Only such packages should be pulled in that are positively, strictly necessary for *all* other packages that build against the given -devel package. For others (your -doc package, for example), it would be little effort to add them as an additional build dependencies to those spec files that actually need them during build. It would also be easily detected, because those packages would fail to build (in the example: once the -devel -> -doc dependency was removed). The benefit would be leaner build environments. Regards Martin N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On 9/2/19 6:00 PM, Martin Wilck wrote:
On Sat, 2019-08-31 at 04:23 +0200, Aaron Puchert wrote:
Am 31.08.19 um 01:21 schrieb Stefan Brüns:
The devel package covers all parts of libqt5-qttools, but most packages only need the headers and libraries for compiling and linking. QDoc is only required to generate HTML help files from inline source documentation.
On second thought, it sounds very plausible that the -devel package should not depend on the -doc package.
That's the general point I was trying to make. IMO "Requires" for -devel packages should be used very conservatively. Only such packages should be pulled in that are positively, strictly necessary for *all* other packages that build against the given -devel package.
For others (your -doc package, for example), it would be little effort to add them as an additional build dependencies to those spec files that actually need them during build. It would also be easily detected, because those packages would fail to build (in the example: once the -devel -> -doc dependency was removed).
The benefit would be leaner build environments.
I guess you could make the argument that the primary use case for -devel packages could be to allow developers / users to write new applications using the library / toolkit etc and as such atleast recommending the development documentation makes sense. But I agree that a definition that leads to smaller build environments makes more sense. Although as a passing thought I wonder how much would fail / break, if we setup obs to ignore Recommends when setting up build roots. There are probably some evil autotools scripts out there doing autodetection that will silently drop features just because a header is no longer present. So I guess if someone did want to test it they'd have to do it in a separate staging with reproducible build checking enabled. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Montag, 2. September 2019 14:50:34 CEST Simon Lees wrote:
On 9/2/19 6:00 PM, Martin Wilck wrote:
On Sat, 2019-08-31 at 04:23 +0200, Aaron Puchert wrote:
Am 31.08.19 um 01:21 schrieb Stefan Brüns:
The devel package covers all parts of libqt5-qttools, but most packages only need the headers and libraries for compiling and linking. QDoc is only required to generate HTML help files from inline source documentation.
On second thought, it sounds very plausible that the -devel package should not depend on the -doc package.
That's the general point I was trying to make. IMO "Requires" for -devel packages should be used very conservatively. Only such packages should be pulled in that are positively, strictly necessary for *all* other packages that build against the given -devel package.
For others (your -doc package, for example), it would be little effort to add them as an additional build dependencies to those spec files that actually need them during build. It would also be easily detected, because those packages would fail to build (in the example: once the -devel -> -doc dependency was removed).
The benefit would be leaner build environments.
I guess you could make the argument that the primary use case for -devel packages could be to allow developers / users to write new applications using the library / toolkit etc and as such atleast recommending the development documentation makes sense. But I agree that a definition that leads to smaller build environments makes more sense. Although as a passing thought I wonder how much would fail / break, if we setup obs to ignore Recommends when setting up build roots. There are probably some evil autotools scripts out there doing autodetection that will silently drop features just because a header is no longer present. So I guess if someone did want to test it they'd have to do it in a separate staging with reproducible build checking enabled.
libqt5-qttools-doc is not a documentation package, but the package for the "qdoc" binary (a tool similar to doxygen). After some fighting, libqt5-qttools-devel no longer Requires libqt5-qttools or libqt5-qttools-doc. There were two packages which failed - qscintilla-qt5 (which needed just the plugin directory ownership) and libqt5-qtdoc (building the Qt5 API documentation, i.e. actually requiring libqt5-qttools-doc). The -devel package still recommends libqt5-qttools and libqt5-qttools-doc, but the OBS already ignores Recommends for building. Regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2019-09-02 at 14:19 +0000, Brüns, Stefan wrote:
On Montag, 2. September 2019 14:50:34 CEST Simon Lees wrote:
On I guess you could make the argument that the primary use case for -devel packages could be to allow developers / users to write new applications using the library / toolkit etc and as such atleast recommending the development documentation makes sense. But I agree that a definition that leads to smaller build environments makes more sense. Although as a passing thought I wonder how much would fail / break, if we setup obs to ignore Recommends when setting up build roots. There are probably some evil autotools scripts out there doing autodetection that will silently drop features just because a header is no longer present. So I guess if someone did want to test it they'd have to do it in a separate staging with reproducible build checking enabled.
The -devel package still recommends libqt5-qttools and libqt5- qttools-doc, but the OBS already ignores Recommends for building.
Simotek says recommends are honoured, you say they're ignored ... I'm confused. I confess my ignorance about how this is designed to work. Martin
On 9/3/19 6:00 AM, Martin Wilck wrote:
On Mon, 2019-09-02 at 14:19 +0000, Brüns, Stefan wrote:
On Montag, 2. September 2019 14:50:34 CEST Simon Lees wrote:
On I guess you could make the argument that the primary use case for -devel packages could be to allow developers / users to write new applications using the library / toolkit etc and as such atleast recommending the development documentation makes sense. But I agree that a definition that leads to smaller build environments makes more sense. Although as a passing thought I wonder how much would fail / break, if we setup obs to ignore Recommends when setting up build roots. There are probably some evil autotools scripts out there doing autodetection that will silently drop features just because a header is no longer present. So I guess if someone did want to test it they'd have to do it in a separate staging with reproducible build checking enabled.
The -devel package still recommends libqt5-qttools and libqt5- qttools-doc, but the OBS already ignores Recommends for building.
Simotek says recommends are honoured, you say they're ignored ... I'm confused. I confess my ignorance about how this is designed to work.
If Stefan says there already ignored then id say he's right. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-09-02 20:30:07 +0000, Martin Wilck wrote:
On Mon, 2019-09-02 at 14:19 +0000, Brüns, Stefan wrote:
On Montag, 2. September 2019 14:50:34 CEST Simon Lees wrote:
On I guess you could make the argument that the primary use case for -devel packages could be to allow developers / users to write new applications using the library / toolkit etc and as such atleast recommending the development documentation makes sense. But I agree that a definition that leads to smaller build environments makes more sense. Although as a passing thought I wonder how much would fail / break, if we setup obs to ignore Recommends when setting up build roots. There are probably some evil autotools scripts out there doing autodetection that will silently drop features just because a header is no longer present. So I guess if someone did want to test it they'd have to do it in a separate staging with reproducible build checking enabled.
The -devel package still recommends libqt5-qttools and libqt5- qttools-doc, but the OBS already ignores Recommends for building.
Simotek says recommends are honoured, you say they're ignored ... I'm confused.
It depends on the project config. By default, recommends are ignored. Recommends are considered if you add "Expandflags: dorecommends" to your project config (osc meta -e prjconf <project>). Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2019-09-03 at 12:39 +0200, Marcus Hüwe wrote:
On 2019-09-02 20:30:07 +0000, Martin Wilck wrote:
On Mon, 2019-09-02 at 14:19 +0000, Brüns, Stefan wrote:
Simotek says recommends are honoured, you say they're ignored ... I'm confused.
It depends on the project config. By default, recommends are ignored. Recommends are considered if you add "Expandflags: dorecommends" to your project config (osc meta -e prjconf <project>).
That looks like something that might be worthwhile to add to https://en.opensuse.org/openSUSE:Build_Service_prjconf. (which is where I looked). Now that I know the flag, I found https://lists.opensuse.org/opensuse-buildservice/2013-03/msg00021.html Thanks, Martin
Am Mittwoch, 28. August 2019, 23:18:29 schrieb Aaron Puchert:
It seems that libqt5-qtwebengine doesn't build on PowerPC anymore, the spec file has
# http://www.chromium.org/blink not ported to PowerPC ExcludeArch: ppc ppc64 ppc64le s390 s390x
AFAIK, libqt5-qtwebengine (or chromium for that matter) *never* built on PowerPC in the first place... ;-) Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Aaron Puchert -
Brüns, Stefan -
Marcus Hüwe -
Martin Wilck -
Martin Wilck -
Simon Lees -
Stefan Brüns
-
Wolfgang Bauer