Processed: Re: Bug#859926: speechd-up: fails to install

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 speech-dispatcher
Bug #859926 [speechd-up] speechd-up: fails to install
Bug reassigned from package 'speechd-up' to 'speech-dispatcher'.
No longer marked as found in versions speechd-up/0.5~20110719-6.
Ignoring request to alter fixed versions of bug #859926 to the same values 
previously set
> retitle -1 breaks with pulse-audio as output when spawned by speechd-up from 
> init system
Bug #859926 [speech-dispatcher] speechd-up: fails to install
Changed Bug title to 'breaks with pulse-audio as output when spawned by 
speechd-up from init system' from 'speechd-up: fails to install'.
> affects -1 speechd-up
Bug #859926 [speech-dispatcher] breaks with pulse-audio as output when spawned 
by speechd-up from init system
Added indication that 859926 affects speechd-up

-- 
859926: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859926
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#859926: speechd-up: fails to install

[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



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[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



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Paul Gevers]

[CC-ing tts-project@l.a.d.o as they are the maintainer of
speech-dispatcher; although I believe most contributers there also read
d-a11n.]

On 22-04-17 00:26, Cobra wrote:
> Looks like we're chasing a pulseaudio<->speech-dispatcher bug now. Fun.

I concluded the same based on my logs. Although there the text was
different (3 times):
[Fri Apr 21 20:04:39 2017 : 454436] speechd:  Error: Module reported
error in request from speechd (code 3xx): 300-Opening sound device
failed. Reason: Couldn't open pulse plugin.
300 UNKNOWN ERROR

> 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).

> 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.

I noticed the same.

> The errcode move is a legit bug fix.

Ack.

> 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.

I came to the same conclusions in my previous e-mail. Good that we agree.

> 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)?

If not, thant I propose to clone this bug for speech-dispatcher.
Cloning, because I think that the delta in socket path is something that
speechd-up should fix. But that is probably (if it does not actually
cause this issue) not RC. But than what would be the issue for
speech-dispatcher? "speech-dispatcher doesn't work with pulse-audio when
started from init-script"? That doesn't sound like a great thing.

What do others think?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi

On 21-04-17 16:21, Cobra wrote:
> 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.

Hmm, should the speech-dispatcher package than rather NOT ship an init
file? Does it make sense in some setups? An when speech-dispatcher has
no init file, maybe than speechd-up shouldn't "Required-Start"
speech-dispatcher in its init file. Not that it matters, it still
doesn't work when I do that.

> 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...

I'll try to figure out further.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[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.

Bug#859926: speechd-up: fails to install

[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



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[MENGUAL Jean-Philippe]

Hi,

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.

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?

Regards,


Le 19/04/2017 à 22:18, Cindy-Sue Causey a écrit :
> On 4/18/17, Paul Gevers  wrote:
>> Hi all,
>>
>> I don't know what to make of it, but when I first start the speechd-up
>> daemon by hand, then the init script succeeds (because it finds the
>> daemon already running). But now it comes, I then can stop and start the
>> daemon successfully, but only when I am quick enough. This is
>> reproducible, sleep 4 works always, sleep 5 always fails (so far).
>>
>> paul@testavoira ~/ $ sudo /sbin/start-stop-daemon --start --nicelevel 0
>> --quiet --oknodo --chdir "/" --exec "/usr/bin/speechd-up" --oknodo
>> --pidfile "/var/run/speechd-up.pid" -- -l1
>> [Tue Apr 18 21:46:42 2017] speechd: Configuration has been read from
>> "/etc/speechd-up.conf"
>>
>> paul@testavoira ~ $ sudo service speechd-up start
>>
>> paul@testavoira ~ $ sudo service speechd-up stop ; sleep 4 ; sudo
>> service speechd-up start
>>
>> paul@testavoira ~ $ sudo service speechd-up stop ; sleep 5 ; sudo
>> service speechd-up start
>> 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.
> 
> 
> Some things have been snipped above while I hope I left enough of
> Paul's latest feedback to give it due Respect. :)
> 
> Simultaneous in my inbox is a different bug about Synaptic possibly
> keeping Orca from operating while Synaptic is open. It's this Bug
> #859262.
> 
> Synaptic "freezes Orca screen reader"
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859262
> 
> Is something like that maybe a possibility?
> 
> Seeing the word "Synaptic" also originally made me wonder if our
> *_CHOICE_* of package managers is affecting things somehow.
> 
> In my case, I have neither Synaptic nor Orca open because I don't use
> those. I only use "apt-get" via terminal interface for my package
> management.
> 
> One thing is that I still don't know how to actually test speechd-up's
> functionality. For now, all I know is that it appeared to have
> successfully, initially installed with no complaints (via "apt-get
> install speechd-up").
> 
> Another factor in my install attempt is that mine was a brand new
> install. There was no residual "clutter" of past installs that could
> potentially also be causing unknown complications.
> 
> Cindy :)
> 

-- 
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 
courieljpmeng...@hypra.fr
site webwww.hypra.fr
Facebook Hypra Twitter Hypra
Linkedin

Bug#859926: speechd-up: fails to install

[Cindy-Sue Causey]

On 4/18/17, Paul Gevers  wrote:
> Hi all,
>
> I don't know what to make of it, but when I first start the speechd-up
> daemon by hand, then the init script succeeds (because it finds the
> daemon already running). But now it comes, I then can stop and start the
> daemon successfully, but only when I am quick enough. This is
> reproducible, sleep 4 works always, sleep 5 always fails (so far).
>
> paul@testavoira ~/ $ sudo /sbin/start-stop-daemon --start --nicelevel 0
> --quiet --oknodo --chdir "/" --exec "/usr/bin/speechd-up" --oknodo
> --pidfile "/var/run/speechd-up.pid" -- -l1
> [Tue Apr 18 21:46:42 2017] speechd: Configuration has been read from
> "/etc/speechd-up.conf"
>
> paul@testavoira ~ $ sudo service speechd-up start
>
> paul@testavoira ~ $ sudo service speechd-up stop ; sleep 4 ; sudo
> service speechd-up start
>
> paul@testavoira ~ $ sudo service speechd-up stop ; sleep 5 ; sudo
> service speechd-up start
> 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.


Some things have been snipped above while I hope I left enough of
Paul's latest feedback to give it due Respect. :)

Simultaneous in my inbox is a different bug about Synaptic possibly
keeping Orca from operating while Synaptic is open. It's this Bug
#859262.

Synaptic "freezes Orca screen reader"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859262

Is something like that maybe a possibility?

Seeing the word "Synaptic" also originally made me wonder if our
*_CHOICE_* of package managers is affecting things somehow.

In my case, I have neither Synaptic nor Orca open because I don't use
those. I only use "apt-get" via terminal interface for my package
management.

One thing is that I still don't know how to actually test speechd-up's
functionality. For now, all I know is that it appeared to have
successfully, initially installed with no complaints (via "apt-get
install speechd-up").

Another factor in my install attempt is that mine was a brand new
install. There was no residual "clutter" of past installs that could
potentially also be causing unknown complications.

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi all,

I don't know what to make of it, but when I first start the speechd-up
daemon by hand, then the init script succeeds (because it finds the
daemon already running). But now it comes, I then can stop and start the
daemon successfully, but only when I am quick enough. This is
reproducible, sleep 4 works always, sleep 5 always fails (so far).

paul@testavoira ~/ $ sudo /sbin/start-stop-daemon --start --nicelevel 0
--quiet --oknodo --chdir "/" --exec "/usr/bin/speechd-up" --oknodo
--pidfile "/var/run/speechd-up.pid" -- -l1
[Tue Apr 18 21:46:42 2017] speechd: Configuration has been read from
"/etc/speechd-up.conf"

paul@testavoira ~ $ sudo service speechd-up start

paul@testavoira ~ $ sudo service speechd-up stop ; sleep 4 ; sudo
service speechd-up start

paul@testavoira ~ $ sudo service speechd-up stop ; sleep 5 ; sudo
service speechd-up start
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.

If I look at the processes that are running after a sleep 4 look, I
notice that speech-dispatcher keeps the same PID, so apparently with
sleep 4 it isn't killed and still alive when speechd-up wants to connect
to it. With sleep 4, the speech-dispatcher is killed and speechd-up
fails to connect (as seen in the speechd-up.log).

The big question is why systemd can't get speech-dispatcher up before
speechd-up wants to talk to it. One thing I noticed is that
/etc/default/speech-dispatcher has RUN=no, so starting speech-dispatcher
with the init script succeeds, but doesn't do anything. I think that
that may cause the confusion of systemd as the speechd-up init script
depends on the speech-dispatcher init script.

Setting RUN=yes, allows systemd to start speech-dispatcher, but
apparently that isn't enough, because it still fails to start
speechd-up. Speech-dispatcher isn't running anymore after starting
speechd-up while it was running before calling the init script, so it
looks like systemd tries to restart speech-dispatcher and fails doing
that properly.

Paul




signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Cindy-Sue Causey]

On 4/17/17, MENGUAL Jean-Philippe  wrote:
> Hi,
>
> We're going to have a look, but here I cannot reproduce. On Stretch, I
> install the package without problems. So I am surprised. I may have
> systemd-sysv, indeed, but not much more.
>

Hi.. I follow accessibility lists and thought I recognized this as a
topic of theirs so I'm "playing along" to finally learn a little more
about it.

I was able to install speechd-up successfully, BUT I have no idea if
it's functional because I don't know how to use it.

I'm on a super basic debootstrap'ed Stretch with Xfce4 as my primary
desktop environment. I've got Fluxbox and something else small that
I've forgotten because I haven't switched around between them in a
while.

All of this is being provided in case it somehow helps explain why
it's working for some of us and not for others.

About the only programs I have are: Libreoffice, GIMP, Inkscape,
Openshot, newly installed Piviti, Xine, and PySolFC (card games).

For sound, aumix is my hero because I went almost a year without sound
until I discovered that package. Others installed include GNOME ALSA
mixer, Qas mixer, mpv video player. Seriously, I was desperate and
downloading things that even remotely sounded like they might help
trigger sound back on.

Again, am mentioning all those because maybe they did something that
triggered at least a successful install. Whether it actually works as
intended or not, I have no clue aka literally clueless.

As for systemd, I haven't touched a thing there. My system is whatever
comes with a debootstrap install.

I'm on a now older ASUS 10" where "uname -a" gets: Linux northpole
4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64 GNU/Linux

That's all I can think to write right now. :)


> Le 16/04/2017 à 22:17, Paul Gevers a écrit :
>> 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.


#ThankYou for the work you all do!

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi Jean-Philippe,

On 17-04-17 11:19, MENGUAL Jean-Philippe wrote:
> We're going to have a look, but here I cannot reproduce. On Stretch, I
> install the package without problems. So I am surprised. I may have
> systemd-sysv, indeed, but not much more.

Seems like your system is the only system where it works then. Also in
Ubuntu, this issue was twice reported¹, while looking at the popcon, it
isn't heavily installed. That makes 5 people where it fails to install.

Paul

¹ https://bugs.launchpad.net/ubuntu/+source/speechd-up/+bug/1504054



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[MENGUAL Jean-Philippe]

Hi,

We're going to have a look, but here I cannot reproduce. On Stretch, I
install the package without problems. So I am surprised. I may have
systemd-sysv, indeed, but not much more.

Regards,


Le 16/04/2017 à 22:17, Paul Gevers a écrit :
> 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
> 

-- 
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 
courieljpmeng...@hypra.fr
site webwww.hypra.fr
Facebook Hypra Twitter Hypra
Linkedin





signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[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



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Paul Gevers]

Hi all,

On 16-04-17 11:32, Cobra wrote:
> I did some tests and installing speechd-up failed the same way.

Same for me.

I added some debugging info to /etc/init.d/speechd-up, and it turns out
that the error is generated because the /proc/$pid in running_pid()
doesn't exist. It should exist as the call to start_daemon() in
start_server() was successful. When I run the command that I think is
executed there manually, the daemon starts properly and the dir in /proc
exists:

paul@testavoira ~ $ sudo /sbin/start-stop-daemon --start --nicelevel 0
--quiet --oknodo --chdir "$PWD" --exec /usr/bin/speechd-up --oknodo
--pidfile /var/run/speechd-up.pid -- -l1
[Sun Apr 16 21:49:40 2017] speechd: Configuration has been read from
"/etc/speechd-up.conf"
paul@testavoira ~ $ ll -d /proc/$(cat /var/run/speechd-up.pid)
dr-xr-xr-x 9 root root 0 apr 16 21:49 /proc/6276

I haven't figured out the difference yet.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#859926: speechd-up: fails to install

[Mika Hanhijärvi]

Hello


On 04/09/2017 10:10 PM, Samuel Thibault wrote:

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




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

Processed: Re: Bug#859926: speechd-up: fails to install

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 speechd-up: fails to install
Bug #859926 [speechd-up] fails to install
Changed Bug title to 'speechd-up: fails to install' from 'fails to install'.

-- 
859926: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859926
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems