Description of problem: The festival server returns: SIOD ERROR: could not open file speech-dispatcher.scm when running: spd-say "Testing test testings" Version-Release number of selected component (if applicable): speech-dispatcher.x86_64 0.10.2-2.fc34 @fedora speech-dispatcher-festival.x86_64 0.10.2-2.fc34 @fedora festival.x86_64 2.5.0-14.fc34 festival-freebsoft-utils.noarch 0.10-21.fc34 @updates How reproducible: always Steps to Reproduce: 1. Set speed-dispatcher to use festival 2. run: sudo festival --server 3. run: spd-say "Testing test testings" Actual results: $ sudo festival --server client(4) Wed Oct 27 00:04:46 2021 : accepted from localhost SIOD ERROR: could not open file speech-dispatcher.scm client(4) Wed Oct 27 00:04:46 2021 : disconnected Expected results: To not see ERROR. Additional info: I have found a similar bug from years ago: https://bugzilla.redhat.com/show_bug.cgi?id=484577 Also: $ sudo find / -name "speech-dispatcher.scm" /usr/share/festival/lib/speech-dispatcher.scm
Here to chime in that I experienced this same issue and resolved it by downloading every file ending in .scm to the directory /usr/share/festival. They were all necessary, I downloaded them one by one to satisfy each new "could not open file" error message in the misguided belief that maybe I wouldn't need to wget them all individually and this one'll be the last one. I downloaded them all from this repo: https://github.com/brailcom/festival-freebsoft-utils Which I found by googling the filename. These .scm files were all apparently required for festival to function, perhaps these should be included in the speech-dispatcher-festival installl?
Same issue here. This is an interoperability problem between festival and festival-freebsoft-utils, therefore I'm CC'ing @music, who owns the latter package. festival expects the .scm modules to be installed in /usr/share/festival festival-freebsoft-utils installs their .scm modules into /usr/share/festival/lib (In reply to David Yang from comment #1) > Here to chime in that I experienced this same issue and resolved it by > downloading every file ending in .scm to the directory /usr/share/festival. > They were all necessary, I downloaded them one by one to satisfy each new > "could not open file" error message in the misguided belief that maybe I > wouldn't need to wget them all individually and this one'll be the last one. > I downloaded them all from this repo: > > https://github.com/brailcom/festival-freebsoft-utils Easier workaround: > cd /usr/share/festival/lib > gio copy *.scm ..
Whoops, can confirm that I also have a /usr/share/festival/lib that contains the files, missed that in my troubleshooting
I took over maintenance of the festival-freebsoft-utils package only recently, after it was orphaned, so I did a little research. It looks like festival-freebsoft-utils has always installed to %{_datadir}/festival/lib. Meanwhile, the changelog message for festival 2.5.0-6 (2018-09-09) includes “Drop lib from %{_datadir}/festival/lib”. That was committed when festival was unretired[1], and it appears to be the origin of the incompatibility. ----- The Texinfo documentation for Festival says [1]: > @example > $ bin/festival > Festival Speech Synthesis System 1.4.3:release Jan 2003 > Copyright (C) University of Edinburgh, 1996-2003. All rights reserved. > For details type `(festival_warranty)' > festival> ^D > @end example > If errors occur at this stage they are most likely to do > with pathname problems. If any error messages are printed > about non-existent files check that those pathnames > point to where you intended them to be. Most of the (default) > pathnames are dependent on the basic library path. Ensure that > is correct. To find out what it has been set to, start the > system without loading the init files. > @example > $ bin/festival -q > Festival Speech Synthesis System 1.4.3:release Jan 2003 > Copyright (C) University of Edinburgh, 1996-2003. All rights reserved. > For details type `(festival_warranty)' > festival> libdir > "/projects/festival/lib/" > festival> ^D > @end example > This should show the pathname you set in your @file{config/config}. Indeed, festival-2.5.0-filesystem-standard.patch sets default_libdir and default_datadir both to /usr/share/festival, and we can confirm: > $ festival > > Festival Speech Synthesis System 2.5.0:release December 2017 > Copyright (C) University of Edinburgh, 1996-2010. All rights reserved. > > clunits: Copyright (C) University of Edinburgh and CMU 1997-2010 > clustergen_engine: Copyright (C) Carnegie Mellon University 2005-2017 > hts_engine: All rights reserved. > For details type `(festival_warranty)' > festival> libdir > "/usr/share/festival" No spec file other than festival and festival-freebsoft-utils contains the string “festival/lib”. I tried the above check on EL9, and got "/usr/share/festival" for libdir. There is currently no festival on EL8. On EL7, libdir is still "/usr/share/festival". ----- Based on all of that, it seems like it would be correct to adjust festival-freebsoft-utils to install directly into /usr/share/festival, on all branches except EPEL7. [1] https://src.fedoraproject.org/rpms/festival/c/f48d9894?branch=f48d9894 [2] https://github.com/festvox/festival/blob/master/doc/festival.texi#L1073 [3] https://src.fedoraproject.org/rpms/festival/blob/d5a56acb3cef074af8ae27106a7a3cb2a27cd2c4/f/festival-2.5.0-filesystem-standard.patch
I reproduced the report locally (thanks for the directions; I’m not a speech-dispatcher user) and confirmed that server does not report an error with the proposed fix. I’ll start pushing updates shortly; testing is appreciated!
FEDORA-2022-5b55863266 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-5b55863266
FEDORA-2022-5b55863266 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-c39206093c has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c39206093c
FEDORA-2022-ff27385487 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-ff27385487
FEDORA-2022-eb6bd67aa1 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-eb6bd67aa1
FEDORA-EPEL-2022-c791bb34c8 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c791bb34c8
FEDORA-EPEL-2022-6a3a9bf070 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-6a3a9bf070
FEDORA-2022-c39206093c has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-c39206093c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c39206093c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-c791bb34c8 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c791bb34c8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-ff27385487 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-ff27385487` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ff27385487 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-eb6bd67aa1 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-eb6bd67aa1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-eb6bd67aa1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-6a3a9bf070 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-6a3a9bf070 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-c791bb34c8 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-eb6bd67aa1 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-ff27385487 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2022-6a3a9bf070 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-c39206093c has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.