From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms12.migadu.com with LMTPS id uGp0LCzJeWSTtQAATFOONw (envelope-from ) for ; Fri, 02 Jun 2023 12:49:16 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id OHmCKyzJeWQbIwAAG6o9tA (envelope-from ) for ; Fri, 02 Jun 2023 12:49:16 +0200 Received: from mail1.fsfe.org (mail1.fsfe.org [217.69.89.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 884424EBF for ; Fri, 2 Jun 2023 12:49:13 +0200 (CEST) From: Jelle Licht DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fsfe.org; s=2021100501; t=1685702952; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QfPH3TG5R7iODAt1DgmBjHbVV56qKyvWn0cVEEqIPMA=; b=OxP0dLbhjaWH8X2WpjzySkK34389H74DOnQ7PHtqkoEMcyz4fkXEYSaVuktOKdDcmBr2cU D37A2esSQIQRQ6STxn6PmuFo0kbtACB4OFMWDi6G5yjVyMzo+yDP1CS9MJSJY2jBOjuc/c XMTXH8aPJqxijdZioynaXaAY/Ek0/O4= To: Kyle Meyer Cc: piem@inbox.kyleam.com Subject: Re: On the road to (GNU) debbugs support, some blockers In-Reply-To: <87zg5l16yq.fsf@kyleam.com> References: <87y1l9ualg.fsf@fsfe.org> <87zg5l16yq.fsf@kyleam.com> Date: Fri, 02 Jun 2023 12:49:07 +0200 Message-ID: <87o7lyi1gc.fsf@fsfe.org> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Country: DE X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -4.00 Authentication-Results: aspmx1.migadu.com; none X-Migadu-Queue-Id: 884424EBF X-Spam-Score: -4.00 X-TUID: i+TYtlRGf1/M Kyle Meyer writes: > Jelle Licht writes: > >> Thanks for working on piem, and sharing it under a free license! > > You're welcome, and thanks for the feedback. > >> the public-inbox-config man page (`man 5 public-inbox-config') demonstrates a >> url without trailing '/'. Piem's documentation uses an url with trailing '/'. >> >> It seems `piem-b4--get-am-files' assumes this url always has a trailing >> '/', which makes it not work for the examples used in the >> public-inbox-config manpage (and in particular, my pre-existing >> configuration). I'm not unsure if public inbox supports the trailing >> '/', but I see no reason to assume it would not. > > public-inbox does work fine with the trailing slash, but I agree that > piem should not insist on the slash. And confusingly I've been > inconsistent about it: the docstring of piem-inboxes says "this value > must end with a slash" but then several spots tack on a slash if needed. > > I'll work on updating every spot that retrieves a URL to go through a > helper that appends a slash if needed (but I probably won't get a chance > to do that until this weekend). > Thanks for confirming the issue. >> The second issue; in order to map (GNU) debbugs data to inbox >> configurations, the current best way I've worked out is to use the >> X-GNU-PR-Package header. > > Have you tried using :listid? For example, for guix-patches, I use > "guix-patches.gnu.org". I'm using the debbugs.el interface to read the messages, which may-or-may-not present a very idiosyncratic version of the messages: --8<---------------cut here---------------start------------->8--- ... List-Id: List-Archive: List-Post: List-Help: X-GNU-PR-Package: guix-patches ... --8<---------------cut here---------------end--------------->8--- > > If X-GNU-PR-Package is better than List-Id for some users/cases, I'm > open to adding support for it. It should be sufficient to teach > piem-inbox-by-header-match to consider that header (along with an > associated piem-inboxes key). 'Better' is a big word, but the X-GNU-PR-Package header is the only one that is really exposed via the debbugs interface afaics. >> Concretely, I've had to adjust `piem-gnus-get-inbox' to also take this >> particular mail header into account when trying to find matching >> configured inboxes. I am not aware of a way for debbugs users to be able >> to use this, without messing with non-debbugs users of gnus. Advice >> appreciated. > > Hmm, I'm missing how it would mess with non-debbugs messages, at least > in the case of what I mentioned above. X-GNU-PR-Package would be > considered when mapping to an inbox, but, for non-debbugs lists, the > other headers/criteria can still match. Yes, you are correct; it can be a fallback check. I'm currently using the following el-patch function definition in my init.el: --8<---------------cut here---------------start------------->8--- (el-patch-defun piem-gnus-get-inbox () "Return inbox name from a Gnus article" (when (derived-mode-p 'gnus-article-mode 'gnus-summary-mode) (with-current-buffer gnus-original-article-buffer (el-patch-wrap 1 1 (or (piem-inbox-by-header-match) (piem-debbugs-by-header-match)))))) --8<---------------cut here---------------end--------------->8--- It could also just be added directly to the `piem-inbox-by-headers-match' instead. >> Third issue: >> The `piem-gnus-mid-to-thread' seems to prepend a line like: "From >> mboxrd@z Thu Jan 1 00:00:00 1970" to entries. The issue comes up when we >> already have a line that starts with "From " at the top, which after >> running the `replace-regexp-in-string' boils down to something like in >> my generated m-piem file: >> --8<---------------cut here---------------start------------->8--- >> From mboxrd@z Thu Jan 1 00:00:00 1970 >>>>From unknown Sat May 27 07:31:53 2023 >> [rest of file] >> --8<---------------cut here---------------end--------------->8--- > > piem-gnus-mid-to-thread's goal is to construct an mbox (in mboxrd > format) from plain messages. It looks like your input is already an > mbox. > > That's not what I see when using Gnus (Emacs 28.2) with NNTP. For > example, here's the mbox that I get when applying > <87y1l7fb9j.fsf@gnu.org1> from yhetil.gnu.guix.patches: > > $ grep -c '^From mboxrd@z' /tmp/piem-b4-u1rBSW/m-piem > 37 > $ grep '^From ' /tmp/piem-b4-u1rBSW/m-piem | grep -cv mboxrd > 0 > > Can you give more details on your setup? For example, perhaps you're > working with mail rather than NNTP, and gnus-summary-display-article > displays that differently? As mentioned, I use debbugs.el to interact with the issue tracker. [1] Using guix: `guix shell emacs emacs-debbugs -- emacs': Evaluate: `(debbugs-gnu '("serious" "important" "normal") '("guix-patches") nil t)' Go to any issue, and open a message. Then, in the message windows, run: `gnus-summary-show-raw-article' For my chosen message, the buffer starts with: --8<---------------cut here---------------start------------->8--- >From unknown Fri Jun 02 06:31:39 2023 X-Loop: help-debbugs@gnu.org Subject: [bug#63824] [PATCH 0/3] gnu: openocd: Update to 0.12.0. ... --8<---------------cut here---------------end--------------->8--- >> Thanks for any help, and please let me know if you'd be interested >> patches for a (clean) integration with (GNU) debbugs. > > Sure, I'd be happy to review patches for that. Thanks. [1]: Not entirely relevant to the issue at hand, but I also have all guix-patches messages available and indexed in my local notmuch setup. When I use piem-gnus /w my modifcations, in combination with piem-notmuch to apply patches using `piem-b4-am', the relevant messages are actually not even downloaded from the yhetil public inbox, since the messages with the message-ids are already found locally! Really wonderful design and/or some convenient emergent properties of how piem does things.