Re: Announcing start of DNF 5 development
On Thu, Mar 5, 2020 at 8:30 AM Daniel Mach wrote: > > > > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a): > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > wrote: > >> Are you going to use sd-bus for the dbus library? > >> > > > > I'd hope not, given that we have cross-distro usage of DNF now, and a > > couple of them don't have systemd. > > > Do you know which distros do not have systemd? > > We have evaluated sd-bus to be the best dbus client available, but we > may have underestimated it's adoption. > > Couldn't systemd team split it into a separate library independent on > the rest of the systemd eco-system? :) Is varlink applicable here? I mention it because I've come across it being used by systemd-homed. It's intended to be available during early boot. -- 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
Fedora-Rawhide-20200309.n.1 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 17 of 43 required tests failed, 9 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 78/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200307.n.1): ID: 541117 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/541117 ID: 541118 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/541118 Old failures (same test failed in Fedora-Rawhide-20200307.n.1): ID: 537391 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/537391 ID: 537392 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/537392 ID: 537394 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/537394 ID: 537396 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/537396 ID: 537397 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/537397 ID: 537398 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/537398 ID: 537399 Test: x86_64 Server-dvd-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/537399 ID: 537431 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/537431 ID: 537432 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/537432 ID: 537433 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/537433 ID: 537434 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/537434 ID: 537470 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/537470 ID: 537472 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/537472 ID: 537473 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/537473 ID: 537484 Test: x86_64 universal install_no_swap URL: https://openqa.fedoraproject.org/tests/537484 ID: 537485 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/537485 ID: 537486 Test: x86_64 universal install_sata **GATING** URL: https://openqa.fedoraproject.org/tests/537486 ID: 537487 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/537487 ID: 537488 Test: x86_64 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/537488 ID: 537489 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/537489 ID: 537491 Test: x86_64 universal install_scsi_updates_img **GATING** URL: https://openqa.fedoraproject.org/tests/537491 ID: 537493 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/537493 ID: 537494 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/537494 ID: 537495 Test: x86_64 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/537495 ID: 537496 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/537496 ID: 537497 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/537497 ID: 537498 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/537498 ID: 537499 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/537499 ID: 537500 Test: x86_64 universal install_mirrorlist_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/537500 ID: 537504 Test: x86_64 universal install_multi **GATING** URL: https://openqa.fedoraproject.org/tests/537504 ID: 537505 Test: x86_64 universal install_repository_http_variation **GATING** URL: https://openqa.fedoraproject.org/tests/537505 ID: 537507 Test: x86_64 universal install_delete_pata@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/537507 ID: 537508 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/537508 ID: 537509 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/537509 ID: 537510 Test: x86_64 universal install_anaconda_text **GATING** URL: https://openqa.fedoraproject.org/tests/537510 ID: 537511 Test: x86_64 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/537511 ID: 537512 Test: x86_64 universal install_blivet_btrfs URL:
[389-devel] 389 DS nightly 2020-03-12 - 97% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/03/12/report-389-ds-base-1.4.3.3-20200312gitad8b926.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
Schedule for Thursday's FPC Meeting (2020-03-12 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2020-03-12 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2020-03-12 09:00 PDT US/Pacific 2020-03-12 12:00 EDT --> US/Eastern <-- 2020-03-12 16:00 GMT Europe/London 2020-03-12 16:00 UTC UTC 2020-03-12 17:00 CET Europe/Berlin 2020-03-12 17:00 CET Europe/Paris 2020-03-12 21:30 IST Asia/Calcutta New Day: Friday - 2020-03-13 00:00 HKT Asia/Hong_Kong 2020-03-13 00:00 +08 Asia/Singapore 2020-03-13 01:00 JST Asia/Tokyo 2020-03-13 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting = Followups = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 = Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines https://pagure.io/packaging-committee/pull-request/814 #topic #pr-938 Add Package Review Process page https://pagure.io/packaging-committee/pull-request/938 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-IoT-32-20200311.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Soft failed openQA tests: 2/8 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-32-20200310.0): ID: 542281 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/542281 ID: 542282 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/542282 Passed openQA tests: 6/8 (x86_64) New passes (same test not passed in Fedora-IoT-32-20200310.0): ID: 542283 Test: x86_64 IoT-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/542283 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20200311.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed, 1 result missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 17/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200309.n.1): ID: 540818 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/540818 ID: 540826 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/540826 ID: 540832 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/540832 ID: 540837 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/540837 ID: 540839 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/540839 ID: 540842 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/540842 ID: 540843 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/540843 ID: 540895 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/540895 ID: 540962 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/540962 Old failures (same test failed in Fedora-Rawhide-20200309.n.1): ID: 540852 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/540852 ID: 540869 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/540869 ID: 540883 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/540883 ID: 540907 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/540907 ID: 540912 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/540912 ID: 540929 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/540929 ID: 540969 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/540969 ID: 540975 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/540975 ID: 540976 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/540976 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-20200309.n.1): ID: 540804 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/540804 ID: 540805 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/540805 ID: 540807 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/540807 ID: 540809 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/540809 ID: 540812 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/540812 ID: 540813 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/540813 ID: 540833 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/540833 ID: 540905 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/540905 ID: 540923 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/540923 Old soft failures (same test soft failed in Fedora-Rawhide-20200309.n.1): ID: 540862 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/540862 ID: 540864 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/540864 ID: 540896 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/540896 ID: 540958 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/540958 ID: 540961 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/540961 ID: 540968 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/540968 Passed openQA tests: 139/171 (x86_64) New passes (same test not passed in Fedora-Rawhide-20200309.n.1): ID: 540806 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/540806 ID: 540810 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/540810 ID: 540811 Test: x86_64 Server-dvd-iso
[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 ||31 --- Comment #7 from Fedora Update System --- perl-String-Print-0.94-1.fc31 has been pushed to the Fedora 31 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 1805545] perl-CPAN-Perl-Releases-5.20200220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1805545 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0200220-1.fc33 |0200220-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 ||0200229-1.fc31 --- Comment #14 from Fedora Update System --- perl-CPAN-Perl-Releases-5.20200229-1.fc31 has been pushed to the Fedora 31 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 ||0200229-1.fc31 --- Comment #7 from Fedora Update System --- perl-CPAN-Perl-Releases-5.20200229-1.fc31 has been pushed to the Fedora 31 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 ||c31 --- Comment #9 from Fedora Update System --- perl-List-AllUtils-0.16-1.fc31 has been pushed to the Fedora 31 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 Status|ON_QA |CLOSED 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 ||30 Resolution|--- |ERRATA Last Closed||2020-03-11 22:25:03 --- Comment #6 from Fedora Update System --- perl-String-Print-0.94-1.fc30 has been pushed to the Fedora 30 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 Status|ON_QA |CLOSED 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 ||c30 Resolution|--- |ERRATA Last Closed||2020-03-11 22:25:02 --- Comment #8 from Fedora Update System --- perl-List-AllUtils-0.16-1.fc30 has been pushed to the Fedora 30 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
Fedora rawhide compose report: 20200311.n.0 changes
OLD: Fedora-Rawhide-20200309.n.1 NEW: Fedora-Rawhide-20200311.n.0 = SUMMARY = Added images:0 Dropped images: 13 Added packages: 34 Dropped packages:2 Upgraded packages: 261 Downgraded packages: 2 Size of added packages: 303.16 MiB Size of dropped packages:140.60 KiB Size of upgraded packages: 5.56 GiB Size of downgraded packages: 6.99 MiB Size change of upgraded packages: 203.65 MiB Size change of downgraded packages: 4.20 KiB = ADDED IMAGES = = DROPPED IMAGES = Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20200309.n.1-sda.raw.xz Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20200309.n.1.iso Image: Server raw-xz aarch64 Path: Server/aarch64/images/Fedora-Server-Rawhide-20200309.n.1.aarch64.raw.xz Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20200309.n.1.iso Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20200309.n.1.aarch64.raw.xz Image: SoaS raw-xz armhfp Path: Spins/armhfp/images/Fedora-SoaS-armhfp-Rawhide-20200309.n.1-sda.raw.xz Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20200309.n.1.iso Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20200309.n.1.iso Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20200309.n.1.iso Image: Workstation raw-xz armhfp Path: Workstation/armhfp/images/Fedora-Workstation-armhfp-Rawhide-20200309.n.1-sda.raw.xz Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20200309.n.1.iso Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20200309.n.1.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20200309.n.1.iso = ADDED PACKAGES = Package: directory-maven-plugin-0.3.1-1.module_f33+7821+c2c8f5c9 Summary: Establish locations for files in multi-module builds RPMs:directory-maven-plugin directory-maven-plugin-javadoc Size:53.88 KiB Package: dsp-1.6-1.fc33 Summary: An audio processing program with an interactive mode RPMs:dsp ladspa-dsp-plugin Size:792.59 KiB Package: ee4j-parent-1.0.1-1.module_f33+7821+c2c8f5c9 Summary: Parent POM file for Eclipse Enterprise for Java projects RPMs:ee4j-parent Size:10.31 KiB Package: jaf-1.2.1-3.module_f33+7821+c2c8f5c9 Summary: JavaBeans Activation Framework RPMs:jaf jaf-javadoc Size:149.62 KiB Package: javamail-1.6.3-4.module_f33+7821+c2c8f5c9 Summary: Java Mail API RPMs:javamail Size:676.45 KiB Package: jericho-html-3.3-16.fc33 Summary: Java library allowing analysis and manipulation of parts of an HTML document RPMs:jericho-html jericho-html-javadoc Size:468.93 KiB Package: jmc-7.1.0-1.module_f33+7821+c2c8f5c9 Summary: JDK Mission Control is a profiling and diagnostics tool RPMs:jmc Size:214.87 MiB Package: jmc-core-7.1.0-1.module_f33+7821+c2c8f5c9 Summary: Core API for JDK Mission Control RPMs:jmc-core jmc-core-javadoc Size:2.15 MiB Package: libretro-gw-0-1.20200213git819b1dd.fc33 Summary: Libretro core for Game & Watch simulators RPMs:libretro-gw Size:967.01 KiB Package: ocaml-lablgtk3-3.1.0-2.fc33 Summary: OCaml interface to gtk3 RPMs:ocaml-lablgtk3 ocaml-lablgtk3-devel ocaml-lablgtk3-doc ocaml-lablgtk3-gtkspell3 ocaml-lablgtk3-gtkspell3-devel ocaml-lablgtk3-sourceview3 ocaml-lablgtk3-sourceview3-devel Size:77.17 MiB Package: opae-1.4.0-6.fc33 Summary: Open Programmable Acceleration Engine (OPAE) SDK RPMs:opae opae-devel Size:589.19 KiB Package: owasp-java-encoder-1.2.2-2.module_f33+7821+c2c8f5c9 Summary: Collection of high-performance low-overhead contextual encoders RPMs:owasp-java-encoder owasp-java-encoder-javadoc Size:110.79 KiB Package: php-phpdocumentor-reflection-docblock5-5.1.0-1.fc33 Summary: DocBlock parser RPMs:php-phpdocumentor-reflection-docblock5 Size:35.58 KiB Package: php-phpmyadmin-motranslator5-5.0.0-1.fc33 Summary: Translation API for PHP using Gettext MO files RPMs:php-phpmyadmin-motranslator5 Size:25.51 KiB Package: php-phpmyadmin-twig-i18n-extension-2.0.0-1.fc33 Summary: Internationalization support for Twig via the gettext library RPMs:php-phpmyadmin-twig-i18n-extension Size:13.99 KiB Package: php-phpunit-php-code-coverage8-8.0.1-1.fc33 Summary: PHP code coverage information RPMs:php-phpunit-php-code-coverage8 Size:202.67 KiB Package: php-sebastian-comparator4-4.0.0-1.fc33 Summary: Compare PHP values for equality RPMs:php-sebastian-comparator4 Size:17.04 KiB Package: php-sebastian-exporter4-4.0.0-1.fc33 Summary: Export PHP variables for visualization RPMs:php-sebastian-exporter4 Size:12.87 KiB Package: php-sebastian-global-state4-4.0.0-1.fc33 Summary: Snapshotting of global state RPMs:php-sebastian-global-state4
[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL
On Wed, Mar 11, 2020 at 8:10 AM Petr Pisar wrote: > > On Wed, Mar 11, 2020 at 06:52:12AM -0700, Troy Dawson wrote: > > On Wed, Mar 11, 2020 at 1:25 AM Petr Pisar wrote: > > > > > > But that leads me to a question about -devel modules. RHEL delivers some > > > -devel modules in a CRB repository. These -devel modules consists of the > > > filtered packages. Is EPEL going to mimic these -devel modules, or not? > > > > > > > Can you give an example of a -devel package in CRB that is from a > > package that is filtered from a module? > > RHEL-8.1.1: > > # dnf module list | grep -e -devel > mariadb-devel10.3 > MariaDB Module > virt-devel rhel > Virtualization module > virt-devel rhel > Virtualization module > > E.g. virt-devel:rhel:8010020190916153839 contains > qemu-kvm-tests-15:2.12.0-88.module+el8.1.0+4233+bc44be3f.x86_64 package. > > RHEL-8.2 Beta brings python38-devel:3.8 module. > Thank you for the examples. I hadn't thought of them. I am going to paste what I proposed, so I can see it right below the examples to see if it still works or not with them. In EPEL 8 or later, it is permitted to have module streams which contain packages with alternate versions to those provided in RHEL. These packages may be newer, built with different options, or even older to serve compatibility needs. These MUST NOT be the default stream -- in every case, explicit user action must be required to opt in to these versions. If the RHEL package is in a RHEL module, then the EPEL module must have the same name as the RHEL module. Any exceptions to the module name must be approved by the EPEL Steering Committee. With all of your examples, the main package is in a RHEL module. As such, the main package would need to be in an EPEL module if it is in EPEL, and would have to follow the EPEL module rules. So, I think they should be ok to be in an EPEL module. A) For the main package (ex: mariadb) that is in a RHEL module, we have stated that we can have an EPEL module, but it must not be default, and it must have the same name as the mariadb module. B) For the -devel packages (ex: mariadb-devel), it would need to be in a module, because we would be having an alternative version of a package provided by RHEL. And it would be in a module, in our examples case, the mariadb module. So, I believe the proposal above, covers this case. If someone created a module, such as mariadb, that has a -devel in CRB, it would be permitted. Troy ___ 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-32-20200310.n.0 compose check report
No missing expected images. Failed openQA tests: 9/171 (x86_64), 1/2 (arm) Old failures (same test failed in Fedora-32-20200309.n.0): ID: 538025 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/538025 ID: 538051 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/538051 ID: 538068 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/538068 ID: 538075 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/538075 ID: 538082 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/538082 ID: 538094 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/538094 ID: 538111 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/538111 ID: 538161 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/538161 ID: 538169 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/538169 ID: 538174 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/538174 Soft failed openQA tests: 19/171 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-32-20200309.n.0): ID: 538078 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/538078 Old soft failures (same test soft failed in Fedora-32-20200309.n.0): ID: 538003 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/538003 ID: 538004 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/538004 ID: 538006 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/538006 ID: 538008 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/538008 ID: 538011 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/538011 ID: 538012 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/538012 ID: 538032 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/538032 ID: 538041 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/538041 ID: 538061 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/538061 ID: 538063 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/538063 ID: 538095 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/538095 ID: 538104 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/538104 ID: 538122 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/538122 ID: 538157 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/538157 ID: 538160 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/538160 ID: 538167 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/538167 ID: 538168 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/538168 ID: 538175 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/538175 Passed openQA tests: 143/171 (x86_64) New passes (same test not passed in Fedora-32-20200309.n.0): ID: 538046 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/538046 ID: 538058 Test: x86_64 Workstation-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/538058 ID: 538059 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/538059 ID: 538091 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background URL: https://openqa.fedoraproject.org/tests/538091 ID: 538120 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/538120 ID: 538121 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/538121 ID: 538133 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/538133 ID: 538136 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/538136 ID: 538155 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/538155 ID: 538163 Test: x86_64 universal
Orphaned packages looking for new maintainers (incl. libxslt with 293 dependents)
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-09.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change aalto-xml java-sig, orphan 1 weeks ago apache-commons-jexl mizdebsk, orphan 3 weeks ago appframework orphan 3 weeks ago bean-validation-api orphan 3 weeks ago bindexorphan 3 weeks ago clang7.0 orphan, sergesanspaille, 4 weeks ago tstellar clang8.0 orphan, sergesanspaille, 3 weeks ago tstellar compress-lzf 0 weeks ago cpptasks orphan 0 weeks ago cuneiform orphan 3 weeks ago disruptor-thrift-server orphan 1 weeks ago dspam gnat, orphan 2 weeks ago dump jridky, orphan, vdolezal 3 weeks ago erlang-fs orphan 2 weeks ago felix-scr-maven-pluginjerboaa, jkang, orphan 4 weeks ago fluid-soundfont kvolny, orphan 0 weeks ago fluxcapacitor orphan, suve 2 weeks ago freemarkerorphan 3 weeks ago geronimo-jta mizdebsk, orphan 3 weeks ago glade3dridi, nonamedotc, orphan, 1 weeks ago rakesh gnome-shell-extension-orphan 3 weeks ago taskwarrior hexter-dssi orphan 0 weeks ago hibernate lef, odubaj, orphan 5 weeks ago ini4j orphan 5 weeks ago jacocojvanek, kdaniel, lef, orphan 2 weeks ago javapoet orphan 1 weeks ago jboss-marshalling mizdebsk, orphan 1 weeks ago jetty-alpn-apimizdebsk, orphan 1 weeks ago jetty-build-support mizdebsk, orphan 0 weeks ago jmol jussilehtola, orphan 3 weeks ago js-jquery-jstree orphan 2 weeks ago js-jquery-notyorphan 2 weeks ago jspecview jussilehtola, orphan 3 weeks ago jsr-311 mizdebsk, orphan 3 weeks ago laszipdevrim, orphan 0 weeks ago libdivecomputer-subsurfaceorphan, rdieter 2 weeks ago liblasdevrim, orphan 0 weeks ago libxslt devrim, jjelen, orphan, 0 weeks ago veillard llvm7.0 jistone, orphan, 4 weeks ago sergesanspaille, tstellar llvm8.0 orphan, sergesanspaille, 3 weeks ago tstellar lv2-c++-tools orphan 0 weeks ago lv2-ll-pluginsorphan 0 weeks ago lz4-java orphan 1 weeks ago lzma-java orphan 1 weeks ago maven-injection-pluginmizdebsk, orphan 0 weeks ago maven-jarsigner-pluginjcapik, mizdebsk, orphan 6 weeks ago maven-mapping mizdebsk, orphan 0 weeks
Re: Fedora 32 Beta Go/No-Go meeting
This is your final reminder. The Fedora 32 Beta Go/No-Go meeting is less than 24 hours away! On Thu, Mar 5, 2020 at 11:40 AM Ben Cotton wrote: > > The Go/No-Go meeting for the Fedora 32 Beta release will be held on > Thursday, 2020-03-12 at 17:00 UTC in #fedora-meeting-1. For more > information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting > > View the meeting on Fedocal at: > https://apps.fedoraproject.org/calendar/meeting/9716/ > > As usual, we will have the Release Readiness meeting following at > 19:00 UTC. This time, I'm asking teams to do their homework in > advance. Please update your team's status at: > https://fedoraproject.org/wiki/Release_Readiness > -- 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
[Test-Announce] Re: Fedora 32 Beta Go/No-Go meeting
This is your final reminder. The Fedora 32 Beta Go/No-Go meeting is less than 24 hours away! On Thu, Mar 5, 2020 at 11:40 AM Ben Cotton wrote: > > The Go/No-Go meeting for the Fedora 32 Beta release will be held on > Thursday, 2020-03-12 at 17:00 UTC in #fedora-meeting-1. For more > information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting > > View the meeting on Fedocal at: > https://apps.fedoraproject.org/calendar/meeting/9716/ > > As usual, we will have the Release Readiness meeting following at > 19:00 UTC. This time, I'm asking teams to do their homework in > advance. Please update your team's status at: > https://fedoraproject.org/wiki/Release_Readiness > -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to enable spec file preprocessing step before srpm build
Hello nils! On Wed, 11 Mar 2020 at 16:07, Nils Philippsen wrote: > > On Wed, 2020-03-11 at 12:21 +0100, clime wrote: > > rpmbuild needs to get a preprocessed spec already. > > Hmm, what do you mean with that? I mean, in this proposal, rpmbuild would need to get an already preprocessed spec file on input to work correctly in case the original spec file contains the new macros. I.e. you need to call some other command first (preproc-rpmspec) to get a spec file which is valid by rpm standard. > The spec files we currently have in > dist-git can be built directly with rpmbuild, you just need to tell > rpmbuild that the sources are in the same directory, e.g.: > > --- 8< --- > nils@gibraltar:~/dist-git/fedora/rpms/dcraw (master)> rpmbuild --define > "%_sourcedir $PWD" -ba --clean dcraw.spec Yes, this wouldn't be possible in my proposal iff the spec file contained the new non-rpm syntax. But `fedpkg local` would work or `mock --buildsrpm --spec dcraw.spec --sources .` would work and some tiny wrapper over rpmbuild (e.g. prerpmbuild as mentioned earlier) can be also provided to give users more low-level experience. > setting SOURCE_DATE_EPOCH=1563926400 > Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.PTKY48 > + umask 022 > + cd /home/nils/rpmbuild/BUILD > + cd /home/nils/rpmbuild/BUILD > + rm -rf dcraw > + /usr/bin/gzip -dc /home/nils/dist-git/fedora/rpms/dcraw/dcraw-9.28.0.tar.gz > [... skip build messages ...] > Wrote: /home/nils/rpmbuild/SRPMS/dcraw-9.28.0-6.fc31.src.rpm > Wrote: > /home/nils/rpmbuild/RPMS/x86_64/dcraw-debugsource-9.28.0-6.fc31.x86_64.rpm > Wrote: /home/nils/rpmbuild/RPMS/x86_64/dcraw-9.28.0-6.fc31.x86_64.rpm > Wrote: > /home/nils/rpmbuild/RPMS/x86_64/dcraw-debuginfo-9.28.0-6.fc31.x86_64.rpm > Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.qq02g8 > + umask 022 > + cd /home/nils/rpmbuild/BUILD > + cd dcraw > + /usr/bin/rm -rf /home/nils/rpmbuild/BUILDROOT/dcraw-9.28.0-6.fc31.x86_64 > + RPM_EC=0 > ++ jobs -p > + exit 0 > Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.x7fCS6 > + umask 022 > + cd /home/nils/rpmbuild/BUILD > + rm -rf dcraw > + RPM_EC=0 > ++ jobs -p > + exit 0 > nils@gibraltar:~/dist-git/fedora/rpms/dcraw (master)> > --- >8 --- > > That aside, the main thing I don't like in your proposal is that the > files would still be called '*.spec', but with the additional macros > they wouldn't be RPM spec files anymore. Files which are to be > preprocessed, should be distinguishable from the preprocessed version > by a different extension, e.g.: > > - something.c --> cpp --> something.i > - Makefile.am --> automake --> Makefile.in --> configure --> Makefile > - sendmail.mc -> /etc/mail/make (m4) -> sendmail.cf I understand this and currently, I give my template spec files .spec.rpkg extension (e.g. https://pagure.io/rpkg-util/blob/master/f/rpkg-util.spec.rpkg). But at the same time, I think that calling the file just somepkg.spec would provide a better user experience. Mainly, I wouldn't like very much to break *.spec glob that people might use. I think what is more important is that the glob finds at least something even if it is not necessarily a pure rpm spec file. I can tell you my related personal experience...I used to do web development and at some point, I was seeing all those extensions like .dhtml, .phtml, .html.j2, etc. used for template files. A few years later, however, I started to see a backward trend - some frameworks began to use again just .html even when speaking about dynamic html files. While I was surprised by this initially, in the end, I found it much easier to work with because usually, one just wants to open a template file (when the problem appears to be in a template) and what is the templating language in use is not that important until a file is opened. Best regards! clime > > Nils > -- > Nils Philippsen"Those who would give up Essential Liberty to > Software Engineer purchase a little Temporary Safety, deserve neither > Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 > PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D > old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 > ___ > 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:
Re: Using %triggerpostun with %systemd_post on upgrades
On Wed, Mar 11, 2020 at 12:38 PM Chris Murphy wrote: > > On Wed, Mar 11, 2020 at 10:26 AM Adam Williamson > wrote: > > > > On Tue, 2020-03-10 at 13:21 -0600, Chris Murphy wrote: > > > Retrying while simplifying... > > > > > > The spec file contains these two lines: > > > > > > %triggerpostun -- fedora-release < 32 > > > %systemd_post fstrim.timer > > > > > > I don't know the proper terminology, but I think 'fedora-release' is a > > > meta package? Since this doesn't exist on anyone's F31 system, I > > > wonder if this should be 'fedora-release-common' instead? > > > > hmm, that's actually a bit tricky, because there's no 'right' way to > > use a real package there. It's canon that you can't assume the 'fedora- > > release' packages specifically are installed, because we allow for > > customization: the 'system-release' virtual provides exist for this > > purpose. All the 'fedora-release' and 'generic-release' subpackages > > should provide the same 'system-release' stuff, anything that depends > > on release-y things is supposed to use 'system-release' (not 'fedora- > > release'), and the idea is that if you're branding Fedora, you fork > > generic-release into your *own* 'branded' -release packages which > > should also provide all the canonical 'system-release' provides. > > > > So...if you can't use virtual provides for triggers, it looks hard to > > do that :/ > > It sounds like Editions definitely have 'fedora-release-common' (and > probably spins created by Fedora). Right? So that means this trigger > needs to be 'fedora-release-common' to have some chance of affecting > upgrades; where 'fedora-release' definitely won't work. Other things are hard already, even within editions, when it comes to upgrades not being the same as clean installs: https://pagure.io/fedora-workstation/issue/138 -- 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: Using %triggerpostun with %systemd_post on upgrades
On Wed, Mar 11, 2020 at 10:26 AM Adam Williamson wrote: > > On Tue, 2020-03-10 at 13:21 -0600, Chris Murphy wrote: > > Retrying while simplifying... > > > > The spec file contains these two lines: > > > > %triggerpostun -- fedora-release < 32 > > %systemd_post fstrim.timer > > > > I don't know the proper terminology, but I think 'fedora-release' is a > > meta package? Since this doesn't exist on anyone's F31 system, I > > wonder if this should be 'fedora-release-common' instead? > > hmm, that's actually a bit tricky, because there's no 'right' way to > use a real package there. It's canon that you can't assume the 'fedora- > release' packages specifically are installed, because we allow for > customization: the 'system-release' virtual provides exist for this > purpose. All the 'fedora-release' and 'generic-release' subpackages > should provide the same 'system-release' stuff, anything that depends > on release-y things is supposed to use 'system-release' (not 'fedora- > release'), and the idea is that if you're branding Fedora, you fork > generic-release into your *own* 'branded' -release packages which > should also provide all the canonical 'system-release' provides. > > So...if you can't use virtual provides for triggers, it looks hard to > do that :/ It sounds like Editions definitely have 'fedora-release-common' (and probably spins created by Fedora). Right? So that means this trigger needs to be 'fedora-release-common' to have some chance of affecting upgrades; where 'fedora-release' definitely won't work. -- 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: Fedora CI update 2020-03-11
Hi, On Wed, Mar 11, 2020 at 6:14 PM Sudhir D wrote: > > > On 3/11/20 7:14 PM, Aleksandra Fedorova wrote: > > Hi, all. > > > > Here is the summary of CI-related work happening in Fedora. > > > > If you have questions or topics to discuss you can also join Fedora CI > > SIG bi-weekly meeting. Next session is today in #fedora-ci IRC channel > > at 15:30 UTC > > > > https://apps.fedoraproject.org/calendar/SIGs/#m9618 > > > > > > > > ### Dist-git tests support multipackage updates > > > > You can define package tests in dist-git via STR format > > > > https://docs.fedoraproject.org/en-US/ci/standard-test-roles/ > > > > Note that dist-git/STR tests are different from running %check tests > > in the rpm building phase. STR tests are executed in a clean virtual > > machine with proper setup of repositories for the latest Fedora > > Rawhide packages. This environment is better suited for integration > > tests, which need to test the installed package, not the sources of > > it. > > > > Dist-git tests are fully compatible with the dynamic sidetag approach: > > if you create a dynamic sidetag for the multi-package update, test > > environment will be created with the content of the entire sidetag, > > not an individual package. > > > > Status: Ready to Use > > Contact: Bruno Goncalves (bgoncalv) and #fedora-ci IRC channel. > > > > ### New test: rpminspect > > > > There is a new rpminspect test running in Fedora Rawhide gating > > enabled by default for all packages in a non-blocking mode. > > > > More details: > > https://github.com/rpminspect/rpminspect > > > > Status: Ready to Use > > Contact: David Cantrell (dcantrell) > > > Thanks for sending out all this information, Aleksandra :) > > I also want to call out Tim Flink (irc: tflink) from Fedora QA team who > worked extensively on getting rpminspect to run in a way that its > results could show up in bodhi. I somehow took it for granted that everyone knows Tim is there. Thanks for clearing that out. > > > > ### Tests for pull-requests via Zuul > > > > Zuul team has enabled Zuul CI engine to test Pagure pull requests. > > > > You can opt-in to Zuul CI per package. > > > > On every pull-request Zuul will > > * run a scratch build > > * run rpminspect on that build > > * run dist-git test defined in STR format(if available) > > * provide comment in the pull-request > > * wait for you to put an manual approval on the PR > > * merge the PR > > > > * you can also get Zuul to handle merge events, so that it will > > automatically build the regular koji build, after the merge. > > > > Zuul now has support for EPEL8 branches. > > > > More details: > > https://fedoraproject.org/wiki/Zuul-based-ci > > > > Status: Ready to use > > Contact: Fabien Boucher (fbo) > > > > ### Koschei as a gating test > > > > With sidetag gating feature enabled it is now possible to run Koschei > > for each dynamic sidetag and make it a part of the gating process. > > > > We do have Koschei deployed on Fedora infrastructure. There is > > on-going work by Mikolaj Izdebski to get it integrated with the Fedora > > Messaging, so that sidetags are submitted in Koschei when created. > > > > Status: research and prototyping > > Contact: Serhii Turivnyi (sturivny) > > > > ### Infra change: new Jenkins master > > > > New Jenkins master to run generic tests and inherit Taskotron pipelines. > > > > Our current Jenkins master, which is used for dist-git tests, was not > > updated for some time and it is by design bundled to the pipeline it > > runs. So adding new pipelines and separating pipelines from the > > Jenkins master configuration is problematic. > > > > The goal here is to have a Jenkins master setup which is easy to > > update. It will have a set of plugins pre-installed and configured for > > Fedora infrastructure endpoints, but jobs configuration will be > > applied to it independently. > > > > More details: > > Current work is done on a Communishift project. Code will be available > > soon at https://github.com/fedora-ci > > > > Status: WIP > > Contact: Jim Bair (jbair) > > > > ### Infra change: common repository and common format for generic tests > > > > We are refactoring the Groovy pipeline library so it is better suited > > to run generic tests. > > > > One of the goals is that generic tests are all run in the same way, > > and you don’t need to add a lot of new Groovy code to add a certain > > bash script as a generic test. > > > > We’d like people to be able to contribute new generic tests without > > prior knowledge of the Jenkins internal setup. > > > > Current focus is rpmdeplint and rpminspect pipelines. > > > > More details: > > https://github.com/fedora-ci > > > > Status: WIP > > Contact: Michal Srb (msrb) > > > > ### Infra change: ODCS composes > > > > We are updating ODCS staging infrastructure to the latest ODCS > > release. Once the Fedora instractructure freeze is over, we will also > > update the ODCS production
Re: Fedora CI update 2020-03-11
On 3/11/20 7:14 PM, Aleksandra Fedorova wrote: Hi, all. Here is the summary of CI-related work happening in Fedora. If you have questions or topics to discuss you can also join Fedora CI SIG bi-weekly meeting. Next session is today in #fedora-ci IRC channel at 15:30 UTC https://apps.fedoraproject.org/calendar/SIGs/#m9618 ### Dist-git tests support multipackage updates You can define package tests in dist-git via STR format https://docs.fedoraproject.org/en-US/ci/standard-test-roles/ Note that dist-git/STR tests are different from running %check tests in the rpm building phase. STR tests are executed in a clean virtual machine with proper setup of repositories for the latest Fedora Rawhide packages. This environment is better suited for integration tests, which need to test the installed package, not the sources of it. Dist-git tests are fully compatible with the dynamic sidetag approach: if you create a dynamic sidetag for the multi-package update, test environment will be created with the content of the entire sidetag, not an individual package. Status: Ready to Use Contact: Bruno Goncalves (bgoncalv) and #fedora-ci IRC channel. ### New test: rpminspect There is a new rpminspect test running in Fedora Rawhide gating enabled by default for all packages in a non-blocking mode. More details: https://github.com/rpminspect/rpminspect Status: Ready to Use Contact: David Cantrell (dcantrell) Thanks for sending out all this information, Aleksandra :) I also want to call out Tim Flink (irc: tflink) from Fedora QA team who worked extensively on getting rpminspect to run in a way that its results could show up in bodhi. ### Tests for pull-requests via Zuul Zuul team has enabled Zuul CI engine to test Pagure pull requests. You can opt-in to Zuul CI per package. On every pull-request Zuul will * run a scratch build * run rpminspect on that build * run dist-git test defined in STR format(if available) * provide comment in the pull-request * wait for you to put an manual approval on the PR * merge the PR * you can also get Zuul to handle merge events, so that it will automatically build the regular koji build, after the merge. Zuul now has support for EPEL8 branches. More details: https://fedoraproject.org/wiki/Zuul-based-ci Status: Ready to use Contact: Fabien Boucher (fbo) ### Koschei as a gating test With sidetag gating feature enabled it is now possible to run Koschei for each dynamic sidetag and make it a part of the gating process. We do have Koschei deployed on Fedora infrastructure. There is on-going work by Mikolaj Izdebski to get it integrated with the Fedora Messaging, so that sidetags are submitted in Koschei when created. Status: research and prototyping Contact: Serhii Turivnyi (sturivny) ### Infra change: new Jenkins master New Jenkins master to run generic tests and inherit Taskotron pipelines. Our current Jenkins master, which is used for dist-git tests, was not updated for some time and it is by design bundled to the pipeline it runs. So adding new pipelines and separating pipelines from the Jenkins master configuration is problematic. The goal here is to have a Jenkins master setup which is easy to update. It will have a set of plugins pre-installed and configured for Fedora infrastructure endpoints, but jobs configuration will be applied to it independently. More details: Current work is done on a Communishift project. Code will be available soon at https://github.com/fedora-ci Status: WIP Contact: Jim Bair (jbair) ### Infra change: common repository and common format for generic tests We are refactoring the Groovy pipeline library so it is better suited to run generic tests. One of the goals is that generic tests are all run in the same way, and you don’t need to add a lot of new Groovy code to add a certain bash script as a generic test. We’d like people to be able to contribute new generic tests without prior knowledge of the Jenkins internal setup. Current focus is rpmdeplint and rpminspect pipelines. More details: https://github.com/fedora-ci Status: WIP Contact: Michal Srb (msrb) ### Infra change: ODCS composes We are updating ODCS staging infrastructure to the latest ODCS release. Once the Fedora instractructure freeze is over, we will also update the ODCS production instance. This work is preparation for possible further use of ODCS to generate composes used by Fedora CI as well as main Fedora composes. Status: WIP Contact: Jan Kaluza (jkaluza) ### Infra change: Testing Farm Service Testing Farm Team is working on open-sourcing parts of the RH internal CI infrastructure as a service, which will be used by Fedora CI's general tests and functional tests pipeline. The main input of the service will be test definitions in the TMT/FMF format. TMT documentation: https://tmt.readthedocs.io/en/latest/ (recently added testcloud + podman provisioner) Code is hosted at GitLab:
Re: Using %triggerpostun with %systemd_post on upgrades
On Tue, 2020-03-10 at 13:21 -0600, Chris Murphy wrote: > Retrying while simplifying... > > The spec file contains these two lines: > > %triggerpostun -- fedora-release < 32 > %systemd_post fstrim.timer > > I don't know the proper terminology, but I think 'fedora-release' is a > meta package? Since this doesn't exist on anyone's F31 system, I > wonder if this should be 'fedora-release-common' instead? hmm, that's actually a bit tricky, because there's no 'right' way to use a real package there. It's canon that you can't assume the 'fedora- release' packages specifically are installed, because we allow for customization: the 'system-release' virtual provides exist for this purpose. All the 'fedora-release' and 'generic-release' subpackages should provide the same 'system-release' stuff, anything that depends on release-y things is supposed to use 'system-release' (not 'fedora- release'), and the idea is that if you're branding Fedora, you fork generic-release into your *own* 'branded' -release packages which should also provide all the canonical 'system-release' provides. So...if you can't use virtual provides for triggers, it looks hard to do that :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
HEADS UP: repoquery --whatrequires yields incomplete results when run from Fedora 32+
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).
--
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] New: perl-Devel-PatchPerl-1.90 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812567 Bug ID: 1812567 Summary: perl-Devel-PatchPerl-1.90 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Devel-PatchPerl Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.90 Current version/release in rawhide: 1.86-1.fc32 URL: http://search.cpan.org/dist/Devel-PatchPerl/ 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/6561/ -- 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] Re: Proposed official change to EPEL guidelines: modules and RHEL
On Wed, Mar 11, 2020 at 06:52:12AM -0700, Troy Dawson wrote: > On Wed, Mar 11, 2020 at 1:25 AM Petr Pisar wrote: > > > > I can only see a small ambiguity regarding build-only packages that are > > filtered out of the module. I believe the rule about the module names should > > not apply for these filtered packages. > > > > If they are filtered out of the module, then end users cannot see > and/or use them. > If that is the case, they are fair game for EPEL, and I believe (but > haven't checked) that packagers already should be able to request > them. I thought so. > Is there a particular package you know about that I could check? > There can barely be any now because there are no modules in EPEL yet. And you cannot see any of the filtered packages in RHEL because they are not distributed to repositories (except the few -devel modules). > > But that leads me to a question about -devel modules. RHEL delivers some > > -devel modules in a CRB repository. These -devel modules consists of the > > filtered packages. Is EPEL going to mimic these -devel modules, or not? > > > > Can you give an example of a -devel package in CRB that is from a > package that is filtered from a module? RHEL-8.1.1: # dnf module list | grep -e -devel mariadb-devel10.3 MariaDB Module virt-devel rhel Virtualization module virt-devel rhel Virtualization module E.g. virt-devel:rhel:8010020190916153839 contains qemu-kvm-tests-15:2.12.0-88.module+el8.1.0+4233+bc44be3f.x86_64 package. RHEL-8.2 Beta brings python38-devel:3.8 module. -- Petr signature.asc Description: PGP signature ___ 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
Re: Proposal to enable spec file preprocessing step before srpm build
On Wed, 2020-03-11 at 12:21 +0100, clime wrote: > rpmbuild needs to get a preprocessed spec already. Hmm, what do you mean with that? The spec files we currently have in dist-git can be built directly with rpmbuild, you just need to tell rpmbuild that the sources are in the same directory, e.g.: --- 8< --- nils@gibraltar:~/dist-git/fedora/rpms/dcraw (master)> rpmbuild --define "%_sourcedir $PWD" -ba --clean dcraw.spec setting SOURCE_DATE_EPOCH=1563926400 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.PTKY48 + umask 022 + cd /home/nils/rpmbuild/BUILD + cd /home/nils/rpmbuild/BUILD + rm -rf dcraw + /usr/bin/gzip -dc /home/nils/dist-git/fedora/rpms/dcraw/dcraw-9.28.0.tar.gz [... skip build messages ...] Wrote: /home/nils/rpmbuild/SRPMS/dcraw-9.28.0-6.fc31.src.rpm Wrote: /home/nils/rpmbuild/RPMS/x86_64/dcraw-debugsource-9.28.0-6.fc31.x86_64.rpm Wrote: /home/nils/rpmbuild/RPMS/x86_64/dcraw-9.28.0-6.fc31.x86_64.rpm Wrote: /home/nils/rpmbuild/RPMS/x86_64/dcraw-debuginfo-9.28.0-6.fc31.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.qq02g8 + umask 022 + cd /home/nils/rpmbuild/BUILD + cd dcraw + /usr/bin/rm -rf /home/nils/rpmbuild/BUILDROOT/dcraw-9.28.0-6.fc31.x86_64 + RPM_EC=0 ++ jobs -p + exit 0 Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.x7fCS6 + umask 022 + cd /home/nils/rpmbuild/BUILD + rm -rf dcraw + RPM_EC=0 ++ jobs -p + exit 0 nils@gibraltar:~/dist-git/fedora/rpms/dcraw (master)> --- >8 --- That aside, the main thing I don't like in your proposal is that the files would still be called '*.spec', but with the additional macros they wouldn't be RPM spec files anymore. Files which are to be preprocessed, should be distinguishable from the preprocessed version by a different extension, e.g.: - something.c --> cpp --> something.i - Makefile.am --> automake --> Makefile.in --> configure --> Makefile - sendmail.mc -> /etc/mail/make (m4) -> sendmail.cf Nils -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ 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 1812502] perl-Log-ger-0.037 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812502 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Log-ger-0.037-1.fc33 Resolution|--- |RAWHIDE Last Closed||2020-03-11 14:18:30 -- 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] Re: Reminder: EPEL Steering Committee meeting moved to Fridays
On Tue, Mar 10, 2020 at 12:47 PM Matthew Miller wrote: > > On Tue, Mar 10, 2020 at 09:09:11AM -0700, Troy Dawson wrote: > > Just a reminder that the EPEL Steering Committee meeting has been > > moved to Fridays at 2100 UTC. > > > > To find out when that is for you, do > > date -d "Fri 2100 UTC" > > > > A reminder should be sent out the day before. > > Hi Troy. Can you let me know if the modular-versions proposal is on an > upcoming agenda? > Yep, just put it on. We'll talk about it, and possibly vote on it, at this Fridays meeting. Troy ___ 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
[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL
On Wed, Mar 11, 2020 at 1:25 AM Petr Pisar wrote: > > On Tue, Mar 10, 2020 at 02:13:22PM -0700, Troy Dawson wrote: > > We propose adding: > > > > In EPEL 8 or later, it is permitted to have module streams which contain > > packages with alternate versions to those provided in RHEL. These packages > > may be newer, built with different options, or even older to serve > > compatibility needs. These MUST NOT be the default stream -- in every > > case, explicit user action must be required to opt in to these > > versions. If the > > RHEL package is in a RHEL module, then the EPEL module must have the same > > name as the RHEL module. Any exceptions to the module name must be > > approved by the EPEL Steering Committee. > > > That's a reasonable proposal. > > I can only see a small ambiguity regarding build-only packages that are > filtered out of the module. I believe the rule about the module names should > not apply for these filtered packages. > If they are filtered out of the module, then end users cannot see and/or use them. If that is the case, they are fair game for EPEL, and I believe (but haven't checked) that packagers already should be able to request them. Is there a particular package you know about that I could check? > But that leads me to a question about -devel modules. RHEL delivers some > -devel modules in a CRB repository. These -devel modules consists of the > filtered packages. Is EPEL going to mimic these -devel modules, or not? > Can you give an example of a -devel package in CRB that is from a package that is filtered from a module? Most people have been complaining that there aren't enough -devel packages in CRB. If there are some in there that don't have an accessible package that corresponds to it, I think that's a bug on the RHEL side and we should let them know. Troy ___ 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
Re: Donate 1 minute of your time to test upgrades from F31 to F32
Hi, So, I went ahead and actually did the upgrade on three different systems: two workstation installs and a server install. I'm happy to report that the upgrade went through without any issues. On F32, I seem to be hitting a qt-webengine bug, though. Abrt reported it here: https://bugzilla.redhat.com/show_bug.cgi?id=1812482 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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
Fedora CI update 2020-03-11
Hi, all. Here is the summary of CI-related work happening in Fedora. If you have questions or topics to discuss you can also join Fedora CI SIG bi-weekly meeting. Next session is today in #fedora-ci IRC channel at 15:30 UTC https://apps.fedoraproject.org/calendar/SIGs/#m9618 ### Dist-git tests support multipackage updates You can define package tests in dist-git via STR format https://docs.fedoraproject.org/en-US/ci/standard-test-roles/ Note that dist-git/STR tests are different from running %check tests in the rpm building phase. STR tests are executed in a clean virtual machine with proper setup of repositories for the latest Fedora Rawhide packages. This environment is better suited for integration tests, which need to test the installed package, not the sources of it. Dist-git tests are fully compatible with the dynamic sidetag approach: if you create a dynamic sidetag for the multi-package update, test environment will be created with the content of the entire sidetag, not an individual package. Status: Ready to Use Contact: Bruno Goncalves (bgoncalv) and #fedora-ci IRC channel. ### New test: rpminspect There is a new rpminspect test running in Fedora Rawhide gating enabled by default for all packages in a non-blocking mode. More details: https://github.com/rpminspect/rpminspect Status: Ready to Use Contact: David Cantrell (dcantrell) ### Tests for pull-requests via Zuul Zuul team has enabled Zuul CI engine to test Pagure pull requests. You can opt-in to Zuul CI per package. On every pull-request Zuul will * run a scratch build * run rpminspect on that build * run dist-git test defined in STR format(if available) * provide comment in the pull-request * wait for you to put an manual approval on the PR * merge the PR * you can also get Zuul to handle merge events, so that it will automatically build the regular koji build, after the merge. Zuul now has support for EPEL8 branches. More details: https://fedoraproject.org/wiki/Zuul-based-ci Status: Ready to use Contact: Fabien Boucher (fbo) ### Koschei as a gating test With sidetag gating feature enabled it is now possible to run Koschei for each dynamic sidetag and make it a part of the gating process. We do have Koschei deployed on Fedora infrastructure. There is on-going work by Mikolaj Izdebski to get it integrated with the Fedora Messaging, so that sidetags are submitted in Koschei when created. Status: research and prototyping Contact: Serhii Turivnyi (sturivny) ### Infra change: new Jenkins master New Jenkins master to run generic tests and inherit Taskotron pipelines. Our current Jenkins master, which is used for dist-git tests, was not updated for some time and it is by design bundled to the pipeline it runs. So adding new pipelines and separating pipelines from the Jenkins master configuration is problematic. The goal here is to have a Jenkins master setup which is easy to update. It will have a set of plugins pre-installed and configured for Fedora infrastructure endpoints, but jobs configuration will be applied to it independently. More details: Current work is done on a Communishift project. Code will be available soon at https://github.com/fedora-ci Status: WIP Contact: Jim Bair (jbair) ### Infra change: common repository and common format for generic tests We are refactoring the Groovy pipeline library so it is better suited to run generic tests. One of the goals is that generic tests are all run in the same way, and you don’t need to add a lot of new Groovy code to add a certain bash script as a generic test. We’d like people to be able to contribute new generic tests without prior knowledge of the Jenkins internal setup. Current focus is rpmdeplint and rpminspect pipelines. More details: https://github.com/fedora-ci Status: WIP Contact: Michal Srb (msrb) ### Infra change: ODCS composes We are updating ODCS staging infrastructure to the latest ODCS release. Once the Fedora instractructure freeze is over, we will also update the ODCS production instance. This work is preparation for possible further use of ODCS to generate composes used by Fedora CI as well as main Fedora composes. Status: WIP Contact: Jan Kaluza (jkaluza) ### Infra change: Testing Farm Service Testing Farm Team is working on open-sourcing parts of the RH internal CI infrastructure as a service, which will be used by Fedora CI's general tests and functional tests pipeline. The main input of the service will be test definitions in the TMT/FMF format. TMT documentation: https://tmt.readthedocs.io/en/latest/ (recently added testcloud + podman provisioner) Code is hosted at GitLab: https://gitlab.com/testing-farm/ Status: WIP (preview May 2020, GA August 2020) Contact: Miroslav Vadkerti (mvadkert) ### CI and Gating documentation There is a repository of CI documentation https://pagure.io/fedora-ci/docs/ The docs are published at https://docs.fedoraproject.org/en-US/ci/
Re: Reducing broken dependencies in fedora (32) repositories
On Wed, Mar 11, 2020 at 2:17 PM Igor Gnatenko wrote: > > We could if somebody will commit on maintaining those packages in stable > releases, keep them always updated, insert proper Obsoletes and create compat > packages all the time. I volunteered to work on stable-release rust packages, and to create compat packages as necessary. I probably won't be able to do this alone, but given the interest in this thread, I think we should be able to do it. > The good news are that Koji maintainers implemented necessary configuration > and when new version will be released and deployed in infra, anybody will be > able to update them in stable using SOP. I don't think rust packages should be treated in any special way here. Every other language ecosystem is dealing with this problem already, so Rust should manage as well. I am not against improving infrastructure, I'm just against making Rust a special case here (since it's actually more nicely behaved as an ecosystem than, for example, Go). Fabio > On Mon, Mar 9, 2020, 18:40 Zbigniew Jędrzejewski-Szmek > wrote: >> >> On Mon, Mar 09, 2020 at 04:53:25PM +0100, Fabio Valentini wrote: >> > On Mon, Mar 9, 2020 at 4:42 PM Zbigniew Jędrzejewski-Szmek >> > wrote: >> > > >> > > On Fri, Mar 06, 2020 at 09:35:52PM +0100, Fabio Valentini wrote: >> > > > https://pagure.io/fedora-health-check/blob/master/f/reports/report-32.md >> > > > Report with testing repos enabled: >> > > > https://pagure.io/fedora-health-check/blob/master/f/reports/report-32-testing.md >> > > >> > > I see a lot of rust packages on this list, but I can't quite figure out >> > > what is wrong: >> > > >> > > For rust-zram-generator, mock says: >> > > Problem 1: nothing provides requested (crate(failure/default) >= 0.1.0 >> > > with crate(failure/default) < 0.2.0) >> > > Problem 2: nothing provides requested (crate(failure_derive/default) >= >> > > 0.1.0 with crate(failure_derive/default) < 0.2.0) >> > > Problem 3: nothing provides requested (crate(rust-ini/default) >= >> > > 0.13.0 with crate(rust-ini/default) < 0.14.0) >> > > >> > > But rust-failure-0.1.6-1.fc32 is the last build in F32 and it has >> > > rust-failure+derive-devel-0.1.6-1.fc32.noarch.rpm which has >> > > Provides: crate(failure/derive) = 0.1.6. >> > > >> > > I'm confused why it's not getting picked up. >> > > >> > > Oh, I see now: >> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1416018 >> > > has Tags: f31-build-side-17673 f31-build-side-17691 >> > > f31-build-side-17821 f31-build-side-19481 f32-build-side-19483 >> > > f33 >> > > but not f32. >> > > >> > > Igor, Josh? >> > >> > Source-only rust packages (those only shipping noarch -devel >> > subpackages) have been untagged from f32 on purpose by Igor. For >> > reasons I disagree with :) >> > So all the missing dependencies in rust packages (that are shipping >> > binaries) on f32 are there because there are no source-only rust >> > packages on f32 at all ... >> >> Hi Igor, >> >> can we please revisit this decision? We need rust-*-devel to do package >> reviews, rebuilds, and whatnot. >> >> Zbyszek >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ 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: Reducing broken dependencies in fedora (32) repositories
No. All dependencies and such are in Fedora Build System and kept there as any other package. On Wed, Mar 11, 2020, 14:10 Peter Robinson wrote: > On Wed, Mar 11, 2020 at 12:58 PM Randy Barlow > wrote: > > > > On 3/9/20 11:53 AM, Fabio Valentini wrote: > > > Source-only rust packages (those only shipping noarch -devel > > > subpackages) have been untagged from f32 on purpose by Igor. For > > > reasons I disagree with:) > > > > I too wish that we kept the Rust devel packages in stable releases. I am > > unable to build updates for my Rust packages by myself since their > > dependencies have been untagged. I recently noticed that a license tag > > was wrong in my Rust packages, and I had to ask for administrator help > > to get it fixed since I don't have permissions to set up the side tags > > and get the crates tagged into them. > > > > I will admit that I don't understand the reasoning behind the decision > > to remove these packages from non-rawhide releases. Igor, could you tell > > us why this is done? > > Is there also a possible license issue here, license depending, that > it's not a reproducible build? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
We could if somebody will commit on maintaining those packages in stable releases, keep them always updated, insert proper Obsoletes and create compat packages all the time. The good news are that Koji maintainers implemented necessary configuration and when new version will be released and deployed in infra, anybody will be able to update them in stable using SOP. On Mon, Mar 9, 2020, 18:40 Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Mar 09, 2020 at 04:53:25PM +0100, Fabio Valentini wrote: > > On Mon, Mar 9, 2020 at 4:42 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Fri, Mar 06, 2020 at 09:35:52PM +0100, Fabio Valentini wrote: > > > > > https://pagure.io/fedora-health-check/blob/master/f/reports/report-32.md > > > > Report with testing repos enabled: > > > > > https://pagure.io/fedora-health-check/blob/master/f/reports/report-32-testing.md > > > > > > I see a lot of rust packages on this list, but I can't quite figure out > > > what is wrong: > > > > > > For rust-zram-generator, mock says: > > > Problem 1: nothing provides requested (crate(failure/default) >= > 0.1.0 with crate(failure/default) < 0.2.0) > > > Problem 2: nothing provides requested (crate(failure_derive/default) > >= 0.1.0 with crate(failure_derive/default) < 0.2.0) > > > Problem 3: nothing provides requested (crate(rust-ini/default) >= > 0.13.0 with crate(rust-ini/default) < 0.14.0) > > > > > > But rust-failure-0.1.6-1.fc32 is the last build in F32 and it has > > > rust-failure+derive-devel-0.1.6-1.fc32.noarch.rpm which has > > > Provides: crate(failure/derive) = 0.1.6. > > > > > > I'm confused why it's not getting picked up. > > > > > > Oh, I see now: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1416018 > > > has Tags: f31-build-side-17673 f31-build-side-17691 > > > f31-build-side-17821 f31-build-side-19481 > f32-build-side-19483 f33 > > > but not f32. > > > > > > Igor, Josh? > > > > Source-only rust packages (those only shipping noarch -devel > > subpackages) have been untagged from f32 on purpose by Igor. For > > reasons I disagree with :) > > So all the missing dependencies in rust packages (that are shipping > > binaries) on f32 are there because there are no source-only rust > > packages on f32 at all ... > > Hi Igor, > > can we please revisit this decision? We need rust-*-devel to do package > reviews, rebuilds, and whatnot. > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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 1812502] perl-Log-ger-0.037 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812502 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- 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 --- Comment #1 from Fedora Update System --- FEDORA-2020-2ac46db8c3 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2ac46db8c3 -- 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: submitting bodhi.template.last to fedpkg update?
On 3/10/20 12:17 PM, Ron Olson wrote: is there a way to pass the body.template.last file to ‘fedpkg update’ so I don’t have to fill it out for every single release, or fill it out again when I get a timeout and have to rerun fedpkg update? See the --file flag on bodhi updates new. It's not exactly what you are asking for, but the template that you fill out when you run fedpkg update is sent to the bodhi CLI with bodhi updates new --file /path/to/template, so you could skip using fedpkg update and use the bodhi CLI yourself if you find that to be an acceptable workaround. ___ 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: Reducing broken dependencies in fedora (32) repositories
On Wed, Mar 11, 2020 at 12:58 PM Randy Barlow wrote: > > On 3/9/20 11:53 AM, Fabio Valentini wrote: > > Source-only rust packages (those only shipping noarch -devel > > subpackages) have been untagged from f32 on purpose by Igor. For > > reasons I disagree with:) > > I too wish that we kept the Rust devel packages in stable releases. I am > unable to build updates for my Rust packages by myself since their > dependencies have been untagged. I recently noticed that a license tag > was wrong in my Rust packages, and I had to ask for administrator help > to get it fixed since I don't have permissions to set up the side tags > and get the crates tagged into them. > > I will admit that I don't understand the reasoning behind the decision > to remove these packages from non-rawhide releases. Igor, could you tell > us why this is done? Is there also a possible license issue here, license depending, that it's not a reproducible build? ___ 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 1812502] New: perl-Log-ger-0.037 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812502 Bug ID: 1812502 Summary: perl-Log-ger-0.037 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Log-ger Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.037 Current version/release in rawhide: 0.036-1.fc33 URL: http://search.cpan.org/dist/Log-ger/ 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/15741/ -- 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: Reducing broken dependencies in fedora (32) repositories
On 3/9/20 11:53 AM, Fabio Valentini wrote: Source-only rust packages (those only shipping noarch -devel subpackages) have been untagged from f32 on purpose by Igor. For reasons I disagree with:) I too wish that we kept the Rust devel packages in stable releases. I am unable to build updates for my Rust packages by myself since their dependencies have been untagged. I recently noticed that a license tag was wrong in my Rust packages, and I had to ask for administrator help to get it fixed since I don't have permissions to set up the side tags and get the crates tagged into them. I will admit that I don't understand the reasoning behind the decision to remove these packages from non-rawhide releases. Igor, could you tell us why this is done? ___ 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 1812177] perl-MooX-StrictConstructor-0.011 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812177 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-MooX-StrictConstructor ||-0.011-1.fc33 ||perl-MooX-StrictConstructor ||-0.011-1.fc32 -- 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: Proposal to enable spec file preprocessing step before srpm build
On Wed, 11 Mar 2020 at 11:24, Richard W.M. Jones wrote: > > On Mon, Mar 09, 2020 at 11:36:33PM +0100, clime wrote: > > On Mon, 9 Mar 2020 at 22:45, Richard W.M. Jones wrote: > > > > > > > > > This would break processing with ‘rpmspec’? > > > > With just rpmspec, yes. The preproc-rpmspec tool can become a wrapper > > around rpmspec aliased prerpmspec essentially doing the preprocessing, > > then immediately passing the result to rpmspec for further processing. > > Similarly with spectool, wrapper prespectool can be provided. > > Also this would break fedpkg local, fedpkg srpm, rpmbuild, any process > which creates an SRPM, and arbitrary scripts that we run over spec > files? Hey Richard! fedpkg local and fedpkg srpm support can be added. rpmbuild needs to get a preprocessed spec already. This can be assured by having support in a higher layer (i.e. in mock). Manually on command line, you would first run: $ preproc-rpmspec -o and then $ rpmbuild -bs if you wanted to do the operation manually. I don't think that we would call somewhere in infra rpmbuild directly. It is either wrapped in mock or in fedpkg so adding support to these places should be sufficient. Ad. "arbitrary scripts that we run over spec file". Do you mean in infrastructure or somewhere else? I am aware of the mass rebuild script and rpmdev-bumpspec that need to be tweaked. Would you know about any other infra scripts that need to be adjusted? Or do you mean packager custom scripts that one would use to make his/her packaging job easier and that work directly on spec file? If someone has such a strong local tooling, probably this proposal wouldn't work for him/her. But this is opt-in only so everyone is free to use what works the best. In other words, I would need to know what are those arbitrary scripts. Also, if the majority of packagers like to use rpmbuild directly when doing local builds, then my proposal wouldn't probably work but I assumed it's not the case. But even there we can offer prerpmbuild wrapper over rpmbuild which will do preprocessing and build in one go to make it easier. There, it's not super pleasant because you will have suddenly two commands (one which runs preprocessing first and one which doesn't) but on the level of fedpkg and mock, the commands stay exactly the same. clime > > If so, it seems like a bad idea to me. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > libguestfs lets you edit virtual machines. Supports shell scripting, > bindings from many languages. http://libguestfs.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 ___ 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 1812177] perl-MooX-StrictConstructor-0.011 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812177 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- 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 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Devel-PatchPerl-1.88-1 ||.fc33 ||perl-Devel-PatchPerl-1.88-1 ||.fc32 -- 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: Proposal to enable spec file preprocessing step before srpm build
On Mon, Mar 09, 2020 at 11:36:33PM +0100, clime wrote: > On Mon, 9 Mar 2020 at 22:45, Richard W.M. Jones wrote: > > > > > > This would break processing with ‘rpmspec’? > > With just rpmspec, yes. The preproc-rpmspec tool can become a wrapper > around rpmspec aliased prerpmspec essentially doing the preprocessing, > then immediately passing the result to rpmspec for further processing. > Similarly with spectool, wrapper prespectool can be provided. Also this would break fedpkg local, fedpkg srpm, rpmbuild, any process which creates an SRPM, and arbitrary scripts that we run over spec files? If so, it seems like a bad idea to me. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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
[Bug 1812257] perl-Devel-PatchPerl-1.88 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812257 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- 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 --- Comment #1 from Fedora Update System --- FEDORA-2020-f54cbf00c9 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f54cbf00c9 -- 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: gpg check failure installing from rawhide
Dne 11. 03. 20 v 1:12 Sam Varshavchik napsal(a): > Kevin Fenzi writes: > >> On Sat, Mar 07, 2020 at 09:47:03AM -0500, Sam Varshavchik wrote: >> > Trying to follow the direction for a bug report against kernel, and >> install >> > the latest kernel from rawhide. >> > >> > The Bugzilla template says: >> > >> > 5. Does this problem occur with the latest Rawhide kernel? To >> install the >> > Rawhide kernel, run “sudo dnf install fedora-repos-rawhide“ >> followed by >> > “sudo dnf update --enablerepo=rawhide kernel“: >> > >> > On F31, right now, 'dnf update --enablerepo=rawhide kernel' wants >> to install >> > 5.6.0-0.rc4.git0.1.fc33, which fails the gpg check: >> > >> > Public key for kernel-core-5.6.0-0.rc4.git0.1.fc33.x86_64.rpm is not >> > installed. Failing package is: >> kernel-core-5.6.0-0.rc4.git0.1.fc33.x86_64 >> > GPG Keys are configured as: >> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_64 >> > >> > So, something, somewhere, needs to be fixed, either the Bugzilla >> template, >> > or something related to signing. >> >> Hum, yeah, thats a though one. >> >> I guess the better command might be: >> >> sudo dnf update --releasever 33 --enablerepo rawhide kernel >> >> but of course there's no way to know '33' is right there unless you >> know. This could be made better moving forward when we land the >> 'rawhide' is called 'rawhide' and not the number change. > > That attempt still doesn't quite work: > > Warning: > /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/kernel-5.6.0-0.rc5.git0.1.fc33.x86_64.rpm: > Header V3 RSA/SHA256 Signature, key ID 9570ff31: NOKEY > Fedora - Rawhide - Developmental packages for t 0.0 B/s | 0 B > 00:00 > Curl error (37): Couldn't read a file:// file for > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64 [Couldn't open > file /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64] > The downloaded packages were saved in cache until the next successful > transaction. > > After doing a whatprovides on that, ended up install > fedora-gpg-keys-33 with nogpgcheck. That allowed the rawhide kernel > package to be installed. > > Of course, installing fedora-gpg-keys-33 conveniently uninstalled > fedora-gpg-keys-31. Can't win 'em all. It seems that fedora-repos-31-1 does not contain F33 GPG key, which should be fixed. You probably want to open ticket against fedora-repos. Vít > ___ > 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
Mock v2.1 release
Hey all, I'm pleased to announce that a new bugfix release of mock tool, A 'simple' chroot build environment manager for building RPMs, is out. There are several bugfixes, mostly for issues caused by rather big previous release (v2.0, cca month ago). See the release notes here: https://github.com/rpm-software-management/mock/wiki/Release-Notes-2.1 The fedora updates links are: F32 https://bodhi.fedoraproject.org/updates/FEDORA-2020-d32d395e18 F31 https://bodhi.fedoraproject.org/updates/FEDORA-2020-d952a70712 F30 https://bodhi.fedoraproject.org/updates/FEDORA-2020-e331425193 EL8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5a84e15907 EL7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88ef4b4d66 The following people contributed to this release: Jakub Kadlcik Miroslav Suchý Remi Collet Tomas Hrnciar Thank you all. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1812362] perl-XML-LibXML-2.0203 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812362 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-XML-LibXML-2.0203-1.fc ||33 -- 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 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|caillon+fedoraproject@gmail | |.com, ka...@ucw.cz, | |rhug...@redhat.com, | |rstr...@redhat.com, | |sandm...@redhat.com | Doc Type|--- |If docs needed, set a value -- 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: 'greenwave failed' – what does this mean?
On Wed, 11 Mar 2020 at 07:58, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > I have two updates [1, 2] for which I got email notifications yesterday: > > This update's test gating status has been changed to 'greenwave_failed'. > It means that Greenwave failed to answer to the request sent by Bodhi. > > This update's test gating status has been changed to 'ignored'. > This means that Bodhi got a successful answer from Greenwave and that this update does not require any tests. > > But a quick peak at the "Automated Tests" page shows 28/28 tests passed, > and "Test gating" shows "no tests are required". How can I figure out > what failed and where? > Seems that everything is in order now, the first request that Bodhi made to Greenwave must have failed, but in such cases Bodhi assumes that the tests are Green and does not block the update. > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2020-2344aea813 > [2] https://bodhi.fedoraproject.org/updates/FEDORA-2020-f24c9b4cd5 > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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 1808956] perl-Encode-3.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808956 Fedora Update System changed: What|Removed |Added Status|ON_QA |MODIFIED --- Comment #8 from Fedora Update System --- FEDORA-2020-5cb807fa40 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5cb807fa40 -- 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 1812295] perl-Encode-3.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812295 --- Comment #2 from Fedora Update System --- FEDORA-2020-5cb807fa40 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5cb807fa40 -- 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 1812295] perl-Encode-3.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812295 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Encode-3.04-443.fc33 --- 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
[Bug 1812295] perl-Encode-3.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812295 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- 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] Re: Proposed official change to EPEL guidelines: modules and RHEL
On Tue, Mar 10, 2020 at 02:13:22PM -0700, Troy Dawson wrote: > We propose adding: > > In EPEL 8 or later, it is permitted to have module streams which contain > packages with alternate versions to those provided in RHEL. These packages > may be newer, built with different options, or even older to serve > compatibility needs. These MUST NOT be the default stream -- in every > case, explicit user action must be required to opt in to these > versions. If the > RHEL package is in a RHEL module, then the EPEL module must have the same > name as the RHEL module. Any exceptions to the module name must be > approved by the EPEL Steering Committee. > That's a reasonable proposal. I can only see a small ambiguity regarding build-only packages that are filtered out of the module. I believe the rule about the module names should not apply for these filtered packages. But that leads me to a question about -devel modules. RHEL delivers some -devel modules in a CRB repository. These -devel modules consists of the filtered packages. Is EPEL going to mimic these -devel modules, or not? -- Petr signature.asc Description: PGP signature ___ 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
[Bug 1812362] New: perl-XML-LibXML-2.0203 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812362 Bug ID: 1812362 Summary: perl-XML-LibXML-2.0203 is available Product: Fedora Version: rawhide Status: NEW Component: perl-XML-LibXML Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, jples...@redhat.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 2.0203 Current version/release in rawhide: 2.0202-2.fc32 URL: https://metacpan.org/release/XML-LibXML 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/3527/ -- 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
'greenwave failed' – what does this mean?
Hi, I have two updates [1, 2] for which I got email notifications yesterday: > This update's test gating status has been changed to 'greenwave_failed'. > This update's test gating status has been changed to 'ignored'. But a quick peak at the "Automated Tests" page shows 28/28 tests passed, and "Test gating" shows "no tests are required". How can I figure out what failed and where? [1] https://bodhi.fedoraproject.org/updates/FEDORA-2020-2344aea813 [2] https://bodhi.fedoraproject.org/updates/FEDORA-2020-f24c9b4cd5 Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-IoT-32-20200310.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 1/8 (x86_64) New failures (same test not failed in Fedora-IoT-32-20200307.0): ID: 540335 Test: x86_64 IoT-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/540335 Soft failed openQA tests: 2/8 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-32-20200307.0): ID: 540333 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/540333 ID: 540334 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/540334 Passed openQA tests: 5/8 (x86_64) -- 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
