| Date | Commit message (Collapse) |
|---|
|
This is true as of e220b8b2ee5cfd458167dc2c6c92726352c4c80e
("Merge remote-tracking branch 'origin/xap-optional' into master")
|
|
I don't have time to check and train spam for all these
projects.
Spam filtering is especially difficult on ruby-core: it
enters via Redmine, so it doesn't have a distinct Received:
chain, and also gets mixed with non-spam bug-report text,
throwing off Bayes training.
And I'm not sure if those mirrors did anybody any good, even;
so lets not say its' a "service" to anybody :P
The actual mirrors remain up, for now, but who knows...
I care about decentralization too much to ask anybody
to trust me to keep anything up :P
|
|
Since we go through the effort of hosting these manpages,
link to them.
|
|
In particular, the '--compact' switch is really useful since it
works without holding the inbox-wide lock for minutes at a time
on giant inboxes (inboxes where copies can take dozens, if not
hundreds of minutes).
|
|
They're nowhere to be found on Xapian.org, and links to
external services are either too long (for manpages.debian.org)
or have privacy-invasive tracking JS on them.
|
|
Otherwise timestamps for .html files get screwed up, too;
and that hurts caching.
|
|
It's not critical, but it's nice to have for cache-friendliness
(otherwise I would not have written it :P)
I guess I should follow up on getting it into 'git contrib/':
https://public-inbox.org/git/20100702033709.GA6818@burratino/
|
|
The nginx manpage is in section 8.
|
|
Oops :x
|
|
-index documentation avoid redundant v1 information and refers
readers to apropriate v1/v2 manpages. Search::Xapian can also
be optional, now, as only the PSGI search interface uses it.
Favor "INBOX_DIR" where appropriate, since "REPO_DIR" can be
confused for code repos which we also support.
XAPIAN_FLUSH_THRESHOLD is documented for all relevant
bulk commands.
|
|
It is no longer a wrapper around copydatabase(1), since
copydatabase did not recover from DatabaseModifiedError.
|
|
copydatabase(1) is an existing Xapian tool which is the
recommended way to upgrade existing DBs to the latest Xapian
database format (currently "glass" for stable/released
versions). Our use of Xapian relies on preserving document IDs,
so we'll wrap it like we do xapian-compact(1) and use the
"--no-renumber" switch.
I could not name the tool "public-inbox-copydatabase" since it
would be ambiguous as to which DB it's actually copying. So, I
abbreviated the suffix to "xcpdb" (Xapian CoPy DataBase), which
I hope is acceptable and unambiguous.
|
|
We're going to need copydatabase, too
|
|
Preventative measures; since marketing is almost always annoying
to me. And trying to avoid unintended consequences.
|
|
And document that we still have GNU-isms in that
include.mk Makefile (and may continue to do so).
Finally, take advantage of GNU-isms to warn users
to run "gmake" to build all manpages.
|
|
We can fix the redundant rule in include.mk which causes
make(1) on FreeBSD to complain; but HTML docs will likely
still require GNU make.
|
|
Otherwise, pod2man complains about "=item 404" not starting
with a letter and thinking it's part of a numbered list.
|
|
* origin/wwwlisting:
www: support listing of inboxes
start depending on Perl 5.10.1+
|
|
|
|
Document `publicinbox.cgitdata' config directive, but allow it
to be unspecified and/or missing for installations which do not
wish to serve static data at all.
For users installing cgit from source to their home directory,
we can usually infer the cgit data path based on the cgit.cgi
binary path, even.
|
|
Incomplete at the moment, but this ought to be a handy reference
for both implementers and users alike.
|
|
We will still return a 404 by default to '/' for compatibility
with users of Plack::App::Cascade or similar. Inboxes are
sorted by modification times to help users detect activity
(similar to the /$INBOX/ topic view).
New configuration options:
* publicinbox.wwwlisting - configure the listing type
* publicinbox.<name>.hide - hide a particular inbox from the listing
See changes to public-inbox-config.pod for full descriptions
of the new options.
Requested-by: Leah Neukirchen <leah@vuxu.org>
https://public-inbox.org/meta/871sdfzy80.fsf@gmail.com/
|
|
|
|
We account for the upstream default location as well as
the Debian-installed one.
|
|
|
|
I mainly need this to enforce RLIMIT_CPU (and RLIMIT_CORE)
when requests come which generate giant, unrealistic diffs.
Per-coderepo limiters may be added in the future. But for now,
I need to prevent cgit from monopolizing resources on my dinky
server.
|
|
This allows users to configure RLIMIT_{CORE,CPU,DATA} using
our "limiter" config directive when spawning external processes.
|
|
Requests intended for cgit are unlikely to conflict with
requests to inboxes. So we can safely hand those requests
off to cgit.cgi.
|
|
We can save admins the trouble of declaring [coderepo "..."]
sections in the public-inbox config by parsing the cgitrc
directly.
Macro expansion (e.g. $HTTP_HOST) expansion is not supported,
yet; but may be in the future.
|
|
diffstat <-> ^diff anchors work within the same attachment or
message while in HTML views which display multiple messages.
|
|
I hate it, but it's necessary to support some mirrors.
|
|
I've relied on this feature to keep the VPS behind
https://public-inbox.org/git/ from OOM-ing since 2016,
so document it to ensure others can make use of low-end
servers like I do.
More limiters may become configurable for viewvcs and
solver functionality (or we continue using the default
one).
|
|
New features ought to be documented
|
|
Since we now support more CSS classes for coloring,
give this feature more visibility.
|
|
Remove confusing documentation around ssoma now that we
have NNTP and downloadable mbox support.
Only lightly-checked for grammar and speling, and not yet
formatting. Edits, corrections and addendums expected :>
|
|
These have existed for a while, actually, so, we might as well
publicize them. While we're at it, add a disclaimer to
discourage reliance on single points of failure.
|
|
This reuses some of the configuration from -watch, but remains
independent since some configurations will use -watch for some
inboxes and -mda for others.
The default remains "spamc" for -mda users so nothing changes
without explicit configuration.
Per-inbox configurations may also be supported in the future.
|
|
Having multiple Xapian partitions is mostly pointless after
the initial import. We can compact all the partitions into
one while keeping the skeleton separate.
|
|
This should make it easier to let users perform comparisons and
migrate to v2 if needed.
|
|
No functional changes, yet, but this makes future changes
easier-to-read.
|
|
Using update-copyrights from gnulib
While we're at it, use the SPDX identifier for AGPL-3.0+ to
ease mechanical processing.
|
|
I still hate that CSS is over-used, but colors are useful
and perhaps using them for highlighting won't be too bad;
but user-supplied colors will ALWAYS be supported.
|
|
It seems Xapian is not prepared for Japanese, unfortunately.
https://public-inbox.org/meta/20170702213657.GA5312@dcvr/
|
|
This will hopefully increase visibility of some archives.
|
|
If a message is spam in one mailbox, it is spam in all others a
particular user/group will care about.
|
|
ssoma is not worth marketing, but perhaps our mirror of
the git mailing list archives is...
|
|
This allows users to customize by using smaller or larger Atom
feeds than the default value of 25 entries.
|
|
We have these manpages, and will always have them, so stop
trying to pretend we're doing something about maintainability,
here.
|
|
For now, we will document this since it allows better
performance without the burden of extensions. Perhaps one day
far in the future Perl can natively support vfork(2) AND that
version of Perl will be widely available, but I suspect that day
is at least a decade away, if not two:
https://rt.perl.org/Ticket/Display.html?id=128227
|
|
And include it into the build + website
|