public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
* [PATCH] staging: fbtft: replace sprintf with snprintf
@ 2026-06-01  0:43 Enchanted Hunter
  2026-06-01  5:44 ` Greg KH
  2026-06-01  8:25 ` Andy Shevchenko
  0 siblings, 2 replies; 10+ messages in thread
From: Enchanted Hunter @ 2026-06-01  0:43 UTC (permalink / raw)
  To: gregkh; +Cc: linux-staging, andy, dri-devel


[-- Attachment #1.1: Type: text/plain, Size: 177 bytes --]

This patch replaces unsafe sprintf calls with snprintf
infbtft_register_framebuffer() to prevent potential buffer
overflow.Signed-off-by: rat1bor <enchantedredhunter@gmail.com>

[-- Attachment #1.2: Type: text/html, Size: 320 bytes --]

[-- Attachment #2: 0001-staging-fbtft-replace-sprintf-with-snprintf.patch --]
[-- Type: text/x-patch, Size: 1343 bytes --]

From a79c6098f2e8bb2ee9e276d339710522175db977 Mon Sep 17 00:00:00 2001
From: rat1bor <enchantedredhunter@gmail.com>
Date: Mon, 1 Jun 2026 03:18:59 +0300
Subject: [PATCH] staging: fbtft: replace sprintf with snprintf

Signed-off-by: rat1bor <enchantedredhunter@gmail.com>
---
 drivers/staging/fbtft/fbtft-core.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
index ca0c38221c16..66509347255a 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -784,10 +784,11 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
 	fbtft_sysfs_init(par);
 
 	if (par->txbuf.buf && par->txbuf.len >= 1024)
-		sprintf(text1, ", %zu KiB buffer memory", par->txbuf.len >> 10);
+		snprintf(text1, sizeof(text1), ", %zu KiB buffer memory", par->txbuf.len >> 10);
 	if (spi)
-		sprintf(text2, ", spi%d.%d at %d MHz", spi->controller->bus_num,
-			spi_get_chipselect(spi, 0), spi->max_speed_hz / 1000000);
+		snprintf(text2, sizeof(text2), ", spi%d.%d at %d MHz",
+			 spi->controller->bus_num, spi_get_chipselect(spi, 0),
+			 spi->max_speed_hz / 1000000);
 	fb_dbg(fb_info,
 	       "%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
 	       fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] staging: fbtft: replace sprintf with snprintf
  2026-06-01  0:43 [PATCH] staging: fbtft: replace sprintf with snprintf Enchanted Hunter
@ 2026-06-01  5:44 ` Greg KH
  2026-06-04  4:40   ` Claude review: " Claude Code Review Bot
  2026-06-04  4:40   ` Claude Code Review Bot
  2026-06-01  8:25 ` Andy Shevchenko
  1 sibling, 2 replies; 10+ messages in thread
From: Greg KH @ 2026-06-01  5:44 UTC (permalink / raw)
  To: Enchanted Hunter; +Cc: linux-staging, andy, dri-devel

On Mon, Jun 01, 2026 at 03:43:55AM +0300, Enchanted Hunter wrote:
> This patch replaces unsafe sprintf calls with snprintf
> infbtft_register_framebuffer() to prevent potential buffer
> overflow.Signed-off-by: rat1bor <enchantedredhunter@gmail.com>

> From a79c6098f2e8bb2ee9e276d339710522175db977 Mon Sep 17 00:00:00 2001
> From: rat1bor <enchantedredhunter@gmail.com>
> Date: Mon, 1 Jun 2026 03:18:59 +0300
> Subject: [PATCH] staging: fbtft: replace sprintf with snprintf
> 
> Signed-off-by: rat1bor <enchantedredhunter@gmail.com>
> ---
>  drivers/staging/fbtft/fbtft-core.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
> index ca0c38221c16..66509347255a 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -784,10 +784,11 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
>  	fbtft_sysfs_init(par);
>  
>  	if (par->txbuf.buf && par->txbuf.len >= 1024)
> -		sprintf(text1, ", %zu KiB buffer memory", par->txbuf.len >> 10);
> +		snprintf(text1, sizeof(text1), ", %zu KiB buffer memory", par->txbuf.len >> 10);
>  	if (spi)
> -		sprintf(text2, ", spi%d.%d at %d MHz", spi->controller->bus_num,
> -			spi_get_chipselect(spi, 0), spi->max_speed_hz / 1000000);
> +		snprintf(text2, sizeof(text2), ", spi%d.%d at %d MHz",
> +			 spi->controller->bus_num, spi_get_chipselect(spi, 0),
> +			 spi->max_speed_hz / 1000000);
>  	fb_dbg(fb_info,
>  	       "%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
>  	       fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
> -- 
> 2.34.1
> 


Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch was attached, please place it inline so that it can be
  applied directly from the email message itself.

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/process/submitting-patches.rst for what is needed in
  order to properly describe the change.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/process/submitting-patches.rst for what a proper
  Subject: line should look like.

- It looks like you did not use your "real" name for the patch on either
  the Signed-off-by: line, or the From: line (both of which have to
  match).  Please read the kernel file,
  Documentation/process/submitting-patches.rst for how to do this
  correctly.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] staging: fbtft: replace sprintf with snprintf
  2026-06-01  0:43 [PATCH] staging: fbtft: replace sprintf with snprintf Enchanted Hunter
  2026-06-01  5:44 ` Greg KH
@ 2026-06-01  8:25 ` Andy Shevchenko
  2026-06-02 17:12   ` Enchanted Hunter
  1 sibling, 1 reply; 10+ messages in thread
From: Andy Shevchenko @ 2026-06-01  8:25 UTC (permalink / raw)
  To: Enchanted Hunter; +Cc: gregkh, linux-staging, andy, dri-devel

On Mon, Jun 1, 2026 at 3:44 AM Enchanted Hunter
<enchantedredhunter@gmail.com> wrote:
>
> This patch replaces unsafe sprintf calls with snprintf in
> fbtft_register_framebuffer() to prevent potential buffer overflow.
>
> Signed-off-by: rat1bor <enchantedredhunter@gmail.com>

Does this change address any compiler warning or something like that?
At a glance I do not see any usefulness of this patch except an
unneeded churn.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] staging: fbtft: replace sprintf with snprintf
  2026-06-01  8:25 ` Andy Shevchenko
@ 2026-06-02 17:12   ` Enchanted Hunter
  2026-06-02 18:31     ` Andy Shevchenko
  0 siblings, 1 reply; 10+ messages in thread
From: Enchanted Hunter @ 2026-06-02 17:12 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: gregkh, linux-staging, andy, dri-devel

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Overall, it doesn't address any compiler warnings, but this is my first
patch. I wanted to start with something concrete, and I saw an unsafe
function and tried to fix it. The fact that the compilation behavior won't
change is true, but the code will become a bit more formal — maybe that's a
good thing.

пн, 1 июн. 2026 г. в 11:25, Andy Shevchenko <andy.shevchenko@gmail.com>:

> On Mon, Jun 1, 2026 at 3:44 AM Enchanted Hunter
> <enchantedredhunter@gmail.com> wrote:
> >
> > This patch replaces unsafe sprintf calls with snprintf in
> > fbtft_register_framebuffer() to prevent potential buffer overflow.
> >
> > Signed-off-by: rat1bor <enchantedredhunter@gmail.com>
>
> Does this change address any compiler warning or something like that?
> At a glance I do not see any usefulness of this patch except an
> unneeded churn.
>
> --
> With Best Regards,
> Andy Shevchenko
>

[-- Attachment #2: Type: text/html, Size: 1450 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] staging: fbtft: replace sprintf with snprintf
  2026-06-02 17:12   ` Enchanted Hunter
@ 2026-06-02 18:31     ` Andy Shevchenko
  2026-06-02 19:33       ` Enchanted Hunter
  0 siblings, 1 reply; 10+ messages in thread
From: Andy Shevchenko @ 2026-06-02 18:31 UTC (permalink / raw)
  To: Enchanted Hunter; +Cc: gregkh, linux-staging, andy, dri-devel

On Tue, Jun 2, 2026 at 8:13 PM Enchanted Hunter
<enchantedredhunter@gmail.com> wrote:
>
> Overall, it doesn't address any compiler warnings, but this is my first patch. I wanted to start with something concrete, and I saw an unsafe function and tried to fix it. The fact that the compilation behavior won't change is true, but the code will become a bit more formal — maybe that's a good thing.

Not sure we need a churn on the working code.

A process hint: Do not top-post.

> пн, 1 июн. 2026 г. в 11:25, Andy Shevchenko <andy.shevchenko@gmail.com>:
>>
>> On Mon, Jun 1, 2026 at 3:44 AM Enchanted Hunter
>> <enchantedredhunter@gmail.com> wrote:
>> >
>> > This patch replaces unsafe sprintf calls with snprintf in
>> > fbtft_register_framebuffer() to prevent potential buffer overflow.
>> >
>> > Signed-off-by: rat1bor <enchantedredhunter@gmail.com>

Another thing, use your real name and not an alias.

>> Does this change address any compiler warning or something like that?
>> At a glance I do not see any usefulness of this patch except an
>> unneeded churn.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] staging: fbtft: replace sprintf with snprintf
  2026-06-02 18:31     ` Andy Shevchenko
@ 2026-06-02 19:33       ` Enchanted Hunter
  2026-06-03  1:13         ` Andy Shevchenko
  0 siblings, 1 reply; 10+ messages in thread
From: Enchanted Hunter @ 2026-06-02 19:33 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: gregkh, linux-staging, andy, dri-devel

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

I suppose I agree with you. My patch does look silly, and I regret wasting
your time. I've just started learning kernel development. Perhaps if you
happen to have any routine task, you could suggest something that would
actually be worth doing. I'm very interested in this. I will sign with my
real name, but I'm from Russia, and I understand that this might be a big
problem right now.

вт, 2 июн. 2026 г. в 21:32, Andy Shevchenko <andy.shevchenko@gmail.com>:

> On Tue, Jun 2, 2026 at 8:13 PM Enchanted Hunter
> <enchantedredhunter@gmail.com> wrote:
> >
> > Overall, it doesn't address any compiler warnings, but this is my first
> patch. I wanted to start with something concrete, and I saw an unsafe
> function and tried to fix it. The fact that the compilation behavior won't
> change is true, but the code will become a bit more formal — maybe that's a
> good thing.
>
> Not sure we need a churn on the working code.
>
> A process hint: Do not top-post.
>
> > пн, 1 июн. 2026 г. в 11:25, Andy Shevchenko <andy.shevchenko@gmail.com>:
> >>
> >> On Mon, Jun 1, 2026 at 3:44 AM Enchanted Hunter
> >> <enchantedredhunter@gmail.com> wrote:
> >> >
> >> > This patch replaces unsafe sprintf calls with snprintf in
> >> > fbtft_register_framebuffer() to prevent potential buffer overflow.
> >> >
> >> > Signed-off-by: rat1bor <enchantedredhunter@gmail.com>
>
> Another thing, use your real name and not an alias.
>
> >> Does this change address any compiler warning or something like that?
> >> At a glance I do not see any usefulness of this patch except an
> >> unneeded churn.
>
> --
> With Best Regards,
> Andy Shevchenko
>

[-- Attachment #2: Type: text/html, Size: 2495 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] staging: fbtft: replace sprintf with snprintf
  2026-06-02 19:33       ` Enchanted Hunter
@ 2026-06-03  1:13         ` Andy Shevchenko
  2026-06-03  9:14           ` Enchanted Hunter
  0 siblings, 1 reply; 10+ messages in thread
From: Andy Shevchenko @ 2026-06-03  1:13 UTC (permalink / raw)
  To: Enchanted Hunter; +Cc: Andy Shevchenko, gregkh, linux-staging, andy, dri-devel



Please, stop top-posting.

On Tue, Jun 02, 2026 at 10:33:34PM +0300, Enchanted Hunter wrote:
> I suppose I agree with you. My patch does look silly, and I regret wasting
> your time. I've just started learning kernel development. Perhaps if you
> happen to have any routine task, you could suggest something that would
> actually be worth doing. I'm very interested in this. I will sign with my
> real name, but I'm from Russia, and I understand that this might be a big
> problem right now.

I have this [1]. It shouldn't be a problem as long as you are not working for
the OFAC sanctioned entity or tied to them in any ways.


> вт, 2 июн. 2026 г. в 21:32, Andy Shevchenko <andy.shevchenko@gmail.com>:
> 
> > On Tue, Jun 2, 2026 at 8:13 PM Enchanted Hunter
> > <enchantedredhunter@gmail.com> wrote:
> > >
> > > Overall, it doesn't address any compiler warnings, but this is my first
> > patch. I wanted to start with something concrete, and I saw an unsafe
> > function and tried to fix it. The fact that the compilation behavior won't
> > change is true, but the code will become a bit more formal — maybe that's a
> > good thing.
> >
> > Not sure we need a churn on the working code.
> >
> > A process hint: Do not top-post.
> >
> > > пн, 1 июн. 2026 г. в 11:25, Andy Shevchenko <andy.shevchenko@gmail.com>:
> > >>
> > >> On Mon, Jun 1, 2026 at 3:44 AM Enchanted Hunter
> > >> <enchantedredhunter@gmail.com> wrote:
> > >> >
> > >> > This patch replaces unsafe sprintf calls with snprintf in
> > >> > fbtft_register_framebuffer() to prevent potential buffer overflow.
> > >> >
> > >> > Signed-off-by: rat1bor <enchantedredhunter@gmail.com>
> >
> > Another thing, use your real name and not an alias.
> >
> > >> Does this change address any compiler warning or something like that?
> > >> At a glance I do not see any usefulness of this patch except an
> > >> unneeded churn.

[1]: https://gist.github.com/andy-shev/a2cb1ee4767d6d2f5d20db53ecb9aabc

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] staging: fbtft: replace sprintf with snprintf
  2026-06-03  1:13         ` Andy Shevchenko
@ 2026-06-03  9:14           ` Enchanted Hunter
  0 siblings, 0 replies; 10+ messages in thread
From: Enchanted Hunter @ 2026-06-03  9:14 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: Andy Shevchenko, gregkh, linux-staging, andy, dri-devel

[-- Attachment #1: Type: text/plain, Size: 2376 bytes --]

ср, 3 июн. 2026 г. в 04:13, Andy Shevchenko <andriy.shevchenko@intel.com>:

>
>
> Please, stop top-posting.
>
> On Tue, Jun 02, 2026 at 10:33:34PM +0300, Enchanted Hunter wrote:
> > I suppose I agree with you. My patch does look silly, and I regret
> wasting
> > your time. I've just started learning kernel development. Perhaps if you
> > happen to have any routine task, you could suggest something that would
> > actually be worth doing. I'm very interested in this. I will sign with my
> > real name, but I'm from Russia, and I understand that this might be a big
> > problem right now.
>
> I have this [1]. It shouldn't be a problem as long as you are not working
> for
> the OFAC sanctioned entity or tied to them in any ways.
>
>
> > вт, 2 июн. 2026 г. в 21:32, Andy Shevchenko <andy.shevchenko@gmail.com>:
> >
> > > On Tue, Jun 2, 2026 at 8:13 PM Enchanted Hunter
> > > <enchantedredhunter@gmail.com> wrote:
> > > >
> > > > Overall, it doesn't address any compiler warnings, but this is my
> first
> > > patch. I wanted to start with something concrete, and I saw an unsafe
> > > function and tried to fix it. The fact that the compilation behavior
> won't
> > > change is true, but the code will become a bit more formal — maybe
> that's a
> > > good thing.
> > >
> > > Not sure we need a churn on the working code.
> > >
> > > A process hint: Do not top-post.
> > >
> > > > пн, 1 июн. 2026 г. в 11:25, Andy Shevchenko <
> andy.shevchenko@gmail.com>:
> > > >>
> > > >> On Mon, Jun 1, 2026 at 3:44 AM Enchanted Hunter
> > > >> <enchantedredhunter@gmail.com> wrote:
> > > >> >
> > > >> > This patch replaces unsafe sprintf calls with snprintf in
> > > >> > fbtft_register_framebuffer() to prevent potential buffer overflow.
> > > >> >
> > > >> > Signed-off-by: rat1bor <enchantedredhunter@gmail.com>
> > >
> > > Another thing, use your real name and not an alias.
> > >
> > > >> Does this change address any compiler warning or something like
> that?
> > > >> At a glance I do not see any usefulness of this patch except an
> > > >> unneeded churn.
>
> [1]: https://gist.github.com/andy-shev/a2cb1ee4767d6d2f5d20db53ecb9aabc
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
>  I don't work for any organizations that are under OFAC sanctions. Sorry
for the top-posting.

[-- Attachment #2: Type: text/html, Size: 3668 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Claude review: Re: [PATCH] staging: fbtft: replace sprintf with snprintf
  2026-06-01  5:44 ` Greg KH
@ 2026-06-04  4:40   ` Claude Code Review Bot
  2026-06-04  4:40   ` Claude Code Review Bot
  1 sibling, 0 replies; 10+ messages in thread
From: Claude Code Review Bot @ 2026-06-04  4:40 UTC (permalink / raw)
  To: dri-devel-reviews

Overall Series Review

Subject: Re: [PATCH] staging: fbtft: replace sprintf with snprintf
Author: Greg KH <gregkh@linuxfoundation.org>
Patches: 8
Reviewed: 2026-06-04T14:40:17.699184

---

This is a single-patch submission that replaces `sprintf` with `snprintf` in `fbtft_register_framebuffer()` in the staging fbtft driver. The change is functionally correct but has several submission quality issues that would likely result in the patch being rejected in its current form.

**Submission issues:**
1. The patch was sent as a **base64-encoded MIME attachment** rather than inline in the email body. Kernel patches must be sent inline per `Documentation/process/submitting-patches.rst`. Tools like `git send-email` should be used.
2. The **commit message has no body** — the Signed-off-by immediately follows the subject. The cover letter text ("This patch replaces unsafe sprintf calls...") should be the commit message body, not just in the email.
3. The **From name** in the email ("Enchanted Hunter") doesn't match the **Signed-off-by name** ("rat1bor"). The kernel requires a real name for contributions; pseudonyms are generally not accepted.
4. The commit message in the cover letter body has formatting errors: "infbtft_register_framebuffer()" (missing space after "in") and "overflow.Signed-off-by" (missing newline before the tag).

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Claude review: Re: [PATCH] staging: fbtft: replace sprintf with snprintf
  2026-06-01  5:44 ` Greg KH
  2026-06-04  4:40   ` Claude review: " Claude Code Review Bot
@ 2026-06-04  4:40   ` Claude Code Review Bot
  1 sibling, 0 replies; 10+ messages in thread
From: Claude Code Review Bot @ 2026-06-04  4:40 UTC (permalink / raw)
  To: dri-devel-reviews

Patch Review

**Correctness: The change is functionally correct.**

The buffers are declared at line 734-735:
```c
char text1[50] = "";
char text2[50] = "";
```

The patch correctly uses `sizeof(text1)` and `sizeof(text2)` as the size arguments, which resolve to 50 since these are stack-allocated arrays (not pointers). The format strings and arguments are preserved correctly.

**Observations:**

1. **Low practical risk from the original code**: The `text1` format `", %zu KiB buffer memory"` with a `size_t` value shifted right by 10 bits will produce at most ~30 characters (e.g. `", 4294967295 KiB buffer memory"` is 31 chars). Similarly, `text2` with `", spi%d.%d at %d MHz"` will realistically fit well within 50 bytes. There is no actual buffer overflow risk here — the `sprintf` calls are safe given the buffer sizes and value ranges. This is a cleanup, not a bug fix, despite the commit message claiming "potential buffer overflow."

2. **Preferred kernel alternative**: The current kernel community preference for this kind of cleanup is `scnprintf()` rather than `snprintf()`. `scnprintf()` returns the number of characters actually written (excluding the null terminator), which is generally more useful and avoids off-by-one confusion with the return value. However, since the return values are not used here, `snprintf()` is functionally equivalent and acceptable.

3. **Style nit**: The reformatted `snprintf` for `text2` has correct alignment — the continuation arguments are aligned to the opening parenthesis, which follows kernel coding style.

**Verdict**: The code change itself is fine as a minor cleanup, but the patch would need to be resubmitted with: (a) a proper commit message explaining the rationale, (b) the patch sent inline (not as an attachment), (c) a real name on the Signed-off-by, and (d) use of `git send-email`. The commit message should also not overstate the risk — this is a style/hardening cleanup, not fixing an actual overflow.

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2026-06-04  4:40 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-01  0:43 [PATCH] staging: fbtft: replace sprintf with snprintf Enchanted Hunter
2026-06-01  5:44 ` Greg KH
2026-06-04  4:40   ` Claude review: " Claude Code Review Bot
2026-06-04  4:40   ` Claude Code Review Bot
2026-06-01  8:25 ` Andy Shevchenko
2026-06-02 17:12   ` Enchanted Hunter
2026-06-02 18:31     ` Andy Shevchenko
2026-06-02 19:33       ` Enchanted Hunter
2026-06-03  1:13         ` Andy Shevchenko
2026-06-03  9:14           ` Enchanted Hunter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox