perl-devel August 2014

perl-devel@lists.fedoraproject.org

27 participants
4451 discussions

[Bug 1108387] New: Build perl-Class-Accessor-Chained for EPEL7
by Red Hat Bugzilla 02 Jan '17

02 Jan '17

https://bugzilla.redhat.com/show_bug.cgi?id=1108387 Bug ID: 1108387 Summary: Build perl-Class-Accessor-Chained for EPEL7 Product: Fedora EPEL Version: epel7 Component: perl-Class-Accessor-Chained Assignee: tcallawa(a)redhat.com Reporter: xavier(a)bachelot.org QA Contact: extras-qa(a)fedoraproject.org CC: perl-devel(a)lists.fedoraproject.org, tcallawa(a)redhat.com Hi, perl-Class-Accessor-Chained is a dependency of another package I'd like to build for EPEL7. Could you please either branch or build it or allow me to request a branch ? Regards, Xavier -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=o1Htl2wJD2&a=cc_unsubscribe

1 3

[Bug 874942] New: Net-DNS: system configuration is used instead of user's
by Red Hat Bugzilla 20 Dec '16

20 Dec '16

https://bugzilla.redhat.com/show_bug.cgi?id=874942 Bug ID: 874942 QA Contact: extras-qa(a)fedoraproject.org Severity: high External Bug URL: http://rt.cpan.org/Public/ Version: rawhide Priority: unspecified CC: mmaslano(a)redhat.com, perl-devel(a)lists.fedoraproject.org, psabata(a)redhat.com Assignee: mmaslano(a)redhat.com Summary: Net-DNS: system configuration is used instead of user's Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: mmaslano(a)redhat.com Type: Bug Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-Net-DNS Product: Fedora External Bug ID: CPAN 67602 If I define my own configuration file, system files are used, which could be security issue. Example: My configuration file is defined as: my $res = Net::DNS::Resolver->new(config_file => '/my/dns.conf'); These files are read even if I defined my own file: /etc/resolv.conf $HOME/.resolv.conf ./.resolv.conf Last 2 files shouldn't be read by default since it's possible security issue - user can drop .resolv.conf pointing to malicious dns server. This issue was found during testing spamassassin with selinux. For details see: https://bugzilla.redhat.com/sh ow_bug.cgi?id=628866#c2 I'm reporting this error back into our bugzilla because of last comment in rt: I think the level of this PR should be elevated to 'security'. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 831716] New: Moving legacy code out of perl-JSON-RPC breaks Bugzilla
by Red Hat Bugzilla 13 Dec '16

13 Dec '16

https://bugzilla.redhat.com/show_bug.cgi?id=831716 Bug ID: 831716 QA Contact: extras-qa(a)fedoraproject.org Severity: high Version: 17 Priority: unspecified CC: emmanuel.seyman(a)club-internet.fr, perl-devel(a)lists.fedoraproject.org Assignee: emmanuel.seyman(a)club-internet.fr Summary: Moving legacy code out of perl-JSON-RPC breaks Bugzilla Regression: --- Story Points: --- Classification: Fedora OS: Linux Reporter: lpsolit(a)netscape.net Type: Bug Documentation: --- Hardware: All Mount Type: --- Status: NEW Component: perl-JSON-RPC Product: Fedora Bugzilla still uses legacy code from JSON::RPC and despite the perl-JSON-RPC package is installed, which makes checksetup.pl happy, the JSON-RPC feature of Bugzilla fails because it cannot find the legacy code. This also prevents Apache from starting when mod_perl is enabled: httpd[1938]: Can't locate JSON/RPC/Legacy/Server/CGI.pm in @INC So the legacy code is still required by Bugzilla, and checksetup.pl and Bugzilla re confused by this package split. -- You are receiving this mail because: You are on the CC list for the bug.

1 26

[Bug 1054061] New: Segfault in Perl_gv_fetchpvn_flags when trying to initialize back_perl openldap backend
by Red Hat Bugzilla 02 Dec '16

02 Dec '16

https://bugzilla.redhat.com/show_bug.cgi?id=1054061 Bug ID: 1054061 Summary: Segfault in Perl_gv_fetchpvn_flags when trying to initialize back_perl openldap backend Product: Red Hat Enterprise Linux 7 Version: 7.0 Component: perl Assignee: perl-maint-list(a)redhat.com Reporter: jsynacek(a)redhat.com QA Contact: qe-baseos-apps(a)redhat.com CC: cweyl(a)alumni.drew.edu, hyc(a)symas.com, iarnell(a)gmail.com, jplesnik(a)redhat.com, kasal(a)ucw.cz, lkundrak(a)v3.sk, mmaslano(a)redhat.com, perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com, psabata(a)redhat.com, rc040203(a)freenet.de, tcallawa(a)redhat.com Depends On: 967719 Group: devel External Bug ID: OpenLDAP ITS 7573 +++ This bug was initially created as a clone of Bug #967719 +++ Description of problem: When trying to initialize back_perl, a segfault occurs deep in perl itself. Version-Release number of selected component (if applicable): perl-5.16.3-264.fc19.x86_64 openldap-2.4.35-4.fc19.x86_64 How reproducible: Almost always. Steps to Reproduce: 1. Install fresh F19 2. If you try the reproducer here, all goes well 3. yum install perl-A* (I have no idea why I needed to do this to get it to segfault) 4. Try reproducer 5. Observe the segfault 6. From now on, reproducer works *without* producing any segfaults. I had to reboot the machine to be able to reproduce the issue again. Note on how to use the reproducer: 1. Unpack 2. Run go.sh (warning: it will wipe your /var/lib/ldap/* and your /etc/openldap/*, so don't run if you use openldap in production) This will run slapd in debug mode, so you will need another console to run the rest. 3. Run try.sh 4. If you want to repeat, go to 2. You can modify go.sh to run slapd through a debugger. However, you will probably need to set LD_PRELOAD=/usr/lib64/perl5/CORE/libperl.so to be able to run try.sh. Actual results: Perl segfaults. Expected results: The back_perl gets initialized without any problems. Additional info: This also happens on my production F18, but it happens always. It looks like it might have something to do with Bug 960048. --- Additional comment from Jan Synacek on 2013-05-28 08:53:11 CEST --- Note that in the frame #3, the my_perl variable changes from a (probably valid) pointer to 0x0. --- Additional comment from Petr Pisar on 2013-07-03 14:38:09 CEST --- What's expected output on the client site? I have patched perl so that it links all XS modules to libperl.so explicitly in my private F20 machine, and I do not get any segfaults. Instead I just get an error message from the second command: $ sh try.sh SASL/EXTERNAL authentication started SASL username: gidNumber=500+uidNumber=500,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config" ldap_add: Insufficient access (50) SASL/EXTERNAL authentication started SASL username: gidNumber=500+uidNumber=500,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase=perl,cn=config" ldap_add: Invalid syntax (21) additional info: objectClass: value #1 invalid per syntax I guess this is how to should work. If this is the real fix, than this issue will be fixed in F20. --- Additional comment from Jan Synacek on 2013-07-03 14:57:38 CEST --- All LDAP operations should succeed without any errors. You don't have sufficient access rights to modify the LDAP database. Running the script as root should do it. You should see something like this: # ./try.sh SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config" SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase=perl,cn=config" ldap_result: Can't contact LDAP server (-1) The last line indicates the termination (you can see that slapd segfaulted in the console where you ran go.sh). Expected output would look like the one above minus the 'ldap_result: ...' line. Plus there may be one additional 'adding new entry' line. --- Additional comment from Petr Pisar on 2013-07-03 16:07:01 CEST --- I run it as a non-root. I get much better results as a root: # ./try.sh SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config" SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase=perl,cn=config" adding new entry "dc=perl-example,dc=com" However the server sometimes segfaults as you reported. --- Additional comment from Jan Synacek on 2013-07-04 07:54:23 CEST --- (In reply to Petr Pisar from comment #4) > I run it as a non-root. I get much better results as a root: Yes, that's how the output is supposed to look. > However the server sometimes segfaults as you reported. Ok, it's strange that it segfaults only sometimes. Does this mean that you can reproduce it even with all the perl modules linked to libperl.so explicitly? --- Additional comment from Petr Pisar on 2013-07-04 09:07:56 CEST --- I recompiled only modules in perl binary package and openldap for the test. Not yet all modules that exist. I also reverted the RTLD_GLOBAL patch and checked slapd does not crashes on linkage error. So the test does not use any not-yet-rebuild modules. I conclude this issue is independent on the linking bug #960048. But we will see more after rebuilding everything. --- Additional comment from Fedora Admin XMLRPC Client on 2013-08-12 13:50:07 CEST --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. --- Additional comment from Howard Chu on 2013-10-13 02:20:16 CEST --- Please also followup to OpenLDAP ITS#7573 with any conclusions you reach, thanks. --- Additional comment from Jan Synacek on 2013-10-16 08:13:38 CEST --- This problem still occurs in F20. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=967719 [Bug 967719] Segfault in Perl_gv_fetchpvn_flags when trying to initialize back_perl openldap backend -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=RTtoq7IB5n&a=cc_unsubscribe

1 9

[Bug 994894] New: perl-Soot does not support ARM
by Red Hat Bugzilla 24 Nov '16

24 Nov '16

https://bugzilla.redhat.com/show_bug.cgi?id=994894 Bug ID: 994894 Summary: perl-Soot does not support ARM Product: Fedora Version: rawhide Component: perl-SOOT Assignee: ppisar(a)redhat.com Reporter: ppisar(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com Depends On: 991031 Blocks: 485251 (F-ExcludeArch-ARM) perl-Soot requires root which does not support ARM (bug #991031). perl-Soot will be disabled on ARM. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CKPzevCLAa&a=cc_unsubscribe

1 9

[Bug 808197] New: FTBFS: big endian bug in self checks
by Red Hat Bugzilla 09 Nov '16

09 Nov '16

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS: big endian bug in self checks https://bugzilla.redhat.com/show_bug.cgi?id=808197 Summary: FTBFS: big endian bug in self checks Product: Fedora Version: 17 Platform: powerpc OS/Version: Linux Status: NEW Severity: high Priority: medium Component: perl-Socket-Netlink AssignedTo: bochecha(a)fedoraproject.org ReportedBy: karsten(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: fedora-perl-devel-list(a)redhat.com, bochecha(a)fedoraproject.org Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Description of problem: perl-Socket-Netlink fails to build on PPC as two of the self checks fail, one of them looks like a big endian bug as the result has a swapped bit: t/12netlink-message-header.t ..... ok # Failed test '$message->attrs after unpack' # at t/13netlink-message-attrs.t line 98. # Structures begin differing at: # $got->{str} = '' # $expected->{str} = 'FGH' # Looks like you failed 1 test of 14. t/13netlink-message-attrs.t ...... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/14 subtests t/14netlink-message-error.t ...... ok # Failed test '$message->pack' # at t/20io-socket-netlink-generic.t line 55. # at bytes 0-0xf (0-15) # got: | 00 00 00 14 00 1e 00 00 00 00 00 00 00 00 00 00 |................| # exp: | 00 00 00 14 00 00 00 1e 00 00 00 00 00 00 00 00 |................| # Looks like you failed 1 test of 13. Version-Release number of selected component (if applicable): perl-Socket-Netlink-0.03-4.fc17 How reproducible: always Steps to Reproduce: 1. ppc-koji build --scratch f17 perl-Socket-Netlink-0.03-4.fc17.src.rpm 2. 3. Actual results: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=469988 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 6

[Bug 671445] New: [PATCH] specfile accords to new packaging guidelines
by Red Hat Bugzilla 03 Nov '16

03 Nov '16

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [PATCH] specfile accords to new packaging guidelines https://bugzilla.redhat.com/show_bug.cgi?id=671445 Summary: [PATCH] specfile accords to new packaging guidelines Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: cpanspec AssignedTo: steve(a)silug.org ReportedBy: mmaslano(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: steve(a)silug.org, fedora-perl-devel-list(a)redhat.com Classification: Fedora Created attachment 474630 --> https://bugzilla.redhat.com/attachment.cgi?id=474630 add epel option This patch should remove things, which are not needed according to new packaging guidelines and latest rpm eg. defining buildroot. The old behaviour is available under --epel option. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 11

[Bug 807793] New: Please build pcsc-perl for EPEL6
by Red Hat Bugzilla 07 Oct '16

07 Oct '16

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Please build pcsc-perl for EPEL6 https://bugzilla.redhat.com/show_bug.cgi?id=807793 Summary: Please build pcsc-perl for EPEL6 Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: pcsc-perl AssignedTo: tmraz(a)redhat.com ReportedBy: mjeanson(a)rlnx.com QAContact: extras-qa(a)fedoraproject.org CC: tmraz(a)redhat.com, fedora-perl-devel-list(a)redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Hi, I was hoping that you could build pcsc-perl for EPEL6. I just tried a scratch build of the fc17 version and it builds without modification within EPEL6. http://koji.fedoraproject.org/koji/taskinfo?taskID=3940535 Thanks, Michael -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 10

[Bug 1078438] New: Templated types are causing "Could not find a typemap for C type"
by Red Hat Bugzilla 06 Oct '16

06 Oct '16

https://bugzilla.redhat.com/show_bug.cgi?id=1078438 Bug ID: 1078438 Summary: Templated types are causing "Could not find a typemap for C type" Product: Red Hat Enterprise Linux 7 Version: 7.0 Component: perl-ExtUtils-ParseXS Assignee: perl-maint-list(a)redhat.com Reporter: mhroncok(a)redhat.com QA Contact: qe-baseos-apps(a)redhat.com CC: perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com Depends On: 1032181 Blocks: 1032056 +++ This bug was initially created as a clone of Bug #1032181 +++ Description of problem: When using perl-ExtUtils-ParseXS to build XS stuff (I don't know the terminology here, sorry), errors like this happens: https://rt.cpan.org/Public/Bug/Display.html?id=86367 Version-Release number of selected component (if applicable): perl-ExtUtils-ParseXS-3.18-291.fc20.noarch How reproducible: Happend when building slic3r-xs Steps to Reproduce: 1. Get slic3r tarball from https://github.com/alexrj/Slic3r/archive/1.0.0RC1.tar.gz 2. unpack && cd Slic3r-1.0.0RC1/xs/ # be usre to be in xs folder 3. perl Build.PL && ./Build Actual results: <snip> Could not find a typemap for C type 'std::vector< double >'. The following C types are mapped by the current typemap: 'AV *', <snip>, 'wchar_t *' in /usr/bin/perl -MExtUtils::XSpp::Cmd -e xspp -- -t "/home/churchyard/Stažené/Slic3r-1.0.0RC1/xs/xsp/typemap.xspt" "/home/churchyard/Stažené/Slic3r-1.0.0RC1/xs/xsp/TriangleMesh.xsp", line 138 Expected results: No errors, just warnings Additional info: This is fixed in upstream release 3.22 and also in development release 3.18_03. Fix is in Bug #1032181. See the error in this build.log: http://copr-be.cloud.fedoraproject.org/results/churchyard/epel7-3dprint/epe… Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1032056 [Bug 1032056] Slic3r 1.0.0RC1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1032181 [Bug 1032181] Templated types are causing "Could not find a typemap for C type" -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ujbL1yHik6&a=cc_unsubscribe

1 14

[Bug 1101265] New: perl-libwww-perl: incorrect handling of SSL certificate verification [fedora-all]
by Red Hat Bugzilla 19 Jul '16

19 Jul '16

https://bugzilla.redhat.com/show_bug.cgi?id=1101265 Bug ID: 1101265 Summary: perl-libwww-perl: incorrect handling of SSL certificate verification [fedora-all] Product: Fedora Version: 20 Component: perl-LWP-Protocol-https Keywords: FutureFeature Severity: high Priority: high Assignee: ppisar(a)redhat.com Reporter: ppisar(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: jpazdziora(a)redhat.com, jplesnik(a)redhat.com, mmaslano(a)redhat.com, mzazrivec(a)redhat.com, perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com, psabata(a)redhat.com +++ This bug was initially created as a clone of Bug #1094442 +++ [...] --- Additional comment from Jan Pazdziora on 2014-05-26 10:55:43 GMT --- (In reply to Petr Pisar from comment #9) > Thank you for the report. However there are two mistakes: > > (1) The IO::Socket::SSL::new option is "SSL_verifycn_scheme", not > "SSL_verifycn_schema". Thus you could not find it in the documentation. Ahh, sorry about that . > (2) The 6.04-3 behavior was flawed. As you can read in the upstream bug > report, the "SSL_verify_mode" option is about checking hostname. It's not > intended to control certificate validation. The same applies to > "PERL_LWP_SSL_VERIFY_HOSTNAME" environment variable. 6.04-4 has restored the > behavior which presented before 6.04. So what is the way for making HTTP requests to websites with self-signed certificates from perl, if the user does not care about the CA chain validation? In other way, what is the way for making LWP behave the same way it used to behave with pre-6 version? --- Additional comment from Petr Pisar on 2014-05-26 11:20:51 GMT --- There is no LWP environment variable or command line option to control that currently. It's possible to pass ssl_opts => {SSL_verify_mode => IO::Socket::SSL::SSL_VERIFY_NONE} to LWP::UserAgent::new if you write your own LWP application. This is also discussed in the upstream report. The reason why the PERL_LWP_SSL_VERIFY_HOSTNAME seemed to work before is the IO::Socket::SSL < 1.950 defaulted to SSL_VERIFY_NONE. This has not been true since Fedora 20. Unfortunately Fedora 20 delivered the flawed LWP::Protocol::https, so it was not visible. I agree with you that there should be way how to disable the certificate validation externally. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vNjL2yMVw5&a=cc_unsubscribe

1 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

perl-devel August 2014