[Bug 193818] New: spamd should start before sendmail
by Red Hat Bugzilla
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=193818
Summary: spamd should start before sendmail
Product: Fedora Core
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: spamassassin
AssignedTo: wtogami(a)redhat.com
ReportedBy: oliva(a)lsd.ic.unicamp.br
CC: fedora-perl-devel-
list@redhat.com,felicity@kluge.net,jm(a)jmason.org,parkerm
@pobox.com,reg+redhat@sidney.com,wtogami(a)redhat.com
Description of problem:
Users that rely on spamc/spamd for mail delivery might face silent mail delivery
failure if spamd is not running when sendmail attempts to deliver them e-mail.
Starting spamd before sendmail would reduce the probability of such a problem.
Version-Release number of selected component (if applicable):
sendmail-8.13.6-1
spamassassin-3.1.2-1.fc6
How reproducible:
Every time
Steps to Reproduce:
1.Boot up
Actual results:
spamd starts after sendmail
Expected results:
It should start before
Additional info:
both are S80, which causes sendmail to start first since it sorts alphabetically
before spamd.
--
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.
17 years, 4 months
[Bug 175439] New: [FC4 Regression]: spamc doesn't use localhost by default
by Red Hat Bugzilla
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=175439
Summary: [FC4 Regression]: spamc doesn't use localhost by default
Product: Fedora Core
Version: fc4
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: spamassassin
AssignedTo: wtogami(a)redhat.com
ReportedBy: hongjiu.lu(a)intel.com
CC: fedora-perl-devel-
list@redhat.com,felicity@kluge.net,jm(a)jmason.org,parkerm
@pobox.com,reg+redhat@sidney.com,wtogami(a)redhat.com
I have
:0fw
| /usr/bin/spamc
in /etc/procmailrc. It worked with FC3. But after upgrading to FC4, I got
Dec 10 08:38:45 ocean spamd[27833]: unauthorized connection from
gate.in.lucon.org [192.168.10.1] at port 32823
My machine has
eth0 Link encap:Ethernet HWaddr 00:07:E9:9C:3E:3E
inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fe80::207:e9ff:fe9c:3e3e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5662 errors:0 dropped:0 overruns:0 frame:0
TX packets:5908 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1160392 (1.1 MiB) TX bytes:2571450 (2.4 MiB)
It looks like spamc is connecting to 192.168.10.1 instead of 127.0.0.1.
--
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.
17 years, 5 months
[Bug 200440] New: Building perl-5.8.8-8 without threading fails
by Red Hat Bugzilla
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=200440
Summary: Building perl-5.8.8-8 without threading fails
Product: Fedora Core
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: dansut(a)tcnow.com
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
Building perl-5.8.8-8 without threading fails with a straightfoward syntax error.
Version-Release number of selected component (if applicable):
perl-5.8.8-8
How reproducible:
easy
Steps to Reproduce:
1. change %define threading 0
2. rpmbuild -ba perl.spec
Additional info:
Problem is in the perl-5.8.8-R-switch.patch
Where S_init_perllib()definition changed the 'pTHX,' should be 'pTHX_'
--
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.
17 years, 6 months
[Bug 191416] New: h2ph generates incorrect code for '#if defined A || defined B'
by Red Hat Bugzilla
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=191416
Summary: h2ph generates incorrect code for '#if defined A ||
defined B'
Product: Fedora Core
Version: devel
Platform: All
URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39130
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@redhat.com,prockai(a)redhat.com
+++ This bug was initially created as a clone of Bug #191409 +++
Description of problem:
This is perlbug #39130 - see URL .
For cpp statements like :
#if defined A || defined B
h2ph would generate the code :
if(defined (defined(&A) ? &A : 0) || defined (defined(&B) ? &B : 0)) {
which is tautologous, as defined(0) is always true .
This turns out to cause real problems on the Linux ppc64 platform,
where "endian-ness" is selectable in the compiler; every inclusion
of "endian.ph", which includes "bits/endian.ph", generates an error:
$ perl -e 'require "sys/socket.ph";'
Both BIG_ENDIAN and LITTLE_ENDIAN defined! at
/usr/lib/perl5/5.8.8/ppc-linux-thread-multi/bits/endian.ph line 10.
Compilation failed in require at...
Because h2ph generated this code in ../bits/endian.ph:
if(defined (defined(&__BIG_ENDIAN__) ? &__BIG_ENDIAN__ : 0) || defined
(defined(&_BIG_ENDIAN) ? &_BIG_ENDIAN : 0)) {
if(defined (defined(&__LITTLE_ENDIAN__) ? &__LITTLE_ENDIAN__ : 0) || defined
(defined(&_LITTLE_ENDIAN) ? &_LITTLE_ENDIAN : 0)) {
die("Both\ BIG_ENDIAN\ and\ LITTLE_ENDIAN\ defined\!");
}
For the cpp code in /usr/include/bits/endian.h:
#if defined __BIG_ENDIAN__ || defined _BIG_ENDIAN
# if defined __LITTLE_ENDIAN__ || defined _LITTLE_ENDIAN
# error Both BIG_ENDIAN and LITTLE_ENDIAN defined!
...
The problem does not happen if the 'defined..' conditions are in parentheses -
ie.
#if defined(A) || defined(B)
produces correct code:
if( defined(&A) || defined(&B) )
A trivial fix for this is to simply replace the ': 0' with ': undef' in
h2ph.PL line 517, as with this patch:
--- perl-5.8.8/utils/h2ph.PL~ 2006-01-12 17:55:04.000000000 -0500
+++ perl-5.8.8/utils/h2ph.PL 2006-05-11 13:50:04.000000000 -0400
@@ -514,7 +514,7 @@
}
} else {
if ($inif && $new !~ /defined\s*\($/) {
- $new .= '(defined(&' . $id . ') ? &' . $id . ' : 0)';
+ $new .= '(defined(&' . $id . ') ? &' . $id . ' : undef)';
} elsif (/^\[/) {
$new .= " \$$id";
} else {
Version-Release number of selected component (if applicable):
ALL
How reproducible:
100%
Steps to Reproduce:
On a ppc64 platform with select-able endian-ness:
# perl -e 'require "sys/socket.ph";'
Actual results:
Both BIG_ENDIAN and LITTLE_ENDIAN defined! at
/usr/lib/perl5/5.8.8/ppc-linux-thread-multi/bits/endian.ph line 10.
Compilation failed in require at...
Expected results:
no error
--
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.
17 years, 6 months
[Bug 199152] New: url(-relative=>1) is broken in CGI.pm
by Red Hat Bugzilla
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=199152
Summary: url(-relative=>1) is broken in CGI.pm
Product: Red Hat Web Application Stack
Version: LAMPv1
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: jvdias(a)redhat.com
QAContact: gozen(a)redhat.com
CC: fedora-perl-devel-list@redhat.com,jorton(a)redhat.com
+++ This bug was initially created as a clone of Bug #188441 +++
Description of problem:
url(-relative) no longer returns the original relative path before rewrites.
This used to work in FC4.
Version-Release number of selected component (if applicable):
perl-5.8.8-4
How reproducible:
100%
Steps to Reproduce:
1. Set up a redirect in your .htaccess file such as:
RewriteEngine On
RewriteBase /
RewriteRule ^testabc.cgi$ test.cgi
2. Create a test perl script, test.cgi such as:
#!/usr/bin/perl
use CGI qw/:standard -no_xhtml/;
print "Content-type: text/plain\n\n";
print url(-relative=>1), "\n";
print url(-absolute=>1), "\n";
3. Look at the web page /testabc.cgi
Actual results:
test.cgi
/testabc.cgi
Expected results:
testabc.cgi
/testabc.cgi
Additional info:
-- Additional comment from jvdias(a)redhat.com on 2006-04-12 17:16 EST --
Hmmm, this does not seem to be a problem with perl's CGI:: module -
I put your rewrite rule in /etc/httpd/conf/httpd.conf's /var/www/cgi-bin/
'Directory' entry, from the standard config from a clean install of
httpd-2.2.0-6 , so it now reads:
---
<Directory "/var/www/cgi-bin">
AllowOverride None
Options FollowSymLinks
Order allow,deny
Allow from all
RewriteEngine On
RewriteBase /cgi-bin
RewriteRule ^testabc.cgi$ test.cgi
</Directory>
---
NOTE: before the server would process the rewrite rule, it insisted that
the FollowSymLinks or FollowSymLinks owner option be specified - without
one of these options enabled, rewrite rules will be ignored.
Then your example test.cgi script works as expected, producing the output:
testabc.cgi
/testabc.cgi
Perhaps your http server is not loading your .htaccess file correctly /
doesn't allow the FollowSymLinks or RewriteRule options ?
I'm CC-ing the httpd maintainer on this - perhaps he could shed some light on
why the rewrite rule might not be taking effect.
If the rewrite rule is correctly applied, the perl CGI module seems to have
no problem with url(-relative=>1) / url(-absolute=>1) .
-- Additional comment from jvdias(a)redhat.com on 2006-04-12 17:49 EST --
Sorry - my mistake - I was looking at the wrong output - it does produce :
test.cgi
/testabc.cgi.
This is a CPAN CGI module bug:
http://rt.cpan.org/Public/Bug/Display.html?id=18500
I'll try out the patch from the above bug (now in CGI 3.17) and see if it
fixes the problem - if so, it can go into the next perl-5.8.8-6+ release.
-- Additional comment from jvdias(a)redhat.com on 2006-04-12 18:53 EST --
OK, I now see the problem - CGI.pm-3.15 has a new "-rewrite" sub url() parameter,
which, if 0, is meant to make url() return the "$SCRIPT_NAME", not the
"$REQUEST_URI". It seems the programmer applies this logic only in the
case of '-absolute=>1', NOT '-relative=>1'. Yes, this seems like a bug
to me - and is still in the latest 3.17 version.
Please try out the attached CGI.pm which fixes the problem - if it works OK,
I'll submit it with the next perl-5.8.8-6 version.
-- Additional comment from jvdias(a)redhat.com on 2006-04-12 18:54 EST --
Created an attachment (id=127678)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=127678&action=view)
CGI.pm (3.15) fixed to use rewritten REQUEST_URI in url() if rewrite!=0
-- Additional comment from jvdias(a)redhat.com on 2006-04-12 18:55 EST --
Sorry, should have mentioned: copy the above CGI.pm attachment to
/usr/lib/perl5/5.8.8/CGI.pm to test.
-- Additional comment from bruno(a)wolff.to on 2006-04-12 22:26 EST --
I tried this out and it looks like it is working. Thanks.
-- Additional comment from jvdias(a)redhat.com on 2006-04-13 16:30 EST --
Thanks for the testing. The fix is now checked into CVS and will go into the
next perl-5.8.8-6 release.
Upstream CPAN CGI.pm bug raised: [rt.cpan.org #18692]
http://rt.cpan.org/Ticket/Display.html?id=18692
-- Additional comment from updates(a)fedora.redhat.com on 2006-06-05 17:00 EST --
perl-5.8.8-5 has been pushed for fc5, which should resolve this issue. If these
problems are still present in this version, then please make note of it in this
bug report.
--
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.
17 years, 6 months
[Bug 185406] New: h2ph problem with gcc internal defines
by Red Hat Bugzilla
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=185406
Summary: h2ph problem with gcc internal defines
Product: Red Hat Enterprise Linux
Version: 4
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@redhat.com,prockai(a)redhat.com
+++ This bug was initially created as a clone of Bug #178343 +++
Description of problem:
> Subject: h2ph problem
> From: George Michaelson <ggm(a)apnic.net>
> To: jvdias(a)redhat.com
> Date: 2006-01-17 19:54
>
> We just got bitten by 32bit vs 64bit logic in the .ph files generated
> from socket.h/stddef.h/limits.h -bits/socket.ph to be exact.
>
> Undefined subroutine &main::__LONG_MAX__ called at (eval 436) line 1.
> Compilation failed in require at
> /usr/lib/perl5/5.8.5/i386-linux-thread-multi/sy s/socket.ph line 11.
> Compilation failed in require at
> /usr/lib/perl5/site_perl/5.8.5/i386-linux-threa d-multi/netinet/in.ph line
> 9.
>
>
> By removing some if/then/else logic, to make it just eval() the 32-bit
> case, the problem went away.
>
> this was after applying an up2date on EL4 for perl 5.8.5:
>
> [ggm@curry log]$ uname -a
> Linux curry.apnic.net 2.6.9-22.0.1.ELsmp #1 SMP Tue Oct 18 18:39:27 EDT
> 2005 i686 i686 i386 GNU/Linux [ggm@curry log]$ rpmquery -a | grep perl
> newt-perl-1.08-7
> mod_perl-1.99_16-4
> perl-Net-DNS-0.48-1
> perl-Time-HiRes-1.55-3
> perl-5.8.5-24.RHEL4
> perl-Filter-1.30-6
> perl-URI-1.30-4
> perl-Digest-SHA1-2.07-5
> perl-Digest-HMAC-1.01-13
> [ggm@curry log]$
>
> the RPM errata lists
>
> > * Tue Nov 01 2005 Jason Vas Dias <jvdias(a)redhat.com> - 3:5.8.5-17.RHEL4
> > - fix bug 170088: broken h2ph fixed with h2ph from 5.8.7
> > - fix bug 171111 / upstream bug 37535: IOCPARM_LEN should be _IOC_SIZE
> > - fix bug 172236: make h2ph pick up gcc built-in include directory
>
> Is it possible you haven't tested enough of the outcomes here? Without
> this, the perl just doesn't work.
>
> -George
>
> --- socket.ph.dist 2006-01-17 16:44:41.000000000 +1000
> +++ socket.ph 2006-01-17 16:44:49.000000000 +1000
> @@ -90,11 +90,7 @@
> eval 'sub SOL_IRDA () {266;}' unless defined(&SOL_IRDA);
> eval 'sub SOMAXCONN () {128;}' unless defined(&SOMAXCONN);
> require 'bits/sockaddr.ph';
> - if((defined(&ULONG_MAX) ? &ULONG_MAX : 0) > 0xffffffff) {
> - eval 'sub __ss_aligntype () { &__uint64_t;}' unless
> defined(&__ss_aligntype); - } else {
> eval 'sub __ss_aligntype () { &__uint32_t;}' unless
> defined(&__ss_aligntype); - }
> eval 'sub _SS_SIZE () {128;}' unless defined(&_SS_SIZE);
> eval 'sub _SS_PADSIZE () {( &_SS_SIZE - (2* $sizeof{
> &__ss_aligntype}));}' unless defined(&_SS_PADSIZE); eval("sub MSG_OOB () {
> 0x01; }") unless defined(&MSG_OOB);
Version-Release number of selected component (if applicable):
ALL - including RHEL-4 perl-5.8.5-*
not a problem with RHEL-3 perl-5.8.0, because gcc-3.2.3's limits.h #defines
things like __LONG_MAX__
How reproducible:
100%
Steps to Reproduce:
$ perl -e 'require "sys/socket.ph";'
Actual results:
Undefined subroutine &main::__LONG_MAX__ called at (eval 256) line 1.
Compilation failed in require at
/usr/lib/perl5/5.8.6/i386-linux-thread-multi/sys/socket.ph line 11.
Compilation failed in require at -e line 1.
Expected results:
no errors
-- Additional comment from jvdias(a)redhat.com on 2006-01-19 12:20 EST --
Now that h2ph correctly picks up the gcc C standard includes, such as limits.h,
from the gcc internal include directory (ie. /usr/lib/gcc/*.../include),
which it was not doing before, due to bug 172236, some perl .ph files cannot be
included because they refer to the newer gcc versions 'internal definitions' such
as __INT_MAX__ / __LONG_MAX__ , which are no longer #define'd in any header file,
but are 'built-in' to the newer gcc compilers, in the same way as __FILE__ or
__LINE__ :
$ echo 'int main(int argc, char **argv, char **envp)
{ long l=__LONG_MAX__; printf( "%ld\n",l); };' >tlm.c
( NOTE: no files are #include-ed )
$ gcc -o tlm tlm.c$ gcc -o tlm tlm.c
tlm.c: In function ‘main’:
tlm.c:1: warning: incompatible implicit declaration of built-in function ‘printf’
$ ./tlm
2147483647
gcc's C standard headers define constants such as LONG_MAX / INT_MAX in terms
of these internal definitions:
$ egrep 'define\ (INT|LONG)_MAX' limits.h
#define INT_MAX __INT_MAX__
#define LONG_MAX __LONG_MAX__
During the generation of the perl platform h2ph includes, we should create a
file included by limits.ph that includes definitions for all the gcc
'internal definitions' such as __LONG_MAX__ that might be referenced .
-- Additional comment from jvdias(a)redhat.com on 2006-01-19 12:57 EST --
Created an attachment (id=123451)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=123451&action=view)
Program to produce perl header for C built-in definitions
Something like the output of this program needs to be prepended to limits.ph
during the build of the perl h2ph platform headers .
-- Additional comment from rc040203(a)freenet.de on 2006-01-19 13:15 EST --
I must be missing something, but why do you try to extract GCC proprietary,
internals?
#include <limits.h> and printing the corresponding POSIX defines would be portable.
C.f. http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
-- Additional comment from jvdias(a)redhat.com on 2006-01-19 15:54 EST --
RE: Comment #3:
/usr/include/limits.h just #includes' gcc's limits.h, unless '__GNUC__ < 2',
and gcc's limits.h would in any case be found first in by a
'#include <limits.h>' .
The whole issue of h2ph and perl's platform includes needs a major revamp, which
it will get once perl-5.8.8 comes out (soon, I hope).
-- Additional comment from jvdias(a)redhat.com on 2006-01-31 13:07 EST --
OK, it wasn't fixed in 5.8.8. I've now raised upstream perl bug
#38385 : http://rt.perl.org/rt3/Ticket/Display.html?id=38385
on this issue, which includes a patch to fix it.
This will be fixed in the next perl releases for RHEL-4, FC-4, and FC-5
(RHEL-3 is unaffected).
-- Additional comment from jvdias(a)redhat.com on 2006-02-02 18:15 EST --
Created an attachment (id=124075)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124075&action=view)
Program to include cpp internal built-in macros in system _h2ph_pre.ph
-- Additional comment from jvdias(a)redhat.com on 2006-02-02 18:21 EST --
This problem is fixed with perl-5.8.8-1 in FC-5, with the patch sent upstream,
which checks for the existence of cpp internal built-ins in Configure, and
writes them to $Config{cppsymbols} so they are correctly written to _h2ph_pre.pl.
This patch will be applied to subsequent perl releases for FC-4 and RHEL-4 ,
but this problem probably does not warrant a complete perl respin just to fix it.
Meanwhile, simply run the 'patch_h2ph_pre.pl' script attached above, as root,
and the system _h2ph_pre.ph (which gets included by every perl header file) will
be patched to define cpp built-ins it does not already define .
-- Additional comment from updates(a)fedora.redhat.com on 2006-03-13 17:12 EST --
>From User-Agent: XML-RPC
perl-5.8.6-24 has been pushed for FC4, which should resolve this issue. If
these problems are still present in this version, then please make note of it in
this bug report.
--
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.
17 years, 6 months
[Bug 199149] New: upstream perl bugs fixed since 5.8.8 was released
by Red Hat Bugzilla
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=199149
Summary: upstream perl bugs fixed since 5.8.8 was released
Product: Red Hat Web Application Stack
Version: LAMPv1
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: jvdias(a)redhat.com
QAContact: gozen(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
+++ This bug was initially created as a clone of Bug #194077 +++
Description of problem:
These upstream perl bugs / issue have beed fixed in the upstream
5.8.x maintenance release of perl since perl-5.8.8 was released:
o 38454 - 'rindex corrects for $[ on bytes rather than UTF-8'
http://rt.perl.org/rt3/index.html?q=38454
apply upstream patch #27116
o 24816 - 'Magic vars seem unsure if they are purely numeric'
http://rt.perl.org/rt3/index.html?q=24816
( perl -wle 'print $? = $? ^ "3"' -> 'Argument "^C" isn't numeric' )
apply upstream patch #27391
o Avoid writing over the input string in the case 'F' in moreswitches.
apply upstream patch #27426
o 34925 - 'overload and rebless'
http://rt.perl.org/rt3/index.html?q=34925
apply upstream patches #27509, #27512
o 34297:
'utf8 overload stringify bug (utf8 caching maybe)'
upstream patch #28006 applied
o 3038 - '$qr = qr/^a$/m; $x =~ $qr; fails'
http://rt.perl.org/rt3/index.html?q=3038
apply upstream patch #27604
o apply upstream patch #27605 - 'Fix off-by-one in $0 set magic.'
o 23141 - '($_) = () fails to set $_ to undef'
http://rt.perl.org/rt3/index.html?q=23141
apply upstream patch #27914
o 38619 - 'Bug in lc and uc (interaction between UTF-8, substr, and lc/uc)'
http://rt.perl.org/rt3/index.html?q=38619
apply upstream patch #27329
Version-Release number of selected component (if applicable):
perl-5.8.8-4
How reproducible:
100%
Steps to Reproduce:
See upstream bug reports and the new RHTS test cases in CVS perl/perl-tests/FC6 .
-- Additional comment from jvdias(a)redhat.com on 2006-06-05 13:36 EST --
Fixed in perl-5.8.8-6 (FC-6) and perl-5.8.8-5 (FC5).
--
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.
17 years, 6 months
[Bug 178343] New: h2ph problem with gcc internal defines
by Red Hat Bugzilla
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=178343
Summary: h2ph problem with gcc internal defines
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:
> Subject: h2ph problem
> From: George Michaelson <ggm(a)apnic.net>
> To: jvdias(a)redhat.com
> Date: 2006-01-17 19:54
>
> We just got bitten by 32bit vs 64bit logic in the .ph files generated
> from socket.h/stddef.h/limits.h -bits/socket.ph to be exact.
>
> Undefined subroutine &main::__LONG_MAX__ called at (eval 436) line 1.
> Compilation failed in require at
> /usr/lib/perl5/5.8.5/i386-linux-thread-multi/sy s/socket.ph line 11.
> Compilation failed in require at
> /usr/lib/perl5/site_perl/5.8.5/i386-linux-threa d-multi/netinet/in.ph line
> 9.
>
>
> By removing some if/then/else logic, to make it just eval() the 32-bit
> case, the problem went away.
>
> this was after applying an up2date on EL4 for perl 5.8.5:
>
> [ggm@curry log]$ uname -a
> Linux curry.apnic.net 2.6.9-22.0.1.ELsmp #1 SMP Tue Oct 18 18:39:27 EDT
> 2005 i686 i686 i386 GNU/Linux [ggm@curry log]$ rpmquery -a | grep perl
> newt-perl-1.08-7
> mod_perl-1.99_16-4
> perl-Net-DNS-0.48-1
> perl-Time-HiRes-1.55-3
> perl-5.8.5-24.RHEL4
> perl-Filter-1.30-6
> perl-URI-1.30-4
> perl-Digest-SHA1-2.07-5
> perl-Digest-HMAC-1.01-13
> [ggm@curry log]$
>
> the RPM errata lists
>
> > * Tue Nov 01 2005 Jason Vas Dias <jvdias(a)redhat.com> - 3:5.8.5-17.RHEL4
> > - fix bug 170088: broken h2ph fixed with h2ph from 5.8.7
> > - fix bug 171111 / upstream bug 37535: IOCPARM_LEN should be _IOC_SIZE
> > - fix bug 172236: make h2ph pick up gcc built-in include directory
>
> Is it possible you haven't tested enough of the outcomes here? Without
> this, the perl just doesn't work.
>
> -George
>
> --- socket.ph.dist 2006-01-17 16:44:41.000000000 +1000
> +++ socket.ph 2006-01-17 16:44:49.000000000 +1000
> @@ -90,11 +90,7 @@
> eval 'sub SOL_IRDA () {266;}' unless defined(&SOL_IRDA);
> eval 'sub SOMAXCONN () {128;}' unless defined(&SOMAXCONN);
> require 'bits/sockaddr.ph';
> - if((defined(&ULONG_MAX) ? &ULONG_MAX : 0) > 0xffffffff) {
> - eval 'sub __ss_aligntype () { &__uint64_t;}' unless
> defined(&__ss_aligntype); - } else {
> eval 'sub __ss_aligntype () { &__uint32_t;}' unless
> defined(&__ss_aligntype); - }
> eval 'sub _SS_SIZE () {128;}' unless defined(&_SS_SIZE);
> eval 'sub _SS_PADSIZE () {( &_SS_SIZE - (2* $sizeof{
> &__ss_aligntype}));}' unless defined(&_SS_PADSIZE); eval("sub MSG_OOB () {
> 0x01; }") unless defined(&MSG_OOB);
Version-Release number of selected component (if applicable):
ALL - including RHEL-4 perl-5.8.5-*
not a problem with RHEL-3 perl-5.8.0, because gcc-3.2.3's limits.h #defines
things like __LONG_MAX__
How reproducible:
100%
Steps to Reproduce:
$ perl -e 'require "sys/socket.ph";'
Actual results:
Undefined subroutine &main::__LONG_MAX__ called at (eval 256) line 1.
Compilation failed in require at
/usr/lib/perl5/5.8.6/i386-linux-thread-multi/sys/socket.ph line 11.
Compilation failed in require at -e line 1.
Expected results:
no errors
--
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.
17 years, 6 months
[Bug 188441] New: url(-relative=>1) is broken in CGI.pm
by Red Hat Bugzilla
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=188441
Summary: url(-relative=>1) is broken in CGI.pm
Product: Fedora Core
Version: fc5
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: bruno(a)wolff.to
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
url(-relative) no longer returns the original relative path before rewrites.
This used to work in FC4.
Version-Release number of selected component (if applicable):
perl-5.8.8-4
How reproducible:
100%
Steps to Reproduce:
1. Set up a redirect in your .htaccess file such as:
RewriteEngine On
RewriteBase /
RewriteRule ^testabc.cgi$ test.cgi
2. Create a test perl script, test.cgi such as:
#!/usr/bin/perl
use CGI qw/:standard -no_xhtml/;
print "Content-type: text/plain\n\n";
print url(-relative=>1), "\n";
print url(-absolute=>1), "\n";
3. Look at the web page /testabc.cgi
Actual results:
test.cgi
/testabc.cgi
Expected results:
testabc.cgi
/testabc.cgi
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.
17 years, 6 months
[Bug 172739] New: Deep recursion in CGI::Carp::warn
by Red Hat Bugzilla
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=172739
Summary: Deep recursion in CGI::Carp::warn
Product: Fedora Core
Version: fc4
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: jorris(a)redhat.com
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
CGI::Carp::Warn experiences deep recursion when hit, followed by a segmentation
fault. This can make developing any web applications using CGI::Carp::Warn
difficult, as any trivial warning will cause pages of log output followed by a
crash.
See https://rt.perl.org/rt3/Ticket/Display.html?id=36521 for details and
possible patches.
Version-Release number of selected component (if applicable):
perl-5.8.6-15
How reproducible:
Always
Steps to Reproduce:
Execute script:
#!/usr/bin/perl
use CGI::Carp qw(fatalsToBrowser);
use diagnostics;
warn "foo";
Results:
Deeply nested warning message followed by segfault.
--
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.
17 years, 6 months