Re: [Sugar-devel] GSoC 2014 - Porting the Sugar core onto Python 3.x info
Hello Daniel, So Improving the unit tests before the actual porting is a must, duely noted. If only =3.3 is supported, all the activities HAVE to be ported to =3.3 as well. Don't you think supporting 2.7+ for a while will enable a smoother transition? I also looked at the dependencies, telepathy doesn't seem to be ported to 3.3 yet, how do you think we should go about porting then? On 9 March 2014 06:02, Daniel Narvaez dwnarv...@gmail.com wrote: I think supporting multiple python versions would be too much of a burden, we are busy enough supporting three toolkits :) Fedora 18 seems to have 3.3 so I think it would be fine to support = 3.3. The unit tests in place are not really thorough, we started writing them only recently. Help improving that would be certainly very welcome. On Saturday, 8 March 2014, Ravi Kumar upma...@gmail.com wrote: Hello everyone, I'm Ravi Kumar, an undergrad Computer Science and Engineering student based in Bangalore. I'm familiar with Source code management with git and proficient with Python, Ruby and C, although I haven't made any real contributions to open-source projects. So this is all the more exciting to me. I see GSoC as a very good opportunity to learn and also be a part of and give something back to a community. I went through the Ideas page and was interested in porting the sugar core onto Python 3.x and I had a bunch of questions. 1. Are there any constraints the community places on the strategy that is to be adopted to port the code or are the strategies up to the person submitting the proposal? 2. How reliable and thorough are the unit tests that are in place? Here's what I've thought through so far. Maintaining a code base in python 2 or in python 3 and then using 2to3 or 3to2 to give out releases is going to be problematic. Say someone files a bug against the Python 3.x version and the code for it was generated using 2to3, there wouldn't be a very good way to fix this. So my initial strategy is to strengthen the unit tests, make them compatible across 2.6-3.3, automate testing with python 2.6 and 3.3 simultaneously with Tox or a similar tool, and then incrementally write polyglot using the six package and other methods to pass more and more unit tests until the whole of the codebase supports Python 2.6 through to 3.3. Then, improve and update the documentation so that the codebase is easy to maintain in the future. Thanks, Ravi Kumar -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC 2014 - Porting the Sugar core onto Python 3.x info
On Mar 9, 2014 7:23 PM, Ravi Kumar upma...@gmail.com wrote: Hello Daniel, So Improving the unit tests before the actual porting is a must, duely noted. If only =3.3 is supported, all the activities HAVE to be ported to =3.3 as well. Don't you think supporting 2.7+ for a while will enable a smoother transition? I also looked at the dependencies, telepathy doesn't seem to be ported to 3.3 yet, Yay! An excuse to make the collab framework so it actually works on things other than XO! This could be interesting. how do you think we should go about porting then? On 9 March 2014 06:02, Daniel Narvaez dwnarv...@gmail.com wrote: I think supporting multiple python versions would be too much of a burden, we are busy enough supporting three toolkits :) Fedora 18 seems to have 3.3 so I think it would be fine to support = 3.3. The unit tests in place are not really thorough, we started writing them only recently. Help improving that would be certainly very welcome. On Saturday, 8 March 2014, Ravi Kumar upma...@gmail.com wrote: Hello everyone, I'm Ravi Kumar, an undergrad Computer Science and Engineering student based in Bangalore. I'm familiar with Source code management with git and proficient with Python, Ruby and C, although I haven't made any real contributions to open-source projects. So this is all the more exciting to me. I see GSoC as a very good opportunity to learn and also be a part of and give something back to a community. I went through the Ideas page and was interested in porting the sugar core onto Python 3.x and I had a bunch of questions. 1. Are there any constraints the community places on the strategy that is to be adopted to port the code or are the strategies up to the person submitting the proposal? 2. How reliable and thorough are the unit tests that are in place? Here's what I've thought through so far. Maintaining a code base in python 2 or in python 3 and then using 2to3 or 3to2 to give out releases is going to be problematic. Say someone files a bug against the Python 3.x version and the code for it was generated using 2to3, there wouldn't be a very good way to fix this. So my initial strategy is to strengthen the unit tests, make them compatible across 2.6-3.3, automate testing with python 2.6 and 3.3 simultaneously with Tox or a similar tool, and then incrementally write polyglot using the six package and other methods to pass more and more unit tests until the whole of the codebase supports Python 2.6 through to 3.3. Then, improve and update the documentation so that the codebase is easy to maintain in the future. Thanks, Ravi Kumar -- Daniel Narvaez ___ 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] Sugar 0.101.3 (unstable)
this release marks our feature freeze for 0.102. Now let's focus on bug fixing! It would be useful to see release notes for each release so as to know what's changed, added and needs to be tested rather than a tarball list dumped to the list. Sources: http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.101.4.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.101.3.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.101.3.tar.xz Will be in tomorrow's F-21/rawhide compose. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
On 9 March 2014 11:02, Peter Robinson pbrobin...@gmail.com wrote: this release marks our feature freeze for 0.102. Now let's focus on bug fixing! It would be useful to see release notes for each release so as to know what's changed, added and needs to be tested rather than a tarball list dumped to the list. I agree, but at the moment I have no time to do that myself. We could have a page in sugar-docs and reviewers would fill in items that are release note worthy when pushing pull requests. Sort of worried about raising the review barrier though. What do people think about that? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC 2014 - Porting the Sugar core onto Python 3.x info
On 9 March 2014 09:23, Ravi Kumar upma...@gmail.com wrote: Hello Daniel, So Improving the unit tests before the actual porting is a must, duely noted. If only =3.3 is supported, all the activities HAVE to be ported to =3.3 as well. Don't you think supporting 2.7+ for a while will enable a smoother transition? Oh I was think about sugar and I forgot about sugar-toolkit-gtk3. So yes, we will have to keep compatibility with 2.7 in toolkit for a looong time. I also looked at the dependencies, telepathy doesn't seem to be ported to 3.3 yet, how do you think we should go about porting then? Ugh. The only way I can think of approaching this is to port telepathy upstream and then keep 2.7 compatibility in sugar until ported telepathy is widely available in distros. Honestly this makes me wonder if we should wait a bit more before porting to python 3. At least until all our dependencies has been ported and available in distros. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Regarding JS collaboration project
If I remember correctly Emil also agreed that the new framework should be independent from telepathy at some point and even worked on it. On 9 March 2014 06:45, Prasoon Shukla prasoon92.i...@gmail.com wrote: Hi Sam. Sorry for the late response but I was occupied with academics. Anyway, I need to bother you again with some questions. So, I went through the thread by Emil Dudev and read the arguments he made in favour of not using the mozilla node server and using telepathy instead. To that, dnarvaez said that using the node server might be a better idea since the current protocol is very unstable. Now, I am somewhat familiar with sugar codebase but certainly not enough to actually discuss the merits or demerits of either of these approaches (although personally, I like better the idea of all communication happening over websocket via a node server). So, the final decision on which approach to take will be in the hands of those more experienced. But as I said before, I would prefer it if we use the websocket protocol to have this kind of architecture: |Sugar Web Activity| - |Sugar Shell| \ \ websocket \ |Node Server| / / / |Sugar Web Activity| - |Sugar Shell| instead of the usual telepathy based communication. This I would like because: 1. We'll be able to use the mozilla server with modifications as needed. 2. We'll be able to use the *huge* node.js ecosystem for realtime communication in any way we want! And, websocket is very versatile - we can send pretty much any binary data over the network. Also, I've worked with node before and found the communication to be quite reliable (which it is not with the current XMPP based protocol, if I understood dnarvaez correctly). That said, I've only tested out my node based work with a handful of people, so... The only downside is the need to have a node server running. For the case when there is not internet connectivity, I think we can make a set of scripts that can be called to run a node server on the one of the machines, say that of the teacher, and all others will connect to it. And of course, this process needs to be simple. Anyway, it just seems right to me to augment JS activities with a JS based collaboration framework. But of course, I don't really know the details all too well to be making the decision here. So, can you please comment on this? Once this decision is made, I can start working on my application. Thanks ᐧ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-build on archlinux without broot
On 9 March 2014 04:07, Sebastian Silva sebast...@fuentelibre.org wrote: Hello, My machine is somewhat constrained in ram and diskspace so running Fedora on a chroot was slow enough that I decided to set *use_broot:false* on *prefs.json* with the intention of running the latest sugar natively. I face a few issues: First, *automake* gave me some issues, it was refusing to build with a cryptic error, it was because I needed to install the *ccache* package. Then, automake wanted to install to /usr/local/bin, so I changed group permissions to /usr/local (I did chgrp wheel /usr/local/*;; chmod g+w /usr/local/*). This installed automake. By the way, I don't think this process was required because my system's automake is newer than the one sugar-build installed. I'll look into this. If you are not hacking sugar core a lot you could just get rid of that module in modules.json. The only r,eason we are building it is that we applied a patch to make python installation quicker, which is very handy when hacking the core modules. We need to find a better solution at some point... Then issues ocurred with gwebsockets. It persistently tried to use python3.3, my system's default, instead of python2.7. Finally I found the culprit, in ./out/sandbox/install/lib/python2.7/site-packages/osbuild/build.py I replaced in line 190 one instance of python for python2.7 and it worked after that. Thanks, pushed that change. Finally when building sugar-base I had to set up the environment variable PYTHON=/usr/bin/python2.7 in order for it to build. In sugar-toolkit-gtk3 we have PYTHON=python2 AM_PATH_PYTHON I don't remember why python2 instead of python2.7 but I think that was probably what the python documentation suggested.. I think we should do the same in sugar-base. I don't think I have write access to that repo, but if you make that change and test it in archlinux, consider it reviewed :) Also, when building sugar, I had to manually create the directory ./out/install/etc/gconf/ or it would fail to install Can I see the output? It seems like something we should fix. I know this is unsupported but I just wanted to share in case somebody would like to setup a dev environment in archlinux. I like that it's rolling release and I won't have to worry about ever upgrading to the next version. My main intention is to have a nice setup for building activities, test latest sugar and also try to help diagnose the performance issues gtk3 sugar has. It's unsupported because it's unlikely to work out-of-the-box. But if anyone wants to try it on the latest version of a distro and do the kind of analysis you have been doing, then it's very useful feedback, because it's likely to find bugs, as we have been seeing here. Thanks. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC 2014 - Porting the Sugar core onto Python 3.x info
We could port telepathy-python, it's a fairly small codebase. I don't think it will be ported, the latest commit is four years old! https://github.com/PabloCastellano/telepathy-python/tree/examples/src But I didn't quite understand what exactly telepathy does. So could you point me to some resource where I could learn a bit about it? and also could you send me a list of python dependencies the sugar core relies on so I could look them up too? On 9 March 2014 16:40, Daniel Narvaez dwnarv...@gmail.com wrote: On 9 March 2014 09:23, Ravi Kumar upma...@gmail.com wrote: Hello Daniel, So Improving the unit tests before the actual porting is a must, duely noted. If only =3.3 is supported, all the activities HAVE to be ported to =3.3 as well. Don't you think supporting 2.7+ for a while will enable a smoother transition? Oh I was think about sugar and I forgot about sugar-toolkit-gtk3. So yes, we will have to keep compatibility with 2.7 in toolkit for a looong time. I also looked at the dependencies, telepathy doesn't seem to be ported to 3.3 yet, how do you think we should go about porting then? Ugh. The only way I can think of approaching this is to port telepathy upstream and then keep 2.7 compatibility in sugar until ported telepathy is widely available in distros. Honestly this makes me wonder if we should wait a bit more before porting to python 3. At least until all our dependencies has been ported and available in distros. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Subject: Re: Regarding JS collaboration project
Hi, It sounds like the school server should be the node server. Does this proposed implementation support python sugar activities? Tony On 03/09/2014 07:32 AM, sugar-devel-requ...@lists.sugarlabs.org wrote: Message: 4 Date: Sun, 9 Mar 2014 12:12:56 +0100 From: Daniel Narvaezdwnarv...@gmail.com To: Prasoon Shuklaprasoon92.i...@gmail.com Cc: Sugar-dev Develsugar-devel@lists.sugarlabs.org, Sam Parkinson sam.parkins...@gmail.com, Emil Dudevemildu...@gmail.com Subject: Re: [Sugar-devel] Regarding JS collaboration project Message-ID: canthhva+df2ihcgof2l5qmbo3xhfsuuxuukhgfyhtqovhw4...@mail.gmail.com Content-Type: text/plain; charset=utf-8 If I remember correctly Emil also agreed that the new framework should be independent from telepathy at some point and even worked on it. On 9 March 2014 06:45, Prasoon Shuklaprasoon92.i...@gmail.com wrote: Hi Sam. Sorry for the late response but I was occupied with academics. Anyway, I need to bother you again with some questions. So, I went through the thread by Emil Dudev and read the arguments he made in favour of not using the mozilla node server and using telepathy instead. To that, dnarvaez said that using the node server might be a better idea since the current protocol is very unstable. Now, I am somewhat familiar with sugar codebase but certainly not enough to actually discuss the merits or demerits of either of these approaches (although personally, I like better the idea of all communication happening over websocket via a node server). So, the final decision on which approach to take will be in the hands of those more experienced. But as I said before, I would prefer it if we use the websocket protocol to have this kind of architecture: |Sugar Web Activity| -|Sugar Shell| \ \ websocket \ |Node Server| / / / |Sugar Web Activity| -|Sugar Shell| instead of the usual telepathy based communication. This I would like because: 1. We'll be able to use the mozilla server with modifications as needed. 2. We'll be able to use the*huge* node.js ecosystem for realtime communication in any way we want! And, websocket is very versatile - we can send pretty much any binary data over the network. Also, I've worked with node before and found the communication to be quite reliable (which it is not with the current XMPP based protocol, if I understood dnarvaez correctly). That said, I've only tested out my node based work with a handful of people, so... The only downside is the need to have a node server running. For the case when there is not internet connectivity, I think we can make a set of scripts that can be called to run a node server on the one of the machines, say that of the teacher, and all others will connect to it. And of course, this process needs to be simple. Anyway, it just seems right to me to augment JS activities with a JS based collaboration framework. But of course, I don't really know the details all too well to be making the decision here. So, can you please comment on this? Once this decision is made, I can start working on my application. Thanks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC 2014 - Porting the Sugar core onto Python 3.x info
On 9 March 2014 12:50, Ravi Kumar upma...@gmail.com wrote: We could port telepathy-python, it's a fairly small codebase. I don't think it will be ported, the latest commit is four years old! https://github.com/PabloCastellano/telepathy-python/tree/examples/src It sounds like telepathy-python might be deprecated, which would explain the lack of activity http://blogs.gnome.org/danni/2011/11/17/let-us-not-mourn-telepathy-python/ Perhaps we could port our code to use telepathy through gobject-introspection or even dbus. I think that's certainly worth investigating. What worries me is that our collaboration framework is already very fragile and the developers still involved with the project doesn't really have much expertise about it. So changing code is pretty scary... But I didn't quite understand what exactly telepathy does. I'm afraid this is all the documentation there is http://telepathy.freedesktop.org/wiki/ We use it for our collaboration framework. It provides presence information and communication channels. So could you point me to some resource where I could learn a bit about it? and also could you send me a list of python dependencies the sugar core relies on so I could look them up too? I'm afraid we don't have such a list. You could grep for imports in sugar and sugar-toolkit-gtk3. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Subject: Re: Regarding JS collaboration project
In theory, yes. We could add support for the web socket based framework to the python toolkit. On 9 March 2014 13:33, Tony Anderson tony_ander...@usa.net wrote: Hi, It sounds like the school server should be the node server. Does this proposed implementation support python sugar activities? Tony On 03/09/2014 07:32 AM, sugar-devel-requ...@lists.sugarlabs.org wrote: Message: 4 Date: Sun, 9 Mar 2014 12:12:56 +0100 From: Daniel Narvaez dwnarv...@gmail.com dwnarv...@gmail.com To: Prasoon Shukla prasoon92.i...@gmail.com prasoon92.i...@gmail.com Cc: Sugar-dev Devel sugar-devel@lists.sugarlabs.org sugar-devel@lists.sugarlabs.org, Sam Parkinson sam.parkins...@gmail.com sam.parkins...@gmail.com, Emil Dudev emildu...@gmail.com emildu...@gmail.com Subject: Re: [Sugar-devel] Regarding JS collaboration project Message-ID: canthhva+df2ihcgof2l5qmbo3xhfsuuxuukhgfyhtqovhw4...@mail.gmail.com canthhva+df2ihcgof2l5qmbo3xhfsuuxuukhgfyhtqovhw4...@mail.gmail.com Content-Type: text/plain; charset=utf-8 If I remember correctly Emil also agreed that the new framework should be independent from telepathy at some point and even worked on it. On 9 March 2014 06:45, Prasoon Shukla prasoon92.i...@gmail.com prasoon92.i...@gmail.com wrote: Hi Sam. Sorry for the late response but I was occupied with academics. Anyway, I need to bother you again with some questions. So, I went through the thread by Emil Dudev and read the arguments he made in favour of not using the mozilla node server and using telepathy instead. To that, dnarvaez said that using the node server might be a better idea since the current protocol is very unstable. Now, I am somewhat familiar with sugar codebase but certainly not enough to actually discuss the merits or demerits of either of these approaches (although personally, I like better the idea of all communication happening over websocket via a node server). So, the final decision on which approach to take will be in the hands of those more experienced. But as I said before, I would prefer it if we use the websocket protocol to have this kind of architecture: |Sugar Web Activity| - |Sugar Shell|\ \ websocket \ |Node Server|/ / / |Sugar Web Activity| - |Sugar Shell| instead of the usual telepathy based communication. This I would like because: 1. We'll be able to use the mozilla server with modifications as needed. 2. We'll be able to use the **huge** node.js ecosystem for realtime communication in any way we want! And, websocket is very versatile - we can send pretty much any binary data over the network. Also, I've worked with node before and found the communication to be quite reliable (which it is not with the current XMPP based protocol, if I understood dnarvaez correctly). That said, I've only tested out my node based work with a handful of people, so... The only downside is the need to have a node server running. For the case when there is not internet connectivity, I think we can make a set of scripts that can be called to run a node server on the one of the machines, say that of the teacher, and all others will connect to it. And of course, this process needs to be simple. Anyway, it just seems right to me to augment JS activities with a JS based collaboration framework. But of course, I don't really know the details all too well to be making the decision here. So, can you please comment on this? Once this decision is made, I can start working on my application. Thanks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Subject: Re: Regarding JS collaboration project
Nice sum up Prasoon ! +1 for the node.js server back office. It will be easy to install it on a XSCE server and I'm starting to include a node.js part to my Sugarizer Server so it could work too on Sugarizer. Just as reminder, Suraj and I worked some months ago on: - A feature list of what is need for collaboration in Sugar [1] - A very basic implementation of websocket presence API on node.js [2]. Unfortunately none of us had time to work more on this. But it could be a good start point for the collaboration project. Lionel [1] https://docs.google.com/document/d/1FZRv0gSV--5Y4dvV9C9dk9K-LT7kEQEwQmX_xVX9H-s/edit [2] https://github.com/surajgillespie/SugarPresenceAPI Hi Sam. Sorry for the late response but I was occupied with academics. Anyway, I need to bother you again with some questions. So, I went through the thread by Emil Dudev and read the arguments he made in favour of not using the mozilla node server and using telepathy instead. To that, dnarvaez said that using the node server might be a better idea since the current protocol is very unstable. Now, I am somewhat familiar with sugar codebase but certainly not enough to actually discuss the merits or demerits of either of these approaches (although personally, I like better the idea of all communication happening over websocket via a node server). So, the final decision on which approach to take will be in the hands of those more experienced. But as I said before, I would prefer it if we use the websocket protocol to have this kind of architecture: |Sugar Web Activity| - |Sugar Shell|\ \ websocket \ |Node Server|/ / / |Sugar Web Activity| - |Sugar Shell| instead of the usual telepathy based communication. This I would like because: 1. We'll be able to use the mozilla server with modifications as needed. 2. We'll be able to use the **huge** node.js ecosystem for realtime communication in any way we want! And, websocket is very versatile - we can send pretty much any binary data over the network. Also, I've worked with node before and found the communication to be quite reliable (which it is not with the current XMPP based protocol, if I understood dnarvaez correctly). That said, I've only tested out my node based work with a handful of people, so... The only downside is the need to have a node server running. For the case when there is not internet connectivity, I think we can make a set of scripts that can be called to run a node server on the one of the machines, say that of the teacher, and all others will connect to it. And of course, this process nee ds to be simple. Anyway, it just seems right to me to augment JS activities with a JS based collaboration framework. But of course, I don't really know the details all too well to be making the decision here. So, can you please comment on this? Once this decision is made, I can start working on my application. Thanks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- next part -- An HTML attachment was scrubbed... URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140309/2ac4/attachment.html -- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel End of Sugar-devel Digest, Vol 65, Issue 32 *** ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Regarding JS collaboration project
If I remember correctly Emil also agreed that the new framework should be independent from telepathy It seems there were two separate threads of the same name: 1 - http://lists.sugarlabs.org/archive/sugar-devel/2014-January/046687.html 2 - http://lists.sugarlabs.org/archive/sugar-devel/2014-January/046773.html and I just read the first one _ Anyway, it's good to see that we don't want to use telepathy for this. So, I'll go ahead and take a look at Emil's code and run it. Will reply back at this thread soon. On Sun, Mar 9, 2014 at 4:42 PM, Daniel Narvaez dwnarv...@gmail.com wrote: If I remember correctly Emil also agreed that the new framework should be independent from telepathy at some point and even worked on it. On 9 March 2014 06:45, Prasoon Shukla prasoon92.i...@gmail.com wrote: Hi Sam. Sorry for the late response but I was occupied with academics. Anyway, I need to bother you again with some questions. So, I went through the thread by Emil Dudev and read the arguments he made in favour of not using the mozilla node server and using telepathy instead. To that, dnarvaez said that using the node server might be a better idea since the current protocol is very unstable. Now, I am somewhat familiar with sugar codebase but certainly not enough to actually discuss the merits or demerits of either of these approaches (although personally, I like better the idea of all communication happening over websocket via a node server). So, the final decision on which approach to take will be in the hands of those more experienced. But as I said before, I would prefer it if we use the websocket protocol to have this kind of architecture: |Sugar Web Activity| - |Sugar Shell| \ \ websocket \ |Node Server| / / / |Sugar Web Activity| - |Sugar Shell| instead of the usual telepathy based communication. This I would like because: 1. We'll be able to use the mozilla server with modifications as needed. 2. We'll be able to use the *huge* node.js ecosystem for realtime communication in any way we want! And, websocket is very versatile - we can send pretty much any binary data over the network. Also, I've worked with node before and found the communication to be quite reliable (which it is not with the current XMPP based protocol, if I understood dnarvaez correctly). That said, I've only tested out my node based work with a handful of people, so... The only downside is the need to have a node server running. For the case when there is not internet connectivity, I think we can make a set of scripts that can be called to run a node server on the one of the machines, say that of the teacher, and all others will connect to it. And of course, this process needs to be simple. Anyway, it just seems right to me to augment JS activities with a JS based collaboration framework. But of course, I don't really know the details all too well to be making the decision here. So, can you please comment on this? Once this decision is made, I can start working on my application. Thanks ᐧ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Performance testing
On 9 March 2014 17:53, Sebastian Silva sebast...@fuentelibre.org wrote: Hi dear Sugar developers. We have participated in the deployment in Peru of Sugar 0.94 (classic) for XO1 and XO1.5. It will be ongoing in 2014 and hopefully we will tighten the feedback circle and work closer with upstream (master). Now we as a team are working in Colombia with XO1.75 and again, the issue of performance creeps in, and they are interested in downgrading to Sugar 0.94 (classic). that way madness lies, if we stay without updating, we break cohesion. It would be best if we could all just work on the same basis. For us to base our work on 0.101+ (new) Sugar, we have to make sure we have solved the performance issues plaguing (new) Sugar and/or OLPC/OS 13.x. Which OLPC version are you comparing with? In the rest of the answer I'll call that X.x :) For this I need your advice. *How do I setup an identical environment for (classic) 0.94 Sugar and (new) 0.101+ Sugar? Can I use sugar-build for this, or something else...?* On which hardware and on which distribution? Anyway it's probably not going to be trivial. So let me suggest an easier first step. You could test 0.94 activities on the top of OLPC 13.x. If they perform the same as OLPC X.x then we know the issue is the gtk3 toolkit (no change was made to the gtk2 toolkit). If they are bad as stock 13.x activities, then we will know it's something in the system. If it's something in the middle we will have to come up with a more complicated strategy. But I think the data we get from this initial testing will be useful to figure out that strategy. *How do I profile the session (CPU usage, memory consumption, timing)? * For memory I would try this https://github.com/pixelb/ps_mem For CPU top should be fine, but it depends what exactly you want to test. For timing I usually just print out time.time intervals from the code :) * Do we have some automated GUI testing? Can I make some?* See sugar-build/build/tests/shell.py, you could use something like that to measure startup time I suppose. Anyway you can use the same kind of code to click around in activities UI etc. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Performance testing
Something I forgot to mention is that when testing activity startup you really need to clean the kernel memory cache before each run, or you will get inconsistent data. sudo sh -c echo 3 /proc/sys/vm/drop_caches On 9 March 2014 18:46, Daniel Narvaez dwnarv...@gmail.com wrote: On 9 March 2014 17:53, Sebastian Silva sebast...@fuentelibre.org wrote: Hi dear Sugar developers. We have participated in the deployment in Peru of Sugar 0.94 (classic) for XO1 and XO1.5. It will be ongoing in 2014 and hopefully we will tighten the feedback circle and work closer with upstream (master). Now we as a team are working in Colombia with XO1.75 and again, the issue of performance creeps in, and they are interested in downgrading to Sugar 0.94 (classic). that way madness lies, if we stay without updating, we break cohesion. It would be best if we could all just work on the same basis. For us to base our work on 0.101+ (new) Sugar, we have to make sure we have solved the performance issues plaguing (new) Sugar and/or OLPC/OS 13.x. Which OLPC version are you comparing with? In the rest of the answer I'll call that X.x :) For this I need your advice. *How do I setup an identical environment for (classic) 0.94 Sugar and (new) 0.101+ Sugar? Can I use sugar-build for this, or something else...?* On which hardware and on which distribution? Anyway it's probably not going to be trivial. So let me suggest an easier first step. You could test 0.94 activities on the top of OLPC 13.x. If they perform the same as OLPC X.x then we know the issue is the gtk3 toolkit (no change was made to the gtk2 toolkit). If they are bad as stock 13.x activities, then we will know it's something in the system. If it's something in the middle we will have to come up with a more complicated strategy. But I think the data we get from this initial testing will be useful to figure out that strategy. *How do I profile the session (CPU usage, memory consumption, timing)? * For memory I would try this https://github.com/pixelb/ps_mem For CPU top should be fine, but it depends what exactly you want to test. For timing I usually just print out time.time intervals from the code :) * Do we have some automated GUI testing? Can I make some?* See sugar-build/build/tests/shell.py, you could use something like that to measure startup time I suppose. Anyway you can use the same kind of code to click around in activities UI etc. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
this release marks our feature freeze for 0.102. Now let's focus on bug fixing! It would be useful to see release notes for each release so as to know what's changed, added and needs to be tested rather than a tarball list dumped to the list. I agree, but at the moment I have no time to do that myself. We could have a page in sugar-docs and reviewers would fill in items that are release note worthy when pushing pull requests. Sort of worried about raising the review barrier though. What do people think about that? Why can't it be auto generated using git and then you just have to make sure there's decent commit messages. Ultimately I think good commit messages should be compulsory because it tells you why changes were made. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
The commit messages for our changes to Sugar core tend to be pretty decent. If we grab those and put them into a wiki page, then we could manually edit them into something more friendly to read once per release cycle. I volunteer to do the editing. Catching changes to the core activities is a bit more haphazard. But once the page is set up, we can put a call out to the maintainers in Fructose (a relatively small group). -walter On Sun, Mar 9, 2014 at 3:33 PM, Peter Robinson pbrobin...@gmail.com wrote: this release marks our feature freeze for 0.102. Now let's focus on bug fixing! It would be useful to see release notes for each release so as to know what's changed, added and needs to be tested rather than a tarball list dumped to the list. I agree, but at the moment I have no time to do that myself. We could have a page in sugar-docs and reviewers would fill in items that are release note worthy when pushing pull requests. Sort of worried about raising the review barrier though. What do people think about that? Why can't it be auto generated using git and then you just have to make sure there's decent commit messages. Ultimately I think good commit messages should be compulsory because it tells you why changes were made. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
Just as a rough sketch of what pulling the commit messages would look like, I've set up http://wiki.sugarlabs.org/go/0.102/Notes -walter On Sun, Mar 9, 2014 at 4:37 PM, Walter Bender walter.ben...@gmail.com wrote: The commit messages for our changes to Sugar core tend to be pretty decent. If we grab those and put them into a wiki page, then we could manually edit them into something more friendly to read once per release cycle. I volunteer to do the editing. Catching changes to the core activities is a bit more haphazard. But once the page is set up, we can put a call out to the maintainers in Fructose (a relatively small group). -walter On Sun, Mar 9, 2014 at 3:33 PM, Peter Robinson pbrobin...@gmail.com wrote: this release marks our feature freeze for 0.102. Now let's focus on bug fixing! It would be useful to see release notes for each release so as to know what's changed, added and needs to be tested rather than a tarball list dumped to the list. I agree, but at the moment I have no time to do that myself. We could have a page in sugar-docs and reviewers would fill in items that are release note worthy when pushing pull requests. Sort of worried about raising the review barrier though. What do people think about that? Why can't it be auto generated using git and then you just have to make sure there's decent commit messages. Ultimately I think good commit messages should be compulsory because it tells you why changes were made. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Patch for Develop
Thanks Sebastian, will include it in the next version. Gonzalo On Sun, Mar 9, 2014 at 1:18 AM, Sebastian Silva sebast...@fuentelibre.orgwrote: Hi Gonzalo, Thank you for breathing new life into Develop activity. In order to try it out in sugar-build I did this little patch. Maybe it can be merged. Regards, Sebastian -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-build on archlinux without broot
Then issues ocurred with gwebsockets. It persistently tried to use python3.3, my system's default, instead of python2.7. Finally I found the culprit, in ./out/sandbox/install/lib/python2.7/site-packages/osbuild/build.py I replaced in line 190 one instance of python for python2.7 and it worked after that. Finally when building sugar-base I had to set up the environment variable PYTHON=/usr/bin/python2.7 in order for it to build. Also, when building sugar, I had to manually create the directory ./out/install/etc/gconf/ or it would fail to install Maybe you can solve this issues just creating symlinks like in fedora: [gonzalo@localhost develop-activity]$ ls -l /bin/python lrwxrwxrwx. 1 root root 7 Jan 9 2013 /bin/python - python2 [gonzalo@localhost develop-activity]$ ls -l /bin/python2 lrwxrwxrwx. 1 root root 9 Jan 9 2013 /bin/python2 - python2.7 Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
On 9 March 2014 20:33, Peter Robinson pbrobin...@gmail.com wrote: this release marks our feature freeze for 0.102. Now let's focus on bug fixing! It would be useful to see release notes for each release so as to know what's changed, added and needs to be tested rather than a tarball list dumped to the list. I agree, but at the moment I have no time to do that myself. We could have a page in sugar-docs and reviewers would fill in items that are release note worthy when pushing pull requests. Sort of worried about raising the review barrier though. What do people think about that? Why can't it be auto generated using git and then you just have to make sure there's decent commit messages. Ultimately I think good commit messages should be compulsory because it tells you why changes were made. In my experience good commits message and good commits split doesn't necessarily make a good list of changes for release notes. They target different audiences. That said it's certainly better than nothing and it might not be too bad given how usually the sugar log looks. I suppose we could just link to github compare (I wonder if there is a way to hide the code diff, it seems to be hidden automatically when there are a lot of commits) https://github.com/sugarlabs/sugar/compare/v0.101.3...v0.101.4 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
On 9 March 2014 21:37, Walter Bender walter.ben...@gmail.com wrote: The commit messages for our changes to Sugar core tend to be pretty decent. If we grab those and put them into a wiki page, then we could manually edit them into something more friendly to read once per release cycle. I volunteer to do the editing. You mean editing when releasing a stable version or also for each unstable version? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-build on archlinux without broot
On 10 March 2014 00:07, Gonzalo Odiard godi...@sugarlabs.org wrote: Then issues ocurred with gwebsockets. It persistently tried to use python3.3, my system's default, instead of python2.7. Finally I found the culprit, in ./out/sandbox/install/lib/python2.7/site-packages/osbuild/build.py I replaced in line 190 one instance of python for python2.7 and it worked after that. Finally when building sugar-base I had to set up the environment variable PYTHON=/usr/bin/python2.7 in order for it to build. Also, when building sugar, I had to manually create the directory ./out/install/etc/gconf/ or it would fail to install Maybe you can solve this issues just creating symlinks like in fedora: [gonzalo@localhost develop-activity]$ ls -l /bin/python lrwxrwxrwx. 1 root root 7 Jan 9 2013 /bin/python - python2 [gonzalo@localhost develop-activity]$ ls -l /bin/python2 lrwxrwxrwx. 1 root root 9 Jan 9 2013 /bin/python2 - python2.7 Gonzalo I think archlinux has those symlinks already, but it also has python which is reallly python 3. Now honestly I think that's a very bad decision archlinux made (and the reason I'm not using it anymore, fwiw, it's a real pain if you are compiling stuff a lot). But it is compatible with best practices suggested by the python documentation. So I think we should follow those practices in sugar-base (i.e. explicitly require python2), which will take care of this issue. We are already doing that in the gtk3 modules. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
In the end, we need a summary to the end public, we can prepare it like in the past, based in the commit messages. Gonzalo On Sun, Mar 9, 2014 at 8:41 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 9 March 2014 22:31, Gaurav Parida gparid...@gmail.com wrote: Keeping the commit messages, will help in knowing the changes done in a release. The documentation aspect of a new release will be easily handled. +1 for the idea. On Mon, Mar 10, 2014 at 2:35 AM, Walter Bender walter.ben...@gmail.comwrote: Just as a rough sketch of what pulling the commit messages would look like, I've set up http://wiki.sugarlabs.org/go/0.102/Notes -walter The mockups look good. It would be great if each one them also has the link to the merge request. In my opinion, the commit messages will be more understandable, if we put some guidelines for them. like preappend the commit messages with with [Feature] / [Bug Fix #] / [Defect] / [Upgrade] from now on... We could include in the release notes only the subject of commits tagged like that. That would avoid to have too many irrelevant implementation details in the notes and also to simply omit commits that are not relevant (like refactorings etc). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-build on archlinux without broot
I see.. :/ Gonzalo On Sun, Mar 9, 2014 at 8:54 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 10 March 2014 00:46, Daniel Narvaez dwnarv...@gmail.com wrote: On 10 March 2014 00:07, Gonzalo Odiard godi...@sugarlabs.org wrote: Then issues ocurred with gwebsockets. It persistently tried to use python3.3, my system's default, instead of python2.7. Finally I found the culprit, in ./out/sandbox/install/lib/python2.7/site-packages/osbuild/build.py I replaced in line 190 one instance of python for python2.7 and it worked after that. Finally when building sugar-base I had to set up the environment variable PYTHON=/usr/bin/python2.7 in order for it to build. Also, when building sugar, I had to manually create the directory ./out/install/etc/gconf/ or it would fail to install Maybe you can solve this issues just creating symlinks like in fedora: [gonzalo@localhost develop-activity]$ ls -l /bin/python lrwxrwxrwx. 1 root root 7 Jan 9 2013 /bin/python - python2 [gonzalo@localhost develop-activity]$ ls -l /bin/python2 lrwxrwxrwx. 1 root root 9 Jan 9 2013 /bin/python2 - python2.7 Gonzalo I think archlinux has those symlinks already, but it also has python which is reallly python 3. Now honestly I think that's a very bad decision archlinux made (and the reason I'm not using it anymore, fwiw, it's a real pain if you are compiling stuff a lot). But it is compatible with best practices suggested by the python documentation. So I think we should follow those practices in sugar-base (i.e. explicitly require python2), which will take care of this issue. We are already doing that in the gtk3 modules. Oh missed the /bin/python - python2 suggestion. That would break archlinux stuff which assumes python is python3. -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
The thing is, I don't have time to do that manually for each unstable release. We either need a volunteer to do it or a way to generate it automatically from the log (which was the goal of my suggestion). On 10 March 2014 00:56, Gonzalo Odiard godi...@sugarlabs.org wrote: In the end, we need a summary to the end public, we can prepare it like in the past, based in the commit messages. Gonzalo On Sun, Mar 9, 2014 at 8:41 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On 9 March 2014 22:31, Gaurav Parida gparid...@gmail.com wrote: Keeping the commit messages, will help in knowing the changes done in a release. The documentation aspect of a new release will be easily handled. +1 for the idea. On Mon, Mar 10, 2014 at 2:35 AM, Walter Bender walter.ben...@gmail.comwrote: Just as a rough sketch of what pulling the commit messages would look like, I've set up http://wiki.sugarlabs.org/go/0.102/Notes -walter The mockups look good. It would be great if each one them also has the link to the merge request. In my opinion, the commit messages will be more understandable, if we put some guidelines for them. like preappend the commit messages with with [Feature] / [Bug Fix #] / [Defect] / [Upgrade] from now on... We could include in the release notes only the subject of commits tagged like that. That would avoid to have too many irrelevant implementation details in the notes and also to simply omit commits that are not relevant (like refactorings etc). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
I am not thinking in doing it for every unstable release, just for 0.102. I already did it for 0.100, I can volunteer to do it again in 0.102 Gonzalo On Sun, Mar 9, 2014 at 8:58 PM, Daniel Narvaez dwnarv...@gmail.com wrote: The thing is, I don't have time to do that manually for each unstable release. We either need a volunteer to do it or a way to generate it automatically from the log (which was the goal of my suggestion). On 10 March 2014 00:56, Gonzalo Odiard godi...@sugarlabs.org wrote: In the end, we need a summary to the end public, we can prepare it like in the past, based in the commit messages. Gonzalo On Sun, Mar 9, 2014 at 8:41 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On 9 March 2014 22:31, Gaurav Parida gparid...@gmail.com wrote: Keeping the commit messages, will help in knowing the changes done in a release. The documentation aspect of a new release will be easily handled. +1 for the idea. On Mon, Mar 10, 2014 at 2:35 AM, Walter Bender walter.ben...@gmail.com wrote: Just as a rough sketch of what pulling the commit messages would look like, I've set up http://wiki.sugarlabs.org/go/0.102/Notes -walter The mockups look good. It would be great if each one them also has the link to the merge request. In my opinion, the commit messages will be more understandable, if we put some guidelines for them. like preappend the commit messages with with [Feature] / [Bug Fix #] / [Defect] / [Upgrade] from now on... We could include in the release notes only the subject of commits tagged like that. That would avoid to have too many irrelevant implementation details in the notes and also to simply omit commits that are not relevant (like refactorings etc). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
The discussion started because Peter would like to have release notes for unstable releases. (Though he might be content with those being just the git logs). On 10 March 2014 01:01, Gonzalo Odiard godi...@sugarlabs.org wrote: I am not thinking in doing it for every unstable release, just for 0.102. I already did it for 0.100, I can volunteer to do it again in 0.102 Gonzalo On Sun, Mar 9, 2014 at 8:58 PM, Daniel Narvaez dwnarv...@gmail.comwrote: The thing is, I don't have time to do that manually for each unstable release. We either need a volunteer to do it or a way to generate it automatically from the log (which was the goal of my suggestion). On 10 March 2014 00:56, Gonzalo Odiard godi...@sugarlabs.org wrote: In the end, we need a summary to the end public, we can prepare it like in the past, based in the commit messages. Gonzalo On Sun, Mar 9, 2014 at 8:41 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On 9 March 2014 22:31, Gaurav Parida gparid...@gmail.com wrote: Keeping the commit messages, will help in knowing the changes done in a release. The documentation aspect of a new release will be easily handled. +1 for the idea. On Mon, Mar 10, 2014 at 2:35 AM, Walter Bender walter.ben...@gmail.com wrote: Just as a rough sketch of what pulling the commit messages would look like, I've set up http://wiki.sugarlabs.org/go/0.102/Notes -walter The mockups look good. It would be great if each one them also has the link to the merge request. In my opinion, the commit messages will be more understandable, if we put some guidelines for them. like preappend the commit messages with with [Feature] / [Bug Fix #] / [Defect] / [Upgrade] from now on... We could include in the release notes only the subject of commits tagged like that. That would avoid to have too many irrelevant implementation details in the notes and also to simply omit commits that are not relevant (like refactorings etc). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
It didn't take me too long to pull together http://wiki.sugarlabs.org/go/0.102/Notes and I am happy to do the same again for the other unstable releases. We need to do some more work for the stable release as per Gonzalo's comments. -walter On Sun, Mar 9, 2014 at 8:04 PM, Daniel Narvaez dwnarv...@gmail.com wrote: The discussion started because Peter would like to have release notes for unstable releases. (Though he might be content with those being just the git logs). On 10 March 2014 01:01, Gonzalo Odiard godi...@sugarlabs.org wrote: I am not thinking in doing it for every unstable release, just for 0.102. I already did it for 0.100, I can volunteer to do it again in 0.102 Gonzalo On Sun, Mar 9, 2014 at 8:58 PM, Daniel Narvaez dwnarv...@gmail.com wrote: The thing is, I don't have time to do that manually for each unstable release. We either need a volunteer to do it or a way to generate it automatically from the log (which was the goal of my suggestion). On 10 March 2014 00:56, Gonzalo Odiard godi...@sugarlabs.org wrote: In the end, we need a summary to the end public, we can prepare it like in the past, based in the commit messages. Gonzalo On Sun, Mar 9, 2014 at 8:41 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 9 March 2014 22:31, Gaurav Parida gparid...@gmail.com wrote: Keeping the commit messages, will help in knowing the changes done in a release. The documentation aspect of a new release will be easily handled. +1 for the idea. On Mon, Mar 10, 2014 at 2:35 AM, Walter Bender walter.ben...@gmail.com wrote: Just as a rough sketch of what pulling the commit messages would look like, I've set up http://wiki.sugarlabs.org/go/0.102/Notes -walter The mockups look good. It would be great if each one them also has the link to the merge request. In my opinion, the commit messages will be more understandable, if we put some guidelines for them. like preappend the commit messages with with [Feature] / [Bug Fix #] / [Defect] / [Upgrade] from now on... We could include in the release notes only the subject of commits tagged like that. That would avoid to have too many irrelevant implementation details in the notes and also to simply omit commits that are not relevant (like refactorings etc). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
Great! So I'll let you know when 0.101.4 is tagged. On 10 March 2014 01:10, Walter Bender walter.ben...@gmail.com wrote: It didn't take me too long to pull together http://wiki.sugarlabs.org/go/0.102/Notes and I am happy to do the same again for the other unstable releases. We need to do some more work for the stable release as per Gonzalo's comments. -walter On Sun, Mar 9, 2014 at 8:04 PM, Daniel Narvaez dwnarv...@gmail.com wrote: The discussion started because Peter would like to have release notes for unstable releases. (Though he might be content with those being just the git logs). On 10 March 2014 01:01, Gonzalo Odiard godi...@sugarlabs.org wrote: I am not thinking in doing it for every unstable release, just for 0.102. I already did it for 0.100, I can volunteer to do it again in 0.102 Gonzalo On Sun, Mar 9, 2014 at 8:58 PM, Daniel Narvaez dwnarv...@gmail.com wrote: The thing is, I don't have time to do that manually for each unstable release. We either need a volunteer to do it or a way to generate it automatically from the log (which was the goal of my suggestion). On 10 March 2014 00:56, Gonzalo Odiard godi...@sugarlabs.org wrote: In the end, we need a summary to the end public, we can prepare it like in the past, based in the commit messages. Gonzalo On Sun, Mar 9, 2014 at 8:41 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 9 March 2014 22:31, Gaurav Parida gparid...@gmail.com wrote: Keeping the commit messages, will help in knowing the changes done in a release. The documentation aspect of a new release will be easily handled. +1 for the idea. On Mon, Mar 10, 2014 at 2:35 AM, Walter Bender walter.ben...@gmail.com wrote: Just as a rough sketch of what pulling the commit messages would look like, I've set up http://wiki.sugarlabs.org/go/0.102/Notes -walter The mockups look good. It would be great if each one them also has the link to the merge request. In my opinion, the commit messages will be more understandable, if we put some guidelines for them. like preappend the commit messages with with [Feature] / [Bug Fix #] / [Defect] / [Upgrade] from now on... We could include in the release notes only the subject of commits tagged like that. That would avoid to have too many irrelevant implementation details in the notes and also to simply omit commits that are not relevant (like refactorings etc). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-build on archlinux without broot
All Arch Linux users I met usually solve this problem when developing by using virtualenv. 2014-03-09 20:54 GMT-03:00 Daniel Narvaez dwnarv...@gmail.com: On 10 March 2014 00:46, Daniel Narvaez dwnarv...@gmail.com wrote: On 10 March 2014 00:07, Gonzalo Odiard godi...@sugarlabs.org wrote: Then issues ocurred with gwebsockets. It persistently tried to use python3.3, my system's default, instead of python2.7. Finally I found the culprit, in ./out/sandbox/install/lib/python2.7/site-packages/osbuild/build.py I replaced in line 190 one instance of python for python2.7 and it worked after that. Finally when building sugar-base I had to set up the environment variable PYTHON=/usr/bin/python2.7 in order for it to build. Also, when building sugar, I had to manually create the directory ./out/install/etc/gconf/ or it would fail to install Maybe you can solve this issues just creating symlinks like in fedora: [gonzalo@localhost develop-activity]$ ls -l /bin/python lrwxrwxrwx. 1 root root 7 Jan 9 2013 /bin/python - python2 [gonzalo@localhost develop-activity]$ ls -l /bin/python2 lrwxrwxrwx. 1 root root 9 Jan 9 2013 /bin/python2 - python2.7 Gonzalo I think archlinux has those symlinks already, but it also has python which is reallly python 3. Now honestly I think that's a very bad decision archlinux made (and the reason I'm not using it anymore, fwiw, it's a real pain if you are compiling stuff a lot). But it is compatible with best practices suggested by the python documentation. So I think we should follow those practices in sugar-base (i.e. explicitly require python2), which will take care of this issue. We are already doing that in the gtk3 modules. Oh missed the /bin/python - python2 suggestion. That would break archlinux stuff which assumes python is python3. ___ 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] Feature freeze
We just finished the review of the design issues the last week, and we agreed in the general points. I think we should make a effort to finalize the features already discussed, and not include anything more. Maybe we can discuss postpone feature freeze by one or two weeks more, but of course this would be something to decide as a community. Gonzalo On Sat, Mar 8, 2014 at 11:18 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I'm releasing 0.101.3 and we are now feature frozen. I marked the pull requests that introduce new features with a [Feature] prefix. I considered closing them to unclutter the queue but then I thought it would be better to keep them around to make sure they are not forgotten. If new pull request which introduces features are posted let's mark them in a same way (for new contributors let's also explain why we are doing that). Time to kill bugs! -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Subject: Re: Regarding JS collaboration project
How would work the collaboration if no schoolserver is present? node.js would be a sugar dependency? Gonzalo On Sun, Mar 9, 2014 at 12:23 PM, Lionel Laské lio...@olpc-france.orgwrote: Nice sum up Prasoon ! +1 for the node.js server back office. It will be easy to install it on a XSCE server and I'm starting to include a node.js part to my Sugarizer Server so it could work too on Sugarizer. Just as reminder, Suraj and I worked some months ago on: - A feature list of what is need for collaboration in Sugar [1] - A very basic implementation of websocket presence API on node.js [2]. Unfortunately none of us had time to work more on this. But it could be a good start point for the collaboration project. Lionel [1] https://docs.google.com/document/d/1FZRv0gSV--5Y4dvV9C9dk9K-LT7kEQEwQmX_xVX9H-s/edit [2] https://github.com/surajgillespie/SugarPresenceAPI Hi Sam. Sorry for the late response but I was occupied with academics. Anyway, I need to bother you again with some questions. So, I went through the thread by Emil Dudev and read the arguments he made in favour of not using the mozilla node server and using telepathy instead. To that, dnarvaez said that using the node server might be a better idea since the current protocol is very unstable. Now, I am somewhat familiar with sugar codebase but certainly not enough to actually discuss the merits or demerits of either of these approaches (although personally, I like better the idea of all communication happening over websocket via a node server). So, the final decision on which approach to take will be in the hands of those more experienced. But as I said before, I would prefer it if we use the websocket protocol to have this kind of architecture: |Sugar Web Activity| - |Sugar Shell|\ \ websocket \ |Node Server|/ / / |Sugar Web Activity| - |Sugar Shell| instead of the usual telepathy based communication. This I would like because: 1. We'll be able to use the mozilla server with modifications as needed. 2. We'll be able to use the **huge** node.js ecosystem for realtime communication in any way we want! And, websocket is very versatile - we can send pretty much any binary data over the network. Also, I've worked with node before and found the communication to be quite reliable (which it is not with the current XMPP based protocol, if I understood dnarvaez correctly). That said, I've only tested out my node based work with a handful of people, so... The only downside is the need to have a node server running. For the case when there is not internet connectivity, I think we can make a set of scripts that can be called to run a node server on the one of the machines, say that of the teacher, and all others will connect to it. And of course, this process nee ds to be simple. Anyway, it just seems right to me to augment JS activities with a JS based collaboration framework. But of course, I don't really know the details all too well to be making the decision here. So, can you please comment on this? Once this decision is made, I can start working on my application. Thanks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- next part -- An HTML attachment was scrubbed... URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140309/2ac4/attachment.html -- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel End of Sugar-devel Digest, Vol 65, Issue 32 *** ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-build on archlinux without broot
Oh interesting! osbuild is actually using a virtualenv. I suspect it doesn't work because we are not activating it but just running the python executable in the virtualenv. So osbuild is using the virtualenv python, but the child processes are not. Now if I could remember why we are not activating the virtualenv... :) Still I think the cleanest solution is to make sugar-base require python2 explicitly. It will also work if you are building archlinux (or gentoo) packages. On 10 March 2014 01:14, S. Daniel Francis fran...@sugarlabs.org wrote: All Arch Linux users I met usually solve this problem when developing by using virtualenv. 2014-03-09 20:54 GMT-03:00 Daniel Narvaez dwnarv...@gmail.com: On 10 March 2014 00:46, Daniel Narvaez dwnarv...@gmail.com wrote: On 10 March 2014 00:07, Gonzalo Odiard godi...@sugarlabs.org wrote: Then issues ocurred with gwebsockets. It persistently tried to use python3.3, my system's default, instead of python2.7. Finally I found the culprit, in ./out/sandbox/install/lib/python2.7/site-packages/osbuild/build.py I replaced in line 190 one instance of python for python2.7 and it worked after that. Finally when building sugar-base I had to set up the environment variable PYTHON=/usr/bin/python2.7 in order for it to build. Also, when building sugar, I had to manually create the directory ./out/install/etc/gconf/ or it would fail to install Maybe you can solve this issues just creating symlinks like in fedora: [gonzalo@localhost develop-activity]$ ls -l /bin/python lrwxrwxrwx. 1 root root 7 Jan 9 2013 /bin/python - python2 [gonzalo@localhost develop-activity]$ ls -l /bin/python2 lrwxrwxrwx. 1 root root 9 Jan 9 2013 /bin/python2 - python2.7 Gonzalo I think archlinux has those symlinks already, but it also has python which is reallly python 3. Now honestly I think that's a very bad decision archlinux made (and the reason I'm not using it anymore, fwiw, it's a real pain if you are compiling stuff a lot). But it is compatible with best practices suggested by the python documentation. So I think we should follow those practices in sugar-base (i.e. explicitly require python2), which will take care of this issue. We are already doing that in the gtk3 modules. Oh missed the /bin/python - python2 suggestion. That would break archlinux stuff which assumes python is python3. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Feature freeze
Feel free to propose delaying feature freeze. The release was already a week late, if we want more time to work on features, I tend to think the final release should be pushed off accordingly too. On 10 March 2014 01:21, Gonzalo Odiard godi...@sugarlabs.org wrote: We just finished the review of the design issues the last week, and we agreed in the general points. I think we should make a effort to finalize the features already discussed, and not include anything more. Maybe we can discuss postpone feature freeze by one or two weeks more, but of course this would be something to decide as a community. Gonzalo On Sat, Mar 8, 2014 at 11:18 AM, Daniel Narvaez dwnarv...@gmail.comwrote: Hello, I'm releasing 0.101.3 and we are now feature frozen. I marked the pull requests that introduce new features with a [Feature] prefix. I considered closing them to unclutter the queue but then I thought it would be better to keep them around to make sure they are not forgotten. If new pull request which introduces features are posted let's mark them in a same way (for new contributors let's also explain why we are doing that). Time to kill bugs! -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Feature freeze
For what it's worth it would be a -1 from me. I would be fine to delay a bit to fix important bugs, but not to add more features, it seems to go completely against the rationale of time based releases. But that's just my opinion. On 10 March 2014 01:34, Daniel Narvaez dwnarv...@gmail.com wrote: Feel free to propose delaying feature freeze. The release was already a week late, if we want more time to work on features, I tend to think the final release should be pushed off accordingly too. On 10 March 2014 01:21, Gonzalo Odiard godi...@sugarlabs.org wrote: We just finished the review of the design issues the last week, and we agreed in the general points. I think we should make a effort to finalize the features already discussed, and not include anything more. Maybe we can discuss postpone feature freeze by one or two weeks more, but of course this would be something to decide as a community. Gonzalo On Sat, Mar 8, 2014 at 11:18 AM, Daniel Narvaez dwnarv...@gmail.comwrote: Hello, I'm releasing 0.101.3 and we are now feature frozen. I marked the pull requests that introduce new features with a [Feature] prefix. I considered closing them to unclutter the queue but then I thought it would be better to keep them around to make sure they are not forgotten. If new pull request which introduces features are posted let's mark them in a same way (for new contributors let's also explain why we are doing that). Time to kill bugs! -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Subject: Re: Regarding JS collaboration project
The only downside is the need to have a node server running. For the case when there is not internet connectivity, I think we can make a set of scripts that can be called to run a node server on the one of the machines, say that of the teacher, and all others will connect to it. And of course, this process needs to be simple. This solution do not solve one of the cases where Sugar collaboration should work, two kids under a tree [1], where the kids don't have any infrastructure. A simple pyhton server can be run in the activity. I did something similar, using websockets in the javascript part in the JournalShare[2] activity, tunneling the http trafic using telepathy, and works pretty well. Gonzalo [1] http://wiki.laptop.org/go/Collaboration_Setup [2] http://activities.sugarlabs.org/en-US/sugar/addon/4656 https://git.sugarlabs.org/journalshare On Sun, Mar 9, 2014 at 9:27 PM, Gonzalo Odiard godi...@sugarlabs.orgwrote: How would work the collaboration if no schoolserver is present? node.js would be a sugar dependency? Gonzalo On Sun, Mar 9, 2014 at 12:23 PM, Lionel Laské lio...@olpc-france.orgwrote: Nice sum up Prasoon ! +1 for the node.js server back office. It will be easy to install it on a XSCE server and I'm starting to include a node.js part to my Sugarizer Server so it could work too on Sugarizer. Just as reminder, Suraj and I worked some months ago on: - A feature list of what is need for collaboration in Sugar [1] - A very basic implementation of websocket presence API on node.js [2]. Unfortunately none of us had time to work more on this. But it could be a good start point for the collaboration project. Lionel [1] https://docs.google.com/document/d/1FZRv0gSV--5Y4dvV9C9dk9K-LT7kEQEwQmX_xVX9H-s/edit [2] https://github.com/surajgillespie/SugarPresenceAPI Hi Sam. Sorry for the late response but I was occupied with academics. Anyway, I need to bother you again with some questions. So, I went through the thread by Emil Dudev and read the arguments he made in favour of not using the mozilla node server and using telepathy instead. To that, dnarvaez said that using the node server might be a better idea since the current protocol is very unstable. Now, I am somewhat familiar with sugar codebase but certainly not enough to actually discuss the merits or demerits of either of these approaches (although personally, I like better the idea of all communication happening over websocket via a node server). So, the final decision on which approach to take will be in the hands of those more experienced. But as I said before, I would prefer it if we use the websocket protocol to have this kind of architecture: |Sugar Web Activity| - |Sugar Shell|\ \ websocket \ |Node Server|/ / / |Sugar Web Activity| - |Sugar Shell| instead of the usual telepathy based communication. This I would like because: 1. We'll be able to use the mozilla server with modifications as needed. 2. We'll be able to use the **huge** node.js ecosystem for realtime communication in any way we want! And, websocket is very versatile - we can send pretty much any binary data over the network. Also, I've worked with node before and found the communication to be quite reliable (which it is not with the current XMPP based protocol, if I understood dnarvaez correctly). That said, I've only tested out my node based work with a handful of people, so... The only downside is the need to have a node server running. For the case when there is not internet connectivity, I think we can make a set of scripts that can be called to run a node server on the one of the machines, say that of the teacher, and all others will connect to it. And of course, this process nee ds to be simple. Anyway, it just seems right to me to augment JS activities with a JS based collaboration framework. But of course, I don't really know the details all too well to be making the decision here. So, can you please comment on this? Once this decision is made, I can start working on my application. Thanks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- next part -- An HTML attachment was scrubbed... URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140309/2ac4/attachment.html -- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel End of Sugar-devel Digest, Vol 65, Issue 32 *** ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs
Re: [Sugar-devel] Feature freeze
On Sun, Mar 9, 2014 at 9:40 PM, Daniel Narvaez dwnarv...@gmail.com wrote: For what it's worth it would be a -1 from me. I would be fine to delay a bit to fix important bugs, but not to add more features, it seems to go completely against the rationale of time based releases. But that's just my opinion. Would be against the time based release, if the propose would be postpone it indefinitely. Many projects working with time based releases, like libreoffice, gnome or fedora adjust the schedules if they consider worth it. Gonzalo On 10 March 2014 01:34, Daniel Narvaez dwnarv...@gmail.com wrote: Feel free to propose delaying feature freeze. The release was already a week late, if we want more time to work on features, I tend to think the final release should be pushed off accordingly too. On 10 March 2014 01:21, Gonzalo Odiard godi...@sugarlabs.org wrote: We just finished the review of the design issues the last week, and we agreed in the general points. I think we should make a effort to finalize the features already discussed, and not include anything more. Maybe we can discuss postpone feature freeze by one or two weeks more, but of course this would be something to decide as a community. Gonzalo On Sat, Mar 8, 2014 at 11:18 AM, Daniel Narvaez dwnarv...@gmail.comwrote: Hello, I'm releasing 0.101.3 and we are now feature frozen. I marked the pull requests that introduce new features with a [Feature] prefix. I considered closing them to unclutter the queue but then I thought it would be better to keep them around to make sure they are not forgotten. If new pull request which introduces features are posted let's mark them in a same way (for new contributors let's also explain why we are doing that). Time to kill bugs! -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Feature freeze
On 10 March 2014 01:48, Gonzalo Odiard godi...@sugarlabs.org wrote: On Sun, Mar 9, 2014 at 9:40 PM, Daniel Narvaez dwnarv...@gmail.comwrote: For what it's worth it would be a -1 from me. I would be fine to delay a bit to fix important bugs, but not to add more features, it seems to go completely against the rationale of time based releases. But that's just my opinion. Would be against the time based release, if the propose would be postpone it indefinitely. I disagree. From https://wiki.gnome.org/ReleasePlanning/TimeBased -- Although we agree on rough aims for each major release, and attempt to achieve those aims, GNOME releases are time-based rather than feature-based. A roughly 6-month release cycle allows us to coordinate development of the features that have actually been implemented, allowing us to maintain the quality of the overall release without delaying everything because of one or two features. If a feature is not ready in time then the developers must not wait long to put it in the next major release. We have found that this encourages both high quality and rapid development compared to feature-based release schedules. -- IMO delaying feature freeze is very clearly against that definition, in many ways. Many projects working with time based releases, like libreoffice, gnome or fedora adjust the schedules if they consider worth it. I honestly don't remember any of these projects making a decision to delay *feature* freeze two weeks after the deadline. I could be wrong of course, I have not followed every single releases of them. More importantly, even if they did, it wouldn't mean their decision was consistent with the time based release schedule rationale. Sometimes it's worth to make compromises. To articulate my point a bit more 1 Delaying feature freeze after the deadline is obviously against time based release definition and rationale. 2 I don't see anything special with the current situation that would suggest we should compromise on our time based approach. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-build on archlinux without broot
El 09/03/14 06:32, Daniel Narvaez escribió: Also, when building sugar, I had to manually create the directory ./out/install/etc/gconf/ or it would fail to install Can I see the output? It seems like something we should fix. Sure, I reproduced it easy enough. Thanks for the feedback. BTW Sorry to hear python2python3 issue moved you away from Arch. I am quite fond of the XO 1.75 I have with Arch thanks to you. What are you using now? Here's the log: [osbuild sugar-build]$ build sugar * Building sugar Command failed: make install Making install in bin make[1]: Entering directory '/home/icarito/Proyectos/sugar-build/sugar/bin' make[2]: Entering directory '/home/icarito/Proyectos/sugar-build/sugar/bin' /usr/bin/mkdir -p '/home/icarito/Proyectos/sugar-build/build/out/install/bin' /usr/bin/install -c sugar sugar-control-panel sugar-install-bundle sugar-launch '/home/icarito/Proyectos/sugar-build/build/out/install/bin' make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/home/icarito/Proyectos/sugar-build/sugar/bin' make[1]: Leaving directory '/home/icarito/Proyectos/sugar-build/sugar/bin' Making install in data make[1]: Entering directory '/home/icarito/Proyectos/sugar-build/sugar/data' Making install in icons make[2]: Entering directory '/home/icarito/Proyectos/sugar-build/sugar/data/icons' make[3]: Entering directory '/home/icarito/Proyectos/sugar-build/sugar/data/icons' make[3]: Nothing to be done for 'install-exec-am'. /usr/bin/mkdir -p '/home/icarito/Proyectos/sugar-build/build/out/install/share/sugar/data/icons' /usr/bin/install -c -m 644 module-about_me.svg module-about_my_computer.svg module-date_and_time.svg module-frame.svg module-keyboard.svg module-language.svg module-modemconfiguration.svg module-network.svg module-power.svg module-updater.svg module-webaccount.svg '/home/icarito/Proyectos/sugar-build/build/out/install/share/sugar/data/icons' make[3]: Leaving directory '/home/icarito/Proyectos/sugar-build/sugar/data/icons' make[2]: Leaving directory '/home/icarito/Proyectos/sugar-build/sugar/data/icons' make[2]: Entering directory '/home/icarito/Proyectos/sugar-build/sugar/data' make[3]: Entering directory '/home/icarito/Proyectos/sugar-build/sugar/data' make[3]: Nothing to be done for 'install-exec-am'. /usr/bin/mkdir -p '/home/icarito/Proyectos/sugar-build/build/out/install/share/GConf/gsettings' /usr/bin/install -c -m 644 sugar-schemas.convert '/home/icarito/Proyectos/sugar-build/build/out/install/share/GConf/gsettings' GCONF_CONFIG_SOURCE=xml:merged:/home/icarito/Proyectos/sugar-build/build/out/install/etc/gconf/gconf.xml.defaults /usr/bin/gconftool-2 --makefile-install-rule sugar.schemas 21 /dev/null (gconftool-2:3576): GConf-WARNING **: Failed to load source xml:merged:/home/icarito/Proyectos/sugar-build/build/out/install/etc/gconf/gconf.xml.defaults: Failed: Could not make directory `/home/icarito/Proyectos/sugar-build/build/out/install/etc/gconf/gconf.xml.defaults': No such file or directory ** GConf:ERROR:gconftool.c:969:main: assertion failed: (err == NULL) /bin/sh: line 1: 3576 Aborted (core dumped) GCONF_CONFIG_SOURCE=xml:merged:/home/icarito/Proyectos/sugar-build/build/out/install/etc/gconf/gconf.xml.defaults /usr/bin/gconftool-2 --makefile-install-rule sugar.schemas 21 /dev/null Makefile:839: recipe for target 'install-data-local' failed make[3]: Leaving directory '/home/icarito/Proyectos/sugar-build/sugar/data' Makefile:697: recipe for target 'install-am' failed make[3]: *** [install-data-local] Error 134 make[2]: *** [install-am] Error 2 make[2]: Leaving directory '/home/icarito/Proyectos/sugar-build/sugar/data' Makefile:536: recipe for target 'install-recursive' failed make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory '/home/icarito/Proyectos/sugar-build/sugar/data' make: *** [install-recursive] Error 1 Makefile:385: recipe for target 'install-recursive' failed [osbuild sugar-build]$ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] small patch for sugar-base to build on Arch
El 09/03/14 06:32, Daniel Narvaez escribió: Finally when building sugar-base I had to set up the environment variable PYTHON=/usr/bin/python2.7 in order for it to build. In sugar-toolkit-gtk3 we have PYTHON=python2 AM_PATH_PYTHON I don't remember why python2 instead of python2.7 but I think that was probably what the python documentation suggested.. I think we should do the same in sugar-base. I don't think I have write access to that repo, but if you make that change and test it in archlinux, consider it reviewed :) What is the the patch process nowadays? Merge request, pull request, patch to list... ? Regards, Sebastian From b708d2ce4308657fe30622e3fb1677ac686d07b7 Mon Sep 17 00:00:00 2001 From: Sebastian Silva sebast...@somosazucar.org Date: Sun, 9 Mar 2014 23:05:44 -0500 Subject: [PATCH] Follow best practices, explicitly require python2 (fixes ArchLinux). --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index cb7806d..2f4aca4 100644 --- a/configure.ac +++ b/configure.ac @@ -12,6 +12,7 @@ AC_PROG_LIBTOOL GNOME_COMPILE_WARNINGS(maximum) +PYTHON=python2 AM_PATH_PYTHON AM_CHECK_PYTHON_HEADERS(,[AC_MSG_ERROR(could not find Python headers)]) -- 1.9.0 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-build on archlinux without broot
El 09/03/14 06:32, Daniel Narvaez escribió: It's unsupported because it's unlikely to work out-of-the-box. But if anyone wants to try it on the latest version of a distro and do the kind of analysis you have been doing, then it's very useful feedback, because it's likely to find bugs, as we have been seeing here. I'd say it pretty much worked out of the box with little tinkering. I even set up the resolution to match a maximized window and it works great. Is it possible to setup a X11 Session to use my sugar-build's sugar? I really like to eat my own sugar ;-) Regards, Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
