Re: [Techteam] Adding a Next release milestone in trac
On Sat, Jun 21, 2008 at 6:12 AM, Michael Stone [EMAIL PROTECTED] wrote: On Fri, Jun 20, 2008 at 11:54:44PM -0400, Kim Quirk wrote: Can we use a combination of milestones and tagging? Seems like a fine idea to me. I have the same concerns Kim expressed, so totally agreed on this one. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making speech-dispatcher python API support asynchronous socket communication
Hi, Thank you all for your ideas. @Tomeu : I looked into the gobject.idle_add and luckily Tomas has an example for me too :). I will be trying that out next. @Tomas: I was facing a similar problem there and I solved it by passing all callbacks to the gidle thread. All SD communication is performed from the GUI thread, but the callbacks don't perform any actions themselves -- they only schedule these actions to be performed within the idle thread. It works surprisingly well. Hmmm, would this mean that if I got a WORD_SPOKEN event notification then the callback to be executed for this event will be executed immediately? If that happens then I guess the solution would be pretty nice. Could it be possible that such event notifications become queued and get executed much after the word has been spoken ? (Developers in the OLPC community would be very interested in providing a karaoke style hightlight effect during speech synthesis in their gtk activities). @Hynek: This really seems like the former problem with socket functions behaving in a strange way in threads with pygtk unless the gtk.gdk.threads_init() is called. The current sample implementation you've sent in the attachment still partly uses threads (through speechd) but doesn't call this function, which now looks likely to cause the problems. Precisely it is and the OLPC community would be interested in providing the solution to the problem at the API layer instead for two reasons : 1. Simplifying the process for the activity developer 2. Avoiding the use of threads Now, what are the reasons why you want to avoid using threads? I had a discussion in the olpc irc channel and the reason for avoiding threads given was that the laptop uses a Suspend and Resume feature for power saving and using threads within the gtk activity would prevent the laptop from suspending. This should be considered carefully as not to create problems later when for instance we want to switch from a text socket protocol to something else. Because if I understand correctly, the proposed solution would necessarily be based on exporting the socket file descriptors in use to the client program. The present diff that I have provided does *not* expose the socket to the client program. It simply uses the speechd thread for handshaking and shifts to async communication after that... (It does not work thats a different thing..) I will try using the gobject.idle_add approach next and see if I make any headway in that direction now. Thanks, Hemant ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
Hi - On Sat, Jun 21, 2008 at 12:41:52PM +0200, Bert Freudenberg wrote: [...] (Sorry, this is probably OT for this list.) Considering the age of this smalltalk-derived image, is there some reason to be convinced that it contains no code/data other than that could be regenerated from sources today? [...] [...] The images contains instances that were created interactively for which there is no source code. I'm not entirely sure how many of these instances there are, but it's not only a few for sure. It would be a huge undertaking, for no obvious benefit than to satisfy those who erroneously believe source code must come in text files. [...] I was trying to hint at another (non-quaint) reason for that. How could someone be sure that such an image contains no malware; no hidden code that only pretends to run the embedded source code? This is one of the fundamental benefits of bootstrapping: one knows exactly what's in there. [...] Anyway, the Debian ftpmasters [...] were concerned about how to be sure what changed from one image to the next. Squeak comes with all the necessary tools built into it, but this does not work well with their established work flow. Plus it requires them (and users) to run the tools embedded into the possibly suspect image in order to describe itself. Do you see how there could be a trust problem there? - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Sucrose 0.81.3 Development Release
The new Sucrose 0.81.3 Development Release is out! The release has several cool new features. Manual reordering of the Home icons and a freeform layout, improved feedback on activity startup, support for custom certificates in Browse, alt+tab activity switching, just to cite some. We are now in feature freeze and the focus will switch on testing, bug triaging and fixes. I'm proud to say that we achieved practically all the features that we had targeted, I want to thanks everyone that made this possible. Checkout the detailed release notes: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.3 We created a sugar-jhbuild branch for the release: http://dev.laptop.org/git?p=sugar-jhbuild;a=shortlog;h=sucrose-0.81.3 Package and images will be made available in various forms in the next few days. In behalf of the Sugar community, Your release team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Issue with activities using sounds and invite and power adapters
If you run the Measure activity and then follow with the Record, the screen (digital camera output) is blank. Thanks for pointing this out. This is a known issue as documented in #3616 and #5500 (Please note however that switching from home view to record activity even while Measure may be in background will bring back video/audio in Record. i.e. Measure-home-record-home-record will work fine. Just a workaround) Thanks, Arjun -- Arjun Sarwal http://dev.laptop.org/~arjs http://youtube.com/watch?v=SwcSEcfR464 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
On Sat, 2008-06-21 at 08:47 -0400, Frank Ch. Eigler wrote: Plus it requires them (and users) to run the tools embedded into the possibly suspect image in order to describe itself. Do you see how there could be a trust problem there? Note this is no different than any time you use a compiler binary provided by someone else... The attack is just as complete... http://cm.bell-labs.com/who/ken/trust.html - Jim -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making speech-dispatcher python API support asynchronous socket communication
Hello, Now the main problem: the gobject method does not seem to run the callback to read data from the socket when data is written to the socket. (I tried to test the socket monitoring method in a separate script and it worked fine then). If the API implementation is not able to read data from the buffer it blocks or deadlocks... This really seems like the former problem with socket functions behaving in a strange way in threads with pygtk unless the gtk.gdk.threads_init() is called. The current sample implementation you've sent in the attachment still partly uses threads (through speechd) but doesn't call this function, which now looks likely to cause the problems. Now, what are the reasons why you want to avoid using threads? I thought the former problem with strange behavior of recv() was solved by the above function. It seems to me a clearer solution to just let the speechd SSIP bindings do their work in their own thread than to extract part of the internals into your program (the socket selects). This should be considered carefully as not to create problems later when for instance we want to switch from a text socket protocol to something else. Because if I understand correctly, the proposed solution would necessarily be based on exporting the socket file descriptors in use to the client program. This is just my thoughts at the moment. I'm not entirely clear about what are the exact concerns and what would be the best way forward, so I'm open to explanations and suggestions. If there is a good reason to avoid threads, we should look for a way to do it. With regards, Hynek Hanke ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
OLPC XO Opera browser as Sugar activity
Hi All, I run Opera on the XO, but if started as an activity it doesn't run (it runs fine when started from terminal). There is a note on the Opera install page that there is an incompatibility between Rainbow and Opera: Note: There is at present an incompatibility between the Opera activity and the OLPC Rainbow security system on some builds. If when you launch the Opera activity, the screen goes blank and stays blank, you have likely encountered that incompatibility. http://wiki.laptop.org/go/Opera That is the symptom I encounter. Could one of you tell me what this incompatibility is, and how to remove it? I'm using build 703, the latest stable build. -Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
man command vs content bundle
http://wiki.laptop.org/go/Man I understand that man is excluded to save on space on-board. But for those who need/want man pages a content bundle should be created. Also, if man were recompiled to look at the location said content bundle would be installed, the actual man command could still function if the bundle were installed. I drafted up a page for this idea on the wiki (and to notify people that man isn't installed). Please post any questions comments concerns at the Talk: page. Seth ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making updating easier
Sounds great! We've discussed a similar thing here, but I don't believe there has been any time for that. For g1g1 people there could possibly be 2 options - 1. Upgrade from 656 to 8.1.1, with the automatic second step of adding activities; or 2. Cleanstall to the 8.1.1 build that already includes activities (a signed candidate for this is available today). If we can keep the upgrade or cleaninstall very simple, that would be great! Thanks for any help any can bring to this! Kim On 6/21/08, Christoph Derndorfer [EMAIL PROTECTED] wrote: Hello all, one of the things that repeatedly came up during a greet meetup at Friends Community School near DC which we had earlier today was that updating the software on the XOs was still too painful for many people. So especially with G1G1 2008 looming on the horizon I'm thinking that it might make sense to come up with an easier way to update the software. Some of the potential solutions discussed are * adding a separate activity that basically acts as a simplified gui for olpc-update, allowing users to upgrade to the latest signed software-builds (with an option to include release candidates) * integrating update functionality into the sugar-control-panel * adding a gui for Bert Freudenberg's script What do you guys think? Cheers, Christoph -- Christoph Derndorfer Co-Editor OLPCnews, http://www.olpcnews.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Sent from Gmail for mobile | mobile.google.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making updating easier
On Jun 21 2008, at 20:10, Kim Quirk was caught saying: Sounds great! We've discussed a similar thing here, but I don't believe there has been any time for that. For g1g1 people there could possibly be 2 options - 1. Upgrade from 656 to 8.1.1, with the automatic second step of adding activities; or 2. Cleanstall to the 8.1.1 build that already includes activities (a signed candidate for this is available today). I've been thikning about update issues a bit and was wondering if we have plans/processes in place to handle maintaince of multiple releases? Meaning that when we release 8.2, will we still provide bug fixes and security updates to 8.1.1 users or are we expecting everyone to move forward to 8.2 and just EOL 8.1.x? Thanks! ~Deepak -- Deepak Saxena [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] Adding a Next release milestone in trac
On Sat, Jun 21, 2008 at 6:12 AM, Michael Stone [EMAIL PROTECTED] wrote: So if someone puts 'Groups' into Milestone 9.1.0; you might also tag it with rel-9.1.0:? because it is undefined and therefore not clear that can make that milestone without a lot more attention. As it gets broken down into smaller parts, some of those features might get rel-9.1.0:+ and some get -. Just so. There seem to be agreement about this, who do need to ask to create the milestone? I guess it should be Update.3 (9.1.0), following the current naming convention. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] Adding a Next release milestone in trac
On Sat, Jun 21, 2008 at 9:07 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Sat, Jun 21, 2008 at 6:12 AM, Michael Stone [EMAIL PROTECTED] wrote: So if someone puts 'Groups' into Milestone 9.1.0; you might also tag it with rel-9.1.0:? because it is undefined and therefore not clear that can make that milestone without a lot more attention. As it gets broken down into smaller parts, some of those features might get rel-9.1.0:+ and some get -. Just so. I would recommend minimizing the amount of syntax required for tagging: 9.1.0 9.1.0:? 9.1.0:+ 9.1.0:- seems sufficient to me. Thoughts? There seem to be agreement about this, who do need to ask to create the milestone? I guess it should be Update.3 (9.1.0), following the current naming convention. I don't see any benefit, personally, in dragging the update.x nomenclature forward. It oversimplifies release versions in the same way that monotonically increasing integers oversimplify activity versions. The more precise we can be about the way we name things the better off we'll be, especially if the tagging scheme depends on this agreed upon naming. Should we also clear out old milestones once they have been passed? Once a milestone has passed, we should take it upon ourselves to re-triage any tickets left in it, at which point it could simply disappear. Another alternative, which might actually prove better in the long run, would be to name the milestones 8.2 and 9.0 (or 8.2.x and 9.0.x), such that their scope is slightly more general, thus allowing the tagging scheme to manage the least-significant version number. In this manner, after releasing 8.2.0, we can simply re-tag any bugs in that milestone which we expect to go out in future bugfix releases as 8.2.1 etc. (leaving them in the 8.2.x milestone), or push them out further to 9.0.x milestone instead. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC XO Opera browser as Sugar activity
I run Opera on the XO, but if started as an activity it doesn't run (it runs fine when started from terminal). There is a note on the Opera install page that there is an incompatibility between Rainbow and Opera: Note: There is at present an incompatibility between the Opera activity and the OLPC Rainbow security system on some builds. If when you launch the Opera activity, the screen goes blank and stays blank, you have likely encountered that incompatibility. http://wiki.laptop.org/go/Opera That is the symptom I encounter. Could one of you tell me what this incompatibility is, and how to remove it? I'm using build 703, the latest stable build. I haven't used Opera lately. If it was working pre-700, this is probably a case of isolation failing. Try: rm /etc/olpc-security followed by a reboot. To reenable isolation: touch /etc/olpc-security and reboot. Good luck, Bob ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
