Re: [yocto] YPDD access code.

2013-01-16 Thread Scott Garman

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.

2013-01-16 Thread Scott Garman

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

2013-01-01 Thread Scott Garman

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"

2013-01-01 Thread Scott Garman

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

2012-12-26 Thread Scott Garman

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

2012-12-11 Thread Scott Garman
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.

2012-12-03 Thread Scott Garman

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.

2012-12-02 Thread Scott Garman

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

2012-12-02 Thread Scott Garman
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

2012-12-02 Thread Scott Garman
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.

2012-12-02 Thread Scott Garman

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

2012-11-29 Thread Scott Garman

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

2012-11-16 Thread Scott Garman

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

2012-11-16 Thread Scott Garman

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

2012-11-15 Thread Scott Garman

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

2012-10-02 Thread Scott Garman

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

2012-09-24 Thread Scott Garman
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

2012-09-12 Thread Scott Garman

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

2012-09-12 Thread Scott Garman

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?

2012-08-31 Thread Scott Garman

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

2012-08-24 Thread Scott Garman

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

2012-08-08 Thread Scott Garman

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

2012-08-08 Thread Scott Garman

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

2012-08-08 Thread Scott Garman

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

2012-08-06 Thread Scott Garman

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

2012-08-01 Thread Scott Garman

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

2012-08-01 Thread Scott Garman

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.

2012-08-01 Thread Scott Garman

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.

2012-07-31 Thread Scott Garman

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?

2012-07-27 Thread Scott Garman

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?

2012-07-27 Thread Scott Garman

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

2012-07-20 Thread Scott Garman

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)

2012-07-16 Thread Scott Garman

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.

2012-07-10 Thread Scott Garman

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

2012-07-09 Thread Scott Garman

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

2012-06-14 Thread Scott Garman

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

2012-06-14 Thread Scott Garman

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.

2012-06-12 Thread Scott Garman

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.

2012-06-12 Thread Scott Garman

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

2012-05-23 Thread Scott Garman

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

2012-05-22 Thread Scott Garman

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

2012-05-22 Thread Scott Garman

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

2012-05-22 Thread Scott Garman

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 ??

2012-05-09 Thread Scott Garman

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.

2012-05-08 Thread Scott Garman

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

2012-05-04 Thread Scott Garman

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

2012-05-04 Thread Scott Garman

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.

2012-05-01 Thread Scott Garman

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.

2012-05-01 Thread Scott Garman

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

2012-03-15 Thread Scott Garman

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

2012-02-25 Thread Scott Garman

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

2012-02-20 Thread Scott Garman

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

2012-02-17 Thread Scott Garman

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

2012-02-14 Thread Scott Garman

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.

2012-02-09 Thread Scott Garman

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)

2012-02-09 Thread Scott Garman

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

2012-02-08 Thread Scott Garman

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

2012-02-08 Thread Scott Garman

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

2012-02-08 Thread Scott Garman

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.

2012-02-03 Thread Scott Garman

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

2012-02-03 Thread Scott Garman

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

2012-02-01 Thread Scott Garman

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

2012-01-26 Thread Scott Garman

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

2012-01-26 Thread Scott Garman

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

2012-01-26 Thread Scott Garman

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

2012-01-26 Thread Scott Garman

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?

2012-01-25 Thread Scott Garman

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

2012-01-05 Thread Scott Garman

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?

2011-11-07 Thread Scott Garman
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?

2011-10-27 Thread Scott Garman

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

2011-10-26 Thread Scott Garman

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

2011-10-26 Thread Scott Garman

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

2011-10-11 Thread Scott Garman

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

2011-09-29 Thread Scott Garman

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)

2011-09-08 Thread Scott Garman
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?

2011-08-11 Thread Scott Garman

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?

2011-07-21 Thread Scott Garman

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?

2011-07-21 Thread Scott Garman

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?

2011-07-21 Thread Scott Garman

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

2011-07-15 Thread Scott Garman

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

2011-06-10 Thread Scott Garman

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

2011-05-06 Thread Scott Garman

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

2011-05-06 Thread Scott Garman

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

2011-04-18 Thread Scott Garman

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

2011-04-09 Thread Scott Garman

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

2011-03-22 Thread Scott Garman

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

2011-03-21 Thread Scott Garman

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

2011-02-12 Thread Scott Garman

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.

2011-02-09 Thread Scott Garman

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

2011-01-21 Thread Scott Garman

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

2011-01-11 Thread Scott Garman

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

2011-01-05 Thread Scott Garman

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

2010-12-23 Thread Scott Garman

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

2010-12-16 Thread Scott Garman

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

2010-12-14 Thread Scott Garman

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

2010-12-14 Thread Scott Garman

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

2010-12-13 Thread Scott Garman

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

2010-12-12 Thread Scott Garman

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

2010-12-09 Thread Scott Garman

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

2010-12-07 Thread Scott Garman

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


  1   2   >