[Bug 1867229] perl-Text-Table-Tiny-1.00 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/modules/by-module/Text/Text-Table-Tiny-1.00.tar.gz to
./Text-Table-Tiny-1.00.tar.gz


-- 
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 1867229] New: perl-Text-Table-Tiny-1.00 is available

[bugzilla]

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

Bug ID: 1867229
   Summary: perl-Text-Table-Tiny-1.00 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Text-Table-Tiny
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.00
Current version/release in rawhide: 0.05-5.fc32
URL: http://search.cpan.org/dist/Text-Table-Tiny/

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


-- 
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: distro perl's ldflags='... -Wl,-z,relro ...' causing module build errors. bug in distro perl flags? or module code?

[PGNet Dev]

On 8/7/20 5:57 AM, Petr Pisar wrote:
> I think the build script does not use Perl configuration consistently. It uses
> ldflags value for the linker flags, but it does not use ld value for the 
> linker
> exectable:
...
> $ perl -MConfig -E 'say $Config{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
> $ perl -MConfig -E 'say $Config{ld}'
> gcc

double-checking here,

perl -MConfig -E 'say $Config{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
perl -MConfig -E 'say $Config{ld}'
gcc

> If your /usr/bin/ld is the binutils ld,

it is:

which ld
/usr/bin/ld

ld -v
GNU ld version 2.34-4.fc32

rpm -ql binutils | grep bin/ld
/usr/bin/ld
/usr/bin/ld.bfd


ls -al /usr/bin/ld
lrwxrwxrwx. 1 root root 20 Jul 28 21:59 /usr/bin/ld -> 
/etc/alternatives/ld*
ls -al /etc/alternatives/ld
lrwxrwxrwx. 1 root root 15 Jul 28 21:59 /etc/alternatives/ld -> 
/usr/bin/ld.bfd*

> 
then -fstack-protector-strong is also

> an invalid option for ld (see ld manual page) and it should also fail. I think

> something tricks you.

noted

> It's not intentional, but it's how perl works.
> 
> When you build perl, the linker flags are modified by a perl build script and
> built into the perl interpreter. Later when a third-party XS module is built,
> the built-in linker flags are reused. That's because the XS module must be
> binary compatible with the perl interpreter and having the same flags ensures
> it. (Some flags, especially compiler flags, changes ABI.) As a result, the
> third-party module is also built rerlo.
> 
> We would like to change it, but perl build script is a giant mess. When I 
> asked
> perl authors for explaining the mess, it turned out that they do not fully
> understand it and, more imporatantly, that they do not want to touch it
> all because they fear breaking a compatibility.
> 
>> Or likely an issue with the module not correctly dealing with it?
> 
> I think that's the case. It should use gcc program for linking.

thx for the comments!  I'll share upstream.
___
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: distro perl's ldflags='... -Wl,-z,relro ...' causing module build errors. bug in distro perl flags? or module code?

[Petr Pisar]

On Thu, Aug 06, 2020 at 05:12:10PM -0700, PGNet Dev wrote:
> 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'"
>
'-Wl,-z,relro' is a linker flag. But not for /usr/bin/ld, but for
/usr/bin/gcc.

> 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'
> 
I think the build script does not use Perl configuration consistently. It uses
ldflags value for the linker flags, but it does not use ld value for the linker
exectable:

$ perl -MConfig -E 'say $Config{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
$ perl -MConfig -E 'say $Config{ld}'
gcc

> 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'
>
If your /usr/bin/ld is the binutils ld, then -fstack-protector-strong is also
an invalid option for ld (see ld manual page) and it should also fail. I think
something tricks you.

> Is this^ a problem with Fedora's perl build flags "incorrectly" _including_
> relro?

Fedora mandates all packaged code to be built with relro. Therefore perl is
also built with relro.

> I've found/followed some of the perl hardening threads @ Fedora;
> IIUC, it's intentional ...
> 
It's not intentional, but it's how perl works.

When you build perl, the linker flags are modified by a perl build script and
built into the perl interpreter. Later when a third-party XS module is built,
the built-in linker flags are reused. That's because the XS module must be
binary compatible with the perl interpreter and having the same flags ensures
it. (Some flags, especially compiler flags, changes ABI.) As a result, the
third-party module is also built rerlo.

We would like to change it, but perl build script is a giant mess. When I asked
perl authors for explaining the mess, it turned out that they do not fully
understand it and, more imporatantly, that they do not want to touch it
all because they fear breaking a compatibility.

> Or likely an issue with the module not correctly dealing with it?

I think that's the case. It should use gcc program for linking.

-- Petr


signature.asc
Description: PGP signature
___
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

[Petr Pisar]

On Thu, Aug 06, 2020 at 07:09:37PM +0200, Tina Müller wrote:
> I'm working at SUSE,
[...]
> As you probably know, the versioning scheme of Perl modules differs from rpm.

We have the same issue in Fedora. We had a discussion about it in the past,
and the result was that while few packagers wanted to fix it, most of them
rejected the change, therefore Fedora did not move.

I saw that Gentoo managed it. Probably because of fewer interested people.

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

At that time I implemented the conversion in pure Perl
 and as
a C library and a program .

$ fvsp -l 0.23
0.230.0

The motivation was keep rpm tool free from Perl and support bootstrapping
Perl when XS version module implementation is binary incompatible with the new
Perl.

Have you thought about an underscore character in the version string? While
modern version module ignores the underscore (0.1_2 is 0.12), there used to be
a guide line that the underscore designates a prerelease (0.1_2 is the second
prerelease of 0.1) and thus should be ordered before the stable release (0.1).
I remember I saw such releases on CPAN. I came to a conclusion that there is
no correct (in the meaning of compatibility) way of handling the undersore.
Maybe it's not a problem anymore.

> # Problem
> 
> As it is impossible to just change all modules in the distributions at the 
> same
> time, we need backwards compatibility.
> 
It depends on how you understand the "distribution". If you mean only the latest
version of the distribution (e.g. Fedora 33 in constrast to Fedora 32), then
Fedora is able to switch the versioning for all packages delivered by Fedora
in one week. (On the assumption that Fedora people agree on it).

> # 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.
> 
Please note that in Fedora we do not use any of them. We moved them from RPM 
tool
to an independent tool maintained by Fedora Perl folks. I want to say that
I value that you share your opinion with Fedora people, but whatever changes
you do in upstream RPM, it won't have any direct effect on packaging of Perl
code in Fedora.

> 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.
> 
That's a nice plan. Would you remove perl() at the end? Or would you mirror
cpan() to perl() and then remove cpan() in order to get back to perl() name
space. I want to say that cpan() is not the best name, because not all Perl
code comes from CPAN.

I don't know packaging in SuSE. But in Fedora we have a problem with legacy. 
Some
packagers want to share one spec file among multiple Fedora (or even RHEL)
releases. That means once you rewrite Requires from the decimal perl() to the
normalized cpan(), the spec files become incompatible with the older
distributions. And that was the fact that shut down my previous attempt in
Fedora. (I proposed to hide the difference in a %perl_v() RPM macro
, but that was 
also
opposed as making the packaging less legible. In general there was opposition
to any change that would require packaging in any new way. But some time
passed, maybe the mood has changed since then. I can try it again.)

> 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.
> 
In Fedora we banned depending on Perl package names for the purpose of
installing the Perl modules. Packagers must use perl() for that purpose. As
for normalizing RPM package versions, you can bump RPM Epoch value.

> 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 

[Bug 1866972] perl-Test2-Suite-0.000132 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Test2-Suite-0.000132-1
   ||.fc33
 Resolution|--- |RAWHIDE
Last Closed||2020-08-07 08:47:28



--- Comment #1 from Petr Pisar  ---
An enhancement release, requires a newer Test-Simple-1.302177, suitable for
Fedora ≥ 33.


-- 
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 1866972] perl-Test2-Suite-0.000132 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




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