Bug 490267

Doh. Of course this then leads on to that the following header files aren't installed either:

generic/{jkSound.h,jkAudIO.h,snack.h,snackDecls.h}

Oh, and this relates to https://bugzilla.redhat.com/show_bug.cgi?id=489430 because the relevant Festival bits and bobs need the aforementioned to compile the EMU system, which relies on tcl-snack, by the looks of it.

I'd assume there are other applications that require this, but you never know.

Is there a dependent software component I could test against?

I'm not at the same workstation as I was when I opened this, so I'm uncertain, but OTOH if you get the TCL ASSP SRC RPM from the noted bug:

https://bugzilla.redhat.com/show_bug.cgi?id=489430

Then it should show up the issue.

Try to rebuild it without having grabbed snackConfig.sh from the .src.rpm then it won't go far...

K.

Seems to be looking for tclConfig.sh, not snackConfig.sh. You sure about that one?

(also, passing --with-tcl=%{libdir} should get it past that)

Ah, found it...

http://emu.sourceforge.net/

Emu 2.x download tarball.

[me@mybox snackssff]$ ./configure --help | grep -i snack
  --with-snack=DIR        use Snack files from DIR
[me@mybox snackssff]$ grep snackConfig.sh ./configure
configure:file=$SNACK_OBJ_DIR/snackConfig.sh
[me@mybox snackssff]$ 

I would hazard that it is part of TEA (TCL Extension Architecture) that requires the [something]Config.sh file to be present, and that this is true of all similar packages?

That picture of the emu cracks me up!

I wasted far too much time packaging up the pre-requisites so I could test emu properly, but I understand how to fixup tcl-snack now.

BTW, I redid some of your packages from 489430... they needed some love.

http://www.auroralinux.org/people/spot/review/new/libassp-0.1-2.fc11.src.rpm
http://www.auroralinux.org/people/spot/review/new/tcl-assp-0.1-2.fc11.src.rpm

I'm 75% done with an emu package. Were you considering maintaining these in Fedora?

Yes, it is quite amusing.

Those assp packages were just for the purposes of getting Emu and hence the festival stuff I wanted done, and included on the bug/ticket in case they helped someone else in the future. It didn't matter so much if they were "messy". Glad you're on track with the snack-devel or whatever stuff.

I don't mind maintaining those packages for as long as I am doing the festival project that I am working on, which may translate to a 4 year PhD course, or may be done on a more casual basis.

I have been working on an Emu package myself. I wasn't suggesting that you should build one, but given that mine tend to get the job done rather than possess all that much finesse, perhaps it's best if you complete yours instead? I'd be fine with testing it, whichever one that is.

That said, I'll wait for your response on this before doing any more on mine, as an Emu package is a lot of work, and there's no point in doing it twice. If you want me to post my work so far then that's fine too.

Apropos, I have found that using 'make -n' can make producing spec files a hell of a lot more easy.

tcl-snack-2.2.10-10.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/tcl-snack-2.2.10-10.fc9

tcl-snack-2.2.10-10.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/tcl-snack-2.2.10-10.fc10

If you do opt to build your own package, could you add a symlink in it from 'labeller2' to 'emulabel'? 

I believe that simple thing will save a lot of people hassle using the Emu system, because eg. from here: http://festvox.org/bsv/x1003.html

That is what it used to be called, and people are hunting for it by the old name.

Either that, or put something in a README.RPM file about it.

Alternatively if you want me to continue to build my Emu RPM I've already done that.

My emu package is 95% done. My only remaining concerns are about how a lot of the emu tcl scripts seem to want to use "tkemu" or "emush", neither of which I can find in the source.

There isn't a "labeller2" binary... there is /usr/lib64/tcl8.5/labeller2/app/labeller.tcl. I'm not sure if making a symlink to that for emulabel will help the people trying to use it as described in that festvox page.

Here's the latest emu SRPM and SPEC I have... perhaps you'll have a better idea how to accomplish your suggestion:

http://www.auroralinux.org/people/spot/review/new/emu-2.0-1.fc11.src.rpm
http://www.auroralinux.org/people/spot/review/new/emu.spec

"binary" was stretching the definition a lot, I'll grant you.

In my .spec file I have references to this call from the makefile's voodoo:

        /usr/bin/tclsh8.5 fixandcp.tcl ./${a} ;

Where $a is:

autoDBinstaller/app/autoDBinstall.tcl  snacktrack/app/formant.tcl
confgui/app/confgui.tcl                snacktrack/app/snacktrack-tool.tcl
emuconfgui/app/emuconfgui.tcl          tkassp/app/tkassp.tcl
labeller2/app/labeller.tcl             tkwizard/app/snitwiztest.tcl

Hence including labeller2 to create a command line program (although not 'binary', really, just a shell script wrapper for the TCL code), and although I'm not 100% certain, I believe 'labeller2' equates to 'emulabel' from earlier versions.

I'll investigate in more detail later.

labeller2/app/labeller.tcl needs to be invoked with wish to work. I suspect it might get called from inside the dbemu environment (dbemu being the only obvious binary in the set).

I haven't worked out what dbemu is for yet ;-)

But I do know what 'fixandcp.tcl' adds this header to the scripts to make them into shell scripts:

--- BEGIN

#!/bin/sh
# The next line is executed by /bin/sh, but not tcl
exec $command  \$0 \${1+"$@"}

--- END

Where $command is set to one of /usr/bin/wish8.5 or /usr/bin/tclsh8.5

Which I think lands us back on the same wavelength...

Yes... but fixandcp.tcl is only run on: dbemu/app/dbemu, because that is the only item in apps= in applications/Makefile...

tcl-snack-2.2.10-10.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

tcl-snack-2.2.10-10.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Perhaps a new ticket for this Emu package would be good at this time?

I've looked at it, and it certainly seems you were right :-)

I'm trying it now, and neither your package, or the binary installer version from http://emu.sourceforge.net/ actually work when following the instructions:

[myuser@mybox bin]$ EMU_TEMPLATE_PATH=/my/home/path/data/time/etc/ dbemu
/home/kyrian
Emu: ./generic/emu_vec.h:265: T& emu_vector<T>::operator[](int) [with T = emu_string]: Assertion `i>=0 && i<length()' failed.
Aborted
[myuser@mybox bin]$ 

I suspect I know why (multiple template files, some of a different format) and will experiment some more...