[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New to Emacspeak - The Red Hat experience (long)
Tim Cross wrote:
>I had a read of your experiences installing emacspeak with Red Hat. I
>have a couple of comments which I hope come across as some
>constructive criticism and not a personal attack.
No offence taken. Always looking for opportunities to repent and mend my
>I think you may have made one very fatal flaw in your approach. That
>is, you appear to be someone who skims through the documentation and
>then tries to get the system working via making little tweaks and
>changes here and there without really understanding what you are doing
>and hoping that things will all work out in the end. Around here where
>I work, we refer to this as "spiral diving" because this approach
>usually leads to increasing degradation of computer stability and
>performance until it all just crashes into the ground.
Knowing what you're doing can help improve your productivity to some extent.
Still can't understand how projects with wizardly knowing developers lag
behind experimental ones.
I'm sure that if you pedantically track your steps you can safely try
all sorts of crazy things and
still avoid real disasters (and learn from little ones).
In addition, if one is eager to get fast results, that's the price he
has to pay.
>I think the
>situation was also made worse by Red Hat RPM dependency problems,
>which is one reason I moved to Debian - the debian package management
>seems to be a lot more sane when it comes to working out and resolving
>package dependencies. Having said that, I don't yuse any packaging
>system for emacspeak as I like to update regularly from CVS and
>emacspeak itself is a very simple package to configure, compile and
>install - almost too simple to warrant a package IMHO.
>A vital point you appear to have missed in the documentation is that
>there are two tcl packatges - standard tcl and extended tcl. Due to
>historical reasons, this can be a bit confusing as the standard tcl
>uses the name tclsh as its interpreter while extended tcl uses the
>interpreter name tcl. While you may have installed the tcl rpm, what
>you really needed to do was install the extended tcl rpm. This is
>something which you would have realised if you had read ALL the
>documentaiton before embarking on your install.
I have removed the tcl link that I have created in /usr/local/bin .
As suggested by Janina Sajka (thanks), I have rebooted the computer with
Red Hat installation CD in drive.
I have selected to upgrade the system and also marked "customize
packages to be upgraded"
before clicking "next".
In the "Individual Package Selection" page, I have highlighted "All
packages" and chose
"select all in group".
I then proceeded with the (quite long) installation.
One probable mistake was to allow it to update the boot loader.
I later found 3 new GRUB entries: the same kernel version concated to
the strings "smp","bigmem","BOOT".
I don't think that they are useful for me (choosing "BOOT" yields few
errors at start-up, even though
the system is functional, I'll stick with the GRUB entry I know).
No data was lost.
$ which tcl
$ rpm -i emacspeak-18.0-1.i386.rpm
has some conflicts with emacspeak 17 installation (from the upgrade
$ rpm --upgrade emacspeak-18.0-1.i386.rpm
emacspeak is now in /usr/bin . emacspeak-eflite script works, emacspeak
with espeakf still doesn't.
>A second point to keep in mind is that Linux is a fairly complex
>operating system and you really need to know what you are doing before
>you start installing different compiler and library versions. Finding
>you get an error when compiling some piece of software and then
>deciding to install another library or compiler
/usr/bin/gcc296 comes with the distribution (they knew that not everyone
is ready for standard C++).
in the flite directory
$ exprot CC=gcc296
had no affect over config/config, so I chaned it manually
So I had
$ make distclean
and this time I did not have to wait all night for compilation to finish.
still troubled by that warning though, I went on to rebuild eflite.
> and seeing if that
>fixes the problem without first trying to understand what the problem
>is will seldom work and you are likely to introduce problems and
>instability which is often subtile and difficult to identify. I would
>probably go so far as to say never install non-distribution libraries
>or compilers unless you really know what you are doing and first
>establish that you definatley do need to do this.
Not to mention ABI inconsistencies between different compiler versions,
so I had to see
if the eflite compiled with 3.2.2 can link with flite libraries compiled
make clean, make, make install (no configure this time) worked.
>A convention with Makefiles is to have a target called "clean" and
>often one called "distclean" or something similar. You should always
>check to see what targets are available in a makefile and if a make
>fails, you should do a "make clean" or "make distclean" before trying
>again to compile the system. If you do a make which fails and then add
>some new libraries, programs etc and then just type make again, the
>make process will continue from the point at which it failed. This can
>result in inconsistencies between the already created/compiled
>programs fromt he first attempt and later attempts. Doing the make
>clean will ensure you start with all object files and binaries at a
>known and more predictable point.
I wouldn't advice anyone to link mixed objects built with different
compilers unless as an experiment.
>A very important step to take to avoid the spiral diving problem is to
>keep track of what you do and when you make some change in an attempt
>to fix a problem, if it does not fix the problem, undo your changes,
>re-analyse the problem and try alternative solutions. Failing to undo
>changes when they don't appear to have fixed the problem will result
>in you moving into an "unknown state" where, if you are lucky enough
>to stumble onto a solution you will be uncertain exactly what
>combination of changes fixed the problem, plus you are likely to
>introduce additional problems which just muddy the waters.
Hope that my installation notes help to show how change logs are
essential (reading manuals also helps).
>Finally, an attitude which I've found very useful when trying to get
>things like emacspeak working is that if it doesn't work, its
>something I have done wrong, not a problem with the software or
>hardware. You are working with a software
>package used by a lot of people on a wide variety of
>platforms/distributions. If you cannot get the system to work,
>the probability is very high the error is due to something you are not
>doing correctly due to some misunderstanding in the installation
>procedures or an over-looked step. Due to the fairly large user base,
>problems in the software or its ability to work with certain hardware,
>are usually identified pretty quickly. This is especially true with
>respect to Red Hat as this is the distribution Raman uses and develops
>emacspeak on. As a Debian user, I can expect some minor glitches when
>first installing emacspeak due to the slight differences in
>installations. Generally, this is fairly trivial to work out and
>solve as long as you adopt a methodical approach, keep track of any
>changes you do and reverse changes once it appears they have not
>solved the problem.
I know that now.
>One final comment regarding your mention of killing comilation jobs
>because they appeared to be taking too long or appeared to
>hang. Depending on the software and your hardware, comilation can be a
>very slow process. Some years ago, I had a linux box which would take
>nearly 30 hours to compile the kernel.
Some notion that it is still alive would be nice. Just remembered the
"-Q" switch. add it to the CFLAGS
and you won't get a boring screen.
>I admit this was a fairly slow
>system with little memory, but it was also with an old 2.0 kernel
>which was a lot smaller than the current kernels. Once the kernel had
>compiled and was installed the system was very usable with emacs and
>emacspeak under a console - I even ran X windows on it from time to
>time and it was still usable. With the speed of modern computers, many
>people have become use to software compiling in seconds or
>minutes. However, this is very much a function of not just the
>hardware platform, but also the type of software being compiled. Some
>packages can be very slow to build and it is quite rare for a stable
>release of something to just go into an infinite loop when it is being
>compiled. So, be very reluctant to interrupt a compilation and if you
>do, make sure you do a make clean and a re-configure before attempting
>any subsequent compilations. When things go wrong, research possible
>causes - re-read documentation, search through archives and do a
>google for answers etc. Only attempt changes and modifications once
>you feel you have a good idea what the problem is and keep track of
>what you do.
>>>>>>"Barak" == Barak Zalstein <email@example.com> writes:
> Barak> New user Installing emacspeak - The Red Hat experience.
> Barak> Prerequisite: Not much.
> Barak> Introduction: As a supplemental to a previous thread (Advice
> Barak> for a new user) Here are my notes from my experience
> Barak> installing emacspeak on a fresh Red Hat 9. The ordering of
> Barak> the sections/events is chronological, but not necessarily
> Barak> logical ;-)
> Barak> The first 3 steps may be considered off-topic, people who know
> Barak> their way around GNU/Linux should feel free to skip them.
> Barak> These steps still might be useful if you're in a culture
> Barak> shock, though.
> Barak> About notation: I am using the $ (dollar) symbol as the
> Barak> beginning of command lines that I have executed (either from a
> Barak> terminal or from an Emacs shell buffer). Of course, you'll
> Barak> need to try them yourself because as my familiarity with Emacs
> Barak> grew, I started using dired mode commands instead of typing
> Barak> them in a shell (so I might have forgotten few change
> Barak> directory commands here and there). I also stopped tracking
> Barak> where I'm root and where I'm not because at one point I
> Barak> started using multiple terminals for that. If you see that one
> Barak> of the commands results with "permission denied" you'll know
> Barak> that you need to: $ su
> Barak> I have written this in a style that should allow one to
> Barak> follow-me follow-me, even if he/she is completely clueless,
> Barak> but someone will have to try this out, (probably with a little
> Barak> rewriting/adaptation to other distributions).
> Barak> Let's go.
> Barak> 1. Download and burn Red Hat 9 CD #1 to CD #3. One can use
> Barak> ftp.redhat.com or (faster) bittorrent for that. Note that you
> Barak> can actually buy these CDs instead, as a token of good will
> Barak> toward Red Hat developers. (I know that Free speech is not
> Barak> the same as Free beer. But when the price is zero, what's the
> Barak> difference, who cares?).
> Barak> 2. Reboot from CDROM and Install the system. I have chosen to
> Barak> install using the graphical display and also chose the
> Barak> workstation among the suggested setups (I knew I'll need GCC
> Barak> sooner rather than later so desktop setup would probably not
> Barak> be good enough, I can't rationalize why I didn't choose the
> Barak> server setup, I didn't choose the customized setup because I
> Barak> wanted to get over with the installation as quickly as
> Barak> possible). The rest of the installation is practically
> Barak> clicking "yes, yes, yes, next, next, next". I was surprised
> Barak> that the sound test was successful (remembering that Red Hat
> Barak> 8.0 didn't get along with my sound hardware), which means that
> Barak> I will not need to compile ALSA today.
> Barak> 3. Now I was stuck. I couldn't connect to the internet as my
> Barak> USB ADSL modem was not supported by this distribution yet.
> Barak> From my previous GNU/Linux experience I knew that I have to
> Barak> get an eciadsl driver. Unfortunately, NTFS was not supported,
> Barak> so even if I had the software packages that I needed on my
> Barak> Windows partition, I would not be able to access them.
> Barak> Fortunately I was able to use an internet connected computer +
> Barak> CD burner for getting and burning that ADSL driver
> Barak> (eciadsl-usermode-0.7). The installation process of that
> Barak> driver, along with mplayer (a video/audio playback utility) is
> Barak> clearly beyond the scope of this text.
> Barak> Let's just say that in order to proceed further with Emacspeak
> Barak> I needed to verify that my system has some basic
> Barak> functionality. I checked that by using commands like: $ wget
> Barak> www.gnu.org Got index.html in the working directory, which
> Barak> means that my internet connection is OK. $ mplayer
> Barak> am_I_a_pirate.mp3 If it can play sound files, surely it can
> Barak> synthesize speech.
> Barak> I later also installed lynx so I'll be able to surf and
> Barak> download stuff without going to graphical mode. I think that
> Barak> this will also help me improve my not-using-a-mouse skills
> Barak> (even though there's nothing wrong with Mozilla or other
> Barak> preinstalled browsers).
> Barak> 4. On with the emacspeak installation: In order to get the
> Barak> software packages that I need, I have used google to search
> Barak> for the terms "emacspeak", "espeakf", "eflite" and just
> Barak> followed the links. I ended up with the following things to
> Barak> do: * wget
> Barak> http://heanet.dl.sourceforge.net/sourceforge/emacspeak/emacspeak-18.tar.gz
> Barak> $ tar zxvf emacspeak-18.tar.gz $ cd emacspeak-18.0 $ less
> Barak> README $ make config
> Barak> That command failed with the error: " emacs -batch -q
> Barak> -no-site-file -l cus-dep.el -f custom-make-dependencies "."
> Barak> Cannot open load file: cus-dep.el make: *** [cus-load.el]
> Barak> Error 255 make: Leaving directory
> Barak> `/home/barak/downloads/emacspeak-18.0/lisp' make: *** [config]
> Barak> Error 2 "
> Barak> Maybe the error happend because I was running it from an Emacs
> Barak> shell buffer? Trying the same command from the command line
> Barak> didn't help. Check if the README/INSTALL file has something
> Barak> about it. README points to Makefile, INSTALL file
> Barak> nonexistent. The Makefile comments tell me that I should do $
> Barak> make config SRC=`pwd` Didn't help. Ok, maybe I'll check it
> Barak> later, trying the RPM package. $ rpm -i
> Barak> emacspeak-18.0-1.i386.rpm "error: Failed dependencies: tclx is
> Barak> needed by emacspeak-18.0-1"
> Barak> Ok, here's tclx package on cd #3. $rpm -i
> Barak> /mnt/cdrom1/RedHat/RPMS/tclx-8.3-88.i386.rpm "error: Failed
> Barak> dependencies: libtk8.3.so is needed by tclx-8.3-88"
> Barak> What have I done to deserve this? (BTW, I saw no graphical
> Barak> tool to handle these specific packages, except for right
> Barak> clicking the rpm file which didn't work neither).
> Barak> RedHat CD #3 contains emacspeak-17.0 RPM, with a similar
> Barak> dependency nightmare. Going like crazy over every package
> Barak> that seems relevant and doing "rpm -i" was futile.
> Barak> 5. Short break: Interstingly, RedHat CD #1 contains
> Barak> README-Accesibility which refers to Emacspeak. It also
> Barak> mentions w3 and recommends installing it by $ rpm -ivh
> Barak> ftp://people.redhat.com/jlamb/w3-4.0pre.44-1.i386.rpm Luckily
> Barak> no dependencies this time. Running it from Emacs doesn't seem
> Barak> to work, though: "Cannot open load file: w3-e21".
> Barak> 6. Completing Emacspeak package build: Let's try Emacspeak 17
> Barak> from source, or shall we go doing something else? Remembering
> Barak> the original Emacspeak 18 error I tried to locate the missing
> Barak> file. From Emacs, the command M-x locate, with cus-dep.el as
> Barak> parameter yields: /usr/share/emacs/21.2/lisp/cus-dep.elc Oh, I
> Barak> see. The RedHat installation had a byte-compiled version of
> Barak> the cus-dep.el file that Emacspeak needs.
> Barak> So if I had installed Emacs from source everything would just
> Barak> be fine, right? $ wget ftp.gnu.org/gnu/emacs got index.html I
> Barak> browsed it using lynx and learned that if I want to be updated
> Barak> and stable I'll need to get emacs-21.3.tar.gz (I should
> Barak> probably set up my Emacs so that the command
> Barak> browse-url-of-buffer will use lynx as default). $ wget
> Barak> ftp.gnu.org/gnu/emacs/emacs-21.3.tar.gz $ tar zxvf
> Barak> emacs-21.3.tar.gz Skimming through the README and INSTALL
> Barak> files reveals that what I need to do is: $ ./configure $ make
> Barak> as root: $ make install And that's all is needed from the GNU
> Barak> Emacs side.
> Barak> So I came back to the extracted emacspeak-18.0 directory and
> Barak> type $ make config Yes! No errors, and it told me "Now type
> Barak> make emacspeak". $ make emacspeak Again, smooth, no errors,
> Barak> and it told me: "Now check installation of the speech server.
> Barak> See Makefile for instructions." And I did. The most
> Barak> important piece of information is that Emacspeak is using tcl
> Barak> and I should probably have one before moving on to
> Barak> eflite/espeakf. $ which tcl "/usr/bin/which: no tcl in
> Barak> (/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/barak/bin)
> Barak> ". Oh no, not again. I was sure that my earlier rpm bashing
> Barak> had installed tcl at least 3 times.
> Barak> 7. Installing tcl Forget the RPM, I'm going to the source.
> Barak> Where can I get it? Google for "tcl", "download" .
> Barak> www.tcl.tk is the place. It also has precompiled binaries, so
> Barak> it's ok if I chicken. Using lynx for downloading the files
> Barak> failed so I had to switch from my comfortable text terminal
> Barak> back to X and launched Mozilla. I later learned that when
> Barak> using lynx, downloading a file and saving a file are two
> Barak> different actions (one doesn't mean the other, yes to one may
> Barak> be a no to the other).
> Barak> I guess that's a proper place to mention that Control-Alt-F1
> Barak> up to Control-Alt-F6 key combinations switch between various
> Barak> text terminals (easier to read with my glaucoma) and
> Barak> Control-Alt-F7 brings us back to the graphical screen.
> Barak> Anyway, $ tar zxvf tcl8.4.2-src.tar.gz simile with README,
> Barak> unix/README. $ cd tcl8.4.2/unix $ ./configure $ make as root
> Barak> $ make install
> Barak> $ which tcl still can't find it. Reading the unix/README and
> Barak> the output of "make install" gave me an idea: maybe I'll just
> Barak> do as root: $ ln -sf /usr/local/bin/tclsh8.4
> Barak> /usr/local/bin/tcl
> Barak> Am I sure that I know what I'm doing? The next steps will
> Barak> tell.
> Barak> 8. Install a speech synthesizer. Unlike espeakf, I already
> Barak> got eflite to work in the past, so I probably should start
> Barak> with what I know. Now might be a good time to freshen up my
> Barak> memory with
> Barak> http://www.cs.vassar.edu/~priestdo/emacspeak/msg01099.html in
> Barak> order to prepare for the next steps. There is no harm in
> Barak> typing $ make install from the directory where I've extracted
> Barak> and built emacspeak-18.0d, as I'm going to use the other
> Barak> scripts anyway.
> Barak> $ tar zxvf flite-1.2-release.tar.gz $ cd flite-1.2-release
> Barak> checking out README (no INSTALL file, but the README has the
> Barak> info) Even if you are not a programmer, It is always
> Barak> interesting to browse the soruce directory. For example,
> Barak> while checking the COPYING file, I learned that flite is free
> Barak> software but released under a different license than the GPL.
> Barak> $ ./configure $ make No, the computer is not dead. It's just
> Barak> compiling very large files. Ok, it is stuck for too long in:
> Barak> " gcc -I../../lang/usenglish -I../../lang/cmulex
> Barak> -I../../include -g -O2 -Wall -c cmu_us_kal16_diphone.c -o
> Barak> cmu_us_kal16_diphone.o"
> Barak> Let's change -O2 to -O0 and hope that it will solve it. $ cd
> Barak> ~/downloads/flite-1.2-release/lang/cmu_us_kal16/ $ gcc
> Barak> -I../../lang/usenglish -I../../lang/cmulex -I../../include -g
> Barak> -O0 -Wall -c cmu_us_kal16_diphone.c -o cmu_us_kal16_diphone.o
> Barak> Few minutes later... Well, I'm killing it. (Later
> Barak> Examination of the C file reveals that optimization level
> Barak> probably doesn't matter in this case, as we are compiling a
> Barak> file with very large data arrays). Compilers, can't live with
> Barak> them, can't shoot them.
> Barak> Let's see if we have any alternative on the system. $ gcc
> Barak> (and pressing tab instead of enter) Found gcc296, not an
> Barak> _official_ GCC release but still one of my favorites. $
> Barak> gcc296 -I../../lang/usenglish -I../../lang/cmulex
> Barak> -I../../include -g -O0 -Wall -c cmu_us_kal16_diphone.c -o
> Barak> cmu_us_kal16_diphone.o That almost worked like a charm, except
> Barak> for the following message: "/tmp/ccqPRq3D.s: Assembler
> Barak> messages: /tmp/ccqPRq3D.s:2165899: Warning: .stabs:
> Barak> description field '10002' too big, try a different debug
> Barak> format"
> Barak> I give up building flite, let's see what about eflite
> Barak> $ tar zxvf eflite-0.3.6.tar.gz $ cd eflite-0.3.6 Tired of
> Barak> typing configure make and make install, maybe I'll prepare a
> Barak> script called "the_usual_please.csh" . But not this time: The
> Barak> INSTALL also tells me that configure needs to accept an
> Barak> additional switch, so I configure it like this: $ ./configure
> Barak> flite_dir=/home/barak/downloads/flite-1.2-release The INSTALL
> Barak> file tells me that I don't need to install flite, I only need
> Barak> flite libraries, so maybe it will work after all without
> Barak> successfully building flite. $ make Surprisingly, the make
> Barak> process is finished successfully. $ make install
> Barak> Now I prepare the emacspeak-eflite script as discussed in the
> Barak> emacspeak mailing list archives:
> Barak> #!/bin/sh ## /usr/local/bin/emacspeak-eflite - execute emacs
> Barak> with speech enhancements ## use EFLITE
> Barak> ## based on #$Id: emacspeak.sh.def,v 17.0 2002/11/23 01:29:08
> Barak> raman Exp $
> Barak> if [ -f $HOME/.emacs ] then INITSTR="-l $HOME/.emacs" fi
> Barak> CL_ALL="" for CL in $* ; do if [ "$CL" = "-o" ]; then
> Barak> DTK_PROGRAM=outloud export DTK_PROGRAM elif [ "$CL" = "-d" ];
> Barak> then DTK_PROGRAM=dtk-soft export DTK_PROGRAM elif [ "$CL" =
> Barak> "-q" ]; then INITSTR="" else CL_ALL="$CL_ALL $CL" fi done
> Barak> export EMACS_UNIBYTE=1 #export DTK_TCL=/usr/bin/eflite export
> Barak> DTK_TCL=/usr/local/bin/eflite
> Barak> exec emacs -q -l
> Barak> /usr/share/emacs/site-lisp/emacspeak/lisp/emacspeak-setup.el
> Barak> $INITSTR $CL_ALL ### end /usr/local/bin/emacspeak-eflite
> Barak> $ chmod +x emacspeak-eflite $ cp emacspeak-flite
> Barak> /usr/local/bin
> Barak> $ emacspeak-eflite It's alive!!!
> Barak> 9. Make typing a bit more comfortable. In order to minimize
> Barak> the number of awkward positions for my fingers. I needed to
> Barak> exchange the location of Caps-Lock and Control. (After blind
> Barak> typing for awhile in Emacs, you find out that you move a lot
> Barak> using the Control and Alt/Meta keys, so you want to make your
> Barak> hand move as little as possible before pressing it).
> Barak> Ok, so where is emacs2.kmap.gz?
> Barak> M-x locate with emacs2.kmap as parameter. nothing, but I
> Barak> found: /lib/kbd/keymaps/i386/qwerty/emacs2.map.gz so opened
> Barak> the directory /lib/kbd/keymaps/i386/qwerty/ as an Emacs dired
> Barak> buffer and executed the shell command on the file
> Barak> emacs2.map.gz by putting point on the start of the file name,
> Barak> pressing the '!' key (that's exclamation mark) and typing
> Barak> "loadkeys " (without the quotation marks). It worked. In
> Barak> which file shall I put this command so that it will be invoked
> Barak> when system starts up? I guess that .bashrc is good enough,
> Barak> is it? I've logged into another terminal and saw that it
> Barak> works. I'll save the graphical user interface for later.
> Barak> 10. Time to festival. It's late, give me a decent RPM,
> Barak> please. rpmfind.net is where to go. The search engine in
> Barak> that site gave a proper link where to download one such rpm,
> Barak> a.k.a festival-1.4.2-16.i386.rpm $ rpm -i
> Barak> festival-1.4.2-16.i386.rpm Good, let's see that it works. $
> Barak> festival Festival starts with an interactive prompt $ (SayText
> Barak> "Please say something") And it does. $ (quit)
> Barak> 11. Going for espeakf. $ cvs -d
> Barak> :pserver:firstname.lastname@example.org:/cvsroot/espeakf
> Barak> login $ (pressing Enter as password) $ cvs -d
> Barak> :pserver:email@example.com:/cvsroot/espeakf
> Barak> co espeakf The README says that copying the .pl file is
> Barak> sufficient, but since we have as Makefile with an "install:"
> Barak> rule, why wouldn't we just type: $ make install Wait, not so
> Barak> fast. the line saying "DESTDIR=" should be changed into
> Barak> something more meaninguful, something like: "DESTDIR=
> Barak> /usr/local/bin" $ make install That was stupid, should have
> Barak> read the Makefile more carefully. Undo changing DESTDIR.
> Barak> The README also says that I should do: $ export DTK_TCL=perl $
> Barak> export DTK_PROGRAM=espeakf.pl I wonder what will happen if
> Barak> I'll type $ emacspeak (instead of running a customized script)
> Barak> Ok, Emacs is up and I face the same problem that I had on
> Barak> SuSE: It will only say special characters '?' (question mark)
> Barak> and '#' (pound). Wonder if I should debug it and improve my
> Barak> perl skills or should I just switch to another distribution
> Barak> (Debian?) and see what's going on there. Avoiding this
> Barak> problem won't make it go away, but I'll probably just dismiss
> Barak> it for awhile.
> Barak> -----------------------------------------------------------------------------
> Barak> To unsubscribe from the emacspeak list or change your address
> Barak> on the emacspeak list send mail to
> Barak> "firstname.lastname@example.org" with a subject of
> Barak> "unsubscribe" or "help"
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "email@example.com" with a
subject of "unsubscribe" or "help"
Emacspeak Files |
Unsubscribe | Search