-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
On Wed, Dec 21, 2005 at 08:22:30PM -0800, Justin Mason wrote:
gpg-signed 4598349584 http://url/of/GPG.KEYS
ie. a keyid that must be present on the files for the update to be valid,
and an URL that that keyid's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Myers writes:
Justin Mason wrote:
I suspect you may have been looking at the default view -- which is
the most
recent mass-check. Since that's almost always going to be a buildbot-driven
mass-check of the sandbox rules, it won't include
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
/var/named/spamassassin.org had:
.mine
$INCLUDE /var/named/spamassassin.org.d/soa_line
===
; see directory layout at EOF
$INCLUDE /var/named/spamassassin.org.d/soa_line
.r358190
Guess who did that. sorry! ;)
So, the buildbot and bbmass systems have been down since Dec 25,
coincidentally since the zone was shut down and rebooted:
jmpts/2c-24-127-183-241 Mon Jan 2 19:33 still logged in
jmsshd c-24-127-183-241 Mon Jan 2 19:33 still logged in
felicity pts/2
http://buildbot.spamassassin.org:8010/t-debian-stable/builds/0/test/0
t/rule_testsNOK 36# Test 36 got: '0' (t/rule_tests.t at line
108 fail #35)
# Expected: '1' (Test for 'T_INVALID_DATE' (type: 8) against 'Sat, 31 Dec 2005
23:59:60 -0500')
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Parker writes:
John Myers wrote:
The rule promotion criteria don't appear to be doing the right thing
with the DATE_IN_* tests.
These tests are essentially a group. Once one of them has been paid
for, the rest have negligible
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Schulz writes:
The main prob is that /etc/rc3.d/S91bbmass , and /etc/rc3.d/S91buildbot
didn't seem to run -- or at least if they *were* run, the daemons didn't
stay up, and didn't log anything.
There's a possibility that there were
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Gardiner Myers writes:
Loren Wilton wrote:
Others have suggested adding new basic rule types with plugins, which is
probably not a terrible idea. But on the other hand, I'd suggest that
cleaning up internal structure as necessary to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Quinlan writes:
John Gardiner Myers [EMAIL PROTECTED] writes:
I think one weakness in the design of eval tests in general is that
their definition is split into two different places, a function
definition in some .pm file and a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Myers writes:
Justin Mason wrote:
Agreed that adding new rule types is *doable*, if not exactly intuitive.
I've done it in the URIBL code, by simply adding eval rules on the fly,
and that seems to work OK. It'd be nice to have a more
sandbox peeps:
So, due to the changes made just before xmas, the sandbox rules no longer
need the T_ prefix, and if one is found, it implies tflags nopublish
-- in other words, it indicates that that rule is not considered
publishable.
This means that if you have rules in a sandbox that you
http://monitoring.apache.org/status/ is now monitoring
SpamAssassin.zones.apache.org. It'll mail here if things fall over.
--j.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
On Wed, Jan 04, 2006 at 11:25:05AM -0800, Justin Mason wrote:
http://monitoring.apache.org/status/ is now monitoring
SpamAssassin.zones.apache.org. It'll mail here if things fall over.
Cool! We should also add
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Schulz writes:
Thomas Schulz writes:
You may have to put some debugging echo lines in the scripts and then
watch the console during boot. I don't think that output to standard out
is logged anywhere, it just appears on the console
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
On Wed, Jan 04, 2006 at 12:19:58PM -0800, Justin Mason wrote:
Feel free to work up a patch against infrastructure/trunk/nagios. Guess
who's been volunteered ;)
Yeah, if I wasn't all hectic this week (see previous mail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Gardiner Myers writes:
DATE_IN_FUTURE_48_96 has an S/O of 1.0, yet is disabled. Others have
S/O values that are just barely under the current threshold.
The results are nonsensical. That highly suggests there is something
wrong with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Myers writes:
I must say I was quite pleasantly surprised to find my change tested so
quickly during a weekend.
I don't use Bayes, so I won't be putting a lot of effort into Japanese
support in Bayes. I will review your proposals:
We need quite a lot of reviews on the 3.1.1 milestone.
--j.
Using SVN trunk, this now works:
sudo sa-update sudo /etc/init.d/spamassassin reload
note that you need to import the GPG key:
wget http://spamassassin.apache.org/updates/GPG.KEY
gpg --import GPG.KEY
The updates are being distributed via Coral (http://coralcdn.org/) to save
load.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Myers writes:
Motoharu Kubo wrote:
The problem here is the use bytes pragma at the top of
Bayes.pm--you'll want to remove that. Removing it will have some
follow-on consequences--the use bytes pragma will probably also have
to be removed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Loren Wilton writes:
As an outsider, I find myself strongly agreeing with Motohraru-san that,
when dealing with at least the oriental multibyte languages, tokinization
belongs early in the stream, before both bayes and rules.
Of course this is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Warren Togami writes:
Justin Mason wrote:
Using SVN trunk, this now works:
sudo sa-update sudo /etc/init.d/spamassassin reload
Cool. Is it in the plans for sa-update to be usable with the 3.1.1
release too?
I think Theo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Loren Wilton writes:
Currently, Bayes is the only code that actually *uses* knowledge of how a
string is tokenized into words; this isn't exposed to the rules at all.
This isn't even slightly true! Virtually every rule written against English
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Motoharu Kubo writes:
Justin Mason wrote:
(1) rewrite from BODY to RAWBODY as Matsuda-san says.
(2) invent NBODY (or something else) apart from BODY. NBODY contains
normalized and tokenized version of body. I once thought
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
rulesrc/sandbox/hstern/70_syndicate.cf: WARNING: 'rules/sandbox-hstern.pm'
not listed in manifest file, line ignored:
loadplugin Mail::SpamAssassin::Plugin::Sandbox::hstern sandbox-hstern.pm
That's not strictly an error,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Henry Stern writes:
include updates_spamassassin_org/MIRRORED.BY
should not be include'd; needs to be fixed in sa-update, but pretty
easy.
include updates_spamassassin_org/languages
include updates_spamassassin_org/triplets.txt
include
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Warren Togami writes:
Justin Mason wrote:
Warren Togami writes:
Justin Mason wrote:
Using SVN trunk, this now works:
sudo sa-update sudo /etc/init.d/spamassassin reload
Cool. Is it in the plans for sa-update to be usable
I got lots of this:
+ ./mass-check --progress --tail=2 -j 4 -f /home/masschk/cor/tgts
rules: failed to run SUBJ_HAS_UNIQ_ID test, skipping:
(Can't locate object method check_for_unique_subject_id via package
Mail
::SpamAssassin::PerMsgStatus at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
this is a scheduled outage, btw.
- --j.
[EMAIL PROTECTED] writes:
*** ASF Nagios ***
Notification Type: PROBLEM
Host: spamassassin.zones.apache.org
Address: 207.7.158.200
State: DOWN
Info: $
Date/Time: Tue Jan 24 19:10:53 GMT 2006
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daryl C. W. O'Shea writes:
* 4623needs 1 vote
* [review] update to support Mail::DomainKeys API change
Without this patch DomainKeys doesn't work with the latest DomainKeys
module from CPAN.
patch has been open for voting since
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
On Wed, Jan 25, 2006 at 02:48:59AM -, [EMAIL PROTECTED] wrote:
+ # bug 4695: we want br/ to be treated the same as br, and
+ # the HTML::Parser API won't do it for us
+ # if ($self-{preclean_empty_elements}) {
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Quinlan writes:
Does the last part of this patch make *any* sense? It's Allen code from
January 2003 (bug 1088), checked in without a comment probably because
none of us understood it. (The single line changes in the patch are
fine.)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
I was just noticing that my test rules which use my sandbox-felicity.pm plugin
aren't hitting any mails. Doing some debugging, I found that the loadplugin
line occurs after all of the rules and their respective ifplugin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
MATSUDA Yoh-ichi writes:
So, I have an another idea.
The idea is 'multiple local DNSBLs/URIBLs proxy or cache server'.
It's like 'Squid' http proxy server, but runs for DNSBLs/URIBLs.
This idea is effective for large site owner, I believe.
But
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
On Fri, Feb 03, 2006 at 02:48:36AM -, [EMAIL PROTECTED] wrote:
+ # this is usually ${TOPDIR}/masses
my $dir = $FindBin::Bin || .;
@@ -726,7 +727,9 @@
else {
- open (SVNINFO, ( svn info
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daryl C. W. O'Shea writes:
Sidney Markowitz wrote:
Do tests 13 and 14 in t/spf.t work for anyone? They haven't for me for a
long
time and I thought it was a configuration issue here, but I am looking at it
and I don't see how they are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
On Tue, Jan 31, 2006 at 11:53:08AM -0800, Justin Mason wrote:
There's no guarantee that sandbox code will be of a distributable quality,
yet. As a result we should not distribute .pm's from the sandbox dir, and
only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
that's not a horrible kludge, it's quite elegant ;)
- --j.
[EMAIL PROTECTED] writes:
Author: felicity
Date: Mon Feb 6 04:04:08 2006
New Revision: 375261
URL: http://svn.apache.org/viewcvs?rev=375261view=rev
Log:
for now, use a horrible
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daryl C. W. O'Shea writes:
Theo Van Dinter wrote:
I think I found a third bug btw:
3) mkrules tries to make sure that loadplugin lines go into the same
file as ifplugin sections, which won't work if the ifplugin sections
span multiple
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
On Mon, Feb 06, 2006 at 04:55:53PM -0800, Justin Mason wrote:
The major side-effect of this would be that .pm files in a
rulesrc/sandbox/* dir have to be moved into the rulesrc/core dir
before their rules can become
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
While responding to ticket 4788:
On Fri, Feb 10, 2006 at 09:12:10PM +0100, [EMAIL PROTECTED] wrote:
Why not use versioned local_state_dir? Wouldn't doing this upon initial
production launch of this capability in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
On Fri, Feb 10, 2006 at 01:15:11PM -0800, Justin Mason wrote:
No -- because all the code-related rules are distributed in the sa-update
tarball as well.
Aha! Right, that's the whole active set thing which I'm still
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daryl C. W. O'Shea writes:
Matthias Keller wrote:
Theo Van Dinter wrote:
On Tue, Feb 14, 2006 at 04:48:17PM -0500, Daryl C. W. O'Shea wrote:
I do have the two messages causing this on my SA 3.1.0 and the debug
output - it always
Theo Van Dinter writes:
I'd like to see us start publishing rule updates for 3.1 sometime here
in the near future. This got me to wondering what our policy should be
about it, specifically 3.1 code is in R-T-C so should the rules be also?
Based on history, I don't think we'll be able to get
: jm 64...; dig spamassassin.org soa
; DiG 9.3.1 spamassassin.org soa
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 971
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4
;; QUESTION SECTION:
;spamassassin.org. IN
Theo Van Dinter writes:
On Wed, Feb 22, 2006 at 05:15:43AM -0500, Warren Togami wrote:
Are the scores in the nightly 3.2.0-svn build completely untuned? My
fp-fn-statistics have always been looking very bad like this.
Yes, the 3.2 scores have not been generated yet, so any statistics
Theo Van Dinter writes:
I was looking at the corpus area and was noticing that the only people
who are currently doing nightly/weekly runs are:
bzoetekouw
cthielen
daf
parkerm
theo
zmi
The buildbot ones haven't been updated in almost a week, jm hasn't
put results in for almost a
Theo Van Dinter writes:
On Sun, Feb 26, 2006 at 03:03:26PM +0100, Michael Monnerie wrote:
So you didn't see my question, obviously ;-)
Again:
Is the spamfile in rsync.spamassassin.org/mailcorpus_zmi/spam/ also of
use? It's all hand sorted.
Actually I did see it, I just didn't have
Theo Van Dinter writes:
On Sat, Feb 25, 2006 at 12:52:16AM -0800, Loren Wilton wrote:
Without looking at the code, and as something of an outsider, some thoughts
that may be useful:
:)
1. Is there any notable rule efficiency difference between being an eval
and being a plugin?
Duncan Findlay writes:
On Sun, Feb 26, 2006 at 11:47:34PM -0500, Theo Van Dinter wrote:
On Sun, Feb 26, 2006 at 11:32:57PM -0500, Duncan Findlay wrote:
So the problem here is that mkrules is never run, so the majority
of rules aren't actually run. I've added in a mkrules call into the
Theo Van Dinter writes:
On Wed, Feb 22, 2006 at 09:59:44AM +, Justin Mason wrote:
Theo Van Dinter writes:
I'd like to see us start publishing rule updates for 3.1 sometime here
in the near future. This got me to wondering what our policy should be
about it, specifically 3.1 code
Daniel Quinlan writes:
[EMAIL PROTECTED] (Justin Mason) writes:
As for the rule updates... Here's my thought. I propose we have the
rule updates be C-T-R to start. If that doesn't work out, we can change
to R-T-C easily. If no one vetos this proposal by 00:00 GMT on 2/28,
we'll take
Theo Van Dinter writes:
On Tue, Feb 28, 2006 at 04:01:03PM -0500, Daryl C. W. O'Shea wrote:
Do we have a rule scoring policy for rule updates yet?
Not really. I figured periodically (monthly?) we'd end up calling
on nightly/weekly submitters to run a special version (say, 3.1 with
the
Duncan Findlay writes:
On Tue, Feb 28, 2006 at 10:29:10PM -0600, Doc Schneider wrote:
5) Anyone having a particular problem that should be addressed for doing
mass-checks?
Now that I think about it, with the rules sandbox stuff, the SVN
checkout probably won't always get the same
Hi --
We in Apache SpamAssassin have run into what appears to be a bit
of an SVN externals misfeature.
We have our main trunk at
https://svn.apache.org/repos/asf/spamassassin/trunk , which contains
'rulesrc', an external for
https://svn.apache.org/repos/asf/spamassassin/rules/trunk . (We use
Michael Monnerie writes:
On Sonntag, 26. Februar 2006 04:12 Theo Van Dinter wrote:
Really? Â I didn't see it or else I would have responded earlier. :(
So you didn't see my question, obviously ;-)
Again:
Is the spamfile in rsync.spamassassin.org/mailcorpus_zmi/spam/ also of
use? It's
Kenneth Porter writes:
On Wednesday, March 01, 2006 12:00 PM + Justin Mason [EMAIL PROTECTED]
wrote:
I can understand that it may be tricky to implicitly perform the svn
update -r on the external, too, since that may be coming from a
different repository.
Did you raise
Doc Schneider writes:
Justin Mason wrote:
Hi --
[nipped]
Cheers for SVN! Loving it apart from that ;)
--j.
Jason,
Is apache.org running the latest v1.3.0 of SVN? I haven't installed it
here yet but am thinking on doing so.
as a client? I think it'll work fine -- iirc I'm
Theo Van Dinter writes:
I removed the newly added --ignore-externals option which doesn't exist
in svn 1.1.4 (the version on the zones machine) and replaced it with a
rm -rf after the initial export.
I'm really not sure why helios doesn't get svn 1.3 installed, but ... maybe
we'll just
[EMAIL PROTECTED] writes:
Author: felicity
Date: Mon Mar 6 10:55:15 2006
New Revision: 383618
URL: http://svn.apache.org/viewcvs?rev=383618view=rev
Log:
more config files that go with plugins, so they should be in rules and not
rulesrc
Hold on -- I'm not keen on this. What's wrong
Theo Van Dinter writes:
On Mon, Mar 06, 2006 at 08:11:24PM +, Justin Mason wrote:
more config files that go with plugins, so they should be in rules and
not rulesrc
Hold on -- I'm not keen on this. What's wrong with ifplugin?
There's nothing wrong with ifplugin, but the idea
Daryl C. W. O'Shea writes:
Justin Mason wrote:
Dan Mahoney, System Admin writes:
And 4) This whenever it gets hung up (those __alarm__ things couldn't be
more vague, could they?):
Mar 2 12:53:07 quark spamd[94770]: __alarm__
Mar 2 12:53:07 quark spamd[94770]: __alarm__
that's
John Myers writes:
Theo Van Dinter wrote:
When it comes down to it, the body/header/etc rules aren't any different
from other code, beyond the fact that they have the same API for ages.
Similarly, the DNS rules have had the same API for ages. Adding and
removing new block lists can
Theo Van Dinter writes:
On Tue, Mar 07, 2006 at 10:19:07AM -0800, John Myers wrote:
I'm not so big on turning off the functionality. We shouldn't erect
barriers against our being able to later publish full rules through
sa-update.
My POV is that we will never publish full rules again
[EMAIL PROTECTED] writes:
mass-check was using the Last Changed Revision # from the source tree to
figure out what version was in use, but we use the raw revision # when
specifying nightly/weekly runs, and the two numbers are very rarely
equal, so it gets hard to track with different numbers.
Doc Schneider writes:
D'Oh! I meant Justin not Jason. His jmason always throws me. ::thud::
heh, I've given up noticing that long ago ;)
--j.
Loren Wilton writes:
If it's a plugin, it has to be a code-tied rule! Otherwise it
wouldn't need the plugin.
Hey, what a neat way to completely disable the initial concept of the
Rules project and put things back into the Land Of Arcana where they
belong!
Just move 'body', 'rawbody',
Dallas L. Engelken writes:
-Original Message-
From: Loren Wilton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 08, 2006 03:09
To: dev@spamassassin.apache.org
Subject: Re: move full rule functionality into a default-off plugin
Let me suggest that this is a *REALLY* *BAD*
Theo Van Dinter writes:
On Wed, Mar 08, 2006 at 09:36:04PM +, Justin Mason wrote:
If nothing else, I am for simply changing the way rawbody rules are
evaluated... Because the current line by line evaluation is too
restrictive, and using a handfull of rules and meta'ing them together
Loren Wilton writes:
It does introduce the danger of algorithmic complexity attacks if .* is
used instead of .{0,20} though -- but we may be able to help this if we
spot that kind of thing in --lint.
I still don't understand why .* is more dangerous in rawbody rules than
it is in full
[EMAIL PROTECTED] writes:
Author: dos
Date: Thu Mar 9 19:28:58 2006
New Revision: 384691
URL: http://svn.apache.org/viewcvs?rev=384691view=rev
Log:
sandbox: add my SIQ plugin for anyone who's interested
insomnia == non-engineered, messy code :(
This plugin executes SIQ queries in
Daryl C. W. O'Shea writes:
On 09/03/06 08:04 PM, Theo Van Dinter wrote:
So right after I sent this, something occured to me... We're going to want
to
have some kind of mirror infrastructure setup for updates. Right now things
are setup to use nyud.net, but I don't know if we want
+1
Theo Van Dinter writes:
Hi,
I have readied a 3.1.1 release set of files and propose that we release 3.1.1:
http://people.apache.org/~felicity/released/
Please test out these files and vote as to whether or not to release them as
3.1.1. Thanks. :)
My Vote: +1
BTW: my
Sidney Markowitz writes:
On 3/17/06 12:38 PM, Kelsey Cummings wrote:
Justin - just noticed I've got a red X on my CLA status. I submitted the
ASF authorization forms or whatever they were a long time ago. I don't
want that to hold up the merging of my proposed patch provide you guys
Daryl C. W. O'Shea writes:
Theo Van Dinter wrote:
On Thu, Mar 23, 2006 at 01:52:56AM -0500, Daryl C. W. O'Shea wrote:
Why do we have Logger.pm converting spaces to underscores? This seems
to be causing nothing but confusion of users.
fwiw, it's not spaces:
$line =~
Daryl C. W. O'Shea writes:
Loren Wilton wrote:
Total guess: that comment was left over from domainkeys, from before the SA
headers were moved up to the top.
Without the comment that'd be clear and is what I'm 99.999% certain it's
there for. I don't see how a copy of headers being
We have a bit of an issue with recent nightly masschecks -- if you look at
http://ruleqa.spamassassin.org/ , in the recent mass-checks table at the
top, there's the following:
20060404391250 2006-04-04 08:50:34 391250 jm
(promotions validated) bzoetekouw cthielen daf theo
Bas Zoetekouw writes:
Hi Justin!
You wrote:
Is there any way the script could be run 2 hours earlier? Or even 1
hr 20 minutes earlier? ;) That way it would fall under the correct
day in the UTC timezone.
What about just tagging the revision at 0:00 UTC? Wouldn't that just
solve
Bas Zoetekouw writes:
Hi Justin!
You wrote:
What about just tagging the revision at 0:00 UTC? Wouldn't that just
solve all problems?
no -- it's not the tag-time that matters; it's the time that the
mass-check started at, expressed in the UTC timezone. Because the zmi
Michael Monnerie writes:
On Mittwoch, 5. April 2006 17:21 Justin Mason wrote:
no -- it's not the tag-time that matters; it's the time that the
mass-check started at, expressed in the UTC timezone. Â Because the
zmi mass-check happens *after* UTC, it shows up as being in
the next day
Michael Monnerie writes:
On Mittwoch, 5. April 2006 19:22 Justin Mason wrote:
(For what it's worth, 0830 UTC was chosen as an hour that's not
during working hours for most of the committers; UTC isn't good
on that count, since it's 1600 PST.)
I don't understand why my results made
Theo Van Dinter writes:
On Wed, Apr 12, 2006 at 03:12:52PM +0200, Michael Monnerie wrote:
Now I would like to add my ZMI_GERMAN ruleset to the mass-check. What
would be the correct way to do it? I can think of:
If you want them run by everyone, the rules would have to be put into a
this is coming up soon -- do we want to get a couple of entrants
for SpamAssassin?
If so, I guess we should come up with potential projects.
- ARF support plugin (bug 4812)
- finishing up the Apache::SpamD module that Michael was working on (bug
4603)
- a bigger test suite (suggested by Theo
Michael Monnerie writes:
On Mittwoch, 12. April 2006 17:58 Theo Van Dinter wrote:
If you want them run by everyone, the rules would have to be put into
a sandbox for testing.
Ah, somewhere very deep in my head I had that sandbox stuff sitting
around, I could remember you speaking about
Theo Van Dinter writes:
On Thu, Apr 13, 2006 at 04:03:54PM -0500, Michael Parker wrote:
- persistent DB connections (suggested by Michael last year)
This exists, but is not an ASL friendly license. So a clean room
implementation might be cool.
I also suggested having things like
should we silence these noisy warnings during the build?
WARNING: KAM_STOCKTIP26: renamed as T_KAM_STOCKTIP26 due to missing T_ prefix
WARNING: KAM_STOCKSYM: renamed as T_KAM_STOCKSYM due to missing T_ prefix
WARNING: KAM_STOCKSYM2: renamed as T_KAM_STOCKSYM2 due to missing T_ prefix
WARNING:
I think it'd make a great SoC project -- agreed!
--j.
Warren Togami writes:
(Below is just a strawman idea for a project that I think would be very
beneficial to the future of the spamassassin project. Please add your
ideas or possible implementation details in reply. Then later we can
Theo Van Dinter writes:
On Mon, Apr 17, 2006 at 12:31:17AM -0400, Warren Togami wrote:
Problems
1) It is only really usable on Linux/Unix hosts, or maybe Cygwin with a
bunch of effort, although not easily with any Windows clients. Even if
you are a Linux user, it is *TOO
Warren Togami writes:
What do we need to do to move forward with this and make an official SoC
project? I think spamassassin should at least mentor this project, but
we can host it elsewhere.
As for project hosting, our options are either:
1) Fedora Project... not sure but I'll ask.
2)
Sidney Markowitz writes:
In svn trunk, is the GTUBE rule being put in 70_inactive.cf and therefore
works
in a make test (which copies rules/*.cf for testing) but does not get
installed, or is my svn trunk installation misconfigured?
doh!
could you open a bug? userconf rules should always
hey,
It strikes me that the process to become an ASF committer is turning out
to be a little too onerous for some of our purposes.
Nowadays we have these rule sandboxes (
http://wiki.apache.org/spamassassin/RuleSandboxes ), and we want to allow
all sorts of people -- including occasional
Chris Santerre writes:
-Original Message-
From: Theo Van Dinter [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 29, 2006 10:38 PM
To: dev@spamassassin.apache.org
Subject: Re: easier rule committing?
- (b) more importantly: is this worth doing? Are we likely
to get
on the zone --
: jm 24...; sudo -u updatesd crontab -l
# temporarily disabled - 2006/05/10 - tvd
#30 8 * * * bash /home/updatesd/svn/spamassassin/build/mkupdates/run_nightly
/var/www/buildbot.spamassassin.org/updatesd/mkupdates.txt 21
#50 8 * * * bash
Theo Van Dinter writes:
On Wed, May 10, 2006 at 04:48:29PM -0400, Theo Van Dinter wrote:
If you haven't already noticed, the main webserver for apache.org
(including svn.apache.org) is down at the moment. Folks in #asfinfra
are working on it, moving the services to other servers, so I'd
Theo Van Dinter writes:
On Thu, May 11, 2006 at 10:30:17AM -0400, Theo Van Dinter wrote:
I did send out some mails about this yesterday, so I'm not sure why
there's a huge surprise now. It's temporary folks, until minotaur
(or a new more permanent home for svn and such) is dealt with.
Theo Van Dinter writes:
On Tue, May 16, 2006 at 05:36:45PM -, [EMAIL PROTECTED] wrote:
trivial fix: inhibit 'undefined value' warnings
--- spamassassin/trunk/lib/Mail/SpamAssassin/Message.pm (original)
+++ spamassassin/trunk/lib/Mail/SpamAssassin/Message.pm Tue May 16 10:36:45
+1! thanks Theo ;)
fwiw, I would suggest putting bug 4802 (DKIM support) at the top
of the changelog, since it's a significant new feature; then bug 3838,
bug 4850 and bug 4826, since they are pretty major fixes too
compared to the rest.
--j.
Theo Van Dinter writes:
Hi there,
I have
Theo Van Dinter writes:
On Wed, May 24, 2006 at 11:35:18PM -0500, Michael Parker wrote:
I fear that the warning is going to lead to a HUGE support headache. We
either need to override the userstate dir for all the tests, add an
additional possible userstate dir that will for sure exist or
Theo Van Dinter writes:
On Thu, May 25, 2006 at 06:08:15PM +0100, Justin Mason wrote:
fwiw, a long term fix would be option (b) -- tests should not be
using the user's real userstate dir.
Yeah, but that's not actually the issue.
The warn() (now info()) is in the M::SA
+1 from me
--j.
401 - 500 of 1307 matches
Mail list logo
