[4839] in linux-announce channel archive
Linux-Announce Digest #132
daemon@ATHENA.MIT.EDU (Digestifier)
Tue May 17 17:13:05 2005
From: Digestifier <Linux-Announce-Request@senator-bedfellow.mit.edu>
To: Linux-Announce@senator-bedfellow.mit.edu
Reply-To: Linux-Announce@senator-bedfellow.mit.edu
Date: Tue, 17 May 2005 17:13:02 EDT
Linux-Announce Digest #132, Volume #5 Tue, 17 May 2005 17:13:02 EDT
Contents:
Bogofilter-0.94.12 - New Stable Release (David Relson)
http://lists.debian.org/debian-devel-announce....Debian Sarge is frozen ("Frederick Noronha (FN)")
----------------------------------------------------------------------------
From: David Relson <relson@osagesoftware.com>
Subject: Bogofilter-0.94.12 - New Stable Release
Date: 16 May 2005 23:10:02 GMT
Bogofilter is a mail filter that classifies email as spam or ham
(non-spam) by a statistical analysis of the message's header and content
(body). The program is able to learn from the user's classifications
and corrections.
The statistical technique is known as the Bayesian technique and its use
for spam was described by Paul Graham in his article "A Plan For Spam".
Gary Robinson, in his weblog Rants, suggests some refinements for
improved discrimination between spam and ham. Bogofilter's primary
algorithm uses the f(w) parameter and the Fisher inverse chi-square
technique that he describes.
Bogofilter is run by an MDA script to classify an incoming message as
spam or ham (using wordlists stored by BerkeleyDB). Bogofilter provides
processing for plain text and html, supports multi-part mime message
with decoding of base64, quoted-printable, and uuencoded text and
ignores attachments, such as images.
Bogofilter is written in C. Supported platforms: Linux, FreeBSD,
Solaris, OS X, HP-UX, AIX, RISC-OS, OS/2, ...
******* ******* ******* ******* *******
The biggest change in bogofilter (since the last stable release in
October 2004) is support for Berkeley DB's transaction capability and
the SQLite3 database.
Lesser changes include a change in classification defaults (from
bi-state to tri-state classification), documentation updates (esp man
page and FAQ), internal code cleanups (including how long options are
processed).
########################################################################
Files are available at http://sourceforge.net/projects/bogofilter for
download.
Here are the md5sums for the release:
1a2825782885f606c9779f2569ca0ac7 bogofilter-0.94.12-1.i586.rpm
3c9d9eb40bb833e9ea0aaedc8936cde0 bogofilter-0.94.12-1.src.rpm
489337defebff75d8e2b46350e946752 bogofilter-0.94.12.tar.bz2
1c578a27fe6e51ad0fd63374cf241335 bogofilter-0.94.12.tar.gz
fed29b28e2d0e16ff5407e9e3ae2f42e bogofilter-static-0.94.12-1.i586.rpm
################################################################
---- Classification Change ----
Bogofilter's classification default has changed from two-state (Yes/No)
to tri-state (Spam/Ham/Unsure). This shows up as a change to the
X-Bogosity line. Spam and ham now appear as:
X-Bogosity: Ham, tests=bogofilter, spamicity=0.011004, ...
X-Bogosity: Spam, tests=bogofilter, spamicity=0.922911, ...
Previously the words "Yes" and "No" were used to identify ham and
spam. Classification "Unsure" is used for messages scoring between
0.45 and 0.99).
---- Changed Options ----
Some options have been added or modified. If you use any of the
changed options, you will probably need to modify your scripts,
procmail recipes, etc. As an example, some bogoutil options which
used to allow either filenames or directory names are now restricted
to filenames. See the man pages and help messages if you have
questions.
---- Transaction Information ----
Prior to version 0.93.0, bogofilter used Berkeley DB only in its
non-transactional mode. With 0.93.0, the use of Berkeley DB's
transactional mode was added. Why transactions? Because transactions
offer ACID, which stands for Atomicity, Consistency, Isolation, and
Durability, which are key to transaction processing in databases and
ensuring the integrity of a database. For more on the subject, see
Wikipedia, i.e. http://en.wikipedia.org/wiki/ACID.
What transactions offer is additional protection against database
corruption. They also include page level locking which makes it
possible for multiples copies of bogofilter (and bogoutil) to be
reading and writing the wordlist at the same time. To make this
happen, Berkeley DB uses additional files, specifically lockfiles and
log files. The presence of these files means that copying a wordlist
can no longer be done using the "cp" command. Bogofilter now includes
utility scripts bf_compact, bf_copy, bf_resize, and bf_tar for
handling 4 common chores relating to databases.
Bogofilter's default build makes use of transactions optional. If
you've never used transactions and haven't told bogofilter to use
them, it won't use them. This simplifies administering bogofilter,
though the risk of a corrupted database is higher. See file
doc/README.db for more detailed technical information on bogofilter's
handling of transactions and how to set up your machine to best support
transactions.
When bogofilter starts, it'll check the bogofilter directory (which
contains the wordlist file) to see if transactions have been used. If
so, it will use transactions; if not, it won't use them.
This auto-probing can be overridden when running bogofilter and
bogoutil. All that is needed is the proper a command line option
("--db-transaction=yes" or "-db--transaction=no" ) or the proper
config file option ("db_transaction=yes" or "db_transaction=no").
Alternatively, when building from source, ./configure can be given
option "--enable-transactions" or "--disable-transactions" to build
executables that will only operate in one mode (and that are a slight
bit smaller).
---- SQLite3 Backend ----
SQLite3 is also supported. It is an alternative, easy-to-handle
datastore that also exhibits ACID properties. It has the same
guarantees as Berkeley DB Transactional Data Store, without the
headaches of lock files and log files. Version 3.2.0 is required.
---- Other Changes ----
For information on other changes, see the Change Log in the NEWS file.
##########################################################################
# Send submissions for comp.os.linux.announce to: cola@stump.algebra.com #
# PLEASE remember a short description of the software and the LOCATION. #
# This group is archived at http://stump.algebra.com/~cola/ #
##########################################################################
------------------------------
Date: Tue, 17 May 2005 02:47:42 CST
From: "Frederick Noronha (FN)" <fred@bytesforall.org>
Subject: http://lists.debian.org/debian-devel-announce....Debian Sarge is frozen
Hello world,
Anthony Towns has committed a minor change to the britney script which
manages updates of packages to testing, and as a result packages are no
longer being accepted into testing without hand-approval by a member of
the release team.
Wait, that didn't come out quite right. Let's try again.
Sarge is now frozen! Wheeeeeee!!!
Thanks are due to everyone who has helped get us to this point: in
particular our ftpmasters, Anthony Towns, James Troup, and Ryan Murray,
for their continued dedication which has made it possible for mortals to
wrangle behemoths such as the 9,000-package sarge; our co-wranglers, the
release assistants Andreas Barth, Frank Lichtenheld, and Joey Hess; and
you, gentle maintainer, for your support and patience.
For those maintainers whose packages were unprepared for a freeze at
this moment (the process has, after all, been a long one), you still
have one last opportunity to get things into shape if there are any
remaining important problems. Read on.
Now to explain what, exactly, we mean by "freeze". The base freeze
upload policy of uploading changes in through unstable if you can,
and testing-proposed-updates if you must, has worked well (or so is the
subjective opinion of the release team), so we plan to continue to apply
the same policy for the freeze of the rest of the archive.
This means that, for all packages that still need to be updated for
sarge, the rules are as follows:
- If your package needs to be updated for sarge, and the version in
unstable doesn't contain extraneous changes (e.g, the version is the
same between testing and unstable), please upload your fix to
unstable and contact debian-release@lists.debian.org.
- If the version in unstable already includes significant changes not
related to the bug to be fixed, contact debian-release about
uploading to testing-proposed-updates. Changed dependencies, new
upstream versions, changed library names, and completely rewriting
the packaging are "significant changes". So are lots of other
things.
- If the version in unstable won't reach testing because of new
library dependencies, contact debian-release about uploading to
testing-proposed-updates.
- If in doubt, contact debian-release first.
- In all cases, when preparing an upload please do not make changes to
the package that are not related to fixing the bugs in question.
Doing so makes it more time consuming for the release team to review
and approve such requests, delaying the release. It also delays the
fix for your package, because you will be asked to reupload.
- When contacting the release team, please explain why you are
requesting an update. Bug numbers are a must. The more we can
figure out from your first email and your changelog (if any), the
more quickly we can get your update in.
- If you have a package that needs updating, *please* don't forget to
contact us. *Don't expect us to find out about it on our own*.
Putting a comment in the changelog is not contacting the release
team. :) (This has happened at least a couple of times during the
base freeze; it's not a very good way of getting your package
approved quickly.)
Now, so as not to have everyone contact us at once about packages we
know we won't approve, here are the guidelines for changes that will be
accepted into testing during the freeze:
- fixes for release critical bugs (i.e., bugs of severity critical,
grave, and serious) in all packages
- fixes for severity: important bugs in packages of priority: optional
or extra, only when this can be done via unstable
- translation updates
- documentation fixes
See <
http://lists.debian.org/debian-devel-announce/2004/08/msg00001.html>
for comparison.
As always, it is the release team's goal to get as much good software
into sarge as possible. However, a freeze does not mean that your
package is ensured a spot in the release. Please continue to stay on
top of release-critical bugs in packages that you maintain; RC bugs in
optional or extra packages that remain unfixed after a week will still
be grounds for removal from testing, just as they have been up to this
point.
Please also note that since many updates (hopefully, the vast majority)
will still be going in through unstable, major changes in unstable right
now can disrupt efforts to get RC bugs fixed. We don't ask you not to
make changes in unstable, but we do ask that you be aware of the effects
your changes can have -- especially if you maintain a library -- and to
feel free to continue making use of experimental where appropriate.
Note once again that you can stage NEW uploads in experimental to avoid
disruption in unstable....
##########################################################################
# Send submissions for comp.os.linux.announce to: cola@stump.algebra.com #
# PLEASE remember a short description of the software and the LOCATION. #
# This group is archived at http://stump.algebra.com/~cola/ #
##########################################################################
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: Linux-Announce-Request@NEWS-DIGESTS.MIT.EDU
You can submit announcements to be moderated via:
Internet: linux-announce@NEWS.ORNL.GOV
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Announce Digest
******************************
