Re: [Sugar-devel] Install Firefox

[Peter Robinson]

On Fri, May 31, 2013 at 6:29 AM, Basanta Shrestha
 wrote:
> Adding fedora=fedora_update and rebuilding didn't work.

And Daniel suggested you didn't do that anyway, there's been a big
change delta since OLPC branched off the F17 release so without
testing I'm not particularly surprised.

> Jerry, As you suggested it installed all the required newer
> firefox,xulrunner and nss... packages but the resulting image couldn't boot
> the XO. Now I am going for your second suggestion. I have created a local
> repo for firefox, xulrunner and other dependencies( 9 altogether) . Could
> you please check if the entries are right?

Does it work if you just yum install them?

> /root/local/.repo
>
> --
> [local]
> name=firefox-xulrunner local
> baseurl=file:///root/local/
> gpgcheck=0
> enabled=1
> --
>
>  olpc-os-12.1.0-xo1.75.ini
>
> Right below [repos] section
>
> --
> [custom_repo]
> local=1,firefox,file:///root/local/
> --
>
>
>
>
>
> On Fri, May 31, 2013 at 1:37 AM, Jerry Vonau  wrote:
>>
>> On Thu, 2013-05-30 at 15:22 +0100, Peter Robinson wrote:
>> > On Thu, May 30, 2013 at 3:09 PM, Daniel Drake  wrote:
>> > > On Wed, May 29, 2013 at 11:50 PM, Peter Robinson
>> > >  wrote:
>> > >> Firefox and xulrunner 17 are the late known good (and matching)
>> > >> builds
>> > >> for Fedora 17, you need the major versions to be matching (so
>> > >> 12/13/17) but if you were pulling in all the latest stable updates
>> > >> into the build you would have matching ones AFAICT from koji so
>> > >> there's some other issue.
>> > >
>> > > Ah yes, you are right, the latest available versions on koji are
>> > > matching (v17) and built OK. I didn't spot them in the mass of failed
>> > > builds. So the Fedora situation is OK.
>> > >
>> > >> I'm not sure what the following lines translate to but you should
>> > >> never use the koji repositories as repos as they contain all sorts of
>> > >> randomly tagged bits that the release repos don't.
>> > >>
>> > >> olpc_frozen_1=0,koji.dist-f17-armv7hl
>> > >> olpc_frozen_2=0,koji.dist-f17-armv7hl-updates-12.1.0
>> > >
>> > > Don't worry, these are not the koji repos you are thinking of. They
>> > > are OLPC's frozen versions of fedora repos from the release's freeze
>> > > date and are not directly from koji - really we should change the
>> > > naming scheme.
>> > >
>> > > And this is the cause of the problem - upon release freeze date, the
>> > > firefox/xulrunner situation was in inconsistent state; this problem
>> > > has been frozen in our repos.
>> > >
>> > > Basanta, I would advise against adding the official fedora-updates
>> > > repo into your build as has been suggested in this thread - while this
>> > > will result in a well matched firefox/xulrunner combination, it will
>> > > bring in a lot of untested package updates that were not part of the
>> > > release and have probably not been tested on OLPC XO.
>> > >
>>
>> That is why later in the thread I suggested to download what yum
>> installed on the XO, then create and use a custom repo for OOB.
>>
>> > > Instead, create a local repo with these 2 packages and add it to your
>> > > build config:
>> > > http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=109570
>> > > http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=116355
>> >
>> > It will need newer nss*/nspr builds too.
>> >
>> > Peter
>>
>> Jerry
>>
>>
>>
>>
>>
>
>
>
> --
> Basanta Shrestha
> Network Engineer
> Open Learning Exchange (OLE) Nepal
> Tel: +977.1.551, 5520075 Ext. 303
> Cell: +977.9818 605110
> http://www.olenepal.org
>
> ___
> Devel mailing list
> de...@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Install Firefox

[Basanta Shrestha]

Adding fedora=fedora_update and rebuilding didn't work.

Jerry, As you suggested it installed all the required newer
firefox,xulrunner and nss... packages but the resulting image couldn't boot
the XO. Now I am going for your second suggestion. I have created a local
repo for firefox, xulrunner and other dependencies( 9 altogether) . Could
you please check if the entries are right?

/root/local/.repo

--
[local]
name=firefox-xulrunner local
baseurl=file:///root/local/
gpgcheck=0
enabled=1
--

 olpc-os-12.1.0-xo1.75.ini

Right below [repos] section

--
[custom_repo]
local=1,firefox,file:///root/local/
--





On Fri, May 31, 2013 at 1:37 AM, Jerry Vonau  wrote:

> On Thu, 2013-05-30 at 15:22 +0100, Peter Robinson wrote:
> > On Thu, May 30, 2013 at 3:09 PM, Daniel Drake  wrote:
> > > On Wed, May 29, 2013 at 11:50 PM, Peter Robinson 
> wrote:
> > >> Firefox and xulrunner 17 are the late known good (and matching) builds
> > >> for Fedora 17, you need the major versions to be matching (so
> > >> 12/13/17) but if you were pulling in all the latest stable updates
> > >> into the build you would have matching ones AFAICT from koji so
> > >> there's some other issue.
> > >
> > > Ah yes, you are right, the latest available versions on koji are
> > > matching (v17) and built OK. I didn't spot them in the mass of failed
> > > builds. So the Fedora situation is OK.
> > >
> > >> I'm not sure what the following lines translate to but you should
> > >> never use the koji repositories as repos as they contain all sorts of
> > >> randomly tagged bits that the release repos don't.
> > >>
> > >> olpc_frozen_1=0,koji.dist-f17-armv7hl
> > >> olpc_frozen_2=0,koji.dist-f17-armv7hl-updates-12.1.0
> > >
> > > Don't worry, these are not the koji repos you are thinking of. They
> > > are OLPC's frozen versions of fedora repos from the release's freeze
> > > date and are not directly from koji - really we should change the
> > > naming scheme.
> > >
> > > And this is the cause of the problem - upon release freeze date, the
> > > firefox/xulrunner situation was in inconsistent state; this problem
> > > has been frozen in our repos.
> > >
> > > Basanta, I would advise against adding the official fedora-updates
> > > repo into your build as has been suggested in this thread - while this
> > > will result in a well matched firefox/xulrunner combination, it will
> > > bring in a lot of untested package updates that were not part of the
> > > release and have probably not been tested on OLPC XO.
> > >
>
> That is why later in the thread I suggested to download what yum
> installed on the XO, then create and use a custom repo for OOB.
>
> > > Instead, create a local repo with these 2 packages and add it to your
> > > build config:
> > > http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=109570
> > > http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=116355
> >
> > It will need newer nss*/nspr builds too.
> >
> > Peter
>
> Jerry
>
>
>
>
>
>


-- 
Basanta Shrestha
Network Engineer
Open Learning Exchange (OLE) Nepal
Tel: +977.1.551, 5520075 Ext. 303
Cell: +977.9818 605110
http://www.olenepal.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [ASLO] Release Ruler-31

[Kalpa Welivitigoda]

On Fri, May 31, 2013 at 6:34 AM, Sugar Labs Activities <
activit...@sugarlabs.org> wrote:

> Activity Homepage:
> http://activities.sugarlabs.org/addon/4192
>
> Sugar Platform:
> 0.96 - 0.100
>
> Download Now:
> http://activities.sugarlabs.org/downloads/file/28638/ruler-31.xo


cat we have th tar ball please?


>
>
> Release notes:
> New translations
>
>
> Sugar Labs Activities
> http://activities.sugarlabs.org
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Best Regards,

Kalpa Welivitigoda
Junior Treasurer | Electrical Engineering Society
Undergraduate | Department of Electrical Engineering
University of Moratuwa
Sri Lanka
http://about.me/callkalpa
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ASLO] Release Ruler-31

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4192

Sugar Platform:
0.96 - 0.100

Download Now:
http://activities.sugarlabs.org/downloads/file/28638/ruler-31.xo

Release notes:
New translations


Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ASLO] Release Turtle Blocks-180

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4027

Sugar Platform:
0.82 - 0.100

Download Now:
http://activities.sugarlabs.org/downloads/file/28637/turtleblocks-180.xo

Release notes:
180

ENHANCEMENT:
* Faster launch time
* New translations

BUG FIXES:
* Catch exception raised when gconf is not available (prevented launch
  on some *old* systems, e.g., Peru 802)


Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ASLO] Release Yupana-15

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4533

Sugar Platform:
0.96 - 0.100

Download Now:
http://activities.sugarlabs.org/downloads/file/28636/yupana-15.xo

Release notes:
New translations


Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [Marketing] Sugar 0.100 or 1.0

[Ron Feigenblatt]

On 5/17/13, Daniel Narvaez  wrote:
> Hello,
> we need to decide if we want the next release to be 1.0 or 0.100.

One asks, what should one call the software to be released?

I will not bore people by repeating why I think "Sugar" is a bad name.
By now, its use is fait accompli. But I think one should still
mitigate what is perhaps its biggest drawback, the generic character.
This can be done by always qualifying the names of products, e.g. via
"Sugar by Sugar Labs", or "sugarlabs.org Sugar" or some other
convention, as long as the one chosen is NEVER changed again.

Now on to the specific question about the version number.

About 27 years ago, a credible person teaching the use of PC-based
"office suites" to the employees of what was then the world's biggest
computer firm told me an amusing story about software version numbers.
Today, I find this story is attested to by text on page 389 of
"Encyclopedia of Microcomputers", Volume 4 (CRC Press, 1989) online
at: books.google.com/books?id=2uy5NlyIzmkC&pg=PA389 , which says:

"dBASE is the most well-received database management software package
for popular types of microcomputers as well as one of the most popular
software programs for microcomputers to date... dBASE, then known as
Vulcan, was developed by Wayne Ratliff in 1980. Ratliff had created
Vulcan at NASA's Jet Propulsion Laboratory in Pasadena, California...
Almost immediately, a marketing decision was made to change Vulcan's
name to dBASE II. Using a lower case character in the name of a
microcomputer software package had never been done before... The 'II'
was added to imply an improved product, even though dBASE I never
existed."

With the subsequent rise of Microsoft in the 1990s, many people would
soon adopt the rule of thumb that one should never buy the first two
versions of any type of software from Microsoft.

And with the chronic online security issues which dominated the early
years of this century, popular wisdom became that all mass-market
software was "beta" (version 0.x) software, i.e. that all of it would
need much patching before it was finally abandoned as obsolete.

Today was are nonplussed by the frequent, irregular, Internet-mediated
notices to upgrade at no charge the version of Acrobat, Java or what
not one uses. Version numbers spin like the odometers of racing
automobiles. We just grin and bear it, and when practical, archive
backup images so that, even without the cooperation of our software
purveyors, we can always elect to rollback the "improvements" which
may break key stuff.

And you can go ask the Redmond people about their recent "new Coke"
experience with "version 8" of their flagship product. A new number
won't make a product succeed.

The bottom line is that by now, I think savvy people in
decision-making positions are pretty cynical about the guiding value
of version numbers per se. Instead, personally, I am disinclined to
update/upgrade any usable software, unless doing so is loudly
advocated by trusted, disinterested, third parties. Only then will I
look at the release note promises and inquire how fully third-party
opinion weighs in on its veracity. And even after that, I will still
pause to weigh the opportunity costs of any proposed change.

The only reason I will accept at once a recommended "free upgrade" for
adequately working software is if the machine in question is attached
to the Internet (not all are!), it also holds or handles sensitive
data, and the purveyor also screams "mea culpa" that the
security-issue boogeyman is hiding under my bed once again.

So, someone like me says software publishers can KEEP their "version"
numbers. Just give me the build date (so that I know if the same
version is running on different machines or not) and if they like, the
sequential integer build number (it is shorter, albeit less
informative). I never forgot the dBASE story from a quarter-century
ago! Maybe many others haven't, either.

At this point, the thing which will sell Sugar (or not) to savvy folks
is the experience of the national education systems which have adopted
it and keep using it.

- Ron
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Install Firefox

[Jerry Vonau]

On Thu, 2013-05-30 at 15:22 +0100, Peter Robinson wrote:
> On Thu, May 30, 2013 at 3:09 PM, Daniel Drake  wrote:
> > On Wed, May 29, 2013 at 11:50 PM, Peter Robinson  
> > wrote:
> >> Firefox and xulrunner 17 are the late known good (and matching) builds
> >> for Fedora 17, you need the major versions to be matching (so
> >> 12/13/17) but if you were pulling in all the latest stable updates
> >> into the build you would have matching ones AFAICT from koji so
> >> there's some other issue.
> >
> > Ah yes, you are right, the latest available versions on koji are
> > matching (v17) and built OK. I didn't spot them in the mass of failed
> > builds. So the Fedora situation is OK.
> >
> >> I'm not sure what the following lines translate to but you should
> >> never use the koji repositories as repos as they contain all sorts of
> >> randomly tagged bits that the release repos don't.
> >>
> >> olpc_frozen_1=0,koji.dist-f17-armv7hl
> >> olpc_frozen_2=0,koji.dist-f17-armv7hl-updates-12.1.0
> >
> > Don't worry, these are not the koji repos you are thinking of. They
> > are OLPC's frozen versions of fedora repos from the release's freeze
> > date and are not directly from koji - really we should change the
> > naming scheme.
> >
> > And this is the cause of the problem - upon release freeze date, the
> > firefox/xulrunner situation was in inconsistent state; this problem
> > has been frozen in our repos.
> >
> > Basanta, I would advise against adding the official fedora-updates
> > repo into your build as has been suggested in this thread - while this
> > will result in a well matched firefox/xulrunner combination, it will
> > bring in a lot of untested package updates that were not part of the
> > release and have probably not been tested on OLPC XO.
> >

That is why later in the thread I suggested to download what yum
installed on the XO, then create and use a custom repo for OOB.

> > Instead, create a local repo with these 2 packages and add it to your
> > build config:
> > http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=109570
> > http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=116355
> 
> It will need newer nss*/nspr builds too.
> 
> Peter

Jerry





___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ASLO] Release TurtleBots-20

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4434

Sugar Platform:
0.86 - 0.100

Download Now:
http://activities.sugarlabs.org/downloads/file/28634/turtlebots-20.xo

Release notes:
-based on TurtleBlocks v179
-butia: join usb4butia and pythonAPI
-butia: add power manager behavior
-butia: add getType motors behavior for refresh blocks
-butia: correct right left motors call
-butia: remove self.butia validation
-butia: remove duplicated reconnect
-butia: fix move_butia speed parameters
-pybot: uniformize functions call
-pybot: getVolt Butia returns the voltage
-pybot: add ax driver
-pybot: fix some drivers calls
-pybot: add sendPacket to ax driver
-pybot: improve debug function
-pybot: change drivers system
-pybot: add basic chotox functionally
-pybot: add basic describe
-pybot: improve refresh function
-pybot: validate open device
-pybot: correct lenght on device send
-pybot: add com_usb get_address function
-pybot: improve time of com_usb find function
-pybot: add openable if sucess open
-pybot: add open and close command
-pybot: remove unnecessary calls if handler is -1
-pybot: add getType to motors driver
-pybot: refresh devices when listing
-pybot: fix type of volt and res sensor
-pybot: battery returns a float again
-pybot: chotox in separate module
-pybot: more function in chotox mode
-pybot: add basic client when no telnet
-pybot: add testMotors function to motors driver
-pybot: validate type in _doCommand function
-pybot: possibility of no auto-connect the client
-pybot: works with device directly
-pybot: disable debug in com_usb
-pybot: update pybot button driver
-nxt: update nxt commit
-patterns: -remove unnnecessary libs in compile
-patterns: remove unnnecessary prints
-wedo: uses same pyusb than pybot
-new translations


Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Error handling in async js code

[Daniel Narvaez]

Hello,

in the async API we have written so far we have not been handling errors
very consistently. I think we should just adopt the nodejs convention. The
first parameter passed to all the async callbacks is an error or null if
the call succeeded.

-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Datastore API for html activities (Daniel Narvaez)

[Manuel Quiñones]

2013/5/30 Daniel Narvaez :
> Updated proposal based on the feedback, limiting myself to loading/saving
> objects for now
>
> * Low level
>
> datastore.getMetadata(objectId, onGotMetadata)
> datastore.setMetadata(objectId, onMetadataSet)
> datastore.loadData(objectId, onStream, onLoaded)
> datastore.create(metadata, onStream, onCreated)
> datastore.update(objectId, metadata, onStream, onUpdated)
>
> * High level
>
> datastoreObject = datastore.DatastoreObject(objectId)
>
> datastoreObject.updateMetadata(metadata, onMetadataUpdated)
> datastoreObject.setDataAsText(text, onDataSet)
> datastoreObject.save(onSaved)
>
> datastoreObject.getMetadata(onGotMetadata)
> datastoreObject.load(onLoaded[metadata, data])
>
> activity.getDatastoreObject()

Looks very good to me.

--
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Datastore API for html activities (Daniel Narvaez)

[Daniel Narvaez]

Updated proposal based on the feedback, limiting myself to loading/saving
objects for now

* Low level

datastore.getMetadata(objectId, onGotMetadata)
datastore.setMetadata(objectId, onMetadataSet)
datastore.loadData(objectId, onStream, onLoaded)
datastore.create(metadata, onStream, onCreated)
datastore.update(objectId, metadata, onStream, onUpdated)

* High level

datastoreObject = datastore.DatastoreObject(objectId)

datastoreObject.updateMetadata(metadata, onMetadataUpdated)
datastoreObject.setDataAsText(text, onDataSet)
datastoreObject.save(onSaved)

datastoreObject.getMetadata(onGotMetadata)
datastoreObject.load(onLoaded[metadata, data])

activity.getDatastoreObject()
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [ASLO] Release Terminal-42

[Gonzalo Odiard]

Of course :)



On Thu, May 30, 2013 at 11:50 AM, Peter Robinson wrote:

> Can I have a tar ball please :)
>
> P
>
> On Wed, May 29, 2013 at 1:47 PM, Sugar Labs Activities
>  wrote:
> > Activity Homepage:
> > http://activities.sugarlabs.org/addon/4043
> >
> > Sugar Platform:
> > 0.98 - 0.100
> >
> > Download Now:
> > http://activities.sugarlabs.org/downloads/file/28633/terminal-42.xo
> >
> > Release notes:
> > Do not try to set unsensitive non existing buttons
> > Get back a working activity history, SL #4131
> > Use sugar-artwork help icon SL#4110
> > Move the helpbutton before the fill separator
> >
> >
> >
> > Sugar Labs Activities
> > http://activities.sugarlabs.org
> >
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [ASLO] Release Terminal-42

[Peter Robinson]

Can I have a tar ball please :)

P

On Wed, May 29, 2013 at 1:47 PM, Sugar Labs Activities
 wrote:
> Activity Homepage:
> http://activities.sugarlabs.org/addon/4043
>
> Sugar Platform:
> 0.98 - 0.100
>
> Download Now:
> http://activities.sugarlabs.org/downloads/file/28633/terminal-42.xo
>
> Release notes:
> Do not try to set unsensitive non existing buttons
> Get back a working activity history, SL #4131
> Use sugar-artwork help icon SL#4110
> Move the helpbutton before the fill separator
>
>
>
> Sugar Labs Activities
> http://activities.sugarlabs.org
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Install Firefox

[Peter Robinson]

On Thu, May 30, 2013 at 3:09 PM, Daniel Drake  wrote:
> On Wed, May 29, 2013 at 11:50 PM, Peter Robinson  wrote:
>> Firefox and xulrunner 17 are the late known good (and matching) builds
>> for Fedora 17, you need the major versions to be matching (so
>> 12/13/17) but if you were pulling in all the latest stable updates
>> into the build you would have matching ones AFAICT from koji so
>> there's some other issue.
>
> Ah yes, you are right, the latest available versions on koji are
> matching (v17) and built OK. I didn't spot them in the mass of failed
> builds. So the Fedora situation is OK.
>
>> I'm not sure what the following lines translate to but you should
>> never use the koji repositories as repos as they contain all sorts of
>> randomly tagged bits that the release repos don't.
>>
>> olpc_frozen_1=0,koji.dist-f17-armv7hl
>> olpc_frozen_2=0,koji.dist-f17-armv7hl-updates-12.1.0
>
> Don't worry, these are not the koji repos you are thinking of. They
> are OLPC's frozen versions of fedora repos from the release's freeze
> date and are not directly from koji - really we should change the
> naming scheme.
>
> And this is the cause of the problem - upon release freeze date, the
> firefox/xulrunner situation was in inconsistent state; this problem
> has been frozen in our repos.
>
> Basanta, I would advise against adding the official fedora-updates
> repo into your build as has been suggested in this thread - while this
> will result in a well matched firefox/xulrunner combination, it will
> bring in a lot of untested package updates that were not part of the
> release and have probably not been tested on OLPC XO.
>
> Instead, create a local repo with these 2 packages and add it to your
> build config:
> http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=109570
> http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=116355

It will need newer nss*/nspr builds too.

Peter
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [NETWORK] Sugar Network 0.9 Beta release

[Aleksey Lim]

== General ==

This is another Beta cycle release of the Sugar Network.
It brings fixes for issues found during 0.8 testing.

The correspondig release of downstream deployment distribition
is Hexoquinasa BETA3, found more information on SL Peru wiki
http://pe.sugarlabs.org/go/Hexoquinasa/v1.0


== Sugar Network Node ==

* Remove timestamp duplicates in node statistics API call

  http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/API#Node_statistics

* Keep presolved dependency trees separately by system architecture

  to let packagekit-backend-presolve working not only on X86
  
http://wiki.sugarlabs.org/go/Platform_Team/packagekit-backend-presolve#Repositories

* Populate Sugar Network activity properties directly from .xo bundles.

  In previous version, strings like activity name, title, etc.
  were importing from the Activity Library, only few of them were
  properly localized. Right now, while importing activity updates from
  Activity Library, Sugar Network reads .xo files and reuse bundled
  localization for the following activity.info fields:

  - name
  - summary
  - description

* Fix indexing activity authors property while importing from
  the Activity Library.

  In previous versions, query API calls like

http://node.sugarlabs.org/context?query=author:Peter

  were returning empty results because Sugar Network content
  was not properly indexed by authors. Right now it should work
  as assumed.

* Index Activity Library content by authors nicknames.

  Since Sugar Network has only one user friendly identifier, User Name
  (to simplify usage workflow), Sugar Network was indexing Activity
  Library updates only by authors full name. For now, nicknames are
  also involved. So, queries like the following will work:

http://node.sugarlabs.org/context?query=author:mulawa


== Sugar Network cient ==

* While cloning activity implementations without dependencies,

  fetch original activity metadata from the server.
  http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/API#PUT_clone

* Add --accept-language client parameter to override system locale.

  sugar-network-client application while sending API calls
  was using only system locale to set HTT Accept-Language header.
  For now, it is also possible to specify particular languages.


== Sugar Shell plugin ==

* Install non Sugar Network based .xo only once.

  The previous code was installing Journal'ed .xo endlessly.


== Web UI ==

Bugfixes:

* Offline author shows name instead of guid
* Context browser returns correctly to last page
* Remove unimplemented followers, solutions, comments fields
* Fix layout in context resources view to avoid overflow
 
User Interface improvements:

* Object browsers switched to show 3 object per page
* Polish translations to make language simpler
* Redirect to newly created project on creation
* Delete artifacts


== Contributor Hub ==

* Make Fail reports visible for anonymous Web users.

  The original idea was not overcrowding top UI and "hide" 
  Fail reports link on Activity authors page. But since Web
  authentication is not yet implemented, this link was moved
  to the top Activity page like:

http://network.sugarlabs.org/hub/?activities&org.laptop.physics

* Set layers globally from settings.

  The idea of Sugar Network layers is about slicing content to make
  usage scenarios more flexible. For example, there is a layer named
  "pilot". It is being used to collect activities and activity versions
  passed QA procedures, i.e., ready to be used by people in the field.
  In new Contributor Hub version, it is possible to set currently
  visible layers from the setting dialog ("gear" button int the
  top-right corner):

http://network.sugarlabs.org/hub/?activities


== Try the release ==

Follow the "Try it" wiki page:

http://wiki.sugarlabs.org/go/Sugar_Network#Try_it

See Sugar Network usage tutorial created by Thomas C Gilliard:

http://wiki.sugarlabs.org/go/Sugar_Network/Tutorial


== Credits ==

* People in the field for exposing the need in such kind projects and
  interest in testing.

* World wide community members who donated funds to make full time
  working possible.

* People on wiki, mailing lists, and, IRC channels who are helping in
  development process.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Install Firefox

[Daniel Drake]

On Wed, May 29, 2013 at 11:50 PM, Peter Robinson  wrote:
> Firefox and xulrunner 17 are the late known good (and matching) builds
> for Fedora 17, you need the major versions to be matching (so
> 12/13/17) but if you were pulling in all the latest stable updates
> into the build you would have matching ones AFAICT from koji so
> there's some other issue.

Ah yes, you are right, the latest available versions on koji are
matching (v17) and built OK. I didn't spot them in the mass of failed
builds. So the Fedora situation is OK.

> I'm not sure what the following lines translate to but you should
> never use the koji repositories as repos as they contain all sorts of
> randomly tagged bits that the release repos don't.
>
> olpc_frozen_1=0,koji.dist-f17-armv7hl
> olpc_frozen_2=0,koji.dist-f17-armv7hl-updates-12.1.0

Don't worry, these are not the koji repos you are thinking of. They
are OLPC's frozen versions of fedora repos from the release's freeze
date and are not directly from koji - really we should change the
naming scheme.

And this is the cause of the problem - upon release freeze date, the
firefox/xulrunner situation was in inconsistent state; this problem
has been frozen in our repos.

Basanta, I would advise against adding the official fedora-updates
repo into your build as has been suggested in this thread - while this
will result in a well matched firefox/xulrunner combination, it will
bring in a lot of untested package updates that were not part of the
release and have probably not been tested on OLPC XO.

Instead, create a local repo with these 2 packages and add it to your
build config:
http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=109570
http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=116355

Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Broken build, terminal

[Gonzalo Odiard]

And that will not appear as a icon in the sugar frame?

I think now we should do the try catch,
until debian updates the libraries.

Gonzalo


On Thu, May 30, 2013 at 9:28 AM, Flavio Danesse  wrote:

> Not if I understand what you say, but from what I see, the error is in the
> "get_text" of Vte.Terminal.
> That function does not exist for that object.
>
> If this is the error to be corrected, you can get the text in the terminal
> using the clipboard as follows:
>
> terminal.select_all()
>
> terminal.copy_clipboard()
>
>
> To do the opposite:
>
> terminal.paste_clipboard()
>
>
>
>
> 2013/5/30 Gonzalo Odiard 
>
>> I have closed #690610, because my test case was wrong.
>>
>> The fix is in vte #676999 and pygobject #690041,
>> but also can needed other fixes in the management of GArray in pygobject.
>>
>> I don't know what is the state of these libraries on debian and ubuntu,
>> but can imagine the terminal maintainer will accept a patch to avoid
>> the error if the feature is not available.
>>
>> Probably safer do a try catch, because the method can be available,
>> but non working depending on the libraries state.
>>
>> Gonzalo
>>
>>
>> On Thu, May 30, 2013 at 7:25 AM, Simon Schampijer wrote:
>>
>>> On 05/30/2013 12:00 PM, Daniel Narvaez wrote:
>>>
 The upstream bug seems to have no activity?

 https://bugzilla.gnome.org/**show_bug.cgi?id=690610

>>>
>>> Right, that is why I have no clue what fix Gonzalo means. Anyhow, he
>>> will let us know.
>>>
>>> Simon
>>>
>>>
>>> __**_
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.**org 
>>> http://lists.sugarlabs.org/**listinfo/sugar-devel
>>>
>>
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Broken build, terminal

[Flavio Danesse]

Not if I understand what you say, but from what I see, the error is in the
"get_text" of Vte.Terminal.
That function does not exist for that object.

If this is the error to be corrected, you can get the text in the terminal
using the clipboard as follows:

terminal.select_all()

terminal.copy_clipboard()


To do the opposite:

terminal.paste_clipboard()




2013/5/30 Gonzalo Odiard 

> I have closed #690610, because my test case was wrong.
>
> The fix is in vte #676999 and pygobject #690041,
> but also can needed other fixes in the management of GArray in pygobject.
>
> I don't know what is the state of these libraries on debian and ubuntu,
> but can imagine the terminal maintainer will accept a patch to avoid
> the error if the feature is not available.
>
> Probably safer do a try catch, because the method can be available,
> but non working depending on the libraries state.
>
> Gonzalo
>
>
> On Thu, May 30, 2013 at 7:25 AM, Simon Schampijer wrote:
>
>> On 05/30/2013 12:00 PM, Daniel Narvaez wrote:
>>
>>> The upstream bug seems to have no activity?
>>>
>>> https://bugzilla.gnome.org/**show_bug.cgi?id=690610
>>>
>>
>> Right, that is why I have no clue what fix Gonzalo means. Anyhow, he will
>> let us know.
>>
>> Simon
>>
>>
>> __**_
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.**org 
>> http://lists.sugarlabs.org/**listinfo/sugar-devel
>>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Broken build, terminal

[Daniel Narvaez]

On 30 May 2013 14:11, Gonzalo Odiard  wrote:

> I have closed #690610, because my test case was wrong.
>
> The fix is in vte #676999 and pygobject #690041,
> but also can needed other fixes in the management of GArray in pygobject.
>
> I don't know what is the state of these libraries on debian and ubuntu,
> but can imagine the terminal maintainer will accept a patch to avoid
> the error if the feature is not available.
>
> Probably safer do a try catch, because the method can be available,
> but non working depending on the libraries state.
>

Yeah please add a try/catch or revert the patch until we have a fix that
doesn't break the build.

Thanks.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Broken build, terminal

[Gonzalo Odiard]

I have closed #690610, because my test case was wrong.

The fix is in vte #676999 and pygobject #690041,
but also can needed other fixes in the management of GArray in pygobject.

I don't know what is the state of these libraries on debian and ubuntu,
but can imagine the terminal maintainer will accept a patch to avoid
the error if the feature is not available.

Probably safer do a try catch, because the method can be available,
but non working depending on the libraries state.

Gonzalo


On Thu, May 30, 2013 at 7:25 AM, Simon Schampijer wrote:

> On 05/30/2013 12:00 PM, Daniel Narvaez wrote:
>
>> The upstream bug seems to have no activity?
>>
>> https://bugzilla.gnome.org/**show_bug.cgi?id=690610
>>
>
> Right, that is why I have no clue what fix Gonzalo means. Anyhow, he will
> let us know.
>
> Simon
>
>
> __**_
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.**org 
> http://lists.sugarlabs.org/**listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RELEASE] sugar-toolkit-gtk3-0.98.7

[Walter Bender]

thx

On Thu, May 30, 2013 at 6:24 AM, Simon Schampijer  wrote:
> == Source ==
>
> http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.98.7.tar.bz2
>
> == News ==
>
> * Release 0.98.7 (Simon Schampijer)
> * Add a binding for gconf_client_set_list (using strings) (Daniel Narvaez)
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Broken build, terminal

[Simon Schampijer]

On 05/30/2013 12:00 PM, Daniel Narvaez wrote:

The upstream bug seems to have no activity?

https://bugzilla.gnome.org/show_bug.cgi?id=690610


Right, that is why I have no clue what fix Gonzalo means. Anyhow, he 
will let us know.


Simon

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] sugar-toolkit-gtk3-0.98.7

[Simon Schampijer]

== Source ==

http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.98.7.tar.bz2

== News ==

* Release 0.98.7 (Simon Schampijer)
* Add a binding for gconf_client_set_list (using strings) (Daniel Narvaez)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Broken build, terminal

[Daniel Narvaez]

The upstream bug seems to have no activity?

https://bugzilla.gnome.org/show_bug.cgi?id=690610


On 30 May 2013 11:40, Simon Schampijer  wrote:

> On 05/30/2013 11:14 AM, Daniel Narvaez wrote:
>
>> Traceback (most recent call last):
>>File
>> "/home/buildbot/slave/raring-**amd64-quick/build/build/out/**
>> install/lib/python2.7/site-**packages/sugar3/activity/**activity.py",
>> line 906, in _prepare_close
>>  self.save()
>>File
>> "/home/buildbot/slave/raring-**amd64-quick/build/build/out/**
>> install/lib/python2.7/site-**packages/sugar3/activity/**activity.py",
>> line 740, in save
>>  self.write_file(file_path)
>>File
>> "/home/buildbot/slave/raring-**amd64-quick/build/build/out/**
>> install/share/sugar/**activities/Terminal.activity/**terminal.py",
>> line 424, in write_file
>>  text, attr = page.vt.get_text(is_selected, None)
>> AttributeError: 'Terminal' object has no attribute 'get_text'
>>
>> Caused by
>>
>> commit b90dac1ad2b8916b123e71b7384863**6f83fa9fe7
>> Author: Simon Schampijer 
>> Date:   Sat Nov 3 15:17:09 2012 +0100
>>
>>  Get back a working activity history, SL #4131
>>
>> It breaks on Debian and Ubuntu, it works on Fedora 18 and 19. I guess it's
>> either a Fedora patch or a more recent libvte required?
>>
>> I'd prefer to change the code to work also with old/unpatched libvte then
>> to add a new module to the build for Ubuntu and Debian.
>>
>
> http://bugs.sugarlabs.org/**ticket/4131should
>  point to the upstream fix. And state which upstream has the fix.
> Which version etc. Gonzalo, can you put some light on it. The upstream
> ticket was [1].
>
> Simon
>
> [1] 
> https://bugzilla.gnome.org/**show_bug.cgi?id=676999
> __**_
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.**org 
> http://lists.sugarlabs.org/**listinfo/sugar-devel
>



-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] How to deploy the webactivity libraries

[Daniel Narvaez]

On 30 May 2013 11:33, Simon Schampijer  wrote:

>
> So you mean for now, we should just add a copy of sugar-web library into
> each activity bundle. And then in the next step deal with the packaging of
> sugar-web as a dependency?
>
>
Yeah, though even for the next step I think we should reevaluate if system
dependencies are really what we want. We will be in a much better position
to decide anyway.


> On the packaging end this means that for the next release the packaging of
> the core will not change at all (sugar, sugar-toolkit-gtk3...). Only the
> webactivities need to be packaged and those contain sugar-web.
>

We will need the html bits (duh more renaming to web necessary) in sugar
and sugar-toolkit-gtk3 but no real packaging changes there.


> I think this would be a good compromise for now, given that things are in
> flux. And in the html+css+js world things seem to change fast, let's see
> which package management will survive the next months [1]. Maybe volo is
> gone by then.
>
> About activity development: we should shape the API while we develop
> activities. I am starting with that process now. The more people doing that
> the better, as now we can change API quickly. Of course for a developer
> this means a rather flux environment.
>

Totally agreed.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Broken build, terminal

[Simon Schampijer]

On 05/30/2013 11:14 AM, Daniel Narvaez wrote:

Traceback (most recent call last):
   File
"/home/buildbot/slave/raring-amd64-quick/build/build/out/install/lib/python2.7/site-packages/sugar3/activity/activity.py",
line 906, in _prepare_close
 self.save()
   File
"/home/buildbot/slave/raring-amd64-quick/build/build/out/install/lib/python2.7/site-packages/sugar3/activity/activity.py",
line 740, in save
 self.write_file(file_path)
   File
"/home/buildbot/slave/raring-amd64-quick/build/build/out/install/share/sugar/activities/Terminal.activity/terminal.py",
line 424, in write_file
 text, attr = page.vt.get_text(is_selected, None)
AttributeError: 'Terminal' object has no attribute 'get_text'

Caused by

commit b90dac1ad2b8916b123e71b73848636f83fa9fe7
Author: Simon Schampijer 
Date:   Sat Nov 3 15:17:09 2012 +0100

 Get back a working activity history, SL #4131

It breaks on Debian and Ubuntu, it works on Fedora 18 and 19. I guess it's
either a Fedora patch or a more recent libvte required?

I'd prefer to change the code to work also with old/unpatched libvte then
to add a new module to the build for Ubuntu and Debian.


http://bugs.sugarlabs.org/ticket/4131 should point to the upstream fix. 
And state which upstream has the fix. Which version etc. Gonzalo, can 
you put some light on it. The upstream ticket was [1].


Simon

[1] https://bugzilla.gnome.org/show_bug.cgi?id=676999
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] How to deploy the webactivity libraries

[Simon Schampijer]

On 05/29/2013 08:17 PM, Daniel Narvaez wrote:

Since I'm the one proposing the implementation, and I'm actually not too
keen about the idea itself, let me take a step back before I get blamed for
it forever :)

My feeling is that we should *not* implement this for 0.100 but rather
consider (very carefully) if it's something we need in one of the next
iterations. Cutting on philosophical considerations, I think we are not
going to be able to provide anything like a stable API for 0.100, for
several reasons including

* We are all too new to this game.
* The time is short and we are not seeing activities being developed yet.
* The web platform is a moving target.
* I have the feeling stable API on html+css+js might be harder than on
traditional interfaces.

Without a stable API, system libraries are just going to cause more issues
then benefits, with activities randomly breaking because the library is too
new or too old.


So you mean for now, we should just add a copy of sugar-web library into 
each activity bundle. And then in the next step deal with the packaging 
of sugar-web as a dependency?


On the packaging end this means that for the next release the packaging 
of the core will not change at all (sugar, sugar-toolkit-gtk3...). Only 
the webactivities need to be packaged and those contain sugar-web.


I think this would be a good compromise for now, given that things are 
in flux. And in the html+css+js world things seem to change fast, let's 
see which package management will survive the next months [1]. Maybe 
volo is gone by then.


About activity development: we should shape the API while we develop 
activities. I am starting with that process now. The more people doing 
that the better, as now we can change API quickly. Of course for a 
developer this means a rather flux environment.


Regards,
   Simon

[1] 
https://wibblycode.wordpress.com/2013/01/01/the-state-of-javascript-package-management/

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Broken build, terminal

[Daniel Narvaez]

Traceback (most recent call last):
  File
"/home/buildbot/slave/raring-amd64-quick/build/build/out/install/lib/python2.7/site-packages/sugar3/activity/activity.py",
line 906, in _prepare_close
self.save()
  File
"/home/buildbot/slave/raring-amd64-quick/build/build/out/install/lib/python2.7/site-packages/sugar3/activity/activity.py",
line 740, in save
self.write_file(file_path)
  File
"/home/buildbot/slave/raring-amd64-quick/build/build/out/install/share/sugar/activities/Terminal.activity/terminal.py",
line 424, in write_file
text, attr = page.vt.get_text(is_selected, None)
AttributeError: 'Terminal' object has no attribute 'get_text'

Caused by

commit b90dac1ad2b8916b123e71b73848636f83fa9fe7
Author: Simon Schampijer 
Date:   Sat Nov 3 15:17:09 2012 +0100

Get back a working activity history, SL #4131

It breaks on Debian and Ubuntu, it works on Fedora 18 and 19. I guess it's
either a Fedora patch or a more recent libvte required?

I'd prefer to change the code to work also with old/unpatched libvte then
to add a new module to the build for Ubuntu and Debian.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Which project to translate at translate.sugarlabs.org

[Chris Leonard]

On Thu, May 30, 2013 at 1:42 AM, Peter Robinson  wrote:
> It's my understand the translations are pulled in a package build
> time. In the case of the core Sugar interface and OS packages that's
> when the rpms are built. In the case of the Activities that's when
> they're bundled into the .xo files. Translations have to be pulled
> from pootle to be actually included. If you look at just about all the
> recent Activity releases they are all primarily to pull in updated
> translations.
>
> When exactly were the translations committed to translate.sl.org that
> you are after.


Besides looking at the git repo for commits by Poolte, we do log all
Pootle commits on this utility list for keeping track of commits.

http://lists.sugarlabs.org/listinfo/pootle-commits

You would have to search for ne and the correct Sugar version to
determine when it was committed.

e.g.

http://lists.sugarlabs.org/archive/pootle-commits/2013-May/008233.html

http://lists.sugarlabs.org/archive/pootle-commits/2012-October/006717.html
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel