Is slackbuilds good for this?

[Unknown]

I've got:
http://slackbuilds.org/howto/
http://slackbuilds.org/howto/versions/
http://slackbuilds.org/faq/

But people who KNOW aren't quaified to test nor see what's missing in the
docos. And I think my query should have been IN FRONT of slackbuilds'
docos. Am I right that slackbuilds is to syncronise the latest version of
an application, with the latest version [and 'versions' can do earlier]
of slackware?

So then, then the first step would be to check if slackbuilds DOES the
specific app. And that means that slackbuild must have a list of apps
which it currently handles?

I badly want to get a running version of <festival: TextToSpeech>.
3 different users claim to have the prior to the latesst v2.1 running.
The web-page and mail-list of this substantial university based project
is dead since 2010. What happened after 2010, that I don't know about?
Has apple changed the computing world or what?

Festival seems to have been very bleeding-edge and requiring the version
to be matched with same-date versions of gcc, make, configure; judging
from the doco which admits:-------
Hopefully we have now sanitized the code sufficiently to to make it
possible for ports to other C++ compilers without too much
difficulty. But please note C++ is not a fully standardized language
and each compiler follows the incomplete standard to various
degrees. Often there are many but simple problems when porting to new
C++ compilers. We are trying to deal with this by increasing our
support. However, it is likely that small changes will be required for
C++ compilers we have not yet tested the system under.
======================== end of doco extract ====

This problem of the latest app needing to be tuned, and hanging by it's
fingernails onto the latest/matching OS-suite, seems to be demonstrated
by the fact that the SAME *.tar.gz gave 3 DIFFERENT `du` when attemped to
be <installed> by: Slakware13, a-fork-of-slakware with a kernel just a few
months older than slakware13, DebianLenny [ca 2009].

The absurd alternative which we are possibly moving towards, is to get
the application, with the MATCHING OS.

WDYS?

[Unknown]

[Ron Gibson]

On Tue, 4 Dec 2012 22:56:00 +0000 (UTC), Unknown <d...@gmail.com> wrote:

> Am I right that slackbuilds is to syncronise the latest version of
>an application, with the latest version [and 'versions' can do earlier]
>of slackware?

Not really. It is an option for applications not included in the distro
with a script so that the compilation can be handled by Slackware
package tools.

Being the "latest version" is an extra plus.

[Grant]

And, how hard is it to look up the sources and find latest versions?

Grant.

[Dan C]

It's not hard. However, that doesn't mean that latest version of source
code will work with the provided Slackbuild script. Sometimes there are
patches involved, and/or different compression schemes.

The purpose of Slackbuilds is NOT to provide the "latest version" of
anything.


--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
"Bother!" said Pooh, as he downed his twelfth Guinness.
Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/
Thanks, Obama: http://brandybuck.site40.net/pics/politica/thanks.jpg

[Aaron W. Hsu]

Dan C wrote:

> It's not hard. However, that doesn't mean that latest version of source
> code will work with the provided Slackbuild script. Sometimes there are
> patches involved, and/or different compression schemes.
>
> The purpose of Slackbuilds is NOT to provide the "latest version" of
> anything.

Indeed, there are times when the latest version of things is specifically
not put as the default slackbuild for reasons of dependencies or the like.

On the other hand, while it is possible that the latest version of a source
will not work with a SlackBuild, it is very often the case that newer
sources will work without significant modification of the script, or with
very little alteration. Thus, if you really want the newer version of the
software, it's worth it to try the original slackbuild and see if it works
cleanly.

--
Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

[Unknown]

On Wed, 05 Dec 2012 00:19:55 -0500, Aaron W. Hsu wrote:

> Dan C wrote:
>
>> It's not hard. However, that doesn't mean that latest version of
>> source code will work with the provided Slackbuild script. Sometimes
>> there are patches involved, and/or different compression schemes.
>>
>> The purpose of Slackbuilds is NOT to provide the "latest version" of
>> anything.
>
> Indeed, there are times when the latest version of things is
> specifically not put as the default slackbuild for reasons of
> dependencies or the like.
>
> On the other hand, while it is possible that the latest version of a
> source will not work with a SlackBuild, it is very often the case that
> newer sources will work without significant modification of the script,
> or with very little alteration. Thus, if you really want the newer
> version of the software, it's worth it to try the original slackbuild
> and see if it works cleanly.

Is this a valid mental-model:---------

A [two-dimensional] matrix lists the currently-handled-pakages,
against the SlakwareVersions [currently 14 & 13]
As new versions of Slakware are introduced, the <spreadsheet> rolls on
and as/if new work is done to hand-craft packages to fit the new version,
then the corresponding element-of-the-spreadsheet is filled in.
-------------

Then obviously, the first step to know if slackbuilds can help you
is to find the list of packages that it currently handles for ANY
slakware version. So this list should be UP FRONT. I can't find it in:

[Dan C]

How long have you been smoking crack?

Probably about time to quit.

--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".

"Bother!" said Pooh, as his U-Boat sank another hospital ship.

[Dan C]

On Wed, 05 Dec 2012 00:19:55 -0500, Aaron W. Hsu wrote:

> Dan C wrote:
>
>> It's not hard. However, that doesn't mean that latest version of
>> source code will work with the provided Slackbuild script. Sometimes
>> there are patches involved, and/or different compression schemes.
>>
>> The purpose of Slackbuilds is NOT to provide the "latest version" of
>> anything.
>
> Indeed, there are times when the latest version of things is
> specifically not put as the default slackbuild for reasons of
> dependencies or the like.
>
> On the other hand, while it is possible that the latest version of a
> source will not work with a SlackBuild, it is very often the case that
> newer sources will work without significant modification of the script,
> or with very little alteration. Thus, if you really want the newer
> version of the software, it's worth it to try the original slackbuild
> and see if it works cleanly.

Yes, I agree completely.

--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".

"Bother!" said Pooh, as he inserted the suppository.

[geep]

FWIW below is my recipe used on Slack 13.37 x86_64 when I played with it
last year. It builds festival locally.
You can see the 10 tar balls used to build festival.
Don't remember any other prerequisites.
Anyway, I prefered espeak).
Cheers,
Peter

#!/bin/sh

gcc -v
uname -a
mkdir build
cd build

tar zxvf ../speech_tools-2.1-release.tar.gz
tar zxvf ../festival-2.1-release.tar.gz
tar zxvf ../festlex_CMU.tar.gz
tar zxvf ../festlex_POSLEX.tar.gz
tar zxvf ../festlex_OALD.tar.gz
tar zxvf ../festvox_kallpc16k.tar.gz
tar zxvf ../festvox_rablpc16k.tar.gz
tar zxvf ../festvox_cmu_us_slt_arctic_hts.tar.gz
tar zxvf ../festvox_cmu_us_awb_cg.tar.gz
tar zxvf ../festvox_cmu_us_rms_cg.tar.gz

export DESTDIR=`pwd`/speech_tools

cd speech_tools
./configure
make -j 2
cd ..

cd festival
./configure
#make -j 2 #get compile errors with this on slack13.37 x86_64
make

cd ../speech_tools
make test
cd ../festival
make test
cd ../..

echo '(SayText "Hello Slackware User")' \
| ./build/festival/bin/festival --pipe

[root]

geep <ge...@nowhere.org> wrote:
> FWIW below is my recipe used on Slack 13.37 x86_64 when I played with it
> last year. It builds festival locally.
> You can see the 10 tar balls used to build festival.
> Don't remember any other prerequisites.
> Anyway, I prefered espeak).
> Cheers,
> Peter

Some change in Slackbuilds for 13.37 has broken all the
scripts. Somewhere in the slackbuild scripts there is a line:
cd $PRGNAM-$VERSION

this line has to be changed to :
cd /tmp/SBo/$PRGNAM-$VERSION

If there was an announcement to this effect I missed the message.

[Chick Tower]

On 2012-12-05, Unknown <d...@gmail.com> wrote:
> Then obviously, the first step to know if slackbuilds can help you
> is to find the list of packages that it currently handles for ANY
> slakware version. So this list should be UP FRONT. I can't find it in:
> http://slackbuilds.org/howto/
> http://slackbuilds.org/howto/versions/
> http://slackbuilds.org/faq/

You can search for the specific programs you're interested in for all
versions of Slackware or for one particular version. You can view lists
of all the programs supported in categories created by the managers of
slackbuilds.org, which sounds like what you asked for.

I believe there are other websites for slackbuilds, such as slacky.eu.
They might have a slackbuild for festival if slackbuilds.org does not.
--
Chick Tower

For e-mail: aols2 DOT sent DOT towerboy AT xoxy DOT net

[Ron Gibson]

On Thu, 6 Dec 2012 18:25:17 +0000 (UTC), Chick Tower
<c.t...@deadspam.com> wrote:

>You can search for the specific programs you're interested in for all
>versions of Slackware or for one particular version. You can view lists
>of all the programs supported in categories created by the managers of
>slackbuilds.org, which sounds like what you asked for.

>I believe there are other websites for slackbuilds, such as slacky.eu.
>They might have a slackbuild for festival if slackbuilds.org does not.

I know you know this but some may not. Of course you don't HAVE to make
a slack package. You can just build it from source usually but it is
often more difficult and no package entry in /var/log/packages.

[Henrik Carlqvist]

On Thu, 06 Dec 2012 19:55:43 -0500, Ron Gibson wrote:
> Of course you don't HAVE to make a slack package. You can just build
> it from source usually but it is often more difficult and no package
> entry in /var/log/packages.

Using an existing build script might be easier than to install manually
from source, but writing your own build script takes more skills than
doing the source installation without any build script.

If you don't have any build script but still want the entry in /var/log/
packages there is a tool called checkinstall. Instead of writing "make
install" you simply write "checkinstall" and it will not only give you
the entry in /var/log/packages but also a Slackware package to install on
more machines.

The home page of checkinstall is
http://asic-linux.com.mx/~izto/checkinstall/ and the latest version is
1.6.2, but I prefer version 1.5.3 myself, you can download 1.5.3 from
http://sourceforge.net/projects/makepack/files/tools/

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[Sylvain Robitaille]

On 07 Dec 2012 07:40:31 GMT, Henrik Carlqvist wrote:

> ... writing your own build script takes more skills than doing the

> source installation without any build script.

Not really. Have a look at
http://www.therockgarden.ca/software/slackware/template.SlackBuild

It should be very clear where any edits are required, and there are a
fair number of packages (such as any which don't require much in the way
of configure options) with which it works just fine as is.

It's a great way to help ensure packages are built consistently.

--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------

[Chick Tower]

On 2012-12-06, root <NoE...@home.org> wrote:
> Some change in Slackbuilds for 13.37 has broken all the
> scripts. Somewhere in the slackbuild scripts there is a line:
> cd $PRGNAM-$VERSION
>
> this line has to be changed to :
> cd /tmp/SBo/$PRGNAM-$VERSION
>
> If there was an announcement to this effect I missed the message.

They seem to work fine for me on 13.37. I use sbopkg to run Slackbuilds
from Slackbuilds.org.

[Henrik Carlqvist]

On Fri, 07 Dec 2012 18:07:34 +0000, Sylvain Robitaille wrote:
>> ... writing your own build script takes more skills than doing the
>> source installation without any build script.
>
> Not really. Have a look at
> http://www.therockgarden.ca/software/slackware/template.SlackBuild
>
> It should be very clear where any edits are required, and there are a
> fair number of packages (such as any which don't require much in the way
> of configure options) with which it works just fine as is.

I wouldn't say that it takes a lot more skills to write a slackbuild
script, but even with a good template it takes a little more skills than
installing manually from source.

For some simple software which installs without any fuzz we can compare
the following work:

To write a slackbuild script:
1) <insert your favorite editor here> foo.SlackBuild
2) edit the line with the version of the program
3) save the file
4) run the script

To install from source:
1) tar xvf foo-1.2.3.tar.gz
2) cd foo-1.2.3
3) ./configure
4) make
5) sudo make install

In the above example I wouldn't say that one method takes more skills
than the other. The tricky part comes with software which doesn't work
out of the box with the "generic installation instructions". First you
will have to figure out how the software needs to be installed. Maybe it
needs some extra configure flags, maybe it doesn't build by simply
running "make" and maybe it doesnt use make to install but some weird
script or maybe it even relies on manually copying files. Once you have
figured out how to install the software manually you can automate this in
a script, but while figuring this out I would guess that most people do
some try and error by the prompt to later implement the script rather
than doing try and error edits of the script.

> It's a great way to help ensure packages are built consistently.

Yes, one of the main advantages with mechanisms like SlackBuild scripts
is that it is well documented how you once built and installed the
software.

[Sylvain Robitaille]

On 07 Dec 2012 20:24:35 GMT, Henrik Carlqvist wrote:

> ... but even with a good template it takes a little more skills

> than installing manually from source.
>
> For some simple software which installs without any fuzz we can
> compare the following work:
>
> To write a slackbuild script:
> 1) <insert your favorite editor here> foo.SlackBuild
> 2) edit the line with the version of the program
> 3) save the file
> 4) run the script

It can be simpler than that:

1) env VERSION=1.0 ./foo.SlackBuild
2) installpkg /tmp/foo-1.0-i686-1.tgz

Versus:

> To install from source:
> 1) tar xvf foo-1.2.3.tar.gz
> 2) cd foo-1.2.3
> 3) ./configure
> 4) make
> 5) sudo make install

> ... The tricky part comes with software which doesn't work

> out of the box with the "generic installation instructions".

Yes. Trial-and-error is indeed best done outside of the script.
But in a case like that, you're going to be trial-and-error-ing
anyway, so it isn't that much more effort to followup, after you get
a successful build, with putting in the required edits to the template
script, then using it to build a proper package and installing that.

Most times (unless I already know "configure; make; make install"
won't get the expected result) my first pass at trial-and-error is
calling the script exactly as I demonstrated above. If that fails,
I start reading installation documentation, "configure --help" output
and whatnot (well, truth be told, I pretty much always read such
documentation quickly before even trying the first pass, but if the
first pass fails, I start *really* reading it).

> ... one of the main advantages with mechanisms like SlackBuild

> scripts is that it is well documented how you once built and
> installed the software.

Absolutely.

[no.to...@gmail.com]

In article <k9qfoi$n30$1...@speranza.aioe.org>, geep <ge...@nowhere.org> wrote:

> On Tue, 04 Dec 2012 22:56:00 +0000, Unknown wrote:

> FWIW below is my recipe used on Slack 13.37 x86_64 when I played with
> it last year. It builds festival locally.
>

Thanks.

> You can see the 10 tar balls used to build festival.
> Don't remember any other prerequisites.
> Anyway, I prefered espeak).

If I live long enough [I started on festival 6 months ago]
I might try espeak; but I've opened this canOworms, so
I must eat it.

This has become more than about festival.
It's now about my method - false logic.
Please see queries IN your build script.
----------------

#!/bin/sh

gcc -v
uname -a

# this info can't get to the <configure & make processes>
# and is just for human consumption - scrolls past quickly ?

mkdir build
cd build

tar zxvf ../speech_tools-2.1-release.tar.gz
tar zxvf ../festival-2.1-release.tar.gz
tar zxvf ../festlex_CMU.tar.gz
tar zxvf ../festlex_POSLEX.tar.gz
tar zxvf ../festlex_OALD.tar.gz
tar zxvf ../festvox_kallpc16k.tar.gz
tar zxvf ../festvox_rablpc16k.tar.gz
tar zxvf ../festvox_cmu_us_slt_arctic_hts.tar.gz
tar zxvf ../festvox_cmu_us_awb_cg.tar.gz
tar zxvf ../festvox_cmu_us_rms_cg.tar.gz

export DESTDIR=`pwd`/speech_tools

# what accesses 'DESTDIR'? There's no ref in -/speech_tools <--- *!

cd speech_tools
./configure
make -j 2
cd ..

cd festival
./configure
#make -j 2 #get compile errors with this on slack13.37 x86_64
make

cd ../speech_tools
make tes

cd ../festival
make tes

cd ../..

echo '(SayText "Hello Slackware User")' \
| ./build/festival/bin/festival --pipe

------------- end of BuildScript --------
Perhaps because I strongly believe in the incremental, rather
than shotgun approach, I've only got these 4, to start with:-

festlex_CMU.tar.gz 1925748
festival-2.1-release.tar.gz 787313
festvox_cmu_us_slt_arctic_hts.tar.gz 1073401
speech_tools-2.1-release.tar.gz 1681999

Simplistically this could be a reason why I'm failing.
But this project is very modular; so parts that handle eg.
the scheme-code can't need to reference parts that
handle the sound-file-building for installing.

OTOH probably I decided to get the first 4 *.tar.gz
based on the docos. Also:
even their <HelloWorld C++ compiler confirmer>
was incompatible -- as Henrik Carlqvist showed.

This goes beyond science, into voodoo/politics.

My explanation/excuse why SEVERAL people have managed to
install a version of festival is that they all, made the latest linux
installation and at the SAME time fetched the 'matching'
[ie. manual hacked] festival tar-balls.

The following:
pwd = /home/Hardware/Audio/Festival/speech_tools/config/systems
ls *Red* = RedHatLinux.mak
alpha_RedHatLinux.mak
ix86_RedHatLinux4.0.mak
ix86_RedHatLinux4.1.mak
ix86_RedHatLinux4.2.mak
ix86_RedHatLinux5.0.mak
ix86_RedHatLinux5.1.mak
ix86_RedHatLinux5.2.mak
ix86_RedHatLinux6.0.mak
ix86_RedHatLinux6.1.mak
ix86_RedHatLinux6.2.mak
ix86_RedHatLinux7.0.mak
unknown_RedHatLinux.mak
plus the docos, makes me think it's manually hacked to
fit specific versions of linux.

Which I confirmed: although my old RH6.2 hasn't go `gcc`, my
Mandrake9?10 has, and the `./configure` completed without
error. Which Slakware13 doesn't.

IIRC Mandrake9?10 gives an error/s at the `make` stage.
I've got everything well documented/logged, but I'm getting
a bit punch drunk. I've read that C++ is crap, but this is just
too much.

[Martin]

On 12/07/2012 09:24 PM, Henrik Carlqvist wrote:

> To write a slackbuild script:
> 1) <insert your favorite editor here> foo.SlackBuild
> 2) edit the line with the version of the program
> 3) save the file
> 4) run the script

I have not come across a software project yet where it was that simple.

> Once you have
> figured out how to install the software manually you can automate this in
> a script

You are right, but there is still a big difference between something
that just needs to run in your local installation (where corners can be
cut and you just dump the upstream version into /usr/local) and creating
a package that needs to work for a large number of people and that
therefore needs to comply with Slackware standards (eg. move doc, info,
man files, shared resources, handle .new files, symlinks, plus all the
slack-desc and doinst.sh paraphernalia). If you want SBo to consider
your SlackBuild the bar is even higher.

> I would guess that most people do
> some try and error by the prompt to later implement the script rather
> than doing try and error edits of the script.

I'd say it is much better developing the script from the start because a
script is software, and a proven approach for software quality is test
driven development. Also, the script can be stopped in various places
(by adding an exit command) and you can verify the situation without any
file being installed on your system. Even after installing the package
you can simply uninstall it to get a clean system.

[Avoi...@gmail.com]

In article <k9qfoi$n30$1...@speranza.aioe.org>, geep <ge...@nowhere.org> wrote:

I was wrong in assume that since the old-Mandrake
derived <config.log> was smaller than for Slakware13,
and that I didn't notice an error message scrolling past,
that the old-Mandrake has succeeded in the ./configure stage.

For the other point of whether I need to build the other
9 *.tar.gz in order to build <speechtools> I still maintain
the the dependency relationships are a tree, and not a
cyclical-graph. Besides some other docos says <you need
to build ca. 3 tar-balls>.

This project has forked into 12 leaves and is killing me!

That every different distribution & version of Linux
needs to be manually hacked to handle the C++ code;
is intolerable.

[Henrik Carlqvist]

On Fri, 07 Dec 2012 21:26:29 +0000, Sylvain Robitaille wrote:
> It can be simpler than that:
>
> 1) env VERSION=1.0 ./foo.SlackBuild
> 2) installpkg /tmp/foo-1.0-i686-1.tgz

With a slightly modified template it could be even more simple,
something like:

...
SCRIPTNAME=`basename $0`
PRGNAM=${PRGNAM:-"`echo $SCRIPTNAME |sed 's/\.SlackBuild.*$//'`"}
VERSION=${VERSION:-`ls ${PRGNAM}-*.tar.* | tail -1 | \
awk -F - '{print $2}' | awk -F .tar '{print $1}'`}
...
SOURCE=`ls $CWD/${PRGNAM}-${VERSION}.tar.* | tail -1`
...

The above (untested) code is supposed to find the version number from any
downloaded source archives. If more than one version of the source is
downloaded "tail -1" tries to select the latest version.

The SOURCE line is also supposed to accept source archives like
foo-1.0.tar.bz2.

[Avoi...@gmail.com]

In article <k9qfoi$n30$1...@speranza.aioe.org>, geep <ge...@nowhere.org> wrote:

>FWIW below is my recipe used on Slack 13.37 x86_64 when I played with it

>last year. It builds festival locally. ...........

This project is morphing absurdly.
All I wanted originally was a utility like Win7 does:
to lie down and have text read to me.

Interestingly, I've discovered that software is like fashion:
for short-attention-span and not for hoarding like gold or algorithms.

Apparently the user is expected to use the current utility to match the
current OS. Or as the illiterate peasant woman knows 'she gets the NOW
shoes for her child to wear NOW'. Both shoes and child-feet-shapes are
moving targets.

Eventually I found a server that has old-Ver13.0 files, and the 3 packages'
dependencies checked OK - of course.

Do C/C++ binaries reference the *.h sources during loading, or why are they
included? I don't do Windows or C and especially not C++.
---------------
The following is original, hence possibly interesting or absurd:-
since `mc` allows browsing and even copying-out of the <compressed package
files>, it's possible to visually extract-copy the key/necessary files.
Also you can read the docos IN the archive.

So I wanted to experiment to see the structure of this interesting package
which uses scheme at one level; and install a minimum file-set.

So I built an empty dir-tree/skeleton and copied the TOP executable.
The idea, is to hopefully be able to construct the tree, while getting an
idea of the structure, by noting the error message for the missing files,
which are progressively added.

Immediately I found IMO a big problem: not only the initial script, but also
the first binary expects absolute file-addresses. All substantial 'outside'
packages that I've ever installed, have been isolated to their own
dir-tree. Some even run from other disks, from previous distributions.

I don't doubt that the mess-of <config/make> scripts that was incompatible
to build from source, for my old V13.0, can be set to eg. install to
/usr/local/festival - plus the libs. But must I assume that THIS set of
executables are 'FIXED' or is that connected to the *.h mystery?

I refuse to allow festival to potentially damage my 'OS executables'.
So if I install it to another partition, together with an extra
Slackware13, can I `chroot` festival:TTS there, or since it needs
to drive sound-hardware, and the proc & dev dirs will be missing?

But is there a way of <?mount bind?> to use the booted partition's
dev & proc dirs ?

== TIA.
ipNews.Send *

[geep]

On Fri, 07 Dec 2012 22:47:54 +0000, no.top.post wrote:
> If I live long enough [I started on festival 6 months ago] I might try
> espeak; but I've opened this canOworms, so I must eat it.
>
> This has become more than about festival. It's now about my method -
> false logic. Please see queries IN your build script. ----------------
> #!/bin/sh
>
> gcc -v
> uname -a
> # this info can't get to the <configure & make processes> # and is just
> for human consumption - scrolls past quickly ?

Yes. They aren't useful. Dunno why they're there!

>
> export DESTDIR=`pwd`/speech_tools
> # what accesses 'DESTDIR'? There's no ref in -/speech_tools <--- *!

You're right. I don't know why it's there. I probably took an existing
Slackbuild script from somewhere and ripped out bits until I got
something that ran OK.
I just know that my script works on my Slack 13.38 x86_64 :)

>
> echo '(SayText "Hello Slackware User")' \
> | ./build/festival/bin/festival --pipe
> ------------- end of BuildScript -------- Perhaps because I strongly
> believe in the incremental, rather than shotgun approach, I've only got
> these 4, to start with:-
>
> festlex_CMU.tar.gz 1925748
> festival-2.1-release.tar.gz 787313
> festvox_cmu_us_slt_arctic_hts.tar.gz 1073401
> speech_tools-2.1-release.tar.gz 1681999
>
> Simplistically this could be a reason why I'm failing. But this project
> is very modular; so parts that handle eg. the scheme-code can't need to
> reference parts that handle the sound-file-building for installing.
>

My notes on why I used the 10 files and where I got them from are sparse.
It was in August 2011 and I can't remember.
Sorry I can't be more helpful.

Cheers,
Peter

[geep]

On Tue, 11 Dec 2012 17:36:14 +0000, geep wrote:

>> echo '(SayText "Hello Slackware User")' \
>> | ./build/festival/bin/festival --pipe
>> ------------- end of BuildScript -------- Perhaps because I strongly
>> believe in the incremental, rather than shotgun approach, I've only got
>> these 4, to start with:-
>>
>> festlex_CMU.tar.gz 1925748
>> festival-2.1-release.tar.gz 787313
>> festvox_cmu_us_slt_arctic_hts.tar.gz 1073401
>> speech_tools-2.1-release.tar.gz 1681999
>>
>> Simplistically this could be a reason why I'm failing. But this project
>> is very modular; so parts that handle eg. the scheme-code can't need to
>> reference parts that handle the sound-file-building for installing.
>>
> My notes on why I used the 10 files and where I got them from are
> sparse. It was in August 2011 and I can't remember. Sorry I can't be
> more helpful.
>
> Cheers,
> Peter

Here are the md5 sums of the tarballs.
Googling the md5 sum you can find lots of places to download the same
files that I used.
md5sum *gz
c93eb3e389ed171ab9abd46afe8897a8 festival-2.1-release.tar.gz
6a2ee4fed7c3ebedf197a3b8524ccb87 festlex_CMU.tar.gz
84af32a914d996f57bc4cb36fe8cdc97 festlex_OALD.tar.gz
aa80f9250065b318325f16fdad3a4484 festlex_POSLEX.tar.gz
2c14269587ad018ee93176bb44f4c38b festvox_cmu_us_awb_cg.tar.gz
a9514a9df32401774c074abec42ffb22 festvox_cmu_us_rms_cg.tar.gz
a9b53441968f6bc612b85c04bbc4cf0f festvox_cmu_us_slt_arctic_hts.tar.gz
3869af78f473b616601cac3fa83cc14e festvox_kallpc16k.tar.gz
34cb2478f5b8fa1ed02f5cbb496c1dcd festvox_rablpc16k.tar.gz
6920ddc75b042910a3bcfee3ab106938 speech_tools-2.1-release.tar.gz

Cheers,
Peter

[Unknown]

Thanks, but as you previously wrote:---
]FWIW below is my recipe used on Slack 13.37 x86_64 when I played with it
]last year. It builds festival locally. ...........

But I'm running ver 13, and I believe that festival is so fragile
[as is C++] that they need to 'match'.

> Cheers,
> Peter