Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2061584 - qemu-user-static needs to be broken into separate package per arch.
Summary: qemu-user-static needs to be broken into separate package per arch.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-03-07 22:24 UTC by Daniel Walsh
Modified: 2022-06-22 01:20 UTC (History)
15 users (show)

Fixed In Version: qemu-7.0.0-2.fc37 qemu-6.2.0-12.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-06-22 00:46:18 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
This patch breaks qemu-user-static into multiple arch packages. (deleted)
2022-05-25 13:56 UTC, Daniel Walsh
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Github coreos fedora-coreos-tracker issues 1088 0 None open New Package Request: qemu-user-static 2022-03-15 16:57:27 UTC

Description Daniel Walsh 2022-03-07 22:24:41 UTC
We want to have Fedora CoreOS ship qemu-user-static by default but currently it is too large and pulls in too many dependencies.

Could it be broken into qemu-user-static-arm64, qemu-user-static-amd65 ...
And potentially eliminate the requirement on python.

This would make it much smaller, and we could install just the arches that we want to support for multi-arch container builds.

Comment 2 Daniel Walsh 2022-04-28 18:02:09 UTC
Any comment on this?

Comment 3 Neal Gompa 2022-04-28 19:27:17 UTC
I don't think it's worth reducing the number of architectures, but what part of it is using Python?

Comment 4 Benjamin Gilbert 2022-05-03 03:32:56 UTC
AIUI the proposal isn't to reduce the number of architectures, but to split them into multiple subpackages.  The package as a whole is 150 MB, and most systems probably don't need e.g. qemu-m68k-static.

/usr/bin/qemu-trace-stap-static is a Python script.

Comment 5 Neal Gompa 2022-05-03 12:11:50 UTC
(In reply to Benjamin Gilbert from comment #4)
> AIUI the proposal isn't to reduce the number of architectures, but to split
> them into multiple subpackages.  The package as a whole is 150 MB, and most
> systems probably don't need e.g. qemu-m68k-static.
> 
> /usr/bin/qemu-trace-stap-static is a Python script.

That's a lot of subpackages:

ngompa@Belldandy-Slimbook ~> ls -hal /usr/bin/qemu-*
-rwxr-xr-x. 1 root root 5.9M Feb 10 16:12 /usr/bin/qemu-aarch64_be-static*
-rwxr-xr-x. 1 root root 5.9M Feb 10 16:12 /usr/bin/qemu-aarch64-static*
-rwxr-xr-x. 1 root root 3.4M Feb 10 16:12 /usr/bin/qemu-alpha-static*
-rwxr-xr-x. 1 root root 4.6M Feb 10 16:12 /usr/bin/qemu-armeb-static*
-rwxr-xr-x. 1 root root 4.6M Feb 10 16:12 /usr/bin/qemu-arm-static*
-rwxr-xr-x. 1 root root 3.4M Feb 10 16:12 /usr/bin/qemu-cris-static*
-rwxr-xr-x. 1 root root 5.5M Feb 10 16:12 /usr/bin/qemu-hexagon-static*
-rwxr-xr-x. 1 root root 3.5M Feb 10 16:12 /usr/bin/qemu-hppa-static*
-rwxr-xr-x. 1 root root 3.9M Feb 10 16:12 /usr/bin/qemu-i386-static*
-rwxr-xr-x. 1 root root 3.7M Feb 10 16:12 /usr/bin/qemu-m68k-static*
-rwxr-xr-x. 1 root root 3.5M Feb 10 16:12 /usr/bin/qemu-microblazeel-static*
-rwxr-xr-x. 1 root root 3.5M Feb 10 16:12 /usr/bin/qemu-microblaze-static*
-rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-mips64el-static*
-rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-mips64-static*
-rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-mipsel-static*
-rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-mipsn32el-static*
-rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-mipsn32-static*
-rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-mips-static*
-rwxr-xr-x. 1 root root 3.4M Feb 10 16:12 /usr/bin/qemu-nios2-static*
-rwxr-xr-x. 1 root root 3.4M Feb 10 16:12 /usr/bin/qemu-or1k-static*
-rwxr-xr-x. 1 root root 4.5M Feb 10 16:12 /usr/bin/qemu-ppc64le-static*
-rwxr-xr-x. 1 root root 4.5M Feb 10 16:12 /usr/bin/qemu-ppc64-static*
-rwxr-xr-x. 1 root root 4.4M Feb 10 16:12 /usr/bin/qemu-ppc-static*
-rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-riscv32-static*
-rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-riscv64-static*
-rwxr-xr-x. 1 root root 3.8M Feb 10 16:12 /usr/bin/qemu-s390x-static*
-rwxr-xr-x. 1 root root 3.5M Feb 10 16:12 /usr/bin/qemu-sh4eb-static*
-rwxr-xr-x. 1 root root 3.5M Feb 10 16:12 /usr/bin/qemu-sh4-static*
-rwxr-xr-x. 1 root root 3.6M Feb 10 16:12 /usr/bin/qemu-sparc32plus-static*
-rwxr-xr-x. 1 root root 3.6M Feb 10 16:12 /usr/bin/qemu-sparc64-static*
-rwxr-xr-x. 1 root root 3.5M Feb 10 16:12 /usr/bin/qemu-sparc-static*
-rwxr-xr-x. 1 root root 5.5K Dec 14 15:42 /usr/bin/qemu-trace-stap-static*
-rwxr-xr-x. 1 root root 3.9M Feb 10 16:12 /usr/bin/qemu-x86_64-static*
-rwxr-xr-x. 1 root root 6.4M Feb 10 16:12 /usr/bin/qemu-xtensaeb-static*
-rwxr-xr-x. 1 root root 6.4M Feb 10 16:12 /usr/bin/qemu-xtensa-static*

Comment 6 Daniel Berrangé 2022-05-03 14:57:44 UTC
(In reply to Neal Gompa from comment #5)
> (In reply to Benjamin Gilbert from comment #4)
> > AIUI the proposal isn't to reduce the number of architectures, but to split
> > them into multiple subpackages.  The package as a whole is 150 MB, and most
> > systems probably don't need e.g. qemu-m68k-static.
> 
> That's a lot of subpackages:
> 
> ngompa@Belldandy-Slimbook ~> ls -hal /usr/bin/qemu-*
> -rwxr-xr-x. 1 root root 5.9M Feb 10 16:12 /usr/bin/qemu-aarch64_be-static*

...snip...


That's the reason the system emulators are not fully split up one per target, but rather grouped into logically related archives. eg all the arm variants in the same package. Footprint is slightly larger but avoids a ridiculous number of RPMs.  eg


> -rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-mips64el-static*
> -rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-mips64-static*
> -rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-mipsel-static*
> -rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-mipsn32el-static*
> -rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-mipsn32-static*
> -rwxr-xr-x. 1 root root 4.2M Feb 10 16:12 /usr/bin/qemu-mips-static*

Could be in a 'qemu-user-mips' sub-RPM, instead of 6 separate sub-RPMs

Comment 7 Daniel Berrangé 2022-05-03 15:04:43 UTC
(In reply to Benjamin Gilbert from comment #4)
> /usr/bin/qemu-trace-stap-static is a Python script.

This looks like a silly mistake

In the RPM spec we have a loop:

  # Rename all QEMU user emulators to have a -static suffix
  for src in %{static_buildroot}%{_bindir}/qemu-*; do
    mv $src %{buildroot}%{_bindir}/$(basename $src)-static; done


which was adding the 'static' suffix to user emulators, but this wildcard accidentally matches  'qemu-trace-stap'

Comment 8 Brent Baude 2022-05-03 16:15:07 UTC
I like Daniel Berrange's idea to package them by arch.  I would even recommend a "fake" rpm package that installs them all.  This would preserve the origin behavior and allow arches to be installed only.

Comment 9 Daniel Walsh 2022-05-03 17:13:32 UTC
Sure qumu-user-static would install all of the subpackages.

But allow us to install qemu-user-x86-static and qemu-user-arm-static on Fedora CoreOS by default.

Comment 10 Neal Gompa 2022-05-03 17:33:01 UTC
(In reply to Daniel Walsh from comment #9)
> Sure qumu-user-static would install all of the subpackages.
> 
> But allow us to install qemu-user-x86-static and qemu-user-arm-static on
> Fedora CoreOS by default.

You'd want more than that. You'd also want qemu-user-power-static and qemu-user-s390-static because containers exist for those types too.

Comment 11 Daniel Berrangé 2022-05-03 18:05:28 UTC
Bogus python dep dropped in:

commit d8c4df3d29c5354c28ea5fe51546adaa3ad0f7b2
Author: Daniel P. Berrangé <berrange>
Date:   Tue May 3 18:58:58 2022 +0100

    Drop redundant qemu-trace-stap copy from qemu-user-static (rhbz#2061584)
    
    The static build of QEMU installs a copy of 'qemu-trace-stap' python
    script, which gets renamed to 'qemu-trace-stap-static' by an overly
    enthusiastic wildcard. This ends up adding a python dependency to
    the qemu-user-static RPM, which is unhelpful.
    
    Anyone who wants to trace QEMU user binaries with the stap helper
    can easily install qemu-common as desired.
    
I've not triggered a full rawhide build just for that change, just checked it via a scratch-build https://koji.fedoraproject.org/koji/taskinfo?taskID=86593853 to validate the python dep is gone

Comment 12 Daniel Berrangé 2022-05-03 18:09:29 UTC
(In reply to Neal Gompa from comment #10)
> (In reply to Daniel Walsh from comment #9)
> > Sure qumu-user-static would install all of the subpackages.
> > 
> > But allow us to install qemu-user-x86-static and qemu-user-arm-static on
> > Fedora CoreOS by default.
> 
> You'd want more than that. You'd also want qemu-user-power-static and
> qemu-user-s390-static because containers exist for those types too.

With the bundling per arch, that would end up meaning you'd have 40 MB, down from 140 MB:

$ du -h -c -s /usr/bin/qemu-*static | tail -1
139M	total

$ du -h -s -c /usr/bin/qemu-{i386,arm*,aarch64,s390x,x86_64,ppc*}-static  | tail
3.9M	/usr/bin/qemu-i386-static
4.4M	/usr/bin/qemu-armeb-static
4.4M	/usr/bin/qemu-arm-static
5.6M	/usr/bin/qemu-aarch64-static
3.8M	/usr/bin/qemu-s390x-static
3.9M	/usr/bin/qemu-x86_64-static
4.4M	/usr/bin/qemu-ppc64le-static
4.5M	/usr/bin/qemu-ppc64-static
4.4M	/usr/bin/qemu-ppc-static
39M	total

Comment 13 Daniel Berrangé 2022-05-03 18:14:08 UTC
(In reply to Daniel Berrangé from comment #11)
> Bogus python dep dropped in:

snip

> I've not triggered a full rawhide build just for that change, just checked
> it via a scratch-build
> https://koji.fedoraproject.org/koji/taskinfo?taskID=86593853 to validate the
> python dep is gone

Oh, but ultimately that doesn't help you're needs, because 'qemu-user-static' still depends on 'qemu-common' and that will pull in python already.

That dep on 'qemu-common' is arguably also somewhat bogus, or at least overkill, for qemu-user / qemu-user-static. I think the only thing in qemu-common that's actually relevant are the license file texts. Even the translations aren't needed as they're only used by the GTK frontend in system emulators

Comment 14 Dusty Mabe 2022-05-03 20:01:30 UTC
(In reply to Daniel Berrangé from comment #12)
> $ du -h -s -c /usr/bin/qemu-{i386,arm*,aarch64,s390x,x86_64,ppc*}-static  |
> tail
> 3.9M	/usr/bin/qemu-i386-static
> 4.4M	/usr/bin/qemu-armeb-static
> 4.4M	/usr/bin/qemu-arm-static
> 5.6M	/usr/bin/qemu-aarch64-static
> 3.8M	/usr/bin/qemu-s390x-static
> 3.9M	/usr/bin/qemu-x86_64-static
> 4.4M	/usr/bin/qemu-ppc64le-static
> 4.5M	/usr/bin/qemu-ppc64-static
> 4.4M	/usr/bin/qemu-ppc-static
> 39M	total


Nice.. I know Neal mentioned we would need s390x and ppc64le but I doubt we would actually add those in practice until some user demand existed for it. If we stated we only cared about x86_64 and aarch64 couldn't we get down to just qemu-x86_64-static and qemu-aarch64-static?


(In reply to Daniel Berrangé from comment #13)
> 
> Oh, but ultimately that doesn't help you're needs, because
> 'qemu-user-static' still depends on 'qemu-common' and that will pull in
> python already.
> 
> That dep on 'qemu-common' is arguably also somewhat bogus, or at least
> overkill, for qemu-user / qemu-user-static. I think the only thing in
> qemu-common that's actually relevant are the license file texts. Even the
> translations aren't needed as they're only used by the GTK frontend in
> system emulators

I know this is asking a lot, but is there a logical breakdown that could make sense for breaking out into yet another subpackage?

Comment 15 Neal Gompa 2022-05-03 22:26:20 UTC
(In reply to Dusty Mabe from comment #14)
> (In reply to Daniel Berrangé from comment #12)
> > $ du -h -s -c /usr/bin/qemu-{i386,arm*,aarch64,s390x,x86_64,ppc*}-static  |
> > tail
> > 3.9M	/usr/bin/qemu-i386-static
> > 4.4M	/usr/bin/qemu-armeb-static
> > 4.4M	/usr/bin/qemu-arm-static
> > 5.6M	/usr/bin/qemu-aarch64-static
> > 3.8M	/usr/bin/qemu-s390x-static
> > 3.9M	/usr/bin/qemu-x86_64-static
> > 4.4M	/usr/bin/qemu-ppc64le-static
> > 4.5M	/usr/bin/qemu-ppc64-static
> > 4.4M	/usr/bin/qemu-ppc-static
> > 39M	total
> 
> 
> Nice.. I know Neal mentioned we would need s390x and ppc64le but I doubt we
> would actually add those in practice until some user demand existed for it.
> If we stated we only cared about x86_64 and aarch64 couldn't we get down to
> just qemu-x86_64-static and qemu-aarch64-static?
> 

Since Fedora makes containers for those architectures, I would personally consider it problematic if you didn't ship them. And 40MB isn't going to hurt you.

> 
> (In reply to Daniel Berrangé from comment #13)
> > 
> > Oh, but ultimately that doesn't help you're needs, because
> > 'qemu-user-static' still depends on 'qemu-common' and that will pull in
> > python already.
> > 
> > That dep on 'qemu-common' is arguably also somewhat bogus, or at least
> > overkill, for qemu-user / qemu-user-static. I think the only thing in
> > qemu-common that's actually relevant are the license file texts. Even the
> > translations aren't needed as they're only used by the GTK frontend in
> > system emulators
> 
> I know this is asking a lot, but is there a logical breakdown that could
> make sense for breaking out into yet another subpackage?

There's already too many splits as it is... :(

Comment 16 Fedora Update System 2022-05-09 20:38:28 UTC
FEDORA-2022-c93cfd49e8 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c93cfd49e8

Comment 17 Fedora Update System 2022-05-09 20:58:06 UTC
FEDORA-2022-c93cfd49e8 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 18 Daniel Walsh 2022-05-10 01:44:43 UTC
Did you break up the qemu-user-static into subpackages?

Comment 19 Dusty Mabe 2022-05-10 02:42:19 UTC
I don't think so: https://src.fedoraproject.org/rpms/qemu/commits/rawhide

Comment 20 Daniel Berrangé 2022-05-10 08:09:56 UTC
Sigh, stupid auto-closer. I merely removed the extra deps on python.

Comment 21 Dusty Mabe 2022-05-10 12:35:53 UTC
(In reply to Daniel Berrangé from comment #20)
> Sigh, stupid auto-closer. I merely removed the extra deps on python.

:) - nevertheless, thank you for doing that part ^^

Comment 22 Cole Robinson 2022-05-17 20:25:15 UTC
If someone takes a stab at it and submits a PR I will help with review and any fine tuning to get it in. Most of the work should be grunt copy+paste stuff I think

Comment 23 Daniel Walsh 2022-05-25 09:03:55 UTC
Created attachment 1883168 [details]
This patch breaks qemu-user-static into three packages.

qemu-user-static package requires qemu-user-static-supported and qemu-user-static-extra.
Not sure about the names for the two packages, but this is what I would envision for the split.

Comment 24 Daniel Berrangé 2022-05-25 09:09:09 UTC
I very much don't like that kind of split because the notion of what is "supported" vs "extra" is very much in the eye of the beholder. If we're going to do any split, then it should mirror the way we split the system emulator packages, where we group by related arch.

Comment 25 Daniel Walsh 2022-05-25 13:56:41 UTC
Created attachment 1883363 [details]
This patch breaks qemu-user-static into multiple arch packages.

Daniel, I have broken out the packages by arch,  PTAL.

Comment 26 Neal Gompa 2022-05-25 14:11:16 UTC
(In reply to Daniel Walsh from comment #25)
> Created attachment 1883363 [details]
> This patch breaks qemu-user-static into multiple arch packages.
> 
> Daniel, I have broken out the packages by arch,  PTAL.

The attachment is private.

Comment 27 Daniel Walsh 2022-05-25 14:35:58 UTC
Fixed, I don't know why this is defaulting to private.

Comment 28 Christian Polizzi 2022-05-25 21:24:10 UTC
Regardless of package management and "splitting" please bear in mind any and all corporate / federal restrictive environments in which downloading anything from beyond the trusted security enclave can prove rto be problematic. As a consequence this also means that you must be cognizant of additional trusted X.509 certificates in a "connected" environment. Reference my comment:

https://github.com/containers/podman/issues/11458#issuecomment-1137858452

Comment 29 Neal Gompa 2022-05-26 04:16:48 UTC
(In reply to Daniel Walsh from comment #27)
> Fixed, I don't know why this is defaulting to private.

You should check your Bugzilla account settings. They may still have legacy settings that default to "Red Hat Confidential"/private for tickets and comments by default. Most accounts shouldn't be affected by this anymore, but I'm aware that it was a problem at one point.

Comment 30 Neal Gompa 2022-05-26 04:25:27 UTC
(In reply to Christian Polizzi from comment #28)
> Regardless of package management and "splitting" please bear in mind any and
> all corporate / federal restrictive environments in which downloading
> anything from beyond the trusted security enclave can prove rto be
> problematic. As a consequence this also means that you must be cognizant of
> additional trusted X.509 certificates in a "connected" environment.
> Reference my comment:
> 
> https://github.com/containers/podman/issues/11458#issuecomment-1137858452

This comment is completely irrelevant in this context:

* You already permit Fedora repositories through, so you must be able to do overlays.
* This ticket is about doing extra package splitting so the FCOS team would be satisfied to ship qemu-user-static on the images rather than requiring overlays.
* X.509 certificates are not used for Fedora content *at all* beyond standard CA certificates for TLS communication to Fedora MirrorManager.
* Fedora CoreOS is not designed for regulated environments.

There is no corporate/federal security concern for this request.

Furthermore, this feature cannot be replicated in RHEL (which is what most of those environments use) because qemu-user is completely unavailable in RHEL. Thus foreign architecture support for multi-arch container builds in RHEL is functionally impossible in a reasonably supportable manner.

Comment 31 Christian Polizzi 2022-05-26 17:28:20 UTC
Perhaps you misunderstood.

Good that you are working on packaging qemu-user-static into the FCOS image builds. Because without it, and if in a restrictive environment that requires an proxy and one that is SSL inspecting (e.g., a typical approach in such environments and generally considered to be an intentional SSL man-in-the-middle attack) then one does indeed need to provision into the podman VM that SSL inspection certificate chain as provided by this type of proxy. Without it, in a scenario such as this, installing the qemu-user-static package (and its dependencies) would be next to impossible. There are also even more restrictive environments in which one would not be able pull packages at all due to more stringent network ACLs and information security policies.

RHEL is not even in scope for anything I stated. FCOS, podman and QEMU emulation of other CPU architectures.

(In reply to Neal Gompa from comment #30)
> * You already permit Fedora repositories through, so you must be able to do
> overlays.
> * This ticket is about doing extra package splitting so the FCOS team would
> be satisfied to ship qemu-user-static on the images rather than requiring
> overlays.
> * X.509 certificates are not used for Fedora content *at all* beyond
> standard CA certificates for TLS communication to Fedora MirrorManager.
> * Fedora CoreOS is not designed for regulated environments.
> 
> There is no corporate/federal security concern for this request.
> 
> Furthermore, this feature cannot be replicated in RHEL (which is what most
> of those environments use) because qemu-user is completely unavailable in
> RHEL. Thus foreign architecture support for multi-arch container builds in
> RHEL is functionally impossible in a reasonably supportable manner.

Comment 32 Daniel Berrangé 2022-05-26 17:39:17 UTC
(In reply to Christian Polizzi from comment #31)
> Perhaps you misunderstood.
> 
> Good that you are working on packaging qemu-user-static into the FCOS image
> builds. Because without it, and if in a restrictive environment that
> requires an proxy and one that is SSL inspecting (e.g., a typical approach
> in such environments and generally considered to be an intentional SSL
> man-in-the-middle attack) then one does indeed need to provision into the
> podman VM that SSL inspection certificate chain as provided by this type of
> proxy. Without it, in a scenario such as this, installing the
> qemu-user-static package (and its dependencies) would be next to impossible.
> There are also even more restrictive environments in which one would not be
> able pull packages at all due to more stringent network ACLs and information
> security policies.

As Neal already said, this is irrelevant to this bug. On this ticket we are
*only* concerned with the packaging layout of QEMU user binaries. Please take any 
other discussions related to podman elsewhere.

Comment 33 Daniel Berrangé 2022-05-26 18:08:03 UTC
(In reply to Daniel Walsh from comment #25)
> Created attachment 1883363 [details]
> This patch breaks qemu-user-static into multiple arch packages.
> 
> Daniel, I have broken out the packages by arch,  PTAL.

I've not had time todo test scratch build, but the proposed spec changes look good to me now.

Comment 34 Daniel Walsh 2022-06-06 12:33:06 UTC
Hey Daniel, did you ever get a chance to look at this?

Is there anything else I need to do to move this forward?

Comment 35 Cole Robinson 2022-06-07 10:08:54 UTC
In rawhide now, I needed to add a few fixes on top since the generated binfmt file list is different depending on host arch.

This bug is against f35. dwalsh do you want this for stable releases too?

Comment 36 Daniel Walsh 2022-06-07 10:11:03 UTC
I would love to get it in F36 if possible.

Comment 37 Fedora Update System 2022-06-08 13:38:37 UTC
FEDORA-2022-7a6b58990b has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-7a6b58990b

Comment 38 Fedora Update System 2022-06-09 16:17:11 UTC
FEDORA-2022-7a6b58990b has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-7a6b58990b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7a6b58990b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 39 Fedora Update System 2022-06-13 01:00:16 UTC
FEDORA-2022-0142d562ca has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-0142d562ca`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-0142d562ca

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 40 Fedora Update System 2022-06-22 00:46:18 UTC
FEDORA-2022-0142d562ca has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.