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=230406
Summary: MakeMaker has perl.mak depending on non-existent
/usr/lib/perl5/5.8.8/i386-linux-thread-
multi/CORE/config.h'
Product: Fedora Core
Version: devel
Platform: i386
OS/Version: Linux
Status: NEW
Severity: medium
Priority: normal
Component: perl
AssignedTo: rnorwood(a)redhat.com
ReportedBy: vonbrand(a)inf.utfsm.cl
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
I tried to build git here, the build fails:
make[2]: Entering directory `/home/vonbrand/tmp/git/perl'
make[2]: *** No rule to make target
`/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/config.h', needed by
`perl.mak'. Stop.
The generated perl.mak file (essentially a Makefile with funny name) contains
the following:
PERL_INC = /usr/lib/perl5/5.8.8/sparc-linux-thread-multi/CORE
...
CONFIGDEP = $(PERL_ARCHLIB)$(DFSEP)Config.pm $(PERL_INC)$(DFSEP)config.h
...
$(FIRST_MAKEFILE) : Makefile.PL $(CONFIGDEP)
I don't see how this could ever have worked, as the $(CONFIGDEP) file doesn't
exist. Strangely, the same git does build OK on Aurora Linux (essentially an
oldish Fedora Core), with the exact same Makefile, where the referenced file
doesn't exist either.
I'm blaming perl as it is the only piece I think might be involved that changed
today, and before updating today the build went fine.
Version-Release number of selected component (if applicable):
perl-5.8.8-13.fc7
How reproducible:
Don't know.
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
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=207838
Summary: Perl getsockopt() on SCTP sockets doesn't work
Product: Fedora Core
Version: fc5
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: rnorwood(a)redhat.com
ReportedBy: pablo_p(a)op.pl
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
Perl getsockopt() on SCTP socket does not work. Following perl code:
------------------------------------------
use strict;
use IO::Socket;
## create sctp socket
my $sock = new IO::Socket::INET(
Proto => 132,
Type => SOCK_STREAM
) or die "Cannot create sctp socket";
## read rto data
my $i = getsockopt($sock, 132, 1);
#print rto data
print join("\n", unpack("I i*", $i));
------------------------------------------
Works on Solaris10, but not on (my) Linux. I checked C getsockopt, and code like
this:
ret = getsockopt(sock , SOL_SCTP, SCTP_RTOINFO, &sctp_info, &len);
works OK only if len is initially set to sizeof(struct sctp_rtoinfo), which is
not what manual says:
-------------------------------------------
> man getsockopt
...
The parameters optval and optlen are used to access option values for
setsockopt(). For getsockopt() they identify a buffer in which the
value for the requested option(s) are to be returned. For getsock-
opt(), optlen is a value-result parameter, initially containing the
size of the buffer pointed to by optval, and modified on return to
indicate the actual size of the value returned. If no option value is
to be supplied or returned, optval may be NULL.
...
-------------------------------------------
Above applies to all SCTP structures available via get/setsockopt.
Version-Release number of selected component (if applicable):
perl-5.8.8-5
glibc-2.4-11
kernel-2.6.17-1.2187_FC5
How reproducible:
every time
Steps to Reproduce:
1. run perl code from description
2. nothing is displayed
Actual results:
nothing is displayed
Expected results:
sctp socket rto into (4 parameters)
Additional info:
SELinux is disabled.
--
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=212369
Summary: Use of uninitialized value in pattern match
Product: Fedora Core
Version: fc6
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: spamassassin
AssignedTo: wtogami(a)redhat.com
ReportedBy: tjb(a)unh.edu
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:
I'm running spamass-milter along with spamassassin and I'm seeing these errors
in /var/log/maillog:
Oct 26 09:19:19 raptor spamd[2509]: Use of uninitialized value in pattern match
(m//) at /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/PerMsgStatus.pm line
879, <GEN4> line 5.
Oct 26 09:19:19 raptor spamd[2509]: Use of uninitialized value in concatenation
(.) or string at
/usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/PerMsgStatus.pm line 953,
<GEN4> line 5.
The may be just warnings as mail is being tagged.
Also saw this:
Oct 26 11:28:21 raptor spamd[5990]: rules: meta test DIGEST_MULTIPLE has
undefined dependency 'DCC_CHECK'
Oct 26 11:28:21 raptor spamd[5990]: spamd: server started on port 783/tcp
(running version 3.1.4)
Version-Release number of selected component (if applicable):
spamassassin-3.1.4-1.fc6
--
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=223753
Summary: Typo in /etc/logrotate.d/sa-update
Product: Fedora Core
Version: fc6
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: spamassassin
AssignedTo: wtogami(a)redhat.com
ReportedBy: adrian(a)lisas.de
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:
logrotate error message:
error: sa-update:3 unknown option 'notifyempty' -- ignoring line
Version-Release number of selected component (if applicable):
spamassassin-3.1.7-4.fc6
Fix:
Something like this:
/var/log/sa-update.log {
monthly
- notifyempty
+ notifempty
missingok
}
--
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=235835
Summary: can you build for EL5?
Product: Fedora Extras
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: perl-IO-Multiplex
AssignedTo: lmb(a)biosci.ki.se
ReportedBy: bpeck(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
I have a package in Extras called conmux which uses perl-IO-Multiplex on the
server side. I was wondering if you could build perl-IO-Multiplex for EL5 as well.
Thanks!
--
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.
Hey all--
So there's a rather spirited discussion perl packaging discussion
going on over at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237883 about
Test::Pod::Coverage module tests, and their importance.
The canonical approach is to insist on all tests being enabled that
possibly can -- even to the point of requiring other modules be
packaged to enable these tests. "Test as much as possible."
Test::Pod::Coverage tests don't actually test the functionality of the
module. Further, they can't tell you if that documentation is any
good, or even plain wrong. We also have a practice of disabling this
test out of hand if it fails for whatever reason... Further, usually
upstream takes the step of explicitly requiring this test be enabled
-- e.g. via TEST_POD=1 or some other mechanism.
Documentation coverage is a good Kwalitee indication (as they say),
not always an indication of good quality -- and certainly not a
consistent, reliable indication of that.
My opinion is that we ought to not mandate the use of Pod coverage
tests, simply because for our purposes it doesn't really matter what
their result is. If they're present, we should conditionalize the
tests (e.g. %_with_pod_tests magic or some such), but not insist on
them by default.
Either way, we ought to document this in Packaging/Perl -- which I
took a quick (and probably dirty) pass at reworking under
PackagingDrafts/Perl.
-Chris
--
Chris Weyl
Ex astris, scientia
Hey folks. Just wanted to let you know that Bugzilla 3.0 (which
should be out soon) has a few perl pre-reqs that aren't in Extras. One
of them is required:
Email-Send
And all of the others are optional but still useful:
Template-GD
Email-MIME-Attachment-Stripper
Email-Reply
In particular, Template-GD really should be in FE--it was
originally part of Template-Toolkit and was moved out in version 2.15.
I figured I'd let you know sooner rather than later, when users
kept asking you for the packages, or when you had to build them anyway
to build a new Bugzilla package. :-)
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
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=237612
Summary: WWW::Bugzilla fails to fetch bug
Product: Fedora Extras
Version: fc6
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: perl-WWW-Bugzilla
AssignedTo: jpo(a)di.uminho.pt
ReportedBy: cweyl(a)alumni.drew.edu
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
WWW::Bugzilla fails to fetch bug with:
Can't locate object method "form" via package "WWW::Mechanize" at
/usr/lib/perl5/vendor_perl/5.8.8/WWW/Bugzilla.pm line 271.
Version-Release number of selected component (if applicable):
perl-WWW-Mechanize-1.22-2.fc6
perl-WWW-Bugzilla-0.8-1.fc6
How reproducible:
Attempt to open an existing bug.
Actual results:
*boom* (see above)
Expected results:
A valid WWW::Bugzilla object to manipulate the given bug.
Additional info:
It appears WWW::Bugzilla 0.9 fixes this. Should be an easyfix as 0.9 is already
available in devel.
--
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=237594
Summary: Upgrade to SVK 2.0.1
Product: Fedora Extras
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: perl-SVK
AssignedTo: ianburrell(a)gmail.com
ReportedBy: ianburrell(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
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.