Re: On the road to (GNU) debbugs support, some blockers

[Jelle Licht <jlicht@fsfe.org>]

Kyle Meyer <kyle@kyleam.com> 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: <debbugs-submit.debbugs.gnu.org>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=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.