Description of problem:
Running through the 'telling the time' tutorial here:
(Which is in summary about making 'saytime' speak with another voice, using the festival voice building tools)
I am finding a whole load of stuff that seems to be missing from the Fedora packaging.
Certainly the absence of 'phonealign', and 'fix_pm' (although 'emulabel' which is also missing, I think is a separate case), are showstoppers for the above.
I'm skipping the rest of the standard template, because I am not really 100% sure it counts as a 'bug' exactly, maybe a packaging problem. You'll just have to forgive me for that. It's late, and I need to be asleep rather than filing bug reports. I will apologise for bundling a load of stuff together under one bug report, though.
On my travels I have noted how to patch several of the programs used in the aforementioned process to work with Fedora's package structure, and can provide those.
However perhaps more pressingly, it seems there are GCC changes (removal of "-fno-shared-data") that prevent parts of the tools being built (which may explain their exclusion), and even after fixing that, there is still need for another path hack to make things build.
There is a patch attached to this Debian bug which will get 'phonealign' and 'fix_pm' to build better:
Thereafter, you need to forcibly add '-I/usr/include/speech_tools' to the relevant Makefiles, and it 'just works' to build the necessary binaries.
I think this stuff should be included, either as part of 'devel', or perhaps a new 'festival-speechtools-voicebuilder' subpackage?
I will help if/where I can with making that happen, as I'm quite averse to building things "the hard way" all the time ;-)
I've also got their 'pointyclicky' UI working with ALSA (and probably can extend this to pulseaudio) and a couple of other improvement patches of my own, which is nice, and maybe worth inclusion as a package.
So, please let me know if this is going to be fixed as a FC package, and if you want me to help with doing so, I guess?
Unfortunately, I have no spare time to work on Festival -- I hope that'll change soon but that's the current state.
When I started working on cleaning up the package a few years ago, my discussions with the Festival developers led me to conclude that the initial focus should be on cleaning up the package as a text-to-speech tool for end users, and that most people using it for more involved work (including research) would probably build their own anyway.
So that's why those things aren't in there. But there's no reason it should stay that way.
Your response reads like what I would say of my other opensource stuff that I wasn't intent on doing more serious research for, which also means it reads like a back-handed request for help ;-)
You're quite right about the balance of users, and indeed that those who would be using it for research would build their own software.
However, it is a pain (*) to do so, and I can't help but feel that may go some way towards explaining why so few people do more with it.
So I'll take the liberty of resolving that down to 'if you submit a revised spec file and source RPM we will probably consider it for inclusion in to FC', and will try and do that if I can, since it will help me and indeed other possible users. If I can package up 'pointyclicky' as well, then so much the better.
Please do correct me if I read this wrong.
*) I've spent a horrendous number of hours trying to even get as far as I have, and too many of those have been fighting with software rather than audio capture hardware.
Created attachment 334676 [details]
Here's a patched-up version of the 'PointyClicky' UI as a .src.rpm.
As mentioned below.
It's a 'first draft' but it should work a lot easier than having to apply the patches, etc. yourself.
I was bored in the extreme and decided to do it at lunch time. Now I am hungry and need to sort that ;-)
Created attachment 334677 [details]
Here is the 'user' version of the previous .src.rpm
... in case a user stumbles upon this before anything else happens.
Ok. I've looked at this, and it seems the existing RPM structure does not actually use the 'festvox-*' source tarball which contains all the stuff you'd need to build your own voice set (and I've checked the likely ones used in your .spec file, which don't seem to either), which rather points in the direction of a separate spec file and package for that if I were to make one and submit it.
Thinking about naming conventions, bundling them together in a package named 'festvox-utils' (without reference to the earlier considered 'buildvoice') would seem to fit better with your inherited convention of naming stuff related to voices as 'festvox*' rather than 'festival*'.
If I understand correctly how the rest of the software works, this would need to be in a different directory (tied with the environment variable FESTVOXDIR), for example using /usr/libexec/festvox-tools/ and tweaking the source files.
Does that way to lay out the package(s) sound agreeable to yours/fedora's philosophy?
Let me know if so, and I'll just make the package up and attach it here.
My plan has been to break the big festival packages into its component parts, at least as much as possible. I haven't worked on it for a couple of years though, unfortunately. The work-in-progress is at:
tcl-assp & libassp are also needed along the way, hence inclusion here.
I've been at this for so long now that I actually forget why, perhaps it is EMU tools?
Created attachment 335218 [details]
libassp src rpm.
Created attachment 335219 [details]
TCL ASSP src rpm./
Created attachment 335223 [details]
First crack of the whip at a festvox-utils package.
Just as it says on the tin.
Package up all the likely-looking files, patch them so they look in just $ESTDIR and not $ESTDIR/bin/ because Fedora is laid out differently.
Created attachment 335224 [details]
Second crack of the whip at a festvox-utils package.
The first one didn't have enough path fixes applied to it, this one should be better.
With the last attached festvox-utils RPM attached, I can successfully do:
Which I could not seem to do before.
That is with:
I have used a define at the top of its spec file in case it needs moving to save confusion of $FESTVOXDIR vs. $ESTDIR.
Seems apparent that there will be some 'stragglers'.
I'll post another version once I've successfully got Festival 'telling the time' and am more sure that the stragglers have been incorporated.
Noted make_mcep to be missing so far, there are probably more.
Created attachment 335227 [details]
This one seems to do it. Third time lucky.
I have been able to successfully test the voice I created for the 'telling the time' demo using the attached version which does include a working make_mcep.
There may need to be some tweaks to 'pointyclicky' to make it save the right parameters into the festival metadata files (one of which I had to fix manually), but that will require starting that process from the beginning to validate, which I'm not up for doing right now.
Ok. Further down the line I note that the festival OALD (Oxford Advanced Learners' Dictionary) is needed for some other examples.
I note that there is a package for it from another distro:
But no Fedora package.
The above package installs no problem on FC10, but installs to a different directory path which is incompatible, and would need a symlink (as root):
ln -s /usr/share/festival/dicts/oald /usr/share/festival/lib/dicts/oald
Further, the CMU dictionary is already included in the main Festival package.
For now I'm going to use that 3rd party RPM and symlink, but it bears discussion as to whether it should be included in FC as a separate RPM, or added to the main 'festival' package, or that the CMU dictionary should be split to a separate "festival-dicts" package.
I leave that up for discussion on or off-ticket as you like.
Oh, the other thing was that the same example references:
Which is not included in any current package, and I am not sure where to suggest or package it myself, because the use of '/src/' in the package implies it to be other than a shell script, but it is actually a shell script just like the other 'programs' included in /usr/libexec/speech-tools/.
However if it is not packaged up under /usr/libexec/speech-tools/src/unitsel/ then it will make people's lives more difficult, even if it may make a mockery of a sensible package naming and directory structure convention to put it there.
Although it is probably useful to note here that the majority of the binaries installed under /usr/libexec/speech-tools/ already come from src/general/ directory of the source distribution, so perhaps artificial moving of binaries has already taken place and needs reverting, reconsidering, or symlinking to?
Other than that, I don't know what to suggest really.
We can't include OALD because it's restricted to non-commercial use.
Fair enough. in regards OALD, but I've not heard back in regards the src/*/ bits and bobs, which is going to become ever more an issue if more festival voice building packages are going to be added to FC.
Anyway, I'm now at the stage of building a 'larger' and more versatile voice, which is going to need more patching of the 'pointyclicky' system mentioned above. I will provide a revised src/user RPM when I have got it to work.
Seems the attached patch (will add momentarily) is needed for the script /usr/libexec/speech-tools/do_build, as per my recent post to the festival mailing list.
It won't work properly with the chosen layout of EST for Fedora (which puts the festival binary in /usr/bin/ but the rest of EST /usr/libexec/speech-tools/) in otherwise.
Created attachment 355142 [details]
Patch to fix path problems in do_build for Fedora.
Here's another file that is built by the process, but not installed:
Should obviously be installed in /usr/libexec/speech-tools/
It's called by bin/make_lpc which is present,and necessary for building a diphone voice, but is not present, so I did a "rpmbuild -bb" and just copied it into place on my system as it's holding up my speech project. That worked, so I assume just adding that to the spec file should do it for this, and that should be quite easy to do as you probably have automated rebuilds ;)
Same a comment #21 applies for "wagon", but during the cl. unit voice 'finalisation' stage. It's looking for it in $ESTDIR/bin/wagon, but that obviously does not exist either.
I can't find out where the reference comes from, but it appears to be built into festival itself somewhere, possibly libFestival.*.
I think I've found it.
The file festvox/src/unitsel/build_clunits.scm needs patching (before building) at line 86 to change:
So that it is compatible with the fedora layout of both $ESTDIR & $FESTVOXDIR being /usr/libexec/speech-tools/
Then there should be no problem for Fedora users to create a clunits voice out of the box, if they have the requisite lack of sanity, and day or three to spare!
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.
Still looking for a maintainer for this stuff?