Date | Commit message (Collapse) |
|
'$inbox' is more human-readable, so that is for the more
human-readable name in most cases. Making our variable naming
more consistent should make the code easier-to-review and
harder to screw up.
|
|
We access the Git object via the Inbox object nowadays, so
there's no point in having a shortcut to it, anymore.
|
|
We parse cgitrc for "repo.path", while we use "coderepo.dir" to
mean the same thing for non-cgit users. So I ended up confusing
myself, here.
But then again, git uses "--git-dir" and "GIT_DIR", so I suspect
"dir" is the better choice than "path", here
|
|
We'll be building off of this for showing diffs in
the coderepo views.
|
|
Hopefully this gets us closer to matching cgit upstream behavior
(which also lacks tests). We'll still need to support macro
expansion at some point for compatibility...
|
|
We can reduce the configuration needed to run cgit by reusing
the static file handling logic of the dumb git HTTP protocol.
I hate logos and icons, so don't expect public-inbox.org or
80x24.org to ever have those to waste users' bandwidth with :P
But I expect other users to find this useful.
|
|
project_list support still needs to be done
And tests need to be written... :<
|
|
We need to instate our cgit handler everywhere we use NewsWWW
to catch wildcard requests which our normal endpoints do not
handle.
|
|
Our high-level config already treats single limits as a
soft==hard limit for limiters; so stop handling that redundant
in the low-level spawn() sub.
|
|
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 depend on git-http-backend for smart HTTP clone support,
however; since cgit does not support smart clones natively.
WWW.pm will be able to cascade down to this as a 404 handler in
the future.
|
|
cgit (and most other CGI executables) is not typically installed
for use via $PATH, so we'll need to support absolute paths to
run it.
|
|
Reads to git-http-backend(1) could fail or EOF prematurely,
so we must be ready for that case.
Furthermore, cgit (and possibly other CGI) uses LF instead
of CRLF, so support those programs, too.
|
|
This will be useful for other CGI wrappers we make.
This also fixes a bug with some PSGI servers which did not
present a real IO::Handle in the psgi.input env field.
|
|
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.
|
|
We'll be spawning cgit and git-diff, which can take gigantic
amounts of CPU time and/or heap given the right (ermm... wrong)
input. Limit the damage that large/expensive diffs can cause.
|
|
No need to scan the entire string, but prefer to match git
behavior. This might be faster if/when Perl can create
substrings efficiently using CoW.
Fix a 80-column violation while we're at it.
|
|
Eventually, we'll have special displays for various git objects
(commit, tree, tag). But for now, we'll just use git-show
to spew whatever comes from git.
|
|
This will be useful for extracting titles/subjects from
commit objects when displaying commits.
|
|
This will be useful for reproducibility when mirroring
coderepos and generating diffs.
|
|
Not entirely sure what is causing this, but it appears to
be causing infinite loops when attempting to display certain
blobs.
Fortunately, the fair scheduling of public-inbox-httpd prevented
this from becoming a real problem aside from increasing CPU
usage.
|
|
There's no reason for us to have git-config(1) warn users when a
config file is entirely missing.
|
|
Newly-cloned epochs need to be in alternates file of
all.git for the web and NNTP interfaces to work. So
allow invocations of "public-inbox-index" to idempotently
ensure the epoch is visible from the all.git repo.
|
|
We'll be using this sub to fill $GIT_DIR/objects/info/alternates
if somebody uses clone --mirror, too
|
|
All of our internal epoch rollover calculations are done using
the estimated unpacked (and uncompressed) size of the repo. The
importer instance needs to check that unpacked size before
selecting an epoch when an epoch already has packed data.
This bug did not impact the initial mass imports since we only
initialize the Import instance once-per-epoch and did not need
to take existing epochs into account.
Tested manually with -mda on a local clone of LKML
Reported-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
CSS specified by the BOFH must never take precedence over
what a user sets in userContent.css.
|
|
The sample userContent.css needs a higher priority than what
the BOFH specifies. In other words, user preference must
ALWAYS take precedence.
Reported-by: Dmitry Alexandrov <321942@gmail.com>
cf. https://public-inbox.org/meta/87mumn4kx8.fsf@gmail.com/
|
|
We were relying on Danga::Socket using the "bytes" pragma,
previously. Nowadays, the "bytes" pragma is not recommended in
general, but bytes::length remains acceptable for getting the
byte-size of a scalar.
|
|
Unused since commit b8c41362f2a5c8fcc6b1846a79c72bfa77565297
("nntp: simplify the long_response API")
|
|
Don't bother assigning to $_[1]; just let Danga::Socket
do its thing since $_[1] should be out-of-scope soon.
|
|
Users on Perl 5.14+ are common, so we can try the bundled Socket
(not "Socket6") module before attempting Socket6 for IPv6.
|
|
We need to keep Unix-socket-only httpd instances working
without Socket6. This fixes t/httpd-unix.t with Socket6
uninstalled.
|
|
* origin/help-color:
wwwtext: inline sample CSS and use highlight
hlmod: support "```$LANG" blocks in text
hlmod: do_hl* performs src_escape immediately
hlmod: make into a singleton
hlmod: hoist out do_hl_lang sub
viewvcs: cleanup utf8 handling
|
|
This can help admins diagnose problems with SolverGit, since
qspawn logs the failed "git apply" command-line in stderr.
(or it can waste admins' time because sometimes there's crap
mail clients which mangle patches)
|
|
For user documentation regarding CSS; showing users the sample
CSS with comments is probably more helpful than having
standalone documentation on CSS classes.
|
|
This is compatible with Markdown; but we still keep the WYSIWYG
nature of plain-text with this. This is only intended for use
with our documentation. Enabling any type of Markdown support
for emails can lead to incompatibilities or interopability
problems with alternative implementations.
|
|
We want to be able to take advantage of this in other modules
|
|
It turns out there's no point in having multiple instances of
this or having to worry about destruction or destruction
ordering.
This will make it easier to reuse the one instance we have
across different modules.
|
|
We'll want to use to support highlighting syntax used by
Markdown and possibly other markup languages (while retaining
the raw plain-text layout and formatting).
|
|
Favor in-place utf8::decode since it's a bit faster without
method dispatch overhead; and don't care about validity just
yet.
HlMod->do_hl itself should return "utf8" strings, since other
parts of our code can use it, so it's not the job of ViewVCS to
post-process HlMod output.
|
|
Leaving out parentheses caused transitions to state="del" or
state="add" to be misidentified.
cf. https://public-inbox.org/meta/20190204105454.GG10587@szeder.dev/
Reported-by: SZEDER Gábor <szeder.dev@gmail.com>
|
|
This is the fallback for the normal WWW endpoint.
Adding this to the top-level seems to be alright, since lynx and
w3m both understand nntp://<HOSTNAME>/<Message-ID> anyways.
If newsgroup and inbox names conflict, then consider it the
fault of the original sender.
Since NewsWWW is intended to support buggy linkifiers in mail clients,
they can interpret nntp:// URLs as http://<HOSTNAME>/<Message-ID>
Inbox ordering from the config file is preserved since
commit cfa8ff7c256e20f3240aed5f98d155c019788e3b
("config: each_inbox iteration preserves config order"),
so admins can rely on that to configure how scanning
works.
Requested-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
cf. https://public-inbox.org/meta/20190107190719.GE9442@pure.paranoia.local/
nntp://news.public-inbox.org/20190107190719.GE9442@pure.paranoia.local
|
|
This is best-effort, but works well-enough in practice for
projects which use shell-friendly filenames as well as the
long path names for some Linux kernel selftests.
|
|
For URLs we generate, we need to escape '&' in query parameters
for correctness.
|
|
Only to be pedantic...
|
|
Sometimes users will write "http://example.com" without the
trailing slash, which every browser and tool I've tested seems
to understand.
|
|
Perl "split" can capture and group in the regexp itself,
so rely on that to shorten our code.
Comparing the /T/ HTML output of a thread from hell (on LKML with
1356 messages) reveals no difference in the rendered result.
Only the HTML source differs in newline placement before/after
the closing </span>
This allows a minor speedup on my X32 Thinkpad @ 1.6GHz with
the aforementioned LKML thread from hell:
before: 3.67s
after: 3.55s
|
|
We use absolute URLs in the Atom feeds (to ease
syndication/mirroring), so hunk headers need to point to the
solver URLs.
|