Re: [OE-core] [PATCH] openssh: Remove deprecated sshd option

[Gary Thomas]

On 2017-05-18 11:09, Gary Thomas wrote:

The UsePrivilegeSeparation is no longer supported (recent SSHD always runs
with previlege separation), so remove this option from the default config
file to avoid this warning:
   /etc/ssh/sshd_config line 110: Deprecated option UsePrivilegeSeparation

Signed-off-by: Gary Thomas <g...@mlbassoc.com>
---
  meta/recipes-connectivity/openssh/openssh/sshd_config | 1 -
  1 file changed, 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssh/openssh/sshd_config 
b/meta/recipes-connectivity/openssh/openssh/sshd_config
index d48bd2b..31fe5d9 100644
--- a/meta/recipes-connectivity/openssh/openssh/sshd_config
+++ b/meta/recipes-connectivity/openssh/openssh/sshd_config
@@ -107,7 +107,6 @@ ChallengeResponseAuthentication no
  #PrintLastLog yes
  #TCPKeepAlive yes
  #UseLogin no
-UsePrivilegeSeparation sandbox # Default for new installations.
  #PermitUserEnvironment no
  Compression no
  ClientAliveInterval 15



Ping?  (It's been more than a month!)

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [RFC] u-boot-fw-utils: Allow target-specific fw_env.config

[Gary Thomas]

On 2017-06-21 07:22, Denys Dmytriyenko wrote:

On Tue, Jun 20, 2017 at 09:33:24PM -0500, Brad Mouring wrote:

On Tue, Jun 20, 2017 at 10:59:55PM +0200, Marek Vasut wrote:

On 06/20/2017 10:53 PM, Brad Mouring wrote:

On Tue, Jun 20, 2017 at 10:43:51PM +0200, Marek Vasut wrote:

On 06/20/2017 10:40 PM, Brad Mouring wrote:

As implemented currently, the fw-utils recipe does not allow for
...
+# by the U-Boot environment utilities "fw_printenv" and "fw_setenv".
+# By default, use the default included in the U-Boot source
+UBOOT_FW_ENV_CONFIG ??= "${S}/tools/env/fw_env.config"
+
  inherit uboot-config
  
  do_compile () {

@@ -19,7 +24,7 @@ do_install () {
install -d ${D}${sysconfdir}
install -m 755 ${S}/tools/env/fw_printenv 
${D}${base_sbindir}/fw_printenv
install -m 755 ${S}/tools/env/fw_printenv ${D}${base_sbindir}/fw_setenv
-   install -m 0644 ${S}/tools/env/fw_env.config 
${D}${sysconfdir}/fw_env.config
+   install -m 0644 ${UBOOT_FW_ENV_CONFIG} ${D}${sysconfdir}/fw_env.config


Do we really need yet another variable ? Wouldn't it make more sense to
add do_install_append_yourmachine() {} in your meta-whatever to
u-boot-fw-utils_%.bbappend and install whatever additional files you need ?


This is (kinda) what we were doing, there was some discussion as to
whether or not this made sense upstream.


Link?


I know it's not a great answer, but we've not pushed the version of the
branch where these changes are going in. Eventually, they'll end up in
this repo:

https://github.com/ni/meta-nilrt


I was unsure of the
acceptability of a do_install_append.*() clobbering a file of the
original do_install().


That's probably what really needs to be discussed.

We can probably add some task which by default installs the
fw_env.config example and can be overridden in meta-whatever . Maybe the
others can jump into here and explain how to handle overriding the
default config file best.


That sounds like a solution that would certainly work for this
use-case, if no one pipes up with objections or a currently-unseen
silver bullet solution, I'll try to whip something together tomorrow
and post. Thanks for the idea.

Denys, I know you keep pushing the "shove it in a do_install_append()",
but to me and my under-informed sensibilities, this seems weird and
unclean to clobber a file in a _append(), would it cause some QA failure?


Hmm, I mentioned it only once... To a patch that does already mention
appending stuff...



We do this all the time for this recipe.  It just takes a simple .bbappend
like this one.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://fw_env.config \
"

do_install_append() {
   install -d ${D}${sysconfdir}
   install -m 0644 ${WORKDIR}/fw_env.config ${D}${sysconfdir}/fw_env.config   
}

PACKAGE_ARCH = "${MACHINE_ARCH}"
COMPATIBLE_MACHINE = "${MACHINE}"

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

Re: [OE-core] [PATCH 01/11] gtk+3: Update the patches to work without PATCHTOOL = "git"

[Gary Thomas]

On 2017-06-15 16:18, Alexander Kanavin wrote:

On 06/15/2017 05:11 PM, Peter Kjellerstedt wrote:


My apologies, but I do not think this is a satisfactory answer: it may
mean you are fixing the wrong problem, or a problem that does not
exist.

Alex


Well, I am pretty sure Git patches that rename files are not supposed
to be used, since quilt does not support this AFAIK. So the change in
this patch should be correct.

However, I would be more than happy if anyone can explain why others
are not seeing this (or does everyone have PATCHTOOL = "git" in their
configurations somehow?)


This is unlikely; I certainly don't. Perhaps if you provide the exact command that is being executed, and what is the 
error it prints, I could try to do the same?

By default (i.e. nothing special in my local.conf), I have
  PATCHTOOL = "quilt"

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH 1/3] pseudo: Handle too many files deadlock

[Gary Thomas]

On 2017-06-14 15:42, Richard Purdie wrote:

If we have large amounts of parallelism, pseudo can end up with too
many open connections and will no longer accept further connections,
hanging. This patch works around that by closing some clients, allowing
turnover of connections and unblocking the system. The downside is a small
but theoretical window of data loss. This is likely better than locking
up entirely though. Discussions with Peter are onging about how we could
better fix this.

Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
---
  .../pseudo/files/toomanyfiles.patch| 62 ++
  meta/recipes-devtools/pseudo/pseudo_1.8.2.bb   |  1 +
  2 files changed, 63 insertions(+)
  create mode 100644 meta/recipes-devtools/pseudo/files/toomanyfiles.patch

diff --git a/meta/recipes-devtools/pseudo/files/toomanyfiles.patch 
b/meta/recipes-devtools/pseudo/files/toomanyfiles.patch
new file mode 100644
index 000..14a8975
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/files/toomanyfiles.patch
@@ -0,0 +1,62 @@
+Currently if we max out the maximum number of files, pseudo can deadlock, 
unable to
+accept new connections yet unable to move forward and unblock the other 
processes
+waiting either.
+
+Rather than hang, when this happens, close out inactive connections, allowing 
us
+to accept the new ones. The disconnected clients will simply reconnect. There 
is
+a small risk of data loss here sadly but its better than hanging.
+
+RP
+2017/4/25
+
+Upstream-Status: Pending [Peter is aware of the issue]
+
+Index: pseudo-1.8.2/pseudo_server.c
+===
+--- pseudo-1.8.2.orig/pseudo_server.c
 pseudo-1.8.2/pseudo_server.c
+@@ -581,6 +581,7 @@ pseudo_server_loop(void) {
+   int rc;
+   int fd;
+   int loop_timeout = pseudo_server_timeout;
++  int hitmaxfiles;
+
+   clients = malloc(16 * sizeof(*clients));
+
+@@ -597,6 +598,7 @@ pseudo_server_loop(void) {
+   active_clients = 1;
+   max_clients = 16;
+   highest_client = 0;
++  hitmaxfiles = 0;
+
+   pseudo_debug(PDBGF_SERVER, "server loop started.\n");
+   if (listen_fd < 0) {
+@@ -663,10 +665,18 @@ pseudo_server_loop(void) {
+   message_time.tv_usec -= 100;
+   ++message_time.tv_sec;
+   }
++  } else if (hitmaxfiles) {
++  /* In theory there is a potential race 
here where if we close a client,
++ it may have sent us a fastop message 
which we don't act upon.
++ If we don't close a filehandle we'll 
loop indefinitely thought.
++ Only close one per loop iteration in 
the interests of caution */
++  close_client(i);
++  histmaxfiles = 0;


Typo?  s/histmaxfiles/hitmaxfiles/


+   }
+   if (die_forcefully)
+   break;
+   }
++  hitmaxfiles = 0;
+   if (!die_forcefully &&
+   (FD_ISSET(clients[0].fd, ) ||
+FD_ISSET(clients[0].fd, ))) {
+@@ -688,6 +698,9 @@ pseudo_server_loop(void) {
+  */
+ pseudo_server_timeout = 
DEFAULT_PSEUDO_SERVER_TIMEOUT;
+ die_peacefully = 0;
++  } else if (errno == EMFILE) {
++  hitmaxfiles = 1;
++  pseudo_debug(PDBGF_SERVER, "Hit max open 
files, dropping a client.\n");
+   }
+   }
+   pseudo_debug(PDBGF_SERVER, "server loop complete [%d clients 
left]\n", active_clients);
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb 
b/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb
index b427b9a..9bcd031 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb
@@ -7,6 +7,7 @@ SRC_URI = 
"http://downloads.yoctoproject.org/releases/pseudo/${BPN}-${PV}.tar.bz
 file://moreretries.patch \
 file://efe0be279901006f939cd357ccee47b651c786da.patch \
 file://b6b68db896f9963558334aff7fca61adde4ec10f.patch \
+   file://toomanyfiles.patch \
 "
  
  SRC_URI[md5sum] = "7d41e72188fbea1f696c399c1a435675"





--
----
Gary Thomas | 

[OE-core] [PATCH] openssh: Remove deprecated sshd option

[Gary Thomas]

The UsePrivilegeSeparation is no longer supported (recent SSHD always runs
with previlege separation), so remove this option from the default config
file to avoid this warning:
  /etc/ssh/sshd_config line 110: Deprecated option UsePrivilegeSeparation

Signed-off-by: Gary Thomas <g...@mlbassoc.com>
---
 meta/recipes-connectivity/openssh/openssh/sshd_config | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssh/openssh/sshd_config 
b/meta/recipes-connectivity/openssh/openssh/sshd_config
index d48bd2b..31fe5d9 100644
--- a/meta/recipes-connectivity/openssh/openssh/sshd_config
+++ b/meta/recipes-connectivity/openssh/openssh/sshd_config
@@ -107,7 +107,6 @@ ChallengeResponseAuthentication no
 #PrintLastLog yes
 #TCPKeepAlive yes
 #UseLogin no
-UsePrivilegeSeparation sandbox # Default for new installations.
 #PermitUserEnvironment no
 Compression no
 ClientAliveInterval 15
-- 
2.7.4

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

Re: [OE-core] [PATCH] curl: fix error for ARMv8 32BE

[Gary Thomas]

On 2017-05-17 09:37, Huang Qiyu wrote:

curl + gnutls can not work on ARMv8 32BE, so change it to curl + ssl.

Signed-off-by: Huang Qiyu <huangqy.f...@cn.fujitsu.com>
---
 meta/recipes-support/curl/curl_7.54.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/curl/curl_7.54.0.bb 
b/meta/recipes-support/curl/curl_7.54.0.bb
index ce5ca37..2c0a395 100644
--- a/meta/recipes-support/curl/curl_7.54.0.bb
+++ b/meta/recipes-support/curl/curl_7.54.0.bb
@@ -20,7 +20,7 @@ SRC_URI[sha256sum] = 
"f50ebaf43c507fa7cc32be4b8108fa8bbd0f5022e90794388f3c7694a3
 CVE_PRODUCT = "libcurl"
 inherit autotools pkgconfig binconfig multilib_header

-PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} gnutls proxy 
zlib"
+PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} ssl proxy 
zlib"
 PACKAGECONFIG_class-native = "ipv6 proxy ssl zlib"
 PACKAGECONFIG_class-nativesdk = "ipv6 proxy ssl zlib"



This seems like a pretty big change and affects all targets,
not just ARMv8/BE

Maybe ssl vs gnutls should be a PACKAGECONFIG option of its own with an
override for just ARMv8/BE?


--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1

[Gary Thomas]

On 2017-05-10 17:38, Alexander Kanavin wrote:

On 05/10/2017 06:34 PM, Davis, Michael wrote:

Sitting on 2.3 wouldn't be too much an issue for me, but I can't speak for 
others that may be in the same situation.
Do these patches / new versions require 1.1.0 or break backwards compatibility 
with 1.0.2?
It would be nice if it could be handled by the 
PREFFERED_VERSION/PREFERRERED_PROVIDER.


PREFERRED_ thing is not possible, unfortunately. 1.1 is API incompatible with 
1.0, and so both need to be provided at
the same time, with recipes explicitly telling which one they need. Most of the 
patchset is moving various recipes to
newer, 1.1 compatible versions, so we minimize the need for 1.0.

1.0 will be provided for as long as upstream supports it, which should be 
another two years or so.


Why not do this in a "softer" way - make the new 1.1 package have the
obscured name (and not be preferred by default)?  That way existing
uses of the older 1.0 package can continue but users can migrate to
1.1 as they see fit?

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] python3: Use _sysconfigdata.py to initialize distutils.sysconfig

[Gary Thomas]

1000110.patch \
 file://upstream-random-fixes.patch \
+
file://0001-Issue-21272-Use-_sysconfigdata.py-to-initialize-dist.patch \
"
 SRC_URI[md5sum] = "8906efbacfcdc7c3c9198aeefafd159e"
 SRC_URI[sha256sum] = 
"0010f56100b9b74259ebcd5d4b295a32324b58b517403a10d1a2aa7cb22bca40"
--
1.9.1

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




--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its 
end"





--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH 1/1] wic: improve error message

[Gary Thomas]

On 2017-03-30 10:37, Chen Qi wrote:

When using `wic create mkefidisk -e core-image-minimal', the following
error message appeared.

  Please bake it with 'bitbake parted-native' and try again.

However, following this command doesn't do any help. The same problem
still appeared.

The problem is that when we 'bitbake parted-native', it doesn't have
anything to do with core-image-minimal. And the required tool 'parted'
is not under core-image-minimal's recipe-sysroot-native directory.

Improve the error message so that following it could get things done.


Why not just fix the wic-tools recipe directly and not push it off onto the 
user?



Signed-off-by: Chen Qi <qi.c...@windriver.com>
---
 scripts/lib/wic/utils/misc.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/utils/misc.py b/scripts/lib/wic/utils/misc.py
index c941112..1b0ab3b 100644
--- a/scripts/lib/wic/utils/misc.py
+++ b/scripts/lib/wic/utils/misc.py
@@ -131,7 +131,7 @@ def exec_native_cmd(cmd_and_args, native_sysroot, catch=3, 
pseudo=""):
   "was not found (see details above).\n\n" % prog
 recipe = NATIVE_RECIPES.get(prog)
 if recipe:
-msg += "Please bake it with 'bitbake %s-native' "\
+msg += "Please make sure wic-tools have %s-native in its DEPENDS, bake 
it with 'bitbake wic-tools' "\
"and try again.\n" % recipe
 else:
 msg += "Wic failed to find a recipe to build native %s. Please "\




--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Error after updating Poky

[Gary Thomas]

On 2017-03-20 13:58, Burton, Ross wrote:


On 20 March 2017 at 12:50, Gary Thomas <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:

Thanks, that did fix it.

I see that those recipe-sysroot* trees are kept around (I don't run rm_work)
For one of my builds which has ~475 packages in tmp/work, they amount to 7GB
Is there any way to prune them?


It's all hardlinks, so be careful how you count.


I didn't realize that!  Thanks

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Error after updating Poky

[Gary Thomas]

On 2017-03-20 13:21, Patrick Ohly wrote:

On Mon, 2017-03-20 at 13:12 +0100, Gary Thomas wrote:

I just updated to the latest Poky master (7e0985bab68547) which
replaced rpm-5.4 with rpm-4.13.90 (git).  My builds in an existing
tree now fail:

|
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so:
file not recognized: File format not recognized
| collect2: error: ld returned 1 exit status
| ext/CMakeFiles/libsolvext.dir/build.make:285: recipe for target 
'ext/libsolvext.so.0' failed
| make[2]: *** [ext/libsolvext.so.0] Error 1
| make[2]: Leaving directory 
'/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/build'
| CMakeFiles/Makefile2:207: recipe for target 
'ext/CMakeFiles/libsolvext.dir/all' failed
| make[1]: *** [ext/CMakeFiles/libsolvext.dir/all] Error 2
| make[1]: Leaving directory 
'/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/build'
| Makefile:163: recipe for target 'all' failed
| make: *** [all] Error 2
| ERROR: Function failed: do_compile (log file is located at
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/temp/log.do_compile.8183)
ERROR: Task 
(/local/poky-cutting-edge/meta/recipes-extended/libsolv/libsolv_0.6.26.bb:do_compile)
 failed with exit code '1'

Looking at this file shows it's a stale symlink:
$ file
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so:
symbolic link to librpmdb-5.4.so
$ file `readlink
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so`
librpmdb-5.4.so: cannot open `librpmdb-5.4.so' (No such file or directory)

Any ideas how to fix this?


The code maintaining the recipe specific sysroots does not always keep
the sysroots in sync with what they should contain, primarily because it
is limited to updating them instead of (at least sometimes) starting
from scratch.

Probably a "bitbake -c clean libsolv && bitbake libsolv" will help in
your case. If it doesn't, try "rm -rf tmp" next (might be faster and
easier too, if more recipes are affected).



Thanks, that did fix it.

I see that those recipe-sysroot* trees are kept around (I don't run rm_work)
For one of my builds which has ~475 packages in tmp/work, they amount to 7GB
Is there any way to prune them?

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] Error after updating Poky

[Gary Thomas]

I just updated to the latest Poky master (7e0985bab68547) which
replaced rpm-5.4 with rpm-4.13.90 (git).  My builds in an existing
tree now fail:

| 
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so: 
file not recognized: File format not recognized

| collect2: error: ld returned 1 exit status
| ext/CMakeFiles/libsolvext.dir/build.make:285: recipe for target 
'ext/libsolvext.so.0' failed
| make[2]: *** [ext/libsolvext.so.0] Error 1
| make[2]: Leaving directory 
'/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/build'
| CMakeFiles/Makefile2:207: recipe for target 
'ext/CMakeFiles/libsolvext.dir/all' failed
| make[1]: *** [ext/CMakeFiles/libsolvext.dir/all] Error 2
| make[1]: Leaving directory 
'/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/build'
| Makefile:163: recipe for target 'all' failed
| make: *** [all] Error 2
| ERROR: Function failed: do_compile (log file is located at 
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/temp/log.do_compile.8183)

ERROR: Task 
(/local/poky-cutting-edge/meta/recipes-extended/libsolv/libsolv_0.6.26.bb:do_compile)
 failed with exit code '1'

Looking at this file shows it's a stale symlink:
$ file 
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so: 
symbolic link to librpmdb-5.4.so
$ file `readlink 
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so`

librpmdb-5.4.so: cannot open `librpmdb-5.4.so' (No such file or directory)

Any ideas how to fix this?

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Hints on submitting to OE-Core

[Gary Thomas]

On 2017-03-18 00:55, Daniel Dickinson wrote:

Hi all,

I've got a pre-alpha 'distro' and some layers I think that could get to
an interesting state.  The intent is to work them up to where they are
suitable to be submitted as patches to oe-core rather than the
current .bbappend and related files.

There's rather a lot of reading (which is good in the sense that I like
actually have documentation, although that's definitely an area I need
to improve on for the layers I've got in the works), and I haven't
nearly got through it all yet, but I was hoping for pointers on the
most important bits to read for prepping patches submission.


Have you read this?
  http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded



Also, in the layers list I'll be asking about some build issues that I
don't see with a manual bitbake, that look like missing preqs on a build
server, unless the layer should be requesting installation of host files
somewhere.


Some tools required by ${HOSTTOOLS} are missing:
  cpio chrpath gawk diffstat makeinfo

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH V9] go: Add recipes for golang compilers and tools

[Gary Thomas]

On 2017-03-08 07:40, Khem Raj wrote:

* This is converging the recipes for go from
  meta-virtualization and oe-meta-go

* Add recipes for go 1.7

* go.bbclass is added to ease out writing
  recipes for go packages

* go-examples: Add an example, helloworld written in go
  This should serve as temlate for writing go recipes

* Disable for musl, at least for now

* Disable for x32/ppc32 which is not supported

Signed-off-by: Khem Raj <raj.k...@gmail.com>
Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>

  

This is looking pretty good now.  I built go & go-helloworld easily
with no warnings, etc.  'go-helloworld' runs fine on my target.

However, there don't seem to be any packages for the target created
by the 'go' recipe:

$ ls tmp/work/cortexa9hf-neon-amltd-linux-gnueabi/go/1.8-r0
armhf-elf-header.patch go   pseudo  
   syslog.patch
build-tmp  gotooldir.patch  recipe-sysroot  
   sysroot-destdir
fix-cc-handling.patch  imagerecipe-sysroot-native   
   temp
fix-target-cc-for-build.patch  license-destdir  
split-host-and-target-build.patch

I manually copied the 'image' directory (which obviously has a lot
of stuff not designed to be on my target board) to my target and
'go' seems to run there.

There is a need for RRECOMMENDS = "git-perltools" once this packaging is set:

~# go get golang.org/x/tour/gotour
go: missing Git command. See https://golang.org/s/gogetcmd
package golang.org/x/tour/gotour: exec: "git": executable file not found in 
$PATH

I ran through the tour (above) and things seemed to go well.

All in all, looking better.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Create more than one image with WIC

[Gary Thomas]

On 2017-03-08 11:57, Ed Bartosh wrote:

On Wed, Mar 08, 2017 at 10:44:21AM +0100, Daniel Schultz wrote:

Hi,

I created two kickstart files (am335x-sdimage.wks, am335x-emmc.wks)
and added them to the local.conf.

When I build the image only the first wks in WKS_FILES will be used
by WIC and the second will be ignored. Is it possible to build two
images in one build?



I don't think it's possible to build more than one image for the same
type. wic is not an exception here.


Includes of the wks files in local.conf:
WKS_FILES_ti33x = "am335x-sdimage.wks am335x-emmc.wks "


WKS_FILES variable is to provide possible wks files to use. First one found will
be used to produce an image.


Would it work to add/define this variable in the corresponding *image*.bb recipe
rather than local.conf?

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] how to *securely* do a remote install of an OE image?

[Gary Thomas]

On 2017-02-28 13:27, Patrick Ohly wrote:

On Tue, 2017-02-28 at 05:28 -0500, Robert P. J. Day wrote:

  my immediate reaction was to use SSH keys, where the
newly-installed system would require SSH logins, and would have to
match the corresponding private key.


That would also be my preferred approach.


  as an alternative, perhaps don't worry about such a situation, but
when the authorized user logs in for what is *supposed* to be the
first time, it will be flagged that someone else has already logged in
earlier, and a warning will be printed, "Previous login to root
detected, you have been compromised, please re-install!"


Or, along the same lines, set an empty root password and force the user
to set a password on the first login. There are ways to do that with
PAM, but I don't have anything at hand.


  i'm sure there are plenty of ways of doing this, anyone have any
pointers?


For ssh keys, there's rootfsdebugfiles.bbclass. In local.conf:

INHERIT += "rootfsdebugfiles"
ROOTFS_DEBUG_FILES += "/home/pohly/.ssh/id_rsa.pub 
${IMAGE_ROOTFS}/home/root/.ssh/authorized_keys ;"

This copies my id_rsa.pub into authorized_keys and thus let's me log
into images that I create via ssh.



Does this work for dropbear or only openssh?

--
--------
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Patchwork not picking changes from the ML

[Gary Thomas]

On 2017-02-24 17:46, Burton, Ross wrote:


On 24 February 2017 at 16:27, Patrick Ohly <patrick.o...@intel.com 
<mailto:patrick.o...@intel.com>> wrote:

Let me clarify that my original proposal was to reply only to the
original author. That was meant to keep noise down on the list. However,
perhaps it should also go to the list?

Then others can help check that Patchwork works, as the original author
might not be aware that a response is missing. It also tells everyone
the relevant link in Patchwork.


As long as patchworks ignores the email it sends, that's not a terrible idea.


I'd be happy either way, as long as I (as the poster) get some
sort of feedback that the patch has been received and queued.

Thanks for improving this system :-)

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Patchwork not picking changes from the ML

[Gary Thomas]

On 2017-02-24 15:21, Patrick Ohly wrote:

On Wed, 2017-02-22 at 15:56 -0600, Jose Lamego wrote:


On 02/22/2017 02:55 PM, Michael Halstead wrote:

I've seen several issues with hooks. I was working on them yesterday and
will continue today.

These are currently managed by hand but we are moving them into
configuration management which should help keep them working consistently.


Michael: one syntax error in patchwork code was pulled into production
yesterday. This is the cause for missing patches. The error is fixed in
the Yocto repo now, please perform a server code update ASAP.

Martin: I will look at the UI issue you are describing and file a bug if
needed.


Would it perhaps make sense to reply to the original author with an
email confirming that his patch is now in Patchwork? It should include a
link to the patch series, too.

This could have several advantages:
  * submitters not aware of Patchwork or whether their target
currently uses it learn about it and then can follow the
progress of their patch
  * everyone gets a confirmation that the submission made it through
the various mail servers and Patchwork itself

It still relies on the original submitter to watch out for breakages in
the processes, but I guess that can't be avoided with an asynchronous,
mail-based process.



I would love to see this added to the process - +1 :-)

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] busybox: setup "inetd" sub-package

[Gary Thomas]

On 2017-02-16 21:47, Sylvain Lemieux wrote:

From: Sylvain Lemieux <slemi...@tycoint.com>

Setup "inetd" as a sub-package in "busybox" and
add the support to install "inetd" as a startup script.

Signed-off-by: Sylvain Lemieux <slemi...@tycoint.com>
---
 meta/recipes-core/busybox/busybox.inc | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index 39c2eef082..a26fa08ca8 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -21,7 +21,7 @@ export EXTRA_LDFLAGS = "${LDFLAGS}"
 # We don't want '-e MAKEFLAGS=' in EXTRA_OEMAKE
 EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} 
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y"

-PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev 
${PN}-hwclock"
+PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev 
${PN}-hwclock ${PN}-inetd"

 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"
@@ -29,8 +29,9 @@ FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev 
${sysconfdir}/mdev.conf ${sysconfd
 FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd"
 FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc"
 FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
+FILES_${PN}-inetd = "${sysconfdir}/init.d/inetd.${BPN} 
${sysconfdir}/inetd.conf"

-INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev 
${PN}-hwclock"
+INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev 
${PN}-hwclock ${PN}-inetd"

 INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd"
 INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
@@ -38,6 +39,7 @@ INITSCRIPT_NAME_${PN}-mdev = "mdev"
 INITSCRIPT_PARAMS_${PN}-mdev = "start 04 S ."
 INITSCRIPT_NAME_${PN}-syslog = "syslog"
 INITSCRIPT_NAME_${PN}-udhcpd = "busybox-udhcpd"
+INITSCRIPT_NAME_${PN}-inetd = "inetd.${BPN}"

 SYSTEMD_PACKAGES = "${PN}-syslog"
 SYSTEMD_SERVICE_${PN}-syslog = "busybox-syslog.service"
@@ -45,7 +47,7 @@ SYSTEMD_SERVICE_${PN}-syslog = "busybox-syslog.service"
 CONFFILES_${PN}-syslog = "${sysconfdir}/syslog-startup.conf.${BPN}"
 CONFFILES_${PN}-mdev = "${sysconfdir}/mdev.conf"

-RRECOMMENDS_${PN} = "${PN}-syslog ${PN}-udhcpc"
+RRECOMMENDS_${PN} = "${PN}-syslog ${PN}-udhcpc ${PN}-inetd"

 inherit cml1 systemd update-rc.d ptest




Doesn't this patch conflict with your previous one adding the -cron sub-package?


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH v2 0/3] Permit to install files from an overlay in images recipes

[Gary Thomas]

On 2017-02-15 18:33, Geoffrey Levillain wrote:

Hi,

These patches introduce a capability to install overlay into image after
fetching them.

There is actually a need to add image-specific configurations files into
image recipes, and these patches are a way to standardize this process as
well as simplify it by re-enabling fetching when image_overlay is
inherited, and by providing a task that copy every files in directories
listed in OVERLAY_ROOT_DIRS into IMAGE_ROOTFS directory.

Geoffrey Levillain (3):
  image.bbclass: No need to force image licence on MIT
  image_overlay.bbclass: Add possibility to install overlays to image
  rm_work.bbclass: Do not remove fetching and install_overlay stamps

 meta/classes/image.bbclass |  2 +-
 meta/classes/image_overlay.bbclass | 24 
 meta/classes/rm_work.bbclass   |  4 
 3 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 meta/classes/image_overlay.bbclass


Can you give an example where this approach is better than just
having the image include some [possibly optional] packages that
contain these image-specific configuration files?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] [PATCH] usbutils: allow udev-hwdb to be optional

[Gary Thomas]

Use RRECOMMENDS for the udev hardware data base, to allow for this
to be suppressed if desired (saves many MB - useful for smaller systems)

Signed-off-by: Gary Thomas <g...@mlbassoc.com>
---
 meta/recipes-bsp/usbutils/usbutils_008.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/usbutils/usbutils_008.bb 
b/meta/recipes-bsp/usbutils/usbutils_008.bb
index cb79360..d3c5bd5 100644
--- a/meta/recipes-bsp/usbutils/usbutils_008.bb
+++ b/meta/recipes-bsp/usbutils/usbutils_008.bb
@@ -21,5 +21,5 @@ inherit autotools gettext pkgconfig distro_features_check
 
 FILES_${PN}-dev += "${datadir}/pkgconfig"
 
-RDEPENDS_${PN} = "udev-hwdb"
+RRECOMMENDS_${PN} = "udev-hwdb"
 RDEPENDS_${PN}-ptest = "libboost-system libboost-thread"
-- 
2.7.4

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

Re: [OE-core] [PATCH 1/3] go: Add recipes for golang compilers and tools

[Gary Thomas]

On 2017-02-08 14:53, Joshua Lock wrote:

On Tue, 2017-02-07 at 17:35 +, Burton, Ross wrote:


On 7 February 2017 at 04:24, Khem Raj <raj.k...@gmail.com 
<mailto:raj.k...@gmail.com>> wrote:

This is converging the recipes for go from
meta-virtualization and oe-meta-go



I'm still of the opinion that this should be in meta-go, not oe-core...


FWIW I disagree. Go is a popular systems language and we're increasingly 
supporting a wide-array of systems with OE
(from iot to ivi and beyond).

Go is already in wide enough use and duplicated in enough layers that we would 
be doing folks a favour by including it
in OE-Core and our build/test cycle.


I agree - if ruby is OE-core worthy, go most certainly is.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] glib-2.0: native package should not depend on DISTRO_FEATURES

[Gary Thomas]

On 2017-01-21 06:02, Gary Thomas wrote:

xxx-native packages should not depend on ${DISTRO} settings.  Doing
so feels inherently wrong and limits the usefulness of sstate-cache.

This patch changes how this package is installed, in particular
removing the dependency on the ${DISTRO_FEATURES} variable in
glib-2.0-native.  This will further improve the ability to share
native packages between builds with differences in ${DISTRO_FEATURES}

Signed-off-by: Gary Thomas <g...@mlbassoc.com>
---
 meta/recipes-core/glib-2.0/glib.inc | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/glib-2.0/glib.inc 
b/meta/recipes-core/glib-2.0/glib.inc
index cb6aca7..a5db455 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -92,16 +92,20 @@ do_install_append () {
sed -i -e '1s,#!.*perl,#! ${USRBINPATH}/env perl,' 
${D}${bindir}/glib-mkenums
fi

+# Make sure gio-querymodules is unique among multilibs
+if test "x${MLPREFIX}" != "x"; then
+mv ${D}${libexecdir}/gio-querymodules 
${D}${libexecdir}/${MLPREFIX}gio-querymodules
+fi
+}
+
+do_install_append_class-target () {
+   # Tests are only installed on targets, not native builds.  Separating 
this out
+   # keeps glib-2.0-native from depending on ${DISTRO_FEATURES}
if [ -f ${D}${datadir}/installed-tests/glib/gdbus-serialization.test ]; 
then
if ${@bb.utils.contains("DISTRO_FEATURES", "x11", "false", 
"true", d)}; then
rm 
${D}${datadir}/installed-tests/glib/gdbus-serialization.test
fi
fi
-
-# Make sure gio-querymodules is unique among multilibs
-if test "x${MLPREFIX}" != "x"; then
-mv ${D}${libexecdir}/gio-querymodules 
${D}${libexecdir}/${MLPREFIX}gio-querymodules
-fi
 }

 do_install_append_libc-musl () {



Ping?


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] [PATCH] glib-2.0: native package should not depend on DISTRO_FEATURES

[Gary Thomas]

xxx-native packages should not depend on ${DISTRO} settings.  Doing
so feels inherently wrong and limits the usefulness of sstate-cache.

This patch changes how this package is installed, in particular
removing the dependency on the ${DISTRO_FEATURES} variable in
glib-2.0-native.  This will further improve the ability to share
native packages between builds with differences in ${DISTRO_FEATURES}

Signed-off-by: Gary Thomas <g...@mlbassoc.com>
---
 meta/recipes-core/glib-2.0/glib.inc | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/glib-2.0/glib.inc 
b/meta/recipes-core/glib-2.0/glib.inc
index cb6aca7..a5db455 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -92,16 +92,20 @@ do_install_append () {
sed -i -e '1s,#!.*perl,#! ${USRBINPATH}/env perl,' 
${D}${bindir}/glib-mkenums
fi
 
+# Make sure gio-querymodules is unique among multilibs
+if test "x${MLPREFIX}" != "x"; then
+mv ${D}${libexecdir}/gio-querymodules 
${D}${libexecdir}/${MLPREFIX}gio-querymodules
+fi
+}
+
+do_install_append_class-target () {
+   # Tests are only installed on targets, not native builds.  Separating 
this out
+   # keeps glib-2.0-native from depending on ${DISTRO_FEATURES}
if [ -f ${D}${datadir}/installed-tests/glib/gdbus-serialization.test ]; 
then
if ${@bb.utils.contains("DISTRO_FEATURES", "x11", "false", 
"true", d)}; then
rm 
${D}${datadir}/installed-tests/glib/gdbus-serialization.test
fi
fi
-
-# Make sure gio-querymodules is unique among multilibs
-if test "x${MLPREFIX}" != "x"; then
-mv ${D}${libexecdir}/gio-querymodules 
${D}${libexecdir}/${MLPREFIX}gio-querymodules
-fi
 }
 
 do_install_append_libc-musl () {
-- 
2.7.4

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

Re: [OE-core] [PATCH 1/2] go: Add recipes for golang compilers and tools

[Gary Thomas]

On 2016-11-10 01:39, Khem Raj wrote:

This is converging the recipes for go from
meta-virtualization and oe-meta-go

Add recipes for go 1.7

go.bbclass is added to ease out writing
recipes for go packages

Signed-off-by: Khem Raj 
---
 meta/classes/go.bbclass|  74 +++
 meta/classes/goarch.bbclass|  40 
 meta/recipes-devtools/go/go-1.4.inc|  15 ++
 .../go/go-1.4/016-armhf-elf-header.patch   |  24 +++
 ...ckport-cmd-link-support-new-386-amd64-rel.patch | 225 +
 meta/recipes-devtools/go/go-1.4/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-1.6.inc|  19 ++
 .../go/go-1.6/armhf-elf-header.patch   |  23 +++
 .../go/go-1.6/fix-cc-handling.patch|  50 +
 .../go/go-1.6/fix-target-cc-for-build.patch|  17 ++
 meta/recipes-devtools/go/go-1.6/gotooldir.patch|  30 +++
 .../go/go-1.6/split-host-and-target-build.patch|  63 ++
 meta/recipes-devtools/go/go-1.6/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-1.7.inc|  18 ++
 .../go/go-1.7/armhf-elf-header.patch   |  23 +++
 .../go/go-1.7/fix-cc-handling.patch|  50 +
 .../go/go-1.7/fix-target-cc-for-build.patch|  17 ++
 meta/recipes-devtools/go/go-1.7/gotooldir.patch|  30 +++
 .../go/go-1.7/split-host-and-target-build.patch|  62 ++
 meta/recipes-devtools/go/go-1.7/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-common.inc |  21 ++
 meta/recipes-devtools/go/go-native.inc |  54 +
 meta/recipes-devtools/go/go-native_1.4.bb  |   2 +
 meta/recipes-devtools/go/go.inc|  74 +++
 meta/recipes-devtools/go/go_1.6.bb |   4 +
 meta/recipes-devtools/go/go_1.7.bb |   4 +
 26 files changed, 1125 insertions(+)
 create mode 100644 meta/classes/go.bbclass
 create mode 100644 meta/classes/goarch.bbclass
 create mode 100644 meta/recipes-devtools/go/go-1.4.inc
 create mode 100644 meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.4/go-cross-backport-cmd-link-support-new-386-amd64-rel.patch
 create mode 100644 meta/recipes-devtools/go/go-1.4/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6.inc
 create mode 100644 meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/fix-cc-handling.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.6/fix-target-cc-for-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/gotooldir.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.6/split-host-and-target-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7.inc
 create mode 100644 meta/recipes-devtools/go/go-1.7/armhf-elf-header.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/fix-cc-handling.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.7/fix-target-cc-for-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/gotooldir.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.7/split-host-and-target-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-common.inc
 create mode 100644 meta/recipes-devtools/go/go-native.inc
 create mode 100644 meta/recipes-devtools/go/go-native_1.4.bb
 create mode 100644 meta/recipes-devtools/go/go.inc
 create mode 100644 meta/recipes-devtools/go/go_1.6.bb
 create mode 100644 meta/recipes-devtools/go/go_1.7.bb

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
new file mode 100644
index 000..e10864d
--- /dev/null
+++ b/meta/classes/go.bbclass
@@ -0,0 +1,74 @@
+inherit goarch
+
+GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
+GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
+GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
+GOBIN_FINAL = "${GOROOT_FINAL}/bin/${GOOS}_${GOARCH}"
+
+export GOOS = "${TARGET_GOOS}"
+export GOARCH = "${TARGET_GOARCH}"
+export GOARM = "${TARGET_GOARM}"
+export CGO_ENABLED = "1"
+export GOROOT
+export GOROOT_FINAL = "${libdir}/${TARGET_SYS}/go"
+export GOBIN_FINAL
+export GOPKG_FINAL = "${GOROOT_FINAL}/pkg/${GOOS}_${GOARCH}"
+export GOSRC_FINAL = "${GOROOT_FINAL}/src"
+export GO_GCFLAGS = "${TARGET_CFLAGS}"
+export GO_LDFLAGS = "${TARGET_LDFLAGS}"
+export CGO_CFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_CFLAGS}"
+export CGO_CPPFLAGS = "${TARGET_CPPFLAGS}"
+export CGO_CXXFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} 
${TARGET_CXXFLAGS}"
+export CGO_LDFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_LDFLAGS}"
+
+DEPENDS += "go-cross"
+DEPENDS_class-native += "go-native"
+
+INHIBIT_PACKAGE_STRIP = "1"
+
+FILES_${PN}-staticdev += "${GOSRC_FINAL}/${GO_IMPORT}"
+FILES_${PN}-staticdev += 

Re: [OE-core] [PATCH] u-boot: mkimage: Fix build of u-boot-mkimage

[Gary Thomas]

On 2016-11-09 01:45, Burton, Ross wrote:


On 9 November 2016 at 00:43, Khem Raj <raj.k...@gmail.com 
<mailto:raj.k...@gmail.com>> wrote:

> I'm guessing that it is using the host compiler instead of the cross 
compiler.

isnt mkimage a host tool ? why are we building it for target ?


If there's no chance that it will be ran on the target for in a SDK then 
patches welcome to force the recipe to native only.

The recipe is using _append without adding whitespace, but fixing that doesn't 
fix the build.


I routinely build and use it on my targets, so no, it's not host only.

--
--------
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] uninative binary?

[Gary Thomas]

On 2016-11-04 11:03, Richard Purdie wrote:

On Fri, 2016-11-04 at 08:16 +0100, Gary Thomas wrote:

Some of my customers need to be able to build without any
network connectivity, so I normally use BB_NO_NETWORK="1"

Is there a way to add the uninative "binary shim" to my
download mirror?  Given that the path includes a hash as
a directory, it's not clear to me how to put it into my
mirror.

Thanks for any ideas


Set UNINATIVE_URL to point at your mirror?

If the file already exists in DL_DIR, it will be used without touching
the network.


Thanks, that worked.  I keep a link to my mirror in my meta tree,
so I added these lines to my ${DISTRO}.conf:
  UNINATIVE_URL ?= "file://${COREBASE}/sources/uninative/1.4/"
  require conf/distro/include/yocto-uninative.inc
  INHERIT += "uninative"
When I ran a build, this got sucked into my ${DL_DIR} as
  $ ls -lR downloads/uninative/
  downloads/uninative/:
  total 4
  drwxrwxr-x 2 gthomas gthomas 4096 Nov  7 13:02 
101ff8f2580c193488db9e76f9646fb6ed38b65fb76f403acb0e2178ce7127ca

  
downloads/uninative/101ff8f2580c193488db9e76f9646fb6ed38b65fb76f403acb0e2178ce7127ca:
  total 4
  lrwxrwxrwx 1 gthomas gthomas 76 Nov  7 13:02 x86_64-nativesdk-libc.tar.bz2 -> 
/local/poky-cutting-edge/sources/uninative/1.4/x86_64-nativesdk-libc.tar.bz2


--
--------
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] uninative binary?

[Gary Thomas]

Some of my customers need to be able to build without any
network connectivity, so I normally use BB_NO_NETWORK="1"

Is there a way to add the uninative "binary shim" to my
download mirror?  Given that the path includes a hash as
a directory, it's not clear to me how to put it into my
mirror.

Thanks for any ideas

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] curious about inherent value of dynamic layers

[Gary Thomas]

On 2016-11-01 11:18, Robert P. J. Day wrote:


  more pedantry: i notice that a small number of layers (eg,
meta-freescale, meta-mentor) include "dynamic" layers, so that some
sublayers are included only conditionally if others layers are
included. from meta-freescale's layer.conf:

/ start

  # The dynamic-layers directory hosts the extensions and layer specific
  # modifications related to Freescale products.
  #
  # The .bbappend and .bb files are included if the respective layer
  # collection is available.
  BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' 
% layer \
   for layer in BBFILE_COLLECTIONS.split())}"
  BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' % 
layer \
   for layer in BBFILE_COLLECTIONS.split())}"

/ end

where the "dynamic-layers" directory in that layer contains further
recipe directories with .bbappend files related to other layers:

  drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 browser-layer
  drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 efl-layer
  drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 filesystem-layer
  drwxrwxr-x. 4 rpjday rpjday 4096 Jun 26 06:36 networking-layer
  drwxrwxr-x. 6 rpjday rpjday 4096 Jun 26 06:36 openembedded-layer
  drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 qt4-layer
  drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 qt5-layer
  drwxrwxr-x. 3 rpjday rpjday 4096 Jun 26 06:36 virtualization-layer

seems like an interesting idea ... opinions on whether this is a
useful approach? or possibly overly confusing? is this approach
mentioned in any OE/YP doc?


It's very useful if they have .bbappend files in these directories
as that will cause problems building if you don't include the corresponding
layers.


--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] some pedantic questions about layer.conf "best practices"

[Gary Thomas]

On 2016-11-01 11:04, Robert P. J. Day wrote:


  updating a tutorial about writing a proper layer.conf file, so some
nitpicky questions about recommended style.

  first, when appending to BBFILES, is it recommended to explicitly
use separate wildcard patterns of "*.bb" and "*.bbappend", or just get
lazy and use "*.bb*"? i realize that, in the end, it makes no
effective difference; i just happen to prefer the more explicit
pattern; just wondering if anyone has any preferences on this either
way. (i did say "nitpicky.")


"*.bb*" also matches "*.bb~" and "*.bbappend~" (I use emacs which makes
these backup files) that could be WAY confusing...



  next, what is best practice for naming a layer, since standards seem
to differ. if i create a layer named "meta-rday", i've seen standards
where the layer is "named" with one of:

  BBFILE_COLLECTIONS += "rday"
  BBFILE_COLLECTIONS += "meta-rday"
  BBFILE_COLLECTIONS += "rday-layer"

amusingly, some freescale layers bounce around:

  BBFILE_COLLECTIONS += "freescale-layer"
  BBFILE_COLLECTIONS += "fsl-arm"
  BBFILE_COLLECTIONS += "fsl-ppc"

even the meta-openembedded (sub)layers don't have a consistent style;
some examples, which show all three styles:

  meta-filesystems/conf/layer.conf:BBFILE_COLLECTIONS += "filesystems-layer"
  meta-initramfs/conf/layer.conf:BBFILE_COLLECTIONS += "meta-initramfs"
  meta-webserver/conf/layer.conf:BBFILE_COLLECTIONS += "webserver"

is there an encouraged style?

  finally, is it necessary to have LAYERDEPENDS include "core"? isn't
that automatic? how could you possibly have a viable build system
without the oe-core layer (unless this gives you the freedom to
replace it with a custom one, which i don't see the value of).

  i think that's it for now ... thoughts?

rday




--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH 2/2] insane: display names instead of ELF machine numbers

[Gary Thomas]

On 2016-10-11 14:36, Burton, Ross wrote:


On 11 October 2016 at 13:26, Gary Thomas <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:

Did you mean to swap the items?  The old version used
  machine, elf.machine()
and this version uses
  elf.machine(), machine


Yes, because the string format changed to be clearer too:

-package_qa_add_message(messages, "arch", "Architecture did not match (%d to 
%d) on %s" % \
- (machine, elf.machine(), package_qa_clean_path(path,d)))
+package_qa_add_message(messages, "arch", "Architecture did not match (%s, 
expected %s) on %s" % \
+ (oe.qa.elf_machine_to_string(elf.machine()), 
oe.qa.elf_machine_to_string(machine),

The old message would say "20 to 62", the new message is "x86-64, expected 
PowerPC".


Much nicer indeed.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH 2/2] insane: display names instead of ELF machine numbers

[Gary Thomas]

On 2016-10-11 14:19, Ross Burton wrote:

The 'arch' QA test currently simply outputs the ELF machine field as a number
which isn't helpful.  Display this as a human-readable name to make it clearer
to the user what the problem is.

Signed-off-by: Ross Burton <ross.bur...@intel.com>
---
 meta/classes/insane.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index b347638..17c9284 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -543,8 +543,8 @@ def package_qa_check_arch(path,name,d, elf, messages):
 # Check the architecture and endiannes of the binary
 if not ((machine == elf.machine()) or \
 ((("virtual/kernel" in provides) or bb.data.inherits_class("module", d) ) and (target_os 
== "linux-gnux32" or target_os == "linux-gnun32"))):
-package_qa_add_message(messages, "arch", "Architecture did not match (%d to 
%d) on %s" % \
- (machine, elf.machine(), package_qa_clean_path(path,d)))
+package_qa_add_message(messages, "arch", "Architecture did not match (%s, 
expected %s) on %s" % \
+ (oe.qa.elf_machine_to_string(elf.machine()), 
oe.qa.elf_machine_to_string(machine), package_qa_clean_path(path,d)))
 elif not ((bits == elf.abiSize()) or  \
 ((("virtual/kernel" in provides) or bb.data.inherits_class("module", d) ) and (target_os 
== "linux-gnux32" or target_os == "linux-gnun32"))):
 package_qa_add_message(messages, "arch", "Bit size did not match (%d to %d) 
%s on %s" % \



Did you mean to swap the items?  The old version used
  machine, elf.machine()
and this version uses
  elf.machine(), machine

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] glibc: Fix timestamp of plural.c after unpack

[Gary Thomas]

On 2016-10-11 11:22, Enrico Scholz wrote:

Mark Hatle <mark.hatle-cwa4wttnnzf54taoqty...@public.gmane.org> writes:


My understanding of the issue is that the extraction of the plural.c and
plural.y files happens so quickly that it is unclear to make if one is older
then the other -- so it sometimes uses bison to rebuild the plural.c.


When this is really the case, this can apply to the workaround too.  So,
there should be added a 'sleep 1' before the 'touch' or (better?) remove
plural.c to enforce a rebuild.


I believe that's the opposite of the desired action, i.e. to always use
the packaged plural.c and never rely on the plural.y=>plural.c transformation.




+do_unpack_workaround() {
+   touch ${S}/intl/plural.c
+}


--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Serious build error

[Gary Thomas]

On 2016-10-09 13:24, Gary Thomas wrote:

Using Poky/Yocto rev 65107a9abe6c6c92c2c21e7dacfe4cc028ab7cb7 (2016-10-09), I 
get this
during do_rootfs for my image:

Collected errors:
  * calculate_dependencies_for: Cannot satisfy the following dependencies for 
epiphany:
  *  webkitgtk (>= 2.12.5) *
  * opkg_solver_install: Cannot install package epiphany.

I'm not sure how to interpret this as webkitgtk v2.12.5-r0 is in my build?
I'm also not sure why the version pinning as the only reference I can find
for this is in .../meta/recipes-gnome/epiphany/epiphany_3.20.3.bb:
  DEPENDS = "libsoup-2.4 webkitgtk gtk+3 iso-codes ca-certificates avahi 
libnotify gcr libwnck3 \

I also didn't find any use of epiphany in any of the image recipes
in the default Poky/Yocto.  Is this actually being tested on a regular
basis?



n.b. I do use epiphany in my [image] recipe, I just didn't see
any use of it in any of the OE-core+Poky/Yocto recipes.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] Serious build error

[Gary Thomas]

Using Poky/Yocto rev 65107a9abe6c6c92c2c21e7dacfe4cc028ab7cb7 (2016-10-09), I 
get this
during do_rootfs for my image:

Collected errors:
  * calculate_dependencies_for: Cannot satisfy the following dependencies for 
epiphany:
  *  webkitgtk (>= 2.12.5) *
  * opkg_solver_install: Cannot install package epiphany.

I'm not sure how to interpret this as webkitgtk v2.12.5-r0 is in my build?
I'm also not sure why the version pinning as the only reference I can find
for this is in .../meta/recipes-gnome/epiphany/epiphany_3.20.3.bb:
  DEPENDS = "libsoup-2.4 webkitgtk gtk+3 iso-codes ca-certificates avahi 
libnotify gcr libwnck3 \

I also didn't find any use of epiphany in any of the image recipes
in the default Poky/Yocto.  Is this actually being tested on a regular
basis?

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Taskhash mismatch?

[Gary Thomas]

On 2016-10-02 15:38, Changhyeok Bae wrote:

Please update meta-raspberrypi layer
to 
http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/?id=4c02c7ce07121c2f5367204445f93199d828bb10


I am using the latest master (as of 2016-10-02) which includes that revision.


2016-10-02 20:51 GMT+09:00 Jonathan Liu <net...@gmail.com 
<mailto:net...@gmail.com>>:

On 2 October 2016 at 18:28, Gary Thomas <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:
> Can someone explain this error?
>
> ERROR: video-demo-image-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch
> 7b8eab500890bd7cd6a00b70740800f1 versus 9471c988c4adee881554263bd10f7196 
for
> 
/local/poky-cutting-edge/meta-rpi/packages/images/video-demo-image.bb.do_image_rpi_sdimg
> ERROR: Taskhash mismatch 7b8eab500890bd7cd6a00b70740800f1 versus
> 9471c988c4adee881554263bd10f7196 for
> 
/local/poky-cutting-edge/meta-rpi/packages/images/video-demo-image.bb.do_image_rpi_sdimg
>
> I'm building with Poky/Yocto + meta-raspberrypi:
> meta  = "master:725e66e1d08ae000d8f68455ddca0e192080dc1f"
> meta-raspberrypi  = "master:4817e2c087097c02755d6309304878e42cf61d3c"
>
> As far as I can tell, the image was created even though the error.
>
> Thanks for any pointers

It happens to me sometimes as well in meta-raspberrypi layer.
Interesting thing is that it doesn't happen in the meta-sunxi layer
for me which has a very similar image class, although without the
device-tree auto-detection and splitting code.

I haven't been able to explain it.


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] Taskhash mismatch?

[Gary Thomas]

Can someone explain this error?

ERROR: video-demo-image-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch 7b8eab500890bd7cd6a00b70740800f1 versus 
9471c988c4adee881554263bd10f7196 for 
/local/poky-cutting-edge/meta-rpi/packages/images/video-demo-image.bb.do_image_rpi_sdimg
ERROR: Taskhash mismatch 7b8eab500890bd7cd6a00b70740800f1 versus 9471c988c4adee881554263bd10f7196 for 
/local/poky-cutting-edge/meta-rpi/packages/images/video-demo-image.bb.do_image_rpi_sdimg


I'm building with Poky/Yocto + meta-raspberrypi:
meta  = "master:725e66e1d08ae000d8f68455ddca0e192080dc1f"
meta-raspberrypi  = "master:4817e2c087097c02755d6309304878e42cf61d3c"

As far as I can tell, the image was created even though the error.

Thanks for any pointers

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] watchdog vs. wd-keepalive

[Gary Thomas]

With recent changes to the watchdog recipe, there are now
separate packages, one which starts "watchdog" and the other
which starts "wd_keepalive".  At least on my hardware (an i.MX6
plus an external watchdog), these are self conflicting.  If the
"watchdog" process starts first, the "wd_keepalive" process fails
because it gets EBUSY when it tries to open the watchdog device
(since both processes use the same config file) and vice-versa.
I've proven that either of these by itself is sufficient (again,
only tested on my hardware) and before these changes I was only
running the 'wd_keepalive' program via a target-specific, ad hoc,
startup.

So, which should it be?  I don't think it can be both as is
current.  Am I missing something?

A couple of other comments:
* The recent changes moved these startup actions into run level 01
(I use sysvinit) which is way too late for my hardware.  I've always
needed to run it at the earliest point in the boot, normally in
run level 'S' at a very high priority (low index like 05)

* The actual watchdog 'ping' interval in the config file doesn't
seem to match the documentation.  I set it to 2 and I get a ping
frequency of 10Hz (20 changes per second), as opposed to 4Hz which
would be 2 seconds per change.  I'll be investigating this further
and may propose some patches.

Thanks for your time

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Crazy display

[Gary Thomas]

On 2016-09-16 00:00, Paul Eggleton wrote:

On Thu, 15 Sep 2016 22:51:47 Richard Purdie wrote:

On Fri, 2016-09-16 at 08:41 +1200, Paul Eggleton wrote:

On Thu, 15 Sep 2016 22:26:09 Gary Thomas wrote:

On 2016-09-15 22:12, Burton, Ross wrote:

On 15 September 2016 at 21:03, Paul Eggleton


<paul.eggle...@linux.intel.com <mailto:paul.eggle...@linux.intel.com>


wrote:

Are you guys perhaps using the same terminal application?
Using screen
/ tmux / anything similar? (I'm using screen here and haven't
experienced problems though.)

I'm using iTerm2 on a Mac to run normal SSH to my Linux box. No
screen/tmux/etc.


Pretty much the same for me - just SSH in an xterm window.


Hmm, I'm still no closer then.

Does it just start happening at some point in the middle of a build?
Or right
from the start?


Seems to happen at various points during the build. Looks like bad
timing of console updates so can happen at any point, I'd see evidence
its happened multiple times in a given build.


This is bizarre. Clearly something is different between your systems and mine
:/


I've only seen it when my build machine was quite busy (yesterday
when I first noticed, I had three builds going at once)

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Crazy display

[Gary Thomas]

On 2016-09-15 22:12, Burton, Ross wrote:


On 15 September 2016 at 21:03, Paul Eggleton <paul.eggle...@linux.intel.com 
<mailto:paul.eggle...@linux.intel.com>> wrote:

Are you guys perhaps using the same terminal application? Using screen / 
tmux
/ anything similar? (I'm using screen here and haven't experienced problems
though.)


I'm using iTerm2 on a Mac to run normal SSH to my Linux box. No screen/tmux/etc.


Pretty much the same for me - just SSH in an xterm window.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] Crazy display

[Gary Thomas]

I haven't seen this before, just thought I'd toss it out there.
I was doing a build (actually three in parallel in separate
windows on my build box) and noticed this:

Currently  3 running tasks (3282 of 5081)  64% |### 
   |

0: busybox-1.24.1-r0 do_compile (pid 29425)
Currently  3 running tasks (3283 of 5081)  64% |### 
   |
Currently  3 running tasks (3429 of 5081)  67% |# 
   |

0: gstreamer1.0-libav-1.8.3-r0 do_configure (pid 10393)
Currently  1 running tasks (3560 of 5081)  70% | 
   |

0: gstreamer1.0-libav-1.8.3-r0 do_compile (pid 17458)
Currently  3 running tasks (3601 of 5081)  70% | 
   |

0: gstreamer1.0-libav-1.8.3-r0 do_compile (pid 17458)
1: gdk-pixbuf-2.34.0-r0 do_package_write_ipk (pid 12673)
2: unifdef-native-2.11-r0 do_populate_lic (pid 24548)

Somehow the task tracker (that does a nice job of telling the user
what's going on without being overwhelming BTW) got very confused!

I doubt if I can every repeat this, just passing on the observation!

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] pointercal-xinput?

[Gary Thomas]

Is this recipe relevant any more (since pointercal was removed)?
  ${Poky}/meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb

It, along with a .bbappend in meta-fsl-arm, is giving me runtime
errors:
  Using calibration data stored in /etc/pointercal.xinput
  Invalid format 42060
  unable to find device EETI eGalax Touch Screen
  Warning: error parsing geometry string - using defaults.
  Using calibration data stored in /etc/pointercal.xinput
  Invalid format 42060
  unable to find device EETI eGalax Touch Screen
  Warning: error parsing geometry string - using defaults.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] gcc: Update to final 6.2.0 release

[Gary Thomas]

On 2016-08-23 14:41, Martin Jansa wrote:

On Tue, Aug 23, 2016 at 02:29:27PM +0200, Gary Thomas wrote:

On 2016-08-23 14:13, Alexander Kanavin wrote:

On 08/23/2016 04:27 AM, Khem Raj wrote:

-#BASEURI ?= "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2"
+BASEURI ?= "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2"
 #SRCREV = "bd9a826d5448db11d29d2ec5884e7e679066f140"
 #BASEURI ?= "git://github.com/gcc-mirror/gcc;branch=gcc-6-branch;protocol=git"
-BASEURI ?= 
"ftp://sourceware.org/pub/gcc/snapshots/6.2.0-RC-20160815/gcc-6.2.0-RC-20160815.tar.bz2;
+#BASEURI ?= 
"ftp://sourceware.org/pub/gcc/snapshots/6.2.0-RC-20160815/gcc-6.2.0-RC-20160815.tar.bz2;
-S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}${SNAP}"
+S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}"
 #S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/git"
 B = "${WORKDIR}/gcc-${PV}/build.${HOST_SYS}.${TARGET_SYS}"


The commented out lines should be dropped, they're just clutter.


Also, how "final" is it when the URL points to a "xxx-RC-yyy"?  Seems
a bit premature...


If you read it a bit more carefully you'll notice that it doesn't point
to "xxx-RC-yyy"?

Only your reply was a bit premature :).



Indeed, all those extra lines...  Sorry for the noise :-(

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] gcc: Update to final 6.2.0 release

[Gary Thomas]

On 2016-08-23 14:13, Alexander Kanavin wrote:

On 08/23/2016 04:27 AM, Khem Raj wrote:

-#BASEURI ?= "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2"
+BASEURI ?= "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2"
 #SRCREV = "bd9a826d5448db11d29d2ec5884e7e679066f140"
 #BASEURI ?= "git://github.com/gcc-mirror/gcc;branch=gcc-6-branch;protocol=git"
-BASEURI ?= 
"ftp://sourceware.org/pub/gcc/snapshots/6.2.0-RC-20160815/gcc-6.2.0-RC-20160815.tar.bz2;
+#BASEURI ?= 
"ftp://sourceware.org/pub/gcc/snapshots/6.2.0-RC-20160815/gcc-6.2.0-RC-20160815.tar.bz2;
-S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}${SNAP}"
+S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}"
 #S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/git"
 B = "${WORKDIR}/gcc-${PV}/build.${HOST_SYS}.${TARGET_SYS}"


The commented out lines should be dropped, they're just clutter.


Also, how "final" is it when the URL points to a "xxx-RC-yyy"?  Seems
a bit premature...

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [RFT] gcc 6.2 RC1 update

[Gary Thomas]

On 2016-08-19 18:01, Khem Raj wrote:



On Aug 19, 2016, at 8:05 AM, Gary Thomas <g...@mlbassoc.com> wrote:

On 2016-08-19 16:59, Khem Raj wrote:

This is a long standing assembler error. Which I never get to bottom of. 
Rwboorinf the build machine helps

  
^

What does this mean?  As I mentioned, it worked fine before you updated to 6.2


‘rebooting’, ( blame the phone keyboard) this is a memory block that returns 
wrong string and somehow related to allocations in assembler, if its the same 
error as I know of. It does not have to do with
gcc.



Fair enough, but a machine reboot wasn't needed.  The actual problem came from
this recent commit:
   commit 08a54713acf424f45d8588c5c149a6053c9ac9c5
   Author: Manjukumar Matha <manjukumar.harthikote-ma...@xilinx.com>
   Date:   Tue Aug 9 10:15:07 2016 -0700
 u-boot.inc: Enable out-of-tree builds

This change broke some FSL specific code (in meta-fsl-arm) that expected to
run in the GIT tree and not a separate 'build' directory - patch already sent.

Sorry for the noise (and blaming the GCC update which otherwise has been very 
unpainful)






On Aug 19, 2016 7:06 AM, "Gary Thomas" <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:

   On 2016-08-19 16:04, Gary Thomas wrote:

   On 2016-08-19 15:40, Khem Raj wrote:


   On Aug 19, 2016, at 3:14 AM, Richard Purdie 
<richard.pur...@linuxfoundation.org
   <mailto:richard.pur...@linuxfoundation.org>> wrote:

   On Tue, 2016-08-16 at 11:55 -0700, Khem Raj wrote:

   Hi All

   I have put together recipe upgrade for upcoming gcc 6.2 
release now
   that it entered RC phase. With gcc 6.2 the recipes are using 
tarballs
   instead of git fetcher as promised :)
   Please help testing it out in your setups and report any 
issues you
   see.

   The commit you need to cherry-pick for OE-core is this one

   
https://github.com/kraj/openembedded-core/commit/0319b603761a16e65d70
   
<https://github.com/kraj/openembedded-core/commit/0319b603761a16e65d70>
   4336112c3709a8bf771c

   Thank you for your help


   I put this through the autobuilder and it passed so I've merged 
it. I
   did this quickly as we're putting a "pre M3" build through a QA 
cycle
   and I wanted to get some of the more invasive changes into that 
build
   so we don't have a stampeding herd of patches breaking everything
   coming up to the final feature freeze for 2.2.

   In other news, we are now also testing musl world builds on the
   autobuilder as part of regular testing.


   Fantastic !


   Problem using this to build meta-fsl-arm:u-boot-fslc for i.MX6:
   CC  lib/asm-offsets.s
   lib/asm-offsets.c:1:0: error: bad value (armv5) for -march= switch

   This worked fine with GCC/6.1 (git)

   Ideas?


   Also, the bitbake "do_compile log" didn't show me this at all,
   I had to get it by running 'bitbake u-boot-fslc -c devshell' and
   then 'make' to see the error :-(


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world
----





--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [RFT] gcc 6.2 RC1 update

[Gary Thomas]

On 2016-08-19 16:59, Khem Raj wrote:

This is a long standing assembler error. Which I never get to bottom of. 
Rwboorinf the build machine helps

   
^

What does this mean?  As I mentioned, it worked fine before you updated to 6.2




On Aug 19, 2016 7:06 AM, "Gary Thomas" <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:

    On 2016-08-19 16:04, Gary Thomas wrote:

On 2016-08-19 15:40, Khem Raj wrote:


On Aug 19, 2016, at 3:14 AM, Richard Purdie 
<richard.pur...@linuxfoundation.org
<mailto:richard.pur...@linuxfoundation.org>> wrote:

On Tue, 2016-08-16 at 11:55 -0700, Khem Raj wrote:

Hi All

I have put together recipe upgrade for upcoming gcc 6.2 
release now
that it entered RC phase. With gcc 6.2 the recipes are 
using tarballs
instead of git fetcher as promised :)
Please help testing it out in your setups and report any 
issues you
see.

The commit you need to cherry-pick for OE-core is this one


https://github.com/kraj/openembedded-core/commit/0319b603761a16e65d70

<https://github.com/kraj/openembedded-core/commit/0319b603761a16e65d70>
4336112c3709a8bf771c

Thank you for your help


I put this through the autobuilder and it passed so I've merged 
it. I
did this quickly as we're putting a "pre M3" build through a QA 
cycle
and I wanted to get some of the more invasive changes into that 
build
so we don't have a stampeding herd of patches breaking 
everything
coming up to the final feature freeze for 2.2.

In other news, we are now also testing musl world builds on the
autobuilder as part of regular testing.


Fantastic !


Problem using this to build meta-fsl-arm:u-boot-fslc for i.MX6:
CC  lib/asm-offsets.s
lib/asm-offsets.c:1:0: error: bad value (armv5) for -march= switch

This worked fine with GCC/6.1 (git)

Ideas?


Also, the bitbake "do_compile log" didn't show me this at all,
I had to get it by running 'bitbake u-boot-fslc -c devshell' and
then 'make' to see the error :-(


--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [RFT] gcc 6.2 RC1 update

[Gary Thomas]

On 2016-08-19 15:40, Khem Raj wrote:



On Aug 19, 2016, at 3:14 AM, Richard Purdie 
<richard.pur...@linuxfoundation.org> wrote:

On Tue, 2016-08-16 at 11:55 -0700, Khem Raj wrote:

Hi All

I have put together recipe upgrade for upcoming gcc 6.2 release now
that it entered RC phase. With gcc 6.2 the recipes are using tarballs
instead of git fetcher as promised :)
Please help testing it out in your setups and report any issues you
see.

The commit you need to cherry-pick for OE-core is this one

https://github.com/kraj/openembedded-core/commit/0319b603761a16e65d70
4336112c3709a8bf771c

Thank you for your help


I put this through the autobuilder and it passed so I've merged it. I
did this quickly as we're putting a "pre M3" build through a QA cycle
and I wanted to get some of the more invasive changes into that build
so we don't have a stampeding herd of patches breaking everything
coming up to the final feature freeze for 2.2.

In other news, we are now also testing musl world builds on the
autobuilder as part of regular testing.


Fantastic !


Problem using this to build meta-fsl-arm:u-boot-fslc for i.MX6:
CC  lib/asm-offsets.s
lib/asm-offsets.c:1:0: error: bad value (armv5) for -march= switch

This worked fine with GCC/6.1 (git)

Ideas?

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [RFT] gcc 6.2 RC1 update

[Gary Thomas]

On 2016-08-19 16:04, Gary Thomas wrote:

On 2016-08-19 15:40, Khem Raj wrote:



On Aug 19, 2016, at 3:14 AM, Richard Purdie 
<richard.pur...@linuxfoundation.org> wrote:

On Tue, 2016-08-16 at 11:55 -0700, Khem Raj wrote:

Hi All

I have put together recipe upgrade for upcoming gcc 6.2 release now
that it entered RC phase. With gcc 6.2 the recipes are using tarballs
instead of git fetcher as promised :)
Please help testing it out in your setups and report any issues you
see.

The commit you need to cherry-pick for OE-core is this one

https://github.com/kraj/openembedded-core/commit/0319b603761a16e65d70
4336112c3709a8bf771c

Thank you for your help


I put this through the autobuilder and it passed so I've merged it. I
did this quickly as we're putting a "pre M3" build through a QA cycle
and I wanted to get some of the more invasive changes into that build
so we don't have a stampeding herd of patches breaking everything
coming up to the final feature freeze for 2.2.

In other news, we are now also testing musl world builds on the
autobuilder as part of regular testing.


Fantastic !


Problem using this to build meta-fsl-arm:u-boot-fslc for i.MX6:
CC  lib/asm-offsets.s
lib/asm-offsets.c:1:0: error: bad value (armv5) for -march= switch

This worked fine with GCC/6.1 (git)

Ideas?



Also, the bitbake "do_compile log" didn't show me this at all,
I had to get it by running 'bitbake u-boot-fslc -c devshell' and
then 'make' to see the error :-(

--
--------
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] "parted" vs "sfdisk"

[Gary Thomas]

On 2016-08-05 12:19, Robert P. J. Day wrote:


  your personal opinions, if you would -- i'm working on some scripts
to do automated installs on a target board, currently based on
parted, but parted seems a bit dense at times, and awkward, and i'm
thinking of switching to sfdisk.

  for people who have done this sort of thing, do you have any strong
opinions either way of parted versus sfdisk? i realize that's not much
to go on, just curious about personal preferences, and why.


As you know, I went the other way - I started with sfdisk and
I find parted more intuitive and easier to use.  I also think
it has a better long-term support horizon.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Strange udev error

[Gary Thomas]

On 2016-07-30 11:18, Gary Thomas wrote:

I just got this udev error  - anyone know what to make of it?
   udevd[149]: no sender credentials received, message ignored

Note: I'm running Poky/Yocto master (039f47ad) and I don't
recall ever seeing this before and I only saw it on one target
built from these sources, others didn't report it.

Any pointers graciously accepted



BTW, I think this may be related to a cranky USB->ethernet
adapter I have, so if that's it, just let me know and I'll
move on...

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] Strange udev error

[Gary Thomas]

I just got this udev error  - anyone know what to make of it?
  udevd[149]: no sender credentials received, message ignored

Note: I'm running Poky/Yocto master (039f47ad) and I don't
recall ever seeing this before and I only saw it on one target
built from these sources, others didn't report it.

Any pointers graciously accepted

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH v2] python-setuptools: Upgrade to v 25.1.0

[Gary Thomas]

On 2016-07-28 11:32, Burton, Ross wrote:


On 27 July 2016 at 23:14, Alejandro Hernandez 
<alejandro.hernan...@linux.intel.com
<mailto:alejandro.hernan...@linux.intel.com>> wrote:

-LIC_FILES_CHKSUM = 
"file://setup.py;beginline=134;endline=134;md5=3e8df024d6c1442d18e84acf8fbbc475"
+LIC_FILES_CHKSUM = 
"file://setup.py;beginline=155;endline=155;md5=3e8df024d6c1442d18e84acf8fbbc475"


Please explain why the license checksum was changed.


In this case, the actual license checksum is the same, it
was just moved down in the file (and seemingly the lines
before are not relevant to the license).

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] webkitgtk: Switch the ARMv7 build to Thumb2 and enable back the JSC JIT.

[Gary Thomas]

On 2016-07-18 23:19, Carlos Alberto Lopez Perez wrote:

* The JSC JIT is broken on ARMv7 without Thumb2.

[YOCTO #9474]

Signed-off-by: Carlos Alberto Lopez Perez <clo...@igalia.com>


Works on my i.MX6Q target!

Acked-by: Gary Thomas <g...@mlbassoc.com>


---
  meta/recipes-sato/webkit/webkitgtk_2.12.3.bb | 17 -
  1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.12.3.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.12.3.bb
index c5e5432..536fa23 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.12.3.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.12.3.bb
@@ -71,10 +71,6 @@ EXTRA_OECMAKE_append_armv5 = " -DENABLE_JIT=OFF "
  EXTRA_OECMAKE_append_armv6 = " -DENABLE_JIT=OFF "
  EXTRA_OECMAKE_append_armv4 = " -DENABLE_JIT=OFF "

-# ARM JIT can build on armv7a, but doesnt' work on runtime, cause
-# displaying problems or ephiphany hang.
-EXTRA_OECMAKE_append_armv7a = " -DENABLE_JIT=OFF "
-
  # binutils 2.25.1 has a bug on aarch64:
  # https://sourceware.org/bugzilla/show_bug.cgi?id=18430
  EXTRA_OECMAKE_append_aarch64 = " -DUSE_LD_GOLD=OFF "
@@ -89,7 +85,18 @@ SECURITY_CFLAGS_append_aarch64 = " -fPIE"
  FILES_${PN} += 
"${libdir}/webkit2gtk-4.0/injected-bundle/libwebkit2gtkinjectedbundle.so"

  # http://errors.yoctoproject.org/Errors/Details/20370/
-ARM_INSTRUCTION_SET = "arm"
+ARM_INSTRUCTION_SET_armv4 = "arm"
+ARM_INSTRUCTION_SET_armv5 = "arm"
+ARM_INSTRUCTION_SET_armv6 = "arm"
+
+# https://bugzilla.yoctoproject.org/show_bug.cgi?id=9474
+# https://bugs.webkit.org/show_bug.cgi?id=159880
+# JSC JIT can build on ARMv7 with -marm, but doesn't work on runtime.
+# Upstream only tests regularly the JSC JIT on ARMv7 with Thumb2 (-mthumb).
+ARM_INSTRUCTION_SET_armv7a = "thumb"
+ARM_INSTRUCTION_SET_armv7r = "thumb"
+ARM_INSTRUCTION_SET_armv7m = "thumb"
+ARM_INSTRUCTION_SET_armv7ve = "thumb"

  # Invalid data memory access: 0x
  # ...




--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Downloads from sourceforge.net

[Gary Thomas]

On 2016-07-13 16:24, Martin Jansa wrote:

Just FYI

If you're seeing a lot of do_fetch failures because of SRC_URI checksums
mismatch, be aware that there is some issue with sourceforge.net, all my
source archive downloads (with wget) download just this HTML:

wget 
http://downloads.sourceforge.net/project/gptfdisk/gptfdisk/0.8.10/gptfdisk-0.8.10.tar.gz


SourceForge





var DR_loc = DR_parse_hash_url();
if (DR_loc) {
 DR_sf_main(DR_loc);
} else {
 window.location.href = '<a  rel="nofollow" href="http://sourceforge.net/home.html">http://sourceforge.net/home.html</a>';
}



We're sorry -- the Sourceforge site is currently in Disaster Recovery mode, and 
currently requires
the use of javascript to function.  Please check back later.



Which of course has different checksums than tarball with sources.

You can see similar message if you try to access e.g. their blog (to find out 
if it's already
known issue for them):
http://sourceforge.net/blog/
or
http://sourceforge.net/blog/category/sitestatus/

Until it's resolved continue to use your better-be-already-populated premirrors.


It seems to have been short lived - I had this issue with 
docbook-xsl-1.79.1.tar.bz2
and the second time I tried it (a few minutes later) it was fine.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] GCC recipe using git?

[Gary Thomas]

I see that the gcc-6.x recipe is using git instead of a tarball.
Is there any way to go back to using tar?  I ship mirrored sources
to my customers (many are behind corporate firewalls and have limited
network access).  The file sizes are so vastly different and it's
quite the burden to have to carry around a 2.5GB file...

-rw-rw-r-- 1 gthomas gthomas   95661481 Jun  3 15:54 sources/gcc-5.4.0.tar.bz2
-rw-rw-r-- 1 gthomas gthomas 2525826872 Jul 12 16:42 
sources/git2_github.com.gcc-mirror.gcc.tar.gz

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] Future of GCC

[Gary Thomas]

Now that GCC 4.x is gone, we're left with (currently) 5.4 & 6.1
Is the intention to track these both for a while, or will 5.x
also be gone once things are working with 6.x?

... just wondering where to spend my effort since I'll have to
make my targets (some are very old) work with at least 5.x

Any advice?  Thanks

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] how to bbappend(?) to u-boot-fw-utils to add a custom /etc/fw_env.config??

[Gary Thomas]

On 2016-07-06 19:10, Robert P. J. Day wrote:


   i may be looking at this entirely incorrectly at the moment, but
what is the preferred way to sneak in a custom, target-specific
/etc/fw_env.config file when adding u-boot-fw-utils to one's image?

   if i examine u-boot-fw-utils_2016.03.bb, i can see that that package
is based on (predictably) the source code for u-boot:

   SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
   S = "${WORKDIR}/git"

which is fine, but if look at the overriding do_install() routine in
that recipe file, i see:

   do_install () {
 install -d ${D}${base_sbindir}
 install -d ${D}${sysconfdir}
 install -m 755 ${S}/tools/env/fw_printenv 
${D}${base_sbindir}/fw_printenv
 install -m 755 ${S}/tools/env/fw_printenv ${D}${base_sbindir}/fw_setenv
 install -m 0644 ${S}/tools/env/fw_env.config 
${D}${sysconfdir}/fw_env.config

so as i read it, the last action of do_install() is to install ... the
generic fw_env.config file sitting in u-boot's tools/env/ directory,
which really has no value. so how does one overcome this?

   i poked around and found a couple layers, here's meta-mender:

https://github.com/mendersoftware/meta-mender/blob/master/recipes-bsp/u-boot/u-boot-fw-utils_2015.10.bbappend

which adds a whole new task just to install a custom config file:


# Keep this separately from the rest of the .bb file in case that .bb file is
# overridden from another layer.
require u-boot-mender.inc

DEPENDS = "u-boot"

# Configure fw_printenv so that it looks in the right place for the environment.
do_configure_fw_printenv () {
 cat > ${D}${sysconfdir}/fw_env.config <

I do something like this in my machine layer, in a .u-boot-fw-utils_%.bbappend 
file:


FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://fw_env.config"

do_install_append() {
   install -d ${D}${sysconfdir}
   install -m 0644 ${WORKDIR}/fw_env.config ${D}${sysconfdir}/fw_env.config
}

PACKAGE_ARCH = "${MACHINE_ARCH}"



Yes, this "installs" the same file twice, but it does what you
need, it installs the desired file in the correct place. And, yes,
it's too bad that this "info" is kept in two completely different
recipes.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH 2/2] gcc: remove GCC 4.9

[Gary Thomas]

On 2016-07-01 16:36, Khem Raj wrote:

I am ok with this patch. If someone intends to keep using gcc 4.9 with
2.2, please speak up.


I am still [very much] using 4.9.  I'm happy to use my own layer to
support this - what file(s) do I need to have to clone this?



On Fri, Jul 1, 2016 at 5:28 AM, Ross Burton <ross.bur...@intel.com> wrote:

Signed-off-by: Ross Burton <ross.bur...@intel.com>
---
  meta/recipes-devtools/gcc/gcc-4.9.inc  |  141 -

  ...

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Python3 error?

[Gary Thomas]

On 06/03/2016 03:41 PM, Richard Purdie wrote:

On Fri, 2016-06-03 at 09:08 +0200, Gary Thomas wrote:

After the change over to Python3, I'm getting this error:

ERROR: Unable to parse /local/poky-cutting-edge/meta-gnome/recipes
-gnome/gnome-vfs/gnome-vfs_2.24.4.bb
Traceback (most recent call last):
File "/local/poky-cutting-edge/bitbake/lib/bb/siggen.py", line
151, in
SignatureGeneratorOEBasicHash.finalise(fn='/local/poky-cutting
-edge/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb',
d=, variant=None):
   try:
  >taskdeps = self._build_data(fn, d)
   except:
File "/local/poky-cutting-edge/bitbake/lib/bb/siggen.py", line
104, in
SignatureGeneratorOEBasicHash._build_data(fn='/local/poky-cutting
-edge/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb',
d=):

  >tasklist, gendeps, lookupcache =
bb.data.generate_dependencies(d)

File "/local/poky-cutting-edge/bitbake/lib/bb/data.py", line 438,
in generate_dependencies(d=):
   if dep not in deps:
  >deps[dep], values[dep] =
build_dependencies(dep, keys, shelldeps, varflagsexcl, d)
   newdeps |=  deps[dep]

This is from a recipe in meta-openembedded

Any ideas how to fix it?


Also, this backtrace is unclear. Could you apply:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip=02d40b13690ac8e9aaad203d09d5158d2f1c16c8

and see if you get a better backtrace?

If so I'd better get that patch cleaned up.


Per your previous message, indeed I did not have your meta-oe patches applied.
I will do that now to move forward, but I have tested this patch as requested.

The messages are a bit better, but it might not tell me what/where to look for
in the failing recipe.  Here's what I see now (head only):

==
WARNING: /local/poky-cutting-edge/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb: Exception during 
build_dependencies for populate_packages
WARNING: /local/poky-cutting-edge/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb: invalid syntax 
(package.bbclass, line 1058)
WARNING: /local/poky-cutting-edge/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb: Error during finalise of 
/local/poky-cutting-edge/meta-oe/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb
ERROR: /local/poky-cutting-edge/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb: invalid syntax (package.bbclass, 
line 1058)

ERROR: Unable to parse 
/local/poky-cutting-edge/meta-oe/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb
Traceback (most recent call last):
  File "/local/poky-cutting-edge/bitbake/lib/bb/siggen.py", line 151, in 
SignatureGeneratorOEBasicHash.finalise(fn='/local/poky-cutting-edge/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb', 
d=, variant=None):

 try:
>taskdeps = self._build_data(fn, d)
 except Exception as e:
  File "/local/poky-cutting-edge/bitbake/lib/bb/siggen.py", line 104, in 
SignatureGeneratorOEBasicHash._build_data(fn='/local/poky-cutting-edge/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb', 
d=):


>tasklist, gendeps, lookupcache = bb.data.generate_dependencies(d)

  File "/local/poky-cutting-edge/bitbake/lib/bb/data.py", line 439, in generate_dependencies(d=object at 0x7f25fa9aa3c8>):

 if dep not in deps:
>deps[dep], values[dep] = build_dependencies(dep, keys, 
shelldeps, varflagsexcl, d)
 newdeps |=  deps[dep]
  File "/local/poky-cutting-edge/bitbake/lib/bb/data.py", line 368, in 
build_dependencies(key='populate_pack
   ...
==

One other python3 comment - my [source] layers are now filling
up with lots of cache files, e.g. .../meta/lib/oe/__pycache__/*
While this may not bother me much, it might do so with some of
my customers as they like to be able to "prove" that their build
came from exactly the same source tree as what we support, etc.
Is this something that can be controlled or even disabled?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] Python3 error?

[Gary Thomas]

After the change over to Python3, I'm getting this error:

ERROR: Unable to parse 
/local/poky-cutting-edge/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb
Traceback (most recent call last):
  File "/local/poky-cutting-edge/bitbake/lib/bb/siggen.py", line 151, in 
SignatureGeneratorOEBasicHash.finalise(fn='/local/poky-cutting-edge/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb', 
d=, variant=None):

 try:
>taskdeps = self._build_data(fn, d)
 except:
  File "/local/poky-cutting-edge/bitbake/lib/bb/siggen.py", line 104, in 
SignatureGeneratorOEBasicHash._build_data(fn='/local/poky-cutting-edge/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb', 
d=):


>tasklist, gendeps, lookupcache = bb.data.generate_dependencies(d)

  File "/local/poky-cutting-edge/bitbake/lib/bb/data.py", line 438, in generate_dependencies(d=object at 0x7f3d6ec78b38>):

 if dep not in deps:
>deps[dep], values[dep] = build_dependencies(dep, keys, 
shelldeps, varflagsexcl, d)
 newdeps |=  deps[dep]

This is from a recipe in meta-openembedded

Any ideas how to fix it?

--
--------
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] sip.bbclass?

[Gary Thomas]

On 2016-05-25 08:13, Khem Raj wrote:



On May 25, 2016, at 8:34 AM, Gary Thomas <g...@mlbassoc.com> wrote:

I was just wondering why sip.bbclass is in OE-core (at least
the Poky version master:c7e614c438706) when nothing uses it?


OE-core can have components which are commonly used in OE infrastructure, 
especially bindings
may be checking all layers in layerindex would better answer your question


My impression was [perhaps erroneously] that for an object to be
in OE-core, it had to be _needed_ by some other object in OE-core.
Many recipes have been migrated out when there was no longer a
use for them, so why not .bbclass files as well?  Most other
layers that need .bbclass files that aren't in OE-core just have
their own classes...

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] sip.bbclass?

[Gary Thomas]

I was just wondering why sip.bbclass is in OE-core (at least
the Poky version master:c7e614c438706) when nothing uses it?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH 1/1] webkitgtk: turn off JIT on armv4 and armv7a

[Gary Thomas]

On 2016-05-19 07:42, Khem Raj wrote:



On May 18, 2016, at 10:38 PM, Robert Yang <liezhi.y...@windriver.com> wrote:



On 05/19/2016 01:28 PM, Khem Raj wrote:



On May 18, 2016, at 8:16 PM, Gary Thomas <g...@mlbassoc.com> wrote:

On 2016-05-18 22:07, Khem Raj wrote:

On Wed, May 18, 2016 at 2:03 AM, Robert Yang <liezhi.y...@windriver.com> wrote:

* It doesn't build on armv4:
{standard input}: Assembler messages:
{standard input}:52: Error: selected processor does not support `blx 
llint_throw_stack_overflow_error' in ARM mode
{standard input}:126: Error: selected processor does not support `bkpt #0' in 
ARM mode
{standard input}:128: Error: selected processor does not support `blx r0' in 
ARM mode
{standard input}:134: Error: selected processor does not support `bkpt #0' in 
ARM mode
{standard input}:185: Error: selected processor does not support `blx 
llint_throw_stack_overflow_error' in ARM mode
{standard input}:256: Error: selected processor does not support `blx r4' in 
ARM mode
{standard input}:310: Error: selected processor does not support `movw 
r2,#:lower16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
{standard input}:311: Error: selected processor does not support `movt 
r2,#:upper16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
{standard input}:315: Error: selected processor does not support `movw 
r2,#:lower16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
{standard input}:316: Error: selected processor does not support `movt 
r2,#:upper16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
[snip]

* It can build on armv7a, but doesn't work on runtime, cause
   displaying problems or ephiphany hang.

[YOCTO #9474]

Signed-off-by: Robert Yang <liezhi.y...@windriver.com>
---
  meta/recipes-sato/webkit/webkitgtk_2.12.1.bb | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
index bdbcbea..23ead72 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
@@ -62,9 +62,14 @@ EXTRA_OECMAKE = " \
  EXTRA_OECMAKE_append_powerpc = " -DENABLE_JIT=OFF "
  EXTRA_OECMAKE_append_powerpc64 = " -DENABLE_JIT=OFF "

-# ARM JIT code does not build on ARMv5/6 anymore, apparently they test only on 
v7 onwards
+# ARM JIT code does not build on ARMv4/5/6 anymore
  EXTRA_OECMAKE_append_armv5 = " -DENABLE_JIT=OFF "
  EXTRA_OECMAKE_append_armv6 = " -DENABLE_JIT=OFF "
+EXTRA_OECMAKE_append_armv4 = " -DENABLE_JIT=OFF "
+
+# ARM JIT can build on armv7a, but doesnt' work on runtime, cause
+# displaying problems or ephiphany hang.
+EXTRA_OECMAKE_append_armv7a = " -DENABLE_JIT=OFF "


this should work fine with thumb2 e.g. so this is a little broad brush
here to diable it across
all armv7


Why do you think that changing the instruction set (to thumb2) would
make the JIT work any better?


Assembler implementation for JIT has always worked better with thumb2.



If you tell me how, I'll test it on my i.MX6 (Cortex-A9) which is
the platform that inspired the original bug report.



Try adding

ARM_INSTRUCTION_SET_armv7a = “thumb"
ARM_INSTRUCTION_SET_armv7ve = “thumb"

in the webkitgtk recipe and see if it helps



Hi,

To be clear, webkitgtk can build on armv7a, but doesn't work on
runtime, cause displaying problems or ephiphany hang.


We are talking runtime here.



Sorry, still fails - tested on my i.MX6 target.  Visiting www.google.com
fails immediately.  Looks like the JIT should be disabled for armv7

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH 1/1] webkitgtk: turn off JIT on armv4 and armv7a

[Gary Thomas]

On 2016-05-18 22:07, Khem Raj wrote:

On Wed, May 18, 2016 at 2:03 AM, Robert Yang <liezhi.y...@windriver.com> wrote:

* It doesn't build on armv4:
{standard input}: Assembler messages:
{standard input}:52: Error: selected processor does not support `blx 
llint_throw_stack_overflow_error' in ARM mode
{standard input}:126: Error: selected processor does not support `bkpt #0' in 
ARM mode
{standard input}:128: Error: selected processor does not support `blx r0' in 
ARM mode
{standard input}:134: Error: selected processor does not support `bkpt #0' in 
ARM mode
{standard input}:185: Error: selected processor does not support `blx 
llint_throw_stack_overflow_error' in ARM mode
{standard input}:256: Error: selected processor does not support `blx r4' in 
ARM mode
{standard input}:310: Error: selected processor does not support `movw 
r2,#:lower16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
{standard input}:311: Error: selected processor does not support `movt 
r2,#:upper16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
{standard input}:315: Error: selected processor does not support `movw 
r2,#:lower16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
{standard input}:316: Error: selected processor does not support `movt 
r2,#:upper16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
[snip]

* It can build on armv7a, but doesn't work on runtime, cause
   displaying problems or ephiphany hang.

[YOCTO #9474]

Signed-off-by: Robert Yang <liezhi.y...@windriver.com>
---
  meta/recipes-sato/webkit/webkitgtk_2.12.1.bb | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
index bdbcbea..23ead72 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.12.1.bb
@@ -62,9 +62,14 @@ EXTRA_OECMAKE = " \
  EXTRA_OECMAKE_append_powerpc = " -DENABLE_JIT=OFF "
  EXTRA_OECMAKE_append_powerpc64 = " -DENABLE_JIT=OFF "

-# ARM JIT code does not build on ARMv5/6 anymore, apparently they test only on 
v7 onwards
+# ARM JIT code does not build on ARMv4/5/6 anymore
  EXTRA_OECMAKE_append_armv5 = " -DENABLE_JIT=OFF "
  EXTRA_OECMAKE_append_armv6 = " -DENABLE_JIT=OFF "
+EXTRA_OECMAKE_append_armv4 = " -DENABLE_JIT=OFF "
+
+# ARM JIT can build on armv7a, but doesnt' work on runtime, cause
+# displaying problems or ephiphany hang.
+EXTRA_OECMAKE_append_armv7a = " -DENABLE_JIT=OFF "


this should work fine with thumb2 e.g. so this is a little broad brush
here to diable it across
all armv7


Why do you think that changing the instruction set (to thumb2) would
make the JIT work any better?

If you tell me how, I'll test it on my i.MX6 (Cortex-A9) which is
the platform that inspired the original bug report.





  # binutils 2.25.1 has a bug on aarch64:
  # https://sourceware.org/bugzilla/show_bug.cgi?id=18430
--
2.7.4

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



--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] krogoth's core-image-minimal is much bigger than jethro's

[Gary Thomas]

On 2016-05-13 09:07, Andrea Adami wrote:

On Fri, May 13, 2016 at 8:48 AM, Robert Yang <liezhi.y...@windriver.com> wrote:


* For ext4:
   11M -> 26M
   The similar to vmdk, qcow2 and iso.

* For tar.bz2:
   2.7M -> 4.5M

The main problem is eudev-hwdb which would be 12M after installed, jethro
doesn't use this, but udev by default, and it's gone in krogoth.
$ du -sh core-image-minimal/1.0-r0/rootfs/etc/udev/*
0core-image-minimal/1.0-r0/rootfs/etc/udev/cache.data
6.4M core-image-minimal/1.0-r0/rootfs/etc/udev/hwdb.bin
5.2M core-image-minimal/1.0-r0/rootfs/etc/udev/hwdb.d
8.0K core-image-minimal/1.0-r0/rootfs/etc/udev/rules.d
4.0K core-image-minimal/1.0-r0/rootfs/etc/udev/udev.conf

Is there an easier way to fix this problem, please ? It's not a good
news for the user who uses core-imag-minimal/udev when they want to
upgrade to krogoth. And this would hurt the small device which uses
udev.



Somehow we have to explicitely opt-out:

+BAD_RECOMMENDATIONS += "eudev-hwdb"

IMHO for embedded devices it would be better to disable by default and
let the distro/machine add a specific RRECOMMEND.


+1



Regards
Andrea



The conf is:
MACHINE = "qemux86-64"
DISTRO = "poky"
PACKAGE_CLASSES = "package_rpm"
EXTRA_IMAGE_FEATURES = "debug-tweaks"
USER_CLASSES = "buildstats image-mklibs"

$ bitbake core-image-minimal

For jethro:
$ ls -lh core-image-minimal-qemux86-64-20160513061306.rootfs.ext4
11M  core-image-minimal-qemux86-64-20160513061306.rootfs.ext4
$ du -sh core-image-minimal-qemux86-64-20160513061306.rootfs.ext4
7.9M core-image-minimal-qemux86-64-20160513061306.rootfs.ext4

For krogoth:

$ ls -lh core-image-minimal-qemux86-64-20160513061459.rootfs.ext4
26M core-image-minimal-qemux86-64-20160513061459.rootfs.ext4

$ du -sh core-image-minimal-qemux86-64-20160513061459.rootfs.ext4
core-image-minimal-qemux86-64-20160513061459.rootfs.ext4

--
Thanks

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



--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] krogoth's core-image-minimal is much bigger than jethro's

[Gary Thomas]

On 2016-05-13 09:23, Robert Yang wrote:



On 05/13/2016 03:07 PM, Andrea Adami wrote:

On Fri, May 13, 2016 at 8:48 AM, Robert Yang <liezhi.y...@windriver.com> wrote:


* For ext4:
   11M -> 26M
   The similar to vmdk, qcow2 and iso.

* For tar.bz2:
   2.7M -> 4.5M

The main problem is eudev-hwdb which would be 12M after installed, jethro
doesn't use this, but udev by default, and it's gone in krogoth.
$ du -sh core-image-minimal/1.0-r0/rootfs/etc/udev/*
0core-image-minimal/1.0-r0/rootfs/etc/udev/cache.data
6.4M core-image-minimal/1.0-r0/rootfs/etc/udev/hwdb.bin
5.2M core-image-minimal/1.0-r0/rootfs/etc/udev/hwdb.d
8.0K core-image-minimal/1.0-r0/rootfs/etc/udev/rules.d
4.0K core-image-minimal/1.0-r0/rootfs/etc/udev/udev.conf

Is there an easier way to fix this problem, please ? It's not a good
news for the user who uses core-imag-minimal/udev when they want to
upgrade to krogoth. And this would hurt the small device which uses
udev.



Somehow we have to explicitely opt-out:

+BAD_RECOMMENDATIONS += "eudev-hwdb"


Does udev still work without eudev-hwdb, please ?


Yes, it works fine, even with hotplug devices.



// Robert



IMHO for embedded devices it would be better to disable by default and
let the distro/machine add a specific RRECOMMEND.

Regards
Andrea



The conf is:
MACHINE = "qemux86-64"
DISTRO = "poky"
PACKAGE_CLASSES = "package_rpm"
EXTRA_IMAGE_FEATURES = "debug-tweaks"
USER_CLASSES = "buildstats image-mklibs"

$ bitbake core-image-minimal

For jethro:
$ ls -lh core-image-minimal-qemux86-64-20160513061306.rootfs.ext4
11M  core-image-minimal-qemux86-64-20160513061306.rootfs.ext4
$ du -sh core-image-minimal-qemux86-64-20160513061306.rootfs.ext4
7.9M core-image-minimal-qemux86-64-20160513061306.rootfs.ext4

For krogoth:

$ ls -lh core-image-minimal-qemux86-64-20160513061459.rootfs.ext4
26M core-image-minimal-qemux86-64-20160513061459.rootfs.ext4

$ du -sh core-image-minimal-qemux86-64-20160513061459.rootfs.ext4
core-image-minimal-qemux86-64-20160513061459.rootfs.ext4

--
Thanks

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





--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] matchbox-keyboard: Hide desktop launcher

[Gary Thomas]

On 2016-04-13 14:24, Maxin B. John wrote:

Hi,

On Wed, Apr 13, 2016 at 02:13:43PM +0200, Gary Thomas wrote:

On 2016-04-13 14:08, Jussi Kukkonen wrote:

On 13 April 2016 at 14:35, Gary Thomas <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:





Have you checked that your /etc/formfactor/machconfig contains 
"HAVE_KEYBOARD=0"? This value is used by
/etc/matchbox/session to decide whether to load the keyboard panel or not, and 
by .the Xsession script to decide whether
to start the daemonized keyboard or not.


Has this or any of the files it depends on (/etc/formfactor/*) changed recently?
As I said, as recently as mid February everything worked as expected, no longer.
If something changed that I need to track, I'm happy to adapt.



Yes, there was a change in Keyboard related logic in formfactor with this 
recent commit:

commit 463fd5ee26c5037b0f4ecfe4bc6ed48945b3b07e
Author: Ross Burton <ross.bur...@intel.com>
Date:   Thu Mar 3 16:56:43 2016 +

  formfactor: assume a keyboard is plugged in

  A sensible assumption is that BSPs have a USB keyboard and mouse connected
  unless told otherwise, so flip the logic in the formfactor config script that
  previously assumed that a keyboard was not connected by default.

  [ YOCTO #9174 ]

(From OE-Core rev: a82ce3e477a475dccea3837eabacd9e93b873ee6)


Wow, what an assumption!  Anyway, adding the correct machconfig for
my target fixes the problem.

Thanks for the pointer



  Signed-off-by: Ross Burton <ross.bur...@intel.com>
  Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
  
if [ -z "$HAVE_KEYBOARD" ]; then
  -HAVE_KEYBOARD=0
  +HAVE_KEYBOARD=1


Best Regards,
Maxin




--
--------
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] matchbox-keyboard: Hide desktop launcher

[Gary Thomas]

On 2016-04-13 14:08, Jussi Kukkonen wrote:

On 13 April 2016 at 14:35, Gary Thomas <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:

On 2016-04-12 10:14, Jussi Kukkonen wrote:

Add patch that hides the keyboard desktop launcher, remove patch that
tries and fails to make the keyboard a single-instance application.

The desktop launcher of matchbox-keyboard is a source of far more
problems than solutions: As an example there's supposed to be only
one instance running at a time but we give the user several ways to
start multiple instances (and the Matchbox WM Single-Instance
implementation is broken by both design and implementation).

After this patch the only instance of matchbox-keyboard is the
daemonized one that can be shown/hidden with the panel applet (when
there is not hardware keyboard). If an additional matchbox-keyboard
needs to be started for debug reasons, it can still be done from
command line.

Fixes [YOCTO #3093].

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com 
<mailto:jussi.kukko...@intel.com>>


Sadly, with this change (and the one it tries to fix), I no longer get
a pop-up matchbox keyboard on my touch-only device.  It used to work
great - any time I had a program wanting input, the keyboard would
appear until I pressed enter.  Now I get nothing and the keyboard icon
in the toolbar is also missing, so my touch based device (no physical
keyboard) is useless :-(

How can I get this behaviour back?  I tried bisecting the changes to find
the cause of the change, but it didn't really tell me much.


This commit _should_ not affect the panel applet or the daemonized keyboard, it 
really only hides the icon from the
desktop launcher.

Have you checked that your /etc/formfactor/machconfig contains 
"HAVE_KEYBOARD=0"? This value is used by
/etc/matchbox/session to decide whether to load the keyboard panel or not, and 
by .the Xsession script to decide whether
to start the daemonized keyboard or not.


Has this or any of the files it depends on (/etc/formfactor/*) changed recently?
As I said, as recently as mid February everything worked as expected, no longer.
If something changed that I need to track, I'm happy to adapt.


---

This change would have been nice to have much before release to give
people time to react (in the unlikely case that someone actually has a
reasonable use case for the launcher). Unfortunately I only thought of
this solution now.

Also available in the git repository at:

git://git.yoctoproject.org/poky-contrib 
<http://git.yoctoproject.org/poky-contrib> jku/hide-matchbox-keyboard

http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/hide-matchbox-keyboard

Cheers,
Jussi


   ...ktop-file-Hide-the-keyboard-from-app-list.patch | 33 
++
   .../matchbox-keyboard/files/single-instance.patch  | 23 
---
   .../matchbox-keyboard/matchbox-keyboard_git.bb 
<http://matchbox-keyboard_git.bb> |  2 +-
   3 files changed, 34 insertions(+), 24 deletions(-)
   create mode 100644

meta/recipes-sato/matchbox-keyboard/files/0001-desktop-file-Hide-the-keyboard-from-app-list.patch
   delete mode 100644 
meta/recipes-sato/matchbox-keyboard/files/single-instance.patch

diff --git 
a/meta/recipes-sato/matchbox-keyboard/files/0001-desktop-file-Hide-the-keyboard-from-app-list.patch

b/meta/recipes-sato/matchbox-keyboard/files/0001-desktop-file-Hide-the-keyboard-from-app-list.patch
new file mode 100644
index 000..6b7a5cf
--- /dev/null
+++ 
b/meta/recipes-sato/matchbox-keyboard/files/0001-desktop-file-Hide-the-keyboard-from-app-list.patch
@@ -0,0 +1,33 @@
+From 38da4cd575edb7463cfff241afff64c2f66ea09a Mon Sep 17 00:00:00 2001
+From: Jussi Kukkonen <jussi.kukko...@intel.com 
<mailto:jussi.kukko...@intel.com>>
+Date: Tue, 12 Apr 2016 09:40:37 +0300
+Subject: [PATCH] desktop file: Hide the keyboard from app list
+
+matchbox-keyboard is not a normal app and there's no need to start
+it via the desktop app grid when using Sato desktop:
+* when there's no hardware keyboard, the panel applet can be used to
+  show/hide the daemonized matchbox-keyboard
+* when there is a hardware keyboard, matchbox-keyboard can still be
+  started for debug purposes from command line or the applet can be
+  enabled by editing /etc/formfactor/machconfig
+
+So hide the keyboard from the desktop app list.
+
+Upstream-Status: Inappropriate [configuration]
+Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com 
<m

Re: [OE-core] [PATCH] matchbox-keyboard: Hide desktop launcher

[Gary Thomas]

   2010-12-22 
20:42:12.0 +0800
-@@ -6,3 +6,5 @@
- Icon=matchbox-keyboard.png
- Categories=Panel;Utility;MB
- X-MB-INPUT-MECHANSIM=True
-+X-MB-SingleInstance=true
-+StartupNotify=true
diff --git a/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb 
b/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb
index 183cba2..eba1970 100644
--- a/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb
+++ b/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb
@@ -15,7 +15,7 @@ PV = "0.0+git${SRCPV}"
  PR = "r4"

  SRC_URI = "git://git.yoctoproject.org/${BPN};branch=matchbox-keyboard-0-1 \
-   file://single-instance.patch \
+   file://0001-desktop-file-Hide-the-keyboard-from-app-list.patch \
 file://80matchboxkeyboard.sh"

  S = "${WORKDIR}/git"




--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [RFC PATCH 0/2] unique -dev package

[Gary Thomas]

On 2016-04-11 15:42, Denys Dmytriyenko wrote:

On Mon, Apr 11, 2016 at 09:35:48AM +0100, Richard Purdie wrote:

On Sun, 2016-04-10 at 21:49 -0400, Denys Dmytriyenko wrote:

On Mon, Apr 11, 2016 at 09:19:32AM +0800, Robert Yang wrote:

On 04/11/2016 06:51 AM, Denys Dmytriyenko wrote:

On Tue, Apr 07, 2015 at 05:58:13AM -0700, Robert Yang wrote:

Hello,

I think that one recipe should only have one -dev package, I'm
not sure
whether this is right or not, please feel free to give your
comments, we


I know it is already 1 year since this change. But I can't seem
to find any
discussion or any explanation to why this change was required and
what
specific problem it was supposed to fix. Please point me to a
clear reasoning
of this change. Thanks.


There is only one source package, so there should be only one pack
of header
files, dev libs, and so on, and they should be placed in a uniq
pkg.


Since you are using "should" twice in the same sentence, can you
please point
me to a ratified RFC?


I couldn't seem to see the history of this discussion in my mail folder
but I do remember some patches along these lines.

The reason for a single -dev package is that the "package chain"
functions we have assumes this. I know there are some specific cases
where we do have multiple -dev packages (qt4, gcc-runtime) but they are
very much in the minority and are special cases.

I'm definitely on record as saying the depchains code needs revisiting
and redoing, preferably with a structured rethink so that we can better
handle situations like this. Until that is done, multiple -dev packages
can cause issues and we did remove some where there didn't seem to be
any real benefit.

Which case is causing problems for you?


Thanks, Richard.

I was updating some of our old recipes to work with the latest code and had to
replace dependencies on libblah-dev to blah-dev as well as -staticdev and -dbg
in several places. When tried to dig up any relevant discussion on this matter
either as a discussion or clear explanation of the problem this causes, I
couldn't find any, hence my inquiry.



You might have been thinking about my problems with -dbg packaging that
currently breaks a number of dependencies.  Bug #9104

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] glib-2.0: Put glib-compile-schemas back in -utils

[Gary Thomas]

On 2016-04-11 13:07, Jussi Kukkonen wrote:

Commit cc97d576 moved a bunch of development tools to the -dev
package. glib-compile-schemas is actually used in postinst by
gsettings.bbclass so it needs to be available on target at package
install time: Move the tool back to glib-2.0-utils which
gsettings.bbclass depends on.

Fixes [YOCTO #9431].

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>


Looks like this fixes it, thanks.

Acked-by: Gary Thomas <g...@mlbassoc.com>


---

I also reviewed again the other tools that were moved in cc97d576:
this one seems like the only one that is needed at postinst.

Possibly glib-compile-schemas should be installed with the library
(like qio-querymodules now is) but I'd rather not do that at this
point in the release as it would mean other changes like moving
the binary install location.

This commit is also available in the git repository at:

   git://git.yoctoproject.org/poky-contrib jku/glib-compile-schemas


  meta/recipes-core/glib-2.0/glib.inc | 1 -
  1 file changed, 1 deletion(-)

diff --git a/meta/recipes-core/glib-2.0/glib.inc 
b/meta/recipes-core/glib-2.0/glib.inc
index 3a03191..e764fad 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -57,7 +57,6 @@ FILES_${PN}-dev += "${libdir}/glib-2.0/include \
  ${bindir}/glib-genmarshal \
  ${bindir}/glib-gettextize \
  ${bindir}/glib-mkenums \
-${bindir}/glib-compile-schemas \
  ${bindir}/glib-compile-resources \
  ${datadir}/glib-2.0/gettext/po/Makefile.in.in \
  ${datadir}/glib-2.0/schemas/gschema.dtd"




--
--------
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] Issues installing GTK based packages

[Gary Thomas]

When installing epiphany into an existing system, I'm now
getting these errors:
  Configuring libgtk-3.0.
  ///var/lib/opkg/info/libgtk-3.0.postinst: line 3: glib-compile-schemas: not 
found
  Configuring gsettings-desktop-schemas.
  ///var/lib/opkg/info/gsettings-desktop-schemas.postinst: line 2: 
glib-compile-schemas: not found
  Configuring epiphany.
  ///var/lib/opkg/info/epiphany.postinst: line 2: glib-compile-schemas: not 
found

I believe this is because glib-compile-schemas was moved from
glib-2.0-utils to glib-2.0-dev by this change (Poky)

commit cc97d5760100415ed22fa329e8962e5f37b8d741
Author: Jussi Kukkonen <jussi.kukko...@intel.com>
Date:   Wed Mar 23 10:59:08 2016 +0200

glib-2.0: Fix packaging

* move gdbus-codegen to ${PN}-codegen
* move other development tools and data files to ${PN}-dev
* remove references to non-existent paths

(From OE-Core rev: 351064e9c5deb6411c8a0d40ebd4fd4f83299d4e)

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>

Installing glib-2.0-dev just to get this tool doesn't seem reasonable as
it hauls in a boatload of other packages, including bash and friends, which
I don't want on my target.

Filed as bug #9431

--
--------
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH 0/2] Fixes for len(TMPDIR) == 410

[Gary Thomas]

On 2016-04-06 11:30, Robert Yang wrote:

The following changes since commit b2dc5a68e74dafedf7960ef77ad3d73912ed7960:

   bdwgc: use github repo for source location (2016-04-05 11:48:09 +0100)

are available in the git repository at:

   git://git.openembedded.org/openembedded-core-contrib rbt/long
   
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/long

Robert Yang (2):
   sanity.bbclass: fix a hardcode in check_path_length()
   wget: fix build when len(TMPDIR) == 410

  meta/classes/sanity.bbclass | 2 +-
  meta/recipes-extended/wget/wget.inc | 5 +
  2 files changed, 6 insertions(+), 1 deletion(-)



How are these patches related and what is magic about a path length of 410?
Are you sure that it might not be 569 on my system for example?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Change in udev

[Gary Thomas]

On 2016-03-24 11:30, Burton, Ross wrote:


On 24 March 2016 at 10:27, Gary Thomas <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:

More recent than poky:2df514bfe4a911c0dca8828038dd94e6265f50ca?


In that case the file should have been generated at build time (please file a 
bug with logs if it wasn't) and is in a
separate package so if you don't need it (its basically the USB and PCI ID 
tables) then you can remove it.

As you say, eudev is new, so there's bound to be small configuration issues to 
work out before release.


Ah, interesting.  The file is in my rootfs, but it doesn't belong
to any package?

This is from my build:

$ ls -l 
tmp/work/teton_p0382-amltd-linux-gnueabi/amanda-server-image/1.0-r0/rootfs/etc/udev/
total 6532
-rw-r--r-- 1 gthomas gthomas   0 Mar 24 07:41 cache.data
-r--r--r-- 1 gthomas gthomas 6660476 Mar 24 09:21 hwdb.bin
drwxr-xr-x 2 gthomas gthomas4096 Mar 24 07:42 hwdb.d
-rw-r--r-- 1 gthomas gthomas  51 Mar 24 08:51 mount.blacklist
drwxr-xr-x 2 gthomas gthomas4096 Mar 24 08:51 mount.blacklist.d
drwxr-xr-x 2 gthomas gthomas4096 Mar 24 09:21 rules.d
drwxr-xr-x 2 gthomas gthomas4096 Mar 24 08:51 scripts
-rw-r--r-- 1 gthomas gthomas  49 Mar 24 07:41 udev.conf

On my target:

root@teton-p0382:~# opkg search /etc/udev/hwdb.bin
root@teton-p0382:~#

I seem to have gotten the hwdb, but not packaged correctly.  Again, on the 
target:

root@teton-p0382:~# opkg list-installed *udev*
eudev - 3.1.5-r0.2
eudev-hwdb - 3.1.5-r0.2
libudev1 - 3.1.5-r0.2
udev-cache - 3.1.5-r0.2
udev-extraconf - 1.1-r0.6
udev-rules-imx - 1.0-r0.6
root@teton-p0382:~# opkg files eudev-hwdb
Package eudev-hwdb (3.1.5-r0.2) is installed on root and has the following 
files:
/etc/udev/hwdb.d/20-pci-classes.hwdb
/etc/udev/hwdb.d/70-pointingstick.hwdb
/etc/udev/hwdb.d/70-mouse.hwdb
/etc/udev/hwdb.d/
/etc/udev/hwdb.d/20-acpi-vendor.hwdb
/etc/udev/hwdb.d/20-usb-vendor-model.hwdb
/etc/udev/hwdb.d/20-sdio-vendor-model.hwdb
/etc/udev/hwdb.d/60-keyboard.hwdb
/etc/udev/hwdb.d/20-net-ifname.hwdb
/etc/udev/hwdb.d/20-usb-classes.hwdb
/etc/udev/hwdb.d/20-bluetooth-vendor-product.hwdb
/etc/udev/hwdb.d/60-evdev.hwdb
/etc/udev/hwdb.d/20-pci-vendor-model.hwdb
/etc/udev/hwdb.d/20-sdio-classes.hwdb
/etc/udev/hwdb.d/20-OUI.hwdb

So /etc/udev/hwdb.bin is somehow unpackaged (an orphan)?

Also, how will I prevent eudev-hwdb from being sucked in if I
only depend [RDEPENDS/RRECOMMENDS] on 'udev'?

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Change in udev

[Gary Thomas]

On 2016-03-24 11:23, Burton, Ross wrote:


On 24 March 2016 at 09:45, Gary Thomas <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:

Is this [somehow] equivalent to the old udev device cache?
Does it really belong in /etc/udev?  What about read-only roots?


An update to current master will help: the file is generated at build time and 
in a separate package so if you don't
need it you can not install it.


More recent than poky:2df514bfe4a911c0dca8828038dd94e6265f50ca?

(I just updated a few hours ago)

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] Change in udev

[Gary Thomas]

I know that udev is being replaced by eudev, but there's a new
behavior I don't understand.  There is a new file /etc/udev/hwdb.bin
that is created at runtime:

$ ls -l /etc/udev
total 6548
-rw-r--r-- 1 root root1785 Jan  9  1970 cache.data
-r--r--r-- 1 root root 6660476 Mar 24 08:21 hwdb.bin
drwxr-xr-x 2 root root4096 Mar 24 06:42 hwdb.d
-rw-r--r-- 1 root root  51 Mar 24 07:51 mount.blacklist
drwxr-xr-x 2 root root4096 Mar 24 07:51 mount.blacklist.d
drwxr-xr-x 2 root root4096 Mar 24 08:21 rules.d
drwxr-xr-x 2 root root4096 Mar 24 07:51 scripts
-rw-r--r-- 1 root root  49 Mar 24 06:41 udev.conf

Is this [somehow] equivalent to the old udev device cache?
Does it really belong in /etc/udev?  What about read-only roots?

Thanks

n.b. I just noticed because a dump of /etc on my device went
from ~6MB to over 12MB...

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Problems with perl 5.22

[Gary Thomas]

On 03/10/2016 04:54 PM, Jens Rehsack wrote:



Am 10.03.2016 um 06:13 schrieb Gary Thomas <g...@mlbassoc.com>:

I'm working on a package (amanda - the Advanced Maryland Archiving
system) that is written heavily in perl with swig interfaces to C.
This code ran great until the update to perl 5.22; it now dies a
horrible death on almost every activity.  These failures seem to
always be in the swig generated wrappers, but that may just be
where most of the work gets done.

I've narrowed this down to exactly the change to perl 5.22 from
5.20. Using bisect as well as experimentation (e.g. trying all
the compiler combinations that have occurred since a last good
version) and I can go from working to failing by only the change
in perl.

The interesting (scary) thing is that I've built amanda for my
target natively on my board running debian, including perl 5.22.
This means I can't say definitively  that perl 5.22 is the culprit
as on debian it runs fine.  So, it's got something to do with the
OE environment/porting/packaging of perl and not just the revision.

I've also tested this on multiple architectures (ARM, PowerPC) with
the same results - with perl 5.20 amanda works, with perl 5.22 it fails.

I've compared the actual 5.22.1 sources used by OE-core and debian
and they are subtly different, although I can't pinpoint any change
that might be responsible.

For the moment, I can just fall back to perl 5.20 for my target
that needs to run amanda, but this isn't a real solution (e.g.
in this state I can't propose my recipe to any layer as it's
totally broken with the current OE-core).  I'd like to see this
fixed but the amanda code (swig wrappers) are horribly complex
which makes debugging quite the challenge, not to mention they
may be about the only way to uncover the bug, whether it's in
amanda or perl.

Any suggestions on how to move forward?


Since I have no clue what's wrong and how it fails (backtrace
would point in some directions), several ideas might work:

How clean is your build location (we realize that often between
updates some files remain in our target images until we wipe
tmp/ - cleansstate for image doesn't help ...)?

Did you prove the library path's of your *.so's? Perl does
almost everything within libperl.so - build against wrong version
causes in weird crashes (scan DBI mailing list for admin's
build issues of DBI on AIX/HP-UX ...).

Maybe share your recipe can help to reproduce the problem
elsewhere and debug locally.


I've spent quite a lot of time trying to come up with debuggable
scenario(s) on many different targets.  This is all packed up in
  https://github.com/GaryThomas/meta-amanda

If you give the README a look, you'll see that there are plenty
of issues to be looked at.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Problems with perl 5.22

[Gary Thomas]

On 2016-03-10 16:54, Jens Rehsack wrote:



Am 10.03.2016 um 06:13 schrieb Gary Thomas <g...@mlbassoc.com>:

I'm working on a package (amanda - the Advanced Maryland Archiving
system) that is written heavily in perl with swig interfaces to C.
This code ran great until the update to perl 5.22; it now dies a
horrible death on almost every activity.  These failures seem to
always be in the swig generated wrappers, but that may just be
where most of the work gets done.

I've narrowed this down to exactly the change to perl 5.22 from
5.20. Using bisect as well as experimentation (e.g. trying all
the compiler combinations that have occurred since a last good
version) and I can go from working to failing by only the change
in perl.

The interesting (scary) thing is that I've built amanda for my
target natively on my board running debian, including perl 5.22.
This means I can't say definitively  that perl 5.22 is the culprit
as on debian it runs fine.  So, it's got something to do with the
OE environment/porting/packaging of perl and not just the revision.

I've also tested this on multiple architectures (ARM, PowerPC) with
the same results - with perl 5.20 amanda works, with perl 5.22 it fails.

I've compared the actual 5.22.1 sources used by OE-core and debian
and they are subtly different, although I can't pinpoint any change
that might be responsible.

For the moment, I can just fall back to perl 5.20 for my target
that needs to run amanda, but this isn't a real solution (e.g.
in this state I can't propose my recipe to any layer as it's
totally broken with the current OE-core).  I'd like to see this
fixed but the amanda code (swig wrappers) are horribly complex
which makes debugging quite the challenge, not to mention they
may be about the only way to uncover the bug, whether it's in
amanda or perl.

Any suggestions on how to move forward?


Since I have no clue what's wrong and how it fails (backtrace
would point in some directions), several ideas might work:


The problem here is that the failures happen in the swig generated
files which are very difficult to debug (and don't really track
in the -dbg packages)



How clean is your build location (we realize that often between
updates some files remain in our target images until we wipe
tmp/ - cleansstate for image doesn't help ...)?


100% clean, I've started from scratch many times



Did you prove the library path's of your *.so's? Perl does
almost everything within libperl.so - build against wrong version
causes in weird crashes (scan DBI mailing list for admin's
build issues of DBI on AIX/HP-UX ...).


As I said, this all works fine when I build [from scratch] with
perl-5.20 and not [from scratch] with perl 5.22



Maybe share your recipe can help to reproduce the problem
elsewhere and debug locally.



I'd be happy to share, perhaps privately if you're inclined?
It's a complicated setup and testing can be a bit tedious, but
I'm happy for any help.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] Problems with perl 5.22

[Gary Thomas]

I'm working on a package (amanda - the Advanced Maryland Archiving
system) that is written heavily in perl with swig interfaces to C.
This code ran great until the update to perl 5.22; it now dies a
horrible death on almost every activity.  These failures seem to
always be in the swig generated wrappers, but that may just be
where most of the work gets done.

I've narrowed this down to exactly the change to perl 5.22 from
5.20. Using bisect as well as experimentation (e.g. trying all
the compiler combinations that have occurred since a last good
version) and I can go from working to failing by only the change
in perl.

The interesting (scary) thing is that I've built amanda for my
target natively on my board running debian, including perl 5.22.
This means I can't say definitively  that perl 5.22 is the culprit
as on debian it runs fine.  So, it's got something to do with the
OE environment/porting/packaging of perl and not just the revision.

I've also tested this on multiple architectures (ARM, PowerPC) with
the same results - with perl 5.20 amanda works, with perl 5.22 it fails.

I've compared the actual 5.22.1 sources used by OE-core and debian
and they are subtly different, although I can't pinpoint any change
that might be responsible.

For the moment, I can just fall back to perl 5.20 for my target
that needs to run amanda, but this isn't a real solution (e.g.
in this state I can't propose my recipe to any layer as it's
totally broken with the current OE-core).  I'd like to see this
fixed but the amanda code (swig wrappers) are horribly complex
which makes debugging quite the challenge, not to mention they
may be about the only way to uncover the bug, whether it's in
amanda or perl.

Any suggestions on how to move forward?

Thanks for your thoughts

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Recovering GCC 4.8

[Gary Thomas]

On 2016-02-19 09:02, Phil Blundell wrote:

On Fri, 2016-02-19 at 07:37 +0100, Gary Thomas wrote:

| checking for suffix of object files... configure: error: in
`/local/p0381_2016-02-19/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libgcc-initial/4.8.4-r0/gcc-4.8.4/build.arm-amltd-linux-gnueabi.arm-amltd-linux-gnueabi/libgcc':
| configure: error: cannot compute suffix of object files: cannot compile
| See `config.log' for more details.


I suspect you probably have some or other option set in CC or CFLAGS
that gcc-4.8 doesn't support.  What does it say in config.log?


It's complaining about an illegal -march=armv7ve, which seems to have
been added since I last built for this machine with GCC 4.8:

commit c6a19917ec5350cdfc4053d14462609782613bbc
Author: Martin Jansa <martin.ja...@gmail.com>
Date:   Tue Oct 6 17:08:59 2015 +0200

arch-armv7ve: add tune include for armv7ve and use it from cortexa7 and 
cortexa15

I'll see what I can do with this.  Duh, I should have looked at
the config.log before raising flags!

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] Recovering GCC 4.8

[Gary Thomas]

I have a need for GCC 4.8 which was recently dropped from OE-core.

commit d9aabf9639510fdb3e2ccc21ba5ae4aa9f6e4a57
Author: Richard Purdie <richard.pur...@linuxfoundation.org>
Date:   Wed Nov 11 08:50:02 2015 -0800

gcc: Drop 4.8

We have 5.2 and 4.9, we don't really need 4.8 now and it can be moved
out to other layers if anyone still wants/needs it.

(From OE-Core rev: 6f98c39418c60b7c0b25b30983d2e5257158a6a4)

I tried to recover this by merging from the parent revision
(poky 2cb1aee04) all of the files mentioned in this change
into my local layer.  Sadly, it does not build, but fails
rather early on (I'm building for Freescale LS1 cortexa7hf)

| checking for arm-amltd-linux-gnueabi-gcc... arm-amltd-linux-gnueabi-gcc  -march=armv7ve -mfpu=neon  -mfloat-abi=hard 
-mcpu=cortex-a7 --sysroot=/local/p0381_2016-02-19/tmp/sysroots/teton-p0381
| checking for suffix of object files... configure: error: in 
`/local/p0381_2016-02-19/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libgcc-initial/4.8.4-r0/gcc-4.8.4/build.arm-amltd-linux-gnueabi.arm-amltd-linux-gnueabi/libgcc':

| configure: error: cannot compute suffix of object files: cannot compile
| See `config.log' for more details.
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at 
/local/p0381_2016-02-19/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libgcc-initial/4.8.4-r0/temp/log.do_configure.9193)
ERROR: Task 1484 (/local/poky-cutting-edge/meta-amltd/recipes-devtools/gcc/libgcc-initial_4.8.bb, do_configure) failed 
with exit code '1'


Any ideas how I can get this to build?  I looked for some other
layer to which this might have been moved, but did not find any.

Thanks

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] ffmpeg: Add -dbg packages for all libraries

[Gary Thomas]

On 2016-02-12 09:32, Richard Purdie wrote:

On Fri, 2016-02-12 at 09:29 +0100, Gary Thomas wrote:

On 2016-02-12 09:17, Richard Purdie wrote:

On Fri, 2016-02-12 at 04:58 +0100, Gary Thomas wrote:

Improve the packaging of the libraries built by this recipe.
  These
are created using special code in the recipe and the debug (-dbg)
packages were not being created.  Adding these packages allow the
libraries in question to be debugged using GDB.


This isn't really policy, the policy is one -dbg package per recipe
and
that is how the dependency chains and dbg-pkgs in IMAGE_FEATURES
work
and so on.

I'm not arguing this is perfect, its not and I would like to see it
change. It is how it all works today though. Is there a pressing
reason
we need to do something different here?


Without this change, none of the [renamed] libraries generated by
the ffmpeg recipe have debug symbols available.  As is, the recipe
is generating separate -dev packages for each library - how is that
different [policy-wise]?

Should the -dev and -dbg info for the libraries be bundled into
ffmpeg-dbg and ffmpeg-dev?  Or perhaps the machinations generating
the -dev packages in that recipe are just wrong?


There should only be one -dev package too.

As you saying the debug symbols are getting placed into the -dev
packages? They must be getting placed and hence packaged somewhere?


I'm not sure where they were going before this change.

It does look like this recipe is packaging things incorrectly, at
least against policy.  I think the biggest thing they were attempting
to achieve was packaging of static development libraries (*.a) in
their own packages.  Should all of this just be in ffmpeg-dev?

I could try just disabling their special packaging and see how well
it works.


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] ffmpeg: Add -dbg packages for all libraries

[Gary Thomas]

On 2016-02-12 09:37, Gary Thomas wrote:

On 2016-02-12 09:32, Richard Purdie wrote:

On Fri, 2016-02-12 at 09:29 +0100, Gary Thomas wrote:

On 2016-02-12 09:17, Richard Purdie wrote:

On Fri, 2016-02-12 at 04:58 +0100, Gary Thomas wrote:

Improve the packaging of the libraries built by this recipe.
  These
are created using special code in the recipe and the debug (-dbg)
packages were not being created.  Adding these packages allow the
libraries in question to be debugged using GDB.


This isn't really policy, the policy is one -dbg package per recipe
and
that is how the dependency chains and dbg-pkgs in IMAGE_FEATURES
work
and so on.

I'm not arguing this is perfect, its not and I would like to see it
change. It is how it all works today though. Is there a pressing
reason
we need to do something different here?


Without this change, none of the [renamed] libraries generated by
the ffmpeg recipe have debug symbols available.  As is, the recipe
is generating separate -dev packages for each library - how is that
different [policy-wise]?

Should the -dev and -dbg info for the libraries be bundled into
ffmpeg-dbg and ffmpeg-dev?  Or perhaps the machinations generating
the -dev packages in that recipe are just wrong?


There should only be one -dev package too.

As you saying the debug symbols are getting placed into the -dev
packages? They must be getting placed and hence packaged somewhere?


I'm not sure where they were going before this change.

It does look like this recipe is packaging things incorrectly, at
least against policy.  I think the biggest thing they were attempting
to achieve was packaging of static development libraries (*.a) in
their own packages.  Should all of this just be in ffmpeg-dev?

I could try just disabling their special packaging and see how well
it works.




Policy notwithstanding, there are a lot of lib*-dbg* packages generated
by non-lib* recipes, so my solution doesn't seem so out of place to me.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] ffmpeg: Add -dbg packages for all libraries

[Gary Thomas]

On 2016-02-12 11:49, Burton, Ross wrote:


On 12 February 2016 at 03:58, Gary Thomas <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:

Improve the packaging of the libraries built by this recipe.  These
are created using special code in the recipe and the debug (-dbg)
packages were not being created.  Adding these packages allow the
libraries in question to be debugged using GDB.


oe-pkgdata-utils says:

ffmpeg-dbg:
 /usr/bin/.debug/ffmpeg
 /usr/bin/.debug/ffprobe
 /usr/bin/.debug/ffserver
 /usr/lib/.debug/libavcodec.so.56.60.100
 /usr/lib/.debug/libavdevice.so.56.4.100
 /usr/lib/.debug/libavfilter.so.5.40.101
 /usr/lib/.debug/libavformat.so.56.40.101
 /usr/lib/.debug/libavutil.so.54.31.100
 /usr/lib/.debug/libpostproc.so.53.3.100
 /usr/lib/.debug/libswresample.so.1.2.101
 /usr/lib/.debug/libswscale.so.3.1.101

So I'm not sure why this would be needed.



I'll check again, maybe it's as simple as ffmpeg-dbg wasn't
brought in as an automatic dependency of mplayer2-dbg although
a bunch of others were.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] ffmpeg: Add -dbg packages for all libraries

[Gary Thomas]

On 2016-02-12 12:03, Gary Thomas wrote:

On 2016-02-12 11:49, Burton, Ross wrote:


On 12 February 2016 at 03:58, Gary Thomas <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:

Improve the packaging of the libraries built by this recipe.  These
are created using special code in the recipe and the debug (-dbg)
packages were not being created.  Adding these packages allow the
libraries in question to be debugged using GDB.


oe-pkgdata-utils says:

ffmpeg-dbg:
 /usr/bin/.debug/ffmpeg
 /usr/bin/.debug/ffprobe
 /usr/bin/.debug/ffserver
 /usr/lib/.debug/libavcodec.so.56.60.100
 /usr/lib/.debug/libavdevice.so.56.4.100
 /usr/lib/.debug/libavfilter.so.5.40.101
 /usr/lib/.debug/libavformat.so.56.40.101
 /usr/lib/.debug/libavutil.so.54.31.100
 /usr/lib/.debug/libpostproc.so.53.3.100
 /usr/lib/.debug/libswresample.so.1.2.101
 /usr/lib/.debug/libswscale.so.3.1.101

So I'm not sure why this would be needed.



I'll check again, maybe it's as simple as ffmpeg-dbg wasn't
brought in as an automatic dependency of mplayer2-dbg although
a bunch of others were.



That's definitely it.  When I install mplayer2-dbg which was has
ffmpeg in DEPENDS, the library debug info was not found and ffmpeg-dbg
was not installed:

# opkg install mplayer2-dbg
Installing mplayer2-dbg (2.0+gitr0+2c378c71a4-r13.1) on root.
mplayer2-dbg: unsatisfied recommendation for libavformat-dbg
mplayer2-dbg: unsatisfied recommendation for libavutil-dbg
mplayer2-dbg: unsatisfied recommendation for libfaad-dbg
mplayer2-dbg: unsatisfied recommendation for libasound-dbg
mplayer2-dbg: unsatisfied recommendation for libavcodec-dbg
mplayer2-dbg: unsatisfied recommendation for libswresample-dbg
mplayer2-dbg: unsatisfied recommendation for libpostproc-dbg
mplayer2-dbg: unsatisfied recommendation for ncurses-libtinfo-dbg
mplayer2-dbg: unsatisfied recommendation for libswscale-dbg
...

So, how should this have worked, or is it a little broken?

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] ffmpeg: Add -dbg packages for all libraries

[Gary Thomas]

On 2016-02-12 09:17, Richard Purdie wrote:

On Fri, 2016-02-12 at 04:58 +0100, Gary Thomas wrote:

Improve the packaging of the libraries built by this recipe.  These
are created using special code in the recipe and the debug (-dbg)
packages were not being created.  Adding these packages allow the
libraries in question to be debugged using GDB.


This isn't really policy, the policy is one -dbg package per recipe and
that is how the dependency chains and dbg-pkgs in IMAGE_FEATURES work
and so on.

I'm not arguing this is perfect, its not and I would like to see it
change. It is how it all works today though. Is there a pressing reason
we need to do something different here?


Without this change, none of the [renamed] libraries generated by
the ffmpeg recipe have debug symbols available.  As is, the recipe
is generating separate -dev packages for each library - how is that
different [policy-wise]?

Should the -dev and -dbg info for the libraries be bundled into
ffmpeg-dbg and ffmpeg-dev?  Or perhaps the machinations generating
the -dev packages in that recipe are just wrong?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] ffmpeg: Add -dbg packages for all libraries

[Gary Thomas]

On 2016-02-12 12:15, Burton, Ross wrote:


On 12 February 2016 at 11:11, Gary Thomas <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:

# opkg install mplayer2-dbg
Installing mplayer2-dbg (2.0+gitr0+2c378c71a4-r13.1) on root.
mplayer2-dbg: unsatisfied recommendation for libavformat-dbg
mplayer2-dbg: unsatisfied recommendation for libavutil-dbg
mplayer2-dbg: unsatisfied recommendation for libfaad-dbg
mplayer2-dbg: unsatisfied recommendation for libasound-dbg
mplayer2-dbg: unsatisfied recommendation for libavcodec-dbg
mplayer2-dbg: unsatisfied recommendation for libswresample-dbg
mplayer2-dbg: unsatisfied recommendation for libpostproc-dbg
mplayer2-dbg: unsatisfied recommendation for ncurses-libtinfo-dbg
mplayer2-dbg: unsatisfied recommendation for libswscale-dbg
...

So, how should this have worked, or is it a little broken?


Well it *should* have worked, but clearly isn't!  Can you file a bug?


I already had, albeit with slightly different wording:
  https://bugzilla.yoctoproject.org/show_bug.cgi?id=9104

I don't have one at hand, but maybe I'll try using different packaging,
e.g. RPM, to see if there is a difference in how this is handled.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] [PATCH] ffmpeg: Add -dbg packages for all libraries

[Gary Thomas]

Improve the packaging of the libraries built by this recipe.  These
are created using special code in the recipe and the debug (-dbg)
packages were not being created.  Adding these packages allow the
libraries in question to be debugged using GDB.

Signed-off-by: Gary Thomas <g...@mlbassoc.com>
---
 meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.5.bb | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.5.bb 
b/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.5.bb
index 7107803..524b5cb 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.5.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_2.8.5.bb
@@ -75,7 +75,7 @@ do_configure() {
 }
 
 RSUGGESTS_${PN} = "mplayer"
-PACKAGES_DYNAMIC += "^lib(av(codec|device|filter|format|util)|swscale).*"
+PACKAGES_DYNAMIC += 
"^lib(av(codec|device|filter|format|util)|postproc|swresample|swscale).*"
 
 python populate_packages_prepend() {
 av_libdir = d.expand('${libdir}')
@@ -108,4 +108,12 @@ python populate_packages_prepend() {
   prepend=True,
   allow_links=True)
 
+# Debug packages (-dbg)
+do_split_packages(d, av_libdir, '^lib(.*)\.so$',
+  output_pattern='lib%s-dbg',
+  description='libav %s debug package',
+  extra_depends='${PN}-dbg',
+  prepend=True,
+  allow_links=True)
+
 }
-- 
2.5.0

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

[OE-core] Error building glib

[Gary Thomas]

Using master as of 2015-12-16 (f1f3716776078d68bd9e3734bca881a486dc2ea3)
I get this error:

ERROR: Command Error: exit status: 1  Output:
Applying patch allow-deprecated.patch
patching file Makefile.am
Hunk #1 succeeded at 18 (offset -5 lines).
patching file gio/fam/Makefile.am
Hunk #1 succeeded at 13 (offset -10 lines).
can't find file to patch at input line 31
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|Index: glib-2.36.0/gio/fen/Makefile.am
|===
|--- glib-2.36.0.orig/gio/fen/Makefile.am
|+++ glib-2.36.0/gio/fen/Makefile.am
--
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
patching file gio/inotify/Makefile.am
Hunk #1 succeeded at 24 (offset -4 lines).
patching file gio/kqueue/Makefile.am
Hunk #1 succeeded at 28 (offset -4 lines).
patching file gio/win32/Makefile.am
patching file gmodule/Makefile.am
patching file Makefile.in
Hunk #1 succeeded at 840 with fuzz 1 (offset 368 lines).
patching file gio/fam/Makefile.in
Hunk #1 succeeded at 787 (offset 354 lines).
can't find file to patch at input line 111
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|Index: glib-2.36.0/gio/fen/Makefile.in
|===
|--- glib-2.36.0.orig/gio/fen/Makefile.in
|+++ glib-2.36.0/gio/fen/Makefile.in
--
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
patching file gio/inotify/Makefile.in
Hunk #1 succeeded at 798 with fuzz 2 (offset 389 lines).
patching file gio/kqueue/Makefile.in
Hunk #1 succeeded at 802 with fuzz 2 (offset 389 lines).
patching file gio/win32/Makefile.in
Hunk #1 succeeded at 800 with fuzz 2 (offset 395 lines).
patching file gmodule/Makefile.in
Hunk #1 succeeded at 785 with fuzz 1 (offset 366 lines).
Patch allow-deprecated.patch does not apply (enforce with -f)
ERROR: Function failed: patch_do_patch
ERROR: Logfile of failure stored in: 
/local/p0382_2015-12-16/tmp/work/cortexa9hf-vfp-neon-amltd-linux-gnueabi/glib-2.0/1_2.46.1-r0/temp/log.do_patch.7269
ERROR: Task 2389 
(/local/poky-cutting-edge/meta/recipes-core/glib-2.0/glib-2.0_2.46.1.bb, 
do_patch) failed with exit code '1'

Any ideas?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Error building glib

[Gary Thomas]

On 2015-12-16 08:10, Burton, Ross wrote:


On 16 December 2015 at 14:49, Gary Thomas <g...@mlbassoc.com 
<mailto:g...@mlbassoc.com>> wrote:

Using master as of 2015-12-16 (f1f3716776078d68bd9e3734bca881a486dc2ea3)
I get this error:

ERROR: Command Error: exit status: 1  Output:
Applying patch allow-deprecated.patch


Looks like you have a layer with a bbappend for glib-2.0, as master's glib-2.0 
doesn't have that patch:


I didn't think to look for that.  Oh the perils of % in recipe names.

Thanks



SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz \
file://configure-libtool.patch \
file://fix-conflicting-rand.patch \
file://add-march-i486-into-CFLAGS-automatically.patch \
file://glib-2.0-configure-readlink.patch \
file://run-ptest \
file://ptest-paths.patch \
file://uclibc.patch \

file://0001-configure.ac-Do-not-use-readlink-when-cross-compilin.patch \
file://allow-run-media-sdX-drive-mount-if-username-root.patch \
   file://0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch \
   file://0001-gio-tests-Don-t-depend-on-a-data-file-that-s-not-bui.patch \
file://Enable-more-tests-while-cross-compiling.patch \
   "

In fact that revision isn't a poky or oe-core commit.

The problem is that allow-deprecated.patch is patching generated files.  Remove 
all hunks that touch Makefile.in.

Ross


--
--------
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] x11vnc: move recipe to meta-oe

[Gary Thomas]

On 2015-10-16 08:44, Martin Jansa wrote:

On Fri, Oct 16, 2015 at 08:40:10AM -0600, Gary Thomas wrote:

On 2015-10-16 08:25, Ioan-Adrian Ratiu wrote:

x11vnc can be configured with --use-system-libvncserver to use an
external libvncserver which will be added to meta-oe. Since oe-core
should not depend on meta-oe, we move x11vnc there.

Signed-off-by: Ioan-Adrian Ratiu <adrian.ra...@ni.com>


Just curious why not the other way - move libvncserver to OE-core?
x11vnc seems like one of the very few [and useful] X based tools that
are present in OE-core that it seems like a huge step backwards to
move it out.


It was discussed in "[OE-core] [oe] [meta-oe][PATCH v2] meta-oe:
recipes-graphics: add libvncserver recipe" thread and I agree with
Otavio that x11vnc doesn't look so fundamental component used by most
embedded builds to deserver being in the core.


Well, I tend to disagree and I don't think there has really been a
discussion - only one "no" (Otavio) and one "I don't know" (Paul).

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] x11vnc: move recipe to meta-oe

[Gary Thomas]

On 2015-10-16 09:29, Otavio Salvador wrote:

On Fri, Oct 16, 2015 at 12:21 PM, Gary Thomas <g...@mlbassoc.com> wrote:

On 2015-10-16 08:44, Martin Jansa wrote:


On Fri, Oct 16, 2015 at 08:40:10AM -0600, Gary Thomas wrote:


On 2015-10-16 08:25, Ioan-Adrian Ratiu wrote:


x11vnc can be configured with --use-system-libvncserver to use an
external libvncserver which will be added to meta-oe. Since oe-core
should not depend on meta-oe, we move x11vnc there.

Signed-off-by: Ioan-Adrian Ratiu <adrian.ra...@ni.com>



Just curious why not the other way - move libvncserver to OE-core?
x11vnc seems like one of the very few [and useful] X based tools that
are present in OE-core that it seems like a huge step backwards to
move it out.



It was discussed in "[OE-core] [oe] [meta-oe][PATCH v2] meta-oe:
recipes-graphics: add libvncserver recipe" thread and I agree with
Otavio that x11vnc doesn't look so fundamental component used by most
embedded builds to deserver being in the core.


Well, I tend to disagree and I don't think there has really been a
discussion - only one "no" (Otavio) and one "I don't know" (Paul).


The recipe being in meta-oe, can be used anyway. It is just out of OE-Core.

Anyway, what x11vnc has to provide to a core system? it even requires
X11 which a lot of embedded systems are moving away from...



Maybe for you, but not my customers - most of them insist on it.

Yes, x11nvc in meta-oe is an answer, but I don't want to have to
drag in meta-oe (way too heavy for my tastes) just to be able to
use it (I use it all the time to debug customer systems that I only
have remote access to)...

Maybe we should abandon Python or GDB (server) from OE-core as they
aren't used by all systems either??

--
--------
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] x11vnc: move recipe to meta-oe

[Gary Thomas]

On 2015-10-16 08:25, Ioan-Adrian Ratiu wrote:

x11vnc can be configured with --use-system-libvncserver to use an
external libvncserver which will be added to meta-oe. Since oe-core
should not depend on meta-oe, we move x11vnc there.

Signed-off-by: Ioan-Adrian Ratiu <adrian.ra...@ni.com>


Just curious why not the other way - move libvncserver to OE-core?
x11vnc seems like one of the very few [and useful] X based tools that
are present in OE-core that it seems like a huge step backwards to
move it out.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] pxz: Add recipe and use it for xz image type

[Gary Thomas]

On 2015-09-24 22:59, Khem Raj wrote:

pxz results in significant time saving when generating xz filetypes for
images due to parallelization support


This adds another host tool dependency - on my Ubuntu (14.04) system, even
if 'xz' is installed, 'pxz' is not and I'd have to add it.  Since *.xz seems
to be the new fashion/trend, perhaps this choice might be optional/configurable?



a simple test on ubuntu build host with 16 CPUs

time xz -M 50% -f -k -c -e -9 --check=crc32 
CX041AEI_PROD_default_2015061105sdy-dbg.rootfs.cpio 
>CX041AEI_PROD_default_2015061105sdy-dbg.rootfs.cpio.xz

real
23m42.299s
user 23m36.947s
sys 0m5.101s

time pxz -M 50% -f -k -c -e -9 --check=crc32 
CX041AEI_PROD_default_2015061105sdy-dbg.rootfs.cpio 
>CX041AEI_PROD_default_2015061105sdy-dbg.rootfs.cpio.xz

real2m59.666s
user 24m38.529s
sys 0m10.056s

Signed-off-by: Khem Raj <raj.k...@gmail.com
---
  meta/classes/image_types.bbclass |  4 ++--
  meta/recipes-extended/pxz/pxz_git.bb | 31 +++
  2 files changed, 33 insertions(+), 2 deletions(-)
  create mode 100644 meta/recipes-extended/pxz/pxz_git.bb

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 306403e..d766cd2 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -233,13 +233,13 @@ COMPRESSIONTYPES = "gz bz2 lzma xz lz4 sum"
  COMPRESS_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}.rootfs.${type}"
  COMPRESS_CMD_gz = "gzip -f -9 -c ${IMAGE_NAME}.rootfs.${type} > 
${IMAGE_NAME}.rootfs.${type}.gz"
  COMPRESS_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}.rootfs.${type}"
-COMPRESS_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_THREADS} 
--check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}.rootfs.${type} > 
${IMAGE_NAME}.rootfs.${type}.xz"
+COMPRESS_CMD_xz = "pxz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_THREADS} 
--check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}.rootfs.${type} > 
${IMAGE_NAME}.rootfs.${type}.xz"
  COMPRESS_CMD_lz4 = "lz4c -9 -c ${IMAGE_NAME}.rootfs.${type} > 
${IMAGE_NAME}.rootfs.${type}.lz4"
  COMPRESS_CMD_sum = "sumtool -i ${IMAGE_NAME}.rootfs.${type} -o 
${IMAGE_NAME}.rootfs.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
  COMPRESS_DEPENDS_lzma = "xz-native"
  COMPRESS_DEPENDS_gz = ""
  COMPRESS_DEPENDS_bz2 = "pbzip2-native"
-COMPRESS_DEPENDS_xz = "xz-native"
+COMPRESS_DEPENDS_xz = "pxz-native"
  COMPRESS_DEPENDS_lz4 = "lz4-native"
  COMPRESS_DEPENDS_sum = "mtd-utils-native"

diff --git a/meta/recipes-extended/pxz/pxz_git.bb 
b/meta/recipes-extended/pxz/pxz_git.bb
new file mode 100644
index 000..fe21be6
--- /dev/null
+++ b/meta/recipes-extended/pxz/pxz_git.bb
@@ -0,0 +1,31 @@
+# Copyright (C) 2015 Khem Raj <raj.k...@gmail.com>
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SUMMARY = "Parallel LZMA compressor compatible with XZ"
+DESCRIPTION = "Parallel XZ is a compression utility that takes advantage of running 
LZMA compression of different parts of an input file on multiple cores and processors 
simultaneously. Its primary goal is to utilize all resources to speed up compression time 
with minimal possible influence on compression ratio"
+HOMEPAGE = "https://jnovy.fedorapeople.org/pxz/;
+LICENSE = "GPL-2.0+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+SECTION = "console/utils"
+DEPENDS = "xz"
+
+SRCREV = "ae808463c2950edfdedb8fb49f95006db0a18667"
+PV = "4.999.9beta+git${SRCPV}"
+SRC_URI = "git://github.com/jnovy/pxz.git"
+
+S = "${WORKDIR}/git"
+
+CFLAGS_append = " -fopenmp -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE"
+LDFLAGS_append = " -llzma"
+
+do_compile ()  {
+   oe_runmake
+}
+
+do_install ()  {
+   oe_runmake DESTDIR=${D} INSTALL="install -p"
+}
+
+deltask do_configure
+
+BBCLASSEXTEND = "native"



--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] pxz: Add recipe and use it for xz image type

[Gary Thomas]

On 2015-09-25 07:25, Khem Raj wrote:



On Sep 25, 2015, at 4:22 AM, Gary Thomas <g...@mlbassoc.com> wrote:

On 2015-09-24 22:59, Khem Raj wrote:

pxz results in significant time saving when generating xz filetypes for
images due to parallelization support


This adds another host tool dependency - on my Ubuntu (14.04) system, even
if 'xz' is installed, 'pxz' is not and I'd have to add it.  Since *.xz seems
to be the new fashion/trend, perhaps this choice might be optional/configurable?


I provided pxz recipe as well.. so I don’t get it where is host tool dep.


Fair enough, I missed your additional recipe.







a simple test on ubuntu build host with 16 CPUs

time xz -M 50% -f -k -c -e -9 --check=crc32 
CX041AEI_PROD_default_2015061105sdy-dbg.rootfs.cpio 
>CX041AEI_PROD_default_2015061105sdy-dbg.rootfs.cpio.xz

real
23m42.299s
user 23m36.947s
sys 0m5.101s

time pxz -M 50% -f -k -c -e -9 --check=crc32 
CX041AEI_PROD_default_2015061105sdy-dbg.rootfs.cpio 
>CX041AEI_PROD_default_2015061105sdy-dbg.rootfs.cpio.xz

real2m59.666s
user 24m38.529s
sys 0m10.056s

Signed-off-by: Khem Raj <raj.k...@gmail.com
---
  meta/classes/image_types.bbclass |  4 ++--
  meta/recipes-extended/pxz/pxz_git.bb | 31 +++
  2 files changed, 33 insertions(+), 2 deletions(-)
  create mode 100644 meta/recipes-extended/pxz/pxz_git.bb

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 306403e..d766cd2 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -233,13 +233,13 @@ COMPRESSIONTYPES = "gz bz2 lzma xz lz4 sum"
  COMPRESS_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}.rootfs.${type}"
  COMPRESS_CMD_gz = "gzip -f -9 -c ${IMAGE_NAME}.rootfs.${type} > 
${IMAGE_NAME}.rootfs.${type}.gz"
  COMPRESS_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}.rootfs.${type}"
-COMPRESS_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_THREADS} 
--check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}.rootfs.${type} > 
${IMAGE_NAME}.rootfs.${type}.xz"
+COMPRESS_CMD_xz = "pxz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_THREADS} 
--check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}.rootfs.${type} > 
${IMAGE_NAME}.rootfs.${type}.xz"
  COMPRESS_CMD_lz4 = "lz4c -9 -c ${IMAGE_NAME}.rootfs.${type} > 
${IMAGE_NAME}.rootfs.${type}.lz4"
  COMPRESS_CMD_sum = "sumtool -i ${IMAGE_NAME}.rootfs.${type} -o 
${IMAGE_NAME}.rootfs.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
  COMPRESS_DEPENDS_lzma = "xz-native"
  COMPRESS_DEPENDS_gz = ""
  COMPRESS_DEPENDS_bz2 = "pbzip2-native"
-COMPRESS_DEPENDS_xz = "xz-native"
+COMPRESS_DEPENDS_xz = "pxz-native"
  COMPRESS_DEPENDS_lz4 = "lz4-native"
  COMPRESS_DEPENDS_sum = "mtd-utils-native"

diff --git a/meta/recipes-extended/pxz/pxz_git.bb 
b/meta/recipes-extended/pxz/pxz_git.bb
new file mode 100644
index 000..fe21be6
--- /dev/null
+++ b/meta/recipes-extended/pxz/pxz_git.bb
@@ -0,0 +1,31 @@
+# Copyright (C) 2015 Khem Raj <raj.k...@gmail.com>
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SUMMARY = "Parallel LZMA compressor compatible with XZ"
+DESCRIPTION = "Parallel XZ is a compression utility that takes advantage of running 
LZMA compression of different parts of an input file on multiple cores and processors 
simultaneously. Its primary goal is to utilize all resources to speed up compression time 
with minimal possible influence on compression ratio"
+HOMEPAGE = "https://jnovy.fedorapeople.org/pxz/;
+LICENSE = "GPL-2.0+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+SECTION = "console/utils"
+DEPENDS = "xz"
+
+SRCREV = "ae808463c2950edfdedb8fb49f95006db0a18667"
+PV = "4.999.9beta+git${SRCPV}"
+SRC_URI = "git://github.com/jnovy/pxz.git"
+
+S = "${WORKDIR}/git"
+
+CFLAGS_append = " -fopenmp -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE"
+LDFLAGS_append = " -llzma"
+
+do_compile ()  {
+   oe_runmake
+}
+
+do_install ()  {
+   oe_runmake DESTDIR=${D} INSTALL="install -p"
+}
+
+deltask do_configure
+
+BBCLASSEXTEND = "native"



--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] gdk-pixbuf: Avoid rebuild failures

[Gary Thomas]

On 2015-09-23 16:32, Richard Purdie wrote:

If gdkpixbuf-native rebuilds and there are stale (broken) modules lying around,
it can fail to run the postinst. E.g. svg links to harfbuzz and if harfbuzz is
removed from the sysroot but the svg loader isn't, we get a symbol linking 
issue.

The reproducer is along the lines of build gdk-pixbuf-native along
with harfbuzz-native and librsvg-native, then make a small change to the
gdk-pixbuf recipe that would cause it to rebuild, clean harfbuzz-native
and then build gdk-pixbuf.

To fix this, when we install gdk-pixbuf, we wipe out any previous loaders.
The idea is that gdk would always come first and anything else installing
itself will come later and rerun the postinst if needed. We can therefore
just remove any other loaders.


Does the analogue of this problem exist for the non-native packages?  I've
not seen it, but it seems that it might based on your analysis.



Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>

diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb
index bdf173a..35bb192 100644
--- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb
@@ -94,3 +94,12 @@ do_install_append_class-native() {

GDK_PIXBUF_MODULEDIR=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/${LIBV}/loaders
  }
  BBCLASSEXTEND = "native"
+
+SSTATEPREINSTFUNCS_append_class-native = " gdkpixbuf_sstate_preinst"
+SYSROOT_PREPROCESS_FUNCS_append_class-native = " gdkpixbuf_sstate_preinst"
+
+gdkpixbuf_sstate_preinst() {
+   if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = 
"populate_sysroot_setscene" ]; then
+   rm -rf ${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/${LIBV}/*
+   fi
+}




--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Error building gdk-pixbuf-native

[Gary Thomas]

On 2015-09-22 12:38, Otavio Salvador wrote:

On Tue, Sep 22, 2015 at 3:14 PM, Gary Thomas <g...@mlbassoc.com> wrote:

On 2015-09-22 12:05, Otavio Salvador wrote:


On Tue, Sep 22, 2015 at 12:28 PM, Gary Thomas <g...@mlbassoc.com> wrote:


When building gdk-pixbuf-native, I got this error:
| DEBUG: Staging files from

/home/local/rpi2_2015-03-05/tmp/work/i686-linux/gdk-pixbuf-native/2.30.8-r0/sysroot-destdir/home/local/rpi2_2015-03-05/tmp/sysroots/i686-linux
to /home/local/rpi2_2015-03-05/tmp/sysroots/i686-linux
| DEBUG: Executing shell function pixbufcache_sstate_postinst
| g_module_open() failed for

/home/local/rpi2_2015-03-05/tmp/sysroots/i686-linux/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so:
libharfbuzz.so.0: cannot open shared object file: No such file or
directory

It seems that [at least] gdk-pixbuf-native needs harfbuzz-native
I looked at the recipe, but it's not 100% obvious to me how to
add this, especially w.r.t. all of the PACKAGECONFIG options.

Guidance?



I had similar failures[1] at O.S. Systems autobuilder and rebuilding
made it work.

1.
http://ci.ossystems.com.br/view/FSL%20Community%20BSP%20-%20master-next/job/fsl-community-bsp-master-next_wayland-imx28evk/827/console

The builds are now succeeding but I did no change to fix it. This
seems like a race for me.

I tried very hard to reproduce the issue locally at my laptop without
success. Do you can reliably reproduce it?



Yes, I had a full tree and this rebuild was kicked off by a meta-data
update.  Once it happened, I tried this:
   % bitbake harfbuzz-native gdk-pixbuf-native -c cleansstate
   % bitbake gdk-pixbuf-native
failed.  However the manual sequence
   % bitbake harfbuzz-native
   % bitbake gdk-pixbuf-native
succeeded.


I still do not reproduce it :-(



It seems to be a host [contamination?] issue.  I get this error
on a build host that does not have libharfbuzz.so installed.  On
a build host which does, there is no error.

Note that it is only for the native package, so perhaps that's
where the dependency needs to be updated/checked (hence my original
query)

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Error building gdk-pixbuf-native

[Gary Thomas]

On 2015-09-22 12:05, Otavio Salvador wrote:

On Tue, Sep 22, 2015 at 12:28 PM, Gary Thomas <g...@mlbassoc.com> wrote:

When building gdk-pixbuf-native, I got this error:
| DEBUG: Staging files from
/home/local/rpi2_2015-03-05/tmp/work/i686-linux/gdk-pixbuf-native/2.30.8-r0/sysroot-destdir/home/local/rpi2_2015-03-05/tmp/sysroots/i686-linux
to /home/local/rpi2_2015-03-05/tmp/sysroots/i686-linux
| DEBUG: Executing shell function pixbufcache_sstate_postinst
| g_module_open() failed for
/home/local/rpi2_2015-03-05/tmp/sysroots/i686-linux/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so:
libharfbuzz.so.0: cannot open shared object file: No such file or directory

It seems that [at least] gdk-pixbuf-native needs harfbuzz-native
I looked at the recipe, but it's not 100% obvious to me how to
add this, especially w.r.t. all of the PACKAGECONFIG options.

Guidance?


I had similar failures[1] at O.S. Systems autobuilder and rebuilding
made it work.

1. 
http://ci.ossystems.com.br/view/FSL%20Community%20BSP%20-%20master-next/job/fsl-community-bsp-master-next_wayland-imx28evk/827/console

The builds are now succeeding but I did no change to fix it. This
seems like a race for me.

I tried very hard to reproduce the issue locally at my laptop without
success. Do you can reliably reproduce it?



Yes, I had a full tree and this rebuild was kicked off by a meta-data
update.  Once it happened, I tried this:
  % bitbake harfbuzz-native gdk-pixbuf-native -c cleansstate
  % bitbake gdk-pixbuf-native
failed.  However the manual sequence
  % bitbake harfbuzz-native
  % bitbake gdk-pixbuf-native
succeeded.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] hand the TEMPLATECONF local over to setup-builddir

[Gary Thomas]

On 2015-09-22 14:25, Lee Nipper wrote:

On Tue, Sep 22, 2015 at 1:45 PM, Marcus Müller <marcus.muel...@ettus.com 
<mailto:marcus.muel...@ettus.com>> wrote:

Hello,
> If I understand correctly it allows a user prepared $TEMPLATECONF
> directory
> to be used by oe-setup-builddir.
Indeed; the point is that oe-setup-builddir was definitely meant to be
used with a TEMPLATECONF set by the user; in bash, the TEMPLATECONF
local variable is automatically passed on from oe-init-build-env to
oe-setup-builddir¹, but in zsh, this doesn't work without explicitely
declaring that should happen (which is the only thing my patch does).

Best regards,
Marcus

¹ not quite sure how; it's a local to the calling script and shouldn't
be a local or env variable to the callee, IMHO.



Hello Marcus,

FWIW, I did some test cases to understand the differences.

With bash 4.3.11, and the examples below,
cases A and B will pass along TEMPLATECONF, but case C does not.
Your patch makes case C work as well.

# A:

TEMPLATECONF=$HOME/my-template-dir source ~/openembedded-core/oe-init-build-env 
$HOME/my-build-dir

# B:
export TEMPLATECONF=$HOME/my-template-dir; source 
~/openembedded-core/oe-init-build-env $HOME/my-build-dir

# C:
TEMPLATECONF=$HOME/my-template-dir; source 
~/openembedded-core/oe-init-build-env $HOME/my-build-dir


And with zsh 5.0.2, case B will pass along TEMPLATECONF, but cases A and C do 
not.
Your patch makes cases A and C work as well with zsh.

I did not expect case A to be different than case C for bash, but it apparently 
works differently than I thought.


This is indeed expected behaviour - environment variables defined
on the command line before the command itself are local to that
command's execution only.

--
----
Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] Error building gdk-pixbuf-native

[Gary Thomas]

When building gdk-pixbuf-native, I got this error:
| DEBUG: Staging files from /home/local/rpi2_2015-03-05/tmp/work/i686-linux/gdk-pixbuf-native/2.30.8-r0/sysroot-destdir/home/local/rpi2_2015-03-05/tmp/sysroots/i686-linux to 
/home/local/rpi2_2015-03-05/tmp/sysroots/i686-linux

| DEBUG: Executing shell function pixbufcache_sstate_postinst
| g_module_open() failed for /home/local/rpi2_2015-03-05/tmp/sysroots/i686-linux/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: libharfbuzz.so.0: cannot open shared 
object file: No such file or directory


It seems that [at least] gdk-pixbuf-native needs harfbuzz-native
I looked at the recipe, but it's not 100% obvious to me how to
add this, especially w.r.t. all of the PACKAGECONFIG options.

Guidance?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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