Re: Wellington smoketest notes - joyride-2270
Hi Martin, Good feedback. On 9 Aug 2008, at 05:08, Martin Langhoff wrote: - Sugar: in the activities List View, the time column does not display last used (perhaps it displays install time?), and the counter does not match number of times used, nor number of documents (what does it count?). The list view time column seems to be the install date, but more than that, it seems to be related to activity bundle creation date (I have an old Activity that when installed fresh from the wiki appears as 5 months ago). The counter column is actually the activity version information. I saw talk somewhere about adding title bars so these columns (and the list view in Journal) would be clearly named (and potentially sortable), perhaps we'll see that in the 9.1.0 release timeframe. --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Proposal: Activity developers mailing list
On Sat, Aug 2, 2008 at 15:23, Morgan Collett [EMAIL PROTECTED] wrote: On Thu, Jul 31, 2008 at 11:47, Morgan Collett [EMAIL PROTECTED] wrote: On Thu, Jul 31, 2008 at 04:42, Bastien [EMAIL PROTECTED] wrote: Any follow-up on the idea of having a precise list of maintainers for all Sugar activities? Even just the email address from the git repo would be nice. I've raised the idea a couple of times to have a mailing list specifically for activity developers, which would be uncluttered by all the traffic on the devel and even sugar lists. That would hopefully have the result that people stay subscribed, or at least notice mails which are important to them. Currently, I'm not even sure which list out of devel and sugar is going to reach more activity developers, hence this cross-post and many others. There are a bunch of issues I'm aware of which need to be communicated clearly and widely: * A lot of activities need updating. There are a good number of us who can help, if we can get the attention of the original / most recent maintainers/authors. We would be willing to do new releases, and we will do so (technically forking) without their help if we don't get their attention. * There is a new activity updater in the control panel in joyride. There is a certain procedure to provide specific versions of the activity for specific builds, so that (future) stable builds get a certain version available, whereas development builds can get other versions of the activity. The exact procedures around that need to be communicated, in such a way that a significant number of activity developers *do* them. * It would be great to have a specific procedure for someone to say I developed this activity, I don't have time to maintain it against future releases, it's available for someone to take over. I suspect several interesting activities are in this position. * We need a way to communicate API changes, new resources, etc to activity developers without this getting lost in the noise of the existing lists. We need a way to get clear feedback on these without getting swamped by non activity developers. * We need to make it easier for new activity developers to get up to speed without having to wade through information they don't need. I am happy to take on making this communication happen but I really think we need this list. I know it's yet another mailing list, but I think it will help make our communication more focussed and effective. I'm adding this to the agenda of today's (tonight's for me) Sugar development meeting. Please comment here in advance of the meeting, or come to the meeting for a more immediate discussion. Morgan We didn't get to discuss this activity developers' mailing list at the Sugar meetings. However I've had no negative feedback. If anyone is opposed to this list, please speak up quickly and loudly. Otherwise I will get it created in the next week, publicize it and invite all known activity developers whose email addresses I can track down to subscribe. My only question is whether this should be @lists.laptop.org or @lists.sugarlabs.org. Please comment, or I will make it the latter by default. Regards Morgan I'm surveying activity developers of non-current activities - I tracked down email addresses from git logs and past posts to mailing lists. I'll send out a report once I get a significant number of responses. It does seem like we should address the sugar list moving over to sugarlabs.org first before considering other changes. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Datastore profiling
Hi, Testcase: Fill the datastore with `many small' objects. Build: 2266 The test was automated with the script at: http://dev.laptop.org/~rlucchese/datastore_fill/fill_ds For this test only the _TEST_SMALL_FILES flag was set in `fill_ds' and the following cmdline was used: $ fill_ds -s sources/ -b 2000 The `sources' dir I used can be found at: http://dev.laptop.org/~rlucchese/datastore_fill/sources/ Before running the script all entries in the datastore were deleted. + Macro investigation of cpu usage A picker graph taken during the test can be found at: http://dev.laptop.org/~rlucchese/datastore_fill/small_files__b2000.picker.svg (http://dev.laptop.org/~rlucchese/datastore_fill/small_files__b2000.picker) The following tab shows cpu usage of the 3 processes that took more cpu time during the sampling time: ($ grapher -c2 -n -r cpu -i small_files__b2000.picker) tot% ps% cmdline --- 55.0python /usr/bin/datastore-service 86.7 31.7python /usr/bin/sugar-activity journalactivity.JournalActivity - During the test the `favorites view' was shown and I think I was told the journal shouldn't take cpu time to update itself in this case. What is it doing than ? + Test log http://dev.laptop.org/~rlucchese/datastore_fill/small_files__b2000.log It took 123+ seconds to fill the datastore with 484 files (total size 20041624 bytes; files pushed to the datastore where text_s.txt, text_s.odt and img_s.jpg from the sources dir linked above). The 123s value is very stable when repeating the test. + cProfile statistics (KCG format) for the datastore: http://dev.laptop.org/~rlucchese/datastore_fill/small_files__b2000.cProfile * functions ordered by self-time: 23.8 posix.write 16.8 send_message of _dbus_bindings.Connection 9.6 _database_gen_allterms_iter of xapian.py 4.2 flush of secore/indexerconnection.py 2.6 add of secore/indexerconnection.py 2.3 cPickle.dumps 2.perform of secore/fieldactions.py 1.7 _act_index_freetext of secore/fieldactions.py 1.6 index of datastore/xapianindex.py 64.6% I/O performance and dbus are predominant in results. As I said, I'm not sure the journal should be so `active' during the test; in the case it would be more interesting to repeat the test after a fix. + Sysprof statistics: http://dev.laptop.org/~rlucchese/datastore_fill/small_files__b2000.sysprof I can't see anything relevant for libxapian and it's bindings (xapian dbg packages were installed) Quite a bit of time goes to librsvg functions rendering svg icons to GtkPixbufs. Attaching strace to the journal activity and grepping open on its output gives: ... open(/usr/share/icons/sugar/scalable/mimetypes/text-x-generic.svg, O_RDONLY|O_LARGEFILE) = 11 open(/usr/share/icons/sugar/scalable/mimetypes/image-x-generic.svg, O_RDONLY|O_LARGEFILE) = 11 open(/usr/share/icons/sugar/scalable/mimetypes/audio-x-generic.svg, O_RDONLY|O_LARGEFILE) = 11 open(/usr/share/icons/sugar/scalable/mimetypes/video-x-generic.svg, O_RDONLY|O_LARGEFILE) = 11 open(/usr/share/icons/sugar/scalable/mimetypes/text-uri-list.svg, O_RDONLY|O_LARGEFILE) = 11 open(/usr/share/icons/sugar/scalable/mimetypes/text-x-generic.svg, O_RDONLY|O_LARGEFILE) = 11 open(/usr/share/icons/sugar/scalable/mimetypes/image-x-generic.svg, O_RDONLY|O_LARGEFILE) = 11 open(/usr/share/icons/sugar/scalable/mimetypes/audio-x-generic.svg, O_RDONLY|O_LARGEFILE) = 11 open(/usr/share/icons/sugar/scalable/mimetypes/video-x-generic.svg, O_RDONLY|O_LARGEFILE) = 11 ... Does this come from sugar.mime or any sugar component ? If yes, would it be possible to share one icon-cache between all sugar modules ? Thanks, riccardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Please help test our new 8.2.0 weekly beta, joyride-2263!
On Thu, Aug 7, 2008 at 8:45 PM, Michael Stone [EMAIL PROTECTED] wrote: We are thrilled to announce a new test build, joyride-2230, valid until Wednesday, August 13. Please help test it according to the detailed instructions at http://wiki.laptop.org/go/Friends_in_testing while we still have time to fix issues you might find! Our specific interest this week continues to be activity compatibility: Does your favorite activity still run on joyride-2263? Currently known issues are recorded at: http://wiki.laptop.org/go/Test_Group_Release_Notes#Build_Joyride_2263 New issues should be filed in our bug-tracking system (dev.laptop.org) according to http://wiki.laptop.org/go/Submitting_bugs or by notifying us by other means. Thanks! Michael This isn't really a bug but rather a general observation so I'm not quite sure where to put it... When you're in the software-update panel of the control-panel then there are cancel and ok buttons in the upper right corner. However the ok button seems redundant as they both do exactly the same thing: close the panel and take you back to the main configuration screen. At least that's the case when the software is up-to-date. IIRC you also need to press a button inside the panel for updating when there's new software available which would again make the ok-button redundant. Cheers, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wellington smoketest notes - joyride-2270
On Sat, Aug 09, 2008 at 04:08:53PM +1200, Martin Langhoff wrote: - Filling up on the disk -- log of one test using the journal, copying large files from usb drives. XO behaves mostly normal (with Browse and chat) up to 10M free (df -f says 11M free). At that point: - Opening Write fails with no msg - Opening Record fails with no msg I am unsurprised that that activities fail to launch in low-space conditions given the degree to which Rainbow's design is based on tweaking the filesystem. (There may be other problems as well, but this one will surely occur once truly low-space conditions are hit.) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
inhibiting suspend via dbus
As it turns out, the activity update control panel needs to inhibit suspend, too, otherwise we go to sleep in the middle of downloading large activities (Firefox, TamTam, etc). Chris, could you make a little wiki page explaining how to interact w/ ohm via dbus to temporarily inhibit suspend, and send me the [[link]]? I figure other people who want to do other long-lived tasks could use this information, too; it should perhaps be included in the activity API docs. (Does Browse properly inhibit suspend during download? It probably should.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
clear/reset buddy info
Maybe this is in a FAQ somewhere but I could not find it: How can one reset the buddy list information/database? I've changed nicknames/colors and the name changed but the associated colors have not changed on any of the XOs I've made friends with before the color changes... Thanks, Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Read Etexts problems with speech-dispatcher resolved -- mostly
As noted here before, using a multi-threaded activity interferes with power management. Read Etexts will have functioning power management if speech-dispatcher is not installed, but will not if it is installed, even if you never use the Speech feature. I did explore a few solutions to the problem and make the speechd API use gobjects to make the communication with the speech server asynchronous. I believe a certain bugfix in python 2.6 will resolve the problems we are facing, The bug has been fixed! There's no need to avoid multi-tasking Python programs any more. It's fixed in python-2.6, PyGOboject 2.14.1, and PyGTK 2.12.1. See http://dev.laptop.org/ticket/4680#comment:12 The 8.2.0 release candidates in Joyride already include those releases of PyGObject and PyGTK, and uses python-2.5 with the bug fix back-ported from python-2.6. It's trivial to tell whether your Python activity has this polling problem that burns up power: just run it, and from another terminal, find its process number(s) and run strace -p on them. If the activity is sitting there doing nothing, but the strace chatters on with system call after system call, you have a polling bug. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO keeps staring at its own belly button
On Fri, Aug 08, 2008 at 09:23:57PM -0700, Ixo X oxI wrote:
On Fri, Aug 8, 2008 at 14:55, Andrew Burgess [EMAIL PROTECTED] wrote:
Have you tried with a swap partition? Swap is robust now on a SD
card, immune to suspend/resume and power cycle.
External swap area sounds cool. How does one set it up? I'll give
it a whirl.
I'd also plug compcache-0.3[1]; it's been working very well for me
without the need for an external swap device.
-iXo
Martin
1. From http://code.google.com/p/compcache/
On joyride this works for me:
sudo su -
yum -y install make autotools gcc
wget http://dev.laptop.org/~dilinger/{stable,testing}/kernel-devel-`uname
-r`.i586.rpm
rpm -ivh kernel-devel-`uname -r`.i586.rpm
cp -af /boot/* /versions/boot/current/boot/
wget http://compcache.googlecode.com/files/compcache-0.3.tar.gz
tar xzf compcache-0.3.tar.gz
cd compcache-0.3
make
./use_compcache.sh
pgpq4OrF0mRgo.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: inhibiting suspend via dbus
As it turns out, the activity update control panel needs to inhibit suspend, too, otherwise we go to sleep in the middle of downloading large activities (Firefox, TamTam, etc). Chris, could you make a little wiki page explaining how to interact w/ ohm via dbus to temporarily inhibit suspend, and send me the [[link]]? I figure other people who want to do other long-lived tasks could use this information, too; it should perhaps be included in the activity API docs. (Does Browse properly inhibit suspend during download? It probably should.) No, this is the wrong approach. We shouldn't be patching every program to avoid suspending at various times. We should be improving the heuristic that the system (Ohm) uses to decide when to suspend. Once we have better information from the kernel about what the running processes are doing, we'd just have to rip out all the little kludges inserted into every program. Normally, when a TCP connection is active, even a suspended XO should break out of suspend when the next packet arrives from the other end. Only if it happens to suspend in the brief interval between receiving that packet and asking for the next one, will such a suspend persist indefinitely. But there may be bugs there (e.g. #6528). We already have bugs because Read was hacked to force suspends, and it turns out it's suspending at the wrong times (#6645, #6684). Let's not add more bugs by hacking more activities to force or unforce suspends. We should understand why ohm isn't noticing that the activity updater isn't idle. Should Ohm be looking for a higher cpu idle% in the seconds before it suspends? Should it be looking for minimal numbers of context switches per second before it suspends? What does the system look like when the updater is running? If we can confine our suspend-kludge patches to one place (ohm) we'll be much better off in the medium and long term. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Read 49 on Joyride (was Re: Evince)
I tried Read 49 on joyride-2273. On Tue, 2008-07-29, Daniel Drake replied: The rpm changelog suggested [that Read supports DjVu]. Can you try it out with a recent joyride? The needed djvulibre library is in the build. Trying the DjVu samples at http://djvu.org/docs/ , Read recognizes it's e.g. a 10-page file. But I had weird behavior: nothing displayed until I zoomed out, page back would make machine very slow, zooming in again would hang, etc. I updated http://dev.laptop.org/ticket/6223#comment:18 ; note this is a Milestone 9.1.0/9.1.0:+ bug. Also TIFF display in Read continues to have glitches as it did in Update.1, http://dev.laptop.org/ticket/7166 So I updated http://wiki.laptop.org/go/Release_Notes/8.2.0#Activity_Issues to say: Read only works well as a PDF viewer. You can start other file formats in Read from the Journal but may have problems. Reading the Sugar handbook PDF from the library, zooming to 400% and then page forward and back (I always click the wrong game pad buttons in eBook mode :-/ ) leads to really slow performance until Read dies. So I reopened http://dev.laptop.org/ticket/7090 , sorry if that's the wrong process. These could all be manifestations of Evince memory handling. http://dev.laptop.org/ticket/6002 is closed, upstream is http://bugzilla.gnome.org/show_bug.cgi?id=303365 -- Is there a way to tell that my XO is low on memory, or was low on memory just before a crash? I don't see anything about low memory in the Read activity log or sugar logs. I got the Keep error every time I stopped the Read activity, I added some log output to http://dev.laptop.org/ticket/7843 Thanks for the new software, what's the OLPC PayPal account :) -- =S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wellington smoketest notes - joyride-2270
On Sun, Aug 10, 2008 at 3:16 AM, Michael Stone [EMAIL PROTECTED] wrote: On Sat, Aug 09, 2008 at 04:08:53PM +1200, Martin Langhoff wrote: - Filling up on the disk -- log of one test using the journal, copying large files from usb drives. XO behaves mostly normal (with Browse and chat) up to 10M free (df -f says 11M free). At that point: - Opening Write fails with no msg - Opening Record fails with no msg I am unsurprised that that activities fail to launch in low-space conditions given the degree to which Rainbow's design is based on tweaking the filesystem. I also expected them to fail. Propagating the error back to the UI is perhaps what I'd call the bug. m -- [EMAIL PROTECTED] [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
Re: Wellington smoketest notes - joyride-2270
On Sun, Aug 10, 2008 at 12:08 AM, Gary C Martin [EMAIL PROTECTED] wrote: Good feedback. Thanks. Overall the system was *very* usable and quite satisfactory to play with, until the point where the presence service lost the plot. We did a complete poweroff of all the machines involved, and that helped. - Sugar: in the activities List View, the time column does not display last used (perhaps it displays install time?), and the counter does not match number of times used, nor number of documents (what does it count?). The list view time column seems to be the install date, but more than that, it seems to be related to activity bundle creation date (I have an old Activity that when installed fresh from the wiki appears as 5 months ago). The counter column is actually the activity version information. I saw talk somewhere about adding title bars so these columns (and the list view in Journal) would be clearly named (and potentially sortable), perhaps we'll see that in the 9.1.0 release timeframe. Would last used be a better date to display? m -- [EMAIL PROTECTED] [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
Re: Please help test our new 8.2.0 weekly beta, joyride-2263!
Christoph Derndorfer wrote: When you're in the software-update panel of the control-panel then there are cancel and ok buttons in the upper right corner. However the ok button seems redundant as they both do exactly the same thing: close the panel and take you back to the main configuration screen. A variant of http://dev.laptop.org/ticket/7643 ? -- =S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Motivation behind recent selections of tickets marked blocks?:8.2.0?
John, I've noticed you tagging lots of tickets over the last few days for consideration as 8.2.0 blockers. Some of your selections make good sense to me, like the GPL tickets (#4265), but others make less sense to me, like the debuginfo packages issue (#4264), the TurtleArt naming issue (#5941), the boot-lock/pretty-boot coupling issue (#7896), and the grab-bag of quality issues (#7413). Could you say a few words about the vision underlying your choices so that I can compare it to my own understanding of what the 8.2.0 release needs to accomplish? Thanks, Michael P.S. - Thanks very much for all the time you've spent combing Trac for tickets that matter to you and bringing them to our collective attention; I wish that more people were equally generous. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: inhibiting suspend via dbus
We shouldn't be patching every program to avoid suspending at various times. We should be improving the heuristic that the system (Ohm) uses to decide when to suspend. Once we have better information from the kernel about what the running processes are doing, we'd just have to rip out all the little kludges inserted into every program. Currently no good definition of criteria exists. I've seen two situations where I need 'inhibit-idle-suspend'. My current attitude is -- I'll set that flag manually when I'm doing these things, and will clear that flag when I can again tolerate suspend: (1) While downloading. I use ethernet, and it has been explained to me that this uses *less* CPU than the keep-alive processes for which Ohm makes an allowance. (2) While running a background computation. It has been suggested that I should use a wrapper, which sends notifications to Ohm. But this is someone else's binary, and uses dynamic dispatching of executables. I really really don't want to monkey with it. One possibility -- OFW already tests for is the XO plugged in?. Maybe Ohm can test for that, and decide that suspend is not needed when the battery is fully charged, and is not being drained. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Python multithreaded GTK programs are still polling in F9, F10
The bug has been fixed! There's no need to avoid multi-tasking Python
programs any more. It's fixed in python-2.6, PyGOboject 2.14.1, and
PyGTK 2.12.1. See http://dev.laptop.org/ticket/4680#comment:12
The [OLPC] 8.2.0 release candidates in Joyride already include those
releases of PyGObject and PyGTK, and uses python-2.5 with the bug
fix back-ported from python-2.6.
I spoke too soon. We have fixes in the Joyride releases, but they
were never tested, and they don't work yet. See:
http://dev.laptop.org/ticket/4678#comment:4
and
http://bugzilla.gnome.org/show_bug.cgi?id=481569
Every multi-threaded Python GTK program in OLPC (and F9, and
F10-Alpha) is still polling once a second. You can easily see this by
doing strace on the sugar-shell Python process.
The test in ./configure in pygobject2-2.15.1-2.fc10.src.rpm uses C to
look in /usr/include/Python.h for PySignal_SetWakeupFd(). There's no
such thing in the Python header files or executable, though. The patch in
python-2.5.1-25.fc9.src.rpm inserts a static function in
signalmodule.c, and adds it to the signal_methods table so that it's
visible from Python. (The changelog says Resolves: rhbz#427794.)
But the changes are not visible from C. I also checked the F9 and F10-Alpha
binaries; they're compiled without this fix.
Aha! The patch file that F9 included is #4 from the Python bug
entry here:
http://bugs.python.org/issue1583
But one day later, upon request, Guido van Rossum added a simple C API
as well, patching Include/pyerrors.h and adding a ten-line public
PySignal_SetWakeupFd function to Modules/signalmodule.c. Those
changes were just made in SVN though; not in a patch file. Those
final changes, including the C API, mistakenly did not get patched
into Fedora's Python-2.5.1 (neither for F9 nor for F10-Alpha).
So one bug is in Fedora's Python-2.5.1; the patch file
python2.6-set_wakeup_fd4.patch needs to be updated to include Guido's
final version from:
http://svn.python.org/view?rev=59574view=rev
The needed change in signalmodule.c is to add these 10 lines:
/* C API for the same, without all the error checking */
int
PySignal_SetWakeupFd(int fd)
{
int old_fd = wakeup_fd;
if (fd 0)
fd = -1;
wakeup_fd = fd;
return old_fd;
}
plus two lines in Include/pyerrors.h:
/* In signalmodule.c */
int PySignal_SetWakeupFd(int fd);
There's apparently another bug in the gtk code that tries to use this
facility; Gnome bug 481569 referenced above gives a litany of
attempts to get this right, but it may not be there yet.
Soon, if the Python in F10 and/or OLPC is fixed, and its pygobject is
recompiled using that Python into a new binary package, and pygtk is
fixed properly, Python multithreaded programs will stop their needless
polling. We're getting very close...
John Gilmore
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: XO keeps staring at its own belly button
Looks like a useful tool/application.. so I started a laptop.org/wiki page
for it.
http://wiki.laptop.org/go/Compcache
I don't have an XO in front of me now to fully develop the page, but if
someone installs and uses it, please update the page with any information
you discover..
Thanks! :) -iXo
2008/8/9 Martin Dengler [EMAIL PROTECTED]
On Fri, Aug 08, 2008 at 09:23:57PM -0700, Ixo X oxI wrote:
On Fri, Aug 8, 2008 at 14:55, Andrew Burgess [EMAIL PROTECTED] wrote:
Have you tried with a swap partition? Swap is robust now on a SD
card, immune to suspend/resume and power cycle.
External swap area sounds cool. How does one set it up? I'll give
it a whirl.
I'd also plug compcache-0.3[1]; it's been working very well for me
without the need for an external swap device.
-iXo
Martin
1. From http://code.google.com/p/compcache/
On joyride this works for me:
sudo su -
yum -y install make autotools gcc
wget
http://dev.laptop.org/~dilinger/{stable,testing}/kernel-devel-`unamehttp://dev.laptop.org/%7Edilinger/%7Bstable,testing%7D/kernel-devel-%60uname-r`.i586.rpm
rpm -ivh kernel-devel-`uname -r`.i586.rpm
cp -af /boot/* /versions/boot/current/boot/
wget http://compcache.googlecode.com/files/compcache-0.3.tar.gz
tar xzf compcache-0.3.tar.gz
cd compcache-0.3
make
./use_compcache.sh
___
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
[Server-devel] Reschedule XS meeting for Friday Aug 15 - or 10 PM Aug 14 EST ---- was (Re: not up for Friday meeting about the XS)
feeling better now, antibiotics really work :) How about same time this upcoming Friday? Will work on an agenda w/ David on Monday. I see the key purpose of this meeting is to let you folks what additional functionality we are working on for Nepal's XS and to make sure that our additions don't conflict w/ future changes to the underlying XS. Here is the additional stuff we are looking to build into the XS over the next 6 months: 1) Customized Nepali version of Moodle 2) Mail server using Squirrel Mail* 3) Setting up a local version of Nepal's E-Library on the XS, a copy of Nepal's current E-Library http://pustakalaya.olenepal.org which uses the open-source fedora-commons repository software. 4) and more stuff that I can't remember at the moment. 5) Connecting schools through ejabberd * Some of these changes are targeted more at the teachers than the kids. We are concerned that the teachers are using the XO's much less than the kids and thus less familiar w/ them. We think e-mail is a relatively easy way to get them to use the XO to the amount of effort to get it running consistently. VoIP would be more effective but would require much more effort. On Thu, 2008-08-07 at 20:01 -0400, Jim Gettys wrote: On Fri, 2008-08-08 at 08:48 +1200, Martin Langhoff wrote: On Fri, Aug 8, 2008 at 3:48 AM, Greg Smith [EMAIL PROTECTED] wrote: I'm OK with reschedule. How about next week at the same time? Hope you feel better soon. Same here. Postpone 7 days? Can Jim make it too next week? I think so. - Jim -- Bryan W. Berry Systems Engineer OLE Nepal, http://www.olenepal.org ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Reschedule XS meeting for Friday Aug 15 - or 10 PM Aug 14 EST ---- was (Re: not up for Friday meeting about the XS)
On Sat, Aug 9, 2008 at 7:47 AM, Michael Stone [EMAIL PROTECTED] wrote: On Sat, Aug 09, 2008 at 12:11:56PM +0545, Bryan Berry wrote: VoIP would be more effective but would require much more effort. Fedora recently set up its own VOIP system, so there may be experts lurking nearby who could be tempted into assisting you. Michael ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel I'm no VoIP expert, but I played with it for a bit on different distros. Trixbox (http://www.trixbox.org/) is CentOS based and is very featureful. On the other hand, Astlinux (http://www.astlinux.org/) is very interesting in that it has a very small footprint. Astlinux runs off a CF card (64MB if I remember correctly). You can also run it off a bootable CD. All the config is browser-based, and all the config files live on a separate USB key (or any other partition). I suspect we will need something in between. Also along the lines of VoIP clients, I've been looking at IAX2 (http://en.wikipedia.org/wiki/Inter-Asterisk_eXchange) clients instead of SIP. iaxcomm (http://iaxclient.sourceforge.net/iaxcomm/) is a simple IAX2 client. On Ubuntu its current, but I haven't found any active RPMs. IAX routes quite nicely as compared to SIP. I'd be interested in seeing a sugarized iaxcomm on the XO. Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor of Information Systems San Francisco State University San Francisco CA 94132 USA http://verma.sfsu.edu/ http://opensource.sfsu.edu/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Reschedule XS meeting for Friday Aug 15 - or 10 PM Aug 14 EST ---- was (Re: not up for Friday meeting about the XS)
thanks Michael, After we get our top priorities working consistently I will definitely take a closer look at voip and try to look up the folks at fedora. On Sat, 2008-08-09 at 10:47 -0400, Michael Stone wrote: On Sat, Aug 09, 2008 at 12:11:56PM +0545, Bryan Berry wrote: VoIP would be more effective but would require much more effort. Fedora recently set up its own VOIP system, so there may be experts lurking nearby who could be tempted into assisting you. Michael -- Bryan W. Berry Systems Engineer OLE Nepal, http://www.olenepal.org ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
