GNU bug report logs -
#58140
Simple offline text-to-speech incoming !
Previous Next
Full log
Message #71 received at 58140 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]
[OpenPGP_signature (application/pgp-signature, attachment)]
This bug report was last modified 2 years and 278 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.