Fedora-Cloud-33-20210105.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-20210104.0):

ID: 751715  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/751715
ID: 751722  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/751722

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1912662] perl-Gnome2-Canvas-1.006 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Gnome2-Canvas-1.006-1.fc32.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=58954468


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

[Bug 1912662] perl-Gnome2-Canvas-1.006 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1744476
  --> https://bugzilla.redhat.com/attachment.cgi?id=1744476=edit
[patch] Update to 1.006 (#1912662)


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

[Bug 1912662] New: perl-Gnome2-Canvas-1.006 is available

[bugzilla]

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

Bug ID: 1912662
   Summary: perl-Gnome2-Canvas-1.006 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Gnome2-Canvas
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.006
Current version/release in rawhide: 1.004-1.fc34
URL: http://search.cpan.org/dist/Gnome2-Canvas/

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/2926/


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

[389-devel] 389 DS nightly 2021-01-05 - 93% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2021/01/05/report-389-ds-base-1.4.4.9-1.fc33.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Bug 1912654] New: perl-HTTP-Message-6.27 is available

[bugzilla]

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

Bug ID: 1912654
   Summary: perl-HTTP-Message-6.27 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-HTTP-Message
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.27
Current version/release in rawhide: 6.26-1.fc34
URL: http://search.cpan.org/dist/HTTP-Message/

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/2977/


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

[389-devel] Please review: 4517 systemd pin warning cleanup

[William Brown]

https://github.com/389ds/389-ds-base/pull/4518

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
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

csync2 is now orphaned

[Angus Salkeld]

Hi all

I have just orphaned https://src.fedoraproject.org/rpms/csync2 as I don't
have the time to maintain it. Honestly I haven't done anything with the
package for years.

I have been getting notifications from
https://bugzilla.redhat.com/show_bug.cgi?id=1907158
about failed builds and it suggests either fixing or orphaning.

Regards
Angus Salkeld
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1910780] perl-ExtUtils-HasCompiler-0.023 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-fee045fac8 has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-fee045fac8`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-fee045fac8

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

[Bug 1910310] perl-libnet-3.13 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-6aba9c3436 has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-6aba9c3436`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-6aba9c3436

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

[Bug 1910204] perl-DateTime-TimeZone-2.46 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-e2d3150bdc has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-e2d3150bdc`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-e2d3150bdc

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

[Bug 1906282] perl-Text-Fuzzy-0.29 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Text-Fuzzy-0.29-1.fc33 |perl-Text-Fuzzy-0.29-1.fc33
   |perl-Text-Fuzzy-0.29-1.el8  |perl-Text-Fuzzy-0.29-1.el8
   ||perl-Text-Fuzzy-0.29-1.el7



--- Comment #10 from Fedora Update System  ---
FEDORA-EPEL-2020-4749700a36 has been pushed to the Fedora EPEL 7 stable
repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1904632] perl-File-Edit-Portable-1.25 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-File-Edit-Portable-1.2 |perl-File-Edit-Portable-1.2
   |5-1.fc33|5-1.fc33
   |perl-File-Edit-Portable-1.2 |perl-File-Edit-Portable-1.2
   |5-1.el8 |5-1.el8
   ||perl-File-Edit-Portable-1.2
   ||5-1.el7



--- Comment #9 from Fedora Update System  ---
FEDORA-EPEL-2020-f42df408d7 has been pushed to the Fedora EPEL 7 stable
repository.
If problem still persists, please make note of it in this bug report.


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

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d4406c9c75   
awstats-7.8-2.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-001e4d949f   
dia-0.97.3-16.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

mhonarc-2.6.24-2.el8
python-typeguard-2.10.0-1.el8
tcpick-0.2.1-38.el8

Details about builds:



 mhonarc-2.6.24-2.el8 (FEDORA-EPEL-2021-a69a2d1d18)
 Perl mail-to-HTML converter

Update Information:

Update to 2.6.24

ChangeLog:

* Mon Dec 14 2020 Xavier Bachelot  - 2.6.24-2
- Better URL: and Source0:
* Tue Dec  1 2020 Xavier Bachelot  - 2.6.24-1
- Update to 2.6.24 (RHBZ#1901625)
- Specfile cleanup
* Tue Jul 28 2020 Fedora Release Engineering  - 
2.6.19-20
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Mon Jun 22 2020 Jitka Plesnikova  - 2.6.19-19
- Perl 5.32 rebuild
* Wed Jan 29 2020 Fedora Release Engineering  - 
2.6.19-18
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild




 python-typeguard-2.10.0-1.el8 (FEDORA-EPEL-2021-05540e9f05)
 Run-time type checker for Python

Update Information:

initial epel8 build

ChangeLog:


References:

  [ 1 ] Bug #1912142 - Please build python-typeguard for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1912142




 tcpick-0.2.1-38.el8 (FEDORA-EPEL-2021-b84199922f)
 A tcp stream sniffer, tracker and capturer

Update Information:

tcpick is a textmode sniffer that can track tcp streams and saves the data
captured in files or displays them in the terminal. Useful for picking files in
a passive way.  It can store all connections in different files, or it can
display all the stream on the terminal. It is useful to keep track of what users
of a network are doing, and is usable with textmode tools like grep, sed and
awk. It can handle eth and ppp interfaces.

ChangeLog:



___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1904632] perl-File-Edit-Portable-1.25 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-File-Edit-Portable-1.2 |perl-File-Edit-Portable-1.2
   |5-1.fc33|5-1.fc33
   ||perl-File-Edit-Portable-1.2
   ||5-1.el8



--- Comment #8 from Fedora Update System  ---
FEDORA-EPEL-2020-ed709adfc2 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1906282] perl-Text-Fuzzy-0.29 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Text-Fuzzy-0.29-1.fc33 |perl-Text-Fuzzy-0.29-1.fc33
   ||perl-Text-Fuzzy-0.29-1.el8



--- Comment #9 from Fedora Update System  ---
FEDORA-EPEL-2020-dac81b46d0 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1909364] perl-CPANPLUS-0.9910 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-8dc1b2602a has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1908799] perl-LWP-Protocol-https-6.10 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-LWP-Protocol-https-6.1 |perl-LWP-Protocol-https-6.1
   |0-1.fc34|0-1.fc34
   |perl-LWP-Protocol-https-6.1 |perl-LWP-Protocol-https-6.1
   |0-1.fc32|0-1.fc32
   ||perl-LWP-Protocol-https-6.1
   ||0-1.fc33



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-d7f21b3224 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1821881] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [fedora-all]

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Convert-ASN1-0.27-21.f |perl-Convert-ASN1-0.27-21.f
   |c34 |c34
   |perl-Convert-ASN1-0.27-19.f |perl-Convert-ASN1-0.27-19.f
   |c32 |c32
   ||perl-Convert-ASN1-0.27-21.f
   ||c33



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-9fa782be3e has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1909364] perl-CPANPLUS-0.9910 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-8e0d016a7b has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1908799] perl-LWP-Protocol-https-6.10 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-LWP-Protocol-https-6.1 |perl-LWP-Protocol-https-6.1
   |0-1.fc34|0-1.fc34
   ||perl-LWP-Protocol-https-6.1
   ||0-1.fc32
 Resolution|--- |ERRATA
Last Closed||2021-01-05 01:18:53



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-6296f09d90 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1910780] perl-ExtUtils-HasCompiler-0.023 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-f46734aa7b has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-f46734aa7b`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-f46734aa7b

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

[Bug 1910310] perl-libnet-3.13 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-819abf0dbb has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-819abf0dbb`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-819abf0dbb

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

[Bug 1910394] perl-Devel-PatchPerl-2.06 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-7fdf29563e has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-7fdf29563e`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-7fdf29563e

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

[Bug 1910105] perl-Net-SSH2-0.72 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-fe5f5b7782 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-fe5f5b7782`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-fe5f5b7782

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

[Bug 1910204] perl-DateTime-TimeZone-2.46 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-ec92254ec1 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-ec92254ec1`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec92254ec1

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[clime]

...snip...

Btw. I posted a long comment here: https://pagure.io/fesco/issue/2532
basically trying to explain the proposal more and mention the
use-cases where it would be useful. So, please, read if you are
interested. I guess, if there is a further discussion it should be
probably carried out here so that it is available for everyone.

One more thing... it's interesting to note that 12 years ago, we had a
very similar discussion to what we have today:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/I35MFMMIDO5FFY3ZFCXGE26PREPPWPCA/#DEJUEWXMAZND626D7ZOSOIFHGWSYGPAG
 - the problem of generating release by using build system vs. using
just cvs/git was discussed there (Colin Walters vs. Jesse Keating). It
would be interesting to know what people discussing the topic in the
thread think about it today.

clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[clime]

On Mon, 4 Jan 2021 at 20:43, Dan Čermák  wrote:
>
> clime  writes:
>
> > ...snip...
> >> >
> >> > $ preproc-rpmspec pkg.spec.rpkg  # prints rendered spec to stdout,
> >> > pkg.spec.rpkg is a spec template
> >>
> >> This would be a viable workaround, but a workaround nevertheless. Since
> >> I am not frequently rebuilding Fedora rpms outside of mock, koji & copr,
> >> I cannot tell how much of a show-stopper that is though. At least I
> >> think that the benefits of the change need to be pretty big to outweigh
> >> this potential downside.
> >
> > If I may ask, why do you think using preproc-rpmspec is a workaround?
>
> I consider it a workaround, because it adds another step to the
> packaging process outside of koji & copr: it still works, but you have
> to go through extra steps.

Yes, there is an extra step that would be wrapped in higher-level tooling.

But when you said "workaround", I was thinking that you actually saw
the correct solution because "workaround" is imho used usually when
someone can't or don't want to solve things the right way so he/she
takes a shortcut. So I was curious what you think is "the right way"
here.

>
>
> 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

Re: Delta RPMs in Fedora 34

[Kevin Fenzi]

On Mon, Jan 04, 2021 at 06:29:13PM -0500, Matthew Miller wrote:
> On Mon, Jan 04, 2021 at 10:21:15PM +, Matthew Almond via devel wrote:
> > There's been a lot of interesting talk about the state and future of
> > drpm. I'd like to propose we continue the conversation about that with
> > a different subject line :)
> 
> Okay, fair. I have a proposal. 
> 
> Right now, the problem is that making delta rpms is expensive, and therefore
> we aren't making very many, which makes them even less useful. Plus, we're
> only making them between updates and for packages where those updates are
> frequent, that means you need to keep on top of things, which may be best
> practice but is most difficult for low-bandwidth users who might most
> benefit in the first place.
> 
> So, the first thing we need to do to fix this is move deltarpm creation out
> of the updates process. Kevin Fenzi tells me this would mean we'd need a
> separate delta RPMs repo, which doesn't sound like a bad thing to me, but
> we're not sure offhand if DNF can handle that without modification.

Yeah, I don't recall how dnf looks for drpms. 
Right now they are in the same repo, using the same repodata. 

If we moved them to a new repo would they get found correctly?

> This would let us make the delta RPMs asynchronously and not block updates.
> And, it would also give us the ability to roughly see how important they are
> to users, because we could see how popular that repository is compared to
> the updates repo.
> 
> I also remember when this was a killer feature for Fedora, and without any
> real way of judging use and demand, I'm hesitant to kill it off. But that's
> definitely plan B. We can point people who are in low-bandwidth situations
> at Silverblue, CoreOS, and Kinoite as the preferred approach.

Yeah, I came up with one more possible way we could get more drpms with
our current setup, but need to talk to pungi maintainers and see if it's
doable. :) After that, it's either split things out or drop drpms I
think. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Delta RPMs in Fedora 34

[Matthew Miller]

On Mon, Jan 04, 2021 at 10:21:15PM +, Matthew Almond via devel wrote:
> There's been a lot of interesting talk about the state and future of
> drpm. I'd like to propose we continue the conversation about that with
> a different subject line :)

Okay, fair. I have a proposal. 

Right now, the problem is that making delta rpms is expensive, and therefore
we aren't making very many, which makes them even less useful. Plus, we're
only making them between updates and for packages where those updates are
frequent, that means you need to keep on top of things, which may be best
practice but is most difficult for low-bandwidth users who might most
benefit in the first place.

So, the first thing we need to do to fix this is move deltarpm creation out
of the updates process. Kevin Fenzi tells me this would mean we'd need a
separate delta RPMs repo, which doesn't sound like a bad thing to me, but
we're not sure offhand if DNF can handle that without modification.

This would let us make the delta RPMs asynchronously and not block updates.
And, it would also give us the ability to roughly see how important they are
to users, because we could see how popular that repository is compared to
the updates repo.

I also remember when this was a killer feature for Fedora, and without any
real way of judging use and demand, I'm hesitant to kill it off. But that's
definitely plan B. We can point people who are in low-bandwidth situations
at Silverblue, CoreOS, and Kinoite as the preferred approach.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1912612] New: perl-HTTP-Cookies-6.10 is available

[bugzilla]

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

Bug ID: 1912612
   Summary: perl-HTTP-Cookies-6.10 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-HTTP-Cookies
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.10
Current version/release in rawhide: 6.09-1.fc34
URL: http://search.cpan.org/dist/HTTP-Cookies/

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/2974/


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

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

[Tom Stellard]

On 1/4/21 11:28 AM, Jeff Law wrote:



On 1/4/21 12:22 PM, Tom Stellard wrote:

On 12/30/20 11:52 AM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/LTOBuildImprovements


== Summary ==
Currently all packages that are not opted out of LTO include
-ffat-lto-objects in their build flags.  This proposal would remove
-ffat-lto-objects from the default LTO flags and only use it for
packages that actually need it.

== Owner ==
* Name: [[User:law | Jeff Law]]
* Email: l...@redhat.com


== Detailed Description ==
-ffat-lto-objects was added to the default LTO flags to ensure that
any installed .o/.a files included actual compiled code rather than
just LTO bytecodes (which are stripped after the install phase).
However, that is wasteful from a compile-time standpoint as few
packages actually install any .o/.a files.

This proposal would remove -ffat-lto-objects from the default LTO
flags and packages that actually need the option would have to opt-in
via an RPM macro in their .spec file.  This should significantly
improve build times for most packages in Fedora.



What is this macro going to be called?  I would like to get an early
start on updating my packages.

No idea.  I'm open to suggestions.

IIRC we had kicked around the idea of having the clang/llvm path
instantiate the LTO bytecodes in .o/.a files, which would avoid these
issues for packages using clang/llvm.  Is that something we still want
to pursue?  I vaguely recall discussing this with David B. and he came
up with a reason why that needed to happen before brp-strip-lto, but I
can't remember any of the details at this point.



Yes, David is still working on a solution for clang/llvm.  I'm not sure, 
though, at what point in the RPM build process the LTO bytecode will get

codegen'd.

-Tom


Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Delta RPMs in Fedora 34

[Matthew Almond via devel]

On Mon, 2021-01-04 at 11:25 -0500, Matthew Miller wrote:
> On Sun, Jan 03, 2021 at 03:25:29PM -0800, Kevin Fenzi wrote:
> > I remember when drpms landed I heard people say they choose Fedora
> > because of them. That may have changed over the years I guess. :) 
> > and there have been only 2 or 3 reports about how few drpms exist
> > in the last few years (ie, most people didn't really notice). 
> 
> Hmmm, here's an idea: what if instead of nightly drpms, we made them
> only
> every two weeks, but always exactly two weeks, so that people
> updating on a
> specific cadence would get them?

There's been a lot of interesting talk about the state and future of
drpm. I'd like to propose we continue the conversation about that with
a different subject line :)

- Matthew
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)

[Matthew Almond via devel]

On Sun, 2021-01-03 at 16:16 -0500, Colin Walters wrote:
> 
> On Sat, Jan 2, 2021, at 10:03 AM, Zbigniew Jędrzejewski-Szmek wrote:
> 
> > I fail to see why this would be significantly better...
> 
> I don't claim that the "separate temporary directory of unpacked
> content" is *better* - just that it's as easy to implement *and*
> doesn't require an RPM format change (with all the consequent pain)
> or support for reflinks from the underlying filesystem.
> 
> >  The logic to
> > handle the split rpm contents would seem to be more complicated
> > than the
> > rewrite with /usr/bin/rpm2extents. Other comments?
> 
> Hard to really say for sure I guess without trying to write
> both.  Probably the biggest impediment is that changes like that
> would end up needing to be split across the librpm + zypper/rpm-
> ostree/dnf tools.  It wasn't an accident really that for rpm-ostree
> /usr/bin/rpm is read-only - we effectively squash those layers
> togther and can thus make deep changes as a single unit.
> 
> Anyways, none of this really *requires* reflinks in any way and so
> calling the Change "RPMCoW" is misleading from that
> perspective.  "DnfParallelUnpack" would probably be a better title,
> with a dependency on "RPMFormatCowReady" or something.  And then my
> point is that one could do "DnfParallelUnpack" without changing the
> RPM format without much more complexity, if any.

Early on in this project I looked at creating all the files during
download in a temporary directory. It would work. It is more filesystem
type agnostic. If moving the decompression to an earlier step were the
sole goal, it's reasonable.

The goal of RPMCoW is to write once, and re-use data multiple times.
This comes up in a number of circumstances for this proposal:

1. Reflinking allows for de-duplication of file content. Today this is 
   only within a single RPM. I am looking at changing rpm2extents to
   reuse data across (cached) rpms to achieve something kind of like
   delta rpm. That is: if you already have file X, you don't write it,
   you clone it from any other rpm.
2. Reflinking allows sharing of file contents, without side effects 
   from the installed copy. Each copy is a real, distinct file, can be 
   deleted and or modified. Only the differences cost something, and
   99% of rpms files don't get modified. The net result is that the 
   rpm cache costs very little.
3. If you can keep a rpm cache, you can reuse the data very quickly, 
   either to build a new rootfs in a subdir/subvolume with the same or 
   different packages, and you can use those files for containers.
   This sounds similar to using snapshots, but with snapshots you're
   operating on a filesystem at a time, and you can only go backwards.
   Here you can decide what you want, and you get maximum reuse 
   automatically.

By contrast "DnfParallelUnpack" by itself, without CoW, is less useful
because you will need to re-fetch and re-decompress data.

Lastly, I'd like to emphasize that I'm not trying to change the "normal
rpm format". Doing so would orphan every previously built and signed
rpm, and would present a serious backward compatibility problem. I aim
to only change how they're downloaded and stored in the cache, locally,
and consumed in rpm itself within the confines of hosts that (can)
enable this.

- Matthew
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora kernel, from version 5.7.6 no longer works on AMD Navi 10 GPUs for PPC64el

[Chris Murphy]

On Mon, Jan 4, 2021 at 2:39 PM Maurizio Mileto  wrote:
>
> Hello everyone, I would like to resume this discourse because unfortunately 
> after months of reports, unfortunately no solution has yet been reached. I 
> wanted to say once again to you all Fedora staff that unfortunately, on 
> PowerPC64le architecture, since the Kernel moved from version 5.6.19 to 
> version 5.7.X, it never worked with AMD Navi 10 GPUs anymore. arrived at 
> version 5.9.X, the computer crashes irreversibly and must be turned off and 
> on again in order to recover it. Is it possible that no one can fix this damn 
> bug? There seems to be a conflict between the Navi 10 software and the 
> software that was introduced from Kernel 5.7.X onwards ... Please help us ...

Can you provide URLs for the reports? In particular the upstream AMD
bug report? And has anyone done a kernel bisect to determine what
commit introduced the bug?


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora kernel, from version 5.7.6 no longer works on AMD Navi 10 GPUs for PPC64el

[Maurizio Mileto]

Hello everyone, I would like to resume this discourse because unfortunately 
after months of reports, unfortunately no solution has yet been reached. I 
wanted to say once again to you all Fedora staff that unfortunately, on 
PowerPC64le architecture, since the Kernel moved from version 5.6.19 to version 
5.7.X, it never worked with AMD Navi 10 GPUs anymore. arrived at version 5.9.X, 
the computer crashes irreversibly and must be turned off and on again in order 
to recover it. Is it possible that no one can fix this damn bug? There seems to 
be a conflict between the Navi 10 software and the software that was introduced 
from Kernel 5.7.X onwards ... Please help us ...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Mass spec file change: Adding BuildRequires: make

[Tom Stellard]

On 11/30/20 2:06 PM, Tom Stellard wrote:

Hi,

As part of the f34 change request[1] for removing make from the 
buildroot, I will be doing a mass update of packages[2] to add 
BuildRequires: make where it is needed.


If you are a package maintainer and would prefer to update your packages 
on your own, please do so before Dec 14, which is when I will begin 
doing the mass update.


I will be doing the updates in batches, so that if there is a mistake 
the impact will be limited.  Here is the rough schedule of the changes:


Dec 14: Update first 50 packages.
Dec 16: Next 1000.
Dec 18: Next 1000.
Jan 4:  Next 1000.


Here are the list of packages that will be updated today:

https://fedorapeople.org/~tstellar/br_make_day4.txt

-Tom



Jan 5:  Next 1000.
Jan 6:  Next 1000.
Jan 7:  Next 1000.
Jan 8:  Rest of packages.

The deadline for completing these updates is the start of the f34 mass 
rebuild (Jan 20).


Thanks,
Tom

[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
[2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1912587] New: please build an EPEL8 build for perl-X11-Protocol and perl-X11-Protocol-Other

[bugzilla]

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

Bug ID: 1912587
   Summary: please build an EPEL8 build for perl-X11-Protocol and
perl-X11-Protocol-Other
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-X11-Protocol
  Assignee: jples...@redhat.com
  Reporter: rosset.fil...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: i...@cicku.me, j...@jima.us, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Hi, please build an EPEL8 build for perl-X11-Protocol and
perl-X11-Protocol-Other

I need theses packages to build clusterssh for EPEL8.

perl-X11-Protocol -> only remove perl-doc requires
perl-X11-Protocol-Other -> rely on perl-X11-Protocol


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

[EPEL-devel] Re: %{python3} no defined in epel-7-aarch64?

[Florian Weimer]

* Miro Hrončok:

> Yes. The macro was added to EPEL 7 only after aarch64 was discontinued there:
>
> https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/YVLZGTBBW2M3GMXHLIA2QMKENBEGPEJY/
>
> No easy way to solve this except to stop building for aarch64 on EPEL
> 7. You could use the %__python3 macro instead to workaround this
> particular problem, but you will most likely hit another one later.

aarch64 is completely EOL on 7, so you should just stop building it.
There is no Extended Update Support and no Extended life cycle support
for it.



Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Copr in 2020 and outlook for 2021

[Miro Hrončok]

On 04. 01. 21 20:53, Miro Hrončok wrote:

On 04. 01. 21 20:48, Miroslav Suchý wrote:

Dne 04. 01. 21 v 20:14 Miro Hrončok napsal(a):

Is there any
chance we could vote for GitHub Actions enablement instead of Travis?
Currently we run a Fedora Docker image on top of the Ubuntu host,
which is less than ideal in some cases (e.g., filesystem package
upgrades...).


I wanted to ask the same thing.


https://pavel.raiskup.cz/blog/github-push-actions-and-copr.html

This is very basic example. Can you give me example of workflows you would 
like to set up? So we can document them (or

check whether there is some blocker).


I am talking about running upstream tests via GitHub actions on Fedora directly 
instead of dockerized Fedora on Ubuntu. E.g. the "Native support for Fedora in 
Travis" point in the original email (the line I forgot to quote). Not about Copr.


As a specific example of a GH Actions workflow, I would like to do this:

jobs:
  build:
runs-on: fedora-latest
steps:
- ...

--
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

Re: %{python3} no defined in epel-7-aarch64?

[Sérgio Basto]

On Mon, 2021-01-04 at 17:38 +, José Abílio Matos wrote:
> I have used copr to build the first alpha release of lyx-2.4:
> 
> https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/build/1858028/ 
> 
> 
> For EPEL7 it build for x86_64 and it fails for aarch64, due to
> %{python3} not being defined.
> 
> 
> 
> The spec file has BR: python3-devel.
> 
> 
> In the install stage I have this:
> 
> 
> %py_byte_compile %{python3} %{buildroot}%{_datadir}/%{name}/lyx2lyx
> 
> 
> 
> This fails in epel-7-aarch64:
> 
> https://download.copr.fedorainfracloud.org/results/jamatos/lyx-devel/epel-7-aarch64/01858028-lyx-devel/build.log.gz
>  
> 
> "
> 
> + python_binary='%{python3}'
> 
> + buildroot_path=/builddir/build/BUILDROOT/lyx-devel-2.4.0-
> 0.2.alpha1.el7.aarch64/usr/share/lyx-devel/lyx2lyx
> 
> ~/build/BUILDROOT/lyx-devel-2.4.0-0.2.alpha1.el7.aarch64
> ~/build/BUILD/lyx-2.4.0-alpha1
> 
> + bytecode_compilation_path=./usr/share/lyx-devel/lyx2lyx
> 
> + failure=0
> 
> + pushd /builddir/build/BUILDROOT/lyx-devel-2.4.0-
> 0.2.alpha1.el7.aarch64
> 
> + xargs -0 '%{python3}' -O -m py_compile
> 
> + find ./usr/share/lyx-devel/lyx2lyx -type f -a -name '*.py' -print0
> 
> xargs: %{python3}: No such file or directory
> 
> + failure=1
> 
> + xargs -0 '%{python3}' -m py_compile
> 
> + find ./usr/share/lyx-devel/lyx2lyx -type f -a -name '*.py' -print0
> 
> xargs: %{python3}: No such file or directory
> 
> + failure=1
> 
> ~/build/BUILD/lyx-2.4.0-alpha1
> 
> + popd
> 
> + test 1 -eq 0
> 
> "
> 
> while in the corresponding x86_64 the first line correctly sets:
> 
> + python_binary=/usr/bin/python3
> 
> 
> Is this known?

yes,  you may want BR python36-devel , take a look at 
https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3orhttps://src.fedoraproject.org/rpms/python3-dateutil/blob/epel7/f/python3-dateutil.spec
 id="-x-evo-selection-start-marker">



-- 
Sérgio M. B.

___
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

Re: Copr in 2020 and outlook for 2021

[Miro Hrončok]

On 04. 01. 21 20:48, Miroslav Suchý wrote:

Dne 04. 01. 21 v 20:14 Miro Hrončok napsal(a):

Is there any
chance we could vote for GitHub Actions enablement instead of Travis?
Currently we run a Fedora Docker image on top of the Ubuntu host,
which is less than ideal in some cases (e.g., filesystem package
upgrades...).


I wanted to ask the same thing.


https://pavel.raiskup.cz/blog/github-push-actions-and-copr.html

This is very basic example. Can you give me example of workflows you would like 
to set up? So we can document them (or
check whether there is some blocker).


I am talking about running upstream tests via GitHub actions on Fedora directly 
instead of dockerized Fedora on Ubuntu. E.g. the "Native support for Fedora in 
Travis" point in the original email (the line I forgot to quote). Not about Copr.


--
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

Re: Copr in 2020 and outlook for 2021

[Miroslav Suchý]

Dne 04. 01. 21 v 20:14 Miro Hrončok napsal(a):
>> Is there any
>> chance we could vote for GitHub Actions enablement instead of Travis?
>> Currently we run a Fedora Docker image on top of the Ubuntu host,
>> which is less than ideal in some cases (e.g., filesystem package
>> upgrades...).
> 
> I wanted to ask the same thing.

https://pavel.raiskup.cz/blog/github-push-actions-and-copr.html

This is very basic example. Can you give me example of workflows you would like 
to set up? So we can document them (or
check whether there is some blocker).

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Dan Čermák]

clime  writes:

> ...snip...
>> >
>> > $ preproc-rpmspec pkg.spec.rpkg  # prints rendered spec to stdout,
>> > pkg.spec.rpkg is a spec template
>>
>> This would be a viable workaround, but a workaround nevertheless. Since
>> I am not frequently rebuilding Fedora rpms outside of mock, koji & copr,
>> I cannot tell how much of a show-stopper that is though. At least I
>> think that the benefits of the change need to be pretty big to outweigh
>> this potential downside.
>
> If I may ask, why do you think using preproc-rpmspec is a workaround?

I consider it a workaround, because it adds another step to the
packaging process outside of koji & copr: it still works, but you have
to go through extra steps.


Cheers,

Dan


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Copr in 2020 and outlook for 2021

[Miroslav Suchý]

Dne 04. 01. 21 v 20:36 Dan Čermák napsal(a):
> Is it intentional that google asks me to sign in? I don't actually have
> a google account.

Yes. It is intentional. The motivation is that you can change your vote later.

If you do not have google account then just write me an email. I will add it to 
spreadsheet manually.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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

[EPEL-devel] Re: %{python3} no defined in epel-7-aarch64?

[Miro Hrončok]

On 04. 01. 21 18:38, José Abílio Matos wrote:

I have used copr to build the first alpha release of lyx-2.4:

https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/build/1858028/ 




For EPEL7 it build for x86_64 and it fails for aarch64, due to %{python3} not 
being defined.




The spec file has BR: python3-devel.


In the install stage I have this:


%py_byte_compile %{python3} %{buildroot}%{_datadir}/%{name}/lyx2lyx



This fails in epel-7-aarch64...


Is this known?


Yes. The macro was added to EPEL 7 only after aarch64 was discontinued there:

https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/YVLZGTBBW2M3GMXHLIA2QMKENBEGPEJY/

No easy way to solve this except to stop building for aarch64 on EPEL 7. You 
could use the %__python3 macro instead to workaround this particular problem, 
but you will most likely hit another one later.



I wonder whether Copr should disable EPEL 7 aarch64 chroots or at least put a 
big red sign next to them.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: %{python3} no defined in epel-7-aarch64?

[Miro Hrončok]

On 04. 01. 21 18:38, José Abílio Matos wrote:

I have used copr to build the first alpha release of lyx-2.4:

https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/build/1858028/ 




For EPEL7 it build for x86_64 and it fails for aarch64, due to %{python3} not 
being defined.




The spec file has BR: python3-devel.


In the install stage I have this:


%py_byte_compile %{python3} %{buildroot}%{_datadir}/%{name}/lyx2lyx



This fails in epel-7-aarch64...


Is this known?


Yes. The macro was added to EPEL 7 only after aarch64 was discontinued there:

https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/YVLZGTBBW2M3GMXHLIA2QMKENBEGPEJY/

No easy way to solve this except to stop building for aarch64 on EPEL 7. You 
could use the %__python3 macro instead to workaround this particular problem, 
but you will most likely hit another one later.



I wonder whether Copr should disable EPEL 7 aarch64 chroots or at least put a 
big red sign next to them.


--
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

Re: Copr in 2020 and outlook for 2021

[Dan Čermák]

Hi,

Miroslav Suchý  writes:

> Let me sum up what we - the Copr team - did in 2020:
>
>  * We enabled CDN for repos. https://fedora-copr.github.io/posts/copr-cdn
>
>  * We enabled runtime dependecies on repositories 
> https://fedora-copr.github.io/posts/runtime-dependencies
>
>  * We migrated all our servers from PHX datacenter to AWS. With zero downtime 
> for your repos.
>
>  * Pavel Raiskup became the new Mock project leader, and he released seven 
> new versions of Mock during 2020.
> https://github.com/rpm-software-management/mock/wiki
>
>  * Our small team has been renamed to Community Packaging Team (CPT) because 
> beside Copr, we maintain other tools as
> well: Mock, dist-git, Tito...
>
>  * We drove changes in createrepo_c, which allowed us better throughput. Now, 
> Copr can build thousands of builds per day.
>
>  * We worked on Fedora packages website, which was outdated and do not work 
> on recent Fedora. Unfortunately, it will not
> be likely used, and static pages will be used as it will require less 
> maintenance.
>
>  * We introduced Project scoring for projects in Copr (up/down vote) 
> http://frostyx.cz/posts/upvoting-projects-in-copr
>
>  * We allowed you to delete multiple builds at once. 
> https://fedora-copr.github.io/posts/deleting-list-of-builds
>
>  * You can use Github Actions now 
> https://pavel.raiskup.cz/blog/github-push-actions-and-copr.html
>
>  * We created modulemd-tools for low-level handling of repositories and 
> modules. And tool for generating
> module-build-macros. https://github.com/rpm-software-management/modulemd-tools
>
>  * We worked hard on better EOL handling of Copr repositories.
>
>  * We parallelized copr-dist-git imports.
>
>  * We wrote code for Ansible DNF Copr module. This still needs to land in a 
> proper place like Ansible Galaxy.
> https://pagure.io/copr/copr/blob/master/f/ansible
>
>  * We provided --isolation=* and --bootstrap=* knob in Copr
>
>  * We started an experimental "external dependencies" feature in Mock.
> https://github.com/rpm-software-management/mock/wiki/Feature-external-deps
>
>  * We created a new python module "templated-dictionary" as a spin-off from 
> Mock's code.
> https://github.com/xsuchy/templated-dictionary
>
>  * We wrote four articles "4 cool new projects to try in COPR" 
> https://fedoramagazine.org/tag/copr/
>
>  * Users now have the ability to change the build timeout up to a maximum of 
> 48 hours
>
>  * Users can group builds in batches now. 
> https://pavel.raiskup.cz/blog/build-ordering-by-batches-in-copr.html
>

That's quite an impressive list!

>
> We already have plans to do:
>
>  * Verify GPG checks in DNF using DNSSEC. 
> https://pagure.io/copr/copr/issue/406
>
>  * Improve hooks (in cooperation with Packit team)
>
>  * We are going to EOL APIv1 and APIv2 
> https://fedora-copr.github.io/posts/EOL-APIv1-APIv2
>
>
> What will we do in 2021? We have some ideas. Some of them are yours, some of 
> them are ours. At the end of this email is
> a link to Google Form where you can vote what you would like to get. We will 
> consider your vote. (listed in no specific
> order)
>
>  * When you create a project, you may specify that it will be for Package 
> Review. We do some settings for you, and
> `rpminspect`  will be run automatically at the end of the build. We can guide 
> users on how to file Package Review BZ. Or
> do that automatically on their behalf.
>
>  * Contribute to fedpkg/Koji that tagged commits will be automatically built 
> in Koji and may be automatically sent to Bodhi.
>
>  * Help with automatic changelog entries.
>
>  * Native support for Fedora in Travis.

I'd say don't bother with Travis, they are becoming increasingly
unusable for non-paying users and I've seen many projects migrate to
github actions.

>
>  * Continue on external dependencies. 
> https://github.com/rpm-software-management/mock/wiki/Feature-external-deps
>
>  * Finish rpm-spec-wizard https://github.com/xsuchy/rpm-spec-wizard
>
>  * Better integration with Koshei.
>
>  * Automatic rebuilds in Copr when dependency change (likely with the help of 
> Koshei)

YES! Please, please, please make this possible. And an additional box of
cookies for you all if it will work with dynamic buildrequires ;-)

>
>  * Enhance release-monitoring and rebase-helper to automatically open PR in 
> Pagure when new version is available.
>
>  * Enhance `Mock --chain` to try to set %bootstrap when standard loop fails. 
> When the set succeeds, rebuild the
> bootstrapped package again without %bootstrap macro.
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
>
>  * Improve the process of finding a sponsor for the first package.
>
>  * Contribute to fedpkg/koji to have machine-readable output.
>
> Please vote here: https://forms.gle/UuH86ECzfZNHJgEr8
> The results are intentionally publicly available. You may check them anytime.
>

Is it intentional that google asks me to sign in? I don't actually have
a google account.

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

[Jeff Law]

On 1/2/21 10:39 AM, Ian McInerney wrote:
>
>
> On Sat, Jan 2, 2021 at 5:33 PM Jeff Law  > wrote:
>
>
>
> On 12/30/20 3:48 PM, Ian McInerney wrote:
> >
> >
> > On Wed, Dec 30, 2020 at 7:54 PM Ben Cotton  
> > >> wrote:
> >
> >     https://fedoraproject.org/wiki/Changes/LTOBuildImprovements
> 
> >      >
> >
> >
> >     == Summary ==
> >     Currently all packages that are not opted out of LTO include
> >     -ffat-lto-objects in their build flags.  This proposal would
> remove
> >     -ffat-lto-objects from the default LTO flags and only use it for
> >     packages that actually need it.
> >
> >     == Owner ==
> >     * Name: [[User:law | Jeff Law]]
> >     * Email: l...@redhat.com 
> >
> >
> >
> >     == Detailed Description ==
> >     -ffat-lto-objects was added to the default LTO flags to
> ensure that
> >     any installed .o/.a files included actual compiled code
> rather than
> >     just LTO bytecodes (which are stripped after the install phase).
> >     However, that is wasteful from a compile-time standpoint as few
> >     packages actually install any .o/.a files.
> >
> >     This proposal would remove -ffat-lto-objects from the
> default LTO
> >     flags and packages that actually need the option would have
> to opt-in
> >     via an RPM macro in their .spec file.  This should significantly
> >     improve build times for most packages in Fedora.
> >
> >
> > Does this mean that packages that are explicitly shipping a static
> > library to the end user need to enable this macro to allow the
> > installed static library to be usable by an end-user's compiler? If
> > this is the case, then the packaging guidelines should be updated to
> > reflect this.
> Yes and the change request reflects that an update to the packaging
> guidelines is necessary.
>
>
> The proposal only says the macro will be documented, but doesn't go
> into any more detail. I think it would be beneficial if the proposal
> mentioned the macro would become required for static library packages
> and that policy needs to be added - since that is adding a new MUST
> section to the packaging guidelines.
ACK.  I'll add some additional text to the proposal.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

[Jeff Law]

On 1/4/21 12:22 PM, Tom Stellard wrote:
> On 12/30/20 11:52 AM, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/LTOBuildImprovements
>>
>>
>> == Summary ==
>> Currently all packages that are not opted out of LTO include
>> -ffat-lto-objects in their build flags.  This proposal would remove
>> -ffat-lto-objects from the default LTO flags and only use it for
>> packages that actually need it.
>>
>> == Owner ==
>> * Name: [[User:law | Jeff Law]]
>> * Email: l...@redhat.com
>>
>>
>> == Detailed Description ==
>> -ffat-lto-objects was added to the default LTO flags to ensure that
>> any installed .o/.a files included actual compiled code rather than
>> just LTO bytecodes (which are stripped after the install phase).
>> However, that is wasteful from a compile-time standpoint as few
>> packages actually install any .o/.a files.
>>
>> This proposal would remove -ffat-lto-objects from the default LTO
>> flags and packages that actually need the option would have to opt-in
>> via an RPM macro in their .spec file.  This should significantly
>> improve build times for most packages in Fedora.
>>
>
> What is this macro going to be called?  I would like to get an early
> start on updating my packages.
No idea.  I'm open to suggestions.

IIRC we had kicked around the idea of having the clang/llvm path
instantiate the LTO bytecodes in .o/.a files, which would avoid these
issues for packages using clang/llvm.  Is that something we still want
to pursue?  I vaguely recall discussing this with David B. and he came
up with a reason why that needed to happen before brp-strip-lto, but I
can't remember any of the details at this point.

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

[Tom Stellard]

On 12/30/20 11:52 AM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/LTOBuildImprovements


== Summary ==
Currently all packages that are not opted out of LTO include
-ffat-lto-objects in their build flags.  This proposal would remove
-ffat-lto-objects from the default LTO flags and only use it for
packages that actually need it.

== Owner ==
* Name: [[User:law | Jeff Law]]
* Email: l...@redhat.com


== Detailed Description ==
-ffat-lto-objects was added to the default LTO flags to ensure that
any installed .o/.a files included actual compiled code rather than
just LTO bytecodes (which are stripped after the install phase).
However, that is wasteful from a compile-time standpoint as few
packages actually install any .o/.a files.

This proposal would remove -ffat-lto-objects from the default LTO
flags and packages that actually need the option would have to opt-in
via an RPM macro in their .spec file.  This should significantly
improve build times for most packages in Fedora.



What is this macro going to be called?  I would like to get an early 
start on updating my packages.


-Tom


To ensure that we can identify packages that need the opt-in now and
in the future, the plan is to pass to brp-strip-lto a flag indicating
whether or not the package has opted into -ffat-lto-objects.  If
brp-strip-lto finds .o/.a files, but the package has not opted into
-ffat-lto-objects, then brp-strip-lto would signal an error.


== Benefit to Fedora ==
The key benefit to Fedora is improved package build times and lower
load on the builders.

== Scope ==
* Proposal owners: The feature owner (Jeff Law) will need to settle on
a suitable RPM macro to indicate an opt-in to -ffat-lto-objects,
implement the necessary tests in brp-strip-lto and opt-in the initial
set of packages.  This will be accomplished by doing the prototype
implementation locally, building all the Fedora packages to generate
the opt-in set.  Committing the necessary opt-ins, then committing the
necessary changes to the RPM macros.

* Other developers:  There should be minimal work for other
developers.  The most likely scenarios where other developers will
need to get involved would include:
# Packages which are excluded from x86_64 builds and which need the
opt-in will need the appropriate package owners to add the opt-in.
# Packages which are FTBFS when the builds are run to find the set of
packages that need to opt-in and which need to opt-in will need
packager attention.
# It is possible that the faster builds may trigger build failures in
packages that have missing dependencies in their Makefiles.  We saw a
few of these during the initial LTO work and those packages were
either fixed or -j parallelism removed.  This work may expose more of
these problems.

I expect these all to be relatively rare occurences, but with 9000+
packages in Fedora I wouldn't be surprised if we see a few of each of
these issues.

* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed) This
should have no release engineering impacts.
* Policies and guidelines: The packaging guidelines will need to be
updated to document the new macro.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: This proposal does not align with any
current Fedora Objectives.

== Upgrade/compatibility impact ==
This change should have zero impact on upgrade/compatibility.  In
fact, the change should have no user visible impacts.


== How To Test ==
No special testing is needed.  Any issues with this proposal will show
up as FTBFS issues.


== User Experience ==
Users should see no changes to the user experience.

== Dependencies ==
Packages which need to opt-in to -ffat-lto-objects will need their
.spec files updated to include the
new macro.


== Contingency Plan ==
If this can not be completed by final development freeze, then the RPM
macro changes would not be installed and the change could defer to
Fedora 35.
* Contingency mechanism: Proposal owner will only commit the RPM macro
changes once the opt-in package set has been identified and opt-ins
added to those package's spec files.  So no special contingency
mechanism should be needed
* Contingency deadline:  It is most beneficial to have this completed
before the mass rebuild; however, the drop dead date should be beta
freeze.
* Blocks release? No
* Blocks product? No

== Documentation ==
No upstream documentation.  Packaging guidelines will need a minor update.

== Release Notes ==
I do not expect this change to require any release notes.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Re: Copr in 2020 and outlook for 2021

[Miro Hrončok]

On 04. 01. 21 18:40, Alexander Scheel wrote:

  * Native support for Fedora in Travis.

Travis has made a lot of changes to how OSS projects can use it, and
(IMO) burnt a lot of good will in the community. All of our upstream
projects ended up moving off it and onto GitHub Actions. Is there any
chance we could vote for GitHub Actions enablement instead of Travis?
Currently we run a Fedora Docker image on top of the Ubuntu host,
which is less than ideal in some cases (e.g., filesystem package
upgrades...).


I wanted to ask the same thing.

And also to say: Community Packaging Team, you rock!

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1910970] perl-LDAP-0.68 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




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

Fedora-IoT-33-20210104.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/15 (aarch64)

New failures (same test not failed in Fedora-IoT-33-20201226.0):

ID: 751283  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/751283

Old failures (same test failed in Fedora-IoT-33-20201226.0):

ID: 751270  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/751270

Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-33-20201226.0):

ID: 751254  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/751254

Passed openQA tests: 15/16 (x86_64), 13/15 (aarch64)

New passes (same test not passed in Fedora-IoT-33-20201226.0):

ID: 751265  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/751265
ID: 751269  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/751269
ID: 751281  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/751281
ID: 751284  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/751284
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: runtime dependencies not in Requires spec section

[Kevin Kofler via devel]

Rex Dieter wrote:
> It's a linked library, so *yes*, rpmbuild will add it.

Depends on whether the application links directly to libQt5Svg.so.5 or 
whether it uses it only through the plugin-based imageformats API 
(libqsvg.so). (And there's also the iconengines/libqsvgicon.so plugin.)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

pghmcfc pushed to perl-IO-FDPass (master). "Update to 1.3 (..more)"

[notifications]

Notification time stamped 2021-01-04 17:58:43 UTC

From 7344b951f09c4b41d8b4ff34561a98a599e768b8 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Jan 04 2021 17:57:59 +
Subject: Update to 1.3


- New upstream release 1.3
  - Do not leak memory on unsuccessful recv
- Use %license unconditionally

---

diff --git a/perl-IO-FDPass.spec b/perl-IO-FDPass.spec
index 7a11d9e..6fa605d 100644
--- a/perl-IO-FDPass.spec
+++ b/perl-IO-FDPass.spec
@@ -1,6 +1,6 @@
 Name:  perl-IO-FDPass
-Version:   1.2
-Release:   15%{?dist}
+Version:   1.3
+Release:   1%{?dist}
 Summary:   Pass a file descriptor over a socket
 License:   GPL+ or Artistic
 URL:   https://metacpan.org/release/IO-FDPass
@@ -51,17 +51,18 @@ find %{buildroot} -type f -name '*.bs' -empty -delete
 make test
 
 %files
-%if 0%{?_licensedir:1}
 %license COPYING
-%else
-%doc COPYING
-%endif
 %doc Changes README
 %{perl_vendorarch}/auto/IO/
 %{perl_vendorarch}/IO/
 %{_mandir}/man3/IO::FDPass.3*
 
 %changelog
+* Mon Jan  4 2021 Paul Howarth  - 1.3-1
+- Update to 1.3
+  - Do not leak memory on unsuccessful recv
+- Use %%license unconditionally
+
 * Tue Jul 28 2020 Fedora Release Engineering  - 
1.2-15
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
 
diff --git a/sources b/sources
index 0d81447..53966eb 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1f60fc0e6b7982ceb45f63ba8a51e46e  IO-FDPass-1.2.tar.gz
+SHA512 (IO-FDPass-1.3.tar.gz) = 
2392074ce9d2bd7a5d2fcc8b359ef3a57c73258b33b637954ecbf00b15e44de05a211242ab245a47bd8cb18a5d928081a843e731563a23b5436fc2559a71968a



https://src.fedoraproject.org/rpms/perl-IO-FDPass/c/7344b951f09c4b41d8b4ff34561a98a599e768b8?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Fedora 34 Change: Localization measurement and tooling (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/LocalizationMeasurementAndTooling


== Summary ==

Provide a public website for end users and contributors, containing
Fedora Workstation translation progress and useful files for
translators (as an example: translation memories).

== Owner ==
* Name: [[User:jibecfed|Jean-Baptiste Holcroft]],
[[User:darknao|Francois Andrieu]]
* Email: 



== Detailed Description ==

Language support is a transversal activity, there is no way to know
the actual language support provided by Fedora as an Operating System.

Because language support and translations are part of each upstream
software, the Linux language community is as spread as the Free Libre
and Open Source community is.

The ability to share efforts is limited (with data, tools, etc.):

* because of the complexity to get an overview of the current
localization status of the Linux community,
* because translators often have a low level of technical knowledge,
* because development experts are more keen to use English by default,
and don't know much about languages support requirements.

Debian did something similar (20 years ago)
https://www.debian.org/international/l10n/ . But this work:

* is limited in terms of features (no translation memories there)
* is too deeply integrated with Debian infrastructure (data
extraction, computation and website generation are 100% debian
specific)
* is using a programming language that doesn't allow to share easily
with existing i18n/l10n libraries (it did not exist 20 years ago)


== Benefit to Fedora ==
It is a progress for the project: provide a new tool to translator community.

It helps the Linux community to better understand the language support
challenges.

It increases contributors effectiveness by providing translation
memories and other tools.

These translation memories open new possibilities:

* to train machines to suggest new translations?
* to detect quality issues (spellcheck, linters, etc)?
* the change the way we ship translations to users? (Ubuntu does it,
but never bring back translation to main project)
* to advertise user that Linux is available in many languages?

== Scope ==

All of the work is isolated, as long as dnf works, the automation
works. The closer to mirror the cheaper it is for network cost (all
Fedora is downloaded at each execution).

* Proposal owners:
** [[User:Darknao|Francois Andrieu]] integrate the existing scripts
into containers to allow execution into openshift
** Infra team:
*** provide some space for script execution (50 GB per release)
*** provide the languages.fedoraproject.org domain name
*** provide a location for static website (about 2 GB per release, may
increase over time)

* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with mission: ''In our community, contributors of all
kinds come together to advance the ecosystem for the benefit of
everyone.''

== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
N/A (not a System Wide Change)

== User Experience ==


== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)

== Documentation ==
A draft with simplistic template is there:
https://jibecfed.fedorapeople.org/partage/fedora-localization-statistics/f32/language/fr/

Code and "documentation" are there:
https://pagure.io/fedora-localization-statistics

About other project:

* Debian's code to build website with language progress:
https://salsa.debian.org/webmaster-team/webwml/-/commits/master/english/international/l10n/scripts/transmonitor-check
* Ubuntu's code to build langpacks:
https://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/files
** Note: ubuntu does provide language progress in launchpad:
https://translations.launchpad.net/ubuntu and some useful
documentation is there: https://dev.launchpad.net/Translations


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Fedora 34 Change: LXQt 0.16.0 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/LXQt_0.16.0


== Summary ==

Update LXQt to 0.16.0 in Fedora.

== Owner ==
* Name: [[User:Zsun|Zamir SUN]]
* Email: zsun#AT#fedoraproject.org 


== Detailed Description ==

LXQt just released with a bunch of bugfixes. It's always good to keep
Fedora users running on most recent software.

Detailed LXQt release note is available
[https://lxqt-project.org/release/2020/11/05/lxqt-0-16-0/ here].

== Benefit to Fedora ==

This change brings bug fixes and enhancements to LXQt in Fedora.

== Scope ==
* Proposal owners:
1. Update all the LXQt related packages in Fedora.
2. Replace ark with lxqt-archiver in the package group.

* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issue/9926 #9926]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
Install using the spin, netinstall or DVD. Or upgrade from older
release. Then users should be able to test by doing any daily work.

== User Experience ==

Users of live media will now see lxqt-archiver instead of ark as the
default compress/decompress tool. For all users there will be a better
user experience and some more alternative themes available to choose
from.

== Dependencies ==

This update is pretty self contained and has been mostly finished in Rawhide.

== Contingency Plan ==
* Contingency mechanism: N/A. This is almost done in rawhide so the
remaining things are more about bug fixing.
* Contingency deadline: Fedora 34 Beta Freezee? N/A (not a System Wide Change)
* Blocks product? N/A

== Documentation ==
N/A (not a System Wide Change)


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Fedora 34 Change: Localization measurement and tooling (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/LocalizationMeasurementAndTooling


== Summary ==

Provide a public website for end users and contributors, containing
Fedora Workstation translation progress and useful files for
translators (as an example: translation memories).

== Owner ==
* Name: [[User:jibecfed|Jean-Baptiste Holcroft]],
[[User:darknao|Francois Andrieu]]
* Email: 



== Detailed Description ==

Language support is a transversal activity, there is no way to know
the actual language support provided by Fedora as an Operating System.

Because language support and translations are part of each upstream
software, the Linux language community is as spread as the Free Libre
and Open Source community is.

The ability to share efforts is limited (with data, tools, etc.):

* because of the complexity to get an overview of the current
localization status of the Linux community,
* because translators often have a low level of technical knowledge,
* because development experts are more keen to use English by default,
and don't know much about languages support requirements.

Debian did something similar (20 years ago)
https://www.debian.org/international/l10n/ . But this work:

* is limited in terms of features (no translation memories there)
* is too deeply integrated with Debian infrastructure (data
extraction, computation and website generation are 100% debian
specific)
* is using a programming language that doesn't allow to share easily
with existing i18n/l10n libraries (it did not exist 20 years ago)


== Benefit to Fedora ==
It is a progress for the project: provide a new tool to translator community.

It helps the Linux community to better understand the language support
challenges.

It increases contributors effectiveness by providing translation
memories and other tools.

These translation memories open new possibilities:

* to train machines to suggest new translations?
* to detect quality issues (spellcheck, linters, etc)?
* the change the way we ship translations to users? (Ubuntu does it,
but never bring back translation to main project)
* to advertise user that Linux is available in many languages?

== Scope ==

All of the work is isolated, as long as dnf works, the automation
works. The closer to mirror the cheaper it is for network cost (all
Fedora is downloaded at each execution).

* Proposal owners:
** [[User:Darknao|Francois Andrieu]] integrate the existing scripts
into containers to allow execution into openshift
** Infra team:
*** provide some space for script execution (50 GB per release)
*** provide the languages.fedoraproject.org domain name
*** provide a location for static website (about 2 GB per release, may
increase over time)

* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with mission: ''In our community, contributors of all
kinds come together to advance the ecosystem for the benefit of
everyone.''

== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
N/A (not a System Wide Change)

== User Experience ==


== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)

== Documentation ==
A draft with simplistic template is there:
https://jibecfed.fedorapeople.org/partage/fedora-localization-statistics/f32/language/fr/

Code and "documentation" are there:
https://pagure.io/fedora-localization-statistics

About other project:

* Debian's code to build website with language progress:
https://salsa.debian.org/webmaster-team/webwml/-/commits/master/english/international/l10n/scripts/transmonitor-check
* Ubuntu's code to build langpacks:
https://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/files
** Note: ubuntu does provide language progress in launchpad:
https://translations.launchpad.net/ubuntu and some useful
documentation is there: https://dev.launchpad.net/Translations


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 34 Change: LXQt 0.16.0 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/LXQt_0.16.0


== Summary ==

Update LXQt to 0.16.0 in Fedora.

== Owner ==
* Name: [[User:Zsun|Zamir SUN]]
* Email: zsun#AT#fedoraproject.org 


== Detailed Description ==

LXQt just released with a bunch of bugfixes. It's always good to keep
Fedora users running on most recent software.

Detailed LXQt release note is available
[https://lxqt-project.org/release/2020/11/05/lxqt-0-16-0/ here].

== Benefit to Fedora ==

This change brings bug fixes and enhancements to LXQt in Fedora.

== Scope ==
* Proposal owners:
1. Update all the LXQt related packages in Fedora.
2. Replace ark with lxqt-archiver in the package group.

* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issue/9926 #9926]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
Install using the spin, netinstall or DVD. Or upgrade from older
release. Then users should be able to test by doing any daily work.

== User Experience ==

Users of live media will now see lxqt-archiver instead of ark as the
default compress/decompress tool. For all users there will be a better
user experience and some more alternative themes available to choose
from.

== Dependencies ==

This update is pretty self contained and has been mostly finished in Rawhide.

== Contingency Plan ==
* Contingency mechanism: N/A. This is almost done in rawhide so the
remaining things are more about bug fixing.
* Contingency deadline: Fedora 34 Beta Freezee? N/A (not a System Wide Change)
* Blocks product? N/A

== Documentation ==
N/A (not a System Wide Change)


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Copr in 2020 and outlook for 2021

[Alexander Scheel]

Congrats! I can say I've used several of these features and they work
well, thanks for your team's work!


One query inline... :)

On Mon, Jan 4, 2021 at 11:53 AM Miroslav Suchý  wrote:
>
> Let me sum up what we - the Copr team - did in 2020:
>
>  * We enabled CDN for repos. https://fedora-copr.github.io/posts/copr-cdn
>
>  * We enabled runtime dependecies on repositories 
> https://fedora-copr.github.io/posts/runtime-dependencies
>
>  * We migrated all our servers from PHX datacenter to AWS. With zero downtime 
> for your repos.
>
>  * Pavel Raiskup became the new Mock project leader, and he released seven 
> new versions of Mock during 2020.
> https://github.com/rpm-software-management/mock/wiki
>
>  * Our small team has been renamed to Community Packaging Team (CPT) because 
> beside Copr, we maintain other tools as
> well: Mock, dist-git, Tito...
>
>  * We drove changes in createrepo_c, which allowed us better throughput. Now, 
> Copr can build thousands of builds per day.
>
>  * We worked on Fedora packages website, which was outdated and do not work 
> on recent Fedora. Unfortunately, it will not
> be likely used, and static pages will be used as it will require less 
> maintenance.
>
>  * We introduced Project scoring for projects in Copr (up/down vote) 
> http://frostyx.cz/posts/upvoting-projects-in-copr
>
>  * We allowed you to delete multiple builds at once. 
> https://fedora-copr.github.io/posts/deleting-list-of-builds
>
>  * You can use Github Actions now 
> https://pavel.raiskup.cz/blog/github-push-actions-and-copr.html
>
>  * We created modulemd-tools for low-level handling of repositories and 
> modules. And tool for generating
> module-build-macros. https://github.com/rpm-software-management/modulemd-tools
>
>  * We worked hard on better EOL handling of Copr repositories.
>
>  * We parallelized copr-dist-git imports.
>
>  * We wrote code for Ansible DNF Copr module. This still needs to land in a 
> proper place like Ansible Galaxy.
> https://pagure.io/copr/copr/blob/master/f/ansible
>
>  * We provided --isolation=* and --bootstrap=* knob in Copr
>
>  * We started an experimental "external dependencies" feature in Mock.
> https://github.com/rpm-software-management/mock/wiki/Feature-external-deps
>
>  * We created a new python module "templated-dictionary" as a spin-off from 
> Mock's code.
> https://github.com/xsuchy/templated-dictionary
>
>  * We wrote four articles "4 cool new projects to try in COPR" 
> https://fedoramagazine.org/tag/copr/
>
>  * Users now have the ability to change the build timeout up to a maximum of 
> 48 hours
>
>  * Users can group builds in batches now. 
> https://pavel.raiskup.cz/blog/build-ordering-by-batches-in-copr.html
>
>
> We already have plans to do:
>
>  * Verify GPG checks in DNF using DNSSEC. 
> https://pagure.io/copr/copr/issue/406
>
>  * Improve hooks (in cooperation with Packit team)
>
>  * We are going to EOL APIv1 and APIv2 
> https://fedora-copr.github.io/posts/EOL-APIv1-APIv2
>
>
> What will we do in 2021? We have some ideas. Some of them are yours, some of 
> them are ours. At the end of this email is
> a link to Google Form where you can vote what you would like to get. We will 
> consider your vote. (listed in no specific
> order)
>
>  * When you create a project, you may specify that it will be for Package 
> Review. We do some settings for you, and
> `rpminspect`  will be run automatically at the end of the build. We can guide 
> users on how to file Package Review BZ. Or
> do that automatically on their behalf.
>
>  * Contribute to fedpkg/Koji that tagged commits will be automatically built 
> in Koji and may be automatically sent to Bodhi.
>
>  * Help with automatic changelog entries.
>
>  * Native support for Fedora in Travis.

Travis has made a lot of changes to how OSS projects can use it, and
(IMO) burnt a lot of good will in the community. All of our upstream
projects ended up moving off it and onto GitHub Actions. Is there any
chance we could vote for GitHub Actions enablement instead of Travis?
Currently we run a Fedora Docker image on top of the Ubuntu host,
which is less than ideal in some cases (e.g., filesystem package
upgrades...).


Thanks,

Alex

>
>  * Continue on external dependencies. 
> https://github.com/rpm-software-management/mock/wiki/Feature-external-deps
>
>  * Finish rpm-spec-wizard https://github.com/xsuchy/rpm-spec-wizard
>
>  * Better integration with Koshei.
>
>  * Automatic rebuilds in Copr when dependency change (likely with the help of 
> Koshei)
>
>  * Enhance release-monitoring and rebase-helper to automatically open PR in 
> Pagure when new version is available.
>
>  * Enhance `Mock --chain` to try to set %bootstrap when standard loop fails. 
> When the set succeeds, rebuild the
> bootstrapped package again without %bootstrap macro.
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
>
>  * Improve the process of finding a sponsor for the first package.
>
>  * Contribute to 

%{python3} no defined in epel-7-aarch64?

[José Abílio Matos]

I have used copr to build the first alpha release of lyx-2.4:
https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/build/1858028/ 

For EPEL7 it build for x86_64 and it fails for aarch64, due to %{python3} not 
being defined.


The spec file has BR: python3-devel.

In the install stage I have this:

%py_byte_compile %{python3} %{buildroot}%{_datadir}/%{name}/lyx2lyx


This fails in epel-7-aarch64:
https://download.copr.fedorainfracloud.org/results/jamatos/lyx-devel/epel-7-aarch64/01858028-lyx-devel/build.log.gz
 
"
+ python_binary='%{python3}'
+ 
buildroot_path=/builddir/build/BUILDROOT/lyx-devel-2.4.0-0.2.alpha1.el7.aarch64/usr/share/lyx-devel/lyx2lyx
~/build/BUILDROOT/lyx-devel-2.4.0-0.2.alpha1.el7.aarch64 
~/build/BUILD/lyx-2.4.0-alpha1
+ bytecode_compilation_path=./usr/share/lyx-devel/lyx2lyx
+ failure=0
+ pushd /builddir/build/BUILDROOT/lyx-devel-2.4.0-0.2.alpha1.el7.aarch64
+ xargs -0 '%{python3}' -O -m py_compile
+ find ./usr/share/lyx-devel/lyx2lyx -type f -a -name '*.py' -print0
xargs: %{python3}: No such file or directory
+ failure=1
+ xargs -0 '%{python3}' -m py_compile
+ find ./usr/share/lyx-devel/lyx2lyx -type f -a -name '*.py' -print0
xargs: %{python3}: No such file or directory
+ failure=1
~/build/BUILD/lyx-2.4.0-alpha1
+ popd
+ test 1 -eq 0
"
while in the corresponding x86_64 the first line correctly sets:
+ python_binary=/usr/bin/python3

Is this known?

Regards,
-- 
José Abílio___
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

[Bug 1909861] perl-Date-HolidayParser-0.43 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Date-HolidayParser-0.4
   ||3-1.fc34
 Resolution|--- |RAWHIDE
Last Closed||2021-01-04 17:12:18



--- Comment #1 from Petr Pisar  ---
This moves from Any::Moose to Moo. It should not break anything, but it
prevents users from choosing between Moose and Moo. Suitable for Rawhide only.


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

Copr in 2020 and outlook for 2021

[Miroslav Suchý]

Let me sum up what we - the Copr team - did in 2020:

 * We enabled CDN for repos. https://fedora-copr.github.io/posts/copr-cdn

 * We enabled runtime dependecies on repositories 
https://fedora-copr.github.io/posts/runtime-dependencies

 * We migrated all our servers from PHX datacenter to AWS. With zero downtime 
for your repos.

 * Pavel Raiskup became the new Mock project leader, and he released seven new 
versions of Mock during 2020.
https://github.com/rpm-software-management/mock/wiki

 * Our small team has been renamed to Community Packaging Team (CPT) because 
beside Copr, we maintain other tools as
well: Mock, dist-git, Tito...

 * We drove changes in createrepo_c, which allowed us better throughput. Now, 
Copr can build thousands of builds per day.

 * We worked on Fedora packages website, which was outdated and do not work on 
recent Fedora. Unfortunately, it will not
be likely used, and static pages will be used as it will require less 
maintenance.

 * We introduced Project scoring for projects in Copr (up/down vote) 
http://frostyx.cz/posts/upvoting-projects-in-copr

 * We allowed you to delete multiple builds at once. 
https://fedora-copr.github.io/posts/deleting-list-of-builds

 * You can use Github Actions now 
https://pavel.raiskup.cz/blog/github-push-actions-and-copr.html

 * We created modulemd-tools for low-level handling of repositories and 
modules. And tool for generating
module-build-macros. https://github.com/rpm-software-management/modulemd-tools

 * We worked hard on better EOL handling of Copr repositories.

 * We parallelized copr-dist-git imports.

 * We wrote code for Ansible DNF Copr module. This still needs to land in a 
proper place like Ansible Galaxy.
https://pagure.io/copr/copr/blob/master/f/ansible

 * We provided --isolation=* and --bootstrap=* knob in Copr

 * We started an experimental "external dependencies" feature in Mock.
https://github.com/rpm-software-management/mock/wiki/Feature-external-deps

 * We created a new python module "templated-dictionary" as a spin-off from 
Mock's code.
https://github.com/xsuchy/templated-dictionary

 * We wrote four articles "4 cool new projects to try in COPR" 
https://fedoramagazine.org/tag/copr/

 * Users now have the ability to change the build timeout up to a maximum of 48 
hours

 * Users can group builds in batches now. 
https://pavel.raiskup.cz/blog/build-ordering-by-batches-in-copr.html


We already have plans to do:

 * Verify GPG checks in DNF using DNSSEC. https://pagure.io/copr/copr/issue/406

 * Improve hooks (in cooperation with Packit team)

 * We are going to EOL APIv1 and APIv2 
https://fedora-copr.github.io/posts/EOL-APIv1-APIv2


What will we do in 2021? We have some ideas. Some of them are yours, some of 
them are ours. At the end of this email is
a link to Google Form where you can vote what you would like to get. We will 
consider your vote. (listed in no specific
order)

 * When you create a project, you may specify that it will be for Package 
Review. We do some settings for you, and
`rpminspect`  will be run automatically at the end of the build. We can guide 
users on how to file Package Review BZ. Or
do that automatically on their behalf.

 * Contribute to fedpkg/Koji that tagged commits will be automatically built in 
Koji and may be automatically sent to Bodhi.

 * Help with automatic changelog entries.

 * Native support for Fedora in Travis.

 * Continue on external dependencies. 
https://github.com/rpm-software-management/mock/wiki/Feature-external-deps

 * Finish rpm-spec-wizard https://github.com/xsuchy/rpm-spec-wizard

 * Better integration with Koshei.

 * Automatic rebuilds in Copr when dependency change (likely with the help of 
Koshei)

 * Enhance release-monitoring and rebase-helper to automatically open PR in 
Pagure when new version is available.

 * Enhance `Mock --chain` to try to set %bootstrap when standard loop fails. 
When the set succeeds, rebuild the
bootstrapped package again without %bootstrap macro.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping

 * Improve the process of finding a sponsor for the first package.

 * Contribute to fedpkg/koji to have machine-readable output.

Please vote here: https://forms.gle/UuH86ECzfZNHJgEr8
The results are intentionally publicly available. You may check them anytime.

CPT team consist of Pavel Raiskup, Silvie Chlupova, Jakub Kadlcik and this year 
we also had in the team Dominik Turecek
and Tomas Hrnciar.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1909861] perl-Date-HolidayParser-0.43 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




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

Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)

[Matthew Miller]

On Sun, Jan 03, 2021 at 03:25:29PM -0800, Kevin Fenzi wrote:
> I remember when drpms landed I heard people say they choose Fedora
> because of them. That may have changed over the years I guess. :) 
> and there have been only 2 or 3 reports about how few drpms exist
> in the last few years (ie, most people didn't really notice). 

Hmmm, here's an idea: what if instead of nightly drpms, we made them only
every two weeks, but always exactly two weeks, so that people updating on a
specific cadence would get them?


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Rawhide-20210104.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
2 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 9/180 (x86_64), 7/122 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20210103.n.0):

ID: 750854  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/750854
ID: 750974  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/750974
ID: 751005  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/751005
ID: 751079  Test: aarch64 universal upgrade_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/751079
ID: 751108  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/751108

Old failures (same test failed in Fedora-Rawhide-20210103.n.0):

ID: 750869  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/750869
ID: 750876  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/750876
ID: 750886  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/750886
ID: 750895  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/750895
ID: 750897  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/750897
ID: 750909  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/750909
ID: 750931  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/750931
ID: 751049  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/751049
ID: 751076  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/751076
ID: 751103  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/751103
ID: 751112  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/751112

Soft failed openQA tests: 21/180 (x86_64), 14/122 (aarch64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20210103.n.0):

ID: 750874  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/750874
ID: 750952  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/750952

Old soft failures (same test soft failed in Fedora-Rawhide-20210103.n.0):

ID: 750815  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/750815
ID: 750816  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/750816
ID: 750823  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/750823
ID: 750827  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/750827
ID: 750831  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/750831
ID: 750832  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/750832
ID: 750845  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/750845
ID: 750917  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/750917
ID: 750926  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/750926
ID: 750927  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/750927
ID: 750935  Test: aarch64 Server-dvd-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/750935
ID: 750946  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/750946
ID: 750966  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/750966
ID: 750970  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/750970
ID: 750993  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/750993
ID: 750994  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/750994
ID: 751004  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/751004
ID: 751007  Test: x86_64 universal upgrade_kde_64bit
URL: 

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

[Jeff Law]

On 1/4/21 2:27 AM, Florian Weimer wrote:
>
>>> A lot of the existing RPM post-processing steps detect, report, and
>>> ignore errors because the generated RPM package might still be partially
>>> useful.
>> True, but ignoring the error in this case runs the very real risk that a
>> package could install a .o/.a file with no code/symbols.  That in turn
>> can cause downstream FTBFS errors in other packages and all kinds of
>> headaches on developer systems.  Failing the build here seems much safer.
>>
>> Contrast to ignoring a dwz error.  The resulting binary RPMs are still
>> very much usable, the debuginfo packages are just larger than is
>> strictly necessary.
> The downside is that toolchain bugs tend to go unnoticed and aren't
> fixed as a result.
Right.  And I think that's been a real problem.  I really dislike
ignoring errors :(

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1910780] perl-ExtUtils-HasCompiler-0.023 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-f46734aa7b has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-f46734aa7b


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

[EPEL-devel] Re: Version of gcc in EPEL7

[José Abílio Matos]

On Monday, January 4, 2021 3:30:20 PM WET Troy Dawson wrote:
> [root@centos7 ~]# g++ -dumpversion
> 4.8.5
> [root@centos7 ~]# g++ -dumpfullversion
> g++: fatal error: no input files
> compilation terminated.
> [root@centos7 ~]# rpm -qf /usr/bin/g++
> gcc-c++-4.8.5-44.el7.x86_64

Thank you. :-)
-- 
José Abílio___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Version of gcc in EPEL7

[Manuel Wolfshant]

On 1/4/21 5:19 PM, José Abílio Matos wrote:


Hi,

last week I have compiled the first alpha release of LyX 2.4 in copr.

As I have been doing in other cases I have built the package in EPEL 7 
and 8, together with the supported Fedora versions and rawhide.



The code only failed in EPEL 7. In a sense this was to be expected 
since the code requires at least gcc 4.9 (full C++ support for regex 
is the culprit here).


The reason why I am writing this is because there is a test in the 
autotools base to catch older versions of gcc and for some reason it 
is not working.



I have been asked what is the output of

g++ -dumpversion

and

g++ -dumpfullversion


in EPEL.


Could anyone that has an available installation send me that output, 
please?



The other tangential question is if there is a newer gcc version that 
can be used in EPEL7. I think this question has been answered several 
times in this list but my search-fu is not working at the moment.




https://smoogespace.blogspot.com/2018/03/using-red-hat-developer-toolset-dts-in.html

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: openvdb-8.0.0 so version change

[Miro Hrončok]

On 26. 12. 20 23:24, Luya Tshimbalanga wrote:

Hello team,

openvdb-8.0.0 is released upstream meaning the soversion is now 8.0 resulting a 
break on dependent packages like OpenImageIO and Blender as tested on COPR 
blender[1].  The commit is already complete 
https://src.fedoraproject.org/rpms/openvdb


and it is a matter of building for proven packagers.


It has been rebuilt now in rawhide causing non-installable packages :(

OpenImageIO: https://bugzilla.redhat.com/show_bug.cgi?id=1912497
blender: https://bugzilla.redhat.com/show_bug.cgi?id=1912498
prusa-slicer: https://bugzilla.redhat.com/show_bug.cgi?id=1912499

Please coordinate such rebuilds with a provenpackager prior to pushing such 
updates. I'll see if they build.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1910780] perl-ExtUtils-HasCompiler-0.023 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-ExtUtils-HasCompiler-0
   ||.023-1.fc34




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

Fedora-IoT-34-20210104.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 3/16 (x86_64), 6/15 (aarch64)

New failures (same test not failed in Fedora-IoT-34-20210102.0):

ID: 751234  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/751234
ID: 751238  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/751238
ID: 751249  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi
URL: https://openqa.fedoraproject.org/tests/751249

Old failures (same test failed in Fedora-IoT-34-20210102.0):

ID: 751230  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/751230
ID: 751239  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/751239
ID: 751241  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/751241
ID: 751242  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/751242
ID: 751244  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/751244
ID: 751248  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/751248

Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-34-20210102.0):

ID: 751223  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/751223

Passed openQA tests: 12/16 (x86_64), 9/15 (aarch64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
System load changed from 0.12 to 0.34
Previous test data: https://openqa.fedoraproject.org/tests/749949#downloads
Current test data: https://openqa.fedoraproject.org/tests/751225#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.57 to 0.43
Previous test data: https://openqa.fedoraproject.org/tests/749964#downloads
Current test data: https://openqa.fedoraproject.org/tests/751240#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Version of gcc in EPEL7

[Troy Dawson]

[root@centos7 ~]# g++ -dumpversion
4.8.5
[root@centos7 ~]# g++ -dumpfullversion
g++: fatal error: no input files
compilation terminated.
[root@centos7 ~]# rpm -qf /usr/bin/g++
gcc-c++-4.8.5-44.el7.x86_64



On Mon, Jan 4, 2021 at 7:20 AM José Abílio Matos  wrote:
>
> Hi,
>
>   last week I have compiled the first alpha release of LyX 2.4 in copr.
>
> As I have been doing in other cases I have built the package in EPEL 7 and 8, 
> together with the supported Fedora versions and rawhide.
>
>
> The code only failed in EPEL 7. In a sense this was to be expected since the 
> code requires at least gcc 4.9 (full C++ support for regex is the culprit 
> here).
>
> The reason why I am writing this is because there is a test in the autotools 
> base to catch older versions of gcc and for some reason it is not working.
>
>
> I have been asked what is the output of
>
> g++ -dumpversion
>
> and
>
> g++ -dumpfullversion
>
>
> in EPEL.
>
>
> Could anyone that has an available installation send me that output, please?
>
>
> The other tangential question is if there is a newer gcc version that can be 
> used in EPEL7. I think this question has been answered several times in this 
> list but my search-fu is not working at the moment.
>
>
> What I wrote above only applies to EPEL 7 as EPEL 8 is working perfectly and 
> I have recently released the stable version of LyX there.
>
>
> Best regards,
>
> --
>
> José Abílio
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Version of gcc in EPEL7

[José Abílio Matos]

Hi,
  last week I have compiled the first alpha release of LyX 2.4 in copr.
As I have been doing in other cases I have built the package in EPEL 7 and 8, 
together with the supported Fedora versions and rawhide.

The code only failed in EPEL 7. In a sense this was to be expected since the 
code requires at least gcc 4.9 (full C++ support for regex is the culprit 
here).
The reason why I am writing this is because there is a test in the autotools 
base to catch older versions of gcc and for some reason it is not working.

I have been asked what is the output of
g++ -dumpversion
and
g++ -dumpfullversion

in EPEL.

Could anyone that has an available installation send me that output, please?

The other tangential question is if there is a newer gcc version that can be 
used in EPEL7. I think this question has been answered several times in this 
list but my search-fu is not working at the moment.

What I wrote above only applies to EPEL 7 as EPEL 8 is working perfectly and I 
have recently released the stable version of LyX there.

Best regards,
-- 
José Abílio___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Bugzilla error when saving

[Richard Shaw]

I was trying to add an issue to this bug but I keep on getting a jira error:

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

Thanks,
Richard

---

There was an error reported for the RPC call to Jira: There was an error
reported for a GitHub REST call. URL:
https://api.github.com/repos/fail2ban/fail2ban/issues/2904 Error: 403
Forbidden at
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line
111. at
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line
111. eval {...} called at
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line
98
Bugzilla::Extension::ExternalBugs::Type::GitHub::_do_rest_call('Bugzilla::Extension::ExternalBugs::Type::GitHub=HASH(0x559586...',
'https://api.github.com/repos/fail2ban/fail2ban/issues/2904', 'GET') called
at /loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm
line 62
Bugzilla::Extension::ExternalBugs::Type::GitHub::get_data('Bugzilla::Extension::ExternalBugs::Type::GitHub=HASH(0x559586...',
'Bugzilla::Extension::ExternalBugs::Bug=HASH(0x559586d39d80)') called at
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Bug.pm line 302 eval
{...} called at
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Bug.pm line 302
Bugzilla::Extension::ExternalBugs::Bug::update_ext_info('Bugzilla::Extension::ExternalBugs::Bug=HASH(0x559586d39d80)',
1) called at /loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Bug.pm
line 125
Bugzilla::Extension::ExternalBugs::Bug::create('Bugzilla::Extension::ExternalBugs::Bug',
'HASH(0x559586967008)') called at
/var/www/html/bugzilla/extensions/ExternalBugs/Extension.pm line 940
Bugzilla::Extension::ExternalBugs::bug_start_of_update('Bugzilla::Extension::ExternalBugs=HASH(0x559586b85cd8)',
'HASH(0x559586b70760)') called at /var/www/html/bugzilla/Bugzilla/Hook.pm
line 21 Bugzilla::Hook::process('bug_start_of_update',
'HASH(0x559586b70760)') called at /var/www/html/bugzilla/Bugzilla/Bug.pm
line 1173 Bugzilla::Bug::update('Bugzilla::Bug=HASH(0x559586b46d38)')
called at /var/www/html/bugzilla/process_bug.cgi line 558
ModPerl::ROOT::Bugzilla::ModPerl::ResponseHandler::var_www_html_bugzilla_process_bug_2ecgi::handler('Apache2::RequestRec=SCALAR(0x559586a0cc18)')
called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 207
eval {...} called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm
line 207
ModPerl::RegistryCooker::run('Bugzilla::ModPerl::ResponseHandler=HASH(0x559586b86560)')
called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 173
ModPerl::RegistryCooker::default_handler('Bugzilla::ModPerl::ResponseHandler=HASH(0x559586b86560)')
called at /usr/lib64/perl5/vendor_perl/ModPerl/Registry.pm line 32
ModPerl::Registry::handler('Bugzilla::ModPerl::ResponseHandler',
'Apache2::RequestRec=SCALAR(0x559586a0cc18)') called at
/var/www/html/bugzilla/mod_perl.pl line 139
Bugzilla::ModPerl::ResponseHandler::handler('Bugzilla::ModPerl::ResponseHandler',
'Apache2::RequestRec=SCALAR(0x559586a0cc18)') called at -e line 0 eval
{...} called at -e line 0 at /var/www/html/bugzilla/Bugzilla/Error.pm line
130. Bugzilla::Error::_throw_error('global/user-error.html.tmpl',
'ext_bz_rest_error', 'HASH(0x559586da17c0)') called at
/var/www/html/bugzilla/Bugzilla/Error.pm line 193
Bugzilla::Error::ThrowUserError('ext_bz_rest_error',
'HASH(0x559586da17c0)') called at
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line
120
Bugzilla::Extension::ExternalBugs::Type::GitHub::_do_rest_call('Bugzilla::Extension::ExternalBugs::Type::GitHub=HASH(0x559586...',
'https://api.github.com/repos/fail2ban/fail2ban/issues/2904', 'GET') called
at /loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm
line 62
Bugzilla::Extension::ExternalBugs::Type::GitHub::get_data('Bugzilla::Extension::ExternalBugs::Type::GitHub=HASH(0x559586...',
'Bugzilla::Extension::ExternalBugs::Bug=HASH(0x559586d39d80)') called at
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Bug.pm line 302 eval
{...} called at
/loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Bug.pm line 302
Bugzilla::Extension::ExternalBugs::Bug::update_ext_info('Bugzilla::Extension::ExternalBugs::Bug=HASH(0x559586d39d80)',
1) called at /loader/0x559579f7e1a8/Bugzilla/Extension/ExternalBugs/Bug.pm
line 125
Bugzilla::Extension::ExternalBugs::Bug::create('Bugzilla::Extension::ExternalBugs::Bug',
'HASH(0x559586967008)') called at
/var/www/html/bugzilla/extensions/ExternalBugs/Extension.pm line 940
Bugzilla::Extension::ExternalBugs::bug_start_of_update('Bugzilla::Extension::ExternalBugs=HASH(0x559586b85cd8)',
'HASH(0x559586b70760)') called at /var/www/html/bugzilla/Bugzilla/Hook.pm
line 21 Bugzilla::Hook::process('bug_start_of_update',
'HASH(0x559586b70760)') called at /var/www/html/bugzilla/Bugzilla/Bug.pm
line 1173 Bugzilla::Bug::update('Bugzilla::Bug=HASH(0x559586b46d38)')
called at /var/www/html/bugzilla/process_bug.cgi line 558

[Bug 1910780] perl-ExtUtils-HasCompiler-0.023 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




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

[Bug 1910394] perl-Devel-PatchPerl-2.06 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2021-7fdf29563e has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-7fdf29563e


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

[Bug 1910394] perl-Devel-PatchPerl-2.06 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Devel-PatchPerl-2.06-1
   ||.fc34




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

Re: Thoughts about packaging a standalone python-PyQt5-sip?

[Rex Dieter]

Scott Talbert wrote:

> On Sat, 2 Jan 2021, Kevin Fenzi wrote:
> 
> I think fundamentally the version of PyQt5-sip probably needs to match
> (or be very close to) the version of sip that PyQt5 itself was
> compiled with.

 I think for calibre (which is currently failing with):

 ...
 /usr/bin/python3 -c import os;
 os.chdir('/builddir/build/BUILD/calibre-5.8.1/build/pyqt/pictureflow');
 from sipbuild.tools.build import main; main(); --verbose --no-make
 --qmake /usr/bin/qmake-qt5 Querying qmake about your Qt installation...
 /usr/bin/qmake-qt5 -query These bindings will be built: pictureflow.
 Generating the pictureflow bindings... -c: Unable to find file
 "QtWidgets/QtWidgetsmod.sip"

 ...we need python-qt5 to be using sip5 also. I looked into it a bit, it
 completely changes from using a configure.py to using sip-build and
 PyQt-builder.

 Or can we just add a subpackage there that uses sip5 and keep the sip4
 ones for sip4 users? something like python3-qt5-sip5-devel ?

 Or should we just convert everything to sip5 now?

 I'd really like to get calibre building again... :)
>>>
>>> It looks like technically you can still use configure.py to build PyQt5
>>> with sip5, but it does seem more forward looking to switch to sip-build
>>> / sip-install.
>>>
>>> BTW, can you please build PyQt-builder for F33?  Thanks.
>>
>> Sure. Also, co-maintainers welcome. :)
> 
> Thanks!  BTW, I starting looking into moving python-qt5 to sip5.  It
> doesn't look like it would be *that* difficult.  I thought about doing a
> PR, but it might be better if the regular pyqt5 maintainer (if
> interested/available) did it.

With my "regular maintainer" hat on, I'll say unfortunately I've not had 
time to look into this and probably won't for the foreseeable immediate 
future.  

I'll also chime in with "co-maintainers" welcome if there are folks 
interested in able in moving this forward.  Just take care to minimize 
breakage.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: runtime dependencies not in Requires spec section

[Rex Dieter]

Vitaly Zaitsev via devel wrote:

> On 30.12.2020 22:49, Germano Massullo wrote:
>> My question is: how can keepassxc trigger the installation of such
>> libraries if the spec file does not contain any Requires dependency that
>> should be the attribute to identify runtime dependencies that are needed
>> by the package?
> 
> Yes, it must. Qt5Svg is a Qt runtime plugin, so it will not be added
> automatically by rpmbuild.

It's a linked library, so *yes*, rpmbuild will add it.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1910394] perl-Devel-PatchPerl-2.06 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|iarn...@gmail.com   |
   Doc Type|--- |If docs needed, set a value




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

[Bug 1910310] perl-libnet-3.13 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-819abf0dbb has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-819abf0dbb

--- Comment #2 from Fedora Update System  ---
FEDORA-2021-6aba9c3436 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-6aba9c3436


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

[Bug 1910310] perl-libnet-3.13 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-819abf0dbb has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-819abf0dbb


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

Fedora rawhide compose report: 20210104.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210103.n.0
NEW: Fedora-Rawhide-20210104.n.0

= SUMMARY =
Added images:0
Dropped images:  67
Added packages:  30
Dropped packages:0
Upgraded packages:   95
Downgraded packages: 0

Size of added packages:  5.70 MiB
Size of dropped packages:0 B
Size of upgraded packages:   985.84 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   57.00 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Cloud_Base qcow2 aarch64
Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20210103.n.0.aarch64.qcow2
Image: Server boot x86_64
Path: Server/x86_64/iso/Fedora-Server-netinst-x86_64-Rawhide-20210103.n.0.iso
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20210103.n.0.iso
Image: Everything boot aarch64
Path: 
Everything/aarch64/iso/Fedora-Everything-netinst-aarch64-Rawhide-20210103.n.0.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20210103.n.0.iso
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-Rawhide-20210103.n.0.armhfp.raw.xz
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20210103.n.0.iso
Image: Everything boot armhfp
Path: 
Everything/armhfp/iso/Fedora-Everything-netinst-armhfp-Rawhide-20210103.n.0.iso
Image: Server boot ppc64le
Path: Server/ppc64le/iso/Fedora-Server-netinst-ppc64le-Rawhide-20210103.n.0.iso
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20210103.n.0.iso
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20210103.n.0.aarch64.tar.xz
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20210103.n.0.iso
Image: Container_Minimal_Base docker armhfp
Path: 
Container/armhfp/images/Fedora-Container-Minimal-Base-Rawhide-20210103.n.0.armhfp.tar.xz
Image: Server boot aarch64
Path: Server/aarch64/iso/Fedora-Server-netinst-aarch64-Rawhide-20210103.n.0.iso
Image: Container_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Base-Rawhide-20210103.n.0.x86_64.tar.xz
Image: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20210103.n.0-sda.raw.xz
Image: Cloud_Base qcow2 x86_64
Path: Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-20210103.n.0.x86_64.qcow2
Image: Server boot armhfp
Path: Server/armhfp/iso/Fedora-Server-netinst-armhfp-Rawhide-20210103.n.0.iso
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20210103.n.0.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20210103.n.0.iso
Image: KDE live x86_64
Path: Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20210103.n.0.iso
Image: Workstation_Appliance raw-xz armhfp
Path: 
Workstation/armhfp/images/Fedora-Workstation-armhfp-Rawhide-20210103.n.0-sda.raw.xz
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20210103.n.0.x86_64.vagrant-libvirt.box
Image: Server dvd aarch64
Path: Server/aarch64/iso/Fedora-Server-dvd-aarch64-Rawhide-20210103.n.0.iso
Image: Xfce_Appliance raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Xfce-armhfp-Rawhide-20210103.n.0-sda.raw.xz
Image: Cloud_Base tar-gz x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-GCP-Rawhide-20210103.n.0.x86_64.tar.gz
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20210103.n.0.iso
Image: KDE raw-xz aarch64
Path: Spins/aarch64/images/Fedora-KDE-Rawhide-20210103.n.0.aarch64.raw.xz
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20210103.n.0-sda.raw.xz
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20210103.n.0.iso
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-Rawhide-20210103.n.0.aarch64.tar.xz
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20210103.n.0.iso
Image: Container_Base docker armhfp
Path: 
Container/armhfp/images/Fedora-Container-Base-Rawhide-20210103.n.0.armhfp.tar.xz
Image: Cloud_Base vagrant-virtualbox x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20210103.n.0.x86_64.vagrant-virtualbox.box
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20210103.n.0.iso
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20210103.n.0.iso
Image: Minimal_Appliance raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Minimal-armhfp-Rawhide-20210103.n.0-sda.raw.xz
Image: Python_Classroom raw-xz armhfp
Path: 
Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20210103.n.0-sda.raw.xz
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20210103.n.0.iso
Image: LXDE live

[Bug 1910310] perl-libnet-3.13 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-libnet-3.13-1.fc34




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

[Bug 1906256] perl-Cache-FastMmap-1.56 is available

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Status|NEW |ON_QA
   Doc Type|--- |If docs needed, set a value



--- Comment #4 from Jan Pazdziora  ---
New build created for Fedora rawhide:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-59813a6f97


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

Re: Unannounced soname bump: ldns

[Miro Hrončok]

On 04. 01. 21 13:14, Petr Menšík wrote:



On 1/4/21 12:38 PM, Miro Hrončok wrote:

On 04. 01. 21 12:26, Petr Menšík wrote:

I had not time to coordinate rebuilt before Christmas, so I left it
intentionally without build. It was built by Jeff Law one day before I
departed to vacation. I haven't noticed that.


As a matter of opinion (i.e. this is not a policy, but my own views), I
think that the state of distgit should always be "good" and any
provenpackager should safely assume that rebuilding any package does not
cause damage.

If I need to rebuild many packages because of a dependency, I should not
need to explore if the latest commits are "ready". A work in progress
should be left in a pull request.

Obviously, this does not always work, because sometimes change in
distgit is necessary for a rebuild from a side tag, but in most cases I
think we should avoid  both "I've pushed a breaking upgrade but I
haven't built it" or "I've pushed a broken commit and will push more
later" approaches.

WDYT?



I thought it was ready and there were no scheduled mass rebuild. ldns
usually does not even receive bugs for months, let alone need for
immediate build change. I even made a mistake and haven't added sources
to upgrade. It should have ended with FTBFS bug instead of broken compose.


To be clear, I'm not trying to reprimand you, but rather to try to establish 
some consensus of what's "good" and what's not. This is just one case of many 
that reminded me to discuss this. No need to discuss this particular case 
specifically.



Is there tooling to help with rebases of changelog conflicts? If leave
it in my branch and someone bumps the spec, can I make just git rebase
equivalent without manual conflict solving? Some git commit message tag
or something similar to help make bumps on merge? It is a little of
work, but annoying. Is there existing automation for it? Makes MR
outdated on any spec change and not too usable.


Give this (experimental) merge driver a try:

https://github.com/encukou/rpm-spec-merge-driver/

--
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

Re: Unannounced soname bump: ldns

[Petr Menšík]

On 1/4/21 12:38 PM, Miro Hrončok wrote:
> On 04. 01. 21 12:26, Petr Menšík wrote:
>> I had not time to coordinate rebuilt before Christmas, so I left it
>> intentionally without build. It was built by Jeff Law one day before I
>> departed to vacation. I haven't noticed that.
> 
> As a matter of opinion (i.e. this is not a policy, but my own views), I
> think that the state of distgit should always be "good" and any
> provenpackager should safely assume that rebuilding any package does not
> cause damage.
> 
> If I need to rebuild many packages because of a dependency, I should not
> need to explore if the latest commits are "ready". A work in progress
> should be left in a pull request.
> 
> Obviously, this does not always work, because sometimes change in
> distgit is necessary for a rebuild from a side tag, but in most cases I
> think we should avoid  both "I've pushed a breaking upgrade but I
> haven't built it" or "I've pushed a broken commit and will push more
> later" approaches.
> 
> WDYT?
> 

I thought it was ready and there were no scheduled mass rebuild. ldns
usually does not even receive bugs for months, let alone need for
immediate build change. I even made a mistake and haven't added sources
to upgrade. It should have ended with FTBFS bug instead of broken compose.

I did that to save version bumping later, just to have it backed up
somewhere. I admit I don't do MR to myself often, thought it was not
necessary. I did not expect anyone would have need to touch it for a few
weeks. No one touched it whole year and I relied on that.

Is there tooling to help with rebases of changelog conflicts? If leave
it in my branch and someone bumps the spec, can I make just git rebase
equivalent without manual conflict solving? Some git commit message tag
or something similar to help make bumps on merge? It is a little of
work, but annoying. Is there existing automation for it? Makes MR
outdated on any spec change and not too usable.

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



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

Re: How to handle a config(noreplace) file that needs to be updated

[Robert-André Mauchin]

On 1/4/21 2:44 AM, Kevin Kofler via devel wrote:

Robert-André Mauchin wrote:

I have a project for which the config file (toml) has been significantly
changed, notably renamed sections. As such some older config parameters
won't work anymore.


Tools like sed, ed, awk etc. in %post scriptlets can do wonders.



I would do that but the cange are too extensive. And some config file 
got renamede I'm not sure how to handle that yet.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1910310] perl-libnet-3.13 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




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

[Bug 1910204] perl-DateTime-TimeZone-2.46 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2021-e2d3150bdc has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-e2d3150bdc


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

[Bug 1837988] CVE-2020-10878 perl: corruption of intermediate language state of compiled regular expression due to integer overflow leads to DoS

[bugzilla]

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

msidd...@redhat.com changed:

   What|Removed |Added

  Flags|needinfo?(msiddiqu@redhat.c |
   |om) |




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

Re: How to handle a config(noreplace) file that needs to be updated

[Fabio Valentini]

On Sun, Jan 3, 2021 at 8:16 PM Robert-André Mauchin  wrote:
>
> Hello,
>
> I have a project for which the config file (toml) has been significantly
> changed, notably renamed sections. As such some older config parameters
> won't work anymore.
> However the current config file can't be overwritten because of
> config(noreplace) directive. How do I recommend my users to move to the
> new config format?
>
> Best regards,
>
> Robert-André

The simplest solution might be to only provide the update with the
breaking change in rawhide / f34, and put a change about the new
config file format into the release notes. Such breaking changes are
to be expected when doing major upgrades, and people should read the
release notes if they have custom configs they care about.

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

Re: Unannounced soname bump: ldns

[Miro Hrončok]

On 04. 01. 21 12:26, Petr Menšík wrote:

I had not time to coordinate rebuilt before Christmas, so I left it
intentionally without build. It was built by Jeff Law one day before I
departed to vacation. I haven't noticed that.


As a matter of opinion (i.e. this is not a policy, but my own views), I think 
that the state of distgit should always be "good" and any provenpackager should 
safely assume that rebuilding any package does not cause damage.


If I need to rebuild many packages because of a dependency, I should not need to 
explore if the latest commits are "ready". A work in progress should be left in 
a pull request.


Obviously, this does not always work, because sometimes change in distgit is 
necessary for a rebuild from a side tag, but in most cases I think we should 
avoid  both "I've pushed a breaking upgrade but I haven't built it" or "I've 
pushed a broken commit and will push more later" approaches.


WDYT?

--
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

Re: Planned Outage - taiga - 2021-01-05 07:00 UTC

[Pierre-Yves Chibon]

On Thu, Dec 31, 2020 at 05:33:08PM +0100, Pierre-Yves Chibon wrote:
> There will be an outage starting at 2021-01-05 07:00 UTC
> which will last approximately 3 hours.
> 
> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/Infrastructure/UTCHowto
> or run:
> date -d '2021-01-05 07:00UTC'
> 
> 
> Reason for outage:
> Upgrade to a more recent/patched taiga
> 
> 
> Affected Services:
> Only taiga (ie: teams.fedoraproject.org)

This outage is now over.

Here is the gist of the changes:
"""
We have successfully deployed the patch release on your Taiga instance.

You have the full changelog at our repositories, but the most notable changes 
are:

- We fixed attachment refresh on comments and the wiki
- We now render custom fields and block reason as Markdown (more powerful 
parsing, allows for hyperlinks, for example)
"""


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unannounced soname bump: ldns

[Petr Menšík]

I am sorry for that.

I had not time to coordinate rebuilt before Christmas, so I left it
intentionally without build. It was built by Jeff Law one day before I
departed to vacation. I haven't noticed that.

Jeff, were there any specific reason behind your build? It would be
nice, if you tried to ping me on IRC first. I think I were still there.

I have no commit access to 3 dependencies, I left it after New Year to
be coordinated with others. It is fixed now by Adam, thank you for
fixing it.

On 12/19/20 6:10 PM, Adam Williamson wrote:
> A new build of ldns was done for Rawhide yesterday by law/pemensik:
> 
> 
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1660180
> 
> This build changes the soname of libreport from libldns.so.2 to
> libldns.so.3.
> 
> This bump was not announced AFAICS, and none of its several
> dependencies appear to have been rebuilt:
> 
> dnsperf-0:2.4.0-2.fc34.x86_64
> dnssec-trigger-0:0.17-1.fc34.x86_64
> flamethrower-0:0.11.0-1.fc34.x86_64
> ldns-devel-0:1.7.0-32.fc33.x86_64
> ldns-utils-0:1.7.0-32.fc33.x86_64
> libreswan-0:4.1-3.fc34.x86_64
> netresolve-backends-aresdns-0:0.0.1-0.28.20160317git.fc33.x86_64
> netresolve-backends-avahi-0:0.0.1-0.28.20160317git.fc33.x86_64
> netresolve-backends-compat-0:0.0.1-0.28.20160317git.fc33.x86_64
> netresolve-backends-ubdns-0:0.0.1-0.28.20160317git.fc33.x86_64
> netresolve-compat-0:0.0.1-0.28.20160317git.fc33.x86_64
> netresolve-core-0:0.0.1-0.28.20160317git.fc33.x86_64
> netresolve-tools-0:0.0.1-0.28.20160317git.fc33.x86_64
> nordugrid-arc-plugins-needed-0:6.9.0-1.fc34.x86_64
> opendnssec-0:2.1.7-1.fc34.x86_64
> python3-ldns-0:1.7.0-32.fc33.x86_64
> 
> This broke today's Rawhide compose due to a KDE dependency chain that
> involves libreswan:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=57780927
> 
> Please remember to announce soname bumps ahead of time and arrange
> rebuilds of dependencies so this kind of problem can be avoided.
> Thanks. I will try and rebuild things, at least compose-critical
> things, now, but if straight rebuilds don't work might need people to
> help out.
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



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

[rpms/perl-Sys-Virt-TCK] PR #1: SELinux policy for Libvirt-TCK

[Daniel P . Berrange]

berrange commented on the pull-request: `SELinux policy for Libvirt-TCK ` that 
you are following:
``
Thanks for this, however, we have a strictly upstream-first policy for libvirt, 
so can't take this kind of thing as a Fedora patch. Please can you send it 
upstream as a patch to the real libvirt-tck git repo.

``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Sys-Virt-TCK/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Pierre-Yves Chibon]

On Thu, Dec 17, 2020 at 09:14:40PM +0100, Fabio Valentini wrote:
> On Thu, Dec 17, 2020 at 8:06 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> >
> >
> > == Summary ==
> > This change should enable an opt-in spec file preprocessor in Fedora
> > infrastructure for the benefit of packagers. The preprocessor allows
> > some very neat tricks that were impossible before, for example
> > generate changelog and release automatically from git metadata or pack
> > the entire dist-git repository into an rpm-source tarball (effectively
> > allowing unpacked repos to live in DistGit).
> 
> As far as I can tell, this is the third implementation of generated
> changelogs ... did the autorelease / autochangelog work that was even
> already deployed in staging not go anywhere?

If you're thinking about rpmautospec, I have in mind to submit it as a change
proposal in the coming month. Fall has been quite busy after the data center
move and I also did not want to have everyone check it and FESCo spend time on
it in a timeframe where we couldn't put up with the work afterward.
So my idea is to submit it in Q1 (Jan-March) to start on it (if approved) in Q2
(May-June).


Pierre
___
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