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
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
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
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
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.
> >
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
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
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.
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.
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
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
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
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
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
>
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,
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
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
17 matches
Mail list logo