date:20120409

runqemu can't launch a target image on Fedora 16 64bit or Opensuse 12.1
64bit, this is because runqemu needs the host's libGL.so, which requires
GLIBC_2.14 which is defined in libc.so.6, but our default libc.so.6 is
version 2.13, here is the message from Richard:

The easiest solution would be to change the nativesdk libc to 2.15. I don't
think we plan to do this for the target libc for 1.2 but we could change
nativesdk's version if its well tested

[YOCTO #1968]

Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
 meta/conf/distro/include/tcmode-default.inc |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/distro/include/tcmode-default.inc 
b/meta/conf/distro/include/tcmode-default.inc
index b481163..3dc0932 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -44,9 +44,9 @@ PREFERRED_VERSION_linux-libc-headers ?= ${LINUXLIBCVERSION}
 PREFERRED_VERSION_linux-libc-headers-nativesdk ?= ${LINUXLIBCVERSION}
 PREFERRED_VERSION_eglibc   ?= ${EGLIBCVERSION}
 PREFERRED_VERSION_eglibc-locale?= ${EGLIBCVERSION}
-PREFERRED_VERSION_eglibc-nativesdk ?= ${EGLIBCVERSION}
+PREFERRED_VERSION_eglibc-nativesdk ?= 2.15
 PREFERRED_VERSION_eglibc-initial   ?= ${EGLIBCVERSION}
-PREFERRED_VERSION_eglibc-initial-nativesdk ?= ${EGLIBCVERSION}
+PREFERRED_VERSION_eglibc-initial-nativesdk ?= 2.15
 PREFERRED_VERSION_cross-localedef-native   ?= ${EGLIBCVERSION}
 PREFERRED_VERSION_uclibc   ?= ${UCLIBCVERSION}
 PREFERRED_VERSION_uclibc-initial   ?= ${UCLIBCVERSION}
-- 
1.7.1


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

[OE-core] [PATCH 0/1] meta-toolchain: runqemu falied on FC16/Opensuse12.1 x86_64

Test info:
* Have tested on:
  * Fedora 16 x86_64
  * Opensuse 12.1 x86_64
  * Ubuntu 10.04

* The testing commands are:
  $ bitbake core-image-sato meta-toolchain meta-toolchain-sdk

  And untar the sdk, then runqemu from the sdk to start the target.

// Robert

The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:

  runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 01:12:15 
+0100)

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

Robert Yang (1):
  meta-toolchain: runqemu falied on FC16/Opensuse12.1 x86_64

 meta/conf/distro/include/tcmode-default.inc |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


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

Re: [OE-core] [PATCH 0/1] meta-toolchain: runqemu falied on FC16/Opensuse12.1 x86_64

2012-04-09 Thread Lu, Lianhao


Robert Yang wrote on 2012-04-09:
 Test info:
 * Have tested on:
   * Fedora 16 x86_64
   * Opensuse 12.1 x86_64

Robert, 
Hongna just found a qemu launch error on openSuse x86_64 using the 2.15 
eglibc-nativesdk, something about the SDL initialization error. Did your 
platform work well?

   * Ubuntu 10.04
 * The testing commands are:
   $ bitbake core-image-sato meta-toolchain meta-toolchain-sdk
   
   And untar the sdk, then runqemu from the sdk to start the target.
 // Robert
 
 The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:
 
   runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 01:12:15 
 +0100)
 are available in the git repository at:
   git://git.pokylinux.org/poky-contrib robert/tc
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/tc
 Robert Yang (1):
   meta-toolchain: runqemu falied on FC16/Opensuse12.1 x86_64
  meta/conf/distro/include/tcmode-default.inc |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 ___ Openembedded-core
 mailing list Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Best Regards,
Lianhao



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

[OE-core] [PATCH 1/1] adt-installer: Fixed ppc kernel naming.

1. Fixed the ppc kernel naming.
2. Disabled opkg shared library to avoid runtime opkg-cl launching
error.
3. Adjusted the variable sequence in adt-installer.conf

Fixed bug [YOCTO #2233]

Signed-off-by: Lianhao Lu lianhao...@intel.com
---
 .../installer/adt-installer/adt_installer  |4 ++--
 .../installer/adt-installer/adt_installer.conf |   20 ++--
 .../installer/adt-installer_1.0.bb |2 +-
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-devtools/installer/adt-installer/adt_installer 
b/meta/recipes-devtools/installer/adt-installer/adt_installer
index 1dd07b7..1a53eb9 100755
--- a/meta/recipes-devtools/installer/adt-installer/adt_installer
+++ b/meta/recipes-devtools/installer/adt-installer/adt_installer
@@ -170,7 +170,7 @@ if [ ! -x $LOCAL_OPKG_LOC/bin/opkg-cl ]; then
   check_result
 
   echo_info Configure opkg ...\n
-  ./autogen.sh --prefix=$parent_folder/$LOCAL_OPKG_LOC 
--with-opkglibdir=$OPKG_LIBDIR --disable-curl --disable-ssl-curl --disable-gpg 
--disable-shave  $parent_folder/$YOCTOADT_INSTALL_LOG_FILE
+  ./autogen.sh --prefix=$parent_folder/$LOCAL_OPKG_LOC 
--with-opkglibdir=$OPKG_LIBDIR --enable-shared=no --disable-curl 
--disable-ssl-curl --disable-gpg --disable-shave  
$parent_folder/$YOCTOADT_INSTALL_LOG_FILE
   check_result
 
   echo_info Make opkg ...\n
@@ -241,7 +241,7 @@ get_qemu_image()
 
   if [ $1 == x86 ] || [ $1 == x86_64 ]; then
 qemu_kernel=bzImage-qemu$target.bin
-  elif [ $1 == mips ]; then
+  elif [ $1 == ppc ] || [ $1 == mips ]; then
 qemu_kernel=vmlinux-qemu$target.bin
   else
 qemu_kernel=zImage-qemu$target.bin
diff --git a/meta/recipes-devtools/installer/adt-installer/adt_installer.conf 
b/meta/recipes-devtools/installer/adt-installer/adt_installer.conf
index 275756e..afc69a4 100644
--- a/meta/recipes-devtools/installer/adt-installer/adt_installer.conf
+++ b/meta/recipes-devtools/installer/adt-installer/adt_installer.conf
@@ -42,7 +42,7 @@ YOCTOADT_NFS_UTIL=Y
 #YOCTOADT_ROOTFS_$arch is for specifying what root filesystem image files you 
want to download from the repository. The valid values to replace $arch are: 
arm, x86, x86_64, powerpc, mips.  The valid image files are: minimal, 
minimal-dev, sato, sato-dev, sato-sdk,lsb, lsb-dev, lsb-sdk.  If you want to 
download multiple images, the entries are space separated
 YOCTOADT_ROOTFS_arm=minimal sato-sdk
 #Specify which root filesystem file to use to extract as target sysroot.  
Please ensure the entry is in the list of downloaded root filesystem files that 
specified above in YOCTOADT_ROOTFS_$arch
-YOCTOADT_TARGET_SYSROOT_IMAGE_arm=minimal
+YOCTOADT_TARGET_SYSROOT_IMAGE_arm=sato-sdk
 #The location where the target sysroot will be setup
 YOCTOADT_TARGET_SYSROOT_LOC_arm=$HOME/test-yocto/arm
 
@@ -52,14 +52,14 @@ YOCTOADT_TARGET_SYSROOT_LOC_arm=$HOME/test-yocto/arm
 #YOCTOADT_TARGET_SYSROOT_LOC_x86=$HOME/test-yocto/x86
 
 #Here's some template of other arches, which you need to change the value in 
-#YOCTOADT_TARGET_SYSROOT_IMAGE_x86_64=
-#YOCTOADT_TARGET_SYSROOT_LOC_x86_64=
-#YOCTOADT_ROOTFS_x86_64=
+#YOCTOADT_ROOTFS_x86_64=sato-sdk
+#YOCTOADT_TARGET_SYSROOT_IMAGE_x86_64=sato-sdk
+#YOCTOADT_TARGET_SYSROOT_LOC_x86_64=$HOME/test-yocto/x86_64
 
-#YOCTOADT_TARGET_SYSROOT_IMAGE_ppc=
-#YOCTOADT_TARGET_SYSROOT_LOC_ppc=
-#YOCTOADT_ROOTFS_ppc=
+#YOCTOADT_ROOTFS_ppc=sato-sdk
+#YOCTOADT_TARGET_SYSROOT_IMAGE_ppc=sato-sdk
+#YOCTOADT_TARGET_SYSROOT_LOC_ppc=$HOME/test-yocto/ppc
 
-#YOCTOADT_TARGET_SYSROOT_IMAGE_mips=
-#YOCTOADT_TARGET_SYSROOT_LOC_mips=
-#YOCTOADT_ROOTFS_mips=
+#YOCTOADT_ROOTFS_mips=sato-sdk
+#YOCTOADT_TARGET_SYSROOT_IMAGE_mips=sato-sdk
+#YOCTOADT_TARGET_SYSROOT_LOC_mips=$HOME/test-yocto/mips
diff --git a/meta/recipes-devtools/installer/adt-installer_1.0.bb 
b/meta/recipes-devtools/installer/adt-installer_1.0.bb
index 07bef88..5dc0896 100644
--- a/meta/recipes-devtools/installer/adt-installer_1.0.bb
+++ b/meta/recipes-devtools/installer/adt-installer_1.0.bb
@@ -30,7 +30,7 @@ ALLOW_EMPTY = 1
 
 PACKAGES = 
 
-PR = r8
+PR = r9
 
 ADT_DEPLOY = ${TMPDIR}/deploy/sdk/
 ADT_DIR = ${WORKDIR}/adt-installer/
-- 
1.7.0.4


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

[OE-core] [PATCH 0/1] adt-installer fixing

Fixing the adt-installer for ppc kernel naming and some other issues.

The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:
  Saul Wold (1):
runqemu-internal: Add console=tty for qemuppc and NFS

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib llu/adt-installer
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=llu/adt-installer

Lianhao Lu (1):
  adt-installer: Fixed ppc kernel naming.

 .../installer/adt-installer/adt_installer  |4 ++--
 .../installer/adt-installer/adt_installer.conf |   20 ++--
 .../installer/adt-installer_1.0.bb |2 +-
 3 files changed, 13 insertions(+), 13 deletions(-)


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

Re: [OE-core] [PATCH 0/1] meta-toolchain: runqemu falied on FC16/Opensuse12.1 x86_64




On 04/09/2012 06:36 PM, Lu, Lianhao wrote:


Robert Yang wrote on 2012-04-09:

Test info:
* Have tested on:
   * Fedora 16 x86_64
   * Opensuse 12.1 x86_64


Robert,
Hongna just found a qemu launch error on openSuse x86_64 using the 2.15 
eglibc-nativesdk, something about the SDL initialization error. Did your 
platform work well?



Maybe he just used ssh without -X or -Y ? There would be an SDL 
initialization error when ssh without -X or -Y. It worked well for me.


// Robert


   * Ubuntu 10.04
* The testing commands are:
   $ bitbake core-image-sato meta-toolchain meta-toolchain-sdk

   And untar the sdk, then runqemu from the sdk to start the target.
// Robert

The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:

   runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 01:12:15 
+0100)
are available in the git repository at:
   git://git.pokylinux.org/poky-contrib robert/tc
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/tc
Robert Yang (1):
   meta-toolchain: runqemu falied on FC16/Opensuse12.1 x86_64
  meta/conf/distro/include/tcmode-default.inc |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

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


Best Regards,
Lianhao



___
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] git 1.7.7: remove perl.mak before compile

Test info:

* $ bitbake git-native -ccompile
* $ touch tmp/sysroots/i686-linux/usr/lib/perl-native/perl/5.14.2/Config.pm
* $ bitake git-native -f -ccompile

git-native (or git) built successfully.

// Robert

The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:

  runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 01:12:15 
+0100)

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

Robert Yang (1):
  git 1.7.7: remove perl.mak before compile

 meta/recipes-devtools/git/git.inc |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)


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

[OE-core] [PATCH 1/1] git 1.7.7: remove perl.mak before compile

The git may fail to rebuild when perl's Config.pm or config.h changes,
this is because Makefile detects that perl/perl.mak is out of date.
Remove perl.mak to let Makefile regenerate it would fix the error.
Both git and git-native have this problem.

To reproduce the error: (On x86_64 host)

$ bitbake git-native
$ touch tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.14.2/Config.pm
$ bitbake git-native -ccompile -f

[YOCTO #2156]

Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
 meta/recipes-devtools/git/git.inc |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-devtools/git/git.inc 
b/meta/recipes-devtools/git/git.inc
index be3831b..ce2f574 100644
--- a/meta/recipes-devtools/git/git.inc
+++ b/meta/recipes-devtools/git/git.inc
@@ -12,6 +12,12 @@ EXTRA_OECONF = 
--with-perl=${STAGING_BINDIR_NATIVE}/perl-native/perl --without-
 
 inherit autotools perlnative
 
+do_compile_prepend () {
+   # Remove perl/perl.mak to fix the out-of-date perl.mak error
+   # during rebuild
+   rm -f perl/perl.mak
+}
+
 do_install () {
oe_runmake install DESTDIR=${D} bindir=${bindir} \
template_dir=${datadir}/git-core/templates \
-- 
1.7.1


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

Re: [OE-core] [PATCH 0/1] shadow-native: disable logging to syslog

2012-04-09 Thread Chris Larson

On Sat, Apr 7, 2012 at 4:59 PM, Saul Wold s...@linux.intel.com wrote:
On 04/05/2012 11:53 PM, Scott Garman wrote:

Hello,

This pull request includes a patch to shadow to disable logging to
syslog, to prevent sysroot user and group additions from writing
entries to the host's syslog.

I have build-tested this with core-image-sato (which builds a few
useradd-based recipes, such as avahi and dbus) for all 5 of our
qemu architectures, while watching my syslog to verify that no
useradd or groupadd entries were written.

With this patch applied, the following error was seen on the AB:

| Running useradd commands...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| ERROR: tried running useradd command 10 times without success, giving up

Check the AB here:

http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/369/steps/shell_19/logs/stdio

We've (Mentor) hit this failure, usually from openssh's do_install,
from our automated builds at random over the past week or two.
--
Christopher Larson

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

Re: [OE-core] [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README


On 4/8/12 4:34 PM, Andreas Oberritter wrote:

On 07.04.2012 02:10, Mark Hatle wrote:

Just ran a local build with the qemumips machine, this is a standard
mips32 target.

 From the configure line for eglibc:

/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/work/mips32-oe-linux/eglibc-2.13-r23+svnr15508/eglibc-2_13/libc/configure
--build=x86_64-linux --host=mips-oe-linux --target=mips-oe-linux
--prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc
--sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib
--includedir=/usr/include --oldincludedir=/usr/include
--infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules
--disable-dependency-tracking
--with-libtool-sysroot=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips
--enable-kernel=2.6.16 --without-cvs --disable-profile --disable-debug
--without-gd --enable-clocale=gnu
--enable-add-ons=ports,nptl,libidn,ports
--with-headers=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips/usr/include
--without-selinux

The system is correctly setting the target to mips-oe-linux.

I checked and bash is the same way.

So the canonical arch is correct, the mips32 is only the packaging
arch.  It was always intended that the packaging arch be used in full on
MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
necessary if we expand the mips tunings.)


I don't think such a change should be done only few days before a
release. Until this patch was applied, the packaging arch has always
been mipsel, not mips32el. Please, revert or fix this!


This is easy to change to the previous behavior...  however it was a bug in the 
original implementation.


But again, I stress nothing changed except for the packaging arch... the way the 
packages are configured, compiled, installed remain the same, only the package 
arch has changed.  The only place that may be affected by this is the package 
feed mechanism.


To revert to the previous behavior, in the 
meta/conf/machine/include/tune-mips.inc:

--- a/meta/conf/machine/include/tune-mips32.inc
+++ b/meta/conf/machine/include/tune-mips32.inc
@@ -9,17 +9,17 @@ TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, mips32
 AVAILTUNES += mips32 mips32el mips32-nf mips32el-nf

 TUNE_FEATURES_tune-mips32 = ${TUNE_FEATURES_tune-mips} mips32
-MIPSPKGSFX_VARIANT_tune-mips32 = mips32
+MIPSPKGSFX_VARIANT_tune-mips32 = mips
 PACKAGE_EXTRA_ARCHS_tune-mips32 = mips mips32

 TUNE_FEATURES_tune-mips32el = ${TUNE_FEATURES_tune-mipsel} mips32
-MIPSPKGSFX_VARIANT_tune-mips32el = mips32el
+MIPSPKGSFX_VARIANT_tune-mips32el = mipsel
 PACKAGE_EXTRA_ARCHS_tune-mips32el = mipsel mips32el

 TUNE_FEATURES_tune-mips32-nf = ${TUNE_FEATURES_tune-mips-nf} mips32
-MIPSPKGSFX_VARIANT_tune-mips32-nf = mips32
+MIPSPKGSFX_VARIANT_tune-mips32-nf = mips
 PACKAGE_EXTRA_ARCHS_tune-mips32-nf = mips-nf mips32-nf

 TUNE_FEATURES_tune-mips32el-nf = ${TUNE_FEATURES_tune-mipsel-nf} mips32
-MIPSPKGSFX_VARIANT_tune-mips32el-nf = mips32el
+MIPSPKGSFX_VARIANT_tune-mips32el-nf = mipsel
 PACKAGE_EXTRA_ARCHS_tune-mips32el-nf = mipsel-nf mips32el-nf

Before I submit this patch though, I would like others to weigh in on the issue. 
 This was a mistake in the earlier version of the code.  The variant wasn't 
be set as it should have been.


The problem is that if you set the tune to mips, you get the default compiler 
behavior.  However, if you set the tune to mips32, you get -march=mips32 added 
to your CCARGS.  This will produce slightly different binaries, thus mips and 
mips32 are not equal.


--Mark


So right now, I don't see any failure conditions with an oe-core build.
(This is oe-core as of earlier today.)

--Mark


___
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

Re: [OE-core] [PATCH 0/1] shadow-native: disable logging to syslog


On 04/08/2012 10:00 PM, Scott Garman wrote:

On 04/07/2012 04:59 PM, Saul Wold wrote:

On 04/05/2012 11:53 PM, Scott Garman wrote:

Hello,

This pull request includes a patch to shadow to disable logging to
syslog, to prevent sysroot user and group additions from writing
entries to the host's syslog.

I have build-tested this with core-image-sato (which builds a few
useradd-based recipes, such as avahi and dbus) for all 5 of our
qemu architectures, while watching my syslog to verify that no
useradd or groupadd entries were written.



With this patch applied, the following error was seen on the AB:

| Running useradd commands...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| ERROR: tried running useradd command 10 times without success,
giving up

Check the AB here:

http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/369/steps/shell_19/logs/stdio



Hi Saul,

The syslog disable patch cannot trigger this error, I'm pretty certain
you have encountered another problem.

The useradd class now uses code which checks that the user account or
group account was created in the passwd and group files, respectively.
If the account was not created (which is verified via a grep command),
the script sleeps for 1 second and tries again, up to 10 times. This is
intended to avoid lockfile races, as useradd and groupadd lock the
passwd and group files when creating accounts.

It seems extremely unlikely that the passwd file was locked for a full
10s worth of attempts to access it. I also see from the logs that the
base-passwd package was installed before this error was encountered,
which *should* rule out the possibility that the useradd command was
failing because /etc/passwd didn't exist yet.

Later useradd commands are also failing in this manner, which makes me
suspect that something is wrong with the /etc/passwd file in this image.
The groupadd commands, on the other hand, are succeeding without any
retries.

So it would be helpful for me to know answers to the following:

Was this a build from scratch or from sstate?


This was from sstate.


Is this problem reproducible? (I'm starting a build from scratch
overnight on my end)

Only saw it on one build over the weekend, but turns out a bug already 
existed with this issue, but it was filed as a PAM build failure (see 
2218) , which maybe I need to re-assign to you.




What does the etc/passwd file in this image look like?


You can get it from the AB yourself, correct?  If not, let me know please.

Sau!


Thanks,

Scott



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

Re: [OE-core] [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

2012-04-09 Thread Koen Kooi

Op 9 apr. 2012, om 17:17 heeft Mark Hatle het volgende geschreven:

On 4/8/12 4:34 PM, Andreas Oberritter wrote:
On 07.04.2012 02:10, Mark Hatle wrote:
Just ran a local build with the qemumips machine, this is a standard
mips32 target.

From the configure line for eglibc:

/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/work/mips32-oe-linux/eglibc-2.13-r23+svnr15508/eglibc-2_13/libc/configure
--build=x86_64-linux --host=mips-oe-linux --target=mips-oe-linux
--prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc
--sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib
--includedir=/usr/include --oldincludedir=/usr/include
--infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules
--disable-dependency-tracking
--with-libtool-sysroot=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips
--enable-kernel=2.6.16 --without-cvs --disable-profile --disable-debug
--without-gd --enable-clocale=gnu
--enable-add-ons=ports,nptl,libidn,ports
--with-headers=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips/usr/include
--without-selinux

The system is correctly setting the target to mips-oe-linux.

I checked and bash is the same way.

So the canonical arch is correct, the mips32 is only the packaging
arch. It was always intended that the packaging arch be used in full on
MIPS. (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
necessary if we expand the mips tunings.)

I don't think such a change should be done only few days before a
release. Until this patch was applied, the packaging arch has always
been mipsel, not mips32el. Please, revert or fix this!

This is easy to change to the previous behavior... however it was a bug in
the original implementation.

But again, I stress nothing changed except for the packaging arch... the way
the packages are configured, compiled, installed remain the same, only the
package arch has changed.

only

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

Re: [OE-core] [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README


On 4/9/12 10:56 AM, Koen Kooi wrote:


Op 9 apr. 2012, om 17:17 heeft Mark Hatle het volgende geschreven:


On 4/8/12 4:34 PM, Andreas Oberritter wrote:

On 07.04.2012 02:10, Mark Hatle wrote:

Just ran a local build with the qemumips machine, this is a standard
mips32 target.

 From the configure line for eglibc:

/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/work/mips32-oe-linux/eglibc-2.13-r23+svnr15508/eglibc-2_13/libc/configure
--build=x86_64-linux --host=mips-oe-linux --target=mips-oe-linux
--prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc
--sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib
--includedir=/usr/include --oldincludedir=/usr/include
--infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules
--disable-dependency-tracking
--with-libtool-sysroot=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips
--enable-kernel=2.6.16 --without-cvs --disable-profile --disable-debug
--without-gd --enable-clocale=gnu
--enable-add-ons=ports,nptl,libidn,ports
--with-headers=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips/usr/include
--without-selinux

The system is correctly setting the target to mips-oe-linux.

I checked and bash is the same way.

So the canonical arch is correct, the mips32 is only the packaging
arch.  It was always intended that the packaging arch be used in full on
MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
necessary if we expand the mips tunings.)


I don't think such a change should be done only few days before a
release. Until this patch was applied, the packaging arch has always
been mipsel, not mips32el. Please, revert or fix this!


This is easy to change to the previous behavior...  however it was a bug in the 
original implementation.

But again, I stress nothing changed except for the packaging arch... the way 
the packages are configured, compiled, installed remain the same, only the 
package arch has changed.


only


Yes, only.  The package arch is used by the feed system and the build of the 
images.  I verified the images were still being generated corrected.  I did not 
verify anything within external package feeds, as I have no way to easily do this.


If anything else in the system is using the package arch as a key, then it's 
broken.  The configure arch, the tuning, and similar are all reasonable things 
to use, but the package arch is arbitrary.  We may have a fairly defined, 
defacto set, but they really are arbitrary and should not affect any software -- 
other then those directly working with the package feeds.


--Mark




___
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

Re: [OE-core] [PATCH 0/1] shadow-native: disable logging to syslog

2012-04-09 Thread Scott Garman


On 04/09/2012 08:30 AM, Saul Wold wrote:

On 04/08/2012 10:00 PM, Scott Garman wrote:

On 04/07/2012 04:59 PM, Saul Wold wrote:

On 04/05/2012 11:53 PM, Scott Garman wrote:

Hello,

This pull request includes a patch to shadow to disable logging to
syslog, to prevent sysroot user and group additions from writing
entries to the host's syslog.

I have build-tested this with core-image-sato (which builds a few
useradd-based recipes, such as avahi and dbus) for all 5 of our
qemu architectures, while watching my syslog to verify that no
useradd or groupadd entries were written.



With this patch applied, the following error was seen on the AB:

| Running useradd commands...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| ERROR: tried running useradd command 10 times without success,
giving up

Check the AB here:

http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/369/steps/shell_19/logs/stdio




Hi Saul,

The syslog disable patch cannot trigger this error, I'm pretty certain
you have encountered another problem.

The useradd class now uses code which checks that the user account or
group account was created in the passwd and group files, respectively.
If the account was not created (which is verified via a grep command),
the script sleeps for 1 second and tries again, up to 10 times. This is
intended to avoid lockfile races, as useradd and groupadd lock the
passwd and group files when creating accounts.

It seems extremely unlikely that the passwd file was locked for a full
10s worth of attempts to access it. I also see from the logs that the
base-passwd package was installed before this error was encountered,
which *should* rule out the possibility that the useradd command was
failing because /etc/passwd didn't exist yet.

Later useradd commands are also failing in this manner, which makes me
suspect that something is wrong with the /etc/passwd file in this image.
The groupadd commands, on the other hand, are succeeding without any
retries.

So it would be helpful for me to know answers to the following:

Was this a build from scratch or from sstate?


This was from sstate.


Is this problem reproducible? (I'm starting a build from scratch
overnight on my end)


Only saw it on one build over the weekend, but turns out a bug already
existed with this issue, but it was filed as a PAM build failure (see
2218) , which maybe I need to re-assign to you.


Yes, I've re-assigned this bug to myself.


What does the etc/passwd file in this image look like?


You can get it from the AB yourself, correct? If not, let me know please.


This was a nightly build and it no longer appears to be on the server - 
assuming I'm connected to the correct one?


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] [PATCH 0/1] shadow-native: disable logging to syslog


On 04/09/2012 09:23 AM, Scott Garman wrote:

On 04/09/2012 08:30 AM, Saul Wold wrote:

On 04/08/2012 10:00 PM, Scott Garman wrote:

On 04/07/2012 04:59 PM, Saul Wold wrote:

On 04/05/2012 11:53 PM, Scott Garman wrote:

Hello,

This pull request includes a patch to shadow to disable logging to
syslog, to prevent sysroot user and group additions from writing
entries to the host's syslog.

I have build-tested this with core-image-sato (which builds a few
useradd-based recipes, such as avahi and dbus) for all 5 of our
qemu architectures, while watching my syslog to verify that no
useradd or groupadd entries were written.



With this patch applied, the following error was seen on the AB:

| Running useradd commands...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| ERROR: tried running useradd command 10 times without success,
giving up

Check the AB here:

http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/369/steps/shell_19/logs/stdio





Hi Saul,

The syslog disable patch cannot trigger this error, I'm pretty certain
you have encountered another problem.

The useradd class now uses code which checks that the user account or
group account was created in the passwd and group files, respectively.
If the account was not created (which is verified via a grep command),
the script sleeps for 1 second and tries again, up to 10 times. This is
intended to avoid lockfile races, as useradd and groupadd lock the
passwd and group files when creating accounts.

It seems extremely unlikely that the passwd file was locked for a full
10s worth of attempts to access it. I also see from the logs that the
base-passwd package was installed before this error was encountered,
which *should* rule out the possibility that the useradd command was
failing because /etc/passwd didn't exist yet.

Later useradd commands are also failing in this manner, which makes me
suspect that something is wrong with the /etc/passwd file in this image.
The groupadd commands, on the other hand, are succeeding without any
retries.

So it would be helpful for me to know answers to the following:

Was this a build from scratch or from sstate?


This was from sstate.


Is this problem reproducible? (I'm starting a build from scratch
overnight on my end)


Only saw it on one build over the weekend, but turns out a bug already
existed with this issue, but it was filed as a PAM build failure (see
2218) , which maybe I need to re-assign to you.


Yes, I've re-assigned this bug to myself.


Ok thanks.


What does the etc/passwd file in this image look like?


You can get it from the AB yourself, correct? If not, let me know please.


This was a nightly build and it no longer appears to be on the server -
assuming I'm connected to the correct one?

ab05, since this was a non-lsb build, the tmp dir you need to look at is 
non-lsbtmp, it should be there, I just checked.




Scott



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

[OE-core] [PATCH 0/1] hello-mod: Remove hello-mod example external kernel module recipe

The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:

  runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 01:12:15 
+0100)

are available in the git repository at:
  git://git.yoctoproject.org/user-contrib/dvhart/oe-core hello-mod
  
http://git.yoctoproject.org/cgit.cgi/user-contrib/dvhart/oe-core/log/?h=hello-mod

Darren Hart (1):
  hello-mod: Remove hello-mod example external kernel module recipe

 meta/recipes-kernel/hello-mod/files/COPYING|  340 
 meta/recipes-kernel/hello-mod/files/Makefile   |   14 -
 meta/recipes-kernel/hello-mod/files/hello.c|   33 ---
 meta/recipes-kernel/hello-mod/hello-mod_0.1.bb |   15 -
 4 files changed, 0 insertions(+), 402 deletions(-)
 delete mode 100644 meta/recipes-kernel/hello-mod/files/COPYING
 delete mode 100644 meta/recipes-kernel/hello-mod/files/Makefile
 delete mode 100644 meta/recipes-kernel/hello-mod/files/hello.c
 delete mode 100644 meta/recipes-kernel/hello-mod/hello-mod_0.1.bb

-- 
1.7.6.5


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

[OE-core] [PATCH 1/1] hello-mod: Remove hello-mod example external kernel module recipe

Fixes [YOCTO #1501]

oe-core contains a core set of recipes user in other layers. The
hello-mod recipe is an example recipe and does not provide any
useful functionality for the target system.

Such a recipe is a better match for an examples layer, such as
meta-skeleton, currently part the poky repository.

Remove hello-mod from oe-core. A subsequent patch to poky will
add it back to meta-skeleton.

Signed-off-by: Darren Hart dvh...@linux.intel.com
---
 meta/recipes-kernel/hello-mod/files/COPYING|  340 
 meta/recipes-kernel/hello-mod/files/Makefile   |   14 -
 meta/recipes-kernel/hello-mod/files/hello.c|   33 ---
 meta/recipes-kernel/hello-mod/hello-mod_0.1.bb |   15 -
 4 files changed, 0 insertions(+), 402 deletions(-)
 delete mode 100644 meta/recipes-kernel/hello-mod/files/COPYING
 delete mode 100644 meta/recipes-kernel/hello-mod/files/Makefile
 delete mode 100644 meta/recipes-kernel/hello-mod/files/hello.c
 delete mode 100644 meta/recipes-kernel/hello-mod/hello-mod_0.1.bb

diff --git a/meta/recipes-kernel/hello-mod/files/COPYING 
b/meta/recipes-kernel/hello-mod/files/COPYING
deleted file mode 100644
index 6d45519..000
--- a/meta/recipes-kernel/hello-mod/files/COPYING
+++ /dev/null
@@ -1,340 +0,0 @@
-   GNU GENERAL PUBLIC LICENSE
-  Version 2, June 1991
-
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
-   51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-   Preamble
-
-  The licenses for most software are designed to take away your
-freedom to share and change it.  By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users.  This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it.  (Some other Free Software Foundation software is covered by
-the GNU Library General Public License instead.)  You can apply it to
-your programs, too.
-
-  When we speak of free software, we are referring to freedom, not
-price.  Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
-
-  To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
-  For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have.  You must make sure that they, too, receive or can get the
-source code.  And you must show them these terms so they know their
-rights.
-
-  We protect your rights with two steps: (1) copyright the software, and
-(2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
-  Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software.  If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
-  Finally, any free program is threatened constantly by software
-patents.  We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary.  To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
-  The precise terms and conditions for copying, distribution and
-modification follow.
-
-   GNU GENERAL PUBLIC LICENSE
-   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
-  0. This License applies to any program or other work which contains
-a notice placed by the copyright holder saying it may be distributed
-under the terms of this General Public License.  The Program, below,
-refers to any such program or work, and a work based on the Program
-means either the Program or any derivative work under copyright law:
-that is to say, a work containing the Program or a portion of it,
-either verbatim or with modifications and/or translated into another
-language.  (Hereinafter, translation is included without limitation in
-the term modification.)  Each licensee is addressed as you.
-
-Activities other than copying,

Re: [OE-core] [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

2012-04-09 Thread Andreas Oberritter

On 09.04.2012 17:17, Mark Hatle wrote:
 On 4/8/12 4:34 PM, Andreas Oberritter wrote:
 On 07.04.2012 02:10, Mark Hatle wrote:
 Just ran a local build with the qemumips machine, this is a standard
 mips32 target.

  From the configure line for eglibc:

 /msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/work/mips32-oe-linux/eglibc-2.13-r23+svnr15508/eglibc-2_13/libc/configure

 --build=x86_64-linux --host=mips-oe-linux --target=mips-oe-linux
 --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
 --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc
 --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib
 --includedir=/usr/include --oldincludedir=/usr/include
 --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules
 --disable-dependency-tracking
 --with-libtool-sysroot=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips

 --enable-kernel=2.6.16 --without-cvs --disable-profile --disable-debug
 --without-gd --enable-clocale=gnu
 --enable-add-ons=ports,nptl,libidn,ports
 --with-headers=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips/usr/include

 --without-selinux

 The system is correctly setting the target to mips-oe-linux.

 I checked and bash is the same way.

 So the canonical arch is correct, the mips32 is only the packaging
 arch.  It was always intended that the packaging arch be used in full on
 MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
 necessary if we expand the mips tunings.)

 I don't think such a change should be done only few days before a
 release. Until this patch was applied, the packaging arch has always
 been mipsel, not mips32el. Please, revert or fix this!
 
 This is easy to change to the previous behavior...  however it was a bug
 in the original implementation.
 
 But again, I stress nothing changed except for the packaging arch... the
 way the packages are configured, compiled, installed remain the same,
 only the package arch has changed.  The only place that may be affected
 by this is the package feed mechanism.

I think breaking package feeds in such a way is one of the worst things
to do in OE.

 To revert to the previous behavior, in the
 meta/conf/machine/include/tune-mips.inc:
 
 --- a/meta/conf/machine/include/tune-mips32.inc
 +++ b/meta/conf/machine/include/tune-mips32.inc
 @@ -9,17 +9,17 @@ TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES,
 mips32
  AVAILTUNES += mips32 mips32el mips32-nf mips32el-nf
 
  TUNE_FEATURES_tune-mips32 = ${TUNE_FEATURES_tune-mips} mips32
 -MIPSPKGSFX_VARIANT_tune-mips32 = mips32
 +MIPSPKGSFX_VARIANT_tune-mips32 = mips
  PACKAGE_EXTRA_ARCHS_tune-mips32 = mips mips32
 
  TUNE_FEATURES_tune-mips32el = ${TUNE_FEATURES_tune-mipsel} mips32
 -MIPSPKGSFX_VARIANT_tune-mips32el = mips32el
 +MIPSPKGSFX_VARIANT_tune-mips32el = mipsel
  PACKAGE_EXTRA_ARCHS_tune-mips32el = mipsel mips32el
   
I don't think this is correct, in all four cases, because no packages
will have that arch.

  TUNE_FEATURES_tune-mips32-nf = ${TUNE_FEATURES_tune-mips-nf} mips32
 -MIPSPKGSFX_VARIANT_tune-mips32-nf = mips32
 +MIPSPKGSFX_VARIANT_tune-mips32-nf = mips
  PACKAGE_EXTRA_ARCHS_tune-mips32-nf = mips-nf mips32-nf
 
  TUNE_FEATURES_tune-mips32el-nf = ${TUNE_FEATURES_tune-mipsel-nf} mips32
 -MIPSPKGSFX_VARIANT_tune-mips32el-nf = mips32el
 +MIPSPKGSFX_VARIANT_tune-mips32el-nf = mipsel
  PACKAGE_EXTRA_ARCHS_tune-mips32el-nf = mipsel-nf mips32el-nf
 
 Before I submit this patch though, I would like others to weigh in on
 the issue.  This was a mistake in the earlier version of the code.  The
 variant wasn't be set as it should have been.
 
 The problem is that if you set the tune to mips, you get the default
 compiler behavior.

According to the gcc docs, there is no mips ISA name. Valid names are:
`mips1', `mips2', `mips3', `mips4', `mips32', `mips32r2', `mips64' and
`mips64r2'. Therefore I don't understand why mips should default to
anything else, if it was an alias for mips32 before.

  However, if you set the tune to mips32, you get
 -march=mips32 added to your CCARGS.  This will produce slightly
 different binaries, thus mips and mips32 are not equal.

Btw, meta/recipes-core/eglibc/eglibc-ld.inc doesn't know about mips32 or
mips32el, so this probably broke, too.
meta/recipes-devtools/gdb/gdb-common.inc likewise. Do overrides still
work, e.g. EXTRA_OECONF_mipsel etc.? How about
meta/recipes-qt/qt4/qt4_arch.inc?

Whatever the answers are, the most important point is that it's the
worst point in time to do such a change. We should rather discuss it
after the release, if at all.

Regards,
Andreas

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

Re: [OE-core] [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README


On 4/9/12 3:06 PM, Andreas Oberritter wrote:

On 09.04.2012 17:17, Mark Hatle wrote:

On 4/8/12 4:34 PM, Andreas Oberritter wrote:

On 07.04.2012 02:10, Mark Hatle wrote:

Just ran a local build with the qemumips machine, this is a standard
mips32 target.



...


So the canonical arch is correct, the mips32 is only the packaging
arch.  It was always intended that the packaging arch be used in full on
MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
necessary if we expand the mips tunings.)


I don't think such a change should be done only few days before a
release. Until this patch was applied, the packaging arch has always
been mipsel, not mips32el. Please, revert or fix this!


This is easy to change to the previous behavior...  however it was a bug
in the original implementation.

But again, I stress nothing changed except for the packaging arch... the
way the packages are configured, compiled, installed remain the same,
only the package arch has changed.  The only place that may be affected
by this is the package feed mechanism.


I think breaking package feeds in such a way is one of the worst things
to do in OE.


To revert to the previous behavior, in the
meta/conf/machine/include/tune-mips.inc:



...


  TUNE_FEATURES_tune-mips32el = ${TUNE_FEATURES_tune-mipsel} mips32
-MIPSPKGSFX_VARIANT_tune-mips32el = mips32el
+MIPSPKGSFX_VARIANT_tune-mips32el = mipsel
  PACKAGE_EXTRA_ARCHS_tune-mips32el = mipsel mips32el


I don't think this is correct, in all four cases, because no packages
will have that arch.



...


Before I submit this patch though, I would like others to weigh in on
the issue.  This was a mistake in the earlier version of the code.  The
variant wasn't be set as it should have been.

The problem is that if you set the tune to mips, you get the default
compiler behavior.


According to the gcc docs, there is no mips ISA name. Valid names are:
`mips1', `mips2', `mips3', `mips4', `mips32', `mips32r2', `mips64' and
`mips64r2'. Therefore I don't understand why mips should default to
anything else, if it was an alias for mips32 before.



We have two sets of available tunings:

mips and mips32 tunings.. (add el and -nf variants)

These are -different- tunings and today the only way to notice the difference is 
based on the package arch.  The package arch is NOT the target ISA.  It's an 
arbitrary string we have come up with to let people know the architecture, ABI 
and optimizations used in producing specific software.  mips indicates that 
it's using the default mips compiler options, whatever those may be.  While 
mips32 says it is specifically tuned to the mips32 architecture settings.


I honestly have no idea what the default compiler settings for mips are, but the 
point is the tunings are different.  If you want the MIPS tune, you may not be 
able to run the items compiled with the -march=mips32 option.  We have to have a 
way to reconcile this.



  However, if you set the tune to mips32, you get
-march=mips32 added to your CCARGS.  This will produce slightly
different binaries, thus mips and mips32 are not equal.


Btw, meta/recipes-core/eglibc/eglibc-ld.inc doesn't know about mips32 or
mips32el, so this probably broke, too.
meta/recipes-devtools/gdb/gdb-common.inc likewise. Do overrides still
work, e.g. EXTRA_OECONF_mipsel etc.? How about
meta/recipes-qt/qt4/qt4_arch.inc?


Overrides are on the GNU canonical arch (TUNE_ARCH) correct?  If that is the 
case then mips or mipsel is the canonical arch.  Again, we do NOT use the 
package arch for these settings!


Below are the overrides and related elements from the bitbake.conf file:

OVERRIDES = 
${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable

DISTROOVERRIDES ?= ${@d.getVar('DISTRO', True) or ''}
MACHINEOVERRIDES ?= ${MACHINE}

# Used by canadian-cross to handle string conversions on TARGET_ARCH where 
needed
TRANSLATED_TARGET_ARCH ??= ${@d.getVar('TARGET_ARCH', True).replace(_, -)}

TARGET_ARCH = ${TUNE_ARCH}

So my reading of this is that, unless overriden somewhere outside of 
bitbake.conf, the override does include the TUNE_ARCH, via the TARGET_ARCH, via 
the TRANSLATED_TARGET_ARCH.




Whatever the answers are, the most important point is that it's the
worst point in time to do such a change. We should rather discuss it
after the release, if at all.


In order to resolve this consider the following:

We have two tunes, mips and mips32, the difference being the -march=mips32 
in the later case.


In order to support both tunes, we need to have a way to differentiate between 
them on a package arch basis or we end up in a situation where we have two 
packages with different contents and no way to tell them apart.


In order to reconcile the above, the three primary options are see are:

*) Define only mips or mips32 tune, but not both -- producing mips as the 
package arch.  (But

Re: [OE-core] [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

2012-04-09 Thread Andreas Oberritter

On 09.04.2012 22:25, Mark Hatle wrote:
 On 4/9/12 3:06 PM, Andreas Oberritter wrote:
 On 09.04.2012 17:17, Mark Hatle wrote:
 On 4/8/12 4:34 PM, Andreas Oberritter wrote:
 On 07.04.2012 02:10, Mark Hatle wrote:
 Just ran a local build with the qemumips machine, this is a standard
 mips32 target.

 
 ...
 
 So the canonical arch is correct, the mips32 is only the packaging
 arch.  It was always intended that the packaging arch be used in
 full on
 MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv,
 etc as
 necessary if we expand the mips tunings.)

 I don't think such a change should be done only few days before a
 release. Until this patch was applied, the packaging arch has always
 been mipsel, not mips32el. Please, revert or fix this!

 This is easy to change to the previous behavior...  however it was a bug
 in the original implementation.

 But again, I stress nothing changed except for the packaging arch... the
 way the packages are configured, compiled, installed remain the same,
 only the package arch has changed.  The only place that may be affected
 by this is the package feed mechanism.

 I think breaking package feeds in such a way is one of the worst things
 to do in OE.

 To revert to the previous behavior, in the
 meta/conf/machine/include/tune-mips.inc:

 
 ...
 
   TUNE_FEATURES_tune-mips32el = ${TUNE_FEATURES_tune-mipsel} mips32
 -MIPSPKGSFX_VARIANT_tune-mips32el = mips32el
 +MIPSPKGSFX_VARIANT_tune-mips32el = mipsel
   PACKAGE_EXTRA_ARCHS_tune-mips32el = mipsel mips32el
 
 I don't think this is correct, in all four cases, because no packages
 will have that arch.

 
 ...
 
 Before I submit this patch though, I would like others to weigh in on
 the issue.  This was a mistake in the earlier version of the code.  The
 variant wasn't be set as it should have been.

 The problem is that if you set the tune to mips, you get the default
 compiler behavior.

 According to the gcc docs, there is no mips ISA name. Valid names are:
 `mips1', `mips2', `mips3', `mips4', `mips32', `mips32r2', `mips64' and
 `mips64r2'. Therefore I don't understand why mips should default to
 anything else, if it was an alias for mips32 before.

 
 We have two sets of available tunings:
 
 mips and mips32 tunings.. (add el and -nf variants)
 
 These are -different- tunings and today the only way to notice the
 difference is based on the package arch.  The package arch is NOT the
 target ISA.  It's an arbitrary string we have come up with to let
 people know the architecture, ABI and optimizations used in producing
 specific software.  mips indicates that it's using the default mips
 compiler options, whatever those may be.  While mips32 says it is
 specifically tuned to the mips32 architecture settings.
 
 I honestly have no idea what the default compiler settings for mips are,
 but the point is the tunings are different.  If you want the MIPS
 tune, you may not be able to run the items compiled with the
 -march=mips32 option.  We have to have a way to reconcile this.
 
   However, if you set the tune to mips32, you get
 -march=mips32 added to your CCARGS.  This will produce slightly
 different binaries, thus mips and mips32 are not equal.

 Btw, meta/recipes-core/eglibc/eglibc-ld.inc doesn't know about mips32 or
 mips32el, so this probably broke, too.
 meta/recipes-devtools/gdb/gdb-common.inc likewise. Do overrides still
 work, e.g. EXTRA_OECONF_mipsel etc.? How about
 meta/recipes-qt/qt4/qt4_arch.inc?
 
 Overrides are on the GNU canonical arch (TUNE_ARCH) correct?  If that is
 the case then mips or mipsel is the canonical arch.  Again, we do
 NOT use the package arch for these settings!
 
 Below are the overrides and related elements from the bitbake.conf file:
 
 OVERRIDES =
 ${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable
 
 DISTROOVERRIDES ?= ${@d.getVar('DISTRO', True) or ''}
 MACHINEOVERRIDES ?= ${MACHINE}
 
 # Used by canadian-cross to handle string conversions on TARGET_ARCH
 where needed
 TRANSLATED_TARGET_ARCH ??= ${@d.getVar('TARGET_ARCH',
 True).replace(_, -)}
 
 TARGET_ARCH = ${TUNE_ARCH}
 
 So my reading of this is that, unless overriden somewhere outside of
 bitbake.conf, the override does include the TUNE_ARCH, via the
 TARGET_ARCH, via the TRANSLATED_TARGET_ARCH.
 

 Whatever the answers are, the most important point is that it's the
 worst point in time to do such a change. We should rather discuss it
 after the release, if at all.
 
 In order to resolve this consider the following:
 
 We have two tunes, mips and mips32, the difference being the
 -march=mips32 in the later case.
 
 In order to support both tunes, we need to have a way to differentiate
 between them on a package arch basis or we end up in a situation where
 we have two packages with different contents and no way to tell them apart.
 
 In order to reconcile the above, the three primary options are

Re: [OE-core] [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README


On 4/9/12 3:25 PM, Mark Hatle wrote:

On 4/9/12 3:06 PM, Andreas Oberritter wrote:

On 09.04.2012 17:17, Mark Hatle wrote:

On 4/8/12 4:34 PM, Andreas Oberritter wrote:

On 07.04.2012 02:10, Mark Hatle wrote:

Just ran a local build with the qemumips machine, this is a standard
mips32 target.



...


So the canonical arch is correct, the mips32 is only the packaging
arch.  It was always intended that the packaging arch be used in full on
MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
necessary if we expand the mips tunings.)


I don't think such a change should be done only few days before a
release. Until this patch was applied, the packaging arch has always
been mipsel, not mips32el. Please, revert or fix this!


This is easy to change to the previous behavior...  however it was a bug
in the original implementation.

But again, I stress nothing changed except for the packaging arch... the
way the packages are configured, compiled, installed remain the same,
only the package arch has changed.  The only place that may be affected
by this is the package feed mechanism.


I think breaking package feeds in such a way is one of the worst things
to do in OE.


To revert to the previous behavior, in the
meta/conf/machine/include/tune-mips.inc:



...


   TUNE_FEATURES_tune-mips32el = ${TUNE_FEATURES_tune-mipsel} mips32
-MIPSPKGSFX_VARIANT_tune-mips32el = mips32el
+MIPSPKGSFX_VARIANT_tune-mips32el = mipsel
   PACKAGE_EXTRA_ARCHS_tune-mips32el = mipsel mips32el

 
I don't think this is correct, in all four cases, because no packages
will have that arch.



...


Before I submit this patch though, I would like others to weigh in on
the issue.  This was a mistake in the earlier version of the code.  The
variant wasn't be set as it should have been.

The problem is that if you set the tune to mips, you get the default
compiler behavior.


According to the gcc docs, there is no mips ISA name. Valid names are:
`mips1', `mips2', `mips3', `mips4', `mips32', `mips32r2', `mips64' and
`mips64r2'. Therefore I don't understand why mips should default to
anything else, if it was an alias for mips32 before.



We have two sets of available tunings:

mips and mips32 tunings.. (add el and -nf variants)

These are -different- tunings and today the only way to notice the difference is
based on the package arch.  The package arch is NOT the target ISA.  It's an
arbitrary string we have come up with to let people know the architecture, ABI
and optimizations used in producing specific software.  mips indicates that
it's using the default mips compiler options, whatever those may be.  While
mips32 says it is specifically tuned to the mips32 architecture settings.

I honestly have no idea what the default compiler settings for mips are, but the
point is the tunings are different.  If you want the MIPS tune, you may not be
able to run the items compiled with the -march=mips32 option.  We have to have a
way to reconcile this.


I did some further digging into the GCC configuration.

The default configuration is defined in the various defines:

#define _R3000 1
#define __mips_fpr 32
#define _MIPS_ARCH_MIPS1 1
#define _MIPS_ARCH mips1
#define _MIPS_TUNE_MIPS1 1
#define _MIPS_TUNE mips1
#define __mips 1
#define _MIPS_ISA _MIPS_ISA_MIPS1

The default is defined for the MIPS1 architecture.

The -march=mips32 changes the above to:

#define __mips__ 1
#define _mips 1
#define mips 1
#define __R3000 1
#define __R3000__ 1
#define R3000 1
#define _R3000 1
#define __mips_fpr 32
#define _MIPS_ARCH_MIPS32 1
#define _MIPS_ARCH mips32
#define _MIPS_TUNE_MIPS32 1
#define _MIPS_TUNE mips32
#define __mips 32
#define __mips_isa_rev 1
#define _MIPS_ISA _MIPS_ISA_MIPS32

Internally in gcc the different between the two is processor optimizations 
change from the R3000 to the MIPS 4Kc, and PTF_AVOID_BRANCHLIKELY is defined.


   PTF_AVOID_BRANCHLIKELY
Set if it is usually not profitable to use branch-likely instructions
for this target, typically because the branches are always predicted
taken and so incur a large overhead when not taken.

So there will in fact be a difference in the generated binaries.


   However, if you set the tune to mips32, you get
-march=mips32 added to your CCARGS.  This will produce slightly
different binaries, thus mips and mips32 are not equal.


Btw, meta/recipes-core/eglibc/eglibc-ld.inc doesn't know about mips32 or
mips32el, so this probably broke, too.
meta/recipes-devtools/gdb/gdb-common.inc likewise. Do overrides still
work, e.g. EXTRA_OECONF_mipsel etc.? How about
meta/recipes-qt/qt4/qt4_arch.inc?


Overrides are on the GNU canonical arch (TUNE_ARCH) correct?  If that is the
case then mips or mipsel is the canonical arch.  Again, we do NOT use the
package arch for these settings!

Below are the overrides and related elements from the bitbake.conf file:

OVERRIDES =

Re: [OE-core] [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

2012-04-09 Thread Phil Blundell

On Mon, 2012-04-09 at 15:25 -0500, Mark Hatle wrote:
 And just to be extra clear, I consider it a defect if we can produce a 
 package 
 with the same name for two different tune settings.. (the exception being the 
 hell that is ARM and thumb namings.)

While you might consider that a defect (and it probably is a defensible
position to do so), it hasn't historically been considered such in OE.
The PACKAGE_ARCH value has, traditionally, been concerned purely with
ISA and ABI (i.e. answering the question can I execute this code?)
rather than optimisations.

For example, the tune-arm926ejs.inc and tune-xscale.inc files in current
oe-core both end up setting PACKAGE_ARCH to armv5tte (sic).  But those
are quite different processors and have different tuning requirements,
so the binaries you get are unlikely to be the same.  If you were to
take the view that the PACKAGE_ARCH must uniquely identify one set of
binaries then obviously each of these tunings (and probably all the ARM
cpu-specific tunings) would need to set PACKAGE_ARCH to some unique
value.

p.



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

[OE-core] ARM tunings was Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README


On 4/9/12 4:03 PM, Phil Blundell wrote:

On Mon, 2012-04-09 at 15:25 -0500, Mark Hatle wrote:

And just to be extra clear, I consider it a defect if we can produce a package
with the same name for two different tune settings.. (the exception being the
hell that is ARM and thumb namings.)


While you might consider that a defect (and it probably is a defensible
position to do so), it hasn't historically been considered such in OE.
The PACKAGE_ARCH value has, traditionally, been concerned purely with
ISA and ABI (i.e. answering the question can I execute this code?)
rather than optimisations.

For example, the tune-arm926ejs.inc and tune-xscale.inc files in current
oe-core both end up setting PACKAGE_ARCH to armv5tte (sic).  But those
are quite different processors and have different tuning requirements,
so the binaries you get are unlikely to be the same.  If you were to
take the view that the PACKAGE_ARCH must uniquely identify one set of
binaries then obviously each of these tunings (and probably all the ARM
cpu-specific tunings) would need to set PACKAGE_ARCH to some unique
value.


I do, and thus the hell that is ARM.  I could not currently generate a single 
package feed that work would on a variety of devices (like a traditional 
workstaton/server Linux OS would.)  While this isn't a big issue in the embedded 
space where we should hopefully be aware of the tunings and configuration were 
are using, it is still a problem.  As the systems get larger, the requirement 
for common pages feeds increases, leading to the problem being, well a problem. 
 (ARM is starting to be considered for Carrier Grade systems, many of which 
have very common requirements to traditional server Linux.  A set of established 
binaries and the vendors just want to drop in optimized applications.)


On ARM what we currently have defined is:
(tune) - (package arch)

arm1136jfs - armv6-vfp
arm920t - armv4t
arm926ejs - armv5te
arm9tdmi - armv4t
armv4b - armv4b
armv4tb - armv4tb
armv4 - armv4
armv4t - armv4t
armv5b - armv5b
armv5b-vfp - armv5b-vfp
armv5eb - armv5eb
armv5eb-vfp - armv5eb-vfp
armv5ehfb-vfp - armv5ehfb-vfp
armv5ehf-vfp - armv5ehf-vfp
armv5e-vfp - armv5e-vfp
armv5hfb-vfp - armv5hfb-vfp
armv5hf-vfp - armv5hf-vfp
armv5tb - armv5tb
armv5tb-vfp - armv5b-vfp
armv5teb - armv5teb
armv5teb-vfp - armv5teb-vfp
armv5tehfb-vfp - armv5tehfb-vfp
armv5tehf-vfp - armv5tehf-vfp
armv5te - armv5te
armv5te-vfp - armv5te-vfp
armv5thfb-vfp - armv5hfb-vfp
armv5thf-vfp - armv5hf-vfp
armv5 - armv5
armv5t - armv5t
armv5t-vfp - armv5-vfp
armv5-vfp - armv5-vfp
armv6b - armv6b-vfp
armv6hfb - armv6hfb-vfp
armv6hf - armv6hf-vfp
armv6tb - armv6tb-vfp
armv6thfb - armv6thfb-vfp
armv6thf - armv6thf-vfp
armv6 - armv6-vfp
armv6t - armv6t-vfp
armv7ab-neon - armv7ab-vfp-neon
armv7ab - armv7ab-vfp
armv7ahfb-neon - armv7ahfb-vfp-neon
armv7ahfb - armv7ahfb-vfp
armv7ahf-neon - armv7ahf-vfp-neon
armv7ahf - armv7ahf-vfp
armv7a-neon - armv7a-vfp-neon
armv7atb-neon - armv7ab-vfp-neon
armv7atb - armv7ab-vfp
armv7athfb - armv7ahfb-vfp
armv7athf-neon - armv7ahf-vfp-neon
armv7athf - armv7ahf-vfp
armv7a - armv7a-vfp
armv7at-neon - armv7a-vfp-neon
armv7at - armv7a-vfp
cortexa8hf-neon - armv7ahf-vfp-neon
cortexa8hf - armv7ahf-vfp
cortexa8-neon - armv7a-vfp-neon
cortexa8thf - armv7ahf-vfp
cortexa8 - armv7a-vfp
cortexa8t - armv7a-vfp
cortexa9hf-neon - armv7ahf-vfp-neon
cortexa9hf - armv7ahf-vfp
cortexa9-neon - armv7a-vfp-neon
cortexa9thf - armv7ahf-vfp
cortexa9 - armv7a-vfp
cortexa9t - armv7a-vfp
cortexm1 - armv7a-vfp
cortexm3 - armv7m-vfp
cortexr4 - armv7r-vfp
ep9312 - ep9312
iwmmxt - iwmmxt
strongarm - armv4

Add in to that one of the tunings -- not indicated by the package arch of thumb 
enabled or not, and its difficult to know exactly what is in a package without 
extracting and examining it.  But I consider this to be a quirk of the ARM 
architecture as implemented in OE.


--Mark


p.



___
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

Re: [OE-core] [PATCH 1/1] connman: ensure ofono package is generated.


On 04/05/2012 11:20 PM, Lianhao Lu wrote:

Make sure ofono package is generated when buidling connman, because
dynamic package connman-plugin-ofono has a RDEPENDS on ofono.

Since this is for a plugin, can the connman-plugin-ofono be generated in 
a separate package (or possibly even a separate recipe that depends on 
ofono, instead of making connman depend on ofono, I am not sure the 
solution below is correct either.


Sau!


Signed-off-by: Lianhao Lulianhao...@intel.com
---
  meta/recipes-connectivity/connman/connman.inc |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-connectivity/connman/connman.inc 
b/meta/recipes-connectivity/connman/connman.inc
index 1a6dd1b..3ed5667 100644
--- a/meta/recipes-connectivity/connman/connman.inc
+++ b/meta/recipes-connectivity/connman/connman.inc
@@ -39,6 +39,8 @@ EXTRA_OECONF += \
  --disable-ntpd \
  

+do_package[depends] = ${MLPREFIX}ofono:do_package
+
  INITSCRIPT_NAME = connman
  INITSCRIPT_PARAMS = start 05 5 2 3 . stop 22 0 1 6 .



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

Re: [OE-core] ARM tunings was Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

2012-04-09 Thread Phil Blundell

On Mon, 2012-04-09 at 16:21 -0500, Mark Hatle wrote:
 I do, and thus the hell that is ARM.  I could not currently generate a single 
 package feed that work would on a variety of devices (like a traditional 
 workstaton/server Linux OS would.) 

Well, actually, you could in fact do exactly that.  What you couldn't
necessarily do with the tunings as they exist right now is generate a
package feed which is optimised for (as opposed to works on) all those
devices.  But it isn't clear to me that you could do that with a
traditional workstaton/server kind of distribution either.  In the x86
world, for example, the majority of the big distros do not bother to
ship individually-tuned binaries for different processor types,
certainly not for the entire distribution.

Add in to that one of the tunings -- not indicated by the package arch
of thumb enabled or not

There are multiple reasons why this isn't indicated by the PACKAGE_ARCH.
Firstly, it's irrelevant: on v5T or newer, the question of whether a
given package is using Thumb-state or not has no ABI impact and there is
no reason for anyone to care at a compatibility level.  Second, it may
be unpredictable: the compiler is at liberty (although current versions
of gcc don't exploit this latitude) to switch arbitrarily between
ARM-state and Thumb-state as it sees fit to get the best performance.
And thirdly, it's just another piece of distro policy in the same way as
compiling for -O2 vs -Os (which we also don't encode into PACKAGE_ARCH)
is.

p.



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

Re: [OE-core] ARM tunings was Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README


On 4/9/12 4:30 PM, Phil Blundell wrote:

On Mon, 2012-04-09 at 16:21 -0500, Mark Hatle wrote:

I do, and thus the hell that is ARM.  I could not currently generate a single
package feed that work would on a variety of devices (like a traditional
workstaton/server Linux OS would.)


Well, actually, you could in fact do exactly that.  What you couldn't
necessarily do with the tunings as they exist right now is generate a
package feed which is optimised for (as opposed to works on) all those
devices.  But it isn't clear to me that you could do that with a
traditional workstaton/server kind of distribution either.  In the x86
world, for example, the majority of the big distros do not bother to
ship individually-tuned binaries for different processor types,
certainly not for the entire distribution.


Depends on the distribution and reasons for these feeds.  What is typical is 
that a base distribution will be generated for a common compatible (reasonable) 
architecture.. i.e. armv5 -- with specific optimized package (glibc, openssl, 
etc) for the target arch, i.e. armv7a.  Then you have a couple of packages 
hand-tuned for size, speed, or other that define or not thumb and add even a 
higher level of optimization.  It's possible, folks do it today.. but it's not 
always obvious.  (I have existing customers today that run a mix like I 
described through their own package feed like system.  They really don't care at 
all that the core system is tuned for a given processor -- they only care that 
their specific applications and certain areas are specifically tuned to their 
use-cases.)  Note, this is not what I would consider a typical use-case!



Add in to that one of the tunings -- not indicated by the package arch
of thumb enabled or not


There are multiple reasons why this isn't indicated by the PACKAGE_ARCH.
Firstly, it's irrelevant: on v5T or newer, the question of whether a
given package is using Thumb-state or not has no ABI impact and there is
no reason for anyone to care at a compatibility level.  Second, it may
be unpredictable: the compiler is at liberty (although current versions
of gcc don't exploit this latitude) to switch arbitrarily between
ARM-state and Thumb-state as it sees fit to get the best performance.
And thirdly, it's just another piece of distro policy in the same way as
compiling for -O2 vs -Os (which we also don't encode into PACKAGE_ARCH)
is.


I agree, on ARM the tunings and optimizations between regular and thumb do not 
impact the ABI what-so-ever.  And so far compilers have to be explicitly set to 
do thumb or tranditional ARM mode.. so in the end developers are looking into 
the performance and size impacts of each of these configuration and making 
changes as they see fit to best meet their needs.  These are unique cases 
though, the majority of the software built for the core OS uses a single policy 
-- it's when something needs to be further optimized that this comes into play.


At this point, I'd like to better differentiate the ARM package arches..  I 
don't care so much about the thumb enabled or not.. but the other tune settings 
are things I do care about.  I started to change that for the last update and 
decided it was a rat-hole I was not willing to go down at this point.  At some 
point in the future, I will look at, and document the differences in the tunings 
according to GCC configurations -- to get a good idea of what is and isn't 
producing the same binaries based on various arch and tune settings.


--Mark


p.



___
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

Re: [OE-core] [PATCH 0/1] hello-mod: Remove hello-mod example external kernel module recipe


On 04/09/2012 10:53 AM, Darren Hart wrote:

The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:

   runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 01:12:15 
+0100)

are available in the git repository at:
   git://git.yoctoproject.org/user-contrib/dvhart/oe-core hello-mod
   
http://git.yoctoproject.org/cgit.cgi/user-contrib/dvhart/oe-core/log/?h=hello-mod

Darren Hart (1):
   hello-mod: Remove hello-mod example external kernel module recipe

  meta/recipes-kernel/hello-mod/files/COPYING|  340 
  meta/recipes-kernel/hello-mod/files/Makefile   |   14 -
  meta/recipes-kernel/hello-mod/files/hello.c|   33 ---
  meta/recipes-kernel/hello-mod/hello-mod_0.1.bb |   15 -
  4 files changed, 0 insertions(+), 402 deletions(-)
  delete mode 100644 meta/recipes-kernel/hello-mod/files/COPYING
  delete mode 100644 meta/recipes-kernel/hello-mod/files/Makefile
  delete mode 100644 meta/recipes-kernel/hello-mod/files/hello.c
  delete mode 100644 meta/recipes-kernel/hello-mod/hello-mod_0.1.bb



Can you do this as a move (git mv) instead of as a delete and re-create? 
 meta-skeleton is part of OE-Core if I have my git foo correct.


Thanks

Sau!

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

Re: [OE-core] [PATCH 0/1] hello-mod: Remove hello-mod example external kernel module recipe



On 04/09/2012 03:14 PM, Saul Wold wrote:
 On 04/09/2012 10:53 AM, Darren Hart wrote:
 The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:

runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 
 01:12:15 +0100)

 are available in the git repository at:
git://git.yoctoproject.org/user-contrib/dvhart/oe-core hello-mod

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

 Darren Hart (1):
hello-mod: Remove hello-mod example external kernel module recipe

   meta/recipes-kernel/hello-mod/files/COPYING|  340 
 
   meta/recipes-kernel/hello-mod/files/Makefile   |   14 -
   meta/recipes-kernel/hello-mod/files/hello.c|   33 ---
   meta/recipes-kernel/hello-mod/hello-mod_0.1.bb |   15 -
   4 files changed, 0 insertions(+), 402 deletions(-)
   delete mode 100644 meta/recipes-kernel/hello-mod/files/COPYING
   delete mode 100644 meta/recipes-kernel/hello-mod/files/Makefile
   delete mode 100644 meta/recipes-kernel/hello-mod/files/hello.c
   delete mode 100644 meta/recipes-kernel/hello-mod/hello-mod_0.1.bb

 
 Can you do this as a move (git mv) instead of as a delete and re-create? 
   meta-skeleton is part of OE-Core if I have my git foo correct.


bwahaha. facepalm. for some reason I thought it was a poky thing and
didn't even look. duh. will resend.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - 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 3/7] conf/machine/include: Cleanup MIPS tunings to match README

2012-04-09 Thread Khem Raj

On Mon, Apr 9, 2012 at 1:25 PM, Mark Hatle mark.ha...@windriver.com wrote:

 In order to reconcile the above, the three primary options are see are:

 *) Define only mips or mips32 tune, but not both -- producing mips as the
 package arch.  (But then what do we do in the future about mips1, mips2,
 mips3, mips4, mips32r2?)

 *) Revert the behavior and have two tunes that produce the identical
 filename package with different contents and deal with this in the future.

 *) Keep it as it is now and produce mips and mips32 packages based on the
 specific tunings defined by the user

I think situation is not something I like but

I would think that 1st option is better. Any machine that has been using
mips32 tuning accidently could now use mips tune files and get same PKG_ARCH
and we move mips32 tune into mips tune and hereon say that mips 32bit in OE
defaults to -march=mips32

we could also change compiler defaults to use -march=mips32 to match
the baseconfig and since qemumips has been using mips32 anyway that sort
of is base mips arch.


 We have a bug, I believe we need to fix it.. first or third options fix
 the bug.. the second option retains the bug to be fixed in the future.

 If you have an alternative to the above, I'm interested -- I just really
 don't like the leave the bug option.

 And just to be extra clear, I consider it a defect if we can produce a
 package with the same name for two different tune settings.. (the exception
 being the hell that is ARM and thumb namings.)

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

[OE-core] [PATCH 0/1] hello-mod: Move hello-mod from meta to meta-skeleton

V2: Do this all in oe-core as meta-skeleton is part of oe-core (duh!)

The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:

  runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 01:12:15 
+0100)

are available in the git repository at:
  git://git.yoctoproject.org/user-contrib/dvhart/oe-core hello-mod
  
http://git.yoctoproject.org/cgit.cgi/user-contrib/dvhart/oe-core/log/?h=hello-mod

Darren Hart (1):
  hello-mod: Move hello-mod from meta to meta-skeleton

 .../recipes-kernel/hello-mod/files/COPYING |0
 .../recipes-kernel/hello-mod/files/Makefile|0
 .../recipes-kernel/hello-mod/files/hello.c |0
 .../recipes-kernel/hello-mod/hello-mod_0.1.bb  |0
 4 files changed, 0 insertions(+), 0 deletions(-)
 rename {meta = meta-skeleton}/recipes-kernel/hello-mod/files/COPYING (100%)
 rename {meta = meta-skeleton}/recipes-kernel/hello-mod/files/Makefile (100%)
 rename {meta = meta-skeleton}/recipes-kernel/hello-mod/files/hello.c (100%)
 rename {meta = meta-skeleton}/recipes-kernel/hello-mod/hello-mod_0.1.bb (100%)

-- 
1.7.6.5


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

[OE-core] [PATCH 1/1] hello-mod: Move hello-mod from meta to meta-skeleton

Fixes [YOCTO #1501]

hello-mod is an example kernel module, and does not provide any real
functionality. As such, it would be better placed under meta-skeleton than
meta.

Signed-off-by: Darren Hart dvh...@linux.intel.com
---
 .../recipes-kernel/hello-mod/files/COPYING |0
 .../recipes-kernel/hello-mod/files/Makefile|0
 .../recipes-kernel/hello-mod/files/hello.c |0
 .../recipes-kernel/hello-mod/hello-mod_0.1.bb  |0
 4 files changed, 0 insertions(+), 0 deletions(-)
 rename {meta = meta-skeleton}/recipes-kernel/hello-mod/files/COPYING (100%)
 rename {meta = meta-skeleton}/recipes-kernel/hello-mod/files/Makefile (100%)
 rename {meta = meta-skeleton}/recipes-kernel/hello-mod/files/hello.c (100%)
 rename {meta = meta-skeleton}/recipes-kernel/hello-mod/hello-mod_0.1.bb (100%)

diff --git a/meta/recipes-kernel/hello-mod/files/COPYING 
b/meta-skeleton/recipes-kernel/hello-mod/files/COPYING
similarity index 100%
rename from meta/recipes-kernel/hello-mod/files/COPYING
rename to meta-skeleton/recipes-kernel/hello-mod/files/COPYING
diff --git a/meta/recipes-kernel/hello-mod/files/Makefile 
b/meta-skeleton/recipes-kernel/hello-mod/files/Makefile
similarity index 100%
rename from meta/recipes-kernel/hello-mod/files/Makefile
rename to meta-skeleton/recipes-kernel/hello-mod/files/Makefile
diff --git a/meta/recipes-kernel/hello-mod/files/hello.c 
b/meta-skeleton/recipes-kernel/hello-mod/files/hello.c
similarity index 100%
rename from meta/recipes-kernel/hello-mod/files/hello.c
rename to meta-skeleton/recipes-kernel/hello-mod/files/hello.c
diff --git a/meta/recipes-kernel/hello-mod/hello-mod_0.1.bb 
b/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
similarity index 100%
rename from meta/recipes-kernel/hello-mod/hello-mod_0.1.bb
rename to meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
-- 
1.7.6.5


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

[OE-core] [PATCH 1/2] tclibc-eglibc.inc: make locale packages dependency conditional

2012-04-09 Thread nitin . a . kamble

From: Nitin A Kamble nitin.a.kam...@intel.com

Only add locale package dependencies if the eglibc is configured
with locale support.
  This avoids dependencies issues for distros such as poky-tiny

Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
 meta/conf/distro/include/tclibc-eglibc.inc |   23 ---
 1 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/meta/conf/distro/include/tclibc-eglibc.inc 
b/meta/conf/distro/include/tclibc-eglibc.inc
index 8b8a214..aed82d1 100644
--- a/meta/conf/distro/include/tclibc-eglibc.inc
+++ b/meta/conf/distro/include/tclibc-eglibc.inc
@@ -23,10 +23,19 @@ LIBC_DEPENDENCIES = libsegfault \
 eglibc-dev \
 eglibc-utils \
 eglibc-thread-db \
-eglibc-localedata-i18n \
-eglibc-gconv-ibm850 \
-eglibc-gconv-cp1252 \
-eglibc-gconv-iso8859-1 \
-eglibc-gconv-iso8859-15 \
-locale-base-en-us \
-locale-base-en-gb 
+${@get_libc_locales_dependencies(d)}
+
+LIBC_LOCALE_DEPENDENCIES = \
+   eglibc-localedata-i18n \
+   eglibc-gconv-ibm850 \
+   eglibc-gconv-cp1252 \
+   eglibc-gconv-iso8859-1 \
+   eglibc-gconv-iso8859-15 \
+   locale-base-en-us \
+   locale-base-en-gb
+
+def get_libc_locales_dependencies(d):
+if 'libc-locales' in (d.getVar('DISTRO_FEATURES', True) or '').split() :
+return d.getVar('LIBC_LOCALE_DEPENDENCIES', True) or ''
+else:
+return ''
-- 
1.7.7


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

[OE-core] [PATCH 2/2] poky-tiny.conf: adjust eglibc options for poky-tiny

2012-04-09 Thread nitin . a . kamble

From: Nitin A Kamble nitin.a.kam...@intel.com

Avoid errors for building meta-toolchain for poky-tiny

This Fixes Bug: [YOCTO #2259]

Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
 meta-yocto/conf/distro/poky-tiny.conf |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/meta-yocto/conf/distro/poky-tiny.conf 
b/meta-yocto/conf/distro/poky-tiny.conf
index 395c6fb..58d64ec 100644
--- a/meta-yocto/conf/distro/poky-tiny.conf
+++ b/meta-yocto/conf/distro/poky-tiny.conf
@@ -63,6 +63,12 @@ ASSUME_PROVIDED += pkgconfig$
 # Reconfigure eglibc for a smaller installation
 # Comment out any of the lines below to disable them in the build
 DISTRO_FEATURES_LIBC_TINY = libc-libm libc-crypt
+# for gettext
+DISTRO_FEATURES_LIBC_TINY += libc-posix-clang-wchar
+# for m4
+DISTRO_FEATURES_LIBC_TINY += libc-spawn libc-locale-code
+# for elfutils
+DISTRO_FEATURES_LIBC_TINY += libc-ftraverse
 # Required for who
 DISTRO_FEATURES_LIBC_MINIMAL = libc-utmp libc-getlogin
 DISTRO_FEATURES_LIBC_REGEX = libc-posix-regexp
-- 
1.7.7


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

[OE-core] [PATCH 0/2] Misc bugfixes

2012-04-09 Thread nitin . a . kamble

From: Nitin A Kamble nitin.a.kam...@intel.com

The following changes since commit 190f6d791d51aaa4cfb9f1cf932bc205ff674fb5:

  runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 01:12:47 
+0100)

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

Nitin A Kamble (2):
  tclibc-eglibc.inc: make locale packages dependency conditional
  poky-tiny.conf: adjust eglibc options for poky-tiny

 meta-yocto/conf/distro/poky-tiny.conf  |6 ++
 meta/conf/distro/include/tclibc-eglibc.inc |   23 ---
 2 files changed, 22 insertions(+), 7 deletions(-)

-- 
1.7.7


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

[OE-core] [PATCH 1/1] tune-mips32: Update the default MIPS tuning to be mips32

Previously the default mips tuning was defined as mips1
internally in the compiler.  Revise this and change to mips32.

This eliminates the need for the mips32 specific tunings, which were
not being used anyway.  (They exists and were used, but were not
differentiated by package arch prior to a recent commit.)

Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
 meta/conf/machine/include/mips/arch-mips.inc |   13 +
 meta/conf/machine/include/tune-mips32.inc|   24 +---
 2 files changed, 10 insertions(+), 27 deletions(-)

diff --git a/meta/conf/machine/include/mips/arch-mips.inc 
b/meta/conf/machine/include/mips/arch-mips.inc
index 8758ecd..c7768a1 100644
--- a/meta/conf/machine/include/mips/arch-mips.inc
+++ b/meta/conf/machine/include/mips/arch-mips.inc
@@ -28,6 +28,11 @@ TUNEVALID[fpu-hard] = Use hardware FPU
 TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, fpu-hard, 
-mhard-float, -msoft-float, d)}
 TARGET_FPU = ${@bb.utils.contains(TUNE_FEATURES, fpu-hard, , soft, 
d)}
 
+# mips32 is the default o32 tuning
+TUNEVALID[mips32] = Enable mips32 specific processor optimizations
+TUNE_CONFLICTS[mips32] = n64 n32
+TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, mips32, 
-march=mips32, , d)}
+
 # Package naming
 MIPSPKGSFX_ENDIAN = ${@bb.utils.contains(TUNE_FEATURES, bigendian, , 
el, d)}
 MIPSPKGSFX_BYTE = ${@bb.utils.contains(TUNE_FEATURES, n64 , 64, , d)}
@@ -40,7 +45,7 @@ TUNE_PKGARCH = 
${MIPSPKGSFX_VARIANT_tune-${DEFAULTTUNE}}${MIPSPKGSFX_FPU}${MIPS
 
 # Base tunes
 AVAILTUNES += mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf 
mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf
-TUNE_FEATURES_tune-mips = o32 bigendian fpu-hard
+TUNE_FEATURES_tune-mips = mips32 o32 bigendian fpu-hard
 BASE_LIB_tune-mips = lib
 MIPSPKGSFX_VARIANT_tune-mips = ${TUNE_ARCH}
 PACKAGE_EXTRA_ARCHS_tune-mips = mips
@@ -55,7 +60,7 @@ BASE_LIB_tune-mips64 = lib64
 MIPSPKGSFX_VARIANT_tune-mips64 = ${TUNE_ARCH}
 PACKAGE_EXTRA_ARCHS_tune-mips64 = mips64
 
-TUNE_FEATURES_tune-mipsel = o32 fpu-hard
+TUNE_FEATURES_tune-mipsel = mips32 o32 fpu-hard
 BASE_LIB_tune-mipsel = lib
 MIPSPKGSFX_VARIANT_tune-mipsel = ${TUNE_ARCH}
 PACKAGE_EXTRA_ARCHS_tune-mipsel = mipsel
@@ -70,7 +75,7 @@ BASE_LIB_tune-mips64el = lib64
 MIPSPKGSFX_VARIANT_tune-mips64el = ${TUNE_ARCH}
 PACKAGE_EXTRA_ARCHS_tune-mips64el = mips64el
 
-TUNE_FEATURES_tune-mips-nf = o32 bigendian
+TUNE_FEATURES_tune-mips-nf = mips32 o32 bigendian
 BASE_LIB_tune-mips-nf = lib
 MIPSPKGSFX_VARIANT_tune-mips-nf = ${TUNE_ARCH}
 PACKAGE_EXTRA_ARCHS_tune-mips-nf = mips-nf
@@ -85,7 +90,7 @@ BASE_LIB_tune-mips64-nf = lib64
 MIPSPKGSFX_VARIANT_tune-mips64-nf = ${TUNE_ARCH}
 PACKAGE_EXTRA_ARCHS_tune-mips64-nf = mips64-nf
 
-TUNE_FEATURES_tune-mipsel-nf = o32
+TUNE_FEATURES_tune-mipsel-nf = mips32 o32
 BASE_LIB_tune-mipsel-nf = lib
 MIPSPKGSFX_VARIANT_tune-mipsel-nf = ${TUNE_ARCH}
 PACKAGE_EXTRA_ARCHS_tune-mipsel-nf = mipsel-nf
diff --git a/meta/conf/machine/include/tune-mips32.inc 
b/meta/conf/machine/include/tune-mips32.inc
index 93ed5ee..f7bad90 100644
--- a/meta/conf/machine/include/tune-mips32.inc
+++ b/meta/conf/machine/include/tune-mips32.inc
@@ -1,25 +1,3 @@
-DEFAULTTUNE ?= mips32
+DEFAULTTUNE ?= mips
 
 require conf/machine/include/mips/arch-mips.inc
-
-TUNEVALID[mips32] = Enable mips32 specific processor optimizations
-TUNE_CONFLICTS[mips32] = n64 n32
-TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, mips32, 
-march=mips32, , d)}
-
-AVAILTUNES += mips32 mips32el mips32-nf mips32el-nf
-
-TUNE_FEATURES_tune-mips32 = ${TUNE_FEATURES_tune-mips} mips32
-MIPSPKGSFX_VARIANT_tune-mips32 = mips32
-PACKAGE_EXTRA_ARCHS_tune-mips32 = mips mips32
-
-TUNE_FEATURES_tune-mips32el = ${TUNE_FEATURES_tune-mipsel} mips32
-MIPSPKGSFX_VARIANT_tune-mips32el = mips32el
-PACKAGE_EXTRA_ARCHS_tune-mips32el = mipsel mips32el
-
-TUNE_FEATURES_tune-mips32-nf = ${TUNE_FEATURES_tune-mips-nf} mips32
-MIPSPKGSFX_VARIANT_tune-mips32-nf = mips32
-PACKAGE_EXTRA_ARCHS_tune-mips32-nf = mips-nf mips32-nf
-
-TUNE_FEATURES_tune-mips32el-nf = ${TUNE_FEATURES_tune-mipsel-nf} mips32
-MIPSPKGSFX_VARIANT_tune-mips32el-nf = mips32el
-PACKAGE_EXTRA_ARCHS_tune-mips32el-nf = mipsel-nf mips32el-nf
-- 
1.7.1


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

[OE-core] [PATCH 0/1] MIPS/MIPS32 tune - MIPS

The following is in reference to the recent discussion about the mips32
-package- arch changing from mips to mips32.  One of the potential options
was to get rid of the previous mips and replace it with the mips32
definition standard.  This patch does just that.

Working with Khem, we have moved the default mips (32-bit) tune to be
-march=mips32 based, and produce package with the package arch of mips.

The side effect of this work is that the prior 'mips' tune was actually
mips1.  I don't believe that was really desired by anyone, but it is a
change.  Also there is no longer a mips32 tune, just an include file
that automatically inherits and chooses the mips tune.

The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:

  runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 01:12:15 
+0100)

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

Mark Hatle (1):
  tune-mips32: Update the default MIPS tuning to be mips32

 meta/conf/machine/include/mips/arch-mips.inc |   13 +
 meta/conf/machine/include/tune-mips32.inc|   24 +---
 2 files changed, 10 insertions(+), 27 deletions(-)


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

Re: [OE-core] [PATCH 0/1] MIPS/MIPS32 tune - MIPS

2012-04-09 Thread Andreas Oberritter

On 10.04.2012 01:31, Mark Hatle wrote:
 The following is in reference to the recent discussion about the mips32
 -package- arch changing from mips to mips32.  One of the potential options
 was to get rid of the previous mips and replace it with the mips32
 definition standard.  This patch does just that.
 
 Working with Khem, we have moved the default mips (32-bit) tune to be
 -march=mips32 based, and produce package with the package arch of mips.
 
 The side effect of this work is that the prior 'mips' tune was actually
 mips1.  I don't believe that was really desired by anyone, but it is a
 change.  Also there is no longer a mips32 tune, just an include file
 that automatically inherits and chooses the mips tune.

There's no backwards compatibility, but I'm fine with the new options.
The mips tune already gets selected by default in arch-mips.inc, so
you can remove it from tune-mips32.inc. Actually I'd prefer removing
tune-mips32.inc completely, so people will notice the
backwards-incompatible change.

Regards,
Andreas

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

Re: [OE-core] [PATCH 0/1] MIPS/MIPS32 tune - MIPS


On 4/9/12 7:14 PM, Andreas Oberritter wrote:

On 10.04.2012 01:31, Mark Hatle wrote:

The following is in reference to the recent discussion about the mips32
-package- arch changing from mips to mips32.  One of the potential options
was to get rid of the previous mips and replace it with the mips32
definition standard.  This patch does just that.

Working with Khem, we have moved the default mips (32-bit) tune to be
-march=mips32 based, and produce package with the package arch of mips.

The side effect of this work is that the prior 'mips' tune was actually
mips1.  I don't believe that was really desired by anyone, but it is a
change.  Also there is no longer a mips32 tune, just an include file
that automatically inherits and chooses the mips tune.


There's no backwards compatibility, but I'm fine with the new options.
The mips tune already gets selected by default in arch-mips.inc, so
you can remove it from tune-mips32.inc. Actually I'd prefer removing
tune-mips32.inc completely, so people will notice the
backwards-incompatible change.


This is backwards compatible if someone was previously including the mips32 
tune.  It only breaks if someone was setting the default tune to mips32 or 
mips32el manually.


If that is a concern, then adding a:

TUNE_FEATURES_tune-mips32 = ${TUNE_FEATURES_tune-mips}
MIPSPKGSFX_VARIANT_tune-mips32 = ${MIPSPKGSFX_VARIANT_tune-mips}
PACKAGE_EXTRA_ARCHS_tune-mips32 = ${PACKAGE_EXTRA_ARCHS_tune-mips}

(and the same for mips32el).  That would ensure that they remain the same, and 
that the package arch of mips can't deviate.


--Mark


Regards,
Andreas



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

Re: [OE-core] [PATCH 0/1] meta-toolchain: runqemu falied on FC16/Opensuse12.1 x86_64




On 04/09/2012 08:21 PM, Robert Yang wrote:



On 04/09/2012 06:36 PM, Lu, Lianhao wrote:


Robert Yang wrote on 2012-04-09:

Test info:
* Have tested on:
* Fedora 16 x86_64
* Opensuse 12.1 x86_64


Robert,
Hongna just found a qemu launch error on openSuse x86_64 using the 2.15
eglibc-nativesdk, something about the SDL initialization error. Did your
platform work well?





Here is the update information from Hongna:

I have finished the test on opensuse x86-64, both qemuarm and qemux86 do
cross debug pass using 2.15 toolchain.

// Robert


Maybe he just used ssh without -X or -Y ? There would be an SDL
initialization error when ssh without -X or -Y. It worked well for me.

// Robert


* Ubuntu 10.04
* The testing commands are:
$ bitbake core-image-sato meta-toolchain meta-toolchain-sdk

And untar the sdk, then runqemu from the sdk to start the target.
// Robert

The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:

runqemu-internal: Add console=tty for qemuppc and NFS (2012-04-06 01:12:15
+0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib robert/tc
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/tc
Robert Yang (1):
meta-toolchain: runqemu falied on FC16/Opensuse12.1 x86_64
meta/conf/distro/include/tcmode-default.inc | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

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


Best Regards,
Lianhao



___
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



___
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] connman: ensure ofono package is generated.

2012-04-09 Thread Lu, Lianhao


Saul Wold wrote on 2012-04-10:
 On 04/05/2012 11:20 PM, Lianhao Lu wrote:
 Make sure ofono package is generated when buidling connman, because
 dynamic package connman-plugin-ofono has a RDEPENDS on ofono.
 
 Since this is for a plugin, can the connman-plugin-ofono be generated in
 a separate package (or possibly even a separate recipe that depends on
 ofono, instead of making connman depend on ofono, I am not sure the
 solution below is correct either.

connman-plugin-ofono is already generated in a separate dynamic package, just 
like other dynamic connman-plugin-bluez4. I think we'd better build the 
connman-plugin-ofono based on the value distro_features, just like we did for 
connman-plugin-bluez4 in commit 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit?id=1288313411f8db7628e9ec4c04f2ad7f830e994d.
 I'll remake the patch. 

-Lianhao 

 Sau!
 
 Signed-off-by: Lianhao Lulianhao...@intel.com
 ---
   meta/recipes-connectivity/connman/connman.inc |2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
 diff --git a/meta/recipes-connectivity/connman/connman.inc 
 b/meta/recipes-connectivity/connman/connman.inc
 index 1a6dd1b..3ed5667 100644
 --- a/meta/recipes-connectivity/connman/connman.inc
 +++ b/meta/recipes-connectivity/connman/connman.inc
 @@ -39,6 +39,8 @@ EXTRA_OECONF += \
   --disable-ntpd \
   
 +do_package[depends] = ${MLPREFIX}ofono:do_package
 +
   INITSCRIPT_NAME = connman
   INITSCRIPT_PARAMS = start 05 5 2 3 . stop 22 0 1 6 .

Best Regards,
Lianhao



___
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] connman: optionally build ofono plugin

Only build connman ofono plugin when 3g distro feature is enabled.

The following changes since commit 1a82989345fb98becb487d270fd93a5e6dffeb47:
  Saul Wold (1):
runqemu-internal: Add console=tty for qemuppc and NFS

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib llu/multilib
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=llu/multilib

Lianhao Lu (1):
  connman: optionally build ofono plugin.

 meta/recipes-connectivity/connman/connman.inc |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


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

[OE-core] [PATCH V2 1/1] connman: optionally build ofono plugin.

Only build ofono plugin when 3g feature is enabled. Also add dependency
to ofono when ofono plugin is being built.

This is part of the buf fixing [YOCTO #2216].

Signed-off-by: Lianhao Lu lianhao...@intel.com
---
 meta/recipes-connectivity/connman/connman.inc |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-connectivity/connman/connman.inc 
b/meta/recipes-connectivity/connman/connman.inc
index 1a6dd1b..c3827f1 100644
--- a/meta/recipes-connectivity/connman/connman.inc
+++ b/meta/recipes-connectivity/connman/connman.inc
@@ -17,6 +17,7 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
 DEPENDS  = dbus glib-2.0 ppp iptables gnutls \
 ${@base_contains('DISTRO_FEATURES', 'bluetooth','bluez4', '', d)} \
 ${@base_contains('DISTRO_FEATURES', 'wifi','wpa-supplicant', '', 
d)} \
+${@base_contains('DISTRO_FEATURES', '3g','ofono', '', d)} \
 
 
 EXTRA_OECONF += \
@@ -30,7 +31,7 @@ EXTRA_OECONF += \
 ${@base_contains('DISTRO_FEATURES', 'wifi','--enable-wifi', 
'--disable-wifi', d)} \
 ${@base_contains('DISTRO_FEATURES', 'bluetooth','--enable-bluetooth', 
'--disable-bluetooth', d)} \
 --enable-dnsproxy \
---enable-ofono \
+${@base_contains('DISTRO_FEATURES', '3g','--enable-ofono', 
'--disable-ofono', d)} \
 --enable-tools \
 --enable-test \
 --disable-polkit \
-- 
1.7.0.4


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

Re: [OE-core] [PATCH 0/1] meta-toolchain: runqemu falied on FC16/Opensuse12.1 x86_64

2012-04-09 Thread Lu, Lianhao


Robert Yang wrote on 2012-04-10:
 
 
 On 04/09/2012 08:21 PM, Robert Yang wrote:
 
 
 On 04/09/2012 06:36 PM, Lu, Lianhao wrote:
 
 Robert Yang wrote on 2012-04-09:
 Test info:
 * Have tested on:
 * Fedora 16 x86_64
 * Opensuse 12.1 x86_64
 
 Robert,
 Hongna just found a qemu launch error on openSuse x86_64 using the 2.15
 eglibc-nativesdk, something about the SDL initialization error. Did your
 platform work well?
 
 
 
 Here is the update information from Hongna:
 
 I have finished the test on opensuse x86-64, both qemuarm and qemux86 do
 cross debug pass using 2.15 toolchain.
 
 // Robert
 
 Maybe he just used ssh without -X or -Y ? There would be an SDL
 initialization error when ssh without -X or -Y. It worked well for me.
 
 // Robert

It just popped into my mind that when ssh with X forwarding, does the SDL 
initialization happen on the Xserver, which is NOT openSuse x86-64, while the 
xclient(qemu) is running on openSue? Could you try launching the qemu directly 
on the openSuse? Thanks!

-Lianhao

 
 * Ubuntu 10.04
 * The testing commands are:
 $ bitbake core-image-sato meta-toolchain meta-toolchain-sdk
 
 And untar the sdk, then runqemu from the sdk to start the target.
 // Robert
 

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

Re: [OE-core] [PATCH 0/1] meta-toolchain: runqemu falied on FC16/Opensuse12.1 x86_64