Re: [OE-core] [PATCH] cmake-native: Depend on ncurses-native too
On Tue, Apr 1, 2014 at 3:11 AM, Mike Crowe wrote: > It seems to be possible to disable building the "CursesDialog" component to > remove the need for ncurses but I couldn't immediately see how to do that > for a bootstrap build. > > The non-native cmake recipe depends on ncurses even though it passes > -DBUILD_CursesDialog=0. you need to disable it completely in CMakefile.txt, just that define does not suffice you might try something like http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-util/cmake/files/cmake-2.8.10-libform.patch?diff_format=f&view=markup -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cmake-native: Depend on ncurses-native too
On Tue, Apr 1, 2014 at 2:31 AM, Richard Purdie wrote: > What does an ncurses enabled cmake give us that is desirable? > bells and whistles - curses GUI frontend :) which I would assume we don't use as much if someone does please speak up -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qemux86-64: re-enable paravirt guest, bring it in sync with qemux86
On Tue, Apr 1, 2014 at 3:00 AM, Stefan Stanacar
wrote:
> Seems wrong that qemux86 has this enabled and qemux86-64 doesn't.
> Also this will allow people to use kvm with -cpu=host.
> Right now, runqemu qemux86-64 kvm uses -cpu=kvm64 because without this
> feature you can't use cpu=host on newer host kernels (>= 3.8).
>
> This basically reverts poky e6149ec6c4c14d3a939022cdc29ac94dced836dd /
> oe-core 64749308fadabb4aa7c39f360c6395827bc5eb3a
> The reason of that commit (which is more than a year old) was that on
> the AB running old kernels (2.6.37) we would see occasional shutdown failures.
> (but if memory serves me right the fix might have been just a coincidence).
>
> I've tested this change with by:
> - run tests on runqemu qemux86-64 (without kvm) (300 seconds)
> - run tests on runqemu qemux86-64 kvm (which uses by default cpu=kvm64) -
> (tests
> took 20 seconds)
> - run tests on runqemu qemux86-64 kvm with cpu=host - (tests took 18
> seconds)
>
> [ YOCTO #5956 ]
thanks for doing it. in quick test it seems to boot in the virtual box
case where I was seeing the same problems.
>
> Signed-off-by: Stefan Stanacar
> ---
> meta/recipes-kernel/linux/linux-yocto_3.14.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
> b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
> index d5202cd..46c4260 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
> @@ -33,5 +33,5 @@ COMPATIBLE_MACHINE =
> "qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
> KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc"
> KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
> KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
> -KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
> +KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
> KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", "
> cfg/x32.scc", "" ,d)}"
> --
> 1.9.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On Tuesday, April 1, 2014, Kang Kai wrote:
> On 2014年03月31日 22:20, Kai Kang wrote:
>
>> From: Roy Li
>>
>> When native package is built, use the uname to return the kernel version.
>>
>> When target is built, read kernel version from
>> ${STAGING_KERNEL_DIR}/kernel-abiversion
>> to avoid to use the hardcode kernel version.
>>
>> Signed-off-by: Roy Li
>> Signed-off-by: Kai Kang
>> ---
>> meta/recipes-support/nss/nss.inc | 15 +--
>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-support/nss/nss.inc b/meta/recipes-support/nss/
>> nss.inc
>> index 404decc..f24da68 100644
>> --- a/meta/recipes-support/nss/nss.inc
>> +++ b/meta/recipes-support/nss/nss.inc
>> @@ -26,6 +26,7 @@ SRC_URI_append_class-target = "\
>> inherit siteinfo
>> PR = "r0"
>> DEPENDS = "sqlite3 nspr zlib nss-native"
>> +DEPENDS_append_class-target += "virtual/kernel"
>> DEPENDS_class-native = "sqlite3-native nspr-native zlib-native"
>> RDEPENDS_${PN} = "perl"
>> @@ -37,12 +38,24 @@ TARGET_CC_ARCH += "${LDFLAGS}"
>> do_compile_prepend_class-native() {
>> export NSPR_INCLUDE_DIR=${STAGING_INCDIR_NATIVE}
>> export NSPR_LIB_DIR=${STAGING_LIBDIR_NATIVE}
>> +export OS_RELEASE=`uname -r`
>> }
>> do_compile_prepend_class-nativesdk() {
>> export LDFLAGS=""
>> }
>> +do_compile_prepend_class-target() {
>> +export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
>> 's/-.*//'`
>> +}
>> +
>> +do_install_prepend_class-native() {
>> +export OS_RELEASE=`uname -r`
>> +}
>> +
>> +do_install_prepend_class-target() {
>> +export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
>> 's/-.*//'`
>> +}
>> do_compile() {
>> export CROSS_COMPILE=1
>> export NATIVE_CC="gcc"
>> @@ -57,7 +70,6 @@ do_compile() {
>> export NSS_USE_SYSTEM_SQLITE=1
>> export NSS_ENABLE_ECC=1
>> -export OS_RELEASE=3.4
>>
>
> How about use var LINUXLIBCVERSION:
>
> export OS_RELEASE="${@d.getVar('LINUXLIBCVERSION', True)}"
>
> it should be the same value with kernel version, right?
No, that's the kernel headers version, if the dependency is on kernel
proper then it won't be the right thing to do since many bsps use different
kernel
>
> --Kai
>
>
>export OS_TARGET=Linux
>> export OS_ARCH=Linux
>> @@ -97,7 +109,6 @@ do_install() {
>> export NSS_USE_SYSTEM_SQLITE=1
>> export NSS_ENABLE_ECC=1
>> -export OS_RELEASE=3.4
>> export OS_TARGET=Linux
>> export OS_ARCH=Linux
>>
>>
>
>
> --
> Regards,
> Neil | Kai Kang
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] libarchive: fix CVE-2013-0211
On 04/01/2014 10:57 PM, Khem Raj wrote: How about test the size of size_t and assigned the related MAX value: > >const size_t max_write = (sizeof(size_t) >= >sizeof(int))?INT_MAX:(sizeof(size_t) == sizeof(short))?SHRT_MAX:CHAR_MAX; > you could use something like (size_t)-1 to denote SIZE_MAX Sounds good, I will do that in V2. //Hongxu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] dbus: backport memory leak patch for error when listing services
Signed-off-by: Jonathan Liu
---
meta/recipes-core/dbus/dbus.inc| 1 +
...y-freeing-if-error-during-listing-service.patch | 45 ++
2 files changed, 46 insertions(+)
create mode 100644
meta/recipes-core/dbus/dbus/fixed-memory-freeing-if-error-during-listing-service.patch
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index 5d57ff4..5727ae7 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -16,6 +16,7 @@ SRC_URI =
"http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
file://os-test.patch \
file://clear-guid_from_server-if-send_negotiate_unix_f.patch \
file://Set-correct-address-when-using-address-systemd.patch \
+ file://fixed-memory-freeing-if-error-during-listing-service.patch \
"
inherit useradd autotools pkgconfig gettext update-rc.d
diff --git
a/meta/recipes-core/dbus/dbus/fixed-memory-freeing-if-error-during-listing-service.patch
b/meta/recipes-core/dbus/dbus/fixed-memory-freeing-if-error-during-listing-service.patch
new file mode 100644
index 000..96290f4
--- /dev/null
+++
b/meta/recipes-core/dbus/dbus/fixed-memory-freeing-if-error-during-listing-service.patch
@@ -0,0 +1,45 @@
+From 03aeaccbffa97c9237b57ca067e3da7388862129 Mon Sep 17 00:00:00 2001
+From: Radoslaw Pajak
+Date: Fri, 8 Nov 2013 13:51:32 +0100
+Subject: [PATCH] fixed memory freeing if error during listing services
+
+Upstream-Status: Backport
+
+Signed-off-by: Radoslaw Pajak
+Reviewed-by: Simon McVittie
+Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71526
+Signed-off-by: Jonathan Liu
+---
+ bus/activation.c | 2 +-
+ bus/services.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/bus/activation.c b/bus/activation.c
+index fcb7133..ea48a26 100644
+--- a/bus/activation.c
b/bus/activation.c
+@@ -2179,7 +2179,7 @@ bus_activation_list_services (BusActivation *activation,
+
+ error:
+ for (j = 0; j < i; j++)
+-dbus_free (retval[i]);
++dbus_free (retval[j]);
+ dbus_free (retval);
+
+ return FALSE;
+diff --git a/bus/services.c b/bus/services.c
+index 6f380fa..01a720e 100644
+--- a/bus/services.c
b/bus/services.c
+@@ -368,7 +368,7 @@ bus_registry_list_services (BusRegistry *registry,
+
+ error:
+ for (j = 0; j < i; j++)
+-dbus_free (retval[i]);
++dbus_free (retval[j]);
+ dbus_free (retval);
+
+ return FALSE;
+--
+1.9.0
+
--
1.9.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] dbus: backport fix for bus activation under systemd session
Signed-off-by: Jonathan Liu
---
meta/recipes-core/dbus/dbus.inc| 1 +
...orrect-address-when-using-address-systemd.patch | 193 +
2 files changed, 194 insertions(+)
create mode 100644
meta/recipes-core/dbus/dbus/Set-correct-address-when-using-address-systemd.patch
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index 677ff78..5d57ff4 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -15,6 +15,7 @@ SRC_URI =
"http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
file://dbus-1.init \
file://os-test.patch \
file://clear-guid_from_server-if-send_negotiate_unix_f.patch \
+ file://Set-correct-address-when-using-address-systemd.patch \
"
inherit useradd autotools pkgconfig gettext update-rc.d
diff --git
a/meta/recipes-core/dbus/dbus/Set-correct-address-when-using-address-systemd.patch
b/meta/recipes-core/dbus/dbus/Set-correct-address-when-using-address-systemd.patch
new file mode 100644
index 000..1fca9bb
--- /dev/null
+++
b/meta/recipes-core/dbus/dbus/Set-correct-address-when-using-address-systemd.patch
@@ -0,0 +1,193 @@
+From d728fdc655f17031da3bb129ab2fd17dadf0fe3a Mon Sep 17 00:00:00 2001
+From: Simon Peeters
+Date: Sun, 7 Oct 2012 16:59:30 +0200
+Subject: [PATCH] Set correct address when using --address=systemd:
+
+When dbus gets launched through systemd, we need to create an address
+string based on the sockets passed.
+
+The _dbus_append_addres_from_socket() function is responsible for
+extracting the address information from the file-descriptor and
+formatting it in a dbus friendly way.
+
+This fixes bus activation when running dbus under a systemd session.
+
+https://bugs.freedesktop.org/show_bug.cgi?id=50962
+
+Upstream-Status: Backport
+
+Signed-off-by: Simon Peeters
+Signed-off-by: Jonathan Liu
+---
+ dbus/dbus-server-unix.c | 38 ++-
+ dbus/dbus-sysdeps-unix.c | 68
+ dbus/dbus-sysdeps-unix.h | 4 +++
+ 3 files changed, 97 insertions(+), 13 deletions(-)
+
+diff --git a/dbus/dbus-server-unix.c b/dbus/dbus-server-unix.c
+index 130f66e..d995240 100644
+--- a/dbus/dbus-server-unix.c
b/dbus/dbus-server-unix.c
+@@ -149,7 +149,7 @@ _dbus_server_listen_platform_specific (DBusAddressEntry
*entry,
+ }
+ else if (strcmp (method, "systemd") == 0)
+ {
+- int n, *fds;
++ int i, n, *fds;
+ DBusString address;
+
+ n = _dbus_listen_systemd_sockets (&fds, error);
+@@ -159,27 +159,39 @@ _dbus_server_listen_platform_specific (DBusAddressEntry
*entry,
+ return DBUS_SERVER_LISTEN_DID_NOT_CONNECT;
+ }
+
+- _dbus_string_init_const (&address, "systemd:");
++ if (!_dbus_string_init (&address))
++ goto systemd_oom;
+
+- *server_p = _dbus_server_new_for_socket (fds, n, &address, NULL);
+- if (*server_p == NULL)
++ for (i = 0; i < n; i++)
+ {
+- int i;
+-
+- for (i = 0; i < n; i++)
++ if (i > 0)
+ {
+- _dbus_close_socket (fds[i], NULL);
++ if (!_dbus_string_append (&address, ";"))
++goto systemd_oom;
+ }
+- dbus_free (fds);
+-
+- dbus_set_error (error, DBUS_ERROR_NO_MEMORY, NULL);
+- return DBUS_SERVER_LISTEN_DID_NOT_CONNECT;
++ if (!_dbus_append_address_from_socket (fds[i], &address, error))
++goto systemd_err;
+ }
+
++ *server_p = _dbus_server_new_for_socket (fds, n, &address, NULL);
++ if (*server_p == NULL)
++goto systemd_oom;
++
+ dbus_free (fds);
+
+ return DBUS_SERVER_LISTEN_OK;
+- }
++ systemd_oom:
++ _DBUS_SET_OOM (error);
++ systemd_err:
++ for (i = 0; i < n; i++)
++{
++ _dbus_close_socket (fds[i], NULL);
++}
++ dbus_free (fds);
++ _dbus_string_free (&address);
++
++ return DBUS_SERVER_LISTEN_DID_NOT_CONNECT;
++}
+ #ifdef DBUS_ENABLE_LAUNCHD
+ else if (strcmp (method, "launchd") == 0)
+ {
+diff --git a/dbus/dbus-sysdeps-unix.c b/dbus/dbus-sysdeps-unix.c
+index b4ecc96..55743b1 100644
+--- a/dbus/dbus-sysdeps-unix.c
b/dbus/dbus-sysdeps-unix.c
+@@ -55,6 +55,7 @@
+ #include
+ #include
+ #include
++#include
+
+ #ifdef HAVE_ERRNO_H
+ #include
+@@ -4160,4 +4161,71 @@ _dbus_check_setuid (void)
+ #endif
+ }
+
++/**
++ * Read the address from the socket and append it to the string
++ *
++ * @param fd the socket
++ * @param address
++ * @param error return location for error code
++ */
++dbus_bool_t
++_dbus_append_address_from_socket (int fd,
++ DBusString *address,
++ DBusError *error)
++{
++ union {
++ struct sockaddr sa;
++ struct sockaddr_storage storage;
++ struct sockaddr_un un;
++ struct sockaddr_in ipv4;
++ struct s
[OE-core] [PATCH 3/3] systemd: backport patch to avoid assertion failures
Signed-off-by: Jonathan Liu
---
...t-use-assert_return-to-check-for-disconne.patch | 513 +
meta/recipes-core/systemd/systemd_211.bb | 1 +
2 files changed, 514 insertions(+)
create mode 100644
meta/recipes-core/systemd/systemd/sd-bus-don-t-use-assert_return-to-check-for-disconne.patch
diff --git
a/meta/recipes-core/systemd/systemd/sd-bus-don-t-use-assert_return-to-check-for-disconne.patch
b/meta/recipes-core/systemd/systemd/sd-bus-don-t-use-assert_return-to-check-for-disconne.patch
new file mode 100644
index 000..c5bee97
--- /dev/null
+++
b/meta/recipes-core/systemd/systemd/sd-bus-don-t-use-assert_return-to-check-for-disconne.patch
@@ -0,0 +1,513 @@
+From a3d59cd1b0a2738d06893948492113f2c35be0af Mon Sep 17 00:00:00 2001
+From: Lennart Poettering
+Date: Wed, 19 Mar 2014 21:41:21 +0100
+Subject: [PATCH] sd-bus: don't use assert_return() to check for disconnected
+ bus connections
+
+A terminated connection is a runtime error and not a developer mistake,
+hence don't use assert_return() to check for it.
+
+Upstream-Status: Backport
+
+Signed-off-by: Jonathan Liu
+---
+ src/libsystemd/sd-bus/bus-control.c | 20 +---
+ src/libsystemd/sd-bus/bus-convenience.c | 58 +
+ src/libsystemd/sd-bus/bus-objects.c | 23 +
+ src/libsystemd/sd-bus/sd-bus.c | 49
+ 4 files changed, 113 insertions(+), 37 deletions(-)
+
+diff --git a/src/libsystemd/sd-bus/bus-control.c
b/src/libsystemd/sd-bus/bus-control.c
+index bb6683e..bd392a2 100644
+--- a/src/libsystemd/sd-bus/bus-control.c
b/src/libsystemd/sd-bus/bus-control.c
+@@ -128,12 +128,14 @@ _public_ int sd_bus_request_name(sd_bus *bus, const char
*name, uint64_t flags)
+ assert_return(bus, -EINVAL);
+ assert_return(name, -EINVAL);
+ assert_return(bus->bus_client, -EINVAL);
+-assert_return(BUS_IS_OPEN(bus->state), -ENOTCONN);
+ assert_return(!bus_pid_changed(bus), -ECHILD);
+ assert_return(!(flags &
~(SD_BUS_NAME_ALLOW_REPLACEMENT|SD_BUS_NAME_REPLACE_EXISTING|SD_BUS_NAME_QUEUE)),
-EINVAL);
+ assert_return(service_name_is_valid(name), -EINVAL);
+ assert_return(name[0] != ':', -EINVAL);
+
++if (!BUS_IS_OPEN(bus->state))
++return -ENOTCONN;
++
+ if (bus->is_kernel)
+ return bus_request_name_kernel(bus, name, flags);
+ else
+@@ -201,11 +203,13 @@ _public_ int sd_bus_release_name(sd_bus *bus, const char
*name) {
+ assert_return(bus, -EINVAL);
+ assert_return(name, -EINVAL);
+ assert_return(bus->bus_client, -EINVAL);
+-assert_return(BUS_IS_OPEN(bus->state), -ENOTCONN);
+ assert_return(!bus_pid_changed(bus), -ECHILD);
+ assert_return(service_name_is_valid(name), -EINVAL);
+ assert_return(name[0] != ':', -EINVAL);
+
++if (!BUS_IS_OPEN(bus->state))
++return -ENOTCONN;
++
+ if (bus->is_kernel)
+ return bus_release_name_kernel(bus, name);
+ else
+@@ -342,9 +346,11 @@ static int bus_list_names_dbus1(sd_bus *bus, char
***acquired, char ***activatab
+ _public_ int sd_bus_list_names(sd_bus *bus, char ***acquired, char
***activatable) {
+ assert_return(bus, -EINVAL);
+ assert_return(acquired || activatable, -EINVAL);
+-assert_return(BUS_IS_OPEN(bus->state), -ENOTCONN);
+ assert_return(!bus_pid_changed(bus), -ECHILD);
+
++if (!BUS_IS_OPEN(bus->state))
++return -ENOTCONN;
++
+ if (bus->is_kernel)
+ return bus_list_names_kernel(bus, acquired, activatable);
+ else
+@@ -735,11 +741,13 @@ _public_ int sd_bus_get_owner(
+ assert_return(name, -EINVAL);
+ assert_return(mask <= _SD_BUS_CREDS_ALL, -ENOTSUP);
+ assert_return(mask == 0 || creds, -EINVAL);
+-assert_return(BUS_IS_OPEN(bus->state), -ENOTCONN);
+ assert_return(!bus_pid_changed(bus), -ECHILD);
+ assert_return(service_name_is_valid(name), -EINVAL);
+ assert_return(bus->bus_client, -ENODATA);
+
++if (!BUS_IS_OPEN(bus->state))
++return -ENOTCONN;
++
+ if (bus->is_kernel)
+ return bus_get_owner_kdbus(bus, name, mask, creds);
+ else
+@@ -1196,10 +1204,12 @@ _public_ int sd_bus_get_owner_machine_id(sd_bus *bus,
const char *name, sd_id128
+ assert_return(bus, -EINVAL);
+ assert_return(name, -EINVAL);
+ assert_return(machine, -EINVAL);
+-assert_return(BUS_IS_OPEN(bus->state), -ENOTCONN);
+ assert_return(!bus_pid_changed(bus), -ECHILD);
+ assert_return(service_name_is_valid(name), -EINVAL);
+
++if (!BUS_IS_OPEN(bus->state))
++return -ENOTCONN;
++
+ if (streq_ptr(name, bus->unique_name))
+ return sd_id128_get_machine(machine);
+
+diff --git a/src/libsystemd/sd-bus/bus-convenience.
Re: [OE-core] [PATCH] nss: avoid to use the hardcode kernel version
On 2014年03月31日 22:20, Kai Kang wrote:
From: Roy Li
When native package is built, use the uname to return the kernel version.
When target is built, read kernel version from
${STAGING_KERNEL_DIR}/kernel-abiversion
to avoid to use the hardcode kernel version.
Signed-off-by: Roy Li
Signed-off-by: Kai Kang
---
meta/recipes-support/nss/nss.inc | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/nss/nss.inc b/meta/recipes-support/nss/nss.inc
index 404decc..f24da68 100644
--- a/meta/recipes-support/nss/nss.inc
+++ b/meta/recipes-support/nss/nss.inc
@@ -26,6 +26,7 @@ SRC_URI_append_class-target = "\
inherit siteinfo
PR = "r0"
DEPENDS = "sqlite3 nspr zlib nss-native"
+DEPENDS_append_class-target += "virtual/kernel"
DEPENDS_class-native = "sqlite3-native nspr-native zlib-native"
RDEPENDS_${PN} = "perl"
@@ -37,12 +38,24 @@ TARGET_CC_ARCH += "${LDFLAGS}"
do_compile_prepend_class-native() {
export NSPR_INCLUDE_DIR=${STAGING_INCDIR_NATIVE}
export NSPR_LIB_DIR=${STAGING_LIBDIR_NATIVE}
+export OS_RELEASE=`uname -r`
}
do_compile_prepend_class-nativesdk() {
export LDFLAGS=""
}
+do_compile_prepend_class-target() {
+export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
's/-.*//'`
+}
+
+do_install_prepend_class-native() {
+export OS_RELEASE=`uname -r`
+}
+
+do_install_prepend_class-target() {
+export OS_RELEASE=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion|sed
's/-.*//'`
+}
do_compile() {
export CROSS_COMPILE=1
export NATIVE_CC="gcc"
@@ -57,7 +70,6 @@ do_compile() {
export NSS_USE_SYSTEM_SQLITE=1
export NSS_ENABLE_ECC=1
-export OS_RELEASE=3.4
How about use var LINUXLIBCVERSION:
export OS_RELEASE="${@d.getVar('LINUXLIBCVERSION', True)}"
it should be the same value with kernel version, right?
--Kai
export OS_TARGET=Linux
export OS_ARCH=Linux
@@ -97,7 +109,6 @@ do_install() {
export NSS_USE_SYSTEM_SQLITE=1
export NSS_ENABLE_ECC=1
-export OS_RELEASE=3.4
export OS_TARGET=Linux
export OS_ARCH=Linux
--
Regards,
Neil | Kai Kang
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libsdl: PACKAGECONFIG conversion
On 04/01/2014 03:54 AM, Richard Purdie wrote:
On Tue, 2014-04-01 at 00:10 -0700, Andre McCurdy wrote:
General cleanup + make it easier for distros / machines which
support OpenGL ES only to prevent attempts to build against libgl.
Signed-off-by: Andre McCurdy
---
meta/recipes-graphics/libsdl/libsdl_1.2.15.bb | 30 ++-
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
index e19c388..f72f74f 100644
--- a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
+++ b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
@@ -12,10 +12,6 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=27818cd7fd83877a8e3ef82b82798ef4"
PROVIDES = "virtual/libsdl"
-DEPENDS = "${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)}
\
- ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl
libglu', '', d)} \
- ${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxext
libxrandr libxrender', '', d)} \
- tslib"
DEPENDS_class-nativesdk = "${@base_contains('DISTRO_FEATURES', 'x11',
'virtual/nativesdk-libx11 nativesdk-libxrandr nativesdk-libxrender nativesdk-libxext',
'', d)}"
I have a nasty feeling this will break libsdl-native :(
Yes, it does :-(
Attempting a v2, but using PACKAGECONFIG to managed DEPENDS for x11
runs into problems. It seems that the nativesdk package renaming
mis-renames DEPENDS coming from PACKAGECONFIG which have a virtual/
prefix (the nativesdk- gets added twice):
ERROR: Nothing PROVIDES 'virtual/nativesdk-nativesdk-libx11' (but
virtual:nativesdk:/home/andre/oe-master/openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
DEPENDS on or otherwise requires it). Close matches:
virtual/nativesdk-libx11
virtual/nativesdk-libc
virtual/nativesdk-db
PR = "r3"
@@ -38,17 +34,31 @@ EXTRA_OECONF = "--disable-static --enable-cdrom
--enable-threads --enable-timers
--disable-mintaudio --disable-nasm --disable-video-dga \
--disable-video-fbcon --disable-video-ps2gs
--disable-video-ps3 \
--disable-xbios --disable-gem --disable-video-dummy \
---enable-input-events --enable-input-tslib --enable-pthreads \
-${@base_contains('DISTRO_FEATURES', 'directfb',
'--enable-video-directfb', '--disable-video-directfb', d)} \
-${@base_contains('DISTRO_FEATURES', 'opengl',
'--enable-video-opengl', '--disable-video-opengl', d)} \
-${@base_contains('DISTRO_FEATURES', 'x11',
'--enable-video-x11', '--disable-video-x11', d)} \
---disable-video-svga \
+--enable-input-events --enable-pthreads --disable-video-svga \
--disable-video-picogui --disable-video-qtopia
--enable-sdl-dlopen \
--disable-rpath \
--disable-pulseaudio"
-PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}"
+PACKAGECONFIG_ALSA ?= "${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '',
d)}"
+PACKAGECONFIG_DIRECTFB ?= "${@base_contains('DISTRO_FEATURES', 'directfb',
'directfb', '', d)}"
+# Warning: "opengl" in DISTRO_FEATURES implies GL and/or GLES but libsdl
supports GL only.
+PACKAGECONFIG_OPENGL ?= "${@base_contains('DISTRO_FEATURES', 'opengl', 'opengl',
'', d)}"
+PACKAGECONFIG_TSLIB ?= "tslib"
+PACKAGECONFIG_X11 ?= "${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '',
d)}"
+
+PACKAGECONFIG ?= " \
+${PACKAGECONFIG_ALSA} \
+${PACKAGECONFIG_DIRECTFB} \
+${PACKAGECONFIG_OPENGL} \
+${PACKAGECONFIG_TSLIB} \
+${PACKAGECONFIG_X11} \
+"
+
PACKAGECONFIG[alsa] = "--enable-alsa
--disable-alsatest,--disable-alsa,alsa-lib,"
+PACKAGECONFIG[directfb] =
"--enable-video-directfb,--disable-video-directfb,directfb"
+PACKAGECONFIG[opengl] = "--enable-video-opengl,--disable-video-opengl,virtual/libgl
libglu"
+PACKAGECONFIG[tslib] = "--enable-input-tslib,--disable-input-tslib,tslib"
+PACKAGECONFIG[x11] = "--enable-video-x11,--disable-video-x11,virtual/libx11 libxext
libxrandr libxrender"
PARALLEL_MAKE = ""
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] cmake: follow ptest output format
On 2014?04?02? 06:33, Otavio Salvador wrote:
Hello,
On Tue, Apr 1, 2014 at 7:49 AM, Richard Purdie
wrote:
On Tue, 2014-04-01 at 17:09 +0800, Kai Kang wrote:
From: Li Wang
ptest output format is incorrect, according to yocto Development Manual
(http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#testing-packages-with-ptest)
The test generates output in the format used by Automake:
:
where the result can be PASS, FAIL, or SKIP, and the testname can be any
identifying string.
So we should change the test result format to match yocto ptest rules.
Signed-off-by: Li Wang
Signed-off-by: Robert Yang
Signed-off-by: Kai Kang
---
meta/recipes-devtools/cmake/cmake.inc | 1 +
.../cmake/cmake/follow_ptest_output_format.patch | 118 +
2 files changed, 119 insertions(+)
create mode 100644
meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
diff --git a/meta/recipes-devtools/cmake/cmake.inc
b/meta/recipes-devtools/cmake/cmake.inc
index 1d5303f..254af45 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -17,6 +17,7 @@ SRC_URI =
"http://www.cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz
file://aarch64-kwsys.patch \
file://qt4-fail-silent.patch \
file://cmake-2.8.11.2-FindFreetype.patch \
+ file://follow_ptest_output_format.patch \
"
inherit autotools-brokensep
diff --git a/meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
b/meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
new file mode 100644
index 000..5428df2
--- /dev/null
+++ b/meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
@@ -0,0 +1,118 @@
+cmake: follow ptest output format
+
+ptest output format is incorrect, according to yocto Development Manual
+(http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#testing-packages-with-ptest)
+5.10.6. Testing Packages With ptest
+The test generates output in the format used by Automake:
+:
+where the result can be PASS, FAIL, or SKIP, and the testname can be any
identifying string.
+So we should change the test result format to match yocto ptest rules.
+
+Signed-off-by: Li Wang
No upstream status. Is there any chance of this going upstream? Might we
be better off postprocessing the output with a script to put it into the
right format?
I agree with both remarks. It'd be good to try to get it somehow
integrated upstream and for OE-Core interim solution would be better
to 'convert' using an external script. This may break external tests
tools people may be using as it changes the format without allowing to
'revert' for normal format.
OK. I'll send it upstream and see what's going on.
--
Regards,
Neil | Kai Kang
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] cmake: follow ptest output format
Hello,
On Tue, Apr 1, 2014 at 7:49 AM, Richard Purdie
wrote:
> On Tue, 2014-04-01 at 17:09 +0800, Kai Kang wrote:
>> From: Li Wang
>>
>> ptest output format is incorrect, according to yocto Development Manual
>> (http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#testing-packages-with-ptest)
>>
>> The test generates output in the format used by Automake:
>> :
>> where the result can be PASS, FAIL, or SKIP, and the testname can be any
>> identifying string.
>>
>> So we should change the test result format to match yocto ptest rules.
>>
>> Signed-off-by: Li Wang
>> Signed-off-by: Robert Yang
>> Signed-off-by: Kai Kang
>> ---
>> meta/recipes-devtools/cmake/cmake.inc | 1 +
>> .../cmake/cmake/follow_ptest_output_format.patch | 118
>> +
>> 2 files changed, 119 insertions(+)
>> create mode 100644
>> meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
>>
>> diff --git a/meta/recipes-devtools/cmake/cmake.inc
>> b/meta/recipes-devtools/cmake/cmake.inc
>> index 1d5303f..254af45 100644
>> --- a/meta/recipes-devtools/cmake/cmake.inc
>> +++ b/meta/recipes-devtools/cmake/cmake.inc
>> @@ -17,6 +17,7 @@ SRC_URI =
>> "http://www.cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz
>> file://aarch64-kwsys.patch \
>> file://qt4-fail-silent.patch \
>> file://cmake-2.8.11.2-FindFreetype.patch \
>> + file://follow_ptest_output_format.patch \
>> "
>>
>> inherit autotools-brokensep
>> diff --git
>> a/meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
>> b/meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
>> new file mode 100644
>> index 000..5428df2
>> --- /dev/null
>> +++ b/meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
>> @@ -0,0 +1,118 @@
>> +cmake: follow ptest output format
>> +
>> +ptest output format is incorrect, according to yocto Development Manual
>> +(http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#testing-packages-with-ptest)
>> +5.10.6. Testing Packages With ptest
>> +The test generates output in the format used by Automake:
>> +:
>> +where the result can be PASS, FAIL, or SKIP, and the testname can be any
>> identifying string.
>> +So we should change the test result format to match yocto ptest rules.
>> +
>> +Signed-off-by: Li Wang
>
> No upstream status. Is there any chance of this going upstream? Might we
> be better off postprocessing the output with a script to put it into the
> right format?
I agree with both remarks. It'd be good to try to get it somehow
integrated upstream and for OE-Core interim solution would be better
to 'convert' using an external script. This may break external tests
tools people may be using as it changes the format without allowing to
'revert' for normal format.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] image.bbclass: USE_DEVFS is now useless
On Tue, 2014-04-01 at 18:51 +0100, Richard Purdie wrote: > On Tue, 2014-04-01 at 18:48 +0100, Phil Blundell wrote: > > Also note that the default for USE_DEVFS was (and is) 1, so the lack > > of this check is actually causing a difference in the default > > behaviour. If there's no appetite for reinstating the USE_DEVFS > > mechanism per se then it seems like it would be a good idea to make > > the default IMAGE_DEVICE_TABLE be blank in order to restore the > > previous default of no /dev in the rootfs. > > > > At present you get a somewhat arbitrary-seeming smattering of devices > > from meta/files/device_table-minimal.txt, including such anachronisms > > as /dev/ttySA0 and /dev/apm_bios. It's hard to imagine that anybody > > actually wants this stuff in their rootfs in this day and age. > > Can we kill apmd at the same time? Please? :) I can't see why not. I'd be surprised if there were many/any real users left, beyond possibly some legacy stuff in meta-handheld, and it definitely doesn't seem "core" by any reasonable interpretation of the term. Apart from packagegrounds, the only recipe in oe-core that mentions a dependency on apmd is matchbox-panel (for the battery applet presumably); that dependency is conditional on having apm in MACHINE_FEATURES (which it isn't by default), and it seems a bit fishy anyway since I can't immediately think of a reason why matchbox-panel would need the actual daemon. So, I think it should probably be safe to just rescind support for both apmd and the MACHINE_FEATURE apm in oe-core. If meta-handheld, meta-oe or anybody else wants to keep apmd then they can do so in their own layers although I rather hope that nobody does. p. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] opkg-0.2.2 release
Hi all, I've just released opkg-0.2.2 with the following bugfixes (issue numbers refer to the opkg issue list): - Fix '--force-reinstall' flag so that it acts as an upgrade rather than removing possibly critical packages before reinstall (issue 71) - Symlinks are now correctly removed during package uninstall (issue 91) - Fixed help and manual pages to reflect that shell globs not true regexps are accepted by opkg (issue 107) - The error message "no valid architecture" is no longer given when the architecture of a package is valid but incompatible with the current system. This is a bugfix only release with no other significant changes. I have also rebased the patches against opkg in oe-core against the new release and checked that they still apply and that the result builds with recent oe-core master. The result was tested on qemuarm by running 'opkg update' against a package feed and installing a few new packages. Do we want to try to get this in to the upcoming Yocto release or shall I delay the recipe upgrade until after the release? If you want it for the upcoming release I'll re-run my tests locally just to be sure it's looking good and then send a patch. Cheers, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Globally replace oe.utils.contains to bb.utils.contains
BitBake has the exact same code as oe.utils.contains so there's no
reason to duplicate it. We now rely on the bb.utils.contains code for
metadata.
Signed-off-by: Otavio Salvador
---
meta/classes/libc-package.bbclass| 6 +++---
meta/classes/systemd.bbclass | 12 ++--
meta/classes/update-rc.d.bbclass | 2 +-
meta/classes/utils.bbclass | 2 +-
meta/lib/oe/rootfs.py| 7 +++
meta/lib/oe/utils.py | 13 -
meta/recipes-core/dbus/dbus.inc | 2 +-
meta/recipes-core/systemd/systemd-serialgetty.bb | 2 +-
meta/recipes-core/systemd/systemd_211.bb | 4 ++--
meta/recipes-core/udev/udev.inc | 2 +-
meta/recipes-devtools/dpkg/dpkg.inc | 2 +-
meta/recipes-devtools/gcc/gcc-common.inc | 4 ++--
meta/recipes-devtools/opkg/opkg.inc | 2 +-
meta/recipes-devtools/perl/perl-ptest.inc| 2 +-
meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb | 2 +-
15 files changed, 25 insertions(+), 39 deletions(-)
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index 0af42a0..c1bc399 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -37,9 +37,9 @@ python __anonymous () {
break
# try to fix disable charsets/locales/locale-code compile fail
-if oe.utils.contains('DISTRO_FEATURES', 'libc-charsets', True, False, d)
and \
-oe.utils.contains('DISTRO_FEATURES', 'libc-locales', True, False,
d) and \
-oe.utils.contains('DISTRO_FEATURES', 'libc-locale-code', True,
False, d):
+if bb.utils.contains('DISTRO_FEATURES', 'libc-charsets', True, False, d)
and \
+bb.utils.contains('DISTRO_FEATURES', 'libc-locales', True, False,
d) and \
+bb.utils.contains('DISTRO_FEATURES', 'libc-locale-code', True,
False, d):
d.setVar('PACKAGE_NO_GCONV', '0')
else:
d.setVar('PACKAGE_NO_GCONV', '1')
diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
index 2bd63a4..a6ad723 100644
--- a/meta/classes/systemd.bbclass
+++ b/meta/classes/systemd.bbclass
@@ -15,9 +15,9 @@ python __anonymous() {
# If the distro features have systemd but not sysvinit, inhibit update-rcd
# from doing any work so that pure-systemd images don't have redundant init
# files.
-if oe.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d):
+if bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d):
d.appendVar("DEPENDS", " systemd-systemctl-native")
-if not oe.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False,
d):
+if not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False,
d):
d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
}
@@ -57,7 +57,7 @@ fi
systemd_populate_packages[vardeps] += "systemd_prerm systemd_postinst"
python systemd_populate_packages() {
-if not oe.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d):
+if not bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d):
return
def get_package_var(d, var, pkg):
@@ -172,7 +172,7 @@ PACKAGESPLITFUNCS_prepend = "systemd_populate_packages "
python rm_systemd_unitdir (){
import shutil
-if not oe.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d):
+if not bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d):
systemd_unitdir = oe.path.join(d.getVar("D", True),
d.getVar('systemd_unitdir', True))
if os.path.exists(systemd_unitdir):
shutil.rmtree(systemd_unitdir)
@@ -186,8 +186,8 @@ python rm_sysvinit_initddir (){
import shutil
sysv_initddir = oe.path.join(d.getVar("D", True), (d.getVar('INIT_D_DIR',
True) or "/etc/init.d"))
-if oe.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and \
-not oe.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d)
and \
+if bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and \
+not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d)
and \
os.path.exists(sysv_initddir):
systemd_unitdir = oe.path.join(d.getVar("D", True),
d.getVar('systemd_unitdir', True), "system")
diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index 0ac2af7..81cc976 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -117,7 +117,7 @@ python populate_packages_updatercd () {
# Check that this class isn't being inhibited (generally, by
# systemd.bbclass) before doing any work.
-if oe.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d) and \
+if bb.utils.contains('DISTRO_FEATURES', 'sysvinit'
Re: [OE-core] image.bbclass: USE_DEVFS is now useless
On Tue, 2014-04-01 at 13:01 -0500, Mark Hatle wrote: > On 4/1/14, 12:51 PM, Richard Purdie wrote: > > On Tue, 2014-04-01 at 18:48 +0100, Phil Blundell wrote: > >> Also note that the default for USE_DEVFS was (and is) 1, so the lack > >> of this check is actually causing a difference in the default > >> behaviour. If there's no appetite for reinstating the USE_DEVFS > >> mechanism per se then it seems like it would be a good idea to make > >> the default IMAGE_DEVICE_TABLE be blank in order to restore the > >> previous default of no /dev in the rootfs. > >> > >> At present you get a somewhat arbitrary-seeming smattering of devices > >> from meta/files/device_table-minimal.txt, including such anachronisms > >> as /dev/ttySA0 and /dev/apm_bios. It's hard to imagine that anybody > >> actually wants this stuff in their rootfs in this day and age. > > > > Can we kill apmd at the same time? Please? :) > > Isn't this still used on some ARM and MIPS targets? (they emulate apm for > basic > power management.) Its not gone as far as I know but whether we need the userspace portion, I'm not so sure, it just does suspend/resume event notifuication afaik these days and I doubt much uses that now. The battery interfaces were long since replaced with proper sysfs ones. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] oe.utils, utils.bbclass: Add any_contains and base_any_contains
On Tue, 2014-04-01 at 15:38 -0300, Otavio Salvador wrote:
> On Tue, Apr 1, 2014 at 2:53 PM, Richard Purdie
> wrote:
> > On Tue, 2014-04-01 at 14:07 -0300, Otavio Salvador wrote:
> >> This is similar to the contains but matches any of values. This is
> >> useful to match for example several DISTRO_FEATURES which ought to
> >> include a PACKAGECONFIG option.
> >>
> >> For example:
> >>
> >> PACKAGECONFIG ??= "${@base_any_contains('DISTRO_FEATURES', 'x11 wayland',
> >> 'gtk+', '', d)}"
> >>
> >> Signed-off-by: Otavio Salvador
> >> ---
> >> meta/classes/utils.bbclass | 3 +++
> >> meta/lib/oe/utils.py | 13 +
> >> 2 files changed, 16 insertions(+)
> >>
> >> diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
> >> index 0a533af..966eda1 100644
> >> --- a/meta/classes/utils.bbclass
> >> +++ b/meta/classes/utils.bbclass
> >> @@ -26,6 +26,9 @@ def base_version_less_or_equal(variable, checkvalue,
> >> truevalue, falsevalue, d):
> >> def base_contains(variable, checkvalues, truevalue, falsevalue, d):
> >> return oe.utils.contains(variable, checkvalues, truevalue,
> >> falsevalue, d)
> >>
> >> +def base_any_contains(variable, checkvalues, truevalue, falsevalue, d):
> >> +return oe.utils.any_contains(variable, checkvalues, truevalue,
> >> falsevalue, d)
> >> +
> >> def base_both_contain(variable1, variable2, checkvalue, d):
> >> return oe.utils.both_contain(variable1, variable2, checkvalue, d)
> >>
> >> diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
> >> index defa536..029d713 100644
> >> --- a/meta/lib/oe/utils.py
> >> +++ b/meta/lib/oe/utils.py
> >> @@ -54,6 +54,19 @@ def contains(variable, checkvalues, truevalue,
> >> falsevalue, d):
> >> return truevalue
> >> return falsevalue
> >>
> >> +def any_contains(variable, checkvalues, truevalue, falsevalue, d):
> >> +val = d.getVar(variable, True)
> >> +if not val:
> >> +return falsevalue
> >> +val = set(val.split())
> >> +if isinstance(checkvalues, basestring):
> >> +checkvalues = set(checkvalues.split())
> >> +else:
> >> +checkvalues = set(checkvalues)
> >> +if checkvalues in val:
> >> +return truevalue
> >> +return falsevalue
> >> +
> >> def both_contain(variable1, variable2, checkvalue, d):
> >> if d.getVar(variable1,1).find(checkvalue) != -1 and
> >> d.getVar(variable2,1).find(checkvalue) != -1:
> >> return checkvalue
> >
> > A more logical name is perhaps containsany().
> >
> > I'd also add that bitbake has special support for contains() and
> > optimises sstate hashes for its use. We don't have such optimisation for
> > containsany(). I think this is perhaps 1.7 material at this point.
>
> I'd use contains_any. Any problem with this?
>
> I didn't find the place bitbake handles it. Can you point the
> reference for me to look at it and complete this?
It starts at lib/bb/codeparser.py:
containsfuncs = ("bb.utils.contains", "base_contains", "oe.utils.contains")
and then that data gets passed around in various caches and so one and
is eventually used in the checksum dependencies.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] alsa-tools: Enable GTK support for X11 and Wayland
On Tue, Apr 1, 2014 at 3:50 PM, Denys Dmytriyenko wrote:
> On Tue, Apr 01, 2014 at 02:08:00PM -0300, Otavio Salvador wrote:
>> Signed-off-by: Otavio Salvador
>> ---
>> This patch depends on the alsa-tools one I sent some minutes ago
>>
>> meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
>> b/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
>> index 4f64a38..fdbe82a 100644
>> --- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
>> +++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
>> @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM =
>> "file://hdsploader/COPYING;md5=94d55d512a9ba36caa9b7df079bae1
>> SRC_URI = "ftp://ftp.alsa-project.org/pub/tools/alsa-tools-${PV}.tar.bz2 \
>> file://mips_has_no_io_h.patch \
>> file://autotools.patch \
>> - ${@base_contains('DISTRO_FEATURES', 'x11', '',
>> 'file://makefile_no_gtk.patch', d)}"
>> + ${@base_any_contains('DISTRO_FEATURES', 'x11', '',
>> 'file://makefile_no_gtk.patch', d)}"
>
> What's the reason to use any_contains here?
Forgot to add the wayland to the list. Good catch.
>> SRC_URI[md5sum] = "1ea381d00a6069a98613aa7effa4cb51"
>> SRC_URI[sha256sum] =
>> "6562611b5a6560712f109e09740a9d4fa47296b07ed9590cb44139c5f154ada2"
>> @@ -20,7 +20,7 @@ inherit autotools-brokensep
>>
>> EXTRA_OEMAKE += "GITCOMPILE_ARGS='--host=${HOST_SYS} --build=${BUILD_SYS}
>> --target=${TARGET_SYS} --with-libtool-sysroot=${STAGING_DIR_HOST}
>> --prefix=${prefix}'"
>>
>> -PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'gtk+', '',
>> d)}"
>> +PACKAGECONFIG ??= "${@base_any_contains('DISTRO_FEATURES', 'x11', 'gtk+',
>> '', d)}"
>
> Same here - what's the reason for the change?
Same here.
>> PACKAGECONFIG[gtk+] = ",,gtk+ gtk+3,"
>>
>> # configure.ac/.in doesn't exist so force copy
I am looking at the other changes Richard has commented and will send a v2.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] alsa-tools: Enable GTK support for X11 and Wayland
On Tue, Apr 01, 2014 at 02:08:00PM -0300, Otavio Salvador wrote:
> Signed-off-by: Otavio Salvador
> ---
> This patch depends on the alsa-tools one I sent some minutes ago
>
> meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
> b/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
> index 4f64a38..fdbe82a 100644
> --- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
> +++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
> @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM =
> "file://hdsploader/COPYING;md5=94d55d512a9ba36caa9b7df079bae1
> SRC_URI = "ftp://ftp.alsa-project.org/pub/tools/alsa-tools-${PV}.tar.bz2 \
> file://mips_has_no_io_h.patch \
> file://autotools.patch \
> - ${@base_contains('DISTRO_FEATURES', 'x11', '',
> 'file://makefile_no_gtk.patch', d)}"
> + ${@base_any_contains('DISTRO_FEATURES', 'x11', '',
> 'file://makefile_no_gtk.patch', d)}"
What's the reason to use any_contains here?
> SRC_URI[md5sum] = "1ea381d00a6069a98613aa7effa4cb51"
> SRC_URI[sha256sum] =
> "6562611b5a6560712f109e09740a9d4fa47296b07ed9590cb44139c5f154ada2"
> @@ -20,7 +20,7 @@ inherit autotools-brokensep
>
> EXTRA_OEMAKE += "GITCOMPILE_ARGS='--host=${HOST_SYS} --build=${BUILD_SYS}
> --target=${TARGET_SYS} --with-libtool-sysroot=${STAGING_DIR_HOST}
> --prefix=${prefix}'"
>
> -PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'gtk+', '',
> d)}"
> +PACKAGECONFIG ??= "${@base_any_contains('DISTRO_FEATURES', 'x11', 'gtk+',
> '', d)}"
Same here - what's the reason for the change?
> PACKAGECONFIG[gtk+] = ",,gtk+ gtk+3,"
>
> # configure.ac/.in doesn't exist so force copy
> --
> 1.9.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] oe.utils, utils.bbclass: Add any_contains and base_any_contains
On Tue, Apr 1, 2014 at 2:53 PM, Richard Purdie
wrote:
> On Tue, 2014-04-01 at 14:07 -0300, Otavio Salvador wrote:
>> This is similar to the contains but matches any of values. This is
>> useful to match for example several DISTRO_FEATURES which ought to
>> include a PACKAGECONFIG option.
>>
>> For example:
>>
>> PACKAGECONFIG ??= "${@base_any_contains('DISTRO_FEATURES', 'x11 wayland',
>> 'gtk+', '', d)}"
>>
>> Signed-off-by: Otavio Salvador
>> ---
>> meta/classes/utils.bbclass | 3 +++
>> meta/lib/oe/utils.py | 13 +
>> 2 files changed, 16 insertions(+)
>>
>> diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
>> index 0a533af..966eda1 100644
>> --- a/meta/classes/utils.bbclass
>> +++ b/meta/classes/utils.bbclass
>> @@ -26,6 +26,9 @@ def base_version_less_or_equal(variable, checkvalue,
>> truevalue, falsevalue, d):
>> def base_contains(variable, checkvalues, truevalue, falsevalue, d):
>> return oe.utils.contains(variable, checkvalues, truevalue, falsevalue,
>> d)
>>
>> +def base_any_contains(variable, checkvalues, truevalue, falsevalue, d):
>> +return oe.utils.any_contains(variable, checkvalues, truevalue,
>> falsevalue, d)
>> +
>> def base_both_contain(variable1, variable2, checkvalue, d):
>> return oe.utils.both_contain(variable1, variable2, checkvalue, d)
>>
>> diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
>> index defa536..029d713 100644
>> --- a/meta/lib/oe/utils.py
>> +++ b/meta/lib/oe/utils.py
>> @@ -54,6 +54,19 @@ def contains(variable, checkvalues, truevalue,
>> falsevalue, d):
>> return truevalue
>> return falsevalue
>>
>> +def any_contains(variable, checkvalues, truevalue, falsevalue, d):
>> +val = d.getVar(variable, True)
>> +if not val:
>> +return falsevalue
>> +val = set(val.split())
>> +if isinstance(checkvalues, basestring):
>> +checkvalues = set(checkvalues.split())
>> +else:
>> +checkvalues = set(checkvalues)
>> +if checkvalues in val:
>> +return truevalue
>> +return falsevalue
>> +
>> def both_contain(variable1, variable2, checkvalue, d):
>> if d.getVar(variable1,1).find(checkvalue) != -1 and
>> d.getVar(variable2,1).find(checkvalue) != -1:
>> return checkvalue
>
> A more logical name is perhaps containsany().
>
> I'd also add that bitbake has special support for contains() and
> optimises sstate hashes for its use. We don't have such optimisation for
> containsany(). I think this is perhaps 1.7 material at this point.
I'd use contains_any. Any problem with this?
I didn't find the place bitbake handles it. Can you point the
reference for me to look at it and complete this?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] image.bbclass: USE_DEVFS is now useless
On 4/1/14, 12:51 PM, Richard Purdie wrote: On Tue, 2014-04-01 at 18:48 +0100, Phil Blundell wrote: Also note that the default for USE_DEVFS was (and is) 1, so the lack of this check is actually causing a difference in the default behaviour. If there's no appetite for reinstating the USE_DEVFS mechanism per se then it seems like it would be a good idea to make the default IMAGE_DEVICE_TABLE be blank in order to restore the previous default of no /dev in the rootfs. At present you get a somewhat arbitrary-seeming smattering of devices from meta/files/device_table-minimal.txt, including such anachronisms as /dev/ttySA0 and /dev/apm_bios. It's hard to imagine that anybody actually wants this stuff in their rootfs in this day and age. Can we kill apmd at the same time? Please? :) Isn't this still used on some ARM and MIPS targets? (they emulate apm for basic power management.) If that's finally gone away -- I'd love to finally kill apmd and related. --Mark Cheers, Richard -- ___ 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
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] [PATCH 1/2] oe.utils, utils.bbclass: Add any_contains and base_any_contains
On Tue, 2014-04-01 at 14:07 -0300, Otavio Salvador wrote:
> This is similar to the contains but matches any of values. This is
> useful to match for example several DISTRO_FEATURES which ought to
> include a PACKAGECONFIG option.
>
> For example:
>
> PACKAGECONFIG ??= "${@base_any_contains('DISTRO_FEATURES', 'x11 wayland',
> 'gtk+', '', d)}"
>
> Signed-off-by: Otavio Salvador
> ---
> meta/classes/utils.bbclass | 3 +++
> meta/lib/oe/utils.py | 13 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
> index 0a533af..966eda1 100644
> --- a/meta/classes/utils.bbclass
> +++ b/meta/classes/utils.bbclass
> @@ -26,6 +26,9 @@ def base_version_less_or_equal(variable, checkvalue,
> truevalue, falsevalue, d):
> def base_contains(variable, checkvalues, truevalue, falsevalue, d):
> return oe.utils.contains(variable, checkvalues, truevalue, falsevalue, d)
>
> +def base_any_contains(variable, checkvalues, truevalue, falsevalue, d):
> +return oe.utils.any_contains(variable, checkvalues, truevalue,
> falsevalue, d)
> +
> def base_both_contain(variable1, variable2, checkvalue, d):
> return oe.utils.both_contain(variable1, variable2, checkvalue, d)
>
> diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
> index defa536..029d713 100644
> --- a/meta/lib/oe/utils.py
> +++ b/meta/lib/oe/utils.py
> @@ -54,6 +54,19 @@ def contains(variable, checkvalues, truevalue, falsevalue,
> d):
> return truevalue
> return falsevalue
>
> +def any_contains(variable, checkvalues, truevalue, falsevalue, d):
> +val = d.getVar(variable, True)
> +if not val:
> +return falsevalue
> +val = set(val.split())
> +if isinstance(checkvalues, basestring):
> +checkvalues = set(checkvalues.split())
> +else:
> +checkvalues = set(checkvalues)
> +if checkvalues in val:
> +return truevalue
> +return falsevalue
> +
> def both_contain(variable1, variable2, checkvalue, d):
> if d.getVar(variable1,1).find(checkvalue) != -1 and
> d.getVar(variable2,1).find(checkvalue) != -1:
> return checkvalue
A more logical name is perhaps containsany().
I'd also add that bitbake has special support for contains() and
optimises sstate hashes for its use. We don't have such optimisation for
containsany(). I think this is perhaps 1.7 material at this point.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] image.bbclass: USE_DEVFS is now useless
On Tue, 2014-04-01 at 18:48 +0100, Phil Blundell wrote: > Also note that the default for USE_DEVFS was (and is) 1, so the lack > of this check is actually causing a difference in the default > behaviour. If there's no appetite for reinstating the USE_DEVFS > mechanism per se then it seems like it would be a good idea to make > the default IMAGE_DEVICE_TABLE be blank in order to restore the > previous default of no /dev in the rootfs. > > At present you get a somewhat arbitrary-seeming smattering of devices > from meta/files/device_table-minimal.txt, including such anachronisms > as /dev/ttySA0 and /dev/apm_bios. It's hard to imagine that anybody > actually wants this stuff in their rootfs in this day and age. Can we kill apmd at the same time? Please? :) Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Quality of meta-oe metadata
On 4/1/14, 12:40 PM, Martin Jansa wrote:
On Tue, Apr 01, 2014 at 12:12:58PM -0500, Mark Hatle wrote:
On 3/29/14, 8:31 PM, Martin Jansa wrote:
Hi, sorry for longer e-mail, this is one of topic I would like to discuss
on OEDAM (http://openembedded.org/wiki/OEDAM), but having some feedback and
thoughts in advance will be very useful.
As people can notice from my "State of bitbake world" e-mails or
http://www.openembedded.org/wiki/Bitbake_World_Status
we never had "green" builds. There are always 20+ failed tasks in those
big builds and just reading the numbers isn't good indicator of quality,
because sooner you break something in dependency tree, fewer recipes will
be actually tested, so fewer failed tasks often means that something
important is broken.
...
3) OE releases work great and don't invalidate sstate signatures so often, so my
feeling is that most developers and projects are just using releases and
less and less people do CI. People will start complaining that something
is broken in meta-oe only when they are upgrading their project from 1.5 to
1.6 when 1.6 is released and that could be too late for fixing meta-oe
issues.
I agree, the success of what we're doing is certainly causing us 'different'
problems. :)
What I'm trying to do with it:
a) sending those e-mails and updating wiki, so that people can easily find
if some build failure is common or something which happens only for them
(something like oestats-client.bbclass page was providing in oe-classic)
It also includes log of QA issues which are usually easy to fix and great
way for new people to learn something about OE.
b) trying to refuse all patches which cause new world issue (or new QA
warn/err) - sometimes missed in logs, because it's often "hidden" by some
other issue and hard to compare 40 issues from previous build with 38
from current.
Also the issues are often triggered later by changes somewhere else...
c) fixing build/qa issues in recipes I've never used or don't even have
hardware to test - just based on assumption that something which builds
is better than broken build, even when it can have some issues in runtime.
d) contacting people who added the recipe which is now failing, often
without reply for months even when I try it multiple times :/
I agree with all of the above. In fact I suspect you are going above and beyond
what you really need to. Kudos for that BTW.
e) moving to "nonworking" directory to mark it as "known-to-be-broken",
last resort for recipes where the fix is complicated and it's not known
if someone is actually using it (because it was broken for months and
nobody replied).
+ easy to find them, because they are still in repository (instead of
git rm + revert when someone fixes it)
- layer index probably doesn't find them, because "nonworking" directory
level isn't in BBFILES, so maybe meta-broken or meta-nonworking would be
better
? some recipes are "broken" just because their dependency is broken, what
to do with such recipe, I usually just say that in commit message when
I'm moving them to "nonworking" with their broken dep.
Have you considered using the blacklist system for this?
You could do something like:
conf/layer.conf:
include ${LAYERDIR}/conf/broken.inc
conf/broken.inc:
BROKENMSG_layername = "The recipe is disabled due to a build failure. If you
need this recipe, or have gotten it to work. Please submit patches to .
Otherwise this recipe will be removed in the future."
# Recipe FOO is broken as of 2014-03-14, see ...
PNBLACKLIST[FOO] = "${BROKENMSG_layername}"
# Recipe BAR is broken as of 2013-06-13, see ...
PNBLACKLIST[BAR] = "${BROKENMSG_layername}"
Then after a given amount of time, say one year? on the broken list -- we can
then remove the items.
If the format of the comments is such that it can be easily parsed, then we can
even automate tracking of these things.
(In cases where dependencies are causing the breakage, the message cause be
augmented with that information as well...)
The advantage of the blacklist system is that if a user tries to use the recipe
they will hopefully see the blacklist message, it prevents having to git mv
recipes, and should be easier for people to find/fix the bad code via a simple
patch. (And hopefully easier to remove old cruft!)
Yes, that's another way of doing that and I was using it on world builds
as well (but without including it in layer and layer.conf to make it
"public")
e.g.
http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/log.world.20140329_001343.log/world_mask.inc
It definitely has the advantage that you can "document" it in the
message and few more details in the file itself.
Disadvantage from my POV was that I never included and enabled it in
repo, so new people didn't know about it and will still see the issues
when they try to build something broken
Re: [OE-core] image.bbclass: USE_DEVFS is now useless
On Tue, 2014-04-01 at 18:44 +0100, Phil Blundell wrote: > On Wed, 2014-02-26 at 11:11 +, Matthieu CRAPET wrote: > > > Setting IMAGE_DEVICE_TABLE or IMAGE_DEVICE_TABLES to empty string in > > an image recipe works (makedevs is not called) > > > > > > > > Should be we drop USE_DEVFS variable (meta/classes/image.bbclass) or > > (re)add check in meta/lib/oe/rootfs.py? > > > Having just tripped over this myself, I think we should re-add the > check. I was going to post a reply to the original patch submission > email but for some reason I can't find it in either my inbox or the > web archive. Also note that the default for USE_DEVFS was (and is) 1, so the lack of this check is actually causing a difference in the default behaviour. If there's no appetite for reinstating the USE_DEVFS mechanism per se then it seems like it would be a good idea to make the default IMAGE_DEVICE_TABLE be blank in order to restore the previous default of no /dev in the rootfs. At present you get a somewhat arbitrary-seeming smattering of devices from meta/files/device_table-minimal.txt, including such anachronisms as /dev/ttySA0 and /dev/apm_bios. It's hard to imagine that anybody actually wants this stuff in their rootfs in this day and age. p. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] image.bbclass: USE_DEVFS is now useless
On Wed, 2014-02-26 at 11:11 +, Matthieu CRAPET wrote: > Setting IMAGE_DEVICE_TABLE or IMAGE_DEVICE_TABLES to empty string in > an image recipe works (makedevs is not called) > > > > Should be we drop USE_DEVFS variable (meta/classes/image.bbclass) or > (re)add check in meta/lib/oe/rootfs.py? Having just tripped over this myself, I think we should re-add the check. I was going to post a reply to the original patch submission email but for some reason I can't find it in either my inbox or the web archive. p. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Quality of meta-oe metadata
On Tue, Apr 01, 2014 at 12:12:58PM -0500, Mark Hatle wrote:
> On 3/29/14, 8:31 PM, Martin Jansa wrote:
> > Hi, sorry for longer e-mail, this is one of topic I would like to discuss
> > on OEDAM (http://openembedded.org/wiki/OEDAM), but having some feedback and
> > thoughts in advance will be very useful.
> >
> > As people can notice from my "State of bitbake world" e-mails or
> > http://www.openembedded.org/wiki/Bitbake_World_Status
> > we never had "green" builds. There are always 20+ failed tasks in those
> > big builds and just reading the numbers isn't good indicator of quality,
> > because sooner you break something in dependency tree, fewer recipes will
> > be actually tested, so fewer failed tasks often means that something
> > important is broken.
>
> ...
>
> > 3) OE releases work great and don't invalidate sstate signatures so often,
> > so my
> > feeling is that most developers and projects are just using releases and
> > less and less people do CI. People will start complaining that something
> > is broken in meta-oe only when they are upgrading their project from
> > 1.5 to
> > 1.6 when 1.6 is released and that could be too late for fixing meta-oe
> > issues.
>
> I agree, the success of what we're doing is certainly causing us 'different'
> problems. :)
>
> > What I'm trying to do with it:
> >
> > a) sending those e-mails and updating wiki, so that people can easily find
> > if some build failure is common or something which happens only for them
> > (something like oestats-client.bbclass page was providing in oe-classic)
> > It also includes log of QA issues which are usually easy to fix and
> > great
> > way for new people to learn something about OE.
> > b) trying to refuse all patches which cause new world issue (or new QA
> > warn/err) - sometimes missed in logs, because it's often "hidden" by
> > some
> > other issue and hard to compare 40 issues from previous build with 38
> > from current.
> > Also the issues are often triggered later by changes somewhere else...
> > c) fixing build/qa issues in recipes I've never used or don't even have
> > hardware to test - just based on assumption that something which builds
> > is better than broken build, even when it can have some issues in
> > runtime.
> > d) contacting people who added the recipe which is now failing, often
> > without reply for months even when I try it multiple times :/
>
> I agree with all of the above. In fact I suspect you are going above and
> beyond
> what you really need to. Kudos for that BTW.
>
> > e) moving to "nonworking" directory to mark it as "known-to-be-broken",
> > last resort for recipes where the fix is complicated and it's not known
> > if someone is actually using it (because it was broken for months and
> > nobody replied).
> > + easy to find them, because they are still in repository (instead of
> > git rm + revert when someone fixes it)
> > - layer index probably doesn't find them, because "nonworking" directory
> > level isn't in BBFILES, so maybe meta-broken or meta-nonworking would
> > be
> > better
> > ? some recipes are "broken" just because their dependency is broken,
> > what
> > to do with such recipe, I usually just say that in commit message when
> > I'm moving them to "nonworking" with their broken dep.
>
> Have you considered using the blacklist system for this?
>
> You could do something like:
>
> conf/layer.conf:
> include ${LAYERDIR}/conf/broken.inc
>
> conf/broken.inc:
>
>
>
> BROKENMSG_layername = "The recipe is disabled due to a build failure. If you
> need this recipe, or have gotten it to work. Please submit patches to
> .
> Otherwise this recipe will be removed in the future."
>
> # Recipe FOO is broken as of 2014-03-14, see ...
> PNBLACKLIST[FOO] = "${BROKENMSG_layername}"
>
> # Recipe BAR is broken as of 2013-06-13, see ...
> PNBLACKLIST[BAR] = "${BROKENMSG_layername}"
>
>
> Then after a given amount of time, say one year? on the broken list -- we can
> then remove the items.
>
> If the format of the comments is such that it can be easily parsed, then we
> can
> even automate tracking of these things.
>
> (In cases where dependencies are causing the breakage, the message cause be
> augmented with that information as well...)
>
> The advantage of the blacklist system is that if a user tries to use the
> recipe
> they will hopefully see the blacklist message, it prevents having to git mv
> recipes, and should be easier for people to find/fix the bad code via a
> simple
> patch. (And hopefully easier to remove old cruft!)
Yes, that's another way of doing that and I was using it on world builds
as well (but without including it in layer and layer.conf to make it
"public")
e.g.
http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/log.world.20140329_001343.log/world_mask.inc
It definitely has the advantage that
[OE-core] OE/TSC monthly IRC meeting notes - Apr 1 2014
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 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] Quality of meta-oe metadata
On 3/29/14, 8:31 PM, Martin Jansa wrote:
Hi, sorry for longer e-mail, this is one of topic I would like to discuss
on OEDAM (http://openembedded.org/wiki/OEDAM), but having some feedback and
thoughts in advance will be very useful.
As people can notice from my "State of bitbake world" e-mails or
http://www.openembedded.org/wiki/Bitbake_World_Status
we never had "green" builds. There are always 20+ failed tasks in those
big builds and just reading the numbers isn't good indicator of quality,
because sooner you break something in dependency tree, fewer recipes will
be actually tested, so fewer failed tasks often means that something
important is broken.
...
3) OE releases work great and don't invalidate sstate signatures so often, so my
feeling is that most developers and projects are just using releases and
less and less people do CI. People will start complaining that something
is broken in meta-oe only when they are upgrading their project from 1.5 to
1.6 when 1.6 is released and that could be too late for fixing meta-oe
issues.
I agree, the success of what we're doing is certainly causing us 'different'
problems. :)
What I'm trying to do with it:
a) sending those e-mails and updating wiki, so that people can easily find
if some build failure is common or something which happens only for them
(something like oestats-client.bbclass page was providing in oe-classic)
It also includes log of QA issues which are usually easy to fix and great
way for new people to learn something about OE.
b) trying to refuse all patches which cause new world issue (or new QA
warn/err) - sometimes missed in logs, because it's often "hidden" by some
other issue and hard to compare 40 issues from previous build with 38
from current.
Also the issues are often triggered later by changes somewhere else...
c) fixing build/qa issues in recipes I've never used or don't even have
hardware to test - just based on assumption that something which builds
is better than broken build, even when it can have some issues in runtime.
d) contacting people who added the recipe which is now failing, often
without reply for months even when I try it multiple times :/
I agree with all of the above. In fact I suspect you are going above and beyond
what you really need to. Kudos for that BTW.
e) moving to "nonworking" directory to mark it as "known-to-be-broken",
last resort for recipes where the fix is complicated and it's not known
if someone is actually using it (because it was broken for months and
nobody replied).
+ easy to find them, because they are still in repository (instead of
git rm + revert when someone fixes it)
- layer index probably doesn't find them, because "nonworking" directory
level isn't in BBFILES, so maybe meta-broken or meta-nonworking would be
better
? some recipes are "broken" just because their dependency is broken, what
to do with such recipe, I usually just say that in commit message when
I'm moving them to "nonworking" with their broken dep.
Have you considered using the blacklist system for this?
You could do something like:
conf/layer.conf:
include ${LAYERDIR}/conf/broken.inc
conf/broken.inc:
BROKENMSG_layername = "The recipe is disabled due to a build failure. If you
need this recipe, or have gotten it to work. Please submit patches to .
Otherwise this recipe will be removed in the future."
# Recipe FOO is broken as of 2014-03-14, see ...
PNBLACKLIST[FOO] = "${BROKENMSG_layername}"
# Recipe BAR is broken as of 2013-06-13, see ...
PNBLACKLIST[BAR] = "${BROKENMSG_layername}"
Then after a given amount of time, say one year? on the broken list -- we can
then remove the items.
If the format of the comments is such that it can be easily parsed, then we can
even automate tracking of these things.
(In cases where dependencies are causing the breakage, the message cause be
augmented with that information as well...)
The advantage of the blacklist system is that if a user tries to use the recipe
they will hopefully see the blacklist message, it prevents having to git mv
recipes, and should be easier for people to find/fix the bad code via a simple
patch. (And hopefully easier to remove old cruft!)
--Mark
What can we do better? How to motivate more people to do CI and send fixes?
When we get to "green" state it will be easier to quickly spot new issues and
easier to fix them, because it will be clear what's causing them.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] oe.utils, utils.bbclass: Add any_contains and base_any_contains
This is similar to the contains but matches any of values. This is
useful to match for example several DISTRO_FEATURES which ought to
include a PACKAGECONFIG option.
For example:
PACKAGECONFIG ??= "${@base_any_contains('DISTRO_FEATURES', 'x11 wayland',
'gtk+', '', d)}"
Signed-off-by: Otavio Salvador
---
meta/classes/utils.bbclass | 3 +++
meta/lib/oe/utils.py | 13 +
2 files changed, 16 insertions(+)
diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
index 0a533af..966eda1 100644
--- a/meta/classes/utils.bbclass
+++ b/meta/classes/utils.bbclass
@@ -26,6 +26,9 @@ def base_version_less_or_equal(variable, checkvalue,
truevalue, falsevalue, d):
def base_contains(variable, checkvalues, truevalue, falsevalue, d):
return oe.utils.contains(variable, checkvalues, truevalue, falsevalue, d)
+def base_any_contains(variable, checkvalues, truevalue, falsevalue, d):
+return oe.utils.any_contains(variable, checkvalues, truevalue, falsevalue,
d)
+
def base_both_contain(variable1, variable2, checkvalue, d):
return oe.utils.both_contain(variable1, variable2, checkvalue, d)
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index defa536..029d713 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -54,6 +54,19 @@ def contains(variable, checkvalues, truevalue, falsevalue,
d):
return truevalue
return falsevalue
+def any_contains(variable, checkvalues, truevalue, falsevalue, d):
+val = d.getVar(variable, True)
+if not val:
+return falsevalue
+val = set(val.split())
+if isinstance(checkvalues, basestring):
+checkvalues = set(checkvalues.split())
+else:
+checkvalues = set(checkvalues)
+if checkvalues in val:
+return truevalue
+return falsevalue
+
def both_contain(variable1, variable2, checkvalue, d):
if d.getVar(variable1,1).find(checkvalue) != -1 and
d.getVar(variable2,1).find(checkvalue) != -1:
return checkvalue
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] alsa-tools: Enable GTK support for X11 and Wayland
Signed-off-by: Otavio Salvador
---
This patch depends on the alsa-tools one I sent some minutes ago
meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
b/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
index 4f64a38..fdbe82a 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
+++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM =
"file://hdsploader/COPYING;md5=94d55d512a9ba36caa9b7df079bae1
SRC_URI = "ftp://ftp.alsa-project.org/pub/tools/alsa-tools-${PV}.tar.bz2 \
file://mips_has_no_io_h.patch \
file://autotools.patch \
- ${@base_contains('DISTRO_FEATURES', 'x11', '',
'file://makefile_no_gtk.patch', d)}"
+ ${@base_any_contains('DISTRO_FEATURES', 'x11', '',
'file://makefile_no_gtk.patch', d)}"
SRC_URI[md5sum] = "1ea381d00a6069a98613aa7effa4cb51"
SRC_URI[sha256sum] =
"6562611b5a6560712f109e09740a9d4fa47296b07ed9590cb44139c5f154ada2"
@@ -20,7 +20,7 @@ inherit autotools-brokensep
EXTRA_OEMAKE += "GITCOMPILE_ARGS='--host=${HOST_SYS} --build=${BUILD_SYS}
--target=${TARGET_SYS} --with-libtool-sysroot=${STAGING_DIR_HOST}
--prefix=${prefix}'"
-PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'gtk+', '', d)}"
+PACKAGECONFIG ??= "${@base_any_contains('DISTRO_FEATURES', 'x11', 'gtk+', '',
d)}"
PACKAGECONFIG[gtk+] = ",,gtk+ gtk+3,"
# configure.ac/.in doesn't exist so force copy
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] alsa-tools: Fix build without x11
The patch had some new tool (hdajackretask) missing which were
triggering build failures in O.S. Systems' builder as:
,[ Build error in a clean tmp, without x11 ]
| checking for GTK3... no
| configure: error: Package requirements (gtk+-3.0) were not met:
|
| No package 'gtk+-3.0' found
|
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
|
| Alternatively, you may set the environment variables GTK3_CFLAGS
| and GTK3_LIBS to avoid the need to call pkg-config.
| See the pkg-config man page for more details.
| make: *** [all] Error 1
`
Signed-off-by: Otavio Salvador
---
.../recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch | 12
meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb| 4 ++--
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
b/meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
index c6cb5b1..2665726 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
+++ b/meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
@@ -1,21 +1,25 @@
Remove some sub-components which need gtk+.
-Signed-off-by: Rogerio Nunes
-
Upstream-Status: Inappropriate [configuration]
+Signed-off-by: Rogerio Nunes
+Signed-off-by: Otavio Salvador
+
diff --git a/Makefile b/Makefile
+index 2457a1c..72346d9 100644
--- a/Makefile
+++ b/Makefile
-@@ -1,8 +1,8 @@
+@@ -1,9 +1,9 @@
VERSION = 1.0.27
TOP = .
-SUBDIRS = as10k1 envy24control \
-mixartloader pcxhrloader rmedigicontrol sb16_csp seq sscape_ctl \
-us428control usx2yloader vxloader echomixer \
+-hwmixvolume hdajackretask hda-verb
+SUBDIRS = as10k1 \
+mixartloader pcxhrloader sb16_csp seq sscape_ctl \
+us428control usx2yloader vxloader \
- hwmixvolume hdajackretask hda-verb
++hwmixvolume hda-verb
all:
+ @for i in $(SUBDIRS); do \
diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
b/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
index 492f8a4..4f64a38 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
+++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.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 ${@base_contains('DISTRO_FEATURES', 'x11',
'gtk+3', '', d)}"
+DEPENDS = "alsa-lib ncurses"
LIC_FILES_CHKSUM =
"file://hdsploader/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
file://ld10k1/COPYING.LIB;md5=7fbc338309ac38fefcd64b04bb903e34"
@@ -21,7 +21,7 @@ inherit autotools-brokensep
EXTRA_OEMAKE += "GITCOMPILE_ARGS='--host=${HOST_SYS} --build=${BUILD_SYS}
--target=${TARGET_SYS} --with-libtool-sysroot=${STAGING_DIR_HOST}
--prefix=${prefix}'"
PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'gtk+', '', d)}"
-PACKAGECONFIG[gtk+] = ",,gtk+,"
+PACKAGECONFIG[gtk+] = ",,gtk+ gtk+3,"
# configure.ac/.in doesn't exist so force copy
AUTOTOOLS_COPYACLOCAL = "1"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] alsa-tools: Fix build without x11
Hello, On Tue, Apr 1, 2014 at 1:18 PM, Otavio Salvador wrote: > There is no way to disable the x11 without mangling the source code so > instead using a patch we now used a 'sed' in do_configure so it is > easier to maintain and extend. The patch had some new tools missing > which were triggering build failures in O.S. Systems' builder as: > > ,[ Build error in a clean tmp, without x11 ] > | checking for GTK3... no > | configure: error: Package requirements (gtk+-3.0) were not met: > | > | No package 'gtk+-3.0' found > | > | Consider adjusting the PKG_CONFIG_PATH environment variable if you > | installed software in a non-standard prefix. > | > | Alternatively, you may set the environment variables GTK3_CFLAGS > | and GTK3_LIBS to avoid the need to call pkg-config. > | See the pkg-config man page for more details. > | make: *** [all] Error 1 > ` > > Signed-off-by: Otavio Salvador A new, v2 version, not using sed is on the way. Ignore this one. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] gdk-pixbuf: pass GDK_PIXBUF_FATAL_LOADER where relevant
Pass GDK_PIXBUF_FATAL_LOADER to the sstate postinst and intercept so that any
problems are flagged as errors instead of being silently ignored.
Signed-off-by: Ross Burton
---
meta/classes/pixbufcache.bbclass|2 +-
scripts/postinst-intercepts/update_pixbuf_cache |1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/pixbufcache.bbclass b/meta/classes/pixbufcache.bbclass
index 414fd30..922174d 100644
--- a/meta/classes/pixbufcache.bbclass
+++ b/meta/classes/pixbufcache.bbclass
@@ -53,7 +53,7 @@ SSTATEPOSTINSTFUNCS_append_class-native = "
pixbufcache_sstate_postinst"
pixbufcache_sstate_postinst() {
if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" =
"populate_sysroot_setscene" ]
then
- gdk-pixbuf-query-loaders --update-cache
+ GDK_PIXBUF_FATAL_LOADER=1 gdk-pixbuf-query-loaders
--update-cache
fi
}
diff --git a/scripts/postinst-intercepts/update_pixbuf_cache
b/scripts/postinst-intercepts/update_pixbuf_cache
index 3f93773..95bf4f9 100644
--- a/scripts/postinst-intercepts/update_pixbuf_cache
+++ b/scripts/postinst-intercepts/update_pixbuf_cache
@@ -1,6 +1,7 @@
#!/bin/sh
export GDK_PIXBUF_MODULEDIR=$D${libdir}/gdk-pixbuf-2.0/2.10.0/loaders
+export GDK_PIXBUF_FATAL_LOADER=1
PSEUDO_UNLOAD=1 qemuwrapper -L $D -E
LD_LIBRARY_PATH=$D/${libdir}:$D/${base_libdir}\
$D${bindir}/gdk-pixbuf-query-loaders \
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] gdk-pixbuf: add an option so that loader errors are fatal
So that gdk-pixbuf-query-loader failures can be identified as such (and executed
later, or run on the target) add a magic environment variable return loader
failures from main().
Signed-off-by: Ross Burton
---
.../gdk-pixbuf/gdk-pixbuf/fatal-loader.patch | 79
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.3.bb |1 +
2 files changed, 80 insertions(+)
create mode 100644 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/fatal-loader.patch
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/fatal-loader.patch
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/fatal-loader.patch
new file mode 100644
index 000..70146c6
--- /dev/null
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/fatal-loader.patch
@@ -0,0 +1,79 @@
+If an environment variable is specified set the return value from main() to
+non-zero if the loader had errors (missing libraries, generally).
+
+Upstream-Status: Pending
+Signed-off-by: Ross Burton
+
+diff --git a/gdk-pixbuf/queryloaders.c b/gdk-pixbuf/queryloaders.c
+index a9ca015..395674a 100644
+--- a/gdk-pixbuf/queryloaders.c
b/gdk-pixbuf/queryloaders.c
+@@ -146,7 +146,7 @@ write_loader_info (GString *contents, const char *path,
GdkPixbufFormat *info)
+ g_string_append_c (contents, '\n');
+ }
+
+-static void
++static gboolean
+ query_module (GString *contents, const char *dir, const char *file)
+ {
+ char *path;
+@@ -155,6 +155,7 @@ query_module (GString *contents, const char *dir, const
char *file)
+ void(*fill_vtable) (GdkPixbufModule *module);
+ gpointer fill_info_ptr;
+ gpointer fill_vtable_ptr;
++gboolean ret = TRUE;
+
+ if (g_path_is_absolute (file))
+ path = g_strdup (file);
+@@ -204,10 +205,13 @@ query_module (GString *contents, const char *dir, const
char *file)
+g_module_error());
+ else
+ g_fprintf (stderr, "Cannot load loader %s\n", path);
++ret = FALSE;
+ }
+ if (module)
+ g_module_close (module);
+ g_free (path);
++
++return ret;
+ }
+
+ #ifdef G_OS_WIN32
+@@ -257,6 +261,7 @@ int main (int argc, char **argv)
+ GString *contents;
+ gchar *cache_file = NULL;
+ gint first_file = 1;
++gboolean success = TRUE;
+
+ #ifdef G_OS_WIN32
+ gchar *libdir;
+@@ -360,7 +365,8 @@ int main (int argc, char **argv)
+ gint len = strlen (dent);
+ if (len > SOEXT_LEN &&
+ strcmp (dent + len - SOEXT_LEN, SOEXT) ==
0) {
+-query_module (contents, path, dent);
++if (!query_module (contents, path,
dent))
++success = FALSE;
+ }
+ }
+ g_dir_close (dir);
+@@ -378,7 +384,8 @@ int main (int argc, char **argv)
+ infilename = g_locale_to_utf8 (infilename,
+-1, NULL, NULL, NULL);
+ #endif
+-query_module (contents, cwd, infilename);
++if (!query_module (contents, cwd, infilename))
++success = FALSE;
+ }
+ g_free (cwd);
+ }
+@@ -394,5 +401,8 @@ int main (int argc, char **argv)
+ else
+ g_print ("%s\n", contents->str);
+
+-return 0;
++if (g_getenv ("GDK_PIXBUF_FATAL_LOADER"))
++return success ? 0 : 1;
++else
++return 0;
+ }
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.3.bb
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.3.bb
index 85a7b43..50e54d8 100644
--- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.3.bb
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.3.bb
@@ -18,6 +18,7 @@ SRC_URI =
"${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz \
file://extending-libinstall-dependencies.patch \
file://run-ptest \
file://tests-check.patch \
+ file://fatal-loader.patch \
"
SRC_URI[md5sum] = "81161cc895eb43afd9ae7354b87e2261"
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] Make ppce300c3 tune hard-float by default
The tuning file for PowerPC e300c3 is soft-float. In OE-classic it was hard-
float and it should be as the c3 has an fpu. I have modified the tuning file
to include both a hard-float version (using the existing ppce300c3 name) and
an optional soft-float version (called ppce300c3-nf).
The following patch also passes a "--with-cpu=e300c3" argument to GLIBC.
For this to have any effect the sqrt/sqrtf implementations added by the
"glibc.fix_sqrt2.patch" are required and also an additional "Implies" file
(added to the mentioned patch as a separate patch for eglibc_2.19).
Tested with eglibc 2.19 on PowerPC MPC5125.
Signed-off-by: Mats Karrman
---
meta/conf/machine/include/tune-ppce300c3.inc | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/meta/conf/machine/include/tune-ppce300c3.inc
b/meta/conf/machine/include/tune-ppce300c3.inc
index 9431222..b19cf22 100644
--- a/meta/conf/machine/include/tune-ppce300c3.inc
+++ b/meta/conf/machine/include/tune-ppce300c3.inc
@@ -2,10 +2,22 @@ DEFAULTTUNE ?= "ppce300c3"
require conf/machine/include/powerpc/arch-powerpc.inc
+AVAILTUNES += "ppce300c3 ppce300c3-nf"
+
+# hard-float
TUNEVALID[ppce300c3] = "Enable ppce300c3 specific processor optimizations"
+TUNE_FEATURES_tune-ppce300c3 = "${TUNE_FEATURES_tune-powerpc} ppce300c3"
+TUNE_PKGARCH_tune-ppce300c3 = "ppce300c3"
+PACKAGE_EXTRA_ARCHS_tune-ppce300c3 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc}
ppce300c3"
TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3", "
-mcpu=e300c3", "", d)}"
-AVAILTUNES += "ppce300c3"
-TUNE_FEATURES_tune-ppce300c3 = "m32 fpu-soft ppce300c3"
-TUNE_PKGARCH_tune-ppce300c3 = "ppce300c3"
-PACKAGE_EXTRA_ARCHS_tune-ppce300c3 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc-nf}
ppce300c3"
+# glibc config options to make use of e300c3 (603e) specific sqrt/sqrtf
routines
+GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3",
"--with-cpu=e300c3", "", d)}"
+
+# soft-float
+TUNEVALID[ppce300c3-nf] = "Enable ppce300c3 specific processor optimizations
(no fpu)"
+TUNE_FEATURES_tune-ppce300c3-nf = "${TUNE_FEATURES_tune-powerpc-nf}
ppce300c3-nf"
+TUNE_PKGARCH_tune-ppce300c3-nf = "ppce300c3-nf"
+PACKAGE_EXTRA_ARCHS_tune-ppce300c3-nf =
"${PACKAGE_EXTRA_ARCHS_tune-powerpc-nf} ppce300c3-nf"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3-nf", "
-mcpu=e300c3", "", d)}"
+
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] eglibc_2.19: Make ppc e300c3 benefit from 603e sqrt optimizations
Tested on PowerPC MPC5125. Signed-off-by: Mats Karrman --- meta/recipes-core/eglibc/eglibc-2.19/glibc.fix_sqrt2.patch |7 +++ 1 file changed, 7 insertions(+) diff --git a/meta/recipes-core/eglibc/eglibc-2.19/glibc.fix_sqrt2.patch b/meta/recipes-core/eglibc/eglibc-2.19/glibc.fix_sqrt2.patch index 037feeb..689b79c 100644 --- a/meta/recipes-core/eglibc/eglibc-2.19/glibc.fix_sqrt2.patch +++ b/meta/recipes-core/eglibc/eglibc-2.19/glibc.fix_sqrt2.patch @@ -1477,6 +1477,13 @@ Index: libc/sysdeps/unix/sysv/linux/powerpc/powerpc32/603e/fpu/Implies +++ libc/sysdeps/unix/sysv/linux/powerpc/powerpc32/603e/fpu/Implies @@ -0,0 +1 @@ +powerpc/powerpc32/603e/fpu +Index: libc/sysdeps/unix/sysv/linux/powerpc/powerpc32/e300c3/fpu/Implies +=== +--- /dev/null libc/sysdeps/unix/sysv/linux/powerpc/powerpc32/e300c3/fpu/Implies +@@ -0,0 +1,2 @@ ++# e300c3 is a variant of 603e so use the same optimizations for sqrt ++powerpc/powerpc32/603e/fpu Index: libc/sysdeps/unix/sysv/linux/powerpc/powerpc32/e500mc/fpu/Implies === --- /dev/null -- 1.7.10.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] alsa-tools: Fix build without x11
There is no way to disable the x11 without mangling the source code so
instead using a patch we now used a 'sed' in do_configure so it is
easier to maintain and extend. The patch had some new tools missing
which were triggering build failures in O.S. Systems' builder as:
,[ Build error in a clean tmp, without x11 ]
| checking for GTK3... no
| configure: error: Package requirements (gtk+-3.0) were not met:
|
| No package 'gtk+-3.0' found
|
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
|
| Alternatively, you may set the environment variables GTK3_CFLAGS
| and GTK3_LIBS to avoid the need to call pkg-config.
| See the pkg-config man page for more details.
| make: *** [all] Error 1
`
Signed-off-by: Otavio Salvador
---
.../alsa/alsa-tools/makefile_no_gtk.patch | 21 -
meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb | 18 ++
2 files changed, 14 insertions(+), 25 deletions(-)
delete mode 100644
meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
diff --git a/meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
b/meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
deleted file mode 100644
index c6cb5b1..000
--- a/meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
+++ /dev/null
@@ -1,21 +0,0 @@
-Remove some sub-components which need gtk+.
-
-Signed-off-by: Rogerio Nunes
-
-Upstream-Status: Inappropriate [configuration]
-
-diff --git a/Makefile b/Makefile
a/Makefile
-+++ b/Makefile
-@@ -1,8 +1,8 @@
- VERSION = 1.0.27
- TOP = .
--SUBDIRS = as10k1 envy24control \
--mixartloader pcxhrloader rmedigicontrol sb16_csp seq sscape_ctl \
--us428control usx2yloader vxloader echomixer \
-+SUBDIRS = as10k1 \
-+mixartloader pcxhrloader sb16_csp seq sscape_ctl \
-+us428control usx2yloader vxloader \
- hwmixvolume hdajackretask hda-verb
-
- all:
diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
b/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
index 492f8a4..23f9360 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
+++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
@@ -3,15 +3,14 @@ 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 ${@base_contains('DISTRO_FEATURES', 'x11',
'gtk+3', '', d)}"
+DEPENDS = "alsa-lib ncurses"
LIC_FILES_CHKSUM =
"file://hdsploader/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
file://ld10k1/COPYING.LIB;md5=7fbc338309ac38fefcd64b04bb903e34"
SRC_URI = "ftp://ftp.alsa-project.org/pub/tools/alsa-tools-${PV}.tar.bz2 \
file://mips_has_no_io_h.patch \
- file://autotools.patch \
- ${@base_contains('DISTRO_FEATURES', 'x11', '',
'file://makefile_no_gtk.patch', d)}"
+ file://autotools.patch"
SRC_URI[md5sum] = "1ea381d00a6069a98613aa7effa4cb51"
SRC_URI[sha256sum] =
"6562611b5a6560712f109e09740a9d4fa47296b07ed9590cb44139c5f154ada2"
@@ -21,11 +20,22 @@ inherit autotools-brokensep
EXTRA_OEMAKE += "GITCOMPILE_ARGS='--host=${HOST_SYS} --build=${BUILD_SYS}
--target=${TARGET_SYS} --with-libtool-sysroot=${STAGING_DIR_HOST}
--prefix=${prefix}'"
PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'gtk+', '', d)}"
-PACKAGECONFIG[gtk+] = ",,gtk+,"
+PACKAGECONFIG[gtk+] = ",,gtk+ gtk+3,"
# configure.ac/.in doesn't exist so force copy
AUTOTOOLS_COPYACLOCAL = "1"
+do_configure_prepend () {
+# Disable tools which require gtk+-2.0 and gtk+-3.0
+if [ "${@base_contains('DISTRO_FEATURES', 'x11', 'yes', 'no', d)}" = "no"
]; then
+sed -e 's/echomixer//g' \
+-e 's/envy24control//g' \
+-e 's/hdajackretask//g' \
+-e 's/rmedigicontrol//g' \
+-i ${S}/Makefile
+fi
+}
+
do_compile_prepend () {
#Automake dir is not correctly detected in cross compilation case
export AUTOMAKE_DIR="$(automake --print-libdir)"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] libc-headers: set TC default to 3.14
On 14-04-01 10:54 AM, Richard Purdie wrote: On Tue, 2014-04-01 at 10:52 -0400, Bruce Ashfield wrote: On 14-04-01 10:50 AM, Martin Jansa wrote: On Tue, Apr 01, 2014 at 08:54:42AM -0400, Bruce Ashfield wrote: On 14-04-01 02:42 AM, Khem Raj wrote: On Mar 31, 2014, at 12:50 PM, Bruce Ashfield wrote: i dont believe you tested all layer combinations I've tested everything I can, as has the autobuilder. I can't offer any more than this. at this point. 3.10 being LTS I would assume its a better option to keep at 3.10 I disagree, this is consistent with other releases and the documented plan of action. I'd rather not have a massive version jump in the fall. its probably not a bad option to stick to LTS version for kernel headers after all Again, I disagree. We can maybe keep the 3.10 recipe around, Thats ugly too. We decided to stick to one version of headers last time. but the default should be 3.14, we need a matched kernel and libc-headers to get the best integration and leveraging of the latest features. If we pull the headers, pull the kernel. this all is understood, however we have to get better with timings especially changing something like kernel headers whose impact is far reaching then just updating kernel proper. We do the best we can and I can only play the timing that is dealt by the upstream projects ... but we all know that! We arranged for as much soak testing and building as we could behind the scenes. That being said, we are going to introduce the versioned kernel and libc-headers recipes in the -rc1 timeframe next time around and we captured that intention on the kernel planning wiki for 1.7 .. so that should help in the next cycle. This failure also seems new: | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemuarm-oe-linux-gnueabi/lttng-modules/2.3.3-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/../instrumentation/events/lttng-module/block.h:344:24: error: 'struct bio' has no member named 'bi_sector' |tp_assign(sector, bio->bi_sector) For qemuarm. Hmm. I did build lttng modules for it here, as I presume the autobuilder did as well. But I'll launch another build to see what happens here. I can confirm we didn't see that on the autobuilder... I was checking my core-image-kernel-dev builds for qemuarm, and managed to confuse myself momentarily (when I didn't see a build trigger), and then remembered. commit 7a974407379b43e40664cad4696b427ee8c18df0 Author: Tom Zanussi Date: Thu Mar 6 22:26:19 2014 -0600 lttng-modules: Exclude arm lttng-modules and gcc-4.8 don't mix, according to the lttng ML 'current_thread_info() not respecting program order with gcc 4.8.x', so remove it from arm builds. (From OE-Core rev: ccf687de7b856dbe6f347956743f07ff05c2533a) Signed-off-by: Tom Zanussi Signed-off-by: Richard Purdie Tom also has the fix for bio*: commit b465c0cb32696eed3ecc42fe4b5b478e4ba07914 Author: Tom Zanussi Date: Thu Mar 6 22:26:20 2014 -0600 lttng-modules: Fix 3.14 bio tracepoints The mainline 3.14 commit 'block: Astract out bvec iterator' broke the lttng-modules tracepoints. Fix them here. (From OE-Core rev: c11b29ff4f24af0445c3c6a694b8dc2037dcd7e4) Signed-off-by: Tom Zanussi Signed-off-by: Richard Purdie -- So this one is expected, and avoided .. but of course if you build it directly it will break. If there's a fix that anyone knows of for ARM, I'm available to test it here. Summary: not introduced by the uprev directly, and it was known before hand .. my foggy memory just managed to forget it.. Cheers, Bruce Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] libarchive: fix CVE-2013-0211
On Tue, Apr 1, 2014 at 12:40 AM, Hongxu Jia wrote: > On 04/01/2014 01:30 PM, Khem Raj wrote: >> >> On Fri, Mar 28, 2014 at 2:43 AM, Hongxu Jia >> wrote: >>> >>> ++ const size_t max_write = INT_MAX; >> >> I think INT_MAX is a mismatch here size_t may not be defined 'unsigned >> int' on all kind of architectures. > > > How about test the size of size_t and assigned the related MAX value: > > const size_t max_write = (sizeof(size_t) >= > sizeof(int))?INT_MAX:(sizeof(size_t) == sizeof(short))?SHRT_MAX:CHAR_MAX; > you could use something like (size_t)-1 to denote SIZE_MAX > //Hongxu > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] libc-headers: set TC default to 3.14
On Tue, 2014-04-01 at 10:52 -0400, Bruce Ashfield wrote: > On 14-04-01 10:50 AM, Martin Jansa wrote: > > On Tue, Apr 01, 2014 at 08:54:42AM -0400, Bruce Ashfield wrote: > >> On 14-04-01 02:42 AM, Khem Raj wrote: > >>> > >>> On Mar 31, 2014, at 12:50 PM, Bruce Ashfield > >>> wrote: > >>> > > i dont believe you tested all layer combinations > > I've tested everything I can, as has the autobuilder. I can't offer > any more than this. > > >> > >> > >>> at this point. 3.10 being LTS > >>> I would assume its a better option to keep at 3.10 > >> > >> > >> I disagree, this is consistent with other releases and the documented > >> plan of action. I'd rather not have a massive version jump in the fall. > > > > its probably not a bad option to stick to LTS version for kernel headers > > after all > > Again, I disagree. > > We can maybe keep the 3.10 recipe around, > >>> > >>> Thats ugly too. We decided to stick to one version of headers last time. > >>> > but the default should > be 3.14, we need a matched kernel and libc-headers to get the best > integration > and leveraging of the latest features. > > If we pull the headers, pull the kernel. > >>> > >>> this all is understood, however we have to get better with timings > >>> especially > >>> changing something like kernel headers whose impact is far reaching then > >>>just updating kernel proper. > >> > >> We do the best we can and I can only play the timing that is dealt > >> by the upstream projects ... but we all know that! > >> > >> We arranged for as much soak testing and building as we could behind > >> the scenes. > >> > >> That being said, we are going to introduce the versioned kernel and > >> libc-headers recipes in the -rc1 timeframe next time around and we > >> captured that intention on the kernel planning wiki for 1.7 .. so that > >> should help in the next cycle. > > > > This failure also seems new: > > > > | > > /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemuarm-oe-linux-gnueabi/lttng-modules/2.3.3-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/../instrumentation/events/lttng-module/block.h:344:24: > > error: 'struct bio' has no member named 'bi_sector' > > |tp_assign(sector, bio->bi_sector) > > For qemuarm. Hmm. I did build lttng modules for it here, as I presume > the autobuilder did as well. > > But I'll launch another build to see what happens here. I can confirm we didn't see that on the autobuilder... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] libc-headers: set TC default to 3.14
On 14-04-01 10:50 AM, Martin Jansa wrote: On Tue, Apr 01, 2014 at 08:54:42AM -0400, Bruce Ashfield wrote: On 14-04-01 02:42 AM, Khem Raj wrote: On Mar 31, 2014, at 12:50 PM, Bruce Ashfield wrote: i dont believe you tested all layer combinations I've tested everything I can, as has the autobuilder. I can't offer any more than this. at this point. 3.10 being LTS I would assume its a better option to keep at 3.10 I disagree, this is consistent with other releases and the documented plan of action. I'd rather not have a massive version jump in the fall. its probably not a bad option to stick to LTS version for kernel headers after all Again, I disagree. We can maybe keep the 3.10 recipe around, Thats ugly too. We decided to stick to one version of headers last time. but the default should be 3.14, we need a matched kernel and libc-headers to get the best integration and leveraging of the latest features. If we pull the headers, pull the kernel. this all is understood, however we have to get better with timings especially changing something like kernel headers whose impact is far reaching then just updating kernel proper. We do the best we can and I can only play the timing that is dealt by the upstream projects ... but we all know that! We arranged for as much soak testing and building as we could behind the scenes. That being said, we are going to introduce the versioned kernel and libc-headers recipes in the -rc1 timeframe next time around and we captured that intention on the kernel planning wiki for 1.7 .. so that should help in the next cycle. This failure also seems new: | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemuarm-oe-linux-gnueabi/lttng-modules/2.3.3-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/../instrumentation/events/lttng-module/block.h:344:24: error: 'struct bio' has no member named 'bi_sector' |tp_assign(sector, bio->bi_sector) For qemuarm. Hmm. I did build lttng modules for it here, as I presume the autobuilder did as well. But I'll launch another build to see what happens here. Bruce | ^ -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] libc-headers: set TC default to 3.14
On Tue, Apr 01, 2014 at 08:54:42AM -0400, Bruce Ashfield wrote: > On 14-04-01 02:42 AM, Khem Raj wrote: > > > > On Mar 31, 2014, at 12:50 PM, Bruce Ashfield > > wrote: > > > >>> i dont believe you tested all layer combinations > >> > >> I've tested everything I can, as has the autobuilder. I can't offer > >> any more than this. > >> > > > > at this point. 3.10 being LTS > > I would assume its a better option to keep at 3.10 > > > I disagree, this is consistent with other releases and the documented > plan of action. I'd rather not have a massive version jump in the fall. > >>> > >>> its probably not a bad option to stick to LTS version for kernel headers > >>> after all > >> > >> Again, I disagree. > >> > >> We can maybe keep the 3.10 recipe around, > > > > Thats ugly too. We decided to stick to one version of headers last time. > > > >> but the default should > >> be 3.14, we need a matched kernel and libc-headers to get the best > >> integration > >> and leveraging of the latest features. > >> > >> If we pull the headers, pull the kernel. > > > > this all is understood, however we have to get better with timings > > especially > > changing something like kernel headers whose impact is far reaching then > > just updating kernel proper. > > We do the best we can and I can only play the timing that is dealt > by the upstream projects ... but we all know that! > > We arranged for as much soak testing and building as we could behind > the scenes. > > That being said, we are going to introduce the versioned kernel and > libc-headers recipes in the -rc1 timeframe next time around and we > captured that intention on the kernel planning wiki for 1.7 .. so that > should help in the next cycle. This failure also seems new: | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemuarm-oe-linux-gnueabi/lttng-modules/2.3.3-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/../instrumentation/events/lttng-module/block.h:344:24: error: 'struct bio' has no member named 'bi_sector' |tp_assign(sector, bio->bi_sector) | ^ -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
On 1 April 2014 14:41, Florin Sarbu wrote: > Well, as far as I see it, these 2 packages (connman and libpcap) are aware > only of bluez4 at the moment. ConnMan supports both, and libpcap uses the libbluetooth API so that should link fine against either as that API didn't change much. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
On 04/01/2014 05:16 PM, Burton, Ross wrote: On 1 April 2014 14:41, Florin Sarbu wrote: Well, as far as I see it, these 2 packages (connman and libpcap) are aware only of bluez4 at the moment. ConnMan supports both, and libpcap uses the libbluetooth API so that should link fine against either as that API didn't change much. Sorry, I meant the recipes are only bluez4 aware. Florin Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] image.bbclass: make x11-base a valid image feature
make
commit 049f89155b1e80875aad6e53b21808b827c06915
Author: Chen Qi
Date: Fri Dec 20 10:45:52 2013 +0800
image.bbclass: add ability to set systemd default target
Add ability to set the default target for systemd images.
The default target for system is controlled by SYSTEMD_DEFAULT_TARGET.
The default value for this variable is derived from checking whether
IMAGE_FEATURES contains 'x11-base' or not. Each image could override
this value in its own recipe. For now, we don't need to do any change,
because all images that support graphical environment has 'x11-base'
in its IMAGE_FEATURES.
[YOCTO #3816]
Signed-off-by: Chen Qi
Signed-off-by: Saul Wold
work for users wanting graphical target. Fixes
ERROR: 'x11-base' in IMAGE_FEATURES is not a valid image feature. Valid
features: dbg-pkgs debug-tweaks dev-pkgs doc doc-pkgs package-management
ptest-pkgs qtcreator-debug read-only-rootfs splash staticdev-pkgs
Signed-off-by: Andreas Müller
---
meta/classes/image.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 29309f5..35e8d3b 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -22,7 +22,7 @@ inherit ${TESTIMAGECLASS}
# IMAGE_FEATURES may contain any available package group
IMAGE_FEATURES ?= ""
IMAGE_FEATURES[type] = "list"
-IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs"
+IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs x11-base"
# rootfs bootstrap install
ROOTFS_BOOTSTRAP_INSTALL = "${@base_contains("IMAGE_FEATURES",
"package-management", "", "${ROOTFS_PKGMANAGE_BOOTSTRAP}",d)}"
--
1.8.3.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Status Update
Executive Summary = 3.14 kernel is in and we have green builds. Managed to make a dent in the defect tracking metrics but work remains. Trending well for the release, need to keep up the bug fixing. 1.6 Release Status === The 3.14 kernel was released, we were able to updated the patches we had queued ready and it merged fairly smoothly. The builds last night after 3.14 was integrated were all green which is nice to see. This included the switch to the two new reference BSPs. This was a big risk factor for the release so its nice to see it happen smoothly, finally. I've started aggressively trying to sort out my bug backlog, I've managed to close about 10 of them over the past week, some were found not to be bugs when they were delved into, some were resolved. There are some interesting bugs to do with sstate reuse too. My remaining 6 bugs (ignoring enhancements) are probably 1.7 material at this point. I know others have been making an effort too, including in other areas like documentation. We still have some runway before release so lets use that time to best advantage and see if we can lower the bug tracking metrics further. I have been trying to merge bug fixes quickly. I have to say that there has been a sharp drop in quality of patches on the list over the last week though. As people rush to try and get things in, its clear less testing is happening and this puts the build at risk. I'm therefore starting to be quite strict on review and if something is rushed and buggy, it (and any subsequent versions) will move to the bottom of the priority list. Autobuilder === This seems to be stabilising. There has been the odd setup issue, another AB had RAID issues and the odd regression crept into the autobuilder code but things are being dealt with and feel under control. Bitbake Changes === There is still some churn on the toaster codebase but given its new code, that is probably only to be expected. There have been some useful sstate signature fixes merged. I'm particularly interested in reports from people where sstate should have been reused and it wasn't. I'd really like to get to the bottom of these issues once and for all. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] util-linux-native: fix qsort_r for CentOS 5.10
On 04/01/2014 08:34 PM, Paul Barker wrote: On 1 April 2014 13:31, Phil Blundell wrote: On Tue, 2014-04-01 at 12:41 +0100, Paul Barker wrote: The more I look at it the more I don't like this patch. It's probably a very rarely used code path but it could blow up if it's called. C provides no guarantees that calling a 3-argument function with only 2 arguments will work. Depending on calling convention it could easily result in stack corruption on some platforms. I'd suggest we try reverting the relevant bits of the upstream change from qsort to qsort_r: http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=c69bbca9c1f6645097bd20fe3a21f5a99a2a0698 I think it should just be the first 3 patch hunks in that commit. It seems vanishingly unlikely that anybody is seriously going to try to use fdisk from util-linux-native to manipulate Sun partition tables and, that being the case, it's presumably going to be quite hard to test any such change. Maybe we should just turn off support for these fringe partition table types altogether. That may be a much, much easier fix. Thank you very much, I will send a patch later:-) // Robert I've reported this to the upstream mailing list anyway as there really should be an autoconf check for qsort_r. Thanks, -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
On 04/01/2014 04:27 PM, Iorga, Cristian wrote:
Hello,
I meant, of course, BlueZ5, connman is ready for BlueZ5.
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Iorga,
Cristian
Sent: Tuesday, April 1, 2014 4:23 PM
To: Sarbu, Florin-Ionut (Wind River)
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
Hmm,
I am quite sure that connman is ready for BlueZ4 for some time.
I am not sure about libpcap, to be honest, did not investigate that.
Can you please provide some facts related to your statements?
Well, as far as I see it, these 2 packages (connman and libpcap) are
aware only of bluez4 at the moment.
connman.inc has:
PACKAGECONFIG[bluetooth] = "--enable-bluetooth, --disable-bluetooth, bluez4"
which will add a build dependency on bluez4.
And speaking of which, it seems that doing:
RDEPENDS_${PN} = "\
dbus \
${@base_contains('PACKAGECONFIG', 'bluetooth', 'bluez4',
'', d)} \
is superfluous as it may be achieved by changing the PACKAGECONFIG live
above to something like:
PACKAGECONFIG[bluetooth] = "--enable-bluetooth, --disable-bluetooth,
bluez4, bluez4"
to achieve the same thing.
Be it as it may, it looks like at this point, having bluetooth in
DISTRO_FEATURES drags in bluez4 and no configurable way to use bluez5.
Florin
Regards,
Cristian
-Original Message-
From: Florin Sarbu [mailto:florin.sa...@windriver.com]
Sent: Tuesday, April 1, 2014 3:27 PM
To: Iorga, Cristian
Cc: openembedded-core@lists.openembedded.org; Richard Purdie
Subject: Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
Please see inline.
On 04/01/2014 02:23 PM, Iorga, Cristian wrote:
Hi all,
I would also say that is an important change, with some possible unforeseen
consequences.
The YP is in the stabilization phase for 1.6 release.
In my opinion, the support for and change to BlueZ (overall) should be
postponed to 1.7.
Also, this not the proper solution, because, in the end, if BlueZ4 will still
be around in 1.7 (which is not my intention, to be honest), this will be worked
out with a Bluetooth stack provider (which can be BZ4 or, preferably, BZ5).
I vote against this patch.
The idea was that people could just have bluetooth in DISTRO_FEATURES and
things would be unchanged, as in use bluez4 like now, and if somebody else
wants bluez5, just add bluez5 to PACKAGECONFIG in some .bbappend's and not rely
on the bluetooth DISTRO_FEATURE until bluez5 supersedes bluez4.
At the moment, one cannot use bluez5 as connman and libpcap explicitly depend
on bluez4.
Regards,
Cristian Iorga
YP
Intel Corporation
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Richard Purdie
Sent: Tuesday, April 1, 2014 1:51 PM
To: Sarbu, Florin-Ionut (Wind River)
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support
for bluez5
On Tue, 2014-04-01 at 13:09 +0300, Florin Sarbu wrote:
Currently connman can only RDEPEND on bluez4.
This patch adds support for having bluez5 in PACKAGECONFIG and get
connman RDEPEND on bluez5 if desired.
Signed-off-by: Florin Sarbu
---
meta/recipes-connectivity/connman/connman.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/connman/connman.inc
b/meta/recipes-connectivity/connman/connman.inc
index b3147c9..53a6a4f 100644
--- a/meta/recipes-connectivity/connman/connman.inc
+++ b/meta/recipes-connectivity/connman/connman.inc
@@ -32,7 +32,7 @@ EXTRA_OECONF += "\
PACKAGECONFIG ??= "wispr \
${@base_contains('DISTRO_FEATURES', 'wifi','wifi', '',
d)} \
- ${@base_contains('DISTRO_FEATURES',
'bluetooth','bluetooth', '', d)} \
+ ${@base_contains('DISTRO_FEATURES',
+ 'bluetooth','bluez4', '', d)} \
${@base_contains('DISTRO_FEATURES', '3g','3g',
'', d)} \ "
@@ -42,6 +42,7 @@ PACKAGECONFIG ??= "wispr \
PACKAGECONFIG[wifi] = "--enable-wifi, --disable-wifi, wpa-supplicant"
PACKAGECONFIG[bluetooth] = "--enable-bluetooth, --disable-bluetooth, bluez4"
You renamed the option above but didn't here and hence broke bluez4.
This is not the quality of patch expected at -rc time for a release :(.
Sorry, I overlooked the change in that one and the others remaining after that.
Cheers,
Richard
+PACKAGECONFIG[bluez5] = "--enable-bluetooth, --disable-bluetooth, bluez5"
Also, to not get it disable bluetooth when using bluez4, the above line should
look something like:
+PACKAGECONFIG[bluez5] = "--enable-bluetooth, , bluez5"
Want me to send another patch or we just drop it and people just do what they
need in their own .bbappend's in order to have bluez5 in?
Thank you,
Florin
PACKA
Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
Hello,
I meant, of course, BlueZ5, connman is ready for BlueZ5.
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Iorga,
Cristian
Sent: Tuesday, April 1, 2014 4:23 PM
To: Sarbu, Florin-Ionut (Wind River)
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
Hmm,
I am quite sure that connman is ready for BlueZ4 for some time.
I am not sure about libpcap, to be honest, did not investigate that.
Can you please provide some facts related to your statements?
Regards,
Cristian
-Original Message-
From: Florin Sarbu [mailto:florin.sa...@windriver.com]
Sent: Tuesday, April 1, 2014 3:27 PM
To: Iorga, Cristian
Cc: openembedded-core@lists.openembedded.org; Richard Purdie
Subject: Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
Please see inline.
On 04/01/2014 02:23 PM, Iorga, Cristian wrote:
> Hi all,
>
> I would also say that is an important change, with some possible unforeseen
> consequences.
> The YP is in the stabilization phase for 1.6 release.
> In my opinion, the support for and change to BlueZ (overall) should be
> postponed to 1.7.
> Also, this not the proper solution, because, in the end, if BlueZ4 will still
> be around in 1.7 (which is not my intention, to be honest), this will be
> worked out with a Bluetooth stack provider (which can be BZ4 or, preferably,
> BZ5).
>
> I vote against this patch.
The idea was that people could just have bluetooth in DISTRO_FEATURES and
things would be unchanged, as in use bluez4 like now, and if somebody else
wants bluez5, just add bluez5 to PACKAGECONFIG in some .bbappend's and not rely
on the bluetooth DISTRO_FEATURE until bluez5 supersedes bluez4.
At the moment, one cannot use bluez5 as connman and libpcap explicitly depend
on bluez4.
>
> Regards,
> Cristian Iorga
> YP
> Intel Corporation
>
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Tuesday, April 1, 2014 1:51 PM
> To: Sarbu, Florin-Ionut (Wind River)
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support
> for bluez5
>
> On Tue, 2014-04-01 at 13:09 +0300, Florin Sarbu wrote:
>> Currently connman can only RDEPEND on bluez4.
>> This patch adds support for having bluez5 in PACKAGECONFIG and get
>> connman RDEPEND on bluez5 if desired.
>>
>> Signed-off-by: Florin Sarbu
>> ---
>> meta/recipes-connectivity/connman/connman.inc | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-connectivity/connman/connman.inc
>> b/meta/recipes-connectivity/connman/connman.inc
>> index b3147c9..53a6a4f 100644
>> --- a/meta/recipes-connectivity/connman/connman.inc
>> +++ b/meta/recipes-connectivity/connman/connman.inc
>> @@ -32,7 +32,7 @@ EXTRA_OECONF += "\
>>
>> PACKAGECONFIG ??= "wispr \
>> ${@base_contains('DISTRO_FEATURES', 'wifi','wifi', '',
>> d)} \
>> - ${@base_contains('DISTRO_FEATURES',
>> 'bluetooth','bluetooth', '', d)} \
>> + ${@base_contains('DISTRO_FEATURES',
>> + 'bluetooth','bluez4', '', d)} \
>> ${@base_contains('DISTRO_FEATURES', '3g','3g',
>> '', d)} \ "
>>
>> @@ -42,6 +42,7 @@ PACKAGECONFIG ??= "wispr \
>>
>> PACKAGECONFIG[wifi] = "--enable-wifi, --disable-wifi, wpa-supplicant"
>> PACKAGECONFIG[bluetooth] = "--enable-bluetooth, --disable-bluetooth,
>> bluez4"
> You renamed the option above but didn't here and hence broke bluez4.
> This is not the quality of patch expected at -rc time for a release :(.
Sorry, I overlooked the change in that one and the others remaining after that.
>
> Cheers,
>
> Richard
>
>> +PACKAGECONFIG[bluez5] = "--enable-bluetooth, --disable-bluetooth, bluez5"
Also, to not get it disable bluetooth when using bluez4, the above line should
look something like:
+PACKAGECONFIG[bluez5] = "--enable-bluetooth, , bluez5"
Want me to send another patch or we just drop it and people just do what they
need in their own .bbappend's in order to have bluez5 in?
Thank you,
Florin
>> PACKAGECONFIG[3g] = "--enable-ofono, --disable-ofono, ofono"
>> PACKAGECONFIG[tist] = "--enable-tist,--disable-tist,"
>> PACKAGECONFIG[openvpn] = "--enable-openvpn
>> --with-openvpn=${sbindir}/openvpn,--disable-openvpn,,openvpn"
>> @@ -114,6 +115,7 @@ RPROVIDES_${PN} = "\ RDEPENDS_${PN} = "\
>>dbus \
>>${@base_contains('PACKAGECONFIG', 'bluetooth', 'bluez4', '',
>> d)} \
>> + ${@base_contains('PACKAGECONFIG', 'bluez5', 'bluez5', '', d)} \
>>${@base_contains('PACKAGECONFIG', 'wifi','wpa-supplicant', '', d)} \
>>${@base_contains('PACKAGECONFIG', '3g','ofono', '', d)} \
>>xuser-account \
>> --
>> 1.9.1
>>
>
> --
> ___
Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
Hmm,
I am quite sure that connman is ready for BlueZ4 for some time.
I am not sure about libpcap, to be honest, did not investigate that.
Can you please provide some facts related to your statements?
Regards,
Cristian
-Original Message-
From: Florin Sarbu [mailto:florin.sa...@windriver.com]
Sent: Tuesday, April 1, 2014 3:27 PM
To: Iorga, Cristian
Cc: openembedded-core@lists.openembedded.org; Richard Purdie
Subject: Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
Please see inline.
On 04/01/2014 02:23 PM, Iorga, Cristian wrote:
> Hi all,
>
> I would also say that is an important change, with some possible unforeseen
> consequences.
> The YP is in the stabilization phase for 1.6 release.
> In my opinion, the support for and change to BlueZ (overall) should be
> postponed to 1.7.
> Also, this not the proper solution, because, in the end, if BlueZ4 will still
> be around in 1.7 (which is not my intention, to be honest), this will be
> worked out with a Bluetooth stack provider (which can be BZ4 or, preferably,
> BZ5).
>
> I vote against this patch.
The idea was that people could just have bluetooth in DISTRO_FEATURES and
things would be unchanged, as in use bluez4 like now, and if somebody else
wants bluez5, just add bluez5 to PACKAGECONFIG in some .bbappend's and not rely
on the bluetooth DISTRO_FEATURE until bluez5 supersedes bluez4.
At the moment, one cannot use bluez5 as connman and libpcap explicitly depend
on bluez4.
>
> Regards,
> Cristian Iorga
> YP
> Intel Corporation
>
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Tuesday, April 1, 2014 1:51 PM
> To: Sarbu, Florin-Ionut (Wind River)
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support
> for bluez5
>
> On Tue, 2014-04-01 at 13:09 +0300, Florin Sarbu wrote:
>> Currently connman can only RDEPEND on bluez4.
>> This patch adds support for having bluez5 in PACKAGECONFIG and get
>> connman RDEPEND on bluez5 if desired.
>>
>> Signed-off-by: Florin Sarbu
>> ---
>> meta/recipes-connectivity/connman/connman.inc | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-connectivity/connman/connman.inc
>> b/meta/recipes-connectivity/connman/connman.inc
>> index b3147c9..53a6a4f 100644
>> --- a/meta/recipes-connectivity/connman/connman.inc
>> +++ b/meta/recipes-connectivity/connman/connman.inc
>> @@ -32,7 +32,7 @@ EXTRA_OECONF += "\
>>
>> PACKAGECONFIG ??= "wispr \
>> ${@base_contains('DISTRO_FEATURES', 'wifi','wifi', '',
>> d)} \
>> - ${@base_contains('DISTRO_FEATURES',
>> 'bluetooth','bluetooth', '', d)} \
>> + ${@base_contains('DISTRO_FEATURES',
>> + 'bluetooth','bluez4', '', d)} \
>> ${@base_contains('DISTRO_FEATURES', '3g','3g',
>> '', d)} \ "
>>
>> @@ -42,6 +42,7 @@ PACKAGECONFIG ??= "wispr \
>>
>> PACKAGECONFIG[wifi] = "--enable-wifi, --disable-wifi, wpa-supplicant"
>> PACKAGECONFIG[bluetooth] = "--enable-bluetooth, --disable-bluetooth,
>> bluez4"
> You renamed the option above but didn't here and hence broke bluez4.
> This is not the quality of patch expected at -rc time for a release :(.
Sorry, I overlooked the change in that one and the others remaining after that.
>
> Cheers,
>
> Richard
>
>> +PACKAGECONFIG[bluez5] = "--enable-bluetooth, --disable-bluetooth, bluez5"
Also, to not get it disable bluetooth when using bluez4, the above line should
look something like:
+PACKAGECONFIG[bluez5] = "--enable-bluetooth, , bluez5"
Want me to send another patch or we just drop it and people just do what they
need in their own .bbappend's in order to have bluez5 in?
Thank you,
Florin
>> PACKAGECONFIG[3g] = "--enable-ofono, --disable-ofono, ofono"
>> PACKAGECONFIG[tist] = "--enable-tist,--disable-tist,"
>> PACKAGECONFIG[openvpn] = "--enable-openvpn
>> --with-openvpn=${sbindir}/openvpn,--disable-openvpn,,openvpn"
>> @@ -114,6 +115,7 @@ RPROVIDES_${PN} = "\ RDEPENDS_${PN} = "\
>>dbus \
>>${@base_contains('PACKAGECONFIG', 'bluetooth', 'bluez4', '',
>> d)} \
>> + ${@base_contains('PACKAGECONFIG', 'bluez5', 'bluez5', '', d)} \
>>${@base_contains('PACKAGECONFIG', 'wifi','wpa-supplicant', '', d)} \
>>${@base_contains('PACKAGECONFIG', '3g','ofono', '', d)} \
>>xuser-account \
>> --
>> 1.9.1
>>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dora][PATCH] opkg-utils: Update to latest git master
On 1 April 2014 13:29, Paul Barker wrote:
> On 1 April 2014 01:58, Denys Dmytriyenko wrote:
>> From: Denys Dmytriyenko
>>
>> The latest commit in opkg-utils allows packages created by opkg-build to be
>> read
>> by dpkg-deb again.
>>
>> (Based on OE-Core master rev: 219944af2700ce9dbc425fac384cd32b0a802123,
>> but all of the update-alternative fixes from master are skipped)
>>
>> Signed-off-by: Denys Dmytriyenko
>> Cc: Paul Barker
>> ---
>> meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
>> b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
>> index 279cb74..fef0d13 100644
>> --- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
>> +++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
>> @@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
>> "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
>>
>> file://opkg.py;beginline=1;endline=18;md5=15917491ad6bf7acc666ca5f7cc1e083"
>> RDEPENDS_${PN} = "python python-shell python-io python-math python-crypt
>> python-logging python-fcntl python-subprocess python-pickle
>> python-compression python-textutils python-stringold"
>> RDEPENDS_${PN}_class-native = ""
>> -SRCREV = "757a1664a440c60e8126443bf984e4bdf374c327"
>> +SRCREV = "c33b217016ee911718b10c9d57f9912935baf5a9"
>> PV = "0.1.8+git${SRCPV}"
>>
>> SRC_URI = "git://git.yoctoproject.org/opkg-utils \
>> --
>> 1.9.1
>>
>
> Personally I would prefer rebasing the existing patch and fixing the
> merge conflict, maintaining the patch author and existing sign offs
> and adding your sign off to the end. I don't know if there's a policy
> on this for Yocto Project.
>
> I've Cc'd Robert Yang as he's the stable branch maintainer for Dora as
> per https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance
>
Infact, NACK on this. opkg-utils/Makefile @
c33b217016ee911718b10c9d57f9912935baf5a9 lists update-alternatives to
be installed on 'make install'.
If you want just this fix, you need to keep SRCREV as is and add the
change from c33b217016ee911718b10c9d57f9912935baf5a9 as a new patch
within oe-core.
Thanks,
--
Paul Barker
Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libpcap.inc: Add PACKAGECONFIG support for bluez
On 04/01/2014 01:47 PM, Martin Jansa wrote:
On Tue, Apr 01, 2014 at 01:16:40PM +0300, Florin Sarbu wrote:
This patch adds support for having bluez5 in PACKAGECONFIG
and get libpcap DEPEND on bluez5.
Signed-off-by: Florin Sarbu
---
meta/recipes-connectivity/libpcap/libpcap.inc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/libpcap/libpcap.inc
b/meta/recipes-connectivity/libpcap/libpcap.inc
index a984e05..1613567 100644
--- a/meta/recipes-connectivity/libpcap/libpcap.inc
+++ b/meta/recipes-connectivity/libpcap/libpcap.inc
@@ -10,8 +10,9 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=1d4b0366557951c84a94fabe3529f867 \
file://pcap.h;beginline=1;endline=34;md5=8d6cf7e17d5745010d633e30bc529ea9"
DEPENDS = "flex-native bison-native libnl"
-PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'bluetooth', 'bluetooth', '', d)}"
-PACKAGECONFIG[bluetooth] = "--enable-bluetooth,--disable-bluetooth,bluez4"
+PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'bluetooth', 'bluez4', '',
d)}"
+PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
+PACKAGECONFIG[bluez5] = "--enable-bluetooth,--disable-bluetooth,bluez5"
Does it work correctly?
If you don't enable both you will always get at least one
--disable-bluetooth and depending on order how packageconfigs were
processed it will be disabled or not.
You are correct, the line:
+PACKAGECONFIG[bluez5] = "--enable-bluetooth,--disable-bluetooth,bluez5"
should be:
+PACKAGECONFIG[bluez5] = "--enable-bluetooth,,bluez5"
to get it to work as expected until bluez5 is replacing entirely bluez4.
Florin
PACKAGECONFIG[canusb] = "--enable-canusb,--enable-canusb=no,libusb"
PACKAGECONFIG[libnl1] = "--with-libnl,--without-libnl,libnl1,libnl1"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] libc-headers: set TC default to 3.14
On 14-04-01 02:42 AM, Khem Raj wrote: On Mar 31, 2014, at 12:50 PM, Bruce Ashfield wrote: i dont believe you tested all layer combinations I've tested everything I can, as has the autobuilder. I can't offer any more than this. at this point. 3.10 being LTS I would assume its a better option to keep at 3.10 I disagree, this is consistent with other releases and the documented plan of action. I'd rather not have a massive version jump in the fall. its probably not a bad option to stick to LTS version for kernel headers after all Again, I disagree. We can maybe keep the 3.10 recipe around, Thats ugly too. We decided to stick to one version of headers last time. but the default should be 3.14, we need a matched kernel and libc-headers to get the best integration and leveraging of the latest features. If we pull the headers, pull the kernel. this all is understood, however we have to get better with timings especially changing something like kernel headers whose impact is far reaching then just updating kernel proper. We do the best we can and I can only play the timing that is dealt by the upstream projects ... but we all know that! We arranged for as much soak testing and building as we could behind the scenes. That being said, we are going to introduce the versioned kernel and libc-headers recipes in the -rc1 timeframe next time around and we captured that intention on the kernel planning wiki for 1.7 .. so that should help in the next cycle. Cheers, Bruce -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] util-linux-native: fix qsort_r for CentOS 5.10
On 1 April 2014 13:31, Phil Blundell wrote: > On Tue, 2014-04-01 at 12:41 +0100, Paul Barker wrote: >> The more I look at it the more I don't like this patch. It's probably >> a very rarely used code path but it could blow up if it's called. C >> provides no guarantees that calling a 3-argument function with only 2 >> arguments will work. Depending on calling convention it could easily >> result in stack corruption on some platforms. >> >> I'd suggest we try reverting the relevant bits of the upstream change >> from qsort to >> qsort_r: >> http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=c69bbca9c1f6645097bd20fe3a21f5a99a2a0698 >> >> I think it should just be the first 3 patch hunks in that commit. > > It seems vanishingly unlikely that anybody is seriously going to try to > use fdisk from util-linux-native to manipulate Sun partition tables and, > that being the case, it's presumably going to be quite hard to test any > such change. Maybe we should just turn off support for these fringe > partition table types altogether. > That may be a much, much easier fix. I've reported this to the upstream mailing list anyway as there really should be an autoconf check for qsort_r. Thanks, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] util-linux-native: fix qsort_r for CentOS 5.10
On Tue, 2014-04-01 at 12:41 +0100, Paul Barker wrote: > The more I look at it the more I don't like this patch. It's probably > a very rarely used code path but it could blow up if it's called. C > provides no guarantees that calling a 3-argument function with only 2 > arguments will work. Depending on calling convention it could easily > result in stack corruption on some platforms. > > I'd suggest we try reverting the relevant bits of the upstream change > from qsort to > qsort_r: > http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=c69bbca9c1f6645097bd20fe3a21f5a99a2a0698 > > I think it should just be the first 3 patch hunks in that commit. It seems vanishingly unlikely that anybody is seriously going to try to use fdisk from util-linux-native to manipulate Sun partition tables and, that being the case, it's presumably going to be quite hard to test any such change. Maybe we should just turn off support for these fringe partition table types altogether. p. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dora][PATCH] opkg-utils: Update to latest git master
On 1 April 2014 01:58, Denys Dmytriyenko wrote:
> From: Denys Dmytriyenko
>
> The latest commit in opkg-utils allows packages created by opkg-build to be
> read
> by dpkg-deb again.
>
> (Based on OE-Core master rev: 219944af2700ce9dbc425fac384cd32b0a802123,
> but all of the update-alternative fixes from master are skipped)
>
> Signed-off-by: Denys Dmytriyenko
> Cc: Paul Barker
> ---
> meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> index 279cb74..fef0d13 100644
> --- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> +++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> @@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
>
> file://opkg.py;beginline=1;endline=18;md5=15917491ad6bf7acc666ca5f7cc1e083"
> RDEPENDS_${PN} = "python python-shell python-io python-math python-crypt
> python-logging python-fcntl python-subprocess python-pickle
> python-compression python-textutils python-stringold"
> RDEPENDS_${PN}_class-native = ""
> -SRCREV = "757a1664a440c60e8126443bf984e4bdf374c327"
> +SRCREV = "c33b217016ee911718b10c9d57f9912935baf5a9"
> PV = "0.1.8+git${SRCPV}"
>
> SRC_URI = "git://git.yoctoproject.org/opkg-utils \
> --
> 1.9.1
>
Personally I would prefer rebasing the existing patch and fixing the
merge conflict, maintaining the patch author and existing sign offs
and adding your sign off to the end. I don't know if there's a policy
on this for Yocto Project.
I've Cc'd Robert Yang as he's the stable branch maintainer for Dora as
per https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance
Thanks,
--
Paul Barker
Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
Please see inline.
On 04/01/2014 02:23 PM, Iorga, Cristian wrote:
Hi all,
I would also say that is an important change, with some possible unforeseen
consequences.
The YP is in the stabilization phase for 1.6 release.
In my opinion, the support for and change to BlueZ (overall) should be
postponed to 1.7.
Also, this not the proper solution, because, in the end, if BlueZ4 will still
be around in 1.7 (which is not my intention, to be honest), this will be worked
out with a Bluetooth stack provider (which can be BZ4 or, preferably, BZ5).
I vote against this patch.
The idea was that people could just have bluetooth in DISTRO_FEATURES
and things would be unchanged, as in use bluez4 like now, and if
somebody else wants bluez5, just add bluez5 to PACKAGECONFIG in some
.bbappend's and not rely on the bluetooth DISTRO_FEATURE until bluez5
supersedes bluez4.
At the moment, one cannot use bluez5 as connman and libpcap explicitly
depend on bluez4.
Regards,
Cristian Iorga
YP
Intel Corporation
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Richard
Purdie
Sent: Tuesday, April 1, 2014 1:51 PM
To: Sarbu, Florin-Ionut (Wind River)
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
On Tue, 2014-04-01 at 13:09 +0300, Florin Sarbu wrote:
Currently connman can only RDEPEND on bluez4.
This patch adds support for having bluez5 in PACKAGECONFIG and get
connman RDEPEND on bluez5 if desired.
Signed-off-by: Florin Sarbu
---
meta/recipes-connectivity/connman/connman.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/connman/connman.inc
b/meta/recipes-connectivity/connman/connman.inc
index b3147c9..53a6a4f 100644
--- a/meta/recipes-connectivity/connman/connman.inc
+++ b/meta/recipes-connectivity/connman/connman.inc
@@ -32,7 +32,7 @@ EXTRA_OECONF += "\
PACKAGECONFIG ??= "wispr \
${@base_contains('DISTRO_FEATURES', 'wifi','wifi', '', d)}
\
- ${@base_contains('DISTRO_FEATURES',
'bluetooth','bluetooth', '', d)} \
+ ${@base_contains('DISTRO_FEATURES',
+ 'bluetooth','bluez4', '', d)} \
${@base_contains('DISTRO_FEATURES', '3g','3g', '',
d)} \ "
@@ -42,6 +42,7 @@ PACKAGECONFIG ??= "wispr \
PACKAGECONFIG[wifi] = "--enable-wifi, --disable-wifi, wpa-supplicant"
PACKAGECONFIG[bluetooth] = "--enable-bluetooth, --disable-bluetooth, bluez4"
You renamed the option above but didn't here and hence broke bluez4.
This is not the quality of patch expected at -rc time for a release :(.
Sorry, I overlooked the change in that one and the others remaining
after that.
Cheers,
Richard
+PACKAGECONFIG[bluez5] = "--enable-bluetooth, --disable-bluetooth, bluez5"
Also, to not get it disable bluetooth when using bluez4, the above line
should look something like:
+PACKAGECONFIG[bluez5] = "--enable-bluetooth, , bluez5"
Want me to send another patch or we just drop it and people just do what
they need in their own .bbappend's in order to have bluez5 in?
Thank you,
Florin
PACKAGECONFIG[3g] = "--enable-ofono, --disable-ofono, ofono"
PACKAGECONFIG[tist] = "--enable-tist,--disable-tist,"
PACKAGECONFIG[openvpn] = "--enable-openvpn
--with-openvpn=${sbindir}/openvpn,--disable-openvpn,,openvpn"
@@ -114,6 +115,7 @@ RPROVIDES_${PN} = "\ RDEPENDS_${PN} = "\
dbus \
${@base_contains('PACKAGECONFIG', 'bluetooth', 'bluez4', '', d)} \
+ ${@base_contains('PACKAGECONFIG', 'bluez5', 'bluez5', '', d)} \
${@base_contains('PACKAGECONFIG', 'wifi','wpa-supplicant', '', d)} \
${@base_contains('PACKAGECONFIG', '3g','ofono', '', d)} \
xuser-account \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-arch: Always use ld.bfd to link the kernel
On Fri, 2014-03-28 at 13:28 -0400, Denys Dmytriyenko wrote:
> > KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH}"
> > -KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld ${HOST_LD_KERNEL_ARCH}"
> > +KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
> > KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
>
> I know this is almost a year-old change.
>
> The question I have is - what should one do when using an external toolchain
> that doesn't have ld.bfd provided? I know these days with gold vs. BFD
> linker,
> it's common to have ld.bfd, but there could be exceptions...
>
> Should this assignment be conditional, so it's easier to override from
> local.conf or distro?
Making those assignments all be conditional doesn't sound like a totally
unreasonable plan to me. (I think it would be a bad idea to make
KERNEL_LD alone be conditional; if we change one then we should change
all four.)
Alternatively I guess you could take the view that the external
toolchain packaging ought to be providing an ld.bfd symlink if there
isn't already one. There are other places in oe-core which mention
ld.bfd (one of them is gcc-cross-initial, which probably wouldn't be an
issue for external toolchains, but another is u-boot which might be) and
fixing the problem in the external toolchain would avoid the need to
find and fix every place that refers to ld.bfd. So I think this would
be my preference.
p.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] Make ppce300c3 tune hard-float by default
On Tue, 2014-04-01 at 11:44 +, Mats Kärrman wrote:
> Hi Richard,
>
> On Tuesday, April 01, 2014 12:48 PM, Richard Purdie wrote:
> > On Tue, 2014-04-01 at 07:54 +, Mats Kärrman wrote:
> >> Hi Khem,
> >>
> >> Thanks for your feedback!
> >>
> >> On Tuesday, April 01, 2014 7:37 AM, Khem Raj wrote:
> >> > On Fri, Mar 28, 2014 at 9:43 AM, Mats Kärrman
> >> > wrote:
> >> >> +# glibc configure options to make use of 603e specific sqrt/sqrtf
> >> >> routines
> >> >> +GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES",
> >> >> "ppce300c3", "--with-cpu=e300c3", "", d)}"
> >> >
> >> > looks good, may be the comment above can be more explanatory saying that
> >> > glibc aliases e300c3 sqrt/sqrtf to 600e versions
> >>
> >> The above statement depends on an added "Implies" file in eglibc and,
> >> more important on a previous patch adding support for 603e/fpu sqrt.
> >>
> >> How is the new Implies file best added, as a patch to the previous patch
> >> or as a new patch?
> >
> >Since this hasn't merge yet please send another patch. If it had merged,
> >an incremental one would be needed.
> >
>
> Sorry if I was unclear. The patch I meant is "glibc.fix_sqrt2.patch" which
> is part of both Dora and master OE-core. This patch adds the sqrt routines
> I'm after and also adds Implies for relevant CPU's. What I need is one more
> Implies that makes sure this code is used for e300c3 also.
>
> Or did you mean merged upstream?
Sorry, its me who misunderstood. Please send a patch which updates that
patch file with the extra information.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] Make ppce300c3 tune hard-float by default
Hi Richard,
On Tuesday, April 01, 2014 12:48 PM, Richard Purdie wrote:
> On Tue, 2014-04-01 at 07:54 +, Mats Kärrman wrote:
>> Hi Khem,
>>
>> Thanks for your feedback!
>>
>> On Tuesday, April 01, 2014 7:37 AM, Khem Raj wrote:
>> > On Fri, Mar 28, 2014 at 9:43 AM, Mats Kärrman
>> > wrote:
>> >> +# glibc configure options to make use of 603e specific sqrt/sqrtf
>> >> routines
>> >> +GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES",
>> >> "ppce300c3", "--with-cpu=e300c3", "", d)}"
>> >
>> > looks good, may be the comment above can be more explanatory saying that
>> > glibc aliases e300c3 sqrt/sqrtf to 600e versions
>>
>> The above statement depends on an added "Implies" file in eglibc and,
>> more important on a previous patch adding support for 603e/fpu sqrt.
>>
>> How is the new Implies file best added, as a patch to the previous patch
>> or as a new patch?
>
>Since this hasn't merge yet please send another patch. If it had merged,
>an incremental one would be needed.
>
Sorry if I was unclear. The patch I meant is "glibc.fix_sqrt2.patch" which
is part of both Dora and master OE-core. This patch adds the sqrt routines
I'm after and also adds Implies for relevant CPU's. What I need is one more
Implies that makes sure this code is used for e300c3 also.
Or did you mean merged upstream?
BR // Mats
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] util-linux-native: fix qsort_r for CentOS 5.10
On 1 April 2014 02:34, Robert Yang wrote: > > > On 04/01/2014 05:22 AM, Paul Barker wrote: >> >> On 26 March 2014 07:01, Robert Yang wrote: >>> >>> The qsort_r() was added to glibc in version 2.8, so there is no qsort_r() >>> on >>> the host like CentOS 5.x, use qsort() to fix it since they are nearly >>> identical. >>> >>> Signed-off-by: Robert Yang >>> --- >>> .../util-linux/util-linux-native-qsort.patch | 34 >>> >>> meta/recipes-core/util-linux/util-linux_2.24.1.bb |4 ++- >>> 2 files changed, 37 insertions(+), 1 deletion(-) >>> create mode 100644 >>> meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch >>> >>> diff --git >>> a/meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch >>> b/meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch >>> new file mode 100644 >>> index 000..1707683 >>> --- /dev/null >>> +++ >>> b/meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch >>> @@ -0,0 +1,34 @@ >>> +From f220d809be1baa654503bf6ff52f3630b0d7015c Mon Sep 17 00:00:00 2001 >>> +From: Robert Yang >>> +Date: Wed, 26 Mar 2014 01:30:29 + >>> +Subject: [PATCH] sun.c: use qsort() to instead of qsort_r() >>> + >>> +qsort_r() was added to glibc in version 2.8, so there is no qsort_r() on >>> +the host like CentOS 5.x. >>> + >>> +Upstream-Status: Inappropriate [Other] >>> + >>> +Signed-off-by: Robert Yang >>> +--- >>> + libfdisk/src/sun.c | 5 ++--- >>> + 1 file changed, 2 insertions(+), 3 deletions(-) >>> + >>> +diff --git a/libfdisk/src/sun.c b/libfdisk/src/sun.c >>> +index e73c701..f7899ec 100644 >>> +--- a/libfdisk/src/sun.c >>> b/libfdisk/src/sun.c >>> +@@ -427,9 +427,8 @@ static int sun_verify_disklabel(struct fdisk_context >>> *cxt) >>> + else >>> + array[i] = -1; >>> + } >>> +-qsort_r(array,ARRAY_SIZE(array),sizeof(array[0]), >>> +-(int (*)(const void *,const void *,void *)) verify_sun_cmp, >>> +-verify_sun_starts); >>> ++qsort(array,ARRAY_SIZE(array),sizeof(array[0]), >>> ++(int (*)(const void *,const void *)) verify_sun_cmp); >> >> >> I've just been looking at this for building util-linux on top of musl >> (as musl-libc doesn't implement qsort_r) >> and my solution was to import a qsort_r implementation from ccl >> (https://ccl.googlecode.com/svn/trunk/qsort_r.c). >> > > Maybe we can do it in YP 1.7. > > >> Are you sure this solution works? verify_sun_cmp takes 3 parameters >> not 2 and it uses the 3rd parameter (data). From reading this I'd >> imagine a segfault is likely to occur in verify_sun_cmp if qsort is >> used instead of qsort_r. >> > > I think it works well since there is a similar patch before we upgrade > the util-linux-native, I will verify later. > The more I look at it the more I don't like this patch. It's probably a very rarely used code path but it could blow up if it's called. C provides no guarantees that calling a 3-argument function with only 2 arguments will work. Depending on calling convention it could easily result in stack corruption on some platforms. I'd suggest we try reverting the relevant bits of the upstream change from qsort to qsort_r: http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=c69bbca9c1f6645097bd20fe3a21f5a99a2a0698 I think it should just be the first 3 patch hunks in that commit. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
Hi all,
I would also say that is an important change, with some possible unforeseen
consequences.
The YP is in the stabilization phase for 1.6 release.
In my opinion, the support for and change to BlueZ (overall) should be
postponed to 1.7.
Also, this not the proper solution, because, in the end, if BlueZ4 will still
be around in 1.7 (which is not my intention, to be honest), this will be worked
out with a Bluetooth stack provider (which can be BZ4 or, preferably, BZ5).
I vote against this patch.
Regards,
Cristian Iorga
YP
Intel Corporation
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Richard
Purdie
Sent: Tuesday, April 1, 2014 1:51 PM
To: Sarbu, Florin-Ionut (Wind River)
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
On Tue, 2014-04-01 at 13:09 +0300, Florin Sarbu wrote:
> Currently connman can only RDEPEND on bluez4.
> This patch adds support for having bluez5 in PACKAGECONFIG and get
> connman RDEPEND on bluez5 if desired.
>
> Signed-off-by: Florin Sarbu
> ---
> meta/recipes-connectivity/connman/connman.inc | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-connectivity/connman/connman.inc
> b/meta/recipes-connectivity/connman/connman.inc
> index b3147c9..53a6a4f 100644
> --- a/meta/recipes-connectivity/connman/connman.inc
> +++ b/meta/recipes-connectivity/connman/connman.inc
> @@ -32,7 +32,7 @@ EXTRA_OECONF += "\
>
> PACKAGECONFIG ??= "wispr \
> ${@base_contains('DISTRO_FEATURES', 'wifi','wifi', '',
> d)} \
> - ${@base_contains('DISTRO_FEATURES',
> 'bluetooth','bluetooth', '', d)} \
> + ${@base_contains('DISTRO_FEATURES',
> + 'bluetooth','bluez4', '', d)} \
> ${@base_contains('DISTRO_FEATURES', '3g','3g', '',
> d)} \ "
>
> @@ -42,6 +42,7 @@ PACKAGECONFIG ??= "wispr \
>
> PACKAGECONFIG[wifi] = "--enable-wifi, --disable-wifi, wpa-supplicant"
> PACKAGECONFIG[bluetooth] = "--enable-bluetooth, --disable-bluetooth, bluez4"
You renamed the option above but didn't here and hence broke bluez4.
This is not the quality of patch expected at -rc time for a release :(.
Cheers,
Richard
> +PACKAGECONFIG[bluez5] = "--enable-bluetooth, --disable-bluetooth, bluez5"
> PACKAGECONFIG[3g] = "--enable-ofono, --disable-ofono, ofono"
> PACKAGECONFIG[tist] = "--enable-tist,--disable-tist,"
> PACKAGECONFIG[openvpn] = "--enable-openvpn
> --with-openvpn=${sbindir}/openvpn,--disable-openvpn,,openvpn"
> @@ -114,6 +115,7 @@ RPROVIDES_${PN} = "\ RDEPENDS_${PN} = "\
> dbus \
> ${@base_contains('PACKAGECONFIG', 'bluetooth', 'bluez4', '', d)} \
> + ${@base_contains('PACKAGECONFIG', 'bluez5', 'bluez5', '', d)} \
> ${@base_contains('PACKAGECONFIG', 'wifi','wpa-supplicant', '', d)} \
> ${@base_contains('PACKAGECONFIG', '3g','ofono', '', d)} \
> xuser-account \
> --
> 1.9.1
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Quality of meta-oe metadata
On Sun, 2014-03-30 at 02:33 -0400, Trevor Woerner wrote: > Hello Martin, > > Excellent, excellent post! > > On 03/29/14 21:31, Martin Jansa wrote: > > 2) There are a lot of changes and component upgrades in oe-core which > >sometimes aren't very straight-forward to adapt to and issues stay in > >meta-oe for months. > > Critical bugfixes aside, I think the current system of unrestrained, > perpetual package bumps is an issue. If dylan uses version 1 of package > XYZ and dora uses version 5, is there any need for the 3 intervening > package bumps which occurred between the release of dylan and dora? To put the other side of the argument to this, if you leave things and just update once, you bring in more change and it usually ends up being progressively harder to debug any issues since more things changed and you don't know which change caused which problem. OE-Core has there fore gone for the "update regularly" philospohy where we can. This means we get to know about issues earlier and have more time to fix them, they're also less likely to get confused with other bugs. > If nothing else, these "irrelevant updates" increase the chance of > causing problems ;-) I'd disagree :) > > 3) OE releases work great and don't invalidate sstate signatures so often, > > so my > >feeling is that most developers and projects are just using releases and > >less and less people do CI. > > Would users prefer a better-tested more-likely-to-work release > containing package versions which were several months old, or is staying > on the bleeding edge more important? There is always exponentially more > work/cost required to be an early adopter. At least for OE-Core, there is a strong pressure to try and keep up to date. The stability is found in the release branches one a set of versions are locked in. If we run into problems and talk to upstreams, the invariable question was "does this reproduce with the last release (or head of SCM)?". If we're up to date, it makes it easier for us to talk to upstreams in that regard too. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libsdl: PACKAGECONFIG conversion
On Tue, 2014-04-01 at 00:10 -0700, Andre McCurdy wrote:
> General cleanup + make it easier for distros / machines which
> support OpenGL ES only to prevent attempts to build against libgl.
>
> Signed-off-by: Andre McCurdy
> ---
> meta/recipes-graphics/libsdl/libsdl_1.2.15.bb | 30
> ++-
> 1 file changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
> b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
> index e19c388..f72f74f 100644
> --- a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
> +++ b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
> @@ -12,10 +12,6 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=27818cd7fd83877a8e3ef82b82798ef4"
>
> PROVIDES = "virtual/libsdl"
>
> -DEPENDS = "${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '',
> d)} \
> - ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl
> libglu', '', d)} \
> - ${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11
> libxext libxrandr libxrender', '', d)} \
> - tslib"
> DEPENDS_class-nativesdk = "${@base_contains('DISTRO_FEATURES', 'x11',
> 'virtual/nativesdk-libx11 nativesdk-libxrandr nativesdk-libxrender
> nativesdk-libxext', '', d)}"
I have a nasty feeling this will break libsdl-native :(
Cheers,
Richard
> PR = "r3"
> @@ -38,17 +34,31 @@ EXTRA_OECONF = "--disable-static --enable-cdrom
> --enable-threads --enable-timers
> --disable-mintaudio --disable-nasm --disable-video-dga \
> --disable-video-fbcon --disable-video-ps2gs
> --disable-video-ps3 \
> --disable-xbios --disable-gem --disable-video-dummy \
> ---enable-input-events --enable-input-tslib --enable-pthreads
> \
> -${@base_contains('DISTRO_FEATURES', 'directfb',
> '--enable-video-directfb', '--disable-video-directfb', d)} \
> -${@base_contains('DISTRO_FEATURES', 'opengl',
> '--enable-video-opengl', '--disable-video-opengl', d)} \
> -${@base_contains('DISTRO_FEATURES', 'x11',
> '--enable-video-x11', '--disable-video-x11', d)} \
> ---disable-video-svga \
> +--enable-input-events --enable-pthreads --disable-video-svga
> \
> --disable-video-picogui --disable-video-qtopia
> --enable-sdl-dlopen \
> --disable-rpath \
> --disable-pulseaudio"
>
> -PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '',
> d)}"
> +PACKAGECONFIG_ALSA ?= "${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa',
> '', d)}"
> +PACKAGECONFIG_DIRECTFB ?= "${@base_contains('DISTRO_FEATURES', 'directfb',
> 'directfb', '', d)}"
> +# Warning: "opengl" in DISTRO_FEATURES implies GL and/or GLES but libsdl
> supports GL only.
> +PACKAGECONFIG_OPENGL ?= "${@base_contains('DISTRO_FEATURES', 'opengl',
> 'opengl', '', d)}"
> +PACKAGECONFIG_TSLIB ?= "tslib"
> +PACKAGECONFIG_X11 ?= "${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '',
> d)}"
> +
> +PACKAGECONFIG ?= " \
> +${PACKAGECONFIG_ALSA} \
> +${PACKAGECONFIG_DIRECTFB} \
> +${PACKAGECONFIG_OPENGL} \
> +${PACKAGECONFIG_TSLIB} \
> +${PACKAGECONFIG_X11} \
> +"
> +
> PACKAGECONFIG[alsa] = "--enable-alsa
> --disable-alsatest,--disable-alsa,alsa-lib,"
> +PACKAGECONFIG[directfb] =
> "--enable-video-directfb,--disable-video-directfb,directfb"
> +PACKAGECONFIG[opengl] =
> "--enable-video-opengl,--disable-video-opengl,virtual/libgl libglu"
> +PACKAGECONFIG[tslib] = "--enable-input-tslib,--disable-input-tslib,tslib"
> +PACKAGECONFIG[x11] = "--enable-video-x11,--disable-video-x11,virtual/libx11
> libxext libxrandr libxrender"
>
> PARALLEL_MAKE = ""
>
> --
> 1.8.1.2
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool: Add depends on binutils-cross
On Tue, 2014-04-01 at 14:12 +0800, b40...@freescale.com wrote:
> From: Zongchun Yu
>
> When use command bitbake -c populate_sdk to
> generate toolchain. a race issue may occur. in this case need
> to add binutils-cross to depends.
>
> Signed-off-by: Zongchun Yu
> ---
> meta/recipes-devtools/libtool/libtool-2.4.2.inc |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> index d26982d..0868dd7 100644
> --- a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> @@ -36,7 +36,7 @@ do_compile_prepend () {
> inherit autotools
> EXTRA_AUTORECONF = "--exclude=libtoolize"
>
> -DEPENDS = "libtool-native"
> +DEPENDS = "libtool-native binutils-cross"
>
> PACKAGES =+ "libltdl libltdl-dev libltdl-dbg libltdl-staticdev"
> FILES_${PN} += "${datadir}/aclocal"
You're patching the .inc file here so this dependency is being applied
to multiple different libtools. Can you perhaps explain the problem you
were seeing with a step by step how to reproduce the problem?
I'd like to understand the real problem here, I don't doubt it exists
but I'm not sure this is the correct fix.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
On Tue, 2014-04-01 at 13:09 +0300, Florin Sarbu wrote:
> Currently connman can only RDEPEND on bluez4.
> This patch adds support for having bluez5 in PACKAGECONFIG
> and get connman RDEPEND on bluez5 if desired.
>
> Signed-off-by: Florin Sarbu
> ---
> meta/recipes-connectivity/connman/connman.inc | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-connectivity/connman/connman.inc
> b/meta/recipes-connectivity/connman/connman.inc
> index b3147c9..53a6a4f 100644
> --- a/meta/recipes-connectivity/connman/connman.inc
> +++ b/meta/recipes-connectivity/connman/connman.inc
> @@ -32,7 +32,7 @@ EXTRA_OECONF += "\
>
> PACKAGECONFIG ??= "wispr \
> ${@base_contains('DISTRO_FEATURES', 'wifi','wifi', '',
> d)} \
> - ${@base_contains('DISTRO_FEATURES',
> 'bluetooth','bluetooth', '', d)} \
> + ${@base_contains('DISTRO_FEATURES', 'bluetooth','bluez4',
> '', d)} \
> ${@base_contains('DISTRO_FEATURES', '3g','3g', '', d)} \
> "
>
> @@ -42,6 +42,7 @@ PACKAGECONFIG ??= "wispr \
>
> PACKAGECONFIG[wifi] = "--enable-wifi, --disable-wifi, wpa-supplicant"
> PACKAGECONFIG[bluetooth] = "--enable-bluetooth, --disable-bluetooth, bluez4"
You renamed the option above but didn't here and hence broke bluez4.
This is not the quality of patch expected at -rc time for a release :(.
Cheers,
Richard
> +PACKAGECONFIG[bluez5] = "--enable-bluetooth, --disable-bluetooth, bluez5"
> PACKAGECONFIG[3g] = "--enable-ofono, --disable-ofono, ofono"
> PACKAGECONFIG[tist] = "--enable-tist,--disable-tist,"
> PACKAGECONFIG[openvpn] = "--enable-openvpn
> --with-openvpn=${sbindir}/openvpn,--disable-openvpn,,openvpn"
> @@ -114,6 +115,7 @@ RPROVIDES_${PN} = "\
> RDEPENDS_${PN} = "\
> dbus \
> ${@base_contains('PACKAGECONFIG', 'bluetooth', 'bluez4', '', d)} \
> + ${@base_contains('PACKAGECONFIG', 'bluez5', 'bluez5', '', d)} \
> ${@base_contains('PACKAGECONFIG', 'wifi','wpa-supplicant', '', d)} \
> ${@base_contains('PACKAGECONFIG', '3g','ofono', '', d)} \
> xuser-account \
> --
> 1.9.1
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] cmake: follow ptest output format
On Tue, 2014-04-01 at 17:09 +0800, Kai Kang wrote:
> From: Li Wang
>
> ptest output format is incorrect, according to yocto Development Manual
> (http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#testing-packages-with-ptest)
>
> The test generates output in the format used by Automake:
> :
> where the result can be PASS, FAIL, or SKIP, and the testname can be any
> identifying string.
>
> So we should change the test result format to match yocto ptest rules.
>
> Signed-off-by: Li Wang
> Signed-off-by: Robert Yang
> Signed-off-by: Kai Kang
> ---
> meta/recipes-devtools/cmake/cmake.inc | 1 +
> .../cmake/cmake/follow_ptest_output_format.patch | 118
> +
> 2 files changed, 119 insertions(+)
> create mode 100644
> meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
>
> diff --git a/meta/recipes-devtools/cmake/cmake.inc
> b/meta/recipes-devtools/cmake/cmake.inc
> index 1d5303f..254af45 100644
> --- a/meta/recipes-devtools/cmake/cmake.inc
> +++ b/meta/recipes-devtools/cmake/cmake.inc
> @@ -17,6 +17,7 @@ SRC_URI =
> "http://www.cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz
> file://aarch64-kwsys.patch \
> file://qt4-fail-silent.patch \
> file://cmake-2.8.11.2-FindFreetype.patch \
> + file://follow_ptest_output_format.patch \
> "
>
> inherit autotools-brokensep
> diff --git
> a/meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
> b/meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
> new file mode 100644
> index 000..5428df2
> --- /dev/null
> +++ b/meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
> @@ -0,0 +1,118 @@
> +cmake: follow ptest output format
> +
> +ptest output format is incorrect, according to yocto Development Manual
> +(http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#testing-packages-with-ptest)
> +5.10.6. Testing Packages With ptest
> +The test generates output in the format used by Automake:
> +:
> +where the result can be PASS, FAIL, or SKIP, and the testname can be any
> identifying string.
> +So we should change the test result format to match yocto ptest rules.
> +
> +Signed-off-by: Li Wang
No upstream status. Is there any chance of this going upstream? Might we
be better off postprocessing the output with a script to put it into the
right format?
Cheers,
Richard
> +---
> +--- a/Source/CTest/cmCTestRunTest.cxx
> b/Source/CTest/cmCTestRunTest.cxx
> +@@ -145,8 +145,8 @@
> + this->CompressOutput();
> + }
> +
> +- this->WriteLogOutputTop(completed, total);
> + std::string reason;
> ++ std::string result;
> + bool passed = true;
> + int res = started ? this->TestProcess->GetProcessStatus()
> + : cmsysProcess_State_Error;
> +@@ -208,57 +208,58 @@
> + || (!success && this->TestProperties->WillFail))
> + {
> + this->TestResult.Status = cmCTestTestHandler::COMPLETED;
> +- cmCTestLog(this->CTest, HANDLER_OUTPUT, " Passed " );
> ++ result = " ";
> + }
> + else
> + {
> + this->TestResult.Status = cmCTestTestHandler::FAILED;
> +- cmCTestLog(this->CTest, HANDLER_OUTPUT, "***Failed " << reason );
> ++ result = " " + reason;
> + outputTestErrorsToConsole =
> this->CTest->OutputTestOutputOnTestFailure;
> + }
> + }
> + else if ( res == cmsysProcess_State_Expired )
> + {
> +-cmCTestLog(this->CTest, HANDLER_OUTPUT, "***Timeout ");
> ++result = "***Timeout ";
> + this->TestResult.Status = cmCTestTestHandler::TIMEOUT;
> + outputTestErrorsToConsole = this->CTest->OutputTestOutputOnTestFailure;
> + }
> + else if ( res == cmsysProcess_State_Exception )
> + {
> + outputTestErrorsToConsole = this->CTest->OutputTestOutputOnTestFailure;
> +-cmCTestLog(this->CTest, HANDLER_OUTPUT, "***Exception: ");
> ++result = "***Exception: ";
> + switch(this->TestProcess->GetExitException())
> + {
> + case cmsysProcess_Exception_Fault:
> +-cmCTestLog(this->CTest, HANDLER_OUTPUT, "SegFault");
> ++result += "SegFault";
> + this->TestResult.Status = cmCTestTestHandler::SEGFAULT;
> + break;
> + case cmsysProcess_Exception_Illegal:
> +-cmCTestLog(this->CTest, HANDLER_OUTPUT, "Illegal");
> ++result += "Illegal";
> + this->TestResult.Status = cmCTestTestHandler::ILLEGAL;
> + break;
> + case cmsysProcess_Exception_Interrupt:
> +-cmCTestLog(this->CTest, HANDLER_OUTPUT, "Interrupt");
> ++result += "Interrupt";
> + this->TestResult.Status = cmCTestTestHandler::INTERRUPT;
> + break;
> + case cmsysProcess_Exception_Numerical:
> +-cmCTestLog(this->CTest, HANDLER_OUTPUT, "Numerical");
> ++result += "Numerical";
> + this->TestResult.Status = cmCTestTestHandler::NUMERICAL;
> +
[OE-core] Public TSC / OE Workgroup meeting today
Hi all, There will be a public OpenEmbedded TSC/workgroup IRC meeting today. If you're interested in discussing long-term technical efforts around the OpenEmbedded project please join us on irc.freenode.net in channel #oe at 16:00 GMT (9am PDT, 11am CDT, 12 EDT, 18:00 CEST, 17:00 BST). Possible topics for discussion (based on the last meeting and recent mailing list topics): - Upcoming release - World build status - Website and other infrastructure issues New topics for discussion are welcome. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] Make ppce300c3 tune hard-float by default
On Tue, 2014-04-01 at 07:54 +, Mats Kärrman wrote:
> Hi Khem,
>
> Thanks for your feedback!
>
> On Tuesday, April 01, 2014 7:37 AM, Khem Raj wrote:
> > On Fri, Mar 28, 2014 at 9:43 AM, Mats Kärrman
> > wrote:
> >> +# glibc configure options to make use of 603e specific sqrt/sqrtf routines
> >> +GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3",
> >> "--with-cpu=e300c3", "", d)}"
> >
> > looks good, may be the comment above can be more explanatory saying that
> > glibc aliases e300c3 sqrt/sqrtf to 600e versions
>
> The above statement depends on an added "Implies" file in eglibc and,
> more important on a previous patch adding support for 603e/fpu sqrt.
>
> How is the new Implies file best added, as a patch to the previous patch
> or as a new patch?
Since this hasn't merge yet please send another patch. If it had merged,
an incremental one would be needed.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libpcap.inc: Add PACKAGECONFIG support for bluez
On Tue, Apr 01, 2014 at 01:16:40PM +0300, Florin Sarbu wrote:
> This patch adds support for having bluez5 in PACKAGECONFIG
> and get libpcap DEPEND on bluez5.
>
> Signed-off-by: Florin Sarbu
> ---
> meta/recipes-connectivity/libpcap/libpcap.inc | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-connectivity/libpcap/libpcap.inc
> b/meta/recipes-connectivity/libpcap/libpcap.inc
> index a984e05..1613567 100644
> --- a/meta/recipes-connectivity/libpcap/libpcap.inc
> +++ b/meta/recipes-connectivity/libpcap/libpcap.inc
> @@ -10,8 +10,9 @@ LIC_FILES_CHKSUM =
> "file://LICENSE;md5=1d4b0366557951c84a94fabe3529f867 \
>
> file://pcap.h;beginline=1;endline=34;md5=8d6cf7e17d5745010d633e30bc529ea9"
> DEPENDS = "flex-native bison-native libnl"
>
> -PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'bluetooth',
> 'bluetooth', '', d)}"
> -PACKAGECONFIG[bluetooth] = "--enable-bluetooth,--disable-bluetooth,bluez4"
> +PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'bluetooth',
> 'bluez4', '', d)}"
> +PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
> +PACKAGECONFIG[bluez5] = "--enable-bluetooth,--disable-bluetooth,bluez5"
Does it work correctly?
If you don't enable both you will always get at least one
--disable-bluetooth and depending on order how packageconfigs were
processed it will be disabled or not.
> PACKAGECONFIG[canusb] = "--enable-canusb,--enable-canusb=no,libusb"
> PACKAGECONFIG[libnl1] = "--with-libnl,--without-libnl,libnl1,libnl1"
>
> --
> 1.9.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cmake-native: Depend on ncurses-native too
On Tue, 2014-04-01 at 11:11 +0100, Mike Crowe wrote: > On Tuesday 01 April 2014 at 10:31:59 +0100, Richard Purdie wrote: > > On Tue, 2014-04-01 at 10:16 +0100, Mike Crowe wrote: > > > cmake detects the presence of curses automatically during configure so > > > cmake-native must also depend on ncurses-native to stop it being removed > > > from the sysroot during the build. > > > > > > Signed-off-by: Mike Crowe > > > --- > > > meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > > > b/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > > > index 08b2c02..8d93b9a 100644 > > > --- a/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > > > +++ b/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > > > @@ -2,7 +2,7 @@ require cmake.inc > > > inherit native > > > > > > # Using cmake's internal libarchive, so some dependencies are needed > > > -DEPENDS += "bzip2-native zlib-native" > > > +DEPENDS += "bzip2-native zlib-native ncurses-native" > > > > > > SRC_URI += "file://cmlibarchive-disable-ext2fs.patch" > > > > > > > What does an ncurses enabled cmake give us that is desirable? > > I'm not really sure. > > CMake's bootstrap configure script detects curses and tries to use it which > causes build failures if curses has gone missing in the meantime. > > In the failure I saw bitbake was building cmake-native and ncurses-native > in parallel in a tree that had previously been used to build for a > different machine. This caused curses.h to be present during > cmake-native.do_configure but go missing before or during > cmake-native.do_compile. > > It seems to be possible to disable building the "CursesDialog" component to > remove the need for ncurses but I couldn't immediately see how to do that > for a bootstrap build. > > The non-native cmake recipe depends on ncurses even though it passes > -DBUILD_CursesDialog=0. I'd much prefer to disable the need for curses if we can since the more convoluted the dependency chain, the longer our build times. If we don't need this, it would be much nicer to disable it, even if we have to patch it out. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] OE monthy today (?)
On Tuesday 01 April 2014 01:18:47 Denys Dmytriyenko wrote: > On Tue, Apr 01, 2014 at 12:52:52AM -0400, Trevor Woerner wrote: > > On 04/01/14 00:34, Denys Dmytriyenko wrote: > > > On Tue, Apr 01, 2014 at 12:04:16AM -0400, Trevor Woerner wrote: > > >> ...in roughly 12 hours from now? > > > > > > ? > > > > I'm referring to the monthly OE meeting that's held on IRC. I'm trying > > to confirm it takes place today and is scheduled for noon EST. > > Did you mean TSC/workgroup meeting? Nothing from Paul yet... It's that time again, yes. I'll send something out. (I really need to get better at sending these in advance - sorry!) Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libpcap.inc: Add PACKAGECONFIG support for bluez
This patch adds support for having bluez5 in PACKAGECONFIG
and get libpcap DEPEND on bluez5.
Signed-off-by: Florin Sarbu
---
meta/recipes-connectivity/libpcap/libpcap.inc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/libpcap/libpcap.inc
b/meta/recipes-connectivity/libpcap/libpcap.inc
index a984e05..1613567 100644
--- a/meta/recipes-connectivity/libpcap/libpcap.inc
+++ b/meta/recipes-connectivity/libpcap/libpcap.inc
@@ -10,8 +10,9 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=1d4b0366557951c84a94fabe3529f867 \
file://pcap.h;beginline=1;endline=34;md5=8d6cf7e17d5745010d633e30bc529ea9"
DEPENDS = "flex-native bison-native libnl"
-PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'bluetooth',
'bluetooth', '', d)}"
-PACKAGECONFIG[bluetooth] = "--enable-bluetooth,--disable-bluetooth,bluez4"
+PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'bluetooth', 'bluez4',
'', d)}"
+PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
+PACKAGECONFIG[bluez5] = "--enable-bluetooth,--disable-bluetooth,bluez5"
PACKAGECONFIG[canusb] = "--enable-canusb,--enable-canusb=no,libusb"
PACKAGECONFIG[libnl1] = "--with-libnl,--without-libnl,libnl1,libnl1"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] util-linux-native: Remove SYS_setns system call in linux kernel 2.6.x
On Tue, 2014-04-01 at 17:09 +0800, Kai Kang wrote:
> From: "yanjun.zhu"
>
> __NR_setns is not defined in linux kernel 2.6.x. To linux kernel 3.0,
> this variable is defined. It has been shown that no native tools use
> this syscall, so it is safe to make this substitution
>
> Signed-off-by: yanjun.zhu
> Signed-off-by: Robert Yang
> Signed-off-by: Kai Kang
> ---
> meta/recipes-core/util-linux/util-linux.inc | 6 ++
> 1 file changed, 6 insertions(+)
This is horrible. Firstly "no native tools use this syscall" - how did
you check that? I suspect you perhaps mean "no native tools in OE-Core
at this time"? How would we know when one is added?
Secondly, this should not be done as a sed, it should be a patch with a
description. This means when we upgrade util-linux, it doesn't silently
stop working or do something unintended.
Cheers,
Richard
> diff --git a/meta/recipes-core/util-linux/util-linux.inc
> b/meta/recipes-core/util-linux/util-linux.inc
> index ad7aac7..0f065b4 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -112,6 +112,12 @@ RPROVIDES_${PN}-dev = "util-linux-libblkid-dev
> util-linux-libmount-dev util-linu
> SYSTEMD_PACKAGES = "${PN}-uuidd"
> SYSTEMD_SERVICE_${PN}-uuidd = "uuidd.service"
>
> +do_compile_prepend_class-native() {
> + if [ `uname -r | grep "2.6."` ]; then
> + sed -i 's:return syscall(SYS_setns:fprintf(stderr,"Kernel does
> not support setns");\n\treturn 1;\n//return syscall(:g'
> ${S}/include/namespace.h
> + fi
> +}
> +
> do_compile () {
> set -e
> install ${WORKDIR}/MCONFIG ${S}/MCONFIG
> --
> 1.8.1.2
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Fix some bash errors
On 2014?04?01? 09:59, Kai Kang wrote: Fix some errors for bash 3.2.48 by take patches from bash 4.3. Yong Zhang (1): bash-3.2.48: fix error path of getc_with_restart .../bash-fix-error-path-of-getc_with_restart.patch | 41 ++ .../bash-3.2.48/bash-fix-getc_with_restart.patch | 28 +++ meta/recipes-extended/bash/bash_3.2.48.bb | 2 ++ 3 files changed, 71 insertions(+) create mode 100644 meta/recipes-extended/bash/bash-3.2.48/bash-fix-error-path-of-getc_with_restart.patch create mode 100644 meta/recipes-extended/bash/bash-3.2.48/bash-fix-getc_with_restart.patch Please ignore it. Thanks. -- Regards, Neil | Kai Kang -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cmake-native: Depend on ncurses-native too
On Tuesday 01 April 2014 at 10:31:59 +0100, Richard Purdie wrote: > On Tue, 2014-04-01 at 10:16 +0100, Mike Crowe wrote: > > cmake detects the presence of curses automatically during configure so > > cmake-native must also depend on ncurses-native to stop it being removed > > from the sysroot during the build. > > > > Signed-off-by: Mike Crowe > > --- > > meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > > b/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > > index 08b2c02..8d93b9a 100644 > > --- a/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > > +++ b/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > > @@ -2,7 +2,7 @@ require cmake.inc > > inherit native > > > > # Using cmake's internal libarchive, so some dependencies are needed > > -DEPENDS += "bzip2-native zlib-native" > > +DEPENDS += "bzip2-native zlib-native ncurses-native" > > > > SRC_URI += "file://cmlibarchive-disable-ext2fs.patch" > > > > What does an ncurses enabled cmake give us that is desirable? I'm not really sure. CMake's bootstrap configure script detects curses and tries to use it which causes build failures if curses has gone missing in the meantime. In the failure I saw bitbake was building cmake-native and ncurses-native in parallel in a tree that had previously been used to build for a different machine. This caused curses.h to be present during cmake-native.do_configure but go missing before or during cmake-native.do_compile. It seems to be possible to disable building the "CursesDialog" component to remove the need for ncurses but I couldn't immediately see how to do that for a bootstrap build. The non-native cmake recipe depends on ncurses even though it passes -DBUILD_CursesDialog=0. Thanks. Mike. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] image/image-prelink/image-mklibs/sanity: Drop pointless EXPORT_FUNCTIONS
I'm sick of seeing people adding to EXPORT_FUNCTIONS in these classes
when they clearly have no idea what it does.
Worse, these uses of it are all broken, the naming is incorrect and
they do nothing. Lets remove them and try and preserve any remaining
part of my sanity.
Signed-off-by: Richard Purdie
---
diff --git a/meta/classes/image-mklibs.bbclass
b/meta/classes/image-mklibs.bbclass
index 23456cc..11f082b 100644
--- a/meta/classes/image-mklibs.bbclass
+++ b/meta/classes/image-mklibs.bbclass
@@ -69,6 +69,3 @@ mklibs_optimize_image() {
fi
done
}
-
-
-EXPORT_FUNCTIONS mklibs_optimize_image
diff --git a/meta/classes/image-prelink.bbclass
b/meta/classes/image-prelink.bbclass
index 53ef47e..d4bb3ae 100644
--- a/meta/classes/image-prelink.bbclass
+++ b/meta/classes/image-prelink.bbclass
@@ -31,5 +31,3 @@ prelink_image () {
pre_prelink_size=`du -ks ${IMAGE_ROOTFS} | awk '{size = $1 ; print size
}'`
echo "Size after prelinking $pre_prelink_size."
}
-
-EXPORT_FUNCTIONS prelink_image
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 29309f5..94abbc9 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -374,8 +374,6 @@ rootfs_sysroot_relativelinks () {
sysroot-relativelinks.py ${SDK_OUTPUT}/${SDKTARGETSYSROOT}
}
-EXPORT_FUNCTIONS zap_empty_root_password remove_init_link do_rootfs
make_zimage_symlink_relative set_image_autologin rootfs_update_timestamp
rootfs_no_x_startup
-
do_fetch[noexec] = "1"
do_unpack[noexec] = "1"
do_patch[noexec] = "1"
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 69d6a24..dd7fe4c 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -25,8 +25,6 @@ def sanity_conf_update(fn, lines, version_var_name,
new_version):
with open(fn, "w") as f:
f.write(''.join(lines))
-EXPORT_FUNCTIONS bblayers_conf_file sanity_conf_read sanity_conf_find_line
sanity_conf_update
-
# Functions added to this variable MUST throw an exception (or sys.exit())
unless they
# successfully changed LCONF_VERSION in bblayers.conf
BBLAYERS_CONF_UPDATE_FUNCS += "oecore_update_bblayers"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] connman.inc: Add PACKAGECONFIG support for bluez5
Currently connman can only RDEPEND on bluez4.
This patch adds support for having bluez5 in PACKAGECONFIG
and get connman RDEPEND on bluez5 if desired.
Signed-off-by: Florin Sarbu
---
meta/recipes-connectivity/connman/connman.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/connman/connman.inc
b/meta/recipes-connectivity/connman/connman.inc
index b3147c9..53a6a4f 100644
--- a/meta/recipes-connectivity/connman/connman.inc
+++ b/meta/recipes-connectivity/connman/connman.inc
@@ -32,7 +32,7 @@ EXTRA_OECONF += "\
PACKAGECONFIG ??= "wispr \
${@base_contains('DISTRO_FEATURES', 'wifi','wifi', '', d)} \
- ${@base_contains('DISTRO_FEATURES',
'bluetooth','bluetooth', '', d)} \
+ ${@base_contains('DISTRO_FEATURES', 'bluetooth','bluez4',
'', d)} \
${@base_contains('DISTRO_FEATURES', '3g','3g', '', d)} \
"
@@ -42,6 +42,7 @@ PACKAGECONFIG ??= "wispr \
PACKAGECONFIG[wifi] = "--enable-wifi, --disable-wifi, wpa-supplicant"
PACKAGECONFIG[bluetooth] = "--enable-bluetooth, --disable-bluetooth, bluez4"
+PACKAGECONFIG[bluez5] = "--enable-bluetooth, --disable-bluetooth, bluez5"
PACKAGECONFIG[3g] = "--enable-ofono, --disable-ofono, ofono"
PACKAGECONFIG[tist] = "--enable-tist,--disable-tist,"
PACKAGECONFIG[openvpn] = "--enable-openvpn
--with-openvpn=${sbindir}/openvpn,--disable-openvpn,,openvpn"
@@ -114,6 +115,7 @@ RPROVIDES_${PN} = "\
RDEPENDS_${PN} = "\
dbus \
${@base_contains('PACKAGECONFIG', 'bluetooth', 'bluez4', '', d)} \
+ ${@base_contains('PACKAGECONFIG', 'bluez5', 'bluez5', '', d)} \
${@base_contains('PACKAGECONFIG', 'wifi','wpa-supplicant', '', d)} \
${@base_contains('PACKAGECONFIG', '3g','ofono', '', d)} \
xuser-account \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] qemux86-64: re-enable paravirt guest, bring it in sync with qemux86
Seems wrong that qemux86 has this enabled and qemux86-64 doesn't.
Also this will allow people to use kvm with -cpu=host.
Right now, runqemu qemux86-64 kvm uses -cpu=kvm64 because without this
feature you can't use cpu=host on newer host kernels (>= 3.8).
This basically reverts poky e6149ec6c4c14d3a939022cdc29ac94dced836dd /
oe-core 64749308fadabb4aa7c39f360c6395827bc5eb3a
The reason of that commit (which is more than a year old) was that on
the AB running old kernels (2.6.37) we would see occasional shutdown failures.
(but if memory serves me right the fix might have been just a coincidence).
I've tested this change with by:
- run tests on runqemu qemux86-64 (without kvm) (300 seconds)
- run tests on runqemu qemux86-64 kvm (which uses by default cpu=kvm64) -
(tests
took 20 seconds)
- run tests on runqemu qemux86-64 kvm with cpu=host - (tests took 18 seconds)
[ YOCTO #5956 ]
Signed-off-by: Stefan Stanacar
---
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
index d5202cd..46c4260 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
@@ -33,5 +33,5 @@ COMPATIBLE_MACHINE =
"qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc"
KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
-KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
+KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", "
cfg/x32.scc", "" ,d)}"
--
1.9.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cmake-native: Depend on ncurses-native too
On Tue, 2014-04-01 at 10:16 +0100, Mike Crowe wrote: > cmake detects the presence of curses automatically during configure so > cmake-native must also depend on ncurses-native to stop it being removed > from the sysroot during the build. > > Signed-off-by: Mike Crowe > --- > meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > b/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > index 08b2c02..8d93b9a 100644 > --- a/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > +++ b/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > @@ -2,7 +2,7 @@ require cmake.inc > inherit native > > # Using cmake's internal libarchive, so some dependencies are needed > -DEPENDS += "bzip2-native zlib-native" > +DEPENDS += "bzip2-native zlib-native ncurses-native" > > SRC_URI += "file://cmlibarchive-disable-ext2fs.patch" > What does an ncurses enabled cmake give us that is desirable? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] cmake-native: Depend on ncurses-native too
cmake detects the presence of curses automatically during configure so cmake-native must also depend on ncurses-native to stop it being removed from the sysroot during the build. Signed-off-by: Mike Crowe --- meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb b/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb index 08b2c02..8d93b9a 100644 --- a/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb +++ b/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb @@ -2,7 +2,7 @@ require cmake.inc inherit native # Using cmake's internal libarchive, so some dependencies are needed -DEPENDS += "bzip2-native zlib-native" +DEPENDS += "bzip2-native zlib-native ncurses-native" SRC_URI += "file://cmlibarchive-disable-ext2fs.patch" -- 1.8.5.3 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] cmake: follow ptest output format
From: Li Wang
ptest output format is incorrect, according to yocto Development Manual
(http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#testing-packages-with-ptest)
The test generates output in the format used by Automake:
:
where the result can be PASS, FAIL, or SKIP, and the testname can be any
identifying string.
So we should change the test result format to match yocto ptest rules.
Signed-off-by: Li Wang
Signed-off-by: Robert Yang
Signed-off-by: Kai Kang
---
meta/recipes-devtools/cmake/cmake.inc | 1 +
.../cmake/cmake/follow_ptest_output_format.patch | 118 +
2 files changed, 119 insertions(+)
create mode 100644
meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
diff --git a/meta/recipes-devtools/cmake/cmake.inc
b/meta/recipes-devtools/cmake/cmake.inc
index 1d5303f..254af45 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -17,6 +17,7 @@ SRC_URI =
"http://www.cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz
file://aarch64-kwsys.patch \
file://qt4-fail-silent.patch \
file://cmake-2.8.11.2-FindFreetype.patch \
+ file://follow_ptest_output_format.patch \
"
inherit autotools-brokensep
diff --git a/meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
b/meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
new file mode 100644
index 000..5428df2
--- /dev/null
+++ b/meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch
@@ -0,0 +1,118 @@
+cmake: follow ptest output format
+
+ptest output format is incorrect, according to yocto Development Manual
+(http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#testing-packages-with-ptest)
+5.10.6. Testing Packages With ptest
+The test generates output in the format used by Automake:
+:
+where the result can be PASS, FAIL, or SKIP, and the testname can be any
identifying string.
+So we should change the test result format to match yocto ptest rules.
+
+Signed-off-by: Li Wang
+---
+--- a/Source/CTest/cmCTestRunTest.cxx
b/Source/CTest/cmCTestRunTest.cxx
+@@ -145,8 +145,8 @@
+ this->CompressOutput();
+ }
+
+- this->WriteLogOutputTop(completed, total);
+ std::string reason;
++ std::string result;
+ bool passed = true;
+ int res = started ? this->TestProcess->GetProcessStatus()
+ : cmsysProcess_State_Error;
+@@ -208,57 +208,58 @@
+ || (!success && this->TestProperties->WillFail))
+ {
+ this->TestResult.Status = cmCTestTestHandler::COMPLETED;
+- cmCTestLog(this->CTest, HANDLER_OUTPUT, " Passed " );
++ result = " ";
+ }
+ else
+ {
+ this->TestResult.Status = cmCTestTestHandler::FAILED;
+- cmCTestLog(this->CTest, HANDLER_OUTPUT, "***Failed " << reason );
++ result = " " + reason;
+ outputTestErrorsToConsole = this->CTest->OutputTestOutputOnTestFailure;
+ }
+ }
+ else if ( res == cmsysProcess_State_Expired )
+ {
+-cmCTestLog(this->CTest, HANDLER_OUTPUT, "***Timeout ");
++result = "***Timeout ";
+ this->TestResult.Status = cmCTestTestHandler::TIMEOUT;
+ outputTestErrorsToConsole = this->CTest->OutputTestOutputOnTestFailure;
+ }
+ else if ( res == cmsysProcess_State_Exception )
+ {
+ outputTestErrorsToConsole = this->CTest->OutputTestOutputOnTestFailure;
+-cmCTestLog(this->CTest, HANDLER_OUTPUT, "***Exception: ");
++result = "***Exception: ";
+ switch(this->TestProcess->GetExitException())
+ {
+ case cmsysProcess_Exception_Fault:
+-cmCTestLog(this->CTest, HANDLER_OUTPUT, "SegFault");
++result += "SegFault";
+ this->TestResult.Status = cmCTestTestHandler::SEGFAULT;
+ break;
+ case cmsysProcess_Exception_Illegal:
+-cmCTestLog(this->CTest, HANDLER_OUTPUT, "Illegal");
++result += "Illegal";
+ this->TestResult.Status = cmCTestTestHandler::ILLEGAL;
+ break;
+ case cmsysProcess_Exception_Interrupt:
+-cmCTestLog(this->CTest, HANDLER_OUTPUT, "Interrupt");
++result += "Interrupt";
+ this->TestResult.Status = cmCTestTestHandler::INTERRUPT;
+ break;
+ case cmsysProcess_Exception_Numerical:
+-cmCTestLog(this->CTest, HANDLER_OUTPUT, "Numerical");
++result += "Numerical";
+ this->TestResult.Status = cmCTestTestHandler::NUMERICAL;
+ break;
+ default:
+-cmCTestLog(this->CTest, HANDLER_OUTPUT, "Other");
++result += "Other";
+ this->TestResult.Status = cmCTestTestHandler::OTHER_FAULT;
+ }
+ }
+ else //cmsysProcess_State_Error
+ {
+-cmCTestLog(this->CTest, HANDLER_OUTPUT, "***Not Run ");
++result = "***Not Run ";
+ }
+
+ passed = this->TestResult.Status == cmCTestTestHandler::COMPLETED;
+ char buf[1024];
+ sprintf(buf, "%6.2f sec", th
[OE-core] [PATCH 3/3] util-linux-native: Remove SYS_setns system call in linux kernel 2.6.x
From: "yanjun.zhu"
__NR_setns is not defined in linux kernel 2.6.x. To linux kernel 3.0,
this variable is defined. It has been shown that no native tools use
this syscall, so it is safe to make this substitution
Signed-off-by: yanjun.zhu
Signed-off-by: Robert Yang
Signed-off-by: Kai Kang
---
meta/recipes-core/util-linux/util-linux.inc | 6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index ad7aac7..0f065b4 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -112,6 +112,12 @@ RPROVIDES_${PN}-dev = "util-linux-libblkid-dev
util-linux-libmount-dev util-linu
SYSTEMD_PACKAGES = "${PN}-uuidd"
SYSTEMD_SERVICE_${PN}-uuidd = "uuidd.service"
+do_compile_prepend_class-native() {
+ if [ `uname -r | grep "2.6."` ]; then
+ sed -i 's:return syscall(SYS_setns:fprintf(stderr,"Kernel does
not support setns");\n\treturn 1;\n//return syscall(:g' ${S}/include/namespace.h
+ fi
+}
+
do_compile () {
set -e
install ${WORKDIR}/MCONFIG ${S}/MCONFIG
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] xorg: Fix for CVE-2013-6424
Integer underflow in the xTrapezoidValid macro in render/picture.h in X.Org allows context-dependent attackers to cause a denial of service (crash) via a negative bottom value. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-6424 Signed-off-by: Baogen Shang Signed-off-by: Kai Kang --- .../xserver-xorg/xorg-CVE-2013-6424.patch | 31 ++ .../xorg-xserver/xserver-xorg_1.15.0.bb| 1 + 2 files changed, 32 insertions(+) create mode 100644 meta/recipes-graphics/xorg-xserver/xserver-xorg/xorg-CVE-2013-6424.patch diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg/xorg-CVE-2013-6424.patch b/meta/recipes-graphics/xorg-xserver/xserver-xorg/xorg-CVE-2013-6424.patch new file mode 100644 index 000..7c61530 --- /dev/null +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg/xorg-CVE-2013-6424.patch @@ -0,0 +1,31 @@ +This patch comes from: +http://lists.x.org/archives/xorg-devel/2013-October/037996.html + +Upstream-Status: Backport + +Signed-off-by: Baogen shang +diff -Naur xorg-server-1.14.0-orig/exa/exa_render.c xorg-server-1.14.0/exa/exa_render.c +--- xorg-server-1.14.0-orig/exa/exa_render.c 2014-02-27 14:32:38.0 +0800 xorg-server-1.14.0/exa/exa_render.c2014-02-27 15:46:59.0 +0800 +@@ -1141,7 +1141,8 @@ + + exaPrepareAccess(pPicture->pDrawable, EXA_PREPARE_DEST); + for (; ntrap; ntrap--, traps++) +-(*ps->RasterizeTrapezoid) (pPicture, traps, -bounds.x1, -bounds.y1); ++if (xTrapezoidValid(traps)) ++(*ps->RasterizeTrapezoid) (pPicture, traps, -bounds.x1, -bounds.y1); + exaFinishAccess(pPicture->pDrawable, EXA_PREPARE_DEST); + + xRel = bounds.x1 + xSrc - xDst; +diff -Naur xorg-server-1.14.0-orig/render/picture.h xorg-server-1.14.0/render/picture.h +--- xorg-server-1.14.0-orig/render/picture.h 2014-02-27 14:32:26.0 +0800 xorg-server-1.14.0/render/picture.h2014-02-27 15:48:13.0 +0800 +@@ -211,7 +211,7 @@ + /* whether 't' is a well defined not obviously empty trapezoid */ + #define xTrapezoidValid(t) ((t)->left.p1.y != (t)->left.p2.y && \ +(t)->right.p1.y != (t)->right.p2.y && \ +- (int) ((t)->bottom - (t)->top) > 0) ++ ((t)->bottom > (t)->top)) + + /* + * Standard NTSC luminance conversions: diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.15.0.bb b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.15.0.bb index a4dda4e..1f9fa04 100644 --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.15.0.bb +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.15.0.bb @@ -5,6 +5,7 @@ SRC_URI += "file://crosscompile.patch \ file://fix_open_max_preprocessor_error.patch \ file://mips64-compiler.patch \ file://aarch64.patch \ +file://xorg-CVE-2013-6424.patch \ " SRC_URI[md5sum] = "c2ace3697b32414094cf8c597c39d7d9" -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] miscellaneous patches
The following changes since commit dee07bee84361eb58cdc0e267b22d71155b89b65: beaglebone: fix typo in the U-Boot config name (2014-03-31 23:04:36 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib kangkai/misc http://git.yoctoproject.org/cgit.cgi//log/?h=kangkai/misc Kai Kang (1): xorg: Fix for CVE-2013-6424 Li Wang (1): cmake: follow ptest output format yanjun.zhu (1): util-linux-native: Remove SYS_setns system call in linux kernel 2.6.x meta/recipes-core/util-linux/util-linux.inc| 6 ++ meta/recipes-devtools/cmake/cmake.inc | 1 + .../cmake/cmake/follow_ptest_output_format.patch | 118 + .../xserver-xorg/xorg-CVE-2013-6424.patch | 31 ++ .../xorg-xserver/xserver-xorg_1.15.0.bb| 1 + 5 files changed, 157 insertions(+) create mode 100644 meta/recipes-devtools/cmake/cmake/follow_ptest_output_format.patch create mode 100644 meta/recipes-graphics/xorg-xserver/xserver-xorg/xorg-CVE-2013-6424.patch -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] State of bitbake world, Failed tasks 2014-03-29
On Sat, Mar 29, 2014 at 11:54 PM, Martin Jansa wrote: > > http://www.openembedded.org/wiki/Bitbake_World_Status > > == Failed tasks 2014-03-29 == > > === common (23) === > * > meta-openembedded/meta-gnome/recipes-gnome/devilspie/devilspie2_0.24.bb, > do_compile > * > meta-openembedded/meta-gnome/recipes-gnome/libgnome/libgnomecanvas_2.30.3.bb, > do_configure > * meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb, > do_compile > * > meta-openembedded/meta-multimedia/recipes-multimedia/libdc1394/libdc1394_git.bb, > do_configure > * > meta-openembedded/meta-networking/recipes-protocols/quagga/quagga_0.99.21.bb, > do_compile > * > meta-openembedded/meta-networking/recipes-support/traceroute/traceroute_2.0.18.bb, > do_compile > * meta-openembedded/meta-oe/recipes-connectivity/daq/daq_2.0.2.bb, > do_install > * meta-openembedded/meta-oe/recipes-devtools/cloud9/cloud9_0.6.bb, > do_compile > * meta-openembedded/meta-oe/recipes-devtools/tcltk/tk_8.6.0.bb, do_compile > * meta-openembedded/meta-oe/recipes-extended/gnuplot/gnuplot_4.4.4.bb, > do_compile > * > meta-openembedded/meta-oe/recipes-extended/mml-widget/gtkmathview_0.8.0.bb, > do_compile > * meta-openembedded/meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb, > do_configure > * > meta-openembedded/meta-oe/recipes-multimedia/sound-themes/sound-theme-freedesktop_0.8.bb, > do_configure > * meta-openembedded/meta-oe/recipes-navigation/monav/monav_0.3.bb, > do_compile > * meta-openembedded/meta-oe/recipes-support/asio/asio_1.4.1.bb, do_compile > * meta-openembedded/meta-oe/recipes-support/inih/libinih_git.bb, > do_install > * > meta-openembedded/meta-oe/recipes-support/open-vcdiff/open-vcdiff_0.8.3.bb, > do_configure > * meta-openembedded/meta-xfce/recipes-apps/mousepad/mousepad_0.3.0.bb, > do_configure > * meta-openembedded/meta-xfce/recipes-apps/xarchiver/xarchiver_git.bb, > do_configure > * > meta-openembedded/meta-xfce/recipes-apps/xfce4-taskmanager/xfce4-taskmanager_git.bb, > do_configure > * > meta-openembedded/meta-xfce/recipes-panel-plugins/closebutton/xfce4-closebutton-plugin_git.bb, > do_configure > * > meta-openembedded/meta-xfce/recipes-xfce/xfce4-settings/xfce4-settings_git.bb, > do_configure > * meta-openembedded/meta-xfce/recipes-xfce/xfwm4/xfwm4_git.bb, > do_configure > Patches for xfce-receipes should go out today... Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] Make ppce300c3 tune hard-float by default
Hi Khem,
Thanks for your feedback!
On Tuesday, April 01, 2014 7:37 AM, Khem Raj wrote:
> On Fri, Mar 28, 2014 at 9:43 AM, Mats Kärrman wrote:
>> +# glibc configure options to make use of 603e specific sqrt/sqrtf routines
>> +GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3",
>> "--with-cpu=e300c3", "", d)}"
>
> looks good, may be the comment above can be more explanatory saying that
> glibc aliases e300c3 sqrt/sqrtf to 600e versions
The above statement depends on an added "Implies" file in eglibc and,
more important on a previous patch adding support for 603e/fpu sqrt.
How is the new Implies file best added, as a patch to the previous patch
or as a new patch?
BR // Mats
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] libarchive: fix CVE-2013-0211
On 04/01/2014 01:30 PM, Khem Raj wrote: On Fri, Mar 28, 2014 at 2:43 AM, Hongxu Jia wrote: ++ const size_t max_write = INT_MAX; I think INT_MAX is a mismatch here size_t may not be defined 'unsigned int' on all kind of architectures. How about test the size of size_t and assigned the related MAX value: const size_t max_write = (sizeof(size_t) >= sizeof(int))?INT_MAX:(sizeof(size_t) == sizeof(short))?SHRT_MAX:CHAR_MAX; //Hongxu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool: Add depends on binutils-cross
>OK is it cross, native or target recipe which has the problem ? >wouldnt it need to also depend on gcc-cross ? Only cross recipe has the problem. There is no need to gcc-cross. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libsdl: PACKAGECONFIG conversion
General cleanup + make it easier for distros / machines which
support OpenGL ES only to prevent attempts to build against libgl.
Signed-off-by: Andre McCurdy
---
meta/recipes-graphics/libsdl/libsdl_1.2.15.bb | 30 ++-
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
index e19c388..f72f74f 100644
--- a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
+++ b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
@@ -12,10 +12,6 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=27818cd7fd83877a8e3ef82b82798ef4"
PROVIDES = "virtual/libsdl"
-DEPENDS = "${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)}
\
- ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl
libglu', '', d)} \
- ${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxext
libxrandr libxrender', '', d)} \
- tslib"
DEPENDS_class-nativesdk = "${@base_contains('DISTRO_FEATURES', 'x11',
'virtual/nativesdk-libx11 nativesdk-libxrandr nativesdk-libxrender
nativesdk-libxext', '', d)}"
PR = "r3"
@@ -38,17 +34,31 @@ EXTRA_OECONF = "--disable-static --enable-cdrom
--enable-threads --enable-timers
--disable-mintaudio --disable-nasm --disable-video-dga \
--disable-video-fbcon --disable-video-ps2gs
--disable-video-ps3 \
--disable-xbios --disable-gem --disable-video-dummy \
---enable-input-events --enable-input-tslib --enable-pthreads \
-${@base_contains('DISTRO_FEATURES', 'directfb',
'--enable-video-directfb', '--disable-video-directfb', d)} \
-${@base_contains('DISTRO_FEATURES', 'opengl',
'--enable-video-opengl', '--disable-video-opengl', d)} \
-${@base_contains('DISTRO_FEATURES', 'x11',
'--enable-video-x11', '--disable-video-x11', d)} \
---disable-video-svga \
+--enable-input-events --enable-pthreads --disable-video-svga \
--disable-video-picogui --disable-video-qtopia
--enable-sdl-dlopen \
--disable-rpath \
--disable-pulseaudio"
-PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}"
+PACKAGECONFIG_ALSA ?= "${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '',
d)}"
+PACKAGECONFIG_DIRECTFB ?= "${@base_contains('DISTRO_FEATURES', 'directfb',
'directfb', '', d)}"
+# Warning: "opengl" in DISTRO_FEATURES implies GL and/or GLES but libsdl
supports GL only.
+PACKAGECONFIG_OPENGL ?= "${@base_contains('DISTRO_FEATURES', 'opengl',
'opengl', '', d)}"
+PACKAGECONFIG_TSLIB ?= "tslib"
+PACKAGECONFIG_X11 ?= "${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '',
d)}"
+
+PACKAGECONFIG ?= " \
+${PACKAGECONFIG_ALSA} \
+${PACKAGECONFIG_DIRECTFB} \
+${PACKAGECONFIG_OPENGL} \
+${PACKAGECONFIG_TSLIB} \
+${PACKAGECONFIG_X11} \
+"
+
PACKAGECONFIG[alsa] = "--enable-alsa
--disable-alsatest,--disable-alsa,alsa-lib,"
+PACKAGECONFIG[directfb] =
"--enable-video-directfb,--disable-video-directfb,directfb"
+PACKAGECONFIG[opengl] =
"--enable-video-opengl,--disable-video-opengl,virtual/libgl libglu"
+PACKAGECONFIG[tslib] = "--enable-input-tslib,--disable-input-tslib,tslib"
+PACKAGECONFIG[x11] = "--enable-video-x11,--disable-video-x11,virtual/libx11
libxext libxrandr libxrender"
PARALLEL_MAKE = ""
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
