Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#2171 closed defect (fixed)

FTBFS in sugar-jhbuild

Reported by: sascha_silbe Owned by: walter
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Turtleart Version: Git as of bugdate
Severity: Blocker Keywords:
Cc: Distribution/OS:
Bug Status: New

Description

The "turtleart" module in sugar-jhbuild fails to build from source:

*** Installing turtleart *** [19/26]
python setup.py install --prefix /home/sascha.silbe/sugar-jhbuild/install
running install
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.6
creating build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/tamyblock.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/taexportlogo.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/talogo.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/tawindow.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/tagplay.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/tacanvas.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/__init__.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/tautils.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/tablock.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/tajail.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/taconstants.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/taexporthtml.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/taturtle.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/tasprite_factory.py -> build/lib.linux-x86_64-2.6/TurtleArt
copying TurtleArt/sprites.py -> build/lib.linux-x86_64-2.6/TurtleArt
running build_scripts
creating build/scripts-2.6
error: file '/home/sascha.silbe/sugar-jhbuild/source/turtleart/turtleart' does not exist
*** Error during phase install of turtleart: ########## Error running python setup.py install --prefix /home/sascha.silbe/sugar-jhbuild/install *** [19/26]

The module configuration is as follows:

  <bundle id="turtleart">
    <branch module="turtleart/mainline.git" checkoutdir="turtleart"/>
  </bundle>

What should we build in sugar-jhbuild? Turtle Art, Turtle Blocks or both? What are the corresponding repositories? What else (if anything) needs to be done to make it work?
What about Trac components? Separate ones or a single "Turtle Art / Turtle Blocks"?

Change History (6)

comment:1 follow-up: Changed 10 years ago by walter

Not sure where the reference to the missing file turtleart is coming from. It is not used by Sugar. I'll have to chase it down.

I believe that this is wholly unrelated to the confusion of names.

Regarding the name, I suppose it depends upon what you refer to as the name. Turtle Blocks is the "name" of the activity in Sugar for what used to be named Turtle Art. Its activity.info is unchanged:

[Activity]
name = Turtle Art
activity_version = 94
license = MIT
bundle_id = org.laptop.TurtleArtActivity
exec = sugar-activity TurtleArtActivity.TurtleArtActivity

The name Turtle Blocks only appears in the en.po file:

#: activity/activity.info:2
msgid "Turtle Art"
msgstr "Turtle Blocks"

Turtle Art is the name of a new activity:

[Activity]
name = Turtle Art Mini
activity_version = 89
license = MIT
bundle_id = org.laptop.TurtleArtMiniActivity
exec = sugar-activity TurtleArtMiniActivity.TurtleArtMiniActivity

TurtleArtMini. The name Turtle Art only appears in the en.po file:

#: activity/activity.info:2
msgid "Turtle Art Mini"
msgstr "Turtle Art"

Turtle Blocks is the activity we should be including in Fructose. It is the activity associated with the TurtleArt component in Trac. I suppose it makes sense to include a TurtleArtMini component as well. I'll file a separate request.

The reason for creating two activities is that the maintainer of the Java version of TurtleArt (the original version) requested that the I make a version of Turtle Art that more close tracks his version. He argued that having two programs, both named Turtle Art, with very different capabilities was confusing. So I made the mini version and made the name change in the .po file.

I didn't change the name everywhere because (a) changing the bundle_id in Sugar would have broken too many things; and (b) I waned the users of the Python version to continue t get the same version when they updated.

comment:2 Changed 10 years ago by walter

Regarding the problem with Make, I did introduce a change to setup.py that was an attempt to resolve a discrepancy with the installation of turtle art into the GNOME desktop on Ubuntu. (The packager had overwritten the existing setup.py file, so I tried to make one that worked in both situations. That may be a clue.

comment:3 Changed 10 years ago by walter

  • Resolution set to fixed
  • Status changed from new to closed

comment:4 in reply to: ↑ 1 Changed 10 years ago by sascha_silbe

Replying to walter:

Regarding the name, I suppose it depends upon what you refer to as the name. Turtle Blocks is the "name" of the activity in Sugar for what used to be named Turtle Art. Its activity.info is unchanged:

[Activity]
name = Turtle Art
activity_version = 94
license = MIT
bundle_id = org.laptop.TurtleArtActivity
exec = sugar-activity TurtleArtActivity.TurtleArtActivity

The name Turtle Blocks only appears in the en.po file:

#: activity/activity.info:2
msgid "Turtle Art"
msgstr "Turtle Blocks"

That's rather confusing.

Turtle Art is the name of a new activity:

[Activity]
name = Turtle Art Mini
activity_version = 89
license = MIT
bundle_id = org.laptop.TurtleArtMiniActivity
exec = sugar-activity TurtleArtMiniActivity.TurtleArtMiniActivity

TurtleArtMini. The name Turtle Art only appears in the en.po file:

#: activity/activity.info:2
msgid "Turtle Art Mini"
msgstr "Turtle Art"

Making it even more confusing.

I didn't change the name everywhere because (a) changing the bundle_id in Sugar would have broken too many things; and (b) I waned the users of the Python version to continue t get the same version when they updated.

Unless I missed something, keeping the bundle_id but changing everything else (human-readable names, repository locations etc.) should achieve what you want.

comment:5 follow-up: Changed 10 years ago by walter

Unless I missed something, keeping the bundle_id but changing everything else (human-readable
names, repository locations etc.) should achieve what you want.

I must not have explained myself clearly. This is exactly what I did. Bundle IDs are unchanged. Just the human-readable strings are changed.

comment:6 in reply to: ↑ 5 Changed 10 years ago by sascha_silbe

Replying to walter:

I must not have explained myself clearly. This is exactly what I did. Bundle IDs are unchanged. Just the human-readable strings are changed.

But not all strings that are seen and used directly by the users have been updated.
As I just saw, even Debian now seems to package Turtle Blocks as sugar-turtleart-activity. This is bound to confuse users.

Note: See TracTickets for help on using tickets.