Fedora-Cloud-33-20210827.0 compose check report
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-33-20210826.0): ID: 959281 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/959281 ID: 959287 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/959287 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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: OpenLDAP 2.5 - Fedora Release - Help Needed
Hi, Simon. On Thursday, 26 August 2021 at 16:04, Simon Pichugin wrote: [...] > I'll wait a bit before posting the Change Proposal, in case somebody > would like to give more feedback on the idea. Please don't wait but just go ahead and post the Change Proposal. It will be discussed here anyway and you can refine it based on feedback. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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: f35-backgrounds ready for review
On Thu, Aug 26, 2021 at 11:38:12AM -0400, Link Dupont wrote: > On Thu, Aug 26 2021 at 03:12:24 PM +, Zbigniew > Jędrzejewski-Szmek wrote: > >True. But those subpackages could just be built from one source > >package: > > > >fedora-backgrounds/f34 => builds all subpackages in the range 21..34 > >fedora-backgrounds/f35 => builds all subpackages in the range 21..35 > > Assuming this range notation is a half-open interval Closed on both sides, I think. But we actually have backgrounds for earlier releases too, see below. > , yes, I like > this idea. Then each subsequent release could take the wallpapers > from its predecessor and create a new subpackage named with the > previous version. I think it'd look like this (e.g. f35 branch): ... %package -n beefy-miracle-backgrounds Summary: Backgrounds for f17 ... %package -n f21-backgrounds Summary: Backgrounds for f21 ... %package -n f35-backgrounds Summary: Backgrounds for f35 Provides: fedora-backgrounds# only when f35 is the latest and then for f36 this would be extended with: %package -n f36-backgrounds Summary: Backgrounds for f36 Provides: fedora-backgrounds# moved here when f36 becomes the latest > Would that get unwieldy as the spec file grows? Is > there an opportunity for macros to make this more sustainable? I don't think it'd be much of a problem even in long form, because we'd essentially get a bunch of new lines once for each release… But yeah, some macro magic would probably make this nicer. Zbyszek ___ 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
Fedora-Cloud-34-20210827.0 compose check report
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-20210826.0): ID: 959418 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/959418 ID: 959424 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/959424 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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: f35-backgrounds ready for review
On Fri, Aug 27, 2021 at 9:12 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Thu, Aug 26, 2021 at 11:38:12AM -0400, Link Dupont wrote: > > On Thu, Aug 26 2021 at 03:12:24 PM +, Zbigniew > > Jędrzejewski-Szmek wrote: > > >True. But those subpackages could just be built from one source > > >package: > > > > > >fedora-backgrounds/f34 => builds all subpackages in the range 21..34 > > >fedora-backgrounds/f35 => builds all subpackages in the range 21..35 > > > > Assuming this range notation is a half-open interval > > Closed on both sides, I think. But we actually have backgrounds for > earlier releases too, see below. > > > , yes, I like > > this idea. Then each subsequent release could take the wallpapers > > from its predecessor and create a new subpackage named with the > > previous version. > > I think it'd look like this (e.g. f35 branch): > > ... > %package -n beefy-miracle-backgrounds > Summary: Backgrounds for f17 > ... > %package -n f21-backgrounds > Summary: Backgrounds for f21 > ... > %package -n f35-backgrounds > Summary: Backgrounds for f35 > Provides: fedora-backgrounds# only when f35 is the latest > > and then for f36 this would be extended with: > > %package -n f36-backgrounds > Summary: Backgrounds for f36 > Provides: fedora-backgrounds# moved here when f36 becomes the latest > > Currently, the spec file has subpackages for each desktop environment though (e.g. f35-backgrounds-gnome, f35-backgrounds-kde, etc.) since they have to be installed in different places for each background. How would we handle that in this type of spec file organization? -Ian > > Would that get unwieldy as the spec file grows? Is > > there an opportunity for macros to make this more sustainable? > > I don't think it'd be much of a problem even in long form, because > we'd essentially get a bunch of new lines once for each release… > But yeah, some macro magic would probably make this nicer. > > Zbyszek > ___ > 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 > ___ 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
Fedora rawhide compose report: 20210827.n.0 changes
OLD: Fedora-Rawhide-20210826.n.1 NEW: Fedora-Rawhide-20210827.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 1 Dropped packages:2 Upgraded packages: 8 Downgraded packages: 0 Size of added packages: 221.67 KiB Size of dropped packages:940.67 KiB Size of upgraded packages: 777.29 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 4.24 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: rust-cursive-tabs-0.6.0-2.fc36 Summary: Tabs for gyscos/cursive views RPMs:rust-cursive-tabs+default-devel rust-cursive-tabs-devel Size:221.67 KiB = DROPPED PACKAGES = Package: java-sleep-2.1-23.fc35 Summary: Multi-paradigm scripting language for Java RPMs:java-sleep java-sleep-javadoc Size:636.97 KiB Package: moconti-102609-20.fc35 Summary: Web Application Server for Sleep RPMs:moconti moconti-javadoc Size:303.69 KiB = UPGRADED PACKAGES = Package: alexandria-0.7.8-6.fc36 Old package: alexandria-0.7.8-5.fc35.1 Summary: Book collection manager RPMs: alexandria Size: 2.36 MiB Size change: 25 B Changelog: * Fri Aug 27 2021 Mamoru TASAKA - 0.7.8-6 - Switch to image_size gem, specify explicitly - Disable 1 failing test Package: chromium-92.0.4515.159-1.fc36 Old package: chromium-91.0.4472.164-2.fc35 Summary: A WebKit (Blink) powered web browser that Google doesn't want you to use RPMs: chrome-remote-desktop chromedriver chromium chromium-common chromium-headless Size: 449.48 MiB Size change: 3.54 MiB Changelog: * Mon Jul 26 2021 Tom Callaway - 92.0.4515.107-1 - update to 92.0.4515.107 - drop python2 deps (finally) * Mon Aug 16 2021 Tom Callaway - 92.0.4515.131-1 - update to 92.0.4515.131 - apply upstream fix for clone3 crash * Tue Aug 17 2021 Tom Callaway - 92.0.4515.159-1 - update to 92.0.4515.159 Package: fedora-bookmarks-28-22.fc36 Old package: fedora-bookmarks-28-10.fc35 Summary: Fedora bookmarks RPMs: fedora-bookmarks Size: 66.97 KiB Size change: 7.92 KiB Package: firefox-91.0.2-1.fc36 Old package: firefox-91.0.1-2.fc36 Summary: Mozilla Firefox Web browser RPMs: firefox firefox-testresults firefox-wayland firefox-x11 Size: 314.14 MiB Size change: 683.75 KiB Changelog: * Thu Aug 26 2021 Martin Stransky - 91.0.2-1 - Updated to 91.0.2 Package: magic-8.3.199-1.fc36 Old package: magic-8.3.196-1.fc35 Summary: A very capable VLSI layout tool RPMs: magic magic-doc Size: 9.06 MiB Size change: -419 B Changelog: * Fri Aug 27 2021 Mamoru TASAKA - 8.3.199-1 - 8.3.199 Package: mingw-filesystem-120-1.fc36 Old package: mingw-filesystem-119-2.fc35 Summary: MinGW cross compiler base filesystem and environment RPMs: mingw-filesystem-base mingw32-filesystem mingw64-filesystem Size: 304.21 KiB Size change: -159 B Changelog: * Fri Aug 27 2021 Sandro Mani - 120-1 - Adapt mingw-find-debuginfo.sh to store debug files below /usr/lib/debug - See https://fedoraproject.org/wiki/Changes/F36MingwDebugLocation Package: python-impacket-0.9.23-1.fc36 Old package: python-impacket-0.9.22-6.fc35 Summary: Collection of Python classes providing access to network packets RPMs: python3-impacket Size: 1.70 MiB Size change: 22.07 KiB Changelog: * Thu Aug 26 2021 Fabian Affolter - 0.9.23-1 - Update to latest upstream release 0.9.23 (closes rhbz#1969986) Package: yokadi-1.2.0-1.fc36 Old package: yokadi-1.1.1-17.fc35 Summary: Command line oriented todo list system RPMs: yokadi Size: 202.83 KiB Size change: 5.64 KiB Changelog: * Thu Aug 26 2021 Fabian Affolter - 1.2.0-1 - Update to latest upstream release 1.2.0 = DOWNGRADED PACKAGES = ___ 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: f35-backgrounds ready for review
On Fri, Aug 27, 2021 at 12:14:10PM +0100, Ian McInerney via devel wrote: > On Fri, Aug 27, 2021 at 9:12 AM Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > > > On Thu, Aug 26, 2021 at 11:38:12AM -0400, Link Dupont wrote: > > > On Thu, Aug 26 2021 at 03:12:24 PM +, Zbigniew > > > Jędrzejewski-Szmek wrote: > > > >True. But those subpackages could just be built from one source > > > >package: > > > > > > > >fedora-backgrounds/f34 => builds all subpackages in the range 21..34 > > > >fedora-backgrounds/f35 => builds all subpackages in the range 21..35 > > > > > > Assuming this range notation is a half-open interval > > > > Closed on both sides, I think. But we actually have backgrounds for > > earlier releases too, see below. > > > > > , yes, I like > > > this idea. Then each subsequent release could take the wallpapers > > > from its predecessor and create a new subpackage named with the > > > previous version. > > > > I think it'd look like this (e.g. f35 branch): > > > > ... > > %package -n beefy-miracle-backgrounds > > Summary: Backgrounds for f17 > > ... > > %package -n f21-backgrounds > > Summary: Backgrounds for f21 > > ... > > %package -n f35-backgrounds > > Summary: Backgrounds for f35 > > Provides: fedora-backgrounds# only when f35 is the latest > > > > and then for f36 this would be extended with: > > > > %package -n f36-backgrounds > > Summary: Backgrounds for f36 > > Provides: fedora-backgrounds# moved here when f36 becomes the latest > > > > > Currently, the spec file has subpackages for each desktop environment > though (e.g. f35-backgrounds-gnome, f35-backgrounds-kde, etc.) since they > have to be installed in different places for each background. How would we > handle that in this type of spec file organization? The same, just have a bunch more of subpackages. A bit messy, but still better than a review and a new package every 6 months. Zbyszek ___ 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: f35-backgrounds ready for review
On Fri, Aug 27, 2021 at 2:22 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Aug 27, 2021 at 12:14:10PM +0100, Ian McInerney via devel wrote: > > On Fri, Aug 27, 2021 at 9:12 AM Zbigniew Jędrzejewski-Szmek < > > zbys...@in.waw.pl> wrote: > > > > > On Thu, Aug 26, 2021 at 11:38:12AM -0400, Link Dupont wrote: > > > > On Thu, Aug 26 2021 at 03:12:24 PM +, Zbigniew > > > > Jędrzejewski-Szmek wrote: > > > > >True. But those subpackages could just be built from one source > > > > >package: > > > > > > > > > >fedora-backgrounds/f34 => builds all subpackages in the range 21..34 > > > > >fedora-backgrounds/f35 => builds all subpackages in the range 21..35 > > > > > > > > Assuming this range notation is a half-open interval > > > > > > Closed on both sides, I think. But we actually have backgrounds for > > > earlier releases too, see below. > > > > > > > , yes, I like > > > > this idea. Then each subsequent release could take the wallpapers > > > > from its predecessor and create a new subpackage named with the > > > > previous version. > > > > > > I think it'd look like this (e.g. f35 branch): > > > > > > ... > > > %package -n beefy-miracle-backgrounds > > > Summary: Backgrounds for f17 > > > ... > > > %package -n f21-backgrounds > > > Summary: Backgrounds for f21 > > > ... > > > %package -n f35-backgrounds > > > Summary: Backgrounds for f35 > > > Provides: fedora-backgrounds# only when f35 is the latest > > > > > > and then for f36 this would be extended with: > > > > > > %package -n f36-backgrounds > > > Summary: Backgrounds for f36 > > > Provides: fedora-backgrounds# moved here when f36 becomes the latest > > > > > > > > Currently, the spec file has subpackages for each desktop environment > > though (e.g. f35-backgrounds-gnome, f35-backgrounds-kde, etc.) since they > > have to be installed in different places for each background. How would we > > handle that in this type of spec file organization? > > The same, just have a bunch more of subpackages. A bit messy, but > still better than a review and a new package every 6 months. One big downside of this approach would be *absolutely huge* sources (all wallpapers since ancient Fedora), even if split into multiple tarballs. The way it's done today, only wallpapers for *one* fedora release have to be uploaded / downloaded at a time. Fabio ___ 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Tue, 2021-08-24 at 10:53 +0200, Ondrej Dubaj wrote: > Hello, > > In the near future, there is a plan to merge autoconf-2.71 to > rawhide. Due to the size of the change and possible breakage of > multiple packages going FTBFS. The number of these packages should > not be many, currently we have ~32 opened FTBFS trackers according to > autoconf-2.71, where the majority of them are just ignored by > maintainers [1]. This can also be a possibility to remove unnecessary > packages from Fedora. After merging the change, there should be a > mechanism for validating. From my perspective, it is effective to > rebuild dependent packages (~1700 packages). After the rebuild, there > should not be many FTBFS packages, but according to the change there > will be some. There was enough time (~6 months) for the maintainers > to prepare for this change. Not everyone is ignoring the bugs I have been working on the am-utils package for this. The package is very old and it utilizes autoconf very heavily. Most of the autoconf noise is use of obsolete macros and I have updated this were I can but there are some things I simply can't fix and some things that shouldn't be changed. I'll keep coming back to it over time since the changes I have made or (rather will be committing over the weekend) do allow the package to build and function on F33 and build in the Copr updated autoconf environment. I expect it will build ok on Monday. > > If there are any concerns or other opinions about the steps after > merging the change, please share your thoughts and we can discuss > them here. > > Thanks very much! > > Regards, > Ondrej > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967 > > On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj > wrote: > > Hello, according to the size of this change and the possible > > breakage of multiple packages before f35 mass rebuild, we decided > > (team working on this change) to postpone this change to early > > lifecycle of f36, where we will have enough time to resolve any > > problems until f36 mass rebuild. > > > > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi wrote: > > > On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote: > > > > Currently, we are trying to stay away from the compat package > > > > and > > > with the > > > > help of other package maintainers trying to fix the failures. > > > > We > > > will give > > > > time to react accordingly and see other possible steps in a few > > > weeks time. > > > > > > > > Currently multiple FTBFS bugs in bugzilla were created > > > > according > > > to > > > > autoconf-2.71. More information available here: > > > > > > > > https://fedoraproject.org/wiki/Changes/Autoconf_271 > > > > > > Whats the current status of this Change? > > > > > > It didn't land before mass rebuild. Is it still planned for f35? > > > > > > kevin > > > ___ > > > 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 > ___ > 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 ___ 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: f35-backgrounds ready for review
On Fri, Aug 27, 2021 at 12:22:04PM +, Zbigniew Jędrzejewski-Szmek wrote: > > Currently, the spec file has subpackages for each desktop environment > > though (e.g. f35-backgrounds-gnome, f35-backgrounds-kde, etc.) since they > > have to be installed in different places for each background. How would we > > handle that in this type of spec file organization? > The same, just have a bunch more of subpackages. A bit messy, but > still better than a review and a new package every 6 months. This makes a strong argument for some kind of fancy macros. -- Matthew Miller Fedora Project Leader ___ 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: f35-backgrounds ready for review
On Fri, Aug 27, 2021 at 02:24:53PM +0200, Fabio Valentini wrote: > One big downside of this approach would be *absolutely huge* sources > (all wallpapers since ancient Fedora), even if split into multiple > tarballs. > The way it's done today, only wallpapers for *one* fedora release have > to be uploaded / downloaded at a time. Yeah, that's why I was thinking of arbitrarily grouping them into sets of 10 releases. That keeps it from becoming *infinitely huge* over time. -- Matthew Miller Fedora Project Leader ___ 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
Fedora-Rawhide-20210827.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 1 of 43 required test results missing Unsatisfied gating requirements that could not be mapped to openQA tests: MISSING: fedora.Cloud_Base-qcow2-qcow2.x86_64.64bit - compose.cloud_autocloud Failed openQA tests: 19/207 (x86_64), 10/141 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210826.n.1): ID: 959468 Test: x86_64 Server-dvd-iso install_lvm_ext4 URL: https://openqa.fedoraproject.org/tests/959468 ID: 959501 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/959501 ID: 959539 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/959539 ID: 959556 Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove@uefi URL: https://openqa.fedoraproject.org/tests/959556 ID: 959569 Test: aarch64 Server-dvd-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/959569 ID: 959688 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/959688 ID: 959701 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/959701 ID: 959710 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/959710 ID: 959725 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/959725 ID: 959726 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/959726 ID: 959727 Test: x86_64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/959727 ID: 959738 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/959738 ID: 959761 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/959761 Old failures (same test failed in Fedora-Rawhide-20210826.n.1): ID: 959440 Test: x86_64 Server-dvd-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/959440 ID: 959463 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/959463 ID: 959494 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/959494 ID: 959495 Test: x86_64 Workstation-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/959495 ID: 959499 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/959499 ID: 959521 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/959521 ID: 959522 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/959522 ID: 959535 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/959535 ID: 959577 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/959577 ID: 959628 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/959628 ID: 959629 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/959629 ID: 959709 Test: x86_64 universal memtest URL: https://openqa.fedoraproject.org/tests/959709 ID: 959728 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/959728 ID: 959756 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/959756 ID: 959760 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/959760 ID: 959776 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/959776 Soft failed openQA tests: 17/207 (x86_64), 9/141 (aarch64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20210826.n.1): ID: 959482 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/959482 Old soft failures (same test soft failed in Fedora-Rawhide-20210826.n.1): ID: 959430 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/959430 ID: 959431 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/959431 ID: 959432 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/959432 ID: 959445 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/959445 ID: 959490 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/959490 ID: 959496 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/959496 ID: 959505 T
Fedora-IoT-36-20210827.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 3/15 (aarch64) Old failures (same test failed in Fedora-IoT-36-20210825.0): ID: 959797 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/959797 ID: 959806 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/959806 ID: 959808 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/959808 Soft failed openQA tests: 3/16 (x86_64), 1/15 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-36-20210825.0): ID: 959778 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/959778 ID: 959779 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/959779 ID: 959785 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/959785 ID: 959794 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/959794 Passed openQA tests: 13/16 (x86_64), 11/15 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
are s390x builders overloaded? Or have they been reconfigured?
Hi, My two most recent ceph builds on s390x have been oom killed. As recently as four days ago they were building fine. Any ideas? -- Kaleb ___ 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: Can comps handle virtual provides?
Miro Hrončok wrote: > Hello. > > We have recently renamed pypy3 to pypy3.7. > As a result, the pypy3-devel package is now called pypy3.7-devel, however > it still provides pypy3-devel. > > pypy3-devel is part of the python-classroom comps group in > comps-f36.xml.in. > > Normally, I'd rename the package there, but in this case I'd rather keep > "pypy3-devel" as it requires less maintenance. Does it work with virtual > provides? Pretty sure answer is no (based on past experience, though the situation may have changed/improved since then) -- Rex ___ 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: Plasmashell: Alt+F2 not working
Sergio Belkin wrote: > Since a few days ago, the keyboard shortcut Alt+F2 for opening "run > command" box is not working. Please followup on upstream bug report on the topic, https://bugs.kde.org/show_bug.cgi?id=437364 In particular, if you can attach your /.config/kglobalshortcutsrc file there, that would help, thanks. We also have a downstream bug, but it needs to be fixed upstream, why I'm encouraging feedback there instead https://bugzilla.redhat.com/show_bug.cgi?id=1974589 -- Rex ___ 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: are s390x builders overloaded? Or have they been reconfigured?
On Fri, 27 Aug 2021 at 10:27, Kaleb Keithley wrote: > > > Hi, > > My two most recent ceph builds on s390x have been oom killed. > > As recently as four days ago they were building fine. > > Any ideas? No idea without links to actual koji build logs to see which of the systems it might be. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ 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: are s390x builders overloaded? Or have they been reconfigured?
On Fri, Aug 27, 2021 at 9:26 AM Kaleb Keithley wrote: > > Hi, > > My two most recent ceph builds on s390x have been oom killed. > > As recently as four days ago they were building fine. > > Any ideas? > Out of curiosity I started a build on my F34 desktop with 32GB ram, and it just OOM'd. Maybe force it to use fewer threads? Thanks, Richard ___ 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: Can comps handle virtual provides?
On Fri, Aug 27, 2021 at 10:42 AM Rex Dieter wrote: > > Miro Hrončok wrote: > > > Hello. > > > > We have recently renamed pypy3 to pypy3.7. > > As a result, the pypy3-devel package is now called pypy3.7-devel, however > > it still provides pypy3-devel. > > > > pypy3-devel is part of the python-classroom comps group in > > comps-f36.xml.in. > > > > Normally, I'd rename the package there, but in this case I'd rather keep > > "pypy3-devel" as it requires less maintenance. Does it work with virtual > > provides? > > Pretty sure answer is no > > (based on past experience, though the situation may have changed/improved > since then) > I don't know about pungi, but DNF is fine with it. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Schedule for Monday's FESCo Meeting (2021-08-23)
On 8/25/21 4:54 AM, Alexander Sosedkin wrote: It's not ideal if one obsolete website forces downgrading the security potentially for all the connections. I hope 5) is addressing that. That's something apps and only apps can handle. Well, but if the system policy says that TLS1.0 is banned, the only way for the app to downgrade would be if it had its own TLS stack, right? I do realize that the current policy mechanism is not designed for narrow deviations, I am just pointing out that it's not ideal because in practice people downgrade because they need narrow deviations for specific connections, and as you well know, relaxing the rules for all connections opens the door to downgrade attacks even on the connections that are capable of TLS2.0. I am asking if there is another way, for instance by having a per-interface policies, and setting up the relaxed rules for an interface that routes traffic to this one deficient remote endpoint. ___ 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: Schedule for Monday's FESCo Meeting (2021-08-23)
On Fri, Aug 27, 2021 at 6:28 PM przemek klosowski via devel wrote: > > > On 8/25/21 4:54 AM, Alexander Sosedkin wrote: > > It's not ideal if one obsolete website forces downgrading the security > potentially for all the connections. I hope 5) is addressing that. > > That's something apps and only apps can handle. > > Well, but if the system policy says that TLS1.0 is banned, the only way for > the app to downgrade would be if it had its own TLS stack, right? The right way is to make the library provide an API that overrides these defaults, and the application to call that API when it's confident it should deviate from the distribution defaults. The current way is that some libraries allow such overriding and some don't. > I do realize that the current policy mechanism is not designed for narrow > deviations, I am just pointing out that it's not ideal because in practice > people downgrade because they need narrow deviations for specific > connections, and as you well know, relaxing the rules for all connections > opens the door to downgrade attacks even on the connections that are capable > of TLS2.0. > > I am asking if there is another way, for instance by having a per-interface > policies, and setting up the relaxed rules for an interface that routes > traffic to this one deficient remote endpoint. It'd be very interesting, hard, and abstraction-permeating to make crypto library configuration depend on endpoints or interfaces, but this is definitely something that should start from within either apps or crypto libraries themselves. crypto-policies is the furthermost component away from things like interfaces and endpoints. ___ 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: f35-backgrounds ready for review
On Fri, Aug 27, 2021 at 08:41:27AM -0400, Matthew Miller wrote: > On Fri, Aug 27, 2021 at 02:24:53PM +0200, Fabio Valentini wrote: > > One big downside of this approach would be *absolutely huge* sources > > (all wallpapers since ancient Fedora), even if split into multiple > > tarballs. > > The way it's done today, only wallpapers for *one* fedora release have > > to be uploaded / downloaded at a time. > > Yeah, that's why I was thinking of arbitrarily grouping them into sets of 10 > releases. That keeps it from becoming *infinitely huge* over time. The other resource issue here is that when you modify the package to add the new wallpapers, everyone who has any of the old ones installed will need to pointlessly update them for the version change. But since that would only happen at branching once a cycle, perhaps thats ok. kevin signature.asc Description: PGP 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: are s390x builders overloaded? Or have they been reconfigured?
On Fri, Aug 27, 2021 at 10:26:22AM -0400, Kaleb Keithley wrote: > Hi, > > My two most recent ceph builds on s390x have been oom killed. > > As recently as four days ago they were building fine. > > Any ideas? Nothing has changed with them recently. We do have some more resources for the kvm lpar though. I'm going to probibly redo them and rebalance disk/cpus/memory at some point, but it will be after beta at least now. In the mean time we may be able to double their memory in the short term (from 10GB to 20GB). I'll try and get that pushed out soon... kevin signature.asc Description: PGP 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: are s390x builders overloaded? Or have they been reconfigured?
On Fri, Aug 27, 2021 at 12:35 PM Kevin Fenzi wrote: > On Fri, Aug 27, 2021 at 10:26:22AM -0400, Kaleb Keithley wrote: > > Hi, > > > > My two most recent ceph builds on s390x have been oom killed. > > > > As recently as four days ago they were building fine. > > > > Any ideas? > > Nothing has changed with them recently. > > We do have some more resources for the kvm lpar though. > I'm going to probibly redo them and rebalance disk/cpus/memory at some > point, but it will be after beta at least now. > > In the mean time we may be able to double their memory in the short term > (from 10GB to 20GB). I'll try and get that pushed out soon... > I hope that's enough. I dropped from 12 to 6 threads and I still hit over 90% memory usage at one point, now on the plus side, that includes a full gnome desktop and Chrome with multiple tabs, on the down side, I still had about 50% of my zram swap still paged from the previous build attempt, but it did complete. Thanks, Richard ___ 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
Update not obsoleting earlier update
https://bodhi.fedoraproject.org/updates/FEDORA-2021-b827e4de0c qemu-6.1.0-2.fc35 FEDORA-2021-b827e4de0c created by rjones a day ago for Fedora 35 ^ This update contains a serious bug (it disables all crypto in qemu) and I "unpushed" it earlier today. https://bodhi.fedoraproject.org/updates/FEDORA-2021-23daee315d qemu-6.1.0-4.fc35 FEDORA-2021-23daee315d created by rjones 2 minutes ago for Fedora 35 ^ This update fixes the bug. However shouldn't it obsolete the first one automatically? Anyway I'd like to delete the first update if possible to avoid the possibility of it being pushed to Fedora. There's no delete operation that I can find. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: Update not obsoleting earlier update
On Fri, Aug 27, 2021 at 07:33:59PM +0100, Richard W.M. Jones wrote: > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-b827e4de0c > qemu-6.1.0-2.fc35 > FEDORA-2021-b827e4de0c created by rjones a day ago for Fedora 35 > > ^ This update contains a serious bug (it disables all crypto in qemu) > and I "unpushed" it earlier today. > > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-23daee315d > qemu-6.1.0-4.fc35 > FEDORA-2021-23daee315d created by rjones 2 minutes ago for Fedora 35 > > ^ This update fixes the bug. I should clarify that although this update says "Disables gcrypt", that means it disables _only_ gcrypt, still using the gnutls internal crypto functions. The first update accidentally disabled the whole of gnutls. Rich. > However shouldn't it obsolete the first one automatically? > > Anyway I'd like to delete the first update if possible to avoid the > possibility of it being pushed to Fedora. There's no delete operation > that I can find. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: Update not obsoleting earlier update
On Fri, Aug 27, 2021 at 8:34 PM Richard W.M. Jones wrote: > > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-b827e4de0c > qemu-6.1.0-2.fc35 > FEDORA-2021-b827e4de0c created by rjones a day ago for Fedora 35 > > ^ This update contains a serious bug (it disables all crypto in qemu) > and I "unpushed" it earlier today. > > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-23daee315d > qemu-6.1.0-4.fc35 > FEDORA-2021-23daee315d created by rjones 2 minutes ago for Fedora 35 > > ^ This update fixes the bug. > > However shouldn't it obsolete the first one automatically? > > Anyway I'd like to delete the first update if possible to avoid the > possibility of it being pushed to Fedora. There's no delete operation > that I can find. Unpushing is the closest you can come to deleting an update, AFAIK. Also, updates only obsolete previous updates for the same package(s) if they were still in either the "pending" or "testing" state. Since you manually unpushed the previous update, it was not obsoleted (because it was not necessary, as it was neither "pending" nor "testing" any longer). Fabio ___ 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
qemu %check hanging intermittently
It seems like the qemu test suite now hangs intermittently after running iotests. Here are some examples: https://koji.fedoraproject.org/koji/taskinfo?taskID=74631239 (x86-64) TEST iotest-qcow2: 313 TEST iotest-qcow2: nbd-qemu-allocation TEST iotest-qcow2: qsd-jobs Not run: 181 Passed all 122 iotests https://kojipkgs.fedoraproject.org//work/tasks/2851/74622851/build.log (i686) TEST iotest-qcow2: 292 TEST iotest-qcow2: 299 TEST iotest-qcow2: 313 TEST iotest-qcow2: nbd-qemu-allocation TEST iotest-qcow2: qsd-jobs Not run: 172 181 186 192 Passed all 119 iotests https://kojipkgs.fedoraproject.org//work/tasks/2885/74622885/build.log (i686) TEST iotest-qcow2: 292 TEST iotest-qcow2: 299 TEST iotest-qcow2: 313 TEST iotest-qcow2: nbd-qemu-allocation TEST iotest-qcow2: qsd-jobs Not run: 172 181 186 192 Passed all 119 iotests I'm not sure exactly why. It seems like the next line of output should be popd which is a trivial bash command and so shouldn't take too much time. This seems to have started to happen round about the time qemu 6.1.0 was released. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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: Fedora Linux 35 Beta blocker status summary
Action summary Accepted blockers - 1. pipewire — pipewire-0.3.31-4.fc35.x86_64 no audio devices found (due to pipewire-media-session user session service not being automatically enabled on update) — NEW ACTION: Maintainer to automatically enable/start pipewire-media-session on upgrade 2. distribution — Fedora 35 backgrounds not present on release-blocking desktops — ON_QA ACTION: QA to verify FEDORA-2021-6924db602c 3. blivet-gui — Software RAID installs fail with "mdadm: specifying chunk size is forbidden for this level" — MODIFIED ACTION: QA to verify FEDORA-2021-d169e03b3f 4. gnome-shell — gnome-shell: cogl_texture_get_gl_texture(): gnome-shell killed by SIGSEGV — NEW ACTION: Maintainers to diagnose and fix issue 5. PackageKit — GNOME Software updates fail with "Prepared update not found" error — NEW ACTION: Maintainers to diagnose and fix issue Bug-by-bug detail = Accepted blockers - 1. pipewire — https://bugzilla.redhat.com/show_bug.cgi?id=1983861 — NEW pipewire-0.3.31-4.fc35.x86_64 no audio devices found (due to pipewire-media-session user session service not being automatically enabled on update) Updates to pipewire do not start pipewire-media-session. Users have to manually start the service. 2. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=1993238 — NEW Fedora 35 backgrounds not present on release-blocking desktops. Update FEDORA-2021-6924db602c contains a candidate fix. See also BZ 1997854 3. blivet-gui — https://bugzilla.redhat.com/show_bug.cgi?id=1996223 — MODIFIED Software RAID installs fail with "mdadm: specifying chunk size is forbidden for this level" blivet-gui is apparently specifying the chunk size for RAID sets and needs to be modified to not do this for RAID 1. Update FEDORA-2021-d169e03b3f contains a candidate fix. 4. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=1989726 — NEW gnome-shell: cogl_texture_get_gl_texture(): gnome-shell killed by SIGSEGV gnome-shell gets SIGSEGV on the Jetson Nano, which is blocking hardware for the aarch64 architecture. 5. PackageKit — https://bugzilla.redhat.com/show_bug.cgi?id=1995817 — NEW GNOME Software updates fail with "Prepared update not found" error GNOME Software package updates fail when attempting to update a package due to a PackageKit file not being found. However, it has become intermittent in the last few days: https://openqa.fedoraproject.org/tests/958345#next_previous -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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: qemu %check hanging intermittently
On Fri, Aug 27, 2021 at 3:42 PM Richard W.M. Jones wrote: > It seems like the qemu test suite now hangs intermittently after > running iotests. Here are some examples: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=74631239 (x86-64) > TEST iotest-qcow2: 313 > TEST iotest-qcow2: nbd-qemu-allocation > TEST iotest-qcow2: qsd-jobs > Not run: 181 > Passed all 122 iotests > > https://kojipkgs.fedoraproject.org//work/tasks/2851/74622851/build.log > (i686) > TEST iotest-qcow2: 292 > TEST iotest-qcow2: 299 > TEST iotest-qcow2: 313 > TEST iotest-qcow2: nbd-qemu-allocation > TEST iotest-qcow2: qsd-jobs > Not run: 172 181 186 192 > Passed all 119 iotests > > https://kojipkgs.fedoraproject.org//work/tasks/2885/74622885/build.log > (i686) > TEST iotest-qcow2: 292 > TEST iotest-qcow2: 299 > TEST iotest-qcow2: 313 > TEST iotest-qcow2: nbd-qemu-allocation > TEST iotest-qcow2: qsd-jobs > Not run: 172 181 186 192 > Passed all 119 iotests > > I'm not sure exactly why. It seems like the next line of output > should be popd which is a trivial bash command and so shouldn't take > too much time. > > This seems to have started to happen round about the time > qemu 6.1.0 was released. > > I got this a couple of times building it as well, I just don't remember if that was something that happened with the rc packages too, or only with the final release. ___ 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: f35-backgrounds ready for review
On Fri, Aug 27, 2021 at 12:34 PM Kevin Fenzi wrote: > On Fri, Aug 27, 2021 at 08:41:27AM -0400, Matthew Miller wrote: > > On Fri, Aug 27, 2021 at 02:24:53PM +0200, Fabio Valentini wrote: > > > One big downside of this approach would be *absolutely huge* sources > > > (all wallpapers since ancient Fedora), even if split into multiple > > > tarballs. > > > The way it's done today, only wallpapers for *one* fedora release have > > > to be uploaded / downloaded at a time. > > > > Yeah, that's why I was thinking of arbitrarily grouping them into sets > of 10 > > releases. That keeps it from becoming *infinitely huge* over time. > > The other resource issue here is that when you modify the package to add > the new wallpapers, everyone who has any of the old ones installed will > need to pointlessly update them for the version change. > > But since that would only happen at branching once a cycle, perhaps > thats ok. > Crazy idea (sorry no quick fix though)... Is a RPM package really the best delivery method? Sure we have to ship at least one background for installation media, but why do we need to download groups of backgrounds? Someone might just want one. Ideally this would be integrated in the DE, but what about an App that searches a central repository with thumbnails and you can pick the background(s) you like and download the full size version? Thanks, Richard ___ 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: f35-backgrounds ready for review
On Friday, 27 August 2021 18.31.36 WEST Kevin Fenzi wrote: > The other resource issue here is that when you modify the package to add > the new wallpapers, everyone who has any of the old ones installed will > need to pointlessly update them for the version change. > > But since that would only happen at branching once a cycle, perhaps > thats ok. > > kevin What you said makes sense, until we look into the gory details. :-) As an example look into f30-backgrounds, the current rawhide changelog for the spec files says: * Wed Jul 21 2021 Fedora Release Engineering - 30.1.2-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Tue Jan 26 2021 Fedora Release Engineering - 30.1.2-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Mon Jul 27 2020 Fedora Release Engineering - 30.1.2-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Tue Jan 28 2020 Fedora Release Engineering - 30.1.2-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Thu Jul 25 2019 Fedora Release Engineering - 30.1.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild So there is no change in this regard. :-) -- José Abílio ___ 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: Fedora Linux 35 Beta blocker status summary
On Fri, 2021-08-27 at 14:50 -0400, Ben Cotton wrote: > Action summary > > > Accepted blockers > - > 1. pipewire — pipewire-0.3.31-4.fc35.x86_64 no audio devices found > (due to pipewire-media-session user session service not being > automatically enabled on update) — NEW > ACTION: Maintainer to automatically enable/start > pipewire-media-session on upgrade The description here is a bit out of date, actually. I have updated the bug. > > 2. distribution — Fedora 35 backgrounds not present on > release-blocking desktops — ON_QA > ACTION: QA to verify FEDORA-2021-6924db602c That update alone will not fully resolve the problem, we will also need a KDE update once it is stable. > > 3. blivet-gui — Software RAID installs fail with "mdadm: specifying > chunk size is forbidden for this level" — MODIFIED > ACTION: QA to verify FEDORA-2021-d169e03b3f I already did, but extra confirmation would be handy. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ 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
Fedora 35 compose report: 20210827.n.1 changes
OLD: Fedora-35-20210825.n.0 NEW: Fedora-35-20210827.n.1 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 0 Dropped packages:2 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:940.67 KiB Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Comp_Neuro live x86_64 Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-35-20210827.n.1.iso Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-35-20210827.n.1.iso = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: java-sleep-2.1-23.fc35 Summary: Multi-paradigm scripting language for Java RPMs:java-sleep java-sleep-javadoc Size:636.97 KiB Package: moconti-102609-20.fc35 Summary: Web Application Server for Sleep RPMs:moconti moconti-javadoc Size:303.69 KiB = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ 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
[Test-Announce] Proposal to CANCEL: 2021-08-30 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't have much for the agenda, and I am planning to run a blocker review meeting, so we'll just have that instead. If you're aware of anything it would be useful to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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
[Test-Announce] 2021-08-30 @ 16:00 UTC - Fedora 35 Blocker Review Meeting
# F35 Blocker Review meeting # Date: 2021-08-30 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.libera.chat Hi folks! We have 1 proposed Beta blocker, 1 proposed Final blocker, and 8 proposed Beta freeze exceptions to review, so let's have a review meeting on Monday. If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F35 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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
Fedora-35-20210827.n.1 compose check report
No missing expected images. Failed openQA tests: 18/205 (x86_64), 8/141 (aarch64) New failures (same test not failed in Fedora-35-20210825.n.0): ID: 960168 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/960168 ID: 960202 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/960202 ID: 960205 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/960205 ID: 960403 Test: x86_64 universal upgrade_2_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/960403 ID: 960418 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/960418 ID: 960443 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/960443 ID: 960471 Test: aarch64 universal install_mirrorlist_graphical@uefi URL: https://openqa.fedoraproject.org/tests/960471 ID: 960484 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/960484 Old failures (same test failed in Fedora-35-20210825.n.0): ID: 960159 Test: x86_64 Server-dvd-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/960159 ID: 960214 Test: x86_64 Workstation-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/960214 ID: 960218 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/960218 ID: 960221 Test: x86_64 Workstation-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/960221 ID: 960239 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/960239 ID: 960240 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/960240 ID: 960241 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/960241 ID: 960254 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/960254 ID: 960264 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background URL: https://openqa.fedoraproject.org/tests/960264 ID: 960294 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/960294 ID: 960327 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/960327 ID: 960343 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi URL: https://openqa.fedoraproject.org/tests/960343 ID: 960346 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/960346 ID: 960384 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/960384 ID: 960426 Test: x86_64 universal memtest URL: https://openqa.fedoraproject.org/tests/960426 ID: 960431 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/960431 ID: 960445 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/960445 ID: 960469 Test: aarch64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/960469 Soft failed openQA tests: 16/141 (aarch64), 19/205 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-35-20210825.n.0): ID: 960356 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/960356 ID: 960455 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/960455 ID: 960478 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/960478 Old soft failures (same test soft failed in Fedora-35-20210825.n.0): ID: 960149 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/960149 ID: 960150 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/960150 ID: 960151 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/960151 ID: 960164 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/960164 ID: 960201 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/960201 ID: 960209 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/960209 ID: 960215 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/960215 ID: 960224 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/960224 ID: 960255 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/96
