[OE-core] [PATCH] Fix build error when enable archiver.

[Lei Maohui]

The error is as fllowing:
ERROR: Task do_deploy_archives in 
virtual:native:/yocto/poky/meta/recipes-extended/newt/libnewt_0.52.20.bb 
depends upon non-existent task do_package_write_rpm in 
virtual:native:/yocto/poky/meta/recipes-extended/newt/libnewt_0.52.20.bb
ERROR: Command execution failed: 1

Signed-off-by: Lei Maohui 
---
 meta/classes/nopackages.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/nopackages.bbclass b/meta/classes/nopackages.bbclass
index 559f507..d9ddfac 100644
--- a/meta/classes/nopackages.bbclass
+++ b/meta/classes/nopackages.bbclass
@@ -10,3 +10,4 @@ deltask do_package_write_ipk_setscene
 deltask do_package_write_deb_setscene
 deltask do_package_qa_setscene
 deltask do_packagedata_setscene
+deltask do_deploy_archives
-- 
1.9.1



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

Re: [OE-core] [PATCH 07/12] libunistring: upgrade to 0.9.10

[Randy MacLeod]

On 06/12/2018 07:18 AM, Maxin B. John wrote:

License-Update: Checksum changed due to updation in documentation. There
are no changes in the license terms.


That's correct but I'm not sure if we should include
a checksum on the (GPLv3) COPYING file since the README
says [1] that:
   This license is based on the GNU GPL version 3, see file COPYING.
I'd like to know if the COPYING file changed to say the _actual_
GPLv2 some day so a checksum would help track such changes.


The README statement is an odd way to convey the license terms.
Is this just standard FSFese?

The libunistring commit that sets out these terms is from 0.9:

commit 3c15d3a96963703fc02cddda7e968e508638d1b8
Author: Bruno Haible 
Date:   Sun Mar 15 02:10:58 2009 +0100

License information.

 COPYING | 674 ...
 COPYING.LIB | 165 +...
 ChangeLog   |   3 +
 README  |   2 +-
 4 files changed, 843 insertions(+), 1 deletion(-)


which doesn't help much other than the ChangeLog:

+   * COPYING.LIB: New file, from gnulib/doc/COPYING.LESSERv3.
+   * COPYING: New file, from gnulib/doc/COPYINGv3.


../Randy


[1] From README:

Copyright
-

The libunistring library and its header files are dual-licensed under
"the GNU LGPLv3+ or the GNU GPLv2". This means, you can use it under either
  - the terms of the GNU Lesser General Public License (LGPL) version 3 or
(at your option) any later version, or
  - the terms of the GNU General Public License (GPL) version 2, or
  - the same dual license "the GNU LGPLv3+ or the GNU GPLv2".

You find the GNU LGPL version 3 in the file COPYING.LIB.  This license is
based on the GNU GPL version 3, see file COPYING.

You can find the GNU GPL version 2 at
.

Note: This dual license makes it possible for the libunistring library
to be used by packages under GPLv2 or GPLv2+ licenses, in particular. See
the table in .

The documentation is under another license; see in the documentation.



Signed-off-by: Maxin B. John 
---
  .../libunistring/{libunistring_0.9.9.bb => libunistring_0.9.10.bb}  | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
  rename meta/recipes-support/libunistring/{libunistring_0.9.9.bb => 
libunistring_0.9.10.bb} (85%)

diff --git a/meta/recipes-support/libunistring/libunistring_0.9.9.bb 
b/meta/recipes-support/libunistring/libunistring_0.9.10.bb
similarity index 85%
rename from meta/recipes-support/libunistring/libunistring_0.9.9.bb
rename to meta/recipes-support/libunistring/libunistring_0.9.10.bb
index ab7cba5..97fac4e 100644
--- a/meta/recipes-support/libunistring/libunistring_0.9.9.bb
+++ b/meta/recipes-support/libunistring/libunistring_0.9.10.bb
@@ -16,15 +16,15 @@ SECTION = "devel"
  LICENSE = "LGPLv3+ | GPLv2"
  LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=6a6a8e020838b23406c81b19c1d46df6 \
  
file://README;beginline=45;endline=65;md5=08287d16ba8d839faed8d2dc14d7d6a5 \
-
file://doc/libunistring.texi;md5=efb80a3799a60f95feaf80661d4f204c \
+
file://doc/libunistring.texi;md5=287fa6075f78a3c85c1a52b0a92547cd \
 "
  
  SRC_URI = "${GNU_MIRROR}/libunistring/libunistring-${PV}.tar.gz \

 file://iconv-m4-remove-the-test-to-convert-euc-jp.patch \
 file://0001-Unset-need_charset_alias-when-building-for-musl.patch \
  "
-SRC_URI[md5sum] = "4f689e37e4c3bd67de5786aa51d98b13"
-SRC_URI[sha256sum] = 
"f5e90c08f9e5427ca3a2c0c53f19aa38b25c500913510ad25afef86448bea84a"
+SRC_URI[md5sum] = "0d3274e9838396b12200f8b54ddaf43b"
+SRC_URI[sha256sum] = 
"a82e5b39a88ea4608e4635479a1cfb2e01aafb925e1290b65710d43f610b"
  
  inherit autotools texinfo

  BBCLASSEXTEND = "native nativesdk"




--
# Randy MacLeod
# Wind River Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] gcc-target.inc: configure gcc for armv7ve targets to default to armv7ve

[Andre McCurdy]

On Wed, Jun 6, 2018 at 11:56 PM, Andre McCurdy  wrote:
> On Wed, Jun 6, 2018 at 11:04 PM, Khem Raj  wrote:
>> On 6/6/18 9:34 PM, Andre McCurdy wrote:
>>>
>>> Originally these ARM specific EXTRA_OECONF options were applied to
>>> both gcc for the target and gcc-cross. That lead to a compromise
>>> being made: gcc on the target was configured to default to an ARM
>>> architecture which was at least compatible with the target (but not
>>> necessarily an exact match) and gcc-cross was configured default to
>>> armv7a for both armv7a and armv7ve (to avoid gcc-cross rebuilds when
>>> switching between the two).
>>>
>>> However, when these ARM specific EXTRA_OECONF options were moved from
>>> gcc-configure-common.inc into gcc-target.inc (ie they were made to
>>> apply only to gcc on the target) the compromise no longer needed to
>>> be made.
>>>
>>> http://git.openembedded.org/openembedded-core/commit/?id=851937dde81de2a9ef54c5f19a78fb12fb82afd4

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

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Andre McCurdy]

On Tue, Jun 12, 2018 at 4:32 PM, Herve Jourdain  wrote:
> Hi Andre,
>
> I believe I did say always present on armv8 and armv7, I did not mean before 
> that.

Right. The point of considering older architecture levels was that IF
we were to drop support for armv4 (I'm not necessarily suggesting that
we do) then we could simplify the tuning files quite a lot, since then
every supported ARM core would support Thumb.

> Having separate tunes for thumb support was necessary on previous 
> architectures where it was optional, but it persisted for architectures which 
> made thumb mandatory.
> I’m not even advocating removing the tune option for previous architectures 
> that would normally not require it, but I believe we should get rid of it for 
> new ARM architectures.

We all seem to be strongly agreeing with each other :-)

BTW, I don't know how much history you've aware of from when this
topic has been discussed previously on the list (it's come up a few
times...). There are people who've created distros etc which do
actually rely on being able to define (for example) an armv7a machine
without Thumb support, even though such a thing doesn't actually
exist. So, as much as we might all agree that removing the option to
disable Thumb support for armv7a etc might be "the right thing to do",
in practice there are going to be people who object to it.

> Cheers,
> Herve
>
>> On 13 Jun 2018, at 04:39, Andre McCurdy  wrote:
>>
>>> On Tue, Jun 12, 2018 at 1:00 PM, Mark Hatle  
>>> wrote:
 On 6/12/18 10:49 AM, Herve Jourdain wrote:
 Hi,

 So I agree with you about restricting to what gcc can support, that's 
 actually my proposal (actually, probably a subset of what gcc can support).
 So for armv8, gcc supports, as architectures: armv8-a, armv8.1-a, 
 armv8.2-a, armv8.3-a, armv8.4-a.
 Then, you can add the supported options with a "+" after the architecture.
 Options supported for armv8-a are: '+crc', '+simd', '+crypto', 
 '+nocrypto', '+nofp'
 Options supported for armv8.1-a are: '+simd', '+crypto', '+nocrypto', 
 '+nofp'
 Options supported for armv8.2-a and armv8.3-a are: '+fp16', '+fp16fml', 
 '+simd', '+crypto', '+dotprod', '+nocrypto', '+nofp'
 Options supported for armv8.4-a are: '+fp16', '+simd', '+crypto', 
 '+dotprod', '+nocrypto', '+nofp'

 As you can see, proposals for armv8-a, whether my previous one, the new 
 one here, or even the one I have updated and used in production, just 
 capture the existing complexity, and not add to it.
 and support for armv8.1-a, armv8.2-a, armv8.3-a, armv8.4a will only add 
 more options down the line.
>>>
>>> Sounds a lot like the above would be TUNE_FEATURES to me..  (even if we 
>>> don't
>>> necessarily define a tune that uses them -- if it's standard another layer
>>> certainly could.)
>>>
 Regarding fpu, gcc supports the following for armv8: fp-armv8, 
 neon-fp-armv8, and crypto-neon-fp-armv8.

 Regarding cpu, I believe that the armv8 supported ones are: ‘cortex-a32’, 
 ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’, ‘cortex-a72’, 
 ‘cortex-a73’, ‘cortex-a75’.

 I personally would like to keep tuning for a specific CPU as much as 
 possible (again I'm working closely with various ARM-based SoCs, so my 
 opinion might be tainted).
>>>
>>> Thats a lot of options, but if we focus on TUNE_FEATURES, I think it's a bit
>>> more reasonable to support all of this.. (maybe that is what needs to be 
>>> done in
>>> the future as well for other architectures.. focus on the 'gcc' behavior and
>>> generate TUNE_FEATURES matching the compiler.)
>>>
>>> I'd like Khem's opinion on how crazy of an idea that is.
>>>
 One thing that could be done to simplify things would be to just use the 
 cpu, and add the options to it. Gcc supports adding options to the cpu.
 '+nofp' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’ and ‘cortex-a55’
 '+crypto' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, 
 ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’

 That could simplify the tune settings, but would give less control than 
 what we currently have.
 As you might have guessed, I do put a specific emphasis on the crypto 
 option, and on the neon option, which are the most interesting for armv8 
 in my opinion.
>>>
>>> In the past 'crypto' options have only been assembly.. if that's changed it 
>>> has
>>> definitely opened up a new facet in all of this work.
>>>
 Regarding thumb, always adding it to the tune without creating specific 
 variants with or without thumb makes sense, since the tune is normally 
 about the SoC capabilities, and arv7 and armv8 both support it.
 You can always select whether you want thumb or not by setting 
 ARM_INSTRUCTION_SET appropriately at the distro level.
>>>
>>> Yes, that might be needed now that thumb is theoretically always supposed 
>>> to be
>>> 

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Herve Jourdain]

Hi Andre,

I believe I did say always present on armv8 and armv7, I did not mean before 
that.
Having separate tunes for thumb support was necessary on previous architectures 
where it was optional, but it persisted for architectures which made thumb 
mandatory.
I’m not even advocating removing the tune option for previous architectures 
that would normally not require it, but I believe we should get rid of it for 
new ARM architectures.

Cheers,
Herve

> On 13 Jun 2018, at 04:39, Andre McCurdy  wrote:
> 
>> On Tue, Jun 12, 2018 at 1:00 PM, Mark Hatle  wrote:
>>> On 6/12/18 10:49 AM, Herve Jourdain wrote:
>>> Hi,
>>> 
>>> So I agree with you about restricting to what gcc can support, that's 
>>> actually my proposal (actually, probably a subset of what gcc can support).
>>> So for armv8, gcc supports, as architectures: armv8-a, armv8.1-a, 
>>> armv8.2-a, armv8.3-a, armv8.4-a.
>>> Then, you can add the supported options with a "+" after the architecture.
>>> Options supported for armv8-a are: '+crc', '+simd', '+crypto', '+nocrypto', 
>>> '+nofp'
>>> Options supported for armv8.1-a are: '+simd', '+crypto', '+nocrypto', 
>>> '+nofp'
>>> Options supported for armv8.2-a and armv8.3-a are: '+fp16', '+fp16fml', 
>>> '+simd', '+crypto', '+dotprod', '+nocrypto', '+nofp'
>>> Options supported for armv8.4-a are: '+fp16', '+simd', '+crypto', 
>>> '+dotprod', '+nocrypto', '+nofp'
>>> 
>>> As you can see, proposals for armv8-a, whether my previous one, the new one 
>>> here, or even the one I have updated and used in production, just capture 
>>> the existing complexity, and not add to it.
>>> and support for armv8.1-a, armv8.2-a, armv8.3-a, armv8.4a will only add 
>>> more options down the line.
>> 
>> Sounds a lot like the above would be TUNE_FEATURES to me..  (even if we don't
>> necessarily define a tune that uses them -- if it's standard another layer
>> certainly could.)
>> 
>>> Regarding fpu, gcc supports the following for armv8: fp-armv8, 
>>> neon-fp-armv8, and crypto-neon-fp-armv8.
>>> 
>>> Regarding cpu, I believe that the armv8 supported ones are: ‘cortex-a32’, 
>>> ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’, ‘cortex-a72’, 
>>> ‘cortex-a73’, ‘cortex-a75’.
>>> 
>>> I personally would like to keep tuning for a specific CPU as much as 
>>> possible (again I'm working closely with various ARM-based SoCs, so my 
>>> opinion might be tainted).
>> 
>> Thats a lot of options, but if we focus on TUNE_FEATURES, I think it's a bit
>> more reasonable to support all of this.. (maybe that is what needs to be 
>> done in
>> the future as well for other architectures.. focus on the 'gcc' behavior and
>> generate TUNE_FEATURES matching the compiler.)
>> 
>> I'd like Khem's opinion on how crazy of an idea that is.
>> 
>>> One thing that could be done to simplify things would be to just use the 
>>> cpu, and add the options to it. Gcc supports adding options to the cpu.
>>> '+nofp' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’ and ‘cortex-a55’
>>> '+crypto' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, 
>>> ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’
>>> 
>>> That could simplify the tune settings, but would give less control than 
>>> what we currently have.
>>> As you might have guessed, I do put a specific emphasis on the crypto 
>>> option, and on the neon option, which are the most interesting for armv8 in 
>>> my opinion.
>> 
>> In the past 'crypto' options have only been assembly.. if that's changed it 
>> has
>> definitely opened up a new facet in all of this work.
>> 
>>> Regarding thumb, always adding it to the tune without creating specific 
>>> variants with or without thumb makes sense, since the tune is normally 
>>> about the SoC capabilities, and arv7 and armv8 both support it.
>>> You can always select whether you want thumb or not by setting 
>>> ARM_INSTRUCTION_SET appropriately at the distro level.
>> 
>> Yes, that might be needed now that thumb is theoretically always supposed to 
>> be
>> present.
> 
> It's not _always_ present - it's missing for armv4 CPUs such as StrongARM.
> 
> However the option has been unnecessarily propagated into tuning files
> for higher architecture levels where support for Thumb _is_ always
> present.

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

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Andre McCurdy]

On Tue, Jun 12, 2018 at 2:43 PM, Mark Hatle  wrote:
> On 6/12/18 3:39 PM, Andre McCurdy wrote:
>> On Tue, Jun 12, 2018 at 1:00 PM, Mark Hatle  wrote:
>>> On 6/12/18 10:49 AM, Herve Jourdain wrote:
 Hi,

 So I agree with you about restricting to what gcc can support, that's 
 actually my proposal (actually, probably a subset of what gcc can support).
 So for armv8, gcc supports, as architectures: armv8-a, armv8.1-a, 
 armv8.2-a, armv8.3-a, armv8.4-a.
 Then, you can add the supported options with a "+" after the architecture.
 Options supported for armv8-a are: '+crc', '+simd', '+crypto', 
 '+nocrypto', '+nofp'
 Options supported for armv8.1-a are: '+simd', '+crypto', '+nocrypto', 
 '+nofp'
 Options supported for armv8.2-a and armv8.3-a are: '+fp16', '+fp16fml', 
 '+simd', '+crypto', '+dotprod', '+nocrypto', '+nofp'
 Options supported for armv8.4-a are: '+fp16', '+simd', '+crypto', 
 '+dotprod', '+nocrypto', '+nofp'

 As you can see, proposals for armv8-a, whether my previous one, the new 
 one here, or even the one I have updated and used in production, just 
 capture the existing complexity, and not add to it.
 and support for armv8.1-a, armv8.2-a, armv8.3-a, armv8.4a will only add 
 more options down the line.
>>>
>>> Sounds a lot like the above would be TUNE_FEATURES to me..  (even if we 
>>> don't
>>> necessarily define a tune that uses them -- if it's standard another layer
>>> certainly could.)
>>>
 Regarding fpu, gcc supports the following for armv8: fp-armv8, 
 neon-fp-armv8, and crypto-neon-fp-armv8.

 Regarding cpu, I believe that the armv8 supported ones are: ‘cortex-a32’, 
 ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’, ‘cortex-a72’, 
 ‘cortex-a73’, ‘cortex-a75’.

 I personally would like to keep tuning for a specific CPU as much as 
 possible (again I'm working closely with various ARM-based SoCs, so my 
 opinion might be tainted).
>>>
>>> Thats a lot of options, but if we focus on TUNE_FEATURES, I think it's a bit
>>> more reasonable to support all of this.. (maybe that is what needs to be 
>>> done in
>>> the future as well for other architectures.. focus on the 'gcc' behavior and
>>> generate TUNE_FEATURES matching the compiler.)
>>>
>>> I'd like Khem's opinion on how crazy of an idea that is.
>>>
 One thing that could be done to simplify things would be to just use the 
 cpu, and add the options to it. Gcc supports adding options to the cpu.
 '+nofp' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’ and ‘cortex-a55’
 '+crypto' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, 
 ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’

 That could simplify the tune settings, but would give less control than 
 what we currently have.
 As you might have guessed, I do put a specific emphasis on the crypto 
 option, and on the neon option, which are the most interesting for armv8 
 in my opinion.
>>>
>>> In the past 'crypto' options have only been assembly.. if that's changed it 
>>> has
>>> definitely opened up a new facet in all of this work.
>>>
 Regarding thumb, always adding it to the tune without creating specific 
 variants with or without thumb makes sense, since the tune is normally 
 about the SoC capabilities, and arv7 and armv8 both support it.
 You can always select whether you want thumb or not by setting 
 ARM_INSTRUCTION_SET appropriately at the distro level.
>>>
>>> Yes, that might be needed now that thumb is theoretically always supposed 
>>> to be
>>> present.
>>
>> It's not _always_ present - it's missing for armv4 CPUs such as StrongARM.
>
> Always present on -modern- ARM processors.. ARMv7 (Cortex) and newer AFAIK.  
> I'm
> not referring to older cores.

OK. Thanks for clarifying.

>> However the option has been unnecessarily propagated into tuning files
>> for higher architecture levels where support for Thumb _is_ always
>> present.
>>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Mark Hatle]

On 6/12/18 3:39 PM, Andre McCurdy wrote:
> On Tue, Jun 12, 2018 at 1:00 PM, Mark Hatle  wrote:
>> On 6/12/18 10:49 AM, Herve Jourdain wrote:
>>> Hi,
>>>
>>> So I agree with you about restricting to what gcc can support, that's 
>>> actually my proposal (actually, probably a subset of what gcc can support).
>>> So for armv8, gcc supports, as architectures: armv8-a, armv8.1-a, 
>>> armv8.2-a, armv8.3-a, armv8.4-a.
>>> Then, you can add the supported options with a "+" after the architecture.
>>> Options supported for armv8-a are: '+crc', '+simd', '+crypto', '+nocrypto', 
>>> '+nofp'
>>> Options supported for armv8.1-a are: '+simd', '+crypto', '+nocrypto', 
>>> '+nofp'
>>> Options supported for armv8.2-a and armv8.3-a are: '+fp16', '+fp16fml', 
>>> '+simd', '+crypto', '+dotprod', '+nocrypto', '+nofp'
>>> Options supported for armv8.4-a are: '+fp16', '+simd', '+crypto', 
>>> '+dotprod', '+nocrypto', '+nofp'
>>>
>>> As you can see, proposals for armv8-a, whether my previous one, the new one 
>>> here, or even the one I have updated and used in production, just capture 
>>> the existing complexity, and not add to it.
>>> and support for armv8.1-a, armv8.2-a, armv8.3-a, armv8.4a will only add 
>>> more options down the line.
>>
>> Sounds a lot like the above would be TUNE_FEATURES to me..  (even if we don't
>> necessarily define a tune that uses them -- if it's standard another layer
>> certainly could.)
>>
>>> Regarding fpu, gcc supports the following for armv8: fp-armv8, 
>>> neon-fp-armv8, and crypto-neon-fp-armv8.
>>>
>>> Regarding cpu, I believe that the armv8 supported ones are: ‘cortex-a32’, 
>>> ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’, ‘cortex-a72’, 
>>> ‘cortex-a73’, ‘cortex-a75’.
>>>
>>> I personally would like to keep tuning for a specific CPU as much as 
>>> possible (again I'm working closely with various ARM-based SoCs, so my 
>>> opinion might be tainted).
>>
>> Thats a lot of options, but if we focus on TUNE_FEATURES, I think it's a bit
>> more reasonable to support all of this.. (maybe that is what needs to be 
>> done in
>> the future as well for other architectures.. focus on the 'gcc' behavior and
>> generate TUNE_FEATURES matching the compiler.)
>>
>> I'd like Khem's opinion on how crazy of an idea that is.
>>
>>> One thing that could be done to simplify things would be to just use the 
>>> cpu, and add the options to it. Gcc supports adding options to the cpu.
>>> '+nofp' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’ and ‘cortex-a55’
>>> '+crypto' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, 
>>> ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’
>>>
>>> That could simplify the tune settings, but would give less control than 
>>> what we currently have.
>>> As you might have guessed, I do put a specific emphasis on the crypto 
>>> option, and on the neon option, which are the most interesting for armv8 in 
>>> my opinion.
>>
>> In the past 'crypto' options have only been assembly.. if that's changed it 
>> has
>> definitely opened up a new facet in all of this work.
>>
>>> Regarding thumb, always adding it to the tune without creating specific 
>>> variants with or without thumb makes sense, since the tune is normally 
>>> about the SoC capabilities, and arv7 and armv8 both support it.
>>> You can always select whether you want thumb or not by setting 
>>> ARM_INSTRUCTION_SET appropriately at the distro level.
>>
>> Yes, that might be needed now that thumb is theoretically always supposed to 
>> be
>> present.
> 
> It's not _always_ present - it's missing for armv4 CPUs such as StrongARM.

Always present on -modern- ARM processors.. ARMv7 (Cortex) and newer AFAIK.  I'm
not referring to older cores.

> However the option has been unnecessarily propagated into tuning files
> for higher architecture levels where support for Thumb _is_ always
> present.
> 

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

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Andre McCurdy]

On Tue, Jun 12, 2018 at 1:00 PM, Mark Hatle  wrote:
> On 6/12/18 10:49 AM, Herve Jourdain wrote:
>> Hi,
>>
>> So I agree with you about restricting to what gcc can support, that's 
>> actually my proposal (actually, probably a subset of what gcc can support).
>> So for armv8, gcc supports, as architectures: armv8-a, armv8.1-a, armv8.2-a, 
>> armv8.3-a, armv8.4-a.
>> Then, you can add the supported options with a "+" after the architecture.
>> Options supported for armv8-a are: '+crc', '+simd', '+crypto', '+nocrypto', 
>> '+nofp'
>> Options supported for armv8.1-a are: '+simd', '+crypto', '+nocrypto', '+nofp'
>> Options supported for armv8.2-a and armv8.3-a are: '+fp16', '+fp16fml', 
>> '+simd', '+crypto', '+dotprod', '+nocrypto', '+nofp'
>> Options supported for armv8.4-a are: '+fp16', '+simd', '+crypto', 
>> '+dotprod', '+nocrypto', '+nofp'
>>
>> As you can see, proposals for armv8-a, whether my previous one, the new one 
>> here, or even the one I have updated and used in production, just capture 
>> the existing complexity, and not add to it.
>> and support for armv8.1-a, armv8.2-a, armv8.3-a, armv8.4a will only add more 
>> options down the line.
>
> Sounds a lot like the above would be TUNE_FEATURES to me..  (even if we don't
> necessarily define a tune that uses them -- if it's standard another layer
> certainly could.)
>
>> Regarding fpu, gcc supports the following for armv8: fp-armv8, 
>> neon-fp-armv8, and crypto-neon-fp-armv8.
>>
>> Regarding cpu, I believe that the armv8 supported ones are: ‘cortex-a32’, 
>> ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’, ‘cortex-a72’, 
>> ‘cortex-a73’, ‘cortex-a75’.
>>
>> I personally would like to keep tuning for a specific CPU as much as 
>> possible (again I'm working closely with various ARM-based SoCs, so my 
>> opinion might be tainted).
>
> Thats a lot of options, but if we focus on TUNE_FEATURES, I think it's a bit
> more reasonable to support all of this.. (maybe that is what needs to be done 
> in
> the future as well for other architectures.. focus on the 'gcc' behavior and
> generate TUNE_FEATURES matching the compiler.)
>
> I'd like Khem's opinion on how crazy of an idea that is.
>
>> One thing that could be done to simplify things would be to just use the 
>> cpu, and add the options to it. Gcc supports adding options to the cpu.
>> '+nofp' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’ and ‘cortex-a55’
>> '+crypto' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, 
>> ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’
>>
>> That could simplify the tune settings, but would give less control than what 
>> we currently have.
>> As you might have guessed, I do put a specific emphasis on the crypto 
>> option, and on the neon option, which are the most interesting for armv8 in 
>> my opinion.
>
> In the past 'crypto' options have only been assembly.. if that's changed it 
> has
> definitely opened up a new facet in all of this work.
>
>> Regarding thumb, always adding it to the tune without creating specific 
>> variants with or without thumb makes sense, since the tune is normally about 
>> the SoC capabilities, and arv7 and armv8 both support it.
>> You can always select whether you want thumb or not by setting 
>> ARM_INSTRUCTION_SET appropriately at the distro level.
>
> Yes, that might be needed now that thumb is theoretically always supposed to 
> be
> present.

It's not _always_ present - it's missing for armv4 CPUs such as StrongARM.

However the option has been unnecessarily propagated into tuning files
for higher architecture levels where support for Thumb _is_ always
present.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Mark Hatle]

On 6/12/18 10:49 AM, Herve Jourdain wrote:
> Hi,
> 
> So I agree with you about restricting to what gcc can support, that's 
> actually my proposal (actually, probably a subset of what gcc can support).
> So for armv8, gcc supports, as architectures: armv8-a, armv8.1-a, armv8.2-a, 
> armv8.3-a, armv8.4-a.
> Then, you can add the supported options with a "+" after the architecture.
> Options supported for armv8-a are: '+crc', '+simd', '+crypto', '+nocrypto', 
> '+nofp'
> Options supported for armv8.1-a are: '+simd', '+crypto', '+nocrypto', '+nofp'
> Options supported for armv8.2-a and armv8.3-a are: '+fp16', '+fp16fml', 
> '+simd', '+crypto', '+dotprod', '+nocrypto', '+nofp'
> Options supported for armv8.4-a are: '+fp16', '+simd', '+crypto', '+dotprod', 
> '+nocrypto', '+nofp'
> 
> As you can see, proposals for armv8-a, whether my previous one, the new one 
> here, or even the one I have updated and used in production, just capture the 
> existing complexity, and not add to it.
> and support for armv8.1-a, armv8.2-a, armv8.3-a, armv8.4a will only add more 
> options down the line.

Sounds a lot like the above would be TUNE_FEATURES to me..  (even if we don't
necessarily define a tune that uses them -- if it's standard another layer
certainly could.)

> Regarding fpu, gcc supports the following for armv8: fp-armv8, neon-fp-armv8, 
> and crypto-neon-fp-armv8.
> 
> Regarding cpu, I believe that the armv8 supported ones are: ‘cortex-a32’, 
> ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’, ‘cortex-a72’, 
> ‘cortex-a73’, ‘cortex-a75’.
> 
> I personally would like to keep tuning for a specific CPU as much as possible 
> (again I'm working closely with various ARM-based SoCs, so my opinion might 
> be tainted).

Thats a lot of options, but if we focus on TUNE_FEATURES, I think it's a bit
more reasonable to support all of this.. (maybe that is what needs to be done in
the future as well for other architectures.. focus on the 'gcc' behavior and
generate TUNE_FEATURES matching the compiler.)

I'd like Khem's opinion on how crazy of an idea that is.

> One thing that could be done to simplify things would be to just use the cpu, 
> and add the options to it. Gcc supports adding options to the cpu.
> '+nofp' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’ and ‘cortex-a55’
> '+crypto' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, 
> ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’
> 
> That could simplify the tune settings, but would give less control than what 
> we currently have.
> As you might have guessed, I do put a specific emphasis on the crypto option, 
> and on the neon option, which are the most interesting for armv8 in my 
> opinion.

In the past 'crypto' options have only been assembly.. if that's changed it has
definitely opened up a new facet in all of this work.

> Regarding thumb, always adding it to the tune without creating specific 
> variants with or without thumb makes sense, since the tune is normally about 
> the SoC capabilities, and arv7 and armv8 both support it.
> You can always select whether you want thumb or not by setting 
> ARM_INSTRUCTION_SET appropriately at the distro level.

Yes, that might be needed now that thumb is theoretically always supposed to be
present.

--Mark

> Cheers,
> Herve
> 
> -Original Message-
> From: Mark Hatle [mailto:mark.ha...@windriver.com] 
> Sent: mardi 12 juin 2018 16:32
> To: Herve Jourdain ; 'Koen Kooi' 
> ; 'Randy Li' 
> Cc: 'OE-core' 
> Subject: Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex 
> processors
> 
> On 6/12/18 4:30 AM, Herve Jourdain wrote:
>> Hi,
>>
>> I believe I'm the "original author" of some patch attempt at tackling this 
>> problem, more than a year ago, as referenced in this series.
>> And I understand why everyone, Khem being the first and not the only one, 
>> would like some "simpler" things for ARM.
>> But the problem is that ARM-based SoCs are very diverse, and ARM does have a 
>> number of optional IP blocks (such as crypto, but neon is another one, and 
>> there are others), defined for each architecture. Then ARM defines some 
>> "standard" SoCs (like cortex-A53, cortex-A57, ...) which may set some of 
>> those optional IPs as required for that SoC, and the rest still as optional.
>> And SoC vendors decide what optional IPs they will implement or not...
> 
> Simplification is a goal in this, but as you said, not always reasonable with 
> a processor designed to be customized.
> 
> Typically true customization (vendor specific) doesn't belong in the oe-core 
> tune files, but stuff that is architecturally defined may.
> 
>> So when we're talking "cortex-A53", it's not necessarily the same cortex-A53 
>> for all SoC vendors.
>>
>> GCC does support all that complexity. So the main question is, do we want to 
>> be able to generate code that could take advantage of the optional IPs 
>> present on a SoC? Or do we prefer to settle for the least common denominator?
> 
> I think this 

Re: [OE-core] [PATCH V2] bitbake.conf: add BB_CURRENT_MC to OVERRIDES

[Andre McCurdy]

On Tue, Jun 12, 2018 at 4:43 AM, Ming Liu  wrote:
> Hi, Andre:
> The reason for needing this multiconfig to be in OVERRIDES, for me, is the
> scenario that I have one recipe but some variables/tasks in it are different
> for multiconfig, for instance:
>
> do_install-mc-default () {}
>
> do_install-mc-foo() {}
>
> and I do not want split them into several almost same recipes with only one
> task different.

Yes, that's clear. But the question is whether you can make the
over-rides you need self contained within the multiconfig config file?

e.g. to enable an over-ride when you build with multiconfig foo, add:

  OVERRIDES .= ":mc-foo"

to foo.conf

If it works, then it gives you more flexibility - you can pick your
own over-ride naming, define multiple over-rides per multiconfig, etc.

> //Ming Liu
>
> 2018-06-12 1:15 GMT+02:00 Andre McCurdy :
>>
>> On Mon, Jun 11, 2018 at 4:34 AM,   wrote:
>> > From: Ming Liu 
>> >
>> > This is useful when the users want different variables/tasks when using
>> > multiconfig.
>>
>> Isn't the idea of multiconfig to select between configurations which
>> already fully define all necessary over-rides?
>>
>> If a particular multiconfig build needs a custom over-ride then the
>> multiconfig can append to OVERRIDES (or MACHINEOVERRIDES etc, as
>> appropriate) directly.
>>
>> ie to avoid confusion isn't it good if building with a multiconfig
>> enabled is always equivalent to building with the contents of the
>> multiconfig file copied directly in local.conf?
>>
>> > Signed-off-by: Ming Liu 
>> > ---
>> >  meta/conf/bitbake.conf | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> > index 3b2ef9f..0c803d5 100644
>> > --- a/meta/conf/bitbake.conf
>> > +++ b/meta/conf/bitbake.conf
>> > @@ -731,7 +731,7 @@ DISTRO_NAME ??= "OpenEmbedded"
>> >  # And finally '_forcevariable' overrides any standard variable,
>> > with the highest priority.
>> >  # This works for functions as well, they are really just variables.
>> >  #
>> > -OVERRIDES =
>> > "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:forcevariable"
>> > +OVERRIDES =
>> > "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:mc-${BB_CURRENT_MC}:forcevariable"
>> >  LIBCOVERRIDE ?= ""
>> >  CLASSOVERRIDE ?= "class-target"
>> >  DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}"
>> > --
>> > 2.7.4
>> >
>> > --
>> > ___
>> > Openembedded-core mailing list
>> > Openembedded-core@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/7] openssh: stop adding -D__FILE_OFFSET_BITS=64 to CFLAGS

[Andre McCurdy]

On Thu, Jun 7, 2018 at 11:48 AM, Andre McCurdy  wrote:
> Openssh takes care of enabling large-file support automatically via
> the AC_SYS_LARGEFILE in the configure.ac, so additional help from the
> recipe is not required.
>
> Even if it were once required, defining __FILE_OFFSET_BITS (ie with
> double leading underscores) looks like a typo and probably never had
> any effect anyway?

Ping.

Any issues with this (the whole series of 7)?

> Signed-off-by: Andre McCurdy 
> ---
>  meta/recipes-connectivity/openssh/openssh_7.7p1.bb | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/meta/recipes-connectivity/openssh/openssh_7.7p1.bb 
> b/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
> index 7b6ee5c..7cf34eb 100644
> --- a/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
> +++ b/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
> @@ -46,9 +46,6 @@ SYSTEMD_SERVICE_${PN}-sshd = "sshd.socket"
>
>  inherit autotools-brokensep ptest
>
> -# LFS support:
> -CFLAGS += "-D__FILE_OFFSET_BITS=64"
> -
>  EXTRA_AUTORECONF += "--exclude=aclocal"
>
>  # login path is hardcoded in sshd
> --
> 1.9.1
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/6] gcc-runtime: Remove -mcpu=cortex-a7 when building for -march=armv7ve

[Andre McCurdy]

On Tue, May 29, 2018 at 10:04 PM, Khem Raj  wrote:
> This fixes conflicts like
> cc1: error: switch -mcpu=cortex-a7 conflicts with -march=armv7-a switch 
> [-Werror]

Ross, this patch still seems to be living on in mut, even after the
latest rebase. It should be dropped as the latest gcc8 patchset
contained a better fix.

> Signed-off-by: Khem Raj 
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-devtools/gcc/gcc-runtime.inc | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
> b/meta/recipes-devtools/gcc/gcc-runtime.inc
> index 72b8081cd3..22617a2838 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> @@ -14,6 +14,8 @@ EXTRA_OECONF_PATHS = "\
>  --with-build-sysroot=${STAGING_DIR_TARGET} \
>  "
>
> +TUNE_FEATURES_remove_armv7ve = "cortexa7"
> +
>  EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
>
>  RUNTIMELIBITM = "libitm"
> --
> 2.17.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Herve Jourdain]

Hi,

So I agree with you about restricting to what gcc can support, that's actually 
my proposal (actually, probably a subset of what gcc can support).
So for armv8, gcc supports, as architectures: armv8-a, armv8.1-a, armv8.2-a, 
armv8.3-a, armv8.4-a.
Then, you can add the supported options with a "+" after the architecture.
Options supported for armv8-a are: '+crc', '+simd', '+crypto', '+nocrypto', 
'+nofp'
Options supported for armv8.1-a are: '+simd', '+crypto', '+nocrypto', '+nofp'
Options supported for armv8.2-a and armv8.3-a are: '+fp16', '+fp16fml', 
'+simd', '+crypto', '+dotprod', '+nocrypto', '+nofp'
Options supported for armv8.4-a are: '+fp16', '+simd', '+crypto', '+dotprod', 
'+nocrypto', '+nofp'

As you can see, proposals for armv8-a, whether my previous one, the new one 
here, or even the one I have updated and used in production, just capture the 
existing complexity, and not add to it.
and support for armv8.1-a, armv8.2-a, armv8.3-a, armv8.4a will only add more 
options down the line.

Regarding fpu, gcc supports the following for armv8: fp-armv8, neon-fp-armv8, 
and crypto-neon-fp-armv8.

Regarding cpu, I believe that the armv8 supported ones are: ‘cortex-a32’, 
‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’, ‘cortex-a72’, 
‘cortex-a73’, ‘cortex-a75’.

I personally would like to keep tuning for a specific CPU as much as possible 
(again I'm working closely with various ARM-based SoCs, so my opinion might be 
tainted).

One thing that could be done to simplify things would be to just use the cpu, 
and add the options to it. Gcc supports adding options to the cpu.
'+nofp' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’ and ‘cortex-a55’
'+crypto' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, 
‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’

That could simplify the tune settings, but would give less control than what we 
currently have.
As you might have guessed, I do put a specific emphasis on the crypto option, 
and on the neon option, which are the most interesting for armv8 in my opinion.

Regarding thumb, always adding it to the tune without creating specific 
variants with or without thumb makes sense, since the tune is normally about 
the SoC capabilities, and arv7 and armv8 both support it.
You can always select whether you want thumb or not by setting 
ARM_INSTRUCTION_SET appropriately at the distro level.

Cheers,
Herve

-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com] 
Sent: mardi 12 juin 2018 16:32
To: Herve Jourdain ; 'Koen Kooi' 
; 'Randy Li' 
Cc: 'OE-core' 
Subject: Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex 
processors

On 6/12/18 4:30 AM, Herve Jourdain wrote:
> Hi,
> 
> I believe I'm the "original author" of some patch attempt at tackling this 
> problem, more than a year ago, as referenced in this series.
> And I understand why everyone, Khem being the first and not the only one, 
> would like some "simpler" things for ARM.
> But the problem is that ARM-based SoCs are very diverse, and ARM does have a 
> number of optional IP blocks (such as crypto, but neon is another one, and 
> there are others), defined for each architecture. Then ARM defines some 
> "standard" SoCs (like cortex-A53, cortex-A57, ...) which may set some of 
> those optional IPs as required for that SoC, and the rest still as optional.
> And SoC vendors decide what optional IPs they will implement or not...

Simplification is a goal in this, but as you said, not always reasonable with a 
processor designed to be customized.

Typically true customization (vendor specific) doesn't belong in the oe-core 
tune files, but stuff that is architecturally defined may.

> So when we're talking "cortex-A53", it's not necessarily the same cortex-A53 
> for all SoC vendors.
> 
> GCC does support all that complexity. So the main question is, do we want to 
> be able to generate code that could take advantage of the optional IPs 
> present on a SoC? Or do we prefer to settle for the least common denominator?

I think this is the key.  What combinations does GCC support (actually generate
code for?)   If GCC can't generate code for that combination, then I don't
believe it belongs as a tune in OE-Core, unless there is a compelling argument 
that assembly level functions will be common enough to justify it.

> As someone who is close to the SoC, I definitely would prefer to be able to 
> take advantage of the optional IPs present on an ARM SoC, and I'd rather have 
> a system that can at least support that even if it's slightly more complex. 
> This said, once it's done, most people won't look under the hood but just use 
> it, so the complexity would end up being hidden - much like now with armv7.

And this is why my GCC statement is being made.  Most developers will define a 
tune, but will never go into the assembly realm.  They simply don't have the 
knowledge or care to devote a bunch of time for a .5% performance improvement.
If GCC can add 

Re: [OE-core] [PATCH 10/12] sqlite3: upgrade to 3.24.0

[Maxin B. John]

Hi Ross,

On Tue, Jun 12, 2018 at 04:22:30PM +0100, Burton, Ross wrote:
> Fails for me when building pseudo:
> 
> | 
> /data/poky-tmp/master/work/x86_64-linux/pseudo-native/1.9.0+gitAUTOINC+fddbe854c9-r0/recipe-sysroot-native/usr/lib/libsqlite3.a(sqlite3.o):
> In function `fts5Bm25Function':
> | sqlite3.c:(.text+0x2a3b8): undefined reference to `log'

Will look into that. Thanks.

> Ross

Best Regards,
Maxin

> On 12 June 2018 at 12:18, Maxin B. John  wrote:
> > 3.23.1 -> 3.24.0
> >
> > Signed-off-by: Maxin B. John 
> > ---
> >  meta/recipes-support/sqlite/{sqlite3_3.23.1.bb => sqlite3_3.24.0.bb} | 4 
> > ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >  rename meta/recipes-support/sqlite/{sqlite3_3.23.1.bb => 
> > sqlite3_3.24.0.bb} (59%)
> >
> > diff --git a/meta/recipes-support/sqlite/sqlite3_3.23.1.bb 
> > b/meta/recipes-support/sqlite/sqlite3_3.24.0.bb
> > similarity index 59%
> > rename from meta/recipes-support/sqlite/sqlite3_3.23.1.bb
> > rename to meta/recipes-support/sqlite/sqlite3_3.24.0.bb
> > index 3755761..ce18fec 100644
> > --- a/meta/recipes-support/sqlite/sqlite3_3.23.1.bb
> > +++ b/meta/recipes-support/sqlite/sqlite3_3.24.0.bb
> > @@ -6,5 +6,5 @@ LIC_FILES_CHKSUM = 
> > "file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed0
> >  SRC_URI = "\
> >http://www.sqlite.org/2018/sqlite-autoconf-${SQLITE_PV}.tar.gz \
> >"
> > -SRC_URI[md5sum] = "99a51b40a66872872a91c92f6d0134fa"
> > -SRC_URI[sha256sum] = 
> > "92842b283e5e744eff5da29ed3c69391de7368fccc4d0ee6bf62490ce555ef25"
> > +SRC_URI[md5sum] = "dcd96fb9bbb603d29f6b0ad9554932ee"
> > +SRC_URI[sha256sum] = 
> > "d9d14e88c6fb6d68de9ca0d1f9797477d82fc3aed613558f87ffbdbbc5ceb74a"
> > --
> > 2.4.0
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libdrm: drop uclibc-specific patch

[Ross Burton]

This patch isn't needed for musl or glibc, so drop it.

Signed-off-by: Ross Burton 
---
 .../drm/libdrm/fix_O_CLOEXEC_undeclared.patch  | 24 --
 meta/recipes-graphics/drm/libdrm_2.4.92.bb |  1 -
 2 files changed, 25 deletions(-)
 delete mode 100644 
meta/recipes-graphics/drm/libdrm/fix_O_CLOEXEC_undeclared.patch

diff --git a/meta/recipes-graphics/drm/libdrm/fix_O_CLOEXEC_undeclared.patch 
b/meta/recipes-graphics/drm/libdrm/fix_O_CLOEXEC_undeclared.patch
deleted file mode 100644
index 4708bf1ebb8..000
--- a/meta/recipes-graphics/drm/libdrm/fix_O_CLOEXEC_undeclared.patch
+++ /dev/null
@@ -1,24 +0,0 @@
-drmdevice.c: define _GNU_SOURCE
-
-Include config.h to fix this build error with uclibc:
-
-libdrm-2.4.66/tests/drmdevice.c: In function 'main':
-libdrm-2.4.66/tests/drmdevice.c:96:60: error:
-'O_CLOEXEC' undeclared (first use in this function)
-fd = open(devices[i]->nodes[j],O_RDONLY | O_CLOEXEC, 0);
-
-Upstream-Status: Pending
-
-Signed-off-by: Maxin B. John 

-diff -Naur libdrm-2.4.66-orig/tests/drmdevice.c libdrm-2.4.66/tests/drmdevice.c
 libdrm-2.4.66-orig/tests/drmdevice.c   2016-02-23 11:34:02.054904502 
+0200
-+++ libdrm-2.4.66/tests/drmdevice.c2016-02-23 11:35:34.371750383 +0200
-@@ -21,6 +21,7 @@
-  *
-  */
- 
-+#include 
- #include 
- #include 
- #include 
diff --git a/meta/recipes-graphics/drm/libdrm_2.4.92.bb 
b/meta/recipes-graphics/drm/libdrm_2.4.92.bb
index 8f59452a49c..2b3bf4f83d2 100644
--- a/meta/recipes-graphics/drm/libdrm_2.4.92.bb
+++ b/meta/recipes-graphics/drm/libdrm_2.4.92.bb
@@ -12,7 +12,6 @@ DEPENDS = "libpthread-stubs libpciaccess"
 
 SRC_URI = "http://dri.freedesktop.org/libdrm/${BP}.tar.bz2 \
file://installtests.patch \
-   file://fix_O_CLOEXEC_undeclared.patch \

file://0001-configure.ac-Allow-explicit-enabling-of-cunit-tests.patch \
   "
 
-- 
2.11.0

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

Re: [OE-core] [PATCH 10/12] sqlite3: upgrade to 3.24.0

[Burton, Ross]

Fails for me when building pseudo:

| 
/data/poky-tmp/master/work/x86_64-linux/pseudo-native/1.9.0+gitAUTOINC+fddbe854c9-r0/recipe-sysroot-native/usr/lib/libsqlite3.a(sqlite3.o):
In function `fts5Bm25Function':
| sqlite3.c:(.text+0x2a3b8): undefined reference to `log'

Ross

On 12 June 2018 at 12:18, Maxin B. John  wrote:
> 3.23.1 -> 3.24.0
>
> Signed-off-by: Maxin B. John 
> ---
>  meta/recipes-support/sqlite/{sqlite3_3.23.1.bb => sqlite3_3.24.0.bb} | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-support/sqlite/{sqlite3_3.23.1.bb => sqlite3_3.24.0.bb} 
> (59%)
>
> diff --git a/meta/recipes-support/sqlite/sqlite3_3.23.1.bb 
> b/meta/recipes-support/sqlite/sqlite3_3.24.0.bb
> similarity index 59%
> rename from meta/recipes-support/sqlite/sqlite3_3.23.1.bb
> rename to meta/recipes-support/sqlite/sqlite3_3.24.0.bb
> index 3755761..ce18fec 100644
> --- a/meta/recipes-support/sqlite/sqlite3_3.23.1.bb
> +++ b/meta/recipes-support/sqlite/sqlite3_3.24.0.bb
> @@ -6,5 +6,5 @@ LIC_FILES_CHKSUM = 
> "file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed0
>  SRC_URI = "\
>http://www.sqlite.org/2018/sqlite-autoconf-${SQLITE_PV}.tar.gz \
>"
> -SRC_URI[md5sum] = "99a51b40a66872872a91c92f6d0134fa"
> -SRC_URI[sha256sum] = 
> "92842b283e5e744eff5da29ed3c69391de7368fccc4d0ee6bf62490ce555ef25"
> +SRC_URI[md5sum] = "dcd96fb9bbb603d29f6b0ad9554932ee"
> +SRC_URI[sha256sum] = 
> "d9d14e88c6fb6d68de9ca0d1f9797477d82fc3aed613558f87ffbdbbc5ceb74a"
> --
> 2.4.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Mark Hatle]

On 6/12/18 4:30 AM, Herve Jourdain wrote:
> Hi,
> 
> I believe I'm the "original author" of some patch attempt at tackling this 
> problem, more than a year ago, as referenced in this series.
> And I understand why everyone, Khem being the first and not the only one, 
> would like some "simpler" things for ARM.
> But the problem is that ARM-based SoCs are very diverse, and ARM does have a 
> number of optional IP blocks (such as crypto, but neon is another one, and 
> there are others), defined for each architecture. Then ARM defines some 
> "standard" SoCs (like cortex-A53, cortex-A57, ...) which may set some of 
> those optional IPs as required for that SoC, and the rest still as optional.
> And SoC vendors decide what optional IPs they will implement or not...

Simplification is a goal in this, but as you said, not always reasonable with a
processor designed to be customized.

Typically true customization (vendor specific) doesn't belong in the oe-core
tune files, but stuff that is architecturally defined may.

> So when we're talking "cortex-A53", it's not necessarily the same cortex-A53 
> for all SoC vendors.
> 
> GCC does support all that complexity. So the main question is, do we want to 
> be able to generate code that could take advantage of the optional IPs 
> present on a SoC? Or do we prefer to settle for the least common denominator?

I think this is the key.  What combinations does GCC support (actually generate
code for?)   If GCC can't generate code for that combination, then I don't
believe it belongs as a tune in OE-Core, unless there is a compelling argument
that assembly level functions will be common enough to justify it.

> As someone who is close to the SoC, I definitely would prefer to be able to 
> take advantage of the optional IPs present on an ARM SoC, and I'd rather have 
> a system that can at least support that even if it's slightly more complex. 
> This said, once it's done, most people won't look under the hood but just use 
> it, so the complexity would end up being hidden - much like now with armv7.

And this is why my GCC statement is being made.  Most developers will define a
tune, but will never go into the assembly realm.  They simply don't have the
knowledge or care to devote a bunch of time for a .5% performance improvement.
If GCC can add specific optimizations, then we've hit the 'trivial optimization'
phase, and a tune may be justified.  We just need to be careful of the variant
names -- once set they will last a VERY long time.

> I've personally followed up on my patches from last year, and I now have a 
> slightly modified/simplified version of them, which I've used to build some 
> production-ready environments using cortex-a53/armv8 tunes, that trigger the 
> optimization for cortex-a53 + neon. And if the SoC I'm working with had the 
> crypto extension, I would be very happy to build for it, by just switching 
> the tune I use for my cortex-a53 to the armv8 tune supporting crypto.
> 
> So I believe now may be a good time to talk this over again, because we're 
> basically building for cortex-a53 with cortexa7/armv7ve, and that is not the 
> most optimal thing to do in my opinion (like, some instructions that were 
> native in armv7ve are simulated in armv8).

I don't think anyone objects to armv8, but I was under the impression that
things like neon were now 'required', (i.e. were not supposed to be removed from
the instruction set.)  So for anything that is now standard, they would be the
definition of armv8.. and if there are rare, but customized version w/o neon or
something else -- then I think it's a silicon vendor specific tune that is 
needed.

In the end it comes down to what has ARM specified, what does GCC support, and
what is ACTUALLY being broadly implemented.

> One thing that I did come up as a simplification was the handling of thumb, I 
> don't think it needs to be an option anymore, since its support is mandatory 
> in armv8 (but I think it was also the case in armv7). That simplifies things 
> a bit, but nothing fundamental, you still need to carry the support for the 
> optional IPs around...

The only reason to continue with the existing 32-bit naming conventions (t,
neon, vfp, etc) is to show the compatibility matrix.  I don't know if this
actually justifies the extensions though.  (I do know I have customers who never
want to use thumb or always [as much as possible] want to use thumb based on
their own performance requirements and designs.. so thumb being switchable is
still a desired attribute -- at least in the armv7 designs I know of.)

> And in addition to what I proposed to support last year, we indeed now have 
> to add armv8.1a, armv8.2a, armv8.3a, armv8.4a (so far...), which each have 
> their own specificities/differences that make it unlikely to be supported 
> within a single file.

IF the instruction scheduling, generated instructions, optimizations, etc are
truely different.. then we should call them armv81a, etc..  (I 

Re: [OE-core] [PATCH v2 1/4] arch-armv8a.inc: add tune include for armv8

[Mark Hatle]

On 6/12/18 12:59 AM, Nicolas Dechesne wrote:
> On Sat, Jun 9, 2018 at 8:26 AM, Randy Li  wrote:
>> There are some addtional instructions apart from bare armv8,
>> also there is armv8.1, armv8.2.
>>
>> Most the processor would support crc, except X-gene 1.
> 
> the commit message doesn't really explain what is going on in this patch..
> 
>>
>> Signed-off-by: Randy Li 
>> ---
>>  meta/conf/machine/include/arm/arch-armv8.inc  |  1 -
>>  meta/conf/machine/include/arm/arch-armv8a.inc | 22 ++
>>  2 files changed, 22 insertions(+), 1 deletion(-)
>>  delete mode 100644 meta/conf/machine/include/arm/arch-armv8.inc
> ^^ this file is used by probably any armv8 machine out there, even
> inside oe-core:
> 
> $ git grep "arch-armv8\.inc"
> include/tune-thunderx.inc:require conf/machine/include/arm/arch-armv8.inc
> qemuarm64.conf:require conf/machine/include/arm/arch-armv8.inc
> 
> so this change would break many things. and it's used in many BSP layers.
> 
>>  create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc
>>
>> diff --git a/meta/conf/machine/include/arm/arch-armv8.inc 
>> b/meta/conf/machine/include/arm/arch-armv8.inc
>> deleted file mode 100644
>> index 5e832fae6d..00
>> --- a/meta/conf/machine/include/arm/arch-armv8.inc
>> +++ /dev/null
>> @@ -1 +0,0 @@
>> -require conf/machine/include/arm/arch-arm64.inc
>> diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc 
>> b/meta/conf/machine/include/arm/arch-armv8a.inc
>> new file mode 100644
>> index 00..b8b9e44c54
>> --- /dev/null
>> +++ b/meta/conf/machine/include/arm/arch-armv8a.inc
>> @@ -0,0 +1,22 @@
>> +DEFAULTTUNE ?= "armv8a-crc"
> 
> even without taking into consideration that this is changing all
> default configs for arm64.. which should for sure be discussed and
> agreed upon... the crc and crypto flags you are adding here, are not
> defined anywhere.
> 
> please review how the armv7 variants were designed/introduced, and try
> to mimic that for armv8 if you think it's needed.
> 
>> +
>> +TUNEVALID[armv8] = "Enable instructions for ARMv8-a"
>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', ' 
>> -march=armv8-a', '', d)}"
>> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', 
>> 'armv8a:', '' ,d)}"
>> +
>> +require conf/machine/include/arm/arch-arm64.inc
>> +
>> +# Little Endian base configs
>> +AVAILTUNES += "armv8a armv8a-crc armv8a-crc-crypto armv8a-crypto"
>> +ARMPKGARCH_tune-armv8a?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-crc?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-crypto ?= "armv8a"
>> +ARMPKGARCH_tune-armv8a-crc-crypto ?= "armv8a"

To add to Nicolas's comment.  Are any of the variants mentioned above, have the
additional instructions generated by the toolchain?  Or are they purely assembly
level functionality?

Generally we defined tunes as something that can be generated by the compiler.
For things that are assembly driven, a new tune is rarely required, but instead
the developer of the component should either do run-time switching of assembly
functions, or it becomes board/distribution specific.  (There are always
exceptions to that, but that policy helps simplify the tunes to things that 
matter.)

>> +TUNE_FEATURES_tune-armv8a  = "armv8a simd"
>> +TUNE_FEATURES_tune-armv8a-crc  = "${ARMPKGARCH_tune-armv8a} crc"
>> +TUNE_FEATURES_tune-armv8a-crypto   = "${TUNE_FEATURES_tune-armv8a} 
>> crypto"
>> +TUNE_FEATURES_tune-armv8a-crc-crypto   = 
>> "${TUNE_FEATURES_tune-armv8a-crc} crypto"
>> +PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a simd"
>> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crc= 
>> "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
>> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto = 
>> "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
>> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto = 
>> "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
>> --
>> 2.14.3
>>
>> --
>> ___
>> 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] rm_work: remove obsolete rm_work_all task

[Richard Purdie]

On Tue, 2018-06-12 at 14:37 +0100, Ross Burton wrote:
> *all tasks have been deprecated and replaced by bitbake --runall.
> 
> Signed-off-by: Ross Burton 
> ---
>  meta/classes/rm_work.bbclass | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/meta/classes/rm_work.bbclass
> b/meta/classes/rm_work.bbclass
> index 318d121d2b5..ff74d232c97 100644
> --- a/meta/classes/rm_work.bbclass
> +++ b/meta/classes/rm_work.bbclass
> @@ -115,12 +115,6 @@ do_rm_work () {
>  fi
>  done
>  }
> -do_rm_work_all () {
> -:
> -}
> -do_rm_work_all[recrdeptask] = "do_rm_work"
> -do_rm_work_all[noexec] = "1"
> -addtask rm_work_all after before do_build
>  
>  do_populate_sdk[postfuncs] += "rm_work_populatesdk"
>  rm_work_populatesdk () {

The idea was to remove the "all" tasks which could be done
better/differently.

I think this one may be an integral part of how rm_work gets triggered
and that without this, bits of the build won't get cleaned up. The key
part is the "before do_build", i.e. its active in the taskgraph of
standard builds.

Cheers,

Richard

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

[OE-core] [PATCH] rm_work: remove obsolete rm_work_all task

[Ross Burton]

*all tasks have been deprecated and replaced by bitbake --runall.

Signed-off-by: Ross Burton 
---
 meta/classes/rm_work.bbclass | 6 --
 1 file changed, 6 deletions(-)

diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
index 318d121d2b5..ff74d232c97 100644
--- a/meta/classes/rm_work.bbclass
+++ b/meta/classes/rm_work.bbclass
@@ -115,12 +115,6 @@ do_rm_work () {
 fi
 done
 }
-do_rm_work_all () {
-:
-}
-do_rm_work_all[recrdeptask] = "do_rm_work"
-do_rm_work_all[noexec] = "1"
-addtask rm_work_all after before do_build
 
 do_populate_sdk[postfuncs] += "rm_work_populatesdk"
 rm_work_populatesdk () {
-- 
2.11.0

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

[OE-core] [PATCH] alsa-tools: rewrite packaging

[Ross Burton]

alsa-tools is actually a collection of 20 separate tools, each with their own
configure scripts.  The dependencies are varied, old, and estoric (FLTK, GTK+ 
1, 2,
and 3, PyGTK 2, Qt3).

Instead of maintaining patches to try and pick a subset that builds, use
PACKAGECONFIG and some magic to build what the user requests.

By default we build all the tools which have no dependencies, and the tools
which need GTK+ 2 or GTK+ 3 if the relevant DISTRO_FEATURES are enabled.

Add a patch to fix the build of ld10k1 with musl.

The ncurses build dependency doesn't seem to be checked for, so remove that.

Signed-off-by: Ross Burton 
---
 ...g-Wreserved-user-defined-literal-warnings.patch | 14 +++-
 .../alsa/alsa-tools/autotools.patch| 44 ---
 .../alsa/alsa-tools/gitcompile_hdajacksensetest| 13 ---
 .../alsa/alsa-tools/makefile_no_gtk.patch  | 29 ---
 meta/recipes-multimedia/alsa/alsa-tools/musl.patch | 47 +++
 meta/recipes-multimedia/alsa/alsa-tools_1.1.6.bb   | 92 +++---
 6 files changed, 119 insertions(+), 120 deletions(-)
 delete mode 100644 meta/recipes-multimedia/alsa/alsa-tools/autotools.patch
 delete mode 100755 
meta/recipes-multimedia/alsa/alsa-tools/gitcompile_hdajacksensetest
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
 create mode 100644 meta/recipes-multimedia/alsa/alsa-tools/musl.patch

diff --git 
a/meta/recipes-multimedia/alsa/alsa-tools/0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch
 
b/meta/recipes-multimedia/alsa/alsa-tools/0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch
index 2290915eab8..c137bc8a284 100644
--- 
a/meta/recipes-multimedia/alsa/alsa-tools/0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch
+++ 
b/meta/recipes-multimedia/alsa/alsa-tools/0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch
@@ -1,14 +1,18 @@
-From 2e48e4045e1e951433da0ca4b1e49798eedde14f Mon Sep 17 00:00:00 2001
+Upstream-Status: Backport
+Signed-off-by: Khem Raj 
+
+From a861bdabf02cd9bfb3ec7c0571c563c0fa14adfb Mon Sep 17 00:00:00 2001
 From: Khem Raj 
-Date: Tue, 24 Apr 2018 12:21:18 -0700
-Subject: [PATCH] Fix clang -Wreserved-user-defined-literal warnings
+Date: Tue, 24 Apr 2018 12:24:32 -0700
+Subject: [PATCH] us428control: Fix clang -Wreserved-user-defined-literal
+ warnings
 
 | us428control.cc:66:18: error: invalid suffix on literal; C++11 requires a 
space between literal and identifier [-Wreserved-user-defined-literal]
 | printf("usage: "PROGNAME" [-v verbosity_level 0..2] [-c card] [-D 
device] [-u usb-device] [-m mode]\n");
 | ^
 
-Upstream-Status: Submitted [https://patchwork.kernel.org/patch/10360805/]
 Signed-off-by: Khem Raj 
+Signed-off-by: Takashi Iwai 
 ---
  us428control/us428control.cc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
@@ -26,3 +30,5 @@ index e839bf4..8cb3c42 100644
printf("mode is one of (us224, us428, mixxx)\n");
  }
  /*
+-- 
+1.7.11.7
diff --git a/meta/recipes-multimedia/alsa/alsa-tools/autotools.patch 
b/meta/recipes-multimedia/alsa/alsa-tools/autotools.patch
deleted file mode 100644
index c85834a593c..000
--- a/meta/recipes-multimedia/alsa/alsa-tools/autotools.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-From b9a65bf3ba5628cfe8cfd2d10ce2dcf11a606775 Mon Sep 17 00:00:00 2001
-From: Dongxiao Xu 
-Date: Thu, 14 Jul 2011 15:40:36 +0800
-Subject: [PATCH] alsa-tools: Fix recipe build error.
-
-Add parameters to autoreconf to support cross compile.
-Remove some sub-components which needs further recipe support.
-
-Signed-off-by: Dongxiao Xu 
-
-Upstream-Status: Inappropriate [configuration]
-

- Makefile  | 4 ++--
- ld10k1/gitcompile | 2 +-
- 2 files changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/Makefile b/Makefile
-index c32bf25..1119372 100644
 a/Makefile
-+++ b/Makefile
-@@ -1,8 +1,8 @@
- VERSION = 1.1.6
- TOP = .
--SUBDIRS = as10k1 envy24control hdsploader hdspconf hdspmixer \
-+SUBDIRS = as10k1 envy24control \
- mixartloader pcxhrloader rmedigicontrol sb16_csp seq sscape_ctl \
--us428control usx2yloader vxloader echomixer ld10k1 qlo10k1 \
-+us428control usx2yloader vxloader echomixer \
- hwmixvolume hdajackretask hda-verb hdajacksensetest
- 
- all:
-diff --git a/ld10k1/gitcompile b/ld10k1/gitcompile
-index 99429ac..20005d9 100755
 a/ld10k1/gitcompile
-+++ b/ld10k1/gitcompile
-@@ -1,6 +1,6 @@
- #!/bin/bash
- 
--autoreconf -fi || exit 1
-+autoreconf $ACLOCAL_FLAGS -fi || exit 1
- export CFLAGS='-O2 -Wall -pipe -g'
- echo "CFLAGS=$CFLAGS"
- echo "./configure $@"
diff --git 
a/meta/recipes-multimedia/alsa/alsa-tools/gitcompile_hdajacksensetest 
b/meta/recipes-multimedia/alsa/alsa-tools/gitcompile_hdajacksensetest
deleted file mode 100755
index 58328bd3a50..000
--- a/meta/recipes-multimedia/alsa/alsa-tools/gitcompile_hdajacksensetest
+++ /dev/null
@@ -1,13 +0,0 @@
-#!/bin/bash
-
-aclocal $ACLOCAL_FLAGS || exit 1
-automake 

Re: [OE-core] [PATCH V2] bitbake.conf: add BB_CURRENT_MC to OVERRIDES

[Ming Liu]

Hi, Andre:
The reason for needing this multiconfig to be in OVERRIDES, for me, is the
scenario that I have one recipe but some variables/tasks in it are
different for multiconfig, for instance:

do_install-mc-default () {}

do_install-mc-foo() {}

and I do not want split them into several almost same recipes with only one
task different.

//Ming Liu

2018-06-12 1:15 GMT+02:00 Andre McCurdy :

> On Mon, Jun 11, 2018 at 4:34 AM,   wrote:
> > From: Ming Liu 
> >
> > This is useful when the users want different variables/tasks when using
> > multiconfig.
>
> Isn't the idea of multiconfig to select between configurations which
> already fully define all necessary over-rides?
>
> If a particular multiconfig build needs a custom over-ride then the
> multiconfig can append to OVERRIDES (or MACHINEOVERRIDES etc, as
> appropriate) directly.
>
> ie to avoid confusion isn't it good if building with a multiconfig
> enabled is always equivalent to building with the contents of the
> multiconfig file copied directly in local.conf?
>
> > Signed-off-by: Ming Liu 
> > ---
> >  meta/conf/bitbake.conf | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index 3b2ef9f..0c803d5 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -731,7 +731,7 @@ DISTRO_NAME ??= "OpenEmbedded"
> >  # And finally '_forcevariable' overrides any standard variable,
> with the highest priority.
> >  # This works for functions as well, they are really just variables.
> >  #
> > -OVERRIDES = "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${
> MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:
> forcevariable"
> > +OVERRIDES = "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${
> MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:
> mc-${BB_CURRENT_MC}:forcevariable"
> >  LIBCOVERRIDE ?= ""
> >  CLASSOVERRIDE ?= "class-target"
> >  DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}"
> > --
> > 2.7.4
> >
> > --
> > ___
> > 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 12/12] xdg-utils: upgrade to 1.1.3

[Maxin B. John]

1.1.2 -> 1.1.3

Signed-off-by: Maxin B. John 
---
 .../xdg-utils/{xdg-utils_1.1.2.bb => xdg-utils_1.1.3.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/xdg-utils/{xdg-utils_1.1.2.bb => 
xdg-utils_1.1.3.bb} (89%)

diff --git a/meta/recipes-extended/xdg-utils/xdg-utils_1.1.2.bb 
b/meta/recipes-extended/xdg-utils/xdg-utils_1.1.3.bb
similarity index 89%
rename from meta/recipes-extended/xdg-utils/xdg-utils_1.1.2.bb
rename to meta/recipes-extended/xdg-utils/xdg-utils_1.1.3.bb
index 7339289..8e46638 100644
--- a/meta/recipes-extended/xdg-utils/xdg-utils_1.1.2.bb
+++ b/meta/recipes-extended/xdg-utils/xdg-utils_1.1.3.bb
@@ -22,8 +22,8 @@ SRC_URI = 
"http://portland.freedesktop.org/download/${BPN}-${PV}.tar.gz \
file://0001-Don-t-build-the-in-script-manual.patch \
   "
 
-SRC_URI[md5sum] = "361e75eb76c94d19f6f4f330d8ee626b"
-SRC_URI[sha256sum] = 
"951952e2c6bb21214e0bb54e0dffa057d30f5563300225c24c16fba846258bcc"
+SRC_URI[md5sum] = "902042508b626027a3709d105f0b63ff"
+SRC_URI[sha256sum] = 
"d798b08af8a8e2063ddde6c9fa3398ca81484f27dec642c5627ffcaa0d4051d9"
 
 UPSTREAM_CHECK_REGEX = 
"xdg-utils-(?P((\d+[\.\-_]*)+)((rc|alpha|beta)\d+)?)\.(tar\.gz|tgz)"
 
-- 
2.4.0

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

[OE-core] [PATCH 11/12] bluez5: upgrade to 5.50

[Maxin B. John]

Refresh the following patch:
0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch

Signed-off-by: Maxin B. John 
---
 ...-obexd-without-systemd-in-the-user-sessio.patch | 45 +-
 .../bluez5/{bluez5_5.49.bb => bluez5_5.50.bb}  |  4 +-
 2 files changed, 21 insertions(+), 28 deletions(-)
 rename meta/recipes-connectivity/bluez5/{bluez5_5.49.bb => bluez5_5.50.bb} 
(91%)

diff --git 
a/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
 
b/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
index 2fde7bc..da71409 100644
--- 
a/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
+++ 
b/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
@@ -1,3 +1,4 @@
+From 99ccdbe155028c4c789803a429072675b87d0c3a Mon Sep 17 00:00:00 2001
 From: Giovanni Campagna 
 Date: Sat, 12 Oct 2013 17:45:25 +0200
 Subject: [PATCH] Allow using obexd without systemd in the user session
@@ -14,19 +15,18 @@ configuration. See thread:
 http://thread.gmane.org/gmane.linux.bluez.kernel/38725/focus=38843
 
 Signed-off-by: Javier Viguera 
+
 ---
- Makefile.obexd  | 4 ++--
- obexd/src/org.bluez.obex.service| 4 
- obexd/src/org.bluez.obex.service.in | 4 
- 3 files changed, 6 insertions(+), 6 deletions(-)
- delete mode 100644 obexd/src/org.bluez.obex.service
- create mode 100644 obexd/src/org.bluez.obex.service.in
+ Makefile.obexd  | 4 ++--
+ obexd/src/{org.bluez.obex.service => org.bluez.obex.service.in} | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+ rename obexd/src/{org.bluez.obex.service => org.bluez.obex.service.in} (76%)
 
 diff --git a/Makefile.obexd b/Makefile.obexd
-index 2e33cbc72f2b..d5d858c857b4 100644
+index c462692..0325f66 100644
 --- a/Makefile.obexd
 +++ b/Makefile.obexd
-@@ -2,12 +2,12 @@
+@@ -1,12 +1,12 @@
  if SYSTEMD
  systemduserunitdir = @SYSTEMD_USERUNITDIR@
  systemduserunit_DATA = obexd/src/obex.service
@@ -39,25 +39,18 @@ index 2e33cbc72f2b..d5d858c857b4 100644
 -EXTRA_DIST += obexd/src/obex.service.in obexd/src/org.bluez.obex.service
 +EXTRA_DIST += obexd/src/obex.service.in obexd/src/org.bluez.obex.service.in
  
- obex_plugindir = $(libdir)/obex/plugins
+ if OBEX
  
-diff --git a/obexd/src/org.bluez.obex.service 
b/obexd/src/org.bluez.obex.service
-deleted file mode 100644
-index a53808884554..
+diff --git a/obexd/src/org.bluez.obex.service 
b/obexd/src/org.bluez.obex.service.in
+similarity index 76%
+rename from obexd/src/org.bluez.obex.service
+rename to obexd/src/org.bluez.obex.service.in
+index a538088..9c815f2 100644
 --- a/obexd/src/org.bluez.obex.service
-+++ /dev/null
-@@ -1,4 +0,0 @@
--[D-BUS Service]
--Name=org.bluez.obex
--Exec=/bin/false
--SystemdService=dbus-org.bluez.obex.service
-diff --git a/obexd/src/org.bluez.obex.service.in 
b/obexd/src/org.bluez.obex.service.in
-new file mode 100644
-index ..9c815f246b77
 /dev/null
 +++ b/obexd/src/org.bluez.obex.service.in
-@@ -0,0 +1,4 @@
-+[D-BUS Service]
-+Name=org.bluez.obex
+@@ -1,4 +1,4 @@
+ [D-BUS Service]
+ Name=org.bluez.obex
+-Exec=/bin/false
 +Exec=@libexecdir@/obexd
-+SystemdService=dbus-org.bluez.obex.service
+ SystemdService=dbus-org.bluez.obex.service
diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.49.bb 
b/meta/recipes-connectivity/bluez5/bluez5_5.50.bb
similarity index 91%
rename from meta/recipes-connectivity/bluez5/bluez5_5.49.bb
rename to meta/recipes-connectivity/bluez5/bluez5_5.50.bb
index b79bda2..6627143 100644
--- a/meta/recipes-connectivity/bluez5/bluez5_5.49.bb
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.50.bb
@@ -2,8 +2,8 @@ require bluez5.inc
 
 REQUIRED_DISTRO_FEATURES = "bluez5"
 
-SRC_URI[md5sum] = "f210e84db707d66af3b889084a6f8bef"
-SRC_URI[sha256sum] = 
"33301d7a514c73d535ee1f91c2aed1af1f2e53efe11d3ac06bcf0d7abed2ce95"
+SRC_URI[md5sum] = "8e35c67c81a55d3ad4c9f22280dae178"
+SRC_URI[sha256sum] = 
"5ffcaae18bbb6155f1591be8c24898dc12f062075a40b538b745bfd477481911"
 
 # noinst programs in Makefile.tools that are conditional on READLINE
 # support
-- 
2.4.0

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

[OE-core] [PATCH 10/12] sqlite3: upgrade to 3.24.0

[Maxin B. John]

3.23.1 -> 3.24.0

Signed-off-by: Maxin B. John 
---
 meta/recipes-support/sqlite/{sqlite3_3.23.1.bb => sqlite3_3.24.0.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/sqlite/{sqlite3_3.23.1.bb => sqlite3_3.24.0.bb} 
(59%)

diff --git a/meta/recipes-support/sqlite/sqlite3_3.23.1.bb 
b/meta/recipes-support/sqlite/sqlite3_3.24.0.bb
similarity index 59%
rename from meta/recipes-support/sqlite/sqlite3_3.23.1.bb
rename to meta/recipes-support/sqlite/sqlite3_3.24.0.bb
index 3755761..ce18fec 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.23.1.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.24.0.bb
@@ -6,5 +6,5 @@ LIC_FILES_CHKSUM = 
"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed0
 SRC_URI = "\
   http://www.sqlite.org/2018/sqlite-autoconf-${SQLITE_PV}.tar.gz \
   "
-SRC_URI[md5sum] = "99a51b40a66872872a91c92f6d0134fa"
-SRC_URI[sha256sum] = 
"92842b283e5e744eff5da29ed3c69391de7368fccc4d0ee6bf62490ce555ef25"
+SRC_URI[md5sum] = "dcd96fb9bbb603d29f6b0ad9554932ee"
+SRC_URI[sha256sum] = 
"d9d14e88c6fb6d68de9ca0d1f9797477d82fc3aed613558f87ffbdbbc5ceb74a"
-- 
2.4.0

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

[OE-core] [PATCH 09/12] mc: upgrade to 4.8.21

[Maxin B. John]

4.8.20 -> 4.8.21

Signed-off-by: Maxin B. John 
---
 meta/recipes-extended/mc/{mc_4.8.20.bb => mc_4.8.21.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/mc/{mc_4.8.20.bb => mc_4.8.21.bb} (93%)

diff --git a/meta/recipes-extended/mc/mc_4.8.20.bb 
b/meta/recipes-extended/mc/mc_4.8.21.bb
similarity index 93%
rename from meta/recipes-extended/mc/mc_4.8.20.bb
rename to meta/recipes-extended/mc/mc_4.8.21.bb
index 70d1b5e..c6a4500 100644
--- a/meta/recipes-extended/mc/mc_4.8.20.bb
+++ b/meta/recipes-extended/mc/mc_4.8.21.bb
@@ -9,8 +9,8 @@ RDEPENDS_${PN} = "ncurses-terminfo"
 SRC_URI = "http://www.midnight-commander.org/downloads/${BPN}-${PV}.tar.bz2 \
file://0001-mc-replace-perl-w-with-use-warnings.patch \
"
-SRC_URI[md5sum] = "dcfc7aa613c62291a0f71f6b698d8267"
-SRC_URI[sha256sum] = 
"2d85daaa6ab26e524946df4823ac2f69802bc16bc967781b5e28d5b86fc3b979"
+SRC_URI[md5sum] = "63d2b90e2198ee79d08eb4a8989220e2"
+SRC_URI[sha256sum] = 
"251d9f0ef9309ef3eea0fdc4c12b8b61149e5056bef1b2de2ccc7f015d973444"
 
 inherit autotools gettext pkgconfig
 
-- 
2.4.0

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

[OE-core] [PATCH 05/12] gtk-icon-utils-native: upgrade to 3.22.30

[Maxin B. John]

 3.22.29 -> 3.22.30

Signed-off-by: Maxin B. John 
---
 ...-icon-utils-native_3.22.29.bb => gtk-icon-utils-native_3.22.30.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-gnome/gtk+/{gtk-icon-utils-native_3.22.29.bb => 
gtk-icon-utils-native_3.22.30.bb} (94%)

diff --git a/meta/recipes-gnome/gtk+/gtk-icon-utils-native_3.22.29.bb 
b/meta/recipes-gnome/gtk+/gtk-icon-utils-native_3.22.30.bb
similarity index 94%
rename from meta/recipes-gnome/gtk+/gtk-icon-utils-native_3.22.29.bb
rename to meta/recipes-gnome/gtk+/gtk-icon-utils-native_3.22.30.bb
index eb35bcc..28e7a31 100644
--- a/meta/recipes-gnome/gtk+/gtk-icon-utils-native_3.22.29.bb
+++ b/meta/recipes-gnome/gtk+/gtk-icon-utils-native_3.22.30.bb
@@ -10,8 +10,8 @@ MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
 
 SRC_URI = 
"http://ftp.gnome.org/pub/gnome/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar.xz \
   file://Remove-Gdk-dependency-from-gtk-encode-symbolic-svg.patch"
-SRC_URI[md5sum] = "229a39f7d9ada53398baa39652630f2e"
-SRC_URI[sha256sum] = 
"a07d64b939fcc034a066b7723fdf9b24e92c9cfb6a8497593f3471fe56fbbbf8"
+SRC_URI[md5sum] = "61e60dc073e0a6893c72043d20579dc0"
+SRC_URI[sha256sum] = 
"a1a4a5c12703d4e1ccda28333b87ff462741dc365131fbc94c218ae81d9a6567"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2 \
 
file://gtk/gtk.h;endline=25;md5=1d8dc0fccdbfa26287a271dce88af737 \
-- 
2.4.0

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

[OE-core] [PATCH 08/12] vte: upgrade to 0.52.2

[Maxin B. John]

0.52.0 -> 0.52.2

Signed-off-by: Maxin B. John 
---
 meta/recipes-support/vte/{vte_0.52.0.bb => vte_0.52.2.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/vte/{vte_0.52.0.bb => vte_0.52.2.bb} (91%)

diff --git a/meta/recipes-support/vte/vte_0.52.0.bb 
b/meta/recipes-support/vte/vte_0.52.2.bb
similarity index 91%
rename from meta/recipes-support/vte/vte_0.52.0.bb
rename to meta/recipes-support/vte/vte_0.52.2.bb
index 254d64e..7324c9c 100644
--- a/meta/recipes-support/vte/vte_0.52.0.bb
+++ b/meta/recipes-support/vte/vte_0.52.2.bb
@@ -11,8 +11,8 @@ inherit gnomebase gtk-doc distro_features_check 
upstream-version-is-even gobject
 SRC_URI += "file://0001-Don-t-enable-stack-protection-by-default.patch \
 ${@bb.utils.contains('PACKAGECONFIG', 'vala', '', 
'file://0001-Add-m4-vapigen.m4.patch', d) } \
 "
-SRC_URI[archive.md5sum] = "95b0d12864f7374128da33998e756e75"
-SRC_URI[archive.sha256sum] = 
"d5ae7257af493afa10ca2a290f284e588021b0bd863dbb75de7c0567"
+SRC_URI[archive.md5sum] = "de8181350dccb010e915e366bdd06d18"
+SRC_URI[archive.sha256sum] = 
"0f2657cef52accbfe56feede55312d7c1984b1291838af3cb8cfc19b26af"
 
 ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
 
-- 
2.4.0

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

[OE-core] [PATCH 07/12] libunistring: upgrade to 0.9.10

[Maxin B. John]

License-Update: Checksum changed due to updation in documentation. There
are no changes in the license terms.

Signed-off-by: Maxin B. John 
---
 .../libunistring/{libunistring_0.9.9.bb => libunistring_0.9.10.bb}  | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-support/libunistring/{libunistring_0.9.9.bb => 
libunistring_0.9.10.bb} (85%)

diff --git a/meta/recipes-support/libunistring/libunistring_0.9.9.bb 
b/meta/recipes-support/libunistring/libunistring_0.9.10.bb
similarity index 85%
rename from meta/recipes-support/libunistring/libunistring_0.9.9.bb
rename to meta/recipes-support/libunistring/libunistring_0.9.10.bb
index ab7cba5..97fac4e 100644
--- a/meta/recipes-support/libunistring/libunistring_0.9.9.bb
+++ b/meta/recipes-support/libunistring/libunistring_0.9.10.bb
@@ -16,15 +16,15 @@ SECTION = "devel"
 LICENSE = "LGPLv3+ | GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=6a6a8e020838b23406c81b19c1d46df6 \
 
file://README;beginline=45;endline=65;md5=08287d16ba8d839faed8d2dc14d7d6a5 \
-
file://doc/libunistring.texi;md5=efb80a3799a60f95feaf80661d4f204c \
+
file://doc/libunistring.texi;md5=287fa6075f78a3c85c1a52b0a92547cd \
"
 
 SRC_URI = "${GNU_MIRROR}/libunistring/libunistring-${PV}.tar.gz \
file://iconv-m4-remove-the-test-to-convert-euc-jp.patch \
file://0001-Unset-need_charset_alias-when-building-for-musl.patch \
 "
-SRC_URI[md5sum] = "4f689e37e4c3bd67de5786aa51d98b13"
-SRC_URI[sha256sum] = 
"f5e90c08f9e5427ca3a2c0c53f19aa38b25c500913510ad25afef86448bea84a"
+SRC_URI[md5sum] = "0d3274e9838396b12200f8b54ddaf43b"
+SRC_URI[sha256sum] = 
"a82e5b39a88ea4608e4635479a1cfb2e01aafb925e1290b65710d43f610b"
 
 inherit autotools texinfo
 BBCLASSEXTEND = "native nativesdk"
-- 
2.4.0

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

[OE-core] [PATCH 04/12] cronie: upgrade to 1.5.2

[Maxin B. John]

1.5.1 -> 1.5.2

Signed-off-by: Maxin B. John 
---
 meta/recipes-extended/cronie/{cronie_1.5.1.bb => cronie_1.5.2.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/cronie/{cronie_1.5.1.bb => cronie_1.5.2.bb} (95%)

diff --git a/meta/recipes-extended/cronie/cronie_1.5.1.bb 
b/meta/recipes-extended/cronie/cronie_1.5.2.bb
similarity index 95%
rename from meta/recipes-extended/cronie/cronie_1.5.1.bb
rename to meta/recipes-extended/cronie/cronie_1.5.2.bb
index cfb8c21..3abca7f 100644
--- a/meta/recipes-extended/cronie/cronie_1.5.1.bb
+++ b/meta/recipes-extended/cronie/cronie_1.5.2.bb
@@ -25,8 +25,8 @@ SRC_URI = 
"https://github.com/cronie-crond/cronie/releases/download/cronie-${PV}
 PAM_SRC_URI = "file://crond_pam_config.patch"
 PAM_DEPS = "libpam libpam-runtime pam-plugin-access pam-plugin-loginuid"
 
-SRC_URI[md5sum] = "910e6effcc032998b0a49fbd46322e18"
-SRC_URI[sha256sum] = 
"6c73666102a6b5d35e2eaf1bd06925f2d4b0cef8d3323c37286dda3089a85338"
+SRC_URI[md5sum] = "703314f58a49ea136e9966d3937d9bf4"
+SRC_URI[sha256sum] = 
"370bf34641691489330e708bd4cdbd779267296a030668a12f77b7e36872fd75"
 
 inherit autotools update-rc.d useradd systemd
 
-- 
2.4.0

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

[OE-core] [PATCH 06/12] gtk+3: upgrade to 3.22.30

[Maxin B. John]

3.22.29 -> 3.22.30

Signed-off-by: Maxin B. John 
---
 meta/recipes-gnome/gtk+/{gtk+3_3.22.29.bb => gtk+3_3.22.30.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-gnome/gtk+/{gtk+3_3.22.29.bb => gtk+3_3.22.30.bb} (83%)

diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.22.29.bb 
b/meta/recipes-gnome/gtk+/gtk+3_3.22.30.bb
similarity index 83%
rename from meta/recipes-gnome/gtk+/gtk+3_3.22.29.bb
rename to meta/recipes-gnome/gtk+/gtk+3_3.22.30.bb
index c3c786b..697b518 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.22.29.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.22.30.bb
@@ -7,8 +7,8 @@ SRC_URI = 
"http://ftp.gnome.org/pub/gnome/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar
file://0002-Do-not-try-to-initialize-GL-without-libGL.patch \
file://0003-Add-disable-opengl-configure-option.patch \
   "
-SRC_URI[md5sum] = "229a39f7d9ada53398baa39652630f2e"
-SRC_URI[sha256sum] = 
"a07d64b939fcc034a066b7723fdf9b24e92c9cfb6a8497593f3471fe56fbbbf8"
+SRC_URI[md5sum] = "61e60dc073e0a6893c72043d20579dc0"
+SRC_URI[sha256sum] = 
"a1a4a5c12703d4e1ccda28333b87ff462741dc365131fbc94c218ae81d9a6567"
 
 S = "${WORKDIR}/gtk+-${PV}"
 
-- 
2.4.0

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

[OE-core] [PATCH 02/12] libinput: upgrade to 1.11.0

[Maxin B. John]

1.9.4 -> 1.11.0

Signed-off-by: Maxin B. John 
---
 .../wayland/{libinput_1.9.4.bb => libinput_1.11.0.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/wayland/{libinput_1.9.4.bb => libinput_1.11.0.bb} 
(86%)

diff --git a/meta/recipes-graphics/wayland/libinput_1.9.4.bb 
b/meta/recipes-graphics/wayland/libinput_1.11.0.bb
similarity index 86%
rename from meta/recipes-graphics/wayland/libinput_1.9.4.bb
rename to meta/recipes-graphics/wayland/libinput_1.11.0.bb
index 67a49df..97264ca 100644
--- a/meta/recipes-graphics/wayland/libinput_1.9.4.bb
+++ b/meta/recipes-graphics/wayland/libinput_1.11.0.bb
@@ -9,8 +9,8 @@ DEPENDS = "libevdev udev mtdev"
 
 SRC_URI = "http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz \
"
-SRC_URI[md5sum] = "8b43d07d1698fb207a0492fc67554d4f"
-SRC_URI[sha256sum] = 
"0bcdbd4c4e3c2a2db322fbdf2ef3284f2e6d6fb7be3af80e6d8de7783f675190"
+SRC_URI[md5sum] = "a182dab52f4d33bc1ef50668dcf53cc6"
+SRC_URI[sha256sum] = 
"64a36c4f826f4b5d473bf2cb803122f96390a18243ec810f2ce8ac5076a0bc12"
 
 UPSTREAM_CHECK_REGEX = "libinput-(?P\d+\.\d+\.(?!9\d+)\d+)"
 inherit meson pkgconfig lib_package
-- 
2.4.0

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

[OE-core] [PATCH 01/12] acpid: upgrade to 2.0.29

[Maxin B. John]

2.0.28 -> 2.0.29

Signed-off-by: Maxin B. John 
---
 meta/recipes-bsp/acpid/{acpid_2.0.28.bb => acpid_2.0.29.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-bsp/acpid/{acpid_2.0.28.bb => acpid_2.0.29.bb} (55%)

diff --git a/meta/recipes-bsp/acpid/acpid_2.0.28.bb 
b/meta/recipes-bsp/acpid/acpid_2.0.29.bb
similarity index 55%
rename from meta/recipes-bsp/acpid/acpid_2.0.28.bb
rename to meta/recipes-bsp/acpid/acpid_2.0.29.bb
index 686526f..9258486 100644
--- a/meta/recipes-bsp/acpid/acpid_2.0.28.bb
+++ b/meta/recipes-bsp/acpid/acpid_2.0.29.bb
@@ -3,5 +3,5 @@ require acpid.inc
 LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
 
file://acpid.h;endline=24;md5=324a9cf225ae69ddaad1bf9d942115b5"
 
-SRC_URI[md5sum] = "0432407b5ff75ae8e08afb43052fde2b"
-SRC_URI[sha256sum] = 
"980c3a54b0d3f2fd49fd845a0584c5c2abeaab9e9ac09fcbb68686bbb57a7110"
+SRC_URI[md5sum] = "6dd58a35cac51bd9503d769f5d13d74d"
+SRC_URI[sha256sum] = 
"58503b27975c466e627eb741c5453dd662f97edef1a3d0aac822fd03a84203ff"
-- 
2.4.0

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

[OE-core] [PATCH 03/12] libsoup-2.4: upgrade to 2.62.2

[Maxin B. John]

2.62.0 -> 2.62.2

Signed-off-by: Maxin B. John 
---
 .../libsoup/{libsoup-2.4_2.62.0.bb => libsoup-2.4_2.62.2.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/libsoup/{libsoup-2.4_2.62.0.bb => 
libsoup-2.4_2.62.2.bb} (89%)

diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.62.0.bb 
b/meta/recipes-support/libsoup/libsoup-2.4_2.62.2.bb
similarity index 89%
rename from meta/recipes-support/libsoup/libsoup-2.4_2.62.0.bb
rename to meta/recipes-support/libsoup/libsoup-2.4_2.62.2.bb
index 5c9dd19..a9f3554 100644
--- a/meta/recipes-support/libsoup/libsoup-2.4_2.62.0.bb
+++ b/meta/recipes-support/libsoup/libsoup-2.4_2.62.2.bb
@@ -11,8 +11,8 @@ SHRT_VER = 
"${@d.getVar('PV').split('.')[0]}.${@d.getVar('PV').split('.')[1]}"
 
 SRC_URI = "${GNOME_MIRROR}/libsoup/${SHRT_VER}/libsoup-${PV}.tar.xz"
 
-SRC_URI[md5sum] = "750b6f6136e5fdd82ac07f60b4aea575"
-SRC_URI[sha256sum] = 
"ab7c7ae8d19d0a27ab3b6ae21599cec8c7f7b773b3f2b1090c5daf178373aaac"
+SRC_URI[md5sum] = "eaf99b04ac8968ed2b26f2509ba75584"
+SRC_URI[sha256sum] = 
"9e536fe3da60b25d2c63addb84a9d5072d00b0d8b8cbeabc629a6bcd63f879b6"
 
 S = "${WORKDIR}/libsoup-${PV}"
 
-- 
2.4.0

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

[OE-core] [PATCH] mesa: fix build on musl

[Ross Burton]

Signed-off-by: Ross Burton 
---
 .../mesa/files/missing-time-h.patch| 29 ++
 meta/recipes-graphics/mesa/mesa_18.1.1.bb  |  1 +
 2 files changed, 30 insertions(+)
 create mode 100644 meta/recipes-graphics/mesa/files/missing-time-h.patch

diff --git a/meta/recipes-graphics/mesa/files/missing-time-h.patch 
b/meta/recipes-graphics/mesa/files/missing-time-h.patch
new file mode 100644
index 000..5a4dcd9c4da
--- /dev/null
+++ b/meta/recipes-graphics/mesa/files/missing-time-h.patch
@@ -0,0 +1,29 @@
+Upstream-Status: Submitted 
[https://lists.freedesktop.org/archives/mesa-dev/2018-June/197438.html]
+Signed-off-by: Ross Burton 
+
+From a138d929be540eee246f8aa6d64e8b6d23922f1b Mon Sep 17 00:00:00 2001
+From: Ross Burton 
+Date: Tue, 12 Jun 2018 11:57:58 +0100
+Subject: [PATCH] drivers/dri/i965: add missing #include
+
+brw_bufmgr.h uses time_t without include time.h, so the build fails under musl.
+---
+ src/mesa/drivers/dri/i965/brw_bufmgr.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h 
b/src/mesa/drivers/dri/i965/brw_bufmgr.h
+index 68f5e0c2c8..5c2702652b 100644
+--- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
 b/src/mesa/drivers/dri/i965/brw_bufmgr.h
+@@ -37,6 +37,8 @@
+ #include 
+ #include 
+ #include 
++#include 
++
+ #include "util/u_atomic.h"
+ #include "util/list.h"
+ 
+-- 
+2.11.0
+
diff --git a/meta/recipes-graphics/mesa/mesa_18.1.1.bb 
b/meta/recipes-graphics/mesa/mesa_18.1.1.bb
index 7aeb28bda36..d9feb334e54 100644
--- a/meta/recipes-graphics/mesa/mesa_18.1.1.bb
+++ b/meta/recipes-graphics/mesa/mesa_18.1.1.bb
@@ -7,6 +7,7 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0004-hardware-gloat.patch \

file://0005-Properly-get-LLVM-version-when-using-LLVM-Git-releas.patch \
file://0006-Use-Python-3-to-execute-the-scripts.patch \
+   file://missing-time-h.patch \
 "
 
 SRC_URI[md5sum] = "063468c930ff61d211ece0191874fa95"
-- 
2.11.0

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

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Herve Jourdain]

Hi,

I believe I'm the "original author" of some patch attempt at tackling this 
problem, more than a year ago, as referenced in this series.
And I understand why everyone, Khem being the first and not the only one, would 
like some "simpler" things for ARM.
But the problem is that ARM-based SoCs are very diverse, and ARM does have a 
number of optional IP blocks (such as crypto, but neon is another one, and 
there are others), defined for each architecture. Then ARM defines some 
"standard" SoCs (like cortex-A53, cortex-A57, ...) which may set some of those 
optional IPs as required for that SoC, and the rest still as optional.
And SoC vendors decide what optional IPs they will implement or not...

So when we're talking "cortex-A53", it's not necessarily the same cortex-A53 
for all SoC vendors.

GCC does support all that complexity. So the main question is, do we want to be 
able to generate code that could take advantage of the optional IPs present on 
a SoC? Or do we prefer to settle for the least common denominator?
As someone who is close to the SoC, I definitely would prefer to be able to 
take advantage of the optional IPs present on an ARM SoC, and I'd rather have a 
system that can at least support that even if it's slightly more complex. This 
said, once it's done, most people won't look under the hood but just use it, so 
the complexity would end up being hidden - much like now with armv7.

I've personally followed up on my patches from last year, and I now have a 
slightly modified/simplified version of them, which I've used to build some 
production-ready environments using cortex-a53/armv8 tunes, that trigger the 
optimization for cortex-a53 + neon. And if the SoC I'm working with had the 
crypto extension, I would be very happy to build for it, by just switching the 
tune I use for my cortex-a53 to the armv8 tune supporting crypto.

So I believe now may be a good time to talk this over again, because we're 
basically building for cortex-a53 with cortexa7/armv7ve, and that is not the 
most optimal thing to do in my opinion (like, some instructions that were 
native in armv7ve are simulated in armv8).

One thing that I did come up as a simplification was the handling of thumb, I 
don't think it needs to be an option anymore, since its support is mandatory in 
armv8 (but I think it was also the case in armv7). That simplifies things a 
bit, but nothing fundamental, you still need to carry the support for the 
optional IPs around...
And in addition to what I proposed to support last year, we indeed now have to 
add armv8.1a, armv8.2a, armv8.3a, armv8.4a (so far...), which each have their 
own specificities/differences that make it unlikely to be supported within a 
single file.

Thoughts? Can we talk this over, so we can have a chance to have a good support 
for armv8-32 in oe, instead of everyone doing its own?

Cheers,
Herve

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Koen Kooi
Sent: mardi 12 juin 2018 11:01
To: Randy Li 
Cc: OE-core 
Subject: Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex 
processors



> Op 9 jun. 2018, om 08:26 heeft Randy Li  het volgende 
> geschreven:
> 
> I read the ARMv8 manual again, it looks the hardware float is 
> mandatory in Linux Distributions and toolchain libraries. Even some 
> cortex processors can be configured without FPU/NEON hardware, but I 
> don't think they would be used in openembeded core.
> 
> So I can assume the NEON(SIMD) would exist all the time. Leaving only 
> the crc and crypto instructions are optional here.
> 
> 
> Randy Li (4):
>  arch-armv8a.inc: add tune include for armv8
>  tune-cortexa35: add tunes for ARM Cortex-A35
>  tune-cortexa32: add tunes for ARM Cortex-A32
>  tune-cortexa72: add tunes for ARM Cortex-A72

Having been forced to deal with the mess that’s 32-bit arm tunes: Let’s only 
add an implementation specific tunes *after* having seem conclusive, repeatable 
benchmark results. 90% of the 32 bit tune files are placebo effect and just 
explode number of package archs in your distro feed. The goal of aarch64 was to 
stop being different for the sake of being different, let’s not make a mess 
because we are used to messes.

regards,

Koen
--
___
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] busybox: remove myself as maintainer.

[Burton, Ross]

I spoke to Andrej earlier and he has agreed, the patch to change
ownership is on the list now.

Thanks Armin for being the maintainer, and thanks Andrej for taking over!

Ross

On 12 June 2018 at 10:32, Alexander Kanavin  wrote:
> I would nominate Andrej Valek  :-)
>
> Being listed in maintainers.inc is indeed not an obligation to fix
> other people's specific issues or work on recipe enhancements in
> general. Maintainers are expected to act on AUH version upgrade
> emails, and look at filed bugs; neither is time consuming.
>
> Alex
>
>
> 2018-06-12 1:17 GMT+03:00 Burton, Ross :
>> They get the AUH upgrade mails, and will be the default assignee for
>> bugs in triage.
>>
>> For something like busybox this isn't a huge amount of work.
>>
>> Ross
>>
>> On 11 June 2018 at 23:13, Andre McCurdy  wrote:
>>> On Mon, Jun 11, 2018 at 3:06 PM, Burton, Ross  wrote:
 Do we have anyone willing to take over?
>>>
>>> Does having a designated maintainer actually achieve anything in practice?
>>>
 Ross

 On 11 June 2018 at 23:03, Armin Kuster  wrote:
> Signed-off-by: Armin Kuster 
> ---
>  meta/conf/distro/include/maintainers.inc | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/meta/conf/distro/include/maintainers.inc 
> b/meta/conf/distro/include/maintainers.inc
> index 628edac..08d7e1b 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -85,7 +85,6 @@ RECIPE_MAINTAINER_pn-build-compare = "Randy Witt 
> "
>  RECIPE_MAINTAINER_pn-build-sysroots = "Richard Purdie 
> "
>  RECIPE_MAINTAINER_pn-builder = "Richard Purdie 
> "
>  RECIPE_MAINTAINER_pn-buildtools-tarball = "Richard Purdie 
> "
> -RECIPE_MAINTAINER_pn-busybox = "Armin Kuster "
>  RECIPE_MAINTAINER_pn-busybox-inittab = "Denys Dmytriyenko "
>  RECIPE_MAINTAINER_pn-bzip2 = "Denys Dmytriyenko "
>  RECIPE_MAINTAINER_pn-ca-certificates = "Alexander Kanavin 
> "
> --
> 2.7.4
>
> --
> ___
> 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
>> --
>> ___
>> 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] maintainers: add Andrej Valek as busybox maintain

[Ross Burton]

Andrej has kindly stepped up as the busybox maintainer.

Signed-off-by: Ross Burton 
---
 meta/conf/distro/include/maintainers.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 4939c79c9eb..bacdc0b9a29 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -85,6 +85,7 @@ RECIPE_MAINTAINER_pn-build-compare = "Randy Witt 
"
 RECIPE_MAINTAINER_pn-build-sysroots = "Richard Purdie 
"
 RECIPE_MAINTAINER_pn-builder = "Richard Purdie 
"
 RECIPE_MAINTAINER_pn-buildtools-tarball = "Richard Purdie 
"
+RECIPE_MAINTAINER_pn-busybox = "Andrej Valek "
 RECIPE_MAINTAINER_pn-busybox-inittab = "Denys Dmytriyenko "
 RECIPE_MAINTAINER_pn-bzip2 = "Denys Dmytriyenko "
 RECIPE_MAINTAINER_pn-ca-certificates = "Alexander Kanavin 
"
-- 
2.11.0

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

Re: [OE-core] [PATCH] busybox: remove myself as maintainer.

[Alexander Kanavin]

I would nominate Andrej Valek  :-)

Being listed in maintainers.inc is indeed not an obligation to fix
other people's specific issues or work on recipe enhancements in
general. Maintainers are expected to act on AUH version upgrade
emails, and look at filed bugs; neither is time consuming.

Alex


2018-06-12 1:17 GMT+03:00 Burton, Ross :
> They get the AUH upgrade mails, and will be the default assignee for
> bugs in triage.
>
> For something like busybox this isn't a huge amount of work.
>
> Ross
>
> On 11 June 2018 at 23:13, Andre McCurdy  wrote:
>> On Mon, Jun 11, 2018 at 3:06 PM, Burton, Ross  wrote:
>>> Do we have anyone willing to take over?
>>
>> Does having a designated maintainer actually achieve anything in practice?
>>
>>> Ross
>>>
>>> On 11 June 2018 at 23:03, Armin Kuster  wrote:
 Signed-off-by: Armin Kuster 
 ---
  meta/conf/distro/include/maintainers.inc | 1 -
  1 file changed, 1 deletion(-)

 diff --git a/meta/conf/distro/include/maintainers.inc 
 b/meta/conf/distro/include/maintainers.inc
 index 628edac..08d7e1b 100644
 --- a/meta/conf/distro/include/maintainers.inc
 +++ b/meta/conf/distro/include/maintainers.inc
 @@ -85,7 +85,6 @@ RECIPE_MAINTAINER_pn-build-compare = "Randy Witt 
 "
  RECIPE_MAINTAINER_pn-build-sysroots = "Richard Purdie 
 "
  RECIPE_MAINTAINER_pn-builder = "Richard Purdie 
 "
  RECIPE_MAINTAINER_pn-buildtools-tarball = "Richard Purdie 
 "
 -RECIPE_MAINTAINER_pn-busybox = "Armin Kuster "
  RECIPE_MAINTAINER_pn-busybox-inittab = "Denys Dmytriyenko "
  RECIPE_MAINTAINER_pn-bzip2 = "Denys Dmytriyenko "
  RECIPE_MAINTAINER_pn-ca-certificates = "Alexander Kanavin 
 "
 --
 2.7.4

 --
 ___
 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
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V3 0/1] oeqa/runtime/cases/selftest.py: rename to _selftest.py

[Chen Qi]

Changes in V3:
* Also rename selftest.json to _selftest.json to avoid runtime_test.py failure 
in oe-selftest.
* Fixed a typo (sato -> full-cmdline)

Changes in V2:
* Fix to depend on _selftest.Selftest.test_install_package.


The following changes since commit fe6e6231441188c3ffe52ef5811a8f30d29ea952:

  local.conf.sample: update libsdl mentions to libsdl2 (2018-06-07 08:53:19 
+0100)

are available in the git repository at:

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

Chen Qi (1):
  oeqa/runtime/cases/selftest.py: rename to _selftest.py

 .../lib/oeqa/runtime/cases/{selftest.json => _selftest.json}  | 0
 meta-selftest/lib/oeqa/runtime/cases/{selftest.py => _selftest.py}| 2 +-
 meta/lib/oeqa/selftest/cases/runtime_test.py  | 4 ++--
 3 files changed, 3 insertions(+), 3 deletions(-)
 rename meta-selftest/lib/oeqa/runtime/cases/{selftest.json => _selftest.json} 
(100%)
 rename meta-selftest/lib/oeqa/runtime/cases/{selftest.py => _selftest.py} (94%)

-- 
1.9.1

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

[OE-core] [PATCH 1/1] oeqa/runtime/cases/selftest.py: rename to _selftest.py

[Chen Qi]

This test modules is designed to be invoked only by selftest. It's
not meant to be tested by normal runtime test. So it should be renamed
with '_' prefix, so that it will not be automatically loaded by normal
runtime tests when 'auto' is in TEST_SUITES.

The failure message is as below.

  RESULTS - selftest.Selftest.test_install_package - Testcase -1: FAILED

Change selftest/cases/runtime_test.py to use '_selftest' accordingly.
Rename selftest.json to _selftest.json accordingly.
Also, fix a typo in runtime_test.py.

Signed-off-by: Chen Qi 
---
 .../lib/oeqa/runtime/cases/{selftest.json => _selftest.json}  | 0
 meta-selftest/lib/oeqa/runtime/cases/{selftest.py => _selftest.py}| 2 +-
 meta/lib/oeqa/selftest/cases/runtime_test.py  | 4 ++--
 3 files changed, 3 insertions(+), 3 deletions(-)
 rename meta-selftest/lib/oeqa/runtime/cases/{selftest.json => _selftest.json} 
(100%)
 rename meta-selftest/lib/oeqa/runtime/cases/{selftest.py => _selftest.py} (94%)

diff --git a/meta-selftest/lib/oeqa/runtime/cases/selftest.json 
b/meta-selftest/lib/oeqa/runtime/cases/_selftest.json
similarity index 100%
rename from meta-selftest/lib/oeqa/runtime/cases/selftest.json
rename to meta-selftest/lib/oeqa/runtime/cases/_selftest.json
diff --git a/meta-selftest/lib/oeqa/runtime/cases/selftest.py 
b/meta-selftest/lib/oeqa/runtime/cases/_selftest.py
similarity index 94%
rename from meta-selftest/lib/oeqa/runtime/cases/selftest.py
rename to meta-selftest/lib/oeqa/runtime/cases/_selftest.py
index 19de740..e6c05ef 100644
--- a/meta-selftest/lib/oeqa/runtime/cases/selftest.py
+++ b/meta-selftest/lib/oeqa/runtime/cases/_selftest.py
@@ -17,7 +17,7 @@ class Selftest(OERuntimeTestCase):
 (status, output) = self.target.run("socat -V")
 self.assertEqual(status, 0, msg="socat is not installed")
 
-@OETestDepends(['selftest.Selftest.test_install_package'])
+@OETestDepends(['_selftest.Selftest.test_install_package'])
 def test_verify_uninstall(self):
 """
 Summary: Check basic package installation functionality.
diff --git a/meta/lib/oeqa/selftest/cases/runtime_test.py 
b/meta/lib/oeqa/selftest/cases/runtime_test.py
index 30fd9b2..3bd0ca6 100644
--- a/meta/lib/oeqa/selftest/cases/runtime_test.py
+++ b/meta/lib/oeqa/selftest/cases/runtime_test.py
@@ -122,10 +122,10 @@ class TestImage(OESelftestTestCase):
 self.skipTest('core-image-full-cmdline not buildable for 
poky-tiny')
 
 features = 'INHERIT += "testimage"\n'
-features += 'TEST_SUITES = "ping ssh selftest"\n'
+features += 'TEST_SUITES = "ping ssh _selftest"\n'
 self.write_config(features)
 
-# Build core-image-sato and testimage
+# Build core-image-full-cmdline and testimage
 bitbake('core-image-full-cmdline socat')
 bitbake('-c testimage core-image-full-cmdline')
 
-- 
1.9.1

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

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Koen Kooi]

> Op 9 jun. 2018, om 08:26 heeft Randy Li  het volgende 
> geschreven:
> 
> I read the ARMv8 manual again, it looks the hardware float is mandatory
> in Linux Distributions and toolchain libraries. Even some cortex
> processors can be configured without FPU/NEON hardware, but I don't
> think they would be used in openembeded core.
> 
> So I can assume the NEON(SIMD) would exist all the time. Leaving only the
> crc and crypto instructions are optional here.
> 
> 
> Randy Li (4):
>  arch-armv8a.inc: add tune include for armv8
>  tune-cortexa35: add tunes for ARM Cortex-A35
>  tune-cortexa32: add tunes for ARM Cortex-A32
>  tune-cortexa72: add tunes for ARM Cortex-A72

Having been forced to deal with the mess that’s 32-bit arm tunes: Let’s only 
add an implementation specific tunes *after* having seem conclusive, repeatable 
benchmark results. 90% of the 32 bit tune files are placebo effect and just 
explode number of package archs in your distro feed. The goal of aarch64 was to 
stop being different for the sake of being different, let’s not make a mess 
because we are used to messes.

regards,

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

[OE-core] [PATCH 1/1] send-error-report: decode response from server

[Robert Yang]

Fixed:
b'Your entry can be found here: http://'

Now looks like:
Your entry can be found here: http://

Signed-off-by: Robert Yang 
---
 scripts/send-error-report | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/send-error-report b/scripts/send-error-report
index 15b5e84..cd2e7f4 100755
--- a/scripts/send-error-report
+++ b/scripts/send-error-report
@@ -143,7 +143,7 @@ def send_data(data, args):
 logging.error(e.reason)
 sys.exit(1)
 
-print(response.read())
+print(response.read().decode('utf-8'))
 
 
 if __name__ == '__main__':
-- 
2.7.4

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

[OE-core] [PATCH 0/1] send-error-report: decode response from server

[Robert Yang]

The following changes since commit 23f15c63777020f5d43b070a1eb2bcf246c19ff8:

  rpm: Fix patch to ensure variables aren't used uninitialised (2018-06-07 
08:52:13 +0100)

are available in the git repository at:

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

Robert Yang (1):
  send-error-report: decode response from server

 scripts/send-error-report | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.7.4

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

[OE-core] [PATCH v3] ltp: fix cve-2017-5669 test case

[Naresh Kamboju]

Adding cve-2017-5669 test fix patch which is accepted upstream in LTP repo.

Ref:
cve-2017-5669: shmat() for 0 (or https://github.com/linux-test-project/ltp/pull/324

Upstream-Status: Accepted [https://github.com/linux-test-project/ltp/pull/324]
CVE: cve-2017-5669
Signed-off-by: Naresh Kamboju 
---
 ...69-shmat-for-0-or-PAGESIZE-with-RND-flag-.patch | 97 ++
 meta/recipes-extended/ltp/ltp_20180515.bb  |  1 +
 2 files changed, 98 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0041-cve-2017-5669-shmat-for-0-or-PAGESIZE-with-RND-flag-.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0041-cve-2017-5669-shmat-for-0-or-PAGESIZE-with-RND-flag-.patch
 
b/meta/recipes-extended/ltp/ltp/0041-cve-2017-5669-shmat-for-0-or-PAGESIZE-with-RND-flag-.patch
new file mode 100644
index 000..2a47785
--- /dev/null
+++ 
b/meta/recipes-extended/ltp/ltp/0041-cve-2017-5669-shmat-for-0-or-PAGESIZE-with-RND-flag-.patch
@@ -0,0 +1,97 @@
+From b767b73ef027ba8d35f297c7d3659265ac80425b Mon Sep 17 00:00:00 2001
+From: Rafael David Tinoco 
+Date: Wed, 30 May 2018 09:14:34 -0300
+Subject: [PATCH] cve-2017-5669: shmat() for 0 (or https://github.com/linux-test-project/ltp/issues/319
+
+According to upstream thread (https://lkml.org/lkml/2018/5/28/2056),
+cve-2017-5669 needs to address the "new" way of handling nil addresses
+for shmat() when used with MAP_FIXED or SHM_REMAP flags.
+
+- mapping nil-page is OK on lower addresses with MAP_FIXED (or else X11 is 
broken)
+- mapping nil-page is NOT OK with SHM_REMAP on lower addresses
+
+Addresses Davidlohr Bueso's comments/changes:
+
+commit 8f89c007b6de
+Author: Davidlohr Bueso 
+Date:   Fri May 25 14:47:30 2018 -0700
+
+ipc/shm: fix shmat() nil address after round-down when remapping
+
+commit a73ab244f0da
+Author: Davidlohr Bueso 
+Date:   Fri May 25 14:47:27 2018 -0700
+
+Revert "ipc/shm: Fix shmat mmap nil-page protection"
+
+For previously test, and now broken, made based on:
+
+commit 95e91b831f87
+Author: Davidlohr Bueso 
+Date:   Mon Feb 27 14:28:24 2017 -0800
+
+ipc/shm: Fix shmat mmap nil-page protection
+
+Signed-off-by: Rafael David Tinoco 
+Tested-by: Naresh Kamboju 
+Reviewed-by: Jan Stancek 
+
+Upstream-Status: Accepted [https://github.com/linux-test-project/ltp/pull/324]
+CVE: cve-2017-5669
+Signed-off-by: Rafael David Tinoco 
+---
+ testcases/cve/cve-2017-5669.c | 20 +++-
+ 1 file changed, 19 insertions(+), 1 deletion(-)
+
+diff --git a/testcases/cve/cve-2017-5669.c b/testcases/cve/cve-2017-5669.c
+index 1ca5983..0834626 100644
+--- a/testcases/cve/cve-2017-5669.c
 b/testcases/cve/cve-2017-5669.c
+@@ -28,7 +28,20 @@
+  * is just to see if we get an access error or some other unexpected 
behaviour.
+  *
+  * See commit 95e91b831f (ipc/shm: Fix shmat mmap nil-page protection)
++ *
++ * The commit above disallowed SHM_RND maps to zero (and rounded) entirely and
++ * that broke userland for cases like Xorg. New behavior disallows REMAPs to
++ * lower addresses (0<=PAGESIZE).
++ *
++ * See commit a73ab244f0da (Revert "ipc/shm: Fix shmat mmap nil-page 
protect...)
++ * See commit 8f89c007b6de (ipc/shm: fix shmat() nil address after 
round-dow...)
++ * See https://github.com/linux-test-project/ltp/issues/319
++ *
++ * This test needs root permissions or else security_mmap_addr(), from
++ * get_unmapped_area(), will cause permission errors when trying to mmap lower
++ * addresses.
+  */
++
+ #include 
+ #include 
+ #include 
+@@ -60,7 +73,11 @@ static void cleanup(void)
+ static void run(void)
+ {
+   tst_res(TINFO, "Attempting to attach shared memory to null page");
+-  shm_addr = shmat(shm_id, ((void *)1), SHM_RND);
++  /*
++   * shmat() for 0 (or < PAGESIZE with RND flag) has to fail with REMAPs
++   * https://github.com/linux-test-project/ltp/issues/319
++   */
++  shm_addr = shmat(shm_id, ((void *)1), SHM_RND | SHM_REMAP);
+   if (shm_addr == (void *)-1) {
+   shm_addr = NULL;
+   if (errno == EINVAL) {
+@@ -89,6 +106,7 @@ static void run(void)
+ }
+ 
+ static struct tst_test test = {
++  .needs_root = 1,
+   .setup = setup,
+   .cleanup = cleanup,
+   .test_all = run,
+-- 
+2.7.4
+
diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb 
b/meta/recipes-extended/ltp/ltp_20180515.bb
index b07c1b9..48739f1 100644
--- a/meta/recipes-extended/ltp/ltp_20180515.bb
+++ b/meta/recipes-extended/ltp/ltp_20180515.bb
@@ -41,6 +41,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \

file://0036-testcases-network-nfsv4-acl-acl1.c-Security-fix-on-s.patch \
file://0039-commands-ar01-Fix-for-test-in-deterministic-mode.patch \

file://0040-read_all-Define-FNM_EXTMATCH-if-not-already-like-und.patch \
+   
file://0041-cve-2017-5669-shmat-for-0-or-PAGESIZE-with-RND-flag-.patch \
"
 
 S = "${WORKDIR}/git"
-- 
2.7.4

-- 
___
Openembedded-core 

Re: [OE-core] [PATCH v2 1/4] arch-armv8a.inc: add tune include for armv8

[Nicolas Dechesne]

On Sat, Jun 9, 2018 at 8:26 AM, Randy Li  wrote:
> There are some addtional instructions apart from bare armv8,
> also there is armv8.1, armv8.2.
>
> Most the processor would support crc, except X-gene 1.

the commit message doesn't really explain what is going on in this patch..

>
> Signed-off-by: Randy Li 
> ---
>  meta/conf/machine/include/arm/arch-armv8.inc  |  1 -
>  meta/conf/machine/include/arm/arch-armv8a.inc | 22 ++
>  2 files changed, 22 insertions(+), 1 deletion(-)
>  delete mode 100644 meta/conf/machine/include/arm/arch-armv8.inc
^^ this file is used by probably any armv8 machine out there, even
inside oe-core:

$ git grep "arch-armv8\.inc"
include/tune-thunderx.inc:require conf/machine/include/arm/arch-armv8.inc
qemuarm64.conf:require conf/machine/include/arm/arch-armv8.inc

so this change would break many things. and it's used in many BSP layers.

>  create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc
>
> diff --git a/meta/conf/machine/include/arm/arch-armv8.inc 
> b/meta/conf/machine/include/arm/arch-armv8.inc
> deleted file mode 100644
> index 5e832fae6d..00
> --- a/meta/conf/machine/include/arm/arch-armv8.inc
> +++ /dev/null
> @@ -1 +0,0 @@
> -require conf/machine/include/arm/arch-arm64.inc
> diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc 
> b/meta/conf/machine/include/arm/arch-armv8a.inc
> new file mode 100644
> index 00..b8b9e44c54
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv8a.inc
> @@ -0,0 +1,22 @@
> +DEFAULTTUNE ?= "armv8a-crc"

even without taking into consideration that this is changing all
default configs for arm64.. which should for sure be discussed and
agreed upon... the crc and crypto flags you are adding here, are not
defined anywhere.

please review how the armv7 variants were designed/introduced, and try
to mimic that for armv8 if you think it's needed.

> +
> +TUNEVALID[armv8] = "Enable instructions for ARMv8-a"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', ' 
> -march=armv8-a', '', d)}"
> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', 
> 'armv8a:', '' ,d)}"
> +
> +require conf/machine/include/arm/arch-arm64.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "armv8a armv8a-crc armv8a-crc-crypto armv8a-crypto"
> +ARMPKGARCH_tune-armv8a?= "armv8a"
> +ARMPKGARCH_tune-armv8a-crc?= "armv8a"
> +ARMPKGARCH_tune-armv8a-crypto ?= "armv8a"
> +ARMPKGARCH_tune-armv8a-crc-crypto ?= "armv8a"
> +TUNE_FEATURES_tune-armv8a  = "armv8a simd"
> +TUNE_FEATURES_tune-armv8a-crc  = "${ARMPKGARCH_tune-armv8a} crc"
> +TUNE_FEATURES_tune-armv8a-crypto   = "${TUNE_FEATURES_tune-armv8a} 
> crypto"
> +TUNE_FEATURES_tune-armv8a-crc-crypto   = 
> "${TUNE_FEATURES_tune-armv8a-crc} crypto"
> +PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a simd"
> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crc= 
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
> --
> 2.14.3
>
> --
> ___
> 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