Re: [yocto] Build error while following Appendix A. Yocto Project Development manual
just to clarify any overlooked issues ...
On Tue, 1 Nov 2011, Tom Zanussi wrote:
... I captured the steps I used below, which should work in the same
way for you.
trz@elmorro:/usr/local/dev/yocto$ mkdir bsp-test; cd bsp-test
trz@elmorro:/usr/local/dev/yocto/bsp-test$ git clone
git://git.yoctoproject.org/poky
trz@elmorro:/usr/local/dev/yocto/bsp-test$ cd poky
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git checkout -b edison
origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git clone
git://git.yoctoproject.org/meta-intel.git
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ cd meta-intel
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ git checkout -b
edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cp -a
meta-crownbay/ meta-mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm
meta-mymachine/conf/machine/crownbay.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv
meta-mymachine/conf/machine/crownbay-noemgd.conf
meta-mymachine/conf/machine/mymachine.conf
should one still change the NAME or DESCRIPTION comments in that new
mymachine.conf file to reflect mymachine as the dev-manual suggests,
or can one just leave them referring to crownbay? recall that the
current dev-manual claims that you need to make those changes. if
you don't, that claim should be softened.
also, there's no mention of editing layer.conf to reflect
mymachine as directed in dev-manual:
BBFILE_COLLECTIONS += mymachine
should that not be done? again, the current dev-manual states that
that change is needed.
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf
meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay/
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv
meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd
meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf
meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
don't you also have to rename crownbay-noemgd/ to mymachine/
under that recipes-graphics/ directory as well, as the dev-manual
directs? you don't mention that here. you also don't mention making
editing changes to recipes-core/tasks/task-core-tools.bbappend as
dev-manual suggests. not necessary?
Here's the resulting linux-yocto_3.0.bbappend:
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cat
meta-mymachine/recipes-kernel/linux/linux-yocto_3.0.bbappend
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_mymachine = mymachine
KMACHINE_mymachine = yocto/standard/common-pc/atom-pc
KERNEL_FEATURES_append_mymachine += cfg/smp.scc
SRCREV_machine_pn-linux-yocto_mymachine ?=
1e18e44adbe79b846e382370eb29bc4b8cd5a1a0
SRCREV_meta_pn-linux-yocto_mymachine ?=
d05450e4aef02c1b7137398ab3a9f8f96da74f52
ok, just took that verbatim.
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ source oe-init-build-env
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ bitbake core-image-sato
NOTE: Tasks Summary: Attempted 4426 tasks of which 247 didn't need to be
rerun and 0 failed.
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/build
other than sourcing from one directory level up and making the
appropriate changes in conf/local.conf to refer to mymachine, no
difference here. just started the build ...
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
[yocto] [PATCH] oprofileui: allow build of server without X libs
Fix the configure script to allow oprofile-server to be built standalone (without needing GTK+ and other X-requiring libraries) Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- configure.ac | 15 +++ 1 files changed, 11 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index d49952e..2a7010b 100644 --- a/configure.ac +++ b/configure.ac @@ -29,9 +29,11 @@ AC_ARG_ENABLE(client, AM_CONDITIONAL(ENABLE_SERVER, test x$enable_server = xyes) AM_CONDITIONAL(ENABLE_CLIENT, test x$enable_client = xyes) -PKG_CHECK_MODULES(OPROFILEUI, [glib-2.0 libglade-2.0 gtk+-2.0 libxml-2.0 gconf-2.0]) -AC_SUBST(OPROFILEUI_CFLAGS) -AC_SUBST(OPROFILEUI_LIBS) +AS_IF([test x$enable_client = xyes], [ +PKG_CHECK_MODULES(OPROFILEUI, [glib-2.0 libglade-2.0 gtk+-2.0 libxml-2.0 gconf-2.0]) +AC_SUBST(OPROFILEUI_CFLAGS) +AC_SUBST(OPROFILEUI_LIBS) +]) PKG_CHECK_MODULES(OPROFILE_SERVER, [glib-2.0]) AC_SUBST(OPROFILE_SERVER_CFLAGS) @@ -41,7 +43,12 @@ AC_ARG_WITH(avahi, [AC_HELP_STRING([--with-avahi], [Use Avahi to announce and search for OProfile servers])], with_avahi=$withval, with_avahi=no) if test $with_avahi = yes; then -PKG_CHECK_MODULES(AVAHI, [avahi-client avahi-glib avahi-ui]) +AS_IF([test x$enable_client = xyes], [ +PKG_CHECK_MODULES(AVAHI, [avahi-client avahi-glib avahi-ui]) +],[ +PKG_CHECK_MODULES(AVAHI, [avahi-client avahi-glib]) +]) + AC_DEFINE_UNQUOTED(WITH_AVAHI, [1], [Using Avahi]) fi AM_CONDITIONAL(WITH_AVAHI, test x$with_avahi = xyes) -- 1.7.5.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build error while following Appendix A. Yocto Project Development manual
On Wed, 2011-11-02 at 05:19 -0700, Robert P. J. Day wrote:
just to clarify any overlooked issues ...
On Tue, 1 Nov 2011, Tom Zanussi wrote:
... I captured the steps I used below, which should work in the same
way for you.
trz@elmorro:/usr/local/dev/yocto$ mkdir bsp-test; cd bsp-test
trz@elmorro:/usr/local/dev/yocto/bsp-test$ git clone
git://git.yoctoproject.org/poky
trz@elmorro:/usr/local/dev/yocto/bsp-test$ cd poky
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git checkout -b edison
origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git clone
git://git.yoctoproject.org/meta-intel.git
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ cd meta-intel
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ git checkout -b
edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cp -a
meta-crownbay/ meta-mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm
meta-mymachine/conf/machine/crownbay.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv
meta-mymachine/conf/machine/crownbay-noemgd.conf
meta-mymachine/conf/machine/mymachine.conf
should one still change the NAME or DESCRIPTION comments in that new
mymachine.conf file to reflect mymachine as the dev-manual suggests,
or can one just leave them referring to crownbay? recall that the
current dev-manual claims that you need to make those changes. if
you don't, that claim should be softened.
Right, not strictly needed, only for consistency, so the language should
be softened, I agree.
also, there's no mention of editing layer.conf to reflect
mymachine as directed in dev-manual:
BBFILE_COLLECTIONS += mymachine
should that not be done? again, the current dev-manual states that
that change is needed.
That is needed, but the steps that required editing files aren't easily
captured in a transcript, so I didn't capture those, but they are still
required. I should have added a do editing step xxx from the doc here
to make that clear, though I did mention that other than the
kernel .bbappend, the steps I went through were pretty much as
described. Anyway, hopefully we can get the changes from this thread in
the doc and it will then all fit together.
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf
meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay/
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv
meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd
meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf
meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
don't you also have to rename crownbay-noemgd/ to mymachine/
under that recipes-graphics/ directory as well, as the dev-manual
directs? you don't mention that here. you also don't mention making
Right, I missed that step. It still builds, though there would be
problems with X at runtime due to this.
editing changes to recipes-core/tasks/task-core-tools.bbappend as
dev-manual suggests. not necessary?
Yes, necessary, again, I didn't add the notes about editing.
Tom
Here's the resulting linux-yocto_3.0.bbappend:
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cat
meta-mymachine/recipes-kernel/linux/linux-yocto_3.0.bbappend
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_mymachine = mymachine
KMACHINE_mymachine = yocto/standard/common-pc/atom-pc
KERNEL_FEATURES_append_mymachine += cfg/smp.scc
SRCREV_machine_pn-linux-yocto_mymachine ?=
1e18e44adbe79b846e382370eb29bc4b8cd5a1a0
SRCREV_meta_pn-linux-yocto_mymachine ?=
d05450e4aef02c1b7137398ab3a9f8f96da74f52
ok, just took that verbatim.
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ source oe-init-build-env
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ bitbake core-image-sato
NOTE: Tasks Summary: Attempted 4426 tasks of which 247 didn't need to be
rerun and 0 failed.
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/build
other than sourcing from one directory level up and making the
appropriate changes in conf/local.conf to refer to mymachine, no
difference here. just started the build ...
rday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build error while following Appendix A. Yocto Project Development manual
okay, what you mentioned as the steps below, I agree with, but a couple
I don't understand. first, in the linux-yocto_3.0.bbappend file, why is
the KMACHINE statement changed to common-pc/atom-pc? If I look st eh
section of the doc in A.5.2.4 talking about going to
cgit/cgit.cgi/linux-yocto-3.0 to get the latest commit strings, I see
that it agrees with the path in #2, but not sure why??
Second, I looked at your cat of the same file containing the SRCREV
commit strings and I don't see that they agree with the commits on the
website even just this morning. Can you explain that? Should I just use
the ones in your cat output or eventually the corrected Dev. Manual?
Jim A
On Tue, 2011-11-01 at 19:45 -0500, Tom Zanussi wrote:
Hi James,
I'm still not sure what happened in your case to cause this problem, but
I just went through the Appendix A example pretty much as described, and
got a good build out of it. There was one particular part of the
example that wasn't exactly clear and that could definitely cause some
build problems if you did it incorrectly (the section that makes changes
to linux-yocto_3.0.bbappend, which in the example has a custom branch in
the .bbappend file, but has the explanation using atom-pc).
I'll work with Scott to make sure that part gets cleaned up, along with
the other comments that should get pulled in, but in the meantime, I
captured the steps I used below, which should work in the same way for
you.
trz@elmorro:/usr/local/dev/yocto$ mkdir bsp-test; cd bsp-test
trz@elmorro:/usr/local/dev/yocto/bsp-test$ git clone
git://git.yoctoproject.org/poky
trz@elmorro:/usr/local/dev/yocto/bsp-test$ cd poky
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git checkout -b edison
origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git clone
git://git.yoctoproject.org/meta-intel.git
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ cd meta-intel
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ git checkout -b
edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cp -a
meta-crownbay/ meta-mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm
meta-mymachine/conf/machine/crownbay.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv
meta-mymachine/conf/machine/crownbay-noemgd.conf
meta-mymachine/conf/machine/mymachine.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf
meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay/
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv
meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd
meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf
meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
The Developer's Manual seems to want to base the BSP on atom-pc for
this example, so we need to specify the atom-pc branch and get the
SRCREVs for atom-pc or the step that modifies the
linux-yocto_3.0.bbappend. So in
meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend, we find both
the KMACHINE branch we need, and the SRCREV on that branch we need for
edison. Since that doesn't specify the meta branch, but the base
recipe does, we can look at the SRCREV_meta there
(meta/recipes-kernel/linux/linux-yocto_3.0.bb) for the SRCREV of the
meta branch, which already matches what we're using, so no change
needed there.
Here's the resulting linux-yocto_3.0.bbappend:
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cat
meta-mymachine/recipes-kernel/linux/linux-yocto_3.0.bbappend
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_mymachine = mymachine
KMACHINE_mymachine = yocto/standard/common-pc/atom-pc
KERNEL_FEATURES_append_mymachine += cfg/smp.scc
SRCREV_machine_pn-linux-yocto_mymachine ?=
1e18e44adbe79b846e382370eb29bc4b8cd5a1a0
SRCREV_meta_pn-linux-yocto_mymachine ?=
d05450e4aef02c1b7137398ab3a9f8f96da74f52
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ source oe-init-build-env
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ bitbake core-image-sato
NOTE: Tasks Summary: Attempted 4426 tasks of which 247 didn't need to be
rerun and 0 failed.
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/build
Tom
On Tue, 2011-11-01 at 12:48 -0700, James Abernathy wrote:
Just to clear up the basics, Prior to following Appendix A verbatim, I
did the following
1. install prerequisites from GS guide
2. git clone git://git.yoctoproject.org/poky
3. cd poky
4. git clone git://git.yoctoproject.org/meta-intel.git
I did not install the poky-extras. I assumed it only had to be
installed if you installed the kernel source for modification like in
Appendix b
Jim a
On Tue, Nov 1, 2011 at 3:40 PM, Tom Zanussi tom.zanu...@intel.com
wrote:
Hi,
On Tue, 2011-11-01 at 11:37
Re: [yocto] Build error while following Appendix A. Yocto Project Development manual
... all of tom's stuff snipped ... ok, based on combining everything in the last several posts, my build for core-image-sato for the new mymachine bsp just finished successfully on my 64-bit ubuntu 11.10 system. happy, happy, joy, joy. must write this all down somewhere. :-) 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] Build error while following Appendix A. Yocto Project Development manual
On Wed, 2011-11-02 at 07:24 -0700, Jim Abernathy wrote:
okay, what you mentioned as the steps below, I agree with, but a couple
I don't understand. first, in the linux-yocto_3.0.bbappend file, why is
the KMACHINE statement changed to common-pc/atom-pc? If I look st eh
section of the doc in A.5.2.4 talking about going to
cgit/cgit.cgi/linux-yocto-3.0 to get the latest commit strings, I see
that it agrees with the path in #2, but not sure why??
This is part of the confusion I mentioned about this section that needs
to be cleaned up. Basically, for this example, to keep things simple,
we want to use an already-existing branch in the repo. The branch that
was somewhat vaguely chosen for this example was the atom-pc branch. So
this should be the branch specified in the KMACHINE, which my
corrected .bbappend shows, rather than the yocto/standard/mymachine in
the example code.
The mention of cgit/cgit.cgi/linux-yocto-3.0 to get the latest commit
strings is correct assuming you're working from master. But this
example is working from edison, where there commits to use are
essentially set in stone and contained in the SRCREVs in the .bb
and .bbappends in the edison branch.
Again, this is part of the confusion in this section that needs cleaning
up.
Second, I looked at your cat of the same file containing the SRCREV
commit strings and I don't see that they agree with the commits on the
website even just this morning. Can you explain that? Should I just use
the ones in your cat output or eventually the corrected Dev. Manual?
I got these commits from the kernel .bb and .bbappends captured in the
edison branch, as mentioened above.
Tom
Jim A
On Tue, 2011-11-01 at 19:45 -0500, Tom Zanussi wrote:
Hi James,
I'm still not sure what happened in your case to cause this problem, but
I just went through the Appendix A example pretty much as described, and
got a good build out of it. There was one particular part of the
example that wasn't exactly clear and that could definitely cause some
build problems if you did it incorrectly (the section that makes changes
to linux-yocto_3.0.bbappend, which in the example has a custom branch in
the .bbappend file, but has the explanation using atom-pc).
I'll work with Scott to make sure that part gets cleaned up, along with
the other comments that should get pulled in, but in the meantime, I
captured the steps I used below, which should work in the same way for
you.
trz@elmorro:/usr/local/dev/yocto$ mkdir bsp-test; cd bsp-test
trz@elmorro:/usr/local/dev/yocto/bsp-test$ git clone
git://git.yoctoproject.org/poky
trz@elmorro:/usr/local/dev/yocto/bsp-test$ cd poky
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git checkout -b edison
origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git clone
git://git.yoctoproject.org/meta-intel.git
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ cd meta-intel
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ git checkout -b
edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cp -a
meta-crownbay/ meta-mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm
meta-mymachine/conf/machine/crownbay.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv
meta-mymachine/conf/machine/crownbay-noemgd.conf
meta-mymachine/conf/machine/mymachine.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf
meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay/
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv
meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd
meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf
meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
The Developer's Manual seems to want to base the BSP on atom-pc for
this example, so we need to specify the atom-pc branch and get the
SRCREVs for atom-pc or the step that modifies the
linux-yocto_3.0.bbappend. So in
meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend, we find both
the KMACHINE branch we need, and the SRCREV on that branch we need for
edison. Since that doesn't specify the meta branch, but the base
recipe does, we can look at the SRCREV_meta there
(meta/recipes-kernel/linux/linux-yocto_3.0.bb) for the SRCREV of the
meta branch, which already matches what we're using, so no change
needed there.
Here's the resulting linux-yocto_3.0.bbappend:
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cat
meta-mymachine/recipes-kernel/linux/linux-yocto_3.0.bbappend
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_mymachine = mymachine
KMACHINE_mymachine = yocto/standard/common-pc/atom-pc
KERNEL_FEATURES_append_mymachine += cfg/smp.scc
SRCREV_machine_pn-linux-yocto_mymachine ?=
Re: [yocto] Build error while following Appendix A. Yocto Project Development manual
On Wed, 2011-11-02 at 08:07 -0700, Jim Abernathy wrote: Second, I looked at your cat of the same file containing the SRCREV commit strings and I don't see that they agree with the commits on the website even just this morning. Can you explain that? Should I just use the ones in your cat output or eventually the corrected Dev. Manual? I got these commits from the kernel .bb and .bbappends captured in the edison branch, as mentioened above. That's a lot clearer now. So does this mean that If I'm working with edison branch, should I have to change the commits strings at all??? The commits in the doc should work - the SRCREV_machine is the last commit on the edison branch for yocto/standard/common-pc/atom-pc and the SRCREV_meta is also valid in edison, though in between the time the doc was written and the time meta-intel was released for edison, the meta SRCREV was bumped up to a later commit, which is the one I used in my 'cat'ed file. Either one should be fine. So no, you can directly use the SRCREVS in the manual and don't have to change those at all. Because the commit strings from your cat'ing of the your file don't agree with what is in my clone of the edison branch for poky or meta-intel. Or am I missing something else (likely). Those commit strings identify commits in the linux-yocto_3.0 repo (http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/). The specific commits used for edison are captured in the linux-yocto_3.0 .bb and .bbappend files mentioned previously. Tom Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-intel candidate branch for 1.1 edison point release
Hi, I've created a new meta-intel/edison-next branch to hold commits intended for the upcoming 1.1 point release. I'll be collecting candidate commits for a 1.1 point release there until it's time to cut the 1.1 point release, and will pull those into edison proper at that point, assuming we have agreement on the set of patches in the branch. Please let me know if you have any comments on this set or if you know of any missing patches that should be added. Thanks, Tom Here's the current set of commit descriptions for the commits in that branch: commit 59292a744ad1ea7875c0f2b7564c4ad74af2d68e Author: Tom Zanussi tom.zanu...@intel.com Date: Fri Oct 28 11:26:22 2011 -0500 meta-crownbay: allow linux-yocto-rt to be used for crownbay The crownbay linux-yocto-rt .bbappend is missing settings needed for use with crownbay - this adds them. Signed-off-by: Tom Zanussi tom.zanu...@intel.com commit 3d78b56773943803f46c09f69e908506fff95b04 Author: Tom Zanussi tom.zanu...@intel.com Date: Thu Oct 27 23:48:15 2011 -0500 meta-fri2: allow linux-yocto-rt to be used for fri2-noemgd The fri2 linux-yocto-rt .bbappend is missing settings needed for use with fri2-noemgd - this adds them. Signed-off-by: Tom Zanussi tom.zanu...@intel.com commit 9b901b4df24c88795e2a188e070249ef5273a8e9 Author: Tom Zanussi tom.zanu...@intel.com Date: Thu Oct 27 17:37:27 2011 -0500 meta-crownbay: add linux-yocto-rt_3.0.bbappend commit 061f3187e8cbec70d5970928b6e8252cb0958f4a (meta-intel: move emgd-driver-bin_1.8 to common) somehow mistakenly removed the unrelated linux-yocto-rt_3.0.bbappend from meta-crownbay. This adds it back. Signed-off-by: Tom Zanussi tom.zanu...@intel.com commit cc0a4df25eb1db45698574d781c13fd7ee2ddaa7 Author: Tom Zanussi tom.zanu...@intel.com Date: Thu Oct 20 17:03:13 2011 -0500 meta-fri2: README correction In the instructions for manually extracting the binaries from the EMGD Linux tarball, an additional step for removing the emgd_drv_video shared library is necessary; this adds it for fri2. Signed-off-by: Tom Zanussi tom.zanu...@intel.com commit b8f9910a39196bdbce37dea25f82538b144d72dd Author: Tom Zanussi tom.zanu...@intel.com Date: Thu Oct 20 17:01:39 2011 -0500 meta-crownbay: README correction In the instructions for manually extracting the binaries from the EMGD Linux tarball, an additional step for removing the emgd_drv_video shared library is necessary; this adds it for crownbay. Signed-off-by: Tom Zanussi tom.zanu...@intel.com The following changes since commit c3e12aa981e97261093abee05bb0301c35f54c23: Tom Zanussi (1): meta-emenlow: switch edison back to linux-yocto-2.6.37 kernel are available in the git repository at: git://git.yoctoproject.org/meta-intel.git tzanussi/edison-next http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/edison-next Tom Zanussi (5): meta-crownbay: README correction meta-fri2: README correction meta-crownbay: add linux-yocto-rt_3.0.bbappend meta-fri2: allow linux-yocto-rt to be used for fri2-noemgd meta-crownbay: allow linux-yocto-rt to be used for crownbay meta-crownbay/README |5 + .../linux/linux-yocto-rt_3.0.bbappend | 20 meta-fri2/README |9 + .../linux/linux-yocto-rt_3.0.bbappend |2 ++ 4 files changed, 36 insertions(+), 0 deletions(-) create mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-intel candidate branch for 1.1 edison point release
On Wed, Nov 2, 2011 at 9:37 AM, Tom Zanussi tom.zanu...@intel.com wrote: Hi, I've created a new meta-intel/edison-next branch to hold commits intended for the upcoming 1.1 point release. From a build perspective, it would be better if these commits ended up in the meta-intel/edison branch. It's generally what we do for poky.git and I'd like to keep meta-intel the same. Also, the autobuilder, when it builds out release branches like this, actually will end up requiring that the release branches for all layers are the same (at least until full layer support is implemented.) -b -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-intel candidate branch for 1.1 edison point release
On Wed, 2011-11-02 at 10:17 -0700, Flanagan, Elizabeth wrote: On Wed, Nov 2, 2011 at 9:37 AM, Tom Zanussi tom.zanu...@intel.com wrote: Hi, I've created a new meta-intel/edison-next branch to hold commits intended for the upcoming 1.1 point release. From a build perspective, it would be better if these commits ended up in the meta-intel/edison branch. It's generally what we do for poky.git and I'd like to keep meta-intel the same. Also, the autobuilder, when it builds out release branches like this, actually will end up requiring that the release branches for all layers are the same (at least until full layer support is implemented.) Yes, they will end up there, as the next paragraph mentions: I'll be collecting candidate commits for a 1.1 point release there until it's time to cut the 1.1 point release, and will pull those into edison proper at that point, assuming we have agreement on the set of patches in the branch. Tom -b ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build error while following Appendix A. Yocto Project Development manual
Well, I finally got a successful build without erros of the Appendix A example for Crownbay, but the image created was only 216MB in size and kernel panic'ed because it couldn't find a valid root file system. I'm going to try again from scratch and see if I missed anything. If that fails, I'll report out. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project 1.1 Announcement
Hi all - this is the announcement that went out on Weds at the Embedded
Linux Conference Europe / LinuxCon Europe, in case you haven't seen it.
Yocto Project Introduces New Features
The Linux Foundation-hosted Yocto Project fosters growing community
of embedded Linux developers, technologies and products
PRAGUE {LinuxCon Europe}, October 26, 2011 – The Yocto Project, a hosted
project at The Linux Foundation, today announced the availability of Yocto
Project Release 1.1, as well as a variety of one-year milestones for the
project.
The Linux Foundation today also announced it will become the host for the
Embedded GNU C Library (EGLIBC), further broadening and strengthening a
common set of tools for embedded Linux development.
The EGLIBC library is an add-on to the GNU C library (glibc) and is
optimized for use in embedded development. Until now, Mentor Graphics, the
founder and chief maintainer of the project through its acquisition of
CodeSourcery, hosted the EGLIBC library. Other participants have included
Freescale, MIPS Technologies, MontaVista Software and Wind River, among
others.
The Yocto Project was announced one year ago (October 2010) to provide
developers with greater consistency in the software and tools they’re using
across multiple architectures for embedded Linux development. The
collaborative project brings together the elements needed to make the
normally difficult embedded Linux development process much easier. The
following milestones and activities are contributing to a vibrant community
for embedded development:
• Alignment of OpenEmbedded technology and the inclusion of
OpenEmbedded representation in the Yocto Project governance structure. The
projects share a common core that consists of software build recipes and
core Linux components that prevent fragmentation and reinforce the
OpenEmbedded methodology as an open standard for embedded Linux build
systems.
• Contribution of tools and technologies such as Cross-prelink,
EGLIBC, Pseudo, Shoeleather Lab (for automated testing) and Swabber have
been contributed from Intel, Mentor Graphics, MontaVista Software and Wind
River.
• Commercial adoption with examples such as FIC’s Pegasus platform
powered by Tridium’s Niagara Framework. The Pegasus platform is an
industrial tablet design that was quickly ported to Linux based on existing
Yocto Project Board Support Packages. Tridium is a world leader in software
frameworks, automation infrastructure technology and device-to-enterprise
integration solution, and FIC is a global designer and manufacturer of
mobile and commercial hardware solutions.
• Board Support Packages that include Intel’s Atom-PC,
Freescale’s MPC8315e-RDB, TI’s BeagleBoard and Ubiquiti’s RouterStation
Pro, among others.
The new Yocto Project Release 1.1 is based on Linux kernel 3.0 and consists
of the following new features and resources that enable developers and
third parties to more quickly and easily build embedded Linux systems:
• Multi-lib: Reduces storage and memory footprint by allowing the
system developer to mix and match binaries.
• Hob: An improved graphical user experience enables developers to select
target architecture, image and layer combinations, and to select or remove
individual packages before building, making the use of the Yocto tools even
easier.
• Layer Tooling: Eases the integration and development of layers by
“flattening” them together into a collection of meta-data, making it much
easier for third parties to develop and release layers.
• Initial support for x32, allowing execution of 32-bit code with all the
benefits of 64-bit mode bringing performance and footprint improvements on
x86 processors.
• Small footprint/fast boot layers that make it easier to develop tiny
embedded systems (less than 8MB of memory) with Yocto.
• New packages and components include 3G cellular data support and
advanced btrfs filesystem, which improve applicability of the Yocto Project
tools to new segments.
• New Yocto Project Developer Guide: This document provides
important information on how to get started in open source, Board Support
Package and kernel development.
“Since its introduction one year ago this week, the Yocto Project has
exploded into a strong open source community of developers, users and
vendors working together to advance Linux in the mobile and embedded
markets,” said Jim Zemlin, executive director at The Linux Foundation. “The
Yocto Project has quickly become a trusted upstream resource for embedded
vendors who need to quickly and easily develop products for a variety of
architectures, and get to market fast.”
Companies and organizations participating in the project include Dell,
Intel, Mentor Graphics, MontaVista, OpenEmbedded eV, Texas Instruments,
Timesys, and Wind River, among others. The Yocto Project participants are
meeting this week at LinuxCon Europe and the Embedded Linux Conference in
Prague, Czech Republic. For more information on these events, please visit
the
Re: [yocto] Build error while following Appendix A. Yocto Project Development manual
On Wed, 2011-11-02 at 12:18 -0700, Jim Abernathy wrote: Well, I finally got a successful build without erros of the Appendix A example for Crownbay, but the image created was only 216MB in size and kernel panic'ed because it couldn't find a valid root file system. That size doesn't sound right. Here's mine: -rw-r--r-- 1 trz trz 358715392 2011-11-01 19:11 core-image-sato-mymachine-2001223904.hddimg And what kind of machine are you booting it on? Tom I'm going to try again from scratch and see if I missed anything. If that fails, I'll report out. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build error while following Appendix A. Yocto Project Development manual
On Wed, 2011-11-02 at 13:07 -0700, Jim Abernathy wrote: On Wed, 2011-11-02 at 14:36 -0500, Tom Zanussi wrote: And what kind of machine are you booting it on? Tom I'm building on Core i5 desktop with Ubuntu 10.10. One of the odd things I've noticed during the build is it takes the usual long time (couple of hours) to build. However when it get to task ~4000, it jumps Yeah, that's not out of line with expectations. You are using BB_NUMBER_THREADS and PARALLEL make in your local.conf, I assume. quickly to 43xx close to the end. Not sure if it's missing something critical and I've not set some parameter about the Root file system somewhere. I wouldn't pay too much attention to the task numbers themselves - some tasks take very little time and finish in quick progression. And there's nothing specific about a root filesystem setting in the appendix instructions, we're just copying existing working settings, but there is something wrong with your build nonetheless. I'm planning on submitting a patch to the appendix as soon as I can today or tomorrow morning, which I'll work through and verify, so you shouldn't have to do any guesswork and shouldn't run into any of these kinds of problems... Tom Jim ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Announcement: pseudo 1.2 released
Making a release announcement on behalf of the pseudo maintainer... pseudo 1.2 is now released. It can be pulled from: Via git: git://github.com/wrpseudo/pseudo.git git://git.yoctoproject.org/pseudo.git branch PSEUDO_1_2 or the tarball from http://downloads.yoctoproject.org/releases/pseudo/pseudo-1.2.tar.bz2 The included ChangeLog.txt (http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/tree/ChangeLog.txt?h=PSEUDO_1_2) Contains a full list of changes. --Mark ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build error while following Appendix A. Yocto Project Development manual
I'm noticing fetcher failures while my bitbake is working. They are listed as warning. Do I ignore these?? WARNING: Fetcher failure for URL: 'None'. Fetch command export HOME=/home/jim; export SSH_AGENT_PID=1500; export SSH_AUTH_SOCK=/tmp/keyring-Zcbzax/ssh; export GIT_CONFIG=/home/jim/bsp-test/poky/build/tmp/sysroots/i686-linux/usr/etc/gitconfig; export PATH=/home/jim/bsp-test/poky/build/tmp/sysroots/i686-linux/usr/bin/core2-poky-linux:/home/jim/bsp-test/poky/build/tmp/sysroots/mymachine/usr/bin/crossscripts:/home/jim/bsp-test/poky/build/tmp/sysroots/i686-linux/usr/sbin:/home/jim/bsp-test/poky/build/tmp/sysroots/i686-linux/usr/bin:/home/jim/bsp-test/poky/build/tmp/sysroots/i686-linux/sbin:/home/jim/bsp-test/poky/build/tmp/sysroots/i686-linux//bin:/home/jim/bsp-test/poky/scripts:/home/jim/bsp-test/poky/bitbake/bin/:/home/jim/bsp-test/poky/scripts:/home/jim/bsp-test/poky/bitbake/bin/:/home/jim/bsp-test/poky/scripts:/home/jim/bsp-test/poky/bitbake/bin/:/home/jim/bsp-test/poky/scripts:/home/jim/bsp-test/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/CodeSourcery/Sourcery_G++_Lite/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games: /home/jim/bsp-test/poky/scripts; /usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P /home/jim/bsp-test/poky/build/downloads 'https://fedorahosted.org/releases/l/i/liberation-fonts/liberation-fonts-1.04.tar.gz' failed with signal 4, output: ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] Development Manual Appendix A changes
From: Tom Zanussi tom.zanu...@intel.com Here are a set of changes that attempt to clean up the BSP Development Manual a bit. Thanks to Robert P. J. Day and Jim Abernathy for their input. I went through the resulting doc and set things up exactly as written, and so far the build is looking ok - will report if it doesn't turn out as expected in the morning... Tom The following changes since commit 9b76e6a2cfc5a4d779f3b06e3acc5ff7b8275470: Simon Busch (1): meta: glib-2.0: don't apply qsort_r test removable patch for native version are available in the git repository at: git://git.yoctoproject.org/poky-contrib.git tzanussi/appendix-a-changes http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/appendix-a-changes Tom Zanussi (1): documentation/dev-manual: BSP Development Example changes .../dev-manual/dev-manual-bsp-appendix.xml | 188 1 files changed, 154 insertions(+), 34 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Help diagnosing a build failure involving ncurses, gettext, and eglibc
On 11/02/2011 05:53 PM, Darren Hart wrote: ... I tried to capture my complete log, but screen froze on me while trying to paste the buffer into a log :( So besides writing a bitbake wrapper to ensure I record ALL my bitbake sessions for reference, I came up with the following to ensure I have a log of every bitbake command I run along with some useful stats. Feel free to use it or flame it: #!/bin/bash TIMESTAMP=$(date -u +%Y%m%d%H%M%S) LOG=$(mktemp --suffix=.log bb-$TIMESTAMP-XXX) if [ -z $LOG ]; then echo ERROR: failed to create log file exit 1 fi ( echo Start: $TIMESTAMP echo /usr/bin/time 21 -v bitbake $@ echo echo End: $(date -u '+%Y%m%d%H%M%S') ) | tee $LOG echo Logfile: $LOG -- 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] Help diagnosing a build failure involving ncurses, gettext, and eglibc
On Thu, Nov 3, 2011 at 12:12 AM, Darren Hart dvh...@linux.intel.com wrote: I came up with the following to ensure I have a log of every bitbake command I run along with some useful stats. Feel free to use it or flame it: #!/bin/bash TIMESTAMP=$(date -u +%Y%m%d%H%M%S) LOG=$(mktemp --suffix=.log bb-$TIMESTAMP-XXX) if [ -z $LOG ]; then echo ERROR: failed to create log file exit 1 fi ( echo Start: $TIMESTAMP echo /usr/bin/time 21 -v bitbake $@ echo echo End: $(date -u '+%Y%m%d%H%M%S') ) | tee $LOG echo Logfile: $LOG It would be nice if we had this as a selectable option in the bitbake wrapper somehow and it saved off logs to tmp/bitbake/logs/ or something appropriate. -M ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
