Re: new Linaro kernel branch available: linux-linaro-2.6.36

[Dave Martin]

Hi,

On Thu, Nov 11, 2010 at 5:59 AM, Nicolas Pitre  wrote:
> Now that the Linaro release is shipping with a 2.6.35 kernel, we need to
> move forward.  I therefore created a linux-linaro-2.6.36 tree which
> contains the v2.6.36 core code but with the latest ARM specific pieces
> from mainline.

Do we have any working configs for linaro supported platforms for use
with this tree?

I quickly tried to build omap based on the packaged stable kernel
config, but I ran into some errors -- let me know if you want more
detail.

For the Thumb-2 and SMP-UP integration work I'd like a config with a
full set of modules that I can test, but I don't care so much about
what platform it is.


Cheers
---Dave

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: new Linaro kernel branch available: linux-linaro-2.6.36

[Anand Gadiyar]

On 11/11/2010 11:29 AM, Nicolas Pitre wrote:
> Now that the Linaro release is shipping with a 2.6.35 kernel, we need to 
> move forward.  I therefore created a linux-linaro-2.6.36 tree which 
> contains the v2.6.36 core code but with the latest ARM specific pieces 
> from mainline.
> 
> This branch is meant to be stable i.e. it won't be rebased, and only 
> patches believed to be in a state ready for mainline inclusion should be 
> merged in that tree.  That should provide a more recent basis for people 
> wanting to forward port their work but who are not comfy with a -rc 
> kernel.
> 
> Of course this didn't get any significant level of testing yet.  Please 
> report any issue you may have with it.

I did a quick boot test with the pandaboard, and can boot up to
a serial console on ttyO2. I used the omap2plus_defconfig to
build. The same image boots up on OMAP3 as well.

- Anand

> Nicolas
> 
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: new Linaro kernel branch available: linux-linaro-2.6.36

[Anand Gadiyar]

On 11/11/2010 4:55 PM, Dave Martin wrote:
> Hi,
> 
> On Thu, Nov 11, 2010 at 5:59 AM, Nicolas Pitre  
> wrote:
>> Now that the Linaro release is shipping with a 2.6.35 kernel, we need to
>> move forward.  I therefore created a linux-linaro-2.6.36 tree which
>> contains the v2.6.36 core code but with the latest ARM specific pieces
>> from mainline.
> 
> Do we have any working configs for linaro supported platforms for use
> with this tree?
> 
> I quickly tried to build omap based on the packaged stable kernel
> config, but I ran into some errors -- let me know if you want more
> detail.
> 

The omap2plus_defconfig works for me, on OMAP3 and OMAP4 both.

Could you let me know what errors you see? I can take a stab at fixing
them. (Or just point me to your config).


> For the Thumb-2 and SMP-UP integration work I'd like a config with a
> full set of modules that I can test, but I don't care so much about
> what platform it is.

SMP_ON_UP is working on this kernel I think - the OMAP4 booted up
with both cores, while the OMAP3 - a unicore cpu - also booted up with
the same image.

> 
> 
> Cheers
> ---Dave
> 
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: new Linaro kernel branch available: linux-linaro-2.6.36

[Dave Martin]

Hi,

On Thu, Nov 11, 2010 at 11:32 AM, Anand Gadiyar  wrote:
[...]
>> On Thu, Nov 11, 2010 at 5:59 AM, Nicolas Pitre  
>> wrote:
>>> Now that the Linaro release is shipping with a 2.6.35 kernel, we need to
>>> move forward.  I therefore created a linux-linaro-2.6.36 tree which
>>> contains the v2.6.36 core code but with the latest ARM specific pieces
>>> from mainline.
>>
>> Do we have any working configs for linaro supported platforms for use
>> with this tree?
>>
>> I quickly tried to build omap based on the packaged stable kernel
>> config, but I ran into some errors -- let me know if you want more
>> detail.
>>
>
> The omap2plus_defconfig works for me, on OMAP3 and OMAP4 both.

OK, I'll probably pick up that config as a starting point -- thanks.

> Could you let me know what errors you see? I can take a stab at fixing
> them. (Or just point me to your config).

Unfortunately I threw the tree away, but I'll try to regenerate it at
some point and let you know.

>> For the Thumb-2 and SMP-UP integration work I'd like a config with a
>> full set of modules that I can test, but I don't care so much about
>> what platform it is.
>
> SMP_ON_UP is working on this kernel I think - the OMAP4 booted up
> with both cores, while the OMAP3 - a unicore cpu - also booted up with
> the same image.

That's good news.  I will certainly give it a try.

The challenge is expected when getting this working with Thumb-2 ;)

Cheers
---Dave

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Problems with BeagleBoard installation

[Dave Martin]

Hi,

[...]

>
> Having said that, last week, being in Olympia, I was "promoting" Linaro
> images between my colleagues there, and their first question was: Ok, so
> why there is no "Try me" or "Download" link from neither www.lnaro.org
> nor main wiki page?
>
There's a "get started" link on the new http://www.linaro.org/ page.

It could be clearer, but I think it's better than what used to be there.

Any help?

Cheers
---Dave

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Please review other-linaro-n-test-result-display-in-launch-control

[Zygmunt Krynicki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.

I'd like to get your feedback on this blueprint:

https://blueprints.edge.launchpad.net/linaro/+spec/other-linaro-n-test-result-display-in-launch-control

Thanks
Zygmunt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJM2+VfAAoJEKkR4hQBRI+lqgwH/2R7UlgDRnLdqTeEq0V2CUhz
qa/v1TgAXMKXOp86hjBk8/sojS6gIbRJ5iEAdytNB8BR4/rqadZKlyh0IiZSF1uv
zt0Rpg/+yhkjpnuFBxPqyBa5Z/Z2X+nuqIZQcvmINzyB8c1VgaQi902neuBs3iUb
QkLcIGpCNZ6re0/XpW4pJLin9FkOq59Lkvc5kZ3WJH8G7Gtd38jVTQ4xBjT69qQT
Z3OJplEZ29MVTyfgRkwDMUB+PjAd/1S2kAndfJJFb/KDNFjRLrBSSCCB4/5QXrWF
xT7C8TmeyMbnMI7LY8a73mheERX+pGYdgqKGY8weiuW7ohEiTk0k79wW+eNUaaA=
=eLf1
-END PGP SIGNATURE-

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Ubuntu ARM and the linaro kernels

[Ricardo Salveti]

On Tue, Nov 9, 2010 at 6:58 PM, Nicolas Pitre  wrote:
> On Tue, 9 Nov 2010, Oliver Grawert wrote:
>
>> hi,
>> Am Montag, den 08.11.2010, 15:46 + schrieb Jamie Bennett:
>> > > * linaro kernels used in ubuntu ARM would need to move to the
>> > > supported
>> > > package set (main) which makes them fall under all freeze restrictions
>> > > the kernel team sets for ubuntu (only SRUs post kernel freeze, patches
>> > > and changes all need to go through the ubuntu-kernel mailing list etc)
>> >
>> > I think we can deal with the via the SRU process. We have already been
>> > using the SRU process this cycle for kernel changes so its a non-issue.
>> well, the kernel freeze and SRU process would happen for you guys a lot
>> earlier due to that, thats why i wanted to bring it up ...
>
> While I see lots of goodness in trying to reduce this duplicated effort,
> I think there is still a slight disconnect between Linaro's and Ubuntu's
> goals for their respective kernels.  While Ubuntu should focus on the
> greatest support to enhance the user experience, Linaro is there to
> promote support of the ARM architecture in general through consolidation
> towards the mainline kernel.
>
> This means that, for example, that the Linaro kernel will not merge
> anything with no hope of ever being accepted upstream, including stuff
> like a single patch adding 45 thousand lines of code in one shot to
> support proprietary 3D graphics libraries.  Now that we have a corporate
> backed entity to promote upstream contributions for the greater benefit
> of all members, we should not weaken this principle by carrying
> proprietary drivers with a dead future which would send a wrong signal.
>
> However, the Ubuntu kernel has little choice but to merge those
> proprietary drivers as the unfortunate fact is that there is simply no
> alternative (yet) to produce a viable 3D user experience.  And I'm
> afraid that this burden has to be carried on the Ubuntu side.  Let's
> hope that the reduced engineering effort on the Ubuntu side due to the
> work now undertaken by the Linaro team will compensate for this
> continuing burden.

That's understandable. Now the question is why John is maintaining and
packaging a tree that also incorporate the Ubuntu sauce on it?

> Linaro is also driving a work force which should serve the greater ARM
> Linux ecosystem, including Ubuntu on ARM of course, but other entities
> as well.  Therefore the Linaro process cannot always be tied to the
> Ubuntu process.  This means that Linaro may not always follow the exact
> same schedule as Ubuntu, and things like Ubuntu sauce patches and/or
> kernel configs might not make sense in all Linaro contexts.

I also agree on this one. I believe that now that Linaro is getting
more popular and used by other entities, makes no much sense in
maintaining something that will be used by Ubuntu. Only a reference
and maintained tree would probably be enough in case distros want to
incorporate it.

>> one option i see is that we use the linaro branches as base and add all
>> distro kernel specifics on top here, but thats something the kernel team
>> has to agree to since they will have to be the ones doing that work (and
>> i personally cant really judge how much work this is for them).
>
> I'm afraid this might have to be the case.  However, Git is pretty
> powerful and effective to carry such a task.

This will probably be the case. At least it's the one that makes more
sense in the Linaro's perspective.

Now the question is, are we sure that this will actually reduce the
workflow for the Ubuntu kernel team? I know in case of Omap 3 it was
one additional flavor, but was somehow OK because it follows upstream
and they are already used with it. Having the Linaro tree as reference
instead of upstream will probably produce a better ARM kernel, but it
seems that it'll give more work to the kernel team, instead of making
things easier.
-- 
Ricardo Salveti de Araujo

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Problems with BeagleBoard installation

[Dave Martin]

Hi there,

For instructions on obtaining and installing the release, you can
visit https://wiki.linaro.org/Releases/1011/Final and click on the
link under "Instructions"

There's also now a high-level video walkthrough at
http://www.linaro.org/low-cost-development-boards/


All this can be found by following links from "Getting started" on
http://www.linaro.org/ ... but I'd agree it's still not as obvious as
it could be.

Jamie et al. -- any ideas on how we can make this more straightforward
for newcomers?

Cheers
---Dave

On Thu, Nov 11, 2010 at 1:17 PM, Pawel Moll  wrote:
>> There's a "get started" link on the new http://www.linaro.org/ page.
>> It could be clearer, but I think it's better than what used to be there.
>> Any help?
>
> Oh, it's much better only, if only with the big "Downloads" link on the
> frontpage :-)
>
> The only thing I could complain now about is that I didn't find any
> visible link to "how to prepare a card with the image" (I mean "how to
> use linux-media-create"). But maybe I just missed it somewhere? I looked
> at the http://www.linaro.org/downloads/ and
> https://wiki.linaro.org/Releases/1011 pages).
>
> Cheers!
>
> Paweł
>
> PS. The "linux-linaro-2.6.35.git" link on the
> http://www.linaro.org/downloads/ points to the "next" repo instead of
> "2.6.35"...
>
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Problems with BeagleBoard installation

[Anca Emanuel]

On Thu, Nov 11, 2010 at 3:24 PM, Dave Martin  wrote:
> Hi there,
...

> Jamie et al. -- any ideas on how we can make this more straightforward
> for newcomers?

I want to test in qemu, Ubuntu 10.10, Intel Core Duo, 2GB RAM machine.
Any instructions ?
An step by step tutorial, with printscreens, will be great.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

RE: [PM] 10/11/2010 - Minutes for the Power Management WG weekly call

[Vishwanath Sripathy]

ACTION: Vishwa to send link for patches (patchworks) for ARM
context save and restore (for OMAP) to the team (mainly for Yong
and Vincent).
Patches posted to LO (mainly OMAP CPUIdle assembly code clean
up):
https://patchwork.kernel.org/patch/204172/
https://patchwork.kernel.org/patch/204182/

Details and patches on Trace point based Instrumentation:
http://omapedia.org/wiki/Power_Management_Debug_and_Profiling
http://omapedia.org/wiki/Power_Management_Device_Latencies_Measur
ement

Regards
Vishwa
> -Original Message-
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Amit Arora
> Sent: Wednesday, November 10, 2010 4:38 PM
> To: linaro-dev@lists.linaro.org
> Subject: [PM] 10/11/2010 - Minutes for the Power Management WG
> weekly call
> 
> Hello Everyone,
> 
> The minutes of the weekly call can be found at:
>
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/20
10
> -11-10
> 
> Attendees: Amit Arora, Amit Kachhap, Vincent, Yong and Vishwa
> 
> Highlight: Discussed individual High Priority blue prints for
status
> and any issues - specially conflicting priorities and any
blockers.
> 
> Regards,
> Amit Arora
> 
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Problems with BeagleBoard installation

[Jamie Bennett]

On 11 Nov 2010, at 13:30, Pawel Moll wrote:


For instructions on obtaining and installing the release, you can
visit https://wiki.linaro.org/Releases/1011/Final and click on the
link under "Instructions"
All this can be found by following links from "Getting started" on
http://www.linaro.org/ ...


Well, can it? ;-)

What I see is that the "Getting started" leads me to the "Downloads"
page, then there is this frame on the right side - "Download Linaro  
for

your board", right? The problem is that the link which is given there:
"More information on the development release as well as download and
installation instructions can be found at:
https://wiki.linaro.org/Releases/1011"; leads to "/Releases/1011" not  
to
"/Releases/1011/Final"... And as far as I can say there is no link  
from

the former to the latter?


There is a table at the bottom with all the release pages.


Probably just a mistake?

Cheers!

Paweł


Regards,
Jamie.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Problems with BeagleBoard installation

[Pawel Moll]

> For instructions on obtaining and installing the release, you can
> visit https://wiki.linaro.org/Releases/1011/Final and click on the
> link under "Instructions"
> All this can be found by following links from "Getting started" on
> http://www.linaro.org/ ... 

Well, can it? ;-)

What I see is that the "Getting started" leads me to the "Downloads"
page, then there is this frame on the right side - "Download Linaro for
your board", right? The problem is that the link which is given there:
"More information on the development release as well as download and
installation instructions can be found at:
https://wiki.linaro.org/Releases/1011"; leads to "/Releases/1011" not to
"/Releases/1011/Final"... And as far as I can say there is no link from
the former to the latter?

Probably just a mistake?

Cheers!

Paweł


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Problems with BeagleBoard installation

[Pawel Moll]

> You were so close. https://wiki.linaro.org/Releases has instructions  on how
> to obtain and use the Linaro images.

Oh sure! Just to be clear - I found it before, searching wiki. But this
time I just tried to pretend a fresher - say one of my Olympia
colleagues - and follow the big links :-)

> I have also asked for a big download link to be prominent on either the

And that's exactly what I was talking about - the huge "Downloads" link
is great.

>> https://wiki.linaro.org/Releases/1011"; leads to "/Releases/1011" not  > to
>> "/Releases/1011/Final"... And as far as I can say there is no link  > from
>> the former to the latter?
> There is a table at the bottom with all the release pages.

Uh, you're right - I found it with Ctrl-F. But not before, even if I
knew what I was looking for ;-)

To summarize, if I may suggest anything - changing the
"https://wiki.linaro.org/Releases/1011"; link on the "Downloads" page so
it points directly to "/Releases/1011/Final" would do the job, I
believe.

Cheers!

Paweł


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Problems with BeagleBoard installation

[Pawel Moll]

> There's a "get started" link on the new http://www.linaro.org/ page.
> It could be clearer, but I think it's better than what used to be there.
> Any help?

Oh, it's much better only, if only with the big "Downloads" link on the
frontpage :-)

The only thing I could complain now about is that I didn't find any
visible link to "how to prepare a card with the image" (I mean "how to
use linux-media-create"). But maybe I just missed it somewhere? I looked
at the http://www.linaro.org/downloads/ and
https://wiki.linaro.org/Releases/1011 pages).

Cheers!

Paweł

PS. The "linux-linaro-2.6.35.git" link on the
http://www.linaro.org/downloads/ points to the "next" repo instead of
"2.6.35"...


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Problems with BeagleBoard installation

[Jamie Bennett]

On 11 Nov 2010, at 13:17, Pawel Moll wrote:


There's a "get started" link on the new http://www.linaro.org/ page.
It could be clearer, but I think it's better than what used to be  
there.

Any help?


Oh, it's much better only, if only with the big "Downloads" link on  
the

frontpage :-)

The only thing I could complain now about is that I didn't find any
visible link to "how to prepare a card with the image" (I mean "how to
use linux-media-create"). But maybe I just missed it somewhere? I  
looked

at the http://www.linaro.org/downloads/ and
https://wiki.linaro.org/Releases/1011 pages).


You were so close. https://wiki.linaro.org/Releases has instructions  
on how

to obtain and use the Linaro images.

I have also asked for a big download link to be prominent on either the
linaro.org site or we could add it to the wiki.


Cheers!

Paweł


Regards,
Jamie.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Problems with BeagleBoard installation

[Jamie Bennett]

On 11 Nov 2010, at 13:53, Pawel Moll wrote:

You were so close. https://wiki.linaro.org/Releases has  
instructions  on how

to obtain and use the Linaro images.


Oh sure! Just to be clear - I found it before, searching wiki. But  
this

time I just tried to pretend a fresher - say one of my Olympia
colleagues - and follow the big links :-)

I have also asked for a big download link to be prominent on either  
the


And that's exactly what I was talking about - the huge "Downloads"  
link

is great.

https://wiki.linaro.org/Releases/1011"; leads to "/Releases/1011"  
not  > to
"/Releases/1011/Final"... And as far as I can say there is no  
link  > from

the former to the latter?

There is a table at the bottom with all the release pages.


Uh, you're right - I found it with Ctrl-F. But not before, even if I
knew what I was looking for ;-)

To summarize, if I may suggest anything - changing the
"https://wiki.linaro.org/Releases/1011"; link on the "Downloads" page  
so

it points directly to "/Releases/1011/Final" would do the job, I
believe.


Thats for Michael to do but for the meantime I'll added explicit  
download links

on the https://wiki.linaro.org/Releases/1011 page.


Cheers!

Paweł


Regards,
Jamie.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Problems with BeagleBoard installation

[Pawel Moll]

> Thats for Michael to do but for the meantime I'll added explicit 
> download links on the https://wiki.linaro.org/Releases/1011 page.

Looks great - probably it's an even better solution than what I
suggested before.

Cheers!

Paweł



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

linaro-next tree

[Lorenzo Pieralisi]

Hi Nicolas,

I noticed that a merge of Grant's ARM DT patches stack into linaro-stable
is on the cards and this is good news.

I have a couple of questions on linaro-next though.

I think it is supposed to track mainline closely, and on this
I'd ask your thoughts please since it does not seem to be so at present.
It could be nice for us to have a development kernel to base our work against
in order to get the latest mainline goodness (and to have a current base to
test/develop patches coming from different git dev trees that are not in the
mainline yet), but still trying to consolidate code for future linaro stable
releases.

To sum it up, I am just asking you what are your plans for the linaro-next 
tree and the operating mode we should aim for.

Thank you very much indeed.

Cheers,
Lorenzo

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Linaro Infrastructure Team Weekly Report (2010-11-05 to 2010-11-11)

[Ian Smith]

All,

The weekly report for the Linaro Infrastructure team may be found at:-
Status report: https://wiki.linaro.org/Platform/Infrastructure/Status/2010-11-11
Burndown 
chart:http://people.canonical.com/~pitti/workitems/maverick/linaro-infrastructure.html


The Infrastructure related blueprints, of which currently there are 4 active 
ones (4 from the last report), are showing that there are 8 work items in 
progress (11 last report), and 12 work items to undertake (12 last report). 

arm-m-validation-dashboard;0 work items completed since last report; 2 
in progress;8 to do
arm-m-image-building-console;  3 work items completed since last report; 4 
in progress;3 to do 
arm-m-automated-testing-framework;  no change in status from last report; 1 in 
progress;0 to do
arm-m-testsuites-and-profilers;no change in status from last report; 1 in 
progress;1 to do

In arm-m-image-building-console, 4 items are awaiting review before they can be 
completed (6 last report).

The focus for the team in the past week has remained on preparing Blueprints 
for the next cycle.

Specifics accomplished this week include:-

* A number of branches were landed this week, including branches for 
passwords, a bug for configurable team access, and configurable email 
notifications.
* Produced a testplan for a headless version of the ISEE IGEP (Cortex A8) 
board.
* Locally integrated JSON (JavaScript Object Notation) schema support

Please let me know if you have any comments or questions.

Kind Regards,
ran
Ian











___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: linaro-next tree

[Nicolas Pitre]

On Thu, 11 Nov 2010, Lorenzo Pieralisi wrote:

> Hi Nicolas,
> 
> I noticed that a merge of Grant's ARM DT patches stack into linaro-stable
> is on the cards and this is good news.

Yes.  Even if the DT patches are not yet guaranteed to go into mainline, 
I'm willing to merge them sooner in the hope of breaking the chicken and 
egg problem we're currently facing.

> I have a couple of questions on linaro-next though.
> 
> I think it is supposed to track mainline closely, and on this
> I'd ask your thoughts please since it does not seem to be so at present.

Right, it is lagging behind at present.

> It could be nice for us to have a development kernel to base our work against
> in order to get the latest mainline goodness (and to have a current base to
> test/develop patches coming from different git dev trees that are not in the
> mainline yet), but still trying to consolidate code for future linaro stable
> releases.

To that effect, I produced a new "stable" branch: linux-linaro-2.6.36.  
The core code is still 2.6.36 but most of the latest ARM specific bits 
and a few drivers to be found in 2.6.37-rc1 were merged into it.

> To sum it up, I am just asking you what are your plans for the linaro-next 
> tree and the operating mode we should aim for.

I'm still wondering about that myself at the moment.  Obviously, the 
linaro-next is _not_ a good base for development.  This is not a stable 
tree but rather a merge tree which is trashed and rebuilt from scratch 
every so often.  It is therefore only useful for testing purposes.  I'm 
therefore asking the question if it is actually useful, and if people 
did use it in the past.  If not then I could probably spend my time on 
other tasks.

The alternative I'm contemplating, which came after the decision to 
merge DT patches in the Linaro "stable" tree, is to continue merging 
patches in that branch and not rebase it, for people to be able to use 
it as a base for their own development.  The criteria for merging 
patches in this tree would be:

1) a patch to be merged is already in a later upstream tree, or

2) a proposed patch must have a high probability of being merged 
   upstream in the future, and

3) only bugfixes would be merged once a new "stable" branch is 
   available.

What do people think?


Nicolas

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Ubuntu ARM and the linaro kernels

[Nicolas Pitre]

On Thu, 11 Nov 2010, Ricardo Salveti wrote:

> On Tue, Nov 9, 2010 at 6:58 PM, Nicolas Pitre  
> wrote:
> > On Tue, 9 Nov 2010, Oliver Grawert wrote:
> >
> >> hi,
> >> Am Montag, den 08.11.2010, 15:46 + schrieb Jamie Bennett:
> >> > > * linaro kernels used in ubuntu ARM would need to move to the
> >> > > supported
> >> > > package set (main) which makes them fall under all freeze restrictions
> >> > > the kernel team sets for ubuntu (only SRUs post kernel freeze, patches
> >> > > and changes all need to go through the ubuntu-kernel mailing list etc)
> >> >
> >> > I think we can deal with the via the SRU process. We have already been
> >> > using the SRU process this cycle for kernel changes so its a non-issue.
> >> well, the kernel freeze and SRU process would happen for you guys a lot
> >> earlier due to that, thats why i wanted to bring it up ...
> >
> > While I see lots of goodness in trying to reduce this duplicated effort,
> > I think there is still a slight disconnect between Linaro's and Ubuntu's
> > goals for their respective kernels.  While Ubuntu should focus on the
> > greatest support to enhance the user experience, Linaro is there to
> > promote support of the ARM architecture in general through consolidation
> > towards the mainline kernel.
> >
> > This means that, for example, that the Linaro kernel will not merge
> > anything with no hope of ever being accepted upstream, including stuff
> > like a single patch adding 45 thousand lines of code in one shot to
> > support proprietary 3D graphics libraries.  Now that we have a corporate
> > backed entity to promote upstream contributions for the greater benefit
> > of all members, we should not weaken this principle by carrying
> > proprietary drivers with a dead future which would send a wrong signal.
> >
> > However, the Ubuntu kernel has little choice but to merge those
> > proprietary drivers as the unfortunate fact is that there is simply no
> > alternative (yet) to produce a viable 3D user experience.  And I'm
> > afraid that this burden has to be carried on the Ubuntu side.  Let's
> > hope that the reduced engineering effort on the Ubuntu side due to the
> > work now undertaken by the Linaro team will compensate for this
> > continuing burden.
> 
> That's understandable. Now the question is why John is maintaining and
> packaging a tree that also incorporate the Ubuntu sauce on it?

I think that the main reason is that this was much easier to have a 
packaged initial release by simply piggybacking on the existing Ubuntu 
infrastructure.  But John's tree and mine are still separate.

> >> one option i see is that we use the linaro branches as base and add all
> >> distro kernel specifics on top here, but thats something the kernel team
> >> has to agree to since they will have to be the ones doing that work (and
> >> i personally cant really judge how much work this is for them).
> >
> > I'm afraid this might have to be the case.  However, Git is pretty
> > powerful and effective to carry such a task.
> 
> This will probably be the case. At least it's the one that makes more
> sense in the Linaro's perspective.
> 
> Now the question is, are we sure that this will actually reduce the
> workflow for the Ubuntu kernel team? I know in case of Omap 3 it was
> one additional flavor, but was somehow OK because it follows upstream
> and they are already used with it. Having the Linaro tree as reference
> instead of upstream will probably produce a better ARM kernel, but it
> seems that it'll give more work to the kernel team, instead of making
> things easier.

What extra work do you see? Maybe we could discuss it?


Nicolas___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Notes & Actions: Linaro Multimedia Working Group - Nov 09, 2010

[Alexandros Frantzis]

Hi,

notes and actions from our Tuesday multimedia cross-vendor call are
available on the wiki:

 + https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2010-11-09

Details about when and where of this meeting can be found here:

 + 
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia#Weekly%20Public%20Call


Thanks,

-- 

 - Alexandros

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Notes & Actions: Linaro Graphics Working Group - Nov 08, 2010

[Alexandros Frantzis]

Hi,

notes and actions from our Monday graphics cross-vendor call are
available on the wiki:

 + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2010-11-08

Details about when and where of this meeting can be found here:

 + 
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%20Call


Thanks,

-- 

 - Alexandros

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Teaching sbuild how to use xdeb

[Guilherme Salgado]

I thought this would be a simple question about integrating xdeb with
sbuild but as it turns out there are other things here that could
benefit from being discussed with a bigger audience, so I'm CCing
linaro-dev.

On Wed, 2010-11-10 at 21:30 +, Wookey wrote:
> +++ Guilherme Salgado [2010-11-10 17:49 -0200]:
> > Hi Wookey,
> > 
> > As I've mentioned on IRC, we want to have sbuild do cross builds using
> > xdeb so that we can use it in
> > .
> 
> Oh, that looks interesting. I'm very keen to have a cross-autobuilder
> churning through things to find out how much stuff actually
> cross-builds at the moment.
> 
> In fact reading that work thing you seem to be wanting to build
> exactly what I want to build: a system that repeatably builds
> packages in pristine chroots. I thought sbuild didn't normally do the
> pristine chroot thing? (which is why I've been using pbuilder to
> supply that functionality to date).

Yeah, I don't think sbuild itself provides that, so I'm using schroot's
type=file chroots for that.  You just point schroot to a tarball
containing your chroot and it will (by default) create a new session
(with a pristine chroot) every time you 'schroot -c '.  If you
want to change the contents of the tarball you can easily do that with
'schroot -c -source'.  All you need for that to work is the
following config:

[natty]
description=Natty chroot
type=file
file=/var/chroots/natty.tar
location=/natty

> 
> If you look at my (Still developing) cross-building spec:
> https://wiki.linaro.org/Platform/Foundations/Specs/CrossBuilding
> you'll see that I have very similar ideas, but I want to have tools to
> do the various aspects of this job (satisfy-cross-deps, upload things,
> download things, do build-ordering), rather than the unhelpfully
> monolithic xdeb. 

It's certainly a good idea to have separate tools (or maybe even
libraries?) for the various aspects, and although at first that didn't
seem necessary to reach our goals in PackageDevelopmentTools, I think
it's clearly becoming more important now as we find opportunities to
collaborate.

> 
> Do you realise that pdebuild-cross (in maverick) already makes a chroot to do
> cross-building in with a single command: 'pdebuild-cross-create'? 

I didn't know about that; I'm still finding my way around all these
tools for cross-building debs. :)

> It installs a base system plus crosstoolchains
> plus build-essential. (defaults to -aarmel). Currently there is just a
> config for maverick, but we can add some more if we want to have natty
> and natty+ppearses flavoured toolchains. That 'make me a cross-chroot'
> stuff hides the bits you detail in "Notes on using sbuild+xdeb to do
> cross compilation" on having to make sure source lines are put in and
> cross-tools installed and so on. It's all done already :-)

That sounds quite nice, and I'm all for not reinventing the wheel, so
I'll have a look at pdebuild-cross.

I just ran pdebuild-cross-create and that seems to create the chroot and
tar it up, so even if we go with sbuild I should be able to use
pdebuild-cross to create the chroots.

> 
> That actually uses multistrap to do the hard work of setting up the
> chroots with the right stuff. This is useful because debootstrap can't
> take a base system from here and tool from there - everything has to
> come from one place (although we could probably fix that). multistrap
> has a neat cascading config scheme for making chroots so you can say
> 'maverick + armel-cross-build + this-toolchain'. This is very handy in
> the real world where the parts you need are not necessarily (yet) in
> the distro.
> 
> > After learning and experimenting a bit, this is what I came up with.  I
> > have some specific questions further down, but any feedback you might
> > have is appreciated.
> 
> I am nervous about sbuild+xdeb. It depends exactly what you are
> trying to do, but xdeb's caching and recursive build behaviour, whilst
> useful in some ways, also means that builds are not repeatable unless
> you either go to special effort to clean things our or do the builds
> in a disposable chroot. (pbuilder gives you the disposable thing for
> free, at the expense of the time it takes to unpack and install deps
> each time). I want a cross-builder to the same thing each time I ask
> it to build a package. xdeb doesn't help at all with that as currently
> designed. Ah, I see you want that too and propose schroot
> snapshots+sessions. That's cool. I've used schroot a lot for managing
> cross-build chroots in the past, but that was persistent ones, not
> snapshotted pristine ones. You'll have to show me how that works. We
> appear to agree completely on the principles of the thing :-) 

And I hope we can agree on the tools as well.  The reason why I went
with sbuild is because I was told it'd be more suitable for this job
than pbuilder, and one thing I liked a

Re: Teaching sbuild how to use xdeb

[James Westby]

On Thu, 11 Nov 2010 17:32:06 -0200, Guilherme Salgado  
wrote:
> > Oh, that looks interesting. I'm very keen to have a cross-autobuilder
> > churning through things to find out how much stuff actually
> > cross-builds at the moment.
> > 
> > In fact reading that work thing you seem to be wanting to build
> > exactly what I want to build: a system that repeatably builds
> > packages in pristine chroots. I thought sbuild didn't normally do the
> > pristine chroot thing? (which is why I've been using pbuilder to
> > supply that functionality to date).

We want to enable people to testbuild packages in a chroot. That may be
a building block that you can make use of to set up an autobuilder.

> Yeah, I don't think sbuild itself provides that, so I'm using schroot's
> type=file chroots for that.  You just point schroot to a tarball
> containing your chroot and it will (by default) create a new session
> (with a pristine chroot) every time you 'schroot -c '.  If you
> want to change the contents of the tarball you can easily do that with
> 'schroot -c -source'.  All you need for that to work is the
> following config:
> 
> [natty]
> description=Natty chroot
> type=file
> file=/var/chroots/natty.tar
> location=/natty

That's one way of using it. I believe that if you just use a plain
chroot type then sbuild will attempt to remove the build-dependencies it
installed at the end of its run (obviously this is less reliable).

> > I think there is a better way, as largely elaborated above: give
> > sbuild a cross-dep resolver, use apt to install things of the
> > appropriate arch, passed through dpkg-cross if no multiarch version of
> > package available. And just issue dpkg-buildpackage -a
> > to do cross-builds. 
> 
> That sounds fine as well, and it's definitely more appealing given that
> we should be able to share at least parts of the new tools/libraries we
> develop.

sbuild already understands something about architectures, as you can
e.g. do -ai386 on an amd64 system, and it will do the right
thing. Perhaps it just needs this extending to handle cases where it
should cross-build, and use an appropriate dep-solving algorithm and
toolchain.

Also of interest is

  http://lists.debian.org/debian-devel/2010/11/msg00170.html

Would that change allow us to piggyback on any other work for the
cross-dep-solving, or would that basically require multi-arch to be
implemented?

Thanks,

James

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Teaching sbuild how to use xdeb

[Loïc Minier]

On Thu, Nov 11, 2010, Guilherme Salgado wrote:
> > In fact reading that work thing you seem to be wanting to build
> > exactly what I want to build: a system that repeatably builds
> > packages in pristine chroots. I thought sbuild didn't normally do the
> > pristine chroot thing? (which is why I've been using pbuilder to
> > supply that functionality to date).
> 
> Yeah, I don't think sbuild itself provides that, so I'm using schroot's
> type=file chroots for that.  You just point schroot to a tarball
> containing your chroot and it will (by default) create a new session
> (with a pristine chroot) every time you 'schroot -c '.  If you
> want to change the contents of the tarball you can easily do that with
> 'schroot -c -source'.  All you need for that to work is the
> following config:
> 
> [natty]
> description=Natty chroot
> type=file
> file=/var/chroots/natty.tar
> location=/natty

 Seems it's actually on topic, I'd love sharing my setup!  :-)

 To setup, I use this schroot.conf snippet:
[natty]
type=file
description=Ubuntu natty
root-users=lool
file=/srv/schroot/chroot-ubuntu-natty-amd64.tar.bz2
location=/chroot-autobuild
preserve-environment=true

 /srv/schroot/chroot-ubuntu-natty-amd64.tar.bz2 is the chroot used on
 Launchpad buildds for natty/amd64.  I'm attaching dl-lp-chroot which
 downloads such a chroot; it's a trivial wrapper around
 https://launchpad.net/api/devel/ubuntu/$dist/$arch/chroot_url URLs


 To use, I then do something like:
mkdir ~/xdeb-dpkg
cd ~/xdeb-dpkg
schroot-xdeb --apt-source --only-explicit dpkg -aarmel

 (the above are just whatever xdeb args I'd like to use)

 schroot-xdeb will install xdeb and a cross-toolchain; it's sadly
 hardcodes my local mirror, but could obviously be adapted

 I should probably implement a feature to wait for confirmation before
 destroying the temporary chroot on failure.

PS: the above run will fail because xdeb doesn't import selinux for some
reason; but it does illustrate things quite well here  :-)
-- 
Loïc Minier
#!/bin/sh
# dl-lp-chroot - download a chroot tarball from Launchpad
# Copyright (C) 2010 Loïc Minier 
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
# SOFTWARE IN THE PUBLIC INTEREST, INC. BE LIABLE FOR ANY CLAIM, DAMAGES OR
# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
#
# Except as contained in this notice, the name of the author shall not be used
# in advertising or otherwise to promote the sale, use or other dealings in
# this Software without prior written authorization from the author.
#
# depends: wget

set -e

self="$(basename "$0")"
arch="`dpkg --print-architecture`"
dist="`lsb_release -cs`"
output_file=""

usage() {
echo "Usage: $self [--arch ] [--dist ] [-O output-file]" >&2
}

die() {
echo "$*" >&2
exit 1
}

if ! which wget >/dev/null; then
die "Please install wget"
fi

while [ $# -gt 0 ]; do
case "$1" in
  --help)
usage
exit 0
  ;;
  --arch)
arch="$2"
if [ -z "$arch" ]; then
die "Empty arch argument"
fi
shift 2
  ;;
  --dist)
dist="$2"
if [ -z "$dist" ]; then
die "Empty dist argument"
fi
shift 2
  ;;
  -O)
output_file="$2"
if [ -z "$output_file" ]; then
die "Empty output file argument"
fi
shift 2
  ;;
  *)
die "Unknown argument $1"
  ;;
esac
done

chroot_url="`wget -q -O - 
"https://launchpad.net/api/devel/ubuntu/$dist/$arch/chroot_url"; | tr -d '"'`"

exec wget ${output_file:+-O "$output_file"} "$chroot_url"

#!/bin/sh

set -e

dist="natty"
chroot="$dist"
arch="armel"
cross_pkgs="binutils-arm-linux-gnueabi gcc-arm-linux-gnueabi 
g++-arm-linux-gnueabi libc6-armel-cross"

session=""

cleanup() {
if [ -n "$session" ]; then
schroot -c "$session" -e
session=""
fi
}

export LC_ALL=C

session=`schroot -c "$chroot" -b`

trap "cleanup" 0 1 2 3 9 11 13 15

run_root() {
schroot -c "$session" -r -u root -- "$@"
}

run() {
sch

Re: Teaching sbuild how to use xdeb

[Wookey]

+++ Guilherme Salgado [2010-11-11 17:32 -0200]:
> I thought this would be a simple question about integrating xdeb with
> sbuild but as it turns out there are other things here that could
> benefit from being discussed with a bigger audience, so I'm CCing
> linaro-dev.

Good idea. I've been planning to send a 'the state of cross building
at the end of this cycle' mail very soon (once specs are done with),
to say what we have so far, what works and what doesn't. (before we
mess with things again :-) 

> On Wed, 2010-11-10 at 21:30 +, Wookey wrote:
> > +++ Guilherme Salgado [2010-11-10 17:49 -0200]:
> > > Hi Wookey,
> > > 

> That sounds quite nice, and I'm all for not reinventing the wheel, so
> I'll have a look at pdebuild-cross.
> 
> I just ran pdebuild-cross-create and that seems to create the chroot and
> tar it up, so even if we go with sbuild I should be able to use
> pdebuild-cross to create the chroots.

OK, glad that works for you too.

I guess if we decide not to use pbuilder at all but use schroot+sbuild
instead then we should call the relevant chroot-creation foo (which is
really multistrap config files and a command like multistrap -f
/usr/share/ubuntu/armel.conf) from somewhere else (if you look
pdebuild-cross-create is very thin veneer). This is a good example of
why tools to do each part well is good - because it becomes dead easy
to support the use of pbuilder or sbuild, as required. 

> > We appear to agree completely on the principles of the thing :-) 
> 
> And I hope we can agree on the tools as well.  The reason why I went
> with sbuild is because I was told it'd be more suitable for this job
> than pbuilder, and one thing I liked about it is that it's got most of
> its functionality packaged in a library (although it's written in perl)
> rather than a single tool.  Is pbuilder like that as well?

pbuilder is all shell, but seems quite well documented and put
together. I don't have strong opinions about it - we used it because
it was there and it was easy to do, and I was familiar with its
operation mode. 

it does have minus points: One disadvantage it has is that a 'make
clean' is done outside the chroot in order to generate a pristine
source package, and thus you need any deps that task needs installed
outside. That doesn't seem easily automable (because the package
doesn't tell you which of its deps are used by make clean, although in
practice a small number of packages (10?) seems to cover many cases.

The other thing I haven't yet found out how to do is to choose which
tools are used inside the chroot. You can have different hook-scripts
easily for different tools (e.g. building with xdeb or building
with xapt+dpkg-buildpackage), but it always wants to run all of them
and I don't see an easy mechanism for saying 'just run these this
time' (without copying different subsets in yourself). No idea if
sbuild makes this any easier or not. In actual use you don't need this
sort of choice anyway if you have a tool-set that works, but
it's handy for experimenting.

> > I still haven't worked out why everyone is so enamoured of xdeb, and
> > keep trying to design things round it. It has some useful features,
> 
> I can't answer that, but I can speculate:
>   - it does the job
>   - most Linaro docs I've seen about cross building use it
>   - we have in-house expertise on the tool
>   - it's written in python

That last is a big minus point from my POV :-) I've had to learn
python to change anything in it and I'm still rubbish at it, which
doesn't help speed development. I'm much happier messing with things
in perl and shell. I'm not 'ist' about these languages - it's just
much easier actually get things done in ones you already know. 

> > but it was designed as a bootstraping-from-local-sources tool, which
> > is not the same thing at all as a tool for cross-building individual
> > packages in a repository context. The clever bit of having heuristics
> > to supply deps is better dealt with by actually fixing the package
> > metadata, and for packages where that's not yet been done (arguably)
> 
> That's what MultiArch is about, right? 

Not exactly, but a feature of the way it is implemented provides
the metadata in dependencies that we need. And handily we can add this
without actually converting the package to multiarch so we can do a
whole pile of that easily. 

> MultiArch seems to be our
> long-term plan, but in the meantime we have to use something else.
> That's where xdeb becomes useful, AIUI.

It is, although my tests so far show that the tens-of-times-simpler
xapt seems to work just as well (slightly better in fact because it
doesn't barf on some packages) for cross-dependency satisfaction. 

> > I have never looked at sbuild so have no idea what the right way to
> > do this is. 
> 
> Err, I thought you would know because Steve L. told me to talk to you if
> I wanted to discuss implementation details.  Anyway, it's good that I
> did because otherwise we wouldn't have found t