Bug#859926: fails to install

[Mika Hanhijärvi]

Package: speechd-up
Version: 0.5~20110719-6+b1
Severity: grave

When I try to install speechd-up package I get this error:

E: speechd-up: subprocess installed post-installation script returned error
exit status 1

Synaptic marks the package as installed. If I try to reinstall the package I
get this error:

E: Internal Erro r, No file name for speechd-up:amd64





-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages speechd-up depends on:
ii libc6 2.24-9
ii libdotconf0 1.3-0.2
ii libspeechd2 0.8.6-4
ii speech-dispatcher 0.8.6-4

speechd-up recommends no packages.

speechd-up suggests no packages.

-- no debconf information

[Samuel Thibault]

Control: retitle -1 speechd-up: fails to install

Hello,

Mika Hanhijärvi, on dim. 09 avril 2017 13:42:36 +0300, wrote:
> When I try to install speechd-up package I get this error:
>
> E: speechd-up: subprocess installed post-installation script returned error
> exit status 1

Do you happen to have the espeakup package installed too? They can't
work at the same time.

Otherwise, could somebody from debian-accessibility check whether
speechd-up works with the current speech-dispatcher?

Samuel

[Mika Hanhijärvi]

Hello

No. I do not have espeakup installed.

I removed espeakup because I wanted to try if speechd-up would solve
atleast part of the one problem I have (maybe offtopic here). For some
reason if espeakup speaks something when computer is booting then screen
reader does not speak on Gdm login screen and on desktop. But espeak
speaks on console. So I have to reboot sometimes severaltimes. If
espeakup does not say anything when computer boots, then screen reader
speaks on gdm, but not on console. If I then login to desktop then Orca
speaks on desktop, but if I go back to gdm screen whitout logging out
from desktop first then screen reader does not speak on gdm screen.
espeakup also does not speak on console. If I logout from desktop then
screen reader starts to speak on gdm screen again, but espeak still does
not speak on console. So I can not switch between desktop, gdm login
screen and console, I am blind so I need to use screen reader.

I have no idea to which package I would need to file the bug, because I
do not know if the problem is in espeakup, pulseaudio,
speech-dispatcher, Orca or espeak / espeak-ng ...

So I wanted to try if speechd-up would solve atleast part of the problem.

- Mika

[Cobra]

Hi,

I did some tests and installing speechd-up failed the same way.

install log from aptitude:

Selecting previously unselected package libdotconf0:amd64.
(Reading database ... 295864 files and directories currently installed.)
Preparing to unpack .../libdotconf0_1.3-0.2_amd64.deb ...
Unpacking libdotconf0:amd64 (1.3-0.2) ...
Selecting previously unselected package libspeechd2:amd64.
Preparing to unpack .../libspeechd2_0.8.6-4_amd64.deb ...
Unpacking libspeechd2:amd64 (0.8.6-4) ...
Selecting previously unselected package speech-dispatcher-audio-plugins:amd64.
Preparing to unpack .../speech-dispatcher-audio-plugins_0.8.6-4_amd64.deb ...
Unpacking speech-dispatcher-audio-plugins:amd64 (0.8.6-4) ...
Selecting previously unselected package speech-dispatcher.
Preparing to unpack .../speech-dispatcher_0.8.6-4_amd64.deb ...
Unpacking speech-dispatcher (0.8.6-4) ...
Selecting previously unselected package speechd-up.
Preparing to unpack .../speechd-up_0.5~20110719-6+b1_amd64.deb ...
Unpacking speechd-up (0.5~20110719-6+b1) ...
Processing triggers for install-info (6.3.0.dfsg.1-1+b2) ...
Setting up libspeechd2:amd64 (0.8.6-4) ...
Processing triggers for libc-bin (2.24-9) ...
Setting up libdotconf0:amd64 (1.3-0.2) ...
Processing triggers for systemd (232-22) ...
Setting up speech-dispatcher-audio-plugins:amd64 (0.8.6-4) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up speech-dispatcher (0.8.6-4) ...
Setting up speechd-up (0.5~20110719-6+b1) ...
Job for speechd-up.service failed because the control process exited with error code.
See "systemctl status speechd-up.service" and "journalctl -xe" for details.
invoke-rc.d: initscript speechd-up, action "start" failed.
● speechd-up.service - LSB: Interface between speakup and speech-dispatcher
Loaded: loaded (/etc/init.d/speechd-up; generated; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2017-04-16 10:45:25 CEST; 12ms ago
Docs: man:systemd-sysv-generator(8)
Process: 31268 ExecStart=/etc/init.d/speechd-up start (code=exited, status=1/FAILURE)

Apr 16 10:45:23 deb9 speechd-up[31268]: Starting Interface between speakup and speech-dispatcher : speechd-up[Sun Apr 16 10:45:23 2017] speechd: Configuration has been read from "/etc/speechd-up.conf"
Apr 16 10:45:23 deb9 speechd-up[31268]: Starting speechd-up...
Apr 16 10:45:23 deb9 speechd-up[31268]: To work, speechd-up needs speakup and speakup_soft modules.
Apr 16 10:45:23 deb9 speechd-up[31268]: They are loaded automatically. If you don't want, type
Apr 16 10:45:23 deb9 speechd-up[31268]: rmmod speakup speakup_soft
Apr 16 10:45:25 deb9 speechd-up[31268]: failed!
Apr 16 10:45:25 deb9 systemd[1]: speechd-up.service: Control process exited, code=exited status=1
Apr 16 10:45:25 deb9 systemd[1]: Failed to start LSB: Interface between speakup and speech-dispatcher.
Apr 16 10:45:25 deb9 systemd[1]: speechd-up.service: Unit entered failed state.
Apr 16 10:45:25 deb9 systemd[1]: speechd-up.service: Failed with result 'exit-code'.
dpkg: error processing package speechd-up (--configure):

subprocess installed post-installation script returned error exit status 1

Processing triggers for systemd (232-22) ...
Errors were encountered while processing:
speechd-up
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up speechd-up (0.5~20110719-6+b1) ...
Job for speechd-up.service failed because the control process exited with error code.
See "systemctl status speechd-up.service" and "journalctl -xe" for details.
invoke-rc.d: initscript speechd-up, action "start" failed.
● speechd-up.service - LSB: Interface between speakup and speech-dispatcher
Loaded: loaded (/etc/init.d/speechd-up; generated; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2017-04-16 10:45:29 CEST; 13ms ago
Docs: man:systemd-sysv-generator(8)
Process: 31560 ExecStart=/etc/init.d/speechd-up start (code=exited, status=1/FAILURE)

Apr 16 10:45:27 deb9 speechd-up[31560]: Starting Interface between speakup and speech-dispatcher : speechd-up[Sun Apr 16 10:45:27 2017] speechd: Configuration has been read from "/etc/speechd-up.conf"
Apr 16 10:45:27 deb9 speechd-up[31560]: Starting speechd-up...
Apr 16 10:45:27 deb9 speechd-up[31560]: To work, speechd-up needs speakup and speakup_soft modules.
Apr 16 10:45:27 deb9 speechd-up[31560]: They are loaded automatically. If you don't want, type
Apr 16 10:45:27 deb9 speechd-up[31560]: rmmod speakup speakup_soft
Apr 16 10:45:29 deb9 speechd-up[31560]: failed!
Apr 16 10:45:29 deb9 systemd[1]: speechd-up.service: Control process exited, code=exited status=1
Apr 16 10:45:29 deb9 systemd[1]: Failed to start LSB: Interface between speakup and speech-dispatcher.
Apr 16 10:45:29 deb9 systemd[1]: speechd-up.service: Unit entered failed state.
Apr 16 10:45:29 deb9 systemd[1]: speechd-up.service: Failed with result 'exit-code'.
dpkg: error processing package speechd-up (--configure):

subprocess installed post-installation script returned error exit status 1

Errors were encountered while processing:
speechd-up

Manually starting speechd-up.service fails the same way.
/var/log/speechd-up.log, with LogLevel 5:

[Sun Apr 16 11:13:42 2017] speechd: Speechd-speakup starts!
[Sun Apr 16 11:13:42 2017] speechd: ERROR! Can't connect to Speech Dispatcher!

speech-dispatcher.service seems to be okay.

$ systemctl status speech-dispatcher.service
● speech-dispatcher.service - LSB: Speech Dispatcher
Loaded: loaded (/etc/init.d/speech-dispatcher; generated; vendor preset: enabled)
Active: active (exited) since Sun 2017-04-16 10:45:22 CEST; 34min ago
Docs: man:systemd-sysv-generator(8)
Tasks: 0 (limit: 4915)
CGroup: /system.slice/speech-dispatcher.service

If someone has any ideas for debugging this, I'd be happy to help out.

[Paul Gevers]

Hi

On 16-04-17 21:51, Paul Gevers wrote:
> I haven't figured out the difference yet.

Probably somebody who knows systemd should have a look. I have the
feeling it is interfering with the script and not doing what I read.

I have no clue where to find the input (the service file?) that systemd
is actually using yet. This is all new to me.

Paul

[Paul Gevers]

Hi Jean-Philippe,

On 19-04-17 22:28, MENGUAL Jean-Philippe wrote:
> 1st, I have always had the idea the the spd service had bugs and was not
> really usable: spent so resource, didn't run really, etc. Hence the fact
> it's always been in "no" in defaults/speech-dispatcher.

So, does that mean that speechd-up should also have such a mechanism
that defaults to no?

What I am now seeing is that speech-dispatcher doesn't stay running when
started with it's init script. If I start it with "sudo service
speech-dispatcher start" than it is in the "active (running)" state for
about 20 seconds and then goes to an "active (exited)" state. I expect
that speechd-up is failing to start because it actually checks if it can
USE speech-dispatcher.

Two things that I then noticed, the man page of speech-dispatcher
mentions that it needs to be started with the "-d" option to run as
daemon (which isn't present in its init file). With debugging
information added I then noticed the following in
/tmp/speechd-debug/speech-dispatcher.log:
[Fri Apr 21 14:10:00 2017 : 638612] speechd: Currently no clients
connected, enabling shutdown timer.
[Fri Apr 21 14:10:05 2017 : 713820] speechd: Terminating...

So it seems speech-dispatcher doesn't want to stay running as daemon. I
guess this is the real issue at stake. (Should we reassign?)

> 2nd, given this feedback, maybe we may try requesting to the initscript
> to wait for some seconds, with a kind of pause parameter? Would it fix
> the bug?

Just to be sure, you mean pausing in the speech-dispatcher init script,
right? Speechd-up already has that. Because of the above, this doesn't
help. I even tried it (actually before I found out the above) and it
didn't work.

Paul

[Cobra]

Hi,

On 2017-04-21 14:18, Paul Gevers wrote:
> On 19-04-17 22:28, MENGUAL Jean-Philippe wrote:
>> 1st, I have always had the idea the the spd service had bugs and was not
>> really usable: spent so resource, didn't run really, etc. Hence the fact
>> it's always been in "no" in defaults/speech-dispatcher.
> So, does that mean that speechd-up should also have such a mechanism
> that defaults to no?
>
> What I am now seeing is that speech-dispatcher doesn't stay running when
> started with it's init script. If I start it with "sudo service
> speech-dispatcher start" than it is in the "active (running)" state for
> about 20 seconds and then goes to an "active (exited)" state. I expect
> that speechd-up is failing to start because it actually checks if it can
> USE speech-dispatcher.
>
> Two things that I then noticed, the man page of speech-dispatcher
> mentions that it needs to be started with the "-d" option to run as
> daemon (which isn't present in its init file). With debugging
> information added I then noticed the following in
> /tmp/speechd-debug/speech-dispatcher.log:
> [Fri Apr 21 14:10:00 2017 : 638612] speechd: Currently no clients
> connected, enabling shutdown timer.
> [Fri Apr 21 14:10:05 2017 : 713820] speechd: Terminating...
>
> So it seems speech-dispatcher doesn't want to stay running as daemon. I
> guess this is the real issue at stake. (Should we reassign?)

The man page states:
"speech-dispatcher is usually started automatically by client libraries
(i.e. autospawn), so you only need to run it manually if
testing/debugging, or when in other explicit need for a special setup."

So this behaviour doesn't seem broken to me, that's rather exactly as
expected. Also, starting speechd-up with start-stop-daemon doesn't show
any failures, despite missing special handling of speech-dispatcher.
There is an open bug about autospawn with multiple users in #616313,
but I don't see an immediate connection to our issues; we're always
root and not touching speechd-up directly.

I enabled this line in /etc/speech-dispatcher/speechd.conf:
CustomLogFile "protocol" "/var/log/speech-dispatcher/speech-dispatcher-protocol.log"

/var/log/speech-dispatcher/speech-dispatcher-protocol.log stays empty
when using service (my VM is still using sysvinit-core now), but when I
use the usual start-stop-daemon command, I get this log:

[Thu Apr 20 15:31:30 2017 : 10113] speechd: 22:DATA:|SET SELF CLIENT_NAME "test:speakup:softsynth"
| (47)
[Thu Apr 20 15:31:30 2017 : 10730] speechd: 22:REPLY:|208 OK CLIENT NAME SET
|
[Thu Apr 20 15:31:30 2017 : 11457] speechd: 22:DATA:|SET SELF NOTIFICATION index_marks on
| (38)
[Thu Apr 20 15:31:30 2017 : 11490] speechd: 22:REPLY:|220 OK NOTIFICATION SET
|
[Thu Apr 20 15:31:30 2017 : 11860] speechd: 22:DATA:|SET SELF NOTIFICATION all on
| (30)
[Thu Apr 20 15:31:30 2017 : 11890] speechd: 22:REPLY:|220 OK NOTIFICATION SET
|
[Thu Apr 20 15:31:30 2017 : 12102] speechd: 22:DATA:|SET SELF CAP_LET_RECOGN none
| (30)
[Thu Apr 20 15:31:30 2017 : 12131] speechd: 22:REPLY:|206 OK CAP LET RECOGNITION SET
|
[Thu Apr 20 15:31:30 2017 : 12356] speechd: 22:DATA:|SET SELF SSML_MODE on
| (23)
[Thu Apr 20 15:31:30 2017 : 12380] speechd: 22:REPLY:|219 OK SSML MODE SET
|

To me, this confirms that autospawn is working, but not when speechd-up
is started by any init system despite having the exact same command
line. I didn't bother switching to systemd again for now.
I also dumped the env from bash and the initd script, but couldn't see
any suspicous differences.

If only speechd-up could provide some detailed logs, but it isn't
particularly chatty when starting up, despite LogLevel 5.

Also, I can confirm hearing some speech at one point when manually
starting speechd-up with start-stop-daemon, but the volume was too low
to understand what it was and it didn't happen again.

[Cobra]

Hi,

On 2017-04-21 20:08, Paul Gevers wrote:
>> I enabled this line in /etc/speech-dispatcher/speechd.conf:
>> CustomLogFile "protocol" "/var/log/speech-dispatcher/speech-dispatcher-protocol.log"
>>
>> /var/log/speech-dispatcher/speech-dispatcher-protocol.log stays empty
>> when using service (my VM is still using sysvinit-core now), but when I
>> use the usual start-stop-daemon command, I get this log:
>

> May it be that starting daemons via service may not have $HOME set? It
> occurs to me that when I start speechd-up manually I see this with "ps
> aux" (notice the socket location):
> root 22182 0.0 0.0 174708 2224 ? Ssl 19:47 0:00
> /usr/bin/speech-dispatcher --spawn --communication-method unix_socket
> --socket-path /root/.cache/speech-dispatcher/speechd.sock
>
> By the way, with "service" it seems that configuration of
> speech-dispatcher is ignored. I find the logging in
> /root/.cache/speech-dispatcher... where it now also records what goes
> wrong..
> [Fri Apr 21 20:04:39 2017 : 549750] speechd: Error [speechd.c:665]:No
> speech output modules were loaded - aborting...

Good catch with the socket and log files. There's indeed no $HOME in
the init.d env. It's just LC_*/LANG, PATH, PWD, TERM; but adding HOME
doesn't help as far as I can tell.
$XDG_RUNTIME_DIR as referenced in /etc/speech-dispatcher/speechd.conf
isn't set in either env.

Looking at the log files, esp.
/root/.cache/speech-dispatcher/log/speech-dispatcher.log, I noticed
that running "sudo /etc/init.d/speechd-up start" works without errors.
Please note: I do not have and use systemd right now.
With systemd in use, this won't work, systemd catches the init script.
Running "sudo service speechd-up start" fails and this log shows a lot
of pulseaudio errors with the sub logs all logging this line:
pulse.c: pa_simple_new() failed: Connection refused

Looks like we're chasing a pulseaudio<->speech-dispatcher bug now. Fun.
Removing pulseaudio and setting AudioOutputMethod to alsa in
/etc/speech-dispatcher/speechd.conf makes speechd-up work.
After rebooting I can hear parts of the boot log messages, and:
$ sudo service speechd-up status
[ ok ] Checking status of Interface between speakup and speech-dispatcher: speechd-up running.

The directories are different when starting at boot:
$ ps aux | grep "speec\h"
root 1479 0.0 0.0 99264 2164 ? Ssl Apr21 0:00 /usr/bin/speechd-up -l1
root 1506 0.0 0.1 59768 4628 ? SLl Apr21 0:00 /usr/lib/speech-dispatcher-modules/sd_dummy /etc/speech-dispatcher/modules/dummy.conf
root 1533 0.0 0.1 59784 4612 ? SLl Apr21 0:00 /usr/lib/speech-dispatcher-modules/sd_generic /etc/speech-dispatcher/modules/generic.conf
root 1541 0.1 0.4 277456 10328 ? SLl Apr21 0:01 /usr/lib/speech-dispatcher-modules/sd_espeak-ng /etc/speech-dispatcher/modules/espeak-ng.conf
root 1586 0.0 0.0 173032 2212 ? Ssl Apr21 0:00 /usr/bin/speech-dispatcher --spawn --communication-method unix_socket --socket-path /.cache/speech-dispatcher/speechd.sock
$ sudo service speechd-up restart
[....] Restarting Interface between speakup and speech-dispatcher: speechd-upStopping speechd-up and unloading speakup modules...
[Sat Apr 22 00:02:55 2017] speechd: Configuration has been read from "/etc/speechd-up.conf"
Starting speechd-up...

To work, speechd-up needs speakup and speakup_soft modules.

They are loaded automatically. If you don't want, type

rmmod speakup speakup_soft
. ok
$ ps aux | grep "speec\h"
root 2170 0.0 0.1 105616 2744 ? Ssl 00:02 0:00 /usr/bin/speechd-up -l1
root 2175 0.6 0.1 59776 4540 ? SLl 00:02 0:00 /usr/lib/speech-dispatcher-modules/sd_dummy /etc/speech-dispatcher/modules/dummy.conf
root 2179 0.4 0.1 59788 4608 ? SLl 00:02 0:00 /usr/lib/speech-dispatcher-modules/sd_generic /etc/speech-dispatcher/modules/generic.conf
root 2181 2.8 0.3 142088 8536 ? SLl 00:02 0:00 /usr/lib/speech-dispatcher-modules/sd_espeak-ng /etc/speech-dispatcher/modules/espeak-ng.conf
root 2188 0.0 0.0 183144 2212 ? Ssl 00:02 0:00 /usr/bin/speech-dispatcher --spawn --communication-method unix_socket --socket-path /root/.cache/speech-dispatcher/speechd.sock

Still a bit broken, but at least it's some progress.
At this stage, I think all these problems belong to speech-dispatcher.
I'll continue digging, but I I'll reset my vm after changing so much.

Just for the record:
I just found out that Jessie doesn't have any issues and the only
relevant changelog entry is "speechd-up.init: Fix startup/shutdown."
- well, for me it looks like the other way around.
Git commit: https://anonscm.debian.org/cgit/pkg-a11y/speechd-up.git/commit/?id=5db9503f13cdadbefb160846e53c8f141a7ee631
The errcode move is a legit bug fix.
STARTTIME might expose some bugs but isn't the root cause of anything.
Required-(Start|Stop) looks strange with the autospawn thing of
speech-dispatcher. But deleting speech-dispatcher from
Required-(Start|Stop) won't do anything - speech-dispatcher won't run
anyway unless enabled to do so in /etc/default/speech-dispatcher.
That's a dead-end, speechd-up doesn't seem to be the primary culprit.

[Paul Gevers]

Hi Cobra,

On 22-04-17 21:26, Cobra wrote:
> On 2017-04-22 19:51, Paul Gevers wrote:

>> On 22-04-17 00:26, Cobra wrote:
>>> The directories are different when starting at boot:

>> This doesn't sound good. I think it shouldn't matter how you call an
>> init-script, it should behave the same. I guess this is speechd-up's
>> responsibility.

>>> At this stage, I think all these problems belong to speech-dispatcher.

>> Well, I am not 100% convinced. The directory for the socket apparently
>> comes from the environment, and I would say that that is the
>> responsibility of the caller (in this case speechd-up or its init-script).
>
> Might need some further testing, but imho that is speech-dispatcher's
> problem, especially with the autospawn. I'd rather have
> speech-dispatcher handle this correctly for all clients than make all
> clients do the right thing (which they will inevitably fail to do).

Good point. Agreed.

>>> That's a dead-end, speechd-up doesn't seem to be the primary culprit.

>> Agree. But I wonder if for the issue at hand (installation failing due
>> to init script failing) we should rather give up on providing an init
>> script that works in all circumstances for now. It seems it may rely on
>> configuration of speech-dispatcher (and sound). So maybe it is best for
>> now to just disable the init script (in a similar way as for
>> speech-dispatcher)?
>
> Sounds like making this package quite useless and I think it's not
> necessary. Fixing init script bugs should suffice.

Agree, but if fixing the bug doesn't happen in time, it will drop out of
Stretch (at least if it remains with speechd-up). If we can't find the
real bug (and a solution), maybe having an init script that needs to be
enabled by the user is better than no speechd-up in Stretch. But see
below. (And what an incredible amount of work are we putting into this
package with a popcon of 9).

> I was thinking of reassigning to the current speech-dispatcher version
> as "breaks with pulse output when spawned by speechd-up from init
> system", keeping the RC level.

Please go ahead.

> Does this count as "breaking unrelated
> packages"? I think so, but speechd-up and speech-dispatcher aren't
> completely unrelated, so I'm unsure.

I don't think so. It breaks a very related package.

> Without further input, I won't issue such bug control commands.

Please don't hesitate further.

> I'd rather open new bugs for any issues with speechd-up's init scripts
> we find instead of cloning.

Ok.

> Yep, things are really working without pulseaudio and there aren't any
> directory changes with systemd handling things. Logs are also there.
> speechd-up is only breaking when speech-dispatcher is configured in a
> special way, but sadly it's speech-dispatcher's default config.

Ack.

Paul

[Paul Gevers]

Control: reassign -1 speech-dispatcher
Control: retitle -1 breaks with pulse-audio as output when spawned by speechd-up from init system
Control: affects -1 speechd-up

On 22-04-17 22:01, Paul Gevers wrote:

> On 22-04-17 21:26, Cobra wrote:
>> I was thinking of reassigning to the current speech-dispatcher version
>> as "breaks with pulse output when spawned by speechd-up from init
>> system", keeping the RC level.
>
> Please go ahead.

Done so now. Let's not wait unnecessary.

Summary for speech-dispatcher contributors:
speechd-up is failing to install (on several systems) because the
init script fails to start successfully. The success or failure of
starting speechd-up depends on
1) which output is used by speech-dispatcher, with alsa it work, but
with the default pulse-audio it doesn't
2) how the speechd-up daemon is started, calling the init script fails
but calling the exact same start-stop-daemon command manually on
the command line succeeds.

The following remark may be spurious. While debugging, we
noticed that the directory that contains the speech-dispatcher socket
may depend on which init system is used. With systemd, it doesn't matter
how speechd-up is called, it puts the socket in
/root/.cache/speech-dispatcher/speechd.sock while with sysvinit-core upon
boot the socket is in
/.cache/speech-dispatcher/speechd.sock (after restarting it is in the same
directory as with systemd)

Paul

[MENGUAL Jean-Philippe]

Hi,

Given delays, and to avoid autoremoval, maybe we could remove the initscript so that the package to be iostallable? And documenting how to run it manually?

Regards,

--

JEAN-PHILIPPE MENGUAL DIRECTEUR TECHNIQUE ET QUALITÉ 84, quai de Jemappes, 75010, Paris +331 84 71 06 61 jpme...@hypra.fr www.hypra.fr

[Paul Gevers]

Hi Jean-Philippe,

On 23-04-17 13:47, MENGUAL Jean-Philippe wrote:
> Given delays, and to avoid autoremoval, maybe we could remove the
> initscript so that the package to be iostallable? And documenting how to
> run it manually?

I proposed that already in this bug, but cobra convinced me to not do
that. Also, now the bug is assigned to speech-dispatcher, it will not
trigger autoremoval as speech-dispatcher is a key package¹. So let's
focus on getting the real bug solved.

Paul

¹ https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

[MENGUAL Jean-Philippe]

Le 23/04/2017 à 15:14, Paul Gevers a écrit :
> Hi Jean-Philippe,
>
> On 23-04-17 13:47, MENGUAL Jean-Philippe wrote:
>> Given delays, and to avoid autoremoval, maybe we could remove the
>> initscript so that the package to be iostallable? And documenting how to
>> run it manually?
>
> I proposed that already in this bug, but cobra convinced me to not do
> that. Also, now the bug is assigned to speech-dispatcher, it will not
> trigger autoremoval as speech-dispatcher is a key package¹. So let's
> focus on getting the real bug solved.

ok sorry I had missed it. I just hope really the package speechd-up not
be removed. :)

Regards,

> Paul
>
> ¹ https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
>

--
Logo Hypra
Photo Jean-Philippe MENGUAL *JEAN-PHILIPPE MENGUAL**
DIRECTEUR TECHNIQUE ET QUALITÉ*
adresse84, quai de Jemappes, 75010, Paris
téléphone+331 84 71 06 61 <tel:+33%201%2000%2000%2000%2000>
courielj...@hypra.fr
site webwww.hypra.fr
Facebook Hypra <https://www.facebook.com/hyprasoftware/>Twitter Hypra
<https://twitter.com/Hypra_>Linkedin
<https://fr.linkedin.com/in/jean-philippe-mengual-800133135>

[fabio duru]

Dear,

I hope my email finds you in good health.

Finally, i made it to success with another partner after you couldn't complete the transaction with me. But i did not forget your effort then, it  was part of my success still. So i left a bank cheque with the Catholic Reverend sister whom i told you about sometime ago as my trusted Secretary.

Contact her at this below email immediately, introduce yourself as the cashier cheque recipient and demand for your cheque release process.

Send email to: Reverend sister Angela Helpe

Email:helper...@gmail.com

Tel:   +228 98766629

[Dennis Filder]

On Mon, Jan 04, 2021 at 10:02:38PM +0100, Paul Gevers wrote:
> [...]
> > Yes, the "pulse,alsa" user-visible change seems interesting. But the
> > implementation seems fragile to me: looking in /proc content is deemed
> > to break at some point or another. We've been struck hard by such kind
> > of tinkering in the past, I'd rather not see that happen again :/
>
> Ack. @Dennis, feel free to comment on this too.

I agree with the assessment that depending on /proc is far from ideal,
but I've been running it for a few months now and it's been working
better than I had expected. However, the issues that I've encountered
so far mostly stem from a lack of integration. For example, Orca is
started via /etc/xdg/autostart and pulseaudio in some cases via the
user's systemd, which means both are uncoordinated and thus race for
the audio device. Another issue I've seen under Bullseye is that gdm3
makes its instance of pulseaudio give up control of the audio device
when the user switches to console which then mutes speakup if
speechd-up has already connected to pulseaudio, and there appears to
be no config option to turn that off.

I've also had some cases where speech-dispatcher pegs the CPU at 100 %
for some reason, but I haven't figured out the cause for that yet.
So, if this patch won't make it into Bullseye, it's not going to be
the end of the world.

The reason I started work on this in the first place is that AFAIK
Firefox some time ago dropped ALSA support and now only supports
pulseaudio. Also to me it seems like the only way to implement
features like automatically picking up a phone call and routing speech
and phone audio to different ears or spatialization of arbitrary sound
sources.

Regards,
Dennis