Date | Commit message (Collapse) |
|
While testing 216light.css changes, I managed to hit some cases
where dillo failed to render ' correctly, but I also can't
reproduce it reliably. Anyways, it's definitely a problem with
some old browsers and newer versions of highlight already work
around it, but Debian 10.x has 3.41, so use "'" to maximize
compatibility.
|
|
We need to detect "git apply" failures reliably when patches
fail. This is necessary for solving for blob 81c1164ae5 in
https://public-inbox.org/git/ when at least two messages can
solve for it (and one of them fails):
1. https://public-inbox.org/git/b9fb52b8-8168-6bf0-9a72-1e6c44a281a5@oracle.com/
2. https://public-inbox.org/git/56664222-6c29-09dc-ef78-7b380b113c4a@oracle.com/
|
|
When solving for blob 81c1164ae5 in https://public-inbox.org/git/,
at least two messages get indexed with the dfpost result for
that blob (after fixing MsgIter to decode all text/* parts):
1. https://public-inbox.org/git/b9fb52b8-8168-6bf0-9a72-1e6c44a281a5@oracle.com/
2. https://public-inbox.org/git/56664222-6c29-09dc-ef78-7b380b113c4a@oracle.com/
However, only the first message contains a usable patch. So
we must adjust SolverGit to account for multiple messages
hitting the same "dfpost:" search result and attempt
"git apply" on all results, not just the first.
In the future, changes to SearchIdx.pm may rid us of invalid
search results and speed up performance (at the expense of
developer/indexing time); but we need to account for old search
indices, first.
|
|
We want to index text/x-patch and text/x-diff, at least,
since "git format-patch" can generate a patch series as
attachments using --attach.
|
|
ISO-2202-JP and other non-UTF-8 messages need to be displayed
correctly.
Fixes: 7d82a8bc04ce ('handle "multipart/mixed" messages which are not multipart')
|
|
--reindex has gotten better over the years, and having parallel
Xapian DB directories would exceed all available disk space for
some users with giant inboxes.
|
|
Spell "Schwartzian" correctly, and clarify the location of
"modified" since we have multiple subs named "modified"
|
|
* learn:
doc: add public-inbox-learn(1) manpage
mda: support multiple List-ID matches
mda: prepare for multiple destinations
inboxwritable: add assert_usable_dir sub
mda: skip MIME parsing if spam
mda: hoist out mda_filter_adjust
filter/base: remove MAX_MID_SIZE constant
mda: hoist out List-ID handling and reuse in -learn
learn: hoist out remove_or_add subroutine
learn: GIT_COMMITTER_<NAME|EMAIL> may be "" or "0"
learn: update usage statement
learn: only map recipient list on "ham" or "rm"
learn: support multiple To/Cc headers
|
|
While it's not RFC2919-conformant, mail software can
theoretically set multiple List-ID headers. Deliver to all
inboxes which match a given List-ID since that's likely the
intended.
Cc: Eric W. Biederman <ebiederm@xmission.com>
Link: https://public-inbox.org/meta/87pniltscf.fsf@x220.int.ebiederm.org/
|
|
And use it for mda, since "0" could be a usable directory
if somebody insists on using relative paths...
|
|
We don't need it in the filter, here, since we have
one in the MDA package.
|
|
It's now possible to inject false-positive ham into an inbox
the same way -mda does via List-ID.
|
|
Since we index X-Alt-Message-ID (because we need to placate some
NNTP clients), we now display it as well, since that Message-ID
could be the X-Alt-Message-ID that the reader is actually
interested in.
|
|
Since we replace extra Message-ID headers with X-Alt-Message-ID
to placate NNTP clients, we should allow searching and indexing
on X-Alt-Message-ID just like we do with Message-ID.
|
|
And use it for the per-message permalink display.
|
|
"refer" is not the correct term, here; since that would mean
multiple messages have the current message in the "References:"
header, and that's a normal occurence.
Instead, we need to warn the reader that the given message
itself has multiple Message-IDs.
|
|
Browsers may underline '<' and '>' in links, which may be
confused with '≤' and '≥'. So have the Message-ID header
display follow what we do with In-Reply-To headers and move the
"<" and ">" outside of <a> in the HTML.
|
|
Mail headers can contain multiple headers of any type, so ensure
we don't hide any information we're getting in the per-message
permalink views.
This means it's possible to have multiple From, Date, To, Cc,
Subject, and In-Reply-To headers displayed.
The thread indices are a special case, I guess, since we run
out of space on the line if the headers too long and tools like
mutt only show the first one.
|
|
We can easily support searching on messages with
multiple From/To/Cc/Subject headers just like we
do with multiple Message-ID headers.
This matches the normal mutt pager display behavior.
|
|
* regen:
v2writable: use msgmap as multi_mid queue
v2writable: move git->cleanup to the correct place
v2writable: reindex handles 3-headered monsters
v2writable: improve "num_for" API and disambiguate
v2writable: set unindexed article number
|
|
I'm not sure they'll make a measurable difference or will
be worth the effort in the future given the prevalance
of HTTPS and giant socket buffers.
Using Inline::C for this may make more sense in the
future, too, especially if we want to be able to use
GnuTLS.
|
|
commit 476fc666c223f0fb ('reduce "PublicInbox::Hval->new_oneline" use')
was mis-titled, since it completely eliminated ->new_oneline use.
|
|
This was intended for solver, but it's unused since
commit 915cd090798069a4
("solver: switch patch application to use a callback")
|
|
InboxWritable::maildir_path_load exists and we may support
it for use with standalone scripts.
|
|
I'm not sure if this will get used anywhere, but at least
call a function which exists in dead code.
|
|
This hasn't been used since commit 48b21cb662c1e17b7 in 2016:
("declare Inbox object for reusability")
|
|
This hasn't been used since commit 1b7e935ab1690e28
("searchidx: fix incremental index with indexlevel=basic on v1")
|
|
Instead of storing Message-IDs in the Msgmap object, we can
store the blob OID.
For initial indexing of mirrors, this lets us preserve
$sync->{regen} by storing the intended article number in
the queue.
On --reindex, the article number we store in Msgmap is ignored
but only used for ordering purposes.
This also allows us to avoid ENOMEM errors if somebody abuses
our system by reusing Message-IDs; but we now risk ENOSPC
instead (but systems tend to have more FS storage than RAM).
|
|
We need to stop the git process to avoid leaking FDs
to Xapian if we recurse ->index_sync on reindex.
|
|
And maybe 8-headered ones, too...
I noticed --reindex failing on the linux-renesas-soc mirror due
one 3-headed monster of a message having 3 sets of headers;
while another normal message had a Message-ID that matched one
of the 3 IDs of the 3-headed monster.
We still try to do the majority of indexing backwards, but we
defer indexing multi-Message-ID'd messages until the end to
ensure we get all the "good" messages in before we process the
multi-headered ones.
Link: https://public-inbox.org/meta/20191016211415.GA6084@dcvr/
|
|
Make it obvious that we're not the Msgmap sub and return an
array because it's less awkward than providing a modifiable ref
to a function to write to.
|
|
We'll actually use the keys of this hash in future commits.
|
|
* origin/inboxdir:
config: remove redundant inboxdir check
config: support "inboxdir" in addition to "mainrepo"
examples/grok-pull.post_update_hook: use "inbox_dir"
|
|
While it is possible to host source code from the root of a URL
using git-http-backend(1), the lack of pathname in the URL can
also be confusing to users. So just add the path name of the
project into the URL itself so users can invoke "git clone"
with one command-line argument instead of two.
Of course, previously documented URLs continue to work as normal.
|
|
This was causing compatibility problems for old configs
when using public-inbox-nntpd.
|
|
"mainrepo" ws a bad name and artifact from the early days when I
intended for there to be a "spamrepo" (now just the
ENV{PI_EMERGENCY} Maildir). With v2, "mainrepo" can be
especially confusing, since v2 needs at least two git
repositories (epoch + all.git) to function and we shouldn't
confuse users by having them point to a git repository for v2.
Much of our documentation already references "INBOX_DIR" for
command-line arguments, so use "inboxdir" as the
git-config(1)-friendly variant for that.
"mainrepo" remains supported indefinitely for compatibility.
Users may need to revert to old versions, or may be referring
to old documentation and must not be forced to change config
files to account for this change.
So if you're using "mainrepo" today, I do NOT recommend changing
it right away because other bugs can lurk.
Link: https://public-inbox.org/meta/874l0ice8v.fsf@alyssa.is/
|
|
* listid:
wwwtext: show listid config directive(s)
mda, watch: wire up List-ID header support
config: allow "0" as a valid mainrepo path
config: avoid unnecessary '||' use
config: simplify lookup* methods
config: we always have {-section_order}
Config.pm: Add support for mailing list information
|
|
Since public-inbox-index may be run against a large list of
(intended) inboxes from the command-line, it's helpful to show
which directory fails the resolution.
|
|
We want to share this piece for potential mirror-ers just
like watchheader.
|
|
This also adds watchheader tests for -watch, which we never
had before :x
|
|
It's probably wrong to use relative path names, but things are
all relative these days anyways with shared and networked FSes.
|
|
'//' is available in Perl 5.10+ which allows `0' and `""' (empty
string) to remain unclobbered.
We also don't need '||=' for initializing our internal caches.
|
|
This ensures we always process inboxes in section order and
reduces the amount of code we have to maintain for each lookup.
Avoiding the cost of inboxes object creation is not worth the
code overhead; and we can implement a config cache via Storable
easily for large configs and -mda users.
|
|
Rewrite a bunch of tests to use ordered input (emulating
"git config -l" output) so we can always walk sections in
the order they were given in the config file.
|
|
The world has turned since I first started following mailing lists and
to my surprise every mailing list that I am subscribed to properly
sets the "List-ID:" mailing list header. So instead of doing
something clever and flexible I am adding support for looking up
public inbox mailing lists by their mailing list name.
That makes the work needed for each email trivial and easy to understand.
- Parse the "List-ID:" header.
- Lookup in the configuration which mailbox is connected to that
"List-ID:"
- Deliver the mail to that mailbox.
To that end this change enhances PublicInbox to have an additional
mailbox configuration parameter "listid" that holds the mailing list
name.
A method is added to the PublicInbox config object called
lookup_list_id that given a mailing list name will return the
PublicInbox in the configuration that is configured to handle that
mailing list.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
[ew: avoid autovivification of $ibx->{listid} for t/config.t]
|
|
I don't trust the MIME type to not munge my email messages in horrible
ways upon occasion. Therefore allow for passing in the raw message
value instead of trusting the mime object to preserve it.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
[ew: use "//" from Perl 5.10+ for defined check]
|
|
This is a plugin for SpamAssassin that happens to be quite
useful in keeping spam off lists I mirror. Hopefully more
people can find it useful now that it has a manpage.
|
|
We rely on Inbox::mm nowadays.
|
|
We need to warn when hitting file or socket memory limits
or misconfigurations which clear O_NONBLOCK to make it easier
to diagnose configuration problems. We'll also warn on
some other errors in case bugs creep in...
|
|
While we avoid generating absolute URLs in most cases, our
"git clone" instructions and URL headers in mboxrd files
contain full URLs.
So do the same thing we do for WwwAtomStream and pre-generate
the full URL before Plack::App::URLMap changes $env->{PATH_INFO}
and $env->{SCRIPT_NAME} back to their original values.
Reported-by: edef <edef@edef.eu>
Link: https://public-inbox.org/meta/cover.0f97c47bb88db8b875be7497289d8fedd3b11991.1569296942.git-series.edef@edef.eu/
|