Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-28 Thread Tomeu Vizoso
On Tue, May 26, 2009 at 02:07, Bastien bastiengue...@googlemail.com wrote:
 Tomeu Vizoso to...@sugarlabs.org writes:

 On Sun, May 24, 2009 at 13:31, Bastien bastiengue...@googlemail.com wrote:
 +1 on the overall.

 Building Sugar from source should be as easy as:

 ,
 | ~$ git://git.sugarlabs.org/sugar-core/mainline.git
 | ~$ ./configure
 | ~$ make
 | ~$ sudo make install
 `

 Well, that works for the sugar shell provided you have all the
 dependencies installed. The point of jhbuild is precisely to get you
 an environment where all the dependencies of the software you are
 interested in are installed without breaking your regular desktop.

 Sorry to be dull here... IIUC, what you describe is the main difference
 between jhbuild and, say, apt-get install sugar on Ubuntu: in the later
 case, dependancies are taken care of by the .deb package whereas in the
 jhbuild case they are all integrated in the jhbuild source?  Does that
 make sense?

Agreed, jhbuild is necessary because we cannot expect all the
dependencies are installed in the distro. It would be great if we
could depend on stuff already in distros that are 1 year old, but we
are currently seeing how the rest of the Linux desktop world are
converging more towards our needs, so there's quite a bit of benefit
by staying at the bleeding edge.

Regards,

Tomeu

 Please note that we don't need to use sudo as all dependencies are
 installed in a user-writable directory.

 Ok.  Thanks for the explanations.

 --
  Bastien

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-25 Thread Tomeu Vizoso
On Sun, May 24, 2009 at 13:31, Bastien bastiengue...@googlemail.com wrote:
 +1 on the overall.

 Building Sugar from source should be as easy as:

 ,
 | ~$ git://git.sugarlabs.org/sugar-core/mainline.git
 | ~$ ./configure
 | ~$ make
 | ~$ sudo make install
 `

Well, that works for the sugar shell provided you have all the
dependencies installed. The point of jhbuild is precisely to get you
an environment where all the dependencies of the software you are
interested in are installed without breaking your regular desktop.

Please note that we don't need to use sudo as all dependencies are
installed in a user-writable directory.

Regards,

Tomeu

 (Sidenote: I guess it's a gitorious thingy, but mainline.git is a pretty
 stupid name for a git repo. It forces the user to create folders by hand
 when pulling several projects.  Why not sugar-core.git?)

 I would also advocate having sugar-jhbuild reduced to sugar-core, where
 the only activity is the Journal.  Other activities should be installed
 separately, either one by one or by bundle.

 Bernie Innocenti ber...@codewiz.org writes:

 Today I've kick-started a newbie on building Sugar to fix a small bug
 and submit his first patch.

 It was just painful.  jhbuild has plenty of rough corners and we could
 easily make things easier with a few changes:

 1) Stop checking out random unstable versions of external projects.
 They break very often, and we cannot fix them.  Let's instead upgrade
 manually every once in a while after some testing.

 2) Do not build C modules that is already available (and recent enough)
 in popular distros.  Specifically: abiword, matchbox, hippocanvas...

 3) Let's move etoys away from the base set of components: the repository
 is often offline, building it breaks very often, and it takes a lot of
 time.  You don't need it in order to test Sugar, the same way you don't
 need TamTam and TurtleArt.

 4) We could check for prerequisites before starting the build.  Some
 configure scripts are stupid enough to fail tests silently and proceed
 anyway using no as a command name in make :-)

 If there's consensus on implementing one or more of these points, I can
 provide patches (or just go on and commit them).

 --
  Bastien
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-25 Thread Bastien
Tomeu Vizoso to...@sugarlabs.org writes:

 On Sun, May 24, 2009 at 13:31, Bastien bastiengue...@googlemail.com wrote:
 +1 on the overall.

 Building Sugar from source should be as easy as:

 ,
 | ~$ git://git.sugarlabs.org/sugar-core/mainline.git
 | ~$ ./configure
 | ~$ make
 | ~$ sudo make install
 `

 Well, that works for the sugar shell provided you have all the
 dependencies installed. The point of jhbuild is precisely to get you
 an environment where all the dependencies of the software you are
 interested in are installed without breaking your regular desktop.

Sorry to be dull here... IIUC, what you describe is the main difference
between jhbuild and, say, apt-get install sugar on Ubuntu: in the later
case, dependancies are taken care of by the .deb package whereas in the
jhbuild case they are all integrated in the jhbuild source?  Does that
make sense?

 Please note that we don't need to use sudo as all dependencies are
 installed in a user-writable directory.

Ok.  Thanks for the explanations.

-- 
 Bastien
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-24 Thread Bastien
+1 on the overall.

Building Sugar from source should be as easy as:

,
| ~$ git://git.sugarlabs.org/sugar-core/mainline.git
| ~$ ./configure 
| ~$ make
| ~$ sudo make install
`

(Sidenote: I guess it's a gitorious thingy, but mainline.git is a pretty
stupid name for a git repo. It forces the user to create folders by hand
when pulling several projects.  Why not sugar-core.git?)

I would also advocate having sugar-jhbuild reduced to sugar-core, where
the only activity is the Journal.  Other activities should be installed
separately, either one by one or by bundle.

Bernie Innocenti ber...@codewiz.org writes:

 Today I've kick-started a newbie on building Sugar to fix a small bug
 and submit his first patch.

 It was just painful.  jhbuild has plenty of rough corners and we could
 easily make things easier with a few changes:

 1) Stop checking out random unstable versions of external projects.
 They break very often, and we cannot fix them.  Let's instead upgrade
 manually every once in a while after some testing.

 2) Do not build C modules that is already available (and recent enough)
 in popular distros.  Specifically: abiword, matchbox, hippocanvas...

 3) Let's move etoys away from the base set of components: the repository
 is often offline, building it breaks very often, and it takes a lot of
 time.  You don't need it in order to test Sugar, the same way you don't
 need TamTam and TurtleArt.

 4) We could check for prerequisites before starting the build.  Some
 configure scripts are stupid enough to fail tests silently and proceed
 anyway using no as a command name in make :-)

 If there's consensus on implementing one or more of these points, I can
 provide patches (or just go on and commit them).

-- 
 Bastien
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-24 Thread Rafael Enrique Ortiz Guerrero
On Sun, May 24, 2009 at 6:31 AM, Bastien bastiengue...@googlemail.comwrote:

 +1 on the overall.

 Building Sugar from source should be as easy as:

 ,
 | ~$ git://git.sugarlabs.org/sugar-core/mainline.git
 | ~$ ./configure
 | ~$ make
 | ~$ sudo make install
 `

 (Sidenote: I guess it's a gitorious thingy, but mainline.git is a pretty
 stupid name for a git repo. It forces the user to create folders by hand
 when pulling several projects.  Why not sugar-core.git?)


You can use something like..

git clone git://git.sugarlabs.org/project/mainline.git project


to avoid creating folders by hand.



 I would also advocate having sugar-jhbuild reduced to sugar-core, where
 the only activity is the Journal.  Other activities should be installed
 separately, either one by one or by bundle.

 Bernie Innocenti ber...@codewiz.org writes:

  Today I've kick-started a newbie on building Sugar to fix a small bug
  and submit his first patch.
 
  It was just painful.  jhbuild has plenty of rough corners and we could
  easily make things easier with a few changes:
 
  1) Stop checking out random unstable versions of external projects.
  They break very often, and we cannot fix them.  Let's instead upgrade
  manually every once in a while after some testing.
 
  2) Do not build C modules that is already available (and recent enough)
  in popular distros.  Specifically: abiword, matchbox, hippocanvas...
 
  3) Let's move etoys away from the base set of components: the repository
  is often offline, building it breaks very often, and it takes a lot of
  time.  You don't need it in order to test Sugar, the same way you don't
  need TamTam and TurtleArt.
 
  4) We could check for prerequisites before starting the build.  Some
  configure scripts are stupid enough to fail tests silently and proceed
  anyway using no as a command name in make :-)
 
  If there's consensus on implementing one or more of these points, I can
  provide patches (or just go on and commit them).

 --
  Bastien
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-24 Thread Bastien
Rafael Enrique Ortiz Guerrero dir...@gmail.com writes:

 You can use something like..

 git clone git://git.sugarlabs.org/project/mainline.git project

 to avoid creating folders by hand.

Yes, thanks!

-- 
 Bastien
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-23 Thread Bernie Innocenti
On 05/22/09 20:18, Sascha Silbe wrote:
 On Fri, May 22, 2009 at 03:45:04PM +0200, Bernie Innocenti wrote:
 
 Support for Fedora 11 was missing in sysdeps.  I pushed a patch adding
 it.
 Thanks! The way Fedora versioning works is starting to get annoying (I
 had to add Fedora 10.93 just two weeks ago). Maybe we should add some
 kind of fallback hack (i.e. use Rawhide for unknown versions) for Fedora.

Good idea, if it's not too much trouble.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-22 Thread Sascha Silbe

On Wed, May 20, 2009 at 11:29:56PM +0200, NoiseEHC wrote:

When I tried jhbuild what I found strange that it does not detect the 
Linux distro so I had to manually enter commands as it was specified 
on the wiki.
That must have been quite some time ago as sugar-jhbuild does detect the 
distro (using lsb-release) since before I started maintaining it. I also 
purged outdated instructions some time ago.


If your distro isn't detected (i.e. ./sugar-jhbuild depscheck is 
giving an error) then either
a) something is broken (recently happened for Fedora because of the 
Rawhide - F11 switchover, but has already been fixed) or

b) you don't have lsb-release installed or
c) it's currently unknown/unsupported (i.e. not one of Debian 
squeeze/sid, Fedora 10/11, Ubuntu intrepid/jaunty).


CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-22 Thread Sascha Silbe

On Thu, May 21, 2009 at 01:29:12PM +0200, NoiseEHC wrote:


I am talking about this:
http://wiki.sugarlabs.org/go/Development_Team/Jhbuild/Fedora
I'm assuming you're talking about the Prerequisites section. There are 
two answers to your question:
1. (sugar-)jhbuild needs a certain set of packages to work at all (git, 
svn, ...), so those need to be installed before you even start 
sugar-jhbuild. While we could do some wrapper checking for all of these 
programs and warning the user accordingly, I do not see any real 
advantage in doing so. The user (*) should read the instructions (i.e. 
the wiki page) anyway.
2. (sugar-)jhbuild only has support for single packages as dependencies, 
not package groups (Debian tasks, Fedora groups, ...). Adding support 
for this is possible, but again with little benefit (as we'd only need 
it for prerequisites).



BTW text like the dependency check will fail if you don't have a  
DISPLAY set does not mean too much for Windows people like me (I did  
manage to google the answer so it was not a question).
I've never seen that happen, so that note is gone for good now. If it 
evers occurs again, please file a bug (as it definitely is a bug).



(*) Read: developer / power user. sugar-jhbuild is not meant for 
ordinary users.


CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-22 Thread Sascha Silbe

On Thu, May 21, 2009 at 08:28:07PM +0200, Bernie Innocenti wrote:


xulrunner now fails to build with gcc 4.4 (in F11) because of a tiny
error in an #elif directive.  Is there a way in jhbuild to apply 
patches

to sources?
Take a look at the telepathy-gabble definition. Other modules try to 
apply patches as well but actually don't because they're using the wrong 
syntax. (*)



xulrunner is also one of the worst compile time hog we have.  If we
could only build it on distros that require it, it would save a lot of
trouble to a lot of developers.

+5. See [1] for what you can do to change that. ;)



I'd vote for disabling it now and lazily wait to see if someone
complains before actually adding a workaround.
You mean you want to break Browse for Debian (the only system where we 
actually compile xulrunner ourselves)? No icecream for you :-P



4) We could check for prerequisites before starting the build.  Some
configure scripts are stupid enough to fail tests silently and 
proceed

anyway using no as a command name in make :-)
Do you mean we should run ./sugar-jhbuild depscheck before each build 
or is it not working at all for you?
In the former case, I would recommend against at, as depscheck is rather 
slow. In the latter case, please provide more details (distro version, 
exact error output, lsb_release output, ...).


(*) I've not yet had time to check whether these patches should actually 
be applied. Seems like it has been broken for quite some time (if it 
ever worked), so the patches are likely to be stale.

[1] http://dev.sugarlabs.org/ticket/137

CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-22 Thread Sascha Silbe

On Thu, May 21, 2009 at 08:41:40PM +0200, Tomeu Vizoso wrote:


No need to do that for all users, we can do it distro by distro. I
think that each distro in jhbuild should have its maintainer, as
Sascha cannot run all of them.
Currently I am (running an instance of all supported distros), but 
you're totally right this doesn't scale well. For a start, a Mandriva 
maintainer would be nice (currently the only distro we don't support, 
but have a set of dependencies for).



Also, maybe what we need is better documentation rather than big
changes that bring new problems?

What kind of documentation are you thinking of?

CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-22 Thread Sascha Silbe

On Thu, May 21, 2009 at 01:34:20PM +0200, NoiseEHC wrote:

For example by autodetecting the Linux distro, it could create a full  
command line. Of course, if it could be automated then it should just  
say something:
The following dependencies are missing: long list here. To install  
them, type in your root password: type here.
Certainly possible, though I have some thoughts regarding the details 
(e.g. the user shouldn't ever type any password into a random program). 
Please file a feature request upstream (i.e. at Gnome).


And why shall I run jhbuild 3 times anyway? It could have a default  
option when it does an update then depscheck and then a build...
Actually you only need to run it two times, as the update part is 
redundant:


[1]:
(Note that build will update first anyway, so run update separately if 
you want to see what changed more easily.)


I agree it's a bit buried, improvements are welcome.
Regarding doing a default macro consisting of depscheck + build, it's a 
good idea. Please file a bug at dev.sugarlabs.org against sugar-jhbuild 
so I don't forget about it. Patches are welcome, of course (take a look 
at sjhbuild/main.py). :)



[1] http://wiki.sugarlabs.org/go/Development_Team/Jhbuild#Other_commands

CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-22 Thread Tomeu Vizoso
On Fri, May 22, 2009 at 14:59, Sascha Silbe
sascha-ml-sugar-de...@silbe.org wrote:
 On Fri, May 22, 2009 at 02:47:22PM +0200, Tomeu Vizoso wrote:

 Also, maybe what we need is better documentation rather than big
 changes that bring new problems?

 What kind of documentation are you thinking of?

 Something like what we currently have, only that addressing the points
 recently raised.

 Can you be a bit more specific, please?

Sorry, the conversation started by Bernie included lots of stuff.
Maybe Bernie could enter tickets for all the jhbuild and documentation
improvements he has identified?

Regards,

Tomeu

 CU Sascha

 --
 http://sascha.silbe.org/
 http://www.infra-silbe.de/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iQEcBAEBAgAGBQJKFqGxAAoJELpz82VMF3DadZwIAJsGMWSxOxodegM6q36d3hR0
 pnQH+JnBQAJb5MqMqCxx9OhgjwxjHc8TjMBw7arqGN/1+Pvzp9sRPa2Hzm87xegH
 kBolRaW01ZllVOttlVYiOpOpuXx8iXRgGrt6dfHGiJ19LsFR9peq8nIGZQBGkF00
 xQTchZEhmfueJM0XIb1Il7t0XfkoYCsoP+guBTJ4ni7Wq1D5ASsafXq7J36h0VxT
 DJKYKzASlpScC4gOGW0GaUz8PWWJJ/+frxZUIF4mZYWe/0BDZ9U6M/ujjK4/cCiu
 Swn3PLt9DYLfqWPO0mrDOc8+nLds5htF/pZURgWGQg2qn20FCp4C8i2RcsRSWI8=
 =pUVc
 -END PGP SIGNATURE-


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-22 Thread Sascha Silbe

On Fri, May 22, 2009 at 02:47:22PM +0200, Tomeu Vizoso wrote:


Also, maybe what we need is better documentation rather than big
changes that bring new problems?

What kind of documentation are you thinking of?

Something like what we currently have, only that addressing the points
recently raised.

Can you be a bit more specific, please?

CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-22 Thread Bernie Innocenti
On 05/22/09 13:29, Sascha Silbe wrote:
 On Wed, May 20, 2009 at 11:29:56PM +0200, NoiseEHC wrote:
 
 When I tried jhbuild what I found strange that it does not detect the
 Linux distro so I had to manually enter commands as it was specified
 on the wiki.
 That must have been quite some time ago as sugar-jhbuild does detect the
 distro (using lsb-release) since before I started maintaining it. I also
 purged outdated instructions some time ago.
 
 If your distro isn't detected (i.e. ./sugar-jhbuild depscheck is
 giving an error) then either
 a) something is broken (recently happened for Fedora because of the
 Rawhide - F11 switchover, but has already been fixed) or
 b) you don't have lsb-release installed or
 c) it's currently unknown/unsupported (i.e. not one of Debian
 squeeze/sid, Fedora 10/11, Ubuntu intrepid/jaunty).

Support for Fedora 11 was missing in sysdeps.  I pushed a patch adding it.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-22 Thread Sascha Silbe

On Fri, May 22, 2009 at 03:45:04PM +0200, Bernie Innocenti wrote:

Support for Fedora 11 was missing in sysdeps.  I pushed a patch adding 
it.
Thanks! The way Fedora versioning works is starting to get annoying (I 
had to add Fedora 10.93 just two weeks ago). Maybe we should add some 
kind of fallback hack (i.e. use Rawhide for unknown versions) for 
Fedora.


CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-22 Thread Edward Cherlin
On Thu, May 21, 2009 at 11:41 AM, Tomeu Vizoso to...@sugarlabs.org wrote:

 As with any other sugar module, people want to run the latest code
 because it will contain bugfixes, etc. I see hulahop in the same way.

As with any other module of anything, some people want to run Stable,
some want Testing, some want Unstable, the very latest code. (I am
using Debian terminology, but the concepts apply anywhere.) I am
willing to use Testing, but not Unstable. I want an option to build
something that is known to compile, with a mechanism in place to
determine when we move forward to another level, and to enforce
periodic bug-triage and bug-fixing when we need to make that move. We
owe this to our development community.
-- 
Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
And Children are my nation.
The Cosmos is my dwelling place, The Truth my destination.
http://earthtreasury.org/worknet (Edward Mokurai Cherlin)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-22 Thread David Van Assche
I can only speak of opensuse and mandriva but we compile xulrunner ourselves
on those 2 plaftorms...

David (nubae)

On Fri, May 22, 2009 at 9:56 PM, Edward Cherlin echer...@gmail.com wrote:

 On Thu, May 21, 2009 at 11:41 AM, Tomeu Vizoso to...@sugarlabs.org
 wrote:

  As with any other sugar module, people want to run the latest code
  because it will contain bugfixes, etc. I see hulahop in the same way.

 As with any other module of anything, some people want to run Stable,
 some want Testing, some want Unstable, the very latest code. (I am
 using Debian terminology, but the concepts apply anywhere.) I am
 willing to use Testing, but not Unstable. I want an option to build
 something that is known to compile, with a mechanism in place to
 determine when we move forward to another level, and to enforce
 periodic bug-triage and bug-fixing when we need to make that move. We
 owe this to our development community.
 --
 Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
 And Children are my nation.
 The Cosmos is my dwelling place, The Truth my destination.
 http://earthtreasury.org/worknet (Edward Mokurai Cherlin)
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-21 Thread Tomeu Vizoso
On Wed, May 20, 2009 at 21:10, Bernie Innocenti ber...@codewiz.org wrote:
 Today I've kick-started a newbie on building Sugar to fix a small bug
 and submit his first patch.

 It was just painful.  jhbuild has plenty of rough corners and we could
 easily make things easier with a few changes:

 1) Stop checking out random unstable versions of external projects.
 They break very often, and we cannot fix them.  Let's instead upgrade
 manually every once in a while after some testing.

We are supposed to be doing this already, which modules are not
following this rule?

 2) Do not build C modules that is already available (and recent enough)
 in popular distros.  Specifically: abiword, matchbox, hippocanvas...

About abiword, we have been depending lately on modifications not
released on a tarball, but 2.7.0 was released recently and it should
contain all we need for now. If during 0.85 we need to hack further on
it, we may need to create unstable tarballs ourselves. Also, not all
distros are building it a way it can be used by Sugar, we should
check.

About hippo, we are the only users, so it can be considered as any
other Sugar module.

About xulrunner, we often want to test with the version that is going
to ship on the next distro releases, plus some distros still don't
package it in a way usable by Sugar (we should fix this).

 3) Let's move etoys away from the base set of components: the repository
 is often offline, building it breaks very often, and it takes a lot of
 time.  You don't need it in order to test Sugar, the same way you don't
 need TamTam and TurtleArt.

I guess this makes sense, though would be good to hear people who hack
on eToys in Sugar.

 4) We could check for prerequisites before starting the build.  Some
 configure scripts are stupid enough to fail tests silently and proceed
 anyway using no as a command name in make :-)

We are supposed to be doing this already. If it's not working then we
should fix it.

 If there's consensus on implementing one or more of these points, I can
 provide patches (or just go on and commit them).

Totally, Sascha is the maintainer so coordinate with him.

Thanks,

Tomeu
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-21 Thread Bernie Innocenti
On 05/20/09 23:29, NoiseEHC wrote:
 When I tried jhbuild what I found strange that it does not detect the
 Linux distro so I had to manually enter commands as it was specified on
 the wiki. Can we get rid of that? (I have no idea how to detect the
 distro or how to automate that just to let you know this fact...)

You mean for installing dependencies?  This requires root privileges, so
jhbuild can't do it on its own.

Besides, we used to have some distro-specific dependency check in the
past, but I someone (marcopg?) ripped it off, probably because it was a
pita to maintain.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-21 Thread Tomeu Vizoso
On Thu, May 21, 2009 at 12:40, Bernie Innocenti ber...@codewiz.org wrote:
 On 05/20/09 23:29, NoiseEHC wrote:
 When I tried jhbuild what I found strange that it does not detect the
 Linux distro so I had to manually enter commands as it was specified on
 the wiki. Can we get rid of that? (I have no idea how to detect the
 distro or how to automate that just to let you know this fact...)

 You mean for installing dependencies?  This requires root privileges, so
 jhbuild can't do it on its own.

 Besides, we used to have some distro-specific dependency check in the
 past, but I someone (marcopg?) ripped it off, probably because it was a
 pita to maintain.

Wasn't ripped off, but improved, we check for system dependencies in
the supported platforms like this:

./sugar-jhbuild depscheck

This will tell you which packages to install with yum/apt-get/etc.

How can we make this more obvious?

Regards,

Tomeu
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-21 Thread NoiseEHC

Bernie Innocenti wrote:

On 05/20/09 23:29, NoiseEHC wrote:
  

When I tried jhbuild what I found strange that it does not detect the
Linux distro so I had to manually enter commands as it was specified on
the wiki. Can we get rid of that? (I have no idea how to detect the
distro or how to automate that just to let you know this fact...)



You mean for installing dependencies?  This requires root privileges, so
jhbuild can't do it on its own.

Besides, we used to have some distro-specific dependency check in the
past, but I someone (marcopg?) ripped it off, probably because it was a
pita to maintain.

  

I am talking about this:
http://wiki.sugarlabs.org/go/Development_Team/Jhbuild/Fedora
As I told I do not know how difficult can it be to automate so if it 
would be a lot of work then of course you should not put too much work 
into it.
BTW text like the dependency check will fail if you don't have a 
DISPLAY set does not mean too much for Windows people like me (I did 
manage to google the answer so it was not a question).


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-21 Thread NoiseEHC

Tomeu Vizoso wrote:

On Thu, May 21, 2009 at 12:40, Bernie Innocenti ber...@codewiz.org wrote:
  

On 05/20/09 23:29, NoiseEHC wrote:


When I tried jhbuild what I found strange that it does not detect the
Linux distro so I had to manually enter commands as it was specified on
the wiki. Can we get rid of that? (I have no idea how to detect the
distro or how to automate that just to let you know this fact...)
  

You mean for installing dependencies?  This requires root privileges, so
jhbuild can't do it on its own.

Besides, we used to have some distro-specific dependency check in the
past, but I someone (marcopg?) ripped it off, probably because it was a
pita to maintain.



Wasn't ripped off, but improved, we check for system dependencies in
the supported platforms like this:

./sugar-jhbuild depscheck

This will tell you which packages to install with yum/apt-get/etc.

How can we make this more obvious?

Regards,

Tomeu


  
For example by autodetecting the Linux distro, it could create a full 
command line. Of course, if it could be automated then it should just 
say something:
The following dependencies are missing: long list here. To install 
them, type in your root password: type here.

Of course if it would be a lot of work you should not waste your time in it.
And why shall I run jhbuild 3 times anyway? It could have a default 
option when it does an update then depscheck and then a build...


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-21 Thread Bernie Innocenti
On 05/21/09 10:03, Tomeu Vizoso wrote:
 1) Stop checking out random unstable versions of external projects.
 They break very often, and we cannot fix them.  Let's instead upgrade
 manually every once in a while after some testing.
 
 We are supposed to be doing this already, which modules are not
 following this rule?

I'm looking at the glucose-external.modules, and I see these modules
being checked out from the tip of the master branch:

 - squeak
 - hulahop
 - hippo-canvas


 2) Do not build C modules that is already available (and recent enough)
 in popular distros.  Specifically: abiword, matchbox, hippocanvas...
 
 About abiword, we have been depending lately on modifications not
 released on a tarball, but 2.7.0 was released recently and it should
 contain all we need for now. If during 0.85 we need to hack further on
 it, we may need to create unstable tarballs ourselves. Also, not all
 distros are building it a way it can be used by Sugar, we should
 check.

And besides, abiword 2.7.0 is not yet in F11 nor Jaunty.


 About hippo, we are the only users, so it can be considered as any
 other Sugar module.

Ok, but it's already packaged in all the distros we target, so why make
people spend precious time building it from source?


 About xulrunner, we often want to test with the version that is going
 to ship on the next distro releases, plus some distros still don't
 package it in a way usable by Sugar (we should fix this).

xulrunner now fails to build with gcc 4.4 (in F11) because of a tiny
error in an #elif directive.  Is there a way in jhbuild to apply patches
to sources?

xulrunner is also one of the worst compile time hog we have.  If we
could only build it on distros that require it, it would save a lot of
trouble to a lot of developers.

I'd vote for disabling it now and lazily wait to see if someone
complains before actually adding a workaround.


 3) Let's move etoys away from the base set of components: the repository
 is often offline, building it breaks very often, and it takes a lot of
 time.  You don't need it in order to test Sugar, the same way you don't
 need TamTam and TurtleArt.
 
 I guess this makes sense, though would be good to hear people who hack
 on eToys in Sugar.

Ok, although this shouldn't impair them in any way.  We just move etoys
to a module that regular users don't have to build by default.


 4) We could check for prerequisites before starting the build.  Some
 configure scripts are stupid enough to fail tests silently and proceed
 anyway using no as a command name in make :-)
 
 We are supposed to be doing this already. If it's not working then we
 should fix it.

It's definitely not working, because we had to manually find out what
was missing along the way.  Do you have any idea where I should look?


 If there's consensus on implementing one or more of these points, I can
 provide patches (or just go on and commit them).
 
 Totally, Sascha is the maintainer so coordinate with him.

OK.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-21 Thread Bert Freudenberg

On 21.05.2009, at 01:03, Tomeu Vizoso wrote:

 On Wed, May 20, 2009 at 21:10, Bernie Innocenti ber...@codewiz.org  
 wrote:
 Today I've kick-started a newbie on building Sugar to fix a small bug
 and submit his first patch.

 It was just painful.  jhbuild has plenty of rough corners and we  
 could
 easily make things easier with a few changes:
 [...]
 3) Let's move etoys away from the base set of components: the  
 repository
 is often offline, building it breaks very often, and it takes a lot  
 of
 time.  You don't need it in order to test Sugar, the same way you  
 don't
 need TamTam and TurtleArt.

 I guess this makes sense, though would be good to hear people who hack
 on eToys in Sugar.


I think the breaks very often assertion is unqualified. But sure,  
removing Etoys from the default build set should be fine.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-21 Thread Bernie Innocenti
On 05/21/09 13:29, NoiseEHC wrote:
 I am talking about this:
 http://wiki.sugarlabs.org/go/Development_Team/Jhbuild/Fedora
 As I told I do not know how difficult can it be to automate so if it
 would be a lot of work then of course you should not put too much work
 into it.
 BTW text like the dependency check will fail if you don't have a
 DISPLAY set does not mean too much for Windows people like me (I did
 manage to google the answer so it was not a question).

You're right.  Please, update the wiki with more information for newbies.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-20 Thread NoiseEHC
Bernie Innocenti wrote:
 Today I've kick-started a newbie on building Sugar to fix a small bug
 and submit his first patch.

 It was just painful.  jhbuild has plenty of rough corners and we could
 easily make things easier with a few changes:

 1) Stop checking out random unstable versions of external projects.
 They break very often, and we cannot fix them.  Let's instead upgrade
 manually every once in a while after some testing.

 2) Do not build C modules that is already available (and recent enough)
 in popular distros.  Specifically: abiword, matchbox, hippocanvas...

 3) Let's move etoys away from the base set of components: the repository
 is often offline, building it breaks very often, and it takes a lot of
 time.  You don't need it in order to test Sugar, the same way you don't
 need TamTam and TurtleArt.

 4) We could check for prerequisites before starting the build.  Some
 configure scripts are stupid enough to fail tests silently and proceed
 anyway using no as a command name in make :-)

 If there's consensus on implementing one or more of these points, I can
 provide patches (or just go on and commit them).

   
When I tried jhbuild what I found strange that it does not detect the 
Linux distro so I had to manually enter commands as it was specified on 
the wiki. Can we get rid of that? (I have no idea how to detect the 
distro or how to automate that just to let you know this fact...)

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Simplifying sugar-jhbuild

2009-05-20 Thread Edward Cherlin
+1 overall.

The Wiki recommends sugar-jhbuild as an environment for developers.

http://wiki.sugarlabs.org/go/Development_Team

Development systems

All of core Sugar development except system-dependent modifications
can be done on a standard computer by compiling jhbuild and editing
with your favorite editor (eclipse/pydev, emacs, vim, etc.).

Given its dismal record of being able to compile and run, I have not
found that to be the case. I had complete success _once_ over a period
of months.

On Wed, May 20, 2009 at 12:10 PM, Bernie Innocenti ber...@codewiz.org wrote:
 Today I've kick-started a newbie on building Sugar to fix a small bug
 and submit his first patch.

 It was just painful.  jhbuild has plenty of rough corners and we could
 easily make things easier with a few changes:

 1) Stop checking out random unstable versions of external projects.
 They break very often, and we cannot fix them.  Let's instead upgrade
 manually every once in a while after some testing.

Yes!

 2) Do not build C modules that is already available (and recent enough)
 in popular distros.  Specifically: abiword, matchbox, hippocanvas...

Assuming that we aren't building modified versions, of course.

 3) Let's move etoys away from the base set of components: the repository
 is often offline, building it breaks very often, and it takes a lot of
 time.  You don't need it in order to test Sugar, the same way you don't
 need TamTam and TurtleArt.

And you don't usually need Sugar to test Etoys. Now that we have
numerous functioning images with functioning Activities, this works
for me. Although I would miss TamTam and Turtle Art. Did I mention
that The Tech Museum of Innovation in San Jose (California) wants to
do an XO exhibit, with a focus on art and music education?

 4) We could check for prerequisites before starting the build.  Some
 configure scripts are stupid enough to fail tests silently and proceed
 anyway using no as a command name in make :-)

Isn't that supposed to be the purpose of './sugar-jhbuild depscheck'?
It doesn't always work, and could be considerably improved with
distribution-specific knowledge.

 If there's consensus on implementing one or more of these points, I can
 provide patches (or just go on and commit them).

Please.

 --
   // Bernie Innocenti - http://codewiz.org/
  \X/  Sugar Labs       - http://sugarlabs.org/
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel




-- 
Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
And Children are my nation.
The Cosmos is my dwelling place, The Truth my destination.
http://earthtreasury.org/worknet (Edward Mokurai Cherlin)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel