[OE-core] [PATCH 4/4] native.bbclass: poison TARGET_CFLAGS etc for native builds

2016-02-26 Thread Andre McCurdy
TARGET_* FLAGS are never passed to the native toolchain. However,
they are exported so their values affect the checksum of every task.

Replace with fixed values to both avoid any unnecessary rebuilding
of native packages when target flags are changed (as before) and now
also to poison any accidental use of target flags with the native
toolchain.

Signed-off-by: Andre McCurdy 
---
 meta/classes/native.bbclass | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index f67ef00..34c08b2 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -26,10 +26,18 @@ TARGET_PREFIX = "${BUILD_PREFIX}"
 TARGET_CC_ARCH = "${BUILD_CC_ARCH}"
 TARGET_LD_ARCH = "${BUILD_LD_ARCH}"
 TARGET_AS_ARCH = "${BUILD_AS_ARCH}"
-TARGET_CPPFLAGS = "${BUILD_CPPFLAGS}"
-TARGET_CFLAGS = "${BUILD_CFLAGS}"
-TARGET_CXXFLAGS = "${BUILD_CXXFLAGS}"
-TARGET_LDFLAGS = "${BUILD_LDFLAGS}"
+
+# TARGET_* FLAGS are never passed to the native toolchain. However, they are
+# exported so their values affect the checksum of every task. Replace with 
fixed
+# values to both avoid any unnecessary rebuilding of native packages when 
target
+# flags are changed and to poison any accidental use of target flags with the
+# native toolchain.
+TARGET_CPPFLAGS = "--target-cppflag-never-passed-to-the-native-toolchain"
+TARGET_CFLAGS = "--target-cflag-never-passed-to-the-native-toolchain"
+TARGET_CXXFLAGS = "--target-cxxflag-never-passed-to-the-native-toolchain"
+TARGET_LDFLAGS = "--target-ldflag-never-passed-to-the-native-toolchain"
+
+# Hardcoding is OK since native always implies x86 or x86-64.
 TARGET_FPU = ""
 
 HOST_ARCH = "${BUILD_ARCH}"
-- 
1.9.1

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


[OE-core] [PATCH 2/4] grub2.inc: avoid passing -isystem to native builds

2016-02-26 Thread Andre McCurdy
grub2 creates its own set of -nostdinc / -isystem / -ffreestanding
CFLAGS and OE's default BUILD_CFLAGS (assigned to CFLAGS for native
builds) etc, conflict with that.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-bsp/grub/grub2.inc | 9 +
 1 file changed, 9 insertions(+)

diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 5a12563..0fdafd5 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -44,6 +44,15 @@ PACKAGECONFIG ??= ""
 PACKAGECONFIG[grub-mount] = "--enable-grub-mount,--disable-grub-mount,fuse"
 PACKAGECONFIG[device-mapper] = 
"--enable-device-mapper,--disable-device-mapper,lvm2"
 
+# grub2 creates its own set of -nostdinc / -isystem / -ffreestanding CFLAGS and
+# OE's default BUILD_CFLAGS (assigned to CFLAGS for native builds) etc, 
conflict
+# with that. Note that since BUILD_CFLAGS etc are not used by grub2 target
+# builds, it's safe to clear them unconditionally for both target and native.
+BUILD_CPPFLAGS = ""
+BUILD_CFLAGS = ""
+BUILD_CXXFLAGS = ""
+BUILD_LDFLAGS = ""
+
 do_configure_prepend() {
# The grub2 configure script uses variables such as TARGET_CFLAGS etc
# for its own purposes. Remove the OE versions from the environment to
-- 
1.9.1

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


[OE-core] [PATCH 1/4] grub2.inc: dont export TARGET_CFLAGS etc to grub2 configure

2016-02-26 Thread Andre McCurdy
The grub2 configure script uses variables such as TARGET_CFLAGS etc
for its own purposes. Remove the OE versions from the configure
environment to avoid conflicts.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-bsp/grub/grub2.inc | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 84a4727..5a12563 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -44,10 +44,16 @@ PACKAGECONFIG ??= ""
 PACKAGECONFIG[grub-mount] = "--enable-grub-mount,--disable-grub-mount,fuse"
 PACKAGECONFIG[device-mapper] = 
"--enable-device-mapper,--disable-device-mapper,lvm2"
 
+do_configure_prepend() {
+   # The grub2 configure script uses variables such as TARGET_CFLAGS etc
+   # for its own purposes. Remove the OE versions from the environment to
+   # avoid conflicts.
+   unset TARGET_CPPFLAGS TARGET_CFLAGS TARGET_CXXFLAGS TARGET_LDFLAGS
+}
+
 # grub and grub-efi's sysroot/${datadir}/grub/grub-mkconfig_lib are
 # conflicted, remove it since no one uses it.
 SYSROOT_PREPROCESS_FUNCS_class-target += "remove_sysroot_mkconfig_lib"
 remove_sysroot_mkconfig_lib() {
 rm -r "${SYSROOT_DESTDIR}${datadir}/grub/grub-mkconfig_lib"
 }
-
-- 
1.9.1

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


[OE-core] [PATCH 3/4] grub2.inc: drop bogus dependency on xz

2016-02-26 Thread Andre McCurdy
grub contains it's own internal lzma library. Attempting to build grub against
the system liblzma shared library or header files is not likely to end well.

This change does not cause a floating dependency since all grub2.inc based
recipes pass "--enable-liblzma=no" to configure.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-bsp/grub/grub2.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 0fdafd5..12cff4f 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -31,7 +31,7 @@ SRC_URI = "ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \

file://0001-Remove-direct-_llseek-code-and-require-long-filesyst.patch \
 "
 
-DEPENDS = "flex-native bison-native xz"
+DEPENDS = "flex-native bison-native"
 
 SRC_URI[md5sum] = "e927540b6eda8b024fb0391eeaa4091c"
 SRC_URI[sha256sum] = 
"65b39a0558f8c802209c574f4d02ca263a804e8a564bc6caf1cd0fd3b3cc11e3"
-- 
1.9.1

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


[OE-core] [PATCH 0/4] poison TARGET_CFLAGS etc for native builds

2016-02-26 Thread Andre McCurdy
The first patch fixes known problems with grub-efi-native
incorrectly leaking target flags into the native build.

The second and third patches fix related grub2.inc issues.

The final patch is the important change. It doesn't highlight
and new problems (ie apart from grub-efi-native) for my typical
builds, but needs wider testing.

Andre McCurdy (4):
  grub2.inc: dont export TARGET_CFLAGS etc to grub2 configure
  grub2.inc: avoid passing -isystem to native builds
  grub2.inc: drop bogus dependency on xz
  native.bbclass: poison TARGET_CFLAGS etc for native builds

 meta/classes/native.bbclass | 16 
 meta/recipes-bsp/grub/grub2.inc | 19 +--
 2 files changed, 29 insertions(+), 6 deletions(-)

-- 
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/3 v2] Upgrade RPM 5 to 5.4.16 (CVS HEAD)

2016-02-26 Thread Mark Hatle
On 2/26/16 5:11 PM, Burton, Ross wrote:
> Sorry Mark...
> 
> | In file included from ../../rpm-5.4.15/rpmio/rpmiotypes.h:8:0,
> |  from ../../rpm-5.4.15/rpmio/rpmsq.c:14:
> | ../../rpm-5.4.15/rpmio/rpmsq.c: In function '_rpm_insque':
> | ../../rpm-5.4.15/rpmio/rpmutil.h:115:30: error: '__transaction_atomic' 
> without
> transactional memory support enabled
> |  #  define RPM_GNUC_TM_ATOMIC __transaction_atomic /* XXX [[outer]] */
> |   ^
> | ../../rpm-5.4.15/rpmio/rpmsq.c:70:3: note: in expansion of macro
> 'RPM_GNUC_TM_ATOMIC'
> |RPM_GNUC_TM_ATOMIC {
> |^
> | ../../rpm-5.4.15/rpmio/rpmsq.c: In function '_rpm_remque':
> | ../../rpm-5.4.15/rpmio/rpmutil.h:115:30: error: '__transaction_atomic' 
> without
> transactional memory support enabled
> |  #  define RPM_GNUC_TM_ATOMIC __transaction_atomic /* XXX [[outer]] */
> |   ^
> | ../../rpm-5.4.15/rpmio/rpmsq.c:81:3: note: in expansion of macro
> 'RPM_GNUC_TM_ATOMIC'
> |RPM_GNUC_TM_ATOMIC {
> |^
> | Makefile:2167: recipe for target 'rpmsq.lo' failed
> 
> on qemux86.

I am not getting this error on qemux86.

My build configuration:

BB_VERSION= "1.29.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Fedora-23"
TARGET_SYS= "i586-oe-linux"
MACHINE   = "qemux86"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "m32 i586"
TARGET_FPU= ""
meta  = "mhatle/rpm-5.4.16:004efb3aaa973dba030847c1c8218238f0cc68c5"

The local.conf is the stock one with buildhistory and package_rpm enabled.

Which compiler do you have enabled?  I'm building with the default 5.3.0 
compiler.

Since I'm not reproducing the problem, I'd like to know what the difference in
configurations is.

--Mark

> Ross
> 
> On 26 February 2016 at 03:28, Mark Hatle  > wrote:
> 
> V2:
> Fixed three issues
> - Added Apache 2.0 license for specific mongodb code
> 
> - Switch SSE usage dynamically in rpmio/keccak.c
>   See rpm-keccak-sse-intrin.patch
> 
> - Add support for architectures that do not support sync_add_and_fetch_8
>   See rpm-atomic-ops.patch
> 
> All of those changes are made in patch 1/3.
> 
> This has been built for all of the qemu* BSPs.
> 
> V1:
> There is not yet an official RPM 5.4.16 release, however one will be 
> coming
> soon.  Until then, 4 distinct patches are used to upgrade RPM 5.4.15 to
> 5.4.16.  These patches are part of the commit (compressed w/ .xz).  
> However
> I am not sending them as part of the email as it's not very interesting
> to review base64.  :P
> 
> Many of the OE patches have been sent to the RPM 5 maintainer, and may be
> part of the official 5.4.16 release.  When that release happens I expect a
> simple rebase to remove the unnecessary patches.
> 
> The following changes since commit 
> 205b446f3fc4a9885179a66a8dab9d81bcc63dca:
> 
>   uclibc: Do not use immediate expansion operator (2016-02-22 20:42:34 
> +)
> 
> are available in the git repository at:
> 
>   git://git.openembedded.org/openembedded-core-contrib
>  mhatle/rpm-5.4.16
>  
> 
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=mhatle/rpm-5.4.16
> 
> Mark Hatle (3):
>   rpm: Uprev to rpm-5.4.16 (pre) and rpm-5.4+cvs to current CVS head
>   rpm: Enable specific crypto and digest settings via variables
>   rpm: A number of the patches have been submitted upstream
> 
>  meta/lib/oe/package_manager.py |   14 +-
>  .../rpm/rpm/0001-define-EM_AARCH64.patch   |2 +-
>  ...arseArgvString-to-parse-the-_gpg_check_pa.patch |2 +-
>  .../rpm/rpm/beecrypt-5.4.15-to-5.4.16.patch.gz |  Bin 0 -> 42815 
> bytes
>  meta/recipes-devtools/rpm/rpm/debugedit-segv.patch |   48 +-
>  ...debugedit-valid-file-to-fix-segment-fault.patch |2 +-
>  .../rpm/rpm/fstack-protector-configure-check.patch |   21 -
>  .../rpm/rpm/header-include-fix.patch   |   12 +-
>  .../rpm/rpm/lua-5.4.15-to-5.4.16.patch.gz  |  Bin 0 -> 269940 
> bytes
>  .../rpm/rpm/makefile-am-exec-hook.patch|2 +-
>  .../rpm/rpm/python-rpm-rpmsense.patch  |   32 +-
>  .../rpm/rpm/rpm-5.4.15-to-5.4.16.patch.gz  |  Bin 0 -> 2239384 
> bytes
>  meta/recipes-devtools/rpm/rpm/rpm-atomic-ops.patch |   73 ++
>  meta/recipes-devtools/rpm/rpm/rpm-canonarch.patch  |2 +-
>  meta/recipes-devtools/rpm/rpm/rpm-db5-or-db6.patch |   39 +-
>  meta/recipes-devtools/rpm/rpm/rpm-db60.patch   |   56 +
>  .../rpm/rpm/rpm-disable-Wno-override-init.patch|   32 -
>  .../rpm/rpm/rpm-disable-auto-stack-protector.patch |   32 +
>  .../rpm/rpm/rpm-fix-logio-cp.patch |2 +-

Re: [OE-core] [yocto] Yocto Project Status WW09

2016-02-26 Thread Christopher Larson
This is the sort of case where it'd be nice if bitbake provided a plugin
mechanism, pure python, no metadata parsing. Something to think about in
the long term..
On Fri, Feb 26, 2016 at 1:59 PM Burton, Ross  wrote:

>
> On 26 February 2016 at 20:16, Philip Balister  wrote:
>
>> I must admit, I'm surprised this is tricky. I look forward to seeing
>> what needs doing. Hopefully, it shows me things I can avoid in my work.
>>
>
> The moral of the story is don't rename layers if you want to maintain a
> semblance of migration.  Renaming meta-yocto to meta-poky means the
> bblayers.conf is invalid, so the migration code can't run because bitbake
> aborts too early.
>
> Ross
> --
> ___
> 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 0/3 v2] Upgrade RPM 5 to 5.4.16 (CVS HEAD)

2016-02-26 Thread Burton, Ross
Sorry Mark...

| In file included from ../../rpm-5.4.15/rpmio/rpmiotypes.h:8:0,
|  from ../../rpm-5.4.15/rpmio/rpmsq.c:14:
| ../../rpm-5.4.15/rpmio/rpmsq.c: In function '_rpm_insque':
| ../../rpm-5.4.15/rpmio/rpmutil.h:115:30: error: '__transaction_atomic'
without transactional memory support enabled
|  #  define RPM_GNUC_TM_ATOMIC __transaction_atomic /* XXX [[outer]] */
|   ^
| ../../rpm-5.4.15/rpmio/rpmsq.c:70:3: note: in expansion of macro
'RPM_GNUC_TM_ATOMIC'
|RPM_GNUC_TM_ATOMIC {
|^
| ../../rpm-5.4.15/rpmio/rpmsq.c: In function '_rpm_remque':
| ../../rpm-5.4.15/rpmio/rpmutil.h:115:30: error: '__transaction_atomic'
without transactional memory support enabled
|  #  define RPM_GNUC_TM_ATOMIC __transaction_atomic /* XXX [[outer]] */
|   ^
| ../../rpm-5.4.15/rpmio/rpmsq.c:81:3: note: in expansion of macro
'RPM_GNUC_TM_ATOMIC'
|RPM_GNUC_TM_ATOMIC {
|^
| Makefile:2167: recipe for target 'rpmsq.lo' failed

on qemux86.

Ross

On 26 February 2016 at 03:28, Mark Hatle  wrote:

> V2:
> Fixed three issues
> - Added Apache 2.0 license for specific mongodb code
>
> - Switch SSE usage dynamically in rpmio/keccak.c
>   See rpm-keccak-sse-intrin.patch
>
> - Add support for architectures that do not support sync_add_and_fetch_8
>   See rpm-atomic-ops.patch
>
> All of those changes are made in patch 1/3.
>
> This has been built for all of the qemu* BSPs.
>
> V1:
> There is not yet an official RPM 5.4.16 release, however one will be coming
> soon.  Until then, 4 distinct patches are used to upgrade RPM 5.4.15 to
> 5.4.16.  These patches are part of the commit (compressed w/ .xz).  However
> I am not sending them as part of the email as it's not very interesting
> to review base64.  :P
>
> Many of the OE patches have been sent to the RPM 5 maintainer, and may be
> part of the official 5.4.16 release.  When that release happens I expect a
> simple rebase to remove the unnecessary patches.
>
> The following changes since commit
> 205b446f3fc4a9885179a66a8dab9d81bcc63dca:
>
>   uclibc: Do not use immediate expansion operator (2016-02-22 20:42:34
> +)
>
> are available in the git repository at:
>
>   git://git.openembedded.org/openembedded-core-contrib mhatle/rpm-5.4.16
>
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=mhatle/rpm-5.4.16
>
> Mark Hatle (3):
>   rpm: Uprev to rpm-5.4.16 (pre) and rpm-5.4+cvs to current CVS head
>   rpm: Enable specific crypto and digest settings via variables
>   rpm: A number of the patches have been submitted upstream
>
>  meta/lib/oe/package_manager.py |   14 +-
>  .../rpm/rpm/0001-define-EM_AARCH64.patch   |2 +-
>  ...arseArgvString-to-parse-the-_gpg_check_pa.patch |2 +-
>  .../rpm/rpm/beecrypt-5.4.15-to-5.4.16.patch.gz |  Bin 0 -> 42815 bytes
>  meta/recipes-devtools/rpm/rpm/debugedit-segv.patch |   48 +-
>  ...debugedit-valid-file-to-fix-segment-fault.patch |2 +-
>  .../rpm/rpm/fstack-protector-configure-check.patch |   21 -
>  .../rpm/rpm/header-include-fix.patch   |   12 +-
>  .../rpm/rpm/lua-5.4.15-to-5.4.16.patch.gz  |  Bin 0 -> 269940
> bytes
>  .../rpm/rpm/makefile-am-exec-hook.patch|2 +-
>  .../rpm/rpm/python-rpm-rpmsense.patch  |   32 +-
>  .../rpm/rpm/rpm-5.4.15-to-5.4.16.patch.gz  |  Bin 0 -> 2239384
> bytes
>  meta/recipes-devtools/rpm/rpm/rpm-atomic-ops.patch |   73 ++
>  meta/recipes-devtools/rpm/rpm/rpm-canonarch.patch  |2 +-
>  meta/recipes-devtools/rpm/rpm/rpm-db5-or-db6.patch |   39 +-
>  meta/recipes-devtools/rpm/rpm/rpm-db60.patch   |   56 +
>  .../rpm/rpm/rpm-disable-Wno-override-init.patch|   32 -
>  .../rpm/rpm/rpm-disable-auto-stack-protector.patch |   32 +
>  .../rpm/rpm/rpm-fix-logio-cp.patch |2 +-
>  .../rpm/rpm/rpm-fix-parseEmbedded.patch|   27 +
>  .../rpm/rpm/rpm-hardlink-segfault-fix.patch|2 +-
>  .../rpm/rpm/rpm-keccak-sse-intrin.patch|   27 +
>  ...ction.c-fix-file-conflicts-for-mips64-N32.patch |2 +-
>  meta/recipes-devtools/rpm/rpm/rpm-libsql-fix.patch |2 +-
>  .../rpm/rpm/rpm-lsb-compatibility.patch|2 +-
>  .../rpm/rpm/rpm-lua-fix-print.patch|  104 --
>  ...rpm-macros.in-disable-external-key-server.patch |   16 +-
>  .../rpm/rpm/rpm-mongodb-sasl.patch |   69 ++
>  meta/recipes-devtools/rpm/rpm/rpm-no-loopmsg.patch |2 +-
>  ...b-before-verifyscript-to-avoid-null-point.patch |2 +-
>  .../rpm/rpm/rpm-packageorigin.patch|2 +-
>  .../rpm/rpm/rpm-payload-use-hashed-inode.patch |   22 +-
>  .../rpm/rpm/rpm-pkgconfigdeps.patch|   10 +-
>  .../rpm/rpm/rpm-platform-file-fix.patch|2 +-
>  meta/recipes-devtools/rpm/rpm/rpm-platform.patch   |2 +-
>  meta/recipes-devtools/rpm/rpm/rpm-platform2.patch  |4 +-
>  

[OE-core] [PATCH 1/1] dhcp: CVE-2015-8605

2016-02-26 Thread mariano . lopez
From: Mariano Lopez 

ISC DHCP allows remote attackers to cause a denial of
service (application crash) via an invalid length field
in a UDP IPv4 packet.

Signed-off-by: Mariano Lopez 
---
 .../dhcp/dhcp/CVE-2015-8605.patch  | 99 ++
 meta/recipes-connectivity/dhcp/dhcp_4.3.3.bb   |  1 +
 2 files changed, 100 insertions(+)
 create mode 100644 meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch

diff --git a/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch 
b/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch
new file mode 100644
index 000..923d5d5
--- /dev/null
+++ b/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch
@@ -0,0 +1,99 @@
+Solves CVE-2015-8605 that caused DoS when an invalid lenght field in IPv4 UDP
+was recived by the server.
+
+Upstream-Status: Backport
+CVE: CVE-2015-8605
+
+Signed-off-by: Mariano Lopez 
+
+===
+diff --git a/common/packet.c b/common/packet.c
+index b530432..e600e37 100644
+--- a/common/packet.c
 b/common/packet.c
+@@ -220,7 +220,28 @@ ssize_t decode_hw_header (interface, buf, bufix, from)
+   }
+ }
+ 
+-/* UDP header and IP header decoded together for convenience. */
++/*!
++ *
++ * \brief UDP header and IP header decoded together for convenience.
++ *
++ * Attempt to decode the UDP and IP headers and, if necessary, checksum
++ * the packet.
++ *
++ * \param inteface - the interface on which the packet was recevied
++ * \param buf - a pointer to the buffer for the received packet
++ * \param bufix - where to start processing the buffer, previous
++ *routines may have processed parts of the buffer already
++ * \param from - space to return the address of the packet sender
++ * \param buflen - remaining length of the buffer, this will have been
++ * decremented by bufix by the caller
++ * \param rbuflen - space to return the length of the payload from the udp
++ *  header
++ * \param csum_ready - indication if the checksum is valid for use
++ * non-zero indicates the checksum should be validated
++ *
++ * \return - the index to the first byte of the udp payload (that is the
++ *   start of the DHCP packet
++ */
+ 
+ ssize_t
+ decode_udp_ip_header(struct interface_info *interface,
+@@ -231,7 +252,7 @@ decode_udp_ip_header(struct interface_info *interface,
+   unsigned char *data;
+   struct ip ip;
+   struct udphdr udp;
+-  unsigned char *upp, *endbuf;
++  unsigned char *upp;
+   u_int32_t ip_len, ulen, pkt_len;
+   static unsigned int ip_packets_seen = 0;
+   static unsigned int ip_packets_bad_checksum = 0;
+@@ -241,11 +262,8 @@ decode_udp_ip_header(struct interface_info *interface,
+   static unsigned int udp_packets_length_overflow = 0;
+   unsigned len;
+ 
+-  /* Designate the end of the input buffer for bounds checks. */
+-  endbuf = buf + bufix + buflen;
+-
+   /* Assure there is at least an IP header there. */
+-  if ((buf + bufix + sizeof(ip)) > endbuf)
++  if (sizeof(ip) > buflen)
+ return -1;
+ 
+   /* Copy the IP header into a stack aligned structure for inspection.
+@@ -257,13 +275,17 @@ decode_udp_ip_header(struct interface_info *interface,
+   ip_len = (*upp & 0x0f) << 2;
+   upp += ip_len;
+ 
+-  /* Check the IP packet length. */
++  /* Check packet lengths are within the buffer:
++   * first the ip header (ip_len)
++   * then the packet length from the ip header (pkt_len)
++   * then the udp header (ip_len + sizeof(udp)
++   * We are liberal in what we accept, the udp payload should fit within
++   * pkt_len, but we only check against the full buffer size.
++   */
+   pkt_len = ntohs(ip.ip_len);
+-  if (pkt_len > buflen)
+-  return -1;
+-
+-  /* Assure after ip_len bytes that there is enough room for a UDP header. */
+-  if ((upp + sizeof(udp)) > endbuf)
++  if ((ip_len > buflen) ||
++  (pkt_len > buflen) ||
++  ((ip_len + sizeof(udp)) > buflen))
+ return -1;
+ 
+   /* Copy the UDP header into a stack aligned structure for inspection. */
+@@ -284,7 +306,8 @@ decode_udp_ip_header(struct interface_info *interface,
+   return -1;
+ 
+   udp_packets_length_checked++;
+-  if ((upp + ulen) > endbuf) {
++  /* verify that the payload length from the udp packet fits in the buffer */
++  if ((ip_len + ulen) > buflen) {
+   udp_packets_length_overflow++;
+   if (((udp_packets_length_checked > 4) &&
+(udp_packets_length_overflow != 0)) &&
diff --git a/meta/recipes-connectivity/dhcp/dhcp_4.3.3.bb 
b/meta/recipes-connectivity/dhcp/dhcp_4.3.3.bb
index 6fcdddc..ee1e082 100644
--- a/meta/recipes-connectivity/dhcp/dhcp_4.3.3.bb
+++ b/meta/recipes-connectivity/dhcp/dhcp_4.3.3.bb
@@ -6,6 +6,7 @@ SRC_URI += "file://dhcp-3.0.3-dhclient-dbus.patch;striplevel=0 \
 file://fixsepbuild.patch \
 

[OE-core] [jethro] 'wic' image support critical fixes

2016-02-26 Thread Otavio Salvador
Hello folks,

[Cced Robert Yang]

I would like to propuse the backport of following changes:

Author: Mariano Lopez 
Date:   Wed Dec 30 06:52:54 2015 +

image_types.bbclass: Rebuild when WICVARS change

The procces to do a wic image is to save a file with
variables required by wic and then call wic using this
file. Because this is external to bitbake if the vars
change, the image won't be rebuild; an example of such
is IMAGE_BOOT_FILES.

This patch adds these variables to vardeps of do_rootfs
when a wic image is build. This will rebuild the image
if a variable needed by wic changes.

[YOCTO #8693]

Signed-off-by: Mariano Lopez 
Signed-off-by: Ross Burton 
(cherry picked from commit 12c54d50ed4c321dc272beb3c6cb770965c979f1)

Author: Christopher Larson 
Date:   Tue Nov 10 14:18:20 2015 -0700

image_types: improve wks path specification

Hardcoding a full input path with zero flexibility goes against
everything the
Yocto Project is about. Rework it to let the user specify the wks base
filename with WKS_FILE and it'll search the layers for the wks file and use
it.

Signed-off-by: Christopher Larson 
Signed-off-by: Ross Burton 
(cherry picked from commit 8cc7f5229f5447c2183ac319dd52c7ed737ec89b)

Author: Noor Ahsan 
Date:   Wed Dec 23 15:50:35 2015 +0200

wic: rawcopy: Copy source file to build folder

When a file is given using --sourceparams then wic directly use that file
instead of copying them to build folder. At time of assembling it os.rename
is called which renames all the files to name. In that process the original
file is renamed. When image recipe is rebuilt then wic complains about
missing file which was renamed in previous build.

[YOCTO #8854]

Signed-off-by: Ed Bartosh 
Signed-off-by: Ross Burton 
(cherry picked from commit 33c52b1f2d39feb641465bf42e8b16d0ab22a316)

Those improve the 'wic' image support on Jethro and are merged into
master for a while. Could those be backported?

-- 
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] harfbuzz: update 1.2.1 -> 1.2.3

2016-02-26 Thread Andre McCurdy
Overview of changes leading to 1.2.3
Thursday, February 25, 2016


- Blacklist GDEF table of certain versions of Times New Roman (Bold) Italic,
  due to bug in glyph class of ASCII double-quote character.  This should
  address "regression" introduced in 1.2.0 when we switched mark zeroing
  in most shapers from BY_UNICODE_LATE to BY_GDEF_LATE.
  This fourth release in a week should finally stablize things...

- hb-ot-font's get_glyph() implementation saw some optimizations.  Though,
  might be really hard to measure in real-world situations.

- Also, two rather small API changes:

We now disable some time-consuming internal bookkeeping if built with NDEBUG
defined.  This is a first time that we use NDEBUG to disable debug code.  If
there exist production systems that do NOT want to enable NDEBUG, please let
me know and I'll add HB_NDEBUG.

Added get_nominal_glyph() and get_variation_glyph() instead of get_glyph()

New API:
- hb_font_get_nominal_glyph_func_t
- hb_font_get_variation_glyph_func_t
- hb_font_funcs_set_nominal_glyph_func()
- hb_font_funcs_set_variation_glyph_func()
- hb_font_get_nominal_glyph()
- hb_font_get_variation_glyph()

Deprecated API:
- hb_font_get_glyph_func_t
- hb_font_funcs_set_glyph_func()

Clients that implement their own font-funcs are encouraged to replace
their get_glyph() implementation with a get_nominal_glyph() and
get_variation_glyph() pair.  The variation version can assume that
variation_selector argument is not zero.  Old (deprecated) functions
will continue working indefinitely using internal gymnastics; it is
just more efficient to use the new functions.

Overview of changes leading to 1.2.2
Wednesday, February 24, 2016


- Fix regression with mark positioning with fonts that have
  non-zero mark advances.  This was introduced in 1.2.0 while
  trying to make mark and cursive attachments to work together.
  I have partially reverted that, so this version is much more
  like what we had before.  All clients who updated to 1.2.0
  should update to this version.

Signed-off-by: Andre McCurdy 
---
 .../harfbuzz/{harfbuzz_1.2.1.bb => harfbuzz_1.2.3.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/harfbuzz/{harfbuzz_1.2.1.bb => harfbuzz_1.2.3.bb} 
(88%)

diff --git a/meta/recipes-graphics/harfbuzz/harfbuzz_1.2.1.bb 
b/meta/recipes-graphics/harfbuzz/harfbuzz_1.2.3.bb
similarity index 88%
rename from meta/recipes-graphics/harfbuzz/harfbuzz_1.2.1.bb
rename to meta/recipes-graphics/harfbuzz/harfbuzz_1.2.3.bb
index fead2d3..cfe885f 100644
--- a/meta/recipes-graphics/harfbuzz/harfbuzz_1.2.1.bb
+++ b/meta/recipes-graphics/harfbuzz/harfbuzz_1.2.3.bb
@@ -12,8 +12,8 @@ DEPENDS = "glib-2.0 cairo fontconfig freetype"
 
 SRC_URI = "http://www.freedesktop.org/software/harfbuzz/release/${BP}.tar.bz2;
 
-SRC_URI[md5sum] = "c50034739e4b5ea85d46199bf7859ea6"
-SRC_URI[sha256sum] = 
"0c189aa386c5ea8d7c315adf273f56f48f412081a367b3f92abc2d0855fa2226"
+SRC_URI[md5sum] = "da8d97e262e6ef8288e1ae76369421bd"
+SRC_URI[sha256sum] = 
"8216d2404aaab7fde87be0365a90d64aa6c55928e104557cfcb37b54a096cb8c"
 
 inherit autotools pkgconfig lib_package
 
-- 
1.9.1

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


[OE-core] [PATCH] gstreamer1.0-plugins-bad.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

2016-02-26 Thread Andre McCurdy
The original over-ride is historical and no obvious issues are seen
now when building in thumb2 for Cortex A15.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
index 7b0c396..64d89b0 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
@@ -135,7 +135,8 @@ EXTRA_OECONF += " \
 
 export OPENCV_PREFIX = "${STAGING_DIR_TARGET}${prefix}"
 
-ARM_INSTRUCTION_SET = "arm"
+ARM_INSTRUCTION_SET_armv4 = "arm"
+ARM_INSTRUCTION_SET_armv5 = "arm"
 
 FILES_${PN}-dev += "${libdir}/gstreamer-${LIBV}/include/gst/gl/gstglconfig.h"
 FILES_${PN}-freeverb += "${datadir}/gstreamer-${LIBV}/presets/GstFreeverb.prs"
-- 
1.9.1

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


Re: [OE-core] [yocto] Yocto Project Status WW09

2016-02-26 Thread Burton, Ross
On 26 February 2016 at 20:16, Philip Balister  wrote:

> I must admit, I'm surprised this is tricky. I look forward to seeing
> what needs doing. Hopefully, it shows me things I can avoid in my work.
>

The moral of the story is don't rename layers if you want to maintain a
semblance of migration.  Renaming meta-yocto to meta-poky means the
bblayers.conf is invalid, so the migration code can't run because bitbake
aborts too early.

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


Re: [OE-core] [yocto] Yocto Project Status WW09

2016-02-26 Thread Philip Balister
On 02/26/2016 02:52 PM, Rudolf J Streif wrote:

 * We're about to try and transition meta-yocto within meta-yocto to

   meta-poky. The amount of pain this is causing is horrible :(.
>>>
>>> Thanks for doing this. Can you summarize the pain? Are there any
>>> important lessons here?
>>
>> The key lesson is our current "migration" code in OE-Core sucks and I
>> have some patches in progress which rewrite pieces of it in a way that
>> makes it more useful. I'm therefore trying to make some positives from
>> it.
>>
>> That said, I haven't found a way to make this work without leaving a
>> dummy layer.conf in the old location since a missing layer.conf file is
>> fatal to bitbake very early on before any migration code triggers.
>>
>> More should become clear when I post the patches, I've been holding off
>> that until I actually manage a patch set that works on the
>> autobuilder...
>>
>> Patches should be out over the weekend (in time for the freeze).
> 
> Sounds like a lot of work and potential for breaking things with little added 
> value other than a more consistent naming. What was the rationale for making 
> the change, if I may ask?

Consistent naming :) It does it make it much easier to explain what the
meta-yocto layer is for. This has been one source of a great deal of
confusion about how all the pieces come together.

I must admit, I'm surprised this is tricky. I look forward to seeing
what needs doing. Hopefully, it shows me things I can avoid in my work.

Philip

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


Re: [OE-core] [yocto] Yocto Project Status WW09

2016-02-26 Thread Rudolf J Streif
> > > 
> > > * We're about to try and transition meta-yocto within meta-yocto to
> > > 
> > >   meta-poky. The amount of pain this is causing is horrible :(.
> > 
> > Thanks for doing this. Can you summarize the pain? Are there any
> > important lessons here?
> 
> The key lesson is our current "migration" code in OE-Core sucks and I
> have some patches in progress which rewrite pieces of it in a way that
> makes it more useful. I'm therefore trying to make some positives from
> it.
> 
> That said, I haven't found a way to make this work without leaving a
> dummy layer.conf in the old location since a missing layer.conf file is
> fatal to bitbake very early on before any migration code triggers.
> 
> More should become clear when I post the patches, I've been holding off
> that until I actually manage a patch set that works on the
> autobuilder...
> 
> Patches should be out over the weekend (in time for the freeze).

Sounds like a lot of work and potential for breaking things with little added 
value other than a more consistent naming. What was the rationale for making 
the change, if I may ask?

Thanks,
:rjs

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


Re: [OE-core] Yocto Project Status WW09

2016-02-26 Thread Richard Purdie
On Fri, 2016-02-26 at 13:45 -0500, Philip Balister wrote:
> On 02/26/2016 12:36 PM, Richard Purdie wrote:
> > Current Dev Position: YP 2.1 M3
> > Next Deadline: YP 2.1 M3 Cutoff (Feature Freeze) February 29, 2016
> >  
> > SWAT team rotation: Tracy -> Alejandero
> > https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
> >  
> > Key Status/Updates:
> > * 2.1 Feature Freeze is upon us. If there is any feature you want
> > to 
> >   see in 2.1 which isn't going to make the deadline, talk to RP.
> > * We plan to release 2.1 M2 despite the sato glib issue, granting
> > an
> >   exception for the high bug and then  concentrate on 2.1 M3.
> > * 2.1 M3 build won't happen until sato glib issue resolved.
> > * Also planning to merge the gobject-introspection changes 
> > * Pseudo connection issue appears to be addressed with increased
> > retry 
> >   numbers. Tests ongoing.
> > * We're about to try and transition meta-yocto within meta-yocto to
> >   meta-poky. The amount of pain this is causing is horrible :(.
> 
> Thanks for doing this. Can you summarize the pain? Are there any
> important lessons here?

The key lesson is our current "migration" code in OE-Core sucks and I
have some patches in progress which rewrite pieces of it in a way that
makes it more useful. I'm therefore trying to make some positives from
it.

That said, I haven't found a way to make this work without leaving a
dummy layer.conf in the old location since a missing layer.conf file is
fatal to bitbake very early on before any migration code triggers.

More should become clear when I post the patches, I've been holding off
that until I actually manage a patch set that works on the
autobuilder...

Patches should be out over the weekend (in time for the freeze).

Cheers,

Richard




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


Re: [OE-core] Yocto Project Status WW09

2016-02-26 Thread Philip Balister
On 02/26/2016 12:36 PM, Richard Purdie wrote:
> Current Dev Position: YP 2.1 M3
> Next Deadline: YP 2.1 M3 Cutoff (Feature Freeze) February 29, 2016
>  
> SWAT team rotation: Tracy -> Alejandero
> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>  
> Key Status/Updates:
> * 2.1 Feature Freeze is upon us. If there is any feature you want to 
>   see in 2.1 which isn't going to make the deadline, talk to RP.
> * We plan to release 2.1 M2 despite the sato glib issue, granting an
>   exception for the high bug and then  concentrate on 2.1 M3.
> * 2.1 M3 build won't happen until sato glib issue resolved.
> * Also planning to merge the gobject-introspection changes 
> * Pseudo connection issue appears to be addressed with increased retry 
>   numbers. Tests ongoing.
> * We're about to try and transition meta-yocto within meta-yocto to 
>   meta-poky. The amount of pain this is causing is horrible :(.

Thanks for doing this. Can you summarize the pain? Are there any
important lessons here?

Philip

> * We're considering a bump in the minimum git version requirements 
>   due to the requirements of various pieces of project tooling.
> * We're rebuilding jethro 2.0.1 due to the glibc security issue, now 
>   at -rc7.
>  
> Key YP 2.1 Dates:
> YP 2.1 M2 Target release date is February 12, 2016 (Will slip a few
> weeks.)
> YP 2.1 M3 Cutoff (Feature Freeze) date is February 29, 2016 noon GMT
> YP 2.1 M3 Target release date is March 18, 2016
> YP 2.1 M4 / Final Cutoff: March 28, 2016 noon GMT - Stabilization only
> milestone.
> YP 2.1 Final Release Target: April 29, 2016
>  
> Key Status Links for YP:
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.1_Status
> https://wiki.yoctoproject.org/wiki/Yocto_2.1_Schedule
> https://wiki.yoctoproject.org/wiki/Yocto_2.1_Features
>  
> Tracking Metrics:
> WDD 2565 (last week 2585)
> (https://wiki.yoctoproject.org/charts/combo.html)
>  
> [If anyone has suggestions for other information you’d like to see on
> this weekly status update, let us know!]
>  
> Thanks,
>  
> Richard
> 
> 
> 
> 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] mirrors/own-mirrors/sanity: Updates after npm fetcher addition

2016-02-26 Thread Richard Purdie
Update the classes after the addition of the npm fetcher to
match the other fetcher additions.

Signed-off-by: Richard Purdie 

diff --git a/meta/classes/mirrors.bbclass b/meta/classes/mirrors.bbclass
index 488b86d..9e6d483 100644
--- a/meta/classes/mirrors.bbclass
+++ b/meta/classes/mirrors.bbclass
@@ -54,6 +54,7 @@ p4://.*/.*  
http://downloads.yoctoproject.org/mirror/sources/ \n \
 osc://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
 https?$://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
 ftp://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
+npm://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
 cvs://.*/.* http://sources.openembedded.org/ \n \
 svn://.*/.* http://sources.openembedded.org/ \n \
 git://.*/.* http://sources.openembedded.org/ \n \
@@ -63,6 +64,7 @@ p4://.*/.*  http://sources.openembedded.org/ \n \
 osc://.*/.* http://sources.openembedded.org/ \n \
 https?$://.*/.* http://sources.openembedded.org/ \n \
 ftp://.*/.* http://sources.openembedded.org/ \n \
+npm://.*/.* http://sources.openembedded.org/ \n \
 ${CPAN_MIRROR}  http://cpan.metacpan.org/ \n \
 ${CPAN_MIRROR}  http://search.cpan.org/CPAN/ \n \
 "
diff --git a/meta/classes/own-mirrors.bbclass b/meta/classes/own-mirrors.bbclass
index e235227..12b4267 100644
--- a/meta/classes/own-mirrors.bbclass
+++ b/meta/classes/own-mirrors.bbclass
@@ -9,4 +9,5 @@ p4://.*/.*  ${SOURCE_MIRROR_URL}
 osc://.*/.* ${SOURCE_MIRROR_URL}
 https?$://.*/.* ${SOURCE_MIRROR_URL}
 ftp://.*/.* ${SOURCE_MIRROR_URL}
+npm://.*/.* ${SOURCE_MIRROR_URL}
 }
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 31f01ca..a0553ee 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -841,7 +841,7 @@ def check_sanity_everybuild(status, d):
 mirror_vars = ['MIRRORS', 'PREMIRRORS', 'SSTATE_MIRRORS']
 protocols = ['http', 'ftp', 'file', 'https', \
  'git', 'gitsm', 'hg', 'osc', 'p4', 'svn', \
- 'bzr', 'cvs']
+ 'bzr', 'cvs', 'npm']
 for mirror_var in mirror_vars:
 mirrors = (d.getVar(mirror_var, True) or '').replace('\\n', 
'\n').split('\n')
 for mirror_entry in mirrors:


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


[OE-core] [PATCH] base: Add nodejs-native dependency for npm:// urls

2016-02-26 Thread Richard Purdie
With the addition of the npm fetcher, we add the native dependency 
handling too.

Signed-off-by: Richard Purdie 

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 1372f38..e066dc9 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -577,6 +577,9 @@ python () {
 elif scheme == "osc":
 d.appendVarFlag('do_fetch', 'depends', ' 
osc-native:do_populate_sysroot')
 
+elif scheme == "npm":
+d.appendVarFlag('do_fetch', 'depends', ' 
nodejs-native:do_populate_sysroot')
+
 # *.lz4 should DEPEND on lz4-native for unpacking
 if path.endswith('.lz4'):
 d.appendVarFlag('do_unpack', 'depends', ' 
lz4-native:do_populate_sysroot')


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


[OE-core] Yocto Project Status WW09

2016-02-26 Thread Richard Purdie
Current Dev Position: YP 2.1 M3
Next Deadline: YP 2.1 M3 Cutoff (Feature Freeze) February 29, 2016
 
SWAT team rotation: Tracy -> Alejandero
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
 
Key Status/Updates:
* 2.1 Feature Freeze is upon us. If there is any feature you want to 
  see in 2.1 which isn't going to make the deadline, talk to RP.
* We plan to release 2.1 M2 despite the sato glib issue, granting an
  exception for the high bug and then  concentrate on 2.1 M3.
* 2.1 M3 build won't happen until sato glib issue resolved.
* Also planning to merge the gobject-introspection changes 
* Pseudo connection issue appears to be addressed with increased retry 
  numbers. Tests ongoing.
* We're about to try and transition meta-yocto within meta-yocto to 
  meta-poky. The amount of pain this is causing is horrible :(.
* We're considering a bump in the minimum git version requirements 
  due to the requirements of various pieces of project tooling.
* We're rebuilding jethro 2.0.1 due to the glibc security issue, now 
  at -rc7.
 
Key YP 2.1 Dates:
YP 2.1 M2 Target release date is February 12, 2016 (Will slip a few
weeks.)
YP 2.1 M3 Cutoff (Feature Freeze) date is February 29, 2016 noon GMT
YP 2.1 M3 Target release date is March 18, 2016
YP 2.1 M4 / Final Cutoff: March 28, 2016 noon GMT - Stabilization only
milestone.
YP 2.1 Final Release Target: April 29, 2016
 
Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.1_Status
https://wiki.yoctoproject.org/wiki/Yocto_2.1_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_2.1_Features
 
Tracking Metrics:
WDD 2565 (last week 2585)
(https://wiki.yoctoproject.org/charts/combo.html)
 
[If anyone has suggestions for other information you’d like to see on
this weekly status update, let us know!]
 
Thanks,
 
Richard-- 
___
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] Another Jethro Backport

2016-02-26 Thread Javier Viguera
Could you please add this commit to the list of Jethro backports?.

--
Thanks

Javier Viguera


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


[OE-core] [jethro][PATCH] image_types_uboot: add cpio.gz.uboot to supported IMAGE_TYPES

2016-02-26 Thread Javier Viguera
From: Arnold Csorvasi 

U-Boot needs the U-Boot header in a ramdisk image to boot it.
Add this header to the cpio.gz image, so that it can be booted
with U-Boot.

Signed-off-by: Arnold Csorvasi 
Signed-off-by: Ross Burton 
---
 meta/classes/image_types_uboot.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image_types_uboot.bbclass 
b/meta/classes/image_types_uboot.bbclass
index 081bca2cc9a0..19e4aa2e4785 100644
--- a/meta/classes/image_types_uboot.bbclass
+++ b/meta/classes/image_types_uboot.bbclass
@@ -22,5 +22,5 @@ COMPRESS_CMD_bz2.u-boot  = "${COMPRESS_CMD_bz2}; 
oe_mkimage ${IMAGE_NAME}.ro
 COMPRESS_DEPENDS_lzma.u-boot = "u-boot-mkimage-native"
 COMPRESS_CMD_lzma.u-boot  = "${COMPRESS_CMD_lzma}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.lzma lzma clean"
 
-IMAGE_TYPES += "ext2.u-boot ext2.gz.u-boot ext2.bz2.u-boot ext2.lzma.u-boot 
ext3.gz.u-boot ext4.gz.u-boot"
+IMAGE_TYPES += "ext2.u-boot ext2.gz.u-boot ext2.bz2.u-boot ext2.lzma.u-boot 
ext3.gz.u-boot ext4.gz.u-boot cpio.gz.u-boot"
 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 02/29] gobject-introspection: add the recipe

2016-02-26 Thread Burton, Ross
On 26 November 2015 at 14:26, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> +# No idea why these sources are installed by upstream and how they are
> meant to be used
> +FILES_${PN}-dev_append = " ${datadir}/gobject-introspection-1.0/tests/*.c
> \
> +   ${datadir}/gobject-introspection-1.0/tests/*.h"
>

Presumably some test suite.  We certainly don't want them in the -dev
package, so until we have ptest for this lets just delete them.

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


[OE-core] [PATCH 1/1] eudev: Keep classic network interface naming scheme

2016-02-26 Thread Alejandro Hernandez
Creates an empty udev rule, causing the system to use the classic network
interface naming scheme, e. g. eth0, eth1.

Signed-off-by: Alejandro Hernandez 
---
 meta/recipes-core/udev/eudev_3.1.5.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-core/udev/eudev_3.1.5.bb 
b/meta/recipes-core/udev/eudev_3.1.5.bb
index 22021a0..4afcfdb 100644
--- a/meta/recipes-core/udev/eudev_3.1.5.bb
+++ b/meta/recipes-core/udev/eudev_3.1.5.bb
@@ -75,6 +75,9 @@ do_install_append(){
 rm -f ${D}${base_libdir}/udev/hid2hci
 
 echo 'udev_run="/var/run/udev"' >> ${D}${sysconfdir}/udev/udev.conf
+
+# Use classic network interface naming scheme
+touch ${D}${sysconfdir}/udev/rules.d/80-net-name-slot.rules
 }
 
 python () {
-- 
2.6.2

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


Re: [OE-core] [PATCH 01/29] qemu.bbclass: add qemu_wrapper_cmdline()

2016-02-26 Thread Burton, Ross
On 26 November 2015 at 14:26, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> +return "PSEUDO_UNLOAD=1 " + qemu_binary + " " + qemu_options + " -L "
> + rootfs_path\
> ++ " -E LD_LIBRARY_PATH=" + string.join(library_paths, ":") +
> " "
>

It's idiomatic to use ":".join and Python 3 has removed string.join
entirely, so can you use ":".join please.

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


Re: [OE-core] [PATCH] oeqa/selftest/buildoptions: Test build does not fail without git rev

2016-02-26 Thread Burton, Ross
On 15 February 2016 at 16:49, Daniel Istrate <
daniel.alexandrux.istr...@intel.com> wrote:

> +shutil.move(git_dir, git_dir_tmp)
>

This is a bit scary.  I think the test should use yocto-layers to create an
empty layer.

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


Re: [OE-core] [PATCH 0/4] Replaces udev with eudev for compatibility when using sysvinit on newer kernels

2016-02-26 Thread Burton, Ross
On 26 February 2016 at 15:45, Alejandro Hernandez <
alejandro.hernan...@linux.intel.com> wrote:

> Sorry, now I understand what you meant, and I see the issue, since, we
> would need to create our own naming scheme at build time, instead of runtime
>

For safety would it be best to tell eudev to use traditional names?

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


Re: [OE-core] [PATCH 0/4] Replaces udev with eudev for compatibility when using sysvinit on newer kernels

2016-02-26 Thread Alejandro Hernandez



On 02/26/2016 09:40 AM, Alejandro Hernandez wrote:



On 02/26/2016 02:24 AM, Andre McCurdy wrote:

On Thu, Feb 25, 2016 at 3:34 PM, Alejandro Hernandez
 wrote:
udev has started to fail on new kernels (4.4), due to being 
deprecated in favor
of systemd's udev implementation. To maintain a sysvinit alternative 
we also
need to provide an alternative to udev. Eudev is a fork of systemds 
udev,

this new eudev recipe provides upstream udev 220 funcitonality.

Builds OK but results in the network no longer being started
automatically at boot up - due to "eth0" now becoming "enp0s3".

Adding an entry for enp0s3 to the init-ifupdown interfaces file is a
solution. Running "touch /etc/udev/rules.d/80-net-name-slot.rules" as
suggested by the eudev Wiki (to force the interface name back eth0)
seems to work too.


I didn't have the same issue, but thanks for pointing that out, 
sending a v2 later.


   https://wiki.gentoo.org/wiki/Eudev

Is there a recommended migration path so that the primary ethernet
interface is brought up automatically, as it was before?


Not as far as I'm concerned, its matter of deciding if we should go 
with the old naming scheme or the new one, unless it was already 
decided before, I'm assuming it would be the latter.


Sorry, now I understand what you meant, and I see the issue, since, we 
would need to create our own naming scheme at build time, instead of runtime



- libgudev is not provided by eudev as it was with udev before
- We can now drop usbutils_007 since usbutils_008 is now compatible
   also with eudev, and not only with systemd's udev
- Adds new eudev package to maintainers.inc

The following changes since commit 
23056103c949b498c23b47579e8dd57ce78e6ed9:


   uclibc: Do not use immediate expansion operator (2016-02-22 
20:42:48 +)


are available in the git repository at:

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

Alejandro Hernandez (4):
   eudev: Replaces udev with eudev for compatibility when sysvinit on
 newer kernels
   libgudev: Fix for new eudev implementation
   usbutils: Fix for new eudev implementation
   maintainers.inc: Add new eudev package and change maintainership 
fore

 udev

  meta-yocto/conf/distro/include/maintainers.inc |   2 +-
  meta/conf/distro/include/default-providers.inc |   2 +-
  meta/recipes-bsp/usbutils/usbutils-008/iconv.patch |  41 
  meta/recipes-bsp/usbutils/usbutils/iconv.patch |  29 +++---
  meta/recipes-bsp/usbutils/usbutils_007.bb  |  31 --
  meta/recipes-bsp/usbutils/usbutils_008.bb  |   5 +-
  .../udev/{udev => eudev}/devfs-udev.rules  |   0
  meta/recipes-core/udev/{udev => eudev}/init|   0
  meta/recipes-core/udev/{udev => eudev}/links.conf  |   0
  meta/recipes-core/udev/{udev => eudev}/local.rules |   0
  .../udev/{udev => eudev}/permissions.rules |   0
  meta/recipes-core/udev/{udev => eudev}/run.rules   |   0
  meta/recipes-core/udev/{udev => eudev}/udev-cache  |   0
  .../udev/{udev => eudev}/udev-cache.default|   0
  meta/recipes-core/udev/{udev => eudev}/udev.rules  |   0
  meta/recipes-core/udev/eudev_3.1.5.bb  |  83 
+++
  meta/recipes-core/udev/udev.inc| 112 
-

  ...yboard_force_release.sh-shell-script-path.patch |  35 ---
  ...-Add-stdint.h-as-it-was-removed-from-mtd-.patch |  29 --
  ...c-Makefile.am-Check-for-input.h-and-input.patch |  52 --
  .../recipes-core/udev/udev/add-install-ptest.patch |  86 


  .../udev/udev/avoid-mouse-autosuspend.patch|  25 -
  .../udev/udev/fix_rule-syntax-regex-ptest.patch|  58 ---
  meta/recipes-core/udev/udev/run-ptest  |   5 -
  meta/recipes-core/udev/udev_182.bb |   9 --
  meta/recipes-gnome/libgudev/libgudev_230.bb|   3 +-
  26 files changed, 102 insertions(+), 505 deletions(-)
  delete mode 100644 meta/recipes-bsp/usbutils/usbutils-008/iconv.patch
  delete mode 100644 meta/recipes-bsp/usbutils/usbutils_007.bb
  rename meta/recipes-core/udev/{udev => eudev}/devfs-udev.rules (100%)
  rename meta/recipes-core/udev/{udev => eudev}/init (100%)
  rename meta/recipes-core/udev/{udev => eudev}/links.conf (100%)
  rename meta/recipes-core/udev/{udev => eudev}/local.rules (100%)
  rename meta/recipes-core/udev/{udev => eudev}/permissions.rules 
(100%)

  rename meta/recipes-core/udev/{udev => eudev}/run.rules (100%)
  rename meta/recipes-core/udev/{udev => eudev}/udev-cache (100%)
  rename meta/recipes-core/udev/{udev => eudev}/udev-cache.default 
(100%)

  rename meta/recipes-core/udev/{udev => eudev}/udev.rules (100%)
  create mode 100644 meta/recipes-core/udev/eudev_3.1.5.bb
  delete mode 100644 meta/recipes-core/udev/udev.inc
  delete mode 100644 

Re: [OE-core] [PATCH 0/4] Replaces udev with eudev for compatibility when using sysvinit on newer kernels

2016-02-26 Thread Alejandro Hernandez



On 02/26/2016 02:24 AM, Andre McCurdy wrote:

On Thu, Feb 25, 2016 at 3:34 PM, Alejandro Hernandez
 wrote:

udev has started to fail on new kernels (4.4), due to being deprecated in favor
of systemd's udev implementation. To maintain a sysvinit alternative we also
need to provide an alternative to udev. Eudev is a fork of systemds udev,
this new eudev recipe provides upstream udev 220 funcitonality.

Builds OK but results in the network no longer being started
automatically at boot up - due to "eth0" now becoming "enp0s3".

Adding an entry for enp0s3 to the init-ifupdown interfaces file is a
solution. Running "touch /etc/udev/rules.d/80-net-name-slot.rules" as
suggested by the eudev Wiki (to force the interface name back eth0)
seems to work too.


I didn't have the same issue, but thanks for pointing that out, sending 
a v2 later.


   https://wiki.gentoo.org/wiki/Eudev

Is there a recommended migration path so that the primary ethernet
interface is brought up automatically, as it was before?


Not as far as I'm concerned, its matter of deciding if we should go with 
the old naming scheme or the new one, unless it was already decided 
before, I'm assuming it would be the latter.



- libgudev is not provided by eudev as it was with udev before
- We can now drop usbutils_007 since usbutils_008 is now compatible
   also with eudev, and not only with systemd's udev
- Adds new eudev package to maintainers.inc

The following changes since commit 23056103c949b498c23b47579e8dd57ce78e6ed9:

   uclibc: Do not use immediate expansion operator (2016-02-22 20:42:48 +)

are available in the git repository at:

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

Alejandro Hernandez (4):
   eudev: Replaces udev with eudev for compatibility when sysvinit on
 newer kernels
   libgudev: Fix for new eudev implementation
   usbutils: Fix for new eudev implementation
   maintainers.inc: Add new eudev package and change maintainership fore
 udev

  meta-yocto/conf/distro/include/maintainers.inc |   2 +-
  meta/conf/distro/include/default-providers.inc |   2 +-
  meta/recipes-bsp/usbutils/usbutils-008/iconv.patch |  41 
  meta/recipes-bsp/usbutils/usbutils/iconv.patch |  29 +++---
  meta/recipes-bsp/usbutils/usbutils_007.bb  |  31 --
  meta/recipes-bsp/usbutils/usbutils_008.bb  |   5 +-
  .../udev/{udev => eudev}/devfs-udev.rules  |   0
  meta/recipes-core/udev/{udev => eudev}/init|   0
  meta/recipes-core/udev/{udev => eudev}/links.conf  |   0
  meta/recipes-core/udev/{udev => eudev}/local.rules |   0
  .../udev/{udev => eudev}/permissions.rules |   0
  meta/recipes-core/udev/{udev => eudev}/run.rules   |   0
  meta/recipes-core/udev/{udev => eudev}/udev-cache  |   0
  .../udev/{udev => eudev}/udev-cache.default|   0
  meta/recipes-core/udev/{udev => eudev}/udev.rules  |   0
  meta/recipes-core/udev/eudev_3.1.5.bb  |  83 +++
  meta/recipes-core/udev/udev.inc| 112 -
  ...yboard_force_release.sh-shell-script-path.patch |  35 ---
  ...-Add-stdint.h-as-it-was-removed-from-mtd-.patch |  29 --
  ...c-Makefile.am-Check-for-input.h-and-input.patch |  52 --
  .../recipes-core/udev/udev/add-install-ptest.patch |  86 
  .../udev/udev/avoid-mouse-autosuspend.patch|  25 -
  .../udev/udev/fix_rule-syntax-regex-ptest.patch|  58 ---
  meta/recipes-core/udev/udev/run-ptest  |   5 -
  meta/recipes-core/udev/udev_182.bb |   9 --
  meta/recipes-gnome/libgudev/libgudev_230.bb|   3 +-
  26 files changed, 102 insertions(+), 505 deletions(-)
  delete mode 100644 meta/recipes-bsp/usbutils/usbutils-008/iconv.patch
  delete mode 100644 meta/recipes-bsp/usbutils/usbutils_007.bb
  rename meta/recipes-core/udev/{udev => eudev}/devfs-udev.rules (100%)
  rename meta/recipes-core/udev/{udev => eudev}/init (100%)
  rename meta/recipes-core/udev/{udev => eudev}/links.conf (100%)
  rename meta/recipes-core/udev/{udev => eudev}/local.rules (100%)
  rename meta/recipes-core/udev/{udev => eudev}/permissions.rules (100%)
  rename meta/recipes-core/udev/{udev => eudev}/run.rules (100%)
  rename meta/recipes-core/udev/{udev => eudev}/udev-cache (100%)
  rename meta/recipes-core/udev/{udev => eudev}/udev-cache.default (100%)
  rename meta/recipes-core/udev/{udev => eudev}/udev.rules (100%)
  create mode 100644 meta/recipes-core/udev/eudev_3.1.5.bb
  delete mode 100644 meta/recipes-core/udev/udev.inc
  delete mode 100644 
meta/recipes-core/udev/udev/0001-Fixing-keyboard_force_release.sh-shell-script-path.patch
  delete mode 100644 
meta/recipes-core/udev/udev/0001-mtd_probe.h-Add-stdint.h-as-it-was-removed-from-mtd-.patch
  delete mode 100644 

Re: [OE-core] [PATCH 0/3] Add initial capability to check CVEs for recipes

2016-02-26 Thread Mariano Lopez


On 02/26/2016 08:57 AM, mikko.rap...@bmw.de wrote:

On Fri, Feb 26, 2016 at 03:56:24PM +0100, Mikko Rapeli wrote:

On Fri, Feb 26, 2016 at 08:48:47AM -0600, Mariano Lopez wrote:

On 02/26/2016 02:14 AM, mikko.rap...@bmw.de wrote:

Hi,

On my developer machine the cve-check ran ok for dizzy but on build server
with sstate-cache and rmwork enabled it failed with what looks like a race
condition when scanning the patch files:

17:45:36 ERROR: Error executing a python function in 
/home/builder/src/base/poky/meta/recipes-extended/mailx/mailx_12.5.bb:
17:45:36
17:45:36 The stack trace of python calls that resulted in this 
exception/failure was:
17:45:36 File: 'do_cve_check', lineno: 17, function: 
17:45:36  0013:else:
17:45:36  0014:bb.note("Failed to update CVE database, skipping CVE 
check")
17:45:36  0015:
17:45:36  0016:
17:45:36  *** 0017:do_cve_check(d)
17:45:36  0018:
17:45:37 File: 'do_cve_check', lineno: 8, function: do_cve_check
17:45:37  0004:Check recipe for patched and unpatched CVEs
17:45:37  0005:"""
17:45:37  0006:
17:45:37  0007:if os.path.exists(d.getVar("CVE_CHECK_TMP_FILE", True)):
17:45:37  *** 0008:patched_cves = get_patches_cves(d)
17:45:37  0009:patched, unpatched = check_cves(d, patched_cves)
17:45:37  0010:if patched or unpatched:
17:45:37  0011:cve_data = get_cve_info(d, patched + unpatched)
17:45:37  0012:cve_write_data(d, patched, unpatched, cve_data)
17:45:37 File: 'cve-check.bbclass', lineno: 13, function: get_patches_cves
17:45:37  0009:cve_match = re.compile("CVE:( CVE\-\d+\-\d+)+")
17:45:37  0010:patched_cves = set()
17:45:37  0011:for url in src_patches(d):
17:45:37  0012:patch_file = bb.fetch.decodeurl(url)[2]
17:45:37  *** 0013:with open(patch_file, "r") as f:
17:45:37  0014:patch_text = f.read()
17:45:37  0015:
17:45:37  0016:# Search for the "CVE: " line
17:45:37  0017:match = cve_match.search(patch_text)
17:45:37 Exception: IOError: [Errno 2] No such file or directory: 
'/home/builder/src/base/build/tmp/work/corei7-64-linux/mailx/12.5-r2/heirloom-mailx_12.5-1.diff'
17:45:37
17:45:37 ERROR: Function failed: do_cve_check

So could this be caused by cve-check changes or is this just a side effect
of some other recipe problems?

I could not see that kind of fixes in master.

-Mikko

The changes in patch series were minimal and actually this part of the code
wasn't touched at all. That part of the code will look for all the files in
the SRC_URI variable and will look for the "CVE:" tag in order to find
patches that solve CVEs.

Yep, the code seems straight forward.


It seems the problem is with the bitbake fetcher, or the recipe;
unfortunately the fetcher is one of the components that most change between
releases. Another thing to check is that if actually there is a
heirloom-mailx_12.5-1.diff file in the paths that the fetcher look for. You
can check this in the cve_check or patch log in the work directory of the
recipe.

Unfortunately the file is there if I check with devshell but I have now
four different CI runs with this failure. Only difference to my developer
machine is sstate cache. Build machines maintain their own sstate cache.

Last two runs were with v2 patches.


Would be possible to run these CI with master to check if you see the 
error too?
Also, what you can do is to put try: except:, but this won't solve the 
problem, just will hide it so the build can finish.




-Mikko


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


[OE-core] [PATCH] systemctl: handle RequiredBy dependencies

2016-02-26 Thread Tomas Novotny
Install section of a systemd service may contain RequiredBy dependency,
which is not handled currently. This means that symlinks to enable the
service are not created and the service may not be started.

Also fix debug output (all dependencies were printed instead of the one
which was enabled or disabled).

Signed-off-by: Tomas Novotny 
---
 .../systemd/systemd-systemctl/systemctl| 61 +-
 1 file changed, 37 insertions(+), 24 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd-systemctl/systemctl 
b/meta/recipes-core/systemd/systemd-systemctl/systemctl
index 697fbd5..1164dd4 100755
--- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
+++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
@@ -125,33 +125,46 @@ for service in $services; do
| tr ',' '\n' \
| grep "$unit_types_re")
 
-   for r in $wanted_by; do
-   echo "WantedBy=$r found in $service"
-   if [ "$action" = "enable" ]; then
-   enable_service=$service
-   if [ "$service_template" = true -a 
"$instance_specified" = false ]; then
-   default_instance=$(sed 
'/^DefaultInstance[[:space:]]*=/s,[^=]*=,,p;d' "$ROOT/$service_file")
-   if [ -z $default_instance ]; then
-   echo "Template unit without instance or 
DefaultInstance directive, nothing to enable"
-   continue
-   else
-   echo "Found DefaultInstance 
$default_instance, enabling it"
-   enable_service=$(echo $service | sed 
"s/@/@$(echo $default_instance | sed 's/\\//g')/")
+   required_by=$(sed '/^RequiredBy[[:space:]]*=/s,[^=]*=,,p;d' 
"$ROOT/$service_file" \
+   | tr ',' '\n' \
+   | grep "$unit_types_re")
+
+   for dependency in WantedBy RequiredBy; do
+   if [ "$dependency" = "WantedBy" ]; then
+   suffix="wants"
+   dependency_list="$wanted_by"
+   elif [ "$dependency" = "RequiredBy" ]; then
+   suffix="requires"
+   dependency_list="$required_by"
+   fi
+   for r in $dependency_list; do
+   echo "$dependency=$r found in $service"
+   if [ "$action" = "enable" ]; then
+   enable_service=$service
+   if [ "$service_template" = true -a 
"$instance_specified" = false ]; then
+   default_instance=$(sed 
'/^DefaultInstance[[:space:]]*=/s,[^=]*=,,p;d' "$ROOT/$service_file")
+   if [ -z $default_instance ]; then
+   echo "Template unit without 
instance or DefaultInstance directive, nothing to enable"
+   continue
+   else
+   echo "Found DefaultInstance 
$default_instance, enabling it"
+   enable_service=$(echo $service 
| sed "s/@/@$(echo $default_instance | sed 's/\\//g')/")
+   fi
fi
-   fi
-   mkdir -p $ROOT/etc/systemd/system/$r.wants
-   ln -s $service_file 
$ROOT/etc/systemd/system/$r.wants/$enable_service
-   echo "Enabled $enable_service for $wanted_by."
-   else
-   if [ "$service_template" = true -a 
"$instance_specified" = false ]; then
-   
disable_service="$ROOT/etc/systemd/system/$r.wants/`echo $service | sed 
's/@/@*/'`"
+   mkdir -p $ROOT/etc/systemd/system/$r.$suffix
+   ln -s $service_file 
$ROOT/etc/systemd/system/$r.$suffix/$enable_service
+   echo "Enabled $enable_service for $r."
else
-   
disable_service="$ROOT/etc/systemd/system/$r.wants/$service"
+   if [ "$service_template" = true -a 
"$instance_specified" = false ]; then
+   
disable_service="$ROOT/etc/systemd/system/$r.$suffix/`echo $service | sed 
's/@/@*/'`"
+   else
+   
disable_service="$ROOT/etc/systemd/system/$r.$suffix/$service"
+   fi
+   rm -f $disable_service
+   [ -d $ROOT/etc/systemd/system/$r.$suffix ] && 
rmdir --ignore-fail-on-non-empty -p $ROOT/etc/systemd/system/$r.$suffix
+   

Re: [OE-core] [PATCH 0/3] Add initial capability to check CVEs for recipes

2016-02-26 Thread Mikko.Rapeli
On Fri, Feb 26, 2016 at 03:56:24PM +0100, Mikko Rapeli wrote:
> On Fri, Feb 26, 2016 at 08:48:47AM -0600, Mariano Lopez wrote:
> > On 02/26/2016 02:14 AM, mikko.rap...@bmw.de wrote:
> > >Hi,
> > >
> > >On my developer machine the cve-check ran ok for dizzy but on build server
> > >with sstate-cache and rmwork enabled it failed with what looks like a race
> > >condition when scanning the patch files:
> > >
> > >17:45:36 ERROR: Error executing a python function in 
> > >/home/builder/src/base/poky/meta/recipes-extended/mailx/mailx_12.5.bb:
> > >17:45:36
> > >17:45:36 The stack trace of python calls that resulted in this 
> > >exception/failure was:
> > >17:45:36 File: 'do_cve_check', lineno: 17, function: 
> > >17:45:36  0013:else:
> > >17:45:36  0014:bb.note("Failed to update CVE database, 
> > >skipping CVE check")
> > >17:45:36  0015:
> > >17:45:36  0016:
> > >17:45:36  *** 0017:do_cve_check(d)
> > >17:45:36  0018:
> > >17:45:37 File: 'do_cve_check', lineno: 8, function: do_cve_check
> > >17:45:37  0004:Check recipe for patched and unpatched CVEs
> > >17:45:37  0005:"""
> > >17:45:37  0006:
> > >17:45:37  0007:if os.path.exists(d.getVar("CVE_CHECK_TMP_FILE", 
> > >True)):
> > >17:45:37  *** 0008:patched_cves = get_patches_cves(d)
> > >17:45:37  0009:patched, unpatched = check_cves(d, patched_cves)
> > >17:45:37  0010:if patched or unpatched:
> > >17:45:37  0011:cve_data = get_cve_info(d, patched + 
> > >unpatched)
> > >17:45:37  0012:cve_write_data(d, patched, unpatched, 
> > >cve_data)
> > >17:45:37 File: 'cve-check.bbclass', lineno: 13, function: get_patches_cves
> > >17:45:37  0009:cve_match = re.compile("CVE:( CVE\-\d+\-\d+)+")
> > >17:45:37  0010:patched_cves = set()
> > >17:45:37  0011:for url in src_patches(d):
> > >17:45:37  0012:patch_file = bb.fetch.decodeurl(url)[2]
> > >17:45:37  *** 0013:with open(patch_file, "r") as f:
> > >17:45:37  0014:patch_text = f.read()
> > >17:45:37  0015:
> > >17:45:37  0016:# Search for the "CVE: " line
> > >17:45:37  0017:match = cve_match.search(patch_text)
> > >17:45:37 Exception: IOError: [Errno 2] No such file or directory: 
> > >'/home/builder/src/base/build/tmp/work/corei7-64-linux/mailx/12.5-r2/heirloom-mailx_12.5-1.diff'
> > >17:45:37
> > >17:45:37 ERROR: Function failed: do_cve_check
> > >
> > >So could this be caused by cve-check changes or is this just a side effect
> > >of some other recipe problems?
> > >
> > >I could not see that kind of fixes in master.
> > >
> > >-Mikko
> > 
> > The changes in patch series were minimal and actually this part of the code
> > wasn't touched at all. That part of the code will look for all the files in
> > the SRC_URI variable and will look for the "CVE:" tag in order to find
> > patches that solve CVEs.
> 
> Yep, the code seems straight forward.
> 
> > It seems the problem is with the bitbake fetcher, or the recipe;
> > unfortunately the fetcher is one of the components that most change between
> > releases. Another thing to check is that if actually there is a
> > heirloom-mailx_12.5-1.diff file in the paths that the fetcher look for. You
> > can check this in the cve_check or patch log in the work directory of the
> > recipe.
> 
> Unfortunately the file is there if I check with devshell but I have now
> four different CI runs with this failure. Only difference to my developer
> machine is sstate cache. Build machines maintain their own sstate cache.

Last two runs were with v2 patches.

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


Re: [OE-core] [PATCH 0/3] Add initial capability to check CVEs for recipes

2016-02-26 Thread Mikko.Rapeli
On Fri, Feb 26, 2016 at 08:48:47AM -0600, Mariano Lopez wrote:
> On 02/26/2016 02:14 AM, mikko.rap...@bmw.de wrote:
> >Hi,
> >
> >On my developer machine the cve-check ran ok for dizzy but on build server
> >with sstate-cache and rmwork enabled it failed with what looks like a race
> >condition when scanning the patch files:
> >
> >17:45:36 ERROR: Error executing a python function in 
> >/home/builder/src/base/poky/meta/recipes-extended/mailx/mailx_12.5.bb:
> >17:45:36
> >17:45:36 The stack trace of python calls that resulted in this 
> >exception/failure was:
> >17:45:36 File: 'do_cve_check', lineno: 17, function: 
> >17:45:36  0013:else:
> >17:45:36  0014:bb.note("Failed to update CVE database, skipping 
> >CVE check")
> >17:45:36  0015:
> >17:45:36  0016:
> >17:45:36  *** 0017:do_cve_check(d)
> >17:45:36  0018:
> >17:45:37 File: 'do_cve_check', lineno: 8, function: do_cve_check
> >17:45:37  0004:Check recipe for patched and unpatched CVEs
> >17:45:37  0005:"""
> >17:45:37  0006:
> >17:45:37  0007:if os.path.exists(d.getVar("CVE_CHECK_TMP_FILE", 
> >True)):
> >17:45:37  *** 0008:patched_cves = get_patches_cves(d)
> >17:45:37  0009:patched, unpatched = check_cves(d, patched_cves)
> >17:45:37  0010:if patched or unpatched:
> >17:45:37  0011:cve_data = get_cve_info(d, patched + 
> >unpatched)
> >17:45:37  0012:cve_write_data(d, patched, unpatched, 
> >cve_data)
> >17:45:37 File: 'cve-check.bbclass', lineno: 13, function: get_patches_cves
> >17:45:37  0009:cve_match = re.compile("CVE:( CVE\-\d+\-\d+)+")
> >17:45:37  0010:patched_cves = set()
> >17:45:37  0011:for url in src_patches(d):
> >17:45:37  0012:patch_file = bb.fetch.decodeurl(url)[2]
> >17:45:37  *** 0013:with open(patch_file, "r") as f:
> >17:45:37  0014:patch_text = f.read()
> >17:45:37  0015:
> >17:45:37  0016:# Search for the "CVE: " line
> >17:45:37  0017:match = cve_match.search(patch_text)
> >17:45:37 Exception: IOError: [Errno 2] No such file or directory: 
> >'/home/builder/src/base/build/tmp/work/corei7-64-linux/mailx/12.5-r2/heirloom-mailx_12.5-1.diff'
> >17:45:37
> >17:45:37 ERROR: Function failed: do_cve_check
> >
> >So could this be caused by cve-check changes or is this just a side effect
> >of some other recipe problems?
> >
> >I could not see that kind of fixes in master.
> >
> >-Mikko
> 
> The changes in patch series were minimal and actually this part of the code
> wasn't touched at all. That part of the code will look for all the files in
> the SRC_URI variable and will look for the "CVE:" tag in order to find
> patches that solve CVEs.

Yep, the code seems straight forward.

> It seems the problem is with the bitbake fetcher, or the recipe;
> unfortunately the fetcher is one of the components that most change between
> releases. Another thing to check is that if actually there is a
> heirloom-mailx_12.5-1.diff file in the paths that the fetcher look for. You
> can check this in the cve_check or patch log in the work directory of the
> recipe.

Unfortunately the file is there if I check with devshell but I have now
four different CI runs with this failure. Only difference to my developer
machine is sstate cache. Build machines maintain their own sstate cache.

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


[OE-core] [PATCH 5/9] scripts: test-recipe Tool for running tests on recipes

2016-02-26 Thread Daniel Istrate
It shares many functionality with oe-selftest.
It requires an aditional argument --recipe 
in order to know on which recipe to test against.

Test recipes should be located at:
meta/lib/oeqa/recipetests/

Signed-off-by: Daniel Istrate 
---
 scripts/test-recipe | 168 
 1 file changed, 168 insertions(+)
 create mode 100755 scripts/test-recipe

diff --git a/scripts/test-recipe b/scripts/test-recipe
new file mode 100755
index 000..3fe80a5
--- /dev/null
+++ b/scripts/test-recipe
@@ -0,0 +1,168 @@
+#!/usr/bin/env python
+
+# Copyright (c) 2016, Intel Corporation.
+# All rights reserved.
+#
+# 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.
+#
+# DESCRIPTION: Will run recipe tests on each provided recipe.
+#
+# USAGE: recipe-test --recipes  --run-all-tests
+#
+# OPTIONS: --recipes 
+#  --list-tests
+#  --list-tests-by  
+#  --run-all-tests
+#  --run-tests-by  
+#
+# NOTE: tests are located in lib/oeqa/recipetests
+#
+# AUTHOR: Daniel Istrate 
+#
+
+
+import sys
+import os
+import unittest
+
+sys.path.insert(0, os.path.dirname(os.path.realpath(__file__)) + '/lib')
+import scriptpath
+scriptpath.add_bitbake_lib_path()
+scriptpath.add_oe_lib_path()
+import argparse_oe
+
+import oeqa.recipetests
+from oeqa.utils.commands import get_test_layer, get_bb_var, bitbake, 
is_recipe_valid
+from oeqa.selftest.base import oeSelfTest
+from oeqa.recipetests.base import RecipeTests
+
+from oeqa.runner import Runner
+
+test_runner = Runner('test-recipe', RecipeTests, oeqa.recipetests)
+log = test_runner.log
+
+
+def get_args_parser():
+description = 'Will run recipe tests on provided recipe.'
+parser = argparse_oe.ArgumentParser(description=description)
+group = parser.add_mutually_exclusive_group(required=True)
+group.add_argument('--run-tests', required=False, action='store', 
nargs='*', dest="run_tests", default=None,
+   help='Select what tests to run (modules, classes or 
test methods). '
+'Format should be: ..')
+group.add_argument('--run-all-tests', required=False, action="store_true", 
dest="run_all_tests", default=False,
+   help='Run all (unhidden) tests')
+group.add_argument('--list-modules', required=False, action="store_true", 
dest="list_modules", default=False,
+   help='List all available test modules.')
+group.add_argument('--list-classes', required=False, action="store_true", 
dest="list_allclasses", default=False,
+   help='List all available test classes.')
+parser.add_argument('--coverage', action="store_true", help="Run code 
coverage when testing")
+group.add_argument('--run-tests-by', required=False, dest='run_tests_by', 
default=False, nargs='*',
+   help='run-tests-by  ')
+group.add_argument('--list-tests-by', required=False, 
dest='list_tests_by', default=False, nargs='*',
+   help='list-tests-by  ')
+group.add_argument('--list-tests', required=False,  action="store_true", 
dest="list_tests", default=False,
+   help='List all available tests.')
+group.add_argument('--list-tags', required=False, dest='list_tags', 
default=False, action="store_true",
+   help='List all tags that have been set to test cases.')
+parser.add_argument('-r', '--recipes', nargs='+', default=False, 
dest='recipes', 
+help='recipe(s) to run tests against.')
+return parser
+
+
+def main():
+parser = get_args_parser()
+args = parser.parse_args()
+
+if args.list_tests:
+test_runner.list_tests()
+return 0
+
+if args.list_tags:
+test_runner.list_tags()
+return 0
+
+if args.list_allclasses:
+test_runner.list_all_classes()
+return 0
+
+if args.list_modules:
+test_runner.list_modules()
+return 0
+
+if args.list_tests_by and len(args.list_tests_by) >= 2:
+valid_options = ['name', 'class', 'module', 'id', 'tag']
+if args.list_tests_by[0] not in valid_options:
+print '--list-tests-by %s not a valid option. Choose one of 
.' % 

Re: [OE-core] [PATCH 0/3] Add initial capability to check CVEs for recipes

2016-02-26 Thread Mariano Lopez

On 02/26/2016 02:14 AM, mikko.rap...@bmw.de wrote:

Hi,

On my developer machine the cve-check ran ok for dizzy but on build server
with sstate-cache and rmwork enabled it failed with what looks like a race
condition when scanning the patch files:

17:45:36 ERROR: Error executing a python function in 
/home/builder/src/base/poky/meta/recipes-extended/mailx/mailx_12.5.bb:
17:45:36
17:45:36 The stack trace of python calls that resulted in this 
exception/failure was:
17:45:36 File: 'do_cve_check', lineno: 17, function: 
17:45:36  0013:else:
17:45:36  0014:bb.note("Failed to update CVE database, skipping CVE 
check")
17:45:36  0015:
17:45:36  0016:
17:45:36  *** 0017:do_cve_check(d)
17:45:36  0018:
17:45:37 File: 'do_cve_check', lineno: 8, function: do_cve_check
17:45:37  0004:Check recipe for patched and unpatched CVEs
17:45:37  0005:"""
17:45:37  0006:
17:45:37  0007:if os.path.exists(d.getVar("CVE_CHECK_TMP_FILE", True)):
17:45:37  *** 0008:patched_cves = get_patches_cves(d)
17:45:37  0009:patched, unpatched = check_cves(d, patched_cves)
17:45:37  0010:if patched or unpatched:
17:45:37  0011:cve_data = get_cve_info(d, patched + unpatched)
17:45:37  0012:cve_write_data(d, patched, unpatched, cve_data)
17:45:37 File: 'cve-check.bbclass', lineno: 13, function: get_patches_cves
17:45:37  0009:cve_match = re.compile("CVE:( CVE\-\d+\-\d+)+")
17:45:37  0010:patched_cves = set()
17:45:37  0011:for url in src_patches(d):
17:45:37  0012:patch_file = bb.fetch.decodeurl(url)[2]
17:45:37  *** 0013:with open(patch_file, "r") as f:
17:45:37  0014:patch_text = f.read()
17:45:37  0015:
17:45:37  0016:# Search for the "CVE: " line
17:45:37  0017:match = cve_match.search(patch_text)
17:45:37 Exception: IOError: [Errno 2] No such file or directory: 
'/home/builder/src/base/build/tmp/work/corei7-64-linux/mailx/12.5-r2/heirloom-mailx_12.5-1.diff'
17:45:37
17:45:37 ERROR: Function failed: do_cve_check

So could this be caused by cve-check changes or is this just a side effect
of some other recipe problems?

I could not see that kind of fixes in master.

-Mikko


The changes in patch series were minimal and actually this part of the 
code wasn't touched at all. That part of the code will look for all the 
files in the SRC_URI variable and will look for the "CVE:" tag in order 
to find patches that solve CVEs.


It seems the problem is with the bitbake fetcher, or the recipe; 
unfortunately the fetcher is one of the components that most change 
between releases. Another thing to check is that if actually there is a 
heirloom-mailx_12.5-1.diff file in the paths that the fetcher look for. 
You can check this in the cve_check or patch log in the work directory 
of the recipe.


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


[OE-core] [PATCH 3/9] selftest: Moved list_classes, list_modules, run methods to runner.py

2016-02-26 Thread Daniel Istrate
Signed-off-by: Daniel Istrate 
---
 meta/lib/oeqa/runner.py | 59 
 scripts/oe-selftest | 65 ++---
 2 files changed, 72 insertions(+), 52 deletions(-)

diff --git a/meta/lib/oeqa/runner.py b/meta/lib/oeqa/runner.py
index 5bfd4d1..e729478 100644
--- a/meta/lib/oeqa/runner.py
+++ b/meta/lib/oeqa/runner.py
@@ -344,6 +344,65 @@ class Runner:
 print 'Looking for:\t %s' % ', '.join(str(x) for x in keyword)
 print 'Total found:\t %s' % len(ts)
 
+def list_modules(self):
+""" List all available modules """
+
+self.log.info('Listing all available test modules:')
+testslist = self.get_tests(include_hidden=True)
+for test in testslist:
+module = test.split('.')[-1]
+print module + ' (hidden)' if module.startswith('_') else module
+
+def list_all_classes(self):
+""" List all tests with their corresponding class and module  
(Hierarchy format) """
+
+testslist = self.get_tests(include_hidden=True)
+for test in testslist:
+module = test.split('.')[-1]
+print module + ' (hidden)' if module.startswith('_') else module
+try:
+import importlib
+modlib = importlib.import_module(test)
+for v in vars(modlib):
+t = vars(modlib)[v]
+if isinstance(t, type(self.base_class)) and issubclass(t, 
self.base_class) and t != self.base_class:
+print " --", v
+for method in dir(t):
+if method.startswith("test_") and 
callable(vars(t)[method]):
+print " --  --", method
+
+except (AttributeError, ImportError) as e:
+print e
+pass
+
+def run(self, testlist, args):
+"""
+:param testlist: ['oeqa.selftest.archiver', 'oeqa.selftest.bblayers', 
..]
+:param args: the args the calling script was invoked with (used by 
coverage)
+"""
+
+suite = unittest.TestSuite()
+loader = unittest.TestLoader()
+loader.sortTestMethodsUsing = None
+runner = unittest.TextTestRunner(verbosity=2, 
resultclass=self.buildResultClass(args))
+
+for test in testlist:
+self.log.info("Loading tests from: %s" % test)
+try:
+suite.addTests(loader.loadTestsFromName(test))
+except AttributeError as e:
+self.log.error("Failed to import %s" % test)
+self.log.error(e)
+return 1
+
+result = runner.run(suite)
+self.log.info("Finished")
+
+if result.wasSuccessful():
+return 0
+else:
+return 1
+
 @staticmethod
 def coverage_setup(run_tests, run_all_tests):
 """ Set up the coverage measurement for the testcases to be run """
diff --git a/scripts/oe-selftest b/scripts/oe-selftest
index 9f71154..ba73502 100755
--- a/scripts/oe-selftest
+++ b/scripts/oe-selftest
@@ -27,11 +27,6 @@
 
 import os
 import sys
-import unittest
-import logging
-import argparse
-import subprocess
-import time as t
 
 sys.path.insert(0, os.path.dirname(os.path.realpath(__file__)) + '/lib')
 import scriptpath
@@ -40,8 +35,7 @@ scriptpath.add_oe_lib_path()
 import argparse_oe
 
 import oeqa.selftest
-import oeqa.utils.ftools as ftools
-from oeqa.utils.commands import runCmd, get_bb_var, get_test_layer
+from oeqa.utils.commands import get_bb_var, get_test_layer
 from oeqa.selftest.base import oeSelfTest, get_available_machines
 
 from oeqa.runner import Runner
@@ -102,40 +96,23 @@ def main():
 criteria = args.list_tests_by[0]
 keyword = args.list_tests_by[1:]
 test_runner.list_testsuite_by(criteria, keyword)
+return 0
 
 if args.list_tests:
 test_runner.list_tests()
+return 0
 
 if args.list_tags:
 test_runner.list_tags()
+return 0
 
 if args.list_allclasses:
-args.list_modules = True
+test_runner.list_all_classes()
+return 0
 
 if args.list_modules:
-log.info('Listing all available test modules:')
-testslist = test_runner.get_tests(include_hidden=True)
-for test in testslist:
-module = test.split('.')[-1]
-info = ''
-if module.startswith('_'):
-info = ' (hidden)'
-print module + info
-if args.list_allclasses:
-try:
-import importlib
-modlib = importlib.import_module(test)
-for v in vars(modlib):
-t = vars(modlib)[v]
-if isinstance(t, type(oeSelfTest)) and issubclass(t, 
oeSelfTest) and t!=oeSelfTest:
-print " 

[OE-core] [PATCH 2/9] selftest: Moved coverage functionality from oe-selftest to oeqa/runner.py

2016-02-26 Thread Daniel Istrate
Signed-off-by: Daniel Istrate 
---
 meta/lib/oeqa/runner.py | 108 +++-
 scripts/oe-selftest | 106 +--
 2 files changed, 108 insertions(+), 106 deletions(-)

diff --git a/meta/lib/oeqa/runner.py b/meta/lib/oeqa/runner.py
index ccb1e3b..5bfd4d1 100644
--- a/meta/lib/oeqa/runner.py
+++ b/meta/lib/oeqa/runner.py
@@ -2,6 +2,7 @@ import os
 import logging
 import sys
 import time
+import unittest
 import oeqa.utils.ftools as ftools
 from oeqa.utils.commands import bitbake, get_bb_var, get_test_layer
 
@@ -35,7 +36,8 @@ class Runner:
 self.log = self.logger_create(self.caller)
 self.builddir = os.environ.get("BUILDDIR")
 
-def logger_create(self, log_name):
+@staticmethod
+def logger_create(log_name):
 """ Create logger obj with logging file as  and 
symlink to it as  """
 
 log_link = '%s.log' % log_name
@@ -342,3 +344,107 @@ class Runner:
 print 'Looking for:\t %s' % ', '.join(str(x) for x in keyword)
 print 'Total found:\t %s' % len(ts)
 
+@staticmethod
+def coverage_setup(run_tests, run_all_tests):
+""" Set up the coverage measurement for the testcases to be run """
+builddir = os.environ.get("BUILDDIR")
+coveragerc = "%s/.coveragerc" % builddir
+data_file = "%s/.coverage." % builddir
+data_file += ((run_tests and '.'.join(run_tests)) or (run_all_tests 
and "all_tests") or "")
+if os.path.isfile(data_file):
+os.remove(data_file)
+with open(coveragerc, 'w') as cps:
+cps.write("[run]\n")
+cps.write("data_file = %s\n" % data_file)
+cps.write("branch = True\n")
+# Measure just BBLAYERS, scripts and bitbake folders
+cps.write("source = \n")
+for layer in get_bb_var('BBLAYERS').split():
+cps.write("%s\n" % layer)
+corebase = get_bb_var('COREBASE')
+cps.write("%s\n" % os.path.join(corebase, 'scripts'))
+cps.write("%s\n" % os.path.join(corebase, 'bitbake'))
+
+return coveragerc
+
+@staticmethod
+def coverage_report():
+""" Loads the coverage data gathered and reports it back """
+try:
+# Coverage4 uses coverage.Coverage
+from coverage import Coverage
+except:
+# Coverage under version 4 uses coverage.coverage
+from coverage import coverage as Coverage
+
+import cStringIO as StringIO
+from coverage.misc import CoverageException
+
+cov_output = StringIO.StringIO()
+# Creating the coverage data with the setting from the configuration 
file
+cov = Coverage(config_file=os.environ.get('COVERAGE_PROCESS_START'))
+try:
+# Load data from the data file specified in the configuration
+cov.load()
+# Store report data in a StringIO variable
+cov.report(file = cov_output, show_missing=False)
+print "\n%s" % cov_output.getvalue()
+except CoverageException as e:
+# Show problems with the reporting. Since Coverage4 not finding  
any data to report raises an exception
+print "%s" % str(e)
+finally:
+cov_output.close()
+
+@classmethod
+def buildResultClass(cls, args):
+"""Build a Result Class to use in the testcase execution"""
+
+class StampedResult(unittest.TextTestResult):
+"""
+Custom TestResult that prints the time when a test starts.  As 
oe-selftest
+can take a long time (ie a few hours) to run, timestamps help us 
understand
+what tests are taking a long time to execute.
+If coverage is required, this class executes the coverage setup 
and reporting.
+"""
+def startTest(self, test):
+import time
+self.stream.write(time.strftime("%Y-%m-%d %H:%M:%S", 
time.localtime()) + " - ")
+super(StampedResult, self).startTest(test)
+
+def startTestRun(self):
+""" Setup coverage before running any testcase """
+if args.coverage:
+try:
+# check if user can do coverage
+import coverage
+print "Coverage is enabled"
+
+# In case the user has not set the variable 
COVERAGE_PROCESS_START,
+# create a default one and export it. The 
COVERAGE_PROCESS_START
+# value indicates where the coverage configuration 
file resides
+# More info on https://pypi.python.org/pypi/coverage
+if not os.environ.get('COVERAGE_PROCESS_START'):
+os.environ['COVERAGE_PROCESS_START'] = 

[OE-core] [PATCH 9/9] recipetests: buildrecipe: Test combinations of bbappend

2016-02-26 Thread Daniel Istrate
Selectively use each combination of .bbappend files with the recipe;
All the combinations should not break the recipe build

Signed-off-by: Daniel Istrate 
---
 meta/lib/oeqa/recipetests/buildrecipe.py | 59 +++-
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/recipetests/buildrecipe.py 
b/meta/lib/oeqa/recipetests/buildrecipe.py
index c303b29..900d042 100644
--- a/meta/lib/oeqa/recipetests/buildrecipe.py
+++ b/meta/lib/oeqa/recipetests/buildrecipe.py
@@ -1,7 +1,9 @@
 from oeqa.recipetests.base import RecipeTests
 from oeqa.selftest.base import get_available_machines
-from oeqa.utils.commands import bitbake, get_tasks_for_recipe
+from oeqa.utils.commands import bitbake, get_tasks_for_recipe, get_bb_var, 
ftools, get_all_bbappends
 import logging
+import os
+import random
 
 
 class BuildRecipeTests(RecipeTests):
@@ -60,3 +62,58 @@ class BuildRecipeTests(RecipeTests):
 # Force task on recipe
 self.log.info('Forcing task %s' % task)
 bitbake('-C %s %s' % (task, self.testrecipe))
+
+def test_combinations_of_bbappend(self):
+""" Selectively use each combination of .bbappend files with the 
recipe """
+
+test_recipe_pv = get_bb_var('PV', self.testrecipe)
+recipe_append_file = self.testrecipe + '_' + test_recipe_pv + 
'.bbappend'
+
+bbappend_msgs = {1: 'msg 1', 2: 'msg 2', 3: 'msg 3', 4: 'msg 4'}
+bbappend_files = {}
+
+# Install all bbappends for recipe
+for i in bbappend_msgs:
+recipe_append_dir = self.testrecipe + '_test_' + str(i)
+recipe_append_path = os.path.join(self.testlayer_path, 
'recipes-test', recipe_append_dir, recipe_append_file)
+os.mkdir(os.path.join(self.testlayer_path, 'recipes-test', 
recipe_append_dir))
+feature = 'SUMMARY += "%s"\n' % bbappend_msgs[i]
+ftools.write_file(recipe_append_path, feature)
+bbappend_files[i] = recipe_append_path
+
+self.add_command_to_tearDown('rm -rf %s' % 
os.path.join(self.testlayer_path, 'recipes-test',
+
self.testrecipe + '_test_*'))
+
+test_recipe_bb = '%s_%s.bb' % (self.testrecipe, test_recipe_pv)
+all_bbappends = get_all_bbappends()
+self.log.info('All bbappends for recipe %s: %s' % (self.testrecipe, 
all_bbappends.get(test_recipe_bb)))
+
+# Build recipe with all bbappends
+bitbake(self.testrecipe)
+
+# Mask two random bbappends (some times it might be the same one, 
which is ok)
+for i in range(len(bbappend_files)):
+choice1 = random.choice(bbappend_msgs.keys())
+choice2 = random.choice(bbappend_msgs.keys())
+mask1 = bbappend_files.get(choice1)
+mask2 = bbappend_files.get(choice2)
+
+feature = 'BBMASK = "%s"\n' % mask1
+feature += 'BBMASK += "%s"\n' % mask2
+self.write_config(feature)
+self.log.info('Applied MASKs [%s, %s]' % (mask1, mask2))
+
+# Make sure the masked bbappends don't show up
+current_bbappends = get_all_bbappends()
+self.log.info('Current bbappends for recipe %s: %s' % 
(self.testrecipe, current_bbappends.get(test_recipe_bb)))
+self.assertNotIn(mask1, current_bbappends.get(test_recipe_bb))
+self.assertNotIn(mask2, current_bbappends.get(test_recipe_bb))
+
+# Make sure the summary was updated
+current_summary = get_bb_var('SUMMARY', self.testrecipe)
+self.log.info('Current summary: "%s"' % current_summary)
+self.assertNotIn(bbappend_msgs.get(choice1), current_summary)
+self.assertNotIn(bbappend_msgs.get(choice2), current_summary)
+
+# Build recipe with custom bbappends
+bitbake(self.testrecipe)
-- 
2.1.0

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


[OE-core] [PATCH 6/9] recipetests: base - Base Class for Test Recipes

2016-02-26 Thread Daniel Istrate
Test Recipes should inherit this class.
It sets up a custom tmp dir for the recipe under test.

Signed-off-by: Daniel Istrate 
---
 meta/lib/oeqa/recipetests/base.py | 25 +
 1 file changed, 25 insertions(+)
 create mode 100644 meta/lib/oeqa/recipetests/base.py

diff --git a/meta/lib/oeqa/recipetests/base.py 
b/meta/lib/oeqa/recipetests/base.py
new file mode 100644
index 000..148c123
--- /dev/null
+++ b/meta/lib/oeqa/recipetests/base.py
@@ -0,0 +1,25 @@
+import os
+import shutil
+from oeqa.selftest.base import oeSelfTest
+import oeqa.utils.ftools as ftools
+
+
+class RecipeTests(oeSelfTest):
+
+def __init__(self, methodName="runTest"):
+super(RecipeTests, self).__init__(methodName)
+self.testinc_path = os.path.join(self.builddir, 'conf/testrecipe.inc')
+self.required_path = os.path.join(self.builddir, 'conf/required.inc')
+self.testrecipe = os.getenv("TESTRECIPE")
+
+# Use a clean TMPDIR for each run
+tmpdir_name = self.builddir + '/tmp_' + self.testrecipe
+shutil.rmtree(tmpdir_name, ignore_errors=True)
+
+feature = 'TMPDIR = "%s"\n' % tmpdir_name
+self.set_required_config(feature)
+
+# write to /conf/requred.inc
+def set_required_config(self, data):
+self.log.debug("Writing to: %s\n%s\n" % (self.required_path, data))
+ftools.write_file(self.required_path, data)
-- 
2.1.0

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


[OE-core] [PATCH 1/9] selftest: Moved method from oe-selftest to oeqa/runner.py

2016-02-26 Thread Daniel Istrate
Moved methods to runner and added parameters to them in
order for them to be used by other runners.

Signed-off-by: Daniel Istrate 
---
 meta/lib/oeqa/runner.py | 344 
 scripts/oe-selftest | 325 +++--
 2 files changed, 359 insertions(+), 310 deletions(-)
 create mode 100644 meta/lib/oeqa/runner.py

diff --git a/meta/lib/oeqa/runner.py b/meta/lib/oeqa/runner.py
new file mode 100644
index 000..ccb1e3b
--- /dev/null
+++ b/meta/lib/oeqa/runner.py
@@ -0,0 +1,344 @@
+import os
+import logging
+import sys
+import time
+import oeqa.utils.ftools as ftools
+from oeqa.utils.commands import bitbake, get_bb_var, get_test_layer
+
+
+class Tc:
+""" Holds information about test cases """
+
+def __init__(self, tcname, tcclass, tcmodule, tcid=None, tctag=None):
+self.tcname = tcname
+self.tcclass = tcclass
+self.fullpath = '.'.join([tcmodule, tcclass, tcname])
+# Trim prefix from tcmodule
+self.tcmodule = tcmodule.split('.')[-1]
+self.tcid = tcid
+# A test case can have multiple tags (as tuples) otherwise str will 
suffice
+self.tctag = tctag
+
+
+class Runner:
+
+def __init__(self, caller, base_class, test_mod_dir):
+"""
+:param caller: eg. selftest, test-recipe (log files will use this name)
+:param base_class: eg. oeSelfTest, RecipeTests
+:param test_mod_dir: eg oeqa.selftest, oeqa.recipetests
+"""
+
+self.caller = caller
+self.base_class = base_class
+self.test_mod_dir = test_mod_dir
+self.log = self.logger_create(self.caller)
+self.builddir = os.environ.get("BUILDDIR")
+
+def logger_create(self, log_name):
+""" Create logger obj with logging file as  and 
symlink to it as  """
+
+log_link = '%s.log' % log_name
+log_file = '%s-%s.log' % (log_name, time.strftime("%Y-%m-%d_%H:%M:%S"))
+
+if os.path.exists(log_link):
+os.remove(log_link)
+os.symlink(log_file, log_link)
+
+log = logging.getLogger(log_name)
+log.setLevel(logging.DEBUG)
+
+fh = logging.FileHandler(filename=log_file, mode='w')
+fh.setLevel(logging.DEBUG)
+
+ch = logging.StreamHandler(sys.stdout)
+ch.setLevel(logging.INFO)
+
+formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s 
- %(message)s', "%Y-%m-%d %H:%M:%S")
+fh.setFormatter(formatter)
+ch.setFormatter(formatter)
+
+log.addHandler(fh)
+log.addHandler(ch)
+
+return log
+
+def preflight_check(self):
+""" Check that the environment is sourced, meta-selftest included in 
bblayers and current dir is BUILDDIR """
+
+self.log.info("Checking that everything is in order before running the 
tests")
+
+if not self.builddir:
+self.log.error("BUILDDIR isn't set. Did you forget to source your 
build environment setup script?")
+return False
+
+if os.getcwd() != self.builddir:
+self.log.info("Changing cwd to %s" % self.builddir)
+os.chdir(self.builddir)
+
+if "meta-selftest" not in get_bb_var("BBLAYERS"):
+self.log.error("You don't seem to have the meta-selftest layer in 
BBLAYERS")
+return False
+
+self.log.info("Running bitbake -p")
+bitbake("-p")
+
+return True
+
+def add_include(self, include_files, include_to):
+""" Include in include_to (local.conf, bblayers.conf) the specified 
files """
+
+include_msg_header = "# include added by %s\n" % self.caller
+include_msg = include_msg_header
+if isinstance(include_files, (list, tuple)):
+for f in include_files:
+include_msg += 'include %s\n' % f
+else:
+include_msg += 'include %s\n' % include_files
+
+if include_msg_header not in 
ftools.read_file(os.path.join(self.builddir, 'conf', include_to)):
+self.log.info("Adding: %s in %s" % (include_files, include_to))
+ftools.append_file(os.path.join(self.builddir, 'conf', 
include_to), include_msg)
+
+def remove_include(self, remove_files, remove_from):
+""" Remove from remove_from (local.conf, bblayers.conf) the specified 
files """
+
+if self.builddir is None:
+return
+
+remove_msg_header = "# include added by %s\n" % self.caller
+remove_msg = remove_msg_header
+if isinstance(remove_files, (list, tuple)):
+for f in remove_files:
+remove_msg += 'include %s\n' % f
+else:
+remove_msg += 'include %s\n' % remove_files
+
+if remove_msg_header in ftools.read_file(os.path.join(self.builddir, 
'conf', remove_from)):
+self.log.info("Removing the include from %s" % remove_from)
+

[OE-core] [PATCH 4/9] oeqa/utils/commands: Added 3 new methods for recipes

2016-02-26 Thread Daniel Istrate
get_all_available_recipes, is_recipe_valid, get_tasks_for_recipe

Signed-off-by: Daniel Istrate 
---
 meta/lib/oeqa/utils/commands.py | 20 
 1 file changed, 20 insertions(+)

diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index 32e001c..6ae09d2 100644
--- a/meta/lib/oeqa/utils/commands.py
+++ b/meta/lib/oeqa/utils/commands.py
@@ -165,6 +165,26 @@ def get_test_layer():
 break
 return testlayer
 
+
+def get_all_available_recipes():
+ret = bitbake('-s')
+available_recipes = re.findall(r'\n(\S+)\s+:', ret.output)
+
+return available_recipes
+
+
+def is_recipe_valid(recipe):
+return recipe in get_all_available_recipes()
+
+
+def get_tasks_for_recipe(recipe):
+""" Get available tasks for recipe """
+ret = bitbake('-c listtasks %s' % recipe)
+tasks = re.findall(':\s+do_(\S+)\s+', ret.output)
+
+return tasks
+
+
 def create_temp_layer(templayerdir, templayername, priority=999, 
recipepathspec='recipes-*/*'):
 os.makedirs(os.path.join(templayerdir, 'conf'))
 with open(os.path.join(templayerdir, 'conf', 'layer.conf'), 'w') as f:
-- 
2.1.0

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


[OE-core] [PATCH 7/9] recipetests: buildrecipe: Test suite for recipe tests

2016-02-26 Thread Daniel Istrate
Includes tests for:
1. test build recipe for all major architectures
2. test rebuild recipe from sstate 1 (with sstate)
3. test_rebuild_recipe_from_sstate_2 (without sstate)
4. test cleaning operations on recipe
5. test force major tasks on recipe

fix for [YOCTO #6370]

Signed-off-by: Daniel Istrate 
---
 meta/lib/oeqa/recipetests/buildrecipe.py | 62 
 1 file changed, 62 insertions(+)
 create mode 100644 meta/lib/oeqa/recipetests/buildrecipe.py

diff --git a/meta/lib/oeqa/recipetests/buildrecipe.py 
b/meta/lib/oeqa/recipetests/buildrecipe.py
new file mode 100644
index 000..c303b29
--- /dev/null
+++ b/meta/lib/oeqa/recipetests/buildrecipe.py
@@ -0,0 +1,62 @@
+from oeqa.recipetests.base import RecipeTests
+from oeqa.selftest.base import get_available_machines
+from oeqa.utils.commands import bitbake, get_tasks_for_recipe
+import logging
+
+
+class BuildRecipeTests(RecipeTests):
+
+log = logging.getLogger('test-recipe.build-recipe')
+
+def test_build_recipe_for_all_major_architectures(self):
+""" Build the recipe with all major architectures(qemux86, qemux86-64, 
qemuarm, qemuppc, qemumips) """
+
+machines = get_available_machines()
+qemu_machines = [m for m in machines if 'qemu' in m]
+
+# Build the recipe for all major architectures
+for m in qemu_machines:
+self.log.info('Building recipe "%s" for architecture "%s"' % 
(self.testrecipe, m))
+self.write_config('MACHINE = "%s"' % m)
+bitbake(self.testrecipe)
+
+def test_rebuild_recipe_from_sstate_1(self):
+""" Rebuild the recipe from sstate with sstate file for the recipe """
+bitbake(self.testrecipe)
+bitbake('-c clean %s' % self.testrecipe)
+bitbake(self.testrecipe)
+
+def test_rebuild_recipe_from_sstate_2(self):
+""" Rebuild the recipe from sstate without sstate file for the recipe 
"""
+bitbake(self.testrecipe)
+bitbake('-c cleansstate %s' % self.testrecipe)
+bitbake(self.testrecipe)
+
+def test_cleaning_operations_on_recipe(self):
+""" Perform cleaning operations on the recipe(cleansstate, clean, 
cleanall) """
+
+clean_tasks = ['cleansstate', 'clean', 'cleanall']
+
+for task in clean_tasks:
+bitbake(self.testrecipe)
+self.log.info('Performing %s for recipe %s' % (task, 
self.testrecipe))
+bitbake('-c %s %s' % (task, self.testrecipe))
+
+def test_force_major_tasks_on_recipe(self):
+""" Force all major tasks on the recipe (bitbake -C  ) 
"""
+major_tasks = ['unpack', 'patch', 'configure', 'compile', 'install', 
'populate_sysroot', 'package',
+   'package_write_rpm', 'package_write_deb', 
'package_write_ipk']
+
+feature = 'PACKAGE_CLASSES = "package_rpm package_deb package_ipk"\n'
+self.write_config(feature)
+
+available_tasks = get_tasks_for_recipe(self.testrecipe)
+
+for task in major_tasks:
+# Check if task is available for recipe
+if task not in available_tasks:
+self.log.warning('Task %s not available for recipe %s' % 
(task, self.testrecipe))
+continue
+# Force task on recipe
+self.log.info('Forcing task %s' % task)
+bitbake('-C %s %s' % (task, self.testrecipe))
-- 
2.1.0

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


[OE-core] [PATCH 8/9] oeqa/utils/commands: Added method - get_all_bbappends

2016-02-26 Thread Daniel Istrate
This method runs 'bitbake-layers show-appends' and
returns a dictionary {recipe: [bbappends], ..}

Signed-off-by: Daniel Istrate 
---
 meta/lib/oeqa/utils/commands.py | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index 6ae09d2..8fdb80d 100644
--- a/meta/lib/oeqa/utils/commands.py
+++ b/meta/lib/oeqa/utils/commands.py
@@ -184,6 +184,28 @@ def get_tasks_for_recipe(recipe):
 
 return tasks
 
+def get_all_bbappends():
+""" Get all bbappends (bitbake-layers show-appends)
+:return:a dict with {recipe: [bbappends]}
+"""
+ret_dict = {}
+ret = runCmd('bitbake-layers show-appends')
+
+for line in ret.output.splitlines():
+bb = re.findall('^(\S+\.bb.*):', line)
+bbappend = re.findall('^\s+(\S+\.bbappend)', line)
+if bb:
+key = bb[0]
+value_list = []
+continue
+if bbappend:
+value = bbappend[0]
+value_list.append(value)
+ret_dict[key] = value_list
+continue
+
+return ret_dict
+
 
 def create_temp_layer(templayerdir, templayername, priority=999, 
recipepathspec='recipes-*/*'):
 os.makedirs(os.path.join(templayerdir, 'conf'))
-- 
2.1.0

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


Re: [OE-core] [PATCH 1/3 v2] rpm: Uprev to rpm-5.4.16 (pre) and rpm-5.4+cvs to current CVS head

2016-02-26 Thread Mark Hatle
On 2/26/16 9:01 AM, alexander.kana...@linux.intel.com wrote:
>> +Set the DB 6 version to match oe-core db 6.0.30
>> +Signed-off-by: Mark Hatle 
>> +-[db-6.1], [db_create], [db.h],
>> ++[db-6.0], [db_create], [db.h],
> 
> Why not update the oe-core recipe of db to 6.1 instead? Rpm is the only
> thing that is holding it back.

Because today is feature freeze, and I'm not going to introduce a new BerkleyDB
version on the day of feature freeze.  The only thing I can test on is RPM --
and there may be other users.

The patch was done as a single unit specifically so when DB-6.1 is introduced,
it's VERY simple to remove.

> Note that last time I tried, it broke completely when trying to create an
> image, but maybe the problem has been fixed in the rpm upstream meanwhile:
> http://lists.openembedded.org/pipermail/openembedded-core/2015-August/109187.html

There were two issues affecting image generation.  One was an upgrade of the rpm
python module broke the PACKAGEORIGIN support we rely on.  The other was a
processing issue in the package_manager.py.  It was splitting on '|', and if any
of the lines came back as warnings (say from BerkleyDB) it would fall over.

Both of the issues were addressed in this set.

--Mark

> Alex
> 
> 
> 

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


Re: [OE-core] [PATCH] ffmpeg: add bzlib, lzma and xv PACKAGECONFIGs

2016-02-26 Thread alexander . kanavin
> +PACKAGECONFIG[xv] = "--enable-outdev=xv,--disable-outdev=xv,libxv"

Ah, ffmpeg already had a way to do it :) This patch is fine.

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


Re: [OE-core] [PATCH 1/3 v2] rpm: Uprev to rpm-5.4.16 (pre) and rpm-5.4+cvs to current CVS head

2016-02-26 Thread alexander . kanavin
> +Set the DB 6 version to match oe-core db 6.0.30
> +Signed-off-by: Mark Hatle 
> +-[db-6.1], [db_create], [db.h],
> ++[db-6.0], [db_create], [db.h],

Why not update the oe-core recipe of db to 6.1 instead? Rpm is the only
thing that is holding it back.

Note that last time I tried, it broke completely when trying to create an
image, but maybe the problem has been fixed in the rpm upstream meanwhile:
http://lists.openembedded.org/pipermail/openembedded-core/2015-August/109187.html

Alex



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


[OE-core] [PATCH] ffmpeg: add bzlib, lzma and xv PACKAGECONFIGs

2016-02-26 Thread Jonathan Liu
Signed-off-by: Jonathan Liu 
---
 meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb 
b/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb
index 3f0cbf8..036d4f1 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb
@@ -29,14 +29,16 @@ DEPENDS = "alsa-lib zlib libogg yasm-native"
 
 inherit autotools pkgconfig
 
-PACKAGECONFIG ??= "avdevice avfilter gpl theora x264 
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
-PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice, libxv"
+PACKAGECONFIG ??= "avdevice avfilter bzlib gpl lzma theora x264 
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 xv', '', d)}"
+PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice"
 PACKAGECONFIG[avfilter] = "--enable-avfilter,--disable-avfilter"
+PACKAGECONFIG[bzlib] = "--enable-bzlib,--disable-bzlib,bzip2"
 PACKAGECONFIG[faac] = "--enable-libfaac,--disable-libfaac,faac"
 PACKAGECONFIG[gpl] = "--enable-gpl,--disable-gpl"
 PACKAGECONFIG[gsm] = "--enable-libgsm,--disable-libgsm,libgsm"
 PACKAGECONFIG[jack] = "--enable-indev=jack,--disable-indev=jack,jack"
 PACKAGECONFIG[libvorbis] = "--enable-libvorbis,--disable-libvorbis,libvorbis"
+PACKAGECONFIG[lzma] = "--enable-lzma,--disable-lzma,xz"
 PACKAGECONFIG[mp3lame] = "--enable-libmp3lame,--disable-libmp3lame,lame"
 PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl"
 PACKAGECONFIG[schroedinger] = 
"--enable-libschroedinger,--disable-libschroedinger,schroedinger"
@@ -46,6 +48,7 @@ PACKAGECONFIG[vaapi] = "--enable-vaapi,--disable-vaapi,libva"
 PACKAGECONFIG[vpx] = "--enable-libvpx,--disable-libvpx,libvpx"
 PACKAGECONFIG[x11] = "--enable-x11grab,--disable-x11grab,virtual/libx11 
libxfixes libxext xproto virtual/libsdl"
 PACKAGECONFIG[x264] = "--enable-libx264,--disable-libx264,x264"
+PACKAGECONFIG[xv] = "--enable-outdev=xv,--disable-outdev=xv,libxv"
 
 # Check codecs that require --enable-nonfree
 USE_NONFREE = "${@bb.utils.contains_any('PACKAGECONFIG', [ 'faac', 'openssl' 
], 'yes', '', d)}"
-- 
2.7.1

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


Re: [OE-core] [PATCH] ffmpeg: add bzlib and lzma PACKAGECONFIGs

2016-02-26 Thread Jonathan Liu
On 26 February 2016 at 22:16, Jonathan Liu  wrote:
> Signed-off-by: Jonathan Liu 
> ---
>  meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb 
> b/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb
> index e7b20fa..53156ed 100644
> --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb
> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb
> @@ -30,14 +30,16 @@ DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 
> 'avdevice', bb.utils.contains(
>
>  inherit autotools pkgconfig
>
> -PACKAGECONFIG ??= "avdevice avfilter gpl theora x264 
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
> +PACKAGECONFIG ??= "avdevice avfilter bzlib gpl lzma theora x264 
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
>  PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice"
>  PACKAGECONFIG[avfilter] = "--enable-avfilter,--disable-avfilter"
> +PACKAGECONFIG[bzlib] = "--enable-bzlib,--disable-bzlib,bzip2"
>  PACKAGECONFIG[faac] = "--enable-libfaac,--disable-libfaac,faac"
>  PACKAGECONFIG[gpl] = "--enable-gpl,--disable-gpl"
>  PACKAGECONFIG[gsm] = "--enable-libgsm,--disable-libgsm,libgsm"
>  PACKAGECONFIG[jack] = "--enable-indev=jack,--disable-indev=jack,jack"
>  PACKAGECONFIG[libvorbis] = "--enable-libvorbis,--disable-libvorbis,libvorbis"
> +PACKAGECONFIG[lzma] = "--enable-lzma,--disable-lzma,xz"
>  PACKAGECONFIG[mp3lame] = "--enable-libmp3lame,--disable-libmp3lame,lame"
>  PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl"
>  PACKAGECONFIG[schroedinger] = 
> "--enable-libschroedinger,--disable-libschroedinger,schroedinger"
> --
> 2.7.1
>

Please disregard this patch. I will rework it to include a
PACKAGECONFIG for xv as well.

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


Re: [OE-core] [PATCH] ffmpeg: fix build when DISTRO_FEATURES doesn't contain x11

2016-02-26 Thread Jonathan Liu
On 27 February 2016 at 01:43,   wrote:
>>> I'd call that a bug, and should be simple to resolve (pass expand=True
>>> when
>>> fetching getVarFlags in the PACKAGECONFIG handling code).
>>>
>>> Ross
>>
>> Feel free to submit a patch to handle the PACKAGECONFIG expansion and
>> then I can update the fix.
>
> I think you need to solve this in a different way altogether. Write a
> patch for the upstream code that turns a floating, implicit xv dependency
> into something that can be explicitly turned on and off, and then add a
> PACKAGECONFIG option for it to the recipe.
>
> Alex

Okay. Please disregard this patch.
I will rework into a new patch.

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


Re: [OE-core] [PATCH] ffmpeg: fix build when DISTRO_FEATURES doesn't contain x11

2016-02-26 Thread alexander . kanavin
>> I'd call that a bug, and should be simple to resolve (pass expand=True
>> when
>> fetching getVarFlags in the PACKAGECONFIG handling code).
>>
>> Ross
>
> Feel free to submit a patch to handle the PACKAGECONFIG expansion and
> then I can update the fix.

I think you need to solve this in a different way altogether. Write a
patch for the upstream code that turns a floating, implicit xv dependency
into something that can be explicitly turned on and off, and then add a
PACKAGECONFIG option for it to the recipe.

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


Re: [OE-core] [PATCH] ffmpeg: fix build when DISTRO_FEATURES doesn't contain x11

2016-02-26 Thread Jonathan Liu
On 26 February 2016 at 23:33, Burton, Ross  wrote:
>
> On 26 February 2016 at 11:17, Jonathan Liu  wrote:
>>
>> It doesn't work in PACKAGECONFIG. that is the first thing I tried.
>
>
> I'd call that a bug, and should be simple to resolve (pass expand=True when
> fetching getVarFlags in the PACKAGECONFIG handling code).
>
> Ross

Feel free to submit a patch to handle the PACKAGECONFIG expansion and
then I can update the fix.

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


Re: [OE-core] [PATCH] rsync: enable native builds for rsync 2.6.9

2016-02-26 Thread Burton, Ross
Retracting this - for native builds GPLv3 is acceptable.

Ross

On 25 February 2016 at 21:59, Ross Burton  wrote:

> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-devtools/rsync/rsync_2.6.9.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-devtools/rsync/rsync_2.6.9.bb
> b/meta/recipes-devtools/rsync/rsync_2.6.9.bb
> index 6854c77..d37cda7 100644
> --- a/meta/recipes-devtools/rsync/rsync_2.6.9.bb
> +++ b/meta/recipes-devtools/rsync/rsync_2.6.9.bb
> @@ -26,3 +26,5 @@ LICENSE = "GPLv2+"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=6d5a9d4c4d3af25cd68fd83e8a8cb09c"
>
>  PR = "r4"
> +
> +BBCLASSEXTEND = "native"
> --
> 2.7.0
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] ffmpeg: fix build when DISTRO_FEATURES doesn't contain x11

2016-02-26 Thread Burton, Ross
On 26 February 2016 at 11:17, Jonathan Liu  wrote:

> It doesn't work in PACKAGECONFIG. that is the first thing I tried.
>

I'd call that a bug, and should be simple to resolve (pass expand=True when
fetching getVarFlags in the PACKAGECONFIG handling code).

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


Re: [OE-core] [PATCH] ffmpeg: fix build when DISTRO_FEATURES doesn't contain x11

2016-02-26 Thread Jonathan Liu
Hi Martin,

It doesn't work in PACKAGECONFIG. that is the first thing I tried.

Regards,
Jonathan

On 26 February 2016 at 22:04, Martin Jansa  wrote:
> On Fri, Feb 26, 2016 at 09:52:25PM +1100, Jonathan Liu wrote:
>> If avdevice is enabled, libxv is used if it is detected by configure
>> for the XV outdev. However, we can't depend on libxv for avdevice when
>> DISTRO_FEATURES doesn't contain x11 as this will result in an error.
>>
>> Fix this by adding a libxv dependency only when the avdevice
>> PACKAGECONFIG is enabled and DISTRO_FEATURES contains x11. XV outdev
>> is only one of many that are supported by avdevice so it is still
>> useful to enable avdevice even if libxv is not available.
>>
>> Signed-off-by: Jonathan Liu 
>> ---
>>  meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb 
>> b/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb
>> index 72393b3..f29c05e 100644
>> --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb
>> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb
>> @@ -23,11 +23,12 @@ SRC_URI[sha256sum] = 
>> "25bcedbdafadac3d09c325c1d46a51f53d858b26a260d5aed6b4f17fea
>>  PROVIDES = "libav libpostproc"
>>
>>  DEPENDS = "alsa-lib zlib libogg yasm-native"
>> +DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 'avdevice', 
>> bb.utils.contains('DISTRO_FEATURES', 'x11', 'libxv', '', d), '', d)}"
>>
>>  inherit autotools pkgconfig
>>
>>  PACKAGECONFIG ??= "avdevice avfilter gpl theora x264 
>> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
>> -PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice, libxv"
>> +PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice"
>
> bb.utils.contains didn't work in PACKAGECONFIG?
>
> Why not
> PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice, 
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'libxv', '', d)"
>
>>  PACKAGECONFIG[avfilter] = "--enable-avfilter,--disable-avfilter"
>>  PACKAGECONFIG[faac] = "--enable-libfaac,--disable-libfaac,faac"
>>  PACKAGECONFIG[gpl] = "--enable-gpl,--disable-gpl"
>> --
>> 2.7.1
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2] ffmpeg: fix build when DISTRO_FEATURES doesn't contain x11

2016-02-26 Thread Jonathan Liu
If avdevice is enabled, libxv is used if it is detected by configure
for the XV outdev. However, we can't depend on libxv for avdevice when
DISTRO_FEATURES doesn't contain x11 as this will result in an error.

Fix this by adding a libxv dependency only when the avdevice
PACKAGECONFIG is enabled and DISTRO_FEATURES contains x11. XV outdev
is only one of many that are supported by avdevice so it is still
useful to enable avdevice even if libxv is not available.

Signed-off-by: Jonathan Liu 
---
 meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb 
b/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb
index 3f0cbf8..e7b20fa 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb
@@ -26,11 +26,12 @@ ARM_INSTRUCTION_SET = "arm"
 PROVIDES = "libav libpostproc"
 
 DEPENDS = "alsa-lib zlib libogg yasm-native"
+DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 'avdevice', 
bb.utils.contains('DISTRO_FEATURES', 'x11', 'libxv', '', d), '', d)}"
 
 inherit autotools pkgconfig
 
 PACKAGECONFIG ??= "avdevice avfilter gpl theora x264 
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
-PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice, libxv"
+PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice"
 PACKAGECONFIG[avfilter] = "--enable-avfilter,--disable-avfilter"
 PACKAGECONFIG[faac] = "--enable-libfaac,--disable-libfaac,faac"
 PACKAGECONFIG[gpl] = "--enable-gpl,--disable-gpl"
-- 
2.7.1

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


[OE-core] [PATCH] ffmpeg: add bzlib and lzma PACKAGECONFIGs

2016-02-26 Thread Jonathan Liu
Signed-off-by: Jonathan Liu 
---
 meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb 
b/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb
index e7b20fa..53156ed 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_3.0.bb
@@ -30,14 +30,16 @@ DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 
'avdevice', bb.utils.contains(
 
 inherit autotools pkgconfig
 
-PACKAGECONFIG ??= "avdevice avfilter gpl theora x264 
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
+PACKAGECONFIG ??= "avdevice avfilter bzlib gpl lzma theora x264 
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
 PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice"
 PACKAGECONFIG[avfilter] = "--enable-avfilter,--disable-avfilter"
+PACKAGECONFIG[bzlib] = "--enable-bzlib,--disable-bzlib,bzip2"
 PACKAGECONFIG[faac] = "--enable-libfaac,--disable-libfaac,faac"
 PACKAGECONFIG[gpl] = "--enable-gpl,--disable-gpl"
 PACKAGECONFIG[gsm] = "--enable-libgsm,--disable-libgsm,libgsm"
 PACKAGECONFIG[jack] = "--enable-indev=jack,--disable-indev=jack,jack"
 PACKAGECONFIG[libvorbis] = "--enable-libvorbis,--disable-libvorbis,libvorbis"
+PACKAGECONFIG[lzma] = "--enable-lzma,--disable-lzma,xz"
 PACKAGECONFIG[mp3lame] = "--enable-libmp3lame,--disable-libmp3lame,lame"
 PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl"
 PACKAGECONFIG[schroedinger] = 
"--enable-libschroedinger,--disable-libschroedinger,schroedinger"
-- 
2.7.1

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


Re: [OE-core] [PATCH] ffmpeg: fix build when DISTRO_FEATURES doesn't contain x11

2016-02-26 Thread Martin Jansa
On Fri, Feb 26, 2016 at 09:52:25PM +1100, Jonathan Liu wrote:
> If avdevice is enabled, libxv is used if it is detected by configure
> for the XV outdev. However, we can't depend on libxv for avdevice when
> DISTRO_FEATURES doesn't contain x11 as this will result in an error.
> 
> Fix this by adding a libxv dependency only when the avdevice
> PACKAGECONFIG is enabled and DISTRO_FEATURES contains x11. XV outdev
> is only one of many that are supported by avdevice so it is still
> useful to enable avdevice even if libxv is not available.
> 
> Signed-off-by: Jonathan Liu 
> ---
>  meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb 
> b/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb
> index 72393b3..f29c05e 100644
> --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb
> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb
> @@ -23,11 +23,12 @@ SRC_URI[sha256sum] = 
> "25bcedbdafadac3d09c325c1d46a51f53d858b26a260d5aed6b4f17fea
>  PROVIDES = "libav libpostproc"
>  
>  DEPENDS = "alsa-lib zlib libogg yasm-native"
> +DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 'avdevice', 
> bb.utils.contains('DISTRO_FEATURES', 'x11', 'libxv', '', d), '', d)}"
>  
>  inherit autotools pkgconfig
>  
>  PACKAGECONFIG ??= "avdevice avfilter gpl theora x264 
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
> -PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice, libxv"
> +PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice"

bb.utils.contains didn't work in PACKAGECONFIG?

Why not
PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice, 
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'libxv', '', d)"

>  PACKAGECONFIG[avfilter] = "--enable-avfilter,--disable-avfilter"
>  PACKAGECONFIG[faac] = "--enable-libfaac,--disable-libfaac,faac"
>  PACKAGECONFIG[gpl] = "--enable-gpl,--disable-gpl"
> -- 
> 2.7.1
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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


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


[OE-core] [dizzy][PATCH] glibc 2.20: Security fix CVE-2015-7547

2016-02-26 Thread Koen Kooi
CVE-2015-7547: getaddrinfo() stack-based buffer overflow

Signed-off-by: Koen Kooi 
---
 meta/recipes-core/glibc/glibc/CVE-2015-7547.patch | 583 ++
 meta/recipes-core/glibc/glibc_2.20.bb |   1 +
 2 files changed, 584 insertions(+)
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2015-7547.patch

diff --git a/meta/recipes-core/glibc/glibc/CVE-2015-7547.patch 
b/meta/recipes-core/glibc/glibc/CVE-2015-7547.patch
new file mode 100644
index 000..d877408
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/CVE-2015-7547.patch
@@ -0,0 +1,583 @@
+From e9db92d3acfe1822d56d11abcea5bfc4c41cf6ca Mon Sep 17 00:00:00 2001
+From: Carlos O'Donell 
+Date: Tue, 16 Feb 2016 21:26:37 -0500
+Subject: [PATCH] CVE-2015-7547: getaddrinfo() stack-based buffer overflow (Bug
+ 18665).
+
+* A stack-based buffer overflow was found in libresolv when invoked from
+  libnss_dns, allowing specially crafted DNS responses to seize control
+  of execution flow in the DNS client.  The buffer overflow occurs in
+  the functions send_dg (send datagram) and send_vc (send TCP) for the
+  NSS module libnss_dns.so.2 when calling getaddrinfo with AF_UNSPEC
+  family.  The use of AF_UNSPEC triggers the low-level resolver code to
+  send out two parallel queries for A and .  A mismanagement of the
+  buffers used for those queries could result in the response of a query
+  writing beyond the alloca allocated buffer created by
+  _nss_dns_gethostbyname4_r.  Buffer management is simplified to remove
+  the overflow.  Thanks to the Google Security Team and Red Hat for
+  reporting the security impact of this issue, and Robert Holiday of
+  Ciena for reporting the related bug 18665. (CVE-2015-7547)
+
+See also:
+https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
+https://sourceware.org/ml/libc-alpha/2016-02/msg00418.html
+
+Upstream-Status: Backport
+CVE: CVE-2015-7547
+
+https://sourceware.org/git/?p=glibc.git;a=commit;h=e9db92d3acfe1822d56d11abcea5bfc4c41cf6ca
+minor tweaking to remove Changelog and NEWS
+
+---
+ resolv/nss_dns/dns-host.c | 111 +++-
+ resolv/res_query.c|   3 +
+ resolv/res_send.c | 260 +++---
+ 3 files changed, 339 insertions(+), 66 deletions(-)
+
+diff --git a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c
+index 3258e70..755832e 100644
+--- a/resolv/nss_dns/dns-host.c
 b/resolv/nss_dns/dns-host.c
+@@ -1031,7 +1031,10 @@ gaih_getanswer_slice (const querybuf *answer, int 
anslen, const char *qname,
+   int h_namelen = 0;
+ 
+   if (ancount == 0)
+-return NSS_STATUS_NOTFOUND;
++{
++  *h_errnop = HOST_NOT_FOUND;
++  return NSS_STATUS_NOTFOUND;
++}
+ 
+   while (ancount-- > 0 && cp < end_of_message && had_error == 0)
+ {
+@@ -1208,7 +1211,14 @@ gaih_getanswer_slice (const querybuf *answer, int 
anslen, const char *qname,
+   /* Special case here: if the resolver sent a result but it only
+  contains a CNAME while we are looking for a T_A or T_ record,
+  we fail with NOTFOUND instead of TRYAGAIN.  */
+-  return canon == NULL ? NSS_STATUS_TRYAGAIN : NSS_STATUS_NOTFOUND;
++  if (canon != NULL)
++{
++  *h_errnop = HOST_NOT_FOUND;
++  return NSS_STATUS_NOTFOUND;
++}
++
++  *h_errnop = NETDB_INTERNAL;
++  return NSS_STATUS_TRYAGAIN;
+ }
+ 
+ 
+@@ -1222,11 +1232,101 @@ gaih_getanswer (const querybuf *answer1, int anslen1, 
const querybuf *answer2,
+ 
+   enum nss_status status = NSS_STATUS_NOTFOUND;
+ 
++  /* Combining the NSS status of two distinct queries requires some
++ compromise and attention to symmetry (A or  queries can be
++ returned in any order).  What follows is a breakdown of how this
++ code is expected to work and why. We discuss only SUCCESS,
++ TRYAGAIN, NOTFOUND and UNAVAIL, since they are the only returns
++ that apply (though RETURN and MERGE exist).  We make a distinction
++ between TRYAGAIN (recoverable) and TRYAGAIN' (not-recoverable).
++ A recoverable TRYAGAIN is almost always due to buffer size issues
++ and returns ERANGE in errno and the caller is expected to retry
++ with a larger buffer.
++
++ Lastly, you may be tempted to make significant changes to the
++ conditions in this code to bring about symmetry between responses.
++ Please don't change anything without due consideration for
++ expected application behaviour.  Some of the synthesized responses
++ aren't very well thought out and sometimes appear to imply that
++ IPv4 responses are always answer 1, and IPv6 responses are always
++ answer 2, but that's not true (see the implementation of send_dg
++ and send_vc to see response can arrive in any order, particularly
++ for UDP). However, we expect it holds roughly enough of the time
++ that this code works, but certainly needs to be fixed to make this
++ a more robust implementation.
++
++ 

[OE-core] [PATCH] ffmpeg: fix build when DISTRO_FEATURES doesn't contain x11

2016-02-26 Thread Jonathan Liu
If avdevice is enabled, libxv is used if it is detected by configure
for the XV outdev. However, we can't depend on libxv for avdevice when
DISTRO_FEATURES doesn't contain x11 as this will result in an error.

Fix this by adding a libxv dependency only when the avdevice
PACKAGECONFIG is enabled and DISTRO_FEATURES contains x11. XV outdev
is only one of many that are supported by avdevice so it is still
useful to enable avdevice even if libxv is not available.

Signed-off-by: Jonathan Liu 
---
 meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb 
b/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb
index 72393b3..f29c05e 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.6.bb
@@ -23,11 +23,12 @@ SRC_URI[sha256sum] = 
"25bcedbdafadac3d09c325c1d46a51f53d858b26a260d5aed6b4f17fea
 PROVIDES = "libav libpostproc"
 
 DEPENDS = "alsa-lib zlib libogg yasm-native"
+DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 'avdevice', 
bb.utils.contains('DISTRO_FEATURES', 'x11', 'libxv', '', d), '', d)}"
 
 inherit autotools pkgconfig
 
 PACKAGECONFIG ??= "avdevice avfilter gpl theora x264 
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
-PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice, libxv"
+PACKAGECONFIG[avdevice] = "--enable-avdevice,--disable-avdevice"
 PACKAGECONFIG[avfilter] = "--enable-avfilter,--disable-avfilter"
 PACKAGECONFIG[faac] = "--enable-libfaac,--disable-libfaac,faac"
 PACKAGECONFIG[gpl] = "--enable-gpl,--disable-gpl"
-- 
2.7.1

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


Re: [OE-core] How to integrate third party application software to yocto image

2016-02-26 Thread Anders Darander
Hi,

Please, don't top post.

* winis...@futuraautomation.com  [160226 06:41]:
> I copied "recipes-navigation" folder from meta-oe (Open embedded build tree) 
> to "/poky/meta "

> I have appended  in “conf/local.conf”  as given below

> IMAGE_INSTALL_append = " navit"

> While creating the image, it spits out the following error,

> winiston@winiston-VirtualBox:~/poky/build$ bitbake qt4e-demo-image
> Loading cache: 100% |##| ETA:  00:00:00
> Loaded 1510 entries from dependency cache.
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing RPROVIDES 'navit' (but 
> /home/winiston/poky/meta/recipes-qt/images/qt4e-demo-image.bb RDEPENDS on or 
> otherwise requires it)
> ERROR: navit was skipped: Recipe is blacklisted: bluez5 conflicts with bluez4 
> and bluez5 is selected in DISTRO_FEATURES

This is the error. You have bluez5 in your DITRO_FEATURES, and I assume
that navit requires bluez4? Anywya, it's blacklisted.

> NOTE: Runtime target 'navit' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['navit']
> ERROR: Required build target 'qt4e-demo-image' has no buildable providers.
> Missing or unbuildable dependency chain was: ['qt4e-demo-image', 'navit']

> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
> winiston@winiston-VirtualBox:~/poky/build$ 

> Should I make any other setting to add the “navit” recipe to my image?
> Is this the correct method of copying  "recipes-navigation" folder  to
> "/poky/meta "  ? 

Well, it works. If you don't mind the rest of meta-oe, I'd rather add
that layer to conf/bblayers.conf. That would make it easier to get
updates to e.g. navit.

Cheers,
Anders

-- 
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] rootfs-postcommands: fix ssh_allow_empty_password checking

2016-02-26 Thread Jonathan Liu
The ssh_allow_empty_password function doesn't check if
sshd_config_readonly exists before running sed which can result in an
error if sshd_config exists but sshd_config_readonly doesn't.

Signed-off-by: Jonathan Liu 
---
 meta/classes/rootfs-postcommands.bbclass | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index f5d6147..e184667 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -112,10 +112,12 @@ zap_empty_root_password () {
 # allow dropbear/openssh to accept root logins and logins from accounts with 
an empty password string
 #
 ssh_allow_empty_password () {
-   if [ -e ${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config ]; then
-   sed -i 's/^[#[:space:]]*PermitRootLogin.*/PermitRootLogin yes/' 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config_readonly
-   sed -i 
's/^[#[:space:]]*PermitEmptyPasswords.*/PermitEmptyPasswords yes/' 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config_readonly
-   fi
+   for config in sshd_config sshd_config_readonly; do
+   if [ -e ${IMAGE_ROOTFS}${sysconfdir}/ssh/$config ]; then
+   sed -i 
's/^[#[:space:]]*PermitRootLogin.*/PermitRootLogin yes/' 
${IMAGE_ROOTFS}${sysconfdir}/ssh/$config
+   sed -i 
's/^[#[:space:]]*PermitEmptyPasswords.*/PermitEmptyPasswords yes/' 
${IMAGE_ROOTFS}${sysconfdir}/ssh/$config
+   fi
+   done
 
if [ -e ${IMAGE_ROOTFS}${sbindir}/dropbear ] ; then
if grep -q DROPBEAR_EXTRA_ARGS 
${IMAGE_ROOTFS}${sysconfdir}/default/dropbear 2>/dev/null ; then
-- 
2.7.1

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


Re: [OE-core] [PATCH 0/4] Replaces udev with eudev for compatibility when using sysvinit on newer kernels

2016-02-26 Thread Andre McCurdy
On Thu, Feb 25, 2016 at 3:34 PM, Alejandro Hernandez
 wrote:
> udev has started to fail on new kernels (4.4), due to being deprecated in 
> favor
> of systemd's udev implementation. To maintain a sysvinit alternative we also
> need to provide an alternative to udev. Eudev is a fork of systemds udev,
> this new eudev recipe provides upstream udev 220 funcitonality.

Builds OK but results in the network no longer being started
automatically at boot up - due to "eth0" now becoming "enp0s3".

Adding an entry for enp0s3 to the init-ifupdown interfaces file is a
solution. Running "touch /etc/udev/rules.d/80-net-name-slot.rules" as
suggested by the eudev Wiki (to force the interface name back eth0)
seems to work too.

  https://wiki.gentoo.org/wiki/Eudev

Is there a recommended migration path so that the primary ethernet
interface is brought up automatically, as it was before?

> - libgudev is not provided by eudev as it was with udev before
> - We can now drop usbutils_007 since usbutils_008 is now compatible
>   also with eudev, and not only with systemd's udev
> - Adds new eudev package to maintainers.inc
>
> The following changes since commit 23056103c949b498c23b47579e8dd57ce78e6ed9:
>
>   uclibc: Do not use immediate expansion operator (2016-02-22 20:42:48 +)
>
> are available in the git repository at:
>
>   git://git.yoctoproject.org/poky-contrib hsalejandro/eudev
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=hsalejandro/eudev
>
> Alejandro Hernandez (4):
>   eudev: Replaces udev with eudev for compatibility when sysvinit on
> newer kernels
>   libgudev: Fix for new eudev implementation
>   usbutils: Fix for new eudev implementation
>   maintainers.inc: Add new eudev package and change maintainership fore
> udev
>
>  meta-yocto/conf/distro/include/maintainers.inc |   2 +-
>  meta/conf/distro/include/default-providers.inc |   2 +-
>  meta/recipes-bsp/usbutils/usbutils-008/iconv.patch |  41 
>  meta/recipes-bsp/usbutils/usbutils/iconv.patch |  29 +++---
>  meta/recipes-bsp/usbutils/usbutils_007.bb  |  31 --
>  meta/recipes-bsp/usbutils/usbutils_008.bb  |   5 +-
>  .../udev/{udev => eudev}/devfs-udev.rules  |   0
>  meta/recipes-core/udev/{udev => eudev}/init|   0
>  meta/recipes-core/udev/{udev => eudev}/links.conf  |   0
>  meta/recipes-core/udev/{udev => eudev}/local.rules |   0
>  .../udev/{udev => eudev}/permissions.rules |   0
>  meta/recipes-core/udev/{udev => eudev}/run.rules   |   0
>  meta/recipes-core/udev/{udev => eudev}/udev-cache  |   0
>  .../udev/{udev => eudev}/udev-cache.default|   0
>  meta/recipes-core/udev/{udev => eudev}/udev.rules  |   0
>  meta/recipes-core/udev/eudev_3.1.5.bb  |  83 +++
>  meta/recipes-core/udev/udev.inc| 112 
> -
>  ...yboard_force_release.sh-shell-script-path.patch |  35 ---
>  ...-Add-stdint.h-as-it-was-removed-from-mtd-.patch |  29 --
>  ...c-Makefile.am-Check-for-input.h-and-input.patch |  52 --
>  .../recipes-core/udev/udev/add-install-ptest.patch |  86 
>  .../udev/udev/avoid-mouse-autosuspend.patch|  25 -
>  .../udev/udev/fix_rule-syntax-regex-ptest.patch|  58 ---
>  meta/recipes-core/udev/udev/run-ptest  |   5 -
>  meta/recipes-core/udev/udev_182.bb |   9 --
>  meta/recipes-gnome/libgudev/libgudev_230.bb|   3 +-
>  26 files changed, 102 insertions(+), 505 deletions(-)
>  delete mode 100644 meta/recipes-bsp/usbutils/usbutils-008/iconv.patch
>  delete mode 100644 meta/recipes-bsp/usbutils/usbutils_007.bb
>  rename meta/recipes-core/udev/{udev => eudev}/devfs-udev.rules (100%)
>  rename meta/recipes-core/udev/{udev => eudev}/init (100%)
>  rename meta/recipes-core/udev/{udev => eudev}/links.conf (100%)
>  rename meta/recipes-core/udev/{udev => eudev}/local.rules (100%)
>  rename meta/recipes-core/udev/{udev => eudev}/permissions.rules (100%)
>  rename meta/recipes-core/udev/{udev => eudev}/run.rules (100%)
>  rename meta/recipes-core/udev/{udev => eudev}/udev-cache (100%)
>  rename meta/recipes-core/udev/{udev => eudev}/udev-cache.default (100%)
>  rename meta/recipes-core/udev/{udev => eudev}/udev.rules (100%)
>  create mode 100644 meta/recipes-core/udev/eudev_3.1.5.bb
>  delete mode 100644 meta/recipes-core/udev/udev.inc
>  delete mode 100644 
> meta/recipes-core/udev/udev/0001-Fixing-keyboard_force_release.sh-shell-script-path.patch
>  delete mode 100644 
> meta/recipes-core/udev/udev/0001-mtd_probe.h-Add-stdint.h-as-it-was-removed-from-mtd-.patch
>  delete mode 100644 
> meta/recipes-core/udev/udev/0002-configure.ac-Makefile.am-Check-for-input.h-and-input.patch
>  delete mode 100644 meta/recipes-core/udev/udev/add-install-ptest.patch
>  delete mode 100644 meta/recipes-core/udev/udev/avoid-mouse-autosuspend.patch
>  delete mode 100644 
> 

Re: [OE-core] [PATCH 0/3] Add initial capability to check CVEs for recipes

2016-02-26 Thread Mikko.Rapeli
Hi,

On my developer machine the cve-check ran ok for dizzy but on build server
with sstate-cache and rmwork enabled it failed with what looks like a race
condition when scanning the patch files:

17:45:36 ERROR: Error executing a python function in 
/home/builder/src/base/poky/meta/recipes-extended/mailx/mailx_12.5.bb:
17:45:36 
17:45:36 The stack trace of python calls that resulted in this 
exception/failure was:
17:45:36 File: 'do_cve_check', lineno: 17, function: 
17:45:36  0013:else:
17:45:36  0014:bb.note("Failed to update CVE database, skipping CVE 
check")
17:45:36  0015:
17:45:36  0016:
17:45:36  *** 0017:do_cve_check(d)
17:45:36  0018:
17:45:37 File: 'do_cve_check', lineno: 8, function: do_cve_check
17:45:37  0004:Check recipe for patched and unpatched CVEs
17:45:37  0005:"""
17:45:37  0006:
17:45:37  0007:if os.path.exists(d.getVar("CVE_CHECK_TMP_FILE", True)):
17:45:37  *** 0008:patched_cves = get_patches_cves(d)
17:45:37  0009:patched, unpatched = check_cves(d, patched_cves)
17:45:37  0010:if patched or unpatched:
17:45:37  0011:cve_data = get_cve_info(d, patched + unpatched)
17:45:37  0012:cve_write_data(d, patched, unpatched, cve_data)
17:45:37 File: 'cve-check.bbclass', lineno: 13, function: get_patches_cves
17:45:37  0009:cve_match = re.compile("CVE:( CVE\-\d+\-\d+)+")
17:45:37  0010:patched_cves = set()
17:45:37  0011:for url in src_patches(d):
17:45:37  0012:patch_file = bb.fetch.decodeurl(url)[2]
17:45:37  *** 0013:with open(patch_file, "r") as f:
17:45:37  0014:patch_text = f.read()
17:45:37  0015:
17:45:37  0016:# Search for the "CVE: " line
17:45:37  0017:match = cve_match.search(patch_text)
17:45:37 Exception: IOError: [Errno 2] No such file or directory: 
'/home/builder/src/base/build/tmp/work/corei7-64-linux/mailx/12.5-r2/heirloom-mailx_12.5-1.diff'
17:45:37 
17:45:37 ERROR: Function failed: do_cve_check

So could this be caused by cve-check changes or is this just a side effect
of some other recipe problems?

I could not see that kind of fixes in master.

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


Re: [OE-core] [PATCH] uclibc support for rng-tools

2016-02-26 Thread Khem Raj
its better fix

> On Feb 25, 2016, at 2:30 AM, Maxin B. John  wrote:
> 
> Uclibc has its own argp implemented as libuargp. So, we add a new
> option --enable-uclibc to select it.
> 
> Signed-off-by: Maxin B. John 
> ---
> .../rng-tools/uclibc-libuargp-configure.patch  | 63 ++
> meta/recipes-support/rng-tools/rng-tools_5.bb  |  4 +-
> 2 files changed, 66 insertions(+), 1 deletion(-)
> create mode 100644 
> meta/recipes-support/rng-tools/rng-tools/uclibc-libuargp-configure.patch
> 
> diff --git 
> a/meta/recipes-support/rng-tools/rng-tools/uclibc-libuargp-configure.patch 
> b/meta/recipes-support/rng-tools/rng-tools/uclibc-libuargp-configure.patch
> new file mode 100644
> index 000..e691315
> --- /dev/null
> +++ b/meta/recipes-support/rng-tools/rng-tools/uclibc-libuargp-configure.patch
> @@ -0,0 +1,63 @@
> +In case of uclibc, use libuargp
> +
> +If we use uclibc for system libraries, select libuargp
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Maxin B. John 
> +---
> +diff -Naur rng-tools-5-orig/configure.ac rng-tools-5/configure.ac
> +--- rng-tools-5-orig/configure.ac2016-02-24 18:11:24.023690235 +0200
>  rng-tools-5/configure.ac 2016-02-24 18:14:49.763118138 +0200
> +@@ -39,6 +39,13 @@
> + [with_libargp=check]
> + )
> +
> ++AC_ARG_ENABLE([uclibc],
> ++AS_HELP_STRING([--enable-uclibc], [Use uclibc for system libraries]),
> ++use_uclibc=yes, use_uclibc=no)
> ++AM_CONDITIONAL(USE_UCLIBC, test "x$use_uclibc" = "xyes")
> ++AS_IF([test "x$use_uclibc" = "xyes"], [AC_DEFINE(USE_UCLIBC)])
> ++AH_TEMPLATE([USE_UCLIBC], [Defined if uclibc libraries are used.])
> ++
> + dnl Make sure anyone changing configure.ac/Makefile.am has a clue
> + AM_MAINTAINER_MODE
> +
> +@@ -101,7 +108,7 @@
> + [need_libargp=no],
> + [need_libargp=yes
> +  if test "x$with_libargp" = "xno"; then
> +-AC_MSG_FAILURE([libargp disabled and libc does 
> not have argp])
> ++AC_MSG_WARN([libargp disabled and libc does not 
> have argp])
> +  fi]
> + )
> + ],
> +@@ -110,7 +117,7 @@
> +
> + dnl Check for libargp
> + AS_IF(
> +-[test "x$need_libargp" = "xyes"],
> ++[test "x$need_libargp" = "xyes" -a "x$use_uclibc" = "xno"],
> + [
> + AC_CHECK_LIB(
> + [argp],
> +@@ -120,6 +127,19 @@
> + )
> + ]
> + )
> ++
> ++dnl Check for libuargp
> ++AS_IF(
> ++[test "x$use_uclibc" = "xyes"],
> ++[
> ++AC_CHECK_LIB(
> ++[uargp],
> ++[argp_parse],
> ++[LIBS="$LIBS -luargp"],
> ++[AC_MSG_FAILURE([libuargp not found])]
> ++)
> ++]
> ++)
> +
> + dnl -
> + dnl Configure options
> diff --git a/meta/recipes-support/rng-tools/rng-tools_5.bb 
> b/meta/recipes-support/rng-tools/rng-tools_5.bb
> index bc67990..53d2d61 100644
> --- a/meta/recipes-support/rng-tools/rng-tools_5.bb
> +++ b/meta/recipes-support/rng-tools/rng-tools_5.bb
> @@ -6,6 +6,7 @@ SRC_URI = 
> "http://heanet.dl.sourceforge.net/sourceforge/gkernel/${BP}.tar.gz \
>file://0001-If-the-libc-is-lacking-argp-use-libargp.patch \
>file://0002-Add-argument-to-control-the-libargp-dependency.patch \
>file://underquote.patch \
> +   file://uclibc-libuargp-configure.patch \

is there tab and space mix here ?

>file://init \
>file://default"
> 
> @@ -23,8 +24,9 @@ inherit autotools update-rc.d
> 
> PACKAGECONFIG = "libgcrypt"
> PACKAGECONFIG_libc-musl = "libargp"
> -PACKAGECONFIG_libc-uclibc = "libargp"
> +PACKAGECONFIG_libc-uclibc = "libuargp"
> PACKAGECONFIG[libargp] = "--with-libargp,--without-libargp,argp-standalone,"
> +PACKAGECONFIG[libuargp] = "--enable-uclibc,,,"
> PACKAGECONFIG[libgcrypt] = "--with-libgcrypt,--without-libgcrypt,libgcrypt,"
> 
> do_install_append() {
> --
> 2.4.0
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core