[OE-core] [PATCH v2] python_2.7.9.bb: Add python-misc as runtime dependency to python-modules

2015-09-16 Thread Erkka Kääriä 
Currently python-misc is not included even if python-modules is. This means 
some python scripts fail even if python-modules is included in the image (for 
example, get-pip.py at bootstrap.pypa.io/get-pip.py).

Signed-off-by: Erkka Kääriä 
---
 meta/recipes-devtools/python/python_2.7.9.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python_2.7.9.bb 
b/meta/recipes-devtools/python/python_2.7.9.bb
index ae45577..f7e2f27 100644
--- a/meta/recipes-devtools/python/python_2.7.9.bb
+++ b/meta/recipes-devtools/python/python_2.7.9.bb
@@ -161,7 +161,8 @@ FILES_${PN}-dbg += 
"${libdir}/python${PYTHON_MAJMIN}/lib-dynload/.debug"
 # catch all the rest (unsorted)
 PACKAGES += "${PN}-misc"
 FILES_${PN}-misc = "${libdir}/python${PYTHON_MAJMIN}"
-RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-misc"
+RDEPENDS_${PN}-modules += "${PN}-misc"
+RDEPENDS_${PN}-ptest = "${PN}-modules"
 #inherit ptest after "require python-${PYTHON_MAJMIN}-manifest.inc" so 
PACKAGES doesn't get overwritten
 inherit ptest
 
-- 
2.1.4

-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] python.inc: Remove --with-wctype-functions configure option

2015-09-16 Thread Erkka Kääriä 
This option is causing issues with python unicode support. Several unicode 
related regression tests are currently failing (test_re and test_codecs for 
example) and removing this option fixes these.

This configure option mostly seems to be historical. Discussion related to 
python issue 9210 (https://bugs.python.org/issue9210) indicates its original 
goal was to save memory and that the option should have been deprecated ages 
ago.

Signed-off-by: Erkka Kääriä 
---
 meta/recipes-devtools/python/python.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python.inc 
b/meta/recipes-devtools/python/python.inc
index e18ab8e..4d428f3 100644
--- a/meta/recipes-devtools/python/python.inc
+++ b/meta/recipes-devtools/python/python.inc
@@ -16,7 +16,6 @@ PYTHON_MAJMIN = "2.7"
 
 inherit autotools
 
-PYTHONLSBOPTS = "--with-wctype-functions"
 PYTHONLSBOPTS_linuxstdbase = "ac_cv_sizeof_off_t=8"
 
 EXTRA_OECONF = "\
-- 
2.1.4

-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 02/12] hostap-utils: Use C99 stddefs in defining local typedefs

2015-09-16 Thread Mikko.Rapeli 
On Tue, Sep 15, 2015 at 08:13:26AM -0700, Khem Raj wrote:
> On Mon, Sep 14, 2015 at 11:33 PM,   wrote:
> > On Mon, Sep 14, 2015 at 04:31:17PM +, Khem Raj wrote:
> >> The code is creating more abstract types which is nice however it should
> >> be using standard defines from stdint.h and not random defines to base
> >> its own type system
> >
> > These types are not random. They are standard Linux kernel types used by 
> > headers
> > exported to userspace and their definitions come from .
> > These headers should not depend on libc headers like stdint.h.
> 
> Right they are not random in general but they are randomly being
> redefined by the application,
> if it should be using linux/types.h those are different types than
> what is being defined here. I have just
> made the semantics of existing logic to be more c99 compliant.
> 
> >
> > Also, this file is actually a convenience copy of  which 
> > should
> > be used directly instead.
> 
> There must be a reason to make own copy. May be hostap-utils want to
> be portable to more than linux

A private copy of  is only usefull with Linux kernel. Since
mid 2000's Linux kernel has a way to properly export these headers to
userspace. Thus the private copies should not be needed anymore.

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

[OE-core] [PATCH 0/3] meta: 3 fixes

2015-09-16 Thread Robert Yang 
The following changes since commit f0189829498e30231d826c9f55aad73e622d076e:

  qemu: Update to upstream patches (2015-09-14 11:22:02 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/3fixes
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/3fixes

Robert Yang (3):
  subversion: 1.8.13 -> 1.8.14 since 1.8.13.tar.gz was gone
  nspr: fix SRC_URI
  mkelfimage: fix owner for /usr/sbin/mkelfImage

 meta/recipes-devtools/mkelfimage/mkelfimage_git.bb |1 +
 .../disable_macos.patch|0
 .../libtool2.patch |0
 ...erf.m4-Regex-modified-to-allow-D-in-paths.patch |0
 .../{subversion_1.8.13.bb => subversion_1.8.14.bb} |4 ++--
 meta/recipes-support/nspr/nspr_4.10.8.bb   |2 +-
 6 files changed, 4 insertions(+), 3 deletions(-)
 rename meta/recipes-devtools/subversion/{subversion-1.8.13 => 
subversion}/disable_macos.patch (100%)
 rename meta/recipes-devtools/subversion/{subversion-1.8.13 => 
subversion}/libtool2.patch (100%)
 rename meta/recipes-devtools/subversion/{subversion-1.8.13 => 
subversion}/serf.m4-Regex-modified-to-allow-D-in-paths.patch (100%)
 rename meta/recipes-devtools/subversion/{subversion_1.8.13.bb => 
subversion_1.8.14.bb} (96%)

-- 
1.7.9.5

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

[OE-core] [PATCH 2/3] nspr: fix SRC_URI

2015-09-16 Thread Robert Yang 
Fixed:
WARNING: Failed to fetch URL 
ftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v4.10.8/src/nspr-4.10.8.tar.gz,
 attempting MIRRORS if available

Its ftp:// doesn't work with wget, but http:// works.

Signed-off-by: Robert Yang 
---
 meta/recipes-support/nspr/nspr_4.10.8.bb |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/nspr/nspr_4.10.8.bb 
b/meta/recipes-support/nspr/nspr_4.10.8.bb
index 944994e..bc60018 100644
--- a/meta/recipes-support/nspr/nspr_4.10.8.bb
+++ b/meta/recipes-support/nspr/nspr_4.10.8.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = 
"file://configure.in;beginline=3;endline=6;md5=90c2fdee38e45d
 
file://Makefile.in;beginline=4;endline=38;md5=beda1dbb98a515f557d3e58ef06bca99"
 SECTION = "libs/network"
 
-SRC_URI = 
"ftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v${PV}/src/nspr-${PV}.tar.gz
 \
+SRC_URI = 
"http://ftp.mozilla.org/pub/nspr/releases/v${PV}/src/nspr-${PV}.tar.gz \
file://remove-rpath-from-tests.patch \
file://fix-build-on-x86_64.patch \
file://remove-srcdir-from-configure-in.patch \
-- 
1.7.9.5

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

[OE-core] [PATCH 1/3] subversion: 1.8.13 -> 1.8.14 since 1.8.13.tar.gz was gone

2015-09-16 Thread Robert Yang 
The subversion-1.8.13.tar.bz2 is gone from ftp, so upgrade to 1.8.14.

Signed-off-by: Robert Yang 
---
 .../disable_macos.patch|0
 .../libtool2.patch |0
 ...erf.m4-Regex-modified-to-allow-D-in-paths.patch |0
 .../{subversion_1.8.13.bb => subversion_1.8.14.bb} |4 ++--
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/subversion/{subversion-1.8.13 => 
subversion}/disable_macos.patch (100%)
 rename meta/recipes-devtools/subversion/{subversion-1.8.13 => 
subversion}/libtool2.patch (100%)
 rename meta/recipes-devtools/subversion/{subversion-1.8.13 => 
subversion}/serf.m4-Regex-modified-to-allow-D-in-paths.patch (100%)
 rename meta/recipes-devtools/subversion/{subversion_1.8.13.bb => 
subversion_1.8.14.bb} (96%)

diff --git 
a/meta/recipes-devtools/subversion/subversion-1.8.13/disable_macos.patch 
b/meta/recipes-devtools/subversion/subversion/disable_macos.patch
similarity index 100%
rename from 
meta/recipes-devtools/subversion/subversion-1.8.13/disable_macos.patch
rename to meta/recipes-devtools/subversion/subversion/disable_macos.patch
diff --git a/meta/recipes-devtools/subversion/subversion-1.8.13/libtool2.patch 
b/meta/recipes-devtools/subversion/subversion/libtool2.patch
similarity index 100%
rename from meta/recipes-devtools/subversion/subversion-1.8.13/libtool2.patch
rename to meta/recipes-devtools/subversion/subversion/libtool2.patch
diff --git 
a/meta/recipes-devtools/subversion/subversion-1.8.13/serf.m4-Regex-modified-to-allow-D-in-paths.patch
 
b/meta/recipes-devtools/subversion/subversion/serf.m4-Regex-modified-to-allow-D-in-paths.patch
similarity index 100%
rename from 
meta/recipes-devtools/subversion/subversion-1.8.13/serf.m4-Regex-modified-to-allow-D-in-paths.patch
rename to 
meta/recipes-devtools/subversion/subversion/serf.m4-Regex-modified-to-allow-D-in-paths.patch
diff --git a/meta/recipes-devtools/subversion/subversion_1.8.13.bb 
b/meta/recipes-devtools/subversion/subversion_1.8.14.bb
similarity index 96%
rename from meta/recipes-devtools/subversion/subversion_1.8.13.bb
rename to meta/recipes-devtools/subversion/subversion_1.8.14.bb
index f843b95..115ae16 100644
--- a/meta/recipes-devtools/subversion/subversion_1.8.13.bb
+++ b/meta/recipes-devtools/subversion/subversion_1.8.14.bb
@@ -14,8 +14,8 @@ SRC_URI = "${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
file://disable_macos.patch \
file://serf.m4-Regex-modified-to-allow-D-in-paths.patch \
 "
-SRC_URI[md5sum] = "4413417b529d7bdf82f74e50df02e88b"
-SRC_URI[sha256sum] = 
"1099cc68840753b48aedb3a27ebd1e2afbcc84ddb871412e5d500e843d607579"
+SRC_URI[md5sum] = "fe476ba26d6835eba4393780ea907361"
+SRC_URI[sha256sum] = 
"7f3883cdfcad4174e06dd94d6e3e8ec91856823268eebe60c924be76f5229a1f"
 
 LIC_FILES_CHKSUM = "file://LICENSE;md5=1c2f0119e478700b5428e26386cff923"
 
-- 
1.7.9.5

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

[OE-core] [PATCH 3/3] mkelfimage: fix owner for /usr/sbin/mkelfImage

2015-09-16 Thread Robert Yang 
Fixed:
packages-split/mkelfimage/usr/sbin/mkelfImage is owned by uid 15220, which is 
the same as the user running bitbake. This may be due to host contamination 
[host-user-contaminated]

This is because its Makefile uses cp -a to install mkelfImage.

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/mkelfimage/mkelfimage_git.bb |1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb 
b/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
index 2845b8c..e1c33a6 100644
--- a/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
+++ b/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
@@ -30,6 +30,7 @@ inherit autotools-brokensep
 do_install_append() {
rmdir ${D}${datadir}/mkelfImage/elf32-i386
rmdir ${D}${datadir}/mkelfImage
+   chown root:root ${D}/${sbindir}/mkelfImage
 }
 
 BBCLASSEXTEND = "native"
-- 
1.7.9.5

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

Re: [OE-core] [PATCH][master][fido][dizzy] Revert "perf: fix for rebuilding"

2015-09-16 Thread Burton, Ross 
On 16 September 2015 at 08:48, Robert Yang 
wrote:

> I've figured out the reason, this is because the task's default cwd
> is ${B}, the easier way to fix the problem is use mkdir -p rather than
> mkdir, autotools.bbclass also has this problem, but I'd like to fix
> exec_func, I will send a patch to bitbake-devel after more testing.
>

Changing the default $B of [dirs] is not something we'll be doing post-M3.
I've a branch that changes that default and have fixed all the obvious
breakage in oe-core already so this is something on my plan for immediately
after 2.1 branches off.

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

Re: [OE-core] [PATCH][master][fido][dizzy] Revert "perf: fix for rebuilding"

2015-09-16 Thread Robert Yang 



On 09/16/2015 04:57 PM, Burton, Ross wrote:


On 16 September 2015 at 08:48, Robert Yang > wrote:

I've figured out the reason, this is because the task's default cwd
is ${B}, the easier way to fix the problem is use mkdir -p rather than
mkdir, autotools.bbclass also has this problem, but I'd like to fix
exec_func, I will send a patch to bitbake-devel after more testing.


Changing the default $B of [dirs] is not something we'll be doing post-M3. I've


Thanks, so let's simply use "mkdir -p" to fix the problem, atm ?


a branch that changes that default and have fixed all the obvious breakage in
oe-core already so this is something on my plan for immediately after 2.1
branches off.


I made 2 patches just now, one is for bitbake, and one for insane.bbclass,
 maybe we are doing the similar things, I can drop them then.

build.py: default exec_func's cwd to WORKDIR

This can fix a few problems:
- The ${B} was nearly always created in the past after any tak runs, for
  example, the ${B} exists after do_clean or do_cleansstate (first
  removed, then created), but ${B} is useless and confused end user in
  this case, the similar to a lot of prefuncs and postfuncs which also
  create ${B}, but not used. This patch fixes the problem.

- This can fix race issue when we use the following commands in other
  tasks:
rm -rf ${B}
mkdir ${B}
  such as autotools.bbclass and perf.bb.

When the 'dirs' or 'cleandirs' is not specified by task, which means
that they are not important, so default to WORKDIR which is more common
and usually existed.

Signed-off-by: Robert Yang 

diff --git a/bitbake/lib/bb/build.py b/bitbake/lib/bb/build.py
index 948c395..a413c35 100644
--- a/bitbake/lib/bb/build.py
+++ b/bitbake/lib/bb/build.py
@@ -182,8 +182,9 @@ def exec_func(func, d, dirs = None):
 bb.utils.mkdirhier(adir)
 adir = dirs[-1]
 else:
-adir = d.getVar('B', True)
-bb.utils.mkdirhier(adir)
+adir = d.getVar('WORKDIR', True)
+if not os.path.exists(adir):
+bb.utils.mkdirhier(adir)

 ispython = flags.get('python')

===

insane.bbclass: only do_qa_unpack warn when SRC_URI is not null

If SRC_URI is null, then no source is needed to be unpacked, thus no
warn.

Signed-off-by: Robert Yang 

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 5c8629a..e22e8a0 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1214,7 +1214,7 @@ python do_qa_unpack() {
 bb.note("Checking has ${S} been created")

 s_dir = d.getVar('S', True)
-if not os.path.exists(s_dir):
+if not os.path.exists(s_dir) and d.getVar('SRC_URI', True):
 bb.warn('%s: the directory %s (%s) pointed to by the S variable 
doesn\'t exist - please set S within the recipe to point to where the source has 
been unpacked to' % (d.getVar('PN', T

 }

// Robert


Ross

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

[OE-core] [PATCH 00/14] Proposed Fido changes

2015-09-16 Thread Joshua Lock 
Please consider the following changes for the fido branch.

The branch has successfully passed an autobuilder run:

https://autobuilder.yoctoproject.org/main/builders/nightly/builds/547

The following changes since commit 5a1839ecc9a2191252019ddd5c253098006f5bc3:

  tzdata: update to 2015d (2015-09-01 21:41:24 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib joshuagl/fido-next
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=joshuagl/fido-next

Alejandro Hernandez (1):
  qemurunner: Improves checking for server and target IPs on qemus
parameters

Armin Kuster (2):
  bind: CVE-2015-1349 CVE-2015-4620 CVE-2015-5722
  openssh: CVE-2015-6563 CVE-2015-6564 CVE-2015-6565

George McCollister (1):
  wic: fix path parsing, use last occurrence

Li Zhou (1):
  libunwind: Security Advisory - libunwind - CVE-2015-3239

Martin Jansa (3):
  rootfs.py: Allow to override postinst-intercepts location
  postinst_intercept: allow to pass variables with spaces
  rootfs.py: show intercept script output in log.do_rootfs

Paul Eggleton (1):
  oeqa/utils/qemurunner: fix logging

Richard Purdie (1):
  runqemu: Handle device names like tapX@NONE

Ross Burton (1):
  oeqa/QemuRunner: don't use bb for logging

Saul Wold (1):
  oprofileui: Use inherit gettext

Sona Sarmadi (2):
  gnutls: CVE-2015-3308
  libtasn1: CVE-2015-3622

 meta/lib/oe/rootfs.py  |   8 +-
 meta/lib/oeqa/utils/qemurunner.py  |  73 +--
 .../bind/bind/CVE-2015-1349.patch  |  60 +++
 .../bind/bind/CVE-2015-4620.patch  |  36 ++
 .../bind/bind/CVE-2015-5722.patch  | 490 +
 meta/recipes-connectivity/bind/bind_9.9.5.bb   |   3 +
 .../openssh/openssh/CVE-2015-6563.patch|  36 ++
 .../openssh/openssh/CVE-2015-6564.patch|  34 ++
 .../openssh/openssh/CVE-2015-6565.patch|  35 ++
 meta/recipes-connectivity/openssh/openssh_6.7p1.bb |   6 +-
 meta/recipes-kernel/oprofile/oprofileui.inc|   2 +-
 .../better-fix-for-double-free-CVE-2015-3308.patch |  65 +++
 .../eliminated-double-free-CVE-2015-3308.patch |  33 ++
 meta/recipes-support/gnutls/gnutls_3.3.12.bb   |   2 +
 .../gnutls/libtasn1/libtasn1-CVE-2015-3622.patch   |  44 ++
 meta/recipes-support/gnutls/libtasn1_4.0.bb|   1 +
 ...rf-opcodes-can-cause-references-beyond-th.patch |  29 ++
 meta/recipes-support/libunwind/libunwind_1.1.bb|   1 +
 scripts/lib/wic/plugin.py  |   2 +-
 scripts/postinst-intercepts/postinst_intercept |   2 +-
 scripts/runqemu-internal   |   2 +-
 21 files changed, 922 insertions(+), 42 deletions(-)
 create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2015-1349.patch
 create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2015-4620.patch
 create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2015-5722.patch
 create mode 100644 
meta/recipes-connectivity/openssh/openssh/CVE-2015-6563.patch
 create mode 100644 
meta/recipes-connectivity/openssh/openssh/CVE-2015-6564.patch
 create mode 100644 
meta/recipes-connectivity/openssh/openssh/CVE-2015-6565.patch
 create mode 100644 
meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
 create mode 100644 
meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch
 create mode 100644 
meta/recipes-support/gnutls/libtasn1/libtasn1-CVE-2015-3622.patch
 create mode 100644 
meta/recipes-support/libunwind/libunwind-1.1/0001-Invalid-dwarf-opcodes-can-cause-references-beyond-th.patch

-- 
2.4.3

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

Re: [OE-core] [PATCH][master][fido][dizzy] Revert "perf: fix for rebuilding"

2015-09-16 Thread Robert Yang 


Hi Martin,

I've figured out the reason, this is because the task's default cwd
is ${B}, the easier way to fix the problem is use mkdir -p rather than
mkdir, autotools.bbclass also has this problem, but I'd like to fix
exec_func, I will send a patch to bitbake-devel after more testing.

// Robert

On 09/15/2015 01:53 PM, Robert Yang wrote:


Hi Martin,

Sorry, I'm blocked by mutitlib SDK issues recently, I will fix it sooner.
Revert the patch is fine to me if it is urgent.

// Robert

On 09/15/2015 01:29 PM, Martin Jansa wrote:

* This reverts commit 9dafa571ed0a40d21a886dec7704c31150b21942.

* The "fix" is causing more issues then it's fixing and there was no
   feedback in many months.
* More info:

http://lists.openembedded.org/pipermail/openembedded-core/2015-June/105684.html

http://lists.openembedded.org/pipermail/openembedded-core/2015-September/109870.html


http://lists.openembedded.org/pipermail/openembedded-core/2015-September/110338.html


Signed-off-by: Martin Jansa 
---
  meta/recipes-kernel/perf/perf.bb | 4 
  1 file changed, 4 deletions(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index adb3a2c..f1d7894 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -118,10 +118,6 @@ do_install() {
  }

  do_configure_prepend () {
-# Fix for rebuilding
-rm -rf ${B}/
-mkdir ${B}/
-
  # If building a multlib based perf, the incorrect library path will be
  # detected by perf, since it triggers via: ifeq ($(ARCH),x86_64). In a
32 bit
  # build, with a 64 bit multilib, the arch won't match and the detection
of a


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

Re: [OE-core] Multilib build support by single toolchain generated by Yocto

2015-09-16 Thread Luo Zhenhua 
Hi Mark, 

Thanks for your comments. 

> -Original Message-
> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> Sent: Tuesday, September 15, 2015 9:05 PM
> 
> On 9/15/15 3:23 AM, Luo Zhenhua wrote:
> >
> > Currently to support 32b and 64b build for same core in Yocto, two
> > separated compilers need to be generated. Is there plan to support
> > multilib build(32b and
> > 64b) by single toolchain which is generated by Yocto in future?
> >
> 
> The requirements for multilib compilers depend on architecture, configuration
> and GNU GCC limitations.  Some architects will work fine with a single 
> compiler,
> others may require multiple compilers.
[Luo Zhenhua-B19537] It is feasible to generate the single toolchain with 
multilib support in Yocto, is the understanding right? 
Do you mind to give more details of above comments for better 
understanding? 


Best Regards,

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

Re: [OE-core] [PATCH 1/4] gtk+/cairo: enable x11 or directfb

2015-09-16 Thread Jussi Kukkonen 
On 16 September 2015 at 05:28, Robert Yang 
wrote:
>
> The gtk+2 requires whether x11 or directfb to build, so we need enable
> either of them. The cairo can be built without x11 or directfb, but gtk+
> requires cairo, so enable x11 or directfb for cairo, too.

What is the issue being fixed here? I can see how current config can go
wrong in some situations but I'm not sure if the approach "if x11 is not a
DISTRO_FEATURE, then automatically use direcfb" is much better. Especially
for cairo: I would have thought building multiple surface backends is a
valid choice there?

Jussi

> Signed-off-by: Robert Yang 
> ---
>  meta/recipes-gnome/gtk+/gtk+.inc  |5 ++---
>  meta/recipes-graphics/cairo/cairo.inc |8 ++--
>  2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/meta/recipes-gnome/gtk+/gtk+.inc
b/meta/recipes-gnome/gtk+/gtk+.inc
> index be5273d..9d697cdb 100644
> --- a/meta/recipes-gnome/gtk+/gtk+.inc
> +++ b/meta/recipes-gnome/gtk+/gtk+.inc
> @@ -17,9 +17,8 @@ X11DEPENDS = "virtual/libx11 libxext libxcursor
libxrandr libxdamage libxrender
>  DEPENDS = "glib-2.0 pango atk jpeg libpng gdk-pixbuf-native
docbook-utils-native \
>   cairo gdk-pixbuf"
>
> -PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11',
'', d)} \
> -   ${@bb.utils.contains('DISTRO_FEATURES', 'directfb',
'directfb', '', d)} \
> -"
> +# Requires x11 or directfb
> +PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11',
'directfb', d)}"
>
>  PACKAGECONFIG[x11] = "--with-x=yes
--with-gdktarget=x11,--with-x=no,${X11DEPENDS}"
>  # without --with-gdktarget=directfb it will check for cairo-xlib which
isn't available without X11 DISTRO_FEATURE
> diff --git a/meta/recipes-graphics/cairo/cairo.inc
b/meta/recipes-graphics/cairo/cairo.inc
> index 1e45318..f6474bc 100644
> --- a/meta/recipes-graphics/cairo/cairo.inc
> +++ b/meta/recipes-graphics/cairo/cairo.inc
> @@ -17,8 +17,12 @@ LICENSE_${PN}-perf-utils = "GPLv3+"
>  X11DEPENDS = "virtual/libx11 libsm libxrender libxext"
>  DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
>
> -PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11
xcb', '', d)} \
> -   ${@bb.utils.contains('DISTRO_FEATURES', 'directfb',
'directfb', '', d)}"
> +# Build cairo-xlib or cairo-directfb for gtk+
> +PACKAGECONFIG ??= " ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11
xcb', 'directfb', d)} \
> +"
> +
> +# No directfb-native, so set PACKAGECONFIG to null when no x11
> +PACKAGECONFIG_class-native ??= "${@bb.utils.contains('DISTRO_FEATURES',
'x11', 'x11', '', d)}"
>
>  PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no
--disable-xlib,${X11DEPENDS}"
>  PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
> --
> 1.7.9.5
>
> --
> ___
> 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 0/2] perf and autotools.bbclass: mkdir ${B} -> mkdir -p ${B}

2015-09-16 Thread Robert Yang 
The following changes since commit f0189829498e30231d826c9f55aad73e622d076e:

  qemu: Update to upstream patches (2015-09-14 11:22:02 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/mkdir
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/mkdir

Robert Yang (2):
  perf: mkdir ${B} -> mkdir -p ${B}
  autotools.bbclass: mkdir ${B} -> mkdir -p ${B}

 meta/classes/autotools.bbclass   |2 +-
 meta/recipes-kernel/perf/perf.bb |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
1.7.9.5

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

[OE-core] [PATCH 1/2] perf: mkdir ${B} -> mkdir -p ${B}

2015-09-16 Thread Robert Yang 
${B} is the default cwd of tasks, so there might be race issues such as:
| mkdir: cannot create directory 
`/path/to/work/qemux86-poky-linux/perf/1.0-r9/perf-1.0/': File exists
[snip]
NOTE: recipe perf-1.0-r9: task do_configure: Failed

Signed-off-by: Robert Yang 
---
 meta/recipes-kernel/perf/perf.bb |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index adb3a2c..242cf62 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -120,7 +120,7 @@ do_install() {
 do_configure_prepend () {
 # Fix for rebuilding
 rm -rf ${B}/
-mkdir ${B}/
+mkdir -p ${B}/
 
 # If building a multlib based perf, the incorrect library path will be
 # detected by perf, since it triggers via: ifeq ($(ARCH),x86_64). In a 32 
bit
-- 
1.7.9.5

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

[OE-core] [PATCH 2/2] autotools.bbclass: mkdir ${B} -> mkdir -p ${B}

2015-09-16 Thread Robert Yang 
${B} is the default cwd of tasks, so there might be race issues such as:
| mkdir: cannot create directory `${B}': File exists
[snip]
NOTE: recipe perf-1.0-r9: task do_configure: Failed

Signed-off-by: Robert Yang 
---
 meta/classes/autotools.bbclass |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index 9ccd7d2..819045a 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -105,7 +105,7 @@ autotools_preconfigure() {
if [ "${S}" != "${B}" ]; then
echo "Previously configured separate build 
directory detected, cleaning ${B}"
rm -rf ${B}
-   mkdir ${B}
+   mkdir -p ${B}
else
# At least remove the .la files since automake 
won't automatically
# regenerate them even if CFLAGS/LDFLAGS are 
different
-- 
1.7.9.5

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

[OE-core] udev + 60-persistent-storage.rules + IDE

2015-09-16 Thread Patrick Ohly 
Hello!

I just noticed that udev (no longer) creates /dev/disk/by-uuid links for
my boot partition under qemu when booting a whole-disk image
(hdddirect). The device is then /dev/hda, with /dev/hda2 being the root
partition.

systemd's 60-persistent-storage.rules indeed skips the relevant rules
because "hd" is not listed:

KERNEL!="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*|xvd*|bcache*|cciss*|dasd*|ubd*",
 GOTO="persistent_storage_end"

Adding "hd*" to that line fixes the problem. I'll send patches to
systemd and for OE-core.

I'm a bit puzzled a) that plain-old IDE block devices have never been
matched by 60-persistent-storage.rules (I checked the history) and b)
that this suddenly broke. I'm fairly sure that I had tested that (but I
cannot 100% guarantee that anymore).

Did indeed something change recently that led to /dev/hda?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

Re: [OE-core] [PATCH 3/4] insane.bbclass: fix package_qa_check_buildpaths

2015-09-16 Thread Richard Purdie 
On Tue, 2015-09-15 at 19:28 -0700, Robert Yang wrote:
> * Ignore elf files because they usually contain build path:
>   - The path of the source file such as .c, these are usually happen
> when separate B and S since we use absolute path to run configure
> script, and then VPATH in Makefile will be an absolute path and
> contains build path, we can use relative path in autotools.bbclass
> to fix the problem, but we don't have to since they are harmless.
>   - The configure options such as "configure --with-libtool-sysroot"
>   - The compile options such as "gcc --sysroot"
>   These are harmless usually, so ignore elf files.

I'm not sure about this. Yes, elf files have large issues in the debug
symbols but the main elf files really shouldn't have build paths in
them. I understand they can creep in through a variety of sources
including B!=S but we should really be identifying them and fixing them,
not pretending they don't exist. The whole point of this check
originally was to get to the bottom of this!

> * Ignore "-dbg" and "-staticdev" package since symbols and .a files
>   usually contain buildpath.

Ideally, we should be fixing the debug code so its using target paths
rather than build ones too...

Cheers,

Richard

> * Ignore .a files too since they contain buildpath, this mainly for
>   ignoring:
>   glibc-2.21: glibc-dev/usr/lib/libc_nonshared.a
>   libgcc-4.9.3: libgcc-dev/usr/lib/x86_64-poky-linux/4.9.3/libgcc_eh.a
>   gcc-runtime-4.9.3: libssp-dev/usr/lib/libssp_nonshared.a
> 
> * Use full path rather than package_qa_clean_path() when report issue,
>   this makes it easier to find the file and fix the problem.
> 
> Then we will verify other warings and fix one be one.


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

Re: [OE-core] [PATCH 1/4] gtk+/cairo: enable x11 or directfb

2015-09-16 Thread Robert Yang 



On 09/16/2015 06:25 PM, Jussi Kukkonen wrote:

On 16 September 2015 at 05:28, Robert Yang > wrote:
 >
 > The gtk+2 requires whether x11 or directfb to build, so we need enable
 > either of them. The cairo can be built without x11 or directfb, but gtk+
 > requires cairo, so enable x11 or directfb for cairo, too.

What is the issue being fixed here? I can see how current config can go wrong in


Make the world build OK when possible, for example, when no x11 in
DISTRO_FEATURE.


some situations but I'm not sure if the approach "if x11 is not a
DISTRO_FEATURE, then automatically use direcfb" is much better. Especially for
cairo: I would have thought building multiple surface backends is a valid choice
there?


Yes, this is not a perfect solution, I don't like to pull in directfb either.
We can override PACKAGECONFIG to custom the build.

// Robert



Jussi

 > Signed-off-by: Robert Yang >
 > ---
 >  meta/recipes-gnome/gtk+/gtk+.inc  |5 ++---
 >  meta/recipes-graphics/cairo/cairo.inc |8 ++--
 >  2 files changed, 8 insertions(+), 5 deletions(-)
 >
 > diff --git a/meta/recipes-gnome/gtk+/gtk+.inc 
b/meta/recipes-gnome/gtk+/gtk+.inc
 > index be5273d..9d697cdb 100644
 > --- a/meta/recipes-gnome/gtk+/gtk+.inc
 > +++ b/meta/recipes-gnome/gtk+/gtk+.inc
 > @@ -17,9 +17,8 @@ X11DEPENDS = "virtual/libx11 libxext libxcursor libxrandr
libxdamage libxrender
 >  DEPENDS = "glib-2.0 pango atk jpeg libpng gdk-pixbuf-native
docbook-utils-native \
 >   cairo gdk-pixbuf"
 >
 > -PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '',
d)} \
 > -   ${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 'directfb',
'', d)} \
 > -"
 > +# Requires x11 or directfb
 > +PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11',
'directfb', d)}"
 >
 >  PACKAGECONFIG[x11] = "--with-x=yes
--with-gdktarget=x11,--with-x=no,${X11DEPENDS}"
 >  # without --with-gdktarget=directfb it will check for cairo-xlib which isn't
available without X11 DISTRO_FEATURE
 > diff --git a/meta/recipes-graphics/cairo/cairo.inc
b/meta/recipes-graphics/cairo/cairo.inc
 > index 1e45318..f6474bc 100644
 > --- a/meta/recipes-graphics/cairo/cairo.inc
 > +++ b/meta/recipes-graphics/cairo/cairo.inc
 > @@ -17,8 +17,12 @@ LICENSE_${PN}-perf-utils = "GPLv3+"
 >  X11DEPENDS = "virtual/libx11 libsm libxrender libxext"
 >  DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
 >
 > -PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 xcb',
'', d)} \
 > -   ${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 'directfb',
'', d)}"
 > +# Build cairo-xlib or cairo-directfb for gtk+
 > +PACKAGECONFIG ??= " ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11
xcb', 'directfb', d)} \
 > +"
 > +
 > +# No directfb-native, so set PACKAGECONFIG to null when no x11
 > +PACKAGECONFIG_class-native ??= "${@bb.utils.contains('DISTRO_FEATURES',
'x11', 'x11', '', d)}"
 >
 >  PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no
--disable-xlib,${X11DEPENDS}"
 >  PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
 > --
 > 1.7.9.5
 >
 > --
 > ___
 > 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] perf triggering a QA error

2015-09-16 Thread Otavio Salvador 
On Wed, Sep 16, 2015 at 1:54 AM, Rongqing Li  wrote:
> On 2015年09月16日 03:00, Otavio Salvador wrote:
>>
>> Hello folks,
>>
>> It seems the commit:
>
>
> try this patch
>
> http://patchwork.openembedded.org/patch/103239/

Works like a charm. Ross, this one fixes the issue for me.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] adwaita-icon-theme: RREPLACE gnome-icon-theme

2015-09-16 Thread Jussi Kukkonen 
RREPLACE, RCONFLICT and RPROVIDE gnome-icon-theme to make on-device
upgrades work.

Signed-off-by: Jussi Kukkonen 
---

 meta/recipes-gnome/gnome/adwaita-icon-theme_3.16.2.1.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-gnome/gnome/adwaita-icon-theme_3.16.2.1.bb 
b/meta/recipes-gnome/gnome/adwaita-icon-theme_3.16.2.1.bb
index 526e699..0d7fa0c 100644
--- a/meta/recipes-gnome/gnome/adwaita-icon-theme_3.16.2.1.bb
+++ b/meta/recipes-gnome/gnome/adwaita-icon-theme_3.16.2.1.bb
@@ -27,6 +27,10 @@ do_install_append() {
 
 PACKAGES = "${PN}-cursors ${PN}-symbolic ${PN}-hires ${PN}"
 
+RREPLACES_${PN} = "gnome-icon-theme"
+RCONFLICTS_${PN} = "gnome-icon-theme"
+RPROVIDES_${PN} = "gnome-icon-theme"
+
 FILES_${PN}-cursors = "${prefix}/share/icons/Adwaita/cursors/"
 FILES_${PN}-symbolic = "${prefix}/share/icons/Adwaita/*/*/*.symbolic.png"
 FILES_${PN}-hires = "${prefix}/share/icons/Adwaita/256x256/"
-- 
2.1.4

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

Re: [OE-core] [PATCH] cryptodev-tests: don't use STAGING_KERNEL_DIR, fix re-packaging in multi-machine builds

2015-09-16 Thread Denys Dmytriyenko 
Ping. Any comments?

On Wed, Sep 09, 2015 at 06:05:19PM -0400, Denys Dmytriyenko wrote:
> From: Denys Dmytriyenko 
> 
> Signed-off-by: Denys Dmytriyenko 
> ---
>  meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb 
> b/meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb
> index efc41ae..be59a4a 100644
> --- a/meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb
> +++ b/meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb
> @@ -9,7 +9,7 @@ 
> file://0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch \
>  file://0002-Fix-tests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch \
>  "
>  
> -EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_DIR}" PREFIX="${D}"'
> +EXTRA_OEMAKE='KERNEL_DIR="${STAGING_EXECPREFIXDIR}" PREFIX="${D}"'
>  
>  do_compile() {
>   oe_runmake testprogs
> -- 
> 2.2.0
> 
> -- 
> ___
> 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 3/4] insane.bbclass: fix package_qa_check_buildpaths

2015-09-16 Thread Robert Yang 

On 09/16/2015 08:38 PM, Richard Purdie wrote:

On Tue, 2015-09-15 at 19:28 -0700, Robert Yang wrote:

* Ignore elf files because they usually contain build path:
   - The path of the source file such as .c, these are usually happen
 when separate B and S since we use absolute path to run configure
 script, and then VPATH in Makefile will be an absolute path and
 contains build path, we can use relative path in autotools.bbclass
 to fix the problem, but we don't have to since they are harmless.
   - The configure options such as "configure --with-libtool-sysroot"
   - The compile options such as "gcc --sysroot"
   These are harmless usually, so ignore elf files.


I'm not sure about this. Yes, elf files have large issues in the debug
symbols but the main elf files really shouldn't have build paths in
them. I understand they can creep in through a variety of sources
including B!=S but we should really be identifying them and fixing them,
not pretending they don't exist. The whole point of this check
originally was to get to the bottom of this!


Thanks, the fix will change a lot to the build behaviour, I'd like to fix
them in 2.1.

// Robert




* Ignore "-dbg" and "-staticdev" package since symbols and .a files
   usually contain buildpath.


Ideally, we should be fixing the debug code so its using target paths
rather than build ones too...

Cheers,

Richard


* Ignore .a files too since they contain buildpath, this mainly for
   ignoring:
   glibc-2.21: glibc-dev/usr/lib/libc_nonshared.a
   libgcc-4.9.3: libgcc-dev/usr/lib/x86_64-poky-linux/4.9.3/libgcc_eh.a
   gcc-runtime-4.9.3: libssp-dev/usr/lib/libssp_nonshared.a

* Use full path rather than package_qa_clean_path() when report issue,
   this makes it easier to find the file and fix the problem.

Then we will verify other warings and fix one be one.






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

Re: [OE-core] [PATCH 1/3] subversion: 1.8.13 -> 1.8.14 since 1.8.13.tar.gz was gone

2015-09-16 Thread Burton, Ross 
On 16 September 2015 at 08:52, Robert Yang 
wrote:

> The subversion-1.8.13.tar.bz2 is gone from ftp, so upgrade to 1.8.14.
>

The FTP server only contains the latest release for each release series so
if they release a 1.8.15 the day after we ship Jethro we'd need to upgrade
subversion again.

The subversion archive is at http://archive.apache.org/dist/subversion/ and
includes all historical releases.  The recipe should use this URL instead.

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

Re: [OE-core] [PATCH 1/3] subversion: 1.8.13 -> 1.8.14 since 1.8.13.tar.gz was gone

2015-09-16 Thread Robert Yang 



On 09/16/2015 09:16 PM, Burton, Ross wrote:


On 16 September 2015 at 08:52, Robert Yang > wrote:

The subversion-1.8.13.tar.bz2 is gone from ftp, so upgrade to 1.8.14.


The FTP server only contains the latest release for each release series so if
they release a 1.8.15 the day after we ship Jethro we'd need to upgrade
subversion again.

The subversion archive is at http://archive.apache.org/dist/subversion/ and
includes all historical releases.  The recipe should use this URL instead.


Thanks, I updated it in the repo:

  git://git.openembedded.org/openembedded-core-contrib rbt/3fixes

commit 967c17d861ce2b9835e3ab12d5b172b059291dd7
Author: Robert Yang 
Date:   Wed Sep 16 07:05:47 2015 -0700

subversion: fix SRC_URI

Fixed:
WARNING: Failed to fetch URL 
http://www.apache.org/dist/subversion/subversion-1.8.13.tar.bz2, attempting 
MIRRORS if available


Ross:
The FTP server only contains the latest release for each release series,
the subversion archive is at http://archive.apache.org/dist/subversion/
and includes all historical releases. The recipe should use this URL
instead.

Signed-off-by: Robert Yang 

diff --git a/meta/recipes-devtools/subversion/subversion_1.8.13.bb 
b/meta/recipes-devtools/subversion/subversion_1.8.13.bb

index f843b95..eb1f0f2 100644
--- a/meta/recipes-devtools/subversion/subversion_1.8.13.bb
+++ b/meta/recipes-devtools/subversion/subversion_1.8.13.bb
@@ -9,7 +9,7 @@ BBCLASSEXTEND = "native"

 inherit gettext pythonnative

-SRC_URI = "${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
+SRC_URI = "http://archive.apache.org/dist/${BPN}/${BP}.tar.bz2 \
file://libtool2.patch \
file://disable_macos.patch \
file://serf.m4-Regex-modified-to-allow-D-in-paths.patch \

// Robert



Ross

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

[OE-core] [PATCH][dizzy] grep2.19: CVE-2015-1345

2015-09-16 Thread Sona Sarmadi 
Fixes heap-based buffer overflow flaw in grep.
Affected versions are: grep 2.19 through 2.21

Removed THANKS.in changes from upstream patch since this
file does not exist in version 2.19.
Replaced tab with spaces in SRC_URI as well.

Upstream fix:
http://git.sv.gnu.org/cgit/grep.git/commit/?id=
83a95bd8c8561875b948cadd417c653dbe7ef2e2

Signed-off-by: Sona Sarmadi 
---
 .../grep/grep-2.19/grep2.19-CVE-2015-1345.patch| 129 +
 meta/recipes-extended/grep/grep_2.19.bb|   4 +-
 2 files changed, 132 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-extended/grep/grep-2.19/grep2.19-CVE-2015-1345.patch

diff --git a/meta/recipes-extended/grep/grep-2.19/grep2.19-CVE-2015-1345.patch 
b/meta/recipes-extended/grep/grep-2.19/grep2.19-CVE-2015-1345.patch
new file mode 100644
index 000..32846f5
--- /dev/null
+++ b/meta/recipes-extended/grep/grep-2.19/grep2.19-CVE-2015-1345.patch
@@ -0,0 +1,129 @@
+From 83a95bd8c8561875b948cadd417c653dbe7ef2e2 Mon Sep 17 00:00:00 2001
+From: Yuliy Pisetsky 
+Date: Thu, 01 Jan 2015 23:36:55 +
+Subject: grep -F: fix a heap buffer (read) overrun
+
+grep's read buffer is often filled to its full size, except when
+reading the final buffer of a file.  In that case, the number of
+bytes read may be far less than the size of the buffer.  However, for
+certain unusual pattern/text combinations, grep -F would mistakenly
+examine bytes in that uninitialized region of memory when searching
+for a match.  With carefully chosen inputs, one can cause grep -F to
+read beyond the end of that buffer altogether.  This problem arose via
+commit v2.18-90-g73893ff with the introduction of a more efficient
+heuristic using what is now the memchr_kwset function. The use of
+that function in bmexec_trans could leave TP much larger than EP,
+and the subsequent call to bm_delta2_search would mistakenly access
+beyond end of the main input read buffer.
+
+* src/kwset.c (bmexec_trans): When TP reaches or exceeds EP,
+do not call bm_delta2_search.
+* tests/kwset-abuse: New file.
+* tests/Makefile.am (TESTS): Add it.
+* NEWS (Bug fixes): Mention it.
+
+Prior to this patch, this command would trigger a UMR:
+
+  printf %0360db 0 | valgrind src/grep -F $(printf %019dXb 0)
+
+  Use of uninitialised value of size 8
+ at 0x4142BE: bmexec_trans (kwset.c:657)
+ by 0x4143CA: bmexec (kwset.c:678)
+ by 0x414973: kwsexec (kwset.c:848)
+ by 0x414DC4: Fexecute (kwsearch.c:128)
+ by 0x404E2E: grepbuf (grep.c:1238)
+ by 0x4054BF: grep (grep.c:1417)
+ by 0x405CEB: grepdesc (grep.c:1645)
+ by 0x405EC1: grep_command_line_arg (grep.c:1692)
+ by 0x4077D4: main (grep.c:2570)
+
+See the accompanying test for how to trigger the heap buffer overrun.
+
+Thanks to Nima Aghdaii for testing and finding numerous
+ways to break early iterations of this patch.
+
+Fixes CVE-2015-1345.
+Upstream-Status: Backport
+
+---
+diff --git a/NEWS b/NEWS
+index 975440d..3835d8d 100644
+--- a/NEWS
 b/NEWS
+@@ -2,6 +2,11 @@ GNU grep NEWS-*- outline 
-*-
+ 
+ * Noteworthy changes in release ?.? (-??-??) [?]
+ 
++** Bug fixes
++
++  grep no longer reads from uninitialized memory or from beyond the end
++  of the heap-allocated input buffer.
++
+ 
+ * Noteworthy changes in release 2.21 (2014-11-23) [stable]
+ 
+diff --git a/src/kwset.c b/src/kwset.c
+index 4003c8d..376f7c3 100644
+--- a/src/kwset.c
 b/src/kwset.c
+@@ -643,6 +643,8 @@ bmexec_trans (kwset_t kwset, char const *text, size_t size)
+ if (! tp)
+   return -1;
+ tp++;
++if (ep <= tp)
++  break;
+   }
+   }
+   }
+diff --git a/tests/Makefile.am b/tests/Makefile.am
+index 2cba2cd..0508cd2 100644
+--- a/tests/Makefile.am
 b/tests/Makefile.am
+@@ -75,6 +75,7 @@ TESTS =  \
+   inconsistent-range  \
+   invalid-multibyte-infloop   \
+   khadafy \
++  kwset-abuse \
+   long-line-vs-2GiB-read  \
+   match-lines \
+   max-count-overread  \
+diff --git a/tests/kwset-abuse b/tests/kwset-abuse
+new file mode 100755
+index 000..6d8ec0c
+--- a/dev/null
 b/tests/kwset-abuse
+@@ -0,0 +1,32 @@
++#! /bin/sh
++# Evoke a segfault in a hard-to-reach code path of kwset.c.
++# This bug affected grep versions 2.19 through 2.21.
++#
++# Copyright (C) 2015 Free Software Foundation, Inc.
++#
++# This program is free software: you can redistribute it and/or modify
++# it under the terms of the GNU General Public License as published by
++# the Free Software Foundation, either version 3 of the License, or
++# (at your option) any later version.
++
++# This program is distributed in the

Re: [OE-core] [PATCH 3/4] insane.bbclass: fix package_qa_check_buildpaths

2015-09-16 Thread Richard Purdie 
On Wed, 2015-09-16 at 21:56 +0800, Robert Yang wrote:
> On 09/16/2015 08:38 PM, Richard Purdie wrote:
> > On Tue, 2015-09-15 at 19:28 -0700, Robert Yang wrote:
> >> * Ignore elf files because they usually contain build path:
> >>- The path of the source file such as .c, these are usually happen
> >>  when separate B and S since we use absolute path to run configure
> >>  script, and then VPATH in Makefile will be an absolute path and
> >>  contains build path, we can use relative path in autotools.bbclass
> >>  to fix the problem, but we don't have to since they are harmless.
> >>- The configure options such as "configure --with-libtool-sysroot"
> >>- The compile options such as "gcc --sysroot"
> >>These are harmless usually, so ignore elf files.
> >
> > I'm not sure about this. Yes, elf files have large issues in the debug
> > symbols but the main elf files really shouldn't have build paths in
> > them. I understand they can creep in through a variety of sources
> > including B!=S but we should really be identifying them and fixing them,
> > not pretending they don't exist. The whole point of this check
> > originally was to get to the bottom of this!
> 
> Thanks, the fix will change a lot to the build behaviour, I'd like to fix
> them in 2.1.

Agreed, this is 2.1 material at this point.

Cheers,

Richard

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

Re: [OE-core] [PATCH] devshell: symlink $TOPDIR to $WORKDIR/topdir

2015-09-16 Thread Christopher Larson 
On Tue, Sep 15, 2015 at 3:56 PM, Christopher Larson 
wrote:

> From: Christopher Larson 
>
> It's quite common to need to copy files out of the devshell back to your
> layers, but most of the variables referring to such paths are not exported
> (and in some cases, should not be, as it'll affect buildsystems we run,
> e.g.
> TOPDIR/BUILDDIR). To resolve this while still making it easier to get files
> out of the devshell, create a ${WORKDIR}/topdir symlink to ${TOPDIR},
> removing
> it after exiting the devshell.
>
> [YOCTO #7670]
>
> Signed-off-by: Christopher Larson 
>

This should probably have been an RFC, thinking about it, as I'm not
entirely happy with this implementation, but I can't think of a good
alternative, lacking a way to set unexported shell variables in the shell
spawned by the terminal, and there's no real way to do that, since we don't
know the shell the user is using. I think this is a decent alternative, if
not a pretty one. Thoughts welcome.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] subversion: 1.8.13 -> 1.8.14 since 1.8.13.tar.gz was gone

2015-09-16 Thread Burton, Ross 
On 16 September 2015 at 15:12, Robert Yang 
wrote:

> -SRC_URI = "${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
> +SRC_URI = "http://archive.apache.org/dist/${BPN}/${BP}.tar.bz2 \
>

Looking at http://www.apache.org/dist/apr/ ($APACHE_MIRROR/apr) it appears
that this latest-release-only applies to every project they release, so we
should change APACHE_MIRROR instead of just the subversion recipe.

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

Re: [OE-core] [PATCH] recipetool: add 'newappend' sub-command

2015-09-16 Thread Paul Eggleton 
Hi Chris,

On Tuesday 15 September 2015 20:57:46 Christopher Larson wrote:
> This sub-command creates a bbappend for the specified target and prints the
> path to the bbappend. The -w argument, as with some of the other recipetool
> commands, will make a version-independent bbappend.
> 
> Example usage: recipetool newappend meta-mylayer virtual/kernel
> 
> [YOCTO #7964]
> 
> Signed-off-by: Christopher Larson 
> ---
>  scripts/lib/recipetool/newappend.py | 126
>  1 file changed, 126 insertions(+)
>  create mode 100644 scripts/lib/recipetool/newappend.py
> 
> diff --git a/scripts/lib/recipetool/newappend.py
> b/scripts/lib/recipetool/newappend.py new file mode 100644
> index 000..be9077c
> --- /dev/null
> +++ b/scripts/lib/recipetool/newappend.py
> @@ -0,0 +1,126 @@
> +# Recipe creation tool - newappend plugin
> +#
> +# This sub-command creates a bbappend for the specified target and prints
> the +# path to the bbappend.
> +#
> +# Example: recipetool newappend meta-mylayer busybox
> +#
> +# Copyright (C) 2015 Christopher Larson 
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License version 2 as
> +# published by the Free Software Foundation.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License along
> +# with this program; if not, write to the Free Software Foundation, Inc.,
> +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> +
> +import argparse
> +import errno
> +import logging
> +import os
> +import re
> +
> +
> +logger = logging.getLogger('recipetool')
> +tinfoil = None
> +
> +
> +def plugin_init(pluginlist):
> +# Don't need to do anything here right now, but plugins must have this
> function defined +pass
> +
> +
> +def tinfoil_init(instance):
> +global tinfoil
> +tinfoil = instance
> +
> +
> +def _provide_to_pn(cooker, provide):
> +"""Get the name of the preferred recipe for the specified provide."""
> +import bb.providers
> +filenames = cooker.recipecache.providers[provide]
> +eligible, foundUnique = bb.providers.filterProviders(filenames,
> provide, cooker.expanded_data, cooker.recipecache) +filename =
> eligible[0]
> +pn = cooker.recipecache.pkg_fn[filename]
> +return pn
> +
> +
> +def _get_recipe_file(cooker, pn):
> +import oe.recipeutils
> +recipefile = oe.recipeutils.pn_to_recipe(cooker, pn)
> +if not recipefile:
> +skipreasons = oe.recipeutils.get_unavailable_reasons(cooker, pn)
> +if skipreasons:
> +logger.error('\n'.join(skipreasons))
> +else:
> +logger.error("Unable to find any recipe file matching %s" % pn)
> +return recipefile
> +
> +
> +def layer(layerpath):
> +if not os.path.exists(os.path.join(layerpath, 'conf', 'layer.conf')):
> +raise argparse.ArgumentTypeError('{0!r} must be a path to a valid
> layer'.format(layerpath)) +return layerpath
> +
> +
> +def newappend(args):
> +pn = _provide_to_pn(tinfoil.cooker, args.target)
> +recipe_path = _get_recipe_file(tinfoil.cooker, pn)
> +
> +# Map recipe path to the layer it's in
> +for layerpath in tinfoil.config_data.getVar('BBLAYERS', True).split():
> +layerconf = os.path.join(layerpath, 'conf', 'layer.conf')
> +l = bb.data.init()
> +l.setVar('LAYERDIR', layerpath)
> +l = bb.parse.handle(layerconf, l)
> +l.expandVarref('LAYERDIR')
> +
> +for layername in l.getVar('BBFILE_COLLECTIONS', True).split():
> +pattern = l.getVar('BBFILE_PATTERN_' + layername, True)
> +if pattern and re.match(pattern, recipe_path):
> +recipe_layer_path = layerpath
> +break
> +else:
> +continue
> +break
> +else:
> +recipe_layer_path =
> os.path.dirname(os.path.dirname(os.path.dirname(recipe_path))) +
> +recipe_relpath = os.path.relpath(recipe_path, recipe_layer_path)
> +append_relpath = recipe_relpath + 'append'
> +append_path = os.path.join(args.destlayer, append_relpath)
> +
> +if args.wildcard_version and '_' in os.path.basename(append_path):
> +base, _ = os.path.splitext(append_path)
> +base, _ = base.rsplit('_', 1)
> +append_path = base + '_%.bbappend'
> +
> +if not os.path.exists(append_path):
> +try:
> +os.makedirs(os.path.dirname(append_path))
> +except OSError as exc:
> +if exc.errno != errno.EEXIST:
> +raise
> +
> +try:
> +open(append_path, 'a')
> +except (OSError, IOError) as exc:
> +

Re: [OE-core] [PATCH] recipetool: add 'newappend' sub-command

2015-09-16 Thread Christopher Larson 
On Wed, Sep 16, 2015 at 8:21 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> Hi Chris,
>
> On Tuesday 15 September 2015 20:57:46 Christopher Larson wrote:
> > This sub-command creates a bbappend for the specified target and prints
> the
> > path to the bbappend. The -w argument, as with some of the other
> recipetool
> > commands, will make a version-independent bbappend.
> >
> > Example usage: recipetool newappend meta-mylayer virtual/kernel
> >
> > [YOCTO #7964]
> >
> > Signed-off-by: Christopher Larson 
> > ---
> >  scripts/lib/recipetool/newappend.py | 126
> >  1 file changed, 126 insertions(+)
> >  create mode 100644 scripts/lib/recipetool/newappend.py
> >
> > diff --git a/scripts/lib/recipetool/newappend.py
> > b/scripts/lib/recipetool/newappend.py new file mode 100644
> > index 000..be9077c
> > --- /dev/null
> > +++ b/scripts/lib/recipetool/newappend.py
> > @@ -0,0 +1,126 @@
> > +# Recipe creation tool - newappend plugin
> > +#
> > +# This sub-command creates a bbappend for the specified target and
> prints
> > the +# path to the bbappend.
> > +#
> > +# Example: recipetool newappend meta-mylayer busybox
> > +#
> > +# Copyright (C) 2015 Christopher Larson 
> > +#
> > +# This program is free software; you can redistribute it and/or modify
> > +# it under the terms of the GNU General Public License version 2 as
> > +# published by the Free Software Foundation.
> > +#
> > +# This program is distributed in the hope that it will be useful,
> > +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > +# GNU General Public License for more details.
> > +#
> > +# You should have received a copy of the GNU General Public License
> along
> > +# with this program; if not, write to the Free Software Foundation,
> Inc.,
> > +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > +
> > +import argparse
> > +import errno
> > +import logging
> > +import os
> > +import re
> > +
> > +
> > +logger = logging.getLogger('recipetool')
> > +tinfoil = None
> > +
> > +
> > +def plugin_init(pluginlist):
> > +# Don't need to do anything here right now, but plugins must have
> this
> > function defined +pass
> > +
> > +
> > +def tinfoil_init(instance):
> > +global tinfoil
> > +tinfoil = instance
> > +
> > +
> > +def _provide_to_pn(cooker, provide):
> > +"""Get the name of the preferred recipe for the specified
> provide."""
> > +import bb.providers
> > +filenames = cooker.recipecache.providers[provide]
> > +eligible, foundUnique = bb.providers.filterProviders(filenames,
> > provide, cooker.expanded_data, cooker.recipecache) +filename =
> > eligible[0]
> > +pn = cooker.recipecache.pkg_fn[filename]
> > +return pn
> > +
> > +
> > +def _get_recipe_file(cooker, pn):
> > +import oe.recipeutils
> > +recipefile = oe.recipeutils.pn_to_recipe(cooker, pn)
> > +if not recipefile:
> > +skipreasons = oe.recipeutils.get_unavailable_reasons(cooker, pn)
> > +if skipreasons:
> > +logger.error('\n'.join(skipreasons))
> > +else:
> > +logger.error("Unable to find any recipe file matching %s" %
> pn)
> > +return recipefile
> > +
> > +
> > +def layer(layerpath):
> > +if not os.path.exists(os.path.join(layerpath, 'conf',
> 'layer.conf')):
> > +raise argparse.ArgumentTypeError('{0!r} must be a path to a
> valid
> > layer'.format(layerpath)) +return layerpath
> > +
> > +
> > +def newappend(args):
> > +pn = _provide_to_pn(tinfoil.cooker, args.target)
> > +recipe_path = _get_recipe_file(tinfoil.cooker, pn)
> > +
> > +# Map recipe path to the layer it's in
> > +for layerpath in tinfoil.config_data.getVar('BBLAYERS',
> True).split():
> > +layerconf = os.path.join(layerpath, 'conf', 'layer.conf')
> > +l = bb.data.init()
> > +l.setVar('LAYERDIR', layerpath)
> > +l = bb.parse.handle(layerconf, l)
> > +l.expandVarref('LAYERDIR')
> > +
> > +for layername in l.getVar('BBFILE_COLLECTIONS', True).split():
> > +pattern = l.getVar('BBFILE_PATTERN_' + layername, True)
> > +if pattern and re.match(pattern, recipe_path):
> > +recipe_layer_path = layerpath
> > +break
> > +else:
> > +continue
> > +break
> > +else:
> > +recipe_layer_path =
> > os.path.dirname(os.path.dirname(os.path.dirname(recipe_path))) +
> > +recipe_relpath = os.path.relpath(recipe_path, recipe_layer_path)
> > +append_relpath = recipe_relpath + 'append'
> > +append_path = os.path.join(args.destlayer, append_relpath)
> > +
> > +if args.wildcard_version and '_' in os.path.basename(append_path):
> > +base, _ = os.path.splitext(append_path)
> > +base, _ = base.rsplit('_', 1)
> > +append_path = base +

Re: [OE-core] How to put a correct dependency with regards to gcc?

2015-09-16 Thread Richard Purdie 
On Fri, 2015-09-04 at 17:03 +, Reshetova, Elena wrote:
> I have a simple problem but not able to come with simple and elegant
> solution for it, so would be very thankful for the suggestions. 
>  
> I have a task that is specified to run after do_fetch. The task needs
> the source to be *actually* fetched, since it operates on archives. It
> works well for everything apart gcc. 
>
> For example in fido branch, my task run for libgcc will fail, because
> do_fetch task for libgcc actually *does not* not fetch the gcc sources
> (only puts a nice lock file in the download folder).
>  
> When I noticed this, I tried to put the dependency on
> gcc-source:do_fetch for my task (because that actually fetches the gcc
> sources) and it works in fido, but in master after changes to gcc
> nothing provides gcc-source and it wants to specify the version, which
> I don’t want to do (ideally I don’t want to put any dependencies to
> gcc, since I don’t really depend on it!). In master a run for
> libgcc-initial fails for the same reasons: gcc tar ball is not there. 
>  
> Is there a way to make it work correctly? 

We could change gcc-shared-work.inc to add:

do_fetch[depends] += "gcc-source-${PV}:do_fetch"

which I think might fix the issues you're seeing. The good news is that
gcc is pretty unique in this regard so you shouldn't see the issue
anywhere else.

I'm also wondering whether we simply should set SRC_URI to be empty
here. The source is fetched, unpacked and patched as part of the
gcc-source recipe. Your code should only really analyse the copy in
gcc-source, its the same source used by all the different gcc variants.

Cheers,

Richard


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

Re: [OE-core] How to put a correct dependency with regards to gcc?

2015-09-16 Thread Richard Purdie 
On Tue, 2015-09-15 at 22:37 -0400, Randy MacLeod wrote:
> I haven't been able to come up with a scheme that works yet.
> With the patch below, I get:
> 
> I'll need someone to explain the intent of the gcc-* pkgs
> design or more time to dig though the files and history.
> 
> Robert tells me that my idea that I need a bitbake rule to:
>   " call the parent implementation or
> if there isn't one, return success."
> has been discussed before and it is not easy to do.
> 
> For me, this is "a nice to have" feature that could wait
> for oe-core-2.1.

The idea is quite simple. Rather than having a copy of the gcc source
for each recipe variant (-cross-initial, -cross, -crosssdk-initial,
-crosssdk, -cross-canadian etc.) we have a single copy of the source.

We tried an older shared stamp scheme which was fragile and prone to
weird failures.  Instead we created the gcc-source recipe which is
responsible for the fetch/unpack/patch/preconfigure and then each recipe
can work off the shared source (and has a dependency on gcc-source).

For Elena's use case, I therefore think it might be better to analyse
the shared source once and not in the case of each recipe (e.g. if
SRC_URI is empty).

Cheers,

Richard



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

[OE-core] [PATCHv2] recipetool: add 'newappend' sub-command

2015-09-16 Thread Christopher Larson 
This sub-command creates a bbappend for the specified target and prints the
path to the bbappend. The -w argument, as with some of the other recipetool
commands, will make a version-independent bbappend.

Example usage: recipetool newappend meta-mylayer virtual/kernel

[YOCTO #7964]

Signed-off-by: Christopher Larson 
---
 scripts/lib/recipetool/newappend.py | 111 
 1 file changed, 111 insertions(+)
 create mode 100644 scripts/lib/recipetool/newappend.py

diff --git a/scripts/lib/recipetool/newappend.py 
b/scripts/lib/recipetool/newappend.py
new file mode 100644
index 000..77b74cb
--- /dev/null
+++ b/scripts/lib/recipetool/newappend.py
@@ -0,0 +1,111 @@
+# Recipe creation tool - newappend plugin
+#
+# This sub-command creates a bbappend for the specified target and prints the
+# path to the bbappend.
+#
+# Example: recipetool newappend meta-mylayer busybox
+#
+# Copyright (C) 2015 Christopher Larson 
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+import argparse
+import errno
+import logging
+import os
+import re
+import sys
+
+
+logger = logging.getLogger('recipetool')
+tinfoil = None
+
+
+def plugin_init(pluginlist):
+# Don't need to do anything here right now, but plugins must have this 
function defined
+pass
+
+
+def tinfoil_init(instance):
+global tinfoil
+tinfoil = instance
+
+
+def _provide_to_pn(cooker, provide):
+"""Get the name of the preferred recipe for the specified provide."""
+import bb.providers
+filenames = cooker.recipecache.providers[provide]
+eligible, foundUnique = bb.providers.filterProviders(filenames, provide, 
cooker.expanded_data, cooker.recipecache)
+filename = eligible[0]
+pn = cooker.recipecache.pkg_fn[filename]
+return pn
+
+
+def _get_recipe_file(cooker, pn):
+import oe.recipeutils
+recipefile = oe.recipeutils.pn_to_recipe(cooker, pn)
+if not recipefile:
+skipreasons = oe.recipeutils.get_unavailable_reasons(cooker, pn)
+if skipreasons:
+logger.error('\n'.join(skipreasons))
+else:
+logger.error("Unable to find any recipe file matching %s" % pn)
+return recipefile
+
+
+def layer(layerpath):
+if not os.path.exists(os.path.join(layerpath, 'conf', 'layer.conf')):
+raise argparse.ArgumentTypeError('{0!r} must be a path to a valid 
layer'.format(layerpath))
+return layerpath
+
+
+def newappend(args):
+import oe.recipeutils
+
+pn = _provide_to_pn(tinfoil.cooker, args.target)
+recipe_path = _get_recipe_file(tinfoil.cooker, pn)
+
+rd = tinfoil.config_data.createCopy()
+rd.setVar('FILE', recipe_path)
+append_path, path_ok = oe.recipeutils.get_bbappend_path(rd, 
args.destlayer, args.wildcard_version)
+if not append_path:
+logger.error('Unable to determine layer directory containing %s', 
recipe_path)
+return 1
+
+if not path_ok:
+logger.warn('Unable to determine correct subdirectory path for 
bbappend file - check that what %s adds to BBFILES also matches .bbappend 
files. Using %s for now, but until you fix this the bbappend will not be 
applied.', os.path.join(destlayerdir, 'conf', 'layer.conf'), 
os.path.dirname(appendpath))
+
+layerdirs = [os.path.abspath(layerdir) for layerdir in 
rd.getVar('BBLAYERS', True).split()]
+if not os.path.abspath(args.destlayer) in layerdirs:
+logger.warn('Specified layer is not currently enabled in 
bblayers.conf, you will need to add it before this bbappend will be active')
+
+if not os.path.exists(append_path):
+bb.utils.mkdirhier(os.path.dirname(append_path))
+
+try:
+open(append_path, 'a')
+except (OSError, IOError) as exc:
+logger.critical(str(exc))
+return 1
+
+print(append_path)
+
+
+def register_command(subparsers):
+parser = subparsers.add_parser('newappend',
+   help='Create a bbappend for the specified 
target in the specified layer')
+parser.add_argument('-w', '--wildcard-version', help='Use wildcard to make 
the bbappend apply to any recipe version', action='store_true')
+parser.add_argument('destlayer', help='Base directory of the destination 
layer to write the bbappend to', type=layer)
+parser.add_argument('target', help='Target recipe/provide to append')

Re: [OE-core] [PATCHv2] recipetool: add 'newappend' sub-command

2015-09-16 Thread Christopher Larson 
On Wed, Sep 16, 2015 at 10:03 AM, Christopher Larson 
wrote:

> This sub-command creates a bbappend for the specified target and prints the
> path to the bbappend. The -w argument, as with some of the other recipetool
> commands, will make a version-independent bbappend.
>
> Example usage: recipetool newappend meta-mylayer virtual/kernel
>
> [YOCTO #7964]
>
> Signed-off-by: Christopher Larson 


v2 change: as Paul suggests, uses get_bbappend_path now.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2 2/3] systemd: Upgrade 219 -> 225

2015-09-16 Thread Andreas Müller 
On Fri, Sep 11, 2015 at 2:19 AM, Khem Raj  wrote:
> Drop patches that were straight backports from upstream
>
> MIT licence was unused and dropped from systemd sources
> for more details see
> https://github.com/systemd/systemd/commit/8f1e0c5f38cdf7e401ab4d2bb93ad816d08e7715
>
> Drop gtkdoc dependency since libudev API documentation has been converted 
> from gtkdoc into man pages
> Remove packaging gudev as it has moved to separate repository outside
> systemd
>
Is anybody preparing patches for gudev (many packets in meta-oe require it)?

If not I can do so. Is the home for libgudev oe-core or better meta-oe?

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

Re: [OE-core] [PATCH V2 2/3] systemd: Upgrade 219 -> 225

2015-09-16 Thread Khem Raj 
On Wed, Sep 16, 2015 at 2:17 PM, Andreas Müller
 wrote:
> Is anybody preparing patches for gudev (many packets in meta-oe require it)?
>
> If not I can do so. Is the home for libgudev oe-core or better meta-oe?

meta-oe is better for now. I am not working on it.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] oeqa/sstatetests: Add test for nativesdk stamp invariance with MACHINE

2015-09-16 Thread Richard Purdie 
nativesdk-glbic should not rebuild when you change MACHINE but
it was. We've fixed that, now add tests to ensure this doesn't
happen again.

Rather than add yet another stamps test, extend one of the 
existing ones to cover this instead.

Signed-off-by: Richard Purdie 

diff --git a/meta/lib/oeqa/selftest/sstatetests.py 
b/meta/lib/oeqa/selftest/sstatetests.py
index 6906b21..c4efc47 100644
--- a/meta/lib/oeqa/selftest/sstatetests.py
+++ b/meta/lib/oeqa/selftest/sstatetests.py
@@ -3,6 +3,7 @@ import unittest
 import os
 import re
 import shutil
+import glob
 
 import oeqa.utils.ftools as ftools
 from oeqa.selftest.base import oeSelfTest
@@ -276,6 +277,8 @@ NATIVELSBSTRING = \"DistroB\"
 """
 The sstate checksums off allarch packages should be independent of 
whichever 
 MACHINE is set. Check this using bitbake -S.
+Also, rather than duplicate the test, check nativesdk stamps are the 
same between
+the two MACHINE values.
 """
 
 topdir = get_bb_var('TOPDIR')
@@ -286,18 +289,20 @@ TMPDIR = \"${TOPDIR}/tmp-sstatesamehash\"
 MACHINE = \"qemux86\"
 """)
 self.track_for_cleanup(topdir + "/tmp-sstatesamehash")
-bitbake("world -S none")
+bitbake("world meta-toolchain -S none")
 self.write_config("""
 TMPDIR = \"${TOPDIR}/tmp-sstatesamehash2\"
 MACHINE = \"qemuarm\"
 """)
 self.track_for_cleanup(topdir + "/tmp-sstatesamehash2")
-bitbake("world -S none")
+bitbake("world meta-toolchain -S none")
 
 def get_files(d):
 f = []
 for root, dirs, files in os.walk(d):
 for name in files:
+if "meta-environment" in root or "cross-canadian" in root:
+continue
 if "do_build" not in name:
 f.append(os.path.join(root, name))
 return f
@@ -306,3 +311,12 @@ MACHINE = \"qemuarm\"
 files2 = [x.replace("tmp-sstatesamehash2", "tmp-sstatesamehash") for x 
in files2]
 self.maxDiff = None
 self.assertItemsEqual(files1, files2)
+
+nativesdkdir = os.path.basename(glob.glob(topdir + 
"/tmp-sstatesamehash/stamps/*-nativesdk*-linux")[0])
+
+files1 = get_files(topdir + "/tmp-sstatesamehash/stamps/" + 
nativesdkdir)
+files2 = get_files(topdir + "/tmp-sstatesamehash2/stamps/" + 
nativesdkdir)
+files2 = [x.replace("tmp-sstatesamehash2", "tmp-sstatesamehash") for x 
in files2]
+self.maxDiff = None
+self.assertItemsEqual(files1, files2)
+


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

[OE-core] [PATCH] glibc: Ensure OVERRIDES doesn't influence sstate checksum

2015-09-16 Thread Richard Purdie 
Switching MACHINE was causing nativesdk-glibc to rebuild. This was
from the use of OVERRIDES in one of the functions. Exclude OVERRIDES
from the checksum to avoid this.

[patch to oe-selftest to ensure this doesn't regress follows]

Signed-off-by: Richard Purdie 

diff --git a/meta/recipes-core/glibc/glibc-ld.inc 
b/meta/recipes-core/glibc/glibc-ld.inc
index 962d666..c5f4db2 100644
--- a/meta/recipes-core/glibc/glibc-ld.inc
+++ b/meta/recipes-core/glibc/glibc-ld.inc
@@ -54,3 +54,4 @@ def glibc_dl_info(d):
 
 EGLIBC_KNOWN_INTERPRETER_NAMES = "${@glibc_dl_info(d)['ldconfig']}"
 RTLDLIST = "${@glibc_dl_info(d)['lddrewrite']}"
+glibc_dl_info[vardepsexclude] = "OVERRIDES"


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

Re: [OE-core] Migrating from Samba 3 to 4

2015-09-16 Thread Paul D. DeRocco 
> From: Paul D. DeRocco
> 
> A couple years ago, I included Samba 3 in a Yocto (Dylan 
> branch) project,
> and got it working. It included a custom smb.conf file, and an added
> usermap file. I'm doing a new version of that project using 
> the Yocto Fido
> branch, and incorporating Samba 4, whose recipe works differently.
> 
> To provide a custom smb.conf, I simply did the usual 
> .bbappend prepending
> my own files subdirectory containing the new smb.conf. The new recipe
> copies smb.conf explicitly inside a do_install_append() 
> function, so never
> looks for mine.
> 
> To provide a usermap file, I created a do_install_append() 
> that created
> the necessary subdirectories and copied the file. Worked fine.
> 
> Neither of those is working now. The final sysroot contains the stock
> smb.conf and no usermap. I'm a bitbake near-newbie, so I need 
> some help.
> Why wouldn't my do_install_append() be called? Isn't it legal 
> to have one
> in the .bb and another in the .bbappend?
> 
> And what is the now-accepted method of supplying a custom smb.conf?
> Copying it in a do_install_append(), or by running a little 
> script with
> ROOTFS_POSTPROCESS_COMMAND? Is the latter how I should be 
> doing both of
> these things?

Never mind about usermap: that was cockpit error.

I'm still left with the question: is there a "standard" way of supplying a
custom smb.conf file for Samba 4?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

[OE-core] Migrating from Samba 3 to 4

2015-09-16 Thread Paul D. DeRocco 
A couple years ago, I included Samba 3 in a Yocto (Dylan branch) project,
and got it working. It included a custom smb.conf file, and an added
usermap file. I'm doing a new version of that project using the Yocto Fido
branch, and incorporating Samba 4, whose recipe works differently.

To provide a custom smb.conf, I simply did the usual .bbappend prepending
my own files subdirectory containing the new smb.conf. The new recipe
copies smb.conf explicitly inside a do_install_append() function, so never
looks for mine.

To provide a usermap file, I created a do_install_append() that created
the necessary subdirectories and copied the file. Worked fine.

Neither of those is working now. The final sysroot contains the stock
smb.conf and no usermap. I'm a bitbake near-newbie, so I need some help.
Why wouldn't my do_install_append() be called? Isn't it legal to have one
in the .bb and another in the .bbappend?

And what is the now-accepted method of supplying a custom smb.conf?
Copying it in a do_install_append(), or by running a little script with
ROOTFS_POSTPROCESS_COMMAND? Is the latter how I should be doing both of
these things?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

[OE-core] [PATCH 1/1] bitbake.conf: update APACHE_MIRROR

2015-09-16 Thread Robert Yang 
>From Ross:
The http://www.apache.org/dist only keeps latest release, so use
http://archive.apache.org/dist, which keeps all the archives.

Signed-off-by: Robert Yang 
---
 meta/conf/bitbake.conf |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index d8a66f9..d57f921 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -566,7 +566,7 @@ BBLAYERS_FETCH_DIR ??= "${COREBASE}"
 # Download locations and utilities.
 ##
 
-APACHE_MIRROR = "http://www.apache.org/dist;
+APACHE_MIRROR = "http://archive.apache.org/dist;
 DEBIAN_MIRROR = "ftp://ftp.debian.org/debian/pool;
 GENTOO_MIRROR = "http://distfiles.gentoo.org/distfiles;
 GNOME_GIT = "git://git.gnome.org"
-- 
1.7.9.5

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

[OE-core] [PATCH 0/1] bitbake.conf: update APACHE_MIRROR

2015-09-16 Thread Robert Yang 
The following changes since commit f0189829498e30231d826c9f55aad73e622d076e:

  qemu: Update to upstream patches (2015-09-14 11:22:02 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/bbconf
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/bbconf

Robert Yang (1):
  bitbake.conf: update APACHE_MIRROR

 meta/conf/bitbake.conf |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.7.9.5

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

[OE-core] [PATCH] image.py: make sure ROOTFS_SIZE is an integer

2015-09-16 Thread Jonathan Liu 
_get_rootfs_size was returning a float in some cases (e.g. 12288.0).

Signed-off-by: Jonathan Liu 
---
 meta/lib/oe/image.py | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oe/image.py b/meta/lib/oe/image.py
index 2361955..f8aa88b 100644
--- a/meta/lib/oe/image.py
+++ b/meta/lib/oe/image.py
@@ -1,6 +1,7 @@
 from oe.utils import execute_pre_post_process
 import os
 import subprocess
+import math
 import multiprocessing
 
 
@@ -169,10 +170,7 @@ class Image(ImageDepGraph):
 base_size = size_kb * overhead_factor
 base_size = (base_size, rootfs_req_size)[base_size < rootfs_req_size] 
+ \
 rootfs_extra_space
-
-if base_size != int(base_size):
-base_size = int(base_size + 1)
-
+base_size = int(math.ceil(base_size))
 base_size += rootfs_alignment - 1
 base_size -= base_size % rootfs_alignment
 
-- 
2.5.0

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