Re: libgps soname bump (gpsd-3.23)

[Miroslav Lichvar]

On Wed, Aug 11, 2021 at 08:27:27PM +0200, Björn 'besser82' Esser wrote:
> All packages have been rebuilt successfully, except for vfrnav, which
> fails for a segfault in inkscape during the testsuite.
> 
> Both sidetags can be merged now, as vfrnav hasn't been built
> successfully for a longer period of time, including the recent mass-
> rebuild for fc35.

I've submitted updates for both sidetags.

Thanks!

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-35-20210811.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 57/139 (aarch64), 23/202 (x86_64)

ID: 945792  Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/945792
ID: 945796  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/945796
ID: 945799  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/945799
ID: 945801  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/945801
ID: 945819  Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/945819
ID: 945820  Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/945820
ID: 945836  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/945836
ID: 945843  Test: aarch64 Server-raw_xz-raw.xz release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/945843
ID: 945853  Test: aarch64 Workstation-raw_xz-raw.xz 
release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/945853
ID: 945857  Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi
URL: https://openqa.fedoraproject.org/tests/945857
ID: 945939  Test: x86_64 universal memtest
URL: https://openqa.fedoraproject.org/tests/945939
ID: 946092  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/946092
ID: 946097  Test: aarch64 Server-dvd-iso install_blivet_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/946097
ID: 946098  Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/946098
ID: 946099  Test: aarch64 Server-dvd-iso 
install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/946099
ID: 946100  Test: aarch64 Server-dvd-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/946100
ID: 946104  Test: aarch64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/946104
ID: 946108  Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/946108
ID: 946126  Test: aarch64 Server-dvd-iso 
install_blivet_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/946126
ID: 946137  Test: aarch64 universal install_repository_http_variation@uefi
URL: https://openqa.fedoraproject.org/tests/946137
ID: 946142  Test: aarch64 universal install_mirrorlist_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/946142
ID: 946143  Test: aarch64 universal install_repository_http_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/946143
ID: 946144  Test: aarch64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/946144
ID: 946154  Test: aarch64 universal install_scsi_updates_img@uefi
URL: https://openqa.fedoraproject.org/tests/946154
ID: 946166  Test: aarch64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/946166
ID: 946171  Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/946171
ID: 946172  Test: aarch64 Server-dvd-iso 
install_repository_nfsiso_variation@uefi
URL: https://openqa.fedoraproject.org/tests/946172
ID: 946173  Test: aarch64 Server-dvd-iso 
install_repository_nfs_variation@uefi
URL: https://openqa.fedoraproject.org/tests/946173
ID: 946174  Test: aarch64 Server-dvd-iso install_updates_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/946174
ID: 946175  Test: aarch64 Server-dvd-iso 
install_repository_nfs_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/946175
ID: 946183  Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/946183
ID: 946184  Test: aarch64 universal install_iscsi@uefi
URL: https://openqa.fedoraproject.org/tests/946184
ID: 946185  Test: aarch64 universal install_kickstart_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/946185
ID: 946187  Test: aarch64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/946187
ID: 946201  Test: aarch64 universal install_package_set_minimal@uefi
URL: https://openqa.fedoraproject.org/tests/946201
ID: 946206  Test: aarch64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/946206
ID: 946207  Test: aarch64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/946207
ID: 946208  Test: aarch64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/946208
ID: 946210  Test: aarch64 Server-dvd-iso install_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/946210
ID: 946213  Test: aarch64 universal 

[Test-Announce] Fedora 35 Branched 20210811.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 35 Branched 20210811.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
pungi - 20210804.n.0: pungi-4.2.9-3.fc35.src, 20210811.n.0: 
pungi-4.2.10-1.fc35.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/35

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20210811.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20210811.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20210811.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20210811.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20210811.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20210811.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Branched_20210811.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1988415] perl-experimental-0.025 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1988415



--- Comment #14 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1955741] perl-experimental-0.024 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1955741



--- Comment #18 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1962451] perl-perlfaq-5.20210520 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1962451



--- Comment #15 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1989153] perl-HTTP-Tiny-0.078 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1989153



--- Comment #13 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1985448] perl-Module-CoreList-5.20210723 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1985448



--- Comment #13 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1972637] FTBFS with glibc-devel-2.33.9000-18.fc35: Installed (but unpackaged) file(s) found: /usr/lib64/perl5/features-time64.ph

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1972637



--- Comment #10 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1947703] Fix broken call to perl.prov when filenames contain spaces

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1947703



--- Comment #14 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1991543] CVE-2021-36770 perl:5.32/perl-Encode: bug in local configuration loading allows arbitrary Perl code execution placed under the current working directory [fedora-all]

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1991543



--- Comment #6 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1985448] perl-Module-CoreList-5.20210723 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1985448



--- Comment #14 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1972637] FTBFS with glibc-devel-2.33.9000-18.fc35: Installed (but unpackaged) file(s) found: /usr/lib64/perl5/features-time64.ph

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1972637



--- Comment #11 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1963116] perl-Module-CoreList-5.20210521 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1963116



--- Comment #14 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1951955] perl-Module-CoreList-5.20210420 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1951955



--- Comment #17 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1988415] perl-experimental-0.025 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1988415



--- Comment #15 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1948241] perl-perlfaq-5.20210411 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1948241



--- Comment #15 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1974093] perl-Module-CoreList-5.20210620 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1974093



--- Comment #13 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1991543] CVE-2021-36770 perl:5.32/perl-Encode: bug in local configuration loading allows arbitrary Perl code execution placed under the current working directory [fedora-all]

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1991543

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1989153] perl-HTTP-Tiny-0.078 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1989153



--- Comment #12 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1962952] perl-Module-CoreList-5.20210520 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1962952



--- Comment #17 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1974093] perl-Module-CoreList-5.20210620 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1974093



--- Comment #12 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1963116] perl-Module-CoreList-5.20210521 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1963116



--- Comment #13 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1962952] perl-Module-CoreList-5.20210520 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1962952



--- Comment #16 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1950578] perl-version-0.9929 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1950578



--- Comment #14 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1955741] perl-experimental-0.024 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1955741



--- Comment #17 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1962451] perl-perlfaq-5.20210520 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1962451



--- Comment #14 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1950578] perl-version-0.9929 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1950578



--- Comment #13 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1951955] perl-Module-CoreList-5.20210420 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1951955



--- Comment #16 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1941280] perl-Module-CoreList-5.20210320 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1941280



--- Comment #26 from Fedora Update System  ---
FEDORA-MODULAR-2021-0a8bfca173 has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-0a8bfca173

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1948241] perl-perlfaq-5.20210411 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1948241



--- Comment #14 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1947703] Fix broken call to perl.prov when filenames contain spaces

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1947703



--- Comment #13 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1941280] perl-Module-CoreList-5.20210320 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1941280



--- Comment #25 from Fedora Update System  ---
FEDORA-MODULAR-2021-6903559673 has been pushed to the Fedora 34 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-6903559673

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Unretiring rubygem-middleware

[Pavel Valena]

I intend to unretire rubygem-middleware.

https://src.fedoraproject.org/rpms/rubygem-middleware/pull-request/1

https://bugzilla.redhat.com/show_bug.cgi?id=1992914

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1992901] New: perl-CPAN-FindDependencies-3.10 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1992901

Bug ID: 1992901
   Summary: perl-CPAN-FindDependencies-3.10 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPAN-FindDependencies
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: i...@cicku.me, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.10
Current version/release in rawhide: 3.09-2.fc35
URL: http://search.cpan.org/dist/CPAN-FindDependencies/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/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/2729/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] Fedora 35 Boost 1.76 rebuilds starting in a side tag

[Thomas Rodgers]

FTBFS issues inline -

On Wed, Aug 11, 2021 at 3:01 AM Jonathan Wakely  wrote:

> On Wed, 11 Aug 2021 at 10:21, Jonathan Wakely  wrote:
> >
> > On Tue, 10 Aug 2021 at 18:23, Benjamin Beasley wrote:
> > >
> > > It looks like none of the packages I maintain or co-maintain that
> depend on boost-devel were rebuilt before the side tag was merged.
> > >
> > > Some (luminance-hdr, cpp-hocon) had automated FTI bugs filed; these
> were fixed by a manual rebuild on my part. Another (usd) should be in the
> same boat once some unrelated problems causing FTBFS are resolved.
> > >
> > > Others (cairomm/cairomm1.16) presumably used only header-only parts of
> Boost, and were silently continuing to use the old Boost. I rebuilt these
> as well.
> >
> > Strictly speaking, they don't need to be rebuilt. They don't have any
> > dependency on the version of boost that the rest of the distro uses.
> > In some cases it's possible that another package that depends on boost
> > libs and cairomm libs will encounter some incompatibility between the
> > Boost releases, but this doesn't happen often in practice.
> >
> > When we update boost in rawhide we never rebuild the packages that
> > only depend on boost headers from boost-devel (although often they get
> > rebuilt anyway by a mass rebuild after the boost update, but the mass
> > rebuild happened first this time).
>
> I suppose we could add to the set of rebuilds by doing a repoquery for
> packages which require boost-devel and also provide %{_libdir}/lib*.so
> files (or a -devel package). That would ensure that any boost types in
> the API and ABI of those shared libraries are using the new versions.
> For standalone applications that don't provide any libraries for other
> packages to use, there's no need to rebuild them.
>
> > > It’s probably worth looking into the process for finding and
> rebuilding dependent packages to see why these were not rebuilt, as there
> must be many other packages that also should have been rebuilt but were not.
> >
> >
> > The process to find them is a reqoquery using --whatrequires
> > libboost\* and is correct. It did find all three of luminance-hdr,
> > cpp-hocon and usd, so I'm not sure why rebuilds weren't issued for
> > them. I'll check to see if that happened to other packages. Thanks for
> > pointing it out.
>
> The packages that didn't get rebuilt are:
>
> 0ad *
>
https://bugzilla.redhat.com/show_bug.cgi?id=1992882


> OpenImageIO ***
> blender ***
> botan *
>
https://bugzilla.redhat.com/show_bug.cgi?id=1992883


> condor *
>
https://bugzilla.redhat.com/show_bug.cgi?id=1992884


> cpp-hocon
> fawkes **
> fcitx5-chinese-addons *
>
libime dependency, libime not built against boost 1.76.0, should be **


> freecad *
>
https://bugzilla.redhat.com/show_bug.cgi?id=1991078

gazebo **
> gpick *
>
no build?


> gqrx *
>
gnu-radio dependency, all of gnu-radio and gr-* need a rebuild, should be**


> hugin *
>
 https://bugzilla.redhat.com/show_bug.cgi?id=1991049


> libreoffice *
>
successfully rebuilt libreoffice-7.1.5.2-4.fc35
 2021-08-11
06:40:30


> luminance-hdr
> luxcorerender ***
> ogre ***
> openms *
>
https://bugzilla.redhat.com/show_bug.cgi?id=1992887


> openshadinglanguage
> opentrep *
>
https://bugzilla.redhat.com/show_bug.cgi?id=1992889


> pcl *
>
https://bugzilla.redhat.com/show_bug.cgi?id=1992893


> python-graph-tool *
>
https://bugzilla.redhat.com/show_bug.cgi?id=1992610


> rb_libtorrent *
>


> shiny ***
> sourcextractor++ *
>
https://bugzilla.redhat.com/show_bug.cgi?id=1992898


> springlobby **
> usd
> vtk *
>
https://bugzilla.redhat.com/show_bug.cgi?id=1992899


>
> The ones marked with a single * were submitted but failed to build
> (some have now been fixed, some need a FTBFS bug filed).
>
> The ones marked ** depend on one of the ones that failed, so are blocked.
>
> The ones marked with *** couldn't be built because a dependency
> failed, but should have been resubmitted after the dep was fixed.
> Those are all done now except blender, which was already FTBFS before
> the boost update, and luxcorerender and shiny, which I'm rebuilding
> now, and gqrx which seems to be broken by the codec2 update.
>
> The rest were not submitted for a rebuild, for some reason. That's
> cpp-hocon, luminance-hdr, openshadinglanguage, and usd. I'm not sure
> why they didn't get submitted.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- 

Re: deltarpm usefulness?

[Fabio Valentini]

On Wed, Aug 11, 2021 at 11:03 PM Kevin Fenzi  wrote:
>
> On Wed, Aug 11, 2021 at 10:03:50PM +0200, Marek Marczykowski-Górecki wrote:
> > Hi all,
> >
> > I think deltarpm is not really useful anymore:
> >  - there are very few drpm files in the repository, see for example:
> >
> > https://download.fedoraproject.org/pub/fedora/linux/updates/34/Everything/x86_64/drpms/
> >
> > https://download.fedoraproject.org/pub/fedora/linux/updates/33/Everything/x86_64/drpms/
> >  - those that actually are there, are mostly about small packages anyway
> >  - personally, I haven't seen it being used for a long time
> >  - there is also argument that people's connection bandwidth nowadays
> >tends to be fast enough to make the package rebuilding actually
> >slower than downloading the whole package (but that really vary between
> >different installations)
>
> Yeah. ;(

I actually wanted to bring up this topic a while ago, but then got side-tracked.
In my experience, drpms have negligible effect on package downloads for updates.

To add some anecdata, these are the stats from today's "dnf
distro-sync" transaction on my laptop, with a few days' worth of
updates+updates-testing changes:

Install4 Packages
Upgrade  161 Packages
Remove 3 Packages

Total download size: 751 M

[DRPM 1/3] python3-tqdm-4.61.1-1.fc34_4.62.0-1.fc34.noarch.drpm: done
[DRPM 2/3] perl-Module-CoreList-5.20210620-1.fc34_5.20210723-1.fc34.noarch.drpm:
done
[DRPM 3/3] binutils-2.35.1-41.fc34_2.35.2-4.fc34.x86_64.drpm: done

Delta RPMs reduced 750.9 MB of updates to 747.5 MB (0.4% saved)

This about matches what I've been seeing on this laptop and my main
machine for many months.
Either there's 0-2% savings at most, or a few % of additional data
downloads due to failed downloads or failed rpm reconstructions.

I wonder why there's so few drpms in most transactions I see?
Does this system not prioritize packages, like, those that are
installed on all variants, or installed by default on Workstation?

The way it is right now, I could turn drpms off entirely, and probably
not change the download size at all (because savings are small and are
cancelled out by failure cases), and save some CPU time. Is it really
worth it keeping all that infrastructure for drpms around, if they
doesn't actually provide any benefit wrt. amount of data to download,
and actually increases CPU usage?

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora rawhide compose report: 20210806.n.0 changes

[Adam Williamson]

On Wed, 2021-08-11 at 14:13 -0700, Kevin Fenzi wrote:
> On Wed, Aug 11, 2021 at 09:42:48AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Aug 06, 2021 at 03:38:38PM +, Fedora Rawhide Report wrote:
> > > OLD: Fedora-Rawhide-20210805.n.0
> > > NEW: Fedora-Rawhide-20210806.n.0
> > > Package:  dummy-test-package-gloster-0-4903.fc35
> > > Old package:  dummy-test-package-gloster-0-4884.fc35
> > > Summary:  Dummy Test Package called Gloster
> > > RPMs: dummy-test-package-gloster
> > > Size: 300.96 KiB
> > > Size change:  1.09 KiB
> > 
> > Is the reverse order intentional here?
> > Also, why all the rebuilds?
> 
> This is the 'monitor gating' application. 
> 
> https://pagure.io/fedora-ci/monitor-gating
> 
> So, it does builds all the time to confirm that the end to end pipeline
> is working as expected. 

It might be interesting to see if we could filter these out of report
mails like this one, though. They do create a lot of noise.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

orphaning rarian

[Mukundan Ragavan]

I am orphaning rarian (https://src.fedoraproject.org/rpms/rarian). As 
far as I can tell, nothing in Fedora depends on it anymore.


# dnf repoquery --releasever rawhide --whatrequires librarian\*
Last metadata expiration check: 0:02:50 ago on Wed 11 Aug 2021 06:03:30 
PM EDT.

rarian-compat-0:0.8.1-27.fc34.x86_64
rarian-devel-0:0.8.1-27.fc34.i686
rarian-devel-0:0.8.1-27.fc34.x86_64


Last upstream release was in 2008 and this is currently FTBFS on 
rawhide/F35.



Mukundan.
--
GPG Key: E5C8BC67



OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Review swaps

[Jerry James]

Hi all,

Who would like to swap package reviews?  I need these 6:

fontawesome5-fonts
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1989300
This one has been mentioned previously on this mailing list.  It is
blocking the review of python-pydata-sphinx-theme, which is needed to
update python-networkx.

flintqs
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1992877
Currently bundled with sagemath, but useful in its own right.

gp2c
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1992878
A PARI/GP script to C converter, needed by sagemath.

pari-nflistdata
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1992879
Data tables for PARI, needed by sagemath.

pari-nflistdata
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1992880
More data tables for PARI, needed by sagemath.

python-pari-jupyter
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1992881
A Jupyter kernel for PARI/GP, needed by sagemath.

Regards,
-- 
Jerry James
http://www.jamezone.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: deltarpm usefulness?

[Marek Marczykowski-Górecki]

On Wed, Aug 11, 2021 at 02:02:39PM -0700, Kevin Fenzi wrote:
> drpms work by downloading the delta, then using it + the version you
> have installed to recreate the signed rpm (just like you downloaded the
> full signed update) 

I'm worried about this process specifically. It does rather heavy
parsing on a drpm file, before having a chance to verify the signature.

> and then the gpg signature is checked of that full rpm,
> just like one you downloaded. If the drpm is tampered with it won't
> reassemble and it will fall back to the full signed rpm.
> 
> Additionally, fedoraproject.org has dnssec enabled, so if you are
> worried, do enable that to avoid hyjacking.

Ok, so there are several things here:
1. DNSSEC protects against only some of the threats. It won't (on its
   own) help if someone intercepts my TCP connection when I download
   updates via wifi in a coffee shop.

2. HTTPS provides _much_ better protection against various kind of MitM
   attacks, but in some threat models is still not enough:
   - It protects only the connection to the server, not integrity of the
 mirrors.fedoraproject.org machine itself (if someone manages to
 exploit a hypothetical bug in the web server there, it's game
 over). 
   - Furthermore, there is a wildcard cert for *.fedoraproject.org, so
 in practice it's enough to break into any of the servers (having
 key for that cert), to make MitM attack feasible.
   - There are over hundred trusted CAs in the default setup. It takes
 just one compromised/malicious to issue a duplicate cert. Both
 scenarios has happened to some CAs in the past.

3. Finally, this is about just Fedora repositories. It doesn't help for
much for dozen other repositories that user is free to add. Some may
even use plain HTTP (and rely just on package signatures)!

While I still think disabling deltarpm by default is a good idea, in
absence of signed metadata there are a few things that could improve the
situation:
 - Pin specific CA in the repo config (sslcacert option)
 - Add CAA record for the same purpose
 - Avoid wildcard cert for such critical purpose, but to make it really
   worth it, the wildcard cert for the domain would need to not exists -
   rather impractical thing. Maybe use separate domain then
   (getfedora.org?)?
 - Some would propose to use own CA to avoid trusting the whole
   DigiCert (or other single CA), but personally I think the downsides
   overweights the benefits

And this is just about the connection part, not about integrity of the
server itself... BTW, I do hope that signing keys are stored somewhere
else.


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to rebuild package using autospec

[Richard Shaw]

On Wed, Aug 11, 2021 at 4:33 PM Ben Beasley  wrote:

> I managed to build usd in Rawhide
> (https://koji.fedoraproject.org/koji/buildinfo?buildID=1817418). Expect
> a build for F35, and updates to the relevant bug reports, in the next
> couple of hours.
>

Awesome! That was the last dep to rebuild Blender with OpenEXR 3.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to rebuild package using autospec

[Ben Beasley]

I managed to build usd in Rawhide 
(https://koji.fedoraproject.org/koji/buildinfo?buildID=1817418). Expect 
a build for F35, and updates to the relevant bug reports, in the next 
couple of hours.


– Ben

On 8/11/21 3:40 PM, Ben Beasley wrote:
Your build did end up failing due to the glibc 2.34 incompatibility 
(https://koji.fedoraproject.org/koji/taskinfo?taskID=73678362).


See https://github.com/PixarAnimationStudios/USD/issues/1592 for details 
on what’s happening. It’s likely that a significant patch to USD will be 
required to fix this properly.


I did manage to get a scratch build to link successfully by re-enabling 
jemalloc, before it failed due to the rpmautospec changelog somehow 
getting mixed up with the files sections for no obvious reason 
(https://koji.fedoraproject.org/koji/taskinfo?taskID=73681239).


I’ll keep looking at this as I have time and see if I can get a 
successful build. It will take a little while even in the best case, as 
each scratch build attempt takes well over an hour.


– Ben

On 8/11/21 12:17 PM, Richard Shaw wrote:
On Wed, Aug 11, 2021 at 11:04 AM Luya Tshimbalanga 
mailto:l...@fedoraproject.org>> wrote:


    Scratch build result:

    F36: https://koji.fedoraproject.org/koji/taskinfo?taskID=73676974
    

    F35: https://koji.fedoraproject.org/koji/taskinfo?taskID=73676978
    

    It seems the issue with glibc 2.34 got resolved. libboost 1.7.6 seems
    working as well. Can someone build usd as I lack the time to do so?


I'll kick off a build, I need it anyway.

Thanks,
Richard

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora rawhide compose report: 20210806.n.0 changes

[Kevin Fenzi]

On Wed, Aug 11, 2021 at 09:42:48AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Aug 06, 2021 at 03:38:38PM +, Fedora Rawhide Report wrote:
> > OLD: Fedora-Rawhide-20210805.n.0
> > NEW: Fedora-Rawhide-20210806.n.0
> > Package:  dummy-test-package-gloster-0-4903.fc35
> > Old package:  dummy-test-package-gloster-0-4884.fc35
> > Summary:  Dummy Test Package called Gloster
> > RPMs: dummy-test-package-gloster
> > Size: 300.96 KiB
> > Size change:  1.09 KiB
> 
> Is the reverse order intentional here?
> Also, why all the rebuilds?

This is the 'monitor gating' application. 

https://pagure.io/fedora-ci/monitor-gating

So, it does builds all the time to confirm that the end to end pipeline
is working as expected. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Help with gdal sphinx doc build failure

[Dan Čermák]

Orion Poplawski  writes:

> On 8/11/21 2:24 PM, Dan Čermák wrote:
>> Hi Orion,
>> 
>> Orion Poplawski  writes:
>> 
>>> I've reported: https://bugzilla.redhat.com/show_bug.cgi?id=1992426
>>>
>
>>> This appears to be due to breathe not handling parsing errors.  There is
>>> a PR upstream at https://github.com/michaeljones/breathe/pull/711 but it
>>> doesn't apply cleanly to the current release so I haven't been able to
>>> test it.
>> 
>> I've applied the patch from the PR to breathe and made a scratch build:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=73684859
>> 
>> Could you give that one a try?
>
> That appears to do the trick.  Can we get that built for rawhide and f35?

Builds are already running and should finish in a few minutes.


Cheers,

Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: deltarpm usefulness?

[Kevin Fenzi]

On Wed, Aug 11, 2021 at 10:03:50PM +0200, Marek Marczykowski-Górecki wrote:
> Hi all,
> 
> I think deltarpm is not really useful anymore:
>  - there are very few drpm files in the repository, see for example:
>
> https://download.fedoraproject.org/pub/fedora/linux/updates/34/Everything/x86_64/drpms/
>
> https://download.fedoraproject.org/pub/fedora/linux/updates/33/Everything/x86_64/drpms/
>  - those that actually are there, are mostly about small packages anyway
>  - personally, I haven't seen it being used for a long time
>  - there is also argument that people's connection bandwidth nowadays
>tends to be fast enough to make the package rebuilding actually
>slower than downloading the whole package (but that really vary between
>different installations)

Yeah. ;( 

>  - and most importantly: drpm files are - by design - processed before
>checking the package signature, which exposes rather big attack
>surface(*)

Thats not the case. 

> Can deltarpm be disabled by default? In the few cases where it's
> actually useful (if there are any...), user is free to enable it, but
> the default would be significantly more secure this way.

I do think we should drop drpms or make them more useful, but I don't
think there's any security angle here. (see below)
> 
> (*) it is integrity protected via a hash in the repository metadata, but
> repository metadata in Fedora are still not signed - so this all heavily
> depends on the integrity of the [HTTPS connection to]
> mirrors.fedoraproject.org server (or any of CAs trusted by the system) -
> a rather fragile single point of failure.

drpms work by downloading the delta, then using it + the version you
have installed to recreate the signed rpm (just like you downloaded the
full signed update) and then the gpg signature is checked of that full rpm,
just like one you downloaded. If the drpm is tampered with it won't
reassemble and it will fall back to the full signed rpm.

Additionally, fedoraproject.org has dnssec enabled, so if you are
worried, do enable that to avoid hyjacking.

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Help with gdal sphinx doc build failure

[Orion Poplawski]

On 8/11/21 2:24 PM, Dan Čermák wrote:

Hi Orion,

Orion Poplawski  writes:


I've reported: https://bugzilla.redhat.com/show_bug.cgi?id=1992426




This appears to be due to breathe not handling parsing errors.  There is
a PR upstream at https://github.com/michaeljones/breathe/pull/711 but it
doesn't apply cleanly to the current release so I haven't been able to
test it.


I've applied the patch from the PR to breathe and made a scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=73684859

Could you give that one a try?


That appears to do the trick.  Can we get that built for rawhide and f35?

Thanks!

--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Help with gdal sphinx doc build failure

[Dan Čermák]

Hi Orion,

Orion Poplawski  writes:

> I've reported: https://bugzilla.redhat.com/show_bug.cgi?id=1992426
>
> gdal docs are failing to build with:
>
>
>
> Exception occurred:
>
>File "/usr/lib/python3.10/site-packages/sphinx/util/cfamily.py", line 
> 275, in fail
>
>  raise self._make_multi_error(errors, '')
>
> sphinx.util.cfamily.DefinitionError: Invalid C++ declaration: Expected 
> identifier in nested name. [error at 8]
>
>typename...
>
>^
>
>
>
> This appears to be due to breathe not handling parsing errors.  There is 
> a PR upstream at https://github.com/michaeljones/breathe/pull/711 but it 
> doesn't apply cleanly to the current release so I haven't been able to 
> test it.

I've applied the patch from the PR to breathe and made a scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=73684859

Could you give that one a try?


Cheers,

Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

deltarpm usefulness?

[Marek Marczykowski-Górecki]

Hi all,

I think deltarpm is not really useful anymore:
 - there are very few drpm files in the repository, see for example:
   
https://download.fedoraproject.org/pub/fedora/linux/updates/34/Everything/x86_64/drpms/
   
https://download.fedoraproject.org/pub/fedora/linux/updates/33/Everything/x86_64/drpms/
 - those that actually are there, are mostly about small packages anyway
 - personally, I haven't seen it being used for a long time
 - there is also argument that people's connection bandwidth nowadays
   tends to be fast enough to make the package rebuilding actually
   slower than downloading the whole package (but that really vary between
   different installations)
 - and most importantly: drpm files are - by design - processed before
   checking the package signature, which exposes rather big attack
   surface(*)

Can deltarpm be disabled by default? In the few cases where it's
actually useful (if there are any...), user is free to enable it, but
the default would be significantly more secure this way.

(*) it is integrity protected via a hash in the repository metadata, but
repository metadata in Fedora are still not signed - so this all heavily
depends on the integrity of the [HTTPS connection to]
mirrors.fedoraproject.org server (or any of CAs trusted by the system) -
a rather fragile single point of failure.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Eclipse IDE packages and friends orphaned

[Aleksandar Kurtakov]

On Wed, Aug 11, 2021 at 9:45 PM Frank Ch. Eigler  wrote:

> Aleksandar Kurtakov  writes:
>
> > List of packages orphaned (all were maintained for the sake of Eclipse
> > stack):
> > * eclipse
> > [...]
>
> Could upstream eclipse make an effort to reduce its dependency
> footprint?
>

Everything is possible if someone finds the time for it.


>
> - FChE
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to rebuild package using autospec

[Ben Beasley]

Your build did end up failing due to the glibc 2.34 incompatibility 
(https://koji.fedoraproject.org/koji/taskinfo?taskID=73678362).


See https://github.com/PixarAnimationStudios/USD/issues/1592 for details 
on what’s happening. It’s likely that a significant patch to USD will be 
required to fix this properly.


I did manage to get a scratch build to link successfully by re-enabling 
jemalloc, before it failed due to the rpmautospec changelog somehow 
getting mixed up with the files sections for no obvious reason 
(https://koji.fedoraproject.org/koji/taskinfo?taskID=73681239).


I’ll keep looking at this as I have time and see if I can get a 
successful build. It will take a little while even in the best case, as 
each scratch build attempt takes well over an hour.


– Ben

On 8/11/21 12:17 PM, Richard Shaw wrote:
On Wed, Aug 11, 2021 at 11:04 AM Luya Tshimbalanga 
mailto:l...@fedoraproject.org>> wrote:


Scratch build result:

F36: https://koji.fedoraproject.org/koji/taskinfo?taskID=73676974


F35: https://koji.fedoraproject.org/koji/taskinfo?taskID=73676978


It seems the issue with glibc 2.34 got resolved. libboost 1.7.6 seems
working as well. Can someone build usd as I lack the time to do so?


I'll kick off a build, I need it anyway.

Thanks,
Richard

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Use of sed in spec files

[Dan Čermák]

Hi Richard,

Richard Shaw  writes:

> It's quite common to need to do some minor manipulation in a spec file and
> you decide to use sed instead of patching so you don't have to update it
> every release.
>
> The problem is that sed returns 0 whether it actually did anything or not.
>
> Thinking about this I did some searching and you can use custom exit
> codes[1].

Nice find!

> The question is, does anyone think this is important? Important enough to
> have guidelines around? Sure it doesn't hurt anything (unless the search
> term is added in another context) but it does lead to spec file cruft.

I think we should mention this in the guidelines and let packagers
decide whether they want to use this or not, as should be able to judge
this best by themselves.


Cheers,

Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Eclipse IDE packages and friends orphaned

[Frank Ch. Eigler]

Aleksandar Kurtakov  writes:

> List of packages orphaned (all were maintained for the sake of Eclipse
> stack):
> * eclipse
> [...]

Could upstream eclipse make an effort to reduce its dependency
footprint?

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The Death of Java (packages)

[Sérgio Basto]

On Wed, 2021-08-11 at 13:26 -0400, Stephen Snow wrote:
> On Wed, 2021-08-11 at 18:44 +0200, Emmanuel Seyman wrote:
> > * Stephen Snow [11/08/2021 12:08] :
> > > 
> > > > > Even tried the review route, which is also beset with arbitrary
> > > > > obstacles.
> > > > 
> > > Wasn't able to download the build via the link provided.
> > 
> > ???
> > Building a package with mock will create the build in
> > /var/lib/mock/...
> > No download should be required.
> > 
> Yup, my mistake, I was able to build.
> I'll try the process again by looking through the review's wanted list.
> 

Also you may fork some packages at https://src.fedoraproject.org/ and
do pull requests to show your ability as packager maintainer 


> Thanks for responding
> 
> Stephen
> 
> > Emmanuel
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The Death of Java (packages)

[Miro Hrončok]

On 11. 08. 21 19:51, Vitaly Zaitsev via devel wrote:


If the package was orphaned more than 8 weeks ago, you must open a new releng 
ticket.


https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/


Correction: If the package was *retired* more than 8 weeks ago.

--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: libgps soname bump (gpsd-3.23)

[Björn 'besser82' Esser]

Am Mittwoch, dem 11.08.2021 um 18:06 +0200 schrieb Björn 'besser82'
Esser:
> Am Mittwoch, dem 11.08.2021 um 17:20 +0200 schrieb Miroslav Lichvar:
> > libgps provided by the gpsd package had another API and ABI break.
> > The
> > following packages need to be rebuilt:
> > 
> > collectd
> > direwolf
> > foxtrotgps
> > marble
> > plasma-workspace
> > vfrnav
> > viking
> > 
> > I tried to rebuild them locally and it seems only direwolf needs a
> > patch. It's here:
> > https://fedorapeople.org/~mlichvar/tmp/gpsd/direwolf-gpsapi12.patch
> > 
> > The new gpsd package is built in a rawhide and f35 sidetag.
> > Please build your packages with:
> > 
> > fedpkg build --target=f36-build-side-44504
> > fedpkg build --target=f35-build-side-44506
> > 
> > If a proven packager is willing to take care all of the packages,
> > please let us know.
> 
> 
> I'll take care of the rebuilds as a proven packager.
> 
> Cheers
> Björn


All packages have been rebuilt successfully, except for vfrnav, which
fails for a segfault in inkscape during the testsuite.

Both sidetags can be merged now, as vfrnav hasn't been built
successfully for a longer period of time, including the recent mass-
rebuild for fc35.

Cheers
Björn


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The Death of Java (packages)

[Ben Beasley]

I think becoming a packager is not as complicated as you’ve written. To 
become a packager, you must convince a packager sponsor to sponsor you. 
That’s all; there is no rule about how to do the convincing.


Sponsors want to be confident that you understand and are likely to 
follow the packaging guidelines. Submitting PR’s, submitting new 
packages for review (to be imported after you are sponsored), and doing 
unofficial package reviews are three common and suggested ways to 
establish a track record, but a sponsor may choose to sponsor a new 
packager (or not!) for any reason whatsoever.


In my opinion, rescuing orphaned packages tends to be one of the harder 
packaging tasks. Many packages are orphaned for lack of time, so they 
often have lingering obsolete practices that ought to be brought into 
compliance with current guidelines. Many others are orphaned because 
they have problems the previous packager found too difficult, 
time-consuming, or frustrating to fix. Working on orphaned packages can 
be a good way to learn quickly and a great way to contribute, but I 
think new packagers are likely to need more mentoring for these 
packages, not less.


On 8/11/21 11:55 AM, Stephen Snow wrote:

Okay,
So to become a packager you have to
  - Get someone to sponsor you as a packager
  - Review existing packages for others
  - take over an orphaned package
  - introduce a package to Fedora  Linux that needs to get approval to
be packaged
  - some other criteria I forgot after reading so many linked documents


I tried to "take" an orphaned package ... can't not a packager, so I
tried to do a review, and even though I appear to be part of the group,
I couldn't even access the review build because apparently I don't have
the rights.

My point is yes, it is requiring effort and it should but not to the
extent of stonewalling contributions, and largely because the
guidelines are confusing, it is a bit like reading a hand drawn map
while driving IMO.

So, back to orphaned packages, if a person from the community is signed
up, signed the CA, the CoC, is a member of the appropriate groups, that
person should be able to volunteer to take on orphaned packages, at
least on a trila basis till they need no handholding. The deesire to
contribute should be the bar to contribute is my point. If technical
requirements are not being met, then they would be removed as packager
and basically timed out for a specific time till they get the
opportunity to try packaging again. However, if they succeed, then
great for all, more contributors, less workload across the board. I
understand that RPM packaging is a complex process, and creating Fedora
Linux is a large task, but for new contributors how are they to learn
the process, if the gate keepers are too efficient?

Regards,
and still hoping to be a packager  someday

Stephen

  
On Wed, 2021-08-11 at 14:16 +0200, Vitaly Zaitsev via devel wrote:

On 11/08/2021 13:37, Stephen Snow wrote:

making joining the packaging group(s) a bit more open would go a
long way to  garnering more packagers IMO


New contributors must know at least the Fedora packaging guidelines.
This is the minimum barrier.

use COPR. Simple and easy.

--
Sincerely,
    Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Use of sed in spec files

[Vitaly Zaitsev via devel]

On 11/08/2021 19:47, Richard Shaw wrote:
I agree, but the real question is, how do you determine when it's no 
longer necessary?


Manual checks on major upstream releases.

I always try to send a pull request with fixes. So I'll remove the sed 
hack when my PR is merged.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The Death of Java (packages)

[Vitaly Zaitsev via devel]

On 11/08/2021 17:55, Stephen Snow wrote:

- Get someone to sponsor you as a packager
- Review existing packages for others


Package sponsors should make sure new contributors are familiar with RPM 
packaging and Fedora guidelines.



introduce a package to Fedora  Linux that needs to get approval to
be packaged


If you are a member of the packagers group, you can simply press a "Take 
ownership" button.


If the package was orphaned more than 8 weeks ago, you must open a new 
releng ticket.


https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Use of sed in spec files

[Richard Shaw]

On Wed, Aug 11, 2021 at 12:46 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 11/08/2021 19:39, Richard Shaw wrote:
> > It's quite common to need to do some minor manipulation in a spec file
> > and you decide to use sed instead of patching so you don't have to
> > update it every release.
>
> Patching is always painful. You need to rebase your patches on every
> upstream release.
>
> I always use sed for trivial fixes.
>

I agree, but the real question is, how do you determine when it's no longer
necessary?

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Use of sed in spec files

[Vitaly Zaitsev via devel]

On 11/08/2021 19:39, Richard Shaw wrote:
It's quite common to need to do some minor manipulation in a spec file 
and you decide to use sed instead of patching so you don't have to 
update it every release.


Patching is always painful. You need to rebase your patches on every 
upstream release.


I always use sed for trivial fixes.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Use of sed in spec files

[Richard Shaw]

It's quite common to need to do some minor manipulation in a spec file and
you decide to use sed instead of patching so you don't have to update it
every release.

The problem is that sed returns 0 whether it actually did anything or not.

Thinking about this I did some searching and you can use custom exit
codes[1].

The question is, does anyone think this is important? Important enough to
have guidelines around? Sure it doesn't hurt anything (unless the search
term is added in another context) but it does lead to spec file cruft.

As I run across them in my packages I plan to update them.

Thanks,
Richard

[1]
https://stackoverflow.com/questions/15965073/return-value-of-sed-for-no-match/15966279
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The Death of Java (packages)

[Stephen Snow]

On Wed, 2021-08-11 at 18:44 +0200, Emmanuel Seyman wrote:
> * Stephen Snow [11/08/2021 12:08] :
> > 
> > > > Even tried the review route, which is also beset with arbitrary
> > > > obstacles.
> > > 
> > Wasn't able to download the build via the link provided.
> 
> ???
> Building a package with mock will create the build in
> /var/lib/mock/...
> No download should be required.
> 
Yup, my mistake, I was able to build.
I'll try the process again by looking through the review's wanted list.

Thanks for responding

Stephen

> Emmanuel
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The Death of Java (packages)

[Emmanuel Seyman]

* Stephen Snow [11/08/2021 12:08] :
>
> > > Even tried the review route, which is also beset with arbitrary
> > > obstacles.
> > 
> Wasn't able to download the build via the link provided.

???
Building a package with mock will create the build in /var/lib/mock/...
No download should be required.

Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Can comps handle virtual provides?

[Miro Hrončok]

Hello.

We have recently renamed pypy3 to pypy3.7.
As a result, the pypy3-devel package is now called pypy3.7-devel, however it 
still provides pypy3-devel.


pypy3-devel is part of the python-classroom comps group in comps-f36.xml.in.

Normally, I'd rename the package there, but in this case I'd rather keep 
"pypy3-devel" as it requires less maintenance. Does it work with virtual provides?


Thanks,
--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to rebuild package using autospec

[Richard Shaw]

On Wed, Aug 11, 2021 at 11:04 AM Luya Tshimbalanga 
wrote:

> Scratch build result:
>
> F36: https://koji.fedoraproject.org/koji/taskinfo?taskID=73676974
>
> F35: https://koji.fedoraproject.org/koji/taskinfo?taskID=73676978
>
> It seems the issue with glibc 2.34 got resolved. libboost 1.7.6 seems
> working as well. Can someone build usd as I lack the time to do so?
>

I'll kick off a build, I need it anyway.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The Death of Java (packages)

[Stephen Snow]

On Wed, 2021-08-11 at 14:20 +0200, Emmanuel Seyman wrote:
> * Stephen Snow [11/08/2021 11:37] :
> > 
> > I feel the frustration you are expressing, and would like to help,
> > nut
> > apparently I don't meet the Fedora Packaging standards.
> 
> I'm curious as to what happened...
Not sure what happened really, I had asked via this email list a few
times over the past to become a package maintainer of a couple of
orphaned java related packages, and got no response. I couldn't use the
take button as it noted I didn't have the rights to do it (still that
way on Pagure for me).
> 
> > Even tried the review route, which is also beset with arbitrary
> > obstacles.
> 
Wasn't able to download the build via the link provided.

> Again, what happened? Can you point us to those reviews?
> 
> > I will keep trying because that is in my nature, but making joining
> > the
> > packaging group(s) a bit more open would go a long way to garnering
> > more
> > packagers IMO.
> 
> What changes to the process would you like to see made?
> 
Please see my repsonse to Vitaly. I think the barrier to getting into
this should be far lower as regarding the following ...
-New contributor asks for sponsorship, someone able to gives it
-new contributor is now a packager and can "take" any orphaned package
-new contributor fails as packager after one release cycle, times out
for one more release cycle before allowed to try to contribute again.
-or new contributor does well, with handholding, and continues the
learning process
- or they do great, and need no handholding, and take on more work load
readily

I really would like to point to how easy it is to become an editor of
Fedora Magazine as an example of the ease with which contributors
should be onboarded.

As one more note from me on this, the packaging guidelines are an
evolved document from years of best practices and failures. Maybe it is
time to rethink the guidelines and particularly the entrance criteria
to reflect today's Fedora Linux.

Regards,
Stephen

> Emmanuel
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: libgps soname bump (gpsd-3.23)

[Björn 'besser82' Esser]

Am Mittwoch, dem 11.08.2021 um 17:20 +0200 schrieb Miroslav Lichvar:
> libgps provided by the gpsd package had another API and ABI break. The
> following packages need to be rebuilt:
> 
> collectd
> direwolf
> foxtrotgps
> marble
> plasma-workspace
> vfrnav
> viking
> 
> I tried to rebuild them locally and it seems only direwolf needs a
> patch. It's here:
> https://fedorapeople.org/~mlichvar/tmp/gpsd/direwolf-gpsapi12.patch
> 
> The new gpsd package is built in a rawhide and f35 sidetag.
> Please build your packages with:
> 
> fedpkg build --target=f36-build-side-44504
> fedpkg build --target=f35-build-side-44506
> 
> If a proven packager is willing to take care all of the packages,
> please let us know.


I'll take care of the rebuilds as a proven packager.

Cheers
Björn


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to rebuild package using autospec

[Luya Tshimbalanga]

Scratch build result:

F36: https://koji.fedoraproject.org/koji/taskinfo?taskID=73676974

F35: https://koji.fedoraproject.org/koji/taskinfo?taskID=73676978

It seems the issue with glibc 2.34 got resolved. libboost 1.7.6 seems 
working as well. Can someone build usd as I lack the time to do so?


On 2021-08-10 9:59 p.m., Ben Beasley wrote:

In general, if you want to rebuild an rpmautospec package with no spec file 
changes, you can do an empty git commit like this:

git commit —allow-empty -m 'Rebuild for foolib 3.14'

Then “fedpkg build” as usual.

The case of usd is not quite so simple. I tried to rebuild it as a 
co-maintainer earlier today. I ran into a problem with OpenEXR 3, committed a 
workaround, and then ran into an incompatibility with glibc 2.34 (it uses 
deprecated allocation hooks that were removed). I’m hoping the primary 
maintainer will take the lead on that. More details are in 
https://bugzilla.redhat.com/show_bug.cgi?id=1991892#c3. As of now, usd is still 
FTBFS.

– Ben

On Tue, Aug 10, 2021, at 11:31 PM, Richard Shaw wrote:

I'm trying to rebuild usd for the boost 1.76 update (I also had a few
packages with BZ filed without a rebuild attempt) but I have no idea
how to.

What is the magic incantation for this case?

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The Death of Java (packages)

[Stephen Snow]

Okay,
So to become a packager you have to 
 - Get someone to sponsor you as a packager
 - Review existing packages for others
 - take over an orphaned package
 - introduce a package to Fedora  Linux that needs to get approval to
be packaged
 - some other criteria I forgot after reading so many linked documents


I tried to "take" an orphaned package ... can't not a packager, so I
tried to do a review, and even though I appear to be part of the group,
I couldn't even access the review build because apparently I don't have
the rights.

My point is yes, it is requiring effort and it should but not to the
extent of stonewalling contributions, and largely because the
guidelines are confusing, it is a bit like reading a hand drawn map
while driving IMO. 

So, back to orphaned packages, if a person from the community is signed
up, signed the CA, the CoC, is a member of the appropriate groups, that
person should be able to volunteer to take on orphaned packages, at
least on a trila basis till they need no handholding. The deesire to
contribute should be the bar to contribute is my point. If technical
requirements are not being met, then they would be removed as packager
and basically timed out for a specific time till they get the
opportunity to try packaging again. However, if they succeed, then
great for all, more contributors, less workload across the board. I
understand that RPM packaging is a complex process, and creating Fedora
Linux is a large task, but for new contributors how are they to learn
the process, if the gate keepers are too efficient?

Regards,
and still hoping to be a packager  someday

Stephen

 
On Wed, 2021-08-11 at 14:16 +0200, Vitaly Zaitsev via devel wrote:
> On 11/08/2021 13:37, Stephen Snow wrote:
> > making joining the packaging group(s) a bit more open would go a
> > long way to  garnering more packagers IMO
> 
> New contributors must know at least the Fedora packaging guidelines. 
> This is the minimum barrier.
> 
> use COPR. Simple and easy.
> 
> -- 
> Sincerely,
>    Vitaly Zaitsev (vit...@easycoding.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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpmautospec release ccalculation

[Fabio Valentini]

On Wed, Aug 11, 2021 at 5:27 PM Michael J Gruber  wrote:
>
> The easy way out :)
> I'm maintaining a few stale packages, though.

Just wondering, if the packages are stale, why convert them?
Packages that change or have new versions often do benefit from
rpmautospec much more than something that never changes, IMO ...

> I wasn't sure about the x vs x+1. Good to know it's fine.

Well, if you run "fedpkg srpm", it should contain the preprocessed
.spec file, with the calculated release number as "%global
release_number" in the header, and the processed %changelog. That
might give you hints about what goes wrong in some of your cases. For
example, if there are "uncommitted changes", rpmautospec will
increment the release number by 1 automatically, with a changelog
message of "Uncommitted changes" :-)

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Kernel thermal configuration issues in laptop

[Iñaki Ucar]

On Wed, 11 Aug 2021 at 16:27, Justin Forbes  wrote:
>
> On Wed, Aug 11, 2021 at 8:46 AM Iñaki Ucar  wrote:
> >
> > On Wed, 11 Aug 2021 at 15:12, Benjamin Berg  wrote:
> > >
> > > Hi,
> > >
> > > is thermald.service active and running on that machine?
> >
> > thermald is not (and was never) installed.
> >
> > I'm pretty sure now it has something to do with some kernel change in
> > the 5.13.x series. I have a (manual) test case that reproduces the
> > issue reliably:
> > - Suspend the laptop and wait a few minutes until it cools down.
> > - Resume the session.
> > - Launch a compilation task when the sensors' output shows a
> > temperature of ~40ºC for the processor.
> >
> > I tested this for:
> > - 5.13.{4,5,8} -> fan doesn't speed up quickly enough, the laptop shuts 
> > down.
> > - 5.12.7 -> fan quickly reaches maximum speed, no shutdown.
> >
> > I see some differences for 5.12.x vs 5.13.x under
> > /sys/class/thermal/thermal_zone*/*, but I'm not sure what I should
> > look for. Or maybe the misconfiguration could be under
> > /sys/class/thermal/cooling_device*/*? Other? Any hints would be
> > appreciated.
>
> Is the intel_tcc_cooling module loaded? If so, what happens if you
> remove it?

It is loaded. Removing it doesn't help.

> Also, have you opened a bz for this? I don't recall seeing
> it, but I could be misremembering.

I didn't, because I was unsure about what or how to report this, so I
wanted to ask for help here first.
I've just opened this: https://bugzilla.redhat.com/show_bug.cgi?id=1992706

Iñaki

>
> Thanks,
> Justin
>
> > Iñaki
> >
> > > If yes, could you please edit the command line of the systemd unit to
> > > include --loglevel=debug and grab some logs[1]?
> > >
> > > Ideally both of a "bad" and "good" case.
> > >
> > > Obviously, we shouldn't be running into a critical temperature
> > > situation where the laptop simply shuts down. But I am not sure whether
> > > this is some misconfiguration or if thermald might be reacting too
> > > slowly for some reason.
> > >
> > > A good next step is likely to raise the issue with the thermald
> > > upstream and include the logs.
> > >
> > > Benjamin
> > >
> > > [1] You can also stop the service and simply run thermald manually as
> > > root. Maybe you find that more convenient. i.e. something like:
> > >   thermald --no-daemon --loglevel=debug --adaptive
> > >
> > > On Wed, 2021-08-11 at 12:31 +0200, Iñaki Ucar wrote:
> > > > Hi,
> > > >
> > > > This is so annoying. Recently, I've been experimenting
> > > > software-initiated shutdowns in my laptop (LG Gram) due to sudden
> > > > temperature rises in which the fan doesn't catch up and doesn't reach
> > > > maximum speed. In the journal, I see:
> > > >
> > > >   kernel: thermal thermal_zone0: acpitz: critical temperature reached,
> > > > shutting down
> > > >
> > > > They happen as follows. When the laptop is still cool (e.g., recently
> > > > powered up), if I launch some compilation task, which is quite CPU
> > > > demanding, then the temperature rises quickly and I hear that the CPU
> > > > fan speeds up too slowly, so slowly that the critical temperature is
> > > > reached and the laptop shuts down. However, if the laptop was already
> > > > medium-hot due to other tasks, then the CPU fan catches up and reaches
> > > > maximum speed quickly, so the temperature is controlled.
> > > >
> > > > This wasn't happening before, and I'm guessing that maybe some default
> > > > kernel thermal parameters have changed recently? (This is replicable at
> > > > least with all the kernels currently installed: 5.13.4, 5.13.5,
> > > > 5.13.8). I see that the thermal policy is step_wise in some thermal
> > > > zones, and user_space in others (there are 8). I'll be happy to provide
> > > > more info if anyone has any clue on how to debug and/or fix this.
> > > >
> > > > Regards,
> > > > --
> > > > Iñaki Úcar
> > > > ___
> > > > devel mailing list -- devel@lists.fedoraproject.org
> > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > > Fedora Code of Conduct:
> > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives:
> > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > > Do not reply to spam on the list, report it:
> > > > https://pagure.io/fedora-infrastructure
> > >
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: 
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > Do not reply to spam on the list, report it: 
> > > 

Re: rpmautospec release ccalculation

[Michael J Gruber]

> On Wed, Aug 11, 2021 at 4:08 PM Michael J Gruber  wrote:
> 
> I think these can be split into a different cases:
> 
> - BibTool: spec: Release: 4%{?dist} verrel: BibTool-2.68-4.fc36
> calculate_release release: 6
> - adf-gillius-fonts: spec: Release: 2%{?dist} verrel:
> adf-gillius-fonts-1.009-2.fc36 calculate_release release: 4
> - flickcurl: spec: Release: 15%{?dist} verrel: flickcurl-1.26-15.fc36
> calculate_release release: 17
> - luckybackup: spec: Release: 10%{?dist} verrel:
> luckybackup-0.4.9-10.fc36 calculate_release release: 13
> - tetex-elsevier: spec: Release: 26%{?dist} verrel:
> tetex-elsevier-0.1.20090917-26.fc36 calculate_release release: 32
> These are correct (or at least, expected).

OK. The README said "Calculate the next value for the RPM release field (i.e. 
to be used for the next build)", so that I wasn't sure whther to expect x or 
x+1 when at x.

> rpmautospec makes the simple assumption of incrementing Release by 1
> for every commit, and adding a changelog entry for every commit
> message.
> Looking at BibTool, there's two commits in there which didn't bump
> Release (adding BR: make and the second F35 Mass rebuild commit),
> which didn't count previously, but do count now.

It used to be habit to bump for Builds only, not intermediate commits. For the 
mass re-rebuild it may have been similar (FTBFS before then don't bump).

> This is the reason why I only converted my packages if I also had a
> version update at the same time, so that it definitely lines up to
> Release: 1.

The easy way out :)
I'm maintaining a few stale packages, though.

> - adf-accanthis-fonts: spec: Release: %autorelease (was 25!) verrel:
> adf-accanthis-fonts-1.8-4.fc36 calculate_release release: 4
> This looks like a bug. I see no obvious reason why the new calculated
> Release number would be 4, but it's possible that the %forge macros
> interfere with the calculation somehow, since they inject all sorts of
> weird stuff.

Oh yes, the previous maintainer switched to the macros before they landed and 
then dumped the package...
PkgHistoryProcessor seems to stop parsing completely at some commit.

On the other hand, looking at the last non-autorelease spec and incrementing 
from that one would have lead to fewer surprises... I mean, if I opt in at some 
point and the tool looks at history before which I cannot rewrite (as opposed 
to the changelog) then things *will* go wrong fpr quite a few packages.

> - dblatex: spec: Release: 5%{?dist} verrel: dblatex-0.3.12-5.fc36
> calculate_release release: 5
> - impressive: spec: Release: 0.9.%{timestamp}svn%{svnversion}%{?dist}
> verrel: impressive-0.13.0-0.9.20210612svn311.fc36 calculate_release
> release: 9
> - notmuch: spec: Release: 2%{?dist} verrel: notmuch-0.32.2-2.fc36
> calculate_release release: 2
> - sil-gentium-basic-fonts: spec: Release: 2%{?dist} verrel:
> sil-gentium-basic-fonts-1.102-2.fc36 calculate_release release: 2
> What's wrong here? The tools all agree.

I wasn't sure about the x vs x+1. Good to know it's fine.

> Note that for "impressive",
> you'd need to use "%autorelease -p -e %{timestamp}svn%{svnversion}" to
> keep the snapshot info in the same format (see the rpmautospec docs
> for details).

Yes. Wanted to convert the easy one first :|

> - portmidi: spec: Release: 41%{?dist} verrel: portmidi-217-41.fc36
> calculate_release release: 30
> This shouldn't happen, unless there are commit(s) that bumped Release
> by more than 1 - in which case you could specify a positive offset for
> the %autorelease macro to take this into account. Maybe the git
> history is a bit messed up, it looks like the last version update
> happened way back before the cvs -> git conversion?

All release bumps are individual commits with "+1", starting from 1.
Maybe PkgHistoryProcessor cannot parse some old specs? Again, relying on that 
is asking for trouble.

> The only thing I am concerned about is "fedpkg verrel" not printing
> the same number as "calculate_release". I think "fedpkg srpm" etc.
> have been adapted to get the release number from rpmautospec, but it
> looks like "fedpkg verrel" did not receive the same treatment. This
> should probably be reported as a bug against fedpkg / rpkg.
> 
> Fabio

Thanks for the detailed analysis!

I do think that taking the last non-autospec spec as a base (rather than 
parsing ancient history) would be much more robust, though. Or at least parse 
the changelog (rather than commit log) because we can rewrite that when we opt 
in.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 

libgps soname bump (gpsd-3.23)

[Miroslav Lichvar]

libgps provided by the gpsd package had another API and ABI break. The
following packages need to be rebuilt:

collectd
direwolf
foxtrotgps
marble
plasma-workspace
vfrnav
viking

I tried to rebuild them locally and it seems only direwolf needs a
patch. It's here:
https://fedorapeople.org/~mlichvar/tmp/gpsd/direwolf-gpsapi12.patch

The new gpsd package is built in a rawhide and f35 sidetag.
Please build your packages with:

fedpkg build --target=f36-build-side-44504
fedpkg build --target=f35-build-side-44506

If a proven packager is willing to take care all of the packages,
please let us know.

Thanks,

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpmautospec release ccalculation

[Fabio Valentini]

On Wed, Aug 11, 2021 at 4:08 PM Michael J Gruber  wrote:
>
> Hi there
>
> When trying to switch to rpmautospec I noticed some surprises in how autospec 
> computes the next release. Environment: I run "rpmautospec" on Fedora 34 as a 
> check before committing to dist-git. I converted one spec file so far, but 
> IIUC "rpmautospec calculate-release" does not depend on the conversion at 
> all. Comparing the release field in the spec, the output of "fedpkg verrel" 
> and that of "rpmautospec calculate-release" (on the rawhide branch) indicates 
> more than 1 problem:
>
> spec: Release: 4%{?dist} verrel: BibTool-2.68-4.fc36 calculate_release 
> release: 6
> spec: Release: %autorelease (was 25!) verrel: adf-accanthis-fonts-1.8-4.fc36 
> calculate_release release: 4
> spec: Release: 2%{?dist} verrel: adf-gillius-fonts-1.009-2.fc36 
> calculate_release release: 4
> spec: Release: 5%{?dist} verrel: dblatex-0.3.12-5.fc36 calculate_release 
> release: 5
> spec: Release: 15%{?dist} verrel: flickcurl-1.26-15.fc36 calculate_release 
> release: 17
> spec: Release: 0.9.%{timestamp}svn%{svnversion}%{?dist} verrel: 
> impressive-0.13.0-0.9.20210612svn311.fc36 calculate_release release: 9
> spec: Release: 10%{?dist} verrel: luckybackup-0.4.9-10.fc36 calculate_release 
> release: 13
> spec: Release: 2%{?dist} verrel: notmuch-0.32.2-2.fc36 calculate_release 
> release: 2
> spec: Release: 41%{?dist} verrel: portmidi-217-41.fc36 calculate_release 
> release: 30
> spec: Release: 2%{?dist} verrel: sil-gentium-basic-fonts-1.102-2.fc36 
> calculate_release release: 2
> spec: Release: 26%{?dist} verrel: tetex-elsevier-0.1.20090917-26.fc36 
> calculate_release release: 32
>
> I know that the (inherited) font package changelogs are special), but next 
> release coming out at a value less than verrel (portmidi, 
> adf-accanthis-fonts) makes me nervous before committing to this. Are the F34 
> commands lacking?

I think these can be split into a different cases:

- BibTool: spec: Release: 4%{?dist} verrel: BibTool-2.68-4.fc36
calculate_release release: 6
- adf-gillius-fonts: spec: Release: 2%{?dist} verrel:
adf-gillius-fonts-1.009-2.fc36 calculate_release release: 4
- flickcurl: spec: Release: 15%{?dist} verrel: flickcurl-1.26-15.fc36
calculate_release release: 17
- luckybackup: spec: Release: 10%{?dist} verrel:
luckybackup-0.4.9-10.fc36 calculate_release release: 13
- tetex-elsevier: spec: Release: 26%{?dist} verrel:
tetex-elsevier-0.1.20090917-26.fc36 calculate_release release: 32
These are correct (or at least, expected).
rpmautospec makes the simple assumption of incrementing Release by 1
for every commit, and adding a changelog entry for every commit
message.
Looking at BibTool, there's two commits in there which didn't bump
Release (adding BR: make and the second F35 Mass rebuild commit),
which didn't count previously, but do count now.
This is the reason why I only converted my packages if I also had a
version update at the same time, so that it definitely lines up to
Release: 1.

- adf-accanthis-fonts: spec: Release: %autorelease (was 25!) verrel:
adf-accanthis-fonts-1.8-4.fc36 calculate_release release: 4
This looks like a bug. I see no obvious reason why the new calculated
Release number would be 4, but it's possible that the %forge macros
interfere with the calculation somehow, since they inject all sorts of
weird stuff.

- dblatex: spec: Release: 5%{?dist} verrel: dblatex-0.3.12-5.fc36
calculate_release release: 5
- impressive: spec: Release: 0.9.%{timestamp}svn%{svnversion}%{?dist}
verrel: impressive-0.13.0-0.9.20210612svn311.fc36 calculate_release
release: 9
- notmuch: spec: Release: 2%{?dist} verrel: notmuch-0.32.2-2.fc36
calculate_release release: 2
- sil-gentium-basic-fonts: spec: Release: 2%{?dist} verrel:
sil-gentium-basic-fonts-1.102-2.fc36 calculate_release release: 2
What's wrong here? The tools all agree. Note that for "impressive",
you'd need to use "%autorelease -p -e %{timestamp}svn%{svnversion}" to
keep the snapshot info in the same format (see the rpmautospec docs
for details).

- portmidi: spec: Release: 41%{?dist} verrel: portmidi-217-41.fc36
calculate_release release: 30
This shouldn't happen, unless there are commit(s) that bumped Release
by more than 1 - in which case you could specify a positive offset for
the %autorelease macro to take this into account. Maybe the git
history is a bit messed up, it looks like the last version update
happened way back before the cvs -> git conversion?

The only thing I am concerned about is "fedpkg verrel" not printing
the same number as "calculate_release". I think "fedpkg srpm" etc.
have been adapted to get the release number from rpmautospec, but it
looks like "fedpkg verrel" did not receive the same treatment. This
should probably be reported as a bug against fedpkg / rpkg.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of 

Re: rpmlint: W: no-manual-page-for-binary shutter

[Jerry James]

On Wed, Aug 11, 2021 at 5:15 AM  wrote:
> Tanks for your information, i will open a ticket.

I already filed a bug about this a month ago:

https://bugzilla.redhat.com/show_bug.cgi?id=1980400

There has been no movement on the bug so far.
-- 
Jerry James
http://www.jamezone.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Kernel thermal configuration issues in laptop

[Justin Forbes]

On Wed, Aug 11, 2021 at 8:46 AM Iñaki Ucar  wrote:
>
> On Wed, 11 Aug 2021 at 15:12, Benjamin Berg  wrote:
> >
> > Hi,
> >
> > is thermald.service active and running on that machine?
>
> thermald is not (and was never) installed.
>
> I'm pretty sure now it has something to do with some kernel change in
> the 5.13.x series. I have a (manual) test case that reproduces the
> issue reliably:
> - Suspend the laptop and wait a few minutes until it cools down.
> - Resume the session.
> - Launch a compilation task when the sensors' output shows a
> temperature of ~40ºC for the processor.
>
> I tested this for:
> - 5.13.{4,5,8} -> fan doesn't speed up quickly enough, the laptop shuts down.
> - 5.12.7 -> fan quickly reaches maximum speed, no shutdown.
>
> I see some differences for 5.12.x vs 5.13.x under
> /sys/class/thermal/thermal_zone*/*, but I'm not sure what I should
> look for. Or maybe the misconfiguration could be under
> /sys/class/thermal/cooling_device*/*? Other? Any hints would be
> appreciated.

Is the intel_tcc_cooling module loaded? If so, what happens if you
remove it?  Also, have you opened a bz for this? I don't recall seeing
it, but I could be misremembering.

Thanks,
Justin

> Iñaki
>
> > If yes, could you please edit the command line of the systemd unit to
> > include --loglevel=debug and grab some logs[1]?
> >
> > Ideally both of a "bad" and "good" case.
> >
> > Obviously, we shouldn't be running into a critical temperature
> > situation where the laptop simply shuts down. But I am not sure whether
> > this is some misconfiguration or if thermald might be reacting too
> > slowly for some reason.
> >
> > A good next step is likely to raise the issue with the thermald
> > upstream and include the logs.
> >
> > Benjamin
> >
> > [1] You can also stop the service and simply run thermald manually as
> > root. Maybe you find that more convenient. i.e. something like:
> >   thermald --no-daemon --loglevel=debug --adaptive
> >
> > On Wed, 2021-08-11 at 12:31 +0200, Iñaki Ucar wrote:
> > > Hi,
> > >
> > > This is so annoying. Recently, I've been experimenting
> > > software-initiated shutdowns in my laptop (LG Gram) due to sudden
> > > temperature rises in which the fan doesn't catch up and doesn't reach
> > > maximum speed. In the journal, I see:
> > >
> > >   kernel: thermal thermal_zone0: acpitz: critical temperature reached,
> > > shutting down
> > >
> > > They happen as follows. When the laptop is still cool (e.g., recently
> > > powered up), if I launch some compilation task, which is quite CPU
> > > demanding, then the temperature rises quickly and I hear that the CPU
> > > fan speeds up too slowly, so slowly that the critical temperature is
> > > reached and the laptop shuts down. However, if the laptop was already
> > > medium-hot due to other tasks, then the CPU fan catches up and reaches
> > > maximum speed quickly, so the temperature is controlled.
> > >
> > > This wasn't happening before, and I'm guessing that maybe some default
> > > kernel thermal parameters have changed recently? (This is replicable at
> > > least with all the kernels currently installed: 5.13.4, 5.13.5,
> > > 5.13.8). I see that the thermal policy is step_wise in some thermal
> > > zones, and user_space in others (there are 8). I'll be happy to provide
> > > more info if anyone has any clue on how to debug and/or fix this.
> > >
> > > Regards,
> > > --
> > > Iñaki Úcar
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > Do not reply to spam on the list, report it:
> > > https://pagure.io/fedora-infrastructure
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
>
>
>
> --
> Iñaki Úcar
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not 

rpmautospec release ccalculation

[Michael J Gruber]

Hi there

When trying to switch to rpmautospec I noticed some surprises in how autospec 
computes the next release. Environment: I run "rpmautospec" on Fedora 34 as a 
check before committing to dist-git. I converted one spec file so far, but IIUC 
"rpmautospec calculate-release" does not depend on the conversion at all. 
Comparing the release field in the spec, the output of "fedpkg verrel" and that 
of "rpmautospec calculate-release" (on the rawhide branch) indicates more than 
1 problem:

spec: Release: 4%{?dist} verrel: BibTool-2.68-4.fc36 calculate_release release: 
6
spec: Release: %autorelease (was 25!) verrel: adf-accanthis-fonts-1.8-4.fc36 
calculate_release release: 4
spec: Release: 2%{?dist} verrel: adf-gillius-fonts-1.009-2.fc36 
calculate_release release: 4
spec: Release: 5%{?dist} verrel: dblatex-0.3.12-5.fc36 calculate_release 
release: 5
spec: Release: 15%{?dist} verrel: flickcurl-1.26-15.fc36 calculate_release 
release: 17
spec: Release: 0.9.%{timestamp}svn%{svnversion}%{?dist} verrel: 
impressive-0.13.0-0.9.20210612svn311.fc36 calculate_release release: 9
spec: Release: 10%{?dist} verrel: luckybackup-0.4.9-10.fc36 calculate_release 
release: 13
spec: Release: 2%{?dist} verrel: notmuch-0.32.2-2.fc36 calculate_release 
release: 2
spec: Release: 41%{?dist} verrel: portmidi-217-41.fc36 calculate_release 
release: 30
spec: Release: 2%{?dist} verrel: sil-gentium-basic-fonts-1.102-2.fc36 
calculate_release release: 2
spec: Release: 26%{?dist} verrel: tetex-elsevier-0.1.20090917-26.fc36 
calculate_release release: 32

I know that the (inherited) font package changelogs are special), but next 
release coming out at a value less than verrel (portmidi, adf-accanthis-fonts) 
makes me nervous before committing to this. Are the F34 commands lacking?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: interesting decrease in package sizes between F34 and F35

[Petr Pisar]

V Wed, Aug 11, 2021 at 01:14:13PM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> I'm building some minimal images with mkosi, and I was working on a
> pull request to add a "package manifest", i.e. a dump of all packages,
> and I noticed that archful packages which were rebuilt with no changes
> between F34 and rawhide have almost all gotten smaller:
[...]
> This is the uncompressed size, so any differences in rpm compression
> are not relevant. The binaries are smaller. Kudos to the compiler folks!
> 
What smaller became is .gnu_debugdata ELF section of the executables. And then
/usr/lib/debug/*.debug files.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Eclipse IDE packages and friends orphaned

[Aleksandar Kurtakov]

On Wed, Aug 11, 2021 at 3:20 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 11/08/2021 12:35, Aleksandar Kurtakov wrote:
> > Eclipse IDE and its ancillary packages are orphaned now. As a result the
> > Eclipse IDE will no longer be installable as a package in Fedora 35.
>
> > Red Hat Eclipse Team
>
> Even Red Hat employees can't handle the Java Stack on Fedora. This is so
> sad.
>

It's a resources problem not a technical one - as the team gains more
upstream duties there is just no time for Fedora, there are only so many
hours in the day.


>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Kernel thermal configuration issues in laptop

[Iñaki Ucar]

On Wed, 11 Aug 2021 at 15:12, Benjamin Berg  wrote:
>
> Hi,
>
> is thermald.service active and running on that machine?

thermald is not (and was never) installed.

I'm pretty sure now it has something to do with some kernel change in
the 5.13.x series. I have a (manual) test case that reproduces the
issue reliably:
- Suspend the laptop and wait a few minutes until it cools down.
- Resume the session.
- Launch a compilation task when the sensors' output shows a
temperature of ~40ºC for the processor.

I tested this for:
- 5.13.{4,5,8} -> fan doesn't speed up quickly enough, the laptop shuts down.
- 5.12.7 -> fan quickly reaches maximum speed, no shutdown.

I see some differences for 5.12.x vs 5.13.x under
/sys/class/thermal/thermal_zone*/*, but I'm not sure what I should
look for. Or maybe the misconfiguration could be under
/sys/class/thermal/cooling_device*/*? Other? Any hints would be
appreciated.

Iñaki

> If yes, could you please edit the command line of the systemd unit to
> include --loglevel=debug and grab some logs[1]?
>
> Ideally both of a "bad" and "good" case.
>
> Obviously, we shouldn't be running into a critical temperature
> situation where the laptop simply shuts down. But I am not sure whether
> this is some misconfiguration or if thermald might be reacting too
> slowly for some reason.
>
> A good next step is likely to raise the issue with the thermald
> upstream and include the logs.
>
> Benjamin
>
> [1] You can also stop the service and simply run thermald manually as
> root. Maybe you find that more convenient. i.e. something like:
>   thermald --no-daemon --loglevel=debug --adaptive
>
> On Wed, 2021-08-11 at 12:31 +0200, Iñaki Ucar wrote:
> > Hi,
> >
> > This is so annoying. Recently, I've been experimenting
> > software-initiated shutdowns in my laptop (LG Gram) due to sudden
> > temperature rises in which the fan doesn't catch up and doesn't reach
> > maximum speed. In the journal, I see:
> >
> >   kernel: thermal thermal_zone0: acpitz: critical temperature reached,
> > shutting down
> >
> > They happen as follows. When the laptop is still cool (e.g., recently
> > powered up), if I launch some compilation task, which is quite CPU
> > demanding, then the temperature rises quickly and I hear that the CPU
> > fan speeds up too slowly, so slowly that the critical temperature is
> > reached and the laptop shuts down. However, if the laptop was already
> > medium-hot due to other tasks, then the CPU fan catches up and reaches
> > maximum speed quickly, so the temperature is controlled.
> >
> > This wasn't happening before, and I'm guessing that maybe some default
> > kernel thermal parameters have changed recently? (This is replicable at
> > least with all the kernels currently installed: 5.13.4, 5.13.5,
> > 5.13.8). I see that the thermal policy is step_wise in some thermal
> > zones, and user_space in others (there are 8). I'll be happy to provide
> > more info if anyone has any clue on how to debug and/or fix this.
> >
> > Regards,
> > --
> > Iñaki Úcar
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: HEADS UP: Go 1.17 and Fedora 35

[Alejandro Saez Morollon]

I just submitted to COPR [0] all of the packages that use Go (I think
so...) for an initial test.

Let's see how it goes.

[0] https://copr.fedorainfracloud.org/coprs/alexsaezm/go1.17/builds/

On Tue, Aug 10, 2021 at 7:46 PM Alejandro Saez Morollon  wrote:
>
> Hi everyone.
>
> I missed the mass rebuild for several reasons, and I didn't prepare
> the Go package for the 1.17 release as I proposed [0].
>
> This email thread is to keep everyone up to date on the progress
> regarding this issue [1].
>
> [0] https://fedoraproject.org/wiki/Changes/golang1.17
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1982396
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] Fedora 35 Boost 1.76 rebuilds starting in a side tag

[Fabio Valentini]

On Wed, Aug 11, 2021 at 12:08 PM Jonathan Wakely  wrote:
>
> On Wed, 11 Aug 2021 at 11:00, Jonathan Wakely wrote:
> > The rest were not submitted for a rebuild, for some reason. That's
> > cpp-hocon, luminance-hdr, openshadinglanguage, and usd. I'm not sure
> > why they didn't get submitted.
>
> Those four packages cannot be updated by rpmdev-bumpspec:
>
> RPMAutoSpec usage detected, not changing the spec file.
>
> That makes my rebuild tools give up and not try to rebuild it. Looks
> like I need to adjust the tools.

You'll probably need the same modifications as the mass rebuild script
used by releng:

https://pagure.io/releng/c/11160f7ccaf57f7da10612e8c857a22fba132155?branch=main
https://pagure.io/releng/c/950ff66d09277039423964654db20d6a43415c6e?branch=main

TL;DR: Since rpmdev-bumpspec will not make .spec file modifications,
you'll just need to check whether its return code was 0, and then run
"git commit -a -m MESSAGE" with the "--allow-empty" flag.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-devel] Re: stable/dev branches

[Mark Reynolds]

On 8/11/21 9:23 AM, Stanislav Levin wrote:


11.11.2020 22:03, Mark Reynolds пишет:

On 11/3/20 8:50 AM, Stanislav Levin wrote:

03.11.2020 15:58, Mark Reynolds пишет:

On 11/3/20 4:41 AM, Stanislav Levin wrote:

Hello.

Currently, I package 1.4.1 branch as the former-stable for ALTLinux.
But it is not updated since July, too stable?


1.4.x branches in upstream:

    upstream/389-ds-base-1.4.1

This is no longer being maintained

    upstream/389-ds-base-1.4.2

This branch is about to stop being maintained

    upstream/389-ds-base-1.4.3

This would be the "most" stable branch at this time.

    upstream/389-ds-base-1.4.4
    upstream/master

1.4.4 and master (2.0.0) are not "stable" and include more cutting edge
changes and features.

HTH,

Mark

It would be much appreciated such future changes will be announced at
time. I think the other distro-packagers need this information too.

We follow the Fedora release schedule:

https://fedoraproject.org/wiki/Releases?rd=Releases/

So...

F34(rawhide) --> 389-ds-base-2.0.0

F33 --> 389-ds-base-1.4.4

F32 --> 389-ds-base-1.4.3

F31 --> 389-ds-base-1.4.2

Now F31 is probably going to be EOLed sooner than later, so we will stop
maintaining 1.4.2 at that time.


I will add something to the landing page of our wiki about this topic.



Hi! Any news on this?
Could you please point me to which branch is current stable or LTS?


389-ds-base-1.4.3 and 1.4.4 are the most stable, 389-ds-base-2.0 and 
master branch are still under heavy development.


HTH,

Mark



Thanks.


___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


--
Directory Server Development Team

___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Help with gdal sphinx doc build failure

[Orion Poplawski]

Thanks!  Keeping an eye on it...

On 8/11/21 6:02 AM, Sandro Mani wrote:

Hi

This [1] patch applies cleanly. I'll give it a try in COPR [2].

Sandro

[1] https://smani.fedorapeople.org/711.patch
[2] https://copr.fedorainfracloud.org/coprs/smani/gdal-breathe/

On 11.08.21 06:37, Orion Poplawski wrote:

I've reported: https://bugzilla.redhat.com/show_bug.cgi?id=1992426

gdal docs are failing to build with:



Exception occurred:

  File "/usr/lib/python3.10/site-packages/sphinx/util/cfamily.py", 
line 275, in fail


    raise self._make_multi_error(errors, '')

sphinx.util.cfamily.DefinitionError: Invalid C++ declaration: Expected 
identifier in nested name. [error at 8]


  typename...

  ^



This appears to be due to breathe not handling parsing errors. There 
is a PR upstream at https://github.com/michaeljones/breathe/pull/711 
but it doesn't apply cleanly to the current release so I haven't been 
able to test it.




I'm in the middle of a hdf5/netcdf/octave update in F35 and so am in a 
bit of a time crunch unfortunately.  I'm not sure if this can be 
worked around easily in gdal or not.





Any suggestions would be greatly appreciated.





--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-devel] Re: stable/dev branches

[Stanislav Levin]

11.11.2020 22:03, Mark Reynolds пишет:
> 
> On 11/3/20 8:50 AM, Stanislav Levin wrote:
>>
>> 03.11.2020 15:58, Mark Reynolds пишет:
>>> On 11/3/20 4:41 AM, Stanislav Levin wrote:
 Hello.

 Currently, I package 1.4.1 branch as the former-stable for ALTLinux.
 But it is not updated since July, too stable?


 1.4.x branches in upstream:

    upstream/389-ds-base-1.4.1
>>> This is no longer being maintained
    upstream/389-ds-base-1.4.2
>>> This branch is about to stop being maintained
    upstream/389-ds-base-1.4.3
>>> This would be the "most" stable branch at this time.
    upstream/389-ds-base-1.4.4
    upstream/master
>>> 1.4.4 and master (2.0.0) are not "stable" and include more cutting edge
>>> changes and features.
>>>
>>> HTH,
>>>
>>> Mark
>> It would be much appreciated such future changes will be announced at
>> time. I think the other distro-packagers need this information too.
> 
> We follow the Fedora release schedule:
> 
> https://fedoraproject.org/wiki/Releases?rd=Releases/
> 
> So...
> 
> F34(rawhide) --> 389-ds-base-2.0.0
> 
> F33 --> 389-ds-base-1.4.4
> 
> F32 --> 389-ds-base-1.4.3
> 
> F31 --> 389-ds-base-1.4.2
> 
> Now F31 is probably going to be EOLed sooner than later, so we will stop
> maintaining 1.4.2 at that time.
> 
> 
> I will add something to the landing page of our wiki about this topic.
> 


Hi! Any news on this?
Could you please point me to which branch is current stable or LTS?

Thanks.



OpenPGP_signature
Description: OpenPGP digital signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

interesting decrease in package sizes between F34 and F35

[Zbigniew Jędrzejewski-Szmek]

I'm building some minimal images with mkosi, and I was working on a
pull request to add a "package manifest", i.e. a dump of all packages,
and I noticed that archful packages which were rebuilt with no changes
between F34 and rawhide have almost all gotten smaller:

-SourcePackage: acl-2.3.1-1.fc34.src.rpm
+SourcePackage: acl-2.3.1-2.fc35.src.rpm
 Packages:  acl libacl
-Size:  255585
+Size:  254969

-SourcePackage: audit-3.0.3-1.fc34.src.rpm
+SourcePackage: audit-3.0.3-2.fc35.src.rpm
 Packages:  audit-libs
-Size:  303278
+Size:  303105

-SourcePackage: coreutils-8.32-30.fc34.src.rpm
+SourcePackage: coreutils-8.32-31.fc35.src.rpm
 Packages:  coreutils coreutils-common
-Size:  16941864
+Size:  16921108

-SourcePackage: dbus-broker-29-2.fc34.src.rpm
+SourcePackage: dbus-broker-29-3.fc35.src.rpm
 Packages:  dbus-broker
-Size:  396543
+Size:  396327

-SourcePackage: expat-2.4.1-1.fc34.src.rpm
+SourcePackage: expat-2.4.1-2.fc35.src.rpm
 Packages:  expat
-Size:  295609
+Size:  295041

...

This is the uncompressed size, so any differences in rpm compression
are not relevant. The binaries are smaller. Kudos to the compiler folks!

Zbyszek



P.S. Sadly, some of this is offset by new deps:

-SourcePackage: cracklib-2.9.6-25.fc34.src.rpm
-Packages:  cracklib
-Size:  251906
+SourcePackage: cracklib-2.9.6-26.fc35.src.rpm
+Packages:  cracklib cracklib-dicts
+Size:  10066620

https://bugzilla.redhat.com/show_bug.cgi?id=1992607
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Kernel thermal configuration issues in laptop

[Benjamin Berg]

Hi,

is thermald.service active and running on that machine?

If yes, could you please edit the command line of the systemd unit to
include --loglevel=debug and grab some logs[1]?

Ideally both of a "bad" and "good" case.

Obviously, we shouldn't be running into a critical temperature
situation where the laptop simply shuts down. But I am not sure whether
this is some misconfiguration or if thermald might be reacting too
slowly for some reason.

A good next step is likely to raise the issue with the thermald
upstream and include the logs.

Benjamin

[1] You can also stop the service and simply run thermald manually as
root. Maybe you find that more convenient. i.e. something like:
  thermald --no-daemon --loglevel=debug --adaptive

On Wed, 2021-08-11 at 12:31 +0200, Iñaki Ucar wrote:
> Hi,
> 
> This is so annoying. Recently, I've been experimenting
> software-initiated shutdowns in my laptop (LG Gram) due to sudden
> temperature rises in which the fan doesn't catch up and doesn't reach
> maximum speed. In the journal, I see:
> 
>   kernel: thermal thermal_zone0: acpitz: critical temperature reached,
> shutting down
> 
> They happen as follows. When the laptop is still cool (e.g., recently
> powered up), if I launch some compilation task, which is quite CPU
> demanding, then the temperature rises quickly and I hear that the CPU
> fan speeds up too slowly, so slowly that the critical temperature is
> reached and the laptop shuts down. However, if the laptop was already
> medium-hot due to other tasks, then the CPU fan catches up and reaches
> maximum speed quickly, so the temperature is controlled.
> 
> This wasn't happening before, and I'm guessing that maybe some default
> kernel thermal parameters have changed recently? (This is replicable at
> least with all the kernels currently installed: 5.13.4, 5.13.5,
> 5.13.8). I see that the thermal policy is step_wise in some thermal
> zones, and user_space in others (there are 8). I'll be happy to provide
> more info if anyone has any clue on how to debug and/or fix this.
> 
> Regards,
> --
> Iñaki Úcar
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure



signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Using reverse week deps for Python interpreters and tox (Supplements instead of Recommends)?

[Miro Hrončok]

Hello Pythonistas.

Currently, the tox package has:

  # Recommend "all the Pythons"
  Recommends: python2.7
  Recommends: python3.6
  Recommends: python3.7
  Recommends: python3.8
  Recommends: python3.9
  Recommends: python3.10
  Recommends: pypy2-devel
  Recommends: pypy3-devel
  Recommends: python2-devel
  Recommends: python3-devel

Every time we add or remove a Python interpreter, we need to change the list:

E.g. 
https://src.fedoraproject.org/rpms/python-tox/c/7220117b812d3b5b009b3b1170ee5242b03efcb2



What if we added this to all interpreters that work with our tox instead?

  Supplements: tox

That way:

 - When we introduce a new interpreter,
   tox starts to pull it by default right away.

 - When different Fedoras (or even EPELs) have different interpreter sets,
   we don't need to divert the tox spec.

OTOH:

 - When we add a new interpreter that Supplements tox, we would still need to 
adapt tox's CI config to include it. Maybe we could adapt the CI tests for tox 
to automatically test with all interpreters that supplement it.


WDYT?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

pypy3 renamed to pypy3.7 on Fedora 35+, also available in Fedora 33/34

[Miro Hrončok]

Hello PyPyistas,

we have renamed the pypy3 package to pypy3.7 (both the component and the 
"binary" package) on Fedora 35+. The package no longer installs to 
/usr/lib64/pypy3-7.x/ but rather to /usr/lib64/pypy3.7/.


*What is this good for?*

When PyPy 3 was updated from Python 3.N to 3.N+1, traditionally we have only 
updated it in Rawhide (and Branched), not to do a backward-incompatible update 
in stable Fedoras.
With this renaming, you can now¹ install pypy3.7 on all Fedoras, despite pypy3 
being 3.6 on Fedora 33 and 34.


¹ (The builds are still running, expect an update in Bodhi later today.)

Once PyPy 3.8 is released, we can introduce it to all Fedora versions.


*Warning to Rawhide/Fedora 35 users*

If you already used the pypy3 package with PyPy 3.7, the pypy3.7 package will 
obsolete it. However, the installation paths are different, so you will need to 
re-create your PyPy 3 virtual environments.



*Details* (feel free to ignore the rest of this email)

During a lifetime of one stable Fedora release, you will get:

- pypy3.N that provides pypy3 and has /usr/bin/pypy3
- pypy3.N+c introduced later in the lifetime

E.g. for Fedora 35:

- pypy3.7 that provides pypy3 and has /usr/bin/pypy3
- pypy3.8 (or newer) might be introduced in the future

For Fedora 33 and 34, there is a transition period:

- pypy3 provides pypy3.6 and has /usr/bin/pypy3
- pypy3.7 was just introduced
- pypy3.8 (or newer) might be introduced in the future

See for example on Fedora 33:

   $ rpm -qa | grep pypy3
   pypy3-libs-7.3.1-6.fc33.x86_64
   pypy3-7.3.1-6.fc33.x86_64
   pypy3-devel-7.3.1-6.fc33.x86_64
   pypy3.7-libs-7.3.4-4.fc33.x86_64
   pypy3.7-7.3.4-4.fc33.x86_64
   pypy3.7-devel-7.3.4-4.fc33.x86_64

   $ pypy3.6 --version
   Python 3.6.9 (831ff17f8cd1, May 26 2021, 11:41:48)
   [PyPy 7.3.1 with GCC 10.3.1 20210422 (Red Hat 10.3.1-1)]

   $ pypy3.7 --version
   Python 3.7.10 (8dd9fc18a6f0, Aug 11 2021, 06:30:36)
   [PyPy 7.3.4 with GCC 10.3.1 20210422 (Red Hat 10.3.1-1)]

   $ pypy3 --version
   Python 3.6.9 (831ff17f8cd1, May 26 2021, 11:41:48)
   [PyPy 7.3.1 with GCC 10.3.1 20210422 (Red Hat 10.3.1-1)]

Note that we *do not* plan to maintain old PyPy versions indefinitely, we plan 
to retire them from Rawhide/Branched as soon as new versions arrive and only 
keep them alive until stable Fedoras goes EOL.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Kernel thermal configuration issues in laptop

[Iñaki Ucar]

On Wed, 11 Aug 2021 at 14:17, Vitaly Zaitsev via devel
 wrote:
>
> On 11/08/2021 12:31, Iñaki Ucar wrote:
> > This is so annoying. Recently, I've been experimenting
> > software-initiated shutdowns in my laptop (LG Gram) due to sudden
> > temperature rises in which the fan doesn't catch up and doesn't reach
> > maximum speed. In the journal, I see:
>
> AMD CPU? Intel should start hardware throttling instead of shutting down.

product: Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to rebuild package using autospec

[Richard Shaw]

On Wed, Aug 11, 2021 at 12:01 AM Ben Beasley 
wrote:

> In general, if you want to rebuild an rpmautospec package with no spec
> file changes, you can do an empty git commit like this:
>
> git commit —allow-empty -m 'Rebuild for foolib 3.14'
>

I'm probably not going to remember that. :)


> Then “fedpkg build” as usual.
>
> The case of usd is not quite so simple. I tried to rebuild it as a
> co-maintainer earlier today. I ran into a problem with OpenEXR 3, committed
> a workaround, and then ran into an incompatibility with glibc 2.34 (it uses
> deprecated allocation hooks that were removed). I’m hoping the primary
> maintainer will take the lead on that. More details are in
> https://bugzilla.redhat.com/show_bug.cgi?id=1991892#c3. As of now, usd is
> still FTBFS.
>

Ok, we'll I'm down to the last few packages for the OpenEXR/Imath disaster
but I can't attempt a rebuild on blender until usd is fixed as it's
uninstallable due to lack of being rebuilt with boost 1.76.

And then once I'm done with that I get to start all over again with OpenEXR
3.1. Fun.

On Wed, Aug 11, 2021 at 5:20 AM Jonathan Wakely  wrote:

> On Wed, 11 Aug 2021 at 06:01, Ben Beasley wrote:
> >
> > In general, if you want to rebuild an rpmautospec package with no spec
> file changes, you can do an empty git commit like this:
> >
> > git commit —allow-empty -m 'Rebuild for foolib 3.14'
> >
> > Then “fedpkg build” as usual.
>
> This should have been documented at
> https://fedoraproject.org/wiki/Changes/rpmautospec and absolutely
> needs to be added to
> https://docs.pagure.org/Fedora-Infra.rpmautospec/index.html


One step better would be to add something in fedpkg similar to how it's
already a wrapper for a lot of git functions.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The Death of Java (packages)

[Emmanuel Seyman]

* Stephen Snow [11/08/2021 11:37] :
>
> I feel the frustration you are expressing, and would like to help, nut
> apparently I don't meet the Fedora Packaging standards.

I'm curious as to what happened...

> Even tried the review route, which is also beset with arbitrary obstacles.

Again, what happened? Can you point us to those reviews?

> I will keep trying because that is in my nature, but making joining the
> packaging group(s) a bit more open would go a long way to garnering more
> packagers IMO.

What changes to the process would you like to see made?

Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Eclipse IDE packages and friends orphaned

[Vitaly Zaitsev via devel]

On 11/08/2021 12:35, Aleksandar Kurtakov wrote:
Eclipse IDE and its ancillary packages are orphaned now. As a result the 
Eclipse IDE will no longer be installable as a package in Fedora 35.



Red Hat Eclipse Team


Even Red Hat employees can't handle the Java Stack on Fedora. This is so 
sad.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The Death of Java (packages)

[Vitaly Zaitsev via devel]

On 11/08/2021 13:37, Stephen Snow wrote:

making joining the packaging group(s) a bit more open would go a long way to  
garnering more packagers IMO


New contributors must know at least the Fedora packaging guidelines. 
This is the minimum barrier.


If someone doesn't want to read and follow the instructions, they can 
use COPR. Simple and easy.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Kernel thermal configuration issues in laptop

[Vitaly Zaitsev via devel]

On 11/08/2021 12:31, Iñaki Ucar wrote:

This is so annoying. Recently, I've been experimenting
software-initiated shutdowns in my laptop (LG Gram) due to sudden
temperature rises in which the fan doesn't catch up and doesn't reach
maximum speed. In the journal, I see:


AMD CPU? Intel should start hardware throttling instead of shutting down.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Non-responsive maintainer tc01 (Ben Rosser)

[Mattias Ellert]

Hi!

I filed a bugzilla request 2021-04-18 (almost 4 month ago) asking for
the uglify-js package to be updated:

https://bugzilla.redhat.com/show_bug.cgi?id=1950780

There has been no reply from the maintainer.

Following the non-responsive maintainer policy
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

I have filed a non-responsive maintainer bugzilla tickat and is asking
on this mailing list if anyone knows how to contact the maintainer tc01
(Ben Rosser):

https://bugzilla.redhat.com/show_bug.cgi?id=1992605

Mattias



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Help with gdal sphinx doc build failure

[Sandro Mani]

Hi

This [1] patch applies cleanly. I'll give it a try in COPR [2].

Sandro

[1] https://smani.fedorapeople.org/711.patch
[2] https://copr.fedorainfracloud.org/coprs/smani/gdal-breathe/

On 11.08.21 06:37, Orion Poplawski wrote:

I've reported: https://bugzilla.redhat.com/show_bug.cgi?id=1992426

gdal docs are failing to build with:



Exception occurred:

  File "/usr/lib/python3.10/site-packages/sphinx/util/cfamily.py", 
line 275, in fail


    raise self._make_multi_error(errors, '')

sphinx.util.cfamily.DefinitionError: Invalid C++ declaration: Expected 
identifier in nested name. [error at 8]


  typename...

  ^



This appears to be due to breathe not handling parsing errors. There 
is a PR upstream at https://github.com/michaeljones/breathe/pull/711 
but it doesn't apply cleanly to the current release so I haven't been 
able to test it.




I'm in the middle of a hdf5/netcdf/octave update in F35 and so am in a 
bit of a time crunch unfortunately.  I'm not sure if this can be 
worked around easily in gdal or not.





Any suggestions would be greatly appreciated.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The Death of Java (packages)

[Stephen Snow]

Hello Fabio,
I was one of those community members to step up, or at least attempt to. What I 
found was an obstacle course instead of welcome to the packagers. I feel the 
frustration you are expressing, and would like to help, nut apparently I don't 
meet the Fedora Packaging standards. Even tried the review route, which is also 
beset with arbitrary obstacles. I will keep trying because that is in my 
nature, but making joining the packaging group(s) a bit more open would go a 
long way to  garnering more packagers IMO.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)

[Ankur Sinha]

On Wed, Aug 11, 2021 13:53:51 +0300, Panu Matilainen wrote:
> 
> 
> The macro needs to be fixed, ending up with 0 is unacceptable and so is
> breaking debuginfo.

For the moment, until these issues can be ironed out, I've given both
F33 and F34 updates negative karma to prevent them from going stable
automatically.

-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure