[Bug 1771314] perl-Protocol-HTTP2-1.10 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Protocol-HTTP2-1.10-1.
   ||fc32



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

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

[Bug 1771314] perl-Protocol-HTTP2-1.10 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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



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

[Bug 1770714] Upgrade perl-Excel-Writer-XLSX to 1.02

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |DUPLICATE
Last Closed||2019-11-12 07:33:43



--- Comment #1 from Jitka Plesnikova  ---


*** This bug has been marked as a duplicate of bug 1771119 ***

-- 
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 1771119] perl-Excel-Writer-XLSX-1.02 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC||jples...@redhat.com



--- Comment #2 from Jitka Plesnikova  ---
*** Bug 1770714 has been marked as a duplicate of this bug. ***

-- 
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 1771314] New: perl-Protocol-HTTP2-1.10 is available

[bugzilla]

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

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



Latest upstream release: 1.10
Current version/release in rawhide: 1.09-5.fc31
URL: http://search.cpan.org/dist/Protocol-HTTP2/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/13684/

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

[EPEL-devel] Missing Python 3 bindings for C libraries in EL7

[Mike DePaulo]

Hi everyone,

Background:
The Pulp 3 upstream project is written in Python 3.
Our installer normally uses PyPI for pure python packages, and OS
packages for C libraries & their python bindings.

Problem:
With RHEL7/CentOS7, we often run into the following thorny situation:
- Package libjuicy, written in C, exists in EL7 (main, optional, or extras).
- Subpackage python2-libjuicy with python2 bindings exists in EL7.
- Subpackage python3-libjuicy does not exist at all for EL7.

Note: libjuicy is a made up name :)

I am not sure how to provide the python3 bindings .

Solutions I've thought of:

1. I see that for pure python packages ("chardet" being an example I
stumbled upon), there's often a python2 package in EL7, but a python3
package in EPEL7. Often at different versions. And I found guidelines
for this. [1]

However, I am worried about robustness (& feasibility) of a
python3-libjuicy bindings-only source package in EPEL7 for an EL7
libjuicy. What if there's a libjuicy update and it breaks the bindings
until we (Pulp / Fedora contributors) update them? And would it be
permissible in EPEL 7?

2. Rebuild the entire EL7 SRPM with changes so it includes the python3
subpackage, and host it on Copr. Example: [2]

However, some of our users, and therefore my teammates, do not want to
add any repo other than EPEL and optional/extras. They would rather
this be in EPEL 7 (or perhaps CentOS 7) somehow.

3. We can request that RHEL7 provides an updated libjuicy with the
python3-libjuicy subpackage.

However, even if they say yes, it would take too long for upstream
release schedule.

Suggestions?

BTW, thank you for all the hard work on EPEL7 Python 3 support. I've
been following the RHEL 7.7 situation.

-Mike

[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
[2] proof-of-concept:
https://github.com/mikedep333/libcomps-rpm/commit/f162e237635e90d090e2f2f187b585aecd82165f
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b3dc1811a1   
rssh-2.3.4-15.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-755c983846   
golang-1.13.3-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-cd52ee3c1e   
putty-0.73-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-89d09bcf60   
php-robrichards-xmlseclibs-2.1.1-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-800a69997a   
djvulibre-3.5.25.3-18.el6


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

recap-2.1.0-4.el6

Details about builds:



 recap-2.1.0-4.el6 (FEDORA-EPEL-2019-6726af7a4e)
 Generates reports of various system information

Update Information:

Adds obsolete for rs-sysmon package

ChangeLog:

* Thu Oct 17 2019 Pete Travis  - 2.1.0-4
- Add obsoletes and provides for 'rs-sysmon', upstream predecessor of recap


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

[Bug 1768805] perl-RDF-Trine for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-RDF-Trine-1.019-8.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dba01dca66

-- 
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 1770310] perl-Net-OpenID-Consumer for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Net-OpenID-Consumer-1.18-11.el8 has been pushed to the Fedora EPEL 8
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f61e804ed4

-- 
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 1770506] Plans for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Device-SerialPort-1.04-35.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-a35eef98e3

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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2380c4654e   
freetds-1.1.20-1.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c6c395c50a   
chromium-78.0.3904.87-1.el8 minizip1.2-1.2.11-24.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9759af0dda   
koji-1.19.1-1.el8


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

codec2-0.8.1-4.el8
collectd-5.9.0-5.el8
conserver-8.2.2-4.el8
libblocksruntime-7.0.0-2.el8
opentrep-0.07.4-1.el8
perl-Device-SerialPort-1.04-35.el8
perl-Net-OpenID-Consumer-1.18-11.el8
perl-RDF-Query-2.918-11.el8
perl-RDF-Trine-1.019-8.el8
perl-Types-URI-0.006-7.el8
perl-URI-Encode-1.1.1-11.el8
python-dulwich-0.19.13-1.el8
python-oletools-0.54.2-2.el8
python-tqdm-4.37.0-1.el8
recap-2.1.0-4.el8

Details about builds:



 codec2-0.8.1-4.el8 (FEDORA-EPEL-2019-32c73c83d9)
 Next-Generation Digital Voice for Two-Way Radio

Update Information:

Initial release for EL 8.

References:

  [ 1 ] Bug #1771033 - Please branch and build codec2 for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1771033




 collectd-5.9.0-5.el8 (FEDORA-EPEL-2019-98f7dbf451)
 Statistics collection daemon for filling RRD files

Update Information:

Build write_riemann plugin

ChangeLog:

* Mon Nov 11 2019 Ruben Kerkhof  - 5.9.0-5
- Enable write_riemann plugin (#1770457)

References:

  [ 1 ] Bug #1770457 - Package collectd-write_riemann is missing from EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1770457




 conserver-8.2.2-4.el8 (FEDORA-EPEL-2019-f44b7ddeb4)
 Serial console server daemon/client

Update Information:

- Rebuilt.

References:

  [ 1 ] Bug #1770008 - Could you please build conserver for EPEL8?
https://bugzilla.redhat.com/show_bug.cgi?id=1770008




 libblocksruntime-7.0.0-2.el8 (FEDORA-EPEL-2019-370a6713f2)
 LLVM's compiler-rt/BlocksRuntime development files

Update Information:

Updated to Clang 7.0.0

ChangeLog:

* Sun Nov 10 2019 Ron Olson  7.0.0-2
- Updated to Clang 7.0.0
* Thu Jul 25 2019 Fedora Release Engineering  - 
5.0.2-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Fri Feb  1 2019 Fedora Release Engineering  - 
5.0.2-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild




 opentrep-0.07.4-1.el8 (FEDORA-EPEL-2019-b4b4a0b9a6)
 C++ library providing a clean API for parsing travel-focused requests

Update Information:

Upstream update

ChangeLog:

* Mon Nov 11 2019 Denis Arnaud  - 0.07.4-1
- Upstream update to 0.07.4




 perl-Device-SerialPort-1.04-35.el8 (FEDORA-EPEL-2019-a35eef98e3)
 Linux/POSIX emulation of Win32::SerialPort functions

Update Information:

Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

References:

  [ 1 ] Bug #1770506 - Plans for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1770506

[Bug 1770507] Plans for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-URI-Encode-1.1.1-11.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6a0b1536e9

-- 
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 1768802] perl-RDF-Query for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-RDF-Query-2.918-11.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-007e47d15e

-- 
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 1763668] [RFE] EPEL8 branch of perl-MouseX-Foreign

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1763668
Bug 1763668 depends on bug 1761857, which changed state.

Bug 1761857 Summary: perl-Mouse for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761857

   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 1763667] [RFE] EPEL8 branch of perl-Pod-Coverage-Moose

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1763667
Bug 1763667 depends on bug 1763664, which changed state.

Bug 1763664 Summary: [RFE] EPEL-8 branch for perl-MooseX-AttributeHelpers
https://bugzilla.redhat.com/show_bug.cgi?id=1763664

   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 1761857] perl-Mouse for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Mouse-2.5.9-2.el8
 Resolution|--- |ERRATA
Last Closed||2019-11-12 05:23:34



--- Comment #5 from Fedora Update System  ---
perl-Mouse-2.5.9-2.el8, perl-MouseX-Types-0.06-24.el8 has been pushed to the
Fedora EPEL 8 stable repository. If problems still persist, please make note of
it in this bug report.

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

[Bug 1744699] [RFE] EPEL8 branch of perl-Apache-LogFormat-Compiler

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Apache-LogFormat-Compi
   ||ler-0.35-10.el8
 Resolution|--- |ERRATA
Last Closed||2019-11-12 05:23:30



--- Comment #5 from Fedora Update System  ---
perl-Apache-LogFormat-Compiler-0.35-10.el8,
perl-POSIX-strftime-Compiler-0.42-11.el8, perl-Test-MockTime-0.17-7.el8 has
been pushed to the Fedora EPEL 8 stable repository. If problems still persist,
please make note of it in this bug report.

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

[Bug 1765525] [RFE] EPEL8 branch of perl-Data-Denter

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Data-Denter-0.15-29.el
   ||8
 Resolution|--- |ERRATA
Last Closed||2019-11-12 05:23:25



--- Comment #3 from Fedora Update System  ---
perl-Data-Denter-0.15-29.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1763667] [RFE] EPEL8 branch of perl-Pod-Coverage-Moose

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Pod-Coverage-Moose-0.0
   ||7-13.el8
 Resolution|--- |ERRATA
Last Closed||2019-11-12 05:23:32



--- Comment #3 from Fedora Update System  ---
perl-Pod-Coverage-Moose-0.07-13.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1762449] perl-Type-Tiny for EL8

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1762449
Bug 1762449 depends on bug 1761857, which changed state.

Bug 1761857 Summary: perl-Mouse for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761857

   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 1761983] Requesting perl-Redis for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Redis-1.995-3.el8
 Resolution|--- |ERRATA
Last Closed||2019-11-12 05:23:27



--- Comment #3 from Fedora Update System  ---
perl-IO-Socket-Timeout-0.32-13.el8, perl-PerlIO-via-Timeout-0.32-13.el8,
perl-Redis-1.995-3.el8 has been pushed to the Fedora EPEL 8 stable repository.
If problems still persist, please make note of it in this bug report.

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

[Bug 1744690] [RFE] EPEL8 branch of perl-Plack

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1744690
Bug 1744690 depends on bug 1744699, which changed state.

Bug 1744699 Summary: [RFE] EPEL8 branch of perl-Apache-LogFormat-Compiler
https://bugzilla.redhat.com/show_bug.cgi?id=1744699

   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 1763637] EPEL8 builds

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1763637
Bug 1763637 depends on bug 1765852, which changed state.

Bug 1765852 Summary: [RFE] EPEL-8 branch for perl-Term-Size
https://bugzilla.redhat.com/show_bug.cgi?id=1765852

   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 1765886] Please provide EPEL8 package

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-LockFile-Simple-0.208-
   ||17.el8
 Resolution|--- |ERRATA
Last Closed||2019-11-12 05:23:26



--- Comment #3 from Fedora Update System  ---
perl-LockFile-Simple-0.208-17.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1765529] [RFE] EPEL8 branch of perl-Data-Serializer

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1765529
Bug 1765529 depends on bug 1765525, which changed state.

Bug 1765525 Summary: [RFE] EPEL8 branch of perl-Data-Denter
https://bugzilla.redhat.com/show_bug.cgi?id=1765525

   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 1763664] [RFE] EPEL-8 branch for perl-MooseX-AttributeHelpers

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-MooseX-AttributeHelper
   ||s-0.25-12.el8
 Resolution|--- |ERRATA
Last Closed||2019-11-12 05:23:28



--- Comment #6 from Fedora Update System  ---
perl-MooseX-AttributeHelpers-0.25-12.el8 has been pushed to the Fedora EPEL 8
stable repository. If problems still persist, please make note of it in this
bug report.

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

[389-devel] Please review: 50703 - ldapssotoken for ds-portal

[William Brown]

https://pagure.io/389-ds-base/pull-request/50703

Thanks! 

--
Sincerely,

William
___
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 1770716] Upgrade perl-Module-CoreList to 5.20191110

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Module-CoreList-5.20191110-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-f4ff3b0278

-- 
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 1770718] Upgrade perl-Net-DAVTalk to 0.17

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Net-DAVTalk-0.17-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-eb875b74dc

-- 
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 1770717] Upgrade perl-Module-Load-Conditional to 0.70

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Module-Load-Conditional-0.70-1.fc29 has been pushed to the Fedora 29
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-24efeb13e4

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

[389-devel] 389 DS nightly 2019-11-12 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/11/12/report-389-ds-base-1.4.2.3-20191112git66a21bf.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Review request: xournalpp

[Luya Tshimbalanga]

Xournal which is currently shipped by default on Fedora Design Suite has 
remained stale since 2016. Enter xournal++, a fork started as a rewrite 
in c++ to evolve beyond. The author of xournal even encourage its use 
considering the compatibility with the format.


Here is the ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1771173


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

[Bug 1770716] Upgrade perl-Module-CoreList to 5.20191110

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Module-CoreList-5.20191110-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-2e005ea26f

-- 
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 1770717] Upgrade perl-Module-Load-Conditional to 0.70

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
perl-Module-Load-Conditional-0.70-1.fc30 has been pushed to the Fedora 30
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-c72d751f08

-- 
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 1770718] Upgrade perl-Net-DAVTalk to 0.17

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Net-DAVTalk-0.17-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-5bdc4ba7c3

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

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-11-12 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open=Meeting).



Source: https://apps.fedoraproject.org/calendar/meeting/9480/

___
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 1767613] perl-Devel-Timer-0.13 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Devel-Timer-0.13-1.fc3 |perl-Devel-Timer-0.13-1.fc3
   |0   |0
   ||perl-Devel-Timer-0.13-1.fc3
   ||1



--- Comment #9 from Fedora Update System  ---
perl-Devel-Timer-0.13-1.fc31 has been pushed to the Fedora 31 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1767613] perl-Devel-Timer-0.13 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Devel-Timer-0.13-1.fc3
   ||0
 Resolution|--- |ERRATA
Last Closed||2019-11-12 02:08:31



--- Comment #8 from Fedora Update System  ---
perl-Devel-Timer-0.13-1.fc30 has been pushed to the Fedora 30 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Re: Potential module for wxGTK3.1 unstable series / Audacity

[Kevin Kofler]

David Timms wrote:
> Perhaps calling a compat package 3.2.0.develseries.3.1.3 etc would make
> sense to indicate to consumers that they are using what will soon (TM)
> become the main version.

Please no. There is a numeric version, please use that, not some ugly 
version hack.

What would be acceptable, I suppose, is:
Name: wxGTK3.2
Version: 3.1.3
though some might even object to that (and demand Name: wxGTK3.1 instead).

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

Re: Modularity and all the things

[Kevin Kofler]

Matthew Miller wrote:
> One of the things I love about Fedora is that we don't have a big company-
> vs-community divide.

Huh? In what parallel universe do you live?

Modularity is just yet another example that clearly shows this divide. Just 
look at how Red Hat's desktop environment choice dominates all of Fedora 
massively and how all the community-packaged desktop environments (i.e., all 
those that do not have a footprint as their logo) consistently get treated 
as second-class citizens (as even a quick glance at getfedora.org will show 
you instantly).

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

[Bug 1771165] New: perl-App-s2p-1.003 is available

[bugzilla]

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

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



Latest upstream release: 1.003
Current version/release in rawhide: 1.002-17.fc31
URL: http://search.cpan.org/dist/App-s2p/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/2645/

-- 
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: Potential module for wxGTK3.1 unstable series / Audacity

[Scott Talbert]

On Mon, 11 Nov 2019, Scott Talbert wrote:


Audacity development (git) requires linking against wxGTK3.1.


Does it really? I cannot find this requirement in their git repository.

see: https://wiki.audacityteam.org/wiki/Building_On_Linux
or from the horse - (Mr Ed):
https://github.com/audacity/audacity/blob/master/linux/build.txt
"
wxWidgets:

1) Clone wxWidgets and checkout 3.1.1 from the Audacity fork of the
   wxWidgets project:
  https://github.com/audacity/wxWidgets/
"

I missed the fact that they build against their fork of wxWidgets from 
their own repo; I'm not sure whether it started as 3.1.1 or not.


Ouch.  So now you're talking about wanting to package a *fork* of a 
development release of wxGTK.  I would strongly suggesting talking to 
Audacity team about why they need a fork of wx 3.1.x and why they cannot get 
their fixes/changes upstreamed (and backported to wx 3.0).  Upstream wx is 
usually pretty good about backporting fixes to 3.0 if you request it.


I just took a quick look at the changes in their wx 3.1.1 fork.  It 
appears they are all Windows and Mac related.  So, their instructions to 
use their fork when building on Linux make no sense.


I would recommend doing as Kevin suggested and continue to build against 
wx 3.0.4 in Fedora.  If you run into a bug that has been fixed in wx 
3.1.x, feel free to report it and we will get the fix backported.


Scott
___
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: Modularity and all the things

[Kevin Kofler]

Matthew Miller wrote:
> There are certainly many examples of awesome great stuff that's been
> created in Fedora without the investment of Red Hat (or anyone's) full
> time employees. The zchunk metadata feature is a recent example. The
> Stewardship SIG is another one. This is good stuff, and I'm super-happy to
> support it. In both of those cases the people interested in that thing
> happening put in exactly the kind of effort I'm talking about here.

Unfortunately, the Stewardship SIG's work is actively being sabotaged by 
default module streams overriding their ursine packages for end users 
(unless they explicitly disable the fedora-modular repository, which is not 
supported anymore because some packages have become module-only) and even in 
the build system (FESCo having just voted for giving Ursa Prime a chance, 
though only for testing with 2 modules for the moment). We need to drop the 
default streams so that people actually get access to the ursine packages 
maintained by the Stewardship SIG.

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

Next NeuroFedora team meeting: 1600 UTC on Tuesday, 12th November

[Ankur Sinha]

Hello everyone,

You are invited to the next NeuroFedora team meeting at 1600UTC on
Tuesday 12th November.  You can see the time in your local time zone by
running this command in a terminal:

$ date --date='TZ="UTC" 1600 next Tue'

or please use the link below:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+team+meeting=20191112T16=1440=1

The agenda for the meeting is:

- Introductions and roll call.
- Tasks from last week's meeting: 
https://meetbot.fedoraproject.org/fedora-neuro/2019-11-05/neurofedora.2019-11-05-16.03.html
- Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
- Open NeuroFedora bugs: https://tinyurl.com/neurofedora-bugs
- Neuroscience query of the week.
- Next meeting day, and chair.
- Open floor.

Tomorrow's meeting will be chaired by: @bt0dotninja

We hope to see you there.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Potential module for wxGTK3.1 unstable series / Audacity

[Scott Talbert]

On Tue, 12 Nov 2019, David Timms wrote:


David Timms wrote:

Audacity development (git) requires linking against wxGTK3.1.


Does it really? I cannot find this requirement in their git repository.

see: https://wiki.audacityteam.org/wiki/Building_On_Linux
or from the horse - (Mr Ed):
https://github.com/audacity/audacity/blob/master/linux/build.txt
"
wxWidgets:

1) Clone wxWidgets and checkout 3.1.1 from the Audacity fork of the
   wxWidgets project:
  https://github.com/audacity/wxWidgets/
"

I missed the fact that they build against their fork of wxWidgets from their 
own repo; I'm not sure whether it started as 3.1.1 or not.


Ouch.  So now you're talking about wanting to package a *fork* of a 
development release of wxGTK.  I would strongly suggesting talking to 
Audacity team about why they need a fork of wx 3.1.x and why they cannot 
get their fixes/changes upstreamed (and backported to wx 3.0).  Upstream 
wx is usually pretty good about backporting fixes to 3.0 if you request 
it.


Scott
___
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: Potential module for wxGTK3.1 unstable series / Audacity

[Kevin Kofler]

David Timms wrote:
> see: https://wiki.audacityteam.org/wiki/Building_On_Linux
> or from the horse - (Mr Ed):
> https://github.com/audacity/audacity/blob/master/linux/build.txt
> "
> wxWidgets:
> 
>   1) Clone wxWidgets and checkout 3.1.1 from the Audacity fork of the
>  wxWidgets project:
> https://github.com/audacity/wxWidgets/
> "
> 
> I missed the fact that they build against their fork of wxWidgets from
> their own repo; I'm not sure whether it started as 3.1.1 or not.

They have been writing this all this time, this is not new in 2.3.3. Just 
ignore it, as usual when an upstream recommends using bundled libraries.

> Well, ... it does build and run against 3.0.4, but lots of "already
> fixed" - in wxGTK - issues are present.

Those are not your job as the Audacity packager to fix. Just build it 
against 3.0.4. We will get wxGTK 3.2.x when it is actually released.

>> Modules are always the wrong solution for libraries because they are
> Isn't that exactly what the module examples are doing ?

Those examples are bad. The Modularity team wants to push modules for this 
use case, but they are absolutely not suitable. See the recent threads about 
Modularity.

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

Re: Modularity and all the things

[Matthew Miller]

On Mon, Nov 11, 2019 at 03:02:13PM -0500, Alex Scheel wrote:
> From my organization at least, we have PM and management buy-in to
> continue contributing so long as we don't have a long-term solution
> that somebody else manages for us. So far, ursine packages have been
> our solution and we've helped with maintaining the stack as community
> members and giving back. That benefits all of Fedora.
> 
> I think we've accomplished something useful with the Stewardship SIG.
> 
> 
> So sure, we don't work only on the Stewardship SIG... But three paid
> Red Hat employees contributing in official capacities (as we have time)
> should, IMO, count for something. :-)

Oh, absolutely! I don't mean to discount this. One of the things I love
about Fedora is that we don't have a big company-vs-community divide. I'm
glad you have management buy-in for this too. 

So, yeah, this definitely counts for something!

-- 
Matthew Miller

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

Re: Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

On 12/11/19 8:05 am, David Timms wrote:
Audacity support when my users crash because they aren't running the 
recommended library (there is other locally adjusted libs which Audacity 
uses). Not that this is different from the past - but I would like it to 

oops, dropped word this is "no" different !
___
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: Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

On 12/11/19 1:33 am, Fabio Valentini wrote:
On Mon, Nov 11, 2019, 15:09 Vít Ondruch > wrote:


Dne 11. 11. 19 v 14:39 Kevin Kofler napsal(a):
 > David Timms wrote:
 >> I would like to be able to release the next Audacity (once
tested) when
 >> it drops.
 > I would recommend against doing that (unless you can get it to
build against
 > wxGTK 3.0 after all). Please wait until wxGTK 3.2 is actually
stable and
 > available in Fedora.

In the mean time, you can use Copr to provide updated wxGTK + Audacity.
Keeping the resolution of possible conflicts on the users.

Vít

I think the easiest solution would be to introduce a wxGTK "compat 
package" for 3.1, assuming it wouldn't conflict with the stable 
versions, and provide both the compat package and audacity builds based 
on it via COPR for testing.


https://trac.wxwidgets.org/wiki/Roadmap

Perhaps calling a compat package 3.2.0.develseries.3.1.3 etc would make 
sense to indicate to consumers that they are using what will soon (TM) 
become the main version.


Dave.
___
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 1771119] perl-Excel-Writer-XLSX-1.02 is available

[bugzilla]

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



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

-- 
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 1771119] New: perl-Excel-Writer-XLSX-1.02 is available

[bugzilla]

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

Bug ID: 1771119
   Summary: perl-Excel-Writer-XLSX-1.02 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Excel-Writer-XLSX
  Keywords: FutureFeature, Triaged
  Assignee: dd...@cpan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.02
Current version/release in rawhide: 1.01-1.fc32
URL: http://search.cpan.org/dist/Excel-Writer-XLSX/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/2860/

-- 
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: Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

On 12/11/19 1:51 am, Scott Talbert wrote:

On Mon, 11 Nov 2019, David Timms wrote:


Issue:
Audacity development (git) requires linking against wxGTK3.1.
The normal Fedora wxGTK3 package is at wxGTK3-3.04 in F29/30/31/devel.
wxGTK3.1 is a development series which eventually leads to wxGTK3.2 
release.

Upstream is currently at 3.1.3 and expecting at least a 3.1.4 next year.
Audacity 2.3.3 release is imminent (RC02).


Hi, one of the wxGTK maintainers here.  Where is the requirement to use 
wxGTK 3.1 documented?  Like Kevin, I can't find that documented.  And if 
it is definitely required, *why* is it required?


I would like to be able to release the next Audacity (once tested) 
when it drops.


I've been reading about Fedora modules, and am wondering whether the 
following would make sense as a potential solution ?:


$ dnf  modules  list  wxGTK3


I would be strongly opposed to using a module for this.  If you 
absolutely *must* have wx 3.1, we should just use a regular 
(non-modular) package. Note that we've already had one request for wx 
3.1 [1], but I've been hesitant to package it since it has unstable 
API/ABI and we typically don't package development releases.


Can you provide amplifying information on the wx 3.1 requirement from 
audacity first?
See earlier, and I'm not sure how realistic this web analysis tool is... 
I don't think it's the same one I've used before:

https://abi-laboratory.pro/index.php?view=timeline=wxwidgets

Dave.
___
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: Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

On 12/11/19 2:36 am, Christopher Engelhard wrote:

On 11/11/2019 3:51 PM, Scott Talbert wrote:
 > Hi, one of the wxGTK maintainers here.  Where is the requirement to use
 > wxGTK 3.1 documented?  Like Kevin, I can't find that documented.  
And if

 > it is definitely required, *why* is it required?

Because it fixes many issues with the earlier version.


On Archlinux audacity-git [1] builds against the default repo version of
wxGTK, i.e. 3.0.4, so it does not seem to be required.
It can in fact build against it - but then shows all the bugs that 
building against the old wxGTK entails. It means I can't get upstream 
Audacity support when my users crash because they aren't running the 
recommended library (there is other locally adjusted libs which Audacity 
uses). Not that this is different from the past - but I would like it to be.


Cheers, Dave.
___
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: Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

On 12/11/19 12:39 am, Kevin Kofler wrote:

David Timms wrote:

Audacity development (git) requires linking against wxGTK3.1.


Does it really? I cannot find this requirement in their git repository.

see: https://wiki.audacityteam.org/wiki/Building_On_Linux
or from the horse - (Mr Ed):
https://github.com/audacity/audacity/blob/master/linux/build.txt
"
wxWidgets:

 1) Clone wxWidgets and checkout 3.1.1 from the Audacity fork of the
wxWidgets project:
   https://github.com/audacity/wxWidgets/
"

I missed the fact that they build against their fork of wxWidgets from 
their own repo; I'm not sure whether it started as 3.1.1 or not.




The normal Fedora wxGTK3 package is at wxGTK3-3.04 in F29/30/31/devel.
wxGTK3.1 is a development series which eventually leads to wxGTK3.2
release. Upstream is currently at 3.1.3 and expecting at least a 3.1.4
next year. Audacity 2.3.3 release is imminent (RC02).


Ewww! Why is nobody complaining to Audacity upstream about that (assuming
that they really do require 3.1)? Requiring an unreleased/unstable wxGTK (I
would not count a development release as "released") makes no sense
whatsoever for a stable release of Audacity. Why are they not maintaining a
stable branch based on a stable wxGTK release? They should.

I found out yesterday, and that's why I'm trying to find most suitable way.


I would like to be able to release the next Audacity (once tested) when
it drops.


I would recommend against doing that (unless you can get it to build against
wxGTK 3.0 after all). Please wait until wxGTK 3.2 is actually stable and
available in Fedora.
Well, ... it does build and run against 3.0.4, but lots of "already 
fixed" - in wxGTK - issues are present.


I would prefer to follow Audacity teams requirements, as otherwise any 
issue reported in Fedora - I get the "did you build it like we said ?" 
response.



I've been reading about Fedora modules, and am wondering whether the
following would make sense as a potential solution ?:

$ dnf  modules  list  wxGTK3

Fedora Modular 30 - x86_64
Name Stream   Profiles Summary
wxGTK3   3.1.n-unstable   default [d], devel   GTK wxWidgets GUI library


No, that would be a very bad idea, because it means Audacity would then
conflict with all other wxGTK applications, or at least force them to run
with the unstable wxGTK with which they were not tested (depending on
whether wxGTK 3.1 is binary-backwards-compatible with 3.0 or not).
But if my user's "must" have the latest Audacity, and don't care about 
any other WxGTK3 using software, shouldn't this be my user's choice to 
make ?

It seems that modules would allow it.

Modules are always the wrong solution for libraries because they are 

Isn't that exactly what the module examples are doing ?


not parallel-installable.

Agreed, I got that much from the reading I've done on modules.


If the module was setup like this, then could the normal repo
audacity.spec package:
BuildRequires: wxGTK3:3.1.n-unstable/devel

Requires: does this get sorted out magically like in a normal package ?


No, building against a module does not work like that, it is more
complicated. But a module is a bad idea anyway, see above.

Where can I find information on using a module in another package ?


As I'm not on the wxGTK3 package team, can I do this without their
approval/assistance ?


No, you definitely need to find a solution together with them.
First step completed: Scott says he is on the wxGTK maintainers team, 
and thanks everyone for your responses so far.


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

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Neal Gompa]

On Mon, Nov 11, 2019 at 5:23 AM Florian Weimer  wrote:
>
> * John M. Harris, Jr.:
>
> > Anyone that has ever worked with CD images understands that every megabyte
> > counts.
>
> It's clearly not a priority for Fedora.  It wouldn't be too difficult to
> replace glibc-all-langpacks with glibc-locale-source in the installer,
> going from 26 MiB to less than 5 MiB compressed and from 208 MiB to
> about 20 MiB uncompressed (which, as I understand it, would affect
> memory requirements during installation).  The proposal was rejected.
>

It *is* a priority, but having less runtime scriptlets is a higher
priority. Your proposal would force scriptlets to be added for
handling langpacks everywhere. We're trying to drive towards
statelessness, not more weird non-deterministic stateful things during
installations and upgrades.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Modularity and all the things

[Alex Scheel]

- Original Message -
> From: "Matthew Miller" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, November 11, 2019 1:16:22 PM
> Subject: Re: Modularity and all the things
> 
> On Tue, Nov 05, 2019 at 10:28:02PM +0100, Fabio Valentini wrote:
> > That's all well and good, but you seem to be forgetting that people
> > are actually getting *paid* to work on modularity for fedora.
> > Any proposal for an alternative, which apparently needs to arrive at
> > least at MVP / proof-of-concept quality before it is even *considered*
> > as an alternative without getting called "trolling", can likely only
> > be worked on in somebody's spare time. I don't think that's a fair
> > requirement, and "exploring and contributing" will stay limited to RH
> > employees if that's the case.
> 
> Well, it really depends on the circumstance. In general, it's just practical
> reality that a proof of concept or MVP will get you a lot further than a
> suggestion -- that's not, like, a Fedora law or something.
> 
> There are certainly many examples of awesome great stuff that's been created
> in Fedora without the investment of Red Hat (or anyone's) full time
> employees. The zchunk metadata feature is a recent example. The Stewardship
> SIG is another one. This is good stuff, and I'm super-happy to support it.
> In both of those cases the people interested in that thing happening put in
> exactly the kind of effort I'm talking about here.

Hi Matthew,


While we certainly aren't numerous, Dinesh (fas: dmoluguw) and myself
(fas: cipherboy) contribute to the Stewardship SIG. Miro (fas: churchyard)
also contributes a lot. And if the load got worse, I'm sure Endi
(fas: edewata) would be willing to help.

From my organization at least, we have PM and management buy-in to
continue contributing so long as we don't have a long-term solution
that somebody else manages for us. So far, ursine packages have been
our solution and we've helped with maintaining the stack as community
members and giving back. That benefits all of Fedora.

I think we've accomplished something useful with the Stewardship SIG.


So sure, we don't work only on the Stewardship SIG... But three paid
Red Hat employees contributing in official capacities (as we have time)
should, IMO, count for something. :-)

- Alex

> 
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
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: are the ppc64le builders low on memory?

[Kaleb Keithley]

On Mon, Nov 11, 2019 at 1:39 PM Kevin Fenzi  wrote:

> On Mon, Nov 11, 2019 at 01:10:07PM -0500, Kaleb Keithley wrote:
> > Last week I built ceph 14.2.4-2 and it built fine on both fc31 and
> rawhide.
> >
> > I fixed a typo for a Requires: and the ppc64le builds today are getting
> > killed.
> >
> > https://kojipkgs.fedoraproject.org//work/tasks/7359/38917359/build.log
>
> Can you please provide links to the top level task?
>

https://koji.fedoraproject.org/koji/taskinfo?taskID=38917295

https://koji.fedoraproject.org/koji/taskinfo?taskID=38913962







> I can't tell what builder this was on, and it looks like you
> resubmitted?
>
> Anyhow, I guess I will reduce the number of cpus on the ppc builders.
>
> kevin
> ___
> 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: are the ppc64le builders low on memory?

[Kevin Fenzi]

On Mon, Nov 11, 2019 at 10:34:10AM -0800, Kevin Fenzi wrote:
> On Mon, Nov 11, 2019 at 01:10:07PM -0500, Kaleb Keithley wrote:
> > Last week I built ceph 14.2.4-2 and it built fine on both fc31 and rawhide.
> > 
> > I fixed a typo for a Requires: and the ppc64le builds today are getting
> > killed.
> > 
> > https://kojipkgs.fedoraproject.org//work/tasks/7359/38917359/build.log
> 
> Can you please provide links to the top level task?
> 
> I can't tell what builder this was on, and it looks like you
> resubmitted?
> 
> Anyhow, I guess I will reduce the number of cpus on the ppc builders. 

I seem to have confused this with another issue, as those builders only
have 4 cpus, and 10GB memory. 

kevin


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

Re: are the ppc64le builders low on memory?

[Kevin Fenzi]

On Mon, Nov 11, 2019 at 01:10:07PM -0500, Kaleb Keithley wrote:
> Last week I built ceph 14.2.4-2 and it built fine on both fc31 and rawhide.
> 
> I fixed a typo for a Requires: and the ppc64le builds today are getting
> killed.
> 
> https://kojipkgs.fedoraproject.org//work/tasks/7359/38917359/build.log

Can you please provide links to the top level task?

I can't tell what builder this was on, and it looks like you
resubmitted?

Anyhow, I guess I will reduce the number of cpus on the ppc builders. 

kevin


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

Re: Modularity: The Official Complaint Thread

[Matthew Miller]

On Tue, Nov 05, 2019 at 03:17:28PM -0500, Stephen Gallagher wrote:
> 4. Documentation of how to create a module stream is comprehensive but
> daunting. There is a lot of available information, but what is really
> lacking is a basic walkthrough for converting a single package to a
> module stream.

It's not just that the documentaiton is daunting. The _steps_ are daunting.
It's not an easy process even for simple cases.

[...]
> 12. Packaging a module requires writing both a spec file and a
> modulemd YAML file, which increases the total amount of work I need to
> do. [5]

I think having this live in a different repo in a whole different dist-git
namespace is a barrier. I'm not sure how to make this easier, but it
definitely multiplies the confusion and complexity for me. In retrospect,
I'd rather have a module definition file live in some "main" package for
each module.

And I also think we're missing a lot of the automation that came as
requirements out of the "Prototype Phase".
https://fedoraproject.org/wiki/Objectives/Fedora_Modularization,_Prototype_Phase



-- 
Matthew Miller

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

Re: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Mon, Nov 11, 2019 at 1:15 PM Robbie Harwood  wrote:
>
> Robbie Harwood  writes:
>
> > Stephen Gallagher  writes:
> >
> >> My intention was to provide some scope to the problem, because it
> >> seemed that a lot of alternatives being floated were not seeing some
> >> of the more subtle cases that we were trying to address. However, the
> >> biggest problem is that nearly every email to the list has been
> >> started with a "Begging the Question" Fallacy. People have started
> >> from the premise that "Modularity is Bad" and all of the rest of the
> >> conversation has continued from there. I'd like to provide an
> >> opportunity for us as a community to *constructively* state our
> >> grievances with Modularity. The fundamental root cause of some of the
> >> miscommunication is, I believe, that Modularity has problems and that
> >> people have assumed that they are fundamental and unfixable.
> >
> > Your framing here precludes a complete redesign, and that option needs
> > to be on the table for any real progress in communication and trust to
> > be made.  If others have "begged" that "modularity is bad", you have
> > done the same for "modularity is good".
>
> It's really frustrating to be repeatedly told we're not arguing in good
> faith and then see things like this (from today's fesco meeting [1]):
>
> 15:48:07  Can we please stop pretending like "start over
> from scratch" is a real option?
>
> Starting from scratch should be an option.  Removing modularity entirely
> should be an option.  Of course, so should be using modularity as it
> exists (or modifying it), but if we don't have those first two as
> options when there are proponents, this isn't a real technical
> discussion.
>

That quote is not fully in context, but that's entirely fair because I
didn't include enough context during the FESCo meeting. I apologize
for that. (Also, as you can tell from the rest of the log, I was
getting frustrated by that point).

When I said it's not a real option, I did not include any of my
reasoning (thus Begging the Question as you rightly point out). My
reasoning is basically this:

* Everyone on the Modularity Team is being paid by Red Hat to work on
Modularity.
* Red Hat Enterprise Linux 8 shipped with Modularity.
* The Modularity Team is responsible for maintaining that in RHEL 8
regardless of what happens in Fedora.
* A full redesign in Fedora is not realistically possible with the
people and resources we have available to us while also maintaining
the current implementation for ten years.
* Therefore we are focused on trying to get the current implementation
into better shape (and/or finding a safe migration strategy to a new
solution) rather than start from an entirely green field.

Thank you, Robbie, for calling me out on this. I did need to explain
this more fully.
___
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: Modularity: The Official Complaint Thread

[Robbie Harwood]

Robbie Harwood  writes:

> Stephen Gallagher  writes:
>
>> My intention was to provide some scope to the problem, because it
>> seemed that a lot of alternatives being floated were not seeing some
>> of the more subtle cases that we were trying to address. However, the
>> biggest problem is that nearly every email to the list has been
>> started with a "Begging the Question" Fallacy. People have started
>> from the premise that "Modularity is Bad" and all of the rest of the
>> conversation has continued from there. I'd like to provide an
>> opportunity for us as a community to *constructively* state our
>> grievances with Modularity. The fundamental root cause of some of the
>> miscommunication is, I believe, that Modularity has problems and that
>> people have assumed that they are fundamental and unfixable.
>
> Your framing here precludes a complete redesign, and that option needs
> to be on the table for any real progress in communication and trust to
> be made.  If others have "begged" that "modularity is bad", you have
> done the same for "modularity is good".

It's really frustrating to be repeatedly told we're not arguing in good
faith and then see things like this (from today's fesco meeting [1]):

15:48:07  Can we please stop pretending like "start over
from scratch" is a real option?

Starting from scratch should be an option.  Removing modularity entirely
should be an option.  Of course, so should be using modularity as it
exists (or modifying it), but if we don't have those first two as
options when there are proponents, this isn't a real technical
discussion.

Thanks,
--Robbie

1: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-11-11/fesco.2019-11-11-15.00.log.html
   As far as I can tell, this is specifically about "encourag[ing]
   packagers to leave things ursine and use modules only for
   alternatives", so my quoting is actually more generous than the
   context suggests.


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

Re: Modularity and all the things

[Matthew Miller]

On Tue, Nov 05, 2019 at 10:28:02PM +0100, Fabio Valentini wrote:
> That's all well and good, but you seem to be forgetting that people
> are actually getting *paid* to work on modularity for fedora.
> Any proposal for an alternative, which apparently needs to arrive at
> least at MVP / proof-of-concept quality before it is even *considered*
> as an alternative without getting called "trolling", can likely only
> be worked on in somebody's spare time. I don't think that's a fair
> requirement, and "exploring and contributing" will stay limited to RH
> employees if that's the case.

Well, it really depends on the circumstance. In general, it's just practical
reality that a proof of concept or MVP will get you a lot further than a
suggestion -- that's not, like, a Fedora law or something.

There are certainly many examples of awesome great stuff that's been created
in Fedora without the investment of Red Hat (or anyone's) full time
employees. The zchunk metadata feature is a recent example. The Stewardship
SIG is another one. This is good stuff, and I'm super-happy to support it.
In both of those cases the people interested in that thing happening put in
exactly the kind of effort I'm talking about here.


-- 
Matthew Miller

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

are the ppc64le builders low on memory?

[Kaleb Keithley]

Last week I built ceph 14.2.4-2 and it built fine on both fc31 and rawhide.

I fixed a typo for a Requires: and the ppc64le builds today are getting
killed.

https://kojipkgs.fedoraproject.org//work/tasks/7359/38917359/build.log

thanks

--

Kaleb
___
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: Add a rule to have a compose when Fedora branched

[Miro Hrončok]

On 11. 11. 19 19:09, Miro Hrončok wrote:

Excellent. I think this is ready to be presented to fesco for a vote.


Unless we decide it requires a change proposal. To limit the required 
bureaucracy, I can help draft it.


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

Re: Add a rule to have a compose when Fedora branched

[Miro Hrončok]

On 11. 11. 19 18:23, Kevin Fenzi wrote:

On Mon, Nov 11, 2019 at 09:51:33AM -0500, Ben Cotton wrote:

On Mon, Nov 11, 2019 at 4:01 AM Miro Hrončok  wrote:


Before you do this, can we figure out the details?

1. Do we use bodhi to handle the freeze?

Previously, this would not be possible, as bodhi was not yet "activated" at
branching, however with rawhide gating (and hopefully "branched gating" soon),
we could.


I'd defer to releng to determine what the best way to handle this is.


When we do branching we adjust koji targets and tags. My thought was to
do the adjustments, but disable some part of the workflow. Either
collect packages in the tag to be signed, or collect them in the tag to
be autosubmitted to gating by bodhi. Then, once a compose is done,
restart that process and process the backlog. If a package is needed for
a fix, it can manually be tagged in.



2. Who handles freeze exceptions, is it releng, QA?


That's a great question. The point of this freeze isn't testing, it's
getting a successful compose, so I would leave it in releng's hands. I
don't see that it needs the freeze exception process that we use for
releases. Of course QA and everyone else can help in determining what
packages need to be updated to fix the compose.


I think this should be completely up to releng. They should only land
things they need to get the compose working.



3. How are the freeeze exceptions handled, via bugzilla? What are the tracker
bugz? Or manually in https://pagure.io/releng/failed-composes/issues ?


There or in the main releng tracker. Whatever makes Mohan and Kevin
happiest. (Or the least unhappy).


releng tracker... but users should not make exceptions normally, it
should only be things needed to make the compose work.


None of this is to throw the problem over the wall and say "it's
releng's problem now!" It's more of "I trust them to come up with the
best solution since they're the ones closest to the problem."


Yep. I agree...


Excellent. I think this is ready to be presented to fesco for a vote.

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

Summary/Minutes from today's FESCo Meeting (2019-11-11)

[Justin Forbes]

=
#fedora-meeting-1: FESCO (2019-11-11)
=


Meeting started by jforbes at 15:00:23 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-11-11/fesco.2019-11-11-15.00.log.html
.



Meeting summary
---
* init process  (jforbes, 15:00:23)

* F32 System-Wide Change: Modules in non-Modular Buildroot  (jforbes,
  15:04:13)
  * LINK: https://pagure.io/fesco/issue/2257   (jforbes, 15:04:13)
  * AGREED: Change default streem for maven module: defer the decision
until we sort out the default modular streams strategy (+8,0,-0)
(jforbes, 15:11:11)
  * LINK:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JNTMUOBZHHCEOV7KS7MRNOBO6VGGT7RX/
(mhroncok, 15:43:13)
  * LINK:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JX7CNMIYVWBY4PWV3QQIDQGOTSNQJB5D/
(mhroncok, 15:43:36)
  * AGREED: Ursa Prime in rawhide with the remark that it doesn't expose
everything, not even "default everything" but rather exposes only
vetted list of modules (+5,0,-3)  (jforbes, 16:21:28)
  * AGREED: For the purposes of testing, we will allow the avocado and
dwm modules in the Ursa Prime buildroot (+5,0,-3)  (jforbes,
16:30:38)
  * AGREED: mark bug 1767351 a f32 fesco beta blocker (+7,0,-0)
(jforbes, 16:38:01)

* Next week's chair  (jforbes, 16:38:17)
  * ACTION: zbyszek will chair next week's meeting  (jforbes, 16:39:46)

* Open Floor  (jforbes, 16:39:55)
  * LINK: https://pagure.io/fesco/issue/2267 soas spin ?  (satellit_,
16:40:33)
  * LINK: https://paste.centos.org/view/bcb39f8f   (zbyszek, 17:01:11)

Meeting ended at 17:25:00 UTC.




Action Items

* zbyszek will chair next week's meeting




Action Items, by person
---
* zbyszek
  * zbyszek will chair next week's meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* sgallagh (142)
* mhroncok (133)
* jforbes (79)
* zbyszek (62)
* nirik (52)
* bookwar (46)
* mbooth (36)
* otaylor (25)
* zodbot (20)
* ignatenkobrain (12)
* satellit_ (7)
* mboddu (1)
* danilocesar (1)
* contyk (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
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: Add a rule to have a compose when Fedora branched

[Kevin Fenzi]

On Mon, Nov 11, 2019 at 09:51:33AM -0500, Ben Cotton wrote:
> On Mon, Nov 11, 2019 at 4:01 AM Miro Hrončok  wrote:
> >
> > Before you do this, can we figure out the details?
> >
> > 1. Do we use bodhi to handle the freeze?
> >
> > Previously, this would not be possible, as bodhi was not yet "activated" at
> > branching, however with rawhide gating (and hopefully "branched gating" 
> > soon),
> > we could.
> >
> I'd defer to releng to determine what the best way to handle this is.

When we do branching we adjust koji targets and tags. My thought was to
do the adjustments, but disable some part of the workflow. Either
collect packages in the tag to be signed, or collect them in the tag to
be autosubmitted to gating by bodhi. Then, once a compose is done,
restart that process and process the backlog. If a package is needed for
a fix, it can manually be tagged in.
> 
> > 2. Who handles freeze exceptions, is it releng, QA?
> >
> That's a great question. The point of this freeze isn't testing, it's
> getting a successful compose, so I would leave it in releng's hands. I
> don't see that it needs the freeze exception process that we use for
> releases. Of course QA and everyone else can help in determining what
> packages need to be updated to fix the compose.

I think this should be completely up to releng. They should only land
things they need to get the compose working. 
> 
> > 3. How are the freeeze exceptions handled, via bugzilla? What are the 
> > tracker
> > bugz? Or manually in https://pagure.io/releng/failed-composes/issues ?
> >
> There or in the main releng tracker. Whatever makes Mohan and Kevin
> happiest. (Or the least unhappy).

releng tracker... but users should not make exceptions normally, it
should only be things needed to make the compose work. 
> 
> None of this is to throw the problem over the wall and say "it's
> releng's problem now!" It's more of "I trust them to come up with the
> best solution since they're the ones closest to the problem."

Yep. I agree... 

kevin


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

Re: Fedora 32 System-Wide Change proposal: On-demand Side Tags

[Ben Cotton]

Per conversation with Miro and Zbigniew, this proposal is withdrawn
for the time being.

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

Fonts packaging policy rewrite proposal

[Nicolas Mailhot]

Hi,

A fonts packaging policy rewrite proposal has been pushed to FPC today:
https://pagure.io/packaging-committee/pull-request/934

It should be clearer, more opinionated, and take into account:
 – updates of The OpenType standard
 – variable fonts
 – web fonts
 – upstream depreciation of non OpenType formats: final stages of the
   Harfbuzz consolidation decided at the 2006 Text Layout summit
   https://www.freedesktop.org/wiki/TextLayout/
– appstream & fonts
– weak dependencies
– and probably more I forget here

It is based on the new fonts-rpm-macros project for automation:


This project builds on tooling enhancements in redhat-rpm-config and
rpm itself, done during the past two years for the Forge and Go sets of
packaging macros. It started 2 years ago as a fork of fontpackages,
which is the core of our current fonts packaging guidelines.

It will require putting the fonts-srpm-macros package in the default
build root, like is done for other domain-specific packaging macro
sets.

Major additions:
 – better documentation (clearer and more complete)
 – better automation (less packager hassle for better and more complete
   results)

Major removals:
 – tools and scripts
 – fixing metadata with ttname


Mostly because no one seems willing to maintain those scripts, or port
ttname to python 3.

https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/

showcases the new policy on 62 real-world source packages. Some of
those are badly delayed updates to Fedora packages, others are brand-new 
packages ready for Fedora inclusion. They include major font packages such as 
Stix, DejaVu, Droid, IBM Plex.


Existing Fedora packages will continue to build, the old fontpackages
macros are grandfathered in fonts-rpm-macros for now. They will be 
removed in a few years to give packagers time to apply the new 
guidelines.

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

Fonts packaging policy rewrite proposal

[Nicolas Mailhot via devel]

Hi,

A fonts packaging policy rewrite proposal has been pushed to FPC today:
https://pagure.io/packaging-committee/pull-request/934

It should be clearer, more opinionated, and take into account:
 – updates of The OpenType standard
 – variable fonts
 – web fonts
 – upstream depreciation of non OpenType formats: final stages of the
   Harfbuzz consolidation decided at the 2006 Text Layout summit
   https://www.freedesktop.org/wiki/TextLayout/
– appstream & fonts
– weak dependencies
– and probably more I forget here

It is based on the new fonts-rpm-macros project for automation:


This project builds on tooling enhancements in redhat-rpm-config and
rpm itself, done during the past two years for the Forge and Go sets of
packaging macros. It started 2 years ago as a fork of fontpackages,
which is the core of our current fonts packaging guidelines.

It will require putting the fonts-srpm-macros package in the default
build root, like is done for other domain-specific packaging macro
sets.

Major additions:
 – better documentation (clearer and more complete)
 – better automation (less packager hassle for better and more complete
   results)

Major removals:
 – tools and scripts
 – fixing metadata with ttname


Mostly because no one seems willing to maintain those scripts, or port
ttname to python 3.

https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/

showcases the new policy on 62 real-world source packages. Some of
those are badly delayed updates to Fedora packages, others are brand-new 
packages ready for Fedora inclusion. They include major font packages such as 
Stix, DejaVu, Droid, IBM Plex.


Existing Fedora packages will continue to build, the old fontpackages
macros are grandfathered in fonts-rpm-macros for now. They will be 
removed in a few years to give packagers time to apply the new 
guidelines.

Regards,
  
-- 
Nicolas Mailhot
___
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] please review: PR 50700 - Add disk monitor to CLI and UI

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50700

--

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

Re: Fedora 31 Elections: Nomination period open

[Ben Cotton]

Reminder that the nominations for various Fedora leadership bodies are
open through 23:59 UTC on 13 November. Nominations must be submitted
before that time on the appropriate wiki page (links below). Current
nomination counts:

FESCo: 6 for 5 seats
Council: 0 for 1 seat
Mindshare: 1 for 1 seat

On Thu, Oct 31, 2019 at 12:22 PM Ben Cotton  wrote:
>
> Today we are starting the Nomination & Campaign period during which we
> accept nominations to the "steering bodies" of the following teams:
>
> * FESCo (Engineering) (5 seats) [1]
> * Fedora Council (1 seat) [2]
> * Mindshare (1 seat) [3]
>
> This period is open until 2019-11-13 at 23:59:59 UTC.
>
> Candidates may self-nominate. If you nominate someone else, please
> check with them to ensure that they are willing to be nominated before
> submitting their name.
>
> The steering bodies are currently selecting interview questions for
> the candidates.
>
> Nominees submit their questionnaire answers via a private Pagure
> issue. The Election Wrangler or their backup will publish the
> interviews to the Community Blog before the start of the voting
> period.
>
> Please note that the interview is mandatory for all nominees. Nominees
> not having their interview ready by end of the Interview period
> (2019-11-20) will be disqualified and removed from the election.
>
> As part of the campaign people may also ask questions to specific
> candidates on the appropriate mailing list.
>
> The full schedule of the elections is available on the Elections
> schedule[4]. For more information about the elections process, see the
> program management docs[5].
>
> [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
> [2] https://fedoraproject.org/wiki/Council/Nominations
> [3] https://fedoraproject.org/wiki/Mindshare/Nominations
> [4] https://fedorapeople.org/groups/schedule/f-31/f-31-elections.html
> [5] https://docs.fedoraproject.org/en-US/program_management/elections/
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis



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

Re: Fedora 31 Elections: Nomination period open

[Ben Cotton]

Reminder that the nominations for various Fedora leadership bodies are
open through 23:59 UTC on 13 November. Nominations must be submitted
before that time on the appropriate wiki page (links below). Current
nomination counts:

FESCo: 6 for 5 seats
Council: 0 for 1 seat
Mindshare: 1 for 1 seat

On Thu, Oct 31, 2019 at 12:22 PM Ben Cotton  wrote:
>
> Today we are starting the Nomination & Campaign period during which we
> accept nominations to the "steering bodies" of the following teams:
>
> * FESCo (Engineering) (5 seats) [1]
> * Fedora Council (1 seat) [2]
> * Mindshare (1 seat) [3]
>
> This period is open until 2019-11-13 at 23:59:59 UTC.
>
> Candidates may self-nominate. If you nominate someone else, please
> check with them to ensure that they are willing to be nominated before
> submitting their name.
>
> The steering bodies are currently selecting interview questions for
> the candidates.
>
> Nominees submit their questionnaire answers via a private Pagure
> issue. The Election Wrangler or their backup will publish the
> interviews to the Community Blog before the start of the voting
> period.
>
> Please note that the interview is mandatory for all nominees. Nominees
> not having their interview ready by end of the Interview period
> (2019-11-20) will be disqualified and removed from the election.
>
> As part of the campaign people may also ask questions to specific
> candidates on the appropriate mailing list.
>
> The full schedule of the elections is available on the Elections
> schedule[4]. For more information about the elections process, see the
> program management docs[5].
>
> [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
> [2] https://fedoraproject.org/wiki/Council/Nominations
> [3] https://fedoraproject.org/wiki/Mindshare/Nominations
> [4] https://fedorapeople.org/groups/schedule/f-31/f-31-elections.html
> [5] https://docs.fedoraproject.org/en-US/program_management/elections/
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis



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

Re: Fedora 31 Does Not Use Swap Well?

[Chris Murphy]

On Sun, Nov 10, 2019 at 8:42 PM Code Zombie  wrote:
>
>
> Hi,
> I recently installed a fresh Fedora 31 in order to improve performance. I 
> have started to have a new problem. When my memory fills up when launching an 
> Android emulator, the system starts acting very slowly and becomes quite 
> unresponsive. I used to fill both memory and swap close to 100% without much 
> degraded performance, but now I wonder if there has been some changes in 
> Fedora memory management causing this?  And after all that, once I close the 
> emulator and free up some memory out of the total 8GB physical, the computer 
> starts to breathe again and back to normal.

This is related to this devel@ list discussion topic:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/

Which is an extension of this Workstation working group issue:
https://pagure.io/fedora-workstation/issue/98

Basically, I still have more questions than answers. But I look
forward to having something testable.

What I can tell you from many conversations I've been having on this subject:
- the kernel's swap is historically only intended for incidental swap
use, i.e. light writes to offload seldom used data to a backing device
in order to free up memory for actively used data

- due to default 1:1 ratio RAM to swap partitioning layouts, and
increased RAM in systems, swap has grown very large, but the bandwidth
to either HDD or SSD swap hasn't kept up. So in the non-incidental
variety of swap use we're increasingly seeing with VM and compile use
cases, swap thrashing is more common. That is, a persistent and
aggressive (high rates of read and/or writes to/from swap). And this
is where swap really fails because everything becomes IO bound in the
course of swap thrashing.

- It's completely reasonable for users to wonder WTF is going on, when
their system appears to have faceplanted even for 15 seconds. While
it's true the best solution is to add more physical RAM, it's common
for hardware to lack any ability to upgrade RAM after purchase.

- Some forms of compressed swap, both swap on ZRAM (entirely RAM
based, no backing swap partition), and ZSWAP (both RAM caching and
disk backed) can help smooth the terribly abrupt transition from RAM
only to swap dependent operations. The catch here is that under heavy
load, both of these become CPU bound due to compression/decompression,
as well as IO bound. It definitely helps moderate the badness of swap
use, but it's not a cure.

- The in-kernel out of memory manager (oom-killer) does not at all
care about user space. It doesn't care about responsiveness or
interactivity at all. It only cares about itself, and keeping its own
directly owned kernel threads running. When low memory threatens the
kernel, is the only time you'll see the kernel oom-killer clobber a
process. While this is tunable, it's really limited, and more often
than not in the current configuration you will see random processes
get killed off, not necessarily the worst offending processes.

- the above two combined translate into strategies to avoid swap
usage, and quickly kill top memory offenders within seconds, instead
of minutes, in order to give the impression of continued system
responsiveness. Of course, what's really happened is a process is
being killed off in order to achieve that.

My suggestion is to reproduce the problem, and capture a few bits of
information and post them to this thread:
$ free -m
$ cat /proc/meminfo
$ swapon

You might consider disabling your swap partition in /etc/fstab, by
just commenting out that line, shutting down all processes you've got
running or even just log out and then back in:

# swapoff /dev/sdXY
# dnf install zram
# systemctl enable --now zram

I've modified /etc/zram.conf to use FACTOR=1 which has worked out
well. Again, not panacea, and it depends by how much you're pressuring
swap, but this might alleviate some of the problem if your use case is
extremely swap IO bound, by exchanging it for CPU and RAM effort.

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

pcre2-10.34-RC2 with AArch64 SIMD JIT

[Petr Pisar]

I've just pushed pcre2-10.34-RC2 into Fedora 32. Among some boring
featuring like Unicode 12.1.0 and matching in invalid UTF strings, now
the AArch64 JIT compiler uses NEON instructions for better performance.
It's a quite fresh new code and there were some issues with it that
I believe are resolved now.

If you find some strange behavior of PCRE2 on AArch64, let me know.

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

Re: Potential module for wxGTK3.1 unstable series / Audacity

[Christopher Engelhard]

On 11/11/2019 3:51 PM, Scott Talbert wrote:
> Hi, one of the wxGTK maintainers here.  Where is the requirement to use 
> wxGTK 3.1 documented?  Like Kevin, I can't find that documented.  And if 
> it is definitely required, *why* is it required?

On Archlinux audacity-git [1] builds against the default repo version of 
wxGTK, i.e. 3.0.4, so it does not seem to be required.

Christopher

[1] https://aur.archlinux.org/packages/audacity-git/ (ignore stated pkg 
version, package pulls master on install)
___
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: I wrote a blog on why we moved Fedora 31 to cgroup V2

[Tomasz Torcz]

On Mon, Nov 11, 2019 at 10:06:40AM -0500, Daniel Walsh wrote:
> https://www.redhat.com/sysadmin/fedora-31-control-group-v2

  You write that snap does not run with v2, but linked bug
shows snapd was fixed 2 months ago:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-bb0a25e48d2

-- 
Tomasz TorczOnce you've read the dictionary,
xmpp: zdzich...@chrome.pl   every other book is just a remix.
___
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 Annual Release Cycle adjusted to match odd-numbered Fedora releases

[Matthew Miller]

On Thu, Nov 07, 2019 at 01:31:48PM +0100, Miro Hrončok wrote:
> tl;dr New Python 3.X versions will be released annually, with RC
> period adjusted to make it possible to update Python in odd-numbered
> Fedora releases. We plan to submit the Python 3.9 change proposal
> for Fedora 33 after the first Python 3.9 alpha (expected in ~2
> weeks).
> 

Very cool! Thanks!
-- 
Matthew Miller

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

Re: Schedule for Mondays's FESCo Meeting (2019-11-11)

[Justin Forbes]

>  F32 System-Wide Change: Modules in non-Modular Buildroot
>  https://pagure.io/fesco/issue/2257
>
Sorry, this is actually https://pagure.io/fesco/issue/2255
___
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

I wrote a blog on why we moved Fedora 31 to cgroup V2

[Daniel Walsh]

https://www.redhat.com/sysadmin/fedora-31-control-group-v2

If you like it, please put it out on social media.
___
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: Potential module for wxGTK3.1 unstable series / Audacity

[Scott Talbert]

On Mon, 11 Nov 2019, David Timms wrote:


Issue:
Audacity development (git) requires linking against wxGTK3.1.
The normal Fedora wxGTK3 package is at wxGTK3-3.04 in F29/30/31/devel.
wxGTK3.1 is a development series which eventually leads to wxGTK3.2 release.
Upstream is currently at 3.1.3 and expecting at least a 3.1.4 next year.
Audacity 2.3.3 release is imminent (RC02).


Hi, one of the wxGTK maintainers here.  Where is the requirement to use 
wxGTK 3.1 documented?  Like Kevin, I can't find that documented.  And if 
it is definitely required, *why* is it required?


I would like to be able to release the next Audacity (once tested) when it 
drops.


I've been reading about Fedora modules, and am wondering whether the 
following would make sense as a potential solution ?:


$ dnf  modules  list  wxGTK3


I would be strongly opposed to using a module for this.  If you absolutely 
*must* have wx 3.1, we should just use a regular (non-modular) package. 
Note that we've already had one request for wx 3.1 [1], but I've been 
hesitant to package it since it has unstable API/ABI and we typically 
don't package development releases.


Can you provide amplifying information on the wx 3.1 requirement from 
audacity first?


Thanks,
Scott

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1714714
___
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: Add a rule to have a compose when Fedora branched

[Ben Cotton]

On Mon, Nov 11, 2019 at 4:01 AM Miro Hrončok  wrote:
>
> Before you do this, can we figure out the details?
>
> 1. Do we use bodhi to handle the freeze?
>
> Previously, this would not be possible, as bodhi was not yet "activated" at
> branching, however with rawhide gating (and hopefully "branched gating" soon),
> we could.
>
I'd defer to releng to determine what the best way to handle this is.

> 2. Who handles freeze exceptions, is it releng, QA?
>
That's a great question. The point of this freeze isn't testing, it's
getting a successful compose, so I would leave it in releng's hands. I
don't see that it needs the freeze exception process that we use for
releases. Of course QA and everyone else can help in determining what
packages need to be updated to fix the compose.

> 3. How are the freeeze exceptions handled, via bugzilla? What are the tracker
> bugz? Or manually in https://pagure.io/releng/failed-composes/issues ?
>
There or in the main releng tracker. Whatever makes Mohan and Kevin
happiest. (Or the least unhappy).

None of this is to throw the problem over the wall and say "it's
releng's problem now!" It's more of "I trust them to come up with the
best solution since they're the ones closest to the problem."

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

[Bug 1770506] Plans for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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

-- 
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 1770507] Plans for EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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

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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via releng issues:
https://pagure.io/releng/issues

Full report available at:
https://churchyard.fedorapeople.org/orphans-2019-11-11.txt
grep it for your FAS username and follow the dependency chain.

   Package  (co)maintainersStatus Change

FUR orphan 0 weeks ago
airsnortorphan 0 weeks ago
apache-mime4j   orphan 2 weeks ago
base64coder jcapik, mizdebsk, orphan   0 weeks ago
batik   jvanek, mizdebsk, orphan   0 weeks ago
classmate   lef, orphan1 weeks ago
cli-parser  lef, orphan1 weeks ago
diffuse cicku, fab, orphan 5 weeks ago
dillo   aarem, orphan  0 weeks ago
eclipse-abrtorphan, sopotc 1 weeks ago
eclipse-cdt akurtakov, eclipse-sig,2 weeks ago
jjohnstn, kdaniel, orphan,
rgrunber
eclipse-epp-logging orphan, sopotc 1 weeks ago
eclipse-launchbar   eclipse-sig, orphan, sopotc1 weeks ago
extra166y   orphan 3 weeks ago
fbdesk  orphan 0 weeks ago
felix-osgi-foundation   orphan 3 weeks ago
freealutjwrdegoede, orphan, pwalter0 weeks ago
glassfish-gmbal orphan 1 weeks ago
glassfish-management-apiorphan 1 weeks ago
glassfish-pfl   orphan 1 weeks ago
grizzly orphan 1 weeks ago
grizzly-npn orphan 1 weeks ago
hibernate-jpa-2.0-api   orphan 0 weeks ago
ht  orphan 0 weeks ago
isight-firmware-tools   jmontleon, orphan  2 weeks ago
jackson mizdebsk, orphan   0 weeks ago
jackson-dataformat-xml  dchen, lef, orphan 1 weeks ago
jandex  orphan 0 weeks ago
jandex-maven-plugin lef, orphan1 weeks ago
java-oauth  lef, orphan1 weeks ago
jboss-connector-1.6-api gil, lef, orphan   1 weeks ago
jboss-jaspi-1.1-api lef, orphan1 weeks ago
jboss-jsp-2.3-api   orphan 0 weeks ago
jboss-transaction-1.1-api   orphan 0 weeks ago
jcsporphan 3 weeks ago
jersey  dchen, gwei3, orphan   1 weeks ago
js-excanvas nodejs-sig, orphan, rathann,   5 weeks ago
williamjmorenor
json_diff   orphan 5 weeks ago
lcmsajax, alexl, caillon, caolanm, 0 weeks ago
gnome-sig, johnp, mbarnes,
orphan, rhughes, rstrode, ssp
leafnodeorphan 5 weeks ago
libAfterImage   ellert, orphan 0 weeks ago
libee   mbartos, orphan0 weeks ago
libetpanorphan, simo   0 weeks ago
libktorrent kde-sig, liquidat, nucleo, 2 weeks ago
orphan, rdieter, tuxbrewr
libmimedir  orphan 0 weeks ago
libnxml orphan 0 weeks ago
libodb-boostdaveisfera, orphan   

Re: Potential module for wxGTK3.1 unstable series / Audacity

[Fabio Valentini]

On Mon, Nov 11, 2019, 15:09 Vít Ondruch  wrote:

>
> Dne 11. 11. 19 v 14:39 Kevin Kofler napsal(a):
> > David Timms wrote:
> >> Audacity development (git) requires linking against wxGTK3.1.
> > Does it really? I cannot find this requirement in their git repository.
> >
> >> The normal Fedora wxGTK3 package is at wxGTK3-3.04 in F29/30/31/devel.
> >> wxGTK3.1 is a development series which eventually leads to wxGTK3.2
> >> release. Upstream is currently at 3.1.3 and expecting at least a 3.1.4
> >> next year. Audacity 2.3.3 release is imminent (RC02).
> > Ewww! Why is nobody complaining to Audacity upstream about that
> (assuming
> > that they really do require 3.1)? Requiring an unreleased/unstable wxGTK
> (I
> > would not count a development release as "released") makes no sense
> > whatsoever for a stable release of Audacity. Why are they not
> maintaining a
> > stable branch based on a stable wxGTK release? They should.
> >
> >> I would like to be able to release the next Audacity (once tested) when
> >> it drops.
> > I would recommend against doing that (unless you can get it to build
> against
> > wxGTK 3.0 after all). Please wait until wxGTK 3.2 is actually stable and
> > available in Fedora.
>
>
> In the mean time, you can use Copr to provide updated wxGTK + Audacity.
> Keeping the resolution of possible conflicts on the users.
>
>
> Vít
>

I think the easiest solution would be to introduce a wxGTK "compat package"
for 3.1, assuming it wouldn't conflict with the stable versions, and
provide both the compat package and audacity builds based on it via COPR
for testing.

Fabio



>
> >
> >> I've been reading about Fedora modules, and am wondering whether the
> >> following would make sense as a potential solution ?:
> >>
> >> $ dnf  modules  list  wxGTK3
> >>
> >> Fedora Modular 30 - x86_64
> >> Name Stream   Profiles Summary
> >> wxGTK3   3.1.n-unstable   default [d], devel   GTK wxWidgets GUI library
> > No, that would be a very bad idea, because it means Audacity would then
> > conflict with all other wxGTK applications, or at least force them to
> run
> > with the unstable wxGTK with which they were not tested (depending on
> > whether wxGTK 3.1 is binary-backwards-compatible with 3.0 or not).
> >
> > Modules are always the wrong solution for libraries because they are not
> > parallel-installable.
> >
> >> If the module was setup like this, then could the normal repo
> >> audacity.spec package:
> >> BuildRequires: wxGTK3:3.1.n-unstable/devel
> >>
> >> Requires: does this get sorted out magically like in a normal package ?
> > No, building against a module does not work like that, it is more
> > complicated. But a module is a bad idea anyway, see above.
> >
> >> As I'm not on the wxGTK3 package team, can I do this without their
> >> approval/assistance ?
> > No, you definitely need to find a solution together with them.
> >
> > Kevin Kofler
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1770721] Upgrade perl-Parse-PMFile to 0.42

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Parse-PMFile-0.42-1.fc
   ||32
 Resolution|--- |RAWHIDE
Last Closed||2019-11-11 14:11:34



-- 
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: Potential module for wxGTK3.1 unstable series / Audacity

[Vít Ondruch]

Dne 11. 11. 19 v 14:39 Kevin Kofler napsal(a):
> David Timms wrote:
>> Audacity development (git) requires linking against wxGTK3.1.
> Does it really? I cannot find this requirement in their git repository.
>
>> The normal Fedora wxGTK3 package is at wxGTK3-3.04 in F29/30/31/devel.
>> wxGTK3.1 is a development series which eventually leads to wxGTK3.2
>> release. Upstream is currently at 3.1.3 and expecting at least a 3.1.4
>> next year. Audacity 2.3.3 release is imminent (RC02).
> Ewww! Why is nobody complaining to Audacity upstream about that (assuming 
> that they really do require 3.1)? Requiring an unreleased/unstable wxGTK (I 
> would not count a development release as "released") makes no sense 
> whatsoever for a stable release of Audacity. Why are they not maintaining a 
> stable branch based on a stable wxGTK release? They should.
>
>> I would like to be able to release the next Audacity (once tested) when
>> it drops.
> I would recommend against doing that (unless you can get it to build against 
> wxGTK 3.0 after all). Please wait until wxGTK 3.2 is actually stable and 
> available in Fedora.


In the mean time, you can use Copr to provide updated wxGTK + Audacity.
Keeping the resolution of possible conflicts on the users.


Vít


>
>> I've been reading about Fedora modules, and am wondering whether the
>> following would make sense as a potential solution ?:
>>
>> $ dnf  modules  list  wxGTK3
>>
>> Fedora Modular 30 - x86_64
>> Name Stream   Profiles Summary
>> wxGTK3   3.1.n-unstable   default [d], devel   GTK wxWidgets GUI library
> No, that would be a very bad idea, because it means Audacity would then 
> conflict with all other wxGTK applications, or at least force them to run 
> with the unstable wxGTK with which they were not tested (depending on 
> whether wxGTK 3.1 is binary-backwards-compatible with 3.0 or not).
>
> Modules are always the wrong solution for libraries because they are not 
> parallel-installable.
>
>> If the module was setup like this, then could the normal repo
>> audacity.spec package:
>> BuildRequires: wxGTK3:3.1.n-unstable/devel
>>
>> Requires: does this get sorted out magically like in a normal package ?
> No, building against a module does not work like that, it is more 
> complicated. But a module is a bad idea anyway, see above.
>
>> As I'm not on the wxGTK3 package team, can I do this without their
>> approval/assistance ?
> No, you definitely need to find a solution together with them.
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: Potential module for wxGTK3.1 unstable series / Audacity

[Kevin Kofler]

David Timms wrote:
> Audacity development (git) requires linking against wxGTK3.1.

Does it really? I cannot find this requirement in their git repository.

> The normal Fedora wxGTK3 package is at wxGTK3-3.04 in F29/30/31/devel.
> wxGTK3.1 is a development series which eventually leads to wxGTK3.2
> release. Upstream is currently at 3.1.3 and expecting at least a 3.1.4
> next year. Audacity 2.3.3 release is imminent (RC02).

Ewww! Why is nobody complaining to Audacity upstream about that (assuming 
that they really do require 3.1)? Requiring an unreleased/unstable wxGTK (I 
would not count a development release as "released") makes no sense 
whatsoever for a stable release of Audacity. Why are they not maintaining a 
stable branch based on a stable wxGTK release? They should.

> I would like to be able to release the next Audacity (once tested) when
> it drops.

I would recommend against doing that (unless you can get it to build against 
wxGTK 3.0 after all). Please wait until wxGTK 3.2 is actually stable and 
available in Fedora.

> I've been reading about Fedora modules, and am wondering whether the
> following would make sense as a potential solution ?:
> 
> $ dnf  modules  list  wxGTK3
> 
> Fedora Modular 30 - x86_64
> Name Stream   Profiles Summary
> wxGTK3   3.1.n-unstable   default [d], devel   GTK wxWidgets GUI library

No, that would be a very bad idea, because it means Audacity would then 
conflict with all other wxGTK applications, or at least force them to run 
with the unstable wxGTK with which they were not tested (depending on 
whether wxGTK 3.1 is binary-backwards-compatible with 3.0 or not).

Modules are always the wrong solution for libraries because they are not 
parallel-installable.

> If the module was setup like this, then could the normal repo
> audacity.spec package:
> BuildRequires: wxGTK3:3.1.n-unstable/devel
> 
> Requires: does this get sorted out magically like in a normal package ?

No, building against a module does not work like that, it is more 
complicated. But a module is a bad idea anyway, see above.

> As I'm not on the wxGTK3 package team, can I do this without their
> approval/assistance ?

No, you definitely need to find a solution together with them.

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

Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

Issue:
Audacity development (git) requires linking against wxGTK3.1.
The normal Fedora wxGTK3 package is at wxGTK3-3.04 in F29/30/31/devel.
wxGTK3.1 is a development series which eventually leads to wxGTK3.2 release.
Upstream is currently at 3.1.3 and expecting at least a 3.1.4 next year.
Audacity 2.3.3 release is imminent (RC02).

I would like to be able to release the next Audacity (once tested) when 
it drops.


I've been reading about Fedora modules, and am wondering whether the 
following would make sense as a potential solution ?:


$ dnf  modules  list  wxGTK3

Fedora Modular 30 - x86_64
Name Stream   Profiles Summary
wxGTK3   3.1.n-unstable   default [d], devel   GTK wxWidgets GUI library


If the module was setup like this, then could the normal repo 
audacity.spec package:

BuildRequires: wxGTK3:3.1.n-unstable/devel

Requires: does this get sorted out magically like in a normal package ?

I don't know whether any other wxGTK using packages could or should be 
using the wxGTK devel series.


As I'm not on the wxGTK3 package team, can I do this without their 
approval/assistance ?


Advice ? Am I on the right track ?

Cheers, Dave.
___
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: Will orphan packages with NEW F31FTBFS bugs tomorrow

[Miro Hrončok]

On 08. 11. 19 13:16, Miro Hrončok wrote:

According to the policy for packages that fail to build from source:

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



I plan to orphan packages with NEW Fedora 31 Fail To Build From Source bugzillas 
tomorrow.


Due to a general "panic" response and the fact that today is a holiday in the US 
and in many European countries, the current plan is to do this on Wednesday.


By doing so, we notify the dependent package owners that something is wrong with 
their dependency before it is removed.


Orphaned packages can be unorphaned without any damage.
When the packages stay orphaned for 6+ weeks, they will be retired.
Retired packages can be unretired. If they are retired for 8+ weeks, new package 
review is needed.


Remember to set the bugzilla to ASSIGNED when you actually work towards fixing 
the build failure.


The list would now be:


ExchangeIR
ExchangeIR
apt-cacher-ng
apt-cacher-ng
archaius
archaius
bibus
busybox
bval
camotics
cduce
clapham
couchdb
csstidy
delve
dumb-init
eclipse-anyedit
eclipse-avr
eclipse-checkstyle
eclipse-color-theme
eclipse-dltk
eclipse-egit
eclipse-emf
eclipse-epic
eclipse-gef
eclipse-license
eclipse-m2e-antlr
eclipse-m2e-apt
eclipse-m2e-buildhelper
eclipse-m2e-core
eclipse-m2e-cxf
eclipse-m2e-egit
eclipse-m2e-maven-dependency-plugin
eclipse-m2e-mavenarchiver
eclipse-m2e-mavendev
eclipse-m2e-modello
eclipse-m2e-plexus
eclipse-m2e-sisu
eclipse-m2e-takari
eclipse-m2e-tycho
eclipse-m2e-workspace
eclipse-m2e-wtp
eclipse-nls
eclipse-pdt
eclipse-quickrex
eclipse-remote
eclipse-sgx
eclipse-subclipse
eclipse-testng
eclipse-usage
eclipse-webtools
erlang-cuttlefish
erlang-erlando
erlang-riak_search
erlang-stdlib2
erlpmd
ferm
fop
giis
gipfel
glob2
glusterd2
golang-github-10gen-openssl
graphite-web
gucharmap
guestfs-browser
ioprocess
isdn4k-utils
jdo-api
jogl2
jove
lbzip2
libgovirt
libserf
libx86
lv2-abGate
lv2-kn0ck0ut
maven-checkstyle-plugin
maven-eclipse-plugin
merkaartor
multibit-commons
multibit-hardware
nodejs-basic-auth
nodejs-buffertools
nodejs-bunyan
nodejs-chai-cheerio
nodejs-chai-fs
nodejs-commonmark
nodejs-compressible
nodejs-cors
nodejs-css-select
nodejs-csslint
nodejs-dateformat
nodejs-defence
nodejs-del
nodejs-delete
nodejs-encodeurl
nodejs-engine-dot-io-parser
nodejs-esprima
nodejs-eyes
nodejs-fake
nodejs-finalhandler
nodejs-find-cache-dir
nodejs-find-up
nodejs-flat-cache
nodejs-git-remote-origin-url
nodejs-globby
nodejs-gnode
nodejs-grunt-contrib-csslint
nodejs-grunt-legacy-util
nodejs-htmlparser2
nodejs-import-local
nodejs-jsonselect
nodejs-load-grunt-tasks
nodejs-make-dir
nodejs-method-override
nodejs-mock-bin
nodejs-mock-git
nodejs-moment
nodejs-negotiator
nodejs-only-shallow
nodejs-path-type
nodejs-pkg-dir
nodejs-pkg-up
nodejs-raw-body
nodejs-redent
nodejs-select-hose
nodejs-send
nodejs-stylus
nodejs-temp-write
nodejs-tilejson
nodejs-tilelive
nodejs-unique-stream
nodejs-vasync
nodejs-write
nodejs-xmlhttprequest
ocaml-bin-prot
ocaml-bisect
ocaml-bitstring
ocaml-deriving
ocaml-json-static
ocaml-mikmatch
ocaml-openin
ocaml-pa-monad
ocaml-pgocaml
ocaml-sexplib
ocaml-type-conv
ocamldsort
paulstretch
perdition
pyexiv2
python-alchimia
python-cattrs
python-cloudservers
python-gfm
python-jira
python-k8sclient
python-sanic
python-subunit2sql
redeclipse
resiprocate
rgbds
sassc
scamper
scilab
sqlite2
swt-chart
tycho
tycho-extras
utop
vdirsyncer
zathura-cb
zathura-djvu
zathura-pdf-mupdf
zathura-pdf-poppler
zathura-ps
zookeeper

Remember, if you'd like a package not to be orphaned, set the bug to ASSIGNED 
and work towards fixing the build failure.



This is coordinated (I'm talking to myself) in this releng ticket:
https://pagure.io/releng/issue/8917



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

[Bug 1770719] Upgrade perl-Net-LibIDN2 to 1.01

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Net-LibIDN2-1.01-1.fc3
   ||2
 Resolution|--- |RAWHIDE
Last Closed||2019-11-11 12:18:04



--- Comment #1 from Petr Pisar  ---
Mainly bug fixes, but slightly different than Fedora has already delivered.
Keep it for Rawhide only due to a possible change of the behavior.

-- 
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 1770718] Upgrade perl-Net-DAVTalk to 0.17

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2019-5bdc4ba7c3 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-5bdc4ba7c3

-- 
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 1770718] Upgrade perl-Net-DAVTalk to 0.17

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2019-eb875b74dc has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-eb875b74dc

-- 
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 1770718] Upgrade perl-Net-DAVTalk to 0.17

[bugzilla]

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



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

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

Review swap for python-molten

[Anna Khaitovich]

Hi everyone,

I'd like to ask for a review for python-molten:

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

It requires python-typing-inspect (which will be reviewed by my sponsor):

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

I'm open for any review in exchange.

Thanks in advance,
Anna
___
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 1770718] Upgrade perl-Net-DAVTalk to 0.17

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Net-DAVTalk-0.17-1.fc3
   ||2



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

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

[Bug 1770717] Upgrade perl-Module-Load-Conditional to 0.70

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2019-24efeb13e4 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-24efeb13e4

-- 
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 1770717] Upgrade perl-Module-Load-Conditional to 0.70

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2019-c72d751f08 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-c72d751f08

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