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 s
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 resolut
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 V
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 allo
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.
Wel
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 legac
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 fa
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-linu
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=-DN
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_
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
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 scr
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_M
17 matches
Mail list logo