Re: [OE-core] [PATCH] util-linux: fix owner and group for binaries in resulting image
Hi,
Are we sure this is not caused by the new glibc2.29/pseudo problems
that has been seen previously ?
Which distro are you building on, and which version of poky/oe are you using ?
/Jacob
On Mon, May 6, 2019 at 5:46 PM Popov Anton wrote:
>
> util-linux source produce some binaries with setuid bit set
>
> do_install function produce binaries in /sbin and /bin with uid:gid
> of user who build image this lead to messages like this:
> mount /dev/sdb1 /mnt/flash
> mount: only root can do that (effective UID is 1000)
> this patch changing owner of binaries in /bin and /sbin to 0:0
>
> Signed-off-by: Anton Popov
> ---
> meta/recipes-core/util-linux/util-linux.inc | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/meta/recipes-core/util-linux/util-linux.inc
> b/meta/recipes-core/util-linux/util-linux.inc
> index 34255a2dec..d75a2dd399 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -201,6 +201,27 @@ do_install () {
> fi
> }
>
> +# when building yocto image with non-root user some binaries appears in
> resulting
> +# image with rights of user who build image. This behaviour may lead to
> misfunction
> +# of some binaries like mount because of setuid bit on them:
> +# mount /dev/sdb1 /mnt/flash
> +# mount: only root can do that (effective UID is 1000)
> +# ls -ld which mount
> +# lrwxrwxrwx1 root root21 Jan 2 1970 /bin/mount ->
> /bin/mount.util-linux
> # root@mitx-fp32:/mnt/system/initrd# ls -ld
> /bin/mount.util-linux
># -rwsr-xr-x1
> 1000 1000 28020 Apr 23 12:49 /bin/mount.util-linux
> +do_install_append_class-target () {
> +for p in $sbinprogs $sbinprogs_a; do
> +if [ -f "${D}${base_sbindir}/$p" ]; then
> +chown 0:0 "${D}${base_sbindir}/$p"
> +fi
> +done
> +for p in $binprogs_a; do
> +if [ -f "${D}${base_bindir}/$p" ]; then
> +chown 0:0 "${D}${base_bindir}/$p"
> +fi
> +done
> +}
> +
> +
> # nologin causes a conflict with shadow-native
> # kill causes a conflict with coreutils-native (if ${bindir}==${base_bindir})
> do_install_append_class-native () {
> --
> 2.20.1
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] dhcp: Revert "dhcp: enable gentle shutdown" and reset handler
This reverts commit 4653fdd4b4cf13543e32fbcf09e50f60c1719a34
This patch is used to solve the problem in which dhcpd can not
be killed by SIGINT and SIGTERM. But it seems not good to rely
on ENABLE_GENTLE_SHUTDOWN, which is an "undesireable feature"
and will release its address after receive both signal, accoring
to the comment in "includes/site.h". Then there is no difference
between "dhclient -x" and "dhclient -r". We can find following
call trace from source code:
main() -> dhcp_context_create() -> isc_app_ctxstart()
-> isc__app_ctxstart()
The root cause is that exit_action() is registered as the signal
handler for SIGTERM and SIGINT, which do-nothing as the comment says.
To fix this problem, we could simply set the default action for
these two signals if ENABLE_GENTLE_SHUTDOWN is not set.
Signed-off-by: Rui Wang
---
...et-default-handler-for-SIGTERM-and-SIGINT.patch | 63 ++
.../dhcp/0006-site.h-enable-gentle-shutdown.patch | 27 --
meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb | 2 +-
3 files changed, 64 insertions(+), 28 deletions(-)
create mode 100644
meta/recipes-connectivity/dhcp/dhcp/0001-dhcp-set-default-handler-for-SIGTERM-and-SIGINT.patch
delete mode 100644
meta/recipes-connectivity/dhcp/dhcp/0006-site.h-enable-gentle-shutdown.patch
diff --git
a/meta/recipes-connectivity/dhcp/dhcp/0001-dhcp-set-default-handler-for-SIGTERM-and-SIGINT.patch
b/meta/recipes-connectivity/dhcp/dhcp/0001-dhcp-set-default-handler-for-SIGTERM-and-SIGINT.patch
new file mode 100644
index 000..d5c9e34
--- /dev/null
+++
b/meta/recipes-connectivity/dhcp/dhcp/0001-dhcp-set-default-handler-for-SIGTERM-and-SIGINT.patch
@@ -0,0 +1,63 @@
+From eaa74a4fd8ebcc031c63a8a39d20cd1ffe0eaf4f Mon Sep 17 00:00:00 2001
+From: Rui Wang
+Date: Tue, 7 May 2019 10:41:20 +0800
+Subject: [PATCH] dhcp: set default handler for SIGTERM and SIGINT
+
+dhcp uses function in bind to init it's state, which will block
+signal SIGTERM and SIGINT by default. This causes dhclient not
+able to be killed by those two signals if gentle-shutdown is
+disabled. So reset their signal handler to default in such
+situation.
+
+Signed-off-by: Rui Wang
+---
+ client/dhclient.c | 3 +++
+ relay/dhcrelay.c | 3 +++
+ server/dhcpd.c| 3 +++
+ 3 files changed, 9 insertions(+)
+
+diff --git a/client/dhclient.c b/client/dhclient.c
+index 825ab00..159cf39 100644
+--- a/client/dhclient.c
b/client/dhclient.c
+@@ -971,6 +971,9 @@ main(int argc, char **argv) {
+ /* install signal handlers */
+ signal(SIGINT, dhcp_signal_handler); /* control-c */
+ signal(SIGTERM, dhcp_signal_handler); /* kill */
++#else
++signal(SIGINT, SIG_DFL);
++signal(SIGTERM, SIG_DFL);
+ #endif
+
+ /* If we're not supposed to wait before getting the address,
+diff --git a/relay/dhcrelay.c b/relay/dhcrelay.c
+index d8caaaf..ec22385 100644
+--- a/relay/dhcrelay.c
b/relay/dhcrelay.c
+@@ -814,6 +814,9 @@ main(int argc, char **argv) {
+ /* install signal handlers */
+ signal(SIGINT, dhcp_signal_handler); /* control-c */
+ signal(SIGTERM, dhcp_signal_handler); /* kill */
++#else
++signal(SIGINT, SIG_DFL);
++signal(SIGTERM, SIG_DFL);
+ #endif
+
+ /* Start dispatching packets and timeouts... */
+diff --git a/server/dhcpd.c b/server/dhcpd.c
+index 55ffae7..f5aced3 100644
+--- a/server/dhcpd.c
b/server/dhcpd.c
+@@ -1052,6 +1052,9 @@ main(int argc, char **argv) {
+ /* install signal handlers */
+ signal(SIGINT, dhcp_signal_handler); /* control-c */
+ signal(SIGTERM, dhcp_signal_handler); /* kill */
++#else
++signal(SIGINT, SIG_DFL);
++signal(SIGTERM, SIG_DFL);
+ #endif
+
+ /* Log that we are about to start working */
+--
+1.8.3.1
+
diff --git
a/meta/recipes-connectivity/dhcp/dhcp/0006-site.h-enable-gentle-shutdown.patch
b/meta/recipes-connectivity/dhcp/dhcp/0006-site.h-enable-gentle-shutdown.patch
deleted file mode 100644
index 6ef70cc..000
---
a/meta/recipes-connectivity/dhcp/dhcp/0006-site.h-enable-gentle-shutdown.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-From 01641d146e4e6bea954e4a4ee1f6230b822665b4 Mon Sep 17 00:00:00 2001
-From: Chen Qi
-Date: Tue, 15 Aug 2017 15:37:49 +0800
-Subject: [PATCH 06/11] site.h: enable gentle shutdown
-
-Upstream-Status: Inappropriate [configuration]
-Signed-off-by: Chen Qi
-
-Rebase to 4.3.6
-Signed-off-by: Hongxu Jia
- includes/site.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-Index: dhcp-4.4.1/includes/site.h
-===
dhcp-4.4.1.orig/includes/site.h
-+++ dhcp-4.4.1/includes/site.h
-@@ -295,7 +295,7 @@
-situations. We plan to revisit this feature and may
-make non-backwards compatible changes including the
-removal of this define. Use at your own risk. */
--/* #define ENABLE_GENTLE_SHUTDOWN */
-+#define ENABLE_GENTLE_SHUTDOWN
-
- /* Include old error codes. This is
[OE-core] [PATCH V2 1/2] systemd: Add -Wno-error=format-overflow to fix biuld with gcc9
gcc9 throws additional warnings about format string overflow
Signed-off-by: Khem Raj
---
meta/recipes-core/systemd/systemd_242.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-core/systemd/systemd_242.bb
b/meta/recipes-core/systemd/systemd_242.bb
index a6b39d57e8..69b1f7ed0e 100644
--- a/meta/recipes-core/systemd/systemd_242.bb
+++ b/meta/recipes-core/systemd/systemd_242.bb
@@ -204,6 +204,8 @@ EXTRA_OEMESON += "-Dkexec-path=${sbindir}/kexec \
-Dsulogin-path=${base_sbindir}/sulogin \
-Dumount-path=${base_bindir}/umount"
+CFLAGS += "-Wno-error=format-overflow"
+
do_install() {
meson_do_install
install -d ${D}/${base_sbindir}
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] systemd: Fix build with gcc9
On Mon, May 06, 2019 at 10:51:35AM -0700, Khem Raj wrote: >... > +gcc-9 has become a bit stricter and can check all kind of formatted > +input/output functions which causes additional warnings when compiling > +networkd > + > +/src/basic/log.h:104:9: error: ‘%s’ directive argument is null > [-Werror=format-overflow=] > + log_internal_realm(LOG_REALM_PLUS_LEVEL(LOG_REALM, (level)), > __VA_ARGS__) >... > + if (r < 0) > + log_link_warning_errno(link, r, "Cannot %s IPv6 for > interface %s: %m", > +- enable_disable(!disabled), > link->ifname); > ++ enable_disable(!disabled), > ++ (link->ifname) ? link->ifname : > ""); >... The fix doesn't look correct to me: gcc says it "is null", so checking whether or not it is null doesn't match the error message. If it is a compiler bug as was at some point mentioned upstream, a better temporary workaround would be to stop making this an error with -Wno-error=format-overflow (untested). cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] gcc-target: Do not set --with-sysroot and gxx-include-dir paths
These options are not needed on target infact since the defaults would
be good enough for compiler to find the relevant headers and libraries
from compiler runtime
with gcc9 it starts to strip the sysroot from gxx-include-dir which
means it tries to look for gxx headers in localdir
ignoring nonexistent directory "usr/include/c++/9.0.1"
ignoring nonexistent directory "usr/include/c++/9.0.1/arm-yoe-linux-gnueabi"
ignoring nonexistent directory "usr/include/c++/9.0.1/backward"
instead of sysroot
Removing these options make it behave normal
Signed-off-by: Khem Raj
---
meta/recipes-devtools/gcc/gcc-target.inc | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-target.inc
b/meta/recipes-devtools/gcc/gcc-target.inc
index 6270059644..bdc6ff658f 100644
--- a/meta/recipes-devtools/gcc/gcc-target.inc
+++ b/meta/recipes-devtools/gcc/gcc-target.inc
@@ -2,9 +2,7 @@ GCCMULTILIB = "--enable-multilib"
require gcc-configure-common.inc
EXTRA_OECONF_PATHS = "\
---with-sysroot=/ \
--with-build-sysroot=${STAGING_DIR_TARGET} \
---with-gxx-include-dir=${includedir}/c++/${BINV} \
"
EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] systemd: Fix build with gcc9
gcc9 throws additional warnings about format string overflow
Signed-off-by: Khem Raj
---
...-format-overflow-warnings-with-gcc-9.patch | 41 +++
meta/recipes-core/systemd/systemd_242.bb | 1 +
2 files changed, 42 insertions(+)
create mode 100644
meta/recipes-core/systemd/systemd/0006-Fix-format-overflow-warnings-with-gcc-9.patch
diff --git
a/meta/recipes-core/systemd/systemd/0006-Fix-format-overflow-warnings-with-gcc-9.patch
b/meta/recipes-core/systemd/systemd/0006-Fix-format-overflow-warnings-with-gcc-9.patch
new file mode 100644
index 00..510ac22150
--- /dev/null
+++
b/meta/recipes-core/systemd/systemd/0006-Fix-format-overflow-warnings-with-gcc-9.patch
@@ -0,0 +1,41 @@
+From c8050da8b7b0e59e4d1d0e15a92b9ecad299dbbb Mon Sep 17 00:00:00 2001
+From: Khem Raj
+Date: Mon, 6 May 2019 10:41:15 -0700
+Subject: [PATCH] Fix format-overflow warnings with gcc-9
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+gcc-9 has become a bit stricter and can check all kind of formatted
+input/output functions which causes additional warnings when compiling
+networkd
+
+/src/basic/log.h:104:9: error: ‘%s’ directive argument is null
[-Werror=format-overflow=]
+ log_internal_realm(LOG_REALM_PLUS_LEVEL(LOG_REALM, (level)),
__VA_ARGS__)
+
+see https://github.com/systemd/systemd/issues/12454
+
+Upstream-Status: Pending
+
+Signed-off-by: Khem Raj
+---
+ src/network/networkd-link.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
+index 533193ac93..976cbbeaaa 100644
+--- a/src/network/networkd-link.c
b/src/network/networkd-link.c
+@@ -339,7 +339,8 @@ static int link_enable_ipv6(Link *link) {
+ r = sysctl_write_ip_property_boolean(AF_INET6, link->ifname,
"disable_ipv6", disabled);
+ if (r < 0)
+ log_link_warning_errno(link, r, "Cannot %s IPv6 for interface
%s: %m",
+- enable_disable(!disabled),
link->ifname);
++ enable_disable(!disabled),
++ (link->ifname) ? link->ifname :
"");
+ else
+ log_link_info(link, "IPv6 successfully %sd",
enable_disable(!disabled));
+
+--
+2.21.0
+
diff --git a/meta/recipes-core/systemd/systemd_242.bb
b/meta/recipes-core/systemd/systemd_242.bb
index a6b39d57e8..93c4472bab 100644
--- a/meta/recipes-core/systemd/systemd_242.bb
+++ b/meta/recipes-core/systemd/systemd_242.bb
@@ -22,6 +22,7 @@ SRC_URI += "file://touchscreen.rules \
file://0003-implment-systemd-sysv-install-for-OE.patch \
file://0004-rules-whitelist-hd-devices.patch \
file://0005-rules-watch-metadata-changes-in-ide-devices.patch \
+ file://0006-Fix-format-overflow-warnings-with-gcc-9.patch \
file://99-default.preset \
"
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] util-linux: fix owner and group for binaries in resulting image
util-linux source produce some binaries with setuid bit set
do_install function produce binaries in /sbin and /bin with uid:gid
of user who build image this lead to messages like this:
mount /dev/sdb1 /mnt/flash
mount: only root can do that (effective UID is 1000)
this patch changing owner of binaries in /bin and /sbin to 0:0
Signed-off-by: Anton Popov
---
meta/recipes-core/util-linux/util-linux.inc | 21 +
1 file changed, 21 insertions(+)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 34255a2dec..d75a2dd399 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -201,6 +201,27 @@ do_install () {
fi
}
+# when building yocto image with non-root user some binaries appears in
resulting
+# image with rights of user who build image. This behaviour may lead to
misfunction
+# of some binaries like mount because of setuid bit on them:
+# mount /dev/sdb1 /mnt/flash
+# mount: only root can do that (effective UID is 1000)
+# ls -ld which mount
+# lrwxrwxrwx1 root root21 Jan 2 1970 /bin/mount ->
/bin/mount.util-linux
# root@mitx-fp32:/mnt/system/initrd# ls -ld
/bin/mount.util-linux
# -rwsr-xr-x1 1000
1000 28020 Apr 23 12:49 /bin/mount.util-linux
+do_install_append_class-target () {
+for p in $sbinprogs $sbinprogs_a; do
+if [ -f "${D}${base_sbindir}/$p" ]; then
+chown 0:0 "${D}${base_sbindir}/$p"
+fi
+done
+for p in $binprogs_a; do
+if [ -f "${D}${base_bindir}/$p" ]; then
+chown 0:0 "${D}${base_bindir}/$p"
+fi
+done
+}
+
+
# nologin causes a conflict with shadow-native
# kill causes a conflict with coreutils-native (if ${bindir}==${base_bindir})
do_install_append_class-native () {
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] ell: add recipe
Please resend, patches do get lost sometimes.
Alex
On Mon, 6 May 2019 at 16:36, Oleksandr Kravchuk
wrote:
>
> Khem -
>
> Is it being hold for a specific reason or it was just lost? Thanks.
>
> On 24/04/2019 07:16, Oleksandr Kravchuk wrote:
> > ELL has originally been part of meta-openembedded, but newer versions
> > of some of the oe-core components depend on it, e.g. ofono.
> >
> > Signed-off-by: Oleksandr Kravchuk
> > ---
> > meta/conf/distro/include/maintainers.inc | 1 +
> > meta/recipes-core/ell/ell_0.19.bb| 22 ++
> > 2 files changed, 23 insertions(+)
> > create mode 100644 meta/recipes-core/ell/ell_0.19.bb
> >
> > diff --git a/meta/conf/distro/include/maintainers.inc
> > b/meta/conf/distro/include/maintainers.inc
> > index 41c2a95d53..c00e5b8c65 100644
> > --- a/meta/conf/distro/include/maintainers.inc
> > +++ b/meta/conf/distro/include/maintainers.inc
> > @@ -166,6 +166,7 @@ RECIPE_MAINTAINER_pn-eglinfo-fb = "Alexander Kanavin
> > "
> > RECIPE_MAINTAINER_pn-eglinfo-x11 = "Alexander Kanavin
> > "
> > RECIPE_MAINTAINER_pn-eglinfo-wayland = "Alexander Kanavin
> > "
> > RECIPE_MAINTAINER_pn-elfutils = "Hongxu Jia "
> > +RECIPE_MAINTAINER_pn-ell = "Oleksandr Kravchuk
> > "
> > RECIPE_MAINTAINER_pn-enchant = "Anuj Mittal "
> > RECIPE_MAINTAINER_pn-encodings = "Armin Kuster "
> > RECIPE_MAINTAINER_pn-epiphany = "Alexander Kanavin
> > "
> > diff --git a/meta/recipes-core/ell/ell_0.19.bb
> > b/meta/recipes-core/ell/ell_0.19.bb
> > new file mode 100644
> > index 00..8f635e673c
> > --- /dev/null
> > +++ b/meta/recipes-core/ell/ell_0.19.bb
> > @@ -0,0 +1,22 @@
> > +SUMMARY = "Embedded Linux Library"
> > +DESCRIPTION = "The Embedded Linux Library (ELL) provides core, \
> > +low-level functionality for system daemons. It typically has no \
> > +dependencies other than the Linux kernel, C standard library, and \
> > +libdl (for dynamic linking). While ELL is designed to be efficient \
> > +and compact enough for use on embedded Linux platforms, it is not \
> > +limited to resource-constrained systems."
> > +SECTION = "libs"
> > +LICENSE = "LGPLv2.1"
> > +LIC_FILES_CHKSUM = "file://COPYING;md5=fb504b67c50331fc78734fed90fb0e09"
> > +
> > +DEPENDS = "dbus"
> > +
> > +inherit autotools pkgconfig
> > +
> > +SRC_URI =
> > "https://mirrors.edge.kernel.org/pub/linux/libs/${BPN}/${BPN}-${PV}.tar.xz;
> > +SRC_URI[md5sum] = "4356397ca11d5f8ec7f1aaf1e91ffea4"
> > +SRC_URI[sha256sum] =
> > "a5a4d45ca002dd91560fcd565e696f59e82631e69c927115dafc640f0b8d779c"
> > +
> > +do_configure_prepend () {
> > +mkdir -p ${S}/build-aux
> > +}
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] ell: add recipe
Khem -
Is it being hold for a specific reason or it was just lost? Thanks.
On 24/04/2019 07:16, Oleksandr Kravchuk wrote:
> ELL has originally been part of meta-openembedded, but newer versions
> of some of the oe-core components depend on it, e.g. ofono.
>
> Signed-off-by: Oleksandr Kravchuk
> ---
> meta/conf/distro/include/maintainers.inc | 1 +
> meta/recipes-core/ell/ell_0.19.bb| 22 ++
> 2 files changed, 23 insertions(+)
> create mode 100644 meta/recipes-core/ell/ell_0.19.bb
>
> diff --git a/meta/conf/distro/include/maintainers.inc
> b/meta/conf/distro/include/maintainers.inc
> index 41c2a95d53..c00e5b8c65 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -166,6 +166,7 @@ RECIPE_MAINTAINER_pn-eglinfo-fb = "Alexander Kanavin
> "
> RECIPE_MAINTAINER_pn-eglinfo-x11 = "Alexander Kanavin
> "
> RECIPE_MAINTAINER_pn-eglinfo-wayland = "Alexander Kanavin
> "
> RECIPE_MAINTAINER_pn-elfutils = "Hongxu Jia "
> +RECIPE_MAINTAINER_pn-ell = "Oleksandr Kravchuk
> "
> RECIPE_MAINTAINER_pn-enchant = "Anuj Mittal "
> RECIPE_MAINTAINER_pn-encodings = "Armin Kuster "
> RECIPE_MAINTAINER_pn-epiphany = "Alexander Kanavin "
> diff --git a/meta/recipes-core/ell/ell_0.19.bb
> b/meta/recipes-core/ell/ell_0.19.bb
> new file mode 100644
> index 00..8f635e673c
> --- /dev/null
> +++ b/meta/recipes-core/ell/ell_0.19.bb
> @@ -0,0 +1,22 @@
> +SUMMARY = "Embedded Linux Library"
> +DESCRIPTION = "The Embedded Linux Library (ELL) provides core, \
> +low-level functionality for system daemons. It typically has no \
> +dependencies other than the Linux kernel, C standard library, and \
> +libdl (for dynamic linking). While ELL is designed to be efficient \
> +and compact enough for use on embedded Linux platforms, it is not \
> +limited to resource-constrained systems."
> +SECTION = "libs"
> +LICENSE = "LGPLv2.1"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=fb504b67c50331fc78734fed90fb0e09"
> +
> +DEPENDS = "dbus"
> +
> +inherit autotools pkgconfig
> +
> +SRC_URI =
> "https://mirrors.edge.kernel.org/pub/linux/libs/${BPN}/${BPN}-${PV}.tar.xz;
> +SRC_URI[md5sum] = "4356397ca11d5f8ec7f1aaf1e91ffea4"
> +SRC_URI[sha256sum] =
> "a5a4d45ca002dd91560fcd565e696f59e82631e69c927115dafc640f0b8d779c"
> +
> +do_configure_prepend () {
> +mkdir -p ${S}/build-aux
> +}
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][PATCH] systemd: Default to non-stateless images
On Mon, May 6, 2019 at 12:18 PM Jonas Bonn wrote: > > Hi Alex, > > On 06/05/2019 11:36, Alex Kiernan wrote: > > On Mon, May 6, 2019 at 5:54 AM Jonas Bonn wrote: > >> > >> Hi Alex, > >> > >> The below is fine and looks good. The one thing that bothers me about > >> this is that "stateless" isn't really a property of the "distro", rather > >> it's a property of the image/machine. > > > > I agree it should be part of image, I'll respin it. > > > >> I suspect, in the same sense that > >> we have readonly-rootfs, that we should probably have image features > >> "stateless-rootfs" (no /etc, no /var) and "volatile-rootfs" (no /var). > >> > > > > That makes sense to me > > > >> Furthermore, if you want to boot with 'ro' on the command-line, I really > >> think you need to build your image with the "readonly-rootfs" feature > >> set. The default should be writable+persistent /etc as that's the > >> configuration used 99% of the time (currently). "readonly-rootfs" does > >> a bit more than just creating machine-id but it's all relevant to the > >> 'ro' case where /etc isn't writable. > >> > > > > I think there's (at least) two use cases for ro boot: > > > > - systems which boot ro and stay that way > > - systems which transition to rw during systemd-remount-fs > > > > I'm in the second case as I have no initramfs and need the filesystem > > readonly until it's fscked/remounted rw. > > I'd argue that you are abusing systemd for this because systemd > explicity requires /etc to be writable. The fact that it works on a > read-only /etc is both incidental and fragile. > Not sure... systemd is explicit in its machinery for some parts of this ro->rw transition (e.g. systemd-machine-id-commit.service), though it's admittedly silent on what the state of the rest of /etc is. > That said, I understand why you want to do this. Have you considered > putting the fsck in a "systemd generator" that doesn't return until fsck > finishes? Generators are kind of like units that run before systemd > starts... or, at least, they can be (ab)used in this way. Systemd won't > start until all the generators are finished (the idea being that the > generators may be responsible for creating units dynamically). > If systemd comes along and breaks it yes... or I'll teach ostree-prepare-root how to do it, but right now the sequencing is all there in systemd. -- Alex Kiernan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][PATCH] systemd: Default to non-stateless images
Hi Alex, On 06/05/2019 11:36, Alex Kiernan wrote: On Mon, May 6, 2019 at 5:54 AM Jonas Bonn wrote: Hi Alex, The below is fine and looks good. The one thing that bothers me about this is that "stateless" isn't really a property of the "distro", rather it's a property of the image/machine. I agree it should be part of image, I'll respin it. I suspect, in the same sense that we have readonly-rootfs, that we should probably have image features "stateless-rootfs" (no /etc, no /var) and "volatile-rootfs" (no /var). That makes sense to me Furthermore, if you want to boot with 'ro' on the command-line, I really think you need to build your image with the "readonly-rootfs" feature set. The default should be writable+persistent /etc as that's the configuration used 99% of the time (currently). "readonly-rootfs" does a bit more than just creating machine-id but it's all relevant to the 'ro' case where /etc isn't writable. I think there's (at least) two use cases for ro boot: - systems which boot ro and stay that way - systems which transition to rw during systemd-remount-fs I'm in the second case as I have no initramfs and need the filesystem readonly until it's fscked/remounted rw. I'd argue that you are abusing systemd for this because systemd explicity requires /etc to be writable. The fact that it works on a read-only /etc is both incidental and fragile. That said, I understand why you want to do this. Have you considered putting the fsck in a "systemd generator" that doesn't return until fsck finishes? Generators are kind of like units that run before systemd starts... or, at least, they can be (ab)used in this way. Systemd won't start until all the generators are finished (the idea being that the generators may be responsible for creating units dynamically). Just for clarification: i) volatile-rootfs: means there's no point in prepopulating /var because it's on a tmpfs and needs to be populated at boot time ii) stateless-rootfs: means there's no point in prepopulating neither /etc nor /var because they are on a tmpfs and need to be populated at boot time iii) readonly-rootfs: means that /etc is really not writable so it's important that: the systemd first-boot stuff needs to be done at build time: machine-id, unit files set up, all tmpfiles.d snippets that touch /etc and /var need to be done in advance. I'm assuming definitions from here? http://0pointer.net/blog/projects/stateless.html Either way, those work for me... Correct. Thanks for digging that up... I should have posted it myself. /Jonas -- Alex Kiernan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Status of meson cross compilation files in the SDK
Looking at latest master, seems like nativesdk-meson recipe takes care of this, via meson.cross template and meson-setup.py that runs at SDK setup? Alex On Sun, 5 May 2019 at 20:29, Carlos Rafael Giani wrote: > > Last I've checked, deploying meson cross compilation files with a Yocto > SDK is tricky because that meson file has to be generated during SDK set > up and because meson assumes that environment variables like $CC refer > to the native host compiler. > > Has anything changed? I have some bits of code here that use meson, and > cross compiling them with the SDK has been difficult at best. > > -- > ___ > 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] [OE-Core][PATCH] systemd: Default to non-stateless images
Hi Peter, On 06/05/2019 12:28, Peter Kjellerstedt wrote: -Original Message- From: openembedded-core-boun...@lists.openembedded.org On Behalf Of Jonas Bonn Sent: den 6 maj 2019 06:54 To: Alex Kiernan ; openembedded- c...@lists.openembedded.org Subject: Re: [OE-core] [OE-Core][PATCH] systemd: Default to non- stateless images Hi Alex, The below is fine and looks good. The one thing that bothers me about this is that "stateless" isn't really a property of the "distro", rather it's a property of the image/machine. I suspect, in the same sense that we have readonly-rootfs, that we should probably have image features "stateless-rootfs" (no /etc, no /var) and "volatile-rootfs" (no /var). Furthermore, if you want to boot with 'ro' on the command-line, I really think you need to build your image with the "readonly-rootfs" feature set. The default should be writable+persistent /etc as that's the configuration used 99% of the time (currently). "readonly-rootfs" does a bit more than just creating machine-id but it's all relevant to the 'ro' case where /etc isn't writable. Just for clarification: i) volatile-rootfs: means there's no point in prepopulating /var because it's on a tmpfs and needs to be populated at boot time This doesn't really say anything about the state of the rootfs outside of /var, i.e., is it writable or read-only? ii) stateless-rootfs: means there's no point in prepopulating neither /etc nor /var because they are on a tmpfs and need to be populated at boot time Same here. iii) readonly-rootfs: means that /etc is really not writable so it's important that: the systemd first-boot stuff needs to be done at build time: machine-id, unit files set up, all tmpfiles.d snippets that touch /etc and /var need to be done in advance. /Jonas Maybe we need some more generic way of describing the intended structure of the image? E.g., what are the expected behavior of /etc, /var and the rest of the rootfs? For each they can typically be "read-only", "persistent" (writable and survives reboots) or "volatile" (writable, but doesn't survive a reboot). Alex already put this link into an earlier response but I'll repeat it here and defer to it for the terminology and justification. http://0pointer.net/blog/projects/stateless.html That said, the paradigm here is that: i) /etc MUST be writable ii) /var MUST be writable iii) For everything, it doesn't matter... writable or not. Most importantly, though, read-only is OK and no program should assume that they can write outside of /etc and /var (and /tmp and /run). /Jonas //Peter -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][PATCH] systemd: Default to non-stateless images
> -Original Message- > From: openembedded-core-boun...@lists.openembedded.org core-boun...@lists.openembedded.org> On Behalf Of Jonas Bonn > Sent: den 6 maj 2019 06:54 > To: Alex Kiernan ; openembedded- > c...@lists.openembedded.org > Subject: Re: [OE-core] [OE-Core][PATCH] systemd: Default to non- > stateless images > > Hi Alex, > > The below is fine and looks good. The one thing that bothers me about > this is that "stateless" isn't really a property of the "distro", > rather > it's a property of the image/machine. I suspect, in the same sense > that > we have readonly-rootfs, that we should probably have image features > "stateless-rootfs" (no /etc, no /var) and "volatile-rootfs" (no /var). > > Furthermore, if you want to boot with 'ro' on the command-line, I > really > think you need to build your image with the "readonly-rootfs" feature > set. The default should be writable+persistent /etc as that's the > configuration used 99% of the time (currently). "readonly-rootfs" does > a bit more than just creating machine-id but it's all relevant to the > 'ro' case where /etc isn't writable. > > Just for clarification: > > i) volatile-rootfs: means there's no point in prepopulating /var > because it's on a tmpfs and needs to be populated at boot time This doesn't really say anything about the state of the rootfs outside of /var, i.e., is it writable or read-only? > ii) stateless-rootfs: means there's no point in prepopulating neither > /etc nor /var because they are on a tmpfs and need to be populated at > boot time Same here. > iii) readonly-rootfs: means that /etc is really not writable so it's > important that: the systemd first-boot stuff needs to be done at build > time: machine-id, unit files set up, all tmpfiles.d snippets that > touch /etc and /var need to be done in advance. > > /Jonas Maybe we need some more generic way of describing the intended structure of the image? E.g., what are the expected behavior of /etc, /var and the rest of the rootfs? For each they can typically be "read-only", "persistent" (writable and survives reboots) or "volatile" (writable, but doesn't survive a reboot). //Peter -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] glib-2.0: fix ptest failures
On Sun, May 05, 2019 at 02:09:49PM +0800, Yu, Mingli wrote: > On 2019年04月30日 21:16, Burton, Ross wrote: > > On Tue, 30 Apr 2019 at 08:45, wrote: >... > > > * Increase the timeout to 15 minutes as the default > > >timeout which is 5 minutes is not enough to fix below error: > > >| Executing: glib/actions.test > > >| Test timed out after 300 seconds > > >| cleaning up pid 13050 > > >| FAIL: glib/actions.test (Child process killed by signal 9) > > > > Looks like we're working around a test case that is going to fail > > because it is timing out. Let's investigate why it is taking so long > > instead. > > The sub-case named test_dbus_threaded[/actions/dbus/threaded] of > glib/actions.test takes almost most of the time, the more details as below. >... On what hardware it this? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][PATCH] systemd: Default to non-stateless images
On Mon, May 6, 2019 at 5:54 AM Jonas Bonn wrote: > > Hi Alex, > > The below is fine and looks good. The one thing that bothers me about > this is that "stateless" isn't really a property of the "distro", rather > it's a property of the image/machine. I agree it should be part of image, I'll respin it. > I suspect, in the same sense that > we have readonly-rootfs, that we should probably have image features > "stateless-rootfs" (no /etc, no /var) and "volatile-rootfs" (no /var). > That makes sense to me > Furthermore, if you want to boot with 'ro' on the command-line, I really > think you need to build your image with the "readonly-rootfs" feature > set. The default should be writable+persistent /etc as that's the > configuration used 99% of the time (currently). "readonly-rootfs" does > a bit more than just creating machine-id but it's all relevant to the > 'ro' case where /etc isn't writable. > I think there's (at least) two use cases for ro boot: - systems which boot ro and stay that way - systems which transition to rw during systemd-remount-fs I'm in the second case as I have no initramfs and need the filesystem readonly until it's fscked/remounted rw. > Just for clarification: > > i) volatile-rootfs: means there's no point in prepopulating /var > because it's on a tmpfs and needs to be populated at boot time > > ii) stateless-rootfs: means there's no point in prepopulating neither > /etc nor /var because they are on a tmpfs and need to be populated at > boot time > > iii) readonly-rootfs: means that /etc is really not writable so it's > important that: the systemd first-boot stuff needs to be done at build > time: machine-id, unit files set up, all tmpfiles.d snippets that touch > /etc and /var need to be done in advance. > I'm assuming definitions from here? http://0pointer.net/blog/projects/stateless.html Either way, those work for me... -- Alex Kiernan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] cml1.bbclass: fix undefined behavior
Whenever cml1 do_configure is used with a defconfig, oldconfig waits for
input. This silently fails on recent kconfig projects with:
"Error in reading or end of file."
We cannot use a more up to date kconfig target such as olddefconfig,
because busybox does not support it.
Signed-off-by: Stefan Müller-Klieser
---
v2:
- switch to good old yes '' | to support busybox
- adapt commit message
meta/classes/cml1.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index 98d24cec746b..c7f6723cb3de 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -1,7 +1,7 @@
cml1_do_configure() {
set -e
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
- oe_runmake oldconfig
+ yes '' | oe_runmake oldconfig
}
EXPORT_FUNCTIONS do_configure
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [warrior][PATCH] uboot-sign: add support for different u-boot configurations
From: Andreas Obergschwandtner
This is done by concatenating the DTB with the kernels public key
to all built u-boot binaries. Furthermore the installation of all
the binaries is required.
Signed-off-by: Andreas Obergschwandtner
Signed-off-by: Richard Purdie
Signed-off-by: Richard Leitner
---
meta/classes/uboot-sign.bbclass | 85 +
1 file changed, 54 insertions(+), 31 deletions(-)
diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 9e3d1d6fc1..2da43655aa 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -45,49 +45,72 @@ UBOOT_NODTB_SYMLINK ?=
"u-boot-nodtb-${MACHINE}.${UBOOT_SUFFIX}"
# Functions in this bbclass is for u-boot only
UBOOT_PN = "${@d.getVar('PREFERRED_PROVIDER_u-boot') or 'u-boot'}"
+concat_dtb_helper() {
+ if [ -e ${UBOOT_DTB_BINARY} ]; then
+ ln -sf ${UBOOT_DTB_IMAGE} ${DEPLOYDIR}/${UBOOT_DTB_BINARY}
+ ln -sf ${UBOOT_DTB_IMAGE} ${DEPLOYDIR}/${UBOOT_DTB_SYMLINK}
+ fi
+
+ if [ -f ${UBOOT_NODTB_BINARY} ]; then
+ install ${UBOOT_NODTB_BINARY} ${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}
+ ln -sf ${UBOOT_NODTB_IMAGE} ${UBOOT_NODTB_SYMLINK}
+ ln -sf ${UBOOT_NODTB_IMAGE} ${UBOOT_NODTB_BINARY}
+ fi
+
+ # Concatenate U-Boot w/o DTB & DTB with public key
+ # (cf. kernel-fitimage.bbclass for more details)
+ deployed_uboot_dtb_binary='${DEPLOY_DIR_IMAGE}/${UBOOT_DTB_IMAGE}'
+ if [ "x${UBOOT_SUFFIX}" = "ximg" -o "x${UBOOT_SUFFIX}" = "xrom" ] && \
+ [ -e "$deployed_uboot_dtb_binary" ]; then
+ oe_runmake EXT_DTB=$deployed_uboot_dtb_binary
+ install ${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
+ elif [ -e "${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}" -a -e
"$deployed_uboot_dtb_binary" ]; then
+ cd ${DEPLOYDIR}
+ cat ${UBOOT_NODTB_IMAGE} $deployed_uboot_dtb_binary | tee
${UBOOT_BINARY} > ${UBOOT_IMAGE}
+ elif [ -n "${UBOOT_DTB_BINARY}" ]; then
+ bbwarn "Failure while adding public key to u-boot binary.
Verified boot won't be available."
+ fi
+}
+
concat_dtb() {
if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${PN}" = "${UBOOT_PN}" ]; then
mkdir -p ${DEPLOYDIR}
- if [ -e ${B}/${UBOOT_DTB_BINARY} ]; then
- ln -sf ${UBOOT_DTB_IMAGE}
${DEPLOYDIR}/${UBOOT_DTB_BINARY}
- ln -sf ${UBOOT_DTB_IMAGE}
${DEPLOYDIR}/${UBOOT_DTB_SYMLINK}
- fi
-
- if [ -f ${B}/${UBOOT_NODTB_BINARY} ]; then
-install ${B}/${UBOOT_NODTB_BINARY}
${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}
-ln -sf ${UBOOT_NODTB_IMAGE} ${UBOOT_NODTB_SYMLINK}
-ln -sf ${UBOOT_NODTB_IMAGE} ${UBOOT_NODTB_BINARY}
- fi
-
- # Concatenate U-Boot w/o DTB & DTB with public key
- # (cf. kernel-fitimage.bbclass for more details)
-
deployed_uboot_dtb_binary='${DEPLOY_DIR_IMAGE}/${UBOOT_DTB_IMAGE}'
- if [ "x${UBOOT_SUFFIX}" = "ximg" -o "x${UBOOT_SUFFIX}" = "xrom"
] && \
- [ -e "$deployed_uboot_dtb_binary" ]; then
+ if [ -n "${UBOOT_CONFIG}" ]; then
+ for config in ${UBOOT_MACHINE}; do
+ cd ${B}/${config}
+ concat_dtb_helper
+ done
+ else
cd ${B}
- oe_runmake EXT_DTB=$deployed_uboot_dtb_binary
- install ${B}/${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
- elif [ -e "${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}" -a -e
"$deployed_uboot_dtb_binary" ]; then
- cd ${DEPLOYDIR}
- cat ${UBOOT_NODTB_IMAGE} $deployed_uboot_dtb_binary |
tee ${B}/${UBOOT_BINARY} > ${UBOOT_IMAGE}
- elif [ -n "${UBOOT_DTB_BINARY}" ]; then
- bbwarn "Failure while adding public key to u-boot
binary. Verified boot won't be available."
+ concat_dtb_helper
fi
fi
}
# Install UBOOT_DTB_BINARY to datadir, so that kernel can use it for
# signing, and kernel will deploy UBOOT_DTB_BINARY after signs it.
+install_helper() {
+ if [ -f ${UBOOT_DTB_BINARY} ]; then
+ install -d ${D}${datadir}
+ # UBOOT_DTB_BINARY is a symlink to UBOOT_DTB_IMAGE, so we
+ # need both of them.
+ install ${UBOOT_DTB_BINARY} ${D}${datadir}/${UBOOT_DTB_IMAGE}
+ ln -sf ${UBOOT_DTB_IMAGE} ${D}${datadir}/${UBOOT_DTB_BINARY}
+ elif [ -n "${UBOOT_DTB_BINARY}" ]; then
+ bbwarn "${UBOOT_DTB_BINARY} not found"
+ fi
+}
+
do_install_append() {
if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${PN}" = "${UBOOT_PN}" ]; then
- if [ -f ${B}/${UBOOT_DTB_BINARY} ]; then
-
[OE-core] [PATCH v3] distutils: Run python from the PATH in the -native case as well
The python distutils generate a python wrapper script for each package,
containing shebang lines pointing to the python executable.
In our case, this is a fully-qualified path to python-native in the
recipe-sysroot-native.
Ubuntu 18.04 restricts the useful length of the shebang line to 125
characters, and Ubuntu 16.04 restricts it to 77. In both cases, the
staged python script fails to run due to the length of the path to
the python-native executable.
Replace the shebang line with nativepython or nativepython3 as appropriate.
The nativepython symlink is installed by the python-native recipe:
#!/usr/bin/env nativepython
We were already doing this for on-target distutils components.
This change applies the sed-line to -native distutils components as well.
In this way, -native clients of these components can invoke the wrapper scripts
directly, without themselves needing to inherit pythonnative.
This works around a known setuptools issue:
https://github.com/pypa/setuptools/issues/494
Even once this issue has been resolved upstream,
we will still need to replace `python` with `nativepython`
Signed-off-by: Douglas Royds
---
meta/classes/distutils.bbclass | 11 +--
meta/classes/distutils3.bbclass | 7 +--
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index 9862731493..b5c9c2fbbd 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -9,6 +9,9 @@ DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
--install-lib=${PYTHON_SITEPACKAGES_DIR} \
--install-data=${datadir}"
+DISTUTILS_PYTHON = "python"
+DISTUTILS_PYTHON_class-native = "nativepython"
+
distutils_do_configure() {
if [ "${CLEANBROKEN}" != "1" ] ; then
NO_FETCH_BUILD=1 \
@@ -53,18 +56,14 @@ distutils_do_install() {
if test -e ${D}${bindir} ; then
for i in ${D}${bindir}/* ; do \
-if [ ${PN} != "${BPN}-native" ]; then
- sed -i -e
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ python:g $i
- fi
+sed -i -e
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\
${DISTUTILS_PYTHON}:g $i
sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
done
fi
if [ -e ${D}${sbindir} ]; then
for i in ${D}${sbindir}/* ; do \
-if [ ${PN} != "${BPN}-native" ]; then
- sed -i -e
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ python:g $i
- fi
+sed -i -e
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\
${DISTUTILS_PYTHON}:g $i
sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
done
fi
diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
index 834e322474..42e7f5ae53 100644
--- a/meta/classes/distutils3.bbclass
+++ b/meta/classes/distutils3.bbclass
@@ -10,6 +10,9 @@ DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
--install-lib=${PYTHON_SITEPACKAGES_DIR} \
--install-data=${datadir}"
+DISTUTILS_PYTHON = "python3"
+DISTUTILS_PYTHON_class-native = "nativepython3"
+
distutils3_do_configure() {
if [ "${CLEANBROKEN}" != "1" ] ; then
NO_FETCH_BUILD=1 \
@@ -57,14 +60,14 @@ distutils3_do_install() {
if test -e ${D}${bindir} ; then
for i in ${D}${bindir}/* ; do \
-sed -i -e
s:${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}:${USRBINPATH}/env\
${PYTHON_PN}:g $i
+sed -i -e
s:${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}:${USRBINPATH}/env\
${DISTUTILS_PYTHON}:g $i
sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
done
fi
if test -e ${D}${sbindir}; then
for i in ${D}${sbindir}/* ; do \
-sed -i -e
s:${STAGING_BINDIR_NATIVE}/python-${PYTHON_PN}/${PYTHON_PN}:${USRBINPATH}/env\
${PYTHON_PN}:g $i
+sed -i -e
s:${STAGING_BINDIR_NATIVE}/python-${PYTHON_PN}/${PYTHON_PN}:${USRBINPATH}/env\
${DISTUTILS_PYTHON}:g $i
sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
done
fi
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
