perl-devel May 2019

perl-devel@lists.fedoraproject.org

3 participants
200 discussions

[rpms/perl-Crypt-OpenSSL-Random] PR #1: Drop Group tag
by Ondřej Lysoněk 29 Jan '20

29 Jan '20

olysonek opened a new pull-request against the project: `perl-Crypt-OpenSSL-Random` that you are following: `` Drop Group tag `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Crypt-OpenSSL-Random/pull-request/1

1 2

[rpms/perl-Crypt-OpenSSL-RSA] PR #1: Drop Group tag
by Ondřej Lysoněk 29 Jan '20

29 Jan '20

olysonek opened a new pull-request against the project: `perl-Crypt-OpenSSL-RSA` that you are following: `` Drop Group tag `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Crypt-OpenSSL-RSA/pull-request/1

1 2

[Bug 1688773] New: Use of uninitialized value in pattern match line 1077, 1086, 1093, 763
by bugzilla＠redhat.com 27 Nov '19

27 Nov '19

https://bugzilla.redhat.com/show_bug.cgi?id=1688773 Bug ID: 1688773 Summary: Use of uninitialized value in pattern match line 1077, 1086, 1093, 763 Product: Fedora Version: 29 Hardware: x86_64 OS: Linux Status: NEW Component: perl-Expect Severity: medium Assignee: paul(a)city-fan.org Reporter: sitezreg(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: jose.p.oliveira.oss(a)gmail.com, paul(a)city-fan.org, perl-devel(a)lists.fedoraproject.org, tremble(a)tremble.org.uk Target Milestone: --- Classification: Fedora Description of problem: Using a cluster command console in "Asbru Connection Manager" throws following error(s): Use of uninitialized value in pattern match (m//) at /usr/share/perl5/vendor_perl/Expect.pm line 1077. Use of uninitialized value in string eq at /usr/share/perl5/vendor_perl/Expect.pm line 1086. Use of uninitialized value in string eq at /usr/share/perl5/vendor_perl/Expect.pm line 1093. Use of uninitialized value in regexp compilation at /usr/share/perl5/vendor_perl/Expect.pm line 763. Note: I've raised the bugreport for the Asbru developer (See: https://github.com/asbru-cm/asbru-cm/issues/134) but was told it is an Expect-related issue so here i am. Version-Release number of selected component (if applicable): perl-Expect-1.35-6.fc29.noarch Sadly i don't know what exactly is being called under the hood. Thanks Alex -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1711098] New: Segmentation Fault in UUlib.so (ScanData) used in perl-Convert-UUlib
by bugzilla＠redhat.com 09 Nov '19

09 Nov '19

https://bugzilla.redhat.com/show_bug.cgi?id=1711098 Bug ID: 1711098 Summary: Segmentation Fault in UUlib.so (ScanData) used in perl-Convert-UUlib Product: Fedora EPEL Version: epel7 Hardware: x86_64 OS: Linux Status: NEW Component: perl-Convert-UUlib Severity: medium Assignee: redhat-bugzilla(a)linuxnetz.de Reporter: nduffy(a)jadeworld.com QA Contact: extras-qa(a)fedoraproject.org CC: perl-devel(a)lists.fedoraproject.org, redhat-bugzilla(a)linuxnetz.de Target Milestone: --- Classification: Fedora Description of problem: When processing certain text, a segmentation fault is generated in the ScanData method in UUlib.so. Version-Release number of selected component (if applicable): perl-Convert-UUlib-1.5-1.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. The following Perl script uses UUlib to read files and process them. -- >8 cut here -- use Convert::UUlib ':all'; LoadFile 'badfile'; -- >8 cut here -- 2. The following input file, when passed to the above Perl, causes the Segmentation Fault. Save this text to a file named "badfile". -- >8 cut here -- a a Content-Type: text/plain -- >8 cut here -- This is a hexdump of badfile to show the bytes. $ hexdump -C badfile 00000000 61 0a 0a 61 0a 0a 43 6f 6e 74 65 6e 74 2d 54 79 |a..a..Content-Ty| 00000010 70 65 3a 20 74 65 78 74 2f 70 6c 61 69 6e 0a |pe: text/plain.| 0000001f $ wc badfile 5 4 31 badfile 3. With the Perl code saved in foo.pl and the text from step 2 saved in a file named badfile, run: $ perl foo.pl Segmentation fault Actual results: Segmentation fault. Expected results: Library should read text and either produce an error if badly formed, otherwise it should decode it. Additional info: This is what I see in gdb. $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.6 (Maipo) $ gdb perl GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/perl...Reading symbols from /usr/lib/debug/usr/bin/perl.debug...done. done. (gdb) run foo.pl Starting program: /usr/bin/perl foo.pl [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007fffefdb6972 in ScanData (datei=datei@entry=0x62a3c0, errcode=errcode@entry=0x7fffffffdf78, boundary=boundary@entry=0x0, ismime=<optimized out>, checkheaders=checkheaders@entry=1, result=result@entry=0x626c50, fname=0x6284e0 "badfile") at uuscan.c:821 821 while (!isspace (*p2) && *p2 != ';') p2++; (gdb) print p2 $1 = 0x7ffff7f41c0d "text/plain" (gdb) list 816 break; 817 } 818 if ((ptr = strchr (line, ':')) != NULL) { 819 ptr++; 820 while (isspace (*ptr)) ptr++; p2 = ptr; 821 while (!isspace (*p2) && *p2 != ';') p2++; 822 c = *p2; *p2 = '\0'; 823 if (p2 != ptr) { 824 _FP_free (result->mimetype); 825 result->mimetype = _FP_strdup (ptr); (gdb) bt #0 0x00007fffefdb6972 in ScanData (datei=datei@entry=0x62a3c0, errcode=errcode@entry=0x7fffffffdf78, boundary=boundary@entry=0x0, ismime=<optimized out>, checkheaders=checkheaders@entry=1, result=result@entry=0x626c50, fname=0x6284e0 "badfile") at uuscan.c:821 #1 0x00007fffefdb878c in ScanPart (datei=datei@entry=0x62a3c0, fname=fname@entry=0x6284e0 "badfile", errcode=errcode@entry=0x7fffffffdf78) at uuscan.c:3141 #2 0x00007fffefda848a in UULoadFileWithPartNo (filename=filename@entry=0x6284e0 "badfile", fileid=0x6284e0 "badfile", fileid@entry=0x0, delflag=delflag@entry=0, partno=partno@entry=-1, partcount=partcount@entry=0x7fffffffe074) at uulib.c:790 #3 0x00007fffefda5181 in XS_Convert__UUlib_LoadFile (my_perl=<optimized out>, cv=<optimized out>) at UUlib.xs:382 #4 0x00007ffff7b0941f in Perl_pp_entersub (my_perl=0x603010) at pp_hot.c:2778 #5 0x00007ffff7b01b96 in Perl_runops_standard (my_perl=0x603010) at run.c:41 #6 0x00007ffff7a9e985 in S_run_body (oldscope=<optimized out>, my_perl=<optimized out>) at perl.c:2402 #7 perl_run (my_perl=0x603010) at perl.c:2320 #8 0x0000000000400ce9 in main (argc=3, argv=0x7fffffffe398, env=0x7fffffffe3b8) at perlmain.c:120 This bug is causing problems with Amavis for us because Amavis uses perl-Convert-UUlib to decode some mime attachments, and one of them is now causing crashes in the scanner. I've narrowed down the text in the attachment as much as possible. Removing any line or even a character in the file means the segmentation faults stop. The letter "a" in the first two lines can be replaced with any character or group of characters, but the last line must remain unchanged. There are no funny characters in the input file, nor DOS line-endings, as shown by the hexdump above. -- You are receiving this mail because: You are on the CC list for the bug.

1 20

[Bug 1704785] New: perl-Net-SSLeay-1.85-9.fc29 FTBFS: /usr/bin/ld: cannot find -lz
by bugzilla＠redhat.com 09 Nov '19

09 Nov '19

https://bugzilla.redhat.com/show_bug.cgi?id=1704785 Bug ID: 1704785 Summary: perl-Net-SSLeay-1.85-9.fc29 FTBFS: /usr/bin/ld: cannot find -lz Product: Fedora Version: 29 Status: NEW Component: perl-Net-SSLeay Assignee: paul(a)city-fan.org Reporter: ppisar(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: jose.p.oliveira.oss(a)gmail.com, kasal(a)ucw.cz, paul(a)city-fan.org, perl-devel(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora perl-Net-SSLeay-1.85-9.fc29 fails to build in F29 and F30: gcc -lpthread -shared -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr -L/usr/lib64 -L/usr/lib -L/usr/local/lib -fstack-protector-strong SSLeay.o -o blib/arch/auto/Net/SSLeay/SSLeay.so \ -L/usr -L/usr/lib64 -L/usr/lib -lssl -lcrypto -lz -lperl \ BUILDSTDERR: /usr/bin/ld: cannot find -lz That's caused by openssl-devel-1.1.1b-4 that removed a dependency on zlib-devel and that was pushed into Fedora ≥ 29. A possible fix is applying commit f571bb6a6929c47b8323c6f2c5214cfefa9dcf37 Author: Paul Howarth <paul(a)city-fan.org> Date: Sat Mar 30 08:06:53 2019 +0000 Get libraries to link against from pkg-config Upstream pull request: https://github.com/radiator-software/p5-net-ssleay/pull/127 to that Fedoras. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1709491] New: perl-homedir creates a local::lib for root user
by bugzilla＠redhat.com 01 Nov '19

01 Nov '19

https://bugzilla.redhat.com/show_bug.cgi?id=1709491 Bug ID: 1709491 Summary: perl-homedir creates a local::lib for root user Product: Fedora Version: 29 Status: NEW Component: perl-local-lib Assignee: jplesnik(a)redhat.com Reporter: grinnz(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: iarnell(a)gmail.com, jplesnik(a)redhat.com, perl-devel(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Description of problem: Upon installing the perl-homedir RPM (which seems to be default in some RHEL/CentOS 7 configurations) a profile.d entry is added which enables a local::lib for all users, including root. The root user should not have a local::lib, as this means 'sudo cpan' or 'sudo cpanm' (though inadvisable) will install into a location unusable by any other user, rather than the global sitelib as expected. Version-Release number of selected component (if applicable): perl-homedir-2.000024-4.fc29.noarch How reproducible: Always Steps to Reproduce: 1. install perl-homedir 2. switch to root user 3. check perl -V Actual results: ~/perl5 is created for root user and local::lib environment variables and directories are visible in perl -V output. Expected results: No local::lib is created or activated for the root user by default. Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1686178] New: perl-libwww-perl-6.37 is available
by bugzilla＠redhat.com 25 Oct '19

25 Oct '19

https://bugzilla.redhat.com/show_bug.cgi?id=1686178 Bug ID: 1686178 Summary: perl-libwww-perl-6.37 is available Product: Fedora Version: rawhide Status: NEW Component: perl-libwww-perl Keywords: FutureFeature, Triaged Assignee: ppisar(a)redhat.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: caillon+fedoraproject(a)gmail.com, john.j5live(a)gmail.com, kasal(a)ucw.cz, perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com, rhughes(a)redhat.com, rstrode(a)redhat.com, sandmann(a)redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 6.37 Current version/release in rawhide: 6.36-2.fc30 URL: http://search.cpan.org/dist/libwww-perl/ 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/3024/ -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1685192] New: LWP::Authen::Negotiate fails to authenticate to Red Hat SSO web server because if missing mutual authentication
by bugzilla＠redhat.com 21 Sep '19

21 Sep '19

https://bugzilla.redhat.com/show_bug.cgi?id=1685192 Bug ID: 1685192 Summary: LWP::Authen::Negotiate fails to authenticate to Red Hat SSO web server because if missing mutual authentication Product: Fedora Version: rawhide Status: NEW Component: perl-LWP-Authen-Negotiate Assignee: steve.traylen(a)cern.ch Reporter: ppisar(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: perl-devel(a)lists.fedoraproject.org, steve.traylen(a)cern.ch Target Milestone: --- External Bug ID: CPAN 128699 Classification: Fedora I encountered a failure when using LWP to perform a Kerberos authentication against Red Hat SSO web server. I narrowed the issue to the fact that LWP::Authen::Negotiate does not enable GSS_C_MUTUAL_FLAG. I developed a fix and posted it to the upstream <https://rt.cpan.org/Ticket/Display.html?id=128699>. Please consider applying it to Fedora. If you don't have time and don't object, I can apply it to Fedora instead of you. -- You are receiving this mail because: You are on the CC list for the bug.

1 13

Making Perl site paths ABI-specific
by Petr Pisar 03 Jul '19

03 Jul '19

It was a long time ago I wrote to this list. I'm thinking about changing site paths. Now, perl configures site paths to: /usr/local/lib64/perl5 /usr/local/share/perl5 so that anyone installing distributions from CPAN in a system-wide manner will install his modules there. These two paths are listed before core and vendor path used by Fedora packages in order to allow users to override Perl modules coming with Fedora. This layout has the nice feature that user's code is available across Fedora upgrades. However, this feature is also bad because perl tends to change ABI and as a result XS modules stop working and becuse the site location precedence they can hinder even Fedora's Perl code. Then inexperienced users report bugs for perl that Perl stopped working after upgrade Fedora. My proposal is make the two paths changing with every new incompatible Perl release (that happens every year with a new minor Perl version). Example: /usr/local/lib64/perl5/5.30 /usr/local/share/perl5/5.30 As a result when users upgrade to Perl 5.30, their locally installed modules become unavailable and thus they won't be able to affect the new system. Also the user immediatelly recongnizes that his locally installed code "disappeared" instead of receiving some cryptic error message from XSLoader few days later when some optional XS module gets loaded. These version specific paths are nothing new. Actually a vanilla Perl installation uses more elaborate path differentiating threaded and non-threaded builds in addition. See Debian or Gentoo. It's important to note that INSTALLSITEBIN would remain /usr/local/bin because nobody's going to add /usr/local/bin/5.30 in PATH manually. (We could deliver a /etc/profile.d file within perl-libs, but I think it would made things more fragile.) One also could be tempted to keep the architecture independent /usr/local/share/perl5 as it is. But that could keep modules without architecture-specific dependencies available after an upgrade. So I believe we should move both paths. So if we conclude that this change is good and should be implemented, the only uncertainity is the issue of aestetic: How exactly should the paths be named? I can see these posibilities: /usr/local/share/perl5/5.30 /usr/local/share/perl5/30 /usr/local/share/perl5.30 The first two keep all Perl files under one directory, while the third one proliferates directories right under /usr/local/share. It also is backward compatible for people who back up or NFS-mount the paths. The last two makes the path a little bit shorter. While the first and last resembles a soname we already give to libperl.so (/usr/lib64/libperl.so.5.30). The first two have also a very tiny posibility of a clash with Perl modules namespaced into "5.30::" or "30::" that could survive from current days (installed into /usr/local/share/perl5). I like the first option. Any opinions? Should we go with this change? Wich format do you like most? -- Petr

3 3

[Bug 1670372] New: Upgrade perl-Net-SFTP-Foreign to 1.90
by bugzilla＠redhat.com 20 Jun '19

20 Jun '19

https://bugzilla.redhat.com/show_bug.cgi?id=1670372 Bug ID: 1670372 Summary: Upgrade perl-Net-SFTP-Foreign to 1.90 Product: Fedora Version: rawhide Status: NEW Component: perl-Net-SFTP-Foreign Assignee: fedorapkg(a)rule.lv Reporter: jplesnik(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fedorapkg(a)rule.lv, jplesnik(a)redhat.com, perl-devel(a)lists.fedoraproject.org, zonexpertconsulting(a)outlook.com Target Milestone: --- Classification: Fedora Latest Fedora delivers 1.89 version. Upstream released 1.90. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

perl-devel May 2019