Date | Commit message (Collapse) |
|
|
|
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
|
|
Hopefully more folks can download and run public-inbox,
nowadays.
|
|
This will be important as we will have more of them.
|
|
This will allow reasonable titles to be generated for
manpages.
|
|
Since this is bundled with the source, we might as well use
internal APIs to avoid having duplicate code (and bugs :P)
|
|
We want the pod2man(1) executable for handling certain
options. Also, use the correct year while we're at it :P
|
|
This makes us closer to git.git style (though I'm not quite sure
why we do this...)
|
|
We use perlpod nowadays since it's Perl, like our code base.
|
|
Also, at least add one of the Tor mirrors (the rest will
be discoverable through the mirrors themselves).
|
|
This means we can still show non-git users a somewhat browseable
URL with a link to the README.html file while allowing git users
to type less when cloning.
All of the following are supported:
git clone https://public-inbox.org/ public-inbox
git clone https://public-inbox.org/public-inbox
git clone https://public-inbox.org/public-inbox.git
torsocks git clone http://ou63pmih66umazou.onion/public-inbox
|
|
Might as well eat our own dogfood...
|
|
It would be too much of a burden for caching system when
user-supplied CSS is more powerful.
|
|
Followup-to: 1365e185d817cdc2de04968c37f597d92226a13b
("view: inline message reply into message view")
|
|
It's no longer a part of the stock Perl distribution,
and we don't need a whole module for just one function.
|
|
A public-inbox is NOT necessarily a mailing list, but it
could serve as an input point for zero, one, or infinite
mailing lists :D
|
|
This is probably trivial enough to be final?
|
|
By converting to using ourt git-fast-import-based Import
module. This should allow us to be more easily installed.
|
|
Quote-folding was a major design mistake pre-1.0. Since this
project is still in its infancy and unlikely to be in wide
use at the moment, redirect the /f/ endpoints back to the
plain message.
|
|
Start documenting our anchors and CSS classes for in case users
want to write their own CSS or even JavaScript for local usage.
|
|
Quote-folding can be detrimental as it fails to hide the
real problem of over-quoting.
Over-quoting wastes bandwidth and space for all readers, not
just WWW readers of the public-inbox. So hopefully removing
quote-folding support from the WWW interface can shame those
repliers into quoting only relevant portions of what they reply
to.
|
|
We need manpages before we can expect people to install this.
|
|
Be less specific, client-side code can be written in any
language (and I do not care for JS runtimes implemented in
C++ :P).
|
|
Letz trie 2 uphear liter8
|