[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
This bug was fixed in the package speech-dispatcher - 0.11.1-1ubuntu3 --- speech-dispatcher (0.11.1-1ubuntu3) jammy; urgency=medium * patches/systemd-socket-activation: Added. - Enables activating Speech Dispatcher via a Systemd socket, it's needed for confined clients to be able to activate the service (LP: #1991022). [ Sebastien Bacher] * debian/control: - Build-Depends on libsystemd-dev * debian/speech-dispatcher.install: - install the new systemd units -- Nathan Pratta Teodosio Tue, 23 May 2023 09:29:24 +0200 ** Changed in: speech-dispatcher (Ubuntu Jammy) Status: Fix Committed => Fix Released -- 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: Fix Released Status in speech-dispatcher source package in Kinetic: Fix Released Status in speech-dispatcher source package in Lunar: Fix Released 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 : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
This bug was fixed in the package speech-dispatcher - 0.11.3-1ubuntu1.1 --- speech-dispatcher (0.11.3-1ubuntu1.1) kinetic; urgency=medium * patches/systemd-socket-activation: Added. - Enables activating Speech Dispatcher via a Systemd socket, it's needed for confined clients to be able to activate the service (LP: #1991022). [ Sebastien Bacher] * debian/control: - Build-Depends on libsystemd-dev * debian/speech-dispatcher.install: - install the new systemd units -- Nathan Pratta Teodosio Tue, 23 May 2023 08:59:41 +0200 ** Changed in: speech-dispatcher (Ubuntu Kinetic) Status: Fix Committed => Fix Released -- 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: Fix Committed Status in speech-dispatcher source package in Kinetic: Fix Released Status in speech-dispatcher source package in Lunar: Fix Released 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 : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
This bug was fixed in the package speech-dispatcher - 0.11.4-2ubuntu0.1 --- speech-dispatcher (0.11.4-2ubuntu0.1) lunar; urgency=medium * patches/systemd-socket-activation: Added. - Enables activating Speech Dispatcher via a Systemd socket, it's needed for confined clients to be able to activate the service (LP: #1991022). [ Sebastien Bacher] * debian/control: - Build-Depends on libsystemd-dev * debian/speech-dispatcher.install: - install the new systemd units -- Nathan Pratta Teodosio Wed, 10 May 2023 08:40:27 +0200 ** Changed in: speech-dispatcher (Ubuntu Lunar) Status: Fix Committed => Fix Released -- 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: Fix Committed Status in speech-dispatcher source package in Kinetic: Fix Committed Status in speech-dispatcher source package in Lunar: Fix Released 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 : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
Verified in Lobster (0.11.4-2ubuntu0.1) and Kinetic (0.11.3-1ubuntu1.1) that the test case produces sound. ** Tags removed: verification-needed verification-needed-kinetic verification-needed-lunar ** Tags added: verification-done verification-done-kinetic verification-done-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: Fix Committed 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 : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
I installed 0.11.1-1ubuntu3 from jammy-proposed and the snap[5] in a Jammy virtual machine, logged out, logged in, opened Pavucontrol, ran snap run --shell geheim XDG_RUNTIME_DIR=/run/user/1000 spd-say hi and verified that the volume indicator in Pavucontrol moved right after issuing the command. [5] https://launchpad.net/~nteodosio/+snap/test-speechd/+build/2103550 ** Tags removed: verification-needed-jammy ** Tags added: verification-done-jammy -- 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: Fix Committed 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 : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
Hello Nathan, or anyone else affected, Accepted speech-dispatcher into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/speech- dispatcher/0.11.1-1ubuntu3 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- jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-jammy. 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 Jammy) Status: New => Fix Committed ** Tags added: verification-needed-jammy -- 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: Fix Committed 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]
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
Hello Nathan, or anyone else affected, Accepted speech-dispatcher into kinetic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/speech- dispatcher/0.11.3-1ubuntu1.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- kinetic to verification-done-kinetic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-kinetic. 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 Kinetic) Status: New => Fix Committed ** Tags added: verification-needed-kinetic -- 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]
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
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]
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
** Description changed: [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. Then, + say. Restart the user session. Then, - systemctl start --user speech-dispatcher.socket #Or restart session or machine 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 ** Description changed: [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
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
We believe the question got answered and the upload should be good for review now ** Changed in: speech-dispatcher (Ubuntu Jammy) Status: Incomplete => New ** Changed in: speech-dispatcher (Ubuntu Kinetic) Status: Incomplete => New ** Changed in: speech-dispatcher (Ubuntu Lunar) Status: Incomplete => New -- 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: New Status in speech-dispatcher source package in Lunar: New 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. Then, systemctl start --user speech-dispatcher.socket #Or restart session or machine 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 : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
Yes, I can confirm that restarting the user session is enough. ** Description changed: [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 system needs to be rebooted. + 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. Then, - systemctl start --user speech-dispatcher.socket + systemctl start --user speech-dispatcher.socket #Or restart session or machine 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 -- 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: Incomplete Status in speech-dispatcher source package in Kinetic: Incomplete Status in speech-dispatcher source package in Lunar: Incomplete 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
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
A user logout/login would qualify as restarting the user session. -- 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: Incomplete Status in speech-dispatcher source package in Kinetic: Incomplete Status in speech-dispatcher source package in Lunar: Incomplete 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 system needs to be rebooted. [Test case] Install the proposed speech-dispatcher and the snap[5] containing spd- say. Then, systemctl start --user speech-dispatcher.socket 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 : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
Hi, what exactly does restarting the session mean? I could verify whether that would work. Otherwise the behavior I observed is consistent with https://source.puri.sm/kop316/mmsd/-/issues/3. ** Bug watch added: source.puri.sm/kop316/mmsd/-/issues #3 https://source.puri.sm/kop316/mmsd/-/issues/3 -- 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: Incomplete Status in speech-dispatcher source package in Kinetic: Incomplete Status in speech-dispatcher source package in Lunar: Incomplete 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 system needs to be rebooted. [Test case] Install the proposed speech-dispatcher and the snap[5] containing spd- say. Then, systemctl start --user speech-dispatcher.socket 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 : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
This looks very good to me, thanks. My only concern is that the test case includes a manual: systemctl start --user speech-dispatcher.socket Is that in place of re-starting the user session? I would expect the socket unit to be started automatically. Should we ask for a restart of the user session as part of the verification, to ensure this happens correctly? ** Description changed: [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] - It's relevance is described in [1], of which I quote the essential parts + 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 system needs to be rebooted. [Test case] Install the proposed speech-dispatcher and the snap[5] containing spd- say. Then, systemctl start --user speech-dispatcher.socket 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 ** Changed in: speech-dispatcher (Ubuntu Lunar) Status: Fix Committed => Incomplete ** Changed in: speech-dispatcher (Ubuntu Kinetic) Status: Fix Committed => Incomplete ** Changed in: speech-dispatcher (Ubuntu Jammy) Status: Fix Committed => Incomplete -- 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: Incomplete Status in speech-dispatcher source package in Kinetic: Incomplete Status in speech-dispatcher source package in Lunar: Incomplete 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
[Desktop-packages] [Bug 1991022] Re: [SRU] Service activation via Systemd socket
Thanks, I've uploaded to the different series now but remove the lsb- base change to not complicate the review (it's another changeset so by SRU rule it would have required another bug/testcase). I always tweaked the lunar and kinetic revision since we can't re-use version which already got published to launchpad ** Changed in: speech-dispatcher (Ubuntu Lunar) Status: Confirmed => Fix Committed ** Changed in: speech-dispatcher (Ubuntu Kinetic) Status: Confirmed => Fix Committed ** Changed in: speech-dispatcher (Ubuntu Jammy) Status: Confirmed => Fix Committed -- 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: Fix Committed 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] It's 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 system needs to be rebooted. [Test case] Install the proposed speech-dispatcher and the snap[5] containing spd- say. Then, systemctl start --user speech-dispatcher.socket 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 : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
