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=204093
Summary: perl -i resets file ACLs and EAs
Product: Fedora Core
Version: fc5
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: rnorwood(a)redhat.com
ReportedBy: josh(a)jbc.edu
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
When perl's -i option is used to do an in-place edit of a file, it resets the
ACLs and extended attributes on that file.
Since perl -i can be a very helpful tool for scripting and system
administration, it would be nice if it preserved ACLs and EAs.
Version-Release number of selected component (if applicable):
perl-5.8.8-5
How reproducible:
always
Steps to Reproduce:
1. touch testfile
2. setfacl -m u:testuser:r testfile
3. setfattr -n user.test testfile
4. perl -pi -e 's/Something/SomethingElse/' testfile
5. getfacl testfile; getfattr testfile
Actual results:
Nothing.
Expected results:
ACLs and EAs set in steps 2 and 3 above.
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.
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=176889
Summary: many missing files when rebuilding per-XML-Grove
Product: Fedora Core
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl-XML-Grove
AssignedTo: jvdias(a)redhat.com
ReportedBy: jkeating(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Please see attached log.
------- Additional Comments From jkeating(a)redhat.com 2006-01-03 20:49 EST -------
Created an attachment (id=122741)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=122741&action=view)
build failure log
--
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.
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=176888
Summary: perl-RPM-Specfile can't find
/usr/share/man/man3/RPM::Specfile.3pm when being built
Product: Fedora Core
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl-RPM-Specfile
AssignedTo: jvdias(a)redhat.com
ReportedBy: jkeating(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Please see attached log.
------- Additional Comments From jkeating(a)redhat.com 2006-01-03 20:48 EST -------
Created an attachment (id=122740)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=122740&action=view)
build failure log
--
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.
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=228433
Summary: perl-version: EPEL branch?
Product: Fedora Extras
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: normal
Component: perl-version
AssignedTo: tcallawa(a)redhat.com
ReportedBy: cweyl(a)alumni.drew.edu
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
A project I'm working on uses perl(version) on RHEL4. Any chance of an EPEL
branch? :)
(note -- the specfile currently uses Build.PL; as perl-Module-Build isn't
available in EPEL yet, it'll probably be necessary to switch over to the
standard Makefile.PL provided.)
--
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.
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=199736
Summary: perl C compiler Can't locate object method "IVX" via
package "B::NV"
Product: Fedora Core
Version: fc5
Platform: i386
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: timliim(a)lucent.com
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
When compile perl script into C code, modules complained
Can't locate object method "IVX" via package "B::NV"
Version-Release number of selected component (if applicable):
$ rpm -qf /usr/lib/perl5/5.8.8/i386-linux-thread-multi/B/C.pm
perl-5.8.8-5
How reproducible:
always.
Steps to Reproduce:
1. create a file tw.pl with this content:
#!/usr/bin/perl -w
use strict;
package mx;
sub new {}
#sub x { my $m = 5.1; }
1;
2. compile with this line
time perl -MO=C tw.pl > t.c
Actual results:
Got error msg
Can't locate object method "IVX" via package "B::NV" at
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/B/C.pm line 650.
CHECK failed--call queue aborted.
Expected results:
Compiling ok, produce a compilable .c file:
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.
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=229179
Summary: check_whitelist and check_spamd scripts missing.
Product: Fedora Core
Version: fc6
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: normal
Component: spamassassin
AssignedTo: wtogami(a)redhat.com
ReportedBy: m.d.t.evans(a)qmul.ac.uk
CC: fedora-perl-devel-
list@redhat.com,felicity@kluge.net,jm@jmason.org,parkerm
@pobox.com,reg+redhat@sidney.com,wtogami@redhat.com
Description of problem:
The SA source contains 2 useful perl scripts, one to maintain the autowhitelist
database file and a nagios monitoring script. It would be helpful if you could
include them. I've attached a patch below (which you will may want to tweak a bit).
Version-Release number of selected component (if applicable):
3.1.8-1.fc6
------- Additional Comments From m.d.t.evans(a)qmul.ac.uk 2007-02-19 07:00 EST -------
Created an attachment (id=148315)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148315&action=view)
Patch file for spamassassin that adds check_whitelist and check_spamd scripts.
--
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.
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=221113
Summary: readline function in perl does not correctly set $!
Product: Fedora Core
Version: fc6
Platform: i386
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: rnorwood(a)redhat.com
ReportedBy: wpilorz(a)gmail.com
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
perldoc -f readline
displays example code how do check for errors with readline:
for (;;) {
undef $!;
unless (defined( $line = <> )) {
die $! if $!;
last; # reached EOF
}
# ...
}
Unfortunately this method no longer works as described in current perl version.
I am including a short perl script readline_test.pl attempting to use that
method and bash script readline_test.bash calling that perl script 16 times;
input is either "1234" or "1234\n",
PERLIO environment variable is set to perlio or stdio,
(PERLIO=perlio is equivalent to PERLIO not set in FC6)
$/ is set to undef, not modified, \2, \1024.
$/ is set to a reference to value specified in environment variable CHUNKSIZE,
unless it is 0 ($/ not set in this case) or negative ($/ set to undef).
In correct perl implementation all 16 tests should run successfully (no die).
The results included show that PERLIO=stdio is better (4 tests fail for stdio, 6
tests fail for perlio)
Version-Release number of selected component (if applicable):
perl-5.8.8-10
How reproducible:
always
Steps to Reproduce:
1. save readline_test.pl and readline_test.bash files from attachemnts into
current directory
2. run the following command in the current directory
bash readline_test.bash
you could prefer to run
bash -vx readline_test.bash
to see exactly what is being run
Actual results:
$ bash readline_test.bash
__ running readline_test.pl for stdin=1234,CHUNKSIZE=-1,PERLIO=perlio...
INFO: $/ will be set to undef
Bad file descriptor at readline_test.pl line 30, <F> chunk 1.
__ running readline_test.pl for stdin=1234,CHUNKSIZE=-1,PERLIO=stdio...
INFO: $/ will be set to undef
Bad file descriptor at readline_test.pl line 30, <F> chunk 1.
__ running readline_test.pl for stdin=1234,CHUNKSIZE=0,PERLIO=perlio...
INFO: $/ will not be set
Bad file descriptor at readline_test.pl line 30, <F> line 1.
__ running readline_test.pl for stdin=1234,CHUNKSIZE=0,PERLIO=stdio...
INFO: $/ will not be set
Bad file descriptor at readline_test.pl line 30, <F> line 1.
__ running readline_test.pl for stdin=1234,CHUNKSIZE=2,PERLIO=perlio...
INFO: $/ will be set to 2
INFO: File /dev/stdin has been read, nbytes = 4
__ running readline_test.pl for stdin=1234,CHUNKSIZE=2,PERLIO=stdio...
INFO: $/ will be set to 2
INFO: File /dev/stdin has been read, nbytes = 4
__ running readline_test.pl for stdin=1234,CHUNKSIZE=1k,PERLIO=perlio...
INFO: $/ will be set to 1024
Bad file descriptor at readline_test.pl line 30, <F> chunk 1.
__ running readline_test.pl for stdin=1234,CHUNKSIZE=1k,PERLIO=stdio...
INFO: $/ will be set to 1024
INFO: File /dev/stdin has been read, nbytes = 4
__ running readline_test.pl for stdin=1234\n,CHUNKSIZE=-1,PERLIO=perlio...
INFO: $/ will be set to undef
Bad file descriptor at readline_test.pl line 30, <F> chunk 1.
__ running readline_test.pl for stdin=1234\n,CHUNKSIZE=-1,PERLIO=stdio...
INFO: $/ will be set to undef
Bad file descriptor at readline_test.pl line 30, <F> chunk 1.
__ running readline_test.pl for stdin=1234\n,CHUNKSIZE=0,PERLIO=perlio...
INFO: $/ will not be set
INFO: File /dev/stdin has been read, nbytes = 5
__ running readline_test.pl for stdin=1234\n,CHUNKSIZE=0,PERLIO=stdio...
INFO: $/ will not be set
Bad file descriptor at readline_test.pl line 30, <F> line 1.
__ running readline_test.pl for stdin=1234\n,CHUNKSIZE=2,PERLIO=perlio...
INFO: $/ will be set to 2
Bad file descriptor at readline_test.pl line 30, <F> chunk 3.
__ running readline_test.pl for stdin=1234\n,CHUNKSIZE=2,PERLIO=stdio...
INFO: $/ will be set to 2
INFO: File /dev/stdin has been read, nbytes = 5
__ running readline_test.pl for stdin=1234\n,CHUNKSIZE=1k,PERLIO=perlio...
INFO: $/ will be set to 1024
Bad file descriptor at readline_test.pl line 30, <F> chunk 1.
__ running readline_test.pl for stdin=1234\n,CHUNKSIZE=1k,PERLIO=stdio...
INFO: $/ will be set to 1024
INFO: File /dev/stdin has been read, nbytes = 5
Expected results:
each run of perl should complete without die and show number of bytes on input
(4 for first 8 tests, 5 for remaining tests)
Additional info:
if PERLIO=perlio is used and there is actual I/O error in data file, the
readline_test.pl dies with inappropriate error message
'Bad file descriptor' rather than 'Input/output error'
im most cases.
This can be easily shown with truncated ISO-9660 image file, loop mounted.
Should I also include test cases for this?
------- Additional Comments From wpilorz(a)gmail.com 2007-01-01 18:46 EST -------
Created an attachment (id=144615)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=144615&action=view)
readline_test.pl test script
--
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.
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=198399
Summary: Package perl lacks IPv6 support
Product: Fedora Core
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: pvrabec(a)redhat.com
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list@redhat.com,mbacovsk@redhat.com
This bug was reported automaticaly in connection with IPv6 project.
Our aim is to support IPv6 in all Fedora Core packages so FC6 and RHEL5 will be ready for IPv6.
This package seems to lack IPv6 support as is illustrated in attached log.
Here follows part of scanning log (grep -r F_INET *)/up to 30 lines:
/perl-5.8.8/pp_sys.c:2369:#if defined (HAS_SOCKETPAIR) || (defined (HAS_SOCKET) && defined(SOCK_DGRAM) && defined(AF_INET) && defined(PF_INET))
/perl-5.8.8/pp_sys.c:2742: if (((struct sockaddr *)SvPVX_const(sv))->sa_family == AF_INET &&
/perl-5.8.8/vms/sockadapt.c:122: if (addr->sa_family == AF_INET &&
/perl-5.8.8/vms/sockadapt.h:115:#ifndef AF_INET
/perl-5.8.8/vms/sockadapt.h:116:# define AF_INET 2
/perl-5.8.8/util.c:4166:#if !defined(HAS_SOCKETPAIR) && defined(HAS_SOCKET) && defined(AF_INET) && defined(PF_INET) && defined(SOCK_DGRAM) && defined(HAS_SELECT)
/perl-5.8.8/util.c:4185: sockets[i] = PerlSock_socket(AF_INET, SOCK_DGRAM, PF_INET);
/perl-5.8.8/util.c:4189: addresses[i].sin_family = AF_INET;
/perl-5.8.8/util.c:4311:#if !defined(HAS_SOCKETPAIR) && defined(HAS_SOCKET) && defined(AF_INET) && defined(PF_INET)
/perl-5.8.8/util.c:4342: listener = PerlSock_socket(AF_INET, type, 0);
/perl-5.8.8/util.c:4346: listen_addr.sin_family = AF_INET;
/perl-5.8.8/util.c:4355: connector = PerlSock_socket(AF_INET, type, 0);
/perl-5.8.8/mpeix/mpeix.c:511: /* AF_INET socket */
/perl-5.8.8/mpeix/mpeix.c:713: if (address->sa_family == AF_INET
/perl-5.8.8/mpeix/mpeix.c:724: if (address->sa_family == AF_INET)
/perl-5.8.8/mpeix/mpeix.c:750: && address->sa_family == AF_INET
/perl-5.8.8/mpeix/mpeix.c:799: result = 30000; /* AF_INET sock max */
--
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.
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=228043
Summary: ??? 64bit sa-update.1 manpage timestamp differs from
32bit?
Product: Fedora Core
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: spamassassin
AssignedTo: wtogami(a)redhat.com
ReportedBy: wtogami(a)redhat.com
CC: fedora-perl-devel-
list@redhat.com,felicity@kluge.net,jm@jmason.org,parkerm
@pobox.com,reg+redhat@sidney.com,wtogami@redhat.com
Odd minor problem... low priority.
/usr/share/man/man1/sa-update.1.gz differs by the following unidiff between the
32bit and 64bit architecture builds of spamassassin.
--- 32 2007-02-09 12:46:19.000000000 -0500
+++ 64 2007-02-09 12:46:10.000000000 -0500
@@ -129,7 +129,7 @@
.\" ========================================================================
.\"
.IX Title "SA-UPDATE 1"
-.TH SA-UPDATE 1 "2006-07-30" "perl v5.8.5" "User Contributed Perl Documentation"
+.TH SA-UPDATE 1 "2007-01-22" "perl v5.8.5" "User Contributed Perl Documentation"
.SH "NAME"
sa\-update \- automate SpamAssassin rule updates
.SH "SYNOPSIS"
This appears to be the only difference in version 3.1.7. Notice that the 32bit
version retained the original source timestamp, while the 64bit version somehow
decided to differ in this behavior by changing the timestamp to the build date.
The above example is 3.1.7 built on RHEL4, but this persists through perl-5.8.8
in FC7 too.
While this appears to create a multilib conflict, in practice this is not a real
problem because spamassassin is based on perl, and we don't ship both archs in a
multilib distribution.
This bug is merely to figure out *why* it is behaving in this strange way
betweeen 32bit and 64bit builds.
--
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.
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=232481
Summary: EPEL branches: a couple of perl packages from fedora.us
Product: Fedora Extras
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: perl-pmtools
AssignedTo: jpo(a)di.uminho.pt
ReportedBy: jpo(a)di.uminho.pt
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
Branches: EPEL4 and EPEL5
Perl packages to branch:
* perl-pmtools
* perl-ExtUtils-CBuilder
* perl-ExtUtils-ParseXS
Note:
* Please create the EPEL branchs from the devel or FC-6
--
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.