Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=226117
--- Comment #16 from Daniel Novotny <dnovotny(a)redhat.com> 2009-12-15 09:19:02 EDT
---
hello Jon,
I'll explain the remaining warnings:
(In reply to comment #8)
The only ones that concern me are these:
Lots of:
mailman.i386: E: file-in-usr-marked-as-conffile
/usr/lib/mailman/templates/zh_TW/userpass.txt
A file in /usr is marked as being a configuration file. Store your conf files
in /etc/ instead.
these are the HTML files Mailman displays in its UI - they are both data
(mailman treats them as data files) and config files, because the user can
change them to customize the look and feel used by his mailing list (to conform
with his web's design and/or content for example)
mailman.i386: W: dangerous-command-in-%pre rm
mailman.i386: W: dangerous-command-in-%post rm
we are not rm-ing any of the
mailman's files, the %pre and %post script
creates its own temporary flag file in /var/run, indicating if the service
is running during an upgrade (see the "restart_flag" variable in the spec)
and we are rm-ing only this script's temporary flag file
mailman.i386: W: incoherent-subsys /etc/rc.d/init.d/mailman $prog
The filename of your lock file in /var/lock/subsys/ is incoherent with your
actual init script name. For example, if your script name is httpd, you have
to use 'httpd' as the filename in your subsys directory. It is also possible
that rpmlint gets this wrong, especially if the init script contains
nontrivial shell variables and/or assignments. These cases usually manifest
themselves when rpmlint reports that the subsys name starts a with '$'; in
these cases a warning instead of an error is reported and you should check the
script manually.
the subsys is coherent, rpmlint is confused by the usage of shell
variables ("It is also possible that rpmlint gets this wrong" applies here)
mailman.i386: W: service-default-enabled /etc/rc.d/init.d/mailman
The service is enabled by default after "chkconfig --add"; for security
reasons, most services should not be. Use "-" as the default runlevel in the
init script's "chkconfig:" line and/or remove the
"Default-Start:" LSB keyword
to fix this if appropriate for this service.
yes, the service seems to be on by default: I can fix this after fedora server
outage is over
--
Configure bugmail:
https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.