Mark,

On 31 Oct 2007, at 12:46 pm, Mark Rogers wrote:

I'm still trying to get my head around the correct way to configure a typical source tarball installation to fit into the Debian way of doing things.

It would probably be wise to start by reading this:

http://www.debian.org/doc/maint-guide/

and then perhaps http://www.debian-administration.org/articles/336 and http://www.debian-administration.org/articles/337

should give you a flavour.

Out of interest, what is the package you're recompiling? Have you tried looking at backports.org to see if it has already been backported?

Cheers,

Dave

On Thu, Nov 01, 2007 at 09:56:30AM +0000, Mark Rogers wrote:

David Reynolds wrote:

...

It would probably be wise to start by reading this:

http://www.debian.org/doc/maint-guide/

and then perhaps http://www.debian-administration.org/articles/336 and http://www.debian-administration.org/articles/337

should give you a flavour.

Thanks, I'll add that to the top of the bedtime reading pile!

...

Out of interest, what is the package you're recompiling? Have you tried looking at backports.org to see if it has already been backported?

dspam.

All the repos have 3.6.8, but 3.8.0 has been available for months and I'm told it fixes a few bugs, but I'm not going to be able to properly test it without putting it onto a live server to get the volume of traffic, so I need to be sure that I can install it and (if necessary) uninstall it and put the official version back without too much grief.

I'd be interested to know what bugs it fixes - dspam 3.6.8 appears to be doing a *fantastic* job on my mail...

Anyways - looking at: http://dspam.nuclearelephant.com/text/CHANGELOG-3.8.0.txt

Doesn't look like there's a lot of difference between the two, and it should be fairly simple to do a backport as follows: apt-get source dspam

Swipe the debian directory from there and put it in to a untarred 3.8.0 directory.

dch -v "3.8.0-0local"

Add changelog line.

dpkg-buildpackage -r fakeroot

rejoice.

Brett Parker wrote:

I'd be interested to know what bugs it fixes - dspam 3.6.8 appears to be doing a *fantastic* job on my mail...

I'm probably looking in the wrong direction, but whilst dspam does indeed do a fantastic job on our email too, it dies perhaps once per day leaving a queue to build up. (Hence the recent thread about using cron to restart mail server.) My server has to handle about 4000 emails/hr, and dspam probably isn't the bottleneck, but it's the bit that's dying, without logging anything to debug it.

There was an additional reason in that I found a patch for 3.8.0 which would enable me to set a threshold for spam to be deleted rather than quarantined (in our experience, if I deleted everything over 90% I'd lose a lot of the quarantine and would never yet have lost a valid email). Unfortunately I can't now find that patch anyway. It would probably have been easy to apply to 3.6.8 - as you say there's not a lot changed - and now that I'm investigating this more I'm finding reports of problems that 3.8 introduced, so the exercise is about 50% academic now (I just want to know how to do it!)

Doesn't look like there's a lot of difference between the two, and it should be fairly simple to do a backport as follows: apt-get source dspam

Swipe the debian directory from there and put it in to a untarred 3.8.0 directory.

dch -v "3.8.0-0local"

Add changelog line.

dpkg-buildpackage -r fakeroot

Thanks, that's just the info I was after! I'll give it a whirl!

rejoice.

Fingers crossed :-)

On Thu, Nov 01, 2007 at 01:53:41PM +0000, Mark Rogers wrote:

Brett Parker wrote:

...

I'd be interested to know what bugs it fixes - dspam 3.6.8 appears to be doing a *fantastic* job on my mail...

I'm probably looking in the wrong direction, but whilst dspam does indeed do a fantastic job on our email too, it dies perhaps once per day leaving a queue to build up. (Hence the recent thread about using cron to restart mail server.) My server has to handle about 4000 emails/hr, and dspam probably isn't the bottleneck, but it's the bit that's dying, without logging anything to debug it.

Ahhh - as an aside to that - I'm going to be looking in to adding dspam support to exim4's acl handler (there's already SA support in the form of the spam condition, but SA definately won't run on my poor little vm!) - I appear to currently handle at most 120 mails an hour (which, technically I suppose, is only 60 mails an hour, because most of those hit dspam which then reinjects it in to exim), but I don't use the dspam daemon... IME dspam is light enough that it's probably as quick using dspam directly as using the daemon...

Anyways - that's my next proper project, getting dspam support in to the acl stage of exim - should be, err, fun ;)

Cheers,

Brett Parker wrote:

dpkg-buildpackage -r fakeroot

OK, that should have been -rfakeroot according to my attempts, but having got that far I'm stuck with the following errors: dpatch apply-all applying patch manpage-in-right-section to ./ ... ok. applying patch link-dynamically to ./ ... ok. applying patch drivers-in-usr_lib_dspam to ./ ... ok. applying patch dspam-webfrontend-config-debian to ./ ... ok. applying patch update-dspam.conf to ./ ... failed. make: *** [patch-stamp] Error 1

I guess that one of the Debian/Ubuntu patches has failed to patch against the new 3.8 dspam.conf but I'm not sure how to proceed?

Mark Rogers mark@quarella.co.uk wrote:

Mark Rogers wrote:

...

applying patch update-dspam.conf to ./ ... failed.
make: *** [patch-stamp] Error 1

[...]

Any suggestions? I haven't managed to find out what patch-stamp "Error 1" means, a Google shows too much noise to find the signal.

That message is from make. I think it means that something exited with error value 1 when trying to build the patch-stamp target (which I think is a dummy timestamp file). So, a command after "patch-stamp:" in the Makefiles failed. I suspect that's dpatch failing, because of the error shown above.

Looking at http://svn.debian.org/wsvn/pkg-dspam/trunk/debian/patches/update-dspam.conf.... it seems only to update dspam.conf.in... does it leave a dspam.conf.in.rej around? Can you apply your new patch manually OK? It might be some change in autotools which is confusing it.

Regards,

Mark Rogers wrote:

MJ Ray wrote:

...

Can you apply your new patch manually OK?

I think so, how best to check? I know the basics of diffs and patches but none of it is day-to-day stuff for me. (yet!)

Sussed it: I didn't have the path's right in the diff to match the directory structure (or at least depth) being used when the patch was applied.

Found a few other similar problems but now getting much further into the build. (Next problem: dspam 3.6.8 had an Oracle driver, dspam-3.8.0 does not, so files are missing.) Nobody said it would be easy, I suppose :-)