[Bug 1814114] perl-Gtk3-0.037 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814114 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Gtk3-0.037-1.fc30.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=42550723 -- 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
[Bug 1814114] New: perl-Gtk3-0.037 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814114 Bug ID: 1814114 Summary: perl-Gtk3-0.037 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Gtk3 Keywords: FutureFeature, Triaged Assignee: berra...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: berra...@redhat.com, dd...@cpan.org, perl-devel@lists.fedoraproject.org, ser...@serjux.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.037 Current version/release in rawhide: 0.036-2.fc32 URL: http://search.cpan.org/dist/Gtk3/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2947/ -- 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
[Bug 1814114] perl-Gtk3-0.037 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814114 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1670723 --> https://bugzilla.redhat.com/attachment.cgi?id=1670723=edit [patch] Update to 0.037 (#1814114) -- 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
[389-devel] 389 DS nightly 2020-03-17 - 96% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/03/17/report-389-ds-base-1.4.3.4-20200317gitb32c745.fc31.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
[Bug 1814107] New: Please make it available on EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1814107 Bug ID: 1814107 Summary: Please make it available on EPEL8 Product: Fedora Version: rawhide Status: NEW Component: perl-Text-Iconv Assignee: andr...@bawue.net Reporter: d...@redhat.com QA Contact: extras...@fedoraproject.org CC: andr...@bawue.net, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Description of problem: It is not available on EPEL8 and is needed for needrestart (indirectly). Additional info: It rebuilds fine without any change. -- 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
Fedora-32-20200316.n.0 compose check report
No missing expected images. Failed openQA tests: 6/171 (x86_64), 1/2 (arm) Old failures (same test failed in Fedora-32-20200315.n.0): ID: 547006 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/547006 ID: 547015 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/547015 ID: 547027 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/547027 ID: 547094 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/547094 ID: 547101 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/547101 ID: 547107 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/547107 ID: 547108 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/547108 Soft failed openQA tests: 15/171 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-32-20200315.n.0): ID: 546936 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/546936 ID: 546937 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/546937 ID: 546939 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/546939 ID: 546941 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/546941 ID: 546944 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/546944 ID: 546945 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/546945 ID: 546965 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/546965 ID: 546982 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/546982 ID: 546984 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/546984 ID: 547028 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/547028 ID: 547055 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/547055 ID: 547090 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/547090 ID: 547093 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/547093 ID: 547100 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/547100 ID: 547112 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/547112 Passed openQA tests: 149/171 (x86_64) New passes (same test not passed in Fedora-32-20200315.n.0): ID: 546958 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/546958 ID: 547002 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/547002 ID: 547003 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/547003 ID: 547013 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/547013 ID: 547066 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/547066 Skipped non-gating openQA tests: 1 of 173 Installed system changes in test x86_64 Everything-boot-iso install_default: System load changed from 0.02 to 0.15 Previous test data: https://openqa.fedoraproject.org/tests/546079#downloads Current test data: https://openqa.fedoraproject.org/tests/546979#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 0.86 to 1.00 Average CPU usage changed from 15.35714286 to 26.09047619 Previous test data: https://openqa.fedoraproject.org/tests/546082#downloads Current test data: https://openqa.fedoraproject.org/tests/546980#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: System load changed from 0.66 to 0.91 Average CPU usage changed from 4.58571429 to 17.92380952 Previous test data: https://openqa.fedoraproject.org/tests/546081#downloads Current test data: https://openqa.fedoraproject.org/tests/546981#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: Mount /run/user/0 disappeared since previous compose Used mem changed from 732 MiB to 895 MiB System load changed from 1.25 to 1.67 Average CPU usage changed from 2.2 to 37.88571429 Previous test data: https://openqa.fedoraproject.org/tests/546100#downloads Current test data:
[Bug 1004354] perl-Alien-ROOT not available on ARM because root is not there
https://bugzilla.redhat.com/show_bug.cgi?id=1004354 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #13 from Fedora Update System --- perl-Alien-ROOT-5.34.36.1-19.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-847f485965 -- 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
[Bug 1813720] perl-Pod-Usage-1.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813720 --- Comment #6 from Fedora Update System --- perl-Pod-Usage-1.70-1.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d708f52a27 -- 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8ce58993d7 mbedtls-2.16.5-1.el8 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-02f03affd4 ansible-2.9.6-1.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1402a55654 nethack-3.6.6-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d92c8360fe chromium-80.0.3987.132-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing log4cplus-1.2.0-11.el8 perl-JSON-Parse-0.56-1.el8 Details about builds: log4cplus-1.2.0-11.el8 (FEDORA-EPEL-2020-5e4c973748) Logging Framework for C++ Update Information: Add log4cplus to EPEL8 ChangeLog: * Wed Jan 29 2020 Fedora Release Engineering - 1.2.0-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Thu Jul 25 2019 Fedora Release Engineering - 1.2.0-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Fri Feb 1 2019 Fedora Release Engineering - 1.2.0-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Fri Jul 13 2018 Fedora Release Engineering - 1.2.0-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Thu Apr 26 2018 Tomas Hozza - 1.2.0-7 - Added gcc-c++ as an explicit BuildRequires * Thu Feb 8 2018 Fedora Release Engineering - 1.2.0-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Thu Aug 3 2017 Fedora Release Engineering - 1.2.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild * Wed Jul 26 2017 Fedora Release Engineering - 1.2.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild * Fri Feb 10 2017 Fedora Release Engineering - 1.2.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild * Wed Mar 23 2016 Zdenek Dohnal zdoh...@redhat.com - 1.2.0-2 - Replacing hard names with macros, returning and commenting macro prever in specfile * Fri Mar 18 2016 zdohnal - 1.2.0-1 - Update to 1.2.0 * Thu Feb 4 2016 Fedora Release Engineering - 1.1.3-0.5.rc3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild * Thu Jan 14 2016 Tomas Hozza - 1.1.3-0.4.rc3 - Fixed typo so that log4cplus is compiled with C++11 support (#1297906) * Wed Jun 17 2015 Fedora Release Engineering - 1.1.3-0.3.rc3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild * Sat May 2 2015 Kalev Lember - 1.1.3-0.2.rc3 - Rebuilt for GCC 5 C++11 ABI change * Tue Dec 16 2014 Tomas Hozza - 1.1.3-0.1.rc3 - update to 1.1.3rc3 - build the library with c++11 support * Sun Aug 17 2014 Fedora Release Engineering - 1.1.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild * Sat Jun 7 2014 Fedora Release Engineering - 1.1.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild * Thu Oct 24 2013 Tomas Hozza - 1.1.2-1 - update to 1.1.2 * Sat Aug 3 2013 Fedora Release Engineering - 1.1.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Thu May 23 2013 Tomas Hozza 1.1.1-1 - update to 1.1.1 * Mon Feb 18 2013 Adam Tkac - 1.1.0-1 - update to 1.1.0 * Thu Feb 14 2013 Fedora Release Engineering - 1.1.0-0.3.rc10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild * Fri Sep 21 2012 Adam Tkac - 1.1.0-0.2.rc10 - some fixes related to pkg review * Thu Sep 20 2012 Adam Tkac - 1.1.0-0.1.rc10 - initial package References: [ 1 ] Bug #1767162 - log4cplus is available on EPEL 7 but not on EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1767162 perl-JSON-Parse-0.56-1.el8 (FEDORA-EPEL-2020-a0bbfb3dea) Read JSON into a Perl variable Update Information: This package contains JSON::Parse, a Perl module for parsing JSON. (JSON means "JavaScript Object Notation" and it is specified in "RFC 7159".) ChangeLog: * Thu Feb 20 2020 Emmanuel Seyman - 0.56-1 - Update to 0.56 - Use /usr/bin/perl instead of %/usr/bin/perl - Pass NO_PERLLOCAL=1 to Makefile.PL - Use %{make_install} instead of "make pure_install" - Use %{make_build} instead of make * Thu Jan 30 2020 Fedora Release Engineering - 0.55-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Fri Jul 26 2019 Fedora Release Engineering - 0.55-7 - Rebuilt for
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 580 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 322 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 319 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 29 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-471d8a7abd sympa-6.2.54-1.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b3684de763 mbedtls-2.7.14-1.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4fdca9429c seamonkey-2.53.1-2.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fbd804208a monit-5.26.0-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b8f44a854a weechat-2.7.1-1.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b467e9784b php-horde-Horde-Form-2.0.20-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7e106e25f9 timeshift-20.03-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing sourcextractor++-0.10-1.el7 Details about builds: sourcextractor++-0.10-1.el7 (FEDORA-EPEL-2020-58450ed489) A program that extracts a catalog of sources from astronomical images, and the successor of SExtractor Update Information: New RPM ChangeLog: * Fri Mar 13 2020 Alejandro Alvarez Ayllon 0.10-1 - Update for upstream release 0.10 * Fri Jan 31 2020 Alejandro Alvarez Ayllon 0.8-1 - New RPM ___ 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
Fedora-Rawhide-20200316.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 2 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 15/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200314.n.0): ID: 546622 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/546622 ID: 546641 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/546641 ID: 546736 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/546736 Old failures (same test failed in Fedora-Rawhide-20200314.n.0): ID: 546607 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/546607 ID: 546615 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/546615 ID: 546621 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/546621 ID: 546626 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/546626 ID: 546628 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/546628 ID: 546631 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/546631 ID: 546632 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/546632 ID: 546672 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/546672 ID: 546684 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/546684 ID: 546751 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/546751 ID: 546758 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/546758 ID: 546764 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/546764 ID: 546765 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/546765 Soft failed openQA tests: 15/171 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20200314.n.0): ID: 546619 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/546619 Old soft failures (same test soft failed in Fedora-Rawhide-20200314.n.0): ID: 546593 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/546593 ID: 546594 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/546594 ID: 546596 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/546596 ID: 546598 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/546598 ID: 546601 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/546601 ID: 546602 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/546602 ID: 546651 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/546651 ID: 546653 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/546653 ID: 546685 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/546685 ID: 546694 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/546694 ID: 546712 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/546712 ID: 546747 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/546747 ID: 546750 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/546750 ID: 546757 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/546757 Passed openQA tests: 141/171 (x86_64) New passes (same test not passed in Fedora-Rawhide-20200314.n.0): ID: 546634 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/546634 ID: 546668 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/546668 ID: 546669 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/546669 ID: 546701 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/546701 Skipped non-gating openQA tests: 1 of 173 Installed system changes in test x86_64
[Bug 1813720] perl-Pod-Usage-1.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813720 --- Comment #5 from Fedora Update System --- perl-Pod-Usage-1.70-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0acf97c1e1 -- 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
[Bug 1813720] perl-Pod-Usage-1.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813720 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- perl-Pod-Usage-1.70-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9360ad9872 -- 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
[389-devel] Re: Please have a look at rewriters design
> On 17 Mar 2020, at 02:49, thierry bordaz wrote: > > Hi, > > As a follow up of the PR https://pagure.io/389-ds-base/pull-request/50939, > I wrote down a small design about rewriters (filter/computed_attr) plugin: > http://www.port389.org/docs/389ds/design/search_rewriters.html > > Comments are welcome Probably the most dangerous thing to say in all of history? Like, your design is very smart, but that cleverness and flexibility carries many risks. The problem at hand is rewriting ad attributes - not to make a framework. I still say focus on that problem alone rather than trying to solve a generic class of problems. Anyway, I still don't think this is the right avenue. There are two major reasons for this: First, is the attempt to make a "generic framework" to solve a "specific problem". We should not have a generic rewrite framework, when all we need is a specific, focused, module just for doing known and well tested attribute transformations. Code like COS or MEP may be generic, and it solves many cases but the surface area is huge, it's hard to test, and it's hard to reason about. We do not have a need for allowing generic, and arbitrary rewriters to exist, especially not when you have to "compile in" the rewriters anyway! This should be simply, an "ad rewrite" plugin, where all it does is that one thing - rewrite the attributes as required for AD emulation for IPA. This is far easier to deploy, test and reason about. Ideally, the configuration is simply "the plugin is enabled or disabled". Second, is the idea of this being a "search rewriter". I don't think this is a good idea. The search path should be simple, it's our hot path. We have many things that have to interact like indexes etc. Look at virtual attribute indexing and such and the work needed for COS to have these used? This plugin should be on the write path, transforming when a change occurs. This means the code is much simpler, easier to test, and we need no modifications to our read paths. Things like MEP and replication will "just work" as will indexing and much more. For me to approve this plugin, I really want to see it being a write-path transformation of values into other values, and it should be focused, targeted, and simple. I do want to make one thing clear though - I think it's much better that this plugin exist in 389-ds rather than in freeipa. The 389-ds project has better tooling (like ASAN/LSAN), faster testing capability and a group of subject matter experts for code review. I think that if you were to move this to freeipa, you would not have the same level of testing or review quality as here, so I'd prefer to see you put it here. Sure, I might be difficult on this topic, but I do it because I believe there is a better, more robust manner to approach this problem space than currently you are considering. :) Thanks, > > best regards > thierry > ___ > 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 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 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
Release fedpkg-1.38
Hi all, a new version fedpkg-1.38 is released. Currently, Fedora 30, 31, 32 and Rawhide packages are in the stable repository, feel free to try other waiting distributions (el6, epel7) in Bodhi. Release description: Feature documentation, changelog and fixes description can be seen here: https://docs.pagure.org/fedpkg/releases/1.38.html Couple features include a demo video. Some items were released earlier the regular release as patches. Updates: https://bodhi.fedoraproject.org/updates/?builds=fedpkg-1.38-2.el6=fedpkg-1.38-2.el7=fedpkg-1.38-2.fc30=fedpkg-1.38-2.fc31=fedpkg-1.38-2.fc32=fedpkg-1.38-2.fc33 Alternative link: https://bodhi.fedoraproject.org/updates/?packages=fedpkg=1 Thanks to all contributors. Regards ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Release rpkg-1.58 fedpkg-1.37
Hi all, a new version fedpkg-1.38 is released. Currently, Fedora 30, 31, 32 and Rawhide packages are in the stable repository, feel free to try other waiting distributions (el6, epel7) in Bodhi. Release description: Feature documentation, changelog and fixes description can be seen here: https://docs.pagure.org/fedpkg/releases/1.38.html Couple features include a demo video. Some items were released earlier the regular release as patches. Updates: https://bodhi.fedoraproject.org/updates/?builds=fedpkg-1.38-2.el6=fedpkg-1.38-2.el7=fedpkg-1.38-2.fc30=fedpkg-1.38-2.fc31=fedpkg-1.38-2.fc32=fedpkg-1.38-2.fc33 Alternative link: https://bodhi.fedoraproject.org/updates/?packages=fedpkg=1 Thanks to all contributors. Regards > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do when packagers "forget" bodhi updates for branched (f32)?
On Mon, Mar 16, 2020 at 09:30:51PM +0100, Fabio Valentini wrote: > Hi everybody, > > It's that time of the semi-year again, and I again found multiple > instances of packages that have updates for rawhide and f31/f30, but > no bodhi update for fedora 32. > > In most cases, the updated package was built on fedora 32 (a koji > build was successful), but no bodhi update was created. In some cases, > f32 was "forgotten" entirely. > > So, assuming the best, those packagers simply forgot that bodhi > updates are necessary for branched releases after the beta freeze. > > What is the best couse of action for such forgotten updates? Some are > bugfixes, others are new versions, and some could be security fixes, > that are then missing from f32 entirely. I pushed a few updates after branching where I did try to submit updates and bodhi rejected them (too early) and then I simply missed the point where they became necessary. so for me - an email to fedora-{devel|announce} with "bodhi updates for f32 are required now" would be good. the more obvious the subject line the better. if that email was indeed sent and I missed it - oops and my apologies :) Failing all that, screaming at the maintainer in the most appreciative and respectful way is always a good way to get things fixed too :) > I *could* file bodhi updates for everything that's missing from f32, > but I do not want to interfere with others' work here. > > Filing bodhi comments on the updates that break the upgrade path > (f31/f30, in this case) is not productive either, since those comments > are often ignored in my experience. > > A few examples that popped up on my systems (I'm sure there are more): > > 1) dnsmasq-2.80-12.fc31 is going to f31 stable: > https://bodhi.fedoraproject.org/updates/FEDORA-2020-aab29ac03c > The corresponding f32 build (dnsmasq-2.80-13.fc32) succeeded in koji, > but then an internal koji error broke it. It wasn't resubmitted, and > there's no bodhi update for it: > https://koji.fedoraproject.org/koji/taskinfo?taskID=42386221 > > 2) libinput-1.15.3-2.fc31 is going to f31 stable: > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d66ed9f32e > The corresponding f32 build in koji was successful, but no bodhi > update is associated with it: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1475404 fixed now, apologies for the mess. Cheers, Peter > > 3) python-matplotlib-3.1.3-1.fc31 is going to f31 stable: > https://bodhi.fedoraproject.org/updates/FEDORA-2020-188dd2b161 > The update to 3.1.3 has been built for f33 and f31, but not for f32. > The 3.1.3 changes aren't even merged from master into the f32 branch > in dist-git. > > Any suggestions what we could do to make sure f32 updates aren't > forgotten after the beta freeze? > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2020-03-16.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change aalto-xml java-sig, orphan 2 weeks ago apache-commons-jexl mizdebsk, orphan 4 weeks ago appframework orphan 4 weeks ago bean-validation-api orphan 4 weeks ago bindexorphan 4 weeks ago clang7.0 orphan, sergesanspaille, 5 weeks ago tstellar clang8.0 orphan, sergesanspaille, 4 weeks ago tstellar compress-lzf orphan 2 weeks ago cpptasks orphan 1 weeks ago cuneiform orphan 4 weeks ago disruptor-thrift-server orphan 2 weeks ago dspam gnat, orphan 3 weeks ago dump jridky, orphan, vdolezal 4 weeks ago erlang-fs orphan 3 weeks ago felix-scr-maven-pluginjerboaa, jkang, orphan 5 weeks ago fluxcapacitor orphan, suve 3 weeks ago freemarkerorphan 4 weeks ago geronimo-jta mizdebsk, orphan 4 weeks ago glade3dridi, nonamedotc, orphan, 2 weeks ago rakesh gnome-shell-extension-orphan 4 weeks ago taskwarrior hexter-dssi orphan 1 weeks ago hibernate lef, odubaj, orphan 6 weeks ago ini4j orphan 6 weeks ago insectfnux, orphan 0 weeks ago jacocojvanek, kdaniel, lef, orphan 3 weeks ago javapoet orphan 2 weeks ago jboss-marshalling mizdebsk, orphan 2 weeks ago jetty-alpn-apimizdebsk, orphan 2 weeks ago jetty-build-support mizdebsk, orphan 1 weeks ago jmol jussilehtola, orphan 4 weeks ago js-jquery-jstree orphan 3 weeks ago js-jquery-notyorphan 3 weeks ago jspecview jussilehtola, orphan 4 weeks ago jsr-311 mizdebsk, orphan 4 weeks ago laszipdevrim, orphan 1 weeks ago libdivecomputer-subsurfaceorphan, rdieter 3 weeks ago liblasdevrim, orphan 1 weeks ago llvm7.0 jistone, orphan, 5 weeks ago sergesanspaille, tstellar llvm8.0 orphan, sergesanspaille, 4 weeks ago tstellar lv2-ll-pluginsorphan 1 weeks ago lz4-java orphan 2 weeks ago lzma-java orphan 2 weeks ago maven-injection-pluginmizdebsk, orphan 1 weeks ago maven-mapping mizdebsk, orphan 1 weeks ago mongo-java-driver jerboaa, lef, mskalick, orphan 3 weeks ago mvel orphan 1 weeks ago naga jussilehtola, orphan 4 weeks ago nekobee-dssi
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2020-03-16.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change aalto-xml java-sig, orphan 2 weeks ago apache-commons-jexl mizdebsk, orphan 4 weeks ago appframework orphan 4 weeks ago bean-validation-api orphan 4 weeks ago bindexorphan 4 weeks ago clang7.0 orphan, sergesanspaille, 5 weeks ago tstellar clang8.0 orphan, sergesanspaille, 4 weeks ago tstellar compress-lzf orphan 2 weeks ago cpptasks orphan 1 weeks ago cuneiform orphan 4 weeks ago disruptor-thrift-server orphan 2 weeks ago dspam gnat, orphan 3 weeks ago dump jridky, orphan, vdolezal 4 weeks ago erlang-fs orphan 3 weeks ago felix-scr-maven-pluginjerboaa, jkang, orphan 5 weeks ago fluxcapacitor orphan, suve 3 weeks ago freemarkerorphan 4 weeks ago geronimo-jta mizdebsk, orphan 4 weeks ago glade3dridi, nonamedotc, orphan, 2 weeks ago rakesh gnome-shell-extension-orphan 4 weeks ago taskwarrior hexter-dssi orphan 1 weeks ago hibernate lef, odubaj, orphan 6 weeks ago ini4j orphan 6 weeks ago insectfnux, orphan 0 weeks ago jacocojvanek, kdaniel, lef, orphan 3 weeks ago javapoet orphan 2 weeks ago jboss-marshalling mizdebsk, orphan 2 weeks ago jetty-alpn-apimizdebsk, orphan 2 weeks ago jetty-build-support mizdebsk, orphan 1 weeks ago jmol jussilehtola, orphan 4 weeks ago js-jquery-jstree orphan 3 weeks ago js-jquery-notyorphan 3 weeks ago jspecview jussilehtola, orphan 4 weeks ago jsr-311 mizdebsk, orphan 4 weeks ago laszipdevrim, orphan 1 weeks ago libdivecomputer-subsurfaceorphan, rdieter 3 weeks ago liblasdevrim, orphan 1 weeks ago llvm7.0 jistone, orphan, 5 weeks ago sergesanspaille, tstellar llvm8.0 orphan, sergesanspaille, 4 weeks ago tstellar lv2-ll-pluginsorphan 1 weeks ago lz4-java orphan 2 weeks ago lzma-java orphan 2 weeks ago maven-injection-pluginmizdebsk, orphan 1 weeks ago maven-mapping mizdebsk, orphan 1 weeks ago mongo-java-driver jerboaa, lef, mskalick, orphan 3 weeks ago mvel orphan 1 weeks ago naga jussilehtola, orphan 4 weeks ago nekobee-dssi
[Bug 1814068] New: perl-HTTP-BrowserDetect-3.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814068 Bug ID: 1814068 Summary: perl-HTTP-BrowserDetect-3.26 is available Product: Fedora Version: rawhide Status: NEW Component: perl-HTTP-BrowserDetect Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora Latest upstream release: 3.26 Current version/release in rawhide: 3.25-2.fc32 URL: http://search.cpan.org/dist/HTTP-BrowserDetect/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5936/ -- 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
Re: Using %triggerpostun with %systemd_post on upgrades
Another idea, since util-linux 2.35 is only on Fedora 32+, how about - %triggerpostun -- fedora-release < 32 + %triggerpostun -- util-linux < 2.35 %systemd_post fstrim.timer -- 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
Re: What to do when packagers "forget" bodhi updates for branched (f32)?
On 16. 03. 20 21:30, Fabio Valentini wrote: 3) python-matplotlib-3.1.3-1.fc31 is going to f31 stable: https://bodhi.fedoraproject.org/updates/FEDORA-2020-188dd2b161 The update to 3.1.3 has been built for f33 and f31, but not for f32. The 3.1.3 changes aren't even merged from master into the f32 branch in dist-git. See https://src.fedoraproject.org/rpms/python-matplotlib/pull-request/24 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
[Bug 1812567] perl-Devel-PatchPerl-1.90 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812567 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2020-03-16 20:38:41 --- Comment #3 from Fedora Update System --- perl-Devel-PatchPerl-1.90-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1812257] perl-Devel-PatchPerl-1.88 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812257 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Devel-PatchPerl-1.88-1 |perl-Devel-PatchPerl-1.88-1 |.fc33 |.fc33 |perl-Devel-PatchPerl-1.88-1 |perl-Devel-PatchPerl-1.88-1 |.fc32 |.fc32 ||perl-Devel-PatchPerl-1.90-1 ||.fc32 Resolution|--- |ERRATA Last Closed||2020-03-16 20:38:43 --- Comment #3 from Fedora Update System --- perl-Devel-PatchPerl-1.90-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1812177] perl-MooX-StrictConstructor-0.011 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812177 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2020-03-16 20:38:23 --- Comment #3 from Fedora Update System --- perl-MooX-StrictConstructor-0.011-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1812362] perl-XML-LibXML-2.0203 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812362 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-XML-LibXML-2.0203-1.fc |perl-XML-LibXML-2.0203-1.fc |33 |33 ||perl-XML-LibXML-2.0203-1.fc ||32 Resolution|--- |ERRATA Last Closed||2020-03-16 20:38:20 --- Comment #3 from Fedora Update System --- perl-XML-LibXML-2.0203-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1811831] perl-Devel-PPPort-3.58 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1811831 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Devel-PPPort-3.58-1.fc |perl-Devel-PPPort-3.58-1.fc |33 |33 ||perl-Devel-PPPort-3.58-1.fc ||32 Resolution|--- |ERRATA Last Closed||2020-03-16 20:37:44 --- Comment #3 from Fedora Update System --- perl-Devel-PPPort-3.58-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1811986] perl-Sys-Virt-6.1.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1811986 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2020-03-16 20:37:57 --- Comment #2 from Fedora Update System --- perl-Sys-Virt-6.1.0-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1811507] perl-Test-Simple-1.302172 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1811507 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Test-Simple-1.302172-1 |perl-Test-Simple-1.302172-1 |.fc33 |.fc33 ||perl-Test-Simple-1.302172-1 ||.fc32 Resolution|--- |ERRATA Last Closed||2020-03-16 20:36:24 --- Comment #3 from Fedora Update System --- perl-Test-Simple-1.302172-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1004354] perl-Alien-ROOT not available on ARM because root is not there
https://bugzilla.redhat.com/show_bug.cgi?id=1004354 --- Comment #12 from Fedora Update System --- perl-Alien-ROOT-5.34.36.1-18.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1811541] rt-4.4.4-4.fc33 FTBFS: No matching package to install: '/usr/share/fonts/google-droid/DroidSans.ttf'
https://bugzilla.redhat.com/show_bug.cgi?id=1811541 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||rt-4.4.4-5.fc32 Resolution|--- |ERRATA Last Closed||2020-03-16 20:36:41 --- Comment #3 from Fedora Update System --- rt-4.4.4-5.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1810624] perl-Redis-1.996 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1810624 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2020-03-16 20:34:41 --- Comment #5 from Fedora Update System --- perl-Redis-1.996-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1810919] perl-Net-GitHub-0.96 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1810919 --- Comment #4 from Fedora Update System --- perl-Net-GitHub-0.96-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1809718] perl-Locale-Codes-3.63 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1809718 --- Comment #8 from Fedora Update System --- perl-Locale-Codes-3.63-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1810308] perl-TimeDate-2.32 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1810308 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2020-03-16 20:33:59 --- Comment #3 from Fedora Update System --- perl-TimeDate-2.32-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1809881] perl-Log-ger-0.031 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1809881 --- Comment #3 from Fedora Update System --- perl-Log-ger-0.031-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1808744] perl-CPAN-Perl-Releases-5.20200229 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808744 --- Comment #9 from Fedora Update System --- perl-CPAN-Perl-Releases-5.20200229-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1809214] perl-Test-Deep-1.130 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1809214 --- Comment #4 from Fedora Update System --- perl-Test-Deep-1.130-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
What to do when packagers "forget" bodhi updates for branched (f32)?
Hi everybody, It's that time of the semi-year again, and I again found multiple instances of packages that have updates for rawhide and f31/f30, but no bodhi update for fedora 32. In most cases, the updated package was built on fedora 32 (a koji build was successful), but no bodhi update was created. In some cases, f32 was "forgotten" entirely. So, assuming the best, those packagers simply forgot that bodhi updates are necessary for branched releases after the beta freeze. What is the best couse of action for such forgotten updates? Some are bugfixes, others are new versions, and some could be security fixes, that are then missing from f32 entirely. I *could* file bodhi updates for everything that's missing from f32, but I do not want to interfere with others' work here. Filing bodhi comments on the updates that break the upgrade path (f31/f30, in this case) is not productive either, since those comments are often ignored in my experience. A few examples that popped up on my systems (I'm sure there are more): 1) dnsmasq-2.80-12.fc31 is going to f31 stable: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aab29ac03c The corresponding f32 build (dnsmasq-2.80-13.fc32) succeeded in koji, but then an internal koji error broke it. It wasn't resubmitted, and there's no bodhi update for it: https://koji.fedoraproject.org/koji/taskinfo?taskID=42386221 2) libinput-1.15.3-2.fc31 is going to f31 stable: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d66ed9f32e The corresponding f32 build in koji was successful, but no bodhi update is associated with it: https://koji.fedoraproject.org/koji/buildinfo?buildID=1475404 3) python-matplotlib-3.1.3-1.fc31 is going to f31 stable: https://bodhi.fedoraproject.org/updates/FEDORA-2020-188dd2b161 The update to 3.1.3 has been built for f33 and f31, but not for f32. The 3.1.3 changes aren't even merged from master into the f32 branch in dist-git. Any suggestions what we could do to make sure f32 updates aren't forgotten after the beta freeze? Fabio ___ 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
[Bug 1808774] perl-List-AllUtils-0.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808774 --- Comment #11 from Fedora Update System --- perl-List-AllUtils-0.16-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1808816] perl-String-Print-0.94 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808816 --- Comment #9 from Fedora Update System --- perl-String-Print-0.94-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1808799] perl-Dist-Zilla-6.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808799 --- Comment #4 from Fedora Update System --- perl-Dist-Zilla-6.014-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1808731] perl-DateTime-Format-Strptime-1.77 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808731 --- Comment #3 from Fedora Update System --- perl-DateTime-Format-Strptime-1.77-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1809202] perl-Date-Manip-6.80 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1809202 --- Comment #6 from Fedora Update System --- perl-Date-Manip-6.80-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1808730] perl-DateTime-1.52 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808730 --- Comment #5 from Fedora Update System --- perl-DateTime-1.52-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1807263] perl-Getopt-Long-Descriptive-0.105 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1807263 --- Comment #5 from Fedora Update System --- perl-Getopt-Long-Descriptive-0.105-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1809718] perl-Locale-Codes-3.63 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1809718 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Locale-Codes-3.63-1.fc |perl-Locale-Codes-3.63-1.fc |33 |33 |perl-Locale-Codes-3.63-1.fc |perl-Locale-Codes-3.63-1.fc |31 |31 |perl-Locale-Codes-3.63-1.fc |perl-Locale-Codes-3.63-1.fc |30 |30 ||perl-Locale-Codes-3.63-1.fc ||32 --- Comment #7 from Fedora Update System --- perl-Locale-Codes-3.63-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1809881] perl-Log-ger-0.031 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1809881 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Log-ger-0.031-1.fc33 |perl-Log-ger-0.031-1.fc33 ||perl-Log-ger-0.031-1.fc32 Resolution|--- |ERRATA Last Closed||2020-03-16 20:21:40 --- Comment #2 from Fedora Update System --- perl-Log-ger-0.031-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1809202] perl-Date-Manip-6.80 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1809202 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Date-Manip-6.80-1.fc31 |perl-Date-Manip-6.80-1.fc31 ||perl-Date-Manip-6.80-1.fc32 --- Comment #5 from Fedora Update System --- perl-Date-Manip-6.80-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1808799] perl-Dist-Zilla-6.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808799 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Dist-Zilla-6.014-1.fc3 |perl-Dist-Zilla-6.014-1.fc3 |3 |3 ||perl-Dist-Zilla-6.014-1.fc3 ||2 Resolution|--- |ERRATA Last Closed||2020-03-16 20:20:19 --- Comment #3 from Fedora Update System --- perl-Dist-Zilla-6.014-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1808774] perl-List-AllUtils-0.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808774 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-List-AllUtils-0.16-1.f |perl-List-AllUtils-0.16-1.f |c33 |c33 |perl-List-AllUtils-0.16-1.f |perl-List-AllUtils-0.16-1.f |c30 |c30 |perl-List-AllUtils-0.16-1.f |perl-List-AllUtils-0.16-1.f |c31 |c31 ||perl-List-AllUtils-0.16-1.f ||c32 --- Comment #10 from Fedora Update System --- perl-List-AllUtils-0.16-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1808730] perl-DateTime-1.52 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808730 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-DateTime-1.52-1.fc33 |perl-DateTime-1.52-1.fc33 ||perl-DateTime-1.52-1.fc32 Resolution|--- |ERRATA Last Closed||2020-03-16 20:19:46 --- Comment #4 from Fedora Update System --- perl-DateTime-1.52-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1808744] perl-CPAN-Perl-Releases-5.20200229 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808744 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0200229-1.fc33 |0200229-1.fc33 |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0200229-1.fc30 |0200229-1.fc30 |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0200229-1.fc31 |0200229-1.fc31 ||perl-CPAN-Perl-Releases-5.2 ||0200229-1.fc32 --- Comment #8 from Fedora Update System --- perl-CPAN-Perl-Releases-5.20200229-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1809214] perl-Test-Deep-1.130 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1809214 Fedora Update System changed: What|Removed |Added Resolution|RAWHIDE |ERRATA --- Comment #3 from Fedora Update System --- perl-Test-Deep-1.130-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1808731] perl-DateTime-Format-Strptime-1.77 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808731 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-DateTime-Format-Strpti |perl-DateTime-Format-Strpti |me-1.77-1.fc33 |me-1.77-1.fc33 ||perl-DateTime-Format-Strpti ||me-1.77-1.fc32 Resolution|--- |ERRATA Last Closed||2020-03-16 20:19:48 --- Comment #2 from Fedora Update System --- perl-DateTime-Format-Strptime-1.77-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1808816] perl-String-Print-0.94 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808816 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-String-Print-0.94-1.fc |perl-String-Print-0.94-1.fc |33 |33 |perl-String-Print-0.94-1.fc |perl-String-Print-0.94-1.fc |30 |30 |perl-String-Print-0.94-1.fc |perl-String-Print-0.94-1.fc |31 |31 ||perl-String-Print-0.94-1.fc ||32 --- Comment #8 from Fedora Update System --- perl-String-Print-0.94-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
[Bug 1807263] perl-Getopt-Long-Descriptive-0.105 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1807263 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Getopt-Long-Descriptiv |perl-Getopt-Long-Descriptiv |e-0.105-1.fc33 |e-0.105-1.fc33 ||perl-Getopt-Long-Descriptiv ||e-0.105-1.fc32 Resolution|--- |ERRATA Last Closed||2020-03-16 20:14:54 --- Comment #4 from Fedora Update System --- perl-Getopt-Long-Descriptive-0.105-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, 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
Re: Intent to request a FESCo exception for python2 for ardour5
Il giorno dom, 15/03/2020 alle 14.44 +0100, Fabio Valentini ha scritto: > On Sun, Mar 15, 2020 at 2:37 PM Alexander Bokovoy < > aboko...@redhat.com> wrote: > > On su, 15 maalis 2020, Guido Aulisi wrote: > > > Hi, > > > > > > I’m going to ask a FESCo exception for python2 for package > > > ardour5. > > > Python2 is only needed to build the package using the WAF build > > > system. > > > > > > Ardour has been undergoing a complete rewriting for 2 years, no > > > stable versions have been released in the last 2 years, > > > so we are stuck with ardour 5.12, which still uses python2 to > > > build. > > > > > > What do you think about that? > > (snip) > > > Just package git master in Rawhide. It has been migrated to waf > > 2.0.19 > > two months ago and builds just fine in Fedora 32 environments with > > Python 3 only. It's not considered ready for production by the developers, yet. > I think FESCo would agree to temporarily continue building it with > python2, given that upstream has already worked on supporting > building > with python3 eventually. At least, I would approve such an exception > request (and other, similar requests for firefox, chromium, etc. have > already been approved). Thank you, I will make the request ASAP. > But, if you think a current git snapshot would be an appropriate > target for packaging, that solves the problem as well (I don't know > how stable their development branch is). AFAIK it's currently in alpha stage, I would wait for the next GIT tag. Ciao Guido FAS: tartina signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Beware: java-1.8.0-openjdk SIGSEGVs / SIGABRTs in rawhide
Il giorno dom, 15/03/2020 alle 15.02 +0100, Fabio Valentini ha scritto: > Hi everybody, > > The latest java-1.8.0-openjdk update for rawhide (the first build > with > GCC 10) seems to have introduced some serious problems - including > crashes and segmentation faults during package builds for Java > packages. I had some problems with sord package with GCC 10, I had to lower optimization to -O1. It only happened on power64le and arm arches, not x86. The problem is in a for loop, the exit condition (with calls a function whcih modifies its argument) is never(?) evaluated (optimized out?). The problem is present in F32 as well. I could not find the root cause, because I do not know power assembler that well. Ciao Guido FAS: tartina signature.asc Description: This is a digitally signed message part ___ 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
[Bug 1814011] New: perl-Mojolicious-8.34 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814011 Bug ID: 1814011 Summary: perl-Mojolicious-8.34 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Mojolicious Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org, robinlee.s...@gmail.com, yan...@declera.com Target Milestone: --- Classification: Fedora Latest upstream release: 8.34 Current version/release in rawhide: 8.33-2.fc33 URL: https://metacpan.org/release/Mojolicious Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5966/ -- 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
Re: RFC: entering luks password on grub level for devices without keyboards
On Mon, 16 Mar 2020 at 13:56, Robbie Harwood wrote: > Tomasz Torcz writes: > > > On Sun, Mar 15, 2020 at 11:12:43PM +0100, Marius Schwarz wrote: > >> Am 15.03.20 um 13:32 schrieb Vitaly Zaitsev via devel: > >> > On 14.03.2020 13:05, Marius Schwarz wrote: > >> >> If you encrypt the fedora ( or any ) installation with luks, as > >> >> security of a mobile device indicates, you end up without the > >> >> possibility to enter the password, when you do not have an > in/external > >> >> keyboard at hand. > >> > You should use TPM 2.0 LUKS unlock instead of using passwords. > >> > > >> I knew someone would bring this up: TMP does not protect your drive, > >> as you could boot with "init=/bin/bash 1" . > > > >How do you do that WITHOUT KEYBOARD? This thread is about very > > specific situation, please do not forget that when generalising. > > I believe nothing stops someone from simply plugging one in. > > And the counter point is that if you can't plug one in, it is not something that is supported. This is not general purpose hardware but a set of hardware that is primarily built to run Microsoft Windows by the vendor. There are going to be limits to what is going to be possible to get done with it. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: confused by rpminspect automated test
On Mon, Mar 09, 2020 at 05:45:34PM +, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Mar 09, 2020 at 10:35:03AM -0700, Adam Williamson wrote: On Mon, 2020-03-09 at 11:49 -0400, David Cantrell wrote: > > > > /etc/rpminspect/rpminspect.conf > > > > So that is a global config file... > > RFE: move it under /usr, and only look for overrides in /etc. > > 99% of users should not modify that, and it shouldn't be in /etc. > > I disagree. Users are allowed to edit configuration files in /etc. True, but Zbigniew isn't wrong either. I think the more modern config pattern he refers to clearly *is* superior; it's much better for the standard configuration to be in a 'not-meant-to-be-edited' file in /usr/share but for the config loading mechanism to look for override snippets in /etc/rpminspect/conf.d or whatever. Yes, very much so. The important part is to be able to drop-in overrides without caring about the rest of the configuration, and to have the rest of the configuration update itself on package upgrades without me having to do anything. It means the upstream configuration can be updated without local customizations being lost, and it's much nicer for the sysadmin as well, for two reasons: 1) If you want to have two different local customizations for different purposes, you can put them in 01-this.conf and 02-that.conf , with the names being descriptive. This is *far* easier to understand when you come back to it in three years than a single monolithic config file which you *maybe* wrote some comments in. 2) You don't have to read or care about the entire config, your snippet only needs to have as much in it as you actually want to change. > As for the location, I could put it with the rest of the vendor-specific data > in /usr/share/rpminspect and allow for the location in /etc to override it as > you suggest. So it would become: > > /usr/share/rpminspect/rpminspect.conf (if it exists) > /etc/rpminspect/rpminspect.conf (if it exists) > > As stated above, I have a pending patch set that will add .rpminspectrc as the > last one in this list. That would be read from the directory you invoke > rpminspect in. The intent here is to allow package maintainers to add it to > dist-git for further control of how rpminspect runs in gating. > > Then if you specify a profile, it would search dirs in this order: > > /usr/share/rpminspect/profiles > /etc/rpminspect/profiles > > The vendor data package would stop providing the /etc files. I'm not opposed > to this layout. Is this along the lines of what you're thinking? Yeah, except with the snippet thing too. Accept partial config snippets, not just an entire file. They main way I imagine myself using rpminspect is to have a bunch of overrides per package, and some "global" Fedora overrides, and to call rpminspect either during review or for koji builds or when modifying dist-git. In general I expect the per-package config to live in dist-git. ".rpminspect" is OK, but a non-hidden file would be even better. (*) This makes sense. My reply to adamw mentioned an ordering I was thinking of: /usr/share/rpminspect /etc/rpminspect . Where . is the dist-git project. I was going to go with .rpminspectrc, but I can name it anything. Do you have any preferences? (*) Does rpminspect have access to dist-git contents when run in gating? Right now it does not, but that is planned pending the config file restructuring I'm talking about. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: confused by rpminspect automated test
On Mon, Mar 09, 2020 at 10:35:03AM -0700, Adam Williamson wrote: On Mon, 2020-03-09 at 11:49 -0400, David Cantrell wrote: > > /etc/rpminspect/rpminspect.conf > > So that is a global config file... > RFE: move it under /usr, and only look for overrides in /etc. > 99% of users should not modify that, and it shouldn't be in /etc. I disagree. Users are allowed to edit configuration files in /etc. True, but Zbigniew isn't wrong either. I think the more modern config pattern he refers to clearly *is* superior; it's much better for the standard configuration to be in a 'not-meant-to-be-edited' file in /usr/share but for the config loading mechanism to look for override snippets in /etc/rpminspect/conf.d or whatever. It means the upstream configuration can be updated without local customizations being lost, and it's much nicer for the sysadmin as well, for two reasons: 1) If you want to have two different local customizations for different purposes, you can put them in 01-this.conf and 02-that.conf , with the names being descriptive. This is *far* easier to understand when you come back to it in three years than a single monolithic config file which you *maybe* wrote some comments in. 2) You don't have to read or care about the entire config, your snippet only needs to have as much in it as you actually want to change. Sorry, let me clarify. I like the ".d" layout for letting a group of files form a valid configuration for a program as well as the override path. i.e., read the system wide default, then local host settings, then per user settings. This is a nice way to structure configuration data. What I was wanting to say is that users and developers should still regard these files as config files and should be ok editing them to at least figure out what they should be set to in order to work. I say this because I don't want "config file settings should be changed" to be reported as a bug in the program when it could be a pull request to update the configuration file. If we're regarding config files as immutable, then there's no reason to have them. So, change the config file around, see what makes it work, then send a pull request to update it in whatever package delivered it. As for the location, I could put it with the rest of the vendor-specific data in /usr/share/rpminspect and allow for the location in /etc to override it as you suggest. So it would become: /usr/share/rpminspect/rpminspect.conf (if it exists) /etc/rpminspect/rpminspect.conf (if it exists) As stated above, I have a pending patch set that will add .rpminspectrc as the last one in this list. That would be read from the directory you invoke rpminspect in. The intent here is to allow package maintainers to add it to dist-git for further control of how rpminspect runs in gating. Then if you specify a profile, it would search dirs in this order: /usr/share/rpminspect/profiles /etc/rpminspect/profiles The vendor data package would stop providing the /etc files. I'm not opposed to this layout. Is this along the lines of what you're thinking? Yeah, except with the snippet thing too. Accept partial config snippets, not just an entire file. Entirely reasonable. I can restructure things to work this way and allow host and user overrides. However, for the latter I think per-project might be more useful than host overrides since this is the sort of program that doesn't get value from per-user settings. It's really per project settings. So I would say: /usr/share/rpminspect /etc/rpminspect . Where . is the dist-git repo you're working on. I have /etc/rpminspect/rpminspect.conf now. Suggestions on how I should split that out and name directories? Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: entering luks password on grub level for devices without keyboards
Tomasz Torcz writes: > On Sun, Mar 15, 2020 at 11:12:43PM +0100, Marius Schwarz wrote: >> Am 15.03.20 um 13:32 schrieb Vitaly Zaitsev via devel: >> > On 14.03.2020 13:05, Marius Schwarz wrote: >> >> If you encrypt the fedora ( or any ) installation with luks, as >> >> security of a mobile device indicates, you end up without the >> >> possibility to enter the password, when you do not have an in/external >> >> keyboard at hand. >> > You should use TPM 2.0 LUKS unlock instead of using passwords. >> > >> I knew someone would bring this up: TMP does not protect your drive, >> as you could boot with "init=/bin/bash 1" . > >How do you do that WITHOUT KEYBOARD? This thread is about very > specific situation, please do not forget that when generalising. I believe nothing stops someone from simply plugging one in. Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: MinGW environment and toolchain update
On 16/03/20 11:23 -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/F33MingwEnvToolchainUpdate == Summary == Update the MinGW base environment and toolchain to the latest upstream stable releases. == Owner == * Name: [[User:smani|Sandro Mani]] * Email: manisan...@gmail.com == Detailed Description == The following packages will be updated * mingw-gcc to version 10.0.0 That's not a GCC release. Does this mean a 10.0.1 pre-release version from GCC Git, or the 10.1.0 release that is expected in a few weeks? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to fix a dependency to the version at build time?
On Mon, Mar 16, 2020 at 10:38:07AM +, Paul Howarth wrote: > On Mon, 16 Mar 2020 11:22:40 +0100 > Vít Ondruch wrote: > > I always thought that one should not call `rpm` during rpmbuild. > > Nevertheless I am not sure what was the reason? Probably locking of > > RPM db? Can somebody elaborate? > > It couldn't be guaranteed to work in the case that the buildroot was > populated using a different version of rpm that used a different > version of libdb. That's not an issue that crops up much these days as > libdb hasn't been version-updated for years (due to licensing issues Except that now we are going to move to sqlite... :) (See rpm 4.16 change posted today) > IIRC) and mock with bootstrap mode enabled would populate the buildroot > using the target's version of rpm anyway these days. and koji does not use bootstrap mode. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390x build problem again (_rpm.error: error reading package header)
On Sat, Mar 14, 2020 at 03:57:09PM -0600, Jerry James wrote: > On Sat, Mar 14, 2020 at 3:46 PM Dominik 'Rathann' Mierzejewski > wrote: > > My scratch builds are failing on s390x: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=42450592 > > https://koji.fedoraproject.org/koji/taskinfo?taskID=42450600 > > https://koji.fedoraproject.org/koji/taskinfo?taskID=42450608 > > with: > > > > _rpm.error: error reading package header > > > > Anyone else seeing this? > > That very issue prevented some packages from being built during the > mass rebuild. As far as I can tell, builds still have not been done > for the affected packages: > > https://pagure.io/releng/issue/9220 Yes, I resubmitted all the ones that failed (actually, I just did a full second pass and resubmitted everything that failed in the initial rebuild), Unfortunately, our messaging plugin/koji does not emit a failed for these builds (since they failed in src.rpm and never "started"). So, we need to figure out some way to identify them before we can resubmit them. I guess the hope was that maintainers would notice and just resbumit them, but thats not happened. ;( I'll update the ticket and we can try and figure something out. 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
[389-devel] Please have a look at rewriters design
Hi, As a follow up of the PR https://pagure.io/389-ds-base/pull-request/50939, I wrote down a small design about rewriters (filter/computed_attr) plugin: http://www.port389.org/docs/389ds/design/search_rewriters.html Comments are welcome best regards thierry ___ 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
Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB
On Mon, Mar 16, 2020 at 11:24 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb > > == Summary == > Change format of the RPM database from Berkeley DB to a new Sqlite format. > > == Owner == > * Name: [[User:pmatilai| Panu Matilainen]] [[User:ffesti|Florian Festi]] > * Email: pmati...@redhat.com ffe...@redhat.com > > == Detailed Description == > > The current rpm database implementation is based on Berkeley DB 5.x, a > version which is unmaintained upstream for several years now. Berkeley > DB 6.x is license incompatible so moving to that is not an option. In > addition, the existing rpmdb implementation is notoriously unreliable > as it's not transactional and has no other means to detect > inconsistencies either. > > Changing to a more sustainable database implementation is long > overdue. We propose to change the default rpmdb format to the new > sqlite based implementation. Support for current BDB format will be > retained in Fedora 33, and phased out to read-only support in Fedora > 34. > > == Benefit to Fedora == > > * A far more robust rpm database implementation > * Getting rid of Berkeley DB dependency in one of the core components > > == Scope == > * Proposal owners: > ** Once [[Changes/RPM-4.16|RPM 4.16]] lands and passes initial > shakedown, change the default rpmdb configuration to sqlite > ** Address any bugs and issues in the database backend found by wider > testing base > ** Help other developers to address Berkeley DB dependencies > > * Other developers: > ** Test for hidden Berkeley DB dependencies in other software, address > them as found and needed > > * Release engineering: [https://pagure.io/releng/issue/9308 #9308] > > * Policies and guidelines: Policies and guidelines are not affected > > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > > === Upgrading === > * Ability to upgrade is not affected > * After upgrade completes, manual action (rpmdb --rebuilddb) will > probably be needed to convert to sqlite. Alternatively user can change > configuration to stay on BDB. > > === Compatibility === > * Container/chroot use-cases will be affected: older rpm versions will > be unable to query/manipulate the rpmdb from outside the chroot > * Koji/COPR may need to override the database format (back to) BDB for > the time being > > == How To Test == > * Rpmdb gets thoroughly exercised as a matter of normal system > operation, performing installs, updates, package builds etc > * Of specific interest here is torture testing: forcibly killing rpm > in various stages of execution - database should stay consistent and > operational (other system state is out of scope) > * Test database conversions from one backend to another (rpmdb > --rebuilddb --define "_db_backend ") > > == User Experience == > * In normal operation, users should see little or no change > * Behavior in error situations is much more robust: forcibly killed > transaction no longer causes database inconsistency or corruption > > == Dependencies == > * This change depends on [[Changes/RPM-4.16|RPM 4.16]], support for > sqlite rpmdb is not present in older versions > * RPM will grow a new dependency on sqlite-libs > * Technically the rpmdb format is an internal implementation detail of > RPM and the data is only accessible through the librpm API, but some > software is making assumptions both about the format and/or in > particular, file naming. These are being tracked at > https://bugzilla.redhat.com/show_bug.cgi?id=1766120 > * Upgrade tooling could/should perform rpmdb rebuild at end, this > would be a good thing to do regardless of this change > > == Contingency Plan == > > * Contingency mechanism: > ** Revert the default database back to Berkeley DB backend in the > package. Running 'rpmdb --rebuilddb' on hosts is currently required to > actually convert the database, but means to automate conversion in > specific conditions is being discussed upstream. > ** The rpm-team does not expect problems with the database backend > itself, but we are aware that postponing may be needed due to > infrastructure or other tooling not being ready, primarily due to > inability to access the database from older releases. > > * Contingency deadline: Beta freeze > * Blocks release? Yes > > == Documentation == > * [https://rpm.org/wiki/Releases/4.16.0 | RPM 4.16 release notes] > > == Release Notes == > > * After upgrading from an older release, rpm operations will issue > warnings about database backend configuration not matching what's on > disk. Users should run 'rpmdb --rebuilddb' at earliest opportunity, or > change configuration to stay on Berkeley DB backend (eg 'echo > %_db_backend bdb > /etc/rpm/macros.db') > * The details are subject to change, the database rebuild may be done > by upgrade tooling > I'm glad to *finally* see this happen, so congratulations to the RPM team for finally making this a reality! I look forward to trying this out in Rawhide as soon as
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9d364c6070 cacti-1.2.10-1.el8 cacti-spine-1.2.10-1.el8 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8ce58993d7 mbedtls-2.16.5-1.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-02f03affd4 ansible-2.9.6-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1402a55654 nethack-3.6.6-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d92c8360fe chromium-80.0.3987.132-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing inxi-3.0.38-1.el8 libslz-1.2.0-2.el8 tweeny-3.1.0-1.el8 Details about builds: inxi-3.0.38-1.el8 (FEDORA-EPEL-2020-f13a0de2dd) A full featured system information script Update Information: Update to 3.0.38. ChangeLog: * Mon Mar 16 2020 Vasiliy N. Glazov - 3.0.38-1 - Update to 3.0.38 * Wed Jan 29 2020 Fedora Release Engineering - 3.0.37-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild libslz-1.2.0-2.el8 (FEDORA-EPEL-2020-b501595a2a) StateLess Zip Update Information: Fix the file permissions of the library ChangeLog: * Mon Mar 16 2020 Dridi Boukelmoune - 1.2.0-2 - Fix the file permissions of the library References: [ 1 ] Bug #1785508 - Please build libslz for EPEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=1785508 tweeny-3.1.0-1.el8 (FEDORA-EPEL-2020-2ebe812f0d) Modern C++ tweening library Update Information: Updated to version 3.1.0. ChangeLog: * Sun Mar 15 2020 Vitaly Zaitsev - 3.1.0-1 - Updated to version 3.1.0. * Fri Jan 31 2020 Fedora Release Engineering - 3-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild ___ 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
Summary/Minutes from today's FESCo Meeting (2020-03-16)
Meeting started by zbyszek at 15:00:56 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2020-03-16/fesco.2020-03-16-15.00.log.html . Meeting summary --- * init process (zbyszek, 15:00:59) * #2356 Fedora 31: Reset eclipse stream for all (once) or leave the bugzilla unfixed? (zbyszek, 15:05:56) * AGREED: Reset is approved (with details to be written up) (+5, 0, 0) (zbyszek, 15:21:12) The wiki page should be linked from a message emitted by the scriptlet, and the reset should be announced to fedora-devel a few days before the package with the resetting scriptlet is pushed out. * ACTION: sgallagh to submit PR for fedora-release to implement the reset. (sgallagh, 15:21:43) * ACTION: zbyszek to write up available options in the wiki (zbyszek, 15:23:24) * #2354 32-bit ARM installer release-blocking status unclear * AGREED: Option 1 is approved (+7, 0, 0) (zbyszek, 15:32:00) * ACTION: bcotton to update the wiki or reassign to the next "volunteer" (zbyszek, 15:35:04) * Next week's chair (zbyszek, 15:35:19) * ACTION: zbyszek will chair the next meeting (zbyszek, 15:35:33) * Open Floor (zbyszek, 15:35:41) * ACTION: bookwar to write up #2284 (zbyszek, 15:39:34) Meeting ended at 15:52:36 UTC. Action Items * sgallagh to submit PR for fedora-release to implement the reset (for #2356) * zbyszek to write up available options in the wiki (for #2356) * bcotton to update the wiki or reassign to the next "volunteer" (for #2354) * zbyszek will chair the next meeting * bookwar to write up #2284 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS UP: repoquery --whatrequires yields incomplete results when run from Fedora 32+
On Wed, Mar 11, 2020 at 5:26 PM Miro Hrončok wrote: > > I have upgraded to Fedora 32 today and after a while I have noticed that > `repoquery --whatrequires` yields incomplete results. > > From Fedora 31: > > $ dnf --refresh repoquery --repo=rawhide{,-source} --whatrequires > python3-flaky > pipenv-0:2018.11.26-13.fc32.src > python-ipykernel-0:5.1.4-1.fc33.src > > > From Fedora 32/33: > > $ dnf --refresh repoquery --repo=rawhide{,-source} --whatrequires > python3-flaky > python-ipykernel-0:5.1.4-1.fc33.src > > > I have reported this here: https://bugzilla.redhat.com/show_bug.cgi?id=1812596 > > > Be extra careful when taking decisions based on `repoquery --whatrequires` > (such > as: I can safely retire this or upgrade that, nothing else requires it). Can confirm this issue on fedora 32. It's now one of the reasons why I haven't upgraded my main machine to f32 yet :/ Looks like "--alldeps" no longer works correctly (neither implicitly or explicitly). Fabio > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] please review: PR 50958 - buldnum.py - fix date formatting issue
https://pagure.io/389-ds-base/pull-request/50958 -- 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
Fedora 33 System-Wide Change proposal: MinGW environment and toolchain update
https://fedoraproject.org/wiki/Changes/F33MingwEnvToolchainUpdate == Summary == Update the MinGW base environment and toolchain to the latest upstream stable releases. == Owner == * Name: [[User:smani|Sandro Mani]] * Email: manisan...@gmail.com == Detailed Description == The following packages will be updated * mingw-gcc to version 10.0.0 * mingw-w64-tools to version 7.0.0 * mingw-winpthreads to version 7.0.0 * mingw-crt to version 7.0.0 * mingw-headers to version 7.0.0 * mingw-binutils to version 2.34 * mingw-gdb to version 9.1 == Benefit to Fedora == Ship the latest available MinGW environment and GNU toolchain. == Scope == * Proposal owners: The above mentioned packages will be updated. Build failures following the mass rebuild will be inspected. * Other developers: Help with build failures may be requested. * Release engineering: Impact check [https://pagure.io/releng/issue/9253] * Release engineering: Mass rebuild requested * Policies and guidelines: No policies need to be changed == Upgrade/compatibility impact == No impact == How To Test == Update the system once the updated packages land, look out for new build failures etc. == User Experience == The features of the newest MinGW environment and GNU Toolchain will be available to the users. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert to older versions of environment / toolchain, mass rebuild mingw packages again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No == Release Notes == Fedora 33 comes with the mingw-w64-7.0.0 environment, mingw-gcc-10, mingw-gdb-9.1 and mingw-binutils 2.34. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org
Fedora 33 System-Wide Change proposal: GNU Make version 4.3
https://fedoraproject.org/wiki/Changes/MAKE43 == Summary == Rebase GNU make in Fedora 33 from make version 4.2 to make version 4.3. == Owner == * Name: [[User:djdelorie| DJ Delorie]] * Email: d...@redhat.com == Detailed Description == Make 4.3 was released on January 19th 2020. It includes many bug fixes and new features. Fedora has been carrying many patches to the 4.2 release which are included in 4.3, reducing the workload for Fedora builders. Note that Fedora is also carrying some patches to retain compatibility with make version 3.8, as an aid to packages which needed time to adapt to make version 4. These compatibility patches will be removed in this rebase, making Fedora's make the same as other distros. Some packages may FTBFS and need help tweaking their Makefiles. == Benefit to Fedora == Stay up to date with upstream GNU make, make sure we have the latest bug fixes et al, be compatible with stock GNU make. == Scope == * Proposal owners: Update to GNU make 4.3 * Other developers: Package owners relying on makefile features specific to older versions of GNU make (including compatibility patches for 3.8 we're dropping) may FTBFS and need to tweak their Makefiles. * Release engineering: (a check of an impact with Release Engineering is pending) * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Users who have local projects using GNU make, which rely on features only available in older versions of GNU make, may need to tweak their Makefiles before rebuilding. Packages which were built previous to this upgrade will not be affected. Specific backwards incompatibilities as called out in the NEWS file for make 4.3: * WARNING: Backward-incompatibility! Number signs (#) appearing inside a macro reference or function invocation no longer introduce comments and should not be escaped with backslashes: thus a call such as: foo := $(shell echo '#') is legal. Previously the number sign needed to be escaped, for example: foo := $(shell echo '\#') Now this latter will resolve to "\#". If you want to write makefiles portable to both versions, assign the number sign to a variable: H := \# foo := $(shell echo '$H') This was claimed to be fixed in 3.81, but wasn't, for some reason. To detect this change search for 'nocomment' in the .FEATURES variable. * WARNING: Backward-incompatibility! Previously appending using '+=' to an empty variable would result in a value starting with a space. Now the initial space is only added if the variable already contains some value. Similarly, appending an empty string does not add a trailing space. == How To Test == GNU make has its own testsuite and does not require specific hardware or testing outside of building the RPM. == User Experience == Users will get all bugfixes included in make 4.3 as well as any new features therein. The make 4.3 NEWS update will include more details. == Dependencies == No dependencies. == Contingency Plan == * Contingency mechanism: Revert to make 4.2.1 * Contingency deadline: Beta freeze. If there is a mass rebuild, preferably before then. * Blocks release? No == Documentation == GNU Make includes its own documentation. No additional documentation work is required. == Release Notes == Full release notes can be found in make's NEWS file: http://git.savannah.gnu.org/cgit/make.git/tree/NEWS -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org
Fedora 33 System-Wide Change proposal: RPM 4.16
https://fedoraproject.org/wiki/Changes/RPM-4.16 == Summary == Update RPM to the 4.16.0 release. == Owner == * Name: User:pmatilai, User:ffesti * Email: pmati...@redhat.com,ffe...@redhat.com == Detailed Description == RPM 4.16 contains numerous improvements over previous versions * New database backends and related developments to enable moving away from Berkeley DB ** experimental sqlite backend ** experimental readonly-bdb backend to support conversion from BDB without the library ** ndb backend promoted out of experimental * Much improved expression parser (specs and macros) * Powerful new macro features (expressions, ternary operator, literal macros, access to macro body, eliminate unexpected double-expansion etc) * Support for macro-only dependency generators (very fast as fork+exec is entirely avoided) * Support for meta dependencies (which do not affect ordering) * Transparent verification support for alternative (ie uncompressed) payload digest (so deltarpm doesn't need to recompress) * Automatic SSD detection and optimization Rawhide rpm will be updated to 4.16 alpha once feature is approved and updated through beta and rc cycles, 4.16.0 final release is expected before to F33 beta freeze. == Benefit to Fedora == See above for overall benefits, but most importantly this is the first major step towards moving away from Berkeley DB based rpmdb. The database format will not change in this release, but this release enables wider testing of the new backend(s) and related features such as switching from one backend to another. In particular it enables testing of *other software* for compatibility and interoperability with non-BDB databases. The change of database format is not a part of this change. == Scope == * Proposal owners: ** Rebase RPM * Other developers: ** Test new release, report issues and bugs ** Test compatibility of other software with different rpmdb format (containers, build-systems and such in particular) * Release engineering: [https://pagure.io/releng/issue/9286 #9286] * Policies and guidelines: As always, utilizing new rpm features is subject to packaging guidelines, but the time for this is after the new version has properly landed. Guideline updates should not be necessary. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * Similar to compiler updates, some previously working specs might fail to build due to stricter error checking and the like. In particular, barewords (ie non-quoted strings) in expressions are no longer supported. == How To Test == Rpm receives a thorough and constant testing via every single package build, system installs and updates. New features can be tested specifically as per their documentation. The prime testing target should revolve around database functionality, robustness and compatibility with other software. There's a [https://bugzilla.redhat.com/show_bug.cgi?id=1766120 tracking bug] for Berkeley DB format dependencies. Details on database testing to be supplied later. == User Experience == There are no significant user experience changes by default, but a significant increase in overall robustness is expected with non-BDB databases. == Dependencies == * A soname bump is involved so all API-dependent packages will need a rebuild * Rpm will grow an additional dependency on sqlite == Contingency Plan == * Contingency mechanism: Roll back to rpm 4.15, but the chance of having to do should be negligible * Contingency deadline: Beta freeze. * Blocks release? No == Documentation == Draft release notes are available at https://rpm.org/wiki/Releases/4.16.0 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org
Fedora 33 System-Wide Change proposal: Sqlite RpmDB
https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb == Summary == Change format of the RPM database from Berkeley DB to a new Sqlite format. == Owner == * Name: [[User:pmatilai| Panu Matilainen]] [[User:ffesti|Florian Festi]] * Email: pmati...@redhat.com ffe...@redhat.com == Detailed Description == The current rpm database implementation is based on Berkeley DB 5.x, a version which is unmaintained upstream for several years now. Berkeley DB 6.x is license incompatible so moving to that is not an option. In addition, the existing rpmdb implementation is notoriously unreliable as it's not transactional and has no other means to detect inconsistencies either. Changing to a more sustainable database implementation is long overdue. We propose to change the default rpmdb format to the new sqlite based implementation. Support for current BDB format will be retained in Fedora 33, and phased out to read-only support in Fedora 34. == Benefit to Fedora == * A far more robust rpm database implementation * Getting rid of Berkeley DB dependency in one of the core components == Scope == * Proposal owners: ** Once [[Changes/RPM-4.16|RPM 4.16]] lands and passes initial shakedown, change the default rpmdb configuration to sqlite ** Address any bugs and issues in the database backend found by wider testing base ** Help other developers to address Berkeley DB dependencies * Other developers: ** Test for hidden Berkeley DB dependencies in other software, address them as found and needed * Release engineering: [https://pagure.io/releng/issue/9308 #9308] * Policies and guidelines: Policies and guidelines are not affected * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == === Upgrading === * Ability to upgrade is not affected * After upgrade completes, manual action (rpmdb --rebuilddb) will probably be needed to convert to sqlite. Alternatively user can change configuration to stay on BDB. === Compatibility === * Container/chroot use-cases will be affected: older rpm versions will be unable to query/manipulate the rpmdb from outside the chroot * Koji/COPR may need to override the database format (back to) BDB for the time being == How To Test == * Rpmdb gets thoroughly exercised as a matter of normal system operation, performing installs, updates, package builds etc * Of specific interest here is torture testing: forcibly killing rpm in various stages of execution - database should stay consistent and operational (other system state is out of scope) * Test database conversions from one backend to another (rpmdb --rebuilddb --define "_db_backend ") == User Experience == * In normal operation, users should see little or no change * Behavior in error situations is much more robust: forcibly killed transaction no longer causes database inconsistency or corruption == Dependencies == * This change depends on [[Changes/RPM-4.16|RPM 4.16]], support for sqlite rpmdb is not present in older versions * RPM will grow a new dependency on sqlite-libs * Technically the rpmdb format is an internal implementation detail of RPM and the data is only accessible through the librpm API, but some software is making assumptions both about the format and/or in particular, file naming. These are being tracked at https://bugzilla.redhat.com/show_bug.cgi?id=1766120 * Upgrade tooling could/should perform rpmdb rebuild at end, this would be a good thing to do regardless of this change == Contingency Plan == * Contingency mechanism: ** Revert the default database back to Berkeley DB backend in the package. Running 'rpmdb --rebuilddb' on hosts is currently required to actually convert the database, but means to automate conversion in specific conditions is being discussed upstream. ** The rpm-team does not expect problems with the database backend itself, but we are aware that postponing may be needed due to infrastructure or other tooling not being ready, primarily due to inability to access the database from older releases. * Contingency deadline: Beta freeze * Blocks release? Yes == Documentation == * [https://rpm.org/wiki/Releases/4.16.0 | RPM 4.16 release notes] == Release Notes == * After upgrading from an older release, rpm operations will issue warnings about database backend configuration not matching what's on disk. Users should run 'rpmdb --rebuilddb' at earliest opportunity, or change configuration to stay on Berkeley DB backend (eg 'echo %_db_backend bdb > /etc/rpm/macros.db') * The details are subject to change, the database rebuild may be done by upgrade tooling -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@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:
Fedora 33 System-Wide Change proposal: Strong crypto settings: phase 2
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 == Summary == We update the current system-wide crypto policy to further disable legacy cryptographic protocols (TLS 1.0 and TLS 1.1), weak Diffie-Hellman key exchange sizes (1024 bit), and use of the SHA-1 hash in signatures. == Owner == * Name: [[User:tmraz|Tomáš Mráz]] * Email: == Detailed Description == Fedora includes several cryptographic components who's security doesn't remain constant over time. Algorithms such as (cryptographic) hashing and encryption typically have a lifetime after which they are considered either too risky to use or plain insecure. That would mean we need to phase out such algorithms from the default settings, or completely disable if they could cause irreparable issue. While in the past we did not disable algorithms in a consistent way (different applications utilized different policies), today we have a system-wide policy followed by a large part of Fedora components. That allows us to move consistently and deprecate algorithms system-wide. For rationale see RFC 7457 for a more complete list of attacks taking advantage of legacy crypto algorithms. The changes for default policy are: * Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols and move the TLS 1.x, x<=1 to legacy level. * Require finite field parameters (RSA, Diffie-Hellman) of 2048 and more in the default settings * Disable SHA1 support for use in signatures (X.509 certificates, TLS, IPSEC handshakes) That is a policy of: LEGACY MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: SHA-1 hash or better (not RIPEMD) Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES) key exchange: ECDHE, RSA, DHE DH params size: >=1023 RSA params size: >=1023 TLS protocols: TLS >= 1.0 DEFAULT MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: with SHA-256 hash or better (not DSA) Ciphers: >= 128-bit key, >= 128-bit block (aes, chacha20, including aes-cbc) key exchange: ECDHE, RSA, DHE DH params size: >= 2048 RSA params size: >= 2048 TLS protocols: TLS >= 1.2 FUTURE MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: SHA-256 hash or better (not DSA) Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers key exchange: ECDHE, DHE DH params size: >= 3072 RSA params size: >= 3072 TLS protocols: TLS >= 1.2 == Benefit to Fedora == With this change we protect users from relying on enabled-by-default weak cryptography, as well as reduce our maintenance cost for future attacks that rely on weak crypto for exploitation. Also please note that Firefox is also moving to similar default crypto settings with the current releases (Firefox 74) [https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-and-tls-1-1/]. == Scope == * Proposal owners: The policies include in crypto-policies package need to be updated. * Other developers: * Crypto policies are updated to the settings above * Release engineering: Copied from F28 change - no impact [https://pagure.io/releng/issue/7235 #7235] (a check of an impact with Release Engineering is needed) * Crypto policies are updated to the settings above * OpenSSL, NSS, GnuTLS and all applications covered under the Fedora Crypto Policies follow the new crypto settings. * Policies and guidelines: No changes to packaging or other guidelines is needed. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == It may be that the new settings break software that connects to servers which utilize weak algorithms. Compatibility can be obtained by switching the system to legacy policy level as follows. update-crypto-policies --set LEGACY == How To Test == Applications which follow the system-wide policy (e.g., curl,wget) should be tested: * whether they can connect to legacy (TLS1.0, TLS1.1) servers when system is in legacy mode * whether the previous connection breaks when system is in default mode * whether the system can connect to TLS 1.2 servers when in default, legacy or future mode. == User Experience == Given the existing deployment of TLS 1.2 on the internet, there should not be significant user experience degradation, although that's a speculation. == Dependencies == * nss * gnutls * openssl * crypto-policies == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) If we notice significant user experience degradation, e.g., due to many custom servers utilizing legacy protocols, we should consider postponing or reducing the number of updates in that change. The change owner will take care of this. * Contingency deadline: beta freeze * Blocks
Fedora 33 System-Wide Change proposal: MinGW environment and toolchain update
https://fedoraproject.org/wiki/Changes/F33MingwEnvToolchainUpdate == Summary == Update the MinGW base environment and toolchain to the latest upstream stable releases. == Owner == * Name: [[User:smani|Sandro Mani]] * Email: manisan...@gmail.com == Detailed Description == The following packages will be updated * mingw-gcc to version 10.0.0 * mingw-w64-tools to version 7.0.0 * mingw-winpthreads to version 7.0.0 * mingw-crt to version 7.0.0 * mingw-headers to version 7.0.0 * mingw-binutils to version 2.34 * mingw-gdb to version 9.1 == Benefit to Fedora == Ship the latest available MinGW environment and GNU toolchain. == Scope == * Proposal owners: The above mentioned packages will be updated. Build failures following the mass rebuild will be inspected. * Other developers: Help with build failures may be requested. * Release engineering: Impact check [https://pagure.io/releng/issue/9253] * Release engineering: Mass rebuild requested * Policies and guidelines: No policies need to be changed == Upgrade/compatibility impact == No impact == How To Test == Update the system once the updated packages land, look out for new build failures etc. == User Experience == The features of the newest MinGW environment and GNU Toolchain will be available to the users. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert to older versions of environment / toolchain, mass rebuild mingw packages again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No == Release Notes == Fedora 33 comes with the mingw-w64-7.0.0 environment, mingw-gcc-10, mingw-gdb-9.1 and mingw-binutils 2.34. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 33 System-Wide Change proposal: GNU Make version 4.3
https://fedoraproject.org/wiki/Changes/MAKE43 == Summary == Rebase GNU make in Fedora 33 from make version 4.2 to make version 4.3. == Owner == * Name: [[User:djdelorie| DJ Delorie]] * Email: d...@redhat.com == Detailed Description == Make 4.3 was released on January 19th 2020. It includes many bug fixes and new features. Fedora has been carrying many patches to the 4.2 release which are included in 4.3, reducing the workload for Fedora builders. Note that Fedora is also carrying some patches to retain compatibility with make version 3.8, as an aid to packages which needed time to adapt to make version 4. These compatibility patches will be removed in this rebase, making Fedora's make the same as other distros. Some packages may FTBFS and need help tweaking their Makefiles. == Benefit to Fedora == Stay up to date with upstream GNU make, make sure we have the latest bug fixes et al, be compatible with stock GNU make. == Scope == * Proposal owners: Update to GNU make 4.3 * Other developers: Package owners relying on makefile features specific to older versions of GNU make (including compatibility patches for 3.8 we're dropping) may FTBFS and need to tweak their Makefiles. * Release engineering: (a check of an impact with Release Engineering is pending) * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Users who have local projects using GNU make, which rely on features only available in older versions of GNU make, may need to tweak their Makefiles before rebuilding. Packages which were built previous to this upgrade will not be affected. Specific backwards incompatibilities as called out in the NEWS file for make 4.3: * WARNING: Backward-incompatibility! Number signs (#) appearing inside a macro reference or function invocation no longer introduce comments and should not be escaped with backslashes: thus a call such as: foo := $(shell echo '#') is legal. Previously the number sign needed to be escaped, for example: foo := $(shell echo '\#') Now this latter will resolve to "\#". If you want to write makefiles portable to both versions, assign the number sign to a variable: H := \# foo := $(shell echo '$H') This was claimed to be fixed in 3.81, but wasn't, for some reason. To detect this change search for 'nocomment' in the .FEATURES variable. * WARNING: Backward-incompatibility! Previously appending using '+=' to an empty variable would result in a value starting with a space. Now the initial space is only added if the variable already contains some value. Similarly, appending an empty string does not add a trailing space. == How To Test == GNU make has its own testsuite and does not require specific hardware or testing outside of building the RPM. == User Experience == Users will get all bugfixes included in make 4.3 as well as any new features therein. The make 4.3 NEWS update will include more details. == Dependencies == No dependencies. == Contingency Plan == * Contingency mechanism: Revert to make 4.2.1 * Contingency deadline: Beta freeze. If there is a mass rebuild, preferably before then. * Blocks release? No == Documentation == GNU Make includes its own documentation. No additional documentation work is required. == Release Notes == Full release notes can be found in make's NEWS file: http://git.savannah.gnu.org/cgit/make.git/tree/NEWS -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 33 System-Wide Change proposal: RPM 4.16
https://fedoraproject.org/wiki/Changes/RPM-4.16 == Summary == Update RPM to the 4.16.0 release. == Owner == * Name: User:pmatilai, User:ffesti * Email: pmati...@redhat.com,ffe...@redhat.com == Detailed Description == RPM 4.16 contains numerous improvements over previous versions * New database backends and related developments to enable moving away from Berkeley DB ** experimental sqlite backend ** experimental readonly-bdb backend to support conversion from BDB without the library ** ndb backend promoted out of experimental * Much improved expression parser (specs and macros) * Powerful new macro features (expressions, ternary operator, literal macros, access to macro body, eliminate unexpected double-expansion etc) * Support for macro-only dependency generators (very fast as fork+exec is entirely avoided) * Support for meta dependencies (which do not affect ordering) * Transparent verification support for alternative (ie uncompressed) payload digest (so deltarpm doesn't need to recompress) * Automatic SSD detection and optimization Rawhide rpm will be updated to 4.16 alpha once feature is approved and updated through beta and rc cycles, 4.16.0 final release is expected before to F33 beta freeze. == Benefit to Fedora == See above for overall benefits, but most importantly this is the first major step towards moving away from Berkeley DB based rpmdb. The database format will not change in this release, but this release enables wider testing of the new backend(s) and related features such as switching from one backend to another. In particular it enables testing of *other software* for compatibility and interoperability with non-BDB databases. The change of database format is not a part of this change. == Scope == * Proposal owners: ** Rebase RPM * Other developers: ** Test new release, report issues and bugs ** Test compatibility of other software with different rpmdb format (containers, build-systems and such in particular) * Release engineering: [https://pagure.io/releng/issue/9286 #9286] * Policies and guidelines: As always, utilizing new rpm features is subject to packaging guidelines, but the time for this is after the new version has properly landed. Guideline updates should not be necessary. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * Similar to compiler updates, some previously working specs might fail to build due to stricter error checking and the like. In particular, barewords (ie non-quoted strings) in expressions are no longer supported. == How To Test == Rpm receives a thorough and constant testing via every single package build, system installs and updates. New features can be tested specifically as per their documentation. The prime testing target should revolve around database functionality, robustness and compatibility with other software. There's a [https://bugzilla.redhat.com/show_bug.cgi?id=1766120 tracking bug] for Berkeley DB format dependencies. Details on database testing to be supplied later. == User Experience == There are no significant user experience changes by default, but a significant increase in overall robustness is expected with non-BDB databases. == Dependencies == * A soname bump is involved so all API-dependent packages will need a rebuild * Rpm will grow an additional dependency on sqlite == Contingency Plan == * Contingency mechanism: Roll back to rpm 4.15, but the chance of having to do should be negligible * Contingency deadline: Beta freeze. * Blocks release? No == Documentation == Draft release notes are available at https://rpm.org/wiki/Releases/4.16.0 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 33 System-Wide Change proposal: Sqlite RpmDB
https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb == Summary == Change format of the RPM database from Berkeley DB to a new Sqlite format. == Owner == * Name: [[User:pmatilai| Panu Matilainen]] [[User:ffesti|Florian Festi]] * Email: pmati...@redhat.com ffe...@redhat.com == Detailed Description == The current rpm database implementation is based on Berkeley DB 5.x, a version which is unmaintained upstream for several years now. Berkeley DB 6.x is license incompatible so moving to that is not an option. In addition, the existing rpmdb implementation is notoriously unreliable as it's not transactional and has no other means to detect inconsistencies either. Changing to a more sustainable database implementation is long overdue. We propose to change the default rpmdb format to the new sqlite based implementation. Support for current BDB format will be retained in Fedora 33, and phased out to read-only support in Fedora 34. == Benefit to Fedora == * A far more robust rpm database implementation * Getting rid of Berkeley DB dependency in one of the core components == Scope == * Proposal owners: ** Once [[Changes/RPM-4.16|RPM 4.16]] lands and passes initial shakedown, change the default rpmdb configuration to sqlite ** Address any bugs and issues in the database backend found by wider testing base ** Help other developers to address Berkeley DB dependencies * Other developers: ** Test for hidden Berkeley DB dependencies in other software, address them as found and needed * Release engineering: [https://pagure.io/releng/issue/9308 #9308] * Policies and guidelines: Policies and guidelines are not affected * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == === Upgrading === * Ability to upgrade is not affected * After upgrade completes, manual action (rpmdb --rebuilddb) will probably be needed to convert to sqlite. Alternatively user can change configuration to stay on BDB. === Compatibility === * Container/chroot use-cases will be affected: older rpm versions will be unable to query/manipulate the rpmdb from outside the chroot * Koji/COPR may need to override the database format (back to) BDB for the time being == How To Test == * Rpmdb gets thoroughly exercised as a matter of normal system operation, performing installs, updates, package builds etc * Of specific interest here is torture testing: forcibly killing rpm in various stages of execution - database should stay consistent and operational (other system state is out of scope) * Test database conversions from one backend to another (rpmdb --rebuilddb --define "_db_backend ") == User Experience == * In normal operation, users should see little or no change * Behavior in error situations is much more robust: forcibly killed transaction no longer causes database inconsistency or corruption == Dependencies == * This change depends on [[Changes/RPM-4.16|RPM 4.16]], support for sqlite rpmdb is not present in older versions * RPM will grow a new dependency on sqlite-libs * Technically the rpmdb format is an internal implementation detail of RPM and the data is only accessible through the librpm API, but some software is making assumptions both about the format and/or in particular, file naming. These are being tracked at https://bugzilla.redhat.com/show_bug.cgi?id=1766120 * Upgrade tooling could/should perform rpmdb rebuild at end, this would be a good thing to do regardless of this change == Contingency Plan == * Contingency mechanism: ** Revert the default database back to Berkeley DB backend in the package. Running 'rpmdb --rebuilddb' on hosts is currently required to actually convert the database, but means to automate conversion in specific conditions is being discussed upstream. ** The rpm-team does not expect problems with the database backend itself, but we are aware that postponing may be needed due to infrastructure or other tooling not being ready, primarily due to inability to access the database from older releases. * Contingency deadline: Beta freeze * Blocks release? Yes == Documentation == * [https://rpm.org/wiki/Releases/4.16.0 | RPM 4.16 release notes] == Release Notes == * After upgrading from an older release, rpm operations will issue warnings about database backend configuration not matching what's on disk. Users should run 'rpmdb --rebuilddb' at earliest opportunity, or change configuration to stay on Berkeley DB backend (eg 'echo %_db_backend bdb > /etc/rpm/macros.db') * The details are subject to change, the database rebuild may be done by upgrade tooling -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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:
Fedora 33 System-Wide Change proposal: Strong crypto settings: phase 2
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 == Summary == We update the current system-wide crypto policy to further disable legacy cryptographic protocols (TLS 1.0 and TLS 1.1), weak Diffie-Hellman key exchange sizes (1024 bit), and use of the SHA-1 hash in signatures. == Owner == * Name: [[User:tmraz|Tomáš Mráz]] * Email: == Detailed Description == Fedora includes several cryptographic components who's security doesn't remain constant over time. Algorithms such as (cryptographic) hashing and encryption typically have a lifetime after which they are considered either too risky to use or plain insecure. That would mean we need to phase out such algorithms from the default settings, or completely disable if they could cause irreparable issue. While in the past we did not disable algorithms in a consistent way (different applications utilized different policies), today we have a system-wide policy followed by a large part of Fedora components. That allows us to move consistently and deprecate algorithms system-wide. For rationale see RFC 7457 for a more complete list of attacks taking advantage of legacy crypto algorithms. The changes for default policy are: * Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols and move the TLS 1.x, x<=1 to legacy level. * Require finite field parameters (RSA, Diffie-Hellman) of 2048 and more in the default settings * Disable SHA1 support for use in signatures (X.509 certificates, TLS, IPSEC handshakes) That is a policy of: LEGACY MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: SHA-1 hash or better (not RIPEMD) Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES) key exchange: ECDHE, RSA, DHE DH params size: >=1023 RSA params size: >=1023 TLS protocols: TLS >= 1.0 DEFAULT MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: with SHA-256 hash or better (not DSA) Ciphers: >= 128-bit key, >= 128-bit block (aes, chacha20, including aes-cbc) key exchange: ECDHE, RSA, DHE DH params size: >= 2048 RSA params size: >= 2048 TLS protocols: TLS >= 1.2 FUTURE MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: SHA-256 hash or better (not DSA) Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers key exchange: ECDHE, DHE DH params size: >= 3072 RSA params size: >= 3072 TLS protocols: TLS >= 1.2 == Benefit to Fedora == With this change we protect users from relying on enabled-by-default weak cryptography, as well as reduce our maintenance cost for future attacks that rely on weak crypto for exploitation. Also please note that Firefox is also moving to similar default crypto settings with the current releases (Firefox 74) [https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-and-tls-1-1/]. == Scope == * Proposal owners: The policies include in crypto-policies package need to be updated. * Other developers: * Crypto policies are updated to the settings above * Release engineering: Copied from F28 change - no impact [https://pagure.io/releng/issue/7235 #7235] (a check of an impact with Release Engineering is needed) * Crypto policies are updated to the settings above * OpenSSL, NSS, GnuTLS and all applications covered under the Fedora Crypto Policies follow the new crypto settings. * Policies and guidelines: No changes to packaging or other guidelines is needed. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == It may be that the new settings break software that connects to servers which utilize weak algorithms. Compatibility can be obtained by switching the system to legacy policy level as follows. update-crypto-policies --set LEGACY == How To Test == Applications which follow the system-wide policy (e.g., curl,wget) should be tested: * whether they can connect to legacy (TLS1.0, TLS1.1) servers when system is in legacy mode * whether the previous connection breaks when system is in default mode * whether the system can connect to TLS 1.2 servers when in default, legacy or future mode. == User Experience == Given the existing deployment of TLS 1.2 on the internet, there should not be significant user experience degradation, although that's a speculation. == Dependencies == * nss * gnutls * openssl * crypto-policies == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) If we notice significant user experience degradation, e.g., due to many custom servers utilizing legacy protocols, we should consider postponing or reducing the number of updates in that change. The change owner will take care of this. * Contingency deadline: beta freeze * Blocks
[Bug 1813603] perl-Module-CoreList-5.20200314 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813603 --- Comment #5 from Fedora Update System --- perl-Module-CoreList-5.20200314-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-419e3082ee -- 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
[Bug 1813602] perl-CPAN-Perl-Releases-5.20200314 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813602 --- Comment #5 from Fedora Update System --- perl-CPAN-Perl-Releases-5.20200314-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0b03b12929 -- 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
[Bug 1813603] perl-Module-CoreList-5.20200314 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813603 --- Comment #4 from Fedora Update System --- perl-Module-CoreList-5.20200314-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-47f1b57e23 -- 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
[Bug 1813602] perl-CPAN-Perl-Releases-5.20200314 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813602 --- Comment #4 from Fedora Update System --- perl-CPAN-Perl-Releases-5.20200314-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-cf95f89bd2 -- 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
Embedded font support for PDFs is lacking; response to: Fonts packaging guidelines change status
Subject: Fonts packaging guidelines change status On Sat, 7 Mar 2020, Nicolas Mailhot wrote: > WHAT IS IT ALL ABOUT > > On 2020-02-13, FPC approved a rewrite of our fonts packaging > guidelines. and again that was published on the 14th removing some top matter through the Section mark: NEW PACKAGES STILL PENDING REVIEW, and advancing PR status on a couple of fonts But this question in the fonts-list was not addressed (see the bottom of this resend to include the devel list): Is a formal 'bug' needed to track this ? Background: That re-write draft as included does not address PDF portability The Fedora most recent prior approach on fonts neglected explicitly supporting the need of Latex chain created documents for type 1 fonts to be embedded in PDFs. From raising this issue previously, it is my understanding that Type 1 fonts are felt to not screen render as well as some later alternatives, but when it comes to generating a Portable Document to reliably render 'the same', one HAS to carry and prefer embedded fonts when present Detection of the issue, and Problem summarized: When one is missing fonts, and runs something like: dvips -t letter -Ppdf -G0 -j0 mypaper.dvi \ -o mypaper.ps one will get a 'missfont.log' as to an inability to embed a required font, 'required' for completeness for portability purposes See the discussion at: https://helpx.adobe.com/acrobat/using/pdf-fonts.html and its practical implication is discussed at: https://blogs.adobe.com/acrolaw/2007/11/pdf_creation_and_font_embedding/ The TL;DR takeaway is: The USPTO requires that PDF must be: Acrobat 4 (PDF 1.3) or higher (See note at end of article) No larger than 8.5? by 11? or A4 page size Have all fonts embedded and subset It is not JUST preparation of documents for filing there, but also for submitting 'camera ready PDF copy' to Lulu print on demand. Lulu is a child of Robert Young [a serial entrepreneur who is best known for founding Red Hat Inc] https://connect.lulu.com/en/discussion/33148 https://connect.lulu.com/en/discussion/33681/pdf-creation-settings-how-can-i-be-sure-my-pdf-will-print-correctly pull requirement: All fonts should be converted to outlines and embedded Way forward: There is a collection of 13 fonts provided under a freely reproducible license from Adobe, known as the Base 13 fonts - Courier, Courier-Bold, Courier-Oblique & Courier-BoldOblique - Times-Roman , Times-Bold , Times-Italic & Times-BoldItalic - Helvetica, Helvetica-Bold, Helvetica-Oblique & Helvetica-BoldOblique - Symbol [ but not: - ZapfDingbats ] I understand that they were removed from Fedora, as the Base 13 are Type 1 fonts but dang it, at least for purposes of completeness to be able to generate legal documents, and to permit me to continue to use FOSS tools to publish for fulfillment at Lulu, can we get these Type 1 fonts back, regardless of slight risk of aesthetic discontent ? Is a formal 'bug' needed to track this ? Thank you -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 32 compose report: 20200316.n.0 changes
OLD: Fedora-32-20200315.n.0 NEW: Fedora-32-20200316.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-32-20200316.n.0.ppc64le.tar.xz = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ 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
[Bug 1813720] perl-Pod-Usage-1.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813720 --- Comment #3 from Fedora Update System --- FEDORA-2020-0acf97c1e1 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0acf97c1e1 -- 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
[Bug 1813720] perl-Pod-Usage-1.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813720 --- Comment #2 from Fedora Update System --- FEDORA-2020-d708f52a27 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d708f52a27 -- 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
[Bug 1813602] perl-CPAN-Perl-Releases-5.20200314 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813602 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-CPAN-Perl-Releases-5.20200314-1.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-cf6dc15b96 -- 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
[Bug 1813603] perl-Module-CoreList-5.20200314 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813603 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-Module-CoreList-5.20200314-1.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-fe90fd7233 -- 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
[Bug 1813720] perl-Pod-Usage-1.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813720 Petr Pisar changed: What|Removed |Added Status|NEW |MODIFIED CC|ppi...@redhat.com | Fixed In Version||perl-Pod-Usage-1.70-1.fc33 Doc Type|--- |If docs needed, set a value --- Comment #1 from Petr Pisar --- A bug-fix release suitable for all Fedoras. -- 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
tipcutils license change
Hello, I'm working on update of tipcutils from 2.2.0 to 3.0.4. This will bring a license change: GPLv2 was dropped upstream, BDS license remains. Sincerely Peter -- Peter Hanecak http://hany.sk/~hany/ GnuPG: http://hany.sk/~hany/gpg/475DFC4C.txt signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: LWT 5.1.2? (was: Re: OCaml 4.10.0 build in Fedora 32 and 33)
On Tue, Feb 25, 2020 at 12:22:10PM -0800, Michel Alexandre Salim wrote: > > On February 25, 2020 3:38 AM Richard W.M. Jones wrote: > > > > > > In the previous mass build LWT FTBFS because the tests failed on POWER > > and s/390 (https://bugzilla.redhat.com/1792780). There is also a new > > version of LWT (https://bugzilla.redhat.com/1755859). The new version > > is noted as an API break, although I don't know how that will affect > > other packages. > > > > Anyway I did manage to update LWT to 5.1.2, fix a few things, and do a > > scratch build. The tests even pass on all arches: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=41885170 > > > Sounds great. I'd say push this for Rawhide and FC32, and maybe update FC31 > later if necessary? I have a feeling that I may have pushed this change by accident when I was doing the OCaml 4.10.0 final build. Anyway, hopefully everything is now fine! If you find any problems related to this then let me know and I'll try and fix it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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
[Bug 1813676] perl-Prima-1.58 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813676 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Prima-1.58-1.fc33 Resolution|--- |RAWHIDE Last Closed||2020-03-16 13:27:39 --- Comment #1 from Petr Pisar --- Many new features. Safer for Rawhide only. -- 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
[Bug 1004354] perl-Alien-ROOT not available on ARM because root is not there
https://bugzilla.redhat.com/show_bug.cgi?id=1004354 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Alien-ROOT-5.34.36.1-1 ||9.fc33 --- Comment #11 from Petr Pisar --- Thank you for the notification. -- 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
[Bug 1813653] perl-TeX-Encode-2.008 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1813653 Tom "spot" Callaway changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-03-16 12:58:58 --- Comment #3 from Tom "spot" Callaway --- In rawhide. -- 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
Fedora-IoT-33-20200316.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 2/8 (x86_64) Old failures (same test failed in Fedora-IoT-33-20200313.0): ID: 546772 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/546772 ID: 546773 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/546773 Skipped non-gating openQA tests: 6 of 8 -- 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