Date | Commit message (Collapse) |
|
|
|
Since MANIFEST is tied to files tracked by git, adding generated
files such as NEWS to that is more effort than its worth (esp.
when I'm wondering if MakeMaker is useful compared to only using
GNU make).
I also have trouble reading CamelCase, so lower-case names
are nicer and more consistent with previous releases
(which were all generated with "git archive"); but did not
include NEWS.
|
|
We'll have non-7-bit ASCII in the 1.2.0 release notes.
|
|
That's the only head-scratcher of the bunch remaining, since
that relies on ranges.
|
|
Yet another case of documenting things which should NOT be used :>
|
|
Tools intended for end users need manpages, and doubly so
to convince potential users NOT to use them :)
|
|
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.
|
|
"#ff0" foreground on a "#fff" background is just too difficult
to distinguish, among other things. So choose slightly darker
colors when using a (painful) "#fff" background.
|
|
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
|
|
Tools intended for end users need manpages.
|
|
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/
|
|
Multiple List-ID headers will be supported in the next commit
|
|
And use it for mda, since "0" could be a usable directory
if somebody insists on using relative paths...
|
|
We don't want to waste cycles parsing the message for MIME bits
if it's spam.
|
|
It makes it easier to document the default -mda behavior is
stricter than normal, including "public-inbox-learn ham"
|
|
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.
|
|
We'll be reusing it for List-ID processing in the next commit.
|
|
Users may be zeroes or blanks.
|
|
Use <foo|bar> since that seems to be the favored notation
for required command args (taking a hint from git(1) manpage).
While we're at it, remove the space after '<' for the redirect
to match git.git coding style.
|
|
It's assumed that "spam" can end up anywhere due to Bcc:, so we
need to scan every single inbox. However, "rm" is usually more
targeted and and "ham" obviously only belongs in some inboxes.
|
|
It's possible to specify these headers multiple times, and
PublicInbox::MDA->precheck takes that into account, so
-learn should, too.
|
|
* origin/multi-mid:
view: show X-Alt-Message-ID in permalink view, too
index: allow search/lookups on X-Alt-Message-ID
linkify: support adding "(raw)" link for Message-IDs
view: improve warning for multiple Message-IDs
view: move '<' and '>' outside <a>
view: display redundant headers in permalink
search: support multiple From/To/Cc/Subject headers
|
|
Bad things happen when user data can control our stack size.
|
|
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 need to remove all the generated documentation files
before running "git-set-file-times" for rsync to our
website.
|
|
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.
|