https://bugzilla.redhat.com/show_bug.cgi?id=849703
Bug ID: 849703
QA Contact: extras-qa(a)fedoraproject.org
Severity: unspecified
Version: 16
Priority: unspecified
CC: cweyl(a)alumni.drew.edu, 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
Assignee: mmaslano(a)redhat.com
Summary: Regular Expression matching in signal handler causes
side-effects
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: tim(a)electronghost.co.uk
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: perl
Product: Fedora
Description of problem:
Executing an RE inside a PERL deferred signal handler causes an unwanted side
effect on RE-execution in the code that was being executed when the signal
arrived.
Version-Release number of selected component (if applicable):
"This is perl 5, version 14, subversion 2 (v5.14.2) built for
x86_64-linux-thread-multi"
How reproducible:
Always
Steps to Reproduce:
Here is a test case:
====== CUT HERE ======
#!/usr/bin/env perl
sub sighup {
my $bar="This-Has-Dashes-HUP";
$bar=~s/.*-//;
print "$bar\n";
}
$SIG{'HUP'}=\&sighup;
while (1) {
my $foo="This:Has:Colons";
$foo=~s/.*://;
if ($foo=~m/:/) {
print "BUG!!: $foo\n";
}
}
====== CUT HERE ======
Run this endless loop and arrange to send it a SIGHUP once per second.
Actual results:
You will see output like the following:
bash$ perl ./t.pl
HUP
HUP
HUP
HUP
BUG!!: This:Has:Colons
HUP
HUP
BUG!!: This:Has:Colons
HUP
BUG!!: This:Has:Colons
HUP
BUG!!: This:Has:Colons
HUP
HUP
BUG!!: This:Has:Colons
HUP
BUG!!: This:Has:Colons
HUP
HUP
BUG!!: This:Has:Colons
HUP
HUP
HUP
BUG!!: This:Has:Colons
Expected results:
You should get output like this (observed on "This is perl 5, version 12,
subversion 4 (v5.12.4) built for x86_64-linux-thread-multi" from Fedora 15):
bash$ perl ./t.pl
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
Additional info:
This is not a crash, like 809796, though they are very likely related or the
same problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=907464
Bug ID: 907464
Summary: cpanm bundle lots of library and is not listed on
fesco page
Product: Fedora
Version: 18
Component: perl-App-cpanminus
Severity: unspecified
Priority: unspecified
Reporter: misc(a)zarb.org
Blocks: 504493 (DuplicSysLibsTracker)
According to the comment in the spec, and the source of cpanm, there is lots of
perl modules bundle into the main software. While the way cpanm work kinda
mandate it, I think there should be some tracking for it, only for security
update reasons.
I would suggest to contact fesco and see what to do ( ie, either unbundle, or
get a bundle exception, and list the module on the appropriate page, with
appropriate provides bundled(foo) tags )
--
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=ZNgmNZvNOV&a=cc_unsubscribe
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=952281
Bug ID: 952281
Summary: perl-App-cpanminus: does not build from source code
Product: Fedora
Version: rawhide
Component: perl-App-cpanminus
Severity: unspecified
Priority: unspecified
Assignee: mmaslano(a)redhat.com
Reporter: fweimer(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: mmaslano(a)redhat.com,
perl-devel(a)lists.fedoraproject.org
Category: ---
This package bundles Perl sources obfuscated using App::FatPacker, which makes
it very difficult to review. Please remove the obfuscated code and replace it
with proper dependencies.
(I have verified that the bundled version of Parse/CPAN/Meta.pm is actually
used by putting a "die;" into it, which was executed.)
--
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=bXs6IZqyJd&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1021161
Bug ID: 1021161
Summary: Perl mktime() still not Y2K38 compatible (even it
should be)?
Product: Fedora
Version: 18
Component: perl
Severity: medium
Assignee: jplesnik(a)redhat.com
Reporter: redhat-bugzilla(a)linuxnetz.de
QA Contact: extras-qa(a)fedoraproject.org
CC: cweyl(a)alumni.drew.edu, iarnell(a)gmail.com,
jplesnik(a)redhat.com, kasal(a)ucw.cz,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
psabata(a)redhat.com, rc040203(a)freenet.de,
tcallawa(a)redhat.com
Description of problem:
According to http://search.cpan.org/~jesse/perl-5.12.0/pod/perl5120delta.pod,
Perl 5.12 (and later) should be Y2K38 compatible. However POSIX::mktime() for
2040 is still returning undef. I am wondering about "Sizeof time_t = 4" in the
build log for i686 as well, shouldn't that be 8 when using -Duse64bitint and/
or -Duselongdouble? Or am I on the wrong path?
Version-Release number of selected component (if applicable):
perl-5.16.3-244.fc18
How reproducible:
Run the following on a 32 bit system:
perl -e 'use POSIX; print mktime(0, 0, 0, 1, 0, 140, 0, 0) . "\n"'
Actual results:
Perl mktime() still not Y2K38 compatible (even it should be)?
Expected results:
2208985200 :)
--
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=6jneoVeN3K&a=cc_unsubscribe