Re: [OE-core] [PATCH] openssh: Remove deprecated sshd option
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 --- 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
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"
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
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
---
.../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, &events) ||
+FD_ISSET(clients[0].fd, &reads))) {
+@@ -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
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 --- 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
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
---
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
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
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
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 --- 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
On 2017-03-20 13:58, Burton, Ross wrote: On 20 March 2017 at 12:50, Gary Thomas 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
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
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
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
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 Signed-off-by: Richard Purdie 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
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?
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
On 2017-02-24 17:46, Burton, Ross wrote: On 24 February 2017 at 16:27, Patrick Ohly 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
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
On 2017-02-16 21:47, Sylvain Lemieux wrote:
From: Sylvain Lemieux
Setup "inetd" as a sub-package in "busybox" and
add the support to install "inetd" as a startup script.
Signed-off-by: Sylvain Lemieux
---
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
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
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
---
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
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 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
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
---
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
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
---
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
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 += "${GOPKG_FINAL}/${GO_IMPORT}*"
+
+GO_INSTALL ?= "$
Re: [OE-core] [PATCH] u-boot: mkimage: Fix build of u-boot-mkimage
On 2016-11-09 01:45, Burton, Ross wrote: On 9 November 2016 at 00:43, Khem Raj 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?
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?
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
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"
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
On 2016-10-11 14:36, Burton, Ross wrote: On 11 October 2016 at 13:26, Gary Thomas 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
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
---
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
On 2016-10-11 11:22, Enrico Scholz wrote:
Mark Hatle 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
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
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?
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 mailto:net...@gmail.com>>: On 2 October 2016 at 18:28, Gary Thomas 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?
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
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
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 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
On 2016-09-15 22:12, Burton, Ross wrote: On 15 September 2016 at 21:03, Paul Eggleton 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
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?
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
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
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
On 2016-08-19 18:01, Khem Raj wrote: On Aug 19, 2016, at 8:05 AM, Gary Thomas 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 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" 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 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
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" 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 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
On 2016-08-19 15:40, Khem Raj wrote: On Aug 19, 2016, at 3:14 AM, Richard Purdie 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
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 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"
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
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
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
On 2016-07-28 11:32, Burton, Ross wrote: On 27 July 2016 at 23:14, Alejandro Hernandez 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.
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
Works on my i.MX6Q target!
Acked-by: Gary Thomas
---
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
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?
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
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??
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
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 wrote: Signed-off-by: Ross Burton --- 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?
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&id=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?
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?
On 2016-05-25 08:13, Khem Raj wrote: On May 25, 2016, at 8:34 AM, Gary Thomas 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?
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
On 2016-05-19 07:42, Khem Raj wrote:
On May 18, 2016, at 10:38 PM, Robert Yang wrote:
On 05/19/2016 01:28 PM, Khem Raj wrote:
On May 18, 2016, at 8:16 PM, Gary Thomas wrote:
On 2016-05-18 22:07, Khem Raj wrote:
On Wed, May 18, 2016 at 2:03 AM, Robert Yang 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
---
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
On 2016-05-18 22:07, Khem Raj wrote:
On Wed, May 18, 2016 at 2:03 AM, Robert Yang 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
---
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
On 2016-05-13 09:07, Andrea Adami wrote: On Fri, May 13, 2016 at 8:48 AM, Robert Yang 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
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 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
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 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 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 Signed-off-by: Richard Purdie 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
On 2016-04-13 14:08, Jussi Kukkonen wrote: On 13 April 2016 at 14:35, Gary Thomas 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 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 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 mailto:jussi.kukko...@intel.com>> +--- + matchbox-keyboard.desktop | 1 + +
Re: [OE-core] [PATCH] matchbox-keyboard: Hide desktop launcher
lity;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
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
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
Looks like this fixes it, thanks.
Acked-by: Gary Thomas
---
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
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
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
Signed-off-by: Richard Purdie
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
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
On 2016-03-24 11:30, Burton, Ross wrote: On 24 March 2016 at 10:27, Gary Thomas 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
On 2016-03-24 11:23, Burton, Ross wrote: On 24 March 2016 at 09:45, Gary Thomas 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
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
On 03/10/2016 04:54 PM, Jens Rehsack wrote: Am 10.03.2016 um 06:13 schrieb 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? 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
On 2016-03-10 16:54, Jens Rehsack wrote: Am 10.03.2016 um 06:13 schrieb 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? 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
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
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 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
I have a need for GCC 4.8 which was recently dropped from OE-core. commit d9aabf9639510fdb3e2ccc21ba5ae4aa9f6e4a57 Author: Richard Purdie 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
On 2016-02-12 12:15, Burton, Ross wrote: On 12 February 2016 at 11:11, Gary Thomas 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
Re: [OE-core] [PATCH] ffmpeg: Add -dbg packages for all libraries
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 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
On 2016-02-12 11:49, Burton, Ross wrote: On 12 February 2016 at 03:58, Gary Thomas 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
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
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
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
[OE-core] [PATCH] ffmpeg: Add -dbg packages for all libraries
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
---
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
Re: [OE-core] Error building glib
On 2015-12-16 08:10, Burton, Ross wrote:
On 16 December 2015 at 14:49, Gary Thomas 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
[OE-core] Error building glib
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] [PATCH] x11vnc: move recipe to meta-oe
On 2015-10-16 09:29, Otavio Salvador wrote: On Fri, Oct 16, 2015 at 12:21 PM, Gary Thomas 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 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
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 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
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 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
On 2015-09-25 07:25, Khem Raj wrote:
On Sep 25, 2015, at 4:22 AM, Gary Thomas 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
+# 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] pxz: Add recipe and use it for xz image type
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
+# 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] gdk-pixbuf: Avoid rebuild failures
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
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
On 2015-09-23 06:15, Burton, Ross wrote: On 22 September 2015 at 16:28, Gary Thomas mailto:g...@mlbassoc.com>> wrote: | 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 Here's my guess at what happened. Starting state was a complete sysroot with at least gdk-pixbuf, harfbuzz, librsvg installed. Yhen you did a new build. At least harfbuzz and gdk-pixbuf were being rebuilt, so purged from the sysroot. gdk-pixbuf rebuilt, installed into sysroot, ran the update-cache script which then found the rsvg loader from the previous sysroot that was not (yet?) removed that links to harfbuzz. Harfbuzz still isn't reinstall yet, linkage fails. Is this with master or a release? There are changes in master compared to fido to improve situations like this. Master updated 2015-09-22 (7b86c771c80d0759c2ca0e57c46c4c966f89c49e) -- ---- 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
On 2015-09-22 14:25, Lee Nipper wrote: On Tue, Sep 22, 2015 at 1:45 PM, Marcus Müller 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
Re: [OE-core] Error building gdk-pixbuf-native
On 2015-09-22 12:38, Otavio Salvador wrote: On Tue, Sep 22, 2015 at 3:14 PM, Gary Thomas wrote: On 2015-09-22 12:05, Otavio Salvador wrote: On Tue, Sep 22, 2015 at 12:28 PM, Gary Thomas 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
On 2015-09-22 12:05, Otavio Salvador wrote: On Tue, Sep 22, 2015 at 12:28 PM, Gary Thomas 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
