Re: can't build mail/spamassassin

[Klaus Heinz <k.heinz%maerzehn.kh-22.de@localhost>]

Robert Elz wrote:

> It looks as if the spamassassin rules on the master site have been
> updated, they're now r923257 (whatever the number denotes - it is bigger
> than r923114 anyway ...)

The number comes from the subversion repository.

> And it appears that the rule set that pkgsrc expects never made it to f.n.o

In former times I updated the files on the ftp server myself, not
relying on the process that is supposed to fetch them automatically.
I do not quite remember why I quit doing that, maybe at one time
I could not write to the directory anymore.

> Anyone who needs them can fetch them from there until a copy make it to
> f.n.o so pkgsrc can auto fetch them.  (The spamassassin source file is
> there as well).    I'm tempted to make it available via IPv6 only, but
> this time, I won't...

I uploaded my own copy of those files to ftp.NetBSD.org and will
inquire upstream why they changed them. As far as I know this was not
supposed to happen...

> What I don't understand with the new spamassassin pkgsrc is the way the
> options (other than ssl and inet6) are handled - that is the spamassassin
> specific options.   pkgsrc has quite a nice options framework, why can't
> spamassassin just use it?

Do you refer to the options which were available in the pkgsrc package for
SpamAssassin 3.2.5?

If you refer to the "options" mentioned below in capital letters,
they are (mostly) not options for users. They are just a means to inform
SpamAssassin of the values chosen by the building entity (that is, pkgsrc).

CONTACT_ADDRESS is in fact a user option but it is supposed to be set
with the keyword 'report_contact' in the configuration file local.cf.
SpamAssassin's build process asks for a contact address interactively.
To avoid this unwanted interaction I requested a variable for this from
upstream und thus CONTACT_ADDRESS was born some years ago.

> Checking if your kit is complete...
> Looks good
> 'CONTACT_ADDRESS' is not a known MakeMaker parameter name.
> 'DEFRULESDIR' is not a known MakeMaker parameter name.
> 'ENABLE_SSL' is not a known MakeMaker parameter name.
> 'LOCALRULESDIR' is not a known MakeMaker parameter name.
> 'LOCALSTATEDIR' is not a known MakeMaker parameter name.
> 'PERL_BIN' is not a known MakeMaker parameter name.
> 'PERL_TAINT' is not a known MakeMaker parameter name.
> 'PERL_WARN' is not a known MakeMaker parameter name.
> 'SYSCONFDIR' is not a known MakeMaker parameter name.
> Writing Makefile for Mail::SpamAssassin
> Makefile written by ExtUtils::MakeMaker 6.55
> 
> which looks "dubious" to me - should I trust that this spamassassin
> has built correctly?

Those harmless but worrying messages come from ExtUtils::MakeMaker
(included in the Perl base distribution). The file Makefile.PL in
SpamAssassin accepts some parameters for the module ExtUtils::MakeMaker
as well as some for its own use. SpamAssassin included a hack to prevent
those messages by using some private variables of ExtUtils::MakeMaker.
Since version 6.43 of ExtUtils::MakeMaker this hack is no longer working,
thus leading to the messages you see.

There is a problem report for this behaviour:

  https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6266

> The build also complains that a whole bunch of (optional) perl modules
> are missing - none of those seem to be anything I care about, but this
> does kind of suggest that the default build might vary depending upon what
> happens to be installed on the build system (and without being listed as
> a dependancy oin a binary package) - I build in a pkg_comp sandbox with
> nothing installed except what the pkgsrc Makefile says it requires (directly
> or via bl3 etc), so all the seemingly optional stuff was absent for my
> build, but would it have been used if I did have it installed?   (Stuff
> like IP::Country and Net::Ident)

Those messages all come from SpamAssassin and suggest modules you might
be interested in. If they happen to be installed they will be used at
run-time, either automatically or if you enable them via the appropriate
plugin.
In your examples, you have to have IP::Country installed to enable the
plugin Mail::SpamAssassin::Plugin::RelayCountry (see the file 
/usr/pkg/etc/spamassassin/init.pre).
Net::Ident is used when you give the option "--auth-ident" to spamd,
otherwise you get messages like this:

  error: spamd: ident-based authentication requested, but Net::Ident
  is unavailable

ciao
     Klaus