Re: [yocto] YPDD access code.
On 01/16/2013 02:20 PM, Scott Garman wrote: Hello, To Yocto core team members who will be attending YPDD at ELC in February - the access code this year for Yocto staff is YPDD13STF. You will be asked to provide this code while registering for ELC. I'm really sorry I sent this to the wrong address. Please understand that the above code is only to be used for staff members who will be running YPDD. The event is free, so it's not like you'd get anything extra for signing up as staff. We simply keep the category separate so we don't end up counting staff members the same as attendees. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] YPDD access code.
Hello, To Yocto core team members who will be attending YPDD at ELC in February - the access code this year for Yocto staff is YPDD13STF. You will be asked to provide this code while registering for ELC. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] discussion of layers in dev manual uses a *really* bad example
On 12/30/2012 01:45 AM, Robert P. J. Day wrote:
more pedantry -- dev manual, section 5.1.2 talks about creating a
new layer and recommends using the meta-yocto layer.conf as a starting
point, which contains:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${LAYERDIR}:${BBPATH}"
the problem is that almost every other layer *appends* LAYERDIR to
BBPATH, not the other way around, so that example is spectacularly
unrepresentative. (i'm unaware of any other layer that sets BBPATH in
that order, and i recall tom zanussi (?) explaining once why that
was.)
perhaps a different example, and a short explanation about why the
meta-yocto layer is the exception here?
ScottR:
As some background on this issue, please take a look at this thread from
almost exactly a month ago:
https://lists.yoctoproject.org/pipermail/yocto/2012-December/013041.html
https://lists.yoctoproject.org/pipermail/yocto/2012-December/013057.html
I agree that we shouldn't recommend using the meta-yocto layer.conf as a
starting point, due to the BBPATH append ordering difference.
And maybe a note about why we order the BBPATH append as we do in
meta-yocto (see Thomas' concise explanation in the second link above)
would be appropriate.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] odd(?) behaviour with qemu arm image and "runqemu-extract-sdk"
On 12/29/2012 09:33 AM, Robert P. J. Day wrote: first time perusing these sections in the yocto docs, kind of puzzling result so i'm prepared to believe i did something silly. reading: http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#workflow-using-stand-alone-cross-development-toolchains "Workflow Using Stand-alone Cross-development Toolchains", and i already had an OE qemuarm core-image-minimal built that i can run just fine with: $ runqemu qemuarm so i was reading that section and followed the link over to the ADT manual: http://www.yoctoproject.org/docs/1.4/adt-manual/adt-manual.html#extracting-the-root-filesystem where it talked about "Extracting the Root Filesystem", so i figured, what the heck, i'll give that a shot, so i ran "runqemu-extract-sdk" on the very rootfs tarball that had been created by my build and extracted it under ~/rootfs, then without reading any further, tried this variation of runqemu for the first time: $ runqemu qemuarm ~/rootfs Assuming /home/rpjday/rootfs is an nfs rootfs Continuing with the following parameters: KERNEL: [/home/rpjday/oe/builds/oe/qemuarm/tmp-eglibc/deploy/images/zImage-qemuarm.bin] ROOTFS: [/home/rpjday/rootfs] FSTYPE: [nfs] Setting up tap interface under sudo [sudo] password for rpjday: Acquiring lockfile for tap0... runqemu-export-rootfs restart /home/rpjday/rootfs Error: Unable to find rpc.mountd binary in /home/rpjday/oe/builds/oe/qemuarm/tmp-eglibc/sysroots/x86_64-linux/usr/sbin/ Have you run 'bitbake meta-ide-support'? Set 'tap0' nonpersistent Releasing lockfile of preconfigured tap device 'tap0' $ so ... how many things did i do wrong? Hi Robert, When you built your original image, it generated a filesystem in a file (in this case, an ext3 one) which the runqemu script used to boot with. But booting an nfs-based image with runqemu requires our userspace NFS server. This is a new requirement that requires you to build the meta-ide-support target. So in this case, what you're seeing is exactly what is intended - the runqemu script tells you what you need to do to proceed. You did nothing wrong. There was a time (a long time ago) when meta-ide-support was built anytime qemu was built, but we ended up splitting it out since it added an unnecessary build dependency on meta-ide-support when most users never needed to boot an NFS image. some random thoughts on this before i dig back into the docs and code: 1) why the name "runqemu-extract-sdk"? it seems that the point of that script is to just untar a root filesystem. i don't see anything being "extracted" per se. I suppose runqemu-extract-rootfs might be a better name for it. When the script was first developed, the main use case for it was extracting the -sdk images so they could be used with our application developer tools. The key thing this script does is extract the rootfs tarball under pseudo, which creates a virtual mapping of file ownership that is necessary for the rootfs to be usable but not require root access from the end user's perspective. 2) i notice that the "dev" directory created by that script contains only regular files instead of actual special device files. but if i use "sudo" to just untar exactly the same tarball, i get real device files. is that the expected behaviour of that script? Yes - since the invokation of pseudo from the runqemu-extract-rootfs script creates a pseudo database that will later be used when runqemu boots the rootfs to read the files. 3) what should i have done earlier to have the apparently necessary usr/sbin/rpc.mountd in my sysroot? Just what the script said: bitbake meta-ide-support it seems odd that i can run my built qemu image just fine if i run it normally, but if i runqemu-extract-sdk to unload a rootfs, suddenly my sysroot is missing that utility. By now I hope it should be clear that the rpc.mountd was not needed to boot a .ext3 image. It's only needed for NFS-based booting. So the file didn't suddenly disappear when you went to boot the NFS-based rootfs. It was just needed for the first time then. and one more thing. from that first link in the dev manual, there's that note that takes you over to the ADT manual. and it's entirely possible that there some critical info *before* the section "Extracting the Root Filesystem" but given how one got there (by following the link), the reader might miss it. I'll have to leave this one to our app dev folks and ScottR if they agree something should be changed. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Denzil 1.2.2 development nearly complete
Hi everyone, I wanted to make sure the community is aware that I am wrapping things up for our next denzil stable release, 1.2.2. We've had some discussions about this at the Technical Team Meetings, but I thought I'd send this out to the mailing lists as well. The current status of my testing branches can be found here: oe-core based tree: http://git.openembedded.org/openembedded-core-contrib/log/?h=sgarman/denzil-next and my poky-based tree: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next I will be submitting a pull request to Richard soon to get these patches merged to the official denzil branches of the oe-core and poky repositories, respectively. If anyone has outstanding patches they need in denzil (or that I've overlooked), please get them to me as soon as possible. To see a list of bugs addressed during the 1.2.2 release cycle, do a Bugzilla search for bugs with a Target Milestone of 1.2.2. Our QA team will be back on Monday, January 7, and will begin another full-pass test cycle on denzil. If they don't find any new bugs and can verify the recently fixed bugs in denzil, our goal is to release 1.2.2 shortly thereafter. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH runqemu] runqemu: add support for FSTYPE=vmdk
l b/scripts/runqemu-internal index 7ca00f8..fd1304e 100755 --- a/scripts/runqemu-internal +++ b/scripts/runqemu-internal @@ -260,13 +260,13 @@ case "$MACHINE" in ;; esac -if [ ! -f "$KERNEL" ]; then +if [ ! -f "$KERNEL" -a "x$FSTYPE" != "xvmdk" ]; then echo "Error: Kernel image file $KERNEL doesn't exist" cleanup return fi -if [ "$FSTYPE" != "nfs" -a ! -f "$ROOTFS" ]; then +if [ "$FSTYPE" != "nfs" -a "$FSTYPE" != "vmdk" -a ! -f "$ROOTFS" ]; then echo "Error: Image file $ROOTFS doesn't exist" cleanup return @@ -341,6 +341,9 @@ if [ "$MACHINE" = "qemux86" ]; then KERNCMDLINE="root=/dev/nfs nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY" QEMUOPTIONS="$QEMU_NETWORK_CMD $QEMU_UI_OPTIONS" fi +if [ "$FSTYPE" = "vmdk" ]; then +QEMUOPTIONS="$QEMU_NETWORK_CMD $QEMU_UI_OPTIONS" +fi # Currently oprofile's event based interrupt mode doesn't work(Bug #828) in # qemux86 and qemux86-64. We can use timer interrupt mode for now. KERNCMDLINE="$KERNCMDLINE oprofile.timer=1" @@ -365,6 +368,9 @@ if [ "$MACHINE" = "qemux86-64" ]; then KERNCMDLINE="root=/dev/nfs nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY" QEMUOPTIONS="$QEMU_NETWORK_CMD $QEMU_UI_OPTIONS" fi +if [ "$FSTYPE" = "vmdk" ]; then +QEMUOPTIONS="$QEMU_NETWORK_CMD $QEMU_UI_OPTIONS" +fi # Currently oprofile's event based interrupt mode doesn't work(Bug #828) in # qemux86 and qemux86-64. We can use timer interrupt mode for now. KERNCMDLINE="$KERNCMDLINE oprofile.timer=1" @@ -560,8 +566,14 @@ fi echo "Running $QEMU..." # -no-reboot is a mandatory option - see bug #100 -echo $QEMUBIN -kernel $KERNEL $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT --append '"'$KERNCMDLINE $SCRIPT_KERNEL_OPT'"' -LD_PRELOAD="$GL_LD_PRELOAD" $QEMUBIN -kernel $KERNEL $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT --append "$KERNCMDLINE $SCRIPT_KERNEL_OPT" +if [ "$FSTYPE" = "vmdk" ]; then +echo $QEMUBIN $VM $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT +LD_PRELOAD="$GL_LD_PRELOAD" $QEMUBIN $VM $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT +else +echo $QEMUBIN -kernel $KERNEL $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT --append '"'$KERNCMDLINE $SCRIPT_KERNEL_OPT'"' +LD_PRELOAD="$GL_LD_PRELOAD" $QEMUBIN -kernel $KERNEL $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT --append "$KERNCMDLINE $SCRIPT_KERNEL_OPT" +fi + cleanup -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Use of BBPATH in a layer.conf file.
On 12/03/2012 09:43 AM, Tomas Frydrych wrote:
On 02/12/12 22:51, Scott Garman wrote:
Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.
In meta-hob, meta-yocto-bsp, and meta-intel, we do:
BBPATH := "${BBPATH}:${LAYERDIR}"
but in meta-yocto, we do:
BBPATH := "${LAYERDIR}:${BBPATH}"
Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.
This meta-yocto setup is intentional (there was thread about that a
while back). meta-yocto is a distro layer, and for any distro layer it
is reasonable to enforce its own precedence over any other layers is may
use, and meta-yocto chooses to do this. Non-distro layers, including all
bsp layers, are expected to always use an append operation so that they
can be stacked together.
Thanks for the concise explanation.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Use of BBPATH in a layer.conf file.
On 12/02/2012 03:24 PM, Paul Eggleton wrote:
On Sunday 02 December 2012 14:51:28 Scott Garman wrote:
Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.
In meta-hob, meta-yocto-bsp, and meta-intel, we do:
BBPATH := "${BBPATH}:${LAYERDIR}"
but in meta-yocto, we do:
BBPATH := "${LAYERDIR}:${BBPATH}"
Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.
I think it actually ought to be:
BBPATH .= ":${LAYERDIR}"
Oh? Would this apply just to meta-yocto or all layer.conf files?
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] meta-yocto layer.conf: Append to BBPATH consistent with other layers
Trivial change to make the appending of BBPATH consistent with how
we do things in other layers.
Signed-off-by: Scott Garman
---
meta-yocto/conf/layer.conf |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-yocto/conf/layer.conf b/meta-yocto/conf/layer.conf
index 7917962..68786b2 100644
--- a/meta-yocto/conf/layer.conf
+++ b/meta-yocto/conf/layer.conf
@@ -1,5 +1,5 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := "${LAYERDIR}:${BBPATH}"
+BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] meta-yocto layer.conf consistency fix
Just a fix to make the appending to BBPATH consistent with how we set it in other layers. Scott The following changes since commit 247b6a3754c2c50318e2a73d79981ba0e9cb560b: gstreamer, gst-plugins*: fix localdata (2012-11-28 15:25:33 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib sgarman/meta-yocto-layer-fix http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgarman/meta-yocto-layer-fix Scott Garman (1): meta-yocto layer.conf: Append to BBPATH consistent with other layers meta-yocto/conf/layer.conf |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Use of BBPATH in a layer.conf file.
Hey folks,
Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.
In meta-hob, meta-yocto-bsp, and meta-intel, we do:
BBPATH := "${BBPATH}:${LAYERDIR}"
but in meta-yocto, we do:
BBPATH := "${LAYERDIR}:${BBPATH}"
Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH resend][opkg-utils] opkg.py/opkg-build: fix creation of tar archives
On 11/10/2012 01:33 AM, Tomas Frydrych wrote: On 24/10/12 12:14, Richard Purdie wrote: On Wed, 2012-10-24 at 12:53 +0200, Steffen Sledz wrote: Since openSUSE 12.2 the installed tar uses posix instead of gnu encoding by default. This format is not fully supported by opkg and results in ipk packages not installable at the target. Collected errors: * get_header_tar: Unknown typeflag: 0x78: Success. * get_header_tar: Unknown typeflag: 0x78: Success. * get_header_tar: Unknown typeflag: 0x78: Success. * extract_archive: Don't know how to handle /var/lib/opkg/tmp/opkg-mg997m/chicken-bin-fGRvr4/PaxHeaders.17512/.: No such file or directory. * get_header_tar: Unknown typeflag: 0x78: No such file or directory. * get_header_tar: Unknown typeflag: 0x78: No such file or directory. ... Signed-off-by: Steffen Sledz --- opkg-build |6 +++--- opkg.py|6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) Merged to master, thanks. Could this be also applied to the danny branch (and perhaps even denzil)? Hi Tomas, I have applied this to my sgarman/denzil-next branches. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Slides from the Yocto Developer Day
On 11/15/2012 03:14 PM, Trevor Woerner wrote:
Thank you.
These are interesting slides. As I was not able to attend the sessions
in Barcelona, I decided to "follow along at home" with the information
posted in this thread.
The slides pdf (ypdd_2012_barcelona_intro_hands_on_lab.pdf) describes
the first line of the contents of the
meta-ypdd/recipes-ypdd/images/ypdd-image.bb <http://ypdd-image.bb> as
follows:
IMAGE_INSTALL = "task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} \
${POKY_EXTRA_INSTALL} psplash dropbear"
The _worksheets.pdf modifies it as follows:
IMAGE_INSTALL = "task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} \
${CORE_IMAGE_EXTRA_INSTALL} psplash dropbear"
I tried both variations using both today's latest HEAD and denzil-7.0.1.
Neither variation worked in either release.
If anyone else is following along, I was able to get the latest HEAD to
work with the following first line:
IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} \
${CORE_IMAGE_EXTRA_INSTALL} psplash dropbear"
For me "latest HEAD" is defined as:
Build Configuration:
BB_VERSION= "1.16.0"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "qemux86"
DISTRO= "poky"
DISTRO_VERSION= "1.3+snapshot-20121115"
TUNE_FEATURES = "m32 i586"
TARGET_FPU= ""
meta
meta-yocto
meta-yocto-bsp= "master:9e0d3c0faa9cc80ce8f2ce0eb31dcd20ef875955"
meta-ypdd = ":"
denzil-7.0.1 never worked for me in any way. At best it would fail with
some obscure perl problem:
| ERROR: Function failed: do_configure (see
/home/trevor/devel/yocto/denzil-7.0.1/ypdd/tmp/work/x86_64-linux/openssl-native-1.0.0i-r0.2/temp/log.do_configure.30074
for further information)
| Can't locate find.pl <http://find.pl> in @INC (@INC contains:
/usr/lib/perl5/site_perl/5.16.0/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.16.0
/usr/lib/perl5/vendor_perl/5.16.0/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.16.0
/usr/lib/perl5/5.16.0/x86_64-linux-thread-multi /usr/lib/perl5/5.16.0
/usr/lib/perl5/site_perl/5.16.0/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.16.0 /usr/lib/perl5/site_perl .) at
perlpath.pl <http://perlpath.pl> line 7.
NOTE: package openssl-native-1.0.0i-r0.2: task do_configure: Failed
The CORE_IMAGE_EXTRA_INSTALL issue must have been a typo I carried
forward from when the labs were done with the edison release. As for the
openssl-native failure, I'm not sure, but I'm guessing this may be due
to a host contamination issue that wasn't triggered with the host OS
setup we had for the lab computers.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Virtual machine images from yocto developer day
On 11/15/2012 10:57 AM, William Mills wrote: Is it possible to get the vdi-files or appliances (which ever it was) used for the labs? It would save some valuable time when doing labs with beginners here at work. Best regards /Fredrik Hugosson Which labs? For the intro labs, the computers were running Linux natively. I took some notes on how I set up those machines I can send you off-list if you'd like - let me know. Things *should* just work if you're using a recent release of Ubuntu, Fedora, or OpenSUSE and follow the setup instructions in our Quick Start Guide: https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Just a side note that I should have materials available on the website by the end of this week I would encourage the presenters to share the setup instructions also so that some one can follow the course ware. Some of the steps in the labs assume setup has been done. I'm all for sharing the info so that this training material can scale as much as possible. Looking over the notes I took, they were mostly about how to set up the desktop environment for the lab computers. I do intend to improve that to include further details about the actual build environment setup. I'm taking my last bit of vacation time for the year starting today and will be back on Nov 26th, so I've added an item to my todo list and will get back to this eventually. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Virtual machine images from yocto developer day
On 11/15/2012 04:05 AM, Fredrik Hugosson wrote: Hi! Thanks for a great developer day in Barcelona! Is it possible to get the vdi-files or appliances (which ever it was) used for the labs? It would save some valuable time when doing labs with beginners here at work. Best regards /Fredrik Hugosson Which labs? For the intro labs, the computers were running Linux natively. I took some notes on how I set up those machines I can send you off-list if you'd like - let me know. Things *should* just work if you're using a recent release of Ubuntu, Fedora, or OpenSUSE and follow the setup instructions in our Quick Start Guide: https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't fetch git SRC_URI via HTTP
On 10/02/2012 02:17 PM, Evade Flow wrote: I'm trying to build core-image-sato for my Pandaboard ES, following the instructions posted here: - http://maniacbug.wordpress.com/2012/08/03/pandayocto/ Thus, my OE build configuration looks like this: I just would like to comment that this is one of the best requests for help I've seen on this mailing list. Kudos for including all the relevant information! Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 00/62] denzil pull request 2
i2html: Fix perl location on recent distros
Ross Burton (1):
pulseaudio: remove ConsoleKit dependency
Saul Wold (7):
build-appliance-image: Update SRCREV to Denzil 1.2.1
build-appliance-image: Add vmx* files and build zip file
build-appliance: add zip-native, which is needed to build the final
zip bundle
python-pygtk: Upgrade to 2.24
kernel: Fix packaging issue
bluez4: fix packaging issue after update
pulseaudio: disable tcpwrap by default
Scott Garman (2):
relocatable.bbclass: Account for case when ORIGIN is in RPATH
kernel.bbclass: put perf .debug dir in -dbg package
Valentin Popa (2):
build-appliance-image: rename from self-hosted-image
xz: updated to version 5.1.1alpha
Xin Ouyang (1):
libatomics-ops: update to the latest version 7.2
Zhenhua Luo (1):
valgrind: fix debug info reading error when do memcheck on ppc
targets
bitbake/lib/bb/ui/crumbs/builder.py| 23 +-
bitbake/lib/bb/ui/crumbs/hig.py| 58 +-
bitbake/lib/bb/ui/crumbs/hobeventhandler.py|4 +-
meta-yocto/conf/distro/poky.conf |2 +
meta/classes/autotools.bbclass | 21 +
meta/classes/distutils.bbclass |2 +-
meta/classes/kernel-yocto.bbclass | 121 +-
meta/classes/kernel.bbclass| 37 +-
meta/classes/mirrors.bbclass |1 -
meta/classes/package.bbclass | 16 +-
meta/classes/relocatable.bbclass |3 +-
meta/classes/setuptools.bbclass|1 +
meta/conf/bitbake.conf |2 +-
meta/conf/multilib.conf|2 +-
meta/recipes-bsp/u-boot/u-boot.inc | 16 +-
meta/recipes-bsp/u-boot/u-boot_2011.03.bb |2 +-
meta/recipes-bsp/u-boot/u-boot_2011.06.bb |2 +-
.../{bluez-hcidump_2.3.bb => bluez-hcidump_2.4.bb} |4 +-
.../{bluez4-4.99 => bluez4-4.101}/bluetooth.conf |0
.../{bluez4-4.99 => bluez4-4.101}/sbc_mmx.patch|0
meta/recipes-connectivity/bluez/bluez4.inc |6 +-
.../bluez/{bluez4_4.99.bb => bluez4_4.101.bb} | 10 +-
...tooth_4.99.bb => gst-plugin-bluetooth_4.101.bb} |7 +-
meta/recipes-connectivity/dhcp/dhcp.inc|2 +
meta/recipes-connectivity/dhcp/dhcp_4.2.3-P2.bb|2 +-
meta/recipes-core/dbus/dbus-glib_0.98.bb |2 +-
meta/recipes-core/dbus/dbus.inc| 17 +-
.../eglibc/eglibc-2.13/supported-tt-ru.patch | 13 +
.../eglibc/eglibc-2.15/glibc.no_sqrt.patch | 15 +
meta/recipes-core/eglibc/eglibc_2.13.bb|3 +-
meta/recipes-core/eglibc/eglibc_2.15.bb|4 +-
meta/recipes-core/glib-2.0/glib-2.0_2.30.3.bb |2 +-
meta/recipes-core/glib-2.0/glib.inc|2 +-
...lf-hosted-image.bb => build-appliance-image.bb} | 28 +-
.../Yocto_Build_Appliance.vmx | 52 +
.../Yocto_Build_Appliance.vmxf |8 +
meta/recipes-core/psplash/psplash_git.bb |4 +-
.../sysvinit/sysvinit-inittab_2.88dsf.bb | 10 +-
meta/recipes-devtools/gcc/gcc-4.6.inc |5 +-
.../gcc/gcc-4.6/gcc.e6500-FSF46.patch | 4015
.../gcc/gcc-4.6/gcc.no_power_builtins.patch| 30 +
.../gcc/gcc-4.6/powerpc-e5500.patch| 465 ---
.../opkg-utils/opkg-utils/add-license-field.patch | 39 -
.../opkg-utils/arfile_header_split.patch | 27 -
.../opkg-utils/index-ignore-filenotfound.patch | 73 -
.../opkg-utils/opkg-utils/mtime-int.patch | 30 -
.../opkg-utils/opkg-utils/shebang.patch| 46 -
meta/recipes-devtools/opkg-utils/opkg-utils_git.bb |9 +-
.../python/python-pygtk/fix-gtkunixprint.patch | 14 +-
...thon-pygtk_2.17.0.bb => python-pygtk_2.24.0.bb} |8 +-
...ind-3.7.0-fix-error-of-reading-debug-info.patch | 33 +
meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |5 +-
meta/recipes-extended/ltp/ltp_20120104.bb |4 +-
meta/recipes-extended/man/man-1.6f/man.conf| 140 +
meta/recipes-extended/man/man_1.6f.bb | 11 +-
meta/recipes-extended/pam/libpam_1.1.5.bb |3 +-
meta/recipes-extended/texi2html/texi2html_5.0.bb |6 +-
.../xz/{xz_5.0.3.bb => xz_5.1.1alpha.bb} | 10 +-
.../pulseaudio/libatomics-ops/doublefix.patch | 27 -
.../fedora/libatomic_ops-1.2-ppclwzfix.patch | 20 -
.../gentoo/libatomic_ops-1.2-mips.patch| 129 -
.../libatomics-ops_fix_for_x32.patch | 41 -
...libatomics-ops_1.2.bb => libatomics-ops_7.2.bb} | 11 +-
.../{libcanberra_0.28.bb => libcanberra_0.29.bb} | 14 +-
meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 11 +-
..._for_x32.patch => pulseaudio_fix_for_x32.patch} |0
.../{puls
Re: [yocto] [linux-yocto] 'bitbake linux-yocto' after 'bitbake linux-yocto -c compile -f' does not create image
On 09/12/2012 01:25 PM, Paul Eggleton wrote: On Wednesday 12 September 2012 11:22:07 Scott Garman wrote: On 09/12/2012 08:06 AM, Rudolf Streif wrote: In Denil modifying kernel parameters and doing bitbake linux-yocto -c compile -f bitbake linux-yocto worked perfectly fine. The tasks after compile were rerun and the new kernel copied to tmp/deploy/images In Edison 7.0.1 this does not seem to work anymore. The tasks do not rerun and the kernel image is not deployed. What has changed? Why does it not work anymore? This was a bug that was introduced in 7.0.1. I have included a patch series in my testing branch that is intended to go into the denzil branch soon: d7b818b bitbake: refactor out codeparser cache into a separate class 66123b9 classes/cml1: ensure -c menuconfig forces a rebuild next time 5bd11a9 bitbake: bitbake: ensure -f causes dependent tasks to be re-run 8b8be74 bitbake: implement checksums for local files in SRC_URI We need to be very careful which patches we backport. In particular that last patch 8b8be74 should not be backported - it's new functionality, requires support in the metadata to work, and led to several further cleanup patches for the metadata to avoid warnings being raised. I agree with the need to be conservative about backporting new features into point-releases. In this case I was given a list from someone of which patches were needed to resolve the menuconfig issue, and I didn't question it. I will make a note to try removing 8b8be74 before I submit my final pull request to denzil - this almost certainly won't happen this week due to conference craziness. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [linux-yocto] 'bitbake linux-yocto' after 'bitbake linux-yocto -c compile -f' does not create image
On 09/12/2012 08:06 AM, Rudolf Streif wrote: In Denil modifying kernel parameters and doing bitbake linux-yocto -c compile -f bitbake linux-yocto worked perfectly fine. The tasks after compile were rerun and the new kernel copied to tmp/deploy/images In Edison 7.0.1 this does not seem to work anymore. The tasks do not rerun and the kernel image is not deployed. What has changed? Why does it not work anymore? This was a bug that was introduced in 7.0.1. I have included a patch series in my testing branch that is intended to go into the denzil branch soon: d7b818b bitbake: refactor out codeparser cache into a separate class 66123b9 classes/cml1: ensure -c menuconfig forces a rebuild next time 5bd11a9 bitbake: bitbake: ensure -f causes dependent tasks to be re-run 8b8be74 bitbake: implement checksums for local files in SRC_URI http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Beaglebone BSP for denzil?
Hello, Am I correct in understanding that the TI Beagleboard BSP from yoctoproject.org should work with the Beaglebone, or do I need meta-ti? I'm not looking for accelerated graphics or anything - this will just be used in a classroom setting where there will be Beaglebones I'd like to boot up to a minimal console image. I'll be doing this with the denzil release. Thanks, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dev manual section on "customizing images" needs serious adjustment
On 08/23/2012 01:13 AM, Tomas Frydrych wrote: Hi, On 22/08/12 21:37, Robert P. J. Day wrote: One way to get additional software into an image is to create a custom image. The manual should make it clear that this is *the* canonical way to add software to your images. Modifications to local.conf are temporary tweaks for testing/debugging (i.e., you should never feel the need to commit your local.conf to some project version control system). Tomas +1. If you add additional packages to core-image-minimal in your local.conf, you're no longer really building core-image-minimal. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Maintenance on older branches, e.g. bernard
On 08/08/2012 11:20 AM, Elvis Dowson wrote: Hi, I just noticed that if one were to try switching to an older poky branch, say bernard, there are a few errors: e.g. meta-yocto layer doesn't have a conf folder. Also if you use one of the tags, e.g. bernard-5.0, bernard-5.0.1, bernard-5.0.2, you can run into build failures. I think at the very least, one should be able to build successfully off one of the older branches, and perhaps it should be part of the regular regression tests? When you say "build successfully", how do you define that? Building core-image-minimal? -sato? -lsb? For which machines? On how many host distros? We have a problem of scale here which is why bernard (now three stable releases old) is no longer undergoing active maintenance or regression testing by the core team. This is where the community or a partner organization with a financial interest in supporting that release for their customers needs to step in. As time goes on, we're seeing more commercial adoption our releases and I think we'll see more of this for the recent releases (edison and denzil in particular, but bernard came out when the Yocto Project was still fairly new). IMO, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom splash screen using psplash
On 08/08/2012 10:10 AM, Scott Garman wrote: On 08/08/2012 08:13 AM, Giovanni Foiani wrote: Hi, I need to setup a custom splash screen replacing the Yocto logo with a custom image. I generated my logo using make-image script into psplash screen and replaced the previous one in meta/recipes-core/psplash/files folder. Then I run * bitbake psplash -c cleansstate * bitbake psplash and then generate a new image, but during boot I still see the Yocto logo. Which is the right procedure? Does the my custom logo (a png image) have some requirements (i.e. size, colors, etc..)? Did you re-generate the image too? Sorry, apparently I can't read this morning. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom splash screen using psplash
On 08/08/2012 08:13 AM, Giovanni Foiani wrote: Hi, I need to setup a custom splash screen replacing the Yocto logo with a custom image. I generated my logo using make-image script into psplash screen and replaced the previous one in meta/recipes-core/psplash/files folder. Then I run * bitbake psplash -c cleansstate * bitbake psplash and then generate a new image, but during boot I still see the Yocto logo. Which is the right procedure? Does the my custom logo (a png image) have some requirements (i.e. size, colors, etc..)? Did you re-generate the image too? Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding gcc-4.5.4 release back into oe-core
On 08/04/2012 12:19 PM, Elvis Dowson wrote: Hi Khem, Do you think it makes sense to add gcc-4.5.4 back into oe-core, if it turns out that gcc-4.7.2 is causing a lot of issues for some targets? I'll politely add that discussions like this (specifically about oe-core) belong on the oe-core mailing list, not this one. Thanks, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] denzil-next (1.2.2) staging branch change
Hello, I just wanted to make a short announcement that I've just renamed my sgarman/denzil-next-1.2.2 staging branches to simply sgarman/denzil-next. oe-core based: http://git.openembedded.org/openembedded-core-contrib/log/?h=sgarman/denzil-next poky based: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next I created the -1.2.2 branches because at the time the Yocto Project 1.2.1 release was still being finalized and I needed to start tracking patches for the next denzil point release. Now that 1.2.1 is out, the meaning of denzil-next is no longer ambiguous. Again, the workflow I'm using is I pull in community requests for denzil commits into my sgarman/denzil-next branches, run some tests on them, and then submit a pull request to the appropriate mailing lists so Richard can then approve and merge them into the official denzil branches. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [denzil-next BREAKAGE] Silent breakage in denzil-next --- uImage*.dts no longer generated
On 08/01/2012 07:50 AM, Leon Woestenberg wrote:
Hello Scott, all,
On Wed, Aug 1, 2012 at 4:31 PM, Leon Woestenberg
mailto:sidebranch.openembed...@gmail.com>> wrote:
Hello Scott,
I tested your denzil-next branch but found breakage that will not
fail the (auto) build.
I'm hitting the "Warning: ${DTS_FILE} is not available!" case.
Disregard the breakage. Local user error; my KERNEL_DEVICETREE missed
the "${S}" prefix.
However, that being said, should we silently fail with a warning of the
specified device tree (DTS) is missing? This is clearly a change of
behaviour that makes the build prone to user errors, as I just demonstrated.
I rather have the build fail.
Hi Leon,
Thanks for bringing this up. I believe Matthew made the original request
for this commit (linux-dtb: add multi-dtb build support,
a40d795ee97d8ada6a0b76c9741a8653fd646893). I'm cc:'ing him on this email
as well as Richard Purdie, who has yet to review the new commits in my
denzil-next branch and may also have some input on this issue.
The question in my mind right now is whether this change is too
risky/change-inducing for a point-release.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [for denzil] kernel.bbclass: Copy bounds.h only if it exists, needed for 2.6.x.
On 08/01/2012 02:08 AM, Leon Woestenberg wrote: Hello Koen, On 08/01/2012 08:55 AM, Koen Kooi wrote: Shouldn't this be sent to the oe-core list?!?!? It was intended for the denzil branch ([for denzil]) of Yocto, that's why I sent it to yocto@yoctoproject.org. If that was wrong reasoning, let me know, I would be glad to change workflow if I know why. Hi Leon, Since Yocto is built upon oe-core, changes to files that live in oe-core should really be sent to the oe-core ML. Our workflow is then to pick things up from oe-core and move them into the poky git repository. Both oe-core and poky have denzil branches this patch applies to, so you'd still make mention in your subject line that the patch is intended for denzil. The main reason to submit patches to the Yocto ML is if it's specific to the meta-yocto layer you find in the Poky git repository, or to discuss overall Yocto issues. Just some things to keep in mind for the future. Thanks, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [for denzil] kernel.bbclass: Copy bounds.h only if it exists, needed for 2.6.x.
On 07/31/2012 01:35 PM, sidebranch.openembed...@gmail.com wrote:
From: Leon Woestenberg
Linux 2.6.x kernels did not (all) have the bounds.h file, so copy
only iff exists.
(See OE-Core 02ac0d1b65389e1779d5f95047f761d7a82ef7a4)
Signed-off-by: Leon Woestenberg
---
meta/classes/kernel.bbclass |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index c21ab96..5f6ff66 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -183,6 +183,11 @@ kernel_do_install() {
cp arch/powerpc/lib/crtsavres.o
$kerneldir/arch/powerpc/lib/crtsavres.o
fi
+ # Necessary for building modules like compat-wireless.
+ if [ -f include/generated/bounds.h ]; then
+ cp include/generated/bounds.h
$kerneldir/include/generated/bounds.h
+ fi
+
# Remove the following binaries which cause strip errors
# during do_package for cross-compiled platforms
bin_files="arch/powerpc/boot/addnote arch/powerpc/boot/hack-coff \
Merged into my sgarman/denzil-next branches:
http://git.openembedded.org/openembedded-core-contrib/log/?h=sgarman/denzil-next
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next
If this passes a round of autobuilder tests, I'll be submitting a pull
request to the official denzil branch shortly thereafter.
Thanks,
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do QEMU images really come with dropbear and an nfs server?
On 07/27/2012 11:04 AM, Robert P. J. Day wrote: On Fri, 27 Jul 2012, Scott Garman wrote: On 07/27/2012 07:18 AM, Robert P. J. Day wrote: the yocto dev manual currently suggests that QEMU images come with both dropbear and an nfs server: http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#using-pre-built-binaries-and-qemu i don't have a QEMU image in front of me to test, but the definition of the basic QEMU images doesn't seem to suggest that that's true. i can see it's easy to add them, but the manual suggests they're there by default. or am i misreading something? It looks like we may need a manual tweak here. core-image-minimal does not come with any ssh server. core-image-lsb should have openssh instead of dropbear. So unless something changed very recently, core-image-sato is the only one that has dropbear in it by default. Also, the manual states "The QEMU images also contain an embedded Network File System (NFS) server that exports the image's root filesystem." This isn't strictly true - instead we offer a native tool which runs a userspace NFS server and if some prep work is done by the user (extracting a rootfs tarball with runqemu-extract-sdk), you can then point the runqemu script to that directory instead of a rootfs image file. rather than a simple manual tweak, what about actually adding one or both of those features to even the smaller core images, then updating the docs accordingly? just a thought. Well, in the case of core-image-minimal, I don't think we want to add additional bloat. Also, when I teach classes on how to create custom image recipes, my exercise is typically to take core-image-minimal, and modify it to include an ssh server (dropbear or openssh) and psplash (which gives students a nice visual change to notice when booting the new image). As a fellow instructor, you may find that useful. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do QEMU images really come with dropbear and an nfs server?
On 07/27/2012 07:18 AM, Robert P. J. Day wrote: the yocto dev manual currently suggests that QEMU images come with both dropbear and an nfs server: http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#using-pre-built-binaries-and-qemu i don't have a QEMU image in front of me to test, but the definition of the basic QEMU images doesn't seem to suggest that that's true. i can see it's easy to add them, but the manual suggests they're there by default. or am i misreading something? It looks like we may need a manual tweak here. core-image-minimal does not come with any ssh server. core-image-lsb should have openssh instead of dropbear. So unless something changed very recently, core-image-sato is the only one that has dropbear in it by default. Also, the manual states "The QEMU images also contain an embedded Network File System (NFS) server that exports the image's root filesystem." This isn't strictly true - instead we offer a native tool which runs a userspace NFS server and if some prep work is done by the user (extracting a rootfs tarball with runqemu-extract-sdk), you can then point the runqemu script to that directory instead of a rootfs image file. Someone please correct me if I'm wrong. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] nothing building under denzil-7.0.1
On 07/20/2012 01:11 PM, Jim Abernathy wrote: There must be some basic thing I'm missing. Nothing that I used to build under denzil 7.0 will now build under denzil 7.0.1 or tracking the denzil branch. Are all the BSPs required to be updated to 7.0.1 before you can run? I'd thought I'd check before I post a bunch of log files. I just downloaded the poky 7.0.1 tarball and cd'ed to that untarred directory and untarred the 7.0 Intel BSPs. There must be a step I'm missing. otherwise this would not have gotten thru testing before deployment. Jim A Hi Jim, We need more specific information about the error(s) you're seeing. We've done extensive QA with 7.0.1 and meta-intel, so I imagine there must be a step you've forgotten. For example, you are using the denzil branch of meta-intel, right? Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] edison/denzil patches (post-1.1.2 and 1.2.1)
On 07/12/2012 10:43 AM, McClintock Matthew-B29882 wrote: Josh, Scott: I've pushed a set of patches for edison/denzil branch - and I may push a few more still to: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil These are all cherry-pick's and most applied cleanly and a few had some minor cleanups. Please consider these for after the point releases. I will continue to push to these branches and rebase these branches off the official upstream trees as well. Cool, this is a fairly convenient way for me to merge in these commits. Like Joshua has pointed out, as long as they are bugfixes and don't introduce significant feature additions or create backward compatibility problems, we are likely to accept them. I'm back from vacation and am catching up on a massive email backlog. Please feel free to ping me in a few days if you don't see these merged into my sgarman/denzil-next-1.2.2 branch. Thanks, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Upcoming Yocto 1.2.1 "denzil" release this week.
Hello, After a review of the QA full pass test report for Yocto 1.2.1, the release team has agreed to submit this release candidate as our final release for 1.2.1. Song Liu will organize the release readiness decision, and I expect Beth Flanagan will be able to perform the official release by the end of this week. Unfortunately the timing of this is such that I will be out of the office for the rest of this week. Saul Wold can handle any questions/concerns in my absence. Thanks so much to everyone who contributed work that went into 1.2.1! We now have 35 bugfixes and a few further enhancements to denzil since 1.2 to share with our users. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] m4 build failure - master && denzil branch
On 07/09/2012 07:51 AM, Jack Mitchell wrote: On 09/07/12 15:37, Martin Jansa wrote: On Mon, Jul 09, 2012 at 03:34:36PM +0100, Jack Mitchell wrote: So, I'm fairly sure this is a real build failure this time, again on the poky master and denzil branch. Please see attached file as the log is too big to paste. does your host use (e)glibc-2.16? if it's so, then you need this patch for m4 http://patchwork.openembedded.org/patch/31377/ Cheers, Yes it does, I saw this issue when building for the Rapsberry Pi the other day and I pulled your patches in which worked. I had assumed it was eglibc 2.16 on target that was causing issues not eglibc 2.16 on the host - hence my confusion to why the Denzil branch not building. I wonder if Saul looking into pulling these in soon? As the denzil maintainer, I'm going to watch for Khem's patches to hit master, and will have them pulled into denzil ASAP. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] running my qemu images with kvm
On 06/14/2012 11:05 AM, Robert P. J. Day wrote: embarrassingly, i only just noticed that if i want my yocto-generated qemu images to take advantage of kvm, i should add the arg "kvm" to my "runqemu" invocation, is that correct? Correct. if that's the case, might it be worth adding that note to the standard oe-init-build-env output at the bottom? or perhaps referring the user to the output of "runqemu -h" for available run-time options? Since the oe-init-build-env script gets invoked for many scenarios that don't involve running runqemu, I'm not convinced that the info is needed - it might be nice to have, but we don't want to clutter the output with too much info. at the moment, it seems awfully easy to run your qemu image without realizing you're not taking advantage of kvm. or am i misreading something? I've been running my QEMU sessions without kvm and it hasn't been a big deal. Since we do mention its use in the runqemu usage help, IMHO it's appropriately documented. I'm not sure what the status is of kvm support in the various environments that Yocto is run in, so enabling kvm by default may not be safe. Please correct me if I'm wrong. Thanks for the feedback, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] oddities in "runqemu" script
On 06/14/2012 11:39 AM, Robert P. J. Day wrote: just a few observations: 1) usage suggests this possible option: MACHINE=xyz not sure what that's supposed to accomplish, that will be rejected by the arg parsing loop, will it not? or how is one supposed to interpret that? This is a bug in the usage() documentation, thanks for reporting it. 2) the process_filename() function appears to accept a filesystem type of "ext4", but the arg parsing loop immediately after that doesn't recognize that as valid, only ext[23]. Our QEMU machines only generate .ext3 images, so that would explain why this never got tested. It's still not good that it's inconsistent, so I've filed a bug to fix that and the above issue: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2611 3) the arg parsing script clearly recognizes the option "audio", but that's not mentioned in the usage() function. That's because we're not yet ready to advertise that the audio option is fully supported, see this bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1018 which isn't even slated for work in 1.3, but rather 1.4. Thanks for these inquiries! Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] denzil bug status.
On 06/12/2012 11:20 AM, Robert P. J. Day wrote: On Tue, 12 Jun 2012, Scott Garman wrote: Hello, As we are less than a week from our intended release candidate freeze date (June 18) for the denzil point-release, I had a meeting with Richard Purdie and Saul Wold to go over the final bug list and assess the remaining work. Here is a summary of the results of that meeting. The bug numbers I'm referring to can be found on the Yocto Project bugzilla site: https://bugzilla.yoctoproject.org ... snip ... was someone working on a fix for downloading tarballs that contain a "+" in the filename, to prevent them from being downloaded repeatedly? recall the recent issue i reported WRT the "gtk+" tarball, which was continually downloaded despite it being in my local mirror. Looks like bug #2546 is tracking this: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2546 It has not been assigned a milestone, perhaps Richard can clarify if the fix is intended/appropriate for 1.2.1. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] denzil bug status.
Hello, As we are less than a week from our intended release candidate freeze date (June 18) for the denzil point-release, I had a meeting with Richard Purdie and Saul Wold to go over the final bug list and assess the remaining work. Here is a summary of the results of that meeting. The bug numbers I'm referring to can be found on the Yocto Project bugzilla site: https://bugzilla.yoctoproject.org Bug 1258 - [crownbay] Xorg eats lots of CPU time after standby STATUS: Still in progress NOTES: Tom Zanussi needs hardware to reproduce the bug, and expects to have a crownbay system in the next day or two. We will revisit this bug once he's had a chance to investigate and assess its impact. Bug 1465 - bitbake cannot fetch local files from SRC_URI when -b is used STATUS: Patch under review on oe-core ML NOTES: A patch for this was just sent out to the oe-core ML this morning, so a fix is under review. Bug 1823 - [Bealgeboard C4] keyboard could not work with 20111207 build STATUS: Just needs documentation NOTES: This appears to be a documentation issue; we will mention the required boot parameters in the release notes for 1.2.1 Bug 2069 - Clutter run failed in qemux86/qemux86_64 on ubuntu/Opensuse/Fedora STATUS: Deferred to 1.3 NOTES: This appears to be a qemugl issue rather than a bug in clutter. The fix for this is likely to be too invasive and the bug has been moved to the next major release. Bug 2328 - Some RPM package file format is not correct on Beagleboard platform STATUS: Deferred to 1.3, document case in release notes NOTES: The fixes required for this are definitely too invasive for a point-release. Rather we will document this case in the release notes. Bug 2329 - Forwarding only sometimes works from qemu connman-based images STATUS: Patch under review on oe-core ML NOTES: This is ready and in my sgarman/denzil-next branch, will be included in my next denzil pull request later today. Bug 2336 - Proxy sanity check message is getting burried STATUS: Patch under review on oe-core ML NOTES: This is ready and in my sgarman/denzil-next branch, will be included in my next denzil pull request later today. Bug 2363 - duplicated bash causes do_rootfs failed on Fedora 17 STATUS: Still in progress NOTES: Saul agreed to try to reproduce the bug on a new Fedora 17 system he's setting up today. Bug 2374 - [eglibc] mtrace should be packaged on it's own STATUS: Still in progress NOTES: We have half a fix for this but it breaks poky-tiny. Richard suggested a fix that could be applied to the poky-tiny distro config that would resolve the second half. Will be testing this ASAP. Bug 2384 - Update distro version warning to not warn about new Ubuntu/Fedora/OpenSUSE releases STATUS: Still in progress NOTES: This is a trivial fix I should have a patch out for soon. Bug 2452 - qemu Unable to find pseudo binary in /usr/bin/ STATUS: Still in progress NOTES: I need to reproduce this issue and get a closer look at it. There is some risk we may need to defer if the fix is complex. Bug 2477 - yocto-7-denzil : core-image-sato doesn't work with Atom N550 STATUS: Still in progress NOTES: Due to inactivity on this bug I have sent an email to the reporter asking for a status update. Depending on the outcome of that we may still be able to resolve it, but there is high risk we won't. Bug 2503 - task-base-extended depends on libc6 >=2.15, 2.13 is built STATUS: Still in progress NOTES: Richard has been assigned this bug and will look into it tomorrow. Significant risk we may need to defer it if the fix is complex. -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] RFC: Merging commits from into the main denzil branch
Hello all, As most of you know, I've been pulling commits into a pair of sgarman/denzil-next branches which are intended to eventually become the next Denzil point-release, 1.2.1. oe-core based branch: http://git.openembedded.org/openembedded-core-contrib/log/?h=sgarman/denzil-next poky based branch: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next So far I haven't merged or requested to merge any of these commits into the main denzil branches of oe-core and poky, for two main reasons: 1. I've only performed the most basic build testing of these branches on a desktop system, building core-image-minimal and core-image-sato for our 5 qemu machines. 2. To date, we haven't had a clear process on how to transition from the maintainer's personal branch into the official repo branch. I'd like to develop a clear and documented process on doing this that involves community feedback on the commits. Just this week I've been able to start using the Yocto autobuilder to do more comprehensive testing of my denzil-next branch, so issue #1 is finally resolved, and I've got a green build to raise my confidence level: http://autobuilder.yoctoproject.org:8010/builders/nightly/builds/462 So now to address issue #2. The goal is to incorporate community feedback, so I'm looking to get ACKs or NAKs for these commits before they go into the main denzil branch. My proposal is to send denzil pull requests to the appropriate mailing lists, and Richard can merge them into the main repo denzil branches once they've received review by the community. My goal is to send these pull requests about once per week, once I've managed to get a green build out of the Yocto autobuilder for my contrib branch. What do folks think about this? Now's your opportunity to offer feedback and influence this process. Thanks! Scott Yocto 1.2.1 release maintainer -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] runqemu qemux86
On 05/22/2012 10:45 AM, jfabernathy wrote: https://bugzilla.yoctoproject.__org/show_bug.cgi?id=2329 <https://bugzilla.yoctoproject.org/show_bug.cgi?id=2329> Scott So if I read this right, I don't need any route or bridge commands to make this work. If the bug gets fixed runqemu qemux86 should setup the environment correctly so the web-webkit should get out to the internet via the host machine connection? JIm A Correct. I'm hesitant to say this, but I'm hoping to have the bug fixed and patch submitted by the end of this week. Hopefully I haven't just jinxed myself. :) I did try it out on core-image-minimal and I can ping anything I have the IP for. Not sure how you get the DNS connections working in qeum. Since we use a static IP configuration for the QEMU sessions, /etc/resolv.conf isn't populated with a nameserver. If you enter one, it should work. I'm not sure if there is something we can/should use as a default DNS setup that would work for all our end users. OpenDNS? Google's nameservers? Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] runqemu qemux86
On 05/22/2012 10:26 AM, James Abernathy wrote: On Tue, May 22, 2012 at 1:04 PM, Scott Garman mailto:scott.a.gar...@intel.com>> wrote: On 05/22/2012 08:15 AM, James Abernathy wrote: On Tue, May 22, 2012 at 10:45 AM, Autif Khan mailto:autif.ml...@gmail.com> <mailto:autif.ml...@gmail.com <mailto:autif.ml...@gmail.com>>__> wrote: On Tue, May 22, 2012 at 7:43 AM, jfabernathy mailto:jfaberna...@gmail.com> <mailto:jfaberna...@gmail.com <mailto:jfaberna...@gmail.com>>__> wrote: > when testing an image using runqemu qemux86, can you get networking to > work?? mine comes up disabled. I want to test an application that requires > Internet access. Yes, I am able to get networking to work out of the box (bitbake core-image-sato, etc.) Internetworking does not work out of the box. This is accomplished over tun/tap devices - I do not know much about these virtual networking devices - they have never failed for me :-) The IP address of the emulated machine is 192.168.7.2 - The IP address of host machine is 192.168.7.1 You can not (out of the box) communicate with machines other than the host machine - so that would included internet etc. So, if you have an ssh server or a web-server running on the host machine - you can ssh to the host machine or browse a webpage using the browser. Alternatively, you can run a proxy server on the build machine and use it to get to the internet. You can run ifconfig to see if the network is configured properly on the emulated machine in the terminal. It should show 192.168.7.2 - if you do not see this - you do not have networking working. I can see the tap0 interface on my host at 192.168.7.1 by using ifconfig. I can also see the eth0 on the qemu machine at 192.168.7.2 However, my host has an ip of 10.0.1.54 with a AP gateway at 10.0.1.1. Somehow I need to connect the networks and I'm not sure exactly how to do that so that DNS servers get used and the traffic all flows. Jim A There is some sort of routing or IP forwarding bug in the sato images that is due to be fixed soon. One thing I've found is you can actually get out to the internet for about 30 seconds or so immediately after the image boots. My suspicion is that some conman script is killing the route after boot. core-image-minimal works consistently, and since minimal doesn't use conman, I'm guessing that is the culprit. https://bugzilla.yoctoproject.__org/show_bug.cgi?id=2329 <https://bugzilla.yoctoproject.org/show_bug.cgi?id=2329> Scott So if I read this right, I don't need any route or bridge commands to make this work. If the bug gets fixed runqemu qemux86 should setup the environment correctly so the web-webkit should get out to the internet via the host machine connection? JIm A Correct. I'm hesitant to say this, but I'm hoping to have the bug fixed and patch submitted by the end of this week. Hopefully I haven't just jinxed myself. :) Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] runqemu qemux86
On 05/22/2012 08:15 AM, James Abernathy wrote: On Tue, May 22, 2012 at 10:45 AM, Autif Khan mailto:autif.ml...@gmail.com>> wrote: On Tue, May 22, 2012 at 7:43 AM, jfabernathy mailto:jfaberna...@gmail.com>> wrote: > when testing an image using runqemu qemux86, can you get networking to > work?? mine comes up disabled. I want to test an application that requires > Internet access. Yes, I am able to get networking to work out of the box (bitbake core-image-sato, etc.) Internetworking does not work out of the box. This is accomplished over tun/tap devices - I do not know much about these virtual networking devices - they have never failed for me :-) The IP address of the emulated machine is 192.168.7.2 - The IP address of host machine is 192.168.7.1 You can not (out of the box) communicate with machines other than the host machine - so that would included internet etc. So, if you have an ssh server or a web-server running on the host machine - you can ssh to the host machine or browse a webpage using the browser. Alternatively, you can run a proxy server on the build machine and use it to get to the internet. You can run ifconfig to see if the network is configured properly on the emulated machine in the terminal. It should show 192.168.7.2 - if you do not see this - you do not have networking working. I can see the tap0 interface on my host at 192.168.7.1 by using ifconfig. I can also see the eth0 on the qemu machine at 192.168.7.2 However, my host has an ip of 10.0.1.54 with a AP gateway at 10.0.1.1. Somehow I need to connect the networks and I'm not sure exactly how to do that so that DNS servers get used and the traffic all flows. Jim A There is some sort of routing or IP forwarding bug in the sato images that is due to be fixed soon. One thing I've found is you can actually get out to the internet for about 30 seconds or so immediately after the image boots. My suspicion is that some conman script is killing the route after boot. core-image-minimal works consistently, and since minimal doesn't use conman, I'm guessing that is the culprit. https://bugzilla.yoctoproject.org/show_bug.cgi?id=2329 Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how to use video ??
On 05/09/2012 04:09 AM, 王春泽 wrote: hi,we are studying yocto now.but we met a problem. we cann't drive the video. canyou give us some advice ? thanks!! Which video? What error are you encountering? No one will be able to help you without more context about your problem. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Point-release process wiki page.
Hi all, As mentioned in the Yocto Technical Team call this morning, I have started documenting the workflow used to maintain a point-release on the wiki: https://wiki.yoctoproject.org/wiki/Yocto_Point-Release_Development_Workflow Right now most of the information there is fairly high-level, and as I refine my processes further, I'll be including things such as script snippets or git commands I end up using to manage things. I also intend to add a section on testing guidelines, as I try to move beyond just doing build tests on our QEMU architectures to doing things like testing non-gplv3 builds, poky-tiny distro, etc. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/2] yocto-kernel: use BUILDDIR to find bblayers.conf
On 05/04/2012 12:18 PM, Tom Zanussi wrote: On Fri, 2012-05-04 at 11:15 -0700, Scott Garman wrote: On 04/30/2012 12:12 PM, tom.zanu...@intel.com wrote: From: Tom Zanussi The current code assumes that builddir == srcdir/build, which it obviously isn't sometimes. Use BUILDDIR to get the actual builddir being used. Fixes [YOCTO #2219]. Signed-off-by: Tom Zanussi Merged to denzil-next, thanks! Thanks, Scott! Could you also merge the other patch that was part of this patchset? (yocto-bsp: clarify help with reference to meta-intel) Thanks for catching that - I've now merged this commit as well. http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/2] yocto-kernel: use BUILDDIR to find bblayers.conf
On 04/30/2012 12:12 PM, tom.zanu...@intel.com wrote: From: Tom Zanussi The current code assumes that builddir == srcdir/build, which it obviously isn't sometimes. Use BUILDDIR to get the actual builddir being used. Fixes [YOCTO #2219]. Signed-off-by: Tom Zanussi Merged to denzil-next, thanks! http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project 1.2.1 release plan.
On 05/01/2012 08:32 AM, Scott Garman wrote: Richard has already started pulling in some patches from master into the denzil-next branch on oe-core: http://git.openembedded.org/openembedded-core/log/?h=denzil-next I'll be merging these on an ongoing basis into my sgarman/denzil-next branch in the poky-contrib repo: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next Sorry about this folks - my denzil-next branch was based on oe-core and not poky. So I've just deleted the branch and will be re-creating it shortly. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project 1.2.1 release plan.
Hi all, I'm going to be the maintainer of the Yocto Project 1.2.1 release, and wanted to let everyone know some details about the current status of this release. Richard has already started pulling in some patches from master into the denzil-next branch on oe-core: http://git.openembedded.org/openembedded-core/log/?h=denzil-next I'll be merging these on an ongoing basis into my sgarman/denzil-next branch in the poky-contrib repo: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next The primary focus for getting patches into 1.2.1 is bugfixing, security updates, and making sure the recently released Ubuntu, Fedora, and OpenSUSE distros work with this release. All other kinds of patches (e.g, performance) will have a very high bar to reach for them to be accepted (i.e, it will have to be very clear they pose little risk to introducing more bugs or stability issues). And of course anything that breaks APIs or compatibility is off the table. It would help me out greatly if in your pull requests you could mention when you want your commit to also be included in 1.2.1. Our intention is currently to include bugfixes for these bugs in the eventual release of 1.2.1: https://bugzilla.yoctoproject.org/buglist.cgi?query_format=advanced&list_id=4572&bug_status=NEW&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&target_milestone=1.2.1 This list is not set in stone and may change at any time. My very rough guesstimate is that we will start testing release candidates for 1.2.1 in about 6-8 weeks. Thanks, and I look forward to helping to ensure that 1.2.1 is a solid and well-tested release! Scott IRC: zenlinux -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] syslinux filesystem size limitation
On 03/15/2012 06:07 AM, Joshua Immanuel wrote: Hello, In yocto I find that the live image (hddimg) is generated using syslinux (in bootimg.bbclass). But, I find there has been no check enforced to find whether the filesystem size exceeds 1 GB. The image will not boot if the hddimg size exceeds 1GB. This is due to the limitation in syslinux. How to address this issue? Is there any other alternate solution for this? Should I file a bug report for this? Yes, this sounds worthy of filing a bug. Bonus points for patch submissions to fix it. ;) Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bugzilla 4.0.3 online
On 02/24/2012 04:22 PM, Michael Halstead wrote: Bugzilla is updated and live on the new server at https://bugzilla.yoctoproject.org/. SSL is now required to connect and all page loads will use the yoctoproject.org domain. Old bookmarks should be redirected properly. If you find issues with the new version please e-mail me at mich...@yoctoproject.org or open a bug at https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Bugzilla Michael Halstead Sys Admin / Yocto Project Thanks Michael, this is a long-awaited upgrade that we're very happy to have. I can appreciate the things you had to untangle to get the upgrade to work. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how do I contribute to yocto
On 02/20/2012 06:03 AM, Joshua Immanuel wrote: Hello all, In the process of creating my custom image, I ended up writing new recipes for packages which does not exist in yocto. I think it will be useful for others. I use the edison branch for my work, and I add the new recipes to my custom layer without disturbing the edison branch. So, how do I contribute these new recipes? Read the wiki https://wiki.yoctoproject.org/wiki/Contribution_Guidelines it doesn't mention about the branch to use etc. Can someone guide me. Hi Joshua, I'd put your layer up on a git repo somewhere (GitHub?) and make sure you have a note in your layer's README file that mentions that the layer is intended for use with the edison release. If you're looking to maintain this layer for multiple releases of Yocto, it may make sense to maintain a similar branch structure - i.e, your master branch aims to build with Poky master, edison branch builds with edison, etc. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Screencast Video: Getting Started with the Yocto Project
Hi everyone, I am excited to announce a video training resource for new users of the Yocto Project. It is the "Getting Started with the Yocto Project" screencast: On Vimeo: http://vimeo.com/36450321 On YouTube: http://www.youtube.com/watch?v=zNLYanJAQ3s Direct download, Windows Media (300 MB) and Ogg (500 MB) formats: http://www.yoctoproject.org/bulk/Getting_Started_with_the_Yocto_Project.wmv http://www.yoctoproject.org/bulk/Getting_Started_with_the_Yocto_Project.ogv This half-hour screencast introduces you to the Yocto Project and explains its benefits. It also includes live demos which explain the following: * An overview of the Poky build system * How the Poky sources are organized (types of metadata and where to find it) * How to build your first Linux image and run it under emulation * An introduction to recipes and an explanation of the most common types of metadata, using actual recipe examples * An introduction to layers * Where to obtain Yocto BSPs from * How simple it is to download and enable a Yocto BSP * Where to find further project resources (documentation, mailing list, git repository, bugzilla) By the end of this screencast, a new user will understand fundamental concepts about the build system, and be able to start their exploration of the Yocto Project with a solid foundation of knowledge. I hope this screencast becomes a useful training resource to help get new users up to speed as quickly as possible with the Yocto Project. Enjoy, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find Log
On 02/14/2012 04:47 AM, James Abernathy wrote:
On Feb 14, 2012, at 4:04 AM, Lu, Lianhao wrote:
James W. wrote on 2012-02-14:
How to locate Log file while a error occur.
It's under the directory ${WORKDIR}/temp/. Actually when an error occurs, you
can find the specific log file in the output, something like.
ERROR: Logfile of failure stored in:
/intel/poky/builds/toolchain/tmp/work-shared/gcc-4.6.2+svnr181430-r22/temp/log.do_patch.15156
Best Regards,
Lianhao
I have a similar questions. If the error occurs and the console log information
scrolls too far to get back to, how do I find the error log file then? I know
what directory all the logs will be, but is there an easy way to find the one
with the error??
In Poky master, we now save the output from bitbake in cooker.log files,
kept under build/tmp/. This will be a feature of our upcoming 1.2
release of Yocto.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to re-use sstate.
On 02/06/2012 07:08 AM, Chris Larson wrote: On Mon, Feb 6, 2012 at 12:53 AM, David Nyström wrote: On 02/04/2012 05:51 AM, Scott Garman wrote: Hello, I'm trying to re-use the sstate from one build directory and move it to another. It's not working - bitbake is rebuilding *everything*. My hunch is the reason for this is because bblayers.conf must differ between the two build directories, because it uses full paths to the layer directories. By default, when you source oe-init-build-env for the first time, it generates a bblayers.conf file with full paths to the default layers, meta and meta-yocto. I thought the point of sstate was that I could copy it between build directories - or even different hosts - and save myself the effort of rebuilding everything if the remaining metadata was the same? Scott We have the same issue, I tried to setup a buildbot to warm up sstate caches over night, and let developers use this common sstate to speed up build times. Epic fail, since paths usually are not consistent. And it seems you can't even fake an "identical path" with symlinks either, bitbake detects the symlink and rebuilds everything. Afaik your BBLAYERS should not be in your signatures at all, unless something in the metadata is accessing it. For what it's worth, I reuse sstate every day, but don't use the poky/oe-core scripts (oe-init-build-env). As a follow-up to this thread, I spent a bit of time today trying to reproduce/isolate the issue, and I could not do so. Changing the paths to layers correctly rebuilt from sstate, and adding an empty layer also didn't trigger a rebuild. So I'm not sure what I saw previously, but unfortunately my original example of this is no longer available for me to work with. I apologize for causing any confusion, but it's still quite possible we have some issues - I'll definitely use bitbake-diffsig to dig deeper the next time I see it. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto in Virtualbox (Ubuntu 11.10)
On 02/09/2012 12:50 AM, cnxsoft wrote: FYI. have done some further tests with the prebuilt binaries and toolchain (yocto-eglibc-i686-i586-toolchain-gmae-1.0.tar.bz2, bzImage-2.6.37-qemux86-1.0.bin and yocto-image-minimal-dev-qemux86-1.0.rootfs.ext3). With Ubuntu 11.10 (Virtual Box), it fails with the same black screen. With Debian Squeeze 6.0.3 (inside Virtual Box), it works fine. PS: For Ubuntu, poky-qemu script to pass libGL detection. Thank you for reporting this, I have filed the following bug to track this issue: http://bugzilla.pokylinux.org/show_bug.cgi?id=1971 Are you using the default user interface (Unity) in your Ubuntu setup? Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto in Virtualbox
On 02/08/2012 07:11 PM, David Smoot wrote: On Feb 8, 2012, at 8:18 AM, cnxsoft wrote: On 08/02/2012 21:06, autif khan wrote: On Wed, Feb 8, 2012 at 3:14 AM, cnxsoft wrote: Hi, .255.0 oprofile.timer=1 " Enabling opengl So, what is the problem? Qemu starts apparently fine, but the qemu window stays black. I would try one of the pre-built images to isolate the problem between running inside virtualbox and your build. This would be much quicker to test than my "export to VMWare Player" suggestion. I'd definitely try this first. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto in Virtualbox
On 02/08/2012 06:01 PM, cnxsoft wrote: On 09/02/2012 00:00, Scott Garman wrote: On 02/08/2012 12:14 AM, cnxsoft wrote: Hi, I have build x86 qemu image using "bitbake -k core-image-sato" following the instructions given at http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html I'm running Ubuntu 11.10 in VirtualBox 4.1.6. When I run qemu, qemu starts apparently fine, but the qemu window stays black. So I'm suspecting that either it does not work in Virtualbox or I may have tochange some settings in qemu (e.g. -vga vmware). Have you installed the Virtualbox guest additions within your VM? Fwiw I've not run into any issues doing this with a Fedora 14 and Fedora 16 VM (other than the builds themselves being dog slow). I make sure to install the guest additions in all my VMs. Scott Thanks Scott. Yes, I have Virtual Box guest additions installed. My host is running Windows XP btw. And yes it was slow...the build for core-image-minimal took around 36 hours... I found a link with a Virtual Box issue (https://wiki.yoctoproject.org/wiki/Build_Appliance_Design), but it seem related to the build itself rather than an issue while running qemu. Hmmm...I'm not sure what to tell you. Really grasping for straws here - one thing you could try is to export the image and load it into VMWare Player and see if there is any difference. If not, that would implicate the guest distro (Ubuntu 11.10). Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto in Virtualbox
On 02/08/2012 12:14 AM, cnxsoft wrote: Hi, I have build x86 qemu image using "bitbake -k core-image-sato" following the instructions given at http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html I'm running Ubuntu 11.10 in VirtualBox 4.1.6. When I run qemu, qemu starts apparently fine, but the qemu window stays black. So I'm suspecting that either it does not work in Virtualbox or I may have tochange some settings in qemu (e.g. -vga vmware). Have you installed the Virtualbox guest additions within your VM? Fwiw I've not run into any issues doing this with a Fedora 14 and Fedora 16 VM (other than the builds themselves being dog slow). I make sure to install the guest additions in all my VMs. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Trying to re-use sstate.
Hello, I'm trying to re-use the sstate from one build directory and move it to another. It's not working - bitbake is rebuilding *everything*. My hunch is the reason for this is because bblayers.conf must differ between the two build directories, because it uses full paths to the layer directories. By default, when you source oe-init-build-env for the first time, it generates a bblayers.conf file with full paths to the default layers, meta and meta-yocto. I thought the point of sstate was that I could copy it between build directories - or even different hosts - and save myself the effort of rebuilding everything if the remaining metadata was the same? Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Hob 1.2 design - Settings dialogue
On 02/02/2012 02:01 PM, Joshua Lock wrote: On 02/02/12 13:51, Joshua Lock wrote: Hi Belen, Sorry this is so long, I don't know how to turn off my verbose switch. On page 4 you mention Shane's intention to have proxy settings in the UI - I just want to point out that this is usually an OS level configuration and we should be wary about how we implement it. I'd suggest we go so far as to just have a "Change system proxy settings" button which launches the OS's network configuration settings. Of course, this opens us up to potential issues around supporting the multitude of available network configuration tools on Linux but I'd suggest we start with a lowest common denominator approach and have the program behave intelligently. Explicitly we can detect whether the binary gnome-control-center and the so file /usr/lib64/control-center-1/panels/libnetwork.so exist (being clever about that path, too) and if so we can execute: "gnome-control-center display network" Which will display the network configuration (and therefore proxy) settings for stock Fedora and Ubuntu desktops. The above is all moot if we're just going to configure the proxy through sites.conf as per Saul's recent mail. Will sites.conf setup proxy settings for git, subversion, and cvs? The proxy situation is a mess under Linux. This is likely to be a non-trivial problem. http://www.yoctoproject.org/blogs/sgarman/2011/proxy-problem Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC: Hob 1.2 design
On 01/31/2012 05:39 PM, Wang, Shane wrote: Hi, all, Belen has a new video for Hob2 workflow and design. https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov Please comment. I'm pretty amazed with this. The workflow seems clear and each screen provides just the right bits of information the user would be interested in seeing. Outstanding! Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding recipes
On 01/26/2012 03:52 PM, Gary Thomas wrote: Any ideas as to why EXTRA_IMAGE_FEATURES += "hello" didn't add the hello code to the final image? EXTRA_IMAGE_FEATURES enables target *features*, not packages. To get your package added, use this in local.conf IMAGE_INSTALL += " hello " Good catch. Thanks, Gary. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding recipes
On 01/26/2012 02:04 PM, jfabernathy wrote:
On 01/26/2012 04:38 PM, Scott Garman wrote:
On 01/26/2012 01:32 PM, jfabernathy wrote:
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and
having it
included in the build I do.
For example, suppose I want to create the
meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello world
as shown in 3.1.2 Autotooled Package section of the Poky reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM =
"file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so
it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES += "helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch problem
and it just locked up there. Had to control-C out of it. Console below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA:
00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO = "poky"
DISTRO_VERSION = "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv = "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb, do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads 'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
If you look in:
ftp://ftp.gnu.org/gnu/hello/
you'll
Re: [yocto] understanding recipes
On 01/26/2012 01:32 PM, jfabernathy wrote:
On 01/26/2012 01:55 PM, Scott Garman wrote:
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and having it
included in the build I do.
For example, suppose I want to create the meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello world
as shown in 3.1.2 Autotooled Package section of the Poky reference
Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
Those examples are defined in the bitbake classes you have in your
base layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES += "helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
I got the layer created like you said, but the test had a fetch problem
and it just locked up there. Had to control-C out of it. Console below:
jim@ubuntu-x64:/build/mycdv-minimal$ bitbake helloworld
Loading cache: 100%
|###| ETA: 00:00:00
Loaded 1037 entries from dependency cache.
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "mycdv"
DISTRO = "poky"
DISTRO_VERSION = "1.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU = ""
meta
meta-yocto = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
meta-mycdv = "edison:34478f24de65dd8de8a4c8b913a1458d82dac1fa"
meta-jfa = "edison:adcf8bf7b52460b94998438e8c2bf854cdec0a80"
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 514 of 693 (ID: 4,
/home/jim/poky/meta-jfa/recipes-jfa/helloworld/helloworld.bb, do_fetch)
NOTE: package helloworld-1.0-r0: task do_fetch: Started
WARNING: Fetcher failure for URL: 'None'. Fetch command export
HOME="/home/jim"; export SSH_AGENT_PID="1413"; export
SSH_AUTH_SOCK="/tmp/keyring-2QW6yC/ssh"; export
GIT_CONFIG="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/etc/gitconfig";
export
PATH="/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/build/mycdv-minimal/tmp/sysroots/mycdv/usr/bin/crossscripts:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/usr/bin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux/sbin:/build/mycdv-minimal/tmp/sysroots/x86_64-linux//bin:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/home/jim/poky/scripts:/home/jim/poky/bitbake/bin/:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/jim/poky/scripts";
/usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P
/home/jim/yocto-downloads 'ftp://ftp.gnu.org/gnu/hello/hello-1.0.tar.gz'
failed with signal 8, output:
I don't see 1.0.tar on the ftp site. How do I control this?
If you look in:
ftp://ftp.gnu.org/gnu/hello/
you'll see which versions are available. Rename your recipe filename to
reflect the version you
Re: [yocto] understanding recipes
On 01/26/2012 08:44 AM, jfabernathy wrote:
I'm trying to understand the concept of creating a recipe and having it
included in the build I do.
For example, suppose I want to create the meta-intel/meta-cedartrail BSP
with the core-image-minimal image, but I wanted to include hello world
as shown in 3.1.2 Autotooled Package section of the Poky reference Manual.
Where do I put the recipe file? I'm guessing a recipe-jfa directory at
the same level as the meta-cedartrail recipe-core, recipe-kernel,
recipe-graphic, recipe-bsp?
Hi Jim,
The best way to do this is to create your own layer, and keep all of
your customizations there.
You'd put this in a directory, say meta-jfa with something like the
following:
meta-jfa/
meta-jfa/conf/layer.conf
meta-jfa/recipes-jfa/helloworld/helloworld.bb
where your layer.conf file would look like:
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5"
Then point your build's bblayers.conf file to include the path to your
meta-jfa/ directory.
I'm also assuming that helloworld.bb file would contain:
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
So where do the values of ${GNU_MIRROR|, and ${PV} get set correctly?
Those examples are defined in the bitbake classes you have in your base
layers.
And what does the following line do or require me to do:
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
This was answered in another post.
Is this all that is needed to get helloworld put into /usr/bin so it can
be executed at the command line when the image is booted?
You'd also need to add the helloworld package to your image file. The
simplest way to do this is to add EXTRA_IMAGE_FEATURES += "helloworld"
in your build's local.conf file.
I think the above should be accurate enough w/o testing it myself.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] normal user for Intel BSPs?
On 01/25/2012 02:18 PM, Darren Hart wrote: On 01/25/2012 09:36 AM, jfabernathy wrote: I've noticed that the meta-intel BSP come up with the default terminal, serial console user, etc. as root. What would it take to make my own BSP that was exactly the same, but the default was a not admin user, but you could su or sudo to root? I'm adding Scott G. who I believe has been working on the useradd scripts and such (to sanity check the following). I believe you should be able to setup new users by extending an image recipe with a new task to make the necessary useradd/mod etc calls on the rootfs prior to packaging it up. Scott, can you offer more detail on how that is done? Hi Jim, Darren: The useradd mechanism is for supporting custom users and groups in recipes. It sounds like what Jim may find more expedient would be to define a recipe which includes a first-boot script which creates the additional users/groups and then sets up custom ownership on the terminal, serial console user, etc. Otherwise you'd have to do this in several recipes. Using the first-boot script approach is documented here: http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#usingpoky-extend-addpkg-postinstalls Whereas using the useradd bitbake class is documented in an example recipe in meta-skeleton/recipes-skeleton/useradd/useradd-example.bb. There is also a slide deck you may find useful here: http://wiki.yoctoproject.org/wiki/images/e/e6/Custom_Users_Groups_in_Yocto1.1.pdf I'll also mention that I'm still shaking out bugs in the useradd mechanism. We have some race conditions that are complicating matters when building from sstate. So if you're using one of our stable releases, the first-boot script approach is probably your safest bet. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't build util-linux
On 01/05/2012 04:49 AM, Gary Thomas wrote: Using a freshly updated master OE Build Configuration: BB_VERSION = "1.15.0" TARGET_ARCH = "arm" TARGET_OS = "linux-gnueabi" MACHINE = "beagleboard" DISTRO = "poky" DISTRO_VERSION = "1.1+snapshot-20120105" TUNE_FEATURES = "armv7a vfp neon cortexa8" TARGET_FPU = "vfp-neon" meta meta-yocto = "master:5aabdbaff7b8be319a86c5e33cc2eb8c2e4aa2ef" | NOTE: DO PACKAGE QA | NOTE: Checking Package: util-linux-agetty | ERROR: Error executing a python function in /tmp/poky-multi/meta/recipes-core/util-linux/util-linux_2.20.1.bb: | AttributeError: 'module' object has no attribute 'check_output' Bah, sorry about this. Apparently the check_output method of the subprocess module is new in Python v2.7 (I'm 99% certain you must be using an older Python than that). I'm in the process of refactoring this to work with a more compatible API. In the meantime, please use Mark's suggested fix. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Including additional layers for doc audit?
Robert's emails about recipes in meta-demoapps missing LIC_FILES_CHKSUM made me realize that for my documentation audit runs, I'm only using the default layers Poky gives you when you source the build environment script. Shall I change this to include all meta- layers we ship with? This would add meta-demoapps and meta-skeleton (perhaps the latter is not necessary). It will of course have an impact on the statistics I've been generating. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What's the purpose of "BDIR" in oe-buildenv-internal?
On 10/27/2011 01:27 PM, Robert P. J. Day wrote: prepping to give a yocto talk to my local (ottawa) LUG next week, and was reviewing the logic of the setup starting with oe-init-build-env, and noticed in scripts/oe-buildenv-internal a test of the variable BDIR for the name of the build directory. but there's no mention of that variable in the calling oe-init-build-env, and i see no mention of it in the intro-level docs. clearly, one could use that shell env variable if one wanted to name the build directory to be used, but given that there's absolutely no explanation of it anywhere for a new user, what exactly is its purpose? rday This allows you to specify a build directory that lives elsewhere on your filesystem, rather than in poky/build. This is handy in case you want to keep the build system source tree pristine. Simply source the build init script with the desired build directory as an argument. I'm quite sure we have this documented, although BDIR isn't explicitly mentioned. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Login Username and Password on MPC8315E-RDB
On 10/26/2011 09:37 PM, Adrian Miller wrote: Hi, After I successfully load the kernel onto my board, I get this: Yocto (Built by Poky 5.0) 1.0 mpc8315e-rdb ttyS0 mpc8315e-rdb login: This is where it requests a username and password. I am wondering where can I find or set the login details. Thank you for your assistance. Unless you've specifically set it otherwise, the root account has no password - just hit Enter. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Results of the latest documentation audit, October 2011
Hello, Here are the results of the latest documentation audit, using a recent Poky master (72a1e63b67445c65954c21f5cbfab74d617a257f): 587 recipes in total 334 recipes are building documentation 252 recipes are not building documentation 7 recipes did not build, and are counted above as "not building documentation" For comparison, here were the results from my last audit (September 29): 589 recipes in total 324 recipes are building documentation 265 recipes are not building documentation 6 recipes did not build. So progress continues to be made. The lists of recipes are attached to this email. We'd like to improve the percentage of recipes that produce documentation (separated into -doc packages, of course) for our next major release (1.2, in April). Our userspace recipe maintainers should look into setting aside some time to know which of their recipes are in the "not building documentation" list and work to improve them. A lot of this is likely to be low-hanging fruit, and is easy to do when upgrading your recipes. Thanks, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center clutter cogl gobject-introspection opkg-nogpg qmmp quicky update-alternatives-dpkg acl acpid alsa-utils apt aspell at atk attr augeas autoconf automake avahi base-files base-passwd bash bc bigreqsproto bind binutils bison blktool blktrace bluez-hcidump bluez4 btrfs-tools byacc bzip2 cairo ccache chrpath clutter-box2d-1.6 clutter-gst-1.6 cmake compositeproto console-tools contacts coreutils cpio createrepo cronie cups curl damageproto dates db dbus dbus-glib dhcp diffstat diffutils directfb distcc dosfstools dpkg dri2proto e2fsprogs ed eglibc enchant ethtool expat file findutils fixesproto flac flex fontsproto foomatic-filters fotowall gail gawk gcc gcc-cross gcc-cross-initial gcc-cross-intermediate gcc-crosssdk gcc-crosssdk-initial gcc-crosssdk-intermediate gcc-runtime gccmakedep gconf-dbus gdb gdbm gdk-pixbuf genext2fs gettext ghostscript git gmp gnome-desktop gnome-doc-utils gnome-keyring gnutls gperf gpgme grep groff gssdp gst-plugin-bluetooth gst-plugins-base gstreamer gthumb gtk+ gupnp gupnp-av gypsy gzip hdparm icu imake inputproto insserv intltool iproute2 iptables iputils jpeg json-glib lame less liba52 libacpi libarchive libassuan libcanberra libcap libcheck libdaemon libdmx libevent libexif libffi libgalago libgcc libgcrypt libgdata libglade libgnome-keyring libice libidn libmpc libnewt libnfsidmap libogg liboil libpam libpcap libpcre libpng librsvg libsdl libsm libsndfile1 libsoup libsoup-2.4 libtasn1 libtirpc libtool libunique libuser libvorbis libx11 libx11-diet libx11-trim libxau libxcb libxcomposite libxcursor libxdmcp libxext libxfixes libxfontcache libxft libxi libxinerama libxml2 libxmu libxp libxpm libxrandr libxrender libxres libxscrnsaver libxslt libxt libxtst libxv libxvmc libxxf86dga libxxf86misc libxxf86vm lighttpd logrotate lsb lsof lttng-ust lzo m4 mailx make makedepend mc mdadm metacity mingetty minicom mkfontdir mkfontscale mktemp mpeg2dec mpfr msmtp mtd-utils mtools nasm ncurses neon net-tools nfs-utils ofono opensp openssh openssl opkg opkg-nogpg oprofile oprofileui pango parted patch pax pax-utils pciutils pcmciautils perl pkgconfig pm-utils popt portmap powertop ppp printproto procps psmisc pth pulseaudio python-dbus python-imaging python-pycurl python-scons qemu qt4-x11-free quilt randrproto readline recordproto renderproto resolvconf resourceproto rgb rpcbind rpm rsync rt-tests rxvt-unicode screen sed setserial shadow shared-mime-info slang speex sqlite3 strace subversion sudo sysfsutils sysklogd syslinux sysstat systemtap sysvinit tar tcl tcp-wrappers telepathy-glib telepathy-idle telepathy-mission-control texinfo tiff time ttf-bitstream-vera udev unzip usbutils util-linux valgrind videoproto vte watchdog which wireless-tools wpa-supplicant x11perf x11vnc xauth xcmiscproto xdg-utils xdpyinfo xf86-input-evdev xf86-input-keyboard xf86-input-mouse xf86-input-synaptics xf86-input-vmmouse xf86-video-intel xf86-video-vesa xf86-video-vmware xhost xinit xkbcomp xmodmap xprop xrandr xrestop xserver-kdrive xserver-xorg xserver-xorg-lite xset xtrans xvinfo xwininfo xz zip zypper alsa-lib alsa-tools apmd apr apr-util avahi-ui beecrypt binutils-cross binutils-crosssdk boost busybox calibrateproto chkconfig clutter clutter-1.6 clutter-box2d cogl connman connman-gnome consolekit cracklib cwautomacros dbus-wait dmxproto dropbear dtc eds-dbus eee-acpi-scripts eggdbus eglibc-initial eglibc-locale elfutils encodings evieext font-alias font-util fontcacheproto fontconfig formfactor freetype fstests gaku galago-daemon gamin gdb-cross glew glib-2.0 glib-networking glproto gnome-common gnome-icon-theme gnome-mime-data gnu-config gobject-introspection grub gst-ffmpeg gst-fluendo-mp3 gst-fluendo-mpegdemux gst-meta-base gst-openmax gst-plugins-bad gst-plugins-good gst-plugins-ugly gtk-doc gtk-engines gtk-sato-engine gtk-theme-tort
Re: [yocto] QEmu Script Error Checking
On 10/11/2011 08:41 AM, Jack Mitchell wrote: I have run into the following issue where the tap device is in use due to the QEmu machine unexpectedly crashing. The error I recieve is here: http://i.imgur.com/5t9U1.png (appologies for the screenshot but it wouldn't let me copy the text) Is there any leaway for more robust error checking or a way to forcibly destroy the tap node to allow a new one to be created? Hi Jack, Since qemu is being run from a parent shell script (runqemu), if qemu were to crash, I would think the parent shell script would continue on and destroy the tap device normally. Might you be killing the runqemu process instead of qemu itself? I'm not sure if there is a way we could reliably force a cleanup of tap devices when runqemu starts, because we need to support the case where multiple instances of qemu sessions are running simultaneously (each with their own tap device). Off the top of my head I think this would make the state of tap devices non-deterministic. Furthermore, we support a mode where an administrator can set up one or more tap devices, allowing the runqemu user to not need sudo privileges. So checking for the case where a tap device exists but no qemu process is running wouldn't work. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Results of the latest documentation audit, September 2011
Hello, As a data point for where we stand in ensuring our packages are producing documentation, I have a script which builds all recipes (using the output of bitbake -s, not world), and then checks that a -doc package is generated which is populated with files. A summary of the results using yesterday's master are as follows: 589 recipes in total 324 recipes are building documentation 265 recipes are not building documentation 6 recipes did not build, and are counted above as "not building documentation" For comparison, here were the results from my last audit (June 10th): 584 recipes in total 307 recipes are building documentation 277 recipes are not building documentation 20 recipes did not build So it's good to see the numbers are improving, if modestly. The lists of recipes are attached to this email. We'd like to improve the percentage of recipes that produce documentation (separated into -doc packages, of course) for our next major release (1.2, in April). Our userspace recipe maintainers should look into setting aside some time to know which of their recipes are in the "not building documentation" list and work to improve them. A lot of this is likely to be low-hanging fruit. Thanks, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center gobject-introspection opkg-nogpg qmmp quicky update-alternatives-dpkg xserver-xf86-lite acl acpid alsa-utils apt aspell at atk attr augeas autoconf automake avahi base-passwd bash bc bigreqsproto bind binutils bison blktool blktrace bluez-hcidump bluez4 btrfs-tools byacc bzip2 cairo ccache chrpath clutter-gst-1.6 cmake compositeproto console-tools contacts coreutils cpio createrepo cronie cups curl damageproto dates db dbus dbus-glib dhcp diffstat diffutils directfb distcc dosfstools dpkg dri2proto e2fsprogs ed eglibc enchant ethtool expat file findutils fixesproto flac flex fontsproto foomatic-filters fotowall gail gawk gcc gccmakedep gconf-dbus gdb gdbm gdk-pixbuf genext2fs gettext ghostscript git glib-2.0 gmp gnome-desktop gnome-doc-utils gnome-keyring gnome-vfs gnutls gperf gpgme grep groff gssdp gst-plugin-bluetooth gst-plugins-base gstreamer gthumb gtk+ gupnp gupnp-av gypsy gzip hal hdparm icu imake inputproto insserv intltool iproute2 iptables iputils jpeg json-glib lame less liba52 libacpi libarchive libassuan libcanberra libcap libcheck libdaemon libdmx libevent libexif libffi libfm libgalago libgcrypt libgdata libglade libgnome-keyring libice libidn libmpc libnewt libnfsidmap libogg liboil libpam libpcap libpcre libpng librsvg libsdl libsm libsndfile1 libsoup libsoup-2.4 libtasn1 libtirpc libtool libunique libuser libvorbis libx11 libx11-diet libx11-trim libxau libxcb libxcomposite libxcursor libxdmcp libxext libxfixes libxfontcache libxft libxi libxinerama libxml2 libxmu libxp libxpm libxrandr libxrender libxres libxscrnsaver libxslt libxt libxtst libxv libxvmc libxxf86dga libxxf86misc libxxf86vm lighttpd logrotate lsof lttng-ust lzo m4 mailx make makedepend mc mdadm metacity mingetty minicom mkfontdir mkfontscale mktemp mpeg2dec mpfr msmtp mtd-utils mtools nasm ncurses neon net-tools nfs-utils ofono opensp openssh openssl opkg opkg-nogpg oprofile oprofileui pango parted patch pax pax-utils pciutils pcmciautils perl pkgconfig pm-utils popt portmap powertop ppp printproto procps psmisc pth pulseaudio python python-dbus python-imaging python-pycurl python-scons qemu qt4-embedded qt4-x11-free quilt randrproto readline recordproto renderproto resourceproto rpcbind rpm rsync rt-tests rxvt-unicode screen sed setserial shared-mime-info slang speex sqlite3 strace subversion sudo sysfsutils sysklogd syslinux sysstat systemtap sysvinit tar tcl tcp-wrappers telepathy-glib telepathy-idle telepathy-mission-control texinfo tiff time udev unzip usbutils util-linux valgrind videoproto vte watchdog which wireless-tools wpa-supplicant x11perf x11vnc xauth xcmiscproto xdg-utils xdpyinfo xf86-input-evdev xf86-input-keyboard xf86-input-mouse xf86-input-synaptics xf86-input-vmmouse xf86-video-intel xf86-video-vesa xf86-video-vmware xhost xinit xkbcomp xmodmap xprop xrandr xrestop xserver-kdrive xserver-xf86-dri-lite xserver-xf86-lite xset xtrans xvinfo xwininfo xz zip alsa-lib alsa-tools apmd apr apr-util avahi-ui base-files beecrypt binutils-cross binutils-cross-canadian-i586 binutils-crosssdk boost busybox calibrateproto chkconfig clutter clutter-1.6 clutter-box2d clutter-box2d-1.6 connman connman-gnome consolekit cracklib cwautomacros dbus-wait dmxproto dropbear dtc eds-dbus eee-acpi-scripts eggdbus eglibc-initial eglibc-locale elfutils encodings evieext font-alias font-util fontcacheproto fontconfig formfactor freetype fstests gaku galago-daemon gamin gcc-cross gcc-cross-canadian-i586 gcc-cross-initial gcc-cross-intermediate gcc-crosssdk gcc-crosssdk-initial gcc-crosssdk-intermediate gcc-runtime gdb-cross gdb-cross-canadian-i586 glew glib-networking glproto gnome-comm
Re: [yocto] qemu boot fail(root-nfs: unknown option: mountprog=21111)
On 09/07/2011 10:49 PM, 蔡振军 wrote: > Hi ALL > > QEMU run well with a pre-build kernel image from yocto site. Now just > change the kernel to one built myself, some error information appeared > about nfs. My kernel image version is 2.6.35 configured by > versatile_defconfig. Error information as following: > > “root-nfs: unknown option: mountprog=2”,this message search nothing > on google. > > Is there something wrong with .config? Add normally is there some > special configuration I should do with kernel to fit QEMU? Hi Feye, The linux-yocto kernel has patches in it to enable booting via a userspace NFS server, which needs to use high port numbers for its mountd and nfsd daemons. You will need to include these patches in your custom kernel if you wish to continue using our userspace NFS boot method. Bruce, can you point Feye to this patchset? Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappend - Where should my file be?
On 08/11/2011 04:51 PM, Chris Tapp wrote:
I've got a linux-wrs_git.bbappend file in a layer (under poky laverne
4.0.1) that contains:
COMPATIBLE_MACHINE_Vortex86DX = "Vortex86DX"
WRMACHINE_Vortex86DX = "common_pc"
FILESEXTRAPATHS := "${THISDIR}/${PN}"
SRC_URI += " file://defconfig"
Where should the defconfig file be relative to the bbappend?
I've tried:
MyLayer
+--- recipies
+--- linux
+--- linux-wrs_git.bbappend
+--- linux-wrs_git
+--- defconfig
However, my defconfig file isn't being picked up during do_unpack:
cp: cannot stat
`/home/chris/yocto/yocto-versions/laverne-4.0.1/meta/recipes-kernel/linux/files/defconfig':
No such file or directory
It looks like this is where the file is expected.
I believe also meta/recipes-kernel/linux/linux/defconfig should also work.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] best cfg for building all of yocto?
On 07/21/2011 10:08 AM, Robert P. J. Day wrote: On Thu, 21 Jul 2011, Scott Garman wrote: On 07/21/2011 09:32 AM, McClintock Matthew-B29882 wrote: On Thu, Jul 21, 2011 at 8:29 AM, Scott Garman wrote: bitbake world should build all of the available packages that aren't explicitly excluded due to machine incompatibilities. It doesn't generate a final image though, just all of the output packages. Is there an easy way to remove a specific package from being built with running bitbake world? There are unmet dependencies: NOTE: Resolving any missing task queue dependencies ERROR: Nothing PROVIDES 'libmad' ERROR: Required build target 'libomxil' has no buildable providers. Missing or unbuildable dependency chain was: ['libomxil', 'libmad'] This happens because conf/distro/include/default-distrovars.inc excludes some recipes which are known to use commercial licenses: COMMERCIAL_LICENSE ?= "lame gst-fluendo-mp3 libmad mpeg2dec ffmpeg qmmp" If you'd like to build these recipes, set COMMERCIAL_LICENSE = "" in your local.conf. related to richard's earlier post about how to exclude packages, shouldn't the initial settings be consistent, then? either a default yocto setup should include commercial licenses, or exclude them (and their packages) entirely. it seems that running a simple "bitbake world" shouldn't just fail. I agree with Robert. I have filed bug #1262 to track this issue. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] best cfg for building all of yocto?
On 07/21/2011 09:32 AM, McClintock Matthew-B29882 wrote: On Thu, Jul 21, 2011 at 8:29 AM, Scott Garman wrote: bitbake world should build all of the available packages that aren't explicitly excluded due to machine incompatibilities. It doesn't generate a final image though, just all of the output packages. Is there an easy way to remove a specific package from being built with running bitbake world? There are unmet dependencies: NOTE: Resolving any missing task queue dependencies ERROR: Nothing PROVIDES 'libmad' ERROR: Required build target 'libomxil' has no buildable providers. Missing or unbuildable dependency chain was: ['libomxil', 'libmad'] This happens because conf/distro/include/default-distrovars.inc excludes some recipes which are known to use commercial licenses: COMMERCIAL_LICENSE ?= "lame gst-fluendo-mp3 libmad mpeg2dec ffmpeg qmmp" If you'd like to build these recipes, set COMMERCIAL_LICENSE = "" in your local.conf. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] best cfg for building all of yocto?
On 07/20/2011 10:10 PM, Kumar Gala wrote: For a new bsp/target what's the best config choice to try and build all of yocto? Is it core-image-sato? - k bitbake world should build all of the available packages that aren't explicitly excluded due to machine incompatibilities. It doesn't generate a final image though, just all of the output packages. core-image-lsb builds a significantly larger set of packages than -sato if you want a reference image that includes more packages. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] couple questions about toolchains from QS manual
On 07/15/2011 07:15 AM, Robert P. J. Day wrote: (look on the bright side -- eventually, after many, many patches, i will have nothing left to whine about.) :) I know I can speak for the team in saying we're incredibly grateful for your help in combing through our documentation. This is a great contribution to the project. Thanks! Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Results of the latest documentation audit, June 2011
Hello, As a data point for where we stand in ensuring our packages are producing documentation, I have some scripts which build all recipes (using the output of bitbake -s, not world), and then check that a -doc package is generated which is populated with files. A summary of the results using yesterday's master are as follows: 584 recipes in total 307 recipes are building documentation 277 recipes are not building documentation 20 recipes did not build, and are counted above as "not building documentation" It's the impression of Saul and I that some of the recipes which do not build are failing due to dependency issues. In this case, it's generally not from a missing dependency, but having another recipe built first which then gets picked up (e.g, during do_configure) and causes a build failure. For comparison, here were the results from last month (May 6th): 591 recipes in total 308 recipes are building documentation 283 recipes are not building documentation 31 recipes did not build The lists of recipes are attached to this email. We'd like to improve the percentage of recipes that produce documentation (separated into -doc packages, of course) for our next major release in October. Our userspace recipe maintainers should look into setting aside some time to know which of their recipes are in the "not building documentation" list and work to improve them. A lot of this is likely to be low-hanging fruit. Thanks, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center alsa-tools clutter-1.6 clutter-box2d clutter-box2d-1.6 clutter-gst-1.6 gobject-introspection json-glib libx11-diet libzypp minicom mtools mutter rpm rxvt-unicode sat-solver syslinux texinfo update-alternatives-dpkg xwininfo zypper acl acpid alsa-utils apt aspell at atk attr augeas autoconf automake avahi base-passwd bash bc bigreqsproto bind binutils bison blktool blktrace bluez-hcidump bluez4 byacc bzip2 cairo chrpath compositeproto console-tools contacts coreutils cpio createrepo cronie cups curl damageproto dates db dbus dbus-glib dhcp diffstat diffutils directfb distcc dosfstools dpkg e2fsprogs ed eglibc enchant ethtool expat file findutils fixesproto flac flex fontsproto foomatic-filters fotowall gail gawk gcc gccmakedep gconf-dbus gdb gdbm gdk-pixbuf genext2fs gettext ghostscript git glib-2.0 gmp gnome-desktop gnome-doc-utils gnome-keyring gnome-vfs gnutls gperf gpgme grep groff gssdp gst-plugins-base gstreamer gthumb gtk+ gupnp gupnp-av gypsy gzip hal hdparm icu imake inputproto insserv intltool iproute2 iptables iputils jpeg lame less liba52 libacpi libassuan libcanberra libcap libcheck libdaemon libdmx libevent libexif libffi libfm libgalago libgcrypt libgdata libglade libgnome-keyring libice libiconv libidn libmpc libnewt libnfsidmap libogg liboil libpam libpcap libpcre libpng librsvg libsm libsndfile1 libsoup libsoup-2.4 libtasn1 libtirpc libtool libunique libuser libvorbis libx11 libx11-trim libxau libxcb libxcomposite libxcursor libxdmcp libxext libxfixes libxfontcache libxft libxi libxinerama libxml2 libxmu libxp libxpm libxrandr libxrender libxres libxscrnsaver libxslt libxt libxtst libxv libxvmc libxxf86dga libxxf86misc libxxf86vm lighttpd logrotate lsof lttng-ust lzo m4 mailx make makedepend mc mdadm metacity mingetty mkfontdir mkfontscale mktemp modutils mpeg2dec mpfr msmtp mtd-utils nasm ncurses neon net-tools nfs-utils ofono opensp openssh openssl opkg opkg-nogpg oprofile oprofileui pango parted patch pax pax-utils pciutils pcmciautils perl pkgconfig pm-utils popt portmap powertop ppp printproto procps psmisc pth pulseaudio python python-dbus python-imaging python-pycurl python-scons qemu qt4-embedded qt4-x11-free quilt randrproto readline recordproto renderproto rpcbind rsync screen sed setserial shared-mime-info slang speex sqlite3 strace subversion sudo sysfsutils sysklogd sysstat systemtap sysvinit tar tcl tcp-wrappers telepathy-glib telepathy-idle telepathy-mission-control tiff time udev unzip usbutils util-linux valgrind videoproto vte watchdog which wireless-tools wpa-supplicant x11perf x11vnc xauth xcmiscproto xdg-utils xdpyinfo xf86-input-evdev xf86-input-keyboard xf86-input-mouse xf86-input-synaptics xf86-input-vmmouse xf86-video-intel xf86-video-vesa xf86-video-vmware xhost xinit xkbcomp xmodmap xprop xrandr xrestop xserver-kdrive xserver-xf86-dri-lite xserver-xf86-lite xset xtrans xvinfo xz zip alsa-lib alsa-tools apmd apr apr-util base-files beecrypt binutils-cross binutils-cross-canadian-i586 binutils-crosssdk bluez-dtl1-workaround boost busybox calibrateproto chkconfig clutter clutter-1.6 clutter-box2d clutter-box2d-1.6 clutter-gst-1.6 connman connman-gnome consolekit cracklib cwautomacros dbus-wait dmxproto dri2proto dropbear dtc eds-dbus eee-acpi-scripts eggdbus eglibc-initial elfutils encodings evieext external-python-tarball font-alias font-util fontcacheproto fontconfig formfactor freet
Re: [yocto] Results of latest documentation audit, May 2011
On 05/06/2011 02:36 PM, Darren Hart wrote: On 05/06/2011 01:29 PM, Scott Garman wrote: Hello, As a data point for where we stand in ensuring our packages are producing documentation, I have some scripts which build all recipes (using the output of bitbake -s, not world), and then check that a -doc package is generated which is populated with files. A summary of the results using yesterday's master are as follows: 591 recipes in total 308 recipes are building documentation 283 recipes are not building documentation 31 recipes did not build (and are counted as not building documentation above). The lists of recipes are attached to this email. We'd like to improve the percentage of recipes that produce documentation (separated into -doc packages, of course) for our next major release in October. Our userspace recipe maintainers should look into setting aside some time to know which of their recipes are in the "not building documentation" list and work to improve them. A lot of this is likely to be low-hanging fruit. I see "linux-*" in the list. What sort of documentation are we looking for? The linux-image* packages in Ubuntu, for example, include a changelog and a copyright. I'm not particularly concerned about the kernel packages. I think we can ignore it. I'll update my script to not report these recipes. The main goal is to ensure that man pages and the like are being generated for userspace applications. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Results of latest documentation audit, May 2011
Hello, As a data point for where we stand in ensuring our packages are producing documentation, I have some scripts which build all recipes (using the output of bitbake -s, not world), and then check that a -doc package is generated which is populated with files. A summary of the results using yesterday's master are as follows: 591 recipes in total 308 recipes are building documentation 283 recipes are not building documentation 31 recipes did not build (and are counted as not building documentation above). The lists of recipes are attached to this email. We'd like to improve the percentage of recipes that produce documentation (separated into -doc packages, of course) for our next major release in October. Our userspace recipe maintainers should look into setting aside some time to know which of their recipes are in the "not building documentation" list and work to improve them. A lot of this is likely to be low-hanging fruit. Thanks, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center alsa-tools clutter-box2d clutter-gst-1.4 eds-tools external-csl-toolchain external-poky-toolchain gail gcc-cross-kernel-3.4.4 glibc glibc-initial gobject-introspection gst-openmax gst-plugins-ugly libomxil libx11-diet libzypp matchbox-theme-sato-2 matchbox-wm-2 minicom modutils-cross mtools puzzles rpm sat-solver texinfo update-alternatives-dpkg web xwininfo yaffs2-utils zaurusd zypper acl acpid alsa-utils apt aspell at atk attr augeas autoconf automake avahi base-passwd bash bc bigreqsproto bind binutils bison blktool blktrace bluez-hcidump bluez4 byacc bzip2 cairo chrpath clutter clutter-gst-1.6 compositeproto console-tools contacts coreutils cpio createrepo cronie cups curl damageproto dates db dbus dbus-glib dhcp diffstat diffutils directfb distcc dosfstools dpkg e2fsprogs ed eglibc enchant ethtool expat file findutils fixesproto flac flex fontsproto foomatic-filters fotowall gawk gcc gccmakedep gconf-dbus gdb gdbm gdk-pixbuf genext2fs gettext ghostscript git glib-2.0 gmp gnome-desktop gnome-doc-utils gnome-keyring gnome-vfs gnutls gperf gpgme grep groff gssdp gst-plugins-base gstreamer gthumb gtk+ gupnp gupnp-av gypsy gzip hal hdparm icu imake inputproto insserv intltool iproute2 iptables iputils jpeg json-glib less liba52 libacpi libassuan libcanberra libcap libcheck libdaemon libdmx libevent libexif libffi libfm libgalago libgcrypt libgdata libglade libgnome-keyring libice libiconv libidn libmpc libnewt libnfsidmap libogg liboil libpam libpcap libpcre libpng librsvg libsm libsndfile1 libsoup libsoup-2.4 libtasn1 libtirpc libtool libunique libuser libvorbis libx11 libx11-trim libxau libxcb libxcomposite libxcursor libxdmcp libxext libxfixes libxfontcache libxft libxi libxinerama libxml2 libxmu libxp libxpm libxrandr libxrender libxres libxscrnsaver libxslt libxt libxtst libxv libxvmc libxxf86dga libxxf86misc libxxf86vm lighttpd logrotate lsof lttng-ust lzo m4 mailx make makedepend mc mdadm metacity mingetty mkfontdir mkfontscale mktemp modutils mpfr msmtp mtd-utils nasm ncurses neon net-tools nfs-utils ofono opensp openssh openssl opkg opkg-nogpg oprofile oprofileui pango parted patch pax pax-utils pciutils pcmciautils perl pkgconfig pm-utils popt portmap powertop ppp printproto procps psmisc pth pulseaudio python python-dbus python-imaging python-pycurl python-scons qemu qt4-embedded qt4-x11-free quilt randrproto readline recordproto renderproto rpcbind rsync rxvt-unicode screen sed setserial shared-mime-info slang speex sqlite3 strace subversion sudo sysfsutils sysklogd syslinux sysstat systemtap tar tcl tcp-wrappers telepathy-glib telepathy-idle telepathy-mission-control tiff time udev unzip usbutils util-linux valgrind videoproto vte watchdog which wireless-tools wpa-supplicant x11perf x11vnc xauth xcmiscproto xdg-utils xdpyinfo xf86-input-evdev xf86-input-keyboard xf86-input-mouse xf86-input-synaptics xf86-input-vmmouse xf86-video-intel xf86-video-vesa xf86-video-vmware xhost xinit xkbcomp xmodmap xprop xrandr xrestop xserver-kdrive xserver-xf86-dri-lite xserver-xf86-lite xset xtrans xvinfo xz zip alsa-lib alsa-tools apmd apr apr-util base-files beecrypt binutils-cross binutils-cross-canadian-i586 binutils-crosssdk bluez-dtl1-workaround boost busybox calibrateproto chkconfig clutter-1.4 clutter-1.6 clutter-box2d clutter-box2d-1.6 clutter-gst-1.4 clutter-gtk-1.4 connman connman-gnome consolekit cracklib cwautomacros dbus-wait dmxproto dri2proto dropbear dtc eds-dbus eds-tools eee-acpi-scripts eggdbus eglibc-initial elfutils encodings evieext external-csl-toolchain external-poky-toolchain external-python-tarball font-alias font-util fontcacheproto fontconfig formfactor freetype fstests gail gaku galago-daemon gamin gcc-cross gcc-cross-canadian-i586 gcc-cross-initial gcc-cross-intermediate gcc-cross-kernel-3.4.4 gcc-crosssdk gcc-crosssdk-initial gcc-crosssdk-intermediate gcc-runtime gdb-cross gdb-cross-canadian-i586 glew
Re: [yocto] Poky release is 5.0 "Bernard" confusion
On 04/18/2011 10:22 AM, Hart, Darren wrote: On 04/10/2011 01:24 AM, Wolfgang Denk wrote: Dear Scott Garman, In message<4da127f6.3010...@intel.com> you wrote: This suggests to me that your local git repository isn't up to date. The tag has been moved at least once since it was created, and it sounds like your repository is behind the most recent move of the tag. You are ... moving release tags? Grrrgh!!! Oh, that surprises me as well. What is the justification here? Generally speaking, I'd expect the tags to be static. I'm cc'ing Beth on this thread, since I was not involved in the tag move. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Poky release is 5.0 "Bernard" confusion
On 04/09/2011 05:04 AM, Robert Berger wrote: Hi, Can someone please tell me if there is a tag in git://git.pokylinux.org/poky.git which corresponds to the official release tarball and what it is? What puzzles me is that if you check out bernard-5.0 from the git repository it does not correspond to http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.tar.bz2 OK, it does not seem to be anything seriously different between the two: # modified: README.hardware # modified: documentation/adt-manual/adt-prepare.xml # modified: documentation/yocto-project-qs/yocto-project-qs.xml # modified: meta/conf/distro/poky.conf ... but you might want to synchronize since some people prefer to work from git and others from the tarball. As an example the README.hardware found in the tarball suggests to build and update u-boot for the Freescale MPC8315E-RDB, which does not exist in the git repo. This suggests to me that your local git repository isn't up to date. The tag has been moved at least once since it was created, and it sounds like your repository is behind the most recent move of the tag. Note: if you use git fetch --all, that will fetch new tags but doesn't update old ones that have moved - you need to explicitly run git fetch --tags. HTH, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure 2 - poky-image-lsb-sdk-beagleboard with bernard-5.0
On 03/22/2011 03:08 PM, Robert Berger wrote: I think it boils down to the fact, that meta/recipes-core/base-files/base-files/sysctl.conf meta/recipes-extended/procps/procps-3.2.8/sysctl.conf are different and both should end up at the rootfs. I guess I could just remove the procps package. But how to resolve this in a more elegant way and how did the autobuilder get away with it? Hi Robert, Could you please report this in our bugzilla? I seem to recall running into something like this too. http://bugzilla.pokylinux.org Thanks, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure - poky-image-lsb-sdk-beagleboard
On 03/21/2011 06:00 AM, Robert Berger wrote: Hi, I don't know if I'm posting to the right mailing list, but just wanted you to know that the latest and greatest from git fails when trying to build poky-image-lsb-sdk for beaglebaord. | make[3]: Leaving directory `/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/docs' | [ -d sgml ] || mkdir sgml | cd sgml; sgml2txt .././sgml/libuser.sgml | Processing file .././sgml/libuser.sgml | troff: fatal error: can't find macro file s | fmt_txt::postASP: Empty output file, error when calling groff. Aborting... | make[2]: *** [sgml/libuser.txt] Error 1 | make[2]: Leaving directory `/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/docs' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1' | make: *** [all] Error 2 | FATAL: oe_runmake failed | ERROR: Function 'do_compile' failed (see /work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/temp/log.do_compile.5485 for further information) NOTE: package libuser-0.57.1-r1: task do_compile: Failed ERROR: Task 1822 (/work/rber/poky/meta/recipes-extended/libuser/libuser_0.57.1.bb, do_compile) failed with exit code '1' Hi Robert, I'm guessing you're building on a Debian-based host distro. Please ensure both the groff and groff-base packages are installed. We just recently fixed our Quick Start guide to include the groff package dependency for Debian-based hosts, but it appears it hasn't been pushed out to our production web site yet. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Master build error caused a small typo by commit today : fetch2: unpack revision
On 02/12/2011 02:38 PM, Mark Hatle wrote: On 2/12/11 1:17 PM, Gary Thomas wrote: On 02/12/2011 12:08 PM, Koen Kooi wrote: Op 12 feb 2011, om 19:09 heeft Mark Hatle het volgende geschreven: On 2/12/11 3:30 AM, Cui, Dexuan wrote: Hi Mark, As Liping said, the following change breaks building xorg-minimal-fonts as destdir is not correct. Can you please explain the actual different between cp and tar here? I think "cp -p" is similar to "tar -x -p" here? We can revert the change. But the reason for it is tar preserves hard links, while cp does not. The problem is that people can hit things like this: | NOTE: Unpacking /OE/tentacle/sources/angstrom-layers/BSP/TI/recipes-bsp/linux/linux-omap-psp-2.6.32/beagleboard/defconfig to /OE/tentacle/build/tmp-angstrom_2010_x/work/beagleboard-angstrom-linux-gnueabi/linux-omap-psp-2.6.32-r99+gitr5fc29e7b2a76a64a739f857858ef0b98294aa155/ | ERROR: Error executing a python function in /OE/tentacle/sources/angstrom-layers/BSP/TI/recipes-bsp/linux/linux-omap-psp_2.6.32.bb: | TypeError: %d format: a number is required, not str | | ERROR: The stack trace of python calls that resulted in this exception/failure was: | ERROR: File "base_do_unpack", line 19, in | ERROR: | ERROR: File "base_do_unpack", line 14, in base_do_unpack | ERROR: | ERROR: File "/OE/tentacle/sources/bitbake/lib/bb/fetch2/__init__.py", line 1015, in unpack | ERROR: ud.method.unpack(ud, root, self.d) | ERROR: | ERROR: File "/OE/tentacle/sources/bitbake/lib/bb/fetch2/__init__.py", line 724, in unpack | ERROR: cmd = 'tar -cf - -C "%d" -ps . | tar -xf - -C "%s/%s/"' % (file, rootdir, destdir) Does not changing this "%d" to "%s" work? Yes, this is the correct fix. Nobody has been around today to push the fix into the tree however. It was a simple typo. I managed to catch Richard on IRC about an hour ago and he pushed a fix to master. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Documentation audit - initial results.
Hello, I thought I'd share the initial results from the documentation audit I've been doing. I count a recipe as generating documentation if it creates a -doc output package which is populated with files (as opposed to an empty directory tree). Using this metric, and building recipes as obtained from bitbake -s for qemux86, I've obtained the following numbers: 302 recipes are producing documentation 285 recipes do not currently produce documentation 22 recipes failed to build I did manage to filter out from this analysis a number of obvious recipe filename patterns: task-/meta-/-native/-nativesdk/-image. That said, there are still some false negatives in the "documentation_missing" list. For example, our plethora of gcc-related recipes do not produce documentation and instead associate it with the primary recipe (gcc), and so on. I will be continuing to look into fixing recipes with missing documentation that *should* be providing it as time goes on, but this gives us a good baseline to start with. To keep track of this baseline, I will be coordinating with Saul sometime soon to add a new (Yocto is not a) distro tracking field to all recipes. This field will be named RECIPE_DOC_AUDIT_STATUS_pn- and will be "red" for recipes that are either missing documentation or (as you add new recipes) have not been audited. The status will be "green" for recipes that either produce documentation or it's been confirmed that the recipe does not need to build documentation. I'd prefer not to further complicate the tracking field, but will consider suggestions from Saul or Richard if finer-grained detail is needed. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center acl acpid alsa-utils apt aspell at atk attr augeas autoconf automake avahi base-passwd bash bc bigreqsproto bind binutils bison blktool blktrace bluez-hcidump bluez4 byacc bzip2 cairo chrpath compositeproto console-tools contacts coreutils cpio createrepo cronie cups curl damageproto dates db dbus dbus-glib dhcp diffstat diffutils directfb distcc dosfstools dpkg e2fsprogs ed eglibc enchant ethtool expat file findutils fixesproto flac flex fontsproto fotowall gawk gcc gccmakedep gconf-dbus gdb gdbm gdk-pixbuf genext2fs gettext glib-2.0 gmp gnome-desktop gnome-doc-utils gnome-keyring gnome-vfs gnutls gperf gpgme grep groff gssdp gst-plugins-base gstreamer gthumb gtk+ gupnp gupnp-av gypsy gzip hal hdparm icu imake inputproto insserv intltool iproute2 iptables jpeg less liba52 libacpi libassuan libcanberra libcap libcheck libdaemon libdmx libevent libexif libffi libfm libgalago libgcrypt libgdata libglade libgnome-keyring libice libidn libmpc libnfsidmap libogg liboil libpam libpcap libpcre libpng librsvg libsm libsndfile1 libsoup libsoup-2.4 libtasn1 libtirpc libtool libunique libuser libvorbis libx11 libx11-trim libxau libxcb libxcomposite libxcursor libxdmcp libxext libxfixes libxfontcache libxft libxi libxinerama libxml2 libxmu libxp libxpm libxrandr libxrender libxres libxscrnsaver libxslt libxt libxtst libxv libxvmc libxxf86dga libxxf86misc libxxf86vm lighttpd logrotate lsof lttng-ust m4 mailx make makedepend mc mdadm metacity mingetty minicom mkfontdir mkfontscale mktemp modutils mpfr msmtp mtd-utils mtools nasm ncurses neon net-tools nfs-utils ofono opensp openssh openssl opkg opkg-nogpg oprofile oprofileui pango parted patch pax pax-utils pciutils pcmciautils perl pkgconfig pm-utils popt portmap powertop ppp printproto procps psmisc pth pulseaudio python python-dbus python-imaging python-pycurl python-scons qemu qt4-embedded qt4-x11-free quilt randrproto readline recordproto renderproto rpcbind rpm rsync screen sed setserial shared-mime-info speex strace subversion sudo sysfsutils sysklogd syslinux sysstat systemtap talloc tar tcl tcp-wrappers telepathy-glib telepathy-idle telepathy-mission-control texinfo tiff time udev unzip usbutils util-linux valgrind videoproto vte watchdog which wireless-tools wpa-supplicant x11perf x11vnc xauth xcmiscproto xdpyinfo xextproto xf86-input-evdev xf86-input-keyboard xf86-input-mouse xf86-input-synaptics xf86-input-vmmouse xf86-video-intel xf86-video-vesa xf86-video-vmware xhost xinit xkbcomp xmodmap xprop xrandr xrestop xserver-kdrive xserver-xf86-dri-lite xserver-xf86-lite xset xtrans xvinfo xwininfo xz zip zypper adt-installer alsa-lib alsa-tools apmd apr apr-util base-files beecrypt binutils-cross binutils-cross-canadian-i586 binutils-crosssdk bluez-dtl1-workaround boost busybox calibrateproto clutter clutter-1.4 clutter-box2d clutter-gst-1.4 clutter-gtk-1.4 connman connman-gnome consolekit cracklib cwautomacros dbus-wait dmxproto dri2proto dropbear dtc eds-dbus eds-tools eee-acpi-scripts eggdbus eglibc-initial elfutils encodings evieext external-csl-toolchain external-poky-toolchain external-python-tarball font-alias font-util fontcacheproto fontconfig formfactor freetype fs
Re: [yocto] Eclipse Plugin Yocto Project Settings
On 01/21/2011 01:48 AM, Diego Sueiro wrote: Jessica, Here is the first output messages from poky-extract-sdk command: Creating directory qemuarm Extracting rootfs tarball using pseudo... /home/dev/yocto/poky-4.0-build/tmp/sysroots/i686-linux/usr/bin/pseudo -P /home/dev/yocto/poky-4.0-build/tmp/sysroots/i686-linux/usr tar -C "qemuarm" -xjf "poky-4.0-build/tmp/deploy/images/poky-image-sato-qemuarm.tar.bz2" pseudo: Couldn't open qemuarm/var/pseudo/pseudo.pid: No such file or directory Thanks Diego for this information. You've uncovered a bug which I've just filed: http://bugzilla.pokylinux.org/show_bug.cgi?id=670 ...and hope to have fixed by the end of today in Poky master (and queued for inclusion in the Laverne point-release coming up). As a workaround, you should be able to use a full pathname when specifying the installation directory to the poky-extract-sdk script. Relative paths are broken. Scott -- Scott Garman Embedded Linux Distro Engineer - Yocto Project ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Libtoo sysrootl issue when testing machine specific sysroot
On 01/10/2011 07:15 PM, Xu, Dongxiao wrote: Hi Richard, When testing the machine specific sysroot patchset for atom-pc and emenlow machines, it exposed a libtool issue that, after the built of "Machine A", and then try to build "Machine B" of the same architecture, those "-L" paths generated by libtool still points to the "Machine A" sysroot, which is definitely not correct and may have issues. Thanks Donxiao for the info. I will make sure to test this scenario before submitting my libtool 2.4 sysroot support to ensure it is resolved. Scott -- Scott Garman Embedded Linux Distro Engineer - Yocto Project ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] Autobuilder fixes and added functionality
On 01/05/2011 08:30 AM, Flanagan, Elizabeth wrote: 3) BuildBot 0.8.2 unfortunately suffers from buildbot bug #1697 on my system, making it not very useful (as you can't view any of the build logs through the web interface). It's fixed in 0.8.3. More details: http://trac.buildbot.net/ticket/1697 I hadn't run into this, so thanks for pointing it out. I'm tempted to wait for 0.8.3p1 which should have the fix for this, rather than trying to pull the fix out to patch 0.8.2 Hi Beth, Do you want me to merge this patchset into master now, or should I wait for a respin based on Buildbot 0.8.3p1 (which should be out by the end of the week, I think)? Scott -- Scott Garman Embedded Linux Distro Engineer - Yocto Project ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/3] Consolidate Pull Requests for Autobuilder
On 12/21/2010 09:17 AM, Beth Flanagan wrote: Scott, This pull request updates the buildbot installer to support BuildBot 0.8.3, which was released yesterday, as well as updated build helper scripts and a new pokyABConfig.py which adds a swabber testing target,implements all current autobuilder build arches and lastly, implements sanity testing. The buildbot installer script has been re-written in python and an INSTALL file added to explain the new installation process. I've tested it on Ubuntu 10.10 and openSUSE 11.3, and would appreciate anyone who has a different system letting me know their experiences with it (good and bad). I've also incorporated a fix to poky-autobuild that sources the correct env script and added some missing build helper scripts, based off of what is actually on the autobuilder. -b Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: eflanagan/bb-0.8.3 Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=eflanagan/bb-0.8.3 Thanks, Beth Flanagan --- Beth Flanagan (3): Upgrade to Buildbot 0.8.3: scripts/poky-setup-autobuilder Adding new scripts to reflect a real autobuilder Change to poky-autobuild to source correct file: INSTALL | 55 +++ README |6 +- scripts/poky-autobuild | 39 ++- scripts/poky-autobuild-cleanoutput |6 +- scripts/poky-autobuild-copy-images | 458 +++ scripts/poky-autobuild-generate-release-external | 220 + scripts/poky-autobuild-generate-release-internal | 232 ++ scripts/poky-autobuild-generate-sources-tarball | 54 +++ scripts/poky-autobuild-postprocess |6 +- scripts/poky-autobuild-preamble | 58 +++ scripts/poky-autobuild-rename-release-images | 128 ++ scripts/poky-autobuild-sanitytest| 58 +++ scripts/poky-output-sort | 117 + scripts/poky-preserve-work-dir | 26 +- scripts/poky-setup-autobuilder | 514 +++--- scripts/pokyABConfig.py | 469 +++- scripts/run-on-buildset-success | 11 + 17 files changed, 2154 insertions(+), 303 deletions(-) create mode 100644 INSTALL create mode 100755 scripts/poky-autobuild-copy-images create mode 100755 scripts/poky-autobuild-generate-release-external create mode 100755 scripts/poky-autobuild-generate-release-internal create mode 100755 scripts/poky-autobuild-generate-sources-tarball create mode 100755 scripts/poky-autobuild-preamble create mode 100755 scripts/poky-autobuild-rename-release-images create mode 100755 scripts/poky-autobuild-sanitytest create mode 100755 scripts/poky-output-sort create mode 100755 scripts/run-on-buildset-success After a few iterations with Beth, I have now pulled this into poky-autobuilder master. Thanks Beth! Scott -- Scott Garman Embedded Linux Distro Engineer - Yocto Project ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [poky] Recipe Updating Status and call to action
On 12/15/2010 06:40 PM, Tian, Kevin wrote: On the other hand, along with this I realize that there's one area we need further discuss. How often should we upgrade packages in a given release cycle? MeeGo only does once. For Yocto we want to keep our recipes in cutting-edge which is why we schedule two upgrade windows in M2 and M3 this time. I'd like to question this. Is the goal for Poky/Yocto to track the bleeding-edge releases of software, or is the goal to be a well-tested and stable foundation for embedded software applications? Upgrading a recipe within a couple of weeks of its release may end up using more of our resources if/when we encounter new bugs that were introduced in the new release. Or worse, if we don't encounter them during distro builds and then our users take our release and discover them for themselves. I'm not saying we need to be as conservative as long-term-support enterprise Linux distros, but IMHO I think racing to always upgrade our recipes to versions released a handful of weeks ago can be counterproductive in many situations. A policy I might put forward for consideration is this: recipe upgrades are done once per release cycle, and upstream versions that have come out within the last 30 days should not be upgraded unless we have a really good reason for doing so. Scott -- Scott Garman Embedded Linux Distro Engineer - Yocto Project ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Add extra parameters for qemu script
On 12/14/2010 02:27 PM, Scott Garman wrote: On 12/13/2010 07:41 PM, Ke, Liping wrote: Hi, Scott I have updated the patch and tested with poky-tree mode (arm, x86). Since kvm and serial needs special processing, so for avoiding repeating the code, I will exclude serial and kvm in permitted extra-option, user need to use (serial, kvm) it they want to use it. For "<-m XXX>" options, I will keep the original logic. If it's arm, the> 128M memory will be forced back to 128M. It's the high-level user's responsibility to make sure other params are valid. Any problem, just let me know. Thanks a lot for your help! Thanks for the patch, Criping. This patch includes the addition of a do_configure_prepend step for the libxfixes recipe? That looks like some debugging info crept in that may not have been intended. In the usage() function, please use $MYNAME instead of $0 for consistency - see the other help echo lines. The rest of the patch looks ok. Please respin one last time with the above minor changes and I'll accept it. One final thing - when you resubmit your patch this time, could you use the create-pull-request/send-pull-request scripts? That way the patch can be pulled in by Richard or Saul with minimal effort, and it will help ensure you get proper credit in the commit log. Scott -- Scott Garman Embedded Linux Distro Engineer - Yocto Project ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Add extra parameters for qemu script
On 12/13/2010 07:41 PM, Ke, Liping wrote: Hi, Scott I have updated the patch and tested with poky-tree mode (arm, x86). Since kvm and serial needs special processing, so for avoiding repeating the code, I will exclude serial and kvm in permitted extra-option, user need to use (serial, kvm) it they want to use it. For "<-m XXX>" options, I will keep the original logic. If it's arm, the> 128M memory will be forced back to 128M. It's the high-level user's responsibility to make sure other params are valid. Any problem, just let me know. Thanks a lot for your help! Thanks for the patch, Criping. This patch includes the addition of a do_configure_prepend step for the libxfixes recipe? That looks like some debugging info crept in that may not have been intended. In the usage() function, please use $MYNAME instead of $0 for consistency - see the other help echo lines. The rest of the patch looks ok. Please respin one last time with the above minor changes and I'll accept it. Thanks, Scott -- Scott Garman Embedded Linux Distro Engineer - Yocto Project ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bug Verify
On 12/13/2010 01:20 AM, Yu, Ke wrote: Hi, I hate to raise this question, but there is still bunch of bugs that is fixed but not verified. According to the process, it is reporter's responsibility to verify the bug, so could I ask the reporter's help on this? Process is sometime tedious but helpful to quality assurance. Thanks a lot for your effort. I have now verified all my bugs. However, the process doesn't seem right to me. As the person who fixed the bug, presumably I performed verification that my fix actually works, which is why I marked the bug as fixed to begin with. At every other company I've been with, bug verification is performed by the QA team - and I think the purpose of it is to ensure someone other than the developer who fixed the bug can independently verify the bug is indeed resolved. A second pair of eyes can spot new problems more easily. JMO, Scott -- Scott Garman Embedded Linux Distro Engineer - Yocto Project ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Add extra parameters for qemu script
On 12/12/2010 05:43 PM, Ke, Liping wrote: I tend to feel that this approach is more flexible, and scales better than having to support each and every qemu option with our own script syntax. Is this acceptable, or should we continue to support our own custom options in addition to Criping's new approach? My gut feeling is that having some simplified way to trigger possibly complex option combinations is still desirable but adding a way to pass additional custom commandline is equally good. This gives us the maximum flexibility moving forwards but keeps the script easy to use? Hi, Scott So the conclusion is that I should keep the old (serial nographic) option while adding the new "<-XXX -XXX -XXX>" option? OK. I will send out the modified patch to you for review later. Yes, please respin the patch with those changes. Thanks! Scott -- Scott Garman Embedded Linux Distro Engineer - Yocto Project ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Add extra parameters for qemu script
On 12/09/2010 12:44 AM, Ke, Liping wrote: Hi, Scott The patch is in the attachment for your review. Below is some notes: 1) Basically I wouldn't like to change any logic of the original code. 2) -serial stdio and -nographic options are removed since they're be covered by the extra parameters. 3) User input would be $poky-qemu qemux86 "<-nographic -m 300>" 4) -m input will be checked still. If it exceeds 128 for arm, it will be changed back to 128M, same logic as before. And after parsing, -m option will be removed and replaced by Kernel options mem=128M for avoiding some instability issue. Generally I modified very few, just add an extra parameters with least intrusion of Current logic. Any comments are welcomed. I will conduct more test with latest code in parallel. Hi Criping, Thanks for the patch. Overall I think this looks good. However, one thing I feel the need to run by Richard, as he expressed some preferences with how the poky-qemu script would work with regard to options. Richard: Criping's patch would remove the standalone options we had to the poky-qemu script (e.g, nographic, serial) and instead requires the user to specify them in one command option which can take any qemu command switch. So for example: poky-qemu qemux86 nographic would become: poky-qemu qemux86 "<-nographic>" The benefit of this is that this allows the user to specify any qemu option they wish. Previously they were limited by the options we allowed them to specify (which were quite limited). I tend to feel that this approach is more flexible, and scales better than having to support each and every qemu option with our own script syntax. Is this acceptable, or should we continue to support our own custom options in addition to Criping's new approach? Scott -- Scott Garman Embedded Linux Distro Engineer - Yocto Project ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] param format about qeme extra options parse in
On 12/06/2010 11:29 PM, Ke, Liping wrote: Hi, Jessica& Scott I am now look...@the task of User specified qemu config support, desc " We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake" Currently, for the user experiences, the param parsing is without specific ordering. So the parsing shell code would be somewhat fixed. Since we're needing to append other user options directly, the options vary greatly. So my plan is all user options are put into "" and read in as one parameters for easier processing in the shell script, for example: ./poky-qemu qemuarm qemuarm.bin unfs_dir serial "-smp -hda /dev/myfda_file -m 256" (extra options for advance user) How do you think of it? All extra options are given within "" as one parameter. Sounds reasonable to me. Scott -- Scott Garman Embedded Linux Distro Engineer - Yocto Project ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
