[OE-core] [PATCH] pulseaudio: 9.0 -> 10.0

[Tanu Kaskinen]

Relase notes:
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/10.0/

The checksum of the LICENSE file changed due to some clarifications.
There were no changes to the actual licensing terms.

The LICENSE variable was not accurate, so I made changes to it.
Specifically:
 * there's no GPL code in PulseAudio so I dropped GPL from the list
 * the LGPL code allows using later versions of the license rather than
   limiting to just 2.1
 * there are some MIT and BSD licensed bits

I added more files to LIC_FILES_CHKSUM to have better coverage of all
the differently licensed code.

Dropped json-c and gdbm from DEPENDS. The new release doesn't use json-c
any more. gdbm isn't used when --with-database=simple is passed to
configure, so it should have been removed from DEPENDS a long time ago.

The new release dropped the Xen module, so the --without-xen configure
option isn't needed any more.

Added a comment for why --without-fftw is used.

Disabled the adrian echo canceller, because it has an unusual license,
and disabling the code was simpler than adding a new license to OE-Core.

Dropped upstreamed patches.
---
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |  80 +++-
 ...oth-fail-if-user-requested-profile-doesn-.patch |  61 ---
 ...ard-don-t-allow-the-CARD_NEW-hook-to-fail.patch |  37 --
 ...-move-profile-selection-after-pa_card_new.patch | 429 -
 ...rd-remove-pa_card_new_data.active_profile.patch |  72 
 ...vailability-for-some-unavailable-profiles.patch |  79 
 .../pulseaudio/pulseaudio_10.0.bb  |  14 +
 .../pulseaudio/pulseaudio_9.0.bb   |  19 -
 8 files changed, 88 insertions(+), 703 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0001-alsa-bluetooth-fail-if-user-requested-profile-doesn-.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0002-card-don-t-allow-the-CARD_NEW-hook-to-fail.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0003-card-move-profile-selection-after-pa_card_new.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0004-card-remove-pa_card_new_data.active_profile.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0005-alsa-set-availability-for-some-unavailable-profiles.patch
 create mode 100644 meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb
 delete mode 100644 meta/recipes-multimedia/pulseaudio/pulseaudio_9.0.bb

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index f5c5ed29c9..818ff560cc 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -2,16 +2,69 @@ SUMMARY = "Sound server for Linux and Unix-like operating 
systems"
 HOMEPAGE = "http://www.pulseaudio.org;
 AUTHOR = "Lennart Poettering"
 SECTION = "libs/multimedia"
-LICENSE = "GPLv2+ & LGPLv2.1"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=d9ae089c8dc5339f8ac9d8563038a29f \
+
+# Most of PulseAudio code is under LGPLv2.1+. There are a few exceptions:
+#
+# The "adrian" echo canceller variant has code under a non-standard permissive
+# license. See src/modules/echo-cancel/adrian-license.txt for details. This
+# recipe disables the adrian echo canceller to avoid hassle with the unusual
+# license.
+#
+# The src/modules/reserve* and src/pulsecore/rtkit* files are under the MIT
+# license.
+#
+# The src/pulsecore/filter/ directory contains code under the 3-clause BSD
+# license.
+#
+# src/utils/qpaeq is licensed under AGPL. qpaeq is not installed by this
+# recipe, however, which is why AGPL is not mentioned in LICENSE.
+#
+# People who distribute PulseAudio binaries need to also consider that there
+# are some dependencies to GPL libraries. LGPL code that depends on GPL
+# libraries probably becomes effectively GPL-licensed (at compile-time? or at
+# at link-time?). I'm not a lawyer, though, so I'm not sure of the exact
+# implications. The GPL dependencies only affect the server, not the client
+# library, with the exception of libdbus that affects both. These are the GPL
+# library dependencies:
+#
+# One of the resampler implementations uses libsamplerate. This recipe doesn't
+# enable that resampler, however.
+#
+# One of the database implementations uses gdbm. This recipe doesn't enable
+# that database implementation, however.
+#
+# module-lirc (enabled by PACKAGECONFIG[lirc]) uses LIRC.
+#
+# module-equalizer-sink uses FFTW. This recipe disables that, however.
+#
+# The dependency with the most complicated licensing considerations is libdbus.
+# When PACKAGECONFIG[dbus] is enabled (like it is by default), libdbus will be
+# used by both the server and the client library (libpulse). Does this affect
+# applications that use libpulse? It should be also noted that libdbus is
+# dual-licensed: either GPLv2+ or AFL-2 terms apply. Whose decision is it which
+# of the licenses apply? What a mess. Some people 

Re: [OE-core] [PATCH v2 2/7] python3-manifest: move htlm.py to python3-html

[Anders Darander]

* Khem Raj  [170202 19:37]:

> On Thu, Feb 2, 2017 at 2:41 AM, Anders Darander  wrote:
> > * Khem Raj  [170201 17:52]:

> >> On 1/30/17 11:18 PM, Anders Darander wrote:
> >> > This allows us to use html.py without importing misc.

> >> html.py is provided by many packages. Does is make more sense to package
> >> html.py on a package of its own ?

> OK, I guess we have to address is when we have more occurances of
> packages providing html.py show up

Just a further note, there's a typo in the commit message, as can be
seen from the patch, it's not html.py per se, but rather `html/`...

Not that it makes a lot of difference...

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

Re: [OE-core] [PATCH 0/2] replace USE_LDCONFIG with ldconfig distro feature

[Khem Raj]

On Fri, Jan 27, 2017 at 2:29 PM, Andre McCurdy  wrote:
> Andre McCurdy (2):
>   bitbake.conf: replace USE_LDCONFIG with new "ldconfig" distro feature
>   systemd: check "ldconfig" distro feature when setting PACKAGECONFIG
>
>  meta/classes/package.bbclass  | 5 +
>  meta/conf/bitbake.conf| 2 +-
>  meta/recipes-core/glibc/glibc-package.inc | 9 +++--
>  meta/recipes-core/systemd/systemd_232.bb  | 2 +-
>  4 files changed, 6 insertions(+), 12 deletions(-)

This changeset looks good.

Acked-by: Khem Raj 

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

Re: [OE-core] [PATCH 0/2] replace USE_LDCONFIG with ldconfig distro feature

[Andre McCurdy]

On Fri, Jan 27, 2017 at 2:29 PM, Andre McCurdy  wrote:
> Andre McCurdy (2):
>   bitbake.conf: replace USE_LDCONFIG with new "ldconfig" distro feature
>   systemd: check "ldconfig" distro feature when setting PACKAGECONFIG

Ping!

>  meta/classes/package.bbclass  | 5 +
>  meta/conf/bitbake.conf| 2 +-
>  meta/recipes-core/glibc/glibc-package.inc | 9 +++--
>  meta/recipes-core/systemd/systemd_232.bb  | 2 +-
>  4 files changed, 6 insertions(+), 12 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] systemd: respect USE_LDCONFIG when setting default PACKAGECONFIG

[Khem Raj]

On Thu, Feb 2, 2017 at 4:58 PM, Andre McCurdy  wrote:
> On Mon, Jan 30, 2017 at 12:42 PM, Andre McCurdy  wrote:
>> On Thu, Jan 26, 2017 at 10:18 PM, Khem Raj  wrote:
>>> On Thu, Jan 26, 2017 at 8:06 PM, Andre McCurdy  wrote:
 Avoid trying to call ldconfig at run-time in distros which force
 USE_LDCONFIG to 0 and therefore don't provide it.
>
> Ping.
>
> Perhaps merge this simple patch first if there's no consensus on
> adding a distro config.


No, please ping the distro config patches instead.

>
 Signed-off-by: Andre McCurdy 
 ---
  meta/recipes-core/systemd/systemd_232.bb | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/meta/recipes-core/systemd/systemd_232.bb 
 b/meta/recipes-core/systemd/systemd_232.bb
 index cc8781e..cfe6958 100644
 --- a/meta/recipes-core/systemd/systemd_232.bb
 +++ b/meta/recipes-core/systemd/systemd_232.bb
 @@ -39,8 +39,10 @@ SRC_URI_append_libc-uclibc = "\
  "
  SRC_URI_append_qemuall = " 
 file://0001-core-device.c-Change-the-default-device-timeout-to-2.patch"

 +USE_LDCONFIG ?= "1"
>>>
>>> now that we have more recipes using this variables. I think it should
>>> to global config space. May be have it as a DISTRO_FEATURE is more
>>> appropriate
>>
>> Patches for both approaches have now been sent to the list.
>>
 +
  PACKAGECONFIG ??= "xz \
 -   ldconfig \
 +   ${@base_conditional('USE_LDCONFIG', '1', 'ldconfig', 
 '', d)} \
 ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', 
 '', d)} \
 ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 
 'xkbcommon', '', d)} \
 ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 
 'selinux', '', d)} \
 --
 1.9.1

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

Re: [OE-core] [PATCH] systemd: respect USE_LDCONFIG when setting default PACKAGECONFIG

[Andre McCurdy]

On Mon, Jan 30, 2017 at 12:42 PM, Andre McCurdy  wrote:
> On Thu, Jan 26, 2017 at 10:18 PM, Khem Raj  wrote:
>> On Thu, Jan 26, 2017 at 8:06 PM, Andre McCurdy  wrote:
>>> Avoid trying to call ldconfig at run-time in distros which force
>>> USE_LDCONFIG to 0 and therefore don't provide it.

Ping.

Perhaps merge this simple patch first if there's no consensus on
adding a distro config.

>>> Signed-off-by: Andre McCurdy 
>>> ---
>>>  meta/recipes-core/systemd/systemd_232.bb | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/meta/recipes-core/systemd/systemd_232.bb 
>>> b/meta/recipes-core/systemd/systemd_232.bb
>>> index cc8781e..cfe6958 100644
>>> --- a/meta/recipes-core/systemd/systemd_232.bb
>>> +++ b/meta/recipes-core/systemd/systemd_232.bb
>>> @@ -39,8 +39,10 @@ SRC_URI_append_libc-uclibc = "\
>>>  "
>>>  SRC_URI_append_qemuall = " 
>>> file://0001-core-device.c-Change-the-default-device-timeout-to-2.patch"
>>>
>>> +USE_LDCONFIG ?= "1"
>>
>> now that we have more recipes using this variables. I think it should
>> to global config space. May be have it as a DISTRO_FEATURE is more
>> appropriate
>
> Patches for both approaches have now been sent to the list.
>
>>> +
>>>  PACKAGECONFIG ??= "xz \
>>> -   ldconfig \
>>> +   ${@base_conditional('USE_LDCONFIG', '1', 'ldconfig', 
>>> '', d)} \
>>> ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', 
>>> '', d)} \
>>> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 
>>> 'xkbcommon', '', d)} \
>>> ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 
>>> 'selinux', '', d)} \
>>> --
>>> 1.9.1
>>>
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for image_types_wic: remove dependency to do_bootimg

[Patchwork]

== Series Details ==

Series: image_types_wic: remove dependency to do_bootimg
Revision: 1
URL   : https://patchwork.openembedded.org/series/5124/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 424768191b)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] ✗ patchtest: failure for pkgconfig: fix typo introduced during recent conversion to PACKAGECONFIG

[Patchwork]

== Series Details ==

Series: pkgconfig: fix typo introduced during recent conversion to PACKAGECONFIG
Revision: 1
URL   : https://patchwork.openembedded.org/series/5121/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 424768191b)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] ✗ patchtest: failure for eudev: add RPROVIDES so eudev-hwdb provides udev-hwdb

[Patchwork]

== Series Details ==

Series: eudev: add RPROVIDES so eudev-hwdb provides udev-hwdb
Revision: 1
URL   : https://patchwork.openembedded.org/series/5119/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 424768191b)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH] image_types_wic: remove dependency to do_bootimg

[Ed Bartosh]

Removing task dependency do_wic -> do_bootimg as wic
doesn't depend on hddimg/booimg anymore.

Signed-off-by: Ed Bartosh 
---
 meta/classes/image_types_wic.bbclass | 5 -
 1 file changed, 5 deletions(-)

diff --git a/meta/classes/image_types_wic.bbclass 
b/meta/classes/image_types_wic.bbclass
index 3e98959..ec6c14d 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -41,11 +41,6 @@ WKS_FILE_CHECKSUM = "${@'${WKS_FULL_PATH}:%s' % 
os.path.exists('${WKS_FULL_PATH}
 do_image_wic[file-checksums] += "${WKS_FILE_CHECKSUM}"
 do_image_wic[depends] += "wic-tools:do_build"
 
-python () {
-if d.getVar('USING_WIC') and 'do_bootimg' in d:
-bb.build.addtask('do_image_wic', '', 'do_bootimg', d)
-}
-
 python do_write_wks_template () {
 """Write out expanded template contents to WKS_FULL_PATH."""
 import re
-- 
2.1.4

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

Re: [OE-core] [PATCH 2/2] Revert "kernel: Modify kernel modules installation path."

[Amarnath Valluri]

Hi,

I am very sorry, i couldn't respond earlier than this, somehow i missed
this thread :(

The motivation of these patches was achieving merged '/usr' in oe-core,
which demands no package installs anything into root(/bin, /sbin, /lib)
folders, and i see no exception for kernel modules/firmware(may be i am
wrong :!). In the real merged usr environment this shouldn't be a
problem as the root symlinks exists.

I guess i can resend these patches as part of 'usrmerge' feature patch
sequence, by keeping these changes behind DISTRO_FEATURES check:

- Amarnath


On Fri, 2017-01-20 at 08:04 -0600, Jason Wessel wrote:
> On 01/20/2017 07:52 AM, Burton, Ross wrote:
> 
> > 
> > On 20 January 2017 at 13:48, Jason Wessel
> >  wrote:
> > WARNING: linux-yocto-4.8.12+gitAUTOINC
> > +3edb4de355_9bcb4ea3fa-r0 do_package: QA Issue: linux-yocto:
> > Files/directories were installed but not shipped in any
> > package:
> >   /lib64
> >   /lib/modules/4.8.17-yocto-standard/modules.builtin
> >   /lib64/firmware
> >   /lib64/firmware/cpia2
> >   /lib64/firmware/cpia2/stv0672_vp4.bin
> > Please set FILES such that these items are packaged.
> > Alternatively if they are unneeded, avoid installing them or
> > delete them within do_install.
> > linux-yocto: 5 installed and not shipped files.
> > [installed-vs-shipped]
> > 
> > I suspect this is trivial with fresh eyes.  What multilib
> > configuration are you using?  My usual "test multilib" stanza is:
> > 
> > 
> > #require conf/multilib.conf
> > #MULTILIBS_x86-64 = "multilib:lib32"
> > #DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> > 
> > 
> > I'm guessing this isn't going to produce the same paths that you're
> > seeing problems with.
> > 
> > 
> > Ross
> 
> 
> It looks like it probably should. 
> 
> 
> MULTILIBS = "multilib:lib32"
> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> 
> 
> 
> If for some reason you wanted to perform the exact same build I have
> the instructions to do so:
> 
> https://github.com/WindRiver-OpenSourceLabs/wr-core/blob/master/docs/README-intel-x86.TXT
> 
> 
> That basically amounts to:
> 
> git clone -b master --recurse-submodules
> https://github.com/WindRiver-OpenSourceLabs/wr-core
> 
> cd wr-core
> 
> . init-intel-x86-env
> 
> 
> Jason. 
> 
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

[OE-core] [PATCH v2] selftest/buildoptions: force compile task instead of cleaning sstates

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval 

There is no need to clean m4 sstates, use force instead.

Signed-off-by: Leonardo Sandoval 
---
 meta/lib/oeqa/selftest/buildoptions.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/selftest/buildoptions.py 
b/meta/lib/oeqa/selftest/buildoptions.py
index d40eb00..a6cdc2d 100644
--- a/meta/lib/oeqa/selftest/buildoptions.py
+++ b/meta/lib/oeqa/selftest/buildoptions.py
@@ -36,8 +36,8 @@ class ImageOptionsTests(oeSelfTest):
 p = get_bb_var('SYSROOT_DESTDIR', 'ccache-native') + 
get_bb_var('bindir', 'ccache-native') + "/" + "ccache"
 self.assertTrue(os.path.isfile(p), msg = "No ccache found (%s)" % p)
 self.write_config('INHERIT += "ccache"')
-bitbake("m4 -c cleansstate")
-bitbake("m4 -c compile")
+bitbake("m4 -c compile -f")
+bitbake("m4 -c clean")
 self.addCleanup(bitbake, 'ccache-native -ccleansstate')
 res = runCmd("grep ccache %s" % 
(os.path.join(get_bb_var("WORKDIR","m4"),"temp/log.do_compile")), 
ignore_status=True)
 self.assertEqual(0, res.status, msg="No match for ccache in m4 
log.do_compile. For further details: %s" % 
os.path.join(get_bb_var("WORKDIR","m4"),"temp/log.do_compile"))
-- 
2.1.4

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

[OE-core] [PATCH] pkgconfig: fix typo introduced during recent conversion to PACKAGECONFIG

[Andre McCurdy]

Signed-off-by: Andre McCurdy 
---
 meta/recipes-devtools/pkgconfig/pkgconfig_git.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb 
b/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
index 5f2a5b6..422c5f3 100644
--- a/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
+++ b/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb
@@ -24,7 +24,8 @@ inherit autotools
 
 PACKAGECONFIG ??= "glib"
 PACKAGECONFIG_class-native = ""
-PACKAGECONFIG_class-native = ""
+PACKAGECONFIG_class-nativesdk = ""
+
 PACKAGECONFIG[glib] = "--without-internal-glib,--with-internal-glib,glib-2.0 
pkgconfig-native"
 
 acpaths = "-I ."
-- 
1.9.1

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

[OE-core] [PATCH v2] selftest/archiver: invalidate stamps instead of removing TMPDIR

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval 

There is no need to remove the whole TMPDIR, instead just invalidate
stamps and build again the targets.

Signed-off-by: Leonardo Sandoval 
---
 meta/lib/oeqa/selftest/archiver.py | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/selftest/archiver.py 
b/meta/lib/oeqa/selftest/archiver.py
index 97b6f5b..0af9634 100644
--- a/meta/lib/oeqa/selftest/archiver.py
+++ b/meta/lib/oeqa/selftest/archiver.py
@@ -28,8 +28,13 @@ class Archiver(oeSelfTest):
 features += 'COPYLEFT_PN_EXCLUDE = "%s"\n' % exclude_recipe
 self.write_config(features)
 
-shutil.rmtree(get_bb_var('TMPDIR'))
-bitbake("%s %s" % (include_recipe, exclude_recipe))
+# build again include/exclude recipes
+bitbake("-C fetch %s" % include_recipe)
+bitbake("-C fetch %s" % exclude_recipe)
+
+# clean output files and stamps
+bitbake("-c clean %s" % include_recipe)
+bitbake("-c clean %s" % exclude_recipe)
 
 src_path = os.path.join(get_bb_var('DEPLOY_DIR_SRC'), 
get_bb_var('TARGET_SYS'))
 
-- 
2.1.4

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

Re: [OE-core] host-user-contaminated QA check

[Seebs]

On Thu, 02 Feb 2017 20:43:49 +0100
Patrick Ohly  wrote:

> One could argue that an implicit "created during build -> owned by
> root" follows the same logic. But as the check as it is now did find
> a real issue and also others in the past (the pseudo bugs that Chris
> mentioned), let's keep it.

I am somewhat inclined to change pseudo's default to "if there's no
entry, report something definitely invalid", or make that an available
option, because that would avoid false positives, and allow a more
rigorous QA check.

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

Re: [OE-core] host-user-contaminated QA check

[Patrick Ohly]

On Thu, 2017-02-02 at 13:11 -0600, Seebs wrote:
> On Thu, 02 Feb 2017 18:17:29 +0100
> Patrick Ohly  wrote:
> 
> > On Thu, 2017-02-02 at 11:12 -0600, Seebs wrote:
> > > > But I find mapping to root:root more attractive because it makes
> > > > packaging simpler (less worries about accidentally copying the
> > > > original uid) and the builds faster (no need to run the QA check).
> 
> > > Hmm. I think I would rather have the QA check, because if a file's
> > > supposed to be non-root, and ends up root instead, that could cause
> > > subtle problems, but we'd no longer have a way to *detect* those
> > > problems.
> 
> > But that's not the kind of the problem detected by the QA check, is
> > it?
> > 
> > It warns when the owner of the file is the same as the user who did
> > the build, but because root isn't (normally) used for building, files
> > accidentally owned by root on the target won't trigger the warning.
> 
> Right. But the purpose of that is to detect files which didn't get
> their ownership correctly set. If we change to a default which we can't
> detect, then we can't detect "files which were supposed to have an
> ownership but didn't get it".

Got it - that's the same concern I had with 'it hides
such sloppy use of "cp"'.

> ("Created under pseudo" is enough to count as "ownership determined by
> recipe", it doesn't have to be an explicit chown.)

One could argue that an implicit "created during build -> owned by root"
follows the same logic. But as the check as it is now did find a real
issue and also others in the past (the pseudo bugs that Chris
mentioned), let's keep it.

-- 
Best Regards, Patrick Ohly

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



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

Re: [OE-core] host-user-contaminated QA check

[Patrick Ohly]

On Thu, 2017-02-02 at 18:49 +0100, Enrico Scholz wrote:
> Patrick Ohly 
> writes:
> 
> > Recently the host-user-contaminated QA check triggered for the trousers
> > recipe in meta-security:
> >
> > WARNING: trousers-0.3.14+gitAUTOINC+4b9a70d578-r0 do_package_qa: QA Issue: 
> > trousers: /trousers/etc/tcsd.conf is owned by uid 1000, which is the same 
> > as the user running bitbake. This may be due to host contamination 
> > [host-user-contaminated]
> >
> > However, that's a false positive in this case. UID 1000 got assigned to
> > the "tss" user in the target sysroot during the build, and tcsd.conf is
> > correctly and intentionally owned by that user because tcsd checks
> > ownership and refuses to start when owned by someone else (including
> > root). It just happened that the UID was the same.
> >
> > This is likely to affect all recipes with files owned by dynamically
> > created users, in particular when the host system assigns UIDs from the
> > same range as the target system (quick poll: who else has 1000 as his
> > UID on his main Linux box? ;-)
> 
> Usually, this can not happen.  There is reserved a range for dynamically
> created users (standard says 100-499, some distributions use 100-999).
> 
> In this case, there is probably some '--system' flag missing when the
> 'tss' user is created (--> packaging bug).

That's a good point. I hadn't considered that.

In that case the QA check has found a real problem, albeit reported it
in a way that it wasn't obvious what was going on - probably the message
should get extended. I therefore retract my earlier proposal.

-- 
Best Regards, Patrick Ohly

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



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

Re: [OE-core] host-user-contaminated QA check

[Seebs]

On Thu, 02 Feb 2017 18:17:29 +0100
Patrick Ohly  wrote:

> On Thu, 2017-02-02 at 11:12 -0600, Seebs wrote:
> > > But I find mapping to root:root more attractive because it makes
> > > packaging simpler (less worries about accidentally copying the
> > > original uid) and the builds faster (no need to run the QA check).

> > Hmm. I think I would rather have the QA check, because if a file's
> > supposed to be non-root, and ends up root instead, that could cause
> > subtle problems, but we'd no longer have a way to *detect* those
> > problems.

> But that's not the kind of the problem detected by the QA check, is
> it?
> 
> It warns when the owner of the file is the same as the user who did
> the build, but because root isn't (normally) used for building, files
> accidentally owned by root on the target won't trigger the warning.

Right. But the purpose of that is to detect files which didn't get
their ownership correctly set. If we change to a default which we can't
detect, then we can't detect "files which were supposed to have an
ownership but didn't get it".

The idea here is that, although there's some performance cost, we
*intend* to require that every file installed have its ownership
determined in some way by the recipe, and if you don't do this but copy
in files you didn't set ownership on somehow, we want to detect that.

("Created under pseudo" is enough to count as "ownership determined by
recipe", it doesn't have to be an explicit chown.)

I think that, if we default to root:root, we'll end up with recipe
errors going unnoticed, when they could have been caught. And if we
default to -3:-3 or something similar, I think we'll catch errors we're
currently missing. For instance, what happens if a recipe copies host
/etc/services in, preserving ownership? Right now, we get a plausible
answer, but that's still actually host contamination!

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

Re: [OE-core] [PATCH v2 2/7] python3-manifest: move htlm.py to python3-html

[Khem Raj]

On Thu, Feb 2, 2017 at 2:41 AM, Anders Darander  wrote:
> * Khem Raj  [170201 17:52]:
>
>> On 1/30/17 11:18 PM, Anders Darander wrote:
>> > This allows us to use html.py without importing misc.
>
>> html.py is provided by many packages. Does is make more sense to package
>> html.py on a package of its own ?
>
> Hm, I had another look at this. On my build:
>
> $ du -sh python3-html/
> 140Kpython3-html/
>
> $ du -sh python3-html/usr/lib/python3.5/html/
> 108Kpython3-html/usr/lib/python3.5/html/
>
> Thus, the major part, 77%, of python3-html is related to my change.
> Thus, I'm not sure that it makes sense to put html in it's own
> package...
>
> I'm not going to add a new package for html for the moment.
>

OK, I guess we have to address is when we have more occurances of
packages providing html.py show up
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] eudev: add RPROVIDES so eudev-hwdb provides udev-hwdb

[Ross Burton]

Otherwise the common name udev-hwdb is only provided by systemd, meaning that
other recipes can't depend on a single name.

Signed-off-by: Ross Burton 
---
 meta/recipes-core/udev/eudev_3.2.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/udev/eudev_3.2.bb 
b/meta/recipes-core/udev/eudev_3.2.bb
index 385ee7a..11931bc 100644
--- a/meta/recipes-core/udev/eudev_3.2.bb
+++ b/meta/recipes-core/udev/eudev_3.2.bb
@@ -81,6 +81,7 @@ RDEPENDS_eudev-hwdb += "eudev"
 RRECOMMENDS_${PN} += "udev-cache"
 
 RPROVIDES_${PN} = "hotplug udev"
+RPROVIDES_eudev-hwdb += "udev-hwdb"
 
 python () {
 if bb.utils.contains ('DISTRO_FEATURES', 'systemd', True, False, d):
-- 
2.8.1

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

Re: [OE-core] host-user-contaminated QA check

[Enrico Scholz]

Patrick Ohly 
writes:

> Recently the host-user-contaminated QA check triggered for the trousers
> recipe in meta-security:
>
> WARNING: trousers-0.3.14+gitAUTOINC+4b9a70d578-r0 do_package_qa: QA Issue: 
> trousers: /trousers/etc/tcsd.conf is owned by uid 1000, which is the same as 
> the user running bitbake. This may be due to host contamination 
> [host-user-contaminated]
>
> However, that's a false positive in this case. UID 1000 got assigned to
> the "tss" user in the target sysroot during the build, and tcsd.conf is
> correctly and intentionally owned by that user because tcsd checks
> ownership and refuses to start when owned by someone else (including
> root). It just happened that the UID was the same.
>
> This is likely to affect all recipes with files owned by dynamically
> created users, in particular when the host system assigns UIDs from the
> same range as the target system (quick poll: who else has 1000 as his
> UID on his main Linux box? ;-)

Usually, this can not happen.  There is reserved a range for dynamically
created users (standard says 100-499, some distributions use 100-999).

In this case, there is probably some '--system' flag missing when the
'tss' user is created (--> packaging bug).



Enrico
-- 
SIGMA Chemnitz GmbH   Registergericht:   Amtsgericht Chemnitz HRB 1750
Am Erlenwald 13   Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
09128 Chemnitz
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] uninative: Make patchelf modified files sparse

[Richard Purdie]

When we switched to recipe specific sysroots (rss), performance took a nose 
dive. Its
easy to blame rss but it turns out not to be entirely at fault.

Three configurations are compared here:

a) Pre-RSS (revision 45df694a9f472ac2f684aadac4d864c3dfdc48a7)
b) Post-RSS (revision 226a508da955439b881b2f0a544a3aee76e59919)
c) as b) with this change

Overall build times:

a) 22794.25user 2687.88system 30:32.84elapsed 1390%CPU (0avgtext+0avgdata 
919056maxresident)k
b) 22677.25user 3238.79system 36:16.68elapsed 1190%CPU (0avgtext+0avgdata 
918896maxresident)k
c) 23571.84user 3383.65system 31:36.83elapsed 1421%CPU (0avgtext+0avgdata 
919068maxresident)k

For the overall build and sstate directories, du -s shows:
a)
3992588   build-pre-rss/sstate-cache
30804484  build-pre-rss/tmp
b)
4013272   build-with-rss/sstate-cache
36519084  build-with-rss/tmp
c)
4014744   build-with-rss2/sstate-cache
35336960  build-with-rss2/tmp

However more worryingly:

$ du -s build-pre-rss/tmp/sysroots/
2506092 build-pre-rss/tmp/sysroots/
$ du -s build-with-rss/tmp/sysroots-components/
3790712 build-with-rss/tmp/sysroots-components/
$ du -s build-with-rss2/tmp/sysroots-components/
2467544 build-with-rss2/tmp/sysroots-components/

These numbers *should* be equivalent but as you can see, b) is ~1.2GB larger. 
The reason turned out
to be patchelf. Taking a specific binary from a specific recipe, bc from 
bc-native, in a) its 82kb
(stripped) yet in b) its 2.17MB.

$ ./patchelf --set-interpreter /bin/rp bc
warning: working around a Linux kernel bug by creating a hole of 2084864 bytes 
in ‘bc’

https://github.com/NixOS/patchelf/blob/master/src/patchelf.cc#L710 shows that 
this "hole" is just
padded zeros using memset, its not a proper sparse hole.

This patch copies files with cp --sparse=always after modifying them with 
patchelf, then replacing
the original file. The better fix will be to fix this in patchself itself and 
seek() there
when writing the new file but that means new uninative tarballs and will take a 
bit of work
so I'm proposing this workaround in the meantime.

Also, this patch drops error handling since subprocess check_output() 
tracebacks will print this
information if the command fails so we can simplify the code.
---
 meta/classes/uninative.bbclass | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 410fb72..0d1063a 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -121,11 +121,8 @@ python uninative_changeinterp () {
 if not elf.isDynamic():
 continue
 
-try:
-subprocess.check_output(("patchelf-uninative", 
"--set-interpreter",
- d.getVar("UNINATIVE_LOADER"), f),
-stderr=subprocess.STDOUT)
-except subprocess.CalledProcessError as e:
-bb.fatal("'%s' failed with exit code %d and the following 
output:\n%s" %
- (e.cmd, e.returncode, e.output))
+subprocess.check_output(("patchelf-uninative", 
"--set-interpreter", d.getVar("UNINATIVE_LOADER"), f), stderr=subprocess.STDOUT)
+subprocess.check_output(("cp", "--sparse=always", f, f + 
".sparse"), stderr=subprocess.STDOUT)
+os.unlink(f)
+os.rename(f + ".sparse", f)
 }
-- 
2.7.4

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

Re: [OE-core] host-user-contaminated QA check

[Christopher Larson]

It's worth noting that host-user-contaminated also triggers on pseudo bugs,
which I've seen before. If we change the behavior, what user would files
that pseudo loses track of entirely be owned by? Or perhaps some of
pseudo's log messages should be made errors..

On Thu, Feb 2, 2017 at 10:17 AM, Patrick Ohly 
wrote:

> On Thu, 2017-02-02 at 11:12 -0600, Seebs wrote:
> > > But I find mapping to root:root more attractive because it makes
> > > packaging simpler (less worries about accidentally copying the
> > > original uid) and the builds faster (no need to run the QA check).
> >
> > Hmm. I think I would rather have the QA check, because if a file's
> > supposed to be non-root, and ends up root instead, that could cause
> > subtle problems, but we'd no longer have a way to *detect* those
> > problems.
>
> But that's not the kind of the problem detected by the QA check, is it?
>
> It warns when the owner of the file is the same as the user who did the
> build, but because root isn't (normally) used for building, files
> accidentally owned by root on the target won't trigger the warning.
>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] host-user-contaminated QA check

[Patrick Ohly]

On Thu, 2017-02-02 at 11:12 -0600, Seebs wrote:
> > But I find mapping to root:root more attractive because it makes
> > packaging simpler (less worries about accidentally copying the
> > original uid) and the builds faster (no need to run the QA check).
> 
> Hmm. I think I would rather have the QA check, because if a file's
> supposed to be non-root, and ends up root instead, that could cause
> subtle problems, but we'd no longer have a way to *detect* those
> problems.

But that's not the kind of the problem detected by the QA check, is it?

It warns when the owner of the file is the same as the user who did the
build, but because root isn't (normally) used for building, files
accidentally owned by root on the target won't trigger the warning.

-- 
Best Regards, Patrick Ohly

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



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

Re: [OE-core] host-user-contaminated QA check

[Seebs]

On Thu, 02 Feb 2017 17:39:07 +0100
Patrick Ohly  wrote:

> On Thu, 2017-02-02 at 10:21 -0600, Seebs wrote:
> > On Thu, 02 Feb 2017 11:38:00 +0100
> > Patrick Ohly  wrote:
> > 
> > > Why do we make the real user ID on the build system visible at all
> > > when running under pseudo? The uid and user name have no meaning
> > > there, as the user won't exist on the target system. Instead we
> > > could map the owner of all files to root:root by default, i.e. in
> > > those cases where no other ownership is recorded in the pseudo
> > > database.
> > 
> > We could. Honestly, the underlying reason we don't is at least in
> > part that that makes the behavior differ more from the behavior of
> > "sudo"; with sudo, you see actual ownerships. But that's less
> > applicable here.
> > 
> > I would be more inclined to report a Definitely Absolutely Not Okay
> > user ID, like 65533. (65534 and 65535 have both been used as Magic
> > Cookies in the past, I think.)
> 
> I had considered that approach myself, too. It would make the QA check
> reliable and in that sense solve the problem.
> 
> But I find mapping to root:root more attractive because it makes
> packaging simpler (less worries about accidentally copying the
> original uid) and the builds faster (no need to run the QA check).

Hmm. I think I would rather have the QA check, because if a file's
supposed to be non-root, and ends up root instead, that could cause
subtle problems, but we'd no longer have a way to *detect* those
problems.

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

Re: [OE-core] host-user-contaminated QA check

[Patrick Ohly]

On Thu, 2017-02-02 at 10:21 -0600, Seebs wrote:
> On Thu, 02 Feb 2017 11:38:00 +0100
> Patrick Ohly  wrote:
> 
> > Why do we make the real user ID on the build system visible at all
> > when running under pseudo? The uid and user name have no meaning
> > there, as the user won't exist on the target system. Instead we could
> > map the owner of all files to root:root by default, i.e. in those
> > cases where no other ownership is recorded in the pseudo database.
> 
> We could. Honestly, the underlying reason we don't is at least in part
> that that makes the behavior differ more from the behavior of "sudo";
> with sudo, you see actual ownerships. But that's less applicable here.
> 
> I would be more inclined to report a Definitely Absolutely Not Okay
> user ID, like 65533. (65534 and 65535 have both been used as Magic
> Cookies in the past, I think.)

I had considered that approach myself, too. It would make the QA check
reliable and in that sense solve the problem.

But I find mapping to root:root more attractive because it makes
packaging simpler (less worries about accidentally copying the original
uid) and the builds faster (no need to run the QA check).

-- 
Best Regards, Patrick Ohly

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



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

Re: [OE-core] host-user-contaminated QA check

[Seebs]

On Thu, 02 Feb 2017 11:38:00 +0100
Patrick Ohly  wrote:

> Why do we make the real user ID on the build system visible at all
> when running under pseudo? The uid and user name have no meaning
> there, as the user won't exist on the target system. Instead we could
> map the owner of all files to root:root by default, i.e. in those
> cases where no other ownership is recorded in the pseudo database.

We could. Honestly, the underlying reason we don't is at least in part
that that makes the behavior differ more from the behavior of "sudo";
with sudo, you see actual ownerships. But that's less applicable here.

I would be more inclined to report a Definitely Absolutely Not Okay
user ID, like 65533. (65534 and 65535 have both been used as Magic
Cookies in the past, I think.)

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

Re: [OE-core] [PATCHv4] qemu: Upgrade to 2.8.0

[Aníbal Limón]

On 01/31/2017 04:10 PM, Aníbal Limón wrote:
> Added patches:
> 
> - target-ppc-fix-user-mode.patch

The patch was integrated into qemu-ppc-for-2.9 branch and  then dropped
, now there are some discussions about the right fix so is better to
wait upstream to integrate the right fix.

Cheers,
alimon

> 
> Rebased patches:
> 
> - exclude-some-arm-EABI-obsolete-syscalls.patc
> 
> Removed patches (already in upstream):
> 
> - 0003-fix-CVE-2016-7908.patch
> - 0004-fix-CVE-2016-7909.patch
> - 0001-target-mips-add-24KEc-CPU-definition.patch
> 
> Changelog,
> 
> http://wiki.qemu.org/ChangeLog/2.8
> 
> Signed-off-by: Aníbal Limón 
> ---
>  meta/recipes-devtools/qemu/qemu.inc|  1 -
>  ...0001-target-mips-add-24KEc-CPU-definition.patch | 54 ---
>  .../qemu/qemu/0003-fix-CVE-2016-7908.patch | 62 
> --
>  .../qemu/qemu/0004-fix-CVE-2016-7909.patch | 42 ---
>  ...-Arm-versatilepb-Add-memory-size-checking.patch | 46 
>  .../exclude-some-arm-EABI-obsolete-syscalls.patch  | 22 +++-
>  .../qemu/qemu/target-ppc-fix-user-mode.patch   | 48 +
>  .../qemu/{qemu_2.7.1.bb => qemu_2.8.0.bb}  |  8 ++-
>  8 files changed, 59 insertions(+), 224 deletions(-)
>  delete mode 100644 
> meta/recipes-devtools/qemu/qemu/0001-target-mips-add-24KEc-CPU-definition.patch
>  delete mode 100644 
> meta/recipes-devtools/qemu/qemu/0003-fix-CVE-2016-7908.patch
>  delete mode 100644 
> meta/recipes-devtools/qemu/qemu/0004-fix-CVE-2016-7909.patch
>  delete mode 100644 
> meta/recipes-devtools/qemu/qemu/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
>  create mode 100644 
> meta/recipes-devtools/qemu/qemu/target-ppc-fix-user-mode.patch
>  rename meta/recipes-devtools/qemu/{qemu_2.7.1.bb => qemu_2.8.0.bb} (70%)
> 
> diff --git a/meta/recipes-devtools/qemu/qemu.inc 
> b/meta/recipes-devtools/qemu/qemu.inc
> index ac5fcac..e3af5c2 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -19,7 +19,6 @@ SRC_URI = "\
>  file://wacom.patch \
>  file://add-ptest-in-makefile.patch \
>  file://run-ptest \
> -file://0001-target-mips-add-24KEc-CPU-definition.patch \
>  "
>  
>  SRC_URI_append_class-native = "\
> diff --git 
> a/meta/recipes-devtools/qemu/qemu/0001-target-mips-add-24KEc-CPU-definition.patch
>  
> b/meta/recipes-devtools/qemu/qemu/0001-target-mips-add-24KEc-CPU-definition.patch
> deleted file mode 100644
> index c4dbee7..000
> --- 
> a/meta/recipes-devtools/qemu/qemu/0001-target-mips-add-24KEc-CPU-definition.patch
> +++ /dev/null
> @@ -1,54 +0,0 @@
> -From 926bc194f918d46bd93557b15da8153b6a94a1d5 Mon Sep 17 00:00:00 2001
> -From: =?UTF-8?q?Andr=C3=A9=20Draszik?= 
> -Date: Mon, 25 Jul 2016 23:58:22 +0100
> -Subject: [PATCH] target-mips: add 24KEc CPU definition
> -MIME-Version: 1.0
> -Content-Type: text/plain; charset=UTF-8
> -Content-Transfer-Encoding: 8bit
> -
> -Define a new CPU definition supporting 24KEc cores, similar to
> -the existing 24Kc, but with added support for DSP instructions
> -and MIPS16e (and without FPU).
> -
> -Signed-off-by: André Draszik 
> 
> -Upstream-Status: Submitted 
> [http://lists.nongnu.org/archive/html/qemu-devel/2016-07/msg05778.html]
> - target-mips/translate_init.c | 22 ++
> - 1 file changed, 22 insertions(+)
> -
> -diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
> -index 39ed5c4..6ae23e4 100644
>  a/target-mips/translate_init.c
> -+++ b/target-mips/translate_init.c
> -@@ -256,6 +256,28 @@ static const mips_def_t mips_defs[] =
> - .mmu_type = MMU_TYPE_R4000,
> - },
> - {
> -+.name = "24KEc",
> -+.CP0_PRid = 0x00019600,
> -+.CP0_Config0 = MIPS_CONFIG0 | (0x1 << CP0C0_AR) |
> -+   (MMU_TYPE_R4000 << CP0C0_MT),
> -+.CP0_Config1 = MIPS_CONFIG1 | (15 << CP0C1_MMU) |
> -+   (0 << CP0C1_IS) | (3 << CP0C1_IL) | (1 << CP0C1_IA) |
> -+   (0 << CP0C1_DS) | (3 << CP0C1_DL) | (1 << CP0C1_DA) |
> -+   (1 << CP0C1_CA),
> -+.CP0_Config2 = MIPS_CONFIG2,
> -+.CP0_Config3 = MIPS_CONFIG3 | (1 << CP0C3_DSPP) | (0 << CP0C3_VInt),
> -+.CP0_LLAddr_rw_bitmask = 0,
> -+.CP0_LLAddr_shift = 4,
> -+.SYNCI_Step = 32,
> -+.CCRes = 2,
> -+/* we have a DSP, but no FPU */
> -+.CP0_Status_rw_bitmask = 0x1378FF1F,
> -+.SEGBITS = 32,
> -+.PABITS = 32,
> -+.insn_flags = CPU_MIPS32R2 | ASE_MIPS16 | ASE_DSP,
> -+.mmu_type = MMU_TYPE_R4000,
> -+},
> -+{
> - .name = "24Kf",
> - .CP0_PRid = 0x00019300,
> - .CP0_Config0 = MIPS_CONFIG0 | (0x1 << CP0C0_AR) |
> --- 
> -2.8.1
> -
> diff --git a/meta/recipes-devtools/qemu/qemu/0003-fix-CVE-2016-7908.patch 
> 

Re: [OE-core] [PATCH 4/4] libgcrypt.inc: Enable use of binconfig

[Burton, Ross]

On 30 January 2017 at 07:47, Nathan Rossi  wrote:

> Due to pkg-config support for libgcrypt being un-available for upstream
> libgcrypt, some packages that depend on libgcrypt rely on the use of
> libgcrypt-config (e.g. QEMU).
>

We disable those scripts for a good reason: they're generally either broken
entirely in a cross-environment, or fail badly if sstate is used.A
better solution really is to just patch qemu's configure (yes, I know this
sucks).

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

Re: [OE-core] [PATCH] selftest: do not perform a full build in test_continue

[Alexander Kanavin]

On 02/02/2017 03:47 PM, Burton, Ross wrote:


 runCmd('bitbake -c cleanall man xcursor-transparent-theme')
-result = runCmd('bitbake man xcursor-transparent-theme -k',
ignore_status=True)
+result = runCmd('bitbake -c unpack -k man
xcursor-transparent-theme', ignore_status=True)


I also have to ask why it does cleanall.  Why isn't clean sufficient?


I guess because it's testing that fetching for one recipe fails but 
unpacking for another recipe succeeds, and getting those tasks to run 
requires cleanall?


Alex

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

[OE-core] [PATCH] usbutils: add dependency on udev-hwdb, not libudev

[Ross Burton]

libudev will be autodetected by the linkage, the intention here was to depend on
udev-hwdb to ensure that the USB ID lists are installed.

Signed-off-by: Ross Burton 
---
 meta/recipes-bsp/usbutils/usbutils_008.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/usbutils/usbutils_008.bb 
b/meta/recipes-bsp/usbutils/usbutils_008.bb
index 75312c3..cb79360 100644
--- a/meta/recipes-bsp/usbutils/usbutils_008.bb
+++ b/meta/recipes-bsp/usbutils/usbutils_008.bb
@@ -21,5 +21,5 @@ inherit autotools gettext pkgconfig distro_features_check
 
 FILES_${PN}-dev += "${datadir}/pkgconfig"
 
-RDEPENDS_${PN} = "libudev"
+RDEPENDS_${PN} = "udev-hwdb"
 RDEPENDS_${PN}-ptest = "libboost-system libboost-thread"
-- 
2.8.1

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

[OE-core] [PATCH 2/3] wic: direct: fix creation of work directory

[Ed Bartosh]

It was a typo in current code: mktemp was used instead of
mkdtemp to create work directory. This is fixed by using
mkdtemp.

Create work directory as a subdirectory of output directory
to make sure both are on the same partition to make moving
of result image faster.

This also fixes possible disk space issues as mkdtemp uses
TMPDIR, TEMP or TMP environment variables to get default value
of its 'dir' parameter. Those variables are usually pointing
to /tmp, which is not the best location to create huge images.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/plugins/imager/direct.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/imager/direct.py 
b/scripts/lib/wic/plugins/imager/direct.py
index 4637fbf3..b38e876 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -122,7 +122,7 @@ class DirectImageCreator:
 """
 self.name = name
 self.outdir = outdir
-self.workdir = tempfile.mktemp(prefix='wic')
+self.workdir = tempfile.mkdtemp(dir=outdir, prefix='tmp.wic.')
 self.ks = ksobj
 
 self._image = None
-- 
2.1.4

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

[OE-core] [PATCH 3/3] wic: get rid of image_output_dir variable

[Ed Bartosh]

Used options.outdir instead of image_output_dir.
There is no sense to use extra variable for this.

Signed-off-by: Ed Bartosh 
---
 scripts/wic | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/scripts/wic b/scripts/wic
index 33355ee..17e8231 100755
--- a/scripts/wic
+++ b/scripts/wic
@@ -203,10 +203,6 @@ def wic_create_subcommand(args, usage_str):
   "kickstart (.wks) filename)\n" % args[0])
 sys.exit(1)
 
-image_output_dir = ""
-if options.outdir:
-image_output_dir = options.outdir
-
 if not options.image_name:
 rootfs_dir = ''
 if 'ROOTFS_DIR' in options.rootfs_dir:
@@ -254,7 +250,7 @@ def wic_create_subcommand(args, usage_str):
 
 print("Creating image(s)...\n")
 engine.wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
-  native_sysroot, scripts_path, image_output_dir,
+  native_sysroot, scripts_path, options.outdir,
   options.compressor, options.bmap, options.debug)
 
 
-- 
2.1.4

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

[OE-core] [PATCH 1/3] wic: engine: create output dir

[Ed Bartosh]

Make sure output directory exists before creating an image.
Create it if it doesn't exist.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/engine.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py
index 592ef77..7fb6f13 100644
--- a/scripts/lib/wic/engine.py
+++ b/scripts/lib/wic/engine.py
@@ -187,6 +187,9 @@ def wic_create(wks_file, rootfs_dir, bootimg_dir, 
kernel_dir,
 if debug:
 msger.set_loglevel('debug')
 
+if not os.path.exists(image_output_dir):
+os.makedirs(image_output_dir)
+
 crobj = creator.Creator()
 
 cmdline = ["direct", native_sysroot, kernel_dir, bootimg_dir, rootfs_dir,
-- 
2.1.4

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

[OE-core] [PATCH 0/3] wic: fix creation of working directory

[Ed Bartosh]

Hi,

Changed working directory to be subdirectory of output dir.
This should fix several possible issues:
- current code uses mktemp which doesn't create anything
- default temporary directory is created in /tmp, which can
  cause wic to take long time to move result image as output
  directory can be on another partition
- possible disk space issues due to the /tmp usage

The following changes since commit 7d75fd29296a9c411881b4288bff2e02cb145a25:

  wic: remove syslinux.py (2017-02-01 12:46:17 +0200)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ed/wic/refactoring-10619
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ed/wic/refactoring-10619

Ed Bartosh (3):
  wic: engine: create output dir
  wic: direct: fix creation of work directory
  wic: get rid of image_output_dir variable

 scripts/lib/wic/engine.py| 3 +++
 scripts/lib/wic/plugins/imager/direct.py | 2 +-
 scripts/wic  | 6 +-
 3 files changed, 5 insertions(+), 6 deletions(-)

--
2.1.4

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

Re: [OE-core] [PATCH] selftest: do not perform a full build in test_continue

[Burton, Ross]

On 2 February 2017 at 13:26, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

>  runCmd('bitbake -c cleanall man xcursor-transparent-theme')
> -result = runCmd('bitbake man xcursor-transparent-theme -k',
> ignore_status=True)
> +result = runCmd('bitbake -c unpack -k man
> xcursor-transparent-theme', ignore_status=True)
>

I also have to ask why it does cleanall.  Why isn't clean sufficient?

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

[OE-core] [PATCH] selftest: do not perform a full build in test_continue

[Alexander Kanavin]

This was fetching and building the toolchain and everything else
against empty download dir and sstate cache, and so was enormously slow.
The test does not need that, it only checks that one fetch task fails and
another succeeds when using bitbake's -k option.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oeqa/selftest/bbtests.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/bbtests.py 
b/meta/lib/oeqa/selftest/bbtests.py
index c4e50cbfa0f..a3b03eaac34 100644
--- a/meta/lib/oeqa/selftest/bbtests.py
+++ b/meta/lib/oeqa/selftest/bbtests.py
@@ -221,7 +221,7 @@ INHERIT_remove = \"report-error\"
 self.track_for_cleanup(os.path.join(self.builddir, 
"download-selftest"))
 self.write_recipeinc('man',"\ndo_fail_task () {\nexit 1 \n}\n\naddtask 
do_fail_task before do_fetch\n" )
 runCmd('bitbake -c cleanall man xcursor-transparent-theme')
-result = runCmd('bitbake man xcursor-transparent-theme -k', 
ignore_status=True)
+result = runCmd('bitbake -c unpack -k man xcursor-transparent-theme', 
ignore_status=True)
 errorpos = result.output.find('ERROR: Function failed: do_fail_task')
 manver = re.search("NOTE: recipe xcursor-transparent-theme-(.*?): task 
do_unpack: Started", result.output)
 continuepos = result.output.find('NOTE: recipe 
xcursor-transparent-theme-%s: task do_unpack: Started' % manver.group(1))
-- 
2.11.0

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

Re: [OE-core] [PATCH 1/4] selftest/buildoptions: use a thinner image to test 'read-only-rootfs' feature

[Burton, Ross]

On 31 January 2017 at 22:50, 
wrote:

> The minimal is much faster to build that sato, so use the former to test
> read-only feature.
>

What Patrick and Richard said.  In particular, it's things like the
gdk-pixbuf and fontconfig postinsts which we need to ensure are not
delayed, and these are not in minimal images.

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

[OE-core] State of bitbake world, Failed tasks 2017-02-01

[Martin Jansa]

On Tue, Jan 31, 2017 at 06:10:49PM +0100, Martin Jansa wrote:
> There is a lot more failures this time (mostly because of RSS), but
> I wanted to share it anyway, to be clear about the current state of
> other layers.
> :

Still a lot of failures, I've updated the report script to stop
processing test-dependencies jenkins jobs, so it's a bit shorter now,
I've sent fixes for firefox*, geoclue and vboxguestdrivers, so next
report shouls be at least 50 lines shorter as well.

== Number of issues - stats ==
{| class='wikitable'
!|Date   !!colspan='3'|Failed tasks 
!!colspan='6'|Failed depencencies!!|Signatures
!!colspan='12'|QA !!Comment
|-
||  ||qemuarm   ||qemux86   ||qemux86_64
||qemuarm||max||min ||qemux86||max||min ||all   ||already-stripped  
||libdir||textrel   ||build-deps||file-rdeps
||version-going-backwards   ||host-user-contaminated
||installed-vs-shipped  ||unknown-configure-option  ||symlink-to-sysroot
||invalid-pkgconfig ||pkgname   ||  
|-
||2017-02-01||178   ||184   ||182   ||N/A   ||N/A   ||N/A   ||N/A   ||N/A   
||N/A   ||0 ||0 ||0 ||2 ||0 
||6 ||156   ||0 ||2 ||0 
||0 ||0 ||0 ||  
|}

http://www.openembedded.org/wiki/Bitbake_World_Status

== Failed tasks 2017-02-01 ==

INFO: jenkins-job.sh-1.8.15 Complete log available at 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.report.20170202_004847.log

=== common (176) ===
* 
meta-browser/recipes-mozilla/firefox-addon/firefox-addon-webconverger_git.bb:do_configure
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-ach_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-af_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-an_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-ar_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-as_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-ast_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-az_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-be_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-bg_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-bn-bd_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-bn-in_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-br_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-bs_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-ca_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-cs_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-cy_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-da_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-de_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-dsb_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-el_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-en-gb_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-en-us_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-en-za_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-eo_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-es-ar_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-es-cl_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-es-es_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-es-mx_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-et_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-eu_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-fa_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-ff_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-fi_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-fr_45.6.0esr.bb:do_install
* 
meta-browser/recipes-mozilla/firefox-l10n/firefox-l10n-fy-nl_45.6.0esr.bb:do_install
* 

Re: [OE-core] [PATCH] gdb 7.12: fix armv8b build

[Burton, Ross]

On 2 February 2017 at 10:28, Koen Kooi  wrote:

> +++ b/meta/recipes-devtools/gdb/gdb/cb93dc7f262978bafe36397a41a56e
> 409a302042.patch
> @@ -0,0 +1,42 @@
> +From cb93dc7f262978bafe36397a41a56e409a302042 Mon Sep 17 00:00:00 2001
> +From: Yao Qi 
> +Date: Mon, 24 Oct 2016 10:59:11 +0100
> +Subject: [PATCH] [GDBserver] Fix conversion warning
> +
> +I got the following warning if I build GDBserver for aarch64_be-linux-gnu,
> +
> +git/gdb/gdbserver/linux-aarch64-low.c:1539:39: error: invalid conversion
> from 'void*' to 'uint32_t* {aka unsigned int*}' [-fpermissive]
> +   uint32_t *le_buf = xmalloc (byte_len);
> +   ^
> +The patch is to fix the warning.
> +
> +gdb/gdbserver:
> +
> +2016-10-24  Yao Qi  
> +
> +   PR server/20733
> +   * linux-aarch64-low.c (append_insns): Cast the return value to
> +   'uint32_t *'.
> +
> +Upstream-status: Backport
>

That's not the nicest patch filename, and needs a S-o-b.

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

Re: [OE-core] [PATCH] glib-2.0: native package should not depend on DISTRO_FEATURES

[Burton, Ross]

On 31 January 2017 at 05:08, Gary Thomas  wrote:

> Ping?
>

Staged locally, thanks Gary.

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

Re: [OE-core] [PATCH] libtasn1: depends on yacc

[Patrick Ohly]

On Wed, 2017-02-01 at 08:56 -0800, Khem Raj wrote:
> 
> On 1/31/17 1:05 AM, Patrick Ohly wrote:
> > This fixes a potential pollution by the build host and build error
> > when yacc isn't installed on the build host:
> > 
> >  | ../../libtasn1-4.9/build-aux/ylwrap: line 175: yacc: command not found
> >  | Makefile:1116: recipe for target 'ASN1.c' failed
> >  | make[3]: *** [ASN1.c] Error 127
> > 
> > Signed-off-by: Patrick Ohly 
> > ---
> >  meta/recipes-support/gnutls/libtasn1_4.9.bb | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/meta/recipes-support/gnutls/libtasn1_4.9.bb 
> > b/meta/recipes-support/gnutls/libtasn1_4.9.bb
> > index b8ff9eaf7a9..3da5d4bcc56 100644
> > --- a/meta/recipes-support/gnutls/libtasn1_4.9.bb
> > +++ b/meta/recipes-support/gnutls/libtasn1_4.9.bb
> > @@ -16,6 +16,8 @@ SRC_URI = "${GNU_MIRROR}/libtasn1/libtasn1-${PV}.tar.gz \
> > file://0004-tools-eliminated-compiler-warnings.patch \
> > "
> >  
> > +DEPENDS = "bison-native"
> > +
> 
> nit on style, you generally put checksum assignments immediately after
> SRC_URI containing the origninal src location. Secondly, if we use +=
> then we dont run the risk of it overwriting prior assignments if any

Makes sense, will change that as suggested.

-- 
Best Regards, Patrick Ohly

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



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

Re: [OE-core] potential bashism in guile_2.0.13.bb

[Patrick Ohly]

On Wed, 2017-02-01 at 09:03 -0800, Khem Raj wrote:
> 
> On 1/31/17 4:29 AM, Patrick Ohly wrote:
> > Hello!
> > 
> > verify-bashisms (after some fixing of the script) reports:
> > 
> > /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/guile/guile_2.0.13.bb
> >  possible bashism in guile_cross_config line 94 ($'...' should be "$(printf 
> > '...')"):  
> > echo '#!'`which ${BUILD_SYS}-guile`$' \\\n--no-auto-compile -e 
> > main -s\n!#\n(define %guile-build-info '\'\( \
> > > ${B}/guile-config.cross
> > 
> > 
> > This is for:
> > 
> > guile_cross_config() {
> > # this is only for target recipe
> > if [ "${PN}" = "guile" ]
> > then
> > # Create guile-config returning target values instead of native 
> > values
> > install -d ${SYSROOT_DESTDIR}${STAGING_BINDIR_CROSS}
> > echo '#!'`which ${BUILD_SYS}-guile`$' \\\n--no-auto-compile -e 
> > main -s\n!#\n(define %guile-build-info '\'\( \
> > > ${B}/guile-config.cross
> > 
> > And the resulting guile-config.cross has (when /bin/sh -> /bin/dash):
> > 
> > #!/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/guile/2.0.13-r0/recipe-sysroot-native/usr/bin/x86_64-linux-guile$
> >  \
> > --no-auto-compile -e main -s
> > !#
> > (define %guile-build-info '(
> > ...
> > 
> > This looks rather strange to me and I've no idea how the Linux kernel
> > will interpret that first shebang line, which literally ends in
> > ...guile$ \
> > 
> > Is the content as intended?
> 
> it should have come out as path to native guile with options, I think if
> this is not happening it might just be installing wrong wrapper when
> used it should complain.

Here's a test script:

#!/bin/echo \
hello world


That prints:
\ /tmp/test2

It doesn't look like line continuation in the shebang line works, so the
above guile-config.cross is just wrong. However, both dash and bash do
the same thing, so I guess the file is not used at all?

>  In any case its better to make it shell
> independent.

So the correct content of guile-config.cross would be this?

#!/.../guile/2.0.13-r0/recipe-sysroot-native/usr/bin/x86_64-linux-guile 
--no-auto-compile -e main -s
!#
(define %guile-build-info '(
...

I have no idea what the script is supposed to do, so I'm a bit reluctant
to change anything.

-- 
Best Regards, Patrick Ohly

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



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

[OE-core] [PATCH] build-perf-test-wrapper.sh: implement locking

[Markus Lehtonen]

In order to prevent multiple instances of the script running at the same
time.

Signed-off-by: Markus Lehtonen 
---
 scripts/contrib/build-perf-test-wrapper.sh | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/scripts/contrib/build-perf-test-wrapper.sh 
b/scripts/contrib/build-perf-test-wrapper.sh
index e03ea97..a4c1929 100755
--- a/scripts/contrib/build-perf-test-wrapper.sh
+++ b/scripts/contrib/build-perf-test-wrapper.sh
@@ -67,6 +67,17 @@ if [ $# -ne 0 ]; then
 exit 1
 fi
 
+# Open a file descriptor for flock and acquire lock
+LOCK_FILE="/tmp/oe-build-perf-test-wrapper.lock"
+if ! exec 3> "$LOCK_FILE"; then
+echo "ERROR: Unable to open lock file"
+exit 1
+fi
+if ! flock -n 3; then
+echo "ERROR: Another instance of this script is running"
+exit 1
+fi
+
 echo "Running on `uname -n`"
 if ! git_topdir=$(git rev-parse --show-toplevel); then
 echo "The current working dir doesn't seem to be a git clone. Please 
cd there before running `basename $0`"
-- 
2.10.2

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

Re: [OE-core] [PATCH v2 2/7] python3-manifest: move htlm.py to python3-html

[Anders Darander]

* Khem Raj  [170201 17:52]:

> On 1/30/17 11:18 PM, Anders Darander wrote:
> > This allows us to use html.py without importing misc.

> html.py is provided by many packages. Does is make more sense to package
> html.py on a package of its own ?

Hm, I had another look at this. On my build:

$ du -sh python3-html/
140Kpython3-html/

$ du -sh python3-html/usr/lib/python3.5/html/
108Kpython3-html/usr/lib/python3.5/html/

Thus, the major part, 77%, of python3-html is related to my change.
Thus, I'm not sure that it makes sense to put html in it's own
package...

I'm not going to add a new package for html for the moment.

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] host-user-contaminated QA check

[Patrick Ohly]

Hello!

Recently the host-user-contaminated QA check triggered for the trousers
recipe in meta-security:

WARNING: trousers-0.3.14+gitAUTOINC+4b9a70d578-r0 do_package_qa: QA
Issue: trousers: /trousers/etc/tcsd.conf is owned by uid 1000, which is
the same as the user running bitbake. This may be due to host
contamination [host-user-contaminated]

However, that's a false positive in this case. UID 1000 got assigned to
the "tss" user in the target sysroot during the build, and tcsd.conf is
correctly and intentionally owned by that user because tcsd checks
ownership and refuses to start when owned by someone else (including
root). It just happened that the UID was the same.

This is likely to affect all recipes with files owned by dynamically
created users, in particular when the host system assigns UIDs from the
same range as the target system (quick poll: who else has 1000 as his
UID on his main Linux box? ;-)

The current solution is to suppress the QA check for affected recipes.
But I wonder whether we can do better.

Why do we make the real user ID on the build system visible at all when
running under pseudo? The uid and user name have no meaning there, as
the user won't exist on the target system. Instead we could map the
owner of all files to root:root by default, i.e. in those cases where no
other ownership is recorded in the pseudo database.

The usual reason for host-user-contaminated is when do_install does a
"cp -a". When mapping the real owner to root, that command will end up
doing the right thing: create a file owned by root on the target.

Because the host user cannot leak into the target anymore, the entire QA
check can be disabled.

The only downsides of this approach that I can think of is that it hides
such sloppy use of "cp" where "install" would be better, and it might be
slightly confusing at first when working under devshell.

Any thoughts?

Seebs, I suppose this wouldn't be hard to implement in pseudo, would it?

-- 
Best Regards, Patrick Ohly

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



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

[OE-core] [PATCH v3 3/3] rootfs-postcommands: Modify ssh-related commands

[David Vincent]

OpenSSH configuration is now a symlink which points to the desired
configuration, so the functions that modified it must be updated to
modify the target and not override it.

Signed-off-by: David Vincent 
---
 meta/classes/rootfs-postcommands.bbclass | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index c42829dd65..60cfac82c4 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -87,15 +87,12 @@ read_only_rootfs_hook () {
sed -i -e 
'/^[#[:space:]]*\/dev\/root/{s/defaults/ro/;s/\([[:space:]]*[[:digit:]]\)\([[:space:]]*\)[[:digit:]]$/\1\20/}'
 ${IMAGE_ROOTFS}/etc/fstab
 
# If we're using openssh and the /etc/ssh directory has no 
pre-generated keys,
-   # we should configure openssh to use the configuration file 
/etc/ssh/sshd_config_readonly
-   # and the keys under /var/run/ssh.
+   # we should configure openssh to use the keys under /var/run/ssh.
if [ -d ${IMAGE_ROOTFS}/etc/ssh ]; then
if [ -e ${IMAGE_ROOTFS}/etc/ssh/ssh_host_rsa_key ]; then
echo "SYSCONFDIR=/etc/ssh" >> 
${IMAGE_ROOTFS}/etc/default/ssh
-   echo "SSHD_OPTS=" >> ${IMAGE_ROOTFS}/etc/default/ssh
else
echo "SYSCONFDIR=/var/run/ssh" >> 
${IMAGE_ROOTFS}/etc/default/ssh
-   echo "SSHD_OPTS='-f /etc/ssh/sshd_config_readonly'" >> 
${IMAGE_ROOTFS}/etc/default/ssh
fi
fi
 
@@ -138,12 +135,10 @@ zap_empty_root_password () {
 # allow dropbear/openssh to accept root logins and logins from accounts with 
an empty password string
 #
 ssh_allow_empty_password () {
-   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}${sysconfdir}/ssh/sshd_config ]; then
+   sed -i --follow-symlinks 
's/^[#[:space:]]*PermitRootLogin.*/PermitRootLogin yes/' 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config
+   sed -i --follow-symlinks 
's/^[#[:space:]]*PermitEmptyPasswords.*/PermitEmptyPasswords yes/' 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config
+   fi
 
if [ -e ${IMAGE_ROOTFS}${sbindir}/dropbear ] ; then
if grep -q DROPBEAR_EXTRA_ARGS 
${IMAGE_ROOTFS}${sysconfdir}/default/dropbear 2>/dev/null ; then
@@ -162,7 +157,7 @@ ssh_allow_empty_password () {
 
 ssh_disable_dns_lookup () {
if [ -e ${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config ]; then
-   sed -i -e 's:#UseDNS yes:UseDNS no:' 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config
+   sed -i --follow-symlinks -e 's:#UseDNS yes:UseDNS no:' 
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config
fi
 }
 
-- 
2.11.0

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

[OE-core] [PATCH v3 1/3] openssh: Package server configuration

[David Vincent]

Split sshd configuration for read-write/read-only rootfs in two distinct
packages. Also, add a package dependency between openssh-sshd package
and a provider of sshd-config.

Signed-off-by: David Vincent 
---
 meta/recipes-connectivity/openssh/openssh_7.4p1.bb | 47 ++
 1 file changed, 40 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-connectivity/openssh/openssh_7.4p1.bb 
b/meta/recipes-connectivity/openssh/openssh_7.4p1.bb
index 3b3d667a68..0afc4bd948 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.4p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.4p1.bb
@@ -91,13 +91,17 @@ do_compile_ptest() {
 }
 
 do_install_append () {
+   # Create default config files
+   install -m 0644 ${D}${sysconfdir}/ssh/sshd_config 
${D}${sysconfdir}/ssh/sshd_config_default
+   rm -f ${D}${sysconfdir}/ssh/sshd_config
+
if [ "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', '', d)}" = 
"pam" ]; then
install -D -m 0644 ${WORKDIR}/sshd ${D}${sysconfdir}/pam.d/sshd
-   sed -i -e 's:#UsePAM no:UsePAM yes:' 
${D}${sysconfdir}/ssh/sshd_config
+   sed -i -e 's:#UsePAM no:UsePAM yes:' 
${D}${sysconfdir}/ssh/sshd_config_default
fi
 
if [ "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}" = 
"x11" ]; then
-   sed -i -e 's:#X11Forwarding no:X11Forwarding yes:' 
${D}${sysconfdir}/ssh/sshd_config
+   sed -i -e 's:#X11Forwarding no:X11Forwarding yes:' 
${D}${sysconfdir}/ssh/sshd_config_default
fi
 
install -d ${D}${sysconfdir}/init.d
@@ -110,7 +114,7 @@ do_install_append () {
 
# Create config files for read-only rootfs
install -d ${D}${sysconfdir}/ssh
-   install -m 644 ${D}${sysconfdir}/ssh/sshd_config 
${D}${sysconfdir}/ssh/sshd_config_readonly
+   install -m 644 ${D}${sysconfdir}/ssh/sshd_config_default 
${D}${sysconfdir}/ssh/sshd_config_readonly
sed -i '/HostKey/d' ${D}${sysconfdir}/ssh/sshd_config_readonly
echo "HostKey /var/run/ssh/ssh_host_rsa_key" >> 
${D}${sysconfdir}/ssh/sshd_config_readonly
echo "HostKey /var/run/ssh/ssh_host_dsa_key" >> 
${D}${sysconfdir}/ssh/sshd_config_readonly
@@ -134,30 +138,59 @@ do_install_ptest () {
 
 ALLOW_EMPTY_${PN} = "1"
 
-PACKAGES =+ "${PN}-keygen ${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-sftp ${PN}-misc 
${PN}-sftp-server"
+PACKAGES =+ "${PN}-keygen ${PN}-scp ${PN}-ssh ${PN}-sshd-config 
${PN}-sshd-config-readonly ${PN}-sshd ${PN}-sftp ${PN}-misc ${PN}-sftp-server"
 FILES_${PN}-scp = "${bindir}/scp.${BPN}"
 FILES_${PN}-ssh = "${bindir}/ssh.${BPN} ${sysconfdir}/ssh/ssh_config"
+FILES_${PN}-sshd-config = "${sysconfdir}/ssh/sshd_config_default"
+FILES_${PN}-sshd-config-readonly = "${sysconfdir}/ssh/sshd_config_readonly"
 FILES_${PN}-sshd = "${sbindir}/sshd ${sysconfdir}/init.d/sshd 
${systemd_unitdir}/system"
-FILES_${PN}-sshd += "${sysconfdir}/ssh/moduli ${sysconfdir}/ssh/sshd_config 
${sysconfdir}/ssh/sshd_config_readonly ${sysconfdir}/default/volatiles/99_sshd 
${sysconfdir}/pam.d/sshd"
+FILES_${PN}-sshd += "${sysconfdir}/ssh/moduli 
${sysconfdir}/default/volatiles/99_sshd ${sysconfdir}/pam.d/sshd"
 FILES_${PN}-sftp = "${bindir}/sftp"
 FILES_${PN}-sftp-server = "${libexecdir}/sftp-server"
 FILES_${PN}-misc = "${bindir}/ssh* ${libexecdir}/ssh*"
 FILES_${PN}-keygen = "${bindir}/ssh-keygen"
 
 RDEPENDS_${PN} += "${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen"
-RDEPENDS_${PN}-sshd += "${PN}-keygen ${@bb.utils.contains('DISTRO_FEATURES', 
'pam', 'pam-plugin-keyinit pam-plugin-loginuid', '', d)}"
+RDEPENDS_${PN}-sshd += "${PN}-keygen sshd-config 
${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam-plugin-keyinit 
pam-plugin-loginuid', '', d)}"
 RDEPENDS_${PN}-ptest += "${PN}-sftp ${PN}-misc ${PN}-sftp-server make"
 
 RPROVIDES_${PN}-ssh = "ssh"
+RPROVIDES_${PN}-sshd-config = "sshd-config"
+RPROVIDES_${PN}-sshd-config-readonly = "sshd-config"
 RPROVIDES_${PN}-sshd = "sshd"
 
 RCONFLICTS_${PN} = "dropbear"
+RCONFLICTS_${PN}-sshd-config = "${PN}-sshd-config-readonly"
+RCONFLICTS_${PN}-sshd-config-readonly = "${PN}-sshd-config"
 RCONFLICTS_${PN}-sshd = "dropbear"
 RCONFLICTS_${PN}-keygen = "ssh-keygen"
 
-CONFFILES_${PN}-sshd = "${sysconfdir}/ssh/sshd_config"
+CONFFILES_${PN}-sshd-config = "${sysconfdir}/ssh/sshd_config_default"
+CONFFILES_${PN}-sshd-config-readonly = "${sysconfdir}/ssh/sshd_config_readonly"
 CONFFILES_${PN}-ssh = "${sysconfdir}/ssh/ssh_config"
 
+pkg_postinst_${PN}-sshd-config () {
+#!/bin/sh
+if [ -e $D${sysconfdir}/ssh/sshd_config ]; then
+rm $D${sysconfdir}/ssh/sshd_config
+fi
+
+# Make sure destination directory exists, before creating the symlink
+mkdir -p $D${sysconfdir}/ssh
+ln -s sshd_config_default $D${sysconfdir}/ssh/sshd_config
+}
+
+pkg_postinst_${PN}-sshd-config-readonly () {
+#!/bin/sh
+if [ -e $D${sysconfdir}/ssh/sshd_config ]; then
+rm $D${sysconfdir}/ssh/sshd_config
+fi
+
+# Make sure destination directory exists, before 

[OE-core] [PATCH v3 2/3] core-image: Set default sshd configuration

[David Vincent]

When selecting OpenSSH as ssh server provider instead of dropbear, also
install the correct configuration depending on whether the final rootfs
is read-only or not.

Signed-off-by: David Vincent 
---
 meta/classes/core-image.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/core-image.bbclass b/meta/classes/core-image.bbclass
index 8431440db4..d1f643d920 100644
--- a/meta/classes/core-image.bbclass
+++ b/meta/classes/core-image.bbclass
@@ -41,7 +41,7 @@ FEATURE_PACKAGES_tools-sdk = "packagegroup-core-sdk 
packagegroup-core-standalone
 FEATURE_PACKAGES_nfs-server = "packagegroup-core-nfs-server"
 FEATURE_PACKAGES_nfs-client = "packagegroup-core-nfs-client"
 FEATURE_PACKAGES_ssh-server-dropbear = "packagegroup-core-ssh-dropbear"
-FEATURE_PACKAGES_ssh-server-openssh = "packagegroup-core-ssh-openssh"
+FEATURE_PACKAGES_ssh-server-openssh = "packagegroup-core-ssh-openssh 
${SSHD_CONFIG}"
 FEATURE_PACKAGES_hwcodecs = "${MACHINE_HWCODECS}"
 
 
@@ -52,6 +52,7 @@ IMAGE_FEATURES_REPLACES_ssh-server-openssh = 
"ssh-server-dropbear"
 # IMAGE_FEATURES_CONFLICTS_foo = 'bar1 bar2'
 # An error exception would be raised if both image features foo and bar1(or 
bar2) are included
 
+SSHD_CONFIG ??= 
"${@bb.utils.contains('IMAGE_FEATURES','read-only-rootfs','openssh-sshd-config-readonly','openssh-sshd-config',d)}"
 MACHINE_HWCODECS ??= ""
 
 CORE_IMAGE_BASE_INSTALL = '\
-- 
2.11.0

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

[OE-core] [PATCH v3 0/3] openssh: Make sshd-config a package

[David Vincent]

This series of patch introduces a new way of modifying OpenSSH sshd
configuration. Instead of modifying the files and launching the server with
custom options, a package which RPROVIDES sshd-config must be installed.

The package to use is selected using a new variable called SSHD_CONFIG which is
used exclusively when selecting ssh-server-openssh in IMAGE_FEATURES.

Changes since v1:
  Remove documentation

Changes since v2:
  Restore SYSCONFDIR in /etc/default/ssh, otherwise keys are not correctly
  generated

David Vincent (3):
  openssh: Package server configuration
  core-image: Set default sshd configuration
  rootfs-postcommands: Modify ssh-related commands

 meta/classes/core-image.bbclass|  3 +-
 meta/classes/rootfs-postcommands.bbclass   | 17 +++-
 meta/recipes-connectivity/openssh/openssh_7.4p1.bb | 47 ++
 3 files changed, 48 insertions(+), 19 deletions(-)

-- 
2.11.0

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

[OE-core] [PATCH] gdb 7.12: fix armv8b build

[Koen Kooi]

Backport fix from GDB upstream to fix big-endian aarch64 build.

Signed-off-by: Koen Kooi 
---
 meta/recipes-devtools/gdb/gdb-7.12.inc |  1 +
 .../cb93dc7f262978bafe36397a41a56e409a302042.patch | 42 ++
 2 files changed, 43 insertions(+)
 create mode 100644 
meta/recipes-devtools/gdb/gdb/cb93dc7f262978bafe36397a41a56e409a302042.patch

diff --git a/meta/recipes-devtools/gdb/gdb-7.12.inc 
b/meta/recipes-devtools/gdb/gdb-7.12.inc
index 2faddc5..7eea65f 100644
--- a/meta/recipes-devtools/gdb/gdb-7.12.inc
+++ b/meta/recipes-devtools/gdb/gdb-7.12.inc
@@ -15,6 +15,7 @@ SRC_URI = "http://ftp.gnu.org/gnu/gdb/gdb-${PV}.tar.xz \
file://0008-Use-exorted-definitions-of-SIGRTMIN.patch \
file://0009-Change-order-of-CFLAGS.patch \
file://0010-resolve-restrict-keyword-conflict.patch \
+  file://cb93dc7f262978bafe36397a41a56e409a302042.patch \
 "
 SRC_URI[md5sum] = "a0a3a00f7499b0c5278ba8676745d180"
 SRC_URI[sha256sum] = 
"834ff3c5948b30718343ea57b11cbc3235d7995c6a4f3a5cecec8c8114164f94"
diff --git 
a/meta/recipes-devtools/gdb/gdb/cb93dc7f262978bafe36397a41a56e409a302042.patch 
b/meta/recipes-devtools/gdb/gdb/cb93dc7f262978bafe36397a41a56e409a302042.patch
new file mode 100644
index 000..a3f488a
--- /dev/null
+++ 
b/meta/recipes-devtools/gdb/gdb/cb93dc7f262978bafe36397a41a56e409a302042.patch
@@ -0,0 +1,42 @@
+From cb93dc7f262978bafe36397a41a56e409a302042 Mon Sep 17 00:00:00 2001
+From: Yao Qi 
+Date: Mon, 24 Oct 2016 10:59:11 +0100
+Subject: [PATCH] [GDBserver] Fix conversion warning
+
+I got the following warning if I build GDBserver for aarch64_be-linux-gnu,
+
+git/gdb/gdbserver/linux-aarch64-low.c:1539:39: error: invalid conversion from 
'void*' to 'uint32_t* {aka unsigned int*}' [-fpermissive]
+   uint32_t *le_buf = xmalloc (byte_len);
+   ^
+The patch is to fix the warning.
+
+gdb/gdbserver:
+
+2016-10-24  Yao Qi  
+
+   PR server/20733
+   * linux-aarch64-low.c (append_insns): Cast the return value to
+   'uint32_t *'.
+
+Upstream-status: Backport
+
+---
+ gdb/gdbserver/linux-aarch64-low.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gdb/gdbserver/linux-aarch64-low.c 
b/gdb/gdbserver/linux-aarch64-low.c
+index e54a8ba..ae80cdd 100644
+--- a/gdb/gdbserver/linux-aarch64-low.c
 b/gdb/gdbserver/linux-aarch64-low.c
+@@ -1536,7 +1536,7 @@ append_insns (CORE_ADDR *to, size_t len, const uint32_t 
*buf)
+ {
+   size_t byte_len = len * sizeof (uint32_t);
+ #if (__BYTE_ORDER == __BIG_ENDIAN)
+-  uint32_t *le_buf = xmalloc (byte_len);
++  uint32_t *le_buf = (uint32_t *) xmalloc (byte_len);
+   size_t i;
+ 
+   for (i = 0; i < len; i++)
+-- 
+2.9.3
+
-- 
2.9.3

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

[OE-core] [PATCH] openssl: Updgrade 1.0.2j -> 1.0.2k

[Andrej Valek]

Signed-off-by: Andrej Valek 
Signed-off-by: Pascal Bach 
---
 .../openssl/openssl/CVE-2016-7055.patch| 43 
 .../recipes-connectivity/openssl/openssl_1.0.2j.bb | 60 --
 .../recipes-connectivity/openssl/openssl_1.0.2k.bb | 59 +
 3 files changed, 59 insertions(+), 103 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/openssl/openssl/CVE-2016-7055.patch
 delete mode 100644 meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
 create mode 100644 meta/recipes-connectivity/openssl/openssl_1.0.2k.bb

diff --git a/meta/recipes-connectivity/openssl/openssl/CVE-2016-7055.patch 
b/meta/recipes-connectivity/openssl/openssl/CVE-2016-7055.patch
deleted file mode 100644
index 83a74cd..000
--- a/meta/recipes-connectivity/openssl/openssl/CVE-2016-7055.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 57c4b9f6a2f800b41ce2836986fe33640f6c3f8a Mon Sep 17 00:00:00 2001
-From: Andy Polyakov 
-Date: Sun, 6 Nov 2016 18:33:17 +0100
-Subject: [PATCH] bn/asm/x86_64-mont.pl: fix for CVE-2016-7055 (Low severity).
-
-Reviewed-by: Rich Salz 
-(cherry picked from commit 2fac86d9abeaa643677d1ffd0a139239fdf9406a)
-
-Upstream-Status: Backport 
[https://github.com/openssl/openssl/commit/57c4b9f6a2f800b41ce2836986fe33640f6c3f8a]
-CVE: CVE-2016-7055
-Signed-off-by: Yi Zhao 

- crypto/bn/asm/x86_64-mont.pl | 5 ++---
- 1 file changed, 2 insertions(+), 3 deletions(-)
-
-diff --git a/crypto/bn/asm/x86_64-mont.pl b/crypto/bn/asm/x86_64-mont.pl
-index 044fd7e..80492d8 100755
 a/crypto/bn/asm/x86_64-mont.pl
-+++ b/crypto/bn/asm/x86_64-mont.pl
-@@ -1148,18 +1148,17 @@ $code.=<<___;
-   mulx2*8($aptr),%r15,%r13# ...
-   adox-3*8($tptr),%r11
-   adcx%r15,%r12
--  adox$zero,%r12
-+  adox-2*8($tptr),%r12
-   adcx$zero,%r13
-+  adox$zero,%r13
- 
-   mov $bptr,8(%rsp)   # off-load [i]
--  .byte   0x67
-   mov $mi,%r15
-   imulq   24(%rsp),$mi# "t[0]"*n0
-   xor %ebp,%ebp   # xor   $zero,$zero # cf=0, of=0
- 
-   mulx3*8($aptr),%rax,%r14
-mov$mi,%rdx
--  adox-2*8($tptr),%r12
-   adcx%rax,%r13
-   adox-1*8($tptr),%r13
-   adcx$zero,%r14
--- 
-2.7.4
-
diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb 
b/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
deleted file mode 100644
index 94672f9..000
--- a/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
+++ /dev/null
@@ -1,60 +0,0 @@
-require openssl.inc
-
-# For target side versions of openssl enable support for OCF Linux driver
-# if they are available.
-DEPENDS += "cryptodev-linux"
-
-CFLAG += "-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS"
-CFLAG_append_class-native = " -fPIC"
-
-LIC_FILES_CHKSUM = "file://LICENSE;md5=27ffa5d74bb5a337056c14b2ef93fbf6"
-
-export DIRS = "crypto ssl apps engines"
-export OE_LDFLAGS="${LDFLAGS}"
-
-SRC_URI += "file://find.pl;subdir=${BP}/util/ \
-file://run-ptest \
-file://openssl-c_rehash.sh \
-file://configure-targets.patch \
-file://shared-libs.patch \
-file://oe-ldflags.patch \
-file://engines-install-in-libdir-ssl.patch \
-file://debian1.0.2/block_diginotar.patch \
-file://debian1.0.2/block_digicert_malaysia.patch \
-file://debian/ca.patch \
-file://debian/c_rehash-compat.patch \
-file://debian/debian-targets.patch \
-file://debian/man-dir.patch \
-file://debian/man-section.patch \
-file://debian/no-rpath.patch \
-file://debian/no-symbolic.patch \
-file://debian/pic.patch \
-file://debian1.0.2/version-script.patch \
-file://openssl_fix_for_x32.patch \
-file://fix-cipher-des-ede3-cfb1.patch \
-
file://openssl-avoid-NULL-pointer-dereference-in-EVP_DigestInit_ex.patch \
-file://openssl-fix-des.pod-error.patch \
-file://Makefiles-ptest.patch \
-file://ptest-deps.patch \
-file://openssl-1.0.2a-x32-asm.patch \
-file://ptest_makefile_deps.patch  \
-file://configure-musl-target.patch \
-file://parallel.patch \
-file://openssl-util-perlpath.pl-cwd.patch \
-file://CVE-2016-7055.patch \
-   "
-SRC_URI[md5sum] = "96322138f0b69e61b7212bc53d5e912b"
-SRC_URI[sha256sum] = 
"e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431"
-
-PACKAGES =+ "${PN}-engines"
-FILES_${PN}-engines = "${libdir}/ssl/engines/*.so ${libdir}/engines"
-
-# The crypto_use_bigint patch means that perl's bignum module needs to be
-# installed, but some distributions (for example Fedora 23) don't ship it by
-# default.  As the resulting error is very misleading check for