Re: [OE-core] [PATCH] linux-yocto: enable strict kernel module signing by default

[Jack Mitchell]

On 27/11/2022 03:34, Bruce Ashfield wrote:

On Fri, Nov 25, 2022 at 11:11 AM Jack Mitchell  wrote:


On 25/11/2022 15:54, Mikko Rapeli wrote:

It's a good default and used in many Linux distributions.
Did not test out of tree modules if they do correct things but
any such failures should be fixed.

One way to verify that kernel module signing also works:

root@qemux86-64:~# dmesg|grep X.509
[1.298936] Loading compiled-in X.509 certificates
[1.328280] Loaded X.509 cert 'Build time autogenerated kernel key: 
ee1bed6d845358744c764683bf73b4404cc79287'

These logs in dmesg show that signing in kernel is enabled and
key is found. Then if any kernel modules load, they were
signed correctly. Additionally modinfo tool from kmod shows kernel module
signing details:


Hi Mikko,

Do the kernel modules get properly stripped, last time I was looking at
this it was skipped when signed and as such root filesystem sizes
ballooned with signed modules.


oe package.py still does skip stripping for signed modules.

I'm sure it is fixable, but we need someone to step up and have a closer look.

Richard can probably comment better than I can, but there's a variety
of use cases (from SDKs, to debug, to SBOM, etc) that all need to deal
with whether binaries are stripped and be able to find the
non-stripped executables in order to work properly.

So to answer the follow up suggestion of using the kernel's module
strip directly .. it also might be feasible, but we need to make sure
that all the other uses cases still work. My preference is to do the
work in package.py, so that we don't have to worry about the kernel
provider and any additional features have code in the same place as a
baseline.



I agree, if the kernel has the right arguments available for properly 
stripping the modules without stripping the signed portion then we can 
set those args manually rather than skipping the strip all together I 
believe.


I also had the same thought with having the kernel do it as I don't know 
where the stripped information goes and how that would then make it into 
debug packages.



Bruce



Regards,
Jack.



root@qemux86-64:~# lsmod
Module  Size  Used by
sch_fq_codel   20480  1
root@qemux86-64:~# modinfo sch_fq_codel
filename:
/lib/modules/5.19.9-yocto-standard/kernel/net/sched/sch_fq_codel.ko
description:Fair Queue CoDel discipline
license:GPL
author: Eric Dumazet
depends:
retpoline:  Y
intree: Y
name:   sch_fq_codel
vermagic:   5.19.9-yocto-standard SMP preempt mod_unload
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key:2B:2A:BE:7D:B5:92:DC:98:A9:F8:D7:00:A6:73:35:20:10:D8:19:EE
sig_hashalgo:   sha512
signature:  72:6C:E1:78:7C:A7:7B:CC:C4:33:23:6B:95:EC:1B:2A:BD:D9:EC:7A:
 85:07:05:B2:70:3C:C9:64:F6:78:8A:01:A0:E3:64:C7:47:BB:5D:0E:
 86:BA:C1:DD:40:05:AE:1F:19:D4:F0:98:49:86:CC:61:14:3C:AB:1E:
 4A:1C:83:47:1D:FA:6D:E4:83:79:3A:2B:3F:7D:B6:E0:09:AE:B4:01:
 07:EE:C9:5B:99:70:4F:49:8A:64:E4:7D:84:AA:37:F5:DB:5F:16:5C:
 D4:DC:0C:33:73:5D:D9:8D:7E:71:5B:A1:ED:61:81:5E:1C:ED:A2:D8:
 76:46:99:B3:78:08:F7:7F:0D:4B:94:26:21:63:47:B0:75:9F:A4:EA:
 3D:14:D4:09:CC:59:F3:FC:80:AC:BF:56:1E:8C:73:FD:CB:07:27:C6:
 3D:98:4C:E4:C3:9C:C0:AD:90:53:46:8F:AE:66:FE:10:C8:92:7F:BA:
 74:C2:B0:E3:6E:47:66:AB:39:25:41:12:66:91:20:27:1A:58:77:75:
 4F:C0:3F:F1:8E:5F:AB:0A:BD:8B:62:4F:2B:01:5A:5C:4E:5C:31:39:
 FB:F4:14:2E:BF:D8:51:4B:C8:D0:E2:0A:20:80:95:05:80:E3:46:75:
 43:80:30:63:6F:A4:25:82:59:35:34:E8:6A:DC:FF:93:F8:32:BB:FA:
 66:2D:B9:08:75:1A:3A:3A:5D:57:F4:63:85:01:B4:EB:96:1B:CE:6F:
 4D:61:FC:AA:6C:39:7F:D6:37:C9:84:0A:84:17:FB:BE:FC:20:CB:EE:
 8C:2F:93:92:F6:48:F4:07:50:84:D8:2C:B5:2E:A7:7D:3A:3F:DC:E9:
 B9:17:EF:47:49:EC:BA:62:1C:C4:C6:58:9C:0C:8D:26:41:6E:1F:C1:
 95:A7:8B:57:5D:1D:4B:B4:04:00:F6:68:24:9E:E2:BF:11:EC:05:6C:
 83:E8:C6:DB:BB:3D:22:8B:31:BB:99:1A:44:E1:15:71:C3:AA:FA:01:
 98:BA:6B:20:26:D6:9C:61:5C:6F:81:29:09:B1:EA:C5:28:15:F3:98:
 C0:18:FE:08:8B:40:A5:F3:3C:71:4B:C6:41:CD:38:51:79:EA:5D:C9:
 13:39:B5:FD:A3:D1:BB:11:94:66:F7:7B:6A:DC:2C:01:5F:AB:73:08:
 68:24:32:BE:BC:7A:90:E5:FD:97:17:6C:DD:46:D0:0E:2C:03:31:66:
 B3:7C:B2:48:E1:E0:1A:63:20:48:4C:D4:55:56:71:04:3B:5F:3B:28:
 BF:64:6C:52:A9:07:6D:FF:21:E9:06:35:E8:A1:D7:F4:C2:F9:D7:7B:
 9D:D2:90:16:2F:68:1E:3F:BE:43:ED:64

Failures in signed kernel module loading should show as errors at
runtime, for example systemd services, or as oeqa parselogs test
failures which detects signature verification error messages from the
kernel.

Signed-off-by: Mikko Rapeli 
---
  meta

Re: [OE-core] [PATCH] linux-yocto: enable strict kernel module signing by default

[Jack Mitchell]

On 25/11/2022 15:54, Mikko Rapeli wrote:
> It's a good default and used in many Linux distributions.
> Did not test out of tree modules if they do correct things but
> any such failures should be fixed.
> 
> One way to verify that kernel module signing also works:
> 
> root@qemux86-64:~# dmesg|grep X.509
> [1.298936] Loading compiled-in X.509 certificates
> [1.328280] Loaded X.509 cert 'Build time autogenerated kernel key: 
> ee1bed6d845358744c764683bf73b4404cc79287'
> 
> These logs in dmesg show that signing in kernel is enabled and
> key is found. Then if any kernel modules load, they were
> signed correctly. Additionally modinfo tool from kmod shows kernel module
> signing details:

Hi Mikko,

Do the kernel modules get properly stripped, last time I was looking at
this it was skipped when signed and as such root filesystem sizes
ballooned with signed modules.

Regards,
Jack.

> 
> root@qemux86-64:~# lsmod
> Module  Size  Used by
> sch_fq_codel   20480  1
> root@qemux86-64:~# modinfo sch_fq_codel
> filename:
> /lib/modules/5.19.9-yocto-standard/kernel/net/sched/sch_fq_codel.ko
> description:Fair Queue CoDel discipline
> license:GPL
> author: Eric Dumazet
> depends:
> retpoline:  Y
> intree: Y
> name:   sch_fq_codel
> vermagic:   5.19.9-yocto-standard SMP preempt mod_unload
> sig_id: PKCS#7
> signer: Build time autogenerated kernel key
> sig_key:2B:2A:BE:7D:B5:92:DC:98:A9:F8:D7:00:A6:73:35:20:10:D8:19:EE
> sig_hashalgo:   sha512
> signature:  72:6C:E1:78:7C:A7:7B:CC:C4:33:23:6B:95:EC:1B:2A:BD:D9:EC:7A:
> 85:07:05:B2:70:3C:C9:64:F6:78:8A:01:A0:E3:64:C7:47:BB:5D:0E:
> 86:BA:C1:DD:40:05:AE:1F:19:D4:F0:98:49:86:CC:61:14:3C:AB:1E:
> 4A:1C:83:47:1D:FA:6D:E4:83:79:3A:2B:3F:7D:B6:E0:09:AE:B4:01:
> 07:EE:C9:5B:99:70:4F:49:8A:64:E4:7D:84:AA:37:F5:DB:5F:16:5C:
> D4:DC:0C:33:73:5D:D9:8D:7E:71:5B:A1:ED:61:81:5E:1C:ED:A2:D8:
> 76:46:99:B3:78:08:F7:7F:0D:4B:94:26:21:63:47:B0:75:9F:A4:EA:
> 3D:14:D4:09:CC:59:F3:FC:80:AC:BF:56:1E:8C:73:FD:CB:07:27:C6:
> 3D:98:4C:E4:C3:9C:C0:AD:90:53:46:8F:AE:66:FE:10:C8:92:7F:BA:
> 74:C2:B0:E3:6E:47:66:AB:39:25:41:12:66:91:20:27:1A:58:77:75:
> 4F:C0:3F:F1:8E:5F:AB:0A:BD:8B:62:4F:2B:01:5A:5C:4E:5C:31:39:
> FB:F4:14:2E:BF:D8:51:4B:C8:D0:E2:0A:20:80:95:05:80:E3:46:75:
> 43:80:30:63:6F:A4:25:82:59:35:34:E8:6A:DC:FF:93:F8:32:BB:FA:
> 66:2D:B9:08:75:1A:3A:3A:5D:57:F4:63:85:01:B4:EB:96:1B:CE:6F:
> 4D:61:FC:AA:6C:39:7F:D6:37:C9:84:0A:84:17:FB:BE:FC:20:CB:EE:
> 8C:2F:93:92:F6:48:F4:07:50:84:D8:2C:B5:2E:A7:7D:3A:3F:DC:E9:
> B9:17:EF:47:49:EC:BA:62:1C:C4:C6:58:9C:0C:8D:26:41:6E:1F:C1:
> 95:A7:8B:57:5D:1D:4B:B4:04:00:F6:68:24:9E:E2:BF:11:EC:05:6C:
> 83:E8:C6:DB:BB:3D:22:8B:31:BB:99:1A:44:E1:15:71:C3:AA:FA:01:
> 98:BA:6B:20:26:D6:9C:61:5C:6F:81:29:09:B1:EA:C5:28:15:F3:98:
> C0:18:FE:08:8B:40:A5:F3:3C:71:4B:C6:41:CD:38:51:79:EA:5D:C9:
> 13:39:B5:FD:A3:D1:BB:11:94:66:F7:7B:6A:DC:2C:01:5F:AB:73:08:
> 68:24:32:BE:BC:7A:90:E5:FD:97:17:6C:DD:46:D0:0E:2C:03:31:66:
> B3:7C:B2:48:E1:E0:1A:63:20:48:4C:D4:55:56:71:04:3B:5F:3B:28:
> BF:64:6C:52:A9:07:6D:FF:21:E9:06:35:E8:A1:D7:F4:C2:F9:D7:7B:
> 9D:D2:90:16:2F:68:1E:3F:BE:43:ED:64
> 
> Failures in signed kernel module loading should show as errors at
> runtime, for example systemd services, or as oeqa parselogs test
> failures which detects signature verification error messages from the
> kernel.
> 
> Signed-off-by: Mikko Rapeli 
> ---
>  meta/recipes-kernel/linux/linux-yocto.inc | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc 
> b/meta/recipes-kernel/linux/linux-yocto.inc
> index 091003ed82..bab1f21479 100644
> --- a/meta/recipes-kernel/linux/linux-yocto.inc
> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> @@ -37,6 +37,9 @@ KERNEL_FEATURES:append = " 
> ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/
>  KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa', 
> 'features/numa/numa.scc', '', d)}"
>  KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat', 
> 'cfg/fs/vfat.scc', '', d)}"
>  
> +# enable module signing by default
> +KERNEL_FEATURES:append = " features/module-signing/force-signing.scc"
> +
>  # A KMACHINE is the mapping of a yocto $MACHINE to what is built
>

[OE-core] [PATCH] meson.bbclass: add cython binary to cross/native toolchain config

[Jack Mitchell]

This allows building Cython based Python modules with the native
meson support which has been present since meson version 0.59.

https://mesonbuild.com/Cython.html

Signed-off-by: Jack Mitchell 
---
 meta/classes/meson.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index b265e6659f..546cd0476f 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -59,6 +59,7 @@ do_write_config() {
 [binaries]
 c = ${@meson_array('CC', d)}
 cpp = ${@meson_array('CXX', d)}
+cython = 'cython3'
 ar = ${@meson_array('AR', d)}
 nm = ${@meson_array('NM', d)}
 strip = ${@meson_array('STRIP', d)}
@@ -98,6 +99,7 @@ EOF
 [binaries]
 c = ${@meson_array('BUILD_CC', d)}
 cpp = ${@meson_array('BUILD_CXX', d)}
+cython = 'cython3'
 ar = ${@meson_array('BUILD_AR', d)}
 nm = ${@meson_array('BUILD_NM', d)}
 strip = ${@meson_array('BUILD_STRIP', d)}
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#166781): 
https://lists.openembedded.org/g/openembedded-core/message/166781
Mute This Topic: https://lists.openembedded.org/mt/91646286/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] rng-tools: disable the CPU affinity mask

[Jack Mitchell]

On 10/05/2021 10:48, Richard Purdie wrote:
> On Mon, 2021-05-10 at 10:33 +0800, Yu, Mingli wrote:
>> From: Mingli Yu 
>>
>> For the jitter entropy source, each task thread will create an internal
>> counter timer thread when the system clock resolution is under 5MHz.
>>
>> But it will introduce high cpu usage for a long time and also make random
>> data generate too slow if sets the CPU affinity mask of the internal counter
>> timer thread.
>>
>> There is no solution until now and the Upstream recommends to disable
>> the internal timer and think Jitter RNG will not work due to the coarse
>> timer. Check [1] and [2] for more details.
>>
>> So disable the CPU affinity mask as a workaround to avoid lots of context
>> switch and too high cpu load for a long time.
>>
>> [1] https://github.com/smuellerDD/jitterentropy-library/issues/37
>> [2] https://github.com/nhorman/rng-tools/pull/123
>>
>> Signed-off-by: Mingli Yu 
>> ---
>>  ...tter.c-disable-the-CPU-affinity-mask.patch | 48 +++
>>  .../rng-tools/rng-tools_6.11.bb   |  1 +
>>  2 files changed, 49 insertions(+)
>>  create mode 100644 
>> meta/recipes-support/rng-tools/rng-tools/0001-rngd_jitter.c-disable-the-CPU-affinity-mask.patch
> 
> Thanks for investigating this upstream. From an OE-Core perspective, I've very
> reluctant to take what looks like a very board specific change which the 
> upstream
> is advising against. The issue is that this will affect all hardware, not just
> the hardware which has the issue. I think we need to find a better solution.
> 
> Cheers,
> 
> Richard
> 

FWIW I forcefully have to ensure nothing pulls in rng-tools in my builds
which are for two different Rockchip chipsets (armv7 and armv8) as the
rng-tools binary pegs the CPU at 100% for minutes after boot, every
boot. It's particularly annoying as openssh brings it in by default
which I've unsuccessfully argued is wrong before. I believe the problem
is probably fairly widespread but just unnoticed.

Regards,

-- 
Jack Mitchell, Consultant
https://www.tuxable.co.uk

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151530): 
https://lists.openembedded.org/g/openembedded-core/message/151530
Mute This Topic: https://lists.openembedded.org/mt/82711446/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] distutils3: allow setup.py to be run from a different directory to ${S}

[Jack Mitchell]

Sometimes setup.py can be buried deep in a source tree. This has
traditionally been solved with setting S to the subdirectory in
the source. However with the new pseudo changes, some python modules
make changes to files beneath ${S}, for example:

S = "${WORKDIR}/git/python/pythonmodule"

then in setup.py it works with source code in a relative fashion, such
as:

../../src

This causes pseudo to abort as it isn't tracking the paths. Therefore
implement the variable DISTUTILS_SETUP_PATH so that recipes can use:

S = "${WORKDIR}/git"
DISTUTILS_SETUP_PATH = "${S}/python/pythonmodule"

inherit distutils3

This allows the full source tree to be monitored, while distutils
can run setup.py from a location other than ${S}.

Signed-off-by: Jack Mitchell 
---
 meta/classes/distutils3.bbclass | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
index 7356b5245a..a916a8000c 100644
--- a/meta/classes/distutils3.bbclass
+++ b/meta/classes/distutils3.bbclass
@@ -12,28 +12,30 @@ DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
 DISTUTILS_PYTHON = "python3"
 DISTUTILS_PYTHON_class-native = "nativepython3"
 
+DISTUTILS_SETUP_PATH ?= "${S}"
+
 distutils3_do_configure() {
 :
 }
 
 distutils3_do_compile() {
-cd ${S}
+cd ${DISTUTILS_SETUP_PATH}
 NO_FETCH_BUILD=1 \
 STAGING_INCDIR=${STAGING_INCDIR} \
 STAGING_LIBDIR=${STAGING_LIBDIR} \
-${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} 
${S}/setup.py \
+${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py \
 build --build-base=${B} ${DISTUTILS_BUILD_ARGS} || \
 bbfatal_log "'${PYTHON_PN} setup.py build ${DISTUTILS_BUILD_ARGS}' 
execution failed."
 }
 distutils3_do_compile[vardepsexclude] = "MACHINE"
 
 distutils3_do_install() {
-cd ${S}
+cd ${DISTUTILS_SETUP_PATH}
 install -d ${D}${PYTHON_SITEPACKAGES_DIR}
 STAGING_INCDIR=${STAGING_INCDIR} \
 STAGING_LIBDIR=${STAGING_LIBDIR} \
 PYTHONPATH=${D}${PYTHON_SITEPACKAGES_DIR} \
-${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} 
${S}/setup.py \
+${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py \
 build --build-base=${B} install --skip-build ${DISTUTILS_INSTALL_ARGS} 
|| \
 bbfatal_log "'${PYTHON_PN} setup.py install ${DISTUTILS_INSTALL_ARGS}' 
execution failed."
 
-- 
2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145401): 
https://lists.openembedded.org/g/openembedded-core/message/145401
Mute This Topic: https://lists.openembedded.org/mt/78806546/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 3/3] systemd-conf: match ethernet interfaces by type rather than globbing

[Jack Mitchell]

If we say we're enabling DHCP on wired/ethernet networks lets be more
specific than trying to catch everything with globbing.

Signed-off-by: Jack Mitchell 
---
 meta/recipes-core/systemd/systemd-conf/wired.network | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd-conf/wired.network 
b/meta/recipes-core/systemd/systemd-conf/wired.network
index dcf3534596..09367edb10 100644
--- a/meta/recipes-core/systemd/systemd-conf/wired.network
+++ b/meta/recipes-core/systemd/systemd-conf/wired.network
@@ -1,5 +1,5 @@
 [Match]
-Name=en* eth*
+Type=ether
 KernelCommandLine=!nfsroot
 
 [Network]
-- 
2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145193): 
https://lists.openembedded.org/g/openembedded-core/message/145193
Mute This Topic: https://lists.openembedded.org/mt/78681668/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/3] systemd-conf: add PACKAGECONFIG to enable/disable auto ethernet DHCP

[Jack Mitchell]

Allow distros which include other network managers to disable the
auto DHCP setup of interfaces in systemd-networkd.

Signed-off-by: Jack Mitchell 
---
 meta/recipes-core/systemd/systemd-conf_246.1.bb | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd-conf_246.1.bb 
b/meta/recipes-core/systemd/systemd-conf_246.1.bb
index d9ec023bfd..944b56ff82 100644
--- a/meta/recipes-core/systemd/systemd-conf_246.1.bb
+++ b/meta/recipes-core/systemd/systemd-conf_246.1.bb
@@ -5,6 +5,9 @@ DefaultTimeoutStartSec setting."
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 
+PACKAGECONFIG ??= "dhcp-ethernet"
+PACKAGECONFIG[dhcp-ethernet] = ""
+
 SRC_URI = "\
 file://journald.conf \
 file://logind.conf \
@@ -17,7 +20,10 @@ do_install() {
install -D -m0644 ${WORKDIR}/journald.conf 
${D}${systemd_unitdir}/journald.conf.d/00-${PN}.conf
install -D -m0644 ${WORKDIR}/logind.conf 
${D}${systemd_unitdir}/logind.conf.d/00-${PN}.conf
install -D -m0644 ${WORKDIR}/system.conf 
${D}${systemd_unitdir}/system.conf.d/00-${PN}.conf
-   install -D -m0644 ${WORKDIR}/wired.network 
${D}${systemd_unitdir}/network/80-wired.network
+
+if ${@bb.utils.contains('PACKAGECONFIG', 'dhcp-ethernet', 'true', 
'false', d)}; then
+   install -D -m0644 ${WORKDIR}/wired.network 
${D}${systemd_unitdir}/network/80-wired.network
+fi
 }
 
 # Based on change from YP bug 8141, OE commit 
5196d7bacaef1076c361adaa2867be31759c1b52
-- 
2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145192): 
https://lists.openembedded.org/g/openembedded-core/message/145192
Mute This Topic: https://lists.openembedded.org/mt/78681665/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/3] Revert "connman: set service to conflict with systemd-networkd"

[Jack Mitchell]

Without further examples of how this is failing revert as using both
together is a valid use case, for example connman handling Wifi/AP
and systemd-networkd handling more complex routing such as for
containers and ethernet switches.

This reverts commit 5303420ead25817f5caec276b79eec7ee797271a.

Signed-off-by: Jack Mitchell 
---
 ...stop-systemd-networkd-when-using-con.patch | 29 ---
 .../connman/connman_1.38.bb   |  1 -
 2 files changed, 30 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch

diff --git 
a/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
 
b/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
deleted file mode 100644
index dd012750a4..00
--- 
a/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From 9fea099d0a3ece37d80ad70d32ebb8a93f8f3280 Mon Sep 17 00:00:00 2001
-From: Yi Zhao 
-Date: Fri, 30 Oct 2020 13:48:45 +0800
-Subject: [PATCH] connman.service: stop systemd-networkd when using connman
-
-Stop systemd-networkd service when we use connman as network manager.
-
-Upstream-Status: Inappropriate [configuration]
-
-Signed-off-by: Yi Zhao 

- src/connman.service.in | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/src/connman.service.in b/src/connman.service.in
-index 79e75d6..014eafe 100644
 a/src/connman.service.in
-+++ b/src/connman.service.in
-@@ -6,6 +6,7 @@ RequiresMountsFor=@localstatedir@/lib/connman
- After=dbus.service network-pre.target systemd-sysusers.service
- Before=network.target multi-user.target shutdown.target
- Wants=network.target
-+Conflicts=systemd-networkd.service systemd-networkd.socket
- Conflicts=systemd-resolved.service
- 
- [Service]
--- 
-2.17.1
-
diff --git a/meta/recipes-connectivity/connman/connman_1.38.bb 
b/meta/recipes-connectivity/connman/connman_1.38.bb
index 45c2934dec..027c41e9af 100644
--- a/meta/recipes-connectivity/connman/connman_1.38.bb
+++ b/meta/recipes-connectivity/connman/connman_1.38.bb
@@ -3,7 +3,6 @@ require connman.inc
 SRC_URI = "${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \

file://0001-plugin.h-Change-visibility-to-default-for-debug-symb.patch \

file://0001-connman.service-stop-systemd-resolved-when-we-use-co.patch \
-   
file://0001-connman.service-stop-systemd-networkd-when-using-con.patch \
file://connman \
file://no-version-scripts.patch \
"
-- 
2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145191): 
https://lists.openembedded.org/g/openembedded-core/message/145191
Mute This Topic: https://lists.openembedded.org/mt/78681664/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 2/2] connman: set service to conflict with systemd-networkd

[Jack Mitchell]

On 02/12/2020 02:20, Yi Zhao wrote:
> 
> On 12/1/20 5:02 AM, Jack Mitchell wrote:
>> On 02/11/2020 09:20, Yi Zhao wrote:
>>> Do not run systemd-networkd and connman simultaneously. These two
>>> network managers may conflict with each other.
>>>
>>> Signed-off-by: Yi Zhao 
>>> ---
>>>  ...stop-systemd-networkd-when-using-con.patch | 29 +++
>>>  .../connman/connman_1.38.bb   |  1 +
>>>  2 files changed, 30 insertions(+)
>>>  create mode 100644 
>>> meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
>>>
>>> diff --git 
>>> a/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
>>>  
>>> b/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
>>> new file mode 100644
>>> index 00..dd012750a4
>>> --- /dev/null
>>> +++ 
>>> b/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
>>> @@ -0,0 +1,29 @@
>>> +From 9fea099d0a3ece37d80ad70d32ebb8a93f8f3280 Mon Sep 17 00:00:00 2001
>>> +From: Yi Zhao 
>>> +Date: Fri, 30 Oct 2020 13:48:45 +0800
>>> +Subject: [PATCH] connman.service: stop systemd-networkd when using connman
>>> +
>>> +Stop systemd-networkd service when we use connman as network manager.
>>> +
>>> +Upstream-Status: Inappropriate [configuration]
>>> +
>>> +Signed-off-by: Yi Zhao 
>>> +---
>>> + src/connman.service.in | 1 +
>>> + 1 file changed, 1 insertion(+)
>>> +
>>> +diff --git a/src/connman.service.in b/src/connman.service.in
>>> +index 79e75d6..014eafe 100644
>>> +--- a/src/connman.service.in
>>>  b/src/connman.service.in
>>> +@@ -6,6 +6,7 @@ RequiresMountsFor=@localstatedir@/lib/connman
>>> + After=dbus.service network-pre.target systemd-sysusers.service
>>> + Before=network.target multi-user.target shutdown.target
>>> + Wants=network.target
>>> ++Conflicts=systemd-networkd.service systemd-networkd.socket
>>> + Conflicts=systemd-resolved.service
>>> + 
>>> + [Service]
>>> +-- 
>>> +2.17.1
>>> +
>>> diff --git a/meta/recipes-connectivity/connman/connman_1.38.bb 
>>> b/meta/recipes-connectivity/connman/connman_1.38.bb
>>> index 027c41e9af..45c2934dec 100644
>>> --- a/meta/recipes-connectivity/connman/connman_1.38.bb
>>> +++ b/meta/recipes-connectivity/connman/connman_1.38.bb
>>> @@ -3,6 +3,7 @@ require connman.inc
>>>  SRC_URI = "${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
>>> 
>>> file://0001-plugin.h-Change-visibility-to-default-for-debug-symb.patch \
>>> 
>>> file://0001-connman.service-stop-systemd-resolved-when-we-use-co.patch \
>>> +   
>>> file://0001-connman.service-stop-systemd-networkd-when-using-con.patch \
>>> file://connman \
>>> file://no-version-scripts.patch \
>>> "
>>>
>> Hi Yi,
>>
>> This breaks our usecase where we have been using connman and
>> systemd-networkd in tandem for a long time. IMO this should be reverted
>> as if the two applications are conflicting then the correct fix is that
>> they should be configured so that they don't both try to configure the
>> same interfaces. As systemd-networkd doesn't ship with any rules by
>> default it shouldn't be doing anything to interfere?
> 
> 
> Currently, A systemd-networkd configuration file 80-wired.network from
> systemd-conf package is also installed by default on HW BSPs. Comman is
> the default network-manager in Yocto. It will manage the wired interface
> automatically. But with this configuration file, the systemd-networkd
> will also try to manage the wired interface as connman does. They may
> conflict with each other.In addition to revert this patch, I think we
> should consider whether to install this configuration file by default.
> Maybe it’s better to install it as an example and users can enable it as
> needed.
> 
> Thanks,
> Yi
> 


Hi Yi,

I see, thank you for pointing that out. I agree that we shouldn't be
shipping custom catch-all networkd snippets. Perhaps it should be
something appended by the Poky distro rather than installed by default?
I assume it is included so that network interfaces come up with a DHCP
address by default so people can ssh into the machine without an extra
config.

Cc kai.k...@windriver.com as it looks like they were the original author.

Regards,
Jack.

> 
>> With this patch I can no-longer run both services as it's a hard
>> conflict with no option to either revert locally, or bbappend this patch
>> out.
>>
>> Regards,
>> Jack.
>>
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145175): 
https://lists.openembedded.org/g/openembedded-core/message/145175
Mute This Topic: https://lists.openembedded.org/mt/77977444/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] Revert "connman: set service to conflict with systemd-networkd"

[Jack Mitchell]

Without further examples of how this is failing revert as using both
together is a valid use case, for example connman handling Wifi/AP
and systemd-networkd handling more complex routing such as for
containers and ethernet switches.

This reverts commit 5303420ead25817f5caec276b79eec7ee797271a.
---
 ...stop-systemd-networkd-when-using-con.patch | 29 ---
 .../connman/connman_1.38.bb   |  1 -
 2 files changed, 30 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch

diff --git 
a/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
 
b/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
deleted file mode 100644
index dd012750a4..00
--- 
a/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From 9fea099d0a3ece37d80ad70d32ebb8a93f8f3280 Mon Sep 17 00:00:00 2001
-From: Yi Zhao 
-Date: Fri, 30 Oct 2020 13:48:45 +0800
-Subject: [PATCH] connman.service: stop systemd-networkd when using connman
-
-Stop systemd-networkd service when we use connman as network manager.
-
-Upstream-Status: Inappropriate [configuration]
-
-Signed-off-by: Yi Zhao 

- src/connman.service.in | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/src/connman.service.in b/src/connman.service.in
-index 79e75d6..014eafe 100644
 a/src/connman.service.in
-+++ b/src/connman.service.in
-@@ -6,6 +6,7 @@ RequiresMountsFor=@localstatedir@/lib/connman
- After=dbus.service network-pre.target systemd-sysusers.service
- Before=network.target multi-user.target shutdown.target
- Wants=network.target
-+Conflicts=systemd-networkd.service systemd-networkd.socket
- Conflicts=systemd-resolved.service
- 
- [Service]
--- 
-2.17.1
-
diff --git a/meta/recipes-connectivity/connman/connman_1.38.bb 
b/meta/recipes-connectivity/connman/connman_1.38.bb
index 45c2934dec..027c41e9af 100644
--- a/meta/recipes-connectivity/connman/connman_1.38.bb
+++ b/meta/recipes-connectivity/connman/connman_1.38.bb
@@ -3,7 +3,6 @@ require connman.inc
 SRC_URI = "${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \

file://0001-plugin.h-Change-visibility-to-default-for-debug-symb.patch \

file://0001-connman.service-stop-systemd-resolved-when-we-use-co.patch \
-   
file://0001-connman.service-stop-systemd-networkd-when-using-con.patch \
file://connman \
file://no-version-scripts.patch \
"
-- 
2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145119): 
https://lists.openembedded.org/g/openembedded-core/message/145119
Mute This Topic: https://lists.openembedded.org/mt/78634667/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 2/2] connman: set service to conflict with systemd-networkd

[Jack Mitchell]

On 02/11/2020 09:20, Yi Zhao wrote:
> Do not run systemd-networkd and connman simultaneously. These two
> network managers may conflict with each other.
> 
> Signed-off-by: Yi Zhao 
> ---
>  ...stop-systemd-networkd-when-using-con.patch | 29 +++
>  .../connman/connman_1.38.bb   |  1 +
>  2 files changed, 30 insertions(+)
>  create mode 100644 
> meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
> 
> diff --git 
> a/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
>  
> b/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
> new file mode 100644
> index 00..dd012750a4
> --- /dev/null
> +++ 
> b/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
> @@ -0,0 +1,29 @@
> +From 9fea099d0a3ece37d80ad70d32ebb8a93f8f3280 Mon Sep 17 00:00:00 2001
> +From: Yi Zhao 
> +Date: Fri, 30 Oct 2020 13:48:45 +0800
> +Subject: [PATCH] connman.service: stop systemd-networkd when using connman
> +
> +Stop systemd-networkd service when we use connman as network manager.
> +
> +Upstream-Status: Inappropriate [configuration]
> +
> +Signed-off-by: Yi Zhao 
> +---
> + src/connman.service.in | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/src/connman.service.in b/src/connman.service.in
> +index 79e75d6..014eafe 100644
> +--- a/src/connman.service.in
>  b/src/connman.service.in
> +@@ -6,6 +6,7 @@ RequiresMountsFor=@localstatedir@/lib/connman
> + After=dbus.service network-pre.target systemd-sysusers.service
> + Before=network.target multi-user.target shutdown.target
> + Wants=network.target
> ++Conflicts=systemd-networkd.service systemd-networkd.socket
> + Conflicts=systemd-resolved.service
> + 
> + [Service]
> +-- 
> +2.17.1
> +
> diff --git a/meta/recipes-connectivity/connman/connman_1.38.bb 
> b/meta/recipes-connectivity/connman/connman_1.38.bb
> index 027c41e9af..45c2934dec 100644
> --- a/meta/recipes-connectivity/connman/connman_1.38.bb
> +++ b/meta/recipes-connectivity/connman/connman_1.38.bb
> @@ -3,6 +3,7 @@ require connman.inc
>  SRC_URI = "${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
> 
> file://0001-plugin.h-Change-visibility-to-default-for-debug-symb.patch \
> 
> file://0001-connman.service-stop-systemd-resolved-when-we-use-co.patch \
> +   
> file://0001-connman.service-stop-systemd-networkd-when-using-con.patch \
> file://connman \
> file://no-version-scripts.patch \
> "
> 

Hi Yi,

This breaks our usecase where we have been using connman and
systemd-networkd in tandem for a long time. IMO this should be reverted
as if the two applications are conflicting then the correct fix is that
they should be configured so that they don't both try to configure the
same interfaces. As systemd-networkd doesn't ship with any rules by
default it shouldn't be doing anything to interfere?

With this patch I can no-longer run both services as it's a hard
conflict with no option to either revert locally, or bbappend this patch
out.

Regards,
Jack.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145097): 
https://lists.openembedded.org/g/openembedded-core/message/145097
Mute This Topic: https://lists.openembedded.org/mt/77977444/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] openssh: Allow enable/disable of rng-tools recommendation on sshd

[Jack Mitchell]

On 25/09/2020 10:58, Ross Burton wrote:
> On Thu, 24 Sep 2020 at 20:58, Otavio Salvador  
> wrote:
>> We are adding a new PACKAGECONFIG option ('rng-tools') to control if we
>> wish the openssh-sshd to RRECOMMENDS the 'rng-tools' package. We are
>> enabling it by default so there is no behavior change.
> 
> Is this fundamentally because many targets now have hardware RNGs that
> the kernel is using, and so rng-tools serves no purpose?
> 
> This was originally added with data from iMX6 (oe-core
> 9b01375236e19e3366c58877c4154d7c71632984) and I'm curious if this
> followup is related to other improvements that have been made to iMX6
> since. Is there a better user space tool, or is the kernel using the
> hardware RNG out of the box?
> 

While I haven't had the time to explore the issue fully on my boards,
the issue I have specifically is that when the board is powered for a
short amount of time, systemd gets stuck on shutting down as rngd is
blocking for (I assume) a certain amount of entropy for it to enter the
ready state. Whether this is down to the specific hardware rng support
on my board, or possibly the lack of it being enabled I haven't dug into
yet.

> I ask because I'm strongly tempted to argue that we should be assuming
> that a RNG is available and let BSPs turn this on if required.
> 
> Ross
> 
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142778): 
https://lists.openembedded.org/g/openembedded-core/message/142778
Mute This Topic: https://lists.openembedded.org/mt/77065556/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] openssh: Allow enable/disable of rng-tools recommendation on sshd

[Jack Mitchell]

On 24/09/2020 20:58, Otavio Salvador wrote:
> We are adding a new PACKAGECONFIG option ('rng-tools') to control if we
> wish the openssh-sshd to RRECOMMENDS the 'rng-tools' package. We are
> enabling it by default so there is no behavior change.
> 
> Signed-off-by: Otavio Salvador 
> ---
> 
>  meta/recipes-connectivity/openssh/openssh_8.3p1.bb | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-connectivity/openssh/openssh_8.3p1.bb 
> b/meta/recipes-connectivity/openssh/openssh_8.3p1.bb
> index fad321898c..e007328704 100644
> --- a/meta/recipes-connectivity/openssh/openssh_8.3p1.bb
> +++ b/meta/recipes-connectivity/openssh/openssh_8.3p1.bb
> @@ -42,12 +42,15 @@ SYSTEMD_SERVICE_${PN}-sshd = "sshd.socket"
>  
>  inherit autotools-brokensep ptest
>  
> -PACKAGECONFIG ??= ""
> +PACKAGECONFIG ??= "rng-tools"
>  PACKAGECONFIG[kerberos] = "--with-kerberos5,--without-kerberos5,krb5"
>  PACKAGECONFIG[ldns] = "--with-ldns,--without-ldns,ldns"
>  PACKAGECONFIG[libedit] = "--with-libedit,--without-libedit,libedit"
>  PACKAGECONFIG[manpages] = "--with-mantype=man,--with-mantype=cat"
>  
> +# Add RRECOMMENDS to rng-tools for sshd package
> +PACKAGECONFIG[rng-tools] = ""
> +
>  EXTRA_AUTORECONF += "--exclude=aclocal"
>  
>  # login path is hardcoded in sshd
> @@ -149,7 +152,10 @@ FILES_${PN}-keygen = "${bindir}/ssh-keygen"
>  
>  RDEPENDS_${PN} += "${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen"
>  RDEPENDS_${PN}-sshd += "${PN}-keygen ${@bb.utils.contains('DISTRO_FEATURES', 
> 'pam', 'pam-plugin-keyinit pam-plugin-loginuid', '', d)}"
> -RRECOMMENDS_${PN}-sshd_append_class-target = " rng-tools"
> +RRECOMMENDS_${PN}-sshd_append_class-target = "\
> +${@bb.utils.filter('PACKAGECONFIG', 'rng-tools', d)} \
> +"
> +
>  # gdb would make attach-ptrace test pass rather than skip but not worth the 
> build dependencies
>  RDEPENDS_${PN}-ptest += "${PN}-sftp ${PN}-misc ${PN}-sftp-server make sed 
> sudo coreutils"
>  
> 

While rng-tools has also been causing havoc with my images as it seems
ARM soc support for whatever underlying generator it uses is spotty,
this seems to be an abuse of packageconfig. Would something like:

BAD_RECOMMENDATIONS_pn-openssh = "rng-tools"

Not perform the same function?

Regards,
Jack.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142772): 
https://lists.openembedded.org/g/openembedded-core/message/142772
Mute This Topic: https://lists.openembedded.org/mt/77065556/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Linux v5.8 modules, exec format error

[Jack Mitchell]

On 02/09/2020 13:14, Bruce Ashfield wrote:
> On Wed, Sep 2, 2020 at 3:39 AM Jack Mitchell  wrote:
>>
>>
>>
>> On 29/08/2020 20:13, Randy Witt wrote:
>>> On 8/29/20 11:41 AM, Bruce Ashfield wrote:
>>>> On Fri, Aug 28, 2020 at 10:28 PM Bruce Ashfield via
>>>> lists.openembedded.org
>>>>  wrote:
>>>>>
>>>>> On Fri, Aug 28, 2020 at 7:15 PM Jack Mitchell  wrote:
>>>>>>
>>>>>> Quick update, I just did an armv7 build with exactly the same codebase
>>>>>> and everything worked fine. Do you have an aarch64 build could test and
>>>>>> confirm working?
>>>>>
>>>>> qemuarm64 was working fine here with -rc1. I've started a new build,
>>>>> but it'll be several hours before I know more (so sometime saturday).
>>>>>
>>>
>>> I saw this on linux-modules today,
>>> https://lore.kernel.org/linux-modules/20200829100334.gk1362...@hirez.programming.kicks-ass.net/T/#t
>>> which references
>>> https://lore.kernel.org/lkml/20200808101222.51030...@coco.lan/ saying it
>>> is a bug in binutils.
>>>
>>> I haven't looked at it anymore other than seeing this email and that
>>> issue are both exec format errors on arm. I have to leave and can't
>>> investigate anymore, but figured this might be useful. If not feel free
>>> to ignore, and sorry for the noise.
>>
>> Hi Randy,
>>
>> Thanks for the heads up, this was indeed was the issue. I'm not sure why
>> it's not manifesting itself on Bruces builds. It seems to be arm64
>> specific and directly correlated to the binutils version. There is a
>> patch coming which will make it in before the release and I assume be
>> backported to v5.8 stable which is also affected.
> 
> Are you seeing that out of the latest master SRCREVs ?
> 
> It isn't just me that isn't seeing this, it is our entire autobuilder
> infrastructure, and everyone else using 5.8/ARM on master.
> 
> Cheers,
> 
> Bruce
> 

Hi Bruce,

Yes, standard mainline kernel at both the v5.8 tag and v5.9-rc2 with a
dozen or so custom patches on top covering dts/driver changes targeting
a rk3399 soc.

Build Configuration:
BB_VERSION   = "1.47.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "arch"
TARGET_SYS   = "aarch64-oe-linux"
TUNE_FEATURES= "aarch64 armv8a crc"
TARGET_FPU   = ""
meta = "master:09f4db415fb6a1398e9e9b359630043c833f6118"

and the patch which to cover it in the meantime.

commit fc439f22c8cf71689a905ff25e326b14f57bdab7
Author: Jack Mitchell 
Date:   Tue Sep 1 09:47:19 2020 +0100

TEMP: fixup aarch64 module loading with new binutils

diff --git a/arch/arm64/kernel/module-plts.c
b/arch/arm64/kernel/module-plts.c
index 0ce3a28e3347..2e224435c024 100644
--- a/arch/arm64/kernel/module-plts.c
+++ b/arch/arm64/kernel/module-plts.c
@@ -305,8 +305,7 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr,
Elf_Shdr *sechdrs,
mod->arch.core.plt_shndx = i;
else if (!strcmp(secstrings + sechdrs[i].sh_name,
".init.plt"))
mod->arch.init.plt_shndx = i;
-   else if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE) &&
-!strcmp(secstrings + sechdrs[i].sh_name,
+   else if (!strcmp(secstrings + sechdrs[i].sh_name,
 ".text.ftrace_trampoline"))
tramp = sechdrs + i;
else if (sechdrs[i].sh_type == SHT_SYMTAB)

Cheers,
Jack.

>>
>> Cheers,
>> Jack.
>>
>>>>
>>>> still working here:
>>>>
>>>> qemuarm64 login: root
>>>> root@qemuarm64:~# uname -a
>>>> Linux qemuarm64 5.9.0-rc2-yoctodev-standard #1 SMP PREEMPT Sat Aug 29
>>>> 14:26:30 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
>>>> root@qemuarm64:~# lsmod
>>>> Module  Size  Used by
>>>> sch_fq_codel   20480  1
>>>> openvswitch   155648  0
>>>> nsh16384  1 openvswitch
>>>> nf_conncount   20480  1 openvswitch
>>>> nf_nat 40960  1 openvswitch
>>>> nf_conntrack  110592  3 nf_nat,openvswitch,nf_conncount
>>>> nf_defrag_ipv6 20480  2 nf_conntrack,openvswitch
>>>> nf_defrag_ipv4 16384  1 nf_conntrack
>>>> root@qemuarm64:~#
>>>>
>>>> Bruce
>>>>
>>>>> Cheers,
>>>>>
>>&g

Re: [OE-core] Linux v5.8 modules, exec format error

[Jack Mitchell]

On 29/08/2020 20:13, Randy Witt wrote:
> On 8/29/20 11:41 AM, Bruce Ashfield wrote:
>> On Fri, Aug 28, 2020 at 10:28 PM Bruce Ashfield via
>> lists.openembedded.org
>>  wrote:
>>>
>>> On Fri, Aug 28, 2020 at 7:15 PM Jack Mitchell  wrote:
>>>>
>>>> Quick update, I just did an armv7 build with exactly the same codebase
>>>> and everything worked fine. Do you have an aarch64 build could test and
>>>> confirm working?
>>>
>>> qemuarm64 was working fine here with -rc1. I've started a new build,
>>> but it'll be several hours before I know more (so sometime saturday).
>>>
> 
> I saw this on linux-modules today,
> https://lore.kernel.org/linux-modules/20200829100334.gk1362...@hirez.programming.kicks-ass.net/T/#t
> which references
> https://lore.kernel.org/lkml/20200808101222.51030...@coco.lan/ saying it
> is a bug in binutils.
> 
> I haven't looked at it anymore other than seeing this email and that
> issue are both exec format errors on arm. I have to leave and can't
> investigate anymore, but figured this might be useful. If not feel free
> to ignore, and sorry for the noise.

Hi Randy,

Thanks for the heads up, this was indeed was the issue. I'm not sure why
it's not manifesting itself on Bruces builds. It seems to be arm64
specific and directly correlated to the binutils version. There is a
patch coming which will make it in before the release and I assume be
backported to v5.8 stable which is also affected.

Cheers,
Jack.

>>
>> still working here:
>>
>> qemuarm64 login: root
>> root@qemuarm64:~# uname -a
>> Linux qemuarm64 5.9.0-rc2-yoctodev-standard #1 SMP PREEMPT Sat Aug 29
>> 14:26:30 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
>> root@qemuarm64:~# lsmod
>> Module  Size  Used by
>> sch_fq_codel   20480  1
>> openvswitch   155648  0
>> nsh    16384  1 openvswitch
>> nf_conncount   20480  1 openvswitch
>> nf_nat 40960  1 openvswitch
>> nf_conntrack  110592  3 nf_nat,openvswitch,nf_conncount
>> nf_defrag_ipv6 20480  2 nf_conntrack,openvswitch
>> nf_defrag_ipv4 16384  1 nf_conntrack
>> root@qemuarm64:~#
>>
>> Bruce
>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>> Regards,
>>>> Jack.
>>>>
>>>> On 28/08/2020 22:35, Jack Mitchell wrote:
>>>>> Hi Bruce,
>>>>>
>>>>> All built in-tree, the same recipe builds an armv7h kernel so I'll
>>>>> try a
>>>>> build for that and see if it's something aarch64 specific. All the
>>>>> modules are failing to load so it's not something specific to g_ether.
>>>>> Please see kernel recipe below for reference.
>>>>>
>>>>> LICENSE = "GPLv2"
>>>>> LIC_FILES_CHKSUM =
>>>>> "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
>>>>>
>>>>> inherit kernel
>>>>>
>>>>> S = "${WORKDIR}/git"
>>>>>
>>>>> SRCREV = "redacted"
>>>>> KBRANCH = "v5.9-rc2"
>>>>>
>>>>> LINUX_VERSION ?= "${KBRANCH}-g${SRCREV}"
>>>>> PV = "${LINUX_VERSION}"
>>>>>
>>>>> SRC_URI = " \
>>>>>
>>>>> git://g...@github.com/redacted/linux.git;name=kernel;branch=${KBRANCH};protocol=ssh
>>>>>
>>>>> \
>>>>> "
>>>>>
>>>>> do_configure_prepend() {
>>>>>  if [ -n "${KBUILD_DEFCONFIG}" ] && [ -f
>>>>> "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" ]; then
>>>>>  oe_runmake_call -C ${S} CC="${KERNEL_CC}"
>>>>> LD="${KERNEL_LD}" O=${B} ${KBUILD_DEFCONFIG}
>>>>>  fi
>>>>> }
>>>>>
>>>>> Cheers,
>>>>> Jack.
>>>>>
>>>>> On 28/08/2020 21:55, Bruce Ashfield wrote:
>>>>>> On Fri, Aug 28, 2020 at 4:20 PM Jack Mitchell  wrote:
>>>>>>>
>>>>>>> Having just upgraded my mainline kernel recipe to a v5.8/v5.9-rc2
>>>>>>> kernel
>>>>>>> from v5.5.8 I've found that modules have somehow broken. I've
>>>>>>> flicked
>>>>>>> between the two and confirmed that the old kernel build works,
>

Re: [OE-core] Linux v5.8 modules, exec format error

[Jack Mitchell]

Quick update, I just did an armv7 build with exactly the same codebase
and everything worked fine. Do you have an aarch64 build could test and
confirm working?

Regards,
Jack.

On 28/08/2020 22:35, Jack Mitchell wrote:
> Hi Bruce,
> 
> All built in-tree, the same recipe builds an armv7h kernel so I'll try a
> build for that and see if it's something aarch64 specific. All the
> modules are failing to load so it's not something specific to g_ether.
> Please see kernel recipe below for reference.
> 
> LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
> 
> inherit kernel
> 
> S = "${WORKDIR}/git"
> 
> SRCREV = "redacted"
> KBRANCH = "v5.9-rc2"
> 
> LINUX_VERSION ?= "${KBRANCH}-g${SRCREV}"
> PV = "${LINUX_VERSION}"
> 
> SRC_URI = " \
> 
> git://g...@github.com/redacted/linux.git;name=kernel;branch=${KBRANCH};protocol=ssh
> \
> "
> 
> do_configure_prepend() {
> if [ -n "${KBUILD_DEFCONFIG}" ] && [ -f
> "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" ]; then
> oe_runmake_call -C ${S} CC="${KERNEL_CC}"
> LD="${KERNEL_LD}" O=${B} ${KBUILD_DEFCONFIG}
> fi
> }
> 
> Cheers,
> Jack.
> 
> On 28/08/2020 21:55, Bruce Ashfield wrote:
>> On Fri, Aug 28, 2020 at 4:20 PM Jack Mitchell  wrote:
>>>
>>> Having just upgraded my mainline kernel recipe to a v5.8/v5.9-rc2 kernel
>>> from v5.5.8 I've found that modules have somehow broken. I've flicked
>>> between the two and confirmed that the old kernel build works, and the
>>> 5.8/5.9 build doesn't. I haven't changed anything bar the git commit
>>> hash. It's a very simple kernel recipe basically just inheriting the
>>> kernel bbclass and setting SRCREV. Running on current tip of master.
>>>
>>> I assume it's something symver related but wanted to ask if anybody
>>> knows anything before I dig too deep.
>>
>> I can say that it is working for me on 5.8 and 5.9-rcX on the reference 
>> kernels.
>>
>> qemux86-64 login: root
>> root@qemux86-64:~# uname -a
>> Linux qemux86-64 5.8.4-yocto-standard #1 SMP PREEMPT Wed Aug 26
>> 16:07:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
>> root@qemux86-64:~# lsmod
>> Module  Size  Used by
>> parport_pc 24576
>> parport28672  1 parport_pc
>> ata_piix   36864  0
>> floppy 77824  0
>> sch_fq_codel   20480  1
>>
>> my 5.9-rc is rebuilding right now, so I can double check it over the weekend.
>>
>> Not super useful, but there shouldn't be anything fundamentally
>> broken, since we've been following along with the latest as usual.
>>
>> Is your g_ether built in-tree, or out of tree ?
>>
>> Bruce
>>
>>
>>>
>>> Cheers,
>>> Jack.
>>>
>>> root@rk3399:~# uname  -a
>>> Linux rk3399 5.9.0-rc2 #1 SMP PREEMPT Fri Aug 28 18:47:44 UTC 2020
>>> aarch64 GNU/Linux
>>>
>>> root@rk3399:~# modprobe g_ether
>>> modprobe: ERROR: could not insert 'g_ether': Exec format error
>>>
>>> root@rk3399:~# modinfo
>>> /lib/modules/5.9.0-rc2/kernel/drivers/usb/gadget/legacy/g_ether.ko
>>> filename:
>>> /lib/modules/5.9.0-rc2/kernel/drivers/usb/gadget/legacy/g_ether.ko
>>> license:GPL
>>> author: David Brownell, Benedikt Spanger
>>> description:RNDIS/Ethernet Gadget
>>> depends:libcomposite,u_ether,usb_f_rndis
>>> intree: Y
>>> name:   g_ether
>>> vermagic:   5.9.0-rc2 SMP preempt mod_unload aarch64
>>> parm:   idVendor:USB Vendor ID (ushort)
>>> parm:   idProduct:USB Product ID (ushort)
>>> parm:   bcdDevice:USB Device version (BCD) (ushort)
>>> parm:   iSerialNumber:SerialNumber string (charp)
>>> parm:   iManufacturer:USB Manufacturer string (charp)
>>> parm:   iProduct:USB Product string (charp)
>>> parm:   qmult:queue length multiplier at high/super speed (uint)
>>> parm:   dev_addr:Device Ethernet Address (charp)
>>> parm:   host_addr:Host Ethernet Address (charp)
>>> parm:   use_eem:use CDC EEM mode (bool)
>>>
>>> [jack@arch-corsair ~]$ file g_ether.ko
>>> g_ether.ko: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV),
>>> BuildID[sha1]=375c0485cb8c4b013dc0694725457bd111899f8c, not stripped
>>>
>>
>>
> 
> 
> 
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141940): 
https://lists.openembedded.org/g/openembedded-core/message/141940
Mute This Topic: https://lists.openembedded.org/mt/76482555/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Linux v5.8 modules, exec format error

[Jack Mitchell]

Hi Bruce,

All built in-tree, the same recipe builds an armv7h kernel so I'll try a
build for that and see if it's something aarch64 specific. All the
modules are failing to load so it's not something specific to g_ether.
Please see kernel recipe below for reference.

LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"

inherit kernel

S = "${WORKDIR}/git"

SRCREV = "redacted"
KBRANCH = "v5.9-rc2"

LINUX_VERSION ?= "${KBRANCH}-g${SRCREV}"
PV = "${LINUX_VERSION}"

SRC_URI = " \

git://g...@github.com/redacted/linux.git;name=kernel;branch=${KBRANCH};protocol=ssh
\
"

do_configure_prepend() {
if [ -n "${KBUILD_DEFCONFIG}" ] && [ -f
"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" ]; then
oe_runmake_call -C ${S} CC="${KERNEL_CC}"
LD="${KERNEL_LD}" O=${B} ${KBUILD_DEFCONFIG}
fi
}

Cheers,
Jack.

On 28/08/2020 21:55, Bruce Ashfield wrote:
> On Fri, Aug 28, 2020 at 4:20 PM Jack Mitchell  wrote:
>>
>> Having just upgraded my mainline kernel recipe to a v5.8/v5.9-rc2 kernel
>> from v5.5.8 I've found that modules have somehow broken. I've flicked
>> between the two and confirmed that the old kernel build works, and the
>> 5.8/5.9 build doesn't. I haven't changed anything bar the git commit
>> hash. It's a very simple kernel recipe basically just inheriting the
>> kernel bbclass and setting SRCREV. Running on current tip of master.
>>
>> I assume it's something symver related but wanted to ask if anybody
>> knows anything before I dig too deep.
> 
> I can say that it is working for me on 5.8 and 5.9-rcX on the reference 
> kernels.
> 
> qemux86-64 login: root
> root@qemux86-64:~# uname -a
> Linux qemux86-64 5.8.4-yocto-standard #1 SMP PREEMPT Wed Aug 26
> 16:07:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
> root@qemux86-64:~# lsmod
> Module  Size  Used by
> parport_pc 24576
> parport28672  1 parport_pc
> ata_piix   36864  0
> floppy 77824  0
> sch_fq_codel   20480  1
> 
> my 5.9-rc is rebuilding right now, so I can double check it over the weekend.
> 
> Not super useful, but there shouldn't be anything fundamentally
> broken, since we've been following along with the latest as usual.
> 
> Is your g_ether built in-tree, or out of tree ?
> 
> Bruce
> 
> 
>>
>> Cheers,
>> Jack.
>>
>> root@rk3399:~# uname  -a
>> Linux rk3399 5.9.0-rc2 #1 SMP PREEMPT Fri Aug 28 18:47:44 UTC 2020
>> aarch64 GNU/Linux
>>
>> root@rk3399:~# modprobe g_ether
>> modprobe: ERROR: could not insert 'g_ether': Exec format error
>>
>> root@rk3399:~# modinfo
>> /lib/modules/5.9.0-rc2/kernel/drivers/usb/gadget/legacy/g_ether.ko
>> filename:
>> /lib/modules/5.9.0-rc2/kernel/drivers/usb/gadget/legacy/g_ether.ko
>> license:GPL
>> author: David Brownell, Benedikt Spanger
>> description:RNDIS/Ethernet Gadget
>> depends:libcomposite,u_ether,usb_f_rndis
>> intree: Y
>> name:   g_ether
>> vermagic:   5.9.0-rc2 SMP preempt mod_unload aarch64
>> parm:   idVendor:USB Vendor ID (ushort)
>> parm:   idProduct:USB Product ID (ushort)
>> parm:   bcdDevice:USB Device version (BCD) (ushort)
>> parm:   iSerialNumber:SerialNumber string (charp)
>> parm:   iManufacturer:USB Manufacturer string (charp)
>> parm:   iProduct:USB Product string (charp)
>> parm:   qmult:queue length multiplier at high/super speed (uint)
>> parm:   dev_addr:Device Ethernet Address (charp)
>> parm:   host_addr:Host Ethernet Address (charp)
>> parm:   use_eem:use CDC EEM mode (bool)
>>
>> [jack@arch-corsair ~]$ file g_ether.ko
>> g_ether.ko: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV),
>> BuildID[sha1]=375c0485cb8c4b013dc0694725457bd111899f8c, not stripped
>>
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141939): 
https://lists.openembedded.org/g/openembedded-core/message/141939
Mute This Topic: https://lists.openembedded.org/mt/76482555/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Linux v5.8 modules, exec format error

[Jack Mitchell]

Having just upgraded my mainline kernel recipe to a v5.8/v5.9-rc2 kernel
from v5.5.8 I've found that modules have somehow broken. I've flicked
between the two and confirmed that the old kernel build works, and the
5.8/5.9 build doesn't. I haven't changed anything bar the git commit
hash. It's a very simple kernel recipe basically just inheriting the
kernel bbclass and setting SRCREV. Running on current tip of master.

I assume it's something symver related but wanted to ask if anybody
knows anything before I dig too deep.

Cheers,
Jack.

root@rk3399:~# uname  -a
Linux rk3399 5.9.0-rc2 #1 SMP PREEMPT Fri Aug 28 18:47:44 UTC 2020
aarch64 GNU/Linux

root@rk3399:~# modprobe g_ether
modprobe: ERROR: could not insert 'g_ether': Exec format error

root@rk3399:~# modinfo
/lib/modules/5.9.0-rc2/kernel/drivers/usb/gadget/legacy/g_ether.ko
filename:
/lib/modules/5.9.0-rc2/kernel/drivers/usb/gadget/legacy/g_ether.ko
license:GPL
author: David Brownell, Benedikt Spanger
description:RNDIS/Ethernet Gadget
depends:libcomposite,u_ether,usb_f_rndis
intree: Y
name:   g_ether
vermagic:   5.9.0-rc2 SMP preempt mod_unload aarch64
parm:   idVendor:USB Vendor ID (ushort)
parm:   idProduct:USB Product ID (ushort)
parm:   bcdDevice:USB Device version (BCD) (ushort)
parm:   iSerialNumber:SerialNumber string (charp)
parm:   iManufacturer:USB Manufacturer string (charp)
parm:   iProduct:USB Product string (charp)
parm:   qmult:queue length multiplier at high/super speed (uint)
parm:   dev_addr:Device Ethernet Address (charp)
parm:   host_addr:Host Ethernet Address (charp)
parm:   use_eem:use CDC EEM mode (bool)

[jack@arch-corsair ~]$ file g_ether.ko
g_ether.ko: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV),
BuildID[sha1]=375c0485cb8c4b013dc0694725457bd111899f8c, not stripped

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141934): 
https://lists.openembedded.org/g/openembedded-core/message/141934
Mute This Topic: https://lists.openembedded.org/mt/76482555/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] wic creates ext4 images that read really slow in u-boot

[Jack Mitchell]

On 19/02/2019 20:45, Leon Woestenberg wrote:
> Hello all,
> 
> On Tue, Feb 19, 2019 at 8:28 PM Andre McCurdy  wrote:
>> On Tue, Feb 19, 2019 at 9:13 AM Leon Woestenberg  wrote:
>>>
>>> Hello Mike,
>>>
>>> sounds familiar.
>>>
>>> On Tue, 19 Feb 2019 at 17:55, Mike Looijmans  
>>> wrote:

 Took me a while to figure out why my board took 90 seconds to boot 
 suddenly.
 The issue turned out to be the ext4 partition created by wic.
>>>
>>> I suspect it's not WIC's fault.

 ZynqMP> load mmc 0:2 0x10 /lib/firmware/fpga.bin
 19311092 bytes read in 85529 ms (219.7 KiB/s)

 Now if I boot the board rename and copy that file onto itself, then it's
 suddenly normal again when I reboot the board:

 ZynqMP> load mmc 0:2 0x1
 I'm not knowledgeable on ext4, so any ideas what's being passed onto the 
 image
 creation tool that causes this?
>>>
>>> I suspect your version of U-Boot does not handle files spread across 
>>> multiple filesystems (allocation) extends efficiently.
>>>
>>> Copying the file makes the copy being layed out in one extend probably.
>>
>>
>> If WIC is generating filesystem images from scratch there's no excuse for 
>> files to be unnecessarily fragmented.
>>
>> Even if some of all of the boot time can be recovered by a patch to u-boot 
>> that won't help systems which have already been deployed and don't have a 
>> way to update the bootloader.
>>
> I am not sure if "fragmented" is the right term in terms of filesystem
> details. Filesystem allocation extents (not "extends" as I mistyped
> earlier) are different from heavy file fragmentation. However, I agree
> things can be made more optimal.
> 
> So, with adding the above, there are *two* issues at play here:
> 1) Most/older versions of U-Boot not able to efficiently load files
> from ext4 filesystems, that cross multiple extents. I am aware of two
> fixes, see below.
> 2) WIC uses mkext4fs in such a way that files can cross multiple
> (allocation) extents. This is sub-optimal and know to cause issues
> with many U-Boot versions (deployed on existing systems in the field).
> The problems shows "randomly" with large files being deployed to the
> ext4 filesystem. We (OE/Yocto) may want to fix this.
> 
>>> I am aware of two fixes for U-Boot. I will look them up, and reply again to 
>>> this thread.
> 
> Google for these two commits. I cherry-picked the first one for my
> project and can confirm it brings back the desired performance. (Still
> assuming this is the identical cause as for TO/Mike.)
> 
> commit 855b8e4f9f255415a7753819e392e4b5d984f35c
> Author: Matt Madison 
> Date:   Sat Aug 19 08:46:46 2017 -0700
> 
> ext4: cache extent blocks during file reads
> 
> A simpler and less-efficient approach to solving
> the problem with extent index blocks than what
> was in fc0fc50f38a4d7d0554558076a79dfe8b0d78cd5,
> but one that does not break write operations.
> 
> Signed-off-by: Matt Madison 
> 
> Regards,
> 
> Leon.
> 
> p.s. excuse the earlier HTML mail with signature
> 

I can concur that I have also used this patch to fix speed issues with
ext4 reads. The problem becomes particularly prominent when you have
large files on a small partition which get over-written. I'm sure I have
seen a patch go into uboot mainline recently which improved performance
but I can't find it or it never actually made it into the tree.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] recipes-support: Add recipe for libgpiod

[Jack Mitchell]

On 11/05/17 23:28, Denys Dmytriyenko wrote:
> On Thu, May 11, 2017 at 08:50:09PM +0200, Belisko Marek wrote:
>> On Thu, May 11, 2017 at 8:19 PM, Denys Dmytriyenko <de...@denix.org> wrote:
>>> Not to derail your enthusiasm, but since this is being proposed for OE-Core,
>>> how is it better than libsoc by Jack Mitchell?
>> libsoc is fine but libgpiod will implement correctly gpio handling in
>> userspace as gpio sysfs is deprecated.
>> What is the problem to have libgpiod available for other potential
>> users? Thanks.
> As far as I know, libsoc is still being actively supported and if there's an 
> API change, it should be fixed in no time. That's why I'm copying Jack here, 
> who is an active OE developer here.
>
> As of having an alternative for other potential users - there's nothing wrong 
> with it. But, acceptance criteria into OE-Core is quite high, especially when 
> there are alternative solutions already available. That's why I'm asking if 
> it's any better than the other solution. In other words, why libgpiod should 
> be accepted to OE-Core, but not libsoc? Maybe it should be submitted to 
> meta-openembedded layer instead?

I would agree that this should go in meta-oe.

I haven't implemented the new ioctl interface yet in libsoc and there is
no reason why there can't be two libraries with similar functionallity.

Cheers,
Jack.

>
>
>> More here: 
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1392949.html
>>>
>>> On Thu, May 11, 2017 at 07:43:00PM +0200, Marek Belisko wrote:
>>>> libgpiod - C library and tools for interacting with the linux GPIO
>>>> character device
>>>>
>>>> Since linux 4.8 the GPIO sysfs interface is deprecated.
>>>> User space should use the character device instead.
>>>> This library encapsulates the ioctl calls and data structures behind a
>>>> straightforward API.
>>>>
>>>> Signed-off-by: Marek Belisko <marek.beli...@open-nandra.com>
>>>> ---
>>>>  meta/recipes-support/libgpiod/libgpiod_0.2.bb | 25 
>>>> +
>>>>  1 file changed, 25 insertions(+)
>>>>  create mode 100644 meta/recipes-support/libgpiod/libgpiod_0.2.bb
>>>>
>>>> diff --git a/meta/recipes-support/libgpiod/libgpiod_0.2.bb 
>>>> b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
>>>> new file mode 100644
>>>> index 000..fe2cd80
>>>> --- /dev/null
>>>> +++ b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
>>>> @@ -0,0 +1,25 @@
>>>> +SUMMARY = "C library and tools for interacting with the linux GPIO 
>>>> character device"
>>>> +HOMEPAGE = "https://github.com/brgl/libgpiod;
>>>> +
>>>> +LICENSE = "LGPLv2.1+"
>>>> +LIC_FILES_CHKSUM = "file://COPYING;md5=2caced0b25dfefd4c601d92bd15116de"
>>>> +
>>>> +UPSTREAM_CHECK_URI = "https://github.com/brgl/libgpiod/releases;
>>>> +
>>>> +SRC_URI = "https://github.com/brgl/libgpiod/archive/v${PV}.tar.gz;
>>>> +
>>>> +SRC_URI[md5sum] = "e3430f35b6efa842693d659c0bfb7ad5"
>>>> +SRC_URI[sha256sum] = 
>>>> "de1947f3cb2cc4174364af430309fe6238976658575655bdbd76c60cffa7df92"
>>>> +
>>>> +inherit autotools pkgconfig
>>>> +
>>>> +# enable tools
>>>> +PACKAGECONFIG ?= "tools"
>>>> +
>>>> +PACKAGECONFIG[tests] = "--enable-tests,--disable-tests,kmod udev"
>>>> +PACKAGECONFIG[tools] = "--enable-tools,--disable-tools,"
>>>> +
>>>> +PACKAGES += " ${PN}-tools"
>>>> +
>>>> +FILES_${PN} = "${libdir}/*"
>>>> +FILES_${PN}-tools = "${bindir}/*"
>>>> --
>>>> 2.7.4
>>>>
>>>> --
>>>> ___
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> BR,
>>
>> marek
>>
>> -- 
>> as simple and primitive as possible
>> -
>> Marek Belisko - OPEN-NANDRA
>> Freelance Developer
>>
>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> Tel: +421 915 052 184
>> skype: marekwhite
>> twitter: #opennandra
>> web: http://open-nandra.com
>>

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

[OE-core] [PATCH 1/2] u-boot: fix extlinux creation race

[Jack Mitchell]

From: Jack Mitchell <j...@embed.me.uk>

There was a race condition in the uboot-extlinux bbclass where
only a half written extlinux.conf would be put in the deploy
directory. Fix this by adding the deploy task after the do_install
rather than after the do_compile.

Signed-off-by: Jack Mitchell <j...@embed.me.uk>
---
 meta/recipes-bsp/u-boot/u-boot.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index c2bcf99840..aa21c0e556 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -304,4 +304,4 @@ do_deploy () {
 fi
 }
 
-addtask deploy before do_build after do_compile
+addtask deploy before do_build after do_install
-- 
2.12.0

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

[OE-core] [PATCH 2/2] u-boot: add option to specify FDT argument in extlinux.conf

[Jack Mitchell]

From: Jack Mitchell <j...@embed.me.uk>

Also fixes a use before defined bug with localdata.

Signed-off-by: Jack Mitchell <j...@embed.me.uk>
---
 meta/classes/uboot-extlinux-config.bbclass | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/meta/classes/uboot-extlinux-config.bbclass 
b/meta/classes/uboot-extlinux-config.bbclass
index aae21713e3..8447a047ee 100644
--- a/meta/classes/uboot-extlinux-config.bbclass
+++ b/meta/classes/uboot-extlinux-config.bbclass
@@ -12,6 +12,7 @@
 # UBOOT_EXTLINUX_KERNEL_ARGS   - Add additional kernel arguments.
 # UBOOT_EXTLINUX_KERNEL_IMAGE  - Kernel image name.
 # UBOOT_EXTLINUX_FDTDIR- Device tree directory.
+# UBOOT_EXTLINUX_FDT   - Device tree file.
 # UBOOT_EXTLINUX_INITRD- Indicates a list of filesystem images to
 #concatenate and use as an initrd 
(optional).
 # UBOOT_EXTLINUX_MENU_DESCRIPTION  - Name to use as description.
@@ -59,6 +60,7 @@
 # a console=...some_tty...
 UBOOT_EXTLINUX_CONSOLE ??= "console=${console}"
 UBOOT_EXTLINUX_LABELS ??= "linux"
+UBOOT_EXTLINUX_FDT ??= ""
 UBOOT_EXTLINUX_FDTDIR ??= "../"
 UBOOT_EXTLINUX_KERNEL_IMAGE ??= "../${KERNEL_IMAGETYPE}"
 UBOOT_EXTLINUX_KERNEL_ARGS ??= "rootwait rw"
@@ -84,6 +86,8 @@ python create_extlinux_config() {
 if not cfile:
 bb.fatal('Unable to read UBOOT_EXTLINUX_CONFIG')
 
+localdata = bb.data.createCopy(d)
+
 try:
 with open(cfile, 'w') as cfgfile:
 cfgfile.write('# Generic Distro Configuration file generated by 
OpenEmbedded\n')
@@ -99,9 +103,8 @@ python create_extlinux_config() {
 default = localdata.getVar('UBOOT_EXTLINUX_DEFAULT_LABEL')
 if default:
 cfgfile.write('DEFAULT %s\n' % (default))
-
+
 for label in labels.split():
-localdata = bb.data.createCopy(d)
 
 overrides = localdata.getVar('OVERRIDES')
 if not overrides:
@@ -121,7 +124,13 @@ python create_extlinux_config() {
 
 kernel_image = localdata.getVar('UBOOT_EXTLINUX_KERNEL_IMAGE')
 fdtdir = localdata.getVar('UBOOT_EXTLINUX_FDTDIR')
-if fdtdir:
+
+fdt = localdata.getVar('UBOOT_EXTLINUX_FDT')
+
+if fdt:
+cfgfile.write('LABEL %s\n\tKERNEL %s\n\tFDT %s\n' %
+ (menu_description, kernel_image, fdt))
+elif fdtdir:
 cfgfile.write('LABEL %s\n\tKERNEL %s\n\tFDTDIR %s\n' %
  (menu_description, kernel_image, fdtdir))
 else:
-- 
2.12.0

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

Re: [OE-core] "inherit setuptools" versus "inherit pypi" -- a python style question

[Jack Mitchell]

On 03/03/17 10:06, Robert P. J. Day wrote:
> On Fri, 3 Mar 2017, Anders Darander wrote:
> 
>> * Robert P. J. Day  [170302 12:33]:
>>
>>> On Thu, 2 Mar 2017, Robert P. J. Day wrote:
>>
   inherit pypi setuptools
   require python-psutil.inc
>>
 and the corresponding .inc file contains:
>>
   RDEPENDS_${PN} += " \
 ${PYTHON_PN}-shell \
 ${PYTHON_PN}-subprocess \
 ${PYTHON_PN}-threading \
   "
>>
 so the first recipe inherits pypi, the second one inherits setuptools,
 and the third inherits *both*. what is the *preferred* style?
>>
>> Well, different purposes... If you take a look at pypi.bbclass, it's all
>> about how to retrieve the module (source code). setuptools.bbclass is
>> about how to install the module...
>>
>> Ie retrieving and installing...
> 
>   yes, i finally twigged to that, but is there a *preferred* style?
> from what i've seen, if there is a pair of files for a python module:
> 
>   * foo.bb (which includes ...)
>   * foo.inc
> 
> the common style seems to be that:
> 
>   * foo.bb inherits setuptools, while
>   * foo.inc inherits pypi (if necessary, of course)
> 
> at least i think that was the common style. obviously, there are
> perfectly acceptable variations, i'd just like to know if there is a
> recommended style.
> 

One reason for this is for py2/py3 reciepes. python-foo.bb will inherit
setuptools, while python3-foo has to inherit setuptools3. So I would
imagine that setuptools should always go in the bb. While pypi is python
version agnostic I believe.

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

Re: [OE-core] non-standard library locations and rpath

[Jack Mitchell]

On 05/12/16 16:43, Khem Raj wrote:

On Mon, Dec 5, 2016 at 2:54 AM, Jack Mitchell <m...@embed.me.uk> wrote:



On 05/12/16 10:44, Jack Mitchell wrote:


On 02/12/16 07:08, Khem Raj wrote:


On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell <m...@embed.me.uk> wrote:


I'm having some troubles with shared library, shared library
dependencies
and rpaths. I have libfoo, which depends on libbar when I try to link
libfoo
with my app, it requires libbar to be found. libbar is in a non-standard
location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now
when I
come to try link my app with libfoo, it fails to link as it can't find
libbar, which I assume means the rpath in libfoo isn't being properly
prepending with sysroot what is the proper way to support this in OE? My
library has the following rpath information:

0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

So why isn't the rpath being prepended with the sysroot when I
compile my
app and link libfoo? The apps build system is using cmake, but this
should
be a built in linker feature, correct?



Only first path ( before :) is relative to location of binary at runtime



Exactly, so how can you make an OE build use the rpaths of libs that
point to the build sysroot. What I have at the moment is

0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

Which would be correct if I was linking on the target. However when OE
sees the rpath in it's cross compile environment it should prepend it
with the build sysroot so you end up with something like

0x000f (RPATH) Library rpath:
[$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]

And then the SDK should end up with something like

0x000f (RPATH) Library rpath:
[$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]

Is this what is expected to happen, or am I stumbling into an
unsupported scenario.

Cheers,



I think basically what I'm saying is that does the linker prepend it's
--sysroot value to absolute rpaths, and if not, should it?


having absolute build paths into rpaths is not a good thing. Linker
will search the libs during link in sysroot its configured to do so.



Ok, that makes sense. So something like this would be more appropriate?

rel_path = relative_path(mylib, otherlib)

-Wl,-rpath $ORIGIN${relpath}



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

Re: [OE-core] non-standard library locations and rpath

[Jack Mitchell]

On 05/12/16 10:44, Jack Mitchell wrote:

On 02/12/16 07:08, Khem Raj wrote:

On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell <m...@embed.me.uk> wrote:

I'm having some troubles with shared library, shared library
dependencies
and rpaths. I have libfoo, which depends on libbar when I try to link
libfoo
with my app, it requires libbar to be found. libbar is in a non-standard
location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now
when I
come to try link my app with libfoo, it fails to link as it can't find
libbar, which I assume means the rpath in libfoo isn't being properly
prepending with sysroot what is the proper way to support this in OE? My
library has the following rpath information:

0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

So why isn't the rpath being prepended with the sysroot when I
compile my
app and link libfoo? The apps build system is using cmake, but this
should
be a built in linker feature, correct?


Only first path ( before :) is relative to location of binary at runtime



Exactly, so how can you make an OE build use the rpaths of libs that
point to the build sysroot. What I have at the moment is

0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

Which would be correct if I was linking on the target. However when OE
sees the rpath in it's cross compile environment it should prepend it
with the build sysroot so you end up with something like

0x000f (RPATH) Library rpath:
[$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]

And then the SDK should end up with something like

0x000f (RPATH) Library rpath:
[$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]

Is this what is expected to happen, or am I stumbling into an
unsupported scenario.

Cheers,


I think basically what I'm saying is that does the linker prepend it's 
--sysroot value to absolute rpaths, and if not, should it?

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

Re: [OE-core] non-standard library locations and rpath

[Jack Mitchell]

On 02/12/16 07:08, Khem Raj wrote:

On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell <m...@embed.me.uk> wrote:

I'm having some troubles with shared library, shared library dependencies
and rpaths. I have libfoo, which depends on libbar when I try to link libfoo
with my app, it requires libbar to be found. libbar is in a non-standard
location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now when I
come to try link my app with libfoo, it fails to link as it can't find
libbar, which I assume means the rpath in libfoo isn't being properly
prepending with sysroot what is the proper way to support this in OE? My
library has the following rpath information:

0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

So why isn't the rpath being prepended with the sysroot when I compile my
app and link libfoo? The apps build system is using cmake, but this should
be a built in linker feature, correct?


Only first path ( before :) is relative to location of binary at runtime



Exactly, so how can you make an OE build use the rpaths of libs that 
point to the build sysroot. What I have at the moment is


0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

Which would be correct if I was linking on the target. However when OE 
sees the rpath in it's cross compile environment it should prepend it 
with the build sysroot so you end up with something like


0x000f (RPATH) Library rpath: 
[$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]


And then the SDK should end up with something like

0x000f (RPATH) Library rpath: 
[$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]


Is this what is expected to happen, or am I stumbling into an 
unsupported scenario.


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

[OE-core] non-standard library locations and rpath

[Jack Mitchell]

I'm having some troubles with shared library, shared library 
dependencies and rpaths. I have libfoo, which depends on libbar when I 
try to link libfoo with my app, it requires libbar to be found. libbar 
is in a non-standard location, /usr/local/bar when I compiled libfoo, I 
used -Wl,rpath-link ${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath 
/usr/local/bar. Now when I come to try link my app with libfoo, it fails 
to link as it can't find libbar, which I assume means the rpath in 
libfoo isn't being properly prepending with sysroot what is the proper 
way to support this in OE? My library has the following rpath information:


0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

So why isn't the rpath being prepended with the sysroot when I compile 
my app and link libfoo? The apps build system is using cmake, but this 
should be a built in linker feature, correct?


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

Re: [OE-core] [PATCH 0/4] Persistent /var/log support

[Jack Mitchell]

On 22/11/16 10:10, Chen Qi wrote:

The following changes since commit a675b2c89e477af088faee9b3be96eae19a85f0b:

  sanity.bbclass: fix logging of an error (2016-11-15 15:18:50 +)

are available in the git repository at:

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

Chen Qi (4):
  bitbake.conf: add VOLATILE_LOG_DIR variable
  base-files: respect VOLATILE_LOG_DIR
  initscripts: support persistent /var/log
  package.bbclass: support persistent /var/log

 meta/classes/package.bbclass   |  2 +-
 meta/conf/bitbake.conf |  3 +
 meta/files/fs-perms-persistent-log.txt | 69 ++
 meta/recipes-core/base-files/base-files_3.0.14.bb  |  4 +-
 .../initscripts/initscripts-1.0/volatiles  |  1 -
 meta/recipes-core/initscripts/initscripts_1.0.bb   |  3 +
 6 files changed, 78 insertions(+), 4 deletions(-)
 create mode 100644 meta/files/fs-perms-persistent-log.txt



Ack from me, I don't know if this is the best way to do it, but it is 
way way way too hard to get persistent logging in OE. I've had to 
implement it in numerous ways, multiple times over the past few years 
and it shouldn't be that hard.

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

Re: [OE-core] npm.bbclass support for deep native modules?

[Jack Mitchell]

On 28/11/16 10:35, Peter A. Bigot wrote:

On 11/28/2016 04:11 AM, Paul Eggleton wrote:

Hi Peter,

On Sat, 26 Nov 2016 18:17:48 Peter A. Bigot wrote:

I'm using the current head of morty and trying to get a handle on the
new nodejs support in OE.

I'm failing to build a recipe for statsd.  Starting with this:

  devtool add 'npm://registry.npmjs.org;name=statsd;version=0.8.0'
  bitbake statsd

produces an error related to the modern-syslog dependency:

   DEBUG: Executing shell function do_compile

| npm ERR! Linux 4.4.0-47-generic
| npm ERR! argv

"/mnt/devel/oe/omap/build-bb-morty-master/tmp/sysroots/x86_64-linux/usr/bin/

node"
"/mnt/devel/oe/omap/build-bb-morty-master/tmp/sysroots/x86_64-linux/usr/bin

/npm" "--arch=arm" "--target_arch=arm" "--production" "--no-registry"
"install"
| npm ERR! node v4.6.1
| npm ERR! npm  v2.15.9

| npm ERR! Registry not defined and registry files not found:
"/mnt/devel/oe/omap/build-bb-morty-master/tmp/work/cortexa8hf-neon-poky-linu

x-gnueabi/statsd/0.8.0-r0/npm_cache/noregistry/modern-syslog/.cache.json",

"/mnt/devel/oe/omap/build-bb-morty-master/tmp/work/cortexa8hf-neon-poky-lin

ux-gnueabi/statsd/0.8.0-r0/npm_cache/modern-syslog/.cache.json".

modern-syslog 1.1.2 needs node-gyp to build a native component and
https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM notes that devtool
can't detect such things.  Doing this works fine to build that package:

  devtool add
'npm://registry.npmjs.org;name=modern-syslog;version=1.1.2'
bitbake modern-syslog

but I'm having no luck getting "bitbake statsd" to find the result.
I've added:

  DEPENDS = "modern-syslog"

to statsd_0.8.0.bb but that isn't helping.  It looks like I need some
way to have the recipe install the prepared modern-syslog into the cache
(or globally?) before baking statsd, but since the cache gets cleared in
npm_do_compile() it's not clear how to make that happen.

I'm very rusty with OE (two years away), so am I missing something or is
this just beyond what the bitbake infrastructure can currently handle?
If so, can somebody suggest a way to hand-patch the recipe, or outline
how npm.bbclass might be extended to support this?

Disclaimer - I'm the one who has been doing most of the recent work
with npm
support (aside from the node.js recipe and the original npm fetcher
plugin,
which were the work of others) however my knowledge of node.js is pretty
limited - most of it has been picked up along the way. So unfortunately I
can't immediately see why this isn't working. The thing that puzzles
me in
particular about the error you're seeing though is that we're explicitly
telling npm not to look for a registry, so why is it complaining about
the
lack of a registry?


Sorry, that wasn't clear.  statsd depends on modern-syslog but the
lockdown and shrinkwrap files generated by devtool don't include it.
From the Wiki:

"Devtool cannot detect native libraries in module dependencies, you
you'll need to manually add packages to recipe"

The Wiki doesn't go into detail of how that's supposed to be done. Is
the existing infrastructure supposed to be able to find
globally-installed modules?

I'm wondering whether https://yarnpkg.com/ or one of the other nodejs
dependency managers might be an alternative, as I believe npm's approach
to dependencies is not suited to level of lockdown needed by Yocto and
many other production systems.

Peter


Hi Peter,

I'm in a similar boat packaging a custom project with a very large 
dependency tree. After looking at the available options and our current 
struggles with npm, yarn was our next point of call. We haven't done 
anything with it yet, but probably plan to in the near future.


Not very helpful, but just a heads up that you're not the only one 
fighting npm ;)


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

[OE-core] mount bindir confusion

[Jack Mitchell]

Does anyone have any input on where mount.* utils should be placed in 
the filesystem. I have the following binaries installed


mount: /usr/sbin/mount.exfat /usr/sbin/mount.exfat-fuse 
/bin/mount.util-linux /bin/mount /sbin/mount.fuse /sbin/mount.exfat 
/sbin/mount.cifs


Due to some being in /usr/sbin and /sbin the mount utility can't find 
the extensions when you try to call it in the following manner:


mount -t exfat /dev/sda1 /mnt

So, what would be the preferable solution? Move mount to a different 
location, move the other mount helpers to where mount is, or create 
symlinks for the helpers to where mount is?


In ArchLinux which I'm currently using at install time everything from 
util-linux in /bin /sbin is moved to the /usr/bin /usr/sbin. Is this the 
way forward as I've heard some talk before of a merged /usr.


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

Re: [OE-core] distro checking and lsb_release

[Jack Mitchell]

On 22/11/16 15:32, Burton, Ross wrote:
>
> On 22 November 2016 at 15:11, Jack Mitchell <m...@embed.me.uk
> <mailto:m...@embed.me.uk>>wrote:
>
> >distro_id = distro_data['DISTRIB_ID']
>  release = distro_data['DISTRIB_RELEASE']
> TypeError: 'NoneType' object is not subscriptable
>
>
> You're using arch which doesn't set those fields.  There's a patch on
> the list which should be in master shortly.

Ah, OK. Installing the lsb-release package does fix this for me in the
shortrun though.

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

Re: [OE-core] distro checking and lsb_release

[Jack Mitchell]

On 22/11/16 14:25, Burton, Ross wrote:

>
> On 22 November 2016 at 14:07, Jack Mitchell <m...@embed.me.uk
> <mailto:m...@embed.me.uk>>wrote:
>
> With the recent changes to distro checking the lsb_release binary
> is now
> required. I tried adding this to SANITY_REQUIRED_UTILITIES however it
> seems as though the distro check is done before the SanityEvent is
> triggered. Where would be the best place to check this binary is
> available to prevent an ugly python traceback?
>
>
> It shouldn't be required at all.  What error are you getting?

You can also run generated qemu images with a command like 'runqemu qemux86'
ERROR: Execution of event handler 'base_eventhandler' failed
Traceback (most recent call last):
  File
"/home/jack/work/build/build-build/openembedded/oe-core.git/meta/classes/base.bbclass",
line 214, in base_eventhandler(e=):
 if not e.data.getVar("NATIVELSBSTRING", False):
>e.data.setVar("NATIVELSBSTRING",
lsb_distro_identifier(e.data))
 e.data.setVar('BB_VERSION', bb.__version__)
  File
"/home/jack/work/build/build-build/openembedded/oe-core.git/meta/classes/base.bbclass",
line 47, in lsb_distro_identifier(d=):
 pass
>return oe.lsb.distro_identifier(adjust_func)

  File
"/home/jack/work/build/build-build/openembedded/oe-core.git/meta/lib/oe/lsb.py",
line 99, in distro_identifier(adjust_hook=None):

>distro_id = distro_data['DISTRIB_ID']
 release = distro_data['DISTRIB_RELEASE']
TypeError: 'NoneType' object is not subscriptable

ERROR: Error parsing configuration files
Traceback (most recent call last):
  File
"/home/jack/work/build/build-build/openembedded/bitbake.git/lib/bb/event.py",
line 124, in fire_class_handlers(event=, d=):
 continue
>execute_handler(name, handler, event, d)

  File
"/home/jack/work/build/build-build/openembedded/bitbake.git/lib/bb/event.py",
line 96, in execute_handler(name='base_eventhandler', handler=, event=, d=):
 try:
>ret = handler(event)
 except (bb.parse.SkipRecipe, bb.BBHandledException):
  File
"/home/jack/work/build/build-build/openembedded/oe-core.git/meta/classes/base.bbclass",
line 214, in base_eventhandler(e=):
 if not e.data.getVar("NATIVELSBSTRING", False):
>e.data.setVar("NATIVELSBSTRING",
lsb_distro_identifier(e.data))
 e.data.setVar('BB_VERSION', bb.__version__)
  File
"/home/jack/work/build/build-build/openembedded/oe-core.git/meta/classes/base.bbclass",
line 47, in lsb_distro_identifier(d=):
 pass
>return oe.lsb.distro_identifier(adjust_func)

  File
"/home/jack/work/build/build-build/openembedded/oe-core.git/meta/lib/oe/lsb.py",
line 99, in distro_identifier(adjust_hook=None):

>distro_id = distro_data['DISTRIB_ID']
 release = distro_data['DISTRIB_RELEASE']
TypeError: 'NoneType' object is not subscriptable


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

[OE-core] distro checking and lsb_release

[Jack Mitchell]

With the recent changes to distro checking the lsb_release binary is now
required. I tried adding this to SANITY_REQUIRED_UTILITIES however it
seems as though the distro check is done before the SanityEvent is
triggered. Where would be the best place to check this binary is
available to prevent an ugly python traceback?

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

Re: [OE-core] libtool --with-libtool-sysroot

[Jack Mitchell]

On 11/11/16 17:33, Burton, Ross wrote:


On 11 November 2016 at 17:31, Jack Mitchell <m...@embed.me.uk
<mailto:m...@embed.me.uk>> wrote:

How would one check which libtool was being used, or influence which
one autotools chooses?


One common problem is a makefile or configure using "libtool" directly
instead of $(LIBTOOL).

Grep the generated Makefiles for "libtool", the only instance where it
is executed should be in an assignment to LIBTOOL.  For example, glib:

LIBTOOL = $(top_builddir)/x86_64-poky-linux-libtool



I got to the bottom of this, I was switching between native and cross 
compiling but only running 'autoreconf -i' so it was detecting libtool 
was already present from previous native runs and not replacing it with 
our 'cross' version of libtool. I feel like there should be a binary 
compatibility check in there to auto overwrite if they don't match, but 
hey ho.


Always use autoreconf -if to force update of all the required autotools 
scripts in future.


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

Re: [OE-core] libtool --with-libtool-sysroot

[Jack Mitchell]

On 11/11/16 15:34, Burton, Ross wrote:


On 11 November 2016 at 14:34, Jack Mitchell <m...@embed.me.uk
<mailto:m...@embed.me.uk>> wrote:

However, looking at the libtool recipe in OE it has a patch which
changes the libtool flag from --with-sysroot to
--with-libtool-sysroot. The question is, how is this version not
making it into my SDK, I have sourced the environment script and a
which libtoolize points to the right path.


Is the package you are trying to build using its own libtool (or the
host libtool), and not our prefixed libtool?

Ross


This may be happening but it's just a generic autotools project. No 
references to libtool in the project apart from the ones automatically 
generated.


autoreconf -i
./configure ${CONFIGURE_FLAGS}
make

How would one check which libtool was being used, or influence which one 
autotools chooses?


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

[OE-core] libtool --with-libtool-sysroot

[Jack Mitchell]

I've run into an issue where libtool isn't using the right prefix in an 
SDK built with -c populate_sdk. Looking at the configure log I can see:


configure: WARNING: unrecognized options: --with-libtool-sysroot

However, looking at the libtool recipe in OE it has a patch which 
changes the libtool flag from --with-sysroot to --with-libtool-sysroot. 
The question is, how is this version not making it into my SDK, I have 
sourced the environment script and a which libtoolize points to the 
right path.


/openembedded/sdk/latest/sysroots/x86_64-oecore-linux/usr/bin/libtoolize

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

[OE-core] gnutls 3.5.3 & linux 3.10

[Jack Mitchell]

is anybody else seeing issues building gnutls with a 3.10 kernel on the 
target and failing at SYS_getrandom? I believe the breakage was 
introduced here


** libgnutls: Use getrandom where available via the syscall interface.
This works around an issue of not-using getrandom even if it exists
since glibc doesn't declare such function.

but AFAIU if the getrandom syscall isn't available it should fallback to 
using /dev/urandom but instead my compile step is just failing. Anyone 
else hitting this problem?


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

Re: [OE-core] [RFC] iptables: add systemd helper unit to load/restore rules

[Jack Mitchell]

On 08/09/16 12:29, Jack Mitchell wrote:

From: Jack Mitchell <j...@embed.me.uk>

there is currently no way to automatically load iptable rules
in OE. Add a systemd unit file to automatically load rules on
network connection. This is cribbed from the way ArchLinux
handles iptables with some minor modifications for OE. New rules
can be generated using 'iptables-save > iptables.rules'
---
 .../iptables/iptables/iptables.rules |  0
 .../iptables/iptables/iptables.service   | 13 +
 meta/recipes-extended/iptables/iptables_1.6.0.bb | 20 ++--
 3 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-extended/iptables/iptables/iptables.rules
 create mode 100644 meta/recipes-extended/iptables/iptables/iptables.service

diff --git a/meta/recipes-extended/iptables/iptables/iptables.rules 
b/meta/recipes-extended/iptables/iptables/iptables.rules
new file mode 100644
index 000..e69de29
diff --git a/meta/recipes-extended/iptables/iptables/iptables.service 
b/meta/recipes-extended/iptables/iptables/iptables.service
new file mode 100644
index 000..041316e
--- /dev/null
+++ b/meta/recipes-extended/iptables/iptables/iptables.service
@@ -0,0 +1,13 @@
+[Unit]
+Description=Packet Filtering Framework
+Before=network-pre.target
+Wants=network-pre.target
+
+[Service]
+Type=oneshot
+ExecStart=@SBINDIR@/iptables-restore /etc/iptables/iptables.rules
+ExecReload=@SBINDIR@/iptables-restore /etc/iptables/iptables.rules
+RemainAfterExit=yes
+
+[Install]
+WantedBy=multi-user.target
diff --git a/meta/recipes-extended/iptables/iptables_1.6.0.bb 
b/meta/recipes-extended/iptables/iptables_1.6.0.bb
index fbbe418..65430a1 100644
--- a/meta/recipes-extended/iptables/iptables_1.6.0.bb
+++ b/meta/recipes-extended/iptables/iptables_1.6.0.bb
@@ -22,13 +22,16 @@ SRC_URI = 
"http://netfilter.org/projects/iptables/files/iptables-${PV}.tar.bz2 \
file://types.h-add-defines-that-are-required-for-if_packet.patch \

file://0001-configure-Add-option-to-enable-disable-libnfnetlink.patch \

file://0002-configure.ac-only-check-conntrack-when-libnfnetlink-enabled.patch \
-  "
+   file://iptables.service \
+   file://iptables.rules \
+"
+
 SRC_URI_append_libc-musl = " file://0001-fix-build-with-musl.patch"

 SRC_URI[md5sum] = "27ba3451cb622467fc9267a176f19a31"
 SRC_URI[sha256sum] = 
"4bb72a0a0b18b5a9e79e87631ddc4084528e5df236bc7624472dcaa8480f1c60"

-inherit autotools pkgconfig
+inherit autotools pkgconfig systemd

 EXTRA_OECONF = "--with-kernel=${STAGING_INCDIR} \
"
@@ -48,3 +51,16 @@ do_configure_prepend() {
# Keep ax_check_linker_flags.m4 which belongs to autoconf-archive.
rm -f libtool.m4 lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4
 }
+
+do_install_append() {
+
+install -d ${D}${sysconfdir}/iptables
+install -m 0644 ${WORKDIR}/iptables.rules ${D}${sysconfdir}/iptables
+
+install -d ${D}${systemd_unitdir}/system
+install -m 0644 ${WORKDIR}/iptables.service 
${D}${systemd_unitdir}/system
+
+   sed -i -e 's,@SBINDIR@,${sbindir},g' 
${D}${systemd_unitdir}/system/iptables.service
+}
+
+SYSTEMD_SERVICE_${PN} = "iptables.service"



If there are no comments on this then I suggest we take it as it is. Not 
having a way to auto load iptables rules is just asking for 
layer/application specific hacks.

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

[OE-core] [RFC] iptables: add systemd helper unit to load/restore rules

[Jack Mitchell]

From: Jack Mitchell <j...@embed.me.uk>

there is currently no way to automatically load iptable rules
in OE. Add a systemd unit file to automatically load rules on
network connection. This is cribbed from the way ArchLinux
handles iptables with some minor modifications for OE. New rules
can be generated using 'iptables-save > iptables.rules'
---
 .../iptables/iptables/iptables.rules |  0
 .../iptables/iptables/iptables.service   | 13 +
 meta/recipes-extended/iptables/iptables_1.6.0.bb | 20 ++--
 3 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-extended/iptables/iptables/iptables.rules
 create mode 100644 meta/recipes-extended/iptables/iptables/iptables.service

diff --git a/meta/recipes-extended/iptables/iptables/iptables.rules 
b/meta/recipes-extended/iptables/iptables/iptables.rules
new file mode 100644
index 000..e69de29
diff --git a/meta/recipes-extended/iptables/iptables/iptables.service 
b/meta/recipes-extended/iptables/iptables/iptables.service
new file mode 100644
index 000..041316e
--- /dev/null
+++ b/meta/recipes-extended/iptables/iptables/iptables.service
@@ -0,0 +1,13 @@
+[Unit]
+Description=Packet Filtering Framework
+Before=network-pre.target
+Wants=network-pre.target
+
+[Service]
+Type=oneshot
+ExecStart=@SBINDIR@/iptables-restore /etc/iptables/iptables.rules
+ExecReload=@SBINDIR@/iptables-restore /etc/iptables/iptables.rules
+RemainAfterExit=yes
+
+[Install]
+WantedBy=multi-user.target
diff --git a/meta/recipes-extended/iptables/iptables_1.6.0.bb 
b/meta/recipes-extended/iptables/iptables_1.6.0.bb
index fbbe418..65430a1 100644
--- a/meta/recipes-extended/iptables/iptables_1.6.0.bb
+++ b/meta/recipes-extended/iptables/iptables_1.6.0.bb
@@ -22,13 +22,16 @@ SRC_URI = 
"http://netfilter.org/projects/iptables/files/iptables-${PV}.tar.bz2 \
file://types.h-add-defines-that-are-required-for-if_packet.patch \

file://0001-configure-Add-option-to-enable-disable-libnfnetlink.patch \

file://0002-configure.ac-only-check-conntrack-when-libnfnetlink-enabled.patch \
-  "
+   file://iptables.service \
+   file://iptables.rules \
+"
+
 SRC_URI_append_libc-musl = " file://0001-fix-build-with-musl.patch"
 
 SRC_URI[md5sum] = "27ba3451cb622467fc9267a176f19a31"
 SRC_URI[sha256sum] = 
"4bb72a0a0b18b5a9e79e87631ddc4084528e5df236bc7624472dcaa8480f1c60"
 
-inherit autotools pkgconfig
+inherit autotools pkgconfig systemd
 
 EXTRA_OECONF = "--with-kernel=${STAGING_INCDIR} \
"
@@ -48,3 +51,16 @@ do_configure_prepend() {
# Keep ax_check_linker_flags.m4 which belongs to autoconf-archive.
rm -f libtool.m4 lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4
 }
+
+do_install_append() {
+
+install -d ${D}${sysconfdir}/iptables
+install -m 0644 ${WORKDIR}/iptables.rules ${D}${sysconfdir}/iptables
+
+install -d ${D}${systemd_unitdir}/system
+install -m 0644 ${WORKDIR}/iptables.service 
${D}${systemd_unitdir}/system
+
+   sed -i -e 's,@SBINDIR@,${sbindir},g' 
${D}${systemd_unitdir}/system/iptables.service
+}
+
+SYSTEMD_SERVICE_${PN} = "iptables.service"
-- 
2.9.3

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

[OE-core] [PATCHv2] file: build with c std as c99

[Jack Mitchell]

From: Jack Mitchell <j...@embed.me.uk>

when using a toolchain not shipped by OE core such as linaro we
can't be sure what the std will be set to. Set to compile as c99
which is the lowest version supported.

Signed-off-by: Jack Mitchell <j...@embed.me.uk>
---
 meta/recipes-devtools/file/file_5.28.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/file/file_5.28.bb 
b/meta/recipes-devtools/file/file_5.28.bb
index 516c8c5..e64a89c 100644
--- a/meta/recipes-devtools/file/file_5.28.bb
+++ b/meta/recipes-devtools/file/file_5.28.bb
@@ -27,6 +27,8 @@ inherit autotools
 EXTRA_OEMAKE_append_class-target = "-e 
FILE_COMPILE=${STAGING_BINDIR_NATIVE}/file-native/file"
 EXTRA_OEMAKE_append_class-nativesdk = "-e 
FILE_COMPILE=${STAGING_BINDIR_NATIVE}/file-native/file"
 
+CFLAGS_append = " -std=c99"
+
 FILES_${PN} += "${datadir}/misc/*.mgc"
 
 do_install_append_class-native() {
-- 
2.9.3

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

Re: [OE-core] [PATCH] cmake.bbclass: avoid treating imports as system includes

[Jack Mitchell]

On 06/09/16 22:41, Andreas Müller wrote:

CMake sets all imported headers as system headers. This causes trouble for c++
projects [1].

Thanks to Jack Mitchell for pointing to the setting [2]. Build tested upon
meta-qt5-extra-world which had lots of fallout before.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
[2] 
http://lists.openembedded.org/pipermail/openembedded-core/2016-September/126067.html

Signed-off-by: Andreas Müller <schnitzelt...@googlemail.com>
---
 meta/classes/cmake.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 5203d8a..7091f8b 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -120,6 +120,7 @@ cmake_do_configure() {
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
  -DCMAKE_VERBOSE_MAKEFILE=1 \
+ -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
  ${EXTRA_OECMAKE} \
  -Wno-dev
 }



This is cleaner than my implementation.

Acked By: Jack Mitchell <j...@embed.me.uk>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] file: specify c std as c99 or greater required

[Jack Mitchell]

On 06/09/16 19:36, Khem Raj wrote:

On Sep 6, 2016, at 6:25 AM, Jack Mitchell <m...@embed.me.uk> wrote:

From: Jack Mitchell <j...@embed.me.uk>

when using a toolchain not shipped by OE core such as linaro we
can't be sure what the std will be set to. Ensure file is compiled
as c99 or greater as required.

comment does not match the code, its using gnu11, secondly is gnu11 needed or 
can it live with
c11


Comment says it needs 'c99 or greater' so I set it to gnu11 which is the 
default we use for gcc6, no? The minimum it can compile with is c99, 
would that be a better option to set?


Cheers,




Signed-off-by: Jack Mitchell <j...@embed.me.uk>
---
meta/recipes-devtools/file/file_5.28.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/file/file_5.28.bb 
b/meta/recipes-devtools/file/file_5.28.bb
index 516c8c5..94848db 100644
--- a/meta/recipes-devtools/file/file_5.28.bb
+++ b/meta/recipes-devtools/file/file_5.28.bb
@@ -27,6 +27,8 @@ inherit autotools
EXTRA_OEMAKE_append_class-target = "-e 
FILE_COMPILE=${STAGING_BINDIR_NATIVE}/file-native/file"
EXTRA_OEMAKE_append_class-nativesdk = "-e 
FILE_COMPILE=${STAGING_BINDIR_NATIVE}/file-native/file"

+CFLAGS_append = " -std=gnu11"
+
FILES_${PN} += "${datadir}/misc/*.mgc"

do_install_append_class-native() {
--
2.9.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

[OE-core] [PATCH] file: specify c std as c99 or greater required

[Jack Mitchell]

From: Jack Mitchell <j...@embed.me.uk>

when using a toolchain not shipped by OE core such as linaro we
can't be sure what the std will be set to. Ensure file is compiled
as c99 or greater as required.

Signed-off-by: Jack Mitchell <j...@embed.me.uk>
---
 meta/recipes-devtools/file/file_5.28.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/file/file_5.28.bb 
b/meta/recipes-devtools/file/file_5.28.bb
index 516c8c5..94848db 100644
--- a/meta/recipes-devtools/file/file_5.28.bb
+++ b/meta/recipes-devtools/file/file_5.28.bb
@@ -27,6 +27,8 @@ inherit autotools
 EXTRA_OEMAKE_append_class-target = "-e 
FILE_COMPILE=${STAGING_BINDIR_NATIVE}/file-native/file"
 EXTRA_OEMAKE_append_class-nativesdk = "-e 
FILE_COMPILE=${STAGING_BINDIR_NATIVE}/file-native/file"
 
+CFLAGS_append = " -std=gnu11"
+
 FILES_${PN} += "${datadir}/misc/*.mgc"
 
 do_install_append_class-native() {
-- 
2.9.3

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

[OE-core] [PATCHv2] cmake: set CMAKE_NO_SYSTEM_FROM_IMPORTED to ON

[Jack Mitchell]

From: Jack Mitchell <j...@embed.me.uk>

set CMAKE_NO_SYSTEM_FROM_IMPORTED to ON in the bbclass
and also the toolchain file. This is required as GCC6
has become more tetchy about the use of -isystem in the
compiler flags.

Imported targets aren't used much in cmake at the moment which
is why errors have been rare and probably worked around in
different ways prior to this patch.

Signed-off-by: Jack Mitchell <j...@embed.me.uk>
---
 meta/classes/cmake.bbclass| 1 +
 meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake | 1 +
 2 files changed, 2 insertions(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 5203d8a..8339a6b 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -57,6 +57,7 @@ set( CMAKE_CXX_FLAGS_RELEASE "${OECMAKE_CXX_FLAGS_RELEASE}" 
CACHE STRING "Additi
 set( CMAKE_ASM_FLAGS_RELEASE "${OECMAKE_C_FLAGS_RELEASE}" CACHE STRING 
"Additional ASM FLAGS for release" )
 set( CMAKE_C_LINK_FLAGS "${OECMAKE_C_LINK_FLAGS}" CACHE STRING "LDFLAGS" )
 set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE STRING "LDFLAGS" )
+set( CMAKE_NO_SYSTEM_FROM_IMPORTED ON )
 
 # only search in the paths provided so cmake doesnt pick
 # up libraries and tools from the native build machine
diff --git a/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake 
b/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
index 60014bb..8279eb6 100644
--- a/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
+++ b/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
@@ -7,6 +7,7 @@ set( CMAKE_FIND_ROOT_PATH $ENV{OECORE_TARGET_SYSROOT} 
$ENV{OECORE_NATIVE_SYSROOT
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
+set( CMAKE_NO_SYSTEM_FROM_IMPORTED ON )
 
 string(REGEX MATCH "sysroots/([a-zA-Z0-9]+)" CMAKE_SYSTEM_PROCESSOR 
$ENV{SDKTARGETSYSROOT})
 string(REGEX REPLACE "sysroots/" "" CMAKE_SYSTEM_PROCESSOR 
${CMAKE_SYSTEM_PROCESSOR})
-- 
2.9.3

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

[OE-core] [PATCH] cmake: set CMAKE_NO_SYSTEM_FROM_IMPORTED to ON

[Jack Mitchell]

From: Jack Mitchell <j...@embed.me.uk>

set CMAKE_NO_SYSTEM_FROM_IMPORTED to ON in the bbclass
and also the toolchain file. This is required as GCC6
has become more tetchy about the use of -isystem in the
compiler flags.

Imported targets aren't used much in cmake at the moment which
is why errors have been rare and probably worked around in
different ways prior to this patch.
---
 meta/classes/cmake.bbclass| 1 +
 meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake | 1 +
 2 files changed, 2 insertions(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 5203d8a..8339a6b 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -57,6 +57,7 @@ set( CMAKE_CXX_FLAGS_RELEASE "${OECMAKE_CXX_FLAGS_RELEASE}" 
CACHE STRING "Additi
 set( CMAKE_ASM_FLAGS_RELEASE "${OECMAKE_C_FLAGS_RELEASE}" CACHE STRING 
"Additional ASM FLAGS for release" )
 set( CMAKE_C_LINK_FLAGS "${OECMAKE_C_LINK_FLAGS}" CACHE STRING "LDFLAGS" )
 set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE STRING "LDFLAGS" )
+set( CMAKE_NO_SYSTEM_FROM_IMPORTED ON )
 
 # only search in the paths provided so cmake doesnt pick
 # up libraries and tools from the native build machine
diff --git a/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake 
b/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
index 60014bb..8279eb6 100644
--- a/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
+++ b/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
@@ -7,6 +7,7 @@ set( CMAKE_FIND_ROOT_PATH $ENV{OECORE_TARGET_SYSROOT} 
$ENV{OECORE_NATIVE_SYSROOT
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
+set( CMAKE_NO_SYSTEM_FROM_IMPORTED ON )
 
 string(REGEX MATCH "sysroots/([a-zA-Z0-9]+)" CMAKE_SYSTEM_PROCESSOR 
$ENV{SDKTARGETSYSROOT})
 string(REGEX REPLACE "sysroots/" "" CMAKE_SYSTEM_PROCESSOR 
${CMAKE_SYSTEM_PROCESSOR})
-- 
2.9.3

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

Re: [OE-core] [RFC][PATCH] cmake-native: work around gcc6's '-isystem'-allergy

[Jack Mitchell]

On 31/08/16 11:15, Andreas Müller wrote:

On Wed, Aug 31, 2016 at 11:25 AM, Jack Mitchell <m...@embed.me.uk> wrote:

On 30/08/16 18:14, Andreas Müller wrote:

since gcc6 we see many cmake/c++ based packets failing with:

| fatal error: stdlib.h: No such file or directory

a fix from gcc is not to expect [1] so work around by replacing '-isystem'
by
'-I' for c++.

Build tested with many recipes in meta-qt5-extra / meta-oe inheriting
cmake.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129

Signed-off-by: Andreas Müller <schnitzelt...@googlemail.com>
---
  meta/recipes-devtools/cmake/cmake-native_3.6.1.bb  |  1 +
  .../0001-GNU.cmake-replace-isystem-by-I.patch  | 42
++
  2 files changed, 43 insertions(+)
  create mode 100644
meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
b/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
index 33930fb..900091e 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
@@ -6,6 +6,7 @@ DEPENDS += "bzip2-native zlib-native"

  SRC_URI += "\
  file://cmlibarchive-disable-ext2fs.patch \
+file://0001-GNU.cmake-replace-isystem-by-I.patch \
  "

  # Disable ccmake since we don't depend on ncurses
diff --git
a/meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch
b/meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch
new file mode 100644
index 000..4c06490
--- /dev/null
+++
b/meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch
@@ -0,0 +1,42 @@
+From a84d20abe6bc68f8d1a597a22af1ca98d62a5ce4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= <schnitzelt...@googlemail.com>
+Date: Fri, 26 Aug 2016 12:14:12 +0200
+Subject: [PATCH] GNU.cmake: replace -isystem by -I
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+since gcc6 we see many c++ based packes failing with:
+
+| fatal error: stdlib.h: No such file or directory
+
+a fix from gcc is not to expect [1] so work around
+
+[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
+
+Upstream-Status: Pending
+
+Signed-off-by: Andreas Müller <schnitzelt...@googlemail.com>
+---
+ Modules/Compiler/GNU.cmake | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/Modules/Compiler/GNU.cmake b/Modules/Compiler/GNU.cmake
+index c2d393d..9d1477d 100644
+--- a/Modules/Compiler/GNU.cmake
 b/Modules/Compiler/GNU.cmake
+@@ -53,6 +53,10 @@ macro(__compiler_gnu lang)
+   set(CMAKE_${lang}_CREATE_PREPROCESSED_SOURCE "<CMAKE_${lang}_COMPILER>
   -E  > ")
+   set(CMAKE_${lang}_CREATE_ASSEMBLY_SOURCE "<CMAKE_${lang}_COMPILER>
   -S  -o ")
+   if(NOT APPLE OR NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 4) #
work around #4462
+-set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-isystem ")
++if("${lang}" STREQUAL "CXX")
++  set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-I ")
++else()
++  set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-isystem ")
++endif()
+   endif()
+ endmacro()
+--
+2.5.5
+


Thanks for the patch Andreas, this fixes my build for now but as you
mentioned is a bit of a hack to get round the issue. As this fixes my
problem does it mean that it's not bitbake which is injecting the isystem,
but instead a CMake recipe somewhere?

Regards,
Jack.
--

I don't know your recipe but I think -isystem in bitbake.conf would
only cause trouble for native recipes.

As a heavy cmake-qt5 user (kde/lxqt/hawaii) I had many failing
cross-recipes not finding stdlib.h. After reading the gcc-bug I check
compile logs and they were full of -isystem on sysroot/usr/include -
had no idea where they came from.
First I grepped oe-core but did not find suspicious (e.g bitbake.conf
- see above). Then I grepped cmake sources and found GNU.cmake,
patched it to affect c++ only and my build errors were gone.

Andreas


So I finally narrowed down what was causing my recipe to fail. For some 
bizzar reason cmake sets all includes that have come from imported 
targets as system includes. It's bonkers but there is very little 
documentation around it and I'm not sure why it would be like that. 
However, there is a magic flag [1], this may be worthwhile setting in 
our cmake class and sdk toolchain file as I can't imagine any reason why 
we would want it to work in the default manner.


If anyone who has been having issues with cmake and isystem, if they 
could try doing setting CMAKE_NO_SYSTEM_FROM_IMPORTED to on in thier 
cmake.bbclass and report back if that fixes things. It's possible my 
earlier bitbake suggestion was a red herring.


Cheers,
Jack.

[1] https://cmake.org/cmake/help/v3.0/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC][PATCH] cmake-native: work around gcc6's '-isystem'-allergy

[Jack Mitchell]

On 30/08/16 18:14, Andreas Müller wrote:

since gcc6 we see many cmake/c++ based packets failing with:

| fatal error: stdlib.h: No such file or directory

a fix from gcc is not to expect [1] so work around by replacing '-isystem' by
'-I' for c++.

Build tested with many recipes in meta-qt5-extra / meta-oe inheriting cmake.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129

Signed-off-by: Andreas Müller 
---
 meta/recipes-devtools/cmake/cmake-native_3.6.1.bb  |  1 +
 .../0001-GNU.cmake-replace-isystem-by-I.patch  | 42 ++
 2 files changed, 43 insertions(+)
 create mode 100644 
meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
index 33930fb..900091e 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb
@@ -6,6 +6,7 @@ DEPENDS += "bzip2-native zlib-native"

 SRC_URI += "\
 file://cmlibarchive-disable-ext2fs.patch \
+file://0001-GNU.cmake-replace-isystem-by-I.patch \
 "

 # Disable ccmake since we don't depend on ncurses
diff --git 
a/meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch 
b/meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch
new file mode 100644
index 000..4c06490
--- /dev/null
+++ 
b/meta/recipes-devtools/cmake/cmake/0001-GNU.cmake-replace-isystem-by-I.patch
@@ -0,0 +1,42 @@
+From a84d20abe6bc68f8d1a597a22af1ca98d62a5ce4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
+Date: Fri, 26 Aug 2016 12:14:12 +0200
+Subject: [PATCH] GNU.cmake: replace -isystem by -I
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+since gcc6 we see many c++ based packes failing with:
+
+| fatal error: stdlib.h: No such file or directory
+
+a fix from gcc is not to expect [1] so work around
+
+[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
+
+Upstream-Status: Pending
+
+Signed-off-by: Andreas Müller 
+---
+ Modules/Compiler/GNU.cmake | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/Modules/Compiler/GNU.cmake b/Modules/Compiler/GNU.cmake
+index c2d393d..9d1477d 100644
+--- a/Modules/Compiler/GNU.cmake
 b/Modules/Compiler/GNU.cmake
+@@ -53,6 +53,10 @@ macro(__compiler_gnu lang)
+   set(CMAKE_${lang}_CREATE_PREPROCESSED_SOURCE "   
 -E  > ")
+   set(CMAKE_${lang}_CREATE_ASSEMBLY_SOURCE "   
 -S  -o ")
+   if(NOT APPLE OR NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 4) # work 
around #4462
+-set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-isystem ")
++if("${lang}" STREQUAL "CXX")
++  set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-I ")
++else()
++  set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-isystem ")
++endif()
+   endif()
+ endmacro()
+--
+2.5.5
+



Thanks for the patch Andreas, this fixes my build for now but as you 
mentioned is a bit of a hack to get round the issue. As this fixes my 
problem does it mean that it's not bitbake which is injecting the 
isystem, but instead a CMake recipe somewhere?


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

[OE-core] gcc 6.1+ and isystem

[Jack Mitchell]

Some of the headers shipped with gcc 6.1 and above now use #include_next 
to try to and do clever things with munging system header files. Our 
injection of isystem into the build at 'meta/conf/bitbake.conf' seems to 
be causing some programs to fail to compile. A full explanation can be 
found at [1], a bug report from GCC specifying that it should only be 
used in extreme cases at [2].


Since we seem to be adding -isystem unconditionally to BUILD_CFLAGS from 
bitbake, and that the default behavior has now changed should this be 
revisited? I'll admit that I am no where near experienced enough with 
GCC and friends internals to make a call on this one, I'm just looking 
for some input.


Regards,
Jack.

[1] 
http://stackoverflow.com/questions/37218953/isystem-on-a-system-include-directory-causes-errors

[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cmake.bbclass: call cmake with a relative path

[Jack Mitchell]

On 22/08/16 15:27, Clemens Lang wrote:

From: Thomas Witt 

CMake wants a relative path for CMAKE_INSTALL_*DIR, an absolute path
breaks cross-compilation. This fact is documented in the following
ticket: https://cmake.org/Bug/view.php?id=14367

$sysconfdir and $localstatedir are not relative to $prefix, so they are
still set as absolute paths. With his change ${PROJECT}Targets.cmake
that are generated by cmakes "export" function will contain relative
paths instead of absolute ones.

Signed-off-by: Thomas Witt 
Signed-off-by: Clemens Lang 
---
 meta/classes/cmake.bbclass | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index b18152a..5203d8a 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,15 +108,15 @@ cmake_do_configure() {
  ${OECMAKE_SITEFILE} \
  ${OECMAKE_SOURCEPATH} \
  -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
- -DCMAKE_INSTALL_BINDIR:PATH=${bindir} \
- -DCMAKE_INSTALL_SBINDIR:PATH=${sbindir} \
- -DCMAKE_INSTALL_LIBEXECDIR:PATH=${libexecdir} \
+ -DCMAKE_INSTALL_BINDIR:PATH=${@os.path.relpath(d.getVar('bindir', 
True), d.getVar('prefix', True))} \
+ -DCMAKE_INSTALL_SBINDIR:PATH=${@os.path.relpath(d.getVar('sbindir', 
True), d.getVar('prefix', True))} \
+ 
-DCMAKE_INSTALL_LIBEXECDIR:PATH=${@os.path.relpath(d.getVar('libexecdir', 
True), d.getVar('prefix', True))} \
  -DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
- -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${sharedstatedir} \
+ 
-DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${@os.path.relpath(d.getVar('sharedstatedir',
 True), d.  getVar('prefix', True))} \
  -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
- -DCMAKE_INSTALL_LIBDIR:PATH=${libdir} \
- -DCMAKE_INSTALL_INCLUDEDIR:PATH=${includedir} \
- -DCMAKE_INSTALL_DATAROOTDIR:PATH=${datadir} \
+ -DCMAKE_INSTALL_LIBDIR:PATH=${@os.path.relpath(d.getVar('libdir', 
True), d.getVar('prefix', True))} \
+ 
-DCMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir', 
True), d.getVar('prefix', True))} \
+ 
-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir', True), 
d.getVar('prefix', True))} \
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
  -DCMAKE_VERBOSE_MAKEFILE=1 \


Thanks. I've just posted another version which uses inline python too; I 
think your version is nicer though.


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

[OE-core] [[PATCH V2]] cmake: install path variables should be relative to the prefix path

[Jack Mitchell]

From: Jack Mitchell <j...@embed.me.uk>

---
 meta/classes/cmake.bbclass | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index b18152a..bc194db 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,15 +108,15 @@ cmake_do_configure() {
  ${OECMAKE_SITEFILE} \
  ${OECMAKE_SOURCEPATH} \
  -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
- -DCMAKE_INSTALL_BINDIR:PATH=${bindir} \
- -DCMAKE_INSTALL_SBINDIR:PATH=${sbindir} \
- -DCMAKE_INSTALL_LIBEXECDIR:PATH=${libexecdir} \
- -DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
- -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${sharedstatedir} \
- -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
- -DCMAKE_INSTALL_LIBDIR:PATH=${libdir} \
- -DCMAKE_INSTALL_INCLUDEDIR:PATH=${includedir} \
- -DCMAKE_INSTALL_DATAROOTDIR:PATH=${datadir} \
+ -DCMAKE_INSTALL_BINDIR:PATH=${@'${bindir}'.replace('${prefix}/', '')} 
\
+ -DCMAKE_INSTALL_SBINDIR:PATH=${@'${sbindir}'.replace('${prefix}/', 
'')} \
+ 
-DCMAKE_INSTALL_LIBEXECDIR:PATH=${@'${libexecdir}'.replace('${prefix}/', '')} \
+ 
-DCMAKE_INSTALL_SYSCONFDIR:PATH=${@'${sysconfdir}'.replace('${prefix}/', '')} \
+ 
-DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${@'${sharedstatedir}'.replace('${prefix}/',
 '')} \
+ 
-DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${@'${localstatedir}'.replace('${prefix}/', 
'')} \
+ -DCMAKE_INSTALL_LIBDIR:PATH=${@'${libdir}'.replace('${prefix}/', '')} 
\
+ 
-DCMAKE_INSTALL_INCLUDEDIR:PATH=${@'${includedir}'.replace('${prefix}/', '')} \
+ 
-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@'${datadir}'.replace('${prefix}/', '')} \
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
  -DCMAKE_VERBOSE_MAKEFILE=1 \
-- 
2.9.3

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

Re: [OE-core] [PATCH] cmake: install path variables should be relative to the prefix path

[Jack Mitchell]

On 22/08/16 14:24, Burton, Ross wrote:


On 22 August 2016 at 14:23, Jack Mitchell <m...@embed.me.uk
<mailto:m...@embed.me.uk>> wrote:

On second thoughts this isn't doing quite what I expected, how would
one remove the prefix from a variable when it's expanded in this manner?


You curse cmake for needing install paths to be relative to the prefix?

Ross


That was last weeks agenda ;)

Could it be done with some inline python? I'm really not all that clued 
up on which variables are available when and where to be manipulated. I 
was thinking something along the lines of


${@d.getVar('bindir').replace(d.getVar('prefix', ''))}

However, this just breaks spectacularly.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cmake: install path variables should be relative to the prefix path

[Jack Mitchell]

On 22/08/16 14:05, Jack Mitchell wrote:

From: Jack Mitchell <j...@embed.me.uk>

---
 meta/classes/cmake.bbclass | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index b18152a..2375d09 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,15 +108,15 @@ cmake_do_configure() {
  ${OECMAKE_SITEFILE} \
  ${OECMAKE_SOURCEPATH} \
  -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
- -DCMAKE_INSTALL_BINDIR:PATH=${bindir} \
- -DCMAKE_INSTALL_SBINDIR:PATH=${sbindir} \
- -DCMAKE_INSTALL_LIBEXECDIR:PATH=${libexecdir} \
- -DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
- -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${sharedstatedir} \
- -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
- -DCMAKE_INSTALL_LIBDIR:PATH=${libdir} \
- -DCMAKE_INSTALL_INCLUDEDIR:PATH=${includedir} \
- -DCMAKE_INSTALL_DATAROOTDIR:PATH=${datadir} \
+ -DCMAKE_INSTALL_BINDIR:PATH=${bindir#${prefix}/} \
+ -DCMAKE_INSTALL_SBINDIR:PATH=${sbindir#${prefix}/} \
+ -DCMAKE_INSTALL_LIBEXECDIR:PATH=${libexecdir#${prefix}/} \
+ -DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir#${prefix}/} \
+ -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${sharedstatedir#${prefix}/} \
+ -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir#${prefix}/} \
+ -DCMAKE_INSTALL_LIBDIR:PATH=${libdir#${prefix}/} \
+ -DCMAKE_INSTALL_INCLUDEDIR:PATH=${includedir#${prefix}/} \
+ -DCMAKE_INSTALL_DATAROOTDIR:PATH=${datadir#${prefix}/} \
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
  -DCMAKE_VERBOSE_MAKEFILE=1 \



On second thoughts this isn't doing quite what I expected, how would one 
remove the prefix from a variable when it's expanded in this manner?


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

[OE-core] [PATCH] cmake: install path variables should be relative to the prefix path

[Jack Mitchell]

From: Jack Mitchell <j...@embed.me.uk>

---
 meta/classes/cmake.bbclass | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index b18152a..2375d09 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,15 +108,15 @@ cmake_do_configure() {
  ${OECMAKE_SITEFILE} \
  ${OECMAKE_SOURCEPATH} \
  -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
- -DCMAKE_INSTALL_BINDIR:PATH=${bindir} \
- -DCMAKE_INSTALL_SBINDIR:PATH=${sbindir} \
- -DCMAKE_INSTALL_LIBEXECDIR:PATH=${libexecdir} \
- -DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
- -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${sharedstatedir} \
- -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
- -DCMAKE_INSTALL_LIBDIR:PATH=${libdir} \
- -DCMAKE_INSTALL_INCLUDEDIR:PATH=${includedir} \
- -DCMAKE_INSTALL_DATAROOTDIR:PATH=${datadir} \
+ -DCMAKE_INSTALL_BINDIR:PATH=${bindir#${prefix}/} \
+ -DCMAKE_INSTALL_SBINDIR:PATH=${sbindir#${prefix}/} \
+ -DCMAKE_INSTALL_LIBEXECDIR:PATH=${libexecdir#${prefix}/} \
+ -DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir#${prefix}/} \
+ -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${sharedstatedir#${prefix}/} \
+ -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir#${prefix}/} \
+ -DCMAKE_INSTALL_LIBDIR:PATH=${libdir#${prefix}/} \
+ -DCMAKE_INSTALL_INCLUDEDIR:PATH=${includedir#${prefix}/} \
+ -DCMAKE_INSTALL_DATAROOTDIR:PATH=${datadir#${prefix}/} \
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
  -DCMAKE_VERBOSE_MAKEFILE=1 \
-- 
2.9.3

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

Re: [OE-core] [PATCH 0/3] Dynamic common utilities

[Jack Mitchell]

On 17/09/15 17:20, Alejandro Joya wrote:

It provide a virtual reference for the common utilities.
it replace of the lock to busybox, it will be simple exchange between other
common utilities like gnu core utils or toybox among others.

In order to enable its required to fill at the distro conf or local.conf

VIRTUAL-RUNTIME_login_manager ?= "busybox"
PREFERRED_PROVIDER_virtual/anybox ?= "busybox"
PREFERRED_RPROVIDER_virtual/anybox ?= "busybox"
VIRTUAL-RUNTIME_anybox ?= "busybox"
VIRTUAL-RUNTIME_anybox-hwclock ?= "busybox-hwclock"

The following changes since commit f0189829498e30231d826c9f55aad73e622d076e:

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

are available in the git repository at:

   git://github.com/Ajoyacr/openembedded-core anybox
   https://github.com/Ajoyacr/openembedded-core/tree/anybox

Alejandro Joya (3):
   core-mage-minimal-initramfs: overwrite hardcoded dependency to virtual
 reference
   initramfs-framework: overwrite hardcoded dependency to virtual
 reference
   packagegroup-core-boot: overwrite hardcoded dependency to virtual
 reference

  meta/recipes-core/images/core-image-minimal-initramfs.bb   | 2 +-
  meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb | 2 +-
  meta/recipes-core/packagegroups/packagegroup-core-boot.bb  | 6 +++---
  3 files changed, 5 insertions(+), 5 deletions(-)



is 'anybox' a good name for the virtual provider? What happens if we have a new 
suite of core utility replacements without box in the name, I assume it will be 
a nightmare to retroactivly change the name so we should probably come up with a 
more generic one now. virtual/core-utils, virtual/base-utils?


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

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Jack Mitchell]

On 02/09/15 16:55, Otavio Salvador wrote:

On Tue, Sep 1, 2015 at 6:34 PM, Joe Slater  wrote:

Implements ifup and ifdown.

Copied from https://github.com/WindRiver-OpenSourceLabs/meta-overc.git
as of commit aa89eebffe06e4aa04701eae9691cb3049cbaef9.

Signed-off-by: Joe Slater 


I think this belongs to meta-networking. Also, what this one provides
which is not provided by the busybox one?



This provides hotplug support which the busybox version does not. I'm torn on 
where it should land i.e. meta-networking vs core but it is a useful addition 
regardless.


If you're attempting to do a non busybox based build, then I don't see the 
reasoning for not just using connman as your networking manager instead which is 
already supported in core.

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

[OE-core] making /var/log persistent

[Jack Mitchell]

I'm trying to make /var/log persistent and I'm having trouble. I've made a 
bbappend to base_files which contains:


dirs755_append =  \
/var/log \


volatiles = tmp

Looking in the resulting image, /var/log is indeed now a directory and not a 
symlink to volatile storage, however when the image is flashed to target and 
booted it is reverted back to being a symlink; I assume by some init script?


Can anyone shed any light on what more is required to get a persistent log 
directory.


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

Re: [OE-core] meta/lib/oe/rootfs.py: dont' remove any packages by default

[Jack Mitchell]

On 31/07/15 11:46, Paul Eggleton wrote:

Hi Robert,

On Friday 31 July 2015 14:56:15 Robert Yang wrote:

Currently, the rootfs.py removes base-passwd, shadow, update-rc.d,
update-alternatives and run-postinsts when package-management not
in IMAGE_FEATURES, this causes two problems:

1) This makes we can't install the removed pkgs to rootfs, such as
 IMAGE_INSTALL_append =  shadow, the shadow can't installed (first
 installed, then removed)

2) The base-passwd has been removed, but the /etc/passwd and /etc/group
 are still existed since they are generated by preinst, this would
 confuse the user, and we can't add a postuninst to remove /etc/passwd
 and /etc/group since they are required when runtime.

I think that we should not remove any pkgs by default, we can add some
interfaces/ways to let the user decide whether to remove them or any
other pkgs, for example, add a REMOVE_PACKAGS variable, leave it as NULL
or only add run-postinsts to it by default.

There is a reason for these not to be there by default when you don't have
runtime package management - the assumption is you won't be adding or removing
any users, thus the binaries that those packages install aren't needed.

Now, it might be argued that if for example you're using some non-package-
management based application installation mechanism that has per-application
users (Android does this) you will need to add and remove users and therefore
you do still need those tools, in which case we would probably need a
mechanism for preventing the removal of those packages. I'm not sure whether
that would be an IMAGE_FEATURES item (e.g. user-management), or perhaps we
just make this code get the value of a variable specifying the list of
packages to remove instead of it being hardcoded as it is now. Either way
though I think the default behaviour does make sense for most people and I
don't think we ought to be changing that part.

Cheers,
Paul


Recently I tried (and failed) to add update-rc.d to my image so I could 
disable/enable init scripts easily and this explains why. I don't know 
what to do about it, but I don't have package management however I would 
like update-rc.d, so I second that something needs to be done to allow 
exceptions or overrides.


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

Re: [OE-core] SDK extract errors on master

[Jack Mitchell]

On 03/07/15 15:56, Jack Mitchell wrote:
Built an SDK today on 7eb0abc5f4d971d9a511c93cfb2eb52b72e6f228 and 
when I tried to install it I got the following error:


Setting it up...ls: cannot access 
/home/jack/Work/build/openembedded/sdk/1/x86_64/environment-setup-*: 
No such file or directory


I have been messing about with the SDK install path and at one point 
it did spew out a load of files installed vs shipped warnings I assume 
due to a change of path and it getting upset about it, but since then 
I deleted the tmp directory and rebuilt a new SDK without warnings. 
However, both acted in the same way.


The SDK then sits without installing, seemingly stuck on: grep 
OECORE_NATIVE_SYSROOT, which I assume means it's looking for the 
(non-existant) environment file.


Any clues? Is this broken for anyone else?

Cheers,
Jack.


Ok, I figured out how I broke it; I used a relative path in SDKPATH. i.e.

SDKPATH=/path/to/sdk/../rel-sdk

So, first off; should this be supported? Secondly, the use-case I was 
trying to get at was to position an SDK relative to the build dir, i.e.


SDKPATH=${TOPDIR}/../sdk

Is there a better way to do this. I guess this problem could be solved 
somewhere in an SDK class by changing the relative path to an absolute 
path. Ideas?


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

Re: [OE-core] SDK extract errors on master

[Jack Mitchell]

On 06/07/15 12:35, Jack Mitchell wrote:

On 03/07/15 15:56, Jack Mitchell wrote:
Built an SDK today on 7eb0abc5f4d971d9a511c93cfb2eb52b72e6f228 and 
when I tried to install it I got the following error:


Setting it up...ls: cannot access 
/home/jack/Work/build/openembedded/sdk/1/x86_64/environment-setup-*: 
No such file or directory


I have been messing about with the SDK install path and at one point 
it did spew out a load of files installed vs shipped warnings I 
assume due to a change of path and it getting upset about it, but 
since then I deleted the tmp directory and rebuilt a new SDK without 
warnings. However, both acted in the same way.


The SDK then sits without installing, seemingly stuck on: grep 
OECORE_NATIVE_SYSROOT, which I assume means it's looking for the 
(non-existant) environment file.


Any clues? Is this broken for anyone else?

Cheers,
Jack.


Ok, I figured out how I broke it; I used a relative path in SDKPATH. i.e.

SDKPATH=/path/to/sdk/../rel-sdk

So, first off; should this be supported? Secondly, the use-case I was 
trying to get at was to position an SDK relative to the build dir, i.e.


SDKPATH=${TOPDIR}/../sdk

Is there a better way to do this. I guess this problem could be solved 
somewhere in an SDK class by changing the relative path to an absolute 
path. Ideas?


Cheers,
Jack.


I found an ugly work-around but it would be nice for this to be 
supported in the future, or at least error on a relative path.


SDKPATH := ${@os.path.abspath(d.getVar('TOPDIR', 
True)+/../sdk/+d.getVar('SDK_VERSION', True)+/+d.getVar('SDK_ARCH', 
True))}


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

Re: [OE-core] SDK extract errors on master

[Jack Mitchell]

On 06/07/15 16:56, Jack Mitchell wrote:

On 06/07/15 13:30, Jack Mitchell wrote:

On 06/07/15 12:35, Jack Mitchell wrote:

On 03/07/15 15:56, Jack Mitchell wrote:
Built an SDK today on 7eb0abc5f4d971d9a511c93cfb2eb52b72e6f228 and 
when I tried to install it I got the following error:


Setting it up...ls: cannot access 
/home/jack/Work/build/openembedded/sdk/1/x86_64/environment-setup-*: No 
such file or directory


I have been messing about with the SDK install path and at one 
point it did spew out a load of files installed vs shipped warnings 
I assume due to a change of path and it getting upset about it, but 
since then I deleted the tmp directory and rebuilt a new SDK 
without warnings. However, both acted in the same way.


The SDK then sits without installing, seemingly stuck on: grep 
OECORE_NATIVE_SYSROOT, which I assume means it's looking for the 
(non-existant) nvironment file.


Any clues? Is this broken for anyone else?

Cheers,
Jack.


Ok, I figured out how I broke it; I used a relative path in SDKPATH. 
i.e.


SDKPATH=/path/to/sdk/../rel-sdk

So, first off; should this be supported? Secondly, the use-case I 
was trying to get at was to position an SDK relative to the build 
dir, i.e.


SDKPATH=${TOPDIR}/../sdk

Is there a better way to do this. I guess this problem could be 
solved somewhere in an SDK class by changing the relative path to an 
absolute path. Ideas?


Cheers,
Jack.


I found an ugly work-around but it would be nice for this to be 
supported in the future, or at least error on a relative path.


SDKPATH := ${@os.path.abspath(d.getVar('TOPDIR', 
True)+/../sdk/+d.getVar('SDK_VERSION', 
True)+/+d.getVar('SDK_ARCH', True))}


Cheers,


The saga continues... so, using a relative path is what causes bitbake 
to spew the 'installed vs shipped' warnings; which I thought were the 
root cause of the SDK failing to install, but apparently not. I'm 
appending a custom recipe like this:


TOOLCHAIN_HOST_TASK += nativesdk-fastboot

Which seems to be the root cause of the SDK failing to install. I have 
grepped the output of bitbake -e image -c populate_sdk and I get:


TOOLCHAIN_HOST_TASK=nativesdk-packagegroup-sdk-host 
packagegroup-cross-canadian-diffusion nativesdk-fastboot


Which looks perfectly reasonable to me; the fastboot recipe also 
builds without issue and the resulting package looks sane. So, why is 
this breaking the SDK and causing other packages not to be installed, 
it looks specifically like it nullifies the 
packagegroup-cross-canadian-diffusion as that is what brings in 
meta-environment and as such environment-setup-* which is what is 
claimed to be missing on SDK extract.


I'm totally out of my depth now as on the surface everything looks OK. 
Any input would be much appreciated.


Cheers,



Turns out it's one of the magic variables that requires an _append 
rather than just a +=.


The example above turns out to be from my tests using _append and I 
didn't realise it was different with just a plain +=.


To conclude, TOOLCHAIN_HOST_TASK += nativesdk-package will overwrite 
TOOLCHAIN_HOST_TASK to just hold nativesdk-package, as such 
nativesdk-packagegroup-sdk-host and 
packagegroup-cross-canadian-diffusion won't be present anymore which 
makes a whole lot of sense now. Using append, like so:


TOOLCHAIN_HOST_TASK_append += nativesdk-fastboot

Will give you the whole list and result in:

TOOLCHAIN_HOST_TASK=nativesdk-packagegroup-sdk-host 
packagegroup-cross-canadian-diffusion nativesdk-fastboot


Which is correct. Sorry for the noise; but just a heads up that I now 
feel strongly that this should be in the Yocto Docs somewhere, there is 
no mention of extending the SDK at all from what I could see and current 
examples found online specify just a plain += is fine to use, which it 
isn't.

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

Re: [OE-core] SDK extract errors on master

[Jack Mitchell]

On 06/07/15 13:30, Jack Mitchell wrote:

On 06/07/15 12:35, Jack Mitchell wrote:

On 03/07/15 15:56, Jack Mitchell wrote:
Built an SDK today on 7eb0abc5f4d971d9a511c93cfb2eb52b72e6f228 and 
when I tried to install it I got the following error:


Setting it up...ls: cannot access 
/home/jack/Work/build/openembedded/sdk/1/x86_64/environment-setup-*: 
No such file or directory


I have been messing about with the SDK install path and at one point 
it did spew out a load of files installed vs shipped warnings I 
assume due to a change of path and it getting upset about it, but 
since then I deleted the tmp directory and rebuilt a new SDK without 
warnings. However, both acted in the same way.


The SDK then sits without installing, seemingly stuck on: grep 
OECORE_NATIVE_SYSROOT, which I assume means it's looking for the 
(non-existant) nvironment file.


Any clues? Is this broken for anyone else?

Cheers,
Jack.


Ok, I figured out how I broke it; I used a relative path in SDKPATH. 
i.e.


SDKPATH=/path/to/sdk/../rel-sdk

So, first off; should this be supported? Secondly, the use-case I was 
trying to get at was to position an SDK relative to the build dir, i.e.


SDKPATH=${TOPDIR}/../sdk

Is there a better way to do this. I guess this problem could be 
solved somewhere in an SDK class by changing the relative path to an 
absolute path. Ideas?


Cheers,
Jack.


I found an ugly work-around but it would be nice for this to be 
supported in the future, or at least error on a relative path.


SDKPATH := ${@os.path.abspath(d.getVar('TOPDIR', 
True)+/../sdk/+d.getVar('SDK_VERSION', 
True)+/+d.getVar('SDK_ARCH', True))}


Cheers,


The saga continues... so, using a relative path is what causes bitbake 
to spew the 'installed vs shipped' warnings; which I thought were the 
root cause of the SDK failing to install, but apparently not. I'm 
appending a custom recipe like this:


TOOLCHAIN_HOST_TASK += nativesdk-fastboot

Which seems to be the root cause of the SDK failing to install. I have 
grepped the output of bitbake -e image -c populate_sdk and I get:


TOOLCHAIN_HOST_TASK=nativesdk-packagegroup-sdk-host 
packagegroup-cross-canadian-diffusion nativesdk-fastboot


Which looks perfectly reasonable to me; the fastboot recipe also builds 
without issue and the resulting package looks sane. So, why is this 
breaking the SDK and causing other packages not to be installed, it 
looks specifically like it nullifies the 
packagegroup-cross-canadian-diffusion as that is what brings in 
meta-environment and as such environment-setup-* which is what is 
claimed to be missing on SDK extract.


I'm totally out of my depth now as on the surface everything looks OK. 
Any input would be much appreciated.


Cheers,

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

[OE-core] SDK extract errors on master

[Jack Mitchell]

Built an SDK today on 7eb0abc5f4d971d9a511c93cfb2eb52b72e6f228 and when 
I tried to install it I got the following error:


Setting it up...ls: cannot access 
/home/jack/Work/build/openembedded/sdk/1/x86_64/environment-setup-*: No 
such file or directory


I have been messing about with the SDK install path and at one point it 
did spew out a load of files installed vs shipped warnings I assume due 
to a change of path and it getting upset about it, but since then I 
deleted the tmp directory and rebuilt a new SDK without warnings. 
However, both acted in the same way.


The SDK then sits without installing, seemingly stuck on: grep 
OECORE_NATIVE_SYSROOT, which I assume means it's looking for the 
(non-existant) environment file.


Any clues? Is this broken for anyone else?

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

[OE-core] subversion configure failure

[Jack Mitchell]

Seems to be some sort of python script failure? Is anyone else seeing 
this? I've dug around a little but can't see anything obvious.


Cheers,
Jack

Attached(2)
DEBUG: Executing python function sysroot_cleansstate
DEBUG: Python function sysroot_cleansstate finished
DEBUG: Executing shell function autotools_preconfigure
DEBUG: Shell function autotools_preconfigure finished
DEBUG: Executing python function autotools_copy_aclocals
DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64', 
'x86_64-linux', 'common']
DEBUG: Python function autotools_copy_aclocals finished
DEBUG: Executing shell function do_configure
automake (GNU automake) 1.15
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later 
http://gnu.org/licenses/gpl-2.0.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey tro...@redhat.com
   and Alexandre Duret-Lutz a...@gnu.org.
AUTOV is 1
NOTE: Executing ACLOCAL=aclocal 
--system-acdir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/work/x86_64-linux/subversion-native/1.8.13-r0/build/aclocal-copy/
 autoreconf --verbose --install --force --exclude=autopoint -I build/ -I 
build/ac-macros/
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal 
--system-acdir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/work/x86_64-linux/subversion-native/1.8.13-r0/build/aclocal-copy/
 -I build/ -I build/ac-macros/ -I build/ -I build/ac-macros/ --force 
build/ac-macros/zlib.m4:26: warning: underquoted definition of SVN_LIB_Z
build/ac-macros/zlib.m4:26:   run info Automake 'Extending aclocal'
build/ac-macros/zlib.m4:26:   or see 
http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build'.
libtoolize: copying file 'build/ltmain.sh'
libtoolize: Remember to add 'LT_INIT' to configure.ac.
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
build/ac-macros/zlib.m4:26: warning: underquoted definition of SVN_LIB_Z
build/ac-macros/zlib.m4:26:   run info Automake 'Extending aclocal'
build/ac-macros/zlib.m4:26:   or see 
http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
autoreconf: running: 
/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr/bin/autoconf
 --include=build/ --include=build/ac-macros/ --force
autoreconf: running: 
/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr/bin/autoheader
 --include=build/ --include=build/ac-macros/ --force
autoreconf: configure.ac: not using Automake
autoreconf: running: gnu-configize
autoreconf: Leaving directory `.'
NOTE: Running 
/home/jack/Work/oe-core.git/test-build/tmp-glibc/work/x86_64-linux/subversion-native/1.8.13-r0/subversion-1.8.13/configure
  --build=x86_64-linux--host=x86_64-linux 
--target=x86_64-linux   
--prefix=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr
 
--exec_prefix=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr

--bindir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr/bin
 
--sbindir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr/sbin
   
--libexecdir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr/lib/subversion
  
--datadir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr/share
  
--sysconfdir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/etc
 
--sharedstatedir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/com
 
--localstatedir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/var
  
--libdir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr/lib
 
--includedir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr/include
 
--oldincludedir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr/include
  
--infodir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr/share/info
 
--mandir=/home/jack/Work/oe-core.git/test-build/tmp-glibc/sysroots/x86_64-linux/usr/share/man
   --disable-silent-rules  
--disable-dependency-tracking 
--without-berkeley-db --without-apxs --without-swig 

Re: [OE-core] [PATCH] alsa-tools: add dependency glib-2.0

[Jack Mitchell]

On 05/06/15 02:50, Kang Kai wrote:

On 2015年06月04日 17:23, Jack Mitchell wrote:

On 04/06/15 06:57, Kai Kang wrote:

Add dependency glib-2.0 for alsa-tools. It is required by new added
sub-component hdajacksensetest.

Signed-off-by: Kai Kang kai.k...@windriver.com
---
  meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb 
b/meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb

index 9133012..b5b9cc4 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb
+++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb
@@ -3,7 +3,7 @@ HOMEPAGE = http://www.alsa-project.org;
  BUGTRACKER = 
https://bugtrack.alsa-project.org/alsa-bug/login_page.php;

  SECTION = console/utils
  LICENSE = GPLv2  LGPLv2+
-DEPENDS = alsa-lib ncurses
+DEPENDS = alsa-lib ncurses glib-2.0
LIC_FILES_CHKSUM = 
file://hdsploader/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \

file://ld10k1/COPYING.LIB;md5=7fbc338309ac38fefcd64b04bb903e34


It would be nice to put this behind a hdajacksensetest packageconfig 
if possible.


The hdajacksensetest is just a sub-directory/component not a feature, 
and it can't be built without library glib.
If make it as a package config, we have to find a way to remove 
hdajacksensetes. I suppose it is not proper to

add it as a packageconfig.

BTW, the dependency on glib-2.0 for alsa-tools is passed by depending 
on gtk+3 if 'x11' in distro feauture. If without 'x11',
not such dependency, then build hdajacksensetest fails. So add 
'glib-2.0' to DEPENDS.


Thanks,



Ok, it's just quite a heavy dependancy for a package which is feasible 
to be installed on very small systems; as you have proved by glib-2.0 
not beiing available in a non-x11 build. In this case I guess the way 
round it would be to split out the alsa-tools packages, but that is also 
a lot of work. The patch is fine and I don't use alsa-tools so I have no 
strong feelings; I just like to keep and eye on and question bloat.


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

Re: [OE-core] [PATCH] alsa-tools: add dependency glib-2.0

[Jack Mitchell]

On 04/06/15 06:57, Kai Kang wrote:

Add dependency glib-2.0 for alsa-tools. It is required by new added
sub-component hdajacksensetest.

Signed-off-by: Kai Kang kai.k...@windriver.com
---
  meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb 
b/meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb
index 9133012..b5b9cc4 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb
+++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.29.bb
@@ -3,7 +3,7 @@ HOMEPAGE = http://www.alsa-project.org;
  BUGTRACKER = https://bugtrack.alsa-project.org/alsa-bug/login_page.php;
  SECTION = console/utils
  LICENSE = GPLv2  LGPLv2+
-DEPENDS = alsa-lib ncurses
+DEPENDS = alsa-lib ncurses glib-2.0
  
  LIC_FILES_CHKSUM = file://hdsploader/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \

  
file://ld10k1/COPYING.LIB;md5=7fbc338309ac38fefcd64b04bb903e34


It would be nice to put this behind a hdajacksensetest packageconfig if 
possible.

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

Re: [OE-core] [PATCH 1/5] bluez5: upgrade to 5.29

[Jack Mitchell]

On 03/04/2015 15:13, Cristian Iorga wrote:

- Large release with over a month and 475 commits since 5.28;
- Internal GATT library received lots of updates;
- Fix for AVCTP key repeat timeout;
- Added support for the Multi Profile Specification (MPS).

Signed-off-by: Cristian Iorga cristian.io...@intel.com
---
  meta/recipes-connectivity/bluez5/{bluez5_5.28.bb = bluez5_5.29.bb} | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
  rename meta/recipes-connectivity/bluez5/{bluez5_5.28.bb = bluez5_5.29.bb} 
(88%)

diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.28.bb 
b/meta/recipes-connectivity/bluez5/bluez5_5.29.bb
similarity index 88%
rename from meta/recipes-connectivity/bluez5/bluez5_5.28.bb
rename to meta/recipes-connectivity/bluez5/bluez5_5.29.bb
index e816998..0fe8e7f 100644
--- a/meta/recipes-connectivity/bluez5/bluez5_5.28.bb
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.29.bb
@@ -1,6 +1,6 @@
  require bluez5.inc
-SRC_URI[md5sum] = bc20a8285530758c68f6a60e4ca62a15
-SRC_URI[sha256sum] = 
85bab48f4b47a158739028682c1e09cf30099c8ea9dfe63360055f8e06fc18a9
+SRC_URI[md5sum] = aa9dc91689695a486c78c131cd68673e
+SRC_URI[sha256sum] = 
df216a6d5ec6133355e5d4ed6b5e7a188a940940d337374e166758513246f0e4

  # noinst programs in Makefile.tools that are conditional on READLINE
  # support



5.30 is available now I think
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] file: remove the original magic.h

[Jack Mitchell]

On 26/03/15 11:31, Junling Zheng wrote:

On 2015/3/26 17:54, Richard Purdie wrote:

On Thu, 2015-03-26 at 09:18 +, Junling Zheng wrote:

The magic.h under the src/ directory should be generated by magic.h.in
during compiling. However, if we modify the magic.h.in, we can find that
sometimes the magic.h would not be generated again, and then we use the
original one which is not correct. So remove the original magic.h.

Signed-off-by: Junling Zheng zhengjunl...@huawei.com
---
  meta/recipes-devtools/file/file_5.22.bb | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/meta/recipes-devtools/file/file_5.22.bb 
b/meta/recipes-devtools/file/file_5.22.bb
index 9c6bb38..f4ee31b 100644
--- a/meta/recipes-devtools/file/file_5.22.bb
+++ b/meta/recipes-devtools/file/file_5.22.bb
@@ -22,6 +22,12 @@ inherit autotools
  
  FILES_${PN} += ${datadir}/misc/*.mgc
  
+do_configure_prepend() {

+   if test -f ${B}/src/magic.h; then
+   rm -rf ${B}/src/magic.h
+   fi
+}
+

If the task checksums change, ${B} should get entirely wiped out with
recent releases of the build system (e.g. dizzy/fido/master). Which
version was this tested and found to be needed with?

Cheers,

Richard


This is tested in the Yocto 1.5 poky-dora-10.0.0, which uses the dora branch of 
oe-core.
But I don't know which version it is actually in oe-core. And I think all 
branches in
oe-core need this fix.

Should ${B} be replaced by ${S}? Although sometimes they're not the same:)

And I am puzzled why ${B} should be wiped out, and does it be replaced by any 
other variable
except ${S}?

Cheers,

Junling



Could this be related to my outstanding bug? There is definitely 
something odd going on around the file magic binary.


https://bugzilla.yoctoproject.org/show_bug.cgi?id=7232

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

Re: [OE-core] [PATCH 0/1] file: add wrapper to nativesdk-file

[Jack Mitchell]

On 11/10/14 10:07, Hongxu Jia wrote:
 The following changes since commit 0172cded27d73437784fe1578110937aede563eb:
 
   build-appliance-image: Update to dizzy head revision (2014-10-10 22:40:57 
 +0100)
 
 are available in the git repository at:
 
   git://git.pokylinux.org/poky-contrib hongxu/fix-nativesdk-file
   
 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-nativesdk-file
 
 Hongxu Jia (1):
   file: add wrapper to nativesdk-file
 
  meta/recipes-devtools/file/file_5.18.bb | 5 +
  1 file changed, 5 insertions(+)
 

With my most recent oe build I'm getting an error when trying to use
file from the SDK. My target machine is x86 and my SDK is x86_64.

Is anybody else seeing this?

[jmitchell@newvsbuild filetest]$ file test.txt

eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc,
1: Warning: offset `�
' invalid
/eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc,
1: Warning: type `�
  ' invalid
/eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc,
6: Warning: offset `Firmware v' invalid
/eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc,
6: Warning: type `Firmware v' invalid

..

/eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc,
1916: Warning: type `.' invalid

file: Size of
`/eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc'
3043460 is not a multiple of 248


-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] wget: use GnuTLS instead of OpenSSL

[Jack Mitchell]

So this error is still blocking my master build, any ideas?

On 04/07/14 10:08, Jack Mitchell wrote:
 Ross,

 I've just pulled this in today after being on holiday for a while and it
 causes a breakage on my system.

 | checking for libgnutls... no
 | configure: error: --with-ssl=gnutls was given, but GNUTLS is not
 available.
 | Configure failed. The contents of all config.log files follows to aid
 debugging

 log: http://ix.io/dfO

 I would have expected gnutls to have been pulled in through the depends
 but it obviously hasn't, or the system hasn't managed to find it...

 Any ideas?

 Cheers,

 On 16/06/14 11:52, Ross Burton wrote:
 OpenSSL has license complications and GnuTLS is preferred, so although the
 license complications don't impact wget use GnuTLS for consistency.

 Also add a recommendation on ca-certificates so that https: URLs work.

 Signed-off-by: Ross Burton ross.bur...@intel.com
 ---
  meta/recipes-extended/wget/wget.inc |7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

 diff --git a/meta/recipes-extended/wget/wget.inc 
 b/meta/recipes-extended/wget/wget.inc
 index a778bca..642d502 100644
 --- a/meta/recipes-extended/wget/wget.inc
 +++ b/meta/recipes-extended/wget/wget.inc
 @@ -3,15 +3,16 @@ HOMEPAGE = https://www.gnu.org/software/wget/;
  SECTION = console/network
  LICENSE = GPLv3
  LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
 -DEPENDS = openssl zlib libpcre
 +DEPENDS = gnutls zlib libpcre
  
  INC_PR = r16
  
  inherit autotools gettext texinfo update-alternatives
  
 -EXTRA_OECONF = --enable-ipv6 --with-libssl-prefix=${STAGING_DIR_HOST} \
 ---with-ssl=openssl --disable-rpath --disable-iri \
 +EXTRA_OECONF = --enable-ipv6 --with-ssl=gnutls --disable-rpath 
 --disable-iri \
  ac_cv_header_uuid_uuid_h=no
  
  ALTERNATIVE_${PN} = wget
  ALTERNATIVE_PRIORITY = 100
 +
 +RRECOMMENDS_${PN} += ca-certificates

 
 


-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] wget: use GnuTLS instead of OpenSSL

[Jack Mitchell]

config.log: http://ix.io/dr3

and yes, gnutls is being built, or at least it's in the work dir.

[jack@jackArch gnutls]$ pwd
/home/jack/Work/oe-core.git/test-build/tmp-eglibc/work/core2-32-oe-linux/gnutls
[jack@jackArch gnutls]$ ls
2.12.23-r8.4  3.2.13-r0  3.2.15-r0  3.3.5-r0
[jack@jackArch gnutls]$

On 17/07/14 12:33, Richard Purdie wrote:
 On Thu, 2014-07-17 at 12:06 +0100, Jack Mitchell wrote:
 So this error is still blocking my master build, any ideas?
 Share the config.log so we can see how the configure test is failing? Is
 gnutls actually built and in the sysroot or not?

 Cheers,

 Richard



-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 

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

Re: [OE-core] [PATCH] wget: use GnuTLS instead of OpenSSL

[Jack Mitchell]

Wait, that config.log is bad. It's from my build with the patch
reverted. Hold up I'll get the proper one out.

On 17/07/14 12:39, Jack Mitchell wrote:
 config.log: http://ix.io/dr3
 
 and yes, gnutls is being built, or at least it's in the work dir.
 
 [jack@jackArch gnutls]$ pwd
 /home/jack/Work/oe-core.git/test-build/tmp-eglibc/work/core2-32-oe-linux/gnutls
 [jack@jackArch gnutls]$ ls
 2.12.23-r8.4  3.2.13-r0  3.2.15-r0  3.3.5-r0
 [jack@jackArch gnutls]$
 
 On 17/07/14 12:33, Richard Purdie wrote:
 On Thu, 2014-07-17 at 12:06 +0100, Jack Mitchell wrote:
 So this error is still blocking my master build, any ideas?
 Share the config.log so we can see how the configure test is failing? Is
 gnutls actually built and in the sysroot or not?

 Cheers,

 Richard

 
 


-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] wget: use GnuTLS instead of OpenSSL

[Jack Mitchell]

Failed with gnutls config.log: http://ix.io/dr4

On 17/07/14 12:39, Jack Mitchell wrote:
 config.log: http://ix.io/dr3
 
 and yes, gnutls is being built, or at least it's in the work dir.
 
 [jack@jackArch gnutls]$ pwd
 /home/jack/Work/oe-core.git/test-build/tmp-eglibc/work/core2-32-oe-linux/gnutls
 [jack@jackArch gnutls]$ ls
 2.12.23-r8.4  3.2.13-r0  3.2.15-r0  3.3.5-r0
 [jack@jackArch gnutls]$
 
 On 17/07/14 12:33, Richard Purdie wrote:
 On Thu, 2014-07-17 at 12:06 +0100, Jack Mitchell wrote:
 So this error is still blocking my master build, any ideas?
 Share the config.log so we can see how the configure test is failing? Is
 gnutls actually built and in the sysroot or not?

 Cheers,

 Richard

 
 


-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] wget: use GnuTLS instead of OpenSSL

[Jack Mitchell]

On 16/06/14 11:52, Ross Burton wrote:
 OpenSSL has license complications and GnuTLS is preferred, so although the
 license complications don't impact wget use GnuTLS for consistency.
 
 Also add a recommendation on ca-certificates so that https: URLs work.
 
 Signed-off-by: Ross Burton ross.bur...@intel.com
 ---
  meta/recipes-extended/wget/wget.inc |7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)
 
 diff --git a/meta/recipes-extended/wget/wget.inc 
 b/meta/recipes-extended/wget/wget.inc
 index a778bca..642d502 100644
 --- a/meta/recipes-extended/wget/wget.inc
 +++ b/meta/recipes-extended/wget/wget.inc
 @@ -3,15 +3,16 @@ HOMEPAGE = https://www.gnu.org/software/wget/;
  SECTION = console/network
  LICENSE = GPLv3
  LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
 -DEPENDS = openssl zlib libpcre
 +DEPENDS = gnutls zlib libpcre
  
  INC_PR = r16
  
  inherit autotools gettext texinfo update-alternatives
  
 -EXTRA_OECONF = --enable-ipv6 --with-libssl-prefix=${STAGING_DIR_HOST} \
 ---with-ssl=openssl --disable-rpath --disable-iri \
 +EXTRA_OECONF = --enable-ipv6 --with-ssl=gnutls --disable-rpath 
 --disable-iri \
  ac_cv_header_uuid_uuid_h=no
  
  ALTERNATIVE_${PN} = wget
  ALTERNATIVE_PRIORITY = 100
 +
 +RRECOMMENDS_${PN} += ca-certificates
 

Ross,

I've just pulled this in today after being on holiday for a while and it
causes a breakage on my system.

| checking for libgnutls... no
| configure: error: --with-ssl=gnutls was given, but GNUTLS is not
available.
| Configure failed. The contents of all config.log files follows to aid
debugging

log: http://ix.io/dfO

I would have expected gnutls to have been pulled in through the depends
but it obviously hasn't, or the system hasn't managed to find it...

Any ideas?

Cheers,

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] My thoughts on the future of OE?

[Jack Mitchell]

On 02/05/14 14:47, Burton, Ross wrote:
 On 2 May 2014 14:00, Mike Looijmans mike.looijm...@topic.nl wrote:
 Just about fifteen minutes ago I was asked the question of Yay, I could
 build a complete image for the board from scratch. Now how do I create and
 run a HelloWorld application on it?
 
 Depending on context simply adding the tools-sdk dev-pkgs
 IMAGE_FEATURES is sufficient to build applications on the target, as
 long as it's for the hello world or iterative development approaches.
 Obviously a recipe would need to be written at some point but getting
 a toolchain in the image for development on the target is trivial.
 
 Ross
 

Or generating and installing the SDK, then develop - cross compile -
copy to target - run - rinse and repeat.

Then when working, update your applications recipe to point to the new
revision and have a clean production image pop out.

The pain points with this come when you want to use new libraries etc
and you have to do a rootfs + sdk rebuild and upgrade but in reality
these are few and far between.

Cheers,

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] OE/TSC monthly IRC meeting notes - Apr 1 2014

[Jack Mitchell]

On 01/04/2014 18:33, Trevor Woerner wrote:

Here are my notes from today's monthly OE/TSC meeting which takes place
the first Tuesday of every month on freenode's #oe channel.

attendees: bluelightning, Jefro, RP, denix, tlwoerner, fray, nerdboy,
kergoth

topic #1: upcoming release
- schedule: https://wiki.yoctoproject.org/wiki/Yocto_1.6_Schedule
- check RP's email
http://lists.openembedded.org/pipermail/openembedded-core/2014-April/091378.html
- test report for rc1 is available:
https://wiki.yoctoproject.org/wiki/WW13_-_2014-03-26_-_Full_Pass_Release_1.6_M5.rc1
- optimism for a good 1.6 release
- enhancements such as READMEs still being accepted
- bug fixes (such as work on SOBBW issues) still being accepted
- bug metrics showing downward trend:
https://wiki.yoctoproject.org/charts/combo.html

topic #2: SOBBW (state of bitbake world) or world build status
- http://www.openembedded.org/wiki/Bitbake_World_Status
- fixing items on the list still needs lots of help, helpers needs a way
to organize themselves to avoid duplication (email, wiki, irc, ...)
- one cause/issue is people sending patches then disappearing, lots of
unmaintained recipes
- possible solutions: meta-nonworking, blacklist.bbclass, smaller core
layer

topic #3: website infrastructure and updates
- at ELCE2013 plans were made for a new
http://www.openembedded.org/wiki/Main_Page
- no plans yet for OE wiki cleanup
- unfortunately the people working on this weren't available to provide
an update


Almost there, ka6sox thinks he has the solution for fixing the PHP 
issues we're having, spoke to him regarding it last week and he is on 
track to fix it when he gets back from working away from home.




open topics
- please make sure any requests for 1.7 are in bugzilla
- recipe style unification between OE and Yocto Project

action items:
- RP to look for remnants of BROKEN = 1 (?)
- fray to move blacklist issue forward with JaMa
- tlwoerner to sync style guides

next meeting: May 6th 2014, same time, same place


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

Re: [OE-core] [dylan] Backport request

[Jack Mitchell]

On 14/03/2014 18:57, Saul Wold wrote:

On 03/14/2014 11:34 AM, Paul Barker wrote:

I'm stuck using Dylan for a project as I need a 3.2 series kernel.
Building on my current development machine I ran into two failures:

eglibc-initial, do_configure: Make 4.0 isn't recognised

This can be fixed by backporting
a678243d6e4add90c1e9459da42de34d3724db5d (already in Dora).

linux-yocto_3.2: do_patch: Unsupported version of git (1.9.0)

I fixed this by removing git-native from ASSUME_PROVIDED in
meta/conf/bitbake.conf so that git-native-1.8.1.4 was built and used.
That isn't something we should commit in Dylan but may be useful for
others to know the solution if they run into the same problem.


Can't you use the buildtools tarball?  It includes the right version of
make and git.


Indeed, this is what I do on my ArchLinux machines when something is too 
new; it's just a simple sourcing of an environment file before the build 
and you're good to go.


Cheers,



Sau!


Thanks,


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

[OE-core] SDK Issues

[Jack Mitchell]

I recently did a new build of my images and SDKs under master
(b188bda18690dc1af) refreshing a 3 month old build. Now everything
builds fine, but when trying to build our in house software with the
SDK, the new SDK falls over citing issues failing to link with libdl. If
I think switch back to using the old SDK, everything builds without
issue. Can anybody think of anything which might have altered the SDK in
the past few months in order to cause this to break? I have done a quick
directory diff of the 2 SDKs and nothing radically different. GCC 4.81
- 4.82 and autotools 1.13  - 1.14 are probably the big changes. From
what I can see the command to build the application is linking with all
the correct libraries and as it builds with previous versions I would be
surprised if this was wrong. It also seems to be struggling with the
-lcrypto libraries, but it hits the libdl issue first so it may just be
a domino effect, or there could be a significant issue with the SDK
generation.

i586-oe-linux-gcc -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse
--sysroot=/scratch/jmitchell/oecore-sdk/1/sysroots/core2-32-oe-linux -I.
-I/scratch/jmitchell/code.git/net-snmp/../include -Wall -pipe  -rdynamic
-g -Wall -Wextra -Wl,--build-id -O2 -Wall -Wstrict-prototypes
-Wwrite-strings -Wcast-qual -Wno-char-subscripts -Dlinux -o .libs/snmpd
snmpd.o -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -rdynamic -rdynamic
 ./.libs/libucdagent.so ./.libs/libucdmibs.so -lwrap
../snmplib/.libs/libsnmp.so -lcrypto -ldl -lelf -ldl  -Wl,--rpath
-Wl,/scratch/jmitchell/code.git/net-snmp/../net-snmp/usr/lib
./.libs/libucdmibs.so: undefined reference to `dlopen'
../snmplib/.libs/libsnmp.so: undefined reference to `EVP_md5'
../snmplib/.libs/libsnmp.so: undefined reference to `EVP_sha1'
../snmplib/.libs/libsnmp.so: undefined reference to `RAND_bytes'
../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestInit'
./.libs/libucdmibs.so: undefined reference to `dlclose'
../snmplib/.libs/libsnmp.so: undefined reference to `DES_ncbc_encrypt'
../snmplib/.libs/libsnmp.so: undefined reference to `DES_cbc_encrypt'
../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestUpdate'
../snmplib/.libs/libsnmp.so: undefined reference to `HMAC'
../snmplib/.libs/libsnmp.so: undefined reference to `DES_key_sched'
./.libs/libucdmibs.so: undefined reference to `dlerror'
./.libs/libucdmibs.so: undefined reference to `dlsym'
../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestFinal'

Any light shed would be much appreciated!

Cheers,

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] SDK Issues

[Jack Mitchell]

On 17/02/14 10:49, Richard Purdie wrote:
 On Mon, 2014-02-17 at 10:44 +, Jack Mitchell wrote:
 I recently did a new build of my images and SDKs under master
 (b188bda18690dc1af) refreshing a 3 month old build. Now everything
 builds fine, but when trying to build our in house software with the
 SDK, the new SDK falls over citing issues failing to link with libdl. If
 I think switch back to using the old SDK, everything builds without
 issue. Can anybody think of anything which might have altered the SDK in
 the past few months in order to cause this to break? I have done a quick
 directory diff of the 2 SDKs and nothing radically different. GCC 4.81
 - 4.82 and autotools 1.13  - 1.14 are probably the big changes. From
 what I can see the command to build the application is linking with all
 the correct libraries and as it builds with previous versions I would be
 surprised if this was wrong. It also seems to be struggling with the
 -lcrypto libraries, but it hits the libdl issue first so it may just be
 a domino effect, or there could be a significant issue with the SDK
 generation.

 i586-oe-linux-gcc -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse
 --sysroot=/scratch/jmitchell/oecore-sdk/1/sysroots/core2-32-oe-linux -I.
 -I/scratch/jmitchell/code.git/net-snmp/../include -Wall -pipe  -rdynamic
 -g -Wall -Wextra -Wl,--build-id -O2 -Wall -Wstrict-prototypes
 -Wwrite-strings -Wcast-qual -Wno-char-subscripts -Dlinux -o .libs/snmpd
 snmpd.o -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -rdynamic -rdynamic
  ./.libs/libucdagent.so ./.libs/libucdmibs.so -lwrap
 ../snmplib/.libs/libsnmp.so -lcrypto -ldl -lelf -ldl  -Wl,--rpath
 -Wl,/scratch/jmitchell/code.git/net-snmp/../net-snmp/usr/lib
 ./.libs/libucdmibs.so: undefined reference to `dlopen'
 ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_md5'
 ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_sha1'
 ../snmplib/.libs/libsnmp.so: undefined reference to `RAND_bytes'
 ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestInit'
 ./.libs/libucdmibs.so: undefined reference to `dlclose'
 ../snmplib/.libs/libsnmp.so: undefined reference to `DES_ncbc_encrypt'
 ../snmplib/.libs/libsnmp.so: undefined reference to `DES_cbc_encrypt'
 ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestUpdate'
 ../snmplib/.libs/libsnmp.so: undefined reference to `HMAC'
 ../snmplib/.libs/libsnmp.so: undefined reference to `DES_key_sched'
 ./.libs/libucdmibs.so: undefined reference to `dlerror'
 ./.libs/libucdmibs.so: undefined reference to `dlsym'
 ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestFinal'

 Any light shed would be much appreciated!
 Binutils changed and we did see some occasional link issues with that.
 You could try the command without -Wl,--as-needed. If that helps, you
 have a library ordering issue which the new stricter binutils picked up.

 I'm just guessing mind but its worth a try...

 Cheers,

 Richard


Good shout, that seems to allow it to build; I didn't even realise
ordering of linker libs could effect the build. I guess I have some
reading to go do!

Cheers RP.

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 

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

[OE-core] [QA Issue] liblto found in wrong location

[Jack Mitchell]

WARNING: QA Issue: gcc-cross-canadian-i586: found library in wrong
location:
/opt/cbnl/oecore-sdk/1/sysroots/i686-oecore-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.8.2/liblto_plugin.so.0
gcc-cross-canadian-i586: found library in wrong location:
/opt/cbnl/oecore-sdk/1/sysroots/i686-oecore-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.8.2/liblto_plugin.so.0.0.0
gcc-cross-canadian-i586: found library in wrong location:
/opt/cbnl/oecore-sdk/1/sysroots/i686-oecore-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.8.2/liblto_plugin.so

It seems like the library is being found in an installed SDK on my host?
I have no idea where to start with this, the gcc-target.inc specifies it
in FILES, but apart from that I can't find any reference to it, maybe
due it being a core GCC lib?

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] bug scrub - RFC

[Jack Mitchell]

On 08/01/14 23:20, Trevor Woerner wrote:
 Hi everyone,
 
 This is a Request For Comments email regarding a bug scrub party the
 OE TSC would like to hold.
 
 
 background:
 It has been noticed that the number of bugs in the bugzilla[1] has been
 climbing; it would be nice to hold a bug scrub event to raise
 awareness of the bugzilla and hopefully get some issues resolved.
 
 
 questions:
 1) Currently it has been suggested this should be a 2-day event, should
 these two days be during the week or over a weekend? In either case,
 which 2 days?
 

If it's two days long then why don't you do the best of both worlds and
have a Friday/Saturday or Sunday/Monday combination?

 2) Since this is an OE event, should it focus only on OE bugs[2], or
 should it be generalized for any bug?

I don't think we should be limiting people to what they can work on
while participating.

 
 3) Should we create a sign-up sheet (wiki) to keep track of who is
 participating, and which issues are being looked at by whom?
 
 (anything else?)

I think maybe a I will be there at some point for some amount of time
column would be good, and maybe a place to register interest for certain
bugs or areas of code that need improvement.

 
 
 notes:
 1) If you or the company for which you work uses OE/Yocto, please
 consider making this a company event and having/allowing the engineers
 (to) participate.
 
 2) Even if you're not a recipe-, or a build-, or a python-wizard there
 are still many things you can do to contribute. Being able to reproduce
 a bug or reporting that a bug can't be reproduced can sometimes be quite
 helpful (sometimes this points to a host issue or to a bug's description
 not being descriptive enough). Sometimes a bug is stuck in the needs
 info stage which maybe you can provide.

People with different environments is always useful, either bleeding
edge or very stable. Variety is the spice of life ;)

 
 3) Can anyone think of way to help get the word out?
 
 4) It would be cool to be able to provide incentives to help people get
 interested and contributing to knocking some bugs around. So if anyone
 (*cough* Intel) has any neat hardware (*cough* Galileo, Edison) they
 could offer as an incentive (or, conversely, if there's a board you'd
 like to see Yocto target) please see about making that happen.
 

A unified effort towards a new trendy board would be a fun goal, but I
worry that hardware teething issues would then eat up run of the mill
bug fixing time, handouts for participation however, (bug fixed/reviewed
by/tested by) would be a great idea.

 
 Thanks and best regards,
 Trevor
 
 
 
 [1] https://bugzilla.yoctoproject.org
 [2]
 https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ACCEPTEDbug_status=IN%20PROGRESS%20DESIGNbug_status=IN%20PROGRESS%20DESIGN%20COMPLETEbug_status=IN%20PROGRESS%20IMPLEMENTATIONbug_status=IN%20PROGRESS%20REVIEWbug_status=REOPENEDbug_status=NEEDINFObug_status=WaitForUpstreamclassification=Build%20System%20%26%20Metadatalist_id=156074product=OE-Corequery_format=advancedresolution=---order=bug_id%20DESCquery_based_on=
 

Cheers,

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] db compile failure

[Jack Mitchell]

On latest master I am running into the following failure:

http://ix.io/9Kh

I'm also getting a _lot_ of warnings like these:

WARNING: The recipe eglibc-locale is trying to install files into a
shared area when those files already exist. Those files and their
manifest location are:

/home/jack/Work/oe-core.git/test-build/tmp-eglibc/deploy/ipk/core2/eglibc-localedata-el-gr_2.18-r0_core2.ipk
   Matched in manifest-core2-eglibc-locale.deploy-ipk

/home/jack/Work/oe-core.git/test-build/tmp-eglibc/deploy/ipk/core2/eglibc-binary-localedata-wae-ch_2.18-r0_core2.ipk

Can anyone shed any light, it seems as though the something is getting
it's wires crossed somewhere...

I haven't yet tried wiping the tmp folder but I could as a last resort.

Cheers,

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] db compile failure

[Jack Mitchell]

On 08/01/14 14:16, Jack Mitchell wrote:
 On latest master I am running into the following failure:
 
 http://ix.io/9Kh

This should be the following link:

http://ix.io/9Ki

 
 I'm also getting a _lot_ of warnings like these:
 
 WARNING: The recipe eglibc-locale is trying to install files into a
 shared area when those files already exist. Those files and their
 manifest location are:
 
 /home/jack/Work/oe-core.git/test-build/tmp-eglibc/deploy/ipk/core2/eglibc-localedata-el-gr_2.18-r0_core2.ipk
Matched in manifest-core2-eglibc-locale.deploy-ipk
 
 /home/jack/Work/oe-core.git/test-build/tmp-eglibc/deploy/ipk/core2/eglibc-binary-localedata-wae-ch_2.18-r0_core2.ipk
 
 Can anyone shed any light, it seems as though the something is getting
 it's wires crossed somewhere...
 
 I haven't yet tried wiping the tmp folder but I could as a last resort.
 
 Cheers,
 


-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] db failure due to libstdc++.so host contamination

[Jack Mitchell]

do_compile.log: http://ix.io/9Ki

Speaking on IRC it seems that host systems with /usr/lib/libstdc++.so
present are failing to build db.

/usr/lib/libstdc++.so is present on at least archlinux in the gcc-libs
and gcc-multilibs package which is a fairly standard package to have
installed. The problem has appeared since commit
a484b35b818768487ff27cf06b8c5d4e128126af in oe-core.

Will try and find some time to do more debugging but if anyone sees any
tell tale signs then shout up.

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Status for Sponsored by git tags

[Jack Mitchell]

On 03/12/13 17:21, Bruce Ashfield wrote:
 On Tue, Dec 3, 2013 at 11:55 AM, Henning Heinold
 hein...@inf.fu-berlin.de wrote:
 On Tue, Dec 03, 2013 at 11:43:41AM -0500, Philip Balister wrote:
 On 12/03/2013 11:08 AM, Henning Heinold wrote:
 Hi,

 how is the status about using Sponsored by git tags. Do we want something
 like that in openemebdded or not?

 What are SPonsored by tags?

 Philip


 Hi Philip,

 Sponsored By tags are used by freebsd and some other projects to show which 
 company
 sponsored the commit
 
 Urk. Of the top of my head .. that just looks nasty. Signed-off-by:
 already indicates
 a company name, so going further than that is overkill IMHO.
 
 Bruce
 ..


Indeed, domain addresses in emails usually give the sponsor of the
work. No need for more bureaucracy.

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] shadow-native: allow for setting password in clear text

[Jack Mitchell]

On 25/11/13 03:03, ChenQi wrote:
 ping
 
 On 11/16/2013 03:37 PM, qi.c...@windriver.com wrote:
 From: Chen Qi qi.c...@windriver.com

 The following changes since commit
 ea92671d9823e3667d6ced7ac2af20f991da404d:

bitbake: cooker: replace w file opening mode with a mode
 (2013-11-12 17:01:37 +)

 are available in the git repository at:

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


 Chen Qi (1):
shadow-native: allow for setting password in clear text

   .../allow-for-setting-password-in-clear-text.patch |  208
 
   meta/recipes-extended/shadow/shadow.inc|1 +
   2 files changed, 209 insertions(+)
   create mode 100644
 meta/recipes-extended/shadow/files/allow-for-setting-password-in-clear-text.patch



Could you provide a short example for how this is to be used? An
additional patch to user-add in meta-skeleton perhaps?

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv5] libjson: update to 0.11 and rename to json-c

[Jack Mitchell]

From: Jack Mitchell jmitch...@cbnl.com

libjson is now known as json-c. Config.sub is removed as it breaks
seperate build dir builds. Built without parallel make as it fails,
official word is not to bother trying.

Signed-off-by: Jack Mitchell jmitch...@cbnl.com
---
 meta/conf/distro/include/seperatebuilddir.inc |  2 +-
 meta/recipes-devtools/json-c/json-c_0.11.bb   | 20 
 meta/recipes-devtools/libjson/libjson_0.9.bb  | 14 --
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc |  2 +-
 4 files changed, 22 insertions(+), 16 deletions(-)
 create mode 100644 meta/recipes-devtools/json-c/json-c_0.11.bb
 delete mode 100644 meta/recipes-devtools/libjson/libjson_0.9.bb

diff --git a/meta/conf/distro/include/seperatebuilddir.inc 
b/meta/conf/distro/include/seperatebuilddir.inc
index c067183..e1a5c6b 100644
--- a/meta/conf/distro/include/seperatebuilddir.inc
+++ b/meta/conf/distro/include/seperatebuilddir.inc
@@ -294,7 +294,7 @@ B_pn-libice = ${SEPB}
 B_pn-libice-native = ${SEPB}
 B_pn-libid3tag = ${SEPB}
 B_pn-libidn = ${SEPB}
-B_pn-libjson = ${SEPB}
+B_pn-json-c = ${SEPB}
 B_pn-libksba = ${SEPB}
 B_pn-libmad = ${SEPB}
 B_pn-libmatchbox = ${SEPB}
diff --git a/meta/recipes-devtools/json-c/json-c_0.11.bb 
b/meta/recipes-devtools/json-c/json-c_0.11.bb
new file mode 100644
index 000..4a75ed5
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_0.11.bb
@@ -0,0 +1,20 @@
+SUMMARY = JSON-C implements a reference counting object model that allows you 
to easily construct JSON objects in C
+HOMEPAGE = https://github.com/json-c/json-c/wiki;
+LICENSE = MIT
+LIC_FILES_CHKSUM = file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2
+
+SRC_URI = https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;
+
+SRC_URI[md5sum] = aa02367d2f7a830bf1e3376f77881e98
+SRC_URI[sha256sum] = 
28dfc65145dc0d4df1dfe7701ac173c4e5f9347176c8983edbfac9149494448c
+
+RPROVIDES_${PN} = libjson
+
+PARALLEL_MAKE = 
+
+inherit autotools
+
+do_configure_prepend() {
+# Clean up autoconf cruft that should noe be in the tarball
+rm ${S}/config.status
+}
diff --git a/meta/recipes-devtools/libjson/libjson_0.9.bb 
b/meta/recipes-devtools/libjson/libjson_0.9.bb
deleted file mode 100644
index e4951a8..000
--- a/meta/recipes-devtools/libjson/libjson_0.9.bb
+++ /dev/null
@@ -1,14 +0,0 @@
-DESCRIPTION = JSON-C - A JSON implementation in C
-HOMEPAGE = http://oss.metaparadigm.com/json-c/;
-
-LICENSE = MIT
-LIC_FILES_CHKSUM = file://COPYING;md5=30a276a476b02c2dcd0849bde417fb17
-
-SRC_URI = http://oss.metaparadigm.com/json-c/json-c-${PV}.tar.gz;
-SRC_URI[md5sum] = 3a13d264528dcbaf3931b0cede24abae
-SRC_URI[sha256sum] = 
702a486c9bf8e19137d484ab5c49b4ad314eb5e1fe37062a72c0a0fa39439475
-
-S = ${WORKDIR}/json-c-${PV}
-
-
-inherit autotools
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index bb13f4b..7e87ef8 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
file://GPL;md5=4325afd396febcb659c36b49533135d4 \
 DEPENDS = libatomics-ops liboil libsamplerate0 libsndfile1 libtool
 # optional
 DEPENDS += udev alsa-lib glib-2.0 dbus gconf
-DEPENDS += libjson gdbm speex libxml-parser-perl-native
+DEPENDS += json-c gdbm speex libxml-parser-perl-native
 
 inherit autotools pkgconfig useradd gettext perlnative
 
-- 
1.8.4.2

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

[OE-core] [PATCHv6] libjson: update to 0.11 and rename to json-c

[Jack Mitchell]

From: Jack Mitchell jmitch...@cbnl.com

libjson is now known as json-c. Config.status is removed as it breaks
seperate build dir builds. Built without parallel make as it fails,
official word is not to bother trying.

Signed-off-by: Jack Mitchell jmitch...@cbnl.com
---
 
 v6: correct commit message

 meta/conf/distro/include/seperatebuilddir.inc |  2 +-
 meta/recipes-devtools/json-c/json-c_0.11.bb   | 20 
 meta/recipes-devtools/libjson/libjson_0.9.bb  | 14 --
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc |  2 +-
 4 files changed, 22 insertions(+), 16 deletions(-)
 create mode 100644 meta/recipes-devtools/json-c/json-c_0.11.bb
 delete mode 100644 meta/recipes-devtools/libjson/libjson_0.9.bb

diff --git a/meta/conf/distro/include/seperatebuilddir.inc 
b/meta/conf/distro/include/seperatebuilddir.inc
index c067183..e1a5c6b 100644
--- a/meta/conf/distro/include/seperatebuilddir.inc
+++ b/meta/conf/distro/include/seperatebuilddir.inc
@@ -294,7 +294,7 @@ B_pn-libice = ${SEPB}
 B_pn-libice-native = ${SEPB}
 B_pn-libid3tag = ${SEPB}
 B_pn-libidn = ${SEPB}
-B_pn-libjson = ${SEPB}
+B_pn-json-c = ${SEPB}
 B_pn-libksba = ${SEPB}
 B_pn-libmad = ${SEPB}
 B_pn-libmatchbox = ${SEPB}
diff --git a/meta/recipes-devtools/json-c/json-c_0.11.bb 
b/meta/recipes-devtools/json-c/json-c_0.11.bb
new file mode 100644
index 000..831f281
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_0.11.bb
@@ -0,0 +1,20 @@
+SUMMARY = JSON-C implements a reference counting object model that allows you 
to easily construct JSON objects in C
+HOMEPAGE = https://github.com/json-c/json-c/wiki;
+LICENSE = MIT
+LIC_FILES_CHKSUM = file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2
+
+SRC_URI = https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;
+
+SRC_URI[md5sum] = aa02367d2f7a830bf1e3376f77881e98
+SRC_URI[sha256sum] = 
28dfc65145dc0d4df1dfe7701ac173c4e5f9347176c8983edbfac9149494448c
+
+RPROVIDES_${PN} = libjson
+
+PARALLEL_MAKE = 
+
+inherit autotools
+
+do_configure_prepend() {
+# Clean up autoconf cruft that should not be in the tarball
+rm ${S}/config.status
+}
diff --git a/meta/recipes-devtools/libjson/libjson_0.9.bb 
b/meta/recipes-devtools/libjson/libjson_0.9.bb
deleted file mode 100644
index e4951a8..000
--- a/meta/recipes-devtools/libjson/libjson_0.9.bb
+++ /dev/null
@@ -1,14 +0,0 @@
-DESCRIPTION = JSON-C - A JSON implementation in C
-HOMEPAGE = http://oss.metaparadigm.com/json-c/;
-
-LICENSE = MIT
-LIC_FILES_CHKSUM = file://COPYING;md5=30a276a476b02c2dcd0849bde417fb17
-
-SRC_URI = http://oss.metaparadigm.com/json-c/json-c-${PV}.tar.gz;
-SRC_URI[md5sum] = 3a13d264528dcbaf3931b0cede24abae
-SRC_URI[sha256sum] = 
702a486c9bf8e19137d484ab5c49b4ad314eb5e1fe37062a72c0a0fa39439475
-
-S = ${WORKDIR}/json-c-${PV}
-
-
-inherit autotools
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index bb13f4b..7e87ef8 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
file://GPL;md5=4325afd396febcb659c36b49533135d4 \
 DEPENDS = libatomics-ops liboil libsamplerate0 libsndfile1 libtool
 # optional
 DEPENDS += udev alsa-lib glib-2.0 dbus gconf
-DEPENDS += libjson gdbm speex libxml-parser-perl-native
+DEPENDS += json-c gdbm speex libxml-parser-perl-native
 
 inherit autotools pkgconfig useradd gettext perlnative
 
-- 
1.8.4.2

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

Re: [OE-core] [PATCHv5] libjson: update to 0.11 and rename to json-c

[Jack Mitchell]

On 18/11/13 16:10, Jack Mitchell wrote:
 From: Jack Mitchell jmitch...@cbnl.com
 
 libjson is now known as json-c. Config.sub is removed as it breaks
 seperate build dir builds. Built without parallel make as it fails,
 official word is not to bother trying.
 

[snip]

v6 incoming with correct commit message and comment typo fixed.

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv4] libjson: update to 0.11 and rename to json-c

[Jack Mitchell]

On 08/11/2013 00:47, Saul Wold wrote:

On 11/07/2013 07:59 AM, Jack Mitchell wrote:

From: Jack Mitchell jmitch...@cbnl.com

libjson is now known as json-c, support for the old namespace is
disabled as it seems to break SEPBUILDDIR configs. Built without
parallel make as it fails, official word is not to bother trying.

Signed-off-by: Jack Mitchell jmitch...@cbnl.com
---

  v4:
   - add --disable-oldname-compat to try and fix suspected SEPBUILDDIR
 issues



Jack,

I hate to ask this, but given this version is also failing, how have you
been testing this recipe?


Just the usual way, standard x86 atom target -c cleansstate and a build 
+ build -c populate_sdk. It also gets rebuilt without a clean sstate as 
I've been holding this patch in my working tree for weeks now.


I don't really know where to go with this now, I was sure it was going 
to be the compat configure functons which were breaking things, but 
obviously not. I'll see if I can find some time to tidy up the actual 
configure script some, and see if that irons out the issues we're 
seeing. I'll also give it a go with SEPBUILDDIR and see if I can get it 
failing over here too.


Cheers!



I attached my do_configure log file.

Thanks
 Sau!


  meta/conf/distro/include/seperatebuilddir.inc |  2 +-
  meta/recipes-devtools/json-c/json-c_0.11.bb   | 16 
  meta/recipes-devtools/libjson/libjson_0.9.bb  | 14 --
  meta/recipes-multimedia/pulseaudio/pulseaudio.inc |  2 +-
  4 files changed, 18 insertions(+), 16 deletions(-)
  create mode 100644 meta/recipes-devtools/json-c/json-c_0.11.bb
  delete mode 100644 meta/recipes-devtools/libjson/libjson_0.9.bb

diff --git a/meta/conf/distro/include/seperatebuilddir.inc
b/meta/conf/distro/include/seperatebuilddir.inc
index c067183..e1a5c6b 100644
--- a/meta/conf/distro/include/seperatebuilddir.inc
+++ b/meta/conf/distro/include/seperatebuilddir.inc
@@ -294,7 +294,7 @@ B_pn-libice = ${SEPB}
  B_pn-libice-native = ${SEPB}
  B_pn-libid3tag = ${SEPB}
  B_pn-libidn = ${SEPB}
-B_pn-libjson = ${SEPB}
+B_pn-json-c = ${SEPB}
  B_pn-libksba = ${SEPB}
  B_pn-libmad = ${SEPB}
  B_pn-libmatchbox = ${SEPB}
diff --git a/meta/recipes-devtools/json-c/json-c_0.11.bb
b/meta/recipes-devtools/json-c/json-c_0.11.bb
new file mode 100644
index 000..59a4b4d
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_0.11.bb
@@ -0,0 +1,16 @@
+SUMMARY = JSON-C implements a reference counting object model that
allows you to easily construct JSON objects in C
+HOMEPAGE = https://github.com/json-c/json-c/wiki;
+LICENSE = MIT
+LIC_FILES_CHKSUM = file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2
+
+SRC_URI =
https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;
+
+SRC_URI[md5sum] = aa02367d2f7a830bf1e3376f77881e98
+SRC_URI[sha256sum] =
28dfc65145dc0d4df1dfe7701ac173c4e5f9347176c8983edbfac9149494448c
+
+RPROVIDES_${PN} = libjson
+
+PARALLEL_MAKE = 
+EXTRA_OECONF = --disable-oldname-compat
+
+inherit autotools
diff --git a/meta/recipes-devtools/libjson/libjson_0.9.bb
b/meta/recipes-devtools/libjson/libjson_0.9.bb
deleted file mode 100644
index e4951a8..000
--- a/meta/recipes-devtools/libjson/libjson_0.9.bb
+++ /dev/null
@@ -1,14 +0,0 @@
-DESCRIPTION = JSON-C - A JSON implementation in C
-HOMEPAGE = http://oss.metaparadigm.com/json-c/;
-
-LICENSE = MIT
-LIC_FILES_CHKSUM = file://COPYING;md5=30a276a476b02c2dcd0849bde417fb17
-
-SRC_URI = http://oss.metaparadigm.com/json-c/json-c-${PV}.tar.gz;
-SRC_URI[md5sum] = 3a13d264528dcbaf3931b0cede24abae
-SRC_URI[sha256sum] =
702a486c9bf8e19137d484ab5c49b4ad314eb5e1fe37062a72c0a0fa39439475
-
-S = ${WORKDIR}/json-c-${PV}
-
-
-inherit autotools
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 4c10aa9..475da41 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM =
file://GPL;md5=4325afd396febcb659c36b49533135d4 \
  DEPENDS = libatomics-ops liboil libsamplerate0 libsndfile1 libtool
  # optional
  DEPENDS += udev alsa-lib glib-2.0 dbus gconf
-DEPENDS += libjson gdbm speex libxml-parser-perl-native
+DEPENDS += json-c gdbm speex libxml-parser-perl-native

  inherit autotools pkgconfig useradd gettext perlnative





--

  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  http://www.embed.me.uk

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

[OE-core] [PATCHv4] libjson: update to 0.11 and rename to json-c

[Jack Mitchell]

From: Jack Mitchell jmitch...@cbnl.com

libjson is now known as json-c, support for the old namespace is
disabled as it seems to break SEPBUILDDIR configs. Built without
parallel make as it fails, official word is not to bother trying.

Signed-off-by: Jack Mitchell jmitch...@cbnl.com
---

 v4:
  - add --disable-oldname-compat to try and fix suspected SEPBUILDDIR 
issues

 meta/conf/distro/include/seperatebuilddir.inc |  2 +-
 meta/recipes-devtools/json-c/json-c_0.11.bb   | 16 
 meta/recipes-devtools/libjson/libjson_0.9.bb  | 14 --
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc |  2 +-
 4 files changed, 18 insertions(+), 16 deletions(-)
 create mode 100644 meta/recipes-devtools/json-c/json-c_0.11.bb
 delete mode 100644 meta/recipes-devtools/libjson/libjson_0.9.bb

diff --git a/meta/conf/distro/include/seperatebuilddir.inc 
b/meta/conf/distro/include/seperatebuilddir.inc
index c067183..e1a5c6b 100644
--- a/meta/conf/distro/include/seperatebuilddir.inc
+++ b/meta/conf/distro/include/seperatebuilddir.inc
@@ -294,7 +294,7 @@ B_pn-libice = ${SEPB}
 B_pn-libice-native = ${SEPB}
 B_pn-libid3tag = ${SEPB}
 B_pn-libidn = ${SEPB}
-B_pn-libjson = ${SEPB}
+B_pn-json-c = ${SEPB}
 B_pn-libksba = ${SEPB}
 B_pn-libmad = ${SEPB}
 B_pn-libmatchbox = ${SEPB}
diff --git a/meta/recipes-devtools/json-c/json-c_0.11.bb 
b/meta/recipes-devtools/json-c/json-c_0.11.bb
new file mode 100644
index 000..59a4b4d
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_0.11.bb
@@ -0,0 +1,16 @@
+SUMMARY = JSON-C implements a reference counting object model that allows you 
to easily construct JSON objects in C
+HOMEPAGE = https://github.com/json-c/json-c/wiki;
+LICENSE = MIT
+LIC_FILES_CHKSUM = file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2
+
+SRC_URI = https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;
+
+SRC_URI[md5sum] = aa02367d2f7a830bf1e3376f77881e98
+SRC_URI[sha256sum] = 
28dfc65145dc0d4df1dfe7701ac173c4e5f9347176c8983edbfac9149494448c
+
+RPROVIDES_${PN} = libjson
+
+PARALLEL_MAKE = 
+EXTRA_OECONF = --disable-oldname-compat
+
+inherit autotools
diff --git a/meta/recipes-devtools/libjson/libjson_0.9.bb 
b/meta/recipes-devtools/libjson/libjson_0.9.bb
deleted file mode 100644
index e4951a8..000
--- a/meta/recipes-devtools/libjson/libjson_0.9.bb
+++ /dev/null
@@ -1,14 +0,0 @@
-DESCRIPTION = JSON-C - A JSON implementation in C
-HOMEPAGE = http://oss.metaparadigm.com/json-c/;
-
-LICENSE = MIT
-LIC_FILES_CHKSUM = file://COPYING;md5=30a276a476b02c2dcd0849bde417fb17
-
-SRC_URI = http://oss.metaparadigm.com/json-c/json-c-${PV}.tar.gz;
-SRC_URI[md5sum] = 3a13d264528dcbaf3931b0cede24abae
-SRC_URI[sha256sum] = 
702a486c9bf8e19137d484ab5c49b4ad314eb5e1fe37062a72c0a0fa39439475
-
-S = ${WORKDIR}/json-c-${PV}
-
-
-inherit autotools
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 4c10aa9..475da41 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
file://GPL;md5=4325afd396febcb659c36b49533135d4 \
 DEPENDS = libatomics-ops liboil libsamplerate0 libsndfile1 libtool
 # optional
 DEPENDS += udev alsa-lib glib-2.0 dbus gconf
-DEPENDS += libjson gdbm speex libxml-parser-perl-native
+DEPENDS += json-c gdbm speex libxml-parser-perl-native
 
 inherit autotools pkgconfig useradd gettext perlnative
 
-- 
1.8.4.2

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

Re: [OE-core] [PATCH] eglibc_2.17.bb: accept make versions 4.0 and greater

[Jack Mitchell]

On 05/11/13 05:11, Jonathan Liu wrote:
 On 4/11/2013 11:35 PM, Jack Mitchell wrote:
 On 04/11/13 06:31, Jonathan Liu wrote:
 Signed-off-by: Jonathan Liu net...@gmail.com
 ---
   meta/recipes-core/eglibc/eglibc-2.17/make-4.patch | 31
 +++
   meta/recipes-core/eglibc/eglibc_2.17.bb   |  1 +
   2 files changed, 32 insertions(+)
   create mode 100644 meta/recipes-core/eglibc/eglibc-2.17/make-4.patch

 diff --git a/meta/recipes-core/eglibc/eglibc-2.17/make-4.patch
 b/meta/recipes-core/eglibc/eglibc-2.17/make-4.patch
 new file mode 100644
 index 000..8349c18
 --- /dev/null
 +++ b/meta/recipes-core/eglibc/eglibc-2.17/make-4.patch
 @@ -0,0 +1,31 @@
 +Accept make versions 4.0 and greater
 +
 +Backport of glibc 28d708c44bc47b56f6551ff285f78edcf61c208a.
 +
 +Upstream-Status: Backport
 +Signed-off-by: Jonathan Liu net...@gmail.com
 +
 +diff -Nur libc.orig/configure libc/configure
 +--- libc.orig/configure2012-12-03 08:11:45.0 +1100
  libc/configure2013-11-04 17:15:31.344984184 +1100
 +@@ -4995,7 +4995,7 @@
 +   ac_prog_version=`$MAKE --version 21 | sed -n 's/^.*GNU
 Make[^0-9]*\([0-9][0-9.]*\).*$/\1/p'`
 +   case $ac_prog_version in
 + '') ac_prog_version=v. ?.??, bad; ac_verc_fail=yes;;
 +-3.79* | 3.[89]*)
 ++3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*)
 +ac_prog_version=$ac_prog_version, ok; ac_verc_fail=no;;
 + *) ac_prog_version=$ac_prog_version, bad; ac_verc_fail=yes;;
 +
 +diff -Nur libc.orig/configure.in libc/configure.in
 +--- libc.orig/configure.in2012-12-03 08:11:45.0 +1100
  libc/configure.in2013-11-04 17:15:31.351650849 +1100
 +@@ -958,7 +958,7 @@
 +   critic_missing=$critic_missing gcc)
 + AC_CHECK_PROG_VER(MAKE, gnumake gmake make, --version,
 +   [GNU Make[^0-9]*\([0-9][0-9.]*\)],
 +-  [3.79* | 3.[89]*], critic_missing=$critic_missing make)
 ++  [3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*],
 critic_missing=$critic_missing make)
 +
 + AC_CHECK_PROG_VER(MSGFMT, gnumsgfmt gmsgfmt msgfmt, --version,
 +   [GNU gettext.* \([0-9]*\.[0-9.]*\)],
 diff --git a/meta/recipes-core/eglibc/eglibc_2.17.bb
 b/meta/recipes-core/eglibc/eglibc_2.17.bb
 index 22129e6..c62ff36 100644
 --- a/meta/recipes-core/eglibc/eglibc_2.17.bb
 +++ b/meta/recipes-core/eglibc/eglibc_2.17.bb
 @@ -28,6 +28,7 @@ SRC_URI =
 http://downloads.yoctoproject.org/releases/eglibc/eglibc-${PV}-svnr22
  file://tzselect-awk.patch \
 
 file://0001-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch \
  file://fix-tibetian-locales.patch \
 +   file://make-4.patch \
  ${BACKPORTS} \
 
   BACKPORTS = \

 Jonathan,

 Does this actually build and work on your system? I have had issues with
 make 4.0 and autotools 2.69 which lead to a failed configure/compile.

 Cheers,

 I was able to build eglibc 2.18 and compile images for my x86 target
 successfully.

 Relevant output from configure:
 checking version of make... 4.0, ok
 ...
 checking for autoconf... autoconf
 checking whether autoconf works... no
 configure: WARNING:
 *** These auxiliary programs are missing or incompatible versions:
 autoconf
 *** some features will be disabled.
 *** Check the INSTALL file for required versions.

 I don't build any SDKs though.

 Regards,
 Jonathan

Ah Ok, that is where the error lies then. Thanks for the confirmation.

Cheers,

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 

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

Re: [OE-core] [PATCH] eglibc_2.17.bb: accept make versions 4.0 and greater

[Jack Mitchell]

On 04/11/13 06:31, Jonathan Liu wrote:
 Signed-off-by: Jonathan Liu net...@gmail.com
 ---
  meta/recipes-core/eglibc/eglibc-2.17/make-4.patch | 31 
 +++
  meta/recipes-core/eglibc/eglibc_2.17.bb   |  1 +
  2 files changed, 32 insertions(+)
  create mode 100644 meta/recipes-core/eglibc/eglibc-2.17/make-4.patch
 
 diff --git a/meta/recipes-core/eglibc/eglibc-2.17/make-4.patch 
 b/meta/recipes-core/eglibc/eglibc-2.17/make-4.patch
 new file mode 100644
 index 000..8349c18
 --- /dev/null
 +++ b/meta/recipes-core/eglibc/eglibc-2.17/make-4.patch
 @@ -0,0 +1,31 @@
 +Accept make versions 4.0 and greater
 +
 +Backport of glibc 28d708c44bc47b56f6551ff285f78edcf61c208a.
 +
 +Upstream-Status: Backport
 +Signed-off-by: Jonathan Liu net...@gmail.com
 +
 +diff -Nur libc.orig/configure libc/configure
 +--- libc.orig/configure  2012-12-03 08:11:45.0 +1100
  libc/configure   2013-11-04 17:15:31.344984184 +1100
 +@@ -4995,7 +4995,7 @@
 +   ac_prog_version=`$MAKE --version 21 | sed -n 's/^.*GNU 
 Make[^0-9]*\([0-9][0-9.]*\).*$/\1/p'`
 +   case $ac_prog_version in
 + '') ac_prog_version=v. ?.??, bad; ac_verc_fail=yes;;
 +-3.79* | 3.[89]*)
 ++3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*)
 +ac_prog_version=$ac_prog_version, ok; ac_verc_fail=no;;
 + *) ac_prog_version=$ac_prog_version, bad; ac_verc_fail=yes;;
 + 
 +diff -Nur libc.orig/configure.in libc/configure.in
 +--- libc.orig/configure.in   2012-12-03 08:11:45.0 +1100
  libc/configure.in2013-11-04 17:15:31.351650849 +1100
 +@@ -958,7 +958,7 @@
 +   critic_missing=$critic_missing gcc)
 + AC_CHECK_PROG_VER(MAKE, gnumake gmake make, --version,
 +   [GNU Make[^0-9]*\([0-9][0-9.]*\)],
 +-  [3.79* | 3.[89]*], critic_missing=$critic_missing make)
 ++  [3.79* | 3.[89]* | [4-9].* | [1-9][0-9]*], 
 critic_missing=$critic_missing make)
 + 
 + AC_CHECK_PROG_VER(MSGFMT, gnumsgfmt gmsgfmt msgfmt, --version,
 +   [GNU gettext.* \([0-9]*\.[0-9.]*\)],
 diff --git a/meta/recipes-core/eglibc/eglibc_2.17.bb 
 b/meta/recipes-core/eglibc/eglibc_2.17.bb
 index 22129e6..c62ff36 100644
 --- a/meta/recipes-core/eglibc/eglibc_2.17.bb
 +++ b/meta/recipes-core/eglibc/eglibc_2.17.bb
 @@ -28,6 +28,7 @@ SRC_URI = 
 http://downloads.yoctoproject.org/releases/eglibc/eglibc-${PV}-svnr22
 file://tzselect-awk.patch \
 
 file://0001-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch \
 file://fix-tibetian-locales.patch \
 +   file://make-4.patch \
 ${BACKPORTS} \

  BACKPORTS = \
 

Jonathan,

Does this actually build and work on your system? I have had issues with
make 4.0 and autotools 2.69 which lead to a failed configure/compile.

Cheers,

-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe][PATCHv3] libjson: update to 0.11 and rename to json-c

[Jack Mitchell]

From: Jack Mitchell jmitch...@cbnl.com

libjson is now known as json-c, it keeps support for the old
libjson namespace so it shouldn't break anything. Built without
parallel make as it would fail when it tries to link to link back
to itself, which is odd, but the official word is: don't build in
parallel.

Signed-off-by: Jack Mitchell jmitch...@cbnl.com
---
 meta/conf/distro/include/seperatebuilddir.inc |  2 +-
 meta/recipes-devtools/json-c/json-c_0.11.bb   | 15 +++
 meta/recipes-devtools/libjson/libjson_0.9.bb  | 14 --
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc |  2 +-
 4 files changed, 17 insertions(+), 16 deletions(-)
 create mode 100644 meta/recipes-devtools/json-c/json-c_0.11.bb
 delete mode 100644 meta/recipes-devtools/libjson/libjson_0.9.bb

diff --git a/meta/conf/distro/include/seperatebuilddir.inc 
b/meta/conf/distro/include/seperatebuilddir.inc
index c067183..e1a5c6b 100644
--- a/meta/conf/distro/include/seperatebuilddir.inc
+++ b/meta/conf/distro/include/seperatebuilddir.inc
@@ -294,7 +294,7 @@ B_pn-libice = ${SEPB}
 B_pn-libice-native = ${SEPB}
 B_pn-libid3tag = ${SEPB}
 B_pn-libidn = ${SEPB}
-B_pn-libjson = ${SEPB}
+B_pn-json-c = ${SEPB}
 B_pn-libksba = ${SEPB}
 B_pn-libmad = ${SEPB}
 B_pn-libmatchbox = ${SEPB}
diff --git a/meta/recipes-devtools/json-c/json-c_0.11.bb 
b/meta/recipes-devtools/json-c/json-c_0.11.bb
new file mode 100644
index 000..a909dac
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_0.11.bb
@@ -0,0 +1,15 @@
+SUMMARY = JSON-C implements a reference counting object model that allows you 
to easily construct JSON objects in C
+HOMEPAGE = https://github.com/json-c/json-c/wiki;
+LICENSE = MIT
+LIC_FILES_CHKSUM = file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2
+
+SRC_URI = https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;
+
+SRC_URI[md5sum] = aa02367d2f7a830bf1e3376f77881e98
+SRC_URI[sha256sum] = 
28dfc65145dc0d4df1dfe7701ac173c4e5f9347176c8983edbfac9149494448c
+
+RPROVIDES_${PN} = libjson
+
+PARALLEL_MAKE = 
+
+inherit autotools
diff --git a/meta/recipes-devtools/libjson/libjson_0.9.bb 
b/meta/recipes-devtools/libjson/libjson_0.9.bb
deleted file mode 100644
index e4951a8..000
--- a/meta/recipes-devtools/libjson/libjson_0.9.bb
+++ /dev/null
@@ -1,14 +0,0 @@
-DESCRIPTION = JSON-C - A JSON implementation in C
-HOMEPAGE = http://oss.metaparadigm.com/json-c/;
-
-LICENSE = MIT
-LIC_FILES_CHKSUM = file://COPYING;md5=30a276a476b02c2dcd0849bde417fb17
-
-SRC_URI = http://oss.metaparadigm.com/json-c/json-c-${PV}.tar.gz;
-SRC_URI[md5sum] = 3a13d264528dcbaf3931b0cede24abae
-SRC_URI[sha256sum] = 
702a486c9bf8e19137d484ab5c49b4ad314eb5e1fe37062a72c0a0fa39439475
-
-S = ${WORKDIR}/json-c-${PV}
-
-
-inherit autotools
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 4c10aa9..475da41 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
file://GPL;md5=4325afd396febcb659c36b49533135d4 \
 DEPENDS = libatomics-ops liboil libsamplerate0 libsndfile1 libtool
 # optional
 DEPENDS += udev alsa-lib glib-2.0 dbus gconf
-DEPENDS += libjson gdbm speex libxml-parser-perl-native
+DEPENDS += json-c gdbm speex libxml-parser-perl-native
 
 inherit autotools pkgconfig useradd gettext perlnative
 
-- 
1.8.4.1

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

[OE-core] Why is i586 the default tune?

[Jack Mitchell]

Can anybody shed any light on why i586 is the default tune, rather than
i686, and for that matter why there is no i686 tune?

Would there be any objections to creating an i686 tune and setting it to
default?


-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe][PATCHv2] libjson: update to 0.11 and rename to json-c

[Jack Mitchell]

On 22/10/13 21:44, Saul Wold wrote:
 On 10/21/2013 01:56 AM, Jack Mitchell wrote:
 From: Jack Mitchell jmitch...@cbnl.com

 libjson is now known as json-c, it keeps support for the old
 libjson namespace so it shouldn't break anything. Built without
 parallel make as it would fail when it tries to link to link back
 to itself, which is odd, but the official word is: don't build in
 parallel.


 Jack,

 Not sure what's going on yet, but I found a configure failure, see the
 attached log file.

 Patch review is going to be a little slower this week as RP and a
 bunch of the Yocto Project community are at Yocto Project Dev Day and
 ELC-E the rest of this week.

 Sau!


I have rebuilt this package multiple times now and have still not
managed to break it. I believe it will just be a dirty build directory,
but that shouldn't be an excuse for it not building.

Does anyone have any suggestions on how to overcome this?


-- 
  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  Cambridgeshire, UK
  http://www.embed.me.uk
-- 

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

Re: [OE-core] [oe][PATCHv2] libjson: update to 0.11 and rename to json-c

[Jack Mitchell]

On 28/10/2013 19:32, Khem Raj wrote:

On Mon, Oct 21, 2013 at 1:56 AM, Jack Mitchell m...@communistcode.co.uk wrote:

From: Jack Mitchell jmitch...@cbnl.com

libjson is now known as json-c, it keeps support for the old
libjson namespace so it shouldn't break anything. Built without
parallel make as it would fail when it tries to link to link back
to itself, which is odd, but the official word is: don't build in
parallel.

Signed-off-by: Jack Mitchell jmitch...@cbnl.com
---

  v2: rebased to latest master

  meta/conf/distro/include/seperatebuilddir.inc |  2 +-
  meta/recipes-devtools/json-c/json-c_0.11.bb   | 13 +
  meta/recipes-devtools/libjson/libjson_0.9.bb  | 14 --
  meta/recipes-multimedia/pulseaudio/pulseaudio.inc |  2 +-
  4 files changed, 15 insertions(+), 16 deletions(-)
  create mode 100644 meta/recipes-devtools/json-c/json-c_0.11.bb
  delete mode 100644 meta/recipes-devtools/libjson/libjson_0.9.bb

diff --git a/meta/conf/distro/include/seperatebuilddir.inc 
b/meta/conf/distro/include/seperatebuilddir.inc
index c067183..e1a5c6b 100644
--- a/meta/conf/distro/include/seperatebuilddir.inc
+++ b/meta/conf/distro/include/seperatebuilddir.inc
@@ -294,7 +294,7 @@ B_pn-libice = ${SEPB}
  B_pn-libice-native = ${SEPB}
  B_pn-libid3tag = ${SEPB}
  B_pn-libidn = ${SEPB}
-B_pn-libjson = ${SEPB}
+B_pn-json-c = ${SEPB}
  B_pn-libksba = ${SEPB}
  B_pn-libmad = ${SEPB}
  B_pn-libmatchbox = ${SEPB}
diff --git a/meta/recipes-devtools/json-c/json-c_0.11.bb 
b/meta/recipes-devtools/json-c/json-c_0.11.bb
new file mode 100644
index 000..e0391f5
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_0.11.bb
@@ -0,0 +1,13 @@
+SUMMARY = JSON-C implements a reference counting object model that allows you to 
easily construct JSON objects in C
+HOMEPAGE = https://github.com/json-c/json-c/wiki;
+LICENSE = MIT
+LIC_FILES_CHKSUM = file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2
+
+SRC_URI = https://s3.amazonaws.com/json-c_releases/releases/${P}.tar.gz;



be explicit and use BPN-PV so that if someday someone creates a
mutation with native of nativesdk then it works there too.
and keep RPROVIDE'ing libjson might make folks with feeds happier.
and use git format-patch -M next time


Thanks for the feedback Khem. My local copy actually has the RPROVIDES 
already and that will come in V3. The patch was formatted with -M, I 
think git couldn't cope with the move and the changes, so just decided 
it was a full rewrite.


As for the BPN-PV, I don't really understand, I just grepped for 
libjson, and changed all the occurrences... the separate build dir being 
one of them, how would you expect the change to look?


Cheers,
Jack.

--

  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  http://www.embed.me.uk

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

Re: [OE-core] [oe][PATCHv2] libjson: update to 0.11 and rename to json-c

[Jack Mitchell]

On 10/22/13 21:44, Saul Wold wrote:

On 10/21/2013 01:56 AM, Jack Mitchell wrote:

From: Jack Mitchell jmitch...@cbnl.com

libjson is now known as json-c, it keeps support for the old
libjson namespace so it shouldn't break anything. Built without
parallel make as it would fail when it tries to link to link back
to itself, which is odd, but the official word is: don't build in
parallel.



Jack,

Not sure what's going on yet, but I found a configure failure, see the 
attached log file.


Patch review is going to be a little slower this week as RP and a 
bunch of the Yocto Project community are at Yocto Project Dev Day and 
ELC-E the rest of this week.


Sau!


Urgh, this library is a PITA. I'm going to be at the Dev Day/ELC-E 
myself so I might seek some professional guidance ;)





Signed-off-by: Jack Mitchell jmitch...@cbnl.com
---

  v2: rebased to latest master

  meta/conf/distro/include/seperatebuilddir.inc |  2 +-
  meta/recipes-devtools/json-c/json-c_0.11.bb   | 13 +
  meta/recipes-devtools/libjson/libjson_0.9.bb  | 14 --
  meta/recipes-multimedia/pulseaudio/pulseaudio.inc |  2 +-
  4 files changed, 15 insertions(+), 16 deletions(-)
  create mode 100644 meta/recipes-devtools/json-c/json-c_0.11.bb
  delete mode 100644 meta/recipes-devtools/libjson/libjson_0.9.bb

diff --git a/meta/conf/distro/include/seperatebuilddir.inc 
b/meta/conf/distro/include/seperatebuilddir.inc

index c067183..e1a5c6b 100644
--- a/meta/conf/distro/include/seperatebuilddir.inc
+++ b/meta/conf/distro/include/seperatebuilddir.inc
@@ -294,7 +294,7 @@ B_pn-libice = ${SEPB}
  B_pn-libice-native = ${SEPB}
  B_pn-libid3tag = ${SEPB}
  B_pn-libidn = ${SEPB}
-B_pn-libjson = ${SEPB}
+B_pn-json-c = ${SEPB}
  B_pn-libksba = ${SEPB}
  B_pn-libmad = ${SEPB}
  B_pn-libmatchbox = ${SEPB}
diff --git a/meta/recipes-devtools/json-c/json-c_0.11.bb 
b/meta/recipes-devtools/json-c/json-c_0.11.bb

new file mode 100644
index 000..e0391f5
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_0.11.bb
@@ -0,0 +1,13 @@
+SUMMARY = JSON-C implements a reference counting object model that 
allows you to easily construct JSON objects in C

+HOMEPAGE = https://github.com/json-c/json-c/wiki;
+LICENSE = MIT
+LIC_FILES_CHKSUM = 
file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2

+
+SRC_URI = 
https://s3.amazonaws.com/json-c_releases/releases/${P}.tar.gz;

+
+SRC_URI[md5sum] = aa02367d2f7a830bf1e3376f77881e98
+SRC_URI[sha256sum] = 
28dfc65145dc0d4df1dfe7701ac173c4e5f9347176c8983edbfac9149494448c

+
+PARALLEL_MAKE = 
+
+inherit autotools
diff --git a/meta/recipes-devtools/libjson/libjson_0.9.bb 
b/meta/recipes-devtools/libjson/libjson_0.9.bb

deleted file mode 100644
index e4951a8..000
--- a/meta/recipes-devtools/libjson/libjson_0.9.bb
+++ /dev/null
@@ -1,14 +0,0 @@
-DESCRIPTION = JSON-C - A JSON implementation in C
-HOMEPAGE = http://oss.metaparadigm.com/json-c/;
-
-LICENSE = MIT
-LIC_FILES_CHKSUM = 
file://COPYING;md5=30a276a476b02c2dcd0849bde417fb17

-
-SRC_URI = http://oss.metaparadigm.com/json-c/json-c-${PV}.tar.gz;
-SRC_URI[md5sum] = 3a13d264528dcbaf3931b0cede24abae
-SRC_URI[sha256sum] = 
702a486c9bf8e19137d484ab5c49b4ad314eb5e1fe37062a72c0a0fa39439475

-
-S = ${WORKDIR}/json-c-${PV}
-
-
-inherit autotools
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc

index 4c10aa9..475da41 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
file://GPL;md5=4325afd396febcb659c36b49533135d4 \

  DEPENDS = libatomics-ops liboil libsamplerate0 libsndfile1 libtool
  # optional
  DEPENDS += udev alsa-lib glib-2.0 dbus gconf
-DEPENDS += libjson gdbm speex libxml-parser-perl-native
+DEPENDS += json-c gdbm speex libxml-parser-perl-native

  inherit autotools pkgconfig useradd gettext perlnative




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

[OE-core] [oe][PATCHv2] libjson: update to 0.11 and rename to json-c

[Jack Mitchell]

From: Jack Mitchell jmitch...@cbnl.com

libjson is now known as json-c, it keeps support for the old
libjson namespace so it shouldn't break anything. Built without
parallel make as it would fail when it tries to link to link back
to itself, which is odd, but the official word is: don't build in
parallel.

Signed-off-by: Jack Mitchell jmitch...@cbnl.com
---

 v2: rebased to latest master

 meta/conf/distro/include/seperatebuilddir.inc |  2 +-
 meta/recipes-devtools/json-c/json-c_0.11.bb   | 13 +
 meta/recipes-devtools/libjson/libjson_0.9.bb  | 14 --
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc |  2 +-
 4 files changed, 15 insertions(+), 16 deletions(-)
 create mode 100644 meta/recipes-devtools/json-c/json-c_0.11.bb
 delete mode 100644 meta/recipes-devtools/libjson/libjson_0.9.bb

diff --git a/meta/conf/distro/include/seperatebuilddir.inc 
b/meta/conf/distro/include/seperatebuilddir.inc
index c067183..e1a5c6b 100644
--- a/meta/conf/distro/include/seperatebuilddir.inc
+++ b/meta/conf/distro/include/seperatebuilddir.inc
@@ -294,7 +294,7 @@ B_pn-libice = ${SEPB}
 B_pn-libice-native = ${SEPB}
 B_pn-libid3tag = ${SEPB}
 B_pn-libidn = ${SEPB}
-B_pn-libjson = ${SEPB}
+B_pn-json-c = ${SEPB}
 B_pn-libksba = ${SEPB}
 B_pn-libmad = ${SEPB}
 B_pn-libmatchbox = ${SEPB}
diff --git a/meta/recipes-devtools/json-c/json-c_0.11.bb 
b/meta/recipes-devtools/json-c/json-c_0.11.bb
new file mode 100644
index 000..e0391f5
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_0.11.bb
@@ -0,0 +1,13 @@
+SUMMARY = JSON-C implements a reference counting object model that allows you 
to easily construct JSON objects in C
+HOMEPAGE = https://github.com/json-c/json-c/wiki;
+LICENSE = MIT
+LIC_FILES_CHKSUM = file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2
+
+SRC_URI = https://s3.amazonaws.com/json-c_releases/releases/${P}.tar.gz;
+
+SRC_URI[md5sum] = aa02367d2f7a830bf1e3376f77881e98
+SRC_URI[sha256sum] = 
28dfc65145dc0d4df1dfe7701ac173c4e5f9347176c8983edbfac9149494448c
+
+PARALLEL_MAKE = 
+
+inherit autotools
diff --git a/meta/recipes-devtools/libjson/libjson_0.9.bb 
b/meta/recipes-devtools/libjson/libjson_0.9.bb
deleted file mode 100644
index e4951a8..000
--- a/meta/recipes-devtools/libjson/libjson_0.9.bb
+++ /dev/null
@@ -1,14 +0,0 @@
-DESCRIPTION = JSON-C - A JSON implementation in C
-HOMEPAGE = http://oss.metaparadigm.com/json-c/;
-
-LICENSE = MIT
-LIC_FILES_CHKSUM = file://COPYING;md5=30a276a476b02c2dcd0849bde417fb17
-
-SRC_URI = http://oss.metaparadigm.com/json-c/json-c-${PV}.tar.gz;
-SRC_URI[md5sum] = 3a13d264528dcbaf3931b0cede24abae
-SRC_URI[sha256sum] = 
702a486c9bf8e19137d484ab5c49b4ad314eb5e1fe37062a72c0a0fa39439475
-
-S = ${WORKDIR}/json-c-${PV}
-
-
-inherit autotools
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 4c10aa9..475da41 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
file://GPL;md5=4325afd396febcb659c36b49533135d4 \
 DEPENDS = libatomics-ops liboil libsamplerate0 libsndfile1 libtool
 # optional
 DEPENDS += udev alsa-lib glib-2.0 dbus gconf
-DEPENDS += libjson gdbm speex libxml-parser-perl-native
+DEPENDS += json-c gdbm speex libxml-parser-perl-native
 
 inherit autotools pkgconfig useradd gettext perlnative
 
-- 
1.8.4

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

[OE-core] [PATCH] libjson: update to 0.11 and rename to json-c

[Jack Mitchell]

From: Jack Mitchell jmitch...@cbnl.com

libjson is now known as json-c, it keeps support for the old
libjson namespace so it shouldn't break anything. Built without
parallel make as it would fail when it tries to link to link back
to itself, which is odd, but the official word is: don't build in
parallel.

Signed-off-by: Jack Mitchell jmitch...@cbnl.com
---
 meta/conf/distro/include/seperatebuilddir.inc |  2 +-
 meta/recipes-devtools/json-c/json-c_0.11.bb   | 13 +
 meta/recipes-devtools/libjson/libjson_0.9.bb  | 14 --
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc |  2 +-
 4 files changed, 15 insertions(+), 16 deletions(-)
 create mode 100644 meta/recipes-devtools/json-c/json-c_0.11.bb
 delete mode 100644 meta/recipes-devtools/libjson/libjson_0.9.bb

diff --git a/meta/conf/distro/include/seperatebuilddir.inc 
b/meta/conf/distro/include/seperatebuilddir.inc
index c067183..e1a5c6b 100644
--- a/meta/conf/distro/include/seperatebuilddir.inc
+++ b/meta/conf/distro/include/seperatebuilddir.inc
@@ -294,7 +294,7 @@ B_pn-libice = ${SEPB}
 B_pn-libice-native = ${SEPB}
 B_pn-libid3tag = ${SEPB}
 B_pn-libidn = ${SEPB}
-B_pn-libjson = ${SEPB}
+B_pn-json-c = ${SEPB}
 B_pn-libksba = ${SEPB}
 B_pn-libmad = ${SEPB}
 B_pn-libmatchbox = ${SEPB}
diff --git a/meta/recipes-devtools/json-c/json-c_0.11.bb 
b/meta/recipes-devtools/json-c/json-c_0.11.bb
new file mode 100644
index 000..e0391f5
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_0.11.bb
@@ -0,0 +1,13 @@
+SUMMARY = JSON-C implements a reference counting object model that allows you 
to easily construct JSON objects in C
+HOMEPAGE = https://github.com/json-c/json-c/wiki;
+LICENSE = MIT
+LIC_FILES_CHKSUM = file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2
+
+SRC_URI = https://s3.amazonaws.com/json-c_releases/releases/${P}.tar.gz;
+
+SRC_URI[md5sum] = aa02367d2f7a830bf1e3376f77881e98
+SRC_URI[sha256sum] = 
28dfc65145dc0d4df1dfe7701ac173c4e5f9347176c8983edbfac9149494448c
+
+PARALLEL_MAKE = 
+
+inherit autotools
diff --git a/meta/recipes-devtools/libjson/libjson_0.9.bb 
b/meta/recipes-devtools/libjson/libjson_0.9.bb
deleted file mode 100644
index e4951a8..000
--- a/meta/recipes-devtools/libjson/libjson_0.9.bb
+++ /dev/null
@@ -1,14 +0,0 @@
-DESCRIPTION = JSON-C - A JSON implementation in C
-HOMEPAGE = http://oss.metaparadigm.com/json-c/;
-
-LICENSE = MIT
-LIC_FILES_CHKSUM = file://COPYING;md5=30a276a476b02c2dcd0849bde417fb17
-
-SRC_URI = http://oss.metaparadigm.com/json-c/json-c-${PV}.tar.gz;
-SRC_URI[md5sum] = 3a13d264528dcbaf3931b0cede24abae
-SRC_URI[sha256sum] = 
702a486c9bf8e19137d484ab5c49b4ad314eb5e1fe37062a72c0a0fa39439475
-
-S = ${WORKDIR}/json-c-${PV}
-
-
-inherit autotools
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 4c10aa9..475da41 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
file://GPL;md5=4325afd396febcb659c36b49533135d4 \
 DEPENDS = libatomics-ops liboil libsamplerate0 libsndfile1 libtool
 # optional
 DEPENDS += udev alsa-lib glib-2.0 dbus gconf
-DEPENDS += libjson gdbm speex libxml-parser-perl-native
+DEPENDS += json-c gdbm speex libxml-parser-perl-native
 
 inherit autotools pkgconfig useradd gettext perlnative
 
-- 
1.8.4

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

[OE-core] [PATCH] crond: remove UID check in init script

[Jack Mitchell]

From: Jack Mitchell jmitch...@cbnl.com

this init script fails when the default shell is busybox sh. This
is because busybox sh doesn't set the UID. No other init scripts
in oecore feel the need to check the UID so just remove the check.

Signed-off-by: Jack Mitchell jmitch...@cbnl.com
---
 meta/recipes-extended/cronie/cronie/crond.init | 8 
 1 file changed, 8 deletions(-)

diff --git a/meta/recipes-extended/cronie/cronie/crond.init 
b/meta/recipes-extended/cronie/cronie/crond.init
index 08f34be..c8dffef 100755
--- a/meta/recipes-extended/cronie/cronie/crond.init
+++ b/meta/recipes-extended/cronie/cronie/crond.init
@@ -23,10 +23,6 @@ CONFIG=/etc/sysconfig/crond
 
 case $1 in
   start)
-if [ $UID -ne 0 ] ; then
-echo User has insufficient privilege.
-exit 1
-fi
 echo -n Starting crond: 
 start-stop-daemon --start --quiet --exec $CROND -- $CRONDARGS
 RETVAL=$?
@@ -37,10 +33,6 @@ case $1 in
 fi
 ;;
   stop)
-if [ $UID -ne 0 ] ; then
-echo User has insufficient privilege.
-exit 1
-fi
 echo -n Stopping crond: 
 start-stop-daemon --stop --quiet --pidfile /var/run/crond.pid
 RETVAL=$?
-- 
1.8.4

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