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.
The best I've found so far is: ./configure --prefix=/usr --sysconfdir=/etc \ --sharedstatedir=/var --localstatedir=/var \ --libexecdir=/usr/lib
Does all that look correct?
The general idea is that if I want to try and build a replacement .deb for an existing package, using a more up to date source tarball, then I want all the files to end up in the same places as would have been the case for the original package.
(For all the documentation I've found, the best so far was an answer to a similar question on a dbus mailing list: http://lists.freedesktop.org/archives/dbus/2006-September/005618.html)
For the time being I'm only looking at i386 packages but I think the only thing that would change for 64-bit would be /usr/lib to /usr/lib64?
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
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.
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 iDunno@sommitrealweird.co.uk [2007-11-01 10:31]:
On Thu, Nov 01, 2007 at 09:56:30AM +0000, Mark Rogers wrote:
David Reynolds wrote:
<<snip>>
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...
** end quote [Brett Parker]
That's nice to hear. I'm just reading up in preparation for an install on my servers. It looks to be better setup for multi-user, multi-domain than Spamassassin from what I've read so far. I'm just revamping my virtual hosting configuration in Exim, possibly using Virtual Exim, to make things a little easier (as in fewer changes to the config post install as I've been planning to use a database backend for it instead of the file structure I put in place rather quickly when I set it up).
Paul Tansom wrote:
That's nice to hear. I'm just reading up in preparation for an install on my servers. It looks to be better setup for multi-user, multi-domain than Spamassassin from what I've read so far.
We're using postfix, but our anecdotal experience is that we get about 50-60x more email through dspam on similar hardware than SA, and that's the reason we're looking at it.
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 wrote:
applying patch update-dspam.conf to ./ ... failed. make: *** [patch-stamp] Error 1
I think its safe to say I'm out of my depth here...
I have worked through the update-dspam.conf.dpatch file (which was of-course generated against files from the 3.6.8 install), and manually applied the patches to dspam.conf.in (from 3.8.0), then recreated the patch file, dropped it in the same directory, and tried again. Same error.
Looking at the patches that needed applying I don't now think (which I had previously thought) that the patch was failing because the 3.8.0 file was too different from the 3.6.8 file for the patch to work. Other patches have applied correctly, though.
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.
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,
MJ Ray wrote:
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?
Yes it does, although I'm not sure what it tells me.
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!)
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 :-)
Mark Rogers mark@quarella.co.uk wrote:
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, [...]
The 3.6.8 packaging is available through SVN or HTTP from http://alioth.debian.org/projects/pkg-dspam/ http://svn.debian.org/wsvn/pkg-dspam
Please update http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418736 if you manage to package it. It sounds like it would be a very good achievement, appreciated by many people!
Thanks,
MJ Ray wrote:
Please update http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418736 if you manage to package it. It sounds like it would be a very good achievement, appreciated by many people!
I've sent an update to that bug, and also created one for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/dspam/+bug/160139
I've been using Ubuntu sources (hence creating the Ubuntu bug) but I suspect they'll just want to push this back upstream to Debian anyway.
-
Brett Parker -
David Reynolds -
Mark Rogers -
MJ Ray -
Paul Tansom