[Sugar-devel] Error doing ./osbuild build

[Gonzalo Odiard]

On Tue, May 28, 2013 at 8:16 AM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> 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...
>

Grr..., now is working, then, probably temporary. Like you say, no clue
about the reason in the message.

>
>
>> 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 :)
>
>

May be you can use: https://pypi.python.org/pypi/websocket-client/0.7.0
I have tested it and works ok.


> 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.
>

It's true only you and manuq are working in the core, but there are
different roles in the community,
and always are more people working on activities than in sugar itself.
I think we thought the web stuff will be a thin layer and not add a monster
like webkit
to the stuff we need compile.

Don't take this as a attack. I value the work you do. But you need
understand sugar-build now is a
central piece in our stack, and we need use it in different ways.

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