bogofilter-static-1.0.0-1 RPM problem (CentOS 3.6)

[David Relson]

On Fri, 23 Dec 2005 11:19:31 +0100
Matthias Andree wrote:

> David Relson <relson at osagesoftware.com> writes:
> 
> >> What processor is this on?  Also what version of DB4?
> >> 
> >> I ask as had some NPTL problems on an AMD K6 with the default db4 rpm,
> >> issue (poorly) outlined here:
> >>   http://thread.gmane.org/gmane.mail.bogofilter.general/8305
> >> and see this bug related to NPTL (not sure if this is your issue):
> >>   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933
> >> 
> >> Chris
> >
> > Al & Chris,
> >
> > My static rpm was built with BerkeleyDB 4.2.52.  Using "ls -l" gives
> > the following info for the rpm and the files it installs..
> 
> What Chris is saying is that although the executable may have been
> linked statically, it may still have inherited dependencies on the
> processor type, mutex support or kernel of the build machine through the
> statically linked Mandrake Berkeley DB.
> 
> Remember the problem that transactions wouldn't work on some
> Fedora/processor combinations because only private environments were
> supported?  I have forgotten the details, the grand picture was that
> their Berkeley DB had compiled NPTL (next-generation POSIX thread
> library) stuff in, which worked only for the latest processor
> generation.
> 
> We need to solve the original problem though; I see these ways out:
> 
> A. 1. build a Berkeley DB 4.2 RPM that installs libdb-4.2.so in the default
>    shared library search path (usually /usr/lib on Linux).
> 
>    2. make sure the OS has GNU libc 2.3.4 or newer installed.
> 
>    3. install the shared-library version
> 
> B. 1. install a suitable Berkeley DB for your system (bogofilter copes
>    with 3.1, 3.2, 3.3, 4.0, 4.1, 4.2, 4.3, 4.4 and recommends 4.1 or
>    later, personally, I'd use 4.2 or newer though)
> 
>    2. use rpmbuild --rebuild on the official *.src.rpm.
> 
> You'll have to use B for x86_64, ppc, sparc and sparc64 anyways.
> 
> I haven't checked yet if LSB mentions anything WRT Berkeley DB that we
> could exploit to enhance compatibility.
> 
> 
> On a personal note, and this is distinctly *not* the official bogofilter
> team opinion: I have been against a convenience package such as
> bogofilter_static. Linking statically means more memory use, more
> efforts to upgrade should a relevant bug in Berkeley DB be found and
> fixed (since bogofilter_static will have to be rebuilt and reinstalled,
> too), and evidently it doesn't resolve problems as far as we'd wish it
> would.  The motivation was to offer a binary RPM for people to try if their
> system has a different Berkeley DB package installed, when instead the
> system should have provided at least a compatibility package (SUSE do,
> db42, and it has regular and thread-local-store variants in /usr/lib and
> /usr/lib/tls). (Personal note ends here.)

Matthias,

I've been corresponding with Al for over a week now.  His first message started with:

: I've downloaded bogofilter-1.0.0-1.i586.rpm and it runs fine on a Fedora 
:  Core 3 (Celeron).  The RPM installs on a Red Hat 9 system (AMD Duron), 
: but bogofilter dumps core.  Don't have a debugger on that machine, so 
: not sure why.  Both machines show up as i686 (uname -m), which leaves me 
: wondering if it is CPU issue since the RPM is i586.rpm.

For bogofilter to have problems on Red Hat 9 seems like something
important with which to deal!  Even though RH9 isn't what I use, it is
one of the major distributions.

In any case, Al shifted to bogofilter-static in an attempt to lessen
BerkeleyDB dependencies.  The problem remains the same, though he and I
have learned a bit more:

  With /etc/bogofilter.cf containing 1 line:
  
      bogofilter_dir=/root/bogofilter/testcore

  and running in directory /root/bogofilter/testcore (which is empty,
  except for the output of a prior "bogoutil -d" run), command 

    bogoutil -l wordlist.db < wordlist

  produces a SIGSEGV, while command 

    bogoutil -C -l wordlist.db < wordlist

  works fine.


  I can't recall ever seeing a problem like this when populating a new
wordlist using bogoutil.  Bogoutil has been reliable and robust, no?
With only a single process involved, threading issues seem improbable. 

> Now that we've had the _static packages in 1.0.0, every future 1.0.X
> version will have to offer them for compatibility, but we cannot
> possibly guarantee that it works on every system.

My recollection is that we created the static rpms for 2 reasons:
people without build privileges and people with borked BerkeleyDB
versions.  Building the static rpm is done automatically by my release
script.  It's not a problem for me.  By the way, here are the download
percentages (from SourceForge) for bogofilter-1.0.0:

 cnt     pct    file
 110    13.1%   bogofilter-1.0.0-1.i586.rpm
  69     8.2%   bogofilter-1.0.0-1.src.rpm
 262    31.3%   bogofilter-1.0.0.tar.bz2
 277    33.1%   bogofilter-1.0.0.tar.gz
  28     3.3%   bogofilter-static-1.0.0-1.i586.rpm
  17     2.0%   md5sum
  24     2.9%   NEWS
  51     6.1%   RELEASE.NOTES
 838


> 
> AFAIK, the pkgsrc project of NetBSD fame has been ported and works on
> Linux, Solaris and other systems. So pkgsrc can also be used to build a
> bogofilter version (currently 0.96.6, supporting db4.3.29 or
> sqlite3.2.7) which may help building a local version, all dependencies
> will be resolved automatically within pkgsrc.
> 
> -- 
> Matthias Andree