TurtleArt doesn't start on amd64 due to 32bit alsaaudio.so in bundle

[sascha_silbe]

TurtleArt doesn't start on Ubuntu/amd64 (and probably any other non-i386 system):

Traceback (most recent call last):
  File "/home/sugar/sugar-jhbuild/install/bin/sugar-activity", line 21, in <module>
    main.main()
  File "/home/sugar/sugar-jhbuild/install/lib/python2.5/site-packages/sugar/activity/main.py", line 105, in main
    module = __import__(module_name)        
  File "/home/sugar/sugar-jhbuild/install/share/sugar/activities/TurtleArt.activity/TurtleArtActivity.py", line 21, in <module>
    import tawindow
  File "/home/sugar/sugar-jhbuild/install/share/sugar/activities/TurtleArt.activity/tawindow.py", line 38, in <module>
    from talogo import *
  File "/home/sugar/sugar-jhbuild/install/share/sugar/activities/TurtleArt.activity/talogo.py", line 30, in <module>
    from audiograb import AudioGrab
  File "/home/sugar/sugar-jhbuild/install/share/sugar/activities/TurtleArt.activity/audiograb.py", line 29, in <module>
    import alsaaudio
ImportError: /home/sugar/sugar-jhbuild/install/share/sugar/activities/TurtleArt.activity/alsaaudio.so: wrong ELF class: ELFCLASS32

[walter]

ouch. any recommendations on how to handle this? (this is part of the more general discussion about bundling)

[erikos]

What is the AudioGrab exact functionality? Can this be upstreamed - is this functionality already somewhere upstream?

[sascha_silbe]

Concerning the concrete issue at hand:
I'm a bit puzzled as to how sugar-jhbuild could accidently build a 32-bit binary on a 64-bit system. It usually requires explicit usage of compiler flags to achieve that.

Regarding the general problem of dependencies and architecture-dependent files:
I've slept over this and put up a general design outline on PackagingIdeas. It probably won't be too popular as it requires quite some effort, especially for the distro-dependent parts. But I couldn't think of anything simpler that really gets the _whole_ job done.
Comments and criticism welcome (especially if it's constructive ;) ).

[walter]

I haven't been following the packaging discussion all that closely--I will now that I have been bit :)

I am guessing that having several prebuilt packages around has got to be part of our future, unfortunately. Also to consider would be a separate extras bundle of common dependencies that many activities might require but are not always available preinstalled. Activity authors can lobby for inclusion of their favorite dependencies.

As far as the specifics of Turtle Art, in order to grab audio data (general case) and DC voltages (OLPC-specific case) we need to make sure that alsa is configured properly. Alsa libraries were (at least at the time this work was originally done) not part of the routine OLPC build, hence the binary was included. Love to figure out a way to not include it.

[wadeb]

I wonder if there is some Python magic to *try* to include a module, and disable activity functionality if it fails?

Also, a lot of my activities use custom C++ extension modules for performance - I ship the source code in the .xo bundle along with a build script, but it's asking a lot of Sugar to compile them for me when the .xo is downloaded :)

[walter]

I am actually already doing a little of that in TA for other reasons entirely--letting end users define extensions. But I am bumping into so Rainbow problems that I need Michael's help in chasing down.

[sascha_silbe]

walter:

Also to consider would be a separate extras bundle of common dependencies that many activities might require but are not always available preinstalled.

Interesting idea. I've added it to my proposal. I suggest continuing the discussion on sugar-devel, though.

walter:

As far as the specifics of Turtle Art, in order to grab audio data (general case) and DC voltages (OLPC-specific case) we need to make sure that alsa is configured properly

I'm afraid I don't know how the audio stuff is supposed to work in Sugar - especially since everything audio-related in Pippy doesn't work at all. Do you have a pointer to some documentation?
What do you mean by "[making] sure that alsa is configured properly"?
Do other Activities use the same module? If not, in what way is TurtleArt special?

wadeb:

I wonder if there is some Python magic to *try* to include a module, and disable activity functionality if it fails?

You already highlighted the magic word. ;)

try :
  import alsaaudio
except ImportError :
  alsaaudio=None

walter:

I am actually already doing a little of that in TA for other reasons entirely--letting end users define extensions. But I am bumping into so Rainbow problems that I need Michael's help in chasing down.

Sorry, lost context. "a little of [what]"?

[walter]

The history of the alsa dependencies in Turtle Art with Sensors has to do with having to set special flags within alsa to accommodate the DC input mode for the microphone. This is why we included an alsa binary. (The only other package that used that mode, to my knowledge, is Measure.)

When I went to fold Turtle Art with Sensors into the mainstream Turtle Art, I inherited this dependency.

Pippy, as I recall, uses the csound libraries for its sound. We had been heading down a path of using a csound service for all audio within Sugar, but I don't think we ever achieved that goal. I think that Victor is working on cleaning up the csound libraries, which will help a great deal.

Regarding this particular ticket, I made the decision that for 0.84, I would revert the changes I introduced regarding sensor input to Turtle Art. (It is still available in the experimental version of Turtle Art (TAPortfolio). Once we have consensus on a strategy, presumably for 0.86, I will revisit this decision.

In regard to importing modules, what I was doing was to allow a Turtle Art module to be loaded from the Journal on the fly. I used a "dummy" module that would be overwritten on the fly. But there is some issue with Rainbow that causes the journal copy of the module not to load (even though the sys path is correctly set). [I had copied it to the /data directory. Works great with Rainbow disabled.

In any case, I will mark this as 0.86 and revert for 0.84. I'll be posting a new set of sources for Turtle Art as soon as I have done a bit more testing.

[walter]

The new Turtle Art (v34) has no sensor input, so this bug can be closed, but I will file a new ticket regarding adding sensors back in to Turtle Art. (Perhaps by making the alsa binary be part of the standard XO build, I can circumvent the problem.)

[walter]

I'll resolve this as fixed and open the new ticket...