Re: VirtualBox and HOST kernel-5.17.12 weirdness
On Sun, 2022-06-12 at 13:59 +1000, Ian Laurie wrote: > > On 6/12/22 11:20, Ian Laurie wrote: > > > > On 6/12/22 09:46, Ian Laurie wrote: > > > > > > On 6/12/22 00:58, Hans de Goede wrote: > > > > Hi, > > > > > > > > On 6/11/22 01:02, Alexander G. M. Smith wrote: > > > > > On 2022-06-08 15:00, Alexander G. M. Smith wrote: > > > > > > Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.: > > > > > > > Is anyone else seeing crashes and other strange events in > > > > > > > VirtualBox > > > > > > > 6.1.34 (from RPMFusion) with Linux guests when the Linux > > > > > > > host is > > > > > > > running > > > > > > > Fedora 36 with kernel-5.17.12? > > > > > > [...] > > > > > > The weird thing is that it works on other CPUs, an AMD > > > > > > Athlon X2 > > > > > > and an Intel 10th generation i5-10500H. Just my Ivy Bridge > > > > > > Intel > > > > > > i7-4820K has the problem. I did try the kernel boot > > > > > > parameter > > > > > > mitigations=off, in case the Spectre or other workarounds > > > > > > were > > > > > > wrong for Ivy Bridge, but it still didn't work. > > > > > One more data point. It fails on an Intel i5-750 too. Same > > > > > broken > > > > > data connections and failed checksums. > > > > > > > > > > My go-to test is to use "dnf clean" followed by "dnf upgrade" > > > > > running as root in a console (thus no networking is between > > > > > keyboard and computer - pipes often fail). My server > > > > > snapshot > > > > > fails to get through the complete dnf upgrade on kernel > > > > > 5.17.13, > > > > > works fine if booting the host with the earlier kernel > > > > > 5.17.11 > > > > > (using the GRUB boot menu to pick the older OS). > > > > > > > > > > So, should we report this to VirtualBox? They seem like the > > > > > most > > > > > appropriate people. Kernel people would be a possibility? > > > > > > > > > > Found a relevant bug report: > > > > > https://www.virtualbox.org/ticket/20976 > > > > > > > > > > And a forum discussion: > > > > > https://forums.virtualbox.org/viewtopic.php?f=7=106071 > > > > > > > > > > Though they don't know that it only happens on certain CPUs > > > > > (or > > > > > motherboards or ?). I'll add some notes about that there. > > > > Note the rpmfusion VirtualBox packages now include this fix: > > > > https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1 > > > > > > > > > > > > > > > > See: > > > > https://koji.rpmfusion.org/koji/buildinfo?buildID=22655 > > > > > > > > Which is supposed to fix this. > > > > > > > > Regards, > > > > > > > > Hans > > > > > > I'm currently running this version, with the 5.18 fixes, but it's > > > not > > > working with kernels 5.17.12/13 or 14. A person reporting > > > success > > > with 5.18.3 reported not having problems with the 5.17 kernels, > > > so > > > maybe there are multiple issues (has been suggested it may be > > > CPU/chipset related). I have not yet tried it on 5.18 but I > > > certainly will today. > > > > > > Ian > > > > > If I understand Sérgio's comment #15 correctly, the 5.18 kernel > > fixes > > don't address the CPU issues possibly created by CVE-2022-1789 > > fixes, > > so there is probably no point in me trying an early 5.18. So the > > CPU > > issues are common to both later 5.17 and 5.18. Sadly all my > > hardware > > here falls under the broken category: > > > > [1] ASUS G750JS 1 x Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz > > Intel Corporation 4th Gen Core Processor Integrated Graphics > > Controller (rev 06) > > NVIDIA Corporation GK104M [GeForce GTX 870M] (rev a1) > > Fedora 36 > > > > [2] Intel NUC i7 NUC11PAH 1 x 11th Gen Intel(R) Core(TM) i7-1165G7 > > @ > > 2.80GHz > > Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) > > Fedora 36 > > > > Since it was going to cost me nothing but time, I tested > kernel-5.18.3-200.fc36.x86_64 with my existing > VirtualBox-6.1.34-4.fc36.x86_64 (RPMFusion updates-testing) and to my > astonishment it seems to be working. On both platforms mentioned > above. So maybe my understanding about the CVE fixes was not > correct. > Or something got fixed between 5.18.2 and 5.18.3 ? Anyway the 5.18.3 > Fedora kernel on Koji with the latest VirtualBox from RPMFusion still > in > testing seems to be working on 2 h/w platforms that were previously > failing from 5.17.12. thank you for the feedback , yes you understand me well, but I hadn't made tests with kernel-5.18.x After read this thread this afternoon , I realize that I also have one Intel(R) Core(TM), I have the i5-9300H CPU and I noticed have network issues with kernel-5.17.12. so I downgrade the kernel kernel-5.17.9- 200.fc35.x86_64 and I confirmed that I hadn't the issues with network. So I was also affected by kernel-5.17.12, but just had weird network issues ... So now, I not sure anymore if we have 2 issues or if it all the same i.e. kvm mitigations which was in first place on
Re: VirtualBox and HOST kernel-5.17.12 weirdness
On 6/12/22 11:20, Ian Laurie wrote: On 6/12/22 09:46, Ian Laurie wrote: On 6/12/22 00:58, Hans de Goede wrote: Hi, On 6/11/22 01:02, Alexander G. M. Smith wrote: On 2022-06-08 15:00, Alexander G. M. Smith wrote: Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.: Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? [...] The weird thing is that it works on other CPUs, an AMD Athlon X2 and an Intel 10th generation i5-10500H. Just my Ivy Bridge Intel i7-4820K has the problem. I did try the kernel boot parameter mitigations=off, in case the Spectre or other workarounds were wrong for Ivy Bridge, but it still didn't work. One more data point. It fails on an Intel i5-750 too. Same broken data connections and failed checksums. My go-to test is to use "dnf clean" followed by "dnf upgrade" running as root in a console (thus no networking is between keyboard and computer - pipes often fail). My server snapshot fails to get through the complete dnf upgrade on kernel 5.17.13, works fine if booting the host with the earlier kernel 5.17.11 (using the GRUB boot menu to pick the older OS). So, should we report this to VirtualBox? They seem like the most appropriate people. Kernel people would be a possibility? Found a relevant bug report: https://www.virtualbox.org/ticket/20976 And a forum discussion: https://forums.virtualbox.org/viewtopic.php?f=7=106071 Though they don't know that it only happens on certain CPUs (or motherboards or ?). I'll add some notes about that there. Note the rpmfusion VirtualBox packages now include this fix: https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1 See: https://koji.rpmfusion.org/koji/buildinfo?buildID=22655 Which is supposed to fix this. Regards, Hans I'm currently running this version, with the 5.18 fixes, but it's not working with kernels 5.17.12/13 or 14. A person reporting success with 5.18.3 reported not having problems with the 5.17 kernels, so maybe there are multiple issues (has been suggested it may be CPU/chipset related). I have not yet tried it on 5.18 but I certainly will today. Ian If I understand Sérgio's comment #15 correctly, the 5.18 kernel fixes don't address the CPU issues possibly created by CVE-2022-1789 fixes, so there is probably no point in me trying an early 5.18. So the CPU issues are common to both later 5.17 and 5.18. Sadly all my hardware here falls under the broken category: [1] ASUS G750JS 1 x Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) NVIDIA Corporation GK104M [GeForce GTX 870M] (rev a1) Fedora 36 [2] Intel NUC i7 NUC11PAH 1 x 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) Fedora 36 Since it was going to cost me nothing but time, I tested kernel-5.18.3-200.fc36.x86_64 with my existing VirtualBox-6.1.34-4.fc36.x86_64 (RPMFusion updates-testing) and to my astonishment it seems to be working. On both platforms mentioned above. So maybe my understanding about the CVE fixes was not correct. Or something got fixed between 5.18.2 and 5.18.3 ? Anyway the 5.18.3 Fedora kernel on Koji with the latest VirtualBox from RPMFusion still in testing seems to be working on 2 h/w platforms that were previously failing from 5.17.12. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-ce8d5824ad halibut-1.3-3.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-aaaeae50ce rubygem-jmespath-1.3.1-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing davix-0.8.2-1.el7 iec16022-0.3.1-1.el7 Details about builds: davix-0.8.2-1.el7 (FEDORA-EPEL-2022-3b6241c488) Toolkit for http based file management Update Information: Davix 0.8.2 ChangeLog: * Sat Jun 11 2022 Mattias Ellert - 0.8.2-1 - New upstream release 0.8.2 iec16022-0.3.1-1.el7 (FEDORA-EPEL-2022-8e3dc6e6a6) Generate ISO/IEC 16022 2D barcodes Update Information: # iec16022 v0.3.1- Bugfix release for an encoding issue - Upstream build system improvements - Upstream removal of zlib dependency ChangeLog: * Sat Jun 11 2022 Robert Scheck - 0.3.1-1 - Upgrade to 0.3.1 (#2095939) * Thu Jan 20 2022 Fedora Release Engineering - 0.3.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Thu Jul 22 2021 Fedora Release Engineering - 0.3.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Tue Jan 26 2021 Fedora Release Engineering - 0.3.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild References: [ 1 ] Bug #2095939 - iec16022-0.3.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=2095939 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1fbc5ebf38 python-elasticsearch-7.17.4-1.el9 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4f458ed801 python-bottle-0.12.21-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing davix-0.8.2-1.el9 iec16022-0.3.1-1.el9 libgeotiff-1.7.1-3.el9 python-redis-4.3.3-1.el9 Details about builds: davix-0.8.2-1.el9 (FEDORA-EPEL-2022-f8a79f6ec6) Toolkit for http based file management Update Information: Davix 0.8.2 ChangeLog: * Sat Jun 11 2022 Mattias Ellert - 0.8.2-1 - New upstream release 0.8.2 iec16022-0.3.1-1.el9 (FEDORA-EPEL-2022-273b8e43ad) Generate ISO/IEC 16022 2D barcodes Update Information: # iec16022 v0.3.1- Bugfix release for an encoding issue - Upstream build system improvements - Upstream removal of zlib dependency ChangeLog: * Sat Jun 11 2022 Robert Scheck - 0.3.1-1 - Upgrade to 0.3.1 (#2095939) * Thu Jan 20 2022 Fedora Release Engineering - 0.3.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild References: [ 1 ] Bug #2095939 - iec16022-0.3.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=2095939 libgeotiff-1.7.1-3.el9 (FEDORA-EPEL-2022-ec2327cb71) GeoTIFF format library Update Information: Build for EPEL9 ChangeLog: * Fri Jun 10 2022 Orion Poplawski - 1.7.1-3 - Make mingw build conditional, disable for EL9 * Fri Mar 25 2022 Sandro Mani - 1.7.1-2 - Rebuild with mingw-gcc-12 * Mon Mar 14 2022 Sandro Mani - 1.7.1-1 - Update to 1.7.1 * Wed Mar 9 2022 Sandro Mani - 1.7.0-8 - Rebuild for proj-9.0.0 * Tue Mar 8 2022 Sandro Mani - 1.7.0-7 - Fix broken mingw pkg-config files * Thu Feb 24 2022 Sandro Mani - 1.7.0-6 - Make mingw subpackages noarch * Thu Feb 24 2022 Sandro Mani - 1.7.0-5 - Add mingw subpackage * Thu Jan 20 2022 Fedora Release Engineering - 1.7.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Thu Jul 22 2021 Fedora Release Engineering - 1.7.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Tue Jul 6 2021 Sandro Mani - 1.7.0-1 - Update to 1.7.0 * Sun Mar 7 2021 Sandro Mani - 1.6.0-5 - Rebuild (proj) * Tue Jan 26 2021 Fedora Release Engineering - 1.6.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Wed Nov 11 2020 Sandro Mani - 1.6.0-3 - Rebuild (proj) * Tue Jul 28 2020 Fedora Release Engineering - 1.6.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild python-redis-4.3.3-1.el9 (FEDORA-EPEL-2022-47e49c4a21) Python interface to the Redis key-value store Update Information: Initial version for epel9 ChangeLog: * Sat Jun 11 2022 Kevin Fenzi - 4.3.3-1 - Update to 4.3.3. Fixes rhbz#2092458 * Tue May 17 2022 Frantisek Zatloukal - 4.3.1-1 - Update to 4.3.1 - Fix tests with Redis 7 * Tue Apr 26 2022 Major Hayden - 4.2.2-2 - Switch to pyproject-rpm-macros for easier EPEL 9 backport. * Mon Apr 4 2022 Frantisek Zatloukal - 4.2.2-1 - Update to 4.2.2 * Fri Jan 21 2022 Fedora Release Engineering - 3.5.3-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Fri Jul 23 2021 Fedora Release Engineering - 3.5.3-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Thu Jun 3 2021 Python Maint - 3.5.3-3 - Rebuilt for Python 3.10 * Wed Jan 27 2021 Fedora Release Engineering - 3.5.3-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Tue Sep 15 2020 Joel Capitao - 3.5.3-1 - Update to 3.5.3 * Wed Jul 29 2020 Fedora Release Engineering - 3.4.1-3 - Rebuilt for
[Bug 2091187] Please build perl-File-Tail for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2091187 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-File-Tail-1.3-24.el9 Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2022-06-12 01:49:07 --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2022-b0942ce6d9 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2091187 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: VirtualBox and HOST kernel-5.17.12 weirdness
On 6/12/22 09:46, Ian Laurie wrote: On 6/12/22 00:58, Hans de Goede wrote: Hi, On 6/11/22 01:02, Alexander G. M. Smith wrote: On 2022-06-08 15:00, Alexander G. M. Smith wrote: Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.: Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? [...] The weird thing is that it works on other CPUs, an AMD Athlon X2 and an Intel 10th generation i5-10500H. Just my Ivy Bridge Intel i7-4820K has the problem. I did try the kernel boot parameter mitigations=off, in case the Spectre or other workarounds were wrong for Ivy Bridge, but it still didn't work. One more data point. It fails on an Intel i5-750 too. Same broken data connections and failed checksums. My go-to test is to use "dnf clean" followed by "dnf upgrade" running as root in a console (thus no networking is between keyboard and computer - pipes often fail). My server snapshot fails to get through the complete dnf upgrade on kernel 5.17.13, works fine if booting the host with the earlier kernel 5.17.11 (using the GRUB boot menu to pick the older OS). So, should we report this to VirtualBox? They seem like the most appropriate people. Kernel people would be a possibility? Found a relevant bug report: https://www.virtualbox.org/ticket/20976 And a forum discussion: https://forums.virtualbox.org/viewtopic.php?f=7=106071 Though they don't know that it only happens on certain CPUs (or motherboards or ?). I'll add some notes about that there. Note the rpmfusion VirtualBox packages now include this fix: https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1 See: https://koji.rpmfusion.org/koji/buildinfo?buildID=22655 Which is supposed to fix this. Regards, Hans I'm currently running this version, with the 5.18 fixes, but it's not working with kernels 5.17.12/13 or 14. A person reporting success with 5.18.3 reported not having problems with the 5.17 kernels, so maybe there are multiple issues (has been suggested it may be CPU/chipset related). I have not yet tried it on 5.18 but I certainly will today. Ian If I understand Sérgio's comment #15 correctly, the 5.18 kernel fixes don't address the CPU issues possibly created by CVE-2022-1789 fixes, so there is probably no point in me trying an early 5.18. So the CPU issues are common to both later 5.17 and 5.18. Sadly all my hardware here falls under the broken category: [1] ASUS G750JS 1 x Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) NVIDIA Corporation GK104M [GeForce GTX 870M] (rev a1) Fedora 36 [2] Intel NUC i7 NUC11PAH 1 x 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) Fedora 36 -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ 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: Wine MinGW system libraries
On 4/20/22 04:13, Richard W.M. Jones wrote:
On Mon, Apr 11, 2022 at 11:18:17PM -0500, Zebediah Figura wrote:
On 4/11/22 08:50, Michael Cronenworth wrote:
On 4/10/22 8:28 PM, Zebediah Figura wrote:
The first problem is that the location of runtime DLLs varies
wildly between distributions, and there's no common independent
way to detect it. We could potentially hardcode a few "guesses"
at the runtime path into Wine's configure script, but that
brings us to the second problem: there's no way to verify the
presence of runtime DLLs. We *are* the loader and lower-level
APIs and would have to bootstrap ourselves first, and this is
pretty much infeasible.
What does that variance between distros look like?
Fedora and SuSE put all binaries, including libgcc binaries, in
/usr/-w64-mingw32/sys-root/mingw/bin/.
Debian puts normal libraries in /usr/-w64-mingw32/lib/, and
libgcc binaries in
/usr/lib/gcc/-w64-mingw32/-/, where
is currently 10 and is win32 or posix.
Arch (well, the AUR) puts all binaries in /usr/-w64-mingw32/bin/.
Can't this just be yet another Wine ./configure flag? It's trivial
for the Fedora spec to set this correctly (using %{mingw64_sysroot}
from mingw{32,64}-filesystem).
Sorry for missing this reply. This is the current purpose of the
--with-system-dllpath flag, as I had described earlier in the same mail.
It's just a bit unfortunate because it means that MinGW packages can't
be automatically picked up by a user trying to compile Wine from source.
___
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: VirtualBox and HOST kernel-5.17.12 weirdness
On 6/12/22 00:58, Hans de Goede wrote: Hi, On 6/11/22 01:02, Alexander G. M. Smith wrote: On 2022-06-08 15:00, Alexander G. M. Smith wrote: Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.: Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? [...] The weird thing is that it works on other CPUs, an AMD Athlon X2 and an Intel 10th generation i5-10500H. Just my Ivy Bridge Intel i7-4820K has the problem. I did try the kernel boot parameter mitigations=off, in case the Spectre or other workarounds were wrong for Ivy Bridge, but it still didn't work. One more data point. It fails on an Intel i5-750 too. Same broken data connections and failed checksums. My go-to test is to use "dnf clean" followed by "dnf upgrade" running as root in a console (thus no networking is between keyboard and computer - pipes often fail). My server snapshot fails to get through the complete dnf upgrade on kernel 5.17.13, works fine if booting the host with the earlier kernel 5.17.11 (using the GRUB boot menu to pick the older OS). So, should we report this to VirtualBox? They seem like the most appropriate people. Kernel people would be a possibility? Found a relevant bug report: https://www.virtualbox.org/ticket/20976 And a forum discussion: https://forums.virtualbox.org/viewtopic.php?f=7=106071 Though they don't know that it only happens on certain CPUs (or motherboards or ?). I'll add some notes about that there. Note the rpmfusion VirtualBox packages now include this fix: https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1 See: https://koji.rpmfusion.org/koji/buildinfo?buildID=22655 Which is supposed to fix this. Regards, Hans I'm currently running this version, with the 5.18 fixes, but it's not working with kernels 5.17.12/13 or 14. A person reporting success with 5.18.3 reported not having problems with the 5.17 kernels, so maybe there are multiple issues (has been suggested it may be CPU/chipset related). I have not yet tried it on 5.18 but I certainly will today. Ian ___ 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: Updated criteria proposal: networking requirements
On Sun, 2022-06-12 at 01:27 +0200, Petr Menšík wrote: > Because of attitude documented in change for systemd-resolved [1], I > expect the only change to get this improved would be switch from > systemd-resolved to anything more DNSSEC friendly. I don't understand > why, but it seems systemd team is avoiding working DNSSEC as much as > they can. Yet it was fixed ALMOST after change related to original issue > #4621 [2], reported 4 years before even the original change in Fedora > were started. > > I will attempt to prepare a better working alternative for the next > release or the one after it. > > 1. https://fedoraproject.org/wiki/Changes/systemd-resolved#DNSSEC > 2. https://github.com/systemd/systemd/issues/4621 Well, that's from quite some time ago. And you have an active thread about this on devel@ where systemd developers seem to be working with you to get your PRs merged. -- 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
[EPEL-devel] [action required (urgent) ] [Bug 2095649] Error Install ImageMagick and Imagemagick-perl together on RH8 (EPEL8 repository)
On Sat, 2022-06-11 at 17:25 +, bugzi...@redhat.com wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=2095649 Hi, for some reason the build on epel 8 to update ImageMagick-6.9.12 from 48 to 50 ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1972114 ) used perl-libs-4:5.32.1-471.module+el8.6.0+13324+628a2397 from I guess modules repo ... this is an error , which I want fix quick as possible. I built it again and now use the correct perl 4:5.26.3-421.el8, so I though ask you please give positive karma urgently on https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0c9f27acb3 Thank you -- Sérgio M. B. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Updated criteria proposal: networking requirements
Because of attitude documented in change for systemd-resolved [1], I expect the only change to get this improved would be switch from systemd-resolved to anything more DNSSEC friendly. I don't understand why, but it seems systemd team is avoiding working DNSSEC as much as they can. Yet it was fixed ALMOST after change related to original issue #4621 [2], reported 4 years before even the original change in Fedora were started. I will attempt to prepare a better working alternative for the next release or the one after it. 1. https://fedoraproject.org/wiki/Changes/systemd-resolved#DNSSEC 2. https://github.com/systemd/systemd/issues/4621 On 09. 06. 22 20:32, Adam Williamson wrote: On Thu, 2022-06-09 at 19:50 +0200, Petr Menšík wrote: I would propose also ability keep DNSSEC validation passthru. If infrastructure provides cryptographic records, they should be available also on the installed host. Without extra modifications. Ie. if delv @$NS is validated for all network DNS servers, then delv should validate too. But that would rule out systemd-resolved in current configuration. delv is a command from bind-utils. Is that too much to ask? I would generally be hesitant to make anything that does not currently work a release criterion. That is effectively requesting development by the back door. It also seems to sort of go against reality - we are apparently fine shipping distributions where this doesn't work, because we've just done it, and there is not an outcry in the press or on social media (AFAICS) that this doesn't work. That tends to imply we don't need to block our releases on it. Basically, if the implied request here is "make it so Fedora really cares whether dnssec works", I'd kinda suggest that should be a Change first. If it's accepted as a Change and gets implemented successfully, then we could maybe consider whether it's a sufficiently important feature to be release blocking. If we haven't even (as a project) decided it's a desirable feature and proved we can implement it (that's what the Change process is for), blocking the release on it seems rather premature... -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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
[Rawhide] Please test Blender 3.2.0 with enabled ffmpeg
Hello everyone, The packaged Blender now has support for ffpmeg (via ffmpeg-free) needed to use other codecs. Some issue may occur due to the difference between ffmpeg-free and upstream ffmpeg meaning a test is needed before possibly supporting on the current release i.e. Fedora 36. Video Editing in Blender will be the starting to test format like MP4. Available package is on https://bodhi.fedoraproject.org/updates/FEDORA-2022-33eb714efd Thank in advance for testing. Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ 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: Enabling ffmpeg on Blender June edition
Let's list these issues now then as this packaged Blender lacked proper video editing support compared to upstream. The built is now on Rawhide to give users a chance to try it out. https://bodhi.fedoraproject.org/updates/FEDORA-2022-33eb714efd ___ 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: VirtualBox and HOST kernel-5.17.12 weirdness
Hi, On 6/11/22 01:02, Alexander G. M. Smith wrote: > On 2022-06-08 15:00, Alexander G. M. Smith wrote: >> Ian Laurie wrote on Friday, 3 June 2022 at 11:17 p.m.: >> > Is anyone else seeing crashes and other strange events in VirtualBox >> > 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running >> > Fedora 36 with kernel-5.17.12? >> [...] >> The weird thing is that it works on other CPUs, an AMD Athlon X2 and an >> Intel 10th generation i5-10500H. Just my Ivy Bridge Intel i7-4820K has the >> problem. I did try the kernel boot parameter mitigations=off, in case the >> Spectre or other workarounds were wrong for Ivy Bridge, but it still didn't >> work. > > One more data point. It fails on an Intel i5-750 too. Same broken data > connections and failed checksums. > > My go-to test is to use "dnf clean" followed by "dnf upgrade" running as root > in a console (thus no networking is between keyboard and computer - pipes > often fail). My server snapshot fails to get through the complete dnf > upgrade on kernel 5.17.13, works fine if booting the host with the earlier > kernel 5.17.11 (using the GRUB boot menu to pick the older OS). > > So, should we report this to VirtualBox? They seem like the most appropriate > people. Kernel people would be a possibility? > > Found a relevant bug report: > https://www.virtualbox.org/ticket/20976 > > And a forum discussion: > https://forums.virtualbox.org/viewtopic.php?f=7=106071 > > Though they don't know that it only happens on certain CPUs (or motherboards > or ?). I'll add some notes about that there. Note the rpmfusion VirtualBox packages now include this fix: https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_kernel_5.18.patch?expand=1 See: https://koji.rpmfusion.org/koji/buildinfo?buildID=22655 Which is supposed to fix this. Regards, Hans ___ 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-20220611.n.0 compose check report
Missing expected images: Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 7 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 32/231 (x86_64), 24/161 (aarch64) New failures (same test not failed in Fedora-Rawhide-20220610.n.1): ID: 1294985 Test: x86_64 Workstation-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1294985 ID: 1295004 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1295004 ID: 1295014 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/1295014 ID: 1295022 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/1295022 ID: 1295053 Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/1295053 ID: 1295070 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/1295070 ID: 1295182 Test: aarch64 Workstation-upgrade desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1295182 ID: 1295191 Test: aarch64 Workstation-upgrade unwanted_packages@uefi URL: https://openqa.fedoraproject.org/tests/1295191 ID: 1295199 Test: x86_64 universal install_mirrorlist_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/1295199 ID: 1295214 Test: x86_64 universal install_delete_pata@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1295214 ID: 1295257 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/1295257 Old failures (same test failed in Fedora-Rawhide-20220610.n.1): ID: 1294961 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/1294961 ID: 1294965 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/1294965 ID: 1294970 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/1294970 ID: 1294971 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/1294971 ID: 1294977 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/1294977 ID: 1294978 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/1294978 ID: 1294979 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/1294979 ID: 1295015 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1295015 ID: 1295016 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/1295016 ID: 1295019 Test: x86_64 KDE-live-iso desktop_printing_builtin URL: https://openqa.fedoraproject.org/tests/1295019 ID: 1295021 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/1295021 ID: 1295023 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1295023 ID: 1295028 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1295028 ID: 1295031 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/1295031 ID: 1295032 Test: x86_64 KDE-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/1295032 ID: 1295044 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1295044 ID: 1295074 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1295074 ID: 1295100 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1295100 ID: 1295102 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/1295102 ID: 1295105 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1295105 ID: 1295110 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/1295110 ID: 1295111 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/1295111 ID: 1295112 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/1295112 ID: 1295113 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/1295113 ID: 1295114 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/1295114 ID: 1295126 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi URL:
Re: [HEADS UP] wxGTK update to 3.1.7
On 6/10/22 03:39 PM, Scott Talbert wrote: On Fri, 10 Jun 2022, Steven A. Falco wrote: On 6/10/22 10:43 AM, Scott Talbert wrote: Hi, I'm updating wxGTK to 3.1.7 in Rawhide - this involves an soname bump. I've created side tag f37-build-side-54462 to perform the build with its dependencies. I've built wxGTK, CubicSDR and audacity in the side tag. @rathann, can you please build wxmacmolplt in the f37-build-side-54462 side tag? Also, feel free to add me as a co-maintainer if you'd rather not have to deal with these requests. :) Is it still too soon to consider a corresponding wxPython? I know you had made a testing build of python3-wxpython4-4.1.2 in mid January. The latest version I see on wxpython.org is wxPython-4.1.2a1.dev5434+7d45ee6a.tar.gz which suggests it is still in alpha. As soon as there is a new upstream release (non-snapshot - which is what those 4.1.2a builds are) of wxPython, I'm planning to move to it. Thankfully, the upstream maintainer, Robin, has become active again recently, so there should be a new release hopefully soon. Makes sense. Thanks for the update, Scott. Steve ___ 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: 20220611.n.0 changes
OLD: Fedora-Rawhide-20220610.n.1 NEW: Fedora-Rawhide-20220611.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 0 Dropped packages:1 Upgraded packages: 18 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:585.01 KiB Size of upgraded packages: 429.22 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -453.13 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20220610.n.1.iso = ADDED PACKAGES = = DROPPED PACKAGES = Package: bodhi-5.7.5-1.fc37 Summary: A modular framework that facilitates publishing software updates RPMs:bodhi-docs python3-bodhi python3-bodhi-client Size:585.01 KiB = UPGRADED PACKAGES = Package: CubicSDR-0.2.7-4.fc37 Old package: CubicSDR-0.2.7-3.fc37 Summary: Cross-Platform Software-Defined Radio Panadapter RPMs: CubicSDR Size: 4.44 MiB Size change: 3.42 KiB Changelog: * Fri Jun 10 2022 Scott Talbert - 0.2.7-4 - Rebuild for wxGTK 3.1.7 Package: audacity-3.1.3-3.fc37 Old package: audacity-3.1.3-2.fc37 Summary: Multitrack audio editor RPMs: audacity audacity-manual Size: 42.75 MiB Size change: -2.45 KiB Changelog: * Fri Jun 10 2022 Scott Talbert - 3.1.3-3 - Rebuild for wxGTK 3.1.7 Package: dummy-test-package-gloster-0-9054.fc37 Old package: dummy-test-package-gloster-0-9051.fc37 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 507.30 KiB Size change: 238 B Changelog: * Fri Jun 10 2022 packagerbot - 0-9052 - rebuilt * Fri Jun 10 2022 packagerbot - 0-9053 - rebuilt * Sat Jun 11 2022 packagerbot - 0-9054 - rebuilt Package: ghc-rpm-macros-2.4.0-1.fc37 Old package: ghc-rpm-macros-2.3.16-1.fc37 Summary: RPM macros for building Haskell packages for GHC RPMs: ghc-filesystem ghc-obsoletes ghc-rpm-macros ghc-rpm-macros-extra Size: 71.46 KiB Size change: 782 B Changelog: * Fri Jun 10 2022 Jens Petersen - 2.4.0-1 - change ghc-deps.sh, splitting buildroot path from ghclibdir so that the ghc version can be used more precisely Package: golang-github-docker-libnetwork-0.8.0-17.20220610gitf6b.fc37 Old package: golang-github-docker-libnetwork-0.8.0-16.20220508git339b972.fc37 Summary: Native Go implementation for connecting containers RPMs: compat-golang-github-moby-libnetwork-devel golang-github-docker-libnetwork-devel Size: 696.39 KiB Size change: -461 B Changelog: * Fri Jun 10 2022 Maxwell G 0.8.0-17 - Bump to f6b1c082a432c2a5814aaedaca56af33d9ea Package: golang-github-klauspost-compress-1.15.6-1.fc37 Old package: golang-github-klauspost-compress-1.15.4-1.fc37 Summary: Optimized compression packages RPMs: golang-github-klauspost-compress-devel Size: 357.86 KiB Size change: 3.65 KiB Changelog: * Fri Jun 10 2022 Dominik Mierzejewski - 1.15.6-1 - update to 1.15.6 (resolves rhbz#2093484) Package: grpc-1.46.3-5.fc37 Old package: grpc-1.46.3-3.fc37 Summary: RPC library and framework RPMs: grpc grpc-cli grpc-cpp grpc-data grpc-devel grpc-doc grpc-plugins python3-grpcio python3-grpcio+protobuf python3-grpcio-admin python3-grpcio-channelz python3-grpcio-csds python3-grpcio-health-checking python3-grpcio-reflection python3-grpcio-status python3-grpcio-testing python3-grpcio-tools Size: 27.48 MiB Size change: 13.05 KiB Changelog: * Fri Jun 10 2022 Benjamin A. Beasley 1.46.3-4 - Fix deprecated ???inspect.getargspec??? * Fri Jun 10 2022 Benjamin A. Beasley 1.46.3-5 - Work around ChannelzServicerTest Python 3.11 regressions for now - Skips five failing tests. Closes RHBZ#2095027. Package: moby-engine-20.10.17-2.fc37 Old package: moby-engine-20.10.16-1.fc37 Summary: The open-source application container engine RPMs: moby-engine moby-engine-fish-completion moby-engine-nano moby-engine-zsh-completion Size: 98.91 MiB Size change: 927.75 KiB Changelog: * Fri Jun 10 2022 Maxwell G - 20.10.17-1 - Update to 20.10.17. Fixes rhbz#2095714. * Sat Jun 11 2022 Maxwell G - 20.10.17-2 - Rebuild for new golang-github-docker-libnetwork Package: muffin-5.4.0-1.fc37 Old package: muffin-5.2.1-1.fc37 Summary: Window and compositing manager based on Clutter RPMs: muffin muffin-devel Size: 9.00 MiB Size change: -1.49 MiB Changelog: * Fri Jun 10 2022 Leigh Scott - 5.4.0-1 - Update to 5.4.0 release Package: py3status-3.44-1.fc37 Old package: py3status-3.34-4.fc36 Summary: An extensible i3status wrapper written in python RPMs: py3status Dropped RPMs: py3status-doc Size: 494.73 KiB Size change: -272.44 KiB Changelog: * Thu Jun 09 2022 Michael J Gruber - 3.44-1
Fedora-Cloud-36-20220611.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-36-20220609.0): ID: 1294915 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1294915 ID: 1294923 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1294923 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
