Re: cmake on Rawhide is broken
Dne 03. 12. 21 v 19:07 Tom Hughes via devel napsal(a):
On 03/12/2021 17:48, Simo Sorce wrote:
On Fri, 2021-12-03 at 17:25 +, Tom Hughes via devel wrote:
On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote:
On 03/12/2021 17:41, Miro Hrončok wrote:
The bundled openssl in opae worries me still, but that's not causing
issues in dependency resolution any more.
I think FESCo should create a strict policy on bundling cryptographic
libraries.
Well bundling a binary from upstream is already against policy
so I don't see how that helps.
The problem isn't a lack of policy, it's that the packager didn't
notice those files or didn't realise they weren't allowed.
So the opae-2.0.0 tarball has libcrypto embedded-in what is the process
now ?
This stuff is used for a Python tool that is used to sign some binary,
almost certainly there is absolutely no reason to bundle libcrypto, the
tool should probably be unbundled and turned into a regular python
module opae depends on.
It has an openssl.py that dlopen's the so:
def _find_openssl_so(self, version, *paths):
candidates = list(paths)
crypto = util.find_library('crypto')
if crypto:
candidates.insert(0, crypto)
for c in candidates:
dll = CDLL(c)
So that might already find the system one if you have it
but probably only if you have openssl-devel installed to
get the .so link with no version.
But dropping the binaries and doing a relatively minor
patch to that is likely all that is needed.
Or just symlink ...
Vít
Do we know who is the current maintainer?
The changelog seem to imply Intel dropped it into Fedora and never
maintained it after Sep 17 2020 ...
Well src.fpo says trix aka Tom Rix is the maintainer.
Tom
OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On 03. 12. 21 18:41, Daniel P. Berrangé wrote: On Fri, Dec 03, 2021 at 05:41:31PM +0100, Miro Hrončok wrote: On 03. 12. 21 16:06, Miro Hrončok wrote: On 03. 12. 21 15:59, Miro Hrončok wrote: On 03. 12. 21 15:49, Miro Hrončok wrote: On 03. 12. 21 15:45, Kamil Dudka wrote: On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote: It seems that libarchive still requires libcrypto.so.1.1()(64bit) But on x86_64, opae-devel provides that with: ExclusiveArch: x86_64 I'll report that. https://bugzilla.redhat.com/show_bug.cgi?id=2028852 The problem is now fixed. The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more. Bundling pre-built openssl is a serious problem, because Fedora is required to strip various functionality from openssl at the source level. We cannot ship these binaries in the RPM, nor can we even have them in the source tarball AFAIK. IOW, stripping the dependancies from the RPM here is not sufficient. IIUC, the tarball needs to be unpacked, the openssl binaries removed, and a new tarball created for import into Fedora dist-git lookside archive storage. I agree. I applied the smallest possible bandaid to unblock other packagers, but the original cause of this problem remains to be solved by the package maintainers. Thta is why https://bugzilla.redhat.com/2028852 remains open. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On 03. 12. 21 18:48, Simo Sorce wrote: Do we know who is the current maintainer? The changelog seem to imply Intel dropped it into Fedora and never maintained it after Sep 17 2020 ... Tom Rix from Red Hat. Username trix. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On 03/12/2021 17:48, Simo Sorce wrote:
On Fri, 2021-12-03 at 17:25 +, Tom Hughes via devel wrote:
On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote:
On 03/12/2021 17:41, Miro Hrončok wrote:
The bundled openssl in opae worries me still, but that's not causing
issues in dependency resolution any more.
I think FESCo should create a strict policy on bundling cryptographic
libraries.
Well bundling a binary from upstream is already against policy
so I don't see how that helps.
The problem isn't a lack of policy, it's that the packager didn't
notice those files or didn't realise they weren't allowed.
So the opae-2.0.0 tarball has libcrypto embedded-in what is the process
now ?
This stuff is used for a Python tool that is used to sign some binary,
almost certainly there is absolutely no reason to bundle libcrypto, the
tool should probably be unbundled and turned into a regular python
module opae depends on.
It has an openssl.py that dlopen's the so:
def _find_openssl_so(self, version, *paths):
candidates = list(paths)
crypto = util.find_library('crypto')
if crypto:
candidates.insert(0, crypto)
for c in candidates:
dll = CDLL(c)
So that might already find the system one if you have it
but probably only if you have openssl-devel installed to
get the .so link with no version.
But dropping the binaries and doing a relatively minor
patch to that is likely all that is needed.
Do we know who is the current maintainer?
The changelog seem to imply Intel dropped it into Fedora and never
maintained it after Sep 17 2020 ...
Well src.fpo says trix aka Tom Rix is the maintainer.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On Fri, 2021-12-03 at 17:25 +, Tom Hughes via devel wrote: > On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote: > > On 03/12/2021 17:41, Miro Hrončok wrote: > > > > > The bundled openssl in opae worries me still, but that's not causing > > > issues in dependency resolution any more. > > > > I think FESCo should create a strict policy on bundling cryptographic > > libraries. > > Well bundling a binary from upstream is already against policy > so I don't see how that helps. > > The problem isn't a lack of policy, it's that the packager didn't > notice those files or didn't realise they weren't allowed. So the opae-2.0.0 tarball has libcrypto embedded-in what is the process now ? This stuff is used for a Python tool that is used to sign some binary, almost certainly there is absolutely no reason to bundle libcrypto, the tool should probably be unbundled and turned into a regular python module opae depends on. Do we know who is the current maintainer? The changelog seem to imply Intel dropped it into Fedora and never maintained it after Sep 17 2020 ... Simo. > Tom > > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On Fri, Dec 03, 2021 at 05:41:31PM +0100, Miro Hrončok wrote: > On 03. 12. 21 16:06, Miro Hrončok wrote: > > On 03. 12. 21 15:59, Miro Hrončok wrote: > > > On 03. 12. 21 15:49, Miro Hrončok wrote: > > > > On 03. 12. 21 15:45, Kamil Dudka wrote: > > > > > On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel > > > > > wrote: > > > > > > It seems that libarchive still requires libcrypto.so.1.1()(64bit) > > > > > > But on x86_64, opae-devel provides that with: > > > > > > ExclusiveArch: x86_64 > > > > > > I'll report that. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2028852 > > The problem is now fixed. The bundled openssl in opae worries me still, but > that's not causing issues in dependency resolution any more. Bundling pre-built openssl is a serious problem, because Fedora is required to strip various functionality from openssl at the source level. We cannot ship these binaries in the RPM, nor can we even have them in the source tarball AFAIK. IOW, stripping the dependancies from the RPM here is not sufficient. IIUC, the tarball needs to be unpacked, the openssl binaries removed, and a new tarball created for import into Fedora dist-git lookside archive storage. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On 03/12/2021 18:25, Tom Hughes wrote: Well bundling a binary from upstream is already against policy so I don't see how that helps. Yes, no pre-built binaries are allowed. The problem isn't a lack of policy, it's that the packager didn't notice those files or didn't realise they weren't allowed. I mean, FESCo should prohibit bundling of any cryptographic libraries because these libraries are the main source of critical vulnerabilities. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote: On 03/12/2021 17:41, Miro Hrončok wrote: The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more. I think FESCo should create a strict policy on bundling cryptographic libraries. Well bundling a binary from upstream is already against policy so I don't see how that helps. The problem isn't a lack of policy, it's that the packager didn't notice those files or didn't realise they weren't allowed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On 03/12/2021 17:41, Miro Hrončok wrote: The problem is now fixed. I can confirm. Many thanks. The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more. I think FESCo should create a strict policy on bundling cryptographic libraries. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On 03. 12. 21 16:06, Miro Hrončok wrote: On 03. 12. 21 15:59, Miro Hrončok wrote: On 03. 12. 21 15:49, Miro Hrončok wrote: On 03. 12. 21 15:45, Kamil Dudka wrote: On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote: Hello all. Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with libcrypto.so.1.1 and fails: + /usr/bin/cmake -S . -B redhat-linux-build -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release RPM build errors: /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Child return code was: 1 Affected Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927 Same issue with my build of cswrap. It is weird that it happens on x86_64 only: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725 This has surfaced by the last package in the default buildroot dropping the dependency on openssl1.1: https://bugzilla.redhat.com/show_bug.cgi?id=2022026#c7 I see more apps affected: sh-5.1$ cmake --help cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory sh-5.1$ appstream-util --help appstream-util: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory It seems that something still pulls in openssl1.1 on other architectures, e.g. in this build: https://koschei.fedoraproject.org/build/11634367 Both aarch64 and ppc64le have openssl1.1 in the root.log It seems that libarchive still requires libcrypto.so.1.1()(64bit) But on x86_64, opae-devel provides that with: ExclusiveArch: x86_64 I'll report that. https://bugzilla.redhat.com/show_bug.cgi?id=2028852 The problem is now fixed. The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On 03. 12. 21 15:59, Miro Hrončok wrote: On 03. 12. 21 15:49, Miro Hrončok wrote: On 03. 12. 21 15:45, Kamil Dudka wrote: On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote: Hello all. Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with libcrypto.so.1.1 and fails: + /usr/bin/cmake -S . -B redhat-linux-build -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release RPM build errors: /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Child return code was: 1 Affected Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927 Same issue with my build of cswrap. It is weird that it happens on x86_64 only: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725 This has surfaced by the last package in the default buildroot dropping the dependency on openssl1.1: https://bugzilla.redhat.com/show_bug.cgi?id=2022026#c7 I see more apps affected: sh-5.1$ cmake --help cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory sh-5.1$ appstream-util --help appstream-util: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory It seems that something still pulls in openssl1.1 on other architectures, e.g. in this build: https://koschei.fedoraproject.org/build/11634367 Both aarch64 and ppc64le have openssl1.1 in the root.log It seems that libarchive still requires libcrypto.so.1.1()(64bit) But on x86_64, opae-devel provides that with: ExclusiveArch: x86_64 I'll report that. https://bugzilla.redhat.com/show_bug.cgi?id=2028852 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On 03. 12. 21 15:49, Miro Hrončok wrote: On 03. 12. 21 15:45, Kamil Dudka wrote: On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote: Hello all. Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with libcrypto.so.1.1 and fails: + /usr/bin/cmake -S . -B redhat-linux-build -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release RPM build errors: /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Child return code was: 1 Affected Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927 Same issue with my build of cswrap. It is weird that it happens on x86_64 only: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725 This has surfaced by the last package in the default buildroot dropping the dependency on openssl1.1: https://bugzilla.redhat.com/show_bug.cgi?id=2022026#c7 I see more apps affected: sh-5.1$ cmake --help cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory sh-5.1$ appstream-util --help appstream-util: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory It seems that something still pulls in openssl1.1 on other architectures, e.g. in this build: https://koschei.fedoraproject.org/build/11634367 Both aarch64 and ppc64le have openssl1.1 in the root.log It seems that libarchive still requires libcrypto.so.1.1()(64bit) But on x86_64, opae-devel provides that with: ExclusiveArch: x86_64 I'll report that. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On 03. 12. 21 15:45, Kamil Dudka wrote: On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote: Hello all. Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with libcrypto.so.1.1 and fails: + /usr/bin/cmake -S . -B redhat-linux-build -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release RPM build errors: /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Child return code was: 1 Affected Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927 Same issue with my build of cswrap. It is weird that it happens on x86_64 only: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725 This has surfaced by the last package in the default buildroot dropping the dependency on openssl1.1: https://bugzilla.redhat.com/show_bug.cgi?id=2022026#c7 I see more apps affected: sh-5.1$ cmake --help cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory sh-5.1$ appstream-util --help appstream-util: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory It seems that something still pulls in openssl1.1 on other architectures, e.g. in this build: https://koschei.fedoraproject.org/build/11634367 Both aarch64 and ppc64le have openssl1.1 in the root.log -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote: > Hello all. > > Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with > libcrypto.so.1.1 and fails: > > + /usr/bin/cmake -S . -B redhat-linux-build > -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG > -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG > -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG > -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF > -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include > -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc > -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 > -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release > RPM build errors: > /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: > cannot open shared object file: No such file or directory > error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) > Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) > Child return code was: 1 > > Affected Koji build: > https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927 Same issue with my build of cswrap. It is weird that it happens on x86_64 only: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725 Kamil ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
On 03/12/2021 15:05, Omair Majid wrote: As a workaround, can you try a BuildRequires of `openssl1.1`? That should get the libraries and let cmake proceed. This is a dirty hack. You package can be linked with legacy openssl1.1 and introduce another compatibility issues. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: cmake on Rawhide is broken
Hi, Vitaly Zaitsev via devel writes: > /usr/bin/cmake: error while loading shared libraries: > libcrypto.so.1.1: cannot open shared object file: No such file or > directory As a workaround, can you try a BuildRequires of `openssl1.1`? That should get the libraries and let cmake proceed. My scratch build with the added BuildRequires: https://koji.fedoraproject.org/koji/taskinfo?taskID=79546890 Thanks, Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
cmake on Rawhide is broken
Hello all. Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with libcrypto.so.1.1 and fails: + /usr/bin/cmake -S . -B redhat-linux-build -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release RPM build errors: /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build) Child return code was: 1 Affected Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
