Latest Debian snapshot

Latest Debian snapshot

[Tony Baechler]

Hi,

First, thank you very much, Samuel!  I was hoping for a new snapshot to 
be released as a Debian package.  Is there any chance that the new 
package will make it to Lenny with the big freeze looming?

I only found two small problems and one very nice improvement.  The bug 
with my rc.local not being able to set parameters is fixed!  The 
synthesizer seems to respond slightly quicker to key presses.  I think I 
remember work being done either with threading or with keyboard input.  
Whatever it is, I can tell the difference.  The synth keeps up with my 
typing speed instead of having a slight lag.  I haven't thoroughly 
tested everything, but I tried Alt+left arrow and it didn't lock up.  I 
haven't checked if the speech stopping after about 4 KB of text has been 
fixed yet.  Over all, I'm impressed.

The two small problems are as follows:  First, I followed Samuel's 
instructions for building modules.  I did the following commands:

m-a prepare
tar -jxf speakup*.tar.bz2
cd modules/speakup  (I was already in /usr/src)
make
make modules_install

The problems are that it isn't obvious that the Speakup source is 
installed under /usr/src/modules/speakup.  I tried changing to the 
speakup directory but it didn't exist.  I wasn't sure if I needed to 
untar the source or not.  I suppose that the modules/speakup directory 
structure needs to stay in place because of Debian policy, but why not 
make a symlink?  If that can't be done, please put a note in 
README.Debian for installing manually since the source in Debian won't 
always be the latest from git, especially when running Stable.  The 
second problem is the underline in modules_install.  Most packages I've 
compiled from source use a dash instead, such as make modules-install.  
For that matter, why not support "make install" instead?

The second problem is slightly more serious.  Apparently the Speakup 
modules must go in /lib/modules/`uname -r`/extra/speakup.  The "make 
modules_install" command put them in the extra directory but not in 
extra/speakup.  I had to manually copy them there.  Until I did, it kept 
loading the old modules, as /sys/module/speakup/version reported 3.0.2.  
I noticed all the files in the speakup directory were older than those 
not, so I figured it was safe to copy them.  Now I have two sets of 
identical Speakup modules, one in the extra/ directory and another in 
extra/speakup/.  This should probably be fixed.

Again, other than those small issues, all seems well and I'm impressed 
by the better performance.  I'm intending on trying cdparanoia and CD 
burning to see if there is better performance.  Speech always stopped 
with cdparanoia because of the repeating progress bar, so that should be 
a good test.

To Michael and others experiencing problems, I recommend installing the 
new package from Samuel's previous post here.

Re: Latest Debian snapshot

[Samuel Thibault]

Tony Baechler, le Thu 24 Jul 2008 06:18:49 -0700, a écrit :
> First, thank you very much, Samuel!  I was hoping for a new snapshot to 
> be released as a Debian package.  Is there any chance that the new 
> package will make it to Lenny with the big freeze looming?

Lenny is planned to be shipped with 2.6.26, so there will be a new
compilation.  Since reports say a new snapshot would fix serious bugs,
that can go through the freeze.

> I haven't checked if the speech stopping after about 4 KB of text has
> been fixed yet.

It should.

> The two small problems are as follows:  First, I followed Samuel's 
> instructions for building modules.  I did the following commands:
> 
> m-a prepare
> tar -jxf speakup*.tar.bz2
> cd modules/speakup  (I was already in /usr/src)
> make
> make modules_install

Errr.  If you installed a debian speakup-source package then you just
need to run

m-a a-i speakup

The instructions you quote above were for the case when you install by
hand from a git clone and don't really have to do with debian except m-a
prepare that installs the stuff that speakup needs to compile.

> The problems are that it isn't obvious that the Speakup source is 
> installed under /usr/src/modules/speakup.

That's debian policy, but as I said above, forget about
it, just use m-a a-i speakup, which is documented in
/usr/share/doc/speakup-source/README.Debian

> Most packages I've compiled from source use a dash instead, such as
> make modules-install.

I guess these weren't kernel module packages.

> For that matter, why not support "make install" instead?

Because modules_install is the kernel way.  Ask the linux-kernel mailing
list ;)

> The second problem is slightly more serious.  Apparently the Speakup 
> modules must go in /lib/modules/`uname -r`/extra/speakup.  The "make 
> modules_install" command put them in the extra directory but not in 
> extra/speakup.  I had to manually copy them there.  Until I did, it kept 
> loading the old modules, as /sys/module/speakup/version reported 3.0.2.  

Again, that's not a speakup issue, but a more general issue: if you
install both a debian package and do installation by hand, you'll end up
with two versions.  Same for any debian package...

> Now I have two sets of identical Speakup modules, one in the extra/
> directory and another in extra/speakup/.  This should probably be
> fixed.

On your system, yes, because you have installed by hand.  Not a debian
issue actually.

> Again, other than those small issues, all seems well

Ok, cool, I will push that version to Debian.

Samuel

Re: Latest Debian snapshot

[Tony Baechler]

Samuel Thibault wrote:
>> I haven't checked if the speech stopping after about 4 KB of text has
>> been fixed yet.
>>     
>
> It should.
>
>   
Hi,

Sorry, no luck.  I ran cdparanoia which shows a constantly updated 
progress bar.  Speech always stops once the progress bar gets displayed 
because it is constantly changing, even if I interrupt speech.  
specifically, if I run cdparanoia and wait for the progress bar to start 
displaying, hit keypad Enter and keypad 8, I get no speech unless I hit 
a Speakup key about four or five times.  If I hold down the keypad 8 for 
a few seconds and release, speech starts again until the buffer (or 
whatever it is) is full again.
>> The two small problems are as follows:  First, I followed Samuel's 
>> instructions for building modules.  I did the following commands:
>>
>> m-a prepare
>> tar -jxf speakup*.tar.bz2
>> cd modules/speakup  (I was already in /usr/src)
>> make
>> make modules_install
>>     
>
> Errr.  If you installed a debian speakup-source package then you just
> need to run
>
> m-a a-i speakup
>
> The instructions you quote above were for the case when you install by
> hand from a git clone and don't really have to do with debian except m-a
> prepare that installs the stuff that speakup needs to compile.
>
>   
Again, sorry but this doesn't seem to be correct.  I tried that several 
times with the previous snapshot after I installed it and it still 
insisted on running "apt-get install speakup-source" every time, 
regardless whether I did "m-a prepare" first and even though I had 
installed the latest (3.0.2 20080517) snapshot previously several weeks 
ago.  It seems that "m-a a-i speakup" always downloads sources even if 
they are installed.  I had the tar.bz2 archive in /usr/src before even 
trying m-a, so presumably it could find it.  I tried running from within 
/usr/src and other directories.
>> The problems are that it isn't obvious that the Speakup source is 
>> installed under /usr/src/modules/speakup.
>>     
>
> That's debian policy, but as I said above, forget about
> it, just use m-a a-i speakup, which is documented in
> /usr/share/doc/speakup-source/README.Debian
>
>   
Yes, that's fine if you want to install what happens to be available in 
the current Debian release.  A section on installing manually would help 
if you're running Stable and want to install from Unstable, but since it 
seems to always download the sources anyway, maybe it wouldn't matter.
>> Most packages I've compiled from source use a dash instead, such as
>> make modules-install.
>>     
>
> I guess these weren't kernel module packages.
>
>   
I meant packages generally, not modules.  Some packages, for example, 
support "make install-strip" to strip binaries first.


The only remaining problem I see is that speech still stops after about 
4 KB.  I have no other hardware synthesizers to try and I don't have 
software speech installed, so I suppose it could be a DEC-Talk Express 
issue.  I would consider that bug somewhat serious as I've missed 
important information when installing packages because speech suddenly 
stops and by the time I get it to come back, text has long since 
scrolled past.  Apparently there is a scrollback buffer in the kernel 
but I never got it to work.

Re: Latest Debian snapshot

[Gaijin]

On Thu, Jul 24, 2008 at 09:00:11AM -0700, Tony Baechler wrote:
> Apparently there is a scrollback buffer in the kernel  
> but I never got it to work.

	Do you know about the 'script' command that will copy all screen
I/O to a file?  Run without parameters, script will log everything  to a
file in the current directory called "typescript".  Use the "exit"
command to exit console logging.

			Michael

Re: Latest Debian snapshot

[Tony Baechler]

Gaijin wrote:
> On Thu, Jul 24, 2008 at 09:00:11AM -0700, Tony Baechler wrote:
>   
>> Apparently there is a scrollback buffer in the kernel  
>> but I never got it to work.
>>     
>
> 	Do you know about the 'script' command that will copy all screen
> I/O to a file?  Run without parameters, script will log everything  to a
> file in the current directory called "typescript".  Use the "exit"
> command to exit console logging.
>   



Yes, that isn't what I'm interested in.  There's screen (1) as well, 
which in combination with script (1) lets you have multiple windows 
open.  One can also direct logs and such to tty7 and read them with 
Alt+F7 from the console.  I was specifically interested in a scrollback 
buffer that is apparently supposed to be part of the kernel and wouldn't 
require redirecting to a file like you suggest with script (1).  One 
doesn't always know how much output will be generated when running a 
command and often one finds out too late that speech stops and text will 
not be spoken which has scrolled off the screen.  A good example is when 
I cat a README file.  I don't need to make a typescript because it's 
already a file on disk.  I don't really want to reread the file with 
more (1) when only a small amount of text wasn't spoken.  A scrollback 
buffer would be ideal.  Besides, I don't want typescripts taking up 
large amounts of disk space and I don't want to keep a record of every 
command with output for security and privacy reasons.  The .bash_history 
is bad enough.  Thanks anyway for the suggestion though.  That is a good 
idea when upgrading so you can see if anything went wrong and what.

Re: Latest Debian snapshot

[Kerry Hoath]

Handshaking with the dectalk express has allways been a problem; in fact 
asap would lock up nicely if you used the type command to read a long text 
file.

Whilst I understand the desire to send multiple killobytes of text to the 
synth and have speakup do the right thing it raises some interesting points.

the scrollback buffer is finite; and most sighted people pipe to a pager 
rather than shift pageup especially if the text is long.

I have no idea whether speakup supports the kernel scrollback buffer which 
relys on storing text in spare video memory.
I do know however that screen's scrollback buffer does in deed work.
This brings up an interesting question regarding how speakup and Linux 
should behave regarding handshaking.

When the synthesizer indicates buffer full, rts goes low and the software 
sending text should supposedly stop generating synthesizer output.

Ok so what do you do from a Linux perspective? Block console output until 
the synth raises rts?
How long should that blokc happen for? What if rts never goes high again?

Should the console freeze forever thereby introducing the possibility of a 
denial of service attack or should speakup give up and assume synth not 
present?
How long should this process take given that people run their synthesizers 
at different speeds?

Does the screen stop scrolling for a sighted person and does the console 
file descriptor ever block for them?

I certainly would like to see the problem solved; however the problem is not 
as simple as blocking console output when the synthesizer handshakes off.
I also notice many cables for the dectalk distress either have bad wiring or 
the firmware in the device doesn't even handshake reliably.
regards, Kerry.

----- Original Message ----- 
From: "Tony Baechler" <tony@baechler.net>
To: "Speakup is a screen review system for Linux." <speakup@braille.uwo.ca>
Sent: Friday, July 25, 2008 6:04 PM
Subject: Re: Latest Debian snapshot


Gaijin wrote:
> On Thu, Jul 24, 2008 at 09:00:11AM -0700, Tony Baechler wrote:
>
>> Apparently there is a scrollback buffer in the kernel
>> but I never got it to work.
>>
>
> Do you know about the 'script' command that will copy all screen
> I/O to a file?  Run without parameters, script will log everything  to a
> file in the current directory called "typescript".  Use the "exit"
> command to exit console logging.
>



Yes, that isn't what I'm interested in.  There's screen (1) as well,
which in combination with script (1) lets you have multiple windows
open.  One can also direct logs and such to tty7 and read them with
Alt+F7 from the console.  I was specifically interested in a scrollback
buffer that is apparently supposed to be part of the kernel and wouldn't
require redirecting to a file like you suggest with script (1).  One
doesn't always know how much output will be generated when running a
command and often one finds out too late that speech stops and text will
not be spoken which has scrolled off the screen.  A good example is when
I cat a README file.  I don't need to make a typescript because it's
already a file on disk.  I don't really want to reread the file with
more (1) when only a small amount of text wasn't spoken.  A scrollback
buffer would be ideal.  Besides, I don't want typescripts taking up
large amounts of disk space and I don't want to keep a record of every
command with output for security and privacy reasons.  The .bash_history
is bad enough.  Thanks anyway for the suggestion though.  That is a good
idea when upgrading so you can see if anything went wrong and what.
_______________________________________________
Speakup mailing list
Speakup@braille.uwo.ca
http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: Latest Debian snapshot

[Samuel Thibault]

Hello,

I guess it may have to go somewhere in the documentation.

Kerry Hoath, le Fri 25 Jul 2008 18:49:37 +0800, a écrit :
> I have no idea whether speakup supports the kernel scrollback buffer which 
> relys on storing text in spare video memory.

It doesn't currently, due to kernel interface limitations.

> Ok so what do you do from a Linux perspective? Block console output until 
> the synth raises rts?

That is what we are doing currently, by stopping the consoles (just like
if you pressed control-S or the scroll lock key).

> How long should that blokc happen for?

Until the synth has eaten some data

> What if rts never goes high again?
> Should the console freeze forever thereby introducing the possibility of a 
> denial of service attack or should speakup give up and assume synth not 
> present?

Speakup currently does the latter: after a few "full_time" timeouts,
speakup considers the synth to be dead, and thus restart the consoles.

> How long should this process take given that people run their synthesizers 
> at different speeds?

Interesting question, I guess full_time should take into account the
speed.

> Does the screen stop scrolling for a sighted person and does the console 
> file descriptor ever block for them?

Yes.

> I certainly would like to see the problem solved; however the problem is not 
> as simple as blocking console output when the synthesizer handshakes off.

It is not simple indeed, but it's implemented and does work to our
knowledge (William usually tests it with his ltlk for instance).  We
haven't yet figured out why it doesn't for the dectalk express.

> I also notice many cables for the dectalk distress either have bad wiring or 
> the firmware in the device doesn't even handshake reliably.

That would explain it.

Samuel

Re: Latest Debian snapshot

[John covici]

And this is why the Dectalk Express often is set to use xon-xoff -- at
least under windows.

on Friday 07/25/2008 Samuel Thibault(samuel.thibault@ens-lyon.org) wrote
 > Hello,
 > 
 > I guess it may have to go somewhere in the documentation.
 > 
 > Kerry Hoath, le Fri 25 Jul 2008 18:49:37 +0800, a écrit :
 > > I have no idea whether speakup supports the kernel scrollback buffer which 
 > > relys on storing text in spare video memory.
 > 
 > It doesn't currently, due to kernel interface limitations.
 > 
 > > Ok so what do you do from a Linux perspective? Block console output until 
 > > the synth raises rts?
 > 
 > That is what we are doing currently, by stopping the consoles (just like
 > if you pressed control-S or the scroll lock key).
 > 
 > > How long should that blokc happen for?
 > 
 > Until the synth has eaten some data
 > 
 > > What if rts never goes high again?
 > > Should the console freeze forever thereby introducing the possibility of a 
 > > denial of service attack or should speakup give up and assume synth not 
 > > present?
 > 
 > Speakup currently does the latter: after a few "full_time" timeouts,
 > speakup considers the synth to be dead, and thus restart the consoles.
 > 
 > > How long should this process take given that people run their synthesizers 
 > > at different speeds?
 > 
 > Interesting question, I guess full_time should take into account the
 > speed.
 > 
 > > Does the screen stop scrolling for a sighted person and does the console 
 > > file descriptor ever block for them?
 > 
 > Yes.
 > 
 > > I certainly would like to see the problem solved; however the problem is not 
 > > as simple as blocking console output when the synthesizer handshakes off.
 > 
 > It is not simple indeed, but it's implemented and does work to our
 > knowledge (William usually tests it with his ltlk for instance).  We
 > haven't yet figured out why it doesn't for the dectalk express.
 > 
 > > I also notice many cables for the dectalk distress either have bad wiring or 
 > > the firmware in the device doesn't even handshake reliably.
 > 
 > That would explain it.
 > 
 > Samuel
 > _______________________________________________
 > Speakup mailing list
 > Speakup@braille.uwo.ca
 > http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Scrollback and DEC-Talk Express

[Tony Baechler]

Kerry Hoath wrote:
> Handshaking with the dectalk express has allways been a problem; in fact 
> asap would lock up nicely if you used the type command to read a long text 
> file.
>   



Hi,

Your explanation was very interesting and was exactly what I was trying 
to figure out.  Yes, the kernel has a scrollback buffer, which is what I 
wanted to know in the first place.  However, you seem to be overlooking 
something or I'm not understanding.  I'm not feeling well so it could be 
my fault.  That is that in very old versions of Speakup from cvs, I 
could easily cat those same README files to the exact same synthesizer 
and speech would go on forever.  I once let it read every single boot 
message from the kernel starting to the login prompt with no problem.  
It's only now in newer git versions that the 4 KB bug shows up, so I 
still consider it a bug that hasn't been fixed.  I admit that I know 
little of handshaking and serial communication, but before there was no 
problem and now there is.  This can be easily demonstrated with the grml 
1.1rc1 live CD, which still had unlimited text output with speech not 
stopping.  Apparently the final 1.1 release upgraded the Speakup version 
so probably has the bug.  I don't know exactly when the bug happened but 
it goes back to my kernel build from the April git clone and probably 
before that.  I don't remember if the Shane Etch CD has this or not, I 
would have to check.

Scrollback and DEC-Talk Express

[John covici]

In the old days the buffer was much larger -- and I think the Dec Talk
Express was using xon-xoff or maybe its using them now and was using
rts/cts before.  Increasing the buffer size to 12k will at least make
the problem go away for most cases.  Now there is another problem and
that is if there is a lot of characters with no space or word
delimiter then you can get into trouble because this will introduce a
buffer overflow.  I have not tested this for a while, so maybe this
one was fixed.

on Saturday 07/26/2008 Tony Baechler(tony@baechler.net) wrote
 > Kerry Hoath wrote:
 > > Handshaking with the dectalk express has allways been a problem; in fact 
 > > asap would lock up nicely if you used the type command to read a long text 
 > > file.
 > >   
 > 
 > 
 > 
 > Hi,
 > 
 > Your explanation was very interesting and was exactly what I was trying 
 > to figure out.  Yes, the kernel has a scrollback buffer, which is what I 
 > wanted to know in the first place.  However, you seem to be overlooking 
 > something or I'm not understanding.  I'm not feeling well so it could be 
 > my fault.  That is that in very old versions of Speakup from cvs, I 
 > could easily cat those same README files to the exact same synthesizer 
 > and speech would go on forever.  I once let it read every single boot 
 > message from the kernel starting to the login prompt with no problem.  
 > It's only now in newer git versions that the 4 KB bug shows up, so I 
 > still consider it a bug that hasn't been fixed.  I admit that I know 
 > little of handshaking and serial communication, but before there was no 
 > problem and now there is.  This can be easily demonstrated with the grml 
 > 1.1rc1 live CD, which still had unlimited text output with speech not 
 > stopping.  Apparently the final 1.1 release upgraded the Speakup version 
 > so probably has the bug.  I don't know exactly when the bug happened but 
 > it goes back to my kernel build from the April git clone and probably 
 > before that.  I don't remember if the Shane Etch CD has this or not, I 
 > would have to check.
 > _______________________________________________
 > Speakup mailing list
 > Speakup@braille.uwo.ca
 > http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: Scrollback and DEC-Talk Express

[Samuel Thibault]

Hello,

It'd indeed be good to know quite precisely when the bug appeared, as we
currently have no clue where to look at (as I said, it works for other
synths).

Samuel

Re: Scrollback and DEC-Talk Express

[Samuel Thibault]

Hello,

Could you pull the git?  I think I have found an issue with the way we
read XON/XOFF, which may very well explain the synth overflow.

Samuel

Re: Scrollback and DEC-Talk Express

[Samuel Thibault]

Samuel Thibault, le Sat 02 Aug 2008 01:03:49 +0100, a écrit :
> Could you pull the git?

If you have already, could you push again?  I've fixed another issue,
particular to dectlk.

Samuel

Re: Scrollback and DEC-Talk Express

[Tony Baechler]

Samuel Thibault wrote:
> Could you pull the git?  I think I have found an issue with the way we
> read XON/XOFF, which may very well explain the synth overflow.
>   



Hi Samuel,

I don't mean to be stupid, but are you saying that you want me to do a 
git-pull and recompile the modules?  If so, I can do that.  I've 
actually noticed that the problem is worse than I thought.  My kernel 
built after the April pull (I think April 14 but I'm not positive on 
this) stops speaking after about 4 KB of text.  The 20080517 Debian 
modules also stop after the same amount of text.  The new Debian 
20080724 modules stop speaking after about 1 to 1.5 KB of text.  It's 
now at the point where I can't even read a 1500 byte email message with 
full headers.  Even README files that I could read completely before now 
stop speaking after about a screen full of text.  The computer on which 
I have the synthesizer and am doing my tests doesn't have the git 
repository so I'll have to clone from scratch, but I'll try it if it 
fixes the problem.

Re: Scrollback and DEC-Talk Express

[Samuel Thibault]

Tony Baechler, le Sun 03 Aug 2008 03:45:50 -0700, a écrit :
> Samuel Thibault wrote:
> >Could you pull the git?  I think I have found an issue with the way we
> >read XON/XOFF, which may very well explain the synth overflow.
> 
> I don't mean to be stupid, but are you saying that you want me to do a 
> git-pull and recompile the modules?

Yes.

Samuel

Re: Scrollback and DEC-Talk Express

[Tony Baechler]

Tony Baechler wrote:
> Samuel Thibault wrote:
>> Could you pull the git?  I think I have found an issue with the way we
>> read XON/XOFF, which may very well explain the synth overflow.



Hi,

OK, so far success!  The key echo seems very slightly less responsive 
than before, but I can live with that.  It passed the cdparanoia test 
with the progress bar being constantly redisplayed.  I tried reading 
other long text passages and it worked.  I would like to do more testing 
but so far so good.  Thank you very much for fixing this.  I think the 
handshaking was the problem.

Re: Scrollback and DEC-Talk Express

[Samuel Thibault]

Tony Baechler, le Mon 04 Aug 2008 03:37:24 -0700, a écrit :
> OK, so far success!

Cool!
It looks like it has been broken for quite a long time, even in the CVS
actually.

> The key echo seems very slightly less responsive than before, but I
> can live with that.

Mmm I'm not sure what could cause that, except maybe if the synth uses
xon/xoff around the flush, so that we are now waiting for a xon before
echoing the key.

I guess a fix could be to use the index returned by the synth to know
when we really need to trigger a flush.

Note btw that maybe tuning the trigger time would fix it too (see
/sys/modules/speakup/parameters/trigger_time, in ms).

Samuel