Date | Commit message (Collapse) |
|
|
|
It was never documented, before.
|
|
For consistency with Xapian documentation (in the "master"
branch).
|
|
* origin/reshard:
xcpdb: support resharding v2 repos
xcpdb: use destination shard as progress prefix
xapcmd: preserve indexlevel based on the destination
v2writable: use a smaller default for Xapian partitions
|
|
* origin/edit:
edit: unlink temporary file when done
v2writable: replace: kill git processes before reindexing
edit: drop unwanted headers before noop check
edit|purge: improve output on rewrites
edit: new tool to perform edits
doc: document the --prune option for -index
admin: expose ->config
AdminEdit: move editability checks from -purge
admin: beef up resolve_inboxes to handle purge options
purge: start moving common options to AdminEdit module
admin: remove warning arg for unconfigured inboxes
v2writable: implement ->replace call
import: switch to "replace_oids" interface for purge
import: extract_author_info becomes extract_commit_info
v2writable: consolidate overview and indexing call
|
|
v2 repos are sometimes created on machines where CPU
parallelization exceeds the capability of the storage devices.
In that case, users may reshard the Xapian DB to any smaller,
positive integer to avoid excessive overhead and contention when
bottlenecked by slow storage.
Resharding can also be used to increase shard count after
hardware upgrades.
|
|
|
|
It's been written for over a year, but I forgot to include
it in the build so it did not get installed or put on the site.
|
|
|
|
This wrapper around V2Writable->replace provides a user-interface
for editing messages as single-message mboxes (or the raw text
via $EDITOR).
|
|
We've had it around for a while, but I forgot to document it :x
|
|
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.
|