[PATCH 0/6] Misc build failure fixes

[PATCH 0/6] Misc build failure fixes

[Paul Eggleton]

The following changes since commit 81379dc141e245307ca391a02b7490b199128991:

  dates: Fix unpackaged files warning (2012-03-13 23:18:19 +0000)

are available in the git repository at:
  git://git.openembedded.org/openembedded-core-contrib paule/fixes14
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/fixes14

Paul Eggleton (6):
  scripts/bitbake: ensure user is in build directory
  pulseaudio: add X library dependencies
  gst-plugins-bad: disable directfb in configure
  mx: add dependencies
  ncurses: fix build when ENABLE_WIDEC is not set
  linux-yocto-tiny: add dependency on xz-native

 meta/recipes-core/ncurses/ncurses.inc              |    5 +++--
 meta/recipes-graphics/mx/mx_1.4.2.bb               |    2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_3.0.bb  |    5 ++++-
 .../gstreamer/gst-plugins-bad_0.10.22.bb           |    4 ++--
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |    3 ++-
 .../pulseaudio/pulseaudio_1.1.bb                   |    2 +-
 scripts/bitbake                                    |    5 +++++
 7 files changed, 18 insertions(+), 8 deletions(-)

-- 
1.7.5.4

[PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Paul Eggleton]

If the user is in any directory other than $BUILDDIR when the bitbake
wrapper script is run, then show an error an exit.

Fixes [YOCTO #2071].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 scripts/bitbake |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/scripts/bitbake b/scripts/bitbake
index dda3b26..45c8697 100755
--- a/scripts/bitbake
+++ b/scripts/bitbake
@@ -47,6 +47,11 @@ float_test() {
 # but earlier versions do not
 float_test "$TARVERSION > 1.23" && needtar="0"
 
+if [ "`pwd`" != "$BUILDDIR" ] ; then
+    echo "BitBake must be run from your build directory: $BUILDDIR"
+    exit 1
+fi
+
 buildpseudo="1"
 if [ $needpseudo = "1" ] && [ -e "$BUILDDIR/pseudodone" ]; then
     PSEUDOBINDIR=`cat $BUILDDIR/pseudodone`
-- 
1.7.5.4

[PATCH 2/6] pulseaudio: add X library dependencies

[Paul Eggleton]

PulseAudio requires libxtst, libice, libsm and libxcb when X11 is
enabled (in our case, when x11 is in DISTRO_FEATURES), so conditionally
add those to DEPENDS.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |    3 ++-
 .../pulseaudio/pulseaudio_1.1.bb                   |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index dda0352..a653af5 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -7,7 +7,8 @@ LIC_FILES_CHKSUM = "file://GPL;md5=4325afd396febcb659c36b49533135d4 \
                     file://LGPL;md5=2d5025d4aa3495befef8f17206a5b0a1 \
                     file://src/modules/bluetooth/proximity-helper.c;beginline=1;endline=25;md5=e4cc710e40a4d900c2c294167bc58270 \
                     file://src/pulsecore/vector.h;beginline=1;endline=21;md5=1b561f0a2ca47b1fa49862a6ccaacff1"
-DEPENDS = "libatomics-ops liboil avahi libsamplerate0 libsndfile1 libtool ${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 gtk+', '', d)}"
+DEPENDS = "libatomics-ops liboil avahi libsamplerate0 libsndfile1 libtool \
+           ${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxtst libice libsm libxcb gtk+', '', d)}"
 # optional
 DEPENDS += "udev alsa-lib glib-2.0 dbus consolekit \
            ${@base_contains('DISTRO_FEATURES', 'bluetooth', 'bluez4', '', d)}"
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
index 3055994..e98a591 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_1.1.bb
@@ -1,6 +1,6 @@
 require pulseaudio.inc
 
-PR = "r6"
+PR = "r7"
 
 DEPENDS += "libjson gdbm speex libxml-parser-perl-native"
 
-- 
1.7.5.4

[PATCH 3/6] gst-plugins-bad: disable directfb in configure

[Paul Eggleton]

Disable directfb output (as we do with SDL) so that it does not get
auto-detected resulting in a race condition.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 .../gstreamer/gst-plugins-bad_0.10.22.bb           |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.22.bb b/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.22.bb
index b99d453..2c97a10 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.22.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.22.bb
@@ -8,11 +8,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
 
 DEPENDS += "gst-plugins-base libmusicbrainz tremor librsvg"
 
-PR = "r2"
+PR = "r3"
 
 inherit gettext
 
-EXTRA_OECONF += "--disable-examples --disable-experimental --disable-sdl --disable-cdaudio \
+EXTRA_OECONF += "--disable-examples --disable-experimental --disable-sdl --disable-cdaudio --disable-directfb \
                  --with-plugins=musicbrainz,wavpack,ivorbis,mpegvideoparse --disable-vdpau --disable-apexsink"
 
 ARM_INSTRUCTION_SET = "arm"
-- 
1.7.5.4

[PATCH 4/6] mx: add dependencies

[Paul Eggleton]

* Add dependency on startup-notification, which is optional but without
  it mx applications will not send startup notifications.
* Add dependencies on gdk-pixbuf and libxrandr which are usually taken
  care of, but are required and thus should be stated explicitly.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/recipes-graphics/mx/mx_1.4.2.bb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-graphics/mx/mx_1.4.2.bb b/meta/recipes-graphics/mx/mx_1.4.2.bb
index c50bc0f..bee65f6 100644
--- a/meta/recipes-graphics/mx/mx_1.4.2.bb
+++ b/meta/recipes-graphics/mx/mx_1.4.2.bb
@@ -3,7 +3,7 @@ LICENSE = "LGPLv2.1"
 
 PR = "r1"
 
-DEPENDS = "clutter-1.8 dbus-glib"
+DEPENDS = "clutter-1.8 dbus-glib libxrandr gdk-pixbuf startup-notification"
 
 inherit autotools gettext
 
-- 
1.7.5.4

[PATCH 5/6] ncurses: fix build when ENABLE_WIDEC is not set

[Paul Eggleton]

If wide character support is disabled (as it is with poky-tiny, for
example) then we won't have libncursesw.so.*, so skip moving these files
in that case. (Fixes a regression introduced in OE-Core revision
ccd370ab147b78de7a5bd74818f755f4d3ca6d81).

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/recipes-core/ncurses/ncurses.inc |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
index e450868..fe2c3e4 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = "file://ncurses/base/version.c;beginline=1;endline=27;md5=cbc
 SECTION = "libs"
 DEPENDS = "ncurses-native"
 DEPENDS_virtclass-native = ""
-INC_PR = "r5"
+INC_PR = "r6"
 
 inherit autotools binconfig multilib_header
 
@@ -185,7 +185,8 @@ shell_do_install() {
             # case will skip this code
             mkdir ${D}${base_libdir}
             mv ${D}${libdir}/libncurses.so.* ${D}${base_libdir}
-            mv ${D}${libdir}/libncursesw.so.* ${D}${base_libdir}
+            ! ${ENABLE_WIDEC} || \
+                mv ${D}${libdir}/libncursesw.so.* ${D}${base_libdir}
 
             mv ${D}${libdir}/libtinfo.so.* ${D}${base_libdir}
             rm ${D}${libdir}/libtinfo.so
-- 
1.7.5.4

[PATCH 6/6] linux-yocto-tiny: add dependency on xz-native

[Paul Eggleton]

The kernel configuration requires lzma to compress the kernel image
(CONFIG_KERNEL_LZMA=y), so add a dependency on xz-native which provides
it.

Fixes [YOCTO #1728].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/recipes-kernel/linux/linux-yocto-tiny_3.0.bb |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.0.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.0.bb
index 5cad513..a3a6167 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.0.bb
@@ -1,6 +1,9 @@
 inherit kernel
 require recipes-kernel/linux/linux-yocto.inc
 
+# We need lzma (as CONFIG_KERNEL_LZMA=y)
+DEPENDS += "xz-native"
+
 #KMACHINE = "yocto/standard/tiny/base"
 KMACHINE = "yocto/standard/base"
 KBRANCH = "${KMACHINE}"
@@ -10,7 +13,7 @@ LINUX_VERSION ?= "3.0.23"
 SRCREV_machine ?= "8fd24b3570ab995848e4123ef13bac64e2c924be"
 SRCREV_meta ?= "e559129b4a6f39f68b75141096b2d516cf7a7f35"
 
-PR = "r2"
+PR = "r3"
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta \
-- 
1.7.5.4

Re: [PATCH 6/6] linux-yocto-tiny: add dependency on xz-native

[Koen Kooi]

Op 14 mrt. 2012, om 01:36 heeft Paul Eggleton het volgende geschreven:

> The kernel configuration requires lzma to compress the kernel image
> (CONFIG_KERNEL_LZMA=y), so add a dependency on xz-native which provides
> it.

Have a look at https://github.com/Angstrom-distribution/meta-ti/commit/b72cb13fcf83b9d342808ea30379bfb6a1321b54 :)

regards,

Koen

Re: [PATCH 6/6] linux-yocto-tiny: add dependency on xz-native

[Paul Eggleton]

On Wednesday 14 March 2012 09:21:06 Koen Kooi wrote:
> Op 14 mrt. 2012, om 01:36 heeft Paul Eggleton het volgende geschreven:
> > The kernel configuration requires lzma to compress the kernel image
> > (CONFIG_KERNEL_LZMA=y), so add a dependency on xz-native which provides
> > it.
> 
> Have a look at
> https://github.com/Angstrom-distribution/meta-ti/commit/b72cb13fcf83b9d3428
> 08ea30379bfb6a1321b54 :)

Right, I thought about that already - but we do not (by default) use defconfigs 
with linux-yocto*, so you'd have to go through all config fragments with this 
check. I figured it probably wasn't worth the effort in this case.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 6/6] linux-yocto-tiny: add dependency on xz-native

[Bruce Ashfield]

On Wed, Mar 14, 2012 at 4:32 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Wednesday 14 March 2012 09:21:06 Koen Kooi wrote:
>> Op 14 mrt. 2012, om 01:36 heeft Paul Eggleton het volgende geschreven:
>> > The kernel configuration requires lzma to compress the kernel image
>> > (CONFIG_KERNEL_LZMA=y), so add a dependency on xz-native which provides
>> > it.
>>
>> Have a look at
>> https://github.com/Angstrom-distribution/meta-ti/commit/b72cb13fcf83b9d3428
>> 08ea30379bfb6a1321b54 :)
>
> Right, I thought about that already - but we do not (by default) use defconfigs
> with linux-yocto*, so you'd have to go through all config fragments with this
> check. I figured it probably wasn't worth the effort in this case.

In this case, you wouldn't go through the fragments, you'd just add one that
turns it on when you want it. Don't audit a defconfig, push the few options that
you want onto the build.

Cheers,

Bruce

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 6/6] linux-yocto-tiny: add dependency on xz-native

[Paul Eggleton]

Hi Bruce,

On Wednesday 14 March 2012 08:29:20 Bruce Ashfield wrote:
> In this case, you wouldn't go through the fragments, you'd just add one that
> turns it on when you want it. Don't audit a defconfig, push the few options
> that you want onto the build.

I'm not sure what you mean here, in the context of generically figuring out 
whether lzma is needed...?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 6/6] linux-yocto-tiny: add dependency on xz-native

[Bruce Ashfield]

On Wed, Mar 14, 2012 at 8:39 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> Hi Bruce,
>
> On Wednesday 14 March 2012 08:29:20 Bruce Ashfield wrote:
>> In this case, you wouldn't go through the fragments, you'd just add one that
>> turns it on when you want it. Don't audit a defconfig, push the few options
>> that you want onto the build.
>
> I'm not sure what you mean here, in the context of generically figuring out
> whether lzma is needed...?

Maybe I misread/misunderstood the question at hand then :) Let me just
rephrase it this way, we have the recipe and the control in this case, so
adding the dependency and making sure that the kernel option to use
it via a config fragment is valid .. which is what you did, minus the fragment,
and we don't really need the fragment, since we know it is on.

You could audit the constructed .config as well, since that's the final word
on whether it actually makes it into the kernel build, but also not really
required here.

So consider this random noise, before I drank my coffee this morning :)

Cheers,

Bruce

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 6/6] linux-yocto-tiny: add dependency on xz-native

[Paul Eggleton]

On Wednesday 14 March 2012 08:59:34 Bruce Ashfield wrote:
> You could audit the constructed .config as well, since that's the final word
> on whether it actually makes it into the kernel build, but also not really
> required here.

This is what I wanted to do, but I'm assuming the config construction happens 
far too late to add the dependency.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 6/6] linux-yocto-tiny: add dependency on xz-native

[Bruce Ashfield]

On Wed, Mar 14, 2012 at 9:03 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Wednesday 14 March 2012 08:59:34 Bruce Ashfield wrote:
>> You could audit the constructed .config as well, since that's the final word
>> on whether it actually makes it into the kernel build, but also not really
>> required here.
>
> This is what I wanted to do, but I'm assuming the config construction happens
> far too late to add the dependency.

Hmm. probably, I admit to not looking too deeply while trying to get enough
coffee into my system to properly think :)

Cheers,

Bruce

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 0/6] Misc build failure fixes

[Richard Purdie]

On Wed, 2012-03-14 at 00:36 +0000, Paul Eggleton wrote:
> The following changes since commit 81379dc141e245307ca391a02b7490b199128991:
> 
>   dates: Fix unpackaged files warning (2012-03-13 23:18:19 +0000)
> 
> are available in the git repository at:
>   git://git.openembedded.org/openembedded-core-contrib paule/fixes14
>   http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/fixes14
> 
> Paul Eggleton (6):
>   scripts/bitbake: ensure user is in build directory
>   pulseaudio: add X library dependencies
>   gst-plugins-bad: disable directfb in configure
>   mx: add dependencies
>   ncurses: fix build when ENABLE_WIDEC is not set
>   linux-yocto-tiny: add dependency on xz-native

Merged to master, thanks.

Richard

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Darren Hart]

On 03/13/2012 05:36 PM, Paul Eggleton wrote:
> If the user is in any directory other than $BUILDDIR when the bitbake
> wrapper script is run, then show an error an exit.
> 
> Fixes [YOCTO #2071].
> 
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
>  scripts/bitbake |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/scripts/bitbake b/scripts/bitbake
> index dda3b26..45c8697 100755
> --- a/scripts/bitbake
> +++ b/scripts/bitbake
> @@ -47,6 +47,11 @@ float_test() {
>  # but earlier versions do not
>  float_test "$TARVERSION > 1.23" && needtar="0"
>  
> +if [ "`pwd`" != "$BUILDDIR" ] ; then
> +    echo "BitBake must be run from your build directory: $BUILDDIR"
> +    exit 1

Should this have some kind of prefix? "ERROR: " or something along those
lines for consistency with other output?

Otherwise, YAY! I've tripped over this frequently and keep doing the cd
dance after a short "What the heck" session. Such a simple fix to -
Thanks Paul!

> +fi
> +
>  buildpseudo="1"
>  if [ $needpseudo = "1" ] && [ -e "$BUILDDIR/pseudodone" ]; then
>      PSEUDOBINDIR=`cat $BUILDDIR/pseudodone`

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

Re: [PATCH 5/6] ncurses: fix build when ENABLE_WIDEC is not set

[Darren Hart]

On 03/13/2012 05:36 PM, Paul Eggleton wrote:
> If wide character support is disabled (as it is with poky-tiny, for
> example) then we won't have libncursesw.so.*, so skip moving these files
> in that case. (Fixes a regression introduced in OE-Core revision
> ccd370ab147b78de7a5bd74818f755f4d3ca6d81).
> 
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>

Perfect, thanks Paul. Poky-tiny is now on the Yocto autobuilder which
should help catch when things like this creep in going forward.

--
Darren

> ---
>  meta/recipes-core/ncurses/ncurses.inc |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
> index e450868..fe2c3e4 100644
> --- a/meta/recipes-core/ncurses/ncurses.inc
> +++ b/meta/recipes-core/ncurses/ncurses.inc
> @@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = "file://ncurses/base/version.c;beginline=1;endline=27;md5=cbc
>  SECTION = "libs"
>  DEPENDS = "ncurses-native"
>  DEPENDS_virtclass-native = ""
> -INC_PR = "r5"
> +INC_PR = "r6"
>  
>  inherit autotools binconfig multilib_header
>  
> @@ -185,7 +185,8 @@ shell_do_install() {
>              # case will skip this code
>              mkdir ${D}${base_libdir}
>              mv ${D}${libdir}/libncurses.so.* ${D}${base_libdir}
> -            mv ${D}${libdir}/libncursesw.so.* ${D}${base_libdir}
> +            ! ${ENABLE_WIDEC} || \
> +                mv ${D}${libdir}/libncursesw.so.* ${D}${base_libdir}
>  
>              mv ${D}${libdir}/libtinfo.so.* ${D}${base_libdir}
>              rm ${D}${libdir}/libtinfo.so

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

Re: [PATCH 6/6] linux-yocto-tiny: add dependency on xz-native

[Darren Hart]

On 03/14/2012 06:12 AM, Bruce Ashfield wrote:
> On Wed, Mar 14, 2012 at 9:03 AM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
>> On Wednesday 14 March 2012 08:59:34 Bruce Ashfield wrote:
>>> You could audit the constructed .config as well, since that's the final word
>>> on whether it actually makes it into the kernel build, but also not really
>>> required here.
>>
>> This is what I wanted to do, but I'm assuming the config construction happens
>> far too late to add the dependency.
> 
> Hmm. probably, I admit to not looking too deeply while trying to get enough
> coffee into my system to properly think :)

Paul is correct here. He would have to wait until kernel_configme
completes before he could be sure that LZMA was needed. Adding to
specific recipes is the best approach in this case.

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

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Paul Eggleton]

On Wednesday 14 March 2012 07:52:01 Darren Hart wrote:
> Should this have some kind of prefix? "ERROR: " or something along those
> lines for consistency with other output?

I did wonder about that; in the end I elected to be consistent with the python 
version errors in the same script (although I was the one who added those 
IIRC... heh). Perhaps we ought to add the "ERROR: " prefix to all of the errors 
in the wrapper script.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Darren Hart]

On 03/14/2012 08:09 AM, Paul Eggleton wrote:
> On Wednesday 14 March 2012 07:52:01 Darren Hart wrote:
>> Should this have some kind of prefix? "ERROR: " or something along those
>> lines for consistency with other output?
> 
> I did wonder about that; in the end I elected to be consistent with the python 
> version errors in the same script (although I was the one who added those 
> IIRC... heh). Perhaps we ought to add the "ERROR: " prefix to all of the errors 
> in the wrapper script.
> 

Consistency is king here IMO. I don't care much one way or the other, so
long as it's consistent.


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

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Andreas Oberritter]

Hello Paul,

On 14.03.2012 01:36, Paul Eggleton wrote:
> If the user is in any directory other than $BUILDDIR when the bitbake
> wrapper script is run, then show an error an exit.

this patch broke my setup.

My $BUILDDIR points to tmp, so that pseudo doesn't get rebuilt for every
machine. I have a shared tmp for many machines.

BUILDDIR doesn't seem to have any other use than pointing to the
'pseudodone' file. I don't understand why it's required to run bitbake
from there.

I'm using a tiny shell fragment to set up my build environment. This is
how it looks like:

export BUILDDIR=${PREFIX}/tmp
export
PATH=${PREFIX}/openembedded-core/scripts:${PREFIX}/bitbake/bin:${PATH}

local.conf and bblayers.conf for individual machines are stored in
${PREFIX}/build/${MACHINE}/conf.

Regards,
Andreas

> Fixes [YOCTO #2071].
> 
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
>  scripts/bitbake |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/scripts/bitbake b/scripts/bitbake
> index dda3b26..45c8697 100755
> --- a/scripts/bitbake
> +++ b/scripts/bitbake
> @@ -47,6 +47,11 @@ float_test() {
>  # but earlier versions do not
>  float_test "$TARVERSION > 1.23" && needtar="0"
>  
> +if [ "`pwd`" != "$BUILDDIR" ] ; then
> +    echo "BitBake must be run from your build directory: $BUILDDIR"
> +    exit 1
> +fi
> +
>  buildpseudo="1"
>  if [ $needpseudo = "1" ] && [ -e "$BUILDDIR/pseudodone" ]; then
>      PSEUDOBINDIR=`cat $BUILDDIR/pseudodone`

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Paul Eggleton]

On Thursday 15 March 2012 01:30:31 Andreas Oberritter wrote:
> On 14.03.2012 01:36, Paul Eggleton wrote:
> > If the user is in any directory other than $BUILDDIR when the bitbake
> > wrapper script is run, then show an error an exit.
> 
> this patch broke my setup.

Ah, sorry about that.
 
> My $BUILDDIR points to tmp, so that pseudo doesn't get rebuilt for every
> machine. I have a shared tmp for many machines.

So a couple of things:

1) Unless I'm missing something you can share the same TMPDIR between multiple 
build directories to get the same result.
 
2) pseudo is a native package. It shouldn't be rebuilt when changing MACHINE. 
In fact I just verified by creating a different build directory with only 
MACHINE changed in the config, it is not rebuilt.

> BUILDDIR doesn't seem to have any other use than pointing to the
> 'pseudodone' file. I don't understand why it's required to run bitbake
> from there.

Well, it's required that bitbake is run from the build directory and when you 
use the setup script as intended that's where BUILDDIR points to. I hadn't 
anticipated that anyone would be changing BUILDDIR to point to anything other 
than the build dir, however I don't really think it's a good idea to support 
that.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Andreas Oberritter]

On 16.03.2012 00:09, Paul Eggleton wrote:
> On Thursday 15 March 2012 01:30:31 Andreas Oberritter wrote:
>> On 14.03.2012 01:36, Paul Eggleton wrote:
>>> If the user is in any directory other than $BUILDDIR when the bitbake
>>> wrapper script is run, then show an error an exit.
>>
>> this patch broke my setup.
> 
> Ah, sorry about that.
>  
>> My $BUILDDIR points to tmp, so that pseudo doesn't get rebuilt for every
>> machine. I have a shared tmp for many machines.
> 
> So a couple of things:
> 
> 1) Unless I'm missing something you can share the same TMPDIR between multiple 
> build directories to get the same result.
>  
> 2) pseudo is a native package. It shouldn't be rebuilt when changing MACHINE. 
> In fact I just verified by creating a different build directory with only 
> MACHINE changed in the config, it is not rebuilt.

Sorry, I messed up some details. In fact, pseudo-native doesn't get
rebuilt, but bitbake pseudo-native still gets executed for every
machine, unless $BUILDDIR/pseudodone is present and contains
PSEUDOBINDIR. This just wastes time and confuses users who receive a
message saying "Pseudo is not present but is required, building this
first before the main build".

>> BUILDDIR doesn't seem to have any other use than pointing to the
>> 'pseudodone' file. I don't understand why it's required to run bitbake
>> from there.
> 
> Well, it's required that bitbake is run from the build directory and when you 
> use the setup script as intended that's where BUILDDIR points to. I hadn't 
> anticipated that anyone would be changing BUILDDIR to point to anything other 
> than the build dir, however I don't really think it's a good idea to support 
> that.

That's because BUILDDIR has no meaning outside oe-core's setup scripts.
In scripts/bitbake, BUILDDIR would better be called PSEUDODONEDIR or
similar, because that's what the variable really means in this context
[1]. If I had a choice to override a more suitably named variable I
certainly would do that. ;-)

In order to verify that scripts/bitbake is called from the build
directory, you could as well just check whether $PWD/conf/local.conf exists.

I'm not using oe-core's scripts, because they make assumptions about the
directory layout that don't fit my project's needs. I think they are
overly complex and they display texts that seem to suit yocto's needs
but at least not mine.

Regards,
Andreas

[1]
$ grep BUILDDIR scripts/bitbake
if [ $needpseudo = "1" ] && [ -e "$BUILDDIR/pseudodone" ]; then
    PSEUDOBINDIR=`cat $BUILDDIR/pseudodone`
    echo $PSEUDOBINDIR > $BUILDDIR/pseudodone
    PSEUDOBINDIR=`cat $BUILDDIR/pseudodone`

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Paul Eggleton]

On Friday 16 March 2012 01:20:44 Andreas Oberritter wrote:
> Sorry, I messed up some details. In fact, pseudo-native doesn't get
> rebuilt, but bitbake pseudo-native still gets executed for every
> machine, unless $BUILDDIR/pseudodone is present and contains
> PSEUDOBINDIR. This just wastes time and confuses users who receive a
> message saying "Pseudo is not present but is required, building this
> first before the main build".

It takes a small amount of time just once. However if this is really an issue 
perhaps we could address it directly rather than hacking around it?

> >> BUILDDIR doesn't seem to have any other use than pointing to the
> >> 'pseudodone' file. I don't understand why it's required to run bitbake
> >> from there.
> > 
> > Well, it's required that bitbake is run from the build directory and when
> > you use the setup script as intended that's where BUILDDIR points to. I
> > hadn't anticipated that anyone would be changing BUILDDIR to point to
> > anything other than the build dir, however I don't really think it's a
> > good idea to support that.
> 
> That's because BUILDDIR has no meaning outside oe-core's setup scripts.
> In scripts/bitbake, BUILDDIR would better be called PSEUDODONEDIR or
> similar, because that's what the variable really means in this context

The naming is such that it should point to the build directory because that's 
where pseudodone is meant to be written. I think when it was introduced there 
was an idea that it might be useful in other contexts, thus the naming.

> In order to verify that scripts/bitbake is called from the build
> directory, you could as well just check whether $PWD/conf/local.conf exists.

Unfortunately it's not that simple. bitbake.conf pulls in local.conf using 
"include" and not "require", thus it doesn't actually have to exist anywhere.

> I'm not using oe-core's scripts, because they make assumptions about the
> directory layout that don't fit my project's needs. I think they are
> overly complex

Could you perhaps elaborate on what needs those scripts are not fulfilling?

> and they display texts that seem to suit yocto's needs but at least not
> mine.

We print these messages so that people know what to do and where to find 
further information. I don't think that's unreasonable. However if you have 
suggestions on how we might improve those messages or allow them to be 
customised if necessary, we could look at changing them.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[VIJAY KUMAR]

[-- Attachment #1: Type: text/plain, Size: 3405 bytes --]

Hi paul,

   Iam not specialist in this. I am just following the steps mentioned here

     http://icedtea.classpath.org/wiki/CrossCompileOECoreTutorial

I am building from this path  vj@ubuntu:/host/coreembedded/oe-core/build$
and it contains pseudodone file.

and in vj@ubuntu:/host/coreembedded/oe-core/build/conf local.conf exits..

and the same is calling bitbake which is present in scripts..

Regards,
VJ

On Fri, Mar 16, 2012 at 4:26 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> On Friday 16 March 2012 01:20:44 Andreas Oberritter wrote:
> > Sorry, I messed up some details. In fact, pseudo-native doesn't get
> > rebuilt, but bitbake pseudo-native still gets executed for every
> > machine, unless $BUILDDIR/pseudodone is present and contains
> > PSEUDOBINDIR. This just wastes time and confuses users who receive a
> > message saying "Pseudo is not present but is required, building this
> > first before the main build".
>
> It takes a small amount of time just once. However if this is really an
> issue
> perhaps we could address it directly rather than hacking around it?
>
> > >> BUILDDIR doesn't seem to have any other use than pointing to the
> > >> 'pseudodone' file. I don't understand why it's required to run bitbake
> > >> from there.
> > >
> > > Well, it's required that bitbake is run from the build directory and
> when
> > > you use the setup script as intended that's where BUILDDIR points to. I
> > > hadn't anticipated that anyone would be changing BUILDDIR to point to
> > > anything other than the build dir, however I don't really think it's a
> > > good idea to support that.
> >
> > That's because BUILDDIR has no meaning outside oe-core's setup scripts.
> > In scripts/bitbake, BUILDDIR would better be called PSEUDODONEDIR or
> > similar, because that's what the variable really means in this context
>
> The naming is such that it should point to the build directory because
> that's
> where pseudodone is meant to be written. I think when it was introduced
> there
> was an idea that it might be useful in other contexts, thus the naming.
>
> > In order to verify that scripts/bitbake is called from the build
> > directory, you could as well just check whether $PWD/conf/local.conf
> exists.
>
> Unfortunately it's not that simple. bitbake.conf pulls in local.conf using
> "include" and not "require", thus it doesn't actually have to exist
> anywhere.
>
> > I'm not using oe-core's scripts, because they make assumptions about the
> > directory layout that don't fit my project's needs. I think they are
> > overly complex
>
> Could you perhaps elaborate on what needs those scripts are not fulfilling?
>
> > and they display texts that seem to suit yocto's needs but at least not
> > mine.
>
> We print these messages so that people know what to do and where to find
> further information. I don't think that's unreasonable. However if you have
> suggestions on how we might improve those messages or allow them to be
> customised if necessary, we could look at changing them.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 4318 bytes --]

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Paul Eggleton]

Hi Vijay,

On Friday 16 March 2012 17:25:33 VIJAY KUMAR wrote:
>    Iam not specialist in this. I am just following the steps mentioned here
> 
>      http://icedtea.classpath.org/wiki/CrossCompileOECoreTutorial
> 
> I am building from this path  vj@ubuntu:/host/coreembedded/oe-core/build$
> and it contains pseudodone file.
> 
> and in vj@ubuntu:/host/coreembedded/oe-core/build/conf local.conf exits..
> 
> and the same is calling bitbake which is present in scripts..

FYI when you run bitbake after using . ./oe-init-build-env it sets up PATH so 
that "bitbake" runs the bitbake wrapper script in scripts/, that is intended.

Are you experiencing a problem relating to this?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Andreas Oberritter]

On 16.03.2012 11:56, Paul Eggleton wrote:
> On Friday 16 March 2012 01:20:44 Andreas Oberritter wrote:
>> Sorry, I messed up some details. In fact, pseudo-native doesn't get
>> rebuilt, but bitbake pseudo-native still gets executed for every
>> machine, unless $BUILDDIR/pseudodone is present and contains
>> PSEUDOBINDIR. This just wastes time and confuses users who receive a
>> message saying "Pseudo is not present but is required, building this
>> first before the main build".
> 
> It takes a small amount of time just once. However if this is really an issue 
> perhaps we could address it directly rather than hacking around it?
> 
>>>> BUILDDIR doesn't seem to have any other use than pointing to the
>>>> 'pseudodone' file. I don't understand why it's required to run bitbake
>>>> from there.
>>>
>>> Well, it's required that bitbake is run from the build directory and when
>>> you use the setup script as intended that's where BUILDDIR points to. I
>>> hadn't anticipated that anyone would be changing BUILDDIR to point to
>>> anything other than the build dir, however I don't really think it's a
>>> good idea to support that.
>>
>> That's because BUILDDIR has no meaning outside oe-core's setup scripts.
>> In scripts/bitbake, BUILDDIR would better be called PSEUDODONEDIR or
>> similar, because that's what the variable really means in this context
> 
> The naming is such that it should point to the build directory because that's 
> where pseudodone is meant to be written. I think when it was introduced there 
> was an idea that it might be useful in other contexts, thus the naming.

What is the reason for storing 'pseudodone' inside BUILDDIR? Wouldn't it
better be stored inside TMPDIR by default? Isn't there any way to get
rid of pseudodone completely?

>> In order to verify that scripts/bitbake is called from the build
>> directory, you could as well just check whether $PWD/conf/local.conf exists.
> 
> Unfortunately it's not that simple. bitbake.conf pulls in local.conf using 
> "include" and not "require", thus it doesn't actually have to exist anywhere.

In fact it is that simple, because If local.conf doesn't exist,
oe-setup-builddir creates it.

>> I'm not using oe-core's scripts, because they make assumptions about the
>> directory layout that don't fit my project's needs. I think they are
>> overly complex
> 
> Could you perhaps elaborate on what needs those scripts are not fulfilling?

1.) OE-core is not my top-level directory. It's included as a git
submodule. it must not contain any data not fetched from the OE-core
repository (i.e. no bitbake tree, no build dirs).

2.) Switching between build directories must not involve changing the
environment.

>> and they display texts that seem to suit yocto's needs but at least not
>> mine.
> 
> We print these messages so that people know what to do and where to find 
> further information. I don't think that's unreasonable. However if you have 
> suggestions on how we might improve those messages or allow them to be 
> customised if necessary, we could look at changing them.

I'd like to display none of those messages to my users. We have our own
help texts that are specific to our distribution and configuration.

Our setup script is based on GNU make and uses make's dependency
tracking. It creates local.conf on its own. I don't want any other
script to do that.

I really don't want to be forced to use those OE-core scripts, if a
two-line script is sufficient to fulfil my needs. This two-line script
just sets up the path to bitbake and sets the location of 'pseudodone'
(which already sucks - the path to bitbake should be sufficient alone).

Regards,
Andreas

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Khem Raj]

On (14/03/12 00:36), Paul Eggleton wrote:
> If the user is in any directory other than $BUILDDIR when the bitbake
> wrapper script is run, then show an error an exit.
> 
> Fixes [YOCTO #2071].


angstrom e.g. does not have this restriction but uses script/bitbake
so this fix seems to be wrong here since its specific to OE-Core's
default build env.

> 
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
>  scripts/bitbake |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/scripts/bitbake b/scripts/bitbake
> index dda3b26..45c8697 100755
> --- a/scripts/bitbake
> +++ b/scripts/bitbake
> @@ -47,6 +47,11 @@ float_test() {
>  # but earlier versions do not
>  float_test "$TARVERSION > 1.23" && needtar="0"
>  
> +if [ "`pwd`" != "$BUILDDIR" ] ; then
> +    echo "BitBake must be run from your build directory: $BUILDDIR"
> +    exit 1
> +fi
> +
>  buildpseudo="1"
>  if [ $needpseudo = "1" ] && [ -e "$BUILDDIR/pseudodone" ]; then
>      PSEUDOBINDIR=`cat $BUILDDIR/pseudodone`
> -- 
> 1.7.5.4
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
-Khem

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Paul Eggleton]

On Monday 02 April 2012 13:00:15 Khem Raj wrote:
> On (14/03/12 00:36), Paul Eggleton wrote:
> > If the user is in any directory other than $BUILDDIR when the bitbake
> > wrapper script is run, then show an error an exit.
> > 
> > Fixes [YOCTO #2071].
> 
> angstrom e.g. does not have this restriction but uses script/bitbake
> so this fix seems to be wrong here since its specific to OE-Core's
> default build env.

This has been implemented differently now:

http://cgit.openembedded.org/openembedded-core/commit/?id=769384decb095fb3c49eb13b8f7f69c978d0bcba

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Chris Larson]

On Mon, Apr 2, 2012 at 1:12 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Monday 02 April 2012 13:00:15 Khem Raj wrote:
>> On (14/03/12 00:36), Paul Eggleton wrote:
>> > If the user is in any directory other than $BUILDDIR when the bitbake
>> > wrapper script is run, then show an error an exit.
>> >
>> > Fixes [YOCTO #2071].
>>
>> angstrom e.g. does not have this restriction but uses script/bitbake
>> so this fix seems to be wrong here since its specific to OE-Core's
>> default build env.
>
> This has been implemented differently now:
>
> http://cgit.openembedded.org/openembedded-core/commit/?id=769384decb095fb3c49eb13b8f7f69c978d0bcba

This'll break the ability to run bitbake from subdirs underneath
BUILDDIR, which is perfectly valid, and supported by bitbake's code
which traverses up the current working path to find
conf/bblayers.conf.
-- 
Christopher Larson

Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory

[Paul Eggleton]

On Monday 02 April 2012 13:32:15 Chris Larson wrote:
> On Mon, Apr 2, 2012 at 1:12 PM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > This has been implemented differently now:
> > 
> > http://cgit.openembedded.org/openembedded-core/commit/?id=769384decb095fb3
> > c49eb13b8f7f69c978d0bcba
> This'll break the ability to run bitbake from subdirs underneath
> BUILDDIR, which is perfectly valid, and supported by bitbake's code
> which traverses up the current working path to find
> conf/bblayers.conf.

I don't know if you've tried this recently but it no longer works with current 
versions of OE-Core and bitbake (can't find local.conf). I'm not exactly sure 
why not and it's likely we should fix it, but right now it's broken anyway.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre