Description of problem: In files in /usr/share/spamassassin/ I see all over the place "@@LOCAL_RULES_DIR@@/local.cf" and "require_version @@VERSION@@" I would expect to see instead "/etc/mail/spamassassin/local.cf" and "require_version 3.003000". The first string appears to show up only in comments, although maybe somewhere else its value may be important, but with the second on according to 'man Mail::SpamAssassin::Conf' one could expect bad things to happen. Something amiss in a configuration stage? Version-Release number of selected component (if applicable): spamassassin-3.3.0-0.26.rc1.fc12
I think this not a real problem. I think that local.cf isn't used. They shouldn't have added that to the tarball.
> I think this not a real problem. I think that local.cf isn't used. I wrote that "@@LOCAL_RULES_DIR@@" appears to show up only in comments so if there are no other occurences this is cosmetics. Only that there is also this "require_version @@VERSION@@" part and that is used and it smells at least problematic. In this form it shows up here: /usr/share/spamassassin/20_advance_fee.cf /usr/share/spamassassin/20_body_tests.cf /usr/share/spamassassin/20_compensate.cf /usr/share/spamassassin/20_dnsbl_tests.cf /usr/share/spamassassin/20_drugs.cf /usr/share/spamassassin/20_dynrdns.cf /usr/share/spamassassin/20_fake_helo_tests.cf /usr/share/spamassassin/20_head_tests.cf /usr/share/spamassassin/20_html_tests.cf /usr/share/spamassassin/20_meta_tests.cf /usr/share/spamassassin/20_net_tests.cf /usr/share/spamassassin/20_phrases.cf /usr/share/spamassassin/20_porn.cf /usr/share/spamassassin/20_uri_tests.cf /usr/share/spamassassin/23_bayes.cf /usr/share/spamassassin/72_active.cf Both /usr/bin/spamassassin and /usr/bin/spamd have "Also, deal with unchanged VERSION macro" code, so maybe one can get away with it, but it looks like a lurking trouble.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
In .cf files from spamassassin-3.3.1-2.fc13 and from spamassassin-3.3.1-5.fc14 I still see: 'require_version @@VERSION@@' and here is a corresponding fragment from /usr/share/perl5/Mail/SpamAssassin/Conf.pm which describes how this is supposed to look like: =item require_version n.nnnnnn Indicates that the entire file, from this line on, requires a certain version of SpamAssassin to run. If a different (older or newer) version of SpamAssassin tries to read the configuration from this file, it will output a warning instead, and ignore it. Note: The version used is in the internal SpamAssassin version format which is C<x.yyyzzz>, where x is major version, y is minor version, and z is maintenance version. So 3.0.0 is C<3.000000>, and 3.4.80 is C<3.004080>. =cut
The reason for this is that we are using the seperate Mail-SpamAssassin-rules file. This is unpacked without setting the version. Here's a quick spec patch that seems to fix it: --- a/spamassassin.spec +++ b/spamassassin.spec @@ -54,10 +54,12 @@ Requires: portreserve %define real_name Mail-SpamAssassin %{!?perl_vendorlib: %define perl_vendorlib %(eval "`%{__perl} -V:installvendorlib`"; echo +%global saversion 3.003002 + Summary: Spam filter for email which can be invoked from mail delivery agents Name: spamassassin Version: 3.3.2 -Release: 0.2.svn1027144%{?dist} +Release: 0.3.svn1027144%{?dist} License: ASL 2.0 Group: Applications/Internet URL: http://spamassassin.apache.org/ @@ -193,6 +195,7 @@ find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';' # Default rules from separate tarball cd $RPM_BUILD_ROOT%{_datadir}/spamassassin/ tar xfvz %{SOURCE1} +sed -i -e 's|\@\@VERSION\@\@|%{saversion}|' *.cf cd - find $RPM_BUILD_ROOT/usr -type f -print | @@ -274,6 +277,9 @@ fi exit 0 %changelog +* Sun Nov 21 2010 Kevin Fenzi <kevin> - 3.3.2-0.3.svn1027144 +- Add sed line to fix @@VERSION@@ issue (bug #550861) + * Fri Oct 29 2010 Kevin Fenzi <kevin> - 3.3.2-0.2.svn1027144 - Fix sa-update sysconfig script line wrapping I don't know if there is a better way to get saversion aside from setting it in a global. Warren? Nb? Thoughts?
Sounds good. Will build a new release shortly. [nb@delta spamassassin]$ git push Enter passphrase for key '/home/nb/.ssh/id_rsa': Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 509 bytes, done. Total 3 (delta 2), reused 0 (delta 0) To ssh://nb.org/spamassassin 8f17aef..7a63292 master -> master [nb@delta spamassassin]$
spamassassin-3.3.2-0.5.svn1071394.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/spamassassin-3.3.2-0.5.svn1071394.fc13
spamassassin-3.3.2-0.5.svn1071394.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/spamassassin-3.3.2-0.5.svn1071394.fc15
spamassassin-3.3.2-0.5.svn1071394.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/spamassassin-3.3.2-0.5.svn1071394.fc14
spamassassin-3.3.2-0.5.svn1071394.fc15 has been pushed to the Fedora 15 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update spamassassin'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/spamassassin-3.3.2-0.5.svn1071394.fc15
spamassassin-3.3.2-0.5.svn1071394.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
spamassassin-3.3.2-0.5.svn1071394.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
After installing spamassassin-3.3.2-0.5.svn1071394.fc14 I still see the following comments in files from /usr/share/spamassassin/: # Please don't modify this file as your changes will be overwritten with # the next update. Use @@LOCAL_RULES_DIR@@/local.cf instead. # See 'perldoc Mail::SpamAssassin::Conf' for details. The catch is that although 'perldoc Mail::SpamAssassin::Conf', or 'man Mail::SpamAssassin::Conf', does mention an existence of "local.cf" it does not directly say where to look for one. That can be found somewhere if one is persistent enough. There is one curious exception. In /usr/share/spamassassin/60_shortcircuit.cf the corresponding comment has this line: # the next update. Use /etc/mail/spamassassin/local.cf instead. No idea why this difference but that is what it would be nice to see in general. Also /usr/share/spamassassin/10_default_prefs.cf is left with: report_contact @@CONTACT_ADDRESS@@ I would not expect this to work too well. All these leftovers are relatively minor, I guess. 'require_version' indeed is everywhere as expected. Thanks!
spamassassin-3.3.2-0.5.svn1071394.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.