Re: [OE-core] [PATCH] trace-cmd: Update to version 2.3.2
wrt Saul's comment, feel free to steal from
http://lists.openembedded.org/pipermail/openembedded-core/2014-April/091622.html
where I wrote why the patches are dropped.
On 6 August 2014 20:23, Yasir Khan wrote:
> From: Yasir-Khan
>
> Current trace-cmd version 1.2 throws "recorder error in
> splice input" error while recording a trace on kernel
> version 3.10. Update the trace-cmd version to latest 2.3.2
> to resolve this error.
>
> Signed-off-by: Yasir-Khan
> ---
> ...dd-checks-for-invalid-pointers-to-fix-seg.patch | 61 -
> ...o-not-call-stop_threads-if-doing-latency-.patch | 38
> ...etting-plugin-to-nop-clears-data-before-i.patch | 96
>
> .../trace-cmd-fix-syntax-error-of-shell.patch | 30 --
> .../{trace-cmd_1.2.bb => trace-cmd_2.3.2.bb} | 31 +--
> 5 files changed, 22 insertions(+), 234 deletions(-)
> delete mode 100644
> meta/recipes-kernel/trace-cmd/trace-cmd/trace-cmd-Add-checks-for-invalid-pointers-to-fix-seg.patch
> delete mode 100644
> meta/recipes-kernel/trace-cmd/trace-cmd/trace-cmd-Do-not-call-stop_threads-if-doing-latency-.patch
> delete mode 100644
> meta/recipes-kernel/trace-cmd/trace-cmd/trace-cmd-Setting-plugin-to-nop-clears-data-before-i.patch
> delete mode 100644
> meta/recipes-kernel/trace-cmd/trace-cmd/trace-cmd-fix-syntax-error-of-shell.patch
> rename meta/recipes-kernel/trace-cmd/{trace-cmd_1.2.bb =>
> trace-cmd_2.3.2.bb} (29%)
>
> diff --git
> a/meta/recipes-kernel/trace-cmd/trace-cmd/trace-cmd-Add-checks-for-invalid-pointers-to-fix-seg.patch
>
> b/meta/recipes-kernel/trace-cmd/trace-cmd/trace-cmd-Add-checks-for-invalid-pointers-to-fix-seg.patch
> deleted file mode 100644
> index 8fdeedb..000
> ---
> a/meta/recipes-kernel/trace-cmd/trace-cmd/trace-cmd-Add-checks-for-invalid-pointers-to-fix-seg.patch
> +++ /dev/null
> @@ -1,61 +0,0 @@
> -From a6e259b2cd43db3c0f69441f627a8cf214f88506 Mon Sep 17 00:00:00 2001
> -From: Mark Asselstine
> -Date: Thu, 5 Apr 2012 15:19:44 -0400
> -Subject: [PATCH] trace-cmd: Add checks for invalid pointers to fix segfaults
> -
> -Upstream-Status: Backport
> -
> -Running 'trace-cmd report' after running latency tracers will cause a
> -segfault due to invalid pointers. Adding checks to ensure
> -pointers/lists are initialized before attempting to use them prevents
> -these segfaults.
> -
> -Link:
> http://lkml.kernel.org/r/1333653586-3379-2-git-send-email-mark.asselst...@windriver.com
> -
> -Signed-off-by: Mark Asselstine
> -Signed-off-by: Steven Rostedt
>
> - trace-input.c | 12 +---
> - 1 file changed, 9 insertions(+), 3 deletions(-)
> -
> -diff --git a/trace-input.c b/trace-input.c
> -index b6af1e6..5151c1e 100644
> a/trace-input.c
> -+++ b/trace-input.c
> -@@ -695,7 +695,8 @@ static void __free_page(struct tracecmd_input *handle,
> struct page *page)
> -
> - static void free_page(struct tracecmd_input *handle, int cpu)
> - {
> -- if (!handle->cpu_data[cpu].page)
> -+ if (!handle->cpu_data || cpu >= handle->cpus ||
> -+ !handle->cpu_data[cpu].page)
> - return;
> -
> - __free_page(handle, handle->cpu_data[cpu].page);
> -@@ -746,8 +747,12 @@ void tracecmd_record_ref(struct record *record)
> -
> - static void free_next(struct tracecmd_input *handle, int cpu)
> - {
> -- struct record *record = handle->cpu_data[cpu].next;
> -+ struct record *record;
> -+
> -+ if (!handle->cpu_data || cpu >= handle->cpus)
> -+ return;
> -
> -+ record = handle->cpu_data[cpu].next;
> - if (!record)
> - return;
> -
> -@@ -2337,7 +2342,8 @@ void tracecmd_close(struct tracecmd_input *handle)
> - /* The tracecmd_peek_data may have cached a record */
> - free_next(handle, cpu);
> - free_page(handle, cpu);
> -- if (!list_empty(&handle->cpu_data[cpu].pages))
> -+ if (handle->cpu_data &&
> -+ !list_empty(&handle->cpu_data[cpu].pages))
> - warning("pages still allocated on cpu %d%s",
> - cpu,
> show_records(&handle->cpu_data[cpu].pages));
> - }
> ---
> -1.7.10.4
> -
> diff --git
> a/meta/recipes-kernel/trace-cmd/trace-cmd/trace-cmd-Do-not-call-stop_threads-if-doing-latency-.patch
>
> b/meta/recipes-kernel/trace-cmd/trace-cmd/trace-cmd-Do-not-call-stop_threads-if-doing-latency-.patch
> deleted file mode 100644
> index 4c00c51..000
> ---
> a/meta/recipes-kernel/trace-cmd/trace-cmd/trace-cmd-Do-not-call-stop_threads-if-doing-latency-.patch
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -From 356dee73d9ced3e019dea2883a7f357fd4664b3e Mon Sep 17 00:00:00 2001
> -From: Mark Asselstine
> -Date: Thu, 5 Apr 2012 15:19:45 -0400
> -Subject: [PATCH] trace-cmd: Do not call stop_threads() if doing latency
> - tracing
> -
> -Upstream-Status: Backport
> -
> -If we are using a latency tracer we do not call start_threads() we
> -should therefore not call sto
[OE-core] [PATCH 0/2] Two fixes about systemd
The following changes since commit 1fafe7ccc563d5ac9e41f5c1de93d2736745b512: ghostscript: Remove bogus gsfonts reference from DESCRIPTION (2014-08-06 11:14:21 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib ChenQi/systemd_alsa-state_v86d http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/systemd_alsa-state_v86d Chen Qi (2): alsa-state: install init script only when 'sysvinit' is in DISTRO_FEATURES v86d: fix for systemd to load uvesafb module correctly meta/recipes-bsp/alsa-state/alsa-state.bb | 10 +++--- meta/recipes-bsp/v86d/v86d/uvesafb.conf |2 ++ meta/recipes-bsp/v86d/v86d_0.1.10.bb | 14 -- 3 files changed, 21 insertions(+), 5 deletions(-) create mode 100644 meta/recipes-bsp/v86d/v86d/uvesafb.conf -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] alsa-state: install init script only when 'sysvinit' is in DISTRO_FEATURES
The /etc/init.d/alsa-state is totally useless for a systemd image.
Its functionality has been replaced by alsa-state.service files.
So if 'sysvinit' is not in DISTRO_FEATURES, installing this script doesn't
make any sense.
[YOCTO #4420]
Signed-off-by: Chen Qi
---
meta/recipes-bsp/alsa-state/alsa-state.bb | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-bsp/alsa-state/alsa-state.bb
b/meta/recipes-bsp/alsa-state/alsa-state.bb
index 874d6bb..d2f8ea2 100644
--- a/meta/recipes-bsp/alsa-state/alsa-state.bb
+++ b/meta/recipes-bsp/alsa-state/alsa-state.bb
@@ -24,11 +24,15 @@ INITSCRIPT_NAME = "alsa-state"
INITSCRIPT_PARAMS = "start 39 S . stop 31 0 6 ."
do_install() {
-sed -i -e "s:#STATEDIR#:${localstatedir}/lib/alsa:g"
${WORKDIR}/alsa-state-init
-install -d ${D}${sysconfdir}/init.d
-install -m 0755 ${WORKDIR}/alsa-state-init
${D}${sysconfdir}/init.d/alsa-state
+# Only install the init script when 'sysvinit' is in DISTRO_FEATURES.
+if ${@bb.utils.contains('DISTRO_FEATURES','sysvinit','true','false',d)};
then
+ sed -i -e "s:#STATEDIR#:${localstatedir}/lib/alsa:g"
${WORKDIR}/alsa-state-init
+ install -d ${D}${sysconfdir}/init.d
+ install -m 0755 ${WORKDIR}/alsa-state-init
${D}${sysconfdir}/init.d/alsa-state
+fi
install -d ${D}/${localstatedir}/lib/alsa
+install -d ${D}${sysconfdir}
install -m 0644 ${WORKDIR}/asound.conf ${D}${sysconfdir}
install -m 0644 ${WORKDIR}/*.state ${D}${localstatedir}/lib/alsa
}
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] v86d: fix for systemd to load uvesafb module correctly
The /etc/init.d/fbsetup script doesn't have any effect in a systemd
image. Its purpose is to load the uvesafb kernel module at boot.
This functionality could be achieved by adding a configuration file
under /etc/modules-load.d/ directory which would be parsed by the
systemd-modules-load.service.
[YOCTO #4420]
Signed-off-by: Chen Qi
---
meta/recipes-bsp/v86d/v86d/uvesafb.conf |2 ++
meta/recipes-bsp/v86d/v86d_0.1.10.bb| 14 --
2 files changed, 14 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-bsp/v86d/v86d/uvesafb.conf
diff --git a/meta/recipes-bsp/v86d/v86d/uvesafb.conf
b/meta/recipes-bsp/v86d/v86d/uvesafb.conf
new file mode 100644
index 000..4378975
--- /dev/null
+++ b/meta/recipes-bsp/v86d/v86d/uvesafb.conf
@@ -0,0 +1,2 @@
+# Load uvesafb.ko at boot
+uvesafb
diff --git a/meta/recipes-bsp/v86d/v86d_0.1.10.bb
b/meta/recipes-bsp/v86d/v86d_0.1.10.bb
index b980331..08438be 100644
--- a/meta/recipes-bsp/v86d/v86d_0.1.10.bb
+++ b/meta/recipes-bsp/v86d/v86d_0.1.10.bb
@@ -12,6 +12,7 @@ PR = "r2"
SRC_URI = "http://distfiles.gentoo.org/distfiles/${BP}.tar.bz2 \
file://Update-x86emu-from-X.org.patch \
file://fbsetup \
+ file://uvesafb.conf \
file://ar-from-env.patch"
SRC_URI[md5sum] = "51c792ba7b874ad8c43f0d3da4cfabe0"
@@ -35,8 +36,17 @@ do_install () {
install -d ${D}${base_sbindir}
install v86d ${D}${base_sbindir}/
-install -d ${D}${sysconfdir}/init.d/
-install -m 0755 ${WORKDIR}/fbsetup ${D}${sysconfdir}/init.d/fbsetup
+# Only install fbsetup script if 'sysvinit' is in DISTRO_FEATURES
+if
${@bb.utils.contains('DISTRO_FEATURES','sysvinit','true','false',d)}; then
+install -d ${D}${sysconfdir}/init.d/
+install -m 0755 ${WORKDIR}/fbsetup ${D}${sysconfdir}/init.d/fbsetup
+fi
+
+# Install systemd related configuration file
+if
${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
+install -d ${D}${sysconfdir}/modules-load.d
+install -m 0644 ${WORKDIR}/uvesafb.conf
${D}${sysconfdir}/modules-load.d
+fi
}
inherit update-rc.d
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] coreutils: drop patch that unconditionally mangles manpages
On 08/07/2014 04:38 AM, Paul Gortmaker wrote:
commit 841ec528ec04e64bd09ff10f8d9ad2d6e3aac05d ("coreutils: update
to upstream version 9.21") added a patch which bypassed the check
for perl and hence defaults to using the dummy man page for all
of the coreutils manpages. This results in all manpages looking like:
NAME
chmod - a GNU coreutils 8.22 program
DESCRIPTION
OOOPS! Due to the lack of perl on the build system, we were unable to
create a proper manual page for chmod.
It is unclear why the test was disabled, but since it clearly
causes the manpages to be useless, we need to drop this patch.
Signed-off-by: Paul Gortmaker
diff --git a/meta/recipes-core/coreutils/coreutils-8.22/dummy_help2man.patch
b/meta/recipes-core/coreutils/coreutils-8.22/dummy_help2man.patch
deleted file mode 100644
index 4757f52aa0be..
--- a/meta/recipes-core/coreutils/coreutils-8.22/dummy_help2man.patch
+++ /dev/null
@@ -1,22 +0,0 @@
-Upstream-Status: Inappropriate [disable feature]
-
-Signed-off-by: Marko Lindqvist
-diff -Nurd coreutils-8.21/man/local.mk coreutils-8.21/man/local.mk
coreutils-8.21/man/local.mk2013-02-05 16:01:21.0 +0200
-+++ coreutils-8.21/man/local.mk2013-03-23 09:12:53.360470192 +0200
-@@ -19,11 +19,11 @@
- EXTRA_DIST += man/help2man man/dummy-man
-
- ## Graceful degradation for systems lacking perl.
--if HAVE_PERL
--run_help2man = $(PERL) -- $(srcdir)/man/help2man
--else
-+#if HAVE_PERL
-+#run_help2man = $(PERL) -- $(srcdir)/man/help2man
-+#else
- run_help2man = $(SHELL) $(srcdir)/man/dummy-man
--endif
-+#endif
-
- man1_MANS = @man1_MANS@
- EXTRA_DIST += $(man1_MANS:.1=.x)
diff --git a/meta/recipes-core/coreutils/coreutils_8.22.bb
b/meta/recipes-core/coreutils/coreutils_8.22.bb
index d5373ae9d66a..b19c1691eb10 100644
--- a/meta/recipes-core/coreutils/coreutils_8.22.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.22.bb
@@ -14,7 +14,6 @@ inherit autotools gettext texinfo
SRC_URI = "${GNU_MIRROR}/coreutils/${BP}.tar.xz \
file://remove-usr-local-lib-from-m4.patch \
- file://dummy_help2man.patch \
file://fix-for-dummy-man-usage.patch \
"
There's some build failure about coreutils on autobuilder that might be
caused by this patch.
Please take a look at it.
Below is a link to the log.
https://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/201/steps/BuildImages_1/logs/stdio
//Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] core-image.bbclass: Correct comment about packagegroups.
Default core image actually includes packagegroup-base-extended, not
just packagegroup-base.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta/classes/core-image.bbclass b/meta/classes/core-image.bbclass
index 67e11bf..62363fb 100644
--- a/meta/classes/core-image.bbclass
+++ b/meta/classes/core-image.bbclass
@@ -7,8 +7,8 @@ LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d
# IMAGE_FEATURES control content of the core reference images
#
-# By default we install packagegroup-core-boot and packagegroup-base packages
- this gives us
-# working (console only) rootfs.
+# By default we install packagegroup-core-boot and packagegroup-base-extended
packages;
+# this gives us working (console only) rootfs.
#
# Available IMAGE_FEATURES:
#
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] RFC: Improving the developer workflow
Hi folks, As most of you know within the Yocto Project and OpenEmbedded we've been trying to figure out how to improve the OE developer workflow. This potentially covers a lot of different areas, but one in particular I where think we can have some impact is helping application developers - people who are working on some application or component of the system, rather than the OS as a whole. Currently, what we provide is an installable SDK containing the toolchain, libraries and headers; we also have the ADT which additionally provides some Eclipse integration (which I'll leave aside for the moment) and has some ability to be extended / updated using opkg only. The pros: * Self contained, no extra dependencies * Relocatable, can be installed anywhere * Runs on lots of different systems * Mostly pre-configured for the desired target machine The cons: * No ability to migrate into the build environment * No helper scripts/tools beyond the basic environment setup * No real upgrade workflow (package feed upgrade possible in theory, but no tools to help manage the feeds and difficult to scale with multiple releases and targets) As the ADT/SDK stand, they do provide an easy way to run the cross-compilation on a separate machine; but that's about it - you're somewhat on your own as far as telling whatever build system your application / some third-party library you need uses to use that toolchain, and completely on your own as far as getting your changes that code into your image or getting those changes integrated into the build system is concerned. We can do better. Bridging the gap We have a lot of power in the build system - e.g. the cross-compilation tools and helper classes. I think it would help a lot if we could give the developer access to some of this power, but in a manner that does not force the developer to have to deal with the pain of actually setting up the build system and keeping it running. I think there is a path forward where we can integrate the build system into the SDK and wrap it in some helper scripts in such a way that we: * Avoid the need to configure the build system - it comes pre-configured. The developer is not expected to need to touch the configuration files at all. * Avoid building anything on the developer's machine that we don't need to - lock the sstate signatures such that only components that the developer ends up building are the ones that they've selected to work on, which are tracked by the tools, and the rest comes from sstate - and perhaps a portion of the sstate is already part of the downloaded SDK to avoid too much fetching during builds, either in the form of sstate packages or already populated into the target sysroot and other places within the internal copy of the build system. This should reduce the likelihood of the system breaking on the developer's machine as well as reduce the number of host dependencies. * Provide tools to add new software - in practical terms this means creating a new recipe in an automated/guided manner (figuring out as much as we can looking at the source tree) and then configuring the build to use the developer's external source tree rather than SRC_URI, by making use of the externalsrc class. This also gives a head start when it comes to integrating the new software into the build - you already have a recipe, even if some additional tweaking is required. * Provide tools to allow modifying software for which a recipe already exists. If the user has an external source tree we use that, otherwise we can fetch the source, apply any patches and place the result in an external source tree, possibly managed with git. (It's fair to say this is perhaps less of an application developer type task, but still an important one and fairly simple to add once we have the rest of the tooling.) * Provide tools to get your changes onto the target in order to test them. With access to the build system, rebuilding the image with changes to a target component is fairly trivial; but we can go further - assuming a network connection to the target is available we can provide tools to simply deploy the files installed by the changed recipe onto the running device (using an "sstate-like" mechanism - remove the old list of files and then install the new ones). * Provide tools to get your changes to the code or the metadata into a form that you can submit somewhere. For compilation, this would mean that we use the normal native / cross tools instead of nativesdk; the only parts that remain as nativesdk are those that we need to provide to isolate the SDK from differences in the host system (such as Python / libc). We'll need to do some additional loader tricks on top of what we currently do for nativesdk so that the native / cross tools can make use of the nativesdk libc in the SDK, but this shouldn't be a serious barrier. Example workflow I won't give a workflo
[OE-core] [PATCH] opkg-utils: allow disabling update-alternatives
From: Sujith H
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as PREFERRED_PROVIDER, but it is more explicit that way.
Signed-off-by: Christopher Larson
Signed-off-by: Sujith H
---
meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
index 693c216..9364740 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
@@ -19,11 +19,17 @@ TARGET_CC_ARCH += "${LDFLAGS}"
PYTHONRDEPS = "python python-shell python-io python-math python-crypt
python-logging python-fcntl python-subprocess python-pickle python-compression
python-textutils python-stringold"
PYTHONRDEPS_class-native = ""
-PACKAGECONFIG = "python"
+PACKAGECONFIG = "python update-alternatives"
PACKAGECONFIG[python] = ",,,${PYTHONRDEPS}"
+PACKAGECONFIG[update-alternatives] = ",,,"
+
+PROVIDES += "${@'virtual/update-alternatives' if 'update-alternatives' in
PACKAGECONFIG.split() else ''}"
do_install() {
oe_runmake PREFIX=${prefix} DESTDIR=${D} install
+if ${@'true' if 'update-alternatives' not in PACKAGECONFIG.split()
else 'false'}; then
+rm -f "${D}${bindir}/update-alternatives"
+fi
}
PACKAGES =+ "update-alternatives-opkg"
--
1.8.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] opkg-utils: allow disabling update-alternatives
Hi Paul Eggleton,
On Thu, Aug 7, 2014 at 2:54 PM, Sujith H wrote:
> From: Sujith H
>
> This is needed to deal with the situation where we're using ipk packaging,
> so
> opkg-utils must be built regardless of what update-alternatives provider we
> prefer. The downside to the current implementation is the need to adjust
> PACKAGECONFIG as well as PREFERRED_PROVIDER, but it is more explicit that
> way.
>
> Signed-off-by: Christopher Larson
> Signed-off-by: Sujith H
> ---
> meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> index 693c216..9364740 100644
> --- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> +++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> @@ -19,11 +19,17 @@ TARGET_CC_ARCH += "${LDFLAGS}"
> PYTHONRDEPS = "python python-shell python-io python-math python-crypt
> python-logging python-fcntl python-subprocess python-pickle
> python-compression python-textutils python-stringold"
> PYTHONRDEPS_class-native = ""
>
> -PACKAGECONFIG = "python"
> +PACKAGECONFIG = "python update-alternatives"
> PACKAGECONFIG[python] = ",,,${PYTHONRDEPS}"
> +PACKAGECONFIG[update-alternatives] = ",,,"
> +
> +PROVIDES += "${@'virtual/update-alternatives' if 'update-alternatives' in
> PACKAGECONFIG.split() else ''}"
>
> do_install() {
> oe_runmake PREFIX=${prefix} DESTDIR=${D} install
> +if ${@'true' if 'update-alternatives' not in
> PACKAGECONFIG.split() else 'false'}; then
> +rm -f "${D}${bindir}/update-alternatives"
> +fi
> }
>
> PACKAGES =+ "update-alternatives-opkg"
> --
> 1.8.4
>
>
In this change I am adding it to PROVIDES only if its required. Hope this
change looks ok?
Thanks,
Sujith H
--
സുജിത് ഹരിദാസന്
Bangalore
Contributor to KDE project
http://fci.wikia.com/wiki/Anti-DRM-Campaign
http://sujithh.info
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] patchwork client problems
On 08/04/2014 03:16 PM, Otavio Salvador wrote:
On Fri, Aug 1, 2014 at 10:07 PM, Peter A. Bigot wrote:
On 07/14/2014 04:21 AM, Peter A. Bigot wrote:
I'm finding attempts to use pwclient on
http://patches.openembedded.org/xmlrpc/ produce an ExpatError because the
returned document is always empty (per a wireshark trace of the
transaction). Can somebody confirm that the server for the command-line
client is working properly? Thanks.
Peter
I've downloaded a fresh copy of pwclient from
http://patches.openembedded.org/help/pwclient/
I've verified my .pwclientrc is exactly what the project info tells me it
should be:
[base]
url: http://patches.openembedded.org/xmlrpc/
project: oe-core
I've verified that pwclient works with other servers.
And I still get empty documents back from the OE patchwork server for every
pwclient command I try.
Anybody have any idea what's going wrong?
Thanks.
Peter
llc[40]$ /tmp/pwclient projects
Traceback (most recent call last):
File "/tmp/pwclient", line 500, in
main()
File "/tmp/pwclient", line 439, in main
action_projects(rpc)
File "/tmp/pwclient", line 213, in action_projects
projects = rpc.project_list("", 0)
File "/usr/lib/python2.7/xmlrpclib.py", line 1224, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.7/xmlrpclib.py", line 1578, in __request
verbose=self.__verbose
File "/usr/lib/python2.7/xmlrpclib.py", line 1264, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib/python2.7/xmlrpclib.py", line 1297, in single_request
return self.parse_response(response)
File "/usr/lib/python2.7/xmlrpclib.py", line 1471, in parse_response
p.close()
File "/usr/lib/python2.7/xmlrpclib.py", line 560, in close
self._parser.Parse("", 1) # end of data
xml.parsers.expat.ExpatError: no element found: line 1, column 0
I have same error; I am adding Khem who I know has access to the
server and can know more about it.
Thanks for confirming this isn't just me.
It's a bit of a problem, since without a working pwclient I can't tell
if there's already a patch that does what I need. If there's a way to
search through the browser interface I haven't figured it out.
Khem, if I can help with diagnosis please let me know.
Peter
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] RFC: Improving the developer workflow
On 07/08/2014 10:10, Paul Eggleton wrote: > Hi folks, > > As most of you know within the Yocto Project and OpenEmbedded we've been > trying to figure out how to improve the OE developer workflow. This > potentially > covers a lot of different areas, but one in particular I where think we can > have some impact is helping application developers - people who are working > on > some application or component of the system, rather than the OS as a whole. > > Currently, what we provide is an installable SDK containing the toolchain, > libraries and headers; we also have the ADT which additionally provides some > Eclipse integration (which I'll leave aside for the moment) and has some > ability to be extended / updated using opkg only. > > The pros: > > * Self contained, no extra dependencies > * Relocatable, can be installed anywhere > * Runs on lots of different systems > * Mostly pre-configured for the desired target machine > > The cons: > > * No ability to migrate into the build environment > * No helper scripts/tools beyond the basic environment setup > * No real upgrade workflow (package feed upgrade possible in theory, but no > tools to help manage the feeds and difficult to scale with multiple releases > and > targets) > Very interesting Paul. fwiw Upgrade solutions are something that is still a read need imho, as I think we discussed at one of the FOSDEMs. (The other real need being an on-board test framework, again imho, and which I believe is ongoing) Historically I, and I suspect others, have done full image updates of the storage medium, onboard flash or whatever but these images are getting so big now that I am trying to move away from that and into using package feeds for updates to embedded targets. My initial experience has been that - as you mention it would be really helpful to have something "more" around management of package feed releases / targets. - some automation around deployment of package feeds to production servers would help, or at least some documentation on best practice. The other big issue I am seeing, which is mostly my own fault thus far, is that I have sometimes taken the easy option of modifying the root filesystem image in various ways within the image recipe (for example changing a Webmin configuration perhaps) However when I then come to upgrade a package in-situ, such as Webmin, the changes are then overwritten. I think this is probably also an issue when upgrading packages that have had local modifications made, and I wonder whether there's a solution to this that I'm not aware of? I am aware of course that mainstream package management tools allow diffing, upgrading, ignoring and such but I am unsure as to how that is supported under Yocto at present? As a minimum I will have to make sure my OEM recipe changes are all in the correct .bbappends I believe think (more best practice notes there) and I definitely need to understand better how configuration file changes are handled when upgrading packages. Cheers, Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] patchwork client problems
On Thu, Aug 07, 2014 at 04:52:23AM -0500, Peter A. Bigot wrote:
> On 08/04/2014 03:16 PM, Otavio Salvador wrote:
> > On Fri, Aug 1, 2014 at 10:07 PM, Peter A. Bigot wrote:
> >> On 07/14/2014 04:21 AM, Peter A. Bigot wrote:
> >>> I'm finding attempts to use pwclient on
> >>> http://patches.openembedded.org/xmlrpc/ produce an ExpatError because the
> >>> returned document is always empty (per a wireshark trace of the
> >>> transaction). Can somebody confirm that the server for the command-line
> >>> client is working properly? Thanks.
> >>>
> >>> Peter
> >>>
> >> I've downloaded a fresh copy of pwclient from
> >> http://patches.openembedded.org/help/pwclient/
> >>
> >> I've verified my .pwclientrc is exactly what the project info tells me it
> >> should be:
> >>
> >> [base]
> >> url: http://patches.openembedded.org/xmlrpc/
> >> project: oe-core
> >>
> >> I've verified that pwclient works with other servers.
> >>
> >> And I still get empty documents back from the OE patchwork server for every
> >> pwclient command I try.
> >>
> >> Anybody have any idea what's going wrong?
> >>
> >> Thanks.
> >>
> >> Peter
> >>
> >> llc[40]$ /tmp/pwclient projects
> >> Traceback (most recent call last):
> >>File "/tmp/pwclient", line 500, in
> >> main()
> >>File "/tmp/pwclient", line 439, in main
> >> action_projects(rpc)
> >>File "/tmp/pwclient", line 213, in action_projects
> >> projects = rpc.project_list("", 0)
> >>File "/usr/lib/python2.7/xmlrpclib.py", line 1224, in __call__
> >> return self.__send(self.__name, args)
> >>File "/usr/lib/python2.7/xmlrpclib.py", line 1578, in __request
> >> verbose=self.__verbose
> >>File "/usr/lib/python2.7/xmlrpclib.py", line 1264, in request
> >> return self.single_request(host, handler, request_body, verbose)
> >>File "/usr/lib/python2.7/xmlrpclib.py", line 1297, in single_request
> >> return self.parse_response(response)
> >>File "/usr/lib/python2.7/xmlrpclib.py", line 1471, in parse_response
> >> p.close()
> >>File "/usr/lib/python2.7/xmlrpclib.py", line 560, in close
> >> self._parser.Parse("", 1) # end of data
> >> xml.parsers.expat.ExpatError: no element found: line 1, column 0
> > I have same error; I am adding Khem who I know has access to the
> > server and can know more about it.
>
> Thanks for confirming this isn't just me.
>
> It's a bit of a problem, since without a working pwclient I can't tell
> if there's already a patch that does what I need. If there's a way to
> search through the browser interface I haven't figured it out.
Click on "Filter" link in top left corner of the table.
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gdk-pixbuf-native: add setscene dep on jpeg-native
From: Shrikant Bobade
Without this, we can get setscene postinst failure due to libjpeg being
unavailable.
Signed-off-by: Christopher Larson
Signed-off-by: Shrikant Bobade
---
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb |1 +
1 file changed, 1 insertion(+)
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 3d08146..1248529 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
@@ -74,6 +74,7 @@ RDEPENDS_${PN}-ptest += "gnome-desktop-testing"
PACKAGES_DYNAMIC += "^gdk-pixbuf-loader-.*"
PACKAGES_DYNAMIC_class-native = ""
+PIXBUFCACHE_SYSROOT_DEPS_class-native +=
"jpeg-native:do_populate_sysroot_setscene"
python populate_packages_prepend () {
postinst_pixbufloader = d.getVar("postinst_pixbufloader", True)
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] pigz: Add dependency on zlib-native for pigz-native
From: Shrikant Bobade
When pigz-native and zlib-native are coming from sstate the setscenes might
not necessarily run in the expected order. The problem happens when setscene
for pigz-native runs before setscene for zlib-native. To fix the issue
do_populate_sysroot_setscene[depends] should be properly set for pigz-native.
Signed-off-by: Mikhail Durnev
Signed-off-by: Shrikant Bobade
---
meta/recipes-extended/pigz/pigz.inc |4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-extended/pigz/pigz.inc
b/meta/recipes-extended/pigz/pigz.inc
index 355fb2a..9a045e7 100644
--- a/meta/recipes-extended/pigz/pigz.inc
+++ b/meta/recipes-extended/pigz/pigz.inc
@@ -30,3 +30,7 @@ ALTERNATIVE_${PN} = "gzip gunzip"
ALTERNATIVE_LINK_NAME[gzip] = "${base_bindir}/gzip"
ALTERNATIVE_LINK_NAME[gunzip] = "${base_bindir}/gunzip"
ALTERNATIVE_PRIORITY = "80"
+
+PIGZ_SYSROOT_DEPS = ""
+PIGZ_SYSROOT_DEPS_class-native = "zlib-native:do_populate_sysroot_setscene"
+do_populate_sysroot_setscene[depends] += "${PIGZ_SYSROOT_DEPS}"
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] RFC: Improving the developer workflow
Hi Alex, On Thursday 07 August 2014 11:13:02 Alex J Lennon wrote: > On 07/08/2014 10:10, Paul Eggleton wrote: > fwiw Upgrade solutions are something that is still a read need imho, as > I think we discussed at one of the FOSDEMs. > > (The other real need being an on-board test framework, again imho, and > which I believe is ongoing) Indeed; I think we've made some pretty good progress here in that the Yocto Project QA team is now using the automated runtime testing to do QA tests on real hardware. Reporting and monitoring of ptest results is also being looked at as well as integration with LAVA. > Historically I, and I suspect others, have done full image updates of > the storage medium, onboard flash or whatever but these images are > getting so big now that I am trying to move away from that and into > using package feeds for updates to embedded targets. Personally with how fragile package management can end up being, I'm convinced that full-image updates are the way to go for a lot of cases, but ideally with some intelligence so that you only ship the changes (at a filesystem level rather than a package or file level). This ensures that an upgraded image on one device ends up exactly identical to any other device including a newly deployed one. Of course it does assume that you have a read-only rootfs and keep your configuration data / logs / other writeable data on a separate partition or storage medium. However, beyond improvements to support for having a read-only rootfs we haven't really achieved anything in terms of out- of-the-box support for this, mainly due to lack of resources. However, whilst I haven't had a chance to look at it closely, there has been some work on this within the community: http://sbabic.github.io/swupdate/swupdate.html https://github.com/sbabic/swupdate https://github.com/sbabic/meta-swupdate/ > My initial experience has been that > > - as you mention it would be really helpful to have something "more" > around management of package feed releases / targets. > > - some automation around deployment of package feeds to production > servers would help, or at least some documentation on best practice. So the scope of my proposal is a little bit narrower, i.e. for the SDK; and I'm suggesting that we mostly bypass the packaging system since it doesn't really add much benefit and sometimes gets in the way when you're an application developer in the middle of development and the level of churn is high (as opposed to making incremental changes after the product's release). > The other big issue I am seeing, which is mostly my own fault thus far, > is that I have sometimes taken the easy option of modifying the root > filesystem image in various ways within the image recipe (for example > changing a Webmin configuration perhaps) > > However when I then come to upgrade a package in-situ, such as Webmin, > the changes are then overwritten. > > I think this is probably also an issue when upgrading packages that have > had local modifications made, and I wonder whether there's a solution to > this that I'm not aware of? We do have CONFFILES to point to configuration files that may be modified (and thus should not just be overwritten on upgrade). There's not much logic in the actual build system to deal with this, we just pass it to the package manager; but it does work, and recipes that deploy configuration files (and bbappends, if the configuration file is being added rather than changed from there) should set CONFFILES so that the right thing happens on upgrade if you are using a package manager on the target. A related issue is that for anything other than temporary changes it's often not clear which recipe you need to change/append in order to provide your own version of a particular config file. FYI I entered the following enhancement bug some months ago to add a tool to help with that: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6447 > I am aware of course that mainstream package management tools allow > diffing, upgrading, ignoring and such but I am unsure as to how that is > supported under Yocto at present? There isn't really any support for this at the moment, no; I think we'd want to try to do this kind of thing at the build system end though to avoid tying ourselves to one particular package manager. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] How to force patch application
Hi All, please can I know if is it possible, using the do_patch routine, to force the application of a given patch? I mean, like the patch --force command. Please let me know, I tried w/o good result. Best Regards, Giuseppe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] RFC: Improving the developer workflow
On 07/08/2014 14:05, Paul Eggleton wrote: > Hi Alex, > > On Thursday 07 August 2014 11:13:02 Alex J Lennon wrote: >> On 07/08/2014 10:10, Paul Eggleton wrote: >> fwiw Upgrade solutions are something that is still a read need imho, as >> I think we discussed at one of the FOSDEMs. >> >> (The other real need being an on-board test framework, again imho, and >> which I believe is ongoing) > Indeed; I think we've made some pretty good progress here in that the Yocto > Project QA team is now using the automated runtime testing to do QA tests on > real hardware. Reporting and monitoring of ptest results is also being looked > at as well as integration with LAVA. > Great news. I really want to look into this but as ever time is the constraining factor. >> Historically I, and I suspect others, have done full image updates of >> the storage medium, onboard flash or whatever but these images are >> getting so big now that I am trying to move away from that and into >> using package feeds for updates to embedded targets. > Personally with how fragile package management can end up being, I'm > convinced > that full-image updates are the way to go for a lot of cases, but ideally > with > some intelligence so that you only ship the changes (at a filesystem level > rather than a package or file level). This ensures that an upgraded image on > one device ends up exactly identical to any other device including a newly > deployed one. Of course it does assume that you have a read-only rootfs and > keep your configuration data / logs / other writeable data on a separate > partition or storage medium. However, beyond improvements to support for > having a read-only rootfs we haven't really achieved anything in terms of out- > of-the-box support for this, mainly due to lack of resources. Deltas. Yes I've seen binary deltas attempted over the years, with varying degrees of success. I can see how what you say could work at a file-system level if we could separate out the writeable data, yes. Not sure I've seen any tooling around this though? Back in the day when I first started out with Arcom Embedded Linux in the late '90's I had us do something similar with a read only JFFS2 system partition and then a separate app/data partition. That seemed to work OK. Maybe I need to revisit that. > However, whilst I haven't had a chance to look at it closely, there has been > some work on this within the community: > > http://sbabic.github.io/swupdate/swupdate.html > https://github.com/sbabic/swupdate > https://github.com/sbabic/meta-swupdate/ I'll take a look. Thanks. > >> My initial experience has been that >> >> - as you mention it would be really helpful to have something "more" >> around management of package feed releases / targets. >> >> - some automation around deployment of package feeds to production >> servers would help, or at least some documentation on best practice. > So the scope of my proposal is a little bit narrower, i.e. for the SDK; and > I'm suggesting that we mostly bypass the packaging system since it doesn't > really add much benefit and sometimes gets in the way when you're an > application developer in the middle of development and the level of churn is > high (as opposed to making incremental changes after the product's release). Mmm. Yes I can understand that. Same here. >> The other big issue I am seeing, which is mostly my own fault thus far, >> is that I have sometimes taken the easy option of modifying the root >> filesystem image in various ways within the image recipe (for example >> changing a Webmin configuration perhaps) >> >> However when I then come to upgrade a package in-situ, such as Webmin, >> the changes are then overwritten. >> >> I think this is probably also an issue when upgrading packages that have >> had local modifications made, and I wonder whether there's a solution to >> this that I'm not aware of? > We do have CONFFILES to point to configuration files that may be modified > (and > thus should not just be overwritten on upgrade). There's not much logic in > the > actual build system to deal with this, we just pass it to the package > manager; > but it does work, and recipes that deploy configuration files (and bbappends, > if > the configuration file is being added rather than changed from there) should > set > CONFFILES so that the right thing happens on upgrade if you are using a > package manager on the target. > > A related issue is that for anything other than temporary changes it's often > not clear which recipe you need to change/append in order to provide your own > version of a particular config file. FYI I entered the following enhancement > bug > some months ago to add a tool to help with that: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6447 Interesting thanks. I don't recall seeing this in recipes. I might have missed it or are not many people using this features in their recipes? Of course the next issu
[OE-core] [PATCH 3/7] logrotate: fix recompile error
Fixed:
NOTE: make -j 32
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stddef.h',
needed by `logrotate.o'. Stop.
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the .depend isn't
regenerated when recompile, the content of the .depend are:
[snip]
logrotate.o: /path/to/sysroot/4.9.0/include/stddef.h
[snip]
And Makefile includes the .depend file if it exists, so there would be
errors when /path/to/sysroot/4.9.0/include/stddef.h doesn't exist.
Remove .depend will fix the problem.
Signed-off-by: Robert Yang
---
meta/recipes-extended/logrotate/logrotate_3.8.7.bb |5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-extended/logrotate/logrotate_3.8.7.bb
b/meta/recipes-extended/logrotate/logrotate_3.8.7.bb
index b386b85..3a6a228 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.8.7.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.8.7.bb
@@ -18,6 +18,11 @@ SRC_URI[sha256sum] =
"f6ba691f40e30e640efa2752c1f9499a3f9738257660994de70a45fe00
EXTRA_OEMAKE = ""
+do_compile_prepend() {
+# Make sure the recompile is OK
+rm -f ${B}/.depend
+}
+
do_install(){
oe_runmake install DESTDIR=${D} PREFIX=${D} MANDIR=${mandir}
mkdir -p ${D}${sysconfdir}/logrotate.d
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 7/7] syslinux: fix reinstall error
Fixed:
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stdarg.h',
needed by `cpio.o'. Stop.
make: *** Waiting for unfinished jobs
ERROR: oe_runmake failed
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the .cpio.o.d isn't
regenerated when recompile (the compile happens when do_install), the content
of it are:
[snip]
cpio.o: /path/to/sysroot/4.9.0/include/stdarg.h
[snip]
And Makefile includes the .cpio.o.d file if it exists, so there would be
errors when /path/to/sysroot/4.9.0/include/stdarg.h doesn't exist.
Remove .*.d (a few .d files, its Makefile uses this wildcard) will fix
the problem.
Signed-off-by: Robert Yang
---
meta/recipes-devtools/syslinux/syslinux_6.01.bb |4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-devtools/syslinux/syslinux_6.01.bb
b/meta/recipes-devtools/syslinux/syslinux_6.01.bb
index e8a1fd4..2377cc0 100644
--- a/meta/recipes-devtools/syslinux/syslinux_6.01.bb
+++ b/meta/recipes-devtools/syslinux/syslinux_6.01.bb
@@ -45,6 +45,10 @@ do_configure() {
}
do_compile() {
+ # Make sure the recompile is OK.
+ # Though the ${B} should always exist, still check it before find and
rm.
+ [ -d "${B}" ] && find ${B} -name '.*.d' -type f -exec rm -f {} \;
+
# Rebuild only the installer; keep precompiled bootloaders
# as per author's request (doc/distrib.txt)
oe_runmake CC="${CC} ${CFLAGS}" LDFLAGS="${LDFLAGS}" firmware="bios"
installer
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/7] fix rebuild error
The following changes since commit 1fafe7ccc563d5ac9e41f5c1de93d2736745b512: ghostscript: Remove bogus gsfonts reference from DESCRIPTION (2014-08-06 11:14:21 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/rebuild http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/rebuild Robert Yang (7): libnewt: fix recompile error trace-cmd: fix recompile error logrotate: fix recompile error kexec-tools: fix recompile error kernelshark: fix recompile error u-boot-mkimage: fix recompile error syslinux: fix reinstall error meta/recipes-bsp/u-boot/u-boot-mkimage_2013.07.bb |3 +++ meta/recipes-devtools/syslinux/syslinux_6.01.bb|4 meta/recipes-extended/logrotate/logrotate_3.8.7.bb |5 + meta/recipes-extended/newt/libnewt_0.52.17.bb |5 + meta/recipes-kernel/kexec/kexec-tools.inc | 11 +++ meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb |5 + meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb |5 + 7 files changed, 38 insertions(+) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/7] kexec-tools: fix recompile error
Fixed:
NOTE: make -j 32
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stddef.h',
needed by `kexec/kexec.o'. Stop.
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the kexec/kexec.d
isn't regenerated when recompile, the content of it are:
[snip]
kexec/kexec.o: /path/to/sysroot/4.9.0/include/stddef.h
[snip]
And Makefile includes the kexec/kexec.d file if it exists, so there
would be errors when /path/to/sysroot/4.9.0/include/stddef.h doesn't
exist.
Remove kexec/kexec.d and other similar files will fix the problem.
Signed-off-by: Robert Yang
---
meta/recipes-kernel/kexec/kexec-tools.inc | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/recipes-kernel/kexec/kexec-tools.inc
b/meta/recipes-kernel/kexec/kexec-tools.inc
index 50b448c..7e3b7ad 100644
--- a/meta/recipes-kernel/kexec/kexec-tools.inc
+++ b/meta/recipes-kernel/kexec/kexec-tools.inc
@@ -15,3 +15,14 @@ inherit autotools-brokensep
COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux|freebsd.*)'
INSANE_SKIP_${PN} = "arch"
+
+do_compile_prepend() {
+# Remove the '*.d' file to make sure the recompile is OK
+for dep in `find ${B} -type f -name '*.d'`; do
+dep_no_d="`echo $dep | sed 's#.d$##'`"
+# Remove file.d when there is a file.o
+if [ -f "$dep_no_d.o" ]; then
+rm -f $dep
+fi
+done
+}
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/7] libnewt: fix recompile error
Fixed:
NOTE: make -j 32
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stddef.h',
needed by `test.o'. Stop.
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the .depend isn't
regenerated when recompile, the content of the .depend are:
[snip]
test.o: /path/to/sysroot/4.9.0/include/stddef.h
[snip]
And Makefile includes the .depend file if it exists, so there would be
errors when /path/to/sysroot/4.9.0/include/stddef.h doesn't exist.
Remove .depend will fix the problem.
Signed-off-by: Robert Yang
---
meta/recipes-extended/newt/libnewt_0.52.17.bb |5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-extended/newt/libnewt_0.52.17.bb
b/meta/recipes-extended/newt/libnewt_0.52.17.bb
index 09b017e..28d5cf1 100644
--- a/meta/recipes-extended/newt/libnewt_0.52.17.bb
+++ b/meta/recipes-extended/newt/libnewt_0.52.17.bb
@@ -46,4 +46,9 @@ do_configure_prepend() {
sh autogen.sh
}
+do_compile_prepend() {
+# Make sure the recompile is OK
+rm -f ${B}/.depend
+}
+
FILES_whiptail = "${bindir}/whiptail"
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/7] trace-cmd: fix recompile error
Fixed:
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stddef.h',
needed by `parse-events.o'. Stop.
make: *** Waiting for unfinished jobs
ERROR: oe_runmake failed
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the
.parse-events.d isn't regenerated when recompile, the content of it are:
[snip]
parse-events.o: /path/to/sysroot/4.9.0/include/stddef.h
[snip]
And Makefile includes the .parse-events.d file if it exists, so there
would be errors when /path/to/sysroot/4.9.0/include/stddef.h doesn't
exist.
Remove .*.d (a few .d files, its Makefile uses this wildcard) will fix
the problem.
Signed-off-by: Robert Yang
---
meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb |5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb
b/meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb
index 6f3319d..7f99dde 100644
--- a/meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb
+++ b/meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb
@@ -18,6 +18,11 @@ EXTRA_OEMAKE = "'prefix=${prefix}'"
FILES_${PN}-dbg += "${datadir}/trace-cmd/plugins/.debug/"
+do_compile_prepend() {
+# Make sure the recompile is OK
+rm -f ${B}/.*.d
+}
+
do_install() {
oe_runmake prefix="${prefix}" DESTDIR="${D}" install
}
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/7] u-boot-mkimage: fix recompile error
Fixed:
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stddef.h',
needed by `crc32.o'. Stop.
make: *** Waiting for unfinished jobs
ERROR: oe_runmake failed
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the .depend isn't
regenerated when recompile, the content of it are:
[snip]
crc32.o: /path/to/sysroot/4.9.0/include/stddef.h
[snip]
And Makefile includes the .depend file if it exists, so there would be
errors when /path/to/sysroot/4.9.0/include/stddef.h doesn't exist.
Remove .*.d (a few .d files, its Makefile uses this wildcard) will fix
the problem.
Signed-off-by: Robert Yang
---
meta/recipes-bsp/u-boot/u-boot-mkimage_2013.07.bb |3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2013.07.bb
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2013.07.bb
index 2ca6050..93c8102 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2013.07.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2013.07.bb
@@ -17,6 +17,9 @@ S = "${WORKDIR}/git"
EXTRA_OEMAKE = 'HOSTCC="${CC}" HOSTLD="${LD}" HOSTLDFLAGS="${LDFLAGS}"
HOSTSTRIP=true'
do_compile () {
+ # Make sure the recompile is OK
+ rm -f ${B}/tools/.depend
+
oe_runmake tools
}
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/7] kernelshark: fix recompile error
Fixed:
make: *** No rule to make target `/path/to/sysroot/4.9.0/include/stddef.h',
needed by `parse-events.o'. Stop.
make: *** Waiting for unfinished jobs
ERROR: oe_runmake failed
This happens when upgrade gcc from 4.9.0 to 4.9.1, and the
.parse-events.d isn't regenerated when recompile, the content of it are:
[snip]
parse-events.o: /path/to/sysroot/4.9.0/include/stddef.h
[snip]
And Makefile includes the .parse-events.d file if it exists, so there
would be errors when /path/to/sysroot/4.9.0/include/stddef.h doesn't
exist.
Remove .*.d (a few .d files, its Makefile uses this wildcard) will fix
the problem.
Signed-off-by: Robert Yang
---
meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb |5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb
b/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb
index 9af91c9..99de97b 100644
--- a/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb
+++ b/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb
@@ -13,6 +13,11 @@ SRC_URI_append =
"file://kernelshark-fix-syntax-error-of-shell.patch"
EXTRA_OEMAKE = "'CC=${CC}' 'AR=${AR}' 'prefix=${prefix}' gui"
+do_compile_prepend() {
+# Make sure the recompile is OK
+rm -f ${B}/.*.d
+}
+
do_install() {
oe_runmake CC="${CC}" AR="${AR}" prefix="${prefix}" DESTDIR="${D}"
install_gui
rm ${D}${bindir}/trace-cmd
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] coreutils: drop patch that unconditionally mangles manpages
On 14-08-07 01:33 AM, Koen Kooi wrote:
>
> Op 6 aug. 2014, om 22:38 heeft Paul Gortmaker
> het volgende geschreven:
>
>> commit 841ec528ec04e64bd09ff10f8d9ad2d6e3aac05d ("coreutils: update
>> to upstream version 9.21") added a patch which bypassed the check
>> for perl and hence defaults to using the dummy man page for all
>> of the coreutils manpages. This results in all manpages looking like:
>>
>> NAME
>> chmod - a GNU coreutils 8.22 program
>>
>> DESCRIPTION
>> OOOPS! Due to the lack of perl on the build system, we were unable to
>> create a proper manual page for chmod.
>>
>> It is unclear why the test was disabled, but since it clearly
>> causes the manpages to be useless, we need to drop this patch.
>
> That all might be true, but DEPENDS doesn't list 'perl' or 'perl-native', so
> this commit is wrong.
Wrong might be overstated. The patch unconditionally disables a
_check_ for perl. So if perl is there, it is used; if it is absent,
it is not. Given that there really is no excuse for shipping
broken manpages, one could argue that a DEPENDS on perl-native
is sensible, and if that is what it takes to get the broken patch
dropped, I'll add one.
P.
--
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] How to force patch application
Not sure if there's an easy way with quilt (check the quilt options) but a relatively easy way would be to use your own patch routine (essentially anything you want). One thing you could do is disable the normal patch application (add ";patch=0" to the end of the patch line in SRC_URI) and then use your own do_patch to force it (if that's really what you want to do). I guess I would ask "why?" and if it were me I'd just reroll the patch and fix it. But I don't know what the real problem is, so... Steve On Thu, Aug 7, 2014 at 6:14 AM, Giuseppe Condorelli < giuseppe.condore...@gmail.com> wrote: > Hi All, > > please can I know if is it possible, using the do_patch routine, > to force the application of a given patch? > I mean, like the patch --force command. > > Please let me know, I tried w/o good result. > > Best Regards, > Giuseppe > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] How to force patch application
Hi Steve, thanks for the reply. The problem is that I need to force a patch application (like patch --force option) at my own risk. Do you see any solution? Giuseppe 2014-08-07 16:43 GMT+02:00 Stephen Arnold : > Not sure if there's an easy way with quilt (check the quilt options) but a > relatively easy way would be to use your own patch routine (essentially > anything you want). One thing you could do is disable the normal patch > application (add ";patch=0" to the end of the patch line in SRC_URI) and > then use your own do_patch to force it (if that's really what you want to > do). I guess I would ask "why?" and if it were me I'd just reroll the > patch and fix it. But I don't know what the real problem is, so... > > Steve > > > > On Thu, Aug 7, 2014 at 6:14 AM, Giuseppe Condorelli < > giuseppe.condore...@gmail.com> wrote: > >> Hi All, >> >> please can I know if is it possible, using the do_patch routine, >> to force the application of a given patch? >> I mean, like the patch --force command. >> >> Please let me know, I tried w/o good result. >> >> Best Regards, >> Giuseppe >> >> -- >> ___ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> >> > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] Yocto: kernel: Add basic fitImage support
This patch adds support for generating a kernel fitImage, which is
a a successor to the uImage format. Unlike uImage, which could only
contain the kernel image itself, the fitImage can contain all kinds
of artifacts, like the kernel image, device tree blobs, initramfs
images, binary firmwares etc. Furthermore, the fitImage supports
different kinds of checksums, not only CRC32 like the uImage did.
Last, but not least, fitImage supports signatures such that either
the whole image or it's parts can be signed and then in turn can
be verified by the bootloader.
So far we only add support for wrapping the kernel image and DTB
into the fitImage. The fitImage uses the sha1 checksum, which is
the default.
Signed-off-by: Marek Vasut
---
meta/classes/kernel.bbclass | 189 +++-
1 file changed, 186 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index b23e2e0..d0faab3 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -13,16 +13,20 @@ INITRAMFS_IMAGE_BUNDLE ?= ""
python __anonymous () {
kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
-if kerneltype == 'uImage':
+if kerneltype == 'uImage' or kerneltype == 'fitImage':
depends = d.getVar("DEPENDS", True)
depends = "%s u-boot-mkimage-native" % depends
d.setVar("DEPENDS", depends)
-d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", re.sub(r'\.[^\.]$', '', kerneltype))
+if kerneltype == 'fitImage':
+d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", "zImage")
+else:
+d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", re.sub(r'\.[^\.]$', '',
kerneltype))
image = d.getVar('INITRAMFS_IMAGE', True)
if image:
d.appendVarFlag('do_bundle_initramfs', 'depends', '
${INITRAMFS_IMAGE}:do_rootfs')
+d.appendVarFlag('do_assemble_fitimage', 'depends', '
${INITRAMFS_IMAGE}:do_rootfs')
# NOTE: setting INITRAMFS_TASK is for backward compatibility
# The preferred method is to set INITRAMFS_IMAGE, because
@@ -485,6 +489,164 @@ do_uboot_mkimage() {
addtask uboot_mkimage before do_install after do_compile
+#
+# Emit the fitImage ITS header
+#
+fitimage_emit_section_start() {
+ cat << EOF >> fit-image.its
+/dts-v1/;
+
+/ {
+description = "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}";
+#address-cells = <1>;
+
+images {
+EOF
+}
+
+#
+# Emit the fitImage ITS kernel section
+#
+# $1 ... Image counter
+# $2 ... Path to kernel image
+# $3 ... Compression type
+fitimage_emit_section_kernel() {
+
+ kernel_csum="sha1"
+
+ ENTRYPOINT=${UBOOT_ENTRYPOINT}
+ if test -n "${UBOOT_ENTRYSYMBOL}"; then
+ ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
+ awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
+ fi
+
+ cat << EOF >> fit-image.its
+kernel@${1} {
+description = "Linux kernel";
+data = /incbin/("${2}");
+type = "kernel";
+arch = "${UBOOT_ARCH}";
+os = "linux";
+compression = "${3}";
+load = <${UBOOT_LOADADDRESS}>;
+entry = <${ENTRYPOINT}>;
+hash@1 {
+algo = "${kernel_csum}";
+};
+};
+EOF
+}
+
+#
+# Emit the fitImage ITS DTB section
+#
+# $1 ... Image counter
+# $2 ... Path to DTB image
+fitimage_emit_section_dtb() {
+
+ dtb_csum="sha1"
+
+ cat << EOF >> fit-image.its
+fdt@${1} {
+description = "Flattened Device Tree blob";
+data = /incbin/("${2}");
+type = "flat_dt";
+arch = "${UBOOT_ARCH}";
+compression = "none";
+hash@1 {
+algo = "${dtb_csum}";
+};
+};
+EOF
+}
+
+#
+# Emit the fitImage ITS configuration section
+#
+# $1 ... Linux kernel ID
+# $2 ... DTB image ID
+fitimage_emit_section_config() {
+
+ conf_csum="sha1"
+
+ # Test if we have any DTBs at all
+ if [ -z "${2}" ] ; then
+ conf_desc="Boot Linux kernel"
+ fdt_line=""
+ else
+ conf_desc="Boot Linxu kernel with FDT blob"
+ fdt_line="fdt = \"fdt@${2}\";"
+ fi
+ kernel_line="kernel = \"kernel@${1}\";"
+
+ cat << EOF >> fit-image.its
+ };
+
+configurations {
+default = "conf@1";
+conf@1 {
+description = "${conf_desc}";
+ ${kernel_line}
+ ${fdt_line}
+hash@1 {
+algo = "${conf_csum}";
+};
+};
+};
+}
[OE-core] [PATCH] Yocto: qt4: Let qmake control some compiler/linker flags
In the case of building an Qt application outside of the Yocto
build system, we want to make sure that a "debug" configuration
of the application does contain debug symbols and is has the
compiler optimalization unset. On the other hand, we want to
have a "release" build which does not contain the debug symbols
and has the compiler optimalization turned on.
The OE_QMAKE_* flags serve to pass all kinds of flags into the
qmake-generated Makefile. Currently, we set OE_QMAKE_CFLAGS to
be ${CFLAGS} and ditto for CXXFLAGS and LDFLAGS in the SDK
toolchain environment script. This poses a problem, since the
CFLAGS can contain optimization options (-O*) and even flags to
produce debugging info (-g). The LDFLAGS may also contain some
harmful flags.
The easy way out is to let qmake's army of configuration files
handle the proper configuration of CFLAGS, CXXFLAGS and LDFLAGS
for the generated Makefile and don't interfere with qmake's
decisions by adding arbitrary flags. This patch completely
scrubs OE_QMAKE_C{,XX}FLAGS and leaves only harmless flags in
OE_QMAKE_LDFLAGS. With this patch, the behavior is as it is
explained in the first paragraph.
Signed-off-by: Marek Vasut
Cc: Eric Bénard
---
meta/recipes-qt/meta/meta-toolchain-qt.inc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-qt/meta/meta-toolchain-qt.inc
b/meta/recipes-qt/meta/meta-toolchain-qt.inc
index c9bdeae..6b162bd 100644
--- a/meta/recipes-qt/meta/meta-toolchain-qt.inc
+++ b/meta/recipes-qt/meta/meta-toolchain-qt.inc
@@ -7,9 +7,9 @@ require recipes-core/meta/meta-toolchain.bb
QT_TOOLS_PREFIX = "${SDKPATHNATIVE}${bindir_nativesdk}"
toolchain_create_sdk_env_script_append() {
-echo 'export OE_QMAKE_CFLAGS="$CFLAGS"' >> $script
-echo 'export OE_QMAKE_CXXFLAGS="$CXXFLAGS"' >> $script
-echo 'export OE_QMAKE_LDFLAGS="$LDFLAGS"' >> $script
+echo 'export OE_QMAKE_CFLAGS=""' >> $script
+echo 'export OE_QMAKE_CXXFLAGS=""' >> $script
+echo 'export OE_QMAKE_LDFLAGS="${TARGET_LINK_HASH_STYLE}"' >> $script
echo 'export OE_QMAKE_CC=$CC' >> $script
echo 'export OE_QMAKE_CXX=$CXX' >> $script
echo 'export OE_QMAKE_LINK=$CXX' >> $script
--
2.0.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] Yocto: kernel: Pull out the linux.bin generation
Pull the generation of linux.bin image, which is then packed into uImage,
into a separate function. No functional change.
Signed-off-by: Marek Vasut
---
meta/classes/kernel.bbclass | 40 +++-
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 2e2b1fe..62e3a4b 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -444,26 +444,32 @@ MODULE_TARBALL_BASE_NAME ?=
"${MODULE_IMAGE_BASE_NAME}.tgz"
MODULE_TARBALL_SYMLINK_NAME ?= "modules-${MACHINE}.tgz"
MODULE_TARBALL_DEPLOY ?= "1"
+uboot_prep_kimage() {
+ if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+ vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
+ linux_suffix=""
+ linux_comp="none"
+ else
+ vmlinux_path="vmlinux"
+ linux_suffix=".gz"
+ linux_comp="gzip"
+ fi
+
+ ${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
+
+ if [ "${linux_comp}" != "none" ] ; then
+ rm -f linux.bin
+ gzip -9 linux.bin
+ mv -f "linux.bin${linux_suffix}" linux.bin
+ fi
+
+ echo "${linux_comp}"
+}
+
do_uboot_mkimage() {
if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
if test "x${KEEPUIMAGE}" != "xyes" ; then
- if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
-
vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
- linux_suffix=""
- linux_comp="none"
- else
- vmlinux_path="vmlinux"
- linux_suffix=".gz"
- linux_comp="gzip"
- fi
-
- ${OBJCOPY} -O binary -R .note -R .comment -S
"${vmlinux_path}" linux.bin
-
- if [ "${linux_comp}" != "none" ] ; then
- rm -f linux.bin
- gzip -9 linux.bin
- mv -f "linux.bin${linux_suffix}" linux.bin
- fi
+ uboot_prep_kimage
ENTRYPOINT=${UBOOT_ENTRYPOINT}
if test -n "${UBOOT_ENTRYSYMBOL}"; then
--
2.0.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] Yocto: kernel: Rework do_uboot_mkimage
Rework the function so part it's internals can be re-used by fitImage
image type. The name of the temporary file , linux.bin , is recycled
a little more as it's now used for both the case where it is gzip
compressed and where it is not. This should be fine, since the file
is temporary and removed after the uImage was created anyway.
There is no functional change here.
Signed-off-by: Marek Vasut
---
meta/classes/kernel.bbclass | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6ed1cb7..2e2b1fe 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -447,22 +447,32 @@ MODULE_TARBALL_DEPLOY ?= "1"
do_uboot_mkimage() {
if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
if test "x${KEEPUIMAGE}" != "xyes" ; then
+ if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+
vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
+ linux_suffix=""
+ linux_comp="none"
+ else
+ vmlinux_path="vmlinux"
+ linux_suffix=".gz"
+ linux_comp="gzip"
+ fi
+
+ ${OBJCOPY} -O binary -R .note -R .comment -S
"${vmlinux_path}" linux.bin
+
+ if [ "${linux_comp}" != "none" ] ; then
+ rm -f linux.bin
+ gzip -9 linux.bin
+ mv -f "linux.bin${linux_suffix}" linux.bin
+ fi
+
ENTRYPOINT=${UBOOT_ENTRYPOINT}
if test -n "${UBOOT_ENTRYSYMBOL}"; then
ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
awk '$3=="${UBOOT_ENTRYSYMBOL}" {print
$1}'`
fi
- if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
- ${OBJCOPY} -O binary -R .note -R .comment -S
arch/${ARCH}/boot/compressed/vmlinux linux.bin
- uboot-mkimage -A ${UBOOT_ARCH} -O linux -T
kernel -C none -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
"${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
- rm -f linux.bin
- else
- ${OBJCOPY} -O binary -R .note -R .comment -S
vmlinux linux.bin
- rm -f linux.bin.gz
- gzip -9 linux.bin
- uboot-mkimage -A ${UBOOT_ARCH} -O linux -T
kernel -C gzip -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
"${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin.gz arch/${ARCH}/boot/uImage
- rm -f linux.bin.gz
- fi
+
+ uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C
"${linux_comp}" -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n
"${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
+ rm -f linux.bin
fi
fi
}
--
2.0.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][RESEND] Yocto: qt4: Avoid duplicate flags in the g++-unix.conf
The removed flags from this g++.conf file, which is installed to the
target as g++-unix.conf are added by gcc-base.conf . Do not add those
flags twice.
Signed-off-by: Marek Vasut
Cc: Eric Bénard
---
meta/recipes-qt/qt4/qt4-4.8.5/g++.conf | 25 ++---
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/meta/recipes-qt/qt4/qt4-4.8.5/g++.conf
b/meta/recipes-qt/qt4/qt4-4.8.5/g++.conf
index 8755031..be78c24 100644
--- a/meta/recipes-qt/qt4/qt4-4.8.5/g++.conf
+++ b/meta/recipes-qt/qt4/qt4-4.8.5/g++.conf
@@ -5,32 +5,14 @@
QMAKE_COMPILER = gcc
QMAKE_CC = $(OE_QMAKE_CC)
-QMAKE_CFLAGS += -pipe $(OE_QMAKE_CFLAGS)
+QMAKE_CFLAGS += $(OE_QMAKE_CFLAGS)
QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO += $(OE_QMAKE_CFLAGS)
-QMAKE_CFLAGS_DEPS += -M
-QMAKE_CFLAGS_WARN_ON += -Wall -W
-QMAKE_CFLAGS_WARN_OFF += -w
-QMAKE_CFLAGS_RELEASE +=
-QMAKE_CFLAGS_DEBUG += -g
-QMAKE_CFLAGS_SHLIB += -fPIC
-QMAKE_CFLAGS_STATIC_LIB+= -fPIC
-QMAKE_CFLAGS_YACC += -Wno-unused -Wno-parentheses
-QMAKE_CFLAGS_HIDESYMS += -fvisibility=hidden
QMAKE_CFLAGS_PRECOMPILE += -x c-header -c ${QMAKE_PCH_INPUT} -o
${QMAKE_PCH_OUTPUT}
QMAKE_CFLAGS_USE_PRECOMPILE += -include ${QMAKE_PCH_OUTPUT_BASE}
QMAKE_CXX = $(OE_QMAKE_CXX)
-QMAKE_CXXFLAGS += $$QMAKE_CFLAGS $(OE_QMAKE_CXXFLAGS)
-QMAKE_CXXFLAGS_DEPS+= $$QMAKE_CFLAGS_DEPS
-QMAKE_CXXFLAGS_WARN_ON += $$QMAKE_CFLAGS_WARN_ON
-QMAKE_CXXFLAGS_WARN_OFF+= $$QMAKE_CFLAGS_WARN_OFF
-QMAKE_CXXFLAGS_RELEASE += $$QMAKE_CFLAGS_RELEASE
+QMAKE_CXXFLAGS += $(OE_QMAKE_CXXFLAGS)
QMAKE_CXXFLAGS_RELEASE_WITH_DEBUGINFO += $$QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO
-QMAKE_CXXFLAGS_DEBUG += $$QMAKE_CFLAGS_DEBUG
-QMAKE_CXXFLAGS_SHLIB += $$QMAKE_CFLAGS_SHLIB
-QMAKE_CXXFLAGS_STATIC_LIB += $$QMAKE_CFLAGS_STATIC_LIB
-QMAKE_CXXFLAGS_YACC+= $$QMAKE_CFLAGS_YACC
-QMAKE_CXXFLAGS_HIDESYMS += $$QMAKE_CFLAGS_HIDESYMS -fvisibility-inlines-hidden
QMAKE_CXXFLAGS_PRECOMPILE += -x c++-header -c ${QMAKE_PCH_INPUT} -o
${QMAKE_PCH_OUTPUT}
QMAKE_CXXFLAGS_USE_PRECOMPILE = $$QMAKE_CFLAGS_USE_PRECOMPILE
@@ -39,9 +21,6 @@ QMAKE_LINK_SHLIB = $(OE_QMAKE_LINK)
QMAKE_LINK_C = $(OE_QMAKE_LINK)
QMAKE_LINK_C_SHLIB = $(OE_QMAKE_LINK)
QMAKE_LFLAGS += $(OE_QMAKE_LDFLAGS)
-QMAKE_LFLAGS_RELEASE +=
-QMAKE_LFLAGS_DEBUG +=
-QMAKE_LFLAGS_APP +=
QMAKE_LFLAGS_NOUNDEF += -Wl,--no-undefined
QMAKE_LFLAGS_RPATH= -Wl,-rpath-link,
--
2.0.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5] Add initial fitImage support
The fitImage is a successor of the U-Boot uImage format, which is considered legacy for years now. The fitImage allows packing multiple kernel images, DTBs and other artifacts into a single image, which can then be protected by SHA checksums and does even support signing the images for verified boot. This patchset is the first stab at adding the new image format into Yocto. Marek Vasut (5): Yocto: kernel: Rework do_uboot_mkimage Yocto: kernel: Pull out the linux.bin generation Yocto: kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE Yocto: kernel: Build DTBs early Yocto: kernel: Add basic fitImage support meta/classes/kernel.bbclass | 229 +--- meta/recipes-kernel/linux/linux-dtb.inc | 14 +- 2 files changed, 226 insertions(+), 17 deletions(-) -- 2.0.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5] Add initial fitImage support
The fitImage is a successor of the U-Boot uImage format, which is considered legacy for years now. The fitImage allows packing multiple kernel images, DTBs and other artifacts into a single image, which can then be protected by SHA checksums and does even support signing the images for verified boot. This patchset is the first stab at adding the new image format into Yocto. Marek Vasut (5): Yocto: kernel: Rework do_uboot_mkimage Yocto: kernel: Pull out the linux.bin generation Yocto: kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE Yocto: kernel: Build DTBs early Yocto: kernel: Add basic fitImage support meta/classes/kernel.bbclass | 229 +--- meta/recipes-kernel/linux/linux-dtb.inc | 14 +- 2 files changed, 226 insertions(+), 17 deletions(-) -- 2.0.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] Yocto: kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE
Remove the lambda function setting KERNEL_IMAGETYPE_FOR_MAKE and instead
set it in the anonymous python function. This also allows us to handle
image types which are not supported directly by kernel, but require some
other kernel target to be built. This is the case for example with the
fitImage, which is the uImage successor.
There is no functional change.
Signed-off-by: Marek Vasut
---
meta/classes/kernel.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 62e3a4b..b23e2e0 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -18,6 +18,8 @@ python __anonymous () {
depends = "%s u-boot-mkimage-native" % depends
d.setVar("DEPENDS", depends)
+d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", re.sub(r'\.[^\.]$', '', kerneltype))
+
image = d.getVar('INITRAMFS_IMAGE', True)
if image:
d.appendVarFlag('do_bundle_initramfs', 'depends', '
${INITRAMFS_IMAGE}:do_rootfs')
@@ -79,8 +81,6 @@ KERNEL_ALT_IMAGETYPE ??= ""
# they are staged.
KERNEL_SRC_PATH = "/usr/src/kernel"
-KERNEL_IMAGETYPE_FOR_MAKE = "${@(lambda s: s[:-3] if s[-3:] == ".gz" else
s)(d.getVar('KERNEL_IMAGETYPE', True))}"
-
copy_initramfs() {
echo "Copying initramfs into ./usr ..."
# In case the directory is not created yet from the first pass compile:
--
2.0.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] Yocto: kernel: Build DTBs early
Pull out the compilation of the DTB blobs right after the kernel's
own do_compile function finishes. This makes them available just in
time for the kernel image construction functions.
Signed-off-by: Marek Vasut
---
meta/recipes-kernel/linux/linux-dtb.inc | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index 6b8f1a5..ee3a5e1 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -5,6 +5,18 @@ python __anonymous () {
d.appendVar("PACKAGES", " kernel-devicetree")
}
+do_compile_append() {
+ if test -n "${KERNEL_DEVICETREE}"; then
+ for DTB in ${KERNEL_DEVICETREE}; do
+ if echo ${DTB} | grep -q '/dts/'; then
+ bbwarn "${DTB} contains the full path to the
the dts file, but only the dtb name should be used."
+ DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
+ fi
+ oe_runmake ${DTB}
+ done
+ fi
+}
+
do_install_append() {
if test -n "${KERNEL_DEVICETREE}"; then
for DTB in ${KERNEL_DEVICETREE}; do
@@ -13,10 +25,8 @@ do_install_append() {
DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
fi
DTB_BASE_NAME=`basename ${DTB} .dtb`
- DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed "s/${MACHINE}/${DTB_BASE_NAME}/g"`
DTB_PATH="${B}/arch/${ARCH}/boot/dts/${DTB}"
- oe_runmake ${DTB}
if [ ! -e "${DTB_PATH}" ]; then
DTB_PATH="${B}/arch/${ARCH}/boot/${DTB}"
fi
--
2.0.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] Yocto: kernel: Add basic fitImage support
This patch adds support for generating a kernel fitImage, which is
a a successor to the uImage format. Unlike uImage, which could only
contain the kernel image itself, the fitImage can contain all kinds
of artifacts, like the kernel image, device tree blobs, initramfs
images, binary firmwares etc. Furthermore, the fitImage supports
different kinds of checksums, not only CRC32 like the uImage did.
Last, but not least, fitImage supports signatures such that either
the whole image or it's parts can be signed and then in turn can
be verified by the bootloader.
So far we only add support for wrapping the kernel image and DTB
into the fitImage. The fitImage uses the sha1 checksum, which is
the default.
Signed-off-by: Marek Vasut
---
meta/classes/kernel.bbclass | 189 +++-
1 file changed, 186 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index b23e2e0..d0faab3 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -13,16 +13,20 @@ INITRAMFS_IMAGE_BUNDLE ?= ""
python __anonymous () {
kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
-if kerneltype == 'uImage':
+if kerneltype == 'uImage' or kerneltype == 'fitImage':
depends = d.getVar("DEPENDS", True)
depends = "%s u-boot-mkimage-native" % depends
d.setVar("DEPENDS", depends)
-d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", re.sub(r'\.[^\.]$', '', kerneltype))
+if kerneltype == 'fitImage':
+d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", "zImage")
+else:
+d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", re.sub(r'\.[^\.]$', '',
kerneltype))
image = d.getVar('INITRAMFS_IMAGE', True)
if image:
d.appendVarFlag('do_bundle_initramfs', 'depends', '
${INITRAMFS_IMAGE}:do_rootfs')
+d.appendVarFlag('do_assemble_fitimage', 'depends', '
${INITRAMFS_IMAGE}:do_rootfs')
# NOTE: setting INITRAMFS_TASK is for backward compatibility
# The preferred method is to set INITRAMFS_IMAGE, because
@@ -485,6 +489,164 @@ do_uboot_mkimage() {
addtask uboot_mkimage before do_install after do_compile
+#
+# Emit the fitImage ITS header
+#
+fitimage_emit_section_start() {
+ cat << EOF >> fit-image.its
+/dts-v1/;
+
+/ {
+description = "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}";
+#address-cells = <1>;
+
+images {
+EOF
+}
+
+#
+# Emit the fitImage ITS kernel section
+#
+# $1 ... Image counter
+# $2 ... Path to kernel image
+# $3 ... Compression type
+fitimage_emit_section_kernel() {
+
+ kernel_csum="sha1"
+
+ ENTRYPOINT=${UBOOT_ENTRYPOINT}
+ if test -n "${UBOOT_ENTRYSYMBOL}"; then
+ ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
+ awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
+ fi
+
+ cat << EOF >> fit-image.its
+kernel@${1} {
+description = "Linux kernel";
+data = /incbin/("${2}");
+type = "kernel";
+arch = "${UBOOT_ARCH}";
+os = "linux";
+compression = "${3}";
+load = <${UBOOT_LOADADDRESS}>;
+entry = <${ENTRYPOINT}>;
+hash@1 {
+algo = "${kernel_csum}";
+};
+};
+EOF
+}
+
+#
+# Emit the fitImage ITS DTB section
+#
+# $1 ... Image counter
+# $2 ... Path to DTB image
+fitimage_emit_section_dtb() {
+
+ dtb_csum="sha1"
+
+ cat << EOF >> fit-image.its
+fdt@${1} {
+description = "Flattened Device Tree blob";
+data = /incbin/("${2}");
+type = "flat_dt";
+arch = "${UBOOT_ARCH}";
+compression = "none";
+hash@1 {
+algo = "${dtb_csum}";
+};
+};
+EOF
+}
+
+#
+# Emit the fitImage ITS configuration section
+#
+# $1 ... Linux kernel ID
+# $2 ... DTB image ID
+fitimage_emit_section_config() {
+
+ conf_csum="sha1"
+
+ # Test if we have any DTBs at all
+ if [ -z "${2}" ] ; then
+ conf_desc="Boot Linux kernel"
+ fdt_line=""
+ else
+ conf_desc="Boot Linxu kernel with FDT blob"
+ fdt_line="fdt = \"fdt@${2}\";"
+ fi
+ kernel_line="kernel = \"kernel@${1}\";"
+
+ cat << EOF >> fit-image.its
+ };
+
+configurations {
+default = "conf@1";
+conf@1 {
+description = "${conf_desc}";
+ ${kernel_line}
+ ${fdt_line}
+hash@1 {
+algo = "${conf_csum}";
+};
+};
+};
+}
[OE-core] [PATCH 3/5] Yocto: kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE
Remove the lambda function setting KERNEL_IMAGETYPE_FOR_MAKE and instead
set it in the anonymous python function. This also allows us to handle
image types which are not supported directly by kernel, but require some
other kernel target to be built. This is the case for example with the
fitImage, which is the uImage successor.
There is no functional change.
Signed-off-by: Marek Vasut
---
meta/classes/kernel.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 62e3a4b..b23e2e0 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -18,6 +18,8 @@ python __anonymous () {
depends = "%s u-boot-mkimage-native" % depends
d.setVar("DEPENDS", depends)
+d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", re.sub(r'\.[^\.]$', '', kerneltype))
+
image = d.getVar('INITRAMFS_IMAGE', True)
if image:
d.appendVarFlag('do_bundle_initramfs', 'depends', '
${INITRAMFS_IMAGE}:do_rootfs')
@@ -79,8 +81,6 @@ KERNEL_ALT_IMAGETYPE ??= ""
# they are staged.
KERNEL_SRC_PATH = "/usr/src/kernel"
-KERNEL_IMAGETYPE_FOR_MAKE = "${@(lambda s: s[:-3] if s[-3:] == ".gz" else
s)(d.getVar('KERNEL_IMAGETYPE', True))}"
-
copy_initramfs() {
echo "Copying initramfs into ./usr ..."
# In case the directory is not created yet from the first pass compile:
--
2.0.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] Yocto: kernel: Pull out the linux.bin generation
Pull the generation of linux.bin image, which is then packed into uImage,
into a separate function. No functional change.
Signed-off-by: Marek Vasut
---
meta/classes/kernel.bbclass | 40 +++-
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 2e2b1fe..62e3a4b 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -444,26 +444,32 @@ MODULE_TARBALL_BASE_NAME ?=
"${MODULE_IMAGE_BASE_NAME}.tgz"
MODULE_TARBALL_SYMLINK_NAME ?= "modules-${MACHINE}.tgz"
MODULE_TARBALL_DEPLOY ?= "1"
+uboot_prep_kimage() {
+ if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+ vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
+ linux_suffix=""
+ linux_comp="none"
+ else
+ vmlinux_path="vmlinux"
+ linux_suffix=".gz"
+ linux_comp="gzip"
+ fi
+
+ ${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin
+
+ if [ "${linux_comp}" != "none" ] ; then
+ rm -f linux.bin
+ gzip -9 linux.bin
+ mv -f "linux.bin${linux_suffix}" linux.bin
+ fi
+
+ echo "${linux_comp}"
+}
+
do_uboot_mkimage() {
if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
if test "x${KEEPUIMAGE}" != "xyes" ; then
- if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
-
vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
- linux_suffix=""
- linux_comp="none"
- else
- vmlinux_path="vmlinux"
- linux_suffix=".gz"
- linux_comp="gzip"
- fi
-
- ${OBJCOPY} -O binary -R .note -R .comment -S
"${vmlinux_path}" linux.bin
-
- if [ "${linux_comp}" != "none" ] ; then
- rm -f linux.bin
- gzip -9 linux.bin
- mv -f "linux.bin${linux_suffix}" linux.bin
- fi
+ uboot_prep_kimage
ENTRYPOINT=${UBOOT_ENTRYPOINT}
if test -n "${UBOOT_ENTRYSYMBOL}"; then
--
2.0.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] coreutils: drop patch that unconditionally mangles manpages
On Thu, Aug 07, 2014 at 09:48:26AM -0400, Paul Gortmaker wrote:
> On 14-08-07 01:33 AM, Koen Kooi wrote:
> >
> > Op 6 aug. 2014, om 22:38 heeft Paul Gortmaker
> > het volgende geschreven:
> >
> >> commit 841ec528ec04e64bd09ff10f8d9ad2d6e3aac05d ("coreutils: update
> >> to upstream version 9.21") added a patch which bypassed the check
> >> for perl and hence defaults to using the dummy man page for all
> >> of the coreutils manpages. This results in all manpages looking like:
> >>
> >> NAME
> >> chmod - a GNU coreutils 8.22 program
> >>
> >> DESCRIPTION
> >> OOOPS! Due to the lack of perl on the build system, we were unable
> >> to
> >> create a proper manual page for chmod.
> >>
> >> It is unclear why the test was disabled, but since it clearly
> >> causes the manpages to be useless, we need to drop this patch.
> >
> > That all might be true, but DEPENDS doesn't list 'perl' or 'perl-native',
> > so this commit is wrong.
>
> Wrong might be overstated. The patch unconditionally disables a
> _check_ for perl. So if perl is there, it is used; if it is absent,
> it is not. Given that there really is no excuse for shipping
> broken manpages, one could argue that a DEPENDS on perl-native
> is sensible, and if that is what it takes to get the broken patch
> dropped, I'll add one.
undeterministic build results mean it's broken
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain
The Qt SDK toolchain pulls in python via packagegroup-cross-canadian-${MACHINE}
and ships it. But the python is missing many modules and is rather incomplete.
The environment-setup-* script configures the PATH variable to point into
it's own sysroot first, it means the python from the SDK is used as well
when the environment is configured. It actually does make sense to use the
python from the SDK, since the SDK should provide the tools needed to build
additional software.
The problem is, the python in the SDK image is stripped to a bare minimum
of modules, which prevents some software from being built with the SDK as
is. Add the same python modules as the buildtools-tarball.bb adds to make
the python shipped with the SDK complete.
Signed-off-by: Marek Vasut
---
meta/recipes-qt/meta/meta-toolchain-qt.inc | 32 +-
1 file changed, 31 insertions(+), 1 deletion(-)
NOTE: This lets me build U-Boot git HEAD , which now has Kconfig in it
and that depends on the "subprocess" module. But instead of adding
just one module, I want to fix this properly and future-proof this.
diff --git a/meta/recipes-qt/meta/meta-toolchain-qt.inc
b/meta/recipes-qt/meta/meta-toolchain-qt.inc
index 6b162bd..99d5e64 100644
--- a/meta/recipes-qt/meta/meta-toolchain-qt.inc
+++ b/meta/recipes-qt/meta/meta-toolchain-qt.inc
@@ -1,4 +1,34 @@
-TOOLCHAIN_HOST_TASK = "nativesdk-packagegroup-${QTNAME}-toolchain-host
packagegroup-cross-canadian-${MACHINE}"
+TOOLCHAIN_HOST_TASK = " \
+ nativesdk-packagegroup-${QTNAME}-toolchain-host \
+ packagegroup-cross-canadian-${MACHINE} \
+ nativesdk-python-core \
+ nativesdk-python-textutils \
+ nativesdk-python-sqlite3 \
+ nativesdk-python-pickle \
+ nativesdk-python-logging \
+ nativesdk-python-elementtree \
+ nativesdk-python-curses \
+ nativesdk-python-compile \
+ nativesdk-python-compiler \
+ nativesdk-python-fcntl \
+ nativesdk-python-shell \
+ nativesdk-python-misc \
+ nativesdk-python-multiprocessing \
+ nativesdk-python-subprocess \
+ nativesdk-python-xmlrpc \
+ nativesdk-python-netclient \
+ nativesdk-python-netserver \
+ nativesdk-python-distutils \
+ nativesdk-python-unixadmin \
+ nativesdk-python-compression \
+ nativesdk-python-json \
+ nativesdk-python-unittest \
+ nativesdk-python-mmap \
+ nativesdk-python-difflib \
+ nativesdk-python-pprint \
+ nativesdk-python-git \
+ nativesdk-python-pkgutil \
+ "
TOOLCHAIN_TARGET_TASK = "packagegroup-${QTNAME}-toolchain-target"
TOOLCHAIN_OUTPUTNAME = "${SDK_NAME}-toolchain-${QTNAME}-${DISTRO_VERSION}"
--
2.0.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] opkg-utils: allow disabling update-alternatives
On 08/07/2014 02:24 AM, Sujith H wrote:
From: Sujith H
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as PREFERRED_PROVIDER, but it is more explicit that way.
Signed-off-by: Christopher Larson
Signed-off-by: Sujith H
---
meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
index 693c216..9364740 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
@@ -19,11 +19,17 @@ TARGET_CC_ARCH += "${LDFLAGS}"
PYTHONRDEPS = "python python-shell python-io python-math python-crypt
python-logging python-fcntl python-subprocess python-pickle python-compression
python-textutils python-stringold"
PYTHONRDEPS_class-native = ""
-PACKAGECONFIG = "python"
+PACKAGECONFIG = "python update-alternatives"
PACKAGECONFIG[python] = ",,,${PYTHONRDEPS}"
+PACKAGECONFIG[update-alternatives] = ",,,"
+
+PROVIDES += "${@'virtual/update-alternatives' if 'update-alternatives' in
PACKAGECONFIG.split() else ''}"
Is there not still a PROVIDES line above that has the
virtual/update-alternative that needs to be removed?
Sau!
do_install() {
oe_runmake PREFIX=${prefix} DESTDIR=${D} install
+if ${@'true' if 'update-alternatives' not in PACKAGECONFIG.split()
else 'false'}; then
+rm -f "${D}${bindir}/update-alternatives"
+fi
}
PACKAGES =+ "update-alternatives-opkg"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] Add initial fitImage support
On 08/07/2014 08:17 AM, Marek Vasut wrote: The fitImage is a successor of the U-Boot uImage format, which is considered legacy for years now. The fitImage allows packing multiple kernel images, DTBs and other artifacts into a single image, which can then be protected by SHA checksums and does even support signing the images for verified boot. This patchset is the first stab at adding the new image format into Yocto. Marek Vasut (5): Yocto: kernel: Rework do_uboot_mkimage Yocto: kernel: Pull out the linux.bin generation Yocto: kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE Yocto: kernel: Build DTBs early Yocto: kernel: Add basic fitImage support meta/classes/kernel.bbclass | 229 +--- meta/recipes-kernel/linux/linux-dtb.inc | 14 +- 2 files changed, 226 insertions(+), 17 deletions(-) Hi Marek, I am going to make a general request, can you please review the Commit Guildlines Wiki for Openembedded: http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines We appreciate your patches, but the commit messages need to be formatted correctly. The Yocto: tag is not needed and you could clearly include which recipe, bbclass, file or subsystem (if across multiple files) so in the above it would be kernel.bbclass: ... If you could please resubmit your changes with the correct commit summary for this series and your other patches that would be greatly appreciated. Myself and others may have further feedback on your patches. Thanks Sau! -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] ubootchart: delete ubootchart recipe
The Ubootchart recipe had known issues. Ubootchart itself is no longer updated upstream. Ubootchart is also now redundant with Bootchart2. If people still want ubootchart around, it can be moved to meta-oe. Ubootchart removed as part of the solution to [YOCTO #5893]. Signed-off-by: Max Eliaser --- meta-yocto/conf/distro/include/distro_alias.inc| 1 - meta-yocto/conf/distro/include/maintainers.inc | 1 - meta-yocto/conf/distro/include/recipe_color.inc| 1 - .../conf/distro/include/upstream_tracking.inc | 2 -- .../ubootchart/files/sysvinit.patch| 14 .../ubootchart/files/ubootchart-stop | 3 -- .../ubootchart/files/ubootchart.desktop| 6 meta/recipes-devtools/ubootchart/ubootchart_svn.bb | 39 -- 8 files changed, 67 deletions(-) delete mode 100644 meta/recipes-devtools/ubootchart/files/sysvinit.patch delete mode 100644 meta/recipes-devtools/ubootchart/files/ubootchart-stop delete mode 100644 meta/recipes-devtools/ubootchart/files/ubootchart.desktop delete mode 100644 meta/recipes-devtools/ubootchart/ubootchart_svn.bb diff --git a/meta-yocto/conf/distro/include/distro_alias.inc b/meta-yocto/conf/distro/include/distro_alias.inc index 48c1d92..5e2f214 100644 --- a/meta-yocto/conf/distro/include/distro_alias.inc +++ b/meta-yocto/conf/distro/include/distro_alias.inc @@ -435,7 +435,6 @@ DISTRO_PN_ALIAS_pn-tremor = "OSPDT upstream=http://www.xiph.org/vorbis/"; DISTRO_PN_ALIAS_pn-tslib = "Debian=tslib Ubuntu=tslib" DISTRO_PN_ALIAS_pn-ttf-bitstream-vera = "Debian=ttf-bitstream-vera Ubuntu=ttf-bitstream-vera" DISTRO_PN_ALIAS_pn-tzcode = "OSPDT" -DISTRO_PN_ALIAS_pn-ubootchart = "OSPDT upstream=http://code.google.com/p/ubootchart"; DISTRO_PN_ALIAS_pn-u-boot-fw-utils = "Ubuntu=u-boot-tools Debian=u-boot-tools" DISTRO_PN_ALIAS_pn-u-boot-mkimage = "Ubuntu=uboot-mkimage Debian=uboot-mkimage" DISTRO_PN_ALIAS_pn-udev-extraconf = "OE-Core" diff --git a/meta-yocto/conf/distro/include/maintainers.inc b/meta-yocto/conf/distro/include/maintainers.inc index 7430c85..13e9209 100644 --- a/meta-yocto/conf/distro/include/maintainers.inc +++ b/meta-yocto/conf/distro/include/maintainers.inc @@ -646,7 +646,6 @@ RECIPE_MAINTAINER_pn-tslib = "Paul Eggleton " RECIPE_MAINTAINER_pn-ttf-bitstream-vera = "Valentin Popa " RECIPE_MAINTAINER_pn-tzcode-native = "Robert Yang " RECIPE_MAINTAINER_pn-tzdata = "Robert Yang " -RECIPE_MAINTAINER_pn-ubootchart = "Cristiana Voicu " RECIPE_MAINTAINER_pn-u-boot-fw-utils = "Cristiana Voicu " RECIPE_MAINTAINER_pn-u-boot-mkimage = "Cristiana Voicu " RECIPE_MAINTAINER_pn-udev-extraconf = "Cristiana Voicu " diff --git a/meta-yocto/conf/distro/include/recipe_color.inc b/meta-yocto/conf/distro/include/recipe_color.inc index 7e50500..5474e83 100644 --- a/meta-yocto/conf/distro/include/recipe_color.inc +++ b/meta-yocto/conf/distro/include/recipe_color.inc @@ -383,7 +383,6 @@ RECIPE_COLOR_pn-trapproto = "yellow" RECIPE_COLOR_pn-tslib = "yellow" RECIPE_COLOR_pn-ttf-bitstream-vera = "yellow" RECIPE_COLOR_pn-tzdata = "yellow" -RECIPE_COLOR_pn-ubootchart = "red" RECIPE_COLOR_pn-u-boot-mkimage = "red" RECIPE_COLOR_pn-udev = "yellow" RECIPE_COLOR_pn-udev-extraconf = "yellow" diff --git a/meta-yocto/conf/distro/include/upstream_tracking.inc b/meta-yocto/conf/distro/include/upstream_tracking.inc index d80ede4..714b692 100644 --- a/meta-yocto/conf/distro/include/upstream_tracking.inc +++ b/meta-yocto/conf/distro/include/upstream_tracking.inc @@ -207,8 +207,6 @@ RECIPE_UPSTREAM_VERSION_pn-tremor="20120122" RECIPE_UPSTREAM_DATE_pn-tremor="Jan 22, 2012" CHECK_DATE_pn-tremor = "Mar 11, 2013" RECIPE_NO_UPDATE_REASON_pn-tremor = "Same revision on different SVN modules" -RECIPE_UPSTREAM_VERSION_pn-ubootchart = "0.0+r12" -CHECK_DATE_pn-ubootchart = "Sep 11, 2012" RECIPE_UPSTREAM_DATE_pn-udev-extraconf = "n/a" RECIPE_UPSTREAM_VERSION_pn-unifdef-native="2.6.18+git" RECIPE_UPSTREAM_DATE_pn-unifdef-native = "Feb 05, 2011" diff --git a/meta/recipes-devtools/ubootchart/files/sysvinit.patch b/meta/recipes-devtools/ubootchart/files/sysvinit.patch deleted file mode 100644 index fc82ed8..000 --- a/meta/recipes-devtools/ubootchart/files/sysvinit.patch +++ /dev/null @@ -1,14 +0,0 @@ -Upstream-Status: Inappropriate [distribution] - -Index: ubootchart.conf -=== ubootchart.conf(revision 9) -+++ ubootchart.conf(working copy) -@@ -1,6 +1,6 @@ - - # If you want to chain on and run somthing other than /sbin/init... --export init_prog=/sbin/init -+export init_prog=/sbin/init.sysvinit - - # On startup ubootchart will mount a tmpfs filesystem at this - # location and chdir here. This is only used for the logging of diff --git a/meta/recipes-devtools/ubootchart/files/ubootchart-stop b/meta/recipes-devtools/ubootchart/files/ubootchart-stop deleted file mode 100644 index 3444069..000 --- a/meta/recipes-devtools/ubootchart/files/ub
[OE-core] [PATCH 1/3] python: python-pycairo: add python-pycairo-native
A -native variant of python-pycairo will be necessary for running the native
version of pybootchartgui. It may also come in handy for running other Python
utilities from the native sysroot.
Signed-off-by: Max Eliaser
---
meta/recipes-devtools/python/python-pycairo_1.10.0.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/python/python-pycairo_1.10.0.bb
b/meta/recipes-devtools/python/python-pycairo_1.10.0.bb
index 5b59b6c..70fe25c 100644
--- a/meta/recipes-devtools/python/python-pycairo_1.10.0.bb
+++ b/meta/recipes-devtools/python/python-pycairo_1.10.0.bb
@@ -20,6 +20,8 @@ S = "${WORKDIR}/py2cairo-${PV}"
inherit distutils pkgconfig
+BBCLASSEXTEND = "native"
+
do_configure() {
BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} ./waf configure
--prefix=${D}${prefix} --libdir=${D}${libdir}
}
--
1.8.3.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] bootchart2: create recipe for bootchart2
This recipe creates packages for the bootchart2 system-wide profiler daemon and related utilities. It fetches the Git revision immediately past the one corresponding to the 0.14.6 release of bootchart2. (0.14.6 had a systemd- related bug that was corrected right after it was tagged.) The recipe contains three packages: * bootchart2 - The daemon itself. * pybootchartgui - Python program to visualize and display the data collected by bootchart2 or compatible daemons such as the original bootchart. * bootchartd-stop-initscript - A SysV init script to stop data collection when booting completes. Depending on how you wish to use bootchart2, you may not end up having all three of those packages installed on your image. There is also a bootchart2-native variant, which is intended solely to provide a native version of the pybootchartgui utility. The non-cross-compiled version of the bootchart2 daemon has not been tested at all, don't use it. The recipe is extensively documented. Read the comments at the beginning of bootchart2_git.bb or else you'll have no idea how to use it. This recipe is based on a recipe from meta-WebOS. The WebOS people had some extra code (including patches against the bootchart2 code) to support the Upstart init system. However, since upstream Poky does not support Upstart, that stuff is being left behind. The WebOS people can write a bbappend to re- add it. Original recipe written by Wonhong Kwon of LG. Upstreamed as part of the solution to [YOCTO #5893]. Signed-off-by: Max Eliaser --- .../bootchart2/bootchart2/bootchartd_stop.sh | 18 +++ meta/recipes-devtools/bootchart2/bootchart2_git.bb | 148 + 2 files changed, 166 insertions(+) create mode 100644 meta/recipes-devtools/bootchart2/bootchart2/bootchartd_stop.sh create mode 100644 meta/recipes-devtools/bootchart2/bootchart2_git.bb diff --git a/meta/recipes-devtools/bootchart2/bootchart2/bootchartd_stop.sh b/meta/recipes-devtools/bootchart2/bootchart2/bootchartd_stop.sh new file mode 100644 index 000..21a7887 --- /dev/null +++ b/meta/recipes-devtools/bootchart2/bootchart2/bootchartd_stop.sh @@ -0,0 +1,18 @@ +#!/bin/sh +### BEGIN INIT INFO +# Provides: bootchartd_stop +# Required-Start:$remote_fs $all +# Required-Stop: +# Default-Start: 2 3 4 5 +# Default-Stop: +# Short-Description: Stop bootchartd collection +# Description: This script accompanies bootchartd from bootchart2. +#bootchartd should stop detect the end of the boot process +#automatically if a window manager is launched, but for +#command-line only operating systems, this script should be +#used instead. +### END INIT INFO + +/sbin/bootchartd stop + +: exit 0 diff --git a/meta/recipes-devtools/bootchart2/bootchart2_git.bb b/meta/recipes-devtools/bootchart2/bootchart2_git.bb new file mode 100644 index 000..e583852 --- /dev/null +++ b/meta/recipes-devtools/bootchart2/bootchart2_git.bb @@ -0,0 +1,148 @@ +# Copyright (c) 2013 LG Electronics, Inc. +# Copyright (C) 2014 Intel Corp. + +# This recipe creates packages for the bootchart2 system-wide profiler daemon +# and related utilities. Depending on the images you're building, additional +# configuration may be needed in order to use it. +# +# Packages: +# * bootchart2 - The daemon itself. +# * pybootchartgui - Python program to visualize and display the data +# collected by bootchart2 or compatible daemons such as the original +# bootchart. +# * bootchartd-stop-initscript - A SysV init script to stop data collection +# when booting completes (see below for details.) +# +# While bootchart2 is designed to stop collecting data roughly when the boot +# process completes, it is not exactly a stopwatch. It has a list of programs +# which are supposed signify that the boot process has completed (for example, +# openbox or gnome-shell,) but it waits a full 20 seconds after such a program +# is launched before stopping itself, to collect additional data. +# +# If you are using a window manager or GUI which isn't included in bootchart2's +# default configuration file, you should write bbappend file to amend +# bootchartd.conf and add it to EXIT_PROC. An example of this is shown in this +# recipe, where the Matchbox window manager (used by Sato) is added. +# +# If you want data collection to end at a certain point exactly, you should +# arrange for the following command to be run: +# bootchartd stop +# You might set this command to be launched by the desktop environment shipped +# on the image you're building after the other startup programs are complete. +# This will not incur the 20 second wait period and will cause bootchart2 to +# behave a bit more like a stopwatch. An example of this is shown in this +# recipe, specifically the bootchartd-stop-initscript package, which stops data +# collection as the last action whe
[OE-core] [PATCH 0/3] Upstream recipe for bootchart2 from WebOS (revised)
Hello list, This series adds a recipe for the bootchart2 daemon (a fork of the original bootchart.) It's based on a recipe from Meta-WebOS, but with extensive modifications. It is intended that bootchart2 will supersede the other bootchart daemons kicking around in oe-core/meta-oe. See bug 5893. [1] Regards, -Max Eliaser [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=5893 The following changes since commit 5452824960e8e77005a25ac11fd069d927523d3e: default-distrovars.inc: Remove unused variable 'LIMIT_BUILT_LOCALES' (2014-06-13 13:08:44 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib meliaser/bootchart2-attempt2 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=meliaser/bootchart2-attempt2 Max Eliaser (3): python: python-pycairo: add python-pycairo-native bootchart2: create recipe for bootchart2 ubootchart: delete ubootchart recipe meta-yocto/conf/distro/include/distro_alias.inc| 1 - meta-yocto/conf/distro/include/maintainers.inc | 1 - meta-yocto/conf/distro/include/recipe_color.inc| 1 - .../conf/distro/include/upstream_tracking.inc | 2 - .../bootchart2/bootchart2/bootchartd_stop.sh | 18 +++ meta/recipes-devtools/bootchart2/bootchart2_git.bb | 148 + .../python/python-pycairo_1.10.0.bb| 2 + .../ubootchart/files/sysvinit.patch| 14 -- .../ubootchart/files/ubootchart-stop | 3 - .../ubootchart/files/ubootchart.desktop| 6 - meta/recipes-devtools/ubootchart/ubootchart_svn.bb | 39 -- 11 files changed, 168 insertions(+), 67 deletions(-) create mode 100644 meta/recipes-devtools/bootchart2/bootchart2/bootchartd_stop.sh create mode 100644 meta/recipes-devtools/bootchart2/bootchart2_git.bb delete mode 100644 meta/recipes-devtools/ubootchart/files/sysvinit.patch delete mode 100644 meta/recipes-devtools/ubootchart/files/ubootchart-stop delete mode 100644 meta/recipes-devtools/ubootchart/files/ubootchart.desktop delete mode 100644 meta/recipes-devtools/ubootchart/ubootchart_svn.bb -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] Add initial fitImage support
On Thursday, August 07, 2014 at 10:10:28 PM, Saul Wold wrote: > On 08/07/2014 08:17 AM, Marek Vasut wrote: > > The fitImage is a successor of the U-Boot uImage format, which is > > considered legacy for years now. The fitImage allows packing multiple > > kernel images, DTBs and other artifacts into a single image, which can > > then be protected by SHA checksums and does even support signing the > > images for verified boot. > > > > This patchset is the first stab at adding the new image format into > > Yocto. > > > > Marek Vasut (5): > >Yocto: kernel: Rework do_uboot_mkimage > >Yocto: kernel: Pull out the linux.bin generation > >Yocto: kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE > >Yocto: kernel: Build DTBs early > >Yocto: kernel: Add basic fitImage support > > > > meta/classes/kernel.bbclass | 229 > > +--- > > meta/recipes-kernel/linux/linux-dtb.inc | 14 +- > > 2 files changed, 226 insertions(+), 17 deletions(-) > > Hi Marek, > > I am going to make a general request, can you please review the Commit > Guildlines Wiki for Openembedded: > > http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines > > We appreciate your patches, but the commit messages need to be formatted > correctly. The Yocto: tag is not needed and you could clearly include > which recipe, bbclass, file or subsystem (if across multiple files) so > in the above it would be kernel.bbclass: ... > > If you could please resubmit your changes with the correct commit > summary for this series and your other patches that would be greatly > appreciated. > > Myself and others may have further feedback on your patches. Ah, thanks! I'll give it a few days and will do V2 as per guidelines. Sorry for the mistake. Best regards, Marek Vasut -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] qemux86-64: support X11 when QEMU is emulating a different GPU than vmware
QEMU is capable of emulating four different VGA adapters: cirrus, std, vmware, and QXL. By adding the cirrus and fbdev X.Org drivers to the qemux86-64 image, the image can be made to launch an X server on when cirrus and std are chosen, in addition to just vmware. (The build of QEMU in OE-Core appears to have QXL disabled, meaning a driver for it is unnecessary.) The runqemu script now allows the choice of emulated VGA adapter to be specified manually, so it's important that qemux86-64 supports any configuration the user might choose without requiring the image to be rebuilt. In addition to adding the two extra drivers to the qemux86-64 image, a section specifying the driver to use is deleted from the image's xorg.conf, allowing the X server to automatically select the most appropriate driver. Testing shows that it does always pick the correct one. Signed-off-by: Max Eliaser --- meta/conf/machine/qemux86-64.conf| 2 ++ .../xorg-xserver/xserver-xf86-config/qemux86-64/xorg.conf| 5 - 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/meta/conf/machine/qemux86-64.conf b/meta/conf/machine/qemux86-64.conf index 642a2d9..837f9f4 100644 --- a/meta/conf/machine/qemux86-64.conf +++ b/meta/conf/machine/qemux86-64.conf @@ -20,6 +20,8 @@ XSERVER = "xserver-xorg \ xf86-input-vmmouse \ xf86-input-keyboard \ xf86-input-evdev \ + xf86-video-cirrus \ + xf86-video-fbdev \ xf86-video-vmware" MACHINE_FEATURES += "x86" diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemux86-64/xorg.conf b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemux86-64/xorg.conf index 10a6d9a..bbda9ea 100644 --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemux86-64/xorg.conf +++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemux86-64/xorg.conf @@ -30,11 +30,6 @@ Section "InputDevice" Option"USB" "on" EndSection -Section "Device" -Identifier"Graphics Controller" -Driver"vmware" -EndSection - Section "Monitor" Identifier"Generic Monitor" Option"DPMS" -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] qemux86: support X11 when QEMU is emulating a different GPU than vmware
QEMU is capable of emulating four different VGA adapters: cirrus, std, vmware, and QXL. By adding the cirrus and fbdev X.Org drivers to the qemux86 image, the image can be made to launch an X server on when cirrus and std are chosen, in addition to just vmware. (The build of QEMU in OE-Core appears to have QXL disabled, meaning a driver for it is unnecessary.) The runqemu script now allows the choice of emulated VGA adapter to be specified manually, so it's important that qemux86 supports any configuration the user might choose without requiring the image to be rebuilt. In addition to adding the two extra drivers to the qemux86 image, a section specifying the driver to use is deleted from the image's xorg.conf, allowing the X server to automatically select the most appropriate driver. Testing shows that it does always pick the correct one. Signed-off-by: Max Eliaser --- meta/conf/machine/qemux86.conf | 2 ++ .../xorg-xserver/xserver-xf86-config/qemux86/xorg.conf | 5 - 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf index ebc27db..3562276 100644 --- a/meta/conf/machine/qemux86.conf +++ b/meta/conf/machine/qemux86.conf @@ -19,6 +19,8 @@ XSERVER = "xserver-xorg \ xf86-input-vmmouse \ xf86-input-keyboard \ xf86-input-evdev \ + xf86-video-cirrus \ + xf86-video-fbdev \ xf86-video-vmware" MACHINE_FEATURES += "x86" diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemux86/xorg.conf b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemux86/xorg.conf index 10a6d9a..bbda9ea 100644 --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemux86/xorg.conf +++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemux86/xorg.conf @@ -30,11 +30,6 @@ Section "InputDevice" Option"USB" "on" EndSection -Section "Device" -Identifier"Graphics Controller" -Driver"vmware" -EndSection - Section "Monitor" Identifier"Generic Monitor" Option"DPMS" -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] xorg-drivers: xf86-video-cirrus: add a recipe for the Cirrus Logic X.Org driver
This driver allows X.Org to use the Cirrus Logic family of VGA adapters. Since
QEMU can emulate a Cirrus VGA adapter, this driver will be of use for images
that are expected to run under QEMU, if QEMU's other VGA adapters are
unavailable.
Signed-off-by: Max Eliaser
---
.../recipes-graphics/xorg-driver/xf86-video-cirrus_1.5.2.bb | 13 +
1 file changed, 13 insertions(+)
create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-cirrus_1.5.2.bb
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-cirrus_1.5.2.bb
b/meta/recipes-graphics/xorg-driver/xf86-video-cirrus_1.5.2.bb
new file mode 100644
index 000..f110522
--- /dev/null
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-cirrus_1.5.2.bb
@@ -0,0 +1,13 @@
+require xorg-driver-video.inc
+
+SUMMARY = "X.Org X server -- cirrus display driver"
+DESCRIPTION = "cirrus is an Xorg driver for Cirrus Logic VGA adapters. These \
+devices are not so common in the wild anymore, QEMU can emulate one, so the \
+driver is still useful."
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=6ddc7ca860dc5fd014e7f160ea699295"
+
+SRC_URI[md5sum] = "91fd6b677d62027cd3001debb587a6a6"
+SRC_URI[sha256sum] =
"3361e1a65d9b84c464752fd612bdf6087622c6dd204121715366a170e5c3ccd7"
+
+DEPENDS_${PN} = "virtual/libx11"
--
1.8.3.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] Add xf86-video-fbdev and xf86-video-cirrus to qemux86 and qemux86-64
Hello list, This series adds additional x.org drivers to the qemux86 and qemux86-64 machines. Now, instead of just including the "vmware" driver, GUI images for these machines will also include "cirrus" and "fbdev" drivers. Rationale: now that the runqemu script allows users to select which VGA adapter they want qemu to emulate, the qemu images should be able to start X servers with any adapter without requiring a rebuild of the image. Note that the drivers have only been added to the qemux86 and qemux86-64 machines. If someone is interested in trying them on the other qemu machines, they shouldn't be hard to add. xf86-video-cirrus did not previously have a recipe, so a new one is also added as part of this series. Regards, -Max Eliaser The following changes since commit 5452824960e8e77005a25ac11fd069d927523d3e: default-distrovars.inc: Remove unused variable 'LIMIT_BUILT_LOCALES' (2014-06-13 13:08:44 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib meliaser/qemu-x-drivers http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=meliaser/qemu-x-drivers Max Eliaser (3): xorg-drivers: xf86-video-cirrus: add a recipe for the Cirrus Logic X.Org driver qemux86: support X11 when QEMU is emulating a different GPU than vmware qemux86-64: support X11 when QEMU is emulating a different GPU than vmware meta/conf/machine/qemux86-64.conf | 2 ++ meta/conf/machine/qemux86.conf | 2 ++ .../recipes-graphics/xorg-driver/xf86-video-cirrus_1.5.2.bb | 13 + .../xorg-xserver/xserver-xf86-config/qemux86-64/xorg.conf | 5 - .../xorg-xserver/xserver-xf86-config/qemux86/xorg.conf | 5 - 5 files changed, 17 insertions(+), 10 deletions(-) create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-cirrus_1.5.2.bb -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] ubootchart: delete ubootchart recipe
The Ubootchart recipe had known issues. Ubootchart itself is no longer updated
upstream. Ubootchart is also now redundant with Bootchart2.
If people still want ubootchart around, it can be moved to meta-oe.
Ubootchart removed as part of the solution to [YOCTO #5893].
Signed-off-by: Max Eliaser
---
.../ubootchart/files/sysvinit.patch| 14
.../ubootchart/files/ubootchart-stop | 3 --
.../ubootchart/files/ubootchart.desktop| 6
meta/recipes-devtools/ubootchart/ubootchart_svn.bb | 39 --
4 files changed, 62 deletions(-)
delete mode 100644 meta/recipes-devtools/ubootchart/files/sysvinit.patch
delete mode 100644 meta/recipes-devtools/ubootchart/files/ubootchart-stop
delete mode 100644 meta/recipes-devtools/ubootchart/files/ubootchart.desktop
delete mode 100644 meta/recipes-devtools/ubootchart/ubootchart_svn.bb
diff --git a/meta/recipes-devtools/ubootchart/files/sysvinit.patch
b/meta/recipes-devtools/ubootchart/files/sysvinit.patch
deleted file mode 100644
index fc82ed8..000
--- a/meta/recipes-devtools/ubootchart/files/sysvinit.patch
+++ /dev/null
@@ -1,14 +0,0 @@
-Upstream-Status: Inappropriate [distribution]
-
-Index: ubootchart.conf
-===
ubootchart.conf(revision 9)
-+++ ubootchart.conf(working copy)
-@@ -1,6 +1,6 @@
-
- # If you want to chain on and run somthing other than /sbin/init...
--export init_prog=/sbin/init
-+export init_prog=/sbin/init.sysvinit
-
- # On startup ubootchart will mount a tmpfs filesystem at this
- # location and chdir here. This is only used for the logging of
diff --git a/meta/recipes-devtools/ubootchart/files/ubootchart-stop
b/meta/recipes-devtools/ubootchart/files/ubootchart-stop
deleted file mode 100644
index 3444069..000
--- a/meta/recipes-devtools/ubootchart/files/ubootchart-stop
+++ /dev/null
@@ -1,3 +0,0 @@
-#! /bin/sh
-
-kill -USR1 $(pidof ubootchartd_bin)
diff --git a/meta/recipes-devtools/ubootchart/files/ubootchart.desktop
b/meta/recipes-devtools/ubootchart/files/ubootchart.desktop
deleted file mode 100644
index 5552b3b..000
--- a/meta/recipes-devtools/ubootchart/files/ubootchart.desktop
+++ /dev/null
@@ -1,6 +0,0 @@
-[Desktop Entry]
-Encoding=UTF-8
-Exec=/sbin/ubootchart-stop
-Name=Stop Bootchart
-Type=Application
-Categories=Programming;
diff --git a/meta/recipes-devtools/ubootchart/ubootchart_svn.bb
b/meta/recipes-devtools/ubootchart/ubootchart_svn.bb
deleted file mode 100644
index b13755e..000
--- a/meta/recipes-devtools/ubootchart/ubootchart_svn.bb
+++ /dev/null
@@ -1,39 +0,0 @@
-SUMMARY = "A boot profiling tool"
-HOMEPAGE = "http://code.google.com/p/ubootchart/";
-LICENSE = "GPLv3"
-LIC_FILES_CHKSUM = "file://COPYING;md5=8f0e2cd40e05189ec81232da84bd6e1a"
-SRCREV = "12"
-PV = "0.0+r${SRCPV}"
-PR = "r6"
-
-#RRECOMMENDS_${PN} = "acct"
-
-SRC_URI = "svn://ubootchart.googlecode.com/svn/;protocol=http;module=trunk \
-file://sysvinit.patch;striplevel=0 \
-file://ubootchart-stop \
-file://ubootchart.desktop"
-
-S = "${WORKDIR}/trunk"
-
-inherit update-alternatives
-
-ALTERNATIVE_${PN} = "init"
-ALTERNATIVE_TARGET[init] = "${base_sbindir}/ubootchartd"
-ALTERNATIVE_LINK_NAME[init] = "${base_sbindir}/init"
-ALTERNATIVE_PRIORITY = "70"
-
-do_compile() {
-${CC} ${CFLAGS} ${LDFLAGS} ${LIBS} ${INCLUDES} ${S}/ubootchartd_bin.c
-o ubootchartd_bin
-}
-
-do_install() {
-install -m 0755 -d ${D}${base_sbindir} ${D}${sysconfdir}/ubootchart
${D}${datadir}/applications
-install -m 0755 ${S}/ubootchartd_bin ${D}${base_sbindir}
-install -m 0755 ${S}/ubootchartd ${D}${base_sbindir}
-install -m 0644 ${S}/ubootchart.conf ${D}${sysconfdir}/ubootchart
-install -m 0755 ${S}/start.sh ${D}${sysconfdir}/ubootchart
-install -m 0755 ${S}/finish.sh ${D}${sysconfdir}/ubootchart
-
-install -m 0755 ${WORKDIR}/ubootchart-stop ${D}${base_sbindir}
-install -m 0644 ${WORKDIR}/ubootchart.desktop
${D}${datadir}/applications
-}
--
1.8.3.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] bootchart2: create recipe for bootchart2
This recipe creates packages for the bootchart2 system-wide profiler daemon and related utilities. It fetches the Git revision immediately past the one corresponding to the 0.14.6 release of bootchart2. (0.14.6 had a systemd- related bug that was corrected right after it was tagged.) The recipe contains three packages: * bootchart2 - The daemon itself. * pybootchartgui - Python program to visualize and display the data collected by bootchart2 or compatible daemons such as the original bootchart. * bootchartd-stop-initscript - A SysV init script to stop data collection when booting completes. Depending on how you wish to use bootchart2, you may not end up having all three of those packages installed on your image. There is also a bootchart2-native variant, which is intended solely to provide a native version of the pybootchartgui utility. The non-cross-compiled version of the bootchart2 daemon has not been tested at all, don't use it. The recipe is extensively documented. Read the comments at the beginning of bootchart2_git.bb or else you'll have no idea how to use it. This recipe is based on a recipe from meta-WebOS. The WebOS people had some extra code (including patches against the bootchart2 code) to support the Upstart init system. However, since upstream Poky does not support Upstart, that stuff is being left behind. The WebOS people can write a bbappend to re- add it. Original recipe written by Wonhong Kwon of LG. Upstreamed as part of the solution to [YOCTO #5893]. Signed-off-by: Max Eliaser --- .../bootchart2/bootchart2/bootchartd_stop.sh | 18 +++ meta/recipes-devtools/bootchart2/bootchart2_git.bb | 148 + 2 files changed, 166 insertions(+) create mode 100644 meta/recipes-devtools/bootchart2/bootchart2/bootchartd_stop.sh create mode 100644 meta/recipes-devtools/bootchart2/bootchart2_git.bb diff --git a/meta/recipes-devtools/bootchart2/bootchart2/bootchartd_stop.sh b/meta/recipes-devtools/bootchart2/bootchart2/bootchartd_stop.sh new file mode 100644 index 000..21a7887 --- /dev/null +++ b/meta/recipes-devtools/bootchart2/bootchart2/bootchartd_stop.sh @@ -0,0 +1,18 @@ +#!/bin/sh +### BEGIN INIT INFO +# Provides: bootchartd_stop +# Required-Start:$remote_fs $all +# Required-Stop: +# Default-Start: 2 3 4 5 +# Default-Stop: +# Short-Description: Stop bootchartd collection +# Description: This script accompanies bootchartd from bootchart2. +#bootchartd should stop detect the end of the boot process +#automatically if a window manager is launched, but for +#command-line only operating systems, this script should be +#used instead. +### END INIT INFO + +/sbin/bootchartd stop + +: exit 0 diff --git a/meta/recipes-devtools/bootchart2/bootchart2_git.bb b/meta/recipes-devtools/bootchart2/bootchart2_git.bb new file mode 100644 index 000..e583852 --- /dev/null +++ b/meta/recipes-devtools/bootchart2/bootchart2_git.bb @@ -0,0 +1,148 @@ +# Copyright (c) 2013 LG Electronics, Inc. +# Copyright (C) 2014 Intel Corp. + +# This recipe creates packages for the bootchart2 system-wide profiler daemon +# and related utilities. Depending on the images you're building, additional +# configuration may be needed in order to use it. +# +# Packages: +# * bootchart2 - The daemon itself. +# * pybootchartgui - Python program to visualize and display the data +# collected by bootchart2 or compatible daemons such as the original +# bootchart. +# * bootchartd-stop-initscript - A SysV init script to stop data collection +# when booting completes (see below for details.) +# +# While bootchart2 is designed to stop collecting data roughly when the boot +# process completes, it is not exactly a stopwatch. It has a list of programs +# which are supposed signify that the boot process has completed (for example, +# openbox or gnome-shell,) but it waits a full 20 seconds after such a program +# is launched before stopping itself, to collect additional data. +# +# If you are using a window manager or GUI which isn't included in bootchart2's +# default configuration file, you should write bbappend file to amend +# bootchartd.conf and add it to EXIT_PROC. An example of this is shown in this +# recipe, where the Matchbox window manager (used by Sato) is added. +# +# If you want data collection to end at a certain point exactly, you should +# arrange for the following command to be run: +# bootchartd stop +# You might set this command to be launched by the desktop environment shipped +# on the image you're building after the other startup programs are complete. +# This will not incur the 20 second wait period and will cause bootchart2 to +# behave a bit more like a stopwatch. An example of this is shown in this +# recipe, specifically the bootchartd-stop-initscript package, which stops data +# collection as the last action whe
[OE-core] [PATCH 0/2] Upstream recipe for bootchart2 from WebOS (revised again)
Hello list, This series adds a recipe for the bootchart2 daemon (a fork of the original bootchart.) It's based on a recipe from Meta-WebOS, but with extensive modifications. It is intended that bootchart2 will supersede the other bootchart daemons kicking around in oe-core/meta-oe. See bug 5893. [1] (Resubmitted this series yet again because I'd mistakenly included Yocto- specific changes in addition to oe-core ones.) Regards, -Max Eliaser [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=5893 The following changes since commit 86afd7eb7c679eb065706137f28f44248f3fbc5a: ghostscript: Remove bogus gsfonts reference from DESCRIPTION (2014-08-06 11:14:40 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib meliaser/bootchart2-attempt3 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=meliaser/bootchart2-attempt3 Max Eliaser (2): bootchart2: create recipe for bootchart2 ubootchart: delete ubootchart recipe .../bootchart2/bootchart2/bootchartd_stop.sh | 18 +++ meta/recipes-devtools/bootchart2/bootchart2_git.bb | 148 + .../ubootchart/files/sysvinit.patch| 14 -- .../ubootchart/files/ubootchart-stop | 3 - .../ubootchart/files/ubootchart.desktop| 6 - meta/recipes-devtools/ubootchart/ubootchart_svn.bb | 39 -- 6 files changed, 166 insertions(+), 62 deletions(-) create mode 100644 meta/recipes-devtools/bootchart2/bootchart2/bootchartd_stop.sh create mode 100644 meta/recipes-devtools/bootchart2/bootchart2_git.bb delete mode 100644 meta/recipes-devtools/ubootchart/files/sysvinit.patch delete mode 100644 meta/recipes-devtools/ubootchart/files/ubootchart-stop delete mode 100644 meta/recipes-devtools/ubootchart/files/ubootchart.desktop delete mode 100644 meta/recipes-devtools/ubootchart/ubootchart_svn.bb -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Upstream recipe for bootchart2 from WebOS (revised again)
On Thu, Aug 07, 2014 at 01:59:20PM -0700, Max Eliaser wrote: > Hello list, > > This series adds a recipe for the bootchart2 daemon (a fork of the original > bootchart.) It's based on a recipe from Meta-WebOS, but with extensive > modifications. > > It is intended that bootchart2 will supersede the other bootchart daemons > kicking around in oe-core/meta-oe. See bug 5893. [1] > > (Resubmitted this series yet again because I'd mistakenly included Yocto- > specific changes in addition to oe-core ones.) This one is missing pycairo change, is it intentional? > > Regards, > -Max Eliaser > > [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=5893 > The following changes since commit 86afd7eb7c679eb065706137f28f44248f3fbc5a: > > ghostscript: Remove bogus gsfonts reference from DESCRIPTION (2014-08-06 > 11:14:40 +0100) > > are available in the git repository at: > > git://git.yoctoproject.org/poky-contrib meliaser/bootchart2-attempt3 > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=meliaser/bootchart2-attempt3 > > Max Eliaser (2): > bootchart2: create recipe for bootchart2 > ubootchart: delete ubootchart recipe > > .../bootchart2/bootchart2/bootchartd_stop.sh | 18 +++ > meta/recipes-devtools/bootchart2/bootchart2_git.bb | 148 > + > .../ubootchart/files/sysvinit.patch| 14 -- > .../ubootchart/files/ubootchart-stop | 3 - > .../ubootchart/files/ubootchart.desktop| 6 - > meta/recipes-devtools/ubootchart/ubootchart_svn.bb | 39 -- > 6 files changed, 166 insertions(+), 62 deletions(-) > create mode 100644 > meta/recipes-devtools/bootchart2/bootchart2/bootchartd_stop.sh > create mode 100644 meta/recipes-devtools/bootchart2/bootchart2_git.bb > delete mode 100644 meta/recipes-devtools/ubootchart/files/sysvinit.patch > delete mode 100644 meta/recipes-devtools/ubootchart/files/ubootchart-stop > delete mode 100644 meta/recipes-devtools/ubootchart/files/ubootchart.desktop > delete mode 100644 meta/recipes-devtools/ubootchart/ubootchart_svn.bb > > -- > 1.8.3.2 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] How to force patch application
Yes, what I said previously: 1) disable current patch: add ";patch=0" to the end of the patch line in SRC_URI 2a) add your patch to SRC_URI (if different than patch above) 2b) make your own do_patch() to apply the patch 2c) try this example for a way to supplement do_patch with your own function: meta-openembedded/meta-networking/recipes-support/netcat/ netcat-openbsd_1.105.bb 3) test it Steve On Thu, Aug 7, 2014 at 7:51 AM, Giuseppe Condorelli < giuseppe.condore...@gmail.com> wrote: > Hi Steve, > > thanks for the reply. > > The problem is that I need to force a patch application (like patch > --force option) at my own risk. > Do you see any solution? > Giuseppe > > > 2014-08-07 16:43 GMT+02:00 Stephen Arnold : > > Not sure if there's an easy way with quilt (check the quilt options) but a >> relatively easy way would be to use your own patch routine (essentially >> anything you want). One thing you could do is disable the normal patch >> application (add ";patch=0" to the end of the patch line in SRC_URI) and >> then use your own do_patch to force it (if that's really what you want to >> do). I guess I would ask "why?" and if it were me I'd just reroll the >> patch and fix it. But I don't know what the real problem is, so... >> >> Steve >> >> >> >> On Thu, Aug 7, 2014 at 6:14 AM, Giuseppe Condorelli < >> giuseppe.condore...@gmail.com> wrote: >> >>> Hi All, >>> >>> please can I know if is it possible, using the do_patch routine, >>> to force the application of a given patch? >>> I mean, like the patch --force command. >>> >>> Please let me know, I tried w/o good result. >>> >>> Best Regards, >>> Giuseppe >>> >>> -- >>> ___ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core >>> >>> >> >> -- >> ___ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> >> > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Upstream recipe for bootchart2 from WebOS (revised again)
The first time I submitted this patch series a few weeks ago, that part got accepted without me noticing, so it's already in oe-core. Saul pointed this out to me, so I rebased to get that patch out of the series. -Max From: Martin Jansa [martin.ja...@gmail.com] Sent: Thursday, August 07, 2014 2:38 PM To: Eliaser, MaX Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH 0/2] Upstream recipe for bootchart2 from WebOS (revised again) This one is missing pycairo change, is it intentional? -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] gmp: uprev it to 6.0.0
On 08/06/2014 04:22 PM, ChenQi wrote: There's a failure on autobuilder. Could you please check whether it's related to this patch. ERROR: Unable to install packages. Command '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/sysroots/x86_64-linux/usr/bin/smart --data-dir=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/qemux86-poky-linux/core-image-full-cmdline/1.0-r0/rootfs/var/lib/smart install -y packagegroup-core-full-cmdline@all psplash@i586 run-postinsts@all packagegroup-core-ssh-openssh@all packagegroup-core-boot@qemux86 locale-base-en-us@i586 locale-base-en-gb@i586' returned 1: Loading cache... Updating cache... [100%] Computing transaction...error: Can't install packagegroup-core-full-cmdline-utils-1.0-r6@all: no package provides libgmp3 https://autobuilder.yoctoproject.org/main/builders/nightly-non-gpl3/builds/197/steps/BuildImages/logs/stdio //Chen Qi I can not reproduce it, maybe related old cache. -Roy -- Best Reagrds, Roy | RongQing Li -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain
Since 'yocto' is a project like freedesktop.org your commit message doesn't
make sense, it should be something like:
meta-toolchain-qt: Install full set of python modules
Op 7 aug. 2014, om 21:10 heeft Marek Vasut het volgende
geschreven:
> The Qt SDK toolchain pulls in python via
> packagegroup-cross-canadian-${MACHINE}
> and ships it. But the python is missing many modules and is rather incomplete.
>
> The environment-setup-* script configures the PATH variable to point into
> it's own sysroot first, it means the python from the SDK is used as well
> when the environment is configured. It actually does make sense to use the
> python from the SDK, since the SDK should provide the tools needed to build
> additional software.
>
> The problem is, the python in the SDK image is stripped to a bare minimum
> of modules, which prevents some software from being built with the SDK as
> is. Add the same python modules as the buildtools-tarball.bb adds to make
> the python shipped with the SDK complete.
>
> Signed-off-by: Marek Vasut
> ---
> meta/recipes-qt/meta/meta-toolchain-qt.inc | 32 +-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> NOTE: This lets me build U-Boot git HEAD , which now has Kconfig in it
> and that depends on the "subprocess" module. But instead of adding
> just one module, I want to fix this properly and future-proof this.
>
> diff --git a/meta/recipes-qt/meta/meta-toolchain-qt.inc
> b/meta/recipes-qt/meta/meta-toolchain-qt.inc
> index 6b162bd..99d5e64 100644
> --- a/meta/recipes-qt/meta/meta-toolchain-qt.inc
> +++ b/meta/recipes-qt/meta/meta-toolchain-qt.inc
> @@ -1,4 +1,34 @@
> -TOOLCHAIN_HOST_TASK = "nativesdk-packagegroup-${QTNAME}-toolchain-host
> packagegroup-cross-canadian-${MACHINE}"
> +TOOLCHAIN_HOST_TASK = " \
> + nativesdk-packagegroup-${QTNAME}-toolchain-host \
> + packagegroup-cross-canadian-${MACHINE} \
> + nativesdk-python-core \
> + nativesdk-python-textutils \
> + nativesdk-python-sqlite3 \
> + nativesdk-python-pickle \
> + nativesdk-python-logging \
> + nativesdk-python-elementtree \
> + nativesdk-python-curses \
> + nativesdk-python-compile \
> + nativesdk-python-compiler \
> + nativesdk-python-fcntl \
> + nativesdk-python-shell \
> + nativesdk-python-misc \
> + nativesdk-python-multiprocessing \
> + nativesdk-python-subprocess \
> + nativesdk-python-xmlrpc \
> + nativesdk-python-netclient \
> + nativesdk-python-netserver \
> + nativesdk-python-distutils \
> + nativesdk-python-unixadmin \
> + nativesdk-python-compression \
> + nativesdk-python-json \
> + nativesdk-python-unittest \
> + nativesdk-python-mmap \
> + nativesdk-python-difflib \
> + nativesdk-python-pprint \
> + nativesdk-python-git \
> + nativesdk-python-pkgutil \
> + "
> TOOLCHAIN_TARGET_TASK = "packagegroup-${QTNAME}-toolchain-target"
> TOOLCHAIN_OUTPUTNAME = "${SDK_NAME}-toolchain-${QTNAME}-${DISTRO_VERSION}"
>
> --
> 2.0.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kexec-tools: reinstate 'kexec-tools' package
The vmcore commit emptied out ${PN} leading to things like:
Collected errors:
* opkg_install_cmd: Cannot install package kexec-tools.
Let's do the right thing and make ${PN} an empty meta-package that drags in all
tools like people expect it to do.
Signed-off-by: Koen Kooi
---
meta/recipes-kernel/kexec/kexec-tools_2.0.7.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-kernel/kexec/kexec-tools_2.0.7.bb
b/meta/recipes-kernel/kexec/kexec-tools_2.0.7.bb
index 1bb7e9f..f0ece0d 100644
--- a/meta/recipes-kernel/kexec/kexec-tools_2.0.7.bb
+++ b/meta/recipes-kernel/kexec/kexec-tools_2.0.7.bb
@@ -9,6 +9,9 @@ SRC_URI[sha256sum] =
"dde5c38be39882c6c91f0129647349c4e1943b077d3020af1970b481ee
PACKAGES =+ "kexec kdump vmcore-dmesg"
+ALLOW_EMPTY_${PN} = "1"
+RRECOMMENDS_${PN} = "kexec kdump vmcore-dmesg"
+
FILES_kexec = "${sbindir}/kexec"
FILES_kdump = "${sbindir}/kdump"
FILES_vmcore-dmesg = "${sbindir}/vmcore-dmesg"
--
1.9.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kexec-tools: Create separate package for vmcore-dmesg
Op 5 aug. 2014, om 02:16 heeft Ricardo Neri
het volgende geschreven:
> The kexec-tools recipe already specifies separate packages for kexec and
> kdump. Thus, it follows that a separate package can also be used to install
> vmcore-dmesg granularly.
This breaks the upgrade patch sinds ${PN} is now an empty package. Please
inspect buildhistory after changes to packaging. I'm sending a patch to fix
this and actually improve the situation a bit.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
