On Fri Oct 25, 2024 at 5:13 PM CEST, Santiago Vila wrote:
> What I see is that the top level meson.build has subdir('doc') and 
> doc/meson.build has a reference to meson-docs, which apparently is 
> setup in a way that meson-docs may be either present or missing.
>
> The error happens when genrefman.py is invoked in meson-docs:
>
> /<<PKGBUILDDIR>>/build/muon internal exe -e /<<PKGBUILDDIR>>/build/.muon/custom_tgt_env/meson_reference_33_dat -- ../subprojects/meson-docs/docs/genrefman.py -q -l fastyaml -g man -o subprojects/meson-docs/meson-reference.3 --no-modules
> /bin/sh: 1: /<<PKGBUILDDIR>>/build/muon: Permission denied

I believe this is just a misleading log message due to the parallel 
execution of build targets. I suspect the genrefman target is invoked at 
the same time as the linking step which overwrites build/muon, and fails 
to run since build/muon is currently being written to. Try to replace

Hi Santiago,

On Thu Oct 24, 2024 at 1:43 PM CEST, Santiago Vila wrote:
> I think this is a Debian bug, which adds "meson-docs" to
> the build but without extra dependencies:
>
> override_dh_auto_build:
> --->    ln -s ../meson-docs subprojects/
>          CC="$(CC_FOR_BUILD)" CFLAGS="$(CPPFLAGS_FOR_BUILD) $(CFLAGS_FOR_BUILD)" LDFLAGS="$(LDFLAGS_FOR_BUILD)" ./bootstrap.sh build
>          build/muon setup -Dprefix=/usr -Dsamurai=disabled -Dreadline=bestline build
>          ninja -C build --verbose

How does this create issues? Upstream's build system already downloads 
the meson-docs wrap into the subprojects directory on demand. Here I'm

On Thu Oct 17, 2024 at 9:57 AM CEST, Andrea Pappacoda wrote:
> I'd still like to figure out what is really happening here though.

By looking closer at the logs[1], my guess is that the 
`subprojects/meson-docs/meson-reference.3` target, which is the 122th 
out of 123, runs at the same time as the 123th target, which links 
together the final muon executable. So you have:

- target 122 executing build/muon
- target 123 overwriting build/muon with the final version

So target 122 fails to run because build/muon is modified at the same 
exact time.

On Fri Sep 27, 2024 at 12:17 PM CEST, Stone Tickle wrote:
> Can't you just download
> https://muon.build/releases/v0.3.0/muon-v0.3.0.tar.gz?  This tarball
> should not change and is what I based the alpine package on.

I could import that directly, yes, but Debian's usual way of doing this 
is to have a "watch file" which watches a particular web page (or JSON 
API) looking for new upstream versions and notifies you when a newer 
release is detected.

>> Possible solutions would include changing <https://muon.build/releases/> to
>> return a single JSON body with all the information
>
> This would be nice, but I'm currently serving the json with nginx using

On Tue Sep 24, 2024 at 11:26 PM CEST, Stone Tickle wrote:
> muon 0.3.0 has been released!

Nice!

I'm having issues upgrading the package in Debian though, as I can't 
find any programmatic way to download a release tarball from either the 
website or the <https://git.sr.ht/~lattis/muon/refs> webpage. The former 
has started requiring JavaScript since commit 
3433df0b5b651a6953dae7a99bc92795b13982a8, and the tool we use in Debian 
to exctract download link from web pages does not support it, while the 
latter doesn't work properly as download links are in the form of 
<https://git.sr.ht/~lattis/muon/archive/COMMIT_HASH.tar.gz> instead of 
archive/TAG.tar.gz, and can't be properly sorted.

Hi Michal,

On Tue Sep 24, 2024 at 2:56 PM CEST, Michal Sieron wrote:
> When muon uses pkgconfig info to populate dependency data, it parses 
> Cflags entry and splits it into include_directories and other flags.
> This is different from meson, which puts everything in flags for 
> compilation.
>
> This difference causes LXC not to compile properly after configuring 
> with muon, as LXC uses dep.partial_depencency(compile_args: true) to 
> add include dirs to different targets.
> I confirmed that modifying it to also set `includes: true` fixes the 
> issue, but it doesn't change the fact this behavior differs from 
> meson.

Il 19 settembre 2024 15:20:09 CEST, Stone Tickle <lattis@mochiro.moe> ha scritto:
>By the way, this should now be fixed.  The new tests shouldn't have a
>dependency on git.

Nice to hear, thanks!

Hi Alessandro,

On Mon Sep 9, 2024 at 11:52 AM CEST, Fabio Alessandro 'Fale' Locati 
wrote:
> Personally I would already be happy if my recipients receive the email 
> with a "From:" field without backscapes.

I think this isn't universally possible. I'm not an email expert, but 
reading RFC 5322's ABNF rules for the From field, together with 
additional comments, it seems that double quotes ('"') can't be easily 
added in a way which get shown on all email clients. Here is the 
relevant ABNF (I've left out the "-obs" rules to reduce the size of the 
quoted parts, since they are obsolete anyway):

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]