5.16 is the correct version, see
https://www.kernel.org/category/releases.html
5.16 will probably be released late January next year.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraprojec
On Friday, December 3, 2021 7:25:19 AM CET Kamil Dudka wrote:
> On Friday, December 3, 2021 12:33:58 AM CET Sérgio Basto wrote:
> > On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote:
> > > On 12/2/21 15:08, Sérgio Basto wrote:
> > > > I didn't understood . What is the difference for /lib64/ld-2.
On Do, 02.12.21 19:38, Florian Weimer (fwei...@redhat.com) wrote:
> It would go into glibc-common on x86-64, and the initial version won't
> be able to launch 32-bit programs (“wrong ELF class: ELFCLASS32”).
"the initial version"? That phrasing makes me wonder, what longer term
plans do you have
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-35-20211202.0):
ID: 1076343 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
> The signature size is roughly proportional to the number of files in
> the package.
Can you explain how the signature is performed? I assume that the verity
top-level hash is calculated for each file and then … ?
And if you have all the per-file hashes, why not do one more level of
Merkle and cal
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-34-20211202.0):
ID: 1076359 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
On Thursday, 02 December 2021 at 21:18, Sebastian Crane wrote:
> Dear Diego,
>
> Welcome! I'm also new to the Fedora community, so maybe we can share
> notes at some point :)
Welcome, both of you.
> As you're interested in packaging open source games for Fedora, I'll
> invite you to an IRC chann
On Thursday, December 2, 2021 9:07:06 PM CET Aleksei Bavshin wrote:
> `smallbitvec` deps are only needed for benchmark, so the test suite is
> actually passing without these. Should be safe to drop with metadata patch.
>
> rust-tiny_http 0.8.2 also has a benchmark-only dependency `fdlimit`
> whi
On 02/12/2021 20:36, Ben Cotton wrote:
Enable the use of fsverity for installed RPM files validation.
-1. RPM already supports files validation and this feature will waste
file system space.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
__
Announcing the creation of a new nightly release validation test event
for Fedora 36 Rawhide 20211203.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki
Dne 02. 12. 21 v 17:04 Ben Cotton napsal(a):
On Thu, Dec 2, 2021 at 11:02 AM Jiri Konecny wrote:
we (Anaconda team) have decided to migrate our old
anaconda-devel-l...@redhat.com mailing list under Fedora. This decision
was made to be closer to community and more discoverable in the Fedora
wo
OLD: Fedora-Rawhide-20211201.n.0
NEW: Fedora-Rawhide-20211203.n.0
= SUMMARY =
Added images:1
Dropped images: 0
Added packages: 5
Dropped packages:4
Upgraded packages: 149
Downgraded packages: 0
Size of added packages: 389.89 KiB
Size of dropped packages
* Kamil Dudka:
> On Friday, December 3, 2021 7:25:19 AM CET Kamil Dudka wrote:
>> On Friday, December 3, 2021 12:33:58 AM CET Sérgio Basto wrote:
>> > On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote:
>> > > On 12/2/21 15:08, Sérgio Basto wrote:
>> > > > I didn't understood . What is the diffe
* Lennart Poettering:
> On Do, 02.12.21 19:38, Florian Weimer (fwei...@redhat.com) wrote:
>
>> It would go into glibc-common on x86-64, and the initial version won't
>> be able to launch 32-bit programs (“wrong ELF class: ELFCLASS32”).
>
> "the initial version"? That phrasing makes me wonder, what
On Thu, Dec 2, 2021 at 11:27 PM Reon Beon via devel <
devel@lists.fedoraproject.org> wrote:
> https://src.fedoraproject.org/rpms/phoronix-test-suite/pull-request/3
This is unfortunate and as much as I hate doing it sometimes you have to
"ping" people. They might have seen it initially but got bu
On Fri, Dec 3, 2021 at 7:15 AM Richard Shaw wrote:
> On Thu, Dec 2, 2021 at 11:27 PM Reon Beon via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> https://src.fedoraproject.org/rpms/phoronix-test-suite/pull-request/3
>
>
> This is unfortunate and as much as I hate doing it sometimes you have
On Fri, Dec 3, 2021 at 8:21 AM Richard Shaw wrote:
>
> On Fri, Dec 3, 2021 at 7:15 AM Richard Shaw wrote:
>>
>> On Thu, Dec 2, 2021 at 11:27 PM Reon Beon via devel
>> wrote:
>>>
>>> https://src.fedoraproject.org/rpms/phoronix-test-suite/pull-request/3
>>
>>
>> This is unfortunate and as much as
On Thu, Dec 2, 2021 at 11:05 AM Stephen Gallagher wrote:
>
> On Thu, Dec 2, 2021 at 7:00 AM wrote:
> >
> > Dear all,
> >
> > You are kindly invited to the meeting:
> >ELN SIG on 2021-12-03 from 12:00:00 to 13:00:00 US/Eastern
> >At fedora-meet...@irc.libera.chat
> >
> > The meeting will b
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
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
Perhaps I glossed over it in the description, but what is the expected user
experience in the event of a RPM fs-verity mismatch/error?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject
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
No missing expected images.
Compose FAILS proposed Rawhide gating check!
1 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 5/208 (x86_64), 8/142 (aarch64)
New failures (same test not failed in Fedora-Rawhide-2021
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. 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 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: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
There was an update [1] to libjxl that appears to have broken some dependencies
(gimp-jxl-plugin, jxl-pixbuf-loader, libaom, etc.).
I'm not sure if the negative karma is helpful, since this update has already
been pushed to stable a few days ago.
What is the proper procedure to escalate this?
Hi Steven,
Am 03.12.21 um 16:19 schrieb Steven A. Falco:
There was an update [1] to libjxl that appears to have broken some
dependencies (gimp-jxl-plugin, jxl-pixbuf-loader, libaom, etc.).
I'm not sure if the negative karma is helpful, since this update has already
been pushed to stable a few
F35 updates has libaom-3.2.0-2 and libjxl-0.6.1-6 already - so did the
buildroot go through?
(This conflicts with heif from rpmfusion, which I can't complain about here, of
course.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Am 03.12.21 um 16:19 schrieb Steven A. Falco:
What is the proper procedure to escalate this? Should I create a bug?
Either create a bug or write to this mailing list (as you did).
I use bodhi only to give simple feedback or post easy workarounds. The interface
is not suitable for discussion
On Fri, Dec 03, 2021 at 08:45:05AM -0500, Stephen Gallagher wrote:
> On Thu, Dec 2, 2021 at 11:05 AM Stephen Gallagher wrote:
> >
> > On Thu, Dec 2, 2021 at 7:00 AM wrote:
> > >
> > > Dear all,
> > >
> > > You are kindly invited to the meeting:
> > >ELN SIG on 2021-12-03 from 12:00:00 to 13:0
On Fri, Dec 03, 2021 at 08:25:45AM -0500, Neal Gompa wrote:
> On Fri, Dec 3, 2021 at 8:21 AM Richard Shaw wrote:
> >
> > On Fri, Dec 3, 2021 at 7:15 AM Richard Shaw wrote:
> >>
> >> On Thu, Dec 2, 2021 at 11:27 PM Reon Beon via devel
> >> wrote:
> >>>
> >>> https://src.fedoraproject.org/rpms/ph
On Thu, Dec 02, 2021 at 02:58:52PM +0100, Florian Weimer wrote:
> * Daniel P. Berrangé:
>
> >
> > The same srpm builds fine in F35 build roots, but fails in F36 build
> > roots with bizarre make errors. make appears to "loose" a bunch of
> > the rules in the makefile, despite them still actually
On Thu, Dec 02, 2021 at 03:00:54PM +0100, Florian Weimer wrote:
> * Daniel P. Berrangé:
>
> > Basically I'd like to try a build in koji with each of the glibc
> > versions in:
> > https://kojipkgs.fedoraproject.org/packages/glibc/2.34.9000/
> > to see if any one of those was the trigger.
>
> An
On Fri, 2021-12-03 at 15:36 +, Michael J Gruber wrote:
> F35 updates has libaom-3.2.0-2 and libjxl-0.6.1-6 already - so did
> the buildroot go through?
> (This conflicts with heif from rpmfusion, which I can't complain
> about here, of course.)
yes , buildroot go through , rpmfusion packages a
On Fri, Dec 3, 2021 at 11:13 AM Michel Alexandre Salim
wrote:
>
> On Fri, Dec 03, 2021 at 08:45:05AM -0500, Stephen Gallagher wrote:
> > On Thu, Dec 2, 2021 at 11:05 AM Stephen Gallagher
> > wrote:
> > >
> > > On Thu, Dec 2, 2021 at 7:00 AM wrote:
> > > >
> > > > Dear all,
> > > >
> > > > You a
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/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/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
The top-level hash is calculated for each file, then that hash is signed with
the inputted rsa key pair and the signed hash is appended to the array of
signed hashes in the rpm metadata. I am guessing the way we worded the proposal
is a little unclear because we call it "the" signature when it's
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 12/3/21 03:15, Andreas Schneider wrote:
On Thursday, December 2, 2021 9:07:06 PM CET Aleksei Bavshin wrote:
`smallbitvec` deps are only needed for benchmark, so the test suite is
actually passing without these. Should be safe to drop with metadata patch.
rust-tiny_http 0.8.2 also has a bench
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 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, 2021-12-03 at 12:21 +0100, Vitaly Zaitsev via devel wrote:
> On 02/12/2021 20:36, Ben Cotton wrote:
> > Enable the use of fsverity for installed RPM files validation.
>
> -1. RPM already supports files validation and this feature will waste
> file system space.
To clarify: RPM does suppor
I think there are two cases of interest:
1) a file or signature in the rpm is corrupted, the signature doesn't have a
matching cert installed, etc...
in this case, if the plugin is present, when you attempt to install the rpm the
verity enable ioctl will explicitly fail, and presumably so will t
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
`plocate` does not have an option which `mlocate` [1] has:
> -A, --all
>Print only names which match all non-option arguments, not
>those matching one or more non-option arguments.
The same could be achieved using extended regular expressions i.e.
`--regex`, but it's cumbersome.
Say I w
On Thu, 2021-12-02 at 20:05 -0500, Josh Boyer wrote:
> Yes, I saw that and I appreciate it. That's a comparison between the
> two implementations. I am asking about what benefits and use cases
> fs-verity solves in Fedora. Right now, the change simply says:
>
> "The main benefit is the ability
On Wed, Dec 01, 2021 at 02:06:41PM +0100, Miro Hrončok wrote:
> See
> https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/2OCCFIKT7LZ7IPO3OKIEH3TDTGERSORM/
>
> Would adding automatically generated obsoletes to 3624 Python packages have
> any observable negati
On Thu, 2021-12-02 at 19:10 -0500, Josh Boyer wrote:
> On Thu, Dec 2, 2021, 5:33 PM Davide Cavalca via devel
> wrote:
>
> > Correct, XFS doesn't support fs-verity at the moment (though it
> > could
> > be implemented if one wanted to).
>
> That means it would exclude Fedora Server and ELN as the
I omitted one more interesting case.
If the verity metadata (signature, root hash) is corrupted after installation
but before the file is opened, then opening/exec-ing the file can fail. Also,
if pages from a binary read in during the exec itself are corrupted, the system
call itself could fail
Hi,
On Fri, Dec 03, 2021 at 05:26:42AM -, Reon Beon via devel wrote:
> https://src.fedoraproject.org/rpms/phoronix-test-suite/pull-request/3
I've just put up an update for F35, please test
https://bodhi.fedoraproject.org/updates/FEDORA-2021-b353ab9902
Given this is a major upgrade from the
> I think there are two cases of interest:
>
> 1) a file or signature in the rpm is corrupted, the signature doesn't have a
> matching
> cert installed, etc...
> in this case, if the plugin is present, when you attempt to install the rpm
> the verity
> enable ioctl will explicitly fail, and pres
Errors at installation time should be fully diagnosable, and even if the output
today doesn't make it totally obvious what happened, it would be easy to fix in
rpm.
The errors post-install are a bit trickier. Imagine you install your rpm, and
kick off some long running daemon from it. A month l
We had an incident today [1] that opae-devel has auto-generated provides
like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
(/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so).
It was pulled into the buildroot instead of the expected openssl1
On 03. 12. 21 20:53, Zbigniew Jędrzejewski-Szmek wrote:
We had an incident today [1] that opae-devel has auto-generated provides
like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
(/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so).
It was
On Fri, Dec 3, 2021 at 3:10 PM Miro Hrončok wrote:
>
> On 03. 12. 21 20:53, Zbigniew Jędrzejewski-Szmek wrote:
> > We had an incident today [1] that opae-devel has auto-generated provides
> > like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
> > (/usr/lib/python3.10/site-pa
On 03/12/2021 20:53, Zbigniew Jędrzejewski-Szmek wrote:
My question: shouldn't we limit the elfdeps generator to files which
are in paths that can be loaded automatically by the linker? (This
could be implemented as e.g. the paths that are default like
/usr/lib64, /usr/local/lib64, …, depending o
On 03. 12. 21 21:10, Miro Hrončok wrote:
On 03. 12. 21 20:53, Zbigniew Jędrzejewski-Szmek wrote:
We had an incident today [1] that opae-devel has auto-generated provides
like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
(/usr/lib/python3.10/site-packages/pacsign/hsm_manag
On Fri, Dec 3, 2021 at 1:15 PM Davide Cavalca wrote:
>
> On Thu, 2021-12-02 at 19:10 -0500, Josh Boyer wrote:
> > On Thu, Dec 2, 2021, 5:33 PM Davide Cavalca via devel
> > wrote:
> >
> > > Correct, XFS doesn't support fs-verity at the moment (though it
> > > could
> > > be implemented if one want
Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> My question: shouldn't we limit the elfdeps generator to files which
> are in paths that can be loaded automatically by the linker? (This
> could be implemented as e.g. the paths that are default like
> /usr/lib64, /usr/local/lib64, …, dependin
On Fri, Dec 03, 2021 at 09:23:39PM +0100, Miro Hrončok wrote:
> On 03. 12. 21 21:10, Miro Hrončok wrote:
> >On 03. 12. 21 20:53, Zbigniew Jędrzejewski-Szmek wrote:
> >>We had an incident today [1] that opae-devel has auto-generated provides
> >>like libcrypto.so.1.1()(64bit), generated for the bund
On 03. 12. 21 22:01, Richard W.M. Jones wrote:
I don't follow this part of the original message. In, for example,
nbdkit-curl-plugin we have:
$ rpm -qf /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so
nbdkit-curl-plugin-1.29.6-1.fc36.x86_64
$ eu-readelf -d /usr/lib64/nbdkit/plugins/nbdkit-curl-p
On 03. 12. 21 21:46, Chris Adams wrote:
Also: why are you using a private bundled copy of OpenSSL? Isn't that
against the packaging guidelines?
Well, that is clearly a bug, that's why https://bugzilla.redhat.com/2028852 is
still open.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
__
On Fri, Dec 03, 2021 at 10:04:05PM +0100, Miro Hrončok wrote:
> On 03. 12. 21 22:01, Richard W.M. Jones wrote:
> >I don't follow this part of the original message. In, for example,
> >nbdkit-curl-plugin we have:
> >
> >$ rpm -qf /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so
> >nbdkit-curl-plugin
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. 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 Fri, Dec 03, 2021 at 06:08:49PM +, Davide Cavalca via devel wrote:
> Broadly speaking, fs-verity makes it possible to ensure that files that
> were installed via an RPM have not been modified. It is useful in
> environments where an attacker might be able to modify system files
> (say, repla
On Wed, Dec 01, 2021 at 04:53:20PM -0500, Colin Walters wrote:
>
>
> On Wed, Dec 1, 2021, at 4:34 PM, Chris Adams wrote:
> > Once upon a time, Colin Walters said:
> >> https://github.com/coreos/fedora-coreos-config/commit/eb74f2ea3e9b453902315539e4f327481162c4f8
> >
> > Missed this message earli
Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't
have anything urgent for this week. As a heads up, I'll be off work
from December 15 through Jan 3, so I'm planning to run a final meeting
for the year next week on December 13, then pick up again next year.
If you're aware of any
Could please you post the rawhide/36 version?
Thanks for your work.
___
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/
Le ven. 3 déc. 2021 à 17:17, Sérgio Basto a écrit :
>
> On Fri, 2021-12-03 at 15:36 +, Michael J Gruber wrote:
> > F35 updates has libaom-3.2.0-2 and libjxl-0.6.1-6 already - so did
> > the buildroot go through?
> > (This conflicts with heif from rpmfusion, which I can't complain
> > about her
74 matches
Mail list logo
