On Mon, Jun 30, 2008 at 06:03:55PM -0700, [EMAIL PROTECTED] wrote:
On Mon, 30 Jun 2008, Erik Garrison wrote:
There is another primary value-add, which is a different operating
system or window manager. To enable this value-add we could be
distributing a minimal image for each of the popular
The current OLPC design is heavily weighted toward reliability and
maintainability. That's all. There's really nothing more to be said:
we all agree that a full-fledged package manager would give more
flexibility at the expense of less reliability. Therefore we are not
using one at this time.
On Mon, Jun 30, 2008 at 9:03 PM, [EMAIL PROTECTED] wrote:
what I would really like to see is for OLPC to not just release the
snapshots, but to have a way for developers to get the rest of the build
environment, complete with either the scripts, or command logs of what is
done to go from the
On Fri, Jun 27, 2008 at 01:24:36PM -0700, [EMAIL PROTECTED] wrote:
On Fri, 27 Jun 2008, Erik Garrison wrote:
What functionality do we certainly lose by using a package management
system as our default software distribution system?
it's not that we loose functionality by using a package-based
On Mon, 30 Jun 2008, Erik Garrison wrote:
On Fri, Jun 27, 2008 at 01:24:36PM -0700, [EMAIL PROTECTED] wrote:
On Fri, 27 Jun 2008, Erik Garrison wrote:
What functionality do we certainly lose by using a package management
system as our default software distribution system?
it's not that we
On Mon, Jun 30, 2008 at 6:50 PM, [EMAIL PROTECTED] wrote:
how many different deployment builds do you think are being supported at
this time? I think it's still in the single digits.
I expect this to change quite drastically soon.
...
customizers are able to take full advantage of the
On Mon, Jun 30, 2008 at 6:58 PM, Martin Langhoff
[EMAIL PROTECTED] wrote:
On Mon, Jun 30, 2008 at 6:50 PM, [EMAIL PROTECTED] wrote:
how many different deployment builds do you think are being supported at
this time? I think it's still in the single digits.
I expect this to change quite
On Mon, Jun 30, 2008 at 07:10:23PM -0400, C. Scott Ananian wrote:
On Mon, Jun 30, 2008 at 6:58 PM, Martin Langhoff
[EMAIL PROTECTED] wrote:
On Mon, Jun 30, 2008 at 6:50 PM, [EMAIL PROTECTED] wrote:
how many different deployment builds do you think are being supported at
this time? I think
On Mon, 30 Jun 2008, Erik Garrison wrote:
On Mon, Jun 30, 2008 at 07:10:23PM -0400, C. Scott Ananian wrote:
On Mon, Jun 30, 2008 at 6:58 PM, Martin Langhoff
[EMAIL PROTECTED] wrote:
On Mon, Jun 30, 2008 at 6:50 PM, [EMAIL PROTECTED] wrote:
how many different deployment builds do you think
On Mon, Jun 30, 2008 at 9:03 PM, [EMAIL PROTECTED] wrote:
what I would really like to see is for OLPC to not just release the
(note: I think what you are asking for is available)
...
I would then like to see someone maintain another base-level distro that
Guys, it'd be great to run all the
We separated out the activities so that we could push the testing and
localization of activities out to the country. How many activities can they
test? As many as they have people and time for.
It is in the deployment guide (and starting to get good discussion from
sales/deployment people) that
On Mon, 30 Jun 2008, Martin Langhoff wrote:
On Mon, Jun 30, 2008 at 9:03 PM, [EMAIL PROTECTED] wrote:
what I would really like to see is for OLPC to not just release the
(note: I think what you are asking for is available)
I thought that it might me.
...
I would then like to see someone
On Fri, Jun 27, 2008 at 8:47 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
Am 27.06.2008 um 20:50 schrieb Erik Garrison:
We already have yum installed on the XO.
Only in the devel builds. You might never have wondered what the
devel_ prefix means in
c. scott ananian wrote:
The current list of OLPC_DEVEL_PACKAGES at:
http://dev.laptop.org/git?p=users/cscott/pilgrim;a=blob;f=streams.d/olpc-develop
ment.stream;hb=joyride#l169
includes:
rpm
yum
yum-metadata-parser
openssh-server
wget
xterm
which
file
tree
On Sat, Jun 28, 2008 at 10:45 AM, [EMAIL PROTECTED] wrote:
which is redundant with type -a in the shell (or type -ap if you're
being picky).
But is 'which' large enough to merit the effort?
when/how would lrzsz be useful?
Many folks using Windows as their primary home OS find themselves
c. scott ananian wrote:
On Sat, Jun 28, 2008 at 10:45 AM, [EMAIL PROTECTED] wrote:
which is redundant with type -a in the shell (or type -ap if you're
being picky).
But is 'which' large enough to merit the effort?
probably not. i was mainly being pedantic. :-)
when/how
On Fri, Jun 27, 2008 at 5:21 PM, Michael Stone [EMAIL PROTECTED] wrote:
We chose a monolithic update solution because of several deficiencies,
*for our primary use case*, of all package-based upgrade solutions with
which we were familiar at the time. Package-based update solutions with
which
On Fri, Jun 27, 2008 at 5:46 PM, Erik Garrison [EMAIL PROTECTED] wrote:
Let's say we dist-upgrade our system. It's in an unbootable state.
In our current situation we attempt to avoid:
* can leave the system in an inconsistent or even unbootable
state on failure.
... by holding around
On Sat, Jun 28, 2008 at 11:26 AM, Martin Langhoff
[EMAIL PROTECTED] wrote:
On Fri, Jun 27, 2008 at 5:21 PM, Michael Stone [EMAIL PROTECTED] wrote:
We chose a monolithic update solution because of several deficiencies,
*for our primary use case*, of all package-based upgrade solutions with
On Sat, Jun 28, 2008 at 11:35 AM, Martin Langhoff
[EMAIL PROTECTED] wrote:
This is a deficiency of package managers which, if solved by us and
I don't think it's trivial to. We are already doing too much to
reinvent unix/linux and that takes from our effort to provide an
education platform.
On Sat, Jun 28, 2008 at 11:38 AM, C. Scott Ananian [EMAIL PROTECTED] wrote:
All reasonable, and the snapshot based approach has certain key
advantages for some uses. There is one thing that really bothers me,
however, and makes me suspect that we cannot actually use the snapshot
approach long
On Sat, Jun 28, 2008 at 11:59 AM, Martin Langhoff
[EMAIL PROTECTED] wrote:
On Sat, Jun 28, 2008 at 11:38 AM, C. Scott Ananian [EMAIL PROTECTED] wrote:
All reasonable, and the snapshot based approach has certain key
advantages for some uses. There is one thing that really bothers me,
however,
On Sat, Jun 28, 2008 at 01:09:58PM -0400, C. Scott Ananian wrote:
Yes, exactly: olpc-update has been designed so that the need for those
scripts is *zero*. You get a clean install every time, guaranteed.
Care to explain the existence and functioning of olpc-configure?
Michael
On Sat, Jun 28, 2008 at 1:29 PM, Michael Stone [EMAIL PROTECTED] wrote:
On Sat, Jun 28, 2008 at 01:09:58PM -0400, C. Scott Ananian wrote:
Yes, exactly: olpc-update has been designed so that the need for those
scripts is *zero*. You get a clean install every time, guaranteed.
Care to explain
On Sat, Jun 28, 2008 at 02:19:09PM -0400, C. Scott Ananian wrote:
On Sat, Jun 28, 2008 at 1:29 PM, Michael Stone [EMAIL PROTECTED] wrote:
Care to explain the existence and functioning of olpc-configure?
olpc-configure exists because /home/olpc is not managed by
olpc-update, and to do things
On Sat, Jun 28, 2008 at 2:34 PM, Michael Stone [EMAIL PROTECTED] wrote:
On Sat, Jun 28, 2008 at 02:19:09PM -0400, C. Scott Ananian wrote:
On Sat, Jun 28, 2008 at 1:29 PM, Michael Stone [EMAIL PROTECTED] wrote:
Care to explain the existence and functioning of olpc-configure?
olpc-configure
Am 27.06.2008 um 04:05 schrieb Stevens:
Hi Bert, all --
On Jun 25, 2008, at 11:37 PM, Bert Freudenberg wrote:
Sure. Do not use the Python script. You don't want to run a Python
activity but a native one - otherwise you get two windows, the
empty one opened by Python and the real one by
What's the logic for having updates erase all manually installed RPMs?
A couple of Support-Gangers and myself were talking about ways to remedy
this.
We came up with the following:
- alias rpm -i $FILE to rpm -i $FILE cp FILE $HOME/.rpms$/FILE with
a script on update that runs rpm -i
On Fri, 27 Jun 2008, Ian Daniher wrote:
What's the logic for having updates erase all manually installed RPMs?
the updates aren't package based, they are snapshot based.
as a result when you apply an update it alters everything outside of
/home.
when you have a very standardized system image
On Fri, Jun 27, 2008 at 01:23:46PM -0400, Ian Daniher wrote:
What's the logic for having updates erase all manually installed RPMs?
A couple of Support-Gangers and myself were talking about ways to remedy
this.
We came up with the following:
- alias rpm -i $FILE to rpm -i $FILE cp FILE
On Sat, Jun 28, 2008 at 12:20 AM, Erik Garrison [EMAIL PROTECTED] wrote:
On Fri, Jun 27, 2008 at 01:23:46PM -0400, Ian Daniher wrote:
What's the logic for having updates erase all manually installed RPMs?
A couple of Support-Gangers and myself were talking about ways to remedy
this.
We came
On Fri, 27 Jun 2008, Erik Garrison wrote:
We should move away from using olpc-update to upgrade systems. We
should not implement this or any hack to preserve manually installed
rpms through olpc-updates.
Existing package managers (e.g. apt, rpm) do exactly what we want and
more.
On Fri, Jun 27, 2008 at 12:17:57PM -0700, [EMAIL PROTECTED] wrote:
On Fri, 27 Jun 2008, Erik Garrison wrote:
We should move away from using olpc-update to upgrade systems. We
should not implement this or any hack to preserve manually installed
rpms through olpc-updates.
Existing package
On Fri, 27 Jun 2008, Erik Garrison wrote:
On Fri, Jun 27, 2008 at 12:17:57PM -0700, [EMAIL PROTECTED] wrote:
On Fri, 27 Jun 2008, Erik Garrison wrote:
We should move away from using olpc-update to upgrade systems. We
should not implement this or any hack to preserve manually installed
rpms
On Sat, Jun 28, 2008 at 12:30:14AM +0530, Sayamindu Dasgupta wrote:
On Sat, Jun 28, 2008 at 12:20 AM, Erik Garrison [EMAIL PROTECTED] wrote:
We already have yum installed on the XO. Why are we not using it to
implement software update procedures?
There are several reasons which occur to
On Fri, Jun 27, 2008 at 02:50:34PM -0400, Erik Garrison wrote:
Existing package managers (e.g. apt, rpm) do exactly what we want and
more. Furthermore they are extensively tested and well documented. Why
have we locally manufactured and promoted the square wheels of
olpc-update and
On Fri, 27 Jun 2008, Michael Stone wrote:
On Fri, Jun 27, 2008 at 02:50:34PM -0400, Erik Garrison wrote:
Existing package managers (e.g. apt, rpm) do exactly what we want and
more. Furthermore they are extensively tested and well documented. Why
have we locally manufactured and promoted the
On Fri, Jun 27, 2008 at 05:21:49PM -0400, Michael Stone wrote:
On Fri, Jun 27, 2008 at 02:50:34PM -0400, Erik Garrison wrote:
Existing package managers (e.g. apt, rpm) do exactly what we want and
more. Furthermore they are extensively tested and well documented. Why
have we locally
See also http://dev.laptop.org/ticket/6432, which actually has a
design with limitations which seemed to satisfy folks.
--scott
--
( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Am 27.06.2008 um 20:50 schrieb Erik Garrison:
We already have yum installed on the XO.
Only in the devel builds. You might never have wondered what the
devel_ prefix means in
http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build708/devel_jffs2/
but there was a time when there was a
Am 26.06.2008 um 00:49 schrieb Stevens:
Hi Bert, all,
I changed the script (OperaActivity.py) posted on the wiki
(http://wiki.laptop.org/go/Opera
).
This is the old script:
import logging
from sugar.activity import activity
import sys, os
import gtk
class
Am 26.06.2008 um 01:22 schrieb John Gilmore:
The activity start script should configure Opera to put its
configuration file in $SUGAR_ACTIVITY_ROOT/data instead of
$HOME/.opera. Also it should set umask to 0002 so the config file is
group-writable (otherwise the next activity instance cannot
On Thu, Jun 26, 2008 at 08:53:47AM +0200, Bert Freudenberg wrote:
Am 26.06.2008 um 01:22 schrieb John Gilmore:
The activity start script should configure Opera to put its
configuration file in $SUGAR_ACTIVITY_ROOT/data instead of
$HOME/.opera. Also it should set umask to 0002 so the
Hi Bert, all --
On Jun 25, 2008, at 11:37 PM, Bert Freudenberg wrote:
Sure. Do not use the Python script. You don't want to run a Python
activity but a native one - otherwise you get two windows, the
empty one opened by Python and the real one by Opera. Instead, you
only need a tiny
Hi All,
I run Opera on the XO, but if started as an activity it doesn't run
(it runs fine when started from terminal). There is a note on the
Opera install page that there is an incompatibility between Rainbow
and Opera:
Note: There is at present an incompatibility between the Opera
The activity start script should configure Opera to put its
configuration file in $SUGAR_ACTIVITY_ROOT/data instead of
$HOME/.opera. Also it should set umask to 0002 so the config file is
group-writable (otherwise the next activity instance cannot overwrite).
See
Hi All,
I run Opera on the XO, but if started as an activity it doesn't run
(it runs fine when started from terminal). There is a note on the
Opera install page that there is an incompatibility between Rainbow
and Opera:
Note: There is at present an incompatibility between the Opera
I run Opera on the XO, but if started as an activity it doesn't run
(it runs fine when started from terminal). There is a note on the
Opera install page that there is an incompatibility between Rainbow
and Opera:
Note: There is at present an incompatibility between the Opera
48 matches
Mail list logo
