Re: [Sugar-devel] Simplifying sugar-jhbuild
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
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
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
+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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[Sugar-devel] Simplifying sugar-jhbuild
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). -- // 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
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
+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
