[Bug 237252] minor error in amavis-clamd.conf
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.
Summary: minor error in amavis-clamd.conf
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237252
------- Additional Comments From nicku(a)nicku.org 2007-06-11 03:20 EST -------
I've been able to restart clamd.amavisd after setting up freshclam and
/etc/freshclam.
The daily.cvd file seems to have been corrupted, even though
rpm -V clamav-update showed no errors. After replacing it using freshclam,
clamd can start, and finally I can receive email again.
--
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.
16 years, 10 months
[Bug 237252] minor error in amavis-clamd.conf
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.
Summary: minor error in amavis-clamd.conf
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237252
nicku(a)nicku.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nicku(a)nicku.org
------- Additional Comments From nicku(a)nicku.org 2007-06-11 01:31 EST -------
After making what might seem a reasonable change:
$ diff /etc/clamd.d/amavisd.conf~ /etc/clamd.d/amavisd.conf
2c2
< LogSyslog
---
> LogSyslog 1
14c14
< FixStaleSocket
---
> FixStaleSocket 1
I find clamd *still* is unhappy:
$ sudo service clamd.amavisd start
Starting clamd.amavisd: Running as user amavis (UID 105, GID 107)
and in /var/log/maillog:
Jun 11 15:29:37 www3 clamd[30966]: Log file size limited to 1048576 bytes.
Jun 11 15:29:37 www3 clamd[30966]: Reading databases from /var/lib/clamav
Jun 11 15:29:37 www3 clamd[30966]: Not supported data format
and then clamd dies.
--
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.
16 years, 10 months
[Bug 212369] New: Use of uninitialized value in pattern match
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=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(a)jmason.org,parkerm
@pobox.com,reg+redhat@sidney.com,wtogami(a)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.
16 years, 10 months
[Bug 241651] New: perl-DBI should be updated...
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=241651
Summary: perl-DBI should be updated...
Product: Fedora Core
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: perl-DBI
AssignedTo: rnorwood(a)redhat.com
ReportedBy: oliver(a)linux-kernel.at
CC: fedora-perl-devel-list(a)redhat.com
http://search.cpan.org/~timb/DBI-1.56/
Currently only 1.53 is available.
It doesn't only include various fixes, but also the new DBD::Gofer (introduced
with 1.54). Yes, there are subtle changes to the DBI internals, that may affect
current code, but perfect for -devel I would say.
However, users of Perl >= 5.9.5 will need at least DBI 1.54 - I'm not sure what
the plan in -devel is for Perl, but if we start trying out 5.9.4 (current perl
developer version), we'll need updated DBI as well - sooner or later.
Just my 2 cent.
--
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.
16 years, 10 months
tests as documentations.
by Chris Weyl
Lately I've started realizing that the test suite of a distribution
can make for excellent examples of how to use something. E.g. lots of
the Catalyst and CGI-* dists include little "test apps" that exercise
the various modules; Moose and Class-MOP both contain extensive test
suites (with Moose going so far as to say "the tests are still the
best documentation" for certain features), etc, etc. Even for
something as mundane as Module::Use I found constraints on the module
that weren't mentioned in the documentation.
So, I've started packaging the test suites under %doc (in new packages
and as I have reason to update existing packages), taking pains (as
always) to deliver them without dependencies and execute bits. This
seemed rather logical to me, as I've always included other docs
(examples/*, doc/*, etc) in %doc and insisted on it in package
reviews. I'm trying to package them up without regards to _my_
thinking they're useful, as what I think isn't useful someone else
usually does (and that other person is typically me 6 months in the
future).
I figured I'd do it for a while, see what feedback I got, then come
here and seek more feedback, and maybe put something in
PackagingDrafts/Perl to address a best practice concerning it. (I
already have a "tests can make good documentation... consider
packaging them" in there, with no screams to date.)
So. Here's what I've been hearing:
1. Questions mainly related to why the change in practice on my part,
e.g. "why? ... oh, ok."
2. "Well, it's your package, it's in %doc and conforms to guidelines"
3. Test suites ought to be executable, and have all their deps met.
#1 was the most popular, followed by #2. One person strongly feels
#3, and doesn't appear to buy the "tests make good docs" argument
under any circumstances. As near as I can tell, most people don't
seem to really care one way or the other.
As things stand, I'm inclined to go forward with "encourage optionally
packaging t/ in %docs, following guidelines (no exec, no deps; split
to -docs if the end package is too large)", but I see a couple
different ways this could go as well.
What do you all think?
-Chris
--
Chris Weyl
Ex astris, scientia
16 years, 10 months
Archive::Zip - 'unauthorized' release.
by Robin Norwood
Hi,
I started working down Chris's excellent list of outdated modules, and
came upon an interesting situation with Archive::Zip - the latest
version (1.18) is flagged as 'unauthorized'. As near as I can tell, the
new author (Adam Kennedy) seems to have taken over maintaining this
module, but hasn't had the ownership transferred in CPAN. I sent Adam
an email asking if he is going to fix this.
Is there a general policy for this sort of situation, and if not, should
there be? I think clearly we would want to avoid downloading such
releases - part of the intent is to prevent people from uploading
releases when they don't own the module, and obvious badness could occur
if someone uploaded an unauthorized release with some sort of badness in
the code. I don't think that's what's going on here (Adam owns quite a
few modules on CPAN, and clearly has a track record).
Should something be added to the perl packaging guidelines, and what do
you think we should do in this instance, other than wait for a response
from Adam?
The latest 'authorized' version:
http://search.cpan.org/~smpeters/Archive-Zip-1.16/
Adam's 'unauthorized' version:
http://search.cpan.org/~adamk/Archive-Zip-1.18/
-RN
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
16 years, 10 months
Fedora to CPAN mapping...
by Chris Weyl
Hey all --
So I took a first shot at a "Fedora to CPAN" mapping script. It's
extremely basic right now, and I blatantly stole the page style from
cvs.fedora.redhat.com and the icons from the wiki. However, the table
itself is at the point where I thought I'd throw it out there for
feedback. Release early, release often, right?
A couple caveats:
* packages / owners are pulled from owners.list in cvs
* package version in Fedora is determined via the spec, also pulled from cvs
* I have a widescreen monitor, so the table may be too wide for some
* core packages ( < F-7 ) aren't taken into account
Pulling from cvs isn't optimal, but it works for now. There's still a
bunch more to be done, e.g.:
* a "quicklink" to open bugs (rt and bz)
* overall statistics would be neat
* per-owner statistics would also be neat
* something to make it more difficult for the email addys to be "harvested"
Anyways. Suggestions, feedback, and civil criticism welcome and requested :)
http://home.comcast.net/~ckweyl/test.html
-Chris
--
Chris Weyl
Ex astris, scientia
16 years, 10 months