date:20220121

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



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

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

[Bug 2043312] perl-CPAN-Perl-Releases-5.20220120 is available

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



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

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

[Bug 2043798] New: Please enable wide character support available in perl-Curses

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

Bug ID: 2043798
   Summary: Please enable wide character support available in
perl-Curses
   Product: Fedora
   Version: 34
Status: NEW
 Component: perl-Curses-UI
  Severity: medium
  Assignee: david.hanneq...@gmail.com
  Reporter: byodl...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: david.hanneq...@gmail.com, emman...@seyman.fr,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Created attachment 1852640
  --> https://bugzilla.redhat.com/attachment.cgi?id=1852640=edit
Adds a find/sed line to the specfile to enable UTF-8

Description of problem:

UTF-8 fails to render properly in Curses::UI widgets, but as noted in the last
comment here:

- https://rt.cpan.org/Public/Bug/Display.html?id=56695

perl-Curses-1.29 and later support this properly, and to use it, we just need
to patch Curses::UI with s/getch/getchar/g and s/addstr/addstring/g

In testing, that does indeed appear to make everything work as desired, so I've
enclosed a diff that could be added to the spec file.  It literally just adds
this line after the existing find(1):

find -name '*.pm' -exec sed -i -e 's/addstr/addstring/g' -e 's/getch/getchar/g'
{} +

Thanks in advance.


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

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

2022-01-21 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-f37ca1b24a   
guacamole-server-1.4.0-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-92a697e332   
zabbix40-4.0.37-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c99f63fce9   
zabbix50-5.0.19-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e18dcf2d58   
uglify-js-3.14.5-2.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-246382d5dc   
golang-1.16.13-2.el7


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

monit-5.30.0-1.el7

Details about builds:



 monit-5.30.0-1.el7 (FEDORA-EPEL-2022-603933287c)
 Manages and monitors processes, files, directories and devices

Update Information:

Update to 5.30.0 (various bugfixes and improvements).

ChangeLog:

* Thu Jan 20 2022 Stewart Adam  - 5.30.0-1
- Update to 5.30.0

References:

  [ 1 ] Bug #1874909 - Missing option in monit.service
https://bugzilla.redhat.com/show_bug.cgi?id=1874909
  [ 2 ] Bug #2039927 - monit-5.30.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2039927


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

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

2022-01-21 Thread updates

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-806b3f5921   
guacamole-server-1.4.0-1.el8


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

fcitx-qt5-1.2.4-4.el8
monit-5.30.0-1.el8
packit-0.44.0-1.el8

Details about builds:



 fcitx-qt5-1.2.4-4.el8 (FEDORA-EPEL-2022-64dc24f255)
 Fcitx IM module for Qt5

Update Information:

rebuild

ChangeLog:

* Fri Jan 21 2022 Qiyu Yan  - 1.2.4-4
- rebuild to qt5 5.15.2 #(2043318)

References:

  [ 1 ] Bug #2043318 - fcitx-qt5 is not installable in RHEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=2043318




 monit-5.30.0-1.el8 (FEDORA-EPEL-2022-854fb5fe62)
 Manages and monitors processes, files, directories and devices

Update Information:

Update to 5.30.0 (various bugfixes and improvements).

ChangeLog:

* Thu Jan 20 2022 Stewart Adam  - 5.30.0-1
- Update to 5.30.0

References:

  [ 1 ] Bug #1874909 - Missing option in monit.service
https://bugzilla.redhat.com/show_bug.cgi?id=1874909
  [ 2 ] Bug #2039927 - monit-5.30.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2039927




 packit-0.44.0-1.el8 (FEDORA-EPEL-2022-a12f6e5d1c)
 A tool for integrating upstream projects with Fedora operating system

Update Information:

0.44.0 upstream release

ChangeLog:

* Thu Jan 20 2022 Packit Service  - 
0.44.0-1
- Packit now correctly finds the release, even if you don't use the version as
  the title of the release on GitHub. 
([packit#1437](https://github.com/packit/packit/pull/1437))
- Local branches are now named as `pr/{pr_id}` when checking out a PR, even
  when it's not being merged with the target branch. This results in the NVR
  of the build containing `pr{pr_id}` instead of `pr.changes{pr_id}`. 
([packit#1445](https://github.com/packit/packit/pull/1445))
- A bug which caused ignoring the `--no-bump` and `--release-suffix` options
  when creating an SRPMs from source-git repositories has been fixed. Packit
  also doesn't touch the `Release` field in the specfile unless it needs to be
  changed (the macros are not expanded that way when not necessary). 
([packit#1452](https://github.com/packit/packit/pull/1452))
- When checking if directories hold a Git-tree, Packit now also allows `.git`
  to be a file with a `gitdir` reference, not only a directory. 
([packit#1458](https://github.com/packit/packit/pull/1458))


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

[Bug 2033349] perl-Test-Modern for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-d804fab894 has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-d804fab894

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

[Bug 2031806] perl-Mouse for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-1526c502bd has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1526c502bd

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

[Bug 2037655] Please branch and build perl-Pod-Coverage-Moose for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-4b4872597d has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4b4872597d

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

[Bug 2038143] Please branch and build perl-HTML-TableExtract for EPEL-9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-9610bed660 has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-9610bed660

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

[Bug 2037860] Please branch and build perl-HTML-Element-Extended for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-e9bfbe9c10 has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e9bfbe9c10

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

[Bug 2031330] Please branch and build perl-HTTP-BrowserDetect in epel9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-b4890fff18 has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-b4890fff18

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

[Test-Announce] 2022-01-24 @ 16:00 UTC - Fedora QA Meeting

2022-01-21 Thread Adam Williamson

# Fedora Quality Assurance Meeting
# Date: 2022-01-24
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.libera.chat

Greetings testers!

We have a few proposals and new community events to talk about, so
let's get together for a meeting on Monday!

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 36 status
3. Current criteria / test case proposals
4. Test Day / community event status
5. Open floor
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

[Bug 2043320] perl-Module-CoreList-5.20220120 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

[Bug 2043312] perl-CPAN-Perl-Releases-5.20220120 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

Re: Build failure in Clementine due to GCC 12

2022-01-21 Thread Robert-André Mauchin


On 1/21/22 22:55, Jonathan Wakely wrote:

On Fri, 21 Jan 2022 at 17:42, Jonathan Wakely  wrote:


On Fri, 21 Jan 2022 at 16:37, Robert-André Mauchin  wrote:


On 1/21/22 14:46, Robert-André Mauchin wrote:

Hello,

So I built Clementine last week with no issue, but it failed during
the mass rebuild with the folloing error:

In file included from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
 In instantiation of 'WorkerPool::WorkerPool(QObject*) [with HandlerType 
= AbstractMessageHandler]':
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
required from here
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
 error: passing 'QString' as 'this' argument discards qualifiers [-fpermissive]
 168 |   local_server_name_ = qApp->applicationName().toLower();
 |   ^
In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
from /usr/include/qt5/QtCore/qlist.h:47,
from /usr/include/qt5/QtCore/qstringlist.h:41,
from /usr/include/qt5/QtCore/QStringList:1,
from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
/usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
QString::toLower() &&'
 510 | Q_REQUIRED_RESULT QString toLower() &&
 |   ^~~


Nothing stands up to me in the linked code:

template 
WorkerPool::WorkerPool(QObject* parent)
  : _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
local_server_name_ = qApp->applicationName().toLower();

if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
}


Anyone knows if a flag, or compiler, has changed since last week? Or have any 
input at all?

Best regards,

Robert-André


So the problem is specific to GCC 12 but I can't find anything in the changelog 
related to this.
It seems toLower() takes a const as input and qApp->applicationName() is not a 
const.


No, you have it backwards.

QString::toLower() && can only be called on a non-const rvalue, and
applicationName() is apparently returning a const object.



I solved by replacing
local_server_name_ = qApp->applicationName().toLower();
to
local_server_name_ = QString(qApp->applicationName()).toLower();


This creates an rvalue, which allows the call to toLower().


Still I would love for a GCC specialist to point me to the relevant change in 
GCC 12 so I can
send a patch upstream with explanation for the change.


The Qt code has two overloads:

 Q_REQUIRED_RESULT QString toLower() const &
 { return toLower_helper(*this); }
 Q_REQUIRED_RESULT QString toLower() &&
 { return toLower_helper(*this); }

For some reason, the second one is being used when it should be the first.

I don't think this is a GCC change though.


I was wrong, this is a weird GCC overload resolution bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104173



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

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

2022-01-21 Thread Robert-André Mauchin


On 10/25/21 21:09, Ben Cotton wrote:

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

== Summary ==
All binaries (executables and shared libraries) are annotated with an
ELF note that identifies the rpm for which this file was built. This
allows binaries to be identified when they are distributed without any
of the rpm metadata. `systemd-coredump` uses this to log package
versions when reporting crashes.

== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbys...@in.waw.pl
* Name: Lennart Poettering
* Email: mzsrq...@0pointer.net


== Detailed Description ==
People mix binaries (programs and libraries) from different
distributions (for example using Fedora containers on Debian or vice
versa), and distribute binaries without packaging metadata (for
example by stripping everything except the binary from a container
image, also removing `/usr/lib/.build-id/*`), compile their own rpm
packages (for internal distribution and installation), and compile and
distribute their own binaries. Sometimes we need to introspect a
binary and figure out its provenance, for example when a program
crashes and we are looking at a core dump, but also when we have a
binary without the packaging metadata. When the need to introspect a
binary arises, we have some very good mechanisms to show the
provenance: when a file is installed through the package manager we
can directly list the providing package, but even without this we can
use build-ids embedded in the binary to uniquely identify the
originating build. But those mechanisms work best when we're in the
realm of a single distribution. In particular, build-ids can be easily
tied to a source rpm, but only when we have the source rpm is part of
the distribution and the build-id was registered in the appropriate
database which maps build-ids to real package names. When we move
outside of the realm of a single distribution, it can be hard to
figure out where a given binary originates from. If we know that a
binary is from a given distribution, we may be able to use some
distro-specific mechanism to figure out this information. But those
mechanisms will be different for different distributions and will
often require network access. With this change we aim to provide a
mechanism that is is very simple, provides a "human-readable" origin
information without further processing, is portable across distros,
and works without network access.

The directly motivating use case is display of core dumps. Right now
we have build-ids, but those are just opaque hexadecimal numbers that
are not meaningful to users. We would like to immediately list
versions of packages involved in the crash (including both the program
and any libraries it links to). It is not enough to query the rpm
database to do the equivalent of `rpm -qf …`: very often programs
crash after some packages have been upgraded and the binaries loaded
into memory are not the binaries that are currently present on disk,
or when through some mishap, the binaries on disk do not match the
installed rpms.  A mechanism that works without rpm database lookup or
network access allows this information to be showed immediately in
`coredumpctl` listings and journal entries about the crash. This
includes crashes that happen in the initrd and sandboxed containers.

A second motivating use case is when users distribute their own
binaries and would like to collect crash information. Build-ids are a
solution that is technically possible, but easy to get wrong in
practice: users would need to immediately record the build-id after
the build and store the mapping to program names, versions, and build
number in some database. It's much easier to be able to record
something during the build in the build product itself.

A third motivating use case is the general mixing of Fedora binaries
with programs and libraries from different distributions, both with
our binaries being used as the base for foreign binaries, and the
other way around. Whilst most distributions provide some mechanism to
figure out the source build information, those mechanisms vary by
distribution and may not be easy to access from a "foreign" system.
Such mixing is expected with containers, flatpaks, snaps, Python
binary wheels, anaconda packages, and quite often when somebody
compiles a binary and puts it up on the web for other people to
download.

We propose a new mechanism which is designed to be very simple but
extensible: a small JSON document is embedded in an section in the ELF
binary. This document can be easily read by a human if necessary, but
it is also well-defined and can be processed programatically. For
example, `systemd-coredump` will immediately make use of this to
display package ''nevra'' information for crashes. The format is also
easy to generate, so it can be added to any build system, either using
the helpers that we provide or even reimplemented from scratch.

For the case where we mix binaries from different

[Bug 2043770] New: perl-Net-HTTP-6.22 is available

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

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



Latest upstream release: 6.22
Current version/release in rawhide: 6.21-3.fc35
URL: http://search.cpan.org/dist/Net-HTTP/

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


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

Fedora-Rawhide-20220120.n.1 compose check report

2022-01-21 Thread Fedora compose checker

No missing expected images.

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

Failed openQA tests: 15/225 (x86_64), 17/157 (aarch64)

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

ID: 1110260 Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/1110260
ID: 1110264 Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/1110264
ID: 1110267 Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/1110267
ID: 1110356 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/1110356
ID: 1110357 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/1110357
ID: 1110410 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1110410
ID: 1110415 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/1110415
ID: 1110434 Test: x86_64 Workstation-upgrade desktop_login
URL: https://openqa.fedoraproject.org/tests/1110434
ID: 1110445 Test: x86_64 Workstation-upgrade desktop_browser
URL: https://openqa.fedoraproject.org/tests/1110445
ID: 1110447 Test: x86_64 Workstation-upgrade evince
URL: https://openqa.fedoraproject.org/tests/1110447
ID: 1110455 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1110455
ID: 1110546 Test: aarch64 universal install_mirrorlist_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1110546

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

ID: 1110285 Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/1110285
ID: 1110287 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1110287
ID: 1110292 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1110292
ID: 1110293 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1110293
ID: 1110322 Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/1110322
ID: 1110341 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1110341
ID: 1110393 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1110393
ID: 1110402 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1110402
ID: 1110407 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1110407
ID: 1110412 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1110412
ID: 1110440 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1110440
ID: 1110452 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1110452
ID: 1110454 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1110454
ID: 1110457 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1110457
ID: 1110459 Test: aarch64 Workstation-upgrade evince@uefi
URL: https://openqa.fedoraproject.org/tests/1110459
ID: 1110545 Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1110545
ID: 1110591 Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/1110591
ID: 1110608 Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1110608
ID: 1110609 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1110609
ID: 1110610 Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/1110610

Soft failed openQA tests: 13/157 (aarch64), 17/225 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 1110414 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1110414
ID: 1110465 Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1110465
ID: 1110482 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1110482
ID: 1110532 Test: x86_64 universal upgrade_2_realmd_client
URL:

[Bug 2043763] New: perl-libwww-perl-6.61 is available

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

Bug ID: 2043763
   Summary: perl-libwww-perl-6.61 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-libwww-perl
  Keywords: FutureFeature, Triaged
  Assignee: mspa...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com, ka...@ucw.cz,
mspa...@redhat.com,
perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.61
Current version/release in rawhide: 6.60-1.fc36
URL: http://search.cpan.org/dist/libwww-perl/

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


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

Re: MinGW & building wheels


Am 21.01.22 um 23:12 schrieb Scott Talbert:
I'm using the mingw stack to cross-compile a Windows binary which shipped as 
part of an otherwise platform neutral Python wheel. The main problem I had 
with Fedora's mingw Python was that I could not create a Windows wheel.


Yep, that's the same thing I'm trying to figure out.  The compiling part works 
fine - it's the mechanics of cross-building a wheel that don't seem as clear.


I figured I needed to run the mingw Python (with wine) to get an actual 
Windows wheel. That part would require a virtualenv for my package.


However I can avoid that problem alltogether as my wheel just needs to contain 
an exe file (as "data") so I can use the Linux Python 3 to create a 
platform-neutral wheel.


I think the venv part would require some more serious patching in Fedora (and 
I would love to see this but unfortunately I can't spend time getting this fixed).


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

question about review process excemptions for Python 3



Hi,

the packaging guidelines have a few excemptions for the package review process 
[1]. I'm working on updating certbot to Python 3 in EPEL 7 (rhbz 1797129, 
[2]). I need some additional Python 3 packages in EPEL 7 to achieve that and 
my question is which of these packages should get a proper review.



A) python3-augeas
https://bugzilla.redhat.com/show_bug.cgi?id=2043744

This is mostly the Fedora spec with just on additional bugfix (already 
upstream).


B) python3-josepy
intended spec file: 
https://github.com/FelixSchwarz/certbot-epel7-python3/blob/rawhide/python3-josepy/python-josepy.spec


I did not want to upgrade the existing EPEL 7 package as the required version 
is Python 3 only. We can not use some newer macros like %pytest but otherwise 
the spec is the same as in Fedora.



C) python3-boto3
python-boto3 (Python 2) version is in RHEL and won't get a Python3 package.
intended spec file: 
https://github.com/FelixSchwarz/certbot-epel7-python3/blob/rawhide/python3-boto3/python3-boto3.spec


The spec file is very close to the RHEL spec file just with some 
customizations removed.


Should I try to get reviews for each of the three packages or can I skip some 
of these according to the Fedora review policy?


Felix



[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process

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

[EPEL-devel] question about review process excemptions for Python 3



Hi,

the packaging guidelines have a few excemptions for the package review process 
[1]. I'm working on updating certbot to Python 3 in EPEL 7 (rhbz 1797129, 
[2]). I need some additional Python 3 packages in EPEL 7 to achieve that and 
my question is which of these packages should get a proper review.



A) python3-augeas
https://bugzilla.redhat.com/show_bug.cgi?id=2043744

This is mostly the Fedora spec with just on additional bugfix (already 
upstream).


B) python3-josepy
intended spec file: 
https://github.com/FelixSchwarz/certbot-epel7-python3/blob/rawhide/python3-josepy/python-josepy.spec


I did not want to upgrade the existing EPEL 7 package as the required version 
is Python 3 only. We can not use some newer macros like %pytest but otherwise 
the spec is the same as in Fedora.



C) python3-boto3
python-boto3 (Python 2) version is in RHEL and won't get a Python3 package.
intended spec file: 
https://github.com/FelixSchwarz/certbot-epel7-python3/blob/rawhide/python3-boto3/python3-boto3.spec


The spec file is very close to the RHEL spec file just with some 
customizations removed.


Should I try to get reviews for each of the three packages or can I skip some 
of these according to the Fedora review policy?


Felix



[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process

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

ROCm-Device-Libs packaging question

2022-01-21 Thread Jeremy Newton

In order to update "rocm-runtime" to the latest, it requires a new package 
"ROCm-Device-Libs" as a build requirement.
The issue is that the project installs files into /usr/amdgcn, which seems 
incorrect to me based on the FHS and Fedora guidelines. Here's the upstream for 
reference:
https://github.com/RadeonOpenCompute/ROCm-Device-Libs

I made a test package but to get it to pass rpmlint, I patched it to put amdgcn 
in "share/amdgcn" and made it a noarch package because it doesn't compile any 
cpu specific code. I proposed to upstream to make this change and it seems they 
don't agree and strongly prefer putting the files in "lib/amdgcn".

It seems the files are bitcode to be used with clang, so the binaries are not 
traditional libraries. At the moment these files are CPU arch independent, but 
they said they might want to add some x86 bit code later.

I guess I have a few questions:
- does bitcode belong in lib? share? Does it matter if these libraries are 
bitcode or not?
- if they were to add x86_64 bitcode, would it then belong in lib64? What about 
GPU related bitcode?
- If no debug info is generated, does this automatically make it a noarch 
package? I don't think bitcode would generate debug information regardless of 
arch
- Would lib/amdgcn would be ok if it's noarch?
- is this a fesco worthy question?

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

Re: MinGW & building wheels

2022-01-21 Thread Scott Talbert


On Fri, 21 Jan 2022, Felix Schwarz wrote:

Does anyone have any experience with using Fedora's MinGW stack to 
cross-compile Python wheels for Windows?


I'm using the mingw stack to cross-compile a Windows binary which shipped as 
part of an otherwise platform neutral Python wheel. The main problem I had 
with Fedora's mingw Python was that I could not create a Windows wheel.


Yep, that's the same thing I'm trying to figure out.  The compiling part 
works fine - it's the mechanics of cross-building a wheel that don't seem 
as clear.


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

Re: Build failure in Clementine due to GCC 12

2022-01-21 Thread Jonathan Wakely

On Fri, 21 Jan 2022 at 17:42, Jonathan Wakely  wrote:
>
> On Fri, 21 Jan 2022 at 16:37, Robert-André Mauchin  wrote:
> >
> > On 1/21/22 14:46, Robert-André Mauchin wrote:
> > > Hello,
> > >
> > > So I built Clementine last week with no issue, but it failed during
> > > the mass rebuild with the folloing error:
> > >
> > > In file included from 
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
> > >from 
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
> > >  In instantiation of 'WorkerPool::WorkerPool(QObject*) [with 
> > > HandlerType = AbstractMessageHandler]':
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
> > > required from here
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
> > >  error: passing 'QString' as 'this' argument discards qualifiers 
> > > [-fpermissive]
> > > 168 |   local_server_name_ = qApp->applicationName().toLower();
> > > |   ^
> > > In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
> > >from /usr/include/qt5/QtCore/qlist.h:47,
> > >from /usr/include/qt5/QtCore/qstringlist.h:41,
> > >from /usr/include/qt5/QtCore/QStringList:1,
> > >from 
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
> > > /usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
> > > QString::toLower() &&'
> > > 510 | Q_REQUIRED_RESULT QString toLower() &&
> > > |   ^~~
> > >
> > >
> > > Nothing stands up to me in the linked code:
> > >
> > > template 
> > > WorkerPool::WorkerPool(QObject* parent)
> > >  : _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
> > >worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
> > >local_server_name_ = qApp->applicationName().toLower();
> > >
> > >if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
> > > }
> > >
> > >
> > > Anyone knows if a flag, or compiler, has changed since last week? Or have 
> > > any input at all?
> > >
> > > Best regards,
> > >
> > > Robert-André
> >
> > So the problem is specific to GCC 12 but I can't find anything in the 
> > changelog related to this.
> > It seems toLower() takes a const as input and qApp->applicationName() is 
> > not a const.
>
> No, you have it backwards.
>
> QString::toLower() && can only be called on a non-const rvalue, and
> applicationName() is apparently returning a const object.
>
> >
> > I solved by replacing
> > local_server_name_ = qApp->applicationName().toLower();
> > to
> > local_server_name_ = QString(qApp->applicationName()).toLower();
>
> This creates an rvalue, which allows the call to toLower().
>
> > Still I would love for a GCC specialist to point me to the relevant change 
> > in GCC 12 so I can
> > send a patch upstream with explanation for the change.
>
> The Qt code has two overloads:
>
> Q_REQUIRED_RESULT QString toLower() const &
> { return toLower_helper(*this); }
> Q_REQUIRED_RESULT QString toLower() &&
> { return toLower_helper(*this); }
>
> For some reason, the second one is being used when it should be the first.
>
> I don't think this is a GCC change though.

I was wrong, this is a weird GCC overload resolution bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104173
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: MinGW & building wheels




Am 21.01.22 um 15:59 schrieb Scott Talbert:
Does anyone have any experience with using Fedora's MinGW stack to 
cross-compile Python wheels for Windows?


I'm using the mingw stack to cross-compile a Windows binary which shipped as 
part of an otherwise platform neutral Python wheel. The main problem I had 
with Fedora's mingw Python was that I could not create a Windows wheel.


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

GCC 12 question

2022-01-21 Thread Steven A. Falco


I've been able to rebuild KiCad using the new gcc-12.0.1-0.2 compiler rpms on 
Rawhide via mock.  While KiCad compiles, it doesn't quite run correctly.

As shown in the attached screenshot, all the icons are missing, and have been replaced 
with question marks.  I wonder if this could be caused by some Fedora libraries that have 
not yet been rebuilt using GCC-12.  I don't know if it is possible to "mix and 
match" things previously compiled with GCC-11 with things newly compiled with GCC-12.

I have a few questions:

1) Does it seem likely that some library (like wx) could be the cause, or is it 
more likely to be a bug in KiCad itself?

2) I believe a mass rebuild will be done soon, which might help, if a library 
is at fault - is there a schedule for that?

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

Re: Is systemd-resolved ignoring /etc/hosts?

2022-01-21 Thread Sergio Belkin

Oh My shame it's working indeed it was a typo, sorry and thanks :)

El vie, 21 ene 2022 a las 17:14, Tomasz Torcz ()
escribió:

> On Fri, Jan 21, 2022 at 05:06:01PM -0300, Sergio Belkin wrote:
> > Is there a way that systemd-resolved honors the /etc/hosts file?
> > Thanks in advance
>
>   There's ReadEtcHosts= setting controlling that. See "man resolved.conf"
> or /etc/systemd/resolved.conf itself.
>
> --
> Tomasz Torcz“Funeral in the morning, IDE hacking
> to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


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

Re: Is systemd-resolved ignoring /etc/hosts?

2022-01-21 Thread Tomasz Torcz

On Fri, Jan 21, 2022 at 05:06:01PM -0300, Sergio Belkin wrote:
> Is there a way that systemd-resolved honors the /etc/hosts file?
> Thanks in advance

  There's ReadEtcHosts= setting controlling that. See "man resolved.conf"
or /etc/systemd/resolved.conf itself.

-- 
Tomasz Torcz“Funeral in the morning, IDE hacking
to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F37 Change: Python Dist RPM provides to only provide PEP503-normalized names (Self-Contained Change proposal)

2022-01-21 Thread Ben Cotton

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

== Summary ==
The legacy `python3dist(NAME)` and `python3.11dist(NAME)` RPM provides
with dots (`.`) in `NAME` will no longer be automatically provided.
`NAME` will only be normalized according to
[https://www.python.org/dev/peps/pep-0503/#normalized-names PEP 503].
E.g. on Fedora 36 a package provides both `python3dist(ruamel-yaml)`
and `python3dist(ruamel.yaml)`, on Fedora 37+ it will only provide
`python3dist(ruamel-yaml)` (and similarly,
`python3.11dist(ruamel-yaml)`.

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com


== Detailed Description ==
This change is only about about automatic RPM provides in the following forms:

* `python3dist(NAME)`
* `python3.Xdist(NAME)`


It does not affect any other provides or package names.

Historically, Python package names were normalized by the RPM
dependency generators in a way that diverged from upstream behavior.
In upstream (e.g. when using `pip`) a package name with a dot is equal
to a package name with a dash (e.g. `pip install ruamel.yaml` and `pip
install ruamel-yaml` are equivalent). In Fedora, the ''Provides'' and
''Requires'' included the dot, but upstream rules defined in
[https://www.python.org/dev/peps/pep-0503/#normalized-names PEP 503]
demand the dot to be replaced by a dash. This caused trouble when
other packages required the packages via a name with a dash. Hence, we
have slowly been migrating to PEP 503 name normalization.

* Since Fedora 32, Python dependency generators have generated both
variants of the ''Provides'' as a preparation for the transition to
PEP 503-only.
* Since Fedora 33, Python dependency generators have generated
''Requires'' in the PEP 503 form (no dots).
* Only packages with manual ''BuildRequires'', ''Requires'',
''Recommends'' etc. with requirements such as `python3dist(foo.bar)`
would be affected by this change. We have fixed all of them in Fedora
36.


Hence, together with [[Changes/Python3.11|the update to Python3.11]],
we will disable the legacy form of the provides.

Python packages with dots in their name will only provide the names with dashes.

=== RHEL/EPEL compatibility ===

This change is fully compatible with RHEL/EPEL 9, which behaves like
Fedora 34 and hence has ''Provides'' in both forms but ''Requires'' in
the PEP 503 form (no dots).

This change is not compatible with RHEL/EPEL 8. If you need to have
manual requirements in the specfile that should work on Fedora 37+ and
RHEL/EPEL 8 in this form and the name includes a dot, we recommend
using 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#py3_dist
`%py3_dsit`].

This change is not relevant to RHEL 7.

This change is not compatible with EPEL 7. If you need to have manual
requirements in the specfile that should work on Fedora 37+ and
RHEL/EPEL 7 in this form and the name includes a dot, we recommend
using 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#py3_dist
`%py3_dsit`].


== Benefit to Fedora ==
* Less automatic provides in the repos - there are 93+93=186 provides
like `python3dist(x.y)` and `python3.Xdist(x.y)` in rawhide today.
* There will be only way way to express a Python package name in this
context, not two.
* One more thing the Python maintainers will cross off their TODO list.

== Scope ==
* Proposal owners:
# check there are really no more manual requirements with dots
# disable the automatically generated provides with dots when we
update to Python 3.11
# double-check there are really no more manual requirements with dots

* Other developers:
** stop adding new manual Python dist requirements with dots
* Release engineering: not needed for this Change
* Policies and guidelines: they already only cover PEP 503
* Trademark approval: not needed for this Change
* Alignment with Objectives: not really


== Upgrade/compatibility impact ==
This is done together with the Python 3.11 update to not have to deal
with little problems, such as packages that can't be rebuilt after the
manual requirements were changed.

== How To Test ==
The following 2 commands should yield nothing:

 $ repoquery --repo=rawhide --provides | grep -E
'^python3(\.[[:digit:]]+)?dist\(\S+\.\S+\)'
 $ repoquery --repo=rawhide --requires | grep -E
'^python3(\.[[:digit:]]+)?dist\(\S+\.\S+\)'

With the exception of packages that failed to rebuild with Python 3.11
(and those will need to be dealt with anyway one way or another).


The following example commands should only give the variant with dashes:

 $ repoquery --repo=rawhide --provides python3-ruamel-yaml | grep -E
'^python3(\.[[:digit:]]+)?dist\('
 $ repoquery --repo=rawhide --provides python3-jaraco-path | grep -E
'^python3(\.[[:digit:]]+)?dist\('

There should be no new broken dependencies because of this.

Note that wiki is eating my double `[]` in the regexes above around
`:digit:`. See the page source for the actual commands :(

== User Experience ==
The actual users should

F37 Change: Python Dist RPM provides to only provide PEP503-normalized names (Self-Contained Change proposal)

2022-01-21 Thread Ben Cotton

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

== Summary ==
The legacy `python3dist(NAME)` and `python3.11dist(NAME)` RPM provides
with dots (`.`) in `NAME` will no longer be automatically provided.
`NAME` will only be normalized according to
[https://www.python.org/dev/peps/pep-0503/#normalized-names PEP 503].
E.g. on Fedora 36 a package provides both `python3dist(ruamel-yaml)`
and `python3dist(ruamel.yaml)`, on Fedora 37+ it will only provide
`python3dist(ruamel-yaml)` (and similarly,
`python3.11dist(ruamel-yaml)`.

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com


== Detailed Description ==
This change is only about about automatic RPM provides in the following forms:

* `python3dist(NAME)`
* `python3.Xdist(NAME)`


It does not affect any other provides or package names.

Historically, Python package names were normalized by the RPM
dependency generators in a way that diverged from upstream behavior.
In upstream (e.g. when using `pip`) a package name with a dot is equal
to a package name with a dash (e.g. `pip install ruamel.yaml` and `pip
install ruamel-yaml` are equivalent). In Fedora, the ''Provides'' and
''Requires'' included the dot, but upstream rules defined in
[https://www.python.org/dev/peps/pep-0503/#normalized-names PEP 503]
demand the dot to be replaced by a dash. This caused trouble when
other packages required the packages via a name with a dash. Hence, we
have slowly been migrating to PEP 503 name normalization.

* Since Fedora 32, Python dependency generators have generated both
variants of the ''Provides'' as a preparation for the transition to
PEP 503-only.
* Since Fedora 33, Python dependency generators have generated
''Requires'' in the PEP 503 form (no dots).
* Only packages with manual ''BuildRequires'', ''Requires'',
''Recommends'' etc. with requirements such as `python3dist(foo.bar)`
would be affected by this change. We have fixed all of them in Fedora
36.


Hence, together with [[Changes/Python3.11|the update to Python3.11]],
we will disable the legacy form of the provides.

Python packages with dots in their name will only provide the names with dashes.

=== RHEL/EPEL compatibility ===

This change is fully compatible with RHEL/EPEL 9, which behaves like
Fedora 34 and hence has ''Provides'' in both forms but ''Requires'' in
the PEP 503 form (no dots).

This change is not compatible with RHEL/EPEL 8. If you need to have
manual requirements in the specfile that should work on Fedora 37+ and
RHEL/EPEL 8 in this form and the name includes a dot, we recommend
using 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#py3_dist
`%py3_dsit`].

This change is not relevant to RHEL 7.

This change is not compatible with EPEL 7. If you need to have manual
requirements in the specfile that should work on Fedora 37+ and
RHEL/EPEL 7 in this form and the name includes a dot, we recommend
using 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#py3_dist
`%py3_dsit`].


== Benefit to Fedora ==
* Less automatic provides in the repos - there are 93+93=186 provides
like `python3dist(x.y)` and `python3.Xdist(x.y)` in rawhide today.
* There will be only way way to express a Python package name in this
context, not two.
* One more thing the Python maintainers will cross off their TODO list.

== Scope ==
* Proposal owners:
# check there are really no more manual requirements with dots
# disable the automatically generated provides with dots when we
update to Python 3.11
# double-check there are really no more manual requirements with dots

* Other developers:
** stop adding new manual Python dist requirements with dots
* Release engineering: not needed for this Change
* Policies and guidelines: they already only cover PEP 503
* Trademark approval: not needed for this Change
* Alignment with Objectives: not really


== Upgrade/compatibility impact ==
This is done together with the Python 3.11 update to not have to deal
with little problems, such as packages that can't be rebuilt after the
manual requirements were changed.

== How To Test ==
The following 2 commands should yield nothing:

 $ repoquery --repo=rawhide --provides | grep -E
'^python3(\.[[:digit:]]+)?dist\(\S+\.\S+\)'
 $ repoquery --repo=rawhide --requires | grep -E
'^python3(\.[[:digit:]]+)?dist\(\S+\.\S+\)'

With the exception of packages that failed to rebuild with Python 3.11
(and those will need to be dealt with anyway one way or another).


The following example commands should only give the variant with dashes:

 $ repoquery --repo=rawhide --provides python3-ruamel-yaml | grep -E
'^python3(\.[[:digit:]]+)?dist\('
 $ repoquery --repo=rawhide --provides python3-jaraco-path | grep -E
'^python3(\.[[:digit:]]+)?dist\('

There should be no new broken dependencies because of this.

Note that wiki is eating my double `[]` in the regexes above around
`:digit:`. See the page source for the actual commands :(

== User Experience ==
The actual users should

Re: Non-responsive packagers: anoopcs, gtiwari, msehnout, sebix, vanessa_kris

2022-01-21 Thread Matthias Runge



> Am 20.01.2022 um 09:57 schrieb Pierre-Yves Chibon :
> 
> Good Morning Everyone,
> 
> The packagers listed here have been receiving a daily email asking them to
> either adjust their bugzilla or their FAS account so the email address in FAS
> matches an existing bugzilla account.
> 
> Having a bugzilla account is mandatory per:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> 
> 
> 
> - sebix contacted since December 4th
> 
> sebix is maintainer of rpms/lockfile-progs
> sebix has a bugzilla override on rpms/lockfile-progs
> sebix is maintainer of rpms/logcheck
> sebix has a bugzilla override on rpms/logcheck
> 
> 
> Thanks,
> 
> Pierre
> 

I have cc’d sebix to this email.

Sebastian, could you please take a look?

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

Is systemd-resolved ignoring /etc/hosts?

2022-01-21 Thread Sergio Belkin

Hi, On Fedora 35, I was that some domain name to be resolved by /etc/hosts
entry.

Let's says:

54.x.y.z somesite.miexample.com

(54.x.y.z is a ipv4 address)

With systemd-resolved is not working.

This my config:
resolvectl domain
Global:
Link 2 (wlp108s0):
Link 3 (docker0):
Link 4 (br-775990106ebc):
Link 13 (vboxnet0):
Link 14 (vboxnet1):
Link 15 (vboxnet2):
Link 16 (vboxnet3):
Link 22 (tun0): example.com

resolvectl dns
global:
Link 2 (wlp108s0): x.y.119.211 x.y.119.212
Link 3 (docker0):
Link 4 (br-775990106ebc):
Link 13 (vboxnet0):
Link 14 (vboxnet1):
Link 15 (vboxnet2):
Link 16 (vboxnet3):
Link 22 (tun0): 192.168.40.40 8.8.8.8

Is there a way that systemd-resolved honors the /etc/hosts file?

Thanks in advance

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

[Bug 2043320] perl-Module-CoreList-5.20220120 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2022-609a40897e has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-609a40897e


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

[Bug 2043320] perl-Module-CoreList-5.20220120 is available

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-4f49739d73 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-4f49739d73


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

[Bug 2043312] perl-CPAN-Perl-Releases-5.20220120 is available

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



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


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

[Bug 2043312] perl-CPAN-Perl-Releases-5.20220120 is available

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2022-36dc49da7f has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-36dc49da7f


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

[Bug 2043312] perl-CPAN-Perl-Releases-5.20220120 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-CPAN-Perl-Releases-5.2
   ||0220120-1.fc36
   Doc Type|--- |If docs needed, set a value
 CC|iarn...@gmail.com,  |
   |jples...@redhat.com |
 Status|NEW |MODIFIED




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

Fedora rawhide compose report: 20220120.n.1 changes

2022-01-21 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20220119.n.0
NEW: Fedora-Rawhide-20220120.n.1

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  8
Dropped packages:0
Upgraded packages:   129
Downgraded packages: 0

Size of added packages:  345.21 MiB
Size of dropped packages:0 B
Size of upgraded packages:   6.26 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-Rawhide-20220120.n.1.armhfp.raw.xz

= DROPPED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20220119.n.0.iso

= ADDED PACKAGES =
Package: erlang-protobuffs-0.9.2-4.fc36
Summary: A set of Protocol Buffers tools and modules for Erlang applications
RPMs:erlang-protobuffs
Size:46.01 KiB

Package: erlang-triq-1.3.0-8.fc36
Summary: A property-based testing library for Erlang
RPMs:erlang-triq
Size:41.24 KiB

Package: intel-llvm8.0-vc-intrinsics-0-1.20211222git753ad50.fc36
Summary: New intrinsics on top of core LLVM IR instructions
RPMs:intel-llvm8.0-vc-intrinsics intel-llvm8.0-vc-intrinsics-devel
Size:894.41 KiB

Package: intel-opencl-clang-13.0.0-1.fc36
Summary: Library to compile OpenCL C kernels to SPIR-V modules
RPMs:intel-opencl-clang intel-opencl-clang-devel
Size:543.91 KiB

Package: libnetconf2-2.0.24-1.fc36
Summary: NETCONF protocol library
RPMs:libnetconf2 libnetconf2-devel
Size:930.65 KiB

Package: libsoup3-3.0.4-1.fc36
Summary: Soup, an HTTP library implementation
RPMs:libsoup3 libsoup3-devel libsoup3-doc
Size:2.88 MiB

Package: llvm8.0-8.0.1-1.fc36
Summary: The Low Level Virtual Machine
RPMs:llvm8.0 llvm8.0-devel llvm8.0-doc llvm8.0-libs llvm8.0-static
Size:336.53 MiB

Package: spirv-llvm8.0-translator-8-1.20211223gita44863e.fc36
Summary: LLVM 8.0 to SPIRV Translator
RPMs:spirv-llvm8.0-translator spirv-llvm8.0-translator-devel 
spirv-llvm8.0-translator-tools
Size:3.40 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  CImg-1:3.0.2-1.fc36
Old package:  CImg-1:3.0.1-1.fc36
Summary:  C++ Template Image Processing Toolkit
RPMs: CImg-devel
Size: 11.19 MiB
Size change:  -1.27 KiB
Changelog:
  * Wed Jan 19 2022 Fedora Release Engineering  - 
1:3.0.1-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Thu Jan 20 2022 josef radinger  -3.0.2-1
  - bump version


Package:  abrt-2.15.0-2.fc36
Old package:  abrt-2.14.6-7.fc35
Summary:  Automatic bug detection and reporting tool
RPMs: abrt abrt-addon-ccpp abrt-addon-kerneloops abrt-addon-pstoreoops 
abrt-addon-upload-watch abrt-addon-vmcore abrt-addon-xorg abrt-atomic abrt-cli 
abrt-console-notification abrt-dbus abrt-desktop abrt-devel abrt-gui 
abrt-gui-devel abrt-gui-libs abrt-libs abrt-plugin-bodhi abrt-plugin-machine-id 
abrt-retrace-client abrt-tui python3-abrt python3-abrt-addon 
python3-abrt-container-addon python3-abrt-doc
Size: 6.48 MiB
Size change:  -185.33 KiB
Changelog:
  * Mon Sep 27 2021 Mat??j Grabovsk??  - 2.14.6-8
  - Use lazy import in the Python exception handler to avoid slowdown in Python
startup (rhbz#2007664)

  * Wed Dec 22 2021 Mat??j Grabovsk??  - 2.14.6-9
  - Rebuild for satyr 0.39

  * Thu Jan 06 2022 Mat??j Grabovsk??  - 2.14.6-10
  - Bump release for rebuild

  * Wed Jan 12 2022 Miro Hron??ok  - 2.14.6-11
  - Make abrt-tui and python3-abrt-container-addon noarch as they contain no 
architecture-specific content
  - Ensure Python bytecode in noarch subpackages is reproducible

  * Mon Jan 17 2022 Mat??j Grabovsk??  - 2.15.0-1
  - Bump abrt library version to 1:0:1
  - cli: Fix path and glob matching for abrt info etc.
  - abrt-dump-oops: Fix vmcore call trace parsing
  - Use lazy imports in abrt_exception_handler3
  - Don't copy coredump to problem dir
  - Detect Python 3.10 and Perl correctly in abrt-action-save-package-data
  - Fix calls to deprecated methods in tests
  - Update translations

  * Wed Jan 19 2022 Mat??j Grabovsk??  - 2.15.0-2
  - Rebuild for testing


Package:  abrt-java-connector-1.3.1-2.fc36
Old package:  abrt-java-connector-1.2.0-8.fc35
Summary:  JNI Agent library converting Java exceptions to ABRT problems
RPMs: abrt-java-connector abrt-java-connector-container
Size: 399.69 KiB
Size change:  5.95 KiB
Changelog:
  * Mon Jan 17 2022 Mat??j Grabovsk??  1.3.0-1
  - Bump libreport dependency to 2.14.0
  - Add make to build-time dependencies

  * Tue Jan 18 2022 Mat??j Grabovsk??  - 1.3.0-2
  - Fix failing tests

  * Wed Jan 19 2022 Mat??j Grabovsk??  - 1.3.1-1
  - New upstream release

  * Wed Jan 19 2022 Mat??j Grabovsk??  - 1.3.1-2
  - Rebuild for testing


Package:  alexandria-0.7.8-6.fc36.1
Old package:  alexandria-0.7.8-6.fc36
Summary:  Book collection manager
RPMs: alexandria
Size: 2.36 MiB
Size change:

[Bug 2032430] perl-Type-Tiny for EPEL 9

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



--- Comment #15 from Fedora Update System  ---
FEDORA-EPEL-2022-7b3a04be87 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-7b3a04be87


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

Re: GCC 12 related issues in rawhide


On 21. 01. 22 19:17, Jakub Jelinek wrote:

On Fri, Jan 21, 2022 at 07:10:53PM +0100, Miro Hrončok wrote:

On 21. 01. 22 19:07, Jakub Jelinek wrote:

On Fri, Jan 21, 2022 at 07:00:41PM +0100, Miro Hrončok wrote:

On 21. 01. 22 17:55, Jakub Jelinek wrote:

In all cases, if it is some compiler error or internal compiler error,
preprocessed source + gcc command line would be highly appreciated,
having us to try to rebuild all the packages again and dig those up
will be very time consuming.


But I suppose you know the best way to obtain those?

I build the package in mock and share the entire
.../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?


The reports are from various architectures, and mock takes some time,
especially if the error is hours into building.
I'm not saying I won't do it if what I'm asking for is not provided,
just that if somebody provides it to me, I will greatly appreciate it
and I (and my team collegues) can spend more time on fixing the bugs
and less on trying to reproduce them.
Several people already mailed me preprocessed sources (thanks a lot for
that) and I've been able to reply quickly to those.



Sorry for not speaking clearly. That was supposed to be a question.

What is the best way to obtain the files you need in order to share them with 
you?


Unless it is LTO related (that complicates things), best is to rerun
whatever gcc/g++ invocation failed with an unexpected error
or internal compiler error with additional -save-temps option, that will
leave the preprocessed file around.  For ICEs, the gcc/g++ driver even tries
to reproduce ICEs and if successful stores everything I need into
/tmp/cc*.out file and writes the name of that file to stderr.
So, if one sees that, using fedpkg to request tarball from the failed build
is one possibility and then copying the /tmp/cc*.out file out of there.
When it is reproducible in a local mock, rerunning the command by hand with
-save-temps is easy too, without access to the arch, one option is to hack
up the spec file, such that it will do:
make usual_stuff || \
( Either uuencode compressed /tmp/cc*.out to stdout here so that it shows up
in build.log or rerun failing gcc/g++ command line with the added
-save-temps here and uuencode compressed *.i or *.ii to stdout etc.
exit 1 )
(done that several times in the past when needed).


Thanks, Jakub.

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

Re: GCC 12 related issues in rawhide

On Fri, 21 Jan 2022 19:10:53 +0100
Miro Hrončok  wrote:

> On 21. 01. 22 19:07, Jakub Jelinek wrote:
> > On Fri, Jan 21, 2022 at 07:00:41PM +0100, Miro Hrončok wrote:
> >> On 21. 01. 22 17:55, Jakub Jelinek wrote:
> >>> In all cases, if it is some compiler error or internal compiler error,
> >>> preprocessed source + gcc command line would be highly appreciated,
> >>> having us to try to rebuild all the packages again and dig those up
> >>> will be very time consuming.
> >>
> >> But I suppose you know the best way to obtain those?
> >>
> >> I build the package in mock and share the entire
> >> .../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?
> > 
> > The reports are from various architectures, and mock takes some time,
> > especially if the error is hours into building.
> > I'm not saying I won't do it if what I'm asking for is not provided,
> > just that if somebody provides it to me, I will greatly appreciate it
> > and I (and my team collegues) can spend more time on fixing the bugs
> > and less on trying to reproduce them.
> > Several people already mailed me preprocessed sources (thanks a lot for
> > that) and I've been able to reply quickly to those.
> > 
> 
> Sorry for not speaking clearly. That was supposed to be a question.
> 
> What is the best way to obtain the files you need in order to share them with 
> you?

- rebuild locally in rawhide mock
- go to the mock chroot
- then to the build directory that calls gcc/g++
- rerun the gcc/g++ command to verify it still happens
- substitute -c for -E and *.o for *.i on the command line
- rerun
- grab the resulting *.i plus the full command line

That's roughly how I do it. Hope it answers your question :-)


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

Re: GCC 12 related issues in rawhide

On Fri, Jan 21, 2022 at 07:10:53PM +0100, Miro Hrončok wrote:
> On 21. 01. 22 19:07, Jakub Jelinek wrote:
> > On Fri, Jan 21, 2022 at 07:00:41PM +0100, Miro Hrončok wrote:
> > > On 21. 01. 22 17:55, Jakub Jelinek wrote:
> > > > In all cases, if it is some compiler error or internal compiler error,
> > > > preprocessed source + gcc command line would be highly appreciated,
> > > > having us to try to rebuild all the packages again and dig those up
> > > > will be very time consuming.
> > > 
> > > But I suppose you know the best way to obtain those?
> > > 
> > > I build the package in mock and share the entire
> > > .../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?
> > 
> > The reports are from various architectures, and mock takes some time,
> > especially if the error is hours into building.
> > I'm not saying I won't do it if what I'm asking for is not provided,
> > just that if somebody provides it to me, I will greatly appreciate it
> > and I (and my team collegues) can spend more time on fixing the bugs
> > and less on trying to reproduce them.
> > Several people already mailed me preprocessed sources (thanks a lot for
> > that) and I've been able to reply quickly to those.
> > 
> 
> Sorry for not speaking clearly. That was supposed to be a question.
> 
> What is the best way to obtain the files you need in order to share them with 
> you?

Unless it is LTO related (that complicates things), best is to rerun
whatever gcc/g++ invocation failed with an unexpected error
or internal compiler error with additional -save-temps option, that will
leave the preprocessed file around.  For ICEs, the gcc/g++ driver even tries
to reproduce ICEs and if successful stores everything I need into
/tmp/cc*.out file and writes the name of that file to stderr.
So, if one sees that, using fedpkg to request tarball from the failed build
is one possibility and then copying the /tmp/cc*.out file out of there.
When it is reproducible in a local mock, rerunning the command by hand with
-save-temps is easy too, without access to the arch, one option is to hack
up the spec file, such that it will do:
make usual_stuff || \
( Either uuencode compressed /tmp/cc*.out to stdout here so that it shows up
in build.log or rerun failing gcc/g++ command line with the added
-save-temps here and uuencode compressed *.i or *.ii to stdout etc.
exit 1 )
(done that several times in the past when needed).

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

Re: Uninitialized variables and F37

2022-01-21 Thread Michael Catanzaro

On Fri, Jan 21 2022 at 01:04:51 PM -0500, Steve Grubb 
 wrote:
He said this would have prevented over 900 fixed CVE's in Chrome and 
12% of

all Android CVE's.


I believe it. This should be treated like any other security hardening 
flag.


Michael

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

Re: GCC 12 related issues in rawhide


On 21. 01. 22 19:07, Jakub Jelinek wrote:

On Fri, Jan 21, 2022 at 07:00:41PM +0100, Miro Hrončok wrote:

On 21. 01. 22 17:55, Jakub Jelinek wrote:

In all cases, if it is some compiler error or internal compiler error,
preprocessed source + gcc command line would be highly appreciated,
having us to try to rebuild all the packages again and dig those up
will be very time consuming.


But I suppose you know the best way to obtain those?

I build the package in mock and share the entire
.../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?


The reports are from various architectures, and mock takes some time,
especially if the error is hours into building.
I'm not saying I won't do it if what I'm asking for is not provided,
just that if somebody provides it to me, I will greatly appreciate it
and I (and my team collegues) can spend more time on fixing the bugs
and less on trying to reproduce them.
Several people already mailed me preprocessed sources (thanks a lot for
that) and I've been able to reply quickly to those.



Sorry for not speaking clearly. That was supposed to be a question.

What is the best way to obtain the files you need in order to share them with 
you?

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

Re: GCC 12 related issues in rawhide

On Fri, Jan 21, 2022 at 07:00:41PM +0100, Miro Hrončok wrote:
> On 21. 01. 22 17:55, Jakub Jelinek wrote:
> > In all cases, if it is some compiler error or internal compiler error,
> > preprocessed source + gcc command line would be highly appreciated,
> > having us to try to rebuild all the packages again and dig those up
> > will be very time consuming.
> 
> But I suppose you know the best way to obtain those?
> 
> I build the package in mock and share the entire
> .../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?

The reports are from various architectures, and mock takes some time,
especially if the error is hours into building.
I'm not saying I won't do it if what I'm asking for is not provided,
just that if somebody provides it to me, I will greatly appreciate it
and I (and my team collegues) can spend more time on fixing the bugs
and less on trying to reproduce them.
Several people already mailed me preprocessed sources (thanks a lot for
that) and I've been able to reply quickly to those.

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

Re: Self Introduction: Chung Chung

2022-01-21 Thread Richard W.M. Jones

On Fri, Jan 21, 2022 at 07:34:05AM -0500, Chung Chung wrote:
> 
> Hi All:
> 
>   My name is Chung, I work in Red Hat and maintain lab systems for my team.
> 
>   I have been doing DevOps/SysAdmin for quite a few years now.   I have done
> some RPM package build for my group internally and I would like to contribute
> as a package maintainer.
> 
>   There are some packages we used in the lab I plan to take ownership of and I
> am open to taking on maintaining other packages also.
> 
>   Thanks and excited for the opportunity to contribute.

Hi and welcome to Fedora.  Let me know once the packager status has
gone through and we can look at Coccinelle.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-21 Thread Marek Polacek

On Fri, Jan 21, 2022 at 06:33:21PM +0100, Dan Horák wrote:
> On Fri, 21 Jan 2022 09:55:01 -0700
> Jerry James  wrote:
> 
> > On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek  wrote:
> > > Another important thing I wanted to say is that we'd like to switch
> > > ppc64le from the numerically problematic IBM extended long double to
> > > IEEE 754 quad long double.  This is an ABI change.  Some libraries
> > > are already built so that they support both ABIs at the same time,
> > > including glibc, libstdc++, libgcc, libgfortran etc.
> > > For other libraries and binaries, the compiler, assembler and linker
> > > will notice if they use long double and flag them as using either
> > > IBM or IEEE long double and linker (or I think dynamic linker too)
> > > might complain when things are mixed.
> > > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> > > but the glibc/gcc libraries are built compatibly with both.
> > > We'd like to configure gcc shortly before the mass rebuild with
> > > --with-long-double-format=ieee so that it will default to
> > > -mabi=ieeelongdouble, probably on a side-tag build first, and it
> > > will be highly desirable to rebuild at least some of the most commonly
> > > used library packages in the order of dependencies there, otherwise
> > > I'd be afraid the mass rebuild could fail for way too many packages
> > > (as the mass rebuild doesn't do dependency order rebuilds but just
> > > goes through packages alphabetically or so).
> > 
> > I don't know if this change is involved, but I've got several packages
> > that failed to build on ppc64le only, with what look like gcc
> > segfaults:
> > - dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527
> > - libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813
> > - libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797
> > - mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297
> 
> ^^^ those are probably
> https://bugzilla.redhat.com/show_bug.cgi?id=2043517

I think you're right.  And #2043517 is the same as #2043357.

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

Re: s390 ruby build failure

2022-01-21 Thread Richard W.M. Jones

To follow up on this thread, I did a scratch build this morning with
some extra instrumentation which was meant to capture the Ruby log
file if the build failed.  But the scratch build succeeded this time
on s390x, although it still failed overall because of the kernel bug.

So I decided to leave it until the kernel bug is fixed and worry about
it afterwards if it happens again.

Thanks all!

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Uninitialized variables and F37

2022-01-21 Thread Steve Grubb

Hello,

This is a continuation of the discussion from F36 Change: GNU Toolchain
Update.

Uninitialized variables are a big problem. They can be sources of information
exposure if parts of a buffer are not initialized. They can also cause
unexpected execution paths if the attacker can groom the memory to a value of
their choosing. If the variable is a pointer to heap, this can cause free to
corrupt memory under certain circumstances. If the uninitialized memory is
part of user input, this can lead to improper input validation. This is not
hypothetical. All of these come from a paper doing an emprical study of
android flaws. [1] The data used in the paper is here. [2]

Part of the problem is that compilers and static analysis tools can't always
find them. I created a test program that has 8 uses of unintialized variables.
Gcc 11 misses all of them. Gcc 12 finds 2. Clang 13 finds 1. cppcheck finds 2
or
3 - but does so much complaining you'd think it found all. Valgrind finds 2.
Flexelint, a commercial linter, finds 1.

Since tools can't always find them, the only option we have right now is force
initialization to something the attacker cannot control. Kees Cook started a
discussion on the llvm developers mail list a while back. He makes a very
clear argument. I would be repeating his points, so please read the original
discussion here (also read the replies):

https://lists.llvm.org/pipermail/cfe-dev/2020-April/065221.html

He talks about -ftrivial-auto-var-init=zero being used for production builds
and -ftrivial-auto-var-init= being used for debug builds. The use
is not just the kernel. Consider a server that returns data across the
network to a client. It could possibly leak crypto keys or passwords if the
returned data structure has uninitialized memory.

For more background, the creator of this technology for LLVM presented a talk
about this feature at a past LLVM developer conference:

https://www.youtube.com/watch?v=I-XUHPimq3o

He said this would have prevented over 900 fixed CVE's in Chrome and 12% of
all Android CVE's.

From deep inside the LLVM thread above, comes this nugget:
---
To add in, we (Microsoft) currently use zero initialization technology in
Visual Studio in a large amount of production code we ship to customers (all
kernel components, a number of user-mode components). This code is both C and
C++.

We already have had multiple vulnerabilities killed because we shipped this
technology in production. We received bug reports with repros that worked on
older versions of Windows without the mitigation and new versions of Windows
that do have it. The new versions don't repro, the old ones do.
---

Microsoft is also digging in to uninitialized variables. They have a lengthy
blog post that talks about extending this to heap memory. [3]

I think this would be an important step forward to turn this on across all
compilations. We could wipe out an entire class of bugs in one fell swoop.
But then, what about heap allocations? Calloc has existed for a long time. It
might be worthwhile to have a CFLAG that can tell glibc (or other allocators)
to substitute something like calloc for malloc.

Cheers,
-Steve

[1] - https://picture.iczhiku.com/resource/paper/shkeTWJEaFUuWCMc.pdf

[2] - http://ml-papers.gitlab.io/android.vulnerabilities-2017/appendix/
MSR2017/vulnerabilitiesList.html

[3] -
https://msrc-blog.microsoft.com/2020/07/02/solving-uninitialized-kernel-pool-memory-on-windows/

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

Re: GCC 12 related issues in rawhide


On 21. 01. 22 17:55, Jakub Jelinek wrote:

In all cases, if it is some compiler error or internal compiler error,
preprocessed source + gcc command line would be highly appreciated,
having us to try to rebuild all the packages again and dig those up
will be very time consuming.


But I suppose you know the best way to obtain those?

I build the package in mock and share the entire 
.../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?


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

Orphaned package: imake

2022-01-21 Thread Adam Jackson

I ported X off of imake a bit over 16 years ago but apparently there's
still 20-odd packages that use it. I don't have the bandwidth or
interest to maintain it, so someone who does is welcome to pick it up.

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

Re: F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)

2022-01-21 Thread Mark Wielaard

Hi,

On Thu, 2022-01-20 at 17:56 -0500, Marek Polacek wrote:
> On Tue, Jan 11, 2022 at 05:00:57PM -0500, Carlos O'Donell wrote:
> > On 1/11/22 13:00, Steve Grubb wrote:
> > > Reading through the GCC 12 changes, there is a significant new feature to 
> > > GCC 
> > > that would appear to be useful for security. There is a new:
> > > 
> > > -ftrivial-auto-var-init=zero
> > > 
> > > flag that initializes all stack variables to zero. Zero being a nice safe 
> > > value that makes programs crash instead of being exploitable.
> > > 
> > > Are there plans to enable this flag so that all applications, but more 
> > > importantly the kernel, are hardened against uninitialized stack 
> > > variables? 
> > > This is one of the major classes of security bugs that could potentially 
> > > be 
> > > eliminated during this mass rebuild.
> > 
> > There are currently no plans that I am aware of that involve turning on
> > '-ftrivial-auto-var-init=zero' in the short term for Fedora. CC'ing Jakub
> > and Marek to comment.
> 
> Also not aware of any plans to always enable it.
>  
> > It is something that should be discussed, turned on in Rawhide first,
> > and likely via redhat-rpm-config default flags first, and then we should
> > fix any fallout.
> > 
> > I'd only be comfortable if we did it early and worked through the 
> > consequences.
> > So it could be something to discuss for F37.
> 
> Right.  It reminds me of MALLOC_PERTURB_, but for automatic variables.
> 
> Obviously it's always important to measure its slowdown (maybe run a SPEC
> benchmark) / compile time / stack usage.  Some of it has been done:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562872.html
> but that was an early version of the patch.  Still, it seems like it'd be
> acceptable.
> 
> It's a new feature, only present in GCC 12 (which hasn't been released as of
> now), so I think it needs more testing before it could be (considered to be)
> enabled by default.
> 
> A good thing is that it doesn't suppress the -Wuninitialized warning so
> you still get a chance to fix your bugs.  It also comes with an attribute
> to keep variables uninitialized even when the options is turned on.

Note that it does make it impossible for valgrind memcheck to track use
of uninitialized (stack) values because it will believe they have been
initialized with zero in any code that is build with this flag, and it
will assume that zero is a valid value.

Obviously as a valgrind hacker I am biased, believing lots of people
run valgrind on production code. So I do think that makes it harder to
find real security issues. Now the code will just appear to work using
a possibly bogus value of zero instead of valgrind memcheck pointing
out where and why you are using an uninitialized value.

Cheers,

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

On Fri, Jan 21, 2022 at 06:42:23PM +0100, Dan Horák wrote:
> > > 
> > > Also note that libmpc failed to build on ppc64le only:
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783
> > 
> > one test core-dumps, I will try a local build to see what's in the core
> 
> Error for mpc_pow_ld (1)
> expected (-9 46)
> got (1.00e0 0)
> FAIL tpow_ld (exit status: 1)
> 
> ^^^ might be related to
> https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition
> 
> 
> dd1.c:545: MPFR assertion failed: rnd_mode == MPFR_RNDA
> FAIL tset (exit status: 134)
> 
> ^^^ dunno

I'd bet the rebuilds need to go in gmp, then mpfr, then libmpc order
so that the first ones pick the new long double ABI.

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

Re: Build failure in Clementine due to GCC 12

2022-01-21 Thread Jonathan Wakely

On Fri, 21 Jan 2022 at 16:37, Robert-André Mauchin  wrote:
>
> On 1/21/22 14:46, Robert-André Mauchin wrote:
> > Hello,
> >
> > So I built Clementine last week with no issue, but it failed during
> > the mass rebuild with the folloing error:
> >
> > In file included from 
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
> >from 
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
> >  In instantiation of 'WorkerPool::WorkerPool(QObject*) [with 
> > HandlerType = AbstractMessageHandler]':
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
> > required from here
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
> >  error: passing 'QString' as 'this' argument discards qualifiers 
> > [-fpermissive]
> > 168 |   local_server_name_ = qApp->applicationName().toLower();
> > |   ^
> > In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
> >from /usr/include/qt5/QtCore/qlist.h:47,
> >from /usr/include/qt5/QtCore/qstringlist.h:41,
> >from /usr/include/qt5/QtCore/QStringList:1,
> >from 
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
> > /usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
> > QString::toLower() &&'
> > 510 | Q_REQUIRED_RESULT QString toLower() &&
> > |   ^~~
> >
> >
> > Nothing stands up to me in the linked code:
> >
> > template 
> > WorkerPool::WorkerPool(QObject* parent)
> >  : _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
> >worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
> >local_server_name_ = qApp->applicationName().toLower();
> >
> >if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
> > }
> >
> >
> > Anyone knows if a flag, or compiler, has changed since last week? Or have 
> > any input at all?
> >
> > Best regards,
> >
> > Robert-André
>
> So the problem is specific to GCC 12 but I can't find anything in the 
> changelog related to this.
> It seems toLower() takes a const as input and qApp->applicationName() is not 
> a const.

No, you have it backwards.

QString::toLower() && can only be called on a non-const rvalue, and
applicationName() is apparently returning a const object.

>
> I solved by replacing
> local_server_name_ = qApp->applicationName().toLower();
> to
> local_server_name_ = QString(qApp->applicationName()).toLower();

This creates an rvalue, which allows the call to toLower().

> Still I would love for a GCC specialist to point me to the relevant change in 
> GCC 12 so I can
> send a patch upstream with explanation for the change.

The Qt code has two overloads:

Q_REQUIRED_RESULT QString toLower() const &
{ return toLower_helper(*this); }
Q_REQUIRED_RESULT QString toLower() &&
{ return toLower_helper(*this); }

For some reason, the second one is being used when it should be the first.

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

> > 
> > Also note that libmpc failed to build on ppc64le only:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783
> 
> one test core-dumps, I will try a local build to see what's in the core

Error for mpc_pow_ld (1)
expected (-9 46)
got (1.00e0 0)
FAIL tpow_ld (exit status: 1)

^^^ might be related to
https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition


dd1.c:545: MPFR assertion failed: rnd_mode == MPFR_RNDA
FAIL tset (exit status: 134)

^^^ dunno


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

[Bug 2042922] Please branch and build perl-Future for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-9b06b94e61 has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-9b06b94e61

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

[Bug 2042872] Please branch and build perl-bareword-filehandles for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-0b67734bdf has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0b67734bdf

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

[Bug 2042871] Please branch and build perl-multidimensional for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-5ef60c45ee has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-5ef60c45ee

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

On Fri, 21 Jan 2022 09:55:01 -0700
Jerry James  wrote:

> On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek  wrote:
> > Another important thing I wanted to say is that we'd like to switch
> > ppc64le from the numerically problematic IBM extended long double to
> > IEEE 754 quad long double.  This is an ABI change.  Some libraries
> > are already built so that they support both ABIs at the same time,
> > including glibc, libstdc++, libgcc, libgfortran etc.
> > For other libraries and binaries, the compiler, assembler and linker
> > will notice if they use long double and flag them as using either
> > IBM or IEEE long double and linker (or I think dynamic linker too)
> > might complain when things are mixed.
> > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> > but the glibc/gcc libraries are built compatibly with both.
> > We'd like to configure gcc shortly before the mass rebuild with
> > --with-long-double-format=ieee so that it will default to
> > -mabi=ieeelongdouble, probably on a side-tag build first, and it
> > will be highly desirable to rebuild at least some of the most commonly
> > used library packages in the order of dependencies there, otherwise
> > I'd be afraid the mass rebuild could fail for way too many packages
> > (as the mass rebuild doesn't do dependency order rebuilds but just
> > goes through packages alphabetically or so).
> 
> I don't know if this change is involved, but I've got several packages
> that failed to build on ppc64le only, with what look like gcc
> segfaults:
> - dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527
> - libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813
> - libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797
> - mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297

^^^ those are probably
https://bugzilla.redhat.com/show_bug.cgi?id=2043517

> - cli11: https://koji.fedoraproject.org/koji/taskinfo?taskID=81476792
> - python-fpylll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81597035

^^^ those are different, but also LTO related

> 
> Also note that libmpc failed to build on ppc64le only:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783

one test core-dumps, I will try a local build to see what's in the core


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

Re: gcc-12.0.0-0.4.fc36 in rawhide

On Fri, 21 Jan 2022 10:09:39 -0700
Jerry James  wrote:

> On Fri, Jan 21, 2022 at 10:06 AM Dan Horák  wrote:
> > could be https://bugzilla.redhat.com/show_bug.cgi?id=2043517
> 
> Thanks for the pointer, Dan.

I think the keyword for this bug is "during RTL pass: final" followed
by an ICE segfault

But there could be other issues too ...


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

Re: F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)

2022-01-21 Thread Steve Grubb

Hello,

On Thursday, January 20, 2022 5:56:04 PM EST Marek Polacek wrote:
> > > Are there plans to enable this flag so that all applications, but more
> > > importantly the kernel, are hardened against uninitialized stack
> > > variables? This is one of the major classes of security bugs that
> > > could potentially be eliminated during this mass rebuild.
> > 
> > There are currently no plans that I am aware of that involve turning on
> > '-ftrivial-auto-var-init=zero' in the short term for Fedora. CC'ing Jakub
> > and Marek to comment.
> 
> Also not aware of any plans to always enable it.

I think we should consider it. I'll start a new thread so that the topic is 
clearer.
 
> > It is something that should be discussed, turned on in Rawhide first,
> > and likely via redhat-rpm-config default flags first, and then we should
> > fix any fallout.
> > 
> > I'd only be comfortable if we did it early and worked through the
> > consequences. So it could be something to discuss for F37.
> 
> Right.  It reminds me of MALLOC_PERTURB_, but for automatic variables.
> 
> Obviously it's always important to measure its slowdown (maybe run a SPEC
> benchmark) / compile time / stack usage.  Some of it has been done:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562872.html
> but that was an early version of the patch.  Still, it seems like it'd be
> acceptable.
> 
> It's a new feature, only present in GCC 12 (which hasn't been released as
> of now), so I think it needs more testing before it could be (considered
> to be) enabled by default.

That's fine. I think F37 is a good target.

> A good thing is that it doesn't suppress the -Wuninitialized warning so
> you still get a chance to fix your bugs.  It also comes with an attribute
> to keep variables uninitialized even when the options is turned on.
> 
> From what I've seen its the kernel that would most benefit from the option,
> and it looks like it already has support for it:
> 
> CONFIG_INIT_STACK_ALL_ZERO
> CONFIG_INIT_STACK_ALL_PATTERN
> 
> so maybe it's enough to enable it for the kernel.  Or start there, see how
> it does, then add it to our hardening flags.

Unless it's been reworked to also allow gcc, this was a clang only option. 
There are a number of distributions that use clang as the compiler for the 
whole project. But let's discuss this in a separate thread about this topic.

Best Regards,
-Steve

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-21 Thread Jerry James

On Fri, Jan 21, 2022 at 10:06 AM Dan Horák  wrote:
> could be https://bugzilla.redhat.com/show_bug.cgi?id=2043517

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

Re: s390 ruby build failure

2022-01-21 Thread Kevin Fenzi

On Fri, Jan 21, 2022 at 12:20:48PM +0100, Vít Ondruch wrote:
> 
> 
> I can't do that:
> 
> 
> ~~~
> 
> $ koji save-failed-tree 81534987
> 2022-01-21 12:20:12,267 [ERROR] koji: ActionNotAllowed: Only owner of failed
> task or 'admin' can run this task.

And sadly due to the mass rebuild churn it's already not available: 

 ~ koji save-failed-tree 81534987
Created task 81611235 for buildroot 32534387
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=81611235
Watching tasks (this may be safely interrupted)...
81611235 saveFailedTree (noarch): assigned
81611235 saveFailedTree (noarch): assigned -> FAILED: GenericError: Buildroot 
directory is missing: /var/lib/mock/f36-build-32534387-4400356/root/builddir
  0 free  0 open  0 done  1 failed

81611235 saveFailedTree (noarch) failed

I'd suggest just doing a scratch build and in that spec dumping out the
files you need for debugging.

kevin

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

On Fri, 21 Jan 2022 09:55:01 -0700
Jerry James  wrote:

> On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek  wrote:
> > Another important thing I wanted to say is that we'd like to switch
> > ppc64le from the numerically problematic IBM extended long double to
> > IEEE 754 quad long double.  This is an ABI change.  Some libraries
> > are already built so that they support both ABIs at the same time,
> > including glibc, libstdc++, libgcc, libgfortran etc.
> > For other libraries and binaries, the compiler, assembler and linker
> > will notice if they use long double and flag them as using either
> > IBM or IEEE long double and linker (or I think dynamic linker too)
> > might complain when things are mixed.
> > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> > but the glibc/gcc libraries are built compatibly with both.
> > We'd like to configure gcc shortly before the mass rebuild with
> > --with-long-double-format=ieee so that it will default to
> > -mabi=ieeelongdouble, probably on a side-tag build first, and it
> > will be highly desirable to rebuild at least some of the most commonly
> > used library packages in the order of dependencies there, otherwise
> > I'd be afraid the mass rebuild could fail for way too many packages
> > (as the mass rebuild doesn't do dependency order rebuilds but just
> > goes through packages alphabetically or so).
> 
> I don't know if this change is involved, but I've got several packages
> that failed to build on ppc64le only, with what look like gcc
> segfaults:
> - cli11: https://koji.fedoraproject.org/koji/taskinfo?taskID=81476792
> - dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527
> - libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813
> - libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797
> - mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297
> - python-fpylll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81597035

could be https://bugzilla.redhat.com/show_bug.cgi?id=2043517


Dan
 
> Also note that libmpc failed to build on ppc64le only:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783
> 
> Since gcc uses libmpc, it's probably important to look at that one carefully.
> -- 
> Jerry James
> http://www.jamezone.org/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: DIGLIM (System-Wide Change proposal)

2022-01-21 Thread Kevin Fenzi

On Wed, Jan 19, 2022 at 11:34:28AM +, Roberto Sassu via devel wrote:
> > From: Roberto Sassu
> > Sent: Tuesday, January 18, 2022 3:36 PM
> > Hi everyone
> > 
> > I recently sent to the kernel mailing lists a patch set to support
> > PGP keys and signatures.
> > 
> > Other than allowing the appraisal of RPM headers without
> > changes to the building infrastructure, it would also simplify
> > key management for the use cases requiring file or fsverity
> > signatures (no need for a secondary key).
> > 
> > This is the link of the patch set:
> > 
> > https://lore.kernel.org/linux-integrity/2022080318.591029-1-
> > roberto.sa...@huawei.com/
> > 
> > One point of the discussion was if there is the need to support
> > PGP in the kernel, or if a distribution should adapt its key
> > management to be compatible with key types currently available
> > in the kernel.
> 
> I have a question related to this. Is the private key used to sign
> kernel modules available also when other packages are built?

Nope. My understanding is that this is only available during that kernel
build and then disguarded. (But you could perhaps ask on fedora's kernel
list about it for more info). 

kevin


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

GCC 12 related issues in rawhide

Hi!

There have been way too many mails recently in the
gcc-12.0.0-0.4.fc36 in rawhide thread and separate threads,
so for those which we haven't responded to yet or new issues,
can I ask you to track it in bugzilla instead of mailing list?

For issues where you suspect it is a bug on a package side and
you'd just like the compiler team to help answer questions,
please file a FTBS bug against the package which fails to build
and CC me and/or Marek Polacek and/or for libstdc++ related questions
Jonathan Wakely.
For issues where you suspect or are sure about a bug on the compiler
side please file a bug against GCC (worst case the component can
be changed against the package).

In all cases, if it is some compiler error or internal compiler error,
preprocessed source + gcc command line would be highly appreciated,
having us to try to rebuild all the packages again and dig those up
will be very time consuming.

Thanks

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-21 Thread Jerry James

On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek  wrote:
> Another important thing I wanted to say is that we'd like to switch
> ppc64le from the numerically problematic IBM extended long double to
> IEEE 754 quad long double.  This is an ABI change.  Some libraries
> are already built so that they support both ABIs at the same time,
> including glibc, libstdc++, libgcc, libgfortran etc.
> For other libraries and binaries, the compiler, assembler and linker
> will notice if they use long double and flag them as using either
> IBM or IEEE long double and linker (or I think dynamic linker too)
> might complain when things are mixed.
> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> but the glibc/gcc libraries are built compatibly with both.
> We'd like to configure gcc shortly before the mass rebuild with
> --with-long-double-format=ieee so that it will default to
> -mabi=ieeelongdouble, probably on a side-tag build first, and it
> will be highly desirable to rebuild at least some of the most commonly
> used library packages in the order of dependencies there, otherwise
> I'd be afraid the mass rebuild could fail for way too many packages
> (as the mass rebuild doesn't do dependency order rebuilds but just
> goes through packages alphabetically or so).

I don't know if this change is involved, but I've got several packages
that failed to build on ppc64le only, with what look like gcc
segfaults:
- cli11: https://koji.fedoraproject.org/koji/taskinfo?taskID=81476792
- dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527
- libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813
- libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797
- mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297
- python-fpylll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81597035

Also note that libmpc failed to build on ppc64le only:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783

Since gcc uses libmpc, it's probably important to look at that one carefully.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2036122] Please branch and build perl-HTML-TreeBuilder-XPath for EPEL-8

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-HTML-TreeBuilder-XPath |perl-HTML-TreeBuilder-XPath
   |-0.14-30.el9|-0.14-30.el9
   ||perl-HTML-TreeBuilder-XPath
   ||-0.14-30.el8



--- Comment #10 from Fedora Update System  ---
FEDORA-EPEL-2022-2ad31b414c 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.
https://bugzilla.redhat.com/show_bug.cgi?id=2036122
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: git clone under mock/koji builders


On 21. 01. 22 17:39, Ron Olson wrote:

Is it possible to clone a repo as part of a Source line? I’ve been looking and 
can’t find any examples.


See 
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_revision_control 
and 
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_git_hosting_services


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

Re: git clone under mock/koji builders

2022-01-21 Thread Ron Olson

Is it possible to clone a repo as part of a Source line? I’ve been looking and 
can’t find any examples.

On 21 Jan 2022, at 10:34, Miro Hrončok wrote:

> On 21. 01. 22 17:21, Ron Olson wrote:
>> Hey all-
>>
>> I have a package that gets an artifact from a repo /and/ expects to have 
>> code from a different branch in the same repo. In my spec file, I can easily 
>> get the artifact via Sources, but getting the code from the separate branch 
>> required me to execute a “git clone” then checkout the branch. This works 
>> fine until I tried doing a mock build where I ran into the issue that 
>> networking like this is apparently unavailable. I saw that I can enabled it 
>> with a command line switch, but I presume that’s not possible with koji.
>>
>> Is there any proper way to checkout code with git from within koji?
>
> No. You need to add it as an extra Source. Koji builds are always offline.
>
> -- 
> Miro Hrončok
> -- 
> Phone: +420777974800
> IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: git clone under mock/koji builders

2022-01-21 Thread Vitaly Zaitsev via devel


On 21/01/2022 17:21, Ron Olson wrote:

Is there any proper way to checkout code with git from within koji?


No. Koji doesn't have network access for security reasons. You must 
download submodules/etc as sources.


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

Re: git clone under mock/koji builders


On 21. 01. 22 17:21, Ron Olson wrote:

Hey all-

I have a package that gets an artifact from a repo /and/ expects to have code 
from a different branch in the same repo. In my spec file, I can easily get the 
artifact via Sources, but getting the code from the separate branch required me 
to execute a “git clone” then checkout the branch. This works fine until I 
tried doing a mock build where I ran into the issue that networking like this 
is apparently unavailable. I saw that I can enabled it with a command line 
switch, but I presume that’s not possible with koji.


Is there any proper way to checkout code with git from within koji?


No. You need to add it as an extra Source. Koji builds are always offline.

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

Re: Build failure in Clementine due to GCC 12

2022-01-21 Thread Robert-André Mauchin


On 1/21/22 14:46, Robert-André Mauchin wrote:

Hello,

So I built Clementine last week with no issue, but it failed during
the mass rebuild with the folloing error:

In file included from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
   from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
 In instantiation of 'WorkerPool::WorkerPool(QObject*) [with HandlerType 
= AbstractMessageHandler]':
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
    required from here
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
 error: passing 'QString' as 'this' argument discards qualifiers [-fpermissive]
    168 |   local_server_name_ = qApp->applicationName().toLower();
    |   ^
In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
   from /usr/include/qt5/QtCore/qlist.h:47,
   from /usr/include/qt5/QtCore/qstringlist.h:41,
   from /usr/include/qt5/QtCore/QStringList:1,
   from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
/usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
QString::toLower() &&'
    510 | Q_REQUIRED_RESULT QString toLower() &&
    |   ^~~


Nothing stands up to me in the linked code:

template 
WorkerPool::WorkerPool(QObject* parent)
     : _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
   worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
   local_server_name_ = qApp->applicationName().toLower();

   if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
}


Anyone knows if a flag, or compiler, has changed since last week? Or have any 
input at all?

Best regards,

Robert-André


So the problem is specific to GCC 12 but I can't find anything in the changelog 
related to this.
It seems toLower() takes a const as input and qApp->applicationName() is not a 
const.

I solved by replacing
local_server_name_ = qApp->applicationName().toLower();
to
local_server_name_ = QString(qApp->applicationName()).toLower();

Still I would love for a GCC specialist to point me to the relevant change in 
GCC 12 so I can
send a patch upstream with explanation for the change.

Thank you.

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

Re: git clone under mock/koji builders

On Fri, 21 Jan 2022 10:21:11 -0600
Ron Olson  wrote:

> Hey all-
> 
> I have a package that gets an artifact from a repo *and* expects to have 
> code from a different branch in the same repo. In my spec file, I can 
> easily get the artifact via Sources, but getting the code from the 
> separate branch required me to execute a “git clone” then checkout 
> the branch. This works fine until I tried doing a mock build where I ran 
> into the issue that networking like this is apparently unavailable. I 
> saw that I can enabled it with a command line switch, but I presume 
> that’s not possible with koji.
> 
> Is there any proper way to checkout code with git from within koji?

builds in koji have network disabled by design


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

git clone under mock/koji builders

2022-01-21 Thread Ron Olson


Hey all-

I have a package that gets an artifact from a repo *and* expects to have 
code from a different branch in the same repo. In my spec file, I can 
easily get the artifact via Sources, but getting the code from the 
separate branch required me to execute a “git clone” then checkout 
the branch. This works fine until I tried doing a mock build where I ran 
into the issue that networking like this is apparently unavailable. I 
saw that I can enabled it with a command line switch, but I presume 
that’s not possible with koji.


Is there any proper way to checkout code with git from within koji?

Thanks for any info!

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

Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)


On 21. 01. 22 17:03, Zdenek Pytela wrote:

Hey folks,

I've just noticed that `ausearch -m AVC,USER_AVC -ts recent` lists a lot of:

type=AVC msg=audit(1642770831.616:31668): avc:  denied  { read } for
pid=866275 comm="locate" name="plocate.db" dev="dm-0" ino=5268062
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0

Is this a bug, or some kind of error in configuration?

plocate uses /var/lib/plocate as its data directory, so it needs to have 
assigned the correct label in selinux-policy. I've already submitted a PR for 
the change.
https://github.com/fedora-selinux/selinux-policy/pull/1018 



Thanks!

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

RE: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

2022-01-21 Thread Roberto Sassu via devel

Hi everyone

(note for the infrastructure mailing list: please check if the changes
I'm proposing could be tested in the Fedora infrastructure, like Copr)

I made the first version of the rpm extension to sign fsverity
digests with a GPG key. The patch set (with some bug fixes)
is available here:

https://github.com/robertosassu/rpm/commits/fsverity-gpg-v1

I tested it locally with my own GPG key. I took an existing
Fedora 34 package and signed it with rpmsign:

$ usr/bin/rpmsign --define "%_gpg_name testhost " \
 --define "%_file_signing_key _GPG_" \
 --define "%_file_signing_cert _GPG_" \
 --addsign --signverity 
tmux-3.1c-2.fc34.x86_64.rpm


I then checked that the package has now fsverity signatures:

$ usr/bin/rpm -qp tmux-3.1c-2.fc34.x86_64.rpm \
  --queryformat '[%{RPMTAG_FILENAMES} 
%{RPMTAG_VERITYSIGNATURES}\n]'
[...]
/usr/bin/tmux iQHHBAABCgAxFiEEEiFa0dGZVYzTrIN+rxtXRMfK0McFAmHq0+4THHRlc3Rob3N0
QHRlc3QudGVzdAAKCRCvG1dEx8rQx81nC/42NW9xJx3rcTiR6/5oL55GPkan+OIq
t2dW1clJUOrxOGVy/5JQTQf0MQXA7gzH1yPgcrskkahjSfWlp4pt7oOw3rukUyaO
zVZxue4XE6XESYtolczK4VEhpc8lbm4hj0e4NCg/dKri/+L5wIdJvmqWNeCfl7uZ
[...]

In a VM I tried to install the modified package. The root filesystem
is ext4 and has the fsverity feature enabled.

The fsverity rpm plugin is also enabled and hasn't been modified
to work with the new PGP signatures.

The kernel includes the patch set I recently sent to the kernel
mailing lists to add support for PGP keys and signatures:

https://lore.kernel.org/linux-integrity/2022080318.591029-1-roberto.sa...@huawei.com/

and another patch that calls verify_pgp_signature() in
fs/verity/signature.c.

The first installation attempt fails, due to the missing key
in the .fs-verity keyring:

# usr/bin/rpm -Uhvi ../tmux-3.1c-2.fc34.x86_64.rpm --debug
[...]
D: Plugin: calling hook fsm_file_prepare in fsverity plugin
D: applying signature: 
[...]
D: failed to enable verity (errno 126) for /usr/bin/tmux;61ead62d

Then, I added the required GPG key to the .fs-verity keyring:

# cat /mnt/repos/linux/certs/pubring.gpg | keyctl padd asymmetric test 
%keyring:.fs-verity
76292211

The key is now loaded:

# keyctl show %keyring:.fs-verity
Keyring
  66741466 --a-swrv  0 0  keyring: .fs-verity
  76292211 --als--v  0 0   \_ asymmetric: test

I retried the tmux installation:

# usr/bin/rpm -Uhvi ../tmux-3.1c-2.fc34.x86_64.rpm --debug
[...]
D: Plugin: calling hook fsm_file_prepare in fsverity plugin
D: applying signature: 
[...]
D: fsverity enabled signature for: path /usr/bin/tmux;61ead713 dest 
/usr/bin/tmux

This time the installation is successful, which means that the PGP
signature has been successfully verified.

Roberto

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

Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)

2022-01-21 Thread Zdenek Pytela

On Fri, Jan 21, 2022 at 2:24 PM Miro Hrončok  wrote:

> On 23. 11. 21 18:18, Ben Cotton wrote:
> >
> https://fedoraproject.org/wiki/Changes/Plocate_as_the_default_locate_implementation
> >
> > == Summary ==
> > The venerable `mlocate` program is replaced by `plocate` — a
> > compatible reimplementation that is faster and uses less disk space.
> >
> >
> > == Owner ==
> > * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
> > * Email: zbyszek at in.waw.pl
> > * Name: [[User:Msekleta| Michal Sekletár]]
> > * Email: msekleta at redhat.com
> > ...
>
> Hey folks,
>
> I've just noticed that `ausearch -m AVC,USER_AVC -ts recent` lists a lot
> of:
>
> type=AVC msg=audit(1642770831.616:31668): avc:  denied  { read } for
> pid=866275 comm="locate" name="plocate.db" dev="dm-0" ino=5268062
> scontext=system_u:system_r:setroubleshootd_t:s0
> tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
>
> Is this a bug, or some kind of error in configuration?
>
plocate uses /var/lib/plocate as its data directory, so it needs to have
assigned the correct label in selinux-policy. I've already submitted a PR
for the change.
https://github.com/fedora-selinux/selinux-policy/pull/1018


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


-- 

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

Re: Do I have a @fedoraproject.org e-mail address ?

2022-01-21 Thread Gary Buhrmaster

On Fri, Jan 21, 2022 at 3:27 PM Vít Ondruch  wrote:

> Isn't it just the standard GMail deduplication?

Likely.  For better or worse, that is the way gmail works.

One can see both the advantages and disadvantages
of the gmail approach, but it does catch some of the
people off-guard at least some of the time (even
those that are familiar with it).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2033349] perl-Test-Modern for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2022-d804fab894 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-d804fab894


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

[Bug 2031806] perl-Mouse for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-1526c502bd has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1526c502bd


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

[Bug 2038143] Please branch and build perl-HTML-TableExtract for EPEL-9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-9610bed660 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-9610bed660


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

Fedora Prioritized Bugs update

2022-01-21 Thread Ben Cotton

It's been a while since we've had some Prioritized Bugs that are
stuck, but here we are. If you can help move these forward, you are a
hero.

1. shim — https://bugzilla.redhat.com/show_bug.cgi?id=1955416 — NEW
Lenovo ThinkPad T490, unable to boot following clean install, stuck at
splash screen

This bug appears to affect multiple popular hardware vendors. Lenovo
is aware of the issue but hasn't been able to reproduce, nor have
maintainers. mattdm was going to connect with the Red Hat Desktop team
to see if they could reproduce. If someone can reliably reproduce this
and test development builds of shim, that would help diagnose the
issue.

2. flatpak — https://bugzilla.redhat.com/show_bug.cgi?id=2032528 — NEW
Flatpak using excessive space in /var/lib/flatpak/appstream

For some users, the appstream directory contains a lot of hidden
subdirectories resulting in many gigabytes of usage.

For more information about the Fedora Prioritized Bugs process, see
https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/

Minutes and logs from the most recent meeting are at
https://meetbot.fedoraproject.org/teams/fedora_prioritized_bugs_and_issues/fedora_prioritized_bugs_and_issues.2022-01-12-16.00.html

--
Ben Cotton
He / Him / His
Fedora Program Manager
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

Re: Do I have a @fedoraproject.org e-mail address ?

2022-01-21 Thread Vít Ondruch



Dne 21. 01. 22 v 15:57 Alain Vigne napsal(a):

Thank you all
To conclude

  * I have a working @fedoraproject.org
 email alias
  * "external" people can reach me via this alias
  * I can't receive emails I sent to this alias from my gmail address
(which is my email address registered in Fedora Accounts)



Isn't it just the standard GMail deduplication?


Vít



  * I need to dig into
https://communityblog.fedoraproject.org/using-fedora-email-alias-gmail/

Best regards
Alain

On Fri, Jan 21, 2022 at 3:44 PM Luna Jernberg  
wrote:


Seems my test email worked

On Fri, Jan 21, 2022 at 3:18 PM Alain Vigne
 wrote:

Thank you, I did read this wiki page a long time ago, but was
not able to retrieve it :(

I remembered that it should work this way, so I sent a test
email to my fedora... address, and I was expecting to get it
in my gmail mailbox...  But it doesn't seem to work for me ?
Maybe an infinite loop ?

  * gmail sends to fedoraproject which forwards to gmail ?

My test e-mail doesn't land in my gmail spam either...

Could someone send me something at   avigne AT fedoraproject
org   please ?
Is there something wrong with me ?
TIA
Alain

On Fri, Jan 21, 2022 at 2:52 PM Ankur Sinha
 wrote:

On Fri, Jan 21, 2022 14:29:07 +0100, Alain Vigne wrote:
> Hi
> I am a Fedora packager [1] and I thought writing to
> my_...@fedoraproject.org
> would redirect to my registered e-mail address... It
seems not !?
> If yes, how to enter needed information to Thunderbird
client, for ex. ?
>
> I couldn't find documentation about this question. Thank
you for your
> explanations.

It is an e-mail alias, there's no mailbox attached to it.
It simply
redirects to whatever e-mail you've specified in FAS.

More information here:

https://fedoraproject.org/wiki/EmailAliases

-- 
Thanks,

Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure



-- 
Alain V.

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

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure



--
Alain V.

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


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

Re: Do I have a @fedoraproject.org e-mail address ?

2022-01-21 Thread arthur


On 21/01/2022 15:57, Alain Vigne wrote:

Thank you all
To conclude

  * I have a working @fedoraproject.org
 email alias
  * "external" people can reach me via this alias
  * I can't receive emails I sent to this alias from my gmail address
(which is my email address registered in Fedora Accounts)
  * I need to dig into
https://communityblog.fedoraproject.org/using-fedora-email-alias-gmail/

Best regards
Alain



Sometimes it takes a while (multiple minutes) to receive an email. It 
could also be that gmail drops the emails for some reason, but if you 
receive emails sent from a different address it should be fine.

I think you have all information now, good luck!

PS. Since I've noticed it several times in this thread, please don't top 
post.
Please read this wiki article: 
https://fedoraproject.org/wiki/Mailing_list_guidelines#Proper_posting_style


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

[Bug 2037655] Please branch and build perl-Pod-Coverage-Moose for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-4b4872597d has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4b4872597d


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

[Bug 2038143] Please branch and build perl-HTML-TableExtract for EPEL-9

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



--- Comment #2 from Paul Howarth  ---
(In reply to Gwyn Ciesla from comment #1)
> Missing dependency: DEBUG util.py:444:  No matching package to install:
> 'perl(HTML::ElementTable) >= 1.16'

perl-HTML-Element-Extended-1.18-21.el9 has now been built and is available in
the epel9 buildroot, which should resolve this issue.


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

[Bug 2037860] Please branch and build perl-HTML-Element-Extended for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-e9bfbe9c10 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e9bfbe9c10


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

[Bug 2031330] Please branch and build perl-HTTP-BrowserDetect in epel9