Re: [OE-core] Improving Build Speed
Why restrict PARALLEL_MAKE to anything less than the number of H/W
threads in the machine?
Came up with a construct PARALLEL_HIGH which is defined alongside
PARALLEL_MAKE in conf/local.conf
PARALLEL_MAKE = -j8
PARALLEL_HIGH = -j24
In the appropriate recipes, which seems to be processed by bitbake
in solitude I do:
PARALLEL_HIGH ?= ${PARALLEL_MAKE}
PARALLEL_MAKE = ${PARALLEL_HIGH}
This means that they will try to use each H/W thread.
Please benchmark the difference. I suspect we can just set the high
number of make for everything. Note that few makefiles are well enough
written to benefit from high levels of make (webkit being an notable
exception).
It looks like it is shaving off ~2 minutes from a build which normally
takes ~84 minutes.
First build
PARALLEL_MAKE = -j12
PARALLEL_HIGH = -j24
BB_NUMBER_THREADS = 24
real83m24.093s
Second build
PARALLEL_MAKE = -j12
PARALLEL_HIGH = -j12
BB_NUMBER_THREADS = 24
real85m12.007s
BR
Ulf
Cheers, Richard ___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Best Regards
Ulf Samuelsson
eMagii
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] nfs-utils: separate package as Debain style
Move binaries used for both nfs client and server into client
package. Add an init script for client package and move
necessary progress from server's init script to this one. Make
client package more powerful and let server package depends on
client one, as Debain does.
Signed-off-by: Zhang Xiao xiao.zh...@windriver.com
---
.../nfs-utils/nfs-utils/nfscommon | 90 ++
.../nfs-utils/nfs-utils/nfsserver | 46 +--
.../nfs-utils/nfs-utils_1.2.9.bb | 27 +--
3 files changed, 114 insertions(+), 49 deletions(-)
create mode 100644 meta/recipes-connectivity/nfs-utils/nfs-utils/nfscommon
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfscommon
b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfscommon
new file mode 100644
index 000..c949b96
--- /dev/null
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfscommon
@@ -0,0 +1,90 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides: nfs-common
+# Required-Start:$portmap hwclock
+# Required-Stop: $portmap hwclock
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: NFS support for both client and server
+# Description: NFS is a popular protocol for file sharing across
+#TCP/IP networks. This service provides various
+#support functions for NFS mounts.
+### END INIT INFO
+#
+# Startup script for nfs-utils
+#
+#
+# Location of executables:
+
+# Source function library.
+. /etc/init.d/functions
+
+test -x $NFS_STATD || NFS_STATD=/usr/sbin/rpc.statd
+test -z $STATD_PID STATD_PID=/var/run/rpc.statd.pid
+#
+# The default state directory is /var/lib/nfs
+test -n $NFS_STATEDIR || NFS_STATEDIR=/var/lib/nfs
+#
+#--
+# Startup and shutdown functions.
+# Actual startup/shutdown is at the end of this file.
+#directories
+create_directories(){
+ echo -n 'creating NFS state directory: '
+ mkdir -p $NFS_STATEDIR
+ ( cd $NFS_STATEDIR
+ umask 077
+ mkdir -p rpc_pipefs
+ mkdir -p sm sm.bak statd
+ chown rpcuser sm sm.bak statd
+ test -w statd/state || {
+ rm -f statd/state
+ :statd/state
+ }
+ umask 022
+ for file in xtab etab smtab rmtab
+ do
+ test -w $file || {
+ rm -f $file
+ :$file
+ }
+ done
+ )
+ chown rpcuser $NFS_STATEDIR
+ echo done
+}
+
+#statd
+start_statd(){
+ echo -n starting statd:
+ start-stop-daemon --start --exec $NFS_STATD --pidfile $STATD_PID
+ echo done
+}
+stop_statd(){
+ echo -n 'stopping statd: '
+ start-stop-daemon --stop --quiet --signal 1 --pidfile $STATD_PID
+ echo done
+}
+#--
+#
+# supported options:
+# start
+# stop
+# restart: stops and starts mountd
+#FIXME: need to create the /var/lib/nfs/... directories
+case $1 in
+ start)
+ create_directories
+ start_statd;;
+ stop)
+ stop_statd;;
+ status)
+ status $NFS_STATD
+ exit $?;;
+ restart)
+ $0 stop
+ $0 start;;
+ *)
+ echo Usage: $0 {start|stop|status|restart}
+ exit 1;;
+esac
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver
b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver
index c263f14..6e0df7e 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfsserver
@@ -1,8 +1,8 @@
#!/bin/sh
### BEGIN INIT INFO
# Provides: nfs-kernel-server
-# Required-Start:$remote_fs $portmap hwclock
-# Required-Stop: $remote_fs $portmap hwclock
+# Required-Start:$remote_fs nfs-common $portmap hwclock
+# Required-Stop: $remote_fs nfs-common $portmap hwclock
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Kernel NFS server support
@@ -24,8 +24,6 @@ test -r /etc/default/nfsd . /etc/default/nfsd
# Location of executables:
test -x $NFS_MOUNTD || NFS_MOUNTD=/usr/sbin/rpc.mountd
test -x $NFS_NFSD || NFS_NFSD=/usr/sbin/rpc.nfsd
-test -x $NFS_STATD || NFS_STATD=/usr/sbin/rpc.statd
-test -z $STATD_PID STATD_PID=/var/run/rpc.statd.pid
#
# The user mode program must also exist (it just starts the kernel
# threads using the kernel module code).
@@ -36,34 +34,9 @@ test -x $NFS_NFSD || exit 0
# ridiculous 99
test $NFS_SERVERS != test $NFS_SERVERS -gt 0 test $NFS_SERVERS
-lt 100 || NFS_SERVERS=8
#
-# The default state directory is /var/lib/nfs
-test -n $NFS_STATEDIR || NFS_STATEDIR=/var/lib/nfs
-#
#--
# Startup and shutdown functions.
# Actual startup/shutdown is
[OE-core] [PATCH] shadow: remove reference to locale env files from su
From: Qiang Chen qiang.c...@windriver.com The /etc/default/locale missing message appears when running su user root@qemu0:/var/log# su root root@qemu0:/var/log# tail auth.log Oct 8 07:47:54 qemu0 login[983]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) Oct 8 07:47:55 qemu0 login[995]: ROOT LOGIN on '/dev/console' Oct 8 07:48:21 qemu0 su[999]: Successful su for root by root Oct 8 07:48:21 qemu0 su[999]: + /dev/console root:root Oct 8 07:48:21 qemu0 su[999]: pam_env(su:session): Unable to open env file: /etc/default/locale: No such file or directory Oct 8 07:48:21 qemu0 su[999]: pam_unix(su:session): session opened for user root by root(uid=0) This commit remove reference from pam.d/su to /etc/default/locale env file to avoid the error messages. Signed-off-by: Qiang Chen qiang.c...@windriver.com --- meta/recipes-extended/shadow/files/pam.d/su |3 --- meta/recipes-extended/shadow/shadow.inc |2 +- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/meta/recipes-extended/shadow/files/pam.d/su b/meta/recipes-extended/shadow/files/pam.d/su index 8e35137..8d590a3 100644 --- a/meta/recipes-extended/shadow/files/pam.d/su +++ b/meta/recipes-extended/shadow/files/pam.d/su @@ -34,9 +34,6 @@ auth sufficient pam_rootok.so # # parsing /etc/environment needs readenv=1 session required pam_env.so readenv=1 -# locale variables are also kept into /etc/default/locale in etch -# reading this file *in addition to /etc/environment* does not hurt -session required pam_env.so readenv=1 envfile=/etc/default/locale # Defines the MAIL environment variable # However, userdel also needs MAIL_DIR and MAIL_FILE variables diff --git a/meta/recipes-extended/shadow/shadow.inc b/meta/recipes-extended/shadow/shadow.inc index 5ab978a..572c3bc 100644 --- a/meta/recipes-extended/shadow/shadow.inc +++ b/meta/recipes-extended/shadow/shadow.inc @@ -44,7 +44,7 @@ SRC_URI_append_class-nativesdk = \ SRC_URI[md5sum] = b8608d8294ac88974f27b20f991c0e79 SRC_URI[sha256sum] = 633f5bb4ea0c88c55f3642c97f9d25cbef74f82e0b4cf8d54e7ad6f9f9caa778 -PR = r13 +PR = r14 # Additional Policy files for PAM PAM_SRC_URI = file://pam.d/chfn \ -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Improving Build Speed
On 20 November 2013 21:05, Ulf Samuelsson angstrom-...@emagii.com wrote:
do_compile() {
if [ x$MAKE = x ]; then MAKE=make; fi
...
for error_count in 1 2 3; do
...
${MAKE} ${EXTRA_OEMAKE} $@ || exit_code=1
...
done
...
}
Not sure, but I think this means that PARALLEL_MAKE might get ignored.
Yeah, good catch - the point of the loop was to handle random failures
caused by dependency chains breaking when doing parallel builds...
Anyway, that hack isn't present in 1.5 because it was caused by using
an unpatched (read: broken) make 3.82 which we now detect at startup.
Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] initscripts: remove erroneous call to /etc/default/rcS
This doesn't exist when using systemd as it's part of the sysvinit package, and this script doesn't need it. Signed-off-by: Ross Burton ross.bur...@intel.com --- meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh |2 -- 1 file changed, 2 deletions(-) diff --git a/meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh b/meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh index 4fffe4e..fe6c196 100755 --- a/meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh +++ b/meta/recipes-core/initscripts/initscripts-1.0/mountnfs.sh @@ -7,8 +7,6 @@ # Default-Stop: ### END INIT INFO -. /etc/default/rcS - # # Run in a subshell because of I/O redirection. # -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Improving Build Speed
Ulf Samuelsson angstrom-dev-aofpy8dbyrpqt0dzr+a...@public.gmane.org
writes:
PARALLEL_MAKE = -j6
BB_NUMBER_THREADS = 24
I define
| PARALLEL_MAKE = \
| -j ${@int(os.sysconf(os.sysconf_names['SC_NPROCESSORS_ONLN'])) * 2} \
| -l ${@int(os.sysconf(os.sysconf_names['SC_NPROCESSORS_ONLN'])) * 150/100} \
|
|
| BB_NUMBER_THREADS ?= \
| ${@int(os.sysconf(os.sysconf_names['SC_NPROCESSORS_ONLN'])) * 150/100}
in my global configuration (note the '-l'). I would like to limit it by
the available RAM size (e.g. one -j per GB) but BB_NUMBER_THREADS makes
it difficultly to express it. There are also dependencies on the used
filesystem (e.g. btrfs performance seems to degrade rapidly with higher
-j).
It would be perfect when bitbake takes the role of the toplevel
jobserver[1] but that's probably very difficultly to implement and
might interfere with recursive make.
and was quicker, but it seemed to be a little flawed. At several
times during the build, the CPU frequtil showed that most of the cores
went down to minimum frequency (2,93 GHz - 1,6 GHz)
Capturing resource usage (-- getrusage(2)) will give more details
(e.g. about i/o load). E.g. see
https://www.cvg.de/people/ensc/oe-metrics.html
Enrico
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] bind: add support for read-only rootfs
On Thu, 2013-11-21 at 00:59 -0600, Mark Hatle wrote: +# When using a read-only rootfs additional setup may be required +# uncomment the following line to make bind start in read-only rootfs +#ALLOW_ROOTFS_READ_ONLY=yes If the filesystem is read-only then it's going to be fairly difficult for the user to uncomment this line on the target. Why would you ever want this variable to be set to anything other than yes? If your filesystem is not in fact read-only then it isn't going to have any effect, and if your filesystem is read-only then bind won't work without it. ++[ `is_on_read_only_partition /etc/bind` = yes ] bind_mount /var/volatile/bind/etc /etc/bind ++[ `is_on_read_only_partition /var/named` = yes ] bind_mount /var/volatile/bind/named /var/named Is it really necessary to mount a tmpfs at /etc/bind? Can't those files just be relocated somewhere else? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] bind: add support for read-only rootfs
Hi Mark, On Thursday 21 November 2013 01:02:11 Mark Hatle wrote: Sorry I forgot to add, this requires the patch that was sent to the list 2013-09-29 -- bind: run in the chrooted jail ... which seems to have been rejected: http://patches.openembedded.org/patch/53845/ 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 3/4] lttng-tools: add PACKAGECONFIG to support --enable-python-bindings and lttng-ust
On 11/21/2013 09:14 PM, Hongxu Jia wrote:
Add PACKAGECONFIG to support --enable-python-bindings
Add PACKAGECONFIG to support lttng-ust
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-kernel/lttng/lttng-tools_2.3.1.bb | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.3.1.bb
b/meta/recipes-kernel/lttng/lttng-tools_2.3.1.bb
index 2f6e504..64b6e02 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.3.1.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.3.1.bb
@@ -9,9 +9,18 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=01d7fc4496aacf37d90df90b90b0cac1 \
file://gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
file://lgpl-2.1.txt;md5=0f0d71500e6a57fd24d825f33242b9ca
-DEPENDS = liburcu popt lttng-ust
+DEPENDS = liburcu popt
RDEPENDS_${PN}-ptest += make
+PYTHON_OPTION = am_cv_python_pyexecdir='${libdir}/python${PYTHON_BASEVERSION}/site-packages' \
+
am_cv_python_pythondir='${libdir}/python${PYTHON_BASEVERSION}/site-packages' \
+
PYTHON_INCLUDE='-I${STAGING_INCDIR}/python${PYTHON_BASEVERSION}' \
+
+PACKAGECONFIG = python lttng-ust
s/=/??=/
I have updated the git branch
git://git.pokylinux.org/poky-contrib hongxu/fix-add-python
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-add-python
//Hongxu
+PACKAGECONFIG[python] = --enable-python-bindings ${PYTHON_OPTION}, \
+ --disable-python-bindings, python swig-native
+PACKAGECONFIG[lttng-ust] = --enable-lttng-ust, --disable-lttng-ust, lttng-ust
+
SRCREV = 5d985544a7ad54afa0514ea7f522a89d8d844860
PV = v2.3.1
@@ -26,12 +35,15 @@ inherit autotools ptest
export KERNELDIR=${STAGING_KERNEL_DIR}
-FILES_${PN} += ${libdir}/lttng/libexec/*
-FILES_${PN}-dbg += ${libdir}/lttng/libexec/.debug
+FILES_${PN} += ${libdir}/lttng/libexec/*
${libdir}/python${PYTHON_BASEVERSION}/site-packages/*
+FILES_${PN}-dbg += ${libdir}/lttng/libexec/.debug
${libdir}/python2.7/site-packages/.debug
+FILES_${PN}-staticdev +=
${libdir}/python${PYTHON_BASEVERSION}/site-packages/*.a
+FILES_${PN}-dev += ${libdir}/python${PYTHON_BASEVERSION}/site-packages/*.la
# Since files are installed into ${libdir}/lttng/libexec we match
# the libexec insane test so skip it.
-INSANE_SKIP_${PN} = libexec
+# Python module needs to keep _lttng.so
+INSANE_SKIP_${PN} = libexec dev-so
INSANE_SKIP_${PN}-dbg = libexec
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] grub-efi: change to generate EFI image in target package
From: Jackie Huang jackie.hu...@windriver.com
To generate the target EFI image in a native package, it requires
the host gcc have the ability to do -m32/-m64 compiling, but gcc
doesn't have that support on the 32bit version of some distributions
(e.g. rehl, suse), it would fail when build a 64bit target on these
32bit hosts.
In fact, all we need from grub-efi-native is the grub-mkimage binary,
so change the solution to:
* grub-efi-native only install grub-mkimage
* grub-efi compiles target modules, generates EFI image
with grub-mkimage and deploy, but install nothing.
Signed-off-by: Jackie Huang jackie.hu...@windriver.com
---
meta/classes/grub-efi.bbclass | 4 +-
.../{grub-efi-native_2.00.bb = grub-efi_2.00.bb} | 43 --
2 files changed, 26 insertions(+), 21 deletions(-)
rename meta/recipes-bsp/grub/{grub-efi-native_2.00.bb = grub-efi_2.00.bb}
(77%)
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index 2f00901..71bd00f 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -15,8 +15,8 @@
# ${GRUB_OPTS} - additional options to add to the config, ';' delimited #
(optional)
# ${GRUB_TIMEOUT} - timeout before executing the deault label (optional)
-do_bootimg[depends] += grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
-do_bootdirectdisk[depends] +=
grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
+do_bootimg[depends] += grub-efi:do_deploy
+do_bootdirectdisk[depends] += grub-efi:do_deploy
GRUB_SERIAL ?= console=ttyS0,115200
GRUBCFG = ${S}/grub.cfg
diff --git a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
b/meta/recipes-bsp/grub/grub-efi_2.00.bb
similarity index 77%
rename from meta/recipes-bsp/grub/grub-efi-native_2.00.bb
rename to meta/recipes-bsp/grub/grub-efi_2.00.bb
index 04973b5..2fe688c 100644
--- a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi_2.00.bb
@@ -14,14 +14,10 @@ LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
# FIXME: We should be able to optionally drop freetype as a dependency
-DEPENDS = autogen-native
-RDEPENDS_${PN} = diffutils freetype
+DEPENDS = autogen-native flex-native bison-native
+DEPENDS_class-target = grub-efi-native
PR = r2
-# Native packages do not normally rebuild when the target changes.
-# Ensure this is built once per HOST-TARGET pair.
-PN := grub-efi-${TRANSLATED_TARGET_ARCH}-native
-
SRC_URI = ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
file://cfg \
file://grub-2.00-fpmath-sse-387-fix.patch \
@@ -39,12 +35,10 @@ COMPATIBLE_HOST = '(x86_64.*|i.86.*)-(linux|freebsd.*)'
S = ${WORKDIR}/grub-${PV}
-# Determine the target arch for the grub modules before the native class
-# clobbers TARGET_ARCH.
-ORIG_TARGET_ARCH := ${TARGET_ARCH}
+# Determine the target arch for the grub modules
python __anonymous () {
import re
-target = d.getVar('ORIG_TARGET_ARCH', True)
+target = d.getVar('TARGET_ARCH', True)
if target == x86_64:
grubtarget = 'x86_64'
grubimage = bootx64.efi
@@ -59,26 +53,37 @@ python __anonymous () {
inherit autotools
inherit gettext
-inherit native
inherit deploy
EXTRA_OECONF = --with-platform=efi --disable-grub-mkfont \
---target=${GRUB_TARGET} --enable-efiemu=no --program-prefix=''
\
+--enable-efiemu=no --program-prefix='' \
--enable-liblzma=no --enable-device-mapper=no
--enable-libzfs=no
-do_mkimage() {
+do_install_class-target() {
+ :
+}
+
+do_install_class-native() {
+ install -d ${D}${bindir}
+ install -m 755 grub-mkimage ${D}${bindir}
+}
+
+do_deploy() {
# Search for the grub.cfg on the local boot media by using the
# built in cfg file provided via this recipe
- ./grub-mkimage -c ../cfg -p /EFI/BOOT -d ./grub-core/ \
+ grub-mkimage -c ../cfg -p /EFI/BOOT -d ./grub-core/ \
-O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
boot linux ext2 fat serial part_msdos part_gpt normal
efi_gop iso9660 search
+ install -m 644 ${B}/${GRUB_IMAGE} ${DEPLOYDIR}
}
-addtask mkimage after do_compile before do_install
-do_deploy() {
- install -m 644 ${B}/${GRUB_IMAGE} ${DEPLOYDIR}
+do_deploy_class-native() {
+ :
}
+
addtask deploy after do_install before do_build
-do_install[noexec] = 1
-do_populate_sysroot[noexec] = 1
+FILES_${PN}-dbg += ${libdir}/${BPN}/${GRUB_TARGET}-efi/.debug
+
+BBCLASSEXTEND = native
+ALLOW_EMPTY_${PN} = 1
--
1.8.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] grub-efi: allow compilation without large model support
From: Jackie Huang jackie.hu...@windriver.com
-mcmodel=large is not supported by gcc with version lower
than 4.4, but we don't need to use memory over 4GiB, so add
a patch to allow compilation without large model support.
Signed-off-by: Jackie Huang jackie.hu...@windriver.com
---
...allow-a-compilation-without-mcmodel-large.patch | 81 ++
meta/recipes-bsp/grub/grub-efi_2.00.bb | 1 +
2 files changed, 82 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
diff --git
a/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
b/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
new file mode 100644
index 000..c6a30c8
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
@@ -0,0 +1,81 @@
+From 0cea0e4266214da1f11e812834f5d5c47a6e04e6 Mon Sep 17 00:00:00 2001
+From: Jackie Huang jackie.hu...@windriver.com
+Date: Tue, 5 Nov 2013 07:23:32 -0500
+Subject: [PATCH] Allow a compilation without -mcmodel=large
+
+* kern/efi/mm.c (grub_efi_allocate_pages): don't allocate 4GiB
+ when compiled without -mcmodel=large
+ (filter_memory_map): remove memory post 4 GiB when compiled
+ without -mcmodel=large
+* configure.ac: add -DMCMODEL_SMALL=1 to TARGET_CFLAGS when
+ -mcmodel=large isn't supported
+
+It's ported from old version of grub which was deliberately
+removed in current and newer version:
+
+2009-06-04 Vladimir Serbinenko phco...@gmail.com
+
+ Allow a compilation without -mcmodel=large
+
+2010-04-21 Vladimir Serbinenko phco...@gmail.com
+
+ * configure.ac: Refuse to compile for x86_64-efi is mcmodel=large
+ is not supported.
+
+Upstream-Status: Inappropriate [compatibility]
+
+Signed-off-by: Jackie Huang jackie.hu...@windriver.com
+---
+ configure.ac|4 +++-
+ grub-core/kern/efi/mm.c |6 +++---
+ 2 files changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 319d063..ee72fee 100644
+--- a/configure.ac
b/configure.ac
+@@ -567,7 +567,9 @@ if test $target_cpu-$platform = x86_64-efi; then
+ [grub_cv_cc_mcmodel=no])
+ ])
+ if test x$grub_cv_cc_mcmodel = xno; then
+-AC_MSG_ERROR([-mcmodel=large not supported. Upgrade your gcc.])
++CFLAGS=$SAVED_CFLAGS -m64 -DMCMODEL_SMALL=1
++TARGET_CFLAGS=$TARGET_CFLAGS -DMCMODEL_SMALL=1
++AC_MSG_WARN([-mcmodel=large not supported. You won't be able to use the
memory over 4GiB. Upgrade your gcc.])
+ else
+ TARGET_CFLAGS=$TARGET_CFLAGS -mcmodel=large
+ fi
+diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
+index a2edc84..c67dd13 100644
+--- a/grub-core/kern/efi/mm.c
b/grub-core/kern/efi/mm.c
+@@ -62,7 +62,7 @@ grub_efi_allocate_pages (grub_efi_physical_address_t address,
+ return 0;
+ #endif
+
+-#if 1
++#if defined (MCMODEL_SMALL)
+ if (address == 0)
+ {
+ type = GRUB_EFI_ALLOCATE_MAX_ADDRESS;
+@@ -305,7 +305,7 @@ filter_memory_map (grub_efi_memory_descriptor_t
*memory_map,
+desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
+ {
+ if (desc-type == GRUB_EFI_CONVENTIONAL_MEMORY
+-#if 1
++#if defined (MCMODEL_SMALL)
+ desc-physical_start = 0x
+ #endif
+ desc-physical_start + PAGES_TO_BYTES (desc-num_pages) 0x10
+@@ -321,7 +321,7 @@ filter_memory_map (grub_efi_memory_descriptor_t
*memory_map,
+ desc-physical_start = 0x10;
+ }
+
+-#if 1
++#if defined (MCMODEL_SMALL)
+ if (BYTES_TO_PAGES (filtered_desc-physical_start)
+ + filtered_desc-num_pages
+ BYTES_TO_PAGES (0x1LL))
+--
+1.7.1
+
diff --git a/meta/recipes-bsp/grub/grub-efi_2.00.bb
b/meta/recipes-bsp/grub/grub-efi_2.00.bb
index 2fe688c..deb9514 100644
--- a/meta/recipes-bsp/grub/grub-efi_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi_2.00.bb
@@ -27,6 +27,7 @@ SRC_URI = ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
file://grub-no-unused-result.patch \
file://grub-2.00-ignore-gnulib-gets-stupidity.patch \
file://fix-issue-with-flex-2.5.37.patch \
+ file://grub-efi-allow-a-compilation-without-mcmodel-large.patch \
SRC_URI[md5sum] = e927540b6eda8b024fb0391eeaa4091c
SRC_URI[sha256sum] =
65b39a0558f8c802209c574f4d02ca263a804e8a564bc6caf1cd0fd3b3cc11e3
--
1.8.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2 v4] grub-efi: change to generate EFI image in target package
From: Jackie Huang jackie.hu...@windriver.com
v4 comments:
no code changes, only added some detail informations explaining whay the change
is necessary and fix the incorrect Upstream-Status statement for the patch.
--
The following changes since commit ee3e2e5ce15a3bf78c7e9d76d7bf68131f2d3ef7:
librsvg: upgrade to 2.40.0 (2013-11-20 14:03:06 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib jhuang0/d_grub-efi_1122_0
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/d_grub-efi_1122_0
Jackie Huang (2):
grub-efi: change to generate EFI image in target package
grub-efi: allow compilation without large model support
meta/classes/grub-efi.bbclass | 4 +-
...allow-a-compilation-without-mcmodel-large.patch | 81 ++
.../{grub-efi-native_2.00.bb = grub-efi_2.00.bb} | 44 +++-
3 files changed, 108 insertions(+), 21 deletions(-)
create mode 100644
meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
rename meta/recipes-bsp/grub/{grub-efi-native_2.00.bb = grub-efi_2.00.bb}
(77%)
--
1.8.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] bind: add support for read-only rootfs
On 11/21/2013 08:12 PM, Phil Blundell wrote: On Thu, 2013-11-21 at 00:59 -0600, Mark Hatle wrote: +# When using a read-only rootfs additional setup may be required +# uncomment the following line to make bind start in read-only rootfs +#ALLOW_ROOTFS_READ_ONLY=yes If the filesystem is read-only then it's going to be fairly difficult for the user to uncomment this line on the target. Hi Phil, I think the user can remount it read-write or just do it at rootfs time. Why would you ever want this variable to be set to anything other than yes? If your filesystem is not in fact read-only then it isn't going to have any effect, and if your filesystem is read-only then bind won't work without it. The purpose is to disable bind in a read-only file system by default. But if user really wants it, they can set this value to 'yes'. ++ [ `is_on_read_only_partition /etc/bind` = yes ] bind_mount /var/volatile/bind/etc /etc/bind ++ [ `is_on_read_only_partition /var/named` = yes ] bind_mount /var/volatile/bind/named /var/named Is it really necessary to mount a tmpfs at /etc/bind? Can't those files just be relocated somewhere else? I'm afraid not. At least I don't know how. Best Regards, Chen Qi p. ___ 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] syslinux: check for __i386__ and __x86_64__ instead of __SIZEOF_POINTER__
From: Lei Liu lei.l...@windriver.com (Note: this patch is being sent for Yocto Project compliance, I don't believe it is generally applicable to oe-core as it's only needed on older host systems.) GCC version 4.2 and earlier does not define __SIZEOF_POINTER__. Check for __i386__ and __x86_64__ instead to make the code compile with old compiler. Signed-off-by: Lei Liu lei.l...@windriver.com Signed-off-by: Randy MacLeod randy.macl...@windriver.com --- .../syslinux/files/gcc-compatibility.patch | 491 + meta/recipes-devtools/syslinux/syslinux_6.01.bb| 4 +- 2 files changed, 494 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-devtools/syslinux/files/gcc-compatibility.patch diff --git a/meta/recipes-devtools/syslinux/files/gcc-compatibility.patch b/meta/recipes-devtools/syslinux/files/gcc-compatibility.patch new file mode 100644 index 000..b291e29 --- /dev/null +++ b/meta/recipes-devtools/syslinux/files/gcc-compatibility.patch @@ -0,0 +1,491 @@ +Check for __i386__ and __x86_64__ instead of __SIZEOF_POINTER__ + +Upstream-Status: Pending + +Signed-off-by: Lei Liu lei.l...@windriver.com +--- + com32/include/bitsize/limits.h |4 ++-- + com32/include/bitsize/stddef.h |4 ++-- + com32/include/bitsize/stdint.h |4 ++-- + com32/include/bitsize/stdintconst.h |4 ++-- + com32/include/bitsize/stdintlimits.h |4 ++-- + com32/include/byteswap.h |4 ++-- + com32/include/setjmp.h |4 ++-- + com32/include/sys/bitops.h |4 ++-- + com32/include/sys/cpu.h |4 ++-- + com32/include/sys/module.h |4 ++-- + com32/lib/libgcc/__muldi3.S |4 ++-- + com32/lib/setjmp.S |4 ++-- + com32/lib/sys/farcall.c |4 ++-- + com32/lib/sys/x86_init_fpu.c | 12 ++-- + com32/sysdump/cpuid.c|4 ++-- + core/call16.c|4 ++-- + core/lzo/enter.ash |4 ++-- + core/lzo/leave.ash |4 ++-- + dos/stdlib.h |4 ++-- + efi/main.c |6 +++--- + efi/wrapper.c|4 ++-- + memdisk/memdisk.h|2 +- + memdisk/setup.c |4 ++-- + memdisk/start32.S|4 ++-- + memdump/code16.h |2 +- + 25 files changed, 53 insertions(+), 53 deletions(-) + +diff --git a/com32/include/bitsize/limits.h b/com32/include/bitsize/limits.h +index 7129c4a..407c720 100644 +--- a/com32/include/bitsize/limits.h b/com32/include/bitsize/limits.h +@@ -5,9 +5,9 @@ + #ifndef _BITSIZE_LIMITS_H + #define _BITSIZE_LIMITS_H + +-#if __SIZEOF_POINTER__ == 4 ++#if defined (__i386__) + #include bitsize32/limits.h +-#elif __SIZEOF_POINTER__ == 8 ++#elif defined (__x86_64__) + #include bitsize64/limits.h + #else + #error Unable to build for to-be-defined architecture type +diff --git a/com32/include/bitsize/stddef.h b/com32/include/bitsize/stddef.h +index 04418a0..bbf070b 100644 +--- a/com32/include/bitsize/stddef.h b/com32/include/bitsize/stddef.h +@@ -5,9 +5,9 @@ + #ifndef _BITSIZE_STDDEF_H + #define _BITSIZE_STDDEF_H + +-#if __SIZEOF_POINTER__ == 4 ++#if defined (__i386__) + #include bitsize32/stddef.h +-#elif __SIZEOF_POINTER__ == 8 ++#elif defined (__x86_64__) + #include bitsize64/stddef.h + #else + #error Unable to build for to-be-defined architecture type +diff --git a/com32/include/bitsize/stdint.h b/com32/include/bitsize/stdint.h +index 7e7b235..500a53b 100644 +--- a/com32/include/bitsize/stdint.h b/com32/include/bitsize/stdint.h +@@ -13,9 +13,9 @@ typedef unsigned charuint8_t; + typedef unsigned short intuint16_t; + typedef unsigned int uint32_t; + +-#if __SIZEOF_POINTER__ == 4 ++#if defined (__i386__) + #include bitsize32/stdint.h +-#elif __SIZEOF_POINTER__ == 8 ++#elif defined (__x86_64__) + #include bitsize64/stdint.h + #else + #error Unable to build for to-be-defined architecture type +diff --git a/com32/include/bitsize/stdintconst.h b/com32/include/bitsize/stdintconst.h +index b2f3141..7caf937 100644 +--- a/com32/include/bitsize/stdintconst.h b/com32/include/bitsize/stdintconst.h +@@ -5,9 +5,9 @@ + #ifndef _BITSIZE_STDINTCONST_H + #define _BITSIZE_STDINTCONST_H + +-#if __SIZEOF_POINTER__ == 4 ++#if defined (__i386__) + #include bitsize32/stdintconst.h +-#elif __SIZEOF_POINTER__ == 8 ++#elif defined (__x86_64__) + #include bitsize64/stdintconst.h + #else + #error Unable to build for to-be-defined architecture type +diff --git a/com32/include/bitsize/stdintlimits.h b/com32/include/bitsize/stdintlimits.h +index c342c44..78f1e89 100644 +--- a/com32/include/bitsize/stdintlimits.h b/com32/include/bitsize/stdintlimits.h +@@ -5,9 +5,9 @@ + #ifndef _BITSIZE_STDINTLIMITS_H + #define _BITSIZE_STDINTLIMITS_H + +-#if __SIZEOF_POINTER__ == 4 ++#if defined (__i386__) +
Re: [OE-core] [PATCH] matchbox-keyboard: check and link against libXrender
On 21 November 2013 07:22, Mark Hatle mark.ha...@windriver.com wrote: +Upstream-Status: Pending This is sad considering that we host the git repo for this. I've merged an equivalent fix from master to the 0.1 branch in git, merged in some more patches that we were hanging on to were already in master, and have a patch to oe-core that I'm just testing now to move our recipe to match. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [master][dora][PATCH 2/2] perf: Disable -Werror flag
On 13-11-21 02:33 AM, Mark Hatle wrote:
From: Konrad Scherer konrad.sche...@windriver.com
If the sed command does not run before make is invoked, the compile
fails. Defining the environment variable is the proper way to disable
warnings as errors build option and eliminates the race condition.
Signed-off-by: Konrad Scherer konrad.sche...@windriver.com
Signed-off-by: Randy MacLeod randy.macl...@windriver.com
---
meta/recipes-kernel/perf/perf.bb | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 138595d..1b889aa 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -40,6 +40,7 @@ export STAGING_INCDIR
export STAGING_LIBDIR
export BUILD_SYS
export HOST_SYS
+export WERROR = 0
do_populate_lic[depends] += virtual/kernel:do_populate_sysroot
@@ -118,10 +119,6 @@ do_install() {
fi
}
-do_configure_prepend () {
-sed -i 's,-Werror ,,' ${S}/tools/perf/Makefile
-}
-
This is will not work for kernels 3.1. I did submit another patch
which works for all kernel versions.
--
Konrad Scherer, MTS, Linux Products Group, Wind River
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ia32-base: Remove cpio and ext3 defaults
On Thu, 2013-11-21 at 15:25 +, Richard Purdie wrote: On real IA hardware, neither the ext3 or cpio images are particularly useful or used. cpio is legacy from initramfs and that specific image now overrides FSTYPES accordingly. The size difference in filesystems makes ext3 as a file format less useful, mainly being useful in the qemu case. When needed users can still override the default FSTYPES so having saner defaults makes sense. This improves build times and uses less network bandwidth for builds and releases. Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org I'm fine with this, although it raises the question if we ought to be doing anything more than tar rootfs in include files like this. there are ia32 machines where a live image is not useful (although rare). Most x86 BSPs would add live - but then again, most x86 BSPs will be starting to consolidate on the genericx86 BSPs anyway But, this is a clear improvement as is. Acked-by: Darren Hart dvh...@linux.intel.com --- diff --git a/meta/conf/machine/include/ia32-base.inc b/meta/conf/machine/include/ia32-base.inc index 8a20bca..e15f927 100644 --- a/meta/conf/machine/include/ia32-base.inc +++ b/meta/conf/machine/include/ia32-base.inc @@ -10,7 +10,7 @@ MACHINE_FEATURES += screen keyboard pci usbhost ext2 ext3 x86 \ MACHINE_EXTRA_RRECOMMENDS += kernel-modules -IMAGE_FSTYPES += ext3 cpio.gz live +IMAGE_FSTYPES += live KERNEL_IMAGETYPE ?= bzImage -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [master][dora][PATCH 1/2] perf: disallow debug optimization.
On Thu, 2013-11-21 at 14:25 +, Phil Blundell wrote: On Thu, 2013-11-21 at 01:33 -0600, Mark Hatle wrote: +def get_optimization(d): +selected_optimization = d.getVar(SELECTED_OPTIMIZATION, True) +if base_contains(SELECTED_OPTIMIZATION, -O0, x, , d) == x: +bb.note(eglibc can't be built with -O0, -O2 will be used instead.) Although the text of that warning is correct, users might find the reference to eglibc slightly confusing if it's perf that they're trying to build. Also, as I mentioned in a different thread not all that long ago when someone submitted a similar patch for gcc-runtime, the proliferation of parse-time python functions to bash SELECTED_OPTIMIZATION around doesn't seem like all that good a thing: this will cause extra overhead for everyone, even those who are not using -O0 and have no interest in perf. And, finally, it remains slightly unclear to me that this is really a problem that the metadata needs to be solving. I haven't seen any particularly convincing explanation of why this can't or shouldn't just be fixed in the distro configuration. I have to admit at this point, this may look better as an include file along the lines of: SELECTED_OPTIMIZATION = -O0 SELECTED_OPTIMIZATION_pn-eglibc = -O2 SELECTED_OPTIMIZATION_pn-perf = -O2 since clutter the recipes with anonymous python fragments isn't particular desirable. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [master][dora][PATCH 1/2] perf: disallow debug optimization.
On 11/21/13, 8:35 AM, Richard Purdie wrote: On Thu, 2013-11-21 at 14:25 +, Phil Blundell wrote: On Thu, 2013-11-21 at 01:33 -0600, Mark Hatle wrote: +def get_optimization(d): +selected_optimization = d.getVar(SELECTED_OPTIMIZATION, True) +if base_contains(SELECTED_OPTIMIZATION, -O0, x, , d) == x: +bb.note(eglibc can't be built with -O0, -O2 will be used instead.) Although the text of that warning is correct, users might find the reference to eglibc slightly confusing if it's perf that they're trying to build. Also, as I mentioned in a different thread not all that long ago when someone submitted a similar patch for gcc-runtime, the proliferation of parse-time python functions to bash SELECTED_OPTIMIZATION around doesn't seem like all that good a thing: this will cause extra overhead for everyone, even those who are not using -O0 and have no interest in perf. And, finally, it remains slightly unclear to me that this is really a problem that the metadata needs to be solving. I haven't seen any particularly convincing explanation of why this can't or shouldn't just be fixed in the distro configuration. I have to admit at this point, this may look better as an include file along the lines of: SELECTED_OPTIMIZATION = -O0 SELECTED_OPTIMIZATION_pn-eglibc = -O2 SELECTED_OPTIMIZATION_pn-perf = -O2 since clutter the recipes with anonymous python fragments isn't particular desirable. Thats part of the problem. We only need to set -O2, when someone sets -O0. But if they set -O1 or -Os (or any other -O...) it appears to work properly... So the python fragment is used to establish a known functional set for that item. --Mark Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] shadow: remove reference to locale env files from su
On 11/21/2013 01:14 AM, qiang.c...@windriver.com wrote: From: Qiang Chen qiang.c...@windriver.com The /etc/default/locale missing message appears when running su user root@qemu0:/var/log# su root root@qemu0:/var/log# tail auth.log Oct 8 07:47:54 qemu0 login[983]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) Oct 8 07:47:55 qemu0 login[995]: ROOT LOGIN on '/dev/console' Oct 8 07:48:21 qemu0 su[999]: Successful su for root by root Oct 8 07:48:21 qemu0 su[999]: + /dev/console root:root Oct 8 07:48:21 qemu0 su[999]: pam_env(su:session): Unable to open env file: /etc/default/locale: No such file or directory Oct 8 07:48:21 qemu0 su[999]: pam_unix(su:session): session opened for user root by root(uid=0) This commit remove reference from pam.d/su to /etc/default/locale env file to avoid the error messages. Signed-off-by: Qiang Chen qiang.c...@windriver.com --- meta/recipes-extended/shadow/files/pam.d/su |3 --- meta/recipes-extended/shadow/shadow.inc |2 +- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/meta/recipes-extended/shadow/files/pam.d/su b/meta/recipes-extended/shadow/files/pam.d/su index 8e35137..8d590a3 100644 --- a/meta/recipes-extended/shadow/files/pam.d/su +++ b/meta/recipes-extended/shadow/files/pam.d/su @@ -34,9 +34,6 @@ auth sufficient pam_rootok.so # # parsing /etc/environment needs readenv=1 session required pam_env.so readenv=1 -# locale variables are also kept into /etc/default/locale in etch -# reading this file *in addition to /etc/environment* does not hurt -session required pam_env.so readenv=1 envfile=/etc/default/locale Should we be providing an empty locale file instead, what happens if someone wants to use the locale mechanism? # Defines the MAIL environment variable # However, userdel also needs MAIL_DIR and MAIL_FILE variables diff --git a/meta/recipes-extended/shadow/shadow.inc b/meta/recipes-extended/shadow/shadow.inc index 5ab978a..572c3bc 100644 --- a/meta/recipes-extended/shadow/shadow.inc +++ b/meta/recipes-extended/shadow/shadow.inc @@ -44,7 +44,7 @@ SRC_URI_append_class-nativesdk = \ SRC_URI[md5sum] = b8608d8294ac88974f27b20f991c0e79 SRC_URI[sha256sum] = 633f5bb4ea0c88c55f3642c97f9d25cbef74f82e0b4cf8d54e7ad6f9f9caa778 -PR = r13 +PR = r14 No more PR bumps please. Sau! # Additional Policy files for PAM PAM_SRC_URI = file://pam.d/chfn \ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [dora][PATCH] libsoup: workaround oe-core mips-gcc ICE
From: Wenzong Fan wenzong@windriver.com
(Note: this is being sent for Yocto Project compliance. The bug is in the
dora oe-core version of the compiler, but only if using -O0.. I consider
it a temporary workaround.)
This error occurs for builds with the oe-core toolchain in debug builds:
header-parsing.c:1263:1: internal compiler error: in
dwarf2out_var_location, at dwarf2out.c:20810
}
^
...
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
{standard input}: Assembler messages:
{standard input}: Warning: missing .end at end of assembly
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
make[3]: *** [header-parsing.o] Error 1
This happens only with optimization option '-O', so force to use '-O2' for mips
target to workaround this issue. Root cause will be addressed.
Signed-off-by: Wenzong Fan wenzong@windriver.com
Signed-off-by: Randy MacLeod randy.macl...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
---
meta/recipes-support/libsoup/libsoup-2.4_2.42.1.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.42.1.bb
b/meta/recipes-support/libsoup/libsoup-2.4_2.42.1.bb
index ef8d439..01ede17 100644
--- a/meta/recipes-support/libsoup/libsoup-2.4_2.42.1.bb
+++ b/meta/recipes-support/libsoup/libsoup-2.4_2.42.1.bb
@@ -26,3 +26,7 @@ inherit autotools pkgconfig
# glib-networking is needed for SSL, proxies, etc.
RRECOMMENDS_${PN} = glib-networking
+
+# Workaround oe-core mips-gcc internal compiler error with '-O':
+# header-parsing.c:1263:1: internal compiler error: in dwarf2out_var_location,
at dwarf2out.c:20810
+CFLAGS_mips += -O2
--
1.8.1.2.545.g2f19ada
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [master][dora][PATCH 1/2] perf: disallow debug optimization.
On Thu, 2013-11-21 at 15:57 +, Phil Blundell wrote: On Thu, 2013-11-21 at 08:47 -0600, Mark Hatle wrote: We have users who desire to build their system at different levels of optimizations for debug, size, profiling, etc. So they do change the default optimization levels from -O2 to -O0, etc. The python fragement is used to only adjust -O0, as -O1 (or -Os) work correctly. Sure, I understand what the python is doing. The things I'm not quite so clear about are: a) If the user asks to build with -O0, is it appropriate for the metadata to second-guess this and quietly switch to using -O2 instead when it thinks it knows best? I suppose the other question is: why exactly does perf fail to build at -O0, and can we just patch it so that it works rather than forcing optimisation on? Even if it can't be fixed, it would be good for the commit message associated with any workaround to explain what the problem is. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa/connman: disable unique test
The connman unique test starts another instance of connmand and then does a ps
to
verify that there's only one of these running, on the assumption that the new
one has quit because there's already one running (started by init).
However, connmand is forking into the background straight away so there's a race
between running ps and the second connmand discovering the first and exiting.
This race can be seen because the test displays the output of ps, and by the
time that second ps has been executed the new connmand has exited.
This is a classic race condition and on a heavily loaded autobuilder inserting
an arbitrary sleep isn't wise. In the scheme of things this test isn't very
useful, so delete it.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/lib/oeqa/runtime/connman.py |8
1 file changed, 8 deletions(-)
diff --git a/meta/lib/oeqa/runtime/connman.py b/meta/lib/oeqa/runtime/connman.py
index 5ef96f6..b592ecc 100644
--- a/meta/lib/oeqa/runtime/connman.py
+++ b/meta/lib/oeqa/runtime/connman.py
@@ -19,11 +19,3 @@ class ConnmanTest(oeRuntimeTest):
def test_connmand_running(self):
(status, output) = self.target.run(oeRuntimeTest.pscmd + ' | grep
[c]onnmand')
self.assertEqual(status, 0, msg=no connmand process, ps output: %s %
self.target.run(oeRuntimeTest.pscmd)[1])
-
-@skipUnlessPassed('test_connmand_running')
-def test_connmand_unique(self):
-self.target.run('/usr/sbin/connmand')
-output = self.target.run(oeRuntimeTest.pscmd + ' | grep -c
[c]onnmand')[1]
-self.assertEqual(output, 1, msg=more than one connmand running in
background, ps output: %s\n%s % (output,
self.target.run(oeRuntimeTest.pscmd)[1]))
-
-
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/1] lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist
On Thu, 2013-11-21 at 21:39 +0800, Hongxu Jia wrote: Hi All, In this case, there are two 'packagegroup-core-nfs-server-1.0-r2.0.all.rpm' in tmp/deploy/rpm/all. One is made by 'bitbake packagegroup-core-nfs ', and the other is made by 'bitbake lib32-packagegroup-core-nfs '. The last one overrode the previous triggered the QA check. By default, packagegroup inherit allarch, which means the PACKAGE_ARCH is all. Is it proper that 'all' packages are not supposed to be expanded into the multilib versions? Yes. There are some other packagegroup recipes have the similar issue. It sounds like there is some configuration causing this to get rebuild. Can you run bitbake-diffsigs on the stamps for the two tasks and see why its building this twice? It sound only happen once. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 1/1] lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist
Hi All,
In this case, there are two 'packagegroup-core-nfs-server-1.0-r2.0.all.rpm'
in tmp/deploy/rpm/all. One is made by 'bitbake packagegroup-core-nfs ',
and the other is made by 'bitbake lib32-packagegroup-core-nfs '.
The last one overrode the previous triggered the QA check.
By default, packagegroup inherit allarch, which means the PACKAGE_ARCH
is all.
Is it proper that 'all' packages are not supposed to be expanded into the
multilib versions?
There are some other packagegroup recipes have the similar issue.
//Hongxu
On 11/14/2013 05:02 PM, Hongxu Jia wrote:
By default, packagegroup-core-nfs do not depend on a certain architecture,
there will be qa warning while multilib enabled.
$ bitbake packagegroup-core-nfs
$ bitbake lib32-packagegroup-core-nfs
...
WARNING: The recipe lib32-packagegroup-core-nfs is trying to install files into
a shared area when those files already exist. Those files and their manifest
location are:
tmp/deploy/rpm/all/packagegroup-core-nfs-server-1.0-r2.0.all.rpm
Matched in manifest-allarch-packagegroup-core-nfs.deploy-rpm
Please verify which package should provide the above files.
...
Set PACKAGE_ARCH with MACHINE_ARCH fixed this issue.
[YOCTO #5532]
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-core/packagegroups/packagegroup-core-nfs.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
index 531eceb..b57ef63 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
@@ -7,6 +7,7 @@ LICENSE = MIT
PR = r2
inherit packagegroup
+PACKAGE_ARCH = ${MACHINE_ARCH}
PACKAGES = ${PN}-server
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] qemu: add bash and python to qemu's RDEPENDS
Why are you adding bash to qemu?
Sau!
On 11/21/2013 05:14 AM, Hongxu Jia wrote:
| Note: adding Smart RPM DB channel
|
| Note: to be installed: qemu@x86_64 run-postinsts@x86_64
kernel-modules@qemux86_64 packagegroup-core-boot@qemux86_64
| Loading cache...
| Updating cache...
[100%]
|
| Computing transaction...error: Can't install qemu-1.5.0-r0.0@x86_64: no
package provides /usr/bin/python
|
| Saving cache...
|
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_rootfs (log file is located at
tmp/work/qemux86_64-wrs-linux/wrlinux-image-glibc-small/1.0-r1/temp/do_rootfs/log.do_rootfs.21373)
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 21ce489..3f3431d 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -5,6 +5,7 @@ DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11 pixman dtc
libsdl
DEPENDS_class-native = zlib-native alsa-lib-native glib-2.0-native pixman-native
dtc-native
DEPENDS_class-nativesdk = nativesdk-zlib nativesdk-libsdl nativesdk-glib-2.0
nativesdk-pixman nativesdk-dtc
RDEPENDS_${PN}_class-nativesdk = nativesdk-libsdl
+RDEPENDS_${PN}_class-target += bash python
require qemu-targets.inc
inherit autotools
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] license.bbclass: fix copying license directories failed
Hi Hongxu,
On Wednesday 20 November 2013 18:39:02 Hongxu Jia wrote:
For each recipe, it populated license files to ${LICENSE_DIRECTORY}/${PN},
such as kernel's license dir was
${LICENSE_DIRECTORY}/kernel-3.10.17-yocto-standard;
In do_rootfs task, it copied license directories from ${LICENSE_DIRECTORY}/
${pkg}, and ${pkg} was listed in ${INSTALLED_PKGS};
We got ${INSTALLED_PKGS} by rpm query, such as the kernel were 'kernel-*',
but the kernel's PN was linux-yocto, so searching ${LICENSE_DIRECTORY}/
kernel-* failed.
Copied license directories from ${LICENSE_DIRECTORY}/${PN} fixed this issue.
[YOCTO #5572]
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/classes/license.bbclass | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index 6d7ee94..32605ff 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -68,15 +68,18 @@ license_create_manifest() {
if [ ${COPY_LIC_DIRS} = 1 ]; then
for pkg in ${INSTALLED_PKGS}; do
mkdir -p
${IMAGE_ROOTFS}/usr/share/common-licenses/${pkg}
- for lic in `ls ${LICENSE_DIRECTORY}/${pkg}`; do
+ pkged_pn=$(sed -n /^PACKAGE NAME:
${pkg}$/,/^$/ \
+ {s/^RECIPE NAME: //; /^PACKAGE
NAME:/d; /^PACKAGE VERSION:/d; /^LICENSE:/d; p} \ +
${LICENSE_MANIFEST})
+ for lic in `ls
${LICENSE_DIRECTORY}/${pkged_pn}`; do
This isn't the right way to do this. If you need to look up the recipe name
from the target package name, in master you can now use:
oe-pkgdata-util lookup-recipe ${PKGDATA_DIR} list of packages
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] [master][dora][PATCH 1/2] perf: disallow debug optimization.
On Thu, 2013-11-21 at 08:47 -0600, Mark Hatle wrote: We have users who desire to build their system at different levels of optimizations for debug, size, profiling, etc. So they do change the default optimization levels from -O2 to -O0, etc. The python fragement is used to only adjust -O0, as -O1 (or -Os) work correctly. Sure, I understand what the python is doing. The things I'm not quite so clear about are: a) If the user asks to build with -O0, is it appropriate for the metadata to second-guess this and quietly switch to using -O2 instead when it thinks it knows best? Personally I am inclined to say that attempting to use -O0 with packages that don't support it should just produce an error and the user should fix their configuration to not do that. And, if we're going to enable optimisation that the user hasn't asked for, shouldn't it be the minimum level consistent with getting the package to build rather than the full -O2 set? b) If the answer to (a) is that the metadata should indeed be doing this, can it be made to do so in a way that doesn't involve running extra python fragments for all users every time the recipe is parsed? c) If the answer to (b) is no, is the feature really so important that it's worth adding extra overhead to the parse for all users in order to benefit the (presumably tiny) minority who might actually be trying to build perf at -O0? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] packagegroup-core-tools-profile: add systemd-analyze
If the systemd DISTRO_FEATURE is enabled, then recommend systemd-analyze for
profiling boot performance.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb |2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
index 9eb1458..4a97c24 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
@@ -17,6 +17,7 @@ RREPLACES_${PN} = task-core-tools-profile
RCONFLICTS_${PN} = task-core-tools-profile
PROFILE_TOOLS_X = ${@base_contains('DISTRO_FEATURES', 'x11', 'sysprof', '',
d)}
+PROFILE_TOOLS_SYSTEMD = ${@base_contains('DISTRO_FEATURES', 'systemd',
'systemd-analyze', '', d)}
RRECOMMENDS_${PN} = \
perf \
@@ -24,6 +25,7 @@ RRECOMMENDS_${PN} = \
kernel-module-oprofile \
blktrace \
${PROFILE_TOOLS_X} \
+${PROFILE_TOOLS_SYSTEMD} \
PROFILETOOLS = \
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Improving Build Speed
On Thu, Nov 21, 2013 at 08:15:08AM +0100, Ulf Samuelsson wrote: 2013-11-21 01:19, Martin Jansa skrev: On Wed, Nov 20, 2013 at 11:43:13PM +0100, Ulf Samuelsson wrote: 2013-11-20 22:29, Richard Purdie skrev: Another idea: I suspect that there is a lot of unpacking and patching of recipes for the target when the native stuff is built. Does it make sense to have multiple threads reading the disk, for the target recipes during the native build or will we just lose out due to seek time? Having multiple threads accessing the disk, might force the disk to spend most of its time seeking. Found an application which measures seek time performance, and my WD Black will do 83 seeks per second, and my SAS disk will do twice that. The RAID of two SAS disks will provide close to SSD throughput (380 MB/s) but seek time is no better than a single SAS disk. Since there is empty time at the end of the native build, does it make sense to minimize unpack/patch of target stuff when we reach that point, and then we let loose? In my benchmarks increasing PARALLEL_MAKE till number of cores was significantly improving build time, but BB_NUMBER_THREADS had minimal influence somewhere above 6 or 8 (tested on various systems, even only 4 was optimum on my older RAID-0 and 2 on single disk). Of course it was quite different for clean build without sstate prepopulated and build where most of the stuff was reused from sstate. see http://wiki.webos-ports.org/wiki/OE_benchmark How many cores do you have in your build machine? The one used in OE_benchmark has 8, my local builder also 8, I got the same results on machines with 32 and 48 cores. My experience (which can be different than what you see), is that PARALLEL_MAKE scales well with number of cores, but BB_NUMBER_THREADS is more or less limited by I/O performance, so even when the machine has 48 cores, it doesn't say anything about running 48 do_populate or do_package tasks at the same time causing avalanche of seeks. The other extreme is when all 48 BB threads are in do_compile and you can get 48x48 gcc processes which again doesn't work well on machine with 48 cores. with PARALLEL_MAKE = -j32 BB_NUMBER_THREADS =6 and very big image build, I see all cores well used most of the time. I started a build, and after 20 minutes it had completed 1500 tasks using: PARALLEL_MAKE = -j24 BB_NUMBER_THREADS = 6 The I decided to kill it. When I did PARALLEL_MAKE = -j12 BB_NUMBER_THREADS = 24 It completed 2000 tasks in less than half the time. You should have finish whole image, you can get 2000 tasks sooner (tasks like fetch/unpack/patch) but then you're still waiting for the rest, with smaller BB_NUMBER_THREADS it seems to spread tasks more evenly (doing more fetch/unpack/patch tasks later when CPUs are busy compiling something, which is good for I/O). This does not use tmpfs though. Do you have any comparision between tmpfs builds and RAID builds? I've sent it to ML few months ago, cannot find it now. I currently do not use INHERIT += rm_work since I want to be able to do changes on some packages. Is there a way to defined rm_work on a package basis? Then the majority of the packages can be removed. I use 75 GB without rm_work Understood, in my scenario I want to build world as soon as possible, keep sstate, record issues and forget about BUILDDIR. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] distro/machine:kernel feature mapping and version checking
All, Regarding the following 2 bugs: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5574 Add kernel version / configuration check mechanism and https://bugzilla.yoctoproject.org/show_bug.cgi?id=2267 Integrate DISTRO_FEATURES with KERNEL_FEATURES There is a need to reduce errors where a DISTRO config might break due to lack of kernel support, things such as systemd. There is also interest in enabling certain kernel features based on DISTRO/MACHINE_FEATURES, such as wifi. Neither of these should depend on the Kernel Version as even with the right version, if the CONFIG_* feature is missing, the image will not work correctly. There is also the risk of false negatives when a feature has been backported to a kernel version that didn't have the feature previously. The recommended approach would be to check for the required CONFIG_* options after the linux-yocto configuration stage. There is also the topic of DISTRO_FEATURES ~= wifi impacting how the kernel will be built. The MACHINE should have some say in how this is done - if the machine can never have wifi, building wifi into the kernel doesn't make a lot of sense. Something like the following might make sense: for FEATURE in DISTRO_FEATURES: if MACHINE_FEATURES contains FEATURES: KERNEL_FEATURES += FEATURE_override Where FEATURE_override is defined something like this: FEATURE = FEATURE_default if exists FEATURE_distro: FEATURE = FEATURE_distro if exists FEATURE_machine: FEATURE = FEATURE_machine This is effectively a fragment name which needs to be provided by the linux-yocto kernel meta data as it will be kernel version dependent. The linkage I'm not sure about is how to know what to test for in the kernel.bbclass without intimate knowledge of the kernel version CONFIG options in recipe space. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [master][dora][PATCH 1/2] perf: disallow debug optimization.
On Thu, 2013-11-21 at 14:35 +, Richard Purdie wrote: I have to admit at this point, this may look better as an include file along the lines of: SELECTED_OPTIMIZATION = -O0 SELECTED_OPTIMIZATION_pn-eglibc = -O2 SELECTED_OPTIMIZATION_pn-perf = -O2 since clutter the recipes with anonymous python fragments isn't particular desirable. Right, exactly. This is what I already do in my distro configuration to deal with a similar situation involving -fasynchronous-unwind-tables and it works fine. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] bind: add support for read-only rootfs
On Thu, 2013-11-21 at 20:24 +0800, ChenQi wrote: The purpose is to disable bind in a read-only file system by default. But if user really wants it, they can set this value to 'yes'. I'm still struggling a bit to understand the reasoning here. Why would you install bind in the first place if you didn't want it to be enabled? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [dora][PATCH] Qemu:Arm:versatilepb: Add memory size checking
From: Jiang Lu lu.ji...@windriver.com
The machine can not work with memory over 256M, so add a checking
at startup. If the memory size exceed 256M, just stop emulation then
throw out warning about memory limitation.
Signed-off-by: Jiang Lu lu.ji...@windriver.com
Signed-off-by: Robert Yang liezhi.y...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
---
...-Arm-versatilepb-Add-memory-size-checking.patch | 34 ++
meta/recipes-devtools/qemu/qemu_1.5.0.bb | 1 +
2 files changed, 35 insertions(+)
create mode 100644
meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
diff --git
a/meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
b/meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
new file mode 100644
index 000..ef1090b
--- /dev/null
+++
b/meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
@@ -0,0 +1,34 @@
+From 896fa02c24347e6e9259812cfda187b1d6ca6199 Mon Sep 17 00:00:00 2001
+From: Jiang Lu lu.ji...@windriver.com
+Date: Wed, 13 Nov 2013 10:38:08 +0800
+Subject: [PATCH] Qemu:Arm:versatilepb: Add memory size checking
+
+The machine can not work with memory over 256M, so add a checking
+at startup. If the memory size exceed 256M, just stop emulation then
+throw out warning about memory limitation.
+
+Signed-off-by: Jiang Lu lu.ji...@windriver.com
+---
+ hw/arm/versatilepb.c |6 ++
+ 1 files changed, 6 insertions(+), 0 deletions(-)
+
+diff --git a/hw/arm/versatilepb.c b/hw/arm/versatilepb.c
+index 753757e..0906377 100644
+--- a/hw/arm/versatilepb.c
b/hw/arm/versatilepb.c
+@@ -193,6 +193,12 @@ static void versatile_init(QEMUMachineInitArgs *args, int
board_id)
+ fprintf(stderr, Unable to find CPU definition\n);
+ exit(1);
+ }
++if (ram_size (256 20)) {
++fprintf(stderr,
++qemu: Too much memory for this machine: %d MB, maximum 256
MB\n,
++((unsigned int)ram_size / (1 20)));
++exit(1);
++}
+ memory_region_init_ram(ram, versatile.ram, args-ram_size);
+ vmstate_register_ram_global(ram);
+ /* ??? RAM should repeat to fill physical memory space. */
+--
+1.7.1
+
diff --git a/meta/recipes-devtools/qemu/qemu_1.5.0.bb
b/meta/recipes-devtools/qemu/qemu_1.5.0.bb
index 06c2cdb..f8c60e8 100644
--- a/meta/recipes-devtools/qemu/qemu_1.5.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_1.5.0.bb
@@ -7,6 +7,7 @@ SRC_URI += file://fdt_header.patch \
file://target-i386-Fix-aflag-logic-for-CODE64-and-the-0x67-.patch \
file://target-ppc_fix_bit_extraction.patch \
file://fxrstorssefix.patch \
+file://Qemu-Arm-versatilepb-Add-memory-size-checking.patch \
SRC_URI_prepend = http://wiki.qemu.org/download/qemu-${PV}.tar.bz2;
--
1.8.1.2.545.g2f19ada
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] qemu: add bash and python to qemu's RDEPENDS
On 11/21/13, 12:42 PM, Saul Wold wrote:
Why are you adding bash to qemu?
My understanding is that there was a bash script that was added as well, once
the python rdepends was resolved.
--Mark
Sau!
On 11/21/2013 05:14 AM, Hongxu Jia wrote:
| Note: adding Smart RPM DB channel
|
| Note: to be installed: qemu@x86_64 run-postinsts@x86_64
kernel-modules@qemux86_64 packagegroup-core-boot@qemux86_64
| Loading cache...
| Updating cache...
[100%]
|
| Computing transaction...error: Can't install qemu-1.5.0-r0.0@x86_64: no
package provides /usr/bin/python
|
| Saving cache...
|
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_rootfs (log file is located at
tmp/work/qemux86_64-wrs-linux/wrlinux-image-glibc-small/1.0-r1/temp/do_rootfs/log.do_rootfs.21373)
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 21ce489..3f3431d 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -5,6 +5,7 @@ DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11 pixman dtc
libsdl
DEPENDS_class-native = zlib-native alsa-lib-native glib-2.0-native pixman-native
dtc-native
DEPENDS_class-nativesdk = nativesdk-zlib nativesdk-libsdl nativesdk-glib-2.0
nativesdk-pixman nativesdk-dtc
RDEPENDS_${PN}_class-nativesdk = nativesdk-libsdl
+RDEPENDS_${PN}_class-target += bash python
require qemu-targets.inc
inherit autotools
___
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] ethtool: add actual test names to make
Automake does not seem to be generating the correct target for buildtest-TESTS,
which
the recipe was using.
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-extended/ethtool/ethtool_3.12.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-extended/ethtool/ethtool_3.12.1.bb
b/meta/recipes-extended/ethtool/ethtool_3.12.1.bb
index 19bca2f..6615009 100644
--- a/meta/recipes-extended/ethtool/ethtool_3.12.1.bb
+++ b/meta/recipes-extended/ethtool/ethtool_3.12.1.bb
@@ -16,7 +16,7 @@ inherit autotools ptest
RDEPENDS_${PN}-ptest += make
do_compile_ptest() {
- oe_runmake buildtest-TESTS
+ oe_runmake test-cmdline test-features
}
do_install_ptest () {
--
1.8.3.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] lttng-ust: add python to lttng-ust's RDEPENDS
| Note: adding Smart RPM DB channel
|
| Note: to be installed: run-postinsts@x86_64 kernel-modules@qemux86_64
packagegroup-core-boot@qemux86_64 lttng-ust@x86_64
| Loading cache...
| Updating cache...
[100%]
|
| Computing transaction...error: Can't install lttng-ust-2:2.3.0-r0.0@x86_64:
no package provides /usr/bin/python
|
| Saving cache...
|
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_rootfs (log file is located at
tmp/work/qemux86_64-wrs-linux/wrlinux-image-glibc-small/1.0-r1/temp/do_rootfs/log.do_rootfs.13619)
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-kernel/lttng/lttng-ust_2.3.1.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-kernel/lttng/lttng-ust_2.3.1.bb
b/meta/recipes-kernel/lttng/lttng-ust_2.3.1.bb
index ae52ee8..228054e 100644
--- a/meta/recipes-kernel/lttng/lttng-ust_2.3.1.bb
+++ b/meta/recipes-kernel/lttng/lttng-ust_2.3.1.bb
@@ -11,6 +11,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c963eb366b781252b0bf0fdf1624d9e9 \
inherit autotools
DEPENDS = liburcu util-linux
+RDEPENDS_${PN} = python
# For backwards compatibility after rename
RPROVIDES_${PN} = lttng2-ust
--
1.8.1.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] xinput-calibrator: add formfactor to RDEPENDS
* 30xinput_calibrate.sh is calling . /etc/formfactor/config
breaking Xsession for images without formfactor
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
index d6b3021..1ffd6d8 100644
--- a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
+++ b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
@@ -27,5 +27,5 @@ do_install_append() {
install -m 0755 ${WORKDIR}/30xinput_calibrate.sh
${D}${sysconfdir}/X11/Xsession.d/
}
-RDEPENDS_${PN} = xinput
+RDEPENDS_${PN} = xinput formfactor
RRECOMMENDS_${PN} = pointercal-xinput
--
1.8.4.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dora][PATCH] Qemu:Arm:versatilepb: Add memory size checking
On 11/21/2013 11:35 AM, Mark Hatle wrote:
From: Jiang Lu lu.ji...@windriver.com
The machine can not work with memory over 256M, so add a checking
at startup. If the memory size exceed 256M, just stop emulation then
throw out warning about memory limitation.
Signed-off-by: Jiang Lu lu.ji...@windriver.com
Signed-off-by: Robert Yang liezhi.y...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
---
...-Arm-versatilepb-Add-memory-size-checking.patch | 34 ++
meta/recipes-devtools/qemu/qemu_1.5.0.bb | 1 +
2 files changed, 35 insertions(+)
create mode 100644
meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
diff --git
a/meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
b/meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
new file mode 100644
index 000..ef1090b
--- /dev/null
+++
b/meta/recipes-devtools/qemu/files/Qemu-Arm-versatilepb-Add-memory-size-checking.patch
@@ -0,0 +1,34 @@
+From 896fa02c24347e6e9259812cfda187b1d6ca6199 Mon Sep 17 00:00:00 2001
+From: Jiang Lu lu.ji...@windriver.com
+Date: Wed, 13 Nov 2013 10:38:08 +0800
+Subject: [PATCH] Qemu:Arm:versatilepb: Add memory size checking
+
+The machine can not work with memory over 256M, so add a checking
+at startup. If the memory size exceed 256M, just stop emulation then
+throw out warning about memory limitation.
+
No Upstream-Status: tag
Sau!
+Signed-off-by: Jiang Lu lu.ji...@windriver.com
+---
+ hw/arm/versatilepb.c |6 ++
+ 1 files changed, 6 insertions(+), 0 deletions(-)
+
+diff --git a/hw/arm/versatilepb.c b/hw/arm/versatilepb.c
+index 753757e..0906377 100644
+--- a/hw/arm/versatilepb.c
b/hw/arm/versatilepb.c
+@@ -193,6 +193,12 @@ static void versatile_init(QEMUMachineInitArgs *args, int
board_id)
+ fprintf(stderr, Unable to find CPU definition\n);
+ exit(1);
+ }
++if (ram_size (256 20)) {
++fprintf(stderr,
++qemu: Too much memory for this machine: %d MB, maximum 256
MB\n,
++((unsigned int)ram_size / (1 20)));
++exit(1);
++}
+ memory_region_init_ram(ram, versatile.ram, args-ram_size);
+ vmstate_register_ram_global(ram);
+ /* ??? RAM should repeat to fill physical memory space. */
+--
+1.7.1
+
diff --git a/meta/recipes-devtools/qemu/qemu_1.5.0.bb
b/meta/recipes-devtools/qemu/qemu_1.5.0.bb
index 06c2cdb..f8c60e8 100644
--- a/meta/recipes-devtools/qemu/qemu_1.5.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_1.5.0.bb
@@ -7,6 +7,7 @@ SRC_URI += file://fdt_header.patch \
file://target-i386-Fix-aflag-logic-for-CODE64-and-the-0x67-.patch
\
file://target-ppc_fix_bit_extraction.patch \
file://fxrstorssefix.patch \
+file://Qemu-Arm-versatilepb-Add-memory-size-checking.patch \
SRC_URI_prepend = http://wiki.qemu.org/download/qemu-${PV}.tar.bz2;
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4] fix some packages (kconfig-frontends/lttng-tools/lttng-ust/qemu) loss RDEPENDS on python
The following changes since commit 725fae65810c477882f7f9d02561362b3f603db0: bitbake: toasterui: fix typo (2013-11-20 14:06:49 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/fix-add-python http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-add-python Hongxu Jia (4): kconfig-frontends: add python to kconfig-frontends's RDEPENDS lttng-ust: add python to lttng-ust's RDEPENDS lttng-tools: add PACKAGECONFIG to support --enable-python-bindings and lttng-ust qemu: add bash and python to qemu's RDEPENDS .../kconfig-frontends/kconfig-frontends_3.12.0.0.bb | 1 + meta/recipes-devtools/qemu/qemu.inc | 1 + meta/recipes-kernel/lttng/lttng-tools_2.3.1.bb | 20 meta/recipes-kernel/lttng/lttng-ust_2.3.1.bb | 1 + 4 files changed, 19 insertions(+), 4 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][V2] matcbox-keyboard: bump SRCREV
Bump to the latest commit on the 0.1 branch.
Drop two redundant patches, and update the license data since upstream has been
re-licensed to LGPL v2.1.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../matchbox-keyboard/files/configure_fix.patch| 15 --
.../matchbox-keyboard/files/png-fix.patch | 49
.../matchbox-keyboard/matchbox-keyboard_git.bb | 14 +++---
3 files changed, 6 insertions(+), 72 deletions(-)
delete mode 100644
meta/recipes-sato/matchbox-keyboard/files/configure_fix.patch
delete mode 100644 meta/recipes-sato/matchbox-keyboard/files/png-fix.patch
diff --git a/meta/recipes-sato/matchbox-keyboard/files/configure_fix.patch
b/meta/recipes-sato/matchbox-keyboard/files/configure_fix.patch
deleted file mode 100644
index 800bf3b..000
--- a/meta/recipes-sato/matchbox-keyboard/files/configure_fix.patch
+++ /dev/null
@@ -1,15 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-Index: matchbox-window-manager/configure.ac
-===
matchbox-window-manager.orig/configure.ac 2007-11-14 12:02:28.0
+
-+++ matchbox-window-manager/configure.ac 2007-11-14 12:18:55.0
+
-@@ -283,7 +283,7 @@
- yes)
-
- case $expat in
--yes)
-+yes|)
- EXPAT_LIBS=-lexpat
- ;;
- *)
diff --git a/meta/recipes-sato/matchbox-keyboard/files/png-fix.patch
b/meta/recipes-sato/matchbox-keyboard/files/png-fix.patch
deleted file mode 100644
index e3834f5..000
--- a/meta/recipes-sato/matchbox-keyboard/files/png-fix.patch
+++ /dev/null
@@ -1,49 +0,0 @@
-Change matchbox-keyboard to look for libpng instead of libpng12, and fix
the
-code so that it works with the 1.2 and 1.5 API.
-
-Upstream-Status: Backport
-Signed-off-by: Ross Burton ross.bur...@intel.com
-
-diff --git a/configure.ac b/configure.ac
-index 9678cf7..9bbbd76 100644
a/configure.ac
-+++ b/configure.ac
-@@ -171,24 +171,7 @@ dnl -- Expat
-
- dnl -- Check for PNG ---
-
--AC_MSG_CHECKING(for libpng12)
--
--if $PKG_CONFIG --exists libpng12; then
--AC_MSG_RESULT(yes)
--PNG_LIBS=`$PKG_CONFIG --libs libpng12`
--PNG_CFLAGS=`$PKG_CONFIG --cflags libpng12`
--else
--AC_MSG_RESULT(no)
--AC_CHECK_LIB([png], [png_create_read_struct],
-- [have_png=yes], [have_png=no])
--
--if test x$have_png=xyes test x$have_png_h=xyes; then
--PNG_LIBS=-lpng -lz
--else
--AC_MSG_ERROR([*** Cannot find libpng12 ])
--fi
--fi
--
-+PKG_CHECK_MODULES(PNG, libpng)
-
- dnl -- Debug Build --
-
-diff --git a/src/matchbox-keyboard-image.c b/src/matchbox-keyboard-image.c
-index 8accc3e..6b4b0e8 100644
a/src/matchbox-keyboard-image.c
-+++ b/src/matchbox-keyboard-image.c
-@@ -65,7 +65,7 @@ png_file_load (const char *file,
- return NULL;
- }
-
-- if ( setjmp( png_ptr-jmpbuf ) ) {
-+ if (setjmp (png_jmpbuf (png_ptr))) {
- png_destroy_read_struct( png_ptr, info_ptr, NULL);
- fclose(fd);
- return NULL;
diff --git a/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb
b/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb
index ffcabca..bcf6f6c 100644
--- a/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb
+++ b/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb
@@ -3,22 +3,20 @@ HOMEPAGE = http://matchbox-project.org;
BUGTRACKER = http://bugzilla.openedhand.com/;
SECTION = x11
-LICENSE = GPLv2+
-LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
-
file://src/matchbox-keyboard.h;endline=20;md5=4ba16ff913ad245dd6d95a6c67f72526 \
-
file://applet/applet.c;endline=20;md5=e9201b3efa0a81a160b88d6feb5cf75b
+LICENSE = LGPLv2.1
+LIC_FILES_CHKSUM = file://COPYING;md5=4fbd65380cdd255951079008b364516c \
+
file://src/matchbox-keyboard.h;endline=17;md5=9d6586c69e4a926f3cb0b4425f24ba3c \
+
file://applet/applet.c;endline=18;md5=4a0f721724746b14d95b51ddd42b95e7
DEPENDS = libfakekey expat libxft gtk+ matchbox-panel-2
-SRCREV = b38f24036cff3be6c2fbcf9ca9881803e69003ac
+SRCREV = 217f1bfe14c41cf7e291d04a63aa2d79cc13d063
PV = 0.0+git${SRCPV}
PR = r4
SRC_URI = git://git.yoctoproject.org/${BPN} \
- file://configure_fix.patch;maxrev=1819 \
file://single-instance.patch \
- file://80matchboxkeyboard.shbg \
- file://png-fix.patch
+ file://80matchboxkeyboard.shbg
S = ${WORKDIR}/git
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] matcbox-keyboard: bump SRCREV
Bump to the latest commit on the 0.1 branch.
Drop two redundant patches, and update the license data since upstream has been
re-licensed to LGPL v2.1.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../matchbox-keyboard/files/configure_fix.patch| 15 --
.../matchbox-keyboard/files/png-fix.patch | 49
.../matchbox-keyboard/matchbox-keyboard_git.bb | 14 +++---
3 files changed, 6 insertions(+), 72 deletions(-)
delete mode 100644
meta/recipes-sato/matchbox-keyboard/files/configure_fix.patch
delete mode 100644 meta/recipes-sato/matchbox-keyboard/files/png-fix.patch
diff --git a/meta/recipes-sato/matchbox-keyboard/files/configure_fix.patch
b/meta/recipes-sato/matchbox-keyboard/files/configure_fix.patch
deleted file mode 100644
index 800bf3b..000
--- a/meta/recipes-sato/matchbox-keyboard/files/configure_fix.patch
+++ /dev/null
@@ -1,15 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-Index: matchbox-window-manager/configure.ac
-===
matchbox-window-manager.orig/configure.ac 2007-11-14 12:02:28.0
+
-+++ matchbox-window-manager/configure.ac 2007-11-14 12:18:55.0
+
-@@ -283,7 +283,7 @@
- yes)
-
- case $expat in
--yes)
-+yes|)
- EXPAT_LIBS=-lexpat
- ;;
- *)
diff --git a/meta/recipes-sato/matchbox-keyboard/files/png-fix.patch
b/meta/recipes-sato/matchbox-keyboard/files/png-fix.patch
deleted file mode 100644
index e3834f5..000
--- a/meta/recipes-sato/matchbox-keyboard/files/png-fix.patch
+++ /dev/null
@@ -1,49 +0,0 @@
-Change matchbox-keyboard to look for libpng instead of libpng12, and fix
the
-code so that it works with the 1.2 and 1.5 API.
-
-Upstream-Status: Backport
-Signed-off-by: Ross Burton ross.bur...@intel.com
-
-diff --git a/configure.ac b/configure.ac
-index 9678cf7..9bbbd76 100644
a/configure.ac
-+++ b/configure.ac
-@@ -171,24 +171,7 @@ dnl -- Expat
-
- dnl -- Check for PNG ---
-
--AC_MSG_CHECKING(for libpng12)
--
--if $PKG_CONFIG --exists libpng12; then
--AC_MSG_RESULT(yes)
--PNG_LIBS=`$PKG_CONFIG --libs libpng12`
--PNG_CFLAGS=`$PKG_CONFIG --cflags libpng12`
--else
--AC_MSG_RESULT(no)
--AC_CHECK_LIB([png], [png_create_read_struct],
-- [have_png=yes], [have_png=no])
--
--if test x$have_png=xyes test x$have_png_h=xyes; then
--PNG_LIBS=-lpng -lz
--else
--AC_MSG_ERROR([*** Cannot find libpng12 ])
--fi
--fi
--
-+PKG_CHECK_MODULES(PNG, libpng)
-
- dnl -- Debug Build --
-
-diff --git a/src/matchbox-keyboard-image.c b/src/matchbox-keyboard-image.c
-index 8accc3e..6b4b0e8 100644
a/src/matchbox-keyboard-image.c
-+++ b/src/matchbox-keyboard-image.c
-@@ -65,7 +65,7 @@ png_file_load (const char *file,
- return NULL;
- }
-
-- if ( setjmp( png_ptr-jmpbuf ) ) {
-+ if (setjmp (png_jmpbuf (png_ptr))) {
- png_destroy_read_struct( png_ptr, info_ptr, NULL);
- fclose(fd);
- return NULL;
diff --git a/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb
b/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb
index ffcabca..489d5a3 100644
--- a/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb
+++ b/meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb
@@ -3,22 +3,20 @@ HOMEPAGE = http://matchbox-project.org;
BUGTRACKER = http://bugzilla.openedhand.com/;
SECTION = x11
-LICENSE = GPLv2+
-LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
-
file://src/matchbox-keyboard.h;endline=20;md5=4ba16ff913ad245dd6d95a6c67f72526 \
-
file://applet/applet.c;endline=20;md5=e9201b3efa0a81a160b88d6feb5cf75b
+LICENSE = LGPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=4fbd65380cdd255951079008b364516c \
+
file://src/matchbox-keyboard.h;endline=17;md5=9d6586c69e4a926f3cb0b4425f24ba3c \
+
file://applet/applet.c;endline=18;md5=4a0f721724746b14d95b51ddd42b95e7
DEPENDS = libfakekey expat libxft gtk+ matchbox-panel-2
-SRCREV = b38f24036cff3be6c2fbcf9ca9881803e69003ac
+SRCREV = 217f1bfe14c41cf7e291d04a63aa2d79cc13d063
PV = 0.0+git${SRCPV}
PR = r4
SRC_URI = git://git.yoctoproject.org/${BPN} \
- file://configure_fix.patch;maxrev=1819 \
file://single-instance.patch \
- file://80matchboxkeyboard.shbg \
- file://png-fix.patch
+ file://80matchboxkeyboard.shbg
S = ${WORKDIR}/git
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [master][dora][PATCH 1/2] perf: disallow debug optimization.
On Thu, 2013-11-21 at 01:33 -0600, Mark Hatle wrote: +def get_optimization(d): +selected_optimization = d.getVar(SELECTED_OPTIMIZATION, True) +if base_contains(SELECTED_OPTIMIZATION, -O0, x, , d) == x: +bb.note(eglibc can't be built with -O0, -O2 will be used instead.) Although the text of that warning is correct, users might find the reference to eglibc slightly confusing if it's perf that they're trying to build. Also, as I mentioned in a different thread not all that long ago when someone submitted a similar patch for gcc-runtime, the proliferation of parse-time python functions to bash SELECTED_OPTIMIZATION around doesn't seem like all that good a thing: this will cause extra overhead for everyone, even those who are not using -O0 and have no interest in perf. And, finally, it remains slightly unclear to me that this is really a problem that the metadata needs to be solving. I haven't seen any particularly convincing explanation of why this can't or shouldn't just be fixed in the distro configuration. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] qemu: add bash and python to qemu's RDEPENDS
On 11/22/2013 03:42 AM, Saul Wold wrote:
On 11/21/2013 11:40 AM, Mark Hatle wrote:
On 11/21/13, 12:42 PM, Saul Wold wrote:
Why are you adding bash to qemu?
My understanding is that there was a bash script that was added as well,
once the python rdepends was resolved.
Actually the bash script break the build first, and then the python's.
Any chance of de-bashing the script?
I will try it.
//Hongxu
Sau!
--Mark
Sau!
On 11/21/2013 05:14 AM, Hongxu Jia wrote:
| Note: adding Smart RPM DB channel
|
| Note: to be installed: qemu@x86_64 run-postinsts@x86_64
kernel-modules@qemux86_64 packagegroup-core-boot@qemux86_64
| Loading cache...
| Updating cache...
[100%]
|
| Computing transaction...error: Can't install
qemu-1.5.0-r0.0@x86_64: no package provides /usr/bin/python
|
| Saving cache...
|
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_rootfs (log file is located at
tmp/work/qemux86_64-wrs-linux/wrlinux-image-glibc-small/1.0-r1/temp/do_rootfs/log.do_rootfs.21373)
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 21ce489..3f3431d 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -5,6 +5,7 @@ DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11
pixman dtc libsdl
DEPENDS_class-native = zlib-native alsa-lib-native
glib-2.0-native pixman-native dtc-native
DEPENDS_class-nativesdk = nativesdk-zlib nativesdk-libsdl
nativesdk-glib-2.0 nativesdk-pixman nativesdk-dtc
RDEPENDS_${PN}_class-nativesdk = nativesdk-libsdl
+RDEPENDS_${PN}_class-target += bash python
require qemu-targets.inc
inherit autotools
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] qemu: add bash and python to qemu's RDEPENDS
| Note: adding Smart RPM DB channel
|
| Note: to be installed: qemu@x86_64 run-postinsts@x86_64
kernel-modules@qemux86_64 packagegroup-core-boot@qemux86_64
| Loading cache...
| Updating cache...
[100%]
|
| Computing transaction...error: Can't install qemu-1.5.0-r0.0@x86_64: no
package provides /usr/bin/python
|
| Saving cache...
|
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_rootfs (log file is located at
tmp/work/qemux86_64-wrs-linux/wrlinux-image-glibc-small/1.0-r1/temp/do_rootfs/log.do_rootfs.21373)
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 21ce489..3f3431d 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -5,6 +5,7 @@ DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11 pixman dtc
libsdl
DEPENDS_class-native = zlib-native alsa-lib-native glib-2.0-native
pixman-native dtc-native
DEPENDS_class-nativesdk = nativesdk-zlib nativesdk-libsdl nativesdk-glib-2.0
nativesdk-pixman nativesdk-dtc
RDEPENDS_${PN}_class-nativesdk = nativesdk-libsdl
+RDEPENDS_${PN}_class-target += bash python
require qemu-targets.inc
inherit autotools
--
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 4/4] qemu: add bash and python to qemu's RDEPENDS
On 11/21/2013 11:40 AM, Mark Hatle wrote:
On 11/21/13, 12:42 PM, Saul Wold wrote:
Why are you adding bash to qemu?
My understanding is that there was a bash script that was added as well,
once the python rdepends was resolved.
Any chance of de-bashing the script?
Sau!
--Mark
Sau!
On 11/21/2013 05:14 AM, Hongxu Jia wrote:
| Note: adding Smart RPM DB channel
|
| Note: to be installed: qemu@x86_64 run-postinsts@x86_64
kernel-modules@qemux86_64 packagegroup-core-boot@qemux86_64
| Loading cache...
| Updating cache...
[100%]
|
| Computing transaction...error: Can't install
qemu-1.5.0-r0.0@x86_64: no package provides /usr/bin/python
|
| Saving cache...
|
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_rootfs (log file is located at
tmp/work/qemux86_64-wrs-linux/wrlinux-image-glibc-small/1.0-r1/temp/do_rootfs/log.do_rootfs.21373)
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 21ce489..3f3431d 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -5,6 +5,7 @@ DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11
pixman dtc libsdl
DEPENDS_class-native = zlib-native alsa-lib-native
glib-2.0-native pixman-native dtc-native
DEPENDS_class-nativesdk = nativesdk-zlib nativesdk-libsdl
nativesdk-glib-2.0 nativesdk-pixman nativesdk-dtc
RDEPENDS_${PN}_class-nativesdk = nativesdk-libsdl
+RDEPENDS_${PN}_class-target += bash python
require qemu-targets.inc
inherit autotools
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ia32-base: Remove cpio and ext3 defaults
On real IA hardware, neither the ext3 or cpio images are particularly useful or used. cpio is legacy from initramfs and that specific image now overrides FSTYPES accordingly. The size difference in filesystems makes ext3 as a file format less useful, mainly being useful in the qemu case. When needed users can still override the default FSTYPES so having saner defaults makes sense. This improves build times and uses less network bandwidth for builds and releases. Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- diff --git a/meta/conf/machine/include/ia32-base.inc b/meta/conf/machine/include/ia32-base.inc index 8a20bca..e15f927 100644 --- a/meta/conf/machine/include/ia32-base.inc +++ b/meta/conf/machine/include/ia32-base.inc @@ -10,7 +10,7 @@ MACHINE_FEATURES += screen keyboard pci usbhost ext2 ext3 x86 \ MACHINE_EXTRA_RRECOMMENDS += kernel-modules -IMAGE_FSTYPES += ext3 cpio.gz live +IMAGE_FSTYPES += live KERNEL_IMAGETYPE ?= bzImage ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] json-glib: enable ptest
Use a patch from upstream to install the test suite and add the minimal logic to
integrate it with ptest.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../json-glib/json-glib/install-tests.patch| 186
meta/recipes-gnome/json-glib/json-glib/run-ptest |3 +
meta/recipes-gnome/json-glib/json-glib_0.16.2.bb | 13 +-
3 files changed, 200 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-gnome/json-glib/json-glib/install-tests.patch
create mode 100644 meta/recipes-gnome/json-glib/json-glib/run-ptest
diff --git a/meta/recipes-gnome/json-glib/json-glib/install-tests.patch
b/meta/recipes-gnome/json-glib/json-glib/install-tests.patch
new file mode 100644
index 000..4bd9764
--- /dev/null
+++ b/meta/recipes-gnome/json-glib/json-glib/install-tests.patch
@@ -0,0 +1,186 @@
+Upstream-Status: Backport
+Signed-off-by: Ross Burton ross.bur...@intel.com
+
+From 3e9858cb9c34f492ad0859bd262c8c4691260b41 Mon Sep 17 00:00:00 2001
+From: Emmanuele Bassi eba...@gnome.org
+Date: Thu, 16 May 2013 23:27:56 +0100
+Subject: [PATCH] build: Add --enable-installed-tests
+
+See https://live.gnome.org/GnomeGoals/InstalledTests for more
+information.
+
+It's still possible to run `make check` with locally uninstalled tests.
+---
+ .gitignore |1 +
+ configure.ac| 16 ++-
+ json-glib/tests/Makefile.am | 46 +++
+ json-glib/tests/parser.c| 24 +++---
+ 4 files changed, 75 insertions(+), 12 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index a84dbb3..54b9706 100644
+--- a/configure.ac
b/configure.ac
+@@ -160,6 +160,19 @@ AS_IF([test x$enable_maintainer_flags = xyes test
x$GCC = xyes],
+ MAINTAINER_CFLAGS=${MAINTAINER_CFLAGS#* }
+ AC_SUBST([MAINTAINER_CFLAGS])
+
++dnl === Test suite
++
++AC_ARG_ENABLE(modular_tests,
++ AS_HELP_STRING([--disable-modular-tests],
++ [Disable build of test programs (default: no)]),,
++ [enable_modular_tests=yes])
++AC_ARG_ENABLE(installed_tests,
++ AS_HELP_STRING([--enable-installed-tests],
++ [Install test programs (default: no)]),,
++ [enable_installed_tests=no])
++AM_CONDITIONAL(BUILD_MODULAR_TESTS, test x$enable_modular_tests = xyes ||
test x$enable_installed_tests=xyes)
++AM_CONDITIONAL(BUILDOPT_INSTALL_TESTS, test x$enable_installed_tests = xyes)
++
+ dnl === Test coverage
=
+
+ AC_ARG_ENABLE([gcov],
+@@ -297,7 +310,8 @@ echo • Compiler flags: ${CFLAGS} ${MAINTAINER_CFLAGS}
+ echo
+ echo • API reference: ${enable_gtk_doc}
+ echo
+-echo • Enable test suite: ${enable_glibtest}
++echo • Enable test suite: ${enable_modular_tests}
++echo • Install tests: ${enable_installed_tests}
+ echo • Build introspection data: ${enable_introspection}
+ echo • Enable test coverage: ${use_gcov}
+ echo
+diff --git a/json-glib/tests/Makefile.am b/json-glib/tests/Makefile.am
+index 9815b95..23a93d6 100644
+--- a/json-glib/tests/Makefile.am
b/json-glib/tests/Makefile.am
+@@ -5,22 +5,23 @@ NULL =
+
+ DISTCLEANFILES =
+
+-INCLUDES = \
+- -I$(top_srcdir) \
+- -I$(top_srcdir)/json-glib \
++insttestdir=$(pkglibexecdir)/installed-tests
++
++AM_CPPFLAGS = \
++ $(JSON_DEBUG_CFLAGS) \
++ -DTESTS_DATA_DIR=\$(top_srcdir)/json-glib/tests\ \
++ -I$(top_srcdir) \
++ -I$(top_srcdir)/json-glib \
+ $(NULL)
+
+-AM_CPPFLAGS = $(JSON_DEBUG_CFLAGS)
-DTESTS_DATA_DIR=\$(top_srcdir)/json-glib/tests\
+ AM_CFLAGS = -g $(JSON_CFLAGS) $(MAINTAINER_CFLAGS)
++
+ LDADD = \
+ ../libjson-glib-1.0.la \
+ $(JSON_LIBS) \
+ $(NULL)
+
+-EXTRA_DIST += stream-load.json
+-
+-noinst_PROGRAMS = $(TEST_PROGS)
+-TEST_PROGS += \
++all_test_programs = \
+ array \
+ boxed \
+ builder \
+@@ -37,4 +38,33 @@ TEST_PROGS += \
+ serialize-full \
+ $(NULL)
+
++test_files = \
++ stream-load.json\
++ $(NULL)
++
++if BUILD_MODULAR_TESTS
++TEST_PROGS += $(all_test_programs)
++noinst_PROGRAMS = $(TEST_PROGS)
++endif
++
++if BUILDOPT_INSTALL_TESTS
++insttest_PROGRAMS = $(all_test_programs)
++
++testmetadir = $(datadir)/installed-tests/$(PACKAGE)
++testmeta_DATA = $(all_test_programs:=.test)
++
++testdatadir=$(insttestdir)
++testdata_DATA = $(test_files)
++
++testdata_SCRIPTS = $(test_script_files)
++endif
++
++EXTRA_DIST += $(test_files)
++
++%.test: % Makefile
++ $(AM_V_GEN) (echo '[Test]' $@.tmp; \
++ echo 'Type=session' $@.tmp; \
++ echo 'Exec=env JSON_TEST_DATA=$(pkglibexecdir)/installed-tests
$(pkglibexecdir)/installed-tests/$' $@.tmp; \
++ mv $@.tmp $@)
++
+ -include $(top_srcdir)/build/autotools/Makefile.am.gitignore
+diff --git
[OE-core] [PATCH] gcc: Upgrade to 4.8.2
The details for bug fixes between 4.8.1 and 4.8.2 is here
http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVEDresolution=FIXEDtarget_milestone=4.8.2
Remove the patches that were applied upstream
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-devtools/gcc/gcc-4.8.inc | 19 ++---
.../gcc/gcc-4.8/0036-PR-target-56102.patch | 83 --
2 files changed, 5 insertions(+), 97 deletions(-)
delete mode 100644 meta/recipes-devtools/gcc/gcc-4.8/0036-PR-target-56102.patch
diff --git a/meta/recipes-devtools/gcc/gcc-4.8.inc
b/meta/recipes-devtools/gcc/gcc-4.8.inc
index 8d50bf7..8d1729b 100644
--- a/meta/recipes-devtools/gcc/gcc-4.8.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.8.inc
@@ -1,20 +1,12 @@
require gcc-common.inc
# Third digit in PV should be incremented after a minor release
-# happens from this branch on gcc e.g. currently its 4.7.1
-# when 4.7.2 is releases and we bump SRCREV beyond the release
-# on branch then PV should be incremented to 4.7.2+svnr${SRCPV}
-# to reflect that change
-PV = 4.8.1
+PV = 4.8.2
-# BINV should be incremented after updating to a revision
-# after a minor gcc release (e.g. 4.7.1 or 4.7.2) has been made
-# the value will be minor-release+1 e.g. if current minor release was
-# 4.7.1 then the value below will have 2 which will mean 4.7.2
-# which will be next minor release and so on.
+# BINV should be incremented to a revision after a minor gcc release
-BINV = 4.8.1
+BINV = 4.8.2
FILESPATH = ${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.8' ], d)}
@@ -65,7 +57,6 @@ SRC_URI = ${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2 \
file://0033-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch \
file://0034-Use-the-multilib-config-files-from-B-instead-of-usin.patch \
file://0035-wcast-qual-PR-55383.patch \
- file://0036-PR-target-56102.patch \
file://0037-gcc-4.8-PR56797.patch \
file://0038-gcc-4.8-build-args.patch \
file://0039-gcc-4.8-PR57717.patch \
@@ -78,8 +69,8 @@ SRC_URI = ${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2 \
file://0046-libatomic-deptracking.patch \
file://0047-repomembug.patch \
-SRC_URI[md5sum] = 3b2386c114cd74185aa3754b58a79304
-SRC_URI[sha256sum] =
545b44be3ad9f2c4e90e6880f5c9d4f0a8f0e5f67e1ffb0d45da9fa01bb05813
+SRC_URI[md5sum] = a3d7d63b9cb6b6ea049469a0c4a43c9d
+SRC_URI[sha256sum] =
09dc2276c73424bbbfda1dbddc62bbbf900c9f185acf7f3e1d773ce2d7e3cdc8
S = ${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}
B = ${WORKDIR}/gcc-${PV}/build.${HOST_SYS}.${TARGET_SYS}
diff --git a/meta/recipes-devtools/gcc/gcc-4.8/0036-PR-target-56102.patch
b/meta/recipes-devtools/gcc/gcc-4.8/0036-PR-target-56102.patch
deleted file mode 100644
index a9498fc..000
--- a/meta/recipes-devtools/gcc/gcc-4.8/0036-PR-target-56102.patch
+++ /dev/null
@@ -1,83 +0,0 @@
-From fa049b3584a1cc36c250205e3d5841e6a40ff677 Mon Sep 17 00:00:00 2001
-From: amker amker@138bc75d-0d04-0410-961f-82ee72b054a4
-Date: Wed, 27 Mar 2013 08:16:54 +
-Subject: [PATCH] PR target/56102
-
-* config/arm/arm.c (thumb1_rtx_costs, thumb1_size_rtx_costs): Fix rtx costs
for SET/ASHIFT/ASHIFTRT/LSHIFTRT/ROTATERT patterns with mult-word mode.
-
-git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@197155
138bc75d-0d04-0410-961f-82ee72b054a4
-
-Upstream-Status: Backport
-http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57329
-
-Signed-off-by: Martin Jansa martin.ja...@gmail.com
- gcc/config/arm/arm.c | 17 ++---
- 1 file changed, 14 insertions(+), 3 deletions(-)
-
-diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
-index 460d333..edf850d 100644
a/gcc/config/arm/arm.c
-+++ b/gcc/config/arm/arm.c
-@@ -7094,7 +7094,7 @@ static inline int
- thumb1_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer)
- {
- enum machine_mode mode = GET_MODE (x);
-- int total;
-+ int total, words;
-
- switch (code)
- {
-@@ -7102,6 +7102,8 @@ thumb1_rtx_costs (rtx x, enum rtx_code code, enum
rtx_code outer)
- case ASHIFTRT:
- case LSHIFTRT:
- case ROTATERT:
-+ return (mode == SImode) ? COSTS_N_INSNS (1) : COSTS_N_INSNS (2);
-+
- case PLUS:
- case MINUS:
- case COMPARE:
-@@ -7125,7 +7127,10 @@ thumb1_rtx_costs (rtx x, enum rtx_code code, enum
rtx_code outer)
- return COSTS_N_INSNS (1) + 16;
-
- case SET:
-- return (COSTS_N_INSNS (1)
-+ /* A SET doesn't have a mode, so let's look at the SET_DEST to get
-+ the mode. */
-+ words = ARM_NUM_INTS (GET_MODE_SIZE (GET_MODE (SET_DEST (x;
-+ return (COSTS_N_INSNS (words)
- + 4 * ((MEM_P (SET_SRC (x)))
-+ MEM_P (SET_DEST (x;
-
-@@ -7822,6 +7827,7 @@ static inline int
- thumb1_size_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer)
- {
- enum machine_mode mode = GET_MODE (x);
-+ int words;
-
- switch (code)
- {
-@@ -7829,6 +7835,8 @@ thumb1_size_rtx_costs (rtx x, enum
Re: [OE-core] [RFC PATCH] bind: add support for read-only rootfs
On Thu, 2013-11-21 at 08:42 -0600, Mark Hatle wrote: On 11/21/13, 6:12 AM, Phil Blundell wrote: On Thu, 2013-11-21 at 00:59 -0600, Mark Hatle wrote: +# When using a read-only rootfs additional setup may be required +# uncomment the following line to make bind start in read-only rootfs +#ALLOW_ROOTFS_READ_ONLY=yes If the filesystem is read-only then it's going to be fairly difficult for the user to uncomment this line on the target. A post image process script would be capable of un-commenting that line (or simply replacing the file with a specific image specific configuration.) That's true, but I still don't understand why this ought to be necessary. Why should it not just default to being enabled? ++ [ `is_on_read_only_partition /etc/bind` = yes ] bind_mount /var/volatile/bind/etc /etc/bind ++ [ `is_on_read_only_partition /var/named` = yes ] bind_mount /var/volatile/bind/named /var/named Is it really necessary to mount a tmpfs at /etc/bind? Can't those files just be relocated somewhere else? My understanding is both locations need to be RW for bind to work properly. In a normal READONLY filesystem configuration, neither is RW by default. What files does it need to write to /etc/bind? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] grub-efi: change to generate EFI image in target package
On Wed, 2013-11-20 at 09:40 +0800, jackie.hu...@windriver.com wrote:
From: Jackie Huang jackie.hu...@windriver.com
It's not a good idea to generate the target EFI image in
a native packge,
This was admittedly a hack when I wrote it...
it would be a problem when build a 64bit
target on 32bit host.
I build 32b on a 64b host regularly, why is it a problem the other way
around?
There is infrastructure in place to specify the target architecture for
the grub efi binary and the modules. The 32b compiler should be able to
do -m64 just as the 64b compiler can do -m32.
In fact, all we need from grub-efi-native
is the grub-mkimage binary, so change the solution to:
* grub-efi-native only install grub-mkimage
Seems reasonable.
* grub-efi compiles target modules, generates EFI image
with grub-mkimage and deploy, but install nothing.
Also makes sense.
Have you tested the 4 possible combinations?
hosttarget
32 32
64 32
32 64
64 64
Signed-off-by: Jackie Huang jackie.hu...@windriver.com
With verification of testing scope and the the minor comments below, I'm
OK with this approach. It's better than the native hack, but I'm not
sure it addresses an actual failure - but that's OK.
---
meta/classes/grub-efi.bbclass | 4 +-
.../{grub-efi-native_2.00.bb = grub-efi_2.00.bb} | 43
--
2 files changed, 26 insertions(+), 21 deletions(-)
rename meta/recipes-bsp/grub/{grub-efi-native_2.00.bb = grub-efi_2.00.bb}
(77%)
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index 2f00901..71bd00f 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -15,8 +15,8 @@
# ${GRUB_OPTS} - additional options to add to the config, ';' delimited #
(optional)
# ${GRUB_TIMEOUT} - timeout before executing the deault label (optional)
-do_bootimg[depends] += grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
-do_bootdirectdisk[depends] +=
grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
+do_bootimg[depends] += grub-efi:do_deploy
+do_bootdirectdisk[depends] += grub-efi:do_deploy
GRUB_SERIAL ?= console=ttyS0,115200
GRUBCFG = ${S}/grub.cfg
diff --git a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
b/meta/recipes-bsp/grub/grub-efi_2.00.bb
similarity index 77%
rename from meta/recipes-bsp/grub/grub-efi-native_2.00.bb
rename to meta/recipes-bsp/grub/grub-efi_2.00.bb
index 04973b5..2fe688c 100644
--- a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi_2.00.bb
@@ -14,14 +14,10 @@ LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
# FIXME: We should be able to optionally drop freetype as a dependency
-DEPENDS = autogen-native
-RDEPENDS_${PN} = diffutils freetype
+DEPENDS = autogen-native flex-native bison-native
+DEPENDS_class-target = grub-efi-native
So no target DEPENDS are created, correct?
PR = r2
-# Native packages do not normally rebuild when the target changes.
-# Ensure this is built once per HOST-TARGET pair.
-PN := grub-efi-${TRANSLATED_TARGET_ARCH}-native
-
SRC_URI = ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
file://cfg \
file://grub-2.00-fpmath-sse-387-fix.patch \
@@ -39,12 +35,10 @@ COMPATIBLE_HOST = '(x86_64.*|i.86.*)-(linux|freebsd.*)'
S = ${WORKDIR}/grub-${PV}
-# Determine the target arch for the grub modules before the native class
-# clobbers TARGET_ARCH.
-ORIG_TARGET_ARCH := ${TARGET_ARCH}
+# Determine the target arch for the grub modules
python __anonymous () {
import re
-target = d.getVar('ORIG_TARGET_ARCH', True)
+target = d.getVar('TARGET_ARCH', True)
if target == x86_64:
grubtarget = 'x86_64'
grubimage = bootx64.efi
@@ -59,26 +53,37 @@ python __anonymous () {
inherit autotools
inherit gettext
-inherit native
inherit deploy
EXTRA_OECONF = --with-platform=efi --disable-grub-mkfont \
---target=${GRUB_TARGET} --enable-efiemu=no
--program-prefix='' \
+--enable-efiemu=no --program-prefix='' \
--enable-liblzma=no --enable-device-mapper=no
--enable-libzfs=no
-do_mkimage() {
+do_install_class-target() {
+ :
+}
+
+do_install_class-native() {
+ install -d ${D}${bindir}
+ install -m 755 grub-mkimage ${D}${bindir}
+}
+
+do_deploy() {
# Search for the grub.cfg on the local boot media by using the
# built in cfg file provided via this recipe
- ./grub-mkimage -c ../cfg -p /EFI/BOOT -d ./grub-core/ \
+ grub-mkimage -c ../cfg -p /EFI/BOOT -d ./grub-core/ \
-O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
boot linux ext2 fat serial part_msdos part_gpt normal
efi_gop iso9660 search
+ install -m 644 ${B}/${GRUB_IMAGE} ${DEPLOYDIR}
}
-addtask mkimage after do_compile before do_install
-do_deploy() {
-
Re: [OE-core] [PATCH 2/2] grub-efi: allow compilation without large model support
On Wed, 2013-11-20 at 09:40 +0800, jackie.hu...@windriver.com wrote:
From: Jackie Huang jackie.hu...@windriver.com
-mcmodel=large is not supported by gcc with version lower
than 4.4, but we don't need to use memory over 4GiB, so add
a patch to allow compilation without large model support.
Signed-off-by: Jackie Huang jackie.hu...@windriver.com
---
...allow-a-compilation-without-mcmodel-large.patch | 69
++
meta/recipes-bsp/grub/grub-efi_2.00.bb | 1 +
2 files changed, 70 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
diff --git
a/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
b/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
new file mode 100644
index 000..b2be74a
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
@@ -0,0 +1,69 @@
+From 0cea0e4266214da1f11e812834f5d5c47a6e04e6 Mon Sep 17 00:00:00 2001
+From: Jackie Huang jackie.hu...@windriver.com
+Date: Tue, 5 Nov 2013 07:23:32 -0500
+Subject: [PATCH] Allow a compilation without -mcmodel=large
+
+* kern/efi/mm.c (grub_efi_allocate_pages): don't allocate 4GiB
+ when compiled without -mcmodel=large
+ (filter_memory_map): remove memory post 4 GiB when compiled
+ without -mcmodel=large
+* configure.ac: add -DMCMODEL_SMALL=1 to TARGET_CFLAGS when
+ -mcmodel=large isn't supported
+
+Upstream-Status: Inappropriate [configuration]
Nice try ;-) This is compatibility, not configuration. If grub-efi
maintainers refuse to accept the patch that's up to them, but we need to
work upstream first. Please prepare a patch for upstream and submit it
for review.
--
Darren
+
+Signed-off-by: Jackie Huang jackie.hu...@windriver.com
+---
+ configure.ac|4 +++-
+ grub-core/kern/efi/mm.c |6 +++---
+ 2 files changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 319d063..ee72fee 100644
+--- a/configure.ac
b/configure.ac
+@@ -567,7 +567,9 @@ if test $target_cpu-$platform = x86_64-efi; then
+ [grub_cv_cc_mcmodel=no])
+ ])
+ if test x$grub_cv_cc_mcmodel = xno; then
+-AC_MSG_ERROR([-mcmodel=large not supported. Upgrade your gcc.])
++CFLAGS=$SAVED_CFLAGS -m64 -DMCMODEL_SMALL=1
++TARGET_CFLAGS=$TARGET_CFLAGS -DMCMODEL_SMALL=1
++AC_MSG_WARN([-mcmodel=large not supported. You won't be able to use the
memory over 4GiB. Upgrade your gcc.])
+ else
+ TARGET_CFLAGS=$TARGET_CFLAGS -mcmodel=large
+ fi
+diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
+index a2edc84..c67dd13 100644
+--- a/grub-core/kern/efi/mm.c
b/grub-core/kern/efi/mm.c
+@@ -62,7 +62,7 @@ grub_efi_allocate_pages (grub_efi_physical_address_t
address,
+ return 0;
+ #endif
+
+-#if 1
++#if defined (MCMODEL_SMALL)
+ if (address == 0)
+ {
+ type = GRUB_EFI_ALLOCATE_MAX_ADDRESS;
+@@ -305,7 +305,7 @@ filter_memory_map (grub_efi_memory_descriptor_t
*memory_map,
+desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
+ {
+ if (desc-type == GRUB_EFI_CONVENTIONAL_MEMORY
+-#if 1
++#if defined (MCMODEL_SMALL)
+desc-physical_start = 0x
+ #endif
+desc-physical_start + PAGES_TO_BYTES (desc-num_pages) 0x10
+@@ -321,7 +321,7 @@ filter_memory_map (grub_efi_memory_descriptor_t
*memory_map,
+ desc-physical_start = 0x10;
+ }
+
+-#if 1
++#if defined (MCMODEL_SMALL)
+ if (BYTES_TO_PAGES (filtered_desc-physical_start)
+ + filtered_desc-num_pages
+BYTES_TO_PAGES (0x1LL))
+--
+1.7.1
+
diff --git a/meta/recipes-bsp/grub/grub-efi_2.00.bb
b/meta/recipes-bsp/grub/grub-efi_2.00.bb
index 2fe688c..deb9514 100644
--- a/meta/recipes-bsp/grub/grub-efi_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi_2.00.bb
@@ -27,6 +27,7 @@ SRC_URI = ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
file://grub-no-unused-result.patch \
file://grub-2.00-ignore-gnulib-gets-stupidity.patch \
file://fix-issue-with-flex-2.5.37.patch \
+ file://grub-efi-allow-a-compilation-without-mcmodel-large.patch \
SRC_URI[md5sum] = e927540b6eda8b024fb0391eeaa4091c
SRC_URI[sha256sum] =
65b39a0558f8c802209c574f4d02ca263a804e8a564bc6caf1cd0fd3b3cc11e3
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] bind: add support for read-only rootfs
On 11/21/13, 6:12 AM, Phil Blundell wrote: On Thu, 2013-11-21 at 00:59 -0600, Mark Hatle wrote: +# When using a read-only rootfs additional setup may be required +# uncomment the following line to make bind start in read-only rootfs +#ALLOW_ROOTFS_READ_ONLY=yes If the filesystem is read-only then it's going to be fairly difficult for the user to uncomment this line on the target. A post image process script would be capable of un-commenting that line (or simply replacing the file with a specific image specific configuration.) Why would you ever want this variable to be set to anything other than yes? If your filesystem is not in fact read-only then it isn't going to have any effect, and if your filesystem is read-only then bind won't work without it. ++ [ `is_on_read_only_partition /etc/bind` = yes ] bind_mount /var/volatile/bind/etc /etc/bind ++ [ `is_on_read_only_partition /var/named` = yes ] bind_mount /var/volatile/bind/named /var/named Is it really necessary to mount a tmpfs at /etc/bind? Can't those files just be relocated somewhere else? My understanding is both locations need to be RW for bind to work properly. In a normal READONLY filesystem configuration, neither is RW by default. --Mark p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] bind: add support for read-only rootfs
On 11/21/13, 6:40 AM, Phil Blundell wrote: On Thu, 2013-11-21 at 20:24 +0800, ChenQi wrote: The purpose is to disable bind in a read-only file system by default. But if user really wants it, they can set this value to 'yes'. I'm still struggling a bit to understand the reasoning here. Why would you install bind in the first place if you didn't want it to be enabled? Why do people use core-image-sato, and then try to remove python? Sorry for the snarkiness, but that's what is being avoided here. I have to send these patches, due to the YP compliance guidelines, which is why this is an RFC and not something I'm suggesting for the actual oe-core.. (since the patch it depends on was not accepted.) --Mark p. ___ 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 1/4] kconfig-frontends: add python to kconfig-frontends's RDEPENDS
| Note: adding Smart RPM DB channel
|
| Note: to be installed: kconfig-frontends@x86_64 run-postinsts@x86_64
kernel-modules@qemux86_64 packagegroup-core-boot@qemux86_64
| Loading cache...
| Updating cache...
[100%]
|
| Computing transaction...error: Can't install
kconfig-frontends-3.10.0.0-r0.0@x86_64: no package provides /usr/bin/python
|
| Saving cache...
|
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_rootfs (log file is located at
tmp/work/qemux86_64-wrs-linux/wrlinux-image-glibc-small/1.0-r1/temp/do_rootfs/log.do_rootfs.30959)
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-devtools/kconfig-frontends/kconfig-frontends_3.12.0.0.bb | 1 +
1 file changed, 1 insertion(+)
diff --git
a/meta/recipes-devtools/kconfig-frontends/kconfig-frontends_3.12.0.0.bb
b/meta/recipes-devtools/kconfig-frontends/kconfig-frontends_3.12.0.0.bb
index 1cebd64..f225af0 100644
--- a/meta/recipes-devtools/kconfig-frontends/kconfig-frontends_3.12.0.0.bb
+++ b/meta/recipes-devtools/kconfig-frontends/kconfig-frontends_3.12.0.0.bb
@@ -11,6 +11,7 @@ LICENSE = GPL-2.0
LIC_FILES_CHKSUM = file://COPYING;md5=9b8cf60ff39767ff04b671fca8302408
SECTION = devel
DEPENDS += ncurses flex bison gperf pkgconfig-native
+RDEPENDS_${PN} += python
SRC_URI = http://ymorin.is-a-geek.org/download/${BPN}/${BP}.tar.xz;
SRC_URI[md5sum] = b939280dcc83f8feabd87a1d5f9b00c2
--
1.8.1.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] bind: add support for read-only rootfs
On Thu, 2013-11-21 at 08:44 -0600, Mark Hatle wrote: I have to send these patches, due to the YP compliance guidelines, which is why this is an RFC and not something I'm suggesting for the actual oe-core.. (since the patch it depends on was not accepted.) Ah, right, sorry, I hadn't quite understood that you didn't plan on actually getting this patch merged. If this was just an informational this is what Wind River is doing internally then obviously that's fine. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] lttng-tools: add PACKAGECONFIG to support --enable-python-bindings and lttng-ust
Add PACKAGECONFIG to support --enable-python-bindings
Add PACKAGECONFIG to support lttng-ust
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-kernel/lttng/lttng-tools_2.3.1.bb | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.3.1.bb
b/meta/recipes-kernel/lttng/lttng-tools_2.3.1.bb
index 2f6e504..64b6e02 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.3.1.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.3.1.bb
@@ -9,9 +9,18 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=01d7fc4496aacf37d90df90b90b0cac1 \
file://gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
file://lgpl-2.1.txt;md5=0f0d71500e6a57fd24d825f33242b9ca
-DEPENDS = liburcu popt lttng-ust
+DEPENDS = liburcu popt
RDEPENDS_${PN}-ptest += make
+PYTHON_OPTION =
am_cv_python_pyexecdir='${libdir}/python${PYTHON_BASEVERSION}/site-packages' \
+
am_cv_python_pythondir='${libdir}/python${PYTHON_BASEVERSION}/site-packages' \
+
PYTHON_INCLUDE='-I${STAGING_INCDIR}/python${PYTHON_BASEVERSION}' \
+
+PACKAGECONFIG = python lttng-ust
+PACKAGECONFIG[python] = --enable-python-bindings ${PYTHON_OPTION}, \
+ --disable-python-bindings, python swig-native
+PACKAGECONFIG[lttng-ust] = --enable-lttng-ust, --disable-lttng-ust, lttng-ust
+
SRCREV = 5d985544a7ad54afa0514ea7f522a89d8d844860
PV = v2.3.1
@@ -26,12 +35,15 @@ inherit autotools ptest
export KERNELDIR=${STAGING_KERNEL_DIR}
-FILES_${PN} += ${libdir}/lttng/libexec/*
-FILES_${PN}-dbg += ${libdir}/lttng/libexec/.debug
+FILES_${PN} += ${libdir}/lttng/libexec/*
${libdir}/python${PYTHON_BASEVERSION}/site-packages/*
+FILES_${PN}-dbg += ${libdir}/lttng/libexec/.debug
${libdir}/python2.7/site-packages/.debug
+FILES_${PN}-staticdev +=
${libdir}/python${PYTHON_BASEVERSION}/site-packages/*.a
+FILES_${PN}-dev += ${libdir}/python${PYTHON_BASEVERSION}/site-packages/*.la
# Since files are installed into ${libdir}/lttng/libexec we match
# the libexec insane test so skip it.
-INSANE_SKIP_${PN} = libexec
+# Python module needs to keep _lttng.so
+INSANE_SKIP_${PN} = libexec dev-so
INSANE_SKIP_${PN}-dbg = libexec
--
1.8.1.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [dora][master][PATCH] util-linux: Package readprofile into it's own package
readprofile was missing from the alternative configuration, which was
causing readprofile to be packaged into the base util-linux.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/recipes-core/util-linux/util-linux.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 5d1dcd1..8a1e78a 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -204,6 +204,9 @@ ALTERNATIVE_LINK_NAME[mount] = ${base_bindir}/mount
ALTERNATIVE_util-linux-umount = umount
ALTERNATIVE_LINK_NAME[umount] = ${base_bindir}/umount
+ALTERNATIVE_util-linux-readprofile = readprofile
+ALTERNATIVE_LINK_NAME[readprofile] = ${base_sbindir}/readprofile
+
ALTERNATIVE_util-linux-losetup = losetup
ALTERNATIVE_LINK_NAME[losetup] = ${base_sbindir}/losetup
--
1.8.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [master][dora][PATCH 1/2] perf: disallow debug optimization.
On 11/21/13, 8:25 AM, Phil Blundell wrote: On Thu, 2013-11-21 at 01:33 -0600, Mark Hatle wrote: +def get_optimization(d): +selected_optimization = d.getVar(SELECTED_OPTIMIZATION, True) +if base_contains(SELECTED_OPTIMIZATION, -O0, x, , d) == x: +bb.note(eglibc can't be built with -O0, -O2 will be used instead.) Although the text of that warning is correct, users might find the reference to eglibc slightly confusing if it's perf that they're trying to build. I'll get that fixed. Also, as I mentioned in a different thread not all that long ago when someone submitted a similar patch for gcc-runtime, the proliferation of parse-time python functions to bash SELECTED_OPTIMIZATION around doesn't seem like all that good a thing: this will cause extra overhead for everyone, even those who are not using -O0 and have no interest in perf. We have users who desire to build their system at different levels of optimizations for debug, size, profiling, etc. So they do change the default optimization levels from -O2 to -O0, etc. The python fragement is used to only adjust -O0, as -O1 (or -Os) work correctly. --Mark And, finally, it remains slightly unclear to me that this is really a problem that the metadata needs to be solving. I haven't seen any particularly convincing explanation of why this can't or shouldn't just be fixed in the distro configuration. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] shadow: remove reference to locale env files from su
On 11/22/2013 02:49 AM, Saul Wold wrote: On 11/21/2013 01:14 AM, qiang.c...@windriver.com wrote: From: Qiang Chen qiang.c...@windriver.com The /etc/default/locale missing message appears when running su user root@qemu0:/var/log# su root root@qemu0:/var/log# tail auth.log Oct 8 07:47:54 qemu0 login[983]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) Oct 8 07:47:55 qemu0 login[995]: ROOT LOGIN on '/dev/console' Oct 8 07:48:21 qemu0 su[999]: Successful su for root by root Oct 8 07:48:21 qemu0 su[999]: + /dev/console root:root Oct 8 07:48:21 qemu0 su[999]: pam_env(su:session): Unable to open env file: /etc/default/locale: No such file or directory Oct 8 07:48:21 qemu0 su[999]: pam_unix(su:session): session opened for user root by root(uid=0) This commit remove reference from pam.d/su to /etc/default/locale env file to avoid the error messages. Signed-off-by: Qiang Chen qiang.c...@windriver.com --- meta/recipes-extended/shadow/files/pam.d/su |3 --- meta/recipes-extended/shadow/shadow.inc |2 +- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/meta/recipes-extended/shadow/files/pam.d/su b/meta/recipes-extended/shadow/files/pam.d/su index 8e35137..8d590a3 100644 --- a/meta/recipes-extended/shadow/files/pam.d/su +++ b/meta/recipes-extended/shadow/files/pam.d/su @@ -34,9 +34,6 @@ auth sufficient pam_rootok.so # # parsing /etc/environment needs readenv=1 session required pam_env.so readenv=1 -# locale variables are also kept into /etc/default/locale in etch -# reading this file *in addition to /etc/environment* does not hurt -session required pam_env.so readenv=1 envfile=/etc/default/locale Should we be providing an empty locale file instead, what happens if someone wants to use the locale mechanism? Hi Sau, Thanks for your comments ! I didn't see much sense providing an empty/faked locale file there, as we didn't provide a update-locale command tool either. Meanwhile, RHEL, fedora didn't require an env file to /etc/default/locale too. If someone really cares the env for locale related, they just need specify their envfile instead our faked env file. # Defines the MAIL environment variable # However, userdel also needs MAIL_DIR and MAIL_FILE variables diff --git a/meta/recipes-extended/shadow/shadow.inc b/meta/recipes-extended/shadow/shadow.inc index 5ab978a..572c3bc 100644 --- a/meta/recipes-extended/shadow/shadow.inc +++ b/meta/recipes-extended/shadow/shadow.inc @@ -44,7 +44,7 @@ SRC_URI_append_class-nativesdk = \ SRC_URI[md5sum] = b8608d8294ac88974f27b20f991c0e79 SRC_URI[sha256sum] = 633f5bb4ea0c88c55f3642c97f9d25cbef74f82e0b4cf8d54e7ad6f9f9caa778 -PR = r13 +PR = r14 No more PR bumps please. OK. I will send V2 patch dropping PR bumps and remove login reference to /etc/default/locale too. Thanks ! Qiang Sau! # Additional Policy files for PAM PAM_SRC_URI = file://pam.d/chfn \ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] grub-efi: allow compilation without large model support
On 11/22/2013 10:49 AM, Darren Hart wrote:
On Wed, 2013-11-20 at 09:40 +0800, jackie.hu...@windriver.com wrote:
From: Jackie Huang jackie.hu...@windriver.com
-mcmodel=large is not supported by gcc with version lower
than 4.4, but we don't need to use memory over 4GiB, so add
a patch to allow compilation without large model support.
Signed-off-by: Jackie Huang jackie.hu...@windriver.com
---
...allow-a-compilation-without-mcmodel-large.patch | 69 ++
meta/recipes-bsp/grub/grub-efi_2.00.bb | 1 +
2 files changed, 70 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
diff --git
a/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
b/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
new file mode 100644
index 000..b2be74a
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
@@ -0,0 +1,69 @@
+From 0cea0e4266214da1f11e812834f5d5c47a6e04e6 Mon Sep 17 00:00:00 2001
+From: Jackie Huang jackie.hu...@windriver.com
+Date: Tue, 5 Nov 2013 07:23:32 -0500
+Subject: [PATCH] Allow a compilation without -mcmodel=large
+
+* kern/efi/mm.c (grub_efi_allocate_pages): don't allocate 4GiB
+ when compiled without -mcmodel=large
+ (filter_memory_map): remove memory post 4 GiB when compiled
+ without -mcmodel=large
+* configure.ac: add -DMCMODEL_SMALL=1 to TARGET_CFLAGS when
+ -mcmodel=large isn't supported
+
+Upstream-Status: Inappropriate [configuration]
Nice try ;-) This is compatibility, not configuration. If grub-efi
maintainers refuse to accept the patch that's up to them, but we need to
Actually it's ported from old version of grub which means that they
allowed the comilation without large model support before, but not now.
From the Changelog, it was added in 2009:
2009-06-04 Vladimir Serbinenko phco...@gmail.com
Allow a compilation without -mcmodel=large
* kern/efi/mm.c (grub_efi_allocate_pages): don't allocate 4GiB
when compiled without -mcmodel=large
(filter_memory_map): remove memory post 4 GiB when compiled
without -mcmodel=large
* configure.ac: fail gracefully and add -DMCMODEL_SMALL=1 to
TARGET_CFLAGS when -mcmodel=large isn't supported
but it was removed in 2010:
2010-04-21 Vladimir Serbinenko phco...@gmail.com
* configure.ac: Refuse to compile for x86_64-efi is mcmodel=large
is not supported.
So I think they may not accept this patch again.
Thanks,
Jackie
work upstream first. Please prepare a patch for upstream and submit it
for review.
--
Darren
+
+Signed-off-by: Jackie Huang jackie.hu...@windriver.com
+---
+ configure.ac|4 +++-
+ grub-core/kern/efi/mm.c |6 +++---
+ 2 files changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 319d063..ee72fee 100644
+--- a/configure.ac
b/configure.ac
+@@ -567,7 +567,9 @@ if test $target_cpu-$platform = x86_64-efi; then
+ [grub_cv_cc_mcmodel=no])
+ ])
+ if test x$grub_cv_cc_mcmodel = xno; then
+-AC_MSG_ERROR([-mcmodel=large not supported. Upgrade your gcc.])
++CFLAGS=$SAVED_CFLAGS -m64 -DMCMODEL_SMALL=1
++TARGET_CFLAGS=$TARGET_CFLAGS -DMCMODEL_SMALL=1
++AC_MSG_WARN([-mcmodel=large not supported. You won't be able to use the
memory over 4GiB. Upgrade your gcc.])
+ else
+ TARGET_CFLAGS=$TARGET_CFLAGS -mcmodel=large
+ fi
+diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
+index a2edc84..c67dd13 100644
+--- a/grub-core/kern/efi/mm.c
b/grub-core/kern/efi/mm.c
+@@ -62,7 +62,7 @@ grub_efi_allocate_pages (grub_efi_physical_address_t address,
+ return 0;
+ #endif
+
+-#if 1
++#if defined (MCMODEL_SMALL)
+ if (address == 0)
+ {
+ type = GRUB_EFI_ALLOCATE_MAX_ADDRESS;
+@@ -305,7 +305,7 @@ filter_memory_map (grub_efi_memory_descriptor_t
*memory_map,
+desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
+ {
+ if (desc-type == GRUB_EFI_CONVENTIONAL_MEMORY
+-#if 1
++#if defined (MCMODEL_SMALL)
+ desc-physical_start = 0x
+ #endif
+ desc-physical_start + PAGES_TO_BYTES (desc-num_pages) 0x10
+@@ -321,7 +321,7 @@ filter_memory_map (grub_efi_memory_descriptor_t
*memory_map,
+ desc-physical_start = 0x10;
+ }
+
+-#if 1
++#if defined (MCMODEL_SMALL)
+ if (BYTES_TO_PAGES (filtered_desc-physical_start)
+ + filtered_desc-num_pages
+ BYTES_TO_PAGES (0x1LL))
+--
+1.7.1
+
diff --git a/meta/recipes-bsp/grub/grub-efi_2.00.bb
b/meta/recipes-bsp/grub/grub-efi_2.00.bb
index 2fe688c..deb9514 100644
--- a/meta/recipes-bsp/grub/grub-efi_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi_2.00.bb
@@ -27,6 +27,7 @@ SRC_URI = ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
file://grub-no-unused-result.patch \
Re: [OE-core] [PATCH 1/2] grub-efi: change to generate EFI image in target package
On 11/22/2013 10:45 AM, Darren Hart wrote:
On Wed, 2013-11-20 at 09:40 +0800, jackie.hu...@windriver.com wrote:
From: Jackie Huang jackie.hu...@windriver.com
It's not a good idea to generate the target EFI image in
a native packge,
This was admittedly a hack when I wrote it...
it would be a problem when build a 64bit
target on 32bit host.
I build 32b on a 64b host regularly, why is it a problem the other way
around?
There is infrastructure in place to specify the target architecture for
the grub efi binary and the modules. The 32b compiler should be able to
do -m64 just as the 64b compiler can do -m32.
It should be, but for most 32bit linux distributions, gcc is not
compiled for supporting 64bit cross compiling.
e.g. on rhel 6.2 32bit:
$ gcc -m64 test.c
test.c:1: sorry, unimplemented: 64-bit mode not compiled in
$ gcc -m64 -v
Using built-in specs.
Target: i686-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic
--with-arch=i686 --build=i686-redhat-linux
Thread model: posix
gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)
on openSUSE 12.2 32bit:
$ gcc -m64 test.c
test.c:1:0: sorry, unimplemented: 64-bit mode not compiled in
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-suse-linux/4.7/lto-wrapper
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7
--enable-ssp --disable-libssp --disable-libitm --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib
--with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--program-suffix=-4.7 --enable-linux-futex --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=i586-suse-linux
Thread model: posix
gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux)
We may have to ask users to re-compile for the supporting if they are
using 32bit hosts. But another problem is, even if we build 64b on 32b
host, I don't think we can run the 64b binary grub-mkimage on the 32b
host.
In fact, all we need from grub-efi-native
is the grub-mkimage binary, so change the solution to:
* grub-efi-native only install grub-mkimage
Seems reasonable.
* grub-efi compiles target modules, generates EFI image
with grub-mkimage and deploy, but install nothing.
Also makes sense.
Have you tested the 4 possible combinations?
hosttarget
32 32
64 32
32 64
64 64
Yes, I tested all these possiblities.
Signed-off-by: Jackie Huang jackie.hu...@windriver.com
With verification of testing scope and the the minor comments below, I'm
OK with this approach. It's better than the native hack, but I'm not
sure it addresses an actual failure - but that's OK.
---
meta/classes/grub-efi.bbclass | 4 +-
.../{grub-efi-native_2.00.bb = grub-efi_2.00.bb} | 43 --
2 files changed, 26 insertions(+), 21 deletions(-)
rename meta/recipes-bsp/grub/{grub-efi-native_2.00.bb = grub-efi_2.00.bb}
(77%)
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index 2f00901..71bd00f 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -15,8 +15,8 @@
# ${GRUB_OPTS} - additional options to add to the config, ';' delimited #
(optional)
# ${GRUB_TIMEOUT} - timeout before executing the deault label (optional)
-do_bootimg[depends] += grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
-do_bootdirectdisk[depends] +=
grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
+do_bootimg[depends] += grub-efi:do_deploy
+do_bootdirectdisk[depends] += grub-efi:do_deploy
GRUB_SERIAL ?= console=ttyS0,115200
GRUBCFG = ${S}/grub.cfg
diff --git a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
b/meta/recipes-bsp/grub/grub-efi_2.00.bb
similarity index 77%
rename from meta/recipes-bsp/grub/grub-efi-native_2.00.bb
rename to meta/recipes-bsp/grub/grub-efi_2.00.bb
index 04973b5..2fe688c 100644
--- a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
+++
[OE-core] [PATCH v2] shadow: remove reference to locale env files from login and su
From: Qiang Chen qiang.c...@windriver.com /etc/default/locale missing message appears when login and running su user qemu0 login[4189]: pam_env(login:session): Unable to open env file: /etc/default/locale: No such file or directory qemu0 login[4189]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) qemu0 su[999]: pam_env(su:session): Unable to open env file: /etc/default/locale: No such file or directory qemu0 su[999]: pam_unix(su:session): session opened for user root by root(uid=0) This commit remove reference from pam.d/login and pam.d/su to /etc/default/locale env file to avoid the error messages as RHEL, fedora does. Signed-off-by: Qiang Chen qiang.c...@windriver.com --- meta/recipes-extended/shadow/files/pam.d/login |3 --- meta/recipes-extended/shadow/files/pam.d/su|3 --- 2 files changed, 6 deletions(-) diff --git a/meta/recipes-extended/shadow/files/pam.d/login b/meta/recipes-extended/shadow/files/pam.d/login index e4dacc2..b340058 100644 --- a/meta/recipes-extended/shadow/files/pam.d/login +++ b/meta/recipes-extended/shadow/files/pam.d/login @@ -32,9 +32,6 @@ auth requisite pam_nologin.so # # parsing /etc/environment needs readenv=1 session required pam_env.so readenv=1 -# locale variables are also kept into /etc/default/locale in etch -# reading this file *in addition to /etc/environment* does not hurt -session required pam_env.so readenv=1 envfile=/etc/default/locale # Standard Un*x authentication. auth include common-auth diff --git a/meta/recipes-extended/shadow/files/pam.d/su b/meta/recipes-extended/shadow/files/pam.d/su index 8e35137..8d590a3 100644 --- a/meta/recipes-extended/shadow/files/pam.d/su +++ b/meta/recipes-extended/shadow/files/pam.d/su @@ -34,9 +34,6 @@ auth sufficient pam_rootok.so # # parsing /etc/environment needs readenv=1 session required pam_env.so readenv=1 -# locale variables are also kept into /etc/default/locale in etch -# reading this file *in addition to /etc/environment* does not hurt -session required pam_env.so readenv=1 envfile=/etc/default/locale # Defines the MAIL environment variable # However, userdel also needs MAIL_DIR and MAIL_FILE variables -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] grub-efi: change to generate EFI image in target package
On Fri, 2013-11-22 at 12:49 +0800, jhuang0 wrote:
On 11/22/2013 10:45 AM, Darren Hart wrote:
On Wed, 2013-11-20 at 09:40 +0800, jackie.hu...@windriver.com wrote:
From: Jackie Huang jackie.hu...@windriver.com
It's not a good idea to generate the target EFI image in
a native packge,
This was admittedly a hack when I wrote it...
it would be a problem when build a 64bit
target on 32bit host.
I build 32b on a 64b host regularly, why is it a problem the other way
around?
There is infrastructure in place to specify the target architecture for
the grub efi binary and the modules. The 32b compiler should be able to
do -m64 just as the 64b compiler can do -m32.
It should be, but for most 32bit linux distributions, gcc is not
compiled for supporting 64bit cross compiling.
Thanks for the detail - including this information in the justification
would be a good idea so anyone looking at the commit log can understand
why it was necessary.
-do_install[noexec] = 1
-do_populate_sysroot[noexec] = 1
+FILES_${PN}-dbg += ${libdir}/${BPN}/${GRUB_TARGET}-efi/.debug
Technically this is an independent functional change...
You mean it should be in a separate commit?
I was thinking so, but I see Saul raised it as an issue with V2, so
please disregard this comment, it's fine.
I'd like to see a blurb added to the commit message stating the bit
about gcc not having support in some distributions (debian/ubuntu do
have it for example, but later versions require the compat package or
some such). The fact that some don't is enough though, and your solution
is cleaner and more consistent with bitbake recipe conventions anyway.
Thanks for keeping at it, this is a good improvement.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] grub-efi: allow compilation without large model support
On Fri, 2013-11-22 at 11:37 +0800, jhuang0 wrote: On 11/22/2013 10:49 AM, Darren Hart wrote: On Wed, 2013-11-20 at 09:40 +0800, jackie.hu...@windriver.com wrote: From: Jackie Huang jackie.hu...@windriver.com -mcmodel=large is not supported by gcc with version lower than 4.4, but we don't need to use memory over 4GiB, so add a patch to allow compilation without large model support. Signed-off-by: Jackie Huang jackie.hu...@windriver.com --- ...allow-a-compilation-without-mcmodel-large.patch | 69 ++ meta/recipes-bsp/grub/grub-efi_2.00.bb | 1 + 2 files changed, 70 insertions(+) create mode 100644 meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch diff --git a/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch b/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch new file mode 100644 index 000..b2be74a --- /dev/null +++ b/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch @@ -0,0 +1,69 @@ +From 0cea0e4266214da1f11e812834f5d5c47a6e04e6 Mon Sep 17 00:00:00 2001 +From: Jackie Huang jackie.hu...@windriver.com +Date: Tue, 5 Nov 2013 07:23:32 -0500 +Subject: [PATCH] Allow a compilation without -mcmodel=large + +* kern/efi/mm.c (grub_efi_allocate_pages): don't allocate 4GiB + when compiled without -mcmodel=large + (filter_memory_map): remove memory post 4 GiB when compiled + without -mcmodel=large +* configure.ac: add -DMCMODEL_SMALL=1 to TARGET_CFLAGS when + -mcmodel=large isn't supported + +Upstream-Status: Inappropriate [configuration] Nice try ;-) This is compatibility, not configuration. If grub-efi maintainers refuse to accept the patch that's up to them, but we need to Actually it's ported from old version of grub which means that they allowed the comilation without large model support before, but not now. From the Changelog, it was added in 2009: 2009-06-04 Vladimir Serbinenko phco...@gmail.com Allow a compilation without -mcmodel=large * kern/efi/mm.c (grub_efi_allocate_pages): don't allocate 4GiB when compiled without -mcmodel=large (filter_memory_map): remove memory post 4 GiB when compiled without -mcmodel=large * configure.ac: fail gracefully and add -DMCMODEL_SMALL=1 to TARGET_CFLAGS when -mcmodel=large isn't supported but it was removed in 2010: 2010-04-21 Vladimir Serbinenko phco...@gmail.com * configure.ac: Refuse to compile for x86_64-efi is mcmodel=large is not supported. So I think they may not accept this patch again. It does appear to be a deliverate removale, fortunatley, you know exactly who to Cc on the list now :-) It's worth shooting it off to the list to see what they say. Either way, it is definitely not a configuration patch. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] image.bbclass: depends on virtual/kernel
From: Chen Qi qi.c...@windriver.com The following changes since commit d60b4ff3517487bd111c6d7e1410882280229377: yocto-bsp: Add missing format specifier in bblayers error message (2013-11-21 14:20:28 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/image-kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/image-kernel Chen Qi (1): image.bbclass: depends on virtual/kernel meta/classes/image.bbclass |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] image.bbclass: depends on virtual/kernel
From: Chen Qi qi.c...@windriver.com
Add 'virtual/kernel' to DEPENDS in image.bbclass so that the kernel
can get built by default. Otherwise, the kernel will not get built
unless it's required by other packages like v86d. As a result, if
we build 'core-image-minimal' for qemumips, the kernel is not built,
and we have 'bitbake linux-yocto' before we can use runqemu to start
the target.
Signed-off-by: Chen Qi qi.c...@windriver.com
---
meta/classes/image.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index bc60f0d..ccb6bf3 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -10,7 +10,7 @@ inherit gzipnative
LICENSE = MIT
PACKAGES =
-DEPENDS += ${MLPREFIX}qemuwrapper-cross ${MLPREFIX}depmodwrapper-cross
+DEPENDS += ${MLPREFIX}qemuwrapper-cross ${MLPREFIX}depmodwrapper-cross
virtual/kernel
RDEPENDS += ${PACKAGE_INSTALL} ${LINGUAS_INSTALL}
RRECOMMENDS += ${PACKAGE_INSTALL_ATTEMPTONLY}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] qemu: add bash and python to qemu's RDEPENDS
On 11/22/2013 03:42 AM, Saul Wold wrote:
On 11/21/2013 11:40 AM, Mark Hatle wrote:
On 11/21/13, 12:42 PM, Saul Wold wrote:
Why are you adding bash to qemu?
My understanding is that there was a bash script that was added as well,
once the python rdepends was resolved.
Any chance of de-bashing the script?
Hi Saul,
How about to de-bash the script by the following patch:
...
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -5,6 +5,7 @@ DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11 pixman
dtc libsdl
DEPENDS_class-native = zlib-native alsa-lib-native glib-2.0-native
pixman-native dtc-native
DEPENDS_class-nativesdk = nativesdk-zlib nativesdk-libsdl
nativesdk-glib-2.0 nativesdk-pixman nativesdk-dtc
RDEPENDS_${PN}_class-nativesdk = nativesdk-libsdl
+RDEPENDS_${PN}_class-target += python
require qemu-targets.inc
inherit autotools
@@ -76,6 +77,12 @@ do_install_append() {
create_wrapper ${D}/${bindir}/qemu-mips \
QEMU_RESERVED_VA=0x0
fi
+
+ # De-bashing the script
+ files=`grep ^\#\! *.*\/bash ${D} -rl`
+ for f in $files; do
+ sed -i s:^#! *.*/bash:#! /bin/sh: $f
+ done
}
# END of qemu-mips workaround
...
The build test is ok.
//Hongxu
Sau!
--Mark
Sau!
On 11/21/2013 05:14 AM, Hongxu Jia wrote:
| Note: adding Smart RPM DB channel
|
| Note: to be installed: qemu@x86_64 run-postinsts@x86_64
kernel-modules@qemux86_64 packagegroup-core-boot@qemux86_64
| Loading cache...
| Updating cache...
[100%]
|
| Computing transaction...error: Can't install
qemu-1.5.0-r0.0@x86_64: no package provides /usr/bin/python
|
| Saving cache...
|
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_rootfs (log file is located at
tmp/work/qemux86_64-wrs-linux/wrlinux-image-glibc-small/1.0-r1/temp/do_rootfs/log.do_rootfs.21373)
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 21ce489..3f3431d 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -5,6 +5,7 @@ DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11
pixman dtc libsdl
DEPENDS_class-native = zlib-native alsa-lib-native
glib-2.0-native pixman-native dtc-native
DEPENDS_class-nativesdk = nativesdk-zlib nativesdk-libsdl
nativesdk-glib-2.0 nativesdk-pixman nativesdk-dtc
RDEPENDS_${PN}_class-nativesdk = nativesdk-libsdl
+RDEPENDS_${PN}_class-target += bash python
require qemu-targets.inc
inherit autotools
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] license.bbclass: fix copying license directories failed
Hi Paul,
On 11/22/2013 12:41 AM, Paul Eggleton wrote:
Hi Hongxu,
On Wednesday 20 November 2013 18:39:02 Hongxu Jia wrote:
For each recipe, it populated license files to ${LICENSE_DIRECTORY}/${PN},
such as kernel's license dir was
${LICENSE_DIRECTORY}/kernel-3.10.17-yocto-standard;
In do_rootfs task, it copied license directories from ${LICENSE_DIRECTORY}/
${pkg}, and ${pkg} was listed in ${INSTALLED_PKGS};
We got ${INSTALLED_PKGS} by rpm query, such as the kernel were 'kernel-*',
but the kernel's PN was linux-yocto, so searching ${LICENSE_DIRECTORY}/
kernel-* failed.
Copied license directories from ${LICENSE_DIRECTORY}/${PN} fixed this issue.
[YOCTO #5572]
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/classes/license.bbclass | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index 6d7ee94..32605ff 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -68,15 +68,18 @@ license_create_manifest() {
if [ ${COPY_LIC_DIRS} = 1 ]; then
for pkg in ${INSTALLED_PKGS}; do
mkdir -p
${IMAGE_ROOTFS}/usr/share/common-licenses/${pkg}
- for lic in `ls ${LICENSE_DIRECTORY}/${pkg}`; do
+ pkged_pn=$(sed -n /^PACKAGE NAME:
${pkg}$/,/^$/ \
+ {s/^RECIPE NAME: //; /^PACKAGE
NAME:/d; /^PACKAGE VERSION:/d; /^LICENSE:/d; p} \ +
${LICENSE_MANIFEST})
+ for lic in `ls
${LICENSE_DIRECTORY}/${pkged_pn}`; do
This isn't the right way to do this. If you need to look up the recipe name
from the target package name, in master you can now use:
oe-pkgdata-util lookup-recipe ${PKGDATA_DIR} list of packages
I am afraid to use oe-pkgdata-util here is not a good idea:
- everything we need has been listed in ${LICENSE_MANIFEST},
we just need to sort them out;
- the oe-pkgdata-util utility only support to search the specific
${PKGDATA_DIR} directory which was ${TMPDIR}/pkgdata/
${MULTIMACH_TARGET_SYS}, but we need to search multiple
${MULTIMACH_TARGET_SYS} directories;
Such as base-passwd in x86_64 and base-files in qemux86_64;
//Hongxu
Cheers,
Paul
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] grub-efi: allow compilation without large model support
On 11/22/2013 1:04 PM, Darren Hart wrote: On Fri, 2013-11-22 at 11:37 +0800, jhuang0 wrote: On 11/22/2013 10:49 AM, Darren Hart wrote: On Wed, 2013-11-20 at 09:40 +0800, jackie.hu...@windriver.com wrote: From: Jackie Huang jackie.hu...@windriver.com -mcmodel=large is not supported by gcc with version lower than 4.4, but we don't need to use memory over 4GiB, so add a patch to allow compilation without large model support. Signed-off-by: Jackie Huang jackie.hu...@windriver.com --- ...allow-a-compilation-without-mcmodel-large.patch | 69 ++ meta/recipes-bsp/grub/grub-efi_2.00.bb | 1 + 2 files changed, 70 insertions(+) create mode 100644 meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch diff --git a/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch b/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch new file mode 100644 index 000..b2be74a --- /dev/null +++ b/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch @@ -0,0 +1,69 @@ +From 0cea0e4266214da1f11e812834f5d5c47a6e04e6 Mon Sep 17 00:00:00 2001 +From: Jackie Huang jackie.hu...@windriver.com +Date: Tue, 5 Nov 2013 07:23:32 -0500 +Subject: [PATCH] Allow a compilation without -mcmodel=large + +* kern/efi/mm.c (grub_efi_allocate_pages): don't allocate 4GiB + when compiled without -mcmodel=large + (filter_memory_map): remove memory post 4 GiB when compiled + without -mcmodel=large +* configure.ac: add -DMCMODEL_SMALL=1 to TARGET_CFLAGS when + -mcmodel=large isn't supported + +Upstream-Status: Inappropriate [configuration] Nice try ;-) This is compatibility, not configuration. If grub-efi maintainers refuse to accept the patch that's up to them, but we need to Actually it's ported from old version of grub which means that they allowed the comilation without large model support before, but not now. From the Changelog, it was added in 2009: 2009-06-04 Vladimir Serbinenko phco...@gmail.com Allow a compilation without -mcmodel=large * kern/efi/mm.c (grub_efi_allocate_pages): don't allocate 4GiB when compiled without -mcmodel=large (filter_memory_map): remove memory post 4 GiB when compiled without -mcmodel=large * configure.ac: fail gracefully and add -DMCMODEL_SMALL=1 to TARGET_CFLAGS when -mcmodel=large isn't supported but it was removed in 2010: 2010-04-21 Vladimir Serbinenko phco...@gmail.com * configure.ac: Refuse to compile for x86_64-efi is mcmodel=large is not supported. So I think they may not accept this patch again. It does appear to be a deliverate removale, fortunatley, you know exactly who to Cc on the list now :-) It's worth shooting it off to the list to see what they say. Either way, it is definitely not a configuration patch. Yes, I will change to compatibility in v4 and add Vladimir in cc list. Thanks, Jackie -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -- 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 4/4] qemu: add bash and python to qemu's RDEPENDS
On 11/22/2013 01:58 PM, Hongxu Jia wrote:
On 11/22/2013 03:42 AM, Saul Wold wrote:
On 11/21/2013 11:40 AM, Mark Hatle wrote:
On 11/21/13, 12:42 PM, Saul Wold wrote:
Why are you adding bash to qemu?
My understanding is that there was a bash script that was added as
well,
once the python rdepends was resolved.
Any chance of de-bashing the script?
Hi Saul,
The script could not be de-bashed, it was made by create_wrapper
which is bashism:
Vim image/usr/bin/qemu-mips
...
#! /bin/bash
realpath=`readlink -fn $0`
export QEMU_RESERVED_VA=0x0
exec -a `dirname $realpath`/qemu-mips `dirname $realpath`/qemu-mips.real
$@
...
The exec's -a option is bashism, so we need to add bash to RDEPENDS.
//Hongxu
Hi Saul,
How about to de-bash the script by the following patch:
...
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -5,6 +5,7 @@ DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11
pixman dtc libsdl
DEPENDS_class-native = zlib-native alsa-lib-native glib-2.0-native
pixman-native dtc-native
DEPENDS_class-nativesdk = nativesdk-zlib nativesdk-libsdl
nativesdk-glib-2.0 nativesdk-pixman nativesdk-dtc
RDEPENDS_${PN}_class-nativesdk = nativesdk-libsdl
+RDEPENDS_${PN}_class-target += python
require qemu-targets.inc
inherit autotools
@@ -76,6 +77,12 @@ do_install_append() {
create_wrapper ${D}/${bindir}/qemu-mips \
QEMU_RESERVED_VA=0x0
fi
+
+ # De-bashing the script
+ files=`grep ^\#\! *.*\/bash ${D} -rl`
+ for f in $files; do
+ sed -i s:^#! *.*/bash:#! /bin/sh: $f
+ done
}
# END of qemu-mips workaround
...
The build test is ok.
//Hongxu
Sau!
--Mark
Sau!
On 11/21/2013 05:14 AM, Hongxu Jia wrote:
| Note: adding Smart RPM DB channel
|
| Note: to be installed: qemu@x86_64 run-postinsts@x86_64
kernel-modules@qemux86_64 packagegroup-core-boot@qemux86_64
| Loading cache...
| Updating cache...
[100%]
|
| Computing transaction...error: Can't install
qemu-1.5.0-r0.0@x86_64: no package provides /usr/bin/python
|
| Saving cache...
|
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_rootfs (log file is located at
tmp/work/qemux86_64-wrs-linux/wrlinux-image-glibc-small/1.0-r1/temp/do_rootfs/log.do_rootfs.21373)
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 21ce489..3f3431d 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -5,6 +5,7 @@ DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11
pixman dtc libsdl
DEPENDS_class-native = zlib-native alsa-lib-native
glib-2.0-native pixman-native dtc-native
DEPENDS_class-nativesdk = nativesdk-zlib nativesdk-libsdl
nativesdk-glib-2.0 nativesdk-pixman nativesdk-dtc
RDEPENDS_${PN}_class-nativesdk = nativesdk-libsdl
+RDEPENDS_${PN}_class-target += bash python
require qemu-targets.inc
inherit autotools
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] grub-efi: change to generate EFI image in target package
On 11/22/2013 1:02 PM, Darren Hart wrote:
On Fri, 2013-11-22 at 12:49 +0800, jhuang0 wrote:
On 11/22/2013 10:45 AM, Darren Hart wrote:
On Wed, 2013-11-20 at 09:40 +0800, jackie.hu...@windriver.com wrote:
From: Jackie Huang jackie.hu...@windriver.com
It's not a good idea to generate the target EFI image in
a native packge,
This was admittedly a hack when I wrote it...
it would be a problem when build a 64bit
target on 32bit host.
I build 32b on a 64b host regularly, why is it a problem the other way
around?
There is infrastructure in place to specify the target architecture for
the grub efi binary and the modules. The 32b compiler should be able to
do -m64 just as the 64b compiler can do -m32.
It should be, but for most 32bit linux distributions, gcc is not
compiled for supporting 64bit cross compiling.
Thanks for the detail - including this information in the justification
would be a good idea so anyone looking at the commit log can understand
why it was necessary.
-do_install[noexec] = 1
-do_populate_sysroot[noexec] = 1
+FILES_${PN}-dbg += ${libdir}/${BPN}/${GRUB_TARGET}-efi/.debug
Technically this is an independent functional change...
You mean it should be in a separate commit?
I was thinking so, but I see Saul raised it as an issue with V2, so
please disregard this comment, it's fine.
I'd like to see a blurb added to the commit message stating the bit
about gcc not having support in some distributions (debian/ubuntu do
have it for example, but later versions require the compat package or
some such). The fact that some don't is enough though, and your solution
is cleaner and more consistent with bitbake recipe conventions anyway.
I will add these information to the commit log in v4.
Thanks,
Jackie
Thanks for keeping at it, this is a good improvement.
--
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
