Age | Commit message (Collapse) | Author |
|
There is still a weird mix between what's in migrations and what's in
schema.sql, but at least they should try to be mostly in sync.
Author: Jelte Fennema-Nio <github-tech@jeltef.nl>
|
|
Without this you would get an error like this:
Failed to parse mbox:
b'/bin/sh: 1: Syntax error: "(" unexpected\n'
This especially matters when loading files downloaded with a browser,
since those often contain (1) or (2) if a file with the same name was
downloaded earlier.
|
|
|
|
|
|
This was broken in the python 2->3 migration, but is apparently an
uncommon enough case that it wasn't properly spotted until now.
Reported and pointers in the right direction from Andres Freund
|
|
This has a default=False set in the django model, but django does not
propagate that into the database which would cause the insert of new
lists to fail with a not-null-violation.
Spotted by Célestin Matte
|
|
This section is expected by pglister_sync.py but missing from the sample file
|
|
Spotted by Célestin Matte
|
|
Back in 2018, commit 4d159ca accidentally included unrelated
functionality which was not completed. This causes the database to be
out of sync with the models defined in the code.
This commit reverts those parts that were not supposed to be included
and leaves the changes that actually were. The code can be re-added once
completed...
Spotted by Célestin Matte
|
|
|
|
|
|
Previously overwriting was only allowed from reparse_messages.py, in
which case it would only reparse the existing message. For the usecase
of overwriting the raw contents and then also reparsing the result, the
--overwrite switch can now be passed to load_messages.py.
|
|
|
|
Timeout error is better than hanging forever. Set a timeout for 30
seconds which is with a big margin longer than should ever be needed.
|
|
Broken in python3 migration, shows how often we have load errors these
days.
|
|
|
|
|
|
|
|
|
|
This allows a logged-in user to get an email delivered to their mailbox,
thereby making it easy to reply to even if they haven't got it already
(and don't have a MUA capable of handling mbox files).
The email body will go out unmodified (including any list headers that
are stored in the archives, but this does not include for example the
unsubscribe link). Envelope sender is set to one configured in the ini
file, and envelope recipient is set to the email address of the user.
|
|
|
|
Empty arrays otherwise have no types in PostgreSQL, which would cause an
error.
|
|
In particular, if parsing the date either fails or if it results in a
date that's in the future, fall back to parsing the dates out of the
Received: headers instead, because at some point there we will find a
parsable date for sure (if not before then when it hit one of our own
servers)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Per pep8 warnings, adjust indentation for consistency
|
|
pep8 standard for indentation
|
|
For some really broken messages, we end up in a cannot-happen codepath.
Trap this one and just consider that MIME part empty, and try again
later.
In passing, also change it so we continue loading after failures of parsing.
We continued in the mode where we just generated diffs, but not when
making updates. Now continue in both cases, but of course don't do the
actual update if the parsing failed.
|
|
Some minor cleanups as well, but mostly just the output of the 2to3 tool
and some manual changes.
|
|
has_key() has been deprecated for a while and will be gone in Python3.
The in syntax is available in both the old and the new versions.
|
|
|
|
tidylib (http://countergram.github.io/pytidylib/) is maintained,
the old tidy one (https://cihar.com/software/utidylib/) is not. And in
particular, python3 support is in the new one.
Generates some minor changs in the existing archives, but it seems to be
just whitespace and some actual incorrectness in the old output.
|
|
Avoid loading two messages at the same time. In particular this can
cause issues if it's two copies of the same message on different lists,
which can cause a UNIQUE violation in the loader. It could also be a
problem if two messages on a new thread arrives in parallel, which could
cause two separate threads to be created.
This could be made more efficient by properly ordering the operations on
storage and using ON CONFLICT, but it's a very rare occassion and it
doesn't matter that we have to wait for a second or two for a previous
storage to complete.
|
|
They shouldn't be there in the first place. Sigh. But if they're there
just pretend they don't exist, so we get a working messageid.
|
|
|
|
That commit was backwards. Oops.
|
|
|
|
|
|
|
|
Previously, only the body changes would show up in the diff, but we'd
actually make updates on the headers as well.
|
|
|
|
|
|
|
|
|
|
Created a *lot* of unnecessary I/O
|
|
|