perl-devel May 2007

perl-devel@lists.fedoraproject.org

14 participants
80 discussions

[Bug 238581] New: careless use of gethostbyname() in Socket.xs
by Red Hat Bugzilla 26 Mar '08

26 Mar '08

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238581 Summary: careless use of gethostbyname() in Socket.xs Product: Fedora Core Version: fc5 Platform: All URL: http://rt.perl.org/rt3/Public/Bug/Display.html?id=42844 OS/Version: Linux Status: NEW Severity: low Priority: medium Component: perl AssignedTo: rnorwood(a)redhat.com ReportedBy: peak(a)argo.troja.mff.cuni.cz QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list(a)redhat.com Description of problem: Socket::inet_aton() does not the length of data returned by gethostbyname() before copying it. See the link to PerlBug for details. Version-Release number of selected component (if applicable): 5.8.8-4 (other versions are affected as well) How reproducible: Easily when you LD_PRELOAD a broken implementation of gethostbyname(). :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 5

[Bug 204679] New: Update perl unicode tables to unicode 5.0
by Red Hat Bugzilla 20 Mar '08

20 Mar '08

1 2

[Bug 225059] New: new iThreads release
by Red Hat Bugzilla 20 Mar '08

20 Mar '08

1 3

[Bug 224320] New: Unable to create sub named "" at /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/XSLoader.pm line 99
by Red Hat Bugzilla 17 Mar '08

17 Mar '08

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224320 Summary: Unable to create sub named "" at /usr/lib64/perl5/5.8.8/x86_64-linux-thread- multi/XSLoader.pm line 99 Product: Fedora Core Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl AssignedTo: rnorwood(a)redhat.com ReportedBy: backes(a)rhrk.uni-kl.de QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list(a)redhat.com Description of problem: perlcc is broken! Version-Release number of selected component (if applicable):perl-5.8.8-10 How reproducible: Each time Steps to Reproduce: 1.compile the following text with perlcc: #!/usr/bin/perl use strict; my $datei; my $i; my @csv_dateien = glob "*.csv"; foreach $datei (@csv_dateien) { open (INHALT, "+<$datei"); open (NEU, ">>new$datei") or die "Kann die Datei $datei nicht oeffnen: $!"; while(defined($i = <INHALT>)) { $i =~ s/\,/\./g; $i =~ s/\;/\,/g; print NEU $i; } close INHALT; close NEU; } 2. Make some file named ...csv 3. start a.out Actual results: Unable to create sub named "" at /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/XSLoader.pm line 99. Expected results: a.out runs correctly Additional info: -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 2

[Bug 227756] New: spamassassin needs restart only if sa-update returns 0
by Red Hat Bugzilla 16 Mar '08

16 Mar '08

1 4

[Bug 232380] New: Pod::Readme: BR'ing perl(Test::Pod::Coverage) creates a circular BR loop
by Red Hat Bugzilla 11 Mar '08

11 Mar '08

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232380 Summary: Pod::Readme: BR'ing perl(Test::Pod::Coverage) creates a circular BR loop Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-Pod-Readme AssignedTo: steve(a)silug.org ReportedBy: cweyl(a)alumni.drew.edu QAContact: extras-qa(a)fedoraproject.org CC: fedora-perl-devel-list(a)redhat.com Another fun circular BR loop :) Though this is seen when trying to rebuild perl-Module-Build: perl-Module-Build BR's perl(Pod::Readme) perl-Pod-Readme BR's perl(Test::Pod::Coverage) perl-Test-Pod-Coverage BR's perl(Pod::Coverage) perl-Pod-Coverage BR's perl(Module::Build) Since Test::Pod::Coverage is a developer test, and not needed for the build of perl-Pod-Readme, can we drop it as a BR to this package? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 4

[Bug 205455] New: RFE: Versioned Obsoletes for built-in perl modules
by Red Hat Bugzilla 10 Mar '08

10 Mar '08

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205455 Summary: RFE: Versioned Obsoletes for built-in perl modules Product: Fedora Core Version: fc5 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl AssignedTo: rnorwood(a)redhat.com ReportedBy: nj(a)leverton.org QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list(a)redhat.com Description of problem: The perl rpm Obsoletes a number of modules which are now included in base perl 5.8.8. However some of these modules do get updated fairly regularly in between perl releases. As a system builder I prefer to update them by building an RPM with cpanflute for the specific module e.g. perl-Time-HiRes, so that I get simple and repeatable installations. But because of the Obsoletes in the perl RPM I have to remember which are in base perl and choose non-standard module names to get round it. If the Obsoletes tag could be made versioned, against the actual module version included in perl, it would simplify the task of keeping systems up to date between Fedora releases. It would also make it it much easier when Fedora perl is updated because $PACKAGE_MANAGER could be trusted not to remove newer modules. At the time of writing the tags for perl 5.8.8 would be: Obsoletes: perl-Digest-MD5 <= 2.36 Obsoletes: perl-MIME-Base64 <= 3.07 Obsoletes: perl-libnet <= 1.19 Obsoletes: perl-Storable <= 2.15 Obsoletes: perl-CGI <= 3.15 Obsoletes: perl-CPAN <= 1.7602 Obsoletes: perl-DB_File <= 1.814 Obsoletes: perl-Filter <= 1.32 Obsoletes: perl-Filter-Simple <= 0.82 Obsoletes: perl-Time-HiRes <= 1.86 Obsoletes: perl-Test-Builder-Tester <= 1.02 Version-Release number of selected component (if applicable): 5.8.8-8 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 4

[Bug 172792] New: use of study() with utf8 support enabled breaks regexps
by Red Hat Bugzilla 06 Mar '08

06 Mar '08

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172792 Summary: use of study() with utf8 support enabled breaks regexps Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: jvdias(a)redhat.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list(a)redhat.com Description of problem: Use of study() with utf8 support enabled breaks perl-5.8.7's regular expressions : OK without UTF: $ echo 'ABDCEFGHIJK' | perl -pe 'study; s/HIJK/1234/;' ABDCEFG1234 $ echo 'ABCDEFGHIJK' | perl -e '$_=<>; study; print /HIJK/,"\n";' 1 FAILS with UTF: $ echo 'ABDCEFGHIJK' | PERL_UNICODE=31 perl -pe 'study; s/HIJK/1234/;' ABDCEFGHIJK $ echo 'ABCDEFGHIJK' | PERL_UNICODE=31 perl -e '$_=<>; study; print /HIJK/,"\n";' (re did not match) Seems to be study() that is the culprit: $ echo 'ABDCEFGHIJK' | PERL_UNICODE=31 perl -pe 's/HIJK/1234/;' ABDCEFG1234 And it is because $_ gets utf8-ness from STDIN: $ echo 'ABDCEFGHIJK' | PERL_UNICODE=63 perl -e '$_=<>; study; print /HIJK/ ? "OK" : "FAIL","\n";' FAIL $ PERL_UNICODE=63 perl -e '$_="ABDCEFGHIJK"; study; print /HIJK/ ? "OK" : "FAIL","\n";' OK This was in the 'en_US.UTF-8' locale. If I make utf-8 support conditional on locale, the problem goes away for the C locale: $ echo 'ABDCEFGHIJK' | PERL_UNICODE=127 LC_ALL=C perl -e '$_=<>; study; print /HIJK/ ? "OK" : "FAIL","\n";' OK Version-Release number of selected component (if applicable): ALL perl versions How reproducible: 100% Additional Information: This is upstream perl bug 37646 ( http://rt.perl.org/rt3/index.html?q=37646 ) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 3

[Bug 234439] New: Using perl's XML::LibXML Xpath function makes perl to crash
by Red Hat Bugzilla 27 Feb '08

27 Feb '08

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234439 Summary: Using perl's XML::LibXML Xpath function makes perl to crash Product: Fedora Core Version: fc6 Platform: i386 OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-XML-LibXML AssignedTo: rnorwood(a)redhat.com ReportedBy: zby(a)post.cz CC: fedora-perl-devel-list(a)redhat.com Description of problem: I study xpath functions using perl's XML::LibXML and the result of one of my tests makes perl to end abnormaly dumping a backtrace and the memory map. I would expect either 0, undef, the xpath's "Invalid expression" or compile (sytax) error to result no matter how the xpath function is build or stated in the code. Version-Release number of selected component (if applicable): 2.6.20-1.2933.fc6 #1 SMP Mon Mar 19 10:42:48 EDT 2007 i686 i686 i386 GNU/Linux perl-5.8.8-10 perl-XML-LibXML-1.58-2.2.2.1 How reproducible: a single occurence - a technology study Steps to Reproduce: 1. 2. 3. Actual results: SIGABRT Expected results: 0, undef, the "Invalid expression" Xpath error or compile (sytax) error Additional info: Datiled steps I did are in the attachement ------- Additional Comments From zby(a)post.cz 2007-03-29 04:58 EST ------- Created an attachment (id=151183) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151183&action=view) error dump plus history -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 2

[Bug 228470] New: LibXML failing under mod_perl (missing initialization code in .xs)
by Red Hat Bugzilla 27 Feb '08

27 Feb '08

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228470 Summary: LibXML failing under mod_perl (missing initialization code in .xs) Product: Fedora Core Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: high Priority: normal Component: perl-XML-LibXML AssignedTo: rnorwood(a)redhat.com ReportedBy: misch(a)czechin.cz CC: fedora-perl-devel-list(a)redhat.com Description of problem: Version-Release number of selected component (if applicable): perl-XML-LibXML-1.58-2.2.2.1 How reproducible: Easily. Steps to Reproduce: 1. run following program under mod_perl or SpeedyCGI or any similar persistent perl interpreter (not /usr/bin/perl, as it is not persistent): use XML::Simple; XMLin('/path/to/any/valid/xml/file.xml') && print "OK" Actual results: first run prints "OK", second run dies with message: Couldn't create file parser context for file "/path/to/any/valid/xml/file.xml": No such file or directory at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/XML/LibXML.pm line 427. Expected results: "OK" Additional info: This bug is already documented in Debian's bug-tracking system, please look there: http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=240334 Basicaly, there is missing one initialization block in LibXML library for perl, which causes it to work correctly when running under non-persistent Perl interpreter, but fails under persistent Perl (eg. mod_perl, etc.). I assigned it a "high" level priority, because this bug effectively disables all functionality of mod_perl modules which are using LibXML, and it is impossible to get around this bug :(((. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

perl-devel May 2007