Re: [Sugar-devel] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
El Fri, 07-05-2010 a las 11:17 -0400, Bernie Innocenti escribió: El Thu, 06-05-2010 a las 23:55 +0200, Sascha Silbe escribió: On Wed, May 05, 2010 at 01:49:23PM +0200, Tomeu Vizoso wrote: We are also scheduling some time to go through the review queue on Tuesday May 11th afternoon (UTC) and on Monday May 17th. Would be great if patch submitters could check that their patches have followed the current process and also that any volunteers pre-reviewed the code, some links follow: http://wiki.sugarlabs.org/go/0.88/Roadmap http://wiki.sugarlabs.org/go/Development_Team/Code_Review http://wiki.sugarlabs.org/go/Development_Team/Code_guidelines Does that mean that all patches that are destined for 0.88.x and were reviewed on the mailing list need to go through review again and thus need to have a ticket created for them, have the patch attached to the ticket and mailing list review comments cutpasted into the ticket? Patches posted to the list quickly received a lot of feedback, including testing and reviews. Unless this was the only way to get them ack'd by a maintainer, I'd rather not go back to bury all our patches into the bug tracker where they don't get nearly as much exposure. For informational purposes, it may make sense to also attach or link the patches to the ticket... this is orthogonal with we conduct our review process. Here's an example of a project that allows reviews to be done both in the bug tracker and on the mailing list: http://www.x.org/wiki/Development/Documentation/SubmittingPatches However, most patches go through the list these days. I asked on #xorg-devel if there were some rationale behind the switch, and these are the answers I got: bernie ajax, daniels, whot: was there a public discussion when xorg switched from doing reviews in bugzilla to doing them in the mailing list? remi|work bernie, it was more or less happening that way already, since git makes it so easy to send patches via email ajax probably in the notes about whichever xdc that was where we talked about it... alanc I'm not sure there was a lot more analysis beyond this is what the Linux kernel process is, so this is the way git was designed to work and the process a lot of the same developers already have to deal with for DRI, and it works there, while we clearly aren't reviewing the patches in bugzilla that get ignored there for years And also: dottedmag bernie: full bugmail log is usually read by much smaller amount of developers than the development mailing list, this seems to be a critical distintction. antrik bernie: simple answer is that anything that requires even the slightiest extra work considerably reduces the chance anyone will take the 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] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
El Fri, 07-05-2010 a las 16:43 +, Aleksey Lim escribió: My only concern about mailing list scheme is that I as component maintainer will have to setup my mail client to effectively track patches that should go to particular release e.g. patches to current dev branch, patches to backport to some of released branches. It is easy w/ bugs.sl.o since there are special fields. We can provide such useful info in email posts but it should be handled somehow in various email clients. Not sure how this issue is handled in projects like xorg or kernel, at the end we can ask patch submitters to create a ticket if they want their patches to be included to particular release or even better, in git post commit scripts, update/create appropriate ticket. In kernel land, when someone wants their patch to be applied to the stable series they just Cc the maintainer of the stable series when sending the patch to lkml. Then, each subsystem maintainer has their own favorite ways to manage incoming patches. Linus said once that he just presses one key in mutt to save each patch he likes to a directory to_apply that he later examines. Andrew Morton and others use more advanced patch queue management tools such as Guilt and StGit: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/man/ http://www.procode.org/stgit/ Personally, I use a hierarchy of four directories to remember outstanding patches to be sent to various upstream projects: http://people.sugarlabs.org/bernie/patches/ We could also take the habit to mark patches in the subjects with tags such as [0.84] [0.86]. Hopefully, the current mess of 3 or 4 versions of Sugar to be supported in parallel is only transient: if we're successful in reconciling deployments with upstream, there should be only one version of Sugar in maintenance mode and one under active development. -- // 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] [ANNOUNCE] Tarballs for release 0.88.1 due for May 17
El Fri, 07-05-2010 a las 16:34 -0300, Andrés Ambrois escribió: * some is seeing commit in `git log` and wants to see discussion thread in existed scheme, every (in ideal) commit should have ticket number In the kernel, I usually search for lkml few words from the comment. You could even click I'm feeling lucky most of the times. Traceability of patches in the absence of a bug tracker is really a non-issue even for projects a lot bigger and more mature than Sugar. Seems like this was design to help with some of these worries: http://ozlabs.org/~jk/projects/patchwork/ You can see it in action at http://patchwork.kernel.org. +1 to synchronizing Trac with the ML and vice versa. We can try install it and see what we can get out of it. If nobody else volunteers to do it, I'll give it a shot this w/e. -- // 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] Maintaining Pippy
Hello Brian, are you still interested in maintaining Pippy? If not, would it be ok with you to pass it to Anish, who has been working on it lately? -- // 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] Maintaining Pippy
El Thu, 06-05-2010 a las 18:46 -0400, Brian Jordan escribió: That sounds fine, I haven't been developing on it for a while. Anish -- let me know if you need any help. I'll make Anish the owner and keep you as a committer in case you want to work on it in the future. Thank you very much for maintaining Pippy until now, btw. -- // 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] [PATCH] Don't crash on invalid favoriteslayout settings
This could happen if the user upgrades Sugar to a new version which
doesn't support the old layout.
Signed-off-by: Bernie Innocenti ber...@codewiz.org
---
src/jarabe/desktop/favoritesview.py |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/jarabe/desktop/favoritesview.py
b/src/jarabe/desktop/favoritesview.py
index 4a84f08..17898f2 100644
--- a/src/jarabe/desktop/favoritesview.py
+++ b/src/jarabe/desktop/favoritesview.py
@@ -697,6 +697,8 @@ class FavoritesSetting(object):
def __init__(self):
client = gconf.client_get_default()
self._layout = client.get_string(self._FAVORITES_KEY)
+if not LAYOUT_MAP.has_key(self._layout):
+self._layout = favoriteslayout.RingLayout.key
logging.debug('FavoritesSetting layout %r' % (self._layout))
self._mode = None
--
1.7.0.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH 1/2] This fixes part of http://bugs.sugarlabs.org/ticket/1876 .
To reclaim space in case of a crash, we also need to delete temporary files at startup time. The rest of the bug is addressed by a separate patch in sugar-toolkit. Signed-off-by: Bernie Innocenti ber...@codewiz.org --- bin/sugar.in |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/bin/sugar.in b/bin/sugar.in index b9f467c..4a5e523 100644 --- a/bin/sugar.in +++ b/bin/sugar.in @@ -19,4 +19,7 @@ fi matchbox-window-manager -use_titlebar no -theme sugar \ -kbdconfig @prefix@/share/sugar/data/kbdconfig +# Remove temporary files. See http://bugs.sugarlabs.org/ticket/1876 +rm -rf $HOME/.sugar/default/data/* + exec sugar-session -- 1.7.0.1 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard navigability of the Sugar UI
El Sat, 01-05-2010 a las 01:05 -0300, Gonzalo Odiard escribió: I would like to work with 0.84 and port to 0.90. At Paraguay Educa we've been also focusing a lot on 0.84 lately. However, I'm starting to worry the history will repeat once again: many deployments have been patching 0.82 with fixes and new features that were never upstreamed, making the transition to 0.84 much more painful that it would have been otherwise. Now we're trying to minimize the gap between development versions of Sugar and what deployments ship. The good news is that there should be pretty good activity compatibility across 0.84, 0.86 and 0.88. In Paraguay we're about to start a new development cycle to rebase the Fedora 11 builds on Sugar 0.88. Much of the stabilization effort of the 0.84 cycle actually went into the OS and activities, so I'm quite optimist. I have read your bug #1969 and contacted a blind programmer to check the selected keys. We can write in the wiki a plan and work together with small patches. Great! Small patches have a higher potential to apply cleanly to both 0.84 and 0.90. -- // 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] Code Review process changes
everyone imho. What you want is called a paid employee! I've seen the same mistake made by a manager (who shall remain anonymous) who demanded that the community be working on fixing boring bugs in the order prioritized by the company objectives. Guess what happened? It was decided that the community was not being useful and development became even more closed. Community management simply doesn't work this way. At this time we have plenty of contributors posting useful patches and fixing bugs that they care about. Take it or loose it. I understand your frustration, but management roles are the hardest to fill in in free software projects. Luckily, community self organization is often a pretty good replacement. Please, let's not assume a rigid attitude of do the boring work or go away, because it's a guaranteed recipe for failure. When someone steps up to maintain a module, we'll be more than glad to re-adjust the commit policy accordingly. For example, sugar-jhbuild can stay the way it is because Sascha seems to be a very responsive maintainer. This is the main problem: we talk about work that needs to be done, but don't want to think about how we are going to resource it. I don't think that's healthy in an open community. No, what's not healthy is insisting on a development model that requires resources we currently don't have and thus loosing all the work that *is* being done. Are you kidding? We have about 3 people who have done reviews in the recent past and those people accumulate lots of other Sugar and non-Sugar responsibilities. Do you know how many full-time maintainers has the linux kernel? Do you know how many maintainers there were in the beginning? Only one. Do you know how the Linux kernel got to have many more? By making it damn easy to contribute. When I posted my first patch, I was not asked to become a maintainer of all the files I modified. Outsiders often look at the kernel development model and say: ha, they can do XYZ because they have so many resources to waste! But they're confusing the cause with the effect. Other projects that were almost dying due to lack of contributors suddenly got new life by simply switching to a bazaar model closer to the kernel. One such example is Xorg. Cjb, who follows the its development closely, could probably support my claim with some statistical evidence. I'm convinced the same would work in revitalizing Sugar's development. Please, let us try. You won't regret 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] Keyboard navigability of the Sugar UI
El Wed, 28-04-2010 a las 17:14 +0200, Tomeu Vizoso escribió: On Tue, Apr 27, 2010 at 16:25, Bernie Innocenti ber...@codewiz.org wrote: Today I filed a bug to keep track of an issue that has been bothering me for a long time: There's interest from the people at La Rioja on this, how can we agree on a plan together and resource it? http://lists.laptop.org/pipermail/olpc-sur/2010-April/005849.html Very good, indeed! Gonzalo, would you and your team like to take over this task for the 0.90 release cycle? In case you missed the original post of this thread: - Mensaje reenviado De: Bernie Innocenti ber...@codewiz.org Para: Sugar Devel sugar-devel@lists.sugarlabs.org Cc: Christian Marc Schmidt christianm...@gmail.com, Eben Eliason eben.elia...@gmail.com Asunto: [Sugar-devel] Keyboard navigability of the Sugar UI Fecha: Tue, 27 Apr 2010 10:25:16 -0400 Today I filed a bug to keep track of an issue that has been bothering me for a long time: http://bugs.sugarlabs.org/ticket/1969 Being an important UI issue, we'd need a good discussion with the design team. Unfortunately, we cannot always follow existing Gnome conventions for keyboard shortcuts. For example, rename cannot be done with F2 because it's already used for the buddy view. -8--8--8--8--8- The Sugar UI should be 100% navigable without using a mouse. Besides being an accessibility issue, it's important for quick navigation, especially for users stuck with a broken XO touchpads. Some proposed changes: * Favorites view * Search should be enabled in the shell view * A caret should appear when the user starts to type * Non-matching activities should be grayed out * TAB should cycle through possible completions * Cursor keys should cycle through the icons * Journal * Cursor up/down should scroll a caret on the list * ENTER should open the selected item (Linux/Windows style) * Rename item: TBD (just type something?) * Go to proprieties: TBD (cursor right?) * Change volume: TBD * Unmount all hot pluggable devices: TBD * Activities list view * Should behave like the journal * Network Neighborhood * Similar to favorites view * Toolbars * There should be a key to move the focus to the toolbars (alt-space?) -- // 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] ASLO QA process
El Sat, 24-04-2010 a las 07:19 +, Aleksey Lim escribió: In my mind activities on ASLO are not something like packages in regular GNU/Linux distribution. ASLO is not one centralized product, as already was mentioned several times it is (or should) palace to share your work (maybe in trash) with others thus we (will)have bunch of outdated/ forgotten projects. And it is ok for sugar (but not for GNU/Linux distributions). I also intended ASLO this way, until I realized that builds are being composed by picking the latest versions of activities from ASLO directly. Same goes for the update control panel. Because of this, users expect the things they find on ASLO to actually work and get pissed off if a new version of an activity breaks horribly. Distributors (like Paraguay Educa and OLPC) need to introduce a QA layer somewhere between the activity authors and the users. Whether we thought it this way or not, bundles on ASLO are equivalent to distro packages. And also most of activities come from individuals i.e. it's their masterpieces. So, lets talking about forking not about taking over. Ok, but we need to make sure that there's a way for one of these forks to become an automatic update for an abandoned activity. Moreover, there's the question of finding good names for activities. If the maintainer of Browse disappears, I wouldn't want to tell users: now you should download BernieBrowse instead of Browse. In my mind instead of increasing level of bureaucracy in sugar, for now, we could ping authors/nd publish forks on ASLO (with new bundle_id) and start implementing new Activities Library with taking into account all sugar specific (ASLO in case of AMO is not such, since Mozilla controls AMO addons and it is mostly centralized repo w/ QA etc). I agree with you that we should keep bureaucracy to a minimum. I liked your proposal of creating per-deployment collections to manage a set of activities that has been tested and approved. I think this is one of the things Uruguay wanted. If we decided to go this path, what would be missing? Does our update API support collections? Can anyone create a collection easily? I'm working on Activities Library (on early stage). It will look like: * server in the person of buddy in F1 view with shared instance of Library activity * any user can join this instance to see what activities are on the server * can just click to launch * can share new activity or fork of existed * any user can be such server, he just need to follow regular sugar practice, create new instance of Library and share it Any ideas are welcome http://wiki.sugarlabs.org/go/Activities/Library#Activity_Library Fantastic project! Will it support multiple libraries, for the same of decentralizing things? I can imagine that many deployments would want a hierarchical thing to save bandwidth and delegate decisions to school principals: the schoolserver would be the first place where children search for activities, then would come the deployment server and lastly ASLO. I think dsd did something like this for the old updater. -- // 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] Code Review process changes
? It's up to you: I'm ok with any decision you make, as long as patches are going to land in git within 48h most of the time. Once we're used to the current levels of latency, one may think a 48h is way too impatient. However, consider that my very first kernel patch got merged in Linus' tree in just about *5* minutes from posting it to lkml. It was very welcoming, very rewarding for me. This may be part of the reason why they managed to attract over one thousand active contributors. -- // 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] ASLO QA process
El Thu, 29-04-2010 a las 09:54 -0300, Daniel Drake escribió: 3. Reproducibility in low-connectivity deployments, or even for cases such as paraguay where connectivity is good but going to ASLO will really be slw and it's much more desirable to set up some simple infrastructure to run it within the school. i.e. that simple infrastructure needs to be developed and good documentation needs to be written. This is easily done by tuning Squid to cache large files if they have .xo extensions. The update panel only does one uncachable query to ASLO. (easiest approach for #3: support OLPC activity microformat. clean, simple format, well documented, designed for low connectivity situations, simple infrastructure is already developed and has been replicated around the world.) I also liked the OLPC microformat a lot more than the as-hoc rpc protocol provided by ASLO. It was simple to implement with any web technology, including static html files, wikis and web applications like ASLO. ASLO already outputs all the information required by the microformat. With some luck, it could be implemented without even touching the php code. -- // 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] Keyboard navigability of the Sugar UI
El Wed, 28-04-2010 a las 08:48 -0700, Christian Marc Schmidt escribió: The proposed keyboard shortcuts sound good. Maybe we can chat about the TBD items? Sure, ping me any time on #sugar. I'm in GMT+4 currently, same TZ as Boston. Or would you rather have a full-blown Design Team meeting? -- // 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] [PATCH] _update_signal_match wasn't initialized
El Wed, 28-04-2010 a las 19:33 +0200, Sascha Silbe escribió: Please provide the updated patch (i.e. including Reviewed-By/Tested-By/... lines) as a separate MIME part (I don't care whether it's marked inline or attachment, but it needs to be a separate MIME part so it doesn't get munged by the MUA). Also I'll need to know which branches it should be applied to. I've never had problems saving inline patches from either Evolution or Thunderbird and then applying them with git am. Mutt of course also works great. This is the regulard workflow to exchange patches by email: Alice: git format-patch -1 Alice: git send-email --to bob foo.patch Bob: (saves raw email body in MUA) Bob: git am foop.patch Ideally, you'd also have an Ack-By from the maintainer of sugar-toolkit (IIRC that's Simon). Hmm... sugar-toolkit is missing a MAINTAINERS file. It would be good to add it, or document the current maintainer mappings somewhere (gitorious, wiki...) -- // 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] Did someone say Webkit?
On Mon, 2010-04-26 at 17:38 -0700, Bobby Powers wrote: I wrote surf a while ago, and it was quite an easy port. In fact, the demo browser for pywebkitgtk was (at least at one point) based on browse. I did most of the work in a day and a half, but ran into problems with both webkit's packaging and the feature-completeness of pywebkitgtk (the ability to download files, for example), both of which seem to be solved now. Surf still works fine in Sugar 0.88 + Fedora 13. How about uploading it to ASLO and putting the source code in git? -- // 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] Keyboard navigability of the Sugar UI
Today I filed a bug to keep track of an issue that has been bothering me for a long time: http://bugs.sugarlabs.org/ticket/1969 Being an important UI issue, we'd need a good discussion with the design team. Unfortunately, we cannot always follow existing Gnome conventions for keyboard shortcuts. For example, rename cannot be done with F2 because it's already used for the buddy view. -8--8--8--8--8- The Sugar UI should be 100% navigable without using a mouse. Besides being an accessibility issue, it's important for quick navigation, especially for users stuck with a broken XO touchpads. Some proposed changes: * Favorites view * Search should be enabled in the shell view * A caret should appear when the user starts to type * Non-matching activities should be grayed out * TAB should cycle through possible completions * Cursor keys should cycle through the icons * Journal * Cursor up/down should scroll a caret on the list * ENTER should open the selected item (Linux/Windows style) * Rename item: TBD (just type something?) * Go to proprieties: TBD (cursor right?) * Change volume: TBD * Unmount all hot pluggable devices: TBD * Activities list view * Should behave like the journal * Network Neighborhood * Similar to favorites view * Toolbars * There should be a key to move the focus to the toolbars (alt-space?) -- // 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] [PATCH] sl#1876: cleanup partially extracted bundle on filesystem error
From: Martin Dengler mar...@martindengler.com This patch solves the most severe issue in #1876: filling up the filesystem with temporary files that won't be deleted afterwards. Before we can consider this bug completely fixed, we still need to do something for the remaining issues: 1) Unpacking shouldn't be attempted if there isn't a safety margin 2) System becomes unresponsive during unpacking 3) No progress indication for the operation, so users are tempted to click multiple times 4) No error messages displayed for unpacking errors, which is a common Sugar nuisance. http://bugs.sugarlabs.org/ticket/1876#comment:5 offers possible strategies for (1) and (2). Signed-off-by: Martin Dengler mar...@martindengler.com Signed-off-by: Bernie Innocenti ber...@codewiz.org --- src/sugar/bundle/bundle.py |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/src/sugar/bundle/bundle.py b/src/sugar/bundle/bundle.py index c9763a0..a04c873 100644 --- a/src/sugar/bundle/bundle.py +++ b/src/sugar/bundle/bundle.py @@ -72,7 +72,12 @@ class Bundle(object): if os.path.isdir(self._path): self._zip_file = None else: -self._zip_file = zipfile.ZipFile(self._path) +try: +self._zip_file = zipfile.ZipFile(self._path) +except (zipfile.error, LargeZipFile), ziperror: +raise MalformedBundleException( +Error accessing zip file %s: %s +% (self._path, ziperror)) self._check_zip_bundle() # manifest = self._get_file(self._infodir + '/contents') -- 1.7.0.1 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Did someone say Webkit?
On Mon, 2010-04-26 at 23:29 +0100, Lucian Branescu wrote: This is part of why I think having an abstraction layer is more important than having a complete pywebkitgtk browser activity. I would be even cooler if Read could also use this abstraction layer for epub. Now it makes sense. As long as there's only one activity using this abstraction layer, it wouldn't make sense to have it as a separate module. But careful: designing glue code of this kind is really hard. They're really bridges with an abstract API on each side. The Linux vfs layer would be a good example. Many iterations may be necessary to refine the interface before it can be considered stable on both side. These things also tend to make debugging very hard, because they introduce 2-3 additional layers of indirection between the user interface and the engine doing the actual work on its behalf. To slightly reduce the overall complexity, one may think to fold hulahop into one of the concrete browser implementations and remove most of the excess flexibility that it delivered. Anyway, Browse appears to be the only user of hulahop in the entire universe, so it would have been stupid to maintain in separately. This is of course just the personal opinion of a minimalist embedded engineer who hates unnecessary abstractions. I'm aware that innumerable books of mainstream software engineering encourage a diametrically opposite approach. In support my demodé opinion, consider that among the production-quality browsers, only Epiphany attempted to abstract away the differences between Mozilla and Webkit. However, after a while they decided it was too much work for too little benefit. Eventually, they discontinued Mozilla support. Epiphany was trying to solve just one half of the whole problem of mediating between multiple applications and browser engines. KDE's KPart would be closer to what you want to do, but after several years of struggling, the webkitpart still hasn't reached the point of usability. That said, I'm not familiar with the details of any of the APIs in question. It may very well be overestimating the actual complexity and the other projects I mentioned might have just been unlucky or mismanaged. On 26 April 2010 21:10, Sayamindu Dasgupta sayami...@gmail.com wrote: On Mon, Apr 26, 2010 at 2:18 PM, Lucian Branescu lucian.brane...@gmail.com wrote: There already is a mostly complete pywebkitgtk activity, Surf. There has been a lot of debate on whether webkit is better than gecko for our purposes. I also plan to only support what is reasonably easy to support and let the abstraction layer be leaky. This way, the new Browse can much more easily be ported to another web engine if needed. In fact, as the abstraction layer grows more complete, Browse can be 'ported' to the rest of the abstraction layer (as opposed to AbstractBrowser+hulahop events which would be the first step). Something which concerns me is the relative lack of maintainer activity for pywebkitgtk. For example, http://code.google.com/p/pywebkitgtk/issues/detail?id=44 lists an issue which was reported in December last year, and there has been no feedback on it (there is a proposed patch as well). The fix for the issue would help address a few crashers in Read in F-12 and above. Of course, as we move to gobject-introspection and friends, this should become less of a concern. Thanks, Sayamindu On 26 April 2010 03:20, Bernie Innocenti ber...@codewiz.org wrote: On Sun, 2010-04-25 at 18:07 +0100, Lucian Branescu wrote: My GSoC project involves building an abstraction layer above pywebkitgtk/hulahop (wiki/AbstractBrowser). While the project itself isn't related, this abstraction layer and one of it's lower layers (i.e. pywebkitgtk) would become a dependency of the sugar toolkit. Very interesting. Would your work make it possible to switch the Browse activity from XPCOM to Webkit? If there were no loss of features, would it be easier for you to switch the Browse activty from hulahop to pywebkitgtk without developing an abstraction framework for both? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] -- // 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] [PATCH] use ConsoleKit instead of HAL for shutdown/reboot
On Wed, 2010-04-21 at 10:32 +1000, James Cameron wrote: However, I've just applied the patch on os119 on XO-1.5, restarted Sugar and tested Restart and Shutdown options, and they function correctly. Restart causes a UL screen and reboot. Shutdown causes a UL screen and power off. As we're there, how do we get rid of the useless UL screen with its ugly inverted color scheme? Moreover, the UL screen fights with powerd's pretty shutdown screens. -- // 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] [PATCH] use ConsoleKit instead of HAL for
On Wed, 2010-04-21 at 01:19 -0400, Michael Stone wrote: P.S. - I might feel differently if I knew how to make D-Bus and ConsoleKit work sanely with chroots, which I care about deeply for purposes of testing. What's the problem? I do: mount --bind /var/run/dbus $ROOT/var/run/dbus I know how to make the /sbin/shutdown approach work sanely with chroots. You're probably still using an old Linux distro. The /sbin/shutdown implementation that comes from upstart 0.6 talks to init over dbus. Sorry to deliver such bad news, but dbus seems to be taking over the platform. As bad as it may seem, now at least we've got a unified IPC system with a consistent security model across many different daemons. -- // 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] Support for EPUB with Read in sugar-jhbuild?
On Sat, 2010-04-24 at 22:21 -0500, James Simmons wrote: 1). How do I get Read as delivered by sugar-jhbuld to work with EPUBs? 2). Does Read support EPUBs on SoaS right now? If not, what are our future plans regarding EPUB support? The only Linux reader that supports EPUB seems to be KDE's Okular, through libepub (ebook-tools). Moreover, Okular does not seem to dynamically reflow the text, which was the only useful feature EPUB had over PDF. Anyway, if we *do* support it, does it have to be in Read? Can't we have one activity per file format instead? It may be simpler from a maintenance and UI design PoV. Besides, EPUB resembles more HTML than PDF. -- // 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] [PATCH] Move etoys to the extra-activities group
This change considerably speeds up building the default target. As discussed on sugar-devel@, Etoys developers don't work in jhbuild, and Sugar core developers rarely need to test their changes against Etoys. To build Etoys and its dependencies, simply do one of: ./sugar-jhbuild build etoys ./sugar-jhbuild build meta-extra-activities Signed-off-by: Bernie Innocenti ber...@codewiz.org --- config/modulesets/extra-activities.modules |5 + config/modulesets/fructose.modules |4 config/modulesets/glucose.modules |1 - 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/config/modulesets/extra-activities.modules b/config/modulesets/extra-activities.modules index eba0bca..2a1123d 100644 --- a/config/modulesets/extra-activities.modules +++ b/config/modulesets/extra-activities.modules @@ -10,6 +10,10 @@ repository type=svn name=penguintv.sf.net href=https://penguintv.svn.sourceforge.net/svnroot/penguintv/; / + autotools id=etoys +branch repo=dev.laptop.org/projects / +dep package=squeak / + /autotools bundle id=penguintv branch repo=penguintv.sf.net module=trunk checkoutdir=penguintv / /bundle @@ -58,6 +62,7 @@ /bundle metamodule id=meta-extra-activities dependencies + dep package=etoys/ dep package=penguintv/ dep package=video-chat-activity/ dep package=connect-activity/ diff --git a/config/modulesets/fructose.modules b/config/modulesets/fructose.modules index 73a14e4..72369f3 100644 --- a/config/modulesets/fructose.modules +++ b/config/modulesets/fructose.modules @@ -30,9 +30,6 @@ bundle id=write branch module=write/mainline.git checkoutdir=write / /bundle - autotools id=etoys -branch repo=dev.laptop.org/projects / - /autotools bundle id=calculate branch module=calculate/mainline.git checkoutdir=calculate / /bundle @@ -51,7 +48,6 @@ metamodule id=meta-fructose dependencies - dep package=etoys/ dep package=read/ dep package=browse/ dep package=chat/ diff --git a/config/modulesets/glucose.modules b/config/modulesets/glucose.modules index cd3ea67..2a9a8ce 100644 --- a/config/modulesets/glucose.modules +++ b/config/modulesets/glucose.modules @@ -51,7 +51,6 @@ dep package=sugar/ dep package=pyabiword/ dep package=abiword-plugins/ - dep package=squeak/ dep package=gnome-python-desktop/ dep package=hulahop/ /dependencies -- 1.7.0.3.311.g6a6955 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] use ConsoleKit instead of HAL for
On Sun, 2010-04-25 at 12:48 -0400, Paul Fox wrote: unified, perhaps, except that access from shell (last i looked) was fairly inadequate. So I'm not the only one to be disgusted by this trend? Modern Linux is becoming worryingly similar to MacOS and Windows. CLI support is being added as an afterthought to new subsystems: http://fedoraproject.org/wiki/Features/NetworkManagerCmdline -- // 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] [PATCH] Move etoys to the extra-activities group
On Sun, 2010-04-25 at 20:12 +0200, Sascha Silbe wrote: On Sun, Apr 25, 2010 at 01:46:21PM -0400, Bernie Innocenti wrote: This change considerably speeds up building the default target. As discussed on sugar-devel@, Etoys developers don't work in jhbuild, and Sugar core developers rarely need to test their changes against Etoys. Please add the link to the decision: http://lists.sugarlabs.org/archive/sugar-devel/2009-May/014432.html [...] Signed-off-by: Bernie Innocenti ber...@codewiz.org Acked-By: Sascha Silbe sascha-...@silbe.org Thanks, committed. PS: I love our new workflow! -- // 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] Streamlining jhbuild
On Sun, 2010-04-25 at 14:39 -0400, Bernie Innocenti wrote: This is the list of remaining targets in Fedora 13, once I've installed all the system dependencies: The situation is somewhat worse in Ubuntu 10.04 (Lucid): logilab-common logilab-astng pylint These are required because Ubuntu is still stuck with pylint 0.19. GConf-dbus This is not really used unless one needs the SUGAR_PROFILE feature. We could easily remove it from the default build. python-xklavier Ubuntu does not seem to have this packaged. Does the control panel applet for configuring the keyboard work in Debian and Ubuntu? sugar-base sugar-datastore sugar-presence-service sugar-toolkit sugar-artwork sugar These are obviously ok. abiword pyabiword abiword-plugins These will finally go away in Lucid, which includes python-abiword. hulahop Ubuntu does not seem to have hulahop packaged. How does Browse manage to work without? meta-glucose read browse chat write terminal calculate log pippy imageviewer turtleart jukebox meta-fructose meta-sugar The fructose activities are 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] [PATCH] Shave off unnecessary dependencies from jhbuild
On Sun, 2010-04-25 at 23:59 +0200, Sascha Silbe wrote: - distutils id=dogtail -branch repo=fedorahosted/ -!-- sysdep: pyatspi -- - /distutils NAK. Please don't remove the package itself, just the dependency in meta-tools. We'll need it again in the future for UI testing. OK. - package name=xulrunner-devel-unstable source=xulrunner/ - package name=xulrunner-python source=xulrunner/ - package name=xulrunner-python-devel source=xulrunner/ + package name=xulrunner source=xulrunner/ /dependencies As mentioned on IRC, please remove the xulrunner dependency completely (on Fedora) as it's only needed for hulahop which we already depend on. But if I remove this, wouldn't jhbuild try to build xulrunner from source? Or am I still misunderstanding how jhbuild thinks? @@ -14,5 +14,5 @@ package name=python-wnck source=gnome-python-desktop/ package name=telepathy-gabble source=telepathy-gabble/ package name=telepathy-salut source=telepathy-salut/ - package name=xulrunner-1.9.1-dev source=xulrunner/!-- for hulahop -- + package name=xulrunner-1.9 source=xulrunner/!-- for hulahop -- /dependencies How recent a hulahop version do we want to ensure? Ubuntu has 0.4.6-0ubuntu2.1, 0.4.8~dfsg-3ubuntu4 and 0.4.9-1ubuntu2 on Intrepid resp. Jaunty and Karmic. If (a subset of) these are sufficient for Browse, we could change hulahop to distro packages on Ubuntu as well and drop the xulrunner dependency. Fedora has 0.7.1. Lucid does not seem to have it at all. Was the package dropped or what? diff --git a/config/sysdeps/debian-family.xml b/config/sysdeps/debian-family.xml index 463f4fe..6aae02b 100644 --- a/config/sysdeps/debian-family.xml +++ b/config/sysdeps/debian-family.xml @@ -66,7 +66,6 @@ package name=python-hippocanvas source=hippo-canvas/ package name=python-libxml2/ package name=python-numpy/ - package name=python-pyatspi/!-- for dogtail -- As we keep dogtail, we also need to keep python-pyatspi. Isn't there a way to prevent jhbuild from requesting this dependency unconditionally? -- // 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] Streamlining jhbuild
On Mon, 2010-04-26 at 00:14 +0200, Sascha Silbe wrote: On Sun, Apr 25, 2010 at 05:42:51PM -0400, Bernie Innocenti wrote: The situation is somewhat worse in Ubuntu 10.04 (Lucid): logilab-common logilab-astng pylint These are required because Ubuntu is still stuck with pylint 0.19. That's because Lucid was already in freeze when 0.20 came out. [snide remark about Fedora update policy removed just in time before sending this email] pylint 0.20 was released on 25 March 2010 (it was also included in Fedora 12). hulahop Ubuntu does not seem to have hulahop packaged. It _does_ have hulahop packaged [3]. Uh? Was the package dropped from Lucid? -- // 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] [PATCH] Shave off unnecessary dependencies from jhbuild
On Mon, 2010-04-26 at 00:33 +0200, Sascha Silbe wrote: Oh, you're right. I got confused by the many different Ubuntu releases; hulahop is only included up to Karmic. They have dropped hulahop from Lucid because it requires xulrunner and python-xpcom. That reminds me I should request Sugar to be removed from Lucid. With almost no activities packages and no Browse to download them from activities.sugarlabs.org, it's pretty much useless to ordinary users. David and the Sugar Team are working on improving the situation: https://edge.launchpad.net/~sugarteam/+archive/ppa Presumably, at some point they'll ask MOTU to merge their changes, or something similar. I'm not familiar with the entire Ubuntu packaging workflow. As we keep dogtail, we also need to keep python-pyatspi. Isn't there a way to prevent jhbuild from requesting this dependency unconditionally? Unfortunately there isn't. The use distro packages part is a custom Sugar Labs hack; making it conditional on what packages are going to be built would be quite some effort to implement. I'm not even sure I'd merge a patch that does this as we'd divert further from upstream JHBuild. Wait a minute, is there a distro without dogtail on which you'd like to use it? PS: Please don't CC me, I'm subscribed to this list and set Mail-Followup-To accordingly. My MUA evidently does not understand Mail-Followup-To. Or maybe it adds you to the list because your address is also in Reply-To. Anyway, can't you simply set the nodupes option in Mailman? -- // 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] Modern Linux trends
On Sun, 2010-04-25 at 18:54 -0400, C. Scott Ananian wrote: I am failing to resist responding to this troll. Dbus access from the command line is fairly good, and NM supports a number of static data files for configuration if that's what you want yo do. Fear not, scriptability of Unix systems is, if anything, *increasing*, as there are now powerful ways to get at the internals of most system software using things like gobject, which provide much more powerful mechanisms than simple pipes and getopt. +1 Insightful. You would have got a +1 Informative if you'd link to a nice tutorial. I've always wanted to learn how to control things with dbus. Learn the new tools, you'll like them. Arguing from the stuck-in-the-mud old fart perspective may be fun, but it's not constructive. Bah, such a luddite! ;-) I'll go back trying to get my scroll wheel emulation to work in my brand new X 1.8. The old xorg.conf way was way too easy: Option EmulateWheel 1 Option EmulateWheelButton 2 When static configuration files fell in disgrace, I figured out that I could achieve the same functionality by means of this simple HAL fdi: /etc/hal/fdi/policy/10-bernie.fdi: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input.mouse merge key=input.x11_driver type=stringmouse/merge match key=info.product contains=TPPS/2 IBM TrackPoint merge key=input.x11_options.EmulateWheel type=string1/merge merge key=input.x11_options.EmulateWheelButton type=string2/merge /match match key=/org/freedesktop/Hal/devices/computer:system.kernel.name string=Linux merge key=input.x11_driver type=stringevdev/merge /match /match /device /deviceinfo Now hal also fell in disgrace and devices are being configured directly by udev. Being clueless, I asked my friends on #xorg-devel: berniewhot: what's the udev equivalent of these hal rules for Xorg 1.8? remi|work bernie, we started writing an upgrade guide for our users with a couple examples : http://dev.gentoo.org/~scarabeus/xorg-server-1.8-upgrade-guide.xml bernieremi|work: thanks! dberkholz remi|work: yeah, i guess we could reverse our old script that translated xorg.conf to fdi dberkholz wherever that thing ended up remi|work dberkholz, that script is dead, it relied on xf86config which can't be pulled easily from the server dberkholz it's been a while, but i thought we had figured out some way around that remi|work dberkholz, besides, I've never been a huge fan of that script. I think our users should know what they're doing remi|work so we're documenting it properly dberkholz i think knowing what you are doing is different from creating needless work dberkholz when will people ever need to repeat this task again? how is it a valuable skill? remi|work then let's not run the script by default remi|work if you create one... remi|work IMHO, trying to figure out how to parse HAL .fdi files isn't much fun. remi|work and given the complexity HAL files can reach, I don't think it'll work reliably dberkholz sigh. that dumb script was never written to actually understand the xml, just to output tags as raw text. Eventually, I wrote this: Section InputClass Identifier TPPS/2 IBM TrackPoint Wheel Emulation Driver evdev Option EmulateWheel true Option EmulateWheelButton 2 MatchProduct TPPS/2 IBM TrackPoint EndSection Unfortunately, it doesn't seem to work. I'm not really sure what the product string is supposed to be, and testing changes requires restarting X. Meanwhile, I'm typing two obscure xinput commands manually every time I start my X server: xinput --set-int-prop 'TPPS/2 IBM TrackPoint' 'Evdev Wheel Emulation Button' 8 2 xinput --set-int-prop 'TPPS/2 IBM TrackPoint' 'Evdev Wheel Emulation' 8 1 Ah, progress... why don't anyone just love it? Now you've got to be a hacker with connections with the Xorg core developers in order to configure your clit mouse on Linux! -- // 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] [PATCH] Shave off unnecessary dependencies from jhbuild
xulrunner-python-devel: we don't need it at all xulrunner-devel: not needed since we don't build hulahop from source dogtail: only needed on systems that build evince csound-devel: not needed since we don't build csound from source Tested on Fedora 13, Fedora 12 and Ubuntu 10.04. Signed-off-by: Bernie Innocenti ber...@codewiz.org --- config/modulesets/tools.modules |1 - config/sysdeps/50fedora-12.xml |4 config/sysdeps/50fedora-rawhide.xml |3 --- config/sysdeps/50ubuntu-10.04.xml |2 +- config/sysdeps/fedora-family.xml|2 +- 5 files changed, 2 insertions(+), 10 deletions(-) diff --git a/config/modulesets/tools.modules b/config/modulesets/tools.modules index 715c640..4dcdd83 100644 --- a/config/modulesets/tools.modules +++ b/config/modulesets/tools.modules @@ -40,7 +40,6 @@ /distutils metamodule id=meta-tools dependencies - dep package=dogtail/ dep package=pep8/ dep package=pylint/ /dependencies diff --git a/config/sysdeps/50fedora-12.xml b/config/sysdeps/50fedora-12.xml index 8cdbc78..cca3cda 100644 --- a/config/sysdeps/50fedora-12.xml +++ b/config/sysdeps/50fedora-12.xml @@ -1,10 +1,6 @@ ?xml version=1.0? dependencies - package name=dogtail source=dogtail/ package name=metacity source=metacity/ package name=pylint source=pylint/ package name=python-xklavier source=python-xklavier/ - package name=xulrunner-devel-unstable source=xulrunner/ - package name=xulrunner-python source=xulrunner/ - package name=xulrunner-python-devel source=xulrunner/ /dependencies diff --git a/config/sysdeps/50fedora-rawhide.xml b/config/sysdeps/50fedora-rawhide.xml index 222166b..cca3cda 100644 --- a/config/sysdeps/50fedora-rawhide.xml +++ b/config/sysdeps/50fedora-rawhide.xml @@ -1,9 +1,6 @@ ?xml version=1.0? dependencies - package name=dogtail source=dogtail/ package name=metacity source=metacity/ package name=pylint source=pylint/ package name=python-xklavier source=python-xklavier/ - package name=xulrunner-devel source=xulrunner/ - package name=xulrunner-python-devel source=xulrunner/ /dependencies diff --git a/config/sysdeps/50ubuntu-10.04.xml b/config/sysdeps/50ubuntu-10.04.xml index a53022d..e7f8452 100644 --- a/config/sysdeps/50ubuntu-10.04.xml +++ b/config/sysdeps/50ubuntu-10.04.xml @@ -14,5 +14,5 @@ package name=python-wnck source=gnome-python-desktop/ package name=telepathy-gabble source=telepathy-gabble/ package name=telepathy-salut source=telepathy-salut/ - package name=xulrunner-1.9.1-dev source=xulrunner/!-- for hulahop -- + package name=xulrunner-1.9 source=xulrunner/!-- for hulahop -- /dependencies diff --git a/config/sysdeps/fedora-family.xml b/config/sysdeps/fedora-family.xml index 4f98658..43ddbd2 100644 --- a/config/sysdeps/fedora-family.xml +++ b/config/sysdeps/fedora-family.xml @@ -6,7 +6,7 @@ package name=avahi-gobject-devel source=avahi/ package name=avahi-tools source=avahi/ package name=boost-devel/ - package name=csound-devel/ + package name=csound/ package name=dbus-devel/ package name=dbus-glib-devel/ package name=dbus-python/ -- 1.7.0.1 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Did someone say Webkit?
On Sun, 2010-04-25 at 18:07 +0100, Lucian Branescu wrote: My GSoC project involves building an abstraction layer above pywebkitgtk/hulahop (wiki/AbstractBrowser). While the project itself isn't related, this abstraction layer and one of it's lower layers (i.e. pywebkitgtk) would become a dependency of the sugar toolkit. Very interesting. Would your work make it possible to switch the Browse activity from XPCOM to Webkit? If there were no loss of features, would it be easier for you to switch the Browse activty from hulahop to pywebkitgtk without developing an abstraction framework for both? -- // 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] Code Review process changes
On Fri, 2010-04-23 at 15:17 +1000, James Cameron wrote: Activities too? I've been tracking #1571 for months now, and if posting the patch here will work, I'm all for it. ;-) If you were just asking whether it's ok to post patches for activities here, sure: we have no separate mailing list for activities (*). If, instead, you were proposing to relax the rules for approving patches to activities, I think we should discuss this carefully. Many activities would probably be better off with their only maintainer reviewing and approving each patch personally. What about the fructose activities? What about orphaned activities? The question of how to handle the case of an unresponsive maintainer came up on #sugar last week: shall we define a formal procedure for taking over projects in ASLO and Gitorious? This is how Fedora handles it: http://fedoraproject.org/wiki/Package_maintainer_policy#What_to_do_if_a_Maintainer_is_absent If it seems reasonable, we could adopt the very same procedure for ASLO and Gitorious, of course with some obvious changes: s/bugzilla/trac/, s/FESco/SLOBs/, s/CVS/Gitorious or ASLO/. (*) this was a deliberate choice: this way, core developers would get a sense of what the infrastructure needs of activities really are, while activity writers would learn about Sugar internals and eventually become core developers. -- // 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] [PATCH] Remove the keep button from the default activity toolbar
On Thu, 2010-04-22 at 23:35 -0400, Frederick Grose wrote: Yes that would work, and wouldn't leave a hidden button taking up space on the tool bar. Ok, we'll work on a patch to do this. By the way, I don't see how one keeps a copy from the Journal to a new Journal item. One can copy to the clipboard and then keep a text file to the Journal from the primary Journal view (in the panel for the object icon - Sugar 0.88), and, in the extended Journal object view, one can copy files as text to attached devices--but how would one keep a copy of the running Activity? Ugh. We clearly need to put a lot more thought into Journal interaction: * lack of multiple selection makes certain tasks such as copying 10 photos to a pendrive amazingly repetitive and slow. * lack of a size column in the list view makes it hard to identify large items that could be deleted to free up some space. -- // 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] [PATCH] Remove the keep button from the default activity toolbar
On Wed, 2010-04-21 at 20:34 -0400, Frederick Grose wrote: Got it, sounds good, thanks. Here's the obvious patch. -0.5 Please, let's move halfway so we don't break workflows already established. For example, someone has already developed lessons for that involve keeping Physics models at various stages of development. Keeping a copy from the Activity tool bar is a part of that. Could we instead hide the Keep a copy button so that it only appears on the pressing of the 'Alt key'. this should take away the temptation for the 'unsweetened' to become 'bitter'. It will take a while before old habits change and a new mental model of keeping ones work takes hold. How about folding Keep a copy inside the popup menu for the Stop button? If we take it away completely, I can already see the angry users telling me that now they have to stop and reopen activities every 10 minutes to ensure their data is safely stored on disk. -- // 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] Code Review process changes
On Tue, 2010-04-20 at 18:26 +0200, Sascha Silbe wrote: We'd like to try a different approach that's used by many successful projects - both small and large ones. Patches are sent to sugar-devel for review. Every Sugar developer (*) can review patches (and multiple reviews are quite welcome). Since the number of developers with commit access is limited, we have a sufficient level of QA even without limiting who can do reviews. I noticed that we're already getting into this habit spontaneously, but it might be good to mention how the various tags are used in the Linux kernel. Here's the relevant excerpt from the Linux kernel documentation on submitting patches [1] [2]: -8--8--8--8--8--8- - Signed-off-by: this is a developer's certification that he or she has the right to submit the patch for inclusion into the kernel. It is an agreement to the Developer's Certificate of Origin, the full text of which can be found in Documentation/SubmittingPatches. Code without a proper signoff cannot be merged into the mainline. - Acked-by: indicates an agreement by another developer (often a maintainer of the relevant code) that the patch is appropriate for inclusion into the kernel. - Tested-by: states that the named person has tested the patch and found it to work. - Reviewed-by: the named developer has reviewed the patch for correctness; see the reviewer's statement in Documentation/SubmittingPatches for more detail. - Reported-by: names a user who reported a problem which is fixed by this patch; this tag is used to give credit to the (often underappreciated) people who test our code and let us know when things do not work correctly. - Cc: the named person received a copy of the patch and had the opportunity to comment on it. -8--8--8--8--8--8- Git handles some of these automatically. When you save a patch, you could simply do: # Export a patch with your Signed-off-by git format-patch -1 -s # Send patch to a maintainer, and cc the mailing list git send-email --to some...@sugarlabs.org --cc sugar-devel@lists.sugarlabs.org Committers should record in the patch who reviewed and ack'd a patch. This can be easily done by editing the comment in interactive mode: git am -i foo.patch (then use e to edit the patch) Alternatively, one could also edit the comment after the fact with git commit --amend. Attributing due credit to reviewers and testers is important because they're a scarce resource. A healthy development process depends on them as much as developers. Personal note: Instead of using a patch tracker, we could also ask patch submitters to file tickets at bugs.sugarlabs.org if there has been no review for, say, 3 days. This gives a streamlined process for most patches while still ensuring nothing gets lost. Another possibility is pinging on the list after a few days, perhaps adding on Cc people who are known to have worked in the area affected by the patch. for informational purposes, I continued to attach some patches to existing tickets. The difference is that it's no longer a required step for getting a patch in the mainline tree. [1] http://kernel.org/doc/Documentation/SubmittingPatches [2] http://kernel.org/doc/Documentation/development-process/5.Posting -- // 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] Keep confusion, yet again
On Mon, 2010-04-19 at 09:41 -0300, Daniel Drake wrote: Argh! Another country, another core team confused by the Keep button. The Argentinian in-house generated teaching materials say: (translated from Spanish) To save the work that you did in the activity, go to the toolbar at the top of the screen and click the Keep button. Same story every single time. Pretty please can someone please pick up the project of improving this situation? Even if it's just killing this button for the time being. I've seen this confusion in all 6 of the countries that I've visited. And in most of those cases, it's written in the teacher training materials, so the trainers pass this misinformation onto the teachers who pass it onto the children. I've seen users and teachers fooled by the Keep key here too. I remember reading in an old book on human interface design called The Psychology of Everyday Object that testers are never going to report usability annoyances of this kind, attributing the mistake to themselves rather than to the UI designer. For now I am going to update the Spanish translation to say Guardia copia (Keep a copy) but this is not the solution... Jorge is going to work on this. -- // 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] Co-maintaining labyrinth
Gary, have you gone MIA? :-) We really need to get these changes in for this release. I'll ask alsroot to add Jorge as a maintainer of Labyrinth in ASLO so we can upload a new bundle. Hope it's ok with you. If, at a later time, you decide that this feature should have been implemented differently, or does not belong to Labyrinth altogether, we'll work together on a new release. On Wed, 2010-04-14 at 12:39 -0400, Bernie Innocenti wrote: Ping? On Thu, 2010-04-08 at 10:28 -0300, Bernie Innocenti wrote: Hello Gary, at Paraguay Educa we started doing some heavy lifting on Labyrinth: http://bugs.sugarlabs.org/ticket/1829 Can you please review the patch and roll a new update in ASLO? If you don't mind, Jorge would like to co-maintain Labyrinth and issue updates for it on ASLO. If you agree, give write permission to userr jasg in Gitorious. If you'd prefer all patches to go through you, we'd be equally happy with this workflow. -- // 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] Co-maintaining labyrinth
Ping? On Thu, 2010-04-08 at 10:28 -0300, Bernie Innocenti wrote: Hello Gary, at Paraguay Educa we started doing some heavy lifting on Labyrinth: http://bugs.sugarlabs.org/ticket/1829 Can you please review the patch and roll a new update in ASLO? If you don't mind, Jorge would like to co-maintain Labyrinth and issue updates for it on ASLO. If you agree, give write permission to userr jasg in Gitorious. If you'd prefer all patches to go through you, we'd be equally happy with this workflow. -- // 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] Co-maintaining labyrinth
Hello Gary, at Paraguay Educa we started doing some heavy lifting on Labyrinth: http://bugs.sugarlabs.org/ticket/1829 Can you please review the patch and roll a new update in ASLO? If you don't mind, Jorge would like to co-maintain Labyrinth and issue updates for it on ASLO. If you agree, give write permission to userr jasg in Gitorious. If you'd prefer all patches to go through you, we'd be equally happy with this workflow. -- // 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] [DESIGN] Simple Journal Backup Restore
On Thu, 2010-04-08 at 17:04 -0300, Esteban Arias wrote: Another possible design: In the volumes Toolbar of the Journal, when the user press click right on the volume connected, the palette shows also: Backup Journal and Restore Journal +1. I like this idea. To backup/restore on the schoolserver, we could add similar commands to the palette of the Journal icon on the volumes toolbar. It sounds more natural there than in the control panel. Martin (Langhoff, not Abente): the backup UI delegates the actual work to 3 simple shell scripts which were written by Daniel Drake last year. They depend on other files from ds-backup-client, so it would make sense to fold them in there. The glue scripts are here: http://people.sugarlabs.org/bernie/sugar/journal-backup http://people.sugarlabs.org/bernie/sugar/journal-backup-list http://people.sugarlabs.org/bernie/sugar/journal-restore Alternatively, we could put these into the sugar-datastore package alongside with the other bits from the ds-backup-client package. This would save us the time to get a new package through the Fedora review process. Since we need a working backup/restore solution by next Monday, I've already included the scripts in a custom ds-backup-client package. If we decide to go for a different solution, I'll make the necessary changes after the release. -- // 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] [DESIGN] Simple Journal Backup Restore
On Mon, 2010-04-05 at 11:39 -0300, Esteban Arias wrote: Hi, In Plan Ceibal (Uruguay) , we developed solution of jorunal backup/restore on sugar 0.82. We added button Backup and button Restore on toolbar of the Journal activitie. If exist pendrive connected, the system do backup/restore in the extern dispositive. When the user press the button, the system run script to do backup/restore. The script is based of solution of Daniel Drake. The UI looks very nice! We were undecided whether to write a control panel item or add these functions to the journal. Are patches available anywhere? How much work would it be to adapt them to Sugar 0.84 and 0.88? It would be useful to make the git trees of Ceibal developers available for public review somewhere (either git.sugarlabs.org or a local gitweb), as you guys probably have accumulated plenty of other useful things that we might like to have. -- // 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] [DESIGN] Simple Journal Backup Restore Control Panel
On Thu, 2010-04-01 at 09:21 +1100, James Cameron wrote: On Wed, Mar 31, 2010 at 06:36:06PM -0300, mabente wrote: So, what do you guys think? I like it. I presume it won't appear unless a school server is known? I wonder if this can be done at the control panel level... probably easier to let the icon appear anyway, and then disable the functionality in the window. In the future, we may want to add a backup/restore function for removable storage. -- // 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] Journal Backup/Restore UI
On Mon, 2010-03-29 at 10:14 +0200, Martin Langhoff wrote: On Mon, Mar 29, 2010 at 2:22 AM, Bernie Innocenti ber...@codewiz.org wrote: However, it looks like it would take a couple of months of effort to get I think you are overengineering this. - Single-file restore is well solved by Moodle's backup/restore UI + Browse - As you found out, librsync isn't what you want... just rsync _all_ of it, and then inject each entry using copy-to-journal. It doesn't fix the disk usage problem, but it sure solves the restart datastore and the associated issue that you are deleting whatever new was in the Journal. You are not restoring. Ok, how about: - an initial rsync with no destination to list what's available - rsync one file at a time + copy-to-journal. There's still the possibility that one very large file would make the entire process fail. Does the datastore support creating entries with no data and writing the data at a later time? I don't know much about the datastore design, but I got that we use uuids as keys, not hashes of the content. Stoopid question: can't you 'FUSE'-mount the XS directory with sshfs and then use copy-to-journal? Latency will make that a tad slower, but the local-diskspace issue is gone. Very good idea. -- // 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] SocialCalc bugs
On Fri, 2010-03-19 at 17:48 +0530, Manusheel Gupta wrote: I have downloaded the OS67. Will check this over the weekend, and get back to you soon. We now have a new public bete build: OS115. See the announcement posted to olpc-devel for full details. Ricardo reported another SocialCalc bug: http://trac.paraguayeduca.org/ticket/585 http://trac.paraguayeduca.org/attachment/ticket/585/tmpqCZ_E0.png The description sais that charts seem to have layout problems. Do you think it's a browser specific bug, a bug in the JavaScript code, or something else? -- // 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] Journal Backup/Restore UI
On Sun, 2010-03-28 at 14:14 +0200, Tomeu Vizoso wrote: I'm a bit confused, is the problem reliable full restore with limited local space or the DS having the xapian DB open while the copy happens? Or both? Both, but somehow we managed to solve them in a quick dirty way: 1) our script kills the datastore process before starting the restore. Then, at the end of the procedure, we restart Sugar. 2) we restore the journal in place, using the --delete-before option of rsync in order to free up space in the filesystem beforehand I've tested this procedure yesterday in a school, and it worked egregiously with two different laptops. The code is here: http://trac.paraguayeduca.org/browser/scripts/os-modifications/diario-restaurar Now we're just missing a nice GUI for end-users: a control panel icon or a button in the journal toolbar. Someone has to file a feature request and discuss it with the Design team. Would anyone like to get started on this while we're still busy fixing the few remaining high-priority bugs in Sugar 0.84? -- // 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] Journal Backup/Restore UI
On Sun, 2010-03-28 at 20:08 +0200, Martin Langhoff wrote: On Sun, Mar 28, 2010 at 2:29 PM, Bernie Innocenti ber...@codewiz.org wrote: On Sun, 2010-03-28 at 14:14 +0200, Tomeu Vizoso wrote: I'm a bit confused, is the problem reliable full restore with limited local space or the DS having the xapian DB open while the copy happens? Or both? Both, but somehow we managed to solve them in a quick dirty way: Doesn't copy-to-journal skip all the ugly? Oh, well, indeed. Though we need to figure out how to glue it to the rsync back-end. The easy part is binding rsync to Python: this was already done in duplicity by wrapping librsync with simple C and Python code which we could steal. Then it starts to get hard: the files are probably going to come down from the xs in some random order. librsync provides a sophisticated callback interface, but there seems to be also a whole-file interface. This approach also opens other interesting possibilities such as restoring individual files or merging the backup with the current journal contents. However, it looks like it would take a couple of months of effort to get something like this done. For the time being, we could keep using the plain rsync and maybe just add a stop/resume interface to the datastore? -- // 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] Journal Backup/Restore UI
On Sun, 2010-03-28 at 21:22 -0300, Bernie Innocenti wrote: Oh, well, indeed. Though we need to figure out how to glue it to the rsync back-end. The easy part is binding rsync to Python: this was already done in duplicity by wrapping librsync with simple C and Python code which we could steal. Wait, I had overlooked this note: librsync does not speak the (hairy) application-specific protocol used by rsync. They only share an algorithm, not any code. This rules it out for our usecase, unless we also want to rewrite the xs backend. -- // 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] New release of F11 for the XO-1 is available for testing - OS13
On Sat, 2010-03-27 at 10:12 -0700, Yioryos Asprobounitis wrote: Too many builds and only one XO-1 :-) Is there any priority? We'll deploy this to ~4000 kids really-soon-now. Bugs reported within 1-2 weeks have a chance of being fixed in time. Is testing os115-py immediately applicable to os13 and vice versa? They should already be very similar, and we're going to merge as much as possible. -- // 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] [IAEP] Children want Sugar 0.84, for the wrong reason
On Mon, 2010-03-15 at 16:03 -0500, Martin Langhoff wrote: Agreed. You can do what you are doing (run a school on newish sw, get a tight feedback bugfix loop) when someone like you is there. [...] Yes -- but we gotta remember that it's productive (specially for Sugar) because you are there. You can turn their frustration into valuable info (and bugfixes). Without you, it's just frustration. Indeed :-( I'm trying to get everyone on IRC and mailing lists before I leave. In Nepal it worked, but here the language barrier is higher. I told everyone that Spanish is welcome in bug reports, blog posts and for chatting on #sugar. Many of our core developers speak Spanish fluently, so they could bridge information to the others. Admittedly, it's not working: people come to IRC, they see that everyone speaks English, and shy away. I don't believe in breaking the community apart in many per-language ghettos, but Spanish probably has enough critical mass to justify a #sugar-es (or #olpc-es) channel. That's a good idea -- try to work in a school with latest Sugar late in the previous school year, to incorporate stuff for the wider deployment in the over-summer-holidas upgrade. (And actually we have a late-starting deployment in La Rioja, which is on-time to take advantage of that work.) Cool! A lot of stuff is moving forward here: * This Monday we'll have another meeting with the formadores to help them file complete and understandable bug reports without the need for us to go on-site. * We're now tracking the remaining bugs here: http://wiki.paraguayeduca.org/index.php/Devel/Builds/Todo * Two more developers of the Paraguay Educa technical team are learning to create OS builds. Next week, they'll start helping out with activities. * The formadores (teacher trainers) got used to the differences in the new software release and are no longer diffident. That's truly a good question. I'll say the teams closest to the deployments. Distant upstreams (kernel, udev, Fedora) don't care directly about our end users. OLPC/SLers are passionate about children learning. [...] Yep - that and combine it with working with a few schools on recent releases, with a developer on-site -- like you, Simon and others are doing. Yes, we definitely need more errant developers! Since there's a limited amount of core developers in OLPC and SL, in the future we may want to encourage deployments to exchange developers. The Paraguayan team now employs hackers with two years of experience. The same is probably true in Uruguay. It would be great if one of them could travel to the fledgling Argentinian deployment and help them build capacity locally. A decentralized model of international collaboration would solve the scalability problem. In practice, it probably means we'll be answering questions about any release for about 1.5 to 2 years after the release date. Interestingly, Mark Shuttleworth has recently argued for a 2 years cycle synchronized across all the enterprise distributions: http://www.markshuttleworth.com/archives/290 If his proposal acquires enough momentum within the community, it would make sense for us to synchronize with it, solving the issue of being left behind by the rest of the development community. N. I'm not so crazy. But we have to fit in the school's 1-year-cycle, have time to stabilise, etc. Small deployments have more flexibility, and when someone like you is literally on site you can go wild... (take advantage of that!) but for the thousands of other schools an LTS Testing and stabilize a new version of Fedora and Sugar on the XO could be done with as little as a few thousand students in a small town, with just 1-2 developers on site. After we're done with Sugar 0.84, I'll try to repeat the development cycle for Sugar 0.88 and Fedora 12, starting with few adventurous volunteers such as the Scratcheros. -- // 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] Restoring journal backups created with 0.82 on 0.84
Martin, Rodolfo Aldo, one of the technicians in Caacupe, reported failure to restore backups created with Sugar 0.82 after the machine has been upgraded to Sugar 0.84. Frankly, I don't understand how the restore script is supposed to work: it rsyncs the files into ~/.ds-restore-tmp and then quits without moving them where the datastore is. I tried moving the files manually into ~/.sugar/default/datastore and restarting Sugar, but nothing shows up. How does the datastore detect an old format that needs updating? Besides this problem, it would be useful to add a control panel icon for listing available backups and restoring them. Is anyone working on this? -- // 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] [IAEP] Children want Sugar 0.84, for the wrong reason
On Mon, 2010-03-15 at 10:46 -0500, Martin Langhoff wrote: On Sun, Mar 14, 2010 at 1:17 AM, Bernie Innocenti ber...@codewiz.org wrote: Me too, but it's not as bad as it seems: the techies use a simple shell script to backup and restore the journal (and scratch data) across So no XS in place? The repair lab is not nearby any of the schools. Downstreams that go to deployment (OLPC!) want to wait until a release is reasonably well tested and stabilised. We have a chicken-and-egg problem: deployments have to participate in testing (and development), otherwise no bugs will ever be fixed. Stability is a classic justification for longer release cycles The thing is: stabilisation takes time. These users are not programmers, nor geeks. They are not the Fedora hard-core gimme the latest even if broken. They are teachers and children in a school. I don't mess with my editor or my version control system often. emacs updates have messed up my life, so I don't do them in the middle of a project. Similarly, teachers won't want frequent updates, or updates that are broken (in Sugar core, or in activity compatibility!). Letting volunteer children and teachers test the software has been incredibly productive. I wish I could have started one month earlier, so there would have been enough time to fix most problems before schools reopened in LatAm. A few trainers who were asked to test new builds much explanation complained for the annoyances without providing enough information for a bug report. Considering that most of them were exposed to computers for the first time in their lives just a couple of months ago, it's no wonder they were unable to distinguish between hardware and software problems. I filed a few real bugs last week, and this week I'll spend a few full days side by side with the trainers to see what issues are still bothering them. That is only true if the dev team only cares about the hardcore geeks that want the latest and greatest. If the dev team cares about end users, then it's not abandonware. Which dev team? There are many: Sugar Labs, OLPC, Fedora, and all the other upstream projects we depend upon. Now I have a problem with udev which is unlikely to be fixed by upstream. The maintainer *does* care about end users, but he'd rather spend his time supporting the current user base than the legacy Fedora 11 which is soon going end-of-life. Same goes for the activities developers: maintaining compatibility with 3-4 releases of Sugar is prohibitive. Backporting bugfixes is also very expensive in terms of time and not something that volunteers are likely to do spontaneously. OLPC allocated developers to maintain the Sugar 0.84 and related activities, but it would save time if we could stay closer the latest Fedora and the latest Sugar, at least at release time. However, the most efficient use of our scarce resources would be to reduce version diversity across downstream distributors in order to share the burden of maintaining all them. Agreed. One path is to release less often. Or to mark certain releases LTS. I've been suffering with RHEL for a while and I'm sure Ubuntu LTS has the same problem: no support for new hardware, ancient versions of software which don't interact well with the rest of the world... I think it would work well if one could freeze the whole universe at the time of the LTS release. Yep. You could make it a major / minor pair. So you only have one LTS per year. Developer releases can happen more often. One year of slack between development and user release would be ideal. By LTS, I thought you meant 5 years :-) -- // 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] Children want Sugar 0.84, for the wrong reason
On Sat, 2010-03-13 at 13:35 +0100, Bert Freudenberg wrote: So +1 to look customization. E.g., why not allow to change the gray frame color? In Etoys you can at least change the toolbar color (not permanently though, I should fix that). Even if it enrages our latte-drinking black-wearing designer friends ;) they're kids after all ... I feel that Sugar should aim to reach the same level of hackability of eToys: every UI element is an object that you could drag, drop, copy or modify. Of course, this has consequences in terms of stability and clarity. Before we could unleash this power we need to think of ways to recover from mistakes. If multiple undo is too hard, a restore everything to defaults might be good enough. Perhaps we're worrying too much. Re-installing the system from USB takes only 3 minutes and is already being done very often. A boy just showed up on the door of the repair lab, saying: se borró el Navegador (the Browse activity deleted itself :-) All we need to do is make the backup-update-restore procedure slightly more automated so that kids and teachers could do it without bothering the technicians. Actually, we don't even need to worry too much for a solid backup and restore procedure. I've always suspected that most kids wouldn't care about preserving their diary. Now it's confirmed: kids are flocking here to get the new version of Sugar even though their journals are not going to be preserved across the upgrade. On the other hand, teachers and teacher trainers always ask to preserve the content of their journal. Technicians use a pair of simple shell scripts to tar up the journal to a USB stick, so they don't depend on being within the range of the correct school server. I'll summarize all these things in a field report asap. -- // 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] Children want Sugar 0.84, for the wrong reason
On Sat, 2010-03-13 at 08:33 -0500, Gerald Ardito wrote: By the way, how do you upgrade the XOs (we have XO-1s) to .84? This is a very big deal for us. We use a local variant of the F11-XO1 images by Stephen Parrish, signed with the deployment keys. The procedure for each laptop is: (1) backup the lease.sig to a USB stick (cp /security/lease.sig /media/PENDRIVE) (2) reboot while pressing all 4 game keys (3) wait for about 3 minutes to load the image (4) boot with the USB stick still fitted to re-activate the laptop If your laptops are unlocked, you can save steps (1) and (4) and you don't need a signed build. The procedure would become: (1) press ESC on boot to get to the ok prompt (2) type copy-nand u:\osNN.img (3) wait for about 3 minutes to load the image See my reply to Bert in this same thread for some considerations about Journal backup/restore. The scripts I mention in that post are available from our public repository, but atm I can't reach the office to retrieve the link. They're really crude scripts, no big deal. It would be really cool if someone could work on a bootable USB stick which would automatically perform full backups and restores. Not only it would save time, it would make students and teachers more autonomous from us techies. -- // 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] [IAEP] Children want Sugar 0.84, for the wrong reason
On Sat, 2010-03-13 at 10:46 -0500, Martin Langhoff wrote: On Sat, Mar 13, 2010 at 8:49 AM, Bernie Innocenti ber...@codewiz.org wrote: On Sat, 2010-03-13 at 08:33 -0500, Gerald Ardito wrote: By the way, how do you upgrade the XOs (we have XO-1s) to .84? This is a very big deal for us. We use a local variant of the F11-XO1 images by Stephen Parrish, signed with the deployment keys. How well is that build working, from a let's use it in the field PoV? Depends very much on who you ask to. Teacher / trainers: It deleted my stuff I can't learn it None of the new activities work We can't work any more with this new version This GNOME thing has many drawbacks GNOME prevents activities from working Children: Please install colored windows The new Sugar is faster How do I get to piecito? (little foot == GNOME) I like the screensaver ...many more... If you ask me: our recent F11-XO1 builds have reached equal or better quality than build 801, provided you disable automatic power management. Activities still need some bug-fixing, but nothing serious. I filed a bunch of bugs in the SL and OLPC trackers. I asked educators to send us clear and complete bug reports every time they see something odd, but all I've seen so far is distress calls, of course sent through private channels instead of the ones I suggested :-) I think this is all natural: non-technical adults tend to panic on the idea to replace something familiar with something that will force them to learn something new. This is the first time in their *lives* it happens, so we should be understanding. In less than 2 months, they'd be happy with this version and unable to use the old one. Hopefully, they will complain a little less on the next upgrade to 0.86 and 0.88... Until they finally get used to the idea that software tends to improve over time rather than getting worse. -- // 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] [IAEP] Children want Sugar 0.84, for the wrong reason
On Sat, 2010-03-13 at 12:07 -0500, Martin Langhoff wrote: On Sat, Mar 13, 2010 at 11:50 AM, Bernie Innocenti ber...@codewiz.org wrote: If you ask me: our recent F11-XO1 builds have reached equal or better quality than build 801, provided you disable automatic power management. Are all activities working, including collaboration? In Gnome, can you actually use FF? Camera? Hopefully, they will complain a little less on the next upgrade to 0.86 and 0.88... Until they finally get used to the idea that software tends to improve over time rather than getting worse. Or we slow down to a rhythm that they can cope with ;-)! Slowing down deployment of new versions might make things even worse! The more changes accumulate, the less familiar the new version will look like, and the more time the users got to get used to the experience provided by the old version, no matter how buggy it was. The Vista vs XP effect. The only way to reduce user adversity to change is getting them used to smooth change by providing a short development cycle with few changes that deliver clear improvements to the user experience in terms of new features or fewer bugs. The #1 bait we used to push this new release onto teachers was 3G support. Suffice saying, GSM connectivity is very popular in places with no wired broadband. Unfortunately, this wasn't quite true, bacause many popular Huawei modems use by default a Windows compatible mode in which they show up as mass-storage devices. After backporting udev to F-11, I found out that now users are being sold an even newer model of Huawei modem which is not yet supported by the Fedora 12 version of udev's rules. Teachers blamed the new Sugar for breaking their shiny new modems: they seem unable to distinguish between a regression, a bug in new feature, or an entirely missing feature. Heh... Anyway, now I found a temporary workaround and reported the missing feature upstream: http://bugzilla.redhat.com/show_bug.cgi?id=573250 Too bad it was so easy: support for new devices would have maed a major selling point for the next version of Fedora :-) -- // 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] Children want Sugar 0.84, for the wrong reason
On Sat, 2010-03-13 at 13:26 -0500, Gerald Ardito wrote: Where can I download this image? I've uploaded one of our builds here: http://people.sugarlabs.org/bernie/olpc/py-xo1/ It's slightly newer than the version we've been installing on children's laptops, and has been lightly tested. If you have trouble, I'll upload the exact same build (os65). I'm now testing build number 81, which has 3G support, but a couple of other regressions which I'm hoping to fix soon-ish. I also recommend testing Steven Parrish's os12, which looks good, besides a issue with NetworkManager. Steven has been focusing on reducing the build size while at the same time increasing the number of bundled activities. My builds are a little more conservative because my builds quickly end up in the hands of children and teachers. Steven and I had to work in isolation due to bandwidth limitations. Soon, we're going to compare nodes and merge our respective improvements into something more consistent. Testing and feedback from technical and non-so-technical users is crucial for us. -- // 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] [IAEP] Children want Sugar 0.84, for the wrong reason
Forgot to answer a paragraph: On Sat, 2010-03-13 at 12:07 -0500, Martin Langhoff wrote: On Sat, Mar 13, 2010 at 11:50 AM, Bernie Innocenti ber...@codewiz.org wrote: If you ask me: our recent F11-XO1 builds have reached equal or better quality than build 801, provided you disable automatic power management. Are all activities working, including collaboration? In Gnome, can you actually use FF? Camera? I've seen some users using Firefox, so it probably works well enough. I've noticed some annoying graphics artifacts on buttons, probably caused by a geode driver bug exposed by the gtk theme. I've been focusing exclusively on Sugar and core activities. Gnome is very popular among children, but I'm not particularly motivated in supporting it. Frankly, I also don't test Sugar beyond very basic functionality: networking, journal, browse... Not only I wouldn't have time to comprehensively test every activity, I also wouldn't do the same things that creative users actually do with them. Instead, I've invested on building a testing team form a small crowd of smart children who are using their laptops 6 hours a day. -- // 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] Status of 3G backport to 0.84
On Wed, 2010-03-10 at 08:17 +0100, Tomeu Vizoso wrote: We had trouble getting the code backported to 0.84 to work until we finally figured out that GsmPalette.set_status() was overriding a method with the same name in its superclass. An unfortunate naming clash. These situations suck, any ideas about how to avoid this? Normally we'd make private methods prefixed with an _, but this set_status() had to be called from outside. It's kind of a language design bug that you could implicitly override things without noticing. Other OOP languages such as Java and C++ share the same problem, but one would expect Python to apply the explicit is better than implicit mantra. Anyway, we worked it around by renaming our function to set_gsm_status(). Great news! Congratulations to all involved, it's a beautiful example of the Paraguay and Uruguay communities working together with the global community. Pity that the patch from Ceibal Jam's Andres didn't got in yet, maybe it will get backported later? https://bugs.sugarlabs.org/ticket/1630 Seems like a very useful addition, we'll look into 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
[Sugar-devel] Status of 3G backport to 0.84
Daniel_C erikos: yes, in that case we should make a backporting Daniel_C erikos: i know that martin and bernie were working in that sense erikos Daniel_C: yeah, I read that yesterday We had trouble getting the code backported to 0.84 to work until we finally figured out that GsmPalette.set_status() was overriding a method with the same name in its superclass. An unfortunate naming clash. Today we got the first connection! I'll spin a 3G enabled F11-XO1 build in a while :-) -- // 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] [Systems] ATTENTION: scheduled downtime of bugs.sugarlabs.org on monday
On Mon, 2010-03-08 at 10:03 +0100, Tomeu Vizoso wrote: One more: * move the localization mailing list from http://lists.laptop.org to http://lists.sugarlabs.org Ok. Sayamindu, shall we coordinate on this? We'd have to move the archives and add a forward rule for the old list administrative addresses. It's been already done for a bunch of lists, so you should find breadcrumbs on the laptop.org side. -- // 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] 3g dependencies
[cc += harald] On Mon, 2010-03-08 at 16:36 +0100, Tomeu Vizoso wrote: Yup, this is for documentation purposes, oriented towards packagers, distributors and deployers. They will do whatever they want, but we wanted to document these dependencies. Only OS-side dependencies that shouldn't concern Sugar directly. In Fedora 11, in addition to what we have already, we need an updated udev (version 145), which also depends on a newer usbutils (0.82). This is necessary to witch hybrid modems into comm mode. I back-ported both these packages from Fedora 12. I didn't notice any regressions so far. I've discussed this briefly with Harald Hoyer, who is both the Fedora packager and the upstream maintainer. If it turns out to be too risky for a F-11 update, we'll have to carry these two packages around in the custom repositories for F11-XO1 and F11-XO1.5. I've also backported all the 10 Sugar patches: http://git.paraguayeduca.org/gitweb/users/bernie/sugar-0.84-3g.git Plus two trivial sugar-artwork patches: http://people.sugarlabs.org/bernie/patches/sugar/sugar-artwork/0001-Add-network-gsm-icon.patch http://people.sugarlabs.org/bernie/patches/sugar/sugar-artwork/0002-eliminate-dupe-battery-charging-100.patch The backported patches have just been massaged enough to apply with no rejects. I tried to be diligent and not loose any bits in the process. Martin (tch) and I are have still not done any serious debugging yet. Wireless networking still works with these patches applied, and the modem control panel also works. 3G devices show up in the panel, but you can't connect just yet. -- // 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] 3g dependencies
On Mon, 2010-03-08 at 14:55 -0300, Bernie Innocenti wrote: In Fedora 11, in addition to what we have already, we need an updated udev (version 145), which also depends on a newer usbutils (0.82). This is necessary to witch hybrid modems into comm mode. Oh, and we have to add ModemManager to the build, of course. Plus two trivial sugar-artwork patches: http://people.sugarlabs.org/bernie/patches/sugar/sugar-artwork/0001-Add-network-gsm-icon.patch http://people.sugarlabs.org/bernie/patches/sugar/sugar-artwork/0002-eliminate-dupe-battery-charging-100.patch Wrong link. These are the correct ones: http://people.sugarlabs.org/bernie/patches/sugar/sugar-artwork/pending/0001-Add-network-gsm-icon.patch http://people.sugarlabs.org/bernie/patches/sugar/sugar-artwork/pending/0002-eliminate-dupe-battery-charging-100.patch -- // 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] [SLOBS] Oversight Board request: Not fully bundled .xo
On Thu, 2010-03-04 at 17:01 -0500, Benjamin M. Schwartz wrote: Aleksey Lim wrote: * the major issue here that ASLO is not particalr deployment oriented portal, e.g. in OLPC case, mentioned issue is mostly means nothing since OLPC can effectively add/remove any component they think is useful for their users I don't understand this claim. ASLO is seeing literally millions of downloads from OLPC deployments. Probably 99% of ASLO traffic is from OLPC's users. If we want Sugar's user-base to keep growing in the future, we need to keep our platform open and viable to users of different hardware. Hopefully soon, also OLPC is going to switch to a non-x86 architecture. It was clear from the beginning that fossilizing on a single immutable ABI (32bit x86 + Fedora 9 + Sugar 0.82) was going to be a dead-end. As for the rest... I think .xo bundles should be absolutely free of binary executables, or anything else that depends on more than the Sugar Platform. We should then introduce a different (better!) bundle format that supports such dependencies, based on 0bundle, 0install, etc. As a temporary codename, call it .x0. While I've always been advocating for using a package system in Sugar, I've not been doing any work in this direction. I'm enormously grateful to Aleksey for being a doer with his pioneering work on 0install. My only concern is that 0install seems to be itself another prototype packaging format, with plenty of crucial features still missing. For example, Aleksey was telling me last week that people build binaries on their personal desktops because there's not yet a real build cluster like Koji or Suse buildservice. Meanwhile, distros are repackaging our xo bundles into native rpms and debs... Are we sure we couldn't just sit and let the distros do their job? I'm convinced that the unprivileged installation issue is easy to overcome once we agree that native packages don't stink and are not more complicated than they need to be. -- // 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] [SLOBS] Oversight Board request: Not fully bundled .xo
On Thu, 2010-03-04 at 22:20 -0300, Bernie Innocenti wrote: If we want Sugar's user-base to keep growing in the future, we need to keep our platform open and viable to users of different hardware. Hopefully soon, also OLPC is going to switch to a non-x86 architecture. It was clear from the beginning that fossilizing on a single immutable ABI (32bit x86 + Fedora 9 + Sugar 0.82) was going to be a dead-end. I should have read the thread to the end before answering, so I would have noticed that you made exactly the same point before me :-) -- // 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] [Systems] [IAEP] Turtle Art on Activities.sugarlabs.org
On Sat, 2010-02-27 at 15:34 +, Aleksey Lim wrote: we can move in several directions at the same time, * web hosting, I'm more thinking about Moodle because hacking AMO will increase ASLO patch which could be wrong way to go since we don't have PHP coders involeved to ASLO coding We already have a Moodle instance running here: http://schools.sugarlabs.org/ I don't know if anyone is using it, and it may very well be an updated version at this time. Caroline could tell you more about it. If you need a development Moodle installation, just let me know. * sugar UI, we already have FileShare activity I'm working on Library-2 activity which should support not only server model but also per-to-peer sharing model (activity will have thumb view to make object browsing more useful) Very interesting... -- // 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] Update methods (Was: Root filesystem ran out of room in F11-on-XO1)
On Wed, 2010-02-24 at 18:13 -0600, Mikus Grinbergs wrote: If my suspicion is correct, then the ease of use of olpc-update (which depends upon /versions) needs to be balanced against the potential for shock if the XO-1 user runs out of room in the XO1 that much sooner. I'm afraid that olpc-update will never become usable in the general case. I find it hard to believe that users will be willing to sacrifice ~500MB of their flash to accommodate updates. In the field, it's a lot faster to flash a new image from USB and then restore the journal from backup. Today I found out that Esteban, a Ceibal developer, has been working on a backup to USB patch for the Journal. In Paraguay, we've been using two simple shell scripts to save and restore the journal across upgrades, but a proper UI would definitely simplify things for the technicians. -- // 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] Sugar 0.88 in F11-XO1
On Wed, 2010-02-24 at 17:50 +, Martin Dengler wrote: Sorry if it's been answered already: I wonder why you prefer 0.88 on F11 for XO-1 builds, rather than 0.88 (or latest) on F12 (or latest) for XO-1 builds? Stabilizing a new Fedora release on the XO-1 is likely to take more time than I can dedicate to it. If someone would like to champion an F12 effort, I'd be glad to help out. -- // 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] Sugar 0.88 in F11-XO1
(re-adding the lists) On Tue, 2010-02-23 at 06:55 -0600, Mikus Grinbergs wrote: But this thread is about F11-on-XO1. Meaning that yum ought to be defaulting to accessing the F11 repositories. I just now enabled the 'rawhide' repository for my F12-based XO1, and explicitly pulled down sugar-0.87.5-1.fc14.noarch.rpm from there. My point is that the Sugar dependencies may have been upstreamed -- but those not in the inner circle don't know WHERE (choose: in releases F12 or F13 or F14; in repos fedora or rawhide or update or update-testing). Luckily, all the dependencies mentioned in the 0.88 Roadmap were already available in F-11, but I've found a few more which weren't documented: python-decorator (in F11, but not in F11-XO1) python-dateutil (in F11, but not in F11-XO1) python-xklavier (not in F11, needs backporting) I'll build a public yum repo with the sugar packages and missing dependencies as soon as I find some time. Meanwhile, I've convinced rpm into installing the rawhide packages on Fedora 11. In this configuration the Metacity window manager crashes on startup for reasons yet to be determined. After restarting Metacity from the console, Sugar 0.88 showed up and appeared to work normally. -- // 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] Sugar 0.88 in F11-XO1
From today's #sugar-meeting: erikos bernie: I think a big problem to recruit 0.88 testers, is that there are no xo images erikos bernie: scratch builds, like tomeu said, sounds good erikos bernie: and then create a repo erikos bernie: maybe mtd is interested in that, too Ok, I'll create some custom F11-XO1 builds with the latest Sugar packages retrofitted for testing purposes. Who would like to help me out? Here's an initial draft: == Packages == Setup a yum repository with 0.88 packages backported to Fedora 11 (built in Koji with --scratch or inside an F11 chroot, whichever is easiest). It shouldn't require too much time, but it would be great if Fedora packages could offload this work from me and make the result available on people.sugarlabs.org in the form of a yum repo. Any volunteers? == OLPC OS Builds == Setup an olpc-os-builder environment to fetch Sugar from the above repo. I could easily do this at Paraguay Educa, but bandwidth to download the resulting builds is very limited here, and downloading images of over 500MB from my public_html folder is going to be painfully slow from the Internet. Perhaps I could duplicate the build harness on one of our buildbot slaves (in Italy) or a new VM on Treehouse. I doubt we can make olpc-os-builder work on Sunjammer, as it's quite Fedora specific. == Testing team == Test these builds with real kids. We have many kids with XO-1's in the nearby town of Caacupe, but school starts tomorrow and we cannot disrupt their regular classes too much. I think I could give an extra laptop to a small number of smart and motivated volunteers to test Sugar 0.88 side by side with 0.82 and 0.84 running on their regular XO. I've already identified a group of kids with a hacker attitude who would be perfect for the job. Educators tell me there are even a few kids who taught themselves to use the shell. Small teams of testers from other deployments would also be welcome, of course. == Collecting Feedback == Since Caacupe is 1hr away from the office, we'll teach our young testers to communicate with the IRC activity and/or through email. Getting them directly on #sugar may be problematic, but I don't want to send our testers to a /dev/null place where nobody would answer their questions. The best business practice to overcome language, cultural and age barriers would be to interpose support engineers. But the open source model requires a tighter feedback loop between users and developers. I don't speak much Spanish myself, so I'm counting on other community members to help out. As we're dealing with young people with little computing experience, we'll have to be tolerant and responsible. Hopefully, the increased confusion in #sugar will not bother technical members of our community too much. == Filing bugs == I'll try to file meaningful Trac tickets for our testers, possibly with logs and a pre-analysis. While our kids might not be able to report bugs on their own, Paraguay Educa has a few field technicians who could learn to do it. == Future opportunity: Fedora 12 == Optionally, try to upgrade to F12 or even F13. This would potentially introduce new distro bugs as well as the Sugar bugs. The benefit would be that we'd be working closer to upstream, but perhaps we'd be better off leaving the bulk of the distro hacking work to OLPC so we can focus our resources on testing only Sugar. == Future opportunity II: Usability testing == The Design Team often expressed the need to test proposed UI patches in the field. This is now possible to a certain extent, although with a limited number of testers. I could act as a dumb proxy: send me patches along with the feedback forms that you'd like the users to fill-in, or something like that. -- // 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] Master nameserver changed for sugarlabs.org et al.
Hello, as announced some time ago, I've moved the master nameserver of the following domains: sugarlabs.org sugarlabs.net somosazucar.org somosazucar.net olenepal.org pustakalaya.org The new master nameserver is ns1.sugarlabs.org, aka lightwave.sugarlabs.org, a virtual machine hosted on treehouse. The old master ns1.codewiz.org, aka trinity.develer.com, is now acting as a secondary slave. Access is regulated by the following (draft) documentation: http://wiki.sugarlabs.org/go/Sysadmin/Nameservers This change was supposed to be straightforward, but as usual it took me the entire day chasing bugs in slave configurations and notifies. Watch out for name resolution problems over the next few days! -- // 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] [Marketing] Fresh Sugar presetnations?
On Wed, 2010-02-17 at 15:50 +0100, Sean DALY wrote: Bernie I'm afraid I'm unable to upload the odp file, it fails each time without a message. Hmm... Perhaps you're hitting the size limit? How big is it? The PDF is there under the 2010 section. I will try to upload the odp again from another computer Thanks! -- // 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] Directory of sugar imagens
On Mon, 2010-02-15 at 19:12 -0600, Kevin Mauricio Benavides Castro wrote: hello to all the list of a few days ago I had that curiosity directory where images are saved on the XO sugar load in this case when it loads. could someone give me the directory where the images The sugar-desaro...@lists.sugarlabs.org list is meant for developers who speak Spanish. The core Sugar development list is sugar-devel@lists.sugarlabs.org -- // 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] [Marketing] Fresh Sugar presetnations?
On Thu, 2010-02-11 at 17:38 +0100, Sean DALY wrote: Hi Bernie hopefully I can upload soon a translated version of my prez from last week's L'Atelier day for the French press Not very technical though if urgent I can arrange a drop for you of untranslated OOo file ? Not urgent, but I don't mind French. I'd have to translate everything to Spanish anyway :-) Please, upload your presentatin to the usual place whenever you like: http://wiki.sugarlabs.org/go/Marketing_Team/Presentations -- // 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] Heads Up: Sugar 0.87.4 coming to Rawhide
On Thu, 2010-02-11 at 22:58 +0100, Sebastian Dziallas wrote: James Cameron wrote: On Thu, Feb 11, 2010 at 08:13:40PM +0100, Sebastian Dziallas wrote: Title says it all, it should be in tomorrows build. Briefly, how do I swing across to this on an OLPC XO-1.5 that is installed with an OLPC F11 build? (There are several problems I'm investigating where I'd like to be able to test a much more recent version of Sugar, and I've not set up an environment to do that in yet). You could do something like: yum --enablerepo=rawhide update sugar* This should work - in case it doesn't, you might need to update some more dependencies from rawhide, too. I'll mention that once you executed that command, it's hard to get back, though. So it'd probably be reasonable to just reflash the XO, if things go wrong. If the method suggested by Sebastian fails due to nasty dependencies, I'd be glad to backport the 0.86 or 0.87 packages to F11 for testers like you. Hopefully it won't take much time, just let me know if it's needed. -- // 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] Fresh Sugar presetnations?
For an upcoming talk, I'd like to remix some of my old Sugar presentations and include new technical and introductory information about SoaS and Sugar's core components. Can anyone point me at existing presentations from which I could shamelessly rip graphics and good ideas? -- // 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] Missing libxklavier-dev dependency on Karmic
On Fri, 2010-02-05 at 13:02 +0100, Tomeu Vizoso wrote: Please do so, I'm very interested on it but it's not in the review queue. Done: http://bugs.sugarlabs.org/ticket/1662 Sorry, I'll never learn our review process :) -- // 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] Missing libxklavier-dev dependency on Karmic
I've just ran sugar-jhbuild on a Karmic machine and a configure failed because libxklavier-dev was missing. Unfortunately, we did not take note of what module was failing, but I guess you can easily figure it out :) -- // 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] [Fwd: Re: club othello]
This error makes me think that the program is confused about where its $HOME should be: /usr/lib/python2.5/site-packages/sugar/graphics/combobox.py:93: PangoWarning: error opening config file '/root/.pangorc': Permiso denegado Rainbow is enabled (probably a very old version of it): reserved credentials (1, 10059) adding group: /usr/sbin/groupadd -o -g 10059 10059 groupadd: el grupo 10059 existe adding user: /usr/sbin/useradd -m -u 1 -g 10059 -c org.laptop.community.ClubOthello.1 -d /home/olpc/isolation/1/uid_to_home_dir/1 1 Creando el buzón de correo: El fichero ya existe dropping privilege to (1, 10059) Try disabling Rainbow to see if it fixes the issue: sudo rm /etc/olpc-security If the problem disappears, then I'm not sure if the fault is in the application, the Pang library, or in Rainbow. Michael would know better. On Thu, 2010-02-04 at 17:06 -0300, Jorge Saldivar wrote: mensaje de correo electrónico attachment (Re: club othello.eml) Forwarded Message From: Esteban Arias ear...@plan.ceibal.edu.uy To: Jorge Saldivar jorgesaldi...@gmail.com Subject: Re: club othello Date: Thu, 4 Feb 2010 12:35:19 -0200 te envio dos logs. El log 1 fue durante la primer vez, cuando entró al salón izq del primer piso. donde se le indica al usuario cómo jugar. y luego subiendo de piso al salón izq y cayo como te indiqué anteriormente. El log 2 fue la segunda vez que entré fui directamente al segundo piso y pasó lo mismo. saludos, Esteban El 4 de febrero de 2010 12:22, Jorge Saldivar jorgesaldi...@gmail.com escribió: Hola Esteban, Me fijo y te aviso Saludos.- -- Jorge A. Saldivar G.- -- // 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] Missing libxklavier-dev dependency on Karmic
On Thu, 2010-02-04 at 23:19 +0100, Sascha Silbe wrote: Can you be a bit more specific, please? The following options come to my mind: a) libxklavier-dev isn't installed because you forgot to install everything depscheck complained about b) libxklavier-dev isn't installed because depscheck didn't complain about it (please post output of lsb_release -irs) c) libxklavier-dev is installed, but python-xklavier doesn't like it. Me bad. I just forgot that jhbuild doesn't automatically check for dependencies on every run... as opposed to the configure script. Tomorrow I'll try uninstalling libxklavier-dev and run depscheck to ensure it properly complains. It almost certainly will. BTW, we've also got hit by the missing --enable-maintainer-mode in one of the sugar modules, for which I had posted a patch some time ago. I'll search for the bug in trac and ping 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] calling for volunteers (was Re: SOAS 2 problems)
On Fri, 2010-01-29 at 11:20 +0100, Tomeu Vizoso wrote: I don't think that nor OLPC nor SLs can do much against MS' press machine: http://www.scidev.net/en/new-technologies/digital-divide/low-cost-laptops-to-change-from-linux-to-microsoft.html But if from time to time OLPC's press releases could briefly mention Sugar, I think it could be great. Indeed. If we could even get to the point of announcing some form of official collaboration, I think it would benefit both OLPC and Sugar. -- // 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] Rainbow in F-11 and F-12
I'd like to import rainbow 0.8.6 in Fedora devel and backport it to F-11, for the purpose of getting it in the Paraguayan build, and maybe also in the F11-XO1 and SoaS, if there's interest. Anything important I should be aware of? -- // 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] Labeling connectors in Labyrinth
Hello Gary, Mary Gomez Go of Paraguay Educa asked me if it is possible to put text labels on the connectors between blocks. I don't think it's possible, but perhaps it's easy to add as a new feature? And here comes the actual question: would you have time to do 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] SOAS 2 problems
On Mon, 2010-01-11 at 11:36 -0500, Caroline Meeks wrote: I second what Jim says. I've had a lot of trouble booting from the boot helper with Blueberry. Bernie looked at this at the GPA and found a bug in Fedora related to video drivers. Bernie, was this bug reported? I think I may have found our bug: https://bugs.freedesktop.org/show_bug.cgi?id=22498 If it seems like a good match for our symptoms, I'll ping it and try to get the fix propagated to Fedora and then SoaS. Sorry I can't help in person, but I'm getting ready to depart from the US tomorrow. Can you help David see if he is having the same problem we saw at GPA? David's problem sounds like a different thing. I'd rather try to diagnose it interactively with him. I can be reached on #sugar (irc.freenode.net) as bernie, or on Jabber as ber...@codewiz.org . -- // 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] SOAS 2 problems
On Tue, 2010-01-12 at 15:16 -0500, Walter Bender wrote: On Tue, Jan 12, 2010 at 3:11 PM, Bernie Innocenti ber...@codewiz.org wrote: On Mon, 2010-01-11 at 11:36 -0500, Caroline Meeks wrote: I second what Jim says. I've had a lot of trouble booting from the boot helper with Blueberry. Bernie looked at this at the GPA and found a bug in Fedora related to video drivers. Bernie, was this bug reported? I think I may have found our bug: https://bugs.freedesktop.org/show_bug.cgi?id=22498 Good catch :) This rpm may already contain the fix we need: http://koji.fedoraproject.org/koji/buildinfo?buildID=149602 My hope is based on this particular changelog entry: * Wed Nov 25 2009 Dave Airlie airl...@redhat.com 6.13.0-0.13.20091125git8b28534bc - rebase to upstream with r600 speed ups and r100 fixes integrated. But there are a number of other bugfixes, too. Caroline, I believe you could install it on SoaS by doing: sudo yum --enablerepo=updates-testing update xorg-x11-drv-ati It should drag in a few more testing packages, that's to be expected. Good luck! -- // 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] SOAS 2 problems
On Tue, 2010-01-12 at 15:27 -0500, Bernie Innocenti wrote: Caroline, I believe you could install it on SoaS by doing: sudo yum --enablerepo=updates-testing update xorg-x11-drv-ati It should drag in a few more testing packages, that's to be expected. Good luck! I got more useful tips from the Xorg developers: airlied bernie: there have been a few bug fixes against rv100 recently airlied so if you can reproduce with 2.6.33-rc3 then we can probably tell airlied or if you can get a dmesg bernie agd5f: I found one bug that seems to match the symptoms: https://bugs.freedesktop.org/show_bug.cgi?id=22498 agd5f bernie: does turning off color tiling help? Option ColorTiling False bernie airlied: I asked our tester to install xorg-x11-drv-ati-6.13.0-0.20.20091221git4b05c47ac.fc12 and report back ( http://koji.fedoraproject.org/koji/buildinfo?buildID=149602 ) bernie agd5f: I don't have access to the machine any more... but I'll suggest caroline to try this too. thanks for the suggestion Installing an updated kernel on SoaS may be a little hard. Try first thesuggestion by agd5f: put a line like this in the Device section of /etc/xorg.conf: Option ColorTiling False If there's no such file at all, create one with these contents: Section Device Identifier Card0 Driver ati Option ColorTiling False EndSection Section Monitor Identifier Monitor0 EndSection Section Screen Identifier Screen0 Device Card0 MonitorMonitor0 DefaultDepth 24 EndSection Section ServerLayout Identifier Xorg server Screen 0 Screen0 0 0 EndSection -- // 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] SOAS 2 problems
On Tue, 2010-01-12 at 16:36 -0500, Bernie Innocenti wrote: Installing an updated kernel on SoaS may be a little hard. Oops: airlied bernie: the new kernel might be a better bet also airlied bernie: from koji for F12 Well, maybe not too hard after all. Try: sudo yum --enablerepo=updates-testing update kernel You can also meet airlied and agd5f on #xorg-devel or on #fedora-devel, as you can see they're very nice and helpful. -- // 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] karma repo is huge!
On Mon, 2010-01-04 at 14:28 +0545, Bryan Berry wrote: It is already over 127 MB and the .git directory is over 65 MB. There must be some giant individual files hanging out somewhere. I absolutely will have to repack this thing Try git repack -a -d -f --window=100 --depth=100 I don't know a good way to search the history for large files (or large deltas). I guess we could ask for advice on #git, though. -- // 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] g.sl.o issues for Karma and perhaps other activities
On Sun, 2010-01-03 at 08:29 +0545, Bryan Berry wrote: I am wary of experimenting when the gslo infrastructure is still in flux. I would rather stick w/ gitweb or cgit and then move to whatever becomes of gslo. Should we start w/ cgit or gitweb? An alternative to installing a local multi-repository interface just occurred to me. To solve the data transfer issue, git offers a pletora of bandwidth-saving options. One possibility is to let the Nepali developers clone from each other's repository: git clone --reference officemate.local:~bryanwb/src/karma \ git://git.sugarlabs.org/karma/mainline.git karma Alternatively, you could rsync the files to your local machine: rsync -aP officemate.local:~bryanwb/src/karma/.git karma-ref.git git clone --reference karma-ref.git \ git://git.sugarlabs.org/karma/mainline.git karma It doesn't matter if the reference repository contains unwanted changes or hasn't been updated for a while. Any good bits will be reused, and the rest will be fetched remotely. Other tips: * Never use the http protocol, as it is quite inefficient. * try passing the --thin option when you pull. The server-side will work harder to minimize file transfers. * Another way to speed-up initial cloning is to limit the number of revisions with --depth. It's usually not a big deal, unless your history contains lots of large files that were subsequently deleted. * If your history contains plenty of similar files, for example PNGs that have been merely moved around, you'd benefit by repacking your repository with larger --window and --depth parameters. You could repack locally and, when you're happy with the result, push it to Gitorious with git push --mirror. * If your history is badly messed up, you may edit it locally with a combination of the advanced git operations such as git rebase --interactive, git reset --hard and git commit --amend. When you publish the resulting edited history, people who had previously cloned from you will have to refetch. Needless to say, git's arsenal of history-rewriting commands is as dangerous as it is powerful. * the git:// protocol is probably slightly faster than using the ssh tunnel. You can easily switch between the two using git remote ... or by editing .git/config manually. Free git advice is available from me on #sugar, GMT-5 office hours. Next business day, on-site support contracts available on demand. Git is a registered trademark of Stupid Version Control Systems, Inc. -- // 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] g.sl.o issues for Karma and perhaps other activities
Sorry it took some time to answer this thread. I'm still recovering from a new year's eve in Times Square :-) On Sat, 2010-01-02 at 12:01 -0500, Wade Brainerd wrote: How badly do you need a user friendly repository creator like Gitorious? If it's not important, you can just use GitWeb which is trivial to set up. I guess the important thing to consider is that Git can handle distributing and merging *code* changes across as many servers as you want. But if you want the metadata like project descriptions updated, you'll have to setup cron or a manual process like that. Honestly, 60 projects doesn't sound like too much work to set up by hand on both servers, compared with the amount of work to actually develop the lessons... Setting up a project on g.sl.o only takes a minute or so. The problem with managing many repositories by hand is not just setting them up. Once you have plenty of people accessing these repositories, you'll need to implement fine-grained access control. The number of access requests probably grows very quickly, proportionally to the number of developers and repositories. Soon or later, your gitmaster will become buried in support requests. That said, Gitorious is a complex Rails application. Compared to other web applications, it was quite hard to deploy and maintain. Indefero (http://www.indefero.net/) sounds like a much simpler alternative that I would investigate. Finally, we've been planning to migrate to the Nokia instance of Gitorious for a while. We're currently waiting for management approval, for which I have no ETA. We'll ping them again after the holidays. Meanwhile, I would appreciate if someone would like to experiment with a fresher installation of Gitorious. Bryan, if you feel like working on it, I could create a gitorious account for you on Sunjammer. I'm open to other possibilities, too. It would be great if we could share our development infrastructure. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ PS: Bryan, you were right: Avatar was fantastic! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] PATCH: add a delete all function to physics
Hello Gary, today I had a great dinner at Mel's aunts and after dinner Mel's cousin and I hacked together this new feature for Physics. We tested on a previous version of the activity, but then we upgraded to the latest version available and -- oops! -- it does not work on x86_64 any more! :-) So here's what you get for not supporting my architecture. An untested patch! --- Physics.activity/tools.py.orig 2009-12-18 22:43:20.779933607 -0500 +++ Physics.activity/tools.py 2009-12-18 22:41:50.680806893 -0500 @@ -458,6 +458,23 @@ else: self.game.world.world.DestroyBody(tokill[0]) +# Destroy everything! +elif pygame.mouse.get_pressed()[2]: + +# Build a Python list of all bodies from the linked list returned by box2D +body = self.game.world.world.GetBodyList() +shapes = [] +while body: +shapes.append(body) +body = body.GetNext() + +# Destroy everything! Muhahahah! +for body in shapes: +self.game.world.world.DestroyBody(body) + +# Oops! Restore the ground which we eagerly destroyed :-) +self.game.world.add.ground() + elif event.type == MOUSEBUTTONUP and event.button == 1: self.cancel() def draw(self): -- // 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] [OLPC_Boston] Printer help needed!
(cc'ing the Sugar development list) On Sun, 2009-12-13 at 11:56 -0500, MacKenzie Sigalos wrote: Dear Boston, Hello Laptop Hello World (formerly One For All) is running a pilot with the 4th grade students at the Cambridge Friends School. We've been having some issues with printing, and despite having sent out our tech team, we're still in need of assistance! The students created projects on the XO and they are trying to figure out how to establish a wireless connection to print them. We showed them how to save Write documents as txt files that they can open with Word. The package that they needed to read the .odt files (what Write files are usually saved as) on the Mac was not on their computers and not compatible with their OS version. Can you provide more information about these Macs? On MacOS X, they may need to use NeoOffice instead of OpenOffice: http://www.neooffice.org/neojava/en/maindownload.php Although it seems that OpenOffice 3.1 now officially supports Mac OS X too: http://download.openoffice.org/other.html#en-US We couldn't get the printer working directly with the XO. They have an HP Photosmart C4500. According to openprinting.org it should work perfectly with Linux. We installed CUPS on two XOs, but we couldn't get the drivers working. The printer itself should be well supported by recent versions of Linux. I have an HP Photosmart C4280 which works perfectly also a scanner. If your XO is running an official OLPC build, it's an ancient version of Fedora from 2 years ago with some modifications that make installing extra packages somewhat harder. You may have better luck Even if you could get the drivers to work, there was no user interface in Sugar for printing documents. Printing never has been high priority in Sugar because we did not expect printers to be commonly available in the places where Sugar is commonly being deployed. Nevertheless, there have been some efforts in that direction: http://wiki.sugarlabs.org/go/Print_Support http://wiki.sugarlabs.org/go/Print_Support_Manual Kyoko, their Tech Director, mentioned that she had tried using a shared printer through the Mac that they have, but it didn't work. She also mentioned that the school was willing to buy a new printer if it was easy to set up. I don't think the problem is with the specific printer model. I'm quite confident we should be able to install OpenOffice on one of those Macs and print from it. I've been using OpenOffice even with an old iBook G4, over 3 years ago. If you have any advice or feedback, we would greatly appreciate your suggestions. The 4th grade teachers are at a standstill until we can figure this out! Hope it helped! -- // 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] [Systems] aslo - CDN
[cc += sugar-de...@] On Thu, 2009-11-26 at 08:44 -0600, dfarn...@sugarlabs.org wrote: Many people have access to the upload directory. We could mitigate this by using separate groups. We already use a soas group for soas. Besides, do the activity authors still need to upload source tarballs here? Couldn't this be done with Remora? If not, couldn't we set release tags on Gitorious and download the tarballs from cgit? I know release tarballs sometimes contain more files than just a git snapshot, but it would work for most activities. My thought is to start moving towards a staging directory layer. Individuals will have assess to specific staging directories. From there, a cron job can sync from staging/ to downloads/ . If the script just moves the files over without any additional checking, security would remain unchanged. One possibility is requiring all files to be gpg signed by the author, but this makes things quite complicated: most developers do not seem to be familiar with gpg, and we'd still have to come up with some fancy ACL system based on the gpg key. It would be much easier if Remora could be configured or extended to distribute all our source tarballs too. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ signature.asc Description: This is a digitally signed message part ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] sunjammer: machine reboot, Nov 29 15:00 EST
We need to perform a reboot of sunjammer.sugarlabs.org required to fix the nfs server. The service outage should protract for just a few minutes. Apologies for any inconvenience, -- // 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] Fwd: [Zero-install-devel] Summary of the chat on #sugar-meeting (2009-10-18)
FYI Mensaje original Asunto: [Zero-install-devel] Summary of the chat on #sugar-meeting (2009-10-18) Fecha: Sun, 18 Oct 2009 16:02:50 +0100 De: Thomas Leonard tal...@gmail.com Responder-a:: The Zero Install system zero-install-de...@lists.sourceforge.net A: The Zero Install system zero-install-de...@lists.sourceforge.net Sugar (http://www.sugarlabs.org/) is a graphical environment designed for children, as an alternative to the familiar office-destkop. It is intended to be used in places with very limited network access, and so has a heavy focus on peer-to-peer interactions. It is an open system, encouraging children to write and distribute their own software. It is often run on XO laptops (brightly-coloured laptops for children), which are fairly low-spec machines (256 MB RAM). Like ROX in 2003, they currently have a system of self-contained bundles which is easy to use, but which does not handle dependencies. Summary of the chat on #sugar-meeting (2009-10-18): Q: How do you deal with library variability between distros? A: For ABI-compatibility, if the distro packages vary too much then we ignore them and use our own. For package name variability, we allow the feed to list all the possible names. If we can't find the package because we don't know its name then again we just use the Zero Install version. We check packages rather than files because we need to know the version too (although checking the filename could work for the specific case of .so files). Q: Sugar wants to support multiple CPU types. Are fat bundles supported? A: There are two ways of getting software. Normally you get the feed and then download the right package for your system. However, 0export can create bundles with packages for multiple architectures: http://0install.net/0export.html [ However, importing a bundle only imports the bits you need. If you want to be able to give the program to someone else later without an Internet connection and with a different CPU type, then you'll need to keep a copy of the original, or change it so that it imports everything. ] Q: How does 0install handle build-time dependencies for source taballs? A: Source packages have a CPU type of src. Build dependencies can be flagged as build only or build and runtime. If you want runtime-only dependencies, your build process must add them to the resulting feed itself. See: http://0install.net/0compile.html Q: Would gcc be a dependency of a source package for a program written in C? A: Ideally, yes, but we don't have a gcc feed at the moment. [ Delight is based on gcc and works, though, so there should be no surprises here. ] Q: Does a source package compile to produce a binary package, or is it simply compiled and installed in one step? A: When you use a program, you may get told there are no binaries available. You have the option to compile from source at that point. Q: Are there any facilities for reporting compilation errors (or other obvious run-time errors) back to the author of a feed? A: Yes, except that currently they come to us instead of to the author. Examples are: Compile failure reports: https://sourceforge.net/tracker/?group_id=76468atid=905152 Run-time failure reports: https://sourceforge.net/tracker/?group_id=76468atid=929902 [ Compile failures prompt the user to report a bug, while run-time failures don't. Runtime bug reports include the version and digest of every dependency. Compile reports should too, but looks like I broke that at some point. ] Q: How do build-time variants work (options to ./configure)? A: We generally prefer to have all configuration work at runtime. Q: What sorts of programmatic interfaces does z-i expose? A: There's a Python API: http://0install.net/python-api/html/index.html Q: If a distro package is later installed, would it be possible to detect the redundancy as remove the redundant 0install package? A: Zero Install checks for dependencies on each run, so if the distribution package disappears then it just behaves as if it was never there and prompts you to download a suitable version. Currently, we're not at all smart about garbage collecting unused packages (you have to select them manually). Sugar would probably check for unused packages at start-up and remove them. Q: What's the startup performance penalty of checking for the dependencies? A: About 0.1s on my laptop. [ Actually that was on my old laptop. Measuring it again, ROX-Filer starts 0.04s faster when not using Zero Install. Edit starts 0.02s faster. ] We have thought about caching the results and having a C launcher quickly check that they were still valid, but so far speed hasn't been an issue. Q: How did you become or find such talented documentation writers? :) A: :-) Q: We are very much concerned with deployments that lack internet access. Has anyone considered the issues involved with P2P 0install on a LAN, or with a local proxy server? A: p2p on a LAN
Re: [Sugar-devel] Zero-calorie bundles?
El Thu, 15-10-2009 a las 19:18 +0200, Martin Langhoff escribió: Ok - that's good. I am familiar with the limitations we are hitting with rpm and dpkg. What I truly wonder about is things like 'autopackage' and klik. See also the 'see also' section in http://en.wikipedia.org/wiki/Zero_Install It would be great if someone (Michael?) could approach them and invite them to next Saturday's IRC meeting to confront ideas (i.e.: megaflame). A while ago there was some serious discussion of the issues with these 'non-OS' pkg managers. Here is a tip of the iceberg - http://www.licquia.org/archives/2006/03/11/autopackage-goes-insane/ The discussion was heated, and sprawled across blogs. Good points were made. Before taking on something like z-i... it'd be worth understanding the good, bad and ugly and how it applies to us... I've read through this interesting saga, including the wiki page that triggered it, which has moved here since then: http://trac.autopackage.org/wiki/LinuxProblems My thinking is that Autopackage the folks are trying to solve an unsolvable problem: 100% binary compatibility across different Linux distributions (or different versions of the same distribution). They will FAIL. And even if they'd succeed, they'd FAIL later on as the x86 becomes less and less ubiquitous as x86-64, ARM and maybe MIPS gain market share. It's a slow, but unstoppable process. In a truly open market in which at least 3 or 4 architectures compete on more or less equal ground, one could as well accomodate a few more build variants for each architecture for the sake of the various OSes and their evolutionary needs. Getting the Zero Install folks involved may bring in fresh expertise They'll know about z-i, not about the needs of Sugar or its users... hence the perspective I am mentioning. Agreed, we should also hear from all the others. Well, perhaps not from the Autopackage crowd, since we already know they FAIL. :-))) -- // 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] [IAEP] ASLO updates
[cc += dfarning, alsroot, syst...@] El Wed, 14-10-2009 a las 17:47 -0700, Josh Williams escribió: I've made some bug fixes to the new ASLO design, I've tested it lightly and it seems to work in all major browsers (even ie6). If you have a few moments, please test it out (download/upload activities, browse around) and let me know if you see any display bugs or major usability issues. http://activities-devel.sugarlabs.org/en-US/sugar/ All links to activity bundles appear to be broken :-( For example: http://activities-devel.sugarlabs.org/en-US/sugar/downloads/file/26072/xpi/labyrinth-7.xo?src=addondetail I'm not sure how to fix it, but I can imagine that it may be related with moving the activity bundles from their old location (/srv/www-sugarlabs/activities/files) to the upload directory (/srv/upload/activities/) done by Dfarning in order to enable Mirrorbrain. Earlier today, alsroot asked me to fix some permission issues that would prevent aslo from writing new activities in the new location. Now I'm also noticing that there's still a copy of the activities in the old location, and it is also bigger by 40MB! /me is very confused :-/ Could anyone who was involved please write a short description of what was changed exactly? I'm only trying to reconstruct the current situation, not looking for a scapegoat. Hmm... well, perhaps we can learn something from this accident: The classic way to avoid the too many cooks syndrome would be to appoint a single official maintainer and make all the change requests go through him. However, I feel this solution would create lots of critical roles and ultimately defeat our ongoing attempts to decentralize system administration. Instead, we shall establish simple procedures to improve sysadmin coordination and communication. For example: 1) commit configuration changes in git along with a short description of what was done and why. We already have repositories for /etc and also and we could create more repos as needed; 2) write a short report for systems@ when we make substantial changes to a service; 3) write or update the wiki documentation for important sysadm procedures such as installing a new instance of a service Use your common sense to decide what needs to be documented and how much detail is needed. At all costs, we want to avoid putting too much bureaucratic burden on volunteers because it's the most effective way to make them look for something more exciting to do. We could save time by coalescing steps (1) and (2): all we need to do is enabling a post-commit hook in the repositories that would send patches to systems-logs@ . We need to be extra careful not to expose passwords in this way. Any volunteers to write and test this procedure? -- // 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] [Zero-install-devel] Zero-calorie bundles?
El Tue, 13-10-2009 a las 20:47 +0100, Thomas Leonard escribió: How about getting together on IRC to exchange ideas regarding packaging strategies? I'd propose next Saturday @ 1500UTC [2], of course negotiable. Sounds like a good idea. Having a repository for Sugar-related apps makes sense and we can certainly help you with that. I'm sure you'll have useful feedback, and integration with Rainbow would be interesting. I'll try to join the IRC if I'm around. I forgot to mention the channel: #sugar-meeting. I'm not sure it solves our hosting problem, though, if the hosting is only for things relevant to Sugar. What kind of policy are you thinking of? We can offer abundant disk space and bandwidth to serve other Zero Install packages, as long as they are Free Software as defined by the FSF, since we are their guests. -- // 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] Zero-calorie bundles?
El Thu, 15-10-2009 a las 10:32 +0200, Martin Langhoff escribió: I think it's a very good idea to look into a userdir-centric packaging system such as z-i. There are of course a few other alternatives, and very well considered critiques of these systems (from OS-centric packagers usually ;-) ) so we don't have to hope we've diagnosed all the potentiall pitfalls -- others have. So a couple of questions -- out of curiosity, no intention to start a flamefest. - Is anything making z-i specially interesting? Honestly? I think the most interesting feature of Zero Install is that it has an active development community working to solve the same hard problems that we are facing with our XO bundles. RPM and Deb have even stronger development, of course, but they're focusing on different usecases and they also seem to be too associated with specific distributions. - What pitfalls will our individual end users and deployment teams face with it? I'm not sure how to answer this question, yet. Getting the Zero Install folks involved may bring in fresh expertise offering new ways to solve the problems on which we have been stalling for years. Let's give them a chance to prove their ideas. -- // 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] [IAEP] ASLO updates
El Thu, 15-10-2009 a las 07:34 +, Aleksey Lim escribió: We just tried to utilize AMO feature when it lets user download public .xos from mirror sources and from files/ for other cases. Recently all .xo were downloaded from files/(even after creating symlink in /upload to files/).. and it was done from several attempts. Hmm... I'm not sure Mirrorbrain would still work if you symlink away from the /srv/upload directory where it is active. To check, use wget on one of the URLs: you should see a 302 redirect before the download starts. Btw, we should start to get psychologically ready to move aslo to beamrider in the future or, better, cluster it on both machines. We could save time by coalescing steps (1) and (2): all we need to do is enabling a post-commit hook in the repositories that would send patches to systems-logs@ . We need to be extra careful not to expose passwords in this way. Any volunteers to write and test this procedure? Well, we don't need such ASLO specific administration 24x7, most of time it could be just regular file-permissions/apache/etc administration. Ok. For now we'll limit it to /etc only. -- // 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
