You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2004/01/14 00:37:11 UTC
Re: Own directory for spamc?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"Malte S. Stretz" writes:
>On Monday 05 January 2004 04:37 CET Duncan Findlay wrote:
>> On Sun, Jan 04, 2004 at 09:59:25PM +0100, Malte S. Stretz wrote:
>> > The spamd directory gets a bit messed up, especially with Sidney's
>> > files getting added. spamd and spamc are twe separate applications
>> > (even though they communicate with each other), each one's got it's own
>> > accompanying files (the one it's headers, the other the rc scripts
>> > etc.) and both are built completely different.
>>
>> I agree. If anything, I'd argue that spamc should be its own top level
>> directory if not entirely separate from the spamassassin
>> distribution.... Certainly it should be build independently.
>>
>> > What do you think about creating an own directory for spamc and move
>> > all related files (including qmail-spamc.c) there? (Moving files is
>> > very easy with SVN, I really love it :)
>>
>> Please :-)
>
>Any other opionions? Vetoes? Justin, Theo, Daniel, what do you think?
+1 -- move away.
- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFABIEnQTcbUG5Y7woRAgtiAJ4rL6mIJqycvFsasqLlt8KfNTnM9ACgpQlb
apW2X5LFC88tUDqh1wQ2GEY=
=K4NH
-----END PGP SIGNATURE-----
Re: More on spamd/win
Posted by Sidney Markowitz <si...@sidney.com>.
Malte S. Stretz wrote:
> I checked in those changes, now everything should run smoothly.
It all tests out ok in both Cygwin and Windows.
Thanks!
--sidney
Re: More on spamd/win
Posted by "Malte S. Stretz" <ms...@gmx.net>.
On Monday 19 January 2004 03:10 CET Sidney Markowitz wrote:
> At the end of this I got all tests working under Windows except
> spamd_unix.t which wasn't supposed to be run but tried because of a
> typo: It says RUNNING_IN_WINDOWS instead of RUNNING_ON_WINDOWS in two
> places near the beginning.
Whoops. Corrected.
> The makefile calls perl2bat on spamc.exe which is not correct. perl2bat
> is supposed to be called only on perl scripts. I this is something to
> fix in Makefile.PL. It doesn't really hurt anything, just creates a
> bogus bat file named spamc.exe.bat.
Yeah, I wondered about that, too. But that's done automagically by EU::MM,
nothing I can change.
> Ok, now for the heart of this message:
> > You need to set the following variables:
> > SPAMD_FORKER=start \cygwin\bin\perl
> > SPAMD_SCRIPT=\cygwin\bin\perl -w -T /bin/spamd
>
> I don't like having to use all these environment variables, and I don't
> think both are necessary.
>
> Since the tests run under SATest.pm are always running in a native perl
> environment, you can always set $spamd_fork to "start $perl_path" when
> running under Windows and $perl_path otherwise.
Good point.
> The Windows perl is perfectly capable of running SATest.pl to invoke
> spamd after doing the redirection.
>
> I just tried it and it works. The only change I made was at line 280 in
> SATest.pm
>
> my $spamd_forker = $perl_path;
> $spamd_forker = "start " . $spamd_forker if ($^O =~ /^MS(DOS|Win)/i);
>
> And I had SPAMD_SCRIPT set to
>
> SPAMD_SCRIPT=\cygwin\bin\perl -w -T /bin/spamd --syslog-socket none
The --syslog-socket isn't necessary, too. It's set automagically to that
value if --syslog stderr is used.
I checked in those changes, now everything should run smoothly.
Cheers (and Thanks for your help),
Malte
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
Re: More on spamd/win
Posted by Sidney Markowitz <si...@sidney.com>.
Malte S. Stretz wrote:
I'm writing this backwards, short minor points first so they don't get
lost in my large message:
At the end of this I got all tests working under Windows except
spamd_unix.t which wasn't supposed to be run but tried because of a
typo: It says RUNNING_IN_WINDOWS instead of RUNNING_ON_WINDOWS in two
places near the beginning.
I can't test dns.t behind the firewall where I am now, but it did behave
as expected in this environment.
The makefile calls perl2bat on spamc.exe which is not correct. perl2bat
is supposed to be called only on perl scripts. I this is something to
fix in Makefile.PL. It doesn't really hurt anything, just creates a
bogus bat file named spamc.exe.bat.
Ok, now for the heart of this message:
> You need to set the following variables:
> SPAMD_FORKER=start \cygwin\bin\perl
> SPAMD_SCRIPT=\cygwin\bin\perl -w -T /bin/spamd
I don't like having to use all these environment variables, and I don't
think both are necessary.
Since the tests run under SATest.pm are always running in a native perl
environment, you can always set $spamd_fork to "start $perl_path" when
running under Windows and $perl_path otherwise.
The Windows perl is perfectly capable of running SATest.pl to invoke
spamd after doing the redirection.
I just tried it and it works. The only change I made was at line 280 in
SATest.pm
my $spamd_forker = $perl_path;
$spamd_forker = "start " . $spamd_forker if ($^O =~ /^MS(DOS|Win)/i);
And I had SPAMD_SCRIPT set to
SPAMD_SCRIPT=\cygwin\bin\perl -w -T /bin/spamd --syslog-socket none
-- sidney
More on spamd/win (was: Own directory for spamc?)
Posted by "Malte S. Stretz" <ms...@gmx.net>.
On Sunday 18 January 2004 21:05 CET Sidney Markowitz wrote:
> Malte S. Stretz wrote:
> > spamd isn't started directly but an intermediate script SATest.pl
> > which does the redirection of STDOUT and STDERR
>
> Do you mean SATest.pm? That's where the call to system() is.
>
> Here is the problem: The only way to fork the background in the
> background is to use the 'start' command to launch it. If you try to use
> redirection with a 'start' command, the output of start is redirected
> but the stdin and stdout handles are not passed to the process it starts
> up. There is no workaround that I know. You cannot get both the running
> in the background and the redirection. Good old Windoze.
You can if you put Perl in between :) But I thought the wrong way round when
I wrote the code. I just committed another change which should make the
stuff work. You need to set the following variables:
SPAMD_FORKER=start \cygwin\bin\perl
SPAMD_SCRIPT=\cygwin\bin\perl -w -T /bin/spamd
I'm not sure about the latter. If the wrapper script was already called via
the cygwin Perl, it should be enough (or necessary) to say
SPAMD_SCRIPT=/bin/spamd
or
SPAMD_SCRIPT=/bin/perl -w -T /bin/spamd
('-x' and '-s stderr' are no longer necessary, as they are the default now)
> > But what I really wanted to know, does spamc still compiles
> > successfully after the move?
>
> Yes, it works fine! :-)
That's good, I wasn't sure if VC would like the getopt.{c,h} files in the
subdirectoy.
Cheers,
Malte
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
Re: Own directory for spamc?
Posted by Sidney Markowitz <si...@sidney.com>.
Malte S. Stretz wrote:
> spamd isn't started directly but an intermediate script SATest.pl
> which does the redirection of STDOUT and STDERR
Do you mean SATest.pm? That's where the call to system() is.
Here is the problem: The only way to fork the background in the
background is to use the 'start' command to launch it. If you try to use
redirection with a 'start' command, the output of start is redirected
but the stdin and stdout handles are not passed to the process it starts
up. There is no workaround that I know. You cannot get both the running
in the background and the redirection. Good old Windoze.
The only way to run a process in the background and have it redirect its
output is to pass filenames in as arguments and have it dup stdin and
stdout.
> The --stdout switch had the disadvantage, that it didn't
> catch *all* output generated by spamd because the stuff was
> redirected after some output had already been generated.
I don't see that! I just tried running spamd with the --stdout patch I
submitted using the --stdout switch and all output went to the file I
gave it. The first output line with the debug switch set is "Score set 0
chosen". What do you see? Perhaps I uploaded the patch before I got that
working right and had the dup of stdout too late? I recall making that
mistake and then correcting it, I may have uploaded the wrong version.
If you want I'll submit a patch for the --stdout option again, as the
version I have here works.
> But what I really wanted to know, does spamc still compiles successfully
> after the move?
Yes, it works fine! :-)
-- sidney
Re: Own directory for spamc?
Posted by "Malte S. Stretz" <ms...@gmx.net>.
On Saturday 17 January 2004 21:36 CET Sidney Markowitz wrote:
> Malte S. Stretz wrote:
> > for Windows I'm not 100% sure (Sidney,
> > could you please test that everything still works?)
>
> No, there are two problems:
>
> 1) In spamd/SATest.pm remove line 264
>
> $spamdargs =~ tr,/,\\, if $RUNNING_ON_WINDOWS;
That was in there before and I didn't notice that it was removed by your
patch. I killed that line.
> 2) You removed the --stdout option to spamd and left the system call in
> the original style system ("$spamdargs > log/$testname.spamd 2>&1 &");
I never committed it ;-) But I just committed the change I had in mind: Now
spamd isn't started directly but an intermediate script SATest.pl which
does the redirection of STDOUT and STDERR. I'll visit my parents later on
and test it on my mother's Windows box (my SA-under-Windows testbed :).
The --stdout switch had the disadvantage, that it didn't catch *all* output
generated by spamd because the stuff was redirected after some output had
already been generated.
I'll commit the rest of your SATest.pm patches in a few minutes.
But what I really wanted to know, does spamc still compiles successfully
after the move?
Cheers,
Malte
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
Re: Own directory for spamc?
Posted by Sidney Markowitz <si...@sidney.com>.
Malte S. Stretz wrote:
> for Windows I'm not 100% sure (Sidney,
> could you please test that everything still works?)
No, there are two problems:
1) In spamd/SATest.pm remove line 264
$spamdargs =~ tr,/,\\, if $RUNNING_ON_WINDOWS;
The command line set up in $spamdargs invokes a cygwin executable and
has unix style arguments. There isn't any way to second guess things
here ... If somebody sets up SPAMD_SCRIPT to invoke spamd in some way,
they'll just have to make sure that whatever they set up can handle unix
format pathnames if there are any. SATest can't force it to Windows
style for them the way it has to when it invokes spamc.
The effect of this bug is that spamd doesn't run at all during the tests
because the spamd pathname argument to cygwin perl is changed to Windows
format.
2) You removed the --stdout option to spamd and left the system call in
the original style system ("$spamdargs > log/$testname.spamd 2>&1 &");
As we discussed, the redirection doesn't work when you use the "start"
command to background the process. I didn't explain how it doesn't work:
Windows redirects the output of the start command, not the command that
is being started, and offers no syntax for doing the latter. As a result
that command writes an empty output to the log file and spamd's output
appears in a console window. stop_spamd depends on the output from spamd
being written into the log file, where it can be read to extract the pid
to be killed.
So you have to find a way to get the output into the log file under
Windows. The way I did it was to implement the --stdout option to spamd,
add it to the arguments, and to change the system call to be
system("$spamdargs"). If you really want to you can make that
conditional on running under Windows.
The effect of this bug is that the spamd process is not killed when the
test tries to kill it.
-- sidney
Re: Own directory for spamc?
Posted by "Malte S. Stretz" <ms...@gmx.net>.
On Wednesday 14 January 2004 01:04 CET Malte S. Stretz wrote:
> On Wednesday 14 January 2004 00:37 CET Justin Mason wrote:
> > >On Monday 05 January 2004 04:37 CET Duncan Findlay wrote:
> > >> On Sun, Jan 04, 2004 at 09:59:25PM +0100, Malte S. Stretz wrote:
> > >> > What do you think about creating an own directory for spamc and
> > >> > move all related files (including qmail-spamc.c) there? (Moving
> > >> > files is very easy with SVN, I really love it :)
> > >>
> > >> Please :-)
> >
> > +1 -- move away.
>
> Ok, it'll get it's own directory in the next few days.
spamc (including qmail-spamc) resides now in its own directory, called
(surprise) spamc. Everything should work fine, even 'make spamd/spamc'.
'make disttest' succeeded both on Linux and Windows. But packagers might
want to check their scripts and for Windows I'm not 100% sure (Sidney,
could you please test that everything still works?)
Cheers,
Malte
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
Re: Own directory for spamc?
Posted by "Malte S. Stretz" <ms...@gmx.net>.
On Wednesday 14 January 2004 00:37 CET Justin Mason wrote:
> "Malte S. Stretz" writes:
> >On Monday 05 January 2004 04:37 CET Duncan Findlay wrote:
> >> On Sun, Jan 04, 2004 at 09:59:25PM +0100, Malte S. Stretz wrote:
> >> > What do you think about creating an own directory for spamc and move
> >> > all related files (including qmail-spamc.c) there? (Moving files is
> >> > very easy with SVN, I really love it :)
> >>
> >> Please :-)
> >
> >Any other opionions? Vetoes? Justin, Theo, Daniel, what do you think?
>
> +1 -- move away.
Ok, it'll get it's own directory in the next few days.
Cheers,
Malte
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>