date:20120806


On 08/03/2012 07:19 PM, Wolfgang Denk wrote:

Dear Radu Moisan,

In message 1343997523-4117-1-git-send-email-radu.moi...@intel.com you wrote:

Building u-boot requires UBOOT_MACHINE. In the u-boot README file
building u-boot is achieved with make NAME_config and then
make all. I assumend UBOOT_MACHINE to be the NAME part and thus,

Actually a plain

make NAME

does the same as make NAME_config  make all.

You might also consider running ./MAKEALL NAME instead, which
aut-adjusts to te number of available cores on the build host, so you
get somewhat reduced build times.


I've tried to build this way but got into some errors and did not 
pursued further in debugging them. However, because UBOOT_MACHINE is 
already used as NAME_config, would be difficult to change it to NAME and 
ask everyone who use it, to switch. I will go with current configuration 
make NAME_config  make all


radu

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH] u-boot: Upgrade to upstream stable 2012.07

For u-boot-fw-utils, fw_enc.c was changed and it requires a header
file config.h which is autogenerated at config so it requires a
make NAME_config.
I used for testing coreboot-x86.

Signed-off-by: Radu Moisan radu.moi...@intel.com
---
 ...ls_2012.04.01.bb = u-boot-fw-utils_2012.07.bb} |7 ---
 ...age_2012.04.01.bb = u-boot-mkimage_2012.07.bb} |6 +++---
 .../{u-boot_2012.04.01.bb = u-boot_2012.07.bb}|8 
 3 files changed, 11 insertions(+), 10 deletions(-)
 rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2012.04.01.bb = 
u-boot-fw-utils_2012.07.bb} (83%)
 rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2012.04.01.bb = 
u-boot-mkimage_2012.07.bb} (84%)
 rename meta/recipes-bsp/u-boot/{u-boot_2012.04.01.bb = u-boot_2012.07.bb} 
(82%)

diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb 
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.07.bb
similarity index 83%
rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.07.bb
index fe3422a..d2224bb 100644
--- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.07.bb
@@ -9,12 +9,12 @@ DEPENDS = mtd-utils
 # make it default
 DEFAULT_PREFERENCE = -1
 
-# This revision corresponds to the tag v2012.04.01
+# This revision corresponds to the tag v2012.07
 # We use the revision in order to avoid having to fetch it from the
 # repo during parse
-SRCREV = 415d386877df49eb051b85ef74fa59a16dc17c7d
+SRCREV = 190649fb4309d1bc0fe7732fd0f951cb6440f935
 
-PV = v2012.04.01+git${SRCPV}
+PV = 2012.07
 
 SRC_URI = git://git.denx.de/u-boot.git;branch=master;protocol=git
 
@@ -23,6 +23,7 @@ S = ${WORKDIR}/git
 EXTRA_OEMAKE = 'HOSTCC=${CC}'
 
 do_compile () {
+  oe_runmake ${UBOOT_MACHINE}
   oe_runmake env
 }
 
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb 
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.07.bb
similarity index 84%
rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb
rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2012.07.bb
index aa107fe..752efcb 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.07.bb
@@ -7,12 +7,12 @@ SECTION = bootloader
 # make it default
 DEFAULT_PREFERENCE = -1
 
-# This revision corresponds to the tag v2012.04.01
+# This revision corresponds to the tag v2012.07
 # We use the revision in order to avoid having to fetch it from the
 # repo during parse
-SRCREV = 415d386877df49eb051b85ef74fa59a16dc17c7d
+SRCREV = 190649fb4309d1bc0fe7732fd0f951cb6440f935
 
-PV = v2012.04.01+git${SRCPV}
+PV = 2012.07
 
 SRC_URI = git://git.denx.de/u-boot.git;branch=master;protocol=git
 
diff --git a/meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb 
b/meta/recipes-bsp/u-boot/u-boot_2012.07.bb
similarity index 82%
rename from meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb
rename to meta/recipes-bsp/u-boot/u-boot_2012.07.bb
index c4ec50d..7ccee30 100644
--- a/meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot_2012.07.bb
@@ -14,13 +14,13 @@ DEFAULT_PREFERENCE = -1
 LICENSE = GPLv2+
 LIC_FILES_CHKSUM = file://COPYING;md5=1707d6db1d42237583f50183a5651ecb
 
-# This revision corresponds to the tag v2012.04.01
+# This revision corresponds to the tag v2012.07
 # We use the revision in order to avoid having to fetch it from the
 # repo during parse
-SRCREV = 415d386877df49eb051b85ef74fa59a16dc17c7d
+SRCREV = 190649fb4309d1bc0fe7732fd0f951cb6440f935
 
-PV = v2012.04.01+git${SRCPV}
-PR = r1
+PV = 2012.07
+PR = r0
 
 SRC_URI = git://git.denx.de/u-boot.git;branch=master;protocol=git
 
-- 
1.7.9.5


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] u-boot: Upgrade to upstream stable 2012.07

On Mon, Aug 06, 2012 at 09:54:07AM +0300, Radu Moisan wrote:
 For u-boot-fw-utils, fw_enc.c was changed and it requires a header
 file config.h which is autogenerated at config so it requires a
 make NAME_config.
 I used for testing coreboot-x86.

Is build with gold resolved in this new release already? By forcing bfd
or to provide working binaries when built with gold?

More info:
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-August/026943.html

Cheers,

 
 Signed-off-by: Radu Moisan radu.moi...@intel.com
 ---
  ...ls_2012.04.01.bb = u-boot-fw-utils_2012.07.bb} |7 ---
  ...age_2012.04.01.bb = u-boot-mkimage_2012.07.bb} |6 +++---
  .../{u-boot_2012.04.01.bb = u-boot_2012.07.bb}|8 
  3 files changed, 11 insertions(+), 10 deletions(-)
  rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2012.04.01.bb = 
 u-boot-fw-utils_2012.07.bb} (83%)
  rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2012.04.01.bb = 
 u-boot-mkimage_2012.07.bb} (84%)
  rename meta/recipes-bsp/u-boot/{u-boot_2012.04.01.bb = u-boot_2012.07.bb} 
 (82%)
 
 diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb 
 b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.07.bb
 similarity index 83%
 rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
 rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.07.bb
 index fe3422a..d2224bb 100644
 --- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.01.bb
 +++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.07.bb
 @@ -9,12 +9,12 @@ DEPENDS = mtd-utils
  # make it default
  DEFAULT_PREFERENCE = -1
  
 -# This revision corresponds to the tag v2012.04.01
 +# This revision corresponds to the tag v2012.07
  # We use the revision in order to avoid having to fetch it from the
  # repo during parse
 -SRCREV = 415d386877df49eb051b85ef74fa59a16dc17c7d
 +SRCREV = 190649fb4309d1bc0fe7732fd0f951cb6440f935
  
 -PV = v2012.04.01+git${SRCPV}
 +PV = 2012.07
  
  SRC_URI = git://git.denx.de/u-boot.git;branch=master;protocol=git
  
 @@ -23,6 +23,7 @@ S = ${WORKDIR}/git
  EXTRA_OEMAKE = 'HOSTCC=${CC}'
  
  do_compile () {
 +  oe_runmake ${UBOOT_MACHINE}
oe_runmake env
  }
  
 diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb 
 b/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.07.bb
 similarity index 84%
 rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb
 rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2012.07.bb
 index aa107fe..752efcb 100644
 --- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb
 +++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.07.bb
 @@ -7,12 +7,12 @@ SECTION = bootloader
  # make it default
  DEFAULT_PREFERENCE = -1
  
 -# This revision corresponds to the tag v2012.04.01
 +# This revision corresponds to the tag v2012.07
  # We use the revision in order to avoid having to fetch it from the
  # repo during parse
 -SRCREV = 415d386877df49eb051b85ef74fa59a16dc17c7d
 +SRCREV = 190649fb4309d1bc0fe7732fd0f951cb6440f935
  
 -PV = v2012.04.01+git${SRCPV}
 +PV = 2012.07
  
  SRC_URI = git://git.denx.de/u-boot.git;branch=master;protocol=git
  
 diff --git a/meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb 
 b/meta/recipes-bsp/u-boot/u-boot_2012.07.bb
 similarity index 82%
 rename from meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb
 rename to meta/recipes-bsp/u-boot/u-boot_2012.07.bb
 index c4ec50d..7ccee30 100644
 --- a/meta/recipes-bsp/u-boot/u-boot_2012.04.01.bb
 +++ b/meta/recipes-bsp/u-boot/u-boot_2012.07.bb
 @@ -14,13 +14,13 @@ DEFAULT_PREFERENCE = -1
  LICENSE = GPLv2+
  LIC_FILES_CHKSUM = file://COPYING;md5=1707d6db1d42237583f50183a5651ecb
  
 -# This revision corresponds to the tag v2012.04.01
 +# This revision corresponds to the tag v2012.07
  # We use the revision in order to avoid having to fetch it from the
  # repo during parse
 -SRCREV = 415d386877df49eb051b85ef74fa59a16dc17c7d
 +SRCREV = 190649fb4309d1bc0fe7732fd0f951cb6440f935
  
 -PV = v2012.04.01+git${SRCPV}
 -PR = r1
 +PV = 2012.07
 +PR = r0
  
  SRC_URI = git://git.denx.de/u-boot.git;branch=master;protocol=git
  
 -- 
 1.7.9.5
 
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] gdk-pixbuf: fix parallel install issue

2012-08-06 Thread wenzong fan


On 08/06/2012 06:32 AM, Colin Walters wrote:

On Fri, 2012-08-03 at 11:30 +0800, wenzong@windriver.com wrote:


Make an explicit dependency to the libs install targets would fix this
issue.


I don't think Yocto should be running the 'make install' target with
parallelism enabled; it's just going to be a source of major pain for
small gain.  Historically Automake's install targets have had a lot of
paralleism issues AIUI, even discarding modules which have custom
install hooks.



Hi Richard,

What's your opinions?

Disable/Enable paralleism for 'make install', this more like a policy
issue rather than tech.

Thanks
Wenzong



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] tcl: Add ${bindir_crossscripts}/tclConfig.sh to sysroot stage

2012-08-06 Thread jackie.huang

From: Jackie Huang jackie.hu...@windriver.com

tclConfig.sh is changed in do_install for cross compile and
is installed to STAGING_BINDIR_CROSS, but if SSTATE_DIR is set
and tcl is from sstage, tclConfig.sh can't be found in
STAGING_BINDIR_CROSS, add ${bindir_crossscripts}/tclConfig.sh
to sysroot stage can fix it.

[YOCTO #2891]

Signed-off-by: Jackie Huang jackie.hu...@windriver.com
---
The following changes since commit a9d0cbe1d84bb26fc1a1f48764fe514cf9f9c548:

  gcc: Bump PR since there have been several gcc changes and various problems 
reported and this should flush anything stale out (2012-08-03 10:32:24 +0100)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib jhuang0/bug2891_tcl_0806
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/bug2891_tcl_0806

Jackie Huang (1):
  tcl: Add ${bindir_crossscripts}/tclConfig.sh to sysroot stage

 meta/recipes-devtools/tcltk/tcl_8.5.11.bb |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

-- 
1.7.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] tcl: Add ${bindir_crossscripts}/tclConfig.sh to sysroot stage

2012-08-06 Thread jackie.huang

From: Jackie Huang jackie.hu...@windriver.com

tclConfig.sh is changed in do_install for cross compile and
is installed to STAGING_BINDIR_CROSS, but if SSTATE_DIR is set
and tcl is from sstage, tclConfig.sh can't be found in
STAGING_BINDIR_CROSS, add ${bindir_crossscripts}/tclConfig.sh
to sysroot stage can fix it.

[YOCTO #2891]

Signed-off-by: Jackie Huang jackie.hu...@windriver.com
---
 meta/recipes-devtools/tcltk/tcl_8.5.11.bb |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/tcltk/tcl_8.5.11.bb 
b/meta/recipes-devtools/tcltk/tcl_8.5.11.bb
index d5cf6dc..f19e25a 100644
--- a/meta/recipes-devtools/tcltk/tcl_8.5.11.bb
+++ b/meta/recipes-devtools/tcltk/tcl_8.5.11.bb
@@ -49,8 +49,8 @@ do_install() {
#sed -i s+${WORKDIR}+${STAGING_INCDIR}+g tclConfig.sh
sed -i s,-L${libdir},-L=${libdir},g tclConfig.sh
sed -i s,-I${includedir},-I=${includedir},g tclConfig.sh 
-   install -d ${STAGING_BINDIR_CROSS}/
-   install -m 0755 tclConfig.sh ${STAGING_BINDIR_CROSS}
+   install -d ${D}${bindir_crossscripts}
+   install -m 0755 tclConfig.sh ${D}${bindir_crossscripts}
cd ..
for dir in compat generic unix
do
@@ -59,6 +59,11 @@ do_install() {
done
 }
 
+SYSROOT_PREPROCESS_FUNCS += tcl_sysroot_preprocess
+tcl_sysroot_preprocess () {
+   sysroot_stage_dir ${D}${bindir_crossscripts} 
${SYSROOT_DESTDIR}${bindir_crossscripts}
+}
+
 PACKAGES =+ tcl-lib
 FILES_tcl-lib = ${libdir}/libtcl8.5.so*
 FILES_${PN} += ${prefix}/lib/tcl8.5 ${prefix}/lib/tcl8
-- 
1.7.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] [PATCH] sstate: Add a two character subdirectory to the sstate directory layout

On Thu, Aug 02, 2012 at 08:57:50PM +0100, Richard Purdie wrote:
 On Thu, 2012-08-02 at 21:40 +0200, Martin Jansa wrote:
  On Thu, Aug 02, 2012 at 04:53:12PM +0100, Richard Purdie wrote:
   On Thu, 2012-08-02 at 16:14 +0200, Martin Jansa wrote:
On Thu, Aug 02, 2012 at 03:53:35PM +0200, Martin Jansa wrote:
 On Wed, Jul 25, 2012 at 10:09:22PM +0100, Richard Purdie wrote:
  Currently all sstate files are placed into one directory. This does 
  not scale and
  causes a variety of filesystem issues. This patch adds a two 
  character subdirectory
  to the layout (based on the first two characters of the hash) so 
  that files
  can be split into several directories.
  
  This should help performance of sstate in most cases by avoding 
  creating directories with 
  huge numbers of files.
  
  The SSTATE_MIRRORS syntax needs updating to account for the extra 
  path element by
  the addition of a PATH item, for example:
  
  SSTATE_MIRRORS = file://.* file:///some/path/to/sstate-cache/PATH
  SSTATE_MIRRORS = file://.* http://192.168.1.23/sstate-cache/PATH;
  
  This change also sets the scene for using things like lsb-release in
  the 
 
 Is it possible to create 2nd level cache with this?
 
 I have some server with slow upload but fully populated sstate-cache.
 
 So on server with faster upload which could be used as offical
 SSTATE_MIRROR for SHR distro I would like to add
 
 SSTATE_MIRRORS ?= file://.* http://slow-server/sstate-cache/PATH;
 
 And then sync my sstate-cache directory to public accessible web root 
 (with rsync).
 
 Problem is that now sstate-cache has all files in slightly different 
 layout then original sstate-cache on slow server. From what I see I 
 guess 
 it finds URL with correct prefix sstate-cache/Gentoo-2.1/0d and 
 downloads it 
 directly to sstate-cache dir (and adds .done)
 
 OE @ ~/oe-core $ ll 
 sstate-cache/sstate-apr-native-x86_64-linux-1.4.6-r1-x86_64-2-*populate-lic*
 -rw-r--r-- 1 bitbake bitbake 9257 Jul 30 12:31 
 sstate-cache/sstate-apr-native-x86_64-linux-1.4.6-r1-x86_64-2-0d2ed24b90d50bf83e5fe94536596e50_populate-lic.tgz
 -rw-r--r-- 1 bitbake bitbake0 Aug  2 15:40 
 sstate-cache/sstate-apr-native-x86_64-linux-1.4.6-r1-x86_64-2-0d2ed24b90d50bf83e5fe94536596e50_populate-lic.tgz.done
 
 And then creates symlink in right prefix back to absolute path of 
 sstate-cache/file:
 OE @ ~/oe-core $ ll 
 sstate-cache/Gentoo-2.1/0d/sstate-apr-native-x86_64-linux-1.4.6-r1-x86_64-2-*populate-lic*
 lrwxrwxrwx 1 bitbake bitbake 123 Aug  2 15:40 
 sstate-cache/Gentoo-2.1/0d/sstate-apr-native-x86_64-linux-1.4.6-r1-x86_64-2-0d2ed24b90d50bf83e5fe94536596e50_populate-lic.tgz
  - 
 /OE/oe-core/sstate-cache/sstate-apr-native-x86_64-linux-1.4.6-r1-x86_64-2-0d2ed24b90d50bf83e5fe94536596e50_populate-lic.tgz
 
 But after sstate-cache directory is rsynced somewhere else and 
 oe-core/sstate-cache is removed, 
 all those symlinks point nowhere and public sstate-cache is unusable.
 
 Can we have relative paths used in symlinks or even instruct fetcher 
 to download that 
 file directly to right prefix?

2 more ideas:

1) would be great to also download file.sigdata if it exists, to be able
   to compare them when they change even on machine which downloaded
   older sstate file from remote url
2) if the reason for this patch was number of files in shared
   sstate-cache directory, then fetcher creating .done files makes
   number double too (would be fine if fetcher stores all 3 files
   (.tgz, .tgz.sigdata, .tgz.done) in right prefix, or moves them to
   right prefix instead of symlinks.
   
   I'm aware of the problem. The main issue is that we probably need to
  
  And what about .sigdata files?

Added
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2898

  I have sort shell script to replace symlinks with real files in prefixed
  dirs, would it be worth it integrating to 
  openembedded-core/scripts/sstate-cache-management.sh
  which doesn't work with new layout anyway?

Added
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2897

   start enforcing complete paths for all downloads in DL_DIR, including
   http:// urls. This would resolve conflicts like:
   
   SRC_URI = http://server1.org/somefile.patch \
  http://server2.org/somefile.patch;
  
  In two separate recipes right?
  
   where the two files are different. The trouble is it will pretty much
   break all the source mirrors :(.
  
  So you would store them in DL_DIR/server1.org/somefile.patch path?
 
 I've wondered about:
 
 DL_DIR/server1.org/somepath/somefile.patch
 
  That would make oposite scenario where the BIG.tgz is available 
  (or even requested by different recipes) from different location less
  efficient.

Re: [OE-core] [PATCH] u-boot: Upgrade to upstream stable 2012.07



On 08/06/2012 09:55 AM, Martin Jansa wrote:

On Mon, Aug 06, 2012 at 09:54:07AM +0300, Radu Moisan wrote:

For u-boot-fw-utils, fw_enc.c was changed and it requires a header
file config.h which is autogenerated at config so it requires a
make NAME_config.
I used for testing coreboot-x86.

Is build with gold resolved in this new release already? By forcing bfd
or to provide working binaries when built with gold?

More info:
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-August/026943.html
I don't know what linker is used, I guess the default one. If you can 
point out to me how to check, I'll be glad to do it.
The patch in your link was not in my tree at the time I've tested, if 
that is relevant in any way.


thanks,
radu

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] u-boot: Upgrade to upstream stable 2012.07

On Mon, Aug 06, 2012 at 10:12:20AM +0300, Radu Moisan wrote:
 
 On 08/06/2012 09:55 AM, Martin Jansa wrote:
  On Mon, Aug 06, 2012 at 09:54:07AM +0300, Radu Moisan wrote:
  For u-boot-fw-utils, fw_enc.c was changed and it requires a header
  file config.h which is autogenerated at config so it requires a
  make NAME_config.
  I used for testing coreboot-x86.
  Is build with gold resolved in this new release already? By forcing bfd
  or to provide working binaries when built with gold?
 
  More info:
  http://lists.linuxtogo.org/pipermail/openembedded-core/2012-August/026943.html

 I don't know what linker is used, I guess the default one. If you can 
 point out to me how to check, I'll be glad to do it.
 The patch in your link was not in my tree at the time I've tested, if 
 that is relevant in any way.

Maybe you were looking to poky repo instead of oe-core?

Find poky equivalent of
http://git.openembedded.org/openembedded-core/commit/?id=2e79fcd673dadeab6358fe22d47c8534c14de03e

The issue reported in that email was fixed
http://git.openembedded.org/openembedded-core/commit/?id=f78044f85ab1a0acce852a7032fc0c81285cd4c1

What I was intereseted is whether upstream added similar patch to
http://git.shr-project.org/git/?p=meta-smartphone.git;a=blob;f=meta-nokia/recipes-bsp/u-boot/u-boot/0001-config-Always-use-GNU-ld.patch
or added other fix to make gold usable for u-boot.

And you can test build with gold if you enable gold by adding ld-is-gold
to DISTRO_FEATURES.

Cheers,

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] u-boot: Upgrade to upstream stable 2012.07

2012-08-06 Thread Wolfgang Denk

Dear Radu,

In message 501f63ff.1070...@intel.com you wrote:

  Actually a plain
 
  make NAME
 
  does the same as make NAME_config  make all.
 
  You might also consider running ./MAKEALL NAME instead, which
  aut-adjusts to te number of available cores on the build host, so you
  get somewhat reduced build times.
 
 I've tried to build this way but got into some errors and did not 
 pursued further in debugging them. However, because UBOOT_MACHINE is 

Could you please tell me exactly what these errors were?  Log files
etc. highly appreciated...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If programming was easy, they wouldn't need something as  complicated
as a human being to do it, now would they?
   - L. Wall  R. L. Schwartz, _Programming Perl_

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/5] gtk-icon-cache: call postinst scriplet at do_rootfs time

2012-08-06 Thread Laurentiu Palcu

On 08/06/2012 01:49 AM, Andreas Müller wrote:
On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller
schnitzelt...@googlemail.com wrote:
On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu
laurentiu.pa...@intel.com wrote:
You could give it a test yourselves and let me know your results. I will
send a version 2 of the patchset(as soon as we all agree on the
solution), with some changes suggested by Mark and some PR bumps
suggested by Koen.
With the image I usually work with [1] and AMD Phenom II X6 1090 16GB
RAM I get a measurable delay - see attachment. I would not be happy
loosing latest do_rootfs enhancements (off topic - thanks for that).
Remeber we are only talking of gtk-update-icon-cache. OK I could buy
an intel host and work just with sato images but...
I suppose you could, but nobody asked you to do that, it's your choice
what's your build machine or what you'll be building for.

Thanks for the measurements though. They do, indeed, show quite a
significant amount of time (around 6 minutes). A run-once solution is to
be considered in this case.

Andreas

[1]
https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
OK I know it is not that important: The image created with this patch
series creates tons of messages like
Why do you think is not important. Please elaborate. Or is it irony? I
don't think is in anybody's benefit if you take this approach. :) All
errors/warnings are important and they have to be taken care of.

xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or
directory

and don't have icons at all. Did you run test that (on a hardware
plattform different to your host)?
I only tested on qemu. And it worked just fine, without any errors. With
all icons in place.

Andreas

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/5] gtk-icon-cache: call postinst scriplet at do_rootfs time

2012-08-06 Thread Andreas Müller

On Mon, Aug 6, 2012 at 9:48 AM, Laurentiu Palcu
laurentiu.pa...@intel.com wrote:

Thanks for the measurements though. They do, indeed, show quite a
significant amount of time (around 6 minutes). A run-once solution is to
be considered in this case.

Andreas

[1]
https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
OK I know it is not that important: The image created with this patch
series creates tons of messages like
Why do you think is not important. Please elaborate. Or is it irony?
Yes sorry - it was late night.
I don't think is in anybody's benefit if you take this approach. :) All
errors/warnings are important and they have to be taken care of.

xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or
directory

Andreas

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/5] gtk-icon-cache: call postinst scriplet at do_rootfs time

2012-08-06 Thread Laurentiu Palcu

On 08/06/2012 11:10 AM, Andreas Müller wrote:
On Mon, Aug 6, 2012 at 9:48 AM, Laurentiu Palcu
laurentiu.pa...@intel.com wrote:

Thanks for the measurements though. They do, indeed, show quite a
significant amount of time (around 6 minutes). A run-once solution is to
be considered in this case.

Andreas

[1]
https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
OK I know it is not that important: The image created with this patch
series creates tons of messages like
Why do you think is not important. Please elaborate. Or is it irony?
Yes sorry - it was late night.
It's OK, let's work together and find the best solution for all of us. I
would also be pissed of if I had to wait an extra 6 minutes every
do_rootfs run.

I don't think is in anybody's benefit if you take this approach. :) All
errors/warnings are important and they have to be taken care of.

xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or
directory

and don't have icons at all. Did you run test that (on a hardware
plattform different to your host)?
I only tested on qemu. And it worked just fine, without any errors. With
all icons in place.
Which hardware did you emulate? My tests were done for overo (ARM
cortext A8). I wonder if the created database is machine specific.
I used qemuarm. As far as I know, the database shouldn't be machine
specific. And, looking at the log you sent, it looks like all commands
succeeded. Otherwise, the 'time' application would also signal in the
log file if the command failed. Could please have a look, on your host
(xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor or
xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome), to see if it
creates the icon-theme.cache files? It does for me and I don't
understand why it doesn't in your case...

Thanks,
Laurentiu

Andreas

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] package-index: inherit pythonnative

On Tue, Jul 24, 2012 at 11:49:52AM +0100, Richard Purdie wrote:
 On Tue, 2012-07-24 at 18:19 +0800, Robert Yang wrote:
  The native python binary has been moved from usr/bin/python to
  usr/bin/python-native/python, the recipe which needs python-native
  should inherit pythonnative, otherwise there would be errors when the
  python script runs.
  
  [YOCTO #2822]
  
  Signed-off-by: Robert Yang liezhi.y...@windriver.com
  ---
   meta/recipes-core/meta/package-index.bb |2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
 
 Which part of this recipe needs python-native? Shouldn't scripts which
 need pythonnative be using the path to the python interpreter
 explicitly?

This fixes my opkg-utils related issues too
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026333.html

The problem is that with pythonnative in opkg-utils it's still using 
#!/usr/bin/env python
in tmp-eglibc/sysroots/x86_64-linux/usr/bin/opkg-make-index

And when python-index executes this:
| + [ -e 
/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/deploy/ipk/ ]
| + touch 
/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/deploy/ipk/Packages
| + flock 
/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/deploy/ipk/Packages.flock
 -c opkg-make-index -r 
/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/deploy/ipk/Packages
 -p 
/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/deploy/ipk/Packages
 -m /var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/deploy/ipk/
| Traceback (most recent call last):

It depends on PATH of package-index not opkg-utils.

Cheers,

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/5] sato-icon-theme: make postinst scriplet run at do_rootfs time

2012-08-06 Thread Burton, Ross

On 3 August 2012 21:19, Laurentiu Palcu laurentiu.pa...@intel.com wrote:
  pkg_postinst_${PN} () {
 -if [ x$D != x ]; then
 -exit 1
 +gtk-update-icon-cache -q $D/usr/share/icons/Sato
 +if [ ! -d $D/etc/gtk-2.0 ]; then
 +mkdir -p $D/etc/gtk-2.0
  fi
 -gtk-update-icon-cache -q /usr/share/icons/Sato
 -echo 'gtk-icon-theme-name = Sato'  /etc/gtk-2.0/gtkrc
 +echo 'gtk-icon-theme-name = Sato'  $D/etc/gtk-2.0/gtkrc
  }

Surely sato-icon-theme should be inheriting the gtk-icon-cache class
to remove all of the duplicated logic?

Ross

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] opkg-utils: inherit pythonnative

On Sun, Aug 05, 2012 at 12:24:12PM +0200, Martin Jansa wrote:
 Signed-off-by: Martin Jansa martin.ja...@gmail.com
 ---
  meta/recipes-devtools/opkg-utils/opkg-utils_git.bb |4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)
 
 diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb 
 b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
 index 92e6624..caa66f7 100644
 --- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
 +++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
 @@ -8,7 +8,9 @@ RDEPENDS_${PN} = python
  RDEPENDS_${PN}_virtclass-native = 
  SRCREV = 49cc783d8e0415059d126ae22c892988717ffda7
  PV = 0.1.8+git${SRCPV}
 -PR = r0
 +PR = r1
 +
 +inherit pythonnative
  
  SRC_URI = git://git.yoctoproject.org/opkg-utils;protocol=git \
 

Please ignore this patch, this needs to be in package-index recipe (and
I had both patches when testing this :/)

Cheers,
-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/5] gtk-icon-cache: call postinst scriplet at do_rootfs time

2012-08-06 Thread Burton, Ross

On 6 August 2012 10:18, Laurentiu Palcu laurentiu.pa...@intel.com wrote:
 Which hardware did you emulate? My tests were done for overo (ARM
 cortext A8). I wonder if the created database is machine specific.

 I used qemuarm. As far as I know, the database shouldn't be machine
 specific.

Looking at updateiconcache.c, all of the functions that write data to
the cache file use write_card16, write_card32 and so on which convert
to big-endian.  Unless there's a bug hidden away, the cache files are
cross-platform.

Ross

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/5] gtk-icon-cache: call postinst scriplet at do_rootfs time

2012-08-06 Thread Andreas Müller

On Mon, Aug 6, 2012 at 11:18 AM, Laurentiu Palcu
laurentiu.pa...@intel.com wrote:

On 08/06/2012 11:10 AM, Andreas Müller wrote:
On Mon, Aug 6, 2012 at 9:48 AM, Laurentiu Palcu
laurentiu.pa...@intel.com wrote:

Thanks for the measurements though. They do, indeed, show quite a
significant amount of time (around 6 minutes). A run-once solution is to
be considered in this case.

Andreas

[1]
https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
OK I know it is not that important: The image created with this patch
series creates tons of messages like
Why do you think is not important. Please elaborate. Or is it irony?
Yes sorry - it was late night.
It's OK, let's work together and find the best solution for all of us. I
would also be pissed of if I had to wait an extra 6 minutes every
do_rootfs run.

I don't think is in anybody's benefit if you take this approach. :) All
errors/warnings are important and they have to be taken care of.

xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or
directory

I will check today evening since the machine with this data is at home...

Andreas

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH] gcc-cross-initial: Ensure it uses an isolated sysroot

If we don't do this, a stale limits.h may be detected in STAGING_DIR_TARGET
which would result in a different limits.h getting generated by 
gcc-cross-initial
that references it. The referenced limits.h will then not get found by 
eglibc-initial
causing rather strange build failures.

The simplest solution is to create a temporary sysroot containing only the 
things
gcc-cross-initial should care about and this results in a correct limits.h file
regardless of what else may have been built.

Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-devtools/gcc/gcc-cross-initial.inc 
b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
index a515fb0..543a94a 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-initial.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
@@ -19,11 +19,23 @@ EXTRA_OECONF = --with-newlib \
 ${OPTSPACE} \
--program-prefix=${TARGET_PREFIX} \
--with-sysroot=${STAGING_DIR_TARGET} \
-   --with-build-sysroot=${STAGING_DIR_TARGET} \
+   --with-build-sysroot=${GCCCROSS_BUILDSYSROOT} \
${EXTRA_OECONF_INITIAL} \
${@base_contains('DISTRO_FEATURES', 'ld-is-gold', 
'--with-ld=${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}ld.bfd', '', d)} \
${EXTRA_OECONF_FPU}
 
+
+GCCCROSS_BUILDSYSROOT = ${B}/tmpsysroot
+
+do_configure_prepend () {
+   sysr=${GCCCROSS_BUILDSYSROOT}${target_includedir}
+   mkdir -p $sysr
+   for t in linux asm asm-generic; do
+   rm -f $sysr/$t
+   ln -s ${STAGING_DIR_TARGET}${target_includedir}/$t $sysr/
+   done
+}
+
 do_compile () {
 oe_runmake all-gcc all-target-libgcc
 }



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH] curl: disable ldap/ldaps explicitly

* openldap from meta-oe is autodetected and then libldap-2.4-2 runtime 
dependency added to curl and almost all meta-efl recipes

Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
 meta/recipes-support/curl/curl_7.26.0.bb |   12 +++-
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-support/curl/curl_7.26.0.bb 
b/meta/recipes-support/curl/curl_7.26.0.bb
index f04b400..418e29c 100644
--- a/meta/recipes-support/curl/curl_7.26.0.bb
+++ b/meta/recipes-support/curl/curl_7.26.0.bb
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = 
file://COPYING;beginline=7;md5=3a34942f4ae3fbf1a303160714e66
 DEPENDS = zlib gnutls
 DEPENDS_virtclass-native = zlib-native openssl-native
 DEPENDS_virtclass-nativesdk = zlib-nativesdk
-PR = r0
+PR = r1
 
 SRC_URI = http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://pkgconfig_fix.patch
@@ -20,11 +20,13 @@ inherit autotools pkgconfig binconfig
 
 EXTRA_OECONF = --with-zlib=${STAGING_LIBDIR}/../ \
 --without-libssh2 \
-   --with-random=/dev/urandom \
-   --without-libidn \
-   --enable-crypto-auth \
+--with-random=/dev/urandom \
+--without-libidn \
+--enable-crypto-auth \
+--disable-ldap \
+--disable-ldaps \
 ${CURLGNUTLS} \
-   
+
 
 CURLGNUTLS =  --with-gnutls=${STAGING_LIBDIR}/../ --without-ssl
 CURLGNUTLS_virtclass-native = --without-gnutls --with-ssl
-- 
1.7.8.6


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V3 00/11] Mesa upgrade/improvements

On Fri, 2012-08-03 at 17:46 +0200, Koen Kooi wrote:
Op 3 aug. 2012, om 15:19 heeft Ross Burton ross.bur...@intel.com het
volgende geschreven:

On Friday, 3 August 2012 at 11:18, Koen Kooi wrote:
libegl and libgles aren't built nowadays, so the problem is
avoided. Noone has dared to touch this subject the past 2.5 years:
http://cgit.openembedded.org/openembedded/commit/recipes/mesa?id=3d96f8cb61225d515b5cb4fe863f0d50c3ced436

The best solution[1] is to disable egl/gles in the mesa-recipes and
add a seperate recipe for them. That way you still get glu and other
useful mesa bits needed for gnome/efl/xfce/etc, but you can skip the
sysroot/shlib poisoning if needed.
After much digging I see that the Beagle PVR drivers only provide
gles and egl, which is why you say that the problem was avoided. Of
course that's just one specific driver, for example the Cedar Trail
EMGD driver does build libgl, libgles and libegl.

If the solution is put the egl/gles bits in another package

Recipe, not package. Big difference :)

then I'm totally confused as to what the actual problem is.
Considering there's numerous libegl libraries for the many variants of
PVR on ARM, I'm struggling to understand exactly what is new here.

Can you explain clearly what the problem is, I'm obviously missing
something. Once I understand the problem I can help with a solution.

You need mesa for the !egl and !gles libs and evil vendor blob for egl
and gles libs. In the emgd case you can get gl from the evil vendor as
well. To build e.g. EFL I need mesa for the !egl and !gles bits, to
build EFL with gles support I need mesa (again !egl, !gles) in
addition to evil vendor blob for egl and gles.
We could make this work with MACHINE_FEATURES or something similar,
but that would mean that a very large chunk of userspace now becomes
machine specific. This is how clutter worked in the past and just look
at the fit the canonical/linaro people threw when they started doing
'embedded' and clutter.

To compress the above: you need to build both the mesa and the
evil-egl-binary *recipes* for things to work, so the egl bits should
be a different recipe, not a subpackage of the mesa recipe. This is
all assuming we care abou the binary blobs e.g. TI distributes for 3d
support. If you don't, fine, merge this patchset.

Let me test this a little bit more. The binary blobs shipped by TI would
be machine specific and would be marked as such in the package feeds?
The mesa pieces would be marked as architecture specific and more
generic. In feeds, machine specific has priority so on the machines
where there is hardware support, the hardware optimised versions would
get installed?

If the above isn't the case, can we make it work like that?

Cheers,

Richard

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] Could we build tar-replacement firstly and not parallel if tar-replacement is needed to build

2012-08-06 Thread Rongqing Li


Hi:

Building failed several times when building tar-replacement-native is 
needed,
The error log shows 
bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/tar: Text
file busy. this log proves an attempt was made to execute a 
pure-procedure

program that is currently open for writing.


Before this error, tar-replacement do_populate_sysroot just starts,
(tar-replacement-native-1.26-r2: task do_populate_sysroot: Started)
After this error, we see tar-replacement do_populate_sysroot just
finish.

So I think the root cause is that do_populate_sysroot sqlite is using
a tar command which being opened to written. in fact, all packages
need tar to do_popolate_sysroot()

I see building tar-replacement-native is started in bitbake file,
could we build tar-replacement firstly, not parallel if needed.



diff --git a/scripts/bitbake b/scripts/bitbake
index 3772d82..1bb8fed 100755
--- a/scripts/bitbake
+++ b/scripts/bitbake
@@ -134,7 +134,10 @@ if [ $buildpseudo -gt 0 ]; then
 fi
 done
 done
-bitbake pseudo-native $TARTARGET $additionalopts -c populate_sysroot
+
+if [ $needptar = 1 ]; then
+   sed -i 's/BB_NUMBER_THREADS =/#BB_NUMBER_THREADS =/g' 
conf/local.conf

+   bitbake $TARTARGET
+   sed -i 's/#BB_NUMBER_THREADS =/BB_NUMBER_THREADS =/g' 
conf/local.conf

+fi
+
+bitbake pseudo-native $additionalopts -c populate_sysroot
 ret=$?
 if [ $ret != 0 ]; then
 exit 1


since building tar-replacement or not depends on host tar version, it is
hard to add a tar dependence to any package, and I did not have a good way
to fix this bug except the upper.

Any advice and suggestion are welcome


--
Best Reagrds,
Roy | RongQing Li


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] gdk-pixbuf: fix parallel install issue

On Sun, 2012-08-05 at 18:32 -0400, Colin Walters wrote:
 On Fri, 2012-08-03 at 11:30 +0800, wenzong@windriver.com wrote:
 
  Make an explicit dependency to the libs install targets would fix this
  issue.
 
 I don't think Yocto should be running the 'make install' target with
 parallelism enabled; it's just going to be a source of major pain for
 small gain.  Historically Automake's install targets have had a lot of
 paralleism issues AIUI, even discarding modules which have custom
 install hooks.

We did used to steer clear of this but more recently tested it out and
with a few exceptions (which we disabled with PARALLEL_MAKEINST=),
parallel make install seems to work fine and did give a small but
measurable speed-up (I'd have to look at the archives to remember what).

It helps that we use the latest automake everywhere and regenerate all
the makefiles ourselves.

So whilst I agree with this from a historical perspective, times so seem
to be changing and improving. If there are issues I do want to know
about and deal with them though.

Cheers,

Richard






___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH] pango: upgrade to upstream stable 1.30.0

Signed-off-by: Radu Moisan radu.moi...@intel.com
---
 .../pango/pango-1.28.4/noconst.patch   |  408 
 .../multilib-fix-clean.patch   |0
 .../{pango-1.28.4 = pango-1.30.0}/no-tests.patch  |   14 +-
 .../pango/{pango_1.28.4.bb = pango_1.30.0.bb} |9 +-
 4 files changed, 10 insertions(+), 421 deletions(-)
 delete mode 100644 meta/recipes-graphics/pango/pango-1.28.4/noconst.patch
 rename meta/recipes-graphics/pango/{pango-1.28.4 = 
pango-1.30.0}/multilib-fix-clean.patch (100%)
 rename meta/recipes-graphics/pango/{pango-1.28.4 = 
pango-1.30.0}/no-tests.patch (33%)
 rename meta/recipes-graphics/pango/{pango_1.28.4.bb = pango_1.30.0.bb} (49%)

diff --git a/meta/recipes-graphics/pango/pango-1.28.4/noconst.patch 
b/meta/recipes-graphics/pango/pango-1.28.4/noconst.patch
deleted file mode 100644
index d4832a5..000
--- a/meta/recipes-graphics/pango/pango-1.28.4/noconst.patch
+++ /dev/null
@@ -1,408 +0,0 @@
-G_CONST_RETURN is deprecated in glib 2.30 so remove to to avoid
-build failures.
-
-RP 2011/10/12
-
-Upstream-Status: Pending
-
-Index: pango-1.28.4/pango/fonts.c
-===
 pango-1.28.4.orig/pango/fonts.c2011-10-12 01:32:09.372046342 +0100
-+++ pango-1.28.4/pango/fonts.c 2011-10-12 01:32:34.512036630 +0100
-@@ -165,7 +165,7 @@
-  *   %NULL if not previously set.  This has the same life-time
-  *   as the font description itself and should not be freed.
-  **/
--G_CONST_RETURN char *
-+const char *
- pango_font_description_get_family (const PangoFontDescription *desc)
- {
-   g_return_val_if_fail (desc != NULL, NULL);
-@@ -1927,7 +1927,7 @@
-  * Return value: the name of the family. This string is owned
-  *   by the family object and must not be modified or freed.
-  **/
--G_CONST_RETURN char *
-+const char *
- pango_font_family_get_name (PangoFontFamily  *family)
- {
-   g_return_val_if_fail (PANGO_IS_FONT_FAMILY (family), NULL);
-@@ -2060,7 +2060,7 @@
-  * Return value: the face name for the face. This string is
-  *   owned by the face object and must not be modified or freed.
-  **/
--G_CONST_RETURN char *
-+const char *
- pango_font_face_get_face_name (PangoFontFace *face)
- {
-   g_return_val_if_fail (PANGO_IS_FONT_FACE (face), NULL);
-Index: pango-1.28.4/pango/pango-attributes.c
-===
 pango-1.28.4.orig/pango/pango-attributes.c 2011-10-12 01:32:09.552046155 
+0100
-+++ pango-1.28.4/pango/pango-attributes.c  2011-10-12 01:32:34.522037975 
+0100
-@@ -97,7 +97,7 @@
-  *
-  * Since: 1.22
-  **/
--G_CONST_RETURN char *
-+const char *
- pango_attr_type_get_name (PangoAttrType type)
- {
-   const char *result = NULL;
-Index: pango-1.28.4/pango/pango-attributes.h
-===
 pango-1.28.4.orig/pango/pango-attributes.h 2011-10-12 01:32:12.712046218 
+0100
-+++ pango-1.28.4/pango/pango-attributes.h  2011-10-12 01:32:36.342045777 
+0100
-@@ -180,7 +180,7 @@
- };
- 
- PangoAttrType pango_attr_type_register (const gchar*name);
--G_CONST_RETURN char * pango_attr_type_get_name (PangoAttrType   type) 
G_GNUC_CONST;
-+const char * pango_attr_type_get_name (PangoAttrType   type) G_GNUC_CONST;
- 
- void pango_attribute_init(PangoAttribute   *attr,
- const PangoAttrClass *klass);
-Index: pango-1.28.4/pango/pango-context.c
-===
 pango-1.28.4.orig/pango/pango-context.c2011-10-12 01:32:09.782046152 
+0100
-+++ pango-1.28.4/pango/pango-context.c 2011-10-12 01:32:34.532039187 +0100
-@@ -188,7 +188,7 @@
-  *
-  * Since: 1.6
-  **/
--G_CONST_RETURN PangoMatrix *
-+const PangoMatrix *
- pango_context_get_matrix (PangoContext *context)
- {
-   g_return_val_if_fail (PANGO_IS_CONTEXT (context), NULL);
-Index: pango-1.28.4/pango/pango-context.h
-===
 pango-1.28.4.orig/pango/pango-context.h2011-10-12 01:32:12.892046153 
+0100
-+++ pango-1.28.4/pango/pango-context.h 2011-10-12 01:32:36.352046105 +0100
-@@ -86,7 +86,7 @@
- 
- voidpango_context_set_matrix (PangoContext  
*context,
- const PangoMatrix 
*matrix);
--G_CONST_RETURN PangoMatrix *pango_context_get_matrix (PangoContext  
*context);
-+const PangoMatrix *pango_context_get_matrix (PangoContext  *context);
- 
- /* Break a string of Unicode characters into segments with
-  * consistent shaping/language engine and bidrectional level.
-Index: pango-1.28.4/pango/pango-font.h
-===
 pango-1.28.4.orig/pango/pango-font.h   2011-10-12 01:32:13.072046150 
+0100
-+++ pango-1.28.4/pango/pango-font.h2011-10-12

Re: [OE-core] [oe-core][RFC] bitbake.conf: exclude whole MACHINEOVERRIDES from OVERRIDES vardeps

On Sun, 2012-08-05 at 12:31 +0200, Martin Jansa wrote:
 On Mon, Jul 23, 2012 at 08:48:52AM -0700, Chris Larson wrote:
  On Mon, Jul 23, 2012 at 8:45 AM, Richard Purdie
  richard.pur...@linuxfoundation.org wrote:
   On Mon, 2012-07-23 at 16:25 +0200, Martin Jansa wrote:
   * whole MACHINEOVERRIDES can change e.g. between MACHINES with different 
   arm architecture, causing allarch packages to reexecute do_package
 bitbake-diffsigs 
   ../shr-core/tmp-eglibc/stamps/all-oe-linux/xserver-nodm-init-2.0-r16.do_package.sigdata.90e760a8f6cecbd87cb2e95f1237e3cc

   ../shr-core/tmp-eglibc/stamps/all-oe-linux/xserver-nodm-init-2.0-r16.do_package.sigdata.9eeccfd15f25032b3b6b132534660fff
 basehash changed from 7618e17d3fda05d1f15246e6800ca0f0 to 
   97bc4dc8c1521c535bd96b2aa62d8a03
 Variable MACHINEOVERRIDES value changed from 
   ${MACHINE}${@bb.utils.contains(TUNE_FEATURES, armv5, :armv5,  
   ,d)}${@bb.utils.contains(TUNE_FEATURES, armv4, :armv4,  
   ,d)}:${MACHINE_CLASS} to ${MACHINE}${@bb.utils.contains(TUNE_FEATURES, 
   armv7a, :armv7a,  ,d)}${@bb.utils.contains(TUNE_FEATURES, 
   armv6, :armv6,  ,d)}${@bb.utils.contains(TUNE_FEATURES, armv5, 
   :armv5,  ,d)}${@bb.utils.contains(TUNE_FEATURES, armv4, 
   :armv4,  ,d)}:${MACHINE_CLASS}
  
   Signed-off-by: Martin Jansa martin.ja...@gmail.com
   ---
meta/conf/bitbake.conf |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
  
   Won't this hide genuine changes where things should get rebuilt too?
  
  If something uses a machine override, won't the overridden value for
  that variable be the one which is stored in the checksum? So any
  effects of this will result in checksum modification anyway, no?
 
 I think it was possible to find different local file in SRC_URI (in
 different override subdirectory), but now with local file checksums
 included in sstate checksum it should be safe too.

Yes, I think this should be safe now and will take the patch.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V3 00/11] Mesa upgrade/improvements

2012-08-06 Thread Koen Kooi

Op 6 aug. 2012, om 14:43 heeft Richard Purdie
richard.pur...@linuxfoundation.org het volgende geschreven:

On Fri, 2012-08-03 at 17:46 +0200, Koen Kooi wrote:
Op 3 aug. 2012, om 15:19 heeft Ross Burton ross.bur...@intel.com het
volgende geschreven:

If the solution is put the egl/gles bits in another package

Recipe, not package. Big difference :)

then I'm totally confused as to what the actual problem is.
Considering there's numerous libegl libraries for the many variants of
PVR on ARM, I'm struggling to understand exactly what is new here.

Can you explain clearly what the problem is, I'm obviously missing
something. Once I understand the problem I can help with a solution.

Let me test this a little bit more. The binary blobs shipped by TI would
be machine specific

They aren't machine specific, they contain multiple blobs to support a wide
range of SoCs. But even if they were machine specific it wouldn't work like you
want to.

and would be marked as such in the package feeds?
The mesa pieces would be marked as architecture specific and more
generic. In feeds, machine specific has priority so on the machines
where there is hardware support, the hardware optimised versions would
get installed?

You're assuming all libraries are subpackaged into their own package and
renamed identically, they aren't (which is actually a feature in the current
situation).

If the above isn't the case, can we make it work like that?

We can't. Even if we could, it would be a giant step backwards for people using
the output of the build (see below).

The only solution that keeps the good things of the current situation is to
have the following recipes:

1) mesa (does not build libgl or libgles)
2) mesa-gles (only builds libgl+libgles)
3) evil-vendor-blob

And you can specify per SoC something like PREFERRED_PROVIDER_virtual/egl =
mesa-gles or PREFERRED_PROVIDER_virtual/egl = evil-vendor-blob.

That will cause problems if you are building for 2 SoCs in the same
architecture family that need different gl providers, the shlib code might get
a bit upset. I don't have a good solution for that, but we have that problem
right now as well.

From the build side we could make it a bit prettier by making all the gl stuff
machine specific, but that will be a giant pain in the ass for the end user
(distro maintainer, $silicon_vendor customer, $silicon_vendor SDK). If we end
up doing it like that, we'll need buy-in from the silicon vendors involved to
change the way they distribute their blobs. That is doable, I managed to get
the TI blobs changed a few times in the past, but it's a slow process.
And everything using GL would suddenly be machine specific, I hope the yocto
autobuilder can keep up with that.

Executive summary: ARM SoCs with 3d suck, Intel parts with 3d sucks less. It's
a mess in oe-core.

regards,

Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] gdk-pixbuf: fix parallel install issue

2012-08-06 Thread Koen Kooi


Op 6 aug. 2012, om 00:32 heeft Colin Walters walt...@verbum.org het volgende 
geschreven:

 On Fri, 2012-08-03 at 11:30 +0800, wenzong@windriver.com wrote:
 
 Make an explicit dependency to the libs install targets would fix this
 issue.
 
 I don't think Yocto should be running the 'make install' target with
 parallelism enabled

You mean oe-core, right?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] u-boot: Upgrade to upstream stable 2012.07


I may be recipe configuration, however, here are my steps:

bitbake u-boot -c cleanall
bitbake u-boot -c fetch
bitbake -c devshell u-boot

in the new shell

make coreboot-x86 (without _config)

The output I got is as follows:

Configuring for coreboot-x86 - Board: coreboot, Options: 
SYS_TEXT_BASE=0xFC

make
/bin/bash: i386-linux-gcc: command not found
/bin/bash: i386-linux-gcc: command not found
basename: missing operand
Try `basename --help' for more information.
make[1]: Entering directory 
`/home/radu/Documents/Development/yocto/build/tmp/work/qemux86-poky-linux/u-boot-2012.07-r0/git'

/bin/bash: i386-linux-gcc: command not found
basename: missing operand
Try `basename --help' for more information.
/bin/bash: i386-linux-gcc: command not found
basename: missing operand
Try `basename --help' for more information.
Generating include/autoconf.mk
/bin/bash: line 3: i386-linux-gcc: command not found
/bin/bash: i386-linux-gcc: command not found
basename: missing operand
Try `basename --help' for more information.
/bin/bash: i386-linux-gcc: command not found
basename: missing operand
Try `basename --help' for more information.
Generating include/autoconf.mk.dep
/bin/bash: line 3: i386-linux-gcc: command not found
make[1]: Leaving directory 
`/home/radu/Documents/Development/yocto/build/tmp/work/qemux86-poky-linux/u-boot-2012.07-r0/git'

/bin/bash: i386-linux-gcc: command not found
/bin/bash: i386-linux-gcc: command not found
basename: missing operand
Try `basename --help' for more information.
make[1]: Entering directory 
`/home/radu/Documents/Development/yocto/build/tmp/work/qemux86-poky-linux/u-boot-2012.07-r0/git'

/bin/bash: i386-linux-gcc: command not found
basename: missing operand
Try `basename --help' for more information.
/bin/bash: i386-linux-gcc: command not found
basename: missing operand
Try `basename --help' for more information.
/bin/bash: i386-linux-gcc: command not found
/bin/bash: i386-linux-ld: command not found
/bin/bash: i386-linux-gcc: command not found
basename: missing operand
Try `basename --help' for more information.
/bin/bash: i386-linux-gcc: command not found
basename: missing operand
Try `basename --help' for more information.
/bin/bash: i386-linux-gcc: command not found
basename: missing operand
Try `basename --help' for more information.
/bin/bash: i386-linux-gcc: command not found
basename: missing operand
Try `basename --help' for more information.
i386-linux-gcc -DDO_DEPS_ONLY \
-g  -Os   -ffunction-sections -fvisibility=hidden -D__KERNEL__ 
-I/home/radu/Documents/Development/yocto/build/tmp/work/qemux86-poky-linux/u-boot-2012.07-r0/git/include 
-fno-builtin -ffreestanding -nostdinc -isystem  -pipe 
-fno-strict-aliasing -Wstrict-prototypes -mregparm=3 
-fomit-frame-pointer -ffreestanding -fno-toplevel-reorder 
-fno-stack-protector  -fno-dwarf2-cfi-asm -DREALMODE_BASE=0x7c0 
-DCONFIG_X86 -D__I386__ -march=i386 -Werror -Wall -Wstrict-prototypes 
-fno-stack-protector  \

-o lib/asm-offsets.s lib/asm-offsets.c -c -S
/bin/bash: i386-linux-gcc: command not found
make[1]: *** [lib/asm-offsets.s] Error 127
make[1]: Leaving directory 
`/home/radu/Documents/Development/yocto/build/tmp/work/qemux86-poky-linux/u-boot-2012.07-r0/git'

make: *** [coreboot-x86] Error 2

However this is the same out as when I do

make coreboot-x86_config
make all

This happens only when I'm trying to build inside the devshell, which 
lead me to believe that maybe the environment is not set completely,  
until at do_compile.


radu


On 08/06/2012 10:45 AM, Wolfgang Denk wrote:

Dear Radu,

In message 501f63ff.1070...@intel.com you wrote:

Actually a plain

make NAME

does the same as make NAME_config  make all.

You might also consider running ./MAKEALL NAME instead, which
aut-adjusts to te number of available cores on the build host, so you
get somewhat reduced build times.

I've tried to build this way but got into some errors and did not
pursued further in debugging them. However, because UBOOT_MACHINE is

Could you please tell me exactly what these errors were?  Log files
etc. highly appreciated...

Best regards,

Wolfgang Denk



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-commits] Bogdan Marinescu : autoconf: updated to 2.69

On Wed, Jul 25, 2012 at 02:18:11PM +0200, Martin Jansa wrote:
 On Sun, Jul 22, 2012 at 10:44:06AM +, g...@git.openembedded.org wrote:
  Module: openembedded-core.git
  Branch: master
  Commit: effb75d42098b3e367d393215fd5d52a0191e954
  URL:
  http://git.openembedded.org/?p=openembedded-core.gita=commit;h=effb75d42098b3e367d393215fd5d52a0191e954
  
  Author: Bogdan Marinescu bogdan.a.marine...@intel.com
  Date:   Thu Jul 19 13:33:52 2012 +0300
  
  autoconf: updated to 2.69
  
  Tested with core-image-sato-sdk and lib32-core-image-sato-sdk.
  This update was done mainly because multilib builds failed on master with 
  this error:
  
  | autoreconf: running: aclocal -I 
  /poky/build/tmp/work/x86-pokymllib32-linux/lib32-automake-1.12.1-r0/automake-1.12.1/m4/
   -I /poky/build/tmp/sysroots/x86_64-linux/usr/share/aclocal-1.12 -I 
  /poky/build/tmp/work/x86-pokymllib32-linux/lib32-automake-1.12.1-r0/automake-1.12.1/aclocal-copy/
   -I 
  /poky/build/tmp/work/x86-pokymllib32-linux/lib32-automake-1.12.1-r0/automake-1.12.1/m4/
   -I /poky/build/tmp/sysroots/x86_64-linux/usr/share/aclocal-1.12 -I 
  /poky/build/tmp/work/x86-pokymllib32-linux/lib32-automake-1.12.1-r0/automake-1.12.1/aclocal-copy/
   --force --warnings=cross
  | aclocal: warning: unknown warning category 'cross'
  | configure.ac:18: error: Autoconf version 2.69 or higher is required
 
 since this upgrade I see autom4te segfaulting when building webkit-efl
 autom4te[8513]: segfault at 29e782688 ip 7f7c52a96e23 sp 7fff07731020 
 error 4 in Dumper.so[7f7c52a9+8000]
 
 webkit-efl build finishes fine and is usable afaik but someone would
 expect tools like autoconf to behave better and not segfault.
 
 This happens on 2 different builders each with different webkit-efl
 version.

Nobody else have seen this in dmesg? It happens quite often and probably
not only while building webkit-efl. Because I don't build webkit-efl so
often:
dmesg | grep -c segfault at.*Dumper.so
37

It could be related to perl as Dumper.so is part of perl install
dev-lang/perl-5.16.0 
(/usr/lib64/perl5/5.16.0/x86_64-linux-thread-multi/auto/Data/Dumper/Dumper.so)

Maybe inheriting perlnative in autoconf would solve that too.

Cheers,

 
 Cheers,
 
  
  Signed-off-by: Bogdan Marinescu bogdan.a.marine...@intel.com
  Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
  
  ---
  
   meta/recipes-devtools/autoconf/autoconf.inc|2 +-
   .../{autoconf_2.68.bb = autoconf_2.69.bb} |4 ++--
   2 files changed, 3 insertions(+), 3 deletions(-)
  
  diff --git a/meta/recipes-devtools/autoconf/autoconf.inc 
  b/meta/recipes-devtools/autoconf/autoconf.inc
  index 2c07701..4f5a5b2 100644
  --- a/meta/recipes-devtools/autoconf/autoconf.inc
  +++ b/meta/recipes-devtools/autoconf/autoconf.inc
  @@ -12,7 +12,7 @@ RDEPENDS_${PN} = m4 gnu-config
   RDEPENDS_${PN}_virtclass-native = m4-native gnu-config-native
   RDEPENDS_${PN}_virtclass-nativesdk = m4-nativesdk gnu-config-nativesdk
   
  -SRC_URI = ${GNU_MIRROR}/autoconf/autoconf-${PV}.tar.bz2 \
  +SRC_URI = ${GNU_MIRROR}/autoconf/autoconf-${PV}.tar.gz \
 file://program_prefix.patch
   
   inherit autotools
  diff --git a/meta/recipes-devtools/autoconf/autoconf_2.68.bb 
  b/meta/recipes-devtools/autoconf/autoconf_2.69.bb
  similarity index 85%
  rename from meta/recipes-devtools/autoconf/autoconf_2.68.bb
  rename to meta/recipes-devtools/autoconf/autoconf_2.69.bb
  index 8d466e0..478f8ed 100644
  --- a/meta/recipes-devtools/autoconf/autoconf_2.68.bb
  +++ b/meta/recipes-devtools/autoconf/autoconf_2.69.bb
  @@ -17,8 +17,8 @@ SRC_URI += file://autoreconf-include.patch \
   file://remove-usr-local-lib-from-m4.patch \
  
   
  -SRC_URI[md5sum] = 864d785215aa60d627c91fcb21b05b07
  -SRC_URI[sha256sum] = 
  c491fb273fd6d4ca925e26ceed3d177920233c76d542b150ff35e571454332c8
  +SRC_URI[md5sum] = 82d05e03b93e45f5a39b828dc9c6c29b
  +SRC_URI[sha256sum] = 
  954bd69b391edc12d6a4a51a2dd1476543da5c6bbf05a95b59dc0dd6fd4c2969
   
   SRC_URI_append_virtclass-native =  file://fix_path_xtra.patch
   
  
  
  ___
  Openembedded-commits mailing list
  openembedded-comm...@lists.openembedded.org
  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits
 
 -- 
 Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com



-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] u-boot: Upgrade to upstream stable 2012.07

2012-08-06 Thread Wolfgang Denk

Dear Radu,

In message 501fc96a.8000...@intel.com you wrote:

 in the new shell
 
  make coreboot-x86 (without _config)
 
 The output I got is as follows:
 
 Configuring for coreboot-x86 - Board: coreboot, Options: 
 SYS_TEXT_BASE=0xFC
 make
 /bin/bash: i386-linux-gcc: command not found
 /bin/bash: i386-linux-gcc: command not found

It seems CROSS_COMPILE is set to i386-linux-, but i386-linux-gcc is
not anywhere in your PATH.  Please check your PATH and fix it.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Advice is seldom welcome; and those who want it the most always like
it the least. -- Philip Earl of Chesterfield

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V3 00/11] Mesa upgrade/improvements

On Mon, 2012-08-06 at 15:24 +0200, Koen Kooi wrote:
Op 6 aug. 2012, om 14:43 heeft Richard Purdie
richard.pur...@linuxfoundation.org het volgende geschreven:

On Fri, 2012-08-03 at 17:46 +0200, Koen Kooi wrote:
Op 3 aug. 2012, om 15:19 heeft Ross Burton ross.bur...@intel.com het
volgende geschreven:

If the solution is put the egl/gles bits in another package

Recipe, not package. Big difference :)

then I'm totally confused as to what the actual problem is.
Considering there's numerous libegl libraries for the many variants of
PVR on ARM, I'm struggling to understand exactly what is new here.

Can you explain clearly what the problem is, I'm obviously missing
something. Once I understand the problem I can help with a solution.

Let me test this a little bit more. The binary blobs shipped by TI would
be machine specific

They aren't machine specific, they contain multiple blobs to support a
wide range of SoCs. But even if they were machine specific it wouldn't
work like you want to.

You're assuming all libraries are subpackaged into their own package
and renamed identically, they aren't (which is actually a feature in
the current situation).

They don't have to be renamed identically, the would have to have
RPROVIDES that cover what is needed in some standard namespace.

If the above isn't the case, can we make it work like that?

We can't. Even if we could, it would be a giant step backwards for
people using the output of the build (see below).

The only solution that keeps the good things of the current situation
is to have the following recipes:

1) mesa (does not build libgl or libgles)
2) mesa-gles (only builds libgl+libgles)
3) evil-vendor-blob

And you can specify per SoC something like
PREFERRED_PROVIDER_virtual/egl = mesa-gles or
PREFERRED_PROVIDER_virtual/egl = evil-vendor-blob.

That will cause problems if you are building for 2 SoCs in the same
architecture family that need different gl providers, the shlib code
might get a bit upset. I don't have a good solution for that, but we
have that problem right now as well.

If we end up doing it like that, we'll need buy-in from the silicon
vendors involved to change the way they distribute their blobs. That
is doable, I managed to get the TI blobs changed a few times in the
past, but it's a slow process.
And everything using GL would suddenly be machine specific, I hope the
yocto autobuilder can keep up with that.

Everything does not have to become machine specific if the things in
question have known good portable APIs. As I understand it we have GL so
we can swap in the binary blobs in place of the generic ones without

Re: [OE-core] [PATCH][RFC] u-boot: Upgrade to upstream stable 2012.07

CROSS_COMPILE is set in EXTRA_OEMAKE which is used in oe-runmake() 
within do_compile()
Running devshell is achieved in do_devshell() which is run after 
do_patch() but before do_compile(), that's why in devshell CROSS_COMPILE 
is not (yet) set.
I think this is the intended way for things to work, devshell usage, as 
I see it, is mainly for pre-compile debugging purposes.


radu

On 08/06/2012 04:46 PM, Wolfgang Denk wrote:

Dear Radu,

In message 501fc96a.8000...@intel.com you wrote:

in the new shell

  make coreboot-x86 (without _config)

The output I got is as follows:

Configuring for coreboot-x86 - Board: coreboot, Options:
SYS_TEXT_BASE=0xFC
make
/bin/bash: i386-linux-gcc: command not found
/bin/bash: i386-linux-gcc: command not found

It seems CROSS_COMPILE is set to i386-linux-, but i386-linux-gcc is
not anywhere in your PATH.  Please check your PATH and fix it.

Best regards,

Wolfgang Denk



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] u-boot: Upgrade to upstream stable 2012.07

2012-08-06 Thread Wolfgang Denk

Dear Radu,

In message 501fd013.5040...@intel.com you wrote:

 CROSS_COMPILE is set in EXTRA_OEMAKE which is used in oe-runmake() 
 within do_compile()
 Running devshell is achieved in do_devshell() which is run after 
 do_patch() but before do_compile(), that's why in devshell CROSS_COMPILE 
 is not (yet) set.

But CROSS_COMPILE _is_ set (and apparently has the value
i386-linux-.

The problem is that PATH is not set such that it contains any such
file as i386-linux-gcc.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Beware of bugs in the above code; I have only proved it correct, not
tried it. - Donald Knuth

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V3 00/11] Mesa upgrade/improvements

On Thu, 2012-08-02 at 17:48 +0100, Ross Burton wrote:
 Re-arranged and fixed up some problems.
 
 The following changes since commit 62d42fe3cfa575cb97b484ccf7b2e9a25cc50770:
 
   tiny-init: Setup /dev/ptmx in init (2012-08-01 23:11:18 +0100)
 
 are available in the git repository at:
 
   git://git.yoctoproject.org/poky-contrib ross/mesa
 
 for you to fetch changes up to 5de29e150a720ccb8749362cfe5fb56f234fb385:
 
   mesa: enable EGL, with DRM and X11 platforms (2012-08-02 17:43:18 +0100)
 
 
 Damien Lespiau (2):
   mesa: Update to 8.0.4 (latest stable version)
   mesa: Use 'require' instead of 'include'
 
 Ross Burton (9):
   mesa: no need to depend on python-native, the class does that
   mesa: format the packages list nicely
   mesa: move glu.pc to libglu-dev
   mesa: add --enable-shared-glapi, and package it in libglapi
   mesa: enable the Graphic Buffer Manager library

I've merged the above since I don't think these are the contentious
part.

   mesa: enable GLES v1 and v2
   mesa-demos: fix GLES2 build
   mesa: respect x11 DISTRO_FEATURE
   mesa: enable EGL, with DRM and X11 platforms

I've left these for now for more discussion.

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] do_rootfs broken due to missing gcc-runtime

2012-08-06 Thread Enrico Scholz

Hi,

having something in the image which brings gcc-runtime-locale-XX in
causes do_rootfs to fail with:

 * satisfy_dependencies_for: Cannot satisfy the following dependencies for 
gcc-runtime-locale-de:
 *  gcc-runtime *
 * opkg_install_cmd: Cannot install package gcc-runtime-locale-de.


This happens for some time already and I saw a patch[1] on the list
which fixes it.  Any reason why it has not been applied yet?


Enrico

Footnotes: 
[1]  http://permalink.gmane.org/gmane.comp.handhelds.openembedded.core/24694


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V3 00/11] Mesa upgrade/improvements

2012-08-06 Thread Koen Kooi

Op 6 aug. 2012, om 16:04 heeft Richard Purdie
richard.pur...@linuxfoundation.org het volgende geschreven:

On Mon, 2012-08-06 at 15:24 +0200, Koen Kooi wrote:
Op 6 aug. 2012, om 14:43 heeft Richard Purdie
richard.pur...@linuxfoundation.org het volgende geschreven:

On Fri, 2012-08-03 at 17:46 +0200, Koen Kooi wrote:
Op 3 aug. 2012, om 15:19 heeft Ross Burton ross.bur...@intel.com het
volgende geschreven:

If the solution is put the egl/gles bits in another package

Recipe, not package. Big difference :)

then I'm totally confused as to what the actual problem is.
Considering there's numerous libegl libraries for the many variants of
PVR on ARM, I'm struggling to understand exactly what is new here.

Can you explain clearly what the problem is, I'm obviously missing
something. Once I understand the problem I can help with a solution.

Let me test this a little bit more. The binary blobs shipped by TI would
be machine specific

They aren't machine specific, they contain multiple blobs to support a
wide range of SoCs. But even if they were machine specific it wouldn't
work like you want to.

You're assuming all libraries are subpackaged into their own package
and renamed identically, they aren't (which is actually a feature in
the current situation).

They don't have to be renamed identically, the would have to have
RPROVIDES that cover what is needed in some standard namespace.

If the above isn't the case, can we make it work like that?

We can't. Even if we could, it would be a giant step backwards for
people using the output of the build (see below).

The only solution that keeps the good things of the current situation
is to have the following recipes:

1) mesa (does not build libgl or libgles)
2) mesa-gles (only builds libgl+libgles)
3) evil-vendor-blob

And you can specify per SoC something like
PREFERRED_PROVIDER_virtual/egl = mesa-gles or
PREFERRED_PROVIDER_virtual/egl = evil-vendor-blob.

That will cause problems if you are building for 2 SoCs in the same
architecture family that need different gl providers, the shlib code
might get a bit upset. I don't have a good solution for that, but we
have that problem right now as well.

Everything does not have to become machine specific if the things in
question have known good portable APIs. As I understand it we have GL so
we

Re: [OE-core] [oe-commits] Bogdan Marinescu : autoconf: updated to 2.69

On Mon, 2012-08-06 at 15:45 +0200, Martin Jansa wrote:
 On Wed, Jul 25, 2012 at 02:18:11PM +0200, Martin Jansa wrote:
  On Sun, Jul 22, 2012 at 10:44:06AM +, g...@git.openembedded.org wrote:
   Module: openembedded-core.git
   Branch: master
   Commit: effb75d42098b3e367d393215fd5d52a0191e954
   URL:
   http://git.openembedded.org/?p=openembedded-core.gita=commit;h=effb75d42098b3e367d393215fd5d52a0191e954
   
   Author: Bogdan Marinescu bogdan.a.marine...@intel.com
   Date:   Thu Jul 19 13:33:52 2012 +0300
   
   autoconf: updated to 2.69
   
   Tested with core-image-sato-sdk and lib32-core-image-sato-sdk.
   This update was done mainly because multilib builds failed on master with 
   this error:
   
   | autoreconf: running: aclocal -I 
   /poky/build/tmp/work/x86-pokymllib32-linux/lib32-automake-1.12.1-r0/automake-1.12.1/m4/
-I /poky/build/tmp/sysroots/x86_64-linux/usr/share/aclocal-1.12 -I 
   /poky/build/tmp/work/x86-pokymllib32-linux/lib32-automake-1.12.1-r0/automake-1.12.1/aclocal-copy/
-I 
   /poky/build/tmp/work/x86-pokymllib32-linux/lib32-automake-1.12.1-r0/automake-1.12.1/m4/
-I /poky/build/tmp/sysroots/x86_64-linux/usr/share/aclocal-1.12 -I 
   /poky/build/tmp/work/x86-pokymllib32-linux/lib32-automake-1.12.1-r0/automake-1.12.1/aclocal-copy/
--force --warnings=cross
   | aclocal: warning: unknown warning category 'cross'
   | configure.ac:18: error: Autoconf version 2.69 or higher is required
  
  since this upgrade I see autom4te segfaulting when building webkit-efl
  autom4te[8513]: segfault at 29e782688 ip 7f7c52a96e23 sp 
  7fff07731020 error 4 in Dumper.so[7f7c52a9+8000]
  
  webkit-efl build finishes fine and is usable afaik but someone would
  expect tools like autoconf to behave better and not segfault.
  
  This happens on 2 different builders each with different webkit-efl
  version.
 
 Nobody else have seen this in dmesg? It happens quite often and probably
 not only while building webkit-efl. Because I don't build webkit-efl so
 often:
 dmesg | grep -c segfault at.*Dumper.so
 37
 
 It could be related to perl as Dumper.so is part of perl install
 dev-lang/perl-5.16.0 
 (/usr/lib64/perl5/5.16.0/x86_64-linux-thread-multi/auto/Data/Dumper/Dumper.so)
 
 Maybe inheriting perlnative in autoconf would solve that too.

autoconf-native *must* use the system perl. Trying to do anything else
will result in circular dependencies.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/9] buildhistory improvements

On Thu, 2012-08-02 at 10:23 +0100, Paul Eggleton wrote:
 A bunch of improvements for buildhistory, implementing some feature
 requests and todo items of my own, as well as tidying up some of the
 code.
 
 
 The following changes since commit 404d2d490fc347203e89d274530c17fb5f0aa20f:
 
   gcc-configure-target: Set native-system-header-dir for target gcc 
 (2012-08-01 23:11:09 +0100)
 
 are available in the git repository at:
 
   git://git.openembedded.org/openembedded-core-contrib 
 paule/buildhistory-fixes7
   
 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/buildhistory-fixes7
 
 Paul Eggleton (9):
   classes/buildhistory: remove obsolete flat package history feature
   classes/buildhistory: ensure old package info is removed
   classes/buildhistory: remove unused functions
   classes/buildhistory: save preinst/postinst/prerm/postrm
   classes/buildhistory: record PKG/PKGE/PKGV/PKGR
   buildhistory_analysis: tidy up duplicate split_version function
   buildhistory_analysis: ignore removal of self-dependencies
   classes/buildhistory: save metadata revisions

Merged to master apart from:

  scripts: add buildhistory-tag script

which seems to need more discussion/work.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] (no subject)

On Sun, 2012-08-05 at 21:48 +0200, Javier Martinez Canillas wrote:
 The OpenEmbedded User Manual list the variables that should be used to
 control the directories into which files are installed.
 
 It says that is a poor practice to specify hardcoded paths instead of
 using these variables, yet there are many recipes that don't use it.
 
 This is second version of a big patch-set that does a cleanup and replace
 the hardcoded paths used on these recipes with the build system variables.
 
 I tried to be as careful as possible to do the proper replacement but
 since I could introduce regressions I split the changes in 30 different
 patches so it could be git bisectable in case of messing a recipe.
 
 Also, the patches increment the recipes PR since the a distro config can
 set the variables to a different value.
 
 Changes since v1:
 
 - Bump recipes PR as suggested by Otavio Salvador and Khem Raj
 - Squash ${base_bindir} and ${sysconfdir} changes for xinetd and lsb
   recipes so the PR number gets incremented only once. 
 
 The patch-set consist of the following patches:
 
 [PATCH v2 01/28] xinetd: use ${sbindir} and ${sysconfdir} instead of
 [PATCH v2 02/28] alsa-state: use ${sbindir} instead of /usr/sbin for
 [PATCH v2 03/28] lsbsetup: use ${bindir} instead of /usr/bin for
 [PATCH v2 04/28] sudo: use ${bindir} and ${sysconfdir} instead of
 [PATCH v2 05/28] lsbtest: use ${bindir} instead of /usr/bin for
 [PATCH v2 06/28] cronie: use variables instead of hardcoded paths
 [PATCH v2 07/28] useradd-example: use ${datadir} instead of
 [PATCH v2 08/28] ubootchart: use variables instead of hardcoded
 [PATCH v2 09/28] xkeyboard-config: use ${datadir} instead of
 [PATCH v2 10/28] systemtap: use ${datadir} instead of /usr/share for
 [PATCH v2 11/28] lsb: use ${base_bindir} and ${sysconfdir} instead
 [PATCH v2 12/28] mingetty: use ${base_sbindir} instead of /sbin for
 [PATCH v2 13/28] external-sourcery: use ${prefix} and ${libdir}
 [PATCH v2 14/28] rpm: use ${localstatedir} and ${libdir} instead of
 [PATCH v2 15/28] at: use ${base_sbindir} instead of /sbin for
 [PATCH v2 16/28] kernel.bbclass: use ${base_libdir} and
 [PATCH v2 17/28] linux-firware: use ${base_libdir} instead of /lib
 [PATCH v2 18/28] openssh: use ${localstatedir} instead of /var for
 [PATCH v2 19/28] libpam: use ${localstatedir} and ${sysconfdir}
 [PATCH v2 20/28] x11-common: use ${sysconfdir} instead of /etc for
 [PATCH v2 21/28] builder: use ${sysconfdir} instead of /etc for
 [PATCH v2 22/28] xserver-nodm-init: use ${sysconfdir} instead of
 [PATCH v2 23/28] lsbinitscripts: use ${sysconfdir} instead of /etc
 [PATCH v2 24/28] usbinit: use ${sysconfdir} instead of /etc for
 [PATCH v2 25/28] qemu-config: use ${sysconfdir} instead of /etc for
 [PATCH v2 26/28] rsync: use ${sysconfdir} instead of /etc for
 [PATCH v2 27/28] chkconfig: use ${sysconfdir} instead of /etc for
 [PATCH v2 28/28] man: use ${sysconfdir} instead of /etc for

Thanks for these, I merged most of them apart from external-sourcery
which Chris commented on, the at recipe which I found a better fix for
which removed the lines in question and the rpm change which I want to
check something out related to it first.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] do_rootfs broken due to missing gcc-runtime

On Mon, 2012-08-06 at 16:21 +0200, Enrico Scholz wrote:
 having something in the image which brings gcc-runtime-locale-XX in
 causes do_rootfs to fail with:
 
  * satisfy_dependencies_for: Cannot satisfy the following dependencies for 
 gcc-runtime-locale-de:
  *  gcc-runtime *
  * opkg_install_cmd: Cannot install package gcc-runtime-locale-de.
 
 
 This happens for some time already and I saw a patch[1] on the list
 which fixes it.  Any reason why it has not been applied yet?

 [1]  http://permalink.gmane.org/gmane.comp.handhelds.openembedded.core/24694

Thanks for the reminder, I merged this.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] opkg-nogpg

On Tue, 2012-07-31 at 22:36 +, Slater, Joseph wrote:
 It looks like opkg already uses --disable-gpg, so opkg-nogpg builds
 the same
 
 and the packaging conflicts with opkg, so perhaps it could be
 eliminated?

We should put a PACKAGECONFIG option into the main opkg recipe, then
delete the other one...

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] linux-yocto-custom: Clarify usage and clear COMPATIBLE_MACHINE

On 08/03/2012 05:27 PM, Bruce Ashfield wrote:
On Fri, Aug 3, 2012 at 7:29 PM, Darren Hart dvh...@linux.intel.com wrote:
There has been some confusion over proper use of the linux-yocto-custom
recipe. It is not intended to build as is from meta-skeleton. It should
be modified via a bbappend file to provide a Linux kernel config at the
very least.

Update the commentary to make this requirement more explicit. Add some
additional detail about how to create a bbappend file and how and when
to modify the various variables.

Clear COMPATIBLE_MACHINE so bitbake will not attempt to build the recipe
unless the user explicitly adds there machine to the variable, which
should encourage them to read the recipe comments before attempting to
build it.

Signed-off-by: Darren Hart dvh...@linux.intel.com
CC: Bruce Ashfield bruce.ashfi...@windriver.com
CC: Tom Zanussi tom.zanu...@intel.com
---
.../recipes-kernel/linux/linux-yocto-custom.bb | 52
+++---
1 file changed, 35 insertions(+), 17 deletions(-)

diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
index 55f0c38..dd98228 100644
--- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
+++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
@@ -1,17 +1,35 @@
# linux-yocto-custom.bb:
#
-# Provides an example/minimal kernel recipe that uses the linux-yocto
-# and oe-core kernel classes to apply a subset of yocto kernel
-# management to git managed kernel repositories.
+# An example kernel recipe that uses the linux-yocto and oe-core
+# kernel classes to apply a subset of yocto kernel management to git
+# managed kernel repositories.
+#
+# To use linux-yocto-custom in your layer, create a
+# linux-yocto-custom.bb file containing at least the following lines:

s/linux-yocto-custom.bb/linux-yocto-custom.bbappend/

Thanks!

+#
+# FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
+# COMPATIBLE_MACHINE_yourmachine = yourmachine
+#
+# You must also provide a Linux kernel configuration. The most direct
+# method is to copy your .config to files/defconfig in your layer,
+# parallel to the linux-yocto-custom.bbappend file.

hmm. parallel ready odd to me, but I don't have a better suggestion.

in the same directory as the bbappend.

+#
+# To use the yocto kernel tooling to generate a BSP configuration
+# using modular configuration fragments, see the yocto-bsp and
+# yocto-kernel tools documentation.
+#
+# Warning:
+#
+# Building this example without providing a defconfig or BSP
+# configuration will result in build or boot errors. This is not a
+# bug.
+#
#
# Notes:
#
-# kconfig(s): the kernel must be configured with a defconfig, or via
-# configuration fragment(s). Either of these can be added
-# via bbappend.

Leaving the part about configuration fragments might be useful.

I removed it because I felt I adequately covered it above:

# You must also provide a Linux kernel configuration. The most direct
# method is to copy your .config to files/defconfig in your layer,
# in the same directory as the bbappend.
#
# To use the yocto kernel tooling to generate a BSP configuration
# using modular configuration fragments, see the yocto-bsp and
# yocto-kernel tools documentation.

.. but this looks good, lets see if it saves a few questions :)

Will send V2 with your comments addressed.

--
Darren

Cheers,

Bruce

-# patches: patches can be merged into to the source git tree itself, added
-#using standard bbappend syntax or controlled via .scc feature
-#descriptions (also via bbappends)
+# patches: patches can be merged into to the source git tree itself,
+#added via the SRC_URI, or controlled via a BSP
+#configuration.
#
# example configuration addition:
#SRC_URI += file://smp.cfg
@@ -20,25 +38,25 @@
# example feature addition (for kernel v3.4 only):
#SRC_URI += file://feature.scc
#
-# Warning:
-#
-# Building the sample kernel tree (kernel.org) without providing any
-# configuration will result in build or boot errors. This is not a bug
-# it is a required element for creating a valid kernel.
-#

inherit kernel
require recipes-kernel/linux/linux-yocto.inc

+# Override SRC_URI in a bbappend file to point at a different source
+# tree if you do not want to build from Linus' tree.
SRC_URI =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1

LINUX_VERSION ?= 3.4
LINUX_VERSION_EXTENSION ?= -custom

+# Override SRCREV to point to a different commit in a bbappend file to
+# build a different release of the Linux kernel.
# tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
SRCREV=76e10d158efb6d4516018846f60c2ab5501900bc

-PR = r0
+PR = r1
PV =

[OE-core] [PATCH 1/1] linux-yocto-custom: Clarify usage and clear COMPATIBLE_MACHINE

There has been some confusion over proper use of the linux-yocto-custom
recipe. It is not intended to build as is from meta-skeleton. It should
be modified via a bbappend file to provide a Linux kernel config at the
very least.

Update the commentary to make this requirement more explicit. Add some
additional detail about how to create a bbappend file and how and when
to modify the various variables.

Clear COMPATIBLE_MACHINE so bitbake will not attempt to build the recipe
unless the user explicitly adds there machine to the variable, which
should encourage them to read the recipe comments before attempting to
build it.

Signed-off-by: Darren Hart dvh...@linux.intel.com
CC: Bruce Ashfield bruce.ashfi...@windriver.com
CC: Tom Zanussi tom.zanu...@intel.com
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
 .../recipes-kernel/linux/linux-yocto-custom.bb | 53 +++---
 1 file changed, 36 insertions(+), 17 deletions(-)

diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb 
b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
index 55f0c38..1f0b3a2 100644
--- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
+++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
@@ -1,17 +1,36 @@
 # linux-yocto-custom.bb:
 #
-#   Provides an example/minimal kernel recipe that uses the linux-yocto
-#   and oe-core kernel classes to apply a subset of yocto kernel 
-#   management to git managed kernel repositories.
+#   An example kernel recipe that uses the linux-yocto and oe-core
+#   kernel classes to apply a subset of yocto kernel management to git
+#   managed kernel repositories.
+#
+#   To use linux-yocto-custom in your layer, create a
+#   linux-yocto-custom.bbappend file containing at least the following
+#   lines:
+#
+# FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
+# COMPATIBLE_MACHINE_yourmachine = yourmachine
+#
+#   You must also provide a Linux kernel configuration. The most direct
+#   method is to copy your .config to files/defconfig in your layer,
+#   in the same directory as the bbappend.
+#
+#   To use the yocto kernel tooling to generate a BSP configuration
+#   using modular configuration fragments, see the yocto-bsp and
+#   yocto-kernel tools documentation.
+#
+# Warning:
+#
+#   Building this example without providing a defconfig or BSP
+#   configuration will result in build or boot errors. This is not a
+#   bug.
+#
 #
 # Notes:
 #
-#   kconfig(s): the kernel must be configured with a defconfig, or via
-#   configuration fragment(s). Either of these can be added
-#   via bbappend.
-#   patches: patches can be merged into to the source git tree itself, added
-#using standard bbappend syntax or controlled via .scc feature 
-#descriptions (also via bbappends)
+#   patches: patches can be merged into to the source git tree itself,
+#added via the SRC_URI, or controlled via a BSP
+#configuration.
 #   
 #   example configuration addition:
 #SRC_URI += file://smp.cfg
@@ -20,25 +39,25 @@
 #   example feature addition (for kernel v3.4 only):
 #SRC_URI += file://feature.scc
 #
-# Warning:
-#
-#   Building the sample kernel tree (kernel.org) without providing any
-#   configuration will result in build or boot errors. This is not a bug
-#   it is a required element for creating a valid kernel.
-#
 
 inherit kernel
 require recipes-kernel/linux/linux-yocto.inc
 
+# Override SRC_URI in a bbappend file to point at a different source
+# tree if you do not want to build from Linus' tree.
 SRC_URI = 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1
 
 LINUX_VERSION ?= 3.4
 LINUX_VERSION_EXTENSION ?= -custom
 
+# Override SRCREV to point to a different commit in a bbappend file to
+# build a different release of the Linux kernel.
 # tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
 SRCREV=76e10d158efb6d4516018846f60c2ab5501900bc
 
-PR = r0
+PR = r1
 PV = ${LINUX_VERSION}+git${SRCPV}
 
-COMPATIBLE_MACHINE = (qemuarm|qemux86|qemuppc|qemumips|qemux86-64)
+# Override COMPATIBLE_MACHINE to include your machine in a bbappend
+# file. Leaving it empty here ensures an early explicit build failure.
+COMPATIBLE_MACHINE = (^$)
-- 
1.7.11.2


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH V2 0/1] linux-yocto-custom: Clarify usage and clear COMPATIBLE_MACHINE

The following changes since commit 47aca0f0f79c30d1df1f89c710d3e354f436145d:

  subversion: Add missing build dependency on sqlite3 (2012-08-06 16:13:45 
+0100)

are available in the git repository at:

  git://git.yoctoproject.org/user-contrib/dvhart/oe-core skeleton
  
http://git.yoctoproject.org/cgit.cgi/user-contrib/dvhart/oe-core/log/?h=skeleton

Darren Hart (1):
  linux-yocto-custom: Clarify usage and clear COMPATIBLE_MACHINE

 .../recipes-kernel/linux/linux-yocto-custom.bb | 53 +++---
 1 file changed, 36 insertions(+), 17 deletions(-)

-- 
1.7.11.2


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] proper(?) way to require an earlier, unsupported version of a recipe file?

2012-08-06 Thread Robert P. J. Day


  what is the OE philosophy for preferring an earlier version of a
recipe file that doesn't even exist anymore?  for example, the
watchdog recipe was recently upgraded from 5.11 to 5.12.  in the
process, the recipe file for 5.11 was removed; therefore, i interpret
that as that OE-core no longer supports that version, which is fine.

  hypothetically, what if someone still *needed* that earlier version?
would it be their responsibility to, say, create a new layer that
re-introduced that older, now-unsupported version?  just curious.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 16/28] kernel.bbclass: use ${base_libdir} and ${sysconfdir} instead of /lib and /etc

On 08/05/2012 12:48 PM, Javier Martinez Canillas wrote:

Hi Javier,

 It is considered good practice to use the build system provided
 variables instead of directly specify hardcoded paths.

Have you tested this with a build using a base_libdir other than /lib ?

 Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
 ---
  meta/classes/kernel.bbclass |   12 ++--
  1 files changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
 index 1d8dff9..b434093 100644
 --- a/meta/classes/kernel.bbclass
 +++ b/meta/classes/kernel.bbclass
 @@ -109,10 +109,10 @@ kernel_do_install() {
   unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
   if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
   oe_runmake DEPMOD=echo INSTALL_MOD_PATH=${D} modules_install

The install doesn't specify base_libdir, so does the kernel make system
honor it?

 - rm -f ${D}/lib/modules/${KERNEL_VERSION}/modules.order
 - rm -f ${D}/lib/modules/${KERNEL_VERSION}/modules.builtin
 - rm ${D}/lib/modules/${KERNEL_VERSION}/build
 - rm ${D}/lib/modules/${KERNEL_VERSION}/source
 + rm -f 
 ${D}${base_libdir}/modules/${KERNEL_VERSION}/modules.order
 + rm -f 
 ${D}${base_libdir}/modules/${KERNEL_VERSION}/modules.builtin
 + rm ${D}${base_libdir}/modules/${KERNEL_VERSION}/build
 + rm ${D}${base_libdir}/modules/${KERNEL_VERSION}/source

if not, these will fail.

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

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] proper(?) way to require an earlier, unsupported version of a recipe file?

On Mon, 2012-08-06 at 12:02 -0400, Robert P. J. Day wrote:
 what is the OE philosophy for preferring an earlier version of a
 recipe file that doesn't even exist anymore?  for example, the
 watchdog recipe was recently upgraded from 5.11 to 5.12.  in the
 process, the recipe file for 5.11 was removed; therefore, i interpret
 that as that OE-core no longer supports that version, which is fine.
 
   hypothetically, what if someone still *needed* that earlier version?
 would it be their responsibility to, say, create a new layer that
 re-introduced that older, now-unsupported version?  just curious.

Well, if there is some reason 5.11 is much better we as in OE-Core
would like to know about it to evaluate if we should be keeping it
around for some reason. If the reason you want that particular version
is specific to you then yes, your own layer would be the place to
maintain it (or a layer shared with other like minded users).

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] proper(?) way to require an earlier, unsupported version of a recipe file?

2012-08-06 Thread Robert P. J. Day

On Mon, 6 Aug 2012, Richard Purdie wrote:

 On Mon, 2012-08-06 at 12:02 -0400, Robert P. J. Day wrote:
  what is the OE philosophy for preferring an earlier version of a
  recipe file that doesn't even exist anymore?  for example, the
  watchdog recipe was recently upgraded from 5.11 to 5.12.  in the
  process, the recipe file for 5.11 was removed; therefore, i interpret
  that as that OE-core no longer supports that version, which is fine.
 
hypothetically, what if someone still *needed* that earlier version?
  would it be their responsibility to, say, create a new layer that
  re-introduced that older, now-unsupported version?  just curious.

 Well, if there is some reason 5.11 is much better we as in OE-Core
 would like to know about it to evaluate if we should be keeping it
 around for some reason. If the reason you want that particular version
 is specific to you then yes, your own layer would be the place to
 maintain it (or a layer shared with other like minded users).

  there was nothing about 5.11 that i see as superior, it's just that
that general question came up last week in class and my admittedly
off-the-cuff answer was that OE-core provided a well-defined, stable
set of recipes to build on and if you *chose* to deviate in any way
from that, that was kind of your problem and you had to deal with it.

  which appears to be pretty much what you're saying.  thanks.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 03/30] lsbsetup: use ${bindir} instead of /usr/bin for packaging

2012-08-06 Thread Mark Hatle


On 8/5/12 10:53 AM, Javier Martinez Canillas wrote:

It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.

Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
---
  meta/recipes-extended/lsb/lsbsetup_1.0.bb |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/lsb/lsbsetup_1.0.bb 
b/meta/recipes-extended/lsb/lsbsetup_1.0.bb
index 9172ee3..bda4589 100644
--- a/meta/recipes-extended/lsb/lsbsetup_1.0.bb
+++ b/meta/recipes-extended/lsb/lsbsetup_1.0.bb
@@ -11,9 +11,9 @@ S = ${WORKDIR}

  do_install() {
  # Only install file if it has a contents
-install -d ${D}/usr/bin
+install -d ${D}${bindir}


the LSB required /usr/bin, I think.  So this might be one of the few cases were 
specifying /usr/bin is acceptable.


(but I'm not against the change)

--Mark


  install -d ${D}/${sysconfdir}
-install -m 0755 ${S}/LSB_Setup.sh ${D}/usr/bin
+install -m 0755 ${S}/LSB_Setup.sh ${D}${bindir}
  install -d  ${D}/${libdir}/lsb
  ln -sf ${base_sbindir}/chkconfig ${D}/${libdir}/lsb/install_initd
  ln -sf ${base_sbindir}/chkconfig ${D}/${libdir}/lsb/remove_initd




___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 16/28] kernel.bbclass: use ${base_libdir} and ${sysconfdir} instead of /lib and /etc

2012-08-06 Thread Javier Martinez Canillas

On Mon, Aug 6, 2012 at 6:14 PM, Darren Hart dvh...@linux.intel.com wrote:
 On 08/05/2012 12:48 PM, Javier Martinez Canillas wrote:

 Hi Javier,

 It is considered good practice to use the build system provided
 variables instead of directly specify hardcoded paths.

 Have you tested this with a build using a base_libdir other than /lib ?

 Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
 ---
  meta/classes/kernel.bbclass |   12 ++--
  1 files changed, 6 insertions(+), 6 deletions(-)

 diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
 index 1d8dff9..b434093 100644
 --- a/meta/classes/kernel.bbclass
 +++ b/meta/classes/kernel.bbclass
 @@ -109,10 +109,10 @@ kernel_do_install() {
   unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
   if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
   oe_runmake DEPMOD=echo INSTALL_MOD_PATH=${D} modules_install

 The install doesn't specify base_libdir, so does the kernel make system
 honor it?

 - rm -f ${D}/lib/modules/${KERNEL_VERSION}/modules.order
 - rm -f ${D}/lib/modules/${KERNEL_VERSION}/modules.builtin
 - rm ${D}/lib/modules/${KERNEL_VERSION}/build
 - rm ${D}/lib/modules/${KERNEL_VERSION}/source
 + rm -f 
 ${D}${base_libdir}/modules/${KERNEL_VERSION}/modules.order
 + rm -f 
 ${D}${base_libdir}/modules/${KERNEL_VERSION}/modules.builtin
 + rm ${D}${base_libdir}/modules/${KERNEL_VERSION}/build
 + rm ${D}${base_libdir}/modules/${KERNEL_VERSION}/source

 if not, these will fail.

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

Hi Darren,

Yes, you are right I didn't think about it.

The kernel is a special case since you just specify the root of the
file system with INSTALL_MOD_PATH the kernel build system will
*always* create lib/modules/${KERNEL_VERSION}.

In fact now that I think about it, I don't know if you can even change
the path were the kernel modules gets installed.

So, yes the kernel is a special case and using a ${base_libdir} other
than /lib will definitely break loadable kernel modules installation.

Richard, Darren is correct and this patch is wrong, this is one of the
cases which is acceptable (and necessary) to hardcode /lib.

Thanks a lot for pointing me out this and sorry for not realizing this
before sending the patch-set.

Best regards,
Javier

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 11/30] lsb: use ${base_bindir} instead of /bin for packaging

2012-08-06 Thread Mark Hatle


On 8/5/12 10:53 AM, Javier Martinez Canillas wrote:

It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.

Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
---
  meta/recipes-extended/lsb/lsb_1.4.bb |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-extended/lsb/lsb_1.4.bb 
b/meta/recipes-extended/lsb/lsb_1.4.bb
index 15dbeaa..5734c5c 100644
--- a/meta/recipes-extended/lsb/lsb_1.4.bb
+++ b/meta/recipes-extended/lsb/lsb_1.4.bb
@@ -23,7 +23,7 @@ S = ${WORKDIR}/lsb-release-${PV}

  do_install(){
oe_runmake install prefix=${D}  mandir=${D}/${datadir}/man/ DESTDIR=${D}
-   mkdir -p ${D}/bin
+   mkdir -p ${D}${base_bindir}
mkdir -p ${D}/${baselib}
mkdir -p ${D}/etc/lsb-release.d
echo -n LSB_VERSION=\core-4.1-noarch:  ${D}/etc/lsb-release



This is another case with the lsb, that lsb-release (and a few other things) are 
documented to me installed into /bin.


Not objecting to the change, just explaining why it was implemented this way.

--Mark

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 17/30] linux-firware: use ${base_libdir} instead of /lib for packaging

On 08/05/2012 08:54 AM, Javier Martinez Canillas wrote:
 It is considered good practice to use the build system provided
 variables instead of directly specify hardcoded paths.

The firmware location is explicitly set because this is where the Linux
kernel requires it to be. This patch will break firmware loading.

--
Darren

 Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
 ---
  .../linux-firmware/linux-firmware_git.bb   |   34 
 ++--
  1 files changed, 17 insertions(+), 17 deletions(-)
 
 diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
 b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
 index a7e4ed6..c5ab173 100644
 --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
 +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
 @@ -35,50 +35,50 @@ do_compile() {
  }
  
  do_install() {
 - install -d  ${D}/lib/firmware/
 - cp -r * ${D}/lib/firmware/
 + install -d  ${D}${base_libdir}/firmware/
 + cp -r * ${D}${base_libdir}/firmware/
  
   # Libertas sd8686
 - ln -sf libertas/sd8686_v9.bin ${D}/lib/firmware/sd8686.bin
 - ln -sf libertas/sd8686_v9_helper.bin ${D}/lib/firmware/sd8686_helper.bin
 + ln -sf libertas/sd8686_v9.bin ${D}${base_libdir}/firmware/sd8686.bin
 + ln -sf libertas/sd8686_v9_helper.bin 
 ${D}${base_libdir}/firmware/sd8686_helper.bin
  
   # Realtek rtl8192* 
 - install -m 0644 LICENCE.rtlwifi_firmware.txt 
 ${D}/lib/firmware/rtlwifi/LICENCE.rtlwifi_firmware.txt
 + install -m 0644 LICENCE.rtlwifi_firmware.txt 
 ${D}${base_libdir}/firmware/rtlwifi/LICENCE.rtlwifi_firmware.txt
  
   # fixup wl12xx location, after 2.6.37 the kernel searches a different 
 location for it
 - ( cd ${D}/lib/firmware ; ln -sf ti-connectivity/* . )
 + ( cd ${D}${base_libdir}/firmware ; ln -sf ti-connectivity/* . )
  }
  
  PACKAGES =+ ${PN}-sd8686 ${PN}-rtl8192cu linux-firmware-rtl8192ce 
 linux-firmware-rtl8192su ${PN}-wl12xx
  
  LICENSE_${PN}-sd8686 = Firmware:LICENSE.libertas
  FILES_${PN}-sd8686 =  \
 -  /lib/firmware/libertas/sd8686_v9* \
 -  /lib/firmware/sd8686* \
 -  /lib/firmware/LICENCE.libertas \
 +  ${base_libdir}/firmware/libertas/sd8686_v9* \
 +  ${base_libdir}/firmware/sd8686* \
 +  ${base_libdir}/firmware/LICENCE.libertas \
  
  
  LICENSE_${PN}-rtl8192cu = Firmware:LICENCE.rtlwifi_firmware
  FILES_${PN}-rtl8192cu =  \
 -  /lib/firmware/rtlwifi/rtl8192cufw.bin \
 -  /lib/firmware/rtlwifi/LICENCE.rtlwifi_firmware.txt \
 +  ${base_libdir}/firmware/rtlwifi/rtl8192cufw.bin \
 +  ${base_libdir}/firmware/rtlwifi/LICENCE.rtlwifi_firmware.txt \
  
  
  LICENSE_${PN}-rtl8192ce = Firmware:LICENCE.rtlwifi_firmware
  FILES_${PN}-rtl8192ce =  \
 -  /lib/firmware/rtlwifi/rtl8192cfw.bin \
 +  ${base_libdir}/firmware/rtlwifi/rtl8192cfw.bin \
  
  
  LICENSE_${PN}-rtl8192su = Firmware:LICENCE.rtlwifi_firmware
  FILES_${PN}-rtl8192su =  \
 -  /lib/firmware/rtlwifi/rtl8712u.bin \
 +  ${base_libdir}/firmware/rtlwifi/rtl8712u.bin \
  
  
  FILES_${PN}-wl12xx =  \
 -  /lib/firmware/wl12* \
 -  /lib/firmware/TI* \
 -  /lib/firmware/ti-connectivity \
 +  ${base_libdir}/firmware/wl12* \
 +  ${base_libdir}/firmware/TI* \
 +  ${base_libdir}/firmware/ti-connectivity \
  
  
 -FILES_${PN} += /lib/firmware/*
 +FILES_${PN} += ${base_libdir}/firmware/*
  
 

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

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 17/30] linux-firware: use ${base_libdir} instead of /lib for packaging

2012-08-06 Thread Phil Blundell

On Mon, 2012-08-06 at 11:10 -0700, Darren Hart wrote:
 On 08/05/2012 08:54 AM, Javier Martinez Canillas wrote:
  It is considered good practice to use the build system provided
  variables instead of directly specify hardcoded paths.
 
 The firmware location is explicitly set because this is where the Linux
 kernel requires it to be. 

Is that actually true?  I thought the kernel just supplied the leafname
that it wanted and the knowledge about what directory to search was
encoded in the hotplug helper scripts.

 This patch will break firmware loading.

That might well be the case, though, unless the scripts have also been
patched to respect ${base_libdir}.  

And, notwithstanding all the above, it's not entirely obvious that
${base_libdir} is semantically the right variable for things that aren't
libraries.  How does the udev recipe represent the patch to /lib/udev?

p.



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] pseudo: Use fxstatat64 in unlinkat

2012-08-06 Thread Peter Seebach

On Thu, 2 Aug 2012 17:48:18 -0500
Peter Seebach peter.seeb...@windriver.com wrote:

 I think probably the right solution is to use the PSEUDO_STATBUF logic
 that's already in ports, and expand on it a bit.

A followup:

I've got a test version of this tagged PSEUDO_1_4_1. I've got one
report about a cryptic error from tar (see yocto #2881 for some
discussion), but would be really interested in feedback from anyone who
is using 32-bit systems with this stuff.

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/5] gtk-icon-cache: call postinst scriplet at do_rootfs time

2012-08-06 Thread Andreas Müller

On Mon, Aug 6, 2012 at 11:18 AM, Laurentiu Palcu
laurentiu.pa...@intel.com wrote:

On 08/06/2012 11:10 AM, Andreas Müller wrote:
On Mon, Aug 6, 2012 at 9:48 AM, Laurentiu Palcu
laurentiu.pa...@intel.com wrote:

Thanks for the measurements though. They do, indeed, show quite a
significant amount of time (around 6 minutes). A run-once solution is to
be considered in this case.

Andreas

[1]
https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
OK I know it is not that important: The image created with this patch
series creates tons of messages like
Why do you think is not important. Please elaborate. Or is it irony?
Yes sorry - it was late night.
It's OK, let's work together and find the best solution for all of us. I
would also be pissed of if I had to wait an extra 6 minutes every
do_rootfs run.

I don't think is in anybody's benefit if you take this approach. :) All
errors/warnings are important and they have to be taken care of.

xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or
directory

Thanks,
Laurentiu

I checked: In both I find the files icon-theme.cache.

Andreas

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V3 00/11] Mesa upgrade/improvements

2012-08-06 Thread Phil Blundell

On Mon, 2012-08-06 at 15:04 +0100, Richard Purdie wrote:
 Ok, we need to do something about this mess, period. Its not going to
 get any better and we need to sort it out. I can't force changes in
 but on the other hand I'm not going to tie the hands of everyone just
 because the ARM world in particular is a total mess in this area.
 
 As such, I'm likely going to allow architecture overrides in core mesa
 so for example, IA can enable gles and egl for everyone and cleanup
 their binary blobs to override them on platforms where it makes sense. I
 suspect someone will start sending patches to enable a generic arm core
 and I am going to have a *really* hard time refusing the patches due to
 any one silicon provider's binary blob issues.

It's not obvious to me that this is really an architecture-level problem
or that having different Mesa feature sets enabled on different
architectures is a positive thing. 

I'm also not totally convinced that any insurmountable problem actually
exists today with evil vendor blobs.  If they install themselves into
some directory that isn't /usr/lib and arrange for the dynamic linker to
find their libEGL.so (etc) ahead of the Mesa one then it seems like
everything should just work with today's technology.  As you observed,
sort of the whole point of the EGL/GL/GLES abstraction is that you have
a common API/ABI to write to irrespective of the implementation.

(Realistically, it seems fairly unlikely that there are very many
situations where using Mesa libGL on top of a vendor libEGL is going to
make much sense.  If you have vendor libEGL but not libGL then the
chances are you have GLES instead and this is probably what you want to
be using.)

So, all in all, I tend to think that we should just apply these patches
and then do whatever else is necessary for the evil-binary-vendor stuff
to be correctly packageable.

p.



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH] iputils: Break libsysfs dependency

2012-08-06 Thread Andy Ross

iputils drops a /bin/arping with a runtime linkage against libsysfs in
/usr.  Port Fedora 17 iputils-20071127-infiniband.patch, which inlines
access previously done by libsysfs.

Signed-off-by: Andy Ross andy.r...@windriver.com
---
 .../files/arping-break-libsysfs-dependency.patch   | 296 +
 meta/recipes-extended/iputils/iputils_s20101006.bb |   5 +-
 2 files changed, 299 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-extended/iputils/files/arping-break-libsysfs-dependency.patch

diff --git 
a/meta/recipes-extended/iputils/files/arping-break-libsysfs-dependency.patch 
b/meta/recipes-extended/iputils/files/arping-break-libsysfs-dependency.patch
new file mode 100644
index 000..37325ee
--- /dev/null
+++ b/meta/recipes-extended/iputils/files/arping-break-libsysfs-dependency.patch
@@ -0,0 +1,296 @@
+arping: Break libsysfs dependency
+
+Port Fedora 17's iputils-20071127-infiniband.patch, which inlines sysfs
+access previously done by libsysfs (which is in /usr, and thus not
+usable by /bin/arping).
+
+Upstream-Status: Inappropriate [not author] 
+Signed-off-by: Andy Ross andy.r...@windriver.com
+---
+ Makefile |2 +-
+ arping.c |  152 --
+ 2 files changed, 109 insertions(+), 45 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index d9a5ca5..943f048 100644
+--- a/Makefile
 b/Makefile
+@@ -27,7 +27,7 @@ all: $(TARGETS)
+ 
+ 
+ tftpd: tftpd.o tftpsubs.o
+-arping: arping.o -lsysfs
++arping: arping.o
+ ping: ping.o ping_common.o
+ ping6: ping6.o ping_common.o -lresolv -lcrypto
+ ping.o ping6.o ping_common.o: ping_common.h
+diff --git a/arping.c b/arping.c
+index 13484de..6379354 100644
+--- a/arping.c
 b/arping.c
+@@ -32,8 +32,6 @@
+ #include netinet/in.h
+ #include arpa/inet.h
+ 
+-#include sysfs/libsysfs.h
+-
+ #include SNAPSHOT.h
+ 
+ static void usage(void) __attribute__((noreturn));
+@@ -52,14 +50,22 @@ int unicasting;
+ int s;
+ int broadcast_only;
+ 
+-struct sockaddr_storage me;
+-struct sockaddr_storage he;
++struct sockaddr_ll *me=NULL;
++struct sockaddr_ll *he=NULL;
+ 
+ struct timeval start, last;
+ 
+ int sent, brd_sent;
+ int received, brd_recv, req_recv;
+ 
++#define SYSFS_MNT_PATH  /sys
++#define SYSFS_CLASS class
++#define SYSFS_NET   net
++#define SYSFS_BROADCAST broadcast
++#define SYSFS_PATH_ENV  SYSFS_PATH
++#define SYSFS_PATH_LEN  256
++#define SOCKADDR_LEN  (2 * sizeof(struct sockaddr_ll))
++
+ #define MS_TDIFF(tv1,tv2) ( ((tv1).tv_sec-(tv2).tv_sec)*1000 + \
+  ((tv1).tv_usec-(tv2).tv_usec)/1000 )
+ 
+@@ -166,6 +172,10 @@ void finish(void)
+   printf(\n);
+   fflush(stdout);
+   }
++
++  free(me);
++  free(he);
++
+   if (dad)
+   exit(!!received);
+   if (unsolicited)
+@@ -189,8 +199,7 @@ void catcher(void)
+   finish();
+ 
+   if ( count!=0   (last.tv_sec==0 || MS_TDIFF(tv,last)  500 ) ) {
+-  send_pack(s, src, dst,
+-(struct sockaddr_ll *)me, (struct sockaddr_ll *)he);
++  send_pack(s, src, dst, me, he);
+   if (count = 0)
+   count--;
+   if (count == 0  unsolicited)
+@@ -239,7 +248,7 @@ int recv_pack(unsigned char *buf, int len, struct 
sockaddr_ll *FROM)
+   return 0;
+   if (ah-ar_pln != 4)
+   return 0;
+-  if (ah-ar_hln != ((struct sockaddr_ll *)me)-sll_halen)
++  if (ah-ar_hln != me-sll_halen)
+   return 0;
+   if (len  sizeof(*ah) + 2*(4 + ah-ar_hln))
+   return 0;
+@@ -250,7 +259,7 @@ int recv_pack(unsigned char *buf, int len, struct 
sockaddr_ll *FROM)
+   return 0;
+   if (src.s_addr != dst_ip.s_addr)
+   return 0;
+-  if (memcmp(p+ah-ar_hln+4, ((struct sockaddr_ll 
*)me)-sll_addr, ah-ar_hln))
++  if (memcmp(p+ah-ar_hln+4, me-sll_addr, ah-ar_hln))
+   return 0;
+   } else {
+   /* DAD packet was:
+@@ -268,7 +277,7 @@ int recv_pack(unsigned char *buf, int len, struct 
sockaddr_ll *FROM)
+*/
+   if (src_ip.s_addr != dst.s_addr)
+   return 0;
+-  if (memcmp(p, ((struct sockaddr_ll *)me)-sll_addr, ((struct 
sockaddr_ll *)me)-sll_halen) == 0)
++  if (memcmp(p, me-sll_addr, me-sll_halen) == 0)
+   return 0;
+   if (src.s_addr  src.s_addr != dst_ip.s_addr)
+   return 0;
+@@ -284,7 +293,7 @@ int recv_pack(unsigned char *buf, int len, struct 
sockaddr_ll *FROM)
+   printf(for %s , inet_ntoa(dst_ip));
+   s_printed = 1;
+   }
+-  if (memcmp(p+ah-ar_hln+4, ((struct sockaddr_ll 
*)me)-sll_addr, ah-ar_hln)) {
++  if (memcmp(p+ah-ar_hln+4, me-sll_addr, ah-ar_hln)) {
+

[OE-core] [oe-core] [denzil branch] Update to the latest version of psplash

2012-08-06 Thread Cooper Jr., Franklin

In the latest version of psplash
(http://git.yoctoproject.org/cgit/cgit.cgi/psplash/) there are two patches
that are not in the version of psplash used in the oe-core denzil branch. The
first patch called Make it easier to customise
colourshttp://git.yoctoproject.org/cgit/cgit.cgi/psplash/commit/?id=84764337a584002a92940323d374b0e417c573a6
moves some color definitions from being hardcoded into psplash.c and puts it
in a new header file called psplash-colors.h. The second patch Fix for psplash
segmentation
faulthttp://git.yoctoproject.org/cgit/cgit.cgi/psplash/commit/?id=de9979aefbc56af59b4d236a4b63dd19dcdcfb53
fixes a segment fault issue.

What I would like to do is update the psplash_git.bb recipe to use the latest
version of psplash that pulls in these two tweaks. The second patch has zero
impact on existing users of the pslash recipe. If a particular layer tweaks the
color definitions in psplash by patching the psplash.c file then the second
patch mentioned above could result in a minor tweak having to be made to those
layers to address the changes. In oe-classic noticed that there is a patch for
psplash
(http://cgit.openembedded.org/openembedded/tree/recipes/psplash/psplash-ti/0001-configurability-for-rev-422.patch)
that patches psplash in almost the same exact way as the Make it easier to
customize colours patch.

Are there any objections in bumping the version of psplash to incorporate the
above mentioned patches? I haven't seen any layer adjust the psplash color
definitions so I doubt there truly being any impact at all.

Regards,
Franklin Cooper Jr.
Texas Instruments
Application Engineer
fcoo...@ti.commailto:fcoo...@ti.com

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core] [denzil branch] Update to the latest version of psplash

2012-08-06 Thread Scott Garman


On 08/06/2012 02:43 PM, Cooper Jr., Franklin wrote:

In the latest version of psplash
(http://git.yoctoproject.org/cgit/cgit.cgi/psplash/)  there are two
patches that are not in the version of psplash used in the oe-core
denzil branch. The first patch called Make it easier to customise
colours
http://git.yoctoproject.org/cgit/cgit.cgi/psplash/commit/?id=84764337a584002a92940323d374b0e417c573a6moves
some color definitions from being hardcoded into psplash.c and puts it
in a new header file called psplash-colors.h.  The second patch Fix for
psplash segmentation fault
http://git.yoctoproject.org/cgit/cgit.cgi/psplash/commit/?id=de9979aefbc56af59b4d236a4b63dd19dcdcfb53fixes
a segment fault issue.

What I would like to do is update the psplash_git.bb recipe to use the
latest version of psplash that pulls in these two tweaks. The second
patch has zero impact on existing users of the pslash recipe. If a
particular layer tweaks the color definitions in psplash by patching the
psplash.c file then the second patch mentioned above could result in a
minor tweak having to be made to those layers to address the changes. In
oe-classic noticed that there is a patch for psplash
(http://cgit.openembedded.org/openembedded/tree/recipes/psplash/psplash-ti/0001-configurability-for-rev-422.patch)
that patches psplash in almost the same exact way as the “Make it easier
to customize colours” patch.

Are there any objections in bumping the version of psplash to
incorporate the above mentioned patches? I haven’t seen any layer adjust
the psplash color definitions so I doubt there truly being any impact at
all.**


Franklin and I discussed this on IRC and I suggested he bring this up on 
the mailing list.


I'm inclined to take and backport the segfault patch into the current 
version of psplash in denzil (which is a git recipe fixed at e05374a). 
Bumping the SRCREV of the recipe and including the color definitions 
patch I'm not so sure about - vocal support from the community could tip 
the scales, though, so speak up if this would be of value to you.


The segfault patch is being tracked with bug #2903:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2903

Thanks,

Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core] [denzil branch] Update to the latest version of psplash

2012-08-06 Thread Otavio Salvador

On Mon, Aug 6, 2012 at 6:54 PM, Scott Garman scott.a.gar...@intel.com wrote:
 I'm inclined to take and backport the segfault patch into the current
 version of psplash in denzil (which is a git recipe fixed at e05374a).
 Bumping the SRCREV of the recipe and including the color definitions patch
 I'm not so sure about - vocal support from the community could tip the
 scales, though, so speak up if this would be of value to you.

I do think it is valuable however layers changing colors will have a
broken patch applying above it and I don't think it is the expected
for a stable release.

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH] image-mklibs: pass correct libdir to mklibs

2012-08-06 Thread Jesse Zhang

libdir should be specified, or else mklibs won't work for 64bit targets.
It wouldn't be able to find the libs.

Traceback (most recent call last):
  File 
build/bitbake_build/tmp/sysroots/i686-linux/usr/bin/x86_64-wrs-linux/mklibs,
 line 553, in module
header = elf_header(find_lib(libraries.copy().pop()))
  File 
build/bitbake_build/tmp/sysroots/i686-linux/usr/bin/x86_64-wrs-linux/mklibs,
 line 89, in elf_header
raise Exception(Cannot find lib:  + obj)
Exception: Cannot find lib:

Signed-off-by: Jesse Zhang sen.zh...@windriver.com
---
 meta/classes/image-mklibs.bbclass |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/meta/classes/image-mklibs.bbclass 
b/meta/classes/image-mklibs.bbclass
index 7623815..66b0f52 100644
--- a/meta/classes/image-mklibs.bbclass
+++ b/meta/classes/image-mklibs.bbclass
@@ -38,6 +38,7 @@ mklibs_optimize_image_doit() {
 
mklibs -v \
--ldlib ${dynamic_loader} \
+   --libdir ${baselib} \
--sysroot ${PKG_CONFIG_SYSROOT_DIR} \
--root ${IMAGE_ROOTFS} \
--target `echo ${TARGET_PREFIX} | sed 's/-$//' ` \
-- 
1.7.7.6


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH] fix mklibs error for 64bit targets

2012-08-06 Thread Jesse Zhang

mklibs should be passed a --libdir option, in order for it to work with 64bit
targets.

Jesse Zhang (1):
  image-mklibs: pass correct libdir to mklibs

 meta/classes/image-mklibs.bbclass |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

-- 
1.7.7.6


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] u-boot: Upgrade to upstream stable 2012.07

2012-08-06 Thread Khem Raj

On Mon, Aug 6, 2012 at 7:13 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Radu,

 In message 501fd013.5040...@intel.com you wrote:

 CROSS_COMPILE is set in EXTRA_OEMAKE which is used in oe-runmake()
 within do_compile()
 Running devshell is achieved in do_devshell() which is run after
 do_patch() but before do_compile(), that's why in devshell CROSS_COMPILE
 is not (yet) set.
 But CROSS_COMPILE _is_ set (and apparently has the value
 i386-linux-.

 The problem is that PATH is not set such that it contains any such
 file as i386-linux-gcc.


 Best regards,

 Wolfgang Denk

 --
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
 Beware of bugs in the above code; I have only proved it correct, not
 tried it. - Donald Knuth

 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


Hi Wolfgang

If the fix proposed here
http://lists.denx.de/pipermail/u-boot/2012-August/129828.html is
accepted into u-boot
then we wont need these glues.

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2 0/1] linux-yocto-custom: Clarify usage and clear COMPATIBLE_MACHINE

2012-08-06 Thread Bruce Ashfield


On 12-08-06 11:56 AM, Darren Hart wrote:

The following changes since commit 47aca0f0f79c30d1df1f89c710d3e354f436145d:

   subversion: Add missing build dependency on sqlite3 (2012-08-06 16:13:45 
+0100)

are available in the git repository at:

   git://git.yoctoproject.org/user-contrib/dvhart/oe-core skeleton
   
http://git.yoctoproject.org/cgit.cgi/user-contrib/dvhart/oe-core/log/?h=skeleton

Darren Hart (1):
   linux-yocto-custom: Clarify usage and clear COMPATIBLE_MACHINE


Looks good to me.

Acked-by: Bruce Ashfield bruce.ashfi...@windriver.com



  .../recipes-kernel/linux/linux-yocto-custom.bb | 53 +++---
  1 file changed, 36 insertions(+), 17 deletions(-)




___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] u-boot: Upgrade to upstream stable 2012.07