Fedora-Cloud-32-20201114.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20201112.0): ID: 721912 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/721912 ID: 721919 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/721919 Passed openQA tests: 6/7 (x86_64), 6/7 (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
Fedora-Cloud-31-20201114.0 compose check report
No missing expected images. Passed openQA tests: 7/7 (x86_64), 7/7 (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
Fedora rawhide compose report: 20201114.n.0 changes
OLD: Fedora-Rawhide-20201112.n.0 NEW: Fedora-Rawhide-20201114.n.0 = SUMMARY = Added images:0 Dropped images: 10 Added packages: 20 Dropped packages:9 Upgraded packages: 233 Downgraded packages: 1 Size of added packages: 13.50 MiB Size of dropped packages:763.18 MiB Size of upgraded packages: 11.16 GiB Size of downgraded packages: 858.12 KiB Size change of upgraded packages: 203.83 MiB Size change of downgraded packages: 1.99 KiB = ADDED IMAGES = = DROPPED IMAGES = Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20201112.n.0.ppc64le.tar.xz Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20201112.n.0.iso Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20201112.n.0.ppc64le.qcow2 Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20201112.n.0.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20201112.n.0.s390x.tar.xz Image: Python_Classroom raw-xz armhfp Path: Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20201112.n.0-sda.raw.xz Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20201112.n.0.s390x.tar.xz Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20201112.n.0.ppc64le.raw.xz Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20201112.n.0.x86_64.vagrant-libvirt.box Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20201112.n.0.x86_64.vagrant-virtualbox.box = ADDED PACKAGES = Package: badvpn-1.999.130-1.fc34 Summary: Peer-to-peer VPN solution RPMs:badvpn Size:3.15 MiB Package: fbzmq-2020.11.09.00-2.fc34 Summary: Framework for writing services in C++ while leveraging libzmq RPMs:fbzmq fbzmq-devel fbzmq-static Size:2.17 MiB Package: mingw-adwaita-qt-1.1.91-1.fc34 Summary: Adwaita theme for Qt-based applications RPMs:mingw32-adwaita-qt5 mingw32-libadwaita-qt5 mingw32-libadwaita-qt5-static mingw64-adwaita-qt5 mingw64-libadwaita-qt5 mingw64-libadwaita-qt5-static Size:503.48 KiB Package: mingw-minizip-2.10.2-1.fc34 Summary: MinGW Windows minizip library RPMs:mingw32-minizip mingw64-minizip Size:180.17 KiB Package: mingw-python-dateutil-2.8.1-1.fc34 Summary: MinGW Windows Python dateutil library RPMs:mingw32-python3-dateutil mingw64-python3-dateutil Size:557.74 KiB Package: mingw-python-homography-0.1.6-1.fc34 Summary: MinGW Windows Python homography library RPMs:mingw32-python3-homography mingw64-python3-homography Size:51.98 KiB Package: mingw-python-psycopg2-2.8.6-2.fc34 Summary: MinGW Windows Python psycopg2 library RPMs:mingw32-python3-psycopg2 mingw64-python3-psycopg2 Size:821.88 KiB Package: mingw-zstd-1.4.5-2.fc34 Summary: MinGW Windows zstd library RPMs:mingw32-zstd mingw64-zstd Size:535.41 KiB Package: rubiks-20070912-1.fc34 Summary: Rubiks cube solvers RPMs:rubiks Size:827.77 KiB Package: rust-blsctl-0.2.3-1.fc34 Summary: Manages BLS entries and kernel cmdline options RPMs:blsctl rust-blsctl+default-devel rust-blsctl-devel Size:1.03 MiB Package: rust-crossbeam-channel0.4-0.4.4-1.fc34 Summary: Multi-producer multi-consumer channels for message passing RPMs:rust-crossbeam-channel0.4+default-devel rust-crossbeam-channel0.4-devel Size:85.18 KiB Package: rust-crossbeam-deque0.7-0.7.3-1.fc34 Summary: Concurrent work-stealing deque RPMs:rust-crossbeam-deque0.7+default-devel rust-crossbeam-deque0.7-devel Size:34.86 KiB Package: rust-crossbeam-epoch0.8-0.8.2-1.fc34 Summary: Epoch-based garbage collection RPMs:rust-crossbeam-epoch0.8+alloc-devel rust-crossbeam-epoch0.8+default-devel rust-crossbeam-epoch0.8+lazy_static-devel rust-crossbeam-epoch0.8+nightly-devel rust-crossbeam-epoch0.8+sanitize-devel rust-crossbeam-epoch0.8+std-devel rust-crossbeam-epoch0.8-devel Size:87.18 KiB Package: rust-crossbeam-queue0.2-0.2.3-1.fc34 Summary: Concurrent queues RPMs:rust-crossbeam-queue0.2+alloc-devel rust-crossbeam-queue0.2+default-devel rust-crossbeam-queue0.2+std-devel rust-crossbeam-queue0.2-devel Size:45.42 KiB Package: rust-crossbeam-utils0.7-0.7.2-1.fc34 Summary: Utilities for concurrent programming RPMs:rust-crossbeam-utils0.7+alloc-devel rust-crossbeam-utils0.7+default-devel rust-crossbeam-utils0.7+lazy_static-devel rust-crossbeam-utils0.7+nightly-devel rust-crossbeam-utils0.7+std-devel rust-crossbeam-utils0.7-devel Size:78.33 KiB Package: rust-crossbeam0.7-0.7.3-1.fc34 Summary: Tools for concurrent programming RPMs:rust-crossbeam0.7+alloc-devel rust-crossbeam0.7+crossbeam-channel-devel rust-crossbeam0.7+crossbeam-deque-devel
Re: Highlights from the latest Copr release
Same today: ssh: connect to host 3.237.199.13 port 22: Connection timed out https://download.copr.fedorainfracloud.org/results/mjg/scribus/fedora-32-x86_64/01768969-scribus156/builder-live.log.gz Copr infra networked borked? ___ 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
Fedora-IoT-33-20201114.0 compose check report
No missing expected images. Failed openQA tests: 3/15 (aarch64), 1/16 (x86_64) New failures (same test not failed in Fedora-IoT-33-20201109.0): ID: 722270 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/722270 ID: 722274 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/722274 Old failures (same test failed in Fedora-IoT-33-20201109.0): ID: 722244 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/722244 ID: 722260 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/722260 Passed openQA tests: 15/16 (x86_64), 12/15 (aarch64) Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.25 to 0.41 Previous test data: https://openqa.fedoraproject.org/tests/719061#downloads Current test data: https://openqa.fedoraproject.org/tests/722261#downloads -- 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
Fedora-Rawhide-20201114.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 16/177 (x86_64), 16/115 (aarch64) New failures (same test not failed in Fedora-Rawhide-20201112.n.0): ID: 721982 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/721982 ID: 721988 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/721988 ID: 722000 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/722000 ID: 722039 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/722039 ID: 722070 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/722070 ID: 722075 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/722075 ID: 722086 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/722086 ID: 722109 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/722109 ID: 722120 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/722120 ID: 722148 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/722148 ID: 722189 Test: aarch64 universal install_mirrorlist_graphical@uefi URL: https://openqa.fedoraproject.org/tests/722189 ID: 722213 Test: aarch64 universal install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/722213 ID: 77 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/77 ID: 78 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/78 ID: 79 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/79 ID: 722230 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/722230 Old failures (same test failed in Fedora-Rawhide-20201112.n.0): ID: 722007 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/722007 ID: 722008 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/722008 ID: 722010 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/722010 ID: 722084 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/722084 ID: 722130 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/722130 ID: 722185 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/722185 ID: 722197 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/722197 ID: 722210 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/722210 ID: 722231 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/722231 ID: 722234 Test: x86_64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/722234 ID: 722236 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/722236 ID: 722237 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/722237 ID: 722238 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/722238 ID: 722239 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/722239 ID: 722240 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/722240 ID: 722242 Test: aarch64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/722242 Soft failed openQA tests: 2/177 (x86_64), 1/115 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20201112.n.0): ID: 721981 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/721981 ID: 722032 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/722032 ID: 722100 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/722100 Passed openQA tests: 159/177 (x86_64), 91/115 (aarch64) New passes (same test not passed in Fedora-Rawhide-20201112.n.0): ID: 721990 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/721990 ID: 722055 Tes
[Test-Announce] Fedora-IoT 34 RC 20201114.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora-IoT 34 RC 20201114.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/34iot You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_34_RC_20201114.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_34_RC_20201114.0_General Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ 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
Fedora-IoT-34-20201114.0 compose check report
No missing expected images. Failed openQA tests: 2/16 (x86_64), 5/15 (aarch64) New failures (same test not failed in Fedora-IoT-34-20201014.0): ID: 722287 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/722287 ID: 722291 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/722291 ID: 722293 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/722293 ID: 722295 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/722295 ID: 722296 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/722296 ID: 722299 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/722299 Old failures (same test failed in Fedora-IoT-34-20201014.0): ID: 722275 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/722275 Passed openQA tests: 14/16 (x86_64), 10/15 (aarch64) New passes (same test not passed in Fedora-IoT-34-20201014.0): ID: 722276 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/722276 ID: 722277 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/722277 ID: 722278 Test: x86_64 IoT-dvd_ostree-iso podman URL: https://openqa.fedoraproject.org/tests/722278 ID: 722279 Test: x86_64 IoT-dvd_ostree-iso podman_client URL: https://openqa.fedoraproject.org/tests/722279 ID: 722280 Test: x86_64 IoT-dvd_ostree-iso base_reboot_unmount URL: https://openqa.fedoraproject.org/tests/722280 ID: 722281 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay URL: https://openqa.fedoraproject.org/tests/722281 ID: 722282 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_rebase URL: https://openqa.fedoraproject.org/tests/722282 ID: 722283 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/722283 ID: 722284 Test: x86_64 IoT-dvd_ostree-iso base_system_logging URL: https://openqa.fedoraproject.org/tests/722284 ID: 722285 Test: x86_64 IoT-dvd_ostree-iso base_selinux URL: https://openqa.fedoraproject.org/tests/722285 ID: 722286 Test: x86_64 IoT-dvd_ostree-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/722286 ID: 722288 Test: x86_64 IoT-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/722288 ID: 722289 Test: x86_64 IoT-dvd_ostree-iso iot_greenboot URL: https://openqa.fedoraproject.org/tests/722289 ID: 722290 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/722290 ID: 722292 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/722292 ID: 722294 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi URL: https://openqa.fedoraproject.org/tests/722294 ID: 722297 Test: aarch64 IoT-dvd_ostree-iso base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/722297 ID: 722298 Test: aarch64 IoT-dvd_ostree-iso iot_greenboot@uefi URL: https://openqa.fedoraproject.org/tests/722298 ID: 722300 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/722300 ID: 722301 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/722301 ID: 722302 Test: aarch64 IoT-dvd_ostree-iso base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/722302 ID: 722303 Test: aarch64 IoT-dvd_ostree-iso base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/722303 ID: 722304 Test: aarch64 IoT-dvd_ostree-iso base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/722304 ID: 722305 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/722305 -- 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
Re: Highlights from the latest Copr release
On Saturday, November 14, 2020 2:36:43 PM CET Michael J Gruber wrote: > Same today: > > ssh: connect to host 3.237.199.13 port 22: Connection timed out > > https://download.copr.fedorainfracloud.org/results/mjg/scribus/fedora-32-x86_64/01768969-scribus156/builder-live.log.gz > > Copr infra networked borked? Meh, no. Sorry for inconvenience. We moved the copr backend to new VM and we kept the old one running because we still want to debug one old problem there. But there was a collision on one builder garbage collecting cron job which I just now stopped. It should be fixed now. Thank you for the report! Pavel ___ 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
Re: Highlights from the latest Copr release
Thanks for fixing it! I tried on irc, but I'm not an irc guy and couldn't make it past "cannot send to nick/channel" ... ___ 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
Re: Proposed updates to the FESCo updates policy document
On Fri, Nov 13, 2020 at 01:05:49AM +0100, Kevin Kofler via devel wrote: > Kevin Fenzi wrote: > > We have been over this. If anyone could untag anything they felt like it > > would make it much more difficult for everyone to integrate their > > changes with the rest of the collection. > > That issue is simply not something we have observed at any time back when > this untagging was still allowed. (And it was even possible as self-service > without involving rel-eng at all, because the Rawhide tag used to be open Actually it was... perhaps you just weren't affected? > before gating was introduced.) In the worst case, if some build(s) depends > on the untagged build(s), the dependent build(s) can simply be untagged as > well. Sure, but that wastes other peoples work, demotivates them from working on things and in general makes things unhappy. > It is definitely possible to revert to a consistent state, because one such > consistent state trivially exists: the one where *all* builds built after > the untagged build get untagged as well. But the minimal set of builds to > untag is typically much smaller, if it is even larger than a singleton (a > set consisting only of the one build you want to untag to begin with). If > the untagged package is a leaf package, the set is even guaranteed to be a > singleton (but that is not even a necessary condition, only a sufficient > condition). Sure, you can revert, but the longer you wait the more work has been done by others on top of what you are reverting. I agree there are some rare times when it's ok to do this, but just letting anyone do this anytime they like could make things worse for everyone IMHO. Anyhow, I guess lets agree to disagree... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposed updates to the FESCo updates policy document
On Fri, Nov 13, 2020 at 02:12:44PM +, Mattia Verga via devel wrote: > ... and third version: > > https://mattia.fedorapeople.org/updates_policy_v3.svg > https://mattia.fedorapeople.org/updates_policy_v3.png Thanks for working on this. ;) I still don't like 'bodhi activation point'. Can you change that to 'bodhi updates-testing activation point' ? Also, I wonder if there couldn't be some way to show the various branches? ie, that rawhide is always rawhide at the top, then branched is made off it, goes thru the process and becomes stable release Fn? Perhaps thats too complex, but it would show streams of releases coming off rawhide... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora rawhide compose report: 20201112.n.0 changes
On Fri, Nov 13, 2020 at 06:45:55PM +0100, Christopher Engelhard wrote: > Hi, > something weird is going on with the rawhide compose (thanks Vit for > alerting me) > > On 13.11.20 00:44, Fedora Rawhide Report wrote: > > Package: nextcloud-20.0.1-3.fc34 > > Old package: nextcloud-20.0.1-2.fc34 > > Summary: Private file sync and share server > > RPMs: nextcloud nextcloud-httpd nextcloud-mysql nextcloud-nginx > > nextcloud-postgresql nextcloud-sqlite > > Size: 415.35 MiB > > Size change: 325.60 MiB > > Changelog: > > * Wed Nov 11 2020 Christopher Engelhard - 20.0.1-3 > > - Remove CentOS/RHEL 7 support from spec file > > The only difference between the two builds is the removal of a separate > config file for EL7 from the .src.rpm. I checked the builds locally and > in koji[1][2] and the packages are virtually identical in size (~115MB > for the .src.rpm, ~90MB total for the rpms). > > Anybody any idea what is happening here? Weird. regular dnf repodiff doesn't show it: dnf repodiff -s --repofrompath old,https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-2020.n.0/compose/Everything/source/tree/ --repofrompath new,https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20201112.n.0/compose/Everything/source/tree/ --repo-old old --repo-new new ... nextcloud-20.0.1-2.fc34 -> nextcloud-20.0.1-3.fc34 -- * Wed Nov 11 2020 Christopher Engelhard - 20.0.1-3 - Remove CentOS/RHEL 7 support from spec file Size change: -158 bytes ... Perhaps it's a bug in compose-changelog? ( https://pagure.io/compose-utils ) kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Package sponsorship
Hello! I submitted a new package for the unit-testing library, which is approved already, but I have no sponsor yet. https://bugzilla.redhat.com/show_bug.cgi?id=1843300 I remember, when the package was approved, some sponsor has sent me an email with a task for checking my skills, but I lost this email somewhere and can not find it :/ I just want to ask, maybe you(sponsors) have some pending packages for reviewing to check or fix? I am continually looking for new packages at https://fedoraproject.org/wiki/PackageMaintainers/InProgressReviewRequests. Still, I can not find one where I can participate because most of them are already reviewed and waiting for maintainer response. Best Regards, Egor ___ 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
Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
On 5 November 2020 13:58:54 CET, Nico Kadel-Garcia wrote: > >sssd also breaks other LDAP setups, It's extremely broken with larger >LDAP setups because it insists on caching *ALL* of the LDAP, barring >being able to filter to only a smaller set of the LDAP. But because so >many LDAP setups scatter group and user information in so many >distinct parts of the LDAP layout, this never works and it *ALWAYS* >times out in large, remot4e LDAP setups. It works for a few seconds at >start time, then crashes and takes out *all* sssd based services. I don't share this experience and I run sssd in large environments. Sssd will by default lookup the user authenticating, the groups that user belongs to and all members of those groups. Looking up group members is easily turned off and leads to a much smoother experience from what I have seen. I still don't think deprecating nscd seems like a reasonable change. Change defaults, well ok. Deprecating, I don't really see why tbh. >___ >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 > ___ 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
Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
On Sat, Nov 14, 2020 at 5:11 PM Markus Larsson wrote: > > > > On 5 November 2020 13:58:54 CET, Nico Kadel-Garcia wrote: > > > >sssd also breaks other LDAP setups, It's extremely broken with larger > >LDAP setups because it insists on caching *ALL* of the LDAP, barring > >being able to filter to only a smaller set of the LDAP. But because so > >many LDAP setups scatter group and user information in so many > >distinct parts of the LDAP layout, this never works and it *ALWAYS* > >times out in large, remot4e LDAP setups. It works for a few seconds at > >start time, then crashes and takes out *all* sssd based services. > > I don't share this experience and I run sssd in large environments. Sssd will > by default lookup the user authenticating, the groups that user belongs to > and all members of those groups. > Looking up group members is easily turned off and leads to a much smoother > experience from what I have seen. > I still don't think deprecating nscd seems like a reasonable change. Change > defaults, well ok. Deprecating, I don't really see why tbh. Part of the difficulty comes when you only want to see certain LDAP groups, or permit access only for certain groups. When those groups are scattered around a poorly organized LDAP layout, it means you need to cache *all* the relevant OU's. Unless your pipeline to your remote environment is large, or you have deployed local LDAP servers to provide a remote mirror, the bulk pre-caching times out and causes all sssd related daemons to turn off after working for a short period, the daemons die. This was *nasty* when I observed it a few years ago, I had to convince the LDAP admins to set up new mirror groups in a much smaller OU workspace. ___ 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
Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
On 14 November 2020 23:35:09 CET, Nico Kadel-Garcia wrote: >On Sat, Nov 14, 2020 at 5:11 PM Markus Larsson wrote: >> >> >> >> On 5 November 2020 13:58:54 CET, Nico Kadel-Garcia wrote: >> > >> >sssd also breaks other LDAP setups, It's extremely broken with larger >> >LDAP setups because it insists on caching *ALL* of the LDAP, barring >> >being able to filter to only a smaller set of the LDAP. But because so >> >many LDAP setups scatter group and user information in so many >> >distinct parts of the LDAP layout, this never works and it *ALWAYS* >> >times out in large, remot4e LDAP setups. It works for a few seconds at >> >start time, then crashes and takes out *all* sssd based services. >> >> I don't share this experience and I run sssd in large environments. Sssd >> will by default lookup the user authenticating, the groups that user belongs >> to and all members of those groups. >> Looking up group members is easily turned off and leads to a much smoother >> experience from what I have seen. >> I still don't think deprecating nscd seems like a reasonable change. Change >> defaults, well ok. Deprecating, I don't really see why tbh. > >Part of the difficulty comes when you only want to see certain LDAP >groups, or permit access only for certain groups. When those groups >are scattered around a poorly organized LDAP layout, it means you need >to cache *all* the relevant OU's. Unless your pipeline to your remote >environment is large, or you have deployed local LDAP servers to >provide a remote mirror, the bulk pre-caching times out and causes all >sssd related daemons to turn off after working for a short period, the >daemons die. This was *nasty* when I observed it a few years ago, I >had to convince the LDAP admins to set up new mirror groups in a much >smaller OU workspace. Sounds like a horrible experience. It seems circumventable by not caching entire OUs though. They way sssd has been used where I have been it has only cached users actually logging in. That's a single setting in sssd.conf that makes all the difference. Not saying you're wrong though, I've just never seen the issue over the years. I have seen early sssd take down an AD domain controller do to aggressively asking for every user but that was many years ago :) ___ 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
Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
On Sat, Nov 14, 2020 at 6:02 PM Markus Larsson wrote: > Sounds like a horrible experience. It seems circumventable by not caching > entire OUs though. They way sssd has been used where I have been it has only > cached users actually logging in. That's a single setting in sssd.conf that > makes all the difference. > Not saying you're wrong though, I've just never seen the issue over the years. > I have seen early sssd take down an AD domain controller do to aggressively > asking for every user but that was many years ago :) Which setting are you referring to? Because a couple of years ago, I couldn't find a graceful way to prevent it. ___ 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
Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
On Sat, 2020-11-14 at 19:11 -0500, Nico Kadel-Garcia wrote: > On Sat, Nov 14, 2020 at 6:02 PM Markus Larsson > wrote: > > > Sounds like a horrible experience. It seems circumventable by not > > caching entire OUs though. They way sssd has been used where I have > > been it has only cached users actually logging in. That's a single > > setting in sssd.conf that makes all the difference. > > Not saying you're wrong though, I've just never seen the issue over > > the years. > > I have seen early sssd take down an AD domain controller do to > > aggressively asking for every user but that was many years ago :) > > Which setting are you referring to? Because a couple of years ago, I > couldn't find a graceful way to prevent it. ignore_group_members is the one. It has other implications which can make a fuzz in certain situations though. Generally what is problematic in my book is that most LDAP directories has a group that contains every user of the directory which promts sssd to pull every user. One could also mask the offending group and in some case that solves the issue. I feel your pain though, I have seen quite a few LDAPs but never a tidy one (not even my freeipa at home is as tidy as I would like it to be). ___ 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
Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
Matthew Miller wrote: > But that's policy as well. It would be reasonable to have a different > policy, like "build and soft dependencies are okay from base -> secondary, > but not hard runtime requirements". But a build-time dependency often automatically results in a hard runtime dependency, e.g., for C/C++ libraries. A common issue in the Core vs. Extras days was that a package in Core had to be compiled without some compile-time-optional feature because that feature would have depended on a library in Extras. The above proposal would not solve this issue. Kevin Kofler ___ 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
Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
Ken Dreyer wrote: > On Fri, Nov 13, 2020 at 3:23 PM Matthew Miller > wrote: >> That reason was _mainly_ to erase the inside Red Hat, >> community-around-the-edges distinction. That was a huge success and >> Fedora wouldn't be interesting without that. But I think the _technical_ >> choice was in retrospect a mistake. There's a reason RHEL 8 switched the >> _other_ way. > > It's true that RHEL 8 split content into BaseOS and AppStream, but the > technical reasons for that particular split were never clear to me. As far as I know, all the splitting done in RHEL, also the individual modules within the modular AppStream repository, is done mainly for business reasons that do not apply to Fedora at all. Kevin Kofler ___ 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
Re: Boot/Install from iso file
Isn't there anyone that tried to do that? :-)
Taking into account that Fedora is a distro that is always searching to be
on the cutting edge: Don't you think that is somewhat annoying and a thing
of the past to install from a usb stick (and not to mention from CD)?
It could be nice to download the Fedora ISO to local drive and to install
from it in a straightforward fashion... and to rely on some grub alchemy,
It could be nice that you could tell the installer where do you have the
iso file and install using it..
Yes I know, it sounds crazy, but sometimes nice things are born so...
Greetings
El mar., 10 nov. 2020 a las 10:16, Sergio Belkin ()
escribió:
> Hi!
> I have the following /etc/grub.d/40_custom file:
> #!/usr/bin/sh
> exec tail -n +3 $0
> # This file provides an easy way to add custom menu entries. Simply type
> the
> # menu entries you want to add after this comment. Be careful not to
> change
> # the 'exec tail' line above.
>
> menuentry "Start Fedora-KDE-Live 33" --class fedora {
> set isofile="/Fedora-KDE-Live-x86_64-33-1.2.iso"
> loopback loop (lvm/fedora-home)/sergio/Descargas/Distros$isofile
> linuxefi (loop)/isolinux/vmlinuz iso-scan/filename=${isofile}
> root=live:CDLABEL=Fedora-KDE-Live-33-1-2 rd.live.image
> initrdefi (loop)/isolinux/initrd.img
> }
> EOF
>
>
> I have used that configuration a few years ago, but now it does not work.
> If I choose that grub entry the screen goes black and I have to reboot. Is
> there something wrong in my custom file?
>
> Thanks in advance!
>
> --
> --
> Sergio Belkin
> LPIC-2 Certified - http://www.lpi.org
>
--
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
___
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
Re: Boot/Install from iso file
On 11/14/20 7:44 PM, Sergio Belkin wrote: Isn't there anyone that tried to do that? :-) Taking into account that Fedora is a distro that is always searching to be on the cutting edge: Don't you think that is somewhat annoying and a thing of the past to install from a usb stick (and not to mention from CD)? It could be nice to download the Fedora ISO to local drive and to install from it in a straightforward fashion... and to rely on some grub alchemy, I really don't see how this is useful, but I did spend some time trying it. The kernel and initrd loaded fine from the iso, but I haven't been able to figure out how to get it to start the installer from there. ___ 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
Fedora-Cloud-33-20201115.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20201112.0): ID: 722312 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/722312 ID: 722319 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/722319 Passed openQA tests: 6/7 (x86_64), 6/7 (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
