[Bug 1807857] please build perl-Sys-SigAction on EPEL8

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1807857



--- Comment #6 from Petr Pisar  ---
Andreas, you become a new maintainer. Do you plan to build this package for
EPEL 8? If you don't, you can grant me the access and I will build it.


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


[Bug 1896657] New: perl-Cache-FastMmap-1.51 is available

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1896657

Bug ID: 1896657
   Summary: perl-Cache-FastMmap-1.51 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Cache-FastMmap
  Keywords: FutureFeature, Triaged
  Assignee: jpazdzi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jpazdzi...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.51
Current version/release in rawhide: 1.50-1.fc34
URL: http://search.cpan.org/dist/Cache-FastMmap/

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


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


Re: python packaging and EPEL: the %py_provides macro

2020-11-10 Thread Mattia Verga via devel
Il 11/11/20 00:11, Miro Hrončok ha scritto:
> On 11/10/20 8:21 PM, Miro Hrončok wrote:
>> On 11/10/20 6:22 PM, Mattia Verga via devel wrote:
>>> Reading the python packaging guidelines [1] it says that "On releases
>>> older than Fedora 33 [...] it is necessary to use %py_provides".
>>>
>>> So I thought that %py_provides was necessary for EPEL7, but with that
>>> macro set, the build fails with "Unknown tag: %py_provides
>>> python3-calcephpy". In EPEL8 I get no errors and the build is completed.
>>>
>>> Said that, should I use the old method ("Provides: python3-pkg_resources
>>> = %{version}-%{release}") in EPEL7? Is it necessary?
>>>
>>> Mattia
>>>
>>> [1]
>>> https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_the_py_provides_macro
>>>
>> Hello. CCing the Python and EPEL lists.
>>
>> You are correct. I can backport the macro to EPEL 7 if it makes your spec 
>> files
>> easier:
>>
>> https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/26
> Upgrade: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b03303e77c
> Override: https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-7-29
>
Thx Miro!
___
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


wlroots 0.12 update with soname change

2020-11-10 Thread Aleksei Bavshin

Greetings,

I'm planning to push wlroots 0.12.0 update into rawhide next week.
As usual, the update is ABI breaking and will change soname (6 -> 7). 
This time no source changes required for any of the packages; simple 
rebuild with release bump would be sufficient.


I will send an additional message once I figure out how to set up a 
side-tag and get new wlroots build published into it.


Affected packages (maintainer aliases in Bcc):
 - cage
 - gamescope
 - phoc
 - sway
 - wayfire

--
With best regards,
Aleksei Bavshin



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


[389-devel] 389 DS nightly 2020-11-11 - 94% PASS

2020-11-10 Thread vashirov
https://fedorapeople.org/groups/389ds/ci/nightly/2020/11/11/report-389-ds-base-2.0.1-2020gitca8ac8e.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


[Bug 1890601] EPEL8 Request: perl-Test-Assert

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890601

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-cdc27a9f46 has been pushed to the Fedora EPEL 8 testing
repository.

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

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


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


Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

2020-11-10 Thread Tom Stellard

On 11/10/20 3:53 AM, Florian Weimer wrote:

* Tom Stellard:


On 11/9/20 1:48 PM, Florian Weimer wrote:

* Miro Hrončok:


On 11/9/20 7:05 PM, Tom Stellard wrote:

Thanks for clarifying.  So it does sound like gcc will need at
dependency on make.  If you do decide to use a weak dependency for this,
then I think I will need to update the proposal to BuildRequire:
make when gcc is used, so that we don't cause a performance
regression in the builds.


Well, we can add:

  Requires: (make if redhat-rpm-config)

To gcc.

Or
Requires: (make if gcc)
to redhat-rpm-config.  Given that the requirement actually comes
from
the -flto usage in redhat-rpm-config, that seems more reasonable to me.



This make sense, but does this work if redhat-rpm-config and gcc are
installed in separate transactions?


We already use

Requires: (annobin if gcc)

and that doesn't seem to cause any problems.



Ok, I've update the proposal to include this change.

-Tom


Thanks,
Florian


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


[Bug 1890922] Add perl-Module-Compile to EPEL8

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890922
Bug 1890922 depends on bug 1890925, which changed state.

Bug 1890925 Summary: Add perl-Test-Base to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1890925

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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


[Bug 1890795] EPEL8 Request: perl-PDL

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890795
Bug 1890795 depends on bug 1890922, which changed state.

Bug 1890922 Summary: Add perl-Module-Compile to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1890922

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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


[Bug 1890793] EPEL8 Request: perl-Devel-REPL

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890793
Bug 1890793 depends on bug 1890794, which changed state.

Bug 1890794 Summary: EPEL8 Request: perl-MooseX-Object-Pluggable
https://bugzilla.redhat.com/show_bug.cgi?id=1890794

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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


[Bug 1890938] Add perl-XXX to EPEL8

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890938
Bug 1890938 depends on bug 1890940, which changed state.

Bug 1890940 Summary: Add perl-JSON-Color to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1890940

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA




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


[Bug 1890586] EPEL8 Request: perl-AnyEvent-BDB

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890586

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-11-11 02:36:52



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


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


[Bug 1890894] Add perl-ExtUtils-F77 to EPEL8

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890894

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-ExtUtils-F77-1.24-4.el
   ||8
 Resolution|--- |ERRATA
Last Closed||2020-11-11 02:36:59



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


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


[Bug 1890794] EPEL8 Request: perl-MooseX-Object-Pluggable

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890794

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-11-11 02:36:49



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


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


[Bug 1890922] Add perl-Module-Compile to EPEL8

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890922

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Module-Compile-0.38-4.
   ||el8
 Resolution|--- |ERRATA
Last Closed||2020-11-11 02:37:01



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


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


[Bug 1890925] Add perl-Test-Base to EPEL8

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890925

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Test-Base-0.89-9.el8
 Resolution|--- |ERRATA
Last Closed||2020-11-11 02:36:56



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


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


[Bug 1890795] EPEL8 Request: perl-PDL

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890795
Bug 1890795 depends on bug 1890894, which changed state.

Bug 1890894 Summary: Add perl-ExtUtils-F77 to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1890894

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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


[Bug 1890935] Add perl-Inline-Files to EPEL8

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890935

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Inline-Files-0.71-6.el
   ||8
 Resolution|--- |ERRATA
Last Closed||2020-11-11 02:36:38



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


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


[Bug 1890938] Add perl-XXX to EPEL8

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890938
Bug 1890938 depends on bug 1890941, which changed state.

Bug 1890941 Summary: Add perl-YAML-PP to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1890941

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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


[Bug 1890918] Add perl-Convert-UU to EPEL8

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890918

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Convert-UU-0.5201-27.e
   ||l8
 Resolution|--- |ERRATA
Last Closed||2020-11-11 02:36:35



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


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


[Bug 1890795] EPEL8 Request: perl-PDL

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890795
Bug 1890795 depends on bug 1890918, which changed state.

Bug 1890918 Summary: Add perl-Convert-UU to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1890918

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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


[Bug 1890908] Add perl-Inline to EPEL8

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890908
Bug 1890908 depends on bug 1890935, which changed state.

Bug 1890935 Summary: Add perl-Inline-Files to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1890935

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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


Schedule for Wednesday's FESCo Meeting (2020-11-11)

2020-11-10 Thread David Cantrell

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-11-11 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

Move the FESCo meeting +1 hour (to 15:00 UTC) when DST is not in action
https://pagure.io/fesco/issue/2496
APPROVED (+6, 2, -0)

F35 System-Wide Change: Python 3.10
https://pagure.io/fesco/issue/2494
APPROVED (+8, 0, -0)

Nonresponsive maintainer: Mark Chappell (tremble)
https://pagure.io/fesco/issue/2492
APPROVED (+4, 0, -0)

Nonresponsive maintainer: Marek Cermak macermak
https://pagure.io/fesco/issue/2491
APPROVED (+3, 0, -0)

= New business =

#2495 Election Interview Questions — FESCo (Fedora 33)
https://pagure.io/fesco/issue/2495

#2475 proposal: let's develop the idea of a new repo for lightly-maintained 
packages
https://pagure.io/fesco/issue/2475

#2473 updates policy is out of date
https://pagure.io/fesco/issue/2473

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1894917] urxvt-unicode crashes while exit.

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1894917

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


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


[389-devel] Question on cloning and replication . . .

2020-11-10 Thread Matthew Harmsen

Everyone,

I received the following from a community member who is using Dogtag and 
389:


   I have 2 questions and 1 note.

   *Note:*
   Here is an interesting thing that I noticed during CA cloning:
   When CA to be cloned has secure connection DS enabled, cloning
   process fails.
   None of docs:

 * https://www.dogtagpki.org/wiki/PKI_10.5_Installing_CA_Clone
 * 
https://github.com/dogtagpki/pki/blob/DOGTAG_10_6_BRANCH/docs/installation/Installing_CA_Clone.md
 * 
https://github.com/dogtagpki/pki/blob/master/docs/installation/ca/Installing_CA_Clone.md

   is covering this issue.
   Solution here is to use
   pki_clone_replication_master_port=389
   pki_clone_replication_clone_port=389
   pki_clone_replication_security=None
   
https://github.com/dogtagpki/pki/blob/DOGTAG_10_5_BRANCH/base/server/etc/default.cfg#L255


   *Question 1 (sorry, bit long):*
   When CA is cloned both DS servers have *nsslapd-referral *attribute
   set in dn: *cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config* entries
   so DS on vm-users4.hostname.com 
   would have
   *dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config
   nsslapd-referral:
   ldap://vm-users3.hostname.com:389/o%3Dpki-tomcat-CA
   *
   and DS on vm-users3.hostname.com 
   *dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config
   nsslapd-referral:
   ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA
   *
   *I wonder what is the meaning of nsslapd-referral attribute?*
   **

   The reason I'm asking is that I was thinking that for replication
   over SSL maybe nsslapd-referral should be modified
   from *ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA
   *
   to *ldaps://vm-users4.hostname.com:636/o%3Dpki-tomcat-CA
   *
   but when I did this nsslapd-referral attribute was reverted to
   original value by DS automatically,
   *so I'm trying to make sure **if nsslapd-referral attribute should
   be left unchanged during enabling of SSL to DS replication?*

   Just in case here is a sample of all changes on both DS (hopefully,
   I didn't miss anything to have properly configured replication over
   SSL):
   vm-users4.hostname.com :
   
   dn: cn=config
   nsslapd-security: on

   dn: cn=RSA,cn=encryption,cn=config
   nsSSLPersonalitySSL: slapd-vm-users4
   nsSSLToken: internal (software)
   nsSSLActivation: on

   dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config
   nsslapd-referral:
   ldap://vm-users3.hostname.com:389/o%3Dpki-tomcat-CA
   

   dn:
   
cn=cloneAgreement1-vm-users4.hostname.com-pki-tomcat,cn=replica,cn=o\3Dpki-tomcat-CA,cn=mapping
   tree,cn=config
   nsDS5ReplicaPort: 636
   nsDS5ReplicaTransportInfo: SSL


   vm-users3.hostname.com :
   
   dn: cn=config
   nsslapd-security: on

   dn: cn=RSA,cn=encryption,cn=config
   nsSSLPersonalitySSL: slapd-vm-users3
   nsSSLToken: internal (software)
   nsSSLActivation: on

   dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config
   nsslapd-referral:
   ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA
   

   dn:
   
cn=masterAgreement1-vm-users4.hostname.com-pki-tomcat,cn=replica,cn=o\3Dpki-tomcat-CA,cn=mapping
   tree,cn=config
   nsDS5ReplicaPort: 636
   nsDS5ReplicaTransportInfo: SSL


   *Question 2:*
   DS has so called "SSF Restrictions"
   
(https://directory.fedoraproject.org/docs/389ds/howto/howto-use-ssf-restrictions.html}
   which may be configured by setting *nsslapd-minssf* attribute in
   *cn=config* entry.
   Default value of *nsslapd-minssf* attribute is 0. W
   Minimum SSF configuration setting can be used to define the minimum
   level of encryption that is required.

   *Do you know what this means?*
   **
   *Should I be concerned?*

   By the way, when is set *nsslapd-minssf* attribute to *128*, DS
   becomes inaccessible and CA is not working.

Thanks in advance for any answers,
-- Matt

P. S. - A copy of this email has also been sent to pki-de...@redhat.com.
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


[Bug 1894777] perl-File-Path-2.18 is available

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1894777

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-File-Path-2.18-1.fc34  |perl-File-Path-2.18-1.fc34
   ||perl-File-Path-2.18-1.fc33
 Resolution|--- |ERRATA
Last Closed||2020-11-11 01:20:10



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


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


[Bug 1893541] perl-ExtUtils-CBuilder-0.280235 is available

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1893541

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-ExtUtils-CBuilder-0.28
   ||0235-1.fc33
 Resolution|--- |ERRATA
Last Closed||2020-11-11 01:19:13



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


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


[Bug 1893495] perl-Pod-Markdown-3.300 is available

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1893495

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Pod-Markdown-3.300-1.f |perl-Pod-Markdown-3.300-1.f
   |c34 |c34
   ||perl-Pod-Markdown-3.300-1.f
   ||c33
 Resolution|--- |ERRATA
Last Closed||2020-11-11 01:19:00



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


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


Re: Help needed: vtk FTBFS, undefined reference to std::__detail::__to_chars_10_impl(char*, unsigned int, unsigned int)::__digits

2020-11-10 Thread Tom Stellard

On 11/10/20 7:17 PM, Sandro Mani wrote:


On 11.11.20 00:42, Tom Stellard wrote:

On 11/10/20 6:24 PM, Will Crawford wrote:



On Tue, 10 Nov 2020 at 11:56, Sandro Mani > wrote:


    /usr/bin/ld:
    CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLHyperTreeGridIO.cxx.o (symbol
    from plugin): undefined reference to symbol
'_ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits@@LLVM_11'
    /usr/bin/ld: /usr/lib64/libLLVM-11.so: error adding symbols: DSO
    missing
    from command line

...

    I'm not sure why ld thinks LLVM is involved, vtk does not pull in 
LLVM

    in any way.

    I'm pretty much clueless, any ideas?


That looks like the object file requires a symbol from libLLVM, and 
gcc isn't linking against it (hence the "DSO missing from command 
line" part).


If you have a log of the whole build you should be able to check how 
that object (the test) is being built; LLVM suggests maybe it was 
built using clang?




Compiling using clang wouldn't cause an object to link against 
libLLVM.so.  However, as Will said, we really need the whole log to

understand better what is happening.



Thanks for your replies. Here is the full log [1]. While clang/llvm are 
pulled into the buildroot as dependencies of other BRs, nothing else in 
the build log mentions either LLVM nor clang. Atteched below is the 
snipped related to building TestXMLHyperTreeGridIO.o. What I find 
particularly strange is the @@LLVM_11 decorated symbol, while nm on 
TestXMLHyperTreeGridIO.cxx.o gives me the undecorated symbol.




Can you try disabling LTO by adding:
%global _lto_cflags %{nil}
to your spec file and see if that helps.

-Tom


Thanks
Sandro

[1] http://smani.fedorapeople.org/tmp/builder-live.log

/usr/bin/g++
-DVTK_IN_VTK
-DvtkRenderingCore_AUTOINIT="2(vtkInteractionStyle,vtkRenderingOpenGL2)"
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/AMR
-I/builddir/build/BUILD/VTK-8.2.0/Filters/AMR
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/Core
-I/builddir/build/BUILD/VTK-8.2.0/Common/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/Utilities/KWIML
-I/builddir/build/BUILD/VTK-8.2.0/Utilities/KWIML
-I/builddir/build/BUILD/VTK-8.2.0/build/Utilities/KWSys
-I/builddir/build/BUILD/VTK-8.2.0/Utilities/KWSys
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/utf8
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/utf8
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/DataModel
-I/builddir/build/BUILD/VTK-8.2.0/Common/DataModel
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/Math
-I/builddir/build/BUILD/VTK-8.2.0/Common/Math
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/Misc
-I/builddir/build/BUILD/VTK-8.2.0/Common/Misc
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/System
-I/builddir/build/BUILD/VTK-8.2.0/Common/System
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/Transforms
-I/builddir/build/BUILD/VTK-8.2.0/Common/Transforms
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/ExecutionModel
-I/builddir/build/BUILD/VTK-8.2.0/Common/ExecutionModel
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/Core
-I/builddir/build/BUILD/VTK-8.2.0/Filters/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/IO/XML
-I/builddir/build/BUILD/VTK-8.2.0/IO/XML
-I/builddir/build/BUILD/VTK-8.2.0/build/IO/Core
-I/builddir/build/BUILD/VTK-8.2.0/IO/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/doubleconversion
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/doubleconversion
-I/usr/include/double-conversion
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/lz4
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/lz4
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/lzma
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/lzma
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/zlib
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/zlib
-I/builddir/build/BUILD/VTK-8.2.0/build/IO/XMLParser
-I/builddir/build/BUILD/VTK-8.2.0/IO/XMLParser
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/expat
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/expat
-I/builddir/build/BUILD/VTK-8.2.0/build/Parallel/Core
-I/builddir/build/BUILD/VTK-8.2.0/Parallel/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/IO/Legacy
-I/builddir/build/BUILD/VTK-8.2.0/IO/Legacy
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/HyperTree
-I/builddir/build/BUILD/VTK-8.2.0/Filters/HyperTree
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/General
-I/builddir/build/BUILD/VTK-8.2.0/Filters/General
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/ComputationalGeometry
-I/builddir/build/BUILD/VTK-8.2.0/Common/ComputationalGeometry
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/Sources
-I/builddir/build/BUILD/VTK-8.2.0/Filters/Sources
-I/builddir/build/BUILD/VTK-8.2.0/build/IO/ParallelXML
-I/builddir/build/BUILD/VTK-8.2.0/IO/ParallelXML
-I/builddir/build/BUILD/VTK-8.2.0/build/Imaging/Sources
-I/builddir/build/BUILD/VTK-8.2.0/Imaging/Sources
-I/builddir/build/BUILD/VTK-8.2.0/build/Imaging/Core
-I/builddir/build/BUILD/VTK-8.2.0/Imaging/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/Infovis/Core

Re: Help needed: vtk FTBFS, undefined reference to std::__detail::__to_chars_10_impl(char*, unsigned int, unsigned int)::__digits

2020-11-10 Thread Sandro Mani


On 11.11.20 00:42, Tom Stellard wrote:

On 11/10/20 6:24 PM, Will Crawford wrote:



On Tue, 10 Nov 2020 at 11:56, Sandro Mani > wrote:


    /usr/bin/ld:
    CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLHyperTreeGridIO.cxx.o (symbol
    from plugin): undefined reference to symbol
'_ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits@@LLVM_11'
    /usr/bin/ld: /usr/lib64/libLLVM-11.so: error adding symbols: DSO
    missing
    from command line

...

    I'm not sure why ld thinks LLVM is involved, vtk does not pull in 
LLVM

    in any way.

    I'm pretty much clueless, any ideas?


That looks like the object file requires a symbol from libLLVM, and 
gcc isn't linking against it (hence the "DSO missing from command 
line" part).


If you have a log of the whole build you should be able to check how 
that object (the test) is being built; LLVM suggests maybe it was 
built using clang?




Compiling using clang wouldn't cause an object to link against 
libLLVM.so.  However, as Will said, we really need the whole log to

understand better what is happening.



Thanks for your replies. Here is the full log [1]. While clang/llvm are 
pulled into the buildroot as dependencies of other BRs, nothing else in 
the build log mentions either LLVM nor clang. Atteched below is the 
snipped related to building TestXMLHyperTreeGridIO.o. What I find 
particularly strange is the @@LLVM_11 decorated symbol, while nm on 
TestXMLHyperTreeGridIO.cxx.o gives me the undecorated symbol.


Thanks
Sandro

[1] http://smani.fedorapeople.org/tmp/builder-live.log

/usr/bin/g++
-DVTK_IN_VTK
-DvtkRenderingCore_AUTOINIT="2(vtkInteractionStyle,vtkRenderingOpenGL2)"
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/AMR
-I/builddir/build/BUILD/VTK-8.2.0/Filters/AMR
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/Core
-I/builddir/build/BUILD/VTK-8.2.0/Common/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/Utilities/KWIML
-I/builddir/build/BUILD/VTK-8.2.0/Utilities/KWIML
-I/builddir/build/BUILD/VTK-8.2.0/build/Utilities/KWSys
-I/builddir/build/BUILD/VTK-8.2.0/Utilities/KWSys
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/utf8
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/utf8
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/DataModel
-I/builddir/build/BUILD/VTK-8.2.0/Common/DataModel
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/Math
-I/builddir/build/BUILD/VTK-8.2.0/Common/Math
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/Misc
-I/builddir/build/BUILD/VTK-8.2.0/Common/Misc
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/System
-I/builddir/build/BUILD/VTK-8.2.0/Common/System
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/Transforms
-I/builddir/build/BUILD/VTK-8.2.0/Common/Transforms
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/ExecutionModel
-I/builddir/build/BUILD/VTK-8.2.0/Common/ExecutionModel
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/Core
-I/builddir/build/BUILD/VTK-8.2.0/Filters/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/IO/XML
-I/builddir/build/BUILD/VTK-8.2.0/IO/XML
-I/builddir/build/BUILD/VTK-8.2.0/build/IO/Core
-I/builddir/build/BUILD/VTK-8.2.0/IO/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/doubleconversion
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/doubleconversion
-I/usr/include/double-conversion
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/lz4
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/lz4
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/lzma
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/lzma
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/zlib
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/zlib
-I/builddir/build/BUILD/VTK-8.2.0/build/IO/XMLParser
-I/builddir/build/BUILD/VTK-8.2.0/IO/XMLParser
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/expat
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/expat
-I/builddir/build/BUILD/VTK-8.2.0/build/Parallel/Core
-I/builddir/build/BUILD/VTK-8.2.0/Parallel/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/IO/Legacy
-I/builddir/build/BUILD/VTK-8.2.0/IO/Legacy
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/HyperTree
-I/builddir/build/BUILD/VTK-8.2.0/Filters/HyperTree
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/General
-I/builddir/build/BUILD/VTK-8.2.0/Filters/General
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/ComputationalGeometry
-I/builddir/build/BUILD/VTK-8.2.0/Common/ComputationalGeometry
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/Sources
-I/builddir/build/BUILD/VTK-8.2.0/Filters/Sources
-I/builddir/build/BUILD/VTK-8.2.0/build/IO/ParallelXML
-I/builddir/build/BUILD/VTK-8.2.0/IO/ParallelXML
-I/builddir/build/BUILD/VTK-8.2.0/build/Imaging/Sources
-I/builddir/build/BUILD/VTK-8.2.0/Imaging/Sources
-I/builddir/build/BUILD/VTK-8.2.0/build/Imaging/Core
-I/builddir/build/BUILD/VTK-8.2.0/Imaging/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/Infovis/Core
-I/builddir/build/BUILD/VTK-8.2.0/Infovis/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/Extraction
-I/builddir/build/BUILD/VTK-8.2.0/Filters/Extraction

Re: Help needed: vtk FTBFS, undefined reference to std::__detail::__to_chars_10_impl(char*, unsigned int, unsigned int)::__digits

2020-11-10 Thread Tom Stellard

On 11/10/20 6:24 PM, Will Crawford wrote:



On Tue, 10 Nov 2020 at 11:56, Sandro Mani > wrote:


/usr/bin/ld:
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLHyperTreeGridIO.cxx.o (symbol
from plugin): undefined reference to symbol
'_ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits@@LLVM_11'
/usr/bin/ld: /usr/lib64/libLLVM-11.so: error adding symbols: DSO
missing
from command line

...

I'm not sure why ld thinks LLVM is involved, vtk does not pull in LLVM
in any way.

I'm pretty much clueless, any ideas?


That looks like the object file requires a symbol from libLLVM, and gcc 
isn't linking against it (hence the "DSO missing from command line" part).


If you have a log of the whole build you should be able to check how 
that object (the test) is being built; LLVM suggests maybe it was built 
using clang?




Compiling using clang wouldn't cause an object to link against 
libLLVM.so.  However, as Will said, we really need the whole log to

understand better what is happening.

-Tom



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


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


Re: Help needed: vtk FTBFS, undefined reference to std::__detail::__to_chars_10_impl(char*, unsigned int, unsigned int)::__digits

2020-11-10 Thread Will Crawford
On Tue, 10 Nov 2020 at 11:56, Sandro Mani  wrote:

/usr/bin/ld:
> CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLHyperTreeGridIO.cxx.o (symbol
> from plugin): undefined reference to symbol
> '_ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits@@LLVM_11'
> /usr/bin/ld: /usr/lib64/libLLVM-11.so: error adding symbols: DSO missing
> from command line
>
...

> I'm not sure why ld thinks LLVM is involved, vtk does not pull in LLVM
> in any way.
>
> I'm pretty much clueless, any ideas?
>

That looks like the object file requires a symbol from libLLVM, and gcc
isn't linking against it (hence the "DSO missing from command line" part).

If you have a log of the whole build you should be able to check how that
object (the test) is being built; LLVM suggests maybe it was built using
clang?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: python packaging and EPEL: the %py_provides macro

2020-11-10 Thread Miro Hrončok

On 11/10/20 8:21 PM, Miro Hrončok wrote:

On 11/10/20 6:22 PM, Mattia Verga via devel wrote:

Reading the python packaging guidelines [1] it says that "On releases
older than Fedora 33 [...] it is necessary to use %py_provides".

So I thought that %py_provides was necessary for EPEL7, but with that
macro set, the build fails with "Unknown tag: %py_provides
python3-calcephpy". In EPEL8 I get no errors and the build is completed.

Said that, should I use the old method ("Provides: python3-pkg_resources
= %{version}-%{release}") in EPEL7? Is it necessary?

Mattia

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



Hello. CCing the Python and EPEL lists.

You are correct. I can backport the macro to EPEL 7 if it makes your spec files 
easier:


https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/26


Upgrade: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b03303e77c
Override: https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-7-29

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


Re: python packaging and EPEL: the %py_provides macro

2020-11-10 Thread Miro Hrončok

On 11/10/20 8:21 PM, Miro Hrončok wrote:

On 11/10/20 6:22 PM, Mattia Verga via devel wrote:

Reading the python packaging guidelines [1] it says that "On releases
older than Fedora 33 [...] it is necessary to use %py_provides".

So I thought that %py_provides was necessary for EPEL7, but with that
macro set, the build fails with "Unknown tag: %py_provides
python3-calcephpy". In EPEL8 I get no errors and the build is completed.

Said that, should I use the old method ("Provides: python3-pkg_resources
= %{version}-%{release}") in EPEL7? Is it necessary?

Mattia

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



Hello. CCing the Python and EPEL lists.

You are correct. I can backport the macro to EPEL 7 if it makes your spec files 
easier:


https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/26


Upgrade: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b03303e77c
Override: https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-7-29

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


Re: python packaging and EPEL: the %py_provides macro

2020-11-10 Thread Miro Hrončok

On 11/10/20 8:21 PM, Miro Hrončok wrote:

On 11/10/20 6:22 PM, Mattia Verga via devel wrote:

Reading the python packaging guidelines [1] it says that "On releases
older than Fedora 33 [...] it is necessary to use %py_provides".

So I thought that %py_provides was necessary for EPEL7, but with that
macro set, the build fails with "Unknown tag: %py_provides
python3-calcephpy". In EPEL8 I get no errors and the build is completed.

Said that, should I use the old method ("Provides: python3-pkg_resources
= %{version}-%{release}") in EPEL7? Is it necessary?

Mattia

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



Hello. CCing the Python and EPEL lists.

You are correct. I can backport the macro to EPEL 7 if it makes your spec files 
easier:


https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/26


Upgrade: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b03303e77c
Override: https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-7-29

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


Re: qemu & LTO

2020-11-10 Thread Jeff Law

On 11/5/20 8:24 AM, Richard W.M. Jones wrote:
> We discovered a few days ago that LTO broke qemu on aarch64.
>
> The original bug reported was:
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=1893892
>
> But actually looking at the build.log[1] we see another assertion
> failure in the test suite.  (Unfortunately although we run the test
> suite, the spec file was ignoring the result so the broken build
> escaped into Rawhide.)
>
> Because qemu is a complicated piece of software we're not clear if the
> bugs found are general bugs in LTO, bugs which are specific to LTO on
> aarch64, or bugs in qemu which are exposed by optimizations made
> possible by LTO.
>
> One thing we do suspect is that this could be the tip of the iceberg
> since the qemu test suite only tests a tiny fraction of the code.
>
> LTO has been disabled across all arches for now.  See the list of
> latest commits that Dan has added:
>
> https://src.fedoraproject.org/rpms/qemu/commits/master

Right.  And it's on my list to investigate (probably sometime in early
2021 given other pressing commitments).  FWIW, there's ~150 LTO opt-outs
on that list to investigate.  While I don't think we need to fix &
enable everything, I do want to thoroughly *understand* every issue and
get appropriate bugs filed.  FWIW, I have a Fedora spec file scanner
which notes all the opted-out packages so I know what needs investigation.


What I've typically seen for execution/testsuite failures have mostly
been package issues, not LTO issues.  Probably the biggest thing is that
LTO can inline across translation units.  So things like poorly written
ASMs that under-specified their dataflow suddenly get inlined and that
under-specification becomes critically important.  The other thing I've
seen a few times is ordering of static constructors for C++ -- LTO
can/will change that and code which relies on specific ordering (which
isn't defined) can fail.   On the LTO side, symbol visibility has been
the biggest headache and they can be insanely hard to track down.

I expect at least some of the opt outs, particularly the target
dependent ones are actually latent codegen issues that LTO happens to
expose, but aren't issues in LTO itself.

There's little doubt we'll find more issues as we work through the
opt-outs.  But that's also why we pushed so hard to get the vast
majority of things up with LTO in F33.  Soak time in Fedora is critical
in my mind.


jeff




.  LTO can change the ordering of static constructors for C++, or
aggressively inline across translation units exposing things like poorly
written asms.  We've seen a small number of (insanely annoying) issues
with symbol visibility in the LTO path itself.



I thought we had LTO disabled for QEMU until I could sit down and dig
into it?!?


jeff

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


[Bug 1890601] EPEL8 Request: perl-Test-Assert

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890601

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


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


Re: python packaging and EPEL: the %py_provides macro

2020-11-10 Thread Miro Hrončok

On 11/10/20 6:22 PM, Mattia Verga via devel wrote:

Reading the python packaging guidelines [1] it says that "On releases
older than Fedora 33 [...] it is necessary to use %py_provides".

So I thought that %py_provides was necessary for EPEL7, but with that
macro set, the build fails with "Unknown tag: %py_provides
python3-calcephpy". In EPEL8 I get no errors and the build is completed.

Said that, should I use the old method ("Provides: python3-pkg_resources
= %{version}-%{release}") in EPEL7? Is it necessary?

Mattia

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


Hello. CCing the Python and EPEL lists.

You are correct. I can backport the macro to EPEL 7 if it makes your spec files 
easier:


https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/26

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


[EPEL-devel] Re: python packaging and EPEL: the %py_provides macro

2020-11-10 Thread Miro Hrončok

On 11/10/20 6:22 PM, Mattia Verga via devel wrote:

Reading the python packaging guidelines [1] it says that "On releases
older than Fedora 33 [...] it is necessary to use %py_provides".

So I thought that %py_provides was necessary for EPEL7, but with that
macro set, the build fails with "Unknown tag: %py_provides
python3-calcephpy". In EPEL8 I get no errors and the build is completed.

Said that, should I use the old method ("Provides: python3-pkg_resources
= %{version}-%{release}") in EPEL7? Is it necessary?

Mattia

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


Hello. CCing the Python and EPEL lists.

You are correct. I can backport the macro to EPEL 7 if it makes your spec files 
easier:


https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/26

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


Re: python packaging and EPEL: the %py_provides macro

2020-11-10 Thread Miro Hrončok

On 11/10/20 6:22 PM, Mattia Verga via devel wrote:

Reading the python packaging guidelines [1] it says that "On releases
older than Fedora 33 [...] it is necessary to use %py_provides".

So I thought that %py_provides was necessary for EPEL7, but with that
macro set, the build fails with "Unknown tag: %py_provides
python3-calcephpy". In EPEL8 I get no errors and the build is completed.

Said that, should I use the old method ("Provides: python3-pkg_resources
= %{version}-%{release}") in EPEL7? Is it necessary?

Mattia

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


Hello. CCing the Python and EPEL lists.

You are correct. I can backport the macro to EPEL 7 if it makes your spec files 
easier:


https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/26

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


Re: Query: What to do for multiple module builds in bodhi for 'jmc' in F33?

2020-11-10 Thread Mohan Boddu
On Tue, Nov 10, 2020 at 9:42 AM Petr Pisar  wrote:
>
> On Mon, Nov 09, 2020 at 10:35:45PM -0500, Jie Kang wrote:
> > Thank you. There is a second stream for jmc in that update:
> > jmc-latest-3320200902194158.601d93de
> >
> > Can it be removed as well?
> >
> I removed it from that update. You should be able to submit a new update with
> jmc:latest:3320201104214853 now.

Thanks Petr

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


Re: Help needed: vtk FTBFS, undefined reference to std::__detail::__to_chars_10_impl(char*, unsigned int, unsigned int)::__digits

2020-11-10 Thread John Reiser

/usr/lib64/ccache/g++ \

   [[snip]]

One more level of expansion of command lines can be obtained by using the '-v' 
parameter:
   g++ -v ...
and a final level by adding -v to collect2, then re-running collect2.  The 
collect2 command
is revealed by "g++ -v".

Also look at the transitive closure of all the [DT_]NEEDED entries in the 
Dynamic section.
Something like:
   for lib in $(find ... -name 'lib*.so*'); do  # every shared library that the 
build uses
  echo $lib
  readelf --dynamic $lib  |  grep NEEDED
   done

If some build succeeds, then "ldd vtkIOXMLCxxTests" gives another list of 
shared libraries.
___
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


python packaging and EPEL: the %py_provides macro

2020-11-10 Thread Mattia Verga via devel
Reading the python packaging guidelines [1] it says that "On releases 
older than Fedora 33 [...] it is necessary to use %py_provides".

So I thought that %py_provides was necessary for EPEL7, but with that 
macro set, the build fails with "Unknown tag: %py_provides 
python3-calcephpy". In EPEL8 I get no errors and the build is completed.

Said that, should I use the old method ("Provides: python3-pkg_resources 
= %{version}-%{release}") in EPEL7? Is it necessary?

Mattia

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

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


[Bug 1894917] urxvt-unicode crashes while exit.

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1894917

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



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


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


[389-devel] Please review: PR 2054 - Do not add referrals for masters with different data generation

2020-11-10 Thread Pierre Rogier
https://github.com/389ds/389-ds-base/pull/4427

-- 
--

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


[Bug 1894917] urxvt-unicode crashes while exit.

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1894917



--- Comment #5 from Robbie Harwood  ---
Thanks Petr.  Apologies for the noise.


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


[Bug 1896471] New: perl-WWW-Mechanize-2.03 is available

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1896471

Bug ID: 1896471
   Summary: perl-WWW-Mechanize-2.03 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-WWW-Mechanize
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, jose.p.oliveira@gmail.com,
ktdre...@ktdreyer.com,
perl-devel@lists.fedoraproject.org,
xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.03
Current version/release in rawhide: 2.02-1.fc34
URL: http://search.cpan.org/dist/WWW-Mechanize/

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


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


Re: Query: What to do for multiple module builds in bodhi for 'jmc' in F33?

2020-11-10 Thread Jie Kang
Thank you Mohan and Petr!

On Tue, Nov 10, 2020 at 9:44 AM Petr Pisar  wrote:
>
> On Mon, Nov 09, 2020 at 10:35:45PM -0500, Jie Kang wrote:
> > Thank you. There is a second stream for jmc in that update:
> > jmc-latest-3320200902194158.601d93de
> >
> > Can it be removed as well?
> >
> I removed it from that update. You should be able to submit a new update with
> jmc:latest:3320201104214853 now.
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Query: What to do for multiple module builds in bodhi for 'jmc' in F33?

2020-11-10 Thread Petr Pisar
On Mon, Nov 09, 2020 at 10:35:45PM -0500, Jie Kang wrote:
> Thank you. There is a second stream for jmc in that update:
> jmc-latest-3320200902194158.601d93de
> 
> Can it be removed as well?
> 
I removed it from that update. You should be able to submit a new update with
jmc:latest:3320201104214853 now.

-- Petr


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


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

2020-11-10 Thread Fedora compose checker
Missing expected images:

Xfce raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 6/177 (x86_64), 16/115 (aarch64)

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

ID: 719599  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/719599
ID: 719601  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/719601
ID: 719649  Test: aarch64 Minimal-raw_xz-raw.xz base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/719649
ID: 719655  Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/719655
ID: 719662  Test: aarch64 Server-dvd-iso install_updates_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/719662
ID: 719664  Test: aarch64 Server-dvd-iso 
install_repository_nfs_variation@uefi
URL: https://openqa.fedoraproject.org/tests/719664
ID: 719670  Test: aarch64 Server-dvd-iso 
install_repository_nfs_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/719670
ID: 719678  Test: aarch64 Server-dvd-iso 
install_repository_nfsiso_variation@uefi
URL: https://openqa.fedoraproject.org/tests/719678
ID: 719689  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/719689
ID: 719819  Test: aarch64 universal install_anaconda_text@uefi
URL: https://openqa.fedoraproject.org/tests/719819

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

ID: 719611  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/719611
ID: 719619  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/719619
ID: 719621  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/719621
ID: 719741  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/719741
ID: 719796  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/719796
ID: 719808  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/719808
ID: 719821  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/719821
ID: 719825  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/719825
ID: 719837  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/719837
ID: 719838  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/719838
ID: 719839  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/719839
ID: 719840  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/719840

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

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

ID: 719547  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/719547
ID: 719579  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/719579
ID: 719592  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/719592

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

ID: 719593  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/719593
ID: 719643  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/719643
ID: 719711  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/719711
ID: 719720  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/719720

Passed openQA tests: 165/177 (x86_64), 91/115 (aarch64)

New passes (same test not passed in Fedora-Rawhide-20201109.n.0):

ID: 719548  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/719548
ID: 719556  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/719556
ID: 719562  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/719562
ID: 719618  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/719618
ID: 719686  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/719686
ID: 719795  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/719795
ID: 719803   

Boot/Install from iso file

2020-11-10 Thread Sergio Belkin
Hi!
I have the following /etc/grub.d/40_custom file:
#!/usr/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type
the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry "Start Fedora-KDE-Live 33" --class fedora {
 set isofile="/Fedora-KDE-Live-x86_64-33-1.2.iso"
 loopback loop (lvm/fedora-home)/sergio/Descargas/Distros$isofile
 linuxefi (loop)/isolinux/vmlinuz iso-scan/filename=${isofile}
root=live:CDLABEL=Fedora-KDE-Live-33-1-2  rd.live.image
 initrdefi (loop)/isolinux/initrd.img
 }
EOF


I have used that configuration a few years ago, but now it does not work.
If I choose that grub entry the screen goes black and I have to reboot. Is
there something wrong in my custom file?

Thanks in  advance!

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


Fedora rawhide compose report: 20201110.n.0 changes

2020-11-10 Thread Fedora Rawhide Report
OLD: Fedora-Rawhide-20201109.n.0
NEW: Fedora-Rawhide-20201110.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  43
Dropped packages:2
Upgraded packages:   160
Downgraded packages: 0

Size of added packages:  107.78 MiB
Size of dropped packages:8.85 MiB
Size of upgraded packages:   4.71 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20201110.n.0.ppc64le.tar.xz
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20201110.n.0.ppc64le.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: anope-2.0.9-2.fc34
Summary: IRC services designed for flexibility and ease of use
RPMs:anope anope-gnutls anope-ldap anope-mysql anope-openssl anope-pcre 
anope-sqlite anope-tre
Size:19.08 MiB

Package: apache-cloudstack-cloudmonkey-6.1.0-1.fc34
Summary: Apache Cloudstack Cloudmonkey
RPMs:apache-cloudstack-cloudmonkey 
golang-github-apache-cloudstack-cloudmonkey-devel
Size:10.73 MiB

Package: calceph-3.4.7-2.fc34
Summary: Astronomical library to access planetary ephemeris files
RPMs:calceph calceph-devel calceph-doc calceph-fortran-devel calceph-libs
Size:22.30 MiB

Package: callaudiod-0.0.4-1.fc34
Summary: Daemon for dealing with audio routing during phone calls
RPMs:callaudiod callaudiod-devel
Size:518.40 KiB

Package: epson-inkjet-printer-escpr2-1.1.24-1.1lsb3.2.fc34
Summary: Drivers for Epson inkjet printers
RPMs:epson-inkjet-printer-escpr2
Size:1.86 MiB

Package: gamescope-3.7-1.fc34
Summary: Micro-compositor for video games on Wayland
RPMs:gamescope
Size:357.92 KiB

Package: golang-github-facebookincubator-flog-0-0.1.20201109gitd2511d0.fc34
Summary: A Go library for logging
RPMs:golang-github-facebookincubator-flog-devel
Size:28.89 KiB

Package: golang-github-facebookincubator-ntp-0-0.1.20201109git143e098.fc34
Summary: Facebook's NTP libraries
RPMs:golang-github-facebookincubator-ntp-devel leaphash ntpcheck responder
Size:22.79 MiB

Package: golang-github-fvbommel-sortorder-1.0.2-1.fc34
Summary: Sort orders and comparison functions
RPMs:golang-github-fvbommel-sortorder-devel
Size:11.92 KiB

Package: golang-github-hugelgupf-socketpair-0-0.1.20201109git05d35a9.fc34
Summary: Go library that provides bidirectionally connected Conns
RPMs:golang-github-hugelgupf-socketpair-devel
Size:11.51 KiB

Package: golang-github-kelvins-sunrisesunset-1.0-1.fc34
Summary: Go package that provides the sunrise and sunset equation
RPMs:golang-github-kelvins-sunrisesunset-devel
Size:14.82 KiB

Package: golang-github-moby-locker-1.0.1-1.fc34
Summary: Go library for locking
RPMs:golang-github-moby-locker-devel
Size:14.51 KiB

Package: golang-github-moby-term-0-0.1.20201109git7f0af18.fc34
Summary: Go utilities for dealing with terminals
RPMs:golang-github-moby-term-devel
Size:23.26 KiB

Package: golang-github-openapi-inflect-0.19.0-1.fc34
Summary: Go library to perform word transformations
RPMs:golang-github-openapi-inflect-devel
Size:17.32 KiB

Package: golang-github-tonistiigi-rosetta-0-0.2.20201109git9ba8546.fc34
Summary: Go utility to detect Rosetta environment
RPMs:golang-github-tonistiigi-rosetta-devel
Size:10.37 KiB

Package: golang-github-xo-terminfo-0-0.1.20201109git454e5b6.fc34
Summary: A terminfo package in pure go
RPMs:golang-github-xo-terminfo golang-github-xo-terminfo-devel
Size:3.30 MiB

Package: kde-style-breeze-1:5.18.5-2.fc34
Summary: KDE 4 version of Plasma 5 artwork, style and assets
RPMs:kde-style-breeze
Size:1.21 MiB

Package: libjwt-1.12.1-3.fc34
Summary: A Javascript Web Token library in C
RPMs:libjwt libjwt-devel
Size:302.83 KiB

Package: mingw-python-OWSLib-0.20.0-1.fc34
Summary: MinGW Windows Python OWSLib library
RPMs:mingw32-python3-OWSLib mingw64-python3-OWSLib
Size:621.86 KiB

Package: mingw-python-affine-2.3.0-3.fc34
Summary: MinGW Windows Python affine
RPMs:mingw32-python3-affine mingw64-python3-affine
Size:67.15 KiB

Package: mingw-python-chardet-3.0.4-3.fc34
Summary: MinGW Windows Python chardet
RPMs:mingw32-python3-chardet mingw64-python3-chardet
Size:384.42 KiB

Package: mingw-python-idna-2.10-1.fc34
Summary: MinGW Windows Python idna
RPMs:mingw32-python3-idna mingw64-python3-idna
Size:193.09 KiB

Package: mingw-python-lxml-4.5.1-1.fc34
Summary: MinGW Windows Python lxml library
RPMs:mingw32-python3-lxml mingw64-python3-lxml
Size:2.25 MiB

Package: mingw-python-markupsafe-1.1.1-3.fc34
Summary: MinGW Windows Python markupsafe library
RPMs:mingw32-python3-markupsafe mingw64-python3-markupsafe
Size:65.54 KiB

Package: mingw-python-pygments-2.7.1-1.fc34
Summary: MinGW Windows Python pygments

Re: Help needed: vtk FTBFS, undefined reference to std::__detail::__to_chars_10_impl(char*, unsigned int, unsigned int)::__digits

2020-11-10 Thread Sandro Mani


On 10.11.20 12:56, Sandro Mani wrote:

Hi

I'm stuck at rebuilding vtk, which I need to move ahead with the proj 
rebuilds. (The error being unrelated to proj.) I get


/usr/bin/ld: 
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLHyperTreeGridIO.cxx.o (symbol 
from plugin): undefined reference to symbol 
'_ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits@@LLVM_11'
/usr/bin/ld: /usr/lib64/libLLVM-11.so: error adding symbols: DSO 
missing from command line


Now, nm tells me

$ nm TestXMLHyperTreeGridIO.cxx.o  | grep 
_ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits

 W _ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits

resp, unmangled the symbol is

std::__detail::__to_chars_10_impl(char*, unsigned int, 
unsigned int)::__digits


I'm not sure why ld thinks LLVM is involved, vtk does not pull in LLVM 
in any way.


I'm pretty much clueless, any ideas?


I could add the command line which leads to this error (exploded for 
readability):


/usr/lib64/ccache/g++
-O2
-flto=auto
-ffat-lto-objects
-fexceptions
-g
-grecord-gcc-switches
-pipe
-Wall
-Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-m64
-mtune=generic
-fasynchronous-unwind-tables
-fstack-clash-protection
-fcf-protection
-D_UNICODE
-DHAVE_UINTPTR_T
-g
-Wl,-lc
-Wl,-lc
-Wl,-z,relro
-Wl,--as-needed
-Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
CMakeFiles/vtkIOXMLCxxTests.dir/vtkIOXMLCxxTests.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestAMRXMLIO.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestDataObjectXMLIO.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestMultiBlockXMLIOWithPartialArrays.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestReadDuplicateDataArrayNames.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestXML.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLGhostCellsImport.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLHierarchicalBoxDataFileConverter.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLHyperTreeGridIO.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLMappedUnstructuredGridIO.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLToString.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLUnstructuredGridReader.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLWriterWithDataArrayFallback.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLWriteRead.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLCompositeDataReaderDistribution.cxx.o
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLReaderBadData.cxx.o
-o ../../../../bin/vtkIOXMLCxxTests
-L/usr/lib/jvm/java/lib/server
-Wl,-rpath,/usr/lib/jvm/java/lib/server:/home/sandro/rpmbuild/BUILD/VTK-8.2.0/build/lib
../../../../lib/libvtkFiltersAMR.so.1
/usr/lib64/libdouble-conversion.so
/usr/lib64/liblz4.so
/usr/lib64/liblzma.so
/usr/lib64/libz.so
/usr/lib64/libexpat.so
../../../../lib/libvtkFiltersHyperTree.so.1
../../../../lib/libvtkIOParallelXML.so.1
../../../../lib/libvtkImagingSources.so.1
../../../../lib/libvtkInfovisCore.so.1
../../../../lib/libvtkInteractionStyle.so.1
../../../../lib/libvtkRenderingOpenGL2.so.1
/usr/lib64/libGLEW.so
../../../../lib/libvtkTestingRendering.so.1
../../../../lib/libvtkIOImage.so.1
../../../../lib/libvtkDICOMParser.so.1
../../../../lib/libvtkmetaio.so.1
/usr/lib64/libjpeg.so
/usr/lib64/libpng.so
/usr/lib64/libtiff.so
../../../../lib/libvtkIOXML.so.1
../../../../lib/libvtkIOXMLParser.so.1
../../../../lib/libvtkParallelCore.so.1
../../../../lib/libvtkIOLegacy.so.1
../../../../lib/libvtkIOCore.so.1
../../../../lib/libvtkFiltersExtraction.so.1
../../../../lib/libvtkFiltersStatistics.so.1
../../../../lib/libvtkImagingFourier.so.1
/usr/lib64/libSM.so
/usr/lib64/libICE.so
/usr/lib64/libX11.so
/usr/lib64/libXext.so
/usr/lib64/libXt.so
../../../../lib/libvtkImagingCore.so.1
../../../../lib/libvtkRenderingCore.so.1
../../../../lib/libvtkFiltersSources.so.1
../../../../lib/libvtkFiltersGeneral.so.1
../../../../lib/libvtkCommonComputationalGeometry.so.1
../../../../lib/libvtkCommonColor.so.1
../../../../lib/libvtkFiltersGeometry.so.1
../../../../lib/libvtkFiltersCore.so.1
../../../../lib/libvtkCommonExecutionModel.so.1
../../../../lib/libvtkCommonDataModel.so.1
../../../../lib/libvtkCommonTransforms.so.1
../../../../lib/libvtkCommonMisc.so.1
../../../../lib/libvtkCommonMath.so.1
../../../../lib/libvtkCommonSystem.so.1
../../../../lib/libvtkCommonCore.so.1
../../../../lib/libvtksys.so.1
-ldl
/usr/lib64/libz.so
___
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


quota-4.06 license change

2020-11-10 Thread Petr Pisar
Upstream relicensed and dropped an old BSD code in 4.06 release. Hence the
RPM package changes license from "BSD and LGPLv2+ and GPLv2 and GPLv2+"
to "LGPLv2+ and GPLv2 and GPLv2+".

-- Petr


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


Help needed: vtk FTBFS, undefined reference to std::__detail::__to_chars_10_impl(char*, unsigned int, unsigned int)::__digits

2020-11-10 Thread Sandro Mani

Hi

I'm stuck at rebuilding vtk, which I need to move ahead with the proj 
rebuilds. (The error being unrelated to proj.) I get


/usr/bin/ld: 
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLHyperTreeGridIO.cxx.o (symbol 
from plugin): undefined reference to symbol 
'_ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits@@LLVM_11'
/usr/bin/ld: /usr/lib64/libLLVM-11.so: error adding symbols: DSO missing 
from command line


Now, nm tells me

$ nm TestXMLHyperTreeGridIO.cxx.o  | grep 
_ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits

 W _ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits

resp, unmangled the symbol is

std::__detail::__to_chars_10_impl(char*, unsigned int, 
unsigned int)::__digits


I'm not sure why ld thinks LLVM is involved, vtk does not pull in LLVM 
in any way.


I'm pretty much clueless, any ideas?

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


Re: Self Introduction: Timothée Ravier (Siosm)

2020-11-10 Thread Silvia Sánchez
Hello!

Welcome and thank you!  Did anyone answer to you to help you with this?

Cheers,
Lailah




On Fri, 6 Nov 2020 at 12:41, Timothée Ravier 
wrote:

> Hi everyone! 
>
> I am Timothée Ravier and I am a Linux system and security engineer
> interested in safe programming languages and container focused operating
> systems.
> I am currently a Red Hat and Fedora CoreOS engineer.
> I maintain an unofficial project nicknamed Kinoite [1] that provide
> variants based on the KDE, XFCE, LXQt, Deepin, Mate and Pantheon desktop
> environments for Fedora Silverblue.
> To help Silverblue systems run applications in Flatpaks, I am working on
> packaging as many KDE applications as possible in Flatpaks for Flathub and
> hopefully in Fedora soon.
> I am working on translating the Fedora CoreOS, Silverblue and Flatpak docs
> in French.
>
> Regarding packaging, I am applying for co-maintainer-ship of the following
> packages:
>   - https://src.fedoraproject.org/rpms/ostree
>   - https://src.fedoraproject.org/rpms/rpm-ostree
>   - https://src.fedoraproject.org/rpms/rust-bootupd
>   - https://src.fedoraproject.org/rpms/rust-fedora-coreos-pinger
>   - https://src.fedoraproject.org/rpms/rust-zincati
>
> Thanks!
>
> [1](
> https://discussion.fedoraproject.org/t/kinoite-a-kde-and-now-xfce-version-of-fedora-silverblue/147
> )
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Fedora-Cloud-31-20201110.0 compose check report

2020-11-10 Thread Fedora compose checker
No missing expected images.

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


Fedora-Cloud-32-20201110.0 compose check report

2020-11-10 Thread Fedora compose checker
No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-32-20201109.0):

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

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


[Bug 1890601] EPEL8 Request: perl-Test-Assert

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1890601



--- Comment #1 from Paul Howarth  ---
https://pagure.io/releng/fedora-scm-requests/issue/30654
https://pagure.io/releng/fedora-scm-requests/issue/30655


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


Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

2020-11-10 Thread Florian Weimer
* Tom Stellard:

> On 11/9/20 1:48 PM, Florian Weimer wrote:
>> * Miro Hrončok:
>> 
>>> On 11/9/20 7:05 PM, Tom Stellard wrote:
 Thanks for clarifying.  So it does sound like gcc will need at
 dependency on make.  If you do decide to use a weak dependency for this,
 then I think I will need to update the proposal to BuildRequire:
 make when gcc is used, so that we don't cause a performance
 regression in the builds.
>>>
>>> Well, we can add:
>>>
>>>  Requires: (make if redhat-rpm-config)
>>>
>>> To gcc.
>> Or
>> Requires: (make if gcc)
>> to redhat-rpm-config.  Given that the requirement actually comes
>> from
>> the -flto usage in redhat-rpm-config, that seems more reasonable to me.
>> 
>
> This make sense, but does this work if redhat-rpm-config and gcc are
> installed in separate transactions?

We already use

Requires: (annobin if gcc)

and that doesn't seem to cause any problems.

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


[Bug 1772783] Upgrade perl-Crypt-X509 to 0.53

2020-11-10 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1772783

Jitka Plesnikova  changed:

   What|Removed |Added

Version|32  |rawhide
Summary|Upgrade perl-Crypt-X509 to  |Upgrade perl-Crypt-X509 to
   |0.52|0.53



--- Comment #2 from Jitka Plesnikova  ---
Latest Fedora delivers 0.51 version. Upstream released 0.53. When you have free
time, please upgrade it.


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


Re: Non-responsive maintainer check avsej for grpc

2020-11-10 Thread Felix Schwarz


Am 09.11.20 um 22:35 schrieb Dan Čermák:

I have filed the respective ticket in Bugzilla [1] as I have seen no
development in the tracking bug to update grpc[2]. The outdated version
of grpc is currently blocking me from updating Bear to anything beyond
3.0.0.


Not directly relatived but:

I think Gwyn is working on updating grpc but as far as I understand there is an 
(upstream) bug which prevents grpc from compiling. The issue has been raised 
upstream but with little progress as far as I can tell.


Probably the best course of action would be to bundle the problematic git 
submodules yourself.


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