Re: [yocto] Menu configuration
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] should dev docs replace "poky-init-build-env" with "oe-init-build-env"?
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. poky-init-build-env). 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] should dev docs replace "poky-init-build-env" with "oe-init-build-env"?
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. > poky-init-build-env). > 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] DOCS: Rename "poky-init-build-env" to "oe-init-build-env"
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 --- 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. poky-init-build-env). +(e.g. oe-init-build-env). You can create the Yocto Project build tree anywhere you want on your development system. Here is an example that creates the tree in mybuilds and names the Yocto Project build directory YP-5.0.1: - $ 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 If you don't specifically name the build directory then Bitbake creates it in the current directory and uses the name build. @@ -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 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 @@ $ 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 -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Supporting upcoming distribution releases
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1]meta/routerstationpro: remove some conflicted configurations
On 07/11/2011 05:22 PM, Jingdong Lu wrote: From: 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@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1]meta/routerstationpro: remove some conflicted configurations
On 07/12/11 16:18, Saul Wold wrote: On 07/11/2011 05:22 PM, Jingdong Lu wrote: From: 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@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
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@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2][KERNEL] meta: add mac80211 and iwlagn features
From: 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 --- 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 000..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 000..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 000..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 000..c2c02c8 --- /dev/null +++ b/meta/cfg/kernel-cache/features/mac80211/mac80211.scc @@ -0,0 +1 @@ +kconf hardware mac80211.cfg -- 1.7.0.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2][KERNEL] meta-fri2: use iwlagn feature
From: Tom Zanussi Make use of the Intel wireless support for the Intel 6205 ABGN. Signed-off-by: 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-e1/intel-e1.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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2][KERNEL] Add and use iwlagn and mac80211 features
From: 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
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@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
On Wed, 2011-07-13 at 09:15 +0800, NiQingliang wrote: > 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 I looked at this but not enough of the distributions we care to support have a python2.6 binary: joshual@scimitar:~ $ /usr/bin/env python2 Python 2.7.1 (r271:86832, Apr 12 2011, 16:16:18) [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> joshual@scimitar:~ $ /usr/bin/env python2.6 /usr/bin/env: python2.6: No such file or directory I'd love to support Arch more thoroughly but they aren't making it easy for us ;-) Cheers, Joshua -- Joshua Lock Yocto Project "Johannes factotum" Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
/usr/bin/env python2 /usr/bin/env python2.7 both of them are ok for archlinux, but I don't know which is ok for other distributions, maybe both are not. maybe we can make a shell script to detect the python version, and make a symbollink to the right one in some directory, and add the directory into env var "PATH". On Wed, 2011-07-13 at 10:08 +0800, Joshua Lock wrote: > On Wed, 2011-07-13 at 09:15 +0800, NiQingliang wrote: > > 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 > > I looked at this but not enough of the distributions we care to support > have a python2.6 binary: > > joshual@scimitar:~ > $ /usr/bin/env python2 > Python 2.7.1 (r271:86832, Apr 12 2011, 16:16:18) > [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> > joshual@scimitar:~ > $ /usr/bin/env python2.6 > /usr/bin/env: python2.6: No such file or directory > > I'd love to support Arch more thoroughly but they aren't making it easy > for us ;-) > > Cheers, > Joshua > -- > Joshua Lock > Yocto Project "Johannes factotum" > Intel Open Source Technology Centre > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote: > /usr/bin/env python2 > /usr/bin/env python2.7 These are both valid on Fedora 15, iirc before distributions started shipping Python 3 they were less common though... > both of them are ok for archlinux, but I don't know which is ok for > other distributions, maybe both are not. > > maybe we can make a shell script to detect the python version, and make > a symbollink to the right one in some directory, and add the directory > into env var "PATH". Patches welcome :-) I looked at it briefly and the work would require more time than I have spare right now just to ensure it worked on all required distributions. If you'd like to work on a patch I'd be happy to help test and review. Cheers, Joshua -- Joshua Lock Yocto Project "Johannes factotum" Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] Enable network sanity checks
Add some CONNECTIVITY_CHECK_URIS to local.conf.sample such that the network sanity checks are enabled for http, https and git sources. The following changes since commit 7354fc9213f27aa1b643dbe88070437f1ee4c063: insane.bbclass: skip rdepends QA checks for kernel / modules (2011-07-12 15:22:09 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib josh/sanity http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=josh/sanity Joshua Lock (1): local.conf.sample: add CONNECTIVITY_CHECK_URIS meta-yocto/conf/local.conf.sample |8 1 files changed, 8 insertions(+), 0 deletions(-) -- 1.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] local.conf.sample: add CONNECTIVITY_CHECK_URIS
Add CONNECTIVITY_CHECK_URIS to run the network connectivity sanity test for http, https and git sources. Signed-off-by: Joshua Lock --- meta-yocto/conf/local.conf.sample |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/meta-yocto/conf/local.conf.sample b/meta-yocto/conf/local.conf.sample index ea32b81..fb20f2c 100644 --- a/meta-yocto/conf/local.conf.sample +++ b/meta-yocto/conf/local.conf.sample @@ -214,3 +214,11 @@ NO32LIBS = "1" # The network based PR service host and port #PRSERV_HOST = "localhost" #PRSERV_PORT = "8585" + +# Use the following URI's to test whether we can succesfully fetch from the +# network (and warn you if not). This test will be run each time a new build +# directory is specfied, if you wish to disable it delete or comment out the +# following few lines that define CONNECTIVITY_CHECK_URIS. +CONNECTIVITY_CHECK_URIS = "git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=HEAD \ + https://eula-downloads.yoctoproject.org/index.php \ + http://bugzilla.yoctoproject.org/report.cgi"; -- 1.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
OK, I will do it.:) On Wed, 2011-07-13 at 10:31 +0800, Joshua Lock wrote: > On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote: > > /usr/bin/env python2 > > /usr/bin/env python2.7 > > These are both valid on Fedora 15, iirc before distributions started > shipping Python 3 they were less common though... > > > both of them are ok for archlinux, but I don't know which is ok for > > other distributions, maybe both are not. > > > > maybe we can make a shell script to detect the python version, and make > > a symbollink to the right one in some directory, and add the directory > > into env var "PATH". > > Patches welcome :-) > > I looked at it briefly and the work would require more time than I have > spare right now just to ensure it worked on all required distributions. > > If you'd like to work on a patch I'd be happy to help test and review. > > Cheers, > Joshua > -- > Joshua Lock > Yocto Project "Johannes factotum" > Intel Open Source Technology Centre > -- 倪庆亮 TEL:13588371863 E-MAIL: niqingli...@insigma.com.cn BLOG: http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/3][KERNEL] linux-yocto-dev meta updates
On 11-07-10 12:25 PM, tom.zanu...@intel.com wrote: From: Tom Zanussi This patchset adds a new eg20t feature to linux-yocto-dev, and makes crownbay use it. It also adds the initial BSP infrastructure for a new BSP, Fish River Island II, which also uses the new feature. Please pull the following branches into linux-yocto-dev: Pull URL: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib Branch: tzanussi/linux-3.0/yocto/standard/fri2 Browse: http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/linux-3.0/yocto/standard/fri2 Pull URL: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib Branch: tzanussi/linux-3.0/meta/fri2 Browse: http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/linux-3.0/meta/fri2 Everything has been merged to the dev kernel (along with an update to 3.0-rc7), and the new BSP branch created. Take it for a spin and lets see how it does. Cheers, Bruce Tom Zanussi (3): meta: add eg20t feature meta/crownbay: remove eg20t.cfg and use new eg20t feature instead meta/fri2: create initial BSP infrastructure meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc |2 +- meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc |7 ++ meta/cfg/kernel-cache/bsp/fri2/fri2.cfg | 69 ++ meta/cfg/kernel-cache/bsp/fri2/fri2.scc | 12 meta/cfg/kernel-cache/features/eg20t/eg20t.cfg | 39 meta/cfg/kernel-cache/features/eg20t/eg20t.scc |1 + 6 files changed, 129 insertions(+), 1 deletions(-) create mode 100644 meta/cfg/kernel-cache/bsp/fri2/fri2-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/fri2/fri2.cfg create mode 100644 meta/cfg/kernel-cache/bsp/fri2/fri2.scc create mode 100644 meta/cfg/kernel-cache/features/eg20t/eg20t.cfg create mode 100644 meta/cfg/kernel-cache/features/eg20t/eg20t.scc ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/2][KERNEL] Add and use iwlagn and mac80211 features
On 11-07-12 7:25 PM, tom.zanu...@intel.com wrote: From: 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 And these are pushed out as well. Bruce 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
> 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) > Thanks for the information, Josh. I will add these into our test plan to make sure the above distribution(N+1) is validated. > 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 Best Regards, Jiajun ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
