No matter what I always get the following:

Traceback (most recent call last):
  File "/opt/tuxdroid/apps/tux_framework/TFW.py", line 12, in ?
    from FWObject import GdgFramework
  File "/opt/tuxdroid/apps/tux_framework/libs/FWObject.py", line 34, in ?
    from GdgObject import *
  File "/opt/tuxdroid/apps/tux_framework/libs/GdgObject.py", line 50, in ?
    from GdgVoiceRec import VoiceRecParametrize, VoiceRecAcquire, VoiceRecMatching
  File "/opt/tuxdroid/apps/tux_framework/libs/GdgVoiceRec.py", line 11, in ?
    import DTW
  File "/opt/tuxdroid/apps/tux_framework/libs/DTW.py", line 27, in ?
    lib = CDLL(DTW_SO)
  File "/usr/lib/python2.4/site-packages/ctypes/__init__.py", line 315, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: /opt/tuxdroid/apps/tux_framework/libs/_DTW.so: undefined symbol: __stack_chk_fail

I have pyxml installed, tuxgi works great, I installed debian i386 Etch just to see if it was an ubuntu problem, same problem.

Anyone have a solution for me?  This thing looks really awesome and I am really excited to start using it but havent had any luck.

fixed my issue, after searching around i found out that an upgrade to Debian Lenny from Etch would solve my issue.

To everyone experiencing my issues, heres a tip, dont use 64-bit, you will hit a wall, also be sure to run Debian testing Lenny, not stable etch.

Don't use 64 bit?  Um, in case you haven't noticed, there aren't many 32 bit CPUs for sale now days.  Everything is going 64 bit.  Everything I use is 64 bit.  Not everyone has a five year old pc.  Most people I know actually like to use fairly recent releases of the Linux kernel in its 64 bit form, in whatever distribution fancies their tastes.

I don't see the logic of making software that only works on a small number of Linux distributions and only in their out-dated 32 bit form.

The claim of "easy to use" is not entirely true, in fact far from it.  If the so-called "easy to use API's" don't even work on your PC, and require special modification, self torture, voodoo rituals, and obscure library tweaking to just get working on what would be considered a "typical" installation, doesn't exactly meet the "easy to use" claim at all.

Instead of having a piece of crap Python API that doesn't even work on many installations, why not just publish the core command structure so someone can make an API in a more stable and easier to use language like C, Perl or PHP and not just Python?  It's obvious their method of a Python library is quite broken.  Either make it more compatible or switch to something that isn't so picky about its environment and just works?  This Python/Debian evangelism is getting really old.

Here they have this great piece of hardware, that appears to be able to do as desired, but their interface software totally sucks.

Also, before I finish my tirade (and I acknowledge it as such), don't give me the "then why don't you write something better yourself?" response.  If this had been an open hardware project where I built the robot with parts I purchased and put together myself etc., then I'd say you'd have a point.  However, I paid good money for this "easy to use" sucker and so far it has been far from easy!  As a paying customer I have a perfect right to complain about something that is obviously not stayed in touch with current technology.

My suggestion?  Make the software work on all Linux environments before thinking of adding new features.  Linux releases are free (along with virtualization), and there is no excuse for not testing the software on the popular releases before saying something is "final" release.

Where's the Tylenol?...

Well, im not saying my solution is a perfectly satisfactory one, I *WAS* using a 64-bit, but I wanted to tinker with my tux droid.  I am also a little dissapointed at the lack of compatibility

as far as the other languages,  it wouldnt hurt to have it work against other languages, I dont particularly see whats wrong with python really.  What I'd like is an apt and yum  repository that has everything tuxdroid needs to *just work* on various distributions and architectures.

Also,  and here comes my rant, dont take it personally..

If you believe you can do so much better why not contribute to the project or write something of your own? 

You have complaints and thats all fair and well, but try to contribute before just complaining, especially if your at a high enough level to gripe about python vs some other language, it must mean you are in a position where you are proficient in multiple languages to the extent of comparing them.

tuxdroid, although very commercial, is very open sourced natured, in open source if you dont like something you just change it by either submitting patches or forking your own, perhaps even writing from the ground up.

Anyhow, thats my two cents,  primarily I just wanted to defend my post as not a way to make up for the shortcomings of the project, as I am not very happy about it either, just as a solution to those willing to try it.

Previously Richard Kelsch wrote:

Don't use 64 bit?  Um, in case you haven't noticed, there aren't many 32 bit CPUs for sale now days.  Everything is going 64 bit.  Everything I use is 64 bit.  Not everyone has a five year old pc.  Most people I know actually like to use fairly recent releases of the Linux kernel in its 64 bit form, in whatever distribution fancies their tastes.

I don't see the logic of making software that only works on a small number of Linux distributions and only in their out-dated 32 bit form.

Well, different parts of the world don't have the same standards it seems, as I've yet to find a 64 bit here at the company And that's the only reason the 64 bit binaries aren't out yet.

I don't see the logic of making software that only works on a small number of Linux distributions and only in their out-dated 32 bit form.

The claim of "easy to use" is not entirely true, in fact far from it.  If the so-called "easy to use API's" don't even work on your PC, and require special modification, self torture, voodoo rituals, and obscure library tweaking to just get working on what would be considered a "typical" installation, doesn't exactly meet the "easy to use" claim at all.

Now about supporting all different linux distributions, that's what I consider more a community work that something a small company can handle by itself as there are too many variations. They decided to go for Ubuntu as it seems it's the usual place people go when they don't want to get problems or tinker around. More advanced linux users shouldn't get much trouble tuning a couple of stuff to adapt the package to their distributions. And usualy some people stand up and package themselves for different architectures and distros. That's the point where it can get "easy to install". But right now it's only true on Ubuntu.

Instead of having a piece of crap Python API that doesn't even work on many installations, why not just publish the core command structure so someone can make an API in a more stable and easier to use language like C, Perl or PHP and not just Python?  It's obvious their method of a Python library is quite broken.  Either make it more compatible or switch to something that isn't so picky about its environment and just works?  This Python/Debian evangelism is getting really old.

Here they have this great piece of hardware, that appears to be able to do as desired, but their interface software totally sucks.

I've no problems with python though I barely know it. But I didn't like the fact that the API was too heavy and managed much things the daemon should have handled. The next move will be to replace the daemon by a library and have an xml-rpc daemon that uses the library. The good point of that is you'll be able to interface yourself at the level you want: xml-rpc for API type commands, from any language, or lower level using the library directly. Right now the 'core command structure' is available, the documentation pages are a bit tricky to find but are outdated anyway. The good place is SVN as the firmware and current daemon are up to date. So you could start from there but I advise to wait for the new library and the xml-rpc daemon to be published.

Also, before I finish my tirade (and I acknowledge it as such), don't give me the "then why don't you write something better yourself?" response.  If this had been an open hardware project where I built the robot with parts I purchased and put together myself etc., then I'd say you'd have a point.  However, I paid good money for this "easy to use" sucker and so far it has been far from easy!  As a paying customer I have a perfect right to complain about something that is obviously not stayed in touch with current technology.
My suggestion?  Make the software work on all Linux environments before thinking of adding new features.  Linux releases are free (along with virtualization), and there is no excuse for not testing the software on the popular releases before saying something is "final" release.
Where's the Tylenol?...

I can send you a special package where all parts are disassembled if you would prefer
From the hardware point of view, you get quite a lot of components for the price. If I had to buy some electronic components for a project close to this, buying a tux and disassmebling it would be much cheaper. Usually a pair of RF modules in this range is already quite the price of tux itself. But I'm not a marketing guy so I can't really argue about that.
For the software, considering the limited ressources, I personally prefer to see it going forward rather than spending time on packaging for every possibe distro. Now the solution I'd see for your problem would be to have a more community oriented spirit for releases. And that's where the problem lies. Some people already suggested some packaging scripts. The problem is that the software development of kysoh is not community oriented: you can't find the up-to-date sources on svn nor can you follow the development, releases are not tagged, and on top of that there's the Acapela license which forces the sound library to be closed source.
Now there's good work being done on the software, it's just not done the "open source" way, but I don't consider a community fork being a good solution as the main software developers are really contributing a lot and that would be plain stupid to do that work twice. It's just that I don't see how the community could participate in the current situation, though there are some people willing to contribute.
If someone has good ideas, they're welcome.

David