Hello:
I found an interesting problem using lei with imaps:// folders. I'm trying
things out with migadu, and the folder paths use '/' separators, so a full
IMAPS folder path for a folder "lore/mentions" is
imaps://imap.migadu.com/lore/mentions. However, if I configure lei-q to use
that remote
On Fri, Sep 10, 2021 at 01:56:53PM +, Eric Wong wrote:
> > Seems to have it as perl-Search-Xapian, which provides Xapian.pm.
>
> Oh I meant the newer SWIG Xapian.pm. Search::Xapian is
> Search/Xapian.pm which uses XS and isn't getting new features.
Ah, no, doesn't look like
Just a quickie note. I was trying to make my query more readable, so I
switched my test example to the following:
[lei]
q = (dfn:Documentation/security/landlock.rst \
OR dfn:Documentation/userspace-api/landlock.rst \
OR dfn:include/uapi/linux/landlock.h \
OR
On Thu, Sep 09, 2021 at 11:36:14PM +, Eric Wong wrote:
> > These are my quickie instructions for how to use lei in a toolbox
> > environment
> > if you are running a distribution like Fedora and don't want to install a
> > lot
> > of perl dependencies into your main OS.
>
> Off the top of
Hi, all:
These are my quickie instructions for how to use lei in a toolbox environment
if you are running a distribution like Fedora and don't want to install a lot
of perl dependencies into your main OS.
1. Grab the dockerfile:
https://gist.github.com/mricon/046ba7c8b03bd92176dbe83e04f2466c
On Thu, Sep 09, 2021 at 09:23:48PM +, Eric Wong wrote:
> > Annoyingly, after I blow away the container to start fresh, I get:
> >
> > t/gcf2.t . skipped: PublicInbox::Gcf2 missing for
> > t/gcf2.t
> >
> > That means gcf2 isn't getting built, right?
>
> Yeah,
On Thu, Sep 09, 2021 at 09:14:36PM +, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > Yep, that was the culprit. After installing pkg-config, gcf2 builds and
> > tests
> > pass. I still have this while running "make test":
>
> Good to know. We
On Thu, Sep 09, 2021 at 08:45:41PM +, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > Hello:
> >
> > I can't seem to get a clean "make test" in the Debian container. It's
> > possible
> > that I'm missing some of the packages, as the offic
On Thu, Sep 09, 2021 at 08:06:28PM +, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > Eric:
> >
> > Is there a way to "tag" a single thread that isn't matching a saved search
> > and
> > have it be followed for any new updates? E.g. someone ping
Hello:
I can't seem to get a clean "make test" in the Debian container. It's possible
that I'm missing some of the packages, as the official Debian container image
is very minimal.
The dockerfile is here:
https://gist.github.com/mricon/046ba7c8b03bd92176dbe83e04f2466c
The pertinent section is:
Eric:
Is there a way to "tag" a single thread that isn't matching a saved search and
have it be followed for any new updates? E.g. someone pings a developer on IRC
and says "you may be interested in following this discussion" -- what's the
best course of action for them to pull that into their
On Wed, Sep 08, 2021 at 02:49:48PM +, Eric Wong wrote:
> > On the other hand, a service that offers full search-based imap/pop3 folders
> > is going to be an easy sell:
> >
> > - it works with any imap client as a simple extra account
> > - it can be mirrored locally and synced two-ways via
On Tue, Sep 07, 2021 at 10:14:04PM +, Eric Wong wrote:
> > One of the
> > options I want to investigate is making IMAP/POP3 accessible individual
> > mailboxes fed by lei, such that a new subsystem maintainer could have a
> > ready-made mailbox available to them without needing to
> >
On Tue, Sep 07, 2021 at 10:02:03PM +, Eric Wong wrote:
> This allows us to link to threads spread across multiple inboxes.
>
> Reported-by: Konstantin Ryabitsev
> Link:
> https://public-inbox.org/meta/20210907140954.4rlh6pn5fz4ljkxp@meerkat.local/
Works great, thanks!
-K
On Thu, Sep 02, 2021 at 09:58:50PM +, Eric Wong wrote:
> OK, there's two main commands, "lei q" and "lei up".
> Both of which may prompt for passwords depending on how
> git-credential is set up:
>
> # the destination, could be Maildir
>
On Tue, Sep 07, 2021 at 08:56:17PM +, Eric Wong wrote:
> > 1. this means that each "lei up" call will be increasingly larger and
> > larger,
> >since when we init the search with rt:, it gets resolved into a datestamp
> >(e.g. rt:2.weeks.ago becomes rt:1625699031). I'm worried that
On Sat, Sep 04, 2021 at 09:36:58PM +, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > Yep, that seems to work fine. Question -- I noticed that lei just issues a
> > regular query, retrieves results with curl and then parses the output. Is
> > there a danger o
Hello:
When using message-id lookups, the results are returned from individual lists,
e.g.:
https://lore.kernel.org/20210901141637.fmvgs4hnk6m4ym7x@meerkat.local
This will redirect to:
https://lore.kernel.org/tools/20210901141637.fmvgs4hnk6m4ym7x@meerkat.local/
Any way to have the
On Thu, Sep 02, 2021 at 09:58:50PM +, Eric Wong wrote:
> Fwiw, most of the functionality works much better with Maildir
> because of potential password prompts needed for IMAP and
> interactivity required.
Okay, I'll try this out with maildir for now -- it's easy to hook mbsync into
the
Eric:
I am getting ready for my presentation to the Linux Plumbers (happening in a
few weeks, eek), which is based around lore, lei (I see what you did there)
and search-based subscriptions. I want to make it hands-on with practical
examples, which is what developers would appreciate more than
Hello:
As reported to me today, the following page generates broken links:
https://lore.kernel.org/lkml/20210902185610.aejfdhjl52l2ivpb@meerkat.local/
The url= entry in PI_CONFIG is just:
url = tools
Theoretically, it would be fixed if the URL was with a leading /, like so:
url = /tools
On Wed, Sep 01, 2021 at 08:54:13PM +, Eric Wong wrote:
> > With lore.kernel.org now 3 different nodes with failover, I'm curious if
> > it's
> > safe to point the NNTP server at that as well. I'm assuming that article
> > numbers are going to be the same across all three systems, but I wanted
Hello:
With lore.kernel.org now 3 different nodes with failover, I'm curious if it's
safe to point the NNTP server at that as well. I'm assuming that article
numbers are going to be the same across all three systems, but I wanted to
double-check that it's the case. I.e., if node1 goes down and
Hello:
What's the proper procedure to remove an inbox from extindex? For example, if
I wanted to drop a source from being replicated to lore.kernel.org, how do I
properly remove it from /all/ search results?
-K
On Fri, Aug 27, 2021 at 10:03:02PM +, Eric Wong wrote:
> If it happens once, it'll happen again. I'm not sure which code
> path triggers it, but maybe this will fix it. There's also a secondary
> patch below which may be more complete, but may also be
> unneeded.
Applied what was between
On Sat, Aug 28, 2021 at 11:50:05AM +, Eric Wong wrote:
> Maybe this works better? *shrug*
>
> I was somewhat under the impression every page needed to
> link/advertise code under the AGPL, but maybe just one HTML page
> is fine... We can't advertise our AGPL code to NNTP/IMAP users,
> nor
On Fri, 27 Aug 2021 at 09:03, Konstantin Ryabitsev
wrote:
> > Just making /all/ show up at the top like a normal inbox (and
> > letting the admin decide on description) seems sufficient. If
> > users can get to /all/ then they can search /all/ as normal.
>
> Sure, this w
On Fri, Aug 27, 2021 at 12:08:43PM +, Eric Wong wrote:
> I think that's too much vertical whitespace at the top of the
> page, and multiple s or boxes at the top can get
> confusing.
>
> Just making /all/ show up at the top like a normal inbox (and
> letting the admin decide on description)
Hello:
I switched the configuration to return wwwlisting as toplevel view (instead of
redirecting / to /all/), but there's some discontent, because the easy
interface to "search everything" is gone and unless someone knows about /all/,
they wouldn't find out about it from the wwwlisting view.
On Thu, Aug 26, 2021 at 12:36:06PM +, Eric Wong wrote:
> Eric Wong wrote:
> > Maybe "/+/" (as in "/+/$FOO.css") is a good URL path prefix...
>
> Pushed as commit 26c635060dcae35feae836b02a18a6a11e408312
It looks good to me, thanks!
-K
On Thu, Aug 26, 2021 at 12:33:30PM +, Eric Wong wrote:
> This hopefully makes the long .onion URL more usable on small
> displays;
It's still not quite fixing the problem (actually, for some reason it's now
looking worse in the narrow mobile view for me). May I suggest the following:
- The /
On Tue, Aug 24, 2021 at 08:11:15PM +, Eric Wong wrote:
> Any chance you're out-of-FDs or permissions are wrong?
>
> There's also an off chance a non-inbox (extindex) object is there.
> Perhaps this debugging patch can shine a light on things:
Aha, it did help identify the problem. There was
Hello:
I tried the nntpd daemon on x-lore, but I seem to be hitting something odd
while retrieving the group list. This is from syslog:
public-inbox-nntpd: Can't call method "minmax" on an undefined value at
/usr/local/share/perl5/PublicInbox/NNTP.pm line 264.
public-inbox-nntpd: during long
Hello:
Just noticed that the wwwlisting page doesn't apply any css stylesheets
(currently still on https://x-lore.kernel.org/lists.html ). It should do the
same thing as any other page view, e.g. so it can properly respect the client
prefers-color-scheme choices.
-K
On Mon, Aug 16, 2021 at 11:35:20PM +, Eric Wong wrote:
> > - I don't think most people would choose to download mbox.gz or click on the
> > "Atom" link from the thread listing page -- there is a thread view for
> > this
> > purpose.
>
> Agreed, I don't think I've ever used them from the
On Mon, Aug 16, 2021 at 10:21:48PM +, Eric Wong wrote:
> > However, site security policies may deliberately prohibit execution of
> > inline content such as scripts and stylesheets as an extra layer of
> > protection against XSS vulnerabilities. For example, with the following
> > HTTP headers
Hello:
Passing more observations from people testing out x-lore.kernel.org:
- the long .onion URL at the bottom of each page causes problems on mobile
devices because it results in a very wide page with blank content on the
right side.
I suggest that we don't need to provide the "git clone"
Hello:
I was playing with mobile view and I think adding "- mbox.gz / Atom" on the
thread listing page is both unnecessary and makes the output too busy. E.g.
compare:
[PATCH v2] drm: avoid races with
modesetting rights
2021-08-16 15:20 UTC (2+ messages)
- mbox.gz / Atom
`
into
the contrib stylesheets makes sure that these styles are applied even
with the strictest security policies in place.
Signed-off-by: Konstantin Ryabitsev
---
contrib/css/216dark.css | 3 ++-
contrib/css/216light.css | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git
On Sat, Aug 14, 2021 at 08:46:33PM +, Eric Wong wrote:
> > It was sent to io...@lists.linux-foundation.org (mailman) and to a bunch of
> > vger lists, all of which have higher boosts in the configuration, e.g.
> > netdev:
>
> boost doesn't come into effect due to the Mailman footer from
>
Eric:
The new x-lore systems are rebuilt and reindexed using the latest master (as
of 2 days ago), but boosts still don't appear to be quite working as intended.
For example, this thread:
https://x-lore.kernel.org/all/20210809175620.720923-1-ltyker...@gmail.com/
It was sent to
On Thu, Aug 05, 2021 at 11:05:41AM +, Eric Wong wrote:
> > - I will bring up the rest of the nodes throughout the week, so
> > x-lore.kernel.org will become more geoip-balanced. I will share any other
> > observations once I have more data. Once all 4 nodes are up, I will share
> > this
On Wed, Aug 04, 2021 at 10:02:46AM +, Eric Wong wrote:
> 2/2 fixes the boost bug reported by Konstantin, and 1/2
> fixes an accounting error which may improve indexing
> performance.
Thank you, trying it out now and will let you know once reindex completes.
Best regards,
-K
On Mon, Aug 02, 2021 at 09:16:56PM +, Eric Wong wrote:
> > I believe this should assign boost value of 0, but the virtualization source
> > seems to be "winning" both via the interface and when retrieving t.mbox.gz.
> > Anything I'm not doing right?
>
> Correct, boost=0 is the default. Did
Eric:
I'm not sure if boost is quite working correctly (or it's possible I'm not
doing something right). E.g. I have the following thread:
https://x-lore.kernel.org/all/d8319fd18df7086b12cdcc23193c313893aa071a.1627362340.git.viresh.ku...@linaro.org/T/#u
It was sent to several vger destinations,
On Thu, Jul 29, 2021 at 10:06:29PM +, Eric Wong wrote:
> My gut says 1g batch-size seems too high (Xapian has extra
> overhead) and could still eat too much into the kernel cache
> (and slow down reads). 100m might be a more reasonable limit
> for jobs=4 and 128G RAM.
Okay, I have things up
On Thu, Jul 29, 2021 at 09:13:21PM +, Eric Wong wrote:
> jobs will be bound by I/O capability for your case. SATA-2 vs
> SATA-3 vs NVME will have a notable difference, as does the
> quality of the device (MLC, TLC, QLC; cache/controller).
So, on these systems with large lvmcache disks, large
Hello:
Is there any specific logic for mixing --batch-size and --jobs? On a system
with plenty of CPUs and lots of RAM, does it make sense to have more --jobs,
larger --batch-size, or some balance of both?
-K
On Wed, Jul 21, 2021 at 02:05:48PM +, Eric Wong wrote:
> publicinbox..boost is now supported (it should be obvious
> higher numbers are handled first, because OS scheduler
> "priority" always confuses me :x)
>
> And -init handles arbitrary "-c KEY=VALUE" things like
> git-config and allows
On Tue, Jul 20, 2021 at 09:07:24PM +, Eric Wong wrote:
> > I figured as much, but we do want to set extra keys *and* write the config
> > in
> > a certain order (e.g. prioritizing some sources over others by listing them
> > first). I currently do this via a list-id globbing match (e.g.
> >
On Mon, Jul 19, 2021 at 08:49:35PM +, Eric Wong wrote:
> > The best I can think of is a systemd watcher service that automatically
> > restarts the daemons when the config file is modified, but I wanted to check
> > here first to see if perhaps I'm missing something simpler.
>
> Yes, a
Hello:
Something I stumbled on today is the need to have the -httpd and -nntpd
daemons reread the config file after we've mirrored and initialized new
inboxdirs. The situation is:
- public-inbox-{httpd,nntpd} are running as systemd services as user
"publicinbox"
- the mirroring and
On Tue, Jun 29, 2021 at 07:59:57PM +, Eric Wong wrote:
> > My thinking is that with mirrors of mirrors of mirrors, if someone submits a
> > GDPR removal request, then there should be an easy way of figuring out where
> > these requests should actually go. Maybe infourl can cover this, but it's
On Sun, Jun 27, 2021 at 04:28:37PM -0400, Kyle Meyer wrote:
> I recently upgraded a server from 08b649735 to 5860b498a and noticed
> that grok-pull didn't bring in any updates. It looks like what's going
> on is that the top-level /manifest.js.gz endpoint is now coming up
> empty.
BTW, I just
On Mon, Jun 28, 2021 at 10:12:36PM +, Eric Wong wrote:
Hope you're finding ways of staying cool and sane. It's hot here on the East
coast, but a) we're used to it, and b) it's not yikes degrees.
> > Imaginary code snippet:
> >
> > $ git show refs/meta/origins:i
> > [metadata]
> > source =
Hello:
I'm working away on grokmirror+public-inbox replication, and I'm trying to
come up with a good solution for passing the "archiver origins" info. In
examples/grok-pull.post_update_hook.sh, we try to get this information out of
a curl call to the clone origin, but this may not be reliable
On Mon, Apr 26, 2021 at 06:47:17PM +, Eric Wong wrote:
> > I'm thinking we need the ability to make it a real clonable repository --
> > perhaps without its own xapian index? Actual git repositories aren't large,
> > especially if they are only used for direct git operations. Disk space is
> >
On Mon, Apr 26, 2021 at 05:37:26PM +, Eric Wong wrote:
> > The latter is specifically something I think would be of interest to kernel
> > folks, so I envision that we'd have something like the following:
> >
> > - a maintainer publishes a configuration file we can pass to lei
>
> The
Hello:
One of the services I think would be interesting to provide is ability for
people to subscribe to "curated saved searches". For example, a kernel
subsystem maintainer can define a set of query parameters (a thread mentions
these files/functions/terms, etc), and allow others to follow this
Eric:
I'm working on the new incarnation of lore.kernel.org (that will run on
multiple frontends as opposed to the centralized version we have now) -- I
hope to have everything ready to go by the time 1.7.x rolls out. I wonder if
you can give some pointers for extindex and /all, specifically:
-
On Fri, Apr 23, 2021 at 07:18:49PM +, Eric Wong wrote:
> > > Btw, I noticed xapian14-bindings isn't packaged. If it were, it
> > > would include the better-maintained Xapian.pm (SWIG) binding.
> > > Getting Search::Xapian (XS) from CPAN would no longer be
> > > necessary.
> >
> > Hmm... I
On Fri, Apr 23, 2021 at 02:02:24AM -0400, Eric Wong wrote:
> > If you want to run public-inbox on CentOS-7 with newer git and xapian, you
> > can
> > use the following packages I am maintaining:
> >
> > https://copr.fedorainfracloud.org/coprs/icon/lfit/packages/
>
> Btw, I noticed
Sending a quick note here since this can be of interest to others.
If you want to run public-inbox on CentOS-7 with newer git and xapian, you can
use the following packages I am maintaining:
https://copr.fedorainfracloud.org/coprs/icon/lfit/packages/
To enable on your system:
yum install
On Tue, Apr 20, 2021 at 10:06:08PM +, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > While poking around, I've discovered that it only fails when "make test"
> > runs
> > as root (don't judge -- this is in a throwaway lab VM):
>
> > Hop
On Tue, Apr 20, 2021 at 08:38:54PM +, Eric Wong wrote:
> > t/lei-daemon.t ... 18/?
> > # Failed test 'connect error noted'
> > # at t/lei-daemon.t line 80.
> > # ''
> > # doesn't match '(?^:\bconnect\()'
> > # Looks like you failed
While playing with libgit2/Gcf2, I've discovered that t/lei-daemon.t will fail
when PERL_INLINE_DIRECTORY is set:
t/lei-daemon.t ... 18/?
# Failed test 'connect error noted'
# at t/lei-daemon.t line 80.
# ''
# doesn't
On Wed, Apr 21, 2021 at 12:02:04AM +0500, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > t/admin.t Warning: Use of "ref" without
> > parentheses is ambiguous at
> > /usr/local/share/public-inbox/blib/lib/PublicInbox/TestCommon.pm l
Something I noticed today:
$ make test
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM"
"-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0,
'blib/lib', 'blib/arch')" t/*.t
t/address.t .. ok
t/admin.t
On Tue, Apr 13, 2021 at 03:44:35PM -0400, Eric Wong wrote:
> On a side note, I'm strongly considering moving to Perl 5.12
> after public-inbox 1.7 is released. perl 5.12.4 will be a
> decade old in a few months (however 5.12.5 was Nov 2012).
As long as we can set the low bar at 5.16, I'm good
On Wed, Mar 17, 2021 at 08:18:43PM +0200, Eric Wong wrote:
> > Is that intentional, or can this be tweaked to show a single result for the
> > same message-id?
>
> Not really. At least for the summary search results, it makes
> no sense:
>
>
On Wed, Mar 17, 2021 at 01:11:16AM -0600, Eric Wong wrote:
> Eric Wong wrote:
> > Requires Tor, for now:
> >
> > http://rskvuqcfnfizkjg6h5jvovwb3wkikzcwskf54lfpymus6mxrzw67b5ad.onion/all/
> > http://lore.czquwvybam4bgbro.onion/all/
>
> Also available without Tor:
>
>
On Fri, Mar 05, 2021 at 10:20:19PM +, Eric Wong wrote:
> So I think the -extindex stuff might be stable and suitable for
> general consumption. The HTML WWW UI around -extindex has some
> rough edges but nothing that would take too much effort to fix.
\o/
> But I'm deeply worried about
On Fri, 26 Feb 2021 at 09:38, Konstantin Ryabitsev
wrote:
> - it's a simple flat dir of numeric files corresponding to the number of the
> message in the index
> - each message is a valid rfc2822 document -- in fact, if I copy them into the
> "new" folder of any ma
Hello:
I'm playing around with using public-inbox as the archiving subsystem for
mlmmj. I know it's possible to simply configure a local address to deliver to
public-inbox-mda [1], but I wonder if there's a way to reduce complexity and
simply configure public-inbox-watch to monitor mlmmj's
On Sun, Feb 21, 2021 at 10:20:13PM +, Eric Wong wrote:
> > This was tested with the latest release of Grokmirror, v2.0.7. Note
> > that the "pull" and "fsck" sections are required even though they're
> > empty.
Hmm... That grok-pull requires the [fsck] section is a bug that I introduced
in
On Tue, Feb 02, 2021 at 09:08:10AM +0100, Uwe Kleine-König wrote:
> (It seems from the outside I have to use /r/ though for lore.kernel.org,
> https://lore.kernel.org/20201215212228.185517-2-clemens.gru...@pqgruber.com
> at least doesn't work.)
That's just a side-effect of our setup -- we define
On Mon, Feb 01, 2021 at 02:26:30PM +0100, Uwe Kleine-König wrote:
> > PublicInbox::NewsWWW fallback lets //$host/$message_id work (no /r/).
> > It can be run as a standalone PSGI, too, see examples/newswww.psgi
>
> Huh, it seems I have to dig deeper into the internals of Plack. Thanks.
>
> > At
On Mon, Dec 28, 2020 at 09:31:39PM +, Eric Wong wrote:
> AFAIK, V2Writable always does the right thing on -purge/-edit;
> at least for WWW users(*).
>
> V2W does more work in rare cases when history gets rewritten,
> but doesn't track anything beyond the latest indexed commit
> hash.
>
> In
On Mon, Dec 28, 2020 at 09:41:46PM +, Eric Wong wrote:
> a) There are occasionally resent revisions of patches with the
>same Message-ID
This is broken and is unwanted. :)
> b) More often, a cross-posted message has different trailers
>depending on which list it was posted to. (And
On Tue, Dec 22, 2020 at 06:28:08AM +, Eric Wong wrote:
> Eric Wong wrote:
> >
> > There's scripts/ssoma-replay which was v1-only and dependent on
> > ssoma. I've been meaning to convert into something that reads
> > NNTP so it's not locked into public-inbox. Maybe it could be
> > part of
On Tue, Dec 22, 2020 at 11:21:18PM +0100, Uwe Kleine-König wrote:
> > 2. the goal of lore.kernel.org is maximum transparency, so we include
> >everything that our own systems add to the headers in an attempt to show
> >that "there's nothing up our sleeves"
> >
> > > I could handcraft a
On Tue, Dec 22, 2020 at 08:37:04AM +0100, Uwe Kleine-König wrote:
> I found that Konstantin Ryabitsev's tool to prepare an initial archive
> from an already existing mailing list[1] filters some of these out, but
> the instance on kernel.org has some of these details, too. (See for
> example
>
Hello:
One of our projects is looking at mailing list hosting and I was wondering if
I should steer them towards public-inbox + mlmmj as opposed to things like the
moribund googlegroups, groups.io, etc.
I know meta uses mlmmj, but there don't appear to be many docs on how things
are organized
On Mon, Dec 14, 2020 at 08:39:38PM +, Eric Wong wrote:
> I've been thinking a bit about UI/UX for local command-line
> tooling, and one thing I've been pondering is exposing Perl5
> regexps as a mechanism for filtering
> mailboxes/newsgroups/URLs/pathnames, etc...
I think it's best to stick
On Thu, Dec 10, 2020 at 10:38:47PM +, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
>
>
> > That said, should public-inbox consider this case when generating the
> > /raw and /t.mbox.gz messages? If the Archived-At and List-Archive
> > headers are listed i
On Thu, 10 Dec 2020 at 16:43, Konstantin Ryabitsev
wrote:
> This is what causes DKIM verification to fail, and NOT the newline:
for the record, the DKIM RFC specifically deals with extra trailing newlines:
The "simple" body canonicalization algorithm ignores all empty lines
On Thu, Dec 10, 2020 at 08:55:40PM +, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > Hello:
> >
> > While investigating why some of the messages retrieved via
> > lore.kernel.org were failing DKIM checks, I realized that
> > public-inbox-httpd appends a
Hello:
While investigating why some of the messages retrieved via
lore.kernel.org were failing DKIM checks, I realized that
public-inbox-httpd appends an extra newline to message bodies. This
newline isn't present in git backends, just in messages retrieved via
(at least) public-inbox-httpd.
On Tue, Dec 08, 2020 at 06:02:32PM +, Eric Wong wrote:
> > So, are things to the point where we only need a single xapian db
> > for all lists, or do we still need to keep individual list indexes?
>
> Only indexlevel=basic (sqlite) for individual lists. This saves
> a bunch of FDs and
On Thu, Nov 26, 2020 at 07:45:43PM +, Eric Wong wrote:
> Requires Tor, for now:
>
> http://rskvuqcfnfizkjg6h5jvovwb3wkikzcwskf54lfpymus6mxrzw67b5ad.onion/all/
> http://lore.czquwvybam4bgbro.onion/all/
Thanks for this work, Eric, things are looking good in my tests, though
I uncovered a bunch
On Tue, Oct 27, 2020 at 07:54:01AM +, Eric Wong wrote:
> ...and mostly wired up for WWW, but requires manual config
> editing atm. Needs docs and tests, and IMAP support.
Great progress! I look forward to reading the forthcoming docs. :)
-K
Hello:
I am writing a tool that would provide an "audit feed" of all pushes
performed to git.kernel.org, so I needed a way to write to public-inbox
v2 format repositories from Python. I figured this may be useful as a
standalone library, so I published it as "ezpi":
Hi, all:
I needed a way to pipe public-inbox straight into patchwork.kernel.org
without having to manage yet another list subscription with postfix pipe
integration. Then I realized that it's generally useful as a way to
deliver straight from public-inbox archives into local inboxes --
On Fri, Oct 02, 2020 at 08:08:30PM +, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > Hello:
> >
> > While discussing something else on the kernel.org users list, the
>
> Btw, is this list public?
It's not, because it's supposed to be just for people w
Hello:
Attempting to subscribe radio...@radiotap.org has highlighted two
problems with list-id matching. When the email comes in from the mailing
list, the header is set as:
List-Id: radiotap.NetBSD.org
Public-inbox doesn't find this because the above list-id header is not
compliant with
Good morning, and congratulations on 1.6.0!
I'm starting to play with the new imapd mode (currently using the imap
daemon on public-inbox.org), and I am curious how we can make it obvious
to the clients that there is a new epoch available. For example, if
someone configures mbsync to fetch
On Sun, Sep 13, 2020 at 06:55:50AM +, Eric Wong wrote:
> Currently (and since the earliest days of this project
> supporting Xapian), indices were per-inbox. This allowed
> inboxes to be isolated, making it easy to add and remove
> inboxes.
>
> The detached/external indices will allows a
On Fri, Sep 04, 2020 at 10:40:24PM +0200, Simon Eigeldinger wrote:
> Hi all,
>
> I know and I guess that has been asked a few times.
> Is it possible to convert a git repo with messages to a mbox file and
> how is that done?
>
> According to the install guide for Public-Inbox you don't need to
>
On Wed, Sep 02, 2020 at 07:05:25PM +, Eric Wong wrote:
> I've been indexing and reindexing a local mirror of
> https://lore.kernel.org/lkml a bit, and it's kinda depressing to
> see newer messages being more and more bloated even on a
> plain-text-only mailing list :<
>
> The first column
On Mon, Aug 17, 2020 at 08:17:37PM -0500, Eric W. Biederman wrote:
> 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 .mailmap and do something useful in the web interface?
>
> Perhaps display an
101 - 200 of 296 matches
Mail list logo
