I've set up an updatinator repository at
http://olpc.download.redhat.com/updatinator/ which contains all
devel_ext3 and devel_jffs2 from build 400 up to build 499. (The total
repository size for this is about 2 gig.) It also has binary diffs for
changed files between all consecutive releases,
On Wed, 2007-06-27 at 16:02 -0400, C. Scott Ananian wrote:
Anyway, here are some quick stats, for upgrades from build 464 to 465 to 466:
I've been doing some more work on updatinator. Now it stores the
release info as a simple key-value file that contains the manifest
sha1 value, and the actual
On Fri, 2007-06-29 at 08:22 -0400, Dan Williams wrote:
Two questions here:
1) what does the scheme do in the case where the file it's about to
replace on the local machine isn't the same as what the manifest on the
local machine says? ie, local changes have changed the sha1 hash of the
On Fri, 2007-06-29 at 10:21 -0400, Dan Williams wrote:
On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote:
The update daemon must provide a fair amount read-only status
information before and during the update process to allow the GUI bits
the flexibility to present that information
On Fri, 2007-06-29 at 15:49 +0200, Alexander Larsson wrote:
I've got the code mostly working now, and I managed to update a qemu
instance of build 406 to the devel build 406 using something like:
./updatinator.py -u http://10.x.y.z/updates --get-manifest olpc-ext3 406
./updatinator.py -u
On Wed, 2007-06-27 at 17:43 -0400, Polychronis Ypodimatopoulos wrote:
I wrote some code to deal with both problems, so that you have a
qualitative hop count (offering real numbers instead of just integers
for hop count) for all nodes in the mesh without
broadcasting/multicasting any frames.
On Tue, 2007-06-26 at 17:47 -0400, Mike C. Fletcher wrote:
I may be missing an operation or two in there, but I *think* that's the
intention. That is, there's an ultimate loading level that sits outside
the standard root to make it all work. That loading level could be in
the BIOS or on
On Tue, 2007-06-26 at 13:55 -0400, Ivan Krstić wrote:
Software updates on the One Laptop per Child's XO laptop
First some stray comments:
1.4. Design note: rsync scalability
---
rsync is a known CPU
On Tue, 2007-06-26 at 15:03 -0400, Mike C. Fletcher wrote:
My understanding here is that Alex's system is currently point-to-point,
but that we don't yet have any way to distribute it on the mesh? That
is, that we are looking at a research project to determine how to make
it work
On Sun, 2007-06-24 at 13:24 -0400, C. Scott Ananian wrote:
On 6/24/07, Ivan Krstić [EMAIL PROTECTED] wrote:
I should have a concrete spec ready for discussion later today.
I will wait with bated breath. =)
Some concrete concerns -- I've got some answers to these, but I'll try
to just
Hi,
My name is Alexander Larsson, and I just started working on the field
upgrade system of the olpc laptops. I have some ideas I'd like to
explain and get feedback on.
The olpc uses a full-image system, as opposed to the per-package
versioning scheme of deb or rpms. So, an upgrade consists
11 matches
Mail list logo
