Re: what storage system(s) are you using?

On Wed, Aug 05, 2020 at 03:11:27AM +, Eric Wong wrote: > I've been mostly using ext4 on SSDs since I started public-inbox > and it works well. As you know, I hope to move lore.kernel.org to a system with a hybrid lvm-cache setup, specifically: 12 x 1.8TB rotational drives set up in a lvm

Re: thoughts on Git::Raw / libgit2?

On Tue, Jun 16, 2020 at 09:40:51PM +, Eric Wong wrote: > Git::Raw is not packaged with CentOS 7.x; but cpan/cpanm is an > option. It is in Debian 10.x as libgit-raw-perl, so I can > report bugs via Debian's BTS[*]. FYI, even though lore.kernel.org runs on CentOS 7.x, most perl modules come

Re: Search based on data in follow-ups

On Tue, May 26, 2020 at 09:35:50PM +, Eric Wong wrote: > > - (subject contains "PATCH") AND (follow-up from test...@example.com > > that contains "Passed") AND NOT (follow-up from me that contains > > "Applied|NACK") > > > > I expect this would require client-side filtering, though, as I

Search based on data in follow-ups

Hello: I suspect this would be Pretty Hard To Do, but wanted to mention it on the list anyway, just as a "musing out loud." It would be cool to be able to exclude/include results based on conditions in thread follow-ups. E.g.: - (subject contains "PATCH") AND (follow-up from

Re: how's memory use? May 2020 edition

On Tue, May 12, 2020 at 08:37:34AM +, Eric Wong wrote: > Hey all, if possible; I'd like to know the memory use of your > daemons (particularly -httpd), relevant pmap(1) (or equivalent) > output, and version of public-inbox in use. This is on lore.kernel.org. We upgraded to 1.5.0 yesterday, so

Re: [PATCH] doc: add clients.txt

On Mon, Apr 27, 2020 at 08:57:08PM +, Eric Wong wrote: > +* kernel.org helpers, including get-lore-mbox and sendmail-pi-feed > + https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git I'd rather it listed b4 instead, as it's a successor to get-lore-mbox:

Re: mail header indexing additions

On Mon, Apr 20, 2020 at 01:53:17AM +, Eric Wong wrote: > I'm probably going to start indexing List-Id: headers by > default, and have `lid:' be the search prefix for inboxes > which combine multiple lists and may have unstable email > addresses. This would be handy indeed! > Anything else

Re: How to force stricter threading

On Thu, Mar 19, 2020 at 07:58:20AM +, Eric Wong wrote: > > So the "Patchwork summary for: linux-renesas-soc" message: > > > > https://lore.kernel.org/linux-renesas-soc/158229483332.12219.5639020605006542672.git-patchwork-summ...@kernel.org/raw > > > > has the following header: > > > >

Attestation signatures in a separate ref

ref containing just PGP-signed metadata of each message. refs/heads/master:m From: Foo Foo To: linux-ker...@vger.kernel.org Message-Id: Date: Fri, 7 Feb 2020 13:43:34 -0500 Subject: [PATCH] add foo to bar We need bar in foo! Signed-off-by: Konstantin Ryabitsev --- foo | 1

Minimalist public-inbox feed: sendmail-pi-feed

Hi, all: I was trying to create a "simplest possible" way to maintain a public-inbox developer feed, and this is the end-result: https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/sendmail-pi-feed It's written to be used with git-send-email, but can, theoretically, be

Limited-history local archives

Hi, all: I wonder if it would be useful to have a feature allowing someone to run a limited-history local copy of a larger remote archive -- for example if someone only wanted a 3-month copy of LKML instead of the whole 20-year enchilada. It's possible to accomplish this with git already

Filter example for ML footers

Hello: Groups.io adds a super-obnoxious footer to all outgoing messages, and I would like to be able to filter that out. Example: https://lore.kernel.org/keys/2019161300.hc7vb7rcb45gsqmg@chatter.i7.local/ The obnoxious footer can be either part of the main body (default "chaotic evil"

Re: Archiving HTML mail

On Tue, Nov 12, 2019 at 11:10:36PM +, Eric Wong wrote: > > Now that public-inbox-mda supports list-id (THANK YOU!), my life > > moderating PI_EMERGENCY is much easier. For lore.kernel.org, > > emergency collects about a thousand messages a week. My Friday > > afternoon routine is usually to

Re: Archiving HTML mail

On Tue, Nov 12, 2019 at 10:29:32PM +, Eric Wong wrote: > > You have to rewrite the HTML parts anyway, to resolve RFC 2392 cid: > > links, prior to handing them to web browsers. I don't think web > > browsers support them. Neither over HTTP, nor browsing locally. > > Yeah. I guess it could

Re: RFC: monthly epochs for v2

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 complexity; especially for stuff that's not-yet-available on distros.

Re: RFC: monthly epochs for v2

On Thu, Oct 24, 2019 at 08:35:03PM +, Eric Wong wrote: Epoch size should be configurable, yes. But I'm against time periods such as months or years being a factor for rollover. Many inboxes (including this one) can go idle for weeks/months; and activity can be unpredictable if there's

RFC: monthly epochs for v2

Hi, all: With public-inbox now providing manifest files, it is easy to communicate to mirroring services when an epoch rolls over. What do you think if we make these roll-overs month-based instead of size-based. So, instead of: git/ 0.git 1.git 2.git it becomes git/ 201908.git

Re: how's memory usage on public-inbox-httpd?

On Sat, Oct 19, 2019 at 12:11:44AM +, Eric Wong wrote: It's been definitely dramatically better. We keep adding lists to lore, so I haven't really been able to watch memory usage after a long period of daemon uptime, but it's never really gone very much above 1GB. In fact, we're downgrading

Re: how's memory usage on public-inbox-httpd?

On Wed, Oct 16, 2019 at 10:10:45PM +, Eric Wong wrote: This is an old-ish discussion, but we finally had a chance to run the httpd daemon for a long time without restarting it to add more lists, and the memory usage on it is actually surprising: $ ps -eF | grep public-inbox publici+ 17741

Re: [PATCH] TODO: add item for searching based on git-patch-id(1)

On Tue, Oct 01, 2019 at 03:37:47AM +, Eric Wong wrote: > I forgot about this feature when I was implementing > blob-ID-based searches :x > --- > TODO | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/TODO b/TODO > index 2c525615..93054bb3 100644 > --- a/TODO > +++ b/TODO > @@

Re: [PATCH] wwwtext: support $INBOX_URL/_/text/config/raw

On Fri, Sep 27, 2019 at 10:48:25AM +, Eric Wong wrote: This returns a git-config(1)-compatible file to make it easier to get started on mirroring an existing public-inbox. Omitting the "raw" from the URL works, as well, but I'm not sure if it's very useful. This is now live on

Re: Git-only operation mode

On Thu, Sep 26, 2019 at 09:10:25PM +, Eric Wong wrote: If grok-pull is using multiple threads, there can be a race there because parallel runs of public-inbox-init can clobber each other (which needs to be fixed :x) Yes, this is true -- there should be a lockfile in the hook to avoid

Re: Git-only operation mode

On Wed, Sep 25, 2019 at 10:45:00PM +, Eric Wong wrote: A follow-up to that -- is running "public-inbox-index" on the repository after it's been updated enough to update the xapian db? It would be easy to do so as part of the grok-pull post-update hook. Yes, on a fresh clone. You'll need

Re: [PATCH] hlmod: update for highlight 3.51 API change

On Thu, Sep 26, 2019 at 01:59:53AM +, Eric Wong wrote: I had my reservations about relying on highlight.pm; and this confirms them, unfortunately :< Oh well... I was also unable to find highlight.pm anywhere outside of Debian packages. I wonder if pygments or any other code

Re: [PATCH 0/2] leak workarounds for Perl 5.16 on CentOS/RHEL 7

On Thu, Sep 26, 2019 at 01:50:36AM +, Eric Wong wrote: After many hours of reviewing our code in PublicInbox::Qspawn, PublicInbox::GitHTTPBackend, and PublicInbox::HTTP and finding nothing but cleanups and documentation improvements; it seems the leaks affecting lore is down to bugs in Perl

Re: Git-only operation mode

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 idle conversations I had with vger.kernel.org folks was to see if we can shift the

Git-only operation mode

Hello: 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 idle conversations I had with vger.kernel.org folks was to see if we can shift the source of truth archive generation to happen at their

Re: httpd 502s [was: trying to figure out 100% CPU usage in nntpd...]

On Fri, Sep 13, 2019 at 03:12:12AM +, Eric Wong wrote: > > No, it's just vanilla what comes with the source. > > OK, and Perl 5.16.3 from CentOS 7? (4:5.16.3-294.el7_6 RPM) Correct, though another thing that may help is the git version -- we install git2u from IUS, so the git version is not

Accolades from kernel maintainers

Eric and others who have worked on public-inbox: I would like to pass along the heartfelt accolades expressed by the kernel maintainers who are greatly pleased at the improvement in their lives brought on by lore.kernel.org. This is your win, and I join them in thanking you for all your hard

Re: httpd 502s [was: trying to figure out 100% CPU usage in nntpd...]

On Thu, Sep 12, 2019 at 08:35:03AM +, Eric Wong wrote: > Eric Wong wrote: > > One more thing, are you running any extra middlewares in the > > .psgi file? Thanks. No, it's just vanilla what comes with the source. > That's probably not it, I suspected the non-fileno path was > being hit,

Re: httpd 502s [was: trying to figure out 100% CPU usage in nntpd...]

On Wed, Sep 11, 2019 at 05:12:50PM +, Eric Wong wrote: > Konstantin Ryabitsev wrote: > > To give some more data points, downgrading to f4f0a3be still shows a > > number of /tmp/PerlIO* (deleted) entries, but the number of pipes stays > > the same over time. If I switch

Re: httpd 502s [was: trying to figure out 100% CPU usage in nntpd...]

On Wed, Sep 11, 2019 at 02:22:15AM +, Eric Wong wrote: > Btw, some of the changes in public-inbox to use EPOLLET / > EPOLLONESHOT would make it more sensitive to kernel bugs, > and missed wakeups could cause resource exhaustion... > > I just noticed this now: >

Re: trying to figure out 100% CPU usage in nntpd...

On Tue, Sep 10, 2019 at 06:12:24PM +, Eric Wong wrote: > > It does seem like there's perhaps a leak somewhere? > > Probably. Not seeing any of that on my (smaller) instances; > but those -httpd haven't been restarted in weeks/months. > > The "PerlIO_" prefix is created from open(..., '+>',

Re: trying to figure out 100% CPU usage in nntpd...

On Mon, Sep 09, 2019 at 05:53:41PM +, Eric Wong wrote: > Konstantin Ryabitsev wrote: > > There also was a weird problem a couple of days ago where one of the > > httpd daemons started returning "Internal Server Error" to all requests. > > Restarting public-inbox

Re: trying to figure out 100% CPU usage in nntpd...

On Sun, Sep 08, 2019 at 10:52:43AM +, Eric Wong wrote: > I've been having trouble reproducing this bug (but maybe summer > weather has been taking its toll, certainly has on my HW). I did notice the same thing after updating to what was the latest master last week -- the nntpd process was

Re: RFC: marking spam via refs/notes/spam to hide it

On Thu, Jun 27, 2019 at 07:50:11PM +, Eric Wong wrote: This makes sense, thanks. I tried it out and it works to remove spam from the frontend, but spamc step seems to fail with a somewhat incongruous error code: spamc failed with: 18944 Oops, might be $? in Perl needs to be >> 8 to get

Re: RFC: marking spam via refs/notes/spam to hide it

On Thu, Jun 27, 2019 at 07:33:32PM +, Eric Wong wrote: > Aside from the git note, public-inbox-learn already does that: > > public-inbox-learn spam > (scans everything in ~/.public-inbox/config since spam is > frequently cross-posted) Ah, that shows how carefully I read docs, I

Re: RFC: marking spam via refs/notes/spam to hide it

On Thu, Jun 27, 2019 at 06:52:36PM +, Eric Wong wrote: I'm reluctant to delete spam because it rebases the repository -- for large ones this can cause excessive downloads to mirrors. A thought occurred to me -- would it make sense to just hide spam from the frontend? E.g.:

RFC: marking spam via refs/notes/spam to hide it

Greetings: I'm reluctant to delete spam because it rebases the repository -- for large ones this can cause excessive downloads to mirrors. A thought occurred to me -- would it make sense to just hide spam from the frontend? E.g.: public-inbox-hide linux-kernel message@id This would do the

Re: [PATCH 00/11] v2: implement message editing

On Mon, 10 Jun 2019 at 14:57, Konstantin Ryabitsev wrote: > I did a few successful tests on small trial lists, but I'm running into > a problem when I try to actually edit something in (a copy of) LKML: > > $ perl5lib/bin/public-inbox-edit -m messageid /mnt/fastio/lkml > (mutt

Re: [WIP] add more debug tracing around idx_init

On Mon, Jun 10, 2019 at 11:12:20PM +, Eric Wong wrote: Somewhere and get more deep into it w/o tracing mutt. I use the MAIL_EDITOR env, in tests, but am kinda hesitant to document/support it forever; but for now, you can use something like: MAIL_EDITOR="perl -i -p -e 's/^Subject:/Foo:/'"

Re: [WIP] v2writable: support INBOX_DEBUG=replace

On Mon, Jun 10, 2019 at 10:03:20PM +, Eric Wong wrote: Maybe PATCH 14/11 fixes it: https://public-inbox.org/meta/20190610215811.untkksidetf3erf6@dcvr/ It didn't, unfortunately. But that won't get you Linux >=3.15 for OFD locks; so Xapian is probably still using the nasty fork()-based

Re: [PATCH 00/11] v2: implement message editing

On Mon, Jun 10, 2019 at 07:29:05PM +, Eric Wong wrote: I did a few successful tests on small trial lists, but I'm running into a problem when I try to actually edit something in (a copy of) LKML: $ perl5lib/bin/public-inbox-edit -m messageid /mnt/fastio/lkml (mutt opens here) 1 kept, 0

Re: [PATCH 00/11] v2: implement message editing

On Mon, Jun 10, 2019 at 03:40:58PM +, Eric Wong wrote: I just noticed, the status message triggers a perl uninitialized warning with multiple epochs, but it's harmless. Will fix in a bit. I did a few successful tests on small trial lists, but I'm running into a problem when I try to

Re: [PATCH 11/11] edit: new tool to perform edits

On Sun, Jun 09, 2019 at 02:51:47AM +, Eric Wong (Contractor, The Linux Foundation) wrote: +public-inbox-edit - edit messages in a public inbox + +=head1 SYNOPSIS + + public-inbox-edit -m MESSAGE-ID --all|INBOX_DIR + + public-inbox-edit -F RAW_FILE --all|INBOX_DIR [.. INBOX_DIR]

Re: [PATCH 00/11] v2: implement message editing

On Sun, Jun 09, 2019 at 02:51:36AM +, Eric Wong (Contractor, The Linux Foundation) wrote: Some organizations are legally responsible for removing certain content but prefer to edit out sensitive parts of a message instead of purging it completely from history. We can build off existing

Re: how's memory usage on public-inbox-httpd?

On Thu, Jun 06, 2019 at 10:10:09PM +, Eric Wong wrote: > All those endpoints should detect backpressure from a slow > client (varnish/nginx in your case) using the ->getline method. Wouldn't that spike up and down? The size I'm seeing stays pretty constant without any significant changes

Re: how's memory usage on public-inbox-httpd?

On Thu, Jun 06, 2019 at 08:37:52PM +, Eric Wong wrote: Do you have commit 7d02b9e64455831d3bda20cd2e64e0c15dc07df5? ("view: stop storing all MIME objects on large threads") That was most significant. Yes. We're running 743ac758 with a few cherry-picked patches on top of that (like epoch

Re: how's memory usage on public-inbox-httpd?

Hello: This is an old-ish discussion, but we finally had a chance to run the httpd daemon for a long time without restarting it to add more lists, and the memory usage on it is actually surprising: $ ps -eF | grep public-inbox publici+ 17741 1 0 52667 24836 8 May24 ?00:00:00

Re: RFE: default hooks for git repositories

On Mon, Apr 01, 2019 at 06:04:03PM +, Eric Wong wrote: Sorry, Eric, I'm close to declaring email bankruptcy. :) I am okay with any solution that lets us add hooks. To explain why we need hooks in public-inbox repos, it's mostly for the ease of mirroring -- I want a post-update hook to

Re: handling GDPR requests

On Mon, Apr 01, 2019 at 05:55:51PM +, Eric Wong wrote: > Try the -purge tool: > https://public-inbox.org/meta/20190111041008.24361-...@80x24.org/ > > I haven't used it outside of tests, so try it in a throwaway repo, > first :) > > It doesn't need to do a full reindex. And the "rebase"

Re: handling GDPR requests

On Mon, Apr 01, 2019 at 05:55:51PM +, Eric Wong wrote: Well, I have my first GDPR request. What's the recommended mechanism of dealing with that? The message in question dates back to mid-last year and I see two problems with deleting it from the repository: 1. It's in the previous epoch

handling GDPR requests

Hello: Well, I have my first GDPR request. What's the recommended mechanism of dealing with that? The message in question dates back to mid-last year and I see two problems with deleting it from the repository: 1. It's in the previous epoch repo of LKML 2. Deleting/editing that message would

Re: RFE: default hooks for git repositories

On Mon, Mar 18, 2019 at 11:11:52PM +, Eric Wong wrote: Eric Wong wrote: Actually, is there a reason the git-native "init.templateDir" configuration variable isn't sufficient? Ping? Sorry, Eric, I'm close to declaring email bankruptcy. :) I am okay with any solution that lets us add

RFE: default hooks for git repositories

Hello: Since V2 creates git shards automatically, I suggest there should be a way to tell it to install some set of default hooks in all new git repos it creates. The easiest would be by using a skel dir and specifying it in PI_CONFIG: [publicinbox]

Re: [PATCH] v2writable: fix epoch rollover on incremental imports

On Wed, Feb 27, 2019 at 08:25:36PM +, Eric Wong wrote: All of our internal epoch rollover calculations are done using the estimated unpacked (and uncompressed) size of the repo. The importer instance needs to check that unpacked size before selecting an epoch when an epoch already has

Re: V2 shard roll-over

On Wed, Feb 27, 2019 at 12:22:04AM +, Eric Wong wrote: > Eric Wong wrote: > > Konstantin Ryabitsev wrote: > > > Eric: > > > > > > I noticed today that the LKML shard 6 has grown over 1.1 GB, which is the > > > size of other shards (0-5).

Re: [RFC 2/2] www: add /~/$MESSAGE_ID global redirector endpoint

On Fri, 1 Feb 2019 at 04:00, Eric Wong wrote: > Both "_mid" and "~mid" can cause usability problems and > work badly when people try to select part of the URL using > a pointing device. But I guess "/-/" or "/_/" are safe-enough > choices and we can disallow them as inbox names... > > However,

V2 shard roll-over

Eric: I noticed today that the LKML shard 6 has grown over 1.1 GB, which is the size of other shards (0-5). I'm wondering if it will roll over to shard 7 automatically, or if there are other steps that need to be undertaken. Best, -K

Re: [PATCH] TODO: add item for "scraper" importers

On Tue, 5 Feb 2019 at 16:32, Eric Wong wrote: > The git-users mailing list is on Google Groups with obfuscated > addresses and censored archives. We should allow users to > import them soon, as obfuscated/censored archives are better > than not having archives at all when Google decides to shut

Re: [RFC 2/2] www: add /~/$MESSAGE_ID global redirector endpoint

On Sun, 27 Jan 2019 at 07:06, Eric Wong wrote: > > Eric Wong wrote: > > The "/~/" is not finalized, yet. Initially I chose "/_/", but > > it could conflict with valid git remote names. > > Any thoughts on the use of "~"? Thinking about combining this > with the "solver" feature for blob

RFC: Using public-inbox v2 repos for distributed patch lifecycle tracking

Hi, all: Here's something I've been mulling over for a while, and sorta goes hand-in-hand with what Eric has been doing with diff highlights work. We have significant duplication of functionality on lore.kernel.org between the public-inbox repository for LKML and the patchwork instance for the

Re: [PATCH] nntp: header responses use CRLF consistently

On Sat, Jan 19, 2019 at 09:14:15AM +0800, Wang Kang wrote: > Dear Konstantin, > > The problem still exists. (Maybe a Perl 'restart' needed?) It was a bit weirder than that, but I got it sorted out. Try it now. -K

Re: [PATCH] nntp: header responses use CRLF consistently

On Wed, Jan 16, 2019 at 04:58:02AM +, Eric Wong wrote: > Thanks, I'm pretty sure the following will fix it. > > Not sure why others hadn't noticed since there's a lot of Alpine > users judging from Message-IDs. Anyways I managed to replicate it > quickly with alpine in Debian ("alpine -url

Re: [PATCH] t/git.t: avoid passing read-only value to git_unquote

On Fri, Jan 18, 2019 at 07:47:06PM +, Eric Wong wrote: > > Perl: v5.16.3 > > This is Fedora? Which version? I was working on getting a > chroot setup for testing some RPM-based distros, but some of the > mirrors/tools for doing that were out-of-date. Might try > installing in QEMU... No,

Re: RFE: unified message-id lookup across all inboxes

On Tue, Jan 08, 2019 at 01:54:20AM +, Eric Wong wrote: > > It will tell you that the message is in another inbox (it was sent to > > linux-arm-kernel and not cc'd to linux-kernel). The users don't like > > that extra click, so they really just want a "show me the message if > > it's anywhere

RFE: unified message-id lookup across all inboxes

Hello, all: One of the features lore.kernel.org users have been asking for is ability to retrieve a message based on its message-id regardless of which inbox it's in. Perhaps look them up in the order they are listed in the config file and display the first found? The way it works currently is

Re: "IMAP IDLE"-like long-polling "git fetch"

On Sat, Dec 29, 2018 at 03:56:21AM +, Eric Wong wrote: > Hey all, I just added this to the TODO file for public-inbox[1] but > obviously it's intended for git.git (meta@public-inbox cc-ed): > > > +* Contribute something like IMAP IDLE for "git fetch". > > + Inboxes (and any git repos) can be

Re: Corrupted lkml repo?

On Sun, Nov 04, 2018 at 03:50:17AM +, Eric Wong wrote: > > Maybe, but If "git clone" stresses the server to the point of breakage > > as you say, something should be done on the server side. I've been > > using the kernel.org repo as Konstantin suggested. > > Based on Konstantin's message; it

Re: Corrupted lkml repo?

On Tue, Oct 30, 2018 at 03:55:23AM +, Yaron Scheffer wrote: > > Several attempts spread over several days to git clone > > https://lore.kernel.org/lkml/0 > > The process fails with the error "server hung up > unexpectedly", at right about the 100% mark. > > Is anyone else seeing this?

Re: public-inbox-ssoma fails with lkml archive

On Tue, Oct 23, 2018 at 07:21:42AM +, Yaron Scheffer wrote: so the lkml archive doesn't follow (mandatory, I presume) naming scheme as PI/meta. I'm not sure if this is an issue in upstream or the deployment, but right now ssoma doesn't work with the lkml archive. The LKML archive uses the

Re: Stripping multipart/alternative HTML parts instead of rejecting

On Wed, Sep 26, 2018 at 10:42:00PM +, Eric Wong wrote: > Konstantin Ryabitsev wrote: > > How do messages with a HTML part get displayed in the web view? Does it get > > offered as a download, or ignored completely? > > Offered as a text/plain so viewable and downloada

Re: Stripping multipart/alternative HTML parts instead of rejecting

On Wed, Sep 26, 2018 at 07:47:05PM +, Eric Wong wrote: I tried scrubbing undesirable parts when the project started, but it caused signature failures when replaying to mlmmj subscribers, so I started rejecting those mails instead. For pure mirrors, there is "filter =

Stripping multipart/alternative HTML parts instead of rejecting

Hi, all: We've started adding other kernel-related mailing lists to lore.kernel.org, not all of them mailed via vger. This raised the issue of html-alternative parts, which are allowed by other mailing list providers that are using mailman. Such messages are currently rejected outright by

Re: other vger lists on lore?

On Mon, Aug 27, 2018 at 08:50:48PM +, Eric Wong wrote: Hi Konstantin, it looks like lore is going well for LKML :> Any plans to expand to other kernel.org lists? Yeah, this is something I'll be actively promoting soon, but I will be caveating this by requesting that all lists joining

Re: [PATCH] view: distinguish strict and loose thread matches

On 08/06/18 16:05, Konstantin Ryabitsev wrote: > I've updated to ce5494b5b83 and reindexed, but it appears that I still > have the same behaviour as previously: > > https://lore.kernel.org/lkml/20180805.004744.1043412275329854518.da...@davemloft.net/ > > Are there any configur

Re: [PATCH] view: distinguish strict and loose thread matches

s that are required for this? Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature

Re: Threading/searching problem

ave to tweak the ordering for giant threads to > favor newer messages. Gotta run for a bit but should be done > today. No rush, I probably won't get around to it until Monday at the earliest. Thanks for your help! Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature

Threading/searching problem

Hi, all: Something I came over today that seems to be wonky. I was trying to find this message: https://lore.kernel.org/lkml/ca+55afz5ewe9otbzdomfsy2ez04qv9eg0kqhwkfyjy0vfvo...@mail.gmail.com/ It's from Linus about WireGuard, so I searched for it:

Re: Warnings from git fsck after lkml import

previously reported this to Konstantin Ryabitsev who maintains kernel.org but since I have not seen any discussion of this I thought I should report it directly here as well. Thanks for bringing this up publically. Yes, I early during v2 development I noticed old mails had some -1400 timez

Re: Q: V2 format

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 for treat the sqlite msgmap database as precious, > and it

[PATCH] Tweak over.sqlite3 queries for sqlite < 3.8

. As far as I can tell, this change has no impact on systems running newer sqlite3 (>= 3.8). .. [1] https://sqlite.org/optoverview.html#disqualifying_where_clause_terms_using_unary_ Signed-off-by: Konstantin Ryabitsev --- lib/PublicInbox/Over.pm | 8 1 file changed, 4 insertions(+), 4 del

[PATCH v2] Contribute SELinux policy for EL7

for PERL_INLINE_DIRECTORY - /var/log/public-inbox is the location for logs - mail delivery is done via postfix-pipe or public-inbox-watch via the provided example systemd service Signed-off-by: Konstantin Ryabitsev --- contrib/selinux/el7/publicinbox.fc | 8 ++ contrib/selinux/el7/publicinbox.te | 113

Re: Some points on public-inbox

On Tue, Jun 12, 2018 at 10:09:15AM +, Eric Wong wrote: I prefer to use public-inbox-watch for mirroring existing lists. -mda is also a bit strict and opinionated (though I have plans to make it less so, optionally), so it's mainly for non-mirrored inboxes. -watch is also safer and less

Re: [PATCH] respect umask if core.sharedRepository is not set

ult of misunderstanding of how git interprets this. And adjust tests slightly to match the new behavior. Reported-by: Konstantin Ryabitsev <38873789-ab42-65a1-20c9-12c30b171...@linuxfoundation.org> --- lib/PublicInbox/InboxWritable.pm | 2 +- t/search.t | 5 +++-- t/v2w

[PATCH] Contribute SELinux policy for EL7

for PERL_INLINE_DIRECTORY - /var/log/public-inbox is the location for logs - mail delivery is done via postfix-pipe (if you're using public-inbox-watch, you shouldn't need to worry about this) Signed-off-by: Konstantin Ryabitsev <konstan...@linuxfoundation.org> --- contrib/selinux/el7/publicinbox.fc | 7 +++ c

Umask and xapian db file permissions

being able to access the index. Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature

Re: [PATCH 0/4] test fixes for latest CPAN modules

On 05/24/18 04:41, Eric Wong wrote: > Konstantin Ryabitsev <konstan...@linuxfoundation.org> wrote: >> Sorry I missed your reply! Yes, you're correct -- applying the above patch >> makes all tests pass. I'm guessing it's also the reason why I'm seeing the >> "already

Re: [PATCH 0/4] test fixes for latest CPAN modules

On Wed, 16 May 2018 at 01:12, Eric Wong wrote: > Ah, took me a while to realize what was going on :x > The Xapian files processes were lacking O_CLOEXEC and FD_CLOEXEC > usage and this was a problem in Xapian >= 1.2.21 && <= 1.2.24 > Relevant Xapian commit should be

Re: Failed tests on CentOS-7

On 05/10/18 17:51, Eric Wong wrote: > Konstantin Ryabitsev <konstan...@linuxfoundation.org> wrote: >> Hello: >> >> Running "make test" I get the following failures: >> >> t/content_id.t . 1/? >> # Failed test 'content_id

tag v2 (pre-)release in git

Eric: Would you be amenable to adding a v2-specific (pre-)release tag to the git repo? The only tag currently is v1.0.0, and, to make my life a bit easier, I wanted to get a ref to work from that's not just a sha1 jumble of characters. :) Best, -- Konstantin Ryabitsev Director

Re: [v2] introduction of content_id

cause these are donated by individual users and I didn't want to expose their potentially private info. Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature

Re: [PATCH] TODO: notes about v2 format for giant archives

On Thu, Feb 08, 2018 at 03:09:51AM +, Eric Wong wrote: > The other thing is I think we can support is subsystem lists > ({netdev,fsdevel,stable}@vger) in the SAME git repo(s) with a > different head for each list. That could make subsystem lists > cheaper to archive since there's a lot of

Re: Has anyone tried importing lkml?

Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation

Re: Has anyone tried importing lkml?

On 2018-01-15 12:55 PM, Eric Wong wrote: > Konstantin Ryabitsev <konstan...@linuxfoundation.org> wrote: >> The question I do have is whether public-inbox is the right tool for >> doing something like this. LKML message count is somewhere in the >> millions, and I'm c

Has anyone tried importing lkml?

doing this at all, or should we blaze that trail on our own? Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature

<    1   2   3