[OE-core] [PATCH 0/1 v2] shadow: backport a patch to make newgrp work
From: "Roy.Li" Diff with v1: fix a typOS The following changes since commit fd9e591f266e1a6c183e77f24e50d31e0d52bdd5: cronie: fix out of tree build (2013-08-19 11:24:51 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib roy/mewgrp1 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=roy/mewgrp1 Roy.Li (1): shadow: backport a patch to make newgrp work .../shadow/files/fix-etc-gshadow-reading.patch | 36 meta/recipes-extended/shadow/shadow_4.1.4.3.bb |1 + 2 files changed, 37 insertions(+) create mode 100644 meta/recipes-extended/shadow/files/fix-etc-gshadow-reading.patch -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] shadow: backport a patch to make newgrp work
From: "Roy.Li"
Signed-off-by: Roy.Li
---
.../shadow/files/fix-etc-gshadow-reading.patch | 36
meta/recipes-extended/shadow/shadow_4.1.4.3.bb |1 +
2 files changed, 37 insertions(+)
create mode 100644
meta/recipes-extended/shadow/files/fix-etc-gshadow-reading.patch
diff --git a/meta/recipes-extended/shadow/files/fix-etc-gshadow-reading.patch
b/meta/recipes-extended/shadow/files/fix-etc-gshadow-reading.patch
new file mode 100644
index 000..80ebdc2
--- /dev/null
+++ b/meta/recipes-extended/shadow/files/fix-etc-gshadow-reading.patch
@@ -0,0 +1,36 @@
+shadow: Fix parsing of gshadow entries
+
+Upstream-Status: Backport
[http://anonscm.debian.org/viewvc/pkg-shadow?view=revision&revision=3096]
+
+newgrp command does not function properly.
+Even with the valid password, it outputs: "'Invalid password'"
+
+Signed-off-by: Roy.Li
+
+2010-02-14 Michael Bunk
+
+ * NEWS, lib/gshadow.c: Fix parsing of gshadow entries.
+
+diff -urpN a/lib/gshadow.c b/lib/gshadow.c
+--- a/lib/gshadow.c2013-07-11 10:18:15.745450428 +0800
b/lib/gshadow.c2013-07-11 10:17:30.465450280 +0800
+@@ -222,6 +222,7 @@ void endsgent (void)
+ if (NULL == buf) {
+ return NULL;
+ }
++ buflen = BUFSIZ;
+ }
+
+ if (NULL == fp) {
+@@ -229,9 +230,9 @@ void endsgent (void)
+ }
+
+ #ifdefUSE_NIS
+- while (fgetsx (buf, (int) sizeof buf, fp) == buf)
++ while (fgetsx (buf, (int) buflen, fp) == buf)
+ #else
+- if (fgetsx (buf, (int) sizeof buf, fp) == buf)
++ if (fgetsx (buf, (int) buflen, fp) == buf)
+ #endif
+ {
+ while ( ((cp = strrchr (buf, '\n')) == NULL)
diff --git a/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
b/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
index af67339..31cef20 100644
--- a/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
+++ b/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
@@ -24,6 +24,7 @@ SRC_URI =
"http://pkg-shadow.alioth.debian.org/releases/${BPN}-${PV}.tar.bz2 \
file://shadow-update-pam-conf.patch \
file://shadow_fix_for_automake-1.12.patch \
file://slackware_fix_for_glib-2.17_crypt.patch \
+ file://fix-etc-gshadow-reading.patch \
"
SRC_URI[md5sum] = "b8608d8294ac88974f27b20f991c0e79"
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] Automake-1.13 fixes
The following changes since commit fd9e591f266e1a6c183e77f24e50d31e0d52bdd5: cronie: fix out of tree build (2013-08-19 11:24:51 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib cazfi/am13 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=cazfi/am13 Marko Lindqvist (2): texinfo: correct dont-depend-on-help2man.patch gtk-engines: fix build with automake-1.13 .../texinfo-5.1/dont-depend-on-help2man.patch | 43 +--- .../gtk-engines-2.20.2/substitute-tests.patch | 37 + .../gtk-engines/gtk-engines_2.20.2.bb |5 +-- 3 files changed, 77 insertions(+), 8 deletions(-) create mode 100644 meta/recipes-gnome/gtk-engines/gtk-engines-2.20.2/substitute-tests.patch -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/6] sysvinit: add init.d/bootlogd status command for LSB compliance
On 8/20/2013 2:39 PM, Phil Blundell wrote: On Tue, 2013-08-20 at 11:25 +0800, jackie.hu...@windriver.com wrote: @@ -37,6 +40,19 @@ case "$0" in ;; esac +# default /var/log/boot is not an option since /var/log becomes +# /var/volatile/log +logfile=/var/local/bootlogd.log + +# +# Create initial log files +# +if [ ! -f "$logfile" ] && touch "$logfile" >/dev/null 2>&1; then + echo "(Nothing has been logged yet.)" >| "$logfile" + chown root:adm "$logfile" + chmod 640 "$logfile" +fi + case "$ACTION" in start) echo -n "Starting $DESC: " @@ -44,9 +60,9 @@ case "$ACTION" in then umask 027 start-stop-daemon --start --quiet \ - --exec $DAEMON -- -r + --exec $DAEMON -- -r -l $logfile else - $DAEMON -r + $DAEMON -r -l $logfile fi echo "$NAME." ;; It's not totally obvious that the changes are related to the "status" command. If you're creating new logfiles that didn't exist previously then I think the commit message ought to explain why. Sorry, my mistake to involve some other patch when I got the patch from our layer, I will remake the patches. Thanks, Jackie p. -- Jackie Huang WIND RIVER | China Development Center MSN:jackiel...@hotmail.com Tel: +86 8477 8594 Mobile: +86 138 1027 4745 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 00/25] Review and ACK
On 19 August 2013 17:19, Saul Wold wrote: > Jackie Huang (1): > texinfo: handle correctly @enumerate specification greater than 10 The patch is missing a signed-off, but then again the patch header does have Jackie's email in. > Joe Slater (2): > coreutils: add PACKAGECONFIG info for acl support > coreutils: allow for acl support I don't like the comment describing the packageconfig format, but that can be removed later. > Khem Raj (3): > qemuppc: Change default tune to 74xx > tune-ppc7400.inc: Add tune file The ordering of these two in the branch is backwards, which could hurt someone doing bisects. Richard, can you fix the ordering when merging? Apart from that, Acked-By: Ross Burton . Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] linux-dtb: Use kernel build system to generate the dtb files
I cannot get this to work, do_install fails because it cannot find the
generated ".dtb" file.
See further in the message:
On 08/13/2013 03:52 PM, Otavio Salvador wrote:
As the Linux kernel, unconditionally, builds the dtc application and
it is the compatible version with the DeviceTree files shipped within
the kernel it is better to use it and the kernel build system to
generate the dtb files.
Some DeviceTree files rely on CPP and kernel headers to be able to
generate the dtb binary contents and it is harder to replicate it
outside of Linux kernel build system so we /use/ it.
To comply with these assumptions we need to use the dtb file when
calling 'make' instead of pointing to the DeviceTree source file; the
code has been made backward compatible but it is advised to move to
the new definition to avoid warnings as:
,[ Original definition ]
| KERNEL_DEVICETREE = "${S}/arch/arm/boot/dts/imx6q-sabresd.dts"
`
Becomes:
,[ New definition ]
| KERNEL_DEVICETREE = "imx6q-sabresd.dtb"
`
Signed-off-by: Otavio Salvador
---
Changes in v2:
- Drop debug warning left by mistake
- Improve bbwarn message (Bruce Ashfield)
- Improve commit log (Bruce Ascfield)
meta/recipes-kernel/linux/linux-dtb.inc | 58 +++--
1 file changed, 26 insertions(+), 32 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index 41dd599..cebc76a 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -1,44 +1,38 @@
# Support for device tree generation
FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/devicetree*"
-KERNEL_DEVICETREE_FLAGS ?= "-R 8 -p 0x3000"
python __anonymous () {
-devicetree = d.getVar("KERNEL_DEVICETREE", True) or ''
-if devicetree:
-depends = d.getVar("DEPENDS", True)
-d.setVar("DEPENDS", "%s dtc-native" % depends)
-packages = d.getVar("PACKAGES", True)
-d.setVar("PACKAGES", "%s kernel-devicetree" % packages)
+d.appendVar("PACKAGES", " kernel-devicetree")
}
do_install_append() {
if test -n "${KERNEL_DEVICETREE}"; then
- for DTS_FILE in ${KERNEL_DEVICETREE}; do
- if [ ! -f ${DTS_FILE} ]; then
- echo "Warning: ${DTS_FILE} is not available!"
- continue
+ 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
- DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F "."
'{print $1}'`
- DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
"s/${MACHINE}/${DTS_BASE_NAME}/g"`
- DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} | sed
"s/${MACHINE}/${DTS_BASE_NAME}/g"`
- dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o
${DTS_BASE_NAME} ${DTS_FILE}
- install -m 0644 ${DTS_BASE_NAME}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
+ 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"`
+ oe_runmake ${DTB}
+ install -m 0644 ${B}/arch/${ARCH}/boot/${DTB}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
This fails now, because ${B}/arch/${ARCH}/boot/${DTB} cannot be found.
The dtb file is in the "dts" subdirectory, so should this line read:
+ install -m 0644 ${B}/arch/${ARCH}/boot/dts/${DTB}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
I wonder why this works on your system?
done
fi
}
do_deploy_append() {
if test -n "${KERNEL_DEVICETREE}"; then
- for DTS_FILE in ${KERNEL_DEVICETREE}; do
- if [ ! -f ${DTS_FILE} ]; then
- echo "Warning: ${DTS_FILE} is not available!"
- continue
+ 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
- DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F "."
'{print $1}'`
- DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
"s/${MACHINE}/${DTS_BASE_NAME}/g"`
- DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} | se
[OE-core] [PATCH] linux-dtb: Fix compilation failure in install and deploy phases
Baking a kernel failed on the devicetree creation. This was caused
by the install and deploy scripts referring to the wrong directory
for the dtb files.
Signed-off-by: Mike Looijmans
---
meta/recipes-kernel/linux/linux-dtb.inc |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index cebc76a..65e61eb 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -16,7 +16,7 @@ do_install_append() {
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"`
oe_runmake ${DTB}
- install -m 0644 ${B}/arch/${ARCH}/boot/${DTB}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
+ install -m 0644 ${B}/arch/${ARCH}/boot/dts/${DTB}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
done
fi
}
@@ -32,7 +32,7 @@ do_deploy_append() {
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"`
install -d ${DEPLOYDIR}
- install -m 0644 ${B}/arch/${ARCH}/boot/${DTB}
${DEPLOYDIR}/${DTB_NAME}.dtb
+ install -m 0644 ${B}/arch/${ARCH}/boot/dts/${DTB}
${DEPLOYDIR}/${DTB_NAME}.dtb
cd ${DEPLOYDIR}
ln -sf ${DTB_NAME}.dtb ${DTB_SYMLINK_NAME}.dtb
cd -
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mesa: enable additional drivers for gallium-llvm x86/x86-64
The additional Gallium drivers are needed for open source ATI Radeon
and NVIDIA graphics drivers.
The radeonsi and r600 drivers require LLVM 3.3 built with r600
PACKAGECONFIG so they must be explicitly enabled by adding r600 to the
mesa PACKAGECONFIG.
Signed-off-by: Jonathan Liu
---
meta/recipes-graphics/mesa/mesa.inc | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 447e186..e985d67 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -50,6 +50,10 @@ PACKAGECONFIG[egl] = "--enable-egl
--with-egl-platforms=${EGL_PLATFORMS}, --disa
PACKAGECONFIG[openvg] = "--enable-openvg, --disable-openvg"
GALLIUMDRIVERS = "swrast"
+GALLIUMDRIVERS_LLVM33 = "${@base_contains('PACKAGECONFIG', 'r600',
'radeonsi,r600', '', d)}"
+GALLIUMDRIVERS_LLVM =
"r300,svga,nouveau${@base_version_less_or_equal('MESA_LLVM_RELEASE', '3.2', '',
',${GALLIUMDRIVERS_LLVM33}', d)}"
+GALLIUMDRIVERS_append_x86 = "${@base_contains('PACKAGECONFIG', 'gallium-llvm',
',${GALLIUMDRIVERS_LLVM}', '', d)}"
+GALLIUMDRIVERS_append_x86-64 = "${@base_contains('PACKAGECONFIG',
'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
# keep --with-gallium-drivers separate, because when only one of gallium
versions is enabled, other 2 were adding --without-gallium-drivers
PACKAGECONFIG[gallium] = "--with-gallium-drivers=${GALLIUMDRIVERS},
--without-gallium-drivers"
PACKAGECONFIG[gallium-egl] = "--enable-gallium-egl, --disable-gallium-egl"
--
1.8.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] sudo: upgrade to 1.8.7
Hi, There were some minor changes: diff sudo-1.8.6p8/doc/LICENSE sudo-1.8.7/doc/LICENSE 3c3Copyright (c) 1994-1996, 1998-2013 diff sudo-1.8.6p8/plugins/sudoers/redblack.c sudo-1.8.7/plugins/sudoers/redblack.c 2c2 < * Copyright (c) 2004-2005, 2007, 2009-2011 --- > * Copyright (c) 2004-2005, 2007, 2009-2013 For the next upgrades, I will mention them in the commit message. Thanks, Cristiana From: Khem Raj [mailto:raj.k...@gmail.com] Sent: Friday, August 16, 2013 6:57 PM To: Voicu, Cristiana Cc: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 2/2] sudo: upgrade to 1.8.7 On Fri, Aug 16, 2013 at 1:30 AM, Cristiana Voicu mailto:cristiana.vo...@intel.com>> wrote: Also, the license had some modifications in two files. would be nice if you mentioned what the changed were. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mesa: enable additional drivers for gallium-llvm x86/x86-64
On Tue, Aug 20, 2013 at 08:10:41PM +1000, Jonathan Liu wrote:
> The additional Gallium drivers are needed for open source ATI Radeon
> and NVIDIA graphics drivers.
>
> The radeonsi and r600 drivers require LLVM 3.3 built with r600
> PACKAGECONFIG so they must be explicitly enabled by adding r600 to the
> mesa PACKAGECONFIG.
BTW: I just got interesting question about egl_gallium:
libEGL warning: Could not open driver /usr/lib/egl/egl_gallium.so
(libLLVM-3.3.so: cannot open shared object file: No such file or
directory)
Could not initialize egl display
EGL error
Aborted
root@qemux86:~# ls -alh /usr/lib/llvm3.3/
drwxr-xr-x2 root root1.0K Aug 20 02:47 .
drwxr-xr-x 35 root root 10.0K Aug 20 02:47 ..
-rwxr-xr-x1 root root 15.8M Aug 19 14:02 libLLVM-3.3.so
-rwxr-xr-x1 root root 78.2K Aug 19 14:02 libLTO.so
-rwxr-xr-x1 root root 10.1K Aug 19 14:02 libprofile_rt.so
I don't know yet why it worked in my tests when I was updating mesa and
llvm, but it's true that we need to make sure that mesa finds
libLLVM-3.3.so in versioned subdirectory in runtime.
>
> Signed-off-by: Jonathan Liu
> ---
> meta/recipes-graphics/mesa/mesa.inc | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> b/meta/recipes-graphics/mesa/mesa.inc
> index 447e186..e985d67 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -50,6 +50,10 @@ PACKAGECONFIG[egl] = "--enable-egl
> --with-egl-platforms=${EGL_PLATFORMS}, --disa
> PACKAGECONFIG[openvg] = "--enable-openvg, --disable-openvg"
>
> GALLIUMDRIVERS = "swrast"
> +GALLIUMDRIVERS_LLVM33 = "${@base_contains('PACKAGECONFIG', 'r600',
> 'radeonsi,r600', '', d)}"
> +GALLIUMDRIVERS_LLVM =
> "r300,svga,nouveau${@base_version_less_or_equal('MESA_LLVM_RELEASE', '3.2',
> '', ',${GALLIUMDRIVERS_LLVM33}', d)}"
> +GALLIUMDRIVERS_append_x86 = "${@base_contains('PACKAGECONFIG',
> 'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
> +GALLIUMDRIVERS_append_x86-64 = "${@base_contains('PACKAGECONFIG',
> 'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
> # keep --with-gallium-drivers separate, because when only one of gallium
> versions is enabled, other 2 were adding --without-gallium-drivers
> PACKAGECONFIG[gallium] = "--with-gallium-drivers=${GALLIUMDRIVERS},
> --without-gallium-drivers"
> PACKAGECONFIG[gallium-egl] = "--enable-gallium-egl, --disable-gallium-egl"
> --
> 1.8.3.4
>
> ___
> 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] [PATCH] mesa: enable additional drivers for gallium-llvm x86/x86-64
On 20/08/2013 8:24 PM, Martin Jansa wrote:
On Tue, Aug 20, 2013 at 08:10:41PM +1000, Jonathan Liu wrote:
The additional Gallium drivers are needed for open source ATI Radeon
and NVIDIA graphics drivers.
The radeonsi and r600 drivers require LLVM 3.3 built with r600
PACKAGECONFIG so they must be explicitly enabled by adding r600 to the
mesa PACKAGECONFIG.
BTW: I just got interesting question about egl_gallium:
libEGL warning: Could not open driver /usr/lib/egl/egl_gallium.so
(libLLVM-3.3.so: cannot open shared object file: No such file or
directory)
Could not initialize egl display
EGL error
Aborted
root@qemux86:~# ls -alh /usr/lib/llvm3.3/
drwxr-xr-x2 root root1.0K Aug 20 02:47 .
drwxr-xr-x 35 root root 10.0K Aug 20 02:47 ..
-rwxr-xr-x1 root root 15.8M Aug 19 14:02 libLLVM-3.3.so
-rwxr-xr-x1 root root 78.2K Aug 19 14:02 libLTO.so
-rwxr-xr-x1 root root 10.1K Aug 19 14:02 libprofile_rt.so
I don't know yet why it worked in my tests when I was updating mesa and
llvm, but it's true that we need to make sure that mesa finds
libLLVM-3.3.so in versioned subdirectory in runtime.
LLVM has been working fine for me with llvmpipe (Intel GMA 3600 -
PowerVR-based), radeon (ATI Radeon HD5450) and nouveau (NVIDIA ION
GeForce 9400M) drivers.
There is a symbolic link in /usr/lib:
$ cd /usr/lib
$ ls -l libLLVM-3.3.so
lrwxrwxrwx 1 root root 22 Aug 19 21:03 libLLVM-3.3.so ->
llvm3.3/libLLVM-3.3.so
I intend to submit xf86-video-ati and xf86-video-nouveau to
meta-openembedded later this week. I tested this change using those
recipes, linux-firmware (needed for ATI 3D acceleration) and the
following kernel options:
CONFIG_DRM_RADEON=m
CONFIG_DRM_RADEON_KMS=y
CONFIG_DRM_NOUVEAU=y
Regards,
Jonathan
Signed-off-by: Jonathan Liu
---
meta/recipes-graphics/mesa/mesa.inc | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 447e186..e985d67 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -50,6 +50,10 @@ PACKAGECONFIG[egl] = "--enable-egl
--with-egl-platforms=${EGL_PLATFORMS}, --disa
PACKAGECONFIG[openvg] = "--enable-openvg, --disable-openvg"
GALLIUMDRIVERS = "swrast"
+GALLIUMDRIVERS_LLVM33 = "${@base_contains('PACKAGECONFIG', 'r600', 'radeonsi,r600',
'', d)}"
+GALLIUMDRIVERS_LLVM =
"r300,svga,nouveau${@base_version_less_or_equal('MESA_LLVM_RELEASE', '3.2', '',
',${GALLIUMDRIVERS_LLVM33}', d)}"
+GALLIUMDRIVERS_append_x86 = "${@base_contains('PACKAGECONFIG', 'gallium-llvm',
',${GALLIUMDRIVERS_LLVM}', '', d)}"
+GALLIUMDRIVERS_append_x86-64 = "${@base_contains('PACKAGECONFIG', 'gallium-llvm',
',${GALLIUMDRIVERS_LLVM}', '', d)}"
# keep --with-gallium-drivers separate, because when only one of gallium
versions is enabled, other 2 were adding --without-gallium-drivers
PACKAGECONFIG[gallium] = "--with-gallium-drivers=${GALLIUMDRIVERS},
--without-gallium-drivers"
PACKAGECONFIG[gallium-egl] = "--enable-gallium-egl, --disable-gallium-egl"
--
1.8.3.4
___
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] gst-plugins-good: fix orc enabling via PACKAGECONFIG
An extra --disable-orc was being added to EXTRA_OECONF regardless of
whether orc was in PACKAGECONFIG, drop this.
Signed-off-by: Paul Eggleton
---
meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb
b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb
index 8868ba7..daffcf1 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb
@@ -25,7 +25,7 @@ inherit gettext gconf
SRC_URI +=
"file://0001-v4l2-fix-build-with-recent-kernels-the-v4l2_buffer-i.patch"
EXTRA_OECONF += "--disable-aalib --disable-esd --disable-shout2
--disable-libcaca --disable-hal --without-check \
- --disable-orc --disable-examples --disable-taglib"
+ --disable-examples --disable-taglib"
do_configure_prepend() {
# This m4 file contains nastiness which conflicts with libtool 2.2.2
--
1.8.1.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] texinfo: handle correctly @enumerate specification greater than 10
Added signed-off in the patch: The following changes since commit 57662d4f813d5795cac1529633db80a09efdb089: meta-skeleton: Add busybox config fragment example (2013-08-13 23:03:44 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib jhuang0/d_texinfo_mpatrol_0820_0 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/d_texinfo_mpatrol_0820_0 Jackie Huang (1): texinfo: handle correctly @enumerate specification greater than 10 .../texinfo-5.1/enumerate_greater_than_ten.patch | 53 meta/recipes-extended/texinfo/texinfo_5.1.bb |1 + 2 files changed, 54 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-extended/texinfo/texinfo-5.1/enumerate_greater_than_ten.patch Thanks, Jackie On 8/16/2013 4:45 PM, jhuang0 wrote: On 8/16/2013 3:16 PM, jackie.hu...@windriver.com wrote: From: Jackie Huang The following changes since commit 57662d4f813d5795cac1529633db80a09efdb089: meta-skeleton: Add busybox config fragment example (2013-08-13 23:03:44 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib jhuang0/d_texinfo_mpatrol_0816_1 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/d_texinfo_mpatrol_0816_1 Sorry that the removing of a trailing white space in the patch would cause patching fail, plase use the updated one: The following changes since commit 57662d4f813d5795cac1529633db80a09efdb089: meta-skeleton: Add busybox config fragment example (2013-08-13 23:03:44 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib jhuang0/d_texinfo_mpatrol_0816_2 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/d_texinfo_mpatrol_0816_2 Jackie Huang (1): texinfo: handle correctly @enumerate specification greater than 10 .../texinfo-5.1/enumerate_greater_than_ten.patch | 51 meta/recipes-extended/texinfo/texinfo_5.1.bb |1 + 2 files changed, 52 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-extended/texinfo/texinfo-5.1/enumerate_greater_than_ten.patch -- 1.7.4.1 Thanks, Jackie Jackie Huang (1): texinfo: handle correctly @enumerate specification greater than 10 .../texinfo-5.1/enumerate_greater_than_ten.patch | 51 meta/recipes-extended/texinfo/texinfo_5.1.bb |1 + 2 files changed, 52 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-extended/texinfo/texinfo-5.1/enumerate_greater_than_ten.patch -- Jackie Huang WIND RIVER | China Development Center MSN:jackiel...@hotmail.com Tel: +86 8477 8594 Mobile: +86 138 1027 4745 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 00/25] Review and ACK
On 8/20/2013 5:53 PM, Burton, Ross wrote: On 19 August 2013 17:19, Saul Wold wrote: Jackie Huang (1): texinfo: handle correctly @enumerate specification greater than 10 The patch is missing a signed-off, but then again the patch header does have Jackie's email in. Sorry for missing the signed-off, I added and replied the patch with the update. Thanks, Jackie Joe Slater (2): coreutils: add PACKAGECONFIG info for acl support coreutils: allow for acl support I don't like the comment describing the packageconfig format, but that can be removed later. Khem Raj (3): qemuppc: Change default tune to 74xx tune-ppc7400.inc: Add tune file The ordering of these two in the branch is backwards, which could hurt someone doing bisects. Richard, can you fix the ordering when merging? Apart from that, Acked-By: Ross Burton . Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Jackie Huang WIND RIVER | China Development Center MSN:jackiel...@hotmail.com Tel: +86 8477 8594 Mobile: +86 138 1027 4745 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Automake-1.13 fixes
On 20 August 2013 09:44, Marko Lindqvist wrote: > > The following changes since commit fd9e591f266e1a6c183e77f24e50d31e0d52bdd5: > > cronie: fix out of tree build (2013-08-19 11:24:51 +0100) > > are available in the git repository at: > > git://git.openembedded.org/openembedded-core-contrib cazfi/am13 > > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=cazfi/am13 Are you deliberately just sending the cover letter, or is my mailer being strange? Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] sanity.bbclass: a new check for required distro features
On 19 August 2013 20:22, wrote: > Now these BSPs can specify in their BSP config, what distro features > are required, and if these are not enabled then appropriate build > error is thrown to help fix the issue. Are there any situations where these distro feature dependencies can't be expressed more precisely in a package recipe, and then something like Otavio's approach of throwing a SkipPackage used? Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Automake-1.13 fixes
On 20 August 2013 14:06, Burton, Ross wrote: > On 20 August 2013 09:44, Marko Lindqvist wrote: >> >> The following changes since commit fd9e591f266e1a6c183e77f24e50d31e0d52bdd5: >> >> cronie: fix out of tree build (2013-08-19 11:24:51 +0100) >> >> are available in the git repository at: >> >> git://git.openembedded.org/openembedded-core-contrib cazfi/am13 >> >> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=cazfi/am13 > > Are you deliberately just sending the cover letter, or is my mailer > being strange? > > Ross I've sent cover letter only. - ML ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Automake-1.13 fixes
>> Are you deliberately just sending the cover letter, or is my mailer >> being strange? > > I've sent cover letter only. For review purposes I much prefer patches in mails, can you send the full series? Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] sanity.bbclass: a new check for required distro features
On Tue, Aug 20, 2013 at 8:11 AM, Burton, Ross wrote: > On 19 August 2013 20:22, wrote: >> Now these BSPs can specify in their BSP config, what distro features >> are required, and if these are not enabled then appropriate build >> error is thrown to help fix the issue. > > Are there any situations where these distro feature dependencies can't > be expressed more precisely in a package recipe, and then something > like Otavio's approach of throwing a SkipPackage used? I have several cases in meta-fsl-demos. Vivante GPU driver provides different libraries depending on the backend to use (DirectFB, FB, Wayland and X11) and they cannot be used at same time. So depending on distro features setting some images are buildable or not. In fact I see same case in OE-Core; core-image-weston /depends/ on wayland distro feature and this is not explicit in metadata nowadays. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] connman: fix systemd support for connman-* packages.
On 13 August 2013 12:26, Yevhen Kyriukha wrote:
> +python __anonymous () {
> +systemd_packages = "${PN}"
> +pkgconfig = d.getVar('PACKAGECONFIG', True)
> +if ('openvpn' or 'vpnc' or 'l2tp' or 'pptp') in pkgconfig.split():
> +systemd_packages += " ${PN}-vpn"
> +d.setVar('SYSTEMD_PACKAGES', systemd_packages)
> +}
I'm not keen on this as its quite a lot of logic to put in the recipe
when it would be good to handle this case of optional packages in the
systemd class itself.
However I'm not sure how best to do this as the FILES_* manipulation
needs to happen *before* the package split, and this check can only
happen *after* the package split. I wonder if it's possible to split
up the systemd class functionality like that.
So, we should probably merge this now, and try and fix the class so we
can remove it again later.
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] sanity.bbclass: a new check for required distro features
On 20 August 2013 12:58, Otavio Salvador wrote: >> Are there any situations where these distro feature dependencies can't >> be expressed more precisely in a package recipe, and then something >> like Otavio's approach of throwing a SkipPackage used? > > I have several cases in meta-fsl-demos. Vivante GPU driver provides > different libraries depending on the backend to use (DirectFB, FB, > Wayland and X11) and they cannot be used at same time. So depending on > distro features setting some images are buildable or not. And does distro_features_check.bbclass work for those? > In fact I see same case in OE-Core; core-image-weston /depends/ on > wayland distro feature and this is not explicit in metadata nowadays. Yes, and it should definitely be checked for. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] linux-dtb: Use kernel build system to generate the dtb files
On Tue, Aug 20, 2013 at 6:55 AM, Mike Looijmans wrote: > I cannot get this to work, do_install fails because it cannot find the > generated ".dtb" file. Yes and I sent another patch, few days ago, to address this regression. I think it is queued for merging. http://patchwork.openembedded.org/patch/55951/ -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] sanity.bbclass: a new check for required distro features
On Tue, Aug 20, 2013 at 9:01 AM, Burton, Ross wrote: > On 20 August 2013 12:58, Otavio Salvador wrote: >>> Are there any situations where these distro feature dependencies can't >>> be expressed more precisely in a package recipe, and then something >>> like Otavio's approach of throwing a SkipPackage used? >> >> I have several cases in meta-fsl-demos. Vivante GPU driver provides >> different libraries depending on the backend to use (DirectFB, FB, >> Wayland and X11) and they cannot be used at same time. So depending on >> distro features setting some images are buildable or not. > > And does distro_features_check.bbclass work for those? Yes; I did it to accomplish our needs. So it does. >> In fact I see same case in OE-Core; core-image-weston /depends/ on >> wayland distro feature and this is not explicit in metadata nowadays. > > Yes, and it should definitely be checked for. Agreed. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] xf86-video-vesa: remove duplicate xf86driproto from DEPENDS
Signed-off-by: Jonathan Liu
---
meta/recipes-graphics/xorg-driver/xf86-video-vesa_2.3.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-vesa_2.3.2.bb
b/meta/recipes-graphics/xorg-driver/xf86-video-vesa_2.3.2.bb
index 7373f85..fb285ea 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-vesa_2.3.2.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-vesa_2.3.2.bb
@@ -14,7 +14,7 @@ supports depths 8, 15 16 and 24."
PR = "${INC_PR}.0"
DEPENDS += "virtual/libx11 libxvmc drm xf86driproto glproto \
- virtual/libgl xineramaproto xf86driproto libpciaccess"
+virtual/libgl xineramaproto libpciaccess"
COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
--
1.8.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] xf86-video-intel: remove duplicate xf86driproto from DEPENDS
Signed-off-by: Jonathan Liu --- meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb b/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb index 9817049..54c4d17 100644 --- a/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb +++ b/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb @@ -10,7 +10,7 @@ Infrastructure (DRI)." LIC_FILES_CHKSUM = "file://COPYING;md5=8730ad58d11c7bbad9a7066d69f7808e" DEPENDS += "virtual/libx11 drm xf86driproto glproto \ - virtual/libgl xineramaproto xf86driproto libpciaccess udev" +virtual/libgl xineramaproto libpciaccess udev" PACKAGECONFIG ??= "" PACKAGECONFIG[sna] = "--enable-sna,--disable-sna" -- 1.8.3.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] qemu-native build regularly failing
Build of qemu-native regularly fails with: | LINK sh4-softmmu/qemu-system-sh4 | /usr/lib/x86_64-linux-gnu/libXext.so.6: undefined reference to `_XEatDataWords' | collect2: error: ld returned 1 exit status This might be some dependency missing, as building first some packets (+ more importantly their dependencies) that do not depend on qemu and only then qemu dependant image success. - ML ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] qemu-native build regularly failing
On Tuesday 20 August 2013 15:51:21 Marko Lindqvist wrote: > Build of qemu-native regularly fails with: > | LINK sh4-softmmu/qemu-system-sh4 > | > | /usr/lib/x86_64-linux-gnu/libXext.so.6: undefined reference to > > `_XEatDataWords' > > | collect2: error: ld returned 1 exit status > > This might be some dependency missing, as building first some packets > (+ more importantly their dependencies) that do not depend on qemu and > only then qemu dependant image success. Do you have something else causing libxext-native to be built by any chance? 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
Re: [OE-core] [PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling
On 13-08-19 03:11 PM, Jason Wessel wrote:
This patch aims to fix the following two cases for the INITRAMFS generation.
1) Allow an image recipe to specify a paired INITRAMFS recipe such
as core-image-minimal-initramfs. This allows building a base
image which always generates the needed initramfs image in one step
2) Allow building a single binary which contains a kernel and
the initramfs.
A key requirement of the initramfs is to be able to add kernel
modules. The current implementation of the INITRAMFS_IMAGE variable
has a circular dependency when using kernel modules in the initramfs
image.bb file that is caused by kernel.bbclass trying to build the
initramfs before the kernel's do_install rule.
The solution for this problem is to have the kernel's
do_bundle_initramfs_image task depend on the do_rootfs from the
INITRAMFS_IMAGE and not some intermediate point. The image.bbclass
will also sets up dependencies to make the initramfs creation task run
last.
The code to bundle the kernel and initramfs together has been added.
At a high level, all it is doing is invoking a second compilation of
the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
to the generated initramfs from the image recipe.
In case it wasn't obvious with Jason cc'ing me, I've seen the patch
before, and I'm good with the change.
So definitely: Acked-by: Bruce Ashfield
I'm adding Andrea to the cc list as well, since we've been talking
about initramfs creation for years now, and I'd want his opinion on
whether this looks good, and would work for meta-handheld.
Cheers,
Bruce
Signed-off-by: Jason Wessel
---
meta/classes/image.bbclass | 12 ++
meta/classes/kernel.bbclass | 96 +--
meta/conf/local.conf.sample | 20 +
3 files changed, 116 insertions(+), 12 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 116bd22..78c25db 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -140,6 +140,10 @@ python () {
d.setVar('MULTILIB_VENDORS', ml_vendor_list)
check_image_features(d)
+initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or ""
+if initramfs_image != "":
+d.appendVarFlag('do_build', 'depends', " %s:do_bundle_initramfs" %
d.getVar('PN', True))
+d.appendVarFlag('do_bundle_initramfs', 'depends', " %s:do_rootfs" %
initramfs_image)
}
#
@@ -614,3 +618,11 @@ do_package_write_deb[noexec] = "1"
do_package_write_rpm[noexec] = "1"
addtask rootfs before do_build
+# Allow the kernel to be repacked with the initramfs and boot image file as a
single file
+do_bundle_initramfs[depends] += "virtual/kernel:do_bundle_initramfs"
+do_bundle_initramfs[nostamp] = "1"
+do_bundle_initramfs[noexec] = "1"
+do_bundle_initramfs () {
+ :
+}
+addtask bundle_initramfs after do_rootfs
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e039dfc..8cf66ce 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ INHIBIT_DEFAULT_DEPS = "1"
KERNEL_IMAGETYPE ?= "zImage"
INITRAMFS_IMAGE ?= ""
INITRAMFS_TASK ?= ""
+INITRAMFS_IMAGE_BUNDLE ?= ""
python __anonymous () {
kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
@@ -19,7 +20,15 @@ python __anonymous () {
image = d.getVar('INITRAMFS_IMAGE', True)
if image:
-d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
+d.appendVarFlag('do_bundle_initramfs', 'depends', '
${INITRAMFS_IMAGE}:do_rootfs')
+
+# NOTE: setting INITRAMFS_TASK is for backward compatibility
+# The preferred method is to set INITRAMFS_IMAGE, because
+# this INITRAMFS_TASK has circular dependency problems
+# if the initramfs requires kernel modules
+image_task = d.getVar('INITRAMFS_TASK', True)
+if image_task:
+d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
}
inherit kernel-arch deploy
@@ -72,9 +81,82 @@ 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 ..."
+ # Find and use the first initramfs image archive type we find
+ rm -f ${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+ for img in cpio.gz cpio.lzo cpio.lzma cpio.xz; do
+ if [ -e
"${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img" ]; then
+ cp
${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img ${B}/usr/.
+ case $img in
+ *gz)
+ echo "gzip decompressing image"
+ gunzip -f
${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.$img
+ break
+ ;;
+ *lzo)
+ echo "lzo decompressi
[OE-core] [CONSOLIDATED PULL 00/25] Final Review and ACK
Richard,
This has been ACK'ed by Ross and Paul, I re-ordered the tune file
usage patches and will create a patch to clean up the comment that
Ross mentions.
I agree with Ross on the texinfo patch, his name is there in the
email.
Thanks
Sau!
The following changes since commit fd9e591f266e1a6c183e77f24e50d31e0d52bdd5:
cronie: fix out of tree build (2013-08-19 11:24:51 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
Bruce Ashfield (2):
linux-yocto-3.8/meta: update drm and intel power management settings
linux-yocto-3.8/meta: enable ALTIVEC for qemuppc
Chen Qi (4):
useradd.bbclass: add missing functions to preinst
init-install.sh: improve hard drive searching process
init-install.sh: fix to handle the boot partition correctly
initscripts: remove obsolete device_table.txt
Chunrong Guo (1):
genext2fs: fix memory corruption on powerpc
Jackie Huang (1):
texinfo: handle correctly @enumerate specification greater than 10
Joe Slater (2):
coreutils: add PACKAGECONFIG info for acl support
coreutils: allow for acl support
Khem Raj (3):
tune-ppc7400.inc: Add tune file
qemuppc: Change default tune to 74xx
uclibc: Upgrade to latest on git
Mark Hatle (1):
prelink: update to latest cross-prelink
Marko Lindqvist (6):
glib-2.0: use trim_version() to get the source directory
pixman: update to upstream version 0.30.2
curl: update to upstream version 7.32.0
glib-2.0: update to upstream version 2.36.4
gtk+: update to upstream version 2.24.20
gettext: update to upstream version 0.18.3
Otavio Salvador (2):
default-distrovars.inc: Add 'DISTRO_FEATURES_DEFAULT' variable
linux-dtb.inc: Fix dtb generation for kernels newer than 3.8
Paul Eggleton (1):
tslib: update to 1.1
Yang Shi (2):
Revert "hello-mod: Ensure the produced package name begins with
kernel-module-"
hello-mod: Add comment for kernel module package naming
.../recipes-kernel/hello-mod/hello-mod_0.1.bb | 9 +-
meta/classes/useradd.bbclass | 3 +
meta/conf/distro/include/default-distrovars.inc| 3 +-
meta/conf/machine/include/tune-ppc7400.inc | 14 +
meta/conf/machine/qemuppc.conf | 2 +-
meta/recipes-bsp/grub/grub-2.00/40_custom | 2 +-
meta/recipes-core/coreutils/coreutils_6.9.bb | 11 +
meta/recipes-core/coreutils/coreutils_8.21.bb | 12 +-
.../parallel.patch | 0
.../gettext/gettext-minimal-0.18.2/aclocal.tgz | Bin 37504 -> 0 bytes
.../COPYING| 0
.../Makefile.in.in | 3 +-
.../Makevars.template | 0
.../gettext/gettext-minimal-0.18.3/aclocal.tgz | Bin 0 -> 37586 bytes
.../config.rpath | 2 +-
.../remove-potcdate.sin| 0
..._0.18.2.bb => gettext-minimal-native_0.18.3.bb} | 0
.../{gettext_0.18.2.bb => gettext_0.18.3.bb} | 5 +-
.../{glib-2.0_2.36.3.bb => glib-2.0_2.36.4.bb} | 6 +-
.../initrdscripts/files/init-install.sh| 160 ++--
.../initscripts/initscripts-1.0/device_table.txt | 197 -
meta/recipes-core/initscripts/initscripts_1.0.bb | 2 -
meta/recipes-core/uclibc/uclibc-git.inc| 3 +-
meta/recipes-core/uclibc/uclibc.inc| 2 +-
.../fix-memory-corruption-on-powerpc.patch | 76 ++
meta/recipes-devtools/genext2fs/genext2fs_1.4.1.bb | 3 +-
meta/recipes-devtools/prelink/prelink_git.bb | 3 +-
.../texinfo-5.1/enumerate_greater_than_ten.patch | 51 ++
meta/recipes-extended/texinfo/texinfo_5.1.bb | 1 +
...utton-do-not-prelight-in-touchscreen-mode.patch | 0
...Duplicate-the-exec-string-returned-by-gtk.patch | 0
.../cellrenderer-cairo.patch | 0
.../configure-nm.patch | 0
.../configurefix.patch | 0
.../{gtk+-2.24.18 => gtk+-2.24.20}/doc-fixes.patch | 0
.../entry-cairo.patch | 0
.../hardcoded_libtool.patch| 0
.../{gtk+-2.24.18 => gtk+-2.24.20}/no-demos.patch | 0
.../run-iconcache.patch| 0
.../toggle-font.diff | 0
.../{gtk+-2.24.18 => gtk+-2.24.20}/xsettings.patch | 0
.../gtk+/{gtk+_2.24.18.bb => gtk+_2.24.20.bb} | 8 +-
.../tslib/0001-Link-plugins-against-libts.patch| 57 --
.../tslib/tslib/32bitBE-support.patch | 55 --
.../recipes-graphics/tslib/tslib/fix_version.patch | 34 -
meta/recipes-graphics/tslib/tslib/multievent.patch | 845 -
.../tslib/tslib/obsolete_automake_macros.patch | 15 -
.../tslib/set-open-mode-for-ts_calibrate_c.patch | 30 -
.../tslib/{tslib_1.0.bb =>
Re: [OE-core] [CONSOLIDATED PULL 00/25] Final Review and ACK
On Tue, 2013-08-20 at 07:28 -0700, Saul Wold wrote: > Richard, > > This has been ACK'ed by Ross and Paul, I re-ordered the tune file > usage patches and will create a patch to clean up the comment that > Ross mentions. > > I agree with Ross on the texinfo patch, his name is there in the > email. Merged, thanks! Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling
On Tue, Aug 20, 2013 at 3:51 PM, Bruce Ashfield
wrote:
> On 13-08-19 03:11 PM, Jason Wessel wrote:
>>
>> This patch aims to fix the following two cases for the INITRAMFS
>> generation.
>>1) Allow an image recipe to specify a paired INITRAMFS recipe such
>> as core-image-minimal-initramfs. This allows building a base
>> image which always generates the needed initramfs image in one step
>>2) Allow building a single binary which contains a kernel and
>> the initramfs.
>>
>> A key requirement of the initramfs is to be able to add kernel
>> modules. The current implementation of the INITRAMFS_IMAGE variable
>> has a circular dependency when using kernel modules in the initramfs
>> image.bb file that is caused by kernel.bbclass trying to build the
>> initramfs before the kernel's do_install rule.
>>
>> The solution for this problem is to have the kernel's
>> do_bundle_initramfs_image task depend on the do_rootfs from the
>> INITRAMFS_IMAGE and not some intermediate point. The image.bbclass
>> will also sets up dependencies to make the initramfs creation task run
>> last.
>>
>> The code to bundle the kernel and initramfs together has been added.
>> At a high level, all it is doing is invoking a second compilation of
>> the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
>> to the generated initramfs from the image recipe.
>
>
> In case it wasn't obvious with Jason cc'ing me, I've seen the patch
> before, and I'm good with the change.
>
> So definitely: Acked-by: Bruce Ashfield
>
> I'm adding Andrea to the cc list as well, since we've been talking
> about initramfs creation for years now, and I'd want his opinion on
> whether this looks good, and would work for meta-handheld.
>
> Cheers,
>
> Bruce
>
>
>>
>> Signed-off-by: Jason Wessel
>> ---
>> meta/classes/image.bbclass | 12 ++
>> meta/classes/kernel.bbclass | 96
>> +--
>> meta/conf/local.conf.sample | 20 +
>> 3 files changed, 116 insertions(+), 12 deletions(-)
>>
>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
>> index 116bd22..78c25db 100644
>> --- a/meta/classes/image.bbclass
>> +++ b/meta/classes/image.bbclass
>> @@ -140,6 +140,10 @@ python () {
>> d.setVar('MULTILIB_VENDORS', ml_vendor_list)
>>
>> check_image_features(d)
>> +initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or ""
>> +if initramfs_image != "":
>> +d.appendVarFlag('do_build', 'depends', " %s:do_bundle_initramfs"
>> % d.getVar('PN', True))
>> +d.appendVarFlag('do_bundle_initramfs', 'depends', " %s:do_rootfs"
>> % initramfs_image)
>> }
>>
>> #
>> @@ -614,3 +618,11 @@ do_package_write_deb[noexec] = "1"
>> do_package_write_rpm[noexec] = "1"
>>
>> addtask rootfs before do_build
>> +# Allow the kernel to be repacked with the initramfs and boot image file
>> as a single file
>> +do_bundle_initramfs[depends] += "virtual/kernel:do_bundle_initramfs"
>> +do_bundle_initramfs[nostamp] = "1"
>> +do_bundle_initramfs[noexec] = "1"
>> +do_bundle_initramfs () {
>> + :
>> +}
>> +addtask bundle_initramfs after do_rootfs
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index e039dfc..8cf66ce 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -9,6 +9,7 @@ INHIBIT_DEFAULT_DEPS = "1"
>> KERNEL_IMAGETYPE ?= "zImage"
>> INITRAMFS_IMAGE ?= ""
>> INITRAMFS_TASK ?= ""
>> +INITRAMFS_IMAGE_BUNDLE ?= ""
>>
>> python __anonymous () {
>> kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
>> @@ -19,7 +20,15 @@ python __anonymous () {
>>
>> image = d.getVar('INITRAMFS_IMAGE', True)
>> if image:
>> -d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
>> +d.appendVarFlag('do_bundle_initramfs', 'depends', '
>> ${INITRAMFS_IMAGE}:do_rootfs')
>> +
>> +# NOTE: setting INITRAMFS_TASK is for backward compatibility
>> +# The preferred method is to set INITRAMFS_IMAGE, because
>> +# this INITRAMFS_TASK has circular dependency problems
>> +# if the initramfs requires kernel modules
>> +image_task = d.getVar('INITRAMFS_TASK', True)
>> +if image_task:
>> +d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
>> }
>>
>> inherit kernel-arch deploy
>> @@ -72,9 +81,82 @@ 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 ..."
>> + # Find and use the first initramfs image archive type we find
>> + rm -f ${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
>> + for img in cpio.gz cpio.lzo cpio.lzma cpio.xz; do
>> + if [ -e
>> "${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img" ]; then
>> + cp
>> ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img
Re: [OE-core] [CONSOLIDATED PULL 00/25] Final Review and ACK
On Tue, Aug 20, 2013 at 11:46 AM, Richard Purdie wrote: > On Tue, 2013-08-20 at 07:28 -0700, Saul Wold wrote: >> Richard, >> >> This has been ACK'ed by Ross and Paul, I re-ordered the tune file >> usage patches and will create a patch to clean up the comment that >> Ross mentions. >> >> I agree with Ross on the texinfo patch, his name is there in the >> email. > > Merged, thanks! Thanks for merging the patches but one change, the poky.conf change (http://patchwork.openembedded.org/patch/55893/), has not been merged. Regards, -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-dtb: Fix compilation failure in install and deploy phases
On Tue, Aug 20, 2013 at 7:02 AM, Mike Looijmans wrote: > Baking a kernel failed on the devicetree creation. This was caused > by the install and deploy scripts referring to the wrong directory > for the dtb files. > > Signed-off-by: Mike Looijmans Nack! The right fix for this has been merged already. Your patch fixes kernel > 3.8 but breaks < 3.8 kernels. The patch applied today has support for both cases. Regards, -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oe.types: add 'path' type
On Mon, Aug 19, 2013 at 11:48 PM, Christopher Larson wrote:
> From: Christopher Larson
>
> - path normalization ('normalize' flag, defaults to enabled)
> - existence verification for paths we know should exist ('mustexist' flag)
> - supports clean handling of relative paths ('relativeto' flag)
>
> Signed-off-by: Christopher Larson
Great addition :-)
> ---
> meta/lib/oe/types.py | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/meta/lib/oe/types.py b/meta/lib/oe/types.py
> index 5dac9de..7f47c17 100644
> --- a/meta/lib/oe/types.py
> +++ b/meta/lib/oe/types.py
> @@ -1,4 +1,7 @@
> +import errno
> import re
> +import os
> +
No need for another new and empty line here.
Rest of code looks alright :-)
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oe.types: add 'path' type
On Tue, Aug 20, 2013 at 8:23 AM, Otavio Salvador wrote:
> On Mon, Aug 19, 2013 at 11:48 PM, Christopher Larson
> wrote:
> > From: Christopher Larson
> >
> > - path normalization ('normalize' flag, defaults to enabled)
> > - existence verification for paths we know should exist ('mustexist'
> flag)
> > - supports clean handling of relative paths ('relativeto' flag)
> >
> > Signed-off-by: Christopher Larson
>
> Great addition :-)
>
> > ---
> > meta/lib/oe/types.py | 18 ++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/meta/lib/oe/types.py b/meta/lib/oe/types.py
> > index 5dac9de..7f47c17 100644
> > --- a/meta/lib/oe/types.py
> > +++ b/meta/lib/oe/types.py
> > @@ -1,4 +1,7 @@
> > +import errno
> > import re
> > +import os
> > +
>
> No need for another new and empty line here.
>
> Rest of code looks alright :-)
Good call, will tweak slightly and re-submit. Thanks for the review.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 00/25] Final Review and ACK
On 08/20/2013 08:06 AM, Otavio Salvador wrote: On Tue, Aug 20, 2013 at 11:46 AM, Richard Purdie wrote: On Tue, 2013-08-20 at 07:28 -0700, Saul Wold wrote: Richard, This has been ACK'ed by Ross and Paul, I re-ordered the tune file usage patches and will create a patch to clean up the comment that Ross mentions. I agree with Ross on the texinfo patch, his name is there in the email. Merged, thanks! Thanks for merging the patches but one change, the poky.conf change (http://patchwork.openembedded.org/patch/55893/), has not been merged. Right, forgot to mention that patch in the this email. Richard can you pull the other part of Otavio's patch set. Thanks Sau! Regards, ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] YB2370: Build Appliance integrates PCManFM filemanager
PCManFM filemanager is integrated into Build Appliance; PCManFM is used to display build results from Hob interface. The following changes since commit fe227a023e30f6651618423ab527cde21a350d1a: genext2fs: fix memory corruption on powerpc (2013-08-20 15:31:26 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib ciorga/YB2370 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ciorga/YB2370 Cristian Iorga (3): Build Appliance: pcmanfm integration build-appliance-image: changing the icon theme to sato builder: register directories with pcmanfm meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 6 +- meta/recipes-graphics/builder/builder_0.1.bb| 2 +- meta/recipes-graphics/builder/files/builder_hob_start.sh| 9 + 3 files changed, 15 insertions(+), 2 deletions(-) -- 1.8.1.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] builder: register directories with pcmanfm
Register directories to be opened with PCManFM
filemanager using xdg-open in Build Appliance.
Signed-off-by: Cristian Iorga
---
meta/recipes-graphics/builder/builder_0.1.bb | 2 +-
meta/recipes-graphics/builder/files/builder_hob_start.sh | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/builder/builder_0.1.bb
b/meta/recipes-graphics/builder/builder_0.1.bb
index 78d41e5..1e8c977 100644
--- a/meta/recipes-graphics/builder/builder_0.1.bb
+++ b/meta/recipes-graphics/builder/builder_0.1.bb
@@ -1,7 +1,7 @@
SUMMARY = "New user to do specific job"
DESCRIPTION = "This recipe create a new user named ${PN}, who is used for
specific jobs like building. The task can be auto started via mini X"
SECTION = "x11"
-PR = "r6"
+PR = "r7"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://builder_hob_start.sh;endline=5;md5=84796c3c41785d86100fdabcbdade00e"
diff --git a/meta/recipes-graphics/builder/files/builder_hob_start.sh
b/meta/recipes-graphics/builder/files/builder_hob_start.sh
index 40616f5..b3a0540 100644
--- a/meta/recipes-graphics/builder/files/builder_hob_start.sh
+++ b/meta/recipes-graphics/builder/files/builder_hob_start.sh
@@ -9,6 +9,15 @@ export PSEUDO_LOCALSTATEDIR=/home/builder/pseudo
export PSEUDO_LIBDIR=/usr/lib/pseudo/lib64
export GIT_PROXY_COMMAND=/home/builder/poky/scripts/oe-git-proxy
+#start pcmanfm in daemon mode to allow asynchronous launch
+pcmanfm -d&
+
+#register folders to open with PCManFM filemanager
+if [ ! -d /home/ubik/tmp/.local/share/applications ]; then
+mkdir -p /home/builder/.local/share/applications/
+xdg-mime default pcmanfm.desktop inode/directory
+fi
+
cd /home/builder/poky
. ./oe-init-build-env
--
1.8.1.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] Build Appliance: pcmanfm integration
PCManFm file manager is integrated in Build Appliance xprop, xdg-utils are also integrated for file association support. Signed-off-by: Cristian Iorga --- meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb index 6a0722a..b58d238 100644 --- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb +++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb @@ -38,11 +38,14 @@ RDEPENDS_packagegroup-self-hosted-host-tools = "\ hdparm \ iptables \ lsb \ +xprop \ +xdg-utils \ mc \ mc-fish \ mc-helpers \ mc-helpers-perl \ mc-helpers-python \ +pcmanfm \ parted \ pseudo \ screen \ -- 1.8.1.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] build-appliance-image: changing the icon theme to sato
Hicolor icon theme does not properly displays icons for folders. Sato icon theme is working correctly. Also, settings-daemon needs to be added to image in order to properly display folder icons. Signed-off-by: Cristian Iorga --- meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb index b58d238..c1e2951 100644 --- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb +++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb @@ -124,7 +124,8 @@ RDEPENDS_packagegroup-self-hosted-extended = "\ grep \ groff \ gzip \ -hicolor-icon-theme \ +settings-daemon \ +sato-icon-theme \ libaio \ libusb1 \ libxml2 \ -- 1.8.1.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [for dylan][PATCH 3/3] linux-dtb.inc: Fix dtb generation for kernels newer than 3.8
From: Otavio Salvador
The 3.8 kernel has change the default directory where the dtb file is
stored. The change has been done at:
,[ Quote of 3.8 kernel change ]
| commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
| Author: Grant Likely
| Date: Tue Nov 27 16:29:11 2012 -0700
|
| ARM: dt: change .dtb build rules to build in dts directory
|
| The current rules have the .dtb files build in a different directory
| from the .dts files. The only reason for this is that it was what
| PowerPC has done historically. This patch changes ARM to use the generic
| dtb rule which builds .dtb files in the same directory as the source .dts.
|
| Cc: Russell King
| Cc: Arnd Bergmann
| Acked-by: Olof Johansson
| Cc: linux-arm-ker...@lists.infradead.org
| Signed-off-by: Grant Likely
| [swarren: added rm command for old stale .dtb files]
| Signed-off-by: Stephen Warren
| Signed-off-by: Rob Herring
`
This change adds support for both places to backward and forward
compatibility.
Signed-off-by: Otavio Salvador
Acked-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-dtb.inc | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index 7c8058f..258a5fc 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -16,8 +16,12 @@ do_install_append() {
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}
- install -m 0644 ${B}/arch/${ARCH}/boot/${DTB}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
+ if [ ! -e "${DTB_PATH}" ]; then
+ DTB_PATH="${B}/arch/${ARCH}/boot/${DTB}"
+ fi
+ install -m 0644 ${DTB_PATH}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
done
fi
}
@@ -32,8 +36,12 @@ do_deploy_append() {
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}"
+ if [ ! -e "${DTB_PATH}" ]; then
+ DTB_PATH="${B}/arch/${ARCH}/boot/${DTB}"
+ fi
install -d ${DEPLOYDIR}
- install -m 0644 ${B}/arch/${ARCH}/boot/${DTB}
${DEPLOYDIR}/${DTB_NAME}.dtb
+ install -m 0644 ${DTB_PATH} ${DEPLOYDIR}/${DTB_NAME}.dtb
cd ${DEPLOYDIR}
ln -sf ${DTB_NAME}.dtb ${DTB_SYMLINK_NAME}.dtb
cd -
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [for dylan][PATCH 2/3] linux-dtb: Use kernel build system to generate the dtb files
From: Otavio Salvador
As the Linux kernel, unconditionally, builds the dtc application and
it is the compatible version with the DeviceTree files shipped within
the kernel it is better to use it and the kernel build system to
generate the dtb files.
Some DeviceTree files rely on CPP and kernel headers to be able to
generate the dtb binary contents and it is harder to replicate it
outside of Linux kernel build system so we /use/ it.
To comply with these assumptions we need to use the dtb file when
calling 'make' instead of pointing to the DeviceTree source file; the
code has been made backward compatible but it is advised to move to
the new definition to avoid warnings as:
,[ Original definition ]
| KERNEL_DEVICETREE = "${S}/arch/arm/boot/dts/imx6q-sabresd.dts"
`
Becomes:
,[ New definition ]
| KERNEL_DEVICETREE = "imx6q-sabresd.dtb"
`
Signed-off-by: Otavio Salvador
Signed-off-by: Saul Wold
---
meta/recipes-kernel/linux/linux-dtb.inc | 57 ++-
1 files changed, 26 insertions(+), 31 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index 401d1e0..7c8058f 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -3,42 +3,37 @@ FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/devicetree*"
KERNEL_DEVICETREE_FLAGS ?= "-R 8 -p 0x3000"
python __anonymous () {
-devicetree = d.getVar("KERNEL_DEVICETREE", True) or ''
-if devicetree:
- depends = d.getVar("DEPENDS", True)
- d.setVar("DEPENDS", "%s dtc-native" % depends)
- packages = d.getVar("PACKAGES", True)
- d.setVar("PACKAGES", "%s kernel-devicetree" % packages)
+ d.appendVar("PACKAGES", " kernel-devicetree")
}
do_install_append() {
if test -n "${KERNEL_DEVICETREE}"; then
- for DTS_FILE in ${KERNEL_DEVICETREE}; do
- if [ ! -f ${DTS_FILE} ]; then
- echo "Warning: ${DTS_FILE} is not available!"
- continue
+ 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
- DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F "."
'{print $1}'`
- DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
"s/${MACHINE}/${DTS_BASE_NAME}/g"`
- DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed "s/${MACHINE}/${DTS_BASE_NAME}/g"`
- dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o
${DTS_BASE_NAME} ${DTS_FILE}
- install -m 0644 ${DTS_BASE_NAME}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
+ 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"`
+ oe_runmake ${DTB}
+ install -m 0644 ${B}/arch/${ARCH}/boot/${DTB}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
done
fi
}
do_deploy_append() {
if test -n "${KERNEL_DEVICETREE}"; then
- for DTS_FILE in ${KERNEL_DEVICETREE}; do
- if [ ! -f ${DTS_FILE} ]; then
- echo "Warning: ${DTS_FILE} is not available!"
- continue
+ 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
- DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F "."
'{print $1}'`
- DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
"s/${MACHINE}/${DTS_BASE_NAME}/g"`
- DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed "s/${MACHINE}/${DTS_BASE_NAME}/g"`
+ 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"`
install -d ${DEPLOYDIR}
- install -m 0644 ${B}/${DTS_BASE_NAME}
${DEPLOYDIR}/${DTB_NAME}.dtb
+ install -m 0644 ${B}/arch/${ARCH}/boot/${DTB}
${DEPLOYDIR}/${DTB_NAME}.dtb
cd ${DEPLOYDIR}
[OE-core] [for dylan][PATCH 1/3] linux-dtb.inc: Replace /boot/ with /${KERNEL_IMAGEDEST}/
From: Mike Looijmans
Devicetree files were installed hard-coded in /boot. When KERNEL_IMAGEDEST
is anything else but "boot", the postinstall script and the file locations
no longer match and the postinstall will fail.
Replace "boot" with "${KERNEL_IMAGEDEST}" to fix this problem, and to allow
the devicetree files to be installed in another location.
Signed-off-by: Mike Looijmans
Signed-off-by: Saul Wold
---
meta/recipes-kernel/linux/linux-dtb.inc |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index 58b93a1..401d1e0 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -1,5 +1,5 @@
# Support for device tree generation
-FILES_kernel-devicetree = "/boot/devicetree*"
+FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/devicetree*"
KERNEL_DEVICETREE_FLAGS ?= "-R 8 -p 0x3000"
python __anonymous () {
@@ -22,7 +22,7 @@ do_install_append() {
DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
"s/${MACHINE}/${DTS_BASE_NAME}/g"`
DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed "s/${MACHINE}/${DTS_BASE_NAME}/g"`
dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o
${DTS_BASE_NAME} ${DTS_FILE}
- install -m 0644 ${DTS_BASE_NAME}
${D}/boot/devicetree-${DTB_SYMLINK_NAME}.dtb
+ install -m 0644 ${DTS_BASE_NAME}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
done
fi
}
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling
On 13-08-20 11:03 AM, Andrea Adami wrote:
On Tue, Aug 20, 2013 at 3:51 PM, Bruce Ashfield
wrote:
On 13-08-19 03:11 PM, Jason Wessel wrote:
This patch aims to fix the following two cases for the INITRAMFS
generation.
1) Allow an image recipe to specify a paired INITRAMFS recipe such
as core-image-minimal-initramfs. This allows building a base
image which always generates the needed initramfs image in one step
2) Allow building a single binary which contains a kernel and
the initramfs.
A key requirement of the initramfs is to be able to add kernel
modules. The current implementation of the INITRAMFS_IMAGE variable
has a circular dependency when using kernel modules in the initramfs
image.bb file that is caused by kernel.bbclass trying to build the
initramfs before the kernel's do_install rule.
The solution for this problem is to have the kernel's
do_bundle_initramfs_image task depend on the do_rootfs from the
INITRAMFS_IMAGE and not some intermediate point. The image.bbclass
will also sets up dependencies to make the initramfs creation task run
last.
The code to bundle the kernel and initramfs together has been added.
At a high level, all it is doing is invoking a second compilation of
the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
to the generated initramfs from the image recipe.
In case it wasn't obvious with Jason cc'ing me, I've seen the patch
before, and I'm good with the change.
So definitely: Acked-by: Bruce Ashfield
I'm adding Andrea to the cc list as well, since we've been talking
about initramfs creation for years now, and I'd want his opinion on
whether this looks good, and would work for meta-handheld.
Cheers,
Bruce
Signed-off-by: Jason Wessel
---
meta/classes/image.bbclass | 12 ++
meta/classes/kernel.bbclass | 96
+--
meta/conf/local.conf.sample | 20 +
3 files changed, 116 insertions(+), 12 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 116bd22..78c25db 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -140,6 +140,10 @@ python () {
d.setVar('MULTILIB_VENDORS', ml_vendor_list)
check_image_features(d)
+initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or ""
+if initramfs_image != "":
+d.appendVarFlag('do_build', 'depends', " %s:do_bundle_initramfs"
% d.getVar('PN', True))
+d.appendVarFlag('do_bundle_initramfs', 'depends', " %s:do_rootfs"
% initramfs_image)
}
#
@@ -614,3 +618,11 @@ do_package_write_deb[noexec] = "1"
do_package_write_rpm[noexec] = "1"
addtask rootfs before do_build
+# Allow the kernel to be repacked with the initramfs and boot image file
as a single file
+do_bundle_initramfs[depends] += "virtual/kernel:do_bundle_initramfs"
+do_bundle_initramfs[nostamp] = "1"
+do_bundle_initramfs[noexec] = "1"
+do_bundle_initramfs () {
+ :
+}
+addtask bundle_initramfs after do_rootfs
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e039dfc..8cf66ce 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ INHIBIT_DEFAULT_DEPS = "1"
KERNEL_IMAGETYPE ?= "zImage"
INITRAMFS_IMAGE ?= ""
INITRAMFS_TASK ?= ""
+INITRAMFS_IMAGE_BUNDLE ?= ""
python __anonymous () {
kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
@@ -19,7 +20,15 @@ python __anonymous () {
image = d.getVar('INITRAMFS_IMAGE', True)
if image:
-d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
+d.appendVarFlag('do_bundle_initramfs', 'depends', '
${INITRAMFS_IMAGE}:do_rootfs')
+
+# NOTE: setting INITRAMFS_TASK is for backward compatibility
+# The preferred method is to set INITRAMFS_IMAGE, because
+# this INITRAMFS_TASK has circular dependency problems
+# if the initramfs requires kernel modules
+image_task = d.getVar('INITRAMFS_TASK', True)
+if image_task:
+d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
}
inherit kernel-arch deploy
@@ -72,9 +81,82 @@ 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 ..."
+ # Find and use the first initramfs image archive type we find
+ rm -f ${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+ for img in cpio.gz cpio.lzo cpio.lzma cpio.xz; do
+ if [ -e
"${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img" ]; then
+ cp
${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img ${B}/usr/.
+ case $img in
+ *gz)
+ echo "gzip decompressing image"
+ gunzip -f
${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.$img
+ brea
Re: [OE-core] [PATCH 3/3] builder: register directories with pcmanfm
On 08/20/2013 09:05 AM, Cristian Iorga wrote:
Register directories to be opened with PCManFM
filemanager using xdg-open in Build Appliance.
Signed-off-by: Cristian Iorga
---
meta/recipes-graphics/builder/builder_0.1.bb | 2 +-
meta/recipes-graphics/builder/files/builder_hob_start.sh | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/builder/builder_0.1.bb
b/meta/recipes-graphics/builder/builder_0.1.bb
index 78d41e5..1e8c977 100644
--- a/meta/recipes-graphics/builder/builder_0.1.bb
+++ b/meta/recipes-graphics/builder/builder_0.1.bb
@@ -1,7 +1,7 @@
SUMMARY = "New user to do specific job"
DESCRIPTION = "This recipe create a new user named ${PN}, who is used for specific
jobs like building. The task can be auto started via mini X"
SECTION = "x11"
-PR = "r6"
+PR = "r7"
No PR Bumps!
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://builder_hob_start.sh;endline=5;md5=84796c3c41785d86100fdabcbdade00e"
diff --git a/meta/recipes-graphics/builder/files/builder_hob_start.sh
b/meta/recipes-graphics/builder/files/builder_hob_start.sh
index 40616f5..b3a0540 100644
--- a/meta/recipes-graphics/builder/files/builder_hob_start.sh
+++ b/meta/recipes-graphics/builder/files/builder_hob_start.sh
@@ -9,6 +9,15 @@ export PSEUDO_LOCALSTATEDIR=/home/builder/pseudo
export PSEUDO_LIBDIR=/usr/lib/pseudo/lib64
export GIT_PROXY_COMMAND=/home/builder/poky/scripts/oe-git-proxy
+#start pcmanfm in daemon mode to allow asynchronous launch
+pcmanfm -d&
+
+#register folders to open with PCManFM filemanager
+if [ ! -d /home/ubik/tmp/.local/share/applications ]; then
^
What's that user? Should it be builder?
+mkdir -p /home/builder/.local/share/applications/
+xdg-mime default pcmanfm.desktop inode/directory
+fi
+
cd /home/builder/poky
. ./oe-init-build-env
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling
On Tue, Aug 20, 2013 at 6:28 PM, Bruce Ashfield
wrote:
> On 13-08-20 11:03 AM, Andrea Adami wrote:
>>
>> On Tue, Aug 20, 2013 at 3:51 PM, Bruce Ashfield
>> wrote:
>>>
>>> On 13-08-19 03:11 PM, Jason Wessel wrote:
This patch aims to fix the following two cases for the INITRAMFS
generation.
1) Allow an image recipe to specify a paired INITRAMFS recipe such
as core-image-minimal-initramfs. This allows building a base
image which always generates the needed initramfs image in one
step
2) Allow building a single binary which contains a kernel and
the initramfs.
A key requirement of the initramfs is to be able to add kernel
modules. The current implementation of the INITRAMFS_IMAGE variable
has a circular dependency when using kernel modules in the initramfs
image.bb file that is caused by kernel.bbclass trying to build the
initramfs before the kernel's do_install rule.
The solution for this problem is to have the kernel's
do_bundle_initramfs_image task depend on the do_rootfs from the
INITRAMFS_IMAGE and not some intermediate point. The image.bbclass
will also sets up dependencies to make the initramfs creation task run
last.
The code to bundle the kernel and initramfs together has been added.
At a high level, all it is doing is invoking a second compilation of
the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
to the generated initramfs from the image recipe.
>>>
>>>
>>>
>>> In case it wasn't obvious with Jason cc'ing me, I've seen the patch
>>> before, and I'm good with the change.
>>>
>>> So definitely: Acked-by: Bruce Ashfield
>>>
>>> I'm adding Andrea to the cc list as well, since we've been talking
>>> about initramfs creation for years now, and I'd want his opinion on
>>> whether this looks good, and would work for meta-handheld.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>
Signed-off-by: Jason Wessel
---
meta/classes/image.bbclass | 12 ++
meta/classes/kernel.bbclass | 96
+--
meta/conf/local.conf.sample | 20 +
3 files changed, 116 insertions(+), 12 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 116bd22..78c25db 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -140,6 +140,10 @@ python () {
d.setVar('MULTILIB_VENDORS', ml_vendor_list)
check_image_features(d)
+initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or ""
+if initramfs_image != "":
+d.appendVarFlag('do_build', 'depends', "
%s:do_bundle_initramfs"
% d.getVar('PN', True))
+d.appendVarFlag('do_bundle_initramfs', 'depends', "
%s:do_rootfs"
% initramfs_image)
}
#
@@ -614,3 +618,11 @@ do_package_write_deb[noexec] = "1"
do_package_write_rpm[noexec] = "1"
addtask rootfs before do_build
+# Allow the kernel to be repacked with the initramfs and boot image
file
as a single file
+do_bundle_initramfs[depends] += "virtual/kernel:do_bundle_initramfs"
+do_bundle_initramfs[nostamp] = "1"
+do_bundle_initramfs[noexec] = "1"
+do_bundle_initramfs () {
+ :
+}
+addtask bundle_initramfs after do_rootfs
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e039dfc..8cf66ce 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ INHIBIT_DEFAULT_DEPS = "1"
KERNEL_IMAGETYPE ?= "zImage"
INITRAMFS_IMAGE ?= ""
INITRAMFS_TASK ?= ""
+INITRAMFS_IMAGE_BUNDLE ?= ""
python __anonymous () {
kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
@@ -19,7 +20,15 @@ python __anonymous () {
image = d.getVar('INITRAMFS_IMAGE', True)
if image:
-d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
+d.appendVarFlag('do_bundle_initramfs', 'depends', '
${INITRAMFS_IMAGE}:do_rootfs')
+
+# NOTE: setting INITRAMFS_TASK is for backward compatibility
+# The preferred method is to set INITRAMFS_IMAGE, because
+# this INITRAMFS_TASK has circular dependency problems
+# if the initramfs requires kernel modules
+image_task = d.getVar('INITRAMFS_TASK', True)
+if image_task:
+d.appendVarFlag('do_configure', 'depends', '
${INITRAMFS_TASK}')
}
inherit kernel-arch deploy
@@ -72,9 +81,82 @@ 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 "Copy
Re: [OE-core] [PATCH 3/3] builder: register directories with pcmanfm
On 08/20/2013 09:41 AM, Iorga, Cristian wrote:
Sould I remove PR entirely?
Or just leave it at version 6?
That's no mistake, I did change the PR because there are no external sources in
this case, so there is not really a new version.
Just an evolution.
Please try to do inline replies, as we prefer them to keep the context.
It should stay at PR="r6" to preserve the package version and
upgradability. Removing PR would cause the package version to go backwards.
Sau!
-Original Message-
From: Saul Wold [mailto:s...@linux.intel.com]
Sent: Tuesday, August 20, 2013 7:38 PM
To: Iorga, Cristian
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 3/3] builder: register directories with pcmanfm
On 08/20/2013 09:05 AM, Cristian Iorga wrote:
Register directories to be opened with PCManFM filemanager using
xdg-open in Build Appliance.
Signed-off-by: Cristian Iorga
---
meta/recipes-graphics/builder/builder_0.1.bb | 2 +-
meta/recipes-graphics/builder/files/builder_hob_start.sh | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/builder/builder_0.1.bb
b/meta/recipes-graphics/builder/builder_0.1.bb
index 78d41e5..1e8c977 100644
--- a/meta/recipes-graphics/builder/builder_0.1.bb
+++ b/meta/recipes-graphics/builder/builder_0.1.bb
@@ -1,7 +1,7 @@
SUMMARY = "New user to do specific job"
DESCRIPTION = "This recipe create a new user named ${PN}, who is used for
specific jobs like building. The task can be auto started via mini X"
SECTION = "x11"
-PR = "r6"
+PR = "r7"
No PR Bumps!
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://builder_hob_start.sh;endline=5;md5=84796c3c41785d86100fdabcbdade00e"
diff --git a/meta/recipes-graphics/builder/files/builder_hob_start.sh
b/meta/recipes-graphics/builder/files/builder_hob_start.sh
index 40616f5..b3a0540 100644
--- a/meta/recipes-graphics/builder/files/builder_hob_start.sh
+++ b/meta/recipes-graphics/builder/files/builder_hob_start.sh
@@ -9,6 +9,15 @@ export PSEUDO_LOCALSTATEDIR=/home/builder/pseudo
export PSEUDO_LIBDIR=/usr/lib/pseudo/lib64
export GIT_PROXY_COMMAND=/home/builder/poky/scripts/oe-git-proxy
+#start pcmanfm in daemon mode to allow asynchronous launch pcmanfm
+-d&
+
+#register folders to open with PCManFM filemanager if [ ! -d
+/home/ubik/tmp/.local/share/applications ]; then
^
What's that user? Should it be builder?
+mkdir -p /home/builder/.local/share/applications/
+xdg-mime default pcmanfm.desktop inode/directory fi
+
cd /home/builder/poky
. ./oe-init-build-env
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] builder: register directories with pcmanfm
Sould I remove PR entirely?
Or just leave it at version 6?
That's no mistake, I did change the PR because there are no external sources in
this case, so there is not really a new version.
Just an evolution.
-Original Message-
From: Saul Wold [mailto:s...@linux.intel.com]
Sent: Tuesday, August 20, 2013 7:38 PM
To: Iorga, Cristian
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 3/3] builder: register directories with pcmanfm
On 08/20/2013 09:05 AM, Cristian Iorga wrote:
> Register directories to be opened with PCManFM filemanager using
> xdg-open in Build Appliance.
>
> Signed-off-by: Cristian Iorga
> ---
> meta/recipes-graphics/builder/builder_0.1.bb | 2 +-
> meta/recipes-graphics/builder/files/builder_hob_start.sh | 9 +
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/builder/builder_0.1.bb
> b/meta/recipes-graphics/builder/builder_0.1.bb
> index 78d41e5..1e8c977 100644
> --- a/meta/recipes-graphics/builder/builder_0.1.bb
> +++ b/meta/recipes-graphics/builder/builder_0.1.bb
> @@ -1,7 +1,7 @@
> SUMMARY = "New user to do specific job"
> DESCRIPTION = "This recipe create a new user named ${PN}, who is used for
> specific jobs like building. The task can be auto started via mini X"
> SECTION = "x11"
> -PR = "r6"
> +PR = "r7"
No PR Bumps!
> LICENSE = "MIT"
> LIC_FILES_CHKSUM =
> "file://builder_hob_start.sh;endline=5;md5=84796c3c41785d86100fdabcbdade00e"
>
> diff --git a/meta/recipes-graphics/builder/files/builder_hob_start.sh
> b/meta/recipes-graphics/builder/files/builder_hob_start.sh
> index 40616f5..b3a0540 100644
> --- a/meta/recipes-graphics/builder/files/builder_hob_start.sh
> +++ b/meta/recipes-graphics/builder/files/builder_hob_start.sh
> @@ -9,6 +9,15 @@ export PSEUDO_LOCALSTATEDIR=/home/builder/pseudo
> export PSEUDO_LIBDIR=/usr/lib/pseudo/lib64
> export GIT_PROXY_COMMAND=/home/builder/poky/scripts/oe-git-proxy
>
> +#start pcmanfm in daemon mode to allow asynchronous launch pcmanfm
> +-d&
> +
> +#register folders to open with PCManFM filemanager if [ ! -d
> +/home/ubik/tmp/.local/share/applications ]; then
^
What's that user? Should it be builder?
> +mkdir -p /home/builder/.local/share/applications/
> +xdg-mime default pcmanfm.desktop inode/directory fi
> +
> cd /home/builder/poky
> . ./oe-init-build-env
>
>
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] builder: register directories with pcmanfm
Register directories to be opened with PCManFM filemanager using xdg-open in Build Appliance. Signed-off-by: Cristian Iorga --- meta/recipes-graphics/builder/files/builder_hob_start.sh | 9 + 1 file changed, 9 insertions(+) diff --git a/meta/recipes-graphics/builder/files/builder_hob_start.sh b/meta/recipes-graphics/builder/files/builder_hob_start.sh index 40616f5..b3a0540 100644 --- a/meta/recipes-graphics/builder/files/builder_hob_start.sh +++ b/meta/recipes-graphics/builder/files/builder_hob_start.sh @@ -9,6 +9,15 @@ export PSEUDO_LOCALSTATEDIR=/home/builder/pseudo export PSEUDO_LIBDIR=/usr/lib/pseudo/lib64 export GIT_PROXY_COMMAND=/home/builder/poky/scripts/oe-git-proxy +#start pcmanfm in daemon mode to allow asynchronous launch +pcmanfm -d& + +#register folders to open with PCManFM filemanager +if [ ! -d /home/ubik/tmp/.local/share/applications ]; then +mkdir -p /home/builder/.local/share/applications/ +xdg-mime default pcmanfm.desktop inode/directory +fi + cd /home/builder/poky . ./oe-init-build-env -- 1.8.1.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] Build Appliance: pcmanfm integration
PCManFm file manager is integrated in Build Appliance xprop, xdg-utils are also integrated for file association support. Signed-off-by: Cristian Iorga --- meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb index 6a0722a..b58d238 100644 --- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb +++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb @@ -38,11 +38,14 @@ RDEPENDS_packagegroup-self-hosted-host-tools = "\ hdparm \ iptables \ lsb \ +xprop \ +xdg-utils \ mc \ mc-fish \ mc-helpers \ mc-helpers-perl \ mc-helpers-python \ +pcmanfm \ parted \ pseudo \ screen \ -- 1.8.1.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] [PATCH v2] YB2370: Build Appliance integrates PCManFM filemanager
PCManFM filemanager is integrated into Build Appliance; PCManFM is used to display build results from Hob interface. Patch v2 fixes wrong increment of PR. The following changes since commit fe227a023e30f6651618423ab527cde21a350d1a: genext2fs: fix memory corruption on powerpc (2013-08-20 15:31:26 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib ciorga/YB2370 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ciorga/YB2370 Cristian Iorga (3): Build Appliance: pcmanfm integration build-appliance-image: changing the icon theme to sato builder: register directories with pcmanfm meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 6 +- meta/recipes-graphics/builder/files/builder_hob_start.sh| 9 + 2 files changed, 14 insertions(+), 1 deletion(-) -- 1.8.1.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] build-appliance-image: changing the icon theme to sato
Hicolor icon theme does not properly displays icons for folders. Sato icon theme is working correctly. Also, settings-daemon needs to be added to image in order to properly display folder icons. Signed-off-by: Cristian Iorga --- meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb index b58d238..c1e2951 100644 --- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb +++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb @@ -124,7 +124,8 @@ RDEPENDS_packagegroup-self-hosted-extended = "\ grep \ groff \ gzip \ -hicolor-icon-theme \ +settings-daemon \ +sato-icon-theme \ libaio \ libusb1 \ libxml2 \ -- 1.8.1.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] kernel.bbclass: Create symbolic link to add ${KERNEL_IMAGETYPE} to boot package
* By default for some platforms U-boot assumes the kernel image is located in
the boot directory of the root filesystem.
* The kernel.bbclass already includes the kernel image in the /boot directory
but adds a version number to the file name.
* Create a symbolic link that names the kernel image in the exact way that
U-boot expects.
Signed-off-by: Franklin S. Cooper Jr
---
Version 2 changes:
Change "ln -s" to "ln -sf" based on Bruce's comment.
meta/classes/kernel.bbclass |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e039dfc..6e7d994 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -109,6 +109,7 @@ kernel_do_install() {
install -d ${D}/${KERNEL_IMAGEDEST}
install -d ${D}/boot
install -m 0644 ${KERNEL_OUTPUT}
${D}/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}
+ ln -sf
${D}/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION}
install -m 0644 vmlinux ${D}/boot/vmlinux-${KERNEL_VERSION}
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [for dylan][PATCH 3/3] linux-dtb.inc: Fix dtb generation for kernels newer than 3.8
Hi Otavio, On Tuesday 20 August 2013 15:17:16 Otavio Salvador wrote: > On Tue, Aug 20, 2013 at 1:51 PM, Franklin S. Cooper Jr wrote: > > From: Otavio Salvador > > > > The 3.8 kernel has change the default directory where the dtb file is > > stored. The change has been done at: > > > > ,[ Quote of 3.8 kernel change ] > > > > | commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8 > > | Author: Grant Likely > > | Date: Tue Nov 27 16:29:11 2012 -0700 > > | > > | ARM: dt: change .dtb build rules to build in dts directory > > | > > | The current rules have the .dtb files build in a different directory > > | from the .dts files. The only reason for this is that it was what > > | PowerPC has done historically. This patch changes ARM to use the > > | generic > > | dtb rule which builds .dtb files in the same directory as the source > > | .dts. > > | > > | Cc: Russell King > > | Cc: Arnd Bergmann > > | Acked-by: Olof Johansson > > | Cc: linux-arm-ker...@lists.infradead.org > > | Signed-off-by: Grant Likely > > | [swarren: added rm command for old stale .dtb files] > > | Signed-off-by: Stephen Warren > > | Signed-off-by: Rob Herring > > > > ` > > > > This change adds support for both places to backward and forward > > compatibility. > > > > Signed-off-by: Otavio Salvador > > Acked-by: Bruce Ashfield > > Franklin, I agree this is the way to go but I think it is a bit risky > to change it in dylan. > > I think it could be included in meta-ti or other layers (in case it is > need for dylan) but it has breakage risk as noticed today in some > behaviour change as found in meta-xilinx. > > Paul, please be conservative about this and my previous linux-dtb > patch. In case it is going to be applied in dylan we need to let it > sleep some more time in master to find any other side effect due the > behaviour change. Agreed, I'd very much prefer to hold on this until it has had time to soak in master. 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
Re: [OE-core] [for dylan][PATCH 3/3] linux-dtb.inc: Fix dtb generation for kernels newer than 3.8
On Tue, Aug 20, 2013 at 1:51 PM, Franklin S. Cooper Jr wrote: > From: Otavio Salvador > > The 3.8 kernel has change the default directory where the dtb file is > stored. The change has been done at: > > ,[ Quote of 3.8 kernel change ] > | commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8 > | Author: Grant Likely > | Date: Tue Nov 27 16:29:11 2012 -0700 > | > | ARM: dt: change .dtb build rules to build in dts directory > | > | The current rules have the .dtb files build in a different directory > | from the .dts files. The only reason for this is that it was what > | PowerPC has done historically. This patch changes ARM to use the generic > | dtb rule which builds .dtb files in the same directory as the source > .dts. > | > | Cc: Russell King > | Cc: Arnd Bergmann > | Acked-by: Olof Johansson > | Cc: linux-arm-ker...@lists.infradead.org > | Signed-off-by: Grant Likely > | [swarren: added rm command for old stale .dtb files] > | Signed-off-by: Stephen Warren > | Signed-off-by: Rob Herring > ` > > This change adds support for both places to backward and forward > compatibility. > > Signed-off-by: Otavio Salvador > Acked-by: Bruce Ashfield Franklin, I agree this is the way to go but I think it is a bit risky to change it in dylan. I think it could be included in meta-ti or other layers (in case it is need for dylan) but it has breakage risk as noticed today in some behaviour change as found in meta-xilinx. Paul, please be conservative about this and my previous linux-dtb patch. In case it is going to be applied in dylan we need to let it sleep some more time in master to find any other side effect due the behaviour change. Regards, -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [for dylan][PATCH 3/3] linux-dtb.inc: Fix dtb generation for kernels newer than 3.8
> -Original Message- > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > Sent: Tuesday, August 20, 2013 1:24 PM > To: Otavio Salvador > Cc: Cooper Jr., Franklin; Patches and discussions about the oe-core layer > Subject: Re: [for dylan][PATCH 3/3] linux-dtb.inc: Fix dtb generation for > kernels > newer than 3.8 > > Hi Otavio, > > On Tuesday 20 August 2013 15:17:16 Otavio Salvador wrote: > > On Tue, Aug 20, 2013 at 1:51 PM, Franklin S. Cooper Jr > > > wrote: > > > From: Otavio Salvador > > > > > > The 3.8 kernel has change the default directory where the dtb file > > > is stored. The change has been done at: > > > > > > ,[ Quote of 3.8 kernel change ] > > > > > > | commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8 > > > | Author: Grant Likely > > > | Date: Tue Nov 27 16:29:11 2012 -0700 > > > | > > > | ARM: dt: change .dtb build rules to build in dts directory > > > | > > > | The current rules have the .dtb files build in a different directory > > > | from the .dts files. The only reason for this is that it was what > > > | PowerPC has done historically. This patch changes ARM to use the > > > | generic > > > | dtb rule which builds .dtb files in the same directory as the source > > > | .dts. > > > | > > > | Cc: Russell King > > > | Cc: Arnd Bergmann > > > | Acked-by: Olof Johansson > > > | Cc: linux-arm-ker...@lists.infradead.org > > > | Signed-off-by: Grant Likely > > > | [swarren: added rm command for old stale .dtb files] > > > | Signed-off-by: Stephen Warren > > > | Signed-off-by: Rob Herring > > > > > > ` > > > > > > This change adds support for both places to backward and forward > > > compatibility. > > > > > > Signed-off-by: Otavio Salvador > > > Acked-by: Bruce Ashfield > > > > Franklin, I agree this is the way to go but I think it is a bit risky > > to change it in dylan. > > > > I think it could be included in meta-ti or other layers (in case it is > > need for dylan) but it has breakage risk as noticed today in some > > behaviour change as found in meta-xilinx. > > > > Paul, please be conservative about this and my previous linux-dtb > > patch. In case it is going to be applied in dylan we need to let it > > sleep some more time in master to find any other side effect due the > > behaviour change. > > Agreed, I'd very much prefer to hold on this until it has had time to soak in > master. [Franklin] No problem. I will put this on the back burner for some time. > > 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
Re: [OE-core] [PATCH v2] kernel.bbclass: Create symbolic link to add ${KERNEL_IMAGETYPE} to boot package
On 8/20/13 1:45 PM, Franklin S. Cooper Jr wrote:
* By default for some platforms U-boot assumes the kernel image is located in
the boot directory of the root filesystem.
* The kernel.bbclass already includes the kernel image in the /boot directory
but adds a version number to the file name.
* Create a symbolic link that names the kernel image in the exact way that
U-boot expects.
This should be done with a package post-install script. It is fairly common for
multilib kernel versions to be installed on a machine at the same time, with the
Link pointing to the 'last-installed' version. Doing it in the do_install rule
will cause a conflict (at least in the RPM case), preventing certain field
upgrade activities.
post install script with something like:
ln -sf $D/boot/
Should work.
(The above assumes that the kernel itself is being packaged.. if it's not being
packages and just copied to the end image -- then doing the link should be fine.)
--Mark
Signed-off-by: Franklin S. Cooper Jr
---
Version 2 changes:
Change "ln -s" to "ln -sf" based on Bruce's comment.
meta/classes/kernel.bbclass |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e039dfc..6e7d994 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -109,6 +109,7 @@ kernel_do_install() {
install -d ${D}/${KERNEL_IMAGEDEST}
install -d ${D}/boot
install -m 0644 ${KERNEL_OUTPUT}
${D}/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}
+ ln -sf
${D}/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION}
install -m 0644 vmlinux ${D}/boot/vmlinux-${KERNEL_VERSION}
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] openssl: avoid NULL pointer dereference in three places
On 08/19/2013 10:07 PM, Xufeng Zhang wrote:
On 08/20/2013 12:13 PM, Saul Wold wrote:
On 08/19/2013 06:59 PM, Xufeng Zhang wrote:
Hi All,
Anybody help me review this?
Thanks,
Xufeng
On 06/04/2013 02:15 PM, Xufeng Zhang wrote:
There are three potential NULL pointer dereference in
EVP_DigestInit_ex(), dh_pub_encode() and dsa_pub_encode()
functions.
Fix them by adding proper null pointer check.
[YOCTO #4600]
[ CQID: WIND00373257 ]
Signed-off-by: Xufeng Zhang
---
...-pointer-dereference-in-EVP_DigestInit_ex.patch | 16 +
...NULL-pointer-dereference-in-dh_pub_encode.patch | 34
meta/recipes-connectivity/openssl/openssl.inc |2 +-
.../recipes-connectivity/openssl/openssl_1.0.1e.bb |2 +
4 files changed, 53 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-avoid-NULL-pointer-dereference-in-EVP_DigestInit_ex.patch
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-avoid-NULL-pointer-dereference-in-dh_pub_encode.patch
diff --git
a/meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-avoid-NULL-pointer-dereference-in-EVP_DigestInit_ex.patch
b/meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-avoid-NULL-pointer-dereference-in-EVP_DigestInit_ex.patch
new file mode 100644
index 000..69924a4
--- /dev/null
+++
b/meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-avoid-NULL-pointer-dereference-in-EVP_DigestInit_ex.patch
@@ -0,0 +1,16 @@
+openssl: avoid NULL pointer dereference in EVP_DigestInit_ex()
+
+We should avoid accessing the type pointer if it's NULL,
+this could happen if ctx->digest is not NULL.
These patches both need Upstream-Status: and Signed-off-by: Tags
Ok, I'll add these stuff when I send V2.
Ok, looking at more details, these are good patches and should be
upstreamed also.
Sau!
+---
+--- a/crypto/evp/digest.c
b/crypto/evp/digest.c
+@@ -199,7 +199,7 @@
+ return 0;
+ }
+ #endif
+-if (ctx->digest != type)
++if (type&& (ctx->digest != type))
+ {
+ if (ctx->digest&& ctx->digest->ctx_size)
+ OPENSSL_free(ctx->md_data);
I am more concerned about this patch as I do not know the code well,
but if ctx->digest is non-NULL and type is, this code would not be
executed which would be wrong, correct?
No, that's correct, if type is NULL, we should not execute the below
code as type pointer is accessed in the following code, see:
int EVP_DigestInit_ex()
{
...
if (ctx->digest != type)
{
if (ctx->digest && ctx->digest->ctx_size)
OPENSSL_free(ctx->md_data);
ctx->digest=type;
if (!(ctx->flags & EVP_MD_CTX_FLAG_NO_INIT) && type->ctx_size)
{
ctx->update = type->update;
...
}
...
}
Your changing the behavior of the code here.
But if we don't change, NULL pointer dereference would appear.
Also reading the code, it should be be possible for type to be NULL,
I think you are saying "it should not be possible"
unless some memory corruption occurs earlier as there is a check at
line 153 for !type, which should cause it to goto skip_to_init.
Yes, it's true, but such code is executed only when OPENSSL_NO_ENGINE is
not defined.
Please verify this patch is really needed.
diff --git
a/meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-avoid-NULL-pointer-dereference-in-dh_pub_encode.patch
b/meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-avoid-NULL-pointer-dereference-in-dh_pub_encode.patch
new file mode 100644
index 000..642b0ea
--- /dev/null
+++
b/meta/recipes-connectivity/openssl/openssl-1.0.1e/openssl-avoid-NULL-pointer-dereference-in-dh_pub_encode.patch
@@ -0,0 +1,34 @@
+openssl: avoid NULL pointer dereference in
dh_pub_encode()/dsa_pub_encode()
+
+We should avoid accessing the pointer if ASN1_STRING_new()
+allocates memory failed.
+---
+--- a/crypto/dh/dh_ameth.c
b/crypto/dh/dh_ameth.c
+@@ -139,6 +139,12 @@
+ dh=pkey->pkey.dh;
+
+ str = ASN1_STRING_new();
++if (!str)
++{
++DHerr(DH_F_DH_PUB_ENCODE, ERR_R_MALLOC_FAILURE);
++goto err;
++}
++
+ str->length = i2d_DHparams(dh,&str->data);
+ if (str->length<= 0)
+ {
+--- a/crypto/dsa/dsa_ameth.c
b/crypto/dsa/dsa_ameth.c
+@@ -148,6 +148,11 @@
+ {
+ ASN1_STRING *str;
+ str = ASN1_STRING_new();
++if (!str)
++{
++DSAerr(DSA_F_DSA_PUB_ENCODE, ERR_R_MALLOC_FAILURE);
++goto err;
++}
+ str->length = i2d_DSAparams(dsa,&str->data);
+ if (str->length<= 0)
+ {
diff --git a/meta/recipes-connectivity/openssl/openssl.inc
b/meta/recipes-connectivity/openssl/openssl.inc
index f5b2432..c753a27 100644
--- a/meta/recipes-connectivity/openssl/openssl.inc
+++ b/meta/recipes-connectivity/openssl/openssl.inc
@@ -5,7 +5,7 @@ BUGTRACKER =
"http:/
Re: [OE-core] [PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling
On 13-08-20 12:41 PM, Andrea Adami wrote:
On Tue, Aug 20, 2013 at 6:28 PM, Bruce Ashfield
wrote:
On 13-08-20 11:03 AM, Andrea Adami wrote:
On Tue, Aug 20, 2013 at 3:51 PM, Bruce Ashfield
wrote:
On 13-08-19 03:11 PM, Jason Wessel wrote:
This patch aims to fix the following two cases for the INITRAMFS
generation.
1) Allow an image recipe to specify a paired INITRAMFS recipe such
as core-image-minimal-initramfs. This allows building a base
image which always generates the needed initramfs image in one
step
2) Allow building a single binary which contains a kernel and
the initramfs.
A key requirement of the initramfs is to be able to add kernel
modules. The current implementation of the INITRAMFS_IMAGE variable
has a circular dependency when using kernel modules in the initramfs
image.bb file that is caused by kernel.bbclass trying to build the
initramfs before the kernel's do_install rule.
The solution for this problem is to have the kernel's
do_bundle_initramfs_image task depend on the do_rootfs from the
INITRAMFS_IMAGE and not some intermediate point. The image.bbclass
will also sets up dependencies to make the initramfs creation task run
last.
The code to bundle the kernel and initramfs together has been added.
At a high level, all it is doing is invoking a second compilation of
the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
to the generated initramfs from the image recipe.
In case it wasn't obvious with Jason cc'ing me, I've seen the patch
before, and I'm good with the change.
So definitely: Acked-by: Bruce Ashfield
I'm adding Andrea to the cc list as well, since we've been talking
about initramfs creation for years now, and I'd want his opinion on
whether this looks good, and would work for meta-handheld.
Cheers,
Bruce
Signed-off-by: Jason Wessel
---
meta/classes/image.bbclass | 12 ++
meta/classes/kernel.bbclass | 96
+--
meta/conf/local.conf.sample | 20 +
3 files changed, 116 insertions(+), 12 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 116bd22..78c25db 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -140,6 +140,10 @@ python () {
d.setVar('MULTILIB_VENDORS', ml_vendor_list)
check_image_features(d)
+initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or ""
+if initramfs_image != "":
+d.appendVarFlag('do_build', 'depends', "
%s:do_bundle_initramfs"
% d.getVar('PN', True))
+d.appendVarFlag('do_bundle_initramfs', 'depends', "
%s:do_rootfs"
% initramfs_image)
}
#
@@ -614,3 +618,11 @@ do_package_write_deb[noexec] = "1"
do_package_write_rpm[noexec] = "1"
addtask rootfs before do_build
+# Allow the kernel to be repacked with the initramfs and boot image
file
as a single file
+do_bundle_initramfs[depends] += "virtual/kernel:do_bundle_initramfs"
+do_bundle_initramfs[nostamp] = "1"
+do_bundle_initramfs[noexec] = "1"
+do_bundle_initramfs () {
+ :
+}
+addtask bundle_initramfs after do_rootfs
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e039dfc..8cf66ce 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ INHIBIT_DEFAULT_DEPS = "1"
KERNEL_IMAGETYPE ?= "zImage"
INITRAMFS_IMAGE ?= ""
INITRAMFS_TASK ?= ""
+INITRAMFS_IMAGE_BUNDLE ?= ""
python __anonymous () {
kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
@@ -19,7 +20,15 @@ python __anonymous () {
image = d.getVar('INITRAMFS_IMAGE', True)
if image:
-d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
+d.appendVarFlag('do_bundle_initramfs', 'depends', '
${INITRAMFS_IMAGE}:do_rootfs')
+
+# NOTE: setting INITRAMFS_TASK is for backward compatibility
+# The preferred method is to set INITRAMFS_IMAGE, because
+# this INITRAMFS_TASK has circular dependency problems
+# if the initramfs requires kernel modules
+image_task = d.getVar('INITRAMFS_TASK', True)
+if image_task:
+d.appendVarFlag('do_configure', 'depends', '
${INITRAMFS_TASK}')
}
inherit kernel-arch deploy
@@ -72,9 +81,82 @@ 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 ..."
+ # Find and use the first initramfs image archive type we find
+ rm -f ${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+ for img in cpio.gz cpio.lzo cpio.lzma cpio.xz; do
+ if [ -e
"${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img" ]; then
+ cp
${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img ${B}/usr/.
+ case $img in
+ *gz)
+ echo "gzip decompressing
[OE-core] [PATCH 2/2] gtk-engines: fix build with automake-1.13
Add patch substitute-tests.patch that works around automake
TESTS limitation.
See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13771.
Signed-off-by: Marko Lindqvist
---
.../gtk-engines-2.20.2/substitute-tests.patch | 37
.../gtk-engines/gtk-engines_2.20.2.bb |5 ++-
2 files changed, 39 insertions(+), 3 deletions(-)
create mode 100644
meta/recipes-gnome/gtk-engines/gtk-engines-2.20.2/substitute-tests.patch
diff --git
a/meta/recipes-gnome/gtk-engines/gtk-engines-2.20.2/substitute-tests.patch
b/meta/recipes-gnome/gtk-engines/gtk-engines-2.20.2/substitute-tests.patch
new file mode 100644
index 000..5c557ba
--- /dev/null
+++ b/meta/recipes-gnome/gtk-engines/gtk-engines-2.20.2/substitute-tests.patch
@@ -0,0 +1,37 @@
+Upstream-Status: Pending
+
+Signed-off-by: Marko Lindqvist
+diff -Nurd gtk-engines-2.20.2/configure.ac gtk-engines-2.20.2/configure.ac
+--- gtk-engines-2.20.2/configure.ac2010-10-01 15:42:37.0 +0300
gtk-engines-2.20.2/configure.ac2013-08-20 02:50:27.930510565 +0300
+@@ -166,6 +166,9 @@
+
+ AC_SUBST(DEVELOPMENT_CFLAGS)
+
++AC_SUBST([exported_symbols_tests], [[$(EXPORTED_SYMBOLS_TESTS)]])
++AC_SUBST([torture_test_tests], [[$(TORTURE_TEST_TESTS)]])
++
+ AM_CONFIG_HEADER([engines/support/config.h])
+
+ AC_CONFIG_FILES([
+diff -Nurd gtk-engines-2.20.2/test/Makefile.am
gtk-engines-2.20.2/test/Makefile.am
+--- gtk-engines-2.20.2/test/Makefile.am2010-09-19 18:18:21.0
+0300
gtk-engines-2.20.2/test/Makefile.am2013-08-20 02:50:36.842510865
+0300
+@@ -66,7 +66,7 @@
+ # Prefix with exported_
+ EXPORTED_SYMBOLS_TESTS = $(patsubst %,exported_%,$(BUILD_ENGINES))
+
+-TESTS += $(EXPORTED_SYMBOLS_TESTS)
++TESTS += @exported_symbols_tests@
+
+
+ #
+@@ -88,7 +88,7 @@
+ TORTURE_TEST_TESTS = torture_buildin $(patsubst
%,torture_%,$(TORTURE_TEST_ENGINES))
+
+ # Add TORTURE_TEST_ENGINES to list of tests
+-TESTS += $(TORTURE_TEST_TESTS)
++TESTS += @torture_test_tests@
+
+ # Possible other tests:
+ # - An extensive theme switch tests that loads/unloads the engine
diff --git a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
index 32d7be4..401e76c 100644
--- a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
+++ b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
@@ -8,8 +8,6 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1"
SECTION = "x11/base"
DEPENDS = "gtk+"
-PR = "r3"
-
PACKAGES_DYNAMIC += "^gtk-engine-.* ^gtk-theme-.*"
RDEPENDS_gtk-theme-redmond = "gtk-engine-redmond95"
@@ -37,6 +35,7 @@ python populate_packages_prepend() {
# TODO: mark theme packages as arch all
}
-SRC_URI += "file://glib-2.32.patch"
+SRC_URI += "file://glib-2.32.patch \
+file://substitute-tests.patch"
SRC_URI[archive.md5sum] = "5deb287bc6075dc21812130604c7dc4f"
SRC_URI[archive.sha256sum] =
"15b680abca6c773ecb85253521fa100dd3b8549befeecc7595b10209d62d66b5"
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] texinfo: correct dont-depend-on-help2man.patch
Patch needed only with automake-1.13 no longer worked as expected after texinfo has been updated to version 5.1. Signed-off-by: Marko Lindqvist --- .../texinfo-5.1/dont-depend-on-help2man.patch | 43 +--- 1 file changed, 38 insertions(+), 5 deletions(-) diff --git a/meta/recipes-extended/texinfo/texinfo-5.1/dont-depend-on-help2man.patch b/meta/recipes-extended/texinfo/texinfo-5.1/dont-depend-on-help2man.patch index 7502328..6e216da 100644 --- a/meta/recipes-extended/texinfo/texinfo-5.1/dont-depend-on-help2man.patch +++ b/meta/recipes-extended/texinfo/texinfo-5.1/dont-depend-on-help2man.patch @@ -1,11 +1,10 @@ Upstream-Status: Inappropŕiate Signed-off-by: Marko Lindqvist -Index: texinfo-5.1/doc/Makefile.am -=== texinfo-5.1.orig/doc/Makefile.am -+++ texinfo-5.1/doc/Makefile.am -@@ -40,7 +40,7 @@ refcard_files = refcard/Makefile refcard +diff -Nurd texinfo-5.1/doc/Makefile.am texinfo-5.1/doc/Makefile.am +--- texinfo-5.1/doc/Makefile.am2013-02-23 02:11:25.0 +0200 texinfo-5.1/doc/Makefile.am2013-08-20 01:43:55.622376198 +0300 +@@ -40,7 +40,7 @@ # Include our texinfo.tex, not Automake's. EXTRA_DIST = epsf.tex texinfo.tex \ fdl.texi \ @@ -14,3 +13,37 @@ Index: texinfo-5.1/doc/Makefile.am $(refcard_files) if INSTALL_WARNINGS +diff -Nurd texinfo-5.1/man/Makefile.am texinfo-5.1/man/Makefile.am +--- texinfo-5.1/man/Makefile.am2013-02-23 02:11:25.0 +0200 texinfo-5.1/man/Makefile.am2013-08-20 01:53:40.542395884 +0300 +@@ -13,24 +13,24 @@ + # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + # These are generated using help2man. +-man_MANS = install-info.1 makeinfo.1 texindex.1 texi2dvi.1 ++#man_MANS = install-info.1 makeinfo.1 texindex.1 texi2dvi.1 + + # These require the build in info/, thus can't do if we failed to find a + # terminal library. + if HAVE_TERMLIBS +-man_MANS += info.1 infokey.1 ++#man_MANS += info.1 infokey.1 + endif + + # These are hand-written. +-man_MANS += info.5 texinfo.5 ++#man_MANS += info.5 texinfo.5 + + # This is generated by pod2man, but let's just run it by hand. +-man_MANS += pod2texi.1 ++#man_MANS += pod2texi.1 + + # These are just .so's to the common program. +-man_MANS += texi2any.1 texi2pdf.1 pdftexi2dvi.1 ++#man_MANS += texi2any.1 texi2pdf.1 pdftexi2dvi.1 + +-EXTRA_DIST = $(man_MANS) ginfo.h2m ++EXTRA_DIST = ginfo.h2m + + # Maintainers should be able to regenerate. + MAINTAINERCLEANFILES = $(man_MANS) -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] qemu-native build regularly failing
On 20 August 2013 16:32, Paul Eggleton wrote: > On Tuesday 20 August 2013 15:51:21 Marko Lindqvist wrote: >> Build of qemu-native regularly fails with: >> | LINK sh4-softmmu/qemu-system-sh4 >> | >> | /usr/lib/x86_64-linux-gnu/libXext.so.6: undefined reference to >> >> `_XEatDataWords' >> >> | collect2: error: ld returned 1 exit status >> >> This might be some dependency missing, as building first some packets >> (+ more importantly their dependencies) that do not depend on qemu and >> only then qemu dependant image success. > > Do you have something else causing libxext-native to be built by any chance? Yes, it seems to be difference between the tree where build fails and the one where build success that former has no libxext-native built. Further, I tested just building libxext-native before building qemu-native, and then the build succeded. - ML ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mesa: enable additional drivers for gallium-llvm x86/x86-64
On Tue, Aug 20, 2013 at 08:41:03PM +1000, Jonathan Liu wrote:
> On 20/08/2013 8:24 PM, Martin Jansa wrote:
> > On Tue, Aug 20, 2013 at 08:10:41PM +1000, Jonathan Liu wrote:
> >> The additional Gallium drivers are needed for open source ATI Radeon
> >> and NVIDIA graphics drivers.
> >>
> >> The radeonsi and r600 drivers require LLVM 3.3 built with r600
> >> PACKAGECONFIG so they must be explicitly enabled by adding r600 to the
> >> mesa PACKAGECONFIG.
> > BTW: I just got interesting question about egl_gallium:
> >
> > libEGL warning: Could not open driver /usr/lib/egl/egl_gallium.so
> > (libLLVM-3.3.so: cannot open shared object file: No such file or
> > directory)
> > Could not initialize egl display
> >
> > EGL error
> > Aborted
> > root@qemux86:~# ls -alh /usr/lib/llvm3.3/
> > drwxr-xr-x2 root root1.0K Aug 20 02:47 .
> > drwxr-xr-x 35 root root 10.0K Aug 20 02:47 ..
> > -rwxr-xr-x1 root root 15.8M Aug 19 14:02 libLLVM-3.3.so
> > -rwxr-xr-x1 root root 78.2K Aug 19 14:02 libLTO.so
> > -rwxr-xr-x1 root root 10.1K Aug 19 14:02 libprofile_rt.so
> >
> > I don't know yet why it worked in my tests when I was updating mesa and
> > llvm, but it's true that we need to make sure that mesa finds
> > libLLVM-3.3.so in versioned subdirectory in runtime.
> LLVM has been working fine for me with llvmpipe (Intel GMA 3600 -
> PowerVR-based), radeon (ATI Radeon HD5450) and nouveau (NVIDIA ION
> GeForce 9400M) drivers.
>
> There is a symbolic link in /usr/lib:
> $ cd /usr/lib
> $ ls -l libLLVM-3.3.so
> lrwxrwxrwx 1 root root 22 Aug 19 21:03 libLLVM-3.3.so ->
> llvm3.3/libLLVM-3.3.so
But this one is from llvm3.3-dev package which isn't installed by
default, isn't it in your setup?
> I intend to submit xf86-video-ati and xf86-video-nouveau to
> meta-openembedded later this week. I tested this change using those
> recipes, linux-firmware (needed for ATI 3D acceleration) and the
> following kernel options:
> CONFIG_DRM_RADEON=m
> CONFIG_DRM_RADEON_KMS=y
> CONFIG_DRM_NOUVEAU=y
>
> Regards,
> Jonathan
> >
> >> Signed-off-by: Jonathan Liu
> >> ---
> >> meta/recipes-graphics/mesa/mesa.inc | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> >> b/meta/recipes-graphics/mesa/mesa.inc
> >> index 447e186..e985d67 100644
> >> --- a/meta/recipes-graphics/mesa/mesa.inc
> >> +++ b/meta/recipes-graphics/mesa/mesa.inc
> >> @@ -50,6 +50,10 @@ PACKAGECONFIG[egl] = "--enable-egl
> >> --with-egl-platforms=${EGL_PLATFORMS}, --disa
> >> PACKAGECONFIG[openvg] = "--enable-openvg, --disable-openvg"
> >>
> >> GALLIUMDRIVERS = "swrast"
> >> +GALLIUMDRIVERS_LLVM33 = "${@base_contains('PACKAGECONFIG', 'r600',
> >> 'radeonsi,r600', '', d)}"
> >> +GALLIUMDRIVERS_LLVM =
> >> "r300,svga,nouveau${@base_version_less_or_equal('MESA_LLVM_RELEASE',
> >> '3.2', '', ',${GALLIUMDRIVERS_LLVM33}', d)}"
> >> +GALLIUMDRIVERS_append_x86 = "${@base_contains('PACKAGECONFIG',
> >> 'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
> >> +GALLIUMDRIVERS_append_x86-64 = "${@base_contains('PACKAGECONFIG',
> >> 'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
> >> # keep --with-gallium-drivers separate, because when only one of gallium
> >> versions is enabled, other 2 were adding --without-gallium-drivers
> >> PACKAGECONFIG[gallium] = "--with-gallium-drivers=${GALLIUMDRIVERS},
> >> --without-gallium-drivers"
> >> PACKAGECONFIG[gallium-egl] = "--enable-gallium-egl,
> >> --disable-gallium-egl"
> >> --
> >> 1.8.3.4
> >>
> >> ___
> >> 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] qemu-native build regularly failing
On Tuesday 20 August 2013 23:26:44 Marko Lindqvist wrote: > On 20 August 2013 16:32, Paul Eggleton > wrote: > > On Tuesday 20 August 2013 15:51:21 Marko Lindqvist wrote: > >> Build of qemu-native regularly fails with: > >> | LINK sh4-softmmu/qemu-system-sh4 > >> | > >> | /usr/lib/x86_64-linux-gnu/libXext.so.6: undefined reference to > >> > >> `_XEatDataWords' > >> > >> | collect2: error: ld returned 1 exit status > >> > >> This might be some dependency missing, as building first some packets > >> (+ more importantly their dependencies) that do not depend on qemu and > >> only then qemu dependant image success. > > > > Do you have something else causing libxext-native to be built by any > > chance? > > Yes, it seems to be difference between the tree where build fails and > the one where build success that former has no libxext-native built. > Further, I tested just building libxext-native before building > qemu-native, and then the build succeded. The problem is we want qemu-native to be buildable both on systems without X11 and systems with X11, so the dependency has to be floating, and this is more or less acceptable for a native recipe - there's only a problem when libxext- native needs to be built. I can't see a lot of value in building libxext- native in any case - what is causing it to be built on your system? 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
Re: [OE-core] qemu-native build regularly failing
On Tue, Aug 20, 2013 at 6:16 PM, Paul Eggleton wrote: > On Tuesday 20 August 2013 23:26:44 Marko Lindqvist wrote: >> On 20 August 2013 16:32, Paul Eggleton >> wrote: >> > On Tuesday 20 August 2013 15:51:21 Marko Lindqvist wrote: >> >> Build of qemu-native regularly fails with: >> >> | LINK sh4-softmmu/qemu-system-sh4 >> >> | >> >> | /usr/lib/x86_64-linux-gnu/libXext.so.6: undefined reference to >> >> >> >> `_XEatDataWords' >> >> >> >> | collect2: error: ld returned 1 exit status >> >> >> >> This might be some dependency missing, as building first some packets >> >> (+ more importantly their dependencies) that do not depend on qemu and >> >> only then qemu dependant image success. >> > >> > Do you have something else causing libxext-native to be built by any >> > chance? >> >> Yes, it seems to be difference between the tree where build fails and >> the one where build success that former has no libxext-native built. >> Further, I tested just building libxext-native before building >> qemu-native, and then the build succeded. > > The problem is we want qemu-native to be buildable both on systems without X11 > and systems with X11, so the dependency has to be floating, and this is more > or > less acceptable for a native recipe - there's only a problem when libxext- > native needs to be built. I can't see a lot of value in building libxext- > native in any case - what is causing it to be built on your system? This floating dependency is a problem; could it be patches to be x11 / x11-less? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] qemu-native build regularly failing
On Tuesday 20 August 2013 18:24:55 Otavio Salvador wrote: > On Tue, Aug 20, 2013 at 6:16 PM, Paul Eggleton > wrote: > > On Tuesday 20 August 2013 23:26:44 Marko Lindqvist wrote: > >> On 20 August 2013 16:32, Paul Eggleton > >> > >> wrote: > >> > On Tuesday 20 August 2013 15:51:21 Marko Lindqvist wrote: > >> >> Build of qemu-native regularly fails with: > >> >> | LINK sh4-softmmu/qemu-system-sh4 > >> >> | > >> >> | /usr/lib/x86_64-linux-gnu/libXext.so.6: undefined reference to > >> >> > >> >> `_XEatDataWords' > >> >> > >> >> | collect2: error: ld returned 1 exit status > >> >> > >> >> This might be some dependency missing, as building first some packets > >> >> (+ more importantly their dependencies) that do not depend on qemu and > >> >> only then qemu dependant image success. > >> > > >> > Do you have something else causing libxext-native to be built by any > >> > chance? > >> > >> Yes, it seems to be difference between the tree where build fails and > >> > >> the one where build success that former has no libxext-native built. > >> Further, I tested just building libxext-native before building > >> qemu-native, and then the build succeded. > > > > The problem is we want qemu-native to be buildable both on systems without > > X11 and systems with X11, so the dependency has to be floating, and this > > is more or less acceptable for a native recipe - there's only a problem > > when libxext- native needs to be built. I can't see a lot of value in > > building libxext- native in any case - what is causing it to be built on > > your system? > > This floating dependency is a problem; could it be patches to be x11 > / x11-less? How would you propose to handle both use-cases? 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
Re: [OE-core] [CONSOLIDATED PULL 00/25] Final Review and ACK
On Tue, 2013-08-20 at 12:06 -0300, Otavio Salvador wrote: > On Tue, Aug 20, 2013 at 11:46 AM, Richard Purdie > wrote: > > On Tue, 2013-08-20 at 07:28 -0700, Saul Wold wrote: > >> Richard, > >> > >> This has been ACK'ed by Ross and Paul, I re-ordered the tune file > >> usage patches and will create a patch to clean up the comment that > >> Ross mentions. > >> > >> I agree with Ross on the texinfo patch, his name is there in the > >> email. > > > > Merged, thanks! > > Thanks for merging the patches but one change, the poky.conf change > (http://patchwork.openembedded.org/patch/55893/), has not been merged. It was resent so I discarded the old series from my queue. You then sent the poky patch to the OE-Core list so every time I searched for it on the poky list, I didn't find it. I have now found and applied it but please keep this in mind in future as its simple things like this that end up delaying things :( Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] qemu-native build regularly failing
On 21 August 2013 00:16, Paul Eggleton wrote: > On Tuesday 20 August 2013 23:26:44 Marko Lindqvist wrote: >> On 20 August 2013 16:32, Paul Eggleton >> wrote: >> > On Tuesday 20 August 2013 15:51:21 Marko Lindqvist wrote: >> >> Build of qemu-native regularly fails with: >> >> | LINK sh4-softmmu/qemu-system-sh4 >> >> | >> >> | /usr/lib/x86_64-linux-gnu/libXext.so.6: undefined reference to >> >> >> >> `_XEatDataWords' >> >> >> >> | collect2: error: ld returned 1 exit status >> >> >> >> This might be some dependency missing, as building first some packets >> >> (+ more importantly their dependencies) that do not depend on qemu and >> >> only then qemu dependant image success. >> > >> > Do you have something else causing libxext-native to be built by any >> > chance? >> >> Yes, it seems to be difference between the tree where build fails and >> the one where build success that former has no libxext-native built. >> Further, I tested just building libxext-native before building >> qemu-native, and then the build succeded. > > The problem is we want qemu-native to be buildable both on systems without X11 > and systems with X11, so the dependency has to be floating, and this is more > or > less acceptable for a native recipe - there's only a problem when libxext- > native needs to be built. I can't see a lot of value in building libxext- > native in any case - what is causing it to be built on your system? > > Cheers, > Paul I'm still running more tests - this seems to be complicated matter. For one, I just got successful build from empty tree by building qemu-native directly. That was build targeted to arm, while failing builds have been for x86 (native is amd64). Also, I think (but cannot be 100% sure any more) build has succeeded on trees where nothing depends on libxext-native but still *something* was needed to be built before qemu-native. - ML ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mesa: enable additional drivers for gallium-llvm x86/x86-64
On 21/08/2013 7:09 AM, Martin Jansa wrote:
On Tue, Aug 20, 2013 at 08:41:03PM +1000, Jonathan Liu wrote:
On 20/08/2013 8:24 PM, Martin Jansa wrote:
On Tue, Aug 20, 2013 at 08:10:41PM +1000, Jonathan Liu wrote:
The additional Gallium drivers are needed for open source ATI Radeon
and NVIDIA graphics drivers.
The radeonsi and r600 drivers require LLVM 3.3 built with r600
PACKAGECONFIG so they must be explicitly enabled by adding r600 to the
mesa PACKAGECONFIG.
BTW: I just got interesting question about egl_gallium:
libEGL warning: Could not open driver /usr/lib/egl/egl_gallium.so
(libLLVM-3.3.so: cannot open shared object file: No such file or
directory)
Could not initialize egl display
EGL error
Aborted
root@qemux86:~# ls -alh /usr/lib/llvm3.3/
drwxr-xr-x2 root root1.0K Aug 20 02:47 .
drwxr-xr-x 35 root root 10.0K Aug 20 02:47 ..
-rwxr-xr-x1 root root 15.8M Aug 19 14:02 libLLVM-3.3.so
-rwxr-xr-x1 root root 78.2K Aug 19 14:02 libLTO.so
-rwxr-xr-x1 root root 10.1K Aug 19 14:02 libprofile_rt.so
I don't know yet why it worked in my tests when I was updating mesa and
llvm, but it's true that we need to make sure that mesa finds
libLLVM-3.3.so in versioned subdirectory in runtime.
LLVM has been working fine for me with llvmpipe (Intel GMA 3600 -
PowerVR-based), radeon (ATI Radeon HD5450) and nouveau (NVIDIA ION
GeForce 9400M) drivers.
There is a symbolic link in /usr/lib:
$ cd /usr/lib
$ ls -l libLLVM-3.3.so
lrwxrwxrwx 1 root root 22 Aug 19 21:03 libLLVM-3.3.so ->
llvm3.3/libLLVM-3.3.so
But this one is from llvm3.3-dev package which isn't installed by
default, isn't it in your setup?
Right. It's in llvm3.3-dev. I have been testing it in my dev image which
includes the dev packages.
It needs to be moved into the main package.
Regards,
Jonathan
I intend to submit xf86-video-ati and xf86-video-nouveau to
meta-openembedded later this week. I tested this change using those
recipes, linux-firmware (needed for ATI 3D acceleration) and the
following kernel options:
CONFIG_DRM_RADEON=m
CONFIG_DRM_RADEON_KMS=y
CONFIG_DRM_NOUVEAU=y
Regards,
Jonathan
Signed-off-by: Jonathan Liu
---
meta/recipes-graphics/mesa/mesa.inc | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 447e186..e985d67 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -50,6 +50,10 @@ PACKAGECONFIG[egl] = "--enable-egl
--with-egl-platforms=${EGL_PLATFORMS}, --disa
PACKAGECONFIG[openvg] = "--enable-openvg, --disable-openvg"
GALLIUMDRIVERS = "swrast"
+GALLIUMDRIVERS_LLVM33 = "${@base_contains('PACKAGECONFIG', 'r600', 'radeonsi,r600',
'', d)}"
+GALLIUMDRIVERS_LLVM =
"r300,svga,nouveau${@base_version_less_or_equal('MESA_LLVM_RELEASE', '3.2', '',
',${GALLIUMDRIVERS_LLVM33}', d)}"
+GALLIUMDRIVERS_append_x86 = "${@base_contains('PACKAGECONFIG', 'gallium-llvm',
',${GALLIUMDRIVERS_LLVM}', '', d)}"
+GALLIUMDRIVERS_append_x86-64 = "${@base_contains('PACKAGECONFIG', 'gallium-llvm',
',${GALLIUMDRIVERS_LLVM}', '', d)}"
# keep --with-gallium-drivers separate, because when only one of gallium
versions is enabled, other 2 were adding --without-gallium-drivers
PACKAGECONFIG[gallium] = "--with-gallium-drivers=${GALLIUMDRIVERS},
--without-gallium-drivers"
PACKAGECONFIG[gallium-egl] = "--enable-gallium-egl, --disable-gallium-egl"
--
1.8.3.4
___
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] [v2][PATCH 1/2] directfb: Upgrade to 1.6.3
Hi, On 19 Aug 2013 20:24, "Lauren Post" wrote: > > directfb: Upgrade to 1.6.3 > > [...] > delete mode 100644 meta/recipes-graphics/directfb/directfb_1.6.1.bb > create mode 100755 meta/recipes-graphics/directfb/directfb_1.6.3.bb Not sure you really wanted the mode change. Cheers, André ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-dtb: Fix compilation failure in install and deploy phases
On 08/20/2013 05:21 PM, Otavio Salvador wrote: On Tue, Aug 20, 2013 at 7:02 AM, Mike Looijmans wrote: Baking a kernel failed on the devicetree creation. This was caused by the install and deploy scripts referring to the wrong directory for the dtb files. Signed-off-by: Mike Looijmans Nack! The right fix for this has been merged already. Your patch fixes kernel > 3.8 but breaks < 3.8 kernels. The patch applied today has support for both cases. Indeed, forget my patch. Mike. Met vriendelijke groet / kind regards, Mike Looijmans TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) – (0)499 - 33.69.79 Telefax: (+31) - (0)499 - 33.69.70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen. The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] eglibc: Update SRC_URI and fix unpackaged empty dir
eglibc 2.18 has now been branched out so point to new
tarballs
Signed-off-by: Khem Raj
---
meta/recipes-core/eglibc/cross-localedef-native_2.18.bb | 6 +++---
meta/recipes-core/eglibc/eglibc-package.inc | 4
meta/recipes-core/eglibc/eglibc_2.18.bb | 6 +++---
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-core/eglibc/cross-localedef-native_2.18.bb
b/meta/recipes-core/eglibc/cross-localedef-native_2.18.bb
index 072b807..62296b5 100644
--- a/meta/recipes-core/eglibc/cross-localedef-native_2.18.bb
+++ b/meta/recipes-core/eglibc/cross-localedef-native_2.18.bb
@@ -16,11 +16,11 @@ inherit autotools
# pick up an eglibc patch
FILESPATH = "${FILE_DIRNAME}/eglibc-${PV}"
-SRC_URI = "http://sakrah.dontexist.org/files/eglibc-${PV}-svnr23532.tar.bz2 \
+SRC_URI =
"http://downloads.yoctoproject.org/releases/eglibc/eglibc-${PV}-svnr23787.tar.bz2
\
file://fix_for_centos_5.8.patch;patchdir=.. \
"
-SRC_URI[md5sum] = "8c83078851c44089a019c626d51c51bb"
-SRC_URI[sha256sum] =
"ecd3167d7d417c05b10ea7ab8e3acbc05f4bc2b389b6fae9c186bc0fd34c3ff1"
+SRC_URI[md5sum] = "b395b021422a027d89884992e91734fc"
+SRC_URI[sha256sum] =
"15f564b45dc5dd65faf0875579e3447961ae61e876933384ae05d19328539ad4"
S = "${WORKDIR}/eglibc-${PV}/localedef"
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index a590cce..1a23805 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -76,6 +76,10 @@ do_install_append () {
rm -f ${D}${sysconfdir}/localtime
rm -rf ${D}${localstatedir}
+ # remove empty eglibc dir
+ if [ -d ${D}${libdir}/eglibc ]; then
+ rmdir ${D}${libdir}/eglibc
+ fi
oe_multilib_header bits/syscall.h
if [ -f ${D}${bindir}/mtrace ]; then
diff --git a/meta/recipes-core/eglibc/eglibc_2.18.bb
b/meta/recipes-core/eglibc/eglibc_2.18.bb
index 2e1d380..17b651f 100644
--- a/meta/recipes-core/eglibc/eglibc_2.18.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.18.bb
@@ -2,7 +2,7 @@ require eglibc.inc
DEPENDS += "gperf-native kconfig-frontends-native"
-SRC_URI = "http://sakrah.dontexist.org/files/eglibc-${PV}-svnr23532.tar.bz2 \
+SRC_URI =
"http://downloads.yoctoproject.org/releases/eglibc/eglibc-${PV}-svnr23787.tar.bz2
\
file://eglibc-svn-arm-lowlevellock-include-tls.patch \
file://IO-acquire-lock-fix.patch \
file://mips-rld-map-check.patch \
@@ -27,8 +27,8 @@ SRC_URI =
"http://sakrah.dontexist.org/files/eglibc-${PV}-svnr23532.tar.bz2 \
file://0001-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch \
file://fix-tibetian-locales.patch \
"
-SRC_URI[md5sum] = "8c83078851c44089a019c626d51c51bb"
-SRC_URI[sha256sum] =
"ecd3167d7d417c05b10ea7ab8e3acbc05f4bc2b389b6fae9c186bc0fd34c3ff1"
+SRC_URI[md5sum] = "b395b021422a027d89884992e91734fc"
+SRC_URI[sha256sum] =
"15f564b45dc5dd65faf0875579e3447961ae61e876933384ae05d19328539ad4"
LIC_FILES_CHKSUM = "file://LICENSES;md5=e9a558e243b36d3209f380deb394b213 \
file://COPYING;md5=393a5ca445f6965873eca0259a17f833 \
--
1.8.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/6] openssh: add init.d/sshd status command for LSB compliance
From: Jackie Huang
Signed-off-by: Li Wang
Signed-off-by: Jackie Huang
---
.../openssh/openssh-6.2p2/init | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-connectivity/openssh/openssh-6.2p2/init
b/meta/recipes-connectivity/openssh/openssh-6.2p2/init
index 12fb79b..72c5822 100644
--- a/meta/recipes-connectivity/openssh/openssh-6.2p2/init
+++ b/meta/recipes-connectivity/openssh/openssh-6.2p2/init
@@ -1,6 +1,9 @@
#! /bin/sh
set -e
+# source function library
+. /etc/init.d/functions
+
# /etc/init.d/ssh: start and stop the OpenBSD "secure shell" daemon
test -x /usr/sbin/sshd || exit 0
@@ -54,6 +57,11 @@ check_keys() {
fi
}
+rh_status() {
+ status /usr/sbin/sshd
+ return $?
+}
+
export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"
case "$1" in
@@ -92,8 +100,12 @@ case "$1" in
echo "."
;;
+ status)
+ rh_status
+ ;;
+
*)
- echo "Usage: /etc/init.d/ssh {start|stop|reload|force-reload|restart}"
+ echo "Usage: /etc/init.d/ssh
{start|stop|status|reload|force-reload|restart}"
exit 1
esac
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/6] sysklogd: add init.d/syslog status command for LSB compliance
From: Jackie Huang
Signed-off-by: Li Wang
Signed-off-by: Jackie Huang
---
meta/recipes-extended/sysklogd/files/sysklogd | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/sysklogd/files/sysklogd
b/meta/recipes-extended/sysklogd/files/sysklogd
index dcbc81e..258f882 100755
--- a/meta/recipes-extended/sysklogd/files/sysklogd
+++ b/meta/recipes-extended/sysklogd/files/sysklogd
@@ -12,6 +12,9 @@
# Short-Description:System logger
### END INIT INFO
+# Source function library.
+. /etc/init.d/functions
+
PATH=/bin:/usr/bin:/sbin:/usr/sbin
pidfile_syslogd=/var/run/syslogd.pid
@@ -132,8 +135,16 @@ case "$1" in
$0 start
fi
;;
+ status)
+status syslogd
+RETVAL=$?
+status klogd
+rval=$?
+[ $RETVAL -eq 0 ] && exit $rval
+exit $RETVAL
+;;
*)
-log_success_msg "Usage: /etc/init.d/sysklogd
{start|stop|reload|restart|force-reload|reload-or-restart}"
+log_success_msg "Usage: /etc/init.d/sysklogd
{start|stop|reload|restart|force-reload|reload-or-restart|status}"
exit 1
esac
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/6 v2] Add status command for daemon of some packages
From: Jackie Huang v2 comments: remove stuff that doesn't related to "status" command -- The following changes since commit d98f08a7ad95d0b17846276b028a6614f16b6846: genext2fs: fix memory corruption on powerpc (2013-08-20 07:11:44 -0700) are available in the git repository at: git://git.pokylinux.org/poky-contrib jhuang0/r_status_for_daemons_0821_0 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/r_status_for_daemons_0821_0 Jackie Huang (6): sysklogd: add init.d/syslog status command for LSB compliance at: add init.d/atd status command for LSB compliance dbus: add init.d/dbus-1 status command for LSB compliance sysvinit: add init.d/bootlogd status command for LSB compliance nfs-utils: add init.d/nfsserver status command for LSB compliance openssh: add init.d/sshd status command for LSB compliance .../nfs-utils/nfs-utils/nfsserver |9 + .../openssh/openssh-6.2p2/init | 14 +- meta/recipes-core/dbus/dbus-1.6.10/dbus-1.init |9 - meta/recipes-core/sysvinit/sysvinit/bootlogd.init |9 - meta/recipes-extended/at/files/S99at | 13 - meta/recipes-extended/sysklogd/files/sysklogd | 13 - 6 files changed, 62 insertions(+), 5 deletions(-) -- 1.7.4.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/6] nfs-utils: add init.d/nfsserver status command for LSB compliance
From: Jackie Huang Signed-off-by: Li Wang Signed-off-by: Jackie Huang --- .../nfs-utils/nfs-utils/nfsserver |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver index e460e26..5b4f199 100644 --- a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver @@ -14,6 +14,8 @@ # # Startup script for nfs-utils # +# Source function library. +. /etc/init.d/functions # # The environment variable NFS_SERVERS may be set in /etc/default/nfsd # Other control variables may be overridden here too @@ -141,6 +143,13 @@ stop) exportfs -ua stop_statd stop_mountd stop_nfsd;; +status) + status /usr/sbin/rpc.mountd + RETVAL=$? + status nfsd + rval=$? + [ $RETVAL -eq 0 ] && exit $rval + exit $RETVAL;; reload)test -r /etc/exports && exportfs -r;; restart)exportfs -ua stop_mountd -- 1.7.4.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/6] at: add init.d/atd status command for LSB compliance
From: Jackie Huang
Signed-off-by: Li Wang
Signed-off-by: Jackie Huang
---
meta/recipes-extended/at/files/S99at | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/at/files/S99at
b/meta/recipes-extended/at/files/S99at
index 386f8a4..d2ba34b 100644
--- a/meta/recipes-extended/at/files/S99at
+++ b/meta/recipes-extended/at/files/S99at
@@ -5,6 +5,9 @@
umask 077
+# Source function library.
+. /etc/init.d/functions
+
start() {
echo -n "Starting atd: "
start-stop-daemon --start --quiet --pidfile /var/run/atd.pid
--background --exec /usr/sbin/atd -- -f
@@ -20,6 +23,11 @@ restart() {
start
}
+rh_status() {
+# run checks to determine if the service is running or use generic status
+status /usr/sbin/atd
+}
+
case "$1" in
start)
start
@@ -30,8 +38,11 @@ case "$1" in
restart|reload)
restart
;;
+ status)
+ rh_status
+ ;;
*)
- echo $"Usage: $0 {start|stop|restart}"
+ echo $"Usage: $0 {start|stop|restart|status}"
exit 1
esac
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/6] sysvinit: add init.d/bootlogd status command for LSB compliance
From: Jackie Huang
Signed-off-by: Li Wang
Signed-off-by: Jackie Huang
---
meta/recipes-core/sysvinit/sysvinit/bootlogd.init |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/sysvinit/sysvinit/bootlogd.init
b/meta/recipes-core/sysvinit/sysvinit/bootlogd.init
index f8f07a0..7b87827 100755
--- a/meta/recipes-core/sysvinit/sysvinit/bootlogd.init
+++ b/meta/recipes-core/sysvinit/sysvinit/bootlogd.init
@@ -13,6 +13,9 @@ DAEMON=/sbin/bootlogd
NAME=bootlogd
DESC="Bootlog daemon"
+# source function library
+. /etc/init.d/functions
+
test -f $DAEMON || exit 0
[ -r /etc/default/bootlogd ] && . /etc/default/bootlogd
@@ -73,10 +76,14 @@ case "$ACTION" in
start-stop-daemon --start --quiet --exec $DAEMON
echo "$NAME."
;;
+ status)
+ status $DAEMON
+ exit $?
+ ;;
*)
N=${0##*/}
N=${N#[SK]??}
- echo "Usage: $N {start|stop|restart|force-reload}" >&2
+ echo "Usage: $N {start|stop|status|restart|force-reload}" >&2
exit 1
;;
esac
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/6] dbus: add init.d/dbus-1 status command for LSB compliance
From: Jackie Huang
Signed-off-by: Li Wang
Signed-off-by: Jackie Huang
---
meta/recipes-core/dbus/dbus-1.6.10/dbus-1.init |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/dbus/dbus-1.6.10/dbus-1.init
b/meta/recipes-core/dbus/dbus-1.6.10/dbus-1.init
index 0351190..04025e6 100644
--- a/meta/recipes-core/dbus/dbus-1.6.10/dbus-1.init
+++ b/meta/recipes-core/dbus/dbus-1.6.10/dbus-1.init
@@ -16,6 +16,9 @@
set -e
+# Source function library.
+. /etc/init.d/functions
+
DAEMON=@bindir@/dbus-daemon
NAME=dbus
DAEMONUSER=messagebus # must match /etc/dbus-1/system.conf
@@ -99,6 +102,10 @@ case "$1" in
stop)
shut_it_down
;;
+ status)
+status $DAEMON
+exit $?
+ ;;
reload|force-reload)
reload_it
;;
@@ -108,7 +115,7 @@ case "$1" in
start_it_up
;;
*)
-echo "Usage: /etc/init.d/$NAME {start|stop|restart|reload|force-reload}"
>&2
+echo "Usage: /etc/init.d/$NAME
{start|stop|status|restart|reload|force-reload}" >&2
exit 1
;;
esac
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] insane.bbclass:WARNING: QA Issue: xxx doesn't match the [a-z0-9.+-]+ regex
Will offer the following warning when there are upper case letters in the BB
file name:
WARNING: QA Issue: xxx doesn't match the [a-z0-9.+-]+ regex
Is there such a regulation in yocto that there can't be upper case letters in
the BB file name ?
Signed-off-by: Yao Xinpan
---
meta/classes/insane.bbclass |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass index
336beaa..4042e1e 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -776,8 +776,8 @@ python do_package_qa () {
testmatrix = d.getVarFlags("QAPATHTEST")
import re
-# The package name matches the [a-z0-9.+-]+ regular expression
-pkgname_pattern = re.compile("^[a-z0-9.+-]+$")
+# The package name matches the [A-Za-z0-9.+-]+ regular expression
+pkgname_pattern = re.compile("^[A-Za-z0-9.+-]+$")
g = globals()
walk_sane = True
@@ -804,7 +804,7 @@ python do_package_qa () {
# Check package name
if not pkgname_pattern.match(package):
package_qa_handle_error("pkgname",
-"%s doesn't match the [a-z0-9.+-]+ regex\n" % package, d)
+"%s doesn't match the [A-Za-z0-9.+-]+ regex\n" %
+ package, d)
path = "%s/%s" % (pkgdest, package)
if not package_qa_walk(path, warnchecks, errorchecks, skip, package,
d):
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
