Re: [OE-core] [PATCH 2/2] weston: upgrade to 4.0.0

2018-04-13 Thread Khem Raj



On 4/11/18 3:11 PM, Paul Eggleton wrote:

Yes, this is a bit of a known bug although I didn't actually file one until
now:

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

Cheers,
Paul

On Wednesday, 11 April 2018 11:17:51 AM NZST Burton, Ross wrote:

Ah presumably this is because the U-S is after the scissors.  Denys,
when you add it back, can you put it above the ---?



Upstream-Status is a Yocto project invention that can confuse other 
communities when submitting the patches for those packages upstream and 
Sign-off-by is also in same bucket in many upstream packages. We need to 
be able to support patch headers that are git am'able upstream as well 
as to openembedded recipe created trees.


One still has to delete these tags but if you forget its still is ok 
since they will be ignored with git am.



Ross

On 11 April 2018 at 00:16, Burton, Ross  wrote:

On 10 April 2018 at 20:06, Denys Dmytriyenko  wrote:

diff --git a/meta/recipes-graphics/wayland/weston/0001-make-error-

portable.patch b/meta/recipes-graphics/wayland/weston/0001-make-error-
portable.patch

index 0671a45..6799254 100644
--- a/meta/recipes-graphics/wayland/weston/0001-make-error-portable.patch
+++ b/meta/recipes-graphics/wayland/weston/0001-make-error-portable.patch
@@ -1,26 +1,25 @@
-From c22e90365d89346258394833cbcad03ff32b2e27 Mon Sep 17 00:00:00 2001
+From ad1d2161c811cff25d1684c33611f300adb753bc Mon Sep 17 00:00:00 2001
  From: Khem Raj 
  Date: Fri, 29 May 2015 20:56:00 -0700
-Subject: [PATCH weston] make error() portable
+Subject: [PATCH] make error() portable

  error() is not posix but gnu extension so may not be available on all
  kind of systemsi e.g. musl.

  Signed-off-by: Khem Raj 

-Upstream-Status: Submitted


Ah, I've seen this before and was wondering if it was a genuine
mistake or devtool being bad.

devtool refresh is doing A Bad Thing and for some reason dropping the
Upstream-Status tag.  Alex, can you see why this is?  Denys, can you
edit it back in?

Ross






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


[OE-core] [PATCH v5] rootfs-postcommands.bbclass: improve binary reproducibility

2018-04-13 Thread Juro Bystricky
Conditionally support binary reproducibility of rootfs images.
If REPRODUCIBLE_TIMESTAMP_ROOTFS is specified then:

1. set /etc/timestamp to a reproducible value
2. set /etc/version to a reproducible value
3. set /etc/gconf: set mtime in all %gconf.xml to reproducible values

The reproducible value is taken from the variable REPRODUCIBLE_TIMESTAMP_ROOTFS.

[YOCTO #11176]
[YOCTO #12422]

Signed-off-by: Juro Bystricky 
---
 meta/classes/rootfs-postcommands.bbclass | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index a4e627f..5522209 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -56,6 +56,7 @@ ROOTFS_POSTPROCESS_COMMAND_append_qemuall = 
"${SSH_DISABLE_DNS_LOOKUP}"
 SORT_PASSWD_POSTPROCESS_COMMAND ??= " sort_passwd; "
 python () {
 d.appendVar('ROOTFS_POSTPROCESS_COMMAND', 
'${SORT_PASSWD_POSTPROCESS_COMMAND}')
+d.appendVar('ROOTFS_POSTPROCESS_COMMAND', 'rootfs_reproducible;')
 }
 
 systemd_create_users () {
@@ -256,10 +257,17 @@ python write_image_manifest () {
 os.symlink(os.path.basename(manifest_name), manifest_link)
 }
 
-# Can be use to create /etc/timestamp during image construction to give a 
reasonably
+# Can be used to create /etc/timestamp during image construction to give a 
reasonably
 # sane default time setting
 rootfs_update_timestamp () {
-   date -u +%4Y%2m%2d%2H%2M%2S >${IMAGE_ROOTFS}/etc/timestamp
+   if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then
+   # Convert UTC into %4Y%2m%2d%2H%2M%2S
+   sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS} 
+%4Y%2m%2d%2H%2M%2S`
+   else
+   sformatted=`date -u +%4Y%2m%2d%2H%2M%2S`
+   fi
+   echo $sformatted > ${IMAGE_ROOTFS}/etc/timestamp
+   bbnote "rootfs_update_timestamp: set /etc/timestamp to $sformatted"
 }
 
 # Prevent X from being started
@@ -328,3 +336,16 @@ python rootfs_log_check_recommends() {
 if 'unsatisfied recommendation for' in line:
 bb.warn('[log_check] %s: %s' % (d.getVar('PN'), line))
 }
+
+# Perform any additional adjustments needed to make rootf binary reproducible
+rootfs_reproducible () {
+   if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then
+   # Convert UTC into %4Y%2m%2d%2H%2M%2S
+   sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS} 
+%4Y%2m%2d%2H%2M%2S`
+   echo $sformatted > ${IMAGE_ROOTFS}/etc/version
+   bbnote "rootfs_reproducible: set /etc/version to $sformatted"
+
+   find ${IMAGE_ROOTFS}/etc/gconf -name '%gconf.xml' -print0 | 
xargs -0r \
+   sed -i -e 
's@\bmtime="[0-9][0-9]*"@mtime="'${REPRODUCIBLE_TIMESTAMP_ROOTFS}'"@g'
+   fi
+}
-- 
2.7.4

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


Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build

2018-04-13 Thread Alexander Kanavin

On 04/13/2018 11:29 PM, Bystricky, Juro wrote:

Yes, I do get warnings, but in both cases (skipping the renaming and also if 
renamed  with MLPREFIX):
WARNING: core-image-minimal-1.0-r0 do_populate_sdk: The postinstall intercept 
hook 'update_gio_module_cache-nativesdk' failed, details in 
/data/master-master/poky/build-x86_64-mingw32-sdk-core-image-minimal/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_populate_sdk

So skipping the renaming will at least give me a correctly named executable in 
the package.


The correctly named executable is the renamed one, as it is then 
consistent with what is in every other nativesdk- package (Linux-hosted 
ones), so the intercept script can properly pick it up. It is not used 
anywhere else except there.



Are you sure the postinst-intercepts can even work with Windows .exe 
executables?
If I understand this correctly, you use a qemuwrapper attempting to run Windows 
executable, and I
cannot imagine this would work. But maybe I am missing something here.


This is tangential to how the executable should be called. Yes, the 
qemuwrapper is allowed to fail, that why it's a warning and not a hard 
failure. When building target images, the fallback to this failure is 
deferring the script to first boot. For SDKs we currently do nothing, 
which means package installation isn't really completed. If SDKs aren't 
able to function properly because of this, we can implement a similar 
deferral of some kind to the environment where those binaries can be 
executed natively without emulation.


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


Re: [OE-core] [PATCH] qemu_2.11.1.bb: support mingw build

2018-04-13 Thread Alistair Francis
On Fri, Apr 13, 2018 at 11:11 AM, Juro Bystricky
 wrote:
> The patch chardev-connect-socket-to-a-spawned-command.patch calls
> "socketpair". This function is missing in mingw, so the patch
> needs to be modified accordingly (by conditional compilation using
> _WIN32 macro where appropriate), otherwise we end up with a broken
> mingw build.
>
> While it is possible to simply remove the whole patch for mingw build
> (via a .bbappend file in meta-mingw), it makes more sense to modify
> the patch itself.
>
> Signed-off-by: Juro Bystricky 

Acked-by: Alistair Francis 

Alistair

> ---
>  ...ardev-connect-socket-to-a-spawned-command.patch | 46 
> +++---
>  1 file changed, 31 insertions(+), 15 deletions(-)
>
> diff --git 
> a/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch
>  
> b/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch
> index 32809d3..6e6bf95 100644
> --- 
> a/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch
> +++ 
> b/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch
> @@ -54,10 +54,11 @@ diff --git a/chardev/char-socket.c b/chardev/char-socket.c
>  index 53eda8ef00..f566107c35 100644
>  --- a/chardev/char-socket.c
>  +++ b/chardev/char-socket.c
> -@@ -852,6 +852,66 @@ static gboolean socket_reconnect_timeout(gpointer 
> opaque)
> +@@ -852,6 +852,68 @@ static gboolean socket_reconnect_timeout(gpointer 
> opaque)
>   return false;
>   }
>
> ++#ifndef _WIN32
>  +static void chardev_open_socket_cmd(Chardev *chr,
>  +const char *cmd,
>  +Error **errp)
> @@ -117,42 +118,49 @@ index 53eda8ef00..f566107c35 100644
>  +object_unref(OBJECT(sioc));
>  +}
>  +}
> ++#endif
>  +
>   static void qmp_chardev_open_socket(Chardev *chr,
>   ChardevBackend *backend,
>   bool *be_opened,
> -@@ -859,6 +919,7 @@ static void qmp_chardev_open_socket(Chardev *chr,
> +@@ -859,6 +921,9 @@
>   {
>   SocketChardev *s = SOCKET_CHARDEV(chr);
>   ChardevSocket *sock = backend->u.socket.data;
> ++#ifndef _WIN32
>  +const char *cmd = sock->cmd;
> ++#endif
>   bool do_nodelay = sock->has_nodelay ? sock->nodelay : false;
>   bool is_listen  = sock->has_server  ? sock->server  : true;
>   bool is_telnet  = sock->has_telnet  ? sock->telnet  : false;
> -@@ -926,7 +987,12 @@ static void qmp_chardev_open_socket(Chardev *chr,
> +@@ -925,7 +990,14 @@
> + } else if (reconnect > 0) {
>   s->reconnect_time = reconnect;
>   }
> -
> --if (s->reconnect_time) {
> +-
> ++#ifndef _WIN32
>  +if (cmd) {
>  +chardev_open_socket_cmd(chr, cmd, errp);
>  +
>  +/* everything ready (or failed permanently) before we return */
>  +*be_opened = true;
> -+} else if (s->reconnect_time) {
> ++} else
> ++#endif
> + if (s->reconnect_time) {
>   sioc = qio_channel_socket_new();
>   tcp_chr_set_client_ioc_name(chr, sioc);
> - qio_channel_socket_connect_async(sioc, s->addr,
> -@@ -985,11 +1051,22 @@ static void qemu_chr_parse_socket(QemuOpts *opts, 
> ChardevBackend *backend,
> +@@ -985,10 +1057,26 @@
>   const char *host = qemu_opt_get(opts, "host");
>   const char *port = qemu_opt_get(opts, "port");
>   const char *tls_creds = qemu_opt_get(opts, "tls-creds");
> ++#ifndef _WIN32
>  +const char *cmd = qemu_opt_get(opts, "cmd");
> ++#endif
>   SocketAddressLegacy *addr;
>   ChardevSocket *sock;
>
>   backend->type = CHARDEV_BACKEND_KIND_SOCKET;
> --if (!path) {
> ++#ifndef _WIN32
>  +if (cmd) {
>  +/*
>  + * Here we have to ensure that no options are set which are 
> incompatible with
> @@ -163,24 +171,33 @@ index 53eda8ef00..f566107c35 100644
>  +error_setg(errp, "chardev: socket: cmd does not support any 
> additional options");
>  +return;
>  +}
> -+} else if (!path) {
> ++} else
> ++#endif
> + if (!path) {
>   if (!host) {
>   error_setg(errp, "chardev: socket: no host given");
> - return;
> -@@ -1021,13 +1098,14 @@ static void qemu_chr_parse_socket(QemuOpts *opts, 
> ChardevBackend *backend,
> +@@ -1021,13 +1109,24 @@
>   sock->has_reconnect = true;
>   sock->reconnect = reconnect;
>   sock->tls_creds = g_strdup(tls_creds);
> ++#ifndef _WIN32
>  +sock->cmd = g_strdup(cmd);
> ++#endif
>
>   addr = g_new0(SocketAddressLegacy, 1);
> --if (path) {
> ++#ifndef _WIN32
>  +if (path || cmd) {
> ++#else
> + if (path) {
> ++#endif
>   UnixSocketAddress *q_unix;
>   addr->type = SOCKET_ADDRESS_LEGACY_KIND_UNIX;
>   q_unix = addr->u.q_unix.data = g_new0(UnixSocketAddress, 1);
> --

[OE-core] [PATCH resend] core-image-minimal-initramfs: use initramfs-framework for initialization

2018-04-13 Thread California Sullivan
initramfs-framework is more modular and expandable. This change was
proposed in commit 28fc6ba761ed4a47efa7c43e7f7dff5e2fe72b5e
"core-image-minimal-initramfs: use initramfs-framework by default" but
reverted due to the selftests runqemu.RunqemuTests.test_boot_machine_iso
and runqemu.RunqemuTests.test_boot_deploy_hddimg failing. Since then,
the kinks have been worked out, and missing functionality that had been
missed (non-EFI installation module) has been added.

Since the PACKAGE_INSTALL variable was getting so long with all these
individual modules getting added, I also introduced a new
INITRAMFS_SCRIPTS variable to the core-image-minimal-initramfs recipe.
This variable makes the recipe look much cleaner, and also allows easier
replacement or additions to the scripts.

Fixes [YOCTO #10987].

Signed-off-by: California Sullivan 
---
Dicussion archives:
* 
http://lists.openembedded.org/pipermail/openembedded-core/2017-December/145808.html
* 
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146244.html
* 
http://lists.openembedded.org/pipermail/openembedded-core/2018-February/147077.html

 meta/recipes-core/images/core-image-minimal-initramfs.bb | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/images/core-image-minimal-initramfs.bb 
b/meta/recipes-core/images/core-image-minimal-initramfs.bb
index 5794a25952a..a9ba91bd310 100644
--- a/meta/recipes-core/images/core-image-minimal-initramfs.bb
+++ b/meta/recipes-core/images/core-image-minimal-initramfs.bb
@@ -3,7 +3,15 @@ DESCRIPTION = "Small image capable of booting a device. The 
kernel includes \
 the Minimal RAM-based Initial Root Filesystem (initramfs), which finds the \
 first 'init' program more efficiently."
 
-PACKAGE_INSTALL = "initramfs-live-boot initramfs-live-install 
initramfs-live-install-efi ${VIRTUAL-RUNTIME_base-utils} udev base-passwd 
${ROOTFS_BOOTSTRAP_INSTALL}"
+INITRAMFS_SCRIPTS ?= "\
+  initramfs-framework-base \
+  initramfs-module-setup-live \
+  initramfs-module-udev \
+  initramfs-module-install \
+  initramfs-module-install-efi \
+ "
+
+PACKAGE_INSTALL = "${INITRAMFS_SCRIPTS} ${VIRTUAL-RUNTIME_base-utils} udev 
base-passwd ${ROOTFS_BOOTSTRAP_INSTALL}"
 
 # Do not pollute the initrd image with rootfs features
 IMAGE_FEATURES = ""
-- 
2.14.3

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


Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build

2018-04-13 Thread Bystricky, Juro
Yes, I do get warnings, but in both cases (skipping the renaming and also if 
renamed  with MLPREFIX):
WARNING: core-image-minimal-1.0-r0 do_populate_sdk: The postinstall intercept 
hook 'update_gio_module_cache-nativesdk' failed, details in 
/data/master-master/poky/build-x86_64-mingw32-sdk-core-image-minimal/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_populate_sdk

So skipping the renaming will at least give me a correctly named executable in 
the package.

Are you sure the postinst-intercepts can even work with Windows .exe 
executables?
If I understand this correctly, you use a qemuwrapper attempting to run Windows 
executable, and I 
cannot imagine this would work. But maybe I am missing something here.

BTW, I cannot remedy this in the meta-mingw layer via a .bbppend, as the code 
that needs to
be modified is in do_install_append, so it is not possible (or not easy) to use 
overrides.



From: Alexander Kanavin [alexander.kana...@linux.intel.com]
Sent: Friday, April 13, 2018 12:32 PM
To: Bystricky, Juro; openembedded-core@lists.openembedded.org
Cc: richard.pur...@linuxfoundation.org; jurobystri...@hotmail.com
Subject: Re: [PATCH] glib-2.0/glib.inc: fix broken mingw build

On 04/13/2018 05:43 PM, Bystricky, Juro wrote:
>> I think the better approach is to accommodate the exe suffix when doing
>> the move:
>
>> mv -v ${D}${libexecdir}/gio-querymodules${EXEEXT}
>> ${D}${libexecdir}/${MLPREFIX}gio-querymodules${EXEEXT}
>
> This was actually the first thing I tried. However, I ended up with 
> "nativesdk-gio-querymodules.exe"
> in the mingw tarrball (in my case 
> poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-2.4+snapshot.tar.xz).
> I am not sure what you expect postinst to do for Windows toolchains/SDKs, but 
> I would expect
> "gio-querymodules.exe", as it used to be until recently.

"nativesdk-gio-querymodules.exe" is totally fine. This utility is used
in only one place:
poky/scripts/postinst-intercepts/update_gio_module_cache, to generate
the cache file of gio modules whenever the gio modules are installed or
removed.

That script is called by postinst_intercept mechanism, which is
triggered via meta/classes/gio-module-cache.bbclass every time a package
that inherits that class is installed.

I am fairly sure that with the patch you sent it is not going to work
for the nativesdk mingw case, as the script does prepend the MLPREFIX to
the utility name (to call the correct version among many when multilib
is in use). We would probably need to append the .exe suffix in there as
well though.

Please do try populate_sdk with nativesdk-glib-2.0 included into it and
watch for any warnings about failed postinst_intercepts.

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


Re: [OE-core] kernel menuconfig broken?

2018-04-13 Thread Bruce Ashfield

On 2018-04-12 5:38 PM, Cal Sullivan wrote:
If you're using a non-linux-yocto kernel you likely need to apply this 
patch to your kernel as well:


https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/recipes-kernel/linux/linux-intel/0001-menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch 



(This is in all linux-yocto kernels, I'm only linking to meta-intel 
because I knew where it was off the top of my head)


This was sent upstream but last I looked it didn't gain any traction. I 
think Bruce resent it recently but I can't be sure.


Yes, and I'm sending it yet again! :D

Bruce



Thanks,
Cal

On 04/12/2018 01:28 PM, Andreas Müller wrote:
On Mon, Apr 2, 2018 at 11:57 PM, Trevor Woerner  
wrote:

On Sun 2018-04-01 @ 11:49:58 PM, Andreas Müller wrote:

When running bitbake -cmenuconfig virtual/kernel I get a flood of
undefined reference errors. Am I alone here?

Sadly, I think you might be.

 $ bitbake virtual/kernel -c menuconfig

works fine for me.

I assume you're doing this for something RaspberryPi-ish?

 Build Configuration:
 BB_VERSION   = "1.37.0"
 BUILD_SYS    = "x86_64-linux"
 NATIVELSBSTRING  = "opensuse-42.3"
 TARGET_SYS   = "arm-oe-linux-gnueabi"
 MACHINE  = "raspberrypi3"
 DISTRO   = "nodistro"
 DISTRO_VERSION   = "nodistro.0"
 TUNE_FEATURES    = "arm armv7ve vfp thumb neon vfpv4 
callconvention-hard cortexa7"

 TARGET_FPU   = "hard"
 meta-raspberrypi = 
"master:63e53f919089027259a513dc2cd4b140789bf1a3"
 meta = 
"master:4cedddb83623c79980b354642dfeaf78218ca4b7"

 meta-oe
 meta-gnome
 meta-python
 meta-networking
 meta-multimedia  = 
"master:b9d1d8718834f7287e5a65373b952cbfe9ce83fe"
 meta-qt5 = 
"master:e60e849de1158c879bd2c150fe79b207cdac031a"
 meta-qt5-extra   = 
"master:a0cf057b2f335e8d2be9180f20770773334ec209"
 meta-realtime    = 
"master:250bc6eaa47e550c1db5e2b0ebd42d86ee43650e"
 meta-browser = 
"master:d1c902440cba26a9d1271cfb914633c68ee3791c"

OK I found that I am not alone [1] and followed the suggestion to
install ncurses-devel. Strange: it install ncurses-libs x86_64. Now I
have back menuconfig but it looks horrible: All framing chars are
displayed as '@'. If I remember correct there was such an issue long
lime ago.

However it is not beautiful but I can work with it.

[1] https://github.com/crops/poky-container/issues/17

Andreas




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


Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build

2018-04-13 Thread Alexander Kanavin

On 04/13/2018 05:43 PM, Bystricky, Juro wrote:

I think the better approach is to accommodate the exe suffix when doing
the move:



mv -v ${D}${libexecdir}/gio-querymodules${EXEEXT}
${D}${libexecdir}/${MLPREFIX}gio-querymodules${EXEEXT}


This was actually the first thing I tried. However, I ended up with 
"nativesdk-gio-querymodules.exe"
in the mingw tarrball (in my case 
poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-2.4+snapshot.tar.xz).
I am not sure what you expect postinst to do for Windows toolchains/SDKs, but I 
would expect
"gio-querymodules.exe", as it used to be until recently.


"nativesdk-gio-querymodules.exe" is totally fine. This utility is used 
in only one place:
poky/scripts/postinst-intercepts/update_gio_module_cache, to generate 
the cache file of gio modules whenever the gio modules are installed or 
removed.


That script is called by postinst_intercept mechanism, which is 
triggered via meta/classes/gio-module-cache.bbclass every time a package 
that inherits that class is installed.


I am fairly sure that with the patch you sent it is not going to work 
for the nativesdk mingw case, as the script does prepend the MLPREFIX to 
the utility name (to call the correct version among many when multilib 
is in use). We would probably need to append the .exe suffix in there as 
well though.


Please do try populate_sdk with nativesdk-glib-2.0 included into it and 
watch for any warnings about failed postinst_intercepts.


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


[OE-core] [PATCH] qemu_2.11.1.bb: support mingw build

2018-04-13 Thread Juro Bystricky
The patch chardev-connect-socket-to-a-spawned-command.patch calls
"socketpair". This function is missing in mingw, so the patch
needs to be modified accordingly (by conditional compilation using
_WIN32 macro where appropriate), otherwise we end up with a broken
mingw build.

While it is possible to simply remove the whole patch for mingw build
(via a .bbappend file in meta-mingw), it makes more sense to modify
the patch itself.

Signed-off-by: Juro Bystricky 
---
 ...ardev-connect-socket-to-a-spawned-command.patch | 46 +++---
 1 file changed, 31 insertions(+), 15 deletions(-)

diff --git 
a/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch
 
b/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch
index 32809d3..6e6bf95 100644
--- 
a/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch
+++ 
b/meta/recipes-devtools/qemu/qemu/chardev-connect-socket-to-a-spawned-command.patch
@@ -54,10 +54,11 @@ diff --git a/chardev/char-socket.c b/chardev/char-socket.c
 index 53eda8ef00..f566107c35 100644
 --- a/chardev/char-socket.c
 +++ b/chardev/char-socket.c
-@@ -852,6 +852,66 @@ static gboolean socket_reconnect_timeout(gpointer opaque)
+@@ -852,6 +852,68 @@ static gboolean socket_reconnect_timeout(gpointer opaque)
  return false;
  }
  
++#ifndef _WIN32
 +static void chardev_open_socket_cmd(Chardev *chr,
 +const char *cmd,
 +Error **errp)
@@ -117,42 +118,49 @@ index 53eda8ef00..f566107c35 100644
 +object_unref(OBJECT(sioc));
 +}
 +}
++#endif
 +
  static void qmp_chardev_open_socket(Chardev *chr,
  ChardevBackend *backend,
  bool *be_opened,
-@@ -859,6 +919,7 @@ static void qmp_chardev_open_socket(Chardev *chr,
+@@ -859,6 +921,9 @@
  {
  SocketChardev *s = SOCKET_CHARDEV(chr);
  ChardevSocket *sock = backend->u.socket.data;
++#ifndef _WIN32
 +const char *cmd = sock->cmd;
++#endif
  bool do_nodelay = sock->has_nodelay ? sock->nodelay : false;
  bool is_listen  = sock->has_server  ? sock->server  : true;
  bool is_telnet  = sock->has_telnet  ? sock->telnet  : false;
-@@ -926,7 +987,12 @@ static void qmp_chardev_open_socket(Chardev *chr,
+@@ -925,7 +990,14 @@
+ } else if (reconnect > 0) {
  s->reconnect_time = reconnect;
  }
- 
--if (s->reconnect_time) {
+-
++#ifndef _WIN32
 +if (cmd) {
 +chardev_open_socket_cmd(chr, cmd, errp);
 +
 +/* everything ready (or failed permanently) before we return */
 +*be_opened = true;
-+} else if (s->reconnect_time) {
++} else
++#endif
+ if (s->reconnect_time) {
  sioc = qio_channel_socket_new();
  tcp_chr_set_client_ioc_name(chr, sioc);
- qio_channel_socket_connect_async(sioc, s->addr,
-@@ -985,11 +1051,22 @@ static void qemu_chr_parse_socket(QemuOpts *opts, 
ChardevBackend *backend,
+@@ -985,10 +1057,26 @@
  const char *host = qemu_opt_get(opts, "host");
  const char *port = qemu_opt_get(opts, "port");
  const char *tls_creds = qemu_opt_get(opts, "tls-creds");
++#ifndef _WIN32
 +const char *cmd = qemu_opt_get(opts, "cmd");
++#endif
  SocketAddressLegacy *addr;
  ChardevSocket *sock;
  
  backend->type = CHARDEV_BACKEND_KIND_SOCKET;
--if (!path) {
++#ifndef _WIN32
 +if (cmd) {
 +/*
 + * Here we have to ensure that no options are set which are 
incompatible with
@@ -163,24 +171,33 @@ index 53eda8ef00..f566107c35 100644
 +error_setg(errp, "chardev: socket: cmd does not support any 
additional options");
 +return;
 +}
-+} else if (!path) {
++} else
++#endif
+ if (!path) {
  if (!host) {
  error_setg(errp, "chardev: socket: no host given");
- return;
-@@ -1021,13 +1098,14 @@ static void qemu_chr_parse_socket(QemuOpts *opts, 
ChardevBackend *backend,
+@@ -1021,13 +1109,24 @@
  sock->has_reconnect = true;
  sock->reconnect = reconnect;
  sock->tls_creds = g_strdup(tls_creds);
++#ifndef _WIN32
 +sock->cmd = g_strdup(cmd);
++#endif
  
  addr = g_new0(SocketAddressLegacy, 1);
--if (path) {
++#ifndef _WIN32
 +if (path || cmd) {
++#else
+ if (path) {
++#endif
  UnixSocketAddress *q_unix;
  addr->type = SOCKET_ADDRESS_LEGACY_KIND_UNIX;
  q_unix = addr->u.q_unix.data = g_new0(UnixSocketAddress, 1);
--q_unix->path = g_strdup(path);
++#ifndef _WIN32
 +q_unix->path = cmd ? g_strdup_printf("cmd:%s", cmd) : g_strdup(path);
++#else
+ q_unix->path = g_strdup(path);
++#endif
  } else {
  addr->type = SOCKET_ADDRESS_LEGACY_KIND_INET;
  addr->u.inet.data = g_new(InetSocketAddress, 1);
@@ -223,4 +240,3 @@ index ae19dcd1ed..6de0f29bcd 100644
   

Re: [OE-core] [PATCH] musl: Upgrade to latest

2018-04-13 Thread Khem Raj
usual master stuff

On Fri, Apr 13, 2018 at 9:18 AM, Burton, Ross  wrote:
> Is this a freeze break request for Sumo or an early submission for master?
>
> Ross
>
> On 13 April 2018 at 17:09, Khem Raj  wrote:
>> Changes are here
>>
>> https://git.musl-libc.org/cgit/musl/log/?qt=range=55df09bfccbfe21fc9dd7d8f94550c0ff25ace04..ae2a01da2e388535da243b3d974aef74a3c06ae0
>>
>> Signed-off-by: Khem Raj 
>> ---
>>  meta/recipes-core/musl/musl_git.bb | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-core/musl/musl_git.bb 
>> b/meta/recipes-core/musl/musl_git.bb
>> index 9f8c5126e8..42ba411f17 100644
>> --- a/meta/recipes-core/musl/musl_git.bb
>> +++ b/meta/recipes-core/musl/musl_git.bb
>> @@ -3,7 +3,7 @@
>>
>>  require musl.inc
>>
>> -SRCREV = "55df09bfccbfe21fc9dd7d8f94550c0ff25ace04"
>> +SRCREV = "ae2a01da2e388535da243b3d974aef74a3c06ae0"
>>
>>  PV = "1.1.19+git${SRCPV}"
>>
>> --
>> 2.17.0
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] musl: Upgrade to latest

2018-04-13 Thread Burton, Ross
Is this a freeze break request for Sumo or an early submission for master?

Ross

On 13 April 2018 at 17:09, Khem Raj  wrote:
> Changes are here
>
> https://git.musl-libc.org/cgit/musl/log/?qt=range=55df09bfccbfe21fc9dd7d8f94550c0ff25ace04..ae2a01da2e388535da243b3d974aef74a3c06ae0
>
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-core/musl/musl_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/musl/musl_git.bb 
> b/meta/recipes-core/musl/musl_git.bb
> index 9f8c5126e8..42ba411f17 100644
> --- a/meta/recipes-core/musl/musl_git.bb
> +++ b/meta/recipes-core/musl/musl_git.bb
> @@ -3,7 +3,7 @@
>
>  require musl.inc
>
> -SRCREV = "55df09bfccbfe21fc9dd7d8f94550c0ff25ace04"
> +SRCREV = "ae2a01da2e388535da243b3d974aef74a3c06ae0"
>
>  PV = "1.1.19+git${SRCPV}"
>
> --
> 2.17.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] bitbake.conf: Set and export TZ envvar to UTC

2018-04-13 Thread Richard Purdie
We just ran into an issue where tar failed to build on one server setup
but built everywhere else just fine.

It was running makeinfo to regenerate some docs files and makeinfo was too
old for the host it was running on. There was no dependency on makeinfo-native
as it was not meant to be regenerating the docs.

It was being regenerated as a date from a timestamp used in the docs
was different in Asian timezones than in the other timezones our builds
were being tested in.

I added an entry to https://wiki.yoctoproject.org/wiki/TipsAndTricks/
about how this was debugged.

As such, lets default to setting and exporting TZ to 'UTC' as was already
pioneered by the reproducibile builds work. This makes the builds
deterministic.

[YOCTO #12665]

Signed-off-by: Richard Purdie 
---
 meta/classes/reproducible_build_simple.bbclass | 1 -
 meta/conf/bitbake.conf | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/reproducible_build_simple.bbclass 
b/meta/classes/reproducible_build_simple.bbclass
index dd11cd9..8a60dee 100644
--- a/meta/classes/reproducible_build_simple.bbclass
+++ b/meta/classes/reproducible_build_simple.bbclass
@@ -4,7 +4,6 @@ BUILD_REPRODUCIBLE_BINARIES = "1"
 
 export PYTHONHASHSEED = "0"
 export PERL_HASH_SEED = "0"
-export TZ = 'UTC'
 export SOURCE_DATE_EPOCH ??= "1520598896"
 
 REPRODUCIBLE_TIMESTAMP_ROOTFS ??= "1520598896"
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 60590e2..ec3207c 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -539,6 +539,7 @@ export MAKE = "make"
 EXTRA_OEMAKE = ""
 EXTRA_OECONF = ""
 export LC_ALL = "en_US.UTF-8"
+export TZ = 'UTC'
 
 ##
 # Patch handling.
-- 
2.7.4

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


[OE-core] [PATCH] musl: Upgrade to latest

2018-04-13 Thread Khem Raj
Changes are here

https://git.musl-libc.org/cgit/musl/log/?qt=range=55df09bfccbfe21fc9dd7d8f94550c0ff25ace04..ae2a01da2e388535da243b3d974aef74a3c06ae0

Signed-off-by: Khem Raj 
---
 meta/recipes-core/musl/musl_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/musl/musl_git.bb 
b/meta/recipes-core/musl/musl_git.bb
index 9f8c5126e8..42ba411f17 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -3,7 +3,7 @@
 
 require musl.inc
 
-SRCREV = "55df09bfccbfe21fc9dd7d8f94550c0ff25ace04"
+SRCREV = "ae2a01da2e388535da243b3d974aef74a3c06ae0"
 
 PV = "1.1.19+git${SRCPV}"
 
-- 
2.17.0

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


[OE-core] [PATCH] yocto-uninative: Update to version 1.9 (fedora28 compatible)

2018-04-13 Thread Richard Purdie
This includes the libxcrypt change which allows uninative to work on fedora28.

Signed-off-by: Richard Purdie 
---
 meta/conf/distro/include/yocto-uninative.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/conf/distro/include/yocto-uninative.inc 
b/meta/conf/distro/include/yocto-uninative.inc
index cd5fc0b..a8e82cb 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -8,6 +8,6 @@
 
 UNINATIVE_MAXGLIBCVERSION = "2.27"
 
-UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/1.8/;
-UNINATIVE_CHECKSUM[i686] ?= 
"427ce522ec97f65c75fd89587d90ef789e8cbca4a617abc4b5822abb01c2d0ae"
-UNINATIVE_CHECKSUM[x86_64] ?= 
"de4947e98e09e1432d069311cc2093974ecb9138a714fd5466f73524de66a693"
+UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/1.9/;
+UNINATIVE_CHECKSUM[i686] ?= 
"83a4f927da81d9889ef0cbe5c12cb782e21c6cc11e6155600b94ff0c99576dce"
+UNINATIVE_CHECKSUM[x86_64] ?= 
"c26622a1f27dbf5b25de986b11584b5c5b2f322d9eb367f705a744f58a5561ec"
-- 
2.7.4

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


Re: [OE-core] [PATCH v2] udev-extraconf: Add systemd-mount to udev-extraconf/mount.sh

2018-04-13 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Hongzhi.Song
> Sent: den 12 april 2018 05:38
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH v2] udev-extraconf: Add systemd-mount to
> udev-extraconf/mount.sh
> 
> This patch fixs the problem that block devices unable to be formatted
> when
> systemd and udev-extraconf recipes added to rootfs.
> 
> If we add systemd and udev-extraconf recipes to rootfs:
> VIRTUAL-RUNTIME_init_manager = "systemd"
> DISTRO_FEATURES_append = " systemd"
> DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
> KERNEL_FEATURES_append = " cfg/systemd.scc"
> IMAGE_INSTALL_append = " udev-extraconf"
> IMAGE_FSTYPES += "tar.bz2 ext4"
> IMAGE_INSTALL_append = " e2fsprogs-mke2fs"
> then systemd-udevd.service will invoke udev rules to automount block
> devices
> any probed under udevd's private namespace, this behavior results in
> host space
> can't format those devices. And host space can't find where the device
> is used.
> 
> Such as:
> root@qemux86:~# mkfs.ext4 /dev/sda1
> mke2fs 1.43.8 (1-Jan-2018)
> /dev/sda1 contains a ext4 file system
> last mounted on Tue Apr  3 06:22:41 2018
> Proceed anyway? (y,N) y
> /dev/sda1 is apparently in use by the system; will not make a
> filesystem here!
> 
> Command 'systemd-mount' recommended by systemd maintainer instead of
> command
> 'mount' will fix the problem brought with private namespace. Systemd-
> mount
> request the mount operation to be executed by PID 1, and hence host
> space can
> access the block devices.
> 
> [YOCTO #12644]
> 
> Signed-off-by: Hongzhi.Song 
> ---
>  meta/recipes-core/udev/udev-extraconf/mount.sh | 71
> ++
>  1 file changed, 60 insertions(+), 11 deletions(-)
> 
> diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh
> b/meta/recipes-core/udev/udev-extraconf/mount.sh
> index d760328a09..4ba9f1dd99 100644
> --- a/meta/recipes-core/udev/udev-extraconf/mount.sh
> +++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
> @@ -4,10 +4,28 @@
>  #
>  # Attempt to mount any added block devices and umount any removed
> devices
> 
> +BASE_INIT="`readlink "/sbin/init"`"
> +INIT_SYSTEMD="/lib/systemd/systemd"

In a system where ${base_libdir} != "lib", e.g, if usrmerge is in 
DISTRO_FEATURES, this may not match reality. You should replace 
all hardcoded paths with something like @base_libdir@ and then 
use sed to apply all the relevant bitbake path variables.

> +
> +if [ "x$BASE_INIT" = "x$INIT_SYSTEMD" ];then
> + # systemd as init uses systemd-mount to mount block devices

You should use tabs to indent this function to match the rest of 
this file.

> +MOUNT="/usr/bin/systemd-mount"
> +UMOUNT="/usr/bin/systemd-umount"
> +
> +if [ -x $MOUNT ] && [ -x $UMOUNT ];
> +then
> +logger "Using systemd-mount to finish mount"
> +else
> +logger "Linux init is using systemd, so please install systemd-mount 
> to finish mount"
> +exit 1
> +fi
> +else
> +MOUNT="/bin/mount"
> +UMOUNT="/bin/umount"
> +fi
> 
> -MOUNT="/bin/mount"
>  PMOUNT="/usr/bin/pmount"
> -UMOUNT="/bin/umount"
> +
>  for line in `grep -h -v ^# /etc/udev/mount.blacklist 
> /etc/udev/mount.blacklist.d/*`
>  do
>   if [ ` expr match "$DEVNAME" "$line" ` -gt 0 ];
> @@ -17,7 +35,35 @@ do
>   fi
>  done
> 
> -automount() {
> +automount_systemd() {
> +name="`basename "$DEVNAME"`"
> +
> +! test -d "/run/media/$name" && mkdir -p "/run/media/$name"

The above is better written as:

[ -d "/run/media/$name" ] || mkdir -p "/run/media/$name"

> +
> +MOUNT="$MOUNT -o silent"
> +
> +# If filesystemtype is vfat, change the ownership group to 'disk', and
> +# grant it with  w/r/x permissions.
> +case $ID_FS_TYPE in
> +vfat|fat)
> +MOUNT="$MOUNT -o umask=007,gid=`awk -F':' '/^disk/{print $3}' 
> /etc/group`"
> +;;
> +# TODO
> +*)
> +;;
> +esac
> +
> +if ! $MOUNT --no-block -t auto $DEVNAME "/run/media/$name"
> +then
> +#logger "mount.sh/automount" "$MOUNT -t auto $DEVNAME 
> \"/run/media/$name\" failed!"
> +rm_dir "/run/media/$name"
> +else
> +logger "mount.sh/automount" "Auto-mount of [/run/media/$name] 
> successful"
> +touch "/tmp/.automount-$name"
> +fi
> +}
> +
> +automount() {
>   name="`basename "$DEVNAME"`"
> 
>   ! test -d "/run/media/$name" && mkdir -p "/run/media/$name"
> @@ -26,7 +72,7 @@ automount() {
>   then
>   MOUNT="$MOUNT -o silent"
>   fi
> -
> +
>   # If filesystem type is vfat, change the ownership group to 'disk', and
>   # grant it with  w/r/x permissions.
>   case $ID_FS_TYPE in
> @@ -46,7 +92,7 @@ automount() {
>   logger "mount.sh/automount" "Auto-mount of [/run/media/$name] 
> successful"
>

Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build

2018-04-13 Thread Bystricky, Juro

> I think the better approach is to accommodate the exe suffix when doing
> the move:

> mv -v ${D}${libexecdir}/gio-querymodules${EXEEXT}
> ${D}${libexecdir}/${MLPREFIX}gio-querymodules${EXEEXT}

This was actually the first thing I tried. However, I ended up with 
"nativesdk-gio-querymodules.exe"
in the mingw tarrball (in my case 
poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-2.4+snapshot.tar.xz).
I am not sure what you expect postinst to do for Windows toolchains/SDKs, but I 
would expect 
"gio-querymodules.exe", as it used to be until recently.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] systemtap: don't build under musl

2018-04-13 Thread Ross Burton
systemtap uses obstack.h and FTW_SKIP_SUBTREE, both of which are GNU extensions
in glibc.

Signed-off-by: Ross Burton 
---
 meta/recipes-kernel/systemtap/systemtap_git.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc 
b/meta/recipes-kernel/systemtap/systemtap_git.inc
index e1b7789aedc..e2f5204a020 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.inc
+++ b/meta/recipes-kernel/systemtap/systemtap_git.inc
@@ -26,6 +26,7 @@ SRC_URI = "git://sourceware.org/git/systemtap.git \
"
 
 COMPATIBLE_HOST = '(x86_64|i.86|powerpc|arm|aarch64|microblazeel|mips).*-linux'
+COMPATIBLE_HOST_libc-musl = 'null'
 
 S = "${WORKDIR}/git"
 
-- 
2.11.0

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


[OE-core] [PATCH] packagegroup-core-tools-profile: include systemtap on MIPS and aarch64

2018-04-13 Thread Ross Burton
Modern systemtap builds fine for MIPS and aarch64, so don't exclude it from this
packagegroup.

Signed-off-by: Ross Burton 
---
 meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
index 554f5298890..fa0e363d863 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
@@ -33,9 +33,7 @@ PERF_libc-musl = ""
 # systemtap needs elfutils which is not fully buildable on some arches/libcs
 SYSTEMTAP = "systemtap"
 SYSTEMTAP_libc-musl = ""
-SYSTEMTAP_mipsarch = ""
 SYSTEMTAP_nios2 = ""
-SYSTEMTAP_aarch64 = ""
 
 # lttng-ust uses sched_getcpu() which is not there on for some platforms.
 LTTNGUST = "lttng-ust"
-- 
2.11.0

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


[OE-core] [PATCH] bitbake.conf: add scp to HOSTTOOLS_NONFATAL

2018-04-13 Thread Jef Driesen
The scp tool is used by the ssh fetcher.

Signed-off-by: Jef Driesen 
---
 meta/conf/bitbake.conf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 60590e2..5cfd117 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -498,6 +498,9 @@ HOSTTOOLS_NONFATAL += "join nl size yes zcat"
 # Used by bzr fetcher
 HOSTTOOLS_NONFATAL += "bzr"
 
+# Used by ssh fetcher
+HOSTTOOLS_NONFATAL += "scp"
+
 CCACHE ??= ""
 # ccache < 3.1.10 will create CCACHE_DIR on startup even if disabled, and
 # autogen sets HOME=/dev/null so in certain situations builds can fail.
-- 
2.7.4

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


Re: [OE-core] [PATCH v2] oeqa/runtime/stap.py: add runtime test for systemtap

2018-04-13 Thread Burton, Ross
On 3 April 2018 at 16:25, Victor Kamensky  wrote:
> +@OETestID(1652)
> +@skipIfNotFeature('tools-profile',
> +  'Test requires tools-profile to be in IMAGE_FEATURES')
> +@OETestDepends(['kernelmodule.KernelModuleTest.test_kernel_module'])
> +def test_stap(self):

Instead of skipIfNotFeature use OETestDepends(systemtap), as platforms
which don't support systemtap can still have tools-profile enabled
(such as musl systems).

Then please add stap to the default cases in testimage.bbclass for the
sdk images.

Also shouldn't the test be looking at the output to check that 'hello
world' was displayed?  Otherwise stap might have done exit(0) but the
script didn't actually run.

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


Re: [OE-core] [PATCH] image_types: use pigz to create .gz files

2018-04-13 Thread Richard Purdie
On Wed, 2018-04-11 at 14:36 +0100, Burton, Ross wrote:
> Wouldn't that introduce a fun circular dependency if pigz-native
> needs
> to be built?

For the sstate code we could probably make it use pigz if present. 

We could also only depend on pigz-native for target, or encode the
actual pigz-native dependencies.

So there may be a few options if its worth the performance win.

Cheers,

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


Re: [OE-core] [PATCH v5 1/2] image.bbclass: add prohibited-paths QA test

2018-04-13 Thread Otavio Salvador
On Fri, Apr 13, 2018 at 6:27 AM, Fabien Lahoudere
 wrote:
> This patch doesn't seem to be applied.
> Is there additional comments or something blocking?

I see no reason for it not being applied.

-- 
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 0/1] man-db: add groff to RDEPENDS

2018-04-13 Thread Chen Qi
The following changes since commit 8dbf71b553b3fb3063ab5f61bb3454a6ab8e6c08:

  bitbake: bitbake-user-manual: Updated "Task Checksums and Setscene" section 
(2018-04-12 22:25:17 +0100)

are available in the git repository at:

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

Chen Qi (1):
  man-db: add groff to RDEPENDS

 meta/recipes-extended/man-db/man-db_2.8.1.bb | 1 +
 1 file changed, 1 insertion(+)

-- 
1.9.1

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


[OE-core] [PATCH 1/1] man-db: add groff to RDEPENDS

2018-04-13 Thread Chen Qi
Add groff to RDEPENDS_${PN}, otherwise, the 'man' command cannot
work correctly on target.

Signed-off-by: Chen Qi 
---
 meta/recipes-extended/man-db/man-db_2.8.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-extended/man-db/man-db_2.8.1.bb 
b/meta/recipes-extended/man-db/man-db_2.8.1.bb
index 528903d..8328a67 100644
--- a/meta/recipes-extended/man-db/man-db_2.8.1.bb
+++ b/meta/recipes-extended/man-db/man-db_2.8.1.bb
@@ -25,6 +25,7 @@ FILES_${PN} += "${prefix}/lib/tmpfiles.d"
 
 FILES_${PN}-dev += "${libdir}/man-db/libman.so ${libdir}/${BPN}/libmandb.so"
 
+RDEPENDS_${PN} += "groff"
 RRECOMMENDS_${PN} += "less"
 RPROVIDES_${PN} += " man"
 
-- 
1.9.1

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


Re: [OE-core] [PATCH v5 1/2] image.bbclass: add prohibited-paths QA test

2018-04-13 Thread Fabien Lahoudere
Hi 

This patch doesn't seem to be applied.
Is there additional comments or something blocking?

Thanks

Fabien

On Mon, 2017-11-27 at 19:28 +, Martyn Welch wrote:
> Sometimes we wish to ensure that files or directories are not installed
> somewhere that may prove detrimental to the operation of the system. For
> example, this may be the case if files are placed in a directory that is
> utilised as a mount point at run time, thus making them inaccessible once
> when the mount point is being utilised.
> 
> Implement the prohibited paths QA test, which enables such locations to be
> specified in a "IMAGE_QA_PROHIBITED_PATHS" variable. This implementation
> allows for a colon separated list of paths to be provided. Shell style
> wildcards can be used.
> 
> Signed-off-by: Fabien Lahoudere 
> Signed-off-by: Martyn Welch 
> ---
> Changes since v1:
>  - Correcting author and SOB.
> 
> Changes since v2:
>  - Reimplemented as image rather than package level QA test.
>  - Changed variable from PROHIBITED_PATH to PROHIBITED_PATHS to better
>    reflect its use.
> 
> Changes since v3:
>  - Rename variable to IMAGE_QA_PROHIBITED_PATHS.
>  - Use str.startswith().
>  - Simplify if statement.
> 
> Changes since v4:
>  - Move QA test to new class "image-insane.bbclass".
> 
>  meta/classes/image-insane.bbclass | 20 
>  meta/classes/image.bbclass|  1 +
>  2 files changed, 21 insertions(+)
>  create mode 100644 meta/classes/image-insane.bbclass
> 
> diff --git a/meta/classes/image-insane.bbclass 
> b/meta/classes/image-insane.bbclass
> new file mode 100644
> index 000..29935cf
> --- /dev/null
> +++ b/meta/classes/image-insane.bbclass
> @@ -0,0 +1,20 @@
> +python image_check_prohibited_paths () {
> +import glob
> +from oe.utils import ImageQAFailed
> +
> +rootfs = d.getVar('IMAGE_ROOTFS')
> +
> +path = (d.getVar('IMAGE_QA_PROHIBITED_PATHS') or "")
> +if path != "":
> +for p in path.split(':'):
> +if not p.startswith('/'):
> +raise ImageQAFailed("IMAGE_QA_PROHIBITED_PATHS \"%s\" must 
> be an absolute path" %
> p, image_check_prohibited_paths)
> +
> +match = glob.glob("%s%s" % (rootfs, p))
> +if match:
> +loc = ", ".join(item.replace(rootfs, '') for item in match)
> +raise ImageQAFailed("Match(es) for IMAGE_QA_PROHIBITED_PATHS 
> \"%s\": %s" % (p,
> loc), image_check_prohibited_paths)
> +}
> +
> +IMAGE_QA_COMMANDS += "image_check_prohibited_paths"
> +
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index d93de02..8b45abb 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -1,4 +1,5 @@
>  inherit rootfs_${IMAGE_PKGTYPE}
> +inherit image-insane
>  
>  # Only Linux SDKs support populate_sdk_ext, fall back to populate_sdk_base
>  # in the non-Linux SDK_OS case, such as mingw32
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build

2018-04-13 Thread Alexander Kanavin

On 04/13/2018 01:28 AM, Juro Bystricky wrote:

mingw build was broken by the commit:
"glib-2.0/glib.inc: apply MLPREFIX renaming to all package classes"

When building for mingw, we encounter build errors such as:

   mv: cannot stat '/<...>/usr/libexec/gio-querymodules': No such 
file or directory

The file that exists is actually "gio-querymodules.exe", but still there is no
good reason to rename it to "nativesdk-gio-querymodules.exe".
So for mingw we simply avoid renaming of the executable, by skippng the line:

   mv -v ${D}${libexecdir}/gio-querymodules 
${D}${libexecdir}/${MLPREFIX}gio-querymodules

[YOCTO #12679]


The reason for the renaming is that postinst_intercept logic will try to 
execute the binary with the mlprefix, when running populate_sdk. I think 
this is not gonna work with your patch, and the bug does not mention 
that you tried it.


I think the better approach is to accommodate the exe suffix when doing 
the move:


mv -v ${D}${libexecdir}/gio-querymodules${EXEEXT} 
${D}${libexecdir}/${MLPREFIX}gio-querymodules${EXEEXT}


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