Sorry, missed it in my pile of emails.

Applied it:

To git.sr.ht:~lanodan/deblob
    4186401..114a215  master -> master

From: "Haelwenn (lanodan) Monnier" <contact@hacktivis.me>

---
 images/freebsd/13.x/genimg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/images/freebsd/13.x/genimg b/images/freebsd/13.x/genimg
index f06eb73..0318a82 100755
--- a/images/freebsd/13.x/genimg
+++ b/images/freebsd/13.x/genimg
@@ -1,3 +1,3 @@
 #!/bin/sh
-export release="13.2-RELEASE"
+export release="13.3-RELEASE"
[message trimmed]

From: "Haelwenn (lanodan) Monnier" <contact@hacktivis.me>

---
 images/freebsd/14.x/genimg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/images/freebsd/14.x/genimg b/images/freebsd/14.x/genimg
index aa3eb86..7caeaf8 100755
--- a/images/freebsd/14.x/genimg
+++ b/images/freebsd/14.x/genimg
@@ -1,3 +1,3 @@
 #!/bin/sh
-export release="14.0-RELEASE"
+export release="14.1-RELEASE"
[message trimmed]

From: "Haelwenn (lanodan) Monnier" <contact@hacktivis.me>

---
 images/freebsd/genimg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/images/freebsd/genimg b/images/freebsd/genimg
index 856930d..40fac1a 100755
--- a/images/freebsd/genimg
+++ b/images/freebsd/genimg
@@ -5,7 +5,7 @@ arch="${1:-amd64}"
 
 dist_base="https://download.freebsd.org/ftp/releases/$arch/$release"
 
[message trimmed]

Nice!  Nearly sent a similar patch to fix compilation with tcc,
so not just a clang thing.

[2024-04-18 14:18:33+0200] Knut Magnus Aasrud:
>> One thing that strikes me as very weird though is the unique-id,
>> not only it's way too short 2^12 = 4096, I think it's reasonable
>> to expect more emails than this.
>
>The hash is 12 bytes, not bits. 2^(8*12)≈8e28 which should be big enough.

Erf, reminds me of why I tend to stick to octet.

And yeah 12 bytes should be enough.

Hi,

Thanks for m2dir I think it solves the issues I have with Maildir as well.

One thing that strikes me as very weird though is the unique-id,
not only it's way too short 2^12 = 4096, I think it's reasonable
to expect more emails than this.

And the collision solving method makes it unsuitable to non-centralised
usage, including folder manipulation done by the email client
itself or moving emails around locally (as the unique-id mustn't
conflict in .meta).

I think something like an UUID using time+random would make the most

[2024-01-22 15:01:55+0100] Armin Preiml:
> query::parse_items should not have the side-effect of writing error
> messages to stdout. It does not fail silently since it returns the
> dupkeys error.

Yeah but that's ignored by secstore/secstore.ha:331 and dupkeys is just !void
so doesn't contains enough information to be useful.

> I think figuring out what keys are duplicates can easily be done by the
> user. Though if this is really a desired feature, the output should be
> done at the tool that uses query::parse. The tool must then figure out
> the duplicates on their own, but then a method to find duplicates could
> be provided by the query module.

From: "Haelwenn (lanodan) Monnier" <contact@hacktivis.me>

Otherwise it would silently abort.
---
 himitsu/query/parse.ha | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/himitsu/query/parse.ha b/himitsu/query/parse.ha
index e9c2722..a44cba8 100644
--- a/himitsu/query/parse.ha
+++ b/himitsu/query/parse.ha
@@ -122,6 +122,18 @@ export fn parse_items(items: []str) (query | error) = {
 	let prev = keys[0];
 	for (let i = 1z; i < len(keys); i += 1) {
[message trimmed]

[2023-12-07 21:42:45-0500] Sebastian:
>On Thu Dec 7, 2023 at 4:29 AM EST, Drew DeVault wrote:
>> I propose that we begin tagging Hare 0.XX.Y versions, for the purpose
>> of improving the relative stability of the ecosystem while Hare begins
>> to be adopted for serious work.
>>
>> The versioning scheme will be a simple date-based scheme for quarterly
>> releases. For instance, if a release were tagged for Q4 2023 (i.e. right
>> now), it would be version 0.23.3, and would be followed by 0.24.0.
>>
>> If this proposal is accepted, the first release would be 0.24.0.
>
>As much as I agree versioned releases would be useful, I think we should
>hold off for a little bit longer. There's quite a few relatively large