Re: New joyride build 2213
Bert Freudenberg wrote: > Am 25.07.2008 um 17:29 schrieb Build Announcer v2: > >> http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2213 >> >> -gnome-python2-gnomevfs 2.22.1-5.olpc3 >> +gnome-python2-gnomevfs 2.22.1-3.olpc3 > > Was this intentional? Yes, it's the same package, I just moved it from public_rpms into Fedora proper. At the same time I resynced the version numbers to follow on directly from F9 (which is currently at 2). Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 2213
Am 25.07.2008 um 17:29 schrieb Build Announcer v2: > http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2213 > > -gnome-python2-gnomevfs 2.22.1-5.olpc3 > +gnome-python2-gnomevfs 2.22.1-3.olpc3 Was this intentional? - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] NAND full issue
On Jul 25 2008, at 20:00, Daniel Drake was caught saying: > So unionfs is the "formal bug fix for 8.2 going forward", or is it a > Uruguay-specific thing? > > unionfs will involve a kernel change. Are we planning to shift them from > 2.6.22 to 2.6.25 where unionfs has been included, or are we going to > backport unionfs to 2.6.22? > > Also, I am a little wary of unionfs, I have used it in the past and > found it to be buggy and unreliable. It may be better now, but we should > be cautious. I've done an analysis of the UFS code and it may be possible to have a standalone unionfs module w/o changes to core kernel. See [1] for my email sent to UFS maintainers and list. My concern is that by forking the code this way, we're introducing another variable. However... Erik has been using AUFS[2] as UFS was crashing badly and not allowing sugar to boot. AUFS is completely standalone and requires no changes to the deployed kernel. This is also non-upstream so we should run it through some form of stress test in our desired configuration. ~Deepak [1] http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2008-July/005895.html [2] http://aufs.sourceforge.net/ -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] NAND full issue
On Sat, Jul 26, 2008 at 1:00 PM, Daniel Drake <[EMAIL PROTECTED]> wrote: > unionfs will involve a kernel change. Erik's got a ko to add to the initrd AIUI. > Have we considered sorting by date and removing from oldest to new until > the threshold is reached? Perhaps excluding starred items. Both date and size are flawed -- Greg and Cjb have explored the flaws of both approaches on [EMAIL PROTECTED] The best notes on this are from Mitch so far - he looked at the FSs and spotted things we can safely delete. And we cannot query for starred items without starting the journal, which does not start in no-space conditions. IMHO, Cjb's script should delete caches and the files various files we know are safe to nuke _before_ we even consider user data - Mitch has identified stray CVS directories. These are safe to nuke. - /var/cache/yum - ~/.sugar/default/logs - ~/.sugar/default/gecko/Cache - Someone mentioned large support files in eToys. Might be worthwhile to nuke large Activities in ~/Activities. If not enough space is available, then it makes sense to nuke user data. cheers, m -- [EMAIL PROTECTED] -- 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
New joyride build 2214
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2214 Changes in build 2214 from build: 2213 Size delta: 0.00M -pygtk2 2.12.1-6.fc9 +pygtk2 2.12.1-7.olpc3 -pygtk2-libglade 2.12.1-6.fc9 +pygtk2-libglade 2.12.1-7.olpc3 -xkeyboard-config 1.2-3.fc9 +xkeyboard-config 1.3-1.olpc3 --- Changes for pygtk2 2.12.1-7.olpc3 from 2.12.1-6.fc9 --- + Use numpy instead of numeric --- Changes for pygtk2-libglade 2.12.1-7.olpc3 from 2.12.1-6.fc9 --- + Use numpy instead of numeric --- Changes for xkeyboard-config 1.3-1.olpc3 from 1.2-3.fc9 --- + Update to 1.3 -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Calling all small keyboards
Not sure if this helps but look at patent 5700097 http:// patft.uspto.gov/netacgi/nph-Parser? Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO% 2Fsrchnum.htm&r=1&f=G&l=50&s1=5700097.PN.&OS=PN/5700097&RS=PN/5700097 It may lead to something else via the patents it references including a Japanese patent from 1983 On Jul 24, 2008, at 12:29 PM, John Watlington wrote: > > We are looking for examples of keyboards for small children > present before 1993. > > Specifically, we are looking for keyboards whose key-key spacing > is between 10.8 and 16.4 mm horizontally, and 10.8 to 18.0 mm > vertically, and with a stroke distance of 0.9 to 6mm. > > Thanks for your memories, > wad > > http://www.google.com/patents?vid=USPAT7354209 > http://www.google.com/patents?vid=USPAT7101101 > http://www.google.com/patents?vid=USPAT5531529 > > ___ > 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: NAND full issue
Kimberley Quirk wrote: > OLPC's response is "Failsafe" for 656, per703, and 8.1.2; and a formal > bug fix for 8.2 going forward: > Uruguay: > Erik is working with Uruguay on the solution described as "Union > Mount" below. It is important that Uruguay own this bug fix themselves > and can maintain it as needed, test it to their satisfaction, decide > how to distribute it. This can be delivered as a USB or wireless > download. Uruguay also has the choice to use the options supported by > OLPC above. So unionfs is the "formal bug fix for 8.2 going forward", or is it a Uruguay-specific thing? unionfs will involve a kernel change. Are we planning to shift them from 2.6.22 to 2.6.25 where unionfs has been included, or are we going to backport unionfs to 2.6.22? Also, I am a little wary of unionfs, I have used it in the past and found it to be buggy and unreliable. It may be better now, but we should be cautious. > RECOVERY SOLUTIONS - > Automatic Free Space: > Provide USB bootable build that would free space in some way. Can we > identify a class of things that we know can be deleted (like cracklib > dictionary of unsafe passwords, large activities). Add a note that a > delete is going to happen during boot. Only works the first time they fill it up, obviously. > Failsafe: > Can be inserted in the build, include 'automatic free space'. It opens > the datastore and sorts by size, wants to find 50M, pops off the stack > deleting stuff from largest to smallest. Can it explain afterwards > what it has done or explain ahead of time what it might do. Provide > options for what to delete. Have we considered sorting by date and removing from oldest to new until the threshold is reached? Perhaps excluding starred items. > The Fix: (fix to 7587) > When the NAND is full, Sugar will boot but not be allowed to write. A > notification about space and inability to write needs to be displayed. ...and the space can be freed by deleting activities and journal items? No unionfs involved? I feel that is the best way forward. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
NAND full issue
NAND Full Issue Attending: Greg, Michael, Joe, Erik, Charlie, Chris, Kim We discussed the problem recently uncovered in Uruguay, the solutions and suggestions that have been posted and came up with a proposal for moving forward. Problem statement: bug 7587 With build 656, when the file system is completely full the laptop will not boot. Currently Uruguay has to ship the laptops back to repair centers causing both shipping costs and downtime costs. Please see below for the 5 types of avoidance, recovery, build image solutions and the bug fix solution. (Most of these have been discussed in some detail on other threads). This proposal addresses the problem for Uruguay a little differently than for other build 656 customers as Uruguay is already diverged from our code base. They may want a more elaborate solution that they can test and deploy at their own pace. OLPC's response is "Failsafe" for 656, per703, and 8.1.2; and a formal bug fix for 8.2 going forward: "Failsafe" OS - includes the "Automatic Free Space" recovery in a build image. This works for laptops that are already refusing to boot as well as for preventing the non-boot problem. On boot up, this will check for free NAND and if there isn't enough to boot, it will display a message that it is deleting files, and it will remove the largest file(s) until 50M is available and then finish booting. This can be delivered on a USB stick. Each country technical liaison can decide if they want to update all laptops, or wait until laptops see the problem (which could be many months). It should also be incorporated in Peru's build (703), which we need to deliver early next week, so we can avoid the problem for 100k laptops. The formal bug fix with better notifications and the ability for the user to chose what to delete will be described in 7587; and will be delivered in 8.2. Uruguay: Erik is working with Uruguay on the solution described as "Union Mount" below. It is important that Uruguay own this bug fix themselves and can maintain it as needed, test it to their satisfaction, decide how to distribute it. This can be delivered as a USB or wireless download. Uruguay also has the choice to use the options supported by OLPC above. Thoughts? Kim --- AVOIDANCE: If the students /teachers had a regime of deleting files, that might avoid the problem. In Uruguay they are capable of displaying a dialog box at 85% full; use that to avoid the problem. RECOVERY SOLUTIONS - Reflash the build via local USB stick - today this is not possible because of their activation system. Automatic Free Space: Provide USB bootable build that would free space in some way. Can we identify a class of things that we know can be deleted (like cracklib dictionary of unsafe passwords, large activities). Add a note that a delete is going to happen during boot. BUILD SOLUTIONS - Union Mount: Erik's 'union mounting' (UFS) - check at boot if you are above threshold. If so, mount the root as readonly and redirect write requests. Nothing would write permanently. You can mark things for delete, which will get deleted at the next shutdown. This can be deployed ahead of time. Failsafe: Can be inserted in the build, include 'automatic free space'. It opens the datastore and sorts by size, wants to find 50M, pops off the stack deleting stuff from largest to smallest. Can it explain afterwards what it has done or explain ahead of time what it might do. Provide options for what to delete. Big File: At reboot, a big file is written and saves space for the case when you can't boot. Seems like it isn't a great idea. Two step boot process - every boot we check that there is a file of a good size; still should have a GUI for deciding what to delete. The Fix: (fix to 7587) When the NAND is full, Sugar will boot but not be allowed to write. A notification about space and inability to write needs to be displayed. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2213
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2213 Changes in build 2213 from build: 2212 Size delta: 0.00M -gnome-python2 2.22.1-5.olpc3 +gnome-python2 2.22.1-3.olpc3 -gnome-python2-gnomevfs 2.22.1-5.olpc3 +gnome-python2-gnomevfs 2.22.1-3.olpc3 -gnome-vfs2 2.22.0-1.olpc3 +gnome-vfs2 2.22.0-2.olpc3 --- Changes for gnome-python2 2.22.1-3.olpc3 from 2.22.1-5.olpc3 --- + Really kill dependency on libbonobo + Kill dependency on libbonobo + Kill dependency on libbonobo + gnome-python modularisation to remove dependencies --- Changes for gnome-python2-gnomevfs 2.22.1-3.olpc3 from 2.22.1-5.olpc3 --- + Really kill dependency on libbonobo + Kill dependency on libbonobo -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Congratulations! but Sugar sucks
I think that one useful thing that we could work out in this thread would be how many dollars and months it would take to get each of these areas from suckage to ruleage. Here's some estimates out of my ... head: 1. datastore. Get consensus: 1.5 months from now (really, 1 month from 8.2). Hire/reassignAndClearTheDecksOf someone to work on this full time: 1 month. Actual work to reach The Next Level: 2-3 months. Cleanup: 2-3 months. Realistically, we can't guarantee that this can make it by 9.1, but it should be close. Time: 6+ months, cost: 4-6 months FTE. Someone with these skills could cost up to $80K/yr in US, over half that internationally. 2. OS updates. Design and consensus: 2.5 months from now. Actual coding: 2 months. (This is the kind of problem that needs good clean design, but is not too very hard to implement.) Time: 5 months, cost: using existing resources. 3. File Sharing. Apparently there is already an intern on this. 3 months, existing resources. 4. Activity Modification: 2 months and <<$5K. 5. Bitfrost Blocked by 4 (activity bundle signatures), above. After that, there are about 2 biggish (1-2 months) features to add, and then the rest is eternal vigilance (much debugging). Say 2-4 months FTE, 6 months ETA 6. Power management ??? 7. Software: if you build it, they will come. 8. Collab: ??? existing resources? 9. Mesh: ??? Add it all up, and I think that with about 3 expensive new-hire FTEs and me (much, much cheaper), 90% of this list could be done in time for 9.1; the other 10% could be done by 9.2 without even using the new FTEs, which would free them up for nextgen development. On the other hand, I think that with just existing resources, only about 30% will be done by 9.1, which will Still Suck. IMO this is a steal - I know nothing about funding here, but if there is a chance of this level of funding I think it is a no-brainer. Say there's $100,000,000 of hardware out there, shipped; I think that this list accounts for easily 10% of the use-value of this hardware; and the costs above are far under $300K, with the most pessimistic accounting. That means that the *immediate* social-value for investment would be around a factor of 20. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems & GL/glx
Daniel Drake wrote: > On Fri, 2008-07-25 at 10:22 -0400, Ton van Overbeek wrote: > >> Just FYI. Tried to boot both joyride-2207 and joyride-2210 (the >> devel-ext3 variant) on >> qemu (on win XP/SP2) but both fail with the same error: >> >> (EE) AIGLX error: dlopen of /usr/lib/sri/swrast_dri.so failed >> (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such >> file or directory) >> >> Fatal server error: >> GLX: could not load software rendered >> >> giving up. >> - >> > > I found a bug in my patch, dlopen() is not documented to populate errno, > but my patch was relying on that. I submitted a new build with the patch > that went upstream which does not contain this assumption. > > Daniel > Seems to be fixed in joyride-2212. This one works fine in qemu. Thanks everybody for the quick fix Ton van Overbeek ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2212
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2212 Changes in build 2212 from build: 2210 Size delta: 0.00M -xorg-x11-server-Xorg 1.4.99.906-1.olpc3 +xorg-x11-server-Xorg 1.4.99.906-2.olpc3 -xorg-x11-server-common 1.4.99.906-1.olpc3 +xorg-x11-server-common 1.4.99.906-2.olpc3 -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: odd yum dependency issues in joyride
On Jul 25 2008, at 18:33, NoiseEHC was caught saying: > > > With 2181 this worked: > yum install mc > yum install make gcc I reproduced what pgf is seeing and the above doesn't work. I still get gkibc-common dependency isue. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: odd yum dependency issues in joyride
noiseehc wrote: > I have just reflashed my XO since it failed to boot. > Did a reflash with 703 > then olpc-update --usb to 2181 > then yum install gcc thanks. i guess i'll chalk my system up to an anomaly then. paul > > [EMAIL PROTECTED] wrote: > > martin wrote: > > > On Fri, Jul 25, 2008 at 06:33:08PM +0200, NoiseEHC wrote: > > > > With 2181 this worked: > > > > yum install mc > > > > yum install make gcc > > > > > > I've been yum install'ing gcc after every olpc-update to joyride since > > > about 1559, and have never had any problems. > > > > > > > interesting. i wonder why mine fails? did either of you start > > with an older (e.g. 656/703) build that included a yum'd gcc? > > > > paul > > =- > > paul fox, [EMAIL PROTECTED] > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > > > > > =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: odd yum dependency issues in joyride
I have just reflashed my XO since it failed to boot. Did a reflash with 703 then olpc-update --usb to 2181 then yum install gcc [EMAIL PROTECTED] wrote: > martin wrote: > > On Fri, Jul 25, 2008 at 06:33:08PM +0200, NoiseEHC wrote: > > > With 2181 this worked: > > > yum install mc > > > yum install make gcc > > > > I've been yum install'ing gcc after every olpc-update to joyride since > > about 1559, and have never had any problems. > > > > interesting. i wonder why mine fails? did either of you start > with an older (e.g. 656/703) build that included a yum'd gcc? > > paul > =- > paul fox, [EMAIL PROTECTED] > ___ > 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: forking PAM to remove cracklib dependency
Hi, > Hi, pam currently depends on cracklib which brings in an 8.5mb > dictionary. It's quite easy to remove this dependency. Any > objections to me requesting a pam OLPC-3 branch and applying the > attached changes on the F-9 package? Looks good. Do you think you can get it upstream, too? In cases like these, I wonder whether just patching Pilgrim to remove the cracklib file after installation is a good idea -- it lets us avoid the package fork. Getting the patch accepted upstream would be best of all, though. - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: odd yum dependency issues in joyride
martin wrote: > On Fri, Jul 25, 2008 at 06:33:08PM +0200, NoiseEHC wrote: > > With 2181 this worked: > > yum install mc > > yum install make gcc > > I've been yum install'ing gcc after every olpc-update to joyride since > about 1559, and have never had any problems. > interesting. i wonder why mine fails? did either of you start with an older (e.g. 656/703) build that included a yum'd gcc? paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
project hosting application: Larry
1. Project name :Language Learning with Larry
2. Existing website, if any :http://wiki.laptop.org/go/Larry
3. One-line description :RPG that teaches foreign language vocabulary.
4. Longer description :RPG that teaches foreign language vocabulary.
:
:
:
5. URLs of similar projects :
6. Committer list
Please list the maintainer (lead developer) as the first entry. Only list
developers who need to be given accounts so that they can commit to your
project's code repository, or push their own. There is no need to list
non-committer developers.
Username Full name SSH2 key URL
E-mail
-
--
#1 My21heartsMelanie Kim[EMAIL PROTECTED](attached)
#2 MchuaMel Chua[EMAIL PROTECTED](you should already have my
ssh2 key)
#3
...
If any developers don't have their SSH2 keys on the web, please attach
them
to the application e-mail.
7. Preferred development model
[X] Central tree. Every developer can push his changes directly to the
project's git tree. This is the standard model that will be familiar
to
CVS and Subversion users, and that tends to work well for most
projects.
[ ] Maintainer-owned tree. Every developer creates his own git tree, or
multiple git trees. He periodically asks the maintainer to look at
one
or more of these trees, and merge changes into the maintainer-owned,
"main" tree. This is the model used by the Linux kernel, and is
well-suited to projects wishing to maintain a tighter control on code
entering the main tree.
If you choose the maintainer-owned tree model, but wish to set up some
shared trees where all of your project's committers can commit directly,
as might be the case with a "discussion" tree, or a tree for an
individual
feature, you may send us such a request by e-mail, and we will set up the
tree for you.
8. Set up a project mailing list:
[ ] Yes, named after our project name
[ ] Yes, named __
[X] No
When your project is just getting off the ground, we suggest you eschew
a separate mailing list and instead keep discussion about your project
on the main OLPC development list. This will give you more input and
potentially attract more developers to your project; when the volume of
messages related to your project reaches some critical mass, we can
trivially create a separate mailing list for you.
If you need multiple lists, let us know. We discourage having many
mailing lists for smaller projects, as this tends to
stunt the growth of your project community. You can always add more lists
later.
9. Commit notifications
[ ] Notification of commits to the main tree should be e-mailed to the
list
we chose to create above
[ ] A separate mailing list, -git, should be created for
commit
notifications
[X] No commit notifications, please
10. Shell accounts
As a general rule, we don't provide shell accounts to developers unless
there's a demonstrated need. If you have one, please explain here, and
list the usernames of the committers above needing shell access.
11. Translation
[X] Set up the laptop.org Pootle server to allow translation commits to
be made
[ ] Translation arrangements have already been made at ___
12. Notes/comments:
I'm a newbie at coding. I started early this July as a project for ILXO. If
you're familiar to their blog (http://ilxo.org/blog/?p=34), I did post some
information about what Larry currently does. The paragraph I wrote is the
second giant paragrapgh on the post.
Current code is at http://svn.melchua.com/larry
id_rsa.pub
Description: Binary data
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: odd yum dependency issues in joyride
On Fri, Jul 25, 2008 at 06:33:08PM +0200, NoiseEHC wrote: > With 2181 this worked: > yum install mc > yum install make gcc I've been yum install'ing gcc after every olpc-update to joyride since about 1559, and have never had any problems. Martin pgphE8HFfCLRL.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: odd yum dependency issues in joyride
[EMAIL PROTECTED] wrote: > c. scott ananian wrote: > > On Fri, Jul 25, 2008 at 10:43 AM, <[EMAIL PROTECTED]> wrote: > > > i've been slowly moving my g1g1 machine forward to joyride (from 656). > > > i had customized it quite a bit, and am trying to restore those changes. > > > i've got xfce running, but a couple of yum dependencies (which were fine > > > with F7) are failing. > > > > > > to wit: > > > > > > # yum install gcc > > [...] > > > --> Missing Dependency: glibc-common = 2.8-3 is needed by package > > glibc-2.8-3.i686 (installed) > > > Error: Missing Dependency: glibc-common = 2.8-3 is needed by package > > glibc-2.8-3.i686 (installed) > > > > Seems strongly related to trac #5056. > > related, perhaps, but clearly new breakage, since a gcc install worked > fine in 656. > > > > > > # yum install firefox > > [...] > > > Error: Missing Dependency: gecko-libs = 1.9.0.1 is needed by package > > firefox-3.0.1-1.fc9.i386 (olpc_development) > > > > Hmm, this might be a more fundamental mismatch, since we have a > > specific version of gecko used for Browse. You could always download > > but didn't we always? (i.e., what's changed?) > > > With 2181 this worked: yum install mc yum install make gcc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Congratulations! but Sugar sucks
On Fri, 25 Jul 2008, Jameson "Chema" Quinn wrote: |> 1. The datastore |> 2. OS Updates |> 3. File Sharing |> 4. Activity Modification |> 5. Bitfrost |> 6. Power management On Thu, Jul 24, 2008 at 11:02 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: On Thu, Jul 24, 2008 at 8:18 PM, Benjamin M. Schwartz <[EMAIL PROTECTED]> wrote: really surprisingly short. Each item on the list has been debated to a stationary point over the last two years, so all that is left is to make a final decision for the engineers to execute. Each task could be completed or hugely improved by a single developer in a few months, provided that we do not allow changes to the requirements, and the developers are not asked to split their time and focus. I do not believe that either of these statements is correct. We are not lacking in decisions: we have substantially complete designs; we are lacking implementation. Each of your items is not the work of "a single developer in a few months": solving these problems is realistically a year's work at least, if we have a single developer working full time on each. I have experience with numbers 1, 3, and 5, and am the principal person responsible for 4 right now. I would say that 3 and 4 are definitely within the "single dev in a few months" time frame; depending on the definition, 4 is in the "as soon as currently applied patches percolate into production" time frame. The further work on 4 - already started - is in the area of activity signatures, which is actually encroaching on 5. In a few full-time months of a single developer, this would put 4 at a place which other platforms could envy, and make concrete strides towards 5, to the point where security would be better, not worse, than other modern platforms (though I agree that there is plenty more work to fulfill the true promise of Bitfrost). I agree that 1 is not so simple; while a rockstar developer might be able to solve all our problems in a two-month all-nighter, 6 months to a year is a more realistic timeframe to get something really solid and stable. I think the biggest issue with #1 (and what Ben was trying to point out) isn't the amount of work needed to implement something, it's agreeing to change from the existing approach, and what new approach to use. there have been several different proposals, but until one of them is selected there isn't going to be much work done on any of them. David Lang___ 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
forking PAM to remove cracklib dependency
Hi,
pam currently depends on cracklib which brings in an 8.5mb dictionary.
It's quite easy to remove this dependency. Any objections to me
requesting a pam OLPC-3 branch and applying the attached changes on the
F-9 package?
This has been in joyride for the last few releases and nobody has
reported any breakage.
--- F-9/pam.spec 2008-05-21 04:37:37.0 -0400
+++ OLPC-3/pam.spec 2008-07-21 11:41:27.0 -0400
@@ -1,3 +1,4 @@
+%define minimal_build 1
%define db_version 4.6.21
%define db_conflicting_version 4.7.0
%define pam_redhat_version 0.99.9-1
@@ -5,7 +6,7 @@
Summary: A security tool which provides authentication for applications
Name: pam
Version: 1.0.1
-Release: 4%{?dist}
+Release: 5%{?dist}
# The library is BSD licensed with option to relicense as GPLv2+ - this option is redundant
# as the BSD license allows that anyway. pam_timestamp and pam_console modules are GPLv2+,
# pam_rhosts_auth module is BSD with advertising
@@ -48,13 +49,15 @@
%endif
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: cracklib, cracklib-dicts >= 2.8
Requires(post): coreutils, /sbin/ldconfig
BuildRequires: autoconf >= 2.60
BuildRequires: automake, libtool
BuildRequires: bison, flex, sed
-BuildRequires: cracklib-devel, cracklib-dicts >= 2.8
BuildRequires: perl, pkgconfig, gettext
+%if %{minimal_build} == 0
+Requires: cracklib, cracklib-dicts >= 2.8
+BuildRequires: cracklib-devel, cracklib-dicts >= 2.8
+%endif
%if %{WITH_AUDIT}
BuildRequires: audit-libs-devel >= 1.0.8
Requires: audit-libs >= 1.0.8
@@ -160,6 +163,9 @@
%if ! %{WITH_AUDIT}
--disable-audit \
%endif
+%if %{minimal_build} == 1
+ --disable-cracklib \
+%endif
--with-db-uniquename=_pam
make
# we do not use _smp_mflags because the build of sources in yacc/flex fails
@@ -230,6 +236,9 @@
%if ! %{WITH_SELINUX}
[ ${dir} = "modules/pam_selinux" ] && continue
%endif
+%if %{minimal_build} == 1
+[ ${dir} = "modules/pam_cracklib" ] && continue
+%endif
if ! ls -1 $RPM_BUILD_ROOT%{_moduledir}/`basename ${dir}`*.so ; then
echo ERROR `basename ${dir}` did not build a module.
exit 1
@@ -296,7 +305,9 @@
%{_moduledir}/pam_access.so
%{_moduledir}/pam_chroot.so
%{_moduledir}/pam_console.so
+%if %{minimal_build} == 0
%{_moduledir}/pam_cracklib.so
+%endif
%{_moduledir}/pam_debug.so
%{_moduledir}/pam_deny.so
%{_moduledir}/pam_echo.so
@@ -384,6 +395,9 @@
%doc doc/adg/*.txt doc/adg/html
%changelog
+* Mon Jul 21 2008 Daniel Drake <[EMAIL PROTECTED]> 1.0.1-5
+- remove cracklib support
+
* Wed May 21 2008 Tomas Mraz <[EMAIL PROTECTED]> 1.0.1-4
- pam_namespace: allow safe creation of directories owned by user (#437116)
- pam_unix: fix multiple error prompts on password change (#443872)
--- F-9/system-auth.pamd 2006-09-04 10:31:09.0 -0400
+++ OLPC-3/system-auth.pamd 2008-07-21 11:40:30.0 -0400
@@ -7,8 +7,7 @@
account required pam_unix.so
-passwordrequired pam_cracklib.so try_first_pass retry=3
-passwordsufficientpam_unix.so try_first_pass use_authtok nullok md5 shadow
+passwordsufficientpam_unix.so try_first_pass nullok md5 shadow
passwordrequired pam_deny.so
session optional pam_keyinit.so revoke
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [RFC] Four solutions to NAND fillup
guylhem wrote: > Hello > > A suggestion for similar problems, which I experienced in the past for > other hardware. > > The /var tree is mostly used for logs and caches - stuff that could be > discarded at reboot. And usually, there's a lof ot them (see with du > -ksh) > > There are some important subdirs that however should be kept. > > What I did : > /var is a link to some directory mounted as shmfs (there are various > ones, take the one you prefer) i think if you look closely at the XO you'll see that this is essentially already done, but the mechanism is slightly different than it might have been in the past. compare the output of "df" with "df /var/log", for instance, and look in /etc/rwtab. if you follow this through in rc.sysinit, you'll find that everything mentioned in /etc/rwtab is mounted on tmpfs. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems & GL/glx
On Fri, 2008-07-25 at 10:22 -0400, Ton van Overbeek wrote: > Just FYI. Tried to boot both joyride-2207 and joyride-2210 (the > devel-ext3 variant) on > qemu (on win XP/SP2) but both fail with the same error: > > (EE) AIGLX error: dlopen of /usr/lib/sri/swrast_dri.so failed > (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such > file or directory) > > Fatal server error: > GLX: could not load software rendered > > giving up. > - I found a bug in my patch, dlopen() is not documented to populate errno, but my patch was relying on that. I submitted a new build with the patch that went upstream which does not contain this assumption. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Congratulations! but Sugar sucks
|> 1. The datastore |> 2. OS Updates |> 3. File Sharing |> 4. Activity Modification |> 5. Bitfrost |> 6. Power management On Thu, Jul 24, 2008 at 11:02 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > On Thu, Jul 24, 2008 at 8:18 PM, Benjamin M. Schwartz > <[EMAIL PROTECTED]> wrote: > > really surprisingly short. Each item on the list has been debated to a > > stationary point over the last two years, so all that is left is to make > a > > final decision for the engineers to execute. Each task could be > completed > > or hugely improved by a single developer in a few months, provided that > we > > do not allow changes to the requirements, and the developers are not > asked > > to split their time and focus. > > I do not believe that either of these statements is correct. > > We are not lacking in decisions: we have substantially complete > designs; we are lacking implementation. > > Each of your items is not the work of "a single developer in a few > months": solving these problems is realistically a year's work at > least, if we have a single developer working full time on each. I have experience with numbers 1, 3, and 5, and am the principal person responsible for 4 right now. I would say that 3 and 4 are definitely within the "single dev in a few months" time frame; depending on the definition, 4 is in the "as soon as currently applied patches percolate into production" time frame. The further work on 4 - already started - is in the area of activity signatures, which is actually encroaching on 5. In a few full-time months of a single developer, this would put 4 at a place which other platforms could envy, and make concrete strides towards 5, to the point where security would be better, not worse, than other modern platforms (though I agree that there is plenty more work to fulfill the true promise of Bitfrost). I agree that 1 is not so simple; while a rockstar developer might be able to solve all our problems in a two-month all-nighter, 6 months to a year is a more realistic timeframe to get something really solid and stable. What I have accomplished - admittedly too slowly - on Develop, I have done in under half-time commitment. I have made it pretty clear that I was available for full-time work, pretty cheaply, but not for free. I could work to contract, with payment working out to around what the GSoC students are getting, and have Develop and Bitfrost in a significantly better place by the end of September (activity signatures done, bitfrost privileges by-application secure on that basis, the Terminal/Journal bitfrost "loophole" mendedl; Develop collaboration/source control starting to be usable). > > ps. and, of course, you've neglected "software for kids that does > things kids want to do", "powerful and pervasive collaboration" and > "mesh networking" in your list of items. All of which are slightly less sucky in their current state than the items mentioned, I think, but definitely need work too. To sum up: if this is a matter of resources, just hire people. Me, and others who want it - I have heard marcopg complaining that he should be full-time, I think. In my case, the worst that could happen is that I don't come through, and, since I am asking for contract work, that would mean you don't pay me, so it would be identical to current situation. The best would be that for less than the price of a classroom-full of XOs, you would get large steps on two of these list items in a couple of months. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [RFC] Four solutions to NAND fillup
Hello A suggestion for similar problems, which I experienced in the past for other hardware. The /var tree is mostly used for logs and caches - stuff that could be discarded at reboot. And usually, there's a lof ot them (see with du -ksh) There are some important subdirs that however should be kept. What I did : /var is a link to some directory mounted as shmfs (there are various ones, take the one you prefer) when no shm is mounted, this directory contain a "skeleton" /var to keep some apps happy during a reboot or in case something bad happen, like removing kernel shmfs support as soon as the first script is run and a shmfs is mounted, the skeleton /var is untarred. takes 1 second "important" subdirs that should be kept (you decide which) are links to normal locations. I use /srv. The symlinks are in the var skeleton tarball Of course the solution can be simplified and improved, like by keeping /var intact and instead using symlinks and a skeleton tarball for stuff you know you want to discard at reboot (/var/log...) but this approach forces me to consider each situation individually. By default whatever is not a symlink to a stable location (/srv) will automatically be discarded on next reboot. This may not be very pretty, but it is quite usefull. This provides room for fixing the situation because a simple reboot clears the log, giving enough space to at least run some delete commands. Guylhem ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems & GL/glx
On Fri, 2008-07-25 at 10:22 -0400, Ton van Overbeek wrote: > Just FYI. Tried to boot both joyride-2207 and joyride-2210 (the > devel-ext3 variant) on > qemu (on win XP/SP2) but both fail with the same error: > > (EE) AIGLX error: dlopen of /usr/lib/sri/swrast_dri.so failed > (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such > file or directory) > > Fatal server error: > GLX: could not load software rendered > > giving up. > - That's really odd, it looks like my patch didn't get applied, or the wrong X server build is creeping in, or something like that. Definitely works for me using freshly reflashed joyride-2210 (jffs2). Can you double check which version you are using? Also see which xserver is there, run "rpm -q xorg-x11-server-Xorg" Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: odd yum dependency issues in joyride
c. scott ananian wrote: > On Fri, Jul 25, 2008 at 10:43 AM, <[EMAIL PROTECTED]> wrote: > > i've been slowly moving my g1g1 machine forward to joyride (from 656). > > i had customized it quite a bit, and am trying to restore those changes. > > i've got xfce running, but a couple of yum dependencies (which were fine > > with F7) are failing. > > > > to wit: > > > > # yum install gcc > [...] > > --> Missing Dependency: glibc-common = 2.8-3 is needed by package > glibc-2.8-3.i686 (installed) > > Error: Missing Dependency: glibc-common = 2.8-3 is needed by package > glibc-2.8-3.i686 (installed) > > Seems strongly related to trac #5056. related, perhaps, but clearly new breakage, since a gcc install worked fine in 656. > > > # yum install firefox > [...] > > Error: Missing Dependency: gecko-libs = 1.9.0.1 is needed by package > firefox-3.0.1-1.fc9.i386 (olpc_development) > > Hmm, this might be a more fundamental mismatch, since we have a > specific version of gecko used for Browse. You could always download but didn't we always? (i.e., what's changed?) > the standalone (unpackaged .tar.gz) version of Firefox. sure. i could do that with a lot of things. :-) i'm willing for this machine to be in limbo for a while (useability-speaking) during joyride testing. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: odd yum dependency issues in joyride
On Fri, Jul 25, 2008 at 10:43 AM, <[EMAIL PROTECTED]> wrote: > i've been slowly moving my g1g1 machine forward to joyride (from 656). > i had customized it quite a bit, and am trying to restore those changes. > i've got xfce running, but a couple of yum dependencies (which were fine > with F7) are failing. > > to wit: > > # yum install gcc [...] > --> Missing Dependency: glibc-common = 2.8-3 is needed by package > glibc-2.8-3.i686 (installed) > Error: Missing Dependency: glibc-common = 2.8-3 is needed by package > glibc-2.8-3.i686 (installed) Seems strongly related to trac #5056. > # yum install firefox [...] > Error: Missing Dependency: gecko-libs = 1.9.0.1 is needed by package > firefox-3.0.1-1.fc9.i386 (olpc_development) Hmm, this might be a more fundamental mismatch, since we have a specific version of gecko used for Browse. You could always download the standalone (unpackaged .tar.gz) version of Firefox. Dennis? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems & GL/glx
On Fri, Jul 25, 2008 at 10:22 AM, Ton van Overbeek <[EMAIL PROTECTED]> wrote: > Just FYI. Tried to boot both joyride-2207 and joyride-2210 (the > devel-ext3 variant) on > qemu (on win XP/SP2) but both fail with the same error: > > (EE) AIGLX error: dlopen of /usr/lib/sri/swrast_dri.so failed > (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such > file or directory) > > Fatal server error: > GLX: could not load software rendered > > giving up. > - > Is this something specific for emulation ??? Hmm, looks like our xorg.conf for qemu needs some adjustment? Daniel? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot boot joyride-2200 from USB stick
On Fri, Jul 25, 2008 at 1:40 AM, Deepak Saxena <[EMAIL PROTECTED]> wrote: > On Jul 24 2008, at 11:46, Deepak Saxena was caught saying: >> > Tried with your version of 14:57 (2720066 bytes). Same result. Same >> > messages, still failure to mount /dev/sda1. >> > Apologies for the disappointing result. Do we need more/other scsi >> > modules? Can we get more debug info from mount? >> >> We shouldn't need anything else from my experimenting. I need to run for a >> few >> hours but will look at this when I return. > > :( Sigh. :( I just realized I don't have a 1G USB stick at the moment. My 1G > XD card does not seem to work properly with my card reader, so writes to > it do not properly complete and I can't copy the boot image over. This bug > is high on my priority list, so I'll be running to the store and getting > one tommorrow. > > ~Deepak > One more datapoint. Tried to boot joyride-2207 on my XO-1 from USB using the devel-ext3 image. Good news: no more missing usb modules. Bad news: still the same mount problem. So I can confirm olpcrd is fixed in the later joyrides. Waiting for more news Ton van Overbeek ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
odd yum dependency issues in joyride
i've been slowly moving my g1g1 machine forward to joyride (from 656). i had customized it quite a bit, and am trying to restore those changes. i've got xfce running, but a couple of yum dependencies (which were fine with F7) are failing. to wit: # yum install gcc olpc_development | 2.5 kB 00:00 primary.sqlite.bz2 | 6.1 MB 00:41 Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package gcc.i386 0:4.3.0-8 set to be updated --> Processing Dependency: binutils >= 2.17.50.0.17-3 for package: gcc --> Processing Dependency: glibc-devel >= 2.2.90-12 for package: gcc --> Running transaction check ---> Package binutils.i386 0:2.18.50.0.6-4.fc9 set to be updated ---> Package glibc-devel.i386 0:2.8-8 set to be updated --> Processing Dependency: glibc-headers = 2.8-8 for package: glibc-devel --> Processing Dependency: glibc = 2.8-8 for package: glibc-devel --> Running transaction check ---> Package glibc.i386 0:2.8-8 set to be updated --> Processing Dependency: glibc-common = 2.8-8 for package: glibc ---> Package glibc-headers.i386 0:2.8-8 set to be updated --> Processing Dependency: kernel-headers for package: glibc-headers --> Processing Dependency: kernel-headers >= 2.2.1 for package: glibc-headers --> Running transaction check ---> Package kernel-headers.i386 0:2.6.25.11-97.fc9 set to be updated ---> Package glibc-common.i386 0:2.8-8 set to be updated --> Processing Dependency: glibc-common = 2.8-3 for package: glibc --> Finished Dependency Resolution glibc-2.8-3.i686 from installed has depsolving problems --> Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i686 (installed) Error: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i686 (installed) and: # yum install firefox Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package firefox.i386 0:3.0.1-1.fc9 set to be updated --> Processing Dependency: gecko-libs = 1.9.0.1 for package: firefox --> Processing Dependency: system-bookmarks for package: firefox --> Running transaction check ---> Package fedora-bookmarks.noarch 0:8-1 set to be updated ---> Package firefox.i386 0:3.0.1-1.fc9 set to be updated --> Processing Dependency: gecko-libs = 1.9.0.1 for package: firefox --> Finished Dependency Resolution firefox-3.0.1-1.fc9.i386 from olpc_development has depsolving problems --> Missing Dependency: gecko-libs = 1.9.0.1 is needed by package firefox-3.0.1-1.fc9.i386 (olpc_development) Error: Missing Dependency: gecko-libs = 1.9.0.1 is needed by package firefox-3.0.1-1.fc9.i386 (olpc_development) if these are expected issues, fine, but they seem a little odd. is it possible that it's breakage caused by our upgrade scheme -- i.e., are some pieces of the old yum metadata left around that are causing the confusion? i'll trac it if anyone thinks i should. oh -- it's joyride 2159, i think, from sometime last week. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems & GL/glx
On Thu, Jul 24, 2008 at 9:44 PM, Daniel Drake <[EMAIL PROTECTED]> wrote: > Just a quick FYI: the keyboard bugs in recent joyrides (various buttons > not working or misbehaving) is fixed by the X server update in joyride 2207. > > The problem was that a Fedora 9 update included an updated evdev driver, > which had been compiled against a newer X server (we have forked > xserver, so we don't automatically get updates there). I have resynced > our xserver with Fedora's so we support the new ABI which evdev uses. > > Resyncing the X server was not quite as simple as you might expect. > Previously, X was compiled along with the mesa sources to offer > software-based GL. The software GL is very slow but word on the street > is that some activities use it anyway. > > In the newer X server, the software GL implementation (dri_swrast) has > been moved to mesa, which we don't include in our builds. The newer X > server also includes a bug which caused it to crash when no swrast was > present, I wrote a patch included in our build which I will be > committing to freedesktop git upstream shortly... > > Anyway, at the moment, we have no swrast in our build, which means no GL > support at all. Does anyone care? > I am going to work with Fedora to get the swrast module separated from > the overweight mesa-dri-drivers - this could return in future if we need it. > > Sorry for any inconvenience, this was the most straightforward way of > getting a working X and a working keyboard again. > > Daniel Just FYI. Tried to boot both joyride-2207 and joyride-2210 (the devel-ext3 variant) on qemu (on win XP/SP2) but both fail with the same error: (EE) AIGLX error: dlopen of /usr/lib/sri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory) Fatal server error: GLX: could not load software rendered giving up. - Is this something specific for emulation ??? Ton van Overbeek ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Congratulations! but Sugar sucks
Am 24.07.2008 um 17:53 schrieb Benjamin M. Schwartz: > Bert Freudenberg wrote: > | Am 24.07.2008 um 14:25 schrieb Benjamin M. Schwartz: > | > |> 1. The datastore > |> 2. OS Updates > |> 3. File Sharing > |> 4. Activity Modification > |> 5. Bitfrost > |> 6. Power management > | > | Note that half of these items have nothing to do with Sugar, oo the > | subject line is a bit misleading. > > Every one of them requires work on the Linux-based software stack that > runs on the XO. The name of that stack is Sugar, as far as I'm aware. > Perhaps a breakdown would be helpful: > > 1. The datastore: Glucose > 2. OS Updates: Ribose. (Ribose is all the low-level software that > keeps > Sugar running on the XO) > 3. File Sharing: Glucose > 4. Activity Modification: Glucose and Fructose. > 5. Bitfrost: Glucose and Ribose. > 6. Power management: Glucose, Ribose, and EC. I don't think that taxonomy actually has caught on. Commonly, only the "fructose" and "glucose" layers are referred to as "Sugar" (as for example discussed on the Sugar list) - basically, the UI and parts it directly depends on (datastore, presence). This is the stuff most directly impacting the learning experience, whereas bitfrost, power management, and OS updates are both of more general use (e.g., I'd love to see bitfrost-like security in my desktop, too) and not directly visible to the learner. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems & GL/glx
2008/7/25 Martin Dengler <[EMAIL PROTECTED]>: > On Fri, Jul 25, 2008 at 08:10:21AM -0400, Chris Marshall wrote: > >> For a lot of applications, using the 3D framework with the simpler >> geometries and more image-oriented, a software OpenGL can be quite >> acceptable. > > Forgive the uninformed question, but this would be a requirement for > clutter to run on the XO, right? >From http://clutter-project.org/: "Runs on Linux, Windows and OSX with backend window system support for GLX, EGL, WGL, SDL and Cocoa." We support SDL; that's what all our pygame activities use. I believe we are only specifically talking about GLX support (that's OpenGL directly implemented by the X server) at this time. Since we're doing software rendering in any case, GLX (Mesa in the X server) is not substantially differenent from linking Mesa directly to your application. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems & GL/glx
On Fri, Jul 25, 2008 at 08:10:21AM -0400, Chris Marshall wrote: > For a lot of applications, using the 3D framework with the simpler > geometries and more image-oriented, a software OpenGL can be quite > acceptable. Forgive the uninformed question, but this would be a requirement for clutter to run on the XO, right? > --Chris Martin pgpYQx25BxKzA.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SMS messaging
Le jeudi 24 juillet 2008 à 09:59 +0200, Guillaume Desmottes a écrit : > The plan with Gadget is to allow user to request random buddies (and > activities) or perform search based on different criteria. As you can > see on [1], currently only search based on buddy properties is > implemented but we plan to add alias search soon (maybe next week if you > really need it). I implemented search by alias using Gadget. The gadget branch is not merged yet and the Gabble one is http://monkey.collabora.co.uk/telepathy-gabble-gadget/ See http://people.collabora.co.uk/~cassidy/spec-olpc-gadget.html#org.laptop.Telepathy.Gadget for the API. G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems & GL/glx
Daniel Drake wrote: > Resyncing the X server was not quite as simple as you might expect. > Previously, X was compiled along with the mesa sources to offer > software-based GL. The software GL is very slow but word on the street > is that some activities use it anyway. > > ... > > Anyway, at the moment, we have no swrast in our build, which means no GL > support at all. Does anyone care? > One thing OpenGL has going for it is portability and availability. There was some wiki mention of interest in one of the embedded subset OpenGL implementations. Did anything ever come from that? The slowness is only relative to modern GPU speed. For a lot of applications, using the 3D framework with the simpler geometries and more image-oriented, a software OpenGL can be quite acceptable. --Chris > I am going to work with Fedora to get the swrast module separated from > the overweight mesa-dri-drivers - this could return in future if we need it. > > Sorry for any inconvenience, this was the most straightforward way of > getting a working X and a working keyboard again. > > 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: Calling all small keyboards
I left my Sinclair in the 1CC conference room. It probably qualifies as well. -walter On Thu, Jul 24, 2008 at 3:29 PM, John Watlington <[EMAIL PROTECTED]> wrote: > > We are looking for examples of keyboards for small children > present before 1993. > > Specifically, we are looking for keyboards whose key-key spacing > is between 10.8 and 16.4 mm horizontally, and 10.8 to 18.0 mm > vertically, and with a stroke distance of 0.9 to 6mm. > > Thanks for your memories, > wad > > http://www.google.com/patents?vid=USPAT7354209 > http://www.google.com/patents?vid=USPAT7101101 > http://www.google.com/patents?vid=USPAT5531529 > > ___ > 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
New joyride build 2210
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2210 Changes in build 2210 from build: 2208 Size delta: 0.00M -libertas-usb8388-firmware 2:5.110.22.p14-1.fc9 +libertas-usb8388-firmware 2:5.110.22.p17-1.olpc2 -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
