[Announcement] - speech-dispatcher package now available

[Hemant Goyal]

Hi,

Fedora and OLPC developers can now download the speech-dispatcher RPM
packages for testing/development of speech enabled activities.

RPMs - OLPC Branch
speech-dispatcher-0.6.6-13.olpc2.i386.rpm -
http://koji.fedoraproject.org/packages/speech-dispatcher/0.6.6/13.olpc2/i386/speech-dispatcher-0.6.6-13.olpc2.i386.rpm
speech-dispatcher-0.6.6-13.olpc2.src.rpm-
http://koji.fedoraproject.org/packages/speech-dispatcher/0.6.6/13.olpc2/src/speech-dispatcher-0.6.6-13.olpc2.src.rpm
speech-dispatcher-debuginfo-0.6.6-13.olpc2.i386.rpm -
http://koji.fedoraproject.org/packages/speech-dispatcher/0.6.6/13.olpc2/i386/speech-dispatcher-debuginfo-0.6.6-13.olpc2.i386.rpm
speech-dispatcher-devel-0.6.6-13.olpc2.i386.rpm  -
http://koji.fedoraproject.org/packages/speech-dispatcher/0.6.6/13.olpc2/i386/speech-dispatcher-devel-0.6.6-13.olpc2.i386.rpm
speech-dispatcher-doc-0.6.6-13.olpc2.i386.rpm -
http://koji.fedoraproject.org/packages/speech-dispatcher/0.6.6/13.olpc2/i386/speech-dispatcher-doc-0.6.6-13.olpc2.i386.rpm
speech-dispatcher-python-0.6.6-13.olpc2.i386.rpm -
http://koji.fedoraproject.org/packages/speech-dispatcher/0.6.6/13.olpc2/i386/speech-dispatcher-python-0.6.6-13.olpc2.i386.rpm

Packages for the F-7, F-8 branch will be soon available too.

Best,
Hemant
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

[Announcement] - speech-dispatcher package now available

[Hemant Goyal]

*Sorry for the Repost - *slightly more formatted email**

Hi,

Fedora and OLPC developers can now download the speech-dispatcher RPM
packages for testing/development of speech enabled activities.

RPMs - OLPC Branch


   - speech-dispatcher-0.6.6-13.olpc2.i386.rpm -
   
http://koji.fedoraproject.org/packages/speech-dispatcher/0.6.6/13.olpc2/i386/speech-dispatcher-0.6.6-13.olpc2.i386.rpm
   - speech-dispatcher-0.6.6-13.olpc2.src.rpm-
   
http://koji.fedoraproject.org/packages/speech-dispatcher/0.6.6/13.olpc2/src/speech-dispatcher-0.6.6-13.olpc2.src.rpm
   - speech-dispatcher-debuginfo-0.6.6-13.olpc2.i386.rpm -
   
http://koji.fedoraproject.org/packages/speech-dispatcher/0.6.6/13.olpc2/i386/speech-dispatcher-debuginfo-0.6.6-13.olpc2.i386.rpm
   - speech-dispatcher-devel-0.6.6-13.olpc2.i386.rpm  -
   
http://koji.fedoraproject.org/packages/speech-dispatcher/0.6.6/13.olpc2/i386/speech-dispatcher-devel-0.6.6-13.olpc2.i386.rpm
   - speech-dispatcher-doc-0.6.6-13.olpc2.i386.rpm -
   
http://koji.fedoraproject.org/packages/speech-dispatcher/0.6.6/13.olpc2/i386/speech-dispatcher-doc-0.6.6-13.olpc2.i386.rpm
   - speech-dispatcher-python-0.6.6-13.olpc2.i386.rpm -
   
http://koji.fedoraproject.org/packages/speech-dispatcher/0.6.6/13.olpc2/i386/speech-dispatcher-python-0.6.6-13.olpc2.i386.rpm


Packages for the F-7, F-8 branch will be soon available too.

Best,
Hemant
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: olpc-dm ck-connector patch

[Marco Pesenti Gritti]

2008/6/24 Tomeu Vizoso [EMAIL PROTECTED]:
 On Tue, Jun 24, 2008 at 4:09 AM, Marco Pesenti Gritti
 [EMAIL PROTECTED] wrote:
 Ok, so I have a theory which I *hope* explains the whole thing.

 In Fedora 7 xinit had ConsoleKit support implemented as a patch:

 http://cvs.fedoraproject.org/viewcvs/rpms/xorg-x11-xinit/F-7/xinit-1.0.2-2-poke-ck.patch?rev=1.1view=log

 This worked fine for us.

 In Fedora 9, ConsoleKit support is implemented as a small executable
 run by xinitrc:

 http://cvs.fedoraproject.org/viewcvs/rpms/xorg-x11-xinit/F-9/ck-xinit-session.c?rev=1.1view=log
 http://cvs.fedoraproject.org/viewcvs/rpms/xorg-x11-xinit/F-9/xinitrc?rev=1.5view=markup

 Now, olpc-dm is calling startx like this:

 execl(/usr/bin/startx, startx, /usr/bin/olpc-session, --,
 -fp, built-ins, -wr, NULL);

 Which means that the default xinitrc is not executed and hence we
 never run ck-xinit-session.

 *If* my theory is correct (I can't verify it right now) then fixing
 this could be as easy as running ck-xinit-session from olpc-session.

 Hmm, who calls olpc-session? It doesn't appear in pstree.

 Modifying startx to call xinit inside ck-xinit-session didn't fixed
 these issues:

 ├─init─┬─agetty
 │  ├─login───bash
 │  ├─mingetty
 │  └─olpc-dm───startx───ck-xinit-sessio───xinit─┬─X
 │
 └─python───Journal\040e6d7e2

 Any other idea?

If you change olpc-session to run sugar as:

exec ck-xinit-session /usr/bin/sugar

The COOKIE is set but for some reason ck still doesn't give us permissions :(

Marco
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: olpc-dm ck-connector patch

[Marco Pesenti Gritti]

2008/6/24 Marco Pesenti Gritti [EMAIL PROTECTED]:
 If you change olpc-session to run sugar as:

 exec ck-xinit-session /usr/bin/sugar

 The COOKIE is set but for some reason ck still doesn't give us permissions :(

After further testing it seem to work fine. There are some caveats on
how the policies works...

I'll post a patch in a bit.

Marco
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: How USB's are enumerated on the XO

[shivaprasad javali]

The USB device that I am connecting is not a storage drive. so there is no
way I can copy a file containing a unique UUID on the device. I just need
one unique parameter for the device when it is connected to the system. On
the XO according to the /proc/bus/usb/devices file It is the port no. But If
have a normal fedora machine it is the bus no.

I just wanted to know If this is because of the way in which the USB
hardware is organised on the olpc/

On Tue, Jun 24, 2008 at 12:11 AM, Eben Eliason [EMAIL PROTECTED]
wrote:

 On Mon, Jun 23, 2008 at 2:36 PM, Carl-Daniel Hailfinger
 [EMAIL PROTECTED] wrote:
  On 23.06.2008 20:29, Jim Gettys wrote:
  While in theory, USB devices can/should send serial numbers, that part
  of the spec is honored mostly by it's absence (due to cost).
 
  As John said, unfortunately, with USB you have to go down to the device
  and see if they have something usable to distinguish devices.
 
 
  The easiest way to achieve this on USB flash disks is to store a file
  with a UUID on each disk upon first insertion.

 Note also that this suggestion is in alignment with an old idea to
 fingerprint drives with identity/colors, to make them function in the
 same identity system as laptops, activities, and objects.
 (http://dev.laptop.org/ticket/1848)

 - Eben
 ___
 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

SuperUser permission for the Driver??

[shivaprasad javali]

Hi,

  I have USB devices (not storage devices, just some usb devices), which
I can use along with my application on the olpc. The driver for these USB
devices are third paty drivers so I have to detach the kernel usb driver so
that I can use my own driver for that USB device. For this I need to have
super user privileges while running my application.

 I am new to programming on Linux. Could anybody point me as to how I
can give superuser privileges to my driver code.

Thanks
Shivaprasad
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

xo-get gives DBus No-reply for my .xo package

[shivaprasad javali]

Hi,

 I have created a .xo package for my application . When I try to install
it through the xo-get command I get a DBus No reply error message for my .xo
package. I also tried to install the activity through the Browser(By mailing
myself the xo) and the journal activity with the same result(It didnt give
me error message or anything simply didnt install). Can anybody please tell
me what the issue may be?

Thanks
Shivaprasad
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

reliably detecting if running on an XO

[Holger Levsen]

Hi,

can I reliably detect if my code is running on XO hardware?
Is checking if /sys/power/olpc-pm exists enough? Is there a better way?


regards,
Holger, currently offline and on battery, therefore not booting an XO 
kernel 
on my laptop :)


pgpqDv5jzUwGN.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [RFC] Unscheduled Software Release for SD Card Corruption

[Robert Myers]

Deepak,

 I've spent some time debugging trac #6532: SD corruption on 
 suspend resume and propose that we provide some sort of update
 with a proposed workaround as this is an issue that has been seen
 by multiple G1G1 users.  Doing a full USR may be overkill for this 
 issue as we may just be able to provide a new kernel and intird RPM, 
 but I'm not sure that we have an official way of providing individual
 package updates.
 
 Please see http://wiki.laptop.org/go/OLPC_SW_ECO_-_SD_CARD_CORRUPTION
 for the official proposal. 

As this involves a new kernel, does it make any sense to try to get 
other kernel related 'low-hanging fruit' into this?

Viz: #3050 'Please include drivers for the Keyspan USA-19HS'; which I'd 
guess is just a compile time switch.

Are any of the other fifty 8.1.1 and 8.2 kernel bugs potentially this 
simple to address?

Bob
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

New faster build 2069

[Build Announcer v2]

http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build2069

Changes in build 2069 from build: 2063

Size delta: 0.13M

-kernel 2.6.22-20080523.1.olpc.28f4cb6e780db07
+kernel 2.6.25-20080619.1.olpc.279b9db99a30fe6

--- Changes for kernel 2.6.25-20080619.1.olpc.279b9db99a30fe6 from 
2.6.22-20080523.1.olpc.28f4cb6e780db07 ---
  + pull from testing
  + Merge branch '2.6.25.y' into testing
  + md: fix use after free when removing rdev via sysfs
  + sparc: Fix mmap VA span checking.
  + sit: Add missing kfree_skb() on pskb_may_pull() failure.
  + POWERPC: mpc5200: Fix unterminated of_device_id table
  + Linux 2.6.25.3
  + CRYPTO: api: Fix scatterwalk_sg_chain
  + CRYPTO: eseqiv: Fix off-by-one encryption
  + reiserfs: Unpack tails on quota files
  + CRYPTO: cryptd: Correct kzalloc error test
  + mm: fix usemap initialization
  + kprobes/arm: fix decoding of arithmetic immediate instructions
  + b43: Fix dual-PHY devices
  + b43: Fix some TX/RX locking issues
  + vfs: fix permission checking in sys_utimensat
  + kprobes/arm: fix cache flush address for instruction stub
  + CRYPTO: authenc: Fix async crypto crash in crypto_authenc_genicv()
  + sched: fix hrtick_start_fair and CPU-Hotplug
  + 2.6.25 regression: powertop says 120K wakeups/sec
  + x86 PCI: call dmi_check_pciprobe()
  + Merge branch '2.6.25.y' into testing
  + md: fix use after free when removing rdev via sysfs
  + sparc: Fix mmap VA span checking.
  + sit: Add missing kfree_skb() on pskb_may_pull() failure.
  + POWERPC: mpc5200: Fix unterminated of_device_id table
  + Linux 2.6.25.3
  + CRYPTO: api: Fix scatterwalk_sg_chain
  + CRYPTO: eseqiv: Fix off-by-one encryption
  + reiserfs: Unpack tails on quota files
  + CRYPTO: cryptd: Correct kzalloc error test
  + mm: fix usemap initialization
  + kprobes/arm: fix decoding of arithmetic immediate instructions
  + b43: Fix dual-PHY devices
  + b43: Fix some TX/RX locking issues
  + vfs: fix permission checking in sys_utimensat
  + kprobes/arm: fix cache flush address for instruction stub
  + CRYPTO: authenc: Fix async crypto crash in crypto_authenc_genicv()
  + sched: fix hrtick_start_fair and CPU-Hotplug
  + 2.6.25 regression: powertop says 120K wakeups/sec
  + x86 PCI: call dmi_check_pciprobe()
  + Merge branch '2.6.25.y' into testing
  + md: fix use after free when removing rdev via sysfs
  + sparc: Fix mmap VA span checking.
  + sit: Add missing kfree_skb() on pskb_may_pull() failure.
  + POWERPC: mpc5200: Fix unterminated of_device_id table
  + Linux 2.6.25.3
  + CRYPTO: api: Fix scatterwalk_sg_chain
  + CRYPTO: eseqiv: Fix off-by-one encryption
  + reiserfs: Unpack tails on quota files
  + CRYPTO: cryptd: Correct kzalloc error test
  + mm: fix usemap initialization
  + kprobes/arm: fix decoding of arithmetic immediate instructions
  + b43: Fix dual-PHY devices
  + b43: Fix some TX/RX locking issues
  + vfs: fix permission checking in sys_utimensat
  + kprobes/arm: fix cache flush address for instruction stub
  + CRYPTO: authenc: Fix async crypto crash in crypto_authenc_genicv()
  + sched: fix hrtick_start_fair and CPU-Hotplug
  + 2.6.25 regression: powertop says 120K wakeups/sec
  + x86 PCI: call dmi_check_pciprobe()
  + OHCI: fix regression upon awakening from hibernation
  + V4L/DVB (7473): PATCH for various Dibcom based devices
  + Merge branch '2.6.25.y' into testing
  + {nfnetlink, ip, ip6}_queue: fix skb_over_panic when enlarging packets
  + dccp: return -EINVAL on invalid feature length
  + md: fix raid5 'repair' operations
  + sparc: Fix SA_ONSTACK signal handling.
  + sparc: Fix fork/clone/vfork system call restart.
  + sparc64: Stop creating dummy root PCI host controller devices.
  + sparc64: Fix wedged irq regression.
  + SPARC64: Fix args to 64-bit sys_semctl() via sys_ipc().
  + serial: Fix sparc driver name strings.
  + sparc: Fix ptrace() detach.
  + sparc: Fix mremap address range validation.
  + sparc: Fix debugger syscall restart interactions.
  + sparc32: Don't twiddle PT_DTRACE in exec.
  + Linux 2.6.25.4
  + r8169: fix oops in r8169_get_mac_version
  + SCSI: aha152x: Fix oops on module removal
  + SCSI: aha152x: fix init suspiciously returned 1, it should follow 0/-E 
convention
  + sch_htb: remove from event queue in htb_parent_to_leaf()
  + i2c-piix4: Blacklist two mainboards
  + SCSI: qla1280: Fix queue depth problem
  + ipvs: fix oops in backup for fwmark conn templates
  + USB: airprime: unlock mutex instead of trying to lock it again
  + rtc: rtc_time_to_tm: use unsigned arithmetic
  + SCSI: libiscsi regression in 2.6.25: fix nop timer handling
  + SCSI: libiscsi regression in 2.6.25: fix setting of recv timer
  + can: Fix can_send() handling on dev_queue_xmit() failures
  + macvlan: Fix memleak on device removal/crash on module removal
  + nf_conntrack: padding breaks conntrack hash on ARM
  + sparc: sunzilog uart order
  + r8169: fix past rtl_chip_info array size for unknown chipsets
  + x86: use defconfigs from x86/configs/*
  + vt: fix canonical input in UTF-8 

Re: SuperUser permission for the Driver??

[Deepak Saxena]

On Jun 24 2008, at 17:35, shivaprasad javali was caught saying:
 Hi,
 
   I have USB devices (not storage devices, just some usb devices), which
 I can use along with my application on the olpc. The driver for these USB
 devices are third paty drivers so I have to detach the kernel usb driver so
 that I can use my own driver for that USB device. For this I need to have
 super user privileges while running my application.
 
  I am new to programming on Linux. Could anybody point me as to how I
 can give superuser privileges to my driver code.

See http://wiki.laptop.org/go/Su

I am not completely sure I grok what you need. Are you trying to load
a driver via insmod or run some installer for the driver?  Note that 
until two days ago, the USB driver was built into to the kernel, so
you can't unload it. What specific device and driver is this?

~Deepak

-- 
Deepak Saxena [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [RFC] Unscheduled Software Release for SD Card Corruption

[Deepak Saxena]

On Jun 24 2008, at 10:23, Robert Myers was caught saying:
 Deepak,
 
  I've spent some time debugging trac #6532: SD corruption on 
  suspend resume and propose that we provide some sort of update
  with a proposed workaround as this is an issue that has been seen
  by multiple G1G1 users.  Doing a full USR may be overkill for this 
  issue as we may just be able to provide a new kernel and intird RPM, 
  but I'm not sure that we have an official way of providing individual
  package updates.
  
  Please see http://wiki.laptop.org/go/OLPC_SW_ECO_-_SD_CARD_CORRUPTION
  for the official proposal. 
 
 As this involves a new kernel, does it make any sense to try to get 
 other kernel related 'low-hanging fruit' into this?

Yes it does. I'll do a quick skim of trac and see if anything else
can be pulled in.

If we do an update, we may also want to consider non-kernel fixes that
we may want to pull in.

~Deepak

-- 
Deepak Saxena [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: How USB's are enumerated on the XO

[K. K. Subramaniam]

On Tuesday 24 Jun 2008 5:18:52 pm shivaprasad javali wrote:
 The USB device that I am connecting is not a storage drive. so there is no
 way I can copy a file containing a unique UUID on the device. I just need
 one unique parameter for the device when it is connected to the system.
Have you tried using /sys/bus/usb/devices/../dev? This gives the major/minor 
number of the attached device. The major number will be that of the usb 
driver, but the minor number will be unique.

HTH,
Subbu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: How USB's are enumerated on the XO

[david]

On Tue, 24 Jun 2008, K. K. Subramaniam wrote:

 On Tuesday 24 Jun 2008 5:18:52 pm shivaprasad javali wrote:
 The USB device that I am connecting is not a storage drive. so there is no
 way I can copy a file containing a unique UUID on the device. I just need
 one unique parameter for the device when it is connected to the system.
 Have you tried using /sys/bus/usb/devices/../dev? This gives the major/minor
 number of the attached device. The major number will be that of the usb
 driver, but the minor number will be unique.

unique, but not repeatable (reboot and plug the two devices in in the 
reverse order and the numbers will be swapped)

I think he's trying to find a way to identify which software device is 
which hardware device.

unfortunantly with USB this is a hard thing to do. udev does lots of 
tricks to try and do this job, but with some devices it's just not 
possible.

I've been watching this conversation, and I don't think that there's any 
way to look at the software device and say 'this is the one plugged into 
the USB slot on the left side' or 'this is the one plugged into the top 
USB slot on the right side', which it sounds like is what the OP is trying 
to do.

if the USB device doesn't provide any unique info to the system all you 
can do is say 'this is the first one that was plugged in'

on some desktop systems you have multiple USB busses, so you can say 'this 
device was plugged into one of the USB slots for bus#1' but the XO laptops 
only have one USB bus.

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Is my NAND dead?

[Richard A. Smith]

Dov Grobgeld wrote:
 Thanks. I did  a copy-nand and the system is up again, but it still 
 doesn't explain why the system wouldn't boot. Is there any way of 
 debugging that?

What build and what firmware are you running?  There are a few different 
bugs that can cause a boot failure.  Debugging it will probably require 
some Mitch Bradly time if not one of the known bugs.

 Should I open a trac issuse about the OpenFirmware pagefault?

Can you duplicate it?  If you can rerun the fixbbt and have it fail then 
I'm sure Mitch would like to fix it.

-- 
Richard Smith  [EMAIL PROTECTED]
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Updates This Week to the Sugar Almanac - Using the Datastore and More

[Faisal Anwar]

Hello All,

First off, thanks to everyone who has been contributing to the almanac (
http://wiki.laptop.org/go/Sugar-api-doc) directly or giving me feedback on
things that need to be added or improved for accuracy. Please keep the
feedback coming.

Among many other additions, the Sugar Almanac now has a section on using the
datastore. It includes a basic overview of the architecture as well as a
bunch of entries on how to do different useful tasks with the datastore:


   - 2 Datastore Helper
Functionshttp://wiki.laptop.org/go/Sugar.datastore.datastore#Datastore_Helper_Functions
  - 2.1 How do I create a new datastore
object?http://wiki.laptop.org/go/Sugar.datastore.datastore#How_do_I_create_a_new_datastore_object.3F
  - 2.2 How do I provide a query to the datastore.find() method so that
  I can find datastore objects with a particular
property?http://wiki.laptop.org/go/Sugar.datastore.datastore#How_do_I_provide_a_query_to_the_datastore.find.28.29_method_so_that_I_can_find_datastore_objects_with_a_particular_property.3F
  - 2.3 How do I delete datastore entries with a particular
property?http://wiki.laptop.org/go/Sugar.datastore.datastore#How_do_I_delete_datastore_entries_with_a_particular_property.3F
  - 2.4 How do I get all the unique values that are mapped to a
  particular key in the
datastore?http://wiki.laptop.org/go/Sugar.datastore.datastore#How_do_I_get_all_the_unique_values_that_are_mapped_to_a_particular_key_in_the_datastore.3F
  - 2.5 How do I get command line access to the files in my
DataStore?http://wiki.laptop.org/go/Sugar.datastore.datastore#How_do_I_get_command_line_access_to_the_files_in_my_DataStore.3F
  - 2.6 How do I identify the different mount points available through
  the datastore
api?http://wiki.laptop.org/go/Sugar.datastore.datastore#How_do_I_identify_the_different_mount_points_available_through_the_datastore_api.3F
   - 3 Class: 
DSObjecthttp://wiki.laptop.org/go/Sugar.datastore.datastore#Class:_DSObject
  - 3.1 How do I create new metadata entries or reassign metadata for a
  datastore object that has been
created?http://wiki.laptop.org/go/Sugar.datastore.datastore#How_do_I_create_new_metadata_entries_or_reassign_metadata_for_a_datastore_object_that_has_been_created.3F
  - 3.2 How do I save a simple text file to the
datastore?http://wiki.laptop.org/go/Sugar.datastore.datastore#How_do_I_save_a_simple_text_file_to_the_datastore.3F
  - 3.3 How do I resume an activity from the datastore
programmatically?http://wiki.laptop.org/go/Sugar.datastore.datastore#How_do_I_resume_an_activity_from_the_datastore_programmatically.3F


Also, for those who are experienced with writing the actual datastore code,
I had the following questions that came up while trying to understand how
this module works:

?? Is there a specific reason why there isn't a set() method in the
datastore.DSMetadata class? Shouldn't people be given standard accessors and
mutators to work with this code. This is especially confusing because it
seems there is presently a get() method, but the set() method does not
exist (so the abstraction is completely different based on whether you are
getting or setting data). d

?? Several things that are currently documented at
http://wiki.laptop.org/go/Low-level_Activity_API#Keeping_and_Resuming are
outdated. Specifically, it says datastore.create() returns the object_id.
That's wrong, it returns the actual DSObject. Furthermore, it says there are
methods called datastore.update and datastore.get_properties, but they don't
exists.

?? The deletion/destruction of datastore activities seems to be a little
confusing. In particular, there is a datastore.delete() method and there is
also a DSObject.destroy() method. Why doesn't datastore.delete() simply call
the destroy() method in its code so that any files associated with the
deleted datastore object are also removed. Given that a warning is thrown
telling the developer that an object is deleted without directly calling
DSObject.destroy() (it is called indirectly through the __del__ method, but
why not have things more explicit?), I'm not sure why this isn't just done
programmatically. Is there ever a reason why one woul perform a delete() on
an object without doing the functionality in DSObject.destroy() and are any
of these reasons compelling enough that we should keep the delete() and
destroy() methods as they are now?


Other questions may come up as people work more on this documentation. In
the meantime, I'd greatly appreciate any feedback on the existing work and
also any answers to the questions above.



Faisal
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Albert Cahalan]

I'm glad that Debian didn't break the rules for etoys.
You're claiming to be open source, yet you've LOST the
source code decades ago. Hacking up binary images is
shockingly horrible software non-engineering.

You've no justification for taking shots at gcc, which
is entirely capable of being bootstrapped from any other
C89 (ANSI C) compiler. BTW, Ken Thompson's hack is not
viable without perfect AI because source code gets modified.

GNU Smalltalk is built in a relatively normal way. OLPC could
ship that instead, assuming that Smalltalk is desirable.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

fixing etoys

[Albert Cahalan]

Here are some ideas that might help you fix some of the problems
with start-up performance, shut-down performance, open source,
and software engineering practices.

You're trying to do a persistant system image on an OS that wasn't
really designed for it. If you were on an exotic system with a
persistant image (like EROS, KeyKOS, or OS/400), you might be able
to cut the power at any time without losing more than a few seconds
of work. The key here is that the persistant system image OSes
continuously write out changes to disk. They do this atomicly,
and in small chunks, rather than overwriting everything at once in
a dangerous non-atomic operation.

You're trying to do a persistant system image on an OS that wasn't
really designed for it. If you were on an exotic system with a
persistant image (like EROS or OS/400), you'd be able to cut the
power at any time without losing more than a few seconds of work.
The key here is that the persistant system image OSes continuously
write out changes to disk. They do this atomicly, and in small
chunks, rather than overwriting everything at once in a dangerous
non-atomic operation.

Start with that. Break each object out into a separate file.
Your database becomes a directory rather than a big blob file.
When an in-memory object changes, you write a copy to a fresh
new file on disk. You keep the old on-disk copy around until
the new one has been synched. (fsync or sync probably, but be
very careful to avoid doing this more than once every few
seconds) You may need subdirectories for better performance;
it is very unwise to rely on Reiserfs-like performance when
having large directories.

On-demand loading is required for start-up performance.

Inheritance from a read-only image will cut per-instance disk size.
On a Debian system, install the read-only image under /usr/share
and the per-instance changes somewhere under $HOME. On the XO,
the read-only image stays in the activity and the per-instance
part goes into the journal. For older XO system software which
does not support grouping multiple files into single Journal entries,
you'll have to do it yourself with a standard archive format.
There are three to choose from: tar, cpio, pax.

To make things maintainable outside of the walled garden, store the
objects in text form. Make them be like nicely formatted source code.
Be permissive in parsing them, and try to preserve any comments that
might be added by users with regular text editors. Try to maximize
compatibility with GNU Smalltalk.

If you have bulk data that would not reasonably be editable with
a text editor, such as PNG images, then leave that part in binary.

To cut down on dirty anonymous pages in memory, and thus greatly
improve the situation on low-memory swapless systems like the XO,
you could do mmap(...,PROT_WRITE|PROT_READ,MAP_PRIVATE,...) on the
binary blobs at startup. This should just be things like PNG images.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Bert Freudenberg]

Am 24.06.2008 um 20:04 schrieb Albert Cahalan:

 I'm glad that Debian didn't break the rules for etoys.
 You're claiming to be open source, yet you've LOST the
 source code decades ago. Hacking up binary images is
 shockingly horrible software non-engineering.

Sorry Albert, this just shows your shocking ignorance.

*All the source code* for *every* piece of byte code in the image is  
available, and not only that, we even *ship* it (unlike all those GPL  
C binaries where you have to go out of your way to find the source,  
let alone being able to modify it). You can open a system browser  
right on the XO and inspect and modify every bit of the system.

Please take your propaganda elsewhere.

 GNU Smalltalk is built in a relatively normal way. OLPC could
 ship that instead, assuming that Smalltalk is desirable.


It is not Smalltalk that is desirable, but Etoys. I'd be very  
interested to hear of equivalent software packages.

- Bert -


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Albert Cahalan]

On Tue, Jun 24, 2008 at 2:18 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
 Am 24.06.2008 um 20:04 schrieb Albert Cahalan:

 I'm glad that Debian didn't break the rules for etoys.
 You're claiming to be open source, yet you've LOST the
 source code decades ago. Hacking up binary images is
 shockingly horrible software non-engineering.

 Sorry Albert, this just shows your shocking ignorance.

 *All the source code* for *every* piece of byte code in the
 image is available, and not only that, we even *ship* it

No. This is not true. You ship a binary blob. That doesn't
count, even if so-called source code is viewable from
within the blob.

It's not source code unless I can:

a. build a bit-for-bit identical image from it (aside from timestamps)
b. edit it with an editor of my choice
c. manage it with svn, git, or anything else
d. diff it with standard tools
e. patch it with standard tools

 GNU Smalltalk is built in a relatively normal way. OLPC could
 ship that instead, assuming that Smalltalk is desirable.

 It is not Smalltalk that is desirable, but Etoys. I'd be very interested to
 hear of equivalent software packages.

Unless you can separate Etoys from Smalltalk, you sure
do desire Smalltalk. If you had source code, you could just
use the GNU Smalltalk interpreter.

Fortunately, you do have the possibility of recreating your
long-lost source code. You can mostly regenerate it from
your binary blob, then rewrite the bits that didn't survive.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Setting up the mesh device

[Sjoerd Simons]

Hi,

 I'm currently working on adding support for the olpc mesh device to NM 0.7.
 From what i understand from David Woodhouse we should be able to really use
 it as two seperated devices these days (with the obvious constraint that it
 shares the radio ofcourse). Some testing shows that i can indeed use the mesh
 while the eth0 is completely unconfigured.

 Now when configuring the msh0 device NM 0.6 does the following:
   0. Set eth0 in ad-hoc mode
   1. Set eth0's essid to olpc-mesh
   2. Wait for an association event on eth0
   3. Continue with ip configuration.

 Which makes me wonder about the following things:
   * Why is the eth0 device set in ad-hoc mode?
   * In what way is the olpc-mesh essid special for eth0?
   * What's the actual meaning of the association event on eth0 for the msh0
 and why should we wait on it. And if it's important, why is this event on
 eth0 instead of msh0 ?

 TIA,
   Sjoerd
-- 
A transistor protected by a fast-acting fuse will protect the fuse by
blowing first.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: fixing etoys

[Yoshiki Ohshima]

At Tue, 24 Jun 2008 14:16:22 -0400,
Albert Cahalan wrote:
 
 Here are some ideas that might help you fix some of the problems
 with start-up performance, shut-down performance, open source,
 and software engineering practices.

  First, Etoys' start up time is very fast.  And shutdown/saving could
be very fast if we can save the whole image.  What is slow is scanning
relevant objects from the image upon saving, due to lack of modularity
in the image.

 You're trying to do a persistant system image on an OS that wasn't
 really designed for it. If you were on an exotic system with a
 persistant image (like EROS, KeyKOS, or OS/400), you might be able
 to cut the power at any time without losing more than a few seconds
 of work. The key here is that the persistant system image OSes
 continuously write out changes to disk. They do this atomicly,
 and in small chunks, rather than overwriting everything at once in
 a dangerous non-atomic operation.

 Start with that. Break each object out into a separate file.
 Your database becomes a directory rather than a big blob file.
 When an in-memory object changes, you write a copy to a fresh
 new file on disk. You keep the old on-disk copy around until
 the new one has been synched. (fsync or sync probably, but be
 very careful to avoid doing this more than once every few
 seconds) You may need subdirectories for better performance;
 it is very unwise to rely on Reiserfs-like performance when
 having large directories.

  Saving the Squeak image to disk is not slow.  (Back then, Ted
Kaehler had a memory system called OOZE for older Smalltalk that does
the checkpointing and constant object-grained swapping.  ALTO had a
memory problem that caused the system crashes once or twice a day
without any reasons.  OOZE kept people from losing their work except
last 30 seconds or so.)

 On-demand loading is required for start-up performance.

  Again, start up time is not a problem.  Etoys start up looks a bit
slow on XO, but that is because the DBus communication that has to be
done.  Otherwise, all it needs to do is reading a continuous 20MB file
into a continuous memory region and scanning the memory once.

 Inheritance from a read-only image will cut per-instance disk size.
 On a Debian system, install the read-only image under /usr/share
 and the per-instance changes somewhere under $HOME. On the XO,
 the read-only image stays in the activity and the per-instance
 part goes into the journal. For older XO system software which
 does not support grouping multiple files into single Journal entries,
 you'll have to do it yourself with a standard archive format.
 There are three to choose from: tar, cpio, pax.
 
 To make things maintainable outside of the walled garden, store the
 objects in text form. Make them be like nicely formatted source code.
 Be permissive in parsing them, and try to preserve any comments that
 might be added by users with regular text editors. Try to maximize
 compatibility with GNU Smalltalk.

  But code and objects are different.  Vast majority of incremental
changes including object creation and setting preferences are already
maintained outside of the walled garden.  The latest image is
(essentially) just a serial applications of updates available at:

http://tinlizzie.org/updates/etoys/updates/

from an early image.

 If you have bulk data that would not reasonably be editable with
 a text editor, such as PNG images, then leave that part in binary.
 
 To cut down on dirty anonymous pages in memory, and thus greatly
 improve the situation on low-memory swapless systems like the XO,
 you could do mmap(...,PROT_WRITE|PROT_READ,MAP_PRIVATE,...) on the
 binary blobs at startup. This should just be things like PNG images.

  I don't say there is a problem, such as the problem of modularity,
and suggestions similar to yours have been made before.  But it seems
that you really don't know how it works and what are the real
problems.

-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Setting up the mesh device

[Dan Williams]

On Tue, 2008-06-24 at 19:42 +0100, Sjoerd Simons wrote:
 Hi,
 
  I'm currently working on adding support for the olpc mesh device to NM 0.7.

I feel sorry for you :)  In some ways 0.7 has made it a lot better for
you (concurrent device support) and in other ways it's made it a bit
harder (more encapsulation of devices due to a well-thought-out object
model).

  From what i understand from David Woodhouse we should be able to really use
  it as two seperated devices these days (with the obvious constraint that it
  shares the radio ofcourse). Some testing shows that i can indeed use the mesh
  while the eth0 is completely unconfigured.
 
  Now when configuring the msh0 device NM 0.6 does the following:
0. Set eth0 in ad-hoc mode
1. Set eth0's essid to olpc-mesh
2. Wait for an association event on eth0
3. Continue with ip configuration.

It was done on eth0 because at the time it was implemented, common
attributes were defined to be set on ethX and were removed from mshX
entirely.  Due to discussions late last year, they got added back to the
mshX interfaces, but there was no functional break and thus no need to
update NM.

You can now set the parameters directly on the mshX device.

  Which makes me wonder about the following things:
* Why is the eth0 device set in ad-hoc mode?

See above.  Should need this any more, the mesh device should be set
adhoc now instead.

* In what way is the olpc-mesh essid special for eth0?

It's not, but setting an SSID is the way in WEXT that you say do this
all for me.  So the card will technically not be set up how you want it
until you set the SSID.  You can simply set the SSID on the mesh
interface now and not on the eth interface.

* What's the actual meaning of the association event on eth0 for the msh0
  and why should we wait on it. And if it's important, why is this event on
  eth0 instead of msh0 ?

You need to wait for the association event before going ahead with any
additional configuration, because that's the signal that the firmware
has joined the right IBSS and that it's set up to send and receive
traffic.  I don't know offhand if the firmware sends the association
event on the mesh interface these days; it used to, and it should, if
the SIOCSIWESSID command is done on the mesh interface.  If it doesn't
do this, then the driver should be changed to fix that and ensure that
commands sent to the mesh interface return events there and not on ethX.

Dan

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Bert Freudenberg]

Am 24.06.2008 um 20:38 schrieb Albert Cahalan:

 On Tue, Jun 24, 2008 at 2:18 PM, Bert Freudenberg [EMAIL PROTECTED] 
  wrote:
 Am 24.06.2008 um 20:04 schrieb Albert Cahalan:

 I'm glad that Debian didn't break the rules for etoys.
 You're claiming to be open source, yet you've LOST the
 source code decades ago. Hacking up binary images is
 shockingly horrible software non-engineering.

 Sorry Albert, this just shows your shocking ignorance.

 *All the source code* for *every* piece of byte code in the
 image is available, and not only that, we even *ship* it

 No. This is not true. You ship a binary blob. That doesn't
 count, even if so-called source code is viewable from
 within the blob.

 It's not source code unless I can:

 a. build a bit-for-bit identical image from it (aside from timestamps)
 b. edit it with an editor of my choice
 c. manage it with svn, git, or anything else
 d. diff it with standard tools
 e. patch it with standard tools

Well, your view then is way more narrow than even the Free Software  
Foundation's. Let me recall the four fundamental software freedoms for  
you:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and adapt it to your  
needs (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor  
(freedom 2).
• The freedom to improve the program, and release your improvements  
to the public, so that the whole community benefits (freedom 3).  
Access to the source code is a precondition for this.

All of these freedoms are satisfied with the way Etoys is developed.  
It might not fit your personal taste, but then, you are very welcome  
to rewrite it to suit your taste. Our time is better spent actually  
improving the software, not reassembling it for no good reason.

 GNU Smalltalk is built in a relatively normal way. OLPC could
 ship that instead, assuming that Smalltalk is desirable.

 It is not Smalltalk that is desirable, but Etoys. I'd be very  
 interested to
 hear of equivalent software packages.

 Unless you can separate Etoys from Smalltalk, you sure
 do desire Smalltalk.

To the kids it is of no real importance that Etoys is written on top  
of Smalltalk. It's just an implementation detail. But I'd still be  
interested in learning about alternatives.

- Bert -


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] etoys now available in Debian's non-free repository

[Robert Withrow]

John and others seem to be making the argument that unless something is 
technologically similar to GCC (in the way it is distributed, developed, 
and coded) it can't be --- picking a term --- open source.  For example, 
Albert says that code has to be manageable by traditional SCM tools, 
patch tools, diff tools, editing tools, etc to be called source code.  
Different tools need not apply.

It seems to me to be a little narrow to define software freedom in terms 
of specific (traditional) development tools; in the same way that it 
seems narrow to define a vehicle as something powered by an animal that 
eats oats.

Isn't it enough for free software to be software that is free (both as 
in beer and speech)?  Or does it also have to be editable by Emacs?

-- 
Robert Withrow, R.W. Withrow Associates, Swampscott, MA, USA
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Project: Departamentos is set up

[Henry Edward Hardy]

Fri, 23 May 2008 19:44:36 -0300, marcel r [EMAIL PROTECTED] wrote:

1. Project Name: Departamentos

Done. Your tree is here:
git+ssh://[EMAIL PROTECTED]/git/activities/departamentos

Please follow instructions here for importing your project:
http://wiki.laptop.org/go/Importing_your_project

Let us know if you have any problems with your tree. Happy hacking.

Cheers,

--
Henry Edward Hardy
[EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Project name : Typing Turtle Activity is set up

[Henry Edward Hardy]

Tue, 24 Jun 2008 11:51:57 -0700, Kate Scheppke [EMAIL PROTECTED]
wrote:

1. Project name : Typing Turtle Activity

Done. Your tree is here:
git+ssh://[EMAIL PROTECTED]/git/activities/typing-turtle

Please follow instructions here for importing your project:
http://wiki.laptop.org/go/Importing_your_project

Let us know if you have any problems with your tree. Happy hacking.

Cheers,

--
Henry Edward Hardy
[EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #7248 NORM 8.2.0 (: Speaker device has inconsistent behavior

[Eben Eliason]

  4. is basically WONTFIX (would you like to open another bug for this so we
  don't lose it but still can close this one in good time?)

When you've finished the rest, simply open a new ticket for (4), and
then reference that ticket number in the closing message.  Thanks!

- Eben
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] etoys now available in Debian's non-free repository

[Frank Ch. Eigler]

Robert Withrow [EMAIL PROTECTED] writes:

 John and others seem to be making the argument 

Only seem.

 that unless something is technologically similar to GCC (in the way
 it is distributed, developed, and coded) it can't be --- picking a
 term --- open source.  [...]

Not at all.

The gist of the argument is that one can't currently know what's
really inside an etoys image, except beyond what it itself tells us,
and cannot even be rebuilt from the sources it claims to contain.

Someone else threw out the Thompson compiler hack and GCC as if it
were an answer to this concern.  Instead, it turns out that GCC is on
the other (positive) extreme of bootstrappability.

- FChE
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] etoys now available in Debian's non-free repository

[Bert Freudenberg]

Am 24.06.2008 um 23:12 schrieb Frank Ch. Eigler:

 The gist of the argument is that one can't currently know what's
 really inside an etoys image, except beyond what it itself tells us,

This is indeed a valid concern. As I wrote before, an external tool  
could be written to examine what exactly is in the image.

 and cannot even be rebuilt from the sources it claims to contain.


even be rebuilt from the sources ... why would you want to do that?  
It could be done, as well as you could tear down the Empire State  
building and rebuild it from scratch, but why?

- Bert -


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Setting up the mesh device

[Polychronis Ypodimatopoulos]

Sjoerd Simons wrote:
 I'm setting the ESSID on the msh0 interface indeed. But i never get an
 association event on it.. While i even get an association event on eth0 when
 it's not up (but with msh0 being up obviously) :) Seems i've got some more 
 bugs
 to file
   

Why would you set an ESSID on the mshX interface in the first place? I 
understand that, from a solid layering perspective, you should be able 
to set essids on mshX since it's treated as a wireless interface, but it 
would logically separate network users. It's hard enough as it is to 
discover nodes in different channels (although different channels do 
have a radio scaling advantage).

p.




-- 
Polychronis Ypodimatopoulos
Graduate student
Viral Communications
MIT Media Lab
Tel: +1 (617) 459-6058
http://www.mit.edu/~ypod/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] etoys now available in Debian's non-free repository

[david]

On Wed, 25 Jun 2008, Bert Freudenberg wrote:

 Am 24.06.2008 um 23:12 schrieb Frank Ch. Eigler:

 The gist of the argument is that one can't currently know what's
 really inside an etoys image, except beyond what it itself tells us,

 This is indeed a valid concern. As I wrote before, an external tool
 could be written to examine what exactly is in the image.

 and cannot even be rebuilt from the sources it claims to contain.


 even be rebuilt from the sources ... why would you want to do that?
 It could be done, as well as you could tear down the Empire State
 building and rebuild it from scratch, but why?

leaving aside all the opensource arguments and just looking at it from a 
purely pragmatic point of view:

becouse paranoid people want to be able to verify that what's in the blob 
is really what it claims to be.

and we need to support these paranoid people becouse there are people who 
really are out to get us, and the small number of paranoid people protect 
us all.

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] etoys now available in Debian's non-free repository

[Bert Freudenberg]

Am 25.06.2008 um 00:12 schrieb [EMAIL PROTECTED]:

 On Wed, 25 Jun 2008, Bert Freudenberg wrote:

 Am 24.06.2008 um 23:12 schrieb Frank Ch. Eigler:

 The gist of the argument is that one can't currently know what's
 really inside an etoys image, except beyond what it itself tells us,

 This is indeed a valid concern. As I wrote before, an external tool
 could be written to examine what exactly is in the image.

 and cannot even be rebuilt from the sources it claims to contain.


 even be rebuilt from the sources ... why would you want to do that?
 It could be done, as well as you could tear down the Empire State
 building and rebuild it from scratch, but why?

 leaving aside all the opensource arguments and just looking at it  
 from a purely pragmatic point of view:

 becouse paranoid people want to be able to verify that what's in the  
 blob is really what it claims to be.

That would be accomplished by the tool I mentioned above.

 and we need to support these paranoid people becouse there are  
 people who really are out to get us, and the small number of  
 paranoid people protect us all.


I think you forgot a smiley to mark this as sarcasm.

- Bert -


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Yummy incron

[Martin Langhoff]

Looking for a (memory, cpu, power) efficient way to trigger
events/scripts on the XS, I came across incrond. It weights ~600KB
according to ps_mem.py, and it looks like the kind of tool we want to
be using. There are a few processes I have on the XS that signal
completion by touching a file in a tmpdir, so that a different process
(with different privileges) can perform other steps. Using incron
rather than poll frequently from an in-memory process or crond seems
much smarter.

rant
Yes, this a bit like DBus, but DBus was designed for a desktop with
Gobs Of Mighty RAM, and it requires that your process must be running
in memory, and that it'd be forking/threaded if you want to process
stuff in parallel. This means our (mostly python) processes are
sitting idly on memory we don't have the luxury to spare. And that
little or nothing happens in parallel.

(The above usage pattern of DBus is interesting in that it encourages
programmers of such services into building them even bigger, more
complex, and more powerful - as it's not feasible to have many small
processes that get spawned to do simple things well. Unless you build
your own incrond based on DBus I guess.)
/rant

I'll be playing with this more, but if it works roughly as the doco
promises, the XS is going to get a whole lot of incron love :-) so I
thought I'd mention it.

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

Re: [Server-devel] Yummy incron

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Langhoff wrote:
| Looking for a (memory, cpu, power) efficient way to trigger
| events/scripts on the XS, I came across incrond. It weights ~600KB
| according to ps_mem.py, and it looks like the kind of tool we want to
| be using. There are a few processes I have on the XS that signal
| completion by touching a file in a tmpdir, so that a different process
| (with different privileges) can perform other steps. Using incron
| rather than poll frequently from an in-memory process or crond seems
| much smarter.
|
| rant
| Yes, this a bit like DBus

What it sounds even more like, to me, is any modern init system.  For example:

Upstart (http://upstart.ubuntu.com/)
OpenRC (http://roy.marples.name/openrc)
InitNG (http://www.initng.org/)
etc.

This new generation of init are designed to provide proper inter-service
dependency management and post-startup event response.  It appears that
both Fedora and Ubuntu are using Upstart.

Given your opposition to DBUS in this context, you might enjoy

http://upstart.ubuntu.com/faq.html#replace-dbus

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhhnAQACgkQUJT6e6HFtqRJRgCfY/+oj/iKJ076oyeT41HlA9QE
NegAnjQqaHTYBHCSu4F5+nWJuG6ck2sv
=XMIJ
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Server-devel] Yummy incron

[Martin Langhoff]

On Tue, Jun 24, 2008 at 9:14 PM, Benjamin M. Schwartz
[EMAIL PROTECTED] wrote:
 What it sounds even more like, to me, is any modern init system.  For
 example:

I'm very keen on new init systems, but this is not one.

 Given your opposition to DBUS in this context, you might enjoy

:-) I'm not really opposed to DBus, but it encourages a model that
only makes sense for a subset of what we are doing. It's great to tell
the main Sugar shell something, as you surely expect it to be there,
up all the time. Other things, well, they have no business being in
memory -

 http://upstart.ubuntu.com/faq.html#replace-dbus

And that tells you exactly what I've been saying - DBus != Upstart,
and I'll add that both of those are != incrond.

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

Re: Setting up the mesh device

[Sjoerd Simons]

On Tue, Jun 24, 2008 at 06:09:58PM -0400, Polychronis Ypodimatopoulos wrote:
 Sjoerd Simons wrote:
 I'm setting the ESSID on the msh0 interface indeed. But i never get an
 association event on it.. While i even get an association event on eth0 when
 it's not up (but with msh0 being up obviously) :) Seems i've got some more
 bugs to file


 Why would you set an ESSID on the mshX interface in the first place? I
 understand that, from a solid layering perspective, you should be able
 to set essids on mshX since it's treated as a wireless interface, but it
 would logically separate network users. It's hard enough as it is to
 discover nodes in different channels (although different channels do
 have a radio scaling advantage).

Because we can? Seriously it's not for NetworkManager to decide this kind of
policy, some higher layer needs to tell it what to do. If that's the same essid
for all machine that's fine (most likely the update sugar NM bits will just
have one essid hardcoded). The current wireless firmware might not even
actually bother with checking essid's on traffic all.

The more important part, like Dan explained, is that this is the way
to tell wireless drivers in linux to go and configure what's needed and tell us
when they're ready for actual traffic (by means of an association event). So we
can start doing things like dhcp and/or autoip.

  Sjoerd
-- 
When you die, you lose a very important part of your life.
-- Brooke Shields
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Berkeley Logo interpreter for XO

[Brian Harvey]

Berkeley Logo is a GPLed interpreter for the Logo programming language
for kids.  It currently runs under Linux (and MacOS and Windows, but it's
Linux that's relevant) using an xterm window as the user interface, and a
separate X11 window for graphics.  It can run on the XO that way, but needs
to be Sugared to fit the UI specs.

The OLPC people say I should ask on this list for anyone interested in helping
with this project.  You can get the source code at
http://www.cs.berkeley.edu/~bh/logo.html

There's also an experimental version using wxWidgets in an attempt to provide
a uniform cross-platform UI.  It was 90% working a year ago, after a year of
effort, and now it's about 93% working.  ;-)  It may be relevant because that
version knows about creating and managing windows, including an interactive
text window, so it might be an easier starting point for a Sugar version.
You can find the current state of that project at
http://sourceforge.net/projects/ucblogo/

Please reply to me explicitly as well as to the list.  Thanks!
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] etoys now available in Debian's non-free repository

[Yoshiki Ohshima]

  After seeing that Jim Gettys and Alan Kay combined failed to
convince a guy on a software issue, it is uncertain that how much I
can add^^; But here goes:

At Wed, 25 Jun 2008 00:04:36 +0200,
Bert Freudenberg wrote:
 
 
 Am 24.06.2008 um 23:12 schrieb Frank Ch. Eigler:
 
  The gist of the argument is that one can't currently know what's
  really inside an etoys image, except beyond what it itself tells us,
 
 This is indeed a valid concern. As I wrote before, an external tool  
 could be written to examine what exactly is in the image.

  Yes, and the argument seems to be going as if having these tools
externally would make some difference.  However, I think that whether
it is inside or not doesn't make any real difference.

  Frank, *all* bits in the binary image file is well-understood.  In
fact, we can open the binary file from an externally running program
(called InterpreterSimulator written in Squeak) and examine every bits
in the file.

  All bytecodes in the image file can be decompiled to human readable
text files and that could also be done externally; not exactly that,
but I once wrote such a thing.  (It was modified InterpreterSimulator;
wo it happened to be written in Squeak^^;)

  You can also compile all code by calling something like:

  SystemNavigation current allBehaviorsDo: [:cls | cls compileAll].

to make sure that the compiled bytecode in the image reflect the
source code text (the code for the compiler included).

  For knowing what bytecodes do and how fast it runs, many people have
been looking at the generated C code and assembly code for the VM to
make sure that the VM does the right thing.  (I mean many people.)

  Of course, one cannot prove that something (bad) would ever never
happen with any piece of software; Squeak probably has some
vulnerability, but we are not talking about vulnerability, but
intentionally put malicious code, yes?  We can (almost) assure that
nobody has spotted any intentionally put malicious code in the image
file.  And subsequent incremental changes are either in the form of
text change set, or some content.  A sizable community will make sure
that malicious code won't get in.

  I don't think Squeak's vulnerability is not particularly higher than
other language interpreters (it would be somewhat lower than most of
other scripting languages, as Squeak has somrestrictions on what you
can do with external C libraries.)  I can imagine a random analog
would be a situation where an email client is compromized and executes
the binary in an email it receives.  But you wouldn't reject the
client because of the vulnerability; rather you would fix it and use
it as an example of strength of open-source development, right?

-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

custom kernel problem

[Scott Douglass]

Hi,

I built and installed a customized kernel RPM following these guides:

http://wiki.laptop.org/go/Rebuilding_OLPC_kernel

http://wiki.laptop.org/go/Kernel

Unfortunately, after I boot up the custom kernel, the X server fails to
start because /home is mounted read-only.

My work around is to login via a text virtual console, init S,
umount /home, and then init 5. This gives me a working /home directory
into which I've installed various activities. At this point everything
is working, including my USB serial port and my USB bluetooth radio.

Is there some reason why /home would be mounted read-only? Any pointers
as to this mysterious, to me, behavior of /home would be appreciated.
The mount command doesn't even show anything mounted on /home.

Mine is a G1G1 XO running build 703 (upgraded from build 656). The
kernel RPM I installed is version 2.6.26-20080622.1.olpc.0.

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: custom kernel problem

[Chris Ball]

Hi Scott,

Unfortunately, after I boot up the custom kernel, the X server
fails to start because /home is mounted read-only.

It's a bug in the master series kernel RPMs (or rather, in the initrd
that accompanies them).  It's being worked on.

Thanks,

- Chris.
-- 
Chris Ball   [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] fixing etoys

[Bernie Innocenti]

Yoshiki Ohshima wrote:
   Again, start up time is not a problem.  Etoys start up looks a bit
 slow on XO, but that is because the DBus communication that has to be
 done.

I frequently hear DBus being accused of latency.  As badly
implemented as it might be, I can't believe a daemon relaying
a bunch of bytes over a UNIX domain socket can introduce more
than 1ms of lag per message, even on a very slow processor.

Has anybody ever analyzed the actual DBus traffic?  With timings?
How many messages are we talking about?

It might very well be that the event loop on one of the endpoints
is misbehaving and not waking up the process immediately when
the socket has incoming data.  This is not at all unusual in
applications that mix GUI and networking, but I don't know the
specific interactions of gtk, dbus and the python bindings.

Also, I'd like to check if we could do anything to reduce our
dependence on DBus to provide basic desktop services for which
there are existing Freedesktop standards and long established
X conventions.

If we manage to make DBus entirely optional, the initial effort
of porting a Linux applications to Sugar would be greatly
simplified.

Yes, one could wrap the thing in libsugarize, but why resort to
a kludge when there are standards we could fall back to?

-- 
   \___/  Bernie Innocenti - http://www.codewiz.org/
  _| X |  Sugar Labs Team  - http://www.sugarlabs.org/
  \|_O_|  It's an education project, not a laptop project!
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] etoys now available in Debian's non-free repository

[Jim Gettys]

On Tue, 2008-06-24 at 11:41 -0700, John Gilmore wrote:
 Jim:
  My point is somewhat different: the only way out of the compilation
  trust trap is another compiler.  Unless someone has done this for gcc,
  it has the identical problem, and there are many possible upstream
  attacks.  I see no reason (probably less) to trust the chain of trust
  for gcc than I do Squeak, as the rewards of attacking gcc are so much
  higher.
 
 Alan:
  We are dealing with stories here, not with any kind of reality. 
 
 Here's a story for you.
 
 GCC is regularly compiled with non-GCC compilers.  It has been
 bootstrapped thousands of times, using dozens of different compilers
 (Sun's, Intel's, Apple's MPW, Green Hills, Code Warrior, MIPS's, ...).
 GCC includes lots of hacks and configuration code to allow it to build
 on other vendors' buggy or divergent compilers.  I've bootstrapped it
 myself hundreds of times, and Cygnus built the testing infrastructure
 to do it nightly on many architectures.  The makefiles are set up to
 do the classic 3-stage bootstrap:
 
   stage1 = binaries from GCC sources compiled with vendor compiler
   stage2 = binaries from GCC sources compiled with stage1 GCC
   stage3 = binaries from GCC sources compiled with stage2 GCC
 
 We then make sure that the stage2 and stage3 binaries are identical.
 (This check has caught hundreds of bugs in gcc, binutils, and in
 vendor compilers.)
 

Ah, yes, I remember this.  I've even struggled to do this once or twice,
but that was about 15 years ago...

 (The 3-stage bootstrap does not prevent or detect a Ken Thompson style
 all-binary attack -- but to succeed on a particular platform, you'd
 have to patch both the vendor compiler and GCC, and keep these patches
 in sync over time.  GCC also supports full blown cross-compilation (of
 itself and anything else), so a cross-bootstrap from any other host
 architecture would break the chain of an all-binary attack.  Debian's
 issue is not about resistance to Thompson attacks; this is just an aside.)
 
 It is trivial to build working binaries of GCC from a source tree, if you
 have a C compiler from any other source.  ./configure  make install.
 
 This is quite different from the eToys situation, in which there is a
 single binary implementation of the language; and the sources, where
 present, are all mixed into a binary blob that's only readable by the
 single implementation.  I have the same concerns that Debian does.  Is
 there even a tool internal to eToys that confirms that everything in a
 blob includes the matching source?  Let alone a tool that would
 extract that source and rebuild the blob from scratch, using a
 virgin binary environment.
 
 We could've bootstrapped GCC once, and limped along ever afterward
 with binaries built from that one original GCC binary.  (In a sense,
 the entire C compiler market has done this.  Bell Labs' original C
 compiler was bootstrapped from a BCPL compiler, and every other C
 compiler probably bootstrapped from Bell's C compilers.)  Instead, the
 GCC maintainers built lots of infrastructure to allow GCC to be
 bootstrapped anytime somebody wants to.  And to test it regularly.
 That's the part that eToys hasn't done.
 
 It turns out to be quite hard to reproduce a GCC release or Linux
 release, bit-for-bit identical, from its source tree.  If you haven't
 tested it, I'd pretty much guarantee that it isn't working.  It has
 subtle dependencies on its build environment, which predates the
 release.  GCC depends on the binutils, on libc, and on many external
 include files, for example.  Even unpacking a source release depends
 on tar and gzip or bzip2, each of which depends on the installed
 shared libc.  Cygnus was bit by such build-environment dependencies
 several times, when trying to produce patches against its old GCC
 binary releases.
 
 Are Fedora releases verified before release to build an identical
 binary CD/DVD image, starting from only a bare Fedora (release X)
 bootable binary CD/DVD, a freshly bought bare PC, and the pile of
 source code RPMs in the Fedora (release X) source CD/DVD?  (I think
 not -- I don't see source or binaries of pilgrim, which makes the
 bootable CD image.)
 
 Are Debian releases tested to reproduce themselves the same way?
 Perhaps eToys can get a reprieve until Debian confirms that it,
 itself, can do what it asks of eToys.
 
   John
 
 PS: Several distros don't make it easy to *find* source code releases.
 There's no obvious path on http://getfedora.com to get the definitive
 F9 source code release; you have to troll around in the mirrors
 looking for it.  OLPC will groan when it gets the first letter asking
 for the matching sources for its binary (flash) release.  It's only a
 few cranky geeks like me who insist on actually obtaining the sources
 for their free binary software.

I hope/believe Dennis has this cleaned up now  I'll check to make
sure.  Please pick on Fedora first, as they are upstream of us ;-).


Back to the 

New faster build 2071

[Build Announcer v2]

http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build2071

Changes in build 2071 from build: 2069

Size delta: 0.13M

-olpcrd 0.42-0
+olpcrd 0.43-0
-olpcupdate 2.7-0
+olpcupdate 2.8-0

--
This mail was automatically generated
See http://dev.laptop.org/~rwh/announcer/faster-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

OLPC Packaging Wishlist

[Michael Stone]

Dear OLPC  Fedora folk:

In response to conversation at Fudcon, I've thrown up OLPC's packaging
wishlist at

  https://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist

OLPC folks: please check to make sure that your work is listed. Also,
please assist Fedora volunteers in any way you can, for example, by
working with them to provide any missing information that is necessary
for packaging.

Fedora folks: please let us know where you need more information! Also,
don't be shy about joining #olpc-devel on irc.oftc.net and asking if it
looks like we're doing something dumb.

Michael
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [RFC] Unscheduled Software Release for SD Card Corruption Workaround

[Kim Quirk]

Thanks Deepak.
I'd love to see the SD card corruption fixed, but we are just about finished
with testing and are now in the release process for 8.1.1... so i recommend
that we schedule this fix for the 8.1.2 release (if we do this release) and
make sure it gets into 8.2.0, which might be the next release we get out the
door.

Other thoughts?

Kim

On Mon, Jun 23, 2008 at 7:13 PM, Deepak Saxena [EMAIL PROTECTED] wrote:

 [Resend to proper sw-eco address]

 Hi,

 I've spent some time debugging trac #6532: SD corruption on
 suspend resume and propose that we provide some sort of update
 with a proposed workaround as this is an issue that has been seen
 by multiple G1G1 users.  Doing a full USR may be overkill for this
 issue as we may just be able to provide a new kernel and intird RPM,
 but I'm not sure that we have an official way of providing individual
 package updates.

 Please see http://wiki.laptop.org/go/OLPC_SW_ECO_-_SD_CARD_CORRUPTION
 for the official proposal.

 Thanks,
 ~Deepak

 --
 Deepak Saxena [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: New joyride build 2072

[Michael Stone]

 -rainbow 0.7.13-1.olpc2
 +rainbow 0.7.5.11.20080104git6c25f7-1.olpc2

What's with the major rainbow regression?

Michael
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SuperUser permission for the Driver??

[shivaprasad javali]

The problem is that when I launch the application from the activity
taskbar(the activity icons at the bottom of the screen) It will run under
normal user privileges(right??). But for the application to work properly
the USB driver has to run under superuser privileges. So I have to figure
out how to do this while the application as a whole still has normal user
privileges. It all works properly if I go to the terminal su from there and
then launch the application from that terminal.

Thanks
Shivaprasad

On Wed, Jun 25, 2008 at 10:07 AM, shivaprasad javali [EMAIL PROTECTED]
wrote:

 The USB HID device which works along with my application needs a third
 party driver(libhid). So I have to detach the device from the kernel  before
 I starting using my own drivers. So I need superuser permission for that to
 detach the USB device from the kernel. I call hid_force_open() (this is a
 libhid() call which detaches the USB device from the kernel and then start
 using its own driver)

 Hope this makes it clear as to what I am trying to do. :)

 Thanks
 Shivaprasad


 On Tue, Jun 24, 2008 at 9:29 PM, Deepak Saxena [EMAIL PROTECTED] wrote:

 On Jun 24 2008, at 17:35, shivaprasad javali was caught saying:
  Hi,
 
I have USB devices (not storage devices, just some usb devices),
 which
  I can use along with my application on the olpc. The driver for these
 USB
  devices are third paty drivers so I have to detach the kernel usb driver
 so
  that I can use my own driver for that USB device. For this I need to
 have
  super user privileges while running my application.
 
   I am new to programming on Linux. Could anybody point me as to how
 I
  can give superuser privileges to my driver code.

 See http://wiki.laptop.org/go/Su

 I am not completely sure I grok what you need. Are you trying to load
 a driver via insmod or run some installer for the driver?  Note that
 until two days ago, the USB driver was built into to the kernel, so
 you can't unload it. What specific device and driver is this?

 ~Deepak

 --
 Deepak Saxena [EMAIL PROTECTED]



___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SuperUser permission for the Driver??

[James Cameron]

So it is root UID you need for a user-space program, not a kernel
driver, I see.  Have you considered setuid?

-- 
James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: New joyride build 2072

[Dennis Gilmore]

On Wednesday 25 June 2008, Michael Stone wrote:
  -rainbow 0.7.13-1.olpc2
  +rainbow 0.7.5.11.20080104git6c25f7-1.olpc2

 What's with the major rainbow regression?
You are probably lucky its even in the build.  my guess its in a joyride repo.  
and has not been built for OLPC-3.
-- 
Dennis Gilmore



signature.asc
Description: This is a digitally signed message part.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel