hm.  to clarify: it'll still be there, but just as a normal SVN directory, not a wierd SVN "external" link.

> hm.  to clarify: it'll still be there, but just as a normal SVN directory, not
> a wierd SVN "external" link.

I'm not sure if I'm doing the right thing at the right place,
but some rules need adjusting for 3.3:


rules/25_dkim.cf, rules/50_scores.cf:
- remove DomainKeys rules (Bug 6098);
- drop scores of ENV_AND_HDR_DKIM_MATCH
  and ENV_AND_HDR_SPF_MATCH as a great goldmine
  for spammers;
- added new rules DKIM_VALID, DKIM_VALID_AU,
  DKIM_ADSP_*, __DKIM_DEPENDABLE;
- dropped scores to 0 for old rules
  DKIM_VERIFIED, DKIM_POLICY_*, while keeping them
  for compatibility with existing uses .cf files
Sending        rules/25_dkim.cf
Sending        rules/50_scores.cf
Transmitting file data ..
Committed revision 789382.

Btw, I have a couple of adsp_override rules (comparable to def_whitelist_from_*,
but in the opposite sense, only applicable to 3.3), such as the ones below.
Should I put them in some .cf file? Where?

adsp_override ebay.com       discardable
adsp_override *.ebay.com     discardable
adsp_override paypal.com     discardable
adsp_override *.paypal.com   discardable
adsp_override paypal.co.uk   discardable
adsp_override ealerts.bankofamerica.com
adsp_override alert.bankofamerica.com
adsp_override americangreetings.com
adsp_override yahoo.americangreetings.com
adsp_override msn.americangreetings.com
adsp_override egreetings.com
adsp_override bluemountain.com
adsp_override hallmark.com
adsp_override update.hallmark.com
adsp_override *.hallmark.com
adsp_override amazon.com            all
adsp_override amazon.co.uk          all
adsp_override amazon.de             all
adsp_override amazon.fr             all
adsp_override birthdayalarm.com     all
adsp_override astrology.com         all
adsp_override linkedin.com          all
adsp_override *.linkedin.com        all
adsp_override facebookmail.com      all
adsp_override *.greenpeace.org      all
adsp_override lists.sourceforge.net all

ok, as of

: 500...; svn commit -m "bug 6139: add note indicating obsolete status of this copy"
Adding         README.txt
Sending        sandbox/jm/20_sought.cf
Transmitting file data ..
Committed revision 789460.


the rulesrc dirs in 3.3.0 trunk, and the 3.2.x maintainance branch, are entirely separate.

Mark: feel free to put those in a .cf in the 'rules' dir.

oh dear.  this is annoying:

: 36...; sudo -u automc -H svn up
Password:
svn: Failed to add directory 'rulesrc': object of the same name already exists
: exit=[1] uid=jm Mon Jun 29 21:51:36 GMT 2009; cd /export/home/automc/svn/spamassassin
: 37...; sudo -u automc rm -rf rulesrc
: uid=jm Mon Jun 29 21:51:50 GMT 2009; cd /export/home/automc/svn/spamassassin
: 38...; sudo -u automc -H svn up
A    t.rules/MIME_BASE64_TEXT
[... etc.]


In other words, "svn up" can't cope with the replacement of an external with a normal dir, and needs a manual "rm -rf rulesrc" to help...

actually, it's worse than that.  Every SVN checkout needs the following, it seems:

svn propdel svn:externals . ; rm -rf rulesrc ; svn up


sorry folks.  won't happen again!

>> Btw, I have a couple of adsp_override rules (comparable to
>> def_whitelist_from_*, but in the opposite sense, only applicable
>> to 3.3), such as the ones below. Should I put them in some .cf file?

> Mark: feel free to put those in a .cf in the 'rules' dir.

Adding rules/60_adsp_override_dkim.cf
Committed revision 789478.

> Adding rules/60_adsp_override_dkim.cf
> Committed revision 789478.

Hmm, sa-update did not copy this file to the
/var/lib/spamassassin/3.003000/updates_spamassassin_org

What else needs to be done please?

> Hmm, sa-update did not copy this file to the
> /var/lib/spamassassin/3.003000/updates_spamassassin_org
> 
> What else needs to be done please?

Reopening just so that my question is not forgotten.

Seems like sa-update is not supplying the current version
of 3.3 rules and scores from the SVN 'rules' directory.

(It is quite possible it's only happening to me due to
fudging soft links to make SVN SA coexist with the one
from FreeBSD ports - am I the only one?)

The release notes should boldly state the change in fetching of rules.

: 692...; svn commit -m "remove the 'make install' step from updates generation; it no longer works to copy rules around" build/mkupdates/run_part2
Sending        build/mkupdates/run_part2
Transmitting file data .
Committed revision 790114.


I think that's fixed it.  reopen again if not.

So, from now on -- do we need to put rules for testing in trunk, too, in addition to our sandboxes? Or is the sandbox still sufficient for testing?

Rules go in trunk/rulesrc/sandbox/{you}/

rules/trunk/{etc...} is deprecated.

(In reply to comment #12)
> Rules go in trunk/rulesrc/sandbox/{you}/
> 
> rules/trunk/{etc...} is deprecated.

yep.

If you want to backport rules for 3.2.x updates, you have to _manually_ add them to branches/3_2_x_updates/rulesrc/sandbox/{you}/ , as well.