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
Hi Samuel,
On 18-10-2020 18:05, Samuel Thibault wrote:
> Sorry for not answering before, I'm terribly busy atm. Just giving a
> quick answer, a proper answer will need more time.
Did you have any chance to give this more thought? The bullseye freeze
is around the corner.
[...]
>> @Samuel, what
Hello,
Sorry for not answering before, I'm terribly busy atm. Just giving a
quick answer, a proper answer will need more time.
Paul Gevers, le sam. 17 oct. 2020 08:17:09 +0200, a ecrit:
> On 02-09-2020 17:46, Dennis Filder wrote:
> > The patch adds a new thread that is on the lookout for Pulseaud
Hi Dennis, Samuel,
On 02-09-2020 17:46, Dennis Filder wrote:
> I looked into this a bit and came up with the attached patch (written
> against 0.10.1-2), but for further improvement I'd need some feedback.
>
> The patch adds a new thread that is on the lookout for Pulseaudio
> processes and recon
I looked into this a bit and came up with the attached patch (written
against 0.10.1-2), but for further improvement I'd need some feedback.
The patch adds a new thread that is on the lookout for Pulseaudio
processes and reconfigures/restarts the output modules accordingly
once it finds one. This
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 propose
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
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,
Le 23/04/2017 à 11:04, Paul Gevers a écrit :
> Control: reassign -1 speech-dispatcher
> Control: retitle -1 breaks with pul
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-di
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 #8599
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
Hi,
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.
>> A
[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 ther
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 s
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
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 se
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
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, sl
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 t
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 whe
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 have
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
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
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
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 hav
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 Tra
26 matches
Mail list logo
