Not much to say ... latest version of amavisd-new, works for me! Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 39807 [details] the ebuild
Created attachment 39808 [details, diff] some amavisd.conf mods
*** Bug 61540 has been marked as a duplicate of this bug. ***
There are three issues that I've discovered with the amavisd-new ebuild: 1) The section which calls razor-admin to create a configuration profile under ${AMAVIS_ROOT} fails _if_ the directory /etc/razor exists and it contains a razor-config file. Specifically, it will not create the ${AMAVIS_ROOT}/.razor/razor-config file because it opts to defer to the file contained under /etc/razor. This causes the sed operation following to fail, and obviously breaks the intended purpose of the process there. I daresay this was a problem in the previous ebuilds too. 2) The default location for the process ID file is now /var/amavis/amavisd.pid. This prevents the init.d script from shutting down the service properly. The solution is either (a) to patch /etc/amavisd.conf to use: $pid_file = "/var/run/amavisd.pid"; (b) to alter the init.d script to use /var/amavis/amavisd.pid when shutting down the service. 3) There is also the matter of the incompatibility with spamassassin-3.0 as described in http://bugs.gentoo.org/show_bug.cgi?id=58057#c32 (due to the fact that amavis is hardcoded to use what is now the wrong path to invoke spamassassin. My tests were conducted with razor-2.62, spamassassin-3.0 and the amavisd-new ebuild in this bug.
Correction, for problem (3) I meant that the spamassassin-3.0 ebuild sets a DATADIR which causes it not to interoperate with amavisd-new.
Furthermore, I meant razor-agent.conf (not razor-config) ... excuse me while I go and prepare some more coffee ;)
With regard to the spamassassin compatibility, I've found that the easiest thing to do is to set: DEF_RULES_DIR => '/usr/share/spamassassin/core', in the block that instantiates the Mail::Spamassassin object in /usr/sbin/avamisd (line #10202). I suppose the question is how to support both the 2.x and 3.x series of spamassassin in this ebuild. By the way (as a matter of curiosity), isn't sed frowned upon in ebuilds in favour of patching?
OK, I think I have a neat solution. Apply a patch which alters line #10202 in /usr/sbin/amavisd from: # DEF_RULES_DIR => '/usr/local/share/spamassassin', to: DEF_RULES_DIR => ((-e '/usr/share/spamassassin/core') ? '/usr/share/spamassassin/core' : '/usr/share/spamassassin'), I'll attach a patch which does exactly that (just a -p0 job). Can anyone percieve any problems with this approach?
Created attachment 40216 [details, diff] spamassassin-3.x compat patch Alters the instantiation of the Mail::SpamAssassin object so that the named parameter DEF_RULES_DIR will be '/usr/share/spamassassin/core' if the directory exists, or /usr/share/spamassassin otherwise.
That can't possibly be done? patching a file, belonging to another package, while installing SpamAssassin-3.0 wouldn't be allowed by the sandbox. If you mean, that you want to update the amavisd-new ebuild, so it does this - then there's the problem that people will have to update/reinstall their amavisd-new to get it working with spamassassin-3.0 - IMHO bad behavior - means there has to be an einfo about this - and I personally hate stuff, that doesn't "just work". The author of amavisd-new says he has prepared amavisd-new so it just should work with SA-3 - isn't the only reason it doesn't on Gentoo - that the files are placed in an odd folder - instead of where the default is?
> That can't possibly be done? patching a file, belonging to another package, while installing SpamAssassin-3.0 wouldn't be allowed by the sandbox. I don't follow - the patch falls purely within the scope of the amavisd-new ebuild and alters usr/sbin/amavisd. What's the issue with that? > If you mean, that you want to update the amavisd-new ebuild, so it does this > - then there's the problem that people will have to update/reinstall > their amavisd-new to get it working with spamassassin-3.0 Yes, this is true. There are a a few other ebuilds in portage which exhibit this class of problem (having to rebuild aspell after I upgraded gcc to avoid a compilation failure in a newer version of gedit which links to aspell being one of the more obscure examples I can think of). I don't like it much either and I think some ebuilds should be able to request the recompilation/rebuilding of others - but that's way out of scope here ;) > isn't the only reason it doesn't on Gentoo - that the files are placed in an odd folder - instead of where the default is? If you meant that the DATADIR is being altered from its default upstream configuration then (1) I don't actually know because admittedly I haven't checked (2) yes, you are absolutely right - my suggestion should be ignored and the "proper" solution should probably go in another bug if it hasn't already.
This patch looks like it will work to me. Hopefully you can get this ebuild into portage soon, as it is anyone trying to use amavisd-new and SA 3.0 has a broken system, and no obvious clues why.
Yes, it does work. I don't see the issue with it - the older versions can be revision bumped, and this new ebuild could go in as unstable. However, as Klavs Klansen mentioned, if the spamassassin ebuild is configuring for a non-standard location for the rulesets then maybe it is that ebuild that should be fixed. Aside from this, there are still the other flaws with the ebuild that I mentioned originally. I'll make more posts on this bug if I work out anything sensible regarding that. I can't be sure what is the "right" or the "wrong" way so I'm hoping a dev will step in at some point and clean this all up ;)
It looks to me, like the spamassassin ebuild is the buggy one: (from SA-3 ebuild) # - Set DATADIR to a subdirectory so other ebuilds which offer rules can store # their stuff below the dir, too. myconf="SYSCONFDIR=/etc DATADIR=/usr/share/spamassassin/core" This makes no sense to me - if other ebuilds did that - SA-3 wouldn't look for them there - otherwise we wouldn't have the problem with amavisd-new that we have. ie. ALL rules needs has to be in the same dir AFAIK - and atleast the SA-core rules, should be where they are suppose to be. If you agree (thus I'm not blind/stupid :) - this should perhaps be turned into a SpamAssassin ebuild problem - or a new bug be created?
I got off my backside and checked ;) ... indeed you are correct. The default is /usr/share/spamassassin for a standard build. One might file it at bug #58057, but mcummings said that the bug was just to track the release process so it looks like a new bug is needed. I'll do it later if no-one else has (if you feel like doing it then please link it here :). Maybe the change was for a reason, but on the face of it I can't think why.
According to te comment in the SA 3.0 ebuild, it's to allow other packages to place their rules in different directories, but this really doesn't make sense since, as you say, SA (and amavisd and rulesdujour, etc.) expect all the rules to be in the same directory, or in SA 'home' directory. The way I see it is this change just breaks everything else for no good reason.
http://bugs.gentoo.org/show_bug.cgi?id=65102 submitted.
how about amavisd-new-2.2.0 ?
Created attachment 43721 [details] amavisd-new-2.2.0.ebuild
This dep no longer exists: >=dev-perl/MIME-tools-6.2 It should be >=dev-perl/MIME-tools-5.415 Also, when I place this ebuild in my overlay, portage does not see it as a newer version (2.2.0 is not newer than 20040701). I had to rename the ebuild to amavisd-new-20041102.ebuild, but then the download failed because the wrong filename was used.
Created attachment 44578 [details] amavisd-new-2.2.0.ebuild MIME-tools dependency fixed. Some of the archiving applications could probably be removed as dependencies also. Add >=mail-filter/amavisd-new-200 to /etc/portage/package.mask to get around the previous odd versioning scheme.
I tested further and found one more thing, the init.d script needs to be changed so the stop action uses the right pidfile, /var/amavis/amavisd.pid: -start-stop-daemon --stop --quiet --pidfile /var/run/amavis/amavisd.pid +start-stop-daemon --stop --quiet --pidfile /var/amavis/amavisd.pid Other than that, it works great! Will this ebuild be checked in to cvs soon? The only problem now is how to handle the version stuff.
Created attachment 44604 [details] amavisd.rc6 Fixed init script. One thing I noted is that amavisd-nanny and amavisd-agent dies with: BDB no env: No such file or directory So either we should not install (they were added in the previous ebuild submitted) them or get it fixed. I'm a bit short on time right now, but if I'll try to take a look at it soon if noone else does before.
<quote>I tested further and found one more thing, the init.d script needs to be changed so the stop action uses the right pidfile<quote> Er, I pointed that out as the second of three problems in comment #4! Please note that the first problem I describe in that comment also *still* applies (yes it's a genuine bug, not just a complaint) - Sune, do you have any thoughts on it? <quote>So either we should not install (they were added in the previous ebuild submitted) them or get it fixed.<quote> Well I, for one, am definitely in favour of getting things fixed. Thanks for looking at this; I'll try and find some time myself to help conclude these problems.
Kerin, I cannot recreate the razor problem. As for the amavisd-nanny amavisd-agent problem you have to remove /etc/amavisd.conf before emerging the package or add: $enable_db = 1; # enable use of BerkeleyDB/libdb (SNMP and nanny) Somehow etc-update is not playing nicely with the changed versioning scheme I guess.
Ah, I see. I'll run through it again from scratch and see what happens on my end.
I also found that amavisd-new-2.2.0.ebuild is missing a RDEPENDS to dev-perl/BerkeleyDB.
dev-perl/BerkeleyDB is listed in RDEPEND on line 44 of the current ebuild. CC'ing net-mail herd. If I had commit rights I'd be willing to maintain this one.
Sune, I'll commit this if you willing to help with bug.
Tuan, I'm here to assist should any bugs crop up.
With the new versioning scheme Portage will not pick this up as an update. After talking with Genone I think we should do the following: 1. Commit 2.2.0 (perhaps add a small comment saying something about abandoning the date versioning scheme). 2. Commit 20040701 as 0.20040701 with added comments as above. 3. Mask 20040701 so stable users will be "downgraded" to 0.20040701. Repeat step 2+3 for 20030616_p9 and 20030616_p8. Any thoughts? Otherwise I'll provide the updated ebuilds shortly.
Sune, sound like a good plan. BTW, would please take a look at these bugs to see if we need to add anything. Close them if it is fixed in the new ebuild. Thanks.
Created attachment 45587 [details] amavisd-new-2.2.0.ebuild - Fixed SRC_URI - Removed the warning about new home directory (was for previous version). - Modified warning if SpamAssassin is not installed to not mention specific line numbers in amavisd.conf. - Added dep on cabextract and removed dep on zoo and freeze.
Created attachment 45932 [details] amavisd-new-0.20040701.ebuild diff amavisd-new-0.20040701.ebuild /usr/portage/mail-filter/amavisd-new/amavisd-new-20040701.ebuild 7,8d6 < MY_VERSION="20040701" < 11c9 < SRC_URI="http://www.ijs.si/software/amavisd/${PN}-${MY_VERSION}.tar.gz" --- > SRC_URI="http://www.ijs.si/software/amavisd/${PN}-${PV/_/-}.tar.gz"
Created attachment 45978 [details] amavisd-new-0.20040701.ebuild Cosmetic fix.
Created attachment 45980 [details] amavisd-new-2.2.0.ebuild Add initial courier support.
Created attachment 45981 [details] amavisd-new-2.2.0.ebuild Removed courier einfo warning as it seems to be wrong.
Created attachment 46020 [details] amavisd-conf.diff Minor fix to default config.
Created attachment 46062 [details] amavisd-new-2.2.0.ebuild Fixed epatch statement.
Created attachment 46081 [details] amavisd-new-2.2.0.ebuild Should work for non Courier users even with Courier patch. Removing last warning.
2.2.1 released. Bump works fine. (Not adding app-arch/pax to DEPEND as it is only stable on a few arches).
I stabled 20040701 yesterday on x86. I'll let it sit for a day or two then revision it to .20040701 then bring this in. Thanks.
Sune, thanks for all of your excellent work on this. I grabbed the amavisd-new-2.2.0 ebuild and bumped it to 2.2.1 (masking anything >2.2.1) and installed it. Thus far, everything is working as expected and all of the gremlins discussed prior on this bug appear to have been resolved :)
Seems like further progress will be tracked on bug 77425.
Thanks everyone.
