Re: [Sugar-devel] Clocks on XOs
On Tue, Jul 06, 2010 at 04:36:55PM -0600, Daniel Drake wrote: PS: I just found yet another laptop which won't activate because the clock was set to 15 July 2000 (not 2010!). Do you see many of these? This was probably a human error in the Fix_clock repair process that happened on that laptop. from my understanding of the 'fix clock'/rtc issue, the clock would go back to about 1970? and not something as recent as 2000. -- | .''`. == Debian GNU/Linux ==.| http://kevix.myopenid.com..| | : :' : The Universal OS| mysite.verizon.net/kevin.mark/.| | `. `' http://www.debian.org/.| http://counter.li.org [#238656]| |___`-Unless I ask to be CCd,.assume I am subscribed._| ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: Bernie wrote: On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: I think you are missing an important requirement: installation without elevated permissions. Rainbow has been bit-rotting for the past 2 years Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still received no independent testing despite repeated calls for same. Rainbow, on the other hand, has seen a major new release, feature development that spurred new work in general Linux sandboxing, and is now available in more distributions than ever before thanks to dedicated support by folks like Luke, Sascha, and Jonas. Finally, if rainbow itself now receives little day-to-day attention, this is because it mostly does what its authors require and it does it well enough not to require their continued hand-holding. To be honest I wasn't a fan of rainbow a bit time ago.. But having Zero Sugar fully implemented and potential possibility to launch almost any piece of software - compile on demand is a regular workflow within 0install (existed sugar doesn't not let such possibility:), rainbow should be more then essential requirement. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Depending on Python 2.6 (was: Re: [PATCH 1/3] Add models for detecting and parsing the providers DB.)
Excerpts from Tomeu Vizoso's message of Tue Jul 06 11:01:44 + 2010: Using 'with' like that makes us depend on Python 2.6. Adding the following code makes with work in Python 2.5: from __future__ import with_statement I have nothing against bumping our dependency from 2.5 to 2.6 but this should be discussed separately so people can give their opinions. We should avoid to depend on Python 2.6 unless it provides actual benefits. The switch from Python 2.5 to Python 2.6 was a pretty major one for distros. I don't know how many of them are still on 2.5 (Debian has 2.6 as default for only a few days now and they're still sorting out issues with packages broken by the switch). Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Uruguay violates GPL by deleting root on OLPCs
Please, when you say Uruguay you should just say Plan Ceibal. Has anyone formally requested Plan Ceibal to correct this situation? Thanks, Gabriel 2010/7/7 John Gilmore g...@toad.com: Ignoring the fact that some deployments ship without root access. Is the practice of completely locking-down the laptops something we'd even want to encourage? Shipping the laptops TiVoized like Uruguay does has put them into serious legal trouble. OLPC should definitely not encourage anybody else to do this. Why bankrupt your project by losing a copyright enforcement lawsuit? Shipping the laptops without root access is a direct violation of the GPLv3 license on a dozen packages (probably 50+ packages in later Fedoras). They have shipped binaries, while using technological means to deny the recipient the practical ability to upgrade or replace them with versions modified or chosen by the recipient. Only an idiot would distribute hundreds of thousands of units while setting themselves up to pay the Free Software Foundation any amount of money they demand. (Given the way OLPC and Uruguay have ignored the notice that they're in violation, for years, I do hope FSF extracts both future compliance, and its next ten years of operating expenses, from these scofflaws.) Or does Uruguay think, Sue us for copyright violation in our own courts -- we'll make sure you lose?? In other words, do they just brazenly steal the GNU Project's software, knowing it's wrong? John Gilmore ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
Aleksey wrote: On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: Bernie wrote: On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: I think you are missing an important requirement: installation without elevated permissions. Rainbow has been bit-rotting for the past 2 years Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still received no independent testing despite repeated calls for same. To be honest I wasn't a fan of rainbow a bit time ago.. But having Zero Sugar fully implemented and potential possibility to launch almost any piece of software... rainbow should be more then essential requirement. Let's be clear: the actual requirement is for something more like safety or isolation. Rainbow is merely one of several reasonable approaches -- and competition and interoperability would be no bad thing here. Michael P.S. - Several other isolation shells that might be worth thinking about, if only to better understand the tradeoffs that rainbow makes, are briefly described at http://sandboxing.org P.P.S. - Also, either way, thanks for your encouragement. :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
On Tue, Jul 6, 2010 at 10:14 PM, Bernie Innocenti ber...@codewiz.org wrote: And that there are efforts to solve that in the future. Oh, I was unaware of this. Who is working on it, and what's the exact plan? http://dev.laptop.org/ticket/9564 Now, folks, please be careful here with all the exaggeration and drama. This list is full of people who don't understand humour or exaggeration. And who don't necesarily understand that security is never absolute, never perfect. Our antitheft scheme doesn't work in a vacuum -- it only works as a social device, to strongly discourage theft and grey-market sales. Tradeoffs is what it's all about. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Uruguay violates GPL by deleting root on OLPCs
On Wed, Jul 7, 2010 at 5:32 AM, John Gilmore g...@toad.com wrote: Shipping the laptops without root access is a direct violation of the GPLv3 license on a dozen packages (probably 50+ packages in later While I understand and agree with the spirit of what John wants, direct violation is a strong thing to say. Is it true? If you can get the src, compile and install and use the GPLv3 software. A quick check of old official images that I have around shows very few gplv3 packages, all of them things that I can easily recompile and put in my ~/bin, tweak my PATH envvar, and use from there. these scofflaws These scofflaws are trying to protect kids from theft, John. Userbase 6 to 12 years old. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Python help
I'm writing a python program for sugar and i recently added a line at the top 'from sugar.activity import activity' and now every time i run it i get a glib.GError:Failed to contact configuration server;.(lots of text) i can't seem to figure out what this means. can anyone point me in the right direction? Thanks :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Rainbow
On Wed, 2010-07-07 at 01:18 -0400, Michael Stone wrote: XO and SoaS distributions are configured for sudo with no password. Yes. However, Uruguay does not maintain this configuration choice. I'm very sorry about this. Rainbow has been bit-rotting for the past 2 years Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still received no independent testing despite repeated calls for same. Raul and I would have liked to resurrect Rainbow in time for F11-0.84, and then for F11-0.88. We asked a couple of times about the current packaging status and what patches still need to be applied in Sugar, but it seemed that there was still too much integration work to be done. and nobody volunteered to work on it. If you check the dates carefully, you'll find that most of my recent work on rainbow and rainbow/sugar integration has occurred while I was on vacation from my real job. So please do count that as volunteer hours. Don't get me wrong, your volunteer work to enhance Rainbow is much appreciated, but it is not by itself sufficient to get Rainbow to work again with Sugar. There seems to be the need for someone who'd be willing to do the missing integration work. People with both Sugar and Rainbow expertise aren't that common. Sure. And if, by some miracle, Sugar ever becomes *worth* attacking [1], then we will all rue the day when we had the opportunity to make it safe and chose not to. I wouldn't worry very much: the attack surface of Sugar from the public Internet is very small: basically, just xulrunner. The LAN of an elementary school is relatively free of advanced crackers. This leaves out only unusual Sugar instances that are being used from home networks connected directly to the Internet. The worst attack vector I can think of would be a malicious activity. I think this is pretty much the same threat of malicious Firefox plugins, and it is being taken care of exactly in the same way. If it becomes Perhaps I'm not being paranoid enough... but anyway, if the situation worsens, we could always restore Rainbow and/or check gpg signatures on installation, like most Linux distros do. A non-privileged account can already effectively do anything that a spammer would like to do. And when will you be shipping my prctl(PR_DISABLENETWORK) kernel patch? (Or have you a better approach?) I thought the review got swamped on lkml a long time ago? Or maybe I was dropped off the cc list... Last thing I know, there was disagreement about what the correct approach was and some linux hackers derailed the thread by invoking the stackable LSM bullshit. What matters the most is that nobody thought that the scenario that your patch was trying to address wasn't an interesting one. You might have a chance to get *some* version of your patch approved if you aggressively reply to the nonsense reviews asking the reviewer: - how would you do it instead? - does your alternative effectively address my use-case? - you and X sent conflicting feedback, please sort it out among yourselves and let me know which approach is preferred - who is the authoritative maintainer to ack a patch like this? In a case like yours, the technical side of getting the patch right is very easy compared to mediating among conflicting design goals. I am still much more satisfied with the approach taken by 0install. [2] 0install is a huge leap forward compared to the crap xo bundle format, but still too much prototypal to cover half of our requirements. The biggest flaw is that there's no well-defined build system to obtain binaries from sources, so activities authors would have to setup multiple environments and build manually for all the architectures we intend to support. When you add a new architecture, it takes months or years before most activities become available for it. I've been advocating a proper build cluster for years. Now that OLPC is working on an ARM-based platform, it will be clear to anyone why it was 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] gconf: sugar - gnome
Hi, Do you think that is better use same keys gconf on sugar and gnome to maintain the same configuration? For example, to set mouse keys on sugar, I should use: '/desktop/gnome/accessibility/keyboard/mousekeys_enable' or '/desktop/sugar/accessibility/keyboard/mousekeys_enable' ? Or, to set mouse theme, I use: '/desktop/gnome/peripherals/mouse/cursor_theme' or '/desktop/sugar/peripherals/mouse/cursor_theme' ? I would use /desktop/sugar/ on sugar and /desktop/gnome/ on gnome... because are differents ambients. Esteban. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.84.11
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.84.11.tar.bz2 == News == * Cannot delete stalled download from journal #1987 * Do not fail if activity mime_type was already installed #1394 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Uruguay violates GPL by deleting root on OLPCs
On Wed, Jul 7, 2010 at 3:42 PM, John Gilmore g...@toad.com wrote: The laptops refuse to boot a developer's version of Linux. They require a signed kernel and initrd. Some people call this DRM; it's definitely TiVoization (check Wikipedia if you don't know the term). I think it is a very well understood concept around here. And it is also well understood that not all developers complain about TiVo. Major projects are holding to GPLv2. As Eben explained, the GPLv3 doesn't require root, it just requires that you be provided all the info you need to install modified software of your choice, in the environment in which the binaries were shipped. su is fine, if documented, and it is. And I think PATH=~/bin/:$PATH is fine too :-) PS: Get a clue, folks. This is bigger than OLPC. I understand and value that 'macro' fight, but OLPC, and OLPC deployments are not the enemy. You also need to know that OLPC is about a lot more than just software. We are a very big tent, and we work in some very hard places. Think of explaining this to teachers, or to the parents of children. I can only suggest getting closer to a large real life deployment (not just Uruguay) to get a sense of the challenges we face on the ground in the work we do... and to get a sense of what our who our users actually are. locks down the hardware to disallow freedom, Let's leave hyperbole for another day. It is a very practical concern -- across the varied world of our deployments *theft* is a very real concern. My personal experience in a very cottoned middle-class environment in latam is that by age 15 everyone in my age group had had something stolen in one way or another -- mostly in relatively low-key muggings. I will be optimistic and hope that 1% of the kids needs root at some point. Most places I go to in latam is about the same -- with of course some exceptions in both directions. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
On Sat, Jul 3, 2010 at 9:54 AM, Bernie Innocenti ber...@codewiz.org wrote: NetworkManager used to call ntpdate when it setup a connection. Was that an OLPC addition? Yes, although it's now present in litl's software builds as well. We figured out that the ntp package has never been present on the XO images. It was ntpdate, which was smaller than the whole ntp package. There's no way to practical way to implement effective anti-theft without taking away root from the user. And once we take away root access, we've also taken away olpc's principle #1: child ownership. See my recent message on this topic. Apart from the hardware fix (which avoids RTC dependency altogether), it is also possible to separate most of root's authority from the RTC priviledge. Installing software, for example, requires root access to the filesystem, but not access to the RTC. What are the school servers doing to keep their clocks reasonable? They're using ntp, with the Fedora pool of ntp servers. You should probably apply for your own pool: http://www.pool.ntp.org/en/vendors.html#open-source It's pretty painless, and makes you a better netizen. Why aren't we using ntp? ntp is probably overkill for XOs. Besides, who would want to give up that much ram? On top of that, ntpd doesn't get along with power saving mode. That's why you use ntpdate. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Wed, Jul 7, 2010 at 2:16 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote: Bernie wrote: On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote: I think you are missing an important requirement: installation without elevated permissions. Rainbow has been bit-rotting for the past 2 years Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still received no independent testing despite repeated calls for same. Rainbow, on the other hand, has seen a major new release, feature development that spurred new work in general Linux sandboxing, and is now available in more distributions than ever before thanks to dedicated support by folks like Luke, Sascha, and Jonas. Finally, if rainbow itself now receives little day-to-day attention, this is because it mostly does what its authors require and it does it well enough not to require their continued hand-holding. To be honest I wasn't a fan of rainbow a bit time ago.. But having Zero Sugar fully implemented and potential possibility to launch almost any piece of software - compile on demand is a regular workflow within 0install (existed sugar doesn't not let such possibility:), rainbow should be more then essential requirement. I took some time to read up on 0install -- very impressive technology, good work. I agree with Michael that this (userland installs) is the direction Sugar should be pursuing. With rainbow (or other sandbox) integration, this would accomplish all of the original goals with a much more robust packaging and dependency system than the .xo bundle. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Announce: OLPC software strategy.
Hi, Now that the 10.1.1 release for XO-1.5 is out, it's a good time to talk about OLPC's software strategy for the future. We've got a few announcements to make: XO-1: = OLPC wasn't planning to make a Fedora 11 release of the XO-1 OS, but a group of volunteers including Steven Parrish, Bernie Innocenti, Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1 builds that follow the OLPC 10.1.1 work. I'm happy to announce that we're planning on releasing an OLPC-signed version of that work, and that this release will happen alongside the next XO-1.5 point release in the coming weeks. So, OLPC release 10.1.2 will be available for both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84, GNOME 2.26 and Fedora 11. We think that offering this fully interoperable software stack between XO-1 and XO-1.5 laptops will greatly aid deployments, and we're very thankful to everyone who has enabled us to be able to turn this XO-1 work into a supported release! To prepare for this XO-1 release, we've started working on fixing some of the remaining bugs in the community F11/XO-1 builds. Paul Fox recently solved a problem with suspend/resume and wifi in the F11/XO-1 kernel, which was the largest blocker for a supported release. We'll continue to work on the remaining bugs, particularly the ones that OLPC is uniquely positioned to help with. The first development builds for this release will be published later this week. XO-1.5: === We'll be continuing to work on XO-1.5 improvements, incorporating fixes to the Known Problems section of the 10.1.1 release notes¹ into the 10.1.2 release. XO-1.75 and beyond: === XO-1.75 software development is underway. Today we're announcing that we're planning on using Fedora as the base distribution for the XO-1.75. This wasn't an obvious decision -- ARM is not a release architecture in Fedora, and so we're committing to help out with that port. Our reasons for choosing Fedora even though ARM work is needed were that we don't want to force our deployments to learn a new distribution and re-write any customizations they've written, we want to reuse the packaging work that's already been done in Fedora for OLPC and Sugar packages, and we want to continue our collaboration with the Fedora community who we're getting to know and work with well. We've started to help with Fedora ARM by adding five new build machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75 development boards. We'd prefer to use Fedora 13 for the XO-1.75, but it hasn't been built for ARM yet -- if anyone's interested in helping out with this or other Fedora ARM work, please check out the Fedora ARM page on the Fedora Wiki². We're also interested in hiring ARM and Fedora developers to help with this; if you're interested in learning more, please send an e-mail to jobs-engineer...@laptop.org. We'll also be continuing to use Open Firmware on the XO-1.75, and Mitch Bradley has an ARM port of OFW running on our development boards already. EC-1.75 open source EC code: OLPC is proud to announce that the XO-1.75 embedded controller will have an open codebase (with a small exception, see below). After much behind-the-scenes effort, EnE has agreed to provide us with a public version of the KB3930 datasheet and is allowing our new code to be made public. The code is not available yet due to a few chunks of proprietary code that need to be purged and some other reformatting. A much more detailed announcement will be provided once the new code is pushed to a public repository. The code will be licensed under the GPL with a special exception for OLPC use. The exception is because EnE has not released the low-level details on the PS/2 interface in the KB3930, so there will be some code that is not available -- relative to the codebase this is a very small amount of code. The GPL licensing exception will allow for linking against this closed code. We're going to investigate ways to move away from this code in the future. (As far as we're aware, this will make the XO-1.75 the first laptop with open embedded controller code!) Multi-touch Sugar: == We've begun working on modifications to Sugar to enable touchscreen and multitouch use (the XO-1.75 will have a touchscreen, as will future OLPC tablets based on its design), and we'll continue to do so. The first outcome from this work is Sayamindu Dasgupta's port of the Meego Virtual Keyboard³ to Sugar -- you can see a screencast of it in action here⁴. It's an exciting time for software development at OLPC. Many thanks for all of your support and efforts! - Chris, on behalf of the OLPC Engineering team. Footnotes: ¹: http://wiki.laptop.org/go/Release_notes/10.1.1 ²: http://fedoraproject.org/wiki/Architectures/ARM ³: http://gitorious.org/fvkbd ⁴:
Re: [Sugar-devel] Announce: OLPC software strategy.
Chris, thanks a lot for the extensive (and exciting!) updates and information, much appreciated:-) Cheers, Christoph Am 08.07.2010 um 00:01 schrieb Chris Ball c...@laptop.org: Hi, Now that the 10.1.1 release for XO-1.5 is out, it's a good time to talk about OLPC's software strategy for the future. We've got a few announcements to make: XO-1: = OLPC wasn't planning to make a Fedora 11 release of the XO-1 OS, but a group of volunteers including Steven Parrish, Bernie Innocenti, Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1 builds that follow the OLPC 10.1.1 work. I'm happy to announce that we're planning on releasing an OLPC-signed version of that work, and that this release will happen alongside the next XO-1.5 point release in the coming weeks. So, OLPC release 10.1.2 will be available for both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84, GNOME 2.26 and Fedora 11. We think that offering this fully interoperable software stack between XO-1 and XO-1.5 laptops will greatly aid deployments, and we're very thankful to everyone who has enabled us to be able to turn this XO-1 work into a supported release! To prepare for this XO-1 release, we've started working on fixing some of the remaining bugs in the community F11/XO-1 builds. Paul Fox recently solved a problem with suspend/resume and wifi in the F11/XO-1 kernel, which was the largest blocker for a supported release. We'll continue to work on the remaining bugs, particularly the ones that OLPC is uniquely positioned to help with. The first development builds for this release will be published later this week. XO-1.5: === We'll be continuing to work on XO-1.5 improvements, incorporating fixes to the Known Problems section of the 10.1.1 release notes¹ into the 10.1.2 release. XO-1.75 and beyond: === XO-1.75 software development is underway. Today we're announcing that we're planning on using Fedora as the base distribution for the XO-1.75. This wasn't an obvious decision -- ARM is not a release architecture in Fedora, and so we're committing to help out with that port. Our reasons for choosing Fedora even though ARM work is needed were that we don't want to force our deployments to learn a new distribution and re-write any customizations they've written, we want to reuse the packaging work that's already been done in Fedora for OLPC and Sugar packages, and we want to continue our collaboration with the Fedora community who we're getting to know and work with well. We've started to help with Fedora ARM by adding five new build machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75 development boards. We'd prefer to use Fedora 13 for the XO-1.75, but it hasn't been built for ARM yet -- if anyone's interested in helping out with this or other Fedora ARM work, please check out the Fedora ARM page on the Fedora Wiki². We're also interested in hiring ARM a nd Fedora developers to help with this; if you're interested in learning more, please send an e-mail to jobs-engineer...@laptop.org. We'll also be continuing to use Open Firmware on the XO-1.75, and Mitch Bradley has an ARM port of OFW running on our development boards already. EC-1.75 open source EC code: OLPC is proud to announce that the XO-1.75 embedded controller will have an open codebase (with a small exception, see below). After much behind-the-scenes effort, EnE has agreed to provide us with a public version of the KB3930 datasheet and is allowing our new code to be made public. The code is not available yet due to a few chunks of proprietary code that need to be purged and some other reformatting. A much more detailed announcement will be provided once the new code is pushed to a public repository. The code will be licensed under the GPL with a special exception for OLPC use. The exception is because EnE has not released the low-level details on the PS/2 interface in the KB3930, so there will be some code that is not available -- relative to the codebase this is a very small amount of code. The GPL licensing exception will allow for linking against this closed code. We're going to investigate ways to move away from this code in the future. (As far as we're aware, this will make the XO-1.75 the first laptop with open embedded controller code!) Multi-touch Sugar: == We've begun working on modifications to Sugar to enable touchscreen and multitouch use (the XO-1.75 will have a touchscreen, as will future OLPC tablets based on its design), and we'll continue to do so. The first outcome from this work is Sayamindu Dasgupta's port of the Meego Virtual Keyboard³ to Sugar -- you can see a screencast of it in action here⁴. It's an exciting time for software development at OLPC. Many thanks for
[Sugar-devel] [ASLO] Release Visual Match-23
Activity Homepage: http://activities.sugarlabs.org/addon/4246 Sugar Platform: 0.82 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/26979/visual_match-23.xo Release notes: * Byron Corrales fixed the robot/word-edit conflict (#2057) * general code cleanup Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Python help
On 8 July 2010 04:49, ALEXANDER JONES (RIT Student) acj3...@rit.edu wrote: I'm writing a python program for sugar and i recently added a line at the top 'from sugar.activity import activity' and now every time i run it i get a glib.GError:Failed to contact configuration server;.(lots of text) i can't seem to figure out what this means. can anyone point me in the right direction? Thanks :) Hi Alexander, Are you able to tell us which version of the sugar.activity package you are importing? Also, can you please paste in the full error. Lastly, which operating system are you running on? ~Tim ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
