bug#55069: Add some means to find LV2 plugins

[Maxime Devos]

> [PATCH] gnu: mda-lv2: Remove unnecessary search-path-specification.

Isn't it currently necessary?  Because lv2 doesn't have a LV2_PATH
search path yet.

Nathan Dehnel schreef op vr 22-04-2022 om 17:13 [-0500]:
> It seems DAWs and plugins can't find each other because there is no
> way to find the plugins outside of the store because there is no
> directory where the plugins are aggregated, and $LV2_PATH isn't set.

I think this would be resolved by adding the search path to the 'lv2'
package (and removing it from lv2-mda-piano, mda-lv2 and calf).

> [PATCH] gnu: Add invada-studio-plugins-lv2.
> [PATCH] gnu: Add distrho-ports-lv2.
> [PATCH] gnu: Add omins-lv2.
> [PATCH] Add drumgizmo

The convention is to add the search paths to the users of the plugins,
not the plugins theirselves.  Cf. GUILE_LOAD_PATH, LIBRARY_PATH,
MINETEST_MOD_PATH, EMACSLOADPATH, INFOPATH ...  See
.

The benefit is that this avoids forgetting LV2_PATH for some plugins,
as it only needs to be added to relatively few places (lv2 itself,
maybe guitarix, maybe ir, arour ...).

Greetings,
Maxime


signature.asc
Description: This is a digitally signed message part

bug#55059: bug in `guix pull`

[Holden Green]

guest@gnu ~/tmp/1$ guix pull
Updating channel 'guix' from Git repository at '
https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to eb34ff1 (17,927 new
commits)...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git eb34ff1
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
building /gnu/store/sflmgcfcdwizj7iyd3pfksdvrkc3pskb-config.scm.drv...
building /gnu/store/7k17dvmcrdicjsdxmpvhss4p3i3d70j5-git.scm.drv...
building /gnu/store/j9s3n7iqvh8pqkxkwy91nq3qynr1nby7-hash.scm.drv...
building /gnu/store/4cbz087cfn1kqmkjqw69vm4zcz5n01i8-module-import.drv...
building /gnu/store/nklbz5qhr7r4lpp2by9lp43ky8a0bl09-module-import.drv...
building
/gnu/store/c6s5105fvkcwcwcnlqy4n312gkam1db6-module-import-compiled.drv...
building
/gnu/store/dzbh008q3mm3rkmhq5j3sgxxhz87dfw1-module-import-compiled.drv...
building
/gnu/store/1hs5ayhrc34gf1l85mv85x08xpx3ckwd-compute-guix-derivation.drv...
Computing Guix derivation for 'x86_64-linux'... /guix pull: error: You
found a bug: the program
'/gnu/store/lb30npcazqfbw8cbkk9kf8pcf17c2sl6-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"eb34ff16cc9038880e87e1a58a93331fca37ad92"; system: "x86_64-linux";
host version: "1.3.0-1.771b866"; pull-version: 1).
Please report the COMPLETE output above by email to .

bug#54941: No such file or directory when running a binary

[Maxime Devos]

Haider Mirza schreef op wo 20-04-2022 om 20:46 [+0100]:
> > (This is not to accuse you Haider, who I don't know, of probing
> Maxime
> > -- but consider the seemingly casual example you are setting for
> noobs
> > in suggesting running an unknown (to others) binary).
> 
> Sorry about that, usually Github Repositories ask for some way to
> reproduce a bug so they can try and debug it. I had expected him to
> have ran the binary in a VM. But like you said it might not be
> apparent to the less experienced. 

Where does the ‘him’ come from?  I don't think I've ever implied that
pronoun.

Also, while making a VM, installing some OS, downloading a binary
inside and running it inside, is definitely technically possible, I
consider it time better spent doing other things with a (to me) higher
value / cost (e.g. reviewing a package definition for ld50-silent-
syphoon, investigating actual bugs(*), some infrastructure patches
...).

(*) Only binaries made from within Guix can feasibly be supported by
Guix, though some separate entities aim to support this to some degree.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#42164: Combining file-append with gexps results in incomprehensible errors

[Brian Cully]

I was having a similar issue, so I dug into this issue a bit,
and it turns out that you *can* select an output from file-append, but
the syntax is a bit wonky:

---[snip]---
(let ((fa (file-append pkg "/path")))
  $~$#fa:output)
---[snip]---

I’ve tried to remove the let:

---[snip]---
$~$#(file-append pkg "/path"):output
---[snip]---

But this confuses the reader, an it things ‘:output’ is a
variable. Not too surprising, but it does make the Guix configuration
files more awkward, since now you have to ‘define’ the file-append
operations at the top level so you can refer to them with the syntax
above.

I would prefer to have something like any of the following (in
order of preference):

---[snip]---
(file-append pkg:output "/path")
(file-append (list pkg "output") "/path")
(file-append $~$#pkg:output "/path")
---[snip]---

The reason being that it’s awkward to select the output after
the file-append due to syntax, and it’s less intuitive than trying to
select the output directly from the package inside the file-append (and
it seems I’m not alone in this). I’ve been through the code, so to some
degree I realize why things are being done the way they are, but that
doesn’t change my current preferences.

I prefer the list over the gexp/ungexp because we already use
lists to select outputs in other parts of the config declarations, and
the gexp/ungexp stuff is harder to understand from the point-of-view of
a user, rather than package author. It’s also not present in the
majority of configs, I’d wager.

Before I found the “correct” way to do things, I did cobble
together some code that allowed the (list pkg "output") form to work,
and would be happy to submit it upstream. It’s not perfect, since it
ignores the ‘output’ argument in the gexp expander in favor of the
stored output in the file-append, but I don’t think that’s an actual
issue in practice.

-bjc

bug#42164: Combining file-append with gexps results in incomprehensible errors

[Maxime Devos]

Brian Cully schreef op za 23-04-2022 om 12:03 [-0400]:
>   I was having a similar issue, so I dug into this issue a bit,
> and it turns out that you *can* select an output from file-append, but
> the syntax is a bit wonky:
> 
> ---[snip]---
> (let ((fa (file-append pkg "/path")))
>   $~$#fa:output)
> ---[snip]---
> 
>   I’ve tried to remove the let:
> 
> ---[snip]---
> $~$#(file-append pkg "/path"):output
> ---[snip]---

Do you mean #~#$fa:output here?

> 
>   But this confuses the reader, an it things ‘:output’ is a
> variable. Not too surprising, but it does make the Guix configuration
> files more awkward, since now you have to ‘define’ the file-append
> operations at the top level so you can refer to them with the syntax
> above.
> 
>   I would prefer to have something like any of the following (in
> order of preference):
> 
> ---[snip]---
> (file-append pkg:output "/path")

This one is only possible if file-append becomes syntax instead of a
procedure.

> (file-append (list pkg "output") "/path")

Possible, but seems semantically wrong to me -- what's a list doing in
a file-manipulating procedure?

> (file-append $~$#pkg:output "/path")

I assume this would be #~#$pkg:output?

My bikeshed proposal:

  (file-append (output glibc "static") "/lib/...")

Here, 'output' is a procedure constructing some kind of object.
This would also be useful outside 'file-append', as it allows
programmatically constructing equivalents #~#$pkg:output for multiple
'output' (there was some package definition some while back where this
would have been useful).

This 'output' could perhaps also be used in 'inputs' / 'native-inputs'
fields.  YMMV.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#42164: Combining file-append with gexps results in incomprehensible errors

[Maxime Devos]

Brian Cully schreef op za 23-04-2022 om 13:29 [-0400]:
>   I like this, and would prefer it over the ‘list’ proposal. I’m
> not sure how to implement it given my limited knowledge of Guix
> internals, though. Special-casing a list inside of file-append was
> fairly straightforward and solved the immediate issue.

Proposed implementation:

(define (output thing output)
  (gexp-input package output))

Seems like this thing already exists, it's just not well-known and not
documented in the manual.

Greetings,
Maxime


signature.asc
Description: This is a digitally signed message part

bug#42164: Combining file-append with gexps results in incomprehensible errors

[Maxime Devos]

Brian Cully schreef op za 23-04-2022 om 16:40 [-0400]:
>   Where is this in the code?

Nowhere.  I tried implementing 'output', and noticed I just ended up
with something equivalent to a simple call to 'gexp-input' (hence,
‘this thing already exists’).  'gexp-input' can be found in (guix
gexp).

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#42164: Combining file-append with gexps results in incomprehensible errors

[Brian Cully]

Maxime Devos  writes:

> Proposed implementation:
>
> (define (output thing output)
>   (gexp-input package output))
>
> Seems like this thing already exists, it's just not well-known and not
> documented in the manual.

Where is this in the code? I couldn’t find it myself (grepping
for these keywords turns up a lot of false positives). On the off chance
it might work, I did try ‘(file-append (output pkg "lib") "/path")’ and
was told that ‘output’ is an unbound variable.

-bjc

bug#42164: Combining file-append with gexps results in incomprehensible errors

[Brian Cully]

Maxime Devos  writes:

> Do you mean #~#$fa:output here?

Yes, I did. Sorry, my fingers have minds of their own, and the
gexp syntax, in particular, really runs counter to their memory.

>> (file-append pkg:output "/path")
>
> This one is only possible if file-append becomes syntax instead of a
> procedure.

I did not expect this to be particularly possible, but I find it
aesthetically and intuitively pleasing enough to propose it anyway.

>> (file-append (list pkg "output") "/path")
>
> Possible, but seems semantically wrong to me -- what's a list doing in
> a file-manipulating procedure?

It need not be a list, but I do think it makes sense inside the
file-append, rather than a modification to file-append’s results, as is
currently the case. I picked list because it was being used elsewhere to
explicitly select a derivation’s output.

> My bikeshed proposal:
>
>   (file-append (output glibc "static") "/lib/...")
>
> Here, 'output' is a procedure constructing some kind of object.
> This would also be useful outside 'file-append', as it allows
> programmatically constructing equivalents #~#$pkg:output for multiple
> 'output' (there was some package definition some while back where this
> would have been useful).
>
> This 'output' could perhaps also be used in 'inputs' / 'native-inputs'
> fields.  YMMV.

I like this, and would prefer it over the ‘list’ proposal. I’m
not sure how to implement it given my limited knowledge of Guix
internals, though. Special-casing a list inside of file-append was
fairly straightforward and solved the immediate issue.

I’d be happy to take a look at implementing this, but I’m a bit
clueless where to begin, as it’s much more general than my previous
attempt. If you (or others) have the time, I’d appreciate any pointers
that’d make it easier to begin.

For instance: I would expect the ‘output’ form to be lowerable,
which would be done in the ‘compile’ branch of a gexp-compiler, but then
it would have to be expanded later in the ‘expand’ branch, which
presents an issue: the third argument to the expander procedure is
already an output. Would we do away with that argument? Somehow fill it
in based on the ‘output’ form (either expressed or implicit)? Let the
‘output’ form, if present, override it?

-bjc

bug#55089: [IceCat and IceDove]: Doesn't use system's locale/timezone.

[Raghav Gururajan via Bug reports for GNU Guix]

Hello Guix,

It appears that the applications IceCat and IceDove doesn't follow 
system's locale/timezone. By default, it uses UTC.


This is observed in Guix System and not sure about foreign distros.

Regards,
RG.


OpenPGP_signature
Description: OpenPGP digital signature

bug#55089: [IceCat and IceDove]: Doesn't use system's locale/timezone.

[bdju]

On Sun Apr 24, 2022 at 1:06 AM CDT, Raghav Gururajan via Bug reports for GNU 
Guix wrote:
> Hello Guix,
>
> It appears that the applications IceCat and IceDove doesn't follow 
> system's locale/timezone. By default, it uses UTC.
>
> This is observed in Guix System and not sure about foreign distros.
>
> Regards,
> RG.

In IceCat at least I believe this is due to the resistfingerprinting
about:config setting. Not sure about IceDove. I have noticed a similar
issue with w3m, though. It doesn't match my system's time.