On Sun, Aug 21, 2016 at 12:08:52PM +0000, Eric Wong wrote: > "W. Trevor King" wrote: > > This is the ssoma archive (with the data in it). I just set up a > > basic HTTP archive (following [1]) based on a Docker image [2] (Gentoo > > doesn't package all the Perl dependencies public-inbox needs). > > Ugh, that sucks (sorry, not a fan of Docker). > > What's missing from Gentoo? Gentoo doesn't package (or I couldn't find the package for) Encode::MIME::Header or Mail::Thread. I tried installing things from CPAN, but ran into a compile-time error from the ‘cpan’ invocationand gave up ;). I can try and reproduce the error if you're curious, but I don't have it handy at the moment. > > $ git config -f srv/notmuch.git/config publicinbox.http http://tremily.us > > $ git config -f srv/notmuch.git/config publicinbox.email notmuch@notmuchmail.org > > That should probably be: > > ; based on your [3] > git config -f srv/notmuch.git/config \ > publicinbox.notmuch.url http://tremily.us/notmuch > > git config -f srv/notmuch.git/config \ > publicinbox.notmuch.address notmuch@notmuchmail.org > > ; this is crucial for all the public-inbox-* tools > git config -f srv/notmuch.git/config \ > publicinbox.notmuch.mainrepo /path/to/notmuch.git I was using these in the Dockerfile's CMD: (cd /srv; for NAME in *; do CONF="/srv/${NAME}/config"; public-inbox-init "${NAME}" "/srv/${NAME}" $(git config -f "${CONF}" publicinbox.http) $(git config -f "${CONF}" publicinbox.email); done) && … Are you saying that I can skip the ~/.public-inbox/config entries setup by public-inbox-init if I set publicinbox.{name}.* in the ssoma repository's config? That would be nice. I don't see a point to having {name} in ssoma-config settings though, since you're already in a single bucket by that point (using publicinbox.{name}.* makes sense in the multi-bucket ~/.public-inbox/config). > > It's not updating automatically yet, but that will probably look > > like: > > > > 1. Pull new mbox [4]. > > 2. Import into notmuch-archives [5]. > > 3. Re-run public-inbox-index (this could probably be via ‘docker exec …’. > > > > But I'll have to test that to confirm. And ideally we'd be using > > ssoma-mda or similar directly, instead of going through mbox, but I'd > > rather get the official headers on the stored mail than be efficient > > ;). > > For mirroring existing lists, I started using public-inbox-watch > which currently watches Maildirs. If I had a Maildir locally, I'd just use procmail and push new messages into ssoma-mda. I'm using the import script because my local mail has “how we delivered this to Trevor” headers (which I don't want to add) but the downloaded mbox has “how we delivered this to notmuch@notmuchmail.org” (which seems like a better fit for a shared ssoma repo). > I recommend public-inbox-watch for mirroring existing lists (such as > what I did with git@vger) but public-inbox-mda for self-hosted lists > (such as meta@public-inbox.org). Why is that? Procmail + public-inbox-mda (or my Python ssoma-mda fork [1,2]) seems simpler and equally effective if you want to insert a message that your mail system is delivering locally. > > One shift from Gmane's mid.gmane.org/… is that the public-inbox UI > > Message-ID lookup is per-bucket, and public-inbox seems to be > > encouraging per-list buckets. > > The public-inbox-nntpd interface supports mid lookups across all > inboxes in that instance; so it should be doable in the WWW > interface, too. Either way, I think it has to be O(n) where (n) is > the number of Xapian DBs, though. I'm more concerned about the interface, and less about the implementation (which can be improved later). The (n) lookups are trivially parallelizable, and you can always add a Message-ID → buckets lookup table if (n) lookups turns out to be too slow. Cheers, Trevor [1]: id:20141107190321.GL23609@odin.tremily.us [2]: id:af679af8257e250ac606e35a1307ad02907b8426.1413663212.git.wking@tremily.us http://public-inbox.org/meta/af679af8257e250ac606e35a1307ad02907b8426.1413663212.git.wking@tremily.us/t/#u -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy