Date | Commit message (Collapse) |
|
We already "use warnings" everywhere, but could miss some spots.
This ought to cover that, and usually Perl module authors are
consistent about avoiding warnings that we won't clutter our
test outputs.
|
|
This can useful for limiting test resource use without relying
on remembering the variable command-line.
|
|
It's only useful for a corner case in long-running daemons when
an admin decides to compact or vacuum a Xapian or SQLite DB.
As a result, other scripts should run slightly faster. For
instance, this saves about 80ms (2.710s => 2.630s) in t/mda.t
on my remote workstation.
While we're at it, make sure EvCleanup is properly require'd
in Daemon.pm and HTTP.pm and document our use of Devel::Peek.
|
|
The `shell' function appears missing, so we'll rely on Bourne
shell expansioN, instead.
Use "$?" instead of "$<" since the latter is only specified
for inference and .DEFAULT rules, not target rules.
Tested on FreeBSD make(1) and bmake(1) on Debian.
|
|
Email::MIME uses Encode::MIME::Header and depends on that
appropriately; however we depend on other parts of the Encode
distribution, but that's bundled with Perl by upstream, anyways;
and should place no additional burden on users.
|
|
Fortunately, there is a pattern to most of these package names
in all distros I've tested (and hopefully other BSDs have them,
too).
Then, reorder the INSTALL document to mention the top-level
modules, first, so users can avoid needing to type extra
dependencies. However, we still list some implicit dependencies
in case the upstream package drops dependencies independently of
us.
Finally, Devel::Peek is not a dependency worth making optional
since it's bundled by Perl upstream. Fedora/RH-based distros
are the only one which turn it into a non-standard package when
Perl5 is installed.
|
|
We don't need to increase our install footprint with
documentation from our internals (which will surely
change).
|
|
Since we now support more CSS classes for coloring,
give this feature more visibility.
|
|
They really shouldn't be... Also, it seems like eliminating IPC::Run
is not going to be worth the effort.
|
|
Otherwise, things do not work from a tarball distribution.
Reported-by: Leah Neukirchen <leah@vuxu.org>
https://public-inbox.org/meta/871sdfzy80.fsf@gmail.com/
|
|
Pre-release for v2 repository support. Thanks to
The Linux Foundation for supporting this work!
|
|
Might as well, this release is mostly to serve as a checkpoint
for the start of new development on v2 stuff mentioned in the
TODO.
|
|
Using update-copyrights from gnulib
While we're at it, use the SPDX identifier for AGPL-3.0+ to
ease mechanical processing.
|
|
Introduce our own SearchThread class for threading messages.
This should allow us to specialize and optimize away objects
in future commits.
|
|
And add a check-manifest target to the Makefile to
ensure we're up-to-date with git (but do not depend on
git).
|
|
We no longer depend on it for the core code, and tests
are optional for users. Hopefully this makes this
easier-to-install.
|
|
This removes the Email::Filter dependency as well as the
signature-breaking scrubber code. We now prefer to
reject unacceptable messages and grudgingly (and blindly)
mirror messages we're not the primary endpoint for.
|
|
We still pull it in via Email::LocalDelivery, but that
dependency will go away, soon.
|
|
Relying on the number of processors isn't a great idea
since some of our tests rely on delays to test blocking
and slow client behavior.
|
|
git has stricter requirements for ident names (no '<>')
which Email::Address allows.
Even in 1.908, Email::Address also has an incomplete fix for
CVE-2015-7686 with a DoS-able regexp for comments. Since we
don't care for or need all the RFC compliance of Email::Address,
avoiding it entirely may be preferable.
Email::Address will still be installed as a requirement for
Email::MIME, but it is only used by the
Email::MIME::header_str_set which we do not use
|
|
Unfortunately, most users still prefer their mail delivered
over SMTP; so we'll at least document mlmmj integration for now
until we can popularize pull-based reading over POP3/NNTP/ssoma.
|
|
This should help poor developers who still use rotating disks on
cheap netbooks.
|
|
While we're at it, update some references to ssoma in the
Makefile.PL comment.
|
|
Message-IDs should not be MIME encoded, but in case they are,
use the raw form for compatibility with ssoma and possibly
other tools. This prevents a potential problem where a
malicious client could confuse our storage layer into indexing
incorrect contents.
|
|
This seems to match more closely with what is expected of Perl
packages based on how blib is used. Hopefully makes the top-level
source tree less cluttered and things easier-to-find.
|
|
Relying on Plack::Handler::CGI is much easier for long-term
maintenance and development.
Nowadays, we even include our own httpd implementation to
facilitate easier deployment with PSGI/Plack.
|
|
In the future, it should be possible to use this:
git ls-files | UPDATE_COPYRIGHT_HOLDER='all contributors' \
UPDATE_COPYRIGHT_USE_INTERVALS=2 \
xargs /path/to/gnulib/build-aux/update-copyright
|
|
Not that we actually have a bare PublicInbox module, yet.
Maybe MID can be it.
|
|
This is necessary since Xapian may not be installed and
we may hide a lot of errors this way.
|
|
We will attempt to generate Atom feeds "by hand" as the
XML::Atom::SimpleFeed API does not support streaming output.
Since email is large and servers are small, this should prevent
wasting memory when we generate larger feeds.
Of course, we hope clients use SAX parsers capable of handling
large streams without slurping.
|
|
Threading in Xapian is mostly supported by now; so start
documenting things.
|
|
We need to make the indexer executable and installable
while we're at it.
|
|
This hopefully allows easier setup.
|
|
We have an HTML homepage, OMG!
|
|
This makes it easier to configure for systems which
determine a script is a CGI script based on suffix.
|
|
This is essential for integrating into my inotify-based
spam training setup.
|
|
We may occasionally encounter horrid HTML which lynx cannot
handle, so improve error reporting.
|
|
While we're at it, sort Makefile.PL and add a note to
update INSTALL, too.
|
|
These tests were designed to run in parallel.
|
|
Using JWZ threading might work decently for this.
Haven't checked in lynx, yet.
|
|
Most notably, the INSTALL is geared towards potential server admins,
whereas the README is also for interested "drive-by" readers.
|
|
This is lightly tested.
|
|
We should be able to wire up the rest, soon.
|
|
SpamAssassin doesn't seem to have this heuristic, but the lack of
the intended email address in To:/Cc: headers cannot be a good
sign (especially when this is a _public_ inbox).
|
|
|
|
|