Re: [OE-core] [PATCH 3/9] json-glib: convert to meson build

[Yi Zhao]

I also encountered this issue. For now, I found it only happened on 
ubuntu 14.04.


Looks like it invokes g-ir-scanner but not g-ir-scanner-wrapper when 
building gir.


In build.ninja:

COMMAND = 
'/buildarea/build/tmp/work/core2-64-poky-linux/json-glib/1.2.8-r0/recipe-sysroot-native/usr/bin/g-ir-scanner' 
...


On ubuntu 16.04, it uses g-ir-scanner-wrapper that could work:

COMMAND = 
/buildarea/build/tmp/work/core2-64-poky-linux/json-glib/1.2.8-r0/recipe-sysroot/usr/bin/g-ir-scanner-wrapper 
...



//Yi


在 2018年01月04日 17:27, Alexander Kanavin 写道:

On 01/04/2018 10:51 AM, ChenQi wrote:
file://0001-Do-not-disable-gobject-introspection-when-cross-comp.patch 
\

+   "


I removed this patch and the compile succeeded.
Could you please check if this patch is really needed?
If it is, I think we'd better make build to succeed by default anyway.


Yes, it is really needed. Without it, introspection files will not be 
generated at all. I'll try to reproduce the failure.


Alex


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

Re: [OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt

[Randy MacLeod]

On 2018-01-11 09:13 PM, Huang, Jie (Jackie) wrote:




-Original Message-
From: MacLeod, Randy
Sent: Friday, January 12, 2018 04:16
To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt

On 2018-01-10 10:07 PM, jackie.hu...@windriver.com wrote:

From: Jackie Huang 

'getopt' is needed by systemd-sysv-install, or it fails with:
| kdump.service is not a native service, redirecting to systemd-sysv-install.
| Executing: /lib/systemd/systemd-sysv-install enable kdump
| /lib/systemd/systemd-sysv-install: line 15: getopt: command not found

Signed-off-by: Jackie Huang 
---
   meta/recipes-core/systemd/systemd_234.bb | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_234.bb b/meta/recipes-

core/systemd/systemd_234.bb

index 4132cdf40f..5a0e4c2247 100644
--- a/meta/recipes-core/systemd/systemd_234.bb
+++ b/meta/recipes-core/systemd/systemd_234.bb
@@ -521,7 +521,7 @@ FILES_${PN} = " ${base_bindir}/* \

   FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-

1/interfaces/ ${sysconfdir}/rpm/macros.systemd"


-RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})

util-linux-agetty"

+RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})

util-linux-agetty util-linux-getopt"

It would be nice to make the dependency conditional on systemd being
configured to support sysvinit scripts.


The sysvinit script is always supported for now:

commit 9d298d1563b3fd5ad569f806cc296e13279e7cf6
Author: Khem Raj 
Date:   Sun Sep 6 15:25:41 2015 +

 systemd: Implement OE-Specific systemd-sysv-install

 Support for chkconfig (--enable-chkconfig) was removed in favour of
 calling an abstraction /lib/systemd/systemd-sysv-install. This
 needs to be implemented for OE.

 Signed-off-by: Khem Raj 
 Signed-off-by: Richard Purdie 

So I think the unconditional dependency is needed unless we change the
support for sysvinit to be optional as well.


I would like to make it configurable but you're right, it works
properly now and the commit log would tip anyone off should we
get around to making systemd's sysvinit support optional.

Thanks,

../Randy



Thanks,
Jackie


../Randy


   RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'serial-getty-

generator', '', 'systemd-serialgetty', d)}"

   RDEPENDS_${PN} += "volatile-binds update-rc.d"





--
# Randy MacLeod.  WR Linux
# Wind River an Intel Company



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

Re: [OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt

[Huang, Jie (Jackie)]

> -Original Message-
> From: MacLeod, Randy
> Sent: Friday, January 12, 2018 04:16
> To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt
> 
> On 2018-01-10 10:07 PM, jackie.hu...@windriver.com wrote:
> > From: Jackie Huang 
> >
> > 'getopt' is needed by systemd-sysv-install, or it fails with:
> > | kdump.service is not a native service, redirecting to 
> > systemd-sysv-install.
> > | Executing: /lib/systemd/systemd-sysv-install enable kdump
> > | /lib/systemd/systemd-sysv-install: line 15: getopt: command not found
> >
> > Signed-off-by: Jackie Huang 
> > ---
> >   meta/recipes-core/systemd/systemd_234.bb | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-core/systemd/systemd_234.bb b/meta/recipes-
> core/systemd/systemd_234.bb
> > index 4132cdf40f..5a0e4c2247 100644
> > --- a/meta/recipes-core/systemd/systemd_234.bb
> > +++ b/meta/recipes-core/systemd/systemd_234.bb
> > @@ -521,7 +521,7 @@ FILES_${PN} = " ${base_bindir}/* \
> >
> >   FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-
> 1/interfaces/ ${sysconfdir}/rpm/macros.systemd"
> >
> > -RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})
> util-linux-agetty"
> > +RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})
> util-linux-agetty util-linux-getopt"
> 
> It would be nice to make the dependency conditional on systemd being
> configured to support sysvinit scripts.

The sysvinit script is always supported for now:

commit 9d298d1563b3fd5ad569f806cc296e13279e7cf6
Author: Khem Raj 
Date:   Sun Sep 6 15:25:41 2015 +

systemd: Implement OE-Specific systemd-sysv-install

Support for chkconfig (--enable-chkconfig) was removed in favour of
calling an abstraction /lib/systemd/systemd-sysv-install. This
needs to be implemented for OE.

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie 

So I think the unconditional dependency is needed unless we change the
support for sysvinit to be optional as well.

Thanks,
Jackie
> 
> ../Randy
> 
> >   RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'serial-getty-
> generator', '', 'systemd-serialgetty', d)}"
> >   RDEPENDS_${PN} += "volatile-binds update-rc.d"
> >
> >
> 
> 
> --
> # Randy MacLeod.  WR Linux
> # Wind River an Intel Company
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] qemu-2.10.1.bb: support mingw build

[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, otherwise we end up with a broken
mingw build.
While it is possible to simply remove the patch on a recipe level for
mingw platform, it makes more sense to modify the patch itself.

Signed-off-by: Juro Bystricky 
---
 ...ardev-connect-socket-to-a-spawned-command.patch | 37 +-
 1 file changed, 29 insertions(+), 8 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 49d4af2..4f85397 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
@@ -55,10 +55,11 @@ diff --git a/chardev/char-socket.c b/chardev/char-socket.c
 index 1ae730a4..c366a02a 100644
 --- a/chardev/char-socket.c
 +++ b/chardev/char-socket.c
-@@ -854,6 +854,66 @@ static gboolean socket_reconnect_timeout(gpointer opaque)
+@@ -854,6 +854,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)
@@ -118,42 +119,51 @@ index 1ae730a4..c366a02a 100644
 +object_unref(OBJECT(sioc));
 +}
 +}
++#endif
 +
  static void qmp_chardev_open_socket(Chardev *chr,
  ChardevBackend *backend,
  bool *be_opened,
-@@ -861,6 +921,7 @@ static void qmp_chardev_open_socket(Chardev *chr,
+@@ -861,6 +923,9 @@ static void qmp_chardev_open_socket(Chardev *chr,
  {
  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;
-@@ -928,7 +989,12 @@ static void qmp_chardev_open_socket(Chardev *chr,
+@@ -928,7 +993,15 @@ static void qmp_chardev_open_socket(Chardev *chr,
  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,
-@@ -987,11 +1053,22 @@ static void qemu_chr_parse_socket(QemuOpts *opts, 
ChardevBackend *backend,
+@@ -987,11 +1060,27 @@ static void qemu_chr_parse_socket(QemuOpts *opts, 
ChardevBackend *backend,
  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
@@ -164,24 +174,35 @@ index 1ae730a4..c366a02a 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;
-@@ -1023,13 +1100,14 @@ static void qemu_chr_parse_socket(QemuOpts *opts, 
ChardevBackend *backend,
+@@ -1023,13 +1112,24 @@ static void qemu_chr_parse_socket(QemuOpts *opts, 
ChardevBackend *backend,
  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 = 

Re: [OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt

[Randy MacLeod]

On 2018-01-10 10:07 PM, jackie.hu...@windriver.com wrote:

From: Jackie Huang 

'getopt' is needed by systemd-sysv-install, or it fails with:
| kdump.service is not a native service, redirecting to systemd-sysv-install.
| Executing: /lib/systemd/systemd-sysv-install enable kdump
| /lib/systemd/systemd-sysv-install: line 15: getopt: command not found

Signed-off-by: Jackie Huang 
---
  meta/recipes-core/systemd/systemd_234.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_234.bb 
b/meta/recipes-core/systemd/systemd_234.bb
index 4132cdf40f..5a0e4c2247 100644
--- a/meta/recipes-core/systemd/systemd_234.bb
+++ b/meta/recipes-core/systemd/systemd_234.bb
@@ -521,7 +521,7 @@ FILES_${PN} = " ${base_bindir}/* \
  
  FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/ ${sysconfdir}/rpm/macros.systemd"
  
-RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV}) util-linux-agetty"

+RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV}) 
util-linux-agetty util-linux-getopt"


It would be nice to make the dependency conditional on systemd being 
configured to support sysvinit scripts.


../Randy


  RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'serial-getty-generator', 
'', 'systemd-serialgetty', d)}"
  RDEPENDS_${PN} += "volatile-binds update-rc.d"
  




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

Re: [OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

On 01/11/2018 11:33 AM, Martin Kelly wrote:

On 01/11/2018 11:26 AM, Khem Raj wrote:

On Thu, Jan 11, 2018 at 11:22 AM, Martin Kelly  wrote:
Khem and Alexander, could you comment on which solution is preferable 
from
an SDK standpoint? Otherwise, could you nominate someone else to do 
so in

your place? :)

Here are the possible solutions proposed:

- Generate meson.cross toolchain file at SDK extraction time.
- Wrap meson with a shell script that dynamically generates a 
toolchain file

and then runs meson pointing to it.
- Change meson to support pulling in env vars in meson.cross, and use a
fixed meson.cross file that references the env vars.



We already have environment file, could it be used for meson as well 
and needed

bits be generated during build time for SDK.



Yes, it is certainly technically possible. I'm wondering whether or not 
that involves ugly special-casing, as I'm not familiar with the SDK 
extraction code. If not, it's probably the best solution.




Specifically, looking at script meta/files/toolchain-shar-extract.sh, I 
don't see a clean way to do something special for a single meson 
package. There is no per-package hook or similar logic.




On 01/09/2018 12:33 PM, Martin Kelly wrote:


On 01/09/2018 10:40 AM, Jussi Pakkanen wrote:


On Tue, Jan 9, 2018 at 8:20 PM, Martin Kelly  wrote:


Note the "native C compiler" line, which directly uses $CC.

I'm not sure if this is correct, but an easy way to fix the issue 
is to
ignore $CC for internal sanity checking when a cross file is 
specified.

In
that way, meson would probe the system and use the normal gcc for 
sanity

checking while still using the cross file for the actual build.



That breaks the whole reason the sanity check is there in the first
place. Its point is to test "is the native compiler the user has
specified working and capable of creating executables". If we change
it then that becomes "is the system default compiler (which we might
or might not use) working". We need to be able to support the case of
users defining both the cross compiler and the native compiler. So
something like this:

CC=/some/native/cc meson --cross-file=mycross.txt 



Yeah, that makes sense. The issue here is that the OE SDK sets CC, 
CXX etc
to point to the cross compiler, not to the native compiler, so when 
meson
assumes it's native, things will break. I think we need a way to 
specify
both cross and host compilers separately from the env vars. For 
example, if

the binaries section were split in two: "host-binaries" and
"target-binaries", then in the cross-file case, meson could use
"host-binaries" instead of looking at CC and other vars.

Right now, the SDK contains fixed contents, and there is some 
top-level

logic
for rewriting a few paths to make everything relocatable. I don't 
think

OE
wants to inject a special-case one-time generation of the 
toolchain file

at SDK
extraction time, as it circumvents the normal build process,



Would it not be possible to generate the cross file when creating the
SDK contents originally? The only change it would need is the same
kind of path fixing. The setup does not really change.



I think it would be possible, but I'm guessing it would require some
special-casing that we may not want to do. Khem probably has a better
informed opinion on this than I.


Another approach would be to generate the toolchain file truly
"on-the-fly",
such that the meson command points to a script that first generates a
toolchain file based on the contents of CC, CXX, etc. and then runs
meson. I
think this is a bad idea because it is complex (will definitely 
surprise

people) and slow. It also breaks people in surprising ways when they
accidentally use a meson from outside the SDK due to the PATH setup.



This is, roughly, what Debian does currently.



That's too bad :).

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

Re: [OE-core] [PATCH] receipes-devtools: QEMU: Bump to version 2.11.0

[Alistair Francis]

On Mon, Jan 8, 2018 at 3:45 PM, Alistair Francis  wrote:
> On Sat, Jan 6, 2018 at 2:15 AM, Richard Purdie
>  wrote:
>> On Fri, 2018-01-05 at 18:18 -0800, Alistair Francis wrote:
>>> On Fri, Jan 5, 2018 at 4:22 PM, Richard Purdie
>>>  wrote:
>>> > > Do you have an easy way to reproduce this hang?
>>> > Was this a musl build you tried to reproduce in?
>>> Ah, it was not. I'll have to figure out how to do a musl build next
>>> week and try again.
>>
>> TCLIBC="musl"
>
> Thanks. Unfortunately I'm still unable to build at all on master so I
> can't reproduce the hang.

Ok, got it. I can reproduce the successful build on master and the
hang. I'm investigating now.

Alistair

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

Re: [OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

On 01/11/2018 11:26 AM, Khem Raj wrote:

On Thu, Jan 11, 2018 at 11:22 AM, Martin Kelly  wrote:

Khem and Alexander, could you comment on which solution is preferable from
an SDK standpoint? Otherwise, could you nominate someone else to do so in
your place? :)

Here are the possible solutions proposed:

- Generate meson.cross toolchain file at SDK extraction time.
- Wrap meson with a shell script that dynamically generates a toolchain file
and then runs meson pointing to it.
- Change meson to support pulling in env vars in meson.cross, and use a
fixed meson.cross file that references the env vars.



We already have environment file, could it be used for meson as well and needed
bits be generated during build time for SDK.



Yes, it is certainly technically possible. I'm wondering whether or not 
that involves ugly special-casing, as I'm not familiar with the SDK 
extraction code. If not, it's probably the best solution.




On 01/09/2018 12:33 PM, Martin Kelly wrote:


On 01/09/2018 10:40 AM, Jussi Pakkanen wrote:


On Tue, Jan 9, 2018 at 8:20 PM, Martin Kelly  wrote:


Note the "native C compiler" line, which directly uses $CC.

I'm not sure if this is correct, but an easy way to fix the issue is to
ignore $CC for internal sanity checking when a cross file is specified.
In
that way, meson would probe the system and use the normal gcc for sanity
checking while still using the cross file for the actual build.



That breaks the whole reason the sanity check is there in the first
place. Its point is to test "is the native compiler the user has
specified working and capable of creating executables". If we change
it then that becomes "is the system default compiler (which we might
or might not use) working". We need to be able to support the case of
users defining both the cross compiler and the native compiler. So
something like this:

CC=/some/native/cc meson --cross-file=mycross.txt 



Yeah, that makes sense. The issue here is that the OE SDK sets CC, CXX etc
to point to the cross compiler, not to the native compiler, so when meson
assumes it's native, things will break. I think we need a way to specify
both cross and host compilers separately from the env vars. For example, if
the binaries section were split in two: "host-binaries" and
"target-binaries", then in the cross-file case, meson could use
"host-binaries" instead of looking at CC and other vars.


Right now, the SDK contains fixed contents, and there is some top-level
logic
for rewriting a few paths to make everything relocatable. I don't think
OE
wants to inject a special-case one-time generation of the toolchain file
at SDK
extraction time, as it circumvents the normal build process,



Would it not be possible to generate the cross file when creating the
SDK contents originally? The only change it would need is the same
kind of path fixing. The setup does not really change.



I think it would be possible, but I'm guessing it would require some
special-casing that we may not want to do. Khem probably has a better
informed opinion on this than I.


Another approach would be to generate the toolchain file truly
"on-the-fly",
such that the meson command points to a script that first generates a
toolchain file based on the contents of CC, CXX, etc. and then runs
meson. I
think this is a bad idea because it is complex (will definitely surprise
people) and slow. It also breaks people in surprising ways when they
accidentally use a meson from outside the SDK due to the PATH setup.



This is, roughly, what Debian does currently.



That's too bad :).

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

[OE-core] ✗ patchtest: failure for recipes-core: move hwclock.sh to util-linux

[Patchwork]

== Series Details ==

Series: recipes-core: move hwclock.sh to util-linux
Revision: 1
URL   : https://patchwork.openembedded.org/series/10505/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Patches not removed from tree [test_src_uri_left_files] 
  Suggested fixAmend the patch containing the software patch file removal
  Patchhwclock.sh



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

Re: [OE-core] Issues with meson in SDK with cross-file

[Khem Raj]

On Thu, Jan 11, 2018 at 11:22 AM, Martin Kelly  wrote:
> Khem and Alexander, could you comment on which solution is preferable from
> an SDK standpoint? Otherwise, could you nominate someone else to do so in
> your place? :)
>
> Here are the possible solutions proposed:
>
> - Generate meson.cross toolchain file at SDK extraction time.
> - Wrap meson with a shell script that dynamically generates a toolchain file
> and then runs meson pointing to it.
> - Change meson to support pulling in env vars in meson.cross, and use a
> fixed meson.cross file that references the env vars.
>

We already have environment file, could it be used for meson as well and needed
bits be generated during build time for SDK.

>
> On 01/09/2018 12:33 PM, Martin Kelly wrote:
>>
>> On 01/09/2018 10:40 AM, Jussi Pakkanen wrote:
>>>
>>> On Tue, Jan 9, 2018 at 8:20 PM, Martin Kelly  wrote:
>>>
 Note the "native C compiler" line, which directly uses $CC.

 I'm not sure if this is correct, but an easy way to fix the issue is to
 ignore $CC for internal sanity checking when a cross file is specified.
 In
 that way, meson would probe the system and use the normal gcc for sanity
 checking while still using the cross file for the actual build.
>>>
>>>
>>> That breaks the whole reason the sanity check is there in the first
>>> place. Its point is to test "is the native compiler the user has
>>> specified working and capable of creating executables". If we change
>>> it then that becomes "is the system default compiler (which we might
>>> or might not use) working". We need to be able to support the case of
>>> users defining both the cross compiler and the native compiler. So
>>> something like this:
>>>
>>> CC=/some/native/cc meson --cross-file=mycross.txt 
>>>
>>
>> Yeah, that makes sense. The issue here is that the OE SDK sets CC, CXX etc
>> to point to the cross compiler, not to the native compiler, so when meson
>> assumes it's native, things will break. I think we need a way to specify
>> both cross and host compilers separately from the env vars. For example, if
>> the binaries section were split in two: "host-binaries" and
>> "target-binaries", then in the cross-file case, meson could use
>> "host-binaries" instead of looking at CC and other vars.
>>
 Right now, the SDK contains fixed contents, and there is some top-level
 logic
 for rewriting a few paths to make everything relocatable. I don't think
 OE
 wants to inject a special-case one-time generation of the toolchain file
 at SDK
 extraction time, as it circumvents the normal build process,
>>>
>>>
>>> Would it not be possible to generate the cross file when creating the
>>> SDK contents originally? The only change it would need is the same
>>> kind of path fixing. The setup does not really change.
>>>
>>
>> I think it would be possible, but I'm guessing it would require some
>> special-casing that we may not want to do. Khem probably has a better
>> informed opinion on this than I.
>>
 Another approach would be to generate the toolchain file truly
 "on-the-fly",
 such that the meson command points to a script that first generates a
 toolchain file based on the contents of CC, CXX, etc. and then runs
 meson. I
 think this is a bad idea because it is complex (will definitely surprise
 people) and slow. It also breaks people in surprising ways when they
 accidentally use a meson from outside the SDK due to the PATH setup.
>>>
>>>
>>> This is, roughly, what Debian does currently.
>>>
>>
>> That's too bad :).
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] recipes-core: move hwclock.sh to util-linux

[Alex Stewart]

* Move the hwclock.sh initscript from the busybox recipe to util-linux.
  This script is generally useful for distros that get their hwclock
  implementation from sources other than busybox and we follow debian's
  example by providing it in util-linux.

:busybox/*
* Remove the busybox-hwclock package, as it no longer has a purpose.
* If busybox is configured to include hwclock, the busybox package will
  RDEPEND on util-linux-hwclock-init.

:util-linux/*
* Provide the hwclock.sh script in util-linux-hwclock-init, which can be
  pulled by any packages that depend on its functionality.
* util-linux-hwclock RDEPENDS on util-linux-hwclock-init for its
  initscript.

Signed-off-by: Alex Stewart 
Acked-by: Haris Okanovic 
Acked-by: Adrian Ratiu 
Acked-by: Ken Sharp 
Natinst-ReviewBoard-ID: 214983, 215755
---
 meta/recipes-core/busybox/busybox.inc| 16 +---
 meta/recipes-core/busybox/busybox_1.27.2.bb  |  1 -
 meta/recipes-core/util-linux/util-linux.inc  | 14 --
 .../{busybox/files => util-linux/util-linux}/hwclock.sh  |  0
 meta/recipes-core/util-linux/util-linux_2.31.bb  |  1 +
 5 files changed, 22 insertions(+), 10 deletions(-)
 rename meta/recipes-core/{busybox/files => util-linux/util-linux}/hwclock.sh 
(100%)

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index 4012f921c6..d9c3c2793b 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -20,19 +20,17 @@ export EXTRA_LDFLAGS = "${LDFLAGS}"
 
 EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} 
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' 
HOSTCPP='${BUILD_CPP}'"
 
-PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev 
${PN}-hwclock"
+PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev"
 
 FILES_${PN}-httpd = "${sysconfdir}/init.d/busybox-httpd /srv/www"
 FILES_${PN}-syslog = "${sysconfdir}/init.d/syslog* 
${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf* 
${systemd_unitdir}/system/syslog.service ${sysconfdir}/default/busybox-syslog"
 FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev ${sysconfdir}/mdev.conf 
${sysconfdir}/mdev/*"
 FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd"
 FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc"
-FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
 
-INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev 
${PN}-hwclock"
+INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev"
 
 INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd"
-INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
 INITSCRIPT_NAME_${PN}-mdev = "mdev"
 INITSCRIPT_PARAMS_${PN}-mdev = "start 04 S ."
 INITSCRIPT_NAME_${PN}-syslog = "syslog"
@@ -276,9 +274,6 @@ do_install () {
if grep "CONFIG_UDHCPD=y" ${B}/.config; then
install -m 0755 ${WORKDIR}/busybox-udhcpd 
${D}${sysconfdir}/init.d/
fi
-   if grep "CONFIG_HWCLOCK=y" ${B}/.config; then
-   install -m 0755 ${WORKDIR}/hwclock.sh ${D}${sysconfdir}/init.d/
-   fi
if grep "CONFIG_UDHCPC=y" ${B}/.config; then
install -d ${D}${sysconfdir}/udhcpc.d
install -d ${D}${datadir}/udhcpc
@@ -377,6 +372,13 @@ python do_package_prepend () {
 else:
 set_alternative_vars("${sysconfdir}/busybox.links.nosuid", 
"${base_bindir}/busybox.nosuid")
 set_alternative_vars("${sysconfdir}/busybox.links.suid", 
"${base_bindir}/busybox.suid")
+
+# If busybox is configured to provide a hwclock implementation, add a
+# package dependency on util-linux-hwclock-init for the
+# /etc/init.d/hwclock.sh initscript.
+with open(d.getVar('B', expand=True) + '/.config', 'r') as fp_conf:
+if 'CONFIG_HWCLOCK=y' in fp_conf.read():
+d.appendVar('RDEPENDS_busybox', ' util-linux-hwclock-init ')
 }
 
 pkg_postinst_${PN} () {
diff --git a/meta/recipes-core/busybox/busybox_1.27.2.bb 
b/meta/recipes-core/busybox/busybox_1.27.2.bb
index 6c1f4888cf..af2abadc5e 100644
--- a/meta/recipes-core/busybox/busybox_1.27.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.27.2.bb
@@ -8,7 +8,6 @@ SRC_URI = 
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-udhcpd \
file://default.script \
file://simple.script \
-   file://hwclock.sh \
file://mount.busybox \
file://syslog \
file://syslog-startup.conf \
diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 248e8bee95..7f86227811 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -19,13 +19,16 @@ LIC_FILES_CHKSUM = 
"file://README.licensing;md5=1715f5ee3e01203ca1e1e0b9ee65918c
  

Re: [OE-core] [PATCH 2/9] gnomebase-meson.bbclass: add a meson-specific version

[Martin Kelly]

On 01/11/2018 09:49 AM, Richard Purdie wrote:

On Thu, 2018-01-11 at 13:35 +0200, Alexander Kanavin wrote:

On 01/10/2018 09:11 PM, Martin Kelly wrote:


Yes, to be clear, I'm not griping, as I'm very happy meson landed
in
OE-core, and I'm working on SDK support now. I have an OE-core
thread
going with meson upstream to get the issue fixed.

To be clear though, I'm not sure it even regressed. AFAICT, it
never
quite worked.

Where would I add SDK tests for this?

meta/lib/oeqa/selftest/cases is the place. Not sure what existing
SDK
tests are already there.


Actually, no. See:

$ ls meta/lib/oeqa/sdk/cases/
buildcpio.py
buildgalculator.py
buildlzip.py
gcc.py
perl.py
python.py

There is also "sdkext" for the eSDK.

You'd run these with:

INHERIT += "testimage"

and then

bitbake  -c testsdk

Cheers,

Richard



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

Re: [OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

Khem and Alexander, could you comment on which solution is preferable 
from an SDK standpoint? Otherwise, could you nominate someone else to do 
so in your place? :)


Here are the possible solutions proposed:

- Generate meson.cross toolchain file at SDK extraction time.
- Wrap meson with a shell script that dynamically generates a toolchain 
file and then runs meson pointing to it.
- Change meson to support pulling in env vars in meson.cross, and use a 
fixed meson.cross file that references the env vars.


On 01/09/2018 12:33 PM, Martin Kelly wrote:

On 01/09/2018 10:40 AM, Jussi Pakkanen wrote:

On Tue, Jan 9, 2018 at 8:20 PM, Martin Kelly  wrote:


Note the "native C compiler" line, which directly uses $CC.

I'm not sure if this is correct, but an easy way to fix the issue is to
ignore $CC for internal sanity checking when a cross file is 
specified. In

that way, meson would probe the system and use the normal gcc for sanity
checking while still using the cross file for the actual build.


That breaks the whole reason the sanity check is there in the first
place. Its point is to test "is the native compiler the user has
specified working and capable of creating executables". If we change
it then that becomes "is the system default compiler (which we might
or might not use) working". We need to be able to support the case of
users defining both the cross compiler and the native compiler. So
something like this:

CC=/some/native/cc meson --cross-file=mycross.txt 



Yeah, that makes sense. The issue here is that the OE SDK sets CC, CXX 
etc to point to the cross compiler, not to the native compiler, so when 
meson assumes it's native, things will break. I think we need a way to 
specify both cross and host compilers separately from the env vars. For 
example, if the binaries section were split in two: "host-binaries" and 
"target-binaries", then in the cross-file case, meson could use 
"host-binaries" instead of looking at CC and other vars.


Right now, the SDK contains fixed contents, and there is some 
top-level logic
for rewriting a few paths to make everything relocatable. I don't 
think OE
wants to inject a special-case one-time generation of the toolchain 
file at SDK

extraction time, as it circumvents the normal build process,


Would it not be possible to generate the cross file when creating the
SDK contents originally? The only change it would need is the same
kind of path fixing. The setup does not really change.



I think it would be possible, but I'm guessing it would require some 
special-casing that we may not want to do. Khem probably has a better 
informed opinion on this than I.


Another approach would be to generate the toolchain file truly 
"on-the-fly",

such that the meson command points to a script that first generates a
toolchain file based on the contents of CC, CXX, etc. and then runs 
meson. I

think this is a bad idea because it is complex (will definitely surprise
people) and slow. It also breaks people in surprising ways when they
accidentally use a meson from outside the SDK due to the PATH setup.


This is, roughly, what Debian does currently.



That's too bad :).

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

[OE-core] Error do_compile libepoxy

[Mathias Rudnik]

Hello,

I am trying to build libepoxy but the do_compile tasks breaks.
I found following error messages in the logs:

arm-poky-linux-gnueabi-gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard 
-mtune=arm1176jzf-s -mfpu=vfp 
--sysroot=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot
 '-Itest/egl_common@sta' '-Itest' '-Iinclude/epoxy' '-I../libepoxy-1.4.3/test' 
'-Iinclude' '-I../libepoxy-1.4.3/include' '-Isrc' '-I../libepoxy-1.4.3/src' 
'-fdiagnostics-color=always' '-pipe' '-D_FILE_OFFSET_BITS=64' '-Wall' 
'-Winvalid-pch' '-std=gnu99' '-O2' '-g' '-O2' '-g' 
'-feliminate-unused-debug-types' 
'-fdebug-prefix-map=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0=/usr/src/debug/libepoxy/1.4.3-r0'
 
'-fdebug-prefix-map=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot-native='
 
'-fdebug-prefix-map=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot='
 '-lEGL' '-fPIC' '
 -Wpointer-arith' '-Wmissing-declarations' '-Wformat=2' '-Wstrict-prototypes' 
'-Wmissing-prototypes' '-Wnested-externs' '-Wbad-function-cast' 
'-Wold-style-definition' '-Wdeclaration-after-statement' '-Wunused' 
'-Wuninitialized' '-Wshadow' '-Wmissing-noreturn' '-Wmissing-format-attribute' 
'-Wredundant-decls' '-Wlogical-op' '-Werror=implicit' '-Werror=nonnull' 
'-Werror=init-self' '-Werror=main' '-Werror=missing-braces' 
'-Werror=sequence-point' '-Werror=return-type' '-Werror=trigraphs' 
'-Werror=array-bounds' '-Werror=write-strings' '-Werror=address' 
'-Werror=int-to-pointer-cast' '-Werror=pointer-to-int-cast' 
'-fno-strict-aliasing' '-Wno-int-conversion' '-MMD' '-MQ' 
'test/egl_common@sta/egl_common.c.o' '-MF' 
'test/egl_common@sta/egl_common.c.o.d' -o 'test/egl_common@sta/egl_common.c.o' 
-c ../libepoxy-1.4.3/test/egl_common.c
../libepoxy-1.4.3/test/egl_common.c: In function 'get_egl_display_or_skip':
../libepoxy-1.4.3/test/egl_common.c:36:5: error: unknown type name 'Display'; 
did you mean 'EGLDisplay'?
 Display *dpy = XOpenDisplay(NULL);
 ^~~
 EGLDisplay
../libepoxy-1.4.3/test/egl_common.c:36:20: error: implicit declaration of 
function 'XOpenDisplay'; did you mean 'eglGetDisplay'? 
[-Werror=implicit-function-declaration]
 Display *dpy = XOpenDisplay(NULL);
^~~~
eglGetDisplay
../libepoxy-1.4.3/test/egl_common.c:36:20: warning: nested extern declaration 
of 'XOpenDisplay' [-Wnested-externs]
cc1: some warnings being treated as errors

Does anybody know what i am doing wrong?


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

Re: [OE-core] [PATCH 2/2] gettext: rationalise optional dependencies

[Khem Raj]

On Wed, Jan 10, 2018 at 9:28 AM, Ross Burton  wrote:
> gettext has optional dependencies on libxml2, glib, libcroco and libunistring.
> If they're not available then gettext will use internal copies, but it can 
> also
> use system libraries.
>
> For gettext-native and nativesdk-gettext continue to use the internal copies 
> to
> reduce the dependencies, but for target use the system shared libraries.
>

Do we get any reduction in size ? if yes how much, not sure whats the defaults
generally used by other distributions but it would nice to be using
the default config
options for best results.

> Also gettext 0.19.7 onwards swapped expat for libxm2, so remove the build
> dependency on expat.
>
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-core/gettext/gettext_0.19.8.1.bb | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/meta/recipes-core/gettext/gettext_0.19.8.1.bb 
> b/meta/recipes-core/gettext/gettext_0.19.8.1.bb
> index c2059e608b1..97083c0da2d 100644
> --- a/meta/recipes-core/gettext/gettext_0.19.8.1.bb
> +++ b/meta/recipes-core/gettext/gettext_0.19.8.1.bb
> @@ -8,7 +8,7 @@ SECTION = "libs"
>  LICENSE = "GPLv3+ & LGPL-2.1+"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
>
> -DEPENDS = "gettext-native virtual/libiconv expat"
> +DEPENDS = "gettext-native virtual/libiconv"
>  DEPENDS_class-native = "gettext-minimal-native"
>  PROVIDES = "virtual/libintl virtual/gettext"
>  PROVIDES_class-native = "virtual/gettext-native"
> @@ -22,8 +22,6 @@ SRC_URI = "${GNU_MIRROR}/gettext/gettext-${PV}.tar.gz \
>  SRC_URI[md5sum] = "97e034cf8ce5ba73a28ff6c3c0638092"
>  SRC_URI[sha256sum] = 
> "ff942af0e438ced4a8b0ea4b0b6e0d6d657157c5e2364de57baa279c1c125c43"
>
> -PACKAGECONFIG[msgcat-curses] = 
> "--with-libncurses-prefix=${STAGING_LIBDIR}/..,--disable-curses,ncurses,"
> -
>  inherit autotools texinfo
>
>  EXTRA_OECONF += "--without-lispdir \
> @@ -33,18 +31,24 @@ EXTRA_OECONF += "--without-lispdir \
>   --disable-native-java \
>   --disable-openmp \
>   --disable-acl \
> - --with-included-glib \
>   --without-emacs \
>   --without-cvs \
>   --without-git \
> - --with-included-libxml \
> - --with-included-libcroco \
> - --with-included-libunistring \
>  "
>  EXTRA_OECONF_append_class-target = " \
>   --with-bisonlocaledir=${datadir}/locale \
>  "
>
> +PACKAGECONFIG ??= "croco glib libxml libunistring"
> +PACKAGECONFIG_class-native = ""
> +PACKAGECONFIG_class-nativesdk = ""
> +
> +PACKAGECONFIG[croco] = 
> "--without-included-libcroco,--with-included-libcroco,libcroco"
> +PACKAGECONFIG[glib] = "--without-included-glib,--with-included-glib,glib-2.0"
> +PACKAGECONFIG[libxml] = 
> "--without-included-libxml,--with-included-libxml,libxml2"
> +PACKAGECONFIG[libunistring] = 
> "--without-included-libunistring,--with-included-libunistring,libunistring"
> +PACKAGECONFIG[msgcat-curses] = 
> "--with-libncurses-prefix=${STAGING_LIBDIR}/..,--disable-curses,ncurses,"
> +
>  acpaths = '-I ${S}/gettext-runtime/m4 \
> -I ${S}/gettext-tools/m4'
>
> --
> 2.11.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] uriparser

[Khem Raj]

On Wed, Jan 10, 2018 at 11:20 AM, Trevor Woerner  wrote:
> Hi Martin,
>
> Any chance the uriparser recipe from meta-luneui
> (https://layers.openembedded.org/layerindex/recipe/32523/) could be added to
> openembedded-core (or meta-openembedded?). It's also now needed for the git
> version of tpm2-tss in meta-measured.
>

I think meta-oe might be ok. If nothing in OE-Core needs it yet then I
dont think it
should be on oe-core

> Best regards,
>  Trevor
>
> --
> ___
> 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 2/9] gnomebase-meson.bbclass: add a meson-specific version

[Richard Purdie]

On Thu, 2018-01-11 at 13:35 +0200, Alexander Kanavin wrote:
> On 01/10/2018 09:11 PM, Martin Kelly wrote:
> > 
> > Yes, to be clear, I'm not griping, as I'm very happy meson landed
> > in 
> > OE-core, and I'm working on SDK support now. I have an OE-core
> > thread 
> > going with meson upstream to get the issue fixed.
> > 
> > To be clear though, I'm not sure it even regressed. AFAICT, it
> > never 
> > quite worked.
> > 
> > Where would I add SDK tests for this?
> meta/lib/oeqa/selftest/cases is the place. Not sure what existing
> SDK 
> tests are already there.

Actually, no. See:

$ ls meta/lib/oeqa/sdk/cases/
buildcpio.py
buildgalculator.py
buildlzip.py
gcc.py
perl.py
python.py

There is also "sdkext" for the eSDK.

You'd run these with:

INHERIT += "testimage"

and then

bitbake  -c testsdk

Cheers,

Richard

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

Re: [OE-core] [PATCH] gcc: add flex-native explicit dependency

[Richard Purdie]

On Thu, 2018-01-11 at 10:02 -0500, Denys Dmytriyenko wrote:
> On Thu, Jan 11, 2018 at 02:41:15PM +, Richard Purdie wrote:
> > and test results so far imply that we need:
> > 
> > diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc b/meta/recipes-
> > devtools/gcc/gcc-7.2.inc
> > index 1d40cba7317..90e4a990cb3 100644
> > --- a/meta/recipes-devtools/gcc/gcc-7.2.inc
> > +++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
> > @@ -11,7 +11,7 @@ BINV = "7.2.0"
> >  FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc-7.2:${FILE_DIRNAME}/gcc-
> > 7.2/backport:"
> >  
> >  DEPENDS =+ "mpfr gmp libmpc zlib"
> > -NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native"
> > +NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native
> > flex-native"
> >  
> >  LICENSE = "GPL-3.0-with-GCC-exception & GPLv3"
> >  
> > 
> > probably in addition to your patch. I'll continue to run some test
> > builds and see how much breakage the above change shows up.
> Thanks. I was building native gcc for the target, while using
> external 
> prebuilt cross toolchain. I first tried adding flex-native to
> NATIVEDEPS 
> list, but that didn't help - looks like this list is only used for
> cross and 
> crosssdk builds.

I'll probably take your at and perf patches, my gcc one which covers
the cross and candadian variants and merge a change to the sstate
dependency code which means we'll explicitly see these dependency
issues in future. I'll queue this in -next and test.

Cheers,

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

[OE-core] [PATCH 4/4] sstate: Avoid indirect bison/flex-native dependencies

[Richard Purdie]

This avoids adding flex-native or bison-native to the sysroot without a specific
dependency in the recipe and means indirect dependencies (e.g. X -> Y -> 
binutils-cross -> flex-native)
no longer met the dependency incidentally. This improves determinism and avoid
build failures when people switch to external toolchains.

Signed-off-by: Richard Purdie 
---
 meta/classes/sstate.bbclass | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 6808942..7509561 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -921,6 +921,13 @@ def setscene_depvalid(task, taskdependees, notneeded, d, 
log=None):
 if taskdependees[task][1] == "do_stash_locale" or taskdependees[task][1] 
== "do_gcc_stash_builddir":
 return True
 
+# Don't pull in flex-native or bison-native without a specific dependency 
in the recipe
+# This improves determinism in the metadata and avoids the dependency 
being met incidentally,
+# e.g. from binutils-cross which doesn't happen in the external toolchain 
case
+if taskdependees[task][1] == 'do_populate_sysroot':
+if taskdependees[task][0] == "flex-native" or taskdependees[task][0] 
== "bison-native":
+return True
+
 # We only need to trigger packagedata through direct dependencies
 # but need to preserve packagedata on packagedata links
 if taskdependees[task][1] == "do_packagedata":
-- 
2.7.4

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

[OE-core] [PATCH 2/4] at: Add missing bison-native dependency

[Richard Purdie]

Signed-off-by: Richard Purdie 
---
 meta/recipes-extended/at/at_3.1.20.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/at/at_3.1.20.bb 
b/meta/recipes-extended/at/at_3.1.20.bb
index 9b537ee..8fe3b43 100644
--- a/meta/recipes-extended/at/at_3.1.20.bb
+++ b/meta/recipes-extended/at/at_3.1.20.bb
@@ -5,7 +5,7 @@ the system load levels drop to a particular level."
 SECTION = "base"
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=4325afd396febcb659c36b49533135d4"
-DEPENDS = "flex flex-native \
+DEPENDS = "flex flex-native bison-native \
${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
 
 RDEPENDS_${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 
'${PAM_DEPS}', '', d)} \
-- 
2.7.4

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

[OE-core] [PATCH 3/4] gcc: Add missing flex-native dependency

[Richard Purdie]

This is needed for all stages of the cross/target/canadian compilers
and without it (and with indirect gcc dependencies disabled), the steps
fail. Add missing dependencies.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/gcc/gcc-7.2.inc| 4 ++--
 meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc 
b/meta/recipes-devtools/gcc/gcc-7.2.inc
index 1d40cba..f3d8a5e 100644
--- a/meta/recipes-devtools/gcc/gcc-7.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
@@ -10,8 +10,8 @@ BINV = "7.2.0"
 
 FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc-7.2:${FILE_DIRNAME}/gcc-7.2/backport:"
 
-DEPENDS =+ "mpfr gmp libmpc zlib"
-NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native"
+DEPENDS =+ "mpfr gmp libmpc zlib flex-native"
+NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native flex-native"
 
 LICENSE = "GPL-3.0-with-GCC-exception & GPLv3"
 
diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc 
b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
index 6d77620..bdd6f7e 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
@@ -3,7 +3,7 @@ inherit cross-canadian
 SUMMARY = "GNU cc and gcc C compilers (cross-canadian for ${TARGET_ARCH} 
target)"
 PN = "gcc-cross-canadian-${TRANSLATED_TARGET_ARCH}"
 
-DEPENDS = "virtual/${TARGET_PREFIX}gcc virtual/${HOST_PREFIX}gcc-crosssdk 
virtual/${HOST_PREFIX}binutils-crosssdk 
virtual/nativesdk-${HOST_PREFIX}libc-for-gcc nativesdk-gettext"
+DEPENDS = "virtual/${TARGET_PREFIX}gcc virtual/${HOST_PREFIX}gcc-crosssdk 
virtual/${HOST_PREFIX}binutils-crosssdk 
virtual/nativesdk-${HOST_PREFIX}libc-for-gcc nativesdk-gettext flex-native"
 
 GCCMULTILIB = "--enable-multilib"
 
-- 
2.7.4

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

[OE-core] [PATCH 1/4] perf: Add missing bison-native and flex-native dependencies

[Richard Purdie]

Signed-off-by: Richard Purdie 
---
 meta/recipes-kernel/perf/perf.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index b79b973..eebe755 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -29,6 +29,8 @@ DEPENDS = " \
 bison flex xz \
 xmlto-native \
 asciidoc-native \
+flex-native \
+bison-native \
 "
 
 do_configure[depends] += "virtual/kernel:do_shared_workdir"
-- 
2.7.4

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

[OE-core] [PATCH] pax-utils: update SRC_URI

[Ross Burton]

The gentoo.osuosl.org mirror doesn't store all versions of pax-utils, so use the
maintainers own mirror which stores them all.

This also means we can remove UPSTREAM_CHECK_URI as the defaults work now.

Thanks to Maxin John for the initial patch.

[ YOCTO #11559 ]

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/pax-utils/pax-utils_1.2.2.bb | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/meta/recipes-devtools/pax-utils/pax-utils_1.2.2.bb 
b/meta/recipes-devtools/pax-utils/pax-utils_1.2.2.bb
index c6c49e9b2d0..9635a5e7082 100644
--- a/meta/recipes-devtools/pax-utils/pax-utils_1.2.2.bb
+++ b/meta/recipes-devtools/pax-utils/pax-utils_1.2.2.bb
@@ -7,13 +7,9 @@ HOMEPAGE = 
"http://www.gentoo.org/proj/en/hardened/pax-utils.xml;
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a"
 
-SRC_URI = "http://gentoo.osuosl.org/distfiles/pax-utils-${PV}.tar.xz \
-"
-
+SRC_URI = "https://dev.gentoo.org/~vapier/dist/pax-utils-${PV}.tar.xz;
 SRC_URI[md5sum] = "a580468318f0ff42edf4a8cd314cc942"
 SRC_URI[sha256sum] = 
"7f4a7f8db6b4743adde7582fa48992ad01776796fcde030683732f56221337d9"
-UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/p/pax-utils/"
-UPSTREAM_CHECK_REGEX = "pax-utils_(?P\d+(\.\d+)+)\.orig\.tar"
 
 RDEPENDS_${PN} += "bash"
 
-- 
2.11.0

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

[OE-core] [rocko][PATCH] package: Record PE value for shlib dependencies

[Böszörményi Zoltán]

When downgrading a package or using a substitute with lower version,
the way to do it is adding or increasing PE. But it didn't help
dependant packages because the shlib records didn't contain PE, only PV.

Let's add the PE value into these records for packages where it's set.

The in-memory variables storing the versions use the PE:PV notation
but the on-disk files must use something else because the : character
is already used as field delimiter in the package.list files storing
these shlib records. Use # instead in the files, so the file format
doesn't change. Conversion occurs on reading/writing the package.list
files.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/package.bbclass | 6 +-
 meta/lib/oe/package.py   | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 2053d46395..8904b8091a 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1669,6 +1669,10 @@ python package_do_shlibs() {
 if not pkgver:
 pkgver = ver
 
+pkgpe = d.getVar('PE')
+if pkgpe:
+pkgver = pkgpe + ':' + pkgver
+
 needed[pkg] = []
 sonames = list()
 renames = list()
@@ -1697,7 +1701,7 @@ python package_do_shlibs() {
 if old_pkg != pkg:
 bb.warn('%s-%s was registered as shlib provider for 
%s, changing it to %s-%s because it was built later' % (old_pkg, old_pkgver, 
s[0], pkg, pkgver))
 bb.debug(1, 'registering %s-%s as shlib provider for %s' % 
(pkg, pkgver, s[0]))
-fd.write(s[0] + ':' + s[1] + ':' + s[2] + '\n')
+fd.write(s[0] + ':' + s[1] + ':' + s[2].replace(':', '#', 1) + 
'\n')
 if s[0] not in shlib_provider:
 shlib_provider[s[0]] = {}
 shlib_provider[s[0]][s[1]] = (pkg, pkgver)
diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 1e5c3aa8e1..d19fe7312d 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -258,7 +258,7 @@ def read_shlib_providers(d):
 s = l.strip().split(":")
 if s[0] not in shlib_provider:
 shlib_provider[s[0]] = {}
-shlib_provider[s[0]][s[1]] = (dep_pkg, s[2])
+shlib_provider[s[0]][s[1]] = (dep_pkg, s[2].replace('#', 
':', 1))
 return shlib_provider
 
 
-- 
2.14.3

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

[OE-core] [PATCH] package: Record PE value for shlib dependencies

[Böszörményi Zoltán]

When downgrading a package or using a substitute with lower version,
the way to do it is adding or increasing PE. But it didn't help
dependant packages because the shlib records didn't contain PE, only PV.

Let's add the PE value into these records for packages where it's set.

The in-memory variables storing the versions use the PE:PV notation
but the on-disk files must use something else because the : character
is already used as field delimiter in the package.list files storing
these shlib records. Use # instead in the files, so the file format
doesn't change. Conversion occurs on reading/writing the package.list
files.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/package.bbclass | 6 +-
 meta/lib/oe/package.py   | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 7dc759699f..966c059851 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1686,6 +1686,10 @@ python package_do_shlibs() {
 if not pkgver:
 pkgver = ver
 
+pkgpe = d.getVar('PE')
+if pkgpe:
+pkgver = pkgpe + ':' + pkgver
+
 needed[pkg] = []
 sonames = list()
 renames = list()
@@ -1714,7 +1718,7 @@ python package_do_shlibs() {
 if old_pkg != pkg:
 bb.warn('%s-%s was registered as shlib provider for 
%s, changing it to %s-%s because it was built later' % (old_pkg, old_pkgver, 
s[0], pkg, pkgver))
 bb.debug(1, 'registering %s-%s as shlib provider for %s' % 
(pkg, pkgver, s[0]))
-fd.write(s[0] + ':' + s[1] + ':' + s[2] + '\n')
+fd.write(s[0] + ':' + s[1] + ':' + s[2].replace(':', '#', 1) + 
'\n')
 if s[0] not in shlib_provider:
 shlib_provider[s[0]] = {}
 shlib_provider[s[0]][s[1]] = (pkg, pkgver)
diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 1e5c3aa8e1..d19fe7312d 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -258,7 +258,7 @@ def read_shlib_providers(d):
 s = l.strip().split(":")
 if s[0] not in shlib_provider:
 shlib_provider[s[0]] = {}
-shlib_provider[s[0]][s[1]] = (dep_pkg, s[2])
+shlib_provider[s[0]][s[1]] = (dep_pkg, s[2].replace('#', 
':', 1))
 return shlib_provider
 
 
-- 
2.14.3

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

Re: [OE-core] [PATCH V2 1/1] coreutils: upgrade to 8.29

[Burton, Ross]

On 9 January 2018 at 01:40, Chen Qi  wrote:

> * hostname is explicitly enabled to keep the same with previous recipe's
>   behaviour.
>

But buildhistory-diff:

packages/corei7-64-poky-linux/coreutils/coreutils: FILELIST: added
"/usr/bin/hostname"

So the old coreutils wasn't building hostname at all (we use /bin/hostname
from busybox).

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

[OE-core] [rocko][PATCH] webkitgtk: update to 2.18.5 (includes Spectre mitigations; see commit description)

[Alexander Kanavin]

This is the only available stable version with mitigation fixes for Spectre.
Webkit upstream developers do not port CVE fixes to earlier stable series,
no exception was made in this case.

More information:

https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/
https://webkitgtk.org/security/WSA-2018-0001.html
https://webkitgtk.org/2018/01/10/webkitgtk2.18.5-released.html

This commit also contains the following commits added in master branch after 
rocko release:

===
webkitgtk: update to 2.18.3

gcc7.patch, musl-fixes.patch, and ppc-musl-fix.patch all change code that is no
longer present in upstream tree. However, a patch with different musl fixes
has been added.

The rest of the patches are rebased to the new tree.

Libtasn is a new dependency.

Disable Gstreamer GL support on x86 due to clashing headers problem.

(From OE-Core rev: 3acae2dcd130122fe76504ec855af78db829d6ec)
===
webkitgtk: fix build with musl and x32

Make the x32 check generic to make it work with musl as well.

Fixes [YOCTO #12118]

(From OE-Core rev: dbd604ccf34e304769937b15051c047561de47f7)
===

Signed-off-by: Alexander Kanavin 
---
 .../webkitgtk/0001-Fix-build-with-musl.patch   |  77 +
 ...ix-racy-parallel-build-of-WebKit2-4.0.gir.patch |  23 +--
 ...c-settings-so-that-gtkdoc-generation-work.patch |  25 +--
 ...bKitMacros-Append-to-I-and-not-to-isystem.patch | 182 -
 ...ng-introspection-files-add-CMAKE_C_FLAGS-.patch |  24 +--
 .../detect-atomics-during-configure.patch  |  26 ++-
 meta/recipes-sato/webkit/webkitgtk/gcc7.patch  |  23 ---
 .../recipes-sato/webkit/webkitgtk/musl-fixes.patch |  48 --
 .../webkit/webkitgtk/ppc-musl-fix.patch|  26 ---
 .../{webkitgtk_2.16.6.bb => webkitgtk_2.18.5.bb}   |  16 +-
 10 files changed, 213 insertions(+), 257 deletions(-)
 create mode 100644 
meta/recipes-sato/webkit/webkitgtk/0001-Fix-build-with-musl.patch
 delete mode 100644 meta/recipes-sato/webkit/webkitgtk/gcc7.patch
 delete mode 100644 meta/recipes-sato/webkit/webkitgtk/musl-fixes.patch
 delete mode 100644 meta/recipes-sato/webkit/webkitgtk/ppc-musl-fix.patch
 rename meta/recipes-sato/webkit/{webkitgtk_2.16.6.bb => webkitgtk_2.18.5.bb} 
(91%)

diff --git a/meta/recipes-sato/webkit/webkitgtk/0001-Fix-build-with-musl.patch 
b/meta/recipes-sato/webkit/webkitgtk/0001-Fix-build-with-musl.patch
new file mode 100644
index 000..7cc4514fccc
--- /dev/null
+++ b/meta/recipes-sato/webkit/webkitgtk/0001-Fix-build-with-musl.patch
@@ -0,0 +1,77 @@
+From 415e31bd5444fa360af58b069f1b9db6607fca7d Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Fri, 6 Oct 2017 17:00:08 +0300
+Subject: [PATCH] Fix build with musl
+
+Upstream-Status: Pending
+Signed-off-by: Alexander Kanavin 
+---
+ Source/JavaScriptCore/runtime/MachineContext.h | 10 +-
+ Source/WTF/wtf/Platform.h  |  2 +-
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/Source/JavaScriptCore/runtime/MachineContext.h 
b/Source/JavaScriptCore/runtime/MachineContext.h
+index 95080b9..2bb689c 100644
+--- a/Source/JavaScriptCore/runtime/MachineContext.h
 b/Source/JavaScriptCore/runtime/MachineContext.h
+@@ -146,7 +146,7 @@ inline void*& stackPointer(mcontext_t& machineContext)
+ #error Unknown Architecture
+ #endif
+ 
+-#elif defined(__GLIBC__)
++#elif defined(__linux__)
+ 
+ #if CPU(X86)
+ return reinterpret_cast((uintptr_t&) 
machineContext.gregs[REG_ESP]);
+@@ -251,7 +251,7 @@ inline void*& framePointer(mcontext_t& machineContext)
+ #error Unknown Architecture
+ #endif
+ 
+-#elif defined(__GLIBC__)
++#elif defined(__linux__)
+ 
+ // The following sequence depends on glibc's sys/ucontext.h.
+ #if CPU(X86)
+@@ -354,7 +354,7 @@ inline void*& instructionPointer(mcontext_t& 
machineContext)
+ #error Unknown Architecture
+ #endif
+ 
+-#elif defined(__GLIBC__)
++#elif defined(__linux__)
+ 
+ // The following sequence depends on glibc's sys/ucontext.h.
+ #if CPU(X86)
+@@ -466,7 +466,7 @@ inline void*& argumentPointer<1>(mcontext_t& 
machineContext)
+ #error Unknown Architecture
+ #endif
+ 
+-#elif defined(__GLIBC__)
++#elif defined(__linux__)
+ 
+ // The following sequence depends on glibc's sys/ucontext.h.
+ #if CPU(X86)
+@@ -583,7 +583,7 @@ inline void*& llintInstructionPointer(mcontext_t& 
machineContext)
+ #error Unknown Architecture
+ #endif
+ 
+-#elif defined(__GLIBC__)
++#elif defined(__linux__)
+ 
+ // The following sequence depends on glibc's sys/ucontext.h.
+ #if CPU(X86)
+diff --git a/Source/WTF/wtf/Platform.h b/Source/WTF/wtf/Platform.h
+index 5a2863b..b36c3ff 100644
+--- a/Source/WTF/wtf/Platform.h
 b/Source/WTF/wtf/Platform.h
+@@ -680,7 +680,7 @@
+ #define HAVE_CFNETWORK_STORAGE_PARTITIONING 1
+ #endif
+ 
+-#if OS(DARWIN) || ((OS(FREEBSD) || defined(__GLIBC__)) && (CPU(X86) || 
CPU(X86_64) || CPU(ARM) || CPU(ARM64) || CPU(MIPS)))
++#if OS(DARWIN) || 

[OE-core] ✗ patchtest: failure for Record PE value for shlib dependencies (rev2)

[Patchwork]

== Series Details ==

Series: Record PE value for shlib dependencies (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/10497/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch[rocko] Record PE value for shlib dependencies
 Issue Shortlog does not follow expected format 
[test_shortlog_format] 
  Suggested fixCommit shortlog (first line of commit message) should follow 
the format ": "



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] ✗ patchtest: failure for Record PE value for shlib dependencies

[Patchwork]

== Series Details ==

Series: Record PE value for shlib dependencies
Revision: 1
URL   : https://patchwork.openembedded.org/series/10497/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* PatchRecord PE value for shlib dependencies
 Issue Shortlog does not follow expected format 
[test_shortlog_format] 
  Suggested fixCommit shortlog (first line of commit message) should follow 
the format ": "



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [morty][PATCH] kernel.bbclass: Fix symlink creation when using externalsrc

[Stefan Stanacar]

do_unpack is by default in SRCTREECOVEREDTASKS so this append can't run, since
this tasks gets removed by externalsrc when it's enabled.

However this was hidden because externalsrc does run do_fetch and do_unpack if
there are type=kmeta or file:// entries in the SRC_URI value of the kernel 
recipe.
(e.g linux-yocto).

Make this a separate task so that it actually gets run for kernel recipes with
no file:// or type=kmeta in SRC_URI.

Signed-off-by: Stefan Stanacar 
---
 meta/classes/kernel.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index f8318b8..3eaae03 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -102,7 +102,7 @@ inherit ${KERNEL_CLASSES}
 # the symlink.
 do_unpack[cleandirs] += " ${S} ${STAGING_KERNEL_DIR} ${B} 
${STAGING_KERNEL_BUILDDIR}"
 do_clean[cleandirs] += " ${S} ${STAGING_KERNEL_DIR} ${B} 
${STAGING_KERNEL_BUILDDIR}"
-base_do_unpack_append () {
+python do_symlink_staging_dir () {
 s = d.getVar("S", True)
 if s[-1] == '/':
 # drop trailing slash, so that os.symlink(kernsrc, s) doesn't use s as 
directory name and fail
@@ -119,6 +119,8 @@ base_do_unpack_append () {
 shutil.move(s, kernsrc)
 os.symlink(kernsrc, s)
 }
+addtask do_symlink_staging_dir after do_unpack before do_patch do_configure
+
 
 inherit kernel-arch deploy
 
-- 
2.7.4

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

[OE-core] [morty][PATCH] kernelsrc/perf: fix dependency on non existant task when using externalsrc

[Stefan Stanacar]

When externalsrc is enabled for kernel, do_patch doesn't exist since is in
SRCTREECOVEREDTASKS, so make these depend on a real task.

Fixes:
ERROR: Task do_unpack in /data/yocto/poky/meta/recipes-kernel/perf/perf.bb
depends upon non-existent task do_patch in 
/data/yocto/poky/meta/recipes-kernel/linux/linux-yocto_4.8.bb

Signed-off-by: Stefan Stanacar 
---
 meta/classes/kernelsrc.bbclass   | 2 +-
 meta/recipes-kernel/perf/perf.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernelsrc.bbclass b/meta/classes/kernelsrc.bbclass
index 9efd46a..ce6c999 100644
--- a/meta/classes/kernelsrc.bbclass
+++ b/meta/classes/kernelsrc.bbclass
@@ -1,6 +1,6 @@
 S = "${STAGING_KERNEL_DIR}"
 do_fetch[noexec] = "1"
-do_unpack[depends] += "virtual/kernel:do_patch"
+do_unpack[depends] += "virtual/kernel:do_configure"
 do_unpack[noexec] = "1"
 do_patch[noexec] = "1"
 do_package[depends] += "virtual/kernel:do_populate_sysroot"
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 03ae446..145774b 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -47,7 +47,7 @@ export PYTHON_SITEPACKAGES_DIR
 #kernel 3.1+ supports WERROR to disable warnings as errors
 export WERROR = "0"
 
-do_populate_lic[depends] += "virtual/kernel:do_patch"
+do_populate_lic[depends] += "virtual/kernel:do_configure"
 
 # needed for building the tools/perf Perl binding
 inherit perlnative cpan-base
-- 
2.7.4

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

[OE-core] [rocko][PATCH] Record PE value for shlib dependencies

[Böszörményi Zoltán]

When downgrading a package or using a substitute with lower version,
the way to do it is adding or increasing PE. But it didn't help
dependant packages because the shlib records didn't contain PE, only PV.

Let's add the PE value into these records for packages where it's set.

The in-memory variables storing the versions use the PE:PV notation
but the on-disk files must use something else because the : character
is already used as field delimiter in the package.list files storing
these shlib records. Use # instead in the files, so the file format
doesn't change. Conversion occurs on reading/writing the package.list
files.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/package.bbclass | 6 +-
 meta/lib/oe/package.py   | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 2053d46395..8904b8091a 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1669,6 +1669,10 @@ python package_do_shlibs() {
 if not pkgver:
 pkgver = ver
 
+pkgpe = d.getVar('PE')
+if pkgpe:
+pkgver = pkgpe + ':' + pkgver
+
 needed[pkg] = []
 sonames = list()
 renames = list()
@@ -1697,7 +1701,7 @@ python package_do_shlibs() {
 if old_pkg != pkg:
 bb.warn('%s-%s was registered as shlib provider for 
%s, changing it to %s-%s because it was built later' % (old_pkg, old_pkgver, 
s[0], pkg, pkgver))
 bb.debug(1, 'registering %s-%s as shlib provider for %s' % 
(pkg, pkgver, s[0]))
-fd.write(s[0] + ':' + s[1] + ':' + s[2] + '\n')
+fd.write(s[0] + ':' + s[1] + ':' + s[2].replace(':', '#', 1) + 
'\n')
 if s[0] not in shlib_provider:
 shlib_provider[s[0]] = {}
 shlib_provider[s[0]][s[1]] = (pkg, pkgver)
diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 1e5c3aa8e1..d19fe7312d 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -258,7 +258,7 @@ def read_shlib_providers(d):
 s = l.strip().split(":")
 if s[0] not in shlib_provider:
 shlib_provider[s[0]] = {}
-shlib_provider[s[0]][s[1]] = (dep_pkg, s[2])
+shlib_provider[s[0]][s[1]] = (dep_pkg, s[2].replace('#', 
':', 1))
 return shlib_provider
 
 
-- 
2.14.3

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

[OE-core] [PATCH] Record PE value for shlib dependencies

[Böszörményi Zoltán]

When downgrading a package or using a substitute with lower version,
the way to do it is adding or increasing PE. But it didn't help
dependant packages because the shlib records didn't contain PE, only PV.

Let's add the PE value into these records for packages where it's set.

The in-memory variables storing the versions use the PE:PV notation
but the on-disk files must use something else because the : character
is already used as field delimiter in the package.list files storing
these shlib records. Use # instead in the files, so the file format
doesn't change. Conversion occurs on reading/writing the package.list
files.

Signed-off-by: Zoltán Böszörményi 
---
 meta/classes/package.bbclass | 6 +-
 meta/lib/oe/package.py   | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 7dc759699f..966c059851 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1686,6 +1686,10 @@ python package_do_shlibs() {
 if not pkgver:
 pkgver = ver
 
+pkgpe = d.getVar('PE')
+if pkgpe:
+pkgver = pkgpe + ':' + pkgver
+
 needed[pkg] = []
 sonames = list()
 renames = list()
@@ -1714,7 +1718,7 @@ python package_do_shlibs() {
 if old_pkg != pkg:
 bb.warn('%s-%s was registered as shlib provider for 
%s, changing it to %s-%s because it was built later' % (old_pkg, old_pkgver, 
s[0], pkg, pkgver))
 bb.debug(1, 'registering %s-%s as shlib provider for %s' % 
(pkg, pkgver, s[0]))
-fd.write(s[0] + ':' + s[1] + ':' + s[2] + '\n')
+fd.write(s[0] + ':' + s[1] + ':' + s[2].replace(':', '#', 1) + 
'\n')
 if s[0] not in shlib_provider:
 shlib_provider[s[0]] = {}
 shlib_provider[s[0]][s[1]] = (pkg, pkgver)
diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 1e5c3aa8e1..d19fe7312d 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -258,7 +258,7 @@ def read_shlib_providers(d):
 s = l.strip().split(":")
 if s[0] not in shlib_provider:
 shlib_provider[s[0]] = {}
-shlib_provider[s[0]][s[1]] = (dep_pkg, s[2])
+shlib_provider[s[0]][s[1]] = (dep_pkg, s[2].replace('#', 
':', 1))
 return shlib_provider
 
 
-- 
2.14.3

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

Re: [OE-core] [PATCH] image: use du --apparent-size when calculating rootfs size

[Alexander Kanavin]

On 01/11/2018 05:42 PM, Burton, Ross wrote:


Exactly same patch from Maxin caused failures previously, no?


Hm, I knew I remembered seeing this before, and found my patches from 
2015, but didn't see the ones from Maxin.  I'll dig the archives again.


http://lists.openembedded.org/pipermail/openembedded-core/2017-November/144748.html

You're welcome :)

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

Re: [OE-core] [PATCH] image: use du --apparent-size when calculating rootfs size

[Burton, Ross]

On 11 January 2018 at 15:42, Burton, Ross  wrote:

> Exactly same patch from Maxin caused failures previously, no?
>>
>
> Hm, I knew I remembered seeing this before, and found my patches from
> 2015, but didn't see the ones from Maxin.  I'll dig the archives again
>

Found it, bad search.  Lets see what happens on the AB this time...

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

Re: [OE-core] [PATCH] image: use du --apparent-size when calculating rootfs size

[Burton, Ross]

On 11 January 2018 at 15:29, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 01/11/2018 05:18 PM, Ross Burton wrote:
>
>> We should pass --apparent-size to du when calculating how large the
>> rootfs is as
>> otherwise we get the actual disk usage, which if the files are compressed
>> by the
>> file system (such as ZFS) may be sufficiently smaller than the space
>> required by
>> the image that construction will fail.
>>
>> Signed-off-by: Ross Burton 
>> ---
>>   meta/classes/image.bbclass | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
>> index 4531aa2a57a..8e763e4d543 100644
>> --- a/meta/classes/image.bbclass
>> +++ b/meta/classes/image.bbclass
>> @@ -534,6 +534,7 @@ def get_rootfs_size(d):
>>   initramfs_maxsize = d.getVar('INITRAMFS_MAXSIZE')
>> output = subprocess.check_output(['du', '-ks',
>> +  '--apparent-size',
>> d.getVar('IMAGE_ROOTFS')])
>>   size_kb = int(output.split()[0])
>>
>
> Exactly same patch from Maxin caused failures previously, no?
>

Hm, I knew I remembered seeing this before, and found my patches from 2015,
but didn't see the ones from Maxin.  I'll dig the archives again.

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

Re: [OE-core] [PATCH] image: use du --apparent-size when calculating rootfs size

[Alexander Kanavin]

On 01/11/2018 05:18 PM, Ross Burton wrote:

We should pass --apparent-size to du when calculating how large the rootfs is as
otherwise we get the actual disk usage, which if the files are compressed by the
file system (such as ZFS) may be sufficiently smaller than the space required by
the image that construction will fail.

Signed-off-by: Ross Burton 
---
  meta/classes/image.bbclass | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 4531aa2a57a..8e763e4d543 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -534,6 +534,7 @@ def get_rootfs_size(d):
  initramfs_maxsize = d.getVar('INITRAMFS_MAXSIZE')
  
  output = subprocess.check_output(['du', '-ks',

+  '--apparent-size',
d.getVar('IMAGE_ROOTFS')])
  size_kb = int(output.split()[0])


Exactly same patch from Maxin caused failures previously, no?

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

[OE-core] [PATCH] image: use du --apparent-size when calculating rootfs size

[Ross Burton]

We should pass --apparent-size to du when calculating how large the rootfs is as
otherwise we get the actual disk usage, which if the files are compressed by the
file system (such as ZFS) may be sufficiently smaller than the space required by
the image that construction will fail.

Signed-off-by: Ross Burton 
---
 meta/classes/image.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 4531aa2a57a..8e763e4d543 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -534,6 +534,7 @@ def get_rootfs_size(d):
 initramfs_maxsize = d.getVar('INITRAMFS_MAXSIZE')
 
 output = subprocess.check_output(['du', '-ks',
+  '--apparent-size',
   d.getVar('IMAGE_ROOTFS')])
 size_kb = int(output.split()[0])
 
-- 
2.11.0

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

Re: [OE-core] [PATCH] webkitgtk: update to 2.18.5 (includes Spectre mitigations; see commit description)

[Alexander Kanavin]

On 01/11/2018 05:00 PM, Alexander Kanavin wrote:

This is the only available stable version with mitigation fixes for Spectre.
Webkit upstream developers do not port CVE fixes to earlier stable series,
no exception was made in this case.


I will now establish whether it's feasible to update currently supported 
YP releases (rocko, pyro, morty) to this version.


Normally we don't do it (even though that leaves dozens of webkit CVEs 
unfixed), but this is special.


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

Re: [OE-core] [PATCH] gcc: add flex-native explicit dependency

[Denys Dmytriyenko]

On Thu, Jan 11, 2018 at 02:41:15PM +, Richard Purdie wrote:
> On Wed, 2018-01-10 at 22:15 -0500, Denys Dmytriyenko wrote:
> > From: Denys Dmytriyenko 
> > 
> > It seems flex is required to build gcc:
> > 
> > > 
> > > .../work-shared/gcc-7.2.0-r0/gcc-7.2.0/missing: line 81: flex:
> > > command not found
> > > WARNING: 'flex' is missing on your system.
> > >  You should only need it if you modified a '.l' file.
> > >  You may want to install the Fast Lexical Analyzer package:
> > >  
> > > Makefile:2799: recipe for target 'gengtype-lex.c' failed
> > > make[1]: [gengtype-lex.c] Error 127 (ignored)
> > Normally this is handled indirectly throught binutils-cross
> > dependency
> > pulling in flex-native implicitly. For deterministic builds, this
> > should
> > be specified explicitly.
> > 
> > Signed-off-by: Denys Dmytriyenko 
> > ---
> >  meta/recipes-devtools/gcc/gcc-7.2.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc b/meta/recipes-
> > devtools/gcc/gcc-7.2.inc
> > index 1d40cba..d1fb6de 100644
> > --- a/meta/recipes-devtools/gcc/gcc-7.2.inc
> > +++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
> > @@ -10,7 +10,7 @@ BINV = "7.2.0"
> >  
> >  FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc-7.2:${FILE_DIRNAME}/gcc-
> > 7.2/backport:"
> >  
> > -DEPENDS =+ "mpfr gmp libmpc zlib"
> > +DEPENDS =+ "mpfr gmp libmpc zlib flex-native"
> >  NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native"
> >  
> >  LICENSE = "GPL-3.0-with-GCC-exception & GPLv3"
> 
> Agreed, however I think we have bigger problems. I'm testing with this:
> 
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index 65f51430ee2..a5c4a73963e 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -921,6 +921,13 @@ def setscene_depvalid(task, taskdependees, notneeded, d, 
> log=None):
>  if taskdependees[task][1] == "do_stash_locale" or taskdependees[task][1] 
> == "do_gcc_stash_builddir":
>  return True
>  
> +
> +if taskdependees[task][1] == 'do_populate_sysroot':
> +if taskdependees[task][0] == "flex-native" or taskdependees[task][0] 
> == "bison-native":
> +#bb.warn("Skipping %s" % str(taskdependees[dep]))
> +bb.warn("Skipping")
> +return True
> +
>  # We only need to trigger packagedata through direct dependencies
>  # but need to preserve packagedata on packagedata links
>  if taskdependees[task][1] == "do_packagedata":
> 
> 
> and test results so far imply that we need:
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc 
> b/meta/recipes-devtools/gcc/gcc-7.2.inc
> index 1d40cba7317..90e4a990cb3 100644
> --- a/meta/recipes-devtools/gcc/gcc-7.2.inc
> +++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
> @@ -11,7 +11,7 @@ BINV = "7.2.0"
>  FILESEXTRAPATHS =. 
> "${FILE_DIRNAME}/gcc-7.2:${FILE_DIRNAME}/gcc-7.2/backport:"
>  
>  DEPENDS =+ "mpfr gmp libmpc zlib"
> -NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native"
> +NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native flex-native"
>  
>  LICENSE = "GPL-3.0-with-GCC-exception & GPLv3"
>  
> 
> probably in addition to your patch. I'll continue to run some test
> builds and see how much breakage the above change shows up.

Thanks. I was building native gcc for the target, while using external 
prebuilt cross toolchain. I first tried adding flex-native to NATIVEDEPS 
list, but that didn't help - looks like this list is only used for cross and 
crosssdk builds.

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

[OE-core] [PATCHv2 5/5] classes/populate_sdk_ext: support wic in eSDK

[rebecca . swee . fun . chang]

From: Chang Rebecca Swee Fun 

Make 'wic' image creation tool/command available in eSDK
environment. This would allow eSDK users to manipulate
images within eSDK environment.

[YOCTO #12177]

Signed-off-by: Chang Rebecca Swee Fun 
---
 meta/classes/populate_sdk_ext.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index eabc365300a..4f7100dd7e1 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -533,7 +533,7 @@ def get_sdk_required_utilities(buildtools_fn, d):
 
 install_tools() {
install -d ${SDK_OUTPUT}/${SDKPATHNATIVE}${bindir_nativesdk}
-   scripts="devtool recipetool oe-find-native-sysroot runqemu*"
+   scripts="devtool recipetool oe-find-native-sysroot runqemu* wic"
for script in $scripts; do
for scriptfn in `find ${SDK_OUTPUT}/${SDKPATH}/${scriptrelpath} 
-maxdepth 1 -executable -name "$script"`; do
lnr ${scriptfn} 
${SDK_OUTPUT}/${SDKPATHNATIVE}${bindir_nativesdk}/`basename $scriptfn`
-- 
2.15.0

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

[OE-core] [PATCHv2 4/5] scripts/wic: explicitly set BUILDDIR within eSDK

[rebecca . swee . fun . chang]

From: Chang Rebecca Swee Fun 

When we run wic within eSDK:
$ wic create mkefidisk -e core-image-minimal

ERROR: BUILDDIR not found, exiting. (Did you forget to source 
oe-init-build-env?)

In order to figure out variable values, one must have sourced
the OE build environment setup script. However, when we are in
within the eSDK environment which isn't initialised like the
normal OE build environment, we can't use wic utility with eSDK.

Reference:
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#wic-requirements

While wic ought to be fixed to be able to run without bitbake
& native tools [YOCTO #11281], but this is a workaround to set
BUILDDIR in the environment so that bitbake environment is setup
for wic to build its required native tools.

Signed-off-by: Chang Rebecca Swee Fun 
---
 scripts/wic | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/wic b/scripts/wic
index d9bea228ad5..7392bc4e7f4 100755
--- a/scripts/wic
+++ b/scripts/wic
@@ -51,6 +51,8 @@ sdkroot = scripts_path
 if os.environ.get('SDKTARGETSYSROOT'):
 while sdkroot != '' and sdkroot != os.sep:
 if os.path.exists(os.path.join(sdkroot, '.devtoolbase')):
+# Set BUILDDIR for wic to work within eSDK
+os.environ['BUILDDIR'] = sdkroot
 # .devtoolbase only exists within eSDK
 # If found, initialize bitbake path for eSDK environment and 
append to PATH
 sdkroot = os.path.join(os.path.dirname(scripts_path), 'bitbake', 
'bin')
-- 
2.15.0

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

[OE-core] [PATCHv2 3/5] scripts/wic: fix error of import wic module in eSDK environment

[rebecca . swee . fun . chang]

From: Chang Rebecca Swee Fun 

wic modules in scripts/lib/ are needed for wic to work, but path to
the python module is not exported in eSDK environment and we were
using an absolutized path of wic script within the sysroots.

We now changed to use real script path instead, where the wic modules
are located. This will also resolved the tracebacks found when running
wic from within the eSDK environment.

Traceback (most recent call last):
  File "/tmp/deploy/sdk/poky_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/wic", 
line 58, in 
from wic import WicError
ImportError: No module named 'wic'

Signed-off-by: Chang Rebecca Swee Fun 
---
 scripts/wic | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/wic b/scripts/wic
index 293a216d71d..d9bea228ad5 100755
--- a/scripts/wic
+++ b/scripts/wic
@@ -40,7 +40,7 @@ from collections import namedtuple
 from distutils import spawn
 
 # External modules
-scripts_path = os.path.abspath(os.path.dirname(__file__))
+scripts_path = os.path.dirname(os.path.realpath(__file__))
 lib_path = scripts_path + '/lib'
 sys.path.insert(0, lib_path)
 import scriptpath
-- 
2.15.0

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

[OE-core] [PATCHv2 2/5] scripts/wic: append bitbake executable file path in eSDK environment

[rebecca . swee . fun . chang]

From: Chang Rebecca Swee Fun 

wic needs a set of tools to be available from sysroots.
wic will find bitbake executable within the environment,
and wic was unable to locate bitbake executable within eSDK
because it wasn't setup with the OE build environment script.
Hence, we need to add bitbake file path into the environment
PATH for wic to be able to discover it and import bb modules.

Signed-off-by: Chang Rebecca Swee Fun 
---
 scripts/wic | 12 
 1 file changed, 12 insertions(+)

diff --git a/scripts/wic b/scripts/wic
index 0d988757150..293a216d71d 100755
--- a/scripts/wic
+++ b/scripts/wic
@@ -46,6 +46,18 @@ sys.path.insert(0, lib_path)
 import scriptpath
 scriptpath.add_oe_lib_path()
 
+# Check whether wic is running within eSDK environment
+sdkroot = scripts_path
+if os.environ.get('SDKTARGETSYSROOT'):
+while sdkroot != '' and sdkroot != os.sep:
+if os.path.exists(os.path.join(sdkroot, '.devtoolbase')):
+# .devtoolbase only exists within eSDK
+# If found, initialize bitbake path for eSDK environment and 
append to PATH
+sdkroot = os.path.join(os.path.dirname(scripts_path), 'bitbake', 
'bin')
+os.environ['PATH'] += ":" + sdkroot
+break
+sdkroot = os.path.dirname(sdkroot)
+
 bitbake_exe = spawn.find_executable('bitbake')
 if bitbake_exe:
 bitbake_path = scriptpath.add_bitbake_lib_path()
-- 
2.15.0

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

[OE-core] [PATCHv2 1/5] scripts/wic: use scriptpath module to find bitbake path and oe lib path

[rebecca . swee . fun . chang]

From: Chang Rebecca Swee Fun 

Use the scriptpath module in order to standardize the adding of
bitbake and meta/lib path to sys.path.

Signed-off-by: Chang Rebecca Swee Fun 
---
 scripts/wic | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/scripts/wic b/scripts/wic
index 097084a6033..0d988757150 100755
--- a/scripts/wic
+++ b/scripts/wic
@@ -43,13 +43,12 @@ from distutils import spawn
 scripts_path = os.path.abspath(os.path.dirname(__file__))
 lib_path = scripts_path + '/lib'
 sys.path.insert(0, lib_path)
-oe_lib_path = os.path.join(os.path.dirname(scripts_path), 'meta', 'lib')
-sys.path.insert(0, oe_lib_path)
+import scriptpath
+scriptpath.add_oe_lib_path()
 
 bitbake_exe = spawn.find_executable('bitbake')
 if bitbake_exe:
-bitbake_path = os.path.join(os.path.dirname(bitbake_exe), '../lib')
-sys.path.insert(0, bitbake_path)
+bitbake_path = scriptpath.add_bitbake_lib_path()
 from bb import cookerdata
 from bb.main import bitbake_main, BitBakeConfigParameters
 else:
-- 
2.15.0

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

[OE-core] [PATCHv2 0/5] Enable wic in eSDK

[rebecca . swee . fun . chang]

From: Chang Rebecca Swee Fun 

Hi all,

Resend as v2 as I realized an issue with BUILDDIR being set
was not correct. I made the correction on Patch 4 by setting
BUILDDIR to sdkroot variable (eSDK base path) before we alter
the variable for bitbake executable file path.

Regards,
Rebecca

-

Hi all,

As the subject called out: this patch series enable wic in eSDK.
The details of what I have done are documented within the commit message.
Basically wic requires an OE build environment, but we are using a
different environment setup script in eSDK. Hence, I have added some
code for wic to explicitly export bitbake variables within eSDK. I
have also make wic to use the shared code in scriptpath for oe lib
and bitbake path addition to sys.path.

I have run the changes on wic oe-selftest and the tests are passing.
What's next: I think it would better to have some test cases
for wic within eSDK if this series are merged.

Thanks.

Regards,
Rebecca


The following changes since commit 364f8bcfcbd04e722490f363ad36a15fb7066ba7:

  linux-firmware: Bump revision to 65b1c68c (2018-01-11 10:26:07 +)

are available in the Git repository at:

  git://push.yoctoproject.org/poky-contrib rebeccas/wic-dev

Chang Rebecca Swee Fun (5):
  scripts/wic: use scriptpath module to find bitbake path and oe lib
path
  scripts/wic: append bitbake executable file path in eSDK environment
  scripts/wic: fix error of import wic module in eSDK environment
  scripts/wic: explicitly set BUILDDIR within eSDK
  classes/populate_sdk_ext: support wic in eSDK

 meta/classes/populate_sdk_ext.bbclass |  2 +-
 scripts/wic   | 23 ++-
 2 files changed, 19 insertions(+), 6 deletions(-)

-- 
2.15.0

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

[OE-core] [PATCH] webkitgtk: update to 2.18.5 (includes Spectre mitigations; see commit description)

[Alexander Kanavin]

This is the only available stable version with mitigation fixes for Spectre.
Webkit upstream developers do not port CVE fixes to earlier stable series,
no exception was made in this case.

More information:

https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/
https://webkitgtk.org/security/WSA-2018-0001.html
https://webkitgtk.org/2018/01/10/webkitgtk2.18.5-released.html

Signed-off-by: Alexander Kanavin 
---
 ...ak-gtkdoc-settings-so-that-gtkdoc-generation-work.patch | 14 +++---
 .../webkit/{webkitgtk_2.18.3.bb => webkitgtk_2.18.5.bb}|  4 ++--
 2 files changed, 9 insertions(+), 9 deletions(-)
 rename meta/recipes-sato/webkit/{webkitgtk_2.18.3.bb => webkitgtk_2.18.5.bb} 
(97%)

diff --git 
a/meta/recipes-sato/webkit/webkitgtk/0001-Tweak-gtkdoc-settings-so-that-gtkdoc-generation-work.patch
 
b/meta/recipes-sato/webkit/webkitgtk/0001-Tweak-gtkdoc-settings-so-that-gtkdoc-generation-work.patch
index e1b69b2a214..83fd5129a01 100644
--- 
a/meta/recipes-sato/webkit/webkitgtk/0001-Tweak-gtkdoc-settings-so-that-gtkdoc-generation-work.patch
+++ 
b/meta/recipes-sato/webkit/webkitgtk/0001-Tweak-gtkdoc-settings-so-that-gtkdoc-generation-work.patch
@@ -1,7 +1,7 @@
-From 3cc0e5900515cbcedd0447e0bdf487cc8d9a0f8c Mon Sep 17 00:00:00 2001
+From 9b09974003097c9a408bbeea568996768efe705b Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin 
 Date: Thu, 11 Aug 2016 17:13:51 +0300
-Subject: [PATCH 5/9] Tweak gtkdoc settings so that gtkdoc generation works
+Subject: [PATCH 05/10] Tweak gtkdoc settings so that gtkdoc generation works
  under OpenEmbedded build system
 
 This requires setting a few environment variables so that the transient
@@ -17,7 +17,7 @@ Signed-off-by: Alexander Kanavin 
  2 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/Source/PlatformGTK.cmake b/Source/PlatformGTK.cmake
-index 50b5393f..7a31db51 100644
+index 50b5393..7a31db5 100644
 --- a/Source/PlatformGTK.cmake
 +++ b/Source/PlatformGTK.cmake
 @@ -24,7 +24,7 @@ macro(ADD_GTKDOC_GENERATOR _stamp_name _extra_args)
@@ -30,7 +30,7 @@ index 50b5393f..7a31db51 100644
  WORKING_DIRECTORY "${CMAKE_BINARY_DIR}"
  VERBATIM
 diff --git a/Tools/gtk/gtkdoc.py b/Tools/gtk/gtkdoc.py
-index 48f862a3..18240e42 100644
+index 03c8e8e..34fbaff 100644
 --- a/Tools/gtk/gtkdoc.py
 +++ b/Tools/gtk/gtkdoc.py
 @@ -318,9 +318,9 @@ class GTKDoc(object):
@@ -39,12 +39,12 @@ index 48f862a3..18240e42 100644
  current_ld_library_path = env.get('LD_LIBRARY_PATH')
 -if current_ld_library_path:
 +if current_ld_library_path and 'RUN' not in env:
- env['RUN'] = 'LD_LIBRARY_PATH="%s:%s" ' % (self.library_path, 
current_ld_library_path)
+ env['LD_LIBRARY_PATH'] = '%s:%s' % (self.library_path, 
current_ld_library_path)
 -else:
 +elif 'RUN' not in env:
- env['RUN'] = 'LD_LIBRARY_PATH="%s" ' % self.library_path
+ env['LD_LIBRARY_PATH'] = self.library_path
  
  if ldflags:
 -- 
-2.14.1
+2.15.1
 
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.18.3.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.18.5.bb
similarity index 97%
rename from meta/recipes-sato/webkit/webkitgtk_2.18.3.bb
rename to meta/recipes-sato/webkit/webkitgtk_2.18.5.bb
index 4938f69b7b6..a64aee22e68 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.18.3.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.18.5.bb
@@ -22,8 +22,8 @@ SRC_URI = 
"http://www.webkitgtk.org/releases/${BPN}-${PV}.tar.xz \
file://0001-Fix-build-with-musl.patch \
"
 
-SRC_URI[md5sum] = "264a22d7467deae606e42b6eb5dd65af"
-SRC_URI[sha256sum] = 
"e15420e1616a6f70f321541d467af5ca285bff66b1e0fa68a01df3ccf1b18f9e"
+SRC_URI[md5sum] = "af18c2cfa00cadfd0b4d8db21cab011d"
+SRC_URI[sha256sum] = 
"0c6d80cc7eb5d32f8063041fa11a1a6f17a29765c2f69c6bc862cd47c2d539b8"
 
 inherit cmake pkgconfig gobject-introspection perlnative distro_features_check 
upstream-version-is-even gtk-doc
 
-- 
2.15.1

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

Re: [OE-core] [PATCH] gcc: add flex-native explicit dependency

[Richard Purdie]

On Wed, 2018-01-10 at 22:15 -0500, Denys Dmytriyenko wrote:
> From: Denys Dmytriyenko 
> 
> It seems flex is required to build gcc:
> 
> > 
> > .../work-shared/gcc-7.2.0-r0/gcc-7.2.0/missing: line 81: flex:
> > command not found
> > WARNING: 'flex' is missing on your system.
> >  You should only need it if you modified a '.l' file.
> >  You may want to install the Fast Lexical Analyzer package:
> >  
> > Makefile:2799: recipe for target 'gengtype-lex.c' failed
> > make[1]: [gengtype-lex.c] Error 127 (ignored)
> Normally this is handled indirectly throught binutils-cross
> dependency
> pulling in flex-native implicitly. For deterministic builds, this
> should
> be specified explicitly.
> 
> Signed-off-by: Denys Dmytriyenko 
> ---
>  meta/recipes-devtools/gcc/gcc-7.2.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc b/meta/recipes-
> devtools/gcc/gcc-7.2.inc
> index 1d40cba..d1fb6de 100644
> --- a/meta/recipes-devtools/gcc/gcc-7.2.inc
> +++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
> @@ -10,7 +10,7 @@ BINV = "7.2.0"
>  
>  FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc-7.2:${FILE_DIRNAME}/gcc-
> 7.2/backport:"
>  
> -DEPENDS =+ "mpfr gmp libmpc zlib"
> +DEPENDS =+ "mpfr gmp libmpc zlib flex-native"
>  NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native"
>  
>  LICENSE = "GPL-3.0-with-GCC-exception & GPLv3"

Agreed, however I think we have bigger problems. I'm testing with this:

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 65f51430ee2..a5c4a73963e 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -921,6 +921,13 @@ def setscene_depvalid(task, taskdependees, notneeded, d, 
log=None):
 if taskdependees[task][1] == "do_stash_locale" or taskdependees[task][1] 
== "do_gcc_stash_builddir":
 return True
 
+
+if taskdependees[task][1] == 'do_populate_sysroot':
+if taskdependees[task][0] == "flex-native" or taskdependees[task][0] 
== "bison-native":
+#bb.warn("Skipping %s" % str(taskdependees[dep]))
+bb.warn("Skipping")
+return True
+
 # We only need to trigger packagedata through direct dependencies
 # but need to preserve packagedata on packagedata links
 if taskdependees[task][1] == "do_packagedata":


and test results so far imply that we need:

diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc 
b/meta/recipes-devtools/gcc/gcc-7.2.inc
index 1d40cba7317..90e4a990cb3 100644
--- a/meta/recipes-devtools/gcc/gcc-7.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
@@ -11,7 +11,7 @@ BINV = "7.2.0"
 FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc-7.2:${FILE_DIRNAME}/gcc-7.2/backport:"
 
 DEPENDS =+ "mpfr gmp libmpc zlib"
-NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native"
+NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native flex-native"
 
 LICENSE = "GPL-3.0-with-GCC-exception & GPLv3"
 

probably in addition to your patch. I'll continue to run some test
builds and see how much breakage the above change shows up.

Cheers,

Richard





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

Re: [OE-core] [PATCH 4/4] gnupg: use native version for signing, rather than one provided by host

[Yang, Zhangle (Eric)]

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

Re: [OE-core] [PATCH] tune-i686: Add new tune for better support of 686-class CPUs.

[Carlos Alberto Lopez Perez]

On 11/01/18 11:29, Richard Purdie wrote:
> On Thu, 2018-01-11 at 05:08 +0100, Carlos Alberto Lopez Perez wrote:
>> There isn't currently any tune available for i686 x86 optimizations.
>> The tune for i586 doesn't enable i686 specific optimizations, and the
>> one for core2 enables things that won't work on a i686 CPU (like
>> SSE3).
>>
>> This patch also changes the default tune for the qemux86 machine from
>> i586 to i686. This should cause no issue, as "runqemu qemux86"
>> already
>> defaults to run with "-cpu pentium2".
>>
>> The tune for core2 now inherits from this one, which allows to remove
>> the override on the X86ARCH32 definition.
>>
>> Signed-off-by: Carlos Alberto Lopez Perez 
>> ---
>>  meta/conf/machine/include/tune-core2.inc |  7 ++-
>>  meta/conf/machine/include/tune-i686.inc  | 25
>> +
>>  meta/conf/machine/qemux86.conf   |  2 +-
>>  3 files changed, 28 insertions(+), 6 deletions(-)
>>  create mode 100644 meta/conf/machine/include/tune-i686.inc
> 
> Please don't do multiple things in a single commit like this.
> 
> The qemux86 default tune change isn't as simple as it might first
> appear as it changes the output artefacts which may or may not mean
> changes to the testing infrastructure (I'd hope not but I also know the
> reality).
> 
> Adding the tune itself should be more straightforward.
> > We do need to keep track of the comment "Set x86 target arch to i686,
> so that glibc enables SSE optimised memcpy, etc." as i586 verses i686
> does make a significant difference to the glibc config.
> 

Sure, I will keep track of the comment. I'll follow-up with a new patch.

Due to this significant difference in performance for glibc, it seems to
me it is worth to try the change on the default tune on qemux68 machine.
Hopefully it will speed-up a bit the testing times both on the testing
architecture and the developer machines.
Will splitting the patch in two will help with this?



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v9 00/14] support profile-optimized build for Python

[Markus Lehtonen]

Changes since v8:
- rebased onto latest master
- fixed a logger naming mistake in python-pgo-image.bb - this mistake caused
  the targetrunner logs not to be printed at all


The following changes since commit e9dfe7eb7f61b909ae7d034e80cfbebc1fad018b:

  icu-dbg: improve reproducibility (2018-01-08 08:45:33 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib marquiz/fixes-9338
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=marquiz/fixes-9338

Markus Lehtonen (14):
  python3-native: support profile optimized build
  python3: fix depends of python3-tests
  python3: add python3-profile-opt recipe
  python3-profile-opt: rename libpython3
  openssh: extend to -native
  iptables: enable native
  iproute2: enable native
  oeqa/targetcontrol: re-introduce get_target_controller()
  oeqa/targetcontrol: add missing arg to SimpleRemoteTarget.__init__
  devtools/images: add python-pgo-image
  python3: support profile optimized build
  python3: fix profile-optimized build of modules
  python3: add python3-tools subpackage
  oeqa: add selftest for python pgo

 meta/lib/oeqa/selftest/cases/python.py |  28 ++
 meta/lib/oeqa/targetcontrol.py |  29 +-
 meta/recipes-connectivity/iproute2/iproute2.inc|   7 +-
 ...1-don-t-use-absolute-path-for-ssh-program.patch |  31 ++
 meta/recipes-connectivity/openssh/openssh_7.6p1.bb |   8 +-
 meta/recipes-devtools/images/python-pgo-image.bb   |  92 ++
 .../python/python-3.5-manifest.inc |  13 ++-
 .../python/python3-native_3.5.3.bb |   9 ++
 meta/recipes-devtools/python/python3-profile-opt   |   1 +
 .../python/python3-profile-opt_3.5.3.bb|  10 ++
 .../python3/0001-cross-compile-support.patch   |   9 --
 ...efile-add-install_generate_profile-target.patch |  25 +
 ...-CFLAGS-for-extensions-when-cross-compili.patch |  56 +++
 ...name-libpython3-to-libpython-profile-opt3.patch | 108 +
 meta/recipes-devtools/python/python3_3.5.3.bb  |  56 ---
 ...revent-absolute-path-in-installed-symlink.patch |  29 ++
 meta/recipes-extended/iptables/iptables_1.6.1.bb   |   3 +
 scripts/contrib/python/generate-manifest-3.5.py|   5 +-
 18 files changed, 489 insertions(+), 30 deletions(-)
 create mode 100644 meta/lib/oeqa/selftest/cases/python.py
 create mode 100644 
meta/recipes-connectivity/openssh/openssh/0001-don-t-use-absolute-path-for-ssh-program.patch
 create mode 100644 meta/recipes-devtools/images/python-pgo-image.bb
 create mode 12 meta/recipes-devtools/python/python3-profile-opt
 create mode 100644 meta/recipes-devtools/python/python3-profile-opt_3.5.3.bb
 create mode 100644 
meta/recipes-devtools/python/python3/Makefile-add-install_generate_profile-target.patch
 create mode 100644 
meta/recipes-devtools/python/python3/Use-correct-CFLAGS-for-extensions-when-cross-compili.patch
 create mode 100644 
meta/recipes-devtools/python/python3/rename-libpython3-to-libpython-profile-opt3.patch
 create mode 100644 
meta/recipes-extended/iptables/iptables/prevent-absolute-path-in-installed-symlink.patch

-- 
2.13.6

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

Re: [OE-core] [PATCH 2/9] gnomebase-meson.bbclass: add a meson-specific version

[Alexander Kanavin]

On 01/10/2018 09:11 PM, Martin Kelly wrote:
Yes, to be clear, I'm not griping, as I'm very happy meson landed in 
OE-core, and I'm working on SDK support now. I have an OE-core thread 
going with meson upstream to get the issue fixed.


To be clear though, I'm not sure it even regressed. AFAICT, it never 
quite worked.


Where would I add SDK tests for this?


meta/lib/oeqa/selftest/cases is the place. Not sure what existing SDK 
tests are already there.



Alex

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

Re: [OE-core] [PATCH 4/4] gnupg: use native version for signing, rather than one provided by host

[Alexander Kanavin]

On 01/10/2018 05:01 PM, Leonardo Sandoval wrote:

Great that you figure out a solution.

So I belive we need to revert this commit:

commit 043d9ac0ae441e9a7e2ea8934bfc595a03ef9a52
Author: Leonardo Sandoval 
Date:   Mon Sep 25 13:52:59 2017 -0700

 sign_rpm.bbclass: force rpm serial signing


The revert is already included in the patch... :)

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

Re: [OE-core] [PATCH] tune-i686: Add new tune for better support of 686-class CPUs.

[Richard Purdie]

On Thu, 2018-01-11 at 05:08 +0100, Carlos Alberto Lopez Perez wrote:
> There isn't currently any tune available for i686 x86 optimizations.
> The tune for i586 doesn't enable i686 specific optimizations, and the
> one for core2 enables things that won't work on a i686 CPU (like
> SSE3).
> 
> This patch also changes the default tune for the qemux86 machine from
> i586 to i686. This should cause no issue, as "runqemu qemux86"
> already
> defaults to run with "-cpu pentium2".
> 
> The tune for core2 now inherits from this one, which allows to remove
> the override on the X86ARCH32 definition.
> 
> Signed-off-by: Carlos Alberto Lopez Perez 
> ---
>  meta/conf/machine/include/tune-core2.inc |  7 ++-
>  meta/conf/machine/include/tune-i686.inc  | 25
> +
>  meta/conf/machine/qemux86.conf   |  2 +-
>  3 files changed, 28 insertions(+), 6 deletions(-)
>  create mode 100644 meta/conf/machine/include/tune-i686.inc

Please don't do multiple things in a single commit like this.

The qemux86 default tune change isn't as simple as it might first
appear as it changes the output artefacts which may or may not mean
changes to the testing infrastructure (I'd hope not but I also know the
reality).

Adding the tune itself should be more straightforward.

We do need to keep track of the comment "Set x86 target arch to i686,
so that glibc enables SSE optimised memcpy, etc." as i586 verses i686
does make a significant difference to the glibc config.

Cheers,

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