June 2022 - devel - Fedora Mailing-Lists

[Test-Announce] Kernel 5.18 Test Week is underway

by Sumantro Mukherjee

Hey All, Kernel 5.18 Test week is happening now. It's fairly simple, head over to the wiki [0] and read in detail about the test week and simply run the test case mentioned in[1] and enter your results. As usual, the Fedora QA team will hangout at #fedora-test-day(a)libera.chat for question and discussion. [0] http://fedoraproject.org/wiki/Test_Day:2022-06-05_Kernel_5.18_Test_Week [1] https://testdays.fedoraproject.org/events/136 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED _______________________________________________ test-announce mailing list -- test-announce(a)lists.fedoraproject.org To unsubscribe send an email to test-announce-leave(a)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-announce@lists.fedorap... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

1 year, 11 months

1
0
0 / 0

Fedora-Cloud-36-20220609.0 compose check report

by Fedora compose checker

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-20220607.0): ID: 1291351 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1291351 ID: 1291359 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1291359 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 year, 11 months

1
0
0 / 0

Hardware without AES-NI: use xchacha12/Adiantum instead of AES-XTS

by py0xc3

Good everning, I just experienced that, when setting up a new Fedora, Anaconda (both "Custom" and "Advanced Custom (Blivet-GUI)") always uses aes-xts-plain64 for disk encryption, even if the hardware does not support AES-NI. Does it make sense to use xchacha12,aes-adiantum-plain64 by default if there is no AES-NI in the hardware? For a general use case, the security advantages of Adiantum can be neglected; both aes-xts & chacha-adiantum are secure. But there are big performance disadvantages of AES when there is no AES-NI (this was the major reason for merging Adiantum into the kernel). Besides the use of system resources, netbooks and such may have strongly decreased battery life times with aes-xts (the issue is primarily aes, not xts). I tested with Fedora 35, KDE spin; but as the issue is Anaconda-centric, I expect that other Workstation installations tend to the same behavior. Adjustments would be limited to Anaconda. Regards & stay safe, Chris

1 year, 11 months

3
3
0 / 0

Planned Outage - Bodhi upgrade - 2022-06-09 09:00 UTC

by Mark O'Brien

Hi all, Apologies for the very delayed notice on this. I should have sent this mail a lot earlier. TL;DR there will be an outage of Bodhi tomorrow morning EU time for some upgrades Planned Outage - Bodhi upgrade - 2022-06-09 09:00 UTC There will be an outage starting at 2022-06-09 09:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2022-06-09 09:00 UTC' Reason for outage: Swtich to OpenID connect for authentication and more... Affected Services: Bodhi and any service which relies on it Ticket Link: https://pagure.io/fedora-infrastructure/issue/10754 Please join #fedora-admin or #fedora-noc on irc.libera.chat or add comments to the ticket for this outage above. Thanks, Mark _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)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-announce@lists.fedora... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

1 year, 11 months

3
2
0 / 0

Fedora-Rawhide-20220601.n.0 compose check report

by Fedora compose checker

Missing expected images: Minimal raw-xz armhfp Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 6/231 (x86_64), 13/161 (aarch64) New failures (same test not failed in Fedora-Rawhide-20220531.n.0): ID: 1286655 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1286655 ID: 1286670 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1286670 ID: 1286734 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1286734 ID: 1286765 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/1286765 ID: 1286772 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/1286772 ID: 1286786 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1286786 ID: 1286787 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/1286787 ID: 1286796 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1286796 ID: 1286822 Test: x86_64 Workstation-upgrade desktop_login URL: https://openqa.fedoraproject.org/tests/1286822 ID: 1286963 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/1286963 Old failures (same test failed in Fedora-Rawhide-20220531.n.0): ID: 1286680 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1286680 ID: 1286767 Test: aarch64 Server-dvd-iso server_cockpit_default@uefi URL: https://openqa.fedoraproject.org/tests/1286767 ID: 1286823 Test: x86_64 Workstation-upgrade desktop_fprint URL: https://openqa.fedoraproject.org/tests/1286823 ID: 1286838 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1286838 ID: 1286841 Test: aarch64 Workstation-upgrade desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1286841 ID: 1286842 Test: aarch64 Workstation-upgrade desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1286842 ID: 1286931 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/1286931 ID: 1286971 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1286971 ID: 1287938 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/1287938 Soft failed openQA tests: 3/161 (aarch64), 6/231 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20220531.n.0): ID: 1286801 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi URL: https://openqa.fedoraproject.org/tests/1286801 ID: 1287936 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1287936 Old soft failures (same test soft failed in Fedora-Rawhide-20220531.n.0): ID: 1286652 Test: x86_64 Workstation-live-iso eog URL: https://openqa.fedoraproject.org/tests/1286652 ID: 1286698 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1286698 ID: 1286699 Test: x86_64 Silverblue-dvd_ostree-iso eog URL: https://openqa.fedoraproject.org/tests/1286699 ID: 1286704 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/1286704 ID: 1286713 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1286713 ID: 1286807 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1286807 ID: 1286848 Test: aarch64 Workstation-upgrade eog@uefi URL: https://openqa.fedoraproject.org/tests/1286848 Passed openQA tests: 218/231 (x86_64), 142/161 (aarch64) New passes (same test not passed in Fedora-Rawhide-20220531.n.0): ID: 1286591 Test: x86_64 Server-dvd-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1286591 ID: 1286728 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1286728 ID: 1286785 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1286785 ID: 1286788 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi URL: https://openqa.fedoraproject.org/tests/1286788 ID: 1286789 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing_builtin@uefi URL: https://openqa.fedoraproject.org/tests/1286789 ID: 1286790 Test: aarch64 Workstation-raw_xz-raw.xz base_package_install_remove@uefi URL: https://openqa.fedoraproject.org/tests/1286790 ID: 1286791 Test: aarch64 Workstation-raw_xz-raw.xz unwanted_packages@uefi URL: https://openqa.fedoraproject.org/tests/1286791 ID: 1286792 Test: aarch64 Workstation-raw_xz-raw.xz base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/1286792 ID: 1286793 Test: aarch64 Workstation-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1286793 ID: 1286794 Test: aarch64 Workstation-raw_xz-raw.xz base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/1286794 ID: 1286795 Test: aarch64 Workstation-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/1286795 ID: 1286797 Test: aarch64 Workstation-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/1286797 ID: 1286798 Test: aarch64 Workstation-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1286798 ID: 1286799 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1286799 ID: 1286800 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1286800 ID: 1286802 Test: aarch64 Workstation-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/1286802 ID: 1286803 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi URL: https://openqa.fedoraproject.org/tests/1286803 ID: 1286844 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi URL: https://openqa.fedoraproject.org/tests/1286844 ID: 1286846 Test: aarch64 Workstation-upgrade evince@uefi URL: https://openqa.fedoraproject.org/tests/1286846 ID: 1286847 Test: aarch64 Workstation-upgrade desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/1286847 ID: 1286883 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/1286883 ID: 1286911 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/1286911 ID: 1286967 Test: aarch64 universal install_kickstart_hdd@uefi URL: https://openqa.fedoraproject.org/tests/1286967 Skipped non-gating openQA tests: 3 of 392 Installed system changes in test x86_64 Server-boot-iso install_default: System load changed from 0.38 to 0.55 Previous test data: https://openqa.fedoraproject.org/tests/1285777#downloads Current test data: https://openqa.fedoraproject.org/tests/1286586#downloads Installed system changes in test x86_64 Server-boot-iso install_default@uefi: System load changed from 0.34 to 0.20 Previous test data: https://openqa.fedoraproject.org/tests/1285778#downloads Current test data: https://openqa.fedoraproject.org/tests/1286587#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used swap changed from 23 MiB to 28 MiB System load changed from 0.75 to 0.97 Previous test data: https://openqa.fedoraproject.org/tests/1285838#downloads Current test data: https://openqa.fedoraproject.org/tests/1286647#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used swap changed from 23 MiB to 9 MiB System load changed from 1.24 to 1.00 Previous test data: https://openqa.fedoraproject.org/tests/1285840#downloads Current test data: https://openqa.fedoraproject.org/tests/1286649#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: Used swap changed from 23 MiB to 54 MiB System load changed from 1.10 to 1.22 Average CPU usage changed from 23.54761905 to 10.55238095 Previous test data: https://openqa.fedoraproject.org/tests/1285865#downloads Current test data: https://openqa.fedoraproject.org/tests/1286674#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used swap changed from 15 MiB to 23 MiB System load changed from 1.74 to 2.28 Average CPU usage changed from 38.76666667 to 80.8 Previous test data: https://openqa.fedoraproject.org/tests/1285866#downloads Current test data: https://openqa.fedoraproject.org/tests/1286675#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: System load changed from 0.74 to 0.61 Previous test data: https://openqa.fedoraproject.org/tests/1285886#downloads Current test data: https://openqa.fedoraproject.org/tests/1286695#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used swap changed from 8 MiB to 9 MiB System load changed from 1.21 to 0.77 Previous test data: https://openqa.fedoraproject.org/tests/1285887#downloads Current test data: https://openqa.fedoraproject.org/tests/1286696#downloads Installed system changes in test aarch64 Server-boot-iso install_default@uefi: 1 services(s) removed since previous compose: getty(a)tty6.service System load changed from 0.63 to 1.49 Previous test data: https://openqa.fedoraproject.org/tests/1285919#downloads Current test data: https://openqa.fedoraproject.org/tests/1286728#downloads Installed system changes in test aarch64 Server-dvd-iso install_default_upload@uefi: System load changed from 1.05 to 0.84 Previous test data: https://openqa.fedoraproject.org/tests/1285932#downloads Current test data: https://openqa.fedoraproject.org/tests/1286741#downloads Installed system changes in test x86_64 universal install_package_set_kde: Mount /run/user/0 disappeared since previous compose Used swap changed from 8 MiB to 10 MiB System load changed from 1.77 to 1.61 Previous test data: https://openqa.fedoraproject.org/tests/1286067#downloads Current test data: https://openqa.fedoraproject.org/tests/1286876#downloads Installed system changes in test x86_64 universal install_package_set_minimal: Used mem changed from 226 MiB to 198 MiB System load changed from 0.41 to 0.15 Previous test data: https://openqa.fedoraproject.org/tests/1286068#downloads Current test data: https://openqa.fedoraproject.org/tests/1286877#downloads Installed system changes in test aarch64 universal install_package_set_minimal@uefi: System load changed from 0.85 to 0.68 Previous test data: https://openqa.fedoraproject.org/tests/1286134#downloads Current test data: https://openqa.fedoraproject.org/tests/1286943#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 year, 11 months

1
0
0 / 0

are you using journalctl FSS consistency checks?

by Zbigniew Jędrzejewski-Szmek

Hi! ** are you using 'journal --setup-keys' and 'journalctl --verify-key=…'? In no, feel free to ignore this. ** background story: [A very simplified explanation of "Forward Secure Sealing": public-private key pair is generated when setting up a journal, the private key is copied off the device and stored somewhere, usually using a QR code and a phone, and when the journal is being rotated the key stored on the device is propagated in one-way fashion, so that new private keys can be generated from the older ones, but not vice versa. If somebody tried to generate a fake journal for past history, that would not pass verification. But it is possible to just delete older journal from the device, so FSS should prevent unnoticed modification, but probably not deletion of logs.] The code for FSS is old and clunky, and is the only thing that requires libgcrypt in libsystemd.so and the systemd package itself. It's not widely used, and I'm considering two options: 1. make that code a plugin a that is loaded if available. It could be packaged as a subpackage, so only users who use it would get libgcrypt. 2. just disable support for this in the Fedora package. Hence the question in $subject… If nobody is using it, 2. would be the easier option. Option 1. gives more flexiblity to users, but it isn't so easy to create a "clean cut" and making this into a plugin would require quite a bit of work, and I'm not sure if it's worth the trouble to develop and maintain this. FSS is implemented using libgcrypt's bignums. The code doesn't really have tests and it's not clear how robust the verification is against hostile data. Systemd has moved (almost completely with F36) from using multiple crypto libraries to relying almost exclusively on openssl. The code for FSS is the only thing that requires libgcrypt in a normal systemd installation. It is also the only thing that requires a crypto library in libsystemd.so, so it effectively pulls in libgcrypt into anything that links to libsystemd.so, which is many things. So option 2. gives us a nice reduction in code size and exposure. Zbyszek

1 year, 11 months

2
1
1 / 0

VirtualBox and HOST kernel-5.17.12 weirdness

by Ian Laurie

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? When I first started to see problems on my first host I blamed my SSD drive, memory etc until I noticed the same problems on another host system. The 2 hosts are running very different h/w (one is an ASUS laptop the other an Intel NUC). Long story short I can fix all the problem on both hosts by booting kernel-5.15.11. Weirdness examples... (1) If you boot Fedora 36 Cinnamon guest, login, launch a terminal and just drag it around the screen... Cinnamon crashes. Sometimes the terminal accepts text, sometimes not requiring the VM to be terminated the nasty way. (2) GNOME... similar to above but you get knocked back to the greeter. (3) Xfce... if you run updates, a lot of the downloads have hashes that don't match, requiring re-download. This happens in Cinnamon also. (4) Any GUI... if you run TOR browser it crashes quickly with error 139 usually, or randomly some other error. I am not blaming the kernel, the issue could be a kernel change VirtualBox isn't compatible with. But since I have this on 2 host was wondering if others are already some way along in working out the problem. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney

1 year, 11 months

4
5
0 / 0

[PATCH] chrpath: Bad assumption can corrupt shared libraries when setting RUNPATH

by Frank R Dana Jr.

Hi all. I know we're all busy people, but I'm hoping I can impose on someone with the necessary rights to take a look at this, as it's been in limbo for several months now. Basically, I discovered a fairly nasty bug in chrpath — a package for which upstream has vanished, so we're pretty much on our own — which fortunately only occurs under rare circumstances. "Fortunately" because, when those circumstances arise and it DOES occur, using chrpath to set the RUNPATH for a shared library can instead corrupt (silently!) the library's dynamic string tables. While failing to actually modify the RUNPATH. My bug report about the issue, with steps to reproduce, is here: https://bugzilla.redhat.com/show_bug.cgi?id=2022931 A few months after reporting, I revisited the problem, isolated the bug, and fixed (at least in my testing) chrpath to no longer exhibit that buggy behavior. I submitted the patch as a PR against our chrpath package repo, since the upstream URL points to an unreachable host. That PR can be found here: https://src.fedoraproject.org/rpms/chrpath/pull-request/6 It's been open for five weeks now. As I said, the conditions that trigger the bug are fairly rare, so I wouldn't say it's URGENT per se. But it does feel like it should be addressed, and I even have a patch that (I believe) does so. Perhaps someone has a few minutes to look it over, verify that I haven't done anything stupid, and help move the process along? (Or provide some guidance on how I should go about doing so.) Thanks! (Everything past this point is additional detail for the morbidly curious. Bail out now if you don't want to end up getting bored to tears with very tedious details, or don't say I didn't warn you.) Those fortunately-rare trigger conditions --------------------------------------------------- The library being modified by chrpath will only be corrupted if its .dynstr section is located at an unexpected location in the ELF header. chrpath blindly assumes that the first section of type SHT_STRTAB it encounters when walking the headers must be the .dynstr table, into which the RUNPATH is to be placed at the offset 'rpathoff'. The assumption chrpath makes APPEARS to be a correct one, 99% of the time. For all executables, and most if not all "normal" libraries, the header is laid out as it assumes and it can update RUNPATH strings without incident. However, should that assumption turn out to be INCORRECT, chrpath will insert a RUNPATH string into the **wrong** table. Whichever section of type SHT_STRTAB it encounters first, that table gets the RUNPATH inserted into it. When it's not the .dynstr table, some other symbol name gets partly or completely overwritten with the new RUNPATH string. Meanwhile, the library's *actual* RUNPATH doesn't change, since the real, correct location in the .dynstr section still has the same value it did before running chrpath. One of the ways a library with unexpected table ordering can be created is the series of events that led me to initially discover the bug: Using a different library-editing tool, patchelf, to insert a new RUNPATH into a library that previously lacked one, then subsequently running chrpath on that library. (Adding a RUNPATH to a library is something patchelf can do that chrpath cannot. chrpath is limited to overwriting existing RUNPATH strings with one of the same length or shorter, using space that's already allocated in th header. It has no ability to allocate additional space for a RUNPATH where none previously existed. patchelf *can* carve out space for a RUNPATH string in a library without one — it rewrites the ELF headers to allocate additional space for the new string. In the process of doing so, it seems to relocate (or create?) the dynamic string (.dynstr) table in a header section located *after* the other, previously-allocated sections.) So, when allocating new space to add a RUNPATH, patchelf places .dynstr somewhere that chrpath assumes it will never be located. A patchelf-modified shared library is effectively a trap waiting to be sprung by an unpatched chrpath, which will make a mess of its string tables the moment it tries to modify them. My proposed fix, as implemented in the submitted PR ------------------------------------------------------------------- My patch is as simple as I could make it, and no simpler. It adds two functions to chrpath: read_section_names() retrieves the names for all of the sections from the file's ELF header. The table contains the name for each section, located at an offset that's stored in the .sh_name member of the section header struct. get_section_name() takes a .sh_name value, and returns the corresponding string located at that offset in the section names table. Patched chrpath still walks the ELF headers to find the dynamic string table, when it needs to write a new RUNPATH into a binary. But instead of stopping at the first SHT_STRTAB section it finds and assuming that's the dynamic string table, the loop now calls get_section_name(sh_name) and checks that the string returned is exactly ".dynstr". If it's not, the loop continues on. Only when both the section type AND name are a match, will it proceed to write the new RUNPATH into the table.

1 year, 11 months

2
1
0 / 0

spec-version-maven-plugin license change

by Jerry James

The spec-version-maven-plugin license has been "CDDL or GPLv2 with exceptions". I am about to update to version 2.1 in Rawhide, which changes the license to "EPL-2.0 or GPLv2 with exceptions". This change should have no practical consequences for Fedora. -- Jerry James http://www.jamezone.org/

1 year, 11 months

1
0
0 / 0

Fedora-IoT-36-20220607.0 compose check report

by Fedora compose checker

No missing expected images. Failed openQA tests: 1/15 (x86_64), 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-36-20220605.0): ID: 1290042 Test: x86_64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1290042 ID: 1290057 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1290057 Passed openQA tests: 14/15 (x86_64), 14/15 (aarch64) New passes (same test not passed in Fedora-IoT-36-20220605.0): ID: 1290043 Test: x86_64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/1290043 ID: 1290044 Test: x86_64 IoT-dvd_ostree-iso base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/1290044 ID: 1290045 Test: x86_64 IoT-dvd_ostree-iso base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1290045 ID: 1290046 Test: x86_64 IoT-dvd_ostree-iso iot_greenboot@uefi URL: https://openqa.fedoraproject.org/tests/1290046 ID: 1290047 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/1290047 ID: 1290048 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/1290048 ID: 1290049 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/1290049 ID: 1290050 Test: x86_64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1290050 ID: 1290051 Test: x86_64 IoT-dvd_ostree-iso base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/1290051 ID: 1290052 Test: x86_64 IoT-dvd_ostree-iso base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/1290052 ID: 1290053 Test: x86_64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/1290053 ID: 1290054 Test: x86_64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/1290054 ID: 1290055 Test: x86_64 IoT-dvd_ostree-iso release_identification@uefi URL: https://openqa.fedoraproject.org/tests/1290055 ID: 1290056 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/1290056 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 year, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel June 2022