date:20141030

systemd needs this file to be there because one of its configuration file
in pam.d, systemd-user, requires it. Otherwise, we would have errors like
below.

systemd: PAM _pam_load_conf_file: unable to open /etc/pam.d/system-auth

Signed-off-by: Chen Qi qi.c...@windriver.com
---
 meta/recipes-extended/pam/libpam/pam.d/system-auth | 12 
 meta/recipes-extended/pam/libpam_1.1.6.bb  |  1 +
 2 files changed, 13 insertions(+)
 create mode 100644 meta/recipes-extended/pam/libpam/pam.d/system-auth

diff --git a/meta/recipes-extended/pam/libpam/pam.d/system-auth 
b/meta/recipes-extended/pam/libpam/pam.d/system-auth
new file mode 100644
index 000..ffb08ab
--- /dev/null
+++ b/meta/recipes-extended/pam/libpam/pam.d/system-auth
@@ -0,0 +1,12 @@
+# This file comes from systemd.
+
+auth sufficient pam_unix.so nullok try_first_pass
+
+account  required   pam_nologin.so
+account  sufficient pam_unix.so
+
+password sufficient pam_unix.so nullok sha512 shadow try_first_pass try_authtok
+
+-session optional   pam_loginuid.so
+-session optional   pam_systemd.so
+session  sufficient pam_unix.so
diff --git a/meta/recipes-extended/pam/libpam_1.1.6.bb 
b/meta/recipes-extended/pam/libpam_1.1.6.bb
index a84e51e..0910b6f 100644
--- a/meta/recipes-extended/pam/libpam_1.1.6.bb
+++ b/meta/recipes-extended/pam/libpam_1.1.6.bb
@@ -17,6 +17,7 @@ SRC_URI = 
http://linux-pam.org/library/Linux-PAM-${PV}.tar.bz2 \
file://pam.d/common-session \
file://pam.d/common-session-noninteractive \
file://pam.d/other \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'file://pam.d/system-auth', '', d)} \
file://libpam-xtests.patch \
file://destdirfix.patch \
file://fixsepbuild.patch \
-- 
1.9.1

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

[OE-core] [PATCH 0/1] libpam: add system-auth in case of systemd

The following changes since commit 4143f3b0ce0d0c52f5b0babc1bb16ac0ac9610eb:

  nativesdk-cmake: Adjust toolchain paths dynamically (2014-10-24 21:59:34 
+0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib ChenQi/libpam-systemd
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/libpam-systemd

Chen Qi (1):
  libpam: add system-auth in case of systemd

 meta/recipes-extended/pam/libpam/pam.d/system-auth | 12 
 meta/recipes-extended/pam/libpam_1.1.6.bb  |  1 +
 2 files changed, 13 insertions(+)
 create mode 100644 meta/recipes-extended/pam/libpam/pam.d/system-auth

-- 
1.9.1

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

Re: [OE-core] [PATCH 0/6] some wic bugfixes

2014-10-30 Thread Maciej Borzecki

On Wednesday 29 of October 2014 17:04:20 Tom Zanussi wrote:
 This patchset fixes a couple serious wic bugs:
 
 [YOCTO #6863] - Wic fails to create a working image for a large file system
 [YOCTO #6290] - Update WIC for gummiboot
 
 I generated core-image-sdk images for each of the wic image types and
 was able to fsck/mount the resulting filesystems.
 
 These should be applied to the next dizzy point release.
 
 The following changes since commit cf82c6756bad8f7a5edc92ce513e02816b88efb3:
 
   bitbake: prserv: don't wait until exit to sync (2014-10-28 15:00:39 +)
 
 are available in the git repository at:
 
   git://git.yoctoproject.org/poky-contrib.git tzanussi/wic-bugfixes-v1
   http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/wic-bugfixes-v1
 
 Tom Zanussi (6):
   wic: Don't allow mkfs to fail silently in partition command
   wic: Use overhead factor when creating partitions from rootfs
 directories
   wic: Update the help text to include -D (--debug)
   Revert wic: set bootimg_dir when using image-name artifacts
   wic: Remove special-case bootimg_dir
   wic: Update bootimg-partition to use bootimg_dir
 
  scripts/lib/image/engine.py| 42
 +- scripts/lib/image/help.py  |
 23  scripts/lib/wic/imager/direct.py   |  5 +--
  .../lib/wic/kickstart/custom_commands/partition.py | 24 +
  scripts/lib/wic/plugins/imager/direct_plugin.py| 20 +--
  scripts/lib/wic/plugins/source/bootimg-efi.py  |  5 ++-
  .../lib/wic/plugins/source/bootimg-partition.py|  9 +++--
  scripts/lib/wic/plugins/source/bootimg-pcbios.py   |  3 +-
  scripts/lib/wic/utils/oe/misc.py   |  1 +
  scripts/wic| 13 +++
  10 files changed, 68 insertions(+), 77 deletions(-)

For the whole series

Acked-by: Maciej Borzecki maciej.borze...@open-rnd.pl

-- 

Maciej Borzęcki 
Senior Software Engineer Open-RnD Sp. z o.o. 
www.open-rnd.pl, Facebook, Twitter 
mobile: +48 telefon, fax: +48 42 657 9079 

Niniejsza wiadomość wraz z załącznikami może zawierać chronione prawem lub 
poufne informacje i została wysłana wyłącznie do wiadomości i użytku osób, do 
których została zaadresowana. Jeśli wiadomość została otrzymana przypadkowo 
zabrania się jej kopiowania lub rozsyłania do osób trzecich. W takim przypadku 
uprasza się o natychmiastowe zniszczenie wiadomości oraz poinformowanie 
nadawcy o zaistniałej sytuacji za pomocą wiadomości zwrotnej. Dziękujemy. 

This message, including any attachments hereto, may contain privileged or 
confidential information and is sent solely for the attention and use of the 
intended addressee(s). If you are not an intended addressee, you may neither 
use this message nor copy or deliver it to anyone. In such case, you should 
immediately destroy this message and kindly notify the sender by reply email. 
Thank you. 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] sysstat: add configuration file in tmpfiles.d

The following changes since commit 4143f3b0ce0d0c52f5b0babc1bb16ac0ac9610eb:

  nativesdk-cmake: Adjust toolchain paths dynamically (2014-10-24 21:59:34 
+0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib ChenQi/sysstat-tmpfiles
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/sysstat-tmpfiles

Chen Qi (1):
  sysstat: add configuration file in tmpfiles.d

 meta/recipes-extended/sysstat/sysstat.inc | 6 ++
 1 file changed, 6 insertions(+)

-- 
1.9.1

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

[OE-core] [PATCH 1/1] sysstat: add configuration file in tmpfiles.d

In sysvinit, we create /var/log/sa via populate-volatiles.sh script and
/etc/default/volatile/99_sysstat configuration file.

In systemd, we need to create a corresponding configuration file under
/etc/tmpfiles.d in order to create /var/log/sa.

Signed-off-by: Chen Qi qi.c...@windriver.com
---
 meta/recipes-extended/sysstat/sysstat.inc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-extended/sysstat/sysstat.inc 
b/meta/recipes-extended/sysstat/sysstat.inc
index 09a5d28..5e80d07 100644
--- a/meta/recipes-extended/sysstat/sysstat.inc
+++ b/meta/recipes-extended/sysstat/sysstat.inc
@@ -25,6 +25,12 @@ do_install() {
rm -rf ${D}/var
install -d ${D}/etc/default/volatiles
install -m 0644 ${WORKDIR}/99_sysstat ${D}/etc/default/volatiles
+
+   if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', 
d)}; then
+   install -d ${D}${sysconfdir}/tmpfiles.d
+   echo d ${localstatedir}/log/sa - - - - \
+${D}${sysconfdir}/tmpfiles.d/sysstat.conf
+   fi
 }
 
 pkg_postinst_${PN} () {
-- 
1.9.1

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

[OE-core] [RFCv2 2/2] scripts: modify environment to use python2 instead

2014-10-30 Thread Martin Hundebøll

In distributions where /usr/bin/python points at python3, the check for
python version fails even when python2 is available at /usr/bin/python2.

The usual way to circumvent this is to manually create a fake
environment, where python is a symlink to python2. Since openembedded
already sets up a semi fake environment, we might as well add a python
symlink to this.

This patch adds a check in oe-buildenv-internal, that runs through a
list of possible python names, and check for their existance and
version. Once a compatible version is found, a symlink is created in
./bitbake/bin/python.

If no compatible version is found, an error is printed and
oe-init-build-env fails.

Signed-off-by: Martin Hundebøll mar...@hundeboll.net
---
 scripts/oe-buildenv-internal | 30 ++---
 scripts/python-env.sh| 46 
 2 files changed, 56 insertions(+), 20 deletions(-)
 create mode 100755 scripts/python-env.sh

diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
index bba6f8f..3841ccb 100755
--- a/scripts/oe-buildenv-internal
+++ b/scripts/oe-buildenv-internal
@@ -29,26 +29,6 @@ if [ ! -z $OECORE_SDK_VERSION ]; then
 return 1
 fi
 
-# Make sure we're not using python v3.x. This check can't go into
-# sanity.bbclass because bitbake's source code doesn't even pass
-# parsing stage when used with python v3, so we catch it here so we
-# can offer a meaningful error message.
-py_v3_check=`/usr/bin/env python --version 21 | grep Python 3`
-if [ $py_v3_check !=  ]; then
-   echo 2 Bitbake is not compatible with python v3
-   echo 2 Please set up python v2 as your default python interpreter
-   return 1
-fi
-
-# Similarly, we now have code that doesn't parse correctly with older
-# versions of Python, and rather than fixing that and being eternally
-# vigilant for any other new feature use, just check the version here.
-py_v26_check=`python -c 'import sys; print sys.version_info = (2,7,3)'`
-if [ $py_v26_check != True ]; then
-   echo 2 BitBake requires Python 2.7.3 or later
-   return 1
-fi
-
 if [ x$BDIR = x ]; then
 if [ x$1 = x ]; then
 BDIR=build
@@ -94,6 +74,16 @@ if ! (test -d $BITBAKEDIR); then
 return 1
 fi
 
+# Make sure we're not using python v3.x. This check can't go into
+# sanity.bbclass because bitbake's source code doesn't even pass
+# parsing stage when used with python v3, so we catch it here so we
+# can offer a meaningful error message.
+source ${OEROOT}/scripts/python-env.sh
+if ! env_set_python; then
+echo env_set_python failed
+return 1
+fi
+
 # Make sure our paths are at the beginning of $PATH
 NEWPATHS=${OEROOT}/scripts:$BITBAKEDIR/bin:
 PATH=$NEWPATHS$(echo $PATH | sed -e s|:$NEWPATHS|:|g -e s|^$NEWPATHS||)
diff --git a/scripts/python-env.sh b/scripts/python-env.sh
new file mode 100755
index 000..d88587e
--- /dev/null
+++ b/scripts/python-env.sh
@@ -0,0 +1,46 @@
+function env_set_python() {
+# List of possible python executables to check in environment
+py_names=(python python2 python2.7)
+
+# Minimum supported python version
+py_minver=(2,7,3)
+
+# Maximum supported python version
+py_maxver=(2,9,9)
+
+# For each python name listed abobe
+for py_name in ${py_names[@]}; do
+# Get the full path from the shell environment
+py=$(command -v $py_name)
+
+# Skip this name if it doesn't exist
+if [ -z $py ]; then
+continue
+fi
+
+# Skip this name if version is too old
+minver=$($py_name -c import sys; print(sys.version_info = 
$py_minver))
+if [ $minver != True ]; then
+continue
+fi
+
+# Skip this name if version is too new
+maxver=$($py_name -c import sys; print(sys.version_info = 
$py_maxver))
+if [ $maxver != True ]; then
+continue
+fi
+
+# Found a compatible python name. Install it in the environment
+echo Setting $py as python env
+ln -sf $py $BITBAKEDIR/bin/python
+
+# Return with success
+return 0
+done
+
+# None of the listed python name were usable. Complain and exit with error
+echo 2 No compatible python interpreter was found.
+echo 2 Please install python v2 and make sure it is available in your 
$$PATH
+
+return 1
+}
-- 
2.1.2

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

[OE-core] [RFCv2 0/2] Support systems with python3 as default

2014-10-30 Thread Martin Hundebøll

Since more distributions plan to move to python3, steps should be taken
to support such systems.

My previous attemt was pretty intrusive and changed all occurrences of
/usr/bin/{env ,}python to /usr/bin/env python2. Such apporach might break
on systems with no python2 alias in env, so here is a different approach.

Paul Braker suggested to auto-detect the available python version and
setup a fake environment, so I have given it a shot. This is quite simple
and much less intrusive than my first attempt. It utilizes the existing
bitbake env and simply tests a few different python names and, if a
compatible version is found, creates a symlink in ./bitbate/bin/python

Comments/suggestions are welcome!

Martin Hundebøll (2):
  scripts: use '/usr/bin/env' in shebangs with python
  scripts: modify environment to use python2 instead

 bitbake/lib/progressbar.py |  2 +-
 scripts/lib/wic/conf.py|  2 +-
 scripts/lib/wic/creator.py |  2 +-
 scripts/lib/wic/imager/baseimager.py   |  2 +-
 scripts/lib/wic/kickstart/__init__.py  |  2 +-
 .../lib/wic/kickstart/custom_commands/micboot.py   |  2 +-
 .../wic/kickstart/custom_commands/micpartition.py  |  2 +-
 scripts/lib/wic/msger.py   |  2 +-
 scripts/lib/wic/plugin.py  |  2 +-
 scripts/lib/wic/pluginbase.py  |  2 +-
 scripts/lib/wic/utils/errors.py|  2 +-
 scripts/lib/wic/utils/fs_related.py|  2 +-
 scripts/lib/wic/utils/misc.py  |  2 +-
 scripts/lib/wic/utils/partitionedfs.py |  2 +-
 scripts/lib/wic/utils/runner.py|  2 +-
 scripts/oe-buildenv-internal   | 30 +-
 scripts/pybootchartgui/pybootchartgui.py   |  2 +-
 scripts/python-env.sh  | 46 ++
 18 files changed, 72 insertions(+), 36 deletions(-)
 create mode 100755 scripts/python-env.sh

-- 
2.1.2

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

[OE-core] [RFCv2 1/2] scripts: use '/usr/bin/env' in shebangs with python

2014-10-30 Thread Martin Hundebøll

To support yocto on systems with python3 as default version, scripts
should use /usr/bin/env python in the shebang, as this allows the use of
a fake env to mimic python2 as default version.

This patch simply replaces occurrences of #!/usr/bin/python with
 #!/usr/bin/env python and was done with this oneliner:

 git grep -lE '^#!/usr/bin/python' | xargs \
 sed -i 's|/usr/bin/python|/usr/bin/env python|'

Signed-off-by: Martin Hundebøll mar...@hundeboll.net
---
 bitbake/lib/progressbar.py| 2 +-
 scripts/lib/wic/conf.py   | 2 +-
 scripts/lib/wic/creator.py| 2 +-
 scripts/lib/wic/imager/baseimager.py  | 2 +-
 scripts/lib/wic/kickstart/__init__.py | 2 +-
 scripts/lib/wic/kickstart/custom_commands/micboot.py  | 2 +-
 scripts/lib/wic/kickstart/custom_commands/micpartition.py | 2 +-
 scripts/lib/wic/msger.py  | 2 +-
 scripts/lib/wic/plugin.py | 2 +-
 scripts/lib/wic/pluginbase.py | 2 +-
 scripts/lib/wic/utils/errors.py   | 2 +-
 scripts/lib/wic/utils/fs_related.py   | 2 +-
 scripts/lib/wic/utils/misc.py | 2 +-
 scripts/lib/wic/utils/partitionedfs.py| 2 +-
 scripts/lib/wic/utils/runner.py   | 2 +-
 scripts/pybootchartgui/pybootchartgui.py  | 2 +-
 16 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/bitbake/lib/progressbar.py b/bitbake/lib/progressbar.py
index b668647..114cdc1 100644
--- a/bitbake/lib/progressbar.py
+++ b/bitbake/lib/progressbar.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
 # -*- coding: iso-8859-1 -*-
 #
 # progressbar  - Text progressbar library for python.
diff --git a/scripts/lib/wic/conf.py b/scripts/lib/wic/conf.py
index d5419f8..be34355 100644
--- a/scripts/lib/wic/conf.py
+++ b/scripts/lib/wic/conf.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python -tt
+#!/usr/bin/env python -tt
 #
 # Copyright (c) 2011 Intel, Inc.
 #
diff --git a/scripts/lib/wic/creator.py b/scripts/lib/wic/creator.py
index a4b19ac..2219377 100644
--- a/scripts/lib/wic/creator.py
+++ b/scripts/lib/wic/creator.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python -tt
+#!/usr/bin/env python -tt
 #
 # Copyright (c) 2011 Intel, Inc.
 #
diff --git a/scripts/lib/wic/imager/baseimager.py 
b/scripts/lib/wic/imager/baseimager.py
index 5bcd2f7..e830527 100644
--- a/scripts/lib/wic/imager/baseimager.py
+++ b/scripts/lib/wic/imager/baseimager.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python -tt
+#!/usr/bin/env python -tt
 #
 # Copyright (c) 2007 Red Hat  Inc.
 # Copyright (c) 2009, 2010, 2011 Intel, Inc.
diff --git a/scripts/lib/wic/kickstart/__init__.py 
b/scripts/lib/wic/kickstart/__init__.py
index 4f5b778..6000982 100644
--- a/scripts/lib/wic/kickstart/__init__.py
+++ b/scripts/lib/wic/kickstart/__init__.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python -tt
+#!/usr/bin/env python -tt
 #
 # Copyright (c) 2007 Red Hat, Inc.
 # Copyright (c) 2009, 2010, 2011 Intel, Inc.
diff --git a/scripts/lib/wic/kickstart/custom_commands/micboot.py 
b/scripts/lib/wic/kickstart/custom_commands/micboot.py
index 66d1678..d162142 100644
--- a/scripts/lib/wic/kickstart/custom_commands/micboot.py
+++ b/scripts/lib/wic/kickstart/custom_commands/micboot.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python -tt
+#!/usr/bin/env python -tt
 #
 # Copyright (c) 2008, 2009, 2010 Intel, Inc.
 #
diff --git a/scripts/lib/wic/kickstart/custom_commands/micpartition.py 
b/scripts/lib/wic/kickstart/custom_commands/micpartition.py
index 59a87fb..43d04f1 100644
--- a/scripts/lib/wic/kickstart/custom_commands/micpartition.py
+++ b/scripts/lib/wic/kickstart/custom_commands/micpartition.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python -tt
+#!/usr/bin/env python -tt
 #
 # Marko Saukko marko.sau...@cybercom.com
 #
diff --git a/scripts/lib/wic/msger.py b/scripts/lib/wic/msger.py
index 9afc85b..9f557e7 100644
--- a/scripts/lib/wic/msger.py
+++ b/scripts/lib/wic/msger.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python -tt
+#!/usr/bin/env python -tt
 # vim: ai ts=4 sts=4 et sw=4
 #
 # Copyright (c) 2009, 2010, 2011 Intel, Inc.
diff --git a/scripts/lib/wic/plugin.py b/scripts/lib/wic/plugin.py
index 61c5859..41a8017 100644
--- a/scripts/lib/wic/plugin.py
+++ b/scripts/lib/wic/plugin.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python -tt
+#!/usr/bin/env python -tt
 #
 # Copyright (c) 2011 Intel, Inc.
 #
diff --git a/scripts/lib/wic/pluginbase.py b/scripts/lib/wic/pluginbase.py
index b8b3a46..e3de9ba 100644
--- a/scripts/lib/wic/pluginbase.py
+++ b/scripts/lib/wic/pluginbase.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python -tt
+#!/usr/bin/env python -tt
 #
 # Copyright (c) 2011 Intel, Inc.
 #
diff --git a/scripts/lib/wic/utils/errors.py b/scripts/lib/wic/utils/errors.py
index 86e230a..9410311 100644
--- a/scripts/lib/wic/utils/errors.py
+++ b/scripts/lib/wic/utils/errors.py
@@ -1,4 +1,4 @@

Re: [OE-core] [RFC 1/2] scripts: use python2 explicitly in shebangs

2014-10-30 Thread Burton, Ross

On 29 October 2014 13:18, Martin Hundebøll mar...@hundeboll.net wrote:

 I used to use a virtualenv to temporarily set Python 2 as the default
 for the shell in which I ran bitbake commands. That was a while ago
 though, all my current builds are running on Ubuntu 12.04/14.04 server
 instances which I access via ssh from my Arch Linux box.


 Using a compatible distro-install is of course the easiest way to get
 going. Could also work with a virtual machine.


Paul meant the Python tool virtualenv,
http://virtualenv.readthedocs.org/en/latest/virtualenv.html.  This can be
used to create an environment where python on the search path is python
2, on a system where /usr/bin/ is python 3.

I admit that I'm leaning towards thinking that we just say bitbake requires
python to be 2.7+ and if your host distribution uses python 3 by default,
use virtualenv.  The logic being added to the V2 series to generate
symlinks and drop them into the bitbake source tree isn't very elegant.

Obviously using virtualenv means you need to use /usr/bin/env in the
shebangs, so that part of the series is still needed.

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

Re: [OE-core] [PATCH] python-pygtk: Restore pkg-config file

2014-10-30 Thread Burton, Ross

On 28 October 2014 15:05, Gary Thomas g...@mlbassoc.com wrote:

 Some previous version of this recipe was errantly removing the pygtk-2.0.pc
 (pkg-config) file.  This is needed for other packages to be able to build
 against this library.


It's deleting the code generator too.  This entire recipe gives me the
heebie-jeebies...

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

Re: [OE-core] [RFC 1/2] scripts: use python2 explicitly in shebangs

2014-10-30 Thread Mark Hatle


On 10/30/14, 7:39 AM, Burton, Ross wrote:

On 29 October 2014 13:18, Martin Hundebøll mar...@hundeboll.net
mailto:mar...@hundeboll.net wrote:

I used to use a virtualenv to temporarily set Python 2 as the default
for the shell in which I ran bitbake commands. That was a while ago
though, all my current builds are running on Ubuntu 12.04/14.04 server
instances which I access via ssh from my Arch Linux box.


Using a compatible distro-install is of course the easiest way to get going.
Could also work with a virtual machine.


Paul meant the Python tool virtualenv,
http://virtualenv.readthedocs.org/en/latest/virtualenv.html.  This can be used
to create an environment where python on the search path is python 2, on a
system where /usr/bin/ is python 3.

I admit that I'm leaning towards thinking that we just say bitbake requires
python to be 2.7+ and if your host distribution uses python 3 by default, use
virtualenv.  The logic being added to the V2 series to generate symlinks and
drop them into the bitbake source tree isn't very elegant.

Obviously using virtualenv means you need to use /usr/bin/env in the shebangs,
so that part of the series is still needed.


Everything should be using the /usr/bin/env python mechanism.  So that is 
correct.

For Yocto Project's poky, we've already said that python 2.7.3 or newer (and not 
3) is required.  If your system doesn't have this you can download the 
buildtools-tarball 'sdk', install that and source it first.


No need for third party things like virtualenv, we already provide the 
capabilities!

(And since this is oe-core, the components to build the special 
buildtools-tarball SDK are available in the tree.. just build it on a supported 
python 2.7.x machine and re-use it on a python3 machine.)


--Mark


Ross




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

Re: [OE-core] [PATCH 2/4] recipes: add x11 to required DISTRO_FEATURES

2014-10-30 Thread Martin Jansa

On Wed, Aug 06, 2014 at 01:48:31PM +0200, Martin Jansa wrote:
On Mon, Jul 28, 2014 at 02:18:30PM +0100, Richard Purdie wrote:
On Thu, 2014-07-24 at 17:22 +0200, Martin Jansa wrote:
On Thu, Jul 24, 2014 at 02:52:45PM +0100, Burton, Ross wrote:
On 24 July 2014 14:42, Martin Jansa martin.ja...@gmail.com wrote:
+REQUIRED_DISTRO_FEATURES = x11

Now I'm wondering why this is the solution.

If you attempt to build e.g. gnome-desktop explicitly without the x11
distro feature you understandably get an error message, because
gnome-desktop depends on libx11 which sanity checks the distro
features. This seems correct.

Presumably you're problem is that you're running world builds and
they're producing errors on gnome-desktop because they can't satisfy a
dependency on libx11. It seems that bubbling up the
REQUIRED_DISTRO_FEATURES tests isn't the right thing to do here - why
can't SkipPackage be handled specially, so if you do bitbake -k world
and libx11 emits SkipPackage, anything that has unsatisfiable
dependencies because of this is also skipped?

We discussed this many months ago and IIRC the conclusion was that user
should explicitly say that he wants to skip the recipes which depend on
something skipped (so that he is aware of what he is missing).

At that time there wasn't REQUIRED_DISTRO_FEATURES support, so I've
created huge list of PNBLACKLISTs to blacklist everything not available
in our setup - so I can do world builds without ERRORs at the beginning.

REQUIRED_DISTRO_FEATURES seems to me like reasonable compromise, that's
why I've sent this patchset to replace small part of my huge blacklist.

This is the list:
https://github.com/openwebos/meta-webos/blob/master/conf/distro/include/webos-recipe-blacklist-world.inc

If someone has time to improve SkipPackage and we really want to skip
all depending packages, I would be glad to test such patch (because it
allows to easily drop all those blacklists for depends-on-broken
components)

The question here is whether we want a system which calculates what it
thinks is right or that we declare it.

The risk is that if SkipPackage (now known as SkipRecipe) were to
automatically spread, you could in theory break the toolchain, have
nothing buildable and bitbake world would return success.

Effectively the -k option to bitbake already does the SkipPackage
spread idea since bitbake just removes dependencies until it works. If
does that in a fairly verbose way but it does so deliberately so you can
see what is going on.

The alternative is to declare what a given recipe supports and then we
can know whether it should be skipped or not under a given circumstance.

Personally, I'm leaning towards a more declarative approach where we
specify what should and shouldn't be expected to work. I'm open to
discussion on it though...

I agree with more declarative approach.

I don't mind maintaining PNBLACKLIST e.g. for components depending on
something we decided to blacklist ourselves in distro config.

But for components like this, where we really know that they won't work
without X11 in DISTRO_FEATURES, I think bitbake should skip them
automatically (thanks to REQUIRED_DISTRO_FEATURES). It already
automatically skips all recipes in xorg-lib directory, why it shouldn't
skip other recipes living somewhere else?

Can we make some decision now?

Cheers,

Richard

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

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

Re: [OE-core] [PATCH 1/1] libpam: add system-auth in case of systemd

2014-10-30 Thread Koen Kooi


 Op 30 okt. 2014, om 10:08 heeft Chen Qi qi.c...@windriver.com het volgende 
 geschreven:
 
 systemd needs this file to be there because one of its configuration file
 in pam.d, systemd-user, requires it. Otherwise, we would have errors like
 below.
 
systemd: PAM _pam_load_conf_file: unable to open /etc/pam.d/system-auth

Isn't it the same as 'common-auth'? ISTR this is due to debian vs fedora naming 
of PAM stuff. I think it would make more sense to check what systemd actually 
wants and then see if a symlink to common-auth or patching systemd to use 
common-auth is the right answer instead of blindly adding system-auth.

regards,

Koen


 
 Signed-off-by: Chen Qi qi.c...@windriver.com
 ---
 meta/recipes-extended/pam/libpam/pam.d/system-auth | 12 
 meta/recipes-extended/pam/libpam_1.1.6.bb  |  1 +
 2 files changed, 13 insertions(+)
 create mode 100644 meta/recipes-extended/pam/libpam/pam.d/system-auth
 
 diff --git a/meta/recipes-extended/pam/libpam/pam.d/system-auth 
 b/meta/recipes-extended/pam/libpam/pam.d/system-auth
 new file mode 100644
 index 000..ffb08ab
 --- /dev/null
 +++ b/meta/recipes-extended/pam/libpam/pam.d/system-auth
 @@ -0,0 +1,12 @@
 +# This file comes from systemd.
 +
 +auth sufficient pam_unix.so nullok try_first_pass
 +
 +account  required   pam_nologin.so
 +account  sufficient pam_unix.so
 +
 +password sufficient pam_unix.so nullok sha512 shadow try_first_pass 
 try_authtok
 +
 +-session optional   pam_loginuid.so
 +-session optional   pam_systemd.so
 +session  sufficient pam_unix.so
 diff --git a/meta/recipes-extended/pam/libpam_1.1.6.bb 
 b/meta/recipes-extended/pam/libpam_1.1.6.bb
 index a84e51e..0910b6f 100644
 --- a/meta/recipes-extended/pam/libpam_1.1.6.bb
 +++ b/meta/recipes-extended/pam/libpam_1.1.6.bb
 @@ -17,6 +17,7 @@ SRC_URI = 
 http://linux-pam.org/library/Linux-PAM-${PV}.tar.bz2 \
file://pam.d/common-session \
file://pam.d/common-session-noninteractive \
file://pam.d/other \
 +   ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
 'file://pam.d/system-auth', '', d)} \
file://libpam-xtests.patch \
file://destdirfix.patch \
file://fixsepbuild.patch \
 -- 
 1.9.1
 
 -- 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
 

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

Re: [OE-core] [PATCH 2/4] recipes: add x11 to required DISTRO_FEATURES

On Thu, 2014-10-30 at 14:20 +0100, Martin Jansa wrote:
On Wed, Aug 06, 2014 at 01:48:31PM +0200, Martin Jansa wrote:
On Mon, Jul 28, 2014 at 02:18:30PM +0100, Richard Purdie wrote:
On Thu, 2014-07-24 at 17:22 +0200, Martin Jansa wrote:
On Thu, Jul 24, 2014 at 02:52:45PM +0100, Burton, Ross wrote:
On 24 July 2014 14:42, Martin Jansa martin.ja...@gmail.com wrote:
+REQUIRED_DISTRO_FEATURES = x11

Now I'm wondering why this is the solution.

REQUIRED_DISTRO_FEATURES seems to me like reasonable compromise, that's
why I've sent this patchset to replace small part of my huge blacklist.

This is the list:
https://github.com/openwebos/meta-webos/blob/master/conf/distro/include/webos-recipe-blacklist-world.inc

The question here is whether we want a system which calculates what it
thinks is right or that we declare it.

The risk is that if SkipPackage (now known as SkipRecipe) were to
automatically spread, you could in theory break the toolchain, have
nothing buildable and bitbake world would return success.

The alternative is to declare what a given recipe supports and then we
can know whether it should be skipped or not under a given circumstance.

Personally, I'm leaning towards a more declarative approach where we
specify what should and shouldn't be expected to work. I'm open to
discussion on it though...

I agree with more declarative approach.

I don't mind maintaining PNBLACKLIST e.g. for components depending on
something we decided to blacklist ourselves in distro config.

Can we make some decision now?

Well, I think there was an implied outcome of this:

a) We don't want to automatically do things, we want something
declarative

b) We therefore need to go and add REQUIRED_DISTRO_FEATURES = x11 to
some further places.

As such, I'll take patches.

Was that what other people understood?

Cheers,

Richard

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

[OE-core] Weird ALTERNATIVES and staging conflict.

2014-10-30 Thread Mike Looijmans


I have this base script that builds FPGA bitstreams:

https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image.inc

Now you can have multiple recipes using it, and as such, it seemed a good idea 
to add these lines to that recipe:


+ALTERNATIVE_${PN} = fpga.bin bitstreams
+ALTERNATIVE_LINK_NAME[fpga.bin] = ${datadir}/fpga.bin
+ALTERNATIVE_TARGET[fpga.bin] = ${datadir}/fpga.bin
+ALTERNATIVE_LINK_NAME[bitstreams] = ${datadir}/bitstreams
+ALTERNATIVE_TARGET[bitstreams] = ${datadir}/bitstreams


This still resulted in staging conflicts. So I made two simple recipes to 
demonstrate the problem:


SUMMARY = FPGA bitstream
XILINX_VIVADO_VERSION = 2014.1
require recipes-bsp/fpga/fpga-image.inc
LICENSE = internal
LIC_FILES_CHKSUM = 
file://${METATOPIC_BASE}/LICENSE;md5=cf85de037de7ae12cc2d0059741fdbae

SRC_URI = 
S = ${WORKDIR}

do_compile() {
echo ${PN}  fpga.bit
}
do_convert_bitstreams() {
ln -f fpga.bit fpga.bin
}


I save this as fpga-image-fake-one.bb and fpga-image-fake-two.bb

I then create an image that installs them both, and bitbake that image. This 
(still) results in the following error:



ERROR: The recipe fpga-image-fake-two is trying to install files into a shared 
area when those files already exist. Those files and their manifest location are:


/home/mike/zynq_platform/build/tmp-glibc/sysroots/topic-miami-7015/usr/share/fpga.bin
 Matched in manifest-topic-miami-7015-fpga-image-fake-one.populate_sysroot
Please verify which recipe should provide the above files.



But looking at the contents of the fake packages, the fpga.bin has been 
renamed by alternatives (as expected), and the symlink will be created after 
installing, so how come I still get this?




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [OE-core] [PATCH 2/4] recipes: add x11 to required DISTRO_FEATURES

2014-10-30 Thread Koen Kooi

Op 30 okt. 2014, om 14:28 heeft Richard Purdie
richard.pur...@linuxfoundation.org het volgende geschreven:

Now I'm wondering why this is the solution.

REQUIRED_DISTRO_FEATURES seems to me like reasonable compromise, that's
why I've sent this patchset to replace small part of my huge blacklist.

This is the list:
https://github.com/openwebos/meta-webos/blob/master/conf/distro/include/webos-recipe-blacklist-world.inc

The question here is whether we want a system which calculates what it
thinks is right or that we declare it.

The risk is that if SkipPackage (now known as SkipRecipe) were to
automatically spread, you could in theory break the toolchain, have
nothing buildable and bitbake world would return success.

The alternative is to declare what a given recipe supports and then we
can know whether it should be skipped or not under a given circumstance.

Personally, I'm leaning towards a more declarative approach where we
specify what should and shouldn't be expected to work. I'm open to
discussion on it though...

I agree with more declarative approach.

I don't mind maintaining PNBLACKLIST e.g. for components depending on
something we decided to blacklist ourselves in distro config.

Can we make some decision now?

Well, I think there was an implied outcome of this:

a) We don't want to automatically do things, we want something
declarative

b) We therefore need to go and add REQUIRED_DISTRO_FEATURES = x11 to
some further places.

As such, I'll take patches.

Was that what other people understood?

That's how I read it and FWIW, I agree.

regards,

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

Re: [OE-core] [PATCH] python-pygtk: Restore pkg-config file

2014-10-30 Thread Andreas Müller

On Thu, Oct 30, 2014 at 1:57 PM, Burton, Ross ross.bur...@intel.com wrote:

 On 28 October 2014 15:05, Gary Thomas g...@mlbassoc.com wrote:

 Some previous version of this recipe was errantly removing the
 pygtk-2.0.pc
 (pkg-config) file.  This is needed for other packages to be able to build
 against this library.


 It's deleting the code generator too.  This entire recipe gives me the
 heebie-jeebies...

 Ross

I have a similar patch in for very long time [1]. At the time of
creation I ran several tests without suspicious results. The whole
'dirty fix #1' can go.

Andreas

[1] 
https://gitorious.org/schnitzeltony-oe-meta/oe-core/commit/dedf83428f297e9461f5c88c32c78192fa96585e
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] python-pygtk: Restore pkg-config file

2014-10-30 Thread Gary Thomas


On 2014-10-30 09:26, Andreas Müller wrote:

On Thu, Oct 30, 2014 at 1:57 PM, Burton, Ross ross.bur...@intel.com wrote:


On 28 October 2014 15:05, Gary Thomas g...@mlbassoc.com wrote:


Some previous version of this recipe was errantly removing the
pygtk-2.0.pc
(pkg-config) file.  This is needed for other packages to be able to build
against this library.



It's deleting the code generator too.  This entire recipe gives me the
heebie-jeebies...

Ross


I have a similar patch in for very long time [1]. At the time of
creation I ran several tests without suspicious results. The whole
'dirty fix #1' can go.

Andreas

[1] 
https://gitorious.org/schnitzeltony-oe-meta/oe-core/commit/dedf83428f297e9461f5c88c32c78192fa96585e



Wow, since Jan 2013 and no action?

Was this proposed to OE-core (i.e. sent to the list)?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] opkg Status Update

2014-10-30 Thread Trevor Woerner

Hi Paul,

I too wanted to express my thanks to you for this work!

On 10/28/14 19:33, Paul Barker wrote:
 This would be a great time for someone to step up and
 help move things forward to v0.4.0 and beyond.

Is there a roadmap for opkg somewhere?

Best regards,
Trevor
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] python-pygtk: Restore pkg-config file

2014-10-30 Thread Andreas Müller

On Thu, Oct 30, 2014 at 4:39 PM, Gary Thomas g...@mlbassoc.com wrote:

 Wow, since Jan 2013 and no action?

 Was this proposed to OE-core (i.e. sent to the list)?

No - my expiereineces sending patches to oe-core are not the best.
Usually they just cause me efforts and aren't applied anyway..

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

[OE-core] [PATCH] Valgrind: Remove test apps not building with ppc64 and PTEST

2014-10-30 Thread Alexandra Safta

Signed-off-by: Alexandra Safta alexandra.sa...@enea.com
---
 .../valgrind/remove-ppc64-tests-failing-build.patch  | 16 
 meta/recipes-devtools/valgrind/valgrind_3.9.0.bb |  3 ++-
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/valgrind/valgrind/remove-ppc64-tests-failing-build.patch

diff --git 
a/meta/recipes-devtools/valgrind/valgrind/remove-ppc64-tests-failing-build.patch
 
b/meta/recipes-devtools/valgrind/valgrind/remove-ppc64-tests-failing-build.patch
new file mode 100644
index 000..7bf3a21
--- /dev/null
+++ 
b/meta/recipes-devtools/valgrind/valgrind/remove-ppc64-tests-failing-build.patch
@@ -0,0 +1,16 @@
+--- a/none/tests/ppc64/Makefile.am 2014-10-22 16:33:20.686773392 +0200
 b/none/tests/ppc64/Makefile.am 2014-10-23 10:31:38.948654523 +0200
+@@ -35,11 +35,10 @@
+
+ check_PROGRAMS = \
+   allexec \
+-  jm-insns lsw round std_reg_imm twi_tdi tw_td power6_bcmp \
++  lsw round std_reg_imm twi_tdi tw_td power6_bcmp \
+   power6_mf_gpr test_isa_2_06_part1 test_isa_2_06_part2 \
+   test_isa_2_06_part3 test_dfp1 test_dfp2 test_dfp3 test_dfp4 \
+-  test_dfp5 test_isa_2_07_part1 test_isa_2_07_part2 \
+-  test_tm test_touch_tm
++  test_dfp5
+
+ AM_CFLAGS+= @FLAG_M64@
+ AM_CXXFLAGS  += @FLAG_M64@
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.9.0.bb 
b/meta/recipes-devtools/valgrind/valgrind_3.9.0.bb
index c415e77..f642856 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.9.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.9.0.bb
@@ -19,6 +19,7 @@ SRC_URI = 
http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://force-nostabs.patch \
file://remove-arm-variant-specific.patch \
file://remove-ppc-tests-failing-build.patch \
+   file://remove-ppc64-tests-failing-build.patch \
file://add-ptest.patch \
file://run-ptest \
   
@@ -63,7 +64,7 @@ do_install_ptest() {
 #
 # The regression tests require scripts and data files that are not
 # copied to the build directory.  They must be copied from the
-# source directory.
+# source directory.
 saved_dir=$PWD
 for parent_dir in ${S} ${B} ; do
 cd $parent_dir
--
1.9.1

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

Re: [OE-core] [PATCH] python-pygtk: Restore pkg-config file

On Thu, 2014-10-30 at 17:14 +0100, Andreas Müller wrote:
 On Thu, Oct 30, 2014 at 4:39 PM, Gary Thomas g...@mlbassoc.com wrote:
 
  Wow, since Jan 2013 and no action?
 
  Was this proposed to OE-core (i.e. sent to the list)?
 
 No - my expiereineces sending patches to oe-core are not the best.
 Usually they just cause me efforts and aren't applied anyway..

Its sad that you feel that and if we can, I'd like to try and fix that
somehow.

People do try their best, equally, the response against the maintainers
if something goes wrong hasn't been ideal either.

Is there anything specific we can try and do better?

Cheers,

Richard

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

Re: [OE-core] Weird ALTERNATIVES and staging conflict.

On Thu, 2014-10-30 at 15:17 +0100, Mike Looijmans wrote:
 I have this base script that builds FPGA bitstreams:
 
 https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image.inc
 
 Now you can have multiple recipes using it, and as such, it seemed a good 
 idea 
 to add these lines to that recipe:
 
 +ALTERNATIVE_${PN} = fpga.bin bitstreams
 +ALTERNATIVE_LINK_NAME[fpga.bin] = ${datadir}/fpga.bin
 +ALTERNATIVE_TARGET[fpga.bin] = ${datadir}/fpga.bin
 +ALTERNATIVE_LINK_NAME[bitstreams] = ${datadir}/bitstreams
 +ALTERNATIVE_TARGET[bitstreams] = ${datadir}/bitstreams
 
 
 This still resulted in staging conflicts.

This isn't surprising since update-alternatives only works for target
systems. It is not designed for operating on the sysroot.

 But looking at the contents of the fake packages, the fpga.bin has been 
 renamed by alternatives (as expected), and the symlink will be created after 
 installing, so how come I still get this?

The staging code uses the output of do_install directly and does
different things to the packaging code path. We've never had someone
with this problem before. Binaries in *bindir only get installed into
the sysroot in the -native case.

I appreciate that tells you why it doesn't work and not how to fix it
but hopefully that helps a bit.

Cheers,

Richard

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

Re: [OE-core] [PATCH] Valgrind: Remove test apps not building with ppc64 and PTEST

On Thu, 2014-10-30 at 17:46 +0100, Alexandra Safta wrote:
 Signed-off-by: Alexandra Safta alexandra.sa...@enea.com

This removes the tests for all architectures? Why is that a good idea?
At the very least this needs more explanation.

Cheers,

Richard




  .../valgrind/remove-ppc64-tests-failing-build.patch  | 16 
 
  meta/recipes-devtools/valgrind/valgrind_3.9.0.bb |  3 ++-
  2 files changed, 18 insertions(+), 1 deletion(-)
  create mode 100644 
 meta/recipes-devtools/valgrind/valgrind/remove-ppc64-tests-failing-build.patch
 
 diff --git 
 a/meta/recipes-devtools/valgrind/valgrind/remove-ppc64-tests-failing-build.patch
  
 b/meta/recipes-devtools/valgrind/valgrind/remove-ppc64-tests-failing-build.patch
 new file mode 100644
 index 000..7bf3a21
 --- /dev/null
 +++ 
 b/meta/recipes-devtools/valgrind/valgrind/remove-ppc64-tests-failing-build.patch
 @@ -0,0 +1,16 @@
 +--- a/none/tests/ppc64/Makefile.am   2014-10-22 16:33:20.686773392 +0200
  b/none/tests/ppc64/Makefile.am   2014-10-23 10:31:38.948654523 +0200
 +@@ -35,11 +35,10 @@
 +
 + check_PROGRAMS = \
 + allexec \
 +-jm-insns lsw round std_reg_imm twi_tdi tw_td power6_bcmp \
 ++lsw round std_reg_imm twi_tdi tw_td power6_bcmp \
 + power6_mf_gpr test_isa_2_06_part1 test_isa_2_06_part2 \
 + test_isa_2_06_part3 test_dfp1 test_dfp2 test_dfp3 test_dfp4 \
 +-test_dfp5 test_isa_2_07_part1 test_isa_2_07_part2 \
 +-test_tm test_touch_tm
 ++test_dfp5
 +
 + AM_CFLAGS+= @FLAG_M64@
 + AM_CXXFLAGS  += @FLAG_M64@
 diff --git a/meta/recipes-devtools/valgrind/valgrind_3.9.0.bb 
 b/meta/recipes-devtools/valgrind/valgrind_3.9.0.bb
 index c415e77..f642856 100644
 --- a/meta/recipes-devtools/valgrind/valgrind_3.9.0.bb
 +++ b/meta/recipes-devtools/valgrind/valgrind_3.9.0.bb
 @@ -19,6 +19,7 @@ SRC_URI = 
 http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
 file://force-nostabs.patch \
 file://remove-arm-variant-specific.patch \
 file://remove-ppc-tests-failing-build.patch \
 +   file://remove-ppc64-tests-failing-build.patch \
 file://add-ptest.patch \
 file://run-ptest \

 @@ -63,7 +64,7 @@ do_install_ptest() {
  #
  # The regression tests require scripts and data files that are not
  # copied to the build directory.  They must be copied from the
 -# source directory.
 +# source directory.
  saved_dir=$PWD
  for parent_dir in ${S} ${B} ; do
  cd $parent_dir
 --
 1.9.1
 


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

[OE-core] Package Upgrading for 1.8

2014-10-30 Thread Saul Wold



Folks,

Just a reminder now that master is open again for patches, now is a 
great time to consider doing package Updates.  Based on some rough 
estimates from 1.7 we did around 300 updates from 34 contributors, that 
got us about 73% packages upgrades.


We currently have about 180 packages due to be updated based on the 
Package Reporting from this last week, about 65 of those where not 
updated in 1.7 so should be given some priority (see attached file), 
there are also 10 that need maintainers, let me know if you are 
interested in any of them.


Here are the stats from 1.7 on who has upgraded packages (I guess I 
don't have enough to do!).  Thanks to everyone who contributed package 
updates.


 61 Saul Wold
 43 Cristian Iorga
 25 Ross Burton
 23 Bruce Ashfield
 15 Armin Kuster
 14 Richard Purdie
 12 Laurentiu Palcu
 11 Paul Eggleton
  9 Hongxu Jia
  9 Cristiana Voicu
  9 Chen Qi
  8 Valentin Popa
  7 Chong Lu
  7 Carlos Rafael Giani
  6 Khem Raj
  5 Tim Orling
  4 Roxana Ciobanu
  4 Robert Yang
  4 Marko Lindqvist
  4 Mark Hatle
  3 Paul Barker
  3 Maxin B. John
  2 Yasir-Khan
  2 Nicolas Dechesne
  2 Fathi Boudra
  1 Ricardo Neri
  1 Peter Seebach
  1 Peter Kjellerstedt
  1 Martin Jansa
  1 Jackie Huang
  1 Darren Hart
  1 Ciobanu Roxana
  1 Chunrong Guo
  1 Andreas Müller


--
Sau!

Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System

ccache3.1.9 3.1.10  
  Wenzong Fan wenzong@windriver.com   
chkconfig 1.3.581.3.62  
  Wenzong Fan wenzong@windriver.com   
gettext   0.18.3.2  0.19.3  
  Wenzong Fan wenzong@windriver.com   
npth  0.91  1.0 
  Saul Wold s...@linux.intel.com   
apt   0.9.9.4   1.0.9.3 
  Saul Wold s...@linux.intel.com   
hdparm9.43  9.45
  Saul Wold s...@linux.intel.com   
dpkg  1.17.41.17.21 
  Saul Wold s...@linux.intel.com   
libaio0.3.109   0.3.110 
  Saul Wold s...@linux.intel.com   
valgrind  3.9.0 3.10.0  
  Saul Wold s...@linux.intel.com   
cronie1.4.111.4.12  
  Saul Wold s...@linux.intel.com   
usbutils  007   008 
  Saul Wold s...@linux.intel.com   
libksba   1.3.0 1.3.1   
  Saul Wold s...@linux.intel.com   
base-passwd   3.5.293.5.36  
  Saul Wold s...@linux.intel.com   
puzzles   r10116N/A 
  Ross Burton ross.bur...@intel.com   
xcb-util-image0.3.9 0.4.0   
  Ross Burton ross.bur...@intel.com   
libxext   1.3.2 1.3.3   
  Ross Burton ross.bur...@intel.com   
libxcb1.10  1.11
  Ross Burton ross.bur...@intel.com   
xcb-util  0.3.9 0.4.0   
  Ross Burton ross.bur...@intel.com   
libpam1.1.6 1.1.8   
  Ross Burton ross.bur...@intel.com   
gsettings-desktop-schemas 3.10.13.14.1  
  Ross Burton ross.bur...@intel.com   
xcb-proto 1.10  1.11
  Ross Burton ross.bur...@intel.com   
xinit 1.3.3 1.3.4   
  Ross Burton ross.bur...@intel.com   
libnotify 0.6.0 0.7.6   
  Ross Burton ross.bur...@intel.com   
screen4.0.3 4.2.1   
  Ross Burton ross.bur...@intel.com   
xcb-util-keysyms  0.3.9 0.4.0   
  Ross

Re: [OE-core] Package Upgrading for 1.8

2014-10-30 Thread Khem Raj

On Thu, Oct 30, 2014 at 11:21 AM, Saul Wold s...@linux.intel.com wrote:

 Folks,

 Just a reminder now that master is open again for patches, now is a great
 time to consider doing package Updates.  Based on some rough estimates from
 1.7 we did around 300 updates from 34 contributors, that got us about 73%
 packages upgrades.

 We currently have about 180 packages due to be updated based on the Package
 Reporting from this last week, about 65 of those where not updated in 1.7 so
 should be given some priority (see attached file), there are also 10 that
 need maintainers, let me know if you are interested in any of them.

I guess you can put me up for python3 recipes and all of toolchain related ones.


 Here are the stats from 1.7 on who has upgraded packages (I guess I don't
 have enough to do!).  Thanks to everyone who contributed package updates.

  61 Saul Wold
  43 Cristian Iorga
  25 Ross Burton
  23 Bruce Ashfield
  15 Armin Kuster
  14 Richard Purdie
  12 Laurentiu Palcu
  11 Paul Eggleton
   9 Hongxu Jia
   9 Cristiana Voicu
   9 Chen Qi
   8 Valentin Popa
   7 Chong Lu
   7 Carlos Rafael Giani
   6 Khem Raj
   5 Tim Orling
   4 Roxana Ciobanu
   4 Robert Yang
   4 Marko Lindqvist
   4 Mark Hatle
   3 Paul Barker
   3 Maxin B. John
   2 Yasir-Khan
   2 Nicolas Dechesne
   2 Fathi Boudra
   1 Ricardo Neri
   1 Peter Seebach
   1 Peter Kjellerstedt
   1 Martin Jansa
   1 Jackie Huang
   1 Darren Hart
   1 Ciobanu Roxana
   1 Chunrong Guo
   1 Andreas Müller


 --
 Sau!

 Saul Wold
 Yocto Component Wrangler @ Intel
 Yocto Project / Poky Build System


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

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

[OE-core] [PATCH v3] buildinfo.bblass: Added buildinfo class

2014-10-30 Thread Alejandro Hernandez

Writes build information to target filesystem to help developers

[YOCTO #6770]

Signed-off-by: Alejandro Hernandez alejandro.hernan...@linux.intel.com
---
 meta/classes/buildinfo.bbclass | 90 ++
 1 file changed, 90 insertions(+)
 create mode 100644 meta/classes/buildinfo.bbclass

diff --git a/meta/classes/buildinfo.bbclass b/meta/classes/buildinfo.bbclass
new file mode 100644
index 000..f00b073
--- /dev/null
+++ b/meta/classes/buildinfo.bbclass
@@ -0,0 +1,90 @@
+#
+# Writes build information to target filesystem
+#
+# Usage: add INHERIT += buildinfo to your conf file
+#
+# Based in part on buildhistory.bbclass
+#
+# Copyright (C) 2014 Intel Corporation
+# Author: Alejandro Enedino Hernandez Samaniego alejandro.hernan...@intel.com
+#
+# Licensed under the MIT license, see COPYING.MIT for details
+#
+
+# From buildhistory.bbclass
+def squashspaces(string):
+import re
+return re.sub(\s+,  , string).strip()
+
+# From buildhistory.bbclass
+def outputvars(vars, listvars, d): 
+vars = vars.split()
+listvars = listvars.split()
+ret = 
+for var in vars:
+value = d.getVar(var, True) or 
+if var in listvars:
+value = squashspaces(value)
+ret += %s = %s\n % (var, value)
+return ret.rstrip('\n')
+
+# From buildhistory.bbclass
+def base_get_metadata_git_branch(path, d): 
+branch = os.popen('cd %s; git branch 21 | grep ^*  | tr -d * ' % 
path).read()
+if len(branch) != 0:
+return branch
+return unknown
+
+# From buildhistory.bbclass
+def base_get_metadata_git_revision(path, d): 
+f = os.popen(cd %s; git log -n 1 --pretty=oneline -- 21 % path)
+data = f.read()
+if f.close() is None:
+rev = data.split( )[0]
+if len(rev) != 0:
+return rev 
+return unknown
+
+# Gets git branch's status (clean or dirty)
+def get_layer_git_status(path):
+f = os.popen(cd %s; git diff --stat 21 | tail -n 1 % path)
+data = f.read()
+if f.close() is None:
+if len(data) != 0:
+return -- modified
+return 
+
+# Returns layer revisions along with their respective status
+def get_layer_revs(d):
+layers = (d.getVar(BBLAYERS, True) or ).split()
+medadata_revs = [%-17s = %s:%s %s % (os.path.basename(i), \
+base_get_metadata_git_branch(i, None).strip(), \
+base_get_metadata_git_revision(i, None), \
+get_layer_git_status(i)) \
+for i in layers]
+return '\n'.join(medadata_revs)
+
+def buildinfo_target(d):
+# Get context
+if d.getVar('BB_WORKERCONTEXT', True) != '1':
+return 
+# Single and list variables to be read
+vars = DISTRO DISTRO_VERSION BB_VERSION BUILD_SYS TARGET_SYS MACHINE 
USER_CLASSES IMAGE_CLASSES IMAGE_FEATURES IMAGE_LINGUAS IMAGE_INSTALL 
PACKAGE_EXCLUDE
+listvars = USER_CLASSES IMAGE_CLASSES IMAGE_FEATURES IMAGE_LINGUAS 
IMAGE_INSTALL PACKAGE_EXCLUDE
+return outputvars(vars, listvars, d)
+
+# Write build information to target filesystem
+buildinfo () {
+cat  ${IMAGE_ROOTFS}${sysconfdir}/build END
+---
+Build Configuration:  |
+---
+${@buildinfo_target(d)}
+---
+Layer Revisions:  |   
+---
+${@get_layer_revs(d)}
+END
+}
+
+IMAGE_PREPROCESS_COMMAND += buildinfo;
-- 
1.9.1

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

Re: [OE-core] Opkg 0.2.3

2014-10-30 Thread Paul Barker

On 30 October 2014 19:15, Michael Gloff mgl...@emacinc.com wrote:
 As Paul mentioned yesterday opkg 0.2.4 is on it's way and 0.2.3 has been
 available for 2 months. If there are not any objections, I have an updated
 recipe and re-created previous patches that I could send. This should also
 modify opkg-colateral to use the new syntax for lists_dir.

I'm also sat on tested patches, I was planning to send them tomorrow.
I've held the patches back as the deadline for such changes for OE 1.7
had passed.

 I would also at this time like to propose changing the default list
 directory from /var/lib to something else (/usr/lib ?). On a read only
 rootfs, everything in /var/lib/ gets mounted on the tmpfs, therefore
 packages installed get lost.

Changes in v0.3.0 will make this much easier to configure. You'll be
able to set cache_dir, lists_dir, info_dir, lock_file and status_file
in opkg.conf. I'd rather we left the defaults as-is and use those
settings once v0.3.0 is released. v0.3.0 will also create any
directories needed if they don't exist. So it may make sense to set
cache_dir to something under /tmp, lock_file to something under /var
or /run and everything else under /usr if that's what's desired.

 I've tested changing the lists_dir and everything is working as expected.

 Michael Gloff


Thanks,

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Valgrind: Remove test apps not building with ppc64 and PTEST

2014-10-30 Thread Tudor Florea



 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org
 [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
 Of Richard Purdie
 Sent: Thursday, October 30, 2014 19:50
 To: Alexandra Safta
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH] Valgrind: Remove test apps not building with
 ppc64 and PTEST
 
 On Thu, 2014-10-30 at 17:46 +0100, Alexandra Safta wrote:
  Signed-off-by: Alexandra Safta alexandra.sa...@enea.com
 
 This removes the tests for all architectures? Why is that a good idea?
 At the very least this needs more explanation.
 
 Cheers,
 
 Richard
 

The patch is indented to remove tests that does not compile only for ppc64 
architecture: changes are only on none/tests/ppc64/Makefile.am file.
The patch is quite similar with the one existing for ppc architecture.

Regards,
  Tudor.


 
 
 
   .../valgrind/remove-ppc64-tests-failing-build.patch  | 16
 
   meta/recipes-devtools/valgrind/valgrind_3.9.0.bb |  3 ++-
   2 files changed, 18 insertions(+), 1 deletion(-)
   create mode 100644 meta/recipes-devtools/valgrind/valgrind/remove-
 ppc64-tests-failing-build.patch
 
  diff --git a/meta/recipes-devtools/valgrind/valgrind/remove-ppc64-tests-
 failing-build.patch b/meta/recipes-devtools/valgrind/valgrind/remove-
 ppc64-tests-failing-build.patch
  new file mode 100644
  index 000..7bf3a21
  --- /dev/null
  +++ b/meta/recipes-devtools/valgrind/valgrind/remove-ppc64-tests-
 failing-build.patch
  @@ -0,0 +1,16 @@
  +--- a/none/tests/ppc64/Makefile.am 2014-10-22
 16:33:20.686773392 +0200
   b/none/tests/ppc64/Makefile.am 2014-10-23
 10:31:38.948654523 +0200
  +@@ -35,11 +35,10 @@
  +
  + check_PROGRAMS = \
  +   allexec \
  +-  jm-insns lsw round std_reg_imm twi_tdi tw_td power6_bcmp \
  ++  lsw round std_reg_imm twi_tdi tw_td power6_bcmp \
  +   power6_mf_gpr test_isa_2_06_part1 test_isa_2_06_part2 \
  +   test_isa_2_06_part3 test_dfp1 test_dfp2 test_dfp3 test_dfp4 \
  +-  test_dfp5 test_isa_2_07_part1 test_isa_2_07_part2 \
  +-  test_tm test_touch_tm
  ++  test_dfp5
  +
  + AM_CFLAGS+= @FLAG_M64@
  + AM_CXXFLAGS  += @FLAG_M64@
  diff --git a/meta/recipes-devtools/valgrind/valgrind_3.9.0.bb
 b/meta/recipes-devtools/valgrind/valgrind_3.9.0.bb
  index c415e77..f642856 100644
  --- a/meta/recipes-devtools/valgrind/valgrind_3.9.0.bb
  +++ b/meta/recipes-devtools/valgrind/valgrind_3.9.0.bb
  @@ -19,6 +19,7 @@ SRC_URI =
 http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
  file://force-nostabs.patch \
  file://remove-arm-variant-specific.patch \
  file://remove-ppc-tests-failing-build.patch \
  +   file://remove-ppc64-tests-failing-build.patch \
  file://add-ptest.patch \
  file://run-ptest \
 
  @@ -63,7 +64,7 @@ do_install_ptest() {
   #
   # The regression tests require scripts and data files that are not
   # copied to the build directory.  They must be copied from the
  -# source directory.
  +# source directory.
   saved_dir=$PWD
   for parent_dir in ${S} ${B} ; do
   cd $parent_dir
  --
  1.9.1
 
 
 
 --
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Package Upgrading for 1.8

2014-10-30 Thread akuster




On 10/30/2014 11:21 AM, Saul Wold wrote:


Folks,

Just a reminder now that master is open again for patches, now is a
great time to consider doing package Updates.  Based on some rough
estimates from 1.7 we did around 300 updates from 34 contributors, that
got us about 73% packages upgrades.

We currently have about 180 packages due to be updated based on the
Package Reporting from this last week, about 65 of those where not
updated in 1.7 so should be given some priority (see attached file),
there are also 10 that need maintainers, let me know if you are
interested in any of them.


I will take pinentry.

- Armin


Here are the stats from 1.7 on who has upgraded packages (I guess I
don't have enough to do!).  Thanks to everyone who contributed package
updates.

  61 Saul Wold
  43 Cristian Iorga
  25 Ross Burton
  23 Bruce Ashfield
  15 Armin Kuster
  14 Richard Purdie
  12 Laurentiu Palcu
  11 Paul Eggleton
   9 Hongxu Jia
   9 Cristiana Voicu
   9 Chen Qi
   8 Valentin Popa
   7 Chong Lu
   7 Carlos Rafael Giani
   6 Khem Raj
   5 Tim Orling
   4 Roxana Ciobanu
   4 Robert Yang
   4 Marko Lindqvist
   4 Mark Hatle
   3 Paul Barker
   3 Maxin B. John
   2 Yasir-Khan
   2 Nicolas Dechesne
   2 Fathi Boudra
   1 Ricardo Neri
   1 Peter Seebach
   1 Peter Kjellerstedt
   1 Martin Jansa
   1 Jackie Huang
   1 Darren Hart
   1 Ciobanu Roxana
   1 Chunrong Guo
   1 Andreas Müller





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

Re: [OE-core] Package Upgrading for 1.8

2014-10-30 Thread Saul Wold


On 10/30/2014 12:07 PM, Paul Barker wrote:

On 30 October 2014 18:21, Saul Wold s...@linux.intel.com wrote:


Folks,

Just a reminder now that master is open again for patches, now is a great
time to consider doing package Updates.  Based on some rough estimates from
1.7 we did around 300 updates from 34 contributors, that got us about 73%
packages upgrades.

We currently have about 180 packages due to be updated based on the Package
Reporting from this last week, about 65 of those where not updated in 1.7 so
should be given some priority (see attached file), there are also 10 that
need maintainers, let me know if you are interested in any of them.


I don't see opkg, opkg-utils or libarchive in those emails or on
http://packages.yoctoproject.org/upgradepkgname. Any particular reason
they're missing?

I will look into that, could be that the code in the fetcher is not 
catching opkg correctly, we are working on updating that code to do a 
better job.



I'll send an upgrade to opkg v0.2.3 tomorrow, then further upgrades
once they're available.

Once I've merged a patch by Jian Liu to opkg-utils there will likely
be an opkg-utils SRCREV update.

I have my eye on libarchive as well as I'm using it within the
development versions of opkg. I'm subscribed to their announcement
mailing list so I'll know when a new release is made.

Thanks, saw your email earlier, thanks your hard work on the OPKG* know 
it's appreciated.


Sau!



Cheers,


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

Re: [OE-core] [PATCH 1/4] license_class: Reimplemented manifest creation in python

2014-10-30 Thread Aníbal Limón


Richard,

I did the changes that you suggest and another small changes adding
LIC_FILES_CHKSUM in some recipes to avoid warnings in manifest creation.

I put together into this branch for review,

https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=alimon/license

Best regards.

On 29/10/14 15:28, Richard Purdie wrote:

On Wed, 2014-10-29 at 12:34 -0600, Aníbal Limón wrote:

Reimplemented license_manifest_create from shell to python, in
order to use oe.license module for handle INCOMPATIBLE_LICENSE
and add License prorities into OR's evaluation.

Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com
---
  meta/classes/license.bbclass | 161 ---
  1 file changed, 90 insertions(+), 71 deletions(-)

diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index a34ea39..c8a86ce 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -25,78 +25,97 @@ python write_package_manifest() {
  'w+').write(image_list_installed_packages(d))
  }
  
-license_create_manifest() {

-# Test if BUILD_IMAGES_FROM_FEEDS is defined in env
-if [ -n ${BUILD_IMAGES_FROM_FEEDS} ]; then
-  exit 0
-fi
-
-   INSTALLED_PKGS=`cat ${LICENSE_DIRECTORY}/${IMAGE_NAME}/package.manifest`
-   LICENSE_MANIFEST=${LICENSE_DIRECTORY}/${IMAGE_NAME}/license.manifest
-   # remove existing license.manifest file
-   if [ -f ${LICENSE_MANIFEST} ]; then
-   rm ${LICENSE_MANIFEST}
-   fi
-   touch ${LICENSE_MANIFEST}
-   for pkg in ${INSTALLED_PKGS}; do
-   filename=`ls ${PKGDATA_DIR}/runtime-reverse/${pkg}| head -1`
-   pkged_pn=$(sed -n 's/^PN: //p' ${filename})
-
-   # check to see if the package name exists in the manifest. if 
so, bail.
-   if grep -q ^PACKAGE NAME: ${pkg} ${LICENSE_MANIFEST}; then
-   continue
-   fi
-
-   pkged_pv=$(sed -n 's/^PV: //p' ${filename})
-   pkged_name=$(basename $(readlink ${filename}))
-   pkged_lic=$(sed -n /^LICENSE_${pkged_name}: /{ s/^LICENSE_${pkged_name}: 
//; s/[|()*]/ /g; s/  */ /g; p } ${filename})
-   if [ -z ${pkged_lic} ]; then
-   # fallback checking value of LICENSE
-   pkged_lic=$(sed -n /^LICENSE: /{ s/^LICENSE: //; s/[|()*]/ /g; 
s/  */ /g; p } ${filename})
-   fi
-
-   echo PACKAGE NAME: ${pkg}  ${LICENSE_MANIFEST}
-   echo PACKAGE VERSION: ${pkged_pv}  ${LICENSE_MANIFEST}
-   echo RECIPE NAME: ${pkged_pn}  ${LICENSE_MANIFEST}
-   printf LICENSE:  ${LICENSE_MANIFEST}
-   for lic in ${pkged_lic}; do
-   # to reference a license file trim trailing + symbol
-   if ! [ -e 
${LICENSE_DIRECTORY}/${pkged_pn}/generic_${lic%+} ]; then
-   bbwarn The license listed ${lic} was not in the 
licenses collected for ${pkged_pn}
-   fi
-printf  ${lic}  ${LICENSE_MANIFEST}
-   done
-   printf \n\n  ${LICENSE_MANIFEST}
-   done
-
-   # Two options here:
-   # - Just copy the manifest
-   # - Copy the manifest and the license directories
-   # With both options set we see a .5 M increase in core-image-minimal
-   if [ ${COPY_LIC_MANIFEST} = 1 ]; then
-   mkdir -p ${IMAGE_ROOTFS}/usr/share/common-licenses/
-   cp ${LICENSE_MANIFEST} 
${IMAGE_ROOTFS}/usr/share/common-licenses/license.manifest
-   if [ ${COPY_LIC_DIRS} = 1 ]; then
-   for pkg in ${INSTALLED_PKGS}; do
-   mkdir -p 
${IMAGE_ROOTFS}/usr/share/common-licenses/${pkg}
-   pkged_pn=$(oe-pkgdata-util lookup-recipe 
${PKGDATA_DIR} ${pkg})
-   for lic in `ls 
${LICENSE_DIRECTORY}/${pkged_pn}`; do
-   # Really don't need to copy the 
generics as they're
-   # represented in the manifest and in 
the actual pkg licenses
-   # Doing so would make your image quite 
a bit larger
-   if [ ${lic#generic_} = ${lic} ]; 
then
-   cp 
${LICENSE_DIRECTORY}/${pkged_pn}/${lic} 
${IMAGE_ROOTFS}/usr/share/common-licenses/${pkg}/${lic}
-   else
-   if [ ! -f 
${IMAGE_ROOTFS}/usr/share/common-licenses/${lic} ]; then
-   cp 
${LICENSE_DIRECTORY}/${pkged_pn}/${lic} 
${IMAGE_ROOTFS}/usr/share/common-licenses/
-   fi
-   ln -sf ../${lic}

[OE-core] [PATCH v4] buildinfo.bblass: Added buildinfo class

2014-10-30 Thread Alejandro Hernandez

Writes build information to target filesystem on /etc/build, such as 

enabled layers, their current status and commit, squashspaces and outputvars 

functions moved from buidlhistory.bbclass to oe/utils.py, to be used by 

different classes and avoid code duplication.

[YOCTO #6770]

Signed-off-by: Alejandro Hernandez alejandro.hernan...@linux.intel.com
---
 meta/classes/buildhistory.bbclass | 39 
 meta/classes/buildinfo.bbclass| 53 +++
 meta/lib/oe/utils.py  | 16 
 3 files changed, 80 insertions(+), 28 deletions(-)
 create mode 100644 meta/classes/buildinfo.bbclass

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index 8b5d5c2..3f87f08 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -155,7 +155,7 @@ python buildhistory_emit_pkghistory() {
 with open(os.path.join(pkgdata_dir, pn)) as f:
 for line in f.readlines():
 if line.startswith('PACKAGES: '):
-packages = squashspaces(line.split(': ', 1)[1])
+packages = oe.utils.squashspaces(line.split(': ', 1)[1])
 break
 except IOError as e:
 if e.errno == errno.ENOENT:
@@ -181,7 +181,7 @@ python buildhistory_emit_pkghistory() {
 rcpinfo.pe = pe
 rcpinfo.pv = pv
 rcpinfo.pr = pr
-rcpinfo.depends = sortlist(squashspaces(d.getVar('DEPENDS', True) or ))
+rcpinfo.depends = sortlist(oe.utils.squashspaces(d.getVar('DEPENDS', True) 
or ))
 rcpinfo.packages = packages
 write_recipehistory(rcpinfo, d)
 
@@ -222,13 +222,13 @@ python buildhistory_emit_pkghistory() {
 pkginfo.pkge = pkge
 pkginfo.pkgv = pkgv
 pkginfo.pkgr = pkgr
-pkginfo.rprovides = sortpkglist(squashspaces(pkgdata.get('RPROVIDES', 
)))
-pkginfo.rdepends = sortpkglist(squashspaces(pkgdata.get('RDEPENDS', 
)))
-pkginfo.rrecommends = 
sortpkglist(squashspaces(pkgdata.get('RRECOMMENDS', )))
-pkginfo.rsuggests = sortpkglist(squashspaces(pkgdata.get('RSUGGESTS', 
)))
-pkginfo.rreplaces = sortpkglist(squashspaces(pkgdata.get('RREPLACES', 
)))
-pkginfo.rconflicts = 
sortpkglist(squashspaces(pkgdata.get('RCONFLICTS', )))
-pkginfo.files = squashspaces(pkgdata.get('FILES', ))
+pkginfo.rprovides = 
sortpkglist(oe.utils.squashspaces(pkgdata.get('RPROVIDES', )))
+pkginfo.rdepends = 
sortpkglist(oe.utils.squashspaces(pkgdata.get('RDEPENDS', )))
+pkginfo.rrecommends = 
sortpkglist(oe.utils.squashspaces(pkgdata.get('RRECOMMENDS', )))
+pkginfo.rsuggests = 
sortpkglist(oe.utils.squashspaces(pkgdata.get('RSUGGESTS', )))
+pkginfo.rreplaces = 
sortpkglist(oe.utils.squashspaces(pkgdata.get('RREPLACES', )))
+pkginfo.rconflicts = 
sortpkglist(oe.utils.squashspaces(pkgdata.get('RCONFLICTS', )))
+pkginfo.files = oe.utils.squashspaces(pkgdata.get('FILES', ))
 for filevar in pkginfo.filevars:
 pkginfo.filevars[filevar] = pkgdata.get(filevar, )
 
@@ -525,36 +525,19 @@ def buildhistory_get_metadata_revs(d):
 for i in layers]
 return '\n'.join(medadata_revs)
 
-
-def squashspaces(string):
-import re
-return re.sub(\s+,  , string).strip()
-
-def outputvars(vars, listvars, d):
-vars = vars.split()
-listvars = listvars.split()
-ret = 
-for var in vars:
-value = d.getVar(var, True) or 
-if var in listvars:
-# Squash out spaces
-value = squashspaces(value)
-ret += %s = %s\n % (var, value)
-return ret.rstrip('\n')
-
 def buildhistory_get_imagevars(d):
 if d.getVar('BB_WORKERCONTEXT', True) != '1':
 return 
 imagevars = DISTRO DISTRO_VERSION USER_CLASSES IMAGE_CLASSES 
IMAGE_FEATURES IMAGE_LINGUAS IMAGE_INSTALL BAD_RECOMMENDATIONS 
NO_RECOMMENDATIONS PACKAGE_EXCLUDE ROOTFS_POSTPROCESS_COMMAND 
IMAGE_POSTPROCESS_COMMAND
 listvars = USER_CLASSES IMAGE_CLASSES IMAGE_FEATURES IMAGE_LINGUAS 
IMAGE_INSTALL BAD_RECOMMENDATIONS PACKAGE_EXCLUDE
-return outputvars(imagevars, listvars, d)
+return oe.utils.outputvars(imagevars, listvars, d)
 
 def buildhistory_get_sdkvars(d):
 if d.getVar('BB_WORKERCONTEXT', True) != '1':
 return 
 sdkvars = DISTRO DISTRO_VERSION SDK_NAME SDK_VERSION SDKMACHINE 
SDKIMAGE_FEATURES BAD_RECOMMENDATIONS NO_RECOMMENDATIONS PACKAGE_EXCLUDE
 listvars = SDKIMAGE_FEATURES BAD_RECOMMENDATIONS PACKAGE_EXCLUDE
-return outputvars(sdkvars, listvars, d)
+return oe.utils.outputvars(sdkvars, listvars, d)
 
 
 def buildhistory_get_cmdline(d):
diff --git a/meta/classes/buildinfo.bbclass b/meta/classes/buildinfo.bbclass
new file mode 100644
index 000..a0220b2
--- /dev/null
+++ b/meta/classes/buildinfo.bbclass
@@ -0,0 +1,53 @@
+#
+# Writes build information to target filesystem
+#
+# Usage: add INHERIT += buildinfo to your conf file
+#
+#

[OE-core] [PATCH V2 0/1] libxml2: fix python path and add libxml2-python

Change since v1:
add python to PACKAGECONFIG.

The following changes since commit 4faca22b8fe63a86d820990207aaf84b3fa83e01:

  ref-manual: Updates to the migrating to YP 1.7 section. (2014-10-28 22:31:18 
+)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib chonglu/libxml2
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=chonglu/libxml2

Robert Yang (1):
  libxml2: fix python path and add libxml2-python

 meta/recipes-core/libxml/libxml2.inc | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

-- 
1.9.1

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

[OE-core] [PATCH V2 1/1] libxml2: fix python path and add libxml2-python

From: Robert Yang liezhi.y...@windriver.com

We have libxml2-python for native and nativesdk, but don't have it for
target, and can't find the reason from the git log, libxml2-python is
widely used, after looked into it's configure.in, we can add it
by PACKAGECONFIG.

The previous --with-python=${STAGING_BINDIR}/python is incorrect, it
acted as work becase it's conigure can check automatically, python is in
${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}, as known as
${PYTHON}.

Add python to PACKAGECONFIG, since createrepo rdepends on libxml2-python.

Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
 meta/recipes-core/libxml/libxml2.inc | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/meta/recipes-core/libxml/libxml2.inc 
b/meta/recipes-core/libxml/libxml2.inc
index c729c19..2bdfed0 100644
--- a/meta/recipes-core/libxml/libxml2.inc
+++ b/meta/recipes-core/libxml/libxml2.inc
@@ -9,8 +9,6 @@ LIC_FILES_CHKSUM = 
file://Copyright;md5=2044417e2e5006b65a8b9067b683fcf1 \
 
file://list.c;beginline=4;endline=13;md5=cdbfa3dee51c099edb04e39f762ee907 \
 
file://trio.c;beginline=5;endline=14;md5=6c025753c86d958722ec76e94cae932e
 
-DEPENDS_class-nativesdk = nativesdk-python
-DEPENDS_class-native = python-native
 DEPENDS =+ zlib
 
 SRC_URI = ftp://xmlsoft.org/libxml2/libxml2-${PV}.tar.gz;name=libtar \
@@ -37,16 +35,17 @@ do_configure_prepend () {
sed -i -e '/.*ansidecl.h.*/d' ${S}/configure.in
 }
 
-do_configure_prepend_class-nativesdk () {
-   # Ensure we get the correct site-packages path
-   export PYTHON_SITE_PACKAGES=${PYTHON_SITEPACKAGES_DIR}
-}
+export PYTHON_SITE_PACKAGES=${PYTHON_SITEPACKAGES_DIR}
+
+PACKAGECONFIG ??= python
+PACKAGECONFIG_linuxstdbase ??= 
 
+PACKAGECONFIG[python] = 
--with-python=${PYTHON},--without-python,python,python-core
 # WARNING: zlib is require for RPM use
-EXTRA_OECONF = --without-python --without-debug --without-legacy 
--with-catalog --without-docbook --with-c14n --without-lzma --with-fexceptions
-EXTRA_OECONF_class-native = --with-python=${STAGING_BINDIR}/python 
--without-legacy --without-docbook --with-c14n --without-lzma --with-zlib
-EXTRA_OECONF_class-nativesdk = --with-python=${STAGING_BINDIR}/python 
--without-legacy --without-docbook --with-c14n --without-lzma --with-zlib
-EXTRA_OECONF_linuxstdbase = --without-python --with-debug --with-legacy 
--with-docbook --with-c14n --without-lzma --with-zlib
+EXTRA_OECONF = --without-debug --without-legacy --with-catalog 
--without-docbook --with-c14n --without-lzma --with-fexceptions
+EXTRA_OECONF_class-native = --without-legacy --without-docbook --with-c14n 
--without-lzma --with-zlib
+EXTRA_OECONF_class-nativesdk = --without-legacy --without-docbook --with-c14n 
--without-lzma --with-zlib
+EXTRA_OECONF_linuxstdbase = --with-debug --with-legacy --with-docbook 
--with-c14n --without-lzma --with-zlib
 
 # required for pythong binding
 export HOST_SYS
-- 
1.9.1

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

Re: [OE-core] [PATCH 1/1] libpam: add system-auth in case of systemd

2014-10-30 Thread ChenQi


On 10/30/2014 09:27 PM, Koen Kooi wrote:

Op 30 okt. 2014, om 10:08 heeft Chen Qi qi.c...@windriver.com het volgende 
geschreven:

systemd needs this file to be there because one of its configuration file
in pam.d, systemd-user, requires it. Otherwise, we would have errors like
below.

systemd: PAM _pam_load_conf_file: unable to open /etc/pam.d/system-auth

Isn't it the same as 'common-auth'? ISTR this is due to debian vs fedora naming 
of PAM stuff. I think it would make more sense to check what systemd actually 
wants and then see if a symlink to common-auth or patching systemd to use 
common-auth is the right answer instead of blindly adding system-auth.

regards,

Koen



Hi Koen,

An alternative is to patch systemd's source code to change the 
systemd-user configuration file.


In fact, I have seen patches in OE whose purpose is merely changing 
'system-auth' to 'common-auth' in the pam configuration files of the 
packages.


So we have two options here:
1. Provide system-auth
2. Patch packages that make use of system-auth and maintain those patches.

I think solution 1 is more reasonable but if you and other people in 
community think that solution 2 can bring us more benefits, I can send 
out a patch using solution 2.


Best Regards,
Chen Qi


Signed-off-by: Chen Qi qi.c...@windriver.com
---
meta/recipes-extended/pam/libpam/pam.d/system-auth | 12 
meta/recipes-extended/pam/libpam_1.1.6.bb  |  1 +
2 files changed, 13 insertions(+)
create mode 100644 meta/recipes-extended/pam/libpam/pam.d/system-auth

diff --git a/meta/recipes-extended/pam/libpam/pam.d/system-auth 
b/meta/recipes-extended/pam/libpam/pam.d/system-auth
new file mode 100644
index 000..ffb08ab
--- /dev/null
+++ b/meta/recipes-extended/pam/libpam/pam.d/system-auth
@@ -0,0 +1,12 @@
+# This file comes from systemd.
+
+auth sufficient pam_unix.so nullok try_first_pass
+
+account  required   pam_nologin.so
+account  sufficient pam_unix.so
+
+password sufficient pam_unix.so nullok sha512 shadow try_first_pass try_authtok
+
+-session optional   pam_loginuid.so
+-session optional   pam_systemd.so
+session  sufficient pam_unix.so
diff --git a/meta/recipes-extended/pam/libpam_1.1.6.bb 
b/meta/recipes-extended/pam/libpam_1.1.6.bb
index a84e51e..0910b6f 100644
--- a/meta/recipes-extended/pam/libpam_1.1.6.bb
+++ b/meta/recipes-extended/pam/libpam_1.1.6.bb
@@ -17,6 +17,7 @@ SRC_URI = 
http://linux-pam.org/library/Linux-PAM-${PV}.tar.bz2 \
file://pam.d/common-session \
file://pam.d/common-session-noninteractive \
file://pam.d/other \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'file://pam.d/system-auth', '', d)} \
file://libpam-xtests.patch \
file://destdirfix.patch \
file://fixsepbuild.patch \
--
1.9.1

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





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

Re: [OE-core] [PATCH 1/1] libpam: add system-auth in case of systemd

2014-10-30 Thread ChenQi


On 10/31/2014 10:59 AM, ChenQi wrote:

On 10/30/2014 09:27 PM, Koen Kooi wrote:
Op 30 okt. 2014, om 10:08 heeft Chen Qi qi.c...@windriver.com het 
volgende geschreven:


systemd needs this file to be there because one of its configuration 
file
in pam.d, systemd-user, requires it. Otherwise, we would have errors 
like

below.

systemd: PAM _pam_load_conf_file: unable to open 
/etc/pam.d/system-auth
Isn't it the same as 'common-auth'? ISTR this is due to debian vs 
fedora naming of PAM stuff. I think it would make more sense to check 
what systemd actually wants and then see if a symlink to common-auth 
or patching systemd to use common-auth is the right answer instead of 
blindly adding system-auth.


regards,

Koen



Hi Koen,

An alternative is to patch systemd's source code to change the 
systemd-user configuration file.


In fact, I have seen patches in OE whose purpose is merely changing 
'system-auth' to 'common-auth' in the pam configuration files of the 
packages.


It might be 'common-passwd', 'common-session', not just 'common-auth'. 
You can see this from the contents of system-auth file.




So we have two options here:
1. Provide system-auth
2. Patch packages that make use of system-auth and maintain those 
patches.


I think solution 1 is more reasonable but if you and other people in 
community think that solution 2 can bring us more benefits, I can send 
out a patch using solution 2.


Best Regards,
Chen Qi


Signed-off-by: Chen Qi qi.c...@windriver.com
---
meta/recipes-extended/pam/libpam/pam.d/system-auth | 12 
meta/recipes-extended/pam/libpam_1.1.6.bb  |  1 +
2 files changed, 13 insertions(+)
create mode 100644 meta/recipes-extended/pam/libpam/pam.d/system-auth

diff --git a/meta/recipes-extended/pam/libpam/pam.d/system-auth 
b/meta/recipes-extended/pam/libpam/pam.d/system-auth

new file mode 100644
index 000..ffb08ab
--- /dev/null
+++ b/meta/recipes-extended/pam/libpam/pam.d/system-auth
@@ -0,0 +1,12 @@
+# This file comes from systemd.
+
+auth sufficient pam_unix.so nullok try_first_pass
+
+account  required   pam_nologin.so
+account  sufficient pam_unix.so
+
+password sufficient pam_unix.so nullok sha512 shadow try_first_pass 
try_authtok

+
+-session optional   pam_loginuid.so
+-session optional   pam_systemd.so
+session  sufficient pam_unix.so
diff --git a/meta/recipes-extended/pam/libpam_1.1.6.bb 
b/meta/recipes-extended/pam/libpam_1.1.6.bb

index a84e51e..0910b6f 100644
--- a/meta/recipes-extended/pam/libpam_1.1.6.bb
+++ b/meta/recipes-extended/pam/libpam_1.1.6.bb
@@ -17,6 +17,7 @@ SRC_URI = 
http://linux-pam.org/library/Linux-PAM-${PV}.tar.bz2 \

file://pam.d/common-session \
file://pam.d/common-session-noninteractive \
file://pam.d/other \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'file://pam.d/system-auth', '', d)} \

file://libpam-xtests.patch \
file://destdirfix.patch \
file://fixsepbuild.patch \
--
1.9.1

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







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

[OE-core] [PATCH 1/1] gst-plugin-bluetooth: remove systemd service file

The service file should be included in bluez4 package, not in plugin package.

This solves the following warning:

WARNING: QA Issue: gst-plugin-bluetooth: Files/directories were installed but 
not shipped
  /lib
  /lib/systemd
  /lib/systemd/system
  /lib/systemd/system/bluetooth.service [installed-vs-shipped]

Signed-off-by: Chong Lu chong...@windriver.com
---
 meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb 
b/meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb
index f2dc0da..c71d612 100644
--- a/meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb
+++ b/meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb
@@ -25,6 +25,7 @@ do_install_append() {
rm -rf ${D}${libdir}/alsa-lib
rm -rf ${D}${datadir}
rm -rf ${D}${includedir}
+   rm -rf ${D}${nonarch_base_libdir}
 }
 
 FILES_${PN} = ${libdir}/gstreamer-0.10/lib*.so
-- 
1.9.1

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

[OE-core] [PATCH 0/1] gst-plugin-bluetooth: remove systemd service file