Re: [Sugar-devel] Enhancing Sugar to support multiple users
On Tue, Sep 7, 2010 at 9:40 AM, Simon Schampijer si...@schampijer.de wrote: On 09/06/2010 03:40 PM, pbrobin...@gmail.com wrote: On Mon, Sep 6, 2010 at 2:05 PM, Daniel Draked...@laptop.org wrote: On 5 September 2010 13:57, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi, I just created a new ticket (http://bugs.sugarlabs.org/ticket/2292) to get some discussions started on what changes need to be made to Sugar to work well in an environment where multiple users will work on the same machine (which is how Peru's next 300,000 XOs will be used: http://www.olpcnews.com/countries/peru/peru_between_one_laptop_per_child_and_seven_children_per_laptop.html). Obviously this touches upon a lot of areas from simple naming of the machine, over the Journal, backups and probably a whole host of other issues that I haven't though of yet. When we discussed this while I was in Peru, one requirement they identified is that the kid would log onto an XO one day and do some work, and then log onto another XO the following week and continue the same work. Assuming this still stands, this strongly calls for a network-based home directory system with some kind of network login service (but someone with experience in such areas should comment). This would require a number of changes at the OS level and server level, but Sugar would be left untouched, as far as I can think. The standard way of doing this in unix is to use nfs and automount with NIS/LDAP authentication. This would mount the users home directory on login. There's a number of issues that come up with this implementation for the XOs in that wireless would need to connect prior to this and NFS over wifi would be interesting at best due to wifi dropouts. To mitigate that problem you'd probably have to wedge some of the caching filesystems that are being developed to allow the home directory to be cached. Suddenly your getting a very complex solution to fix the problem. Yes, this is true. I obviously used wired connections when using LDAP/NFS. In a lap with fixed equipment this is an easy setup. For the XOs, I agree this could lead to frustration. (even in my case kids very confused because someone has pulled the cables) The other possible alternative to this would be to use something like couchdb to store the contents of the journal and associated config files where you can have a local couchdb that replicates to a remote service. This might be the simpler solution but would obviously require development. Peter Interesting. A solution where you only need to sync twice (start/stop) might be better in the wifi environment. It is something that I've been meaning of trying to dogfood as a concept as I think it would be a perfect cloud (and yes I frickn hate the term) storage solution for deployments as it allows you to change servers, move storage etc without having to reconfigure the client side. I got as far as setting up the server side of things and playing around with evolution-couchdb for storing evo contacts but no further. There's some glib helper files. I was actually hoping to get more time to play with this more once Fedora 14 / SoaS 4 is out the door. I have some server resources available to set up the server side if anyone else is interested as well. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
On Sun, Sep 5, 2010 at 10:57 AM, Bernie Innocenti ber...@codewiz.org wrote: El Sun, 05-09-2010 a las 00:53 +0100, pbrobin...@gmail.com escribió: Well I am for SoaS related things which while isn't XO hardware related it does affect everything further up the stack does that not count :-( Such parallel efforts are indeed mutually beneficial. Dextrose also enjoyed the pioneering packaging and testing effort carried on on 0.88 by the SoaS folks, plus the platform stabilization work done by dsd, pgf and cjb. Isn't this the normal thing in FLOSS development? No point as its directly Fedora related but if people could add positive karma to this it would be fixed quicker, else in about 4-5 days it will head to F-14 stable. https://admin.fedoraproject.org/updates/gnome-python2-desktop-2.31.1-5.fc14 Done, but I'm afraid I had to give it negative karma: Looking at the upstream GIT of evince it looks like this is another of the apis that have been deprecated upstream and Read needs to be updated to fix the issue http://git.gnome.org/browse/evince/diff/libdocument/ev-selection.h?id=18d2af9bce80392407fae997c8dfa029f5a54123 Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Enhancing Sugar to support multiple users
On Mon, Sep 6, 2010 at 2:05 PM, Daniel Drake d...@laptop.org wrote: On 5 September 2010 13:57, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi, I just created a new ticket (http://bugs.sugarlabs.org/ticket/2292) to get some discussions started on what changes need to be made to Sugar to work well in an environment where multiple users will work on the same machine (which is how Peru's next 300,000 XOs will be used: http://www.olpcnews.com/countries/peru/peru_between_one_laptop_per_child_and_seven_children_per_laptop.html). Obviously this touches upon a lot of areas from simple naming of the machine, over the Journal, backups and probably a whole host of other issues that I haven't though of yet. When we discussed this while I was in Peru, one requirement they identified is that the kid would log onto an XO one day and do some work, and then log onto another XO the following week and continue the same work. Assuming this still stands, this strongly calls for a network-based home directory system with some kind of network login service (but someone with experience in such areas should comment). This would require a number of changes at the OS level and server level, but Sugar would be left untouched, as far as I can think. The standard way of doing this in unix is to use nfs and automount with NIS/LDAP authentication. This would mount the users home directory on login. There's a number of issues that come up with this implementation for the XOs in that wireless would need to connect prior to this and NFS over wifi would be interesting at best due to wifi dropouts. To mitigate that problem you'd probably have to wedge some of the caching filesystems that are being developed to allow the home directory to be cached. Suddenly your getting a very complex solution to fix the problem. The other possible alternative to this would be to use something like couchdb to store the contents of the journal and associated config files where you can have a local couchdb that replicates to a remote service. This might be the simpler solution but would obviously require development. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
On Mon, Sep 6, 2010 at 10:46 PM, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 06-09-2010 a las 11:49 +0100, pbrobin...@gmail.com escribió: Done, but I'm afraid I had to give it negative karma: Looking at the upstream GIT of evince it looks like this is another of the apis that have been deprecated upstream and Read needs to be updated to fix the issue http://git.gnome.org/browse/evince/diff/libdocument/ev-selection.h?id=18d2af9bce80392407fae997c8dfa029f5a54123 To keep the testing cycle shorter, couldn't you just build the rpms locally and test them once on your system before pushing them to bodhi? I don't maintain that package. I also don't maintain Read. The gnome-python2 package I did update was just re-enabling the upstream. In that regard i did test the gnome-python2 package but but not against Read as where I was in the world at the time I didn't have a working F-14 system to hand with X working so its pretty hard to. At the moment I've worked every day in the last month and I've being travelling around Europe at least once a week so I'm battling to have time to do the basic stuff and I didn't believe I'm the only person in the sugar testing world. The problem isn't evince or gnome-python2 but that Read needs to be updated again for the new upstream evince api changes (again). Looking in Read git the last tagged release is Read 79 yet on a.sl.o is Read 86. I'm not sure what the rest of the changes are or which version is correct so going on the official Read 79 release it wouldn't work any way. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
On Sat, Sep 4, 2010 at 10:24 AM, Mikus Grinbergs mi...@bga.com wrote: For now, please don't file bugs unless you include patches. I can understand not wanting bug reports against items which OLPC/Sugar are still in the process of changing. But why defer reporting problems which might not be addressed unless there was a report ? For instance, Read-87 fails to launch on XO-1 os1 (F14) when it tries to 'import evince'. Though the necessary gnome-python2-evince package was not included in the os1 build, when I manually install that package from the yum Fedora-14 repositories, the import statement still fails -- apparently because the evince.so module provided by the current Fedora-14 package has internal inconsistencies. I myself do not have a Python test case which does 'import evince' - nor do I have a patch - but perhaps the maintainers of the Read Activity might want to discuss this situation with the maintainers of Python on Fedora 14. This is a known problem with Read at the moment. I fixed the package the other day and its filtering through the updates-testing. There's a number of fairly large number of issues with Fedora 14 at the moment due to the new systemd and python 2.7 not to mention some quite big gnome related changes. We're preparing the SoaS 4 release based on this as well so the SoaS team are aware of a number of issues and we're working as quickly as possible to fix them (but the 3 people in the team are also very busy with other life related things as well) and this will benefit this release as well because both teams can work towards the same goal. Regards, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
On Sat, Sep 4, 2010 at 3:56 PM, Daniel Drake d...@laptop.org wrote: On 4 September 2010 03:24, Mikus Grinbergs mi...@bga.com wrote: For now, please don't file bugs unless you include patches. I can understand not wanting bug reports against items which OLPC/Sugar are still in the process of changing. But why defer reporting problems which might not be addressed unless there was a report ? Because nobody other than me is fixing the problems right now, and the bugs will go stale. And if someone is available to fix bugs, you only have to spend 5 minutes working with the image to encounter several of them. A bug tracker is needless overhead for such early and loose development. Well I am for SoaS related things which while isn't XO hardware related it does affect everything further up the stack does that not count :-( This of course will change with time, if the project continues to progress. For instance, Read-87 fails to launch on XO-1 os1 (F14) when it tries to 'import evince'. Though the necessary gnome-python2-evince package was not included in the os1 build, when I manually install that package from the yum Fedora-14 repositories, the import statement still fails -- apparently because the evince.so module provided by the current Fedora-14 package has internal inconsistencies. I myself do not have a Python test case which does 'import evince' - nor do I have a patch - but perhaps the maintainers of the Read Activity might want to discuss this situation with the maintainers of Python on Fedora 14. As this is a topic purely related to Sugar you are welcome to file a bug on the SL bug tracker, or start a discussion on the sugar mailing list. No point as its directly Fedora related but if people could add positive karma to this it would be fixed quicker, else in about 4-5 days it will head to F-14 stable. https://admin.fedoraproject.org/updates/gnome-python2-desktop-2.31.1-5.fc14 I should also clarify that if you have an easy solution for a bug (such as: add package XYZ) you are welcome to file a bug - by only file bugs with patches I guess I meant only file bugs with patches or simple solutions I'm just trying to focus and organize the OS-level work, and to avoid wasting time on bug tracking in this early stage. Thanks for working with me on this... Daniel ___ olpc mailing list o...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/olpc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Initial F14 developers-only release for XO and XO-1.5
Hey Daniel, Yippee! I suspect the sugar starting issues is the same one we're seeing in SoaS for F-14. I'm very busy until Sunday but i hope to have at least some time to be able to look at that problem and help you out where possibly as no doubt both SoaS and the builds for the XO will share a lot of common problems. With the kernel nearing a recent release is there any plans to get a chunk of the kernel patches upstream to ease on going maintenance? As always ping me if there's anywhere specific I can be of assistance in upstream Fedora. Peter On Wed, Sep 1, 2010 at 6:22 AM, Daniel Drake d...@laptop.org wrote: Hi, After seeing the community help significantly with F11-on-XO development, I'm wondering if we can do something similar for a future release. So, I've taken the first few steps in getting OLPC's technologies rebased on Fedora 14 and Linux v2.6.35. The result has lots of problems, but I figure that publishing the work so far is the first step in getting things fixed. Things are in such an early stage that I'm labelling this as a developers-only release. To name a few: Sugar crashes all the time, the XO-1.5 camera doesn't work, there are some funky graphics bugs on XO-1, no power management, DCON doesn't work right on either laptop, desktop switching lands you at a blank screen. For now, please don't file bugs unless you include patches. And, to take 1 bite at a time out of this huge task, lets ignore all but the biggest sugar issues for now because there is plenty of OS work to be done first. (or alternatively lets take sugar issues directly to SL trac) And the links: 2.6.35 kernel is in git://dev.laptop.org/olpc-2.6 branch olpc-2.6.35 OS build is done from 'f14' branch of olpc-os-builder First released images are at http://build.laptop.org/F14/os1/ Trac is at http://dev.laptop.org/milestone/F14 (basically my immediate TODO), please don't file tickets unless you include patches in these early days Note: I haven't tested those exact images (since Chris @ OLPC built them), so boot-testing them can be the first task for someone. I have been working from the same codebases making local images successfully, so they will probably work (to the extent that things are working). At this point this is all something put together by me in my spare time. It's not known if or when OLPC would start working on an official release from these efforts. But I figure that if we get things properly stabilized and all the work is done cleanly, we'll find one way or another to get this in the hands of deployments. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Default unlock key ring (Fedora 11 + Gnome 2.26.3 + Apps)
On Tue, Aug 24, 2010 at 1:14 PM, Martin Langhoff mar...@laptop.org wrote: Yeah, I filed a bug recently about this. IMHO we should set whatever gconf key controls this to no encrypted keyring, not prompting. This has been the default in Fedora for quite some time. I'm not sure whether it was in the F-11 time frame but it certainly was for any clean installs from F-12 and later. Peter On Tue, Aug 24, 2010 at 3:24 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Aug 23, 2010 at 23:08, Hernan Pachas hernan.pac...@gmail.com wrote: Dear friends, How I can unlock the default ring keys. I need never ask the system keys, because End users are children. It should be noted that the system runs on the XO laptop, the program OLPC. Your help will be very important for the deployment of 500k laptops OLPC. Operating system Fedora + Gnome + App Hi Hernan, don't remember how exactly I did it a while ago, but this page helped me figure it out: http://live.gnome.org/GnomeKeyring/Pam Regards, Tomeu ---Hernan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 2:33 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Sun, Aug 8, 2010 at 15:15, Martin Langhoff martin.langh...@gmail.com wrote: On Sun, Aug 8, 2010 at 4:01 AM, Tomeu Vizoso to...@sugarlabs.org wrote: I tihnk I have been sloppy with my words, so let me clarify two things: - killing processes should be done only to avoid OOM (because currently the kernel kills the wrong thing most of the time). Can't we just _close it nicely_? When you are about to get into OOM? Don't think so because it's very probable that the kernel will block or kill something randomly before the activity or the user react. But as I said, before we reach this point we should have given the activities and/or the user the option to avoid this situation. Not sure what the requirements would be of implementing something like iphone/ipod (well versions prior to 4) where when the Activity is backgrounded it saves its state and quits so you don't really have more than one app running at a time? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Tue, Jul 6, 2010 at 5:02 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. PackageKit can already do that. There was a furore around 6 months ago when someone enabled it by default for Fedora. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity packaging
On Tue, Jul 6, 2010 at 6:50 PM, John Gilmore g...@toad.com wrote: I think you are missing an important requirement: installation without elevated permissions. Enhancing deb or rpm to be able to do this would be a win all around. A nonroot install would install under one's home directory, if either the package was marked as tested for homedir installation, or the user provided an override. The underlying OS would have to ship user PATH and LD_LIBRARY_PATH defaults to include $HOME/bin and $HOME/lib. A package database would exist under $HOME as well. Read-only access to the global package database would allow the local package to check dependencies, etc. It may be useful to define a standard programming convention for a package to readily find its control files and data files (either in /etc and /usr/lib, or in $HOME/.something, etc). Ideally it should be possible to ask that a package be installed under any particular directory, allowing users to install several different versions of a package and run them from different places. This would let users run multiple applications which depend on particular versions of another package (e.g. python), while allowing the system default to be upgraded to the latest (incompatible) version. rpm can already do that. It can relocate the package install location. I'd argue for adding this to deb, partly because Fedora at one point indicated a willingness to move from rpm/yum to deb/apt whenever someone does the work, whereas Debian and Ubuntu seem satisfied with deb and apt. But that would be a longer road for OLPC and other existing Fedora users. I very much doubt that would ever happen. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] behaviour of F-keys on XO HS
On Tue, Jul 20, 2010 at 2:27 AM, Gonzalo Odiard godi...@gmail.com wrote: Yeah How we detect what keyboard is present? Wouldn't you be better of using xkeys or what ever gtk uses and they you don't need to what keyboard is present, it would just work. Peter On Mon, Jul 19, 2010 at 9:26 PM, Walter Bender walter.ben...@gmail.com wrote: On Mon, Jul 19, 2010 at 5:20 PM, Paul Fox p...@laptop.org wrote: i'd like to bring this discussion to a conclusion. i'm starting to be a fan of this proposal of bert's -- it's very simple, keeps the keys the same in sugar and in gnome, and on membrane and non-membrane keyboards, it's backwards compatible with existing use on XO-1, and the volume/ brightness keys remain easily discoverable. it does require that sugar respond to F5 and F6 for journal and frame -- i still don't have a feeling for whether that's an issue or not, and if so, how big. The only activity I am aware of that uses F5 and F6 on the XO is the most recent version of Paint that Gonzolo is working on. Presumably these keymaps could be grabbed by Paint when running on an OLPC XO 1.0 or when we detect the membrane keyboard. Otherwise, we could keep the mapping as Bert suggests. any yeas or nays? Yeah. paul bert wrote: On 17.07.2010, at 09:31, Bernie Innocenti wrote: El Thu, 15-07-2010 a las 23:08 -0400, Paul Fox escribió: i think everyone (except apple, i'm learning tonight) agrees this is the correct setup when not in sugar. Lenovo also seems to be switching to the Apple layout: http://www.blogcdn.com/www.engadget.com/media/2010/01/thinkpadedgepost16.jpg http://www.thinkpads.com/wp-content/gallery/lenovo-thinkpad-edge-13-review/lenov o-thinkpad-edge-13-keyboard.jpg Almost all the historic F-key mappings have an alternative CTRL+key or ALT+key mapping in modern HIGs. Keys to control laptop volume and brightness are accessed much more frequently, so it's foreseeable that over time they will supplant the F-keys in PC keyboards. +1 IMHO pressing fn to get f1 to f10 makes sense. In my daily routine I much more often change volume or brightness than use the numbered F keys. Looking at this again http://wiki.laptop.org/go/OLPC_Spanish_Non-membrane_Keyboard I propose: f1-f8 produce F key codes both with and without the fn key f9-f12 produce F codes only with fn, and volume/brightness events without fn. So holding down fn always gets you the F key codes, you can change volume/brightness without modifier, and as a bonus you can use the first eight F keys even without the fn key. This mapping should work both in Sugar and outside. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard Responsable de Desarrollo Sistemas Australes ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Announce: OLPC software strategy.
Hi Chris, Well done to the team for all the hard work! 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! Excellent news! 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. Now that the major release is out what are the plans for upstreaming the kernel and other changes for both the XO-1.5 as well as the remaining bits for the XO-1? 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. Very interested in helping out, pushing builds etc through koji so let me know what needs attention and I'll help out where I can. 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
Re: New XO-1 10.1.2 build 300
On Thu, Jul 8, 2010 at 9:07 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Thu, Jul 8, 2010 at 3:48 PM, Daniel Drake d...@laptop.org wrote: It's particularly significant because (when the release goes final) it means we have synchronized software between XO-1 and XO-1.5. Are we aiming for a synchronised 10.1.2 for XO-1 and XO-1.5? Yes, see the email from chris about the software announcements. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: F11-for-XO1.5 Release 10.1.1 Release Candidate 4
On Thu, Jul 1, 2010 at 4:30 PM, Bernie Innocenti ber...@codewiz.org wrote: El Wed, 30-06-2010 a las 19:28 -0400, Chris Ball escribió: * #9112: Fix Enable Browse to embed PDF files in itself regression Can someone please post the patch? I'd like it applied to the latest version of Browse for F11-0.88 (and SoaS). Why do we need to patch it? Why not get it in upstream and then it will be in the next release. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
