Tian, Kevin wrote:
>> From: Ke, Liping
>> Sent: Monday, December 13, 2010 2:53 PM
>>
>> Hi, Jessica & Josh
>>
>> When we are trying to run installer script on lianhao's x86_64
>> machine, we found if the images are build in two days, according to
>> current version naming convention, some of the
Hi, Jessica
I have put the installer script tar ball in the below links:
http://llu-piketon.sh.intel.com/installer.tar
You can have a try. Below is some key notes:
1. since now version has problems, we have submit bug 586
http://bugzilla.pokylinux.org/show_bug.cgi?id=586
So currently we have n
>From: Ke, Liping
>Sent: Monday, December 13, 2010 2:53 PM
>
>Hi, Jessica & Josh
>
>When we are trying to run installer script on lianhao's x86_64 machine, we
>found if the
>images are build in two days, according to current version naming convention,
>some of the
>packages will be installed to /
Hi, Jessica & Josh
When we are trying to run installer script on lianhao's x86_64 machine, we
found if the images are build in two days, according to current version naming
convention, some of the packages will be installed to
/opt/poky/0.9+snapshot-20101210, some will be to
/opt/poky/0.9+snap
During the last phase of the recipe factoring, the board compatibility
lists ended up in the wrong place, which meant we had an incomplete
list of boards, and the same set of boards for both kernels (stable
and devel).
To fix this, I've yanked the compatibility to the recipes themselves and
update
During the last phase of the recipe factoring, the board compatibility
lists ended up in the wrong place, which meant we had an incomplete
list of boards, and the same set of boards for both kernels (stable
and devel).
To fix this, I've yanked the compatibility to the recipes themselves and
update
On Mon, Dec 13, 2010 at 12:05 AM, Bruce Ashfield
wrote:
> On 10-12-13 12:03 AM, Xu, Jiajun wrote:
>>>
>>> On Sun, Dec 12, 2010 at 9:10 PM, Xu, Jiajun wrote:
>
> [Resend with correct mailing lists]
>
>
> Yocto / Poky Folks:
>
> Thanks to everyone's hard work, we are cur
On Sun, Dec 12, 2010 at 9:10 PM, Xu, Jiajun wrote:
>> [Resend with correct mailing lists]
>>
>>
>> Yocto / Poky Folks:
>>
>> Thanks to everyone's hard work, we are currently on working getting
>> the first build of M2 started and available for QA testing on Monday.
>>
>> I have pushed out the last
Fixes [BUGID: 585]
The qemuppc irq handling was only partially updated to 2.6.37,
this completes the job. qemuppc builds and boots with this
change.
Signed-off-by: Bruce Ashfield
---
.../conf/distro/include/poky-default-revisions.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Somehow the ppc32 irq routines were only partially updated
to 2.6.37. I'll have to check later to see what happened, since
these were all built and booted here.
The fix is simple enough, here's the update for the SRCREV
that gets qemuppc building again.
Pull URL: git://git.pokylinux.org/poky-con
On 10-12-13 12:03 AM, Xu, Jiajun wrote:
On Sun, Dec 12, 2010 at 9:10 PM, Xu, Jiajun wrote:
[Resend with correct mailing lists]
Yocto / Poky Folks:
Thanks to everyone's hard work, we are currently on working getting
the first build of M2 started and available for QA testing on Monday.
I have
> On Sun, Dec 12, 2010 at 9:10 PM, Xu, Jiajun wrote:
>>> [Resend with correct mailing lists]
>>>
>>>
>>> Yocto / Poky Folks:
>>>
>>> Thanks to everyone's hard work, we are currently on working getting
>>> the first build of M2 started and available for QA testing on Monday.
>>>
>>> I have push
On 12/12/2010 05:43 PM, Ke, Liping wrote:
I tend to feel that this approach is more flexible, and scales better
than having to support each and every qemu option with our own script
syntax. Is this acceptable, or should we continue to support our own
custom options in addition to Criping's new a
> [Resend with correct mailing lists]
>
>
> Yocto / Poky Folks:
>
> Thanks to everyone's hard work, we are currently on working getting
> the first build of M2 started and available for QA testing on Monday.
>
> I have pushed out the lastest commit that was pending in the
> distro/master area t
> I tend to feel that this approach is more flexible, and scales better
> > than having to support each and every qemu option with our own script
> > syntax. Is this acceptable, or should we continue to support our own
> > custom options in addition to Criping's new approach?
>
> My gut feeling is
15 matches
Mail list logo
