Hello Nathan, or anyone else affected, Accepted speech-dispatcher into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/speech- dispatcher/0.11.4-2ubuntu0.1 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-lunar. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: speech-dispatcher (Ubuntu Lunar) Status: New => Fix Committed ** Tags added: verification-needed verification-needed-lunar -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to speech-dispatcher in Ubuntu. https://bugs.launchpad.net/bugs/1991022 Title: [SRU] Service activation via Systemd socket Status in speech-dispatcher package in Ubuntu: Fix Released Status in speech-dispatcher source package in Jammy: New Status in speech-dispatcher source package in Kinetic: Fix Committed Status in speech-dispatcher source package in Lunar: Fix Committed Bug description: [Description] Systemd socket activation for Speech Dispatcher. - Creates the speech-dispatcher.socket; - Modifies the server so that it can detect it was automatically launched by that socket activation; and - Modifies the Autotools files accordingly. [Impact] Its relevance is described in [1], of which I quote the essential parts [my notes in brackets]: > Sandboxed applications [snaps] that use Speech Dispatcher currently bundle it inside of the sandbox, so that each application has its own "private" instance of Speech Dispatcher running. This works more or less, but it has the downside that speech dispatcher cannot coordinate simultaneous messages from multiple apps. When multiple sandboxed apps use Speech Dispatcher at the same time, the text reading overlaps. > > In order to solve this issue, I would really like to give sandboxed apps access to the Speech Dispatcher instance of the host. That can be done by implementing the action of the speech dispatcher service via a Systemd socket: > The only issue I see is having it auto launch. I think it would probably be a good step forward for speech-dispatcher to be auto launched by a systemd socket like other daemons already do on demand. That way the host speech-dispatcher with it's configuration would be used by all snaps, [Additional information] The changes are already merged upstream[21][22][23], but still not released. I have built and installed the package in Mantic and verified that running spd-say from inside a snap causes the host's dispatcher to spawn and emit sound — see 'Test case' for more details. This has also been verified in Jammy by Lissyx[31][32] and there is a merge proposal[4] for the Firefox snap that assumes the incorporation of this delta in speech-dispatcher. Note: Either the installed socket needs to be started manually to function correctly or the session must be restarted or the system needs to be rebooted. [Test case] Install the proposed speech-dispatcher and the snap[5] containing spd- say. Restart the user session so the new systemd unit gets activated. Then, snap run --shell geheim $ XDG_RUNTIME_DIR=/run/user/1000 spd-say hi should say "hi" through your loudspeakers. If you have no loudspeakers or if you are testing in a virtual machine, you can use Pavucontrol to verify that the dummy output device meter shows activity right after you issue the last command. [Regression potential] If the socket communication were not working (e.g. connection refused), then this would result in text-to-speech failing, even for a not sandboxed program. Do note, however, that if the socket were not available for whatever reason (e.g. the user didn't start it manually nor rebooted), then the sd_listen_fds(0) >= 1 test would be false and no regression would be observed, as then the program would fallback to its usual operation. [1] https://github.com/brailcom/speechd/issues/335 [21] https://github.com/brailcom/speechd/pull/763 [22] https://github.com/brailcom/speechd/pull/776 [23] https://github.com/brailcom/speechd/pull/817 [31] https://irclogs.ubuntu.com/2023/05/17/%23ubuntu-desktop.html [32] https://bugzilla.mozilla.org/show_bug.cgi?id=1729750#c23 [4] https://github.com/canonical/firefox-snap/pull/12 [5] https://launchpad.net/~nteodosio/+snap/test-speechd/+build/2103550 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/speech-dispatcher/+bug/1991022/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
