Eric Wong writes:
> While MTAs seem to stop '\0' from appearing in headers, users
> fetching archives via git remain susceptible to having '\0' land
> in archives. So we'll filter them out of Xapian and SQLite DBs
> to avoid interopability problems with CLI tools since there's no
> known message
Eric Wong writes:
> Jεan Sacren wrote:
>> public-inbox developers,
>>
>> I'm totally new to public-inbox. But I checked out the whole tree and
>> built using the master branch[0].
>>
>> If I execute this[1]:
>>
>> git clone --mirror http://lore.kernel.org/netdev/0 netdev/git/0.git
>>
I just dug up some old emails and I got at least one persons current
email address wrong because they have changed their email address
frequently.
They have an update to their preferred email address in the .mailmap
in the linux-kernel source. Is there any chance public-inbox could
look at .mai
Eric Wong writes:
> Eric Wong wrote:
>> "Eric W. Biederman" wrote:
>> > - $name =~ tr/<>//d;
>> > + $name =~ tr/\n\r<>$/ /d;
>>
>> Is getting rid of '$' an effort to avoid double interpolation by Per
n the future transform a few more characters
into spaces, and don't use string interpolation, use comma separated
variables instead.
Signed-off-by: "Eric W. Biederman"
---
I honestly don't know if I have closed all of the holes
when implementing the code this way. But this chang
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> Eric Wong writes:
>> > "Eric W. Biederman" wrote:
>> >> > The email messages are placed without modification into the public
>> >> > inbox repository so minimize changes
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>>
>> > The command imap_fetch connects to the specified imap mailbox and
>> > fetches any unfetch messages than waits with imap idle until there ar
ebied...@xmission.com (Eric W. Biederman) writes:
> The command imap_fetch connects to the specified imap mailbox and
> fetches any unfetch messages than waits with imap idle until there are
> more messages to fetch.
>
> By default messages are placed in the specified public inbox
PublicInbox::Config.pm::_fill() assumes that address is an array.
Therefore when handling an unset address use an array containing a
single string, instead of a single string.
Signed-off-by: "Eric W. Biederman"
---
I accidentially created a public inbox without an address at some
mirror so I don't want automation
to accidentally cause something important to be lost.
No email messages are deleted from the server instead IMAPTracker
is used to remember which messages were downloaded.
Signed-off-by: "Eric W. Biederman"
---
scripts/i
multiple IMAP mailboxes you will need multiple trackers.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/IMAPTracker.pm | 73 ++
1 file changed, 73 insertions(+)
create mode 100644 lib/PublicInbox/IMAPTracker.pm
diff --git a/lib/PublicInbox/IMAPTr
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> Eric Wong writes:
>> > Is your stuff based on Mail::IMAPClient still working well?
>>
>> Yes. I have fixed a few things to make the code more robust.
>> Which is mostly me learning how Mail::IMA
Eric Wong writes:
> "Eric W. Biederman" wrote:
>>
>> A few days ago I stumbled upon this magic decoder ring for IMAP.
>> The "Ten Commandments of How to Write an IMAP client"
>>
>> https://www.washington.edu/imap/documentation/commndmt.txt
Eric Wong writes:
> "Eric W. Biederman" wrote:
>>
>> A few days ago I stumbled upon this magic decoder ring for IMAP.
>> The "Ten Commandments of How to Write an IMAP client"
>>
>> https://www.washington.edu/imap/documentation/commndmt.tx
Eric Wong writes:
> Konstantin Ryabitsev wrote:
>> On Fri, Oct 25, 2019 at 12:22:14PM +, Eric Wong wrote:
>> > > I'm not sure about a libpublicinbox... I have been really
>> > > hesitant to depend on shared C/C++ libraries whenever I use Perl
>> > > or Ruby because of build and install compl
A few days ago I stumbled upon this magic decoder ring for IMAP.
The "Ten Commandments of How to Write an IMAP client"
https://www.washington.edu/imap/documentation/commndmt.txt
The part I was most clearly missing was that for IMAP it is better to
open multiple sockets (one per mail folder on t
l whose List-ID won't
be configured.
> Cc: Eric W. Biederman
> Link: https://public-inbox.org/meta/87pniltscf@x220.int.ebiederm.org/
> ---
> lib/PublicInbox/MDA.pm| 19 +--
> script/public-inbox-learn | 5 +++--
> script/public-inbox-mda | 7 +
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> There are two reasonable things that can be done, and I suggest
>> we do them both.
>> - Print a warning. (To be deleted if this case turns out to be common).
>> - Deliver to all of the lists you have mail
Eric Wong writes:
> "Eric W. Biederman" wrote:
>
> ... nothing? Just checked my mail server and it's not out of
> space and I'm not seeing any errors in logs. Anyways I'm
> offline for a bit and will be back (hopefully :x)
Apologies, I accidentally
Eric Wong writes:
> Given my recent traumatic experience[*] around multiple
> From/To/Cc/Subject headers; I guess we should prepare for the
> possibility of multiple List-ID headers showing up in -mda.
>
> Right now, we handle the first one (and I'm updating -learn to
> support List-ID, too); but
--
unsubscribe: meta+unsubscr...@public-inbox.org
archive: https://public-inbox.org/meta/
Eric Wong writes:
> "Eric W. Biederman" wrote:
>>
>> Date: Tue, 15 Jan 2019 16:36:42 -0600
>>
>> 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
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> Eric Wong,
>>
>> These should all of my generic patches to support my import_imap_mailbox
>> script. The really important patch that adds to the support for List-ID
>> to public inbox configuration
Eric Wong writes:
> "Eric W. Biederman" wrote:
>>
>> Date: Thu, 16 May 2019 19:26:47 -0500
>>
>> To make the results reproducible and comprehensible when
>> a large number of mail boxes are being processed process the
>> mail boxes
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> Eric Wong writes:
>>
>> > "Eric W. Biederman" wrote:
>> >> my $tracker = PublicInbox::IMAPTracker->new();
>> >
>> > Thanks. What's PublicInbox::IMAPTracker?
Date: Fri, 27 Jul 2018 20:54:27 -0500
This removes the need to delete from an imap mailbox when downloading it's
messages.
Signed-off-by: "Eric W. Biederman"
---
This is simple and potentially very useful.
lib/PublicInbox/IMAPTracker.pm | 73 +++
Date: Sun, 29 Jul 2018 15:52:57 -0500
Signed-off-by: "Eric W. Biederman"
---
Hmm. I thought I was using this but now that I am quickly checking
I don't see this being used anywhere. I think
PublicInbox::Admin::resolve_inboxes has superceded this functionality.
Please feel fr
Date: Thu, 16 May 2019 19:26:47 -0500
To make the results reproducible and comprehensible when
a large number of mail boxes are being processed process the
mail boxes in sorted order, instead of in random hash order.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/Config.pm
Date: Tue, 15 Jan 2019 16:36:42 -0600
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"
---
Eric Wong,
These should all of my generic patches to support my import_imap_mailbox
script. The really important patch that adds to the support for List-ID
to public inbox configuration file I have already sent.
I haven't written tests and I get the following test failure when I run
make test
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> my $tracker = PublicInbox::IMAPTracker->new();
>
> Thanks. What's PublicInbox::IMAPTracker?
Something that keeps the last fetched UID in an sqlite database.
I will follow up with a patch for that as well
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> Eric Wong writes:
>>
>> > Alyssa Ross wrote:
>> >
>> >> Subject: Do I need multiple publicinbox..address values?
>> >
>> > Absolutely not
>> >
>> &g
the configuration that is configured to handle that
mailing list.
Signed-off-by: "Eric W. Biederman"
---
The relevant snippet from my imap import program looks like:
sub list_hdr_ibx($$)
{
my ($config, $list_hdr) = @_;
my $list_id;
if ($list_hdr =~ m/\0/) {
Eric Wong writes:
> Alyssa Ross wrote:
>
>> Subject: Do I need multiple publicinbox..address values?
>
> Absolutely not
>
>> Suppose I have a mailing list, foo-disc...@example.org, and a
>> public-inbox set up, subscribed to that mailing list, that is subscribed
>> to that list as public-inbox+f
Eric Wong writes:
> Konstantin Ryabitsev wrote:
>> On Wed, Sep 25, 2019 at 07:45:03PM +, Eric Wong wrote:
>> > > Is there a way to run just the archiver component of public-inbox --
>> > > just
>> > > writing to git repos without any of the indexing/frontend bits? One of
>> > > the
>> > > i
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> The add method computes the number using num_for, which uses
>> Msgmpa::mid_insert.
>>
>> Short of the sequence number for msgmap getting scrambled I don't
>> see how that can go wrong. Sigh.
&
Eric Wong writes:
> Eric Wong wrote:
>> "Eric W. Biederman" wrote:
>> >
>> > Eric,
>> >
>> > I am just starting to dig into this, I just noticed that I have several
>> > inboxes that are seeing huge skips in message numbers
Eric,
I am just starting to dig into this, I just noticed that I have several
inboxes that are seeing huge skips in message numbers assigned in
msgmap. Do you have any idea why this would be?
If not I will dig in and figure this out. I just figured I would ask
in case you have any handy canid
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> Eric Wong writes:
>>
>> > "Eric W. Biederman" wrote:
>> >>
>> >> I don't trust the MIME type to not munge my email messages in horrible
>> >> ways u
Eric Wong writes:
> "Eric W. Biederman" wrote:
>>
>> The world has turned since I first started following mailing lists and
>> to my surprise every mailling list that I am subscribed to properly
>> sets the "List-ID:" mailing list header. So inst
Eric Wong writes:
> "Eric W. Biederman" wrote:
>>
>> 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
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"
---
The context here is because the only c
Consolidate subject handling in the add function to make it easier to
read and understand.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/Import.pm | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/lib/PublicInbox/Import.pm b/lib/PublicInbox/Impor
handle that mailing list.
Signed-off-by: "Eric W. Biederman"
---
Some context. I have my mailing list email coming in via imap, and I
have a script that looks at List-ID and delivers them to the appropriate
public-inbox. I am hoping to get my script at least into the PublicInbox
sc
Johannes Berg writes:
> On Fri, 2018-09-28 at 23:01 +0200, Eric W. Biederman wrote:
>>
>> I have looked at gnus and there is support in there for performing
>> searches via the old gmane web interface. Public inbox already provides
>> an attribute that tells you what
Johannes Berg writes:
> Sorry to just jump into an old thread; I was wondering about IMAP server
> support as well, in particular because unlike NNTP that allows pushing
> the search to the server, and that would be useful for local archives.
>
>> Hosting an IMAP/POP3 server is way more overhead
Eric Wong writes:
> "Eric W. Biederman" wrote:
>>
>> This ensures that the number of added files remains the same and thus
>> the article numbers derived from a repository will remain the same.
>>
>> I think this is the last place in public-inbox
archive.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/Import.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/PublicInbox/Import.pm b/lib/PublicInbox/Import.pm
index bfa7a8053297..3df7d98f298b 100644
--- a/lib/PublicInbox/Import.pm
+++ b/lib/P
ebied...@xmission.com (Eric W. Biederman) writes:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
>> Eric Wong writes:
>>
>>> I wrote:
>>>> While testing this, it looks like I introduced a bug to
>>>> indexlevel=basic which broke increment
ebied...@xmission.com (Eric W. Biederman) writes:
> Eric Wong writes:
>
>> I wrote:
>>> While testing this, it looks like I introduced a bug to
>>> indexlevel=basic which broke incremental indexing when I made it
>>> possible to upgrade to (medium|ful
Eric Wong writes:
> I wrote:
>> While testing this, it looks like I introduced a bug to
>> indexlevel=basic which broke incremental indexing when I made it
>> possible to upgrade to (medium|full). Patch coming for that in
>> a bit...
>
> Eep, I think there's deeper problems with indexlevel=basic
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> --- a/lib/PublicInbox/Msgmap.pm
>> +++ b/lib/PublicInbox/Msgmap.pm
>> @@ -51,6 +51,10 @@ sub new_file {
>> $dbh->begin_work;
>> $self->created_at(time) unles
syncs.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/SearchIdx.pm | 3 ++-
lib/PublicInbox/V2Writable.pm | 10 ++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/lib/PublicInbox/SearchIdx.pm b/lib/PublicInbox/SearchIdx.pm
index 2532c8dfd10d..54f82aa8e
Now that we track the num highwater mark it is safe to remove messages
from msgmap that have been previously allocated. Removing even the
highest numbered article will no longer cause new message numbers to
move backwards.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/V2W
number to the msgmap in case it is
not currently present.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/V2Writable.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/PublicInbox/V2Writable.pm b/lib/PublicInbox/V2Writable.pm
index 92d2672c78c4..4dd14331a78f 100644
Instrument the tests to verify the highwater num highwater mark is
where it is expected.
Signed-off-by: "Eric W. Biederman"
---
t/v1reindex.t | 10 ++
t/v2reindex.t | 7 +++
2 files changed, 17 insertions(+)
diff --git a/t/v1reindex.t b/t/v1reindex.t
index 87
Place the expected value second in is and isnt tests because when
these tests fail they report the second value as the expected value.
A report saying got 0 expected 8 'no Xapian search results' can be confusing.
Signed-off-by: "Eric W. Biederman"
---
t/v1reindex.t | 6 +
While inspecting the tests I realized that because we have been
reusing variables there can be a memory between one test case and
another. Add scopes and local variables to prevent an unintended
memory between one test and another.
Signed-off-by: "Eric W. Biederman"
---
t/v1reind
Deeply inspect the entire message map in the reindexing tests
as the actual message order is significant and can result
in surprises.
Signed-off-by: "Eric W. Biederman"
---
t/v1reindex.t | 35 +++
t/v2reindex.t | 33
because things don't yet work as they should.
Signed-off-by: "Eric W. Biederman"
---
t/v1reindex.t | 194 +
t/v2reindex.t | 195 ++
2 files changed, 389 insertions(+)
diff --git a/t/
While inspecting the tests I realized that because we have been
reusing variables there can be a memory between one test case and
another. Add scopes and local variables to prevent an unintended
memory between one test cases.
Signed-off-by: "Eric W. Biederman"
---
t/v2rein
Signed-off-by: "Eric W. Biederman"
---
t/v1reindex.t | 7 +++
t/v2reindex.t | 7 +++
2 files changed, 14 insertions(+)
diff --git a/t/v1reindex.t b/t/v1reindex.t
index 8e78aa761333..876c9db3441a 100644
--- a/t/v1reindex.t
+++ b/t/v1reindex.t
@@ -246,6 +246,7 @@ ok(!-d $xa
update the indexers to use this
value.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/Msgmap.pm | 23 +--
lib/PublicInbox/SearchIdx.pm | 8
lib/PublicInbox/V2Writable.pm | 4 ++--
3 files changed, 27 insertions(+), 8 deletions(-)
diff -
When walking messages newest to oldest, assigning the larger numbers
before smaller numbers ensures older messages get smaller numbers.
This leads to the possibility of a msgmap that can be regenerated when
needed.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/SearchI
the code
reveals this can happen anytime gfi_start has not been called.
So just fix atfork_child to skip closing file descriptors that have
not yet been setup.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/Import.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/PublicIn
that can be very confusing as old messages show up
before newer ones.
Finally in v2 deleted messages have not been being deleted from the
msgmap. Which while great for keeping message numbers from going
backwards it means things still show up that shouldn't.
Eric W. Biederman (13):
Impo
Eric Wong writes:
> "Eric W. Biederman" wrote:
>>
>> While playing with git fast export I discovered that mixing <> and
>> read would give inconsistent results. I tracked the issue down to
>> using sysread in ProcessPipe instead of plain read.
>&g
cient needs to use buffered I/O.
Signed-off-by: "Eric W. Biederman"
---
Am I missing something or was this a fundamental bug from the beginning?
lib/PublicInbox/ProcessPipe.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/PublicInbox/ProcessPipe.pm b/lib/Publi
ebied...@xmission.com (Eric W. Biederman) writes:
> Eric Wong writes:
>
>> "Eric W. Biederman" wrote:
>>> My current goal is to make it pleasant to read linux-kernel and possibly
>>> other large archives on my personal machine. Right now the git
&
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> My current goal is to make it pleasant to read linux-kernel and possibly
>> other large archives on my personal machine. Right now the git
>> trees for linux-kernel are aboug 6.8G. Small enough to fit in RAM
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> Have you considered searching public inboxes via git grep?
>
> Not yet...
>
>> For a big server lore.kernel.org with a lot of searches and a lot of
>> clients it might not make sense. But for home use wh
Eric Wong writes:
> "Eric W. Biederman" wrote:
>>
>> Use ||= '' to ensure that if the From or Sender header is not present
>> the code sees an empty string and instead of undefined.
>>
>> I had some email messages with a From field without
Have you considered searching public inboxes via git grep?
For a big server lore.kernel.org with a lot of searches and a lot of
clients it might not make sense. But for home use where searches are
rare and the indexes can not be kept in ram, but the mailbox might fit
git grep sounds attractive?
Use ||= '' to ensure that if the From or Sender header is not present
the code sees an empty string and instead of undefined.
I had some email messages with a From field without an @ (because the
sender was local) and without a Sender which were causing errors when
imported. I think this was ba
Eric Wong writes:
> "Eric W. Biederman" wrote:
>>
>> This is my respin of these patches. I have used the levels:
>> full, medium, basic.
>>
>> I think basic conveys the message that it is ok to run with and you can
>> expect most things to wor
If indexlevel is specified on the command line prefer that.
If indexlevel is specified in the config file prefer that.
If indexlevel is not specified anywhere default to full.
This should make indexlevel somewhat approachable.
Signed-off-by: "Eric W. Biederman"
---
I believe t
themselves.
Update the reindex tests to exercise the full medium and basic code paths
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/Config.pm| 2 +-
lib/PublicInbox/SearchIdx.pm | 8 +++
t/v1reindex.t| 43 +++-
t/v2rein
call is made conditional upon
index levels of 'full' and 'medium'. The index levels that index
positions and terms the two things public-inbox uses Xapian to index.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/SearchIdx.pm | 172 ++---
os as well.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/SearchIdx.pm | 94 +++-
1 file changed, 49 insertions(+), 45 deletions(-)
diff --git a/lib/PublicInbox/SearchIdx.pm b/lib/PublicInbox/SearchIdx.pm
index 0e0796c12c12..b19618c71508 100644
-
o run with all 3 different levels
so at least these code paths get exercised.
Eric W. Biederman (3):
SearchIdx.pm: Make indexing search positions optional
SearchIdx: Add the mechanism for making all Xapian indexing optional
SearchIdx: Allow the amount of indexing be configured
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> This adds a new inbox configuration option 'indexlevel' that can take
>> the values 'positions', 'terms', and 'over'.
>
> The names of these user-facing configuration
Signed-off-by: "Eric W. Biederman"
---
t/v2reindex.t | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/v2reindex.t b/t/v2reindex.t
index f8e2b1b2d46e..5bc307f1cac1 100644
--- a/t/v2reindex.t
+++ b/t/v2reindex.t
@@ -14,13 +14,13 @@ foreach my $mod (qw(DBD::SQL
Previously if a minmax test failed it would say it was expecting the
incorrect value, which is confusing when looking into why the test
fails.
Signed-off-by: "Eric W. Biederman"
---
t/v2reindex.t | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/v2rei
Now that some of the indexes are optionals these tests might fail
so teach them to fail more cleanly.
Signed-off-by: "Eric W. Biederman"
---
t/search.t | 45 ++---
t/v2writable.t | 2 +-
2 files changed, 27 insertions(+), 20 deletions(-)
Signed-off-by: "Eric W. Biederman"
---
t/v2reindex.t | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/v2reindex.t b/t/v2reindex.t
index 9bc271fc2d35..f8e2b1b2d46e 100644
--- a/t/v2reindex.t
+++ b/t/v2reindex.t
@@ -48,6 +48,7 @@ if ('test remove later') {
$im->done;
While developing the ability to disable the indexes I found a few places
where the existing tests could be slightly improved.
Here are my improvements.
Eric W. Biederman (4):
t/v2reindex.t: Ensure the numbers 1 to 10 are used
t/search.t t/v2writable.t: Teach search tests to fail
. The new call is made conditional upon
index levels of 'position' and 'terms' The two things public-inbox
uses Xapian to index.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/SearchIdx.pm | 171 ++-
1 file changed, 88 insert
except the positions of terms is
indexed.
When set to 'over' terms and positions are not indexed. Just the
Overview database for NNTP is created. Which is still quite good and
allows searching for messages by Message-ID. But there are no indexes to
support
searching inside the em
os as well.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/SearchIdx.pm | 94 +++-
1 file changed, 49 insertions(+), 45 deletions(-)
diff --git a/lib/PublicInbox/SearchIdx.pm b/lib/PublicInbox/SearchIdx.pm
index 0e0796c12c12..cc92c389a152 100644
-
change.
Eric W. Biederman (3):
SearchIdx.pm: Make indexing search positions optional
SearchIdx: Add the mechanism for making all Xapian indexing optional
SearchIdx: Allow the amount of indexing be configured
lib/PublicInbox/Config.pm| 2 +-
lib/PublicInbox/SearchIdx.pm | 255
v2 trees already do this and when the indexes are deleted and
rebuilt they maintain they commit numbers.
Add a v1 version of the v2reindex test to verify that reindexing is
working properly on v1 as well as v2.
Signed-off-by: "Eric W. Biederman"
---
lib/PublicInbox/SearchIdx.pm |
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> I believe we can modify the msg number assignment to assign numbers to
>> deletes as well as adds. Short of the same Message-ID coming up twice
>> that should be enough for the current backwards loop to assig
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>> > Eric Wong writes:
>> >> "Eric W. Biederman" wrote:
>> >>>
>> >>> Because of the parallelism in V2 I have n
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> > "Eric W. Biederman" wrote:
>> >> Eric Wong writes:
>> > As far as personal mail goes, I wouldn't want serial numbers at all
>> > (more unnecessary state to keep track of).
&
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> Eric Wong writes:
>> > "Eric W. Biederman" wrote:
>> >> Then I am going to report a probable bug. In V2 in public-inbox-index
>> >> I can not find a path from finding a
ebied...@xmission.com (Eric W. Biederman) writes:
> Eric Wong writes:
>
>> "Eric W. Biederman" wrote:
>>>
>>> Because of the parallelism in V2 I have noticed messages in numbered
>>> in an order that does not correspond to their commit order. S
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> Eric Wong writes:
>> > "Eric W. Biederman" wrote:
>> >> I have been digging through the code looking so I can understand the v2
>> >> format and I have some ideas on how things mi
Konstantin Ryabitsev writes:
> On Thu, Jul 05, 2018 at 11:13:46PM +, Eric Wong wrote:
>>"Eric W. Biederman" wrote:
>>> It looks like public-inbox has some challenges when importing some
>>> questionable emails. The import of lkml has resulted in severa
Eric Wong writes:
> "Eric W. Biederman" wrote:
>> I have been digging through the code looking so I can understand the v2
>> format and I have some ideas on how things might be improved, and some
>> questions so that I understand.
>
> Great to know you&
Konstantin Ryabitsev writes:
> On Wed, Jul 11, 2018 at 03:01:53PM -0500, Eric W. Biederman wrote:
>> Names. Is there a good reason not to use message numbers as the names
>> in the git repositories? (Other than the cost to change the code?) That
>> would remove the need
1 - 100 of 110 matches
Mail list logo