Fedora-Rawhide-20211217.n.1 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 20 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 67/159 (aarch64), 95/228 (x86_64) New failures (same test not failed in Fedora-Rawhide-20211216.n.0): ID: 1089433 Test: aarch64 Workstation-upgrade evince@uefi URL: https://openqa.fedoraproject.org/tests/1089433 Old failures (same test failed in Fedora-Rawhide-20211216.n.0): ID: 1089187 Test: x86_64 Server-dvd-iso install_blivet_standard_partition_ext4 URL: https://openqa.fedoraproject.org/tests/1089187 ID: 1089188 Test: x86_64 Server-dvd-iso install_blivet_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1089188 ID: 1089189 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1089189 ID: 1089190 Test: x86_64 Server-dvd-iso install_btrfs_preserve_home URL: https://openqa.fedoraproject.org/tests/1089190 ID: 1089191 Test: x86_64 Server-dvd-iso install_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1089191 ID: 1089192 Test: x86_64 Server-dvd-iso install_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1089192 ID: 1089196 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home URL: https://openqa.fedoraproject.org/tests/1089196 ID: 1089197 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/1089197 ID: 1089199 Test: x86_64 Server-dvd-iso install_lvm_ext4 URL: https://openqa.fedoraproject.org/tests/1089199 ID: 1089206 Test: x86_64 Server-dvd-iso install_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1089206 ID: 1089209 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/1089209 ID: 1089211 Test: x86_64 Server-dvd-iso install_standard_partition_ext4 URL: https://openqa.fedoraproject.org/tests/1089211 ID: 1089214 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/1089214 ID: 1089215 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/1089215 ID: 1089216 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4 URL: https://openqa.fedoraproject.org/tests/1089216 ID: 1089217 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1089217 ID: 1089218 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/1089218 ID: 1089227 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/1089227 ID: 1089228 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/1089228 ID: 1089233 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/1089233 ID: 1089234 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/1089234 ID: 1089238 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/1089238 ID: 1089240 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/1089240 ID: 1089241 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1089241 ID: 1089244 Test: x86_64 Workstation-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1089244 ID: 1089245 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1089245 ID: 1089273 Test: x86_64 KDE-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/1089273 ID: 1089280 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1089280 ID: 1089303 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/1089303 ID: 1089305 Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount URL: https://openqa.fedoraproject.org/tests/1089305 ID: 1089306 Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/1089306 ID: 1089307 Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/1089307 ID: 1089308 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/1089308 ID: 1089309 Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove@uefi URL: https://openqa.fedoraproject.org/tests/1089309 ID: 1089310 Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1089310 ID: 1089311 Test: x86_64
Re: is an accidentally reverted Fedora feature/change a blocker?
On Sat, 2021-12-18 at 15:16 -0500, Matthew Miller wrote: > On Sat, Dec 18, 2021 at 10:49:53AM -0800, Adam Williamson wrote: > > > This makes sense to me. It might also make sense for big changes to also > > > include proposed updates to the validation criteria, just as modern > > > software > > > development expects new features to come with tests for those features. > > > > We do this, but only for *functional* requirements, which I think is > > correct. I don't want us to be pinning software versions and what > > specific implementation of a given function "must be" used in the > > release criteria, in general, because it seems like a terrible > > mechanism for it, and one that really wouldn't scale. > > Okay, fair enough — and I'm definitely not wanting to add _more_ automatic > blockers. :) > > But it does seem like we should have _some_ set of automated testing that's > linked to intentional, acccepted changes. Nano-as-default in Fedora Server > is another one. > > Maybe even something where "getting the test hooked up" is the next step for > the change owner after the change is accepted. Is there a way where change > owners could plug into some of our existing automated testing to do that? So, there is kind of a scaling issue there. AFAIK openQA is still the only system actually doing compose-level automated testing, and it just isn't really endlessly scalable, especially as currently deployed (on a limited amount of physical hardware) and monitored (...mostly by me). We need to pick what we focus on with it quite carefully. I could add a "is-nano-default" test to it, sure, but...where do we stop if we go down that route? There are, what, 20+ Changes per release? If we start adding tests related to even half of them per cycle, we're piling up tests at a fairly rapid clip, and it would start to cause issues with manageability quite quickly. Never mind if we went back and did it for the hundreds or more Features and Changes we've had in the past. I have added a couple of tests of this approximate type (like a "is GTK+ 2 installed by default?" test) recently, because the desktop team asked nicely, but that was my capricious whim and if they asked for more I might say no :P I think this might be more feasible if we managed to implement compose- level testing in Fedora CI, for the benefits of maybe a wider base of people to maintain and monitor results, more capacity, less overhead (you don't need all of openQA's screenshot-monitoring, video-recording special sauce to implement a "is nano default?" test, really), and somewhat fewer domain-specific knowledge requirements in maintaining and monitoring tests... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20211217.n.1 changes
OLD: Fedora-Rawhide-20211216.n.0 NEW: Fedora-Rawhide-20211217.n.1 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 7 Dropped packages:0 Upgraded packages: 195 Downgraded packages: 0 Size of added packages: 8.83 MiB Size of dropped packages:0 B Size of upgraded packages: 3.87 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 71.30 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Robotics live x86_64 Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20211216.n.0.iso = ADDED PACKAGES = Package: golang-github-charmbracelet-glamour-0.3.0-1.fc36 Summary: Stylesheet-based markdown rendering for your CLI apps RPMs:golang-github-charmbracelet-glamour-devel Size:32.65 KiB Package: golang-github-muhammadmuzzammil1998-jsonc-0-0.1.20211217git615b091.fc36 Summary: JSON with comments for Go RPMs:golang-github-muhammadmuzzammil1998-jsonc-devel Size:15.91 KiB Package: golang-github-sourcegraph-jsonrpc2-0.1.0-2.fc36 Summary: Package jsonrpc2 provides a client and server implementation of JSON-RPC 2.0 RPMs:golang-github-sourcegraph-jsonrpc2-devel Size:23.24 KiB Package: libinjection-3.10.0-4.fc36 Summary: SQL / SQLI tokenizer parser analyzer library RPMs:libinjection libinjection-devel libinjection-tests Size:5.77 MiB Package: mingw-qt6-qtshadertools-6.2.2-1.fc36 Summary: Qt6 for Windows - Qt Shader Tools component RPMs:mingw32-qt6-qtshadertools mingw64-qt6-qtshadertools Size:2.70 MiB Package: rust-pretty_assertions0.7-0.7.2-1.fc36 Summary: Overwrite assert_eq! and assert_ne! with colorful drop-in replacements RPMs:rust-pretty_assertions0.7+default-devel rust-pretty_assertions0.7-devel Size:91.66 KiB Package: tsl-sparse-map-0.6.2-1.fc36 Summary: C++ implementation of a memory efficient hash map and hash set RPMs:tsl-sparse-map-devel Size:211.40 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: 389-ds-base-2.0.12-1.fc36 Old package: 389-ds-base-2.0.11-1.fc36 Summary: 389 Directory Server (base) RPMs: 389-ds-base 389-ds-base-devel 389-ds-base-libs 389-ds-base-snmp cockpit-389-ds python3-lib389 Size: 23.20 MiB Size change: -2.37 MiB Changelog: * Thu Dec 16 2021 Mark Reynolds - 2.0.12-1 - Bump version to 2.0.12-1 - Issue 4299 - UI LDAP editor - add "edit" and "rename" functionality - Issue 4962 - Fix various UI bugs - Database and Backups (#5044) - Issue 5046 - BUG - update concread (#5047) - Issue 5043 - BUG - Result must be used compiler warning (#5045) - Issue 4165 - Don't apply RootDN access control restrictions to UNIX connections - Issue 4931 - RFE: dsidm - add creation of service accounts - Issue 5024 - BUG - windows ro replica sigsegv (#5027) - Issue 5020 - BUG - improve clarity of posix win sync logging (#5021) - Issue 5008 - If a non critical plugin can not be loaded/initialized, bootstrap should succeeds (#5009) Package: CFR-0.151-5.fc36 Old package: CFR-0.151-4.fc35 Summary: CFR - Another Java Decompiler RPMs: CFR CFR-javadoc Size: 3.47 MiB Size change: 827 B Changelog: * Fri Aug 06 2021 ohrdlick - 0.151-5 - bumped javaVersion from 1.6 to 1.8 to make jdk17 happy Package: NetworkManager-1:1.36.0-0.3.fc36 Old package: NetworkManager-1:1.36.0-0.2.fc36 Summary: Network connection manager and user applications RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora NetworkManager-config-server NetworkManager-dispatcher-routing-rules NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi NetworkManager-wwan Size: 28.42 MiB Size change: 5.85 KiB Changelog: * Thu Dec 16 2021 Wen Liang - 1:1.36.0-0.3 - update to an early 1.36 snapshot (1.35.3) Package: alsa-lib-1.2.6.1-3.fc36 Old package: alsa-lib-1.2.6.1-2.fc36 Summary: The Advanced Linux Sound Architecture (ALSA) library RPMs: alsa-lib alsa-lib-devel alsa-topology alsa-ucm Size: 7.71 MiB Size change: 2.76 KiB Changelog: * Fri Dec 17 2021 Jaroslav Kysela - 1.2.6.1-3 - updated alsa-ucm-conf to 1.2.6.3 Package: anagramarama-0.6-1.fc36 Old package: anagramarama-0.5-3.fc36 Summary: Anagram puzzle game RPMs: anagramarama Size: 3.95 MiB Size change: 487.74 KiB Changelog: * Thu Dec 16 2021 Dennis Payne - 0.6-1 - Newest release Package: ansible-pcp-2.2.4-1.fc36 Old package: ansible-pcp-2.2.2-1.fc36 Summary: Ansible Metric collection for Performance Co-Pilot RPMs: ansible-pcp Size: 121.39 KiB Size change: 400 B Changelog: * Fri Dec 17 2021 Nathan Scott 2.2.4-1 - Small fixes for bpftrace, mssql roles and tests - RHEL9 - add "Requires: ansible-core"
Re: is an accidentally reverted Fedora feature/change a blocker?
On Sat, Dec 18, 2021 at 10:49:53AM -0800, Adam Williamson wrote: > > This makes sense to me. It might also make sense for big changes to also > > include proposed updates to the validation criteria, just as modern software > > development expects new features to come with tests for those features. > > We do this, but only for *functional* requirements, which I think is > correct. I don't want us to be pinning software versions and what > specific implementation of a given function "must be" used in the > release criteria, in general, because it seems like a terrible > mechanism for it, and one that really wouldn't scale. Okay, fair enough — and I'm definitely not wanting to add _more_ automatic blockers. :) But it does seem like we should have _some_ set of automated testing that's linked to intentional, acccepted changes. Nano-as-default in Fedora Server is another one. Maybe even something where "getting the test hooked up" is the next step for the change owner after the change is accepted. Is there a way where change owners could plug into some of our existing automated testing to do that? -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: is an accidentally reverted Fedora feature/change a blocker?
On Sat, 2021-12-18 at 13:23 -0500, Matthew Miller wrote: > On Sat, Dec 18, 2021 at 09:09:17AM -0800, Adam Williamson wrote: > > However, I think there'd be a solid case for FESCo to take anything > > like this as a blocker, and procedurally that makes more sense too - > > Changes are under FESCo's remit. So if a case like this is caught > > before release, I'd say file a FESCo ticket asking them to consider it > > as a blocker. > > This makes sense to me. It might also make sense for big changes to also > include proposed updates to the validation criteria, just as modern software > development expects new features to come with tests for those features. We do this, but only for *functional* requirements, which I think is correct. I don't want us to be pinning software versions and what specific implementation of a given function "must be" used in the release criteria, in general, because it seems like a terrible mechanism for it, and one that really wouldn't scale. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: is an accidentally reverted Fedora feature/change a blocker?
On Sat, Dec 18, 2021 at 09:09:17AM -0800, Adam Williamson wrote: > However, I think there'd be a solid case for FESCo to take anything > like this as a blocker, and procedurally that makes more sense too - > Changes are under FESCo's remit. So if a case like this is caught > before release, I'd say file a FESCo ticket asking them to consider it > as a blocker. This makes sense to me. It might also make sense for big changes to also include proposed updates to the validation criteria, just as modern software development expects new features to come with tests for those features. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: is an accidentally reverted Fedora feature/change a blocker?
On Fri, 2021-12-17 at 19:29 -0700, Chris Murphy wrote: > Fedora 33 brough systemd-resolved by default; but in Fedora 35 this > somehow got reverted. > > I've proposed it as a blocker, but the main point of the thread is > really to discuss the general case of whether such a thing is a > blocker? I'm not thinking of a release criterion that applies to this > case. It seems reasonable that approved+implemented features that > subsequently break (accidentally or even intentionally when absent an > approved change) should be blockers. > > Server edition is missing /etc/resolv.conf symlink (use systemd-resolved) > https://bugzilla.redhat.com/show_bug.cgi?id=2032085 It's an interesting question! I'd say on the *whole* they wouldn't qualify as blockers under the main criteria-driven process we go through (with the blockerbugs app and voting system and meetings and yadda yadda), because that intentionally doesn't generally concern itself with exactly *how* things work, just *that* the things work. However, I think there'd be a solid case for FESCo to take anything like this as a blocker, and procedurally that makes more sense too - Changes are under FESCo's remit. So if a case like this is caught before release, I'd say file a FESCo ticket asking them to consider it as a blocker. As a sidenote, I was surprised openQA didn't choke on this bug, as I thought some things we do with static DNS configuration would only work with resolved...but I just went and checked, and last year we "improved" those things to use commands that work with both resolved and the old setup, so the same commands could be used on both F33 (old way, still supported at the time) and F34+ (meant to be the new way). So that's why we didn't run into this there. Ha. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20211218.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-20211217.0): ID: 1089087 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1089087 ID: 1089098 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1089098 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-35-20211218.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-35-20211216.0): ID: 1089071 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1089071 ID: 1089082 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1089082 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
