Date   

Re: Supporting upcoming distribution releases

niqingliang
 

I think Archlinux is the preferred choice.-_-
Just joke.

I doubt why the bitbake need python2.x but just use /bin/env python. I
think If it need a specific version python, it should write it in the
shebang. e.g. /bin/env python2.6

On Wed, 2011-07-13 at 05:08 +0800, Richard Purdie wrote:
On Tue, 2011-07-12 at 12:01 -0700, Darren Hart wrote:

On 07/12/2011 11:51 AM, Joshua Lock wrote:
In our technical team call today we spent some time discussing how to
support distribution releases that are due to happen around the time of
Yocto 1.1.

Yocto 1.1 is scheduled for release on October 6th[1], the same month in
which both Ubuntu and Fedora have new releases planned[2,3].
OpenSUSE doesn't have a release scheduled until November 10th[4].

We should accommodate for these releases in our planning around 1.1 as
we need to ensure that Yocto 1.1 can be used on the new versions of the
chosen supported distros.

I had initially suggested we have people doing test and any relevant
development around the beta cycles of Ubuntu and Fedora:

Fedora Beta (2011-09-20)
Ubuntu (2011-09-01)
In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which
afaict (based on the 6th milestone being followed by an RC) should
roughly equate to a beta.

However this aligns with our RC period at which point we may not want to
accept large patches?

To meet our stabilise complete goal of August 29th we'd have to have
people testing with:
Fedora Alpha (2011-08-16)
Ubuntu Alpha 3 (2011-08-04)
OpenSUSE Milestone 4 (2011-08-11)

What are peoples thoughts on this?
At the very least a sanity test to know which sorts of issues we'll hit
with these would be valuable. However, I believe our policy is N-1, and
not N+1,N,N-1, so supporting not-yet released versions isn't something I
think we should spend too much time on. Minor fixes to support these
post release seem like good candidates for a point release.
Much as I'd like to agree with you, traditionally this does tend to bite
us hard. The fixes some of the releases have needed are sometimes not so
minor too :(.

The reason is that we have a community with a significant portion of
people who do stay close to the edge as far as distros go. They'll take
latest releases and expect Yocto to work on them even if the releases
come out at the same time. Its not often realised how far in advance
trees get frozen for stabilisation.

So summary is I'm in favour of trying to identify problems early and
then doing what we can to address them...

As such, this time around I'll update my build machine to latest Ubuntu
at the beginning of August....

Cheers,

Richard

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
--
倪庆亮
TEL: 13588371863
E-MAIL: niqingliang@...
BLOG: http://niqingliang2003.wordpress.com


[PATCH 2/2][KERNEL] meta-fri2: use iwlagn feature

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

Make use of the Intel wireless support for the Intel 6205 ABGN.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
meta/cfg/kernel-cache/bsp/fri2/fri2.scc | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc
index eca5cab..6ac0bfb 100644
--- a/meta/cfg/kernel-cache/bsp/fri2/fri2.scc
+++ b/meta/cfg/kernel-cache/bsp/fri2/fri2.scc
@@ -5,6 +5,7 @@ include features/intel-e1xxxx/intel-e1xxxx.scc
include features/dmaengine/dmaengine.scc
include features/serial/8250.scc
include features/ericsson-3g/f5521gw.scc
+include features/iwlagn/iwlagn.scc

include features/logbuf/size-normal.scc

--
1.7.0.4


[PATCH 1/2][KERNEL] meta: add mac80211 and iwlagn features

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

Add iwlagn feature (Intel Wirelss WiFi Next Gen AGN) and one of its
dependencies, mac80211, as a feature, since there are a bunch of other
config items that have the same dependency and could use it.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
meta/cfg/kernel-cache/features/iwlagn/iwlagn.cfg | 4 ++++
meta/cfg/kernel-cache/features/iwlagn/iwlagn.scc | 3 +++
.../kernel-cache/features/mac80211/mac80211.cfg | 5 +++++
.../kernel-cache/features/mac80211/mac80211.scc | 1 +
4 files changed, 13 insertions(+), 0 deletions(-)
create mode 100644 meta/cfg/kernel-cache/features/iwlagn/iwlagn.cfg
create mode 100644 meta/cfg/kernel-cache/features/iwlagn/iwlagn.scc
create mode 100644 meta/cfg/kernel-cache/features/mac80211/mac80211.cfg
create mode 100644 meta/cfg/kernel-cache/features/mac80211/mac80211.scc

diff --git a/meta/cfg/kernel-cache/features/iwlagn/iwlagn.cfg b/meta/cfg/kernel-cache/features/iwlagn/iwlagn.cfg
new file mode 100644
index 0000000..4119da7
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/iwlagn/iwlagn.cfg
@@ -0,0 +1,4 @@
+# iwgaln depends on NETDEVICES (base.cfg), PCI and MAC80211
+CONFIG_PCI=y
+
+CONFIG_IWLAGN=m
diff --git a/meta/cfg/kernel-cache/features/iwlagn/iwlagn.scc b/meta/cfg/kernel-cache/features/iwlagn/iwlagn.scc
new file mode 100644
index 0000000..afc76bc
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/iwlagn/iwlagn.scc
@@ -0,0 +1,3 @@
+kconf hardware iwlagn.cfg
+
+include features/mac80211/mac80211.scc
diff --git a/meta/cfg/kernel-cache/features/mac80211/mac80211.cfg b/meta/cfg/kernel-cache/features/mac80211/mac80211.cfg
new file mode 100644
index 0000000..d4a9374
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/mac80211/mac80211.cfg
@@ -0,0 +1,5 @@
+# mac80211 depends on NET (base.cfg), WIRELESS <- WLAN and CFG80211
+CONFIG_WLAN=y
+
+CONFIG_MAC80211=m
+CONFIG_CFG80211=m
diff --git a/meta/cfg/kernel-cache/features/mac80211/mac80211.scc b/meta/cfg/kernel-cache/features/mac80211/mac80211.scc
new file mode 100644
index 0000000..c2c02c8
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/mac80211/mac80211.scc
@@ -0,0 +1 @@
+kconf hardware mac80211.cfg
--
1.7.0.4


[PATCH 0/2][KERNEL] Add and use iwlagn and mac80211 features

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

This patchset adds a couple new features, iwlagn and mac80211 for the
fri2 BSP.

Please pull into linux-yocto-dev.

Pull URL: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib
Branch: tzanussi/linux-3.0/meta/iwlagn
Browse: http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/linux-3.0/meta/iwlagn

Tom Zanussi (2):
meta: add mac80211 and iwlagn features
meta-fri2: use iwlagn feature

meta/cfg/kernel-cache/bsp/fri2/fri2.scc | 1 +
meta/cfg/kernel-cache/features/iwlagn/iwlagn.cfg | 4 ++++
meta/cfg/kernel-cache/features/iwlagn/iwlagn.scc | 3 +++
.../kernel-cache/features/mac80211/mac80211.cfg | 5 +++++
.../kernel-cache/features/mac80211/mac80211.scc | 1 +
5 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 meta/cfg/kernel-cache/features/iwlagn/iwlagn.cfg
create mode 100644 meta/cfg/kernel-cache/features/iwlagn/iwlagn.scc
create mode 100644 meta/cfg/kernel-cache/features/mac80211/mac80211.cfg
create mode 100644 meta/cfg/kernel-cache/features/mac80211/mac80211.scc


Re: Supporting upcoming distribution releases

Richard Purdie
 

On Tue, 2011-07-12 at 12:01 -0700, Darren Hart wrote:

On 07/12/2011 11:51 AM, Joshua Lock wrote:
In our technical team call today we spent some time discussing how to
support distribution releases that are due to happen around the time of
Yocto 1.1.

Yocto 1.1 is scheduled for release on October 6th[1], the same month in
which both Ubuntu and Fedora have new releases planned[2,3].
OpenSUSE doesn't have a release scheduled until November 10th[4].

We should accommodate for these releases in our planning around 1.1 as
we need to ensure that Yocto 1.1 can be used on the new versions of the
chosen supported distros.

I had initially suggested we have people doing test and any relevant
development around the beta cycles of Ubuntu and Fedora:

Fedora Beta (2011-09-20)
Ubuntu (2011-09-01)
In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which
afaict (based on the 6th milestone being followed by an RC) should
roughly equate to a beta.

However this aligns with our RC period at which point we may not want to
accept large patches?

To meet our stabilise complete goal of August 29th we'd have to have
people testing with:
Fedora Alpha (2011-08-16)
Ubuntu Alpha 3 (2011-08-04)
OpenSUSE Milestone 4 (2011-08-11)

What are peoples thoughts on this?
At the very least a sanity test to know which sorts of issues we'll hit
with these would be valuable. However, I believe our policy is N-1, and
not N+1,N,N-1, so supporting not-yet released versions isn't something I
think we should spend too much time on. Minor fixes to support these
post release seem like good candidates for a point release.
Much as I'd like to agree with you, traditionally this does tend to bite
us hard. The fixes some of the releases have needed are sometimes not so
minor too :(.

The reason is that we have a community with a significant portion of
people who do stay close to the edge as far as distros go. They'll take
latest releases and expect Yocto to work on them even if the releases
come out at the same time. Its not often realised how far in advance
trees get frozen for stabilisation.

So summary is I'm in favour of trying to identify problems early and
then doing what we can to address them...

As such, this time around I'll update my build machine to latest Ubuntu
at the beginning of August....

Cheers,

Richard


Re: Supporting upcoming distribution releases

Darren Hart <dvhart@...>
 

On 07/12/2011 12:26 PM, Joshua Lock wrote:
On Tue, 2011-07-12 at 12:01 -0700, Darren Hart wrote:
Final note: I'm left wondering if this emails contents also make sense
as a wiki page?
Some sort of distro links for schedule page would be great. If people
want to share that they are testing the pre-release distros, that would
be useful, but we need to find a way to keep it concise and not into a
"getting it to work on XYZ" forum - although that would be useful a
separate page per distro.
Or perhaps we should just integrate this information into our schedule?
That is a great idea!

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: [PATCH 0/1]meta/routerstationpro: remove some conflicted configurations

Bruce Ashfield <bruce.ashfield@...>
 

On 07/12/11 16:18, Saul Wold wrote:
On 07/11/2011 05:22 PM, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

Some kernel options were redefined by routerstationpro.cfg and
it will cause some bugs. So remove some configurations which have
been defined in base.cfg or standard.cfg from routerstationpro.cfg.

Fix bug [YOCTO #1161]
Fix bug [YOCTO #773]
The Bug fix info needs to go into the commit message, not as part of the
email header as it will get lost here.
Not for the kernel, we explicitly don't want them in the kernel
tree. I'll make sure the appropriate bugs get updated in the tracker.

Bruce


Thanks
Sau!

Jingdong Lu (1):
meta/routerstationpro: remove some conflicted configurations

.../bsp/routerstationpro/routerstationpro.cfg | 45 --------------------
1 files changed, 0 insertions(+), 45 deletions(-)

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: [PATCH 0/1]meta/routerstationpro: remove some conflicted configurations

Saul Wold <sgw@...>
 

On 07/11/2011 05:22 PM, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

Some kernel options were redefined by routerstationpro.cfg and
it will cause some bugs. So remove some configurations which have
been defined in base.cfg or standard.cfg from routerstationpro.cfg.

Fix bug [YOCTO #1161]
Fix bug [YOCTO #773]
The Bug fix info needs to go into the commit message, not as part of the email header as it will get lost here.

Thanks
Sau!

Jingdong Lu (1):
meta/routerstationpro: remove some conflicted configurations

.../bsp/routerstationpro/routerstationpro.cfg | 45 --------------------
1 files changed, 0 insertions(+), 45 deletions(-)

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: Supporting upcoming distribution releases

Joshua Lock <josh@...>
 

On Tue, 2011-07-12 at 12:01 -0700, Darren Hart wrote:

On 07/12/2011 11:51 AM, Joshua Lock wrote:
In our technical team call today we spent some time discussing how to
support distribution releases that are due to happen around the time of
Yocto 1.1.

Yocto 1.1 is scheduled for release on October 6th[1], the same month in
which both Ubuntu and Fedora have new releases planned[2,3].
OpenSUSE doesn't have a release scheduled until November 10th[4].

We should accommodate for these releases in our planning around 1.1 as
we need to ensure that Yocto 1.1 can be used on the new versions of the
chosen supported distros.

I had initially suggested we have people doing test and any relevant
development around the beta cycles of Ubuntu and Fedora:

Fedora Beta (2011-09-20)
Ubuntu (2011-09-01)
In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which
afaict (based on the 6th milestone being followed by an RC) should
roughly equate to a beta.

However this aligns with our RC period at which point we may not want to
accept large patches?

To meet our stabilise complete goal of August 29th we'd have to have
people testing with:
Fedora Alpha (2011-08-16)
Ubuntu Alpha 3 (2011-08-04)
OpenSUSE Milestone 4 (2011-08-11)

What are peoples thoughts on this?
At the very least a sanity test to know which sorts of issues we'll hit
with these would be valuable. However, I believe our policy is N-1, and
not N+1,N,N-1, so supporting not-yet released versions isn't something I
think we should spend too much time on. Minor fixes to support these
post release seem like good candidates for a point release.
I understand what you're saying but I think the stance bears further
consideration because our release is so close to that of the
distributions and because so many of our target users will upgrade on
release day (or sooner) I think it's in the interest of the project to
be aware of the issues before release and ideally to have fixed as many
of any issues as possible.

I don't think it likely we will spin a point release in time to have
something that works on the distro launch day if we take the approach
you're advocating.

If people think this isn't a big deal I can live with that, but
experience suggests we will field support enquiries about these things
and therefore to my mind it seems prudent to accommodate for that.

I think the onus for this testing
will fall on engineers as the project QA is already pretty stretched. I
have a tendency to update to early releases on at least one machine so
will no doubt do some testing on Fedora but it would be nice to have a
genuine strategy for this rather than relying on ad-hoc developer
upgrades.

I personally do not upgrade my primary development machine to
pre-release distributions because I don't want those issues to derail me
from working on features. However, I could certainly kick off VMs
running whatever and set them building on one of our larger servers.
Absolutely. I'm not meaning to suggest all our developers should run
unstable OS's.

Aside; the schedule has feature development long complete by this
point ;-)



Final note: I'm left wondering if this emails contents also make sense
as a wiki page?
Some sort of distro links for schedule page would be great. If people
want to share that they are testing the pre-release distros, that would
be useful, but we need to find a way to keep it concise and not into a
"getting it to work on XYZ" forum - although that would be useful a
separate page per distro.
Or perhaps we should just integrate this information into our schedule?

Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre


Minutes: Yocto Technical Team (Tuesday, July 12, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))

Liu, Song <song.liu@...>
 

Attendees:
 
Dave, Paul, Darren, Jeff, Dirk, Richard, Josh, Tom, Koen, Saul, Mark, Denys, Jason, Beth, Song
 
Action item list:
* Team: please take a look at the proposed post 1.1 items (yellow in the M3 table, this is a draft, may change) on the wiki page and let Song know if there is any comment or concerns.
* Saul: talk to Jianjun, QA should work with developers to make sure we can cover more distro testing (informal) before major release. Joshua and Darren volunteers for some of these testing.
* Song: check status with Jianjun on Stabilization tasks he owned.
* Darren/Song: define specific deliverables of 'Fast boot time' for M3 and Yocto 1.1.
* Saul: circulate the idea of having a Sprint B for M3 via emails.
* Saul: check update commits (one release criteria)
 
Minutes:
 
* opens - 5 min 
- Darren: documentation process for release, making sure we can update the README.hardware after release if needed. (no time for this one this time, will put this on next week's agenda)
 
* Review Yocto 1.1 M2 schedule (Sprint and Stabilize tasks) and Release Criteria - 15 min (Song) See details at: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria
- All M2 items are already done.
- One M2 stabilization item is done, 3 in progress
- QA does not have resource for N+1 distro testing for every milestone release. But will do that for 1.1 release.
- Kernel version lock: Linux 3.0 should be released by next week. Yocto 1.1 target is 3.0+, lock in Linux 3.0 now (minimum). Will decide on 3.1 on Aug 15, the beginning of M4.
- All M2 high bugs now are committed to make M2.
- There are new bugs from the most recent QA test. Saul will follow up with the team.
 
* Review M3 feature list, M3 Sprint B? -20 min (Song)
- Sync qemugl with MeeGo - Implementation: was on the drop list, Edwin feels that he may be able to work on this if BSP work progresses well. We should be clear that BSP development work takes higher priority, if this one does not make 1.1, it is fine. Will keep this one on drop list.
- 'BSP update/intro': it should be fine without this for Yocto 1.1. Will work on this post 1.1.
- Fast boot time: it goes hand in hand with image side reduction. Darren will define the specifics for M3/1.1 deliverables.

* Discussion of using Weighted Defect density as one of the release criteria
- No time at this meeting for this one, will put it on next week's agenda.

* Action Item Review - 5 min (Song)
1. Song: update Google calendar with the new bridge info (done)
2. Darren: open a new bug to track a BBXM related issue (done)
3. Bruce: Split bug 414 into multiple ones to work and track separately (done, bug 1204, also added feature "replace qemuppc' for post 1.1)
4. Song: send Dexuan note about bug 1099.(done, 1099 is fixed)


Re: Supporting upcoming distribution releases

Darren Hart <dvhart@...>
 

On 07/12/2011 11:51 AM, Joshua Lock wrote:
In our technical team call today we spent some time discussing how to
support distribution releases that are due to happen around the time of
Yocto 1.1.

Yocto 1.1 is scheduled for release on October 6th[1], the same month in
which both Ubuntu and Fedora have new releases planned[2,3].
OpenSUSE doesn't have a release scheduled until November 10th[4].

We should accommodate for these releases in our planning around 1.1 as
we need to ensure that Yocto 1.1 can be used on the new versions of the
chosen supported distros.

I had initially suggested we have people doing test and any relevant
development around the beta cycles of Ubuntu and Fedora:

Fedora Beta (2011-09-20)
Ubuntu (2011-09-01)
In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which
afaict (based on the 6th milestone being followed by an RC) should
roughly equate to a beta.

However this aligns with our RC period at which point we may not want to
accept large patches?

To meet our stabilise complete goal of August 29th we'd have to have
people testing with:
Fedora Alpha (2011-08-16)
Ubuntu Alpha 3 (2011-08-04)
OpenSUSE Milestone 4 (2011-08-11)

What are peoples thoughts on this?
At the very least a sanity test to know which sorts of issues we'll hit
with these would be valuable. However, I believe our policy is N-1, and
not N+1,N,N-1, so supporting not-yet released versions isn't something I
think we should spend too much time on. Minor fixes to support these
post release seem like good candidates for a point release.

I think the onus for this testing
will fall on engineers as the project QA is already pretty stretched. I
have a tendency to update to early releases on at least one machine so
will no doubt do some testing on Fedora but it would be nice to have a
genuine strategy for this rather than relying on ad-hoc developer
upgrades.

I personally do not upgrade my primary development machine to
pre-release distributions because I don't want those issues to derail me
from working on features. However, I could certainly kick off VMs
running whatever and set them building on one of our larger servers.


Final note: I'm left wondering if this emails contents also make sense
as a wiki page?
Some sort of distro links for schedule page would be great. If people
want to share that they are testing the pre-release distros, that would
be useful, but we need to find a way to keep it concise and not into a
"getting it to work on XYZ" forum - although that would be useful a
separate page per distro.


Cheers,
Joshua

1. https://wiki.pokylinux.org/wiki/Yocto_1.1_Schedule
2. https://wiki.ubuntu.com/OneiricReleaseSchedule
3. http://fedoraproject.org/wiki/Releases/16/Schedule
4. http://en.opensuse.org/Roadmap
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Supporting upcoming distribution releases

Joshua Lock <josh@...>
 

In our technical team call today we spent some time discussing how to
support distribution releases that are due to happen around the time of
Yocto 1.1.

Yocto 1.1 is scheduled for release on October 6th[1], the same month in
which both Ubuntu and Fedora have new releases planned[2,3].
OpenSUSE doesn't have a release scheduled until November 10th[4].

We should accommodate for these releases in our planning around 1.1 as
we need to ensure that Yocto 1.1 can be used on the new versions of the
chosen supported distros.

I had initially suggested we have people doing test and any relevant
development around the beta cycles of Ubuntu and Fedora:

Fedora Beta (2011-09-20)
Ubuntu (2011-09-01)
In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which
afaict (based on the 6th milestone being followed by an RC) should
roughly equate to a beta.

However this aligns with our RC period at which point we may not want to
accept large patches?

To meet our stabilise complete goal of August 29th we'd have to have
people testing with:
Fedora Alpha (2011-08-16)
Ubuntu Alpha 3 (2011-08-04)
OpenSUSE Milestone 4 (2011-08-11)

What are peoples thoughts on this? I think the onus for this testing
will fall on engineers as the project QA is already pretty stretched. I
have a tendency to update to early releases on at least one machine so
will no doubt do some testing on Fedora but it would be nice to have a
genuine strategy for this rather than relying on ad-hoc developer
upgrades.

Final note: I'm left wondering if this emails contents also make sense
as a wiki page?

Cheers,
Joshua

1. https://wiki.pokylinux.org/wiki/Yocto_1.1_Schedule
2. https://wiki.ubuntu.com/OneiricReleaseSchedule
3. http://fedoraproject.org/wiki/Releases/16/Schedule
4. http://en.opensuse.org/Roadmap
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre


[PATCH] DOCS: Rename "poky-init-build-env" to "oe-init-build-env"

Robert P. J. Day
 

Adjust a couple doc files to reflect that the older
poky-init-build-env command has been renamed to oe-init-build-env.

Signed-off-by: Robert P. J. Day <rpjday@...>

---

diff --git a/documentation/adt-manual/adt-prepare.xml b/documentation/adt-manual/adt-prepare.xml
index 7fbc876..e6f5c9b 100644
--- a/documentation/adt-manual/adt-prepare.xml
+++ b/documentation/adt-manual/adt-prepare.xml
@@ -29,13 +29,13 @@
This term refers to the area where you run your builds.
The area is created when you source the Yocto Project setup environment script
that is found in the Yocto Project source directory
- (e.g. <filename>poky-init-build-env</filename>).
+ (e.g. <filename>oe-init-build-env</filename>).
You can create the Yocto Project build tree anywhere you want on your
development system.
Here is an example that creates the tree in <filename>mybuilds</filename>
and names the Yocto Project build directory <filename>YP-5.0.1</filename>:
<literallayout class='monospaced'>
- $ source poky-bernard-5.0.1/poky-init-build-env $HOME/mybuilds/YP-5.0.1
+ $ source poky-bernard-5.0.1/oe-init-build-env $HOME/mybuilds/YP-5.0.1
</literallayout>
If you don't specifically name the build directory then Bitbake creates it
in the current directory and uses the name <filename>build</filename>.
@@ -110,7 +110,7 @@
$ cd yocto-project
$ wget http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2
$ tar xjf poky-bernard-5.0.1.tar.bz2
- $ source poky-bernard-5.0.1/poky-init-build-env poky-5.0.1-build
+ $ source poky-bernard-5.0.1/oe-init-build-env poky-5.0.1-build
$ bitbake adt-installer
</literallayout>
</para>
diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml
index 52f7391..500444f 100644
--- a/documentation/yocto-project-qs/yocto-project-qs.xml
+++ b/documentation/yocto-project-qs/yocto-project-qs.xml
@@ -296,7 +296,7 @@
<literallayout class='monospaced'>
$ wget http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2
$ tar xjf poky-bernard-5.0.1.tar.bz2
- $ source poky-bernard-5.0.1/poky-init-build-env poky-5.0.1-build
+ $ source poky-bernard-5.0.1/oe-init-build-env poky-5.0.1-build
</literallayout>
</para>


--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: should dev docs replace "poky-init-build-env" with "oe-init-build-env"?

Richard Purdie
 

On Tue, 2011-07-12 at 07:17 -0400, Robert P. J. Day wrote:
poking around my git clone and i notice a few references to what
*seems* to be the older script for init'ing the build environment in
the documentation directory:

$ grep -rw poky-init-build-env *
adt-manual/adt-prepare.xml: (e.g. <filename>poky-init-build-env</filename>).
adt-manual/adt-prepare.xml: $ source poky-bernard-5.0.1/poky-init-build-env $HOME/mybuilds/YP-5.0.1
... and a couple more ...
$

as i read it, the correct name should be oe-init-build-env, no? is
someone already lined up to fix that? if not, i can submit a patch.
It did get renamed as you describe, yes. I don't think anyone has a
patch so I'd gladly take one, thanks!

Richard


should dev docs replace "poky-init-build-env" with "oe-init-build-env"?

Robert P. J. Day
 

poking around my git clone and i notice a few references to what
*seems* to be the older script for init'ing the build environment in
the documentation directory:

$ grep -rw poky-init-build-env *
adt-manual/adt-prepare.xml: (e.g. <filename>poky-init-build-env</filename>).
adt-manual/adt-prepare.xml: $ source poky-bernard-5.0.1/poky-init-build-env $HOME/mybuilds/YP-5.0.1
... and a couple more ...
$

as i read it, the correct name should be oe-init-build-env, no? is
someone already lined up to fix that? if not, i can submit a patch.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: Menu configuration

Richard Purdie
 

On Mon, 2011-07-11 at 10:00 -0700, Turner Randy wrote:
Hello list,

Is there a interactive menu-based configuration for yocto/poky builds
similar to that provided in Buildroot? Or is someone working on this?
At present there is not any interactive menu based configuration but
there is work ongoing on a UI called hob which allows you to select
packages and construct images of those packages so its a graphical front
end to the system.

We're also in the process of starting to better markup configuration
variables in the metadata so that writing some kind of menu based
configuration system would be easier in the future.

We're certainly open to any help in those areas too!

Cheers,

Richard


Re: [PATCH][poky-extras] meta-kernel-dev: allow for dangling bbappend files

Bruce Ashfield <bruce.ashfield@...>
 

On 11-07-11 10:49 PM, Darren Hart wrote:
With the bitbake commit:
7a2a24de094ce8f2e2068bbee6709dfc2cdc69b9
missing base recipe files for bbappends became an error. Rather than creating a
separate kernel development layer for every layer containing a new kernel recipe
name, conditionally set BB_DANGLINGAPPENDS_WARNONLY.

Signed-off-by: Darren Hart<dvhart@...>
CC: Bruce Ashfield<bruce.ashfield@...>

Agreed. This is the right solution.

Acked-by: Bruce Ashfield <bruce.ashfield@...>

CC: Jeff Mitchell<jmitchell@...>
---
meta-kernel-dev/conf/layer.conf | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/meta-kernel-dev/conf/layer.conf b/meta-kernel-dev/conf/layer.conf
index 33f1ca5..01e5b15 100644
--- a/meta-kernel-dev/conf/layer.conf
+++ b/meta-kernel-dev/conf/layer.conf
@@ -1,3 +1,7 @@
+# Avoid having to split this into multiple layers
+# Allow missing base recipe files for our bbappends
+BB_DANGLINGAPPENDS_WARNONLY ?= "true"
+
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"


PACKAGES_DYNAMIC handling in multilib

Xu, Dongxiao <dongxiao.xu@...>
 

Hi Richard,

Recently I am doing some work related with multilib.

In current code logic, I see packages that defined in "PACKAGES" variable will be automatically tagged with libxx-PN.

However there seems no logic to handle the PACKAGES_DYNAMIC case. Is it missed?

Besides, there is runtime package split code, for example in perl recipe, there are perl-module-* packages split by the following code.

python populate_packages_prepend () {
libdir = bb.data.expand('${libdir}/perl/${PV}', d)
do_split_packages(d, libdir, 'auto/(Encode/.[^/]*)/.*', 'perl-module-%s', 'perl module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
do_split_packages(d, libdir, 'auto/([^/]*)/.*', 'perl-module-%s', 'perl module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
do_split_packages(d, libdir, 'Module/([^\/]*).*', 'perl-module-%s', 'perl module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
do_split_packages(d, libdir, '(^(?!(CPAN\/|CPANPLUS\/|Module\/|unicore\/|auto\/)[^\/]).*)\.(pm|pl|e2x)', 'perl-module-%s', 'perl module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
}

To support lib32-perl/lib64-perl and other similar recipes, I think we may have to specifically handle such pieces of code in current poky.

Do you have suggestions on the above?

Thanks,
Dongxiao


[PATCH][poky-extras] meta-kernel-dev: allow for dangling bbappend files

Darren Hart <dvhart@...>
 

With the bitbake commit:
7a2a24de094ce8f2e2068bbee6709dfc2cdc69b9
missing base recipe files for bbappends became an error. Rather than creating a
separate kernel development layer for every layer containing a new kernel recipe
name, conditionally set BB_DANGLINGAPPENDS_WARNONLY.

Signed-off-by: Darren Hart <dvhart@...>
CC: Bruce Ashfield <bruce.ashfield@...>
CC: Jeff Mitchell <jmitchell@...>
---
meta-kernel-dev/conf/layer.conf | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/meta-kernel-dev/conf/layer.conf b/meta-kernel-dev/conf/layer.conf
index 33f1ca5..01e5b15 100644
--- a/meta-kernel-dev/conf/layer.conf
+++ b/meta-kernel-dev/conf/layer.conf
@@ -1,3 +1,7 @@
+# Avoid having to split this into multiple layers
+# Allow missing base recipe files for our bbappends
+BB_DANGLINGAPPENDS_WARNONLY ?= "true"
+
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"

--
1.7.1
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


[PATCH 1/1] meta/routerstationpro: remove some conflicted configurations

Jingdong Lu <jingdong.lu@...>
 

From: Jingdong Lu <jingdong.lu@...>

Some kernel options were redefined by routerstationpro.cfg and
it will cause some bugs. So remove some configurations which have
been defined in base.cfg or standard.cfg from routerstationpro.cfg.
1) Gerneral setup:
remove CONFIG_EXPERIMENTAL, CONFIG_SYSVIPC, CONFIG_POSIX_MQUEUE
2) Native Language Support:
remove all related options

Signed-off-by: Jingdong Lu <jingdong.lu@...>
---
.../bsp/routerstationpro/routerstationpro.cfg | 45 --------------------
1 files changed, 0 insertions(+), 45 deletions(-)

diff --git a/meta/cfg/kernel-cache/bsp/routerstationpro/routerstationpro.cfg b/meta/cfg/kernel-cache/bsp/routerstationpro/routerstationpro.cfg
index f58dfe8..1ac2c31 100644
--- a/meta/cfg/kernel-cache/bsp/routerstationpro/routerstationpro.cfg
+++ b/meta/cfg/kernel-cache/bsp/routerstationpro/routerstationpro.cfg
@@ -209,14 +209,11 @@ CONFIG_CONSTRUCTORS=y
#
# General setup
#
-# CONFIG_EXPERIMENTAL is not set
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
-# CONFIG_SYSVIPC is not set
-# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set

@@ -1461,48 +1458,6 @@ CONFIG_SUNRPC=y
#
# Partition Types
#
-# CONFIG_PARTITION_ADVANCED is not set
-CONFIG_MSDOS_PARTITION=y
-CONFIG_NLS=y
-CONFIG_NLS_DEFAULT="iso8859-1"
-CONFIG_NLS_CODEPAGE_437=y
-# CONFIG_NLS_CODEPAGE_737 is not set
-# CONFIG_NLS_CODEPAGE_775 is not set
-# CONFIG_NLS_CODEPAGE_850 is not set
-# CONFIG_NLS_CODEPAGE_852 is not set
-# CONFIG_NLS_CODEPAGE_855 is not set
-# CONFIG_NLS_CODEPAGE_857 is not set
-# CONFIG_NLS_CODEPAGE_860 is not set
-# CONFIG_NLS_CODEPAGE_861 is not set
-# CONFIG_NLS_CODEPAGE_862 is not set
-# CONFIG_NLS_CODEPAGE_863 is not set
-# CONFIG_NLS_CODEPAGE_864 is not set
-# CONFIG_NLS_CODEPAGE_865 is not set
-# CONFIG_NLS_CODEPAGE_866 is not set
-# CONFIG_NLS_CODEPAGE_869 is not set
-# CONFIG_NLS_CODEPAGE_936 is not set
-# CONFIG_NLS_CODEPAGE_950 is not set
-# CONFIG_NLS_CODEPAGE_932 is not set
-# CONFIG_NLS_CODEPAGE_949 is not set
-# CONFIG_NLS_CODEPAGE_874 is not set
-# CONFIG_NLS_ISO8859_8 is not set
-# CONFIG_NLS_CODEPAGE_1250 is not set
-# CONFIG_NLS_CODEPAGE_1251 is not set
-# CONFIG_NLS_ASCII is not set
-# CONFIG_NLS_ISO8859_1 is not set
-# CONFIG_NLS_ISO8859_2 is not set
-# CONFIG_NLS_ISO8859_3 is not set
-# CONFIG_NLS_ISO8859_4 is not set
-# CONFIG_NLS_ISO8859_5 is not set
-# CONFIG_NLS_ISO8859_6 is not set
-# CONFIG_NLS_ISO8859_7 is not set
-# CONFIG_NLS_ISO8859_9 is not set
-# CONFIG_NLS_ISO8859_13 is not set
-# CONFIG_NLS_ISO8859_14 is not set
-# CONFIG_NLS_ISO8859_15 is not set
-# CONFIG_NLS_KOI8_R is not set
-# CONFIG_NLS_KOI8_U is not set
-CONFIG_NLS_UTF8=y

#
# Kernel hacking
--
1.7.0.4