pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: can't build mail/spamassassin



    Date:        Sat, 27 Mar 2010 19:45:53 -0400
    From:        Steven Bellovin <smb%cs.columbia.edu@localhost>
    Message-ID:  
<C450A424-5D03-4E66-83C6-167908825648%cs.columbia.edu@localhost>

  | attempts to fetch Mail-SpamAssassin-rules-3.3.1.r923114.tgz fail.

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 ...)

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

I did manage to fetch a copy (and have sent the files to smb) - I have also
put them on munnari.oz.au:

        ftp://munnari.oz.au/pub/sa-rules/*

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...

Incidentally, I totally agree with both supplying a set of rules with pkgsrc
(not expecting people installing the package to automatically have net access
when they install it) and with picking one set of rules and making those be
what pkgsrc installs (people who want newer ones can then go and update as
often as they feel the need - personally, I prefer things to be stable, so I
can trust my mail filtering - if it is occasionally not as up to date as
possible, then some spam will slip through - big deal, even with perfect rules
it gets through anyway ... - the alternative is to be constantly running
something where I'm never really sure what works and what doesn't).

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?

As it is now, the build reports ...

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?

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)

kre



Home | Main Index | Thread Index | Old Index