Re: [OLPC Engineering] [Techteam] New F14-arm build os1 - Fedora mirror plus more!

[Paul Fox]

peter wrote:
 > On Sun, Aug 14, 2011 at 5:00 PM, Chris Ball  wrote:
 > > Hi Peter,
 > >
 > > On Sun, Aug 14 2011, Peter Robinson wrote:
 > >> The Peter's first release with Fedora Secondary Mirrors goodness plus
 > >> much more release!
 > >>
 > >> Download from:
 > >>
 > >>   http://build.laptop.org/~pbrobinson/f14-arm/os1/
 > >
 > > If I give you permissions on http://build.laptop.org/F14-arm/, maybe you
 > > could continue using Martin's numbering scheme?  It's better to minimize
 > > the number of places we're hosting builds, I think, and not to have
 > > shared build numbers in the same stream that point to different builds.
 > 
 > I only put it there as I didn't know where else to put it, as for
 > numbering schemes IMO it would be nice to pre able to use different
 > prefixes to make it a little easier to determine what they all are.

peter -- can you tell us how you'll decide when to do new builds? 

i think we could use one soon, if only because the kernel in os36
(which seems to be the same in your os1) is a week and a half old, and
as i recall it was even then missing some things that slipped through
the branch shuffles that were going on.  it would also be nice to
get the numbering and location thing behind us -- it's hard to ask
someone to install a '1' release when they're already running a '36'
release.

paul

 > 
 > Peter
 > ___
 > olpc mailing list
 > o...@lists.fedoraproject.org
 > https://admin.fedoraproject.org/mailman/listinfo/olpc

=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 59.2 degrees)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Prefix to OFW's chosen/bootpath

[James Cameron]

On Tue, Aug 16, 2011 at 09:13:31PM +0100, Daniel Drake wrote:
> On Mon, Aug 15, 2011 at 10:59 PM, James Cameron  wrote:
> > Address of SDIO controller in the SoC. ?See show-devs for others.
> > Plausible that a different model of SoC might eventually have a
> > different value, but I don't expect that soon.
> >
> > You might parse out and ignore the bit between @ and /.
> 
> One of the main reasons we parse bootpath is to figure out which SD
> bus we are booting from (i.e. internal/external SD card).

Yes.

> The address presumably changes for internal vs external, as it does on
> x86.

Not so.

XO-1.75

ok dev int
ok pwd
/sd@d428/disk@3
ok dev ext
ok pwd
/sd@d428/disk@1 <-- unchanged address
ok 

XO-1.5

ok dev int
ok pwd
/pci/sd@c/disk@3
ok dev ext
ok pwd
/pci/sd@c/disk@1<-- unchanged address
ok 

XO-1

ok dev int
ok pwd
/pci/nandflash@c
ok dev ext
ok pwd
/pci/sd@c,1/disk@1
ok 

> So it should be parsed and not ignored.

I don't think olpc-configure should rely on d428 being in the
string, but I don't expect it to change.  I think disk@3 and disk@1
should be checked for, ignoring the other text.

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sugar and GTK updates

[Mikus Grinbergs]

had nowhere near the configurability of G2


Whether you intended to or not, you've just joined forces with those
who criticise the fallback mode without actually saying whats wrong
with it. What functionality were you missing?


If you were someone working to improve the fallback mode, I would 
consider my time well spent to explain my comment.  But to inform those 
not directly involved, please read what I _DID_ already say regarding 
what I dislike: "had nowhere near the configurability of G2".


mikus



p.s.  For example, in the panels G2 gives me a LOT of function via LMB 
-- icon move and delete, panel resize and add, etc.  G3 fallback mode 
(out of the box) has taken all those configurability facilities away.


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

Re: License files - L10n

[Chris Leonard]

On Tue, Aug 16, 2011 at 7:08 PM, John Gilmore  wrote:
> The theory was to provide, in flash, the unofficial license
> translations in the languages primarily used in deployments,
> e.g. Spanish.  That way the kids can actually tell what rights they
> have without having to (1) learn English, or (2) access a perhaps
> nonexistent or very slow Internet connection.
>
> Providing the English language license is a requirement of the
> licenses themselves; if you ship the software, you must provide them.
> Providing the unofficial translations is not a requirement of the
> licenses.  But how can you teach kids the principles of free software
> without them ever being able to read how they can apply those principles
> in their own life with the software right in front of them?

To be clear, that theory is not described in ticket #8043 or on it's
predecessors #6928 and #4265 which clearly focus on the need for
compliance and not on the educational content opportunity.

As the person who proposed
http://lists.laptop.org/pipermail/devel/2011-June/032457.html

and followed through on
http://lists.laptop.org/pipermail/devel/2011-July/032539.html

bundling the UN's Universal Declaration of Human Rights in multiple
languages (~ 100 in the LatAmCarib bundle),  I can certainly
appreciate the pedagogic value of translations of a document
enshrining the freedoms expressed in the FSF licenses.  However, that
was in no way expressed as the purpose of this or previous tickets.

As I said on the ticket #8043 (in the case that it was desired to
provide translations):

"Please provide links to the English texts that you want posted in
Pootle if you still want to pursue this approach."

>>  I'm just hoping
>> to close a simple ticket here and this is the easiest and most correct
>> solution I could devise.
>
> Easiest, certainly.  Most correct, no.

Most correct in the compliance sense expressed in the tickets, perhaps
not in the educational sense of the revised theory you are now
propounding, for which I have some sympathy.

Please provide the necessary links to the license texts of interest on
the ticket and I will use the txt2po function of the Translate Toolkit
to convert them into PO files to be hosted on our Pootle instance,
which can be sent upstream upon completion for review to
.

Unfortunately, only the GFDLv1.3 is currently available in Spanish,
and the only language(s) of the GPLv3 relevant to a deployment that I
know of are Armenian (and perhaps French).  Perhaps with time we can
improve on that coverage the way we have tried to reach out to other
upstream and downstream efforts and providing Pootle hosting (AbiWord
/ Gnash / Waveplace) or links and tracking (Gnome / Fedora /
Translation Project).

I await inclusion of the relevant relevant links on the ticket and I
will process the texts for posting on Pootle.  What OLPC or Sugar Labs
 or gnu.org does with them then is a policy question for each to
determine for themselves and one that will remain a moot point until
relevant translations are performed.

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

Re: License files - L10n

[James Cameron]

(repost from trac)

-1, simple is the enemy of the good.

We must not replace the English version of the GPL and LGPL licenses,
since these are the forms in which the licenses are granted. We must
continue to display these.

We should provide translation of all user-displayed strings in what we
ship.

Since we can't not-ship the licenses, we have to consider them.

We should include translations of the interactive notices:

  Copyright (C)   
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.

We should include translations of the licenses. There are translations
available. Where a translation is not available, a new one should be
created. We should translate as much as we can, as best we can, and be
prepared to correct the translations. The translations we ship should
explicitly deny that they replace the English license.

Since there is already an upstream translation effort, it should be
engaged. It can surely help.

For presentation, I'd like to see:

* the English notice side by side with the translated notice, at Sugar startup, 
(find out from the Sugar Labs Design Team how they would like to do this),

* the English license side by side with the translated license, in the
* My Settings - About my Computer. 

Currently, we have a translated notice, and an untranslated license.
This is adequate, but not good.

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: License files - L10n

[John Gilmore]

The theory was to provide, in flash, the unofficial license
translations in the languages primarily used in deployments,
e.g. Spanish.  That way the kids can actually tell what rights they
have without having to (1) learn English, or (2) access a perhaps
nonexistent or very slow Internet connection.

Providing the English language license is a requirement of the
licenses themselves; if you ship the software, you must provide them.
Providing the unofficial translations is not a requirement of the
licenses.  But how can you teach kids the principles of free software
without them ever being able to read how they can apply those principles
in their own life with the software right in front of them?

(Indeed some of the deployments appear to have never read nor
understood the licenses -- or to just be corrupt -- since they violate
the TiVoization clause.  Having locally readable licenses may help fix
that, too.)

The license translations are tiny -- a couple of kbytes each -- so
flash space isn't a big issue.

>   I'm just hoping
> to close a simple ticket here and this is the easiest and most correct
> solution I could devise.

Easiest, certainly.  Most correct, no.

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

Re: Sugar and GTK updates

[Daniel Drake]

On Tue, Aug 16, 2011 at 11:28 PM, Mikus Grinbergs  wrote:
> Some comments (NOT based on the XO):
>
> Been running Fedora 15 on a desktop.  Was disappointed in G3 "fallback" --
> it looked like G2, but had nowhere near the configurability of G2.

Whether you intended to or not, you've just joined forces with those
who criticise the fallback mode without actually saying whats wrong
with it. What functionality were you missing?

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

Re: Sugar and GTK updates

[Chris Ball]

Hi,

On Tue, Aug 16 2011, Mikus Grinbergs wrote:
> It is likely that computer neophytes will find G3 (or "fallback")
> acceptable -- but G3 itself as originally packaged in Fedora 15 has
> raised such a firestorm among long-time Linux users to in my opinion
> warrant being omitted from mention as a future direction for the XO.

I agree with you about finding G3 annoying and unconfigurable, but
disagree that we should form a constraint linking what long-time Linux
users find uninteresting and what should be omitted from mention as a
future direction for the XO.  That's not what we're here for.

- Chris.
-- 
Chris Ball  
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sugar and GTK updates

[Gonzalo Odiard]

On Tue, Aug 16, 2011 at 7:28 PM, Mikus Grinbergs  wrote:

> At the moment, the fallback environment is working well on XO-1 in my
>>> testing. It's really not that different from before - nothing has
>>>
>> ...
>>
>>
>>  - keeping G3 "fallback" desktop, hmm, well tested, in current and
>> future Fedoras
>>
>
> Some comments (NOT based on the XO):
>
> Been running Fedora 15 on a desktop.  Was disappointed in G3 "fallback" --
> it looked like G2, but had nowhere near the configurability of G2.
>
> [I may be wrong, but I got the impression that G3 "fallback" was a
> temporary expedient (to be dropped in future Fedora releases).]
>
> It is likely that computer neophytes will find G3 (or "fallback")
> acceptable -- but G3 itself as originally packaged in Fedora 15 has raised
> such a firestorm among long-time Linux users to in my opinion warrant being
> omitted from mention as a future direction for the XO.
>


May be this is not a problem, we are doing computers to new users!

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

Re: Sugar and GTK updates

[Mikus Grinbergs]

At the moment, the fallback environment is working well on XO-1 in my
testing. It's really not that different from before - nothing has

...

 - keeping G3 "fallback" desktop, hmm, well tested, in current and
future Fedoras


Some comments (NOT based on the XO):

Been running Fedora 15 on a desktop.  Was disappointed in G3 "fallback" 
-- it looked like G2, but had nowhere near the configurability of G2.


[I may be wrong, but I got the impression that G3 "fallback" was a 
temporary expedient (to be dropped in future Fedora releases).]


It is likely that computer neophytes will find G3 (or "fallback") 
acceptable -- but G3 itself as originally packaged in Fedora 15 has 
raised such a firestorm among long-time Linux users to in my opinion 
warrant being omitted from mention as a future direction for the XO.


mikus

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

Re: Sugar and GTK updates

[Daniel Drake]

On Tue, Aug 16, 2011 at 9:35 PM, Kevin Gordon  wrote:
> While I understand that a move to GTK3 would eventually mean less bloat, i
> did not realize,  from what I now infer here,  that also keeping the GTK2
> functionality concurrent on the machine would still have savings. Again,
> good news.

You are right on that point - having concurrent GTK3 + GTK2 support in
Sugar will be an overhead, particularly while some running parts of
Sugar are GTK2 and others are GTK3. It will mean that both library
versions are installed and loaded into memory. But this will be
temporary, and is not a huge overhead.

Even so, there are 2 justifications for this temporary overhead:

1. It's the path to a smaller/faster/better system, so we should take
it (and work to keep the concurrency period short)

2. And more importantly... We don't have a choice! Sugar is already
significantly broken. If you go beyond F14 you have no Read and no
Browse. We have no upstream support for key parts of our underlying
system. This situation will get worse and worse, more and more things
will break, and the transition will become more and more painful the
longer we wait.

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

Re: Sugar and GTK updates

[Peter Robinson]

Thank you Daniel,

This is what I've been saying for some time!

On Tue, Aug 16, 2011 at 8:28 PM, Daniel Drake  wrote:
> On Tue, Aug 16, 2011 at 6:49 PM, Benjamin M. Schwartz
>  wrote:
>> 2.  The system requirements (especially disk space) are affected more by
>> changes in Fedora than changes in Sugar.  A large amount of disk space is
>> taken up by files whose presence is unnecessary.  Customizing the build to
>> exclude these files takes significant human effort to execute and test
>> (see http://dev.laptop.org/ticket/4281), especially if the tradeoff is
>> different for XO-1 vs. XO-1.5.
>
> And just to build on this point a bit more...
>
> The changes referred to in the mail that opened this thread - GTK3 and
> PyGI - are not expected to be items of bloat. Rather the opposite.
>
> Moving to PyGI is expected to reduce startup time and reduce memory
> usage. No need for me to repeat Tomeu's arguments;
> http://blog.tomeuvizoso.net/2009/05/reducing-sugars-memory-usage.html
>
> This move will also allow us to drop a load of bindings packages, as
> the way PyGI works is that it allows python to call into C libraries
> through only a small generic introspection layer, plus a few small
> introspection data files. That will save some disk space.
>
> Moving from GTK2 to GTK3 is not a significant change. The version
> number bump was mostly for some internal restructuring and
> backwards-incompatible API changes, the actual end result is not that
> different from GTK2. Some things are faster and smaller, and GTK3 .so
> size has dropped 0.2mb to 4.1mb size on my system. A few things might
> be slightly slower, but the benchmarks I saw indicating this largely
> blamed the GTK3 theme for the small performance losses (which Sugar
> won't be using), and you won't notice it.
>
> Right now we ship both Mozilla and webkit in our builds. Both steps
> combined will allow us to drop mozilla, saving 30-50mb of disk space.
> I'll let others jump in with the "and webkit is faster/better"
> arguments!
>
> Sugar is growing features, but nothing that I feel that challenges the
> XO-1 at this point. The XO-1 images are big, and Fedora creep from
> 9-11 and 11-14 has hurt us a little, but we expect XO-1 deployments to
> ship without GNOME (which several do, at least), so the issue isn't as
> big as it appears.

Part of the growth in F-14 was new features like webM and other things
that we so actually want and get benefit from. Some of the growth was
due to changes for gnome3 that didn't end up making it to Fedora 14
that will be reduced in upcoming releases as things are deprecated and
cleaned up post gnome3 (believe me, I've found out how much of a mess
this was from building the entire distro from scratch for ARM)!

I've been working on keeping Fedora's deps in check for quite some
time (from around Fedora 8 or 9 if my memory serves me correctly). Its
unfortunately one of those pretty thankless and never ending jobs.
There's always improvements that can be made and there's always things
that people miss. If people pick up on things where we can split
certain features out into sub-packages so we don't pull in big deps do
let me know, I will get the changes upstream, even if I do them
myself!

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

Re: Sugar and GTK updates

[Kevin Gordon]

Folks:

I did  not know some of this either, and I appreciate the detailed feedback
as to what is envisioned. I also agree it's all really good news.

I did not know that the XO-1 builds would be shipping without Gnome.  In our
own little deployments, that might be an issue, as many of the users like
that UI and now do a lot 'over there'; but, maybe that's not a global
concern. And there very well may be a better and less resource intensive
desktop that provides the same functionality

And yes, ML, I appreciate that $6 * 500K is a large number; but it's smaller
than $230 * 500K to replace a machine that is 5 years old in order to take
advantage of some really neat new features that could have widespread
benefi, but are otherwise not possible   If the goal is to enable some of
these without even a small hardware upgrade, even better:-)

While I understand that a move to GTK3 would eventually mean less bloat, i
did not realize,  from what I now infer here,  that also keeping the GTK2
functionality concurrent on the machine would still have savings. Again,
good news.

Unfortunately, or actually very fortunately for the talented development
community at large, I will not be hacking in the source.  I will continue to
test whatever you want me to though.

So, I hereby end my 'pointless rant'.  I was actually just asking what the
plans were and whether one needed to plan for a stopgap measure to ensure
XO-1 compatibility going forward, but mea culpa for not being aware of the
ramifications, or having missed some of the referenced material.

Cheers

KG




On Tue, Aug 16, 2011 at 4:11 PM, Alan Jhonn Aguiar Schwyn <
alan...@hotmail.com> wrote:

>
> Thank's for the information... I did not know...
>
> Alan
>
> > From: c...@laptop.org
> > To: alan...@hotmail.com
> > CC: devel@lists.laptop.org
> > Subject: Re: Sugar and GTK updates
> > Date: Tue, 16 Aug 2011 12:33:16 -0400
>
> >
> > Hi,
> >
> > On Tue, Aug 16 2011, Alan Jhonn Aguiar Schwyn wrote:
> > > I always wondered why not put an SD of 2 instead of 1, suppose that
> > > production costs differ in nothing (or very little)
> >
> > The XO-1 isn't manufactured anymore. When it was manufactured, it used
> > bare NAND rather than an SD card, and the cost of 2G of bare NAND was
> > significantly more expensive than 1G of bare NAND.
> >
> > - Chris.
> > --
> > Chris Ball  
> > One Laptop Per Child
>
> ___
> 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: Prefix to OFW's chosen/bootpath

[Daniel Drake]

On Mon, Aug 15, 2011 at 10:59 PM, James Cameron  wrote:
> Address of SDIO controller in the SoC.  See show-devs for others.
> Plausible that a different model of SoC might eventually have a
> different value, but I don't expect that soon.
>
> You might parse out and ignore the bit between @ and /.

One of the main reasons we parse bootpath is to figure out which SD
bus we are booting from (i.e. internal/external SD card). The address
presumably changes for internal vs external, as it does on x86. So it
should be parsed and not ignored.

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

RE: Sugar and GTK updates

[Alan Jhonn Aguiar Schwyn]

Thank's for the information... I did not know...
Alan

> From: c...@laptop.org
> To: alan...@hotmail.com
> CC: devel@lists.laptop.org
> Subject: Re: Sugar and GTK updates
> Date: Tue, 16 Aug 2011 12:33:16 -0400
> 
> Hi,
> 
> On Tue, Aug 16 2011, Alan Jhonn Aguiar Schwyn wrote:
> > I always wondered why not put an SD of 2 instead of 1, suppose that
> > production costs differ in nothing (or very little)
> 
> The XO-1 isn't manufactured anymore.  When it was manufactured, it used
> bare NAND rather than an SD card, and the cost of 2G of bare NAND was
> significantly more expensive than 1G of bare NAND.
> 
> - Chris.
> -- 
> Chris Ball  
> One Laptop Per Child
  ___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sugar and GTK updates

[Martin Langhoff]

On Tue, Aug 16, 2011 at 3:37 PM, Daniel Drake  wrote:
> At the moment, the fallback environment is working well on XO-1 in my
> testing. It's really not that different from before - nothing has

That's really good news! All the pointless ranting has given me the
impression that it was broken.

So folks who care about keeping XO-1 alive can help us...

 - tracking Fedora's base "growth"

 - keeping G3 "fallback" desktop, hmm, well tested, in current and
future Fedoras

 - helping us jettison Mozilla/gecko/xulrunner

 - hacking on PyGI and/or helping test the results

cheers,




m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - 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: Sugar and GTK updates

[Daniel Drake]

On Tue, Aug 16, 2011 at 8:04 PM, Martin Langhoff
 wrote:
> To turn this in a more productive direction: to keep XO-1 alive there
> are two paths
>
> 1 - Keep releasing on an F14 base. Stay on latest GNOME 2.x, perhaps
> backport Sugar 0.92~0.96 series pre-Gobject introspection.
>
> 2 - Attempt F16, with the "fallback" GNOME 3, or XFCE. Probably needs
> extensive testing of the fallback environment.

At the moment, the fallback environment is working well on XO-1 in my
testing. It's really not that different from before - nothing has
mysteriously disappeared like people seem to think. Actually, the
functionality has grown, because some new GNOME 3 work (e.g. control
center) is available on the "old" applications menu.

That's not to say that things won't get worse in future, or that wider
testing won't throw up some issues, but at this point, I doubt the
"two paths, what's our alternate desktop?" discussion would be
productive. There isn't a driving force for us to change direction
from the one we've been following for the last few years.

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

Re: Sugar and GTK updates

[Daniel Drake]

On Tue, Aug 16, 2011 at 6:49 PM, Benjamin M. Schwartz
 wrote:
> 2.  The system requirements (especially disk space) are affected more by
> changes in Fedora than changes in Sugar.  A large amount of disk space is
> taken up by files whose presence is unnecessary.  Customizing the build to
> exclude these files takes significant human effort to execute and test
> (see http://dev.laptop.org/ticket/4281), especially if the tradeoff is
> different for XO-1 vs. XO-1.5.

And just to build on this point a bit more...

The changes referred to in the mail that opened this thread - GTK3 and
PyGI - are not expected to be items of bloat. Rather the opposite.

Moving to PyGI is expected to reduce startup time and reduce memory
usage. No need for me to repeat Tomeu's arguments;
http://blog.tomeuvizoso.net/2009/05/reducing-sugars-memory-usage.html

This move will also allow us to drop a load of bindings packages, as
the way PyGI works is that it allows python to call into C libraries
through only a small generic introspection layer, plus a few small
introspection data files. That will save some disk space.

Moving from GTK2 to GTK3 is not a significant change. The version
number bump was mostly for some internal restructuring and
backwards-incompatible API changes, the actual end result is not that
different from GTK2. Some things are faster and smaller, and GTK3 .so
size has dropped 0.2mb to 4.1mb size on my system. A few things might
be slightly slower, but the benchmarks I saw indicating this largely
blamed the GTK3 theme for the small performance losses (which Sugar
won't be using), and you won't notice it.

Right now we ship both Mozilla and webkit in our builds. Both steps
combined will allow us to drop mozilla, saving 30-50mb of disk space.
I'll let others jump in with the "and webkit is faster/better"
arguments!

Sugar is growing features, but nothing that I feel that challenges the
XO-1 at this point. The XO-1 images are big, and Fedora creep from
9-11 and 11-14 has hurt us a little, but we expect XO-1 deployments to
ship without GNOME (which several do, at least), so the issue isn't as
big as it appears.

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

Re: Sugar and GTK updates

[Martin Langhoff]

On Tue, Aug 16, 2011 at 1:32 PM, Kevin Gordon  wrote:
> At around $6.75 per unit

Please remember to multiply times 500K -- that's roughly the sizes our
largest deployments deal with. Others clock in at ~60K. Unless you're
offering to fund the move, they might be unimpressed with your
proposal ;-)

To turn this in a more productive direction: to keep XO-1 alive there
are two paths

1 - Keep releasing on an F14 base. Stay on latest GNOME 2.x, perhaps
backport Sugar 0.92~0.96 series pre-Gobject introspection.

2 - Attempt F16, with the "fallback" GNOME 3, or XFCE. Probably needs
extensive testing of the fallback environment.

Either way, there are useful things people can do to improve the
viability of those options, like

 - Test the fallback GNOME3 mode, file bugs (and follow up on them!) upstream.

 - Work to make XFCE or an alternative desktop -viable- on the XO.
Avoid the temptation to bikeshed on your favourite desktop. Focus on
drafting and executing a plan to make it work really well on the XO.
Engage with upstream, hopefully they care. That's what matters.

 - Help us polish the current Sugar series on F14, learn enough to
help keep Sugar working on F14 even as we move forward...

just some thoughts :-)




m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - 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: Sugar and GTK updates

[Benjamin M. Schwartz]

On 08/16/2011 11:49 AM, Kevin Gordon wrote:
> My concern is that feature creep, and with concurrent support dependency
> increases, it could make the footprint and hardware requirements so large
> on an XO-1, that it becomes untenable.
> 
> Has there been discussion as to when the development cycle might stop for
> the older XO-1's, (perhaps strawmanning in as F14 with .94), so that this
> innovation and progress can continue on the more modern platforms?

This is a reasonable concern.  I am just watching from the sidelines, but
I can tell you:

1.  IMHO builds running on XO-1 already have the flavor of "backports",
with XO-1.5 being the primary development target.  I don't think anyone is
delaying Sugar development due to XO-1 constraints.

2.  The system requirements (especially disk space) are affected more by
changes in Fedora than changes in Sugar.  A large amount of disk space is
taken up by files whose presence is unnecessary.  Customizing the build to
exclude these files takes significant human effort to execute and test
(see http://dev.laptop.org/ticket/4281), especially if the tradeoff is
different for XO-1 vs. XO-1.5.

3.  XO-1 support is likely to be dropped when deployments indicate that
they have lost any interest in upgrading them.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sugar and GTK updates

[Kevin Gordon]

That actually wasnt what I was suggesting about future OS releases for
theXO-1.  I was suggesting that one might, for future releases that have a
larger footprint and more need to swap, that there would be a 'requirement'
for OS 12.x.x  to have the SD slot occupied with at least a 2Gb SD card,
that would be populated as the builders see fit.

At around $6.75 per unit, it could be replaced if it wore out.  If it was
dedicated to swap, links, and easily backed up data, its failure, even if in
a couple of years, would not be a prohibitive cost.

KG



On Tue, Aug 16, 2011 at 12:33 PM, Chris Ball  wrote:

> Hi,
>
> On Tue, Aug 16 2011, Alan Jhonn Aguiar Schwyn wrote:
> > I always wondered why not put an SD of 2 instead of 1, suppose that
> > production costs differ in nothing (or very little)
>
> The XO-1 isn't manufactured anymore.  When it was manufactured, it used
> bare NAND rather than an SD card, and the cost of 2G of bare NAND was
> significantly more expensive than 1G of bare NAND.
>
> - Chris.
> --
> Chris Ball  
> One Laptop Per Child
> ___
> 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: Sugar and GTK updates

[Martin Langhoff]

On Tue, Aug 16, 2011 at 12:37 PM, Ed McNierney  wrote:
> That is indeed correct, but it was also to reduce cost.

Exactly what Ed and cjb say.

- Early on, raw NAND was cheaper, and FTLs in SD/microSD were
unusable. This drove XO-1 decisions.

- SD/microSD prices dipped below raw NAND, and some passable FTLs
appeared in market (thanks to cameras, phones). This drove XO-1.5
decisions.

- microSD prices went up, quality and reliabiliy down -- eMMC offers
parts stability and is competitively priced, so that's what we do for
XO-1.75: eMMC.

A changing industry...



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - 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: Sugar and GTK updates

[Ed McNierney]

Peter -

That is indeed correct, but it was also to reduce cost.  The demand for NAND in 
microSD card format is driven by cameras and cell phones.  Since those volumes 
are very high compared to the sales volume of raw NAND chips, a microSD card of 
a desired capacity was actually cheaper than raw NAND chips.

- Ed

Ed McNierney
CTO
One Laptop per Child
e...@laptop.org
+1 (978) 761-0049

On Aug 16, 2011, at 12:33 PM, Peter Robinson wrote:

> On Tue, Aug 16, 2011 at 5:21 PM, Alan Jhonn Aguiar Schwyn
>  wrote:
>> 
>> I always wondered why not put an SD of 2 instead of 1, suppose that
>> production costs differ in nothing (or very little)
> 
> The XO-1 doesn't have an SD card, its a flash chip soldered to the
> motherboard. The 1.5 introduced the internal sd card to allow
> deployments to chose size and speed.
> 
> Peter
> ___
> 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: Sugar and GTK updates

[Chris Ball]

Hi,

On Tue, Aug 16 2011, Alan Jhonn Aguiar Schwyn wrote:
> I always wondered why not put an SD of 2 instead of 1, suppose that
> production costs differ in nothing (or very little)

The XO-1 isn't manufactured anymore.  When it was manufactured, it used
bare NAND rather than an SD card, and the cost of 2G of bare NAND was
significantly more expensive than 1G of bare NAND.

- Chris.
-- 
Chris Ball  
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sugar and GTK updates

[Peter Robinson]

On Tue, Aug 16, 2011 at 5:21 PM, Alan Jhonn Aguiar Schwyn
 wrote:
>
> I always wondered why not put an SD of 2 instead of 1, suppose that
> production costs differ in nothing (or very little)

The XO-1 doesn't have an SD card, its a flash chip soldered to the
motherboard. The 1.5 introduced the internal sd card to allow
deployments to chose size and speed.

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

RE: Sugar and GTK updates

[Alan Jhonn Aguiar Schwyn]

I always wondered why not put an SD of 2 instead of 1, suppose that production 
costs differ in nothing (or very little)

Date: Tue, 16 Aug 2011 11:49:53 -0400
Subject: Sugar and GTK updates
From: kgordon...@gmail.com
To: devel@lists.laptop.org

Folks:

I have been watching the flurry of emails and updates to the Sugar activities, 
the discussion surrounding including more rpm's in Sugar, and the desired OLPC 
upgrading of GTK discussions with interest.


My concern is that feature creep, and with concurrent support dependency 
increases, it could make the footprint and hardware requirements so large on an 
XO-1, that it becomes untenable.

Has there been discussion as to when the development cycle might stop for the 
older XO-1's, (perhaps strawmanning in as F14 with .94), so that this 
innovation and progress can continue on the more modern platforms?  Or, perhaps 
have OS builds for the newer releases for an XO-1 be tailored to (and insist 
on) a configuration woih an SD card of at least 2Gb, with 256Mb of swap, to be 
installed on an XO-1?  While this wouldn't address any issues wrt the small 
main memory, or video performance, it might alleviate some of the footprint 
size and swap thrashing concerns that might arise.  A 2Gb SD card is a pretty 
cheap h/w upgrade, imo.  Perhaps I've just missed the discussion and all this 
is already handled. Wouldn't be the first time :-)


Just curious.

Cheers

KG


___
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

License files - L10n

[Chris Leonard]

All,

I'm hoping to close a ticket in the OLPC Trac, and I wanted to float
my proposed solution past the group.

This ticket
http://dev.laptop.org/ticket/8043

Suggests providing translated versions of the licenses.

http://dev.laptop.org/ticket/8043#comment:4
http://dev.laptop.org/ticket/8043#comment:6

My answer is that we can't *replace* license files with translated
versions as only Englsih is "official" and we shouldn't add to
theworkload and confusion by adding "unofficial" versions anyway, but
we can point people to the home of "unofficial" translated versions on
an "official" site.

https://www.gnu.org/licenses/translations.html

Does that sound like a reasonable compromise under the circumstances?
I realize anything having to do with licenses is likely to promote a
firestorm, whcih is not my intent.  I also realize that any decision
on modifying license files needs to be taken by suitable
management-level people on behalf of their projects.  I'm just hoping
to close a simple ticket here and this is the easiest and most correct
solution I could devise.

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

Sugar and GTK updates

[Kevin Gordon]

Folks:

I have been watching the flurry of emails and updates to the Sugar
activities, the discussion surrounding including more rpm's in Sugar, and
the desired OLPC upgrading of GTK discussions with interest.

My concern is that feature creep, and with concurrent support dependency
increases, it could make the footprint and hardware requirements so large on
an XO-1, that it becomes untenable.

Has there been discussion as to when the development cycle might stop for
the older XO-1's, (perhaps strawmanning in as F14 with .94), so that this
innovation and progress can continue on the more modern platforms?  Or,
perhaps have OS builds for the newer releases for an XO-1 be tailored to
(and insist on) a configuration woih an SD card of at least 2Gb, with 256Mb
of swap, to be installed on an XO-1?  While this wouldn't address any issues
wrt the small main memory, or video performance, it might alleviate some of
the footprint size and swap thrashing concerns that might arise.  A 2Gb SD
card is a pretty cheap h/w upgrade, imo.  Perhaps I've just missed the
discussion and all this is already handled. Wouldn't be the first time :-)

Just curious.

Cheers

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

Re: Rought csound and csound-python rpms for f14 arm

[Gonzalo Odiard]

Hebemus tam tam in xo 1.75!
Need check if with the check I did, the binary continue working in XO 1, and
XO 1.75, but looks trivial

Gonzalo

On Tue, Aug 16, 2011 at 10:07 AM, Gonzalo Odiard  wrote:

> Ok, I will see if found any information bout this.
>
> Gonzalo
>
>
>
>> Sounds like there's x86 specific assembler in there somewhere, if
>> that's the case you'd need to migrate the code to generic C that's not
>> platform specific.
>>
>> Peter
>>
>>
>> > On Mon, Aug 15, 2011 at 7:19 PM, Martin Langhoff <
>> martin.langh...@gmail.com>
>> > wrote:
>> >>
>> >> Peter, Gonzalo,
>> >>
>> >> The koji buildfarm is busted. On one of my XOs I've built csound by
>> >> hand. It builds straight from the latest f14 spec, using `fedpkg
>> >> local`.
>> >>
>> >> RPMs here - http://dev.laptop.org/~martin/public_rpms/f14-arm/ so
>> >> hopefully they'll land in the next build...
>> >>
>> >>  - Peter, do tell me if/when I should remove rpms like these once we
>> >> have canonical ones from koji
>> >>
>> >>  - Gonzalo -- you can always grab the rpms directly ;-) -- I installed
>> >> them, but TamTam* still crashes on startup. But there's enough there
>> >> now to debug and/or rebuild any possible binaries I think ;-)
>> >>
>> >> cheers,
>> >>
>> >>
>> >> m
>> >> --
>> >>  martin.langh...@gmail.com
>> >>  mar...@laptop.org -- Software Architect - OLPC
>> >>  - ask interesting questions
>> >>  - don't get distracted with shiny stuff  - working code first
>> >>  - http://wiki.laptop.org/go/User:Martinlanghoff
>> >
>> >
>> >
>> > --
>> > Gonzalo Odiard
>> >
>> >
>> >
>>
>
>
>
> --
> Gonzalo Odiard
>
>
>


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

Re: Rought csound and csound-python rpms for f14 arm

[Gonzalo Odiard]

Ok, I will see if found any information bout this.

Gonzalo


> Sounds like there's x86 specific assembler in there somewhere, if
> that's the case you'd need to migrate the code to generic C that's not
> platform specific.
>
> Peter
>
>
> > On Mon, Aug 15, 2011 at 7:19 PM, Martin Langhoff <
> martin.langh...@gmail.com>
> > wrote:
> >>
> >> Peter, Gonzalo,
> >>
> >> The koji buildfarm is busted. On one of my XOs I've built csound by
> >> hand. It builds straight from the latest f14 spec, using `fedpkg
> >> local`.
> >>
> >> RPMs here - http://dev.laptop.org/~martin/public_rpms/f14-arm/ so
> >> hopefully they'll land in the next build...
> >>
> >>  - Peter, do tell me if/when I should remove rpms like these once we
> >> have canonical ones from koji
> >>
> >>  - Gonzalo -- you can always grab the rpms directly ;-) -- I installed
> >> them, but TamTam* still crashes on startup. But there's enough there
> >> now to debug and/or rebuild any possible binaries I think ;-)
> >>
> >> cheers,
> >>
> >>
> >> m
> >> --
> >>  martin.langh...@gmail.com
> >>  mar...@laptop.org -- Software Architect - OLPC
> >>  - ask interesting questions
> >>  - don't get distracted with shiny stuff  - working code first
> >>  - http://wiki.laptop.org/go/User:Martinlanghoff
> >
> >
> >
> > --
> > Gonzalo Odiard
> >
> >
> >
>



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

Re: Rought csound and csound-python rpms for f14 arm

[Peter Robinson]

On Tue, Aug 16, 2011 at 12:25 PM, Gonzalo Odiard  wrote:
> I have installed the packages csound, csound-devel and csound-python,
> and all the dependencies needed to compile the binaries in TamTam suite
> (alsa-lib-devel, gcc-c++, python-devel, make, gcc, pygtk-devel)
> but when compile I have the error:
>
> unknow register named 'st' in 'asm'
>
> pointing to the macro:
>
> #define FLOAT_TO_SHORT(in,out) __asm__ __volatile__ ("fistps %0" : "=m"
> (out) : "t" (in) : "st");
>
> Any idea?

Sounds like there's x86 specific assembler in there somewhere, if
that's the case you'd need to migrate the code to generic C that's not
platform specific.

Peter


> On Mon, Aug 15, 2011 at 7:19 PM, Martin Langhoff 
> wrote:
>>
>> Peter, Gonzalo,
>>
>> The koji buildfarm is busted. On one of my XOs I've built csound by
>> hand. It builds straight from the latest f14 spec, using `fedpkg
>> local`.
>>
>> RPMs here - http://dev.laptop.org/~martin/public_rpms/f14-arm/ so
>> hopefully they'll land in the next build...
>>
>>  - Peter, do tell me if/when I should remove rpms like these once we
>> have canonical ones from koji
>>
>>  - Gonzalo -- you can always grab the rpms directly ;-) -- I installed
>> them, but TamTam* still crashes on startup. But there's enough there
>> now to debug and/or rebuild any possible binaries I think ;-)
>>
>> cheers,
>>
>>
>> m
>> --
>>  martin.langh...@gmail.com
>>  mar...@laptop.org -- Software Architect - OLPC
>>  - ask interesting questions
>>  - don't get distracted with shiny stuff  - working code first
>>  - http://wiki.laptop.org/go/User:Martinlanghoff
>
>
>
> --
> Gonzalo Odiard
>
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Rought csound and csound-python rpms for f14 arm

[Gonzalo Odiard]

I have installed the packages csound, csound-devel and csound-python,
and all the dependencies needed to compile the binaries in TamTam suite
(alsa-lib-devel, gcc-c++, python-devel, make, gcc, pygtk-devel)
but when compile I have the error:

unknow register named 'st' in 'asm'

pointing to the macro:

#define FLOAT_TO_SHORT(in,out) __asm__ __volatile__ ("fistps %0" : "=m"
(out) : "t" (in) : "st");

Any idea?

Gonzalo


On Mon, Aug 15, 2011 at 7:19 PM, Martin Langhoff
wrote:

> Peter, Gonzalo,
>
> The koji buildfarm is busted. On one of my XOs I've built csound by
> hand. It builds straight from the latest f14 spec, using `fedpkg
> local`.
>
> RPMs here - http://dev.laptop.org/~martin/public_rpms/f14-arm/ so
> hopefully they'll land in the next build...
>
>  - Peter, do tell me if/when I should remove rpms like these once we
> have canonical ones from koji
>
>  - Gonzalo -- you can always grab the rpms directly ;-) -- I installed
> them, but TamTam* still crashes on startup. But there's enough there
> now to debug and/or rebuild any possible binaries I think ;-)
>
> cheers,
>
>
> m
> --
>  martin.langh...@gmail.com
>  mar...@laptop.org -- Software Architect - OLPC
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
>



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