[Sugar-devel] Error doing ./osbuild build

Daniel Narvaez dwnarvaez at gmail.com
Tue May 28 07:16:04 EDT 2013


On Tuesday, 28 May 2013, Gonzalo Odiard wrote:

> After doing a new clone, in F18 I get the following error:
>
> * Building gwebsockets
>     dist = best[req.key] = env.best_match(req, self, installer)
>   File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 825, in
> best_match
>     return self.obtain(req, installer) # try and download/install
>   File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 837, in
> obtain
>     return installer(requirement)
>   File "/usr/lib/python2.7/site-packages/setuptools/dist.py", line 294, in
> fetch_build_egg
>     return cmd.easy_install(req)
>   File
> "/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", line
> 592, in easy_install
>     raise DistutilsError(msg)
> distutils.errors.DistutilsError: Could not find suitable distribution for
> Requirement.parse('zope.interface>=3.6.0')
>


Setuptools is doing an horrible job at reporting the error there, but I
suspect this is a transient issue, does it work if you retry now? At least
I've seen similar traces before that was just temporary network errors...


> Zope? really? :)
>

I think this is dragged in by autobahn, which is a websocket client we are
using for gwebsockets tests. If you want to write a gwebsockets client to
avoid the dependency feel free, I take patches :)


> The last time I tried, sugar-build installed ruby.
>

It is required to build webkitgtk, not much we can do about that other than
sending them patches to avoid the dep if possible at all.


> I think we should be more careful about our dependencies, in fact, in the
> past, adding dependencies was publicly discussed
>

It doesn't make much sense to discuss any single sub dependency dragged in
by stuff we obviously need like webkit.

The autobahn dependency in gwebsockets could have be discussed perhaps. As
I said the alternative would be to write a gwebsockets client, but in my
opinion it's not worth the effort just to avoid this build time dependency.
Especially since we are not going to need a client outside the tests.

I have the following proposals:
> * Review the dependencies. Have more and more dependencies is a recipe to
> a nightmare.
>

If we add new stuff, like a new toolkit based on a completely different
software stack, and never remove old stuff, like gtk2 support, we are
doomed to increase our dependencies. I don't think there is a way around
that.

Of course I agree that we should be careful. But sometimes it's better to
depend on something than to write your own code which you then need to
maintain. I think that's the case for the autobahn dependency in
gwebsockets for example.


> * Split the compilation, one part to compile sugar and another to compile
> sugar-web,
> sugar-web is more unstable, and have a lot of issues.
>

This would add more maintenance, buildbot etc work that I personally don't
have time to do. I welcome anyone to jump in and maintain a
sugar-without-html build if it is considered necessary.

IMO we decided that HTML activities was the main goal for the release and
it would good if it was more of a collective effort, including testing and
fixing the build. Right now is mostly just me and Manuel... Most other
people seems to be annoyed by the build issues rather than trying to
participate. If we wanted to have only a small part of the team work on it
and the rest not being bothered by the changes, it would have been better
to work on a branch until stuff was more stable.

* The buildbot should compile all, doing a clean clone.
>

Sure, it does one clean build per day.



> * If possible, the changes should be tested before are commited to git.
>

They are generally tested but it's often difficult to anticipate all the
possible issues. The network issue Lionel was having triggered issues that
I had not anticipated for example.
In your case, the change landed several days ago, so it has definitely been
tested by multiple people and by the bots. When we figure out what the
issue is exactly we can probably understand why it was not catched.


-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130528/7b6cb684/attachment.html>


More information about the Sugar-devel mailing list