Re: Paul Grosu

[Vascom]

pgrosu - is your FAS name?
Are you in packager group?

ср, 20 нояб. 2019 г. в 10:20, Paul Grosu :
>
> Hi Vascom,
>
> Thank you for the quick reply.  I already added the SSH public key, but when 
> I try to ssh with my private key and enter the username pgrosu at the 
> (login:) it says "No supported authentication methods available".  Does it 
> mean I should wait a day for it to go through, or should I contact the admin?
>
> Thanks,
> Paul
>
> On Wed, Nov 20, 2019 at 2:04 AM Vascom  wrote:
>>
>> You need to add your public ssh key at FAS page
>> https://admin.fedoraproject.org/accounts
>> And login via ssh.
>>
>> Read all information on
>> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
>>
>> ср, 20 нояб. 2019 г. в 09:54, Paul Grosu :
>> >
>> > Hello Fedora Development Community,
>> >
>> > I work at Northeastern University as a researcher in the Gene Cooperman 
>> > Lab, and will be supporting the DMTCP package 
>> > (https://apps.fedoraproject.org/packages/dmtcp) and DMTCP-devel 
>> > (https://apps.fedoraproject.org/packages/dmtcp-devel).  We are about to 
>> > release a new version of the package but don't have a aarch-64 machine, 
>> > and was wondering how to go about having access to one of the test 
>> > machines listed on the following weblink: 
>> > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
>> >
>> > Please let me know how to proceed regarding getting access to a test 
>> > machine.
>> >
>> > Thank you,
>> > Paul
>> > ___
>> > 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
___
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: Paul Grosu

[Paul Grosu]

Hi Vascom,

Thank you for the quick reply.  I already added the SSH public key, but
when I try to ssh with my private key and enter the username pgrosu at the
(login:) it says "No supported authentication methods available".  Does it
mean I should wait a day for it to go through, or should I contact the
admin?

Thanks,
Paul

On Wed, Nov 20, 2019 at 2:04 AM Vascom  wrote:

> You need to add your public ssh key at FAS page
> https://admin.fedoraproject.org/accounts
> And login via ssh.
>
> Read all information on
>
> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
>
> ср, 20 нояб. 2019 г. в 09:54, Paul Grosu :
> >
> > Hello Fedora Development Community,
> >
> > I work at Northeastern University as a researcher in the Gene Cooperman
> Lab, and will be supporting the DMTCP package (
> https://apps.fedoraproject.org/packages/dmtcp) and DMTCP-devel (
> https://apps.fedoraproject.org/packages/dmtcp-devel).  We are about to
> release a new version of the package but don't have a aarch-64 machine, and
> was wondering how to go about having access to one of the test machines
> listed on the following weblink:
> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
> >
> > Please let me know how to proceed regarding getting access to a test
> machine.
> >
> > Thank you,
> > Paul
> > ___
> > 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

corsepiu pushed to perl-HTTP-Entity-Parser (f30). "Update to 0.22."

[notifications]

Notification time stamped 2019-11-20 07:19:28 UTC

From 8c9e3505ec84293aaaf1fb43db5b4893fcb521c2 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius 
Date: Nov 20 2019 05:48:46 +
Subject: Update to 0.22.


---

diff --git a/.gitignore b/.gitignore
index f380dc3..f19a402 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTTP-Entity-Parser-0.21.tar.gz
+/HTTP-Entity-Parser-0.22.tar.gz
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index b6c4404..403ea89 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,6 +1,6 @@
 Name:   perl-HTTP-Entity-Parser
-Version:0.21
-Release:6%{?dist}
+Version:0.22
+Release:1%{?dist}
 Summary:PSGI compliant HTTP Entity Parser
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/HTTP-Entity-Parser
@@ -69,6 +69,9 @@ data and application/json.
 %{_mandir}/man3/*
 
 %changelog
+* Wed Nov 20 2019 Ralf Corsépius  - 0.22-1
+- Update to 0.22.
+
 * Fri Jul 26 2019 Fedora Release Engineering  - 
0.21-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
 
diff --git a/sources b/sources
index 1104c2f..b6f2c3f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (HTTP-Entity-Parser-0.21.tar.gz) = 
3852741017748205d9e030a6a42d5a949e3497c5e119713d81c9bf6ee42f9a0a822e65f4be9b8785840b6e81841c7715d34aabcb9b8d950611ce528f702fffd1
+SHA512 (HTTP-Entity-Parser-0.22.tar.gz) = 
fc54b92af197ec4dbdb1069f5a7a8db0892483f80a3737f4914cb6d03dd0ec01b2b215bed96b6736474d2d484516071926774610ace475199cae44174cc2abd0



https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/8c9e3505ec84293aaaf1fb43db5b4893fcb521c2?branch=f30
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org

corsepiu pushed to perl-HTTP-Entity-Parser (f30). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2019-11-20 07:19:28 UTC

From f9188b8c5bbd9194e355199626e2d9d96b724902 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 26 2019 03:37:35 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index 2e77cb2..b6c4404 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,6 +1,6 @@
 Name:   perl-HTTP-Entity-Parser
 Version:0.21
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:PSGI compliant HTTP Entity Parser
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/HTTP-Entity-Parser
@@ -69,6 +69,9 @@ data and application/json.
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 26 2019 Fedora Release Engineering  - 
0.21-6
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
+
 * Fri May 31 2019 Jitka Plesnikova  - 0.21-5
 - Perl 5.30 rebuild
 



https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/f9188b8c5bbd9194e355199626e2d9d96b724902?branch=f30
___
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

corsepiu pushed to perl-HTTP-Entity-Parser (f30). "Cleanup merger"

[notifications]

Notification time stamped 2019-11-20 07:19:28 UTC

From a6579e3a2f38523e561b9ad2acd8c1e995c7eb6b Mon Sep 17 00:00:00 2001
From: Ralf Corsépius 
Date: Nov 20 2019 06:57:09 +
Subject: Cleanup merger


---

diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index 403ea89..a0c3a6d 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -72,12 +72,6 @@ data and application/json.
 * Wed Nov 20 2019 Ralf Corsépius  - 0.22-1
 - Update to 0.22.
 
-* Fri Jul 26 2019 Fedora Release Engineering  - 
0.21-6
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
-
-* Fri May 31 2019 Jitka Plesnikova  - 0.21-5
-- Perl 5.30 rebuild
-
 * Fri Feb 01 2019 Fedora Release Engineering  - 
0.21-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/a6579e3a2f38523e561b9ad2acd8c1e995c7eb6b?branch=f30
___
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

corsepiu pushed to perl-HTTP-Entity-Parser (f30). "Perl 5.30 rebuild"

[notifications]

Notification time stamped 2019-11-20 07:19:28 UTC

From 40a1ad5be1f6689fb491f3d414768e53fc2c922a Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: May 31 2019 14:39:28 +
Subject: Perl 5.30 rebuild


---

diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index 65c3cd3..2e77cb2 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,6 +1,6 @@
 Name:   perl-HTTP-Entity-Parser
 Version:0.21
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:PSGI compliant HTTP Entity Parser
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/HTTP-Entity-Parser
@@ -69,6 +69,9 @@ data and application/json.
 %{_mandir}/man3/*
 
 %changelog
+* Fri May 31 2019 Jitka Plesnikova  - 0.21-5
+- Perl 5.30 rebuild
+
 * Fri Feb 01 2019 Fedora Release Engineering  - 
0.21-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/40a1ad5be1f6689fb491f3d414768e53fc2c922a?branch=f30
___
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: Paul Grosu

[Vascom]

You need to add your public ssh key at FAS page
https://admin.fedoraproject.org/accounts
And login via ssh.

Read all information on
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

ср, 20 нояб. 2019 г. в 09:54, Paul Grosu :
>
> Hello Fedora Development Community,
>
> I work at Northeastern University as a researcher in the Gene Cooperman Lab, 
> and will be supporting the DMTCP package 
> (https://apps.fedoraproject.org/packages/dmtcp) and DMTCP-devel 
> (https://apps.fedoraproject.org/packages/dmtcp-devel).  We are about to 
> release a new version of the package but don't have a aarch-64 machine, and 
> was wondering how to go about having access to one of the test machines 
> listed on the following weblink: 
> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
>
> Please let me know how to proceed regarding getting access to a test machine.
>
> Thank you,
> Paul
> ___
> 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

Paul Grosu

[Paul Grosu]

Hello Fedora Development Community,

I work at Northeastern University as a researcher in the Gene Cooperman
Lab, and will be supporting the DMTCP package (
https://apps.fedoraproject.org/packages/dmtcp) and DMTCP-devel (
https://apps.fedoraproject.org/packages/dmtcp-devel).  We are about to
release a new version of the package but don't have a aarch-64 machine, and
was wondering how to go about having access to one of the test machines
listed on the following weblink:
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

Please let me know how to proceed regarding getting access to a test
machine.

Thank you,
Paul
___
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: Review request: selenium-geckodriver

[Luya Tshimbalanga]

Hello Thomas,

I will take your review in exchange of mine below:

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

Would you update yours following the feedback?


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

Re: undefined symbol from OpenColorIO prevents Blender from running

[Luya Tshimbalanga]

On 2019-11-19 7:49 p.m., Richard Shaw wrote:


I'm all for fixing bugs quickly but it was only assigned to OCIO in BZ 
on 11/20 (UTC) and it's still November 19th for me :)



Same for me at the time writing. =) Thank for the quick reply.


It would hopefully be fixed by a simple rebuild which any 
provenpackager can do, but digging a little deeper:


$ c++filt _ZN4YAML6detail9node_data12empty_scalarB5cxx11E
YAML::detail::node_data::empty_scalar[abi:cxx11]

So the problem is really with YAML. It looks like Till Hofmann built 
yaml-cpp 0.6.3 for Fedora 30 and 31 (I only built it for Rawhide) and 
did not rebuild OCIO.


That makes sense. This case shows a better mechanism for updating 
dependent packages is much needed to avoid such problem using the 
following command below as an example:


# dnf --repoid=rawhide repoquery --qf "%{name}" --whatrequires 
"libyaml-cpp.so.0.6()(64bit)"
Last metadata expiration check: 0:00:43 ago on Tue 19 Nov 2019 
09:47:36 PM CST.

OpenColorIO
calamares-libs
daggy
dcm2niix
facter
fawkes-core
fawkes-lua
fawkes-plugin-navgraph
librime
mir-server-libs
pdns-ixfrdist
thinkfan




I'll take care of OCIO.

Thanks, I will keep track.

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

corsepiu pushed to perl-HTTP-Entity-Parser (f31). "Update to 0.22."

[notifications]

Notification time stamped 2019-11-20 06:04:06 UTC

From 8c9e3505ec84293aaaf1fb43db5b4893fcb521c2 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius 
Date: Nov 20 2019 05:48:46 +
Subject: Update to 0.22.


---

diff --git a/.gitignore b/.gitignore
index f380dc3..f19a402 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTTP-Entity-Parser-0.21.tar.gz
+/HTTP-Entity-Parser-0.22.tar.gz
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index b6c4404..403ea89 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,6 +1,6 @@
 Name:   perl-HTTP-Entity-Parser
-Version:0.21
-Release:6%{?dist}
+Version:0.22
+Release:1%{?dist}
 Summary:PSGI compliant HTTP Entity Parser
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/HTTP-Entity-Parser
@@ -69,6 +69,9 @@ data and application/json.
 %{_mandir}/man3/*
 
 %changelog
+* Wed Nov 20 2019 Ralf Corsépius  - 0.22-1
+- Update to 0.22.
+
 * Fri Jul 26 2019 Fedora Release Engineering  - 
0.21-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
 
diff --git a/sources b/sources
index 1104c2f..b6f2c3f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (HTTP-Entity-Parser-0.21.tar.gz) = 
3852741017748205d9e030a6a42d5a949e3497c5e119713d81c9bf6ee42f9a0a822e65f4be9b8785840b6e81841c7715d34aabcb9b8d950611ce528f702fffd1
+SHA512 (HTTP-Entity-Parser-0.22.tar.gz) = 
fc54b92af197ec4dbdb1069f5a7a8db0892483f80a3737f4914cb6d03dd0ec01b2b215bed96b6736474d2d484516071926774610ace475199cae44174cc2abd0



https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/8c9e3505ec84293aaaf1fb43db5b4893fcb521c2?branch=f31
___
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

corsepiu pushed to perl-HTTP-Entity-Parser (master). "Update to 0.22."

[notifications]

Notification time stamped 2019-11-20 05:49:13 UTC

From 8c9e3505ec84293aaaf1fb43db5b4893fcb521c2 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius 
Date: Nov 20 2019 05:48:46 +
Subject: Update to 0.22.


---

diff --git a/.gitignore b/.gitignore
index f380dc3..f19a402 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTTP-Entity-Parser-0.21.tar.gz
+/HTTP-Entity-Parser-0.22.tar.gz
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index b6c4404..403ea89 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,6 +1,6 @@
 Name:   perl-HTTP-Entity-Parser
-Version:0.21
-Release:6%{?dist}
+Version:0.22
+Release:1%{?dist}
 Summary:PSGI compliant HTTP Entity Parser
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/HTTP-Entity-Parser
@@ -69,6 +69,9 @@ data and application/json.
 %{_mandir}/man3/*
 
 %changelog
+* Wed Nov 20 2019 Ralf Corsépius  - 0.22-1
+- Update to 0.22.
+
 * Fri Jul 26 2019 Fedora Release Engineering  - 
0.21-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
 
diff --git a/sources b/sources
index 1104c2f..b6f2c3f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (HTTP-Entity-Parser-0.21.tar.gz) = 
3852741017748205d9e030a6a42d5a949e3497c5e119713d81c9bf6ee42f9a0a822e65f4be9b8785840b6e81841c7715d34aabcb9b8d950611ce528f702fffd1
+SHA512 (HTTP-Entity-Parser-0.22.tar.gz) = 
fc54b92af197ec4dbdb1069f5a7a8db0892483f80a3737f4914cb6d03dd0ec01b2b215bed96b6736474d2d484516071926774610ace475199cae44174cc2abd0



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

[Bug 1773915] Upgrade perl-MooX-late to 0.016

[bugzilla]

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

Ralf Corsepius  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2019-11-20 05:28:33



--- Comment #1 from Ralf Corsepius  ---
Test suite massaging only. No evident reason to push the package to older
fedora release.

-- 
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 1769974] [RFE] EPEL8 branch of perl-Hash-MultiValue

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Hash-MultiValue-0.16-16.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-aa8365a86e

-- 
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 1771705] [RFE] EPEL8 branch of perl-HTTP-Entity-Parser

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-HTTP-Entity-Parser-0.21-2.el8, perl-HTTP-MultiPartParser-0.02-10.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-649cb530bc

-- 
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-20 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/11/20/report-389-ds-base-1.4.1.9-1.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

Re: undefined symbol from OpenColorIO prevents Blender from running

[Richard Shaw]

On Tue, Nov 19, 2019 at 9:27 PM Luya Tshimbalanga 
wrote:

> Some users reported Blender which I maintain failed to start due to this
> issue:
>
> blender: symbol lookup error: /lib64/libOpenColorIO.so.1: undefined symbol: 
> _ZN4YAML6detail9node_data12empty_scalarB5cxx11E
>
>
>
> Accordingly, the problem is caused by OpenColorIO from which Blender
> depends. A bug is already filed [1] and it would be nice to fix it.
> Currently,the latest build of OpenColorIO on Fedora 31 is 1.1.1-2 while
> Rawhide is on 1.1.1-4[2]
>

I'm all for fixing bugs quickly but it was only assigned to OCIO in BZ on
11/20 (UTC) and it's still November 19th for me :)

It would hopefully be fixed by a simple rebuild which any provenpackager
can do, but digging a little deeper:

$ c++filt _ZN4YAML6detail9node_data12empty_scalarB5cxx11E
YAML::detail::node_data::empty_scalar[abi:cxx11]

So the problem is really with YAML. It looks like Till Hofmann built
yaml-cpp 0.6.3 for Fedora 30 and 31 (I only built it for Rawhide) and did
not rebuild OCIO.

And other packages probably need to be rebuilt as well:
# dnf --repoid=rawhide repoquery --qf "%{name}" --whatrequires
"libyaml-cpp.so.0.6()(64bit)"
Last metadata expiration check: 0:00:43 ago on Tue 19 Nov 2019 09:47:36 PM
CST.
OpenColorIO
calamares-libs
daggy
dcm2niix
facter
fawkes-core
fawkes-lua
fawkes-plugin-navgraph
librime
mir-server-libs
pdns-ixfrdist
thinkfan

I'll take care of OCIO.

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

[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

   Fixed In Version|perl-Module-Load-Conditiona |perl-Module-Load-Conditiona
   |l-0.70-1.fc32   |l-0.70-1.fc32
   |perl-Module-Load-Conditiona |perl-Module-Load-Conditiona
   |l-0.70-1.fc31   |l-0.70-1.fc31
   |perl-Module-Load-Conditiona |perl-Module-Load-Conditiona
   |l-0.70-1.fc29   |l-0.70-1.fc29
   ||perl-Module-Load-Conditiona
   ||l-0.70-1.fc30



--- Comment #17 from Fedora Update System  ---
perl-Module-Load-Conditional-0.70-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

[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

   Fixed In Version|perl-Net-DAVTalk-0.17-1.fc3 |perl-Net-DAVTalk-0.17-1.fc3
   |2   |2
   |perl-Net-DAVTalk-0.17-1.fc2 |perl-Net-DAVTalk-0.17-1.fc2
   |9   |9
   ||perl-Net-DAVTalk-0.17-1.fc3
   ||0



--- Comment #9 from Fedora Update System  ---
perl-Net-DAVTalk-0.17-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

[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

   Fixed In Version|perl-Module-CoreList-5.2019 |perl-Module-CoreList-5.2019
   |1110-1.fc32 |1110-1.fc32
   |perl-Module-CoreList-5.2019 |perl-Module-CoreList-5.2019
   |1110-1.fc31 |1110-1.fc31
   |perl-Module-CoreList-5.2019 |perl-Module-CoreList-5.2019
   |1110-1.fc29 |1110-1.fc29
   ||perl-Module-CoreList-5.2019
   ||1110-1.fc30



--- Comment #16 from Fedora Update System  ---
perl-Module-CoreList-5.20191110-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

[389-devel] Re: Performance discussion

[William Brown]

> On 14 Nov 2019, at 22:33, Ludwig Krispenz  wrote:
> 
> 
> On 11/14/2019 12:17 PM, William Brown wrote:
>> 
>>> On 14 Nov 2019, at 19:06, Ludwig Krispenz  wrote:
>>> 
>>> 
>>> On 11/14/2019 09:29 AM, William Brown wrote:
> On 14 Nov 2019, at 18:22, Ludwig Krispenz  wrote:
> 
> Hi William,
> 
> before further thinking about this, I need some clarification, or maybe I 
> just missed this. When you talk about 1..16 threads do you mean worker 
> threads ?
 Server worker threads. ldclt is set to only use 10 client threads - which 
 is surprising that with 10 client threads we see a decline when workers > 
 10 (one would assume it should stabilise).
 
> Or concurrent client connection threads in ldclt/rsearch/ - how many 
> concurrent connections do you have and how does varying this number 
> change results ?
 I will add more tests to this to allow varying the ldclt numbers.
>>> ok, and I assume that you are using a version with nunc-stans removed, 
>>> could you please also verify the effect of tubo-mode on/off ?
>> Correct, I'm using git master. Yes I'll check that also. I plan to add 
>> permutations like this to the test harness so it's easier for us to repeat 
>> in the future when we make changes.
>> 
>> I also need to find a way to wire in perf/stap so we can generate 
>> flamegraphs from each test run too for later analysis.
>> 
>> Thanks for the great ideas :)
> Thanks, and one more idea ;-)
> Can you separate the client and the server on two different machines, I've 
> seen ldclt or other clients impacting cpu usage a lot, there will be some 
> network overhead, but this should be ok (and more realistic)

That was the original goal, but I can't seperate it (yet) because we restart to 
change settings ... 

I'm not sure what's the best way to do it - have the tests maybe act as a 
generator and then you have to run the ldclt from a seperate machine? Not sure 
really  I need to think what it should look like.

I know viktor did some work on pytest over multiple hosts so perhaps that could 
help here too to coordinate? I think they also were speaking about ansible as 
well ... maybe he should comment if he has ideas.



>> 
> Regards,
> Ludwig
> 
> On 11/14/2019 03:34 AM, William Brown wrote:
>> Hi all,
>> 
>> After our catch up, we were discussing performance matters. I decided to 
>> start on this while waiting for some of my tickets to be reviewed and to 
>> see what's going on.
>> 
>> These tests were carried out on a virtual machine configured in search 6 
>> to have access to 6 CPU's, and search 12 with 12 CPU. Both machines had 
>> access to 8GB of ram.
>> 
>> The hardware is an i7 2.2GHz with 6 cores (12 threads) and 32GB of ram, 
>> with NVME storage provided.
>> 
>> The rows are the VM CPU's available, and the columns are the number of 
>> threads in nsslapd-threadnumber. No other variables were changed. The 
>> database has 6000 users and 4000 groups. The instance was restarted 
>> before each test. The search was a randomised uid equality test with a 
>> single result. I provided the thread 6 and 12 columns to try to match 
>> the VM and host specs rather than just the traditional base 2 sequence 
>> we see.
>> 
>> I've attached a screen shot of the results, but I have some initial 
>> thoughts to provide on this. What's interesting is our initial 1 thread 
>> performance and how steeply it ramps up towards 4 thread. This in mind 
>> it's not a linear increase. Per thread on s6 we go from ~3800 to ~2500 
>> ops per second, and a similar ratio exists in s12. What is stark is that 
>> after t4 we immediately see a per thread *decline* despite the greater 
>> amount of available computer resources. This indicates that it is poor 
>> locking and thread coordination causing a rapid decline in performance. 
>> This was true on both s6 and s12. The decline intesifies rapidly once we 
>> exceed the CPU avail on the host (s6 between t6 to t12), but still 
>> declines even when we do have the hardware threads available in s12.
>> 
>> I will perform some testing between t1 and t6 versions to see if I can 
>> isolate which functions are having a growth in time consumption.
>> 
>> For now an early recommendation is that we alter our default CPU 
>> auto-tuning. Currently we use a curve which starts at 16 threads from 1 
>> to 4 cores, and then tapering down to 512 cores to 512 threads - however 
>> in almost all of these autotuned threads we have threads greater than 
>> our core count. This from this graph would indicate that this decision 
>> only hurts our performance rather than improving it. I suggest we change 
>> our thread autotuning to be 1 to 1 ratio of threads to cores to prevent 
>> over contention on lock resources.
>> 
>> 

[389-devel] Please review gssapi test on suse support 50730

[William Brown]

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


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

undefined symbol from OpenColorIO prevents Blender from running

[Luya Tshimbalanga]

Some users reported Blender which I maintain failed to start due to this 
issue:


blender: symbol lookup error: /lib64/libOpenColorIO.so.1: undefined symbol: 
_ZN4YAML6detail9node_data12empty_scalarB5cxx11E


Accordingly, the problem is caused by OpenColorIO from which Blender 
depends. A bug is already filed [1] and it would be nice to fix it. 
Currently,the latest build of OpenColorIO on Fedora 31 is 1.1.1-2 while 
Rawhide is on 1.1.1-4[2]


Thanks in advance.

Reference:

---

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1774164

[2] https://koji.fedoraproject.org/koji/packageinfo?packageID=13789

--
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 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|ON_QA   |CLOSED
   Fixed In Version|perl-Net-DAVTalk-0.17-1.fc3 |perl-Net-DAVTalk-0.17-1.fc3
   |2   |2
   ||perl-Net-DAVTalk-0.17-1.fc2
   ||9
 Resolution|--- |ERRATA
Last Closed||2019-11-20 03:17:52



--- Comment #8 from Fedora Update System  ---
perl-Net-DAVTalk-0.17-1.fc29 has been pushed to the Fedora 29 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 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

   Fixed In Version|perl-Module-Load-Conditiona |perl-Module-Load-Conditiona
   |l-0.70-1.fc32   |l-0.70-1.fc32
   |perl-Module-Load-Conditiona |perl-Module-Load-Conditiona
   |l-0.70-1.fc31   |l-0.70-1.fc31
   ||perl-Module-Load-Conditiona
   ||l-0.70-1.fc29



--- Comment #16 from Fedora Update System  ---
perl-Module-Load-Conditional-0.70-1.fc29 has been pushed to the Fedora 29
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 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

   Fixed In Version|perl-Module-CoreList-5.2019 |perl-Module-CoreList-5.2019
   |1110-1.fc32 |1110-1.fc32
   |perl-Module-CoreList-5.2019 |perl-Module-CoreList-5.2019
   |1110-1.fc31 |1110-1.fc31
   ||perl-Module-CoreList-5.2019
   ||1110-1.fc29



--- Comment #15 from Fedora Update System  ---
perl-Module-CoreList-5.20191110-1.fc29 has been pushed to the Fedora 29 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: What's the State of the Java SIG?

[Kevin Kofler]

Aleksandra Fedorova wrote:
> I see that Mikolaj has a vision how it supposed to work. And I think he
> spent quite some time designing the workflow which would fit this vision,
> thus it is worth to listen to it with an open mind.
> 
> @Mikolaj, can you document the setup for java toolchain somewhere other
> than a mailing list? Buildroot modules, defaults streams, what Java
> packager should and shouldn't use... Probably one of those outdated wiki
> pages can be updated for that.

Buildroot-only modules? Stuff Java packagers shouldn't use? Why should we 
let one individual packager hold the entire Java ecosystem on Fedora hostage 
with such antisocial diktats?

I stand by my position that buildroot-only content of any kind (buildroot-
only packages, buildroot-only modules, packages filtered from modules, etc.) 
should just not be allowed in Fedora, ever. (And where it has already 
slipped through, it needs to be made user-installable (and available for all 
other packages) as soon as possible.) This is not even directly related to 
Modularity, Modularity just happens to be the way this anti-feature was 
implemented.

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: Orphaning nm-tray

[Kevin Kofler]

Sérgio Basto wrote:
> I use nm-applet instead plasma-nm in my kde and nm-applet just enforce
> libgobject , libgtk3 , libmm-glib, libpango, libpangocairo and
> nm-connection-editor [1]
> 
> [1]
> dnf repoquery --requires network-manager-applet

We were not talking about things required by network-manager-applet, but 
about things REQUIRING network-manager-applet, which should not happen.

At least here on F29 KDE:
[kevin@desktop64 ~]$ LANG=C.UTF-8 rpm -q network-manager-applet
package network-manager-applet is not installed

So I don't know what Raphael means by "There's indeed not much sense to have 
another tray icon when NetworkManager itself places anyways (by enforced 
dependencies) its own icon aside."

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 1773830] perl-Term-Table-0.015 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-Term-Table-0.015-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-950a4ee96f

-- 
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 1766572] [RFE] EPEL8 branch of perl-Perl-Critic-Pulp

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2019-11-20 02:30:26



--- Comment #4 from Fedora Update System  ---
perl-Perl-Critic-Pulp-97-2.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 1766572] [RFE] EPEL8 branch of perl-Perl-Critic-Pulp

[bugzilla]

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

Bug 1766571 Summary: [RFE] EPEL8 branch of perl-Pod-MinimumVersion
https://bugzilla.redhat.com/show_bug.cgi?id=1766571

   What|Removed |Added

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



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

[Bug 1766571] [RFE] EPEL8 branch of perl-Pod-MinimumVersion

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2019-11-20 02:30:24



--- Comment #4 from Fedora Update System  ---
perl-Pod-MinimumVersion-50-26.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 1766561] [RFE] EPEL8 branch of perl-constant-defer

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2019-11-20 02:30:14



--- Comment #4 from Fedora Update System  ---
perl-constant-defer-6-15.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 1744707] [RFE] EPEL8 branch of perl-CGI-Compile

[bugzilla]

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

Bug 1744708 Summary: [RFE] EPEL8 branch of perl-CGI-Emulate-PSGI
https://bugzilla.redhat.com/show_bug.cgi?id=1744708

   What|Removed |Added

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



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

[Bug 1766568] [RFE] EPEL8 branch of perl-podlinkcheck

[bugzilla]

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

Bug 1766561 Summary: [RFE] EPEL8 branch of perl-constant-defer
https://bugzilla.redhat.com/show_bug.cgi?id=1766561

   What|Removed |Added

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



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

[Bug 1758758] mod_perl-2.0.11 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|mod_perl-2.0.11-1.fc32  |mod_perl-2.0.11-1.fc32
   |mod_perl-2.0.11-1.fc30  |mod_perl-2.0.11-1.fc30
   |mod_perl-2.0.11-1.fc31  |mod_perl-2.0.11-1.fc31
   |mod_perl-2.0.11-1.fc29  |mod_perl-2.0.11-1.fc29
   |mod_perl-2.0.11-1.el7   |mod_perl-2.0.11-1.el7
   ||mod_perl-2.0.11-1.el8



--- Comment #16 from Fedora Update System  ---
mod_perl-2.0.11-1.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 1766568] [RFE] EPEL8 branch of perl-podlinkcheck

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2019-11-20 02:30:20



--- Comment #4 from Fedora Update System  ---
perl-podlinkcheck-15-10.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 1766565] [RFE] EPEL8 branch of perl-File-Find-Iterator

[bugzilla]

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

Bug 1766564 Summary: [RFE] EPEL8 branch of perl-Class-Iterator
https://bugzilla.redhat.com/show_bug.cgi?id=1766564

   What|Removed |Added

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



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

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

[bugzilla]

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

Bug 1744708 Summary: [RFE] EPEL8 branch of perl-CGI-Emulate-PSGI
https://bugzilla.redhat.com/show_bug.cgi?id=1744708

   What|Removed |Added

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



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

[Bug 1766568] [RFE] EPEL8 branch of perl-podlinkcheck

[bugzilla]

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

Bug 1766565 Summary: [RFE] EPEL8 branch of perl-File-Find-Iterator
https://bugzilla.redhat.com/show_bug.cgi?id=1766565

   What|Removed |Added

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



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

[Bug 1766564] [RFE] EPEL8 branch of perl-Class-Iterator

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2019-11-20 02:30:15



--- Comment #4 from Fedora Update System  ---
perl-Class-Iterator-0.3-22.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 1766570] [RFE] EPEL8 branch of perl-Test-Pod-LinkCheck

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2019-11-20 02:30:22



--- Comment #4 from Fedora Update System  ---
perl-Test-Pod-LinkCheck-0.008-20.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 1766570] [RFE] EPEL8 branch of perl-Test-Pod-LinkCheck

[bugzilla]

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

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

   What|Removed |Added

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



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

[Bug 1766565] [RFE] EPEL8 branch of perl-File-Find-Iterator

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2019-11-20 02:30:18



--- Comment #4 from Fedora Update System  ---
perl-File-Find-Iterator-0.4-22.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 1744708] [RFE] EPEL8 branch of perl-CGI-Emulate-PSGI

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-CGI-Emulate-PSGI-0.23-
   ||12.el8
 Resolution|--- |ERRATA
Last Closed||2019-11-20 02:30:11



--- Comment #4 from Fedora Update System  ---
perl-CGI-Emulate-PSGI-0.23-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

Re: Orphaning nm-tray

[Sérgio Basto]

On Wed, 2019-11-20 at 02:56 +0100, Kevin Kofler wrote:
> Raphael Groner wrote:
> > Right, we've planned to use nm-tray for the LXQt spin. But the
> > package is
> > already removed because it never worked as it should. There's
> > indeed not
> > much sense to have another tray icon when NetworkManager itself
> > places
> > anyways (by enforced dependencies) its own icon aside.
> 
> What is enforcing a dependency on nm-applet (NetworkManager-gnome)?
> Any such 
> dependency is a bug. (I had successfully gotten all such
> dependencies 
> eradicated as part of my Kannolo work, but some may have snuck back
> in 
> again, grrr!)


I use nm-applet instead plasma-nm in my kde and nm-applet just enforce
libgobject , libgtk3 , libmm-glib, libpango, libpangocairo and 
nm-connection-editor [1]

[1]
dnf repoquery --requires network-manager-applet

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

[Bug 1773830] perl-Term-Table-0.015 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Term-Table-0.015-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-1c0b045a7f

-- 
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: Orphaning nm-tray

[Kevin Kofler]

Raphael Groner wrote:
> Right, we've planned to use nm-tray for the LXQt spin. But the package is
> already removed because it never worked as it should. There's indeed not
> much sense to have another tray icon when NetworkManager itself places
> anyways (by enforced dependencies) its own icon aside.

What is enforcing a dependency on nm-applet (NetworkManager-gnome)? Any such 
dependency is a bug. (I had successfully gotten all such dependencies 
eradicated as part of my Kannolo work, but some may have snuck back in 
again, grrr!)

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: Minimization Objective report

[Kevin Kofler]

Adam Jackson wrote:
> That's about 44M worth of potential savings out of a 204M base image, a
> bit over 20%. I'll happily file proper bug reports for these somewhere
> if we want, but it took me like 30 minutes to look into this. If you're
> not even willing to put in _that_ little effort, then forgive me for
> not taking your assertion that "you simply cannot win" very seriously.

I am not the one who spent 2 months gaining 0.5%…

Also, most of your suggestions (and also most of the ideas the Minimization 
team has been floating so far) are very specific to the cloud image and will 
do absolutely nothing to decrease the size of real-world Fedora 
installations and live images.

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 1773830] perl-Term-Table-0.015 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
perl-Term-Table-0.015-1.fc31 has been pushed to the Fedora 31 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-3f02dd5aec

-- 
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 1748209] Please add CPAN's XML::Feed to EPEL-6 and EPEL-7

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-XML-Feed-0.43-1.el6|perl-XML-Feed-0.43-1.el6
   ||perl-XML-Feed-0.59-4.el7



--- Comment #11 from Fedora Update System  ---
perl-URI-Fetch-0.13-11.el7, perl-XML-Atom-0.42-6.el7, perl-XML-Feed-0.59-4.el7,
perl-XML-RSS-LibXML-0.3105-9.el7 has been pushed to the Fedora EPEL 7 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 1748209] Please add CPAN's XML::Feed to EPEL-6 and EPEL-7

[bugzilla]

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

Bug 1763496 Summary: [RFE] EPEL-7 branch for perl-DateTime-Format-Flexible
https://bugzilla.redhat.com/show_bug.cgi?id=1763496

   What|Removed |Added

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



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

[Bug 1758758] mod_perl-2.0.11 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|mod_perl-2.0.11-1.fc32  |mod_perl-2.0.11-1.fc32
   |mod_perl-2.0.11-1.fc30  |mod_perl-2.0.11-1.fc30
   |mod_perl-2.0.11-1.fc31  |mod_perl-2.0.11-1.fc31
   |mod_perl-2.0.11-1.fc29  |mod_perl-2.0.11-1.fc29
   ||mod_perl-2.0.11-1.el7



--- Comment #15 from Fedora Update System  ---
mod_perl-2.0.11-1.el7 has been pushed to the Fedora EPEL 7 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 1763496] [RFE] EPEL-7 branch for perl-DateTime-Format-Flexible

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2019-11-20 00:29:46



--- Comment #4 from Fedora Update System  ---
perl-DateTime-Format-Flexible-0.32-1.el7 has been pushed to the Fedora EPEL 7
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: Modularity and all the things

[John M. Harris Jr]

On Tuesday, November 19, 2019 4:42:31 AM MST Petr Pisar wrote:
> Manual work. Random commiters skipping them.

If your goal is to make it so that "Random commiters" are packagers, that's 
going to fall flat very quickly - as they'll just throw one version of the 
package in, never think about it again. That is an untenable situation.

-- 
John M. Harris, Jr.
Splentity

___
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: Introducing Square 1

[John M. Harris Jr]

On Monday, October 28, 2019 12:59:07 PM MST Troy Dawson wrote:
> Smoother initial creation of RHEL 9.[5]
I hope this is already clear, but what is good for RHEL is not necessarily 
good for Fedora. If it would do good here too, that's excellent. If not, that 
will be something that needs to get done down the line, perhaps in "CentOS 
Steam".

> - Get initial list of "core binaries"
See the package group @core?

> -- trimming out "extra" package languages.  (ex: perl for a
> minor script, when everything is in python.)

I don't really understand what you mean by this. Many contributors prefer to 
contribute with Perl scripts, rather than Python scripts. There are many 
people, myself included, that know Perl well, but do not know Python well, if 
at all.

> -- trimming functionality and/or moving functionality to sub-packages
> or separate package.
For what purpose? Can you provide an example of a package which would benefit 
from this, that does not already do something similar?

> - integrate these tests into the rawhide gating system, to alert when
> new dependencies have been added.

This could also be integrated into the already-extant release monitoring 
software.

-- 
John M. Harris, Jr.
Splentity

___
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] Re: Couple of troubles around using dsconf

[William Brown]

> On 19 Nov 2019, at 22:36, Matus Honek  wrote:
> 
> Hello folks,
> 
> Context: My setup is a running dscontainer with exported /data. While
> developing (outside of the container) I am trying to run `dsconf
> ldapi://%2fpath%2fto%2fdscontainers%2fsocket security get`.
> 
> Issue 1: I get IndexError exception:
>  File "/home/mhonek/src/ds/up/src/lib389/lib389/_mapped_object.py",
> line 158, in display
> How to fix the fact we can get no results to display, and to fix it
> correctly so that nothing else eventually blows up? Don't know...

Raise an issue seems like the first place to deal with this, especially with 
the stack trace associated.

> 
> Issue 2: Tracing back I find out I autobinded as non-root (non 0 UID).
> Expectable, but still unexpected. So I tried to override this by
> providing `-D` and `-w` explicitly to dsconf. No change, still
> autobinding. Turns out the autobind has preference over simple bind in
> DirSrv.open, this comes from [implementation].
> Possible solution: Instead of `elif can_autobind(): ... else:
> simple_bind` do `elif self.binddn is not None: ... else
> can_autobind(): ...`. Worked for me. Would this blow up some use-case?
> Don't know...

autobind is super important for ldapi - you have to prefer autobind else things 
go wildly wrong  but also that whole section of dirsrv.open is extremely 
cursed and never should have been structured like that. But this is the bed we 
have, so we have to lie in it now.

A major drawback that I have been suffering from here is in your statement - 
would this blow up some use-case? I have no idea. It's python, which is 
basically schroedingers language. It's unknown unless it's observed running.

I'd suggest we open an issue here and then let's think about how we could solve 
it, but it won't be easy because all of the def open code needs a rethink - we 
need a better approach to how to determine how we want to present 
authentication credentials.

> 
> Sub-issue 2a: Given I was able to autobind as non-root UID, the
> wording in a log message [aubind-log]. The word "root" probably
> shouldn't be there?

Sure, just open an issue and fix it? (This is kind of why I want PR's to not 
need an issue, to encourage quicker small fixes like this rather than a lot of 
admin overhead to the process).

> 
> Somewhat troubling 1: At the time of running open in the autobind
> branch in DirSrv.open [autobind] the value of `self.bindpw` is
> literally "password" even though no `-D` nor `-w` was provided on
> command line for dsconf. I believe there are some reasons (besides
> "because the code is written so") why this is so but I would like to
> be enlightened here.

Lib389 didn't always have a topologies module. Previously each instance would 
be setup manually in each test with ds.allocate(); ds.create(); ds.bind() ... 
So that meant a lot of "testing" defaults ended up in DirSrv. It became a 
kitchen sink. It was later on that we start to really modularise it out with 
DSLdapObject, topologies and others. That caused a lot of defaults to shift 
out, but a lot of fragments of that legacy still exist in DirSrv because it has 
an extremely fragile design. 

Anyway, this can probably be removed, it shouldn't be needed, and it could 
confuse def open().

In general, I've been trying to push toward local_simple_allocate and 
remote_simple_allocate, but I never got traction on it. The whole way we setup 
DirSrv as a type is really messy :( ... Actually, the whole DirSrv type is a 
small microcosm of evil ... 

Honestly I would *love* a solid two weeks in a room with you, simon, mark, 
viktor, and we just clean and replace DirSrv as a type. That would be amazing.

> 
> [implementation] https://pagure.io/389-ds-base/c/e07e489
> [autobind-log] 
> https://pagure.io/389-ds-base/blob/6d70cbe/f/src/lib389/lib389/__init__.py#_1063
> [autobind] 
> https://pagure.io/389-ds-base/blob/6d70cbe/f/src/lib389/lib389/__init__.py#_1060
> 
> Please, share your ideas, where I went wrong, what we could go ahead with.

Computers were a mistake, that was where we went wrong :) 

But when you see a problem, you talk about it (which you did), then we fix it. 
:) 

> 
> Thanks,
> Matus
> 
> -- 
> Matúš Honěk
> Software Engineer
> Red Hat Czech
> ___
> 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

—
Sincerely,

William Brown

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

Re: What's the State of the Java SIG?

[Mat Booth]

On Mon, 18 Nov 2019 at 11:17, John M. Harris Jr 
wrote:
> I must disagree. That it "works" in RHEL doesn't mean that it should be
done
> in Fedora. The current situation in Fedora, where maven and ant have been
> "moved" to modules has screwed over the Eclipse packagers, for example,
and
> more are to follow.
>

I'm flattered that you think there is more than one Eclipse packager these
days, but it is not my perception that choices made by the maven and ant
maintainer has screwed over Eclipse.

>From my PoV the problem is that Ursa Prime née Major has been coming Real
Soon Now™ for years to obviate the build issues but it just never
materialised. This is why the Eclipse stack has gotten into a bit of a
pickle -- I waited far too long with far too much naive optimism before
modularising and I'm sad to say that not modularising Eclipse sooner has
done a great disservice to users.

TBH as a desktop application, I see a brighter future in Flatpak for
Eclipse and maybe when our Flatpak distribution is mature enough, we can
eventually stop shipping RPMs altogether
___
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: Not shipping 3 types of bytecode in python3-libs?

[Fabio Valentini]

On Tue, Nov 19, 2019, 22:30 Miro Hrončok  wrote:

> On 19. 11. 19 21:55, Fabio Valentini wrote:
> > On Tue, Nov 19, 2019 at 8:32 PM Miro Hrončok 
> wrote:
> >>
> >> On 19. 11. 19 20:20, Adam Jackson wrote:
> >>> In the spirit of positivity and collaboration, I spent a few minutes
> >>> looking at the results given to try to find some easy wins. Here's what
> >>> I found:
> >>>
> >>> python3-libs ships multiple copies of its pyc files, corresponding to
> >>> different optimization levels. I don't know what a good packaging
> >>> solution to that would look like, but if we only shipped the -O2 kind
> >>> (which seems appropriate for minimization, as they're smallest) we
> >>> could drop about 13M out of 32M, which seems pretty great.
> >>
> >> Note that it would make more sense to drop the optimized ones, as most
> of our
> >> packages invoke Python without -O or -OO.
> >>
> >> It would certainly need more planning and figuring out what shall
> happen if the
> >> optimized bytecode is not there and users actually run Python with -O
> or -OO,
> >> but we can discusses that if you want.
> >
> > I wonder, does running python programs with -O2 actually yield
> > noticeably better performance?
> > If that's the case, maybe we could discuss setting -O2 as a
> > distro-wide default setting?
>
> It drops asserts and docstrings. Some code require both to function, hence
> defaulting to this would be dangerous.
>

Yeah I guess so :D
Thanks for the clarification!


> --
> 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
>
___
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: Not shipping 3 types of bytecode in python3-libs?

[Miro Hrončok]

On 19. 11. 19 21:55, Fabio Valentini wrote:

On Tue, Nov 19, 2019 at 8:32 PM Miro Hrončok  wrote:


On 19. 11. 19 20:20, Adam Jackson wrote:

In the spirit of positivity and collaboration, I spent a few minutes
looking at the results given to try to find some easy wins. Here's what
I found:

python3-libs ships multiple copies of its pyc files, corresponding to
different optimization levels. I don't know what a good packaging
solution to that would look like, but if we only shipped the -O2 kind
(which seems appropriate for minimization, as they're smallest) we
could drop about 13M out of 32M, which seems pretty great.


Note that it would make more sense to drop the optimized ones, as most of our
packages invoke Python without -O or -OO.

It would certainly need more planning and figuring out what shall happen if the
optimized bytecode is not there and users actually run Python with -O or -OO,
but we can discusses that if you want.


I wonder, does running python programs with -O2 actually yield
noticeably better performance?
If that's the case, maybe we could discuss setting -O2 as a
distro-wide default setting?


It drops asserts and docstrings. Some code require both to function, hence 
defaulting to this would be dangerous.


--
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: Not shipping 3 types of bytecode in python3-libs?

[Fabio Valentini]

On Tue, Nov 19, 2019 at 8:32 PM Miro Hrončok  wrote:
>
> On 19. 11. 19 20:20, Adam Jackson wrote:
> > In the spirit of positivity and collaboration, I spent a few minutes
> > looking at the results given to try to find some easy wins. Here's what
> > I found:
> >
> > python3-libs ships multiple copies of its pyc files, corresponding to
> > different optimization levels. I don't know what a good packaging
> > solution to that would look like, but if we only shipped the -O2 kind
> > (which seems appropriate for minimization, as they're smallest) we
> > could drop about 13M out of 32M, which seems pretty great.
>
> Note that it would make more sense to drop the optimized ones, as most of our
> packages invoke Python without -O or -OO.
>
> It would certainly need more planning and figuring out what shall happen if 
> the
> optimized bytecode is not there and users actually run Python with -O or -OO,
> but we can discusses that if you want.

I wonder, does running python programs with -O2 actually yield
noticeably better performance?
If that's the case, maybe we could discuss setting -O2 as a
distro-wide default setting?

Fabio

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

[Test-Announce] Fedora 32 Rawhide 20191119.n.2 nightly compose nominated for testing

[rawhide]

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

Notable package version changes:
anaconda - 20191115.n.0: anaconda-32.14-1.fc32.src, 20191119.n.2: 
anaconda-32.15-1.fc32.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/32

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

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191119.n.2_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191119.n.2_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191119.n.2_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191119.n.2_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191119.n.2_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191119.n.2_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191119.n.2_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
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 1774235] New: perl-EV-4.28 is available

[bugzilla]

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

Bug ID: 1774235
   Summary: perl-EV-4.28 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-EV
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: carl@george.computer, emman...@seyman.fr,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.28
Current version/release in rawhide: 4.27-1.fc31
URL: https://metacpan.org/release/EV

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

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

Not shipping 3 types of bytecode in python3-libs?

[Miro Hrončok]

On 19. 11. 19 20:20, Adam Jackson wrote:

In the spirit of positivity and collaboration, I spent a few minutes
looking at the results given to try to find some easy wins. Here's what
I found:

python3-libs ships multiple copies of its pyc files, corresponding to
different optimization levels. I don't know what a good packaging
solution to that would look like, but if we only shipped the -O2 kind
(which seems appropriate for minimization, as they're smallest) we
could drop about 13M out of 32M, which seems pretty great.


Note that it would make more sense to drop the optimized ones, as most of our 
packages invoke Python without -O or -OO.


It would certainly need more planning and figuring out what shall happen if the 
optimized bytecode is not there and users actually run Python with -O or -OO, 
but we can discusses that if you want.


--
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: Minimization Objective report

[Adam Jackson]

On Fri, 2019-11-15 at 23:38 +0100, Kevin Kofler wrote:
> Adam Samalik wrote:
> > 1/ A history chart for base images [2] is now being generated — includes
> > data since 25 September. It's a bit rough initial implementation, but it's
> > there!
> 
> Almost 2 months of work to save… 0.5%! That does not look like a huge 
> success to me. You simply cannot win against the creeping bloat. :-(

Ahem.

In the spirit of positivity and collaboration, I spent a few minutes
looking at the results given to try to find some easy wins. Here's what
I found:

python3-libs ships multiple copies of its pyc files, corresponding to
different optimization levels. I don't know what a good packaging
solution to that would look like, but if we only shipped the -O2 kind
(which seems appropriate for minimization, as they're smallest) we
could drop about 13M out of 32M, which seems pretty great.

About 2/3 of glib2 is translations. If it was langpacked like glibc you
could drop another 8M. Likewise about 9M out of 10M for coreutils-
common, 4.5 out of 7.5 for bash, 4 out of 10 for gnupg2.

You're not using coreutils-single, which would save you another 6M or
so.

It's hard to understand why dejavu-sans-fonts is in there, since there
are zero font libraries installed in the container base. Probably
that's brought in by the langpacks somewhere along the line, but it
seems like fonts and translations should be logically separate here (no
point installing fonts if you're not going to be printing or making
images, right?). That's another 5.5M.

That's about 44M worth of potential savings out of a 204M base image, a
bit over 20%. I'll happily file proper bug reports for these somewhere
if we want, but it took me like 30 minutes to look into this. If you're
not even willing to put in _that_ little effort, then forgive me for
not taking your assertion that "you simply cannot win" very seriously.

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

[Bug 1774197] New: perl-Devel-PatchPerl-1.80 is available

[bugzilla]

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

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



Latest upstream release: 1.80
Current version/release in rawhide: 1.78-1.fc32
URL: http://search.cpan.org/dist/Devel-PatchPerl/

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

-- 
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: Orphaning nm-tray

[Raphael Groner]

…
> But LXDE and nm-applet are GTK, LXQt and nm-tray are Qt.

Right, we've planned to use nm-tray for the LXQt spin. But the package is 
already removed because it never worked as it should. There's indeed not much 
sense to have another tray icon when NetworkManager itself places anyways (by 
enforced dependencies) its own icon aside.

~Raphael
___
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: libdav1d SONAME bump

[Robert-André Mauchin]

On Friday, 18 October 2019 22:44:24 CET you wrote:
> On Friday, 11 October 2019 16:10:55 CEST you wrote:
> > Hello,
> > 
> > Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
> > 2.0.0 to libdav1d.so.3.0.0.
> > I will be updating it next week on F31/32, consumers of these libraries
> > (ffmpeg, xine-lib, vlc) will need to rebuild their packages.
> > 
> > Best regards,
> > 
> > Robert-André
> 
> libdav1d SONAME bumped in F32 and EPEL8. Consumers of this library (ffmpeg,
> xine-lib, vlc), please rebuild your packages.
> 
> I still plan on doing F31 at a later date.
> 
> Best regards,
> 
> Robert-André

I have updated dav1d in F31. 
Please create a buildroot override for it in RPMFusion (dav1d-0.5.1-1.fc31) 
and update the consumers of this library (ffmpeg, xine-lib, vlc).

Best regards,

Robert-André

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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Co on 2019-11-20 from 18:00:00 to 19:00:00 GMT
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. A general agenda is the 
following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-6
#topic EPEL-7
#topic EPEL-8
#topic Openfloor
#endmeeting




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

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

[EPEL-devel] Re: Any plans for supporting multiple python3 versions in EPEL8?

[Orion Poplawski]

On 11/16/19 8:25 AM, Miro Hrončok wrote:
> On 16. 11. 19 3:53, Orion Poplawski wrote:
>>     I'm wondering if anyone can shed any light on possible roadmaps for
>> transitioning to newer python 3.X in RHEL8/EPEL8.  What we have now appears
>> to be:
>>
>> A module for different pythonXY versions:
>>
>> python27 2.7 [d]   common [d]    Python programming
>> language, version 2.7
>> python36 3.6 [d][e]    common [d], build    Python programming
>> language, version 3.6
>>
>> A python3Y base package:
>>
>> python36.x86_64    3.6.8-2.module+el8.1.0+3334+5cb623d7
>>   python36-debug.x86_64
>> 3.6.8-2.module+el8.1.0+3334+5cb623d7  python36-devel.x86_64 
>> 3.6.8-2.module+el8.1.0+3334+5cb623d7   
>> python36-rpm-macros.noarch 3.6.8-2.module+el8.1.0+3334+5cb623d7
>>
>> But python3- modules, including:
>>
>> python3-libs.x86_64    3.6.8-15.1.el8
>> python3-tkinter.x86_64 3.6.8-15.1.el8
>>
>> And since:
>>
>> # rpm -E %python3_pkgversion
>> 3
>>
>> It seems any transition is going to have to be a hard break and/or we're
>> going to need modules.  Is there any hope for parallel installable python3Y
>> stacks in RHEL8?  Are we just going to have python36 forever?
> 
> The EL8 Python modules are planned to be parallel installable.
> That's why the module name is python36, not python or python3.
> 

Okay, but what does that actually get us in practice?  If I have python36 and
python38 installed:

- what verion(s) of python3-libs do I have?
- what version(s) of python modules from EPEL do I have?

With EPEL7 I can have both python34-blah and python36-blah, but with
python3_pkgversion = 3 we just have python3-blah in EPEL8 (currently built for
3.6).


-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



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

Re: What's the State of the Java SIG?

[Fabio Valentini]

On Tue, Nov 19, 2019 at 5:12 PM Aleksandra Fedorova  wrote:
>
> Hi, Fabio,
>
> On Mon, Nov 18, 2019 at 10:30 AM Fabio Valentini  wrote:
>>
>> Hi everybody,
>>
>> You're probably aware that the Stewardship SIG has been picking up
>> some (±230) Java packages to keep them from getting removed from
>> fedora, and to try to keep them maintained. Since the fraction of
>> out-of-date packages has fallen from 70% to 30% (with 0 FTBFS issues
>> left), I think we've done a pretty good job so far.
>

Hi Aleksandra!

> I'd like to make it clear first that the work of Stewardship SIG is highly 
> appreciated. Thank you for doing it.

Thank you. That's good to hear.

>>
>> But, you might ask, wouldn't the Java SIG be well suited to that task?
>> I'm asking myself the same thing, but I feel like I've been shouting
>> into the void for months - according to the Wiki page for the SIG [0],
>> the Java SIG has 26 listed members, of which I only recognise 4-5 as
>> packagers who are still actively contributing to fedora. For a few
>> others, I've already gone through the Non-responsive Maintainer
>> process.
>>
>> Both the page for the Java SIG [0] and Java in fedora [1] look like
>> they haven't been updated in years - they even list some things as
>> "wishlisted" or "in progress" which were packaged for fedora a while
>> ago, but have since been retired again, either due to getting
>> orphaned, or due to FTBFS issues — most of which were being caused by
>> a lack of maintenance since circa 2017, which is when most Java
>> packagers seem to have fallen into a black hole, as far as I can tell
>> (getting information by deciphering Hawking Radiation is hard, you
>> know).
>>
>> So, I'm wondering - what's *actually* the state of the Java SIG? The
>> IRC channel is silent, the Mailing list is dead except 0-2 posts *PER
>> MONTH* (mostly from non-SIG members), and the Wiki pages are wildly
>> out of date.
>>
>> Can we at least get the two Wiki pages get updated to the current state?
>> Does the Java ecosystem on fedora need more involvement from the community?
>> Or is it time for a "tabula rasa" and restart the SIG?
>>
>> I really hope we can get something off the ground, soon - because I
>> and other members of the Stewardship SIG have been spending a lot of
>> hours each week on keeping this stuff working, but my patience and
>> energy are reaching their limits. I'd really like to slowly start
>> handing over Java packages to someone who's actually using them, and
>> is interested in keeping them maintained.
>
>
> I agree with your point that Stewardship SIG supposed to be only a temporary 
> owner of certain packages. The goal of the SIG is to step in if there is a 
> critical unresolved issue in the current state, and then route the issue to 
> the right owner.
>
> >  So, if you're an active member of the Java SIG, or a (proven)packager
> > interested in Java packaging on fedora, please speak up - maybe we can
> > get this ball rolling :)
>
> But I'd like to reset the conversation here.
>
> The point of Java SIG and I think the nature of your request to it is not to 
> take the responsibility of packages Stewardship SIG inherited.
>
> Rather we have a generic problem: how one can package and maintain Java stack 
> and Java application in Fedora. Java SIG supposed to be the owner of this 
> topic. It needs to provide the common place for Java developers (app 
> maintainers as well as toolchain maintainers) to communicate to each other 
> and come up with solutions to the common issues.
>
> The way how exactly the issue should be resolved (with or without modules, 
> with or without buildroot packages and so on) is for the Java SIG members to 
> figure out.
>
> Thus, I would suggest to frame the request differently. Instead of asking who 
> can maintain certain non-modular Java packages, let's ask who can describe 
> the path forward for Java-related packages in Fedora, and who is willing to 
> work on it.
>
> I see that Mikolaj has a vision how it supposed to work. And I think he spent 
> quite some time designing the workflow which would fit this vision, thus it 
> is worth to listen to it with an open mind.
>
> @Mikolaj, can you document the setup for java toolchain somewhere other than 
> a mailing list? Buildroot modules, defaults streams, what Java packager 
> should and shouldn't use... Probably one of those outdated wiki pages can be 
> updated for that.

(snip)

> This will create a starting point for this conversation and set the context, 
> so that app maintainers can work constructively with it rather than fall into 
> yet another generic modularity conversation.

I agree, this seems like a productive way forward. It's also the
reason why I didn't want to prominently mention Modularity in the
original message, and instead tried to focus on the issue at hand -
the future of Java packaging in fedora. There also seems to be
conflicting information floating around concerning the Java modules
(maven, ant, 

Re: Modularity and the system-upgrade path

[Kevin Kofler]

Petr Pisar wrote:
> That's nice theory that will never come true becaue it would require to
> make all Perl code parallel-installable. And Perl code is not only
> libraries as in the Python language. That's also myriad of Perl scripts
> that you want to have in PATH.

But the scripts do not need to care about the version of Perl you are 
running, do they? It matters for compiled code, but why for Perl scripts? 
Those can just run with the default version of Perl if they support it, or 
with the shebang line changed to something like #!/usr/bin/perl5.30 if 
that's what they require.

> If you start fidling with things in PATH, you have the problem of SCL. And
> as you wrote, SCL is terrible. And that was the reason why we have
> modularity: We do not want to relocate code to non-standard paths.

I agree that the SCL approach is not optimal, but letting the versions just 
conflict is much worse!

The best way to deal with conflicts in PATH is to suffix the binaries, not 
to move them. But that is only needed when it makes a difference for the end 
user which version they run. If the executable script "foo" does the exact 
same thing when run under Perl 5.28 or 5.30, then you need only one 
/usr/bin/foo set up to run against the distribution default Perl, the other 
one is redundant (which is the nice thing about parallel installation: you 
do not have to support running all the executables under a non-default Perl, 
only those that actually need it).

> I think it's inevitable that there will be conflicts and it's better to
> have them managable with a package manager (i.e. having default
> streams) rather crates few modules that silently overlay non-modular
> packages whe a user enables them.
> 
> The parallel installablity is nice, but it's way more difficult than
> parallel availability.

I think that any model that has conflicts is not workable for the Fedora 
user base. Desktops and small servers are not normally containerized, so 
being able to install different applications without conflict is a non-
negotiable requirement.

I see only 2 ways to provide a newer Perl for Fedora:
1. as a parallel-installable compatibility package, or
2. as a grouped official Bodhi update including a rebuild of all packages
   depending on the old Perl ABI
(and only the first one is suitable if you wish to provide an older Perl, 
because you should not be downgrading the system Perl).
Failing those, the only option is really:
3. just don't do it.

Providing a perl:5.30 module replacing the system Perl (and breaking 
everything in the distro depending on it) is essentially useless and does 
not provide much value over option 3.

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: What's the State of the Java SIG?

[Aleksandra Fedorova]

Hi, Fabio,

On Mon, Nov 18, 2019 at 10:30 AM Fabio Valentini 
wrote:

> Hi everybody,
>
> You're probably aware that the Stewardship SIG has been picking up
> some (±230) Java packages to keep them from getting removed from
> fedora, and to try to keep them maintained. Since the fraction of
> out-of-date packages has fallen from 70% to 30% (with 0 FTBFS issues
> left), I think we've done a pretty good job so far.
>

I'd like to make it clear first that the work of Stewardship SIG is highly
appreciated. Thank you for doing it.


> But, you might ask, wouldn't the Java SIG be well suited to that task?
> I'm asking myself the same thing, but I feel like I've been shouting
> into the void for months - according to the Wiki page for the SIG [0],
> the Java SIG has 26 listed members, of which I only recognise 4-5 as
> packagers who are still actively contributing to fedora. For a few
> others, I've already gone through the Non-responsive Maintainer
> process.
>
> Both the page for the Java SIG [0] and Java in fedora [1] look like
> they haven't been updated in years - they even list some things as
> "wishlisted" or "in progress" which were packaged for fedora a while
> ago, but have since been retired again, either due to getting
> orphaned, or due to FTBFS issues — most of which were being caused by
> a lack of maintenance since circa 2017, which is when most Java
> packagers seem to have fallen into a black hole, as far as I can tell
> (getting information by deciphering Hawking Radiation is hard, you
> know).
>
> So, I'm wondering - what's *actually* the state of the Java SIG? The
> IRC channel is silent, the Mailing list is dead except 0-2 posts *PER
> MONTH* (mostly from non-SIG members), and the Wiki pages are wildly
> out of date.
>
> Can we at least get the two Wiki pages get updated to the current state?
> Does the Java ecosystem on fedora need more involvement from the community?
> Or is it time for a "tabula rasa" and restart the SIG?
>
> I really hope we can get something off the ground, soon - because I
> and other members of the Stewardship SIG have been spending a lot of
> hours each week on keeping this stuff working, but my patience and
> energy are reaching their limits. I'd really like to slowly start
> handing over Java packages to someone who's actually using them, and
> is interested in keeping them maintained.
>

I agree with your point that Stewardship SIG supposed to be only a
temporary owner of certain packages. The goal of the SIG is to step in if
there is a critical unresolved issue in the current state, and then route
the issue to the right owner.

>  So, if you're an active member of the Java SIG, or a (proven)packager
> interested in Java packaging on fedora, please speak up - maybe we can
> get this ball rolling :)

But I'd like to reset the conversation here.

The point of Java SIG and I think the nature of your request to it is not
to take the responsibility of packages Stewardship SIG inherited.

Rather we have a generic problem: how one can package and maintain Java
stack and Java application in Fedora. Java SIG supposed to be the owner of
this topic. It needs to provide the common place for Java developers (app
maintainers as well as toolchain maintainers) to communicate to each other
and come up with solutions to the common issues.

The way how exactly the issue should be resolved (with or without modules,
with or without buildroot packages and so on) is for the Java SIG members
to figure out.

Thus, I would suggest to frame the request differently. Instead of asking
who can maintain certain non-modular Java packages, let's ask who can
describe the path forward for Java-related packages in Fedora, and who is
willing to work on it.

I see that Mikolaj has a vision how it supposed to work. And I think he
spent quite some time designing the workflow which would fit this vision,
thus it is worth to listen to it with an open mind.

@Mikolaj, can you document the setup for java toolchain somewhere other
than a mailing list? Buildroot modules, defaults streams, what Java
packager should and shouldn't use... Probably one of those outdated wiki
pages can be updated for that.

This will create a starting point for this conversation and set the
context, so that app maintainers can work constructively with it rather
than fall into yet another generic modularity conversation.

PS, side note about Modularity: If I understand the current state of
> things correctly, the plan is to make the "maven:3.5" and "ant:1.10"
> modular packages be installable alongside non-modular Java packages.
> They're currently shadowing non-modular packages (since they have
> default streams), but I understand this is getting fixed. This means
> that the non-modular Java packages (especially maven, ant, xmvn, their
> dependencies, and other packages which are used for building Java RPM
> packages in fedora) will need to be maintained as non-modular packages
> indefinitely.
>

-- 
Aleksandra Fedorova
bookwar

Re: Orphaning my packages

[Sandro Bonazzola]

Il giorno mar 19 nov 2019 alle ore 16:19 Sandro Bonazzola <
sbona...@redhat.com> ha scritto:

>
>
> Il giorno mar 19 nov 2019 alle ore 15:20 Roman Mohr 
> ha scritto:
>
>> Hi,
>>
>> I take [1] as the opportunity  to orphan the following packages:
>>
>> rpms/aspectjweaver
>> rpms/assertj-core
>> rpms/hystrix
>> rpms/memoryfilesystem
>> rpms/rxjava
>> rpms/archaius
>>
>
> I need to check with oVirt infra team, but I guess I'll take them.
>
>
> * *
Not going to be needed anymore in oVirt so not taking them and letting them
become orphans.
___
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: Orphaning my packages

[Sandro Bonazzola]

Il giorno mar 19 nov 2019 alle ore 15:20 Roman Mohr  ha
scritto:

> Hi,
>
> I take [1] as the opportunity  to orphan the following packages:
>
> rpms/aspectjweaver
> rpms/assertj-core
> rpms/hystrix
> rpms/memoryfilesystem
> rpms/rxjava
> rpms/archaius
>

I need to check with oVirt infra team, but I guess I'll take them.


>
> I don't use these projects anymore, and I don't have time to follow them.
>
> Best Regards,
> Roman
>
> [1] https://pagure.io/fesco/issue/2280
>
> ___
> 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
>


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com
*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.
*
___
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-java] What's the State of the Java SIG?

[Aleksandar Kurtakov]

On Tue, Nov 19, 2019 at 4:54 PM Stephen John Smoogen 
wrote:

> On Tue, 19 Nov 2019 at 09:17, Gerald Henriksen  wrote:
> >
> > On Mon, 18 Nov 2019 21:08:02 -0800, you wrote:
> >
> > >On 11/18/19 7:29 PM, Neal Gompa wrote:
> > >> I can't speak for everyone, but at least my experience was that it was
> > >> functionally impossible to discover how to package Java stuff. In a
> > >> lifetime (and a job) ago, I was much more engaged in the Java
> > >> ecosystem. Back then, I tried to learn how to package and ship Java
> > >> stuff in Fedora. But the documentation was (and still is) incredibly
> > >> poor. I only managed to package one library, and it was not easy for
> > >> me to figure out how to do it. The amount of effort I expended to do
> > >> it put me off to doing more in the Java ecosystem.
> > >
> > >Maybe I misunderstood the earlier comment.  I understand that Java can
> > >be difficult to package, but I thought Gerald was saying that using
> > >modules somehow made it easier.
> >
> > I have no idea whether modules make it easier or not.
> >
> > My point was that the Java SIG collapsed long before the modules
> > became an issue, so "rebooting" the Java SIG isn't going to change
> > anything unless those calling for the reboot come up with packagers
> > for the Java ecosystem.
> >
>
> Let us be clear here.. Java and Fedora have never done well. The
> original 'Everything must be broken into separate parts and
> integrated' vs 'the ecosystem bundles everything' was with Java and
> made anyone working with Java in Fedora grind teeth on either being
> way behind on some software or not having it all in Fedora. The
> problem is that work was unmaintainable especially when the entire
> ecosystem is built around having bundles of software where you only
> needed 1-2 classes from a specific zip. Then there is a bunch of stuff
> in these languages where you need to rebuild things in a specific
> order or multiple times or a dozen other things using tools you need
> but no one is maintaining. The original SIG was a bunch of hero
> maintainers who said 'ok I am going to make this happen' and put in a
> hell of an effort to get a lot of stuff unbundled and integrated. [At
> the time in I think Fedora 8-10 timeframe, there was a large push by
> certain people to get rid of all Java from the OS because it could not
> be properly integrated. ]
>
> Over time these hero's burnt out just like the hero's who have
> maintained perl, php, TeX, Nodejs, and many other stacks have.
> Modules are basically a last gasp for them to trying to keep this
> maintainable for the last hero maintainers. They allow for you to spec
> out a lot of grunt work of building X before Y so you can rebuild Y
> with X. They allow you to say I needed this thing but I am not
> maintaining it so I am not shipping it... if someone will take it over
> I can remove that hidden part but I don't have time to keep this up.
>
> It isn't just a matter of trying to build a team to maintain these...
> it is a lot of work dealing with things volunteer packagers* don't
> have time for:
>  o) Documenting each package
>  o) Documenting how to break apart X into usable rpm packages
>  o) Writing scripts to try and automate that in the rpmbuild parts
>  o) Deal with the fact that every upstream software is slightly
> different (aka perl Makefile.pl output is never the same)
>  o) Keep up with the fact that every other upstream release has
> decided to add N dependencies which are either not in Fedora or not
> the version in Fedora.
>
> Doing this with a team means a lot of time coordinating with each
> other. That means spending a lot of time in meetings with each other
> or ending getting burnt too many times with Packager B updating Y
> which breaks your Z. [Modular streams are supposed to help you on
> this.. but it just makes it a combinatoric headache you have to deal
> with even more meetings to keep from happening.] Most volunteers don't
> like meetings, and they usually don't have time for them.. so we end
> up with a very fractured space. Most of the problems we are seeing
> with modules are from fractures already there but only shown when
> FTBFS happened in the past.
>
> * I am going to be very clear here. Even if Red Hat pays someone a
> salary, most of our work on Fedora is volunteer time. Our main job is
> probably only related to the packages we put in by the fact we need it
> to complete said job. We usually don't have time to much more than
> people who have weekends on something.
>


Couldn't have expressed better what I think !!!


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

Re: [fedora-java] What's the State of the Java SIG?

[Stephen John Smoogen]

On Tue, 19 Nov 2019 at 09:17, Gerald Henriksen  wrote:
>
> On Mon, 18 Nov 2019 21:08:02 -0800, you wrote:
>
> >On 11/18/19 7:29 PM, Neal Gompa wrote:
> >> I can't speak for everyone, but at least my experience was that it was
> >> functionally impossible to discover how to package Java stuff. In a
> >> lifetime (and a job) ago, I was much more engaged in the Java
> >> ecosystem. Back then, I tried to learn how to package and ship Java
> >> stuff in Fedora. But the documentation was (and still is) incredibly
> >> poor. I only managed to package one library, and it was not easy for
> >> me to figure out how to do it. The amount of effort I expended to do
> >> it put me off to doing more in the Java ecosystem.
> >
> >Maybe I misunderstood the earlier comment.  I understand that Java can
> >be difficult to package, but I thought Gerald was saying that using
> >modules somehow made it easier.
>
> I have no idea whether modules make it easier or not.
>
> My point was that the Java SIG collapsed long before the modules
> became an issue, so "rebooting" the Java SIG isn't going to change
> anything unless those calling for the reboot come up with packagers
> for the Java ecosystem.
>

Let us be clear here.. Java and Fedora have never done well. The
original 'Everything must be broken into separate parts and
integrated' vs 'the ecosystem bundles everything' was with Java and
made anyone working with Java in Fedora grind teeth on either being
way behind on some software or not having it all in Fedora. The
problem is that work was unmaintainable especially when the entire
ecosystem is built around having bundles of software where you only
needed 1-2 classes from a specific zip. Then there is a bunch of stuff
in these languages where you need to rebuild things in a specific
order or multiple times or a dozen other things using tools you need
but no one is maintaining. The original SIG was a bunch of hero
maintainers who said 'ok I am going to make this happen' and put in a
hell of an effort to get a lot of stuff unbundled and integrated. [At
the time in I think Fedora 8-10 timeframe, there was a large push by
certain people to get rid of all Java from the OS because it could not
be properly integrated. ]

Over time these hero's burnt out just like the hero's who have
maintained perl, php, TeX, Nodejs, and many other stacks have.
Modules are basically a last gasp for them to trying to keep this
maintainable for the last hero maintainers. They allow for you to spec
out a lot of grunt work of building X before Y so you can rebuild Y
with X. They allow you to say I needed this thing but I am not
maintaining it so I am not shipping it... if someone will take it over
I can remove that hidden part but I don't have time to keep this up.

It isn't just a matter of trying to build a team to maintain these...
it is a lot of work dealing with things volunteer packagers* don't
have time for:
 o) Documenting each package
 o) Documenting how to break apart X into usable rpm packages
 o) Writing scripts to try and automate that in the rpmbuild parts
 o) Deal with the fact that every upstream software is slightly
different (aka perl Makefile.pl output is never the same)
 o) Keep up with the fact that every other upstream release has
decided to add N dependencies which are either not in Fedora or not
the version in Fedora.

Doing this with a team means a lot of time coordinating with each
other. That means spending a lot of time in meetings with each other
or ending getting burnt too many times with Packager B updating Y
which breaks your Z. [Modular streams are supposed to help you on
this.. but it just makes it a combinatoric headache you have to deal
with even more meetings to keep from happening.] Most volunteers don't
like meetings, and they usually don't have time for them.. so we end
up with a very fractured space. Most of the problems we are seeing
with modules are from fractures already there but only shown when
FTBFS happened in the past.

* I am going to be very clear here. Even if Red Hat pays someone a
salary, most of our work on Fedora is volunteer time. Our main job is
probably only related to the packages we put in by the fact we need it
to complete said job. We usually don't have time to much more than
people who have weekends on something.




-- 
Stephen J Smoogen.
___
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-java] What's the State of the Java SIG?

[Gerald Henriksen]

On Mon, 18 Nov 2019 21:08:02 -0800, you wrote:

>On 11/18/19 7:29 PM, Neal Gompa wrote:
>> I can't speak for everyone, but at least my experience was that it was
>> functionally impossible to discover how to package Java stuff. In a
>> lifetime (and a job) ago, I was much more engaged in the Java
>> ecosystem. Back then, I tried to learn how to package and ship Java
>> stuff in Fedora. But the documentation was (and still is) incredibly
>> poor. I only managed to package one library, and it was not easy for
>> me to figure out how to do it. The amount of effort I expended to do
>> it put me off to doing more in the Java ecosystem.
>
>Maybe I misunderstood the earlier comment.  I understand that Java can 
>be difficult to package, but I thought Gerald was saying that using 
>modules somehow made it easier.

I have no idea whether modules make it easier or not.

My point was that the Java SIG collapsed long before the modules
became an issue, so "rebooting" the Java SIG isn't going to change
anything unless those calling for the reboot come up with packagers
for the Java ecosystem.

And one of the reasons few want to package Java stuff is that because
for most of the Java stuff the users prefer to simply install the
provided jdk/jre and then download the jar files from upstream,
because by using official upstream provided jar files they can get
help from upstream with any problems.
___
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

Orphaning my packages

[Roman Mohr]

Hi,

I take [1] as the opportunity  to orphan the following packages:

rpms/aspectjweaver
rpms/assertj-core
rpms/hystrix
rpms/memoryfilesystem
rpms/rxjava
rpms/archaius

I don't use these projects anymore, and I don't have time to follow them.

Best Regards,
Roman

[1] https://pagure.io/fesco/issue/2280
___
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: What are the benefits of default modular streams over non-modular packages?

[Nico Kadel-Garcia]

On Mon, Nov 18, 2019 at 6:23 AM Mikolaj Izdebski  wrote:
>
> On Thu, Nov 14, 2019 at 4:59 PM Miro Hrončok  wrote:
> > I've asked whether it wouldn't be in fact much easier to keep the default
> > versions of our packages non-modular.
> >
> > Others have said they are interested in this as well. A huge thread 
> > happened but
> > it hasn't delivered an answer.
> > Arguments were made that default modular streams are planned to deliver the
> > exact same experience as non-modular packages, yet it was not said if it
> > wouldn't be easier to just deliver non-modular packages for default 
> > versions.
> >
> > Maybe it would be helpful to try to reformulate the question:
> >
> >
> > **What are the benefits of default modular streams over non-modular 
> > packages?**
>
> As Petr Pisar noted earlier, default streams are designed to deliver the same
> user experience as ursine packages, therefore there is no *direct* advantage
> or disadvantage of them over ursine packages, for Fedora *users*.

Confusing and inconsistent resolution of dependency chains is a direct
consequence of using modularity. These threads have pointed out
others.

> Default streams are modules. Building packages as modules has very significant
> advantages to some package maintainers. Certain maintainers (like me) can save
> a lot of time by building packages as modules.  This *indirectly*
> benefits users and

Those maintainers are a small though vocal minority. Can anyone name
three packages that genuinely benefit from modularity, rather than
/etc/alternatives, SCL style separate deployment in /opt/. If there
was always a bae installation and modules were, in fact, only an
add-on, that might have been more stable.

> other Fedora contributors - maintainers who can more easily build packages 
> have
> more time to spend on important bugs and features affecting users, can get 
> more
> involved in other Fedora activities etc.

At the cost of the time of *other* package maintainers who have to
deal with the inconsistent dependency resolutions at build and
deployment time. It's not, so far, proven to be a helpful technology.
___
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: What are the benefits of default modular streams over non-modular packages?

[Stephen Gallagher]

On Mon, Nov 18, 2019 at 7:24 AM Kevin Kofler  wrote:
>
> Mikolaj Izdebski wrote:
> > As Petr Pisar noted earlier, default streams are designed to deliver the
> > same user experience as ursine packages, therefore there is no *direct*
> > advantage or disadvantage of them over ursine packages, for Fedora
> > *users*.
>
> Sorry, the "no disadvantage" part is just not true:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6KLXZXI777Q7C7MPEO7HHWM7XGVSJVIK/
>

> * introduce upgrade path issues when upgrading to a newer Fedora,

This has been acknowledged as a bug and is on its way to being fixed.

> * make it harder to replace packages with local versions (because the module 
> normally takes precedence over non-modular versions of the same packages),

This is a valid concern and it is one we are investigating a solution
for right now. One possible answer: if the RPM location is specified
directly (URL or filesystem location) assume that the user wants to
override the modular package.

> * may introduce dependency version conflicts due to versioned dependencies on 
> other modules (whereas non-modular packages currently cannot depend on 
> non-default modules, and it should really stay that way), and those are just 
> the 3 obvious issues.

We just adopted the policy that a default module stream may not depend
on any non-default module streams. As long as this is properly
enforced, this issue is addressed already.

> The design fails to deliver on its promise of delivering the exact same user
> experience.
>

This is incorrect. The *implementation* is currently failing to
deliver the same user experience.
___
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 2 exodus is happening now

[Tomas Mraz]

On Fri, 2019-11-15 at 02:02 +0100, Miro Hrončok wrote:
> system-config-rootpassword

Fixed to use python3 in system-config-rootpassword-1.99.6-21.fc32,
please do not retire.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
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] Couple of troubles around using dsconf

[Matus Honek]

Hello folks,

Context: My setup is a running dscontainer with exported /data. While
developing (outside of the container) I am trying to run `dsconf
ldapi://%2fpath%2fto%2fdscontainers%2fsocket security get`.

Issue 1: I get IndexError exception:
  File "/home/mhonek/src/ds/up/src/lib389/lib389/_mapped_object.py",
line 158, in display
How to fix the fact we can get no results to display, and to fix it
correctly so that nothing else eventually blows up? Don't know...

Issue 2: Tracing back I find out I autobinded as non-root (non 0 UID).
Expectable, but still unexpected. So I tried to override this by
providing `-D` and `-w` explicitly to dsconf. No change, still
autobinding. Turns out the autobind has preference over simple bind in
DirSrv.open, this comes from [implementation].
Possible solution: Instead of `elif can_autobind(): ... else:
simple_bind` do `elif self.binddn is not None: ... else
can_autobind(): ...`. Worked for me. Would this blow up some use-case?
Don't know...

Sub-issue 2a: Given I was able to autobind as non-root UID, the
wording in a log message [aubind-log]. The word "root" probably
shouldn't be there?

Somewhat troubling 1: At the time of running open in the autobind
branch in DirSrv.open [autobind] the value of `self.bindpw` is
literally "password" even though no `-D` nor `-w` was provided on
command line for dsconf. I believe there are some reasons (besides
"because the code is written so") why this is so but I would like to
be enlightened here.

[implementation] https://pagure.io/389-ds-base/c/e07e489
[autobind-log] 
https://pagure.io/389-ds-base/blob/6d70cbe/f/src/lib389/lib389/__init__.py#_1063
[autobind] 
https://pagure.io/389-ds-base/blob/6d70cbe/f/src/lib389/lib389/__init__.py#_1060

Please, share your ideas, where I went wrong, what we could go ahead with.

Thanks,
Matus

-- 
Matúš Honěk
Software Engineer
Red Hat Czech
___
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: Modularity and the system-upgrade path

[Petr Pisar]

On 2019-11-19, Igor Gnatenko  wrote:
> Yes, but what you have described is basically to create 2 streams of
> perl-Sys-Virt module. Which is probably not what normal people want.

Having two different perl-Sys-Virt packages was requesed by
Daniel. That was not my choice.

> Creating module for one package is the worst idea ever.
>
Matter of opinion.

> Sure, bundling perl-Sys-Virt into the libvirt module would solve the
> problem, but then what's the point of modules? You will be building
> libvirt itself then multiple times due to the stream expansion.
> 
Then put perl-Sys-Virt into a separat module.

And please to do not top-post.

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

[Petr Pisar]

On 2019-11-18, Kevin Kofler  wrote:
> Petr Pisar wrote:
>> In your example the the packager maintains 4 versions (in the sense of
>> dist-git branches and builds submitted to Koji) of the software
>> (FXX fish 3, FXX+1 fish 4, stream 3 fish 3, stream 4 fish 4).
>> 
>> That's exactly what you as a package does not want. Igor's approach
>> enabled you to offer the same set of fishes with only two branches.
>
> 2 of the branches would be trivial merges or cherry picks from the other 2 
> branches. I do not see the issue.
>
Manual work. Random commiters skipping them.

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

[Bug 1773920] Upgrade perl-Prima to 1.57

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |DUPLICATE
Last Closed||2019-11-19 11:36:34



--- Comment #1 from Petr Pisar  ---


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

-- 
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 1773353] perl-Prima-1.57 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||jples...@redhat.com



--- Comment #2 from Petr Pisar  ---
*** Bug 1773920 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

Re: Modularity and the system-upgrade path

[Igor Gnatenko]

Yes, but what you have described is basically to create 2 streams of
perl-Sys-Virt module. Which is probably not what normal people want.
Creating module for one package is the worst idea ever.

Sure, bundling perl-Sys-Virt into the libvirt module would solve the
problem, but then what's the point of modules? You will be building
libvirt itself then multiple times due to the stream expansion.

On Tue, Nov 19, 2019 at 11:38 AM Petr Pisar  wrote:
>
> On 2019-11-15, Igor Gnatenko  wrote:
> > On Fri, Nov 15, 2019, 17:38 Petr Pisar  wrote:
> >> On 2019-11-15, Daniel P  Berrang=C3=A9  wrote:
> >> >
> >> > Consider if we move the virtualization stack (QEMU & Libvirt) into a
> >> > module with two streams, one libvirt 5.8.0 and one libvirt 6.1.0.
> >> >
> >> > Now we want to build Perl bindings for libvirt. We'll need the
> >> > corresponding version of perl-Sys-Virt either 5.8.0 or 6.1.0,
> >> > built for each virt module stream, but also built for each Perl
> >> > module stream 5.26 / 5.30. eg the combinatorial expansion
> >> >
> >> >  -   perl-Sys-Virt 5.8.0   with libvirt 5.9.0 with perl 5.26
> >> >  -   perl-Sys-Virt 5.8.0   with libvirt 5.9.0 with perl 5.30
> >> >  -   perl-Sys-Virt 6.1.0   with libvirt 6.1.0 with perl 5.26
> >> >  -   perl-Sys-Virt 6.1.0   with libvirt 6.1.0 with perl 5.30
> [...]
> > The problem described by Daniel was that Perl module should be different
> > version when building against 5.x libvirt.
> >
> >> Example: Let's say you have libvirt module with 5.8.0 and 6.1.0 streams
> >> and perl module with 5.26 and 5.30 streams. If you add perl-Sys-Virt
> >> into a new module, you write a modulemd file for it like this:
> >>
> >> - buildrequiers:
> >> libvirt: [5.8.0, 6.1.0]
> >> perl: [5.26, 5.30]
> >> platform: [f32]
> >>   requires:
> >> libvirt: [5.8.0, 6.1.0]
> >> perl: [5.26, 5.30]
> >> platform: [f32]
> >>
> You are right. Then either you put perl-Sys-Virt 5.8.0 into
> a perl-Sys-Virt:5.8.0 stream with this dependency specification:
>
> - buildrequiers:
> libvirt: [5.9.0]
> perl: [5.26, 5.30]
> platform: [f32]
>   requires:
> libvirt: [5.9.0]
> perl: [5.26, 5.30]
> platform: [f32]
>
> and perl-Sys-Virt 6.1.0 package into perl-Sys-Virt:6.1.0 stream with:
>
> - buildrequiers:
> libvirt: [6.1.0]
> perl: [5.26, 5.30]
> platform: [f32]
>   requires:
> libvirt: [6.1.0]
> perl: [5.26, 5.30]
> platform: [f32]
>
> Or you put perl-Sys-Virt package into libvirt module and for
> libvirt:5.9.0 stream you write:
>
> - buildrequiers:
> perl: [5.26, 5.30]
> platform: [f32]
>   requires:
> perl: [5.26, 5.30]
> platform: [f32]
>
> and for libvirt:6.1.0 stream you do the same.
>
> What approach you want to choose probably depends on compatibility
> among perl-Sys-Virt package versions and among libvirt versions. And how
> often they are released.
>
> I.e. if you can rebase perl-Sys-Virt inside libvirt stream because
> perl-Sys-Virt does not break ABI, then it makes sense to keep it inside
> libvirt module. That's because public ABI of a module should not change
> inside a stream.
>
> You can also consider how expensive is to build, test and deliver the
> libvirt module. If e.g. building perl-Sys-Virt were much quicker than
> building libvirt, and there were plenty of perl streams, then it would
> make sense to move perl-Sys-Virt package into its own module.
>
> I think it's a similar problem as to when bundle all dependencies into
> one package and when to aim for splitting it into muliple independent
> packages.
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1771705] [RFE] EPEL8 branch of perl-HTTP-Entity-Parser

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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

-- 
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: Modularity and the system-upgrade path

[Petr Pisar]

On 2019-11-16, Kevin Kofler  wrote:
> Petr Pisar wrote:
>> With your proposal Bugzilla packager would have to package Bugzilla
>> twice: as a normal package for default Perl 5.26 and as a module for Perl
>> 5.30. Then a user would have hard time to select the right combinations of
>> Perl and Bugzilla. It would double fork work pacakgers and and make
>> the system more dificult for users.
>
> The Bugzilla rebuild for the non-default Perl actually belongs IN the Perl 
> module. Otherwise, enabling the non-default stream for the Perl module will 
> break the user's Bugzilla and force them to manually enable the 
> corresponding non-default stream for the Bugzilla module. Plus, since there 
> are many Perl applications, having a module for each of them (each tracking 
> Perl's module streams) just does not scale.
> 
Adding Bugzilla in Perl module does not scale either. You have many Perl
applications and you should put them all into the Perl module. As
a result you would have a Perl module containing all Perl applications.
We now more than 3000 such packages. You can imagine that you were never
be eable to build such a giant module because there is always a package
that fails to build. Also whenever you want to provide a new
incompatible application you would have to fork the giant Perl module.
Do you want to have perl:5.30-with-Bugzilla-5.1.2-with-slic3r-1.3.0-...?

I believe that better approach is to meld modularity into RPM. So that
you can have plenty of small independent packages aware of parallel
availability.

> But what this example really shows is that it is a horrible idea to have a 
> Perl module to begin with. The non-default Perl needs to be packaged as a 
> parallel-installable compatibility package (or as an SCL, but that opens its 
> own can of worms) instead. You cannot just replace a language interpreter 
> (especially not one as widely used as Perl) with a different version. (As 
> you pointed out yourself, that breaks even fedpkg. Even though fedpkg itself 
> is not even written in Perl!) The parallel-installable approach is also the 
> only reasonable way to support applications that require a non-default 
> version of Perl, without conflicting with the rest of the distribution.
>
That's nice theory that will never come true becaue it would require to
make all Perl code parallel-installable. And Perl code is not only
libraries as in the Python language. That's also myriad of Perl scripts
that you want to have in PATH. If you start fidling with things in PATH,
you have the problem of SCL. And as you wrote, SCL is terrible. And that
was the reason why we have modularity: We do not want to relocate code
to non-standard paths.

I think it's inevitable that there will be conflicts and it's better to
have them managable with a package manager (i.e. having default
streams) rather crates few modules that silently overlay non-modular
packages whe a user enables them.

The parallel installablity is nice, but it's way more difficult than
parallel availability.

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

[Bug 1773830] perl-Term-Table-0.015 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC||jples...@redhat.com



--- Comment #5 from Jitka Plesnikova  ---
*** Bug 1773921 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 1773921] Upgrade perl-Term-Table to 0.015

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |DUPLICATE
Last Closed||2019-11-19 10:36:34



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


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

-- 
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 1773921] New: Upgrade perl-Term-Table to 0.015

[bugzilla]

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

Bug ID: 1773921
   Summary: Upgrade perl-Term-Table to 0.015
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Term-Table
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.014 version. Upstream released 0.015. When you have
free time, please upgrade it.

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

[Bug 1773920] New: Upgrade perl-Prima to 1.57

[bugzilla]

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

Bug ID: 1773920
   Summary: Upgrade perl-Prima to 1.57
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Prima
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: lkund...@v3.sk, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 1.56 version. Upstream released 1.57. When you have free
time, please upgrade it.

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

Re: Modularity and the system-upgrade path

[Petr Pisar]

On 2019-11-15, Igor Gnatenko  wrote:
> On Fri, Nov 15, 2019, 17:38 Petr Pisar  wrote:
>> On 2019-11-15, Daniel P  Berrang=C3=A9  wrote:
>> >
>> > Consider if we move the virtualization stack (QEMU & Libvirt) into a
>> > module with two streams, one libvirt 5.8.0 and one libvirt 6.1.0.
>> >
>> > Now we want to build Perl bindings for libvirt. We'll need the
>> > corresponding version of perl-Sys-Virt either 5.8.0 or 6.1.0,
>> > built for each virt module stream, but also built for each Perl
>> > module stream 5.26 / 5.30. eg the combinatorial expansion
>> >
>> >  -   perl-Sys-Virt 5.8.0   with libvirt 5.9.0 with perl 5.26
>> >  -   perl-Sys-Virt 5.8.0   with libvirt 5.9.0 with perl 5.30
>> >  -   perl-Sys-Virt 6.1.0   with libvirt 6.1.0 with perl 5.26
>> >  -   perl-Sys-Virt 6.1.0   with libvirt 6.1.0 with perl 5.30
[...]
> The problem described by Daniel was that Perl module should be different
> version when building against 5.x libvirt.
>
>> Example: Let's say you have libvirt module with 5.8.0 and 6.1.0 streams
>> and perl module with 5.26 and 5.30 streams. If you add perl-Sys-Virt
>> into a new module, you write a modulemd file for it like this:
>>
>> - buildrequiers:
>> libvirt: [5.8.0, 6.1.0]
>> perl: [5.26, 5.30]
>> platform: [f32]
>>   requires:
>> libvirt: [5.8.0, 6.1.0]
>> perl: [5.26, 5.30]
>> platform: [f32]
>>
You are right. Then either you put perl-Sys-Virt 5.8.0 into
a perl-Sys-Virt:5.8.0 stream with this dependency specification:

- buildrequiers:
libvirt: [5.9.0]
perl: [5.26, 5.30]
platform: [f32]
  requires:
libvirt: [5.9.0]
perl: [5.26, 5.30]
platform: [f32]

and perl-Sys-Virt 6.1.0 package into perl-Sys-Virt:6.1.0 stream with:

- buildrequiers:
libvirt: [6.1.0]
perl: [5.26, 5.30]
platform: [f32]
  requires:
libvirt: [6.1.0]
perl: [5.26, 5.30]
platform: [f32]

Or you put perl-Sys-Virt package into libvirt module and for
libvirt:5.9.0 stream you write:

- buildrequiers:
perl: [5.26, 5.30]
platform: [f32]
  requires:
perl: [5.26, 5.30]
platform: [f32]

and for libvirt:6.1.0 stream you do the same.

What approach you want to choose probably depends on compatibility
among perl-Sys-Virt package versions and among libvirt versions. And how
often they are released.

I.e. if you can rebase perl-Sys-Virt inside libvirt stream because
perl-Sys-Virt does not break ABI, then it makes sense to keep it inside
libvirt module. That's because public ABI of a module should not change
inside a stream.

You can also consider how expensive is to build, test and deliver the
libvirt module. If e.g. building perl-Sys-Virt were much quicker than
building libvirt, and there were plenty of perl streams, then it would
make sense to move perl-Sys-Virt package into its own module.

I think it's a similar problem as to when bundle all dependencies into
one package and when to aim for splitting it into muliple independent
packages.

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

[Bug 1773915] New: Upgrade perl-MooX-late to 0.016

[bugzilla]

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

Bug ID: 1773915
   Summary: Upgrade perl-MooX-late to 0.016
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-MooX-late
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.015 version. Upstream released 0.016. When you have
free time, please upgrade it.

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

Re: Modularity and the system-upgrade path

[Petr Pisar]

On 2019-11-15, Przemek Klosowski via devel  
wrote:
> Of course in practice the combinatorial behavior only happens within the 
> subsets of software that depend on each other, but, nevertheless, it 
> seems to me that this means that we have to control and limit the number 
> of interdependent modules drastically, like to single digits.
>
When it matters, maintainers can limit the number of combinations. E.g.
you can restrict to 2 combinations like this:

- buildrequiers:
libvirt: [5.8.0]
perl: [5.26]
platform: [f32]
  requires:
libvirt: [5.8.0]
perl: [5.26]
platform: [f32]
- buildrequiers:
libvirt: [6.1.0]
perl: [5.30]
platform: [f32]
  requires:
libvirt: [6.1.0]
perl: [5.30]
platform: [f32]

But don't forget that if a built module can actually work with many
streams at run-time, you cam simplify it like this:

- buildrequiers:
libvirt: [5.8.0]
perl: [5.26, 5.30]
platform: [f32]
  requires:
libvirt: [5.8.0, 6.1.0]
perl: [5.26, 5.30]
platform: [f32]

This declares that you want to make two builds and each of the builds
will be compatible with both libvirt streams. This is what Java modules
often do.

> we haven't found the right abstraction for dealing with software
> versioning yet.
>
I'm pessimistic. Fedora as any binary distribution distributes binaries.
ABI changes usually proliferate quicker than API incompatibilities.
That's why e.g. Gentoo does not have this issue because there you simply
put "spec files" for multiple versions into a repository and the exact
binary combination is formed at installation time on a user's machine.
There is missing "Koji" in the the distribution chain.

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

pghmcfc pushed to perl-HTTP-Entity-Parser (epel8). "Update to 0.21."

[notifications]

Notification time stamped 2019-11-19 10:04:21 UTC

From d1516812796ec821ee78fe9be2dfa637cb59f422 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius 
Date: Mar 04 2018 18:18:55 +
Subject: Update to 0.21.


---

diff --git a/.gitignore b/.gitignore
index 7a9712a..f380dc3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTTP-Entity-Parser-0.20.tar.gz
+/HTTP-Entity-Parser-0.21.tar.gz
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index c7c36cc..8d969a3 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,13 +1,16 @@
 Name:   perl-HTTP-Entity-Parser
-Version:0.20
-Release:3%{?dist}
+Version:0.21
+Release:1%{?dist}
 Summary:PSGI compliant HTTP Entity Parser
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/HTTP-Entity-Parser/
 Source0:
http://www.cpan.org/authors/id/K/KA/KAZEBURO/HTTP-Entity-Parser-%{version}.tar.gz
 
 BuildArch:  noarch
-BuildRequires:  perl-interpreter >= 0:5.008005
+
+BuildRequires:  %{__perl}
+
+BuildRequires:  perl-interpreter >= 0:5.008001
 BuildRequires:  perl-generators
 
 BuildRequires:  perl(Carp)
@@ -66,6 +69,9 @@ data and application/json.
 %{_mandir}/man3/*
 
 %changelog
+* Sun Mar 04 2018 Ralf Corsépius  - 0.21-1
+- Update to 0.21.
+
 * Thu Feb 08 2018 Fedora Release Engineering  - 
0.20-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
 
diff --git a/sources b/sources
index c86a2bc..1104c2f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (HTTP-Entity-Parser-0.20.tar.gz) = 
c80d9058b8682c51a0fe3669249cc219142e674959237d8ae6bd435afafc16c92a38328329e9b09a25af8a79fec5bf01050145d3c63dd81b15ad9d75946fdfc6
+SHA512 (HTTP-Entity-Parser-0.21.tar.gz) = 
3852741017748205d9e030a6a42d5a949e3497c5e119713d81c9bf6ee42f9a0a822e65f4be9b8785840b6e81841c7715d34aabcb9b8d950611ce528f702fffd1



https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/d1516812796ec821ee78fe9be2dfa637cb59f422?branch=epel8
___
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

pghmcfc pushed to perl-HTTP-Entity-Parser (epel8). "Merge remote-tracking branch 'origin/f28' into epel8"

[notifications]

Notification time stamped 2019-11-19 10:04:21 UTC

From 2500edb24653261a9ec4bd47746869289f83d57a Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Nov 13 2019 10:17:50 +
Subject: Merge remote-tracking branch 'origin/f28' into epel8


---

diff --git a/.gitignore b/.gitignore
index e69de29..f380dc3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/HTTP-Entity-Parser-0.21.tar.gz
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
new file mode 100644
index 000..8d969a3
--- /dev/null
+++ b/perl-HTTP-Entity-Parser.spec
@@ -0,0 +1,94 @@
+Name:   perl-HTTP-Entity-Parser
+Version:0.21
+Release:1%{?dist}
+Summary:PSGI compliant HTTP Entity Parser
+License:GPL+ or Artistic
+URL:http://search.cpan.org/dist/HTTP-Entity-Parser/
+Source0:
http://www.cpan.org/authors/id/K/KA/KAZEBURO/HTTP-Entity-Parser-%{version}.tar.gz
+
+BuildArch:  noarch
+
+BuildRequires:  %{__perl}
+
+BuildRequires:  perl-interpreter >= 0:5.008001
+BuildRequires:  perl-generators
+
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(Cwd)
+BuildRequires:  perl(Encode)
+BuildRequires:  perl(Exporter)
+BuildRequires:  perl(Fcntl)
+BuildRequires:  perl(File::Basename)
+BuildRequires:  perl(File::Spec::Functions)
+BuildRequires:  perl(File::Temp)
+BuildRequires:  perl(Hash::MultiValue)
+BuildRequires:  perl(HTTP::Headers)
+BuildRequires:  perl(HTTP::Message) >= 6
+BuildRequires:  perl(HTTP::MultiPartParser)
+BuildRequires:  perl(IO::File)
+BuildRequires:  perl(JSON::MaybeXS) >= 1.003007
+BuildRequires:  perl(Module::Build::Tiny) >= 0.035
+BuildRequires:  perl(Module::Load)
+BuildRequires:  perl(Stream::Buffered)
+BuildRequires:  perl(Test::More) >= 0.98
+BuildRequires:  perl(WWW::Form::UrlEncoded) >= 0.23
+
+BuildRequires:  perl(base)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(utf8)
+BuildRequires:  perl(warnings)
+
+Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+
+%description
+HTTP::Entity::Parser is a PSGI-compliant HTTP Entity parser. This module
+also is compatible with HTTP::Body. Unlike HTTP::Body, HTTP::Entity::Parser
+reads HTTP entities from PSGI's environment $env->{'psgi.input'} and parses
+it. This module supports application/x-www-form-urlencoded, multipart/form-
+data and application/json.
+
+%prep
+%setup -q -n HTTP-Entity-Parser-%{version}
+
+%build
+%{__perl} Build.PL --installdirs=vendor
+./Build
+
+%install
+./Build install --destdir=$RPM_BUILD_ROOT --create_packlist=0
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+./Build test
+
+%files
+%doc Changes README.md eg/
+%license LICENSE
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Sun Mar 04 2018 Ralf Corsépius  - 0.21-1
+- Update to 0.21.
+
+* Thu Feb 08 2018 Fedora Release Engineering  - 
0.20-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
+
+* Thu Jul 27 2017 Fedora Release Engineering  - 
0.20-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
+
+* Sun Jul 23 2017 Ralf Corsépius  - 0.20-1
+- Update to 0.20.
+
+* Tue Jun 06 2017 Jitka Plesnikova  - 0.19-2
+- Perl 5.26 rebuild
+
+* Thu Feb 09 2017 Ralf Corsépius  - 0.19-1
+- Upstream update.
+
+* Thu Nov 03 2016 Ralf Corsépius  - 0.18-2
+- Reflect feedback from review.
+
+* Fri Oct 07 2016 Ralf Corsépius  - 0.18-1
+- Initial Fedora package.
diff --git a/sources b/sources
index e69de29..1104c2f 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+SHA512 (HTTP-Entity-Parser-0.21.tar.gz) = 
3852741017748205d9e030a6a42d5a949e3497c5e119713d81c9bf6ee42f9a0a822e65f4be9b8785840b6e81841c7715d34aabcb9b8d950611ce528f702fffd1



https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/2500edb24653261a9ec4bd47746869289f83d57a?branch=epel8
___
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

pghmcfc pushed to perl-HTTP-Entity-Parser (epel8). "Tweak for EPEL-8 build (..more)"

[notifications]

Notification time stamped 2019-11-19 10:04:21 UTC

From a361c95e084349b8162f6d2390b066a20d24300b Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Nov 13 2019 11:53:55 +
Subject: Tweak for EPEL-8 build


- Use author-independent source URL
- Classify buildreqs by usage
- Fix permissions verbosely
- Make %files list more explicit

---

diff --git a/perl-HTTP-Entity-Parser.rpmlintrc 
b/perl-HTTP-Entity-Parser.rpmlintrc
new file mode 100644
index 000..42d8877
--- /dev/null
+++ b/perl-HTTP-Entity-Parser.rpmlintrc
@@ -0,0 +1,2 @@
+from Config import *
+addFilter("spelling-error %description -l en_US 
(env|psgi|www|urlencoded|multipart|json) -> ")
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index 763361e..56e0fb1 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,44 +1,43 @@
 Name:   perl-HTTP-Entity-Parser
 Version:0.21
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:PSGI compliant HTTP Entity Parser
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/HTTP-Entity-Parser
-Source0:
https://cpan.metacpan.org/authors/id/K/KA/KAZEBURO/HTTP-Entity-Parser-%{version}.tar.gz
-
+Source0:
https://cpan.metacpan.org/modules/by-module/HTTP/HTTP-Entity-Parser-%{version}.tar.gz
 BuildArch:  noarch
-
-BuildRequires:  %{__perl}
-
-BuildRequires:  perl-interpreter >= 0:5.008001
+# Build
+BuildRequires:  coreutils
 BuildRequires:  perl-generators
-
+BuildRequires:  perl-interpreter
+BuildRequires:  perl(Module::Build::Tiny) >= 0.035
+# Module
 BuildRequires:  perl(Carp)
-BuildRequires:  perl(Cwd)
 BuildRequires:  perl(Encode)
-BuildRequires:  perl(Exporter)
 BuildRequires:  perl(Fcntl)
-BuildRequires:  perl(File::Basename)
-BuildRequires:  perl(File::Spec::Functions)
 BuildRequires:  perl(File::Temp)
-BuildRequires:  perl(Hash::MultiValue)
-BuildRequires:  perl(HTTP::Headers)
 BuildRequires:  perl(HTTP::Message) >= 6
 BuildRequires:  perl(HTTP::MultiPartParser)
-BuildRequires:  perl(IO::File)
 BuildRequires:  perl(JSON::MaybeXS) >= 1.003007
-BuildRequires:  perl(Module::Build::Tiny) >= 0.035
 BuildRequires:  perl(Module::Load)
 BuildRequires:  perl(Stream::Buffered)
-BuildRequires:  perl(Test::More) >= 0.98
+BuildRequires:  perl(strict)
+BuildRequires:  perl(warnings)
 BuildRequires:  perl(WWW::Form::UrlEncoded) >= 0.23
-
+# Test Suite
 BuildRequires:  perl(base)
-BuildRequires:  perl(strict)
+BuildRequires:  perl(Cwd)
+BuildRequires:  perl(Exporter)
+BuildRequires:  perl(File::Basename)
+BuildRequires:  perl(File::Spec::Functions)
+BuildRequires:  perl(Hash::MultiValue)
+BuildRequires:  perl(HTTP::Headers)
+BuildRequires:  perl(IO::File)
+BuildRequires:  perl(Test::More) >= 0.98
 BuildRequires:  perl(utf8)
-BuildRequires:  perl(warnings)
-
-Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+# Dependencies
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+Requires:   perl(HTTP::Message) >= 6
 
 %description
 HTTP::Entity::Parser is a PSGI-compliant HTTP Entity parser. This module
@@ -51,24 +50,34 @@ data and application/json.
 %setup -q -n HTTP-Entity-Parser-%{version}
 
 %build
-%{__perl} Build.PL --installdirs=vendor
+perl Build.PL --installdirs=vendor
 ./Build
 
 %install
-./Build install --destdir=$RPM_BUILD_ROOT --create_packlist=0
-
-%{_fixperms} $RPM_BUILD_ROOT/*
+./Build install --destdir=%{buildroot} --create_packlist=0
+%{_fixperms} -c %{buildroot}
 
 %check
 ./Build test
 
 %files
-%doc Changes README.md eg/
 %license LICENSE
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%doc Changes README.md eg/
+%{perl_vendorlib}/HTTP/
+%{_mandir}/man3/HTTP::Entity::Parser.3*
+%{_mandir}/man3/HTTP::Entity::Parser::JSON.3*
+%{_mandir}/man3/HTTP::Entity::Parser::MultiPart.3*
+%{_mandir}/man3/HTTP::Entity::Parser::OctetStream.3*
+%{_mandir}/man3/HTTP::Entity::Parser::UrlEncoded.3*
 
 %changelog
+* Wed Nov 13 2019 Paul Howarth  - 0.21-2
+- Tweak for EPEL-8 build
+  - Use author-independent source URL
+  - Classify buildreqs by usage
+  - Fix permissions verbosely
+  - Make %%files list more explicit
+
 * Sun Mar 04 2018 Ralf Corsépius  - 0.21-1
 - Update to 0.21.
 



https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/a361c95e084349b8162f6d2390b066a20d24300b?branch=epel8
___
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