Hi all! I'm happy to tell you that u-config has been just accepted in 
Debian Unstable :)

See 
<https://lists.debian.org/msgid-search/E1snMMf-00AIVQ-Ot@fasolo.debian.org>.

Thanks again for your work, Chris! Bye :)

This patch adds a small u-config.1 manual page, formatted using the
mdoc(7) language. In order to avoid having to keep up to date both the
manual page and the u-config.c source, the manual page defers to the
`--help` option when it comes to which pkg-config options and
environment variables are supported.

Debian has a policy of always shipping manual pages with binaries in
/usr/bin, hence why I wrote this.
---
Hi! First of all thanks for your work on u-config, it's a really nice 
little tool. I intend to package this for Debian, since I find it useful 
when working on pkg-config files. As also mentioned in the commit 
message, this is the reason why I wrote this. If there's anything 
I should change, please let me know. I'll soon also send this as
[message trimmed]

Il 25 luglio 2024 16:24:25 CEST, Sertonix <sertonix@posteo.net> ha scritto:
>In tests/fmt/test_all_meson_files.meson git is used to search for meson
>files. This doesn't work when running the tests from a tarball. Could this
>be changed to work without a git tree?

Hi, in Debian I've patched this test to use find(1) instead. You can find the patch here: <https://salsa.debian.org/debian/muon-meson/-/commit/884285111e23d598bf0c1cd081a9e90f2e0122a0>

On Mon Jul 22, 2024 at 8:20 PM CEST, Stone Tickle wrote:
> So what I have done is to replace this condition with simply:
>
> ```
> platform = host_machine.system()
> if platform != 'windows'
>     platform = 'posix'
> endif
> ```
>
> This should remove the need for this patch and should hopefully prevent
> issues on other "unknown" platforms.  Platforms that muon supports that
> are not posix compatible may be added as needed.

Hi Vincent,

On Tue Jul 16, 2024 at 5:05 AM CEST, Vincent Torri wrote:
> just for my information, have you tried to bootstrap muon on Hurd with 
> that patch ?

Of course! It built successfully with the latest Debian GNU/Hurd 
release. All tests pass too, apart from the has_function() one; this is 
a known upstream Meson bug in their test suite, according to the patch 
which introduced Hurd into .system(). From 
<https://github.com/mesonbuild/meson/pull/4351>:

> Hurd can't run the project tests because it lacks the primitives to 
> run concurrent.futures, half the tests that do run don't pass because 

The GNU Hurd operating system is mostly POSIX compliant[1], and adding
it to the lists of platforms considered "posix" by muon makes the build
succeed.

[1]: https://www.gnu.org/software/hurd/faq/posix_compatibility.html
---
 meson.build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meson.build b/meson.build
index bbdeb076..16a120cc 100644
--- a/meson.build
+++ b/meson.build
@@ -45,6 +45,7 @@ if (
[message trimmed]

Before this patch, muon would use strtol() when converting a string
representing a 64-bit number. The C standard defines long to only be at
least 32 bits wide, but this doesn't cause issues on Unix-like systems
which use the LP64 data model where longs are 64 bits wide. On other
systems though, like 32-bit systems and Windows, longs are only 32 bits
wide, so it becomes impossible to parse strings containing 64-bit
numbers, even though muon pretended to always use 64-bit integers.

An example makes this pretty clear:

    $ getconf LONG_BIT
    32

    $ cat long.meson
[message trimmed]

Hi Matěj,

On Sun Jul 7, 2024 at 9:07 PM CEST, Matěj Cepl wrote:
> format=flowed emails is another of those things which I would
> love if worked, but they don’t (besides, it doesn’t resolve
> issues, which I see as actual problems … e.g., an inclusion of
> too long URLs in emails, hand-made footnotes I make here are not
> ideal).
>
> A lot of arugments why I think it is a waste of time to even try
> to implement are covered in [1] (many implementations are also
> buggy [2]), but paradoxically even people who claim to support it
> break it openly [3] (no, that isn’t improving of the format, it
> is giving up, RFC3676 email should have 78 characters per line,

Hi all!

RFC 3676, which defines Format=Flowed, also sets some requirements for 
message quoting. Apart from mandating the ">" character, it also 
formalizes the concept of "quote depth". The standards says that "The 
number of ">" characters at the start of the line specifies the quote 
depth", and it really means it; the examples make it clearer:

   When creating quoted flowed lines, each such line starts with the
   quote indicator.

   Note that because of space-stuffing, the lines
       >> Exit, Stage Left
   and

On Mon Feb 20, 2023 at 6:59 PM CET, Robin Jarry wrote:
> Could you please respond to this message stating whether you accept or
> refuse the change of license from MIT to GPL[2] for the aerc project.
> This will only affect future versions of aerc. Existing releases will
> remain with their original license (MIT).

Hi Robin, I don't know if I was Bcc'd or if I received this because I'm
subscribed to aerc-devel, as I only sent a really small patch.

In any case, you're free to relicense my small contribution under the
GPL2, or under the terms of any license of the GPL family if you so
wish.

I look forward to notmuch integration out of the box! Thank you very