An RH bug was opened and closed on this in 2014:
https://bugzilla.redhat.com/show_bug.cgi?id=1151565
I attached a patch to the bug for the latest sa-update.cron script from
the 3.4.2 RPM to invoke sa-compile if the plugin is enabled and re2c is
installed.
Hi,
it may be worth to run a memtest on your system.
Daniele
On 28/09/2018 12:25, Ronny Wagner wrote:
Hello Community,
since few days i have a problem with spamassassin.
I can't start the service, i found out, when i delete some channels in directory
"/var/lib/spamassassin/3.004001" the ser
On 9/28/2018 6:25 AM, Ronny Wagner wrote:
> Hello Community,
>
> since few days i have a problem with spamassassin.
> I can't start the service, i found out, when i delete some channels in
> directory "/var/lib/spamassassin/3.004001" the service come up.
>
> I download a test channel (/usr/bin/sa-
2017-08-25 10:08 GMT-06:00 Randal, Phil :
> I've seen this, caused by a CPAN install which leaves stuff like this in
> .bashrc:
>
> export PERL_LOCAL_LIB_ROOT="$PERL_LOCAL_LIB_ROOT:/root/perl5";
> export PERL_MB_OPT="--install_base /root/perl5"; export
> PERL_MM_OPT="INSTALL_BASE=/root/perl5";
>
I've seen this, caused by a CPAN install which leaves stuff like this in
.bashrc:
export PERL_LOCAL_LIB_ROOT="$PERL_LOCAL_LIB_ROOT:/root/perl5";
export PERL_MB_OPT="--install_base /root/perl5"; export
PERL_MM_OPT="INSTALL_BASE=/root/perl5";
export PERL5LIB="/root/perl5/lib/perl5:$PERL5LIB";
expo
On Thu, 24 Aug 2017, Ricky Gutierrez wrote:
spamassassin-3.4.1-14.el7.centos.x86_64
Where did you get that?
The official Centos 7 version (as far as I can tell) is 3.4.0-2 and the
latest available via FC is 3.4.1-12 from FC26.
I don't have a RedHat account, but I expect Centos would pretty
On Sat, 17 Jun 2017 16:00:10 +0100
Peter Smith wrote:
> >> 1) After compiling, my compiled ruleset is stored in
> >> /var/lib/spamassassin/compiled/5.014/3.004001. Do I now need to
> >> remove my rules from /etc/mail/spamassassin/
> >
> > You don't need to remove anything.
> >
> > The stock rule
>> 1) After compiling, my compiled ruleset is stored in
>> /var/lib/spamassassin/compiled/5.014/3.004001. Do I now need to
>> remove my rules from /etc/mail/spamassassin/
>
> You don't need to remove anything.
>
> The stock rules aren't stored there anyway, it's just local rules.
Ahh, I think perh
On Sat, 17 Jun 2017 13:48:32 +0100
Peter Smith wrote:
> Hello list,
>
> I'm playing around with sa-compile in an attempt to improve
> performance, but I have a couple of questions that I can't find
> answered in the online docs.
>
> 1) After compiling, my compiled ruleset is stored in
> /var/lib
On 20.04.17 17:07, Bill Cole wrote:
ls -ld /usr/bin/X11
lrwxrwxrwx 1 root root 1 Mar 11 2007 /usr/bin/X11 -> .
That's a weird Ubuntu (or Debian?) quirk. It shouldn't be necessary
but it probably shouldn't be fiddled with either, except maybe to
'chmod -h o-w /usr/bin/X11' (to remove the worl
No I don't. I have not used Gentoo and am not on that mailing list.. I
hope my questions do not appear too newbie, since I've been running Unix
systems for a long time, although this particular one had me stumped.
Thelma is the name of one of my servers, another is Louise. That
location has ser
On 2017-04-20 17:31, Robert Steinmetz AIA wrote:
> >>> thelma@thelma:~$ echo $PATH
BTW, do you have any connection to the Thelma who's asking a constant
stream of close-to-newbie questions in the Gentoo user mailing list?
It's not that common a name, so forgive me for the short-circuit in my
bra
Thank you Bill,
I checked all of the permissions at every level, they were all 755
except for as noted, which I changed. to 755
It works now.
I'll re-check this in the morning and run security scans to make sure
everything is tied down..
I appreciate your help.
Bill Cole wrote:
On 20 Apr
On Thu, 2017-04-20 at 17:07 -0400, Bill Cole wrote:
If your distro has an rkhunter package available, then I'd recommend
that you install it. Once you're happy that your system clean, do its
initial update "rkhunter --propupt" and thereafter make sure its run as
a daily cronjob. This way you shoul
On 20 Apr 2017, at 16:16, Robert Steinmetz AIA wrote:
Thank you Bill,
That has given me a clue. I ran the commands below:
thelma@thelma:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/usr/local/games:/snap/bin
thelma@thelma:~$ ls -ld /usr/l
Reindl Harald wrote:
just ask your distribution how they broke your environment
this is *not* a spamassassin issue and all the stuuf you do abvoe
is not supposed to make things better - how do you imagine "I
deleted the /usr/bin/X11 link an
Thank you Bill,
That has given me a clue. I ran the commands below:
thelma@thelma:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/usr/local/games:/snap/bin
thelma@thelma:~$ ls -ld /usr/local/sbin
drwxr-xr-x 2 root root 48 Mar 11 2007 /usr/lo
On 19 Apr 2017, at 9:52, Robert Steinmetz wrote:
Robert Steinmetz wrote:
Responding to my own post with new information.
I think I've confirmed that the problem is the $PATH, or the perl
equivalent.
I added the full path name where the specific commands were called and
that removed that error
Title: Signature
Robert Steinmetz wrote:
Responding to my own post with new information.
I think I've confirmed that the problem is the $PATH, or the perl
equivalent.
I added the full path name where the specific commands were called
and that removed
Ian Zimmerman wrote:
On 2017-04-18 10:17, Robert Steinmetz wrote:
tty is in /usr/bin
But it is stty, not tty, which fails to be found. And stty is
(normally) in /bin. So it looks a lot like /bin (and probably /sbin) is
missing from the PATH.
Yes thanks stty is in /bin
This could be re
On 2017-04-18 10:17, Robert Steinmetz wrote:
> tty is in /usr/bin
But it is stty, not tty, which fails to be found. And stty is
(normally) in /bin. So it looks a lot like /bin (and probably /sbin) is
missing from the PATH.
This could be related to the long-advertised switch to a unified /u
Title: Signature
RW wrote:
On Mon, 17 Apr 2017 16:37:35 -0400
Robert Steinmetz wrote:
I upgrades my working Ubuntu 14.04 LTS to 16.04 LTS SpamAssassin
version 3.4.1.
Something happened during the upgrade and I ma now unable to get
sa-compile to configu
On Mon, 17 Apr 2017 16:37:35 -0400
Robert Steinmetz wrote:
> I upgrades my working Ubuntu 14.04 LTS to 16.04 LTS SpamAssassin
> version 3.4.1.
> Something happened during the upgrade and I ma now unable to get
> sa-compile to configure properly.
>
> Here is the message
>
> > root@thelma:~# dp
> On Feb 12, 2015, at 14.09, Kevin A. McGrail wrote:
>
> On 2/11/2015 7:25 PM, listsb-spamassas...@bitrate.net wrote:
>> i hope another solicitation for this help request is ok.
>
> It's ok.
>
> Overall, I agree. I tested on a devel box and running sa-compile does have
> an rm line but did l
On Thu, 12 Feb 2015 14:09:00 -0500
Kevin A. McGrail wrote:
> On 2/11/2015 7:25 PM, listsb-spamassas...@bitrate.net wrote:
> > i hope another solicitation for this help request is ok.
>
> It's ok.
>
> Overall, I agree. I tested on a devel box and running sa-compile
> does have an rm line but did
On 2/11/2015 7:25 PM, listsb-spamassas...@bitrate.net wrote:
i hope another solicitation for this help request is ok.
It's ok.
Overall, I agree. I tested on a devel box and running sa-compile does
have an rm line but did leave these files listed below.
Because /tmp is a considered auto cle
i hope another solicitation for this help request is ok.
> On Feb 04, 2015, at 09.19, btb wrote:
>
> hi-
>
> i happened to notice a bunch of old files in /tmp/, related to spamassassin.
> after a bit of testing, it looks like sa-compile isn't cleaning up after
> itself?
>
> >ls -alH /tmp/
>
21.10.2012 03:10, Kevin A. McGrail kirjoitti:
> On 10/20/2012 5:01 PM, Jari Fredriksson wrote:
>> Sa-compile says:
>>
>> # /usr/bin/sa-compile
>> Oct 20 23:59:32.992 [6734] info: generic: base extraction starting. this
>> can take a while...
>> Oct 20 23:59:32.992 [6734] info: generic: extracting f
On 10/20/2012 5:01 PM, Jari Fredriksson wrote:
Sa-compile says:
# /usr/bin/sa-compile
Oct 20 23:59:32.992 [6734] info: generic: base extraction starting. this
can take a while...
Oct 20 23:59:32.992 [6734] info: generic: extracting from rules of type
body_0
100%
[
On Sun, 2011-11-20 at 13:37 +1000, Noel Butler wrote:
> Hi,
> Does anyone have a list of the error codes?
> running normally for years called from cron bash script, I am moving
> it to cron perl script (for lots of reasons and other things), run
> from console it works, but run from cron it fails,
On 11/12/2010 6:05 PM, fchan wrote:
2) re2c 0.12.3
I can't say I even recall using re2c 0.12.x, but I do remember several
bugs in 0.13.x prior to the current 0.13.5. Is upgrading an option?
0.13.5 has been stable for over 2 years and works great here.
--
/Jason
On 11/12/10 5:38 PM, fchan wrote:
I was trying to do sa-compile -D on my system and I got this error
message: \
first, tell us:
1) version of SA
2) version of re2c
3) what rules, other than stock SA rules do you have
4) what local rules, changes, edits do you have?
5) what operating system, i38
On 11/12/10 5:38 PM, fchan wrote:
I was trying to do sa-compile -D on my system and I got this error
message: \
first, tell us:
1) version of SA
2) version of re2c
3) what rules, other than stock SA rules do you have
4) what local rules, changes, edits do you have?
5) what operating system, i38
Daniel McDonald-3 wrote:
>
> The question is not how processing one mail compares, but how 10 per
> second
> compare in each scenario. That's where the win is - lower total cpu
> utilization to accomplish the same work.
>
Yes, that makes sense to me.
Daniel McDonald-3 wrote:
>
> But your nu
On 8/2/10 7:53 AM, "Daniel Lemke" wrote:
>
>
> Yet Another Ninja wrote:
>>
>> compiled rules only affects body & rawbody rules.
>> Network tests won't be affected and are probably the reason for the lack
>> of a massive difference.
>>
>
> Good advice, I disabled all the other plugins and ran
On Mon, 2010-08-02 at 05:53 -0700, Daniel Lemke wrote:
> Yet Another Ninja wrote:
> > compiled rules only affects body & rawbody rules.
> > Network tests won't be affected and are probably the reason for the lack
> > of a massive difference.
>
> Good advice, I disabled all the other plugins and r
Yet Another Ninja wrote:
>
> compiled rules only affects body & rawbody rules.
> Network tests won't be affected and are probably the reason for the lack
> of a massive difference.
>
Good advice, I disabled all the other plugins and ran spamassassin in local
test mode, processing a huge text
On Sat, 2010-07-31 at 09:13 +0300, Henrik K wrote:
> You are making strange and wrong speculations.
>
Fair enough - now I know this.
> It parses applicable rules into "native C code regexes", instead of running
> them through Perl regex engine. It's known to speed up things 15% or so
> (look at s
On Fri, Jul 30, 2010 at 11:56:08PM +0100, Martin Gregorie wrote:
> On Fri, 2010-07-30 at 15:35 -0400, Bowie Bailey wrote:
> > On 7/30/2010 3:26 PM, Bowie Bailey wrote:
> > > On 7/30/2010 3:08 PM, Emin Akbulut wrote:
> > >> Simply disable regular ruleset and test again. If it takes 6.93-5.78
> > >>
On Fri, 2010-07-30 at 15:35 -0400, Bowie Bailey wrote:
> On 7/30/2010 3:26 PM, Bowie Bailey wrote:
> > On 7/30/2010 3:08 PM, Emin Akbulut wrote:
> >> Simply disable regular ruleset and test again. If it takes 6.93-5.78
> >> seconds or
> >> something similar, you are right.
> > I'm actually having
On 2010-07-30 21:26, Bowie Bailey wrote:
On 7/30/2010 3:08 PM, Emin Akbulut wrote:
Simply disable regular ruleset and test again. If it takes 6.93-5.78
seconds or
something similar, you are right.
I'm actually having the same issue on my new home server. I set up SA
and got it working. Then
On 7/30/2010 3:26 PM, Bowie Bailey wrote:
> On 7/30/2010 3:08 PM, Emin Akbulut wrote:
>> Simply disable regular ruleset and test again. If it takes 6.93-5.78
>> seconds or
>> something similar, you are right.
> I'm actually having the same issue on my new home server. I set up SA
> and got it wo
On 7/30/2010 3:08 PM, Emin Akbulut wrote:
> Simply disable regular ruleset and test again. If it takes 6.93-5.78
> seconds or
> something similar, you are right.
I'm actually having the same issue on my new home server. I set up SA
and got it working. Then I ran sa-compile, enabled the plugin i
Simply disable regular ruleset and test again. If it takes 6.93-5.78 seconds
or
something similar, you are right.
On Fri, Jul 30, 2010 at 12:20 PM, Daniel Lemke wrote:
>
> Another Windows related question
>
> I (think I) successfully compiled my ruleset into native code. I used a XP
> box wit
Justin Mason wrote:
> On Fri, Jan 29, 2010 at 14:59, Mark Martinec wrote:
>> On Friday 29 January 2010 04:20:15 René Berber wrote:
>>> Jason Bertoch wrote:
What version of re2c are you using? Can you post the output of
'spamassassin -D --lint' to pastebin?
>>> Now using re2c 1.3.5 same
Jason Bertoch wrote:
> On 1/28/2010 10:20 PM, René Berber wrote:
>>
>> Now using re2c 13.5 same problem, to be precise it doesn't hang, it
>> loops (the CPU usage goes up and down, RSS the same, up and down) at the
>> same point.
>>
>> Here's the output http://pastebin.com/m438000e0
>>
>
> Assumi
On Fri, Jan 29, 2010 at 14:59, Mark Martinec wrote:
> On Friday 29 January 2010 04:20:15 René Berber wrote:
>> Jason Bertoch wrote:
>> > What version of re2c are you using? Can you post the output of
>> > 'spamassassin -D --lint' to pastebin?
>>
>> Now using re2c 1.3.5 same problem, to be precise
On Friday 29 January 2010 04:20:15 René Berber wrote:
> Jason Bertoch wrote:
> > What version of re2c are you using? Can you post the output of
> > 'spamassassin -D --lint' to pastebin?
>
> Now using re2c 1.3.5 same problem, to be precise it doesn't hang, it
> loops (the CPU usage goes up and dow
On 1/28/2010 10:20 PM, René Berber wrote:
Now using re2c 13.5 same problem, to be precise it doesn't hang, it
loops (the CPU usage goes up and down, RSS the same, up and down) at the
same point.
Here's the output http://pastebin.com/m438000e0
Assuming you recompiled your rules after the re2c
René Berber wrote:
> Jason Bertoch wrote:
>
>> What version of re2c are you using? Can you post the output of
>> 'spamassassin -D --lint' to pastebin?
>
> Now using re2c 1.3.5 same problem, to be precise it doesn't hang, it
Oops!0.13.5
> loops (the CPU usage goes up and down, RSS
Jason Bertoch wrote:
> What version of re2c are you using? Can you post the output of
> 'spamassassin -D --lint' to pastebin?
Now using re2c 1.3.5 same problem, to be precise it doesn't hang, it
loops (the CPU usage goes up and down, RSS the same, up and down) at the
same point.
Here's the outp
Mark Martinec wrote:
> It hasn't been determined exactly which is the minimal working version,
> the 0.12 was chosen just as a version whose predecessors are known to fail.
> Actually SpamAssassin 3.3.0 was tested with 0.13.5, which worked fine.
I'll try that version tonight.
> Not sure which is
René,
> > What version of re2c are you using? Can you post the output of
> > 'spamassassin -D --lint' to pastebin?
>
> re2c is version 0.12.1. The script sa-compile checks the version so I
> don't think there's a problem there.
It hasn't been determined exactly which is the minimal working ver
Jason Bertoch wrote:
> Can you post the output of 'spamassassin -D --lint' to pastebin?
Here's the current working output: http://pastebin.com/m35634489
--
René Berber
Jason Bertoch wrote:
> On 1/28/2010 3:54 PM, René Berber wrote:
>> Hi,
>>
>> I'm having a problem with spamassassin 3.3.0 after doing sa-compile.
>>
>> The operation didn't return any error and seems to go as usual, but
>> running 'spamassassin --lint' hangs, and it didn't before using
>> sa-compi
On 1/28/2010 3:54 PM, René Berber wrote:
Hi,
I'm having a problem with spamassassin 3.3.0 after doing sa-compile.
The operation didn't return any error and seems to go as usual, but
running 'spamassassin --lint' hangs, and it didn't before using
sa-compile (it doesn't after using the solution b
On Wed, Jul 15, 2009 at 14:38, Michael Scheidell wrote:
> 'them'?
>
> men in black?
>
> freebsd? or CPAN maintainer of Term:ReadKey?
Up to you. ;) I'd recommend the latter.
--j.
> ps, out of office messages, read receipt and FPS on vabounce. OOO messages,
> and RR messages cannot be whiteliste
'them'?
men in black?
freebsd? or CPAN maintainer of Term:ReadKey?
ps, out of office messages, read receipt and FPS on vabounce. OOO
messages, and RR messages cannot be whitelisted by the sending mta since
they never include the original message. I think I started some patches
on it, but O
the progress indicators use Term::ReadKey, which (looking at its
source) appears to call "resize" under certain circumstances. you
should probably file a bug with them
On Wed, Jul 15, 2009 at 14:28, Michael Scheidell wrote:
> wondering..
>
> am I missing something? 'resize: not found'
>
> go
Never mind, it works. J Just calling it without any parameters
has it default do The Right ThingT.
- Mark
From: Mark [mailto:ad...@asarian-host.net]
Sent: dinsdag 28 april 2009 23:24
To: users@spamassassin.apache.org
Subject: sa-compile command-line?
Ok, finally got re2c compi
> > > I was just doing an update and compile and ran into this problem which is
> > > new, as I never had troulbe before. Error is token exceeds limit, as
> > > below. Any help would be appreciated.
>
> > What's your re2c version?
>
> as below, you are correct, re2c.0.13.3
> > > re2c: error:
On Tue, Apr 28, 2009 at 07:44:08PM +0200 or thereabouts, Karsten Bräckelmann
wrote:
> On Tue, 2009-04-28 at 11:16 -0500, Gary wrote:
> > I was just doing an update and compile and ran into this problem which is
> > new, as I never had troulbe before. Error is token exceeds limit, as
> > below. An
On Tue, 2009-04-28 at 11:16 -0500, Gary wrote:
> I was just doing an update and compile and ran into this problem which is
> new, as I never had troulbe before. Error is token exceeds limit, as
> below. Any help would be appreciated.
What's your re2c version?
> SA ~ # sa-update --gpgkey 6C6191E
I wrote:
> meta __SEEK_LZH2GT 0 # Microsoft Office 2003 Pro
> meta __SEEK_O1TQTY 0 # aving trouble viewing this e
> meta __SEEK_QGCXIK 0 # lots of dots
> which relies on the names being derived from the string.
Benny Pedersen wrote:
> the above __SEEK_* is random so you disable random seek :
On Tue, April 21, 2009 22:25, James Wilkinson wrote:
> meta __SEEK_LZH2GT 0 # Microsoft Office 2003 Pro
> meta __SEEK_O1TQTY 0 # aving trouble viewing this e
> meta __SEEK_QGCXIK 0 # lots of dots
> which relies on the names being derived from the string.
the above __SEEK_* is random so you
On Tue, Apr 21, 2009 at 21:25, James Wilkinson
wrote:
> Karsten Bräckelmann wrote:
>> By looking at the sub-rules' names I got the impression they are just
>> random. But maybe they actually are somehow based on the rule's content?
>> Never checked. Justin?
>
> Justin Mason replied:
>> yep, they'
Karsten Bräckelmann wrote:
> By looking at the sub-rules' names I got the impression they are just
> random. But maybe they actually are somehow based on the rule's content?
> Never checked. Justin?
Justin Mason replied:
> yep, they're derived from a hash of the string.
Is that documented, or co
2009/4/17 Karsten Bräckelmann :
> On Fri, 2009-04-17 at 16:18 +0100, Matt wrote:
>> Karsten Bräckelmann wrote:
>
>> > Err, Matt, just had a very brief look at the code and the resulting
>> > metas, but -- how is that different? :)
>>
>> Blame that comment on lack of sleep - I read that as limiting
On Fri, 2009-04-17 at 16:18 +0100, Matt wrote:
> Karsten Bräckelmann wrote:
> > Err, Matt, just had a very brief look at the code and the resulting
> > metas, but -- how is that different? :)
>
> Blame that comment on lack of sleep - I read that as limiting the depth
> of the tree and not being
Karsten Bräckelmann wrote:
Would constructing it using a binary (or n-ary, with small upper bound
of n) tree speed the compilation up?
Err, Matt, just had a very brief look at the code and the resulting
metas, but -- how is that different? :)
The result is exactly the tree struc
On Thu, 2009-04-16 at 21:58 +0100, Matt wrote:
> Karsten Bräckelmann wrote:
> >
> > Wonder why that is -- due to the excessively long metas? The sub-rules'
> > REs are quite trivial.
> >
> > Would constructing it using a binary (or n-ary, with small upper bound
> > of n) tree speed the compilation
RobertH wrote:
matt,
wouldnt deleting the ~./spamassassin folder also delete the bayes data in
many circumstances?
Yes this would - this was purely for testing purposes - as Justin said
in a previous email some information is cached in that folder so I
deleted it to make sure that it was
> From: Matt
>
> Using a slightly different method - using a maximum number of
> children parser. The times were taken after deleting the
> ~/.spamassassin folder before each run.
>
> Before
>
> real21m24.068s
> user18m58.465s
> sys 0m45.532s
>
> After using 4 children
>
>
Karsten Bräckelmann wrote:
Wonder why that is -- due to the excessively long metas? The sub-rules'
REs are quite trivial.
Would constructing it using a binary (or n-ary, with small upper bound
of n) tree speed the compilation up?
Using a slightly different method - using a maximum number of
for those in the know re the programming and speed of processing using
sa-compile...
it appears the fules compile fast without the sought ruleset applied.
and time to compile increases by roughly (very rough) a factor of 10 with
sought ruleset applied.
is that time extra time spent strictly in
well.. thats not it. im using 0.13.5 also.
Larry Nedry wrote:
On 4/16/09 at 7:44 AM -0400 Michael Scheidell wrote:
Larry: what version of re2c are you using?
re2c 0.13.5
--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation
* Certi
On 4/16/09 at 7:44 AM -0400 Michael Scheidell wrote:
>Larry: what version of re2c are you using?
re2c 0.13.5
> On 4/15/09 at 10:30 AM -0400 Rick Macdougall wrote:
>> Normal sa-update && sa-compile takes about 2 minutes here.
>> If I add JM's saught rules it takes over 30 minutes.
>
> Here's another data point. With JM's sought and sought-fraud rules the
> compile takes less than 7 minutes on a server ru
Hi!
Normal sa-update && sa-compile takes about 2 minutes here.
If I add JM's saught rules it takes over 30 minutes.
Here's another data point. With JM's sought and sought-fraud rules the
compile takes less than 7 minutes on a server running an Intel Core 2 Duo
running at 2.13 GHz.
# time sa
A lot of stuff is cached between runs in ~/.spamassassin...
--j.
On Thu, Apr 16, 2009 at 02:56, Larry Nedry wrote:
> On 4/15/09 at 10:30 AM -0400 Rick Macdougall wrote:
>>Normal sa-update && sa-compile takes about 2 minutes here.
>>If I add JM's saught rules it takes over 30 minutes.
>
> Here's
On 4/15/09 at 10:30 AM -0400 Rick Macdougall wrote:
>Normal sa-update && sa-compile takes about 2 minutes here.
>If I add JM's saught rules it takes over 30 minutes.
Here's another data point. With JM's sought and sought-fraud rules the
compile takes less than 7 minutes on a server running an Int
On Wed, 15 Apr 2009, Rick Macdougall wrote:
jp wrote:
It only takes a minute or three on my systems depending on load. 21 seconds
on a zero load dual core virtual machine with 2gb ram.
On Wed, Apr 15, 2009 at 08:56:22AM +1000, Res wrote:
Is there a method of speeding this beast up? I can buil
On Wed, 2009-04-15 at 17:31 -0400, Michael Scheidell wrote:
> > Is there a method of speeding this beast up? I can build four entire
> > kernels and their modules from scratch in the same time it takes this
> > thing to compile (45mins) is it really worth using this method?
> > Last time I tried wi
> Is there a method of speeding this beast up? I can build four entire
> kernels and their modules from scratch in the same time it takes this
> thing to compile (45mins) is it really worth using this method?
> Last time I tried without it, I noticed next to no difference, opinions?
>
Same here, s
jp wrote:
It only takes a minute or three on my systems depending on load. 21
seconds on a zero load dual core virtual machine with 2gb ram.
On Wed, Apr 15, 2009 at 08:56:22AM +1000, Res wrote:
Is there a method of speeding this beast up? I can build four entire
kernels and their modules from
It only takes a minute or three on my systems depending on load. 21
seconds on a zero load dual core virtual machine with 2gb ram.
On Wed, Apr 15, 2009 at 08:56:22AM +1000, Res wrote:
> Is there a method of speeding this beast up? I can build four entire
> kernels and their modules from scratch
> I just installed SpamAssassin 3.2.5 and after doing a sa-update and
> sa-compile I get the following:
>
> Illegal octal digit '8' ignored at /usr/local/bin/sa-compile line 631,
> <$fh> line 2436.
> Wide character in print at /usr/local/bin/sa-compile line 385, <$fh>
> line 2436.
>
> They compil
- Original Message -
From: "Ralf Hildebrandt" <[EMAIL PROTECTED]>
To:
Sent: Monday, May 05, 2008 7:21 AM
Subject: Re: sa-compile problem
* Jared Hall <[EMAIL PROTECTED]>:
Symptoms are typical re2c problems. Try version 0.12.3
http://sourceforge.net/project/
* Jared Hall <[EMAIL PROTECTED]>:
> Symptoms are typical re2c problems. Try version 0.12.3
> http://sourceforge.net/project/showfiles.php?group_id=96864&package_id=103574&release_id=534536
I'm using 0.13.3-1, so I should downgrade?
--
Ralf Hildebrandt (i.A. des IT-Zentrums) [EMAIL PROT
Ralf Hildebrandt wrote:
# spamassassin -V
SpamAssassin version 3.2.4
running on Perl version 5.8.8
>From my /usr/local/scripts/update_spamassassin cronjob
/usr/bin/sa-update --channelfile
/etc/mail/spamassassin/sare-sa-update-channels.txt \
--gpgkey 856AA88A \
--gpgkey 6C6191E3
follo
Rosenbaum, Larry M. wrote:
> > From: Bowie Bailey [mailto:[EMAIL PROTECTED]
> >
> > Rosenbaum, Larry M. wrote:
> > > > From: Bowie Bailey [mailto:[EMAIL PROTECTED]
> > > >
> > > > I would say that sa-compile is the preferred method due to its
> > > > performance benefits. There aren't many (any?
> From: Bowie Bailey [mailto:[EMAIL PROTECTED]
>
> Rosenbaum, Larry M. wrote:
> > > From: Bowie Bailey [mailto:[EMAIL PROTECTED]
> > >
> > > I would say that sa-compile is the preferred method due to its
> > > performance benefits. There aren't many (any?) drawbacks to using
> > > it.
> >
> > I do
>
> I don't use it here because it takes too long (over 20 minutes) to
> compile.
> (This is with SA v3.2.4, which is a big improvement over v3.2.3)
>
> L
Why would how long it takes to compile matter as long as you get some return
on investment?
Is the machine heavily loaded or just a small u
Rosenbaum, Larry M. wrote:
> > From: Bowie Bailey [mailto:[EMAIL PROTECTED]
> >
> > I would say that sa-compile is the preferred method due to its
> > performance benefits. There aren't many (any?) drawbacks to using
> > it.
>
> I don't use it here because it takes too long (over 20 minutes) to
> From: Bowie Bailey [mailto:[EMAIL PROTECTED]
>
> I would say that sa-compile is the preferred method due to its
> performance benefits. There aren't many (any?) drawbacks to using it.
I don't use it here because it takes too long (over 20 minutes) to compile.
(This is with SA v3.2.4, which is a
Robert - elists wrote:
> > I would say that sa-compile is the preferred method due to its
> > performance benefits. There aren't many (any?) drawbacks to using
> > it.
> >
> > That said, I still cannot get it to work on my system. Everything
> > works fine with the standard rulesets, but as soo
>
> I would say that sa-compile is the preferred method due to its
> performance benefits. There aren't many (any?) drawbacks to using it.
>
> That said, I still cannot get it to work on my system. Everything works
> fine with the standard rulesets, but as soon as I enable the compiled
> rules
Robert - elists wrote:
> Greetings
>
> Is using sa-compile the standard now?
>
> ... or are most organizations still just using the stock formatted
> rulesets?
>
> If not the standard, is it the SA recommended standard?
>
> I know there can be problems or issues, yet if we do use sa-compile as
=?ISO-8859-1?Q?Luis_Hern=E1n_Otegui?= writes:
> Hi, everybody, sa-compile was running allright in my systems, and the
> saturday it began to spit out this output (from sa-compile -D):
there are a number of bugs in sa-compile that are fixed in SVN
trunk-- please apply the patches from
http://issue
* Daryl C. W. O'Shea <[EMAIL PROTECTED]> [070915 19:26]:
> micah wrote:
>> If so, I'm looking for ideas for detecting if there are actually any
>> updates from sa-update, and then *only* churning the sa-compile if there
>> were updates. As I have it now, I'm running a sa-compile no matter what,
1 - 100 of 160 matches
Mail list logo
