[Bug 1866972] New: perl-Test2-Suite-0.000132 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1866972 Bug ID: 1866972 Summary: perl-Test2-Suite-0.000132 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test2-Suite Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.000132 Current version/release in rawhide: 0.000130-1.fc33 URL: http://search.cpan.org/dist/Test2-Suite/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/9536/ -- 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: Proposing a new Perl Module Versioning Scheme
I wrote a blog post thoroughly explaining Perl module versions and agree with the assessment and suggested method presented (though I have no comment on the remedy). http://blogs.perl.org/users/grinnz/2018/04/a-guide-to-versions-in-perl.html -Dan On Thu, Aug 6, 2020, 1:09 PM Tina Müller wrote: > Hi, > > I'm working at SUSE, and for about a year I have been in charge of updating > the CPAN modules in SUSE Open Build Service: > https://build.opensuse.org/project/show/devel:languages:perl > > This is half automated. The spec file is generated with the cpanspec > script, > and we manually look over the diff and then request the package to be > updated. > > I would like to make a suggestion and will explain the problems in detail, > so > that we are all on the same page. > > # Status Quo > > As you probably know, the versioning scheme of Perl modules differs from > rpm. > For perl, the versions are decimal, so it can happen that for a given > module A > versions 0.23 and 0.3 are released. The latter one is higher for perl. > Semantically, 0.23 is 0.230.0 and 0.3 is 0.300.0, when correctly > translated to a > rpm like version. > > You can also use versions like 1.2.3 in perl. In that case, they are > already > semantically equal to rpm like versions. The majority of perl modules > still uses > decimal versions, though. > > Many distributions including openSUSE and Fedora are just taking over the > perl > module version literally. > > This sometimes leads to problems, for example if module B requires module > A: > > Requires: perl(A) >= 0.23 > > When module A is uploaded with version 0.3, this will result in an > unresolvable > dependency. > > In those cases we have to manually fix the requirement. > Granted, this doesn't happen very often, but when, it's annoying. > > There might also be cases where it is the other way around, e.g. module A > has versions 0.02 and 0.1. 0.02 is just the same as 0.2 in rpm. > > Module B has: > > Requires: perl(A) >= 0.1 > > If module A is still at version 0.02, the dependency will be satisfied, > because 0.1 is lower in rpm than 0.02. > But that is wrong. In this case we don't see the mistake though. > > Here is a discussion about this that started when I posted my Howto > for creating a CPAN module with correct Metadata: > https://github.com/perlpunk/perl5-module-meta/issues/5 > > # Alternative > > The correct way to translate the versions for the spec would be: > > perl -wE'say version->parse($ARGV[0])->normal;' 0.23 > v0.230.0 > > and then we just have to cut off the 'v' at the beginning. > This should work correctly for all module versions, and it is the right > thing > to do. > We wouldn't need any manual handling anymore. > > # Problem > > As it is impossible to just change all modules in the distributions at the > same > time, we need backwards compatibility. > > # Proposal > > I discussed this on IRC #opensuse-factory. A suggestion came up how to > avoid > having to be backward compatible. > > The versions of each module inside a CPAN distribution are usually > generated > at build time with perl.prov > ( > https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.prov > ). > > Some distributions also use > https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.req > but openSUSE doesn't. The dependencies are extracted at the time when the > spec > file is generated. > > We could add a new capability additionally to perl(). Maybe cpan(). This > can > use the new versioning scheme. > The packages could be built with both capabilities. > As soon as all packages are rebuilt, we can start to adjust the Requires > lines to use the new capability. > > This part is actually pretty easy and shouldn't require much work. Please > correct me if I'm wrong. > > However, there is also the package version, and instead of > > Require: perl(A::B) >= x.y > > one can do > > Require: perl-A-B >= x.y > > so for those package versions we need backward compatibility. > > My idea is to take a snapshot of all CPAN modules we have in our repository > and save the package id and the version. > > The migration strategy to the new versioning scheme would be: > > All modulues having 1, 2 or 3 decimals can update to the new scheme > whenever > a new version is uploaded. > > Let's take module A as the example again. The current (CPAN) version would > be > 0.23. > > When a new version 0.3 is uploaded, we compare the version for A to our > saved > version 0.23. If it is (decimally) higher, we use the new scheme: 0.300.0. > Same thing for other modules requiring A (although we mostly use capability > requirements anyway). > > For all modules having 4 or more decimals, the switch to the version scheme > has to wait until the major version is updated (which might be never for > some > modules). > E.g. module B has 1.201703. Then we have to wait until the major version is > incremented to 2. > > I made some statistics for our
[Bug 1859415] perl-Log-Log4perl-1.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1859415 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Log-Log4perl-1.50-1.fc |perl-Log-Log4perl-1.50-1.fc |33 |33 |perl-Log-Log4perl-1.50-1.fc |perl-Log-Log4perl-1.50-1.fc |32 |32 |perl-Log-Log4perl-1.50-1.fc |perl-Log-Log4perl-1.50-1.fc |31 |31 ||perl-Log-Log4perl-1.50-1.el ||8 --- Comment #10 from Fedora Update System --- FEDORA-EPEL-2020-ac5d34630b has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
distro perl's ldflags='... -Wl,-z,relro ...' causing module build errors. bug in distro perl flags? or module code?
i'm attempting to build a MaxMind GeopIP2 DB reader perl module MaxMind::DB::Reader::XS ( https://metacpan.org/pod/MaxMind::DB::Reader::XS ) on Fedora 32. the build fails on F32 with Errors: "/usr/bin/ld: unrecognized option '-Wl,-z,relro'" & "Unsupported compile language "C"" ? I've filed a bug at the module upstream uninstallable on Fedora32, errors: "/usr/bin/ld: unrecognized option '-Wl,-z,relro'" & "Unsupported compile language "C"" ? https://github.com/maxmind/MaxMind-DB-Reader-XS/issues/32 the build fails only with Fedora's distro perl, which _includes_ the ldflags perl -V | grep -i " ldflags" ldflags ='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -L/usr/local/lib' but is _successful_ on opensuse, where distro perl's ldflags do NOT include '-Wl,-z,relro', perl -V | grep -i " ldflags" ldflags =' -L/usr/local/lib64 -fstack-protector-strong' Is this^ a problem with Fedora's perl build flags "incorrectly" _including_ relro? I've found/followed some of the perl hardening threads @ Fedora; IIUC, it's intentional ... Or likely an issue with the module not correctly dealing with it? ___ 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 1842274] perl-Excel-Writer-XLSX-1.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1842274 --- Comment #10 from Upstream Release Monitoring --- Created attachment 1710703 --> https://bugzilla.redhat.com/attachment.cgi?id=1710703=edit [patch] Update to 1.07 (#1842274) -- 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 1842274] perl-Excel-Writer-XLSX-1.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1842274 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Excel-Writer-XLSX-1.06 |perl-Excel-Writer-XLSX-1.07 |is available|is available --- Comment #9 from Upstream Release Monitoring --- Latest upstream release: 1.07 Current version/release in rawhide: 1.03-2.fc32 URL: http://search.cpan.org/dist/Excel-Writer-XLSX/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2860/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Proposing a new Perl Module Versioning Scheme
Hi, I'm working at SUSE, and for about a year I have been in charge of updating the CPAN modules in SUSE Open Build Service: https://build.opensuse.org/project/show/devel:languages:perl This is half automated. The spec file is generated with the cpanspec script, and we manually look over the diff and then request the package to be updated. I would like to make a suggestion and will explain the problems in detail, so that we are all on the same page. # Status Quo As you probably know, the versioning scheme of Perl modules differs from rpm. For perl, the versions are decimal, so it can happen that for a given module A versions 0.23 and 0.3 are released. The latter one is higher for perl. Semantically, 0.23 is 0.230.0 and 0.3 is 0.300.0, when correctly translated to a rpm like version. You can also use versions like 1.2.3 in perl. In that case, they are already semantically equal to rpm like versions. The majority of perl modules still uses decimal versions, though. Many distributions including openSUSE and Fedora are just taking over the perl module version literally. This sometimes leads to problems, for example if module B requires module A: Requires: perl(A) >= 0.23 When module A is uploaded with version 0.3, this will result in an unresolvable dependency. In those cases we have to manually fix the requirement. Granted, this doesn't happen very often, but when, it's annoying. There might also be cases where it is the other way around, e.g. module A has versions 0.02 and 0.1. 0.02 is just the same as 0.2 in rpm. Module B has: Requires: perl(A) >= 0.1 If module A is still at version 0.02, the dependency will be satisfied, because 0.1 is lower in rpm than 0.02. But that is wrong. In this case we don't see the mistake though. Here is a discussion about this that started when I posted my Howto for creating a CPAN module with correct Metadata: https://github.com/perlpunk/perl5-module-meta/issues/5 # Alternative The correct way to translate the versions for the spec would be: perl -wE'say version->parse($ARGV[0])->normal;' 0.23 v0.230.0 and then we just have to cut off the 'v' at the beginning. This should work correctly for all module versions, and it is the right thing to do. We wouldn't need any manual handling anymore. # Problem As it is impossible to just change all modules in the distributions at the same time, we need backwards compatibility. # Proposal I discussed this on IRC #opensuse-factory. A suggestion came up how to avoid having to be backward compatible. The versions of each module inside a CPAN distribution are usually generated at build time with perl.prov (https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.prov). Some distributions also use https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.req but openSUSE doesn't. The dependencies are extracted at the time when the spec file is generated. We could add a new capability additionally to perl(). Maybe cpan(). This can use the new versioning scheme. The packages could be built with both capabilities. As soon as all packages are rebuilt, we can start to adjust the Requires lines to use the new capability. This part is actually pretty easy and shouldn't require much work. Please correct me if I'm wrong. However, there is also the package version, and instead of Require: perl(A::B) >= x.y one can do Require: perl-A-B >= x.y so for those package versions we need backward compatibility. My idea is to take a snapshot of all CPAN modules we have in our repository and save the package id and the version. The migration strategy to the new versioning scheme would be: All modulues having 1, 2 or 3 decimals can update to the new scheme whenever a new version is uploaded. Let's take module A as the example again. The current (CPAN) version would be 0.23. When a new version 0.3 is uploaded, we compare the version for A to our saved version 0.23. If it is (decimally) higher, we use the new scheme: 0.300.0. Same thing for other modules requiring A (although we mostly use capability requirements anyway). For all modules having 4 or more decimals, the switch to the version scheme has to wait until the major version is updated (which might be never for some modules). E.g. module B has 1.201703. Then we have to wait until the major version is incremented to 2. I made some statistics for our devel:languages:perl repo to see how many decimals the packages have: a: 21 a.b:120 a.bb: 2045 a.bbb: 497 a.: 100 a.b: 25 a.bb: 165 a.bbb+: 11 a.b.c+: 129 So the large majority uses 3 or less decimals. I know the second part is a lot of work, and it feels it comes a bit too late, considered how long perl has been around. OTOH perl will probably stay around for a while. What do you think? Do you think it's worth it? Are there any flaws in my migration strategy? Or do you have alternative suggestions? Would be
[Bug 1802607] perl-Net-DNS-1.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1802607 --- Comment #12 from Upstream Release Monitoring --- An unexpected error occurred while creating the scratch build and has been automatically reported. Sorry! -- 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 1802607] perl-Net-DNS-1.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1802607 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Net-DNS-1.25 is|perl-Net-DNS-1.26 is |available |available --- Comment #11 from Upstream Release Monitoring --- Latest upstream release: 1.26 Current version/release in rawhide: 1.21-2.fc32 URL: http://search.cpan.org/dist/Net-DNS/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3147/ -- 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 1866735] perl-Module-ScanDeps-1.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1866735 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Module-ScanDeps-1.28-1 ||.fc33 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-08-06 10:36:25 -- 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 1866735] New: perl-Module-ScanDeps-1.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1866735 Bug ID: 1866735 Summary: perl-Module-ScanDeps-1.28 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Module-ScanDeps Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: anon.am...@gmail.com, jose.p.oliveira@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.28 Current version/release in rawhide: 1.27-7.fc33 URL: http://search.cpan.org/dist/Module-ScanDeps/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3112/ -- 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
