[rpms/perl-Net-Netmask] PR #1: Tests
jplesnik opened a new pull-request against the project: `perl-Net-Netmask` that you are following: `` Tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Net-Netmask/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20210330.n.0 compose check report
No missing expected images. Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 6/189 (x86_64), 17/127 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210329.n.0): ID: 837333 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/837333 ID: 837390 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/837390 ID: 837398 Test: aarch64 Server-dvd-iso install_blivet_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/837398 ID: 837406 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/837406 ID: 837429 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/837429 ID: 837527 Test: aarch64 universal install_mirrorlist_graphical@uefi URL: https://openqa.fedoraproject.org/tests/837527 ID: 837554 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/837554 ID: 837566 Test: aarch64 universal install_kickstart_nfs@uefi URL: https://openqa.fedoraproject.org/tests/837566 Old failures (same test failed in Fedora-Rawhide-20210329.n.0): ID: 837293 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/837293 ID: 837337 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/837337 ID: 837341 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/837341 ID: 837369 Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/837369 ID: 837370 Test: aarch64 Minimal-raw_xz-raw.xz base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/837370 ID: 837371 Test: aarch64 Minimal-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/837371 ID: 837372 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/837372 ID: 837373 Test: aarch64 Minimal-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/837373 ID: 837374 Test: aarch64 Minimal-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/837374 ID: 837375 Test: aarch64 Minimal-raw_xz-raw.xz base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/837375 ID: 837411 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/837411 ID: 837452 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/837452 ID: 837453 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/837453 ID: 837528 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/837528 ID: 837558 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/837558 Soft failed openQA tests: 46/127 (aarch64), 69/189 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20210329.n.0): ID: 837388 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/837388 Old soft failures (same test soft failed in Fedora-Rawhide-20210329.n.0): ID: 837256 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/837256 ID: 837257 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/837257 ID: 837263 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/837263 ID: 837264 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/837264 ID: 837268 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/837268 ID: 837270 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/837270 ID: 837271 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/837271 ID: 837272 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/837272 ID: 837292 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/837292 ID: 837294 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/837294 ID: 837302 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/837302 ID: 837303 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/837303 ID: 837305 Test: x86_64 Server-dvd-iso
Fedora-34-20210330.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Failed openQA tests: 5/178 (x86_64), 40/127 (aarch64) New failures (same test not failed in Fedora-34-20210329.n.0): ID: 837005 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/837005 ID: 837031 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/837031 ID: 837054 Test: aarch64 Minimal-raw_xz-raw.xz base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/837054 ID: 837055 Test: aarch64 Minimal-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/837055 ID: 837059 Test: aarch64 Minimal-raw_xz-raw.xz base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/837059 ID: 837072 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/837072 ID: 837075 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/837075 ID: 837076 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/837076 ID: 837081 Test: aarch64 Server-dvd-iso base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/837081 ID: 837087 Test: aarch64 Server-dvd-iso install_repository_nfsiso_variation@uefi URL: https://openqa.fedoraproject.org/tests/837087 ID: 837088 Test: aarch64 Server-dvd-iso release_identification@uefi URL: https://openqa.fedoraproject.org/tests/837088 ID: 837089 Test: aarch64 Server-dvd-iso install_updates_nfs@uefi URL: https://openqa.fedoraproject.org/tests/837089 ID: 837091 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/837091 ID: 837093 Test: aarch64 Server-dvd-iso base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/837093 ID: 837098 Test: aarch64 Server-dvd-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/837098 ID: 837101 Test: aarch64 Server-dvd-iso install_repository_nfs_graphical@uefi URL: https://openqa.fedoraproject.org/tests/837101 ID: 837108 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/837108 ID: 837109 Test: aarch64 Server-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/837109 ID: 837110 Test: aarch64 Server-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/837110 ID: 837112 Test: aarch64 Server-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/837112 ID: 837115 Test: aarch64 Workstation-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/837115 ID: 837118 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/837118 ID: 837119 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/837119 ID: 837120 Test: aarch64 Workstation-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/837120 ID: 837121 Test: aarch64 Workstation-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/837121 ID: 837122 Test: aarch64 Workstation-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/837122 ID: 837123 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi URL: https://openqa.fedoraproject.org/tests/837123 ID: 837124 Test: aarch64 Workstation-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/837124 ID: 837228 Test: aarch64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/837228 ID: 837238 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/837238 ID: 837241 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/837241 ID: 837253 Test: aarch64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/837253 Old failures (same test failed in Fedora-34-20210329.n.0): ID: 837032 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/837032 ID: 837036 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/837036 ID: 837053 Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/837053 ID: 837056 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/837056 ID: 837057 Test: aarch64 Minimal-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/837057 ID: 837058 Test: aarch64 Minimal-raw_xz-raw.xz
Fedora-Cloud-33-20210330.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-20210329.0): ID: 836923 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/836923 ID: 836930 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/836930 Passed openQA tests: 6/7 (aarch64), 6/7 (x86_64) New passes (same test not passed in Fedora-Cloud-33-20210329.0): ID: 836935 Test: aarch64 Cloud_Base-qcow2-qcow2 base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/836935 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: selinux-policy package versioning change
On Mon, Mar 29, 2021 at 1:56 PM Zdenek Pytela wrote: > We do not expect any impact to end users neither to developers unless the > exact version was used somewhere. If there are no objections, we will make > the change in a week time. Final freeze begins a week from today. Even though the change is intended to be transparent, I wonder if it's better to make sure the change happens before freeze rather than appearing in an update after release with a different versioning scheme on released media (ISOs and images, etc). I mention it now because for whatever reason some things that were stable already in the hours before beta freeze actually didn't make it onto beta composes. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-32-20210330.0 compose check report
No missing expected images. Failed openQA tests: 1/7 (aarch64) New failures (same test not failed in Fedora-Cloud-32-20210329.0): ID: 836946 Test: aarch64 Cloud_Base-qcow2-qcow2 base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/836946 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-20210329.0): ID: 836938 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/836938 ID: 836945 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/836945 Passed openQA tests: 6/7 (x86_64), 5/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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1941280] perl-Module-CoreList-5.20210320 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1941280 --- Comment #18 from Fedora Update System --- FEDORA-MODULAR-2021-d2bbd86f06 has been pushed to the Fedora 32 Modular stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1928387] perl-ExtUtils-CBuilder-0.280236 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1928387 --- Comment #13 from Fedora Update System --- FEDORA-MODULAR-2021-d2bbd86f06 has been pushed to the Fedora 32 Modular stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1941280] perl-Module-CoreList-5.20210320 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1941280 --- Comment #17 from Fedora Update System --- FEDORA-MODULAR-2021-36caf59de1 has been pushed to the Fedora 33 Modular stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1928387] perl-ExtUtils-CBuilder-0.280236 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1928387 --- Comment #12 from Fedora Update System --- FEDORA-MODULAR-2021-36caf59de1 has been pushed to the Fedora 33 Modular stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1928387] perl-ExtUtils-CBuilder-0.280236 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1928387 --- Comment #11 from Fedora Update System --- FEDORA-MODULAR-2021-1c0b6fab46 has been pushed to the Fedora 34 Modular stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1941280] perl-Module-CoreList-5.20210320 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1941280 --- Comment #16 from Fedora Update System --- FEDORA-MODULAR-2021-1c0b6fab46 has been pushed to the Fedora 34 Modular stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20210330.n.0 changes
OLD: Fedora-Rawhide-20210329.n.0 NEW: Fedora-Rawhide-20210330.n.0 = SUMMARY = Added images:0 Dropped images: 9 Added packages: 6 Dropped packages:4 Upgraded packages: 131 Downgraded packages: 0 Size of added packages: 3.80 MiB Size of dropped packages:168.86 KiB Size of upgraded packages: 6.50 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 196.60 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20210329.n.0.ppc64le.qcow2 Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20210329.n.0.iso Image: LXQt live x86_64 Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-Rawhide-20210329.n.0.iso Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20210329.n.0.iso Image: Everything boot ppc64le Path: Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-Rawhide-20210329.n.0.iso Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20210329.n.0.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20210329.n.0.iso Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20210329.n.0.ppc64le.tar.xz Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20210329.n.0.ppc64le.raw.xz = ADDED PACKAGES = Package: eth-tools-11.0.0.0-163.fc35 Summary: Intel Ethernet Fabric Suite basic tools and libraries for fabric management RPMs:eth-tools-basic eth-tools-fastfabric Size:701.75 KiB Package: python-doubleratchet-0.7.0~beta-3.fc35 Summary: Python implementation of the Double Ratchet algorithm RPMs:python3-doubleratchet Size:39.27 KiB Package: python-editdistance-s-1.0.0-1.fc35 Summary: Fast implementation of the Levenshtein distance RPMs:python3-editdistance-s Size:129.48 KiB Package: python-pyunicorn-0.6.1-2.fc35 Summary: Unified complex network and recurrence analysis toolbox RPMs:python3-pyunicorn Size:2.36 MiB Package: s-tui-1.1.1-1.fc35 Summary: Terminal-based CPU stress and monitoring utility RPMs:s-tui Size:77.57 KiB Package: softfloat-3.5.0-1.20210329git42f2f99.fc35 Summary: Berkeley IEEE Binary Floating-Point Library RPMs:softfloat-devel Size:525.54 KiB = DROPPED PACKAGES = Package: php-jeremeamia-superclosure-2.4.0-8.fc34 Summary: Serialize Closure objects, including their context and binding RPMs:php-jeremeamia-superclosure Size:23.79 KiB Package: php-justinrainbow-json-schema-2.0.5-14.fc34 Summary: A library to validate a json schema RPMs:php-justinrainbow-json-schema Size:31.95 KiB Package: php-justinrainbow-json-schema4-4.1.0-11.fc34 Summary: A library to validate a json schema RPMs:php-justinrainbow-json-schema4 Size:35.36 KiB Package: python-s-tui-1.1.1-3.fc35 Summary: Terminal-based CPU stress and monitoring utility RPMs:python3-s-tui Size:77.76 KiB = UPGRADED PACKAGES = Package: adcli-0.9.1-3.fc35 Old package: adcli-0.9.1-2.fc35 Summary: Active Directory enrollment RPMs: adcli adcli-doc Size: 663.62 KiB Size change: -1.07 KiB Changelog: * Mon Mar 29 2021 Sumit Bose - 0.9.1-3 - Add vendor error message Resolves: rhbz#1889386 Package: arpwatch-14:3.1-10.fc35 Old package: arpwatch-14:3.1-9.fc35 Summary: Network monitoring tools for tracking IP addresses on a network RPMs: arpwatch Size: 1.53 MiB Size change: 1.96 KiB Changelog: * Mon Mar 29 2021 Benjamin A. Beasley - 14:3.1-10 - generate ethercodes.dat from latest oui.csv Package: awscli-1.19.39-1.fc35 Old package: awscli-1.19.37-1.fc35 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 2.00 MiB Size change: 258 B Changelog: * Mon Mar 29 2021 Gwyn Ciesla - 1.19.39-1 - 1.19.39 Package: bcc-0.19.0-1.fc35 Old package: bcc-0.18.0-4.fc35 Summary: BPF Compiler Collection (BCC) RPMs: bcc bcc-devel bcc-doc bcc-lua bcc-tools python3-bcc Size: 5.97 MiB Size change: -2.24 MiB Changelog: * Mon Mar 29 2021 Jiri Olsa - 0.19.0-1 - Rebase to latest upstream Package: clipit-1.4.5-2.fc35 Old package: clipit-1.4.5-1.fc35 Summary: A lightweight, fully featured GTK+ clipboard manager RPMs: clipit Size: 444.72 KiB Size change: 910 B Changelog: * Mon Mar 29 2021 Mamoru TASAKA - 1.4.5-2 - Force GDK_BACKEND to x11 (bug 1943480, bug 1943509) Package: container-selinux-2:2.159.0-2.dev.gitd89a599.fc35 Old package: container-selinux-2:2.158.0-5.dev.gite78ac4f.fc35 Summary: SELinux policies for container runtimes RPMs: container-selinux Size: 47.97 KiB Size change: -1.49 KiB Changelog: * Mon Mar 29 2021 RH Container Bot
[Bug 1943595] perl-PPIx-Regexp-0.079 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1943595 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-PPIx-Regexp-0.079-1.fc |perl-PPIx-Regexp-0.079-1.fc |35 |35 ||perl-PPIx-Regexp-0.079-1.fc ||34 Resolution|--- |ERRATA Last Closed||2021-03-31 00:16:29 --- Comment #4 from Fedora Update System --- FEDORA-2021-6483127319 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 34 compose report: 20210330.n.0 changes
OLD: Fedora-34-20210329.n.0 NEW: Fedora-34-20210330.n.0 = SUMMARY = Added images:0 Dropped images: 21 Added packages: 4 Dropped packages:0 Upgraded packages: 63 Downgraded packages: 0 Size of added packages: 7.88 MiB Size of dropped packages:0 B Size of upgraded packages: 352.40 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -49.35 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Container_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Base-34-20210329.n.0.aarch64.tar.xz Image: Container_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Base-34-20210329.n.0.x86_64.tar.xz Image: Container_Minimal_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Minimal-Base-34-20210329.n.0.x86_64.tar.xz Image: Xfce raw-xz armhfp Path: Spins/armhfp/images/Fedora-Xfce-34-20210329.n.0.armhfp.raw.xz Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-34-20210329.n.0.iso Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-34-20210329.n.0.aarch64.raw.xz Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-34-20210329.n.0.s390x.tar.xz Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-34-20210329.n.0.s390x.tar.xz Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-34-20210329.n.0.ppc64le.tar.xz Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-34-20210329.n.0.ppc64le.tar.xz Image: Design_suite live x86_64 Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-34-20210329.n.0.iso Image: SoaS raw-xz armhfp Path: Spins/armhfp/images/Fedora-SoaS-34-20210329.n.0.armhfp.raw.xz Image: Container_Minimal_Base docker armhfp Path: Container/armhfp/images/Fedora-Container-Minimal-Base-34-20210329.n.0.armhfp.tar.xz Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-34-20210329.n.0.iso Image: Cloud_Base tar-gz x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-GCP-34-20210329.n.0.x86_64.tar.gz Image: Container_Base docker armhfp Path: Container/armhfp/images/Fedora-Container-Base-34-20210329.n.0.armhfp.tar.xz Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-34-20210329.n.0.iso Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-34-20210329.n.0.iso Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-34-20210329.n.0.iso Image: SoaS raw-xz aarch64 Path: Spins/aarch64/images/Fedora-SoaS-34-20210329.n.0.aarch64.raw.xz Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-34-20210329.n.0.aarch64.tar.xz = ADDED PACKAGES = Package: r2cutter-0.1.1-4.fc34 Summary: GUI for radare2 reverse engineering framework RPMs:r2cutter r2cutter-devel Size:7.66 MiB Package: rust-quickcheck0.9-0.9.2-1.fc34 Summary: Automatic property based testing with shrinking RPMs:rust-quickcheck0.9+default-devel rust-quickcheck0.9+env_logger-devel rust-quickcheck0.9+log-devel rust-quickcheck0.9+regex-devel rust-quickcheck0.9+unstable-devel rust-quickcheck0.9+use_logging-devel rust-quickcheck0.9-devel Size:76.35 KiB Package: rust-socket2_0.3-0.3.19-1.fc34 Summary: Utilities for handling networking sockets RPMs:rust-socket2_0.3+default-devel rust-socket2_0.3+pair-devel rust-socket2_0.3+reuseport-devel rust-socket2_0.3+unix-devel rust-socket2_0.3-devel Size:65.67 KiB Package: s-tui-1.1.1-1.fc34 Summary: Terminal-based CPU stress and monitoring utility RPMs:s-tui Size:77.54 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: atasm-1.09-1.fc34 Old package: atasm-1.08-8.fc34 Summary: 6502 cross-assembler RPMs: atasm Size: 342.68 KiB Size change: 4.09 KiB Changelog: * Thu Mar 25 2021 Dan Hor??k - 1.09-1 - update to 1.09 - CVE-2019-19785 CVE-2019-19786 CVE-2019-19787 Package: beakerlib-1.27-1.fc34 Old package: beakerlib-1.26-1.fc34 Summary: A shell-level integration testing library RPMs: beakerlib beakerlib-vim-syntax Size: 172.81 KiB Size change: 1.35 KiB Changelog: * Thu Mar 25 2021 Dalibor Pospisil - 1.27-1 - rlCheckRequirements is now able to check also versions requirements Package: beep-1.4.7-6.fc34 Old package: beep-1.4.7-4.fc34 Summary: Beep the PC speaker any number of ways RPMs: beep Size: 209.54 KiB Size change: 3.44 KiB Changelog: * Wed Mar 24 2021 Hans Ulrich Niedermann - 1.4.7-5 - Add "Recommends: kmod(pcspkr.ko)" to install the driver if available (#1942670) * Thu Mar 25 2021 Hans Ulrich Niedermann - 1.4.7-6 - Remove any kmod(pcspkr.ko) dependencies as they install the wrong package Package: caja-1.24.1-1.fc34 O
Re: Proposal to fail builds if RPATH is found in Fedora 35
On Fri, Mar 26, 2021, at 2:06 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Mar 26, 2021 at 06:51:56PM +0100, Miro Hrončok wrote: > > On 26. 03. 21 18:24, Charalampos Stratakis wrote: > > >python2.7churchyard cstratak torsava vstinner > > > > I was curious. The error is: > > > > 0001: file '/usr/lib64/python2.7/lib-dynload/pyexpat.so' contains a > > standard > > rpath '/usr/lib64' in [/usr/lib64] > > > > And the cause is... our own patch > > > > https://src.fedoraproject.org/rpms/python2.7/blob/rawhide/f/00187-add-RPATH-to-pyexpat.patch > > > > For reasons I don't understand, the bugzilla referenced from the > > patch is private. It is a RHEL 6.2 bugzilla from 2012 that could be > > summarized as: > > > > "If the user sets $LD_LIBRARY_PATH to a directory with > > broken/incompatible libraries, Python breaks." > > I'd vote for treating this as the wrong solution in the wrong place. > If you set LD_LIBRARY_PATH, you get to keep both pieces if anything goes > wrong. > Agreed. /me glares at SCL for LD_LIBRARY_PATH brokenness V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rebuilding packages that use std::call_once from libstdc++
Hi, Jonathan Wakely writes: > Due to an unplanned ABI break that I caused in libstdc++, I will soon > start to rebuild the packages listed below. This rebuild will remove > references to some symbols in libstdc++.so which do not work as > intended, and so will not be present in the final gcc-11.1.0 release. > > See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference. > > Package maintainers should not need to do anything, but will see a > %release bump and a rebuild. > dotnet3.1 I am bit surprised that dotnet3.1 is in that list but not dotnet5.0. Is there some way I can confirm whether a package (like dotnet5.0) is affected or not? Thanks, Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Account Migration & Production Deployment Update: COMPLETE!
On Tue, Mar 30, 2021 at 09:30:33AM +0300, Alexander Bokovoy wrote: > > Could you please explain where you want to do it? Noggin (Fedora > Accounts app) does handle the login itself, not FreeIPA. In the context > of what Fedora contributors interact with, FreeIPA is only directly > exposed via Kerberos authentication flow. Well, I don't know. I am not implementing anything myself. I should leave that to the people who would be implemnting things (the noggin team). > > Noggin can be modified to accept separate password and token values. In > fact, FreeIPA Web UI does have password-based login implemented in this > way -- there are separate password and token value login fields if user > has OTP associated. Yeah, note that we are using IPA / RHEL8. It does not have seperate password and token fields, so I assume this is something coming to IPA soon. :) > Security query/response pairs are something that Noggin would need to > manage on top of FreeIPA as well and thus would handle login with them. > We do not have any mechanism in FreeIPA to allow you to handle this on > behalf of Noggin. ok > For security query/response pairs to be useful in FreeIPA context, > they'd need to be plugged into the main password change flows. There are > currently two major ones and the rest just piggy-backs on either of > them: > > - a password change via LDAP protocol > - a password change via Kerberos protocol > > Our current scheme for resetting forgotten or unknown passwords in > FreeIPA requires administrators to initiate a reset with a temporary > password, pre-set or randomly generated. Then a user changes the > password via one of the two methods above -- either directly or with the > help of one of applications that utilize those, by specifying the > temporary password first and providing a new one afterwards. > > Kerberos password change protocol implements a single request and a > single reply message where the request is initiated by a client and the > server replies with a success or an error, after which the password is > either updated or not. The request sent by the client includes a single > user-data component (part of generic Kerberos KRB_PRIV message as per > RFC4120 section 5.7.1). I don't think this is supported via KDCproxy is it? > > LDAP password change may include and return a control that could be used > to pass through some additional information in both directions with a > bit more flexibility than on the Kerberos side. It still requires that > an LDAP client implements this exchange so Noggin would need to > implement the logic for this too. ok. > If we'd want to add security query/response pairs to allow users to > 'securely' reset their passwords initiated by themselves, this would be > possible with an appropriate extension of an LDAP control and changes to > FreeIPA Web UI and Noggin to support that. The bigger problem is to find > a way to securely store these pairs encrypted per user. Right now the > only per-user secret we have is something generated with the help of its > password but since this is all about being able to reset that password > without knowing its content, we need somewhat different method that > would still be secure against others. In FreeIPA nobody, including > administrators, is able to discover the user's password from a hashed > form. Yeah, this stuff is not at all easy... will talk with the noggin folks and see if we can come up with anything that we might want to persue. Thanks! kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: selinux-policy package versioning change
On Tue, Mar 30, 2021, at 3:56 PM, Zdenek Pytela wrote: > > > On Mon, Mar 29, 2021 at 10:45 PM justina colmena ~biz > wrote: > > I'm still a little bit confused about the SELinux targeted policy > > "development" process versus the actual "roll-out," implementation, and > > deployment not only to Fedora on the deskop, but to various distributions > > of > > "CentOS" or commercial installations of Red Hat Enterprise Linux (RHEL) "in > > the cloud" especially on OpenVZ or other shared-kernel virtualization > > technologies as the case may be for businesses and end users who might > > otherwise benefit from SELinux Mandatory Access Control policies built in > > to > > the Linux kernel. > Most of the development happens in the rawhide github branch and > selected commits subsequently go to stable Fedora releases as well as > to Centos Stream and RHEL. There is no package difference between > various Fedora editions and spins for the same version. Would the RHEL 9 package have version 34 under this scheme? V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Work getting hwcaps microchiecture package geneataion into rpm
It says all the pull request checks have passed but they haven't done them yet. Unfortunately. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Display a message on the console while upgrading a package
On Tue, 2021-03-30 at 19:35 +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Mar 30, 2021 at 06:54:25PM +, Gary Buhrmaster wrote: > > On Tue, Mar 30, 2021 at 6:18 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > There is no good way to do this. > > > > This is one of those cases where I occasionally > > miss a mainframe fix update feature to prevent > > certain bad automated results. > > > > In SMP/E, there was the concept of HOLD's for > > a fix. There were a number of HOLD reasons, > > but one was ACTION, which prevented the > > application of the fix unless the HOLD was > > released. I.e. you had to read the docs and > > either do, or prepare to do, whatever the > > ACTION said to do before you could proceed > > FWIW, with Debian's apt, that's more or less what you get: the > upgrade > will block and ask questions. I remember quite a few times I got burned by this behavior on Debian based systems - nothing better than to start a big system update and go away only to come back hours later and find it stuck at the ~10th package asking some useless question and not progressing with the update at all. Also given that package update transactions are not always atomic and can easily result in a broken system if interrupted in the middle, this also makes breakage more likely as the transaction remains in vulnerable state much longer than it would be otherwise necessary, waiting for the user to notice and answer the question. > We have never done this in the rpm world, > and while sometimes this makes things harder, I think this is the > right > choice in the long run. Essentially, interactive questions during > upgrades > are are fine as long as you have one or two or three servers per > human, > *and* the human has time and knowledge and energy to deal with the > questions. > But the world has changed, and we have many more machines per person, > and > many more non-power users then ever. > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: selinux-policy package versioning change
On Mon, Mar 29, 2021 at 10:45 PM justina colmena ~biz wrote: > I'm still a little bit confused about the SELinux targeted policy > "development" process versus the actual "roll-out," implementation, and > deployment not only to Fedora on the deskop, but to various distributions > of > "CentOS" or commercial installations of Red Hat Enterprise Linux (RHEL) > "in > the cloud" especially on OpenVZ or other shared-kernel virtualization > technologies as the case may be for businesses and end users who might > otherwise benefit from SELinux Mandatory Access Control policies built in > to > the Linux kernel. > Most of the development happens in the rawhide github branch and selected commits subsequently go to stable Fedora releases as well as to Centos Stream and RHEL. There is no package difference between various Fedora editions and spins for the same version. > On Monday, March 29, 2021 11:56:23 AM AKDT Zdenek Pytela wrote: > > Hi, > > > > We plan to change the versioning scheme of the selinux-policy packages. > > > > Based on a request to using tags in selinux-policy github repo, we > > discussed further actions and possible automation and decided to couple > the > > tags with the package version, together with making a change for better > > comprehensibility. > > > > So far, the package version changed with branching a new Fedora release > off > > rawhide (e. g. 3.14.6 to 3.14.7), and the release part of the NVR scheme > > was used for updates (3.14.7-1). After the change, the version would > > contain the Fedora branch number and the sequential number of the package > > in the branch (34.1), and the release part would be used only for changes > > in packaging (34.1-1). It would apply to Fedora 34 and newer. > > > > In github repo, tags matching the Fedora package version would be used > > (v34.1), pairing the latest commit in github with the latest commit in > the > > package (34.1-1). > > > > We do not expect any impact to end users neither to developers unless the > > exact version was used somewhere. If there are no objections, we will > make > > the change in a week time. > > > > Cheers, > > -- Zdenek Pytela Security SELinux team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Display a message on the console while upgrading a package
On Tue, Mar 30, 2021 at 06:54:25PM +, Gary Buhrmaster wrote: > On Tue, Mar 30, 2021 at 6:18 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > There is no good way to do this. > > This is one of those cases where I occasionally > miss a mainframe fix update feature to prevent > certain bad automated results. > > In SMP/E, there was the concept of HOLD's for > a fix. There were a number of HOLD reasons, > but one was ACTION, which prevented the > application of the fix unless the HOLD was > released. I.e. you had to read the docs and > either do, or prepare to do, whatever the > ACTION said to do before you could proceed FWIW, with Debian's apt, that's more or less what you get: the upgrade will block and ask questions. We have never done this in the rpm world, and while sometimes this makes things harder, I think this is the right choice in the long run. Essentially, interactive questions during upgrades are are fine as long as you have one or two or three servers per human, *and* the human has time and knowledge and energy to deal with the questions. But the world has changed, and we have many more machines per person, and many more non-power users then ever. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Planned Outage - System upgrades - 2021-04-01 19:00 UTC
There will be an outage starting at 2021-04-01 19:00 UTC, which will last approximately 5 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-04-01 19:00UTC' Reason for outage: We will be updating and rebooting various servers to bring them up to date and confirm changes from the recent account system migration. During the outage window services may be up or down as various systems reboot. No one service should be affected very long. Affected Services: Most services will be affected, with the exception of: mirrorlists, docs, hotspot, geoip, and getfedora. Ticket Link: https://pagure.io/fedora-infrastructure/issue/9814 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Display a message on the console while upgrading a package
On Tue, 2021-03-30 at 19:11 +0200, Robert-André Mauchin wrote:
> Hello,
>
> Following a change in the config file of a program, I'd like to display
> a message to my users to indicate they need to update the config file
> with the new one. I try "echo" in the update scriptlet:
>
> %postun
> if [ "$1" -ge "1" ] ; then # Upgrade
> dnscrypt-proxy -service install --config
> %{_sysconfdir}/dnscrypt-proxy/dnscrypt-proxy.toml
> echo 'Since version 2.0.45, some of the configuration files have been
> renamed.
> Please merge your config to
> /etc/dnscrypt-proxy/dnscrypt-proxy.toml.rpmnew then
> replace dnscrypt-proxy.toml with that file.
> Read /usr/share/doc/dnscrypt-proxy/ChangeLog to merge files accordingly.'
> fi
>
> But it doesn't work as expected. Is there a way to transmit that message
> to my users?
Besides putting it in the update description, no.
You cannot assume that updates are done attended, or done from a
console. What if they're using dnf-automatic? What if they're using a
graphical application which doesn't display console output?
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Display a message on the console while upgrading a package
On Tue, Mar 30, 2021 at 6:18 PM Zbigniew Jędrzejewski-Szmek wrote: > There is no good way to do this. This is one of those cases where I occasionally miss a mainframe fix update feature to prevent certain bad automated results. In SMP/E, there was the concept of HOLD's for a fix. There were a number of HOLD reasons, but one was ACTION, which prevented the application of the fix unless the HOLD was released. I.e. you had to read the docs and either do, or prepare to do, whatever the ACTION said to do before you could proceed Of course, one could just set up systems to bypass all the HOLDs if appropriate for your use case, but it could prevent certain errors from occurring without at least thinking about the implications of applying the fix. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Display a message on the console while upgrading a package
On Tue, Mar 30, 2021 at 07:11:16PM +0200, Robert-André Mauchin wrote:
> Hello,
>
> Following a change in the config file of a program, I'd like to
> display a message to my users to indicate they need to update the
> config file with the new one. I try "echo" in the update scriptlet:
>
> %postun
> if [ "$1" -ge "1" ] ; then # Upgrade
> dnscrypt-proxy -service install --config
> %{_sysconfdir}/dnscrypt-proxy/dnscrypt-proxy.toml
> echo 'Since version 2.0.45, some of the configuration files have
> been renamed.
> Please merge your config to
> /etc/dnscrypt-proxy/dnscrypt-proxy.toml.rpmnew then
> replace dnscrypt-proxy.toml with that file.
> Read /usr/share/doc/dnscrypt-proxy/ChangeLog to merge files accordingly.'
> fi
>
> But it doesn't work as expected. Is there a way to transmit that
> message to my users?
There is no good way to do this. In particular, when you consider that
some people use 'sudo dnf' from the command line, some use PackageKit,
and some use dnf-automatic and such, there is mechanism that would cover
all cases.
But even if there was, it wouldn't be desirable to do this. Many
people won't read the notification, and even if they did, they
wouldn't act on it. In general, the assumption is that any update
*must* take care of upgrading the configuration. And incompatible
config-format changes in a released Fedora version are discouraged.
Simply put, upstream shouldn't do such backwards-incompatible changes
without a very good reason. There is really no nice way to handle this
in a package [*]. If the update can't be done automatically, then making
the service fail to start as described as suggested in the other part
of the thread is an option. Either way, this most likely should only
happen in rawhide.
Zbyszek
[*] Sometimes, a breaking change is unavoidable. For example, major
version bumps of a database, in particular postgresql. But I doubt
that this config format change is like that and the code couldn't have
been made to read both the old and new formats.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] python39 in EPEL7
Hello, I am posting to gather if there is enough support to provide python39 in EPEL. Currently, EL7 users wanting to run modern python apps under uwsgi can only use uwsgi-plugin-pyton36@epel. New Django releases are expected to require 3.8 or higher. There is a rh-python38 SCL, but this version does not have a compatible uwsgi-plugin. From https://bugzilla.redhat.com/show_bug.cgi?id=1781940 I gather that there is interest in getting python39 in EPEL. I talked to Miro Hrončok, who was willing to work on packaging, if there would be sufficient support from EPEL. Thanks, Pim ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Display a message on the console while upgrading a package
On 3/30/21 1:17 PM, Robert Marcano wrote:
On 3/30/21 1:11 PM, Robert-André Mauchin wrote:
Hello,
Following a change in the config file of a program, I'd like to
display a message to my users to indicate they need to update the
config file with the new one. I try "echo" in the update scriptlet:
%postun
if [ "$1" -ge "1" ] ; then # Upgrade
dnscrypt-proxy -service install --config
%{_sysconfdir}/dnscrypt-proxy/dnscrypt-proxy.toml
echo 'Since version 2.0.45, some of the configuration files have
been renamed.
Please merge your config to
/etc/dnscrypt-proxy/dnscrypt-proxy.toml.rpmnew then
replace dnscrypt-proxy.toml with that file.
Read /usr/share/doc/dnscrypt-proxy/ChangeLog to merge files
accordingly.'
fi
But it doesn't work as expected. Is there a way to transmit that
message to my users?
The automatic message about the saving of the new configuration as an
*.rpmnew file should tell any sysadmins that the configuration needs to
be revised.
Let me add that DNF should show the list of configuration files saved as
*.rpmsave or *.rpmnew at the end of the transaction. It is easy to skip
those messages inside a long list of lines with
as progress bars
If the service doesn't works fine with the old configuration. Maybe you
could add a service ExecStartPre script that fails with a pretty message
about the file migration required.
Best regards,
Robert-André
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Display a message on the console while upgrading a package
On 3/30/21 1:11 PM, Robert-André Mauchin wrote:
Hello,
Following a change in the config file of a program, I'd like to display
a message to my users to indicate they need to update the config file
with the new one. I try "echo" in the update scriptlet:
%postun
if [ "$1" -ge "1" ] ; then # Upgrade
dnscrypt-proxy -service install --config
%{_sysconfdir}/dnscrypt-proxy/dnscrypt-proxy.toml
echo 'Since version 2.0.45, some of the configuration files have been
renamed.
Please merge your config to
/etc/dnscrypt-proxy/dnscrypt-proxy.toml.rpmnew then
replace dnscrypt-proxy.toml with that file.
Read /usr/share/doc/dnscrypt-proxy/ChangeLog to merge files
accordingly.'
fi
But it doesn't work as expected. Is there a way to transmit that message
to my users?
The automatic message about the saving of the new configuration as an
*.rpmnew file should tell any sysadmins that the configuration needs to
be revised.
If the service doesn't works fine with the old configuration. Maybe you
could add a service ExecStartPre script that fails with a pretty message
about the file migration required.
Best regards,
Robert-André
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Display a message on the console while upgrading a package
Hello,
Following a change in the config file of a program, I'd like to display
a message to my users to indicate they need to update the config file
with the new one. I try "echo" in the update scriptlet:
%postun
if [ "$1" -ge "1" ] ; then # Upgrade
dnscrypt-proxy -service install --config
%{_sysconfdir}/dnscrypt-proxy/dnscrypt-proxy.toml
echo 'Since version 2.0.45, some of the configuration files have been
renamed.
Please merge your config to
/etc/dnscrypt-proxy/dnscrypt-proxy.toml.rpmnew then
replace dnscrypt-proxy.toml with that file.
Read /usr/share/doc/dnscrypt-proxy/ChangeLog to merge files accordingly.'
fi
But it doesn't work as expected. Is there a way to transmit that message
to my users?
Best regards,
Robert-André
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Rebuilding packages that use std::call_once from libstdc++
Due to an unplanned ABI break that I caused in libstdc++, I will soon start to rebuild the packages listed below. This rebuild will remove references to some symbols in libstdc++.so which do not work as intended, and so will not be present in the final gcc-11.1.0 release. See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference. Package maintainers should not need to do anything, but will see a %release bump and a rebuild. OpenImageIO PDAL SoapySDR audacious audacity blender boost botan2 ceph chromium clang cockatrice community-mysql cpprest date davix deepin-file-manager deepin-image-viewer dolphin-emu domoticz dotnet3.1 doxygen dyninst et fawkes firefox fish folly freecad freeopcua gazebo gdb gnome-sudoku gnuradio godot heaptrack hidviz hpx icecat icu insight julia kdevelop-php kernelshark kf5-kio kicad kio-extras kismet libarcus libarcus-lulzbot libdigidocpp libixion libmodsecurity libomp librealsense libreoffice librime lld lldb llvm llvm7.0 lnav log4cplus logiops luxcorerender mame mapnik mariadb mingw-llvm mir mlir mmapper movit mozc mozjs78 mypaint mysql-connector-odbc nghttp2 nodejs oidn ompl onednn opencv openshadinglanguage openvdb osm2pgsql osmium-tool paraview parzip pdns poedit polly poppler primesieve protobuf protobuf-c proxysql prusa-slicer pulseeffects pyosmium python-pynest2d qgis qmasterpassword qpid-proton qt-creator qt5-qtlocation qt5-qtwebengine qt5-qtwebkit qtcurve rdkit re2 rlottie root rstudio scipy seqan2 spirv-llvm-translator sqlitebrowser srt supercollider swift-lang thunderbird tkrzw uhd usbguard vapoursynth vigra warzone2100 watchman webextension-token-signing webkit2gtk3 wesnoth worker wsjtx xrdcl-http xrootd yacreader zimlib zynaddsubfx ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Disable bodhi auto-update creation on rawhide?
Il 30/03/21 17:07, Ian McInerney ha scritto: > Is there a way I can disable the creation of updates automatically in > Bodhi for builds I submit to rawhide? Short answer: no. > I find it very inconvenient because it means I can't add the > appropriate bugzilla references/description to the update when I > submit package updates that need them. If you meant you want to add bugs to the update so that they will be closed, you can: https://bodhi.fedoraproject.org/docs/user/automatic_updates.html#associate-bugs-to-automatic-updates Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2021-03-31 from 16:00:00 to 17:00:00 US/Eastern At fedora-meet...@irc.freenode.net The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic EPEL-9 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9854/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planet -> WeMakeFedora.org RMS: what are people saying?
On 30/03/2021 16:17, Matthew Miller wrote: > On Tue, Mar 30, 2021 at 02:36:05AM +0200, Daniel Pocock wrote: >> Looking at what people post, I think I can summarize it concisely: >> people either love him or they hate him. > > That is certainly not the case; I neither love nor hate him, although I do > try to make an effort to love all human beings, flaws and all. But, this > isn't a topic for devel list. We have several conversations about this in > progress, including in the Fedora Council on an official response and in the > Fedora Council Discussion category: > > https://discussion.fedoraproject.org/t/free-software-advocates-seek-removal-of-richard-stallman-and-entire-fsf-board/28290 > > https://discussion.fedoraproject.org/t/rms-is-the-past-fedora-is-building-the-future/28451 > > Let's keep the devel list to devel. Yes, I wasn't planning to elaborate here on devel. I've added an extra thread over there just in case two RMS threads are not enough. https://discussion.fedoraproject.org/t/applying-the-same-criteria-to-fsf-rms-and-fsfe-matthias-kirschner/28465 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1941319] perl-Perl-Metrics-Simple-0.19 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1941319 --- Comment #14 from Fedora Update System --- FEDORA-2021-22d4054b32 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-22d4054b32` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-22d4054b32 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1938172] perl-Test-PostgreSQL-1.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1938172 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Test-PostgreSQL-1.28-1 |perl-Test-PostgreSQL-1.28-1 |.fc35 |.fc35 |perl-Test-PostgreSQL-1.28-1 |perl-Test-PostgreSQL-1.28-1 |.fc34 |.fc34 |perl-Test-PostgreSQL-1.28-1 |perl-Test-PostgreSQL-1.28-1 |.fc32 |.fc32 |perl-Test-PostgreSQL-1.28-1 |perl-Test-PostgreSQL-1.28-1 |.fc33 |.fc33 ||perl-Test-PostgreSQL-1.28-1 ||.el8 --- Comment #13 from Fedora Update System --- FEDORA-EPEL-2021-7333ebbdac has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] Please review: PR 4665: issue 4585 - backend redesign phase 3c - dbregion test removal #4665
FYI: A second review is needed on that one (as most of the changes reviewed by Mark the first time have been removed) https://github.com/389ds/389-ds-base/pull/4665 -- -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1943227] perl-Perl-Metrics-Simple-1.0.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1943227 --- Comment #11 from Fedora Update System --- FEDORA-2021-22d4054b32 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-22d4054b32` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-22d4054b32 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1943227] perl-Perl-Metrics-Simple-1.0.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1943227 --- Comment #10 from Fedora Update System --- FEDORA-2021-cefcaa82a2 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-cefcaa82a2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cefcaa82a2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1941319] perl-Perl-Metrics-Simple-0.19 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1941319 --- Comment #13 from Fedora Update System --- FEDORA-2021-cefcaa82a2 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-cefcaa82a2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cefcaa82a2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Disable bodhi auto-update creation on rawhide?
On ti, 30 maalis 2021, Ian McInerney wrote: Is there a way I can disable the creation of updates automatically in Bodhi for builds I submit to rawhide? I find it very inconvenient because it means I can't add the appropriate bugzilla references/description to the update when I submit package updates that need them. I would prefer the behavior of branched releases where I have to make the update myself. One way to get around that right now is by using side-tags. If you created a side-tag for rawhide and built packages in it, then they would not be submitted automatically. Instead, you'd need to create a bodhi update yourself for this side-tag. This gives you back all the control but with an overhead of a side-tag. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Disable bodhi auto-update creation on rawhide?
On Tue, Mar 30, 2021 at 11:08 AM Ian McInerney wrote: > > Is there a way I can disable the creation of updates automatically in Bodhi > for builds I submit to rawhide? I find it very inconvenient because it means > I can't add the appropriate bugzilla references/description to the update > when I submit package updates that need them. I would prefer the behavior of > branched releases where I have to make the update myself. > If you build in a side tag, it won't auto-create and push updates. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Disable bodhi auto-update creation on rawhide?
Is there a way I can disable the creation of updates automatically in Bodhi for builds I submit to rawhide? I find it very inconvenient because it means I can't add the appropriate bugzilla references/description to the update when I submit package updates that need them. I would prefer the behavior of branched releases where I have to make the update myself. Thanks, -Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Introducing Shells to Fedora community
> We already have several Linux distros available and more are incoming weekly, > and we want > to have a polished Fedora experience as well. While we have Fedora on the > list, we > submitted our trademark request and are working through the details and would > like to > invite you for further collaboration between Fedora and Shells to create a > better Fedora > experience and potentially even create a spin! Probably worth noting here that the Shells team is very willing to offer complementary accounts to people interested in helping getting Fedora systems running in their environment. It's a pretty nifty service, and the team behind it is long-time open source friends formerly from the PIA vpn (sponsors of Freenode, GNOME Guadec, and more). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-7f38c5da36 lib3mf-2.0.1-1.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-7f980da66e tor-0.3.5.14-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-615589a3ad zarafa-7.1.14-4.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a650134f4f exim-4.94-2.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b1d43d7b48 atasm-1.09-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a1ab6f9c4e libmediainfo-21.03-1.el7 libzen-0.4.39-1.el7 mediainfo-21.03-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing chromium-89.0.4389.90-3.el7 openssl11-1.1.1g-3.el7 Details about builds: chromium-89.0.4389.90-3.el7 (FEDORA-EPEL-2021-d0a9c2bf03) A WebKit (Blink) powered web browser that Google doesn't want you to use Update Information: Fix issue where chromium would crash upon accessing components/cast_*. Thanks to Gentoo for the patch. It also fixes some security issues, because why not: CVE-2021-21191 CVE-2021-21192 CVE-2021-21193 ChangeLog: * Thu Mar 25 2021 Tom Callaway - 89.0.4389.90-3 - apply upstream fix for newer system libva * Wed Mar 24 2021 Tom Callaway - 89.0.4389.90-2 - fix crashes with components/cast_* * Thu Mar 18 2021 Tom Callaway - 89.0.4389.90-1 - update to 89.0.4389.90 - disable auto-download of widevine binary only blob * Mon Mar 15 2021 Tom Callaway - 89.0.4389.82-2 - add support for futex_time64 References: [ 1 ] Bug #1939460 - CVE-2021-21191 chromium-browser: Use after free in WebRTC https://bugzilla.redhat.com/show_bug.cgi?id=1939460 [ 2 ] Bug #1939461 - CVE-2021-21192 chromium-browser: Heap buffer overflow in tab groups https://bugzilla.redhat.com/show_bug.cgi?id=1939461 [ 3 ] Bug #1939462 - CVE-2021-21193 chromium-browser: Use after free in Blink https://bugzilla.redhat.com/show_bug.cgi?id=1939462 openssl11-1.1.1g-3.el7 (FEDORA-EPEL-2021-857a9f7853) Utilities from the general purpose cryptography library with TLS implementation Update Information: - backport from 1.1.1g-15: version bump - backport from 1.1.1g-14: CVE-2021-3450 openssl: CA certificate check bypass with `X509_V_FLAG_X509_STRICT` - backport from 1.1.1g-13: Fix CVE-2021-3449 `NULL` pointer deref in `signature_algorithms processing` ChangeLog: * Mon Mar 29 2021 Robert Scheck 1.1.1g-3 - backport from 1.1.1g-15: version bump - backport from 1.1.1g-14: CVE-2021-3450 openssl: CA certificate check bypass with X509_V_FLAG_X509_STRICT - backport from 1.1.1g-13: Fix CVE-2021-3449 NULL pointer deref in signature_algorithms processing References: [ 1 ] Bug #1941547 - CVE-2021-3450 openssl: CA certificate check bypass with X509_V_FLAG_X509_STRICT https://bugzilla.redhat.com/show_bug.cgi?id=1941547 [ 2 ] Bug #1941554 - CVE-2021-3449 openssl: NULL pointer dereference in signature_algorithms processing https://bugzilla.redhat.com/show_bug.cgi?id=1941554 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planet -> WeMakeFedora.org RMS: what are people saying?
On 30/03/2021 16:11, Matthew Miller wrote: > On Tue, Mar 30, 2021 at 01:37:48AM +0200, Daniel Pocock wrote: >> As I noted in the original email, "I will not speculate that this is any >> more than a coincidence". I don't want to make either assumptions or >> accusations, you do a huge amount of work and everybody here understands >> that. > > Oh come on; this is a well-known rhetorical device, and I'm sure you know > that as well. You say that you will not "speculate", but then go ahead and > state the thing that you _would_ speculate, were you to do so, but claim to > not be doing. Of course, that's not actually any different. If you actually > do not want to raise an accusation, the way to do it is to not raise that > accusation. Given we all know that there was a lot of work going on I feel most people here appreciate that it is an unlucky coincidence. I could have been more careful to keep it at that level. > This may sound like I am a bit irked, and I'll explain why: you already sent > me a private mail with a _different_ accusation, and I responded to you then > that it was not any intentional action at all and likely a side-effect of > the account system update -- which, as Kevin verifies, is the case. So you > _really_ have no reason for this speculation. I'm genuinely sorry that all this negativity is going around and it has been reflected in the email about this site. I don't think the negativity starts with any one person on either side. The solution often involves investing in the organization and that is a lot harder when everybody is losing contact with each other due to the pandemic. > In any case, please make sure this site follows these trademark guidelines: > https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Community_sites_and_accounts Thanks for pointing that out, I'll do a basic template some time in the next few days. Regards, Daniel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1943227] perl-Perl-Metrics-Simple-1.0.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1943227 --- Comment #9 from Fedora Update System --- FEDORA-2021-2573e42852 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-2573e42852` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-2573e42852 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1941319] perl-Perl-Metrics-Simple-0.19 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1941319 --- Comment #12 from Fedora Update System --- FEDORA-2021-2573e42852 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-2573e42852` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-2573e42852 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal to fail builds if RPATH is found in Fedora 35
On Mon, Mar 29, 2021 at 2:36 PM Charalampos Stratakis wrote: > > > - Original Message - > > From: "Alexander Bokovoy" > > To: "Development discussions related to Fedora" < > devel@lists.fedoraproject.org> > > Sent: Friday, March 26, 2021 10:06:28 PM > > Subject: Re: Proposal to fail builds if RPATH is found in Fedora 35 > > > > > For example, Samba has a number of internal libraries in > > /usr/lib64/samba which have to be linked to by any plugin built for > > Samba, even when it is provided by a different package. This situation > > is not described in the packaging guidelines and practically ignored. > > Thanks for this example, I'll investigate that specific usecase. > I don't think there is anything wrong with having rpath to a private directory (/usr/lib64/samba) -- that's exactly what rpath is for, so that the app could find its private libraries that we don't want the whole world to have access to. What we should avoid is rpath to standard libdir, which is /usr/lib or /usr/lib64. (Sorry if this has already been discussed, I'm a bit behind on email.) -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planet -> WeMakeFedora.org RMS: what are people saying?
On Tue, Mar 30, 2021 at 02:36:05AM +0200, Daniel Pocock wrote: > Looking at what people post, I think I can summarize it concisely: > people either love him or they hate him. That is certainly not the case; I neither love nor hate him, although I do try to make an effort to love all human beings, flaws and all. But, this isn't a topic for devel list. We have several conversations about this in progress, including in the Fedora Council on an official response and in the Fedora Council Discussion category: https://discussion.fedoraproject.org/t/free-software-advocates-seek-removal-of-richard-stallman-and-entire-fsf-board/28290 https://discussion.fedoraproject.org/t/rms-is-the-past-fedora-is-building-the-future/28451 Let's keep the devel list to devel. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planet -> WeMakeFedora.org RMS: what are people saying?
On Tue, Mar 30, 2021 at 01:37:48AM +0200, Daniel Pocock wrote: > As I noted in the original email, "I will not speculate that this is any > more than a coincidence". I don't want to make either assumptions or > accusations, you do a huge amount of work and everybody here understands > that. Oh come on; this is a well-known rhetorical device, and I'm sure you know that as well. You say that you will not "speculate", but then go ahead and state the thing that you _would_ speculate, were you to do so, but claim to not be doing. Of course, that's not actually any different. If you actually do not want to raise an accusation, the way to do it is to not raise that accusation. This may sound like I am a bit irked, and I'll explain why: you already sent me a private mail with a _different_ accusation, and I responded to you then that it was not any intentional action at all and likely a side-effect of the account system update -- which, as Kevin verifies, is the case. So you _really_ have no reason for this speculation. In any case, please make sure this site follows these trademark guidelines: https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Community_sites_and_accounts -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)
On Mon, 29 Mar 2021 21:33:14 +0200 Daniel Pocock wrote: > > > On 29/03/2021 11:49, Dan Horák wrote: > > On Wed, 24 Mar 2021 16:13:08 +0100 > > Daniel Pocock wrote: > > > >> > >> > >> On 22/02/2021 22:43, Dan Horák wrote: > >>> On Mon, 22 Feb 2021 21:19:26 - > >>> "Tom Seewald" wrote: > >>> > > On 22/02/2021 21:18, Tom Seewald wrote: > > > > > > > > Personally, I have an older GPU, RX 580 Polaris series, I will only > > spend dev time on the AMD Navi GPU issues after AMD makes the RX 6800 XT > > available in my region. I simply don't have that card and I'm not going > > to waste money buying the original Navi card, RX 5700, when the new card > > will arrive imminently. > > There is no indication from the bug report that it requires a Navi card > to reproduce. The reporter stated that they are using a RX Vega 56 which > is the previous gpu generation. Why do you believe this is specific to > Navi devices? > >> > >> To clarify, there are a range of different issues with different amdgpu > >> cards > >> > >> If anybody can provide tips for troubleshooting in any of these bug > >> reports it would be very welcome. > >> > >> https://gitlab.freedesktop.org/drm/amd/-/issues/1519 > >> navi2 - RX 6900 XT > >> > >> https://gitlab.freedesktop.org/drm/amd/-/issues/1446 > >> vega RX 56 Red Dragon > >> > >> https://gitlab.freedesktop.org/drm/amd/-/issues/1293 > >> Fiji-based cards since kernel 5.7 > > > > I suspect there is no other way besides bisecting on a system with > > the same/similar card ... > > > > also adding another page size related issue > > https://gitlab.freedesktop.org/drm/amd/-/issues/1549 > > Polaris-based cards, starting post-5.10, confirmed in 5.11-rc2 > > > > but here the original submitter of the bug was able to identify the > > offending commit > > > In #1446 the original reporter has offered to bisect, I didn't see > further feedback yet. > > I'd be willing to contribute a small amount of time on the RX 6800 XT if > I am able to get the card and if I feel the time will be productive, for > example, if somebody more familiar with it can give me some specific > things to test. > > I would genuinely like to have the benefits of PCIe 4 and 16GB video RAM > too but the cards are simply not available here. > > As the Navi 2 cards appear to be more suited to my purposes, I wasn't > really interested in spending time or money on the Navi 1 cards. I'd > rather just put the effort in with a Navi 2 card. I have some good news, there is a fix for my issue, actually in 2 parts, both in the generic amdgpu memory management code. IMO it's worth to retry on the other cards as well. https://gitlab.freedesktop.org/agd5f/linux/-/commit/fe001e70a55d0378328612be1fdc3abfc68b9ccc - already in AMD's drm-next tree https://github.com/xen0n/linux/commit/84ada72983838bd7ce54bc32f5d34ac5b5aae191 - being discussed in https://lists.freedesktop.org/archives/dri-devel/2021-March/301805.html Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Introduction
Hi Odinaka, thanks for showing interest in our project. There are tips for Outreachy applicants in readme [1] of the project. If anything is unclear feel free to ping me on IRC or send me an email. L. [1] https://pagure.io/fedora-qa/landingpage On Tue, Mar 30, 2021 at 12:40 PM Joy Odinaka wrote: > Hi, > I am Odinaka Joy, an outreachy applicant for the 2021 session. I am a web > developer based in Nigeria. > > I would love to join the Fedora team and contribute to the project - Improve > Fedora QA Dashboard. > > I have experience with JavaScript, React and Redux and would love to > improve my skills by contributing to this project. > > My contacts: > IRC Username: dinakajoy > Email: odinaka...@gmail.com > > I would appreciate any guidance to help me get started with my > contribution. > > Thank you. > > Best regards, > Odinaka Joy > ___ > qa-devel mailing list -- qa-devel@lists.fedoraproject.org > To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Introduction
Hi, I am Odinaka Joy, an outreachy applicant for the 2021 session. I am a web developer based in Nigeria. I would love to join the Fedora team and contribute to the project - Improve Fedora QA Dashboard. I have experience with JavaScript, React and Redux and would love to improve my skills by contributing to this project. My contacts: IRC Username: dinakajoy Email: odinaka...@gmail.com I would appreciate any guidance to help me get started with my contribution. Thank you. Best regards, Odinaka Joy ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFC: declaring estimated per-builder RAM usage in spec file
On 3/30/21 12:43 PM, Nico Kadel-Garcia wrote: On Tue, Mar 30, 2021 at 4:46 AM Panu Matilainen wrote: On 3/29/21 8:17 PM, Michel Alexandre Salim wrote: Hi again, On Fri, 2021-03-26 at 17:29 -0700, Michel Alexandre Salim wrote: [snip] Right now I'm just overriding _smp_build_ncpus to 1, but there is a more elegant solution I'd like to propose: What if one can declaratively set the required RAM per build job -- either with a single macro, or maybe two if the LTO usecase requires even more RAM. e.g. to declare each core might take up to 8 GB: %global _smp_build_ram_per_cpu 8192 then in case this is run on our aarch64 builder with 40GB RAM, dynamically take the minimum of the existing _smp_build_ncpus (which AIUI is determined by the number of cores on the machine) and (amount of RAM / _smp_build_ram_per_cpu), in this case capping the actual number passed to -j to 5. Is there interest in having this be available? I could imagine it might be useful for other resource-intensive package builds e.g. for Chromium. Thanks to Dennis, Dan and Miroslav for the helpful pointers! Short-term I'll look into adopting something similar to the Ceph script, but medium-term - maybe we can get the scriptlet into redhat- rpm-config and then eventually have it in RPM itself once Panu's patch is reworked? (Having it in redhat-rpm-config or some other RPM is probably needed anyway, for older supported releases, so ideally we use the same macros and only override them in redhat-rpm-config if they were undefined). cc:ing Panu for context on the RPM PR status. There's no progress on that front, other than occasionally thinking about it. It might not be a bad idea to be able to put an actual BuildRequire on the amount of memory (and other similar - disk space also comes to mind) into specs. Let's *not*. The amount of space saved in storage by putting socks and underwear in their own separate drawers os often overwhelmed by the space wasted in giving those drawers sides and a way to slide in and out. In other words, it creates unnecessary overhead in managing build environment resources. It's also difficult to predict in advance, especially for the worst offenders, such as builds whose upstream components are often pulled in dynamically: "pip install", "cpan", "mvn", "gradle", "rubygem", and my recent favorite for unpredictable and only erratically evailble dependencies, "go". While well designed SRPMs and .spec files to rely only on other RPMs for their dependencies, many in the field do not. And even when the dependencies are available, even a small change in "test" procedures can massively expand RAM and disk use during compilation. In other words, the memory requirements are likely to diverge, *massively* and unpredictably. It's safer and simpler to simply allocate memory generously for build environments. The point is not that everybody should add such requirements to their packages, but to have that *option* for those monster packages out there. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFC: declaring estimated per-builder RAM usage in spec file
On Tue, Mar 30, 2021 at 4:46 AM Panu Matilainen wrote: > > On 3/29/21 8:17 PM, Michel Alexandre Salim wrote: > > Hi again, > > > > On Fri, 2021-03-26 at 17:29 -0700, Michel Alexandre Salim wrote: > >> > > [snip] > >> Right now I'm just overriding _smp_build_ncpus to 1, but there is a > >> more elegant solution I'd like to propose: > >> > >> What if one can declaratively set the required RAM per build job -- > >> either with a single macro, or maybe two if the LTO usecase requires > >> even more RAM. e.g. to declare each core might take up to 8 GB: > >> > >> %global _smp_build_ram_per_cpu 8192 > >> > >> then in case this is run on our aarch64 builder with 40GB RAM, > >> dynamically take the minimum of the existing _smp_build_ncpus (which > >> AIUI is determined by the number of cores on the machine) and (amount > >> of RAM / _smp_build_ram_per_cpu), in this case capping the actual > >> number passed to -j to 5. > >> > >> Is there interest in having this be available? I could imagine it > >> might > >> be useful for other resource-intensive package builds e.g. for > >> Chromium. > >> > > > > Thanks to Dennis, Dan and Miroslav for the helpful pointers! > > > > Short-term I'll look into adopting something similar to the Ceph > > script, but medium-term - maybe we can get the scriptlet into redhat- > > rpm-config and then eventually have it in RPM itself once Panu's patch > > is reworked? > > > > (Having it in redhat-rpm-config or some other RPM is probably needed > > anyway, for older supported releases, so ideally we use the same macros > > and only override them in redhat-rpm-config if they were undefined). > > > > cc:ing Panu for context on the RPM PR status. > > There's no progress on that front, other than occasionally thinking > about it. > > It might not be a bad idea to be able to put an actual BuildRequire on > the amount of memory (and other similar - disk space also comes to mind) > into specs. Let's *not*. The amount of space saved in storage by putting socks and underwear in their own separate drawers os often overwhelmed by the space wasted in giving those drawers sides and a way to slide in and out. In other words, it creates unnecessary overhead in managing build environment resources. It's also difficult to predict in advance, especially for the worst offenders, such as builds whose upstream components are often pulled in dynamically: "pip install", "cpan", "mvn", "gradle", "rubygem", and my recent favorite for unpredictable and only erratically evailble dependencies, "go". While well designed SRPMs and .spec files to rely only on other RPMs for their dependencies, many in the field do not. And even when the dependencies are available, even a small change in "test" procedures can massively expand RAM and disk use during compilation. In other words, the memory requirements are likely to diverge, *massively* and unpredictably. It's safer and simpler to simply allocate memory generously for build environments. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1838000] CVE-2020-12723 perl: corruption of intermediate language state of compiled regular expression due to recursive S_study_chunk() calls leads to DoS
https://bugzilla.redhat.com/show_bug.cgi?id=1838000 --- Comment #26 from errata-xmlrpc --- This issue has been addressed in the following products: Red Hat Enterprise Linux 7.7 Extended Update Support Via RHSA-2021:1032 https://access.redhat.com/errata/RHSA-2021:1032 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1837988] CVE-2020-10878 perl: corruption of intermediate language state of compiled regular expression due to integer overflow leads to DoS
https://bugzilla.redhat.com/show_bug.cgi?id=1837988 --- Comment #27 from errata-xmlrpc --- This issue has been addressed in the following products: Red Hat Enterprise Linux 7.7 Extended Update Support Via RHSA-2021:1032 https://access.redhat.com/errata/RHSA-2021:1032 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1837975] CVE-2020-10543 perl: heap-based buffer overflow in regular expression compiler leads to DoS
https://bugzilla.redhat.com/show_bug.cgi?id=1837975 --- Comment #25 from errata-xmlrpc --- This issue has been addressed in the following products: Red Hat Enterprise Linux 7.7 Extended Update Support Via RHSA-2021:1032 https://access.redhat.com/errata/RHSA-2021:1032 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Account Migration & Production Deployment Update: COMPLETE!
Dnia Sat, Mar 27, 2021 at 10:56:32AM -0700, Kevin Fenzi napisał(a): > On Sat, Mar 27, 2021 at 11:08:19AM +0100, Tomasz Torcz wrote: > > > > > > Notification via sms is... not too secure. ;( > > > https://www.vice.com/en/article/y3g8wb/hacker-got-my-texts-16-dollars-sakari-netnumber > > > > I didn't write SMS. SMS is terrible, it's the worst 2F channel nowadays. > > I meant push notification, when the message is sent through secure channel > > to your smart phone and you get popup asking for authorization. > > At least: > > > > - Google does that: > > https://s3.amazonaws.com/neowin/news/images/uploaded/2017/07/1500141361_google_mobile_prompt.jpg > > - Microsoft Suite (Teams, Outlook) on my corporate accounts: > > https://techcommunity.microsoft.com/t5/image/serverpage/image-id/46536iDD69C684B52CC495 > > - My banking app (for login and transfer authorizations) > > https://android.com.pl/apps/wp-content/uploads/2020/03/alior.jpg.webp > > > > This seem to be easiest and most secure 2FA, but requires cooperation > > with Android framework. Next in line are FIDO/Yubikeys, and OTP codes. > > Ah, ok. Well, not everyone has access to them. > > I have a android based phone, but it's de-googled, > so I can't get any google push notifications. Others > may have i-phones or... perhaps even no smart phone at all. ;) Both IOS and Tizen have some push notification frameworks, like Android. I'm not familiar with specifics, as their marketshare is insignificant here, less than 7% combined. Anyway, any solution is more usable than this peculiar way of combining password with OTP code. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. to...@pipebreaker.pl Your routes will be aggreggated. -- Alex Yuriev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Outreachy 2021 applicant
Hi Kunal, thanks for showing interest in our project, I see you already found our pagure repo and an issue you like to work on. I'll assign that issue to you. For any more questions feel free to post here or contact me directly via email lbra...@redhat.com L. On Tue, Mar 30, 2021 at 7:36 AM KUNAL PRAKASH wrote: > Hello everyone :) > I hope everyone is doing good in this pandemic. > Myself Kunal Prakash. 2nd year student from NIT Patna. I am experienced > with Javascript, React, Redux, CSS. I come across "Improve Fedora QA > Dashboard" project. I really liked the project and want to contribute to it. > Thank you. > ___ > qa-devel mailing list -- qa-devel@lists.fedoraproject.org > To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFC: declaring estimated per-builder RAM usage in spec file
On 3/29/21 8:17 PM, Michel Alexandre Salim wrote: Hi again, On Fri, 2021-03-26 at 17:29 -0700, Michel Alexandre Salim wrote: [snip] Right now I'm just overriding _smp_build_ncpus to 1, but there is a more elegant solution I'd like to propose: What if one can declaratively set the required RAM per build job -- either with a single macro, or maybe two if the LTO usecase requires even more RAM. e.g. to declare each core might take up to 8 GB: %global _smp_build_ram_per_cpu 8192 then in case this is run on our aarch64 builder with 40GB RAM, dynamically take the minimum of the existing _smp_build_ncpus (which AIUI is determined by the number of cores on the machine) and (amount of RAM / _smp_build_ram_per_cpu), in this case capping the actual number passed to -j to 5. Is there interest in having this be available? I could imagine it might be useful for other resource-intensive package builds e.g. for Chromium. Thanks to Dennis, Dan and Miroslav for the helpful pointers! Short-term I'll look into adopting something similar to the Ceph script, but medium-term - maybe we can get the scriptlet into redhat- rpm-config and then eventually have it in RPM itself once Panu's patch is reworked? (Having it in redhat-rpm-config or some other RPM is probably needed anyway, for older supported releases, so ideally we use the same macros and only override them in redhat-rpm-config if they were undefined). cc:ing Panu for context on the RPM PR status. There's no progress on that front, other than occasionally thinking about it. It might not be a bad idea to be able to put an actual BuildRequire on the amount of memory (and other similar - disk space also comes to mind) into specs. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Self Introduction: Michal Josef Spacek
Hi, My name is Michal Josef Spacek. I am a Perl programmer and Red Hat employee. I have been supporting Perl packaging in Red Hat. I am interested in Perl programming, Wikidata, projects of Wikimedia Foundation, data processing. CPAN account: https://metacpan.org/author/SKIM personal homepage: https://skim.cz PS: my first Perl package BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1944554 Kind regards, Michal Josef Spacek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Account Migration & Production Deployment Update: COMPLETE!
On ma, 29 maalis 2021, Kevin Fenzi wrote: On Sat, Mar 27, 2021 at 11:02:58PM +0100, Björn Persson wrote: Kevin Fenzi wrote: > I'd like us to add security query/respond pairs. Those can very easily weaken security, as the answers are often public and easy for an attacker to look up, especially when there are only a few predefined questions to choose from. I was not advocating predefined questions. :) If I can enter my own question, then I can come up with some things that only I and my family know. That requires careful and security- conscious consideration. Many people would come up with insecure questions. Well, I always use randomly generated words for mine. But I agree, some people would make poor choices there. There's a limited supply of such personal secrets that I can be sure I'll remember, so I can't do that for too many sites. It also requires a not too public life. People who publish their entire lives on Facebook will have trouble coming up with a question that an attacker can't find the answer to. Another reason to randomly generate. Otherwise I'll make up a nonsensical phrase to enter as the answer, and store it securely. That turns the "security question" into a backup passphrase. If you want people to do this, then it's better to ask them to make up a passphrase. Sure, that might be better, although I still like that it's a manual process. ie, they have to tell it to an admin and the admin has to make sure everything looks right, etc. But in the end there's lots of ways to do all this, but one good reason we wanted to get off running our own account system was to not have to deal with this so much. So, really I think we should work to improve / land any changes we want here in IPA itself. Then everyone can benifit from it, and the IPA team that has a lot more security experence than I can do the right thing implementing it. :) Of course IPA has focused on the corp setting and this is kind of an expansion of their area, so we will need to discuss things with them I think. Could you please explain where you want to do it? Noggin (Fedora Accounts app) does handle the login itself, not FreeIPA. In the context of what Fedora contributors interact with, FreeIPA is only directly exposed via Kerberos authentication flow. Noggin can be modified to accept separate password and token values. In fact, FreeIPA Web UI does have password-based login implemented in this way -- there are separate password and token value login fields if user has OTP associated. Security query/response pairs are something that Noggin would need to manage on top of FreeIPA as well and thus would handle login with them. We do not have any mechanism in FreeIPA to allow you to handle this on behalf of Noggin. For security query/response pairs to be useful in FreeIPA context, they'd need to be plugged into the main password change flows. There are currently two major ones and the rest just piggy-backs on either of them: - a password change via LDAP protocol - a password change via Kerberos protocol Our current scheme for resetting forgotten or unknown passwords in FreeIPA requires administrators to initiate a reset with a temporary password, pre-set or randomly generated. Then a user changes the password via one of the two methods above -- either directly or with the help of one of applications that utilize those, by specifying the temporary password first and providing a new one afterwards. Kerberos password change protocol implements a single request and a single reply message where the request is initiated by a client and the server replies with a success or an error, after which the password is either updated or not. The request sent by the client includes a single user-data component (part of generic Kerberos KRB_PRIV message as per RFC4120 section 5.7.1). LDAP password change may include and return a control that could be used to pass through some additional information in both directions with a bit more flexibility than on the Kerberos side. It still requires that an LDAP client implements this exchange so Noggin would need to implement the logic for this too. If we'd want to add security query/response pairs to allow users to 'securely' reset their passwords initiated by themselves, this would be possible with an appropriate extension of an LDAP control and changes to FreeIPA Web UI and Noggin to support that. The bigger problem is to find a way to securely store these pairs encrypted per user. Right now the only per-user secret we have is something generated with the help of its password but since this is all about being able to reset that password without knowing its content, we need somewhat different method that would still be secure against others. In FreeIPA nobody, including administrators, is able to discover the user's password from a hashed form. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
[389-devel] 389 DS nightly 2021-03-30 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/03/30/report-389-ds-base-2.0.3-20210330gited4773408.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
