guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#58140] [PATCH 2/6] gnu: Add kaldi-for-vosk.


From: Maxime Devos
Subject: [bug#58140] [PATCH 2/6] gnu: Add kaldi-for-vosk.
Date: Thu, 29 Sep 2022 11:32:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0



On 29-09-2022 10:20, Nicolas Graves wrote:

Trailing #t haven't been required since a long time.
A big part of the code, and in particular old forms, come from the code
of the current kaldi package. Should I also change the same code chunks
for kaldi in an additional patch ?

That would be nice, but not required I'd say.

If it's Linux only, you can use the 'supported-systems' field for that,
see (gnu packages linux) for examples.
I don't really know that. Ydotool probably only work on Linux, since
they rely on linux keycodes. I don't know for X. Maybe someone should
test. Should I suppose it only supports Linux by default?

I think that usually 'if it works on Linux, it probably can work on similar-ish systems as well’ is a reasonable assumption, but perhaps with the keycodes, it isn't.

However, if the problem is in 'ydotool', you can mention that in the supported-systems of 'ydotool', 'supported-systems' has a kind of implicit transitivity going by the use of package-transitive-supported-systems in (guix ui).

Why select an older version?  Would keeping the original (and more
up-to-date) version work?  To avoid a name conflict between the openfst
(which would be inconvenient for "guix show", "guix install", "guix
shell"), you can override the 'name' field.

No, it doesn't work and that's the reason why I used this version.

In that case, I recommend adding a comment to the definition, to avoid the risk of someone 'helpfully' updating the package anyway, and an upstream report, such that upstream can address the compatibility problems with the new version.

It
might however work with the version that's present for kaldi (1.7.3
IIRC), I can test that. But the flags aren't the same, so we probably
should do another package anyway.

I didn't change the name, but I also haven't exported the variable
(define instead of define-public). I expected the package to not be
available through "guix search" or "guix install". Is that OK?

I suppose it is OK, though personally I think it might be a bit confusing, e.g. to people using "guix shell -D ..." ending up with a package version in their environment that they can't find with "guix search".

Greetings,
Maxime.

Attachment: OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]