Hi there. We all have the November release coming up. Even though
the different groups have different release cycles, it would be nice
to do a coordinated release in November that shows off the work we've
all been doing.
As part of that I want to make sure the toolchain outputs play well
togethe
Tom Gall wrote:
> Hi All,
>
> I've started a Eclipse page https://wiki.linaro.org/Eclipse/Evaluation
>
> It's mostly meant as a place to collect Eclipse information which
> perhaps might drive some future blueprints.
>
> It's mostly skeleton at this point so feel free to add to it.
>
Here are s
Hi James,
On Mon, Sep 13, 2010 at 05:11:19PM -0400, James Westby wrote:
> A further thought occurred to me the other day.
> I assume that we have to put the source packages in the hwpack too, for
> at least the packages with some GPL code. Given that hwpacks also serve
> as a snapshot of the arch
The weekly report for the Linaro Foundations team may be found at:
Status report: https://wiki.linaro.org/Platform/Foundations/2010-09-08
Overall status: https://wiki.linaro.org/Releases/FoundationsStatus
Work continues on bugfixing for the 10.11 release, as well as some spec work
not affecting
On Mon, 13 Sep 2010 23:59:42 +0200, Alexander Sack wrote:
> On Mon, Sep 13, 2010 at 11:11 PM, James Westby
> wrote:
> > I assume that we have to put the source packages in the hwpack too, for
> ...
> > Knowing which packages to include source for will be tricky, so I would
> > implement this as
Note that the ARM/Keil DS-5 (http://www.keil.com/arm/ds5/) and the
CodeSourcery SG++ (http://www.codesourcery.com/sgpp) are both Eclipse
based and focused on ARM.
To put in my unasked for two cents, I don't think Linaro should get
into this area as Eclipse is terrible to use, and the market is wel
On Mon, Sep 13, 2010 at 11:11 PM, James Westby wrote:
> I assume that we have to put the source packages in the hwpack too, for
...
> Knowing which packages to include source for will be tricky, so I would
> implement this as source for all of them, at least to start with.
Right, feels like a goo
Hi All,
I've started a Eclipse page https://wiki.linaro.org/Eclipse/Evaluation
It's mostly meant as a place to collect Eclipse information which
perhaps might drive some future blueprints.
It's mostly skeleton at this point so feel free to add to it.
Regards,
Tom
User Platforms
___
A further thought occurred to me the other day.
I assume that we have to put the source packages in the hwpack too, for
at least the packages with some GPL code. Given that hwpacks also serve
as a snapshot of the archive, we can't rely on a pointer to the original
archive to serve the purpose.
Kn
Hi Peter,
Are you past this? If not it might be easier to give me a call. If you
miss a response from me its best to also copy my r-woodru...@ti.com email
address (given my environment setup few mails age there much).
Where are you at in the world? I can verbally explain via phone more
quickly.
On Mon, 13 Sep 2010 12:35:05 +0200, Alexander Sack wrote:
> headless is already available and can already be used for testing
> (even if omap3 is in there atm). The other heads are failing to build
> because we don't have hardware packs yet.
>
> Now that you say that we won't hook up hwpack-creat
On Mon, 13 Sep 2010 17:03:16 +0200, Alexander Sack wrote:
> Sure: with this change we can produce our images without any kernel
> whatsoever (e.g. as those are coming from hwpacks).
Ok, we're back to this again. I still haven't heard any convincing
arguments for why that is a good idea. Could you
On Mon, 13 Sep 2010 10:50:29 +0200, Alexander Sack wrote:
> If the separate lexbuilder backend deployment causes any issues we can
> also just hook this up to live-helper so we produce the hwpacks in the
> headless run.
I've used hudson to build them for now, as it took just a few minutes as
I ha
I believe these patches will make powertop better for both x86 and
ARM. So are they OK for omap4?
If yes, I think we can apply them on ti-omap4 branch as well as master.
-Bryan
On Mon, Sep 13, 2010 at 2:31 PM, wrote:
> This is for powertop to run better on kernel. the first patch is back port
On Mon, 13 Sep 2010 11:08:19 -0400, James Westby
wrote:
> On Mon, 13 Sep 2010 17:03:16 +0200, Alexander Sack wrote:
> > Sure: with this change we can produce our images without any kernel
> > whatsoever (e.g. as those are coming from hwpacks).
>
> Ok, we're back to this again. I still haven't h
On Mon, 13 Sep 2010 16:51:34 +0200, Alexander Sack wrote:
> On Mon, Sep 13, 2010 at 4:03 PM, James Westby
> wrote:
> > On Mon, 13 Sep 2010 12:35:05 +0200, Alexander Sack wrote:
> >> headless is already available and can already be used for testing
> >> (even if omap3 is in there atm). The other
On Mon, 13 Sep 2010 16:48:52 +0200, Alexander Sack wrote:
> > Unfortunately the names change, and I don't know how to set up a
> > "current" link. However, there are stable URLs that get you most of the
> > way there, e.g.
> >
> > http://jameswestby.net:8080/view/Hardware%20Packs/job/linaro-omap3
On Mon, Sep 13, 2010 at 4:59 PM, James Westby
wrote:
> On Mon, 13 Sep 2010 16:51:34 +0200, Alexander Sack wrote:
>> From changelog:
>> * functions/defaults.sh:
>> + in turn allow builds without kernel flavours
>>
>> https://edge.launchpad.net/~asac/+archive/armel1/+files/live-helper_2.0%7Ea10
On Mon, Sep 13, 2010 at 4:03 PM, James Westby
wrote:
> Inclusion of dependencies isn't implemented yet, so these hwpacks aren't
> going to be usable as snapshots we can come back to yet. If that's
> really important then I can have that fixed today.
the important use case is really the kernel pac
On Mon, Sep 13, 2010 at 4:03 PM, James Westby
wrote:
> On Mon, 13 Sep 2010 12:35:05 +0200, Alexander Sack wrote:
>> headless is already available and can already be used for testing
>> (even if omap3 is in there atm). The other heads are failing to build
>> because we don't have hardware packs ye
On Mon, Sep 13, 2010 at 4:03 PM, James Westby
wrote:
> On Mon, 13 Sep 2010 10:50:29 +0200, Alexander Sack wrote:
> You can see the hwpacks at
>
> http://jameswestby.net:8080/view/Hardware%20Packs/
awesome ... i will check those a bit later.
>
> Unfortunately the names change, and I don't know
On Mon, Sep 13, 2010 at 12:25 PM, Scott Bambrough
wrote:
> On Mon, 2010-09-13 at 11:56 +0200, Alexander Sack wrote:
>> On Mon, Sep 13, 2010 at 11:49 AM, Scott Bambrough
>> wrote:
>> > On Mon, 2010-09-13 at 10:50 +0200, Alexander Sack wrote:
>> >> If the separate lexbuilder backend deployment caus
On Mon, 2010-09-13 at 11:56 +0200, Alexander Sack wrote:
> On Mon, Sep 13, 2010 at 11:49 AM, Scott Bambrough
> wrote:
> > On Mon, 2010-09-13 at 10:50 +0200, Alexander Sack wrote:
> >> If the separate lexbuilder backend deployment causes any issues we can
> >> also just hook this up to live-helper
awesome news ...
On Thu, Sep 9, 2010 at 11:53 PM, Alexandros Frantzis
wrote:
>
> 1. debian/patches/remove_cogl_gl_types.patch:
>
> This, of course, breaks some applications (clutk, mutter, gnome-shell to
> name a few) but the fix is trivial (just a correct GL header inclusion in
> the appli
On Mon, Sep 13, 2010 at 11:49 AM, Scott Bambrough
wrote:
> On Mon, 2010-09-13 at 10:50 +0200, Alexander Sack wrote:
>> If the separate lexbuilder backend deployment causes any issues we can
>> also just hook this up to live-helper so we produce the hwpacks in the
>> headless run.
>>
> No, this sho
On Mon, 2010-09-13 at 10:50 +0200, Alexander Sack wrote:
> If the separate lexbuilder backend deployment causes any issues we can
> also just hook this up to live-helper so we produce the hwpacks in the
> headless run.
>
No, this shouldn't be the case. Do it right the first time, and have a
longe
Bryan,
In general, I'd say yes they'd work with OMAP4 too.
As soon as TI turns on cpufreq/cpuidle config options for OMAP4, it should
all work since the patch to allow it to work on ARM is now upstream.
However, we haven't tested since we have no OMAP4 HW.
/Amit
On 10 Sep 13, Bryan Wu wrote:
On Fri, Sep 10, 2010 at 5:53 PM, James Westby
wrote:
> Hi,
>
> A hardware pack creation script is now available, so we can generate
> them, and the install script is close to being finished too. I have a
> lexbuidler backend that we can use later, but these things have so few
> requirements to bui
28 matches
Mail list logo
