Re: [OE-core] [PATCH 5/7] pixman: updat to 0.24.4
Op 1 mrt. 2012, om 08:26 heeft Saul Wold het volgende geschreven:
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../{pixman_0.24.2.bb = pixman_0.24.4.bb} |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
rename meta/recipes-graphics/xorg-lib/{pixman_0.24.2.bb = pixman_0.24.4.bb}
(82%)
diff --git a/meta/recipes-graphics/xorg-lib/pixman_0.24.2.bb
b/meta/recipes-graphics/xorg-lib/pixman_0.24.4.bb
similarity index 82%
rename from meta/recipes-graphics/xorg-lib/pixman_0.24.2.bb
rename to meta/recipes-graphics/xorg-lib/pixman_0.24.4.bb
index c710b42..4c90ea3 100644
--- a/meta/recipes-graphics/xorg-lib/pixman_0.24.2.bb
+++ b/meta/recipes-graphics/xorg-lib/pixman_0.24.4.bb
@@ -15,10 +15,9 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=14096c769ae0cbb5fcb94ec468be11b3 \
DEPENDS += zlib libpng
PE = 1
-PR = r1
+PR = r0
Setting it to the default is bogus, no?
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] self-hosted: Fix multiple libx11 error
Op 1 mrt. 2012, om 08:46 heeft Saul Wold het volgende geschreven: From: Zhai Edwin edwin.z...@intel.com Self-hosted needs package libx11-dev, which is ambiguous as virtual/libx11 is provided by libx11 or libx11-trim. This patch explictly set the perferred one, libx11-trim-dev, to avoid this. I don't like this patch, it now forces a distro decision on a task on oe-core, which is bad. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] self-hosted-image: Create a VMDK image with correct SYSLINUX_* settings
Op 1 mrt. 2012, om 08:46 heeft Saul Wold het volgende geschreven:
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-core/images/self-hosted-image.bb | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/images/self-hosted-image.bb
b/meta/recipes-core/images/self-hosted-image.bb
index a0a7592..d56c2cb 100644
--- a/meta/recipes-core/images/self-hosted-image.bb
+++ b/meta/recipes-core/images/self-hosted-image.bb
@@ -1,11 +1,23 @@
IMAGE_INSTALL = task-core-boot task-core-apps-console task-core-ssh-openssh
task-self-hosted
+LICENSE = MIT
+LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
+
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
+
+PR = r5
AFAICT PR in images does nothing, since they are nostamp.
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] self-hosted-image: Create a VMDK image with correct SYSLINUX_* settings
On Thu, 2012-03-01 at 09:15 +0100, Koen Kooi wrote:
Op 1 mrt. 2012, om 08:46 heeft Saul Wold het volgende geschreven:
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-core/images/self-hosted-image.bb | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/images/self-hosted-image.bb
b/meta/recipes-core/images/self-hosted-image.bb
index a0a7592..d56c2cb 100644
--- a/meta/recipes-core/images/self-hosted-image.bb
+++ b/meta/recipes-core/images/self-hosted-image.bb
@@ -1,11 +1,23 @@
IMAGE_INSTALL = task-core-boot task-core-apps-console
task-core-ssh-openssh task-self-hosted
+LICENSE = MIT
+LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
+
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
+
+PR = r5
AFAICT PR in images does nothing
PR doesn't do anything
, since they are nostamp.
although with BasicHash, we could change that :)
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] insane.bbclass: fix elf.arch not matching
Hi, I am trying to built a x86_64 bit target filesystem on a 64 bit host(Ubuntu-11.10) using yocto poky framework. I encountered the same problem while compiling the kernel for my target. *WARNING: QA Issue: Architecture did not match (62 to 3) on /work/x86_64_intel-linux/linux-yocto-3.0.4+git3+d05450e4aef02c1b7137398ab3a9f8f96da74f52_5+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/packages-split/kernel-vmlinux/boot/vmlinux-3.0.4-yocto-standard-00054-g6b2c7d6 * As you can see I am using linux-yocto kernel version 3.0.4. So can you please shed some light on this issue. Thanks, JC PS: This is my first post on OE mailing list. Please direct me if I went wrong somewhere. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCHv2 2/5] bitbake.conf: remove TARGET_ARCH from in SDKPATH
On 02/25/2012 11:49 PM, Martin Jansa wrote: +SDK_NAME_PREFIX = oecore should this be weak assignment ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCHv2 2/5] bitbake.conf: remove TARGET_ARCH from in SDKPATH
On Thu, Mar 01, 2012 at 01:23:29AM -0800, Khem Raj wrote: On 02/25/2012 11:49 PM, Martin Jansa wrote: +SDK_NAME_PREFIX = oecore should this be weak assignment Yeah, probably could be (I'm not overwritting this from my distro conf so I haven't tried), but SDK_NAME assignment also wasn't weak and distros were overwritting it. Someone with custom SDK_NAME(_PREFIX) please try and send patch. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] site.conf.sample: Fix broken SOCKS proxy setup and configuration
From: Inaky Perez-Gonzalez inaky.perez-gonza...@intel.com
SOCKS proxy specification with git was using conflicting methods and
thus was failing when mixed SOCKS needs were in place (requiring no
proxy for some hosts and proxy for the rest)
- GIT_PROXY_COMMAND is an environment variable GIT uses to OVERRIDE
all proxy configuration in ~/.gitconfig or any other gitconfig. By
using it to configure, it was breaking havoc on site git
configuration or the one generated by bitbake in tmp/.
Renamed to OE_GIT_PROXY_COMMAND in meta/conf/site.conf.sample
(with a doc tidbit on the name chosen), meta/classes/base.bbclass.
- The gitconfig generated by bitbake was wrong. There was a typo error
(gitproxy vs gitProxy), thus all lines were being ignored. Fixed in
meta/classes/base.bbclass.
- The gitconfig generated was being placed in
${STAGING_DIR_NATIVE}/usr/etc/gitconfig; git was looking for it in
${STAGING_DIR_NATIVE}/etc/gitconfig. Fixed that in
meta/classes/base.bbclass, at the same time creating a
GIT_CONFIG_PATH variable, since it is also referenced in
generate_git_config() and have all instances refer to that.
Signed-off-by: Inaky Perez-Gonzalez inaky.perez-gonza...@intel.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/classes/base.bbclass |9 +
meta/conf/site.conf.sample | 16
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index e80e874..a76fe55 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -111,16 +111,17 @@ python base_do_unpack() {
raise bb.build.FuncFailed(e)
}
-GIT_CONFIG = ${STAGING_DIR_NATIVE}/usr/etc/gitconfig
+GIT_CONFIG_PATH = ${STAGING_DIR_NATIVE}/etc
+GIT_CONFIG = ${GIT_CONFIG_PATH}/gitconfig
def generate_git_config(e):
from bb import data
if data.getVar('GIT_CORE_CONFIG', e.data, True):
gitconfig_path = e.data.getVar('GIT_CONFIG', True)
-proxy_command = gitproxy = %s\n %
data.getVar('GIT_PROXY_COMMAND', e.data, True)
+proxy_command = gitProxy = %s\n %
data.getVar('OE_GIT_PROXY_COMMAND', e.data, True)
-bb.mkdirhier(bb.data.expand(${STAGING_DIR_NATIVE}/usr/etc/,
e.data))
+bb.mkdirhier(bb.data.expand(${GIT_CONFIG_PATH}, e.data))
if (os.path.exists(gitconfig_path)):
os.remove(gitconfig_path)
@@ -128,7 +129,7 @@ def generate_git_config(e):
f.write([core]\n)
ignore_hosts = data.getVar('GIT_PROXY_IGNORE', e.data,
True).split()
for ignore_host in ignore_hosts:
-f.write(gitproxy = none for %s\n % ignore_host)
+f.write(gitProxy = none for %s\n % ignore_host)
f.write(proxy_command)
f.close
diff --git a/meta/conf/site.conf.sample b/meta/conf/site.conf.sample
index d438298..68d1da9 100644
--- a/meta/conf/site.conf.sample
+++ b/meta/conf/site.conf.sample
@@ -22,17 +22,25 @@ SCONF_VERSION = 1
#GIT_PROXY_PORT = 81
#export GIT_PROXY_COMMAND = ${COREBASE}/scripts/oe-git-proxy-command
-# GIT_PROXY_IGNORE_* lines define hosts which do not require a proxy to access
+# Set to yes to have a gitconfig generated for handling proxies; you
+# might not want this if you have all that set in your global git
+# configuration. If you don't enable it, the rest of the entries
+# (_PROXY_IGNORE, etc) don't really work that well
#GIT_CORE_CONFIG = Yes
-#GIT_PROXY_IGNORE_1 = host.server.com
-#GIT_PROXY_IGNORE_2 = another.server.com
+
+# Space separate list of hosts to ignore for GIT proxy
+#GIT_PROXY_IGNORE = host.server.com another.server.com
# If SOCKS is available run the following command to comple a simple transport
# gcc scripts/oe-git-proxy-socks.c -o oe-git-proxy-socks
# and then share that binary somewhere in PATH, then use the following settings
#GIT_PROXY_HOST = proxy.example.com
#GIT_PROXY_PORT = 81
-#export GIT_PROXY_COMMAND = ${COREBASE}/scripts/oe-git-proxy-socks-command
+
+# GIT_PROXY_COMMAND is used by git to override all proxy settings from
+# configuration files, so we prefix OE_ to avoid breaking havoc on the
+# generated (or local) gitconfig's.
+#OE_GIT_PROXY_COMMAND = ${COREBASE}/scripts/oe-git-proxy-socks-command
# Uncomment this to use a shared download directory
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gdk-pixbuf: Pick up ${NM} from the environment.
On 02/27/2012 11:36 PM, James Limbouris wrote:
Signed-off-by: James Limbouris ja...@digitalmatter.com.au
---
.../gdk-pixbuf-2.24.0/configure_nm.patch | 19 +++
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.0.bb |3 ++-
2 files changed, 21 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.24.0/configure_nm.patch
diff --git
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.24.0/configure_nm.patch
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.24.0/configure_nm.patch
new file mode 100644
index 000..1697967
--- /dev/null
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.24.0/configure_nm.patch
@@ -0,0 +1,19 @@
+At this stage of configure, ${NM} has already been correctly set.
+This AC_PATH_PROG overwrites the correct path with a host path.
+
+Upstream-Status: Inappropriate [configuration]
+Signed-off-by: James Limbouris ja...@digitalmatter.com.au
+
+Index: gdk-pixbuf-2.24.0/configure.ac
+===
+diff -uNr gdk-pixbuf-2.24.0/configure.ac gdk-pixbuf-2.24.0.mod/configure.ac
+--- gdk-pixbuf-2.24.0/configure.ac 2011-08-27 11:27:52.0 +0800
gdk-pixbuf-2.24.0.mod/configure.ac 2012-02-28 14:48:36.481126410
+0800
+@@ -147,7 +147,6 @@
+ AC_SYS_LARGEFILE
+
+ AM_PROG_AS
+-AC_PATH_PROG(NM, nm, nm)
you could use AC_CHECK_TOOLS(NM, [$NM nm], nm)
here instead of deleting it
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] insane.bbclass: fix elf.arch not matching
On 03/01/2012 01:04 AM, Jegan Chandru wrote: Hi, I am trying to built a x86_64 bit target filesystem on a 64 bit host(Ubuntu-11.10) using yocto poky framework. I encountered the same problem while compiling the kernel for my target. /WARNING: QA Issue: Architecture did not match (62 to 3) on /work/x86_64_intel-linux/linux-yocto-3.0.4+git3+d05450e4aef02c1b7137398ab3a9f8f96da74f52_5+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/packages-split/kernel-vmlinux/boot/vmlinux-3.0.4-yocto-standard-00054-g6b2c7d6/ As you can see I am using linux-yocto kernel version 3.0.4. So can you please shed some light on this issue. Do you have the commit you replied to in your tree ? commit 74686edafa241839d3880e06740ee7450ff94fd8 Author: Nitin A Kamble nitin.a.kam...@intel.com Date: Tue Jan 10 17:33:31 2012 -0800 insane.bbclass: fix elf.arch not matching error for x32 kernel For x32 the user space is 32bit and the kernel is 64bit. So the elf.arch for vmlinuz is x86_64 and not x86. This commit fixes this QA error thrown for x32 kernel. | ERROR: QA Issue: Architecture did not match (62 to 3) on /work/qemux86_64-poky-linux-gnux32/linux-korg-3.1+git1+e2bf8464ddbf5da24d3d320cded5691828a91a0b-r1/packages-split/kernel-vmlinux/boot/vmlinux-3.1.0-yocto-standard-01628-ge2b Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com Thanks, JC PS: This is my first post on OE mailing list. Please direct me if I went wrong somewhere. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] psuedo-native strangeness on 64 bit build machine
On 02/29/2012 07:12 AM, Steve Sakoman wrote: On Wed, Feb 29, 2012 at 6:22 AM, Steve Sakoman sako...@gmail.com wrote: On Wed, Feb 29, 2012 at 12:45 AM, Petr Štetiar yn...@true.cz wrote: Now it's impossible to finish the build, the most noticeable failure is gcc, which fails for me in patching task due to the parallel build settings. Changing the parallel settings back to 1 helps here also. I just tried building gcc and can confirm that it fails for me on the 64 bit build machine. For me, a -c cleansstate gcc and then a rebuild resulted in a successful gcc build. I did not need to turn off parallel builds. just add NO32LIBS = 1 to your local.conf Steve ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] libx11-1.4.4: Add patch makekeys_crosscompile.patch
Am Donnerstag, den 01.03.2012, 14:14 +0800 schrieb Xiaofeng Yan: On 2012年02月09日 17:06, Paul Menzel wrote: Am Donnerstag, den 09.02.2012, 16:05 +0800 schrieb Xiaofeng Yan: From: Xiaofeng Yanxiaofeng@windriver.com LSB 4.1 complain a host contamination error from libx11 because of absent patch makekeys_crosscompile.patch from libx11-trim-1.4.4. [YOCTO #1970] could you squash both patches please? Also please add the output from the cover letter to the commit message. Signed-off-by: Xiaofeng Yanxiaofeng@windriver.com I just noticed. Your Thunderbird setup seems to be broken. For some reason it deletes spaces. --- .../libx11-1.4.4/makekeys_crosscompile.patch | 45 1 files changed, 45 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-graphics/xorg-lib/libx11-1.4.4/makekeys_crosscompile.patch diff --git a/meta/recipes-graphics/xorg-lib/libx11-1.4.4/makekeys_crosscompile.patch b/meta/recipes-graphics/xorg-lib/libx11-1.4.4/makekeys_crosscompile.patch Here Thunderbird removed a line break. new file mode 100644 index 000..e5eacf0 --- /dev/null +++ b/meta/recipes-graphics/xorg-lib/libx11-1.4.4/makekeys_crosscompile.patch @@ -0,0 +1,45 @@ +Because the size of unsigned long is different between 32-bit +and 64-bit, judge whether target is 32-bit or 64-bit and tell +makekey. Trailing space at the end. Could you also add the error message to the patch file in a *separate* patch please. Preferably before copying it. Do you mean I use an separated file to record error message? So there are two file here. one is for makekeys_crosscompile.patch, another is for a file to record error message. right? Sorry, I did not understand your reply either. :/ 1. Copy the error message you got when building without the patch. 2. Go to meta/recipes-graphics/xorg-lib/libx11-trim-1.4.4/makekeys_crosscompile.patch and add that error message to the commit message of the patch above. Make that the first patch. 3. Now copy this file to libx11-1.4.4 and submit as a second patch. + +Upstream-Status: Pending + +Signed-off-by: dbuit...@windriver.com + +--- libX11-1.3.4.orig/src/util/makekeys.c 2010-01-15 09:11:36.0 +0800 libX11-1.3.4/src/util/makekeys.c 2011-05-24 19:04:25.454774908 +0800 […] Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libx11-trim/diet: Add RPROVIDES for libx11-dev
We have things that depend on libx11-dev, this patch ensures the -trim
and -diet versions provide it. This resolves some multiple providers
warnings.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
Koen/Saul: This is how I think we should be fixing the libx11 issues...
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet_1.4.4.bb
b/meta/recipes-graphics/xorg-lib/libx11-diet_1.4.4.bb
index 6106986..4bab148 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet_1.4.4.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet_1.4.4.bb
@@ -14,6 +14,7 @@ SRC_URI += file://x11_disable_makekeys.patch \
file://fix-utf8-wrong-define.patch \
+RPROVIDES_${PN}-dev = libx11-dev
SRC_URI[md5sum] = ed7c382cbf8c13425b6a66bcac0ca5d9
SRC_URI[sha256sum] =
7fe62180f08ef5f0a0062fb444591e349cae2ab5af6ad834599f5c654e6c840d
diff --git a/meta/recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb
b/meta/recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb
index 3fd5d82..b2c753d 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb
@@ -5,7 +5,7 @@ DESCRIPTION += Support for XCMS is disabled in this version.
LICENSE = MIT MIT-style BSD
LIC_FILES_CHKSUM = file://COPYING;md5=172255dee66bb0151435b2d5d709fcf7
-PR = r0
+PR = r1
DEPENDS += libxcb xproto xextproto xtrans libxau kbproto inputproto
xf86bigfontproto xproto-native
@@ -13,6 +13,7 @@ SRC_URI += file://x11_disable_makekeys.patch \
file://keysymdef_include.patch \
file://makekeys_crosscompile.patch
+RPROVIDES_${PN}-dev = libx11-dev
SRC_URI[md5sum] = ed7c382cbf8c13425b6a66bcac0ca5d9
SRC_URI[sha256sum] =
7fe62180f08ef5f0a0062fb444591e349cae2ab5af6ad834599f5c654e6c840d
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libx11-trim: Drop obsolete 1.3.4 version
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-graphics/xorg-lib/libx11-trim-1.3.4/include_fix.patch
b/meta/recipes-graphics/xorg-lib/libx11-trim-1.3.4/include_fix.patch
deleted file mode 100644
index eeb4175..000
--- a/meta/recipes-graphics/xorg-lib/libx11-trim-1.3.4/include_fix.patch
+++ b/dev/null
@@ -1,21 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
- configure.ac |6 +++---
- 1 file changed, 3 insertions(+), 3 deletions(-)
-
libX11-1.3.4.orig/configure.ac
-+++ libX11-1.3.4/configure.ac
-@@ -353,9 +353,9 @@
- #
- # Find keysymdef.h
- #
--AC_MSG_CHECKING([keysymdef.h])
--dir=`$PKG_CONFIG --variable=includedir xproto`
--KEYSYMDEF=$dir/X11/keysymdef.h
-+AC_ARG_WITH(keysymdef,
-+ AC_HELP_STRING([--with-keysymdef=DIR/keysymdef.h], [The location of
keysymdef.h]),
-+ KEYSYMDEF=$withval, KEYSYMDEF=)
- if test -f $KEYSYMDEF; then
- AC_MSG_RESULT([$KEYSYMDEF])
- else
diff --git
a/meta/recipes-graphics/xorg-lib/libx11-trim-1.3.4/makekeys_crosscompile.patch
b/meta/recipes-graphics/xorg-lib/libx11-trim-1.3.4/makekeys_crosscompile.patch
deleted file mode 100644
index e5eacf0..000
---
a/meta/recipes-graphics/xorg-lib/libx11-trim-1.3.4/makekeys_crosscompile.patch
+++ b/dev/null
@@ -1,45 +0,0 @@
-Because the size of unsigned long is different between 32-bit
-and 64-bit, judge whether target is 32-bit or 64-bit and tell
-makekey.
-
-Upstream-Status: Pending
-
-Signed-off-by: dbuit...@windriver.com
-
libX11-1.3.4.orig/src/util/makekeys.c 2010-01-15 09:11:36.0
+0800
-+++ libX11-1.3.4/src/util/makekeys.c 2011-05-24 19:04:25.454774908 +0800
-@@ -33,6 +33,7 @@
- #include X11/keysymdef.h
- #include stdio.h
- #include stdlib.h
-+#include stdint.h
-
- typedef unsigned long Signature;
-
-@@ -124,7 +125,12 @@
- name = info[i].name;
- sig = 0;
- while ((c = *name++))
-- sig = (sig 1) + c;
-+#ifdef USE32
-+ sig = (uint32_t)(sig 1) + c;
-+#else
-+ sig = (uint64_t)(sig 1) + c;
-+#endif
-+
- first = j = sig % z;
- for (k = 0; tab[j]; k++) {
- j += first + 1;
-@@ -163,7 +169,11 @@
- name = info[i].name;
- sig = 0;
- while ((c = *name++))
-- sig = (sig 1) + c;
-+#ifdef USE32
-+ sig = (uint32_t)(sig 1) + c;
-+#else
-+ sig = (uint64_t)(sig 1) + c;
-+#endif
- first = j = sig % z;
- while (offsets[j]) {
- j += first + 1;
diff --git a/meta/recipes-graphics/xorg-lib/libx11-trim-1.3.4/nodolt.patch
b/meta/recipes-graphics/xorg-lib/libx11-trim-1.3.4/nodolt.patch
deleted file mode 100644
index bf6c7d5..000
--- a/meta/recipes-graphics/xorg-lib/libx11-trim-1.3.4/nodolt.patch
+++ b/dev/null
@@ -1,12 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
libX11-1.3.4.orig/configure.ac
-+++ libX11-1.3.4/configure.ac
-@@ -32,7 +32,6 @@
-
- # Checks for programs.
- AC_PROG_LIBTOOL
--DOLT
- AC_PROG_CC
- PKG_PROG_PKG_CONFIG
-
diff --git
a/meta/recipes-graphics/xorg-lib/libx11-trim-1.3.4/x11_disable_makekeys.patch
b/meta/recipes-graphics/xorg-lib/libx11-trim-1.3.4/x11_disable_makekeys.patch
deleted file mode 100644
index 561b577..000
---
a/meta/recipes-graphics/xorg-lib/libx11-trim-1.3.4/x11_disable_makekeys.patch
+++ b/dev/null
@@ -1,33 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
- src/util/Makefile.am | 21 -
- 1 file changed, 21 deletions(-)
-
libX11-1.3.4.orig/src/util/Makefile.am
-+++ libX11-1.3.4/src/util/Makefile.am
-@@ -1,24 +1,3 @@
-
--noinst_PROGRAMS=makekeys
--
--makekeys_CFLAGS = \
-- $(X11_CFLAGS) \
-- $(CWARNFLAGS)
--
--CC = @CC_FOR_BUILD@
--CPPFLAGS = @CPPFLAGS_FOR_BUILD@
--CFLAGS = @CFLAGS_FOR_BUILD@
--LDFLAGS = @LDFLAGS_FOR_BUILD@
--
- EXTRA_DIST = mkks.sh
-
--if LINT
--# Check source code with tools like lint sparse
--
--ALL_LINT_FLAGS=$(LINT_FLAGS) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
-- $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS)
--
--lint:
-- $(LINT) $(ALL_LINT_FLAGS) makekeys.c
--
--endif LINT
diff --git a/meta/recipes-graphics/xorg-lib/libx11-trim_1.3.4.bb
b/meta/recipes-graphics/xorg-lib/libx11-trim_1.3.4.bb
deleted file mode 100644
index 3a8f2c4..000
--- a/meta/recipes-graphics/xorg-lib/libx11-trim_1.3.4.bb
+++ b/dev/null
@@ -1,20 +0,0 @@
-require libx11.inc
-
-DESCRIPTION += Support for XCB, and XCMS is disabled in this version.
-
-LICENSE = MIT MIT-style BSD
-LIC_FILES_CHKSUM = file://COPYING;md5=bf75bfe4d05068311b5e6862d4b5f2c5
-
-PR = r2
-
-DEPENDS += libxcb xproto xextproto xtrans libxau kbproto inputproto
xf86bigfontproto xproto-native
-
-SRC_URI += file://x11_disable_makekeys.patch \
-file://include_fix.patch \
-file://nodolt.patch \
-file://makekeys_crosscompile.patch
-
-SRC_URI[md5sum] = f65c9c7ecbfb64c19dbd7927160d63fd
-SRC_URI[sha256sum] =
Re: [OE-core] [PATCH] libx11-trim/diet: Add RPROVIDES for libx11-dev
On Thu, Mar 01, 2012 at 11:55:16AM +, Richard Purdie wrote:
We have things that depend on libx11-dev, this patch ensures the -trim
and -diet versions provide it. This resolves some multiple providers
warnings.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
It's probably fine now as only libx11_1.4.4.bb has
BBCLASSEXTENDS = nativesdk native
but can we use RPROVIDES_${BPN}-dev = libx11-dev
?
Cheers,
---
Koen/Saul: This is how I think we should be fixing the libx11 issues...
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet_1.4.4.bb
b/meta/recipes-graphics/xorg-lib/libx11-diet_1.4.4.bb
index 6106986..4bab148 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet_1.4.4.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet_1.4.4.bb
@@ -14,6 +14,7 @@ SRC_URI += file://x11_disable_makekeys.patch \
file://fix-utf8-wrong-define.patch \
+RPROVIDES_${PN}-dev = libx11-dev
SRC_URI[md5sum] = ed7c382cbf8c13425b6a66bcac0ca5d9
SRC_URI[sha256sum] =
7fe62180f08ef5f0a0062fb444591e349cae2ab5af6ad834599f5c654e6c840d
diff --git a/meta/recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb
b/meta/recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb
index 3fd5d82..b2c753d 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb
@@ -5,7 +5,7 @@ DESCRIPTION += Support for XCMS is disabled in this
version.
LICENSE = MIT MIT-style BSD
LIC_FILES_CHKSUM = file://COPYING;md5=172255dee66bb0151435b2d5d709fcf7
-PR = r0
+PR = r1
DEPENDS += libxcb xproto xextproto xtrans libxau kbproto inputproto
xf86bigfontproto xproto-native
@@ -13,6 +13,7 @@ SRC_URI += file://x11_disable_makekeys.patch \
file://keysymdef_include.patch \
file://makekeys_crosscompile.patch
+RPROVIDES_${PN}-dev = libx11-dev
SRC_URI[md5sum] = ed7c382cbf8c13425b6a66bcac0ca5d9
SRC_URI[sha256sum] =
7fe62180f08ef5f0a0062fb444591e349cae2ab5af6ad834599f5c654e6c840d
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/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.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libx11-trim/diet: Add RPROVIDES for libx11-dev
Op 1 mrt. 2012, om 12:55 heeft Richard Purdie het volgende geschreven: We have things that depend on libx11-dev, this patch ensures the -trim and -diet versions provide it. This resolves some multiple providers warnings. Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- Koen/Saul: This is how I think we should be fixing the libx11 issues... I'm going to say something shockingly out of character: I think the trim/diet/normal seperation should be done with DISTRO_FEATURES + PACKAGECONFIG. Due to shlib naming the 3 recipes cannot coexist in the feeds anyway. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] multiple kernel builds
Hi, all! How could I achieve multiple kernel packages builds in single build? I need multiple kernel configurations for single hardware (which will live in single build and booted on request). So I need to put 2 uImages on one ubifs partition or different mtd partitions, which is ok. But I need to build both in single run. Any ideas? Thanks a lot, S. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libx11-trim/diet: Add RPROVIDES for libx11-dev
On Thu, 2012-03-01 at 13:11 +0100, Koen Kooi wrote: Op 1 mrt. 2012, om 12:55 heeft Richard Purdie het volgende geschreven: We have things that depend on libx11-dev, this patch ensures the -trim and -diet versions provide it. This resolves some multiple providers warnings. Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- Koen/Saul: This is how I think we should be fixing the libx11 issues... I'm going to say something shockingly out of character: I think the trim/diet/normal seperation should be done with DISTRO_FEATURES + PACKAGECONFIG. Due to shlib naming the 3 recipes cannot coexist in the feeds anyway. I agree although in this case, PACKAGECONFIG should be enough. I propose we fix the immediate problem as per the patch and then look at converting to PACKAGECONFIG. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libx11-trim/diet: Add RPROVIDES for libx11-dev
Op 1 mrt. 2012, om 13:50 heeft Richard Purdie het volgende geschreven: On Thu, 2012-03-01 at 13:11 +0100, Koen Kooi wrote: Op 1 mrt. 2012, om 12:55 heeft Richard Purdie het volgende geschreven: We have things that depend on libx11-dev, this patch ensures the -trim and -diet versions provide it. This resolves some multiple providers warnings. Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- Koen/Saul: This is how I think we should be fixing the libx11 issues... I'm going to say something shockingly out of character: I think the trim/diet/normal seperation should be done with DISTRO_FEATURES + PACKAGECONFIG. Due to shlib naming the 3 recipes cannot coexist in the feeds anyway. I agree although in this case, PACKAGECONFIG should be enough. I propose we fix the immediate problem as per the patch and then look at converting to PACKAGECONFIG. Agreed. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] multiple kernel builds
Op 1 mrt. 2012, om 13:50 heeft Sergey Lapin het volgende geschreven: Hi, all! How could I achieve multiple kernel packages builds in single build? I need multiple kernel configurations for single hardware (which will live in single build and booted on request). So I need to put 2 uImages on one ubifs partition or different mtd partitions, which is ok. But I need to build both in single run. Any ideas? Have a look at multi-kernel.inc in meta-ti. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Porting KDE Plasma Active (WIP)
Just to let you know that I'm still working on this. The git repository (at [1]) shows what was currently done, since kdelibs builds now it could be possible to port other programs that depend on it. The good and the bad news: Good: * Most things will compile and install * Workarounds should be easy to understand Bad: * There are workarounds for cruel hard-coded where to find and install strings in CMake files * My popularity as KDE developer decreases every time I ask Why does package XYZ installs it's CMake files into the libdir? * ^ Of course this is a joke, but some really do.. * The user has to install kdelibsX-dev (X is either version 4 or 5) since KDE (like Koen already stated) needs to execute KDE/Qt programs that depend on the whole KDE stack again in a native flavor. About the current status: The main dependency kdelibs builds but in do_package there is a ominous QA error: ERROR: QA Issue: kdelibs4 rdepends on kdelibs4-dev Since this error message is important, it will not help (me) much to resolve the error. In other words is there any way to debug this? Plasma Acttve builds now. And if the kdelibs QA error is resolved it should be possible to build an image and test it (hopefully). There might be some missing DEPENDS entries and the TODO has also some lines left, but my current priority is to debug the QA error. [1] https://gitorious.org/openembedded-core-layers/meta-kde -- Regards Samuel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Porting KDE Plasma Active (WIP)
Op 1 mrt. 2012, om 14:24 heeft Samuel Stirtzel het volgende geschreven: Just to let you know that I'm still working on this. The git repository (at [1]) shows what was currently done, since kdelibs builds now it could be possible to port other programs that depend on it. The good and the bad news: Good: * Most things will compile and install * Workarounds should be easy to understand Bad: * There are workarounds for cruel hard-coded where to find and install strings in CMake files * My popularity as KDE developer decreases every time I ask Why does package XYZ installs it's CMake files into the libdir? * ^ Of course this is a joke, but some really do.. * The user has to install kdelibsX-dev (X is either version 4 or 5) since KDE (like Koen already stated) needs to execute KDE/Qt programs that depend on the whole KDE stack again in a native flavor. Can we just build them natively and put them in the host sysroot? About the current status: The main dependency kdelibs builds but in do_package there is a ominous QA error: ERROR: QA Issue: kdelibs4 rdepends on kdelibs4-dev Since this error message is important, it will not help (me) much to resolve the error. In other words is there any way to debug this? No testlab in oe-core, but buildhistory pretty much does the same: http://dominion.thruhere.net/koen/cms/the-testlab-strikes-again regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Porting KDE Plasma Active (WIP)
2012/3/1 Koen Kooi k...@dominion.thruhere.net: * The user has to install kdelibsX-dev (X is either version 4 or 5) since KDE (like Koen already stated) needs to execute KDE/Qt programs that depend on the whole KDE stack again in a native flavor. Can we just build them natively and put them in the host sysroot? Short answer: Yes but not with Qt-native from OE. Long answer: For automoc4 this is no problem and meta-kde also got the recipe. For the packages kconfig_compiler (needs libkdecore) and makekdewidgets (needs libkdecore and libkdeui) it might work, as long as the programs got their libraries. Since building kdelibs native in OpenEmbedded would need a full featured Qt-native and the other dependencies it would cause a lot overhead. Building libkdecore and kconfig_compiler alone works, but libkdeui pulls everything else in. The paths where KDE looks for the executables can be altered at the kde4.inc file (see [1] ) About the current status: The main dependency kdelibs builds but in do_package there is a ominous QA error: ERROR: QA Issue: kdelibs4 rdepends on kdelibs4-dev Since this error message is important, it will not help (me) much to resolve the error. In other words is there any way to debug this? No testlab in oe-core, but buildhistory pretty much does the same: http://dominion.thruhere.net/koen/cms/the-testlab-strikes-again Thanks, I will look into that. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core [1] https://gitorious.org/openembedded-core-layers/meta-kde/blobs/ea8f4cbc56b985708c33230a981ae9169e7fb156/recipes/kde4.inc#line67 -- Regards Samuel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] psuedo-native strangeness on 64 bit build machine
On Thu, Mar 1, 2012 at 2:33 AM, Khem Raj raj.k...@gmail.com wrote: On 02/29/2012 07:12 AM, Steve Sakoman wrote: On Wed, Feb 29, 2012 at 6:22 AM, Steve Sakoman sako...@gmail.com wrote: On Wed, Feb 29, 2012 at 12:45 AM, Petr Štetiar yn...@true.cz wrote: Now it's impossible to finish the build, the most noticeable failure is gcc, which fails for me in patching task due to the parallel build settings. Changing the parallel settings back to 1 helps here also. I just tried building gcc and can confirm that it fails for me on the 64 bit build machine. For me, a -c cleansstate gcc and then a rebuild resulted in a successful gcc build. I did not need to turn off parallel builds. just add NO32LIBS = 1 to your local.conf I can do that, but I'm still a bit confused why a clean build succeeds, but a rebuild triggered by sstate hash fails with the 32 bit lib issue. Is this another case of a flawed recipe (like wpa-supplicant) that can't be rerun because it modifies $S? Steve ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Porting KDE Plasma Active (WIP)
On Thursday 01 March 2012 15:15:11 Samuel Stirtzel wrote: For the packages kconfig_compiler (needs libkdecore) and makekdewidgets (needs libkdecore and libkdeui) it might work, as long as the programs got their libraries. Since building kdelibs native in OpenEmbedded would need a full featured Qt-native and the other dependencies it would cause a lot overhead. Building libkdecore and kconfig_compiler alone works, but libkdeui pulls everything else in. Ouch :( I can imagine trying to break these up would be quite tricky. Perhaps it's something we have to live with for the time being. If we do rely on external executables, then we should check and error out as early as possible if the required executables don't exist. No testlab in oe-core, but buildhistory pretty much does the same: http://dominion.thruhere.net/koen/cms/the-testlab-strikes-again Thanks, I will look into that. FYI there's very basic documentation for buildhistory here: http://wiki.yoctoproject.org/wiki/Buildhistory Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] Buildhistory, was Re: do rootfs does not create log files
On Thu, Mar 1, 2012 at 3:31 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Thursday 01 March 2012 13:38:04 Andreas Müller wrote: Would it be big effort to have the package scripts (pre-/postinst, postrm) handled by buildhistory? Do you mean you would like the contents of the scripts recorded in buildhistory? Yes that's what I meant :) If so, I guess this is possible; if we just output each script to a separate file I don't think it should be too difficult. Making it work nicely if you switch back to the old (symlinked) mode would be an extra trick, though I'm starting to wonder if that's worth continuing to support. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] initscripts: Properly handle new timestamp format
On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote: Recent changes have attempted to make consistant use of /etc/timestamp In particular 5aab665 initscripts: Make /etc/timestamp consistent again. 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes This new format can cause problems as the value is too large for most [32 bit] machines. Work around this by only comparing the MMDD portion (which does fit in 32 bits). Also, the new format is not directly compatible with the 'date' command line, so it must be reformatted for use. Signed-off-by: Gary Thomas g...@mlbassoc.com --- .../initscripts/initscripts-1.0/bootmisc.sh|4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) I merged the changes to busybox in relation to this. Is this patch still needed? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] initscripts: Properly handle new timestamp format
On 2012-03-01 07:59, Richard Purdie wrote: On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote: Recent changes have attempted to make consistant use of /etc/timestamp In particular 5aab665 initscripts: Make /etc/timestamp consistent again. 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes This new format can cause problems as the value is too large for most [32 bit] machines. Work around this by only comparing the MMDD portion (which does fit in 32 bits). Also, the new format is not directly compatible with the 'date' command line, so it must be reformatted for use. Signed-off-by: Gary Thomasg...@mlbassoc.com --- .../initscripts/initscripts-1.0/bootmisc.sh|4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) I merged the changes to busybox in relation to this. Is this patch still needed? Let me check - I didn't see the related busybox change. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] initscripts: Properly handle new timestamp format
On 2012-03-01 08:11, Gary Thomas wrote: On 2012-03-01 07:59, Richard Purdie wrote: On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote: Recent changes have attempted to make consistant use of /etc/timestamp In particular 5aab665 initscripts: Make /etc/timestamp consistent again. 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes This new format can cause problems as the value is too large for most [32 bit] machines. Work around this by only comparing the MMDD portion (which does fit in 32 bits). Also, the new format is not directly compatible with the 'date' command line, so it must be reformatted for use. Signed-off-by: Gary Thomasg...@mlbassoc.com --- .../initscripts/initscripts-1.0/bootmisc.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) I merged the changes to busybox in relation to this. Is this patch still needed? Let me check - I didn't see the related busybox change. I missed the busybox change because there was no PR bump :-( The problem with the change turning off CONFIG_FEATURE_DATE_COMPAT is that now 'date' from busybox works one way and 'date' from coreutils works another. Using coreutils: root@cobra8148p81:~# date 201203011520 date: invalid date `201203011520' root@cobra8148p81:~# date 030115202012 Thu Mar 1 15:20:00 UTC 2012 root@cobra8148p81:~# ls -l /bin/date lrwxrwxrwx 1 root root 14 Mar 1 15:14 /bin/date - date.coreutils Using busybox: root@cobra8148p81:~# ln -s /bin/busybox /tmp/date root@cobra8148p81:~# /tmp/date 201203011520 Thu Mar 1 15:20:00 UTC 2012 I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back on along with my reformatting change. I can make an updated patch if you agree. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] image_types.bbclass: fix link creation failure if the target already exists
On Wed, 2012-02-29 at 21:33 +0100, Petr Štetiar wrote: | ln: failed to create symbolic link `beagleboard/systemd-image-beagleboard.tar.bz2': File exists NOTE: package systemd-image-1.0-r0: task do_rootfs: Failed Signed-off-by: Petr Štetiar yn...@true.cz --- meta/classes/image_types.bbclass |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Is this still necessary after the recent image_types.bbclass fixes? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] initscripts: Properly handle new timestamp format
On 2012-03-01 08:44, Richard Purdie wrote: On Thu, 2012-03-01 at 08:27 -0700, Gary Thomas wrote: On 2012-03-01 08:11, Gary Thomas wrote: On 2012-03-01 07:59, Richard Purdie wrote: On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote: Recent changes have attempted to make consistant use of /etc/timestamp In particular 5aab665 initscripts: Make /etc/timestamp consistent again. 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes This new format can cause problems as the value is too large for most [32 bit] machines. Work around this by only comparing the MMDD portion (which does fit in 32 bits). Also, the new format is not directly compatible with the 'date' command line, so it must be reformatted for use. Signed-off-by: Gary Thomasg...@mlbassoc.com --- .../initscripts/initscripts-1.0/bootmisc.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) I merged the changes to busybox in relation to this. Is this patch still needed? Let me check - I didn't see the related busybox change. I missed the busybox change because there was no PR bump :-( The problem with the change turning off CONFIG_FEATURE_DATE_COMPAT is that now 'date' from busybox works one way and 'date' from coreutils works another. Using coreutils: root@cobra8148p81:~# date 201203011520 date: invalid date `201203011520' root@cobra8148p81:~# date 030115202012 Thu Mar 1 15:20:00 UTC 2012 root@cobra8148p81:~# ls -l /bin/date lrwxrwxrwx 1 root root 14 Mar 1 15:14 /bin/date - date.coreutils Using busybox: root@cobra8148p81:~# ln -s /bin/busybox /tmp/date root@cobra8148p81:~# /tmp/date 201203011520 Thu Mar 1 15:20:00 UTC 2012 I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back on along with my reformatting change. I can make an updated patch if you agree. Is this going to cause us a problem in real world usage? I'd hope in the general case we use standard formatting? I have to admit I'm getting more than a little frustrated with what seems like a continual set of changes bouncing this format around in different directions :(. I agree and I'm sorry I missed this in my first change - I was just trying to make the time stamps be consistent. As far as I can recall (which is a really long time), 'date' has always wanted the format MMDDHHmm[], so I think that's what we should expect. That format doesn't compare easily which is why the timestamp was changed (not by me) to a more ISO standard MMDDHHmm. If busybox has 64-bit math enabled, then this can be compared with no problems, it just has to be munged into the format 'date' wants. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] initscripts: Properly handle new timestamp format
On Thu, Mar 1, 2012 at 12:27, Gary Thomas g...@mlbassoc.com wrote: I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back on along with my reformatting change. I can make an updated patch if you agree. This is indeed the better solution. Please send an updated patch in meanwhile so Richard can apply it once he has some time and restore the right behavior. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] initscripts: Properly handle new timestamp format
On 2012-03-01 09:04, Otavio Salvador wrote: On Thu, Mar 1, 2012 at 12:52, Gary Thomasg...@mlbassoc.com wrote: On 2012-03-01 08:44, Richard Purdie wrote: Is this going to cause us a problem in real world usage? I'd hope in the general case we use standard formatting? I have to admit I'm getting more than a little frustrated with what seems like a continual set of changes bouncing this format around in different directions :(. I agree and I'm sorry I missed this in my first change - I was just trying to make the time stamps be consistent. As far as I can recall (which is a really long time), 'date' has always wanted the format MMDDHHmm[], so I think that's what we should expect. That format doesn't compare easily which is why the timestamp was changed (not by me) to a more ISO standard MMDDHHmm. If busybox has 64-bit math enabled, then this can be compared with no problems, it just has to be munged into the format 'date' wants. So we can have compat and 64-bit math and have it properly behaving? Yes, I believe so. I'll work up the patch and test it now. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 0/2] Fix /etc/timestamp handling
Recent changes have attempted to make consistant use of /etc/timestamp In particular 5aab665 initscripts: Make /etc/timestamp consistent again. 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes e32e236 busybox: Enable 64 bit shell tests, and disable non-standard date format interpretation. However, this format of the timestamp is not directly compatible with the 'date' command line, so it must be reformatted for use. Also, the busybox CONFIG_FEATURE_DATE_COMPAT needs to be enabled so that all versions of 'date', whether from busybox or coreutils, agree on the format when setting the date from the command line. Gary Thomas (2): initscripts: Properly format date when set from timestamp busybox: Restore 'date' compatability meta/recipes-core/busybox/busybox-1.19.3/defconfig |2 +- meta/recipes-core/busybox/busybox_1.19.3.bb|2 +- .../initscripts/initscripts-1.0/bootmisc.sh|2 +- meta/recipes-core/initscripts/initscripts_1.0.bb |2 +- 4 files changed, 4 insertions(+), 4 deletions(-) -- 1.7.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 1/2] initscripts: Properly format date when set from timestamp
Reformat date, as stored in /etc/timestamp, to match CLI format.
Signed-off-by: Gary Thomas g...@mlbassoc.com
Signed-off-by: Gary Thomas g...@mlbassoc.com
---
.../initscripts/initscripts-1.0/bootmisc.sh|2 +-
meta/recipes-core/initscripts/initscripts_1.0.bb |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh
b/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh
index 20ec0a0..5b86e79 100755
--- a/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh
+++ b/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh
@@ -71,7 +71,7 @@ then
SYSTEMDATE=`date -u +%4Y%2m%2d%2H%2M`
read TIMESTAMP /etc/timestamp
if [ ${TIMESTAMP} -gt $SYSTEMDATE ]; then
- date -u $TIMESTAMP
+ date -u ${TIMESTAMP#}${TIMESTAMP%}
/etc/init.d/hwclock.sh stop
fi
fi
diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb
b/meta/recipes-core/initscripts/initscripts_1.0.bb
index e16f19f..68701ce 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -3,7 +3,7 @@ DESCRIPTION = Initscripts provide the basic system startup
initialization scrip
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe
-PR = r131
+PR = r132
INHIBIT_DEFAULT_DEPS = 1
--
1.7.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 2/2] busybox: Restore 'date' compatability
Restore CONFIG_FEATURE_DATE_COMPAT so that all versions of 'date',
whether from busybox or coreutils, agree on the format when
setting the date from the command line.
Signed-off-by: Gary Thomas g...@mlbassoc.com
---
meta/recipes-core/busybox/busybox-1.19.3/defconfig |2 +-
meta/recipes-core/busybox/busybox_1.19.3.bb|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/busybox/busybox-1.19.3/defconfig
b/meta/recipes-core/busybox/busybox-1.19.3/defconfig
index ca49671..372d7b5 100644
--- a/meta/recipes-core/busybox/busybox-1.19.3/defconfig
+++ b/meta/recipes-core/busybox/busybox-1.19.3/defconfig
@@ -172,7 +172,7 @@ CONFIG_CAT=y
CONFIG_DATE=y
# CONFIG_FEATURE_DATE_ISOFMT is not set
# CONFIG_FEATURE_DATE_NANO is not set
-# CONFIG_FEATURE_DATE_COMPAT is not set
+CONFIG_FEATURE_DATE_COMPAT=y
CONFIG_ID=y
CONFIG_GROUPS=y
CONFIG_TEST=y
diff --git a/meta/recipes-core/busybox/busybox_1.19.3.bb
b/meta/recipes-core/busybox/busybox_1.19.3.bb
index 45e284f..49ac859 100644
--- a/meta/recipes-core/busybox/busybox_1.19.3.bb
+++ b/meta/recipes-core/busybox/busybox_1.19.3.bb
@@ -1,5 +1,5 @@
require busybox.inc
-PR = r4
+PR = r5
SRC_URI = http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball
\
file://udhcpscript.patch \
--
1.7.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCHv2 2/5] bitbake.conf: remove TARGET_ARCH from in SDKPATH
On Thu, Mar 01, 2012 at 10:40:52AM +0100, Martin Jansa wrote: On Thu, Mar 01, 2012 at 01:23:29AM -0800, Khem Raj wrote: On 02/25/2012 11:49 PM, Martin Jansa wrote: +SDK_NAME_PREFIX = oecore should this be weak assignment Yeah, probably could be (I'm not overwritting this from my distro conf so I haven't tried), but SDK_NAME assignment also wasn't weak and distros were overwritting it. Someone with custom SDK_NAME(_PREFIX) please try and send patch. And we should change TARGET_ARCH in SDK_NAME to PACKAGE_ARCH or TUNE_PKGARCH because meta-toolchain-gmae for armv7a ends in oecore-i686-arm-toolchain-gmae-20120229.tar.bz2 and for armv4t with similar name (I was lucky that it took more then day to build) oecore-i686-arm-toolchain-gmae-20120301.tar.bz2 Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCHv2 2/5] bitbake.conf: remove TARGET_ARCH from in SDKPATH
On Thu, 2012-03-01 at 19:25 +0100, Martin Jansa wrote: On Thu, Mar 01, 2012 at 10:40:52AM +0100, Martin Jansa wrote: On Thu, Mar 01, 2012 at 01:23:29AM -0800, Khem Raj wrote: On 02/25/2012 11:49 PM, Martin Jansa wrote: +SDK_NAME_PREFIX = oecore should this be weak assignment Yeah, probably could be (I'm not overwritting this from my distro conf so I haven't tried), but SDK_NAME assignment also wasn't weak and distros were overwritting it. Someone with custom SDK_NAME(_PREFIX) please try and send patch. And we should change TARGET_ARCH in SDK_NAME to PACKAGE_ARCH or TUNE_PKGARCH because meta-toolchain-gmae for armv7a ends in oecore-i686-arm-toolchain-gmae-20120229.tar.bz2 and for armv4t with similar name (I was lucky that it took more then day to build) oecore-i686-arm-toolchain-gmae-20120301.tar.bz2 Agreed... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] image_types: add IMAGE_ROOTFS_ALIGNMENT
Introduce a new variable called IMAGE_ROOTFS_ALIGNMENT that allows to control
the aligment of the size of the rootfs. Its default value is set to 1KiB so
that the existing behaviour is not changed. In case the SD card emulation of
a QEMU system emulator gets used you may set the alignment to 2MiB.
---
meta/classes/image_types.bbclass | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index f756c39..314d6d1 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -55,9 +55,19 @@ def get_imagecmds(d):
cmds += \n + localdata.getVar(runimagecmd, True)
return cmds
+# The default aligment of the size of the rootfs is set to 1KiB. In case
+# you're using the SD card emulation of a QEMU system simulator you may
+# set this value to 2048 (2MiB alignment).
+IMAGE_ROOTFS_ALIGNMENT ?= 1
+
runimagecmd () {
# Image generation code for image type ${type}
- ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = ($1 *
${IMAGE_OVERHEAD_FACTOR}); OFMT = %.0f ; print ((base_size
${IMAGE_ROOTFS_SIZE} ? base_size : ${IMAGE_ROOTFS_SIZE}) +
${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
+ # The base_size gets calculated:
+ # - initial size determined by `du -ks` of the IMAGE_ROOTFS
+ # - then multiplied by the IMAGE_OVERHEAD_FACTOR
+ # - then rounded up to IMAGE_ROOTFS_ALIGNMENT
+ # - finally tested against IMAGE_ROOTFS_SIZE
+ ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = $1 *
${IMAGE_OVERHEAD_FACTOR} + ${IMAGE_ROOTFS_ALIGNMENT} - 1; base_size -=
base_size % ${IMAGE_ROOTFS_ALIGNMENT}; print ((base_size ${IMAGE_ROOTFS_SIZE}
? base_size : ${IMAGE_ROOTFS_SIZE}) + ${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
${cmd}
# Now create the needed compressed versions
cd ${DEPLOY_DIR_IMAGE}/
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] scripts/oe-git-proxy-socks-command: Improve error fallback/handling
If oe-git-proxy-socks isn't available, try and create it. If that fails, tell the user there is a problem, don't just fail to find the command. [YOCTO #2007] Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- diff --git a/scripts/oe-git-proxy-socks-command b/scripts/oe-git-proxy-socks-command index 90fa14e..39e0acb 100755 --- a/scripts/oe-git-proxy-socks-command +++ b/scripts/oe-git-proxy-socks-command @@ -1,2 +1,17 @@ #! /bin/bash +SCRIPTDIR=`dirname $0` +# Check oe-git-proxy-socks exists +PROXYSOCKS=`which oe-git-proxy-socks 2 /dev/null` +if [ -z $PROXYSOCKS -a -e $SCRIPTDIR/oe-git-proxy-socks.c ]; then + # If not try and build it + gcc $SCRIPTDIR/oe-git-proxy-socks.c -o $SCRIPTDIR/oe-git-proxy-socks +fi +PROXYSOCKS=`which oe-git-proxy-socks 2 /dev/null` +if [ ! -x $PROXYSOCKS ]; then + # If that fails, explain to the user + echo Unable to find oe-git-proxy-socks. This is usually created with the command + echo 'gcc scripts/oe-git-proxy-socks.c -o scripts/oe-git-proxy-socks' which we tried + echo but it doesn't seem to have worked. Please compile the binary manually. + exit 1 +fi oe-git-proxy-socks -S $GIT_PROXY_HOST:$GIT_PROXY_PORT $@ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 0/2] Fix /etc/timestamp handling
On Thu, 2012-03-01 at 10:41 -0700, Gary Thomas wrote: Recent changes have attempted to make consistant use of /etc/timestamp In particular 5aab665 initscripts: Make /etc/timestamp consistent again. 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes e32e236 busybox: Enable 64 bit shell tests, and disable non-standard date format interpretation. However, this format of the timestamp is not directly compatible with the 'date' command line, so it must be reformatted for use. Also, the busybox CONFIG_FEATURE_DATE_COMPAT needs to be enabled so that all versions of 'date', whether from busybox or coreutils, agree on the format when setting the date from the command line. Gary Thomas (2): initscripts: Properly format date when set from timestamp busybox: Restore 'date' compatability Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libproxy: Fix build errors due to missing prototypes
On Thu, 2012-03-01 at 10:08 -0800, Khem Raj wrote: g++ really does not like the missing prototypes here we were missing close() and read() so include unistd.h to get them Signed-off-by: Khem Raj raj.k...@gmail.com --- .../libproxy/libproxy/g++-namepace.patch | 22 meta/recipes-support/libproxy/libproxy_0.4.7.bb|6 +++- 2 files changed, 26 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-support/libproxy/libproxy/g++-namepace.patch Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] scripts/oe-git-proxy-socks-command: Add fallback to use nc
If our own proxy command isn't available for some reason and nc is available, fall back to use it. Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- diff --git a/scripts/oe-git-proxy-socks-command b/scripts/oe-git-proxy-socks-command index 39e0acb..8acffb5 100755 --- a/scripts/oe-git-proxy-socks-command +++ b/scripts/oe-git-proxy-socks-command @@ -8,10 +8,16 @@ if [ -z $PROXYSOCKS -a -e $SCRIPTDIR/oe-git-proxy-socks.c ]; then fi PROXYSOCKS=`which oe-git-proxy-socks 2 /dev/null` if [ ! -x $PROXYSOCKS ]; then - # If that fails, explain to the user - echo Unable to find oe-git-proxy-socks. This is usually created with the command - echo 'gcc scripts/oe-git-proxy-socks.c -o scripts/oe-git-proxy-socks' which we tried - echo but it doesn't seem to have worked. Please compile the binary manually. - exit 1 + # If that fails, we can see if netcat (nc) is available + NETCAT=`which nc 2 /dev/null` + if [ ! -x $NETCAT ]; then + # If that fails, explain to the user + echo Unable to find oe-git-proxy-socks. This is usually created with the command + echo 'gcc scripts/oe-git-proxy-socks.c -o scripts/oe-git-proxy-socks' which we tried + echo but it doesn't seem to have worked. Please compile the binary manually. + echo Alternativly, install nc (netcat) on this machine. + exit 1 + fi + exec $NETCAT -x $GIT_PROXY_HOST:$GIT_PROXY_PORT $@ fi oe-git-proxy-socks -S $GIT_PROXY_HOST:$GIT_PROXY_PORT $@ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] image_types: add IMAGE_ROOTFS_ALIGNMENT
On 03/01/2012 12:55 PM, Ken Werner wrote:
Introduce a new variable called IMAGE_ROOTFS_ALIGNMENT that allows to control
the aligment of the size of the rootfs. Its default value is set to 1KiB so
that the existing behaviour is not changed. In case the SD card emulation of
a QEMU system emulator gets used you may set the alignment to 2MiB.
---
meta/classes/image_types.bbclass | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index f756c39..314d6d1 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -55,9 +55,19 @@ def get_imagecmds(d):
cmds += \n + localdata.getVar(runimagecmd, True)
return cmds
+# The default aligment of the size of the rootfs is set to 1KiB. In case
+# you're using the SD card emulation of a QEMU system simulator you may
+# set this value to 2048 (2MiB alignment).
+IMAGE_ROOTFS_ALIGNMENT ?= 1
+
runimagecmd () {
# Image generation code for image type ${type}
- ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = ($1 *
${IMAGE_OVERHEAD_FACTOR}); OFMT = %.0f ; print ((base_size
${IMAGE_ROOTFS_SIZE} ? base_size : ${IMAGE_ROOTFS_SIZE}) + ${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
+ # The base_size gets calculated:
+ # - initial size determined by `du -ks` of the IMAGE_ROOTFS
+ # - then multiplied by the IMAGE_OVERHEAD_FACTOR
+ # - then rounded up to IMAGE_ROOTFS_ALIGNMENT
+ # - finally tested against IMAGE_ROOTFS_SIZE
+ ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = $1 *
${IMAGE_OVERHEAD_FACTOR} + ${IMAGE_ROOTFS_ALIGNMENT} - 1; base_size -= base_size %
${IMAGE_ROOTFS_ALIGNMENT}; print ((base_size ${IMAGE_ROOTFS_SIZE} ? base_size
: ${IMAGE_ROOTFS_SIZE}) + ${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
${cmd}
Is there a reason you removed the OFMT from this line?
Sau!
# Now create the needed compressed versions
cd ${DEPLOY_DIR_IMAGE}/
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Image generation change
I'm having a problem after the recent change
commit eacedb4f2afa98dbd2f5ea7a9f52e6ea952a72d2
Author: Richard Purdie richard.pur...@linuxfoundation.org
Date: Wed Feb 29 16:24:26 2012 +
image_types: Correctness fixes
* Add a newline to improve the output formatting
* Use set() to turn the list into a set of unique items to prevnt
the same image code running twice (for e.g. IMAGE_FSTYPES = tar.gz
tar.bz2)
* Support multiple compression extensions such as .gz.u-boot
* Fix basetype/type typo and fix multiple image generation
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
I build initrd-style images which can be loaded by U-Boot. This is a multi-step
process - first create the root image as ext3.gz, then pack it into the U-Boot
image. Before this change, I could use this setup:
IMAGE_FSTYPES = ext3.gz initrd
IMAGE_CMD_initrd = uboot_initrd;
IMAGE_ROOTFS_SIZE = 24576
where the 'uboot_initrd' command expected the ext3.gz image to be complete and
all it does is the U-Boot mkimage magic.
This no longer works as when uboot_initrd() runs, there is no ext3.gz image
yet built. I'm not sure I understand the exact reason, but if I revert just
these lines, the process works again.
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 5b48a09..8ea170a 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -29,7 +29,7 @@ def get_imagecmds(d):
if d.getVar('IMAGE_LINK_NAME', True):
cmds += rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.*
-for type in set(types):
+for type in types:
ccmd = []
subimages = []
localdata = bb.data.createCopy(d)
If there is another way to solve my problem, i.e. generate the wrapped
up initrd image, that will still work with the code as is, I'd be happy
to use it, but I'm not sure how to write such a process.
Any ideas gladly accepted, thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gdk-pixbuf: Pick up ${NM} from the environment.
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
Of Khem Raj
Sent: Thursday, 1 March 2012 6:06 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] gdk-pixbuf: Pick up ${NM} from the
environment.
On 02/27/2012 11:36 PM, James Limbouris wrote:
Signed-off-by: James Limbouris ja...@digitalmatter.com.au
---
.../gdk-pixbuf-2.24.0/configure_nm.patch | 19
+++
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.0.bb |3 ++-
2 files changed, 21 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-
2.24.0/configure_nm.patch
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-
2.24.0/configure_nm.patch b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-
2.24.0/configure_nm.patch
new file mode 100644
index 000..1697967
--- /dev/null
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-
2.24.0/configure_nm.patch
@@ -0,0 +1,19 @@
+At this stage of configure, ${NM} has already been correctly set.
+This AC_PATH_PROG overwrites the correct path with a host path.
+
+Upstream-Status: Inappropriate [configuration]
+Signed-off-by: James Limbouris ja...@digitalmatter.com.au
+
+Index: gdk-pixbuf-2.24.0/configure.ac
+=
==
+diff -uNr gdk-pixbuf-2.24.0/configure.ac gdk-pixbuf-
2.24.0.mod/configure.ac
+--- gdk-pixbuf-2.24.0/configure.ac 2011-08-27 11:27:52.0 +0800
gdk-pixbuf-2.24.0.mod/configure.ac 2012-02-28
14:48:36.481126410 +0800
+@@ -147,7 +147,6 @@
+ AC_SYS_LARGEFILE
+
+ AM_PROG_AS
+-AC_PATH_PROG(NM, nm, nm)
you could use AC_CHECK_TOOLS(NM, [$NM nm], nm)
here instead of deleting it
On my system at least, nm has already been found and examined by the config
script at this stage.
The AC_PATH_PROG looks for it a second time, and overwrites the already correct
entry.
So, do we need an AC_CHECK_TOOLS?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gdk-pixbuf: Pick up ${NM} from the environment.
On (02/03/12 03:07), James Limbouris wrote:
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
Of Khem Raj
Sent: Thursday, 1 March 2012 6:06 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] gdk-pixbuf: Pick up ${NM} from the
environment.
On 02/27/2012 11:36 PM, James Limbouris wrote:
Signed-off-by: James Limbouris ja...@digitalmatter.com.au
---
.../gdk-pixbuf-2.24.0/configure_nm.patch | 19
+++
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.0.bb |3 ++-
2 files changed, 21 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-
2.24.0/configure_nm.patch
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-
2.24.0/configure_nm.patch b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-
2.24.0/configure_nm.patch
new file mode 100644
index 000..1697967
--- /dev/null
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-
2.24.0/configure_nm.patch
@@ -0,0 +1,19 @@
+At this stage of configure, ${NM} has already been correctly set.
+This AC_PATH_PROG overwrites the correct path with a host path.
+
+Upstream-Status: Inappropriate [configuration]
+Signed-off-by: James Limbouris ja...@digitalmatter.com.au
+
+Index: gdk-pixbuf-2.24.0/configure.ac
+=
==
+diff -uNr gdk-pixbuf-2.24.0/configure.ac gdk-pixbuf-
2.24.0.mod/configure.ac
+--- gdk-pixbuf-2.24.0/configure.ac 2011-08-27 11:27:52.0
+0800
gdk-pixbuf-2.24.0.mod/configure.ac 2012-02-28
14:48:36.481126410 +0800
+@@ -147,7 +147,6 @@
+ AC_SYS_LARGEFILE
+
+ AM_PROG_AS
+-AC_PATH_PROG(NM, nm, nm)
you could use AC_CHECK_TOOLS(NM, [$NM nm], nm)
here instead of deleting it
On my system at least, nm has already been found and examined by the config
script at this stage.
The AC_PATH_PROG looks for it a second time, and overwrites the already
correct entry.
So, do we need an AC_CHECK_TOOLS?
its set in environment yes but removing it in not correct
thing from the package perspective. using AC_CHECK_TOOLS makes it work well
in cross environment and native build bahavior is not changed.
More over such a patch will be a welcome in upstream of this package
as well.
--
-Khem
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gdk-pixbuf: Pick up ${NM} from the environment.
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
Of Khem Raj
Sent: Friday, 2 March 2012 1:24 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH] gdk-pixbuf: Pick up ${NM} from the
environment.
On (02/03/12 03:07), James Limbouris wrote:
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On
Behalf
Of Khem Raj
Sent: Thursday, 1 March 2012 6:06 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] gdk-pixbuf: Pick up ${NM} from the
environment.
On 02/27/2012 11:36 PM, James Limbouris wrote:
Signed-off-by: James Limbouris ja...@digitalmatter.com.au
---
.../gdk-pixbuf-2.24.0/configure_nm.patch | 19
+++
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.0.bb |3 ++-
2 files changed, 21 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-
2.24.0/configure_nm.patch
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-
2.24.0/configure_nm.patch b/meta/recipes-gnome/gdk-pixbuf/gdk-
pixbuf-
2.24.0/configure_nm.patch
new file mode 100644
index 000..1697967
--- /dev/null
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-
2.24.0/configure_nm.patch
@@ -0,0 +1,19 @@
+At this stage of configure, ${NM} has already been correctly set.
+This AC_PATH_PROG overwrites the correct path with a host path.
+
+Upstream-Status: Inappropriate [configuration]
+Signed-off-by: James Limbouris ja...@digitalmatter.com.au
+
+Index: gdk-pixbuf-2.24.0/configure.ac
+=
==
+diff -uNr gdk-pixbuf-2.24.0/configure.ac gdk-pixbuf-
2.24.0.mod/configure.ac
+--- gdk-pixbuf-2.24.0/configure.ac 2011-08-27
11:27:52.0 +0800
gdk-pixbuf-2.24.0.mod/configure.ac 2012-02-28
14:48:36.481126410 +0800
+@@ -147,7 +147,6 @@
+ AC_SYS_LARGEFILE
+
+ AM_PROG_AS
+-AC_PATH_PROG(NM, nm, nm)
you could use AC_CHECK_TOOLS(NM, [$NM nm], nm)
here instead of deleting it
On my system at least, nm has already been found and examined by the
config script at this stage.
The AC_PATH_PROG looks for it a second time, and overwrites the already
correct entry.
So, do we need an AC_CHECK_TOOLS?
its set in environment yes but removing it in not correct
thing from the package perspective. using AC_CHECK_TOOLS makes it work
well
in cross environment and native build bahavior is not changed.
More over such a patch will be a welcome in upstream of this package
as well.
It is more than set in the environment - the configure script spits out two
messages about it before hitting this macro.
So, I think the check is entirely extraneous.
I have seen this issue patched out in other gnome packages, some in oe-core.
At least one was marked Upstream-Status: Inappropriate [configuration], and one
marked Pending.
So I got the idea that upstream was not interested...
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] initscripts: Properly handle new timestamp format
On 03/01/2012 06:06 PM, Gary Thomas wrote: As far as I can recall (which is a really long time), 'date' has always wanted the format MMDDHHmm[], so I think that's what we should expect. That format doesn't compare easily which is why the timestamp was changed (not by me) to a more ISO standard MMDDHHmm. If busybox has 64-bit math enabled, then this can be compared with no problems, it just has to be munged into the format 'date' wants. So we can have compat and 64-bit math and have it properly behaving? Yes, I believe so. I'll work up the patch and test it now. It might be very helpful for other developers if 64-bit math requirement of busybox would be documented somewhere. BR, Lauri ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] multilib build failure with shadow-sysroot:do_populate_sysroot_setscene
RP, I have image-sato multilib build failure with following error: ERROR: Task do_package_setscene depends upon nonexistant task /distro/edwin-working/poky/meta/recipes-extended/shadow/shadow-sysroot_4.1.4.3.bb:do_populate_sysroot_setscene Summary: There was 1 ERROR message shown, returning a non-zero exit code. After removing shadow-sysroot:do_populate_sysroot_setscene from USERADDSETSCENEDEPS in meta/classes/useradd.bbclass, I can pass the build. Why does it become nonexistant task in multilib building? Any possible fix for it? Thanks, Edwin -- best rgds, edwin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] Fix libpam's chmod
The libpam's has an error when generating the rootfs:
chmod: cannot access `/usr/sbin/unix_chkpwd': No such file or directory
This is because the following code in libpam_1.1.5.bb:
pkg_postinst_pam-plugin-unix () {
# below is necessary to allow unix_chkpwd get user info from shadow file
# on lsb images
chmod 4755 ${sbindir}/unix_chkpwd
}
This is to set the setuid permission for unix_chkpwd (the lsb test
requires this), but it lacks a ${D}, and we can do this in the install
stage.
[YOCTO #2049]
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-extended/pam/libpam_1.1.5.bb |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-extended/pam/libpam_1.1.5.bb
b/meta/recipes-extended/pam/libpam_1.1.5.bb
index 283f477..8cddca9 100644
--- a/meta/recipes-extended/pam/libpam_1.1.5.bb
+++ b/meta/recipes-extended/pam/libpam_1.1.5.bb
@@ -85,10 +85,7 @@ do_install() {
install -d ${D}${sysconfdir}/pam.d/
install -m 0644 ${WORKDIR}/pam.d/* ${D}${sysconfdir}/pam.d/
-}
-pkg_postinst_pam-plugin-unix () {
-# below is necessary to allow unix_chkpwd get user info from shadow file
-# on lsb images
-chmod 4755 ${sbindir}/unix_chkpwd
+# The lsb requires unix_chkpwd has setuid permission
+chmod 4755 ${D}${sbindir}/unix_chkpwd
}
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gdk-pixbuf: Pick up ${NM} from the environment.
It is more than set in the environment - the configure script spits out two messages about it before hitting this macro. So, I think the check is entirely extraneous. if you can point that there is another check which makes this one redundant thats a different issue and then your patch is ok. but I doubt thats the case I have seen this issue patched out in other gnome packages, some in oe-core. At least one was marked Upstream-Status: Inappropriate [configuration], and one marked Pending. So I got the idea that upstream was not interested... usually such patches are taken status may be too conservative ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- -Khem ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
